Re: Implementation Repository

Judging from what I've been reading so far, there is
one major difference between the design I have worked
on and the one being agreed here. That is, my ImR
works on the premise that you don't register each and
every object with the ImR, instead you register the
POAs that contain the objects (as described in the
Henning paper).

My rationale for taking this approach is that if a
server contains tens, hundreds or even more objects,
the system can handle them in a more scalable fashion
as there are fewer calls to the ImR. The disadvantage,
of course, is that your servers (or more specifically,
the library you link with your servers) has to mess
around with object keys and is hence not portable
between ORBs.

Originally I felt that the advantages of that approach
outweighed the disadvantages. With hindsight, the
other approach would have made my ImR *much* simpler
(there's quite a bit of code in there for manipulating
object references, POAs and so on). Maybe the ImR
could make both methods available, the
register-every-object way for portable servers and the
register-every-POA way for more scalable (but
non-portable) servers. Comments anyone?

I have attached the IDL for the Implementation
Repository I have been working on. Basically the
Repository interface contains the general
administrative interface, and the Server interface is
implemented by both the manager objects in the ImR and
the proxy objects in the servers.

Cheers,
James

[original message snipped]

__________________________________________________
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