![]() |
![]() |
![]() |
![]() |
![]() |
Figure 2‑1 illustrates the basic architectural elements of an Oracle Tuxedo ATMI environment: external interfaces to the environment, the ATMI layer, the MIB, Oracle Tuxedo system services, and the environment’s interface with standards-compliant resource managers.Figure 2‑1 The Oracle Tuxedo ATMI Basic ArchitectureAs shown in this illustration, the Oracle Tuxedo ATMI environment contains the following components:
The MIB is an interface that enables users to program and administer an Oracle Tuxedo ATMI environment easily. MIB operations enable users to perform all management tasks (monitoring, configuring, tuning, and so on). The MIB allows users to perform one task to one object at a time or to build toolkits with which to batch tasks and/or objects. For information about the MIB and the MIB interface, see “Oracle Tuxedo Management Tools” on page 4‑1. The application processing services available to Oracle Tuxedo developers include data compression, data-dependent routing, data encoding, data encryption, data marshalling, load balancing, message prioritization, and service and event naming. These services are described in the discussions that follow.The system administration processes that provide the administrative services are described in “Oracle Tuxedo System Administration and Server Processes” on page 3‑1 and “Oracle Tuxedo Management Tools” on page 4‑1. Figure 2‑2 shows the using of the ATMI.Figure 2‑2 Using the ATMIThe ATMI functions knit together distributed programs by enabling them to send and receive data. All ATMI functions send or receive data in typed buffers.Table 2‑1 presents a list of ATMI functions for C and COBOL bindings, and the tasks they perform. The functions are grouped by task.
Table 2‑1 Using the ATMI Functions
Note: The use of the Oracle Tuxedo ATMI transaction management functions is optional. Because Oracle Tuxedo also supports the X/Open TX transaction management functions, you may want to use those functions for transaction management.
• “Using ATMI to Handle System and Application Errors” in Administering a Oracle Tuxedo Application at Run Time
Request/response communication Asynchronous routing of events among the clients and servers in an Oracle Tuxedo ATMI application. Publish-and-subscribe transactions usually run as high-priority messages. The Oracle Tuxedo system has a transactional publish-and-subscribe system called EventBroker. Figure 2‑3 shows the synchronous request/response communication.Figure 2‑3 Synchronous Request/Response CommunicationIn an asynchronous call, the Oracle Tuxedo client does not wait for a service request it has submitted to finish before undertaking other tasks. Instead, after issuing a request, the client performs additional tasks (which may include issuing more requests). When a reply to the first request is available, the client retrieves it.Figure 2‑4 shows the asynchronous request/response communication.Figure 2‑4 Asynchronous Request/Response CommunicationFigure 2‑5 shows the conversional communication.Figure 2‑5 Conversational CommunicationThe Oracle Tuxedo system offers a queue-based architecture known as /Q for ATMI applications that require persistent storage of data. The /Q component allows any client or server to store messages or service requests in queues and guarantees that any stored request is sent through the transaction protocol to ensure safe storage.Oracle Tuxedo system queues can be ordered as last in, first out (LIFO) or first in, first out (FIFO), or on the basis of time or priority. A collection of queues is administered and referred to as a single entity known as a queue space.Figure 2‑6 shows the queue-based messaging.Figure 2‑6 Queue-Based MessagingThe Oracle Tuxedo publish-and-subscribe component, known as EventBroker, provides a communication paradigm in which an arbitrary number of suppliers can post messages for an arbitrary number of subscribers. ATMI client and server processes using EventBroker communicate with one another based on a set of subscriptions. EventBroker acts like a newspaper delivery person who delivers newspapers only to customers who have paid for a subscription.Figure 2‑7 shows the posting and subscribing to and event.Figure 2‑7 Posting and Subscribing to an EventFigure 2‑8 shows the event-based messaging.Figure 2‑8 Event-based MessagingThe Oracle Tuxedo system offers a powerful communication paradigm called unsolicited notification. When unsolicited notification occurs, an ATMI client receives a message that it has never requested. This capability, which is managed by EventBroker, makes it possible for application clients to receive notification of application-specific events as they occur, without having to request notification explicitly in real time.Unsolicited messages can be sent to client processes by name (tpbroadcast) or by an identifier received with a previously processed message (tpnotify). Messages sent via tpbroadcast can originate either in a service or in another client. You can target a narrow or wide audience. You can send a message with or without guaranteed delivery to an individual client through point-to-point notification (tpnotify), or you can send information to a group of clients (tpbroadcast). For example, a server may alert a single client that the account about which the client is inquiring has been closed. Or, a server may send a message to all the clients on a machine to remind the users that the machine will be shut down for maintenance at a specific time.Figure 2‑9 shows the unsolicited notification messaging.Figure 2‑9 Unsolicited Notification MessagingAny process that wants to be notified about a particular event (such as a machine being shut down for maintenance) can register a request, with the system, to be notified automatically. Once registered, a client or server is informed whenever the specified event occurs. This type of automatic communication about an event is called unsolicited notification.
• “Using the Request/Response Model (Synchronous Calls)” in Tutorials for Developing Oracle Tuxedo ATMI Applications
• “Using Conversational Communication” in Tutorials for Developing Oracle Tuxedo ATMI Applications
• “Using Queue-based Communication” in Tutorials for Developing Oracle Tuxedo ATMI Applications
• “Using Event-based Communication” in Tutorials for Developing Oracle Tuxedo ATMI Applications
• “Using Unsolicited Notification” in Tutorials for Developing Oracle Tuxedo ATMI ApplicationsNested and forwarded service requests allow Oracle Tuxedo services to act as ATMI clients and call other services.Figure 2‑10 shows the nested requests.Figure 2‑10 Nested Service RequestsA customer uses a cash machine to transfer money from his or her savings account to her checking account. An Oracle Tuxedo application performs the work necessary to transfer the money. First, on behalf of the customer, the client issues a request for a service called TRANSFER, and the request is placed on a queue for a server that provides that service. Next, the TRANSFER service requests two other services, WITHDRAW and DEPOSIT, which are processed by a second server. The WITHDRAW and DEPOSIT services return responses to the TRANSFER service. Finally, TRANSFER sends a response to the client’s response queue. When the client retrieves the response from the queue, the system displays a message on the screen of the cash machine, notifying the customer that the transfer is complete.Figure 2‑11 shows the forwarded service requests.Figure 2‑11 Forwarded Service Requests
• “Using Nested Calls” in Tutorials for Developing Oracle Tuxedo ATMI Applications
• “Using Forwarded Calls” in Tutorials for Developing Oracle Tuxedo ATMI ApplicationsAll communication within the Oracle Tuxedo ATMI environment is accomplished by transferring messages. The Oracle Tuxedo system passes service request messages between ATMI clients and servers through operating system (OS) interprocess communications (IPC) message queues. System messages and data are passed between OS-supported, memory-based queues of clients and servers in buffers. In the Oracle Tuxedo ATMI environment, messages are packaged in typed buffers, buffers that contain both message data and data identifying the types of message data being sent.Figure 2‑12 shows the processing of a request.Figure 2‑12 Processing a RequestA client uses an ATMI function to request a service by name. A naming facility is used to check the MIB to determine whether the specified service is currently available.The Oracle Tuxedo system uses data-dependent routing, which is an automatic routing option to map messages that meet specific criteria (message value) to a specific server. If messages use data-dependent routing, the system uses the data in the buffer for the routing algorithm. This algorithm provides a method of selecting a group of servers that can process the service request.A local service request may be prepared for a selected server and enqueued on that server’s queue with a predefined priority. This practice is called service prioritization. Once the service request is on the server, the run-time system retrieves the message in priority order. The message is dispatched to the appropriate service and processed. Then the results are returned to the client queue.The service routine is executed and returns a reply (also a typed buffer). The run-time system prepares the reply for the client by encoding the message automatically: it packages the data in such a way that it can be transmitted between machines on which different types of byte ordering are used, allowing data to cross network and platform boundaries. The system then sends the message to the client. This process is called data encoding. The run-time system on the client retrieves the reply message, decodes it if necessary, and delivers the Field Manipulation Language (FML) buffers (or buffers of another message buffer type) to package the application data. Type validation, encoding, routing, and load balancing are performed as required. Service requests can be performed synchronously or asynchronously.A buffer is a memory area that serves as a logical container for data. When a buffer contains no metadata (that is, no information about itself), it is an untyped buffer. When a buffer includes metadata such as information that can be stored in it (for example, a type and subtype, or string names that characterize a buffer), it is a typed buffer.
•
•
•
•
•
• You assign buffer types in the ENVFILE parameter defined in the MACHINES section of the Oracle Tuxedo (UBBCONFIG) configuration file. Assigning or overriding them in the ENVFILE parameter in the SERVERS section of the Oracle Tuxedo configuration file can make them unavailable to processes that require them.Definitions of the various types of message buffers are provided in the description of tm_typesw in tuxtypes(5) in the Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference.When you use ATMI communication functions, your application must first use tpalloc to get a buffer from the system, specifying its size, type, and optionally subtype. The Oracle Tuxedo system recognizes and processes the buffer type, so that your data is transmitted over any type of network, protocol, and operating system supported by the Oracle Tuxedo system. For descriptions of the different types of Oracle Tuxedo buffers, see “Managing Typed Buffers” in Programming a Oracle Tuxedo ATMI Application Using C.
• tuxtypes(5), typesw(5), and UBBCONFIG(5) in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference.Data compression is the process of shrinking an application buffer so that it can be transmitted more quickly across a network or to a remote domain. By setting a maximum size for an application buffer, you can make sure that compression is triggered automatically for application buffers that match or exceed a specified size. When the buffer arrives at its destination, its data is decompressed, that is, restored to its original size.Figure 2‑13 shows the data compression.Figure 2‑13 Data CompressionA distributed application consists of one or more local or remote clients that communicate with one or more servers on several machines linked through a network. A client (or server acting as a client) issues a request for a particular service. The address of the request is determined by data (carried in the same buffer that conveys the request), identifying the server that can fulfill the request. More than one server may be able to do so. The Oracle Tuxedo system selects a server to receive the request by matching the data to the routing criteria provided in the bulletin board.Figure 2‑14 illustrates this process.Figure 2‑15 illustrates this process.Figure 2‑15 Data-Dependent Routing with Rule-Based ServersFigure 2‑16 shows how client requests are routed to servers in a distributed application. In this example, a banking application called bankapp uses data-dependent routing. bankapp has three server groups (BANK1, BANK2, and BANK3) and two routing criteria (Account ID and Branch ID). The services WITHDRAW, DEPOSIT, and INQUIRY are routed using the Account_ID field; the services OPEN and CLOSE are routed using the Branch_ID field.
Encoding and decoding enable messages with different data representations (for example, byte ordering or character sets) to be transferred between machines. The Oracle Tuxedo system encodes and decodes data to a machine-independent representation for transmission to other machines involved in an Oracle Tuxedo application.The Oracle Tuxedo system uses buffer types to determine the type of fields contained in a message, and to perform the mapping required for coding tasks. This mapping is not performed by unstructured buffer types such as X_OCTET and CARRAY. Thus, developers using X_OCTET and CARRAY buffers are free to deploy in mixed-machine environments.Encryption is the act of converting a message into a coded format that is unintelligible to all users except the user for which the message is intended. When an encrypted message arrives at its destination, it is decrypted, that is, converted back to its original format.Figure 2‑17 illustrates the data encryption.Figure 2‑17 Data EncryptionLoad balancing is a technique used by the Oracle Tuxedo system for distributing service requests evenly among servers that offer the same service. Load balancing avoids overburdening some servers while leaving others idle or infrequently used. Before sending a request to a service routine, the Oracle Tuxedo system identifies all servers capable of handling the request and selects the one most appropriate for maintaining a balanced load across all the servers in the configuration.Load refers to a number assigned to a service request based on the amount of time required to execute that service. Loads are assigned to services so that the Oracle Tuxedo system can understand the relationship between requests. To keep track of the amount of work, or total load, being performed by each server in a configuration, the administrator assigns a load factor to every service and service request. A load factor is a number indicating the amount of time needed to execute a service or a request. On the basis of these numbers, statistics are generated for each server and maintained on the bulletin board on each machine. Each bulletin board keeps track of the cumulative load associated with each server, so that when all servers are busy, the Oracle Tuxedo system can select the one with the lightest load.You can control whether a load-balancing algorithm is used on the system as a whole. Such as algorithm should be used only when necessary, that is, only when a service is offered by servers that use more than one queue. Services offered by only one server, or by multiple servers in a Multiple Server, Single Queue (MSSQ) do not need load balancing. The LDBAL parameter for these services should be set to N. In other cases, you may want to set LDBAL to Y.To determine how to assign load factors (in the SERVICES section of UBBCONFIG), run an application for a long period of time and note the average time it takes to perform each service. Assign a LOAD value of 50 (LOAD=50) to any service that takes roughly the average amount of time. Any service taking longer than average should have a LOAD>50; any service taking less than the average should have a LOAD<50.Figure 2‑18 illustrates the load balancing.Figure 2‑18 Load BalancingFigure 2‑19 illustrates the prioritization of messages.Figure 2‑19 Prioritization of MessagesA “starvation prevention” mechanism prevents low-priority messages from waiting endlessly on the queue. Every tenth message is dequeued in first in, first out (FIFO) order regardless of priority; the first through the ninth messages are dequeued in order of priority.When an Oracle Tuxedo system server is activated, the bulletin board advertises the names of its services. Service names are associated with a server’s physical address so that requests can be routed to that server. Names that programmers use in their applications are completely location transparent. When a client program asks for a service by name, the Oracle Tuxedo system consults its name registry in the bulletin board. The name registry provides the information necessary to convert the string name (for example, TICKET) to a machine name and the physical address of a server that advertises that service. The Oracle Tuxedo system then sends the request to the appropriate server.Figure 2‑20 illustrates the locating of a service by name.Figure 2‑20 Locating a Service by Name
• UBBCONFIG *SERVICES section
• Listing 2 provides a Client/Server Affinity UBBCONFIG example.Listing 2 Client/Server Affinity UBBCONFIG ExampleFor more information, see UBBCONFIG(5) and TM_MIB(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference in the Oracle Tuxedo Reference Guide.