ClearPath Enterprise Servers

(1)

ClearPath Enterprise Servers

Open Distributed Transaction Processing

Technical Overview

MCP 12.0

(2)

(3)

unisys

imagine it. done.

ClearPath Enterprise Servers

Open Distributed Transaction Processing

Technical Overview

MCP 12.0

(4)

NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the products described in this document are set forth in such agreement. Unisys cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, special, or consequential damages.

You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used.

The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions.

Notice to U.S. Government End Users: This is commercial computer software or hardware documentation developed at private expense. Use, reproduction, or disclosure by the Government is subject to the terms of Unisys standard commercial license for the products, and where applicable, the restricted/limited rights provisions of the contract data rights clauses.

(5)

ClearPath Enterprise

Servers

Open Distributed

Transaction Processing

Technical Overview MCP 12.0 ClearPath Enterprise Servers Open Distributed Transaction Processing Technical Overview MCP 12.0 8999 5435–002 8999 5435–002

(6)

(7)

Client Programs ... 2–2 Client Programs and the Client Role ... 2–2 Client Program Structure ... 2–3 Interfaces for Client Programs... 2–3 Server Programs ... 2–3 Handling Service Requests... 2–3 Creating Server Programs ... 2–3 Service Routines... 2–4 Processing Requests... 2–5 Service Routine Structure... 2–5 Interfaces for Service Routines ... 2–5 Client/Server Communication Methods... 2–5 Request-Response Communications ... 2–6 Conversational Communications ... 2–8 Advantages of the Client/Server Paradigm... 2–9 Application Program Interfaces... 2–9

Open Distributed Transaction Processing

Architecture Overview ... 2–10 Supported APIs... 2–11

Section 3. Open Distributed Transaction Processing

Application Programs ... 3–2 Language Interfaces ... 3–2 Desktop Agent and Workstation... 3–3 Transaction Server ... 3–3 Transaction Manager (TM) ... 3–3 Enterprise Database Server ... 3–4 OSI-TP ... 3–4

Section 4. Open Distributed Transaction Processing Library

Task and Documentation Summary... 4–1 Documents for System Administrators ... 4–2 Documents for Application Developers ... 4–3

(8)

Contents

Appendix A. Standards on Which Open Distributed Transaction Processing Products Are Based

The Open Group Distributed Transaction Processing (DTP)

Model ... A–1 Implementations of the DTP Model... A–1 Building Blocks of the DTP Model ... A–2 Components... A–2 Interfaces ... A–4 OSI-TP Distributed Transaction Processing Protocols and

Services ... A–5 The OSI-TP Standard ... A–6 Relationship to Networking Protocols... A–6 Model of a Global Transaction ... A–6 Systems in the Transaction ... A–7 Steps in the Transaction... A–9 Two-Phase Commitment Process ... A–10

(9)

Figures

2–1. Open Distributed Transaction Processing Application Environment ... 2–1 2–2. Open Distributed Transaction Processing Client Program... 2–2 2–3. Open Distributed Transaction Processing Service Routines ... 2–4 2–4. Request-Response Communications... 2–6 2–5. Asynchronous Communication ... 2–7 2–6. Conversation Communications ... 2–8 2–7. Open Distributed Transaction Processing Process Model ... 2–10 3–1. Primary Components of Open Distributed Transaction Processing ... 3–1 A–1. Components and Interfaces of the DTP Model ... A–2 A–2. The DTP Model and OSI-TP ... A–5 A–3. Example Global Transaction Configuration ... A–7 A–4. Steps in the Global Transaction ... A–9 A–5. Two-Phase Commit Protocol ... A–11

(10)

(11)

Section 1 Welcome to Open Distributed

Transaction Processing

Documentation Updates

This document contains all the information that was available at the time of publication. Changes identified after release of this document are included in problem list entry (PLE)

18576554. To obtain a copy of the PLE, contact your Unisys representative or access

the current PLE from the Unisys Product Support Web site:

http://www.support.unisys.com/all/ple/18576554

Note:_{If you are not logged into the Product Support site, you will be asked to do so.}

Open Distributed Transaction Processing provides an open, standards-compliant environment for developing distributed transaction processing (DTP) applications. Open Distributed Transaction Processing supports global transactions specified by the Open Group DTP model.

Open Distributed Transaction Processing enables you to easily build and manage client-server applications for the enterprise and the Internet. You can write the business logic for your server application as a set of interoperable, services by using a third generation programming language (such as COBOL, ALGOL, or C), or by using a fourth generation language tool (such as Enterprise Application Environment). Open Distributed Transaction Processing then runs these services in the scalable, transactional

environment that is MCP and makes them available to interact with other platforms when needed.

Open Distributed Transaction Processing acts as middleware for your distributed enterprise and Internet applications. That is, it enables clients to communicate with servers without requiring you to concern yourself with communication protocols and platforms. Open Distributed Transaction Processing provides an open environment that supports a wide variety of clients, databases, networks, legacy systems, and

(12)

(13)

Section 2 Using Clients and Servers

One of the features that Open Distributed Transaction Processing uses to integrate applications in real time across a variety of systems is support for the client/server paradigm. In this paradigm

• A client is a process that requests services and receives replies.

• A server is a process that accepts requests, calls appropriate services, and returns replies to the requestor.

Open Distributed Transaction Processing provides the infrastructure to support client and server applications. It facilitates client access to servers and their constituent services, manages the services themselves, and supports access to database resources.

