Promoting the interoperability of MQs objects. Based on Java JMS

0.6.1 2017-08-10 11:24 UTC


Latest Stable Version Monthly Downloads Total Downloads License


queue-interop tries to identify and standardize a common way for PHP programs to create, send, receive and read MQ messages to achieve interoperability.

Through discussions and trials, we try to create a standard, made of common interfaces but also recommendations.

If PHP projects that provide queue implementations begin to adopt these common standards, then PHP applications and projects that use MQs can depend on the common interfaces instead of specific implementations. This facilitates a high-level of interoperability and flexibility that allows users to consume any MQ transport implementation that can be adapted to these interfaces.

The work done in this project is not officially endorsed by the PHP-FIG. We adhere to the spirit and ideals of PHP-FIG, and hope this project will pave the way for one or more future PSRs.


You can install this package through Composer:

composer require queue-interop/queue-interop


Send a message:


$factory = new AcmeConnectionFactory('acme://');

$context = $factory->createContext();


Consume a message:


$factory = new AcmeConnectionFactory('acme://');

$context = $factory->createContext();
$consumer = $consumer->createConsumer($context->createQueue('aQueue'));

if ($message = $consumer->receiveNoWait()) {

    // reject on fail
    // $consumer->reject($message);

// or 

$timeout = 5000; // 5sec
if ($message = $consumer->receive($timeout)) {

Find out more here:

Compatible projects



Amqp interop

There is AMQP interop built on top of queue interop. It is completly compatible with queue interop and only adds some AMQP specific features.


composer require queue-interop/amqp-interop

Compatible projects


Everyone is welcome to join and contribute.

The general workflow looks like this:

  1. Someone opens a discussion (GitHub issue) to suggest an interface
  2. Feedback is gathered
  3. The interface is added to a development branch
  4. We release alpha versions so that the interface can be experimented with
  5. Discussions and edits ensue until the interface is deemed stable by a general consensus
  6. A new minor version of the package is released

We try to not break BC by creating new interfaces instead of editing existing ones.

While we currently work on interfaces, we are open to anything that might help towards interoperability, may that be code, best practices, etc.


MIT license