[omniORB] Multiple Servers servicing the same object name?

[Duncan Grisby]

On Monday 21 February, klarson@McLeodUSA.com wrote:

> We are beginning to integrate OmniOrb into our business
> applications.  We are trying to do some planning on how to handle
> error and etc.  One of the things we are looking at is what happens
> if we lose the system which is serving an object.  The thought was
> that we would bring up 2 servers which would both register with the
> name service.  The nameservice would then have 2 available servers
> to which to direct clients.  If one of these went down, then the
> other server would simply service all (new) clients.  This worked
> when we were playing around with Visbroker, but does not seem to
> work with OmniOrb?  It seems that a new server registry overrides
> any server already registered, meaning that a name can only be
> serviced by a single host at one thime?  Is this part of the name
> service specification? Is there a way go get Omninames to do this?

The naming service is simply a service which maps names to objects.
You cannot map the same name to more than one object. This is part of
the standard. You can't really use the naming service to do what you
want.

Fault tolerance in distributed systems is fundamentally hard, and it's
essentially impossible to come up with a completely general-purpose
solution. The OMG are currently working on a fault tolerance
specification, but I don't think anyone supports it yet.

Various ORBs, including Visibroker, have proprietary mechanisms which
provide some degree of fault tolerance, but they can't cope with all
things you might want to do. omniORB has no such mechanism.

I think your best approach is to carefully analyse what you require in
the way of fault tolerance, and then implement something which does
that. I recommend that you use omniORB 3, since the POA makes it much
easier to forward clients from one place to another, and do object
loading on demand.

HTH,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --