Net8 Administrator's Guide
Release 8.1.6

Part Number A76933-01





Go to previous page Go to next page

Net8 Architecture

This chapter describes the Net8 architecture. This chapter includes the following sections:

Transparent Network Substrate (TNS)

Transparent Application Failover (TAF) is a foundation technology that is built into Net8 providing a single, common interface to all industry-standard protocols.

With TNS, peer-to-peer application connectivity is possible. In a peer-to-peer architecture, two or more computers (called nodes when they are employed in a networking environment) 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.

Overview of Stack Communications

The concept of distributed processing relies on the ability of computers separated by both design and physical location to communicate and interact with each other. This is accomplished through a process known as stack communications.

Stack communications can be explained by referencing the Open Systems Interconnection (OSI) model. In the OSI model, communication between separate computers occurs in a stack-like fashion with information passing from one node to the other through several layers of code. Figure 3-1 shows a typical OSI protocol communications stack.

Figure 3-1 OSI Communications Stack

Information descends through layers on the client side where it is packaged for transport across a network medium in such a manner that it can be translated and understood by corresponding layers on the server side.

A typical OSI protocol communications stack contains seven such layers:

Client Application

The OSI layer closest to the user, and as such is dependent on the functionality requested by the user. For example, in a database environment, a Forms application may attempt to initiate communication in order to access data from a server.


Ensures that data is represented in a format that the application and session layers can accommodate. This includes keeping track of syntax and semantics of the data transferred between the client and server. If necessary, the presentation layer translates between multiple data representation formats by using a common data format.


Establishes, manages, and terminates network sessions between the client and server. This is a virtual pipe that carries data requests and responses. The session layer manages whether the data traffic can go in both directions at the same time (referred to as asynchronous), or in only one direction at a time (referred to as synchronous).


Implements the data transport ensuring that the data is transported reliably.


Ensures that the data transport is routed through optimal paths through a series of interconnected subnetworks.


Provides reliable transit of data across a physical link.


Defines the electrical, mechanical, and procedural specifications for activating, maintaining and deactivating the physical link between client and server.

Stack Communications in a Typical Net8 Client/Server Environment

Stack communications allow Oracle clients and servers to share, modify, and manipulate data between themselves. The layers in a typical Oracle communications stack are similar to those of a standard OSI communications stack. This section covers the following topics:

Net8 Client-Side Interaction

In an Oracle client-server transaction, information passes through the following layers:

Figure 3-2 shows a client-server communications stack in an Oracle networking environment.

Figure 3-2 Typical Communications Stack in an Oracle Environment

Client Application

Oracle client applications provide all user-oriented activities, such as character or graphical user display, screen control, data presentation, and application flow. The application identifies database operations to send to the server and passes them through to the Oracle Call Interface (OCI).

Oracle Call Interface (OCI)

Oracle Call Interface (OCI) code contains all the information required to initiate a SQL dialog between the client and the server. It defines calls to the server to:

The client application uses a combination of these calls to request activity within the server. OCI 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 OCI calls into a single message to the server. When a call is performed, control is passed to Net8 to establish the connection and transmit the request to the server.

See Also:

Oracle Call Interface Programmer's Guide 

Two-Task Common (TTC)

Two-Task Common (TTC) is Oracle's implementation of the presentation layer. TTC provides character set and data type conversion between different character sets or formats on the client and server. This layer is optimized on a per connection basis to perform conversion only when required

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


Net8 provides all the session and transport layer functionality in an Oracle communication stack. It is responsible for establishing and maintaining the connection between the client application and server, as well as exchanging messages between them. Net8 is also responsible for mapping session functionality into industry-standard protocols.

Net8 has three component layers that facilitate session and transport layer functionality:

Component  Description 

Network Interface (NI) 

This layer provides a generic interface for Oracle clients, servers, or external processes to access Net8 functions. The NI layer handles the "break" and "reset" requests for a connection.

NI uses Network Naming (NN) to resolve names to connect descriptors. 

Network Session (NS)  

This layer receives requests from NI, and settles all generic machine-level connectivity issues, such as: the location of the server or destination (open, close functions); whether one or more protocols will be involved in the connection (open, close functions); and how to handle interrupts between client and server based on the capabilities of each (send, receive functions).

NS uses Network Route (NR) to route the network session to the destination and Network Authentication (NA) to negotiate any authentication requirements with the destination. 

