+1, can some one do a PoC on RabitMQ with the JMS transport? and if it is successful then submit that as a sample on to synapse, if we fail to do that, what ever the theory is, we will have to go for a native AMQP or some transport which can work with AMQP providers like RabitMQ.
Lahiru, whould you like to do this? Or may be Rajith :-) Thanks, Ruwan On Fri, Nov 27, 2009 at 9:41 AM, Hiranya Jayathilaka <hiranya...@gmail.com>wrote: > > > On Thu, Nov 26, 2009 at 8:42 PM, Rajith Attapattu <rajit...@gmail.com>wrote: > >> On Wed, Nov 25, 2009 at 11:22 PM, Hiranya Jayathilaka >> <hiranya...@gmail.com> 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. >> > > Can we use the JMS transport to talk with brokers like RabbitMQ which are > not written in Java? Do you mean to say that we can already use the Axis2 > JMS transport to connect with JMS unaware AMQP brokers? If that can be done > then I'm ready to give up the idea of writing a native AMQP transport. > However we need to properly document such tasks by providing sufficient > samples. > > Thanks, > Hiranya > > >> 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 <rajit...@gmail.com> >> > 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 <glah...@gmail.com >> > >> >> 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: dev-unsubscr...@synapse.apache.org >> >> For additional commands, e-mail: dev-h...@synapse.apache.org >> >> >> > >> > >> > >> > -- >> > Hiranya Jayathilaka >> > Software Engineer; >> > WSO2 Inc.; http://wso2.org >> > E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 >> > Blog: http://techfeast-hiranya.blogspot.com >> > >> >> >> >> -- >> Regards, >> >> Rajith Attapattu >> Red Hat >> http://rajith.2rlabs.com/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >> For additional commands, e-mail: dev-h...@synapse.apache.org >> >> > > > -- > Hiranya Jayathilaka > Software Engineer; > WSO2 Inc.; http://wso2.org > E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.blogspot.com > -- Ruwan Linton Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
