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

[Phil Dawes <philipd parallax co uk>]

Elliot Lee wrote:
> 
> If the IMR is a daemon, though, that totally excludes using
> same-address-space object implementations. You must have the IMR inside
> the client ORB in order to load implementations from shared libraries, and
> there goes your premise byebye.
> 

Actually no. The IMR can determine that the client orb is an orbit orb
through the vendor profile in the request. It then calls the orb through
a proprietary interface telling it that there is a shared library
located at path X and the orb then loads it and activates it. The client
doesn't see any of this.

If the orb isn't an orbit orb then the IMR simply starts a 'shared
library wrapper' executable which hosts the shared library object (like
you mentioned earlier) and sends a location forward to the client.


> > 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*.
> 
> Yes, that is the TAO way. It has now been explained enough times to me to
> be thoroughly engrained in my head ;-) It does possibly suffer from the
> POA Object ID problem noted above, though.

Yes, I think you might be right there. Actually no, the POA object ID
only needs to be unique in the IMR. That is an easier problem to solve,
because the IMR can validate the poa id on registration.



> > 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?
> 
> You must have some sort of standard directory listing of object references
> of objects that wish to advertise their availability to service requests
> for a specific interface. (See below)

Yes, but you don't want to have each and every one also responsible for
activating the objects if they are not running at the point the user
wants to use them. I suspect that that functionality is in the
name-service because thats the first service that got finished. If we'd
written a trader, or perhaps an interface->object lookup service we'd be
doing activation with that instead.




> > Can you only deal out references to objects on servers that are
> > currently running?
> 
> gnome-name-service starts servers for a name if they are not running and
> an executable is registered for that name.
> 
> I'm not convinced that gnome-name-service is the best place for storing
> information about servers that can be started. For example, it doesn't
> allow a client to choose between multiple implementations of the same
> interface, and doesn't allow the same address space object
> implementations.


IMR provides scope both of this (in conjunction with other services ;-).
It's nifty because it decouples the activation from the lookup, so these
services don't have to handle activation of the objects recorded in
them.
 

> Most likely what should be done is to write a spec for storing information
> on the available implementations and the ways they can be accessed. Then a
> libgnorba routine will exist to read that information in and provide it to
> the application, and another routine to activate an implementation with a
> specified type and activation method.
> 
> The activation methods that I can see using would be:
>         shared library - use the GNOME plugin API to load
>                          the implementation into our address space.
>         standalone - fork & exec type of thing.
>         relay - Use name service to lookup the IOR of a
>                 server activator object, and then pass the activation
>                 on to it (allows for distributing programs across
>                 a network, etc).
> 
> Much of this information is in the GNOME plugin spec, but
> we would probably want information such as "what interfaces are supported
> by implementation X" and "what is a human readable description of the
> functionality of implementation X".
> 
> The name service can be used to advertise the services of running
> implementations that wish to make themselves known. The activation routine
> would optionally work with the name service to see if an implementation is
> already running.
> 

Hmmm... What does this actually give you over an IMR? With an IMR the
user is free to tweak the activation policies of the objects
him/herself.


> > > 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.
> 
> I don't see how that is a problem. You just have your activation routine
> return a remote objref instead. There is perfect transparency as far as
> the app is concerned.

Yes but you're still specifying an activation 'routine'. This routine is
proprietary to baboon/ORBit. I'm saying you don't need a routine at all
- you can have a corba object to do this (the factory), and have it
activated implicitly upon use using the IMR. Surely this is better than
a proprietary activation routine - systems other than gnome can create
gnome objects and use them.

[snippage]

> > 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.
> 
> Not necessarily. You don't want this "if it's a shared library, it just
> happens magically". For example, you might want to run the same
> application on a really fast system and a really slow system. On the fast
> system, you obviously want the implementation loaded as a shared library,
> but on the slow system, it might be faster to talk over the network than
> do the computations on the local system.
> 

Exactly. 
Hmmm... So does the give_me_a_factory() function take the "shlib" arg as
a hint, not a command?


> Providing mechanism in libraries, and leaving the policy up to the
> application, is a big part of what I am arguing for.

Providing mechanism in libraries, and leaving the policy up to the
*user* is what I'm arguing for ;-)


> > Instead you've restricted the migration of the object - it can never be
> > moved or implemented as anything else other than a shared library.
> 
> 1. This is not true (see my above thing about how ORBit does same address
> space calls, etc.)
> 
> 2. This migration is called object by value (basically, allowing the state
> of the object to be transported for manipulation, instead of just an
> object reference), and until CORBA 2.3 comes out and we all see the spec
> and evaluate it, migration will happen on the application level, not the
> ORB level.

Object by value is one way of doing object migration (albeit a heavily
flawed one IMHO). What I meant was the users ability to replace one
implementation of the object with another (possibly remote) one without
upsetting, recoding (or touching) the client app. 


> > 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?
> 
> No, you are going to use the GNOME printing services ;-)
> 

But with an IMR you can write a gnome printing server which gets
activated on demand, regardless of whether the client is gnome oriented
or not.



> > 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...?
> 
> gnome-name-service is the currently source of all knowledge about what's
> running or can be run. The gnome-name-service IOR is stored as a root
> window property, which works for GNOME.

I'm not keen on this for the above reasons. 


[snip again]

> > 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).
> 
> AFAIK, using factories or not is orthagonal to using an IMR.

But activating your 'root' level factories is not. (i.e. the factories
you use to bootstrap your first transient objects)

> > 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
> 
> (Relying on a well-known port is a Bad Idea - you've instantly limited the
> flexibility of your system as far as "scalability and transparency". ;-)

But the point was that I've regained it by leveraging the IMR as a back
up plan if the ORB can't find that object at that host/port . I'm still
waiting for a better solution to this ;-)


> > 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.
> 
> Already covered, already possible.

Okay. (still need to use proprietary 'get_factory' though)


> > 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.
> 
> Already covered. Would work fairly nicely if ORBit supported
> LOCATION_FORWARD (which it will once someone gets around to making that
> happen).

Dick's expressed an interest in doing this. Anyway, I don't see how your
'get_factory()' call can be made from any orb - its not on a corba
interface (and if it was, you'd still need a way of bootstrapping it).


> > I really hope I've convinced you.
> 
> No, but you definitely _have_ helped my understand your viewpoint better
> by writing a clear point-by-point like this, and that is very much
> appreciated.
> 

My pleasure :-)

Cheers,

Phil.