To implement request/response communication between ATMI clients and servers, the Oracle Tuxedo system uses interprocess communication (IPC) message queues. Queues are the key to connectionless communication. Each server is assigned an IPC message queue called a request queue, and each client is assigned a reply queue. Therefore, rather than establishing and maintaining a connection with a server, a client application can send requests to the server by putting those requests on the server’s queue, and then check and retrieve messages from the server by pulling messages from its own reply queue.

The request/response model is used for both synchronous and asynchronous service requests.

• Synchronous Messaging
  
• Asynchronous Messaging
  

Conversational communication is the Oracle Tuxedo system implementation of a human-like paradigm for exchanging messages between ATMI clients and servers. In this form of communication, a virtual connection is maintained between the client and server. Just as in a conversation between two people, a number of messages pass back and forth between the two entities until a conclusion is reached. Over the course of the communication, both sides “remember” the point (or state) of the conversation so that relatively long operations, such as adhoc queries, reports, and file transfers, can be supported. By default, conversational servers are available, but more can be spawned automatically if needed.

The Oracle Tuxedo system provides an API that can be used to create conversations in applications; specifically, to connect clients to servers, to send and receive messages, and to end the conversation.

Figure 2-5 Conversational Communication

Conversations can be nested but performance may be degraded as a result of doing so. Conversations may contain either transactions or service requests as appropriate. Although a conversational service can make service calls and establish conversations, those service calls and conversations cannot be forwarded. A conversation can be within the scope of—and controlled by—a transaction.

The 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 Queue-Based Messaging

Application queues are appropriate if you must communicate in a time-independent fashion. Time-independence is a characteristic of programs that operate independently from one another and do not need to synchronize their communications simultaneously. Time-independent programs synchronize by leaving messages for each other in application queues. Messages can be dequeued in any of several ordering schemes, such as FIFO order, priority order, or time-based order. Oracle Tuxedo client and server programs can enqueue messages and dequeue messages from queues. More than one client and server can access the same queue.

To use an application queue, your program must name the queue to be accessed and the queue space in which it resides. Your application can use more than one queue space and each space can contain more than one message queue.

Because application queues reside on a disk, the availability of stored messages is guaranteed even after machine failures. To determine when the use of application queues is appropriate, you need to determine when time-independent synchronization occurs in your business, for example, in filling orders. Orders can be enqueued to disk and depending on specific order criteria, such as items or shipment location, placed in different queue spaces. Within each queue space, you can determine additional criteria, such as cost, state, and so on.

The 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 Posting and Subscribing to an Event

Event generators (either clients or servers) inform EventBroker of changes and problems as they occur. This process is called posting an event. EventBroker then matches the name of the event to an event name associated with a list of subscribers, and notifies each subscriber on the list of the event.

• Types of Events Reported
  
• How Events Are Reported
  

The 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 Unsolicited Notification Messaging

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

Because there is no limit to the number of clients and servers that may generate events and receive unsolicited notification about such events, the task of managing this category of communication can become complex.

See Also

• 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
• Oracle Tuxedo Message Queuing Servers
• Administering Your Application Queues Using Command-line Utilities
• Using Queue-based Communication in Tutorials for Developing Oracle Tuxedo ATMI Applications
• Oracle Tuxedo Publish-and-Subscribe Servers
• Managing Events Using EventBroker
• Using Event-based Communication in Tutorials for Developing Oracle Tuxedo ATMI Applications
• Using Unsolicited Notification in Tutorials for Developing Oracle Tuxedo ATMI Applications

Nesting works particularly well in a 3-tier client/server architecture (i.e., a system that comprises a presentation logic layer), a business logic layer, and a database layer. In such a system, the presentation layer is used to formulate a request for a particular business function that involves one or more queries to a database.

Figure 2-10 Nested Service Requests

• Benefit of Nested Requests
  
• Example of a Nested Service Request
  

One alternative to nesting service requests is called request forwarding. Instead of processing a client’s request, a service can pass the request to another service. The second service, also, can either process the request or pass it to another service.

Figure 2-11 Forwarded Service Requests

