		BEA WebLogic Enterprise 4.2 Developer Center
		HOME \| SITE MAP \| SEARCH \| CONTACT \| GLOSSARY \| PDF FILES \| WHAT'S NEW
		Administration \| TABLE OF CONTENTS \| PREVIOUS TOPIC \| NEXT TOPIC \| INDEX

Working with Multiple Domains (BEA TUXEDO System)

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 Chapter 9, "Configuring Multiple Domains (WLE System)."

This chapter discusses the following topics:

Benefits of Using BEA TUXEDO System Domains

Using Domains provides the following benefits:

Scalability and modular growth-Programmers can structure their application for modularity, isolation of failures, and independent growth. Interoperation with other transaction processing applications is achieved easily by adding to the Domains configuration the description of the interfaces (that is, services) used by a remote application.
Transparency and independence-Applications are totally unaware of service distribution. A service may be available on the same machine, on another machine in the local domain, or on a remote domain. Client application programmers do not need to know the implementation changes made to a service, the location of a service, network addresses, and so on.
Aliasing capability-This allows you to define a mapping between the service names used by a remote application and the service names used by the local application, allowing for easy integration of applications that use different naming schemes.
Transaction management and reliability-The Domains feature us integrated with the BEA TUXEDO system transaction management capabilities.
Availability-You can specify alternate destinations to handle failure conditions.
Security-An access control list (ACL) facility is provided to restrict access to local services from a particular set of remote domains. Domains also provides encryption and password verification.

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

The following table describes the sections of the DMCONFIG file.


Section of the DMCONFIG File	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:

Set environment variables
Build a local application configuration file and a local domain gateway configuration file
Build a remote application configuration file and a remote domain gateway configuration file

Setting Environment Variables

You need to set the following environment variables for the application to be configured successfully:

TUXDIR-The root directory (for example, /opt/tuxedo)
TUXCONFIG-The application configuration file (for example, lapp.tux or rapp.tux)
BDMCONFIG-The Domains gateway configuration file (for example, lapp.bdm or rapp.bdm)
PATH-Must include $TUXDIR/bin
LD_LIBRARY_PATH-Must include $TUXDIR/lib

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 NT, no variable for shared libraries is required.

Example

$ 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 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.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 first contains the domain administrative server (DMADM).
The second contains the gateway administrative server (GWADM) and the domain gateway (GWTDOMAIN).

The following three servers are defined:

DMADM-The domain administrative server enables run-time administration of the configuration information required by domain gateway groups. This server provides run-time administration of the binary domain configuration file and supports a list of registered gateway groups. (There must be only one instance of DMADM per Domains application.)
GWADM-The gateway administrative server enables run-time administration of a particular Domains gateway group. This server gets domain configuration information from the DMADM server. It also provides administrative functionality and transaction logging for the gateway group.

GWTDOMAIN-The domain gateway server enables access to and from remote Domains. It allows for interoperability of two or more BEA TUXEDO domains. Information about the local and remote services it needs to export and import is included in the domain configuration file. The domain gateway server should always be configured with REPLYQ=N.

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:

GWGRP specifies the name of the gateway server group as specified in the application.
TYPE of TDOMAIN indicates that the local domain will be communicating with another BEA TUXEDO domain. Other options are SNA and OSI.
DOMAINID identifies the name of the Domains gateway and must be unique across all Domains.

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:

NWADDR specifies either the network address to accept connections from other BEA TUXEDO Domains (local Domains entry), or the network address to connect to other BEA TUXEDO Domains (remote Domains entry).

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 first server group (SRVGP=RDMGRP) contains the Domains administrative server (DMADM).
The second server group (SRVGP=RGWGRP) contains the gateway administrative server, GWADM, and the Domains gateway, GWTDOMAIN.
The third server group (SRVGP=APPGRP) contains the application server simpserv.

The following four servers are defined:

DMADM-The Domains administrative server
GWADM-The gateway administrative server
GWTDOMAIN-The Domains gateway server

simpserv-The simple application server that advertises the TOUPPER service, which converts strings from lowercase to uppercase characters

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 Chapter 6, "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:

Local Domains-Provides a first level of security. A partial view of the application (that is, a subset of services) can be made available to remote domains. This partial view is defined by including the corresponding services in the DM_LOCAL_SERVICES section of the DMCONFIG file.
Domains Passwords-Authentication techniques are required to ensure the proper identity of each remote domain. Domains provides a facility for the definition of passwords on a per-remote-domain basis. This is configured by setting SECURITY=DM_PW in dmconfig(5).
Access Control-Access control provides another level of security in which you can restrict access to services within a local domain such that only selected remote domains can execute these services. This is configured in the DM_ACCESS_CONTROL section of the dmconfig(5).
Link-Level Encryption- Encryption can be used across domains to ensure data privacy, so a network-based eavesdropper cannot learn the content of BEA TUXEDO messages or application-generated messages from domain gateway to domain gateway. This is configured by setting MINENCRYPTBITS and MAXENCRYPTBITS in the dmconfig(5). (See Chapter 6, "Building Networked Applications," for more information.)

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. The following chart describes these two fields.


Domain ACL Field	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. The following table describes these fields.


Routing Table 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: `[:``subtype1``[,``subtype2` `. . .]][;``type2``[:``subtype3``[,``subtype4` `. . . ]]] . . .` where the maximum length is 256 characters over 32 `type`/`subtype` combinations. Valid values for `subtype` are names 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 a`tof()`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 � 1999 BEA Systems, Inc. All Rights Reserved.
Required browser version: Netscape Communicator version 4.0 or higher, or Microsoft Internet Explorer version 4.0 or higher.
Last update: July 05, 1999.