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.
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.
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:
The Entera Toolkit requires the following steps in application development:
The complexities of using the native DCE API set are:
The advantages of using the native DCE API set are:
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.
Both Connection/DCE and Entera let the end user set the protection level at runtime.
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.
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.
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 Users Group of Michigan (DUGM)
Author: Janani Janakiraman