Musings on an Erlang GUI System.

[Niclas Eklund]

Hello!

It's possible to re-direct calls if the IOR contain an
ALTERNATE_IIOP_ADDRESS component (supported by Orber). If the 
client-side ORB cannot connect to the master host/port, it tries the
alternate address list. If the server-side ORB is still alive, but the
server object no longer exists, then the call will not be re-directed.
It's also possible to add extra "master"-components, but that's
usually more expensive than ALTERNATE_IIOP_ADDRESS.

Full re-direction requires support for the OMG Fault Tolerance (FT)
specification, which allows the user to replicate objects and to
receive alarms via CosNotification (telecom). The FT specification
includes HeartBeats, which makes it possible to "ping" the server-side
ORB. If no reply is received within the given time-limit the connection is
closed.

Orber users can achieve full, light-weight, re-direction if the
following applies:

 * multi-node Orber installation

 * pseudo-objects

 * ALTERNATE_IIOP_ADDRESS (see corba:add_alternate_iiop_address/3)

 * client-side ORB supports ALTERNATE_IIOP_ADDRESS & IIOP-1.2

In this case, the service will stay alive as long as one of the nodes is
alive. Note, it's not recommended that you use pseudo-objects at all time.

/Niclas



On Tue, 18 Feb 2003, Scott Lystig Fritchie wrote:

> >>>>> "lg" == Luke Gorrie <luke@REDACTED> writes:
> 
> lg> BTW, is there anything like process links and monitor_node in
> lg> CORBA these days?
> 
> Not that I'm aware of.(*)  I'm neck-deep in IONA's C++ ORB
> implementation.  It doesn't have stuff like that, because you (the
> client) are not really supposed to know what's going on behind the
> scenes: CORBA will take care of those mussy details for you.
> 
> The implementation gives us control over per-session-establishment
> timeouts and per-call timeouts, but it's up to you to decide what to
> do when CORBA throws an exception.  Typically it's re-resolve the
> handle and then try again ... for some number of attempts.
> 
> The naming service is only as good as what feeds the naming service.
> In the re-attempt loop I mentioned above, it's a good idea to
> re-resolve the name, just in case the server moved.(**)
> 
> If the server dies & goes completely silent, you're at the mercy of
> TCP to figure out that the server has died.  Unless your per-call
> timeout fires first.
> 
> You could write your own transport help avoid many of these problems,
> but rolling your own protocol is difficult to do, SCTP implementations
> are still scarce, and using something like UNIX domain sockets doesn't
> distribute your apps very far.
> 
> The fault-tolerant CORBA environments I've seen have components whose
> sole job is to call CORBA-style ping methods (and occasionally
> lower-level liveness tests) periodically to try to determine if things
> are still up.  If they're dead, it's environment-specific how the
> error is dealt with, a new service started, and the name service
> updated before all the clients give up retrying.
> 
> -Scott
> 
> (*) I've done a lot of mucking with CORBA, both tweaking client-side
> stubs (communication and marshalling) and server-side.  Fortunately
> or not for me, I'm not as familiar with spiffy-new developments in
> CORBA Land.  If I'm living in the CORBA stone age, I'd appreciate
> a whack by the Cudgel of Enlightenment.  :-)
> 
> (**) It's my understanding that it's possible to use the same IOR
> thingie to talk to a server that's moved to a different place, but
> haven't a clue if that's really true.  All the IORs that I've seen
> have hostnames (and perhaps even port numbers) hidden inside them.