Applied SOA: Part 5 – Interoperability

This is part of a series of blog post about Applied SOA. The past blog entries are:

• Introduction
• SOA Basics
• Service Discovery Process
• Service Taxonomy

In this article, I’ll cover the Interoperability.  SOA aims is to expose capabilities through services in order to let different agents leverage those capabilities.  A common theme is therefore interoperability.  Given the universal reach of services (as opposed to objects or components for instance), the interoperability bar tends to be quite high.

Technical Interoperability

Now the first thing that pops into technologists’ mind when interoperability is mentioned is technical interoperability:  the ability for two systems to communicate with each other despite their underlying technological stack differences.  This is no small challenges.

Indeed, we would think that with SOAP & WS-*, all those interoperability problems are behind us, all taken care of by standardisation bodies, right?  Well, not quite.  Although those standards enable basic interoperability in an unprecedented way, they still do not guarantee it.  The center of the problem is the way SOAP specs can be interpreted and how differently it was interpreted by different vendors.

As a result, it isn’t trivial to achieve interoperability between heterogeneous systems.  For instance, Microsoft published four months ago a package of bindings to use with different vendors.

Two opposing forces are at play when we consider technical interoperability:

• The richness of the protocol used in the services
• How interoperable we want it to be

For instance, consider the following list of Services protocol:

• WS-* (e.g. WS-Atomic, WS-Security, etc.)
• WS-I Basic Profile
• REST / OData
• SQL Views
• File share

As we go down the list, protocols get simpler and simpler.  The first ones allow rich scenarios (e.g. distributing a transaction, sharing a claims based security context, etc.) while the later ones do not.  The amount of potential clients grow as we go down though:  who  can’t drop a file on a file share?

Now once you’ve decided on how much interoperability you can afford given the protocol your solution needs, you have many tactics to make it happen.  For web services, this typically involves getting closer protocol standards and not letting your development platform do as much as it otherwise would.

Indeed, many web services platform offer a great story to quickly author web services by eliminating a lot of the gory details of SOAP.  Different development platform (e.g. .NET vs Java) takes different decisions on those details which make them incompatible though.  Pesky details such as field ordering, native types to SOAP types mapping, how list of objects are mapped to XML schema, etc. can all bring incompatibilities between a service and its consumers if written in different platforms.

All that being said, those problems are known and great guidelines exist.  For the .NET platform, an excellent tool for authoring interoperable web services is WSCF (Web Service Contract First) by thinktecture.  Those tools accelerate protocol-centric development instead of marking details.

The key here is to test with the different target platforms.  Quite similar to multi-web browser development really.

Business Interoperability

Another aspect of interoperability is business interoperability.  Let’s say we solved the technical interoperability problem and we have a great recipe to build web services interoperable with our target consumers but that we do not speak the same business language, how really interoperable are we?

An example I like to give concerns two hypothetical services within a consulting company (yeah, I love consulting company examples!).  The first service returns a list of employees who didn’t fill up their weekly timesheets while a second service sends email to an employee.  We could easily combine those two services in order to warn offenders they haven’t filled their timesheet yet, couldn’t we?  What if the first service signature looks something like this:

EmployeeData[] GetOffenders()

where the EmployeeData data contract has the following shape:

EmployeeData :
{
  EmployeeNumber : integer,
  FirstName : string,
  LastName : string
}

and the second service looks like this:

SendEmail(emailAddress : string, mailBody : string)

Well…  we got ourselves a typical data mismatch problem.  The first service identify employees by employee number while the second one expect their email address.

A simplistic example, but quite common one in large enterprises, especially ones where acquisitions created a patchwork of different semantics (e.g. here a project is something with a billing code and people staffed on it, there it’s an aggregation of teams with no budget semantics).

Again, this is a problem with solid existing solutions, but it is still something to be mindful of when elaborating a Service Oriented Architecture.  Two typical solutions to this problem are:

• Schema rationalisation (or Canonical Data Model, CDM) where services expose a canonical model where different entities only have one meaning and representation.
• Entity Aggregation (e.g. Master Data Management) where different semantics and representations are allowed to exist but a central authority performs reconciliation.

In conclusion, it is important to define what type of interoperability (both technical & business) we target and to take the necessary steps to achieve it given the challenges of the solution’s context.