Message Queuing - Publish and Subscribe
OpenQueue provides a publish and subscribe
architecture. Users (either
people or applications) subscribe to particular topics hosted on an
OpenQueue server. If a user is connected to the server with a client
program, any new messages published to topics the user has subscribed to
are sent to the client. If the client disconnects for some time, then
reconnects, the server will send the client any messages the client may
have missed.
This allows systems to operate with great flexibility. For example,
suppose an web-based store accepts orders on a web page and then sends the
orders on to a distribution center, using XML to describe the orders. The
store doesn't want to make web users wait for the distant distribution
center's inventory application to process the order. The solution is for
the web application to send a message to an OpenQueue topic to store these
orders, and then to return immediately to the web user. Then the
inventory application can receive the order messages from the
OpenQueue server, and process them as it gets to them.
By adding the intermediate step of storing
orders in the OpenQueue server, we achieve several benefits. First, the
web page and the inventory app can both work at their optimal rates. The
web page can handle a sudden burst of orders, because it only has to drop
the message into OpenQueue. The inventory app can plod along at a
leisurely pace, since the orders are all safely stored in the OpenQueue
server for it.
Second, the system still works if one of the apps is down. Let's say the
inventory app is offline because of a bad hard disk. While that machine
is being repaired, the web page can continue to process orders and put
them into the queue on the OpenQueue server. When the inventory app goes
online again, it connects to the OpenQueue server and picks up where it
left off. No orders are lost.
Third, it allows business logic to be organized better. Suppose each
order message actually needs to be seen by the distribution center (as
mentioned), the accounts receivable department (for billing), and the
customer service
department (for thank you notes, etc.). The web page doesn't need to know
all that; it just needs to publish the new order to the Orders topic, and
all interested applications, from all of those departments, can subscribe
to that topic as needed. When a new app needs to start subscribing to the
topic, the web page doesn't need to be changed.
Back to OpenQueue's home
page.