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

[Phil Dawes <philipd parallax co uk>]

Sorry I took so long to reply to this email - I've got a bit of an email
backlog at the moment ;)


Elliot Lee wrote:
> 
> 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.
> 

The IMR doesn't require an interface to be accessed. Administered,
perhaps - although products like ORBix use command line and gui tools to
deal with this (which is just as proprietary when you think about it,
but doesn't pollute the server code).

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

This isn't what I meant. The client doesn't 'activate the object' - the
IMR does (invisibly to the client and orb). However the person
registering the implementation with the repository needs to tell it how
to activate the object when the client requires it.


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

Oooh - that's really smart! :)


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

Not really. The IMR doesn't affect the semantic lifecycle of the objects
- to the client it should be as if the persistent object was always
running. The IMR just provides a neat way of implementing this 'always
running-ness'.

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

I don't think the clients should only have control over the lifecycles
of the servers at all. I think they may want to control the lifecycles
of the *objects* in some way, but shouldn't be able to say when a server
lives or dies.


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

The IMR provides specifically 'daemon' behaviour. You register servers
which implement 'daemon' objects (i.e. persistent) with the IMR, and the
IMR then provides activation on demand. Exactly the same semantic
functionality could be achieved by starting up all your daemon servers
containing persistent objects when the machine boots and leaving them
running. However this would be wasteful (especially when scaling to
10000+ objects) so instead we use an IMR.


> > 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.
 
Yes, you could do this as well, but the IMR additionally provides a
default lookup point for the orb if all else fails. The orb would look
for the object at the usual point (or points if the IOR contains many
addresses to try) - then if all else fails it will try the IMR (the last
address in the IOR - it won't actually know it's trying the IMR). The
IMR has the ability to check if the server is running and actually start
it if it's not.

This allows the object to change position without leaving a paper trail
- as a basic requirement it only needs to inform the IMR of its new
position. This provides some degree of scalability and robustness in a
distributed system.


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

The client program doesn't have (and never will have) the power to
decide what access method is best - that is decided by the person who
writes the object. 
What's the client program going to do - dynamically re-write an
executable object server as a shared library? ;-)

I'm not keen on this idea of the client explicitly activating the
object. It doesn't give the client anything and it removes the
flexibility from the object developer. I don't think the client should
care where its object resides - it should just gain a reference to the
object and use it.

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

You *do* have an IMR daemon running. You don't need to tell the ORB.

Let me say again: The client/client ORB does *NOT* use any interface to
the IMR. It doesn't even *know* the IMR exists. All it does is get a
reference to an object and then use it.

The orb attempts to make the call on the object, but the persistent
object reference host/port points to the IMR so the call ends up there.
The IMR then identifies the object that the request was intended for,
starts it if required, modifies the reference to point to the object and
sends a LOCATION_FORWARD back to the orb. 
*No interface is used*.
*The client-side orb doesn't do anything special at all*.


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

I was wondering how if the persistent object reference was obtained
through other means (e.g. stringified IOR, trader, gnome-specific 'I
want an object which supports this interface on this display') and the
namingservice has never been used, how does the activation work? 
Must you always use the naming service?
Can you only deal out references to objects on servers that are
currently running?


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

Because every factory is a persistent object, and you need factories to
create transient objects. In baboon there are going to be a lot of
client owned transient objects created and so it makes sense to have
them created as shared libraries. However you may decide that you need
to implement the object in its own executable (perhaps on another
machine) at a later date - hence the transparency.


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

string_to_object(IOR) (or indeed any method of gaining an object
reference) is infinitely better and definitely not functionally
equivelent to give_me_a_factory("foobar","shlib").

First of all with give_me_a_factory("foobar","shlib") you've specified
that the factory object is a shared library. This hasn't given you
anything - if the object was implemented as a shared library it would be
loaded into your address space anyway. Instead you've restricted the
migration of the object - it can never be moved or implemented as
anything else other than a shared library. And you loose scalability and
opportunities for transparent load-balancing in the future.

Secondly you've asked for a factory. This means that you have to create
a new transient object. There is nothing wrong with this approach for
this type of object, but the example was with a persistent object. What
happens when you want to implement singleton objects? Are you going to
create a printer object every time you want to use a printer?

Finally you still haven't solved the chicken and egg problem. Where does
your factory come from? Some pre-designated place on the disk? What
happens if the client implementation isn't on the same filesystem as the
factory? Perhaps a pre-designated host/port...?


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

I understand - I'm very susceptable to the 'we're doing it the corba
way, so it must be good' affliction. However I think the IMR is a *very*
good idea. All the corba vendors have this functionality - and they're
not all stupid. 

It has the following advantages for gnome:


1) It is not invasive. A server implementation does not have to be
registered with it, and the client doesn't even know about it. 
The fact that it seperates activation from creation and does not involve
itself with the lifecycle of objects is powerful - this
factory-pattern-fits-all idea is a bad one, forcing the creation of each
new object before use. COM suffers from this problem and the designers
are attempting to backtrack from it (see monikers,
running-object-tables, global-interface-tables and the singleton hacks
in MTS). 

2) It provides a mechanism whereby the client can know a default
position (host:port) for an object, but the orb can still recover if the
object isn't there 

3) It allows object implementations to move about silently and
transparently without affecting the service to the client - this is very
powerful. When we start to use corba orbs and baboon applications like
we use web servers and browsers today this will become even more
apparent.

4) It solves the chicken & egg bootstrapping factory objects problem
without polluting the client code or the server code, or requiring the
orb to magically know its location. 
This is because the client orb gets implicit details on how to activate
the implementation in the IOR of the object (i.e. host:port of IMR and
POA id), and doesn't do anything special to use them.

5) It can be used from *any* client orb. The orb does not need prior
knowledge about the IMR other than supporting LOCATION_FORWARD. 

I really hope I've convinced you. Location independence is a major part
of corba, and violating it gains us nothing.  It would be a shame to
throw that away with explicit and proprietary activation APIs.

Cheers,

Phil.

P.S. Perhaps if you replaced the name 'persistent object' with the name
'daemon object', and replaced IMR with orbit-activation-daemon...?