 |  |  |  |  |
| | | | |
 |  |
When a service proxy invokes an operation on a service, the operation's parameters are passed to FUSE Services Framework where they are built into a message and placed on the wire. When the message is received by the service, FUSE Services Framework reads the message from the wire, reconstructs the message, and then passes the operation parameters to the application code responsible for implementing the operation. When the application code is finished processing the request, the reply message undergoes a similar chain of events on its trip to the service proxy that originated the request. This is shown in Figure 21.1.
JAX-WS defines a mechanism for manipulating the message data between the application level code and the network. For example, you might want the message data passed over the open network to be encrypted using a proprietary encryption mechanism. You could write a JAX-WS handler that encrypted and decrypted the data. Then you could insert the handler into the message processing chains of all clients and servers.
As shown in Figure 21.2, the handlers are placed in a chain that is traversed between the application level code and the transport code that places the message onto the network.
The JAX-WS specification defines two basic handler types:
Logical handlers can process the message payload and the properties stored in the message context. For example, if the application uses pure XML messages, the logical handlers have access to the entire message. If the application uses SOAP messages, the logical handlers have access to the contents of the SOAP body. They do not have access to either the SOAP headers or any attachments unless they were placed into the message context.
Logical handlers are placed closest to the application code on the handler chain. This means that they are executed first when a message is passed from the application code to the transport. When a message is received from the network and passed back to the application code, the logical handlers are executed last.
Protocol handlers can process the entire message received from the network and the properties stored in the message context. For example, if the application uses SOAP messages, the protocol handlers would have access to the contents of the SOAP body, the SOAP headers, and any attachments.
Protocol handlers are placed closest to the transport on the handler chain. This means that they are executed first when a message is received from the network. When a message is sent to the network from the application code, the protocol handlers are executed last.
![[Tip]](imagesdb/tip.gif) | Tip |
|---|---|
The only protocol handler supported by FUSE Services Framework is specific to SOAP. |
The differences between the two handler types are very subtle and they share a common base interface. Because of their common parentage, logical handlers and protocol handlers share a number of methods that must be implemented, including:
The handleMessage() method is the central method in any handler. It is the method responsible for
processing normal messages.
handleFault() is the method responsible for processing fault messages.
close() is called on all executed handlers in a handler chain when a message has reached
the end of the chain. It is used to clean up any resources consumed during message processing.
The differences between the implementation of a logical handler and the implementation of a protocol handler revolve around the following:
The specific interface that is implemented
All handlers implement an interface that derives from the Handler interface. Logical handlers
implement the LogicalHandler interface. Protocol handlers implement protocol specific extensions
of the Handler interface. For example, SOAP handlers implement the
SOAPHandler interface.
The amount of information available to the handler
Protocol handlers have access to the contents of messages and all of the protocol specific information that is packaged with the message content. Logical handlers can only access the contents of the message. Logical handlers have no knowledge of protocol details.
To add a handler to an application you must do the following:
Determine whether the handler is going to be used on the service providers, the consumers, or both.
Determine which type of handler is the most appropriate for the job.
Implement the proper interface.
To implement a logical handler see Implementing a Logical Handler.
To implement a protocol handler see Implementing a Protocol Handler.
Configure your endpoint(s) to use the handlers.
| |  | |
 |
