Configuring BDMCONFIG


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| Download Documentation \| Contact \| Glossary

\| WebLogic Server Doc Home \| WTC Administration Guide \| Previous Topic \| Next Topic \| Contents \| View as PDF

Note: For more detailed reference information on the WebLogic Tuxedo Connector XML configuration file, elements and attributes, and the wtc_config.dtd, see The wtc_config.dtd.

The BDMCONFIG section of the WebLogic Tuxedo Connector XML configuration file describes how to establish connectivity and provide security between domains in the WebLogic Server and Tuxedo environments. The XML configuration file is composed of configuration parameters that are analogous to the interoperability attributes required for the communication between Tuxedo domains.

If the WebLogic Tuxedo Connector is configured, it is started as part of the WebLogic Server application environment. Any configuration condition that prevents the WebLogic Tuxedo Connector from starting results in an error being logged to the WebLogic Server error log.

The following sections provide configuration information about BDMCONFIG:

Configuring the Connections Between Domains

Note: For more information on Dynamic Status, see How ConnectionPolicy Affects Dynamic Status.

Several options can specify the conditions under which a local domain gateway tries to establish a connection with a remote domain. Specify these conditions using the ConnectionPolicy parameter in the T_DM_LOCAL_TDOMAIN and T_DM_REMOTE_TDOMAIN sections of BDMCONFIG. You can select any of the following connection policies:

For connection policies of ON_STARTUP and INCOMING_ONLY, Dynamic Status is invoked. Dynamic Status checks and reports on the status of remote services.

How to Request a Connection at Boot Time (ON_STARTUP)

A policy of ON_STARTUP means that a domain gateway attempts to establish a connection with its remote domain access points at gateway server initialization time. The connection policy retries failed connections at regular intervals determined by the RetryInterval parameter and the MaxRetries parameter. To request a connection at boot time, the following entry is required in the BDMCONFIG section of your XML configuration file:

Example:

          <ConnectionPolicy>ON_STARTUP</ConnectionPolicy>

How to Configure RetryInterval

You can control the frequency of automatic connection attempts by specifying the interval (in seconds) during which the gateway should wait before trying to establish a connection again. The minimum value is 0; the default value is 60, and maximum value is 2147483647. The following example specifies that the gateway waits 30 seconds before trying to establish a connection again.

Example:

            <RetryInterval>30</RetryInterval>

How to Configure MaxRetries

Note: Use only when ConnectionPolicy is set to ON_STARTUP. For other connection policies, retry processing is disabled.

You indicate the number of times a domain gateway tries to establish connections to remote domain access points before quitting by assigning a value to the MaxRetries parameter: the minimum value is 0; the default and maximum value is 2147483647.

If you set MaxRetries to 0, automatic connection retry processing is turned off. The server does not attempt to connect to the remote gateway automatically.
Example:
```
            <MaxRetries>0</MaxRetries>
```
If you set MaxRetries to a number, the gateway tries to establish a connection the specified number of times before quitting. In the following example, the server tries to establish a connection 10 times before quitting.
Example:
```
            <MaxRetries>10</MaxRetries>
```

If you set MaxRetries to 2147483647, retry processing is repeated indefinitely or until a connection is established.

Example:

            <MaxRetries>2147483647</MaxRetries>

Table 3-1 Example Settings of MaxRetries and RetryInterval Parameters

If you set ...	Then ...
<ConnectionPolicy>ON_STARTUP</ConnectionPolicy> <RetryInterval>30</RetryInterval> <MaxRetries>3</MaxRetries>	The gateway makes 3 attempts to establish a connection, at 30 seconds intervals, before quitting.
<ConnectionPolicy>ON_STARTUP</ConnectionPolicy> <MaxRetries>0</MaxRetries>	The gateway attempts to establish a connection at initialization time but does not retry if the first attempt fails.
<ConnectionPolicy>ON_STARTUP</ConnectionPolicy> <RetryInterval>30</RetryInterval>	The gateway attempts to establish a connection every 30 seconds until a connection is established.

If you set ...

Then ...

<ConnectionPolicy>ON_STARTUP</ConnectionPolicy>

The gateway makes 3 attempts to establish a connection, at 30 seconds intervals, before quitting.

<ConnectionPolicy>ON_STARTUP</ConnectionPolicy>

The gateway attempts to establish a connection at initialization time but does not retry if the first attempt fails.

<ConnectionPolicy>ON_STARTUP</ConnectionPolicy>

