[Top] [Previous Page] [Next Page] [Bottom]


Chapter 8. Working with Multiple Domains

This chapter describes the task of administering services across multiple Domains by using the BEA TUXEDO Domains feature. This chapter discusses the following topics:

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 8-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 8-1 BEA TUXEDO Domains Gateway

graphic3.gif (9123 bytes)

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:

Setting Environment Variables

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

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.dom; 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.dom; 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 8-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, rapp for "remote application." lapp is configured to allow its clients to access a service called TOUPPER, which is advertised in rapp.

Figure 8-2 A Local and a Remote Application (simpapp)

simpapp.gif (5863 bytes)

Defining the Local Domains Environment

For the sample local application configuration file (lapp.ubb) shown in Listing 8-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:

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 8-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 8-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 8-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:

Defining the Exported Services

For the sample remote domain gateway configuration file (rapp.dom), shown in Listing 8-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 8-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:

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 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.


[Top] [Previous Page] [Next Page] [Bottom]