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.
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. 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. 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. 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. Interesting converstation, hope you don't mind my $0.02.. Regards, Colin. http:/hermesjms.com -----Original Message----- From: Robert Greig [mailto:[EMAIL PROTECTED] Sent: 15 September 2006 13:34 To: [email protected] Subject: Re: QPID/HermesJMS On 14/09/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > I am planning a refactoring of the java client to create an AMQP > client API and then build the JMS layer on top of it. > So people who are interested can directly access AMQP specific features. The approach we had taken before was to have an "extended JMS" API that exposed additional methods and potentially interfaces, e.g. org.apache.qpid.jms.Session extends javax.jms.Session. I would be interested to understand what kind of features you would like to expose? Do you think the existing approach is not adequate for your needs, i.e. do you want to create a completely un-JMS-like API? My initial thought is that I don't like the general idea of have two APIs - two is one too many unless there is a good functional or historical reason for it. It asks users to make a choice they may not feel comfortable making (are you saying to users that to get the "full power" of AMQP you need to use our proprietary API?). JMS is by its nature a compromise of an API, hence why we wanted to extend it like most JMS implementations, and some AMQP concepts are relatively tricky to map (the Destination concept in JMS being the most obvious example). Maybe we can do better here, although I think that Martin's great work on the URIs helps a lot in making it easier for the users. In other languages, where there is no standard messaging API we have freedom to create whatever API feels best for that language but for Java I believe JMS will for the time being be the primary API. Maybe if AMQP takes off with other messaging vendors we would be able to get some of our extensions added to a future version of JMS. > Since Robert seem to be back I am going to talk with him and settle on > the direction. I'm still just checking mail sporadically but will be back full time from Monday. RG
