The following diagram shows the execution flow of an incoming request:
Figure 1. IIOP request execution flow
- The TCP/IP listener
- The CICS® TCP/IP
listener monitors specified ports for inbound requests. You specify IIOP
ports and configure the listener by defining and installing TCPIPSERVICE resources.
The
listener receives the incoming request and starts the transaction specified
in the TCPIPSERVICE definition for that port. For IIOP services, this transaction
resource definition must have the program attribute set to DFHIIRRS, the request
receiver program. The default transaction name is CIRR.
- Request receiver
- The
request receiver retrieves the incoming request and examines the contents
of the GIOP formatted message stream. The following GIOP message types can
be received and are handled as follows:
- Request
-
- A CICS USERID is determined from Secure Sockets Layer (SSL) parameters,
or by calling a CICS user-replaceable program specified by the TCPIPSERVICE
resource definition. The CICS USERID is used for authorization of the request
by the request processor.
- A CICS TRANSID is determined, from the message content, by comparison
with installed REQUESTMODEL resource definitions. The CICS TRANSID defines
execution parameters that are used if a new request processor instance is
created to handle the request.
- The request is passed to the request processor using an associated request
stream, which is an internal CICS routing mechanism. The object key in
the request, or any transaction service context, determines if the request
must be sent to an existing processor.
Note: A transaction in this
context means a unit of work defined and managed using the Object Transaction
Service (OTS) specification.
The request-handling logic uses
a directory to determine if an IIOP request should be routed to an existing
request processor instance (by means of its associated request stream). The
directory, DFHEJDIR, relates request streams (and request processor instances)
to OTS transactions and the object keys of stateful session beans that manage
their own transactions. DFHEJDIR is a recoverable CICS file.
- Incoming GIOP 1.1 Fragments are rejected with a GIOP MessageError message.
- LocateRequest
- Locate
requests have no operation or parameters. They are passed to a new
instance of the request processor.
- CancelRequest
- A cancel request notifies a server that the client is no longer expecting
a reply to a specified pending Request or LocateRequest message. This is an
advisory message only, no reply is expected. A cancel request received during
fragment processing causes the request in progress to be terminated. All other
cancel requests are ignored.
- MessageError
- A message
error indicates that the client has not recognized a reply that the request
receiver has sent to it. This error is recorded for diagnostic purposes and
a CloseConnection message sent to end the connection.
- Fragments
- A fragment
is a continuation of a Request or a Reply. It contains a GIOP message header
followed by data. Incoming GIOP 1.1 fragments are rejected with a GIOP MessageError
message.
Linkage from the request receiver to the request processor
can exploit CICS dynamic routing services to provide load balancing within
the CICSplex.
The CIRR request receiver terminates when it has no further
work to do. (That is, CIRR terminates when there are no outstanding GIOP
requests to read from the TCPIPSERVICE and no outstanding responses to send
from earlier requests. Should further workload arrive for the TCPIPSERVICE
after the CIRR task has been terminated, a new CIRR task is started.)
- Request processor
- The
request processor manages the execution of the IIOP request. It :
- Locates the object identified by the request
- For an enterprise bean request, calls the container to process the bean
method
- For a request for a stateless CORBA object, processes the request itself
(although the transaction service may also be involved)
The request processor instance that handles each IIOP request is
configured by a CORBASERVER resource definition.