The gateway attempts to establish a connection every 30 seconds until a connection is established.

How to Request Connections for Client Demands (ON_DEMAND)

Note: If the ConnectionPolicy is not specified in the XML configuration file, the WebLogic Tuxedo Connector uses a ConnectionPolicy of ON_DEMAND.

A connection policy of ON_DEMAND means that a connection is attempted only when requested by either a client request to a remote service or an administrative connect command. To allow requests for client demands for a connection, use the following entry in the BDMCONFIG section of your XML configuration file:

Example:

          <ConnectionPolicy>ON_DEMAND</ConnectionPolicy>

Accepting Incoming Connections (INCOMING_ONLY)

A connection policy of INCOMING_ONLY means that a domain gateway does not to establish a connection to remote domains upon starting. The domain gateway is available for incoming connections from remote domain access points and remote services are advertised when the domain gateway for this local domain access point receives an incoming connection. To allow requests for client demands for a connection, use the following entry in the BDMCONFIG section of your XML configuration file:

Example:

          <ConnectionPolicy>INCOMING_ONLY</ConnectionPolicy>

How to use LOCAL Connection Policy

Note: A ConnectionPolicy of LOCAL is not valid for local domains.

A connection policy of LOCAL indicates that a remote domain connection policy is explicitly defaulted to the local domain ConnectionPolicy attribute value. If the remote domain ConnectionPolicy is not defined, the system uses the setting specified by the associated local domain (specified by the LocalAccessPoint). To set a remote domain connection policy to LOCAL, use the following entry in the T_DM_REMOTE_TDOMAIN section of your XML configuration file:

Example:

          <ConnectionPolicy>LOCAL</ConnectionPolicy>

How ConnectionPolicy Affects Dynamic Status

Dynamic Status is a feature of the gateway process (GWTDOMAIN) to determine the availability of remote services. The connection policy used in the WebLogic Tuxedo Connector configuration file determines whether the Dynamic Status feature is available for a service. The following table describes how ConnectionPolicy affects Dynamic Status capability.

ON_STARTUP	Dynamic Status is on. Services imported from a remote domain are advertised while a connection to that remote domain exists.
ON_DEMAND	Dynamic Status is off. Services imported from remote domains are always advertised.
INCOMING_ONLY	Dynamic Status is on. Remote services are initially suspended. The domain gateway is available for incoming connections from remote domains. Remote services are advertised when the local domain gateway receives an incoming connection.

Configuring Domains-level Failover and Failback

Note: In the Tuxedo T/ Domain, there is a limit of 3 backup remote domains. The WebLogic Tuxedo Connector has no limit to the number of backup domains allowed to be configured for a service.

Domains-level failover is a mechanism that transfers requests to alternate remote domains when a failure is detected with a primary remote domain. It also provides failback to the primary remote domain when that domain is restored.

This level of failover/failback depends on Dynamic Status. The domain must be configured with a CONNECTION_POLICY of ON_STARTUP or INCOMING_ONLY to enable Domains-level failover/failback.

Domains-level failover/failback defines a remote domain as available when a network connection to the remote domain exists, and unavailable when a network connection to the remote domain does not exist.

Prerequisite to Using Domains-level Failover and Failback

To use Domains-level failback, you must specify ON_STARTUP or INCOMING_ONLY as the value of the CONNECTION_POLICY parameter.

A connection policy of ON_DEMAND is unsuitable for Domains-level failback as it operates on the assumption that the remote domain is always available. If you do not specify ON_STARTUP or INCOMING_ONLY as your connection policy, your servers cannot fail over to the alternate remote domains that you have specified with the Tuxedo RDOM parameter.

Note: A remote domain is available if a network connection to it exists; a remote domain is unavailable if a network connection to it does not exist.

How to Configure Domains to Support Failover

To support failover, you must specify the remote domains responsible for executing a particular service. Specifically, you must specify each remote domain with a T_DM_REMOTE_TDOMAIN section in your XML configuration file.

Suppose a service is available from two remote domains: TDOM1 and TDOM3. Include the following entry in the BDMCONFIG section on your XML configuration file:

<T_DM_REMOTE_TDOMAIN AccessPoint="TDOM1">

		<LocalAccessPoint>TDOM2</LocalAccessPoint>

		<AccessPointId>TDOM1</AccessPointId>

		<Type>TDOMAIN</Type>

		<NWAddr>//mydomain.acme.com:20305</NWAddr>

