SOA musings

I'm trying to work out if there is anything interesting in SOA. I'm hopeful that there is, but I haven't found anything written about SOA that captures it, despite the fact that a lot of clever people are writing about SOA. Of course, much of this verbiage is due to to the SOA hype machine. But once you discard the hype, what is left?

If there is any merit to Web Services, it must be in SOA, since it is certainly not in the concrete realization of SOA as XML Web Services. Each layer is flawed in various ways. XML may be a nice document interchange format, but it is a strange choice as a message serialization format for communications protocols (even if you focus on document/literal style web services). SOAP, XML Schema and WSDL all have reasonable ideas at their cores, and can all be made to work, but none of them fit their niches perfectly, and none of them are a model of simplicity and elegance.

So where is the merit in SOA?

The most frequently cited statement of the essence of SOA seems to be Don Box's four tenets:

  1. Boundaries are explicit.
  2. Services are autonomous.
  3. Services share schema and contract, not class.
  4. Service compatibility is determined based on policy.

The first two tenets seem to me to be a matter of emphasis, rather than innovations. These principles can be used to advantage in conjunction with CORBA or COM; conversely, there is nothing about Web Services that requires these principles to be observed (though some Web Services toolkits make boundaries explicit simply by having an excessively clunky programming model).

The third tenet seems like the weakest of the four. CORBA and COM do not share programming language classes; they share contracts defined in their IDLs. The relevant implementations map contracts specified using those IDLs onto machine-centric bindings and representations, rather than the textual XML representations used by Web Services. But there is little in those IDLs that mandates such a particular mapping. In any case, the debate does not seem to hinge on the superiority of XML as a data format compared to more machine-centric formats (perhaps becuase the XML generated by web-services toolkits is often little more human-readable than machine-centric representations). So my guess is that this tenet has its origin as a reaction to something else:

  • Java RMI, where the Java programming language also serves as the IDL, and objects can be passed across remote interfaces with few restrictions.
  • COM, which was often seen as simply a mechanism for inter-programming-languange calls. This has left it somewhat tainted as a distributed programming technology, despite the existence of DCOM.

My conclusion is that if the first three tenets were all there is to SOA, then CORBA and DCOM would be perfectly adequate technologies for implementing SOA.

Which leaves "Service compatibility is determined based on policy". I have not yet come to any conclusion about how strong this tenet is. I suspect that there is something there, but the examples offered by WS-Policy and the related specifications are not very convincing.

Published interfaces

Martin Fowler's description of published interfaces struck a chord. In my day job, I maintain a large Java code base, which is used from several other projects. Mostly those other projects use the "published" interfaces, but sometimes they try to use classes and interfaces that I regard as internal (although they are declared as public, since they are internal but widely used within my code base). Eventually I will have to document the list of published classes and interfaces. I plan to start by making a list of classes that are already used externally. A while ago, I wrote a Perl script that analyzes dependencies between .class files, and it shouldn't be too hard to adapt it for this purpose.