SOA Elephants and Semantic Coupling

Rockford Lhotka raises some interesting points in the article. It basically boils down to the following points.

SOA is headed for Gartners curve of disillusionment. This is inevitable, not because of any intrinsic property of SOA, but because all significant tech in the last 20 years has followed this curve. Fair enough, there's a lot of hot air out there which needs to deflate. Also, people are building much more interesting systems today using SOA. Some of these will succeed and some will fail and that's going to help better define what are suitable problems, solutions, methods and limitations to SOA.

Don't use synchronous services. There's too much overhead. No arguments there. Asynchronous Document-Oriented Services (ADOS) is the sweet-spot of SOA. It has lower overheads and promotes a degree of looser coupling (as the connection-level) and allows a more efficient use of network, transactional and clustering resources. This is such an accepted use-case, that it is the primary use-case of WSDL 2.0. MS, WS-RM, HTTP, RSS can all be used to perform ADOS. The transport is not important, it's the style of interaction that matters. If you are serious about building a scalable SOA application, use ADOS.

SOA / WS solves the syntactic coupling part (Schema and WSDL) but not the Semantic Coupling. What is this? From the post:

Semantic coupling refers to the behavioral dependencies between components or services actual meaning to the interaction between a consumer and a service.

Every service implements some tangible behavior. A consumer calls the service, thus becoming coupled to that service, at both a syntactic and semantic level. At the syntactic level, the consumer must use the address, binding and contract defined by the service – all of which are forms of coupling. But the consumer also expects some specific behavior from the service – which is a form of semantic coupling. And this is where things get very complex. The broader the expected behavior, the tighter the coupling.

So building anything other than fine-grained atomized services (such as adding a number or pre-authorizing a credit-card) are doomed to failure because of semantic-coupling. That is really weird, cos I could have sworn I bought some books on Amazon yesterday. Surely they have systems that are semantically coupled? Do they know something we don't?

Any systems that are linked together as part of a broader workflow involves semantic-coupling as defined above, but so what? We have been building these systems for some time. Sure there are issues about building such systems, but the need is there, so we'll build them anyway. Many, many issues are in their infancy, such as service versioning. That doesn't mean solutions don't exist, there just isn't a well accepted standard for them yet.

Furthermore it is possible to partly describe the semantic coupling between two systems in terms of the expected sequences of messages exchanged between the two systems and their associated timeouts. This is a type of functional testing and is part of the best-practice in building SOA (see this article for more about SOA testing).