On SOA and OOA

I originally wrote this entry on October 7, 2004, and published it on blogs.sun.com.

It may be unfair to pick on a 12-month-old friendly piece on the concept of Service Oriented Architecture (SOA); but I'm pointing to Hoa He's article because it is one of the more well-written ones, comparatively speaking.

The distinction Dr. Hoa He draws between SOA and OO programming (or should I say OOA, Object-Oriented Architecture) is interesting but seems to have some basic flaws, the primary one being that of mis-taken analogies, particularly the CD analogy of service.

To say that OO programming is about shipping code with document or data ("every CD would come with its own player and they are not supposed to be separated") is a bit of an over-simplification of OO principles if not pure and simple red herring. Furthermore, in the CD analogy, the CD sometimes stands for the consumer of the service and sometimes for the data sent to the service. The latter, of course, is of greater interest. In most cases of SOA, however, something does happen to some data. Nothing seems to happen to CDs as they move from player to player and they leave no trace in the service cosmos (unless of course they're copied and sent off to digisphere). To draw a more complete picture of SOA, it seems, one would have to account for those traces and come up with better analogies.

Now, to idempotency: How can idempotency be achieved without any state in the service or some other service on which the responding service depends? Again, idempotency seems O.K. with CDs which leave very little trace behind on the "player service" after having been played. But if a trace is left behind, which is always the most interesting case for an enterprise or an exchange of one sort or another, then how can you have idempotency if that trace is unavailable to the service, i.e. if the service is "stateless".

Moving on to exchange and document-centric view of things: "SOAP RPC web services are not SOA; document-centric SOAP web services are SOA," Dr. He writes. Not much of a controversy here, only an anticipation: Documents are usually exchanged. So, would it have been better to jump to EOA (Exchange Oriented Architecture), i.e. the IETF model of "architecture" (a large number of useful exchange protocols for plug and play) than to SOA, specially when the concept of "service" is so loaded as the mis-taken analogies I discussed above prove? Just a question to wonder about . . .

Here is another point having to do with the essentiality of WSDL, which I don't think is drawn clearly in the article: In a "SOAP Web Service," the description of a service must be in WSDL, the article says. This aspect of it has always confused me quite a bit. Let me give an example, one that I have given before in other forums.

MMS-Cs (Multi-Media Messaging Service Centers) have now been in production and deployment for more than 3 years, but the MMS specs (at least up to 23.140 v. 6.7, September 2004) produced by 3GPP have never defined the service in WSDL. In plain English, they do lay out, in great detail, the format of SOAP messages and how they are used. So, what is the problem in not specifying a WSDL specially if the choreography of the service cannot even be captured in WSDL?

It would be an odd thing to claim MMS-C architecture is not a SOA architecture simply because it does not define service in terms of WSDL unless we want to say that the "S" in "SOA" is not quite about "Service" the way we know of it from deployments.

Concluding on a positive note, here is an interesting quote from the article: 'Ironically, SOAP was originally designed just for RPC. It won't be long before someone claims that "SOAP" actually stands for "SOA Protocol".' I don't know why but I like that quote.

And last, but definitely not least, it may be worthwhile to see if there are any points of comparison between REST and (a categorical lift of) Linda with particular attention to the HTTP GET, DELETE, POST and PUT interface semantics in REST as described in Dr. He's article.