![]() |
![]() |
e-docs > Tuxedo > Using the Tuxedo Domains Component > Planning and Configuring ATMI Domains |
Using the Tuxedo Domains Component
|
Planning and Configuring ATMI Domains
The following sections explain how to plan and configure a domain for a BEA Tuxedo ATMI Domains environment:
Planning to Build Domains from Multiple BEA Tuxedo Applications
The following figure shows two BEA Tuxedo applications: the bankapp application and a credit card authorization application.
Figure 2-1 Two BEA Tuxedo Applications
The bankapp application connects ATMs at various bank branches to the central bank office. The credit card authorization application processes customer requests for credit cards. Over time, the bank managers realize that their customers would be better served if the bankapp application could communicate directly with the credit card authorization application. With direct communication, the bank could offer instant credit cards to anyone opening a new account. The bankapp application is a sample application included with the BEA Tuxedo distribution, and the credit card authorization application is a hypothetical extension of bankapp. The bankapp application files reside at the following location:
Where tux_prod_dir represents the directory in which the BEA Tuxedo distribution is installed.
The following listing shows the content of a file named ubbmp, which is the UBBCONFIG file for the multiple-machine version of the bankapp application.
Listing 2-1 ubbmp Configuration File for the bankapp Application
.
.
.
*RESOURCES
IPCKEY 80952
UID <user id from id(1)>
GID <group id from id(1)>
PERM 0660
MAXACCESSERS 40
MAXSERVERS 35
MAXSERVICES 75
MAXCONV 10
MAXGTT 20
MASTER SITE1,SITE2
SCANUNIT 10
SANITYSCAN 12
BBLQUERY 30
BLOCKTIME 30
DBBLWAIT 6
OPTIONS LAN,MIGRATE
MODEL MP
LDBAL Y
##SECURITY ACL
##AUTHSVC "..AUTHSVC"
#
*MACHINES
<SITE1's uname> LMID=SITE1
TUXDIR="<TUXDIR1>"
APPDIR="<APPDIR1>"
ENVFILE="<APPDIR1>/ENVFILE"
TLOGDEVICE="<APPDIR1>/TLOG"
TLOGNAME=TLOG
TUXCONFIG="<APPDIR1>/tuxconfig"
TYPE="<machine type1>"
ULOGPFX="<APPDIR1>/ULOG"
<SITE2's uname> LMID=SITE2
TUXDIR="<TUXDIR2>"
APPDIR="<APPDIR2>"
ENVFILE="<APPDIR2>/ENVFILE"
TLOGDEVICE="<APPDIR2>/TLOG"
TLOGNAME=TLOG
TUXCONFIG="<APPDIR2>/tuxconfig"
TYPE="<machine type2>"
ULOGPFX="<APPDIR2>/ULOG"
#
*GROUPS
#
# Group for Authentication Servers
#
##AUTHGRP LMID=SITE1 GRPNO=101
#
# Group for Application Queue (/Q) Servers
#
##QGRP1 LMID=SITE1 GRPNO=102
## TMSNAME=TMS_QM TMSCOUNT=2
## OPENINFO="TUXEDO/QM:<APPDIR1>/qdevice:QSP_BANKAPP"
#
# Group for Application Manager's Servers
#
##MGRGRP1 LMID=SITE1 GRPNO=103
#
# Group for EventBroker Servers
#
##EVBGRP1 LMID=SITE1 GRPNO=104
DEFAULT: TMSNAME=TMS_SQL TMSCOUNT=2
BANKB1 LMID=SITE1 GRPNO=1
OPENINFO="TUXEDO/SQL:<APPDIR1>/bankdl1:bankdb:readwrite"
BANKB2 LMID=SITE2 GRPNO=2
OPENINFO="TUXEDO/SQL:<APPDIR2>/bankdl2:bankdb:readwrite"
*NETWORK
SITE1 NADDR="<network address of SITE1>"
BRIDGE="<device of provider1>"
NLSADDR="<network listener address of SITE1>"
SITE2 NADDR="<network address of SITE2>"
BRIDGE="<device of provider2>"
NLSADDR="<network listener address of SITE2>"
*SERVERS
#
# TUXEDO System /T server providing application specific authentication.
# Ref. AUTHSVR(5).
#
##AUTHSVR SRVGRP=AUTHGRP SRVID=1 RESTART=Y GRACE=0 MAXGEN=2
## CLOPT="-A"
#
# TUXEDO System /T Message Queue Manager. It is a server that enqueues and
# dequeues messages on behalf of programs calling tpenqueue(3) and
# tpdequeue(3) respectively. Ref. TMQUEUE(5).
#
##TMQUEUE SRVGRP=QGRP1 SRVID=1 CONV=N GRACE=0
## CLOPT="-s QSP_BANKAPP:TMQUEUE"
#
# TUXEDO System /T Message Forwarding Server that forwards messages that have
# been stored using tpenqueue(3) for later processing. Ref. TMQFORWARD(5).
#
##TMQFORWARD SRVGRP=QGRP1 SRVID=2 CONV=N REPLYQ=N GRACE=0
## CLOPT="-- -e -n -d -q Q_OPENACCT_LOG"
#
# TUXEDO System /T User Event Broker that manages user events by notifying
# subscribers when those events are posted. Ref. TMUSREVT(5).
#
##TMUSREVT SRVGRP=EVBGRP1 SRVID=1 GRACE=3600
## ENVFILE="<APPDIR1>/TMUSREVT.ENV"
## CLOPT="-e tmusrevt.out -o tmusrevt.out -A --
## -f <APPDIR1>/tmusrevt.dat"
## SEQUENCE=11
#
# TUXEDO Application Server that subscribes to certain events.
#
##ACCTMGR SRVGRP=MGRGRP1 SRVID=1
## CLOPT="-A -o ACCTMGR.LOG -- -w 1000.00"
## SEQUENCE=12
DEFAULT: RESTART=Y MAXGEN=5 REPLYQ=Y CLOPT="-A"
TLR SRVGRP=BANKB1 SRVID=1 RQADDR=tlr1
CLOPT="-A -- -T 100 -e 1000.00"
TLR SRVGRP=BANKB1 SRVID=2 RQADDR=tlr1
CLOPT="-A -- -T 200 -e 1000.00"
TLR SRVGRP=BANKB2 SRVID=3 RQADDR=tlr2
CLOPT="-A -- -T 600 -e 1000.00"
TLR SRVGRP=BANKB2 SRVID=4 RQADDR=tlr2
CLOPT="-A -- -T 700 -e 1000.00"
XFER SRVGRP=BANKB1 SRVID=5
XFER SRVGRP=BANKB2 SRVID=6
ACCT SRVGRP=BANKB1 SRVID=7
ACCT SRVGRP=BANKB2 SRVID=8
BAL SRVGRP=BANKB1 SRVID=9
BAL SRVGRP=BANKB2 SRVID=10
BTADD SRVGRP=BANKB1 SRVID=11
BTADD SRVGRP=BANKB2 SRVID=12
AUDITC SRVGRP=BANKB1 SRVID=13 CONV=Y MIN=1 MAX=10 RQADDR="auditc"
BALC SRVGRP=BANKB1 SRVID=24
BALC SRVGRP=BANKB2 SRVID=25
#
*SERVICES
DEFAULT: LOAD=50 AUTOTRAN=Y TRANTIME=30
WITHDRAWAL PRIO=50 ROUTING=ACCOUNT_ID
DEPOSIT PRIO=50 ROUTING=ACCOUNT_ID
TRANSFER PRIO=50 ROUTING=ACCOUNT_ID
INQUIRY PRIO=50 ROUTING=ACCOUNT_ID
CLOSE_ACCT PRIO=40 ROUTING=ACCOUNT_ID
OPEN_ACCT PRIO=40 ROUTING=BRANCH_ID
BR_ADD PRIO=20 ROUTING=BRANCH_ID
TLR_ADD PRIO=20 ROUTING=BRANCH_ID
ABAL PRIO=30 ROUTING=b_id
TBAL PRIO=30 ROUTING=b_id
ABAL_BID PRIO=30 ROUTING=b_id
TBAL_BID PRIO=30 ROUTING=b_id
ABALC_BID PRIO=30 ROUTING=b_id
TBALC_BID PRIO=30 ROUTING=b_id
#
*ROUTING
ACCOUNT_ID FIELD=ACCOUNT_ID
BUFTYPE="FML"
RANGES="10000-59999:BANKB1,
60000-109999:BANKB2"
BRANCH_ID FIELD=BRANCH_ID
BUFTYPE="FML"
RANGES="1-5:BANKB1,
6-10:BANKB2"
b_id FIELD=b_id
BUFTYPE="VIEW:aud"
RANGES="1-5:BANKB1,
6-10:BANKB2"
The following sections demonstrate two different ways of reconfiguring the bankapp application and the credit card authorization application so that they can communicate directly with one another:
Option 1: Reconfigure the Applications as a Single BEA Tuxedo Domain
One solution is to combine the bankapp application and the credit card authorization application into one BEA Tuxedo application, or domain, as shown in the following figure.
Figure 2-2 Combining Two BEA Tuxedo System Applications
Creating the UBBCONFIG File for the Combined Application To create the UBBCONFIG file for the combined application, take the following information from the UBBCONFIG file for the credit card authorization application and add it to the UBBCONFIG file for the bankapp application:
The following listing shows a possible UBBCONFIG file for the combined application.
Listing 2-2 Sample UBBCONFIG File for the Combined Application
*RESOURCES
IPCKEY 76666
UID 0000
GID 000
PERM 0660
MAXACCESSERS 40
MAXSERVERS 35
MAXSERVICES 75
MAXCONV 10
MAXGTT 100
MASTER SITE1,SITE2
SCANUNIT 10
SANITYSCAN 5
BBLQUERY 50
BLOCKTIME 2
DBBLWAIT 6
OPTIONS LAN,MIGRATE
MODEL MP
LDBAL Y
#
*MACHINES
#
# Machines for the bankapp part
mach1 LMID=SITE1
TUXDIR="/home/rsmith/tuxroot"
APPDIR="/home/rsmith/bankapp"
ENVFILE="/home/rsmith/bankapp/ENVFILE"
TLOGDEVICE="/home/rsmith/bankapp/TLOG"
TLOGNAME=TLOG
TUXCONFIG="/home/rsmith/bankapp/tuxconfig"
TYPE="type1"
ULOGPFX="/home/rsmith/bankapp/ULOG"
mach2 LMID=SITE2
TUXDIR="/home/rsmith/tuxroot"
APPDIR="/home/rsmith/bankapp"
ENVFILE="/home/rsmith/bankapp/ENVFILE"
TLOGDEVICE="/home/rsmith/bankapp/TLOG"
TLOGNAME=TLOG
TUXCONFIG="/home/rsmith/bankapp/tuxconfig"
TYPE="type2"
ULOGPFX="/home/rsmith/bankapp/ULOG"
mach3 LMID=SITE3
TUXDIR="/home/rsmith/tuxroot"
APPDIR="/home/rsmith/bankapp"
ENVFILE="/home/rsmith/bankapp/ENVFILE"
TLOGDEVICE="/home/rsmith/bankapp/TLOG"
TLOGNAME=TLOG
TUXCONFIG="/home/rsmith/bankapp/tuxconfig"
TYPE="type2"
ULOGPFX="/home/rsmith/bankapp/ULOG"
#
# Machine for the credit card authorization part
sfexpz LMID=SITE4
TUXDIR="/home/rsmith/tuxroot"
APPDIR="/home/rsmith/bankapp"
ENVFILE="/home/rsmith/bankapp/ENVFILE"
TLOGDEVICE="/home/rsmith/bankapp/TLOG"
TLOGNAME=TLOG
TUXCONFIG="/home/rsmith/bankapp/tuxconfig"
TYPE="type1"
ULOGPFX="/home/rsmith/bankapp/ULOG"
#
*GROUPS
DEFAULT: TMSNAME=TMS_SQL TMSCOUNT=2
#
# Groups for the bankapp part
BANKB1 LMID=SITE1 GRPNO=1
OPENINFO="TUXEDO/SQL:/home/rsmith/bankapp/bankdl1:bankdb:readwrite"
BANKB2 LMID=SITE2 GRPNO=2
OPENINFO="TUXEDO/SQL:/home/rsmith/bankapp/bankdl2:bankdb:readwrite"
BANKB3 LMID=SITE3 GRPNO=3
OPENINFO="TUXEDO/SQL:/home/rsmith/bankapp/bankdl3:bankdb:readwrite"
#
# Group for the credit card authorization part
CREDIT LMID=SITE4 GRPNO=4
OPENINFO="TUXEDO/SQL:/home/rsmith/bankapp/crdtdl1:bankdb:readwrite"
#
*NETWORK
#
# Network connections for the bankapp part
SITE1 NADDR="<network address of SITE1>"
BRIDGE="<device of provider1>"
NLSADDR="<network listener address of SITE1>"
SITE2 NADDR="<network address of SITE2>"
BRIDGE="<device of provider2>"
NLSADDR="<network listener address of SITE2>"
SITE3 NADDR="<network address of SITE3>"
BRIDGE="<device of provider3>"
NLSADDR="<network listener address of SITE3>"
#
# Network connections for the credit card authorization part
SITE4 NADDR="<network address of SITE4>"
BRIDGE="<device of provider4>"
NLSADDR="<network listener address of SITE4>"
#
*SERVERS
DEFAULT: RESTART=Y MAXGEN=5 REPLYQ=Y CLOPT="-A"
#
# Servers for the bankapp part
TLR SRVGRP=BANKB1 SRVID=1 RQADDR=tlr1
CLOPT="-A -- -T 100 -e 1000.00"
TLR SRVGRP=BANKB1 SRVID=2 RQADDR=tlr1
CLOPT="-A -- -T 200 -e 1000.00"
TLR SRVGRP=BANKB2 SRVID=3 RQADDR=tlr2
CLOPT="-A -- -T 600 -e 1000.00"
TLR SRVGRP=BANKB2 SRVID=4 RQADDR=tlr2
CLOPT="-A -- -T 700 -e 1000.00"
TLR SRVGRP=BANKB3 SRVID=5 RQADDR=tlr3
CLOPT="-A -- -T 800 -e 1000.00"
TLR SRVGRP=BANKB3 SRVID=6 RQADDR=tlr3
CLOPT="-A -- -T 900" -e 1000.00
XFER SRVGRP=BANKB1 SRVID=7
XFER SRVGRP=BANKB2 SRVID=8
XFER SRVGRP=BANKB3 SRVID=9
ACCT SRVGRP=BANKB1 SRVID=10
ACCT SRVGRP=BANKB2 SRVID=11
ACCT SRVGRP=BANKB3 SRVID=12
BAL SRVGRP=BANKB1 SRVID=13
BAL SRVGRP=BANKB2 SRVID=14
BAL SRVGRP=BANKB3 SRVID=15
BTADD SRVGRP=BANKB1 SRVID=16
BTADD SRVGRP=BANKB2 SRVID=17
BTADD SRVGRP=BANKB3 SRVID=18
AUDITC SRVGRP=BANKB1 SRVID=19 CONV=Y MIN=1 MAX=10 RQADDR="auditc"
BALC SRVGRP=BANKB1 SRVID=20
BALC SRVGRP=BANKB2 SRVID=21
BALC SRVGRP=BANKB3 SRVID=22
#
# Servers for the credit card authorization part
TLRA SRVGRP=CREDIT SRVID=26
CLOPT="-A -- -T 300"
ACCTA SRVGRP=CREDIT SRVID=27
CRDT SRVGRP=CREDIT SRVID=35
#
*SERVICES
DEFAULT: LOAD=50 AUTOTRAN=Y TRANTIME=30
#
# Services for the bankapp part
WITHDRAWAL PRIO=50 ROUTING=ACCOUNT_ID
DEPOSIT PRIO=50 ROUTING=ACCOUNT_ID
TRANSFER PRIO=50 ROUTING=ACCOUNT_ID
INQUIRY PRIO=50 ROUTING=ACCOUNT_ID
CLOSE_ACCT PRIO=40 ROUTING=ACCOUNT_ID
OPEN_ACCT PRIO=40 ROUTING=BRANCH_ID
BR_ADD PRIO=20 ROUTING=BRANCH_ID
TLR_ADD PRIO=20 ROUTING=BRANCH_ID
ABAL PRIO=30 ROUTING=b_id
TBAL PRIO=30 ROUTING=b_id
ABAL_BID PRIO=30 ROUTING=b_id
TBAL_BID PRIO=30 ROUTING=b_id
ABALC_BID PRIO=30 ROUTING=b_id
TBALC_BID PRIO=30 ROUTING=b_id
#
# Services for the credit card authorization part
WITHDRAWALA PRIO=50
INQUIRYA PRIO=50
OPENCA PRIO=40
CLOSECA PRIO=40
DEPOSITA PRIO=50
OPEN_ACCT2 PRIO=40
OPENC PRIO=40
#
*ROUTING
ACCOUNT_ID FIELD=ACCOUNT_ID
BUFTYPE="FML"
RANGES="10000-39999:BANKB1,
40000-69999:BANKB2,
70000-109999:BANKB3,
*:*"
BRANCH_ID FIELD=BRANCH_ID
BUFTYPE="FML"
RANGES="1-5:BANKB1,
6-10:BANKB2,
11-15:BANKB3"
b_id FIELD=b_id
BUFTYPE="VIEW:aud"
RANGES="1-5:BANKB1,
6-10:BANKB2,
11-15:BANKB3"
Limitations of Option 1
Option 2: Reconfigure the Applications as a Domains Configuration
Another solution is to reconfigure the bankapp application and the credit card authorization application as a Domains configuration, as shown in the following figure. The two domains interoperate through two TDomain gateway server processes, one running in each domain.
Figure 2-3 Domains Configuration
To create the Domains configuration for the bankapp and credit card authorization applications, you need to create two UBBCONFIG files, one for each of the BEA Tuxedo applications, and two DMCONFIG files, one for each of the BEA Tuxedo applications. Creating the UBBCONFIG File for the bankapp Application in the Domains Environment To create the UBBCONFIG file for the bankapp application in the Domains environment, start with a copy of the UBBCONFIG file shown in Sample UBBCONFIG File for the Combined Application and make the following changes:
The following listing shows a possible UBBCONFIG file for the bankapp application in the Domains environment.
Listing 2-3 Sample UBBCONFIG File for the bankapp Application in the Domains Environment
*RESOURCES
IPCKEY 76666
UID 0000
GID 000
PERM 0660
MAXACCESSERS 40
MAXSERVERS 35
MAXSERVICES 75
MAXCONV 10
MAXGTT 100
MASTER SITE1,SITE2
SCANUNIT 10
SANITYSCAN 5
BBLQUERY 50
BLOCKTIME 2
DBBLWAIT 6
OPTIONS LAN,MIGRATE
MODEL MP
LDBAL Y
MAXBUFTYPE 16
#
*MACHINES
mach1 LMID=SITE1
TUXDIR="/home/rsmith/tuxroot"
APPDIR="/home/rsmith/bankapp"
ENVFILE="/home/rsmith/bankapp/ENVFILE"
TLOGDEVICE="/home/rsmith/bankapp/TLOG"
TLOGNAME=TLOG
TUXCONFIG="/home/rsmith/bankapp/tuxconfig"
TYPE="type1"
ULOGPFX="/home/rsmith/bankapp/ULOG"
mach2 LMID=SITE2
TUXDIR="/home/rsmith/tuxroot"
APPDIR="/home/rsmith/bankapp"
ENVFILE="/home/rsmith/bankapp/ENVFILE"
TLOGDEVICE="/home/rsmith/bankapp/TLOG"
TLOGNAME=TLOG
TUXCONFIG="/home/rsmith/bankapp/tuxconfig"
TYPE="type2"
ULOGPFX="/home/rsmith/bankapp/ULOG"
mach3 LMID=SITE3
TUXDIR="/home/rsmith/tuxroot"
APPDIR="/home/rsmith/bankapp"
ENVFILE="/home/rsmith/bankapp/ENVFILE"
TLOGDEVICE="/home/rsmith/bankapp/TLOG"
TLOGNAME=TLOG
TUXCONFIG="/home/rsmith/bankapp/tuxconfig"
TYPE="type2"
ULOGPFX="/home/rsmith/bankapp/ULOG"
#
*GROUPS
DEFAULT: TMSNAME=TMS_SQL TMSCOUNT=2
#
# Groups for bankapp
BANKB1 LMID=SITE1 GRPNO=1
OPENINFO="TUXEDO/SQL:/home/rsmith/bankapp/bankdl1:bankdb:readwrite"
BANKB2 LMID=SITE2 GRPNO=2
OPENINFO="TUXEDO/SQL:/home/rsmith/bankapp/bankdl2:bankdb:readwrite"
BANKB3 LMID=SITE3 GRPNO=3
OPENINFO="TUXEDO/SQL:/home/rsmith/bankapp/bankdl3:bankdb:readwrite"
#
# Groups for Domains
DMADMGRP LMID=SITE1 GRPNO=4
GWTGROUP LMID=SITE2 GRPNO=5
#
*NETWORK
SITE1 NADDR="<network address of SITE1>"
BRIDGE="<device of provider1>"
NLSADDR="<network listener address of SITE1>"
SITE2 NADDR="<network address of SITE2>"
BRIDGE="<device of provider2>"
NLSADDR="<network listener address of SITE2>"
SITE3 NADDR="<network address of SITE3>"
BRIDGE="<device of provider3>"
NLSADDR="<network listener address of SITE3>"
#
*SERVERS
DEFAULT: RESTART=Y MAXGEN=5 REPLYQ=Y CLOPT="-A"
#
# Servers for Domains
DMADM SRVGRP=DMADMGRP
SRVID=1001
REPLYQ=N
RESTART=Y
GRACE=0
GWADM SRVGRP=GWTGROUP
SRVID=1002
REPLYQ=N
RESTART=Y
GRACE=0
GWTDOMAIN SRVGRP=GWTGROUP
SRVID=1003
RQADDR="GWTGROUP"
REPLYQ=N
RESTART=Y
GRACE=0
#
# Servers for bankapp
TLR SRVGRP=BANKB1 SRVID=1 RQADDR=tlr1
CLOPT="-A -- -T 100 -e 1000.00"
TLR SRVGRP=BANKB1 SRVID=2 RQADDR=tlr1
CLOPT="-A -- -T 200 -e 1000.00"
TLR SRVGRP=BANKB2 SRVID=3 RQADDR=tlr2
CLOPT="-A -- -T 600 -e 1000.00"
TLR SRVGRP=BANKB2 SRVID=4 RQADDR=tlr2
CLOPT="-A -- -T 700 -e 1000.00"
TLR SRVGRP=BANKB3 SRVID=5 RQADDR=tlr3
CLOPT="-A -- -T 800 -e 1000.00"
TLR SRVGRP=BANKB3 SRVID=6 RQADDR=tlr3
CLOPT="-A -- -T 900" -e 1000.00
XFER SRVGRP=BANKB1 SRVID=7
XFER SRVGRP=BANKB2 SRVID=8
XFER SRVGRP=BANKB3 SRVID=9
ACCT SRVGRP=BANKB1 SRVID=10
ACCT SRVGRP=BANKB2 SRVID=11
ACCT SRVGRP=BANKB3 SRVID=12
BAL SRVGRP=BANKB1 SRVID=13
BAL SRVGRP=BANKB2 SRVID=14
BAL SRVGRP=BANKB3 SRVID=15
BTADD SRVGRP=BANKB1 SRVID=16
BTADD SRVGRP=BANKB2 SRVID=17
BTADD SRVGRP=BANKB3 SRVID=18
AUDITC SRVGRP=BANKB1 SRVID=19 CONV=Y MIN=1 MAX=10 RQADDR="auditc"
BALC SRVGRP=BANKB1 SRVID=20
BALC SRVGRP=BANKB2 SRVID=21
BALC SRVGRP=BANKB3 SRVID=22
#
*SERVICES
DEFAULT: LOAD=50 AUTOTRAN=Y TRANTIME=30
WITHDRAWAL PRIO=50 ROUTING=ACCOUNT_ID
DEPOSIT PRIO=50 ROUTING=ACCOUNT_ID
TRANSFER PRIO=50 ROUTING=ACCOUNT_ID
INQUIRY PRIO=50 ROUTING=ACCOUNT_ID
CLOSE_ACCT PRIO=40 ROUTING=ACCOUNT_ID
OPEN_ACCT PRIO=40 ROUTING=BRANCH_ID
BR_ADD PRIO=20 ROUTING=BRANCH_ID
TLR_ADD PRIO=20 ROUTING=BRANCH_ID
ABAL PRIO=30 ROUTING=b_id
TBAL PRIO=30 ROUTING=b_id
ABAL_BID PRIO=30 ROUTING=b_id
TBAL_BID PRIO=30 ROUTING=b_id
ABALC_BID PRIO=30 ROUTING=b_id
TBALC_BID PRIO=30 ROUTING=b_id
#
*ROUTING
ACCOUNT_ID FIELD=ACCOUNT_ID
BUFTYPE="FML"
RANGES="10000-39999:BANKB1,
40000-69999:BANKB2,
70000-109999:BANKB3,
*:*"
BRANCH_ID FIELD=BRANCH_ID
BUFTYPE="FML"
RANGES="1-5:BANKB1,
6-10:BANKB2,
11-15:BANKB3"
b_id FIELD=b_id
BUFTYPE="VIEW:aud"
RANGES="1-5:BANKB1,
6-10:BANKB2,
11-15:BANKB3"
Note: In the previous example, REPLYQ=N is specified for the DMADM, GWADM, and GWTDOMAIN servers. This setting is not required: you can, if you prefer, designate a reply queue for any of these servers by specifying REPLYQ=Y. When REPLYQ is set to N, however, performance may be improved.
Creating a DMCONFIG File for the bankapp Application
You also need to create a DMCONFIG file for the bankapp application, an example of which is shown in the following listing. The binary version of the a DMCONFIG file (BDMCONFIG) must reside on the same machine as the DMADM server.
Listing 2-4 Sample DMCONFIG File for the bankapp Application
*DM_LOCAL
LOCAL1 GWGRP=GWTGROUP
TYPE=TDOMAIN
ACCESSPOINTID="BANK"
BLOCKTIME=10
CONNECTION_POLICY=ON_STARTUP
DMTLOGDEV="/home/rsmith/bankapp/DMTLOG"
AUDITLOG="/home/rsmith/bankapp/AUDITLOG"
#
*DM_REMOTE
REMOT1 TYPE=TDOMAIN
ACCESSPOINTID="CREDIT.CARD"
#
# If the DM_EXPORT section is absent, as in this sample DMCONFIG
# file, all services advertised by the local domain are available
# to the remote domains. Thus, the following bankapp services are
# available to the credit card authorization application:
#
# WITHDRAWAL
# DEPOSIT
# TRANSFER
# INQUIRY
# CLOSE_ACCT
# OPEN_ACCT
# BR_ADD
# TLR_ADD
# ABAL
# TBAL
# ABAL_BID
# TBAL_BID
# ABALC_BID
# TBALC_BID
#
*DM_IMPORT
WITHDRAWALA RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
INQUIRYA RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
OPENCA RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
CLOSECA RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
DEPOSITA RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
OPEN_ACCT2 RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
OPENC RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
#
*DM_TDOMAIN
LOCAL1 NWADDR="albany.acme.com:4051"
REMOT1 NWADDR="newyork.acme.com:65431"
Creating the UBBCONFIG File for the Credit Card Authorization Application in the Domains Environment
To create the UBBCONFIG file for the credit card authorization application in the Domains environment, make the following changes to the UBBCONFIG file for the credit card authorization application:
The following listing shows a possible UBBCONFIG file for the credit card authorization application in the Domains environment.
Listing 2-5 Sample UBBCONFIG File for the Credit Card Authorization Application in the Domains Environment
*RESOURCES
IPCKEY 76666
UID 0000
GID 000
PERM 0660
MAXACCESSERS 40
MAXSERVERS 35
MAXSERVICES 75
MAXCONV 10
MAXGTT 100
MASTER SITE1
SCANUNIT 10
MODEL SHM
LDBAL Y
#
*MACHINES
sfexpz LMID=SITE1
TUXDIR="/home/rsmith/tuxroot"
APPDIR="/home/rsmith/creditapp"
ENVFILE="/home/rsmith/creditapp/ENVFILE"
TLOGDEVICE="/home/rsmith/creditapp/TLOG"
TLOGNAME=TLOG
TUXCONFIG="/home/rsmith/creditapp/tuxconfig"
TYPE="type1"
ULOGPFX="/home/rsmith/creditapp/ULOG"
#
*GROUPS
DEFAULT: TMSNAME=TMS_SQL TMSCOUNT=2
#
# Group for credit card authorization
CREDIT LMID=SITE1 GRPNO=1
OPENINFO="TUXEDO/SQL:/home/rsmith/creditapp/crdtdl1:bankdb:readwrite"
#
# Groups for Domains
DMADMGRP LMID=SITE1 GRPNO=2
GWTGROUP LMID=SITE1 GRPNO=3
#
*SERVERS
DEFAULT: RESTART=Y MAXGEN=5 REPLYQ=Y CLOPT="-A"
#
# Servers for Domains
DMADM SRVGRP=DMADMGRP
SRVID=50
REPLYQ=N
RESTART=Y
GRACE=0
GWADM SRVGRP=GWTGROUP
SRVID=60
REPLYQ=N
RESTART=Y
GRACE=0
GWTDOMAIN SRVGRP=GWTGROUP
SRVID=70
RQADDR="GWTGROUP"
REPLYQ=N
RESTART=Y
GRACE=0
#
# Servers for credit card authorization
TLRA SRVGRP=CREDIT SRVID=1
CLOPT="-A -- -T 600"
ACCTA SRVGRP=CREDIT SRVID=2
CRDT SRVGRP=CREDIT SRVID=3
#
*SERVICES
DEFAULT: LOAD=50 AUTOTRAN=Y TRANTIME=30
# Services for credit card authorization
WITHDRAWALA PRIO=50
INQUIRYA PRIO=50
OPENCA PRIO=40
CLOSECA PRIO=40
DEPOSITA PRIO=50
OPEN_ACCT2 PRIO=40
OPENC PRIO=40
Note: In the previous example, REPLYQ=N is specified for the DMADM, GWADM, and GWTDOMAIN servers. This setting is not required: you can, if you prefer, designate a reply queue for any of these servers by specifying REPLYQ=Y. When REPLYQ is set to N, however, performance may be improved.
Creating a DMCONFIG File for the Credit Card Authorization Application
You also need to create a DMCONFIG file for the credit card authorization application, an example of which is shown in the following listing.
Listing 2-6 Sample DMCONFIG File for the Credit Card Authorization Application
*DM_LOCAL
LOCAL1 GWGRP=GWTGROUP
TYPE=TDOMAIN
ACCESSPOINTID="CREDIT.CARD"
BLOCKTIME=8
DMTLOGDEV="/home/rsmith/creditapp/DMTLOG"
AUDITLOG="/home/rsmith/creditapp/AUDITLOG"
#
*DM_REMOTE
REMOT1 TYPE=TDOMAIN
ACCESSPOINTID="BANK"
#
# If the DM_EXPORT section is absent, as in this sample DMCONFIG
# file, all services advertised by the local domain are available
# to the remote domains. Thus, the following credit card
# authorization services are available to the bankapp application:
#
# WITHDRAWALA
# INQUIRYA
# OPENCA
# CLOSECA
# DEPOSITA
# OPEN_ACCT2
# OPENC
#
*DM_IMPORT
WITHDRAWAL RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
DEPOSIT RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
TRANSFER RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
INQUIRY RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
CLOSE_ACCT RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
OPEN_ACCT RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
BR_ADD RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
TLR_ADD RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
ABAL RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
TBAL RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
ABALC_BID RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
TBALC_BID RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
#
*DM_TDOMAIN
LOCAL1 NWADDR="newyork.acme.com:65431"
REMOT1 NWADDR="albany.acme.com:4051"
Examining the creditapp Domains Configuration
The creditapp application is a sample Domains configuration that spans four machines. In effect, the creditapp application is yet another solution to reconfiguring the bankapp application and the credit card authorization application—as described in Planning to Build Domains from Multiple BEA Tuxedo Applications—so that the two applications can communicate directly with one another. In this solution, the bankapp and credit card authorization applications are reconfigured as four BEA Tuxedo domains, one domain per machine, that interoperate using TDomain gateway server processes.
The creditapp application is included with the BEA Tuxedo distribution. Its files reside at the following location:
Where tux_prod_dir represents the directory in which the BEA Tuxedo distribution is installed.
The Domains configuration for the creditapp application requires four UBBCONFIG files, one for each of the BEA Tuxedo domains, and four DMCONFIG files, one for each of the BEA Tuxedo domains. The four UBBCONFIG files are named ubbdom1 through ubbdom4, and the four DMCONFIG files are named domcon1 through domcon4. The files reside in the creditapp directory.
The following listing shows the content of the ubbdom1 configuration file. Notice in the SERVERS section that this domain is configured for three TDomain gateway groups, to be used by this domain to communicate with the three other domains in the Domains configuration.
Listing 2-7 ubbdom1 Configuration File for the creditapp Application
.
.
.
*RESOURCES
IPCKEY 80952
UID <user id from id(1)>
GID <group id from id(1)>
PERM 0660
MAXACCESSERS 40
MAXSERVERS 35
MAXSERVICES 75
MAXCONV 10
MASTER SITE1
MODEL SHM
LDBAL Y
MAXGTT 100
MAXBUFTYPE 16
SCANUNIT 10
SANITYSCAN 5
DBBLWAIT 6
BBLQUERY 50
BLOCKTIME 2
#
#
*MACHINES
<SITE1's uname> LMID=SITE1
TUXDIR="<TUXDIR1>"
APPDIR="<APPDIR1>"
ENVFILE="<APPDIR1>/ENVFILE"
TLOGDEVICE="<APPDIR1>/TLOG"
TLOGNAME=TLOG
TUXCONFIG="<APPDIR1>/tuxconfig"
ULOGPFX="<APPDIR1>/ULOG"
TYPE="<machine type1>"
#
#
*GROUPS
DEFAULT: LMID=SITE1
BANKB1 GRPNO=1 TMSNAME=TMS_SQLTMSCOUNT=2
OPENINFO="TUXEDO/SQL:<APPDIR1>/crdtdl1:bankdb:readwrite"
BANKB2 GRPNO=2
BANKB3 GRPNO=3
BANKB4 GRPNO=4
#
#
*SERVERS
#
DEFAULT: RESTART=Y MAXGEN=5 REPLYQ=Y CLOPT="-A"
DMADM SRVGRP=BANKB2 SRVID=32
GWADM SRVGRP=BANKB2 SRVID=30
GWTDOMAIN SRVGRP=BANKB2 SRVID=31
GWADM SRVGRP=BANKB3 SRVID=24
GWTDOMAIN SRVGRP=BANKB3 SRVID=25
GWADM SRVGRP=BANKB4 SRVID=20
GWTDOMAIN SRVGRP=BANKB4 SRVID=21
TLRA SRVGRP=BANKB1 SRVID=2
CLOPT="-A -- -T 100"
BTADD SRVGRP=BANKB1 SRVID=3
ACCTA SRVGRP=BANKB1 SRVID=4
CRDT SRVGRP=BANKB1 SRVID=5
CRDTA SRVGRP=BANKB1 SRVID=6
#
*SERVICES
DEFAULT: LOAD=50
INQUIRYA PRIO=50
WITHDRAWALA PRIO=50
OPEN_ACCT2 PRIO=40
OPENC PRIO=40
OPENCA PRIO=40
CLOSECA PRIO=40
BR_ADD PRIO=20
TLR_ADD PRIO=20
The following listing shows the content of the domcon1 Domains configuration file. Notice in the DM_LOCAL section (also known as the DM_LOCAL_DOMAINS section) that this domain is configured for three TDomain gateway groups, to be used by this domain to communicate with the three other domains in the Domains configuration. The domcon1 content shown here has been updated with the improved Domains terminology described in Terminology Improvements for DMCONFIG File.
Listing 2-8 domcon1 Domains Configuration File for the creditapp Application
.
.
.
*DM_RESOURCES
#
VERSION=U22
#
#
#
*DM_LOCAL
#
QDOM1 GWGRP=BANKB2
TYPE=TDOMAIN
ACCESSPOINTID="QDOM1"
BLOCKTIME=10
MAXACCESSPOINT=89
DMTLOGDEV="<APPDIR1>/DMTLOG"
AUDITLOG="<APPDIR1>/AUDITLOG"
DMTLOGNAME="DMTLOG_TDOM1"
QDOM2 GWGRP=BANKB3
TYPE=TDOMAIN
ACCESSPOINTID="QDOM2"
BLOCKTIME=10
MAXACCESSPOINT=89
DMTLOGDEV="<APPDIR1>/DMTLOG"
AUDITLOG="<APPDIR1>/AUDITLOG"
DMTLOGNAME="DMTLOG_TDOM2"
QDOM3 GWGRP=BANKB4
TYPE=TDOMAIN
ACCESSPOINTID="QDOM3"
BLOCKTIME=10
MAXACCESSPOINT=89
DMTLOGDEV="<APPDIR1>/DMTLOG"
AUDITLOG="<APPDIR1>/AUDITLOG"
DMTLOGNAME="DMTLOG_TDOM3"
#
#
*DM_REMOTE
#
TDOM1 TYPE=TDOMAIN
ACCESSPOINTID="TDOM1"
TDOM2 TYPE=TDOMAIN
ACCESSPOINTID="TDOM2"
TDOM3 TYPE=TDOMAIN
ACCESSPOINTID="TDOM3"
#
#
*DM_TDOMAIN
#
TDOM1 NWADDR="<network address of SITE2>"
NWDEVICE="<device of provider2>
TDOM2 NWADDR="<network address of SITE3>"
NWDEVICE="<device of provider3>
TDOM3 NWADDR="<network address of SITE4>"
NWDEVICE="<device of provider4>
QDOM1 NWADDR="<network address of SITE1>"
NWDEVICE="<device of provider1>
QDOM2 NWADDR="<network address of SITE1A>"
NWDEVICE="<device of provider1>
QDOM3 NWADDR="<network address of SITE1B>"
NWDEVICE="<device of provider1>
#
#
*DM_EXPORT
#
WITHDRAWALA
INQUIRYA
OPENCA
CLOSECA
If you decide to run the creditapp application, start by reading the README file in the creditapp directory. The README file explains how to use a UNIX shell script named RUNME.sh to run the creditapp application. If you want to run the creditapp application on a Windows system, read the README file to learn the basic setup information and then execute the comparable tasks in the Windows environment. For details on using BEA Tuxedo on Windows, see, Using BEA Tuxedo ATMI on Windows.
Setting Up a Domains Configuration
To configure a Domains environment, you as the Domains administrator must specify all the information that a BEA Tuxedo domain needs to know about the other domains—the remote domains—involved in the Domains configuration. This information includes local services exported to the remote domains, services imported from the remote domains, and addressing and security parameters for contacting the remote domains. This information is defined in the UBBCONFIG and DMCONFIG configuration files for each domain involved in the Domains configuration.
The Domains example described in the following sections is based on the simpapp application, which is a sample application included with the BEA Tuxedo distribution at the following location:
Where tux_prod_dir represents the directory in which the BEA Tuxedo distribution is installed.
Configuring a Sample Domains Application (simpapp)
The Domains example, illustrated in the following figure, consists of two BEA Tuxedo domains: lapp, a local application based on simpapp, and rapp, a remote application based on simpapp. The lapp application is configured to allow its clients to access a service called TOUPPER that is available in the rapp application.
Figure 2-4 Local and Remote Applications in simpapp
Configuration Tasks The following tasks are required to configure the lapp and rapp applications.
How to Set Environment Variables for lapp You need to set the following environment variables for the lapp application to be configured successfully:
Windows Example
prompt> set TUXDIR=C:\bea\tuxedo
prompt> set APPDIR=C:\home\lapp
prompt> set TUXCONFIG=C:\home\lapp\lapp.tux
prompt> set BDMCONFIG=C:\home\lapp\lapp.bdm
prompt> set PATH=%APPDIR%;%TUXDIR%\bin;%PATH%
Note: Windows accesses the required dynamically loadable library files through its PATH variable setting.
UNIX Example
prompt> TUXDIR=/home/rsmith/bea/tuxedo
prompt> APPDIR=/home/rsmith/lapp
prompt> TUXCONFIG=/home/rsmith/lapp/lapp.tux
prompt> BDMCONFIG=/home/rsmith/lapp/lapp.bdm
prompt> PATH=$APPDIR:$TUXDIR/bin:/bin:$PATH
prompt> LD_LIBRARY_PATH=$APPDIR:$TUXDIR/lib:/lib:/usr/lib:
$LD_LIBRARY_PATH
prompt> export TUXDIR APPDIR TUXCONFIG BDMCONFIG PATH LD_LIBRARY_PATH
How to Define the Domains Environment for lapp in the UBBCONFIG File
In lapp.ubb, the text version of the lapp application configuration file, only the required parameters are defined. Default settings are used for the other parameters. The following listing shows the content of lapp.ubb.
Listing 2-9 lapp.ubb Configuration File
# lapp.ubb
#
*RESOURCES
IPCKEY 111111
MASTER LAPP
MODEL SHM
*MACHINES
giselle
LMID=LAPP
TUXDIR="/home/rsmith/tuxedo"
APPDIR="/home/rsmith/lapp"
TUXCONFIG="/home/rsmith/lapp/lapp.tux"
*GROUPS
LDMGRP GRPNO=1 LMID=LAPP
LGWGRP GRPNO=2 LMID=LAPP
.
.
.
*SERVERS
DMADM SRVGRP=LDMGRP SRVID=1
GWADM SRVGRP=LGWGRP SRVID=1
GWTDOMAIN SRVGRP=LGWGRP SRVID=2 REPLYQ=N
.
.
.
*SERVICES
.
.
.
Note: In the previous UBBCONFIG file listing, REPLYQ=N is specified for the DMADM, GWADM, and GWTDOMAIN servers. This setting is not required: you can, if you prefer, designate a reply queue for any of these servers by specifying REPLYQ=Y. When REPLYQ is set to N, however, performance may be improved.
Server Group Definitions
The following server groups are defined in lapp.ubb:
Server Definitions
How to Define Domains Parameters for lapp in the DMCONFIG File
In lapp.dom, the text version of the lapp Domains configuration file, only the required parameters are defined. Default settings are used for optional parameters. The following listing shows the content of the lapp.dom file.
Listing 2-10 lapp.dom Domains Configuration File
#
# lapp.dom
#
*DM_LOCAL
LAPP GWGRP=LGWGRP
TYPE=TDOMAIN
ACCESSPOINTID="111111"
*DM_REMOTE
RAPP TYPE=TDOMAIN
ACCESSPOINTID="222222"
*DM_EXPORT
*DM_IMPORT
TOUPPER
*DM_TDOMAIN
LAPP NWADDR="//giselle:5000"
RAPP NWADDR="//juliet:5000"
DM_LOCAL Section Definitions
The DM_LOCAL section identifies the local domain access points, their associated domain gateway groups, and their characteristics. There is one and only one local domain access point per domain gateway group.
The lapp.dom file specifies only one local domain access point, LAPP, and defines the following properties for the LAPP access point:
DM_REMOTE Section Definitions
The DM_REMOTE section identifies the remote domain access points and their characteristics. There may be one or more remote domain access points per domain gateway group.
The lapp.dom file specifies only one remote domain access point, RAPP, and defines the following properties for the RAPP access point:
DM_EXPORT Section Definitions
The DM_EXPORT section provides information about the services that are exported to one or more remote domains through a local domain access point. If this section is absent, or is present but empty, all services advertised by the local domain are available to the remote domains associated with the access points defined in the DM_REMOTE section.
As specified in the lapp.dom file, no lapp services are available to the rapp application through the LAPP access point.
DM_IMPORT Section Definitions
The DM_IMPORT section provides information about the services that are imported through one or more remote domain access points and made available to the local domain through one or more local domain access points. If this section is absent, or is present but empty, no remote services are available to the local domain.
As specified in the lapp.dom file, the rapp service named TOUPPER is available to the lapp application.
DM_TDOMAIN Section Definitions
The DM_TDOMAIN section defines the addressing information required by the BEA Tuxedo Domains component. Each domain access point specified in the LOCAL and REMOTE sections of the configuration file appears as an entry in the in the DM_TDOMAIN section.
Associated with each local domain access point entry is a NWADDR value, which specifies the network address at which the local domain will accept connections from one or more remote domains.
Associated with each remote domain access point entry is a NWADDR value, which specifies the network address at which the local domain will make a connection to a remote domain.
As specified in the lapp.dom file, the lapp application will listen for incoming connection requests on the network address giselle:5000, where giselle is the name of the machine on which the lapp application is running, and 5000 is the listening port. Also specified in lapp.dom is that when the lapp application attempts to make a connection to the rapp application, it will use the network address juliet:5000, where juliet is the name of the machine on which the rapp application is running, and 5000 is the destination port.
How to Compile Application and Domains Gateway Configuration Files for lapp
The lapp.ubb application configuration file contains the information necessary to boot the lapp application. You compile this file into a binary data file by running tmloadcf(1).
The lapp.dom Domains configuration file contains the information used by the local lapp TDomain gateway to communicate with the remote rapp TDomain gateway. You compile this file into a binary data file by running dmloadcf(1).
To compile both configuration files, use the following sample session as a guide.
Windows:
prompt> cd C:\home\lapp
prompt> set TUXCONFIG=C:\home\lapp\lapp.tux
prompt> tmloadcf -y lapp.ubb
prompt> set BDMCONFIG=C:\home\lapp\lapp.bdm
prompt> dmloadcf -y lapp.dom
UNIX:
prompt> cd /home/rsmith/lapp
prompt> TUXCONFIG=/home/rsmith/lapp/lapp.tux
prompt> export TUXCONFIG
prompt> tmloadcf -y lapp.ubb
prompt> BDMCONFIG=/home/rsmith/lapp/lapp.bdm
prompt> export BDMCONFIG
prompt> dmloadcf -y lapp.dom
Once you build both the lapp and rapp applications, you boot the applications on their respective machines by executing the tmboot(1) command:
prompt> tmboot -y
The order in which the two applications are booted does not matter. Monitor the applications with dmadmin(1), as described in Administering Domains. Once both applications are booted, a client in the lapp application can call the TOUPPER service provided by the rapp application.
How to Set Environment Variables for rapp
You need to set the following environment variables for the rapp application to be configured successfully:
Windows Example
prompt> set TUXDIR=C:\bea\tuxedo
prompt> set APPDIR=C:\home\rapp
prompt> set TUXCONFIG=C:\home\rapp\rapp.tux
prompt> set BDMCONFIG=C:\home\rapp\rapp.bdm
prompt> set PATH=%APPDIR%;%TUXDIR%\bin;%PATH%
Note: Windows accesses the required dynamically loadable library files through its PATH variable setting.
UNIX Example
prompt> TUXDIR=/home/rsmith/bea/tuxedo
prompt> APPDIR=/home/rsmith/rapp
prompt> TUXCONFIG=/home/rsmith/rapp/rapp.tux
prompt> BDMCONFIG=/home/rsmith/rapp/rapp.bdm
prompt> PATH=$APPDIR:$TUXDIR/bin:/bin:$PATH
prompt> LD_LIBRARY_PATH=$APPDIR:$TUXDIR/lib:/lib:/usr/lib:
$LD_LIBRARY_PATH
prompt> export TUXDIR APPDIR TUXCONFIG BDMCONFIG PATH LD_LIBRARY_PATH
How to Define the Domains Environment for rapp in the UBBCONFIG File
In rapp.ubb, the text version of the rapp application configuration file, only the required parameters are defined. Default settings are used for the other parameters. The following listing shows the content of the rapp.ubb file.
Listing 2-11 rapp.ubb Application Configuration File
# rapp.ubb
#
*RESOURCES
IPCKEY 222222
MASTER RAPP
MODEL SHM
*MACHINES
juliet
LMID=RAPP
TUXDIR="/home/rsmith/bea/tuxedo"
APPDIR="/home/rsmith/rapp"
TUXCONFIG="/home/rsmith/rapp/rapp.tux"
*GROUPS
RDMGRP GRPNO=1 LMID=RAPP
RGWGRP GRPNO=2 LMID=RAPP
APPGRP GRPNO=3 LMID=RAPP
.
.
.
*SERVERS
DMADM SRVGRP=RDMGRP SRVID=1
GWADM SRVGRP=RGWGRP SRVID=1
GWTDOMAIN SRVGRP=RGWGRP SRVID=2 REPLYQ=N
simpserv SRVGRP=APPGRP SRVID=1
.
.
.
*SERVICES
TOUPPER
.
.
.
Note: In the previous UBBCONFIG file listing, REPLYQ=N is specified for the DMADM, GWADM, and GWTDOMAIN servers. This setting is not required: you can, if you prefer, designate a reply queue for any of these servers by specifying REPLYQ=Y. When REPLYQ is set to N, however, performance may be improved.
The following server groups are defined in rapp.ubb:
The simpserv server advertises the TOUPPER service, which converts strings from lowercase to uppercase characters.
How to Define Domains Parameters for rapp in the DMCONFIG File
In rapp.dom, the text version of the rapp Domains configuration file, only the required parameters are defined. Default settings are used for the other parameters. The following listing shows the content of the rapp.dom file.
Listing 2-12 rapp.dom Domains Configuration File
# rapp.dom
#
*DM_LOCAL
RAPP GWGRP=RGWGRP
TYPE=TDOMAIN
ACCESSPOINTID="222222"
*DM_REMOTE
LAPP TYPE=TDOMAIN
ACCESSPOINTID="111111"
*DM_EXPORT
TOUPPER
*DM_IMPORT
*DM_TDOMAIN
RAPP NWADDR="//juliet:5000"
LAPP NWADDR="//giselle:5000"
The rapp.dom Domains configuration file is similar to the lapp.dom Domains configuration file, except that the two files list different services to be exported and imported. Specifically, the rapp.dom file defines the following Domains configurations for the rapp application:
How to Compile Application and Domain Gateway Configuration Files for rapp
The rapp.ubb application configuration file contains the information necessary to boot the rapp application. You compile this file into a binary data file by running tmloadcf(1).
The rapp.dom Domains configuration file contains the information used by the local rapp TDomain gateway to communicate with the remote lapp TDomain gateway. You compile this file into a binary data file by running dmloadcf(1).
To compile both configuration files, use the following sample session as a guide.
Windows:
prompt> cd C:\home\rapp
prompt> set TUXCONFIG=C:\home\rapp\rapp.tux
prompt> tmloadcf -y rapp.ubb
prompt> set BDMCONFIG=C:\home\rapp\rapp.bdm
prompt> dmloadcf -y rapp.dom
UNIX:
prompt> cd /home/rsmith/rapp
prompt> TUXCONFIG=/home/rsmith/rapp/rapp.tux
prompt> export TUXCONFIG
prompt> tmloadcf -y rapp.ubb
prompt> BDMCONFIG=/home/rsmith/rapp/rapp.bdm
prompt> export BDMCONFIG
prompt> dmloadcf -y rapp.dom
Once you build both the rapp and lapp applications, you boot the applications on their respective machines by executing the tmboot(1) command:
prompt> tmboot -y
The order in which the two applications are booted does not matter. Monitor the applications with dmadmin(1), as described in Administering Domains. Once both applications are booted, a client in the lapp application can call the TOUPPER service provided by the rapp application.
See Also
How to Compress Data Between Domains
Data sent between domains can be compressed for faster performance. To configure compression, set the CMPLIMIT parameter in the DM_TDOMAIN section of the DMCONFIG file. This parameter, which is only relevant to remote domain access points, specifies the compression threshold to be used when sending data to a remote domain. The minimum value is 0, and the maximum value is 2147483647. The default setting is 2147483647. Application buffers larger than the specified size will be compressed.
For more information about setting the CMPLIMIT parameter, see "Compressing Data Over a Network" in Administering a BEA Tuxedo Application at Run Time.
How to Route Service Requests to Remote Domains
Data-dependent routing information used by domain gateways to send service requests to specific remote domains is provided in the DM_ROUTING section of the DMCONFIG file. The FML, FML32, VIEW, VIEW32, X_C_TYPE, X_COMMON, and XML typed buffers are supported.
To create a routing table for a domain involved in a Domains configuration, you specify the following information in the DM_ROUTING section of the DMCONFIG file:
For an example of a Domains data-dependent routing configuration, see Specifying Domains Data-Dependent Routing. For a detailed description of Domains data-dependent routing, see the DM_ROUTING section on reference page DMCONFIG(5)in BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference.
Setting Up Security in a Domains Configuration
The BEA Tuxedo ATMI environment provides the following basic security capabilities for Domains configurations:
The security capabilities available to Domains configurations and those available to individual BEA Tuxedo applications are relatively independent but compatible. For information about the security capabilities available to BEA Tuxedo applications, see Using Security in ATMI Applications.
Domains Security Mechanisms
The BEA Tuxedo Domains component provides the following security mechanisms:
In addition, the local domain and a remote domain can use any of three levels of password security when attempting to connect to one another. You configure the level of password security on a local domain basis by setting the SECURITY parameter in the DM_LOCAL section of the DMCONFIG file.
How to Configure Principal Names for Domains Authentication
As described in "Establishing a Link Between Domains" on page 2-25 in Using Security in ATMI Applications, a local TDomain gateway needs an identity, or principal name, that both the local domain and a remote domain know about so that the remote domain can authenticate the local domain when the domains are attempting to connect to one another. Similarly, the remote TDomain gateway needs an identity, or principal name, that both the remote domain and the local domain know about so that the local domain can authenticate the remote domain when the domains are attempting to establish a connection to one another. In addition, the local TDomain gateway uses its assigned principal name to acquire a set of security credentials needed when setting up the connection.
The local TDomain gateway needs a second principle name to acquire a set of security credentials required to enforce the local access control list (ACL) policy described in How to Configure ACL Policy for a Remote Domain.
As the administrator, you use the following configuration parameters to specify the principal names for the TDomain gateways running in your Release 7.1 or later BEA Tuxedo applications:
Specifies the security principal name identification string to be used for authentication purposes by an application running BEA Tuxedo 7.1 or later software. This parameter may contain a maximum of 511 characters (excluding the terminating NULL character). The principal name specified for this parameter becomes the identity of one or more system processes—including TDomain gateway (GWTDOMAIN) processes—running in this application.
During application booting, each TDomain gateway process in the application calls the authentication plug-in to acquire security credentials for the security principal name specified in SEC_PRINCIPAL_NAME. A TDomain gateway acquires these credentials for the principal name specified in the SEC_PRINCIPAL_NAME parameter.
Specifies the connection principal name identifier, which is the principal name for verifying the identity of the domain gateway associated with this local domain access point when establishing a connection to a remote domain. This parameter applies only to domain gateways of type TDOMAIN running BEA Tuxedo 7.1 or later software.
The CONNECTION_PRINCIPAL_NAME parameter may contain a maximum of 511 characters (excluding the terminating NULL character). If this parameter is not specified, the connection principal name defaults to the ACCESSPOINTID string for this local domain access point.
For default authentication plug-ins, if a value is assigned to the CONNECTION_PRINCIPAL_NAME parameter for this local domain access point, it must be the same as the value assigned to the ACCESSPOINTID parameter for this local domain access point. If these values do not match, the local TDomain gateway process will not boot, and the system will generate the following userlog(3c) message: ERROR: Unable to acquire credentials.
Specifies the connection principal name identifier, which is the principal name for verifying the identity of this remote domain access point when establishing a connection to the local domain. This parameter applies only to domain gateways of type TDOMAIN running BEA Tuxedo 7.1 or later software.
The CONNECTION_PRINCIPAL_NAME parameter may contain a maximum of 511 characters (excluding the terminating NULL character). If this parameter is not specified, the connection principal name defaults to the ACCESSPOINTID string for this remote domain access point.
For default authentication plug-ins, if a value is assigned to the CONNECTION_PRINCIPAL_NAME parameter for this remote domain access point, it must be the same as the value assigned to the ACCESSPOINTID parameter for this remote domain access point. If these values do not match, any attempt to set up a connection between the local TDomain gateway and the remote TDomain gateway will fail, and the system will generate the following userlog(3c) message: ERROR: Unable to initialize administration key for domain domain_name.
In the following example, the CONNECTION_PRINCIPAL_NAME identities in the DMCONFIG file are used when establishing a connection through the LOCAL1 access point and the REMOT1 access point.
*DM_LOCAL
LOCAL1 GWGRP=bankg1
TYPE=TDOMAIN
ACCESSPOINTID="BA.CENTRAL01"
CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
*DM_REMOTE
REMOT1 TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
CONNECTION_PRINCIPAL_NAME="BA.BANK01"
How to Configure Domains Password Security
Domain gateways can be made to authenticate incoming connections requested by remote domains. Application administrators can define when security should be enforced for incoming connections from remote domains.
As the administrator, you can specify the level of security used by a particular local domain by setting the SECURITY parameter in the DM_LOCAL section of the DMCONFIG file. There are three levels of password security:
If in the TUXCONFIG file the SECURITY parameter is set to NONE or is not set, the Domains configuration can still require the TDomain gateways to enforce security at the DM_PW level. If the DM_PW option is selected, each remote domain must have a password defined in the DM_PASSWORDS section of the BDMCONFIG file. In other words, incoming connections without a password are rejected by the TDomain gateway.
Using the DM_MIB(5) to Set Domains Passwords (DM_PW)
You can use the DM_MIB to set Domains passwords (DM_PW). The T_DM_PASSWORDS class in the DM_MIB represents configuration information for interdomain authentication through local and remote access points of type TDOMAIN. The T_DM_PASSWORDS class contains the following entries for each remote domain.
Note: Passwords are stored securely in encrypted format.
For information about formatting MIB administrative requests and interpreting MIB administrative replies, see reference page DM_MIB(5)in BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference.
Using the dmadmin Command to Set Domains Passwords (DM_PW)
You can also use the dmadmin command to set Domains passwords (DM_PW):
prompt> dmadmin
passwd [-r] local_domain_access_point_name
remote_domain_access_point_name
The dmadmin command prompts you for new passwords for the specified local and remote domain access points. For more information about dmadmin(1), see Administering Domains.
Examples of Coding Password Security Between Domains
The SECURITY parameter in the DM_LOCAL section of the DMCONFIG file specifies the security type of a local domain. If authentication is required, it is done every time a connection is established between the local domain and a remote domain. If the security types of the two domains are incompatible, or if the passwords do not match, the connection fails.
Example 1: Setting Security to NONE
If SECURITY is set to NONE for a local domain, incoming connection attempts are not authenticated. Even with SECURITY set to NONE, a local domain can still connect to a remote domain that has SECURITY set to DM_PW, but before such a connection can be established, you must define the passwords on both sides by using DM_MIB(5) or the dmadmin passwd command.
Listing 2-13 Setting Security to NONE for Both Application and Domains
LOCAL1: SECURITY in UBBCONFIG set to NONE
SECURITY in DMCONFIG set to NONE
REMOT1: SECURITY in UBBCONFIG set to NONE
SECURITY in DMCONFIG set to DM_PW
In this example, LOCAL1 is not enforcing any security but REMOT1 is enforcing DM_PW security. On the initiator (LOCAL1) side, the pertinent attributes in UBBCONFIG and DMCONFIG are set as follows:
UBBCONFIG
*RESOURCES
SECURITY NONE
DMCONFIG
*DM_LOCAL
LOCAL1 GWGRP=bankg1
TYPE=TDOMAIN
ACCESSPOINTID="BA.CENTRAL01"
CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
SECURITY=NONE
*DM_REMOTE
REMOT1 TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
CONNECTION_PRINCIPAL_NAME="BA.BANK01"
On the responder (REMOT1) side, the pertinent attributes in UBBCONFIG and DMCONFIG are set as follows:
UBBCONFIG
*RESOURCES
SECURITY NONE
DMCONFIG
*DM_LOCAL
REMOT1 GWGRP=bankg2
TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
CONNECTION_PRINCIPAL_NAME="BA.BANK01"
SECURITY=DM_PW
*DM_REMOTE
LOCAL1 TYPE=TDOMAIN
ACCESSPOINTID="BA.CENTRAL01"
CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
After the required attributes have been set in the TUXCONFIG and BDMCONFIG files, boot the applications on LOCAL1 and REMOT1.
On LOCAL1:
dmadmin
passwd LOCAL1 REMOT1
Enter Local Domain Password:foo1
Reenter Local Domain Password:foo1
Enter Remote Domain Password:foo2
Reenter Remote Domain Password:foo2
On REMOT1:
dmadmin
passwd REMOT1 LOCAL1
Enter Local Domain Password:foo2
Reenter Local Domain Password:foo2
Enter Remote Domain Password:foo1
Reenter Remote Domain Password:foo1
Once passwords have been created on both domains, a connection can be established and services can be invoked on the remote domain.
Listing 2-14 Setting Application Security to NONE and Domains Security to DM_PW
On the initiator (LOCAL1) side, the pertinent attributes in UBBCONFIG and DMCONFIG are set as follows:
UBBCONFIG
*RESOURCES
SECURITY NONE
DMCONFIG
*DM_LOCAL
LOCAL1 GWGRP=bankg1
TYPE=TDOMAIN
ACCESSPOINTID="BA.CENTRAL01"
CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
SECURITY=DM_PW
*DM_REMOTE
REMOT1 TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
CONNECTION_PRINCIPAL_NAME="BA.BANK01"
On the responder (REMOT1) side, the pertinent attributes in UBBCONFIG and DMCONFIG are set as follows:
UBBCONFIG
*RESOURCES
SECURITY NONE
DMCONFIG
*DM_LOCAL
REMOT1 GWGRP=bankg2
TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
CONNECTION_PRINCIPAL_NAME="BA.BANK01"
SECURITY=DM_PW
*DM_REMOTE
LOCAL1 TYPE=TDOMAIN
ACCESSPOINTID="BA.CENTRAL01"
CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
After the required attributes have been set in the TUXCONFIG and BDMCONFIG files, boot the applications on LOCAL1 and REMOT1:
On LOCAL1:
dmadmin
passwd LOCAL1 REMOT1
Enter Local Domain Password:foo1
Reenter Local Domain Password:foo1
Enter Remote Domain Password:foo2
Reenter Remote Domain Password:foo2
On REMOT1:
dmadmin
passwd REMOT1 LOCAL1
Enter Local Domain Password:foo2
Reenter Local Domain Password:foo2
Enter Remote Domain Password:foo1
Reenter Remote Domain Password:foo1
Once passwords have been created on both domains, a connection can be established and services can be invoked on the remote domain.
Example 2: Setting Security to APP_PW
If the SECURITY parameter in the UBBCONFIG is set to APP_PW or higher, then SECURITY in the DMCONFIG can be set to NONE, APP_PW, or DM_PW. Because you can define multiple views of a domain in one DMCONFIG file (one view per local domain definition), you can assign a different type of security mechanism to each of those views.
Note: If SECURITY is set to APP_PW for a local domain access point in the DMCONFIG, then SECURITY in the UBBCONFIG must be set to APP_PW or higher.
Listing 2-15 Setting Security to APP_PW for Both Application and Domains
LOCAL1: SECURITY in UBBCONFIG set to APP_PW
SECURITY in DMCONFIG set to APP_PW
REMOT1: SECURITY in UBBCONFIG set to APP_PW
SECURITY in DMCONFIG set to APP_PW
In this example, both LOCAL1 and REMOT1 enforce APP_PW security.
On the initiator (LOCAL1) side, the pertinent attributes in UBBCONFIG and DMCONFIG are set as follows:
UBBCONFIG
*RESOURCES
SECURITY APP_PW
DMCONFIG
*DM_LOCAL
LOCAL1 GWGRP=bankg1
TYPE=TDOMAIN
ACCESSPOINTID="BA.CENTRAL01"
CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
SECURITY=APP_PW
*DM_REMOTE
REMOT1 TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
CONNECTION_PRINCIPAL_NAME="BA.BANK01"
On the responder (REMOT1) side, the pertinent attributes in UBBCONFIG and DMCONFIG are set as follows.
UBBCONFIG
*RESOURCES
SECURITY APP_PW
DMCONFIG
*DM_LOCAL
REMOT1 GWGRP=bankg2
TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
CONNECTION_PRINCIPAL_NAME="BA.BANK01"
SECURITY=APP_PW
*DM_REMOTE
LOCAL1 TYPE=TDOMAIN
ACCESSPOINTID="BA.CENTRAL01"
CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
After the TUXCONFIG and BDMCONFIG files have been created, boot the applications on LOCAL1 and REMOT1.
How to Configure Domains Access Control Lists
To set up a Domains access control list (ACL) in the DM_ACCESS_CONTROL section of the DMCONFIG file, you specify the name of the ACL and the remote domain access points associated with the ACL name. The following table clarifies the procedure.
Upon creating an ACL, you use the ACL parameter in the DM_EXPORT section of the DMCONFIG file to restrict access to a local service exported through a particular local domain access point to just those remote domain access points associated with the ACL name (for example, ACL=ACLGRP1). How to Configure ACL Policy for a Remote Domain As the administrator, you use the following configuration parameters to set and control the ACL policy for remote domains running BEA Tuxedo release 7.1 or later software. You set these parameters in the DM_REMOTE section of the DMCONFIG file.
Specifies the access control list (ACL) policy for this remote domain access point. This parameter applies only to domain gateways of type TDOMAIN running BEA Tuxedo 7.1 or later software and domain gateways of type OSITPX running BEA Tuxedo 8.0 or later software.
LOCAL means that the local domain replaces the credential (identity) of any service request received from the remote domain with the principal name specified in the LOCAL_PRINCIPAL_NAME parameter for this remote domain access point. GLOBAL means that the local domain does not replace the credential received with a remote service request; if no credential is received with a remote service request, the local domain forwards the service request to the local service as is (which usually fails). If not specified, the default is LOCAL.
The local principal name identifier (credential) assigned by the local domain to service requests received from the remote domain when the ACL_POLICY parameter for this remote domain access point is set (or defaulted) to LOCAL. This parameter applies only to domain gateways of type TDOMAIN running BEA Tuxedo 7.1 or later software and domain gateways of type OSITPX running BEA Tuxedo 8.0 or later software.
The LOCAL_PRINCIPAL_NAME parameter may contain a maximum of 511 characters (excluding the terminating NULL character). If this parameter is not specified, the local principal name defaults to the ACCESSPOINTID string for this remote domain access point.
Specifies the credential policy for this remote domain access point. This parameter applies only to domain gateways of type TDOMAIN running BEA Tuxedo 8.0 or later software.
LOCAL means that the local domain removes the credential (identity) from a local service request destined for this remote domain access point. GLOBAL means that the local domain does not remove the credential from a local service request destined for this remote domain access point. If not specified, the default is LOCAL.
Note that the CREDENTIAL_POLICY parameter controls whether or not the local domain removes the credential from a local service request before sending the request to a remote domain. The ACL_POLICY parameter controls whether or not the local domain replaces the credential of a service request received from a remote domain with the principal name specified in the LOCAL_PRINCIPAL_NAME parameter.
In the following example, the connection for the REMOT1 access point is configured for global ACL in the DMCONFIG file, meaning that the domain gateway for the LOCAL1 access point passes client requests from the REMOT1 access point without change. For global ACL, the LOCAL_PRINCIPAL_NAME entry for the REMOT1 access point is ignored. Also, because CREDENTIAL_POLICY=GLOBAL, the domain gateway for the LOCAL1 access point does not remove the credential from any local service request destined for the REMOT1 access point.
*DM_LOCAL
LOCAL1 GWGRP=bankg1
TYPE=TDOMAIN
ACCESSPOINTID="BA.CENTRAL01"
CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
SECURITY=DM_PW
*DM_REMOTE
REMOT1 TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
CONNECTION_PRINCIPAL_NAME="BA.BANK01"
ACL_POLICY=GLOBAL
CREDENTIAL_POLICY=GLOBAL
LOCAL_PRINCIPAL_NAME="BA.BANK01.BOB"
How to Configure Domains Link-Level Encryption
Domains link-level encryption (LLE) establishes data privacy for messages moving over the network links that connect the local domain gateway to the remote domain gateway. There are three levels of link-level encryption security: 0-bit (no encryption), 56-bit (International), and 128-bit (United States and Canada).
To set up Domains link-level encryption on domain gateway links, follow these steps.
*DM_TDOMAIN
LOCAL1 NWADDR="newyork.acme.com:65431"
MINENCRYPTBITS=min
MAXENCRYPTBITS=max
REMOT1 NWADDR="albany.acme.com:4051"
MINENCRYPTBITS=min
MAXENCRYPTBITS=max
In the preceding example, when tmboot(1) starts the application, each domain gateway reads the BDMCONFIG file to access various parameters, including MINENCRYPTBITS and MAXENCRYPTBITS, and propagates those parameters to its local and remote domains. When the local domain is establishing a network link with a remote domain, the two domains negotiate the key size until they agree on the largest key size supported by both.
Setting Up Connections in a Domains Configuration
You can specify the conditions under which a local domain gateway tries to establish a connection to a remote domain. To specify these conditions, assign a value to the CONNECTION_POLICY parameter in the DM_LOCAL section of the DMCONFIG file. You can select any of the following connection policies:
For BEA Tuxedo release 8.1 or later, you can also define the connection policy on a per remote domain basis in the DM_TDOMAIN section of the DMCONFIG file. For details, see How To Configure Your Connection Policy.
For connection policies of ON_STARTUP and INCOMING_ONLY, Dynamic Status is invoked. Dynamic Status, described in How Connection Policy Determines Availability of Remote Services, is a BEA Tuxedo Domains capability that checks and reports the status of remote services.
How to Request Connections for Client Demands (ON_DEMAND Policy)
A connection policy of ON_DEMAND (CONNECTION_POLICY=ON_DEMAND) means that a connection is attempted only when either a local client requests a remote service or an administrative dmadmin connect command is run. ON_DEMAND is the default connection policy setting.
The following diagram shows how connections are attempted and made by a domain gateway for which the connection policy is ON_DEMAND.
Figure 2-5 Connections Made with an ON_DEMAND Policy
How to Request Connections at Boot Time (ON_STARTUP Policy) A connection policy of ON_STARTUP (CONNECTION_POLICY=ON_STARTUP) means that a domain gateway attempts to establish a connection with its remote domains when the domain gateway server is initialized. By default, the ON_STARTUP connection policy retries failed connections every 60 seconds, but you can specify a different value for this interval, as explained in How to Configure the Connection Retry Interval for ON_STARTUP Only. The following diagram shows how connections are attempted and made by a domain gateway for which the connection policy is ON_STARTUP. Figure 2-6 Connections Made with an ON_STARTUP Policy
How to Limit Connections to Incoming Messages Only (INCOMING_ONLY Policy) A connection policy of INCOMING_ONLY (CONNECTION_POLICY=INCOMING_ONLY) means that a domain gateway does not try to establish a connection to remote domains upon starting. The following diagram shows how connections are attempted and made by a domain gateway for which the connection policy is INCOMING_ONLY. Figure 2-7 Connections Made with an INCOMING_ONLY Policy (Accept Incoming Connections)
How to Configure the Connection Retry Interval for ON_STARTUP Only When the CONNECTION_POLICY parameter is set to ON_STARTUP, automatic connection retry processing is available. Connection retry processing enables a domain gateway to retry, automatically, a failed attempt to connect to a remote domain. As the administrator, you can control the frequency of automatic connection attempts. To do so, specify the length (in seconds) of the interval during which the gateway should wait before trying, again, to establish a connection. You can specify the retry interval by setting the RETRY_INTERVAL parameter as follows: You can specify between 0 and 2147483647 seconds. If the connection policy is ON_STARTUP and you do not specify a value for the RETRY_INTERVAL parameter, a default of 60 seconds is used. The RETRY_INTERVAL parameter is valid only when the connection policy is ON_STARTUP. For the other connection policies (ON_DEMAND and INCOMING_ONLY), connection retry processing is not available. How to Configure the Maximum Retry Number You indicate the number of times that a domain gateway tries to establish connections to remote domains before quitting by assigning a value to the MAXRETRY parameter: the minimum value is 0; the default and maximum value is the value of the MAXLONG parameter (2147483647).
RETRY_INTERVAL=number_of_seconds
The MAXRETRY parameter is valid only when the connection policy is ON_STARTUP. For the other connection policies (ON_DEMAND and INCOMING_ONLY), connection retry processing is not available.
The following table presents examples of how MAXRETRY and RETRY_INTERVAL affect automatic connection retry processing.
Example of Coding Connection Policies Between Domains Because domains involved in a Domains configuration work independently of one another, any combination of connection policies is allowed in a Domains configuration. However, not every connection policy combination is practical. In most cases, for example, configuring each of two interoperating domains with a connection policy of ON_STARTUP does not make much sense. The following configuration example is a practical connection policy combination. In this example, LOCAL1 is configured for ON_STARTUP in the local DMCONFIG file, and REMOT1 is configured for INCOMING_ONLY in the remote DMCONFIG file. In local DMCONFIG file: In remote DMCONFIG file: *DM_LOCAL
*DM_LOCAL
LOCAL1 GWGRP=bankg1
TYPE=TDOMAIN
CONNECTION_POLICY=ON_STARTUP
MAXRETRY=5
RETRY_INTERVAL=100*DM_REMOTE
REMOT1 TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
REMOT1 GWGRP=bankg2
TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
CONNECTION_POLICY=INCOMING_ONLY*DM_REMOTE
LOCAL1 TYPE=TDOMAIN
ACCESSPOINTID="BA.CENTRAL01"
CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
Controlling Connections in a Domains Configuration
As the administrator, you can control the number of connections you want to establish between domains. You can also break the connections between local and remote domains.
How to Establish Connections Between Domains
To establish a connection between a local domain gateway and a remote domain, run the dmadmin command with the connect (co) subcommand:
prompt> dmadmin co -d local_domain_access_point_name
By default, connections are established between the local domain you have specified and all remote domains configured for the local gateway. If you want to establish a connection to only one remote domain, specify that domain on the command line with the -R option:
prompt> dmadmin co -d local_domain_access_point_name
-R remote_domain_access_point_name
If a connection attempt fails and the connection policy is ON_STARTUP with connection retry processing turned on, repeated attempts to connect (via connection retry processing) are made.
How to Break Connections Between Domains
To break a connection between a local gateway and a remote domain (making sure that the gateway does not try to re-establish the connection through automatic connection retry processing), run the dmadmin command with the disconnect (dco) subcommand:
prompt> dmadmin dco -d local_domain_access_point_name
By default, all remote domains configured for the local gateway are disconnected. If you want to end the connection to only one remote domain, specify that domain on the command line with the -R option:
prompt> dmadmin dco -d local_domain_access_point_name
-R remote_domain_access_point_name
Automatic connection retry processing is stopped by this command, regardless of whether there are any active connections when the command is run.
How to Report on Connection Status
Using the dmadmin printdomain command, you can generate a report on connection status and the connections being retried. The connect command reports whether a connection attempt has succeeded. The printdomain command prints information about the specified local domain, including a list of remote domains, a list of remote domains to which it is connected, and a list of remote domains to which it is trying to establish connections.
The following example shows a dmadmin session in which the printdomain command is issued (in its abbreviated form, pd) for a local domain access point named LOCAL1.
prompt> dmadmin
dmadmin - Copyright ...
.
.
.
pd -d LOCAL1
Local domain :LOCAL1
Connected domains:
Domainid: REMOT1
Disconnected domains being retried:
Domainid: REMOT2
dco -d LOCAL1 -R REMOT1
Operation completed successfully. Use printdomain(pd) to obtain results.
dco -d LOCAL1 -R REMOT2
Operation completed successfully. Use printdomain(pd) to obtain results.
co -d LOCAL1 -R REMOT1
Operation completed successfully. Use printdomain(pd) to obtain results.
pd -d LOCAL1
Local domain :LOCAL1
Connected domains:
Domainid: REMOT1
In this example, the remote domain access point names (REMOT1, REMOT2) and their DOMAINID—ACCESSPOINTID—names (REMOT1, REMOT2) are the same, as defined in the DM_REMOTE section of the DMCONFIG file, to keep the example simple.
Configuring Domains Link-Level Failover and Keepalive
Domains link-level failover is a mechanism that ensures that an alternate network link becomes active when a primary link fails. Domains keepalive is a mechanism that keeps interdomain connections open through firewalls during periods of inactivity and enables quick detection of connection failures. Domains keepalive is available in BEA Tuxedo release 8.1 or later.
For a description of Domains link-level failover, see How to Configure Domains Link-Level Failover. For a description of Domains keepalive, see Specifying Domains Keepalive.
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |