ORACLE SERVER AND UNIX TP MONITOR-1

Question

제품 : ORACLE SERVER
작성날짜 : 2002-05-17
====================================================================
Subject: Oracle Server and UNIX Transaction Processing Monitors - 1
=====================================================================
PURPOSE
This file contains commonly asked questions about Oracle Server and UNIX
Transaction Processing Monitors (TPMs). The topics covered in this article are
     o What is a Transaction Processing Monitor (TPM)?
     o What is the X/Open Distributed Transaction Processing Model?
     o How does the Oracle Server works with TPMs?
     o How should I position TPMs with my customer?
     o What Oracle products must a customer purchase?
     o Where can my customer purchase a TPM?
     o Availability and packaging
Explanation & Example
What is a Transaction Processing Monitor?
=========================================
Under UNIX, a Transaction Processing Monitor (TPM) is a tool that coordinates
the flow of transaction requests between front-end client processes that issue
requests and back-end servers that process them. A TPM is used as
the "glue" to coordinate transactions that require the services of several
different types of back-end processes, such as application servers and
resource managers, possibly distributed over a network.
In a typical TPM environment, front-end client processes perform screen
handling and ask for services from back-end server processes via calls to the
TPM. The TPM then routes the requests to the appropriate back-end server
process or server processes, wherever they are located on the network. Through
configuration information, the TPM knows what services are available and where
they are located. Generally, the back-end server processes are specialized so
that each one handles one type of requested service. The TPM provides
location transparency as well and can send messages through the network
utilizing lower-level transport services such as TCP/IP or OSF DCE.
The back-end servers process the requests as necessary and
return the results back to the TP monitor. The TP monitor then routes
these results back to the original front-end client process.
A TPM is instrumental in the implementation of truly distributed processing.
Front-end clients and back-end processes have no knowledge of each
other. They operate as separate entities, and it is this concept that provides
flexibility in application development. Front-end and back-end processes are
developed in the UNIX client-server style, with each side optimized for its
particular task. Server functionality can be deployed in stages, which makes
it easy to add functionality as needed later in the product cycle. It also
makes it easy to distribute both the front-end and back-end processes
throughout the network on the most appropriate hardware for the job. In
addition, multiple back-end server processes of the same type might be
activated to handle increasing numbers of users.
What is the X/Open Distributed Transaction Processing Model?
============================================================
The X/Open Transaction Processing working group has been working
for several years to establish a standard architecture to implement
distributed transaction processing on open systems. In late 1991,
X/Open published the initial Distributed Transaction Processing (DTP)
model specification and defined the first of several interfaces that
exist between the components of the model. Subsequently, other publications
and a revised model specification have been published.
An important function of the TPM in the X/Open DTP model is the
synchronization of any commits and rollbacks that are required to complete
a distributed transaction request. The Transaction Manager (TM) portion
of the TPM is the entity responsible for ordering when distributed commits
and rollbacks will take place. Thus, if a distributed application program
is written to take advantage of the TM portion of the TPM, then it,
and not the DBMS, becomes responsible for enabling the two-phase commit
process. Article 2 has more detail on this model.
How does the Oracle Server work with TPMs?
==========================================
When a TPM is used without invoking an X/Open TM component to manage the
transactions, Oracle Server needs no special functionality. The transaction
will be managed by Oracle itself. However, when the TPM X/Open TM component
is used to manage the transaction, the Oracle Server, that is the Oracle DBMS,
acts as a Resource Manager--a type of back-end process. In the case of
TPM-managed transactions, the TM needs a way to tell the RMs about the stages
of the transaction. This is done by a standard, X/Open defined interface
called XA. Article 2 of of this document gives more information about both
the X/Open model and Oracle7's use of XA.
Because the XA interface provides a standard interface between the TM and the
resource manager, it follows that the TM can communicate with any XA-compliant
resource manager (e.g., RDBMS), and, conversely, that a resource manager can
communicate with any XA-compliant TM. Thus, the Oracle Server, beginning with
Oracle7, works with any XA-compliant TM.
How should I position TPMs with my customer?
============================================
There's been a great deal of confusion about the need for TPM technology. Some
software suppliers, most notably IBM, will assert that a TPM like CICS is a
necessary requirement for high volume OLTP. Other vendors will assert that
there is seldom a need for such technology. And yet others promote TPMs as
providers of higher transaction throughput.
From Oracle's standpoint, customers might choose TPM technology under any of
the following conditions:
1. For heterogeneous database access, especially for 2PC capability
     This means that a TPM can be used to coordinate 2PC between Oracle
     DBMS and any other XA-compliant database, such as Informix. This
     does NOT provide SQL heterogeneity - SQL calls to Oracle DBMS may be
     different than SQL calls to Informix. The TPM handles the routing,
     communication, and two-phase commit portion of the transaction, but
     does not translate one type of SQL call into another.