</T_DM_REMOTE_TDOMAIN>

<T_DM_REMOTE_TDOMAIN AccessPoint="TDOM3">

		<LocalAccessPoint>TDOM2</LocalAccessPoint>

		<AccessPointId>TDOM3</AccessPointId>

		<Type>TDOMAIN</Type>

		<NWAddr>//myotherdomain.com:50302</NWAddr>

</T_DM_REMOTE_TDOMAIN>

How to Configure Domains to Support Failback

Failback occurs when a network connection to the primary remote domain is reestablished for any of the following reasons:

Automatic retries (ON_STARTUP only)
Incoming connections

Authentication of Remote Domains

Note: Tuxedo 6.5 users should set the Interoperate parameter to Yes and set the Security parameter to NONE. If you require security features and use the WebLogic Tuxedo Connector, you will need to upgrade to Tuxedo 7.1 or higher.

Domain gateways can be made to authenticate incoming connections requested by remote domains and outgoing connections requested by local domains. Application administrators can define when security should be enforced for incoming connections from remote domains. You can specify the level of security used by a particular local domain by setting the SECURITY parameter in the T_DM_LOCAL_TDOMAIN section of your XML configuration file. There are three levels of password security:

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 T_DM_PASSWORD element of the XML configuration file. You use the weblogic.wtc.gwt.genpasswd utility to create encrypted application passwords.
Remote Domains Password (using the DM_PW option)—this feature enforces security between two or more domains. Connections between the local and remote domains are authenticated using password pairs defined in the T_DM_PASSWORD element of the XML configuration file. You use the weblogic.wtc.gwt.genpasswd utility to create encrypted remote domains passwords.

The SECURITY parameter in the T_DM_LOCAL_TDOMAIN section of your XML configuration file must match the SECURITY parameter of the *DM_LOCAL_DOMAINS section of the Tuxedo domain configuration file.

If authentication is required, it is done every time a connection is established between the local domain and a remote domain.
If the security type of the T_DM_LOCAL_TDOMAIN does not match the security type of the *DM_LOCAL_DOMAINS or if the passwords do not match, the connection fails.

Setting the T_DM_PASSWORD Element

Use weblogic.wtc.gwt.genpasswd to generate encrypted passwords for LocalPassword, RemotePassword, and AppPassword elements. The utility uses a key to encrypt a password that is copied into the WebLogic Tuxedo Connector XML configuration file. The result is a valid WebLogic Tuxedo Connector XML element.

The XML configuration file does not store clear text passwords.
The key must included in the Argument field of the StartUp class to provide the WebLogic Tuxedo Connector access to the key on startup.
- Use the PasswordKey parameter to assign the key.
- The PasswordKey argument can only be assigned one key value.
- If there are no T_DM_PASSWORD entries in the XML configuration file, the PasswordKey argument is ignored.

Usage

Call the utility without any arguments to display the command line options.

Example:

$ java weblogic.wtc.gwt.genpasswd

Usage: genpasswd Key <LocalPassword|RemotePassword|AppPassword> 
<local|remote|application>

Examples

This section provides examples of each of the password element types.

LocalPasswords

The following example uses key1 to encrypt "LocalPassword1" as the password of the local domain.

$ java weblogic.wtc.gwt.genpasswd Key1 LocalPassword1 local

<LocalPassword IV="I#^Da0efo1">!djK*87$klbJJ</LocalPassword>

RemotePasswords

The following example uses mykey to encrypt "RemotePassword1" as the password for the remote domain.

$ java weblogic.wtc.gwt.genpasswd mykey RemotePassword1 remote

<RemotePassword IV="Rq$45%%kK">McFrd3#f41Kl</RemotePassword>

AppPasswords

The following example uses key1 to encrypt "test123" as the application password.

$ weblogic.wtc.gwt.genpasswd mykey test123 application

<AppPassword IV="gx8aSkAgLFg=">c98Y/P94HY3rCAVmkF=</AppPassword>

User Authentication

Note: Tuxedo 6.5 users should set the Interoperate parameter to Yes and set the Security parameter to NONE. The AclPolicy and CredentialPolicy elements are ignored if the WebLogic Tuxedo Connector is used to interoperate with Tuxedo 6.5. If you require security features and use the WebLogic Tuxedo Connector, you will need to upgrade to Tuxedo 7.1 or higher.

