![]() |
![]() |
|
|
How to Create the INTERFACES Section of the Configuration File
Note: This section applies only to the CORBA environments.in BEA Tuxedo.
The INTERFACES section in the configuration file is used to define parameters for CORBA environments in the BEA Tuxedo system. In this section, you define application-wide default parameters for CORBA interfaces used by the application. For a CORBA interface participating in factory-based routing, you define the interface names and specify the name of the routing criteria that the Tuxedo CORBA environment should apply to each interface. Factory-based routing is a feature that lets you distribute processing to specific server groups.
In addition to defining the INTERFACES section, you must specify routing criteria in the ROUTING section and the names of groups in the GROUPS section when you implement factory-based routing. For details about the parameters and more information about factory-based routing, see the section "How to Create the ROUTING Section of the Configuration File" in this chapter.
Specifying CORBA Interfaces in the INTERFACES Section
You indicate specific information about CORBA interfaces used by your application in the INTERFACES section of the configuration file. There are no required parameters. CORBA interfaces need not be listed if no optional parameters are desired. The INTERFACES section includes the following types of information:
Table 3-2 lists the AUTOTRAN, FACTORYROUTING, LOAD, PRIO, SRVGRP, TRANTIME, and TIMEOUT parameters characteristics.
Specifying FACTORYROUTING Criteria
For each CORBA interface, the INTERFACES section specifies what kinds of criteria the interface routes on. The INTERFACES section specifies the routing criteria via an identifier, FACTORYROUTING.
University Sample
The University Production sample application demonstrates how to code factory-based routing (see Listing 3-3). You can find the UBBCONFIG files (ubb_p.nt or ubb_p.mk) for this sample in the directory where the BEA Tuxedo software is installed. Look in the \samples\corba\university\production subdirectory.
Production Sample INTERFACES Section
*INTERFACES
"IDL:beasys.com/UniversityP/Registrar:1.0"
FACTORYROUTING = STU_ID
"IDL:beasys.com/BillingP/Teller:1.0"
FACTORYROUTING = ACT_NUM
The preceding example shows the fully qualified interface names for the two interfaces in the University Production sample. The FACTORYROUTING identifier specifies the names of the routing values, which are STU_ID and ACT_NUM, respectively.
To understand the connection between the INTERFACES FACTORYROUTING parameter and the ROUTING section, see the section CORBA Factory-based Routing in the University Production Sample Application.
Bankapp Sample
Listing 3-4 shows how factory-based routing is specified in the Bankapp sample application.
Bankapp Sample Factory-based Routing
*INTERFACES
"IDL:BankApp/Teller:1.0"
FACTORYROUTING=atmID
*ROUTING
atmID
TYPE = FACTORY
FIELD = "atmID"
FIELDTYPE = LONG
RANGES = "1-5:BANK_GROUP1,
6-10: BANK_GROUP2,
*:BANK_GROUP1
In this example, the IDL:Bankapp/Teller interface uses a factory-based routing scheme called atmID, as defined in the ROUTING section. In the ROUTING section, the sample indicates that the processing will be distributed across two groups. BANK_GROUP1 processes interfaces used by the application when the atmID field is between 1 and 5, or greater than 10. BANK_GROUP2 processes interfaces used by the application when the atmID field is between 6 and 10, inclusive.
Enabling Load Balancing
In BEA Tuxedo CORBA envirionments, load balancing is always enabled.
A LOAD factor is assigned to each CORBA interface invoked, which keeps track of the total load of CORBA interfaces that each server process has performed. Each interface request is routed to the server with the smallest total load. The routing of that request causes the server's total to be increased by the LOAD factor of the CORBA interface requested. When load balancing is not activated, and multiple servers offer the same CORBA interface, the first available queue receives the request.
For more information about load balancing in BEA Tuxedo CORBA environments, refer to "Enabling System-controlled Load Balancing," in the Scaling, Distributing, and Tuning CORBA Applications manual.
Support for parallel objects in CORBA environments has been added for release 8.0 of BEA Tuxedo, which introduces load balancing across mulitple servers in a local domain. For more information about parallel objects in BEA Tuxedo CORBA environments, refer to the "Using Parallel Objects" section in Scaling, Distributing, and Tuning CORBA Applications.
Controlling the Flow of Data by Interface Priority
You can control the flow of data in a BEA Tuxedo client or server application by assigning interface priorities using the PRIO parameter. For instance, Server 1 offers Interfaces A, B, and C. Interfaces A and B have a priority of 50 and Interface C has a priority of 70. An interface requested for C will always be dequeued before a request for A or B. Requests for A and B are dequeued equally with respect to one another. The system dequeues every tenth request in FIFO order to prevent a message from waiting indefinitely on the queue.
The PRIO parameter has the following characteristics:
Specifying Different Interface Parameters for Different Server Groups
You can specify different load, priority, or other interface-specific parameters for different server groups. To do this, you should repeat the interface's entry for each group with different values for the SRVGRP parameter.
![]() |
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|