The request handler is the main integration point between the channel
driver and the toolkit, and must therefore be specific to the communication
protocol, device, and business distribution channel. A request handler should
inherit from the abstract class DSERequestHandler, which is an implementation
of the RequestHandler interface. The abstract implementation class is provided
as a starting point for developing new request handlers.
After a request
handler class has been defined, it must be registered in the toolkit configuration
file (server btt.xml), using the requestHandler field ID.
The
request handler must perform the following tasks:
- Process the request. The request handler must be able to determine the
contents of the ChannelContext request data in order to build and execute
the application operation when a request is made from the device. For example,
the request handler must be able to determine the operation name to be executed
and the parent context to chain to the operation context, to update the timestamp
of the session in the application session table, to handle a request to execute
operations without a session, etc.
- Process the request to establish the session. By getting the ChannelContext
request data, the request handler must be able to perform any integration
that may be required when the request is made from a device to establish the
session. For example, the request handler may be required to determine if
the request is for an existing session and be able to obtain that session
from the application session table.
- Determine the presentation handler. The channel driver must be able to
determine this handler for the specific device from the channel handler, which
is maintained by the handler registry. The presentation handler is required
when a response must be returned to the device.
- Handle exceptions. The request handler must be able to handle all exceptions.
The request handler should first attempt to determine the channel presentation
handler to render the exception back to the device. This is not always possible
as an invalid presentation handler may have been specified in the server configuration
or the application server connection may not have been established. In the
event that the presentation handler cannot be determined, exceptions should
be logged to the server Trace Facility.
The following table briefly describes the methods of the RequestHandler
interface:
Table 1. PresentationHandler interface methodsMethod |
Description |
void processReply (ChannelContext channelContext, ServerOperation
operation) |
Transforms the application data into a reply for the
specific channel. Should be customized for each presentation handler. |
void processSessionReply(ChannelContext channelContext) |
Informs the device that the session has been successfully
established and performs any additional processing not available from the
processReply() method. This method is used when a session has already been
established, and should be customized for each presentation handler. |
void processException (ChannelContext channelContext,
Exception exception) |
This method provides a generic mechanism to render an
error to the client device. The method is used when an exception occurs, and
should be customized for each presentation handler. |