2016/12/13 - Apache Etch has been retired.

For more information, please explore the Attic.

Nameservice Client Details

A typical etch client, which prefers a tcp transport starts itself up with the following set of operations:

String uri = "tcp://localhost:4004";
RemoteBlahClient server = BlahHelper.newServer( uri, null, factory );
server._startAndWaitUp( 4000 );

Here is the flow related to creating and starting a new server on the client end:

Plain Connect

Naming Service enhancement: What changes?

With the naming service under the hood, the only thing that changes would be the uri string itself. Rest of the operations remain the same. Of course, the old uri would work perfectly fine as before ensuring that the addition of Name Service capabilities are backward compatible.

String uri = "etch:etch.examples.perf.Perf/foo"
RemoteBlahClient server = BlahHelper.newServer( uri, null, factory );
server._startAndWaitUp( 4000 );

The following figure explains the flow:

Nameservice Connect

The "target transport stack/factory" in the figure could be any target transport like TCP, TLS, etc. This distinction would be clear from the uri returned by the name service or through the uri specified by the user itself (for further details, please visit the main page).

Dealing with disconnection

There are three scenarios possible during a connection breakdown:

  1. The application explicitly requests an end to the connection between itself and the target service. This will be of the form:

    server._stopAndWaitDown( 4000 );

  2. There is an unexpected disconnect between the application and the target service. In order to maintain the most up to date name translation, every time a disconnect occurs, the old target transport stack would be discarded and a new one be created (using the latest translation) which would be then used to reconnect. The flow associated with this process is shown below:

Nameservice Disconnect