| Previous | Table of Contents | Next |
Clients request services by issuing requests.
The term request is broadly used to refer to the entire sequence of causally related events that transpires between a client
initiating it and the last event causally associated with that initiation. For example:
• the client receives the final response associated with that request from the server,
• the server carries out the associated operation in case of a oneway request, or
• the sequence of events associated with the request terminates in a failure of some sort. The initiation of a Request is an event.
The information associated with a request consists of an operation, a target object, zero or more (actual) parameters, and
an optional request context.
A request form is a description or pattern that can be evaluated or performed multiple times to cause the issuing of requests.
As described in the OMG IDL Syntax and Semantics chapter, request forms are defined by particular language bindings. An alternative
request form consists of calls to the dynamic invocation interface to create an invocation structure, add arguments to the
invocation structure, and to issue the invocation (refer to the Dynamic Invocation Interface chapter for descriptions of these
request forms).
A value is anything that may be a legitimate (actual) parameter in a request. More particularly, a value is an instance of
an OMG IDL data type. There are non-object values, as well as values that reference objects.
An object reference is a value that reliably denotes a particular object. Specifically, an object reference will identify
the same object each time the reference is used in a request (subject to certain pragmatic limits of space and time). An object
may be denoted by multiple, distinct object references.
A request may have parameters that are used to pass data to the target object; it may also have a request context that provides
additional information about the request. A request context is a mapping from strings to strings.
A request causes a service to be performed on behalf of the client. One possible outcome of performing a service is returning
to the client the results, if any, defined for the request.
If an abnormal condition occurs during the performance of a request, an exception is returned. The exception may carry additional
return parameters particular to that exception.
The request parameters are identified by position. A parameter may be an input parameter, an output parameter, or an input-output
parameter. A request may also return a single return result value, as well as the results stored into the output and input-output
parameters.
The following semantics hold for all requests:
• Any aliasing of parameter values is neither guaranteed removed nor guaranteed to be preserved.
• The order in which aliased output parameters are written is not guaranteed.
• The return result and the values stored into the output and input-output parameters are undefined if an exception is returned.
For descriptions of the values and exceptions that are permitted, see Section 1.2.4,
“Types,? on page 1-4 and Section 1.2.8.3, “Exceptions,? on page 1-8.