The Importance of Mediation in a Services Network
As an SOA matures and expands, incompatibilities inevitably will emerge that must be managed to achieve your goals.
by Frank Martinez

October 21, 2005

This article is the fifth in my series on services networking. In previous articles (see Resources), I have advanced services networking as the best architectural approach to SOA because it is more scalable, stable, and uniform than alternative architectures. Solutions such as certain SOA Fabrics help enterprises create services networks. Such solutions consist of message-aware intermediaries and federated registries. Message-aware intermediaries are deployed throughout the SOA and route messages from consumers to providers while functioning as distributed policy enforcement points. They guarantee adherence to vital policies and encourage enterprise-wide service sharing and reuse. Federated registries act as the system of record for all metadata required for services network governance, lifecycle, operations, and policy management.

In this article, you'll learn how policies are enforced or implemented by shared in-network intermediaries—rather than at each individual endpoint—enabling communication between diverse endpoints via the creation of an "intelligent" services network.

Dispelling the "Utopian SOA" Myth
Standards, such as SOAP and WSDL, lie at the foundation of Web services and SOA. In the utopian vision of SOA, uniform adoption of these standards—augmented by additional WS-* specifications such as WS-Policy, WS-Security, WS-Addressing, and WS-ReliableMessaging—promises to enable enterprises to leverage the ubiquitous Internet as a reliable, secure enterprise messaging backbone, linking services together to form new business processes and applications capable of supporting a broad spectrum of business needs.

In this utopian vision, these standards and specifications mysteriously align, making consumption of any given service prescriptive; in other words, service behavior for any and all possible consumption scenarios is prescribed in advance. In this vision, there is collective, worldwide (or at least enterprise-wide) standards agreement—everyone will work off of the same profiles of the same versions of the same standards and specifications—and we shall thereafter halt the clock and stop the world from spinning.

Sarcasm aside, there are clear realities that impinge upon this utopian ideal, and these realities must be addressed to have a successful SOA. Standards evolve over time, moving through different phases of maturity, ultimately gaining adoption within commercial products and enterprise infrastructures. I should note that a significant number of today's technology standards, including most of those in the Web services domain, are actually "specifications" and in reality you can't say that these specifications are frozen across time and space. This means even something as broadly supported as WS-Security will still undergo modifications before it is adopted as a standard or becomes a de facto standard through broad acceptance and wide-scale implementation as a stable specification. (Note: At the time of publication, there were three versions of the WS-Security specification in use.) Even SOAP has been revised several times (versions 1.1 and 1.2 are currently in use).

As each version of a Web services platform is released, it incorporates support for one of the more recent versions of a variety of standards and specifications. Because the "latest" version of a specification is relative and changes over time (as well as the breadth of supported specifications, which usually increases with each platform release), it inevitably follows that Web services built in one version of a platform will support different standards and specifications than those built using the subsequent version of the platform.

This results in impedance mismatches that can potentially obstruct communication among services in the SOA. This problem is significant—in any enterprise of any size, there are multiple versions of multiple platforms in place at the same time (such as IBM, SAP, Microsoft), leading to countless combinations of standards and specifications.

The solution to this prescriptive approach problem is to govern runtime interactions among services declaratively—service behavior for various consumption scenarios is declared after the fact and enforced flexibly at run time through pervasive mediation, rather than only through explicit prescription during service creation and interface publishing. Declarative SOA embraces the inevitability of impedances, enabling context-specific flexibility via declaratively stated policies that are enforced in the network (depending on the consumption scenario).

This is how the SOA infrastructure can, in effect, provide a manifestation of Postel's Law: Be liberal in what you accept, and conservative in what you send. The SOA can be "liberal" in what is accepted, thereby exponentially magnifying the reach, ubiquity, and business value of these shared services rather than limiting their utility and relevance by constraining their consumption through strict adherence to arbitrary, prescriptive guidelines.

Standards incompatibilities represent only one type of emerging incompatibility among services. Others include incompatibilities between messaging protocols (HTTP vs. FTP vs. JMS) and incompatibilities in message exchange patterns (a synchronous client trying to consume an asynchronous service). Taken together, it becomes clear that there are multiple, inevitable incompatibilities that must be arbitrated for an SOA to function.

Use the Services Network
Should you wait until all standards are "finished" (a highly unlikely state)? Should you dictate "standards support" for your enterprise (a very difficult, unpopular position)? Should you give up and dust off your books on CORBA?

Once again, the services network comes to the rescue. Recall that a services network is premised on the concept of pervasive intermediation: All messages run through the network before they reach the ultimate service provider. Previously, I discussed how services network intermediaries can implement policies that govern these interactions, but that's not all. Services network intermediaries also can mediate incompatibilities among standards, message protocols, and message exchange patterns that threaten the success of the SOA. This mediation enables the network itself to broker communication reliably between previously incompatible services.

Ultimately, the role of the services network is to isolate all consuming applications from change, allowing services to change as required or desired, without also requiring lock-step changes to each dependent, consuming application. You can choose from three types of mediation: standards mediation, protocol mediation, and message exchange pattern mediation.

It is important to be able to support and take advantage of standards throughout their entire evolution (see Figure 1), largely because waiting for them to stop evolving is an untenable position (in other words, they never stop evolving). So, services network intermediaries should provide out-of-the-box support for envelope and header modifications designed to arbitrate between different supported versions of any standard or specification.

For example, if a consumer is designed to send a SOAP 1.1-formatted message and the ultimate service provider is expecting raw XML, the intermediary should be capable of stripping away the SOAP envelope and passing the raw XML message to the legacy service. Similarly, modifications to individual headers (such as different versions of WS-Addressing) should be facilitated. Leading services networks solutions provide for multiple standards mediation scenarios.

Protocol mediation (see Figure 2) is an intermediation-based approach that also provides the means to easily bridge between messaging protocols. The purist view of SOA holds that all communication takes place over Internet-standard protocols such as HTTP. In reality, any enterprise with existing services projects (or integration projects leveraging services) will utilize a variety of ESB or MOM backbones. Many of these will be JMS-based rather than HTTP-based. These services should be shared across the broader network, thereby increasing their value to the enterprise. Leading services networking solutions offer protocol mediation in the network, thereby enabling the binding of a message sent over HTTP to a JMS queue or topic and vice versa.

It is inevitable that message exchange pattern incompatibilities will emerge in any SOA, so message exchange pattern mediation would come into play (see Figure 3). This means there will be services that expect to communicate synchronously as well as those that expect to communicate asynchronously. Without network intermediation, these services would be unable to couple. Leading services networking solutions bridge these incompatibilities, however, effectively breaking the consumer-provider communication into two distinct communications—consumer-to-intermediary and intermediary-to-provider—with the intermediary capable of both synchronous and asynchronous behavior.

Throughout this series on SOA I've introduced the concept of a services network, described how to build one properly within your enterprise, discussed the importance of governance and standards to the success of your SOA, and outlined how to use services network intermediaries to arbitrate incompatibilities and to provide reliable messaging to the standards-based SOA. Rolled together, the ideas I've outlined will help you get the most out of SOA.

About the Author
Frank Martinez is the CTO, chairman, and cofounder of Blue Titan Software, a provider of service-oriented infrastructure that helps enterprise architects control, share, and scale applications, driving business innovation across the distributed enterprise.