Aehso’s Output

Brain.Save(), Steve Maine’s blog, has an excellent piece on Isomorphism that, in the ideal world, everyone could swear they undertood before attempting to write a web service. The vast majority of coders out there will never get this write for a very simple reason – they are too used to cutting writing code in a particular language/environment/platform and they make the mistake of carrying over these habits when it comes to modelling services.

Steve makes some references CORBA in his article, commenting that

Previous distributed object systems focused on establish a common local programming model and treated the mechanism of inter-object communication as an implementation detail. The late arrival of a standardized inter-ORB wire protocol to the CORBA scene is, I think, evidence that wire-level interoperability was a secondary concern for them.

History illustrates that IIOP did arrive late but I don’t think Steve is giving CORBA the credit it deserves here. (Some comparisons before reading on – SOA has XSD/WSDL/Policy for definition and SOAP for protocol, CORBA has IDL for definition and IIOP for protocol)

• The early CORBA specifications were more concerned with constructing a canonical form for service interfaces (IDL) than defining the local programming model. In fact, it wasn’t until the arrival of the POA in CORBA 2.3 that the local programming model for implementing CORBA servers was tied down in fine detail.
• The OMG had no choice but to pin down the IDL specification before tackling the underlying IIOP specification. There’s a very, very good reason for that – it allowed the various language mapping experts to start writing language bindings, ORB vendors to develop products and early adapters to start modelling solutions on CORBA IDL, knowing that better interoperabily was on the way.

Would it have made sense for the OMG to have produced the IIOP specification first? If they had done that, there would have been no way of expressing the service contract between the peer local programming languages involved in the interaction. Remember, IIOP uses binary encoding, not verbose text/XML encoding! It may be that Steve is forgetting the vacuum that CORBA filled at the time. People just didn’t want interoperability beyond a single vendor’s offering – everyone was used to being locked into COM or using sockets or an client/server RPC on Unix

Steve’s statement that “wire level interoperability is the only thing that matters” is an interesting one. Wire-level interoperability is all well and good but SOA still needs a higher level canonical form that humans can use to interpret service definitions.

Let me put it this way, which would you be happiest with receiving if you were thinking of interoperating with a 3rd party’s service:

1. A set of raw SOAP messages (and the SOAP/WS-Adressing/WS-Policy specifications) illustrating wire-level interoperability
2. An annotated XSD/WSDL/Policy document
3. An Indigo interface of CLR types annotated with custom attributes.

(There’s no need to answer that, it was a rhetorical question) From a SOA tool vendors perspective, it would be nice not to have to wrry about all those intermediate constructs like WSDL and just go straight from the native definition to “on the wire interoperabilty” the way you know best. But you are assuming that your tool developers have the competence to hand craft the mapping perfectly and you are assuming that your customers don’t have some other requirement for at least producing WSDL (e.g. modelling tool interop).

I’ve always wondered if the CORBA vendors wouldn’t gain wider acceptance into the SOA ’scene’ if they just went and renamed CORBA to CSORBA (Common Service Object Request Broker Arch). Folks get so hung up on the difference between a “service” and a CORBA object. Steve rightly hints at this again in his article when he states:

…distributed objects are a perfectly reasonable way of looking at web services. I think that’s true to some degree; as long as you recognize that those ‘distributed objects’ are an illusion of your model and don’t exist in any real way beyond your network port, distributed objects are as good a model as any other isomorphism

Hmmmmm, the Portable Object Adapter anyone?

P.S. Steve, I did enjoy the SOAP vs REST comment at the end!

aehso net