Oracle7 Server Distributed Systems Volume I: Distributed Data

Contents Index Home Previous Next

SQL*Net Version 2 Architecture

This section provides a more detailed discussion of SQL*Net and the role it plays in distributed systems.

SQL*Net version 2 uses the Transparent Network Substrate (TNS) and industry-standard network protocols to connect a client to a server and establish an Oracle session.

The next few sections describes the following architectural concepts:

Transparent Network Substrate (TNS)

Forming the basis for Oracle networking products, the Transparent Network Substrate (TNS) enables Oracle to provide a network of applications above all existing networks of computers. With TNS, peer-to-peer application connectivity is possible where no direct machine-level connectivity exists. Peer-to-peer is an architecture in which two or more nodes can communicate with each other directly, without the need for any intermediary devices. In a peer-to-peer system, a node can be both a client and a server.

TNS provides two key features to a TNS-based network product and, in turn, any application built using TNS:

TNS is the foundation component of all current and planned network products from Oracle. Today, TNS networks connect Oracle clients and servers through SQL*Net version 2. In the future, Oracle Corporation will provide additional TNS-based application connectivity tools.

SQL*Net's Communication Role

In a distributed transaction, SQL*Net is responsible for sending information across various networks on behalf of a client application or database server. In such a configuration, there are commonly two types of computers acting as the client and server. Two-Task Common (see [*]) ensures that all differences between clients and servers, such as internal datatype representations or NLS character sets, are resolved, allowing the client and server to communicate transparently. SQL*Net relays all communication tasks to TNS through its common entry points. SQL*Net is unaffected by the specific communication mechanism used underneath TNS (for example, TCP/IP, DECnet, shared memory, and so on).

Communication between client and server proceeds in a stack-like fashion with corresponding levels communicating in a peer relationship. The logical exchange unit at each layer of the stack conveys the level of generalization employed at that level. The Oracle client and server exchange SQL statements and data rows. At the UPI/OPI (User/Oracle Program Interface) layers, these exchanges translate into series of calls to SQL routines such as logon, parse, execute, and fetch. The SQL*Net layer handles these calls as a series of Oracle send/receive messages, and TNS in turn processes the packets over the network. The network protocol, not provided by Oracle (typically provided with each particular platform by its vendor), guarantees a reliable means of communication between the two tasks.

Figure 2 - 5. Oracle Client-Server Components

SQL*Net in Distributed Processing

SQL*Net is responsible for enabling communications between the cooperating partners in a distributed transaction, either client-server or server-to-server. Specifically, SQL*Net enables clients and servers to connect to each other, send data such as SQL statements and data responses, initiate interrupts from the client or server, and disconnect when the session is complete. During the life of the connection, SQL*Net resolves all differences between the internal data representations and/or character sets of the computers being used.

When a client or server makes a connection request, SQL*Net receives the request. If more than one machine is involved, SQL*Net passes the request to the TNS, to be transmitted over the appropriate communications protocol to the appropriate server. On the server, SQL*Net receives the request from TNS and passes it to the database as a network message with one or more parameters (that is, a SQL statement).

Except for the initial connection, the local and remote applications generate the same requests whether they run on the same computer or are distributed across multiple computers. The initial connection differs only in that the application or user must specify the name of the remote database.

Components Involved in Distributed Processing

Several software components complete a distributed transaction, whether it is a client-server or server-server transaction. Figure 2 - 5 shows the components of a client-server session. These components are described in the following sections.

Client Side Interaction

The following paragraphs discuss the components of the client-server transaction process, beginning with the client application and concluding with the Oracle Server.

Client Application

The client application provides all user-oriented activities, such as character or graphical user display, screen control, data presentation, application flow, and other application specifics. The application identifies any SQL database operations to send to the server database and passes them through the User Program Interface (UPI).

User Program Interface (UPI)

The UPI code that contains all information required to initiate a SQL dialogue between the client and the server. It defines calls to the server to:

The client application uses some combination of these calls to request activity within the server. Often, all UPI calls can be combined into a single message to the server, or they may be processed one at a time through multiple messages to the server, depending on the nature of the client application. Oracle products attempt to minimize the number of messages sent to the server by combining many UPI calls into a single message to the server. When a call is performed, control is passed to SQL*Net to establish the connection or transmit the request to the server.

Two-Task Common

Two-Task Common provides character set and data type conversion between different character sets or formats between client and server. This layer is optimized to perform conversion only when required on a per connection basis.

At the time of initial connection, SQL*Net version 2 is responsible for evaluating differences in internal data and character set representations and determining whether conversions are required for the two computers to communicate.

SQL*Net

The role of SQL*Net is to establish and maintain a connection between the client application and the server and exchange messages between them. The network listener receives connection requests for a particular database and passes control to the server.

Transparent Network Substrate (TNS)

TNS receives requests from network applications, in this case SQL*Net, and settles all generic machine-level connectivity issues, such as:

The generic set of TNS functions (open, close, send, receive) passes control to an Oracle Protocol Adapter to make a protocol-specific call.

Additionally, TNS optionally provides encryption and sequenced cryptographic message digests to protect data in transit. See Secure Network Services Administrator's Guide for more information.

Oracle Protocol Adapter

The Oracle Protocol Adapter is responsible for mapping TNS functionality to any industry-standard protocol used in the client-server connection. The adapters are responsible for mapping the equivalent functions between TNS and a specific protocol.

Network-Specific Protocols

All Oracle software in the client-server connection process requires an existing network protocol stack to make the machine-level connection between the two machines. The network protocol is responsible only for getting the data from the client machine to the server machine, at which point the data is passed to the server-side Oracle Protocol Adapter.

Server-Side Interaction

Going up the process stack on the server side is the reverse of what occurred on the way down the client side. See the right side of Figure 2 - 5.

The one operation unique to the server side is the act of receiving the initial connection. The server has a process (the network listener) that regularly checks for incoming connections and evaluates their destination.

The network listener is a process on a server that listens for connection requests for one or more databases on one or more protocols. It is discussed in "SQL*Net and the Network Listener" [*]. Based on the Oracle Server ID (SID) specified, the connection is passed to the Oracle Server.

The components above SQL*Net, the OPI and the Oracle Server, are different from those on the client side.

Oracle Program Interface (OPI)

The OPI has a complementary function to that of the UPI. It is responsible for responding to each of the possible messages sent by the UPI. For example, a UPI request to fetch 25 rows would have an OPI response to return the 25 rows once they have been fetched.

Oracle Server

The Oracle Server side of the connection is responsible for receiving dialog requests from the client UPI code and resolving SQL statements on behalf of the client application. Once received, a request is processed and the resulting data is passed to the OPI for responses to be formatted and returned to the client application.

Server-to-Server Interaction

When two servers are communicating to complete a distributed transaction, the process and dialogues are the same as in the client-server scenario, except that there is no client application. See Chapter 5, "Distributed Updates" for more information. The server has its own version of UPI, called NPI. The NPI interface can perform all of the functions that the UPI does for clients, allowing a coordinating server to construct SQL requests for additional servers. Figure 2 - 6 shows a server-to-server connection and all associated layers.

Figure 2 - 6. Oracle Server-Server Components

Contents Index Home Previous Next