Oracle7 Server Distributed Systems Volume I: Distributed Data

Contents Index Home Previous Next

The MultiProtocol Interchange

Oracle's client-server and server-to-server models provide connectivity across multiple network protocols.

Data Access Across Transfer Protocols

Oracle's MultiProtocol Interchange can be used with SQL*Net to enable transparent data access across protocols, allowing a client using one protocol to communicate with a server using a different protocol. This way, clients and servers running different network protocols can communicate using only their native protocols. This eliminates the need to purchase and maintain multiple protocol stacks.

All of the advanced Oracle7 capabilities, such as basic replication, the advanced replication option, stored procedure calls, and automatic transaction recovery mechanisms, can operate transparently across any number of protocol boundaries.

Multiple Interchanges can be combined to provide multistage protocol conversion, all transparent to programmers and users alike. Applications simply ask for services by name, and SQL*Net automatically calculates the most efficient route to take through the network and establishes the connection.

When the network topology changes, such as when a new server is added to the network, users and applications are completely unaware of the change, because SQL*Net transparently calculates a new route automatically at request time. Where there are multiple possible routes, SQL*Net will use the most efficient route based on high-level weighting provided by the network administrator.

This product is described in detail in the Oracle MultiProtocol Interchange Administrator's Guide. For information on configuring the MultiProtocol Interchange, see the Oracle Network Manager Administrator's Guide.

MultiProtocol Interchanges in the Client-Server Configuration

With SQL*Net version 2, the client and server can belong to different communities connected by one or more MultiProtocol Interchange(s). A community is a group of computers that can communicate using the same transport level protocol, such as TCP/IP. That is, computers that use the same protocol are members of the same community.

For example, a MultiProtocol Interchange can be installed on a node that is loaded with two protocol stacks, TCP/IP and DECnet. Then, it can enable a network running TCP/IP to communicate with a network running DECnet. The result is a higher-level application network in which any two applications can communicate. Using an Interchange as an intermediary, applications on the client and server machines can communicate even though they are using different protocols. Any data exchanged in the client-server applications is forwarded through the Interchanges along the path.

Figure 2 - 3 shows a connection between a client (protocol A) and a server (protocol B) in adjacent communities. A MultiProtocol Interchange joins the two networks. SQL*Net and an Oracle Protocol Adapter specific to Protocol A are installed on the client while SQL*Net and an Oracle Protocol Adapter specific to Protocol B are installed on the database server. The Interchange has adapters for both Protocol A and Protocol B. In a sense, it is bilingual (or poly-lingual). When communication is requested between the two communities, the MultiProtocol Interchange translates between the two protocols.

Figure 2 - 3. Heterogeneous Networking with a Client-Server Connection

MultiProtocol Interchanges in the Server-to-Server Configuration

In a server-to-server configuration, this same heterogeneous network capability is extended to include database-to-database communications. Two types of server-to-server connections are possible using SQL*Net:

Figure 2 - 4. Heterogeneous Networking in a Distributed Database Transaction

The example in Figure 2 - 4 shows both types of connections.

In this example, Server 1 is a member of two communities, Community A and Community B. A client application in Community A accesses the database server (Server 1) within the same community. Server 1 determines that the transaction must be distributed further to retrieve data from tables in Server 2 and Server 3. Server 1 initiates a connection to Server 2 in Community B to which Server 1 also belongs. Server 1 also initiates a connection to Server 3 through the MultiProtocol Interchange installed between Community B and Community C.

Server 1 does not have to use an MultiProtocol Interchange to initiate an additional request for data from Community B since it belongs to both Community A and Community B, but it must use an Interchange to access a server in Community C.

Note that using the Interchange imposes no new restrictions on a SQL*Net connection. If used in a client-server connection, clients have a standard peer-to-peer connection between the client and server although they are in different communities.

Similarly, if a server initiates a connection with another server through an Interchange using a database link, the standard database link restrictions apply.


Contents Index Home Previous Next