Messaging Identifier Uniqueness via Connection ID Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In messaging systems like WebSphere MQ, the existing methods for generating unique message identifiers lead to clashes with correlation identifiers, making it difficult for third parties to correlate identifiers with specific application instances, and the generated identifiers are not visible outside the connection issuing the calls.
Innovation Solution
A method where the Connection Identifier (ConnId) is used as both a Correlation Identifier and a Message Identifier from the same name space, ensuring uniqueness and allowing third parties to track messages using either identifier, with the ConnId being generated using a clock-based value and a specific prefix to differentiate it from system-generated identifiers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If system-generated Message Identifiers and user-generated Correlation Identifiers share the same name space, then it is possible for the system generated Message Identifier in a request message to be copied into the Correlation Identifier of any corresponding response message, but this design presents the user with the problem of generating Correlation Identifiers that are guaranteed not to clash with the system generated Message Identifiers
Solution Approach 1:
The identifier generation process is segmented into two distinct parts: a fixed prefix component and a variable suffix component. The prefix identifies the type of identifier (e.g., 'MSGID' for system-generated message identifiers, 'CORRID' for user-generated correlation identifiers), while the suffix provides the unique value. This segmentation allows the system to maintain both identifiers in the same name space without collision by ensuring they have different prefixes, thus resolving the contradiction between identifier reuse flexibility and identifier uniqueness.
2Reliability
If a unique message identifier is generated through MQPUT/MQBACK call sequence, then the system generates a unique message identifier, but the message with that identifier never be visible outside the connection issuing the calls
Solution Approach 1:
The system performs a preliminary action by generating the unique identifier through the MQPUT/MQBACK sequence, but instead of allowing the message to remain hidden, it subsequently publishes or exposes the generated identifier through a visible interface. This preliminary generation followed by exposure ensures both uniqueness (from the MQPUT/MQBACK sequence) and visibility (through subsequent publication), resolving the contradiction between identifier uniqueness and message visibility.
3Reliability
If Connection Identifier is used as both Correlation Identifier and Message Identifier, then ensures uniqueness and allows third parties to track messages using either identifier, but requires the Conn_id to be differentiated from system-generated identifiers
Solution Approach 1:
The identifier system applies local quality by giving each identifier type a distinct prefix that reflects its origin and purpose. Connection Identifiers have a prefix like 'CONNID', while system-generated message identifiers have a prefix like 'MSGID'. This local differentiation (through prefixes) allows third parties to easily distinguish between different types of identifiers and track messages appropriately, resolving the contradiction between identifier uniqueness and identifier differentiation complexity.
Data Source
AI summary
A system and method for messaging in which, when a connection to a queue manager (220) is established, the queue manager allocates a Connection Identifier from the same name space (300) as Message Identifiers and returns this information (400) to the user. The user can then use this Connection Identifier as a Correlation Identifier, safe in the knowledge that it will not clash with any system generated Message Identifier or Correlation Identifier. A secondary benefit to this allocation scheme is that if a shared reply queue suffers from a build-up of messages then the Correlation Identifier in those messages can be used to identify the application expected to receive those messages.