2. For transaction monitoring and workload control
     The leading TPMs supply tools to actively manage the flow of
     transactions between clients and servers and to load balance the work
     load across all available processors on a network, not just on a
     single multi-processor system. Some TPMs also have the ability to
     dynamically bring up additional back-end services during peak work
     hours.
3. For more flexible application development and installation
     One of the key features of the DTP model is application modularity.
     Modularity, that is, the decomposition of a large program into small,
     easily defined, coded and maintained "mini-programs" makes it easy to
     add new functionality as needed. Modularity also makes it much easier
     to distribute the front-end and back-end processes and the resource
     managers across hardware throughout a network.
4. For isolating the client from details of the data model
By using the service oriented programming model, the client program
     is unaware of the data model. The service can be recoded to use a
     different one with no change to the client. To get this advantage,
     the application developer must explicitly code the server and client
     to fit the service model.
5. For connection of thousands of users
     TP Monitors, because of their three-tier architecture, can be used
     to connect users to an intermediate machine or machines, removing
     the overhead of handling terminal connections from the machine
     actually running the database. See Article 4 for more information.
There are also several cases where TPM technology is not the right answer.
These include:
1. If the customer is simply looking for a performance improvement
     The customer may have heard a theory that "higher performance
     is possible for large scale applications only if they use a
     TP monitor". First, no performance gain can be achieved for
     existing applications; in fact, they won't even run under a TP
     Monitor without recoding. Second, performance improvements have
     only been documented for large numbers of users, and "large"
     means many hundreds or thousands. Without a TP Monitor,
     Oracle Server can handle several hundred users with its normal
     two-task architecture and several times that using the Multi
     Threaded Server. For more on performance, see Article 4.
2. If the customer has made large investment in his existing Oracle
applications
     TP monitor applications must be designed from the ground up to take
     advantage of TP monitor technology. Current Oracle customers will find
     it difficult to "retrofit" a TP monitor to their existing applications.
     The Multi Threaded Server, on the other hand, allows the use of
     existing Oracle applications without change.
3. If the customer is committed to the Oracle tool set
     Currently, none of Oracle's front-end tools (Oracle Forms, etc.) is
     designed to work with TP monitors. It is possible to invoke a
     TP Monitor by using user exits. However, the fact that the TP
     Monitor model hides the data model from the client means that only
     the screen display parts of Forms can be used, not the automatic
     mapping from screen blocks to tables.
4. If the customer does not have a staff of experienced software engineers
     This is still very young technology for UNIX. There is not a lot of
knowledge in the industry on how to build TP monitor applications or
what techniques are most useful and which are not. Furthermore,
     integrating products from different vendors, even with the support
     of standard interfaces, is more complex than deploying an integrated
     all-Oracle solution. Because TP monitor technology is fairly
     complex, we recommend that you let the TP monitor supplier promote
     the virtues of their technology and differentiate themselves from
     their competitors.
