The following topics describe how set up and initialize load balancing and failure processing.

To set up load balancing for Info*Engine services as well as provide redundant components in case a component fails, the following processes are available:

Your site can choose to use one or both of these methods for load balancing and failure processing.

To locate Info*Engine components, the Naming Service starts its search at the LDAP search base specified in its LDAP entry. It locates all component entries under the search base that have the specified name. When there is more than one component with the same name in the search base, Info*Engine randomly chooses the one that receives a request.

If you install an Info*Engine component in only one location and that component fails, an error message is generated and returned to the user or calling application. If you install and configure multiple instances of a component and one of the components fails, the Naming Service sends the request to another instance of the same component.

After you have installed an Info*Engine task processor, adapter, or gateway multiple times, you can set up load balancing and failure processing by configuring the components so that they have a common service name. This configuration is done using the Info*Engine Property Administration utility. After you have established a common service name, task and JSP authors must specify this name in the INSTANCE parameter of the adapter webjects or in the task tag attribute that identifies the task processor to use.

You can configure components so that they have a common service name using the following processes:

The following sections provide examples of setting up these methods of load balancing and failure processing.

Creating one LDAP entry with multiple host and port attributes for redundant components is a quick way to provide for loading balancing and failures. This method requires that all component properties are the same for the components and that the components are accessed through a TCP host and port connection.

This method works well in the following situations:

Creating unique LDAP entries for each component and then adding a common service name as an additional service name allows the entries to reside in the same branch in your LDAP directory. This provides flexibility in setting the properties for redundant components. All of the entries can reside in the same branch because each entry has a unique service name which, by default, makes the distinguished name for the service unique. The common service name that is added after the creation of the LDAP entry is the name used when the Naming Service searches for services; it does not become part of the distinguished name for the service.

Using this method can work well when you have multiple instances of the Info*Engine task processor or an adapter that may have different properties but still provides the same function in your environment.

For example, assume that you have three task processors, each residing on a different host, and because the hosts do not have the same capacity, you do not want the Max Thread Count field on each processor LDAP entry form set to the same number. You can then modify the three LDAP entries for the task processors.

Assume that these entries were created when you installed the Info*Engine servers on their respective hosts and that you have set up your environment to run the Naming Service from one of the hosts. To specify the maximum number of requests allowed at one time, and to provide load balancing and failure processing between these task processors, edit the service properties through the Info*Engine Property Administration utility. On each server form, enter the number of requests to allow in the Max Thread Count field. For example, the following table lists the unique service names of three task processors and a maximum thread count for each:

The service names for these entries use the default distinguished names and runtime service names to produce three unique services.

On each form, also add a common task processor service name by typing the common name in the field under the existing service name and clicking Add. For example, you could add the service name “com.myCompany.myLocation.infoengineServer.taskProcessor.” Then when the Naming Service receives requests for a task processor that has this common name, it randomly chooses one of the three task processors with the common name. If the one selected does not respond, another is chosen.

Having multiple LDAP entries with the same service name in unique branches of the LDAP directory provides you with the most flexibility in setting the properties for the components. Using this method assumes that you have set up unique branches in your LDAP server under which the entries can reside (as defined in the distinguished name for each service). The Info*Engine Property Administration utility does not create branches; they must exist before you open Property Administration to add the LDAP entries. Required branches can be created through the Create Repository option in the Task Delegate Administration utility.

This method can work well when you have a complex branching system set up in your LDAP directory and when you have multiple Info*Engine environments. You can restrict access to certain components to certain environments, but allow for load balancing in other environments.

For example, assume that there are three data repositories with unique properties for each repository and that the same JDBC adapter is installed three times, one for each repository. To set up load balancing across all three adapters, you could set the following attributes on the adapter LDAP entries:

Also, assume that each entry has a unique DBUSER attribute that identifies the username for accessing the database. Therefore, in each LDAP entry the service name value is the same (com.myCompany.JDBC) and the host, port, database user, and distinguished name subtree values are unique. In this example, the entries each have unique ptcRuntimeServiceName attributes so that each component has its unique set of properties.

When the Naming Service receives requests for an instance of “com.myCompany.JDBC” and the Naming Service search base is set at the LDAP entry of “dc=myCompany,dc=com,” the Naming Service balances the load across all three JDBC adapters. To do load balancing, Info*Engine randomly selects which of the three adapters receives each query and each adapter connects to a different database.

Task and JSP authors can use the following failure processing techniques within individual tasks or JSPs. These techniques do not require that the components have a common service name.

Using multiple processor attributes on a task tag allows an author to specify multiple task processors that can execute the specified task. If the first processor listed is not available, Info*Engine attempts to connect to the next one in the list. This process continues until a connection is made or until all processors have been tried.

For additional information about the using the task tag, see Info*Engine Tags.

Using multiple INSTANCE parameter values on an adapter webject allows an author to specify multiple adapters that can execute the specified webject. If the first adapter listed is not available, Info*Engine attempts to connect to the next one in the list. This process continues until a connection is made or until all adapters have been tried.

Info*Engine also provides the following parameters, which can be useful in structuring failure processing: