AMQP Support in Orocos

Hi all,

my name is Nico and I am a research associate affiliated at the
Bonn-Rhein-Sieg University of Applied Sciences (BRSU), Germany.

In our group we are working with KU Leuven and other partners on
the EU funded research project BRICS (Best Practice in Robotics [1]).

Within BRICS we want to provide *good* tools, models, and functional
libraries to accelerate the development of modern robotic applications.
Ranging from development environments to communication middlewares and
robotic software frameworks, we try to come up with solutions and "best
practices" which are needed in the community.

Here at BRSU, we assessed and screened the marketplace for
communication middleware technologies/standards (e.g. CORBA,
AMQP, DDS, and more) from a robotics perspective. We identified
several needs for a communication middleware in our domain.

* Data-centric applications: In robotics we build mainly data-centric
applications (e.g. providers and consumers of sensor-data are
distributed). We need a simple and easy support, to build such
applications.

* Loose coupling: For the sake of reuseability we do not want to couple
components, therefore a communication middleware should provide means to
build such loosely coupled applications in terms of time and
location-transparency.

* Interoperability: In order to be interoperable with heterogenous
components the "common language" should be the data types which are
communicated.

* And even more :)

Coming back to the marketplace, message-oriented communication
middleware are exactly adressing this demands. Interestingly, (to the
best of my knowledge) no common robotic software framework (e.g. Orocos,
Player, OpenRTM-aist) supports a pure message-oriented communication
middleware as a AMQP or DDS implementation. Therefore, we propose to
"integrate" an AMQP implementation (see below ZeroMQ as a proposal) in
Orocos. We would like to work on such an "integration".

The intend of this post is to get opinions from the Orocos developers
about the feasibility of a AMQP support in Orocos and about potential
barriers. I am looking forward for your feedback.

Best regards,
Nico

ZeroMQ:
-------
Please find below a compiled list of features provided by ZeroMQ. Please
refer also to [3].

License:
=> LGPL

Supported programming languages:
=> C
=> C++
=> Java
=> Python
=> and more

Supported operating systems:
=> Linux
=> Mac OS X
=> NetBSD
=> and more

The ZeroMQ message-oriented middleware is based on the AMQP model [2]
and specification. In contrast to other message-oriented middleware,
ZeroMQ provides different architectural styles of message brokering.

Usually, a central message broker is repsonsible for message delivering.

This centralized architecture has serveral advantages:

=> loose coupling of senders and receivers
=> lifetime of senders and receivers do not overlap
=> broker is resistent to application failures

However, the centralized architecture also has several disadvantages.
Firstly, the broker incurs an excessive amount of network communication.
Secondly, due to the potential high load of the message broker, the
broker itself can become a bottleneck and the *single point of
failure* of the messaging system.

Therefore, ZeroMQ supports different messaging models:

=> broker (as mentioned above)
=> brokerless (peer-to-peer coupling)
=> broker as directory server (senders and receivers are loosely coupled
and they find each other via the directory broker, but the messaging
is done peer-to-peer)
=> distributed broker (multiple brokers, one each for a specific topic
or message queue)
=> distributed directory server (multiple directory servers to avoid a
single point of failure).

[1] www.best-of-robotics.org
[2] http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol
[3] http://www.zeromq.org/

AMQP Support in Orocos

On Mon, 7 Jun 2010, Nico Hochgeschwender wrote:

>
> my name is Nico and I am a research associate affiliated at the
> Bonn-Rhein-Sieg University of Applied Sciences (BRSU), Germany.
>
> In our group we are working with KU Leuven and other partners on
> the EU funded research project BRICS (Best Practice in Robotics [1]).
>
> Within BRICS we want to provide *good* tools, models, and functional
> libraries to accelerate the development of modern robotic applications.
> Ranging from development environments to communication middlewares and
> robotic software frameworks, we try to come up with solutions and "best
> practices" which are needed in the community.
>
> Here at BRSU, we assessed and screened the marketplace for
> communication middleware technologies/standards (e.g. CORBA,
> AMQP, DDS, and more) from a robotics perspective. We identified
> several needs for a communication middleware in our domain.
>
> * Data-centric applications: In robotics we build mainly data-centric
> applications (e.g. providers and consumers of sensor-data are
> distributed). We need a simple and easy support, to build such
> applications.
>
> * Loose coupling: For the sake of reuseability we do not want to couple
> components, therefore a communication middleware should provide means to
> build such loosely coupled applications in terms of time and
> location-transparency.
>
> * Interoperability: In order to be interoperable with heterogenous
> components the "common language" should be the data types which are
> communicated.
>
> * And even more :)
>
> Coming back to the marketplace, message-oriented communication
> middleware are exactly adressing this demands. Interestingly, (to the
> best of my knowledge) no common robotic software framework (e.g. Orocos,
> Player, OpenRTM-aist) supports a pure message-oriented communication
> middleware as a AMQP or DDS implementation. Therefore, we propose to
> "integrate" an AMQP implementation (see below ZeroMQ as a proposal) in
> Orocos. We would like to work on such an "integration".
>
> The intend of this post is to get opinions from the Orocos developers
> about the feasibility of a AMQP support in Orocos and about potential
> barriers. I am looking forward for your feedback.

I am fully supporting this ambition :-)

ZeroMQ is certainly a good candidate, and I agree with your summary of its
pros and cons. I would like to add OpenSplice <http://www.opensplice.org>
to your radar (e.g.,
<http://www.opensplice.com/section-item.asp?snum=3&sid=352>); the
disadvantage of OpenSplice is that it does not contain all the features of
the commercial version, and the fact that there _is_ a commercial version
is not a good omen...
The DDS standard
<http://en.wikipedia.org/wiki/Data_Distribution_Service>
<http://www.omg.org/technology/documents/dds_spec_catalog.htm>
is also implemented by OpenDDS, but that is built on top of ACE/CORBA, so
it brings some of the problems you mention.

Another, more complex but also much more professional, AMP middleware
project (LGPL) is OpenSAF <http://www.opensaf.org/>.
It provides AMP, including "the ability to discover, monitor and manage
the hardware resources in the underlying platform in a manner that is hardware independent"
<http://www.saforum.org/doc/AdobeViewer.asp?doc_filename=/HOA/assn16627/documents/The_Service_Availability_Solution_FINAL_Whitepaper.pdf&sfind=&print=1&docid=332912>
which is feature that every middleware (and framework like Orocos) must
have in order to be really useful in professional, heterogeneous
application environments.

Best regards,

Herman

> Nico
>
> ZeroMQ:
> -------
> Please find below a compiled list of features provided by ZeroMQ. Please
> refer also to [3].
>
> License:
> => LGPL
>
> Supported programming languages:
> => C
> => C++
> => Java
> => Python
> => and more
>
> Supported operating systems:
> => Linux
> => Mac OS X
> => NetBSD
> => and more
>
> The ZeroMQ message-oriented middleware is based on the AMQP model [2]
> and specification. In contrast to other message-oriented middleware,
> ZeroMQ provides different architectural styles of message brokering.
>
> Usually, a central message broker is repsonsible for message delivering.
>
> This centralized architecture has serveral advantages:
>
> => loose coupling of senders and receivers
> => lifetime of senders and receivers do not overlap
> => broker is resistent to application failures
>
> However, the centralized architecture also has several disadvantages.
> Firstly, the broker incurs an excessive amount of network communication.
> Secondly, due to the potential high load of the message broker, the
> broker itself can become a bottleneck and the *single point of
> failure* of the messaging system.
>
> Therefore, ZeroMQ supports different messaging models:
>
> => broker (as mentioned above)
> => brokerless (peer-to-peer coupling)
> => broker as directory server (senders and receivers are loosely coupled
> and they find each other via the directory broker, but the messaging
> is done peer-to-peer)
> => distributed broker (multiple brokers, one each for a specific topic
> or message queue)
> => distributed directory server (multiple directory servers to avoid a
> single point of failure).
>
>
> [1] www.best-of-robotics.org
> [2] http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol
> [3] http://www.zeromq.org/
>
>
>
>
>

AMQP Support in Orocos

Hi Herman,

> I am fully supporting this ambition :-)

Very good to know :)

> ZeroMQ is certainly a good candidate, and I agree with your summary of its
> pros and cons. I would like to add OpenSplice <http://www.opensplice.org>
> to your radar (e.g.,
> <http://www.opensplice.com/section-item.asp?snum=3&sid=352>); the
> disadvantage of OpenSplice is that it does not contain all the features of
> the commercial version, and the fact that there _is_ a commercial version
> is not a good omen...

I looked also (not very much in detail) into OpenSplice [1], MilSoft
[2], and CoreDX [3]. However, as you mentioned, they are (or some
verions) are commercial; a good reason *not* to consider :)

> The DDS standard
> <http://en.wikipedia.org/wiki/Data_Distribution_Service>
> <http://www.omg.org/technology/documents/dds_spec_catalog.htm>
> is also implemented by OpenDDS, but that is built on top of ACE/CORBA, so
> it brings some of the problems you mention.

That is exactly the problem; to the best of my knowledge OpenDDS is the
only free implementation of the DDS specification. See above.

