Related Patterns
Observer3 ([GHJV94]): In the context of the Observer pattern the Notification Server would play the role of the Subject and all registered clients are Observers. In opposition to the Observer pattern the subject observed by all clients is not the Notification Server but the shared resource - the database. So there is a separation between the “real” Subject observed and the notification mechanism used to propagate changes. Moreover in the Observer pattern the Subject notifies all Observers about the changes including the Observer that has initiated this notification. This additional notification is not desired in the context of a Notification Server. The Notification Server is different from the Observer pattern both in its structure and behavior.
Publisher-Subscriber4 ([BMRSS96]): Like in the Publisher-Subscriber scenario the Notification Server (the Publisher) publishes events about changes of a shared resource it relates to. All clients (the Subscribers) that are interested in those information registers themselves with the Notification Server. If applied to the Notification Server the Publisher would send unnecessary or even undesired notifications to the Subscribers. The example makes use of the Event Channel as a variation of the Publisher-Subscriber.
Asynchronous Completion Token 5([PHS98]): T.B.D.
Example
The following example was implemented in a CORBA-based environment. It makes use of CORBAservices like Naming and Event Notification ([OMG96]). Here all clients that are working on a shared database notify each other about the changes they made within the database by using the same Notification Server (figure 5). There are synchronous and asynchronous communications between the clients and the Notification Server in both directions. Synchronous communication is used by the client to register with and unregister from the Notification Server and, in certain circumstances, by the Notification Server to instruct a client to unregister. Asynchronous communication is used to propagate change notifications. Notifications from the clients to the Notification Server are concentrated via an event channel, here an n-to-one connection, and will be forwarded to each client by using an event channel as a one-to-one connection. The Notification Server registers itself in the Naming Service, so it can be found and accessed easily by new clients for registration issues.
Figure 5
The following IDL interface descriptions are used for synchronous communication. A client uses the Notification Server via its NotificationServerIF and, in the other direction, the Notification Server can communicate with a client over the NotificationClientIF.
// NotificationServer
// IDL
module NotificationServer {
interface ConstructionInfoIF {
attribute CosEventChannelAdmin::DSTEventChannel channelToNS;
attribute CosEventChannelAdmin::DSTEventChannel channelFromNS;
#pragma class byValue ConstructionInfo
struct byValue { // cOOl :-)
CosEventChannelAdmin::DSTEventChannel channelToNS;
CosEventChannelAdmin::DSTEventChannel channelFromNS;
};
};
interface NotificationServerIF {
readonly attribute string name;
ConstructionInfoIF::byValue registerClient (in NotificationClientIF aNotificationClient);
void unregisterClient (in NotificationClientIF aNotificationClient);
};
interface NotificationClientIF {
readonly attribute string name;
void unregisterFrom (in NotificationServerIF aNotificationServer);
};
};
| 