[omniORB-dev] ImR idl proposal

[kendall bailey]

Thomas Lockhart wrote:

>
> OK, here are some comments :)
>
> 1) The IDL is for a "portable implementation repository". How about 
> naming the module "ImplRepo" or ?? rather than "omniImR" which sounds 
> rather specific to omniORB?


Possibly.  It's too early to worry much about that.  I suppose I'm 
hoping that this become a standard part of the omniORB family.   Still 
free to work with other orbs, but an official omni* sub-project like 
omniNotify.  We'll see.

>
> 2) There are interfaces for several features including load monitoring 
> etc which are not fundamental to the operation of an ImR. We should 
> separate those out into separate IDL files to allow minimalist ORB 
> implementations to ignore those interfaces. And perhaps to allow us to 
> ignore them for our first implementation ;) 


I don't understand the "several".  What else besides the load balancing? 
 My next pass will try to split this out.

>
> 3) Programs, processes, POAs, and objects need to be kept straight. 
> I'm not sure that the distinction between "program" and "process" is 
> necessary, and "object" does not really appear in the IDL but matching 
> clients to server *objects* is my simplistic view of what the ImR 
> does. H&V use "server application" and "object"; "POA" is mentioned 
> too. I'd suggest using H&V (specifically chapter 14) for guidance on 
> terminology.


I've read H&V.  It assumes the POA will interact directly with the ImR. 
 In fact, it makes the assumption that a portable ImR is impossible.  I 
agreed, until Duncan described what he had in mind.  Indirect binding 
won't be as seamless as H&V assumes it should be, but it should work 
just as well. Duncan's approach was so similar to the load balancing 
service I've worked on that the two seemed made for each other.

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.  The ImR will not store the identity of those 
thousands of objects.  Rather it knows only the "program" aka "adapter" 
in H&V lingo.  With a portable ImR there is no need to make all those 
objects share a POA though.

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.

Now that I review H&V, even though 14.4.2 doesn't list load balancing, 
14.4.1 does.  It might therefore be considered "fundamental"...


>
> 4) I like the idea of allowing one "server application" to host 
> multiple "objects", so the extra layers in the IDL to support this is 
> worth the effort.
>
> More comments later... 


I'll see what I can do with the IDL.

Thanks,
Kendall