It’s just data

Control freaks

Don and Keith (who has a broken permalink) call me to task on my If you ever are in a position where you can control both ends of the wire... There are much better protocols than SOAP statement.  This statement is merely a device I use to get to the heart of the issue quickly.

The primary purpose of this statement is to deflate arguments like this one.  Read the entire thread to see how well it works.

It is also about setting expectations... for example: round tripping is not always 100%.  There are a concessions one must make in order to achieve true platform and language neutrality.

But mostly it is to make the point that you rarely control both ends of the wire as much as you might think.  Systems are fractal.  Even if two relatively adjacent parts are developed in the same language on the same platform by the same company, if there are two teams involved and the interface is viewed as a contract, then it makes sense to view this interface as an fungible.


Hi Sam,

This is one reason I like Roger Session's Software Fortress Model so much - it points fairly nicely to the fact that different things are appropriate within each fortress compared to between fortresses.

http://www.thearchitect.co.uk/weblog/archives/2003/04/000134.html

I think the important thing is that you have different options inside (when you do control both ends) and outside (when you don't).  SOAP MAY be right inside too, which is partly Don's point (and I suspect Sam's too ;-).

There are some minor problems with the Fortress model too, but from the 39,000 foot view it seems to provide a useful framework for my thoughts at least.

- Jorgen

Posted by Jorgen Thelin at

Regarding Keith's comment:

"I can't think of system I could build ... that requires anything SOAP doesn't offer."

Couldn't you also make this statement about pretty much any middleware technology?

Check out the infrastructure services and domain specific specs at OMG, then try:

"I can't think of system I could build ... that requires anything CORBA doesn't offer."

Here we go with yet another silver bullet! ;-)

The main difference with SOAP of course is the inherent extensibility it has (primarily SOAP headers and XML namespaces) without needing to run back to some central authority to register an extension (like the "slot ids" in CORBA IIOP Service Contexts)

- Jorgen

Posted by Jorgen Thelin at

Add your comment