0

I am planning on using RabbitMQ as the AMQP implementation in my project. But I would like to restrict myself to using only the AMQP spec and not use any RabbitMQ extensions to AMQP.

Is there a way I can leave this 'spec-safety' check to the compiler ? For ex: if there was a AMQP-spec-only library of RabbitMQ, then by including only this library, I can leave it to the compiler to complain everytime I try to use an extension (as it cannot find the definition/implementation for that extension in the AMQP-spec-only library).

I want to do this so that if I try to switch to a different AMQP implementation, It will be easier ! (I am planning to use Spring Integration to abstract from the underlying AMQP implementation).

2020
  • 2,821
  • 2
  • 23
  • 40

1 Answers1

1

I would first check with the Rabbit guys...

https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

The Spring abstractions simply sits on top of the RabbitMQ Java client.

While Spring-AMQP (and hence Spring Integration) provides a general abstraction over AMQP, we currently only have a concrete Rabbit implemention. It may, or may not, work with other brokers, to the extent that the RabbitMQ client will do so.

We'd welcome contributions for other implementations of the abstraction, if needed.

Gary Russell
  • 166,535
  • 14
  • 146
  • 179
  • yes. it is a rabbitmq question and not a Spring one. Your statement "it[Spring-AMQP] may, or may not, work with other brokers." scares me, considering that it is made by a Spring integration team-member ! But I appreciate the honesty ! May be I am naive to think that a project like Spring-AMQP should restrict itself to the AMQP spec and ignore custom extensions of implementations ! – 2020 May 03 '13 at 23:24
  • If I just use the methods of Spring's AmqpTemplate (and not the ones added by RabbitTemplate) then eventhough I instantiate RabbitTemplate, I should be able to avoid AMQP-implementation dependencies ? – 2020 May 03 '13 at 23:49
  • What I mean is that we use the underlying Rabbit Java client; Spring-AMQP will work with other brokers to the extent that the Rabbit Java client will work with other brokers. Spring-AMQP is intended as a mechanism to provide an abstraction over *any* java client; with the general abstraction in the `spring-amqp` project, and the abstraction over the RabbitMQ java client in the `spring-rabbit` project. Jf the rabbit client doesn't work for you for some reason (with some other broker), then a spring-xxx project can provide that while maintaining a consistent API for applications. – Gary Russell May 03 '13 at 23:54
  • It's similar to the `spring-integration-sftp` module using the `Jsch` library; if someone wants to use a different library, the abstractions are in place to do so, but someone will need to write the implementation. – Gary Russell May 03 '13 at 23:58
  • One last point. It's not a question of 'honesty'. I think you might be missing the point that, unlike JMS, AMQP is NOT a Java API; it's a wire protocol that defines how the communication is structured. There is no standard Java 'API', in the AMQP spec, that any Java compiler can "enforce". Notice that the page you cite is titled 'Protocol Extensions'. Rabbit has a Java (and other) APIs that implement the protocol on the wire. Spring-AMQP has an implementation that uses that API and has made a best-effort to provide an abstraction that will allow other APIs to be plugged in. – Gary Russell May 04 '13 at 02:38
  • Thanks ! Your response does clarify Spring's approach. And I will leave my question open for RabbitMQ experts/devs to say if RabbitMQ solves my problem in any way. – 2020 May 07 '13 at 23:32