16.4.2 DCE-CIOP Invoke Response Message

   Invoke response messages are returned from servers to clients as the response_message parameter of an invoke RPC.

5. Previous revisions of DCE-CIOP included an endpoint_id member, obtained from an optional TAG_ENDPOINT_ID component, as part of the object identity. The endpoint ID, if used, is now contained within the object key, and its position is specified by the optional TAG_ENDPOINT_ID_POSITION component.

6. Previous revisions of DCE-CIOP encoded the Context in the InvokeRequestHeader. It has been moved to the body for consistency with GIOP.

   Like invoke request messages, an invoke response message is made up of a header and a body. The header has a fixed format, while the format of the body depends on the operation’s OMG IDL definition and the outcome of the invocation.

   16.4.2.1 Invoke response header

   DCE-CIOP invoke response headers have the following structure:

   module DCE_CIOP { // IDL

   enum InvokeResponseStatus {INVOKE_NO_EXCEPTION,INVOKE_USER_EXCEPTION,INVOKE_SYSTEM_EXCEPTION,INVOKE_LOCATION_FORWARD,INVOKE_TRY_AGAIN

   };

   struct InvokeResponseHeader { boolean byte_order; IOP::ServiceContextList service_context; InvokeResponseStatus status;

   // if status = INVOKE_NO_EXCEPTION,

   // result then inouts and outs follow

   // if status = INVOKE_USER_EXCEPTION or // INVOKE_SYSTEM_EXCEPTION, an exception follows

   // if status = INVOKE_LOCATION_FORWARD, an // IOP::IOR follows }; };

   The members have the following definitions:

• byte_order indicates the byte ordering used in the representation of the remainder of the message. A value of FALSE indicates big-endian byte ordering, and TRUE indicates little-endian byte ordering.

• service_context contains any ORB service data that needs to be sent from the client to the server.

• status indicates the completion status of the associated request, and also determines the contents of the body.

   16.4.2.2 Invoke Response Body

   The contents of the invoke response body depends on the value of the status member of the invoke response header, as well as the OMG IDL definition of the operation being invoked. Its format is one of the following:

• If the status value is INVOKE_NO_EXCEPTION, then the body contains the operation result value (if any), followed by all inout and out parameters, in the order in which they appear in the operation signature, from left to right.

• If the status value is INVOKE_USER_EXCEPTION or INVOKE_SYSTEM_EXCEPTION, then the body contains the exception, encoded as in GIOP.

• If the status value is INVOKE_LOCATION_FORWARD, then the body contains a new IOR containing a TAG_INTERNET_IOP or TAG_MULTIPLE_COMPONENTS profile whose components can be used to communicate with the object specified in the invoke request message7. This profile must provide at least one new DCE-CIOP binding component. The client ORB is responsible for resending the request to the server identified by the new profile. This operation should be transparent to the client program making the request. See “DCE-CIOP Object Location? on page 16-21 for more details.

• If the status value is INVOKE_TRY_AGAIN, then the body is empty and the client should reissue the invoke RPC, possibly after a short delay8.