Open Distributed Transaction Processing and the Client/Server

Paradigm

Figure 2–1 shows how clients and servers interoperate in an Open Distributed Transaction Processing environment.

Database Host Database Application Services Application Services Server Server CLIENT CLIENT CLIENT CLIENT

(14)

Using Clients and Servers

Explanation

In this diagram, client applications provide user interface routines and request application services. Application services provide core business logic, which does transactional data access and updates. Open Distributed Transaction Processing provides the infrastructure or middleware that integrates clients, services, and databases into a unified distributed application.

Note the shift from a client/database approach toward a client/server approach. This application partitioning promotes a clean separation of functionality—user interaction on one hand, with core business logic and data management on the other. This separation makes application development and enhancement easier.

Client Programs

In their simplest form, client programs are application modules that interact with users or devices and send service requests to Open Distributed Transaction Processing software. Open Distributed Transaction Processing software and the underlying communications systems are responsible for routing service requests to the appropriate servers. Client programs have no knowledge of networks.

As shown in Figure 2–2, client programs typically handle the front-end work of traditional applications; that is, they handle the dialogue with the user. Client programs accept input data from users and return the results of transactions in the form of data or messages.

Figure 2–2. Open Distributed Transaction Processing Client Program

Although client programs can perform some of their own back-end work as well, the task of communicating with database management systems and other resource managers is typically left to service routines.

Client Programs and the Client Role

The term client has two important meanings for Open Distributed Transaction Processing systems:

• Client can refer to a type of application program.

• Client can also refer to the role a service routine plays when it requests a service. That is, a service routine can act as a client by requesting services from other service routines.

(15)

Client Program Structure

There is no required coding structure for client programs, as there is for service routines. However, client programs must adhere to communication techniques that are defined in the XATMI standard.

More Information

For information about these communication techniques, see “Client/Server Communication Methods,” later in this section.

Interfaces for Client Programs

Client programs can use an assortment of standard interfaces and platform-specific software products to provide users all the capabilities they require.

Open DTP standard interfaces available on all platforms include • TX

• XATMI

Server Programs

Server programs are entities that process requests for services from clients and pass those requests to the appropriate service routines. A server program can offer one or more services. In addition, the same service can be offered by more than one server program.

The Open Group XATMI standard does not specify how service routines are incorporated into servers, nor does it specify the details of how servers operate. These issues are left to vendors (such as Unisys) to determine.

Handling Service Requests

Generally speaking, server programs handle service requests in the following manner: 1. Check a message queue for a service request.

2. Call the appropriate service routine to handle the service request.

3. Handle communications between the client program and the service routine (in cooperation with the Open Distributed Transaction Processing communication resource manager component).

4. Regain control after the service routine terminates.

Creating Server Programs

Open Distributed Transaction Processing server programs consist of several

(16)

Distributed Transaction Processing products. Others must be created or generated by application developers or system administrators.

Service Routines

Service routines are server subprograms that interact with databases or other resource managers to perform specific tasks for client programs. Service routines can issue service requests to other service routines and include their work in global transactions. These can be

• Global transactions started by client programs

• Global transactions started by service routines themselves

As Figure 2–3 indicates, service routines typically handle the back-end work of traditional Open Distributed Transaction Processing applications. They have no user interface functions. As with client programs, service routines do not need to know about networks. Open Distributed Transaction Processing software and underlying

communications systems handle the exchange of data and messages between client programs and service routines.

(17)

Processing Requests

Generally speaking, service routines process service requests in the following manner: 1. Receive control from the server.

2. Access a data structure to obtain request information, such as the name of the requested service, input data, and other items.

3. Perform the service by updating a database, sending requests to other Open Distributed Transaction Processing servers, or performing other related tasks. 4. Terminate and return control to the server.

Service routines can also interact with client programs in a conversational manner by sending and receiving data and messages over an extended period of time.

Service Routine Structure

To conform with the communication model in the XATMI standard, service routines must begin processing and end processing in the same way. This structure is known as the service routine template.

The Open Distributed Transaction Progressing XATMI Programming Guide provides detailed information about the service routine template.

Interfaces for Service Routines

Service routines can use an assortment of standard interfaces and platform-specific software products to provide users all the capabilities they require.

Standard Interfaces

Open Group DTP standard interfaces available on all platforms include • TX

• XATMI

Client/Server Communication Methods

The Open Distributed Transaction Processing Client-server architecture is based largely on the Open Group XATMI standard. The XATMI standard specifies a framework for structuring applications as client programs, server programs, and service routines. In addition, the standard provides a distinctive model for client/server communication.

(18)

Client programs, server programs, and service routines can use two methods to communicate:

• Request-response

A client program sends one request to Open Distributed Transaction Processing software, and a service routine returns one response (through its server). No connection between the programs is established .

• Conversational

A client program and a service routine exchange any number of messages through Open Distributed Transaction Processing software (and a server program), using descriptors to identify one another.

Both client/server communication methods are supported for both single machine and distributed environments. That is, client programs and service routines can communicate by both methods, in exactly the same ways, no matter where they reside.

Request-Response Communications

When application programs use the request-response method to communicate, they each send one message to Open Distributed Transaction Processing software: The client program sends a request, and the service routine returns a response (through a server program). No connections are established and no other communications occur. Figure 2–4 shows how request-response communications work.

(19)

Observations

When a client program and a service routine use the request-response method to communicate, the following events occur:

