IMRs again (was Re: Comments on the baboon plugin spec)

[Phil Dawes <philipd parallax co uk>]

Elliot Lee wrote:
> 
> On Mon, 14 Sep 1998, Phil Dawes wrote:
> 
> > I was just wondering whether it might be better not to have the api
> > explicitly deal with shared libraries (i.e. dlopen etc..), but instead
> > register the component as a shared library with the implementation
> > repository. The client then treats it as a standard corba object (i.e.
> > uses nameservice/trader or stringified-IOR).
> 
> In case my opinion isn't clear, it is "screw the IMR".
> 
> The IMR is _totally_ undefined. Until the CORBA spec standardizes on an
> interface for it (CORBA 3.0 perhaps), it is just a piece of marketing
> terminology.

I don't understand this comment. The IMR doesn't *need* to be defined -
its use is transparent to the client.

Its true that the interface between the server orb and the IMR is
undefined, but then since both are made by the same people I don't
really see the problem. Perhaps if this interface was made explicit then
you could use different IMRs with different vendors server orbs, but I
don't see how this could be accumplished without forcing a specific
implementation of the IMR onto the vendor (since the activation strategy
- i.e. how to activate the server (fork, dlopen etc..), would need to be
apparent in the interface).
 
> Some ORB's have implemented a set of services that they call the IMR.
> People keep pointing at the TAO design because they think it is good.
> 
> The TAO service (which it calls the implementation repository) for
> handling activation of servers has these problems IMHO:
>         - Requires extensions (ping object, etc.) instead of using
>           existing CORBA spec behaviour.

What existing corba spec behaviour? AFAIK the corba spec doesn't mandate
how you check to see if a server is alive (NB. DCOM does however).
Besides, the pinging functionality isn't *required* - you don't have to
do it if you don't want to.
N.B. the pinging interface is handled by the orb internally - the client
code is not polluted by this proprietaryness.

>         - Duplicates the functionality of the naming service
>           (reading the Implementation_Repository interface shows
>            a definite overlap with the CosNaming::BindingContext
>            interface)

The naming service and the IMR fulfill completely different roles which
are in no way mutually exclusive. The naming service doesn't activate
persistent servers. The IMR doesn't map names to object references.

>         - Doesn't allow explicit control of the life cycle of servers,

Thats because it's specifically designed not to.

>           and no distinction between same-address-space and
>           remote servers (i.e. the servers are only as useful as the
>           clients using them, so the clients should have control over how
>           the servers live and die).

Yes, thats a fine assumption if there's only one client per server, but
unfortunately many corba services have to service multiple clients. In
these circumstances either the server controls its own lifecycle (i.e.
becomes a persistent object) or the clients indirectly control it (e.g.
ref counting, garbage collection, designated lifecycle controller)

Actually the client not knowing where the server resides is quite a
powerful thing - it provides scope for scalability, load balancing and
object migration. 

BTW why do you want the client to control how the object is implemented?
(I might be missing something here)


>         - Much of the interface works on a per-server basis rather than a
>           per-object basis, which means that the IMR becomes yet another
>           place where you have to muck with the internals of objrefs
>           for forwarding things, etc. (right now there are only ~4
>           routines in ORBit where objref internals are manipulated
>           directly, and it makes adding features like objref structure
>           reuse a lot easier).

Is this a problem? The client orb does nothing special with the object
reference other than support location forwarding - and that's standard
anyway.
The server orb does need to construct the persistent IOR somehow, but
then it would have to do that anyway to support persistent object refs -
regardless of how you implement them (and I personally can't see any
other way of implementing them other than using an IMR, or something
which duplicates its functionality).

> 
> LOCATION_FORWARD is a neat trick to use (adding support for this to ORBit
> on the client side would be nice), but because the TAO IMR _is_
> transparent, you lose a lot of control. So along comes the lifecycle(?)
> service to let you specify when servers start up and die and all that. You
> wind up running two things (IMR+lifecycle) instead of just doing the
> manipulation directly.
> 

Thats because you are dealing with two different problems! Persistent
objects (which always exist) and must magically be bootstrapped, and
objects with a defined lifecycle must be controlled by some designated
client(s).

BTW How do you intend on implementing persistent objects without an IMR? 
- How do you 'create' your lifecycle-managed objects if its not through
some factory? How does that factory get created? 
Answer: At some point a factory must be magically bootstrapped - it is a
persistent object which just 'exists', and the IMR allows you to do
this.

If you do decide to tie the activation of objects to the naming service,
how do you activate objects which haven't been 'looked up' by name?


> </misc thoughts>
> 
> > BTW I'm not sure that gnome_plugin is the right word for this
> > functionality - what we are implementing here is shared library orbit
> > corba servers. Perhaps 'orbit component' might be a better name.
> 
> This is a GNOME-specific extension, not a generic ORBit thing. It is
> orthagonal to a server being run in the same address space.
> ORBit is an ORB, not a component model. "Component" implies a lot more
> than just a shared object. etc. etc. etc.
> 

Yes, I agree that component is an overloaded term - my mistake.
I still think that this functionality is part of corba though. All the
top corba vendors support shared library objects - the spec even
mentions them. 

If orbit is to support persistent objects activated transparently from
shared libraries then it must have a bootstrapping
activation/deactivation API embedded in the shared library. I believe
this is exactly what you have defined in the gnome-plugin specification.

Cheers,

Phil.