On 23-Aug-1999, Daan Leijen <[EMAIL PROTECTED]> wrote:
> The bad thing is that Corba is not a binary protocol and thus H/Direct needs
> a different backend/mapping for each different Corba vendor. Many languages
> provide a Corba binding by providing their own Corba environment and
> interacting with other Corba environments via the IIOP (internet)
> protocol of Corba which *is* a binary standard.
Well, it's a bad thing if you want to have an easy mapping to every
vendor's implementation. The nice thing about different
backends/mappings for each vendor is that you can optimize them (or even
just implement them) on a variety of platforms without having to worry
about how you would implement or optimize the same thing on different
platforms, or whether your approach is generalizable to other languages.
One nice thing about this is that it seems the ORBit folks
have figured out how to implement a CORBA method call for not much more
than the cost of a standard C call in the case of same address space
objects. You can discuss the pros and cons of both cases all day long.
I think it would have been a good idea for the CORBA people (OMG) to define
*a* binary standard which ORBs should implement, because this would make
things easier for language vendors who don't want to do too much work.
Maybe they do -- there are lots of standards on the OMG web site ;-)
The language mapping as it appears to the user is of course quite
standard (a few initialization calls are vendor specific).
So one alternative (which we employed to implement the MCORBA binding
of CORBA for Mercury) is to target a standard language mapping.
We targetted the C++ language mapping. So Mercury programs wanting
to invoke methods on CORBA objects actually invoke C++ methods,
which talk to the ORB for us -- all we needed to do this was a
C FFI.
And programs that want to interact with CORBA objects implemented in
Mercury have the ORB call C++ which calls Mercury. So we just needed
a reverse C FFI for this.
> Supporting Orbit however seems quite easy and it would be very cool to have
> around, allowing for a comparison between COM and ORBit.
> You should contact Sigbjorn Finne on the exact details but if
> ORBit looks like COM (which is probably true) than it wouldn't
> too much work.
ORBit probably does look a bit like COM because it aims at very
efficient same address space calls. If it's nice and small and
has IIOP support (which it should get at some stage at least) then
you can use it to talk with any other vendors ORB (all ORBs are supposed
to speak IIOP to each other).
Of course you'll need to check on the exact status of ORBit. When
we started work on MCORBA it was very very rough.
If enough people are interested (say 5 or more) in starting a mailing
list on the topic of FFIs, component interfaces, etc for declarative
languages (Haskell and Mercury come to mind) then I would be interested.
(I chose 5 because I think I already know 5 people who might be
interested in the topic).
[shameless plug mode on]
Also if people are interested in MCORBA, there is a paper at
http://www.cs.mu.oz.au/mercury/information/papers.html
I will be giving talks on the MCORBA system at
- K.U. Leuven on 31st August 10am
- Microsoft Research Cambridge on 9th Sep.
[shameless plug mode off]
Tyson.
