A common application requirement is to present messages to a channel for processing in an order that is not directly related to the order of their arrival at the prior channel. For example:

• Retail Applications. EDI messages for shipping arrive from the warehouse in random order, and must be dispatched to the appropriate customer record for invoicing.
• Medical Applications. Test results are generated by a lab in the order of processing, but need to be dispatched to the record of a patent as a group (all or none).
• Shipping Applications. Messages must be sent to a remote location in processing order. If the entire message set cannot be created, then none of the messages should be sent.
• Cross-system Message Exchange Application. Sequenced messages are sent across the web to another system. The arrival order at the destination cannot be predicted, and the messages must be processed in a particular sequence that is not related to their arrival time.
• Unordered batches must be processed in a specific order. Incoming messages, perhaps from an iterator over an incoming message, must process portions of a message in a sequence that is different from the defined order of the elements in the original message.

Underlying these types of requirements is a system that receives in some intermixed sequence, is charged with not losing any messages, and desires to process the incoming messages in parallel. Parallelism loses the input ordering. However, single threading has an adverse impact on performance.

The ordered listener is an iWay Service Manager (iSM) channel that alleviates these concerns of parallelism, retaining the required order, and collecting messages for a specific purpose for dispatch to the next channel. Messages can be dispatched as they become available, while retaining the order, or as an ordered group when the final message of the group is recognized. With the exception of the ordering facility, an ordered queue is similar to the commonly used internal queue, and it retains the characteristics of that type of channel. This includes support for low and high watermark tracking, passivation, inhibition, and so on.

It is the responsibility of the application designer to determine the type of queue required and to place messages on the queue appropriately for the application.