| Oracle9i Net Services Administrator's Guide Release 2 (9.2) Part Number A96580-02 |
|
|
View PDF |
| Oracle9i Net Services Administrator's Guide Release 2 (9.2) Part Number A96580-02 |
|
|
View PDF |
This chapter describes the architecture of Oracle Net, the listener, shared server, dedicated server, and Oracle Connection Manager.
This chapter contains these topics:
| See Also:
Chapter 1, "Networking Challenges in the Internet Age" for an introductory level overview of Oracle Net 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:
Figure 4-1 illustrates the various layers on the client and on the database server after a connection has been established.
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:
1. Physical layer
2. Data link layer
3. Network layer
4. Transport layer
5. Session layer
6. Presentation layer
7. Application layer
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.
| See Also:
|
As shown in Figure 4-1, the client/server stack is comprised of the following:
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.
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.
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.
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:
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 Transmission Control Protocol/Internet Protocol (TCP/IP) is the de facto standard communication protocol used for client/server conversation over a network.
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.
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).
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.
The Oracle 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.
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.
In addition to the TTC presentation, the Oracle database server supports many other presentations that can be used for Web clients accessing features inside the database. The listener facilitates this by supporting any presentation requested by the database.
For example, Figure 4-4 shows the stack communication layers used in an HTTP or FTP connection to Oracle XML DB in the Oracle9i instance. WebDAV connections use the same stack communication layers as HTTP and FTP.
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.
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.
Optionally, listening endpoints--port numbers--can be dynamically registered with the listener. For example, with Oracle XML DB, HTTP, FTP, and WebDAV listening endpoints are registered with the listener.
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.
Figure 4-7 shows the role of a listener during connection establishment with a browser making an HTTP connection and a client making a TTC connection:
See Also:
|
Based on the service handler type registered with the listener, the listener forwards requests to either a shared server or dedicated server process.
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-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.
|
Note: Dedicated server architectures do not support HTTP, FTP, or WebDAV clients. Only TTC clients are supported. |
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 two processes:
The CMGW gateway process 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 CMADMIN administrative process. CMADMIN is a multi-threaded process that is responsible for all administrative functions of Oracle Connection Manager.
|
Note: On Windows NT, the gateway process is represented by the |
Table 4-1 describes the detailed responsibilities of the CMGW and CMADMIN processes.
Figure 4-10 shows the CMGW process registering with the CMADMIN 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.
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.
|
 Copyright © 2001, 2002 Oracle Corporation. All Rights Reserved. |
|
