•
|
Replicates the ORA_GRP1 and APP_GRP1 server groups on an additional server machine, Production Machine 2, as ORA_GRP2 and APP_GRP2 and partitions the database.
|
Figure 7‑1 shows the replicated
ORA_GRP and
APP_GRP server groups.
Figure 7‑2 shows the server groups in the Production sample application replicated on a second server machine. The replicated server groups are defined as
ORA_GRP2 and
APP_GRP2 in the
UBBCONFIG file for the Production sample application.
In Figure 7‑2, the only difference between the content of the server groups on Production Machine 1 and Production Machine 2 is the database. The University database is partitioned into two databases. The database on Production Machine 1 contains student and account information for students with IDs between 100001 and 100005. The database on Production Machine 2 contains student and account information for students with IDs between 100006 and 100010.
To achieve scalability gains, the Registrar and
Teller objects are configured in the Production sample application to have the method activation policy. The method activation policy results in the following behavior changes:
In the Basic through the Production sample applications, the Registrar object had an activation policy of
process. All requests from client applications on the
Registrar object went to the same object instance in the memory of the server machine. This design is adequate for a small-scale deployment. However, as client application demands increase, requests from client applications on the
Registrar object eventually become queued, and response time drops.
However, when the Registrar and
Teller objects have an activation policy of
method and the server applications that manage these objects are replicated, the
Registrar and
Teller objects can process multiple requests from client applications in parallel. The only constraint is the number of server application processes that are available to instantiate the
Registrar and
Teller objects.
For the CORBA application to instantiate copies of the Registrar and
Teller objects in each of the replicated server application processes, each copy of the
Registrar and
Teller objects have an unique object ID (OID). The factories that create these objects are responsible for assigning them unique OIDs. For information about generating unique object IDs, see
Creating CORBA Server Applications.
•
|
Requests from client applications to the Registrar object are routed based on the student ID. Requests from student ID 100001 to 100005 go to Production Machine 1. Requests from student ID 100006 to 100010 go to Production Machine 2.
|
•
|
Requests from the Registrar object to the Teller object are routed based on account number. Billing requests for account 200010 to 200014 go to Production Machine 1. Billing requests for account 200015 to 200019 go to Production Machine 2.
|
•
|
The find_registrar() operation of the RegistrarFactory object to require a student ID.
|
•
|
The find_teller() operation of the TellerFactory object to require an account number.
|
During the development process, you need to modify the invocation to the TP::create_object_reference() operation for the
RegistrarFactory and
TellerFactory objects to include an
NVlist that specifies routing criteria. The
criteria parameter of the
TP::create_object_reference()operation specifies a list of named values to be used for factory-based routing, as follows:
•
|
The RegistrarFactory object in the Production sample application specifies the value for criteria to be STU_ID.
|
•
|
The TellerFactory object in the Production sample application specifies the value for criteria to be ACT_NUM.
|
The value of the criteria parameter must match exactly the routing criteria name, field, and field type specified in the
ROUTING section of the
UBBCONFIG file.
The UBBCONFIG file is the key to achieving scalability in a CORBA application. This section describes how the
UBBCONFIG file for the Production sample application is modified to:
1.
|
In the GROUPS section of the UBBCONFIG file, specify the names of the groups you want to configure. In the Production sample application, there are four server groups: APP_GRP1, APP_GRP2, ORA_GRP1, and ORA_GRP2.
|
2.
|
In the SERVERS section of the UBBCONFIG file, enter the following information for the server application process you want to replicate:
|
•
|
The GROUP parameter, which specifies the name of the server group to which the server application process belongs. If you are replicating a server process across multiple groups, specify the server process once for each group.
|
•
|
The SRVID parameter, which specifies a unique administrative ID for the server machine.
|
•
|
The MIN parameter, which specifies the number of instances of the server application process to start when the CORBA application is started. You need to start at least two server application processes.
|
•
|
The MAX parameter, which specifies the maximum number of server application processes that can be running at any one time.You can specify no more than five server application processes.
|
The MIN and
MAX parameters determine the degree to which a given server application can process requests in parallel on a given object. During run time, the system administrator can examine resource bottlenecks and start additional server processes, if necessary. In this sense, the application is scaled by the system administrator.
1.
|
The INTERFACES section lists the names of the interfaces for which you want to enable factory-based routing. For each interface, this section specifies the value on which the interface routes. The routing value is specified in the FACTORYROUTING identifier.
|
2.
|
The ROUTING section specifies the following data for each routing value:
|
•
|
The TYPE parameter, which specifies the type of routing. In the Production sample application, the type of routing is factory-based routing. Therefore, this parameter is defined to FACTORY.
|
•
|
The FIELD parameter, which specifies the name that the factory inserts in the routing value. In the Production sample application, the field parameters are student_id and account_number.
|
•
|
The FIELDTYPE parameter, which specifies the data type of the routing value. In the Production sample application, the field types for STU_ID and ACT_NUM are long.
|
•
|
The RANGES parameter, which specifies the values that are routed to each group.
|
The example shows that Registrar objects for students with IDs 100001 through 100005 are instantiated in
ORA_GRP1, and students with IDs 100006 through 100010 are instantiated in
ORA_GRP2.Likewise,
Teller objects
for accounts 200010 through 200014 are instantiated in
APP_GRP1, and accounts 200015 through 200019 are instantiated in
APP_GRP2.
3.
|
The groups specified by the RANGES identifier in the ROUTING section of the UBBCONFIG file need to be identified and configured. For example, the Production sample application specifies four groups: ORA_GRP1, ORA_GRP2, APP_GRP1, and APP_GRP2. These groups need to be configured, and the machines on which they run need to be identified.
|
drive:\TUXDIR\samples\corba\university\
production
/usr/TUXDIR/samples/corba/university/
production
In addition, you need to copy the utils directory into your work directory. The
utils directory contains files that set up logging, tracing, and access to the University database.
The build process for the UBBCONFIG file prompts you for an application password. This password will be used to log on to the client applications. Enter the password and press Enter. You are then prompted to verify the password by entering it again.
crdl -b blocks -z directorypath
crlog -m SITE1
blocks specifies the number of blocks to be allocated for the transaction log, and
directorypath indicates the location of the transaction log. The
directorypath option needs to match the location specified in the
TLOGDEVICE parameter in the
UBBCONFIG file. The following is an example of the command on Windows:
3.
|
Enter q to quit the Interactive Administrative Interface.
|
During the development process, you would use the buildobjclient and
buildobjserver commands to build the client and server applications. However, for the Production sample application, this step has been done for you. The directory for the Production sample application contains a
makefile that builds the client and server sample applications.
2.
|
At the Enter student id: prompt, enter any number between 100001 and 100010.
|
4.
|
At the Enter domain password: prompt, enter the password you defined when you loaded the UBBCONFIG file.
|
You need to modify the UBBCONFIG file to specify the additional server groups, the server application processes that run in the new server groups, and the server machines on which the server groups run.