7 Degrees of SOA Coupling
“Complete decoupling is incredibly difficult and expensive, if not impossible,” says Ron Schmelzer, senior analyst from the SOA analyst firm ZapThink. In this recent posting, Schmelzer tackles the belief that a system is either loosely-coupled, or it isn’t. Although the importance of loose-coupling has been known for some time, the dialogue around this post has garnered some interesting discussion.
The 7 dimensions of loose-coupling Schmelzer describes include:
- Service Contract
- Service Policy
- Data Schema
- Semantic Layer
The report has this to say about Implementation Loose-Coupling:
All SOA implementations must be at least loosely coupled at the implementation level, but clearly this is not enough to guarantee the sort of complete loose coupling so desired by the business.
The Service Contract mentions the advantages in using the Service Description Framework:
The Service Description Framework (SDF) … is one of those technology-neutral Service contract templates. In those approaches, new Service contracts don’t simply replace old ones. Old contracts are never deprecated unless a transition path is provided for Service consumers.
The issue of late-binding is brought up as well:
[Probably] the best practice in this arena is the use of late-binding approaches that leverage run-time registries and contract-based binding to abstract the binding specifics of Service consumers and keep Service contract changes from propagating.
Until we have resolved the issues of seamless interoperability across web service stacks (primarily arising from the XML to Object databinding issues), run time binding to services by consumers which involve the generation and implementation of dynamic client side proxies is nothing more than a VisionQuest! The only run-time approach that will work in the current environment that DOES “leverage run-time registries and contract-based binding” is limited to dynamic binding to different SOAP endpoint’s (which could come from a run-time lookup against a registry) if and only if a priori interoperability testing has been done between potential producer and consumer web service code.
The report ties Service Policy to Service Contract as follows:
Companies looking to address Service variability should handle changes to policy the same way they handle changes to Service contract: late-binding, Service intermediary-enabled, registry-based, and governed.
Business Process is handled similarly:
By defining processes in metadata and exposing those processes using Service contracts (the recursive vision of process compose of Service and exposed as Service) abstracts the implementation of the process from the Service consumer.
Data Schema is first described as being handled differently:
Schemas are key to Service data interoperability. However, what happens when Schemas change? One key approach is to address information and schema management in the same way you approach Service metadata management. Data schema can be treated as a form of metadata and the use of exception management, transformations, Service intermediaries, and Data Services are all key to enabling loose coupling of data structure.
Yet is then tied back in to Service Contracts - “Schema are no different than Service contracts”.
The report states that while loose-coupling from an Infrastructure perspective may be easy to define, few vendors deliver on this kind of flexibility:
[This] means that at any time, the company can change their infrastructure without having to rebuild all the Service consumers and providers.
The ultimate solution is described at the Semantic level - dynamic service definitions where ” the definition of the Service interface must change based on the context of the Service requester. As a result, a Service can change its contract between invocations”. This loosening of syntax seems like it would work well with the REST model, however its incorporation into the WS standards remains unknown at this time.
This list leaves out the most important aspect of loose coupling: ubiquity. If I and only one other partner adopt the world’s most dynamically reconfigurable middleware architecture then he and I are tightly bound to one another. Imagine the two of us dreamed up our own custom variation of WS-*; let’s call it WS-Silo. Then between the two of us, we could do all sorts of nifty changes on one side to the interface without disrupting the other side; but we can’t interoperate with ANYONE else.
While there may not be broad agreement on the specifics of how loose-coupling is to be achieved, its goal does seem to remain squarely in the consensus - decrease the cost of changing systems by changing them independently of each other.
In SOA each service has a role or genre. For example, if you have services of the Harvest genre (as described by the e-Framework) you know you may not be able to change the data schema of others services without consequences for your consumers.
This is what makes SOA hard. As far as I understand these rules don't address this kind of issues.