1. A client program sends a request to the Open Distributed Transaction Processing communication resource manager (CRM). The request consists of input for one particular service.

2. The CRM passes the request to a server program.

3. The server program calls a service routine that performs the requested service. 4. When the service routine completes its work and terminates, the server program

sends the response to the Open Distributed Transaction Processing CRM. 5. The CRM passes the response to the client program.

Variations

Application programs that use the request-response method can communicate synchronously or asynchronously:

• In synchronous communications, the client program waits (or blocks) until it receives the service routine's response.

• In asynchronous communications, the client program asks Open Distributed

Transaction Processing software for the service routine's response when it is ready. This enables the client program to perform useful work while it waits for the service routine to finish.

Figure 2–5. shows how asynchronous communication works.

(20)

Benefits of Request-Response

The request-response communications method is attractive because it • Meets the needs of most applications

• Simplifies application development. Service routines that use the request-response method must begin processing and end processing the same way. After a

programmer learns how to develop one service routine, the rest are relatively easy.

Conversational Communications

When programs use the conversational method to communicate, they establish logical connections through Open Distributed Transaction Processing software and send an unlimited number of messages back and forth.

Figure 2–6 shows how conversational communications work.

Figure 2–6. Conversation Communications

Observations

When a client program and a service routine use the conversational method to communicate, the following events occur:

1. A client program sends a request to the Open Distributed Transaction Processing communications resource manager (CRM). The request consists of input for one particular service.

2. The CRM passes the request to a server program.

(21)

4. The client program and service routine send and receive messages through the CRM, using conversation descriptors to identify one another. The conversation is half-duplex; one program sends and the other receives. During their conversation, the programs can reverse the sending and receiving roles.

5. When the service routine completes its work and terminates, the conversation ends. The CRM returns the service routine's final message to the client program.

Benefits

The conversational method is useful because it enables

• Service routines to send incremental results to client programs

• Client programs and service routines to exchange large amounts of data • Client programs and service routines to vary their actions and perform different

tasks, based on messages received during conversations.

Advantages of the Client/Server Paradigm

The principal benefits of application partitioning are that

• By developing services, application designers can focus on developing core business functions and their interaction. This focus enables them to easily prototype the business logic and key functional elements. Display considerations can be dealt with separately.

• By separating user interface and business logic, you can reuse services, regardless of presentation issues. Thus a single service can be called by clients that provide various user interfaces, from workstation screens to Web pages.

• You can enhance and evolve existing services with little or no impact to clients. • A single client can call multiple services. This means that an application developer

can pick and choose which services a client calls. Some services can be new, while others already exist. The client can package these functions with a consistent look and feel to the user.

Application Program Interfaces

As middleware, Open Distributed Transaction Processing facilitates the interaction of clients and servers. It does this, in part, by means of special application program interfaces (APIs).

(22)

Open Distributed Transaction Processing Architecture

Overview

Figure 2–7 shows how the component software of Open Distributed Transaction Processing mediates such interaction.

Figure 2–7. Open Distributed Transaction Processing Process Model

Explanation

In this diagram, client processes, such as desktop applications, call named services. Calls become message-based requests for service that enter Open Distributed Transaction Processing and are dispatched to server processes implementing the requested services. A key function of discrete services is the access and updating of resource managers (databases). If updates are made within the scope of a transaction, Open Distributed Transaction Processing transaction management services coordinate the transaction on behalf of the participating clients and services, and in cooperation with the participating resource managers .

Open Distributed Transaction Processing component software applications execute as a group of cooperating processes using message-based communications. For example, a simple client-server application request involves the following steps:

1. A client process, such as a desktop application, calls an Open Distributed Transaction Processing managed service.

2. A request message is formatted and passed over the network to the desktop agent on the Open Distributed Transaction Processing server node.

(23)

3. The request message is then passed from the desktop agent process directly to the server queue for processing.

4. The server process reads the message from its queue and invokes the requested named service. Typically a service will access a resource manager, perhaps

performing an update. Upon service completion, the reply message is placed in the client’s queue in the desktop agent. From here, the reply propagates back over the network to the initiating client process.

5. By default, server processes are stateless and serially reusable. After completing a request, the server loops back to its initial state and is ready to process the next request in its queue.

Advantages

By dynamically mapping requests to managed servers, Open Distributed Transaction Processing exercises broad control over the flow of processing for the overall application. Dynamic, flexible mapping means that you can configure the relationship between clients and servers to handle

• Many clients dealing with one server • Many clients dealing with many servers • One client dealing with many servers

Supported APIs

Open Distributed Transaction Processing programming interfaces support the

client/server model of application development. Applications are structured as client and server components using message-based procedure invocations to communicate. The procedure paradigm encapsulates the notion of a request for a specific service and a mechanism for exchanging the data (that is, the request and response arguments). Open Distributed Transaction Processing offers a rich set of communication interfaces to meet a variety of application design requirements. In addition to communications interface, the Open Distributed Transaction Processing transaction demarcation (TX) interface provides the means to define reliable distributed transactions.

Communications Programming Interface (XATMI)

Open Distributed Transaction Processing provides library-based programming interfaces. Library-based programming is supported through a set of COBOL, ALGOL, or C

procedures known as XATMI. Open Distributed Transaction Processing XATMI is based on Open Group’s DTP XATMI interface, and is a core part of the overall DTP Distributed Transaction Processing model. You can use XATMI procedures to send a named service request from one application component to another.

(24)

