Abstraction Cocktail

06 Feb 2009

I was reading about that quite rarely. But it has spread like epidemic lately. I can see it now in almost any text about SOA, WOA, REST or SOAP. I'm talking about a phenomenon that I call the fallacy of mixing abstraction layers.

Have you ever heard proposition that if we all implemented SOAP then we all can communicate without problems? Such proposition is only partially true. And it is altogether false when talking about the business services layer of architecture. Why is that?

SOAP is just another network protocol. In OSI model it would belong somewhere to presentation layer. Because SOAP is just a protocol, it does not assign any business meaning to individual operations or arguments. It can define that an argument is a floating-point number. It can even define that the argument is named "balance". But is it balance of checking account? Or of some other financial product? Or is it a subjective value of balance of good and evil in the world? And even if could somehow figure out that it is a balance of checking account, many questions still remain: what is the precision and rounding rules? Can it be negative? Are there any upper and lower bounds? And even if that can be answered, then we get to the problems with operation using that argument: what are the consistency guarantees of the operation, what is the synchronicity? Are there any parallelism limitations? Side effects? Undefined states?

Expecting that SOAP will guarantee application interoperability is almost the same like expecting that IP will guarantee that. If IP could do that, then all interoperability problems would have been solved few decades ago. SOAP is closer to the application (on higher level of abstraction), but it is still not the application itself. Application is using SOAP and we must make sure that applications will use SOAP in interoperable ways. This is in no way specific to SOAP. RESTful services and other low-formality mechanisms exhibit even more interoperability problems, as they lack sufficiently widespread means of schema definition.

Only a good definition of interface on the appropriate layer of abstraction can guarantee interoperability of applications. The appropriate layer is in most cases application layer of OSI reference model (not the application layer of TCP/IP reference model which is in fact just a catch-all layer). The interface should define entities and concepts that are meaningful from business perspective and not only some XML tags and types. The interface definition should include also definition of bindings: it should define how the business concepts are translated to SOAP (or RESTful service), that SOAP in this particular case is using HTTP binding and so on.

The usual rules apply: Architecture first, technologies second. There is no panacea, no magic solution for interoperability. The sooner the people realize that, the sooner will the SOA/SOAP/WOA/REST hype be over.