Architecture of the Notification Classes
The implementation of a notification operation requires the client to take on additional functionality that is more typically server-like, while the server must take on additional functionality that is more typically client-like. The client must now have the ability to listen for an incoming message; the server, on the other hand, must be able to initiate a message.
In this way, notification blurs the traditional distinction between a client and a server. Clients become servers; servers become clients.
The following two diagrams illustrate the architecture of the generated client and server-side notification code.
Figure 5 – Architecture of the generated client-side notification classes
At the top of the figure are the general client-side classes that are always generated for any message pattern. Below are the notification-specific classes. Note that the notification classes look like server-side classes, yet they are for use on the client. These classes give the client the required functionality to set up a listener to receive notification.
Additionally, two specialized configuration files are generated:
client-handlers.xml, the configuration file for chaining message handlers on the client. These are the message handlers for incoming notification messages. (For clients without services, this file is still generated but contains only a logger.)client-objects.xml, the configuration file for named objects used on the server side. This file is required for notification in order to set up a listener on the client side. For information on how to configure and use named objects, see Chapter 16, Named Objects.The server-side architecture looks like this:
Figure 6 – Architecture of the generated server-side notification classes 
At the top of the figure are the classes normally generated on the server side. Below is a special NotificationProxy class that is used to send a message to the client. No special configuration files are required on the server side.
