A participant wants to retrieve information from another participant.
How can one participant receive information from another participant if that information cannot easily be packaged into a single message?
The interested participant, or Subscriber, initiates a Subscribe-Notify conversation by sending a message to the Provider that expresses its interest in data the Provider can supply. The Provider subsequently keeps sending notification messages to the Subscriber until a stop condition is reached.
The Subscribe-Notify conversation involves the following participants:
Subscribe-Notify requires the originator, i.e. the Subscriber to receive inbound messages, which can be a challenge in situations where it sits behind a firewall that allows only outbound connections. In such cases, the conversation has to fall back to the initiator using Polling.
Subscribe-Notify makes more efficient use of network resources than Polling. Even if the Subscriber knows the appropriate interval to poll, Subscribe-Notify transmits only half as many messages as a repeated Request-Response, ignoring administrative messages, such as Lease or Renewal Reminder.
Subscribe-Notify is particularly efficient if the Subscriber cannot judge the interval at which interesting events occur, or if this frequency varies widely. As long as no noteworthy events occur, no messages have to be sent.
Subscribe-Notify forces the Subscriber to wait for an update rather than to actively request a status. For slow-changing data streams, new subscribers may want to request the current state immediately instead of waiting for the next regular update. For this purpose, the Subscribe message may be acknowledged with an immediate Notify message to the new subscriber.
Most systems establish an ontology to express interest in specific topics and subtopics, as described in Publish-Subscribe Channel
The Provider may acknowledge the subscription immediately using a Quick Acknowledgment. Some Providers may also provide a list of active subscriptions to the Subscriber.
The Subscribe-Notify conversation does not have a natural stopping point -- notification messages could continue indefinitely. Therefore, a stopping condition is needed. Typical stopping conditions are:
Example: Streaming Results from a Long-running QueryWhen an application invokes a query that takes a long time to process, some of the results may be available before the query completes. In this case, the provider can start sending partial results before the whole operation completes. The client can start processing the result data sooner, possible providing a better user experience. This approach does not work well if a global operation such as sorting is required, unless of course the data that is fetched is already in the desired order, for example because the database has a clustered index on the data. NoSQL column data stored tend to cluster by the primary key as they use it to distribute data across nodes and because their data sets tend to be too large for global sorts. Therefore, using Subscribe-Notify to retrieve data incrementally works particularly well.
Example: Stock Ticker SubscriptionA service may want to receive frequent updates to the price of a traded security. Instead of repeatedly polling, the service should subscribe and receive the price updates as Fire-and-Forget messages.
Example: WS-EventingDifferent approaches: WS-Eventing uses single URL, not meant for pub-sub topics. WS-Notification more complex, includes topic hierarchy.
Related patterns: Lease, Polling, Publish-Subscribe Channel, Quick Acknowledgment, Renewal Reminder
Want to keep up-to-date? Follow My Blog.
Want to read more in depth? Check out My Articles.
Want to see me live? See where I am speaking next.
|© 2003, 2019 • All rights reserved.|