Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at