Hi, > > One commonly cited one is threading, if anyone has used RV for > > example, its model of having dispatch queues (not to be > confused with > > transport queues) onto which messages are placed by listeners (i.e. > > subscriptions) totally decouples the subscription from the final > > message callback. This model is very flexible letting you dispatch > > messages from timers as well as transports. Its semantics > would need > > some enhancements in a transactional environment but it's a > good example of where JMS ain't so great. > > I am not terribly familiar with RV at the API level. If I > understand you correctly, RV provides a general message > delivery API that can be used to deliver messages via the > equivalent of a MessageConsumer even though those messages > did not originate from the messaging transport?
You can push messages and timer events to the same dispatch queue, the messages can come from more than one transport, i.e. in RV a multicast/port combination. The point here is that the dispatch and threading is under your own control where in JMS it is not. > We could add some feature like this to our extended JMS API > although as you mention I am not sure how acknowledge modes > and transactions would fit with this. It appears to be > slightly higher level than JMS? I'd say it's lower level than JMS as the threading and dispatching is handled within a JMS provider. > > The JMS message model is also limiting, notably in its flat > MapMessage > > but you can work around this by either casing into a TreeMessage or > > exposing the tree via an object in an ObjectMessage. I once > worked on > > an RV JMS provider at a bank and we put a pluggable > marshalling layer > > to convert the RV message to and from a JMS message, you'd > certainly > > need to support this as there is no guarantee your client code is > > talking to the QPID AMQ server and hence no agreement on > how the JMS message is mapped to and from the transport. > > We have extended the JMS message model. In AMQP, the message > header contains mime type and encoding fields, and we allow > the registration of mime type handlers (all the JMS message > types are handled like this under the covers). If you want to > introduce a TreeMessage you can just register some classes > with the MessageFactoryRegistry, with some suitable mime type > of your choosing. OK, cool. Would this be portable to other AMQP server side implementations? > > I'm not convinced about a JMS Session also being a > ManagementSession, > > it feels more natural to me to mirror the JMS pattern in a > > > ManagementConnectionFactory/ManagementConnection/ManagementSes > sion set > > of interfaces separately - it could make the code simpler to manage > > and better match the different security policies between regular > > messaging, broker management and monitoring. > > I'm not sure what you are referring to? What is a ManagementSession? I should have made myself clearer - these ManagementXXX interfaces are made up to highlight a difference in functionality between management/monitoring and core messaging, many JMS providers give broker access via a quite separate API (e.g. Tibco EMS has a TibjmsAdmin). Some provide JMX too. I guess in my ideal provider I'd see: 1. A clean simple JMS implementation. 2. A more functional API that maps to semantics of the provider with messaging and admin. 3. A JMX provider that reuses the transport via the admin API (this means you end up delivering a JMS and a JMX provider...) I've seen several mails on the merits of a public AMPQ API on top of which a JMS API is layered. One benefit of this I've not seen mentioned is that it localises the mapping between AMPQ and JMS semantics in one place, e.g. concepts of queues, topics and messages. This could be a real maintenance benefit as well as making the codebase clearer. Regards, Colin. http://hermesjms.com
