About DOM and CORBA

[Didier PH Martin]

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 at netfolder.com
http://www.netfolder.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)