Table of Contents Previous Next PDF


Introduction to Oracle Tuxedo Programming

Introduction to Oracle Tuxedo Programming
This topic includes the following sections:
Oracle Tuxedo Distributed Application Programming
A distributed application consists of a set of software modules that reside on multiple hardware systems, and that communicate with one another to accomplish the tasks required of the application. For example, as shown in Figure 1‑1, a distributed application for a remote online banking system includes software modules that run on a bank customer’s home computer, and a computer system at the bank on which all bank account records are maintained.
Figure 1‑1 Distributed Application Example - Online Banking System
The task of checking an account balance, for example, can be performed simply by logging on and selecting an option from a menu. Behind the scenes, the local software module communicates with the remote software module using special application programming interface (API) routines.
The Oracle Tuxedo distributed application programming environment provides the API routines necessary to enable secure, reliable communication between the distributed software modules. This API is referred to as the Application-to-Transaction Monitor Interface (ATMI).
The ATMI enables you to:
Communication Paradigms
Table 1‑1 describes the Oracle Tuxedo ATMI communication paradigms available to application developers.
 
Refer to Using the ATMI /Q Component for more information on the /Q facility.
Oracle Tuxedo Clients
An Oracle Tuxedo ATMI client is a software module that collects a user request and forwards it to a server that offers the requested service. Almost any software module can become an Oracle Tuxedo client by calling the ATMI client initialization routine and “joining” the Oracle Tuxedo application. The client can then exchange information with the server.
The client calls the ATMI termination routine to “leave” the application and notify the Oracle Tuxedo system that it (the client) no longer needs to be tracked. Consequently, Oracle Tuxedo application resources are made available for other operations.
The operation of a basic client process can be summarized by the pseudo-code shown in Listing 1‑1.
Listing 1‑1 Pseudo-code for a Client
START PROGRAM
enroll as a client of the BEA TUXEDO application
place initial client identification in data structure
perform until end
get user input
place user input in DATA-REC
send service request
receive reply
pass reply to the user
end perform
leave application
END PROGRAM
 
Most of the actions described in the above listing are implemented with ATMI calls. Others—placing the user input in DATA-REC and passing the reply to the user—are implemented with COBOL routines.
An ATMI client may send and receive any number of service requests before leaving the application. The client may send these requests as a series of request/response calls or, if it is important to carry state information from one call to the next, by establishing a connection to a conversational server. In both cases, the logic in the client program is similar, but different ATMI calls are required for these two approaches.
Before you can execute an ATMI client, you must run the buildclient -C command to compile it and link it with the Oracle Tuxedo ATMI and required libraries. Refer to “Writing Clients” on page 4‑1 for information on the buildclient(1) command.
Oracle Tuxedo Servers
An Oracle Tuxedo ATMI server is a process that provides one or more services to a client. A service is a specific business task that a client may need to perform. Servers receive requests from clients and dispatch them to the appropriate service subroutines.
Basic Server Operation
To build server processes, applications combine their service subroutines with a controlling program provided by the Oracle Tuxedo system. This system-supplied controlling program is a set of predefined routines. It performs server initialization and termination and places user input in data structures that can be used to receive and dispatch incoming requests to service routines. All of this processing is transparent to the application.
Figure 1‑2 summarizes, in pseudo-code, the interaction between a server and a service subroutine.
Figure 1‑2 Pseudo-code for a Request/Response Server and a Service Subroutine
After initialization, an ATMI waits until a request message is delivered to its message queue, dequeues the request, and dispatches it to a service subroutine for processing. If a reply is required, the reply is considered part of request processing.
The conversational paradigm is somewhat different from request/response, as illustrated by the pseudo-code in Figure 1‑3.
Figure 1‑3 Pseudo-code for a Conversational Service Subroutine
The Oracle Tuxedo system-supplied controlling program contains the code needed to enroll a process as an ATMI server, advertise services, and dequeue requests. ATMI calls are used in service subroutines that process requests. When you are ready to compile and test your service subroutines, you must link edit them with the server and generate an executable server. To do so, run the buildserver -C command.
Servers as Requesters
If a client requests several services, or several iterations of the same service, a subset of the services might be transferred to another server for execution. In this case, the server assumes the role of a client, or requester. Both clients and servers can be requesters; a client, however, can only be a requester. This coding model is easily accomplished using the Oracle Tuxedo ATMI calls.
Note:
Oracle Tuxedo API: ATMI
In addition to the COBOL code that expresses the logic of your application, you must use the Application-to-Transaction Monitor Interface (ATMI), the interface between your application and the Oracle Tuxedo system.
The ATMI is a reasonably compact set of calls used to open and close resources, begin and end transactions, and support communication between clients and servers. Table 1‑2 summarizes the ATMI calls. Each call is described in the Oracle Tuxedo ATMI COBOL Function Reference.
 

Copyright © 1994, 2017, Oracle and/or its affiliates. All rights reserved.