Figure 2‑1 shows two Oracle Tuxedo applications: the
bankapp application and a credit card authorization application.
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 Oracle 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 Oracle Tuxedo distribution is installed.
Listing 2‑1 shows the content of a file named
ubbmp, which is the
UBBCONFIG file for the multiple-machine version of 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
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"
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:
Listing 2‑2 shows a possible
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"
Another solution is to reconfigure the bankapp application and the credit card authorization application as a Domains configuration, as shown in
Figure 2‑3. The two domains interoperate through two TDomain gateway server processes, one running in each domain.
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 Oracle Tuxedo applications, and two
DMCONFIG files, one for each of the Oracle Tuxedo applications.
|
•
|
In the MACHINES section, remove the machine entry for the credit card authorization application.
|
|
•
|
In the NETWORK section, remove the network entry for the credit card authorization application.
|
|
•
|
In the GROUPS section, do the following:
|
|
•
|
In the SERVERS section, do the following:
|
|
•
|
In the SERVICES section, remove the service entries for the credit card authorization application.
|
Listing 2‑3 shows a possible
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.
|
You also need to create a DMCONFIG file for the
bankapp application, an example of which is shown in
Listing 2‑4. The binary version of the a
DMCONFIG file (
BDMCONFIG) must reside on the same machine as the
DMADM server.
*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”
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:
|
•
|
In the GROUPS section, add a group entry for the DMADM server and a different group entry for the GWADM and GWTDOMAIN servers.
|
|
•
|
In the SERVERS section, add server entries for the DMADM, GWADM, and GWTDOMAIN servers.
|
Listing 2‑5 shows a possible
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.
|
*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”
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 Oracle Tuxedo Applications” on page 2‑1—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 Oracle Tuxedo domains, one domain per machine, that interoperate using TDomain gateway server processes.
The creditapp application is included with the Oracle Tuxedo distribution. Its files reside at the following location:
Where tux_prod_dir represents the directory in which the Oracle Tuxedo distribution is installed.
The Domains configuration for the creditapp application requires four
UBBCONFIG files, one for each of the Oracle Tuxedo domains, and four
DMCONFIG files, one for each of the Oracle 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.
Listing 2‑7 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.
.
.
.
*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
Listing 2‑8 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” on page 1‑22.
#
#
*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_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>
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 Oracle Tuxedo on Windows, see,
Using Oracle Tuxedo ATMI on Windows.
Where tux_prod_dir represents the directory in which the Oracle Tuxedo distribution is installed.
The Domains example, illustrated in Figure 2‑4, consists of two Oracle 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.
|
•
|
TUXDIR—Absolute pathname to the Oracle Tuxedo system root directory on this machine; sometimes represented as tux_prod_dir.
|
|
•
|
APPDIR—Absolute pathname to the lapp application root directory on this machine.
|
|
•
|
TUXCONFIG—Absolute pathname of the device or filename where the application binary configuration file for lapp is found on this machine.
|
|
•
|
BDMCONFIG—Absolute pathname of the device or filename where the Domains binary configuration file for lapp is found on this machine.
|
|
•
|
PATH—must include %TUXDIR%\bin (Windows) or $TUXDIR/bin (UNIX).
|
|
•
|
LD_LIBRARY_PATH (UNIX only)—list of dynamically loadable libraries that must be loaded on this machine (must include $TUXDIR/lib); on HP-UX on the HP 9000, use SHLIB_PATH instead of LD_LIBRARY_PATH.
|
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%
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
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.
Listing 2‑9 shows the content of
lapp.ubb.
|
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.
|
|
•
|
LDMGRP—contains the Domains administrative server ( DMADM).
|
|
•
|
LGWGRP—contains the gateway administrative server ( GWADM) and the TDomain gateway server ( GWTDOMAIN).
|
|
•
|
DMADM—the Domains administrative server enables run-time modification of the Domains configuration information in the binary Domains configuration file ( BDMCONFIG). DMADM supports a list of registered gateway groups. Only one instance of DMADM may be running in an Oracle Tuxedo domain involved in a Domains configuration.
|
|
•
|
GWADM—the gateway administrative server enables run-time administration of a particular domain gateway group. This server gets Domains configuration information from the DMADM server. It also provides administrative functionality and transaction logging for the gateway group.
|
|
•
|
GWTDOMAIN—the TDomain gateway server enables access to and from remote Oracle Tuxedo domains, allowing interoperability of two or more Oracle Tuxedo domains. Information about the local and remote services that the TDomain gateway exports and imports is included in the Domains configuration file ( DMCONFIG).
|
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.
Listing 2‑10 shows the content of the
lapp.dom file.
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:
|
•
|
GWGRP value is LGWGRP, the name of the domain gateway server group specified in the lapp.ubb file.
|
|
•
|
TYPE of TDOMAIN indicates that the lapp application will be communicating with the rapp application through the local TDomain gateway server. This parameter indicates the protocol used by the gateways. Other TYPE values include IDOMAIN (Oracle eLink Adapter for Mainframe gateway), SNAX (Oracle eLink Adapter for Mainframe SNA gateway), and OSITP/ OSITPX (Oracle eLink Adapter for Mainframe OSI TP gateway).
|
|
•
|
ACCESSPOINTID identifies the name of the local domain access point; this identifier must be unique across all domains involved in the Domains configuration.
|
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:
|
•
|
TYPE of TDOMAIN indicates that the lapp application will be communicating with the rapp application through the local TDomain gateway server.
|
|
•
|
ACCESSPOINTID identifies the name of the remote domain access point; this identifier must be unique across all domains involved in the Domains configuration.
|
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.
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.
The DM_TDOMAIN section defines the addressing information required by the Oracle 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.
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.
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).
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
|
•
|
TUXDIR—Absolute pathname to the Oracle Tuxedo system root directory on this machine; sometimes represented as tux_prod_dir.
|
|
•
|
APPDIR—Absolute pathname to the rapp application root directory on this machine.
|
|
•
|
TUXCONFIG—Absolute pathname of the device or filename where the application binary configuration file for rapp is found on this machine.
|
|
•
|
BDMCONFIG—Absolute pathname of the device or filename where the Domains binary configuration file for rapp is found on this machine.
|
|
•
|
PATH—must include %TUXDIR%\bin (Windows) or $TUXDIR/bin (UNIX).
|
|
•
|
LD_LIBRARY_PATH (UNIX only)—list of dynamically loadable libraries that must be loaded on this machine (must include $TUXDIR/lib); on HP-UX on the HP 9000, use SHLIB_PATH instead of LD_LIBRARY_PATH.
|
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%
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
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.
Listing 2‑11 shows the content of the
rapp.ubb file.
|
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.
|
|
•
|
RDMGRP—contains the Domains server DMADM.
|
|
•
|
RGWGRP—contains the Domains servers GWADM and GWTDOMAIN.
|
|
•
|
APPGRP—contains the application server simpserv.
|
The simpserv server advertises the
TOUPPER service, which converts strings from lowercase to uppercase characters.
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.
Listing 2‑12 shows the content of the
rapp.dom file.
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:
|
•
|
Specifies that the rapp application will listen for incoming connection requests on network address juliet:5000, where juliet is the name of the machine on which the rapp application is running, and 5000 is the listening port.
|
|
•
|
Specifies that if the rapp application attempts to make a connection to the lapp application, it will use the network address giselle:5000, where giselle is the name of the machine on which the lapp application is running, and 5000 is the destination port.
|
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).
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
|
•
|
UBBCONFIG(5) in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference
|
|
•
|
DMCONFIG(5) in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference
|
|
•
|
Authentication—Verifies the identities of the local domain and a remote domain when attempting to establish a connection to one another
|
|
•
|
Authorization—Restricts remote client access to local services via access control lists (ACLs)
|
|
•
|
Domains authentication—Supplies the means by which the local domain and a remote domain can mutually authenticate one another when attempting to connect to one another. You specify identities, or principal names, for the local domain and each remote domain via the CONNECTION_PRINCIPAL_NAME parameter in the DM_LOCAL and DM_REMOTE sections of the DMCONFIG file.
|
|
•
|
Domains local domain access—Restricts local services to remote domains. If a service is not exported to remote domains, it is unavailable to them. You export a service by placing an entry for the service in the DM_EXPORT section of the DMCONFIG file.
|
|
•
|
Domains access control lists (ACLs)—Restricts the availability of services in a local domain to only certain remote domains. You create ACL names in the DM_ACCESS_CONTROL section of the DMCONFIG file and apply the ACL names to services in the EXPORT section of the DMCONFIG file.
|
|
•
|
Domains ACL policy—Controls the ACL policy for remote domains. You configure a local or global ACL policy for a remote domain via the ACL_POLICY parameter in the DM_REMOTE section of the DMCONFIG file.
|
|
•
|
Domains link-level encryption—Ensures data privacy between communicating domain gateways. For TDomain gateways, you configure link-level encryption by setting the MINENCRYPTBITS and MAXENCRYPTBITS parameters in the DM_TDOMAIN section of the DMCONFIG file.
|
As described in “Establishing a Link Between Domains” 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 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.
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"
|
•
|
No security (using the NONE option)—Incoming connections from remote domains are not authenticated.
|
|
•
|
Application password (using the APP_PW option)—Incoming connections from remote domains are authenticated using the application password defined in the TUXCONFIG file. (The application password is not included in the UBBCONFIG file.) The Oracle Tuxedo application password is administered with tmloadcf(1), which prompts for the password when the SECURITY option is enabled in the TUXCONFIG file. The password is automatically propagated with the TUXCONFIG file to the other machines in the configuration. You can update the password dynamically using the tmadmin command.
|
|
•
|
Domains password (using the DM_PW option )—Connections between the local and remote domains are authenticated using passwords defined in the DM_PASSWORDS section of the BDMCONFIG file. (The DM_PASSWORDS section is not included in the DMCONFIG file.) These passwords are added to the binary configuration file after dmloadcf has been run, using DM_MIB(5) or the passwd subcommand of the dmadmin(1) command. Each entry contains the password used by a remote domain to access the local domain, and the password required by the local domain to access a remote domain.
|
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.
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.
|
•
|
TA_DMLACCESSPOINT—Name of the local domain access point to which the password applies.
|
|
•
|
TA_DMRACCESSPOINT—Name of the remote domain access point to which the password applies.
|
|
•
|
TA_DMLPWD—Local password used to authenticate connections between the local domain access point (identified by TA_DMLACCESSPOINT) and the remote domain access point (identified by TA_DMRACCESSPOINT).
|
|
•
|
TA_DMRPWD—Remote password used to authenticate connections between the remote domain access point (identified by TA_DMRACCESSPOINT) and the local domain access point (identified by TA_DMLACCESSPOINT).
|
prompt> dmadmin
passwd [-r] local_domain_access_point_name
remote_domain_access_point_name
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.
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 shows setting security to NONE for both application and domains.
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:
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:
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"
Listing 2‑14 shows the 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:
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:
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"
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 shows the setting security to APP_PW for both application and domains.
On the initiator (LOCAL1) side, the pertinent attributes in
UBBCONFIG and
DMCONFIG are set as follows:
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.
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.
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).
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 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.
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"
|
1.
|
Open the DMCONFIG file with a text editor and add the following lines to the DM_TDOMAIN section.
|
*DM_TDOMAIN
LOCAL1 NWADDR=“
newyork.acme.com:65431”
MINENCRYPTBITS=
min
MAXENCRYPTBITS=
max
REMOT1 NWADDR=“
albany.acme.com:4051”
MINENCRYPTBITS=
min
MAXENCRYPTBITS=
max
|
2.
|
Load the configuration by running dmloadcf(1). The dmloadcf command parses DMCONFIG and loads the binary BDMCONFIG file to the location referenced by the BDMCONFIG variable.
|
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.
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.
Figure 2‑5 shows how connections are attempted and made by a domain gateway for which the connection policy is
ON_DEMAND.
Figure 2‑6 shows how connections are attempted and made by a domain gateway for which the connection policy is
ON_STARTUP.
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.
Figure 2‑7 shows how connections are attempted and made by a domain gateway for which the connection policy is
INCOMING_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:
RETRY_INTERVAL=number_of_seconds
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.
|
•
|
If you set MAXRETRY=0, connection retry processing is turned off. The local domain gateway does not attempt to connect to the remote domain gateway(s) automatically.
|
|
•
|
If you set MAXRETRY=number, the gateway tries to establish a connection the specified number of times before quitting.
|
|
•
|
If you set MAXRETRY=MAXLONG, the default setting, connection retry processing is repeated up to 2147483647 times or until a connection is established.
|
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.
Table 2‑2 presents examples of how
MAXRETRY and
RETRY_INTERVAL affect automatic connection retry processing.
*DM_LOCAL
LOCAL1 GWGRP=bankg1
TYPE=TDOMAIN
CONNECTION_POLICY=ON_STARTUP
MAXRETRY=5
RETRY_INTERVAL=100
*DM_REMOTE
REMOT1 TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
*DM_LOCAL
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"
prompt> dmadmin co -d local_domain_access_point_name
prompt> dmadmin co -d local_domain_access_point_name
-R remote_domain_access_point_name
prompt> dmadmin dco -d local_domain_access_point_name
prompt> dmadmin dco -d local_domain_access_point_name
-R remote_domain_access_point_name
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.
|
•
|
.SysConnectionConfig - Connection configuration has changed. The Connection configuration changed event may happen when the following configuration parameters change between two domains:
|
|
•
|
.SysConnectionDropped - Connection has dropped. The .SysConnectionDropped event must also indicate the reason for the drop. There are three specific reasons why a connection drop can occur and each of them must be appended to the INFO message. They are:
|
|
•
|
.SysConnectionFailed - Connection is unsuccessful. The .SysConnectionFailed event also indicates the reason for failure. There can be several reasons for why a failure and all must be appended to the INFO message:
|