The following table gives a summary of the Open Distributed Transaction Processing communication programming functions:

Request-Response Conversational TPCALL TPACALL TPGETRPLY TPRETURN TPCONNECT TPSEND TPRECV TPDISCONN

Open Distributed Transaction Processing XATMI communication interfaces support two general programming models: synchronous and asynchronous request-response and conversations.

Transaction Demarcation (TX) Interface

The Open Distributed Transaction Processing XATMI communication interfaces provide flexible mechanisms for distributed application components to exchange service requests and data. Open Distributed Transaction Processing also supports a transaction demarcation interface that enables work done by distributed services to be bounded by a global transaction. The three fundamental functions are TXBEGIN, TXCOMMIT, and TXROLLBACK, as defined by the DTP TX interface.

The TXBEGIN function defines the beginning of a global transaction. When a client calls TXBEGIN, Open Distributed Transaction Processing creates a global transaction identifier to associate with subsequent requests issued by the client—for example, TPCALL and TPACALL requests. As calls are made to services, the transaction identifier and related context is propagated. Eventually, the client will want to complete the computation and, all being well, will invoke TXCOMMIT. If the client detects a failure—for example an adverse return from a TPCALL—it will invoke TXROLLBACK. The commit and rollback functions alert Open Distributed Transaction Processing to the client request to complete the transaction, either coordinating the commitment of all resource manager updates or directing them to roll back. The Open Distributed Transaction Processing Transaction Manager interacts with the participating resource managers to complete the coordination protocol. Of course, if Open Distributed Transaction Processing detects a failure outside the scope of client initiator, it will force a rollback and alert the client. XATMI is both powerful and flexible. The API set allows the development of distributed application components that communicate through a rich set of communications functions. The TX API adds the transaction semantics to glue the application

components together for true mission-critical applications. You can use synchronous, asynchronous, and conversational mechanisms singly and in combination to structure the simplest through the most complex distributed applications. XATMI masks the network, providing location transparency and easy access to deployed server components and the services they advertise.

(25)

Section 3 Open Distributed Transaction

Processing

MCP software releases contain deliverables that are required to build, run, and manage client/server distributed transaction applications.

Figure 3–1 shows the primary components that enable Open Distributed Transaction Processing.

(26)

Open Distributed Transaction Processing

The elements of the foregoing diagram include • Applications programs

• Language Interfaces

• Desktop Agent and BEA Tuxedo Workstation • Transaction Server

• Transaction Manager • Enterprise Database Server

• OSI-TP

Application Programs

Application programs (APs) are the site-developed client and server processes. These applications provide the user interface, request and provide services, and apply the business rules to the computer-based business operations. Typically clients are

responsible for interacting with users; servers are responsible for opening, updating, and closing the resource managers (databases).

Client Applications

Client application programs can be located on a desktop workstation, can be Web based or—in the MCP environment—Transaction Server based (that is, using a Remote File or a Direct Window application), or initiated outside of the Transaction Server environment. XATMI services are always managed by Transaction Server. You can develop new server applications by using Enterprise Application Environment, COBOL74, COBOL85, C, and ALGOL. You can also adapt existing Transaction Server applications to be used as servers with little or no modification, if they conform to the Open Distributed Transaction Processing guidelines.

More Information

For details on developing a client or server application for Open Distributed Transaction Processing, see the Open Distributed Transaction Processing Programming Guide.

Language Interfaces

You can write application programs in the MCP environment by using the COBOL85, COBOL74, ALGOL, and C languages. The COBOL85 and C language shells provided by Open Distributed Transaction Processing reduce the programming effort required to implement applications.

(27)

With the exception of C, you can use the following interfaces with all of these languages:

• Enterprise Database Server native interface • Transaction Server native interface

• TX

• XATMI

C can use the TX interface and (through Transaction Server) the XATMI interface.

Desktop Agent and Workstation

The Workstation component supplies the XATMI and TX interfaces to desktop

applications. It works in conjunction with the Desktop Agent (DA) and the Desktop Agent protocol-specific handler (DA PSH) (both in the MCP environment) to access services that have been implemented for the MCP environment. For a single transaction, each copy of the DA program acts as an MCP client application program on behalf of a single transactional desktop client application program.

Transaction Server

The Transaction Server implements in the MCP environment the CRM function of the Open DTP model. As such, Transaction Server connects a client application with a server and service. The CRM

• Routes service calls from the client to the appropriate server.

• Transforms data so that data transferred between client and server is machine dependent.

• Works with the transaction manager to coordinate transaction commitments.

More Information

For information about the CRM function in the Open DTP model, see Appendix A, “Standards on Which Open Distributed Transaction Processing Products Are Based.”

Transaction Manager (TM)

The primary function of the TM is to manage global transactions. Application programs (clients) define a global transaction by calling TXBEGIN and TXCOMMIT/TXROLLBACK TX calls. The TM directs resource managers to either apply their part of the global transaction or roll it back. The TM implements the industry standard XA interface to accomplish this.

(28)

More Information

For details about the TM functions of the Open Group model, see Appendix A,

“Standards on Which Open Distributed Transaction Processing Products Are Based.”

Enterprise Database Server

The Enterprise Database Server implements in the MCP environment the RM in the Open Group model. As such, Enterprise Database Server handles the two-phase commit protocol (XA interface) that allows the synchronization between multiple databases.

More Information

For details about the RM functions in the Open Group model, see Appendix A, “Standards on Which Open Distributed Transaction Processing Products Are Based.” See also the Open Distributed Transaction Processing Programming Guide for some Enterprise Database Server considerations.

