The Web Services Mediator
The Web Services Mediator (WSM) is a middleware layer that allows an application to be written once, and later utilize any Web Service without expensive application re-writes. What does this mean for applications such as the taxi portal we discussed earlier? Among other benefits, the taxi portal would automatically scale to support new taxi Web Services as they became available without having to modify the application to invoke methods of additional client proxy objects. The portal application would also be fault tolerant to taxi Web Services that become unavailable - either temporarily or permanently - and would not inefficiently use the proxy objects of these unavailable Web Services.
In order for an application to use any Web Service, a WSM application is built around a contract that defines the communications between the application and the WSM. The WSM can then be instructed to map those communications to any Web Service, with the WSM handling all necessary transformations between the original application contract and the selected Web Service. Target Web Services can be specified to the WSM directly, or characteristics (e.g., lowest cost, QoS measures) can be specified from which the WSM selects the best fit Web Service from a registry.
Figure 2: Architecture of an application accessing Web Services through the Web Services Mediator (WSM). Applications use an STG client proxy that allows access to the services of all Web Services within that STG. Patterns are models that map communications between the STG interface and each Web Service interface.
Figure 2 depicts the architecture of an application based on the WSM. Web Services WS-A and WS-B are Web Services hosted by third-parties. Each Web Service WS-A and WS-B implement the same or same type of functionality but their implementations as well as their exported interfaces differ. The Service Type Group (STG) denotes the type of functionality that is provided by both Web Services WS-A and WS-B. The STG Interface is the application contract, and can be thought of as a normalized interface to that type of Web Service that an application can use to bind to any Web Service that provides that type of functionality - that is, any Web Service belonging to that STG. The STG Interface is defined by the application developer or an IT organization of a corporation, and specific interesting groups (i.e. specific vertical market players) may provide pre-defined STGs. Patterns 1 and 2 are XML-based interface models that map the actual interface exported by each Web Service to that of the STG.
Applications access the functionality of each Web Service through a STG client proxy object, which makes the WSM application programming model exactly identical with that of standard Web Services. The STG client proxy abstracts from the application the differences between individual Web Services within that STG, and allows the different Web Services to provide the actual functionality without having to modify the application. STG models can also be cascaded to build higher-level application contracts to a variety of back-end Web Services.
The application code snippet below demonstrates how to write a WSM application that computes the square root of an integer using the WSM to dynamically hot-swap between multiple square root Web Services. The application makes method calls to the STG client proxy object that is generated, as usual, from a standard WSDL file.
public static void main(String[] args)
{
STGProxy_squareroot proxy = new STGProxy_squareroot();
System.out.println
("The square root of 25 is " + proxy.squareroot(25));
}
Note:Color coded lines have been split for display purposes
Now, the WSM can be instructed to use any one of the multiple available square root Web Services through a configuration file known as the WSM Policy File. Assuming there exists a square root Web Service uniquely identified within the system as sqrtWS_A, the WSM Policy File can simply direct the WSM to map all communications from the application to the Web Service identified as sqrtWS_A. Later, if it is discovered that sqrtWS_A is no longer providing sufficiently good results, the WSM can be instructed to map the application communications to another Web Service that is uniquely identified by sqrtWS_B. No application modification is required whatsoever.
The WSM effectively decouples an application from its consumed Web Services, and isolates the application’s characteristics (e.g., reliability, scalability, latency) from being adversely affected by any one or a set of “weakest link” Web Services. Changes to any of the Web Services consumed by an application are managed by simply changing a WSM configuration file entry, or the WSM itself can be configured to dynamically compose together the consumed Web Services by assigning fail-over attributes. The WSM moves application maintenance and customization away from expensive developers and error-prone development cycles, to less expensive administrators.
Next week, in the second installment of this three-part series, we will continue our exploration of real world architectures for Web Services-based applications with a particular emphasis on mobile and pervasive environments. We will also take a closer look at the WSM, and how it facilitates and supports the development of real world applications.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
