| Previous | Table of Contents | Next |
Request messages encode CORBA object invocations, including attribute accessor operations, and CORBA::Object operations get_interface
and get_implementation. Requests flow from client to server.
Request messages have three elements, encoded in this order:
• A GIOP message header
• A Request Header
• The Request Body
15.4.2.1 Request Header
The request header is specified as follows:
module GIOP { // IDL extended for version 1.1, 1.2, and 1.3.
// GIOP 1.0
struct RequestHeader_1_0 { // Renamed from RequestHeader IOP::ServiceContextList service_context; unsigned long request_id;
boolean response_expected; sequence <octet> object_key; string operation; CORBA::OctetSeq requesting_principal;
};
// GIOP 1.1
struct RequestHeader_1_1 { IOP::ServiceContextList service_context; unsigned long request_id; boolean response_expected; octet
reserved[3]; // Added in GIOP 1.1 sequence <octet> object_key; string operation; CORBA::OctetSeq requesting_principal;
};
// GIOP 1.2, 1.3
typedef short AddressingDisposition;const short KeyAddr = 0;const short ProfileAddr = 1;const short ReferenceAddr = 2;
struct IORAddressingInfo {unsigned long selected_profile_index;IOP::IOR ior;
};
union TargetAddress switch (AddressingDisposition) {case KeyAddr: sequence <octet> object_key;case ProfileAddr: IOP::TaggedProfile profile;case ReferenceAddr: IORAddressingInfo ior;
};
struct RequestHeader_1_2 {unsigned long request_id;octet response_flags;octet reserved[3];TargetAddress target;string operation;IOP::ServiceContextList service_context;// requesting_principal not in GIOP 1.2 and 1.3
}; typedef RequestHeader_1_2 RequestHeader_1_3; };
The members have the following definitions:
• request_id is used to associate reply messages with request messages (including LocateRequest messages). The client (requester) is responsible for generating values so that ambiguity is eliminated; specifically, a client must not re-use request_id values during a connection if: (a) the previous request containing that ID is still pending, or (b) if the previous request containing that ID was canceled and no reply was received. (See the semantics of the Section 15.4.4, “CancelRequest Message,? on page 15-41).
• reserved is always set to 0 in GIOP 1.1. These three octets are reserved for future use.
• For GIOP 1.0 and 1.1, object_key identifies the object that is the target of the invocation. It is the object_key field from the transport-specific GIOP profile (e.g., from the encapsulated IIOP profile of the IOR for the target object). This value is only meaningful to the server and is not interpreted or modified by the client.
• response_flags is set to 0x0 for a SyncScope of NONE and WITH_TRANSPORT. The flag is set to 0x1 for a SyncScope of WITH_SERVER. A non exception reply to a request message containing a response_flags value of 0x1 should contain an empty body, i.e. the equivalent of a void operation with no out/inout parameters. The flag is set to 0x3 for a SyncScope of WITH_TARGET. These values ensure interworking compatibility between this and previous versions of GIOP.
For GIOP 1.0 and 1.1 a response_expected value of TRUE is treated like a response_flags value of \x03, and a response_expected value of FALSE is treated like a response_flags value of \x00.
• For GIOP 1.2, 1.3, target identifies the object that is the target of the invocation. The possible values of the union are:
• KeyAddr is the object_key field from the transport-specific GIOP profile (e.g., from the encapsulated IIOP profile of the IOR for the target object). This value is only meaningful to the server and is not interpreted or modified by the client. • ProfileAddr is the transport-specific GIOP profile selected for the target’s IOR by the client ORB. • IORAddressingInfo is the full IOR of the target object. The selected_profile_index indicates the transport-specific GIOP profile that was selected by the client ORB. The first profile has an index of zero.
• operation is the IDL identifier naming, within the context of the interface (not a fully qualified scoped name), the operation
being invoked. In the case of attribute accessors, the names are _get_<attribute> and _set_<attribute>. The case of the operation
or attribute name must match the case of the operation name specified in the OMG IDL source for the interface being used.
In the case of CORBA::Object operations that are defined in the CORBA Core
(Section 4.3, “Object Reference Operations,? on page 4-12) and that correspond to
GIOP request messages, the operation names are _interface, _is_a, _non_existent, _domain_managers, and _component.
Note – The name _get_domain_managers is not used, to avoid conflict with a get operation invoked on a user defined attribute
with name domain_managers.
For GIOP 1.2 and later versions, only the operation name _non_existent shall be used.
The correct operation name to use for GIOP 1.0 and 1.1 is _non_existent. Due to a typographical error in CORBA 2.0, 2.1, and
2.2, some legacy implementations of GIOP 1.0 and 1.1 respond to the operation name _not_existent. For maximum interoperability
with such legacy implementations, new implementations of GIOP
1.0 and 1.1 may wish to respond to both operation names, _non_existent and _not_existent.
• service_context contains ORB service data being passed from the client to the server, encoded as described in Section 13.7, “Service Context,? on page 13-28.
• requesting_principal contains a value identifying the requesting principal. It is provided to support the BOA::get_principal operation. The usage of the requesting_principal field is deprecated for GIOP versions 1.0 and 1.1. The field is not present in the request header for GIOP version 1.2, 1.3.
There is no padding after the request header when an unfragmented request message body is empty.
15.4.2.2 Request Body
In GIOP versions 1.0 and 1.1, request bodies are marshaled into the CDR encapsulation of the containing Message immediately
following the Request Header. In GIOP version 1.2 and 1.3, the Request 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 Request Body will not require
remarshaling if the Message or Request header are modified. The data for the request body includes the following items encoded
in this order:
• All in and inout parameters, in the order in which they are specified in the operation’s OMG IDL definition, from left to right.
• An optional Context pseudo object, encoded as described in Section 15.3.5.4, “Context,? on page 15-29. This item is only included if the operation’s OMG IDL definition includes a context expression, and only includes context members as defined in that expression.
For example, the request body for the following OMG IDL operation
double example (in short m, out string str, inout long p);
would be equivalent to this structure:
struct example_body { short m; // leftmost in or inout parameter long p; // ... to the rightmost
};