| Previous | Table of Contents | Next |
22.14.2.1 ReplyHandler
The ReplyHandler interface is a base interface for all specific ReplyHandlers (either type-specific or Generic ones). It
is used as the generic reply_destination argument when a request is sent to a Router:
22.14.2.2 Router
The Router interface is used to pass messages when a request cannot be synchronously invoked on its final target.
22.14.2.3 send_request
The Router is passed all the information necessary to either route the request toward the target by calling send_request on
another Router, or to invoke the request on its final target.
22.14.2.4 send_multiple_requests
The Router is passed a sequence of RequestInfo structures, where each RequestInfo is a completely self-contained set of information
allowing the Router to either route the request toward the target by calling send_request on another Router, or to invoke
the request on its final target.
22.14.2.5 UntypedReplyHandler
This interface is the target of replies when the polling model is used.
22.14.2.6 reply
The reply operation is invoked when the reply to a PersistentRequest becomes available. The operation is invoked with the
following arguments:
• operation_name - The string name of the original request operation. This is necessary if the untyped reply must be turned
into a callback on a typed ReplyHandler (as is the case if the polling client has switched models after making the request
and associated a ReplyHandler with its Poller).
• reply_type - The status of the Reply (either NO__EXCEPTION, USER_EXCEPTION, or SYSTEM_EXCEPTION). LOCATION_FORWARD replies are not invoked on the ReplyHandler.
• reply_body - The marshaled data of the reply along with the byte order with which it was marshaled.
22.14.2.7 PersistentRequest
Instances of this interface are created by the Client Router for polling model invocations, and is queried to obtain the status
of a request, including the reply’s data if available.
22.14.2.8 readonly attribute reply_available
Returns the value TRUE if and only if the reply is currently available and has not yet been returned to some caller of get_reply.
Returns the value FALSE if and only if the reply has not yet been returned to the ClientRouter. This attribute cannot be checked
if the response has already been delivered to some caller of get_reply, as the PersistentRequest instance will have been deactivated
at that time and the ORB will return the system exception OBJECT_NOT_EXIST on any subsequent invocations on that PersistentRequest.
22.14.2.9 get_reply
The get_reply operation is invoked to poll or block for a reply to a PersistentRequest. The operation returns the status of
the reply (either NO_EXCEPTION, USER_EXCEPTION, or SYSTEM_EXCEPTION) or raises the ReplyNotAvailable exception if no reply
is obtained before the specified timeout occurs. If the response is returned to the caller, the PersistentRequest is deactivated
so that future invocations of get_reply raise the system exception OBJECT_NOT_EXIST. The operation takes the following arguments:
• blocking -if set, the operation does not return until either a reply can be returned or the PersistentRequest becomes invalid (due to an expired time-to-live).
• timeout - ignored if blocking is TRUE. Otherwise, the request blocks for the specified number of seconds or until a reply is available. If no reply becomes available after the specified timeout has expired, the ReplyNotAvailable exception is raised.
• reply_body - the data of the reply as originally marshaled by the target.
22.14.2.10 attribute associated_handler
The possibly nil ReplyHandler reference of the type-specific ReplyHandler registered to receive a callback reply for this
request. This attribute is initially nil if the PersistentRequest was created for a polling client, and becomes non-nil if
the client decides to switch from the polling model to the callback model.
22.14.2.11 PersistentRequestRouter
This interface is used by the messaging-aware client ORB to create a request that can be queried to obtain its status and
reply data (e.g., using the polling model).
22.14.2.12 create_persistent_request
When a PersistentRequest is created for a message, no reply destination is supplied. Instead, the PersistentRequestRouter
establishes itself as the reply destination and returns to the caller a reference that has operations for obtaining the status
and reply for the request. The operation that returns this new PersistentRequest takes the following arguments:
• profile_index -the index of the profile in the target IOR that is being used for this request. This is necessary so the target router can choose the correct object key when composing the final GIOP request.
• to_visit - the suggested sequence of Routers to which the message should be sent if the target is not available. This sequence may be modified as the request is sent from Router to Router.
• target - the full IOR of this message’s target.
• selected_qos - the list of QoS that was selected for this message.
• message - the payload (arguments, return value, raised exception) for this message.