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

Herman Bruyninckx wrote:

> On Wed, 9 Jul 2003, Henrik I. Christensen wrote:
>
> [...]
> > Yep OROCOS should provide an abstraction for IPC and below the
> > abstraction one might use Corba (as KTH/FAW uses TAO). One problem is
> > often to provide the hiding in such a fashion that the programmer of
> > OROCOS is completely hidden from the Corba layer, but this should be
> > the case. For general communication to make it transparent across
> > templates... (all the fancy C++ features) is use of valuetypes, which
> > makes programming more difficult to understand, but the software
> > engineering is "prettier", so there is trade-off.
>
> Are you aware of some sort of "Howto" about this topic? (I.e., about
> how and why to hide CORBA from programmers.)

Hiding CORBA is absolutely necessary from my point of view. Why ? CORBA is
not only a moving target, it also offers such a variety of features that it
is very hard for an unexperienced user to make the appropriate selections.
A component builder for example wants to focus on his application domain
instead of becoming a software or even a CORBA expert. The purpose of a
framework is just to provide easy to use means to support users in such a
way that they can build upon already approved patterns and therefore
approved solutions. If you look at CORBA how difficult it is to use
valuetypes etc. or asynchronous method invocation correctly, you know what
I am talking about.

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. The only place where you get
in touch with CORBA is at the communication objects where the to be
transmitted data structures have to be described in IDL. This however is
even not visible if you only use communication objects on which the
community has already agreed upon (by the way that will be the key to
really have pluggable components !!!). Hiding CORBA now even allows the
framework builder to select that CORBA mechanism which best fits the needs
of the patterns. What does this mean ? CORBA for example provides
asynchronous method invocations in that in even two flavors, but also
oneway with guarantees (for example guaranteed delivery at the remote
object). I currently use the oneway instead of the AMI, but switching to
AMI if that should make sense at some time will be invisible to the
framework user. Furthermore, the communication objects for example
completely hide any pain with CORBA name space data types. Their methods
are completely "unpolluted" and can even use STL classes which are much
more common etc.

Christian Schlegel

--

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