This topic includes the following sections:
This topic describes how to distribute applications in the Oracle Tuxedo CORBA environment, using a CORBA application as an example.
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. |
Note: | 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. |
This topic includes the following sections:
Distributing an application enables you to select which parts of an application should be grouped together logically and where these groups should run. You distribute an application by creating more than one entry in the GROUPS
section of the UBBCONFIG
file, and by dividing application resources or tasks among the groups. Creating groups of servers enables you to partition a very large application into its component business applications, and to assure that each of these into logical components is of a manageable size and in an optimal location.
The benefits of a distributed application include:
With the Oracle Tuxedo CORBA system, you can use factory-based routing to distribute the processing of a particular CORBA interface across multiple server groups and, if desired, across multiple machines. This feature allows you to distribute the processing load, which can prevent the processing bottlenecks that occur when concurrent, resource-intensive applications compete for the available CPU, memory, disk I/O, and network resources. For an example of using factory-based routing, see Scaling with Factory-based Routing.
For more information about Oracle Tuxedo CORBA scalability features, see Scaling Oracle Tuxedo CORBA Applications.
This topic includes the following sections:
Note: | This topic applies to Oracle Tuxedo servers only. |
Data-dependent routing is a mechanism whereby a service request is routed by a client (or a server acting as a client) to a server within a specific group based on a data value contained within the buffer that is sent. Within the internal code of a service call, Oracle Tuxedo chooses a destination server by comparing a data field with the routing criteria it finds in the bulletin board shared memory.
For any given service, a routing criteria identifier can be specified in the SERVICES
section of the UBBCONFIG
file. The routing criteria identifier (in particular, the mapping of data ranges to server groups) is specified in the ROUTING
section.
Data-dependent routing has the following characteristics:
SERVICES
section of the UBBCONFIG
file.ROUTING
section of the UBBCONFIG
file.
Table 3-1 illustrates how client requests are routed to servers. In this example, a banking application called bankapp
uses data-dependent routing. For bankapp
, there are three groups (BANKB1
, BANKB2
, and BANKB3
), and two routing criteria (Account_ID
and Branch_ID
). The services WITHDRAW
, DEPOSIT
, and INQUIRY
are routed using the Account_ID
field. The services OPEN
and CLOSE
are routed using the Branch_ID
field.
Listing 3-1 shows a sample UBBCONFIG
file that contains the GROUPS
, SERVICES
, and ROUTING
sections of a configuration file to accomplish data-dependent routing in the Oracle Tuxedo system.
*GROUPS
BANKB1 GRPNO=1
BANKB2 GRPNO=2
BANKB3 GRPNO=3
#
*SERVICES
WITHDRAW ROUTING=ACCOUNT_ID
DEPOSIT ROUTING=ACCOUNT_ID
INQUIRY ROUTING=ACCOUNT_ID
OPEN_ACCT ROUTING=BRANCH_ID
CLOSE_ACCT ROUTING=BRANCH_ID
#
*ROUTING
ACCOUNT_ID FIELD=ACCOUNT_ID BUFTYPE=”FML”
RANGES=”MIN - 9999:*,
10000-49999:BANKB1,
50000-79999:BANKB2,
80000-109999:BANKB3,
*:*”
BRANCH_ID FIELD=BRANCH_ID BUFTYPE=”FML”
RANGES=”MIN - 0:*,
1-4:BANKB1,
5-7:BANKB2,
8-10:BANKB3,
*:*”
This topic includes the following sections:
For more information about the UBBCONFIG
file, see “Creating a Configuration File” in Setting Up an Oracle Tuxedo Application
.
The UBBCONFIG
file contains a description of either data-dependent routing (Oracle Tuxedo) or factory-based routing (Oracle Tuxedo CORBA), as follows:
GROUPS
section is populated with as many server groups as are required for distributing the system. This allows the system to route a request to a server in a specific group. These groups can all reside on the same site (SHM
mode) or, if there is networking, the groups can reside on different sites (MP
mode).SERVICES
section must list the routing criteria for each service that uses the ROUTING
parameter.Note: | If a service has multiple entries, each with a different SRVGRP parameter, all such entries must set ROUTING the same way to ensure consistency for that service. A service can route only on one field, which must be the same for all the same services. |
INTERFACES
section must list the name of the routing criteria for each CORBA interface that uses the FACTORYROUTING
parameter. This parameter is set to the name of a routing criteria defined in the ROUTING
section.ROUTING
section to the configuration file to show mappings between data ranges and groups so that the system can send the request to a server in a specific group. Each ROUTING
section item contains an identifier that is used in the INTERFACES
section (for Oracle Tuxedo ATMI) or in the SERVICES
section (for Oracle Tuxedo).
The parameters in the GROUPS
section implement two important aspects of distributed transaction processing:
Table 3-2 describes the parameters in the GROUPS
section.
The SERVICES
section contains parameters that control the way application services are handled. An entry line in this section is associated with a service by its identifier name. Because the same service can be link edited with more than one server, the SRVGRP
parameter is provided to tie the parameters for an instance of a service to a particular group of servers.
Two parameters in the SERVICES
section are particularly related to distributed transaction processing (DTP) for Oracle Tuxedo CORBA applications that use Oracle Tuxedo ATMI services: AUTOTRAN
, and TRANTIME
.
Table 3-4 describes the parameters in the SERVICES
section.
Listing 3-2 shows a sample SERVICES section.
*SERVICES
# Publish Tuxedo Teller application services
#
DEBIT
AUTOTRAN=Y
CREDIT
AUTOTRAN=Y
CURRBALANCE
AUTOTRAN=Y
The INTERFACES
section contains parameters that control the way application interfaces are handled. An entry line in this section is associated with an interface by its identifier name. Because the same interface can be link edited with more than one server, the SRVGRP
parameter is provided to tie the parameters for an instance of a interface to a particular group of servers.
Three parameters in the INTERFACES
section are particularly related to distributed transaction processing (DTP): FACTORYROUTING
, AUTOTRAN
, and TRANTIME
.
Table 3-4 describes the parameters in the INTERFACES
section.
Listing 3-2 shows a sample INTERFACES section.
*INTERFACES
"IDL:beasys.com/UniversityP/Registrar:1.0"
FACTORYROUTING = STU_ID
AUTOTRAN=Y
TRANTIME=50
"IDL:beasys.com/BillingP/Teller:1.0"
FACTORYROUTING = ACT_NUM
AUTOTRAN=Y
For information about ROUTING
parameters that support Oracle Tuxedo data-dependent routing or Oracle Tuxedo CORBA factory-based routing, see “Creating a Configuration File” in Setting Up an Oracle Tuxedo Application
.
Listing 3-4 shows the ROUTING
section of the UBBCONFIG
file used in the Production sample application for factory-based routing.
*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"
For CORBA applications, to configure factory-based routing across multiple domains, you must configure the factory_finder.ini
file to identify factory objects that are used in the current (local) domain but that are resident in a different (remote) domain. For more information, see “Configuring Multiple Domains Multiple Domains for CORBA Applications in Using the Oracle Tuxedo Domains Component
.
This topic includes the following sections:
This section is specific to Oracle Tuxedo and explains how and why you need to modify the domain gateway configuration to support routing. For more information about the domain gateway configuration file, see “Configuring Multiple Domains Multiple Domains for CORBA Applications in Using the Oracle Tuxedo Domains Component .
The Domain gateway configuration information is stored in a binary file called BDMCONFIG
. The DMCONFIG
file (ASCII) is created and edited with any text editor. The compiled BDMCONFIG
file can be updated while the system is running by using the dmadmin(1)
command.
You must have one BDMCONFIG
file for each Oracle Tuxedo application that requires the Domains functionality. System access to the BDMCONFIG
file is provided through the Domains administrative server, DMADM
(5). When a gateway group is booted, the gateway administrative server, GWADM
(5), requests from the DMADM
server a copy of the configuration required by that group. The GWADM
server and the DMADM
server also ensure that run-time changes to the configuration are reflected in the corresponding Domain gateway groups.
Note: | For more information about modifying the DMCONFIG file, see “Configuring Multiple Domains Multiple Domains for CORBA Applications” in Using the Oracle Tuxedo Domains Component. |
The DM_ROUTING
section provides information for data-dependent routing of service requests using FML
, VIEW
, X_C_TYPE
, and X_COMMON
typed buffers. Lines within the DM_ROUTING
section have the form CRITERION_NAME
, where CRITERION_NAME
is the (identifier) name of the routing entry specified in the SERVICES section. The CRITERION_NAME
entry may contain no more than 15 characters.
Table 3-5 describes the parameters in the DM_ROUTING section.
The routing field can be of any data type supported in FML
or VIEW
. A numeric routing field must have numeric range values, and a string routing field must have string range values.
String range values for string, carray, and character field types must be placed inside a pair of single quotation marks and cannot be preceded by a sign. Short and long integer values are a string of digits, optionally preceded by a plus (+
) or minus (-
) sign. Floating point numbers are of the form accepted by the C compiler or atof()
: an optional sign, followed by a string of digits optionally containing a decimal point, and an optional e
or E
followed by an optional sign or space, and an integer.
When a field value matches a range, the associated RDOM
value specifies the remote domain to which the request should be routed. An RDOM
value of *
indicates that the request can go to any remote domain known by the gateway group. Within a range/RDOM
pair, the range is separated from the RDOM
by a colon (:
).
Listing 3-5 shows a configuration file that defines a five-site domain configuration. It has four bank branch domains communicating with a Central Bank Branch. Three of the bank branches run within other Oracle Tuxedo system domains. The fourth branch runs under the control of another TP domain, and OSI-TP is used in the communication with that domain. The example shows the Oracle Tuxedo Domain gateway configuration file from the Central Bank point of view. In the DM_TDOMAIN
section, this example shows a mirrored gateway for b01
.
# BEA TUXEDO DOMAIN CONFIGURATION FILE FOR THE CENTRAL BANK
#
#
*DM_LOCAL_DOMAINS
# <local domain name> <Gateway Group name> <domain type> <domain id> <log device>
# [<audit log>] [<blocktime>]
# [<log name>] [<log offset>] [<log size>]
# [<maxrdom>] [<maxrdtran>] [<maxtran>]
# [<maxdatalen>] [<security>]
# [<tuxconfig>] [<tuxoffset>]
#
#
DEFAULT: SECURITY = NONE
c01 GWGRP = bankg1
TYPE = TDOMAIN
DOMAINID = "BA.CENTRAL01"
DMTLOGDEV = "/usr/apps/bank/DMTLOG"
DMTLOGNAME = "DMTLG_C01"
c02 GWGRP = bankg2
TYPE = OSITP
DOMAINID = "BA.CENTRAL01"
DMTLOGDEV = "/usr/apps/bank/DMTLOG"
DMTLOGNAME = "DMTLG_C02"
NWDEVICE = "OSITP"
URCH = "ABCD"
#
*DM_REMOTE_DOMAINS
#<remote domain name> <domain type> <domain id>
#
b01 TYPE = TDOMAIN
DOMAINID = "BA.BANK01"
b02 TYPE = TDOMAIN
DOMAINID = "BA.BANK02"
b03 TYPE = TDOMAIN
DOMAINID = "BA.BANK03"
b04 TYPE = OSITP
DOMAINID = "BA.BANK04"
URCH = "ABCD"
#
*DM_TDOMAIN
#
# <local or remote domainname> <network address> [nwdevice]
#
# Local network addresses
c01 NWADDR = "//newyork.acme.com:65432" NWDEVICE ="/dev/tcp"
c02 NWADDR = "//192.76.7.47:65433" NWDEVICE ="/dev/tcp"
# Remote network addresses: second b01 specifies a mirrored gateway
b01 NWADDR = "//192.11.109.5:1025" NWDEVICE = "/dev/tcp"
b01 NWADDR = "//194.12.110.5:1025" NWDEVICE = "/dev/tcp"
b02 NWADDR = "//dallas.acme.com:65432" NWDEVICE = "/dev/tcp"
b03 NWADDR = "//192.11.109.156:4244" NWDEVICE = "/dev/tcp"
#
*DM_OSITP
#
#<local or remote domain name> <apt> <aeq>
# [<aet>] [<acn>] [<apid>] [<aeid>]
# [<profile>]
#
c02 APT = "BA.CENTRAL01"
AEQ = "TUXEDO.R.4.2.1"
AET = "{1.3.15.0.3},{1}"
ACN = "XATMI"
b04 APT = "BA.BANK04"
AEQ = "TUXEDO.R.4.2.1"
AET = "{1.3.15.0.4},{1}"
ACN = "XATMI"
*DM_LOCAL_SERVICES
#<service_name> [<Local Domain name>] [<access control>] [<exported svcname>]
# [<inbuftype>] [<outbuftype>]
#
open_act ACL = branch
close_act ACL = branch
credit
debit
balance
loan LDOM = c02 ACL = loans
*DM_REMOTE_SERVICES
#<service_name> [<Remote domain name>] [<local domain name>]
# [<remote svcname>] [<routing>] [<conv>]
# [<trantime>] [<inbuftype>] [<outbuftype>]
#
tlr_add LDOM = c01 ROUTING = ACCOUNT
tlr_bal LDOM = c01 ROUTING = ACCOUNT
tlr_add RDOM = b04 LDOM = c02 RNAME ="TPSU002"
tlr_bal RDOM = b04 LDOM = c02 RNAME ="TPSU003"
*DM_ROUTING
# <routing criteria> <field> <typed buffer> <ranges>
#
ACCOUNT FIELD = branchid BUFTYPE ="VIEW:account"
RANGES ="MIN - 1000:b01, 1001-3000:b02, *:b03"
*DM_ACCESS_CONTROL
#<acl name> <Remote domain list>
#
branch ACLIST = b01, b02, b03
loans ACLIST = b04