GB2469695A

GB2469695A - Keeping subscriber applications up-to-date

Info

Publication number: GB2469695A
Application number: GB0909919A
Authority: GB
Inventors: Philip Willoughby; Jonathan Levell
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2009-04-21
Filing date: 2009-06-10
Publication date: 2010-10-27
Also published as: GB0909919D0

Abstract

In a publish/subscribe messaging environment (300), a messaging broker (330) receives a publication from a publishing application. The broker publishes a state message (341) on a topic including new information, wherein the message is a retained publication which is only sent to new subscribers (351) on the topic, and publishes an event message (342) on the topic as a non-retained publication of the difference between the previous and new states, wherein the event message is sent to all existing subscribers (352-354) on the topic. The state message and event message are published within a single unit of work. A new subscriber receives the retained state message and all subsequent event messages. Existing subscribers receive an event message and apply the message difference between previous and new states to the state at the subscriber.

Description

METHOD AND SYSTEM FOR KEEPING

SUBSCRIBER APPLICATIONS UP-TO-DATE

FIELD OF THE NVENTION

This invention relates to the field of publish and subscribe messaging. In particular, the invention relates to keeping subscribing applications up-to-date with state information.

BACKGROUND OF THE INVENTION

In the scenario of one publisher and many subscribers there may be a large amount of state information on a topic, little of which changes with each publication. The challenge is to ensure that the state of all subscribers, including those who have just joined, is kept up-to-date.

If a subscriber is in place before a publisher begins publishing messages, the subscriber application subscribes to a topic, gets a first message which is a state message, sets the state to the state message, gets the next message which is an event message, applies the event message changes, and is ready to receive the next event message.

For late-joining subscribers, the situation causes problems.

In one conventional method, a publisher publishes the entire state in each message as a retained publication. The entire state is in each message, as this may be the first message for at least one subscriber, and the message must be retained so that subscribers who join before the next state is published are aware of what is going on.

This has the disadvantage that in some situations, outbound communications are expensive and therefore it is not feasible to re-send the entire state in each message. For example, communications may be expensive due to reduced battery life, network costs, etc. In another conventional method, the subscriber application is responsible for ensuring it does not apply old changes to new state and for ensuring it has missed no event messages. A lot of application logic is required for late-joining subscribers. In some situations, subscribers cannot communicate with the broker which makes this option untenable.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention there is provided a method for keeping subscriber applications up-to-date in a publishlsubscribe messaging environment, including a messaging system operating on a hardware processor receiving a publication from a publishing application; and comprising the messaging system: publishing a state message on a topic including new state information, wherein the state message is a retained publication which is only sent to new subscribers on the topic; publishing an event message on the topic as a non-retained publication of the difference between the previous and new states, wherein the event message is sent to all existing subscribers on the topic and wherein the state message and event message are published within a single unit of work. Preferably, any of said steps are implemented in either of computer hardware or computer software and embodied in a computer-readable medium.

A new subscriber may receive the retained state message and all subsequent event messages.

Existing subscribers receiving an event message may apply the message difference between previous and new states to the state at the subscriber.

A new subscriber on a topic may follow the steps: subscribe to the topic; get a first message in the form of a retained state message; set the state to the state message; get a next message which is an event message; apply the event message changes; and loop to receive a next event message.

The state message may be marked as retained for new subscribers only.

According to a second aspect of the present invention there is provided a system for keeping subscriber applications up-to-date in a publish/subscribe messaging environment, comprising: a messaging system operable on a hardware processor capable of receiving a publication from a publishing application; the messaging system including a computer-based publishing mechanism for receiving a publication from a publishing application and transforming the publication into: a state message on a topic including new state information, wherein the state message is a retained publication which is only sent to new subscribers on the topic, and an event message on the topic as a non-retained publication of the difference between the previous and new states, wherein the event message is sent to all existing subscribers on the topic, wherein the state message and event message are published within a single unit of work.

A new subscriber application may receive the retained state message and all subsequent event messages. Existing subscriber applications receiving an event message may include a state update mechanism to apply the message difference between previous and new states to the state at the subscriber application.

According to a third aspect of the present invention there is provided a computer program product for keeping subscriber applications up-to-date in a publishlsubscribe messaging environment, the computer program product comprising: a computer-readable storage medium; computer program instructions operative to: publish a state message on a topic including new state information, wherein the state message is a retained publication which is only sent to new subscribers on the topic; publish an event message on the topic as a non-retained publication of the difference between the previous and new states, wherein the event message is sent to all existing subscribers on the topic; wherein the state message and event message are published within a single unit of work; and wherein said program instructions are stored on said computer-readable storage medium.

