Fujitsu, along with Sun, NEC, Oracle and Sonic Software published a proposal for reliable messaging with SOAP. I assume this has been reported all over blogland already, but I am a bit "connection challenged" right now since I've been on the road, so I couldn't really do much blog reading. I've had time to look at this spec offline, though, and I think it is indeed interesting -- because it is so familiar.

Comparing WS-Reliability to the 2 year old BizTalk Framework 2.0, which first defined the reliability mechanism also known as SRMP -- SOAP Reliable Messaging Protocol, shows that there's unfortunately very little new to see in WS-Reliability, with the notable exception of ordered delivery of message sequences through the use of unique message identifiers. What's also interesting -- and doesn't really make me happy -- is that we're seeing the invention of yet another message header with message-id. WS-Routing, for instance, already defines one and I don't get why there needs to be yet another header to establish message identity with WS-Routing being around for such a long time already. I would think that reliable messaging is something that doesn't really work without a solid understanding of where to send a message, so it certainly could and probably should pick up that header instead of defining its own.

A bigger problem is, though, that WS-Reliability carries forward quite a few shortcomings of the BizTalk Framework and introduces a whole set of new problems due to the spec's choice of language.

• Because WS-Reliability is unaware of and not integrated with WS-Routing, it is only useful as a point to point mechanism. While routing from the sender to the receiver will likely be possible, the "ReplyTo" to send the acknowledgement message to does specify a plain URL and doesn't allow integration with a reverse path as per WS-Routing. This means that unless the ACK message can be piggybacked on a synchronous response (the luckiest of all circumstances), the spec requires either direct connectivity from the receiver back to the sender, which may be impossible due to firewalls and NAT, or requires some form of acknowledgement message dispatcher gateway at the sender's site, which requires some form of central service deployment as well. In short: This doesn't really work for a desktop PC wishing to reliably deliver a message to an external service from within the corporate firewall.
• There's quite a few problems to be solved with regards to simple sequence numbers and resends of an unaltered, carbon-copy (2.2.2) of the original message considering the accuracy of message timestamps, digital signatures, context coordination and techniques to avoid replay attacks. Sending the exact same message may be entirely impossible, even if it couldn't be delivered properly and therefore the "MUST" requirement of 2.2.2 cannot be fulfilled. Also, in 2.2.2 there's a reference to a "specified number of resend attempts" -- who specifies them?
• The spec rightfully calls for persistent storage of messages (2.2.3), but doesn't spell out rules for when messages must be written to persistent storage in the process (it should obviously before sending and after receiving, but before acknowledgement and forward).

What I find also very noteworthy is that the authors say that they have yet to address synchronization between sender and receiver and establishing a common understanding by sender and receiver about whether the message was properly delivered (meaning that the send/ack cycle was fully completed). I assume that once they do so, they'll throw the synchronous, piggybacked reply on top of HTTP out of the window, because this creates an in-doubt situation for the acknowledging party.

A modular application without well-defined extensibility points is not modular.

I still can't believe that I stayed up until 2am to see the Giants throw away their game like that in the 4Q.

The recurring New Year's Resolution: "Keeping up with technology." Sigh!

