15.4.3 Reply Message

   Reply messages are sent in response to Request messages if and only if the response expected flag in the request is set to TRUE. Replies include inout and out parameters, operation results, and may include exception values. In addition, Reply messages may provide object location information. In GIOP versions 1.0 and 1.1, replies flow only from server to client.

   Reply messages have three elements, encoded in this order:

• A GIOP message header

• A ReplyHeader structure

• The reply body

   15.4.3.1 Reply Header

   The reply header is defined as follows:

   module GIOP { // IDL extended for 1.2 and 1.3

   #ifndef GIOP_1_2 // GIOP 1.0 and 1.1

   enum ReplyStatusType_1_0 { // Renamed from ReplyStatusType NO_EXCEPTION, USER_EXCEPTION, SYSTEM_EXCEPTION, LOCATION_FORWARD

   };

   // GIOP 1.0

   struct ReplyHeader_1_0 { // Renamed from ReplyHeaderIOP::ServiceContextList service_context;unsigned long request_id;ReplyStatusType_1_0 reply_status;

   };

   // GIOP 1.1typedef ReplyHeader_1_0 ReplyHeader_1_1;// Same Header contents for 1.0 and 1.1

   #else // GIOP 1.2, 1.3 enum ReplyStatusType_1_2 {

   NO_EXCEPTION,USER_EXCEPTION,SYSTEM_EXCEPTION,LOCATION_FORWARD,LOCATION_FORWARD_PERM,// new value for 1.2NEEDS_ADDRESSING_MODE // new value for 1.2

   };

   struct ReplyHeader_1_2 {unsigned long request_id;ReplyStatusType_1_2 reply_status;IOP::ServiceContextList service_context;

   };

   typedef ReplyHeader_1_2 ReplyHeader_1_3; #endif // GIOP_1_2 };

   The members have the following definitions:

• request_id is used to associate replies with requests. It contains the same request_id value as the corresponding request.

• service_context contains ORB service data being passed from the server to the client, encoded as described in Section 15.2.3, “GIOP Message Transfer,? on page 15-4.

• reply_status indicates the completion status of the associated request, and also determines part of the reply body contents. If no exception occurred and the operation completed successfully, the value is NO_EXCEPTION and the body contains return values. Otherwise the body

• contains an exception, or • directs the client to reissue the request to an object at some other location, or • directs the client to supply more addressing information.

   There is no padding after the reply header when an unfragmented reply message body is empty.

   15.4.3.2 Reply Body

   In GIOP version 1.0 and 1.1, reply bodies are marshaled into the CDR encapsulation of the containing Message immediately following the Reply Header. In GIOP version 1.2 and 1.3, the Reply Body is always aligned on an 8-octet boundary. The fact that GIOP specifies the maximum alignment for any primitive type is 8 guarantees that the ReplyBody will not require remarshaling if the Message or the Reply Header are modified. The data for the reply body is determined by the value of reply_status. There are the following types of reply body:

• If the reply_status value is NO_EXCEPTION, the body is encoded as if it were a structure holding first any operation return value, then any inout and out parameters in the order in which they appear in the operation’s OMG IDL definition, from left to right. (That structure could be empty.)

• If the reply_status value is USER_EXCEPTION or SYSTEM_EXCEPTION, then the body contains the exception that was raised by the operation, encoded as described in Section 15.3.5.5, “Exception,? on page 15-30. (Only the user-defined exceptions listed in the operation’s OMG IDL definition may be raised.)

   When a GIOP Reply message contains a `reply_status' value of SYSTEM_EXCEPTION, the body of the Reply message conforms to the following structure:

   module GIOP { // IDL

   struct SystemExceptionReplyBody { string exception_id; unsigned long minor_code_value; unsigned long completion_status; };

   };

   The high-order 20 bits of minor_code_value contain a 20-bit “Vendor Minor Codeset ID? (VMCID); the low-order 12 bits contain a minor code. A vendor (or group of vendors) wishing to define a specific set of system exception minor codes should obtain a unique VMCID from the OMG, and then use those 4096 minor codes as they see fit; for example, defining up to 4096 minor codes for each system exception. Any vendor may use the special VMCID of zero (0) without previous reservation, but minor code assignments in this codeset may conflict with other vendor's assignments, and use of the zero VMCID is officially deprecated.

   Note – OMG standard minor codes are identified with the 20 bit VMCID \x4f4d0. This appears as the characters ‘O’ followed by the character ‘M’ on the wire, which is defined as a 32-bit constant called OMGVMCID \x4f4d0000 (see Section 4.12.4, “Standard Minor Exception Codes,? on page 4-73) so that allocated minor code numbers can be or-ed with it to obtain the minor_code_value.

• If the reply_status value is LOCATION_FORWARD, then the body contains an object reference (IOR) encoded as described in Section 15.3.6, “Object References,? on page 15-30. The client ORB is responsible for re-sending the original request to that (different) object. This resending is transparent to the client program making the request.

• The usage of the reply_status value LOCATION_FORWARD_PERM behaves like the usage of LOCATION_FORWARD, but when used by a server it also provides an indication to the client that it may replace the old IOR with the new IOR. Both the old IOR and the new IOR are valid, but the new IOR is preferred for future use.

• If the reply_status value is NEEDS_ADDRESSING_MODE then the body contains a GIOP::AddressingDisposition. The client ORB is responsible for re-sending the original request using the requested addressing mode. The resending is transparent to the client program making the request.

   Note – Usage of LOCATATION_FORWARD_PERM is now deprecated, due to problems it causes with the semantics of the Object::hash() operation. LOCATATION_FORWARD_PERM features could be removed from some future GIOP versions if solutions to these problems are not provided.

   For example, the reply body for a successful response (the value of reply_status is NO_EXCEPTION) to the Request example shown on page 15-37 would be equivalent to the following structure:

   struct example_reply {

   Note that the object_key field in any specific GIOP profile is server-relative, not absolute. Specifically, when a new object reference is received in a LOCATION_FORWARD Reply or in a LocateReply message, the object_key field embedded in the new object reference’s GIOP profile may not have the same value as the object_key in the GIOP profile of the original object reference. For details on location forwarding, see Section 15.6, “Object Location,? on page 15-49.