Oracle9i Net Services Administrator's Guide
Release 1 (9.0.1)

Part Number A90154-01
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index


Go to previous page Go to next page

Architecture of Oracle Net Services

This chapter describes the architecture of Oracle Net, the listener, shared server, dedicated server, and Oracle Connection Manager.

This chapter contains these topics:

Oracle Net Stack Communication Architecture

The primary function of Oracle Net is to establish and maintain connections between a client application and an Oracle database server. Oracle Net is comprised of several communication layers that enable clients and database servers to share, modify, and manipulate data.

This section contains these topics:

Stack Communication for Client/Server Application Connections

Figure 4-1 illustrates the various layers on the client and on the database server after a connection has been established.

Figure 4-1 Layers Used in a Client/Server Application Connection

Text description of net81099.gif follows
Text description of the illustration net81099.gif

This communication architecture is based on 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, including:

Figure 4-2 shows how Oracle Net software--Oracle Net Foundation layer and Oracle Protocol Support--fits into the Session layer of the OSI model.

Figure 4-2 OSI Communication Layers

Text description of net81100.gif follows
Text description of the illustration net81100.gif

See Also: for information about the OSI stack 

As shown in Figure 4-1, the client/server stack is comprised of the following:

Client Application

During a session with the database, the client uses Oracle Call Interface (OCI) to interact with the database server. OCI is a software component that provides an interface between the client application and the SQL language the database server understands.

See Also:

Oracle Call Interface Programmer's Guide 


Character set differences can occur if the client and database server are running on different operating systems. The presentation layer resolves any differences. It is optimized for each connection to perform conversion only when required.

The presentation layer used by client/server applications is Two-Task Common (TTC). TTC provides character set and data type conversion between different character sets or formats on the client and database server.

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.

Oracle Net Foundation Layer

The Oracle Net foundation layer is responsible for establishing and maintaining the connection between the client application and database server, as well as exchanging messages between them. The Oracle Net foundation layer is able to perform these tasks because of a technology called Transparent Network Substrate (TNS). TNS provides a single, common interface functioning over all industry-standard protocols. In other words, TNS enables peer-to-peer application connectivity. 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.

On the client side, the Oracle Net foundation layer receives client application requests and resolves all generic computer-level connectivity issues, such as:

On the server side, the Oracle Net foundation layer performs the same tasks as it does on the client side and also works with the listener to receive incoming connection requests.

In addition to establishing and maintaining connections, the Oracle Net foundation layer communicates with naming methods to resolve names and uses security services to ensure secure connections.

Oracle Protocol Support

Positioned between the Oracle Net foundation layer and the network protocol layer, the Oracle protocol support layer is responsible for mapping TNS functionality to industry-standard protocols used in the client/server connection. This layer supports the following network protocols:

Network Protocol

All Oracle software in the client/server connection process requires an existing network protocol stack to establish the computer-level connection between the two computers for the transport layer. The network protocol is responsible for transporting data from the client computer to the database server computer, at which point the data is passed to the serverside Oracle protocol support layer.

The protocols have the following characteristics:

TCP/IP Protocol

The Transmission Control Protocol/Internet Protocol (TCP/IP) is the de facto standard communication protocol used for client/server conversation over a network.

TCP/IP with SSL Protocol

The TCP/IP with Secure Sockets Layer (SSL) protocol enables an Oracle application on a client to communicate with remote Oracle databases through TCP/IP and SSL. Oracle Advanced Security is required in order to use TCP/IP with SSL.

SSL stores authentication data, such as certificates and private keys, in an Oracle Wallet. When the client initiates a connection to the database server, SSL performs a handshake between the two using the certificate. During the handshake, the following processes occur:

The database server checks the user's certificate to verify that it bears the certificate authority's signature.

See Also:

Oracle Advanced Security Administrator's Guide 

Named Pipes Protocol

The Named Pipes protocol is a high-level interface providing interprocess communications between clients and database servers using distributed applications. One severside process creates the pipe, and the other clientside process opens it by name. What one side writes, the other can read, and vice versa. Named Pipes is specifically designed for PC LAN environments.

Named Pipes enables client/server conversation over a network using Named Pipes. This combination of Oracle products enables an Oracle application on a client to communicate with remote Oracle databases through Named Pipes (if the Oracle database is running on a host system that supports network communication using Named Pipes).

LU6.2 Protocol

The Logical Unit Type 6.2 (LU6.2) protocol is part of the IBM Advanced Program-to-Program Communication (APPC) architecture.

APPC is the IBM peer-to-peer (program-to-program) protocol for the System Network Architecture (SNA) network. SNA is an IBM reference model similar to the OSI model.

