KeithBa writes...

I also believe that OOP will be supplanted as the dominant programming model over the next 5-10 years as the XML and Web services model takes hold. I'm already building apps where I send hand-crafted SOAP messages within the application from one piece of code to another. Remember: the OS itself works off a message pump.

I agree, but we have examples already that are far simpler than SOAP/WS-xxx. Consider the open source Erlang system. Their messaging system is multi-language through the use of erl_interface and works with pure Java using jinterface.  ¶ 9:18 PM

Don Box writes...

My only point of contention is Sam's statement that when you control both ends of the wire, SOAP isn't the right answer.

I'm not convinced... For one, even in a homogeneous system, managing interface evolution in a CORBA/DCOM-like system is much harder than in a XML/SOAP-based system.

This might be a good argument if the choices were restricted to SOAP, CORBA, and DCOM. But remember, all three of these systems were intended for multi-language and multi-owner distributed interfaces.

If you truly own both end-points then you can provide very simple and transparent mechanisms such as those in Gemstone Smalltalk. Or far simpler, the open source Erlang.

And Don continues...

More importantly, as the supporting infrastructure for SOAP gets hardened into the (distributed and local) computing fabric, there is a lot to be gained from leveraging it. Today, this advantage isn't so obvious. Going forward, I think it will be.

No doubt there will be a lot to be leveraged as enterprises invest millions of dollars into a SOAP/WS-xxx infrastructure.

The question though is this the most efficient investment? Why?

The Web Services hype (and it is not much more than that today for most corporations) appears to me to be a "taking" in the making. If I controlled the purse strings I would sit back as long as possible to watch this stuff shake out. Let someone else spend the $$$ for now and then read the blogs that tell me what went wrong.

If I had to forge ahead with something I would do the simplest thing that could possibly work. I would look for the Web Services equivalent of Philip and Alex's Guide to Web Publishing   ¶ 8:47 PM

Andy [Hertzfeld] says "the hard thing about being a programmer is keeping track of lots of abstract things." I disagree. The hard part of programming is creating static documents (whether tectual or graphical) that result in correct dynamic interactions. This static to dynamic barrier is something most people don't cross with ease.

I'm with Phil Windley on this. (The quote above is from his blog). We struggle to simplify dynamic interactions even conceptually. And we have not even begun to figure out truly useful notations.

Toss distance and asynchrony into the equation and we are still very much at a loss.  ¶ 8:19 PM

From Infoworld's Web Services Report...

This declarative approach is the real essence of SOA, and of course it's not a new idea. I trace its lineage to MTS (Microsoft Transaction Server), which begat COM+ and J2EE. All these middleware technologies pull services (e.g., transaction management, connection pooling) out of components, and weave them into to the fabric in which the components are deployed.

We can (and should) go even 30 years back to discover some deeper roots of Web Services that run through but do not originate with MTS...

• CORBA 1.0 in 1991 was based on several earlier efforts from the 1980s.
• The modern transactional aspects have their roots deeper still at AT&T more than 20 years ago.
• Tuxedo is itself influenced by IMS in the 1970s.