[omniORB-dev] ImR idl proposal

[kendall bailey]

pesco@gmx.de wrote:

>On Wed, Jan 22, 2003 at 03:33:06PM -0600, kendall bailey wrote:
>  
>
>>I wasn't too thrilled with the term "program" either.  I couldn't use 
>>"adapter" as H&V does.  However, there should be some logical grouping 
>>of objects so that a bunch can be migrated all at once.  The ImR could 
>>be told that program X is now hosted in process Y rather than Z, and the 
>>thousands of objects that once would have auto-started process Z now 
>>will start process Y.
>>    
>>
>
>Why can't we use adapters to group objects?
>
>  
>

The design of the ImR I'm pursueing is based on some of Duncan's 
suggestions.  Rather than look at object keys and tie objects to POA 
names, the ImR relies on the server application to generate the direct 
reference on demand when passed a couple identifiers.  With this 
approach there is no reason to limit a server app to use an adapter name 
as one of the identifiers, and so I didn't want the terminology used to 
suggest that should be the case.

>I don't think there's a need for a lot of objects to share the same
>POA if we group by POA because the objects themselves could reside in
>children of the POA registered in the ImR...
>
>  
>

Related POAs will still generate different object keys, so if the ImR is 
going to see them all as one logical group, it still needs a single 
identifier.  It can't recognize the related POAs by decoding object keys.

>  
>
>>H&V table 14.1 has "Logical Server Name", "POA Name", and host/port. 
>>I'm replacing these with process, program and an IOR for a 
>>ProcessManager.  You're welcome to suggest better names.
>>    
>>
>
>This reminds me of another question. Which information about an object
>should comprise its identity within the location domain? If
>administered by adapter, the object key within the target ORB, or some
>resemblence thereof (assuming we can't get at the key in a portable way)
>would work?
>
>  
>

The assumption I am working with is that 2 identifiers are enough to 
uniquely find an object.  A "program" name (or subsystem, or adapter, or 
logical_server) and an object name.  The ImR must be told which physical 
process the program lives in at any particular time.  With that it can 
start the process if needed, and ask the process to generate a direct 
reference to the object with the given program and object name.  The 
server process is responsible for activating any POA required.  I expect 
the program name will often be an adapter name like 
"rootPOA/subPOA1/subPOA2", and then the server program may trigger 
adapter activators via find_POA() calls to get the right POA, then 
generate an IOR from the object name with create_reference_with_id(). 
 Of course it could do something more direct than that.  An ImR client 
lib might need a callback hook to let it look up the repository id 
associated with a given object too.  I haven't got that far.

This approach costs an additional round trip between the ImR and the 
server process, but it avoids tinkering with object keys.


Kendall