There is no limit to the number of times a request can be forwarded. Because a service that forwards a request does not need to wait for a reply from the service receiving the request, forwarding, unlike nesting requests, does not block servers. Forwarding, however, is not supported by the X/Open protocol X/ATMI, which may be a problem in some applications.

See Also

• Using Nested Calls in Tutorials for Developing Oracle Tuxedo ATMI Applications
• Using Forwarded Calls in Tutorials for Developing Oracle Tuxedo ATMI Applications

The benefits of service request processing include:

• Connectionless processing—this processing, coupled with direct client/server communication, reduces the overhead associated with establishing a connection.
• Reduced network traffic—service requests invoke potentially complex services on remote machines, sending only the minimum data required and receiving minimal results.

See Also

• What Are the Oracle Tuxedo ATMI Messaging Paradigms?
• What Are Typed Buffers?

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 an Oracle Tuxedo ATMI Application Using C.

See Also

• tuxtypes(5), typesw(5), and UBBCONFIG(5) in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference

Data-dependent routing is useful when clients issue service requests to:

• Horizontally partitioned databases
• Rule-based servers
• Distributed applications

A horizontally partitioned database is an information repository that has been divided into segments, each of which is used to store a different category of information. This arrangement is similar to a library in which each shelf of a bookcase holds books for a different category (for example, biography, fiction, and so on).

A rule-based server is a server that determines whether service requests meet certain, application-specific criteria before forwarding them to service routines. Rule-based servers are useful when you want to handle requests that are almost identical by taking slightly different actions for business reasons.

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

Suppose two clients in a banking application issue requests for the current balance in two accounts: Account 3 and Account 17. If data-dependent routing is being used in the application, then the Oracle Tuxedo system performs the following actions:

1. Gets the account numbers for the two service requests (3 and 17).
2. Checks the routing tables on the Oracle Tuxedo bulletin board that show which servers handle which range of data. (In this example, server 1 handles all requests for Accounts 1 through 10; server 2 handles all requests for Accounts 11 through 20.)
3. Sends each request to the appropriate server. Specifically, the system forwards the request about Account 3 to server 1, and the request about Account 17 to server 2.

Figure 2-14 Data-Dependent Routing with a Horizontally Partitioned Database

A banking application includes the following rules:

• Customers can withdraw up to $500 without entering a special password.
• Customers must enter a special password to withdraw more than $500.

Two clients issue withdrawal requests: one for $100 and one for $800. If data-dependent routing is enabled to support the withdrawal rules, the Oracle Tuxedo system performs the following actions:

1. Gets the amount specified for withdrawal in the two service requests ($100 and $800).
2. Checks the routing tables on the Oracle Tuxedo bulletin board that show which servers handle request for the amount being requested. (In this example, server 1 handles all requests to withdraw amounts up to $500; server 2 handles all requests to withdraw amount over $500.)
3. Sends each request to the appropriate server. Specifically, the system forwards the request for $100 to server 1 and the request for $800 to server 2.

   Figure 2-15 Data-Dependent Routing with Rule-Based Servers

   
   

   

   
   

The following figure 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.

Figure 2-16 Sample Banking Application Using Routing Criteria

In the preceding figure, requests are routed as indicated in the following table:

When services are named, an application component can locate another component through a name. Names can be simple words (such as “deposit”) or alphanumeric strings (such as “deposit2”). Names should be selected on the basis of the scope of the application and a map that contains the global picture of the relationships among application components. These maps or services are like the pages in a telephone book for application components.

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 Locating a Service by Name

The Oracle Tuxedo system offers a publish-and-subscribe mechanism: clients and servers can dynamically register or unregister a standing request to receive alerts (or messages) when a particular event occurs. Other clients and servers post user-defined or system events as they occur in the application. When a client or server no longer needs to be notified about a particular event, the relevant subscription can be cancelled.

To initiate C/SA, you must configure the follwing:

• UBBCONFIG *SERVICES section
• TM_MIB
  • T_SERVICE Class Definition
  • T_SVCGRP Class Definition

• Client/Server Affinity UBBCONFIG Example