|
•
|
Oracle Tuxedo TDomain gateway (implemented by the GWTDOMAIN server process)—provides interoperability between two or more Oracle Tuxedo domains through a specially designed TP protocol that flows over network protocol TCP/IP. Working with the WebLogic Tuxedo Connector (WTC) gateway, an Oracle WebLogic Server component, the Oracle Tuxedo TDomain gateway can also provide interoperability between Tuxedo domains and WebLogic Server applications.
|
|
•
|
Oracle TMA TCP gateway (implemented by the GWIDOMAIN server process) provides interoperability between Oracle Tuxedo domains and applications running under IBM OS/390 Customer Information Control System (CICS) and Information Management System (IMS) over network protocol TCP/IP. The gateway supports only non-transactional tasks.
|
|
•
|
Oracle TMA SNA gateway (implemented by the GWSNAX server process)—provides interoperability between Oracle Tuxedo domains and applications running on any System Network Architecture (SNA) Advanced Program-to-Program Communications (APPC) or Common Programming Interface for Communications (CPI-C) supported platform, including IBM OS/400, OS/390 CICS and IMS systems and VSE/CICS. The gateway supports communication with multiple SNA networks.
|
|
•
|
Oracle TMA OSI TP gateway (implemented by the GWOSITP server process)—provides interoperability between Oracle Tuxedo domains and other transaction processing applications that use the Open Systems Interconnection (OSI) transaction processing (TP) standard. OSI TP is a protocol for distributed transaction processing defined by the International Standards Organization (ISO). The gateway supports global transactions and various non-transactional tasks.
|
Figure 1‑2 shows an example Domains configuration involving four domains, three of which are Oracle Tuxedo domains.
|
•
|
Multinetwork support—gateways can communicate with other domains via a variety of network protocols, such as TCP/IP, IPX/SPX, OSI, and others. However, a gateway is limited by the capabilities of the networking library to which it is linked. In other words, a gateway typically supports a single type of network protocol. As an example, the Oracle Tuxedo TDomain gateway supports only TCP/IP.
|
|
•
|
Bypass-Domain model—ATMI applications that across multiple domains can communicate with each other through RDMA directly without using GWTDOMAIN.
|
|
•
|
Transaction management—gateways enable ATMI applications to interoperate with other domains within a transaction. The gateway coordinates the commitment or rollback of transactions running across domains.
|
|
•
|
Multiple messaging models—gateways support the following ATMI messaging models, without any need to change existing Oracle Tuxedo applications:
|
|
•
|
Request/response model—ATMI applications using the Oracle Tuxedo system can request services from applications running in other domains.
|
|
•
|
Conversational model—ATMI applications can establish conversations with programs running in other domains.
|
|
•
|
Queuing model—ATMI applications using the Oracle Tuxedo system can store data on queues in other domains.
|
|
•
|
Typed buffer support—gateways can perform encoding and decoding operations for all the types of buffers defined by Oracle Tuxedo ATMI applications.
|
|
•
|
tpinit(3c)/ tpterm(3c)—Oracle Tuxedo applications do not attach to the environment of a remote domain; they use domain gateways to access a remote domain. Therefore, an extra tpinit()/ tpterm() sequence is not needed for remote applications.
|
|
•
|
tpadvertise(3c) and tpunadvertise(3c)—Domains does not support these functions because domain gateways do not support dynamic service advertisements across domains.
|
|
•
|
tpnotify(3c) and tpbroadcast(3c)—Domains does not support the unsolicited communication paradigm provided by these functions.
|
|
•
|
Event posting (tppost(3c)) and notification of events ( tpsubscribe(3c))—Domains does not support these functions across domains.
|
Support for tpforward(3c) is provided to preserve application portability. Forwarded requests are interpreted by domain gateways as simple service requests. This process is shown in
Figure 1‑3, which illustrates the simple scenario of a service using
tpforward to send a request to a remote service.
Oracle Tuxedo applications use tpconnect(3c) to open a conversation with a remote service,
tpsend(3c) and
tprecv(3c) to communicate with this service, and
tpdiscon(3c) to end the conversation. Domain gateways maintain the conversation with the remote service, and support the same semantics for returns (that is,
tpreturn with
TPSUCCESS or
TPFAIL) and disconnects that are defined for Oracle Tuxedo conversational services.
The Oracle Tuxedo system enables messages to be queued to persistent storage (disk) or to non-persistent storage (memory) for later processing or retrieval. ATMI provides primitives that allow messages to be added (that is, tpenqueue) or read (that is,
tpdequeue) from queues. Reply messages and error messages can be queued for later return to clients. An administrative command interpreter (that is,
qmadmin) is provided for creating, listing, and modifying queues. Servers are provided to accept requests to enqueue and dequeue messages (that is,
TMQUEUE server), to forward messages from the queue for processing (that is,
TMQFORWARD server), and to manage the transactions that involve queues (that is,
TMS_QM server).
Figure 1‑4 illustrates how one Oracle Tuxedo domain communicates with another domain via a domain gateway.
Figure 1‑5 shows the Oracle Tuxedo Domains administrative servers used to administer a Domains configuration.
A domain gateway group, as shown in the previous figure, consists of a
gateway administrative server (
GWADM), a domain gateway server (for example,
GWTDOMAIN), and (optional) a Domains transaction log (
TLOG). The
GWADM server enables run-time administration of the domain gateway. An Oracle Tuxedo domain can communicate with one or more remote domains through a domain gateway group.
The GWADM(5) server registers with the
DMADM server to obtain the configuration information used by the corresponding gateway group.
GWADM accepts requests from the
DMADMIN service, which is a generic administrative service advertised by the
DMADM server, for run-time statistics or changes in the run-time options of the specified gateway group. Periodically,
GWADM sends an “I-am-alive” message to the
DMADM server. If no reply is received from
DMADM,
GWADM registers again. This process ensures the
GWADM server always has the current information about the Domains configuration for its gateway group.
the DMADM(5) server provides a registration service for gateway groups. This service is requested by
GWADM servers as part of their initialization procedure. The registration service downloads the configuration information required by the requesting gateway group. The
DMADM server maintains a list of registered gateway groups, and propagates to these groups any changes made to the Domains configuration file (
BDMCONFIG).
|
•
|
dmloadcf(1)—reads the DMCONFIG file, checks the syntax, and loads the binary BDMCONFIG configuration file.
|
|
•
|
dmunloadcf(1)—translates the BDMCONFIG configuration file from binary to text format.
|
|
•
|
dmadmin(1)—allows an Oracle Tuxedo administrator to update the BDMCONFIG file when the Tuxedo domain is running.
|
Figure 1‑6 shows the relationships between the Domains administrative tools and the Domains text and binary configuration files. Administration using the
dmadmin utility is through the
DMADMIN service, which is advertised by the
DMADM server.
The dmloadcf(1) command parses the
DMCONFIG file and loads the information into
BDMCONFIG. The command uses the environment variable
BDMCONFIG to point to the device or system filename in which the configuration should be stored.
The dmloadcf command, through the
-c option, also provides an estimate of the interprocess communications (IPC) resources needed for each local domain specified in the configuration.
The dmloadcf command checks the
DMTYPE file (
%TUXDIR%\udataobj\DMTYPE for Windows or
$TUXDIR/udataobj/DMTYPE for UNIX) to verify that the domain gateway types specified in the Domains configuration file are valid. Each type of domain gateway has a domain type designator
(TDOMAIN, SNAX, OSITP, OSITPX), which is used as a tag in the
DMTYPE file. Each line in this file has the following format:
The dmunloadcf(1) command converts the
BDMCONFIG configuration file from binary to text format and prints the output to standard output. For more information about
dmunloadcf, see reference page
dmunloadcf(1) in
Oracle Tuxedo Command Reference.
The dmadmin(1) command allows an Oracle Tuxedo administrator to configure, monitor, and tune domain gateways when the Tuxedo domain is running. It acts as an administrative command interpreter that translates administrative commands and sends requests to the
DMADMIN service, a generic administrative service advertised by the
DMADM server.
DMADMIN invokes functions that validate, retrieve, or update information in the
BDMCONFIG file.
You invoke dmadmin with the
-c option to dynamically update the
BDMCONFIG file. Depending on the configuration being changed, some updates will take place immediately, while others will take place only for new occurrences of whatever is affected by the update.
|
Note:
|
The master machine for an Oracle Tuxedo domain contains the domain’s UBBCONFIG file, and is designated as the master machine in the RESOURCES section of the UBBCONFIG file. Starting, stopping, and administering a Tuxedo domain is done through the master machine.
|
The BDMCONFIG file is a binary version of the
DMCONFIG file. It is created by running the
dmloadcf command, which parses
DMCONFIG and loads the binary
BDMCONFIG file to the location referenced by the
BDMCONFIG environment variable. As with
DMCONFIG, the
BDMCONFIG file may be given any name; the actual name is the device or system filename specified in the
BDMCONFIG environment variable. The
BDMCONFIG environment variable must be set to an absolute pathname ending with the device or system filename where
BDMCONFIG is to be loaded.
Unlike the TUXCONFIG file, which is the binary version of
UBBCONFIG, the
BDMCONFIG file is
not propagated to any other machine in a Tuxedo domain when the Tuxedo application is booted. For the
BDMCONFIG file to reside on any other machine in a Tuxedo domain, the administrator for that domain must manually place it there.
The DMCONFIG file is made up of specification sections. Lines beginning with an asterisk (*) indicate the beginning of a specification section. Each such line contains the name of the section immediately following the *. The asterisk is required when specifying a section name.
|
•
|
DM_LOCAL (also known as DM_LOCAL_DOMAINS)
|
|
•
|
DM_domtype, where domtype is TDOMAIN, OSITP, OSITPX, or SNACRM + SNALINKS + SNASTACKS
|
|
Note:
|
The DM_LOCAL section must precede the DM_REMOTE section.
|
Figure 1‑7 is a simple example of what you are trying to accomplish.
In the example, you must also create a DMCONFIG file for Domain Y that complements the
DMCONFIG file created for Domain X. That is, a local domain access point in the Domain X
DMCONFIG file would be a remote domain access point in the Domain Y
DMCONFIG file, and a remote domain access point in the Domain X
DMCONFIG file would be a local domain access point in the Domain Y
DMCONFIG file. The example demonstrates the use of the TDomain gateway server.
Table 1‑1 provides a description of each section in the
DMCONFIG file.
|
|
|
DM_LOCAL (also known as DM_LOCAL_DOMAINS)
|
Defines one or more local domain access point identifiers (also known as local domains, or LDOMs). For each local domain access point (logical name) that you define, you specify a domain gateway group ( TDOMAIN, ...) for the access point in this section, and you specify in the DM_EXPORT section the local services available through the access point. The local services available through the local domain access point will be available to clients in one or more remote domains.
You can define multiple local domain access points in this section, one for each gateway group (TDOMAIN, SNAX, OSITP, OSITPX) used by this Oracle Tuxedo domain to communicate with a remote domain.
One and only one local domain access point is allowed per gateway group. A domain gateway group consists of a GWADM server process and a domain gateway server process (for example, GWTDOMAIN, the TDomain gateway server).
|
DM_REMOTE (also known as DM_REMOTE_DOMAINS)
|
Defines one or more remote domain access point identifiers (also known as remote domains, or RDOMs). For each remote domain access point (logical name) that you define, you specify a domain gateway group ( TDOMAIN, ...) for the access point in this section, and you specify in the DM_IMPORT section the remote services available through the access point. The remote services available through the remote domain access point will be available to clients in the local domain.
*DM_REMOTE
REMOT1 TYPE=TDOMAIN
ACCESSPOINTID=“ BA.BANK01”
REMOT2 TYPE=TDOMAIN
ACCESSPOINTID=“ BA.BANK02”
|
DM_EXPORT (also known as DM_LOCAL_SERVICES)
|
Specifies the local services exported to one or more remote domains through a local domain access point defined in the DM_LOCAL section. Only the services specified for a local domain access point are available to clients on one or more remote domains, meaning that specifying services in this section is a way to restrict remote client access to local services. If the DM_EXPORT section is absent, or is present but empty, all services advertised by the local domain are available to the remote domains.
A local service made available to remote domains inherits many of its properties from the SERVICES section of the local UBBCONFIG file. Some of the properties that may be inherited are LOAD, PRIO, AUTOTRAN, ROUTING, BUFTYPE, and TRANTIME.
|
DM_IMPORT (also known as DM_REMOTE_SERVICES)
|
Specifies the remote services imported through one or more remote domain access points defined in the DM_REMOTE section and made available to the local domain through one or more local domain access points. If the DM_IMPORT section is absent, or is present but empty, no remote services are available to the local domain.
A remote Oracle Tuxedo service made available to the local domain inherits many of its properties from the SERVICES section of the remote UBBCONFIG file. Some of the properties that may be inherited are LOAD, PRIO, AUTOTRAN, ROUTING, BUFTYPE, and TRANTIME.
|
Note:
|
You may substitute RDOM for the RACCESSPOINT parameter, and LDOM for the LACCESSPOINT parameter.
|
|
|
|
Specifies global Domains configuration information, specifically a user-supplied configuration version string. The only parameter in this section is VERSION=string, where string is a field in which users can enter a version number for the current DMCONFIG file. This field is not checked by the software.
|
|
|
|
|
|
Specifies one or more access control list (ACL) names and associates one or more remote domain access points with each specified ACL name. You can use the ACL parameter in the DM_EXPORT section by setting ACL=ACL_NAME 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.
|
|
|
|
|
|
Defines the parameters required for a particular Domains configuration. Currently, the value of domtype can be TDOMAIN, OSITP, OSITPX, or SNACRM + SNALINKS + SNASTACKS. Each domain type must be specified in a separate section.
In a DM_TDOMAIN section, you define the TDomain-specific network configuration for a local or remote domain access point. You can also define the network configuration for one or more remote domain access points associated with one or more WebLogic Server applications, to combine Tuxedo ATMI servers and WebLogic Server Enterprise JavaBean (EJB) servers in an application; for details, see Oracle Tuxedo Interoperability.
The DM_TDOMAIN section should have an entry per local domain access point if requests from remote domains to local services are accepted through that access point. For each local domain access point specified in this section, you must specify the network address to be used for listening for incoming connections.
The DM_TDOMAIN section should have an entry per remote domain access point if requests from the local domain to remote services are accepted through that access point. For each remote domain access point specified in this section, you must specify the destination network address to be used when connecting to that remote domain access point.
Beginning with Tuxedo release 9.0, the DM_TDOMAIN section can have an entry per TDomain session between specific local and remote domain access points. For each TDomain session specified in this section, you must specify the destination network address to use when connecting to that TDomain session.
|
For a detailed description of the DMCONFIG file, see reference pages
DMCONFIG(5)and
DM_MIB(5)in
Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference.
For Oracle Tuxedo release 7.1 or later, the dmunloadcf command generates by default a
DMCONFIG file that uses the improved domains terminology. Use the
-c option to print a
DMCONFIG file that uses the previous domains terminology. For example:
prompt> dmunloadcf -c > dmconfig_prev
In the following example, the remote service TOUPPER is available through two different remote domain access points named
REMOT1 and
REMOT2, and the data-dependent routing criteria for
TOUPPER is defined in the routing criteria table named
ACCOUNT. In the example,
RTOUPPER1 and
RTOUPPER2 are alias service names for
TOUPPER, which is the actual service name expected by the remote domains.
For the ACCOUNT routing table,
VIEW and
account are the type and subtype of data buffers for which this routing table is valid, and
branchid is the name of the field in the VIEW data buffer to which routing is applied. The allowed values for the
branchid field are as follows:
|
•
|
For the REMOT1 access point, the allowed values range from the minimum value allowed on the machine associated with REMOT1 to less than or equal to 1000.
|
|
•
|
For the REMOT2 access point, the allowed values range from the 1001 to less than or equal to 3000.
|
If the value of the branchid field for a
TOUPPER service request is within the range
MIN-1000, the service request is routed through the
REMOT1 access point. If the value of the
branchid field for a
TOUPPER service request is within the range
1001-3000, the service request is routed through the
REMOT2 access point.
The Oracle Tuxedo system provides two timeout mechanisms: a transaction timeout mechanism and a
blocking timeout mechanism. The transaction timeout is used to define the duration of an ATMI transaction, which may involve several service requests. The timeout value is defined when the transaction is started. The blocking timeout is used to define the duration of individual service requests, that is, how long the ATMI application is willing to wait for a reply to a service request.
If a process is not in transaction mode, the Oracle Tuxedo system performs blocking timeouts. If a process is in transaction mode, the Oracle Tuxedo system performs transaction timeouts but not blocking timeouts. The latter statement is true for
intradomain transactions (that is, transactions handled within a single Oracle Tuxedo domain) but is not true for
interdomain transactions. For
interdomain transactions, if a process is in transaction mode, the Domains software performs both transaction timeouts and blocking timeouts.
|
•
|
AUTOTRAN—When AUTOTRAN is turned on for a service and a service request is received for the service that is not already within a transaction, the local Oracle Tuxedo system automatically starts a transaction for the service.
|
|
•
|
TRANTIME—Transaction timeout value in seconds for transactions automatically started for the service. If this timeout value is exceeded for a transaction, the Oracle Tuxedo nodes (machines) infected with the transaction generate a TMS timeout message.
|
A service advertised on a machine running Oracle Tuxedo release 8.1 or later inherits an additional transaction-timeout property named MAXTRANTIME from the
RESOURCES section of the
UBBCONFIG file. If the
MAXTRANTIME timeout value is less than the
TRANTIME timeout value or the timeout value passed in a
tpbegin(3c) call to start a transaction, the timeout for a transaction is reduced to the
MAXTRANTIME value.
MAXTRANTIME has no effect on a transaction started on a machine running Oracle Tuxedo 8.0 or earlier, except that when a machine running Oracle Tuxedo 8.1 or later is infected by the transaction, the transaction timeout value is capped—reduced if necessary—to the
MAXTRANTIME value configured for that node.
|
•
|
If an interdomain transaction infects a node that does not understand the MAXTRANTIME parameter, or the node understands the MAXTRANTIME parameter but the parameter is not set, the timeout value for the transaction is determined by TRANTIME or by the timeout value passed in the tpbegin() call that started the transaction. If the TRANTIME or tpbegin() timeout value is exceeded, all Oracle Tuxedo nodes infected with the transaction—including the node that started the transaction—generate a TMS timeout message.
|
If the TRANTIME or
tpbegin() timeout value is less than or equal to
MAXTRANTIME, the transaction-handling scenario becomes the one previously described.
If the TRANTIME or
tpbegin() timeout value is greater than
MAXTRANTIME, the infected node reduces the timeout value for the transaction to
MAXTRANTIME. If the
MAXTRANTIME timeout value is exceeded, the infected node generates a TMS timeout message.
For more information about MAXTRANTIME, see
MAXTRANTIME in the
RESOURCES section in
UBBCONFIG(5) or
TA_MAXTRANTIME in the
T_DOMAIN class in
TM_MIB(5).
In the DM_LOCAL section of the
DMCONFIG file, you can set the blocking timeout for a local domain access point using the
BLOCKTIME parameter. For example:
The BLOCKTIME parameter specifies the maximum wait time a blocking ATMI call will block before timing out. A blocking timeout condition implies that the affected service request has failed.
If BLOCKTIME is not specified in the
DMCONFIG file, the default is set to the value of the
BLOCKTIME parameter specified in the
RESOURCES section of the
UBBCONFIG file. If the
BLOCKTIME parameter is not specified in the
UBBCONFIG file, the default is set so that (
SCANUNIT * BLOCKTIME) is approximately 60 seconds.
Be aware that interdomain transactions generate blocking timeout conditions when transaction duration exceeds
BLOCKTIME. That is, for an interdomain transaction, if the
BLOCKTIME value is less than (a) the
TRANTIME timeout value specified in the
SERVICES section of the
UBBCONFIG file or (b) the timeout value passed in the
tpbegin() call to start the transaction, the timeout for the transaction is reduced to the
BLOCKTIME value. In contrast, for
intradomain transactions (that is, transactions handled within a single Oracle Tuxedo domain), the
BLOCKTIME value specified in the
RESOURCES section of the
TUXCONFIG file has
no effect on the timeout of an intradomain transaction.
|
•
|
ON_DEMAND (default)—Connect when requested by either (1) a client request to a remote service or (2) an administrative “connect” command. Under this connection policy, a connection can be established in any of the following ways:
|
|
•
|
ON_STARTUP—Connect at gateway server initialization (boot) time. Under this connection policy, a connection can be established in any of the following ways:
|
|
•
|
INCOMING_ONLY—Accept incoming connections but do not initiate a connection automatically. Under this connection policy, a connection can be established in any of the following ways:
|
In the DM_LOCAL section of the
DMCONFIG file, you set the connection policy for a local domain access point using the
CONNECTION_POLICY parameter. For example:
LOCAL1 to
REMOT1 —
ON_DEMAND
LOCAL1 to
REMOT2 —
ON_STARTUP
Specifying LOCAL or no connection policy for a remote domain access point defaults to the global connection policy.
Without the remote-domain connection policy capability, a global connection policy of ON_STARTUP means that the local TDomain gateway will try to connect to
all remote domains at boot time, even if some of the remote domains will not be used initially. With a large number of remote domains, the boot time could be substantial. With the remote-domain connection policy capability, you can select which remote domain connections
not to automatically establish at boot time for a global connection policy of
ON_STARTUP.
|
•
|
Specify the connection_policy parameter attributes you want to use. If you do not specify a connection policy for a TDomain session, the connection policy attribute for that session point defaults to LOCAL.
|
|
•
|
FAILOVERSEQ: Specifies a TDomain session failover sequence and primary record.
|
|
•
|
LACCESSPOINT (also known as LDOM): Specifies the name of a local domain access point listed in the DM_LOCAL section.
|
The FAILOVERSEQ,
LACCESSPOINT and
CONNECTION_POLICY parameters are used to establish a per TDomain session policy and are specified in
Listing 1‑1:
The DM_TDOMAIN section consists of seven records that include three TDomain sessions.
|
•
|
Record 4 is the primary record for TDomain session LOCAL1,REMOT1 since its FAILOVERSEQ number is smaller than record 7. The connection policy for this TDomain session is ON_STARTUP, and it requires 128 bits Link-Level Encryption security policy. If connection to this record fails, then a connection attempt is made to its secondary/backup record, which is record 7.
|
|
•
|
Record 6 is the primary record for TDomain session LOCAL2,REMOT2. The connection policy for this session is ON_DEMAND. There is no secondary/backup failover record for this session. Local access point LOCAL2 connects with two TDomain sessions: one with REMOT1 in record 5, and another with REMOT2.
|
|
•
|
Use dmloadcf -y to compile and convert DMCONFIG file into BDMCONFIG file.
|
|
•
|
Use tmboot -y to boot the server
|
To make the DMCONFIG file smaller and easier to work with,
LACCESSPOINT can contain regular expressions to describe multiple local domain access points.
|
Note:
|
DM_TDOMAIN is the only section in the DMCONFIG file that allows LACCESSPOINT to contain regular expressions.
|
When the DMCONFIG file is compiled, regular expressions are expanded to their full local domain names in the output binary
BDMCONFIG file. The size of the
BDMCONFIG file is increased accordingly as shown in
Listing 1‑2:
Using DM_MIB to specify and request TDomain session information directly modifies the
BDMCONFIG file. The original
DMCONFIG file is unmodified. For more information about
DM_MIB, see
DM_MIB(5) in
Section 5 - File Formats, Data Descriptions, MIBs, and System Processes Reference.
DM_MIB uses three T_DM_TDOMAIN Class Definition attributes to create a per TDomain session connection policy in the
BDMCONFIG file:
|
•
|
TA_DMFAILOVERSEQ: Specifies and requests the session connection failover sequences and primary records for a TDomain session record in the BDMCONFIG file.
|
|
•
|
TA_DMLACCESSPOINT: Specifies and requests a local domain access point found in the DM_LOCAL section for a TDomain session record in the BDMCONFIG file.
|
You can use DM_MIB to add, delete, or retrieve TDomain session records in the
BDMCONFIG file. All applicable T_DM_TDOMAIN Class Definition key fields must be used to add, delete, or retrieve requests for TDomain session record information.
Example 1: DM_MIB request used to add a new TDomain session and connection policy record.
Example 2: DM_MIB request used to delete an existing TDomain session connection policy record.
Using DMADMIN to specify and request TDomain information works similarly to using
DM_MIB. That is to say, using
DMADMIN modifies the
BDMCONFIG file and leaves the original
DMCONFIG file unmodified.
DMADMIN uses three field indentifiers to add a per TDomain connection policy record in the
BDMCONFIG file:
|
•
|
TA_DMFAILOVERSEQ: Specifies and requests the session connection failover sequences and primary records for a TDomain session record in the BDMCONFIG file.
|
|
•
|
TA_LDOM: Specifies and requests a local domain access point found in the DM_LOCAL section for a TDomain session record in the BDMCONFIG file.
|
You can use DMADMIN to add, delete, or retrieve TDomain session records. The following example illustrates how
DMADMIN is used to add a TDomain session connection policy record in the
BDMCONFIG file:
When CONNECTION_POLICY is set to
ON_STARTUP, you can configure two other parameters to determine how many times the local domain gateway attempts to establish a connection to the remote domains. By default, the local domain gateway retries failed connections every 60 seconds, but you can specify a different value for this interval using parameters
MAXRETRY and
RETRY_INTERVAL.
You use the MAXRETRY parameter to specify the number of times that a domain gateway tries to establish connections to remote domains. The minimum value is 0, and the maximum value is 2147483647. The default setting is 2147483647. Setting this parameter to 0 turns off connection retry processing.
You use the RETRY_INTERVAL parameter to specify the number of seconds between automatic attempts to establish a connection to remote domains. The minimum value is 0, and the maximum value is 2147483647. The default setting is 60. If the
MAXRETRY parameter is set to 0, setting
RETRY_INTERVAL is not allowed.
*DM_TDOMAIN
LOCAL1 NWADDR=“
//albany.acme.com:4051”
CONNECTION_POLICY=ON_STARTUP
MAXRETRY=5
RETRY_INTERVAL=100
REMOT1 NWADDR=“
//newyork.acme.com:65431”
CONNECTION_POLICY=ON_STARTUP
MAXRETRY=10
RETRY_INTERVAL=40
In the second example, the MAXRETRY and
RETRY_INTERVAL values 10 and 40 will be the automatic connection retry criteria used by the local TDomain gateway to establish a connection to the remote domain access point named
REMOT1.
|
•
|
For ON_DEMAND, the local domain gateway continually advertises services imported from a remote domain.
|
|
•
|
For ON_STARTUP, the local domain gateway advertises services imported from a remote domain as long as a connection exists to the remote domain.
|
|
•
|
For INCOMING_ONLY, the local domain gateway advertises services imported from a remote domain when the gateway receives an incoming connection or when a dmadmin connect command is issued.
|
When the connection policy is ON_STARTUP or
INCOMING_ONLY (but not
ON_DEMAND),
Dynamic Status, a TDomain gateway feature, checks the status of remote services. The status of a remote service depends on the status of the network connection between the local and remote domain gateways. Remote services are advertised and available on the local domain whenever a connection is successfully established to the domain on which they reside. Remote services are suspended and unavailable whenever the connection is not established to the domain on which they reside.
When connections to both REMOT1 and
REMOT2 are up, the domain gateway load balances requests for the
RSVC service. If the connection to
REMOT1 goes down, the gateway sends all requests for
RSVC to
REMOT2. If both connections go down, the gateway suspends
RSVC in the bulletin board. Subsequent requests for
RSVC are either routed to a local service or fail with
TPENOENT.
|
•
|
Optional parameters for the DM_TDOMAIN section in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference
|
|
•
|
T_DM_TDOMAIN Class Definition in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference
|
In the DM_IMPORT section of the
DMCONFIG file, you can set up the Domains-level failover and failback functionality for your Domains configuration. In the
DM_TDOMAIN section of the
DMCONFIG file, you can set up the Domains link-level failover functionality for your Domains configuration.
In this example, the TOUPPER service can be executed through any of three remote domain access points:
REMOT1 (primary),
REMOT2, and
REMOT3. When
REMOT1 is unavailable,
REMOT2 is used for failover. When
REMOT1 and
REMOT2 are both unavailable,
REMOT3 is used for failover.
You must specify ON_STARTUP or
INCOMING_ONLY as the value of the
CONNECTION_POLICY parameter if you want to configure alternate remote domains for a service. If you specify
ON_DEMAND as your connection policy, your servers cannot “fail over” to the alternate remote domains that you have specified in the
RACCESSPOINT parameter.
|
•
|
Manual dmadmin connect command
|
The first entry is considered to be the primary address, which means its NWADDR is the first network address tried when a connection is being attempted to the remote domain access point. The second entry is considered to be the secondary address, which means its
NWADDR is the second network address tried when a connection cannot be established using the primary address.
Table 1‑4 provides some key information about Domains keepalive.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* For TCP-level keepalive to quickly detect a TDomain gateway connection failure, it must be set to a small time interval. Doing so may flood the network with TCP packets.
|
|
•
|
LOCAL (relevant only to remote domain access points)
|
*DM_TDOMAIN
LOCAL1 NWADDR=“
//albany.acme.com:4051”
TCPKEEPALIVE=Y
REMOT1 NWADDR=“
//newyork.acme.com:65431”
REMOT2 NWADDR=“
//philly.acme.com:65431”
TCPKEEPALIVE=NO
LOCAL1 to
REMOT1 — TCP-level keepalive enabled
LOCAL1 to
REMOT2 — TCP-level keepalive disabled
Specifying LOCAL or no configuration for a remote domain access point defaults to the local TCP-level keepalive configuration.
You use the DMKEEPALIVE parameter to specify the maximum time that the local TDomain gateway will wait without receiving any traffic on the Domains connection; if the maximum time is exceeded, the gateway sends an application-level keepalive request message. The allowed values for
DMKEEPALIVE are:
|
•
|
1 <= value <= 2147483647 (keepalive enabled), in milliseconds, currently rounded up to the nearest second by the Domains software
|
The DMKEEPALIVE default setting is 0.
You use the DMKEEPALIVEWAIT parameter to specify the maximum time that the local TDomain gateway will wait without receiving an acknowledgement to a sent keepalive message. If the maximum time is exceeded, the gateway assumes that the connection to the remote TDomain gateway is broken and releases any resources associated with the connection. The minimum value for
DMKEEPALIVEWAIT is 0, and the maximum value is 2147483647 milliseconds, currently rounded up to the nearest second by the Domains software. The
DMKEEPALIVEWAIT default setting is 0.
|
•
|
If DMKEEPALIVE is 0 (keepalive disabled), setting DMKEEPALIVEWAIT has no effect.
|
|
•
|
If DMKEEPALIVE is enabled and DMKEEPALIVEWAIT is set to a value greater than DMKEEPALIVE, the local TDomain gateway will send more than one application-level keepalive message before the DMKEEPALIVEWAIT timer expires. This combination of settings is allowed.
|
|
•
|
If DMKEEPALIVE is enabled and DMKEEPALIVEWAIT is set to 0, receiving an acknowledgement to a sent keepalive message is unimportant: any such acknowledgement is ignored by the local TDomain gateway. The local TDomain gateway continues to send keepalive messages every time the DMKEEPALIVE timer times out. Use this combination of settings to keep an idle connection open through a firewall.
|
To clarify the use of DMKEEPALIVE and
DMKEEPALIVEWAIT, consider the following Domains application-level keepalive configuration:
*DM_TDOMAIN
LOCAL1 NWADDR=“
//albany.acme.com:4051”
DMKEEPALIVE=1010
DMKEEPALIVEWAIT=20
REMOT1 NWADDR=“
//newyork.acme.com:65431”
DMKEEPALIVE=4000
DMKEEPALIVEWAIT=3000
REMOT2 NWADDR=“
//philly.acme.com:65431”
DMKEEPALIVE=-1
LOCAL1 to
REMOT1 — Keepalive timer = 4 seconds, and wait timer = 3 seconds
LOCAL1 to
REMOT2 — Keepalive timer = 2 seconds, and wait timer = 1 second
|
•
|
1 <= value <= 2147483647 in milliseconds, currently rounded up to the nearest second by the Domains software
|
|
•
|
1 <= value <= 2147483647 in milliseconds, currently rounded up to the nearest second by the Domains software
|
|
1.
|
Edit the UBBCONFIG file with any text editor and configure the Domains administrative servers and the TDomain gateway server. For example:
|
|
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.
|
|
3.
|
Edit the DMCONFIG file with any text editor and configure the Domains environment for the TDomain gateway server. For example:
|
*DM_LOCAL
LOCAL1 GWGRP=GWTGROUP
TYPE=TDOMAIN
ACCESSPOINTID=“
BA.CENTRAL01”
BLOCKTIME=30
CONNECTION_POLICY=ON_STARTUP
MAXRETRY=5
RETRY_INTERVAL=100
*DM_TDOMAIN
LOCAL1 NWADDR=“
//albany.acme.com:4051”
REMOT1 NWADDR=“
//newyork.acme.com:65431”
REMOT2 NWADDR=“
//philly.acme.com:65431”
The DMCONFIG file must reside on the same machine as the
DMADM server.
|
5.
|
Start the Oracle Tuxedo application servers by running tmboot(1). The tmboot command executes all administrative processes and all servers listed in the SERVERS section of the TUXCONFIG file named by the TUXCONFIG and TUXOFFSET environment variables. It starts the servers in the order that they are listed in the SERVERS section: DMADM, then GWADM, and then GWTDOMAIN. The Domains servers must be started in this order. In addition, the Domains servers must be started before the application servers.
|
Listing 1‑4 and
Listing 1‑5 give you an idea of how to configure an Oracle Tuxedo application for Domains migration. The entries of particular importance to the Domains migration are highlighted in bold.
*RESOURCES
IPCKEY 76666
MASTER SITE1,SITE2
OPTIONS LAN,MIGRATE
MODEL MP
#
*MACHINES
mach1 LMID=SITE1
TUXDIR=“/home/rsmith/tuxroot”
APPDIR=“/home/rsmith/bankapp”
TUXCONFIG=“/home/rsmith/bankapp/tuxconfig”
mach2 LMID=SITE2
TUXDIR=“/home/rsmith/tuxroot”
APPDIR=“/home/rsmith/bankapp”
TUXCONFIG=“/home/rsmith/bankapp/tuxconfig”
mach3 LMID=SITE3
TUXDIR=“/home/rsmith/tuxroot”
APPDIR=“/home/rsmith/bankapp”
TUXCONFIG=“/home/rsmith/bankapp/tuxconfig”
#
*GROUPS
DMADMGRP LMID=“SITE1,SITE3” GRPNO=1
GWTGROUP LMID=“SITE2,
SITE3” GRPNO=2
.
.
.
*NETWORK
SITE1 NADDR=“//albany.acme.com:4065”
NLSADDR=“//albany.acme.com:4068”
SITE2 NADDR=“//auburn.acme.com:4065”
NLSADDR=“//auburn.acme.com:4068”
SITE3 NADDR=“//boston.acme.com:4065”
NLSADDR=“//boston.acme.com:4068”
#
*SERVERS
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
.
.
.
|
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_TDOMAIN
LOCAL1 NWADDR=“//albany.acme.com:4051”
LOCAL1 NWADDR=“//boston.acme.com:4051”
REMOT1 NWADDR=“//newyork.acme.com:65431”
REMOT2 NWADDR=“//philly.acme.com:65431”
In the sample configuration files, the DMADM server and the TDomain gateway group servers are configured to migrate to the
SITE3 machine. For the
DMADM migration, an administrator will activate a
DMADM server process on the
SITE3 machine after completing the following tasks:
|
•
|
Setting the BDMCONFIG environment variable on the SITE3 machine.
|
|
•
|
Running the dmloadcf(1) command to load the BDMCONFIG file on the SITE3 machine.
|
For the TDomain gateway group migration, an administrator will activate GWADM and
GWTDOMAIN server processes on the
SITE3 machine. At that point, the configurations and responsibilities associated with the
LOCAL1 access point will be handled by the new
GWTDOMAIN server process listening for incoming connection requests on network address
boston.acme.com:4051.
|
Note:
|
The DMADM and domain gateway group(s) do not have to be migrated to the same machine.
|
To migrate DMADM to a new machine, follow these steps.
|
1.
|
Copy DMCONFIG to the new machine and run dmloadcf.
|
|
1.
|
In the DMCONFIG file, add multiple listening addresses, in the following format, to the DM_TDOMAIN section:
|
|
3.
|
The DMCONFIG files for the remote domains should include both network addresses specified in step 1.
|
|
4.
|
Activate the GWADM and GWTDOMAIN server processes on the new machine. For details, see the following section.
|
|
•
|
Command tmboot(1) with the -s command line option
|
|
•
|
GWTDOMAIN no longer participates transaction as a TMS; however, local domain takes the responsibility of importing necessary TMS service to BB so that transactions can be performed, as well as exchanging necessary information between two domains.
|
|
•
|
GWTDOMAIN can work on either bypass domain model by default or non-bypass domain model by specifying THROUGHGATEWAY=Y in DMCONFIG.
|
|
•
|
GWTDOMAIN explores the abilities of remote domain and determines whether this feature is able to be employed. GWTDOMAIN may work on both bypass domain model and non-bypass model, according to the opposite domain's setting. However, for the same connection, namely a certain remote domain gateway, it can only be either bypass-domain or traditional.
|
|
•
|
Bypass-domain model does not support security level ACL or MANDATORY_ACL with different security tokens across domains. If ACL or MANDATORY_ACL is specified in UBBCONFIG and ACL_POLICY in DMCONFIG is set to LOCAL, the two domains of which ACL_POLICY is specified automatically switch off their bypass domain feature.
|
|
•
|
You cannot configure GWWS in UBBCONFIG when bypass domain is specified; otherwise, tmloadcf will report an error.
|
|
|
|
|
|
|
ON_DEMAND should not be specified when GWTDOMAIN runs on bypass domain model; otherwise, ON_DEMAND will be automatically treated as ON_STARTUP and GWTDOMAIN will output message " LIBGWT_CAT XXXX, ON_STARTUP is applied instead of ON_DEMAND on bypass domain model".
|
|
|
|
Note that every remote domain should be given a unique BYPASSDOM_SEQ_NUM. Only the services that locate on the connected domains are imported.
|
|
|
|
|
|
|
It works on the transmission of any data between GWTDOMAIN, either trigged by messaging or GWTDOMAIN's protocol; however, messaging of ATMI calls no longer uses the specified encryption method.
|
|
|
|
|
|
|
|
|
|
|
|
It works on the transmission of any data between GWTDOMAIN, either trigged by messaging or GWTDOMAIN's protocol; however, messaging of ATMI calls no longer uses the specified encryption method.
|
|
|
|
|
|
|
|
If ACL in DM_REMOTE section is configured as LOCAL, it only works on non-bypass domain model.
|
|
|
|
|
|
|
|
