"Vendor" meaning different implementations of the AMQP spec, both the client
libraries as well as the broker. For example, right now the Spring AMQP
project only supports RabbitMQ and lists the RabbitMQ client libraries as a
dependency. Spring doesn't necessarily implement their own AMQP client
library.

Qpid support would come along with the Spring AMQP project. Right now they
say they have tested Qpid with Spring AMQP, however it is not officially
supported and the framework is written in such a way that it is hard to
decouple from RabbitMQ. For example, right now the declaration of an
exchange is tied specifically to the RabbitMQ implementation. Once Spring
does some more abstraction over channels, administration and message
conversion then support for other implementations such as Qpid should become
much easier.

There's nothing sub-optimal about the current Camel AMQP component - in fact
its simplicity is a great testament to how inter-operable the Qpid project
is with JMS semantics. Looking at the source at
http://svn.apache.org/viewvc/camel/trunk/components/camel-amqp/src/main/java/org/apache/camel/component/amqp/
there is just one file that extends JmsComponent whose primary
responsibility is:


If the features within the JMS component are what you need, then you're
golden. If you want to do more AMQP-specific stuff like header exchanges
then you would need to leverage a component that allowed you to specify
those features directly. That was the hope of this component - allowing
direct access to the AMQP feature set.


Glen Mazza-3 wrote
> 
> Hi, your GitHub intro for this component says: "An Apache Camel 
> <http://camel.apache.org/> Component that will natively communicate
> with 
> a RabbitMQ <http://www.rabbitmq.com/> broker. This is implemented
> using 
> Spring's AMQP project, so it should ultimately become vendor-agnostic."  
> I guess you mean *broker*-agnostic, i.e., it should be able to work with 
> the Qpid broker if you're not using native RabbitMQ features.  Is there 
> anything preventing it from working now with the Qpid broker, or you 
> just haven't had time to test it yet?
> 
> Also, what do you mean by "...instead of a JMS->AMQP interface via Qpid" 
> When you say "Qpid" I guess you mean Camel's AMQP component 
> (http://camel.apache.org/amqp.html) which uses the Qpid client 
> libraries.  Is there something suboptimal with using Qpid's client 
> library to implement an AMQP client (i.e., it's doing a strange 
> JMS->AMQP mapping instead of pure AMQP) or it's just that you can't take 
> advantage of any native RabbitMQ features when using it?
> 


--
View this message in context: 
http://camel.465427.n5.nabble.com/Spring-AMQP-Apache-Camel-Component-Released-tp5027785p5029275.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Reply via email to