JAN 18, 2008 4:16pm ET

Related Links

New Product News – September 6, 2013
September 6, 2013
IBM to Buy Green Hat
January 4, 2012
Is BOA the New SOA?
December 8, 2011

Web Seminars

The Real Cost of “Chat Now” for Your Business
July 29, 2014
Improve Omni-channel Shopping Experience with Product Information Management
August 21, 2014

Achieving Loose Coupling in your Web Services Environment

Print
Reprints
Email

Loose coupling is perhaps the most important design goal of the service-oriented architecture (SOA) philosophy. Loosely coupled systems minimize dependencies between service entities thus leading to more flexible solutions that have the ability to evolve seamlessly alongside ever-changing business requirements. By opposition, brittle connections in your services prevent component reuse.

 

Software developers appreciate clear requirements. Coding against a frozen interface or WSDL is efficient and convenient. On the other hand, a loosely coupled system requires flexibility in terms of the network location and the protocol used by the target implementation. Given this requirement, one might conclude that the frozen interface is a luxury that developers should renounce in the name of loose coupling. Developers would instead write complex software that magically finds the right network target and adapts to the particularities of the implementation at runtime. In a Web services environment where requesters and services are scattered across the network, replicating this type of mechanism to each entity would be ludicrous.

 

A more efficient approach consists of managing connections between your Web services entities independently of the actual service implementations. These connections typically reflect business processes and architectural decisions that should be the concern of administrators rather than software developers. Furthermore, it is more powerful to unify such bindings and decision-making in a central location thus enabling the definition of homogenous binding rules covering multiple services.

 

XML Appliances

 

XML appliances facilitates many aspects of your SOA. You can use them to delegate complex security requirements; you can use them to accelerate common and expensive XML-related tasks such as schema validation and transformations. More important to the topic at hand, you can use XML appliances as gateways binding services with requesters based on customizable rules. XML appliances are particularly powerful intermediaries in your SOA because of their ability to be content aware. While handling XML-based traffic, the XML appliance will apply rules using the numerous XML-based standards. For example, using WSDLs, XML appliances understand what services are being invoked. Other XML-based standards typically used by XML appliances to help define and enforce policies include XPath, XSLT, XSD, WS-Security, WS-Trust.

 

An XML appliance deployed as a policy enforcement point will allow an administrator to define rules that govern the conditions under which services are consumed. Those rules are created using a graphical user interface. Modifications and additions of these rules are applicable in real time without any service interruption and without the underlying services being aware of them.

 

In the following examples, we’ll see how you can take advantage of an XML appliance to manage loose coupling in your Web services environment.

 

Content Based Routing

 

Traditional gateways and routers are not content aware. Because of this, content-aware decision-making is typically dismissed as business logic and must therefore be left to the service implementation to handle. However, as the network traffic for enterprise software is increasingly becoming XML-based, architects recognize the power of leveraging content-aware appliances to apply policies and enable loose coupling.

 

To illustrate this point, imagine an asset-tracking service relying on the fictional WSLoc standard. An enterprise service is connecting to different external providers to track its assets. An outgoing request would look like:

 

acme delivery inc

ASDF-1234

 

Our enterprise architect understands the fact that the partnering providers evolve over time. Instead of coding in all the different targets for the WSLoc implementations in each of the requesting services, these requests are forwarded through an XML appliance which applies routing rules defined by the administrator. As part of the routing policy, the administrator of the XML appliance will use a simple XPath expression to select the provider:

 

/s:Envelope/s:Body/wloc:getPosition/wloc:provider

 

The result of this expression would then be used to select the appropriate target URL, again as part of the routing policy rules. Doing business with new delivery companies becomes as simple as the administrator updating the rules in the XML appliance to handle a new provider name. There is no service interruption involved and no software development. Content-based routing is the most popular loose coupling related pattern used by service-oriented architects. Routing rules based on such patterns allow the administrator to choose endpoints based on any aspect of a message. A well-known example of this mechanism is the subject of the WS-Addressing specification in which SOAP nodes rely on predefined SOAP headers to deduct a binding target.

 

Transport Mapping

 

The same XML appliance can further be leveraged for mapping between transport mechanisms. Given the same fictional use case described earlier, let’s imagine that a new partnering provider implements the WSLoc standard but exposes a JMS binding. Until now, the requesting services only had to deal with HTTP endpoints. Should each of these requesting services be enhanced to support whatever flavor of JMS is used by this new partner? Of course, the XML appliance will simply take this into account in the routing rules. The incoming message can be dropped on the queue and the XML appliance can further be instructed to wait for a response on a matching queue, effectively providing an HTTP to JMS transport mapping for the enterprise services.

 

Typical XML appliances support HTTP/S, several flavors of JMS such as IBM and TIBCO, FTP, etc. But more importantly, the XML appliance will allow you to define rules that bridge those different transports between requesters and services.

 

Examples of mapping of transport mechanisms:

JMS to HTTP

HTTP to JMS

FTP to JMS

JMS to FTP

FTP to HTTP

HTTP to FTP

 

Service Virtualization

 

A few months down the road, the WSLoc standard evolves to version 1.1. Although new operations are added, none are important to our enterprise services, which only uses the getPosition operation. Furthermore, the getPosition operation does not change beyond the namespace. The delivery partners are not planning to upgrade anytime soon, but a new partner only uses this most recent version of WSLoc.

 

Get access to this article and thousands more...

All Information Management articles are archived after 7 days. REGISTER NOW for unlimited access to all recently archived articles, as well as thousands of searchable stories. Registered Members also gain access to:

  • Full access to information-management.com including all searchable archived content
  • Exclusive E-Newsletters delivering the latest headlines to your inbox
  • Access to White Papers, Web Seminars, and Blog Discussions
  • Discounts to upcoming conferences & events
  • Uninterrupted access to all sponsored content, and MORE!

Already Registered?

Filed under:
SOA

Advertisement

Twitter
Facebook
LinkedIn
Login  |  My Account  |  White Papers  |  Web Seminars  |  Events |  Newsletters |  eBooks
FOLLOW US
Please note you must now log in with your email address and password.