|
|
 |
| e-docs > Tuxedo > Using the Tuxedo TOP END Domain Gateway with ATMI Applications > Interconnecting Systems with the TOP END Domain Gateway |
|
Using the Tuxedo TOP END Domain Gateway with ATMI Applications
|
Interconnecting Systems with the TOP END Domain Gateway
This topic includes the following sections:
Interoperability Scenarios Between the BEA TOP END and BEA Tuxedo Systems
As shown in the following figure, the TOP END Domain Gateway supports three scenarios for interoperability between the BEA TOP END and BEA Tuxedo systems:
Figure 2-1 Supported TEDG Interoperability Scenarios
See Also
How the TEDG Handles Connections and Message Passing
This topic includes the following sections:
Request/Response Message Passing
The TEDG supports the request/response mode of passing messages between BEA Tuxedo and BEA TOP END systems. The systems use the TEDG as an intermediary.
BEA Tuxedo Client to BEA TOP END Server
BEA Tuxedo clients view the TEDG as a local server. The TEDG advertises services based on the SERVICE entries in the DM_REMOTE_SERVICES section of the DMCONFIG file. Client programs make requests using tpcall(3c) as if they were addressing a local service. Asynchronous requests and responses are supported via the tpacall(3c) and tpgetrply(3c) functions, respectively.
The TEDG uses the service name to locate the SERVICE entry in the DM_REMOTE_SERVICES section to determine the corresponding BEA TOP END product, function, MSR target, and function qualifier. For FML32 buffers, data marshalling is performed, as required, before a message is sent.
BEA TOP END servers respond to client requests using tp_server_send(3T).
BEA TOP END Client to BEA Tuxedo Server
BEA TOP END clients request BEA Tuxedo services using tp_client_send(3T) or tp_client_signon(3T). BEA TOP END client calls are asynchronous. Responses are handled by the tp_client_receive(3T) call.
Message routing is based on three pieces of information advertised by the TEDG: the product, the function and, optionally, the MSR target. Normal BEA TOP END routing and load-balancing rules are used to determine the destination node. When a message is received by the TEDG, the product, function, optional MSR target, and function qualifier specified in the message are used to determine the corresponding BEA Tuxedo service as specified by the SERVICE entries in the DM_LOCAL_SERVICES section of the DMCONFIG file. The message is sent to the appropriate BEA Tuxedo service after any required data unmarshalling is performed.
See Also
Conversational Message Passing
The BEA Tuxedo and BEA TOP END systems support different styles of conversational message passing.
The TEDG provides a mapping of BEA TOP END pseudo-conversations to the BEA Tuxedo conversation model. This mapping allows:
Establishing Connections Between BEA Tuxedo and BEA TOP END Systems
BEA TOP END nodes advertise available services to adjacent nodes at connection time. New services are advertised dynamically. Services are unadvertised if they are no longer available. Thus, at any time a BEA TOP END node can determine the status of all services on nodes to which it is connected.
The BEA Tuxedo system takes a different approach. Within a multi-node BEA Tuxedo domain, the connection architecture is quite similar to that of a BEA TOP END system. However, interdomain connectivity is different.
The BEA Tuxedo system offers three possible connection policies that can be assigned to a TEDG:
By default, the connection to another domain is not made until a service request that requires such a connection is made (CONNECTION_POLICY=ON_DEMAND). This type of connection is called a lazy connection. The gateway, however, advertises remote services to the local domain before any connections are made. If a connection cannot be made, the gateway returns an error to the caller, but the relevant services remain advertised.
Optionally, a TEDG can be configured to connect, automatically, with other BEA TOP END systems at the start of each day (CONNECTION_POLICY=ON_STARTUP). If a connection is established, all associated services are assumed to be available and are advertised. If a connection cannot be established, or if a connection is established but subsequently fails, related services are suspended (CONNECTION_POLICY=INCOMING_ONLY and CONNECTION_POLICY=ON_STARTUP). Thus, remote services can be configured such that they are continually advertised (CONNECTION_POLICY=ON_DEMAND), or advertised only when a connection to the remote domain is open (CONNECTION_POLICY=ON_STARTUP and CONNECTION_POLICY=INCOMING_ONLY).
For local services, regardless of the connection policy, the TEDG advertises (exports) its local services to the BEA TOP END system when a connection is established with a BEA TOP END node. The TEDG determines which services to advertise using the rules in the DMCONFIG file for the local domain. The TEDG advertises each SERVICE entry in the DM_LOCAL_SERVICES section that is associated with the local domain. For each of these services the TEDG advertises the associated parameters (TE_PRODUCT, TE_FUNCTION, and TE_TARGET) to the BEA TOP END system. The status of individual service availability is not tracked by the BEA TOP END system; only the status of the network connection is tracked.
Connecting at Boot Time (ON_STARTUP)
The BEA Tuxedo ON_STARTUP policy most closely resembles the BEA TOP END connection policy. When this policy has been selected, the TEDG attempts to connect to each of its configured BEA TOP END nodes. If multiple network addresses are configured they are tried serially. Connection retries apply if configured. If a connection attempt succeeds, the TEDG advertises the associated remote services to the local domain. If a connection attempt fails (or is lost), the associated imported services are suspended until the connection is reestablished. The status of individual service availability on the BEA TOP END node is not tracked.
Connecting When a Client Program Requests a Remote Service (ON_DEMAND)
The ON_DEMAND or "lazy connection" policy is the default connection policy on the BEA Tuxedo system. Connections are attempted as needed to fulfill client requests for remote services. If multiple network addresses are configured they are tried serially. Connection retries do not apply. The TEDG advertises remote services to the BEA Tuxedo system on startup but does not actually connect to any BEA TOP END nodes. Remote services are always advertised, regardless of the connection status. The status of individual service availability on the BEA TOP END node is not tracked.
Accepting Incoming Connections Only (INCOMING_ONLY)
The INCOMING_ONLY policy specifies that the TEDG does not attempt to connect to remote domains and does not advertise associated remote services. Connections must be initiated by the BEA TOP END system connecting to the TEDG or by a manual connection attempt by the BEA Tuxedo administrator. Multiple network addresses can be handled only by an administrator establishing a connection manually. Connection retries do not apply. When a connection is successfully established, the associated remote services are advertised. If a connection fails, the associated imported services are suspended until the connection is reestablished. The status of individual service availability on the BEA TOP END node is not tracked.
Message Routing
Both the BEA TOP END and BEA Tuxedo systems support routing based on message content. However, the two facilities differ in the granularity of routing provided through the TEDG. You can use the data-dependent routing (DDR) feature of the BEA Tuxedo system and the message sensitive routing (MSR) feature of the BEA TOP END system to direct message traffic, at a low level, between both systems.These facilities are not mutually exclusive and can be used together to control message traffic between systems.
BEA Tuxedo Data-Dependent Routing (DDR)
Specify routing criteria for the TEDG, as you do for other Domains components, in the DM_ROUTING section of the DMCONFIG file. The criteria you specify allow messages to be routed to specific remote domains depending upon the content of the messages. For the TEDG, a remote domain maps to a specific NI (BEA TOP END system node).
BEA TOP END Message Sensitive Routing (MSR)
BEA TOP END clients can use MSR facilities or explicitly specify an MSR target as part of their service request. Because BEA Tuxedo services are mapped to BEA TOP END service parameters that include the optional MSR target (TARGET parameter in the DM_LOCAL_SERVICES section of the DMCONFIG file), it is possible to route messages from the BEA TOP END system to specific services provided by the BEA Tuxedo system (as long as the BEA Tuxedo services are mapped uniquely).
Formats and Message Content Conversion (MCC)
The TOP END Domain Gateway supports BEA TOP END clients and servers using either raw data buffers or FML32. The BEA TOP END formats facility, which is used primarily to describe screen formats, is not supported.
The Message Content Conversion (MCC) feature, which provides hooks for message translation and relies on formats, is also not supported. When a message is sent to the TEDG with a format specified, the format information is ignored and a message about this occurrence is recorded in the userlog.
Message Size and Types
The BEA TOP END system and the TEDG can send and receive messages up to 30K (30 X 1024) bytes (30,000 for RTQ messages) long. BEA TOP END Large Message Architecture (LMA) is not supported by the TEDG.
You can disable the LMA feature in the BEA TOP END application programming interface by setting the attach_info parameter to NULL in all BEA TOP END CSI calls. If an attachment is included in a function call, the TEDG will:
Because the BEA Tuxedo system allows large messages as part of normal processing, the TEDG detects large messages, returns an error to the client, and does not forward the messages to the BEA TOP END system.
The TEDG supports BEA TOP END clients and servers using either raw data buffers or FML32. The use of BEA TOP END screen formats is not supported.
How the TEDG Handles Queue Processing
Both the BEA TOP END and BEA Tuxedo systems support reliable queues as a means of passing messages between components. The BEA Tuxedo /Q facility and the BEA TOP END Recoverable Transaction Queuing (RTQ) product allow messages to be passed using a queue as a stable intermediary, capable of storing messages before processing. This model is useful when offline processing of requests is preferred, or when such processing is the only practical method of client/server communication. Both /Q and RTQ guarantee that once a message is successfully placed on a queue it will be delivered to a server. Full transaction semantics are supported for both the original message queuing and the subsequent message processing.
The TEDG supports the queuing of messages between the BEA Tuxedo and BEA TOP END systems, as well as transactional queuing between systems. While /Q and RTQ offer similar capabilities, they are fundamentally different in their approach to handling queued messages.
The BEA Tuxedo system provides a function that allows programs to explicitly dequeue messages (see tpdequeue(3c) in BEA Tuxedo ATMI C Function Reference). Alternatively, a system-supplied service, TMQFORWARD(5), can be configured to dequeue messages automatically and forward them to standard BEA Tuxedo servers via the normal tpcall(3c) function. The destination service is mapped to the queue name.
In contrast, the BEA TOP END system does not provide a dequeuing facility for user programs. Instead, messages are dequeued by the RTQ subsystem, which delivers them to the intended service. The destination service address is supplied as part of the process of enqueuing the message (see tp_rtq_put(3T) in BEA TOP END Programmer's Reference Manual). The relationship between the queues and the services is arbitrary.
See Also
How the TEDG Supports Transactions
The TOP END Domain Gateway (TEDG) supports transactional message passing and queuing between BEA TOP END and BEA Tuxedo systems.
Specifically, the TEDG performs the following functions:
Transaction Identifier Mapping
Both BEA TOP END and BEA Tuxedo systems follow the XA standard for transaction identifiers (XID). In the BEA Tuxedo system, the latter are referred to as Global Transaction Identifiers (GTRID). BEA TOP END users identify transactions with the term "XID." The XA XID is composed of a Global Transaction ID (GTRID) and a Branch Qualifier (BQUAL). The TEDG creates a new transaction branch for each new transaction step; this is known as a loosely-coupled relationship. Refer to "Using GTRID Mapping in Transactions" in Using the BEA Tuxedo Domains Component for details on loosely-coupled and tightly-coupled relationships. The TEDG supports loop-back transactions that span BEA TOP END or BEA Tuxedo systems multiple times. A new branch is generated for each hop.
For transaction branches destined for the BEA TOP END system, the TEDG creates a branch following the BEA TOP END branch design. For incoming transaction branches the BEA Tuxedo design is used.
Transaction Management
The TEDG supports transaction management by providing transaction logging and recovery capabilities.
Logging Transactions
The TEDG logs the transaction state during the two-phase commit process to enable recovery. Each instance of the TEDG has its own log. The specification of the DMTLOG is given in the DM_LOCAL_DOMAINS section of the DMCONFIG file. As with other Domains features, the logging functionality is provided by the GWADM administrative server.
When a transaction has been committed on all nodes, the records for that transaction are removed from the log.
Transaction Recovery
The TEDG performs recovery in a fashion identical to other Domains products.
When a domain gateway group is booted, the gateway performs an automatic warm start of the DMTLOG. The warm start includes a scan of the log to determine whether any transactions have not been completed. If incomplete transactions are found, action is taken to complete them.
The TEDG supports connections to BEA TOP END nodes that use the BEA TOP END Extended Recovery (XR) feature. The TEDG itself cannot be an XR node.
See Also
Characteristics of the APIs
Both the BEA Tuxedo and BEA TOP END provide application programming interfaces (APIs) that follow the X/Open DTP model. The BEA Tuxedo API is called the Application-to-Transaction Monitor Interface (ATMI). The BEA TOP END API is referred to as the Client/Server Interaction (CSI) facility.
Characteristics of the BEA Tuxedo ATMI
The BEA Tuxedo ATMI provides the interface between the application and the transaction processing system. It provides routines to open and close resources, manage transactions, manage typed buffers, and invoke request/response, conversational, and queuing functions.
The BEA Tuxedo ATMI functions are used by BEA Tuxedo client and server programs to communicate with BEA TOP END client and server programs through the TOP END Domain Gateway (TEDG). To a great extent, the way in which ATMI functions are used to communicate with BEA TOP END applications is identical to how ATMI functions are used to communicate with other BEA Tuxedo programs or applications through other domain gateways. The primary difference is that the TEDG does not support the same functions and features as other domain gateways. Because the TEDG connects two similar but not identical client/server environments, only features common to both environments can be supported when these environments are interoperating. This set of features common to both the BEA Tuxedo and BEA TOP END systems is provided by the TEDG through configuration, feature mapping, and exposing supported features at the ATMI programming interface in a way that closely matches the standard use of the ATMI.
Supported ATMI Features and Functions
The following ATMI programming features are supported for communication via the TEDG. The functions listed as examples are the primary functions associated with the features from a TEDG perspective. To write a complete application, other interface functions are also required.
Unsupported ATMI Features
For several BEA Tuxedo ATMI features there are no corresponding features in the BEA TOP END system. Therefore, these features are not supported by the TEDG, although they are still available in the BEA Tuxedo system. The following ATMI features are not supported by the TEDG:
Characteristics of the BEA TOP END CSI
CSI, the BEA TOP END application programming interface (API), provides a set of routines used by BEA TOP END client and server programs to communicate with BEA Tuxedo client and server programs through the TEDG. To a great extent, the way in which CSI routine calls are used to communicate with BEA Tuxedo ATMI applications is identical to how CSI routines are used to communicate with other CSI applications. The primary difference is the features or options supported for each routine. The TEDG supports a set of features common to both the BEA Tuxedo and BEA TOP END systems through configuration, feature mapping, and exposure of supported features at the CSI programming interface in a way that closely matches the standard use of the CSI.
Supported CSI Features and Routines
BEA TOP END offers several programming interfaces. For the purpose of this document, they can all be considered part of CSI (Client/Server Interaction). The following programming features and routines are supported for communication via the TEDG:
The routine calls listed as examples are the primary routine calls associated with the features from a TEDG perspective. To write a complete application, other routine calls are also required. In addition, other variations of the calls listed here may be available.
Unsupported CSI Features
For several BEA TOP END programming facilities there are no corresponding features in the BEA Tuxedo system. Therefore these programming facilities are not supported by the TEDG, although they are still available in the BEA TOP END system.
See Also
How the TEDG Is Administered
The TOP END Domain Gateway (TEDG) is administered as part of the BEA Tuxedo application space using standard BEA Tuxedo tools (tmadmin(1) and dmadmin(1)). The TEDG cannot be administered through the BEA TOP END system.
The TEDG is primarily configured using BEA Tuxedo tools (DMCONFIG and dmloadcf(1)). The only configuration necessary in the BEA TOP END system, beyond configuring the TEDG nodes, is configuration of any security mechanisms being used.
Run-time administration of the TEDG is done using BEA Tuxedo tools: the dmadmin command, and the DMADM and GWADM gateway servers.
See Also
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