Happy New Year. Patricia and I spent New Year's in New York this time. Observations: The city changed a lot and then again it didn't. There are definitely more "new parents" to be seen now, the Times Square area is no longer a place to be scared of, quite a few subway lines and stations got a makeover ... still, it doesn't feel that much different from back in '96 when I moved back to Germany (I've been back to NY only twice since then and not at all after 9/11/01).

Restaurant favorites this time around: Sushi Hana, 466 Amsterdam Ave - great sushi, excellent sake list; El Quijote, 226 W 23rd St - a long-time classic and easily the best value place for lobster lovers (If you are really hungry get the Paella with Lobster -- I am a big boy and I have no chance finishing it); EJ's Luncheonette, 445 Amsterdam Ave - The west-side standard for breakfast.

And this was definitely the last time I flew Delta Airlines across the Atlantic. Charging for booze on a trans-Atlantic flight is ridiculous. On top of that, our baggage is MIA for the third day now.

What would Leonardo do, if he was living today?

A beginner's guide to the Latin language, part 1. In a world that was better governed than the one in which we are forced to dwell, Latin was the foundation of the educational system, and the fountain of literacy: to know how to read and write was to know how to read and write Latin.  Knowing Latin, you could speak to anyone else who had been educated under the same régime.  Knowledge of the Latin language remains a matter worth pursuing. For speakers of English, Latin offers more than most others of the valuable intellectual exercise that comes from the study of foreign languages.  It opens a door to the classical, mediæval, and renaissance worlds.  The Latin language has a solemn beauty and cultural resonance that few others share.  It enhances your appreciation of the greatest music written in Europe.  In this article, which your interest or lack of same may turn into a series of several, we consider the grammatical structure of Latin and how it contrasts with English. [kuro5hin.org]

7 years. I had Latin in school for 7 years. It was the first foreign language I learned. English is actually only my third language. Considering that, it's absolutely ridiculous what's left of it in my head. I can, however typically get the gist of most of what's written on the walls in old churches throughout Europe. I absolutely love Renaissance arts, the early and high periods of the Italian Renaissance specifically and some of the greatest works are, unsurprisingly, in churches.

The above is indeed absolutely accurate, the referenced article contains a few things I don't agree with, though. For instance, last time I looked there were Roman languages, Indo-Germanic languages and Slavic languages as the biggest language groups in Europe.  Add Greek, and the unlikely group of Finnish and Hungarian, which share common roots, and with the exception of a few local languages that are entirely different, this should cover most of the language roots in Europe. "Indo-European" doesn't exist, though. English, German, Dutch, Norwegian, Swedish, Danish have all Indo-Germanic roots, while French, Italian and Spanish have Roman roots. So, historically speaking, our languages are either Imperialist or Barbarian.

Aliens pledge their support in war with Iraq.

... "It sounds like Bush is getting desperate," says one skeptic. "Little green men wanting to fight side by side with America? It's like Bush can't get the support of the other countries on our world, so he's counting on getting help from other worlds." ...

An completely on-topic post in regards to my blog-title and an opportunity to publicly thank my friend Steve Swartz for a great birthday gift that has very much enlightened me. He signed me up for a subscription to Weekly World News and since I am a curious reader of this insightful paper, I know more about the culture of America than ever before. The best thing about Weekly World News is that they never, ever would report anything that is not 100% true. Never.

However, the reference to that satirical WWN article is also on-topic because I honestly think that there are good reasons to be hestitant about marching towards Baghdad. Saddam is a cruel dictator, but establishing a healthy democracy by western measures in the void of power that will come after Saddam after such a war is entirely illusionary. Such a democracy has never remotely existed there and the Arab world as such has a completely different perception and concept of leadership that has little in common with our western ideas and which we should accept to not understand. Also, it's noteworthy that North Korea has just admitted a nuclear arms program and shrugs off complaints about restarting its nuke plants. ... I would consider that a bigger concrete and present threat, really. Probably a third of all countries in the world have some biological or chemical weapons capacity. Something tells me that the rushed urgency in the case of Iraq isn't a good idea. Then again, I could be all wrong because of intelligence information that we all will never know of.

 

I had an IM discussion with a fellow (unnamed) blogger about the post preceding this one. He thinks I shouldn't make political remarks here.

Fighting dictators and terrorism is about protecting our freedom. Free speech is part of that. Therefore I speak. Do politics and technology mix? They do and they must. At the newtelligence office, a good deal of the daytime talk is about political issues and world events. We're all interested in many things beyond technology and that enables us to make better strategic judgements. We don't agree on many things. In fact, our basic views are almost evenly distributed across the political spectrum - which makes discussions even more interesting.

Welcome a new blogger on the block: Morten Abrahamsen! (Blog, RSS). Morten is a friend of mine who I met at one of my many visits to Norway last year.

Morten is, among other things, a key architect of a major B2B exchange system in Norway, has been more than once more than knee-deep in the mud of the not-so-nice areas of Windows DNA and demonstrates a very pragmatic point-of-view towards system architecture that very often truly reflects the coolness of his Nordic home in winter. A blog to watch and a person to learn from.

One step closer. SOAP 1.2 has reached W3C candidate recommendation status. Primer, Part 1, Part 2.

Quickies.
Dave Winer:  ...thanks to the magic of namespaces...
[Sam Ruby]

I think I understand why Sam thinks that Dave writing this is something worth quoting :)