Access Control Lists (ACLs) limit the access to local services within a local domain by restricting the remote domains that can execute these services. Inbound policy from a remote domain is specified using the AclPolicy element. Outbound policy towards a remote domain is specified using the CredentialPolicy element. This allows WebLogic Server and Tuxedo applications to share the same set of users and the users are able to propagate their credentials from one system to the other.

The valid values for this parameter are:

LOCAL: The domain gateway's security token is passed.
GLOBAL: The user's security token is passed.

Security Requirements for servers

If the RemoteAccessPoint is running with an AclPolicy of LOCAL, then any requests from that RemoteAccessPoint must have the credentials of the WebLogic Tuxedo Connector instantiation.
If the RemoteAccessPoint is running with an AclPolicy of GLOBAL, then any requests from that RemoteAccessPoint must have the user identity from the token received on the request.

Security Requirements for clients

If a remote domain is running with the CredentialPolicy set to LOCAL then the request to Tuxedo has the credentials of the remote domain gateway.
If a remote domain is running with the CredentialPolicy set to GLOBAL then the WebLogic Tuxedo Connector constructs tokens based on the identity of the caller.

How to Configure WebLogic Tuxedo Connector to Provide Security between Tuxedo and WebLogic Server

Note: Tuxedo 6.5 does not have the required security infrastructure to support security mapping. Tuxedo 6.5 users should set the Interoperate parameter to Yes and set the Security parameter to NONE. If you require security features and use the WebLogic Tuxedo Connector, you will need to upgrade to Tuxedo 7.1 or higher.

Use the following steps to configure WebLogic Tuxedo Connector to provide security between Tuxedo and WebLogic Server applications:

Configure the T_DM_LOCAL_TDOMAIN

Set the SECURITY parameter in the T_DM_LOCAL_TDOMAIN section of your XML configuration file to match the SECURITY parameter of the *DM_LOCAL_DOMAINS section of the Tuxedo domain configuration file.

Example T_DM_LOCAL_TDOMAIN Configuration

<T_DM_LOCAL_TDOMAIN AccessPoint="Your weblogic domain">

     <Type>TDOMAIN</Type>

     <Security>DM_PW</Security>

     <ConnectionPolicy>ON_DEMAND</ConnectionPolicy>

     <ConnPrincipalName>wldom1</ConnPrincipalName>

     <NWAddr>//DKUMAR:3045</NWAddr>

     <Interoperate>Yes</Interoperate>

</T_DM_LOCAL_TDOMAIN>

Example Tuxedo *DM_LOCAL_DOMAINS Configuration

*DM_LOCAL_DOMAINS

domain1      DOMAINID = "domain1"

      GWGRP = "GWGRP"

      CONNECTION_POLICY=ON_DEMAND

      DMTLOGDEV = "/nfs/home1/dkumar/lcsol5/tmp.100/DMTLOG"

      DMTLOGNAME = "DMTLG1"

      SECURITY=DM_PW

      BLOCKTIME=10

Configure the T_DM_REMOTE_TDOMAIN

Configure the T_DM_REMOTE_TDOMAIN to establish an inbound and outbound Access Control List (ACL) policy.

Perform the following steps to prepare the WebLogic Server environment:

Add an AclPolicy element to the T_DM_REMOTE_TDOMAIN section of the XML configuration file.
Example:
```
            <AclPolicy>GLOBAL</AclPolicy>
```
Add a CredentialPolicy element to the T_DM_REMOTE_TDOMAIN section of the XML configuration file.
Example:
```
            <CredentialPolicy>GLOBAL</CredentialPolicy>
```
If the CredentialPolicy is set to GLOBAL, you must have a copy of the Tuxedo tpusr file in your WebLogic Server environment. Use the following steps to configure the WebLogic Tuxedo Connector by adding a TpUserFile element to your XML configuration file:
1. Copy the tpusr file from TUXEDO to the WebLogic Server application environment or generate your own tpusr file.
2. Add a TpUserFile element to the T_DM_REMOTE_TDOMAIN section of the XML configuration file.
  Example:
```
            <TpUsrFile>pathname_filename_of_tpusr_file</TpUsrFile>
```

Note: For more information on how to create a Tuxedo tpusr file, see How to Enable User-Level Authentication.

Example T_DM_LOCAL_TDOMAIN Configuration

