Hello all,

we moved the discussion to "orocos-dev". See below.

>> I know RTT has ties into Corba, ROS, and YARP for extending the reach of
>> Orocos components into distributed systems. We would like to further extend
>> RTT into other middlewares, like DDS and/or ZeroMQ. Is there a guide
>> somewhere for how this should be done, or should I just look at the existing
>> extensions and improvise?
>
> A group in Bonn-Rhine-Sieg University near Bonn, Germany, is doing a
> similar effort with ZeroMQ nowadays. (There has been one or two messages
> about that on orocos-dev...)

Indeed. By that means we start with the discussion.

>
> I would like to keep the middleware stuff _completely_ out of the RTT
> source tree.
>

Agree.

> The way to go, in my opinion, is to (finally) start a decent discussion on
> orocos-dev about how this _should_ be done, since all efforts until know
> have been very ad hoc. (By lack of a decently _modelled_ separation of
> concerns between Communication (read 'middleware') and the other concerns
> (Computation, Coordination, Configuration and Connection).
> A very important aspect of this serious design is how to deal with the
> models for data flow, and how to integrate those models in the binaries
> that are being deployed, such that they become available for introspection.
>

We have posted this a while ago that we started to work on a ZeroMQ
integration to Orocos. We still have to tackle some conceptual issues
which we would like to communicate to the Orocos developers now.

The main goal which we want to achieve is to make all choices
concerning communication in distributed systems *explicit* and
*accessible* for the
system integrator. Moreover, the framework itself (in our case Orocos) should
not constrain the available functionality provided by a middleware.

(1) Use case: a user might want to use ZeroMQ as a communication
library, Google protocol buffer for message definition and
marshalling, and some ZeroConf implementation for service discovery
within the framework (e.g. Orocos). We call this the available "points
of variation" or "protocol stack view" (including service discovery,
IDL, messaging, and transport) and
we showed in our recent IROS paper that such a separation would allow
to improve a system with respect to quality attributes, e.g.
scalability. As an example we proved this concept by a naive
implementation with ZeroMQ plus custom marshalling.

(2) Use case: a user might want to use ZeroMQ features (e.g. software
network devices like Brokers or Proxies) in Orocos.

Now the question is how do we support these use cases in Orocos and
the current Orocos toolchain? Further, how should these aspects be
decoupled from RTT?

IMHO the first use case is right now quite tough to implement because
it would require several changes for the toolchain (e.g. orogen and
typegen). A naive implementation for the second use case would be to
provide standalone Orocos components providing only that special
functionality (e.g. Brokers). That would be similar to the TaskBrowser
and Deployer components already provided by OCL.

Nico & Azamat

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Hello all,

we moved the discussion to "orocos-dev". See below.

>> I know RTT has ties into Corba, ROS, and YARP for extending the reach of
>> Orocos components into distributed systems. We would like to further extend
>> RTT into other middlewares, like DDS and/or ZeroMQ. Is there a guide
>> somewhere for how this should be done, or should I just look at the existing
>> extensions and improvise?
>
> A group in Bonn-Rhine-Sieg University near Bonn, Germany, is doing a
> similar effort with ZeroMQ nowadays. (There has been one or two messages
> about that on orocos-dev...)

Indeed. By that means we start with the discussion.

>
> I would like to keep the middleware stuff _completely_ out of the RTT
> source tree.
>

Agree.

> The way to go, in my opinion, is to (finally) start a decent discussion on
> orocos-dev about how this _should_ be done, since all efforts until know
> have been very ad hoc. (By lack of a decently _modelled_ separation of
> concerns between Communication (read 'middleware') and the other concerns
> (Computation, Coordination, Configuration and Connection).
> A very important aspect of this serious design is how to deal with the
> models for data flow, and how to integrate those models in the binaries
> that are being deployed, such that they become available for introspection.
>

We have posted this a while ago that we started to work on a ZeroMQ
integration to Orocos. We still have to tackle some conceptual issues
which we would like to communicate to the Orocos developers now.

The main goal which we want to achieve is to make all choices
concerning communication in distributed systems *explicit* and
*accessible* for the
system integrator. Moreover, the framework itself (in our case Orocos) should
not constrain the available functionality provided by a middleware.

(1) Use case: a user might want to use ZeroMQ as a communication
library, Google protocol buffer for message definition and
marshalling, and some ZeroConf implementation for service discovery
within the framework (e.g. Orocos). We call this the available "points
of variation" or "protocol stack view" (including service discovery,
IDL, messaging, and transport) and
we showed in our recent IROS paper that such a separation would allow
to improve a system with respect to quality attributes, e.g.
scalability. As an example we proved this concept by a naive
implementation with ZeroMQ plus custom marshalling.

(2) Use case: a user might want to use ZeroMQ features (e.g. software
network devices like Brokers or Proxies) in Orocos.

Now the question is how do we support these use cases in Orocos and
the current Orocos toolchain? Further, how should these aspects be
decoupled from RTT?

IMHO the first use case is right now quite tough to implement because
it would require several changes for the toolchain (e.g. orogen and
typegen). A naive implementation for the second use case would be to
provide standalone Orocos components providing only that special
functionality (e.g. Brokers). That would be similar to the TaskBrowser
and Deployer components already provided by OCL.

Nico & Azamat

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.