The Oracle Tuxedo system is a middleware product that distributes applications across multiple platforms, databases, and operating systems using message-based communications and, if desired, distributed transaction processing.
• Distributed services—allow transparent access to application and/or system services located on different hardware platforms.
• Fast, connectionless communications—clients connect to a bulletin board rather than to servers, thus improving system performance.
• Server transparency—the directory of services on the bulletin board maps service names to servers; clients do not need to be aware of server identity.
• Scalability—application designers can quickly scale their Oracle Tuxedo applications to match varying system load demands because services and servers can be replicated and distributed easily. Designers can set thresholds programmatically to enable the Oracle Tuxedo system to spawn new servers or to shut down servers automatically.
• Password security and access control security—password security allows application designers to control access by requiring passwords at initialization time (authentication). Further control is available through authorization, a means of restricting access to certain application services to clients that have been given explicit permission and that have authenticated identities.
• Application-specific and system events notification—the Oracle Tuxedo system provides details about application and system events, such as servers unexpectedly terminating and networks failing. When an event is posted by clients or servers, the Oracle Tuxedo publish-and-subscribe component looks up all the subscribers to that event and takes appropriate actions, as determined by each subscription.
• Management information base (MIB)—an administrative interface that enables administrators to monitor, configure, and tune their applications through their own programs. It is an implementation-independent management database defined as a set of Field Manipulation Language (FML) attributes, which allows administrators to query or change information.
• Web-based administration—a graphical user interface, available through the World Wide Web, for the configuration and control of Oracle Tuxedo applications.
• Communication techniques—the application programming interface (API) for the Oracle Tuxedo system is a superset of X/Open’s XATMI interface called the Application-to-Transaction Monitor Interface, or ATMI. The Oracle Tuxedo ATMI is a rich set of communication techniques for writing distributed applications.
• Distributed Transaction Processing (DTP)—allows work being done throughout a distributed application to be atomically completed, an essential characteristic of any OLTP system.
• Typed buffers—provide transparent handling of application data across heterogeneous platforms.
• X/Open XA compliance—the Oracle Tuxedo system conforms to the X/Open interface standard for transaction database systems (called resource managers). As a result, application designers can mix and match databases within an application while maintaining data integrity.
• X/Open TX compliance—the Oracle Tuxedo system conforms to the X/Open interface standard for transaction demarcation. Oracle Tuxedo also offers its own ATMI interface for transaction demarcation.
• Asymmetrical protocols—a many-to-one relationship between clients and a server. Clients always initiate a dialog by requesting a service. Servers wait passively for requests from clients.
• Encapsulation of services—the server is a specialist: when given a message requesting a service, it determines how to get the job done. Servers can be upgraded without affecting clients as long as the published message interface used by both is unchanged.
• Integrity—the code and data for a server are centrally maintained, which results in inexpensive maintenance and the protection of shared data integrity. At the same time, clients remain personal and independent.
• Location transparency—the server is a process that can reside on the same machine as a client process or on a different machine across a network. Client/server software usually hides the location of a server from clients by redirecting service requests. Clients should not have to be aware of the location of servers.
• Namespace transparency—clients should be able to use the same naming conventions (and namespace) to locate any server on the network.
• Message-based exchanges—clients and servers are loosely-coupled processes that can exchange service requests and replies using messages.
• Modular, extensible design—the modular design of a client/server application enables that application to be fault-tolerant. In a fault-tolerant system, failures may occur without causing a shutdown of the entire application. In a fault-tolerant client/server application, one or more servers may fail without stopping the whole system as long as the services offered on the failed servers are available on servers that are still active. Another advantage of modularity is that a client/server application can respond automatically to increasing or decreasing system loads by adding or shutting down one or more services or servers.
• Platform independence—the ideal client/server software is independent of hardware or operating system platforms, allowing the mixing of client and server platforms. Clients and servers can be deployed on different hardware using different operating systems, optimizing the type of work each performs.
• Reusable code—service programs can be used on multiple servers.
• Scalability—client/server systems can be scaled horizontally or vertically. Horizontal scaling means adding or removing client workstations with only a slight performance impact. Vertical scaling means migrating to a larger and faster server machine or adding server machines.
• Separation of client/server functionality—client/server is a relationship between processes running on the same or separate machines. A server process is a provider of services. A client is a consumer of services. Client/server provides a clean separation of functions.
• Shared resources—one server can provide services for many clients at the same time, and regulate their access to shared resources.Figure 1‑1 2-Tier and 3-Tier Client/Server ModelsThe Oracle Tuxedo system fits into the middle of the client/server model. In a Oracle Tuxedo application, clients log in and request services offered by an application. The Oracle Tuxedo system offers these services through a transparent bulletin board. The bulletin board provides a global directory advertising service.
• Clients—programs that collect input from users, send requests through the Oracle Tuxedo system to servers, and deliver server replies to users.
• Servers—programs that encapsulate the business logic into a set of services that define the application.
• Middleware—comprises all the distributed software needed to support interactions between clients and servers. It is the medium that enables a client to obtain a service from a server. Middleware includes (1) API functions used by the client—to issue requests and receive replies—and the server—to issue replies—and (2) messaging paradigms used to transmit client requests and server responses over a network. Middleware does not include the client user interface, the application logic, or the services provided by the servers.For descriptions of the Oracle Tuxedo application processing services, see “Oracle Tuxedo ATMI Architecture” on page 2‑1.For descriptions of the Oracle Tuxedo system administration processes that provide the administrative services, see “Oracle Tuxedo System Administration and Server Processes” on page 3‑1 and “Oracle Tuxedo Management Tools” on page 4‑1. For detailed instructions on using the administrative services, see Setting Up an Oracle Tuxedo Application and Administering an Oracle Tuxedo Application at Run Time.