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.

 

Again, the software development team could hack away at the existing requesting service implementations to simultaneously support both versions of the WSDL and use them interchangeably, depending on the external target. However, this type of loose coupling problem can be reduced to a transformation task, which is easily handled by the XML appliance.

 

Since the getPosition operation has not changed, the administrator of the XML appliance simply has to insert a new XSLT stylesheet to transform outgoing requests and incoming responses to use the new namespace when communicating with the new delivery partner using this new version of WSLoc. Once again, this is a simple update which did not affect our existing services and avoided the need for any service interruption.

 

The same stylesheet will be reused if and when the other partners decide to upgrade their WSLoc implementation. Moreover, if the development team decides to upgrade the enterprise services, the XML appliance will simply not care. The rules set by the administrator are defined so that the transformation only occurs if deemed necessary as per the inspection of the incoming request. A basic XPath expression will take care of testing this.

 

The concept of service virtualization can be pushed further. The XML appliance can transform incoming WSLoc compliant messages into a completely different format, provided all the necessary information is present. This would be used when overlapping standards are used or when a participant uses a proprietary format.

 

Late Binding Using External Decision Points

 

A routing rule need not involve hardcoded static URLs. Imagine the case where an XML appliance receives a Web service call for a completely unknown service. Typically, the XML appliance policy would dictate to refuse the incoming message and return an error. You could instead instruct the XML appliance to discover the unknown service using the corporate UDDI registry. A UDDI registry service is a Web service that manages information about service providers, service implementations and service metadata. Service providers can use UDDI to advertise the services they offer. Service consumers can use UDDI to discover services that suit their requirements and to obtain the service metadata needed to consume those services. At runtime, the XML appliance would discover the service using the UDDI protocol and deduct the target where the message should be routed to.

 

Querying a UDDI directory to bind requester and service is just one example of relying on an external decision point. Another such example is the proprietary infrastructure that you typically find in big corporations. UDDI, LDAP and other standard-based directories will interoperate with the XML appliance out of the box. However, proprietary systems will not. In order to provide loose coupling involving these corporate proprietary decision points, the XML appliance must provide an api that allows the user to programatically plugin support right into the routing rules.

 

Identity-Based Routing

 

Whenever an XML appliance is involved in the authentication of requesters, and it often is, the identity of the requester can be used as part of the enforced policies. Although identity is commonly thought of as pertaining to authorization or access control, it often plays a role in routing rules. The cliche example for this is when a particular service has different implementations for different groups of users reflecting their subscription levels.

 

In the context of our example, a partner company might have two different instances of their WSLoc service. One version would be publicly accessible and another would be reserved for partners. One could imagine that there exists a service level agreement (SLA) between the requesting enterprise and this delivery partner where the WSLoc implementation must respond within a predefined latency and provide high availability. This in turn translates into a more expensive deployment, which would be reserved for such requesters who have a contract with the company.

 

Assuming that this partner uses its own XML appliance for authentication, the routing policy would only route to the high-availability version of the service for requesters who have provided credentials that are associated with a partner account.

 

Perhaps the WSLoc implementation is initially only anonymously accessible but over time the need arise for a paying high availability version of the service. This type of changing requirement is accommodated without having to change the WSLoc implementation. A new instance of the same service is simply deployed in a high-availability environment with the necessary redundancy.

 

Rules controlling the binding between services and requesters can be based on many factors not presented here. For example, you could instruct an XML appliance to choose a target based on time of day, the address of the requester and some predefined quota.

 

By abstracting this logic out of your actual service implementation and relying on infrastructure for enforcing binding and transformation rules, you gain the benefit of centralizing your policy management and enforcement; you gain a higher flexibility where changes are applied without need for costly software updates and service interruptions.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access