Oracle® Application Server Adapter for Tuxedo User's Guide 10g Release 2 (10.1.2) B15802-01 |
|
![]() Previous |
![]() Next |
This section provides an overview of the features and architecture of OracleAS Adapter for Tuxedo.
This section contains the following topics:
OracleAS adapter for Tuxedo integrates Oracle Application Server with the legacy and mainframe applications. OracleAS Adapter for Tuxedo models services running on the BEA Tuxedo application server. The BEA Tuxedo application server provides two programming interfaces, Common Object Request Broker Architecture (CORBA) and Application to Transaction Monitor Interface (ATMI). ATMI supports a programming interface that offers procedural library-based programming using a set of C or COBOL procedures. ATMI also provides an interface for communication, transaction, and data buffer management. In addition, the ATMI interface and BEA Tuxedo system implement the X/Open distributed transaction processing (DTP) model for transaction processing.
In OracleAS Adapter for Tuxedo, Tuxedo services are modeled as a collection of interactions, where each interaction is mapped to a specific Tuxedo service along with its particular input record and output record.
OracleAS Adapter for Tuxedo includes the following features:
Improves performance by providing direct access to the platform where OracleAS Adapter for Tuxedo runs.
Models Tuxedo services as a collection of interactions, where each interaction is mapped to a specific Tuxedo service, along with the input and output records.
Captures and maintains a metadata schema for the Tuxedo system by importing Tuxedo metadata either from FML and VIEW files or from a JOLT file, and transforming this metadata into mapping definitions for Oracle Connect.
Supports Tuxedo/T synchronous calls.
Maps Tuxedo message structures to XML data and back.
Supports local transactions by acting as a Resource Manager (RM). This is achieved by the adapter responding to Connect XML transactional verbs and issuing the corresponding ATMI transactional calls. The back-end service is responsible for the transaction semantics and implementation.
Supports full client authentication with the Tuxedo server. An optional use of username and password is also supported.
Supports the following types of buffers:
STRING
VIEW
: Both 16-bit and 32-bit are supported.
CARRAY
FML
: Both 16-bit and 32-bit support are supported.
XML
MBSTRING
: Only supported in BEA Tuxedo version 8.1 and higher.
OracleAS Adapter for Tuxedo does not support two-phase commit and cannot participate in a distributed transaction.
The following components comprise the architecture for Oracle AS Adapter for Tuxedo:
J2CA 1.0 Tuxedo adapter: The J2CA Tuxedo adapter is a standard resource adapter that is compliant with J2EE Connector Architecture, providing J2EE components connectivity.
Oracle Connect: Oracle Connect runs on the legacy system and handles requests from the J2CA 1.0 Tuxedo adapter that runs within Oracle Application Server Containers for J2EE (OC4J).
Oracle Studio: Oracle Studio is the configuration tool for Oracle Connect. Configuration tasks using Oracle Studio are performed on a Windows platform. Oracle Studio uses perspectives that enables you to generate specific information necessary to model OracleAS Adapter for Tuxedo.
Figure 1-1 illustrates the components of OracleAS Adapter for Tuxedo.
Figure 1-1 Architecture of OracleAS Adapter for Tuxedo
The J2CA 1.0 Tuxedo adapter converts the J2CA interaction invocation received from an application client to the XML format and passes the XML format to Oracle Connect on the legacy server. The daemon listens for the request coming from the J2CA 1.0 Tuxedo adapter client and assigns a server process to handle the request. The properties of the server process (such as connection pooling requirements) are defined by a workspace definition within the daemon. The server process includes an instance of the application engine, which converts the XML format into native structures understandable by Tuxedo and passes the converted XML to the back-end adapter. The back-end adapter builds an interaction based on the metadata for the back-end adapter stored in the repository and the incoming converted XML and passes it to the legacy application. The results of this execution are passed back to the application engine, using the back-end adapter, where these results are converted to XML and passed back to the client.