Crazy benchmarks

There are a lot of JVM vs. CLR "benchmarks" popping up all over the place, which are used as arguments for or against the respective environments. I am not talking about the "Petshop wars" here; I have rather looked at a few of the "little ones" that are used as ammunition in advocacy forums. The problem: Almost all of these "benchmarks" really only show how hard it is to write good and fair performance tests that give others some actual guidance.

I picked out two: On Javalobby.com, Dan Benanav shows how Swing outperforms Windows Forms by comparing the performance of the grid controls of Swing and Windows Forms. The Swing version wins easily in his version -- further down in the discussion thread someone rewrote the scenario and Windows Forms blows Swing away. The issue is that this test is so singularly focused on a specific feature that it doesn't tell anybody anything good about either environment. The same is true for Daniel Mettlers Mono benchmark. The "benchmark" tries to illustrate performance using 100000 iterations through a loop printing "Hello World" to the console. Again, this test may say a lot about console output performance but nothing about anything else.

In a time, where any desktop machine that you can buy at a supermarket has more firepower than 98% of all desktop applications will ever need in terms of GUI performance, client-side benchmarks are really "out". Even a Java application without any JIT will work more than satisfactory for most users that have >1GHz under their fingertips. Good server-side benchmarks are a different issue and still needed. But those require a lot of time, architectural thought, knowledge of proper algorithms and, more importantly, the money to buy/lease/borrow the required hardware.

The biggest "performance problem" is typically not the underlying platform, it's thoughtless programming where (proper choices of) algorithms don't play any role, where the choice between synchronous and asynchronous operations are not considered, where time is burned up in parsing and compiling query-plans for ad-hoc SQL queries instead of using stored procedures, where complex service constructs like EJB or COM+ are mindlessly used for "code consistency" reasons and not for the services they provide and so on and so on.

Only if all these things are considered, comparing platforms for raw speed may begin to make sense. However, the result is typically: "Your mileage may vary" and "It still depends on what you do".  The great side-effect of benchmark wars like those happening around the .NET/J2EE Petshop battle is that there are a lot of architectural best practices evolving in the process: These are the interesting bits, the raw numbers are of much lesser value.

All numbers are worthless if you don't look at how they were achieved and learn from the differences in choice of platform, architecture and implementation technique.

However, it'd be much more important to look at a different kind of speed: How long does it take the average developer to complete a certain task, achieveing set quality goals? How long does it take an average developer to understand code he or she needs to maintain? I don't see such benchmarks all that often.

Pioneer 10 lives.

WS-Policy is public. This spec is significant as it is a step towards separating message content declaration (aka "what we have now in WSDL") from the services and QoS declaration. There are also significant new specs around WS-Security. WS-Trust and WS-SecureConversation are specifically interesting for things as those that I have been doing with my Kerberos integration with WS-Security, because it provides a framework for establishing trust relationships and secure, "connection-like" bidirectional conversations (and not only one-shot messages).

Microsoft Watch: "One source close to the company said that Microsoft has held internal discussions to kick around ideas for XML-specific language, referred to internally as 'X#'." (via Managed Space) [Brian Jepson's Radio Weblog]

(a) Dig out your PDC2001 CD.
(b) Look for the "XLANG/s" sample
(c) Look at the assemblies with ILDASM