One popular use of a Message Registry is to be a catalog of Message definitions that are used to validate incoming messages. In these scenarios, the receiver of a message might need to "match" it to the corresponding Message definition that the message is meant to adhere to. This specification does not mandate how this "matching" is done. For example, matching headers or schema of the incoming message to the Message definitions in the Registry is one option.
In a Registry with many Message definitions, and each one of those having potentially multiple Versions, results in a 2-dimensional collection of Message definitions to match against, which could make finding the exact Message definition complex, non-deterministic or very slow. To help with these situations, this specification provides the following guidance:
- Use of CloudEvents is RECOMMENDED as it will provide well-defined metadata that will appear in each Message to help differentiate Message definitions.
- Messages definitions SHOULD have a
messageidvalue that is the same as the CloudEvents'typecontext attribute defined for that Message. This will allow for an exact mapping from the incoming Message'stypeattribute to its related Message definition. - Message Resource types SHOULD be defined with a
maxversionsof1. This eliminates the need for each incoming Message to include some unique Version discriminator. - Modifications to Message definitions SHOULD NOT result in "on the wire" changes
to the resulting messages as that could break existing systems. Rather, new
Messages definitions SHOULD be created, with new
typeandmessageidvalues, and referenced through the use of thedeprecatedattribute.
Implementations, and Registry model authors, MAY deviate from these recommendations however they are then responsible for defining the mechanisms by which a unique Message definition is matched to incoming messages.