|
|
Working with Multiple Domains (BEA Tuxedo Systems)
This chapter describes the task of administering services across multiple Domains by using the BEA Tuxedo Domains feature. For information about configuring WebLogic Enterprise domains, refer to Configuring Multiple Domains (BEA WebLogic Enterprise Systems).
This topic includes the following sections:
Benefits of Using BEA Tuxedo System Domains
Using Domains provides the following benefits:
What Is the Domains Gateway Configuration File?
All domain configuration information is stored in a binary file, called the BDMCONFIG file. You can create and edit the domain gateway configuration file (DMCONFIG file), with any UNIX text editor. You can update the compiled BDMCONFIG file while the system is running by using the dmadmin(1) command when using Domains. There must be one BDMCONFIG file per BEA Tuxedo application.
A BEA Tuxedo system domain gateway is a server supplied by the BEA Tuxedo system that enables access to and from remote domains. Domains provides a gateway administrative server (GWADM) that enables run-time administration of the Domains gateway group, and a Domains administrative server (DMADM) that enables run-time administration of the Domains configuration information (BDMCONFIG). You enable remote domain access by specifying a gateway group and a domain administration group in the GROUPS section of the TUXCONFIG file, and by adding entries for the gateway and the two administrative servers in the SERVERS section.
In Figure 10-1, DGW is the domain gateway; GWADM is the gateway administrative server; DMADM is the Domains administrative server; and BDMCONFIG is the Domains gateway configuration file.
Figure 10-1 BEA Tuxedo Domains Gateway
Components of the DMCONFIG File
Table 10-1 describes the sections of the DMCONFIG file.
Section |
Purpose |
---|---|
DM_LOCAL_DOMAINS |
Describes the environment for a particular domain gateway group. You can use multiple entries in this section to define multiple gateway groups within a single BEA Tuxedo application. |
DM_REMOTE_DOMAINS |
Identifies the remote domains that clients and servers of this Domains application can access. |
DM_LOCAL_SERVICES |
Describes the set of services in this domain which remote domains can access. |
DM_REMOTE_SERVICES |
Describes the set of services provided by remote domains that are accessible from this domain. |
DM_ROUTING |
Specifies criteria for data-dependent routing used by gateways to route service requests to specific remote domains. |
DM_ACCESS_CONTROL |
Specifies a named list (the Access Control List) of remote domains permitted to access a particular service. |
DM_<dmtype> |
Defines the specific parameters required for a particular Domains instance. Currently, the value of dmtype can be OSITP, SNA, or TDOMAIN. (This chapter focuses only on TDOMAIN.) You must specify each domain type in a section of its own. |
Configuring Local and Remote Domains
To configure a local domain and a remote domain, perform the following tasks:
You need to set the following environment variables for the application to be configured successfully:
On AIX, LIBPATH must be set instead of LD_LIBRARY_PATH. On HP UX, SHLIB_PATH must be set instead of LD_LIBRARY_PATH. On Windows NT, no variable for shared libraries is required.
Examples
$ TUXDIR=/opt/tuxedo
$ PATH=$TUXDIR/bin:$PATH
$ LD_LIBRARY_PATH=$TUXDIR/lib:$LD_LIBRARY_PATH
$ export TUXDIR PATH LD_LIBRARY_PATH
Building a Local Application Configuration File and a Local Domains Gateway Configuration File
Build a local application configuration file using tmloadcf(1), and a local domain gateway configuration file using dmloadcf(1). The local application configuration file (lapp.ubb) contains the information necessary to boot the local application. This file is compiled into a binary data file (lapp.tux), using tmloadcf(1).
The local domain gateway configuration file (lapp.dom) contains the information used by domain gateways for communications with other domains. This file is compiled into a binary data file (lapp.bdm), using dmloadcf(1).
$ cd /home/lapp
$ TUXCONFIG=/home/lapp/lapp.tux; export TUXCONFIG
$ tmloadcf -y lapp.ubb
$ BDMCONFIG=/home/lapp/lapp_bdm; export BDMCONFIG
$ dmloadcf -y lapp.dom
$ tmboot -y
Building a Remote Application Configuration File and a Remote Domains Gateway Configuration File
Build a remote application configuration file and a remote domain gateway configuration file. The remote application configuration file (rapp.ubb) contains the information used by domain gateways for communication with other domains. This file is compiled into a binary data file (rapp.tux).
The remote domain gateway configuration file (rapp.dom) contains the information used by domain gateways to initialize the context required for communications with other domains. This configuration file is similar to the local domain gateway configuration file. The difference is in which services are exported and imported. This file is compiled into a binary data file (rapp.bdm).
$ cd /home/rapp
$ TUXCONFIG=/home/rapp/rapp.tux; export TUXCONFIG
$ tmloadcf -y rapp.ubb
$ BDMCONFIG=/home/rapp/rapp_bdm; export BDMCONFIG
$ dmloadcf -y rapp.dom
$ tmboot -y
Once you create both the local and remote domains, you can then boot the application using tmboot(1). The order in which the two domains are booted does not matter. Monitor the applications with dmadmin(1).
Once both applications are booted, a client in the local application can call the TOUPPER service residing in the remote application.
Example of a Domains-based Configuration
The Domains example, illustrated in Figure 10-2 and throughout this chapter, consists of two applications, both of which are based on the Simpapp example provided with the BEA Tuxedo system. The first application is called lapp for "local application;" the second application is called rapp for "remote application." lapp is configured to allow its clients to access a service called TOUPPER, which is advertised in rapp.
Figure 10-2 A Local and a Remote Application (simpapp)
Defining the Local Domains Environment
For the sample local application configuration file (lapp.ubb) shown in Listing 10-1, only the required parameters are defined. Default settings are used for the other parameters.
The following two server groups are defined:
The following three servers are defined:
Listing 10-1 Example of a Local Application Configuration File
# lapp.ubb
#
*RESOURCES
IPCKEY 111111
MASTER LAPP
MODEL SHM
*MACHINES
giselle
LMID=LAPP
TUXDIR="/opt/tuxedo"
APPDIR="/home/lapp"
TUXCONFIG="/home/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
Defining the Local and Remote Domains, Addressing, and Imported and Exported Services
For the sample local domain gateway configuration file (lapp.dom), shown in Listing 10-2, only the required parameters are defined. Default settings are used for the other parameters.
The DM_LOCAL_DOMAIN section identifies the local domains and their associated gateway groups. This section has one entry (LAPP) and specifies the parameters required for the domain gateway processes in that group, as follows:
The DM_REMOTE_DOMAINS section identifies the known set of remote Domains and their characteristics. This section has one entry (RAPP). TYPE is used to classify the type of Domains. DomainsID is a unique domain identifier.
The DM_TDOMAIN section defines the addressing information required by the BEA Tuxedo Domains feature. Following are entries in the section for each local and remote domain specified in this configuration file:
The DM_LOCAL_SERVICES section provides information about the services that are exported. This section has no entries because no services are being exported.
The DM_REMOTE_SERVICES section provides information about the services that are imported. The TOUPPER service is imported so that it can be accessed by clients in the local domains.
Listing 10-2 Example of a Local Domains Gateway Configuration File
#
# lapp.dom
#
*DM_LOCAL_DOMAINS
LAPP GWGRP=LGWGRP
TYPE=TDOMAIN
DOMAINID="111111"
*DM_REMOTE_DOMAINS
RAPP TYPE=TDOMAIN
DOMAINID="222222"
*DM_TDOMAIN
LAPP NWADDR="//mach1:5000"
RAPP NWADDR="//mach2:5000"
*DM_LOCAL_SERVICES
*DM_REMOTE_SERVICES
TOUPPER
Defining the Remote Domains Environment
For the sample remote application configuration file (rapp.ubb), shown in Listing 10-3, only the required parameters are defined. Default settings are used for the other parameters.
The following three server groups are defined:
The following four servers are defined:
Listing 10-3 Example of a Remote Application Configuration File
# rapp.ubb
#
*RESOURCES
IPCKEY 222222
MASTER RAPP
MODEL SHM
*MACHINES
juliet
LMID=RAPP
TUXDIR="/opt/tuxedo"
APPDIR="/home/rapp"
TUXCONFIG="/home/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
Defining the Exported Services
For the sample remote domain gateway configuration file (rapp.dom), shown in Listing 10-4, only the required parameters are defined. Default settings are used for the other parameters.
This configuration file is similar to the local domain gateway configuration file. The difference is in which services are exported and imported.
The DM_LOCAL_SERVICES section provides information about the services exported by each local domain. In this example, the TOUPPER service is exported and included in the DM_LOCAL_SERVICES section. No service is imported so there are no entries in the DM_REMOTE_SERVICES section.
Listing 10-4 Example of a Remote Domains Gateway Configuration File
# rapp.dom
#
*DM_LOCAL_DOMAINS
RAPP GWGRP=RGWGRP
TYPE=TDOMAIN
DOMAINID="222222"
*DM_REMOTE_DOMAINS
LAPP TYPE=TDOMAIN
DOMAINID="111111"
*DM_TDOMAIN
RAPP NWADDR="//mach2:5000"
LAPP NWADDR="//mach1:5000"
*DM_LOCAL_SERVICES
TOUPPER
*DM_REMOTE_SERVICES
Using Data Compression Between Domains
Data compression is useful in most applications and vital to supporting large configurations. When data is sent between Domains, you can elect to compress it for faster performance. This is configured by setting the CMPLIMIT parameter in the dmconfig(5). See Building Networked Applications, for more information on data compression.
Ensuring Security in Domains
Because Domains can exist under diverse ownership, multiple ways are offered to enable you to provide sufficient security:
Creating a Domain Access Control List (ACL)
To create a domain ACL, you must specify the name of the domain ACL and a list of the remote domains that are part of the list (the Domain Import List) in the DM_ACCESS_CONTROL section of the DMCONFIG file. Table 10-2 describes these two fields.
Fields |
Description |
---|---|
Domain ACL name |
The name of this ACL. A valid name consists of a string of 1-30 characters, inclusive. It must be printable and it may not include a colon, a pound sign, or a new line character. An example is: ACLGRP1 |
Domain import VIEW list |
The list of remote domains that are granted access for this access control list. A valid value in this field is a set of one or more comma-separated strings. An example is: REMDOM1,REMDOM2,REMDOM3 |
Routing Service Requests to Remote Domains
Information for data-dependent routing used by gateways to route service requests (to specific remote domains) is provided in the DM_ROUTING section of the DMCONFIG file. The FML32, VIEW32, FML, VIEW, X_C_TYPE, and X_COMMON typed buffers are supported. To create a routing table for a domain, you must specify the buffer type for which the routing entry is valid, the name of the routing entry and field, and the ranges and associated remote domain names of the routing field. Table 10-3 describes these fields.
Fields |
Description |
---|---|
Buffer type |
A list of types and subtypes of data buffers for which this routing entry is valid. The types may include FML32, VIEW32, FML, VIEW, X_C_TYPE, or X_COMMON. No subtype can be specified for type FML; subtypes are required for the other types. The * (or wildcard) value is not allowed. Duplicate type/subtype pairs cannot be specified for the same routing criteria name; more than one routing entry can have the same criteria name as long as the type/subtype pairs are unique. If multiple buffer types are specified for a single routing entry, the data types of the routing field for each buffer type must be the same. Valid values for type are: where the maximum length is 256 characters over 32 type/subtype combinations. Valid values for subtype are names that may not include semicolons, colons, commas, or asterisks. An example is FML. |
Domain routing criteria |
The name (identifier) of the routing entry. A valid value is any string of 1-15 characters, inclusive. An example is ROUTTAB1. |
Routing field name |
The name of the routing field. This field is assumed to be a field name that is identified in an FML field table (for FML buffers) or an FML VIEW table (for VIEW, X_C_TYPE, or X_COMMON buffers). A valid value is an identifier string that is 1-30 characters, inclusive. An example is FIELD1. |
Ranges |
The ranges and associated remote domain names (RDOM) for the routing field. The routing field can be of any data type supported in FML. A numeric routing field must have numeric range values, and a string routing field must have string range values. String range values for string, carray, and character field types must be placed inside a pair of single quotes and cannot be preceded by a sign. Short and long integer values are a string of digits, optionally preceded by a plus or minus sign. Floating point numbers are of the form accepted by the C compiler or atof()as follows: an optional sign, then a string of digits optionally containing a decimal point, then an optional e or E followed by an optional sign or space, followed by an integer. When a field value matches a range, the associated RDOM value specifies the remote domains to which the request should be routed. An RDOM value of * indicates that the request can go to any remote domain known by the gateway group. Valid values are a comma-separated ordered list of range/RDOM pairs where a range is one of two types: (a) a single value (signed numeric value or character string in single quotes); or (b) a range of the form lower-upper (where lower and upper are both signed numeric values or character strings in single quotes). Note that lower must be less than or equal to upper. Within a range/RDOM pair, the range is separated from the RDOM by a colon ( : ). MIN can be used to indicate the minimum value for the data type of the associated FIELD; for strings and carrays, it is the null string; for character fields, it is 0; for numeric values, it is the minimum numeric value that can be stored in the field. MAX can be used to indicate the maximum value for the data type of the associated FIELD; for strings and carrays, it is effectively an unlimited string of octal-255 characters; for a character field, it is a single octal-255 character; for numeric values, it is the maximum numeric value that can be stored in the field. Thus, MIN - -5 is all numbers less than or equal to -5 and - MAX is the set of all numbers greater than or equal to 6. The meta-character * (wildcard) in the position of a range indicates any values not covered by the other ranges previously seen in the entry; only one wildcard range is allowed per entry and it should be last (ranges following it are ignored). An example is 1-100:REMDOM3. |
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|