<T_DM_REMOTE_TDOMAIN AccessPoint="Your Tuxedo domain">

          <LocalAccessPoint>wldom1</LocalAccessPoint>

          <AccessPointId>domain1</AccessPointId>

          <Type>TDOMAIN</Type>

          <AclPolicy>LOCAL</AclPolicy>

          <ConnPrincipalName>domain1</ConnPrincipalName>

          <CredentialPolicy>LOCAL</CredentialPolicy>

            
          <TpUsrFile>C:\runs\tmp.100\config\wldom1\tpusr</TpUsrFile>

          <NWAddr>//lcsol5:3500</NWAddr>

</T_DM_REMOTE_TDOMAIN>

Example Tuxedo *DM_LOCAL_DOMAINS Configuration

*DM_REMOTE_DOMAINS

          wldom1 DOMAINID = "wldom1"

          ACCESSPOINTID="wldom1"

          ACL_POLICY="LOCAL"

          CREDENTIAL_POLICY="LOCAL"

Example ACL Policy for Simpapp and Simpserv Examples

This section provides an example of how to set up ACL control using the simpapp and simpserv examples.

Only John and Bob have access to Toupper.
Only Dan and John to access Tolower.
Toupper is used for accessing remote the Tuxedo service TOUPPER.
Tolower provides the actual service for remote Tuxedo user.

Use the following steps to establish ACL control:

Add user John, Bob, and Dan to WebLogic Security using the WebLogic Server Console.

Modify the ejb-jar.xml to add the security-role and method_permission elements for the Tuxedo TOUPPER service. The bolded statements indicate the changes added to support the security implementation.

Listing 3-1 TOUPPER ejb-jar.xml Security Example Code

<?xml version="1.0"?>
<!--
Copyright (c) 2000 BEA Systems, Inc. All rights reserved

THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF BEA Systems, Inc. The copyright 
notice above does not evidence any actual or intended publication of such source 
code.

-->

<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 
2.0//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd'>

<ejb-jar>
          <enterprise-beans>
                    <session>
                              <ejb-name>Toupper</ejb-name>
          <home>weblogic.wtc.examples.simpapp.ToupperHome</home>
          <remote>weblogic.wtc.examples.simpapp.Toupper</remote>                                                  
          <ejb-class>weblogic.wtc.examples.simpapp.ToupperBean</ejb-class>
                              <session-type>Stateful</session-type>
                              <transaction-type>Container</transaction-type>
                    </session>
          </enterprise-beans>
          <assembly-descriptor>
                    <security-role>
                              <role-name>dom2</role-name>
                    </security-role>
                    <method-permission>
                              <role-name>dom2</role-name>
                              <method>
                                          <ejb-name>Toupper</ejb-name>
                                          <method-name>Toupper</method-name>
                              </method>
                    </method-permission>
                    <container-transaction>
                              <method>
                                        <ejb-name>Toupper</ejb-name>
                                        <method-intf>Remote</method-intf>
                                        <method-name>*</method-name>
                              </method>
                              <trans-attribute>Supports</trans-attribute>
                      </container-transaction>
          </assembly-descriptor>
</ejb-jar>

Modify the Weblogic-ejb-jar.xml to add the security-role-assignment element for the Tuxedo TOUPPER service. The bolded statements indicate the changes added to support the security implementation.

Listing 3-2 TOUPPER Weblogic-ejb-jar.xml Security Example Code

<?xml version="1.0"?>
<!--

Copyright (c) 2000 BEA Systems, Inc. All rights reserved

THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF BEA Systems, Inc. The copyright 
notice above does not evidence any actual or intended publication of such source 
code.

-->

<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 6.0.0 
EJB//EN' 'http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd'>

<weblogic-ejb-jar>
          <weblogic-enterprise-bean>
                    <ejb-name>Toupper</ejb-name>
                    <stateful-session-descriptor>
                              <stateful-session-cache>
                    <max-beans-in-cache>100</max-beans-in-cache>
                              </stateful-session-cache>
                    </stateful-session-descriptor>
                    <jndi-name>tuxedo.services.ToupperHome</jndi-name>
          </weblogic-enterprise-bean>
          <security-role-assignment>
                    <role-name>dom2</role-name>
                    <principal-name>john</principal-name>
                    <principal-name>bob</principal-name>
          </security-role-assignment>
</weblogic-ejb-jar>

Modify the ejb-jar.xml to add the security-role and method-permission elements for the Tolower service. The bolded statements indicate the changes added to support the security implementation.

Listing 3-3 Tolower ejb-jar.xml Security Example Code

<?xml version="1.0"?>
<!--