> Another, more complex but also much more professional, AMP middleware
> project (LGPL) is OpenSAF <http://www.opensaf.org/>.
> It provides AMP, including "the ability to discover, monitor and manage
> the hardware resources in the underlying platform in a manner that is
> hardware independent"
> <http://www.saforum.org/doc/AdobeViewer.asp?doc_filename=/HOA/assn16627/documents/The_Service_Availability_Solution_FINAL_Whitepaper.pdf&sfind=&print=1&docid=332912>
>
> which is feature that every middleware (and framework like Orocos) must
> have in order to be really useful in professional, heterogeneous
> application environments.

Thanks. In particular the hardware monitoring stuff might be of interest
for us. I have to check whether there is already a mature implementation
of the OpenSAF specification...

Best regards,
Nico

[1]http://www.opensplice.com/
[2]http://dds.milsoft.com.tr/en/dds-home.php
[3]twinoakscomputing.com/snews/products/coredx-data-distribution-software

AMQP Support in Orocos

There already been small discussions about MOM middleware [1]. I'm also in
favor of such an implementation, since there's interesting features such as
redundancies of brokers. Also, we had many performance problems with CORBA
with a non perfect network setup. Does ZeroMQ supports Windows? Also, did
you look at Apache Qpid which tends to be a major player in AMQP ?

Philippe

[1] http://www.orocos.org/forum/rtt/rtt-dev/rtt-and-ocl-200-beta1-released

2010/6/7 Nico Hochgeschwender <nico [dot] hochgeschwender [..] ...>

>
> Hi all,
>
> my name is Nico and I am a research associate affiliated at the
> Bonn-Rhein-Sieg University of Applied Sciences (BRSU), Germany.
>
> In our group we are working with KU Leuven and other partners on
> the EU funded research project BRICS (Best Practice in Robotics [1]).
>
> Within BRICS we want to provide *good* tools, models, and functional
> libraries to accelerate the development of modern robotic applications.
> Ranging from development environments to communication middlewares and
> robotic software frameworks, we try to come up with solutions and "best
> practices" which are needed in the community.
>
> Here at BRSU, we assessed and screened the marketplace for
> communication middleware technologies/standards (e.g. CORBA,
> AMQP, DDS, and more) from a robotics perspective. We identified
> several needs for a communication middleware in our domain.
>
> * Data-centric applications: In robotics we build mainly data-centric
> applications (e.g. providers and consumers of sensor-data are
> distributed). We need a simple and easy support, to build such
> applications.
>
> * Loose coupling: For the sake of reuseability we do not want to couple
> components, therefore a communication middleware should provide means to
> build such loosely coupled applications in terms of time and
> location-transparency.
>
> * Interoperability: In order to be interoperable with heterogenous
> components the "common language" should be the data types which are
> communicated.
>
> * And even more :)
>
> Coming back to the marketplace, message-oriented communication
> middleware are exactly adressing this demands. Interestingly, (to the
> best of my knowledge) no common robotic software framework (e.g. Orocos,
> Player, OpenRTM-aist) supports a pure message-oriented communication
> middleware as a AMQP or DDS implementation. Therefore, we propose to
> "integrate" an AMQP implementation (see below ZeroMQ as a proposal) in
> Orocos. We would like to work on such an "integration".
>
> The intend of this post is to get opinions from the Orocos developers
> about the feasibility of a AMQP support in Orocos and about potential
> barriers. I am looking forward for your feedback.
>
> Best regards,
> Nico
>
> ZeroMQ:
> -------
> Please find below a compiled list of features provided by ZeroMQ. Please
> refer also to [3].
>
> License:
> => LGPL
>
> Supported programming languages:
> => C
> => C++
> => Java
> => Python
> => and more
>
> Supported operating systems:
> => Linux
> => Mac OS X
> => NetBSD
> => and more
>
> The ZeroMQ message-oriented middleware is based on the AMQP model [2]
> and specification. In contrast to other message-oriented middleware,
> ZeroMQ provides different architectural styles of message brokering.
>
> Usually, a central message broker is repsonsible for message delivering.
>
> This centralized architecture has serveral advantages:
>
> => loose coupling of senders and receivers
> => lifetime of senders and receivers do not overlap
> => broker is resistent to application failures
>
> However, the centralized architecture also has several disadvantages.
> Firstly, the broker incurs an excessive amount of network communication.
> Secondly, due to the potential high load of the message broker, the
> broker itself can become a bottleneck and the *single point of
> failure* of the messaging system.
>
> Therefore, ZeroMQ supports different messaging models:
>
> => broker (as mentioned above)
> => brokerless (peer-to-peer coupling)
> => broker as directory server (senders and receivers are loosely coupled
> and they find each other via the directory broker, but the messaging
> is done peer-to-peer)
> => distributed broker (multiple brokers, one each for a specific topic
> or message queue)
> => distributed directory server (multiple directory servers to avoid a
> single point of failure).
>
>
> [1] www.best-of-robotics.org
> [2] http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol
> [3] http://www.zeromq.org/
>
>
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

