Hi All, Here's my perspective (and motivation) behind the proposal.
I totaly agree that JMS is "the messaging API" for Java. However the goal of AMQP is not be another JMS implementation. We have a much more ambitious goal. Don't we ??? If somebody is interested in working with AMQP (without being bothered with JMS, now I maybe too optimistic here ) then they should be able to do it easily. Besdies we are pushing for a SCA/AMQP binding. There is also a SCA/JMS binding. So where is differentiation factor if just only have a JMS client? I don't buy the argument that users are going to get confused. This is how I would position it. AMQP is a messaging protocol, JMS is not, it's just and API. Since JMS is "the messaging API" for java we have implemented JMS using AMQP. But that doesn't mean that AMQP doesn't deserve to have a client API of it's own. Remember, AMQP is not just java, any language can implement it, so if there is a c++ client that publish a message, we should have a java client that can fully utilise the power of AMQP without being limited to JMS simply bcos thats how we choose to expose it. I think AMQP fully deserves to have it's own client API. It's a protocol on it's own right and it shoudn't live under the JMS banner. JMS is one way of using it, not just the only way. Comments are most welcomed. Regards, Rajith On 9/15/06, Robert Greig <[EMAIL PROTECTED]> wrote:
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