OSI-TP

Open Systems Interconnection Transaction Processing (OSI-TP) is an optional product that provides interoperability and distributed transaction processing services. OSI-TP enables local clients and servers to interact with remote servers and clients to perform both global and nonglobal transactions. Open Distributed Transaction Processing TMs and communications resource managers (CRMs) rely on OSI-TP to establish and terminate dialogues between TMs, to send and receive messages, and to coordinate commitment and rollback processing with other systems. This product makes it possible to distribute Open Distributed Transaction Processing applications across both

homogeneous and heterogeneous platforms.

More Information

For details about the OSI-TP functions in the Open Group model, see Appendix A, “Standards on Which Open Distributed Transaction Processing Products Are Based.”

(29)

Section 4 Open Distributed Transaction

Processing Library

To choose the Open Distributed Transaction Processing documents you should be familiar with, you need to know what tasks belong with what job description and in which documents the tasks belonging to your job description can be found.

Task and Documentation Summary

The following tables list the major tasks required to implement Open Distributed Transaction Processing software and applications in an MCP environment. For each task, the corresponding Open Distributed Transaction Processing documentation is listed.

Installing Open Distributed Transaction Processing Software

The following table lists the tasks required for installing Open Distributed Transaction Processing for the MCP environment.

Task Reference

Install the TM software Open Distributed Transaction Processing Installation and Administration Guide Install the OSI-TP software Open Distributed Transaction

Processing Installation and Administration Guide Install the CRM software Open Distributed Transaction

Processing Installation and Administration Guide Install the two-phase commit

software

Open Distributed Transaction Processing Installation and Administration Guide

(30)

Open Distributed Transaction Processing Library

Developing Application Programs

The following tables list the tasks required for developing application programs for Open Distributed Transaction Processing.

Define VIEW entities Open Distributed Transaction Processing Installation and Administration Guide Open Distributed Transaction Processing Programming Guide

Declare the TX interface Open Distributed Transaction Processing Programming Guide

Declare the XATMI interface Open Distributed Transaction Processing Programming Guide

Create a server program Open Distributed Transaction Processing Programming Guide

Configure the application program to Transaction Server

Open Distributed Transaction Processing Installation and Administration Guide

Perform Ongoing Administration

The following tables list the tasks required for performing ongoing administration for Open Distributed Transaction Processing software and application programs.

Administer the TM Open Distributed Transaction Processing Installation and Administration Guide Administer the CRM Open Distributed Transaction Processing

Installation and Administration Guide Administer the OSI-TP Open Distributed Transaction Processing

Installation and Administration Guide

Documents for System Administrators

System administrators perform the following tasks:

• Install the Open Distributed Transaction Processing software. • Define VIEW entities.

• Configure the application program to the Transaction Server.

(31)

The following documents are designed for system administrators on MCP systems: • Open Distributed Transaction Processing Technical Overview

• Open Distributed Transaction Processing Installation and Administration Guide

This guide introduces the Open Distributed Transaction Processing product and describes the procedures for installing, configuring, and administering the software product.

Documents for Application Developers

Application developers perform the following tasks: • Declare the TX interface.

• Declare the XATMI interface. • Create a server program.

The following documents are designed for application developers on MCP systems: • Open Distributed Transaction Processing Technical Overview

• Open Distributed Transaction Processing Programming Guide

This guide provides a conceptual and procedural overview of how to develop Open Distributed Transaction Processing application programs on MCP systems. Topics covered in this document include overviews of the Open Distributed Transaction Processing transaction manager, TX Application Programming Interface, XATMI Application Programming interface, and relevant programming language concerns. This document refers readers to two cross-platform documents for extensive detailed information.

• Open Distributed Transaction Processing TX Application Program Interface Programming Guide

This guide describes the Open Distributed Transaction Processing TX Application Programming Interface (API), which application programs use to begin, end, and direct global transactions. In particular, this guide describes the concepts and components of the Open Group DTP model and related terminology, global transactions, timeouts, chaining, and other attributes of the TX API. It explains and provides examples of how to use the TX functions to perform the tasks of beginning, ending, and directing global transactions. This guide also provides language-specific reference information for each function in the TX service library.

(32)

• Open Distributed Transaction Processing XATMI Application Program Interface Programming Guide

This guide describes the Open Distributed Transaction Processing XATMI application program interface (API), which application programs (AP) use to communicate with other APs in the network through the communication resource manager (CRM). In particular, this guide describes the concepts and components of the Open Group DTP model and related terminology, the client/server communications model, request-response and conversational programming models, and attributes of the XATMI API. It explains and provides examples of how to use the XATMI functions to communicate with the CRM to perform various tasks. This guide also provides language-specific reference information for each function in the XATMI service library.

• Transaction Server Configuration Guide

This guide provides an overview of the basic concepts and functions of Transaction Server. It includes instructions for creating a working Transaction Server

configuration and information on how to monitor and fine-tune Transaction Server system performance.

(33)

Appendix A

Standards on Which Open Distributed

Transaction Processing Products Are

Based

In its Open Distributed Transaction Processing products, Unisys supports two established distributed transaction processing standards.

• The Open Group distributed transaction processing (DTP) model • OSI Transaction Processing (OSI-TP) protocols and services

The Open Group Distributed Transaction

Processing (DTP) Model

