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.