The IIOP request flow

The following diagram shows the execution flow of an incoming request:
Figure 1. IIOP request execution flow
This diagram shows a the TCP/IP sockets listener receiving an IIOP request and passing it to the request receiver transaction CIRR. The request receiver links to the security URM (DFHXOPUS) and passes the request to the request processor transaction CIRP (which may be in another region). The request processor interacts with the transaction service and the container and passes control to the requested user method. This is described in the following text.
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.