Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Subscribe now for rapid prototyping

The Publisher-Subscriber pattern reduces object dependencies for flexible UI design

By Kurt Jacobs, JavaWorld.com, 11/09/01

Frequent requirement changes during a software development cycle can often lead to disruption and anxiety. Software team members scramble to update their API to accommodate new requirements. As a solution, the Publisher-Subscriber pattern can be instrumental in reducing object dependencies; thereby reducing the need for frequent API changes. In addition, the pattern proves useful when used for rapid prototyping. In this article, I show you how this versatile development tool can simplify your programming tasks again and again.

Benefits of a Publisher-Subscriber implementation

You can realize the following benefits by utilizing the Publisher-Subscriber pattern:

• A publisher can publish events to 1-N subscribers. You can easily implement systems that contain more than one object that requires the same information.
• Objects communicate with each other indirectly through domain-specific events so object dependencies are reduced or eliminated.
• You can add new objects to a system with minimal impact because the API need not change. This characteristic accommodates systems with frequent requirement changes.
• Objects have location transparency. Objects that receive events do not have to know the event's origin. Conversely, an object can make a request via a publisher without concern for where the object carrying out the request exists.

What is the Publisher-Subscriber pattern?

The Publisher-Subscriber pattern is modeled after the publisher-subscriber relationship that exists between a consumer and a periodical publisher. In the Publisher-Subscriber pattern there are publisher and subscriber objects. Publishers are also referred to as senders, observables, subjects, broadcasters, or notifiers. The publisher object maintains a list of subscribers and notifies each subscriber when a state change occurs in an object of interest to that subscriber. A publisher has one to many relationships with subscribers. Although a system may contain one or more publishers, each publisher in all likelihood has many subscribers. For example, a system that publishes weather conditions can have several subscribers at any one time.

Subscribers are also referred to as receivers, listeners, observers, or callbacks. A subscriber registers to receive updates from a publisher by calling a publisher, providing a reference to itself for future callbacks and a parameter that indicates for what object the subscriber wants updates. After registering with a publisher, the subscriber receives unsolicited updates from a publisher whenever its monitored object experiences a state change. When you use a Publisher-Subscriber implementation to facilitate a communication framework, the subscriber is notified each time the event type for which it has registered is published.

The subscriber continues to receive updates until it terminates the subscription. This type of subscription is called a push subscription because data is sent to the subscriber without the client requesting each delivery. Each subscriber may want to monitor more than one object or receive more than one event type notification. For example, an online trading application may contain an object that subscribes to several different market data event types for a particular stock symbol. This online trading object may subscribe to events pertaining to the volume transacted for a specific stock symbol or to events relating to each trade for that symbol during any given day. At any time, a subscriber may unsubscribe to all updates without affecting other objects in the system.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.