Hi Colin! > 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.
I've not heard about the threading problems of JMS. I wonder is that often cited in the Tibco/RV world? The application programming model you are describing that you use with RV sounds like that used in Erlang to some degree (which has roots in Carl Hewitt's Actors). http://tunes.org/wiki/Actor Recently this programming model has become available on the Java platform via the Scala programming language. Really interesting stuff: http://lambda-the-ultimate.org/node/1615 > 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. What to you mean by casing into a TreeMessage? What is a TreeMessage? Is that a Tibco extension? It sounds like you are referring to a feature added to activemq in release 4.1 http://www.activemq.org/site/structured-message-properties-and-mapmessages.html This is likely inspired by AMQP as a FieldTable allows for nested maps. Having a list/array type is a nice addition. The AMQP working group ought to consider lists/arrays as a type when the field-table types are reviewed soon. It would be possible to use a FieldTable as a message body. This would reuse the encoding/decoding already present for a FieldTable. In a past life I worked on a telecoms rating/billing system that used only IIRC int, long, float, double, list and map as types in it's "service" layer. Services could be implemented in C, C++, Java or a proprietary scripting language. It was surprising to see what could be done with on such a humble base. > 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 think Robert has already asked what a ManagementSession is. Is it another RV extension? > hope you don't mind my $0.02.. Not at all. I think it's great to hear about other messaging products. I am not familiar with RV. I think it would be great to do a survey of messaging products out there and see how Qpid and AMQP compare. Steve. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
