SOA Tight Coupling

Service Oriented Architecture is a name for modeling an automated process as a set of services. This approach pushes back against the usual IT pattern of defining a central database that various programs interface with. SOA solves some problems, but I have found that it doesn't go far enough.

The problem with the monolithic central database pattern of traditional IT is one of dependency. All of the applications that interface with the central database come to depend upon its schema. And in order for them to communicate with each other, their schema dependencies must overlap. This makes it difficult to modify one application without breaking the others. As a result, the applications not only become too dependent upon the database, they also become too dependent upon each other.

The SOA solution to this is to integrate applications through contracts instead of through databases. Each application, or service as it is now called, defines a set of requests that it can process, and the schema for those requests. Services house their own databases, so that internal schema can change without affecting any other services.

This is an improvement, but I have found that it is not enough. In practice, SOA still leads to tight coupling. This happens in two ways.

First, a service -- a logical concept -- becomes tightly coupled to machines -- a physical concept. The service must be installed on a server or set of servers, and its database must be housed within that farm. Clients of the service are configured to send requests to that machine or farm. It is difficult to move a service to new hardware, or to start a second instance of a service within the organization.

Second, service contracts get tightly coupled to their implementations. Most contracts in practice are not negotiated among a group of service providers and clients. Instead, each contract is dictated by the service provider. In some implementation technologies, such as WSDL, a client must contact the service to discover the contract. And even when the contract was negotiated, as was ISO-8583 for financial exchange, it is often implemented inconsistently from one service provider to the next. The end result is that the client must know the particular service provider it is using instead of a general purpose contract.

Here's my solution
At the day job, we have a number of third-party integration solutions where we play the role of service provider. We reduce coupling by moving the integration point away from the network. Instead, we publish client-side APIs that talk to our servers. We use language constructs such as interfaces to define contracts. Language-based interfaces tend to be less fragile than protocol-based contracts because we have compiler validation.

We have to write a client implementation for each technology that is expected to use the service (e.g. both Java and .NET). But this is more than offset by the time saved by the consumer of the service. It is much easier for one party to ensure interoperability on both sides of the protocol. Just look at how easily a .NET web service client talks to a .NET web service, as compared to bridging .NET and Java.

If more than one service provider implements the interface, then the client can quickly swap one service for another. In fact, this switch can be made at run time, where some requests are sent to one provider and others to another provider.

This is only a partial solution, however. Our service is still tightly coupled to our datacenter. It would not be easy to move or split the data. But if we needed to, at least those concerns will be neatly hidden away behind a client-side interface.

Leave a Reply

You must be logged in to post a comment.