Table of Contents Previous Next PDF


The Production Sample Application

The Production Sample Application
This topic includes the following sections:
Notes:
The Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB text references, associated code samples, should only be used to help implement/run third party Java ORB libraries, and for programmer reference only.
Technical support for third party CORBA Java ORBs should be provided by their respective vendors. Oracle Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.
How the Production Sample Application Works
The Production sample application provides the same end-user functionality as the Wrapper sample application. The Production sample application demonstrates how to use CORBA features of the Oracle Tuxedo software to scale a CORBA application. The Production sample application does the following:
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.
Note:
The following sections describe how the Production sample application uses replicated server applications, replicated server groups, object state management, and factory-based routing to scale the Production sample application.
Replicating Server Applications
When you replicate server applications:
In the Production sample application, the server applications are replicated in the following manner:
Figure 7‑1 shows the replicated ORA_GRP and APP_GRP server groups.
Figure 7‑1 Replicated Server Groups in the Production Sample Application
In Figure 7‑1, note the following:
There can be no more than one instance of the RegistrarFactory, Registrar, TellerFactory, or Teller objects within a single server application process.
There can be any number of CourseSynopsisEnumerator objects within a server application process.
Replicating Server Groups
Server groups are a feature of the Oracle Tuxedo software that allow you to add server machines to an existing CORBA application. When you replicate a server group, you can do the following:
The way in which server groups are configured and replicated is specified in the UBBCONFIG file.
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.
Figure 7‑2 Replicating Server Groups Across Server Machines
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.
Using a Stateless Object Model
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.
Using Factory-based Routing
Factory-based routing is a CORBA feature that allows you to send a request from a client application to a specific server group. Using factory-based routing, you can spread the processing load for a CORBA application across multiple server machines. The Production sample application uses factory-based routing in the following way:
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.
For information about setting up factory-based routing, see Creating CORBA Server Applications.
The Development Process for the Production Sample Application
This section describes the development process required when scaling a CORBA application. These steps are in addition to the development process outlined in Chapter 3, “The Basic Sample Application.”
Note:
OMG IDL
During the development process, to support factory-based routing, you would make modifications to the Object Management Group (OMG) Interface Definition Language (IDL) definitions for the following operations:
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.
For information about implementing factory-based routing, see Creating CORBA Server Applications.
The Client Application
During the development process, you would specify a STU_ID value when creating a Registrar object. The STU_ID value defines to which server group the request from the client application is routed.
In the Production sample application, the University server application creates the Teller object in the same way a client application would. Therefore, an ACT_NUM value needs to be specified when creating a Teller object.
The Server Application
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.
For information about implementing factory-based routing in a factory, see Creating CORBA Server Applications.
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:
Replicating Server Application Processes and Server Groups
During the development process, modify the UBBCONFIG file in the following way to configure replicated server application processes and server groups:
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.
The following example shows lines from the GROUPS and SERVERS sections of the UBBCONFIG file for the Production sample application.
*GROUPS
APP_GRP1
LMID = SITE1
GRPNO = 2
TMSNAME = TMS
APP_GRP2
LMID = SITE1
GRPNO = 3
TMSNAME = TMS
ORA_GRP1
LMID = SITE1
GRPNO = 4
OPENINFO = "ORACLE_XA:Oracle_XA+Acc=P/scott/tiger+SesTm=100+LogDir
=.+MaxCur=5"
CLOSEINFO = ""
TMSNAME = "TMS_ORA"
ORA_GRP2
LMID = SITE1
GRPNO = 5
OPENINFO = "ORACLE_XA:Oracle_XA+Acc=P/scott/tiger+SesTm=100+LogDir
=.+MaxCur=5"
CLOSEINFO = ""
TMSNAME = "TMS_ORA"
              
*SERVERS
# By default, activate 2 instances of each server
# and allow the administrator to activate up to 5
# instances of each server
DEFAULT:
MIN = 2
MAX = 5
tellp_server
SRVGRP = ORA_GRP1
SRVID = 10
RESTART = N
tellp_server
SRVGRP = ORA_GRP2
SRVID = 10
RESTART = N
billp_server
SRVGRP = APP_GRP1
SRVID = 10
RESTART = N
billp_server
SRVGRP = APP_GRP2
SRVID = 10
RESTART = N
univp_server
SRVGRP = ORA_GRP1
SRVID = 20
RESTART = N
univp_server
SRVGRP = ORA_GRP2
SRVID = 20
RESTART = N
Implementing Factory-based Routing
For each interface for which you want to enable factory-based routing, you need to define the following information in the UBBCONFIG file:
During the development process, make the following changes to the UBBCONFIG file:
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.
The following example shows the FACTORYROUTING identifier for the Registrar and Teller objects in the Production sample application:
INTERFACES
"IDL:beasys.com/UniversityP/Registrar:1.0"
FACTORYROUTING = STU_ID
"IDL:beasys.com/BillingP/Teller:1.0"
FACTORYROUTING = ACT_NUM
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 following example shows the ROUTING section of the UBBCONFIG file used in the Production sample application:
*ROUTING
STU_ID
FIELD = "student_id"
TYPE = FACTORY
FIELDTYPE = LONG
RANGES = "100001-100005:ORA_GRP1,100006-100010:ORA_GRP2"
ACT_NUM
FIELD = "account_number"
TYPE = FACTORY
FIELDTYPE = LONG
RANGES = "200010-200014:APP_GRP1,200015-200019:APP_GRP2"
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.
Note:
The names of the server groups in the GROUPS section must exactly match the group names specified in the ROUTING section.
The ICF File
During the development process, you need to change the activation policy of the Registrar, RegistrarFactory, Teller, and TellerFactory objects from process to method. For information about defining activation and transaction policies for CORBA objects, see Creating CORBA Server Applications.
Building the Production Sample Application
To build the Production sample application, complete the following steps:
1.
2.
3.
4.
5.
Load the UBBCONFIG file.
6.
7.
The following sections describe these steps.
Note:
Copying the Files for the Production Sample Application into a Work Directory
The files for the Production sample application are located in the following directories:
Windows
drive:\TUXDIR\samples\corba\university\production
UNIX
/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.
You will use the files in Table 7‑1 to create the Production sample application.
 
