[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: About DOM and CORBA

• From: "Gavin Thomas Nicol" <gtn@e...>
• To: "'Didier PH Martin'" <martind@n...>, "'XML Dev'" <xml-dev@i...>
• Date: Sat, 3 Apr 1999 18:19:57 -0500

> 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?

I don't understand exactly what you mean by this question. The OMG specifies
a standard mapping for *clients* such that code written to use C++ client
objects will generally work without changes no matter which ORB libraries
you compile against (that is the point of the standard mapping). IIOP
provides an interoperable way for clients to talk to server implementations
on any ORB.

That said, the same is not true of the *server* objects (object
implementations).
Different vendors give various classes different names, so it is usually
not possible to compile implementations created by one ORB vender withot
changes if you choose to use a different ORB vendor.

> 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.

Again, this is not true of clients, only servers. Clients can also
interoperate across languages. The only real issue here is that
some ORBs provide "fast-call" semantics such that object implementations
bound into the binary of the application do not incur IIOP overhead.
For a fine-grained interface like the DOM, this is crucial to good
performance, but in general in an interoperable environment, you
cannot take advantage of this.

> 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.

Again, for client code, interoperability is not a problem ( and even COM
gatewaying is seamless).

Anyway, one of the problems that I did point out to the DOM WG on a number
of occasions is that by defining the JAVA and ECMA bindings for the DOM,
we have given up interoperability there to a degree. For example, if you
run the DOM IDL through a JAVA IDL compiler, the generated client and
server interfaces will differ from those in the DOM spec.

I think that realistically, DOM used CORBA IDL only to provide a *default*
binding for languages defined by the OMG. From a practical perspective, the
DOM interfaces are too fine-grained for serious use in a distributed
environment, and "fast-call" semantics are not interoperable, so
there is room for a standard definition of DOM bindings for C++. C++
bindings would include all kinds of things, like binary compatibility,
memory management, etc, etc.


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...)

• References:
  • About DOM and CORBA
    • From: "Didier PH Martin" <martind@n...>

• Prev by Date: Re: About DOM and CORBA (long)
• Next by Date: Re: Anti-Microsoft Flames
• Previous by thread: Re: About DOM and CORBA (long)
• Next by thread: Re: About DOM and CORBA
• Index(es):
  • Date
  • Thread