Consider adopting some attributes that are well known in JMS

[mamwl1]

Area(s)

area:messaging

Is your change request related to a problem? Please describe.

No specific problem, but I am trying to find common ground for span attributes and I think JMS is worth a look at.

Describe the solution you'd like

The JMS spec (https://jakarta.ee/specifications/messaging/3.0/jakarta-messaging-spec-3.0.pdf) defines a standard API for Java applications to perform messaging. JMS supports both point-to-point (queue based) and publish / subscribe (topic) based paradigms. The JMS spec has a long history and is widely adopted in the industry, for example the following products - not an exhaustive list - have JMS APIS:

• IBM MQ
• IBM WebSphere Application Server
• Microsoft Azure Service Bus
• RedHat JBoss
• RabbitMQ via the JMS Client for RabbitMQ
• Confluent Kafka via the JMS Client for Confluent Platform
• Amazon SQS Java Messaging Library
• Apache Rocket MQ (although looks like this is a work in progress)

With such wide adoption of JMS, I think it is worth seeing if there are concepts in there which should be part of the semantic
conventions for messaging. While they might not be applicable everywhere, the fact that they are widely agreed concepts should mean that they will be widely applicable for open telemetry.

JMS defines a number of message headers:

• JMSDestination: this is the equivalent of the existing messaging.destination.name attribute.
• JMSDeliveryMode: indicating whether a message is persistent or not. This could be mapped to a new messaging.message.persistent=true|force attribute.
• JMSMessageID: this is the equivalent of the existing messaging.message.id attribute
• JMSTimestamp: the time when the message was sent. This could be mapped to a new messaging.message.send_time or something similar.
• JMSCorrelationID: this is the equivalent of the existing messaging.message.conversation_id attribute
• JMSReplyTo: used to identify where reply messages are sent. This could be mapped to a new messaging.message.reply_to or something similar.
• JMSRedelivered: a boolean indicating whether a message has been redelivered or not. This is related to messaging.servicebus.message.delivery_count. It could be mapped to a new messaging.message.redelivered=true|false attribute.
• JMSXDeliveryCount: how many times a message has been delivered. Identical to messaging.servicebus.message.delivery_count. It could be mapped to a new messaging.message.delivery_count=n attribute.
• JMSType: can be used for schema related information. The semantic conventions today don't cover payload, so there is no obvious need for this today.
• JMSExpiration: the time at which the message is no longer valid. This could be mapped to a new messaging.message.expiration_time, or something similar.
• JMSPriority: how important a message is, higher priority messages are delivered first. This could be mapped to a new messaging.message.priority field which takes a numerical value.

Additionally there are:

• JMSXUserID: the user that sent a message. This could be mapped to a messaging.producer.* name space.
• JMSXAppID: the app that sent the message. This could be mapped to a messaging.producer.* name space.

And several others which might be rather more niche. The properties I have mentioned above I would expect to be applicable to anything that has a JMS API.

Describe alternatives you've considered

All of the above concepts are relevant to IBM MQ, while they could be defined in an IBM MQ specific way, I would hope that the concepts are common enough that they could be used by others.

Additional context

I mentioned this on the messaging SIG a few weeks ago so raising this so people can have a read and think about it. I am happy to get a PR raised with changes to the docs, and more formalized wording, but a discussion first would be good.