2
The Role of the Heterogeneous Services Component

Oracle's synchronous solutions for operating in a heter ogeneous environment are Oracle Transparent Gateways and Generic Connectivity. The common component of the Oracle database server for supporting these solutions is Heterogeneous Services. This chapter describes the architecture and functionality of the Heterogeneous Services component and its interaction with Oracle Transparent Gateways and Generic Connectivity.

This chapter contains these topics:

• Heterogeneous Connectivity Process Architecture
• Heterogeneous Services Agents
• Types of Heterogeneous Services Agents
• Het erogeneous Services Components
• Configuring He terogeneous Services
• The Heterogeneous Servic es Data Dictionary
• Gateway Process Flow

Hete rogeneous Connectivity Process Architecture

At a high level, Oracle heterogeneous connectivity process architecture is structured as shown in Figure 2-1.

Figure 2-1 Oracle Heterogeneous Connectivity Process Architecture

Text description of the illustration heter006.gif

The Hetero geneous Services component in the Oracle database server talks to a Heterogeneous Services agent process which, in turn, talks to the non-Oracle system. We can conceptually divide the code into three parts:

• The Heterogeneous Services component in the Oracle database server. Most of the heterogeneous connectivity related proces sing is done in this module.
• Agent generic code. This is code in the agent tha t is generic to all Heterogeneous Services based products. This consists, for the most part, of code to communicate with the database and multithreading support.
• The driver. This is the module that communicates with the non-Oracle system. It is used to map calls from the Heterogeneous Services external application programming interface (API) onto the native API of the non-Oracle system and it is non-Oracle system specific.

Heterogeneous Services Agents

A Heterogeneous Service agent is the process through which an Oracle server connects to a n on-Oracle system. This agent process that accesses a non-Oracle system is called a gateway. Access to all gateways goes through the H eterogeneous Services component in the Oracle server and all gateways contain the same agent-generic code. Each gateway has a differe nt driver linked in that maps the Heterogeneous Services application programming interface (API) to the client API of the non-Oracle system.

The agent process consists of two components. These are agent generic code and a no n-Oracle system-specific driver. An agent exists primarily to isolate the Oracle database server from third-party code. In order for a process to access the non-Oracle system, the non-Oracle system client libraries have to be linked into it. In the absence of the ag ent process, these libraries would have to be directly linked into the Oracle database and problems in this code could cause the Orac le server to go down. Having an agent process isolates the Oracle server from any problems in third-party code so that even if a fata l error takes place, only the agent process will end.

An agent can reside in the following places:

• On the same machine as the non-Oracle system
• On the same machine as the Oracle server
• On a machine different from either of these two

Agent processes are usually started when a user session makes its first non-Oracle system access through a database link. These connections are made using Oracle 's remote data access software, Oracle Net Services, which enables both client/server and server-server communication. The agent proc ess continues to run until the user session is disconnected or the database link is explicitly closed.

Multithreaded agents behave slightly differently. They have to be explicitly started and shut down by a database administ rator instead of automatically being spawned by Oracle Net Services.

Types of Heterogeneous Services Agents

There are two types of Heterogeneous Services agents:

• Oracle Transparent Gateways
• Generic Connectivity Agents

Oracle Transparent Gateways

An Oracle Transparent Gateway is a gateway that is designed for accessing a specific n on-Oracle system. Oracle Corporation provides gateways to access several commercially produced non-Oracle systems; many of these gate ways have been ported to several platforms. For example, an Oracle Transparent Gateway for Sybase on Solaris is the Solaris port of a gateway designed to access Sybase database systems.

With Oracle Transparent Gateways, you can use an Oracle database server to access data anywhere in a distributed database system without being required to know either the location of the data or how it is stored. When the results of your queries are returned to you by the Oracle database server, they ar e presented to you as if the data stores from which they were taken all resided within a remote instance of an Oracle distributed dat abase.

Ge neric Connectivity Agents

In addition to Oracle Transparent Gateways for various non-Oracle database systems, there is a set of agents that comprise the Oracle Generic Connectivity feature. These agent s contain only generic code and the customer is responsible for providing the necessary drivers. Oracle has Generic Connectivity agen ts for ODBC and OLE DB that enable you to use ODBC and OLEDB drivers to access non-Oracle systems that have an ODBC or an OLE DB inte rface.

To access a specific non-Oracle system using Generic Connectivity agents, you must c onfigure an ODBC or OLE DB driver to the non-Oracle system. These drivers are not provided by Oracle corporation. However, as long as Oracle Corporation supports the ODBC and OLE DB protocols, you can use the Generic Connectivity feature to access any non-Oracle sys tem that can be accessed using an ODBC or OLE DB driver.

Generic Connectivity agents have s ome limitations. Connections to a Generic Connectivity agent can be made only for the local Oracle database server. Functionality of these agents, especially when compared to the Oracle Transparent Gateways, is limited.

Heterogeneous Services Components

This section discusses the components of Heterogeneous Services in the Oracle database server. The se components are:

• Transaction Se rvice
• SQL Service

Transaction Service

The transaction service component of the Heterogeneous Services component makes it possible for non-Oracle systems to be integrated into Oracle database server transactions and sessions. When you access a no n-Oracle system for the first time over a database link within your Oracle user session, you transparently set up an authenticated se ssion in the non-Oracle system. At the end of your Oracle user session, the authenticated session in the non-Oracle database system i s also closed.

