Re: First draft of "OROCOS II" proposal...

Anthony Mallet wrote:

> Christian Schlegel writes:
> | So I decided with Orocos::SmartSoft to hide the communication layer such
> | that the user space does not contain any CORBA details anymore and that one
> | can even exchange the underlying middleware.
>
> Note that we've been saying this from the very beginning of Orocos...
> But since I've been working with this idea in mind, a few doubts have
> shown up. Maybe you'll have answers :)

I try my best ...

> If you hide CORBA... why use CORBA at all? CORBA is already an
> abstraction of remote procedure calls and, to me, abstrating an
> abstration doesn't make much sense (even not talking about the
> overhead).

First of all, CORBA is completely independent of the operating system etc. You
do not have to cope with byte orders, marshalling etc. It is even available for
different programming languages and the interface description language (I at
least use the IDL for describing the to be transmitted part of a communication
object) is standard and powerful enough. So it is a good idea to build upon
widely accepted approaches.

The overhead can be neglected since the implementation can be done such that
patterns do not impose much additional load. Comparing the slight additional
load to what kind of overhead can be introduced by "wrongly" using CORBA or
trying to implement marshalling with RPC on your own is normally much higher. In
particular, the TAO people do know very well how to achieve efficient
implementations and I don't think it is a good idea to try to compete with that
large group of experts. Just take advantage of what they already developed !

Nevertheless, one could of course implement the patterns on top of RPC as well
and former versions of SmartSoft had been implemented on top of sockets for
example. But believe me, the TAO ORB is great !

Having an abstraction allows me to exchange the underlying communication
mechanism, the features used of CORBA etc. without bothering the SmartSoft user
with progress made at the lower levels. No component developer has to change
anything if I switch from oneway communication to AMI for example ...

>
> The CORBA approach is complex, that's true. If you hide it under a
> simpler layer... then you don't need all the complexity of CORBA, do you?
> If you can switch between different communication mechanisms
> transparently, then you're tight to the simplest of the mechanisms you
> would like to use..

Absolutely right ! CORBA provides much more than is needed in our robotic
applications for example. The danger is that you use that parts of CORBA which
are not adequate. But you can provide the knowledge of what parts are suited by
carefully selecting appropriate mechanisms and hiding them from the component
builder. So what is wrong if there are many many features which are not used ?
These do not influence us in any way. TAO has been selected because the goal of
that ORB is not only realtime, but efficiency ! And that can be experienced if
you compare it to other ORBs ...

> Maybe you'll answer: interoperability, standards, etc. But if you use
> RPC (or XML-RPC, or whatever), aren't you interoperable in the same way?
> Aren't these approaches standards too?

Yes, SOAP even works across middleware platforms. But then you really should not
care too much about efficiency. Those approaches are primarily good at providing
various levels of transparency. The TAO IDL compiler is optimized with respect
to providing very efficient marshalling mechanisms for example. There might be a
lot of applications where efficiency is not the big issue. In our applications,
it is (or still it is, perhaps at some time, computers are even faster ....)

> Thus I think that if one want to use CORBA, then one doesn't want to hide
> it, because CORBA was designed to provide a more powerful approach than
> existing ones, and it _is_ the abstraction already. This is complex, and
> that's the price... It doesn't make sense to use a complex and powerful
> infrastructure if it's hidden behind a simpler one...

I do not agree at all ! Why ? Patterns are in particular good in providing
approved solutions and the communication patterns are such an approved
solutions. The communication patterns provide a component approach where the
kind of interaction of components including the semantics of the interface
methods are exactly specified. Using a general middleware system does not answer
the question of how to ensure the semantic integrity of all the exposed
interface objects and their member functions. By the way, if you talk to people
trying to do object oriented design, they almost always worry about the lack of
semantic consistency of interface methods. In my view, it is completely right to
restrict a framework if it still provides what is needed by giving you support
in mastering the complexity of distributed applications. Using a complex and
powerful infrastructure gives me the good feeling that I know that I will always
find what is needed to implement the SmartSoft patterns. I also know that there
is a large community providing very good support and that I can rely on them.
Nevertheless, I also want to restrict the alternatives such that I can have
students, robotics people and software engineering experts at distributed places
contributing components such that they can work like plug-and-play. Only using
CORBA or other systems is not enough, the SmartSoft patterns already did a great
job in a variety of projects !

> I'm still convinced that the user space shouldn't contain any details on
> the communication layer, though :)

I always welcome any comments and questions and try to answer them as good as
possible. I of course do not claim that the "wrappers" I provide can be used or
make sense for _any_ application. It is just that there are at least a set of
applications where they already proved to be the right approach. So that gives
me the guarantee that the approach is feasible. One of the benefits of the
communication patterns is for example that you are always fully aware when
communication is involved. Since objects are always transmitted by value you
always know that accessing an attribute does not generate any hidden traffic.
Complete transparency which might be acceptable in business applications is not
wanted in robotics. Here you want to have some level of control on resources
without abandoning the advantages of transparency.

By the way, the patterns can be implemented on top of RPCs as well but building
robotic components on top of plain RPC calls is against my goal of complexity
management by decoupling.

Have a nice day :-))

Christian



--

---------------------------------------------------------------------
Christian Schlegel
FAW Ulm (Research Institute for Applied Knowledge Processing)
PO Box 2060
D-89010 Ulm
Germany

Tel. : ++49 (731) 501 8949
Fax  : ++49 (731) 501 999
email: [email protected]
WWW  : http://www.faw.uni-ulm.de/
---------------------------------------------------------------------