[omniORB] Implementation Repository

[baileyk@schneider.com]

On Wednesday 16 January, duncan@grisby.org wrote:

> The ImR generates references that encode in its object ids:

> 1) The identity of the server program that hosts the object.
> 2) An identifier that is meaningful to the server program.

> Now, on receiving a request, the ImR does:

> 3) Decode the object id
> 4) Find the process details
> 5) Start the process if needed and wait for it to register.
> 6) Invoke an operation on the server's management object, giving it
>    the identifier from (2). The management object implementation
>    concocts a suitable object reference using normal POA features.
>    (Maybe activating the object; maybe just using id_to_reference,
>    etc.)
> 7. The ImR redirects the client to the new reference.

This is sounding more and more like the load balancing service I've played
with implementing for some time.  I used the name service as a go-between
though.  I didn't need the service to start the server processes, so it
just scanned the name service for contexts called "replica" and created an
indirect reference and registered it in the name service above the replica
context as the "primary".  As requests came in to the load balancer the
replica references are chosen (random, round-robin, or active balancing)
and the requests forwarded.  It required the replicas to make available a
management object which could identify host identity, load properties and
coordinate client migration from one replica to another without any aid
from client application code (all using location forwarding).  It's far
from complete but the prototypes worked wonderfully.

One goal was to prevent the load balancer from becoming a single point of
failure.  If it isn't there, or the primary object references fail, the
clients all had code to go searching for the replicas in the name service
and pick one.  Well, that's what all the clients are doing now, since no
load balancer ever got deployed, :)

A portable ImR like you suggest could be aware of the replica groups and
manage the load balancing as well as the process startup and indirect
binding.  This would make it more likely that I could help build it!

When you speak of server program identity, may I suggest a logical/physical
program distinction?  The ImR should be configurable to map logical program
ids to physical processes.  Then I'd expect a common scenario would assign
logical program ids to each POA (or group of closely related POAs) so that
each could later be moved to another pysical program if needed.


Kendall