|
Notification Server
|
| bet | 4/6 | | Sana | 21.03.2017 | | Hajmi | 133,61 Kb. | | #605 |
Consequences
Network Traffic. Because all registered clients are notified after a change, there may be high network traffic while these clients access information that was probably affected by the change.
Clients’ Responsibility. It is difficult to require all possible clients of a shared resource to use its associated Notification Server(s). Therefore all system parts sharing a resource have to agree to use its Notification Server(s) to coordinate notification of possible resource modifications.
Implementation
Granularity. The application of a Notification Server is not limited for a database as a whole. Instead you could divide your database conceptually into smaller parts that can be handled even as passive resources with their own Notifications Servers. You should try to divide every resource into disjoint parts to avoid additional and sometimes useless notifications. If you are not able to obtain a disjoint division, you have to ensure that clients working with those resources are registered by all Notification Servers of the joint set of resources.
Communication. If your applications are intended to run within a distributed heterogeneous environment, you should decide to apply standards like CORBA and CORBAservices from the Object Management Group (OMG) as much as possible ([OMG94, OMG95, OMG96]).
Notification. It will take some time to inform all registered clients about recent changes if there are many of them registered with the Notification Server. Do not use a synchronous communication model to avoid the blocking of the notifying client or the Notification Server - not only from the client to the Notification Server but also from the Notification Server to the other clients. The Event Notification Service will work best for an asynchronous decoupled communication ([OMG96]).
Callbacks. When you implement the callback mechanism that notifies a client about notifications multicasted by the Notification Server, apply the concepts of the Command2 pattern to construct a simple and flexible client interface ([GHJV94]).
Initial Connection. If a desktop client wants to establish an initial connection to the Notification Server (e.g. for registration purposes), it has to look for it. Here the Naming Service may help by supporting you to access the Notification Server by a symbolic/meaningful name ([OMG96]).
Sharing & Concurrency. A Notification Server is usually shared among many clients. So, if you don’t use the Event Notification Service ([OMG96]) you are responsible for coordinating concurrent access to the shared Notification Server to avoid race conditions. Here you can apply the OMG Concurrency Control Service to serialize access ([OMG96]).
Location. A Notification Server should be located on a reliable system because it must be available as much as the resource server. One solution could be to co-locate Notification Server with its associated resource.
Availability. If a Notification Server goes down for any reason, you should handle the situation. One way to do this is the application of a Strategy ([GHJV94]), where one strategy deals with the normal case - the available Notification Server - and another Strategy addresses that case where no Notification Server is alive, e.g. by polling the database as if there was no Notification Server.
|
| |