AMQP Support in Orocos

Hi Philippe,

> There already been small discussions about MOM middleware [1]. I'm also
> in favor of such an implementation, since there's interesting features
> such as redundancies of brokers. Also, we had many performance problems
> with CORBA with a non perfect network setup. Does ZeroMQ supports
> Windows? Also, did you look at Apache Qpid which tends to be a major
> player in AMQP ?
>

ZeroMQ supports Windows. I looked also into Apache Qpid [1] and RabbitMQ
[2].

My personal opinion is that RabbitMQ and ZeroMQ are much more
mature with respect to the reported user stories, supported
operating systems, and supported programming languages.

But, that is actually a pitty "all" of them claim to be compliant with
the AMQP specification. As we know, several CORBA implementations
claimed this as well :)

[1] http://qpid.apache.org/
[2] http://www.rabbitmq.com/

> [1] http://www.orocos.org/forum/rtt/rtt-dev/rtt-and-ocl-200-beta1-released

Wrapping up the discussion on the above post, AMQP could be
another "transport" mechanism without any dependencies for
Orocos itself, and AMQP could be an ideal candidate for the
redesigned data flow in RTT 2.0?!

By the way, I am pretty new to Orocos :)

Regards,
Nico

0MQ and AMQP

For info, 0MQ does not implement AMQP but a simpler brokerless architecture. The 0MQ API looks like message-aware sockets. AMQP's main weak points (from my experience from designing and implementing it) are that it is relatively complex to learn and use, and depends on a central broker. Also there are many versions of the protocol (0.8, 0.9, 0.91, 0.10) that do not work together, and all different from the eventual 1.0 version. If you do not mind these issues then RabbitMQ makes a good broker. iMatix's OpenAMQ is also a good broker. 0MQ has a tiny footprint, memory and CPU. AMQP is rather heavier, doing much more work per message. This gives us very different performance profiles: 50-100K messsages/second with AMQP vs. 4M-8M msg/sec with 0MQ. 0MQ does not do persistent (disk-based) messaging.

The best way to understand the differences is simply to try. It will take you about an hour to start to use 0MQ, a day to understand it and write some real applications. Since I live in Brussels I can come to KU Leuven if someone there wants help in using 0MQ. But it's really so simple...

0MQ and AMQP

For info, 0MQ does not implement AMQP but a simpler brokerless architecture. The 0MQ API looks like message-aware sockets. AMQP's main weak points (from my experience from designing and implementing it) are that it is relatively complex to learn and use, and depends on a central broker. Also there are many versions of the protocol (0.8, 0.9, 0.91, 0.10) that do not work together, and all different from the eventual 1.0 version. If you do not mind these issues then RabbitMQ makes a good broker. iMatix's OpenAMQ is also a good broker. 0MQ has a tiny footprint, memory and CPU. AMQP is rather heavier, doing much more work per message. This gives us very different performance profiles: 50-100K messsages/second with AMQP vs. 4M-8M msg/sec with 0MQ. 0MQ does not do persistent (disk-based) messaging.

The best way to understand the differences is simply to try. It will take you about an hour to start to use 0MQ, a day to understand it and write some real applications. Since I live in Brussels I can come to KU Leuven if someone there wants help in using 0MQ. But it's really so simple...

0MQ and AMQP

AMQP seems to bo implemented in 0MQ-1 and version 2 seems to drop AMQP
protocol support (as well as SCTP),
at least for this moment. Version 2 seems to have a much cleaner API, at
least from the point of view of simple messaging
requirements.

Piotr

On Thu, Jun 17, 2010 at 00:46, <ph [..] ...> wrote:

> For info, 0MQ does not implement AMQP but a simpler brokerless
> architecture. The 0MQ API looks like message-aware sockets. AMQP's main
> weak points (from my experience from designing and implementing it) are that
> it is relatively complex to learn and use, and depends on a central broker.
> Also there are many versions of the protocol (0.8, 0.9, 0.91, 0.10) that do
> not work together, and all different from the eventual 1.0 version. If you
> do not mind these issues then RabbitMQ makes a good broker. iMatix's
> OpenAMQ is also a good broker. 0MQ has a tiny footprint, memory and CPU.
> AMQP is rather heavier, doing much more work per message. This gives us
> very different performance profiles: 50-100K messsages/second with AMQP vs.
> 4M-8M msg/sec with 0MQ. 0MQ does not do persistent (disk-based) messaging.
>
> The best way to understand the differences is simply to try. It will take
> you about an hour to start to use 0MQ, a day to understand it and write some
> real applications. Since I live in Brussels I can come to KU Leuven if
> someone there wants help in using 0MQ. But it's really so simple...
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>