SOA, Separation of concerns and agnosticism (4/5)

Separation of concerns and interoperability

Because the contract must be interoperable we need to define contracts in a technology that is interoperable and preferably vendor-neutral by nature.

We also need to make sure that both the message protocol as well as the transport protocol are standardized as much as possible. Ie. in case we use a message protocol that cannot be supported on a specific platform or a transport which is not supported by all required platforms, this poses us with a significant interoperability challenge. Sometimes both message and transport are coupled (ie. REST), sometimes decoupled (ie. SOAP where the message protocol remains SOAP but the transport protocol can change from ie. HTTP to JMS).

For this interoperability challenge to be resolved we can choose a technology that allows for cross-platform interoperability, like SOAP, REST or plain XML over HTTP. As you can see the standards used in this paragraph are all industry standards. Industry standards are standards that agreed on and have large industry support. As an example, at the time of writing, SOAP 1.1 has more industry support than SOAP 2.0, so although SOAP 2.0 has some improvements over SOAP 1.1, personally still I would prefer the older standard.

Choosing industry standards for the technical contract, the chances of interoperability increase, as multiple different types of platforms would most likely be compatible, despite the platforms being disparate systems.

As a side note, if technology like SOAP is used, the contract can easily be designed first because WSDL (yes another industry standard) can be used to describe the contract in a standardized way (from technology point of view). This would help creating a (separately governed) contract that can be used by both the service designer as well as the service consumer designer to allow for concurrent design and delivery of both service as well as its consumer.