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

[Elliot Lee <sopwith redhat com>]

On Thu, 17 Sep 1998, Phil Dawes wrote:

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

When I was talking about a server, from the client's point of view the
only connection is that object reference. Servers and objects are
inextricably intertwined, because from the client's view, the one provides
the other.

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

Just thought of another problem with this TAO approach thing - it requires
that POA object ID's be unique in a global namespace, instead of a
per-server namespace.

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

ORBit object implementations can be used as both same-address-space and
remote implementations at the same time (and you can do fun things like
pass an objref or IOR for an implementation in your address space to
remote programs, and if you ever receive that objref back, the same
address space calls will be used). Once a process has activated an object
implementation with the POA and gotten an objref for it from the POA, the
location of the object is transparent as far as same address space vs. 
remote calls.

It is entirely feasible to allow the executable file to be dlopen()'d and
used just like an implementation inside a shared library, and it is even
easier than that to make a ten line wrapper around a shared library
implementation that turns it into a standalone server.

[moved from above]
> 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.

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

You're wrong:

The program using an object (aka client, aka application) has the big
picture of how that object will be used, how that object (aka
implementation) will relate to other applications, etc. That knowledge is
impossible for the object implementation to know, because a basic premise
of the OO model is being able to reuse an object implementation.

The client knows exactly what programmatic context the object will be used
in, so therefore the client is the only entity qualified to make the
decision of how the implementation is activated. 

Furthermore, I don't see how it _removes_ flexibility from the person
writing the object implementation (which you mean by "object developer", I
think). Elaborate...?

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

Yes, sorry, by saying "interface to the IMR", I mean more the interface
used to control it (register/unregister servers, etc.), but also an
interface that allows specifying the activation method, etc. etc.

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.

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

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

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

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. 

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

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

Whether it's better or not is discussed below, but it most definitely IS
functionally equivalent. There is no difference in the client-side end
result between an application retrieving a factory IOR from an external
source, and it calling give_me_a_factory(). There is a difference in how
the returned object reference happens to be implemented, but that
difference is invisible as far as client-side usage of that objref goes.

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

Providing mechanism in libraries, and leaving the policy up to the
application, is a big part of what I am 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.

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

(A better example might help me give a better answer :)

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

AFAIK, using factories or not is orthagonal to using an IMR.

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

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

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

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

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

[insert text from earlier in the document]
> I don't think the client should care where its object resides - it
> should just gain a reference to the object and use it.

You are speaking from a nice theoretical standpoint here, and I think it
sounds good in a textbook. In the real world, applications need control
over these things so they can get decent performance based on how they are
going to use the object. If an object's creation is initiated by a client,
that client should be able to have control over how the object is created.

As I pointed out above, this does not in any way contradict the goal of
location transparency for when the actual foobar::frobate() calls are made
(e.g. when you want to allow other clients to use an object that you
explicitly activated).

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

'persistent object' says 'state that persists between activations' to me,
not 'a widely provided service that is always available'. Factories are
usually not persistent because they most often do not save their state
between activations.

Ta,
-- Elliot
"In film you will find four basic story lines. Man versus man, man versus
nature, nature versus nature, and dog versus vampire."
    - Steven Spielberg