The practice of "separating concerns" is a critically important tool for software architects, as it helps us introduce loose coupling where we need it in the systems we design. Unfortunately, it seems we're not as collectively proficient with that practice as we need to be, at least in the context of Web services and SOA.
If we are attempting to separate concern A from concern B, then we are seeking a design that provides that variations in A do not induce or require a corresponding change in B (and usually, the converse). If we manage to successfully separate those concerns, then we say that they are "decoupled", for obvious reasons. As a simple example, a car's side view mirror controls are decoupled from its accelerator, permitting us to adjust our mirrors without fear that the car will speed up or slow down.
In IT, in particular distributed systems, we often talk about the importance of the "separation of interface from implementation". Well, actually, we tend not to talk about it as much in recent years, since it seems to have become a law of the land; assumed desirable in the general case. Web services have certainly claimed to take it to heart with WSDL, the idea there being that clients implementations are authored to the platform/language/protocol/OS-independent description of the service, rather than to the service implementation. Definitely a good idea, of course. But does it really separate the concerns in the way we discussed above? Let's have a closer look ...
We can test WSDL's capacity to separate interface from implementation by asking the following question; can the implementation of a WSDL-described service vary arbitrarily without requiring a corresponding change in the interface? The answer is clearly no, as for any given WSDL document, it's quite trivial to identify a change in the implementation that would require a change in the interface. For example, if our interface included an operation for retrieving real time stock quotes - say, getRealtimeStockQuote() - then a change to an implementation of that operation to return delayed stock quotes would necessitate a change in the interface because clients would be assuming quotes were realtime, as that is what "getRealtimeStockQuote" would be documented to mean.
So, in fact, WSDL does *not* separate implementation from interface. Surprising, isn't it?
The billion dollar question then, is how *can* these concerns be separated? Obviously another kind of interface/service description language can't help us, since none of the reasons that the test above failed had anything to do with any specific feature of WSDL; CORBA's IDL would have faired just as badly, as would DCOM, Java RMI, etc. No, we need to look higher up in the stack.
We observed in the stock quote example above, that getRealtimeStockQuote() couldn't be used as part of an interface to both a realtime and delayed stock quote service implementation. The reason was simply that the operation is specific to realtime quotes. Had the operation been a more *general* one like getStockQuote(), then it could have accomodated that change in implementation by representing the *type* of stock quote in the data that is returned. And from this we learn a very important lesson; the more generic the operation, the more the concerns of interface and implementation are separated, and the more decoupled the message sender and receiver become.
But how far can we go with this generalization exercise? How much loose coupling can we hope to gain? Well, if getStockQuote() is more general than getRealtimeStockQuote(), wouldn't a simple get() operation be more general still, even *maximally* general; that such an operation would be implementable by any service which provided data to clients that asked for it?
The Web provides us such an operation (HTTP GET), and it has indeed been implemented by an extremely large and diverse set of services over the past 15 years. The sooner we as an industry collectively realize this, the sooner we can all get to work on building out the Web as the embodiment of the SOA vision.
About the author
Mark Baker is well-known in the SOA and Web services community because of his continuous efforts to promote an architectural style called REST (REpresentational State Transfer), criticizing many of the standards and specifications as being ignorant of what made and continues to make the Web successful.