What Oracle products must a customer purchase?
==============================================
If your customer is only interested in building Oracle-managed TP Monitor
transactions, the only Oracle products required are the Oracle Server
and the appropriate Oracle precompiler for whatever language the
application is being written in--most likely C or Cobol. If TPM-managed
transactions are required, the Oracle7 Server with the distributed option
is also required. SQL*Net is optional because the TPM takes care of the
network services. Article 2 describes when you would choose to have the TP
Monitor manage the transactions.
Where can my customer purchase a TPM?
=====================================
There are many vendors offering the UNIX TPM products. (Oracle does not
relicense TPMs.) Information on the most well known products is provided
below:
The following support XA:
Product & Vendor     FCS          Known OS/Platform Ports
"TUXEDO System/T"     1986          UNIX SVR4 & SVR3: Amdahl, AT&T,
UNIX System Laboratories          Bull, Compaq, Dell, Fujitsu, ICL,
190 River Road                    Motorola, Olivetti, Pyramid,Sequent,
Summit, NJ 07901               Sun, Toshiba, Unisys, NCR, Stratus
                         Other: IBM AIX, HP/UX, DEC Ultrix
"TOP END"      1992          UNIX SVR4: NCR
NCR Corporation
1334 S. Patterson Blvd.
Dayton, OH 45479
"ENCINA"          1992          IBM AIX, HP, Sun (SunOS and Solaris)
Transarc Corporation               Other: OS/2, DOS, HP-UX, STRATUS
707 Grant Street (Depends on DCE)
Pittsburgh, PA 15219
"CICS/6000" 1993          AIX: IBM
IBM Corporation                    (Depends on DCE)
"CICS 9000" 1994          HP-UX
HP
The following do not currently support XA:
Product & Vendor     FCS          Known OS/Platform Ports
"VIS/TP"          unknown          unknown
VISystems, Inc.
11910 Greenville Avenue
Dallas, TX 75243
"UniKix"          1990          UNIX: ARIX, AT&T, NCR, Pyramid,
UniKix                     Sequent, Sun, Unisys      
"MicroFocus           1993          SCO Unix, AIX
Transaction System"
Micro Focus
26 West Street
Newbury RG13 1JT
UK
There are also several third parties who are reselling the products listed
above.
In addition, Groupe Bull, Digital, Siemens-Nixdorf, and several other hardware
vendors are planning to redesign their proprietary TPMs to be XA-compliant and
suitable for use on UNIX systems.
Availability and Packaging
==========================
On what platforms is the XA Library available?
Oracle provides the XA interface with Oracle7 Server on all platforms that
support an XA-compliant TPM. Support for XA is included as part of the
Oracle7 Server distributed option and has no extra charge in and of itself.
Which version of XA does Oracle Server support?
Oracle7 Server supports the Common Application Environment (CAE) version of
XA, based on the specification published by X/Open in late 1991. It will
require that the TM also be at that level. This means Tuxedo /T version 4.2,
for example.
Oracle Server supports all required XA functions. There are some optional
features Oracle Server does not support, such as asynchronous operation.
None of those options affect application programming.
Page (2/4)
This file contains commonly asked questions about Oracle Server and UNIX
Transaction Processing Monitors (TPMs). The topics covered in this article are
     o Oracle Server Working with UNIX TPMs
     o TPM Application Architecture
The questions answered in part 2 provide additional detail to the information
provided in part 1.
Oracle Server Working with UNIX TP Monitors
===========================================
Do I need XA to use Oracle Server with TPMs? If I don't use it, what are
the consequences?
There are a number of real applications running today with Oracle Server and
TPMs but not using XA. To use a TPM with Oracle without using XA, the user
would write an "application server" program which could handle one or more
"services". For example, a server program might handle a service called
"debit_credit". The key requirement is that the entire transaction,
including the "commit work", must be executed within a single service. This
is the restriction which XA will remove, as we'll see later. Each
server process can serially handle requests on behalf of different clients.
Because a server process can handle many client processes, this can
reduce the total number of active processes on the server system,
thereby reducing resource requirements and possibly increasing overall
throughput.
When Oracle is used with a TPM in this mode, we call it an Oracle-managed
transaction since the transaction commit or rollback is done with a SQL
statement.
What is XA? How does XA help Oracle7 work with UNIX TPMs?
XA is an industry standard interface between a Transaction Manager and a
Resource Manager. A Resource Manager (RM) is an agent which
controls a shared, recoverable resource; such a resource can be
returned to a consistent state after a failure. For example, Oracle7 Server
is an RM and uses its redo log and undo segments to be able to do this.
A Transaction Manager (TM) manages a transaction including the
commitment protocol and, when necessary, the recovery after a failure.
Normally, Oracle Server acts as its own TM and manages its own commitment
and recovery. However, using a standards-based TM allows Oracle7 to
cooperate with other heterogeneous RMs in a single transaction.
The commonly used TPMs include a TM component for this purpose. In order to
use the TM capability of the TPM rather than Oracle7's own transaction
management, the application uses a transaction demarcation API (called TX)
provided by the TPM rather than the SQL transaction control statements (e.g.
"commit work"). For each TX call, the TM then instructs all RMs, by the
appropriate XA commands, to follow the two-phase commit protocol. We
call this a TPM-managed transaction.
The following picture shows these interfaces within a monolithic application
program model. This is the model most commonly described in the
DTP literature. We'll see later what the picture looks like when we add
Oracle7 and when we switch to a modularized client-server application
program model.
          | |
          | |
          | Application Program (AP) |
          | |
          | |
               | | |                    |
