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

[Elliot Lee <sopwith redhat com>]

On Tue, 15 Sep 1998, Phil Dawes wrote:

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

It does need to be defined, because it provides a service, and services
*usually* have a defined interface via which they are accessed and/or
administered, and a defined set of functionality. TAO's IMR has a defined
interface, so I don't see why you're saying that the IMR doesn't need to
be defined. 

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

Not necessarily:

typedef sequence<string> stringlist;
interface IMR {
	object activate_object(string object_name, stringlist preferred_methods);
};

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

You can do it on a connection level ("ioctl(fd, FIONREAD, ...)"),
or you can send an invalid GIOP message and expect an error back.

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

It is involved with the life cycle of servers internally (it starts them,
and knows when they are running and stop running), it just doesn't give
the user the control.

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

Err I meant to say "The clients should be able to have control" over when
the servers live and die, because the clients know how they are going to
use the servers.

If a server wants to stick around as a daemon, that's fine - my point was
that the TAO IMR doesn't allow the distinction.

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

Yes, but that doesn't have anything to do with the IMR. Allowing servers
to do LOCATION_FORWARD on objects they are currently providing could be
implemented using the following operation:

module CORBA {
	interface Object {
		void forward(in Object new_location);
	};
};

That doesn't have a whole lot to do with the IMR... You just keep a list
of forwarded object references on the server side.

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

I don't want the client to be able to control how the object is
implemented, I want them to be able to control how the object is accessed
(same address space, remote calls, whatever), because the client knows
what type of service it requires from the object, and therefore what
access method is best.

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

The POA spec allows persistence of ObjectId's, but that doesn't directly
translate to persistence of objects (it might be able to though, using a
custom servant manager and -ORBBindAddr or whatever). You know how much
the CORBA spec says about persistent objects themselves? It's a two-line
glossary entry :)

To have truly persistent objects, you would need to either have an IMR
daemon running (how do you get the IOR to this, to use in your
as-yet-undefined IMR interface? Nobody knows), or that the client-side ORB
would treat persistent IOR's specially, and start/load servers for them. 
Both ways are horrible.

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

gnome-name-service already does this.

> how do you activate objects which haven't been 'looked up' by name?

Hmmm? What do you mean?

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

Why do we need to support "persistent objects activated transparently from
shared libraries"?

You're using an aweful lot of buzzwords, and it's not apparent to me what
advantages this gives over the give_me_a_factory("foobar") function in
baboon... give_me_a_factory("foobar", "shlib") is functionally equivalent
to string_to_object(persistentIOR), but is a good bit less complicated to
implement, and no less complicated on the client side. I'd say that makes
it better :)

I am wary of adding features just because people have warm fuzzy feelings
about them. These are not features that are required in the CORBA spec,
and they don't give you any advantages afaics.

-- Elliot
Progress (n.): The process through which Usenet has evolved from smart
people in front of dumb terminals to dumb people in front of smart
terminals.  -- obs@burnout.demon.co.uk