On Fri, Nov 27, 2009 at 10:53 AM, Ruwan Linton <ruwan.lin...@gmail.com>wrote:
> +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 :-) > Sure, I will do talk to Rajith and do it. Lahiru > > 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 > -- Apache Qpid, Worlds dominant messaging middleware..!!!
