CICS Transaction Gateway V5 The WebSphere ... - IBM Redbooks

10.3 Testing the configuration
We tested both our J2EE EJB application (CTGTesterCCI) and our servlet-based
Web application (CTGTesterECI) in our J2EE Server, using the following two
topologies:
► HTTP Transport Handler (port 80) -> J2EE Server
► IBM HTTP Server (port 99) -> WebSphere Plugin -> J2EE Server
266 CICS Transaction Gateway V5
Note: This second topology was used to demonstrate how to authenticate
the Web client and flow the security context onto CICS, since at the time of
writing the HTTP Transport Handler did not support basic authentication.
However, this support has now been made available with the PTF for APAR
PQ59911, and we advise you to use this function if you require Web client
authentication.
For further details on these different topologies, refer to Figure 10-2 on page 241.
How the HTTP request is matched to the definitions
Before testing, it is good to have a general understanding of how the URL is
matched to your definitions. If something goes wrong, you then have an idea of
where to look.
When using the IBM HTTP Server as the protocol catcher, the HTTP Server acts
merely as a router for the HTTP request. The HTTP request is passed from the
HTTP server into the WebSphere plugin and onto the Web container in the J2EE
Server. Therefore, the HTTP Server can be used as a proxy to the J2EE Server
or to handle security.
When using the HTTP Transport Handler in the J2EE Server, the HTTP request
is received directly by the J2EE Server listening on the defined port, and the
request is forwarded directly to the Web container in the J2EE Server.
Using the HTTP Server
The HTTP Server configuration is stored in the httpd.conf file. Within this file,
there is one statement we are particularly interested in:
Service /CTGTester*/*
/usr/lpp/WebSphere/WebServerPlugIn/bin/was400plugin.so:service_exit
The Service statement maps a request over to the WebSphere plugin
environment. If the URL matches the given template (/CTGTester*/*), then the
request is passed to the WebSphere plugin's executable module
(was400plugin.so), which is defined in the second part of the URL, along with the
entry point to be invoked in that module (service_exit).