[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] About DOM and CORBA
Hi, We are currently working on a C++ DOM mapping. We took the time to read again the DOM specs and the appendices contains un ambiguous definitions for: - java - Ecma script. I say un ambiguous because these language binary interfaces are already specified and a Java implementation form one vendor should inter-operate with an other java implementation because java classes exposes standard binary interfaces. Thus, we can say that Java and JavaScript are really inter-operable because of this common interface binary signature. We have problems now with CORBA and I need some check from the dev community to be sure we didn't made any mistake in our interpretations. Here is the problem. OMG specify that IDL defined interfaces could be mapped to different languages and specify certain language mapping like for instance C++. So far so good. However under this rosy universe a shadow of doubt submerged our mind. Do OMG specify a standard binary interface for all object? This is necessary if we want to have object truly be inter-operable (not on paper but in the real world). Moved by the doubt, we checked again the OMG CORBA 2.2 specs and found a remote execution interface named IIOP (using internet for inter-object communication or binding) but we didn't found any binary interface specification for local execution. I mean here for objects running in the same address space as a host executable kind of dynamic libraries or shared libraries. <Question> Are we right or we missed a chapter defining a specific binary interface specification? </Question> <Implications> The implications of the lack of a standard binary interface definition for CORBA object leads to serious problems and more specifically to implementers following W3C CORBA interface definition as defined in the DOM level 1 appendix. If, as we think (but want to check with you the exactness of it) CORBA has no standard binary interface or standard binary signature for CORBA objects, then a manufacturer is free to implement its own signature. Thus, a certain manufacturer may choose a C++ type interface created with a VTBL or an other one may choose a different implementation with an other kind of binary interface. This would mean that an CORBA object would in practice be dependent on a specific manufacturer implementation and inter-operability would be more a wish than a reality. There is a chapter defining bridging with DCOM and some chapters on bridging CORBA objects among manufacturer. These last chapter just increased our doubts. The concrete implication of this is that if a parser with a DOM CORBA interface created with manufacturer X would not necessarily interface with manufacturer Y with a different binary signature without the usage of a translation bridge. The concrete implication is that we just added conversion overhead to the process. There is also a chapter on IIOP as an inter-object communication device. In this case, this implies that all communication between objects needs to a) serialize the call in IIOP format, uses a local port to communicate with the other object and then have the other object de-serialize the format into local function calls. Again, this process add unnecessary overhead to the process. </implications> <conclusion> If our interpretation is right, there is actually only two languages where W3C made clear recommendation and where objects created with such interfaces could communicate together without any ambiguity and a reasonable performance (no marshalling overhead). In reality, in the concrete world we should reduce this to a single language Java. Therefore the actual recommendation could be implemented and could run in the real world only for the Java language. Now, if someone want to implement the DOM with a C++ language may have serious problems with actual specs: a) OMG CORBA specify only interfaces but concrete manufacturer implantations could have their own idiosyncratic object binary signatures. b) If a C++ implementation uses CORBA, the only way to have real standardized communication between objects is through IIOP. This has the result of introducing an supplementary overhead and cancel all C++ speed improvement over interpreted languages. c) If a C++ implementation uses CORBA and bridging conventions, again supplementary overhead is introduced especially if object are in the same address space. Thus, C++ DOM implementation are not as formalized as Java. A C++ implementation is then felt in the cracks. <Conclusion> <Call for help> Are we right to interpret OMG specs like that? Did we missed something? If not, C++ implementation are still in the no mans land and there should be an interface proposal either from W3C or from an other party.If we are right, we propose a XPCOM (Mozilla) or COM )Microsoft) type interface. This type of interface is based on a standard C++ VTBL as defined by ANSI. All interfaces inherit from a IUknown interface. this last requirement being optional and not mandatory. At least, C++ objects would be able to inter-operate because of their common binary signature. I hope we wont get stupid answers to this request for help and that people will take the time to think and do their homework before replying, We would all benefit from a sane debate on this. The goal is not to bash on any one but to find a solution to a problem. We will publish a paper to help otehr implementation to at least get the same binary interface and result in concrete re-usage of C++ objects implemented by different parties. Thanks in advance for your input. </Call for help> Regards Didier PH Martin mailto:martind@n... http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|