APPC architecture lets the client and host communicate over an SNA network without forcing the client to emulate a terminal (as in terminal-to-host protocols). APPC architecture enables peer-to-peer communication; the client can initiate communication with the database server.

An SNA network with the LU6.2 and Physical Unit Type 2.1 (PU2.1) protocols provides APPC. The LU6.2 protocol defines a session between two application programs; LU6.2 is a product-independent LU type.

LU6.2 enables an Oracle application on a PC to communicate with the database server. This communication occurs over an SNA network with the Oracle database on a host system that supports APPC.

VI Protocol

The Virtual Interface (VI) protocol can be used for application Web server and database server communication. VI is the de facto standard communication protocol for clustered server environments. Specifically designed for clusters, VI is a thin protocol that is more efficient than TCP/IP. Applications perform better using VI, because VI places most of the messaging burden upon high-speed network hardware, freeing the CPU for other tasks.

VI reduces the overhead of TCP/IP by eliminating intermediate copies and by transferring most of the messaging burden away from the CPU and onto the network hardware. The result is a low-latency, high-throughput interconnect protocol that reduces the amount of CPU cycles dedicated to messaging.

See Also: for the VI specification 


Information passed from a client application across a network protocol is received by a similar communications stack on the database server side. The process flow on the database server side is the reverse of the process flow on the client side, with information ascending through the communication layers.

Instead of OCI, the database server uses Oracle Program Interface (OPI). For each statement sent from OCI, OPI provides a response. For example, an OCI request to fetch 25 rows would elicit an OPI response to return the 25 rows once they have been fetched.

Stack Communication for Java Application Connections

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

Figure 4-3 shows the stack communication layers used by JDBC drivers.

Figure 4-3 Layers Used for Java-Client Applications

Text description of net81101.gif follows
Text description of the illustration net81101.gif


The Named Pipes protocol is supported but is not represented in this figure. 

The JDBC OCI driver uses a communication stack similar to a standard client/server communication stack. The JDBC Thin driver uses a Java implementation of the Oracle Net foundation layer called JavaNet and a Java implementation of TTC called JavaTTC.

See Also:

Oracle9i JDBC Developer's Guide and Reference 

Stack Communication for Web Client Connections

In addition to TTC presentation, the Oracle database server supports many other presentations that can be used for Web clients accessing features inside the database. For example, the database can be configured to accept HTTP and Internet Inter-ORB Protocol (IIOP) connections. The HTTP presentation is used to access Oracle Internet File System, and the IIOP presentation is used for connections to Enterprise JavaBeans (EJBs) and Common Object Request Broker Architecture (CORBA) applications in the database.

Figure 4-4 Layers Used in Web Client Connections

Text description of net81102.gif follows
Text description of the illustration net81102.gif

See Also:

Oracle9i Enterprise JavaBeans Developer's Guide and Reference 

Listener Architecture

The database server receives an initial connection from a client application through the listener. The listener is an application positioned on top of the Oracle Net foundation layer. Figure 4-5 illustrates the various layers on the client and database server during an initial connection.

Figure 4-5 Layers Used in an Initial Connection

Text description of net81103.gif follows
Text description of the illustration net81103.gif


The Named Pipes protocol is supported but is not represented in this figure. 

The listener brokers client requests, handing off the requests to the Oracle database server. Every time a client requests a network session with a database server, a listener receives the initial request.

Each listener is configured with one or more protocol addresses that specify its listening endpoints. Clients configured with one of these protocol addresses can send connection requests to the listener.

Once a client request has reached the listener, the listener selects an appropriate service handler to service the client's request and forwards the client's request to it. The listener determines if a database service and its service handlers are available through service registration. During service registration, the PMON process--an instance background process--provides the listener with information about the following:

This information enables the listener to direct a client's request appropriately Figure 4-6 shows instances registering information with listeners. Note that it does not represent all the information that can be registered.

Figure 4-6 Service Registration

Text description of net81035.gif follows
Text description of the illustration net81035.gif

Optionally, listening endpoints--port numbers--can be dynamically registered with the listener. For example, if Oracle9i JVM is installed, HTTP and IIOP listening endpoints are registered with the listener.

See Also:

Oracle9i Enterprise JavaBeans Developer's Guide and Reference for information about dynamically registering HTTP and IIOP listening endpoints 

If the listener is not running when an instance starts, PMON is not able to register the service information. PMON attempts to connect to the listener periodically, however, it may take up to 60 seconds before PMON registers with the listener after it has been started. To initiate service registration immediately after the listener is started, use the SQL statement ALTER SYSTEM REGISTER. This is especially useful in high-availability configurations.

If a listener receives an incoming request before the respective instance has been registered, the listener rejects the request.