BRJEF DESCRIPTTON OF THE DRAWINGS

The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, both as to organization and method of operation, together with objects, features, and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanying drawings in which: Figure 1 is a schematic diagram of a publish/subscribe system; Figure 2 is a block diagram of a computer system in which the present invention may be implemented; Figure 3 is a block diagram of a publishlsubscribe system in accordance with the present invention; Figure 4 is a flow diagram of a method of subscribing to a topic in accordance with an aspect of the present invention; and Figure 5 is a flow diagram of a method of publishing a message in accordance with an aspect of the present invention.

It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numbers may be repeated among the figures to indicate corresponding or analogous features.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the present invention.

Publishlsubscribe systems are intended for situations where a single message is required by and is distributed to multiple users. The big advantage over other delivery methods is that publishlsubscribe keeps the publisher separated from the subscriber. This means that the publisher in a publishlsubscribe environment does not need to have any knowledge of either the subscriber's existence or the applications that may use the published information.

Likewise, the subscriber does not need to know anything about the publisher application.

Referring to Figure 1, a publishisubscribe system 100 is shown. One or more publishers 111, 112 publish messages from applications to a broker 130. Subscribers 121, 122 subscribe to some or all of those published messages that are held on the broker 130. The broker 130 matches the publications to the subscribers and ensures that all the messages are made available and delivered to all the subscribers in a timely manner.

Referring to Figure 2, an exemplary system for implementing a system on which publishlsubscribe applications and the broker operate include a data processing system 200 suitable for storing and/or executing program code including at least one processor 201 coupled directly or indirectly to memory elements through a bus system 203. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

The memory elements may include system memory 202 in the form of read only memory (ROM) 204 and random access memory (RAM) 205. A basic input/output system (BIOS) 206 may be stored in ROM 204. System software 207 may be stored in RAM 205 including operating system software 208. Software applications 210 may also be stored in RAM 205.

The system 200 may also include a primary storage means 211 such as a magnetic hard disk drive and secondary storage means 212 such as a magnetic disc drive and an optical disc drive. The drives and their associated computer-readable media provide non-volatile storage of computer-executable instructions, data structures, program modules and other data for the system 200. Software applications may be stored on the primary and secondary storage means 211, 212 as well as the system memory 202.

The computing system 200 may operate in a networked environment using logical connections to one or more remote computers via a network adapter 216.

Input/output devices 213 can be coupled to the system either directly or through intervening I/O controllers. A user may enter commands and information into the system 200 through input devices such as a keyboard, pointing device, or other input devices (for example, microphone, joy stick, game pad, satellite dish, scanner, or the like). Output devices may include speakers, printers, etc. A display device 214 is also connected to system bus 203 via an interface, such as video adapter 215.

By default, a broker discards a publication when it has been sent to all interested subscribers.

However, a publisher can specify that it wants the broker to keep a copy of a publication, which is then called a retained publication. The retained copy can be sent by the broker to subsequent subscribers who register an interest in the topic. This means that new subscribers do not have to wait for information to be published again before they receive it. For example, a subscriber registering a subscription to a stock price would receive the current price immediately, without waiting for the stock price to change (and hence be republished). The broker retains only one publication for each topic and subscription point, so the old publication is deleted when a new one arrives.

In the described method and system, when a new message is published on a topic a new retained message is provided, referred to as a "retained-only" message, which is only sent to new subscribers. Simultaneously, a "difference-only", non-retained message is sent to all existing subscribers.

This allows the retained message on a topic, which is automatically the first message on that topic delivered to new subscribers, to be updated simultaneously with the publication of a latest event message.

No subscriber who receives the retained-only message will receive the concurrent or any previous event messages. However, any subscriber who receives the retained-only message will then receive all subsequent event messages in the form of difference-only messages.

Referring to Figure 3, a publishisubscribe system 300 is shown with a broker 330 with a publication mechanism 331. A new message to be published 340 is converted to a new state message in the form of a retained-only message 341 and a new event message in the form of a difference-only, non-retained message 342.

The retained-only message 341 is sent to any new subscribers 351 on the topic, and the difference-only message 342 is sent to all the existing subscribers 352-354.

The described method and system provide the publisher with an option to retain a publication without publishing it to existing subscribers. The logic for each publication becomes: 1. Begin a unit-of-work; 2. Publish the entire new state as a retained-only publication within that unit-of-work; 3. Publish the difference between previous and new states as a normal publication within that unit-of-work; 4. Commit the unit-of-work.

