Oracle7 Server Distributed Systems Volume I: Distributed Data
Oracle Network Products and Distributed Systems
In today's highly distributed information systems, networking is one of the most important architectural components. This section describes some of the ways that Oracle network products can be implemented to create an efficient distributed system.
Transparency in a Distributed System
The functionality of a distributed system must be provided in such a manner that the underlying complexities of the system are transparent to both users and administrators. A network implementation in a distributed system must be able to deliver:
Network Transparency
SQL*Net's layered architecture allows standard applications to run transparently over many types of protocols by simply using the appropriate Oracle Protocol Adapter. Thus, Oracle applications developed with a local database can be distributed across a network to access the same, or a similarly formatted, Oracle database with no changes to the application.
SQL*Net is responsible for forwarding application requests for data from an Oracle client or server to a server and returning the results to the initiator of the query. From the application developer's or application user's perspective, all data interaction using SQL*Net is invisible to the application and user.
Additionally, it is possible to change the network structure beneath the application without changing the application. This capability is known as network transparency.
Figure 2 - 2 illustrates a possible distributed systems scenario.
Figure 2 - 2. Possible Distributed Systems Scenario
Location Transparency: Database Links, Synonyms, and Service Names
Oracle7 server provides the means to make data objects such as tables in remote databases look to an application developer or user of that data object like they are in the local database. This is called location transparency. The database link and synonym allow the database in which they are created to identify a remote data object and make the location transparent. Establishing and maintaining location transparency is a joint function of the network administrator and the DBA. The network administrator is typically responsible for database links which are discussed later in this chapter, while views, synonyms and other forms of transparency are the responsibility of the DBA. They are discussed![[*]](jump.gif)
, "Database Administration".
Location transparency removes all need for references to the location of the data from applications when the synonym is used. Should the location of the remote table be moved to another machine or database, only the synonym and database link need be updated to reference the new location. No changes to applications are required.
If the database link connection is specified as a service name (or symbolic name) in the network configuration file (TNSNAMES.ORA), the database links accessing the data do not have to be changed if the remote database is moved. The only update required is to the TNSNAMES.ORA file. Similarly, if Oracle Names is used, only the central network definition needs to be changed.
TNSNAMES.ORA, and other configuration files are created using Oracle Network Manager. The configuration files are described in Appendix A of Understanding SQL*Net. For detailed instructions on creating the network definition and the configuration files for SQL*Net and other Oracle networking products, see the Oracle Network Manager Administrator's Guide.
Application Transparency
Another benefit of SQL*Net's encapsulated network architecture is that client-server applications can be built on one class of system and deployed on another. An application system back-end developed on a PC server can, for example, be redeployed on a large minicomputer server without the end-users needing to know that the location of the application has changed.
This flexibility means that server systems can be selected for current requirements, rather than for some large future need. Likewise, a system developed on a mainframe can be moved down to smaller, more cost-effective servers without reworking any of the code. This flexibility also allows exactly the same application code that is running on a large, central processor complex to be run on small, workgroup servers on remote PC LANs.