Resource Manager API | | | |
(e.g. SQL) -----|--|------------- | TX API
          | | v |          |
          --------|-------------     |          |
          | v | | v
     ---------------------- | | --------------------
     | | | | | |
     | Resource | | |<----->| Transaction |
     | Managers | |--- | Manager |
     | (RMs) | |<-------->| (TM) |
     | |--- | |
     | |<----------->| |
     ---------------------- XA --------------------
                    Interface
The XA interface is an interface between two system components, not
an application program interface; the application program does
not write XA calls nor need to know the details of this interface.
The TM cannot do transaction coordination without the assistance of
the RM; the XA interface is used to get that assistance.
How does the DTP Model support client-server?
The above picture was actually simplified to make it easier to explain
the role of XA. In a true distributed transaction architecture, there
are multiple applications, each with an Application Program, a Resource
Manager, and a Transaction Manager. The applications communicate by
using a Communication Resource Manager. The CRM is generally provided
as a component of the TPM. It includes the transaction information when
it sends messages between applications, so that both applications can
act of behalf of the same transaction. The following picture
illustrates this:
Client Application
| AP |
||| | |
SQL ||| | TX | CRM
||V V | API
-||-- ----- |
| |V | | | V
--|-- |<---| | -----
| V || | | | |
----- |<----| TM |<-->| CRM |
| || | |XA+ | |
| RMs |<-----| | -----
| | XA | | A
----- ----- | Server Application
| -----------------------------
| | AP |
| -----------------------------
| ||| | |
| SQL ||| | TX | CRM
| ||V V | API
| -||-- ----- |
| | |V | | | V
| --|-- |<---| | -----
| | V || | | | |
| ----- |<----| TM |<-->| CRM |
| | || | |XA+ | |
| | RMs |<-----| | -----
| | | XA | | A
| ----- ----- |
| |
| |
-------- |
/ |
/ |
/ |
Most TP Monitor products include both a TM and a CRM, and also provide
additional functions such as task scheduling and workload monitoring.
What is XA+? What does Oracle need to do to comply with it?
XA+ is an interface that lets the X/Open model actually be distributed
because it allows a communication resource manager to tell a TM on the
server that a message from a client just came in for a particular
transaction. Oracle is not currently planning to provide an X/Open
communication resource manager, so we don't have any plans right now
to do XA+. Version 2 of the DTP model paper from X/Open describes it.
The status of the current XA+ specification is "snapshot".
When would I choose an Oracle-managed transaction vs a TPM-managed
transaction?
Oracle Server is very efficient at managing its own transactions. If
the TPM manages the transaction, in general some additional overhead
will be incurred.
The two main reasons a customer might prefer to use a TPM-managed
transaction are as follows:
(1) He may need to update RMs from different vendors. Experience so far
has been that the most common case is wanting to update both Oracle and
a TP Monitor managed resource such as a transactional queuing service
in the same transaction (see Article 3).
(2) He may want to use the model of having several different services in
a transaction, even to the same database. For example, the
"debit_credit" service could be split into a "debit" service and a
"credit" service. This is a very attractive model, but this type of
modularity does exact a performance penalty (see Article 4).
Can I get a version of XA to run on Oracle Server version 6?
No, the XA functionality uses two underlying mechanisms in the Oracle
Server which are not available in version 6: two-phase commit and
session switching. The upi calls for these functions do not not exist
in version 6.
When would I use XA vs Oracle7 to coordinate all-Oracle distributed
transactions?
Generally speaking, Oracle Server should be used to coordinate all-Oracle
distributed transactions. The main reason for using XA to coordinate
transactions would be that you want to use the TP Monitor service-oriented
architecture. That is, you would like to construct an application built of
services and service requests in order to benefit from the modularity and
workload control such an environment provides.
TP Monitor Application Architecture
===================================
What might a TP Monitor application look like?
Most TPM applications will consist of two more more programs, where
there are front-end client programs which request services and back-end
server programs which provide services. In this case, the TPM supplies an
additional capability which is transactional communication. The client
describes the boundaries of the transaction, through the use of the TX API,
and the TPM relays that transaction information to each requested service.
The overall application structure generally looks like the following in the
client-server model. The "TP Monitor Services" box is not necessarily a
process. It could be one or more processes, or just libraries coordinating
through shared memory. Each client process and server process could be on
a different machine. Normally, the application server processes would be
connected to their Oracle Server processes using the IPC driver; the TPM
would be used to deliver messages between application client processes on
one machine and application server processes on another. However, the
application server processes could also be connected with the standard
Oracle SQL*Net to shadow processes on different machines. This might be
useful if one of the databases was on a machine which did not support TPMs.
|Application| |Application| |Application|
| Client 1 | | Client 2 | | Client 3 |
| | | | | |
\ TPM API | TPM API / TPM API
| |
| TP Monitor Services |
| |
     | --------------------- |
