Decoupling Applications from Services
Figure 1: A client proxy-based application programming model for Web Services. In order to invoke a method of a Web Service, a Java application calls the corresponding method of a Java client proxy object. The client proxy then encapsulates the invocation request as a SOAP message, and routes it to the appropriate endpoint where the Web Service is located.
Applications based on Web Services use a simple client proxy application programming model. A client proxy is similar to a “stub” that is local to the application and provides the same API (e.g., methods and arguments) as the actual Web Service. However, the client proxy does not implement any of the Web Service’s business logic, but instead brokers communications between the application and the remote Web Service. Essentially, the application invokes methods of the client proxy, which then encapsulates the method calls together with any arguments as a SOAP message and transmits the message to the Web Service. The Web Service performs the desired functionality, and returns the result as a SOAP message to the client proxy. The method call of the client proxy then returns with the result. Figure 1 graphically depicts the client proxy application programming model.
Since a client proxy is particular to each Web Service and represents the exact interface of that Web Service, application calls to a client proxy object effectively hardwire that application to the corresponding Web Service. This tight coupling prevents the development of real world applications because:
1. The characteristics of the application, such as reliability and latency, are directly determined by the characteristics of the consumed Web Services. The “weakest” Web Services will adversely affect the overall characteristics of the composite application. A developer will be in for a rude shock to see the application she spent months making reliable going down every day because of a misbehaving Web Service.
2. Changes to the Web Services consumed by an application require invasive re-writes followed by a laborious re-testing cycle. Using a different Web Service requires integrating into the application a different client proxy, and re-writing the application method invocations. The process of making such source code changes as new Web Services emerge or as existing ones become unattractive or unavailable is prohibitively expensive, if not impractical.
The key to a real world Web Services-based application architecture is to decouple the application from the consumed Web Services so that the characteristics of each Web Service do not have a hardwired effect on the application, nor do changes to any Web Service require time consuming and expensive rewriting of the application. A real world application architecture using Web Services must be based on dynamic composition in which any consumed Web Service can be hot-swapped out and new Web Services hot-swapped in, all without making any changes to the application source code.
Hot-swapping Web Services would be easy if it were not for the unique interface signature of each Web Service. Even Web Services that are similar or competitive have unique and different signatures since no two people implement a given program identically. Consider a very simple Web Service that calculates the integral square root of an integer. The interface signatures of two different implementations of this square root Web Service are as follows:
| Implementation A | Implementation B |
int sqrt (int a) | ID sqrt (int a)
int getResult (ID b) |
The first implementation is a straightforward one, while the second one is a pipelined implementation that requires an additional call to the getResult method with the identifier returned from the sqrt call to access the actual square root value. From this very simple example, we see that multiple Web Service implementations of identical capability will require different application-side support. From each method name and its exact functionality, to operation sequencing requirements, and to the granularity of the methods that are exposed, each Web Service implementation will be very different.
An application architecture for Web Services must be able to abstract away these differences so as to support dynamic composition and hot-swapping.
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.
