[Previous] [Contents] [Next] [IONA Technologies]


Chapter 24
Locators


Contents

24.1 The Default Locator
24.2 Writing a New Locator



When _bind() is called with a null host name, OrbixWeb will use the locator to find the target object in the distributed system. This chapter describes the default locator supplied with OrbixWeb and explains how to replace it with a user-defined locator implementation.

24.1 The Default Locator

The default OrbixWeb locator mechanism searches for a server using the following sequence of steps:

    1. The locator first attempts to contact an OrbixWeb daemon process at the local (client) host. If no such process exists, then the location attempt fails.
    2. The locator invokes the method lookUp(), which contacts the local OrbixWeb daemon and requests a list of host names for the specified server name.
    3. The host names returned by the daemon are arranged in a random order. OrbixWeb then iterates through this list, attempting to verify the registration of the server at each host in turn. The locator returns the first host at which the desired server is registered.
    4. If the server is registered at none of the configured hosts, the locator attempts to locate the server at the local host. If the server is registered at the local host, the location attempt succeeds. Otherwise, the location attempt fails.
Note that if the location attempt fails, then the _bind() call also fails and throws an OrbixWeb system exception. The location attempt succeeds when it locates a host at which the server name passed to _bind() has been registered, but this does not guarantee that the _bind() itself will succeed. The method _bind() demands satisfaction of additional criteria, such as successful launching of the server and location of the specified object within the server.

For successful operation of the default locator, it is necessary to specify server names and corresponding target hosts in advance. The configuration of the default locator must be carried out with respect to the local OrbixWeb daemon process, which manipulates the locator configuration files. This configuration and some additional details of the default locator functionality are described in Chapter 3, "OrbixWeb Configuration" of the OrbixWeb Reference Guide.

The lookUp() method

The lookUp() method is a crucial part of the implementation of the OrbixWeb default location mechanism. It is this method which is responsible for nominating a list of candidate host names at which the server should be sought. The signature of lookUp() (as defined in class IE.Iona.Orbix2.CORBA.locatorClass) is:

The parameters to this method will be described in full later in this chapter.

Unlike the location mechanism in some versions of Orbix, the OrbixWeb default locator does not make use of a publicly accessible default locator object in order to call the method lookUp(). Consequently, an OrbixWeb client cannot call the default locator lookUp() method directly. However, it is possible to implement this functionality and this is discussed in the next subsection.

Note that the object _CORBA.locator (defined in package IE.Iona.Orbix2) is only used to allow programmers to override the default lookUp() implementation and is assigned to null unless explicitly replaced, as described in section 24.2.

Default lookUp() functionality

Although programmers will not normally have to make explicit use of the lookUp() method (since it is used implicitly through calls to _bind()), it may on occasion be useful to do so. A direct call to the lookUp() method invoked by the OrbixWeb default locator is not possible, but this functionality can be easily imitated.

The default lookUp() implementation uses the IT_daemon IDL interface, which is implemented by the OrbixWeb daemon. In order to mimic the behaviour of lookUp(), it is simply necessary to bind to the local OrbixWeb daemon process and invoke the IT_daemon::lookUp() operation. The IDL signature of this operation is:

The operation invocation can be coded as follows:

Each string in the sequence of strings returned by operation lookUp() gives the name of a host on which the specified server may be registered. The lookUp() operation returns an empty sequence if no host names can be found for the specified server. If the call succeeds, then the program can choose any of the returned host names,1 or perhaps iterate over them attempting to bind to the required object at each in turn (receiving an exception on one of the binds indicates an error such as the host not being available).

The hops parameter to lookUp() specifies the maximum number of hops which can be used to fulfil a request, thereby limiting the number of hosts involved in a search. The _bind() method uses the value _CORBA._LOCATOR_HOPS (which can be changed by a programmer who wishes to modify how _bind() uses lookUp()). Explicit calls to lookUp() can specify any byte value, except that the constant value _CORBA._MAX_LOCATOR_HOPS is used if a greater value is specified.

The tag parameter is simply a string used in daemon diagnostic messages and can generally be assigned the value null.

24.2 Writing a New Locator

If the search facility provided by the OrbixWeb default locator is not appropriate, or if it needs to be augmented for a given application, then an alternative locator can be installed by:

Note that the default value of _CORBA.locator is null, which indicates that the default locator algorithm should be used where appropriate.

The locator lookUp() method is passed the name of the server being sought and it should return a list of names of hosts on which that server is registered in the Implementation Repository.

Class locatorClass is defined as follows:

The parameters of lookUp() are as follows:

     ServiceName
    
The name of the server being sought.

     MaxHops
    
In the default locator this is interpreted as the maximum number of machines to search for the required server. An interpretation similar to this one should be retained in a user defined locator if it is to be used without changing client code that explicitly calls lookUp().

     context
    
A context parameter. This allows a client to pass extra information to the locator: for example, constraints on how to search for the server. A trader is an example of where this is important: the context parameter can be used to define properties to be used when deciding between a set of servers with the same name.

It is often advisable that a locator randomises the sequence before returning it.



1 The default implementation of the locator randomises the sequence before returning it. This is a basic technique in load balancing to avoid swamping any one server.



[Roadmap] [Introduction] [GS: Applications] [GS: Applets]
[IDL] [Mapping] [Programming OrbixWeb] [Publishing Objects] [Retrieving Objects] [IIOP]
[Running Clients] [Running Servers] [Exceptions] [Inheritance] [Callbacks] [Contexts]
[API Configuration] [TypeCode] [Any] [DII] [IR] [Filters] [Smart Proxies] [Loaders] [Locators]
[Index]