Browse Prior Art Database

Preservation of affinity whilst routing messages through multi-partition messaging systems

IP.com Disclosure Number: IPCOM000240672D
Publication Date: 2015-Feb-17
Document File: 2 page(s) / 51K

Publishing Venue

The IP.com Prior Art Database

Abstract

A system to preserve affinity and relative ordering of messages in a horizontally scaled, partitioned messaging system that supports multiple parallel message producers and multiple parallel message consumers.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.

Page 01 of 2

Preservation of affinity whilst routing messages through multi-partition messaging systems

Disclosed is a system that is able to preserve affinity and relative ordering of messages in a horizontally scaled, partitioned messaging system.

    A message producer is an application that sends messages for some business purpose. A message consumer is an application that receives messages and is typically the implementation of the business process. A messaging server is an intermediary that provides routing and management of message traffic, providing facilities such as reliable delivery, persistence and recoverability.

    A messaging server may be horizontally scaled in order to support the workload associated with multiple message producers operating in parallel, and multiple message consumers also operating in parallel. To support the associated throughput and capacity, the messaging server may be 'partitioned' such that message routing and storage are striped across a number of physical or virtual servers. A message producer connected to a server partitioned in this way may need to send a stream of messages that are related to one another, and require that the related messages are all delivered to one of the parallel consumers. A typical scenario is that the consumers are parallel instances of a business service that performs operations based on the received messages. Furthermore in such a scenario, it is frequently necessary or desirable that the related messages are delivered to one consuming instance and arrive in the order that they were sent.

    As a concrete example, consider a stream of messages relating to a purchase order; the first message creates the order including customer details; the subsequent messages modify the order by adding or removing items, and the final message executes the order. It is important that the messages are all processed, preferably by one instance of the business service, in the order that they were sent.

    A further example is a dealing system in which receipt of a first message will create a business object (e.g. a dealing instruction), second and subsequent messages will modify the instruction (e.g. adding or removing instruments or modifying quantities) and receipt of a final message will trigger execution of the instruction. It is essential that these messages and the operations they perform are processed in the correct order, and they should all be routed to one particular execution engine (message consumer). There are other examples where it is desirable for all messages within a set or stream to be delivered to the same business service instance - e.g. for workload management or performance (e.g. cache hit maximisation), or for reasons of governance, audit or problem determination.

    It is well-known in the design of messaging systems that related messages may need to be grouped. A message group is a finite set of messages that must be delivered together as a unit and optionally to be delivered in the s...