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.
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
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.