See Also:

Oracle9i SQL Reference for further information about the ALTER SYSTEM REGISTER statement 

Figure 4-7 shows the role of a listener during connection establishment:

  1. The database registers information about the services, instances, and service handlers with the listener.

  2. The client makes an initial connection with the listener.

  3. The listener parses the client request and forwards it to the service handler for the database service requested.

Figure 4-7 Listener Architecture

Text description of net81108.gif follows
Text description of the illustration net81108.gif

Database Server Process Architecture

Based on the service handler type registered with the listener, the listener forwards requests to either a shared server process or a dedicated server process.

Shared Server Processes

Shared server processes are utilized in the shared server architecture. Figure 4-8 depicts a shared server architecture. With shared server architectures, client processes ultimately connect to a dispatcher. The PMON process registers the location and load of the dispatchers with the listener, enabling the listener to forward requests to the least loaded dispatcher.

A dispatcher can support multiple client connections concurrently. Each client connection is bound to a virtual circuit. A virtual circuit is a piece of shared memory used by the dispatcher for client database connection requests and replies. The dispatcher places a virtual circuit on a common queue when a request arrives. An idle shared server picks up the virtual circuit from the common queue, services the request, and relinquishes the virtual circuit before attempting to retrieve another virtual circuit from the common queue. This approach enables a small pool of server processes to serve a large number of clients.

Figure 4-8 Shared Server Architecture

Text description of net81116.gif follows
Text description of the illustration net81116.gif

Dedicated Server Processes

Figure 4-9 depicts a dedicated server architecture. With a dedicated server architecture, each client process connects to a dedicated server process. The server process is not shared by any other client.

PMON registers information about dedicated server processes with the listener. This enables the listener to start up a dedicated server process when a client request arrives and forward the request to it.


Dedicated server architectures do not support HTTP and IIOP clients. Only TTC clients are supported. 

Figure 4-9 Dedicated Server Architecture

Text description of net81115.gif follows
Text description of the illustration net81115.gif

Oracle Connection Manager Architecture

Oracle Connection Manager is a router through which a client connection request may be sent either to its next hop or directly to the database server. Clients who route connection requests through an Oracle Connection Manager can take advantage of the connection multiplexing, access control, and protocol conversion features configured on that Oracle Connection Manager.

Oracle Connection Manager has three process types:

The gateway process, CMGW, receives client connections and evaluates against a set of rules whether to deny or allow access. If access is allowed, the gateway process forwards the requests to the next hop, typically the database server. In addition to allowing or denying access, the CMGW process can also multiplex or funnel multiple client connections through a single protocol connection.

The CMGW process registers with the administrative process, CMADMIN. CMADMIN is a multi-threaded process that is responsible for all administrative functions of Oracle Connection Manager.

Table 4-1 describes the detailed responsibilities of the CMGW and CMADMIN processes.

Table 4-1 Oracle Connection Manager Processes

Process  Description 

CMGW (Oracle Connection Manager Gateway Process) 

The CMGW process is responsible for the following tasks:

  • Registering with the CMADMIN process

  • Listening for incoming connection requests. By default it listens on TCP/IP with port 1630.

  • Initiating connection requests to listeners for clients

  • Relaying data between the client and database server

  • Answering requests initiated by the Oracle Connection Manager Control utility


CMADMIN (Oracle Connection Manager Administrative Process) 

The CMADMIN process is responsible for the following tasks:

  • Processing the CMGW registration

  • Identifying all listeners serving at least one database instance

  • Registering source route address information about the CMGW process and listeners

  • Answering requests initiated by the Oracle Connection Manager Control utility

  • Locating Oracle Names servers

  • Monitoring registered listeners with Oracle Names servers

  • Maintaining address information in Oracle Names servers for clients

  • Periodically sending a request to Oracle Names servers to update their cache of available services


Figure 4-10 shows the CMGW process registering with the CMADIN process and the CMGW process handling client requests. Notice that the CMGW process has denied access to the fourth client. The three client connections are then multiplexed through a single network protocol connection to the database.

Figure 4-10 Oracle Connection Manager Architecture

Text description of net81128.gif follows
Text description of the illustration net81128.gif

A Complete Architecture

Oracle Net provides an architectural solution that allows for greater scalability in Internet and intranet environments.

Figure 4-11 shows how multiple connections to an Oracle database server are made more scalable with Oracle Connection Manager and a shared server architecture. Oracle Connection Manager is used to offload some of the network I/O of the application Web servers, and shared server is used to serve more concurrent users.

Figure 4-11 Scalable Architectural Solutions

Text description of net81113.gif follows
Text description of the illustration net81113.gif

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

All Rights Reserved.
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index