Previous Table of Contents Next


7.2.1 create_request


   Because it creates a pseudo-object, this operation is defined in the Object interface (see Section 4.3, “Object Reference Operations,? on page 4-12 for the complete interface definition). The create_request operation is performed on the Object that is to be invoked.

   module CORBA{

   interface Object{ // PIDL . . . . .

   void create_request ( in Context ctx, // context object for operation in Identifier operation, // intended operation on object

in NVList

arg_list,

// args to operation

inout NamedValue result, // operation result
out Request req, // newly created request
in Flags req_flags // request flags
);
};
};

   This operation creates an ORB request. The actual invocation occurs by calling invoke or by using the send / get_response calls.

   The operation name specified on create_request is the same operation identifier that is specified in the OMG IDL definition for this operation. In the case of attributes, it is the name as constructed following the rules specified in the ServerRequest interface as described in the DSI in Section 8.3, “ServerRequestPseudo-Object,? on page 8-3.

   The arg_list, if specified, contains a list of arguments (input, output, and/or input/output) that become associated with the request. If arg_list is omitted (specified as NULL), the arguments (if any) must be specified using the add_arg call below.

   Arguments may be associated with a request by passing in an argument list or by using repetitive calls to add_arg. One mechanism or the other may be used for supplying arguments to a given request; a mixture of the two approaches is not supported.

   If specified, the arg_list becomes associated with the request; until the invoke call has completed (or the request has been deleted), the ORB assumes that arg_list (and any values it points to) remains unchanged.

   When specifying an argument list, the value and len for each argument must be specified. An argument’s datatype, name, and usage flags (i.e., in, out, inout) may also be specified; if so indicated, arguments are validated for data type, order, name, and usage correctness against the set of arguments expected for the indicated operation.

   An implementation of the request services may relax the order constraint (and allow arguments to be specified out of order) by doing ordering based upon argument name.

   The context properties associated with the operation are passed to the object implementation. The object implementation may not modify the context information passed to it.

   The operation result is placed in the result argument after the invocation completes.

   The req_flags argument is defined as a bitmask (long) that may contain the following flag values: CORBA::OUT_LIST_MEMORY indicates that any out-arg memory is associated with the argument list (NVList).

   Setting the OUT_LIST_MEMORY flag controls the memory allocation mechanism for out-arg memory (output arguments, for which memory is dynamically allocated). If OUT_LIST_MEMORY is specified, an argument list must also have been specified on the create_request call. When output arguments of this type are allocated, they are associated with the list structure. When the list structure is freed (see below), any associated out-arg memory is also freed.

   If OUT_LIST_MEMORY is not specified, then each piece of out-arg memory remains available until the programmer explicitly frees it with procedures provided by the language mappings (see the C Language Mapping specification, Argument Passing Considerations section; C++ Language Mapping specification, NVList section; and the COBOL Language Mapping specification, Argument Passing Considerations section).

   The implicit object reference operations non_existent, is_a, and get_interface may be invoked using DII. No other implicit object reference operations may be invoked via DII.

   To create a request for any one of these allowed implicit object reference operations, create_request must be passed the name of the operation with a “_? prepended, in the parameter “operation.? For example to create a DII request for “is_a?, the name passed to create_request must be “_is_a.? If the name of an implicit operation that is not invocable through DII is passed to create_request with a “_? prepended, create_request shall raise a BAD_PARAM standard system exception with the standard minor code 32. For example, if “_is_equivalent? is passed to create_request as the “operation? parameter will cause create_request to raise the BAD_PARAM standard system exception with the standard minor code 32.