The Open Group is a private international consortium of vendors and users who are working together on models and standards for open systems. The DTP model is the Open Group general framework for conducting distributed transaction processing. It identifies software components that support distributed transaction processing and specifies how those components interact. A major goal of the DTP model is to guide computer system vendors in the creation of transaction processing environments that meet the stringent requirements identified previously in this section.

Open Distributed Transaction Processing products are based on the Open Group DTP model and other relevant standards. For more information about the model, see the Open Group Distributed TP Reference Model.

Implementations of the DTP Model

The Open Group DTP model is not a complete blueprint for building software products. Rather, it is a common point of reference toward which products like Open Distributed Transaction Processing aim. Different implementations might meet the requirements of the model in different ways. In addition, real-world products must perform many functions that are not addressed by the model.

(34)

Standards on Which Open Distributed Transaction Processing Products Are Based

Building Blocks of the DTP Model

The DTP model works by defining the building blocks that make up a DTP system. There are two kinds of building blocks:

Components

Software entities that make up a transaction processing system. Components include application programs that users develop and system software components that vendors supply.

Interfaces

Sets of functions that enable components to communicate and interact. The DTP model defines interfaces that application programs use to communicate with each other and define transactions. It also defines interfaces that system software components use to interact with each other and process transactions.

Components

Components that support the appropriate Open Group DTP interfaces can interoperate with one another, regardless of who built them.

Figure A–1 shows the functional components and interfaces of the DTP model. This model is sometimes referred to as the four-box model.

Figure A–1. Components and Interfaces of the DTP Model

One set of these four boxesÄÄan application program and its associated DTP system componentsÄÄis called an instance of the model. In a global transaction, two or more instances of the model work together to complete the transaction. Different instances of the model can reside on the same machine or on different machines in the network.

(35)

Application Program (AP)

An application program is a user-written component that performs one or more specific tasks. Application programs define global transaction boundaries, access resource managers, and request work from other application programs. An application program interacts with other system components using interfaces defined in the model. In the Open Distributed Transaction Processing and BEA Tuxedo implementations of the Open DTP model, application programs are partitioned into well-defined modules called client programs, server programs, and service routines.

• Client programs are modules that send service requests and occasionally update databases directly. Client programs contain user interface components, some application logic, and occasionally, data management components. Client programs can be implemented as Windows applications, Web pages, Java applets (displayed in browsers), and in other ways.

• Server programs are modules that dispatch service routines to satisfy requests from client programs.

• Service routines are server subprograms that contain data management components and some application logic.

Client programs and server programs (together with associated service routines) can be located on different machines or the same machine. In this discussion, client programs, server programs, and service routines are sometimes referred to as application programs (for readability and simplicity).

Resource Manager (RM)

Resource managers are system software components, such as databases or file access systems that provide access to resources. To qualify as an Open Group compliant RM, a software component must support the XA interfaceÄÄa set of system-level functions that RMs and transaction managers use to communicate with one another during global transactions. Examples of RMs are Informix Online, Oracle, SQL Server, and Enterprise Database Server databases.

A single instance of the Open DTP model can include multiple RMs.

Transaction Manager (TM)

A transaction manager is a system software component that manages global transactions on behalf of application programs. TMs coordinate commands from application programs and communications resource managers to start and complete global transactions by communicating with all RMs participating in those global transactions.

The TM is different from a transaction monitor (like Transaction Server) that schedules programs, routes messages, and so on. On MCP systems, the TM is implemented as a separate component.

(36)

Communications Resource Manager (CRM)

A communications resource manager is a system software component that enables one instance of the model to communicate with another instance of the model. The CRM handles communication between the different application programs engaged in a global transaction. It also enables communication between TMs on different systems.

Interfaces

In the Open Group DTP model, application programs conduct global transactions using interfaces that system software components provide. These interfaces include

• SQL and other AP-RM interfaces • TX interface

• XATMI interface

SQL and Other AP-RM Interfaces

Application programs use these interfaces to access resources. Examples of interfaces between application programs and resource managers (RM) include the Structured Query Language (SQL) and the indexed sequential access method (ISAM). The interface used in any particular case is defined by the requirements of the RM rather than by the Open Group DTP model. However, the use of standardized interfaces such as SQL enhances application program portability.

TX Interface

Application programs use the TX interface to define global transaction boundaries. The Open Group TX specification defines the functionality and behavior of this interface.

XATMI Interface

Client programs and server programs (service routines) use the XATMI interface to communicate during global and nonglobal transactions. The following kinds of communication are supported:

• Synchronous request-response. A client sends a service request and waits for a reply from the server.

• Asynchronous request-response. A client sends a service request and later asks for a reply from the server. The client may request other services or perform other work before obtaining the reply.

• Conversational. A client establishes a logical connection with a server and conducts a dialog with that server. Dialogs are half-duplex; one program sends and the other receives. During conversations, clients and servers can exchange the sending and receiving roles.

(37)

Transaction Internet Protocol (TIP) Interface

The TIP provides support for the Transaction Internet Protocol (TIP – RFC 2371) for interaction with platforms that support this protocol. It provides a direct protocol between TMs executing on different platforms. The TM uses this protocol to import, export, and manage transactions with diverse execution environments. Several middleware products use this protocol.

OSI-TP Distributed Transaction Processing

Protocols and Services

The four-box picture of the Open Group DTP model as described in Figure A–1 is incomplete in one respect. It does not show how different instances of the model communicate with one another when they reside on different machines. As shown in Figure A–2, a fifth box is necessary. For communication between different systems, the Open Group DTP model supports communication protocols and services that are defined in the International Organization for Standardization (ISO) OSI-TP standard.

