22.14.1 Structures

   22.14.1.1 MessageBody

   This structure is used to wrap the marshaled GIOP message data (either request arguments or reply data) to support repackaging as the request components around that data (such as service contexts or object key) change due to Routing. Since GIOP 1.2 Request and Reply Bodies are always aligned to an 8-octet boundary, it is necessary to keep track of the

• data and the length of that data as a sequence of octet, and

• the byte order with which that data was originally marshaled.

   22.14.1.2 RequestMessage

   This structure explicitly contains all the components of a GIOP request. When the target is actually invoked, its members are used to compose an actual GIOP request.

   The RequestMessage has the following members:

• giop_version - the version of the GIOP that was used when the message was marshaled.

• service_contexts - the sequence of service contexts selected for this request. Routers must propagate all Service Contexts with unknown tags.

• body - the CDR stream message payload and marshaling byte order for repackaging within a new GIOP request once the routed message can be synchronously invoked on the target.

• response_flags - As explained further in the General Inter-ORB Protocol chapter, Section 15.4.1, “GIOP Message Header,? on page 15-31, the meaning of the two least significant bits is defined as:

• the least significant bit (bit-0) indicates whether or not a response may be returned. If this bit is “1?, then the server-side ORB shall always send a ReplyMessage. If the bit-0 is “0?, no ReplyMessage will be sent. This replicates the function of the response_expected boolean in CORBA. • Bit-1 is considered if and only if bit-0 is “1.? If bit-1 is “0? the server sends a ReplyMessage before invoking the target. If bit-1 is “1? the ReplyMessage is sent after the target has completed the invocation.

• reserved • object_key - the opaque object key of the target. This may change if a GIOP

object forwarding occurs for this request. • operation - the operation name of the request being made.

   22.14.1.3 ReplyDestination

   This structure contains enough information for the response to be returned once the actual invocation has been made on the target.

• handler_type - Either UNTYPED or TYPED indicating which type of ReplyHandler is to receive the response. This flag is necessary to ensure that no is_a must be performed when the Target Router is ready to return the reply as described in Section 22.14.3.5, “Target Router,? on page 22-54.

• handler - an Object reference to the ReplyHandler that is the destination of the response.

   22.14.1.4 RequestInfo

   This structure contains the information required for an intermediate Router to get a request closer to its target and for a target Router to invoke that request on its target.

• visited - the sequence of Routers through which the message has been sent already. Each router may add its reference to this sequence before forwarding the request to another Router. This sequence can be used by a Router to detect cycles in a network of Routers, but this is not a requirement step in the Routing protocol.

• to_visit - the suggested sequence of Routers to which the message should be sent if the target is not available. This sequence may be modified as the request is sent from Router to Router.

• profile_index -the index of the profile in the target IOR that is being used for this request. This is necessary so the target router can choose the correct object key when composing the final GIOP request.

• target - the full IOR of this message’s target.

• reply_destination - a reference to the ReplyHandler for this request along with the disposition of that ReplyHandler. If the handler_type is UNTYPED, the destination is an untyped ReplyHandler (meaning that it was created when create_persistent_request was called and is implemented by the ClientRouter). If the handler_type is TYPED, the reply destination is a type-specific ReplyHandler implemented by an application using the callback model. If the reply destination is nil, no reply will be sent and the handler_type can be ignored.

• selected_qos - the list of QoS that was selected for the Routing of this message.

• message - the payload (arguments, return value, raised exception) for this message, including the byte order with which the message was originally marshaled.