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:
