Specialized Pivot Point Handlers, a.k.a. Providers
New technology like Web services can be viewed as simply a new means of accessing existing IT assets. When you're looking at the wide variety of ways in which data can be accessed (servlets, Web services, Java RMI, and so on), you can see that each of them uses a different mechanism for transferring the data from one source to another; however, the business logic that is executed should not change based on the means of data transport. In keeping with this separation of roles, Axis' handlers will typically be written in such a way that they are simply the bridge between Axis and your existing business logic. Of course, it is possible to write handlers such that all of the code is contained within the handler itself, but when the next big thing comes along, chances are it would require more work than if a clean delineation had been kept between the means of transporting the data and the business logic. This concept is very similar to how many people write their servlets or JSPs; the HTML presentation logic is in the JSP, whereas the real work is done through accessing beans or some external Java code.
In keeping with this separation, the pivot point handlers should be written such that their job is to interpret the incoming SOAP message, locate the business resources needed to perform the desired task, execute the task, and then place any response data into the response SOAP message. Although we discuss this subject in terms of a pivot point handler, this same design pattern can (and should) be used for any of the handlers written no matter where in the chains they appear.
There is no limit to the types of resources that handlers can access. By the time Axis ships its first release, it should contain handlers that will enable access to resources such as:
However, currently, Axis is only at an alpha state, and only two types of handlers come with it: a Java RPC handler and a Java Message handler. The Java RPC handler will examine the body of the request message and convert it into a procedure call. In other words, it will deserialize the XML elements in the body into individual Java objects (the method parameters) and, based on the method name (also in the body element), call that specified method with those Java objects as parameters. If there is a return value from the procedure call, it will be serialized and placed into the body of the response SOAP message. (It might be useful to examine the code for this handler—you can find it in the Axis source in a file called org/apache/axis/providers/java/RPCProvider.java.)
The other handler that comes with Axis is the Java Message handler. This handler is similar to the Java RPC handler in that it will examine the body of the request SOAP message to determine which Java method to call. However, unlike the RPC handler, which will deserialize the XML into Java objects, the Message handler will take the XML as is and simply pass it along to the desired method untouched. This approach is useful in a document-centric processing model—one in which the business logic wishes to receive the data in raw XML rather than to have Axis try to do any conversions.
As long as it is possible to write Java code to access the desired resource, there is no reason why a handler cannot be written to access it—thus making Axis an incredibly flexible and powerful SOAP processor. Of course, sometimes a handler's role is to perform a task that is SOAP specific, and in that case placing the logic inside the handler itself might make sense. For example, a handler that determines which Web service to invoke would probably not need to access any back-end systems, but instead would use just the data in the SOAP message.
Ultimately, the choice of how to design and write a handler is not mandated by Axis, but rather is left up to the handler writer. Axis does not place any restrictions on your design choices in hopes that the system remains flexible and pluggable enough that it can be used in a limitless number of configurations.