Release 8.1.6
Part Number A76933-01
 Library |
 Product |
 Contents |
 Index |
| Net8 Administrator's Guide Release 8.1.6 Part Number A76933-01 |
|
This chapter describes the Net8 architecture. This chapter includes the following sections:
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.
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.
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:
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 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:
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.
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) 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.
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:
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.
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) 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.
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.
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.
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.
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:
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:
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 - 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.
|
Note: JDBC clients can be configured to use directory naming, as described in Oracle8i JDBC Developer's Guide and Reference |
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).
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:
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.
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|