On 15/09/06, Colin Crist <[EMAIL PROTECTED]> wrote:
One benefit of having a more AMQP friendly API that the JMS layer uses is that you can avoid being bound into some of the shortcomings JMS imposes.
I certainly agree with the view that JMS has shortcomings (and also things that are simply left up to implementations to define) but my general point is that I am not convinced we need to have a completely new API to address these issues. For the cases I have seen so far, extensions to the existing JMS concepts are reasonable ways of dealing with these issues.
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? 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?
In JMS a session has some similarity to a dispatch queue (its often got one inside it) so I guess some of this flexibility could still be exposed if there really was a queue underneath.
Yes there is a dispatch queue in our implementation although the current implementation is quite tightly bound to our transport, for things like acknowledgements and transactions.
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.
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/ManagementSession 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?
Interesting converstation, hope you don't mind my $0.02..
Absolutely, your feedback is very useful. RG
