Clemens Vasters is talking about a large sample application he is writing for TechEd. It is a distributed, transactional system, and he is working through the difficulty of handling failures. Specifically, he is wondering what to do if his transactional serviced component makes a call to a web service over HTTP, and a failure happens somewhere in the overall transaction.

He goes on to describe a number of complicated ways around the problem. I see a couple of basic problems, issues with his approach:

• Trying to use a simple, stateless protocol as part of a transactional system.
• Trying to make a distributed method call look just like a local call.

At the risk of sounding like a crotchety CORBA asshole, if you want platform and language independence and distributed transactions, you might want to use something more than a dirt-simple, stateless, text-only wire protocol.

It is terribly strange to have watched web services grow from the wonderfully simple XML-RPC, to then evolve into SOAP, which reveled in its "distributed programming without the CORBA cruft" attitude, to then, piece by piece, replace all of CORBA's complexity. I guess it is cool that every firewall in the world lets port 80 pass, but maybe that shouldn't be the only criteria used when selecting a protocol.

I'm not sure when they were handing out the distributed programming feel-good pills, but I sure missed them. It is odd to think that a distributed method call can look and function just like a local one. It is bizarre to implement a system this way. But this attitude prevails, in a kind of "gee whiz, I'm writing distributed software today!" way.

Adding host-independence introduces many problems you don't face with a regular system. Memory management, transaction management, and service location all get a lot more complicated when components are distributed among a bunch of different servers. Distributed method calls shouldn't look and feel like local calls because they aren't the same; so much more can go wrong.

Clemens is a really smart guy, as are a lot of the people working on these issues. But I'm sad that our industry couldn't come together a little better to solve these problems. My concern is that we'll be stuck with another albatross, like the 16-bit windows legacy. There were perfectly good reasons for the way things were designed, but the framework started collapsing under its own hacked-together weight. Distributed development will surely be a large part of future systems, but I'm not terribly happy with the way things are going.