Data Access With DCE (DAD)

With the shift to the client/server paradigm, users sitting at their client machines expect to be able to access data from various sources. Accessing data from a remote client in a distributed environment poses certain challenges:

Current tools for remote data access such as SQLNet do a poor job of addressing the above challenges.

The Distributed Computing Environment (DCE) is the most comprehensive and open solution that addresses the challenges posed by distributed computing. Some of the services it provides are:

DCE exports a set of APIs, which can be used by developers to build their client/server applications. Various third-party vendors have built additional layers on top of DCE to ease the work for the developers.

Approaches

There are some approaches you can take to build an application that accesses data in a DBMS from a remote client machine:

In our project, data is stored in an Oracle DBMS that runs on an AIX server. The client runs on a Windows machine and the front end is built using PowerBuilder.

Connection/DCE for OCI

If you have existing remote database applications that use PowerBuilder as the front end to access data from a remote Oracle server using SQLnet or some other product, the application need not be modified at all to use Connection/DCE. Connection/DCE is implemented as a generic OCI driver on the client end. The client PC as well as the server machine need to be on the DCE network.

On the server side, some configuring is necessary to set up the server program (one time). Once the setup is complete, a simple one-line command starts the server. The end user sees no difference if s/he uses the Connection/DCE product, as opposed to using SQLnet. But under the hood, DCE provides all its benefits:

Entera Toolkit

The Entera Toolkit requires the following steps in application development:

  1. Write the SQL statement file (Entera-compliant format).
  2. Run SQLMAKE to generate the definition file and client stubs.
  3. Start the database server (using ORA_START utility).
  4. Write the client application (using PowerBuilder):

Native DCE API Set

The complexities of using the native DCE API set are:

The advantages of using the native DCE API set are:

Comparison of Approaches

The above three approaches really are different styles of programming, and therefore difficult to compare directly, but we can look at some issues pertaining to each.

Setting protection levels at runtime

Both Connection/DCE and Entera let the end user set the protection level at runtime.

Transparent database access

Because the server can use the Cell Directory Service (CDS) to store its bindings, the clients need not be aware of the actual location/name of the server machine.

Connecting to the DBMS

Connection/DCE provides the capability to do a proxy login. The database passwords are never sent across the network when proxy login is switched on. The proxy login switch is set by the server. If a user chooses to use proxy login, s/he cannot access her/his DB account from an application that does not go through Connection/DCE.

Entera does not provide a built-in proxy login mechanism. The user needs to first get DCE credentials and then login to the DB supplying her/his DB user name and password. Entera provides a simple API call to connect to the DB and set up the DB context.

Using the native DCE API set, the developer needs to use the Oracle Call Interface (OCI) to connect to the database. The developer also must design RPC calls that let the client perform all the steps needed to login to the DBMS.

Modifying the existing application

Connection/DCE seemlessly integrates with existing PowerBuilder applications. There is no need to write any interface definition files or server-side code.

Entera provides the capability to generate stubs for PowerBuilder, but the application programmer needs to rewrite portions of the application to make the Entera API calls (for connecting to the database, making queries, etc.). The interface definition files can be written in Entera-compliant SQL format instead of DCE IDL. There is no need to write any code for the server program, because it provides ready-made server start-up programs.

Using the native DCE API set, the developer first needs to write the interface definition file using DCE IDL. Furthermore, native DCE provides the capability to generate stubs in C only (no support for PowerBuilder or any other language). One also needs to be familiar with OCI.

DCE skills required by the developer

Interfacing with the DBMS

Customizing applications

Software needed


DCE Users Group of Michigan (DUGM)
Author:
Janani Janakiraman
Revised: 06/14/96
URL: http://www.citi.umich.edu/dugm