The OMG IDL that declares the Teller and TellerFactory interfaces.
The OMG IDL that declares the CourseSynopsisEnumerator, Registrar, and RegistrarFactory interfaces.
The C++ source code for method implementations of the CourseSynopsisEnumerator, Registrar, and RegistrarFactory interfaces.
The UBBCONFIG file for the UNIX operating system.
The UBBCONFIG file for the Windows operating system.
The makefile for the Production sample application on the UNIX operating system.
The makefile for the Production sample application on the Windows operating system.
log.cpp, log.h, log_client.cpp, and log_server.cpp
oradbconn.cpp and oranoconn.cpp
samplesdb.cpp and samplesdb.h
unique_id.cpp and unique_id.h
samplesdbsql.h and samplesdbsql.pc
Changing the Protection on the Files for the Production Sample Application
During the installation of the Oracle Tuxedo software, the sample application files are marked read-only. Before you can edit the files or build the files in the Production sample application, you need to change the protection of the files you copied into your work directory, as follows:
Windows
prompt>attrib -r drive:\workdirectory\*.*
UNIX
prompt>chmod u+rw /workdirectory/*.*
Setting the Environment Variables
Use the following command to set the environment variables used to build the client and server applications in the Production sample application:
Windows
prompt>setenvp
UNIX
prompt>/bin/ksh
prompt>. ./setenvp.sh
Initializing the University Database
Use the following command to initialize the University database used with the Production sample application:
Windows
prompt>nmake -f makefilep.nt initdb
UNIX
prompt>make -f makefilep.mk initdb
Loading the UBBCONFIG File
Use the following command to load the UBBCONFIG file:
Windows
prompt>tmloadcf -y ubb_p.nt
UNIX
prompt>tmloadcf -y ubb_p.mk
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.
Creating a Transaction Log
The transaction log records the transaction activities in a CORBA application. During the development process you need to define the location of the transaction log (specified by the TLOGDEVICE parameter) in the UBBCONFIG file. For the Production sample application, the transaction log is placed in your work directory.
You need to complete the following steps to open the transaction log for the Production sample application:
1.
tmadmin
2.
crdl -b blocks -z directorypath
crlog -m SITE1
where
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:
crdl -b 500 -z c:\mysamples\university\production\TLOG
3.
Enter q to quit the Interactive Administrative Interface.
Compiling the Production Sample Application
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.
Use the following commands to build the CORBA C++ client and server application in the Production sample application:
Windows
prompt>nmake -f makefilep.nt
UNIX
Running the Production Sample Application
To run the Production sample application, complete the following steps:
1.
2.
The following sections describe these steps in detail.
Starting the Server Application
Start the system and sample application server applications in the Production sample application by entering the following command:
prompt>tmboot -y
This command starts the following server processes:
The Oracle Tuxedo system EventBroker.
The transaction management services, including the NameManager and the FactoryFinder services.
The Interface Repository server process.
Four processes of the University server application.
Four processes of the ATMI application Teller.
Four processes of the Billing server application.
The IIOP Listener/Handler process.
Before using another sample application, enter the following command to stop the system and sample application server processes:
prompt>tmshutdown
Starting the CORBA C++ Client Application
Start the CORBA C++ client application in the Production sample application by completing the following steps:
1.
prompt>univp_client
2.
At the Enter student id: prompt, enter any number between 100001 and 100010.
3.
4.
At the Enter domain password: prompt, enter the password you defined when you loaded the UBBCONFIG file.
5.
Note:
How the Production Sample Application Can Be Scaled Further
The Production sample application can be scaled even more by:
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.
For example, instead of routing to the two existing server groups in the Production sample application, you can modify the routing rules in the UBBCONFIG file to partition the application further among additional server groups. Any modification to the routing tables must match the information in the UBBCONFIG file.
Note:

Copyright © 1994, 2017, Oracle and/or its affiliates. All rights reserved.