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