Queuing - an Optimal Means of Handling Messages

Messages as the Crux of Business Events

Consider the following application scenario.

The operations of a large bookseller, BooksOnLine, are based on an online book ordering system which automates activities across the various departments involved in the entire sale process.The front end of the system is an order entry application which is used to enter new orders.These incoming orders are processed by an order processing application which validates and records the order. Shipping departments located at regional warehouses are then responsible for ensuring that these orders are shipped in a timely fashion. There are three regional warehouses: one serving the East Region, one serving the West Region, and a third warehouse for shipping International orders. Once an order has been shipped, the order information is routed to a central billing department which handles payment processing.The customer service department, located at its own site, is responsible for maintaining order status and handling inquiries about orders.

This scenario describes an application in which messages come from and are disbursed to multiple clients (nodes) in a distributed computing environment. Messages are not only passed back and forth between clients and servers but are also intricately interleaved between processes on different servers. The integration of the various component applications consist of multi-step processes in which each step is triggered by one or more messages, and which may then give rises to one or more messages.

Using Queues to Coordinate the Interchange of Messages

Business applications communicate with each other by means of such messages. The question is: How is this to be coordinated? BooksOnLine is a single enterprise but, as commerce spreads across the internet, there is an increasing need for applications belonging to different enterprises to communicate. Typically their interchange consists of a message containing data, and a request for action which may be embedded in the data. The problem in a nutshell is that applications within and between enterprises need to function autonomously, but also to process information interdependently.

In queuing systems, producer applications put messages into a queue (enqueue). In the simple case, messages are then retrieved from the same queue by Consumer applications (dequeue). This lets applications can continue with their work after placing a request in the queue because they are not blocked waiting for a reply. It is also allows applications to continue with their work until there is a message to retrieve.

What Queuing Systems Must Provide

Performance

The decoupling of "requests for service" from "supply of services" increases efficiency, and provides the infrastructure for complex scheduling. Further, queueing systems need to exhibit high performance characteristics as might be measured by the following metrics:

• Number of messages enqueued/dequeued per second

• Time to evaluate a complex query on a message warehouse

• Time to recover/restart the messaging process after a failure

Scalability

Queuing systems have to exhibit high scalability. A system should continue to exhibit high performance as the number of programs using the application increase, as the number of messages increase, and as the size of the message warehouse increases.

Persistence for Security

Handling an intricate scheduling of message-passing is not the only challenge. Unfortunately, networks, computing hardware, and software applications will all fail from time to time. For deferred execution to work correctly in the presence of network, machine and application failures, messages that constitute requests for service must be stored persistently, and processed exactly once. In other words, messaging must be persistent.

Being able to preserve messages is fundamental. Applications may have to deal with multiple unprocessed messages arriving simultaneously from external clients or from programs internal to the application, and in such situations they may not have the necessary resources. Similarly, the communication links between databases may not be available all the time or may be reserved for some other purpose. If the system falls short in its capacity to deal with these messages immediately, the application must be able to store the messages until they can be processed. By the same token, external clients or internal programs may not be ready to receive messages that have been processed.

Persistence for Scheduling

Queuing systems need message persistence so they can deal with priorities: messages arriving later may be of higher priority than messages arriving earlier; messages arriving earlier may have to wait for messages arriving later before actions are executed; the same message may have to be accessed by different processes; and so on. Such priorities may not be fixed. One crucial dimension of handling the dynamic aspect of message persistence has to do with windows of opportunity that grow and shrink.It may be that messages in a specific queue become more important than messages in other queues, and so need to be processed with less delay or interference from messages in other queues. Similarly, it may be more pressing to send messages to some destinations than to others.

Persistence for Accessing and Analyzing Metadata

Finally, message persistence is crucial because the control component of the message can be as important as the payload data. For instance, the time that messages are received or dispatched can be a crucial part of the message. Often it will constitute the legal interface for a transaction. Legal issues aside, the message will often retain importance as a business asset after it has been executed.For instance, it may be central to analyzing periods of greatest demand, or for evaluating the lag between receiving and completing an order. Given these requirements, tracking and documentation should be the responsibility of the messaging system, not the developer.