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.
Back to top
|