[omniORB-dev] Implementation Repository

[James Waller]

> Not quite.  Each IOR for a persistent object must be
> generated by the 
> ImR, that much is true.  But the ImR does not store
> per-object 
> information.  That would not scale well.
>
[snip]

Right, but I believe that even having to make a
separate call to the ImR to get an IOR for every
object (regardless of whether the ImR stores anything)
will adversely affect scalability. If a server wants
to publish a ton of object references, that's still a
lot of calls to the ImR which makes it become more of
a bottleneck. However, maybe a way to (at least
partially) alleviate this would be to allow the server
to get IORs en masse by making one call to the ImR
with a whole load of object references.

I haven't looked at your prototype yet, but I will as
soon as I have time. This load-balancing idea sounds
interesting. My ImR does not go into the realm of
load-balancing as I tried to limit the initial scope
of the thing.

> Are you saying you've modified the POA itself?

No. This ImR does not rely on any special
modifications to omniORB itself. What happens is as
follows: the ImR registers the fully-qualified name of
each POA internally and creates an actual CORBA POA to
match (if this isn't done, LocateRequest messages
fail). It then uses an interceptor to catch incoming
requests, get the POA names from their object keys,
match them to a registered POA and redirect the call
to the server under which that POA is registered. Of
course, if the server/POA combination is registered,
the ImR will reply with an OBJECT_NOT_EXIST exception.

The server interface library works by using an
encodeIOR interceptor to detect when an IOR is encoded
for an object that belongs to one of the registered
POAs. In this case the interceptor takes the IOR and
replaces the address information with that of the ImR.
Again this means analysing the object keys which makes
the server library non-portable between ORBs, as does
the use of the interceptor. But this takes place
entirely within the server and does not involve the
ImR at all.

> Are you planning to release your ImR under an open
> license?  I'd be 
> interested in seeing the code.
> 

Yes, absolutely. It's not usable yet, though. I need a
little more time to complete some essential parts and
do some further testing - probably a couple of weeks.
By then it should consist of a feature-complete, alpha
quality ImR daemon, server library and admin client
program. I would like it if we can pool our ideas and
that (at least some of) the work I've done could
become part of an 'official' omniORB Implementation
Repository.

Cheers,
James

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com