On Wed, Nov 25, 2009 at 11:22 PM, Hiranya Jayathilaka <[email protected]> wrote: > Well personally I like the idea of Synapse having a native AMQP > implementation rather than having to access AMQP queues over JMS. Some of > the prominent AMQP providers like RabbitMQ does not provide JMS and JNDI > support at a satisfactory level. IMHO it is totally worth having this > transport - as an optional one of course.
Good question and one for the FAQ. AMQP servers does not need to be aware of JMS or support JNDI. The Qpid client (or for that matter any JMS client built on top of AMQP) will map JMS semantics on to AMQP, and the protocol takes care of the rest. The AMQP WG does understand the prominence of JMS very well, hence have taken that into account when designing the protocol. You could use Qpid JNDI to represent pre created AMQP queues (using a management tool), or you could dynamically create these queues based on the destination configuration. The new address syntax for all language clients that Qpid is currently working on has a lot more flexibility than the older format. For example It could do things, like specify declare arguments (to make use of provide specific features like max-queue-size,max-queue-count, reject-policy ..etc) Another example is setting destination specific flow control, or reliability expectations. Another important point to note is that, this configuration is done with AMQP 1.0 in mind. So you could just upgrade to an AMQP 1.0 server __without any code changes__ Another benefit of the JMS transport is that you could use it to talk to RabbitMQ or Qpid brokers. If we use a native AMQP transport it will likely be very close to a particular protocol version and the sensible option is to use 0-10 or go straight to 1.0 It should be noted there are significant semantic differences between 0-8/0-9, 0-10 and 1.0 versions of the protocol. So it will not work with RabbitMQ. If you use 1.0 currently no production versions exist as the protocol is yet to be ratified. If that is taken into account you will end up writing a higher level client that is protocol agnostic, which would quite bit of work for no real benefit. So why not use the JMS transport? The RabbitMQ sever is at 0-8 (0-9 too ??) version of the protocol, while the Qpid java broker supports 0-8,0-9,0-10 and the c++ broker only the 0-10 version. However the Qpid JMS client supports all (0-8,0-9 and 0-10) versions of the protocol. So you should be able to use the JMS transport with RabbitMQ or Qpid. (The Qpid client and RabbitMQ does have a few quirks, and that is more due to issues with the 0-8 protocol and to the fact that some features are not supported by one vendor) So in summary I still don't see any tangible benefit of having a native AMQP transport, unless we have some very compelling use cases. Infact I think for a project like Synapse using AMQP via JMS seems like a safe bet. But if someone is willing to experiment, I wouldn't stand in the way either :) > Thanks, > Hiranya > > On Wed, Nov 25, 2009 at 11:14 PM, Rajith Attapattu <[email protected]> > wrote: >> >> Hi Lahiru, >> >> I am afraid it's in an unusable state atm mainly due to my fault. >> I would also like to take this opportunity to discuss the continuity >> of the amqp transport. >> >> The motivation behind creating an AMQP specific transport instead of >> using it via the JMS transport was due to the perceived flexibility & >> performance achieved via a transport that is close to the protocol. >> >> However as Qpid gained more experience and myself having the privilege >> of working with customers and end users realized that the JMS >> implementation is lacking this flexibility more due to design issues >> than any real issue with the API itself. Over the last year or so we >> made significant improvements to the JMS client. >> The new address format that will be used by all the Qpid clients >> including JMS will be rich enough to tune protocol specifics via the >> javax.jms.Destination abstraction while allowing applications to use >> pure JMS without having to resort to a vendor specific low level API. >> Going forward management aspects such as having to create >> queues/exchanges dynamically could be done by sending a map message >> than invoking a protocol command. Infact in AMQP 1.0 management/admin >> work such as declaring queues are not protocol specific commands any >> more. They are achieved via sending messages to a known admin/mgt >> service within a container. >> >> There was also quite a bit of performance work done in the JMS client >> to the extent the difference btw the JMS layer and lower layer is >> negligible for a real business application especially within the >> context of Synapse. In artificial benchmarks the diff is about 10k >> msg/sec. >> >> Therefore with the benefit of hindsight I feel that having an AMQP >> specific transport doesn't add anything significant over the well >> tested JMS transport that Synapse has. >> However before coming to a conclusion, it would be worthwhile to >> figure out all the use cases around AMQP with Synapse. >> Then we could document how they could be achieved via the JMS transport. >> If there are any use cases that cannot be reasonably met, then perhaps >> we could discuss about an AMQP specific transport. >> >> Regards, >> >> Rajith >> >> On Wed, Nov 25, 2009 at 9:22 AM, Lahiru Gunathilake <[email protected]> >> wrote: >> > Hi all, >> > >> > I like to do some work with synapse AMQP trasport and like to know the >> > status of the trasport in current synapse code base. >> > >> > Regards >> > Lahiru >> > >> > -- >> > Apache Qpid, Worlds dominant messaging middleware..!!! >> > >> >> >> >> -- >> Regards, >> >> Rajith Attapattu >> Red Hat >> http://rajith.2rlabs.com/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Hiranya Jayathilaka > Software Engineer; > WSO2 Inc.; http://wso2.org > E-mail: [email protected]; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.blogspot.com > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