For an example of the use of this technology, a sports reporting application is considered in which the user is presented with events from a sporting event as they happen, and can scroll back through the events to see how the current situation was reached. The publishing application maintains the complete history of events and has an input for new events, which are typed in by an observer. Each time a new event occurs, the publishing application appends the event to its history, creates a unit of work, publishes the complete history as a retained-only publication, publishes the event as a normal publication, and then commits the unit of work.

The subscribing application has a complete history of events. When it receives a retained publication (immediately after it subscribes), it replaces its history of events with the complete history from that publication. When it receives a non-retained publication (all subsequent publications) it appends the event from that publication to its history of events.

Without this technology, the publishing application would need to publish the complete history of events to all subscribers. Using this technology therefore reduces the amount of information sent to each subscriber as each event occurs to the minimum necessary. If there are many subscribers and a lot of necessary historical data, this will amount to a significant saving in expenditure on network costs.

It is known that application programs can to some extent duplicate this functionality by using multiple topics to distinguish state and event messages and using an application-defined sequencing mechanism to determine whether an event message received after a state message should be added to the subscriber's state or not. The described method is a significant advancement on this known art because it removes both the requirement for multiple topics and the requirement for an application-level sequencing mechanism. This makes the application system much simpler to administrate and much more flexible: new subscribing or publishing applications can be developed and deployed without the need to maintain compatibility with the synchronization protocol.

A second example is that of a security camera publishing images to multiple monitoring stations. If some, hut not all, of the image has changed since the last published image: the publishing application publishes the complete image as a retained-only publication and the region which has changed since the last captured image as a normal publication within the same unit of work. If the entire image has changed (for example because the lights have been turned on or off in the monitored area): the publishing application publishes the complete image as a retained-and-published publication.

The subscribing applications maintain a current image. They replace the current image with any retained publications they receive, and they alter the region which changed when they receive any non-retained publications.

in both of the above examples, the messaging system and application programs use this technology to ensure that all subscribers always have up-to-date information and that no irrelevant information has been sent. The functional requirements of the application are therefore met, and the communications cost of the application is minimized.

Referring to Figure 4, a flow diagram 400 shows the flow of a late-joining subscriber to a topic. A subscriber subscribes 401 to a topic and gets a first message 402 which is a state message in the form of a retained-only message. The state is set 403 from the state message.

The subscriber gets 404 the next message which is an event message in the form of a difference-only, non-retained message. The subscriber applies the event message changes.

This is the same flow as for existing applications where they are guaranteed to subscribe before the publisher begins publishing. This technology therefore lifts a limitation from a class of existing user applications, and allows anyone who was doing it the hard way before to simplir their application code significantly.

This technology is solving the same problem by ensuring that late-joining subscribers receive up-to-date state for the point-in-time that they subscribe and can therefore safely look at the subsequent messages in a stream' when they missed the start.

Referring to Figure 5. a flow diagram 500 shows a flow at a broker when receiving a published message. A message is published 501 and it is determined if the message is to be retained 502, If so, the message is stored as a retained publication for this topic. If not the message is delivered 504 to all subscribers.

if the message is to be retained and the message has been stored 503, it is then determined if the message is marked "retain-only" 504. If not, the message is delivered to all subscribers 504 as it is a standard retained message and not the new type of "retained-only" message which is only sent to new subscribers.

Once the message is delivered 504 or if the message is marked "retain-only' and the message is not delivered, the flow ends 506.

The classic use-case for this form of publish-subscribe scenario is sports scores. The stream of event and state messages might be as follows: Event: State: Kick-off Spurs 0 -Arsenal 0 Arsenal Score Spurs 0 -Arsenal 1 Arsenal Score Spurs 0 -Arsenal 2 Spurs Score Spurs I -Arsenal 2 Spurs Score Spurs 2 -Arsenal 2 Final Whistle Result: Spurs 2 -Arsenal 2 Supposing a subscriber joins around the time of the Spurs first score. If the subscriber gets only one state message and all subsequent event messages, it is important that it processes either the state message from immediately above the row in which Spurs first score and all event messages from the score onwards or the state message from the row in which Spurs first score and all event messages afier the row.

Any other combination means the subscriber will not know the correct score at the end of the game. The described method and system ensures that the subscriber will receive one of these combinations, it can therefore be written more simply and efficiently because it knows it can safely process every message it receives.

The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. The invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus or device.

The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk read only memory (CD-ROM), compact disk read/write (CD-R/W), and DVD.

Improvements and modifications can be made to the foregoing without departing from the scope of the present invention.