Novell is now a part of Micro Focus

The Transformation of API_Info into a Multi-tiered, Database Application: A Series

Articles and Tips: article

LAWRENCE V. FISHER
Senior Research Engineer
Developer Information

01 Jul 1998


The first in a series of articles which will take you through the steps to build a C-based Client/server application into a Java-based, multi-tiered, distributed application.

Introduction

In December 1997, we published an article entitled, "Quo Vadis," or "Where Are You Going?" In that article, we described the direction for the articles we (Novell Developer Notes staff writers) were going to write in the future. Since that time, Novell has introduced OSA (Open Solutions Architecture). For more information on OSA, see the March 1998 issue of Novell Developer Notes.

Putting it all together, we asked ourselves, "Why not use our new direction to give developers some examples of how to put a multi-tiered NDS application together using OSA?"

In the design phase, we realized that an application that truly represents the basics of what developers need to do would be sizeable. This created a problem because every developer is at a different place and probably wouldn't want to sort through some huge application to find specific example.

In order to accommodate as many levels as possible, we decided to create a progression of examples from a C-based client/server application to a Java-based, multi-tiered, distributed application called AnyInfo. Each example will correspond to a Web page containing a diagram, explanatory Novell Developer Notes articles, and sources in a buildable project downloadable from our Web site.

The result, we hope, will be a collection of articles that show you how to evolve a C-based application towards Java-based multi-tiered goals in buildable steps.

The figures on the following pages illustrate examples that have either already been implemented in previous articles or will be implemented in the next few issues.

Note: If you have an idea for an additional example, we would like to hear from you. E-mail your requests to larry_fisher@novell.com.

Example 1: A completely C-based, NDS enabled, network application called API_Info with a Windows client, a service NLM, and an NWAdmin snap-in.

Example 2: API_Info is extended with Java applets so that users can access the application with browsers.

Example 3: Add Java snap-ins so that the application's NDS component can be administered with ConsoleOne.

Example 4: Extend the schema design to provide for NDS scalability.

Example 5: Enable the application's Java Applets to access NDS via Novell Java Beans on the server.

Example 6: Add RMI for communication between middle tiers and the application's distributed services.

Example 7: Replace old API_Info service NLMs with Oracle8 databases using JDBC drivers for access.

Example 8: Add CORBA to restore access to old API_Info service NLMs in the new multi-tiered model.

Example 1: A C-based, NDS Enabled, Network Application, Called API_Info

Example 1 is an entirely C-based, client-network, fully NDS enabled application. It has already been implemented in the following Novell Developer Notes article series:

  • "Anatomy of a Simple IntranetWare Client/Server Application", Pt 1- September 1997

  • "Anatomy of a Simple IntranetWare Client/Server Application", Pt 2- October 1997

  • "Anatomy of a Simple IntranetWare Client/Server Application", Pt 3- November 1997

The above articles were based on an application called API_Info. The API_Info application itself consists of:

  • any number of API_Info clients running on intraNetWare client32 enabled stations.

  • any number of API_Info NLMs running on intraNetWare servers.

  • an appropriate number of NDS objects in multiple NDS trees representing instances of the NLMs running on servers in those trees.

  • an NWAdmin snap-in to extend NDS schemas for the application's object type and administer the application's NDS objects.

API_Info connects to its found service NLMs via NetWare's NCP extension mechanism. The NLM then accesses its own simple data store (equivalent to a hash table).

Although the articles listed above for Example 1 have described API_Info as containing only API prototype information, the application can contain any kind of single-item data. I use API_Info to contain my address book.

Example 2: Java Applet Clients Added

The second example consists of everything in the first example but with the added capability of Java applet clients accessing the service through a Java/NLM gateway. By using a Java/NLM gateway, API_Info extends its client base to include applets running in Java-enabled browsers.

Example 2 has already been implemented in the following Novell Developer Notes article series:

  • "Extending Your NLM System Into Java, with Ease" - January 1998

  • "The Java Side of the API_Info Java/NLM Gateway" - January 1998

  • "The NLM Side of the API_Info Java/NLM Gateway" - February 1998

This example allows a user to access the application from any platform without installing application client software or the NetWare client. Applet clients can often be added to a NetWare application without any recoding of its C-based parts.

Example 2 is the beginning of the conversion of API_Info into the multi-tiered distributed application we will call AnyInfo. However in example 2, AnyInfo still uses the API_Info service to access its data store, the Applet clients have no NDS capability, and there is no security. These deficiencies will be corrected in later examples.

Example 3: ConsoleOne Snap-ins Added

Example 3 further transforms API_Info into AnyInfo with the addition of Java ConsoleOne snap-ins to administer API_Info objects. Note that the objects shown in the NDS tree are still instantiated from the API_Info class. This will change in Example 4 when AnyInfo classes will be designed to improve the application's NDS scalability.

