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/
>
>
>
>
>

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
>