Figure A–2. The DTP Model and OSI-TP

Although OSI-TP and the Open Group DTP model were developed by different standards organizations, they are compatible and complementary. Generally speaking, the Open Group model defines the application side of the distributed transaction processing environment, while the OSI-TP standard defines the network side.

(38)

The OSI-TP Standard

The OSI-TP standard (ISO 10026), completed in 1992, defines protocols and services that computer systems in networks use to

• Establish and terminate dialogs between application programs. • Exchange data.

• Coordinate processing.

• Manage the completion and recovery of global transactions.

OSI-TP is actually an umbrella term for a collection of standards that support a broad set of transaction processing requirements.

Unisys implementations of OSI-TP support the ISO/IEC 10026-3 standard. This standard describes services and protocols that are tailored specifically for the Open Group XATMI specification.

These services and protocols enable Open Group compliant system software (namely, transaction managers and communications resource managers) to

• Initiate and accept or reject remote service requests inside and outside global transactions.

• Send and receive data across networks.

• Prepare, commit, and roll back global transactions.

Relationship to Networking Protocols

As the name suggests, OSI-TP can be implemented in OSI networks. However, many organizations do not have OSI networks and have no plans to adopt them. Unisys addresses this problem by making OSI-TP available for all supported networks: • OSI

• Transmission control protocol/internet protocol (TCP/IP)

More specifically, OSI-TP, together with OSI presentation and session protocols, can be implemented on top of other transport (and lower) protocols.

Model of a Global Transaction

How do user application programs, Open Group DTP components, and OSI-TP components interact during a global transaction? The following example shows how a travel agent in one city could use a network of Open Distributed Transaction Processing application programs to book an airline flight and reserve a rental car in a single global transaction.

(39)

Systems in the Transaction

Figure A–3 shows the systems involved in the example global transaction.

(40)

Explanation

In the example, each instance of the DTP model (each set of four boxes) represents a separate node in the Open Distributed Transaction Processing network.

Minneapolis

This is the node where the travel agent is located. The application program in the Minneapolis node is the client program in this global transaction because it begins the global transaction and requests services from the application programs in the other nodes. The client program could be implemented as a standalone Windows application, a Web page, a Java applet (displayed in a browser), and in other ways.

Chicago

This is the node where the airline reservation application and database are located. The application program in the Chicago node is a server program in this global transaction because it receives the request for airline reservations from the client in the Minneapolis node. The airline reservation database is a resource manager (RM) accessed by the server program.

New York

This is the node where the car rental application and database are located. The

application program in the New York node is a server program in this global transaction because it receives the request for a car rental from the client in the Minneapolis node. The car rental database is an RM accessed by the server program.

To emphasize that clients and servers are both considered application programs in the DTP model, the figure shows the same set of components in each node. In the case of the Minneapolis node, it is entirely possible for a client program to access a local RM directly as part of a global transaction. For example, the Minneapolis RM might maintain trip history information on the travel agency’s clients. To simplify the example, however, only the RMs accessed by the two server programs will be discussed in the rest of this subsection.

(41)

Steps in the Transaction

Figure A–4 shows the steps involved in completing the example global transaction.

(42)

Explanation

1. The client program in Minneapolis begins the global transaction by calling its TM. 2. The client program in Minneapolis sends a separate request for services for each

part of the transaction (the airline reservation and the car rental). Each service request passes through the CRM and OSI-TP in the Minneapolis node and is forwarded to the appropriate node. When it reaches the destination node, the service request passes through OSI-TP and the CRM to the server program that actually performs the work.

3. The server programs in Chicago and New York book the airline reservation and reserve the rental car by updating RMs (databases) on their respective systems. When they have completed their parts of the global transaction, the server programs send confirmations to the client program in Minneapolis by way of the CRM and OSI-TP components in their respective nodes.

4. The client program in Minneapolis instructs its TM to commit the global transaction. Using the two-phase commit protocol, the TMs and the RMs involved in the transaction guarantee that both databases are committed or rolled back together. That is, either both portions of the global transaction succeed or both are rolled back.

Two-Phase Commitment Process

The two-phase commitment process is an essential part of global transactions. In the travel agent example, you do not want to rent the car if you cannot get the airline reservation. To synchronize and coordinate commitment processing, so that RMs in Chicago and New York commit their parts of the global transaction on an all-or-nothing basis, Open Group components and OSI-TP components use the two-phase commit protocol.

When the application program in Minneapolis determines that the global transaction is ready to be completed, it instructs its TM to commit the work. The TM in Minneapolis is in charge of the commitment process from then on.

Details of the Commitment Process

In the example, the TM in Minneapolis coordinates the commitment processing performed by the TMs in Chicago and New York. The TMs in Chicago and New York carry out the commitment processing for their respective RMs. The following figure shows a close-up of the communication between a single RM and its associated TM during the two phases of the commitment process (this figure applies equally to the Chicago and New York nodes).

(43)

Figure A–5 shows the commitment process and how all the TMs in the example network work together to commit the global transaction.

Figure A–5. Two-Phase Commit Protocol

Explanation

Prepare phase

1. The TM in Minneapolis begins the prepare phase by sending a prepare to commit command to the global transaction participants: the nodes in Chicago and New York. These commands are routed through the respective CRMs and OSI-TP to the TMs in each city. The TMs in Chicago and New York, in turn, send prepare-to-commit commands to their respective RMs (the databases that were updated for the airline and car rental reservations).