Additionally, one or more non-Oracle systems can participate in an Oracle di stributed transaction. When an application commits a transaction, Oracle's two-phase commit protocol accesses the non-Oracle database system to coordinate transparently the distributed transaction. Even in those cases where the non-Oracle system does not support all aspects of Oracle two-phase commit protocol, Oracle can (with some limitations) support distributed transactions with the non-Oracle system.

SQL Service

The Structured Query Language (SQL) service handles the processing of all SQL-related operations. The work done by the SQL service includes:

• Mapping Oracle internal SQL-related calls to the Heterogeneous Services driver application programing interfac e (API); this is in turn mapped by the driver to the client API of the non-Oracle system
• Translating SQL statements from Oracle's SQL dialect to the SQL dialect of the non-Oracle system
• Translating queries that reference Oracle data dictionary tables to queries that extract the necessary information from the non-Oracle system data dictionary
• Converting data from no n-Oracle system datatypes to Oracle datatypes and back
• Making up for missing f unctionality at the non-Oracle system by issuing multiple queries to get the necessary data and doing post processing to get the desi red results

Configuring Heterogeneous Services

In the previous section, we described what the different heterogeneous components do. These components consist entirely of generic code and, in order to work with so many different non-Oracle systems, their behavior has to be configured. Each gateway has configuration information stored in the driver module and this information is uploaded to the server immediately after the connection to the gateway has been establishe d. We can divide this configuration information into three parts:

• Data Dictionary Translations
• Heterogeneous Services Initialization Parameters
• Capabilities

Data Dictionary Translations

Data dictionary translations are views on non-Oracle system data dictionary tables that help Heterogeneous Services translate references to Oracle data dictionary tables into queries needed to retrieve the equivalent information from the non-Oracle system data dictionar y.

Het erogeneous Services Initialization Parameters

Heterogeneous Services initialization parameters serve two functions.

• They give the user a means of fine-tuning the gateway to optimize performance and memory utilization for the gateway and the Heterogeneous Services component.
• They enable the user to tell the gateway (and, thereby, Heterogene ous Services) how the non-Oracle system has been configured (for example what language the non-Oracle system is running in). To put i t another way, they give Heterogeneous Services information about the configurable properties of the non-Oracle system.

You can examine the Heterogeneous Services initialization parameters for a session by querying the view V$HS_PARAMETER. Users can set initialization parameters in gateway initialization files.

Capabilities

Capabilities tell Heterogeneous Services about the limitations of the non-Oracle system ( such as what types of SQL statements are and are not supported) and how to map Oracle datatypes and SQL expressions to their non-Orac le system equivalents. In other words, they tell Heterogeneous Services about the non-configurable properties of the non-Oracle syste m. Capabilities cannot be changed by the user.

The Heterogeneous Services Data Dictionary

< p class="BP">As mentioned in the previous section, configuration information is uploaded from an agent to the Heterogeneous Services component immediately after the connection to the agent has been established. Because this information can be very large in size, it is inefficient to do uploads on each connection. Therefore, the first time an Oracle database talks to an agent, the configuration in formation is uploaded and stored in Heterogeneous Services data dictionary tables and thereafter no upload takes place until somethin g at the agent changes (for example, if a patch is applied or if the agent is upgraded to a new version).

Classes and Instances

Using Heterogeneous Services, a user can access several non-Oracle systems from a single Oracle database. This is illustrated in Figure 2-2, which shows two non-Oracle systems b eing accessed.

Figure 2-2 Accessing Multiple Non-Oracle Instances

Text description of the illustration heter002.gif

B oth agents upload configuration information, which is stored as part of the Heterogeneous Services data dictionary information on the Oracle database server.

Although it is possible to store data dictionary information at on e level of granularity by having completely separate definitions in the Heterogeneous Services data dictionary for each individual in stance, this might lead to an unnecessarily large amount of redundant data dictionary information. To avoid this, Oracle organizes th e Heterogeneous Services data dictionary by two levels of granularity, called class and instance.

A class pertains to a specific type of non-Oracle system. For example, you might want to access the class of Sybase database s ystems with your Oracle database server. An instance defines specializations within a class. For example, you might want to access se veral separate instances within a Sybase database system. Each class definition (one level of granularity) is shared by all the parti cular instances (a second level of granularity) under that class. Further, instance information takes precedence over class informati on, and class information takes precedence over server-supplied defaults.

For example, supp ose that the Oracle database server accesses three instances of Sybase and two instances of Ingres II. Sybase and Ingres II each have their own code, requiring separate class definitions for the Oracle database server to access them. The Heterogeneous Services data dictionary therefore would contain two class definitions, one for Sybase and one for Ingres II, with five instance definitions, one f or each instance being accessed by the Oracle database server.

Note that instance level cap ability and data dictionary information are session specific and hence are not stored in the Heterogeneous Services data dictionary o f the Oracle database server. However, instance level initialization parameters can be stored in the database.

Data Dictionary Views

The Heterogeneous Services data dictionary views contain the following kinds of information:

• Names of instances and classes uploaded into t he Oracle data dictionary
• Capabilities, including SQL translations, defined fo r each class or instance
• Data Dictionary translations defined for each class o r instance
• Initialization parameters defined for each class or instance

You can access information from the Oracle data dictionary by using fixed views. The views are categorized into three main types:

• General views
• Views used for the transaction service
• Views used for the SQL service

See Also: Appendix C, "Data Dictionary Translation Support"

See Also: Appendix C, "Data Dictionary Trans lation Support"