Re: [boost] CORBA iimplementation for Boost interest?

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2008-04-02 03:50:37

Jonathan Franklin skrev:
> I would be much happier w/ something built on an architecture similar to
> ICE.
>   

ICE seems nice.  I have never really used it, just played around a bit 
some years ago.  The problem as I see it, with  ICE and other frameworks 
like it, is the fact that there are others like them that they usually 
are not compatible in critical ways.  If everybody try to make their own 
standards we will not have any.  That is the point of looking to IIOP or 
Web services, ICE, Spread, .Net remoting(on wire), ... etc. to provide 
solutions to compatibility with who you talk to on the wire.  
Essentially supporting existing and future wire standards, or standards 
in other layers in the protocol stack,  with a single transparent C++ 
solution may be way more desirable than tossing in your own wanna-be 
communication standard.  This is, and really should be much more a C++ 
community, and possibly standard, issue than it ever will become an 
issue for the members of OMG or other middleware providers.  They are 
concerned with what languages to support, some of them want to support 
many languages with their single middleware product.  Comercial tie-up 
is often more of a goal than a comfortable and smooth ride for their 
customers.  Fredom of choice is something they only want until they got 
you.  This would maybe be somewhat OK if any middle ware solution could 
talk to any other middleware solution.  But that is typically not the 
case, typically you have to have the same product in both ends.  The 
effect is income to middleware vendors and completly needless training, 
consultancy, porting and license cost for their customers.  CORBA is 
here somewhat better than the pack of other solutions, comersial tie-up 
is harder for the vendors.  If you really start to dislike great but 
expencive products like ORBExpress, then you can switch to any of the 
many other cheaper or free to use C++ ORBs.

If it is transperent to the application code I write in C++  what 
transport or wire standard is used, then I will be very happy.  In the 
C++ world this could be a traditional code generator like IDL to C++ or 
something like a compile time policy selection.  But there could also be 
support for a deployment/runtime pluggable protocol support and maybe 
even a solution that transperently switch back-end between method 
invokations at run time.  With something like that we are really closing 
in on something that would be of great use. 

One of the issues with the OO paradigm in  middleware like CORBA is that 
it tends to lead users to somewhat bloat use of concepts, like objects 
with methods, when something simpler is all that is needed.  In C++ I 
wich these requirements could be concepts like iterator concepts in 
STL.  If all I need is message passing to an transport level end-point, 
then I use that concept requirenment in C++ code.  If I really need a 
object to talk to on the other side, then I use a different concept.  
Then my function calls could be mapped to back end much like itterators 
to containers. 

Mapping between interface definition languages will also be needed to 
make all this work.  But that is really orthognal to a new C++ mapping 
for CORBA et. al.  There seems to be a CORBA IDL to WSDL mapping defined 
by OMG, and there are probably many others as well.  I have not studied 
any of them.

Side note:  I think there are efforts by MS within the .Net framework to 
make transport transperent to .Net based clients.  Likewise do many of 
the propriatory SOA frameworks do similar things.  I whish we got this 
in standarized portable  C++.  
> In a nutshell, when I need CORBA, I use TAO.  But I really want something
> else.
>   

Yes, but that does not exclude using CORBA ORBs like TAO as a back end 
for experimenting with a good C++ CORBA mapping.  If feasable this 
mapping should become front end for middleware communication solutions 
in general.  I therefore second the opinion that work on a C++ CORBA 
mapping is a great place to start.  I also wish this work has more focus 
on the needs of the C++ comunity than the OMG generally ever will.  That 
should definently not exclude OMG solutions/standards to new mappings, 
we should just have critical eyes to some details.  Tie-up with CORBA in 
this C++ front end is one step on the way of being as bad as tie-up with 
propriatory or none standardized back ends.  But I think, or hope, this 
may be avoided.  In the end of the day, a solution with CORBA tie-up is 
much better than nothing, and I think it would be a great project 
standing on its own feet.      

-- 
Bjørn