synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lahiru Gunathilake <glah...@gmail.com>
Subject Re: Like to know the Synapse AMQP trasports status
Date Fri, 27 Nov 2009 05:30:33 GMT
On Fri, Nov 27, 2009 at 10:53 AM, Ruwan Linton <ruwan.linton@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 <hiranya911@gmail.com
> > wrote:
>
>>
>>
>> On Thu, Nov 26, 2009 at 8:42 PM, Rajith Attapattu <rajith77@gmail.com>wrote:
>>
>>> On Wed, Nov 25, 2009 at 11:22 PM, Hiranya Jayathilaka
>>> <hiranya911@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 <rajith77@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 <
>>> glahiru@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-unsubscribe@synapse.apache.org
>>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Hiranya Jayathilaka
>>> > Software Engineer;
>>> > WSO2 Inc.;  http://wso2.org
>>> > E-mail: hiranya@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-unsubscribe@synapse.apache.org
>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>
>>>
>>
>>
>> --
>> Hiranya Jayathilaka
>> Software Engineer;
>> WSO2 Inc.;  http://wso2.org
>> E-mail: hiranya@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: ruwan@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>



-- 
Apache Qpid, Worlds dominant messaging middleware..!!!

Mime
View raw message