This section includes the following topics:
Note: | For detailed information about creating a configuration file for a distributed Oracle Tuxedo CORBA application, refer to the Scaling, Distributing, and Tuning CORBA Applications guide. |
A distributed Oracle Tuxedo ATMI application consists of one or more local or remote clients that communicate with one or more servers residing on several machines linked through a network, all of which are administered as a single entity in one Oracle Tuxedo configuration file. To set up a distributed configuration, you must create a configuration file that includes the following sections:
If your configuration spans multiple domains and uses data-dependent routing, you must also modify the domain gateway configuration file (DMCONFIG
) to support
routing functionality.
In the RESOURCES
section you define governing parameters for system-wide resources, such as the maximum number of servers allowed in the application. All parameter settings in this section apply to the entire application.
Note: | The parameters described in the tables in this topic are used only for distributed applications. For a description of the basic parameters that are available for any kind of OracleTuxedo application, see UBBCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference. |
In the MACHINES
section you assign logical names to all the physical machines in your configuration (including all the processing elements in multiprocessor machines) and define other parameters for individual machines. The following table describes the parameters available for defining machine names and other machine-specific parameters for each machine that participates in a distributed application.
In the GROUPS
section you identify each server group in your application so that the Oracle Tuxedo system can route requests to the member servers of specific groups.
The GROUPS
section is populated with the number of server groups required for the application. Server groups can all reside on the same site (SHM
mode) or, in a distributed application, they can reside on different sites (MP
mode).
Parameters in the GROUPS
section implement two important aspects of distributed transaction processing:
The following table describes the parameters in the GROUPS
section.
The SERVICES
section contains parameters that determine how application services are handled. Every line of every entry in this section is associated with a service by its identifier name.
You must identify the service provided by each server group in the SERVICES
section. 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.
The following table describes the parameters in the SERVICES
section that are available for defining distributed applications.
If your application includes transaction processing, you may also want to set three other parameters in the SERVICES
section: AUTOTRAN
, ROUTING
, and TRANTIME
. These parameters are described in Configuring Your ATMI Application to Use Transactions.
The following listing shows a sample of the SERVICES section.
*SERVICES
WITHDRAW ROUTING=ACCOUNT_ID
DEPOSIT ROUTING=ACCOUNT_ID
OPEN_ACCT ROUTING=BRANCH_ID
In the ROUTING
section you specify the criteria to be used when data-dependent routing is performed. If a service is listed in multiple entries, each with a different SRVGRP
parameter, the ROUTING
section must be set with the same value in all entries. Otherwise, routing cannot be done consistently for that service. Because a service can be routed on one field only, the value of that field must be the same in all entries for the same service.
You can add a ROUTING
section to the configuration file to show mappings between data ranges and groups. The information in this section enables the system to send a request to a server in a specific group. Each ROUTING
section item contains an identifier that is used in the SERVICES
section.
Lines within the ROUTING
section have the following form.
CRITERION_NAME
required_parameters
where CRITERION_NAME
is the name of the routing entry specified in the SERVICES
section for data-dependent routing. The value of CRITERION_NAME
must be a string with a maximum of 15 characters.
The following table describes the parameters in the ROUTING
section.
The following excerpt from a sample UBBCONFIG
file shows the GROUPS
, SERVICES
, and ROUTING
sections, which support data-dependent routing in an Oracle Tuxedo application.
*GROUPS
BANKB1 GRPNO=1
BANKB2 GRPNO=2
BANKB3 GRPNO=3
#
*SERVICES
WITHDRAW ROUTING=BY_ACCOUNT_ID
DEPOSIT ROUTING=BY_ACCOUNT_ID
INQUIRY ROUTING=BY_ACCOUNT_ID
OPEN_ACCT ROUTING=BY_BRANCH_ID
CLOSE_ACCT ROUTING=BY_BRANCH_ID
#
*ROUTING
BY_ACCOUNT_ID FIELD=ACCOUNT_ID BUFTYPE=”FML”
RANGES=”MIN - 9999:*,
10000-49999:BANKB1,
50000-79999:BANKB2,
80000-109999:BANKB3,
*:*”
BY_BRANCH_ID FIELD=BRANCH_ID BUFTYPE=”FML”
RANGES=”MIN - 0:*,
1-4:BANKB1,
5-7:BANKB2,
8-10:BANKB3,
*:*”
All domain gateway configuration information is stored in a binary file called BDMCONFIG
. This file is created by first writing a text configuration file called DMCONFIG
and then compiling it into a binary version called BDMCONFIG
. The compiled BDMCONFIG
file can be updated while the system is running by using the dmadmin(1)
command. Although the Oracle Tuxedo documentation refers to these configuration files as DMCONFIG
and BDMCONFIG
, you can give these files any names.
You must have one BDMCONFIG
file for each Oracle Tuxedo application to which you want to add 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 the DMCONFIG file, refer to DMCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference. |
The DM_ROUTING
section provides information for data-dependent routing of service requests using FML
, XML
, VIEW
, X_C_TYPE
, and X_COMMON
typed buffers. Lines within the DM_ROUTING
section have the following form.
CRITERION_NAME
required_parameters
where CRITERION_NAME
is the name of the routing entry specified in the SERVICES
section. The value of CRITERION_NAME
must be a string with a maximum of 15 characters.
The following table describes the parameters in the DM_ROUTING
section.
The value in the routing field can be any data type supported in FML
or VIEW
; it may be a numeric range or a string range. The following rules apply to string range values for string, carray, and character field types:
atof()
: a plus or minus sign, followed by a string of digits (optionally containing a decimal point), then an optional e
or E
followed by an optional sign or space, followed by an integer.RACCESSPOINT
value specifies the remote domain to which the request should be routed. An RACCESSPOINT
value of *
indicates that the request may be sent to any remote domain known by the gateway group. Within a range/RACCESSPOINT
pair, the range must be separated from the RACCESSPOINT
by a: (colon).The following sample configuration file defines a two-domain application distributed across five sites. The five sites include a Central Bank Office and four bank branches. Three of the branches belong to an Oracle Tuxedo domain. The fourth branch belongs to another TP domain, and OSI-TP is used to communicate with that domain.
The example shows the Oracle Tuxedo system domain gateway configuration file from the Central Bank point of view. In the DM_TDOMAIN
section, this example shows a mirrored gateway for b01
.
# TUXEDO DOMAIN CONFIGURATION FILE FOR THE CENTRAL BANK
#
#
*DM_LOCAL
#local_domain_name
Gateway_Group_name
domain_type
domain_ID
log_device
# [
audit log
] [
blocktime
]
# [log name
] [
log offset
] [
log size
]
maxaccesspoint
# [] [
maxraptran
] [
maxtran
]
# [maxdatalen
] [
security
]
# [tuxconfig
] [
tuxoffset
]
#
#
DEFAULT: SECURITY = NONE
c01 GWGRP = bankg1
TYPE = TDOMAIN
ACCESSPOINTID = "BA.CENTRAL01"
DMTLOGDEV = "/usr/apps/bank/DMTLOG"
DMTLOGNAME = "DMTLG_C01"
c02 GWGRP = bankg2
TYPE = OSITP
ACCESSPOINTID = "BA.CENTRAL01"
DMTLOGDEV = "/usr/apps/bank/DMTLOG"
DMTLOGNAME = "DMTLG_C02"
NWDEVICE = "OSITP"
URCH = "ABCD"
#
*DM_REMOTE
#remote_domain_name domain_type domain_ID
#
b01 TYPE = TDOMAIN
ACCESSPOINTID = "BA.BANK01"
b02 TYPE = TDOMAIN
ACCESSPOINTID = "BA.BANK02"
b03 TYPE = TDOMAIN
ACCESSPOINTID = "BA.BANK03"
b04 TYPE = OSITP
ACCESSPOINTID = "BA.BANK04"
URCH = "ABCD"
#
*DM_TDOMAIN
#
#local_or_remote_domain_name
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_EXPORT
#service_name
[
Local_Domain_name
] [
access_control
] [
exported_svcname
]
# [inbuftype
] [
outbuftype
]
#
open_act ACL = branch
close_act ACL = branch
credit
debit
balance
loan LACCESSPOINT = c02 ACL = loans
*DM_IMPORT
#service_name
[
Remote_domain_name
] [
local_domain_name
]
# [remote_svcname
] [
routing
] [
conv
]
# [trantime
] [
inbuftype
] [
outbuftype
]
#
tlr_add LACCESSPOINT = c01 ROUTING = ACCOUNT
tlr_bal LACCESSPOINT = c01 ROUTING = ACCOUNT
tlr_add RACCESSPOINT = b04 LACCESSPOINT = c02 RNAME ="TPSU002"
tlr_bal RACCESSPOINT = b04 LACCESSPOINT = c02 RNAME ="TPSU003"
*DM_ROUTING
#routing_criteria
field
typed_buffer
ranges
#
acl_name
ACCOUNT FIELD = branchid BUFTYPE ="VIEW:account"
RANGES ="MIN - 1000:b01, 1001-3000:b02, *:b03"
*DM_ACCESS_CONTROL
#
Remote_domain_list
#
branch ACLIST = b01, b02, b03
loans ACLIST = b04