Copyright (c) 2000 BEA Systems, Inc. All rights reserved 
THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF BEA Systems, Inc. The copyright 
notice above does not evidence any actual or intended publication of such source 
code.

-->
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 
2.0//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd'>

<ejb-jar>
          <enterprise-beans>
                    <session>
                              <ejb-name>Tolower</ejb-name>
                        <home>weblogic.wtc.jatmi.TuxedoServiceHome</home>
                          <remote>weblogic.wtc.jatmi.TuxedoService</remote>                                        
                        <ejb-class>weblogic.wtc.examples.simpserv.TolowerBean</ejb-class>
                        <session-type>Stateless</session-type>
                        <transaction-type>Container</transaction-type>
                    </session>
          </enterprise-beans>

          <assembly-descriptor>
                    <security-role>
                              <role-name>rdom2</role-name>
                    </security-role>
                    <method-permission>
                              <role-name>rdom2</role-name>
                              <method>
                                        <ejb-name>Tolower</ejb-name>
                                        <method-name>service</method-name>
                              </method>
                    </method-permission>
                    <container-transaction>
                              <method> 
                                        <ejb-name>Tolower</ejb-name>
                                        <method-intf>Remote</method-intf>
                                        <method-name>*</method-name>
                              </method>
                              <trans-attribute>Supports</trans-attribute>
                    </container-transaction>
          </assembly-descriptor>
</ejb-jar>

Modify the Weblogic-ejb-jar.xml to add the security-role-assignment element for the Tolower service.The bolded statements indicate the changes added to support the security implementation.

Listing 3-4 Tolower Weblogic-ejb-jar.xml Security Example Code

<?xml version="1.0"?>
<!--

Copyright (c) 2000 BEA Systems, Inc. All rights reserved

THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF BEA Systems, Inc. The copyright 
notice above does not evidence any actual or intended publication of such source 
code.

-->

<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 6.0.0 
EJB//EN' 'http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd'>

<weblogic-ejb-jar>
          <weblogic-enterprise-bean>
                    <ejb-name>Tolower</ejb-name>
          <stateless-session-descriptor>
                    <pool>
                              <max-beans-in-free-pool>100</max-beans-in-free-pool>
                    </pool>
          </stateless-session-descriptor>
          <jndi-name>tuxedo.services.TOLOWERHome</jndi-name>
          </weblogic-enterprise-bean>
          <security-role-assignment>
                    <role-name>rdom2</role-name>
                    <principal-name>john</principal-name>
                    <principal-name>dan</principal-name>
          </security-role-assignment>
</weblogic-ejb-jar>

Perform the following steps to prepare the Tuxedo environment for outbound requests:

If needed, add the group using tpgrpadd.
If needed, add John, Bob, and Dan as users using tpusradd.
Add TOUPPER service to be protected by TUXEDO ACL using tpacladd.
Set the BDMCONFIG for the remote domain (the WebLogic Server domain) with the ACL_POLICY="GLOBAL".

Perform the following steps to prepare the Tuxedo environment for inbound requests:

If needed, add the group using tpgrpadd.
If needed, add John, Bob, and Dan as users using tpusradd.
Add TOUPPER service to be protected by TUXEDO ACL using tpacladd.
Set the BDMCONFIG for the remote domain (the WebLogic Server domain) with the ACL_POLICY="GLOBAL". If ACL_POLICY="LOCAL", you must configure the remote DOMAINID as a user using tpusradd.

Perform the following steps to prepare the WebLogic Server environment:

Copy the tpusr file from TUXEDO or generate your own tpusr file.
Add a TpUserFile element to the T_DM_REMOTE_TDOMAIN section of the XML configuration file.
Example:
```
            <TpUsrFile>full path name to tpusr</TpUsrFile>.
```
Add a CredentialPolicy element to the T_DM_REMOTE_TDOMAIN section of the XML configuration file. Set the value to GLOBAL.
Example:
```
            <CredentialPolicy>GLOBAL</CredentialPolicy>
```

Link-Level Encryption

You can use encryption across domains to ensure data privacy. In this way, a network-based eavesdropper cannot learn the content of messages or application-generated messages flowing from one domain gateway to another. You configure this security mechanism by setting the MINENCRYPTBITS and MAXENCRYPTBITS parameters of the T_DM_LOCAL_TDOMAIN and the T_DM_REMOTE_TDOMAIN sections of your XML configuration file.

Note: Encryption requires appropriate licensing. For more information on license requirements, see Licensing.