next up previous contents
Next: Example Up: Structural Patterns Previous: MethodInvoker

   
Dispatcher


  
Figure 2.3: Architecture of Dispatcher
\begin{figure}
\center{\epsfig{file=./figs/Dispatcher.eps,width=.8\textwidth} }
\end{figure}

A Dispatcher maintains a number of channels and allows clients to join one or more of those channels, and send and receive messages to/from channels. When an object joins a channel (given the channel name), it will be dispatched all messages received on that channel in the form of method invocations. Note that in order to receive all messages, an object should implement the methods required by the group (application-specific). It may itself invoke methods on all members of the channel (a channel is nothing else than a group !).

Note that an object that has not previously called Join() is nevertheless able to send messages to the group members and receive responses, but requests dispatched to the group members will not be dispatched to it.

The Dispatcher class is a replacement for classes RemoteMethodCall (client side) and MethodInvoker (server side). Instead of using 2 classes, client-server applications can more conveniently be written using the dispatcher. Its main advantage is that, instead of assuming 1 client and 1 server, it allows multiple clients to issue requests and register to get their methods invoked. In one line, the dispatcher is a more sophisticated class offering the combined interfaces of both RemoteMethodCall and MethodInvoker and allows multiple objects to be registered.

The architecture of the Dispatcher is shown in fig. 2.3. A hashtable maintains a name and a channel entry (ChannelEntry) for each channel created in the dispatcher. Clients wishing to send messages have to specify which channel to use (by giving its name).

A client does not have to explicitly have to create a new channel, may may just call the dispatcher's Join method. When the channel already exists, the caller will be added to the channel's object list, otherwise a new channel will be created (ChannelEntry) and added to the dispatcher's hashtable with the channel's name as key.

A ChannelEntry consists essentialy of a channel, a PullPushAdapter, a MessageCorrelator and a MethodInvoker. Sending a message using the dispatcher involves the following steps: first ChannelEntry corresponding to the name given in the call is received. Then a Message is created and registered with the MessageCorrelator instance under its message ID. Subsequently the message is sent (1), using the channel as transport. Finally, the result (or results) is retrieved using the MessageCorrelator (2).

The previous description applies to a caller in the client role. The server role process is as follows: when a message is received by the PullPushAdapter, it is will be forwarded either to the MessageCorrelator if it is a response, or to the MethodInvoker if the message is a request.2.5 The case of a response was treated above (2), when a request is received (3), the method invoker constructs a MethodCall and applies it to all of the target objects listening to that channel in turn. The return values are sent back using the channel (4).



 
next up previous contents
Next: Example Up: Structural Patterns Previous: MethodInvoker
Bela Ban
1998-08-06