Publish and subscribe data processing with failover using...

Details Publish and subscribe data processing with failover using... Publish and subscribe data processing with failover using...

1998-12-29

2001-10-02

Beausoleil, Robert (Department: 2181)

Error detection/correction and fault detection/recovery

Data processing system error or fault handling

Reliability and availability

C714S040000, C709S223000, C709S231000, C707S793000

Reexamination Certificate

active

06298455

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to the field of data processing and more specifically to data processing which distributes messages from suppliers (called, hereinafter, “publishers”) of data messages to consumers (called, hereinafter “subscribers”) of such messages.
BACKGROUND OF THE INVENTION
Publish/subscribe data processing systems have become very popular in recent years as a way of distributing data messages from publishing computers to subscribing computers. The increasing popularity of the Internet, which has connected a wide variety of computers all over the world, has helped to make such publish/subscribe systems even more popular. Using the Internet, a World Wide Web browser application (the term “application” or “process” refers to a software program, or portion thereof, running on a computer) can be used in conjunction with the publisher or subscriber in order to graphically display messages. Such systems are especially useful where data supplied by a publisher is constantly changing and a large number of subscribers needs to be quickly updated with the latest data. Perhaps the best example of where this is useful is in the distribution of stock market data.
In such systems, publisher applications of data messages do not need to know the identity or location of the subscriber applications which will receive the messages. The publishers need only connect to a publish/subscribe distribution agent process, which is included in a group of such processes making up a broker network, and send messages to the distribution agent process, specifying the subject of the message to the distribution agent process. The distribution agent process then distributes the published messages to subscriber applications which have previously indicated to the broker network that they would like to receive data messages on particular subjects. Thus, the subscribers also do not need to know the identity or location of the publishers. The subscribers need only connect to a distribution agent process.
One such publish/subscribe broker network which is currently in use, and which has been developed by the Transarc Corp. (a wholly owned subsidiary of the assignee of the present patent application, IBM Corp.) is shown in FIG.
1
. Publishers
11
and
12
connect to the publish/subscribe broker network
2
and send published messages to broker network
2
which distributes the messages to subscribers
31
,
32
,
33
,
34
. Publishers
11
and
12
, which are data processing applications which output data messages, connect to broker network
2
using the well known inter-application data connection protocol known as remote procedure call (or RPC). Each publisher application could be running on a separate machine, alternatively, a single machine could be running a plurality of publisher applications. The broker network
2
is made up of a plurality of distribution agents (
21
through
27
, which will also be referred to herein as “brokers”) which are connected in a hierarchical fashion which will be described below as a “tree structure”. These distribution agents, each of which could be running on a separate machine, are data processing applications which distribute data messages through the broker network
2
from publishers to subscribers. Subscriber applications
31
,
32
,
33
and
34
connect to the broker network
2
via RPC in order to receive published messages.
Publishers
11
and
12
first connect via RPC directly to a root distribution agent
21
which in turn connects via RPC to second level distribution agents
22
and
23
which in turn connect via RPC to third level distribution agents
24
,
25
,
26
and
27
(also known as “leaf distribution agents” since they are the final distribution agents in the tree structure). Each distribution agent could be running on its own machine, or alternatively, groups of distribution agents could be running on the same machine. The leaf distribution agents connect via RPC to subscriber applications
31
through
34
, each of which could be running on its own machine.
In order to allow the broker network
2
to determine which published messages should be sent to which subscribers, publishers provide the root distribution agent
21
with the name of a distribution stream for each published message. A distribution stream (called hereinafter a “stream”) is an ordered sequence of messages having a name (e.g., “stock” for a stream of stock market quotes) to distinguish the stream from other streams. Likewise, subscribers provide the leaf distribution agents
31
through
34
with the name of the streams to which they would like to subscribe. In this way, the broker network
2
keeps track of which subscribers are interested in which streams so that when publishers publish messages to such streams, the messages can be distributed to the corresponding subscribers. Subscribers are also allowed to provide filter expressions to the broker in order to limit the messages which will be received on a particular stream (e.g., a subscriber
31
interested in only IBM stock quotes could subscribe to the stream “stock” by making an RPC call to leaf distribution agent
24
and include a filter expression stating that only messages on the “stock” stream relating to IBM stock should be sent to subscriber
31
).
The above-described publish/subscribe broker network architecture provides the advantage of central coordination of all published messages, since all publishers must connect to the same distribution agent (the root) in order to publish a message to the broker network hierarchy. For example, total ordering of published messages throughout the broker hierarchy is greatly facilitated, since the root can easily assign sequence numbers to each published message on a stream.
Total ordering allows something called “failover” to be carried out. In failover, should a first distribution agent (e.g.,
22
) fail for any reason (e.g., a power loss due to a local thunderstorm) other distribution agents (e.g.,
24
and
25
) which communicate directly with this first distribution agent will instead transfer their subscriptions to (failover to) a second distribution agent (e.g.,
23
) which is a sibling of the first distribution agent (e.g.,
22
. The totally ordered stream feature allows distribution agents
24
and
25
to make an historic re-subscription to distribution agent
23
so as to pick up where they left off before the failure in terms of receiving published messages on the streams to which they have subscriptions. Specifically, in an historic resubscriptions, distribution agent
24
would make a subscription request to distribution agent
23
asking for all future published messages on a stream as well as all past messages back to the particular sequence number (provided with the historic resubscriptions request) of the last message that distribution agent
24
received on the stream from distribution agent
22
before distribution agent
22
failed. This ensures the distribution agent
24
receives all published messages on the stream despite the fact that distribution agent
22
has failed.
However, this
FIG. 1
architecture also has the disadvantage of publisher inflexibility, since each publisher is constrained to publishing from the single root distribution agent, even when it would be much easier for a publisher to connect to a closer distribution agent. Accordingly, publish/subscribe software designers are beginning to consider architectures where publishers are allowed to publish messages directly to any distribution agent in the broker network. This clearly has the advantage of removing the above-mentioned constraint on publishers. However, as with any tradeoff, it presents other problems. For example, providing total ordering of published messages on a stream is very difficult, since there is no longer a central distribution agent (broker) from which all publishers must publish. In other words, the central coordination at the root that was present in the above-mentioned root-based architecture and that made failover so straight

Affiliated with

Also associated with

Rating

Publish and subscribe data processing with failover using... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Publish and subscribe data processing with failover using..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Publish and subscribe data processing with failover using... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2556553