[omniORB] Implementation Repository

[Duncan Grisby]

On Wednesday 15 January, baileyk@schneider.com wrote:

> > Yes. In fact, the application could use a transient POA. The
> > persistence is in the object reference pointing to the ImR.
> 
> OK, but doesn't that break the CORBA object model just a little?  A
> transient object may die and some client sent an OBJECT_NOT_EXIST.  Later,
> using the ImR based reference again it might see the object alive again?

That can happen with a persistent POA too. It's up to the application
to make sure OBJECT_NOT_EXIST doesn't get thrown when it isn't true.
Whether the POA has the persistent policy or not makes no difference.

> You obviously know more about the encoding of IORs than I do.  From your
> description I assume that the ImR will need to persist only POA identities
> and not individual objects.

The ImR doesn't even need to know POA identities. It just needs to map
identifiers of its own choosing to server processes to run. Thinking
about it some more, the ImR doesn't even need to be able to look
inside object references to get their keys out, as long as the server
process gives it some helpful hints, although there are some
advantages to allowing the ImR to get at object keys.

The version that does make use of object keys is essentially the same
as the steps you propose, except there's no need for the POA id...

> The ImR generated references would encode in the object id the following:
> 1) The identity of the POA which hosts the target persistent object

The identity of the server program that hosts the object.

> 2) The entire object key field of the target persistent object reference

> Upon receiving a request for the reference the ImR would
> 3) Decode the object ID and find the POA identity and original object key.
                                       ^^^^^^^^^^^^
                                       server process

> 4) Look in it's persistent store to find the running process or how to
> start the process.
> 5) Start the process if needed, wait for it to register and indicate that
> the required POA is available (or can be made available by an adapter
> activator... or perhaps it assumes this).

It assumes that the object is now available to be invoked upon, either
because the application explicitly activated the object, or because
there is a servant manager that can do it. If the server didn't start
the POA, it must have an adapter activator that will do it on demand.

Note that in all these options, only the object reference is required.
The POA identity is never needed on its own.

> 6) Constructs a new reference with the original persistent object's key and
> the new/existing process's host/port (or other endpoint) information (btw,
> how does it obtain the new host/port or other endpoint info?)

By dissecting the control IOR the server gave it when it registered on
start up (using omniORB specific features). If it takes the IOR for
the control object and puts a different object key in, it will now be
a valid reference for the object in question.

> 7) redirect the client to the new reference.


The other way to do it doesn't involve the ImR digging into IORs at
all, but it requires one extra round trip to the server process:

The ImR generates references that encode in its object ids:

1) The identity of the server program that hosts the object.
2) An identifier that is meaningful to the server program.

Now, on receiving a request, the ImR does:

3) Decode the object id
4) Find the process details
5) Start the process if needed and wait for it to register.
6) Invoke an operation on the server's management object, giving it
   the identifier from (2). The management object implementation
   concocts a suitable object reference using normal POA features.
   (Maybe activating the object; maybe just using id_to_reference,
   etc.)
7. The ImR redirects the client to the new reference.

This approach has two main advantages. First, it means that the ImR
doesn't have to mess with object keys, making it more portable.
Second, it makes it much easier for the references the ImR produces to
be friendly corbaloc URIs, since the identifiers used at each stage
can be human readable strings. Of course, supporting corbaloc URIs
would mean becoming omniORB specific again, and would require a small
change to the ORB core to allow the omniINSPOA to have a servant
manager.

The disadvantages of the second approach are the extra call to the
server, and the fact that the server has to implement the function in
the management object, rather than using standard POA facilities for
the same thing.

> Hypothetically, if another ORB handled all persistent references indirectly
> through it's own ImR, it may not constrain itself to generating identical
> object keys on every server restart, right?  Is it guaranteed that the
> original key will still work?

True. If an ORB can only do persistent POAs using its own ImR, that
would mean things based on object key would not work. It would still
be able to interact with an omniImR using the second approach above,
though, since transient POAs could be used. I don't imagine it would
be sensible to use omniImR in conjunction with another ImR.

> Your example:
> 
>   servant = new MyImpl();
>   return omniImR::makePersistent(servant->_this());
> 
> How does this provide the ImR a POA identity to associate the reference to
> (assuming there can be more than one per process)?  Does it get it out of
> the object key? Or maybe it doesn't care?

As I think I have shown above, it doesn't care.

>  Are you assuming a POA can not
> migrate from one server program to another (e.g. factoring of a monolithic
> server into several cooperating smaller servers)?

With either scheme, a POA would be able to migrate to a different
process. In the first scheme, it would need to keep the same POA name
so the object key remained valid; in the second case, it could do
anything it liked, as long as it implemented the simple look up
function.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --