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.
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