Example 3 has already been implemented in the following Novell Developer Notes article series:

  • "Introducing OSA's New Tools Platform, ConsoleOne" - March 1998

  • "Snapping Your NDS App in to ConsoleOne" - March 1998

  • "Adding a Property Page to ConsoleOne" - April 1998

  • "Extending an NDS Schema With ConsoleOne's NDS Namespace" - May 1998

Example 4: NDS Schema is Extended for Application Scalability

Example 4 is the first example that has not already been implemented in previous articles.

The API_Info class added to the schema in example 1, allowed the administrator to create API_Info objects in an NDS tree that would contain the locations of API_Info service instances and their associated databases. In order to find a particular database, API_Info had to search the whole tree for objects of type API_Info. In a large tree with thousands of objects, this could take quite a while. This example will explain how to eliminate this scalability problem.

In example 4, we will extend the schema for a couple of new classes. The first new class will be much like the old API_Info class in that it will contain a service location attribute and an attribute to reference the application's administrator. However, the AnyInfo class will also have an additional attribute to contain the subject name for the database at its service location.

Example 4, will explain how to add a class called AnyInfoList to contain references to all of the AnyInfo objects created in the tree. Administration is kept minimal by automating list maintenance with ConsoleOne snap-in functionality. Since the attributes used for the list are of the distinguished name syntax, when an administrator adds an AnyInfo object, AnyInfo's ConsoleOne snap-ins will automatically add a reference to the new object to the list. When an AnyInfo object is deleted, NDS will automatically delete its reference from the list. Also, if a referenced object is moved, NDS will automatically update its reference in the list to point to the new location.

Source code and an article for example 4 will be available in the August issue of Novell Developer Notes.

Example 5: Novell's NDS Java Beans Added

In example 5, the proxy application is extended to provide the NDS access needed by the client applets to select a tree and then search it for database location objects. This NDS access is accomplished with Novell's NetWare Java Beans SDK.

When the AnyInfo client applet is loaded into the user's browser, it will set up input and output streams with a Client Proxy Application thread spawned for it. This thread will contain the state information necessary to maintain the user's connection, (e.g., tree and database selections, etc.)

After this, the Proxy Application thread will send the Applet a list of trees, allowing the user to select a tree.

After a tree is selected, the Client Proxy Application will access its AnyInfo List object to obtain a reference to each of the tree's AnyInfo data location objects, (the schema extensions necessary to implement this were added in example 4.)

The Client Proxy Application reads the Subject attribute from each data location object referenced by the list object and then builds a list of available subject names. When the search is finished, it sends the list to the user so that a subject database can be selected. Once the user has selected a subject, the Client Proxy Application will make the connection to the appropriate database to handle requests.

Note: The connection to the selected database is no longer made with an NCP extension. Instead, a Client Proxy Application will make a connection to an Access Proxy Application on the database's server using a Socket, (explained in example 2.) A native method GateWay NLM is still needed in this example for the Client Proxy Application to access the old API_Info service NLM. In example 6, the API_Info service NLMs will be replaced by Oracle8 databases accessed by JDBC using SQL.

Source code and an article for example 5 will be available in the September issue of Novell Developer Notes.

Example 6: RMI Access to Distributed Services Added

In example 6, the NCP extension method used by the old API_Info example application to connect to distributed services is replaced by RMI (Remote Method Invocation).

In Java's distributed object model, RMI is used to connect special objects (called remote objects) which can be distributed over a network. A Java remote object is any object that extends the java.rmi.Remote class.

Your code in one Java virtual machine can obtain a reference to a remote object in another virtual machine and then call the remote object's methods as if they were in the same machine. In the case of this example, the calling VMs will be on different servers.

However, this communication method only works with Java remote objects. So, it is strictly a Java to Java solution. Example 8 demonstrates how to access legacy distributed services based on other languages, for example C, using CORBA.

Source code and an article for example 6 will be available in the October issue of Novell Developer Notes.

Example 7: Oracle8 with JDBC Access Added

In example 7, the old API_Info service NLM is replaced by an Oracle8 database.

The Access Proxy Application now interprets the request buffer initially sent by the user's Client Applet and uses JDBC to make the appropriate SQL request to the Oracle8 DBMS.

There are many variations of SQL among vendors. Since you probably already know what flavor of SQL you want to use, the database used in this example will be very simple, comprised only of a single two column table. One column is used for the key and the other for the data. This will help limit the SQL needed.

Source code and an article for example 7 will be available in the November issue of Novell Developer Notes.

Example 8: CORBA Access to Legacy Services Added

Example 8 adds CORBA access so that we can access the old API_Info NLM services in our new model.

CORBA uses a special language called IDL, (Interface Description Language) to define interface points between executables. Since there are IDL compilers for all major languages, you can build a system where Java code can call C code through IDL and vice-versa.

There is much more to say about CORBA, which we will try to do when we discuss example 8 in the December issue of Novell Developer Notes.

Our Download Site

Use the URL shown below to access our download site for all source examples.

http://www.novell.com/coolsolutions/tools/index.html

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates