Reliable Messaging in a Services Network

In previous articles, I advocated the deployment of network-centric service-oriented architecture (SOA) infrastructure solutions to enable reliable, consistent, and predictable communication between Web services deployed across a distributed enterprise. These solutions come with policy frameworks designed to deliver metadata-driven SOA governance. These frameworks consist of message intermediaries deployed throughout the SOA that function as distributed policy enforcement points, guaranteeing adherence to vital policies and encouraging enterprise-wide service sharing and reuse, combined with a federated registry acting as the system of record for all service metadata required for governance.

Services networking is the best approach to an SOA governance framework because it is more scalable, stable, and uniform than alternative architectures. The message intermediaries in a services network are SOAP routers, and the moment when a router intermediates, a message provides an optimal point to uniformly govern all interactions with and between services. So policies are enforced or implemented in the networkrather than at each individual endpointenabling communication between diverse endpoints through the creation of an "intelligent" services network.

The Two Core Problems
To support the most sophisticated enterprise applications, the services network must solve two core problems:

Enterprise incompatibility. An enterprise IT landscape is composed of countless incompatibilities: incompatibilities in platform selection, standards use, service sophistication, invocation pattern, developer skillset, and so on, all of which must be mitigated to enable seamless service sharing in the enterprise. Service sharing through loose coupling lies at the foundation of the benefits of SOA, enabling business agility, lowering IT cost, and reducing time to market for new applications. These incompatibilities create impedances to service sharing, and therefore must be removed for enterprise SOA to achieve its goals.

Management of countless nonfunctional application aspects. As SOA changes the IT landscape, transforming it from a few, large applications to a network of many shared services, nonfunctional aspects become unmanageable, particularly when nonfunctional requirements can vary at run time depending on the consuming application. Although nonfunctional aspects cover a wide range of capabilities (security and logging, for example), I'll focus on reliability (specifically message reliability) and ubiquity (specifically message backbone ubiquity).

Enterprise SOAs need a messaging backbone that is both ubiquitous and reliable if they are to support the most essential business applications. Internet-standard protocols (HTTP, FTP, and SMTP) provide ubiquitythey already reach every corner of any enterprisebut they lack reliability and native support for sophisticated message exchange patterns (MEPs).

Conversely, proprietary MOMs or MOM-based ESBs provide reliable messaging and support for a broad range of MEPs, but they lack the ubiquity, simplicity, and composability that standards-based protocols offer. Also, due to a mindset couched in traditional integration (a mindset shared by vendors as well as many architects), the use of ESBs and MOM tools often add additional barriers to interoperability rather than removing them, as they can encourage tight coupling within the context of a specific integration project.

The Services Network Solution
One goal of a services network is to solve these two problemsflexibly enforcing nonfunctional application aspects (specifically ubiquitous reliable messaging) while eliminating as many incompatibilities as possible.

Taking a services networking approach to SOA can solve both of these problems: You can mediate incompatibilities and manage nonfunctional aspects.

Regarding the first problem, services networks are premised on network intermediation. This intermediation provides a juncture where you can mediate away many of the incompatibilities I described, extending the reach, applicability, and interoperability of the SOA. Services networks are built around a network of SOAP routers that intermediate messages passing between services in the SOA, enabling the network itself to reliably broker communication between previously incompatible services. This intermediation-based approach also provides the means to easily bridge messages to existing JMS solutions, freeing services that had been tightly coupled to existing integration projects, thereby unlocking their value for reuse by the enterprise.

As for the second problem, a sophisticated services network can provide message reliability guarantees, combining ubiquity and reliability into a shared, uniform messaging backbone, comprehensive enough to support the most demanding, business-critical SOAs. This is done through a combination of embedding durable queuing into the services network (guaranteeing the delivery of all service messages) and support for the emerging WS-ReliableMessaging specification.

This is the fourth article in my services networks series for Enterprise Architect. I've introduced the concept of a services network, described how to properly build one within your enterprise, discussed the importance of governance to the success of your SOA, and outlined using a services network to mediate away service incompatibilities and provide reliable messaging to the SOA.

Remember these key points:

Services networking is a unique approach to SOA, providing a scalable solution designed to enable reliable, consistent, and predictable communication between Web services deployed across a distributed enterprise.

A services network is held together by a distributed router network, composed of linked SOAP routers that intermediate and route all communication and enable the SOA to scale globally.

The services network provides for optimal SOA governance, which becomes increasingly important as SOAs scale, affording the enterprise to reap the global benefits of services sharing and reuse.

The services network can efficiently arbitrate between services that have inherent incompatibilities. And a services network can guarantee message reliability in support of enterprise applications that require that level of sophistication.