May AMQP improve OpenHab?

The Organization for the Advancement of Structured Information Standards released a messaging standard focused on perfomance and interoperability named AMQP. I think it would improve
openhab to support this protocol. It is not so lightweight like MQTT but enables Message queuing and also security management.

This Blog entry shows the differences between AMQP, MQTT and STOMP:

The distinction is not clear because MQTT implementations also support message queuing and security (SSL, topic ACLs, etc.).

I assume you asking about a new AMQP binding. Another possibility is to use the existing OH MQTT binding and the MQTT adapter in RabbitMQ. The adapter bridges the two protocols.

That blog posting is a little out of date. My comments are from a Mosquitto perspective but most of what I’m going to say is part of the MQTT spec so should be universal.

Indeed MQTT does not support message queueing (i.e. one-to-one communications) but you typically don’t do one-to-one communication in an home automation context. Instead something that has data publishes it and any client who may care about that data can subscribe to it. You can fake one-to-one through access control lists (ACLs) (i.e. only allow two clients to access a given topic). So there is a workaround to this limitation of MQTT.

In reference to queueing messages for guaranteed delivery and guaranteed order of delivery, MQTT supports that too, but that isn’t what the author of that article is referring to when he says “supports message queueing”. It is an unfortunate overloading of the term.

MQTT also has some pretty good security built into it including ACLs, encrypted traffic (TLS), client authentication, etc. I will agree that most AQMP servers like IBM MQ, Oracle’s WebLogic (I think they support AMQP now) and RabbitMQ will support things like client authentication and authorization on a more “enterprise” scale (e.g. hook into a company’s PKI and/or Directory Services). But in a home automation scenario a simple user/password file and perhaps some self-signed certificates for TLS is all the average HA user is going to want (who wants to set up their own PKI, yuck).

To address his points directly:

restrict access to queues

So can MQTT through access control lists.

manage their depth

MQTT (at least Mosquitto) has a max_queued_messages, though it is a global setting, not on a per-topic basis

and more

It is hard to compare that statement.

Ignoring the comparison between AMQP and MQTT, if you can find some devices, service, or APIs that require AMQP which would be beneficial in a home automation context I will wholeheartedly agree with you and perhaps even help with the implementation (messaging is one of my areas of expertise). However, without a concrete use case I just don’t see the value of adding a new binding to support a messaging protocol that no one uses in a home automation context.

Besides, as @steve1 mentions, if you use RabbitMQ you can bridge between AMQP and MQTT there and let OH stick to MQTT.

And for the record, all my discussion above also applies to JMS, and IBM MQ.

I agree MQTT doesn’t support message queues in the JMS or MQ sense although it supports other flavors of “message queuing” to clients. It’s a little misleading, although mostly true. to say message queues are “one-to-one”. There can be any number of listeners to a JMS message queue, for example, but only one listener will receive the message at any given point in time. If a listener rejects the message, it may be delivered to another listener. I’ve seen software architectures where this has been used to implement load balancing and high availability systems (where members of a set of stateless servers can die but the system still continues processing queued messages). However, I have difficulty believing that this a requirement for most, if any, openHAB installations.

The other possible benefit of AMQP is that it can be operated without a broker so reliability may be somewhat better.

Agreed. In my rush to write I and didn’t correctly describe the difference.