[omniORB] Porting old (BOA based) Python code to omniORB

[Duncan Grisby]

On Wednesday 23 August, Gary Pennington wrote:

> I've just started using omniORB and I'm trying to port some existing
> Python code from an older ORB, Fnorb.

[...]

> I need a server to be able to provide persistent references to objects
> which represent users. The server must be able to
> create/retrieve/delete/update users based on supplied parameters and
> these users should outlive the existence of the server.

If by "persistent references" you mean that the published CORBA object
references live beyond the life-time of the server process, then you
need to do two things. First, you must create a POA with the
PERSISTENT Lifespan policy (and probably the USER_ID IdAssignment
policy), so the object keys you create are the same each time the
process runs. Second, you have to use the omniORB-specific
-ORBpoa_iiop_port command line argument to force the server to use the
same TCP port number every time.

[...]

> <security stuff...>
> check to see if there is an active reference for the user <HOW DO THIS
> USING POA?>
> if there is return it
>     if not get user from DB
>         if no user return error
>         else
>             activate user and return reference
> 
> 
> Does the above approach make any sense when using a POA? Or should I be
> looking at doing something a little fancier with my own POA and using
> object activations?

That approach makes sense. Using a POA with the USER_ID policy lets
you use object ids which are derived from your system's user names. To
check if an object is active, you just use the POA's id_to_reference()
operation -- if the servant is active, that returns a CORBA object
reference which you can return; if the servant is not active, it
raises the ObjectNotActive exception, and you can activate the object.

There are a number of alternative approaches which may be better for
your application. It may be good to use a POA with a ServantLocator or
ServantActivator. That way, the code to get a user can return an
object reference (created with create_reference_with_id()) regardless
of whether the servant for the object is currently active or not. Then
when a request for an object comes in, the ServantManager gets to
activate the object if it isn't already active.

(The difference between the ServantLocator and the ServantActivator is
that when you activate an object in the ServantActivator, it stays
active after the call; with the ServantLocator, the object is
activated and deactivated on each call.)

I recommend that you read the relevant bits of "Advanced CORBA
Programming with C++" by Henning & Vinoski. Don't be put off by the
C++ -- the design issues are the same whatever language you use.

Hope that helps!

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --