In my part 3 we touched on three new guidelines that support improved interoperability, these were:
- Use asynchronous communication to avoid temporal coupling.
- Use pull based communication to avoid centralized decision making.
- Use names to support process interaction.
The use of names that (i.e. URIs) is what fundamentally distinguishes it from SOAP. All the quidelines of interoperability that I have described so far are not disallowed by SOAP. However, unlike REST that requires these characteristics, SOAP says nothing about them. This is unfortunate since architecture is about defining constraints. As Roy Fielding writes:
A software architecture is defined by a configuration of architectural elements–components, connectors, and data–constrained in their relationships in order to achieve a desired set of architectural properties.
The conspicous absence of constraints in SOAP, particularly those that support interoperability is a clear indication of the vacuous nature of the specification. The only constraint one can possibly derive from SOAP is its lack of support for the URI. REST has been described as having a few verbs and infinite nouns. By contrast SOAP is the opposite, a few nouns (however not fixed) and an infinite number of verbs. Can someone explain to their wives the SOAP definition?
SOAP revolves around an infinite (actually more like unbounded but countable) number of verbs. Therefore the solutions that arrive out of it would focus on how to manage these verbs. That is one could provide a commonly agreed upon taxonomy of verbs then that would a good step towards progress. Fortunately, that taxonomy already exists in speech acts, and the theory says that there are only a few verbs1 and every other derivation can be shown to be equivalent. SOAP adherents of course chose to ignore that research.
The definition of SOAP has always been a moving target, however SOAP adherents have finally settled down and drawn a line in the sand (more like painting themselves in a corner). The newest definition goes like this “SOAP defines a message structure (the SOAP envelope infoset), a set of rules for processing SOAP messages, and an extensibility framework.” How this all fits in supporting interoperability is explained by Mark Champion:
The interoperability gains come when one has to deal with multiple transports, encryption, authentication, security, transactions, binding to programming objects.
In effect, you have a proliferation of WS-* specifications, that incidentally are according to their theory is composable. That is a monumental effort is in progress to classify the space of infinite combination of verbs. What is a committee to do if all one can work with is verbs?
The idea of seamlessly composing “ilities” into a solution has been tackled in research of Aspect Oriented Programming (AOP). AOP provides an elegant solution to apply cross-cutting concerns in a modular fashion. However, what has clearly not been resolved is the ability to compose aspects themselves. Yes there are constructs for precedence rules in aspect application. However there’s no way to automagically determine if a combination of two aspects will work as intended. Unfortunately, the SOAP adherents are mired looking at XML protocols and ignoring the big picture. The fact is, nobody has shown effective aspect oriented composition.
If you can’t show composition, then how are all these WS-* specifications supposed to string themselves together? The only way to do that is to pre-wire them together. This make interoperability more difficult because now you need completeness to achieve it. To ask vendors to complete the stack especially when that stack continues to move is impractical and a coordination nightmare. It’s anyone’s guess when the parade of WS-* specs will end. It is now becoming clear that this isn’t a parade but it is more like a death march. A death march that anyone with a half a brain shouldn’t even consider participating in.
I’ve begun this series by emphasizing “Interoperability, Interoperability, Interoperability”. SOAP adherents on the otherhand would have you believe that interoperability is achieved by adapting a composable set of standard protocols. Unfortunately its more like a lock-in strategy, because one would have to select from a prewired set of protocols. Vendors that do not support an equivalent set of protocols and aren’t wired the same way would be incompatible.
Pragamatic interoperability is achieved by selecting appropriate constructs that support loosely coupled development. Standards (i.e. abstract interfaces) are just one aspect of creating loosely coupled components, however there are other aspects. I’ve created a more comprehensive table that you could use to evaluate the interoperability of your design. The table shows dimensions that are not covered by REST. REST by itself is not completely devoid of problems, nevertheless as I have shown, it provides a firm foundation for building interoperable systems.
I was supposed to talk about messaging layers, however I needed to get the above post out of my chest. In a subsequent piece I will also talk about the trampoline nature of REST.
1. Does a taxonomy of nouns make sense? Although you can create classifications every thing has a distinct identity separate from its classification. Verbs by contrast don’t have identity independent of their “direct objects”.