+1 for developing a native AMQP transport. Thanks, Ruwan
On Thu, Nov 26, 2009 at 9:52 AM, 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. > > 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 > -- Ruwan Linton Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: [email protected]; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
