| Previous | Table of Contents | Next |
Emerging specifications for Object Services occasionally require service-specific context information to be passed implicitly
with requests and replies. The Interoperability specifications define a mechanism for identifying and passing this service-specific
context information as “hidden? parameters. The specification makes the following assumptions:
• Object Service specifications that need additional context passed will completely specify that context as an OMG IDL data type.
• ORB APIs will be provided that will allow services to supply and consume context information at appropriate points in the process of sending and receiving requests and replies.
• It is an ORB’s responsibility to determine when to send service-specific context information, and what to do with such information in incoming messages. It may be possible, for example, for a server receiving a request to be unable to de-encapsulate and use a certain element of service-specific context, but nevertheless still be able to successfully reply to the message.
As shown in the following OMG IDL specification, the IOP module provides the mechanism for passing Object Service–specific
information. It does not describe any service-specific information. It only describes a mechanism for transmitting it in the
most general way possible. The mechanism is currently used by the DCE ESIOP and could also be used by the Internet Inter-ORB
protocol (IIOP) General Inter_ORB Protocol (GIOP).
Each Object Service requiring implicit service-specific context to be passed through GIOP will be allocated a unique service
context ID value by OMG. Service context ID values are of type unsigned long. Object service specifications are responsible
for describing their context information as single OMG IDL data types, one data type associated with each service context
ID.
The marshaling of Object Service data is described by the following OMG IDL:
module IOP { // IDL
typedef unsigned long ServiceId;
struct ServiceContext {
ServiceId context_id;
sequence <octet> context_data;
};
typedef sequence <ServiceContext>ServiceContextList; };
The context data for a particular service will be encoded as specified for its service-specific OMG IDL definition, and that
encoded representation will be encapsulated in the context_data member of IOP::ServiceContext
. (See Section 15.3.3,
“Encapsulation? on page 15-14). The
context_id member contains the service ID value identifying the service and data format. Context data is encapsulated in octet
sequences to permit ORBs to handle context data without unmarshaling, and to handle unknown context data types.
During request and reply marshaling, ORBs will collect all service context data associated with the Request or Reply in a
ServiceContextList, and include it in the generated messages. No ordering is specified for service context data within the
list. The list is placed at the beginning of those messages to support security policies that may need to apply to the majority
of the data in a request (including the message headers).
Each Object Service requiring implicit service-specific context to be passed through GIOP will be allocated a unique service
context ID value by the OMG. Service context ID values are of type unsigned long. Object service specifications are responsible
for describing their context information as single OMG IDL data types, one data type associated with each service context
ID.
The high-order 24 bits of a service context ID contain a 24-bit vendor service context codeset ID (VSCID); the low-order 8
bits contain the rest of the service context ID. A vendor (or group of vendors) who wishes to define a specific set of service
context IDs should obtain a unique VSCID from the OMG, and then define a specific set of service context IDs using the VSCID
for the high-order bits.
The VSCIDs of zero to 15 inclusive (0x000000 to 0x00000f) are reserved for use for OMG-defined standard service context IDs
(i.e., service context IDs in the range 04095 are reserved as OMG standard service contexts).