[mercury-users] MCORBA

[David Glen JEFFERY]

On 14-Jun-1999, Luke Evans <Luke.Evans at seagatesoftware.com> wrote:
> MCORBA will be a fairly important component in the project I've just started
> in Mercury.  This involves writing 'actors' in Mercury which define
> primitive data-mining functions which are installed onto the network.  These
> primitives then form the building blocks of more abstract, distributed, data
> analysis.  Obviously I could write the CORBAry bits in C++ and just bind
> this to Mercury via the C interface, but this seems a shame. 

That would indeed be a shame. Hopefully you will find that MCORBA does what you
are looking for.

We will be very interested to see what your experiences with MCORBA are...
please keep us posted. The current public release (0.2) has, I expect a
fair number of holes in it. I do, however, intend to put a fair amount of
effort into developing MCORBA further during the next few months, so your
feedback (and bug reports) would be very much appreciated. I don't at this
stage know when the next public release will be, but I'm sure we'll be able
to supply you with patches and bug-fixes as they become available.

> What I'd like to know at this juncture is how much MCORBA is dependent on
> the specifics of OmniORB.  

We put a fair amount of effort into ensuring that the C++ code that we
generate isn't OmniORB specific --- it should work with any ORB that adheres
to the C++ CORBA 2.0 spec.

However, there is a little bit of hand-coded C++ in the mcorba library which
calls the OmniORB initialisation code for things like the naming service. We're
probably only talking about 10 lines or so, and it is all in one place.
(Basically, rather than calling the COS Naming Service as a CORBA object, it 
is hard-coded... MCORBA is complete enough now that it should be able to
generate the correct code from the naming service's IDL, though). In any
case, just re-writing the hand coded C++ *shouldn't* be too hard.

> We
> found Orbacus to be about the best ORB for quality and completeness.  It has
> proper Interface Repository support as well as DII/DSI.  Support is second
> to none - we get patches from the developers within minutes/hours typically.
> The ORB is available for free to non-commercial organisations (and charges
> for 'developer licenses' for commercial operations), yet compares
> exceedingly well with the 'big boys' (Visibroker and Orbix).

Great. I may check it out. It would be good for us to test with more than one
ORB.

> How much effort would be involved to support Orbacus instead of OmniORB.

Very little, I'd imagine, although it has never been tested.

> What is the rationale for adopting OmniORB in the first place (or is this
> accidental)?  

Basically we were just looking for a complete implementation with a license
that suited our needs (and is available as a Debian Linux package). We certainly
have no intention of tying ourselves to it, though!

> I'm too lazy to have inspected the MCORBA code yet - I'm hoping to get easy
> answers!

Hopefully these answers were easy enough... let us know if you want more
information.


dgj
-- 
David Jeffery (dgj at cs.mu.oz.au) | If your thesis is utterly vacuous
PhD student,                    | Use first-order predicate calculus.
Dept. of Comp. Sci. & Soft. Eng.|     With sufficient formality
The University of Melbourne     |     The sheerist banality
Australia                       | Will be hailed by the critics: "Miraculous!"
                                |     -- Anon.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------