ClearPath Enterprise Servers

Transcription

1 ClearPath Enterprise Servers Open Distributed Transaction Processing Technical Overview MCP 12.0 April 2008

2 .

3 unisys imagine it. done. ClearPath Enterprise Servers Open Distributed Transaction Processing Technical Overview MCP 12.0 April

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. Unisys and ClearPath are registered trademarks of Unisys Corporation in the United States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders.

5 ClearPath Enterprise Servers Open Distributed Transaction Processing Technical Overview MCP 12.0 ClearPath Enterprise Servers Open Distributed Transaction Processing Technical Overview MCP Bend here, peel upwards and apply to spine.

6 .

7 Contents Section 1. Welcome to Open Distributed Transaction Processing Section 2. Using Clients and Servers Client Programs Client Programs and the Client Role Client Program Structure Interfaces for Client Programs Server Programs Handling Service Requests Creating Server Programs Service Routines Processing Requests Service Routine Structure Interfaces for Service Routines Client/Server Communication Methods Request-Response Communications Conversational Communications Advantages of the Client/Server Paradigm Application Program Interfaces Open Distributed Transaction Processing Architecture Overview Supported APIs Section 3. Open Distributed Transaction Processing Application Programs Language Interfaces Desktop Agent and Workstation Transaction Server Transaction Manager (TM) Enterprise Database Server OSI-TP Section 4. Open Distributed Transaction Processing Library Task and Documentation Summary Documents for System Administrators Documents for Application Developers iii

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 Index... 1 iv

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

10 Figures vi

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) To obtain a copy of the PLE, contact your Unisys representative or access the current PLE from the Unisys Product Support Web site: 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 communications options. You can mix and match these in endless combinations

12 Welcome to Open Distributed Transaction Processing

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. CLIENT CLIENT Application Services Server Database Host CLIENT CLIENT Application Services Server Database Figure 2 1. Open Distributed Transaction Processing Application Environment

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 Using Clients and Servers 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 components. Some components are predefined by Unisys and are included with Open

16 Using Clients and Servers 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. Figure 2 3. Open Distributed Transaction Processing Service Routines

17 Using Clients and Servers 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 Using Clients and Servers 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. Figure 2 4. Request-Response Communications

19 Using Clients and Servers Observations Variations 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. 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. Figure 2 5. Asynchronous Communication

20 Using Clients and Servers 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. 3. The server program calls a service routine that performs the requested service

21 Using Clients and Servers Benefits 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. 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 Using Clients and Servers 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 Using Clients and Servers Advantages 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. 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 Using Clients and Servers The following table gives a summary of the Open Distributed Transaction Processing communication programming functions: Request-Response TPCALL TPACALL TPGETRPLY TPRETURN Conversational 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. Figure 3 1. Primary Components of 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 Open Distributed Transaction Processing 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 Open Distributed Transaction Processing 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 Install the TM software Install the OSI-TP software Install the CRM software Install the two-phase commit software Reference Open Distributed Transaction Processing Installation and Administration Guide Open Distributed Transaction Processing Installation and Administration Guide Open Distributed Transaction Processing Installation and Administration Guide 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. Task Define VIEW entities Declare the TX interface Declare the XATMI interface Create a server program Configure the application program to Transaction Server Reference Open Distributed Transaction Processing Installation and Administration Guide Open Distributed Transaction Processing Programming Guide Open Distributed Transaction Processing Programming Guide Open Distributed Transaction Processing Programming Guide Open Distributed Transaction Processing Programming Guide 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. Task Administer the TM Administer the CRM Administer the OSI-TP Reference Open Distributed Transaction Processing Installation and Administration Guide Open Distributed Transaction Processing Installation and Administration Guide 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. Maintain and monitor Open Distributed Transaction Processing operations

31 Open Distributed Transaction Processing Library 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 Library 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 A 1

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. A

35 Standards on Which Open Distributed Transaction Processing Products Are Based 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 A 3

36 Standards on Which Open Distributed Transaction Processing Products Are Based 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. A

37 Standards on Which Open Distributed Transaction Processing Products Are Based 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 A 5

38 Standards on Which Open Distributed Transaction Processing Products Are Based 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 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. A

39 Standards on Which Open Distributed Transaction Processing Products Are Based Systems in the Transaction Figure A 3 shows the systems involved in the example global transaction. Figure A 3. Example Global Transaction Configuration A 7

40 Standards on Which Open Distributed Transaction Processing Products Are Based 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. A