Oracle Protocols  

Oracle protocols are Oracle's implementation of the transport layer. Oracle protocols are responsible for mapping NS functionality to industry-standard protocols used in the client-server connection. Each protocol is responsible for mapping the equivalent functions between NS and a specific protocol. Oracle protocols include:

  • TCP/IP

  • TCP/IP with SSL

  • SPX

  • Named Pipes

  • LU6.2


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 for the transport layer. 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.

Server-Side Interaction

Information passed from a client application across a network protocol is received by a similar communications stack on the server side. The process stack on the server side is the reverse of the process stack on the client side, with information ascending through communication layers. The one operation unique to the server side is the act of receiving the initial connection through the listener.

The following components above the network session layer are different from those on the client side:

Oracle Program Interface (OPI)

Oracle Program Interface (OPI) performs a complementary function to that of the OCI. It is responsible for responding to each of the possible messages sent by the OCI. For example, an OCI 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 requests from the client OCI 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 communicate to complete a distributed transaction, the server acts as a client application. The server has its own version of OCI, called the Network Program Interface (NPI). The NPI interface performs all of the functions that the OCI does for clients, allowing a coordinating server to construct SQL requests for additional servers.

Stack Communications for Clients Connecting to a Directory Server

Clients that access a LDAP-compliant directory server go through an additional LDAP layer to connect to the directory, as shown in Figure 3-3. The directory sends the information back to the client through the traditional client stack.

Figure 3-3 Typical Client vs. Net8 LDAP Client Communications Stack

Stack Communications for JDBC Clients

Oracle's Java Database Connectivity (JDBC) Drivers provide Java programmers access to an Oracle database. Oracle offers two JDBC drivers.

The layers in a JDBC client communications stack are similar to those of a standard Oracle communications stack, as shown in Figure 3-4:

Figure 3-4 Typical Client vs. JDBC Client Communications Stack


The server-side stack is the same as Figure 3-2

The JDBC/OCI client stack is similar to a typical Net8 Client stack. The Thin JDBC client stack has similar components implemented differently. In a Java client applet-server transaction, information passes through the following layers:

DBAccess Interface

The Java DBAccess Interface layer enables the client to initiate a SQL session much like Oracle Call Interface (OCI) does in a standard client communication stack.


JavaTTC provides a subset version of the Two-Task Common (TTC) implementation necessary for exchanges of information between the Java client and the database. JavaTTC is responsible for:


JavaNet provides a communication infrastructure so the JDBC client can connect to an Oracle database. This information is equivalent to NI, NR/NN/NA, and TNS in Net8.

TCP/IP Protocol

TCP/IP Protocol - Java NS will only run on top of TCP/IP, because Java sockets use TCP/IP.

Figure 3-5 shows a communication stack between a Java client applet and an Oracle database.

Figure 3-5 Java Client/Server Communications Stack in a JDBC Environment


JDBC clients can be configured to use directory naming, as described in Oracle8i JDBC Developer's Guide and Reference 

Stack Communications for Oracle8i JServer Clients

Oracle8i has Java support with Oracle8i JServer. Oracle8i JServer includes support for Java stored procedures, JDBC, SQLJ, Common Object Request Broker Architecture (CORBA), and Enterprise JavaBeans (EJBs).

See Also:

Oracle8i Java Developer's Guide for an overview of Oracle8i JServer 

Oracle8i JServer supports the General Inter-Orb Protocol (GIOP) presentation for Java Virtual Machine (VM) requests. GIOP is used by clients accessing Enterprise Java Beans and CORBA Servers in the Java VM.

EJB and CORBA clients use a different communication stack than a typical Net8 client stack, as shown in Figure 3-6. Differences include:

Figure 3-6 Typical Net8 Client vs. Oracle8i JServer Client Communication Stack

The server side does not require many of the Net8 communication layers needed in a typical Net8 connection. Instead, the server side only requires a network protocol of TCP/IP and an Oracle protocol of TCP/IP or TCP/IP with SSL. The only component of Net8 required is Network Session (NS). Figure 3-7 shows a communication stack between a client and the Oracle8i JServer option in the Oracle database.

Figure 3-7 Client/Server Communications Stack in an Oracle8i JServer Environment

See Also:


Go to previous page Go to next page
Copyright © 1996-2000, Oracle Corporation.

All Rights Reserved.