This section gives you a conceptual overview of the Web client architecture.
The main component of the Web client is a servlet that runs on a Web server and uses Java technology to deliver HTML pages to a Web browser. The HTML pages are generated based on the information from the MQ Workflow system.
An application server that can run Java servlets is needed to create the HTML pages that are displayed in the Web browser. IBM WebSphere Application Server is the only officially-supported application server, provides automatic configuration of the Web client, and is provided with IBM HTTP Server. WebSphere Application Server can also run with a variety of other Web servers, some of which require a plug-in to be able to run Java servlets. You can also use other application servers that implement the required servlet and JSP standards.
The application server runs a set of Java classes that make up the
HTTP
interface to MQ Workflow. After the information has been retrieved from
the
Workflow system, a configurable Viewer
class is called
that converts the
data into HTML pages. You can use Java Server Pages (JSPs) to create
these pages which
are then sent back to the Web browser.
If your environment does not yet support JSPs, the Web client's servlet can work with MQ Workflow proprietary HTML template files that are stored on the Web server. However, this approach is not as flexible as using JSPs.
The following figure shows the Web client architecture in a three-tier scenario:
The Web client actually is composed of the parts running in the servlet container. The HTTP requests are sent to an HTTP server where the a rerouted to the servlet container. The Web client then uses the Java API of MQ Workflow to connect to the workflow system.
The Web client Servlet is the entry point for all requests coming from the clients by HTTP. The parameters passed with such a request are processed and the command requested is delegated to a component capable of handling it, a Command Handler. Command Handlers execute the commands sent by the clients by calling the corresponding Workflow API methods. One Command Handler typically implements multiple command-API call mappings.
A Command Handler Adapter allows the use of multiple Command Handlers in parallel. Using this mechanism you can add commands of your own design to the Web client without having to implement all the basic functions yourself.
The Command Handler then should use Java Server Pages (JSPs) to create a response to the client’s request. Normally that is an html page, but you can send any kind of HTTP response your client is able to interpret.
The server and client components communicate with each other by using the WebSphere MQ message queuing. If you want to use your own thin client solution, you can use the MQ Workflow API and write your own applications. The MQ Workflow Concepts and Architecture book contains a detailed description of the Web-based Client architecture.
For information about how the Web client uses HTTP sessions to manage the MQ Workflow sessions for logged-on users, see Session handling.
For information about the setup scenarios in which the Web client architecture is used and further information on how the client connects to the workflow servers, see the Concepts and Architecture and Installation Guide books.