| | Transaction Manager | |
---------------|---------------|---------------------
TPM API | | XA | XA | TPM API
| | inter- | inter- |
          | | face | face |
          | | | |
----------- | | -----------
|Application| | | |Application|
| Server 1 |--- ---| Server 2 |
| (Pro*C) | | | | (Pro*C) |
| SQL | SQL
| | | |
| Resource ----------- ----------- |
| Manager | | | | |
| | Oracle7 | | Oracle7 | |
| | Server | | Server | |
| | Process | | Process | |
| | | | | |
| ----------- ----------- |
| | | |
| ----------------------------------------------------- |
| | | |
| | SGA | |
| | | |
| ----------------------------------------------------- |
| |
Application client programs might be written in C and be linked with
TPM libraries. Alternatively, they could use a screen painter product.
Application server programs would be written in Pro*C or Pro*COBOL and
be linked with TPM libraries, the normal Oracle7 user-side libraries
and libxa.a. The Oracle7 Server process is the regular Oracle7 executable.
More complicated application architectures can also be constructed. Most of
the TPMs allow a server to become a client of another service, so you can
involve additional servers.
Could I use Oracle7's Multi Threaded Server as the SQL*Net connection in the
previous picture?
Yes, but that will not be needed in many cases. For example, both
application server processes in the previous picture could talk to a
single Oracle7 Server process through the Multi Threaded Server in the
previous picture. However, since the TPM architecture typically reduces
the number of server processes, the reduction in processes using Multi
Threaded Server may be less significant than in an architecture without
TPMs. If the application will use database links, however, then MTS will
be required.
How do I write an Oracle TP Monitor application?
The actual API used to talk to the TPM varies between vendors, so you need
to get the documentation from the vendor. However, all have a way to
indicate where a transaction begins and ends and a way to send a request
and receive a response from a client to a server. Some use an RPC model,
some use a pseudo-RPC model, and some use a send/receive model. The TX API
described earlier is a subset of the TPM API as defined by each of
the TPM providers.
The client program and server program might look something like the
following examples. We h (such as Tuxedo's
"tpacall
Reference Ducumment
---------------------

Answer 1

hello,
the role is the same on all plattforms. the reports server takes requests for running reports, spawns an engine that executes the request. in addition to that, the server also provides scheduling services and security features for the reports environment.
regards,
the oracle reports team