Designing a Service's Interaction Layer
It is not advisable to put in a handler business logic or processing particular to
specific requests and responses.
You cannot store client specific state in a handler: A handler's logic acts on
all requests and responses that pass through an endpoint. However, you may use
the handler to store port specific state, which is state common to all method calls
on that service interface. Note also that handlers execute in the context of the
component in which they are present.
Do not store client specific state in a handler.
Also note that handlers work directly on the SOAP message, and this involves
XML processing. You can use handlers to pass client specific state through the
message context. (See Passing Context Information on Web Service Calls on
Use of handlers can result in a significant performance impact for the service
as a whole.
Use of handlers could potentially affect the interoperability of your service.
See the next section on interoperability. Keep in mind that it takes advanced
knowledge of SOAP message manipulation APIs (such as SAAJ) to correctly use
handlers. To avoid errors, Web service developers should try to use existing or
vendor supplied handlers. Using handlers makes sense primarily for writing
system services such as auditing, logging, and so forth.
A major benefit of Web services is interoperability between heterogeneous plat
forms. To get the maximum benefit, you want to design your Web service to be
interoperable with clients on any platform, and, as discussed in Chapter 2, the Web
Services Interoperability (WS I) organization helps in this regard. WS I promotes a
set of generic protocols for the interoperable exchange of messages between Web
services. The WS I Basic Profile promotes interoperability by defining and recom
mending how a set of core Web services specifications and standards (including
SOAP, WSDL, UDDI, and XML) can be used for developing interoperable Web