email article
	printer friendly

Reliable Messaging in a Services Network
Intermediation-based, networking-centric approaches enable your SOA to support the most sophisticated enterprise applications.
by Frank Martinez

June 2, 2005

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.