synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <>
Subject Re: Like to know the Synapse AMQP trasports status
Date Thu, 26 Nov 2009 15:48:17 GMT
On Thu, Nov 26, 2009 at 4:31 AM, Asanka Abeysinghe <> wrote:
> +1 for native AMQP transport,
> By bridging from JMS to AMQP is it possible to get the full advantage of
> AMQP specific features like exchanges, exchange types, routing keys, dynamic
> creation of queues etc ... ?

Again Good question and one for the FAQ.
Even now the JMS client is flexible enough to take full advantage of
exchanges, exchange types, rk's and dynamic creation of queues.
The new addressing format is even more flexible as it permits lot more
options like flow control, reliability expectations, declare and bind
arguments, how and when queues should be created by the client (ex
never - centrally administered, producer-created by producer,
consumer-created by consumer)
(As an aside, it's worth noting that exchanges are not going to be
there in 1.0 )

If you need to create queues as part of business logic, you could
still use the createQueue()/createTopic() methods and pass in an
address string and get the same benefits mentioned above.
As I mentioned in my first email, one important development in AMQP
1.0 is that management commands such as declare, bind , query queues
etc... are not part of the core protocol, but rather sent as messages
over the transport to a known admin/mgt service. The Qpid project's
QMF framework is aiming to follow that direction even from 0-10 by
allowing to perform management functions using pure message passing
(ex using Map messages)

Does this sufficiently answer your all your questions?
If not please feel free to dig further and I am happy to answer any
questions you have.

If you have specific use cases that would also help, as sometimes
discussing in abstract form is a bit difficult.



> - Asanka
> On Thu, Nov 26, 2009 at 10:34 AM, Ruwan Linton <>
> wrote:
>> +1 for developing a native AMQP transport.
>> Thanks,
>> Ruwan
>> On Thu, Nov 26, 2009 at 9:52 AM, Hiranya Jayathilaka
>> <> 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 <>
>>> 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 <>
>>>> 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
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> --
>>> Hiranya Jayathilaka
>>> Software Engineer;
>>> WSO2 Inc.;
>>> E-mail:;  Mobile: +94 77 633 3491
>>> Blog:
>> --
>> Ruwan Linton
>> Technical Lead & Product Manager; WSO2 ESB;
>> WSO2 Inc.;
>> email:; cell: +94 77 341 3097
>> blog:
> --
> Asanka Abeysinghe
> Architect - WSO2, Inc.
> m: +94 77 7340064      p: +94 11 2688451/3
> e: w:
> b:


Rajith Attapattu
Red Hat

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message