2. In response to the prepare-to-commit commands, the RMs in Chicago and New York secure their database updates on stable storage and then report to their respective TMs that they are ready to commit. In turn, the TMs in Chicago and New York report this information to the TM in Minneapolis.

Commit phase

3. When it has determined that the RMs in Chicago and New York are ready to commit, the TM in Minneapolis begins the commit phase by sending its commit commands to the TMs in Chicago and New York. Each of these TMs, in turn, sends a commit command to its RM.

4. The RMs commit their database updates and send confirmations through their respective TMs to the TM in Minneapolis. The TM reports to the client application in Minneapolis that the RMs have been successfully committed.

An RM Is Unable to Commit

If either RM responds negatively (or not at all) at the end of the prepare phase, the TM in Minneapolis directs both RMs to roll back their updates. Then the TM reports to the client program that the commitment requested by the client program failed. In this way, all portions of the global transaction either succeed or fail together.

(44)

(45)

Index

A

application developers, MCP documents for, 4-3

application program interface (API) defined, 2-11

TX, 2-12 XATMI, 2-11 application programs

defined, 3-2

defined by DTP model, A-3

role in global transaction, A-8, A-10 applications

client functions, 3-2 AP-RM interface

defined by DTP model, A-4 examples of, A-4

architecture, Open Distributed Transaction Processing, 2-10

asynchronous communications, 2-7

C

client applications, functions, 3-2 client programs

client role, 2-2 defined, 2-2 interfaces, 2-3 structure, 2-3

user interfaces and, 2-2 client role, 2-2

client/server communication methods, 2-5 Open Distributed Transaction

Processing, 2-1 client/server paradigm advantages, 2-11 client request, 2-10 diagram, 2-10 explanation, 2-10 commitment process

in global transaction, A-10

role of application program in, A-10

role of Resource Manager, A-10 role of Transaction Manager in, A-10 when rollback occurs, A-11

communication

conversational method, 2-6, 2-8 request-response method, 2-6 communications programming interface

(XATMI), 2-11

conversational communications, A-4 request-response communications, A-4 Communications Resource Manager (CRM)

defined by DTP model, A-4 functions, 3-3

role in global transaction, A-10

components, Open Distributed Transaction Processing system, 3-1

conversational communications benefits of, 2-9

defined, 2-8 example of, 2-8

CRM (See Communications Resource Manager)

D

DA (See Desktop Agent)

DA PSH (See Desktop Agent protocol-specific handler)

database management systems, service routines and, 2-4

Desktop Agent (DA), role, 3-3

Desktop Agent protocol-specific handler (DA PSH), 3-3

documentation

application developers, 4-3

Open Distributed Transaction Processing tasks, 4-1

system administrators, 4-2 DTP model

figure, A-2

implementation of

in different products, A-1 interfaces, A-2

(46)

Index

E

Enterprise Database Server, as Resource Manager, 3-4, A-3

G

global transactions example of, A-7

role of DTP model components in, A-7

I

Informix databases, as Resource Manager, A-3 interfaces, language, 3-2

L

language interfaces, 3-2

M

middleware, definition, 1-1

O

Open Distributed Transaction Processing architecture overview, 2-10

client programs used in, 2-2 client/server infrastructure, 2-1 client/server paradigm, 2-1 communications methods, 2-5 components, 3-1 defined, 1-1 features, 1-1

Open Group view of, A-1 servers used in, 2-3

service routines used in, 2-4 Open Group consortium, A-1 OSI-TP

defined by ISO 10026, A-6 network interoperability, A-6 relationship to DTP model, A-5

R

request-response communications asynchronous, 2-7 benefits of, 2-8 defined, 2-6 example of, 2-6 synchronous, 2-7 Resource Manager (RM)

defined by DTP model, A-3 examples of, A-3

functions, 3-4

role in global transaction, A-10 RM (See Resource Manager)

S

server programs components of, 2-4 creating, 2-4 defined, 2-3 request processing, 2-5 service requests, 2-3 service routines, 2-4, 2-5 XATMI standard and, 2-3 service requests

server programs and, 2-3 service routines and, 2-5 service routines

acting as client programs, 2-2 defined, 2-4

interfaces available to, 2-5 manipulating databases with, 2-4 relationship with server programs, 2-3 service requests and, 2-5

structure of, 2-5

standards, Open Group Distributed Transaction Processing, A-1 synchronous communications, 2-7 system administrators

documentation, 4-2 tasks for MCP servers, 4-2

T

tasks, documentation for implementing Open Distributed Transaction

Processing, 4-1

(47)

Index

TM (See Transaction Manager) transaction demarcation (TX)

interface

defined by DTP model, A-4 Transaction Internet Protocol (TIP), A-5 Transaction Manager (TM)

comparison with transaction monitors, A-3 defined by DTP model, A-3

functions, 3-3

role in global transaction, A-10 transaction monitors, comparison with

Transaction Manager, A-3

Transaction Server, as the Communications Resource Manager, 3-3

Transmission Control Protocol/Internet Protocol (TCP/IP), with OSI-TP, A-6 two-phase commit protocol, example of, A-10 TX (See transaction demarcation)

U

user interfaces, 2-2

W

workstation environment, 3-3

X

XATMI (See communications programming interface)

(48)

(49)

(50)