Re: CORBA performance - why CORBA

[Michael Meeks <michael peabody ximian com>]

Hi Guys,

On Fri, 7 Dec 2001, Diego Sevilla Ruiz wrote:
> BS> I don't understand why I keep hearing this, when CORBA itself
doesn't
> BS> guarantee message delivery for oneway calls. Sure, Orbit may give
that
> BS> guarantee (how can it?)

        It garentees only that the message will be delivered at some stage
- assuming the application does not die. If the application dies - it's
rather hard to deliver - so that's hardly a problem.

        ORBit2 also specifies that it will always arrive, and that it will
arrive in the right order - simply because all it's streams are connection
based, and always will be - as are pretty much ever ORB's.

        I'm not aware of an ORB where there are any issues with using
oneway in terms of loss / re-ordering.

> BS> but ignoring this is precisely the kind of transparency that
> BS> is actually a dangerous simplification.

        Not at all, for the above reasons; go find an ORB that doesn't
talk to ORBit2 via TCP/IP - it won't be able to - since ORBit2 doesn't
support any non-connection based protocols.

        Of course - there might be ordering problems - according to the
spec, but then find me an ORB that re-orders it's method invocations.
Again I suspect you'll have no joy.

        So - yes - it does assume more than the spec says, and yes that's
an extremely reasonable and sane thing to do - which is why oneway is
great.

        An analogy is that when you build a footbridge, you design it so
it will not fail under the load of as many fat people as can fit on it
jumping up and down. You do not design it against people loading a huge
mound of large lead blocks in the middle.

> Perhaps, it's time now, with ORBit2, to implement some kind of
> asynchrony following the OMG standard for it (as commented out in the
> articles).

        Go for it - all the code is there to do it - it _should_ be
relatively simple to make it comply to the standard - not that I've had
time to read it yet; still in my TODO.

> The idea behind it is allowing the client deciding the asynchrony
> of its invocations regardless of the contract (IDL) used.

        Great - if you want to write the code do; it'd be really good to
have; let me know when you start.

        Regards,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot