Some additional historical context from my personal observations... The "jms.queue." and "jms.topic." queue/address prefixes were put in place years ago when the code-base was relatively young. This was before my time but I believe this was done because it was an extremely simple (and effective) solution to the problem of how to provide different semantics between JMS and core. JMS was the first and only non-core protocol supported by the broker for a long time. As other protocols were implemented the whole prefix notion was recognized as a weakness (e.g. see ARTEMIS-203). Since the donation to Apache significant work has been done on other protocols like AMQP, MQTT, and STOMP. IMO, this has pressed the issue to the point of action.
I think making the changes that Martyn has outlined will provide a better foundation for the long-term of health of Artemis which is an increasingly multi-protocol broker. It should make the broker simpler which will be a win for configuration as well as maintenance and new protocol integration. Justin ----- Original Message ----- From: "Martyn Taylor" <mtay...@redhat.com> To: dev@activemq.apache.org Sent: Wednesday, November 16, 2016 9:16:02 AM Subject: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0 All, Some discussion has happened around this topic already, but I wanted to ensure that everyone here, who have not been following the JIRA/ARTEMIS-780 branch has a chance for input and to digest the information in this proposal. In order to understand the motivators outlined here, you first need to understand how the existing addressing model works in Artemis. For those of you who are not familiar with how things currently work, I’ve added a document to the ARTEMIS-780 JIRA in the attachments section, that gives an overview of the existing model and some more detail / examples of the proposal: *https://issues.apache.org/jira/browse/ARTEMIS-780 <https://issues.apache.org/jira/browse/ARTEMIS-780>* To summarise here, the Artemis routing/addressing model has some restrictions: 1. It’s not possible with core (and therefore across all protocols) to define ,at the broker side, semantics about addresses. i.e. whether an address behaves as a “point to point” or “publish subscribe” end point 2. For JMS destinations additional configuration and objects were added to the broker, that rely on name-spacing to add semantics to addresses i.e. “jms.topic.” “jms.queue.” A couple of issues with this: 1. This only works for JMS and no other protocols 2. Name-spacing causes issues for cross protocol communication 3. It means there’s two ways of doing things, 1 for JMS and 1 for everything else. 3. The JMS and Core destination definitions do not have enough information to define more intricate behaviours. Such as whether an address should behave like a “shared subscription” or similar to a “volatile subscription” where clients don’t get messages missed when they are offline. 4. Some protocols (AMQP is a good example) don’t have enough information in their frames for the broker to determine how to behave for certain endpoints and rely on broker side configuration (or provider specific parameters). Proposal What I’d like to do (and what I’ve proposed in ARTEMIS-780) is to get rid of the JMS specific components and create a single unified mechanism for configuring all types of endpoints across all protocols to define: - Point to point (queue) - Shared Durable Subscriptions - Shared Non Durable Subscriptions - Non Shared durable subscriptions - Non Shared Non durable subscriptions To do this, the idea is to create a new “Address” configuration/management object, that has certain properties such as a routing type which represents how messages are routed to queues with this address. When a request for subscription is received by Artemis, the relevant piece can just look up the address and check it’s properties to determine how to behave (or if an address doesn’t exist) then default to our existing behaviour. For those interested in the details of how this might work I’ve outlined some specific examples in the document on the JIRA. What are the user impacts: 1. Configuration would need to be revised in order to expose the new addressing object. I propose that we either continue supporting the old schema for a while and/or provide a tool to migrate the configuration schema. 2. Some new management operations would need to be added to expose the new objects. 3. The JMS configuration and management objects would become obsolete, and would need removing. The Broker side JMS resources were only a thin facade to allow some JMS specific behaviour for managing destinations and for things like registering objects in JNDI. Broker side JNDI was removed in Artemis 1.0 in order to align with ActiveMQ 5.x style of client side JNDI. These JMS pieces and their management objects don't really do much, creating connection factories for instance offers no functionality right now. Going forward, users should be able to use the core management API to do everything. 4. All client applications should behave exactly as they were before. The proposal is for adding features to the core model, not removing any. For things like the Artemis JMS client which relied on name-spaces, they’ll be a mechanism to define a name-spaced address and a mechanism to switch back on name-spaces in the client. 5. Given some of the API changes and removal of the JMS specific pieces. This would likely warrant a major bump. i.e. Artemis 2.0.0. Whilst I’ve been looking at this, it’s become apparent, that the JMS pieces have leaked into lots of areas of the code base, which does mean we’d need to do a fair amount refactoring to move these bits to the new model. In my opinion this proposal can only be a good thing. It creates a single place (core) where all addressing objects are configured and managed and allows all protocol managers to plug into the same mechanism. It solves some of the cross protocol JMS → other protocols that we’ve seen users struggle with, but still offers a way to support all the old behaviour in client applications. What are others thoughts on this? Any suggestions, comments or concerns? Regards Martyn
