1.2.8 Operations

   An operation is an identifiable entity that denotes the indivisible primitive of service provision that can be requested. The act of requesting an operation is referred to as invoking the operation. An operation is identified by an operation identifier.

   An operation has a signature that describes the legitimate values of request parameters and returned results. In particular, a signature consists of:

• A specification of the parameters required in requests for that operation.

• A specification of the result of the operation.

• An identification of the user exceptions that may be raised by an invocation of the operation.

• A specification of additional contextual information that may affect the invocation.

• An indication of the execution semantics the client should expect from an invocation of the operation.

   Operations are (potentially) generic, meaning that a single operation can be uniformly invoked on objects with different implementations, possibly resulting in observably different behavior. Genericity is achieved in this model via interface inheritance in IDL and the total decoupling of implementation from interface specification.

   The general form for an operation signature is:

   [oneway] <op_type_spec> <identifier> (param1, ..., paramL) [raises(except1,...,exceptN)] [context(name1, ..., nameM)]

   where:

• The optional oneway keyword indicates that best-effort semantics are expected of requests for this operation; the default semantics are exactly-once if the operation successfully returns results or at-most-once if an exception is returned.

•The <op_type_spec> is the type of the return result.

•The <identifier> provides a name for the operation in the interface.

• The operation parameters needed for the operation; they are flagged with the modifiers in, out, or inout to indicate the direction in which the information flows (with respect to the object performing the request).

• The optional raises expression indicates which user-defined exceptions can be signaled to terminate an invocation of this operation; if such an expression is not provided, no user-defined exceptions will be signaled.

• The optional context expression indicates which request context information will be available to the object implementation; no other contextual information is required to be transported with the request.

   1.2.8.1 Parameters

   A parameter is characterized by its mode and its type. The mode indicates whether the value should be passed from client to server (in), from server to client (out), or both (inout). The parameter’s type constrains the possible value, which may be passed in the directions dictated by the mode.

   1.2.8.2 Return Result

   The return result is a distinguished out parameter.

   1.2.8.3 Exceptions

   An exception is an indication that an operation request was not performed successfully. An exception may be accompanied by additional, exception-specific information.

   The additional, exception-specific information is a specialized form of record. As a record, it may consist of any of the types described in Section 1.2.4, “Types,? on page 1-4.

   All signatures implicitly include the system exceptions; the standard system exceptions are described in Section 4.12.2, “System Exceptions,? on page 4-64.

   1.2.8.4 Contexts

   A request context provides additional, operation-specific information that may affect the performance of a request.

   1.2.8.5 Execution Semantics

   Two styles of execution semantics are defined by the object model:

• At-most-once: if an operation request returns successfully, it was performed exactly once; if it returns an exception indication, it was performed at-most-once.

• Best-effort: a best-effort operation is a request-only operation (i.e., it cannot return any results and the requester never synchronizes with the completion, if any, of the request).

   The execution semantics to be expected is associated with an operation. This prevents a client and object implementation from assuming different execution semantics.

   Note that a client is able to invoke an at-most-once operation in a synchronous or deferred-synchronous manner.