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.
The UBBCONFIG file contains a description of either data-dependent routing (Oracle Tuxedo) or factory-based routing (Oracle Tuxedo CORBA), as follows:
|
•
|
The 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).
|
|
•
|
For factory-based routing in Oracle Tuxedo CORBA, the 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.
|
|
•
|
Add a 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:
|
•
|
By allowing a second LMID to be associated with the server group, they name an alternate machine to which a group of servers can be migrated if the MIGRATE option is specified.
|
Table 3‑2 describes the parameters in the
GROUPS section.
|
|
|
|
|
LMID must be assigned in the MACHINES section to indicate that this server group runs on this particular machine. A second LMID value can be specified (separated from the first by a comma) to name an alternate machine to which this server group can be migrated if the MIGRATE option has been specified. Servers in the group must specify RESTART=Y to migrate.
|
|
|
Associates a numeric group number with this server group. The number must be greater than zero (0) and less than 30000. It must be unique among entries in the GROUPS section in this configuration file. (Required)
|
|
|
Specifies which transaction management server (TMS) should be associated with this server group.
|
|
|
Specifies how many copies of TMSNAME should be started for this server group. The minimum value is 2. If not specified, the default is 3. All TMSNAME servers started for a server group are automatically set up in an MSSQ set. (Optional)
|
|
|
Specifies information needed to open a particular instance of a particular resource manager, or it indicates that such information is not required for this server group. When a resource manager is named in the OPENINFO parameter, information such as the name of the database and the access mode is included. The entire value string must be enclosed in double quotes and must not be more than 256 characters. The format of the OPENINFO string is dependent on the requirements of the vendor providing the underlying resource manager. The string required by the vendor must be prefixed with rm_name:, which is the published name of the vendor's transaction (XA) interface followed immediately by a colon ( :).
The OPENINFO parameter is ignored if TMSNAME is not set or is set to TMS. If TMSNAME is set but the OPENINFO string is set to the null string ( "") or if this parameter does not appear on the entry, it means that a resource manager exists for the group but does not require any information for executing an open operation.
|
|
|
|
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‑3 describes the parameters in the
SERVICES section.
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.
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.
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.
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.
|
|
|
|
|
Specifies the name of the routing field. It must contain 30 characters or fewer. This field is assumed to be a field name identified in an FML field table (for FML buffers) or an FML VIEW table (for VIEW, X_C_TYPE, or X_COMMON buffers). The FLDTBLDIR and FIELDTBLS environment variables are used to locate FML field tables; the VIEWDIR and VIEWFILES environment variables are used to locate FML VIEW tables. If a field in an FML32 buffer is used for routing, it must have a field number less than or equal to 8191.
|
|
|
No subtype can be specified for type FML, and subtypes are required for the other types ( * is not allowed).
If multiple buffer types are specified for a single routing entry, the data types of the routing field for each buffer type must be the same. (If the field value is not set (for FML buffers), or does not match any specific range, and a wildcard range has not been specified, then an error is returned to the application process that requested the execution of the remote service.) No routing is allowed on CORBA and EJB (TGIOP is not a valid buffer type).
|
|
|
Specifies the ranges and associated remote domain names (RDOM) for the routing field. The string must be enclosed in double quotes, with the format of a comma-separated ordered list of range/RDOM pairs.
A range is either a single value (signed numeric value or character string in single quotes), or a range of the form lower - upper (where lower and upper are both signed numeric values or character strings in single quotes). The value of lower must be less than or equal to upper. A single quote embedded in a character string value (such as “O'Brien”), must be preceded by two backslashes ( “O\\'Brien”).
|
•
|
Use MIN to indicate the minimum value for the data type of the associated FIELD. For strings and carrays, it is the null string; for character fields, it is 0; for numeric values, it is the minimum numeric value that can be stored in the field.
|
|
•
|
Use MAX to indicate the maximum value for the data type of the associated FIELD. For strings and carrays, it is effectively an unlimited string of octal-255 characters; for a character field, it is a single octal-255 character; for numeric values, it is the maximum numeric value that can be stored in the field.
|
Thus, MIN - -5 is all numbers less than or equal to -5, and 6 - MAX is all numbers greater than or equal to 6.
The metacharacter * (wildcard) in the position of a range indicates any values not covered by the other ranges previously seen in the entry. Only one wildcard range is allowed per entry and it should be last (ranges following it are ignored).
|
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
