Page 449
transparent gateways to third-party database servers, procedural gateways to other applications, or the Oracle Web Server.
In this section, you will look closely at the network transport services, the native local area network (LAN), and wide area network (WAN) protocol stacks that make up the core of networking. You will also touch on native network naming services as they apply to the native network protocols. Native network naming services are used to map "English" names and aliases for computers with their network addresses. Oracle Names is used to map English names and aliases to Oracle databases. Oracle Names often takes advantage of native network naming services by allowing the administrator to specify server host names rather than network addresses in the Oracle Names database.
As promised, jargon will be defined as it comes up, starting with network architectures and protocol stacks. A network architecture is a collection of modular components that are combined to form an effective, synergistic solution. Each component provides a "service" to the whole. By choosing and combining a subset of the available component technologies, a network architecture is built. It is this ability to mix and match components that underlies the principle of open systems and interoperability.
Without some type of reference blueprint for the assembly of components and a set of standards governing their construction, these pieces would not be plug and play. This environment exists for native network transports. These standards are often called protocols, and the reference blueprint is called a stack. The reference blueprint describes the network framework as a stack of service layers, much like a layer cake. Each layer has a specific, clearly defined responsibility within the stack and provides service to the layer above until the stack of components is working together.
For the native network transport, the reference model is the International Organization for Standardization's (ISO) Open Systems Interconnection reference model. Standards are developed and maintained by the American National Standards Institute (ANSI) and the Institute of Electronic and Electrical Engineers (IEEE) 802 committee. The Oracle networking layers and protocols above the native network transport follow Oracle's SQL*Net architecture.
The current SQL*Net architecture blueprint is missing some important protocol layer detail needed to understand how SQL*Net works. It is missing the core network protocol of SQL*Net, Oracle's Transparent Network Substrate (TNS) peer-to-peer networking application. It is the TNS that provides the primary abstraction layer, or a common application interface, to many of the network products that make Oracle applications hardware and network transparentthus the name Transparent Network Substrate. TNS provides the service layer to access the native network transport, Oracle Names, and various security and naming services. The Oracle Network Listener is a TNS application that runs on an Oracle server to establish connections between clients and the server. The TNS layer is responsible for most of the client error messages, as the TNS prefix on these error messages reveals.
Page 450
There are five fundamental protocol layers that make up the SQL*Net architecture (see
Figure 19.1):
FIG. 19.1
The client side and
server side SQL*Net
and Net8 protocol
stacks.
The Oracle Protocol Adapters are the interfaces between specific native protocol stack implementations and the Transparent Network Substrate (TNS). The Oracle Protocol Adapters perform a function similar to the interfaces in the native network transport, mapping the standard functionality to TNS with those functions found in the native stack. Oracle Protocol Adapters are specific to the exact vendor's implementation of the native protocol stack.
As stated earlier, the TNS is a peer-to-peer networking protocol developed by Oracle. It provides the means for establishing network connections and delivering a "pipe" through which to pass SQL*Net, application messages, and data. The most critical TNS application is the Network Listener.
The Network Listener is a protocol-independent application listener, or daemon, that receives TNS connections for any TNS application running on the Oracle server. SQL*Net connections
Page 451
are identified by the listener, based on a SQL*Net-specific port or socket identified in the ADDRESS portion of the connect descriptor in the TNSNAMES.ORA file or Oracle Names database. While a session is established with the listener, a dedicated server process is established (or assigned) to handle the communication session.
As the foundation for both TNS and SQL*Net, your local area network (LAN) protocols must be working properly before anything layered on top will work. Understanding proper LAN operation, therefore, is a required prerequisite to understanding Oracle networking. As I describe the native network protocol stack, I will emphasize the concepts needed for troubleshooting and proper design.
As previously mentioned, the reference blueprint for the native network transport is the ISO's seven layer Open Systems Interconnection (OSI) reference model. In the late 1970s, the ISO organized a subcommittee of computer professionals to establish standards to encourage interoperability among computer and data communication vendors. The resulting OSI blueprint organizes network communication into the following seven layers:
Layer 1Physical Layer
Layer 2Data-Link Layer
Layer 3Network Layer
Layer 4Transport Layer
Layer 5Session Layer
Layer 6Presentation Layer
Layer 7Application Layer
For your purposes, this reference blueprint is much too detailed; I will describe a simplified reference blueprint (see Figure 19.2), beginning with the foundation, the interfaces, and the protocol stacks.
Nothing can be built without a strong foundation. The same is true of networks. This layer consists of the physical cabling and electronics required to electrically transmit data between computers. This world is governed by the Electronics Industries Association (EIA), Telecommunication Industries Association (TIA), and the Institute of Electrical and Electronic Engineers (IEEE). The joint EIA/TIA standards committee has worked toward the development of a cabling standards and standard practices. These standards harmonize the wiring necessary for telephone and data. The adoption of the EIA/TIA-568A standard in the wiring industry has driven most LANs to a star-wired design using telephone-type cable called unshielded twisted-pair (UTP). Shielded twisted-pair (IBM Type1 Token-Ring) and fiber optic cabling are also recommended in the 568A standard.