Section B.1. The Publish-Subscribe Design Pattern

B.1. The Publish-Subscribe Design Pattern

The solution to the problems just listed is to design around them using what is known as the publish-subscribe design pattern. The idea behind the pattern is a simple one: decouple the publishers from the subscribers by introducing a dedicated subscription service and a dedicated publishing service in between, as shown in Figure B-1.

Figure B-1. A publish-subscribe system

Subscribers that want to subscribe to events register with the subscription service, which manages the lists of subscribers, and also provides a similar ability to unsubscribe. Similarly, all publishers use the publisher service to fire their events, and avoid delivering the events directly to the subscribers. The subscription and publishing services provide a layer of indirection that decouples your system. No longer do the subscribers have any knowledge about the identity of the publishers. They can subscribe to a type of an event, and will receive the event from any publisher, and the subscription mechanism is uniform across all publishers. In fact, no publisher has to manage any subscription list, and the publishers have no idea who the subscribers are. They deliver the event to the publishing service to be delivered to any interested subscriber.

B.1.1. Subscriber Types

You can even define two types of subscribers: transient subscribers are in-memory running subscribers, and persistent subscribers are subscribers that persist on the disk, representing services to invoke when the event takes place. For transient subscribers, you can use the duplex callback mechanism as a handy way of passing the callback reference to the running service. For the persistent subscribers, all you really need to record is the subscriber address as a reference. When the event is raised, the publishing service will call to the persistent subscriber address and deliver the event to it. Another important distinction between the two types of subscriptions is that you can store the persistent subscription on the disk or in a database. Doing so will persist the subscription across application shutdowns or machine crashes and reboots, thus enabling administrative configuration of the subscriptions. Obviously, you cannot save the transient subscription across an application shutdown, and you will need to set up the transient subscription explicitly every time the application starts.