#include <Reply_Dispatcher.h>
Inheritance diagram for TAO_Reply_Dispatcher:
Public Methods | |
TAO_Reply_Dispatcher (void) | |
Constructor. More... | |
virtual | ~TAO_Reply_Dispatcher (void) |
Destructor. More... | |
virtual int | dispatch_reply (TAO_Pluggable_Reply_Params ¶ms)=0 |
Dispatch the reply. More... | |
CORBA::ULong | reply_status (void) const |
Get the reply status. More... | |
virtual void | connection_closed (void)=0 |
The used for the pending reply has been closed. More... | |
Protected Attributes | |
CORBA::ULong | reply_status_ |
Reply or LocateReply status. More... |
Traditional synchronous replies simply receive the message and wake up the waiting thread (if any). Asynchronous Method Invocation (Callbacks) must process the message in the thread that receives it. Deferred Synchronous (DII) and AMI in the Poller mode save the reply for later processing in the application. The lower level components in the ORB only deal with this abstract interface, when the invocation is made the right type of Reply Dispatcher is instantiated and registered with the Transport object.
|
Constructor.
|
|
Destructor.
|
|
The used for the pending reply has been closed. No reply is expected. @ TODO: If the connection was closed due to a CloseConnection message then we could re-issue the request instead of raising the exception, it would a matter of simply adding a boolean argument to this function. Reimplemented in TAO_Asynch_Reply_Dispatcher_Base, and TAO_Synch_Reply_Dispatcher. |
|
Dispatch the reply. Return 1 on sucess, -1 on error. @ TODO Pluggable Messaging: this method has too many arguments, the "Right Thing"[tm] is for the Transport Object to create a "ClientReply" that encapsulates all we need to process a reply. Naturally it is possible that different messaging protocols implement different variants of such ClientReply class. Reimplemented in TAO_Asynch_Reply_Dispatcher_Base, and TAO_Synch_Reply_Dispatcher. |
|
Get the reply status.
|
|
Reply or LocateReply status.
|