[omniORB] Implementation Repository

[Duncan Grisby]

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

> An ImR would allow some persistent POAs to use transient port numbers.  At
> least that's my experience with Orbix 2000.

Indeed.

>  The IOR points to the ImR host
> and port.  You're saying application code would first ask a persistent POA
> to generate an object reference, and then explicity pass that to the ImR in
> order to get the indirect reference?

Yes. In fact, the application could use a transient POA. The
persistence is in the object reference pointing to the ImR.

>   That sounds OK, I guess.  The ImR
> might end up being portable, but server code would not.  No other ORB's ImR
> would require such explicit generation of indirect references.

The server code would be portable. It would be possible to do exactly
the same steps with any ORB.

I don't like implicit use of an ImR. It can lead to problems where the
application thinks it is using an ImR, but actually isn't, due to
misconfiguration. Making the use explicit means everything is obvious.

> Also in H&V section 14.4.5, it's described that an ImR would need to know
> how to decode the object key of a reference in order to find the POA name.
> If this can't be done, then does the ImR need to keep a persistent store
> mapping indirect references to the direct references?  I see a potential
> scalability problem if so.

I don't think there's a problem in that respect. If an application
wants to have a lot of persistent objects, it can use a persistent
POA, and an AdapterActivator to activate it. Then, the ImR just needs
to issue object references containing the complete object keys for the
application. It doesn't need to know anything about what the keys
mean. That does imply that the ImR has to have ORB specific code to
mess with object keys, but it would work no matter what the keys mean.


>  Is there a real need to use a single ImR with
> multiple ORB product?

I believe so. Anyone using omniORB in conjunction with a Java ORB has
a use for one. I think there are definite advantages to having all the
object activation configuration in a single place, compared to one per
ORB.

> Once an explicit approach is done, wouldn't it be advisable to add code to
> the POA to use the ImR interface to automatically generate the indirect
> reference?

Like I say above, my opinion is that making things like this explicit
is more useful than making it implicit, since there is much less scope
for getting confused about what's going on. I certainly think there's
a need for libraries to make using the ImR as clean and painless as
possible. I don't see it as a real burden for an application to do
something like

  servant = new MyImpl();
  return omniImR::makePersistent(servant->_this());

compared to the version without the extra call.

[...]
> True.  However, do a majority of omniORB users (at least those interested
> in an ImR) want to have Python and omniORBpy installed *and* deployed into
> their production environment?  Sounds good to me, but I wasn't sure the
> consensus would be for a Python implementation.

I think encouraging people to install omniORBpy is a good thing :-)
Not just because I wrote it, but also because I think a lot of
projects could gain a great deal by using Python in places that it's
appropriate.

Cheers,

Duncan.

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