Novell is now a part of Micro Focus

Quo Vadis

Articles and Tips: article

Senior Research Engineer
Developer Information

Senior Research Engineer
Developer Information

01 Dec 1997

The fourth installment in a series of articles on the anatomy of a simple IntranetWare client/server application. This article discusses key technologies such as NDS, Java, ORB, and RMI and tells how they will be addressed in future articles.


We interrupt this series of articles ("The Anatomy of a Simple IntranetWare Client/Server Application," Parts 1, 2, 3, in the September, October, and November issues, respectively) to ask you (and let you ask us) this important question: "Quo Vadis?" (Where are you going?) and to interject some important (and parenthetical) comments.

In this DevNote, we'll do a brief review of the material Larry covered in the first three articles in this series. Then, we'll talk about some of the technologies emerging along the golden road to network-centric computing and how we'll address them in future articles.

Where We've Been

In the September, October, and November issues, Larry Fisher had a series of three articles called "The Anatomy of a Simple IntranetWare Client/Server Application." These articles described how to build the server, installation/administration, and client pieces of a NetWare-based client/server application called API_INFO.

"The Anatomy of a Simple IntranetWare Client/Server Application, Part I" covered the server part of the application, which was implemented as an NLM, and covered:

  • The anatomy of a simple NLM

  • Some simple load balancing guidelines

  • How to develop a simple NLM

  • Using an NCP (NetWare Core Protocol) extension to expose your NLM's service on the network.

"The Anatomy of a Simple IntranetWare Client/Server Application, Part II" in the October issue talked about how to develop the NWAdmin snap-in used to install and administer the API_INFO program. The article covered:

  • NDS schema composition

  • Designing new classes and attributes

  • Extending an NDS schema

  • The NWAdmin Snap-in protocol

Last month's installment, "The Anatomy of a Simple IntranetWare Client/Server Application, Part III" showed how to develop the client part of the application. It talked about:

  • How to develop a simple IntranetWare client

  • Searching an NDS tree to acquire the optimal service instance for your client

  • Connecting to the service

  • Navigating NDS trees in a multi-tree environment

Where We're Going

Up to this point, this series of articles has focussed on Novell's traditional business. NLMs and NDS have been part of the Novell development picture for at least 5 years. While there are many developers who will continue to work in this architecture, the world is changing, and Novell is driving the acceptance of a number of new technologies. In future articles in this series, we will show how these emerging technologies (see Figure 1) integrate with the NetWare world we have come to know and love.

Figure 1: Some technologies that you'll be reading about in Developer Notes.

Building on the foundation of the API_INFO distributed application that Larry presented in the first three articles in this series, we'll explore how these technologies can extend the reach of applications you develop out into Internet space.


Novell has always been one of the industry's strongest supporters of client heterogeneity. The Internet explosion has only increased the number of client platforms that can access data on your NetWare/IntranetWare servers.

Applets. One of the most exciting innovations for NetWare developers is the ability of a Java applet running in a browser to act as a NetWare client. In the next article in this series, we'll show how an applet can act as a client to an existing NLM. See "Next Month" later in this article for more information.

IntranetWare. Last month's article in this series showed how to develop a client application using some of NetWare's client APIs. We will continue to cover the client APIs that support NetWare's traditional client base (Windows 95 and NT, Macintosh, and OS/2).

Unix. Unix has not been a significant part of the NetWare client picture. We believe a new NetWare client for Unix (sorry, we can't announce when it will be released) will change this. When it happens, we'll tell you about the client services available to Unix clients, and provide examples of client applications for Unix.


Clients not only access the file, print, and directory services provided by NetWare and NDS, but also access services provided by distributed applications you develop.

NLM. NLMs have been the primary platform for providing distributed services in a NetWare environment. Next month's article will show how to extend services provided by an NLM to a Java client.

Java. Novell's Web Server enables you to provide services written as Java applications. Next month's article will be the first of several that will show how an application written in Java can provide services to clients.

Legacy (Mini/Mainframe). Many of the services that your clients need access to exist on legacy systems. The series of articles on Novell Trader describes how a client can use CORBA to access services that may be provided by a legacy system. See the following Novell Developer Notes articles for more information:

  • "Novell Trader Service Architectural Overview," by John Christensen, August '97.

  • "Using the Novell Trader," by Sheldon Bagley, October '97.

  • "Novell Helper Class: Trader Service," by Paul Roper, November'97.

  • "Novell Trader: An Advanced Tutorial on Registration and Server Object Creation," by Robert Whitehead, December '97.

Directory Services

NDS is another area that is expanding to new servers and into the Internet. Although NDS will comprise the same set of services, regardless of the provider platform, the choice of platform may impact the overall architecture of your distributed application.

NDS on IntranetWare. As the primary platform for NDS, IntranetWare has been the focus of several articles on NDS development, and will continue to be a focus in future articles.

NDS for NT. Recently released in beta, NDS for NT provides the same services for managing network resources for NT servers that NetWare/IntranetWare servers have had for years. An article in this series will illustrate a distributed application based on NDS for NT.

NDS for Unix. When available, we will demonstrate a distributed application using NDS provided by a Unix server.

LDAP. Lightweight Directory Access Protocol (LDAP) is becoming the de facto standard for accessing directory information over the Internet or intranets. An article in the near future will show how to access NDS resources from an Internet client via LDAP.


Example applications we will provide will utilize communication protocols at several levels.

IPX/SPX. Current versions of NetWare/IntranetWare use IPX/SPX as the default protocol. Although we will probably not provide code that explicitly utilizes IPX/SPX, some of our example programs (the first three articles in this series, for example) will work in the typical IPX/SPX-based network environment.

TCP/IP. The next release of IntranetWare (code-named Moab) will use TCP/IP as its communications protocol. Some of the applications demonstrated in future articles will rely on the presence of TCP/IP as the underlying communications protocol.

RMI. Remote Method Invocation (RMI) enables you to create distributed Java-to-Java applications, in which the methods of remote Java objects can be invoked from other Java virtual machines, possibly on different hosts. Sun is adding the capability to RMI to use IIOP to access objects. A future article will highlight a distributed application using RMI.

IIOP, SSL, and CORBA. Internet Inter-ORB Protocol (IIOP) is a transport protocol which is part of the Object Management Group's Common Object Request Broker Architecture (CORBA) for distributed computing. IIOP uses the Secure Sockets Layer 3.0 (SSL) to ensure security. One of our future articles will incorporate all these aspects of the CORBA architecture into a reimplementation of the API_INFO distributed application.

Language Environments

C/C++. NetWare applications are traditionally implemented in C/C++. Example programs we provide with our future articles will continue to use C/C++ where appropriate.

Java. Java is becoming a language for developing both client and server components of distributed applications. See next month's article for an example of a Java-based application that accesses IntranetWare-based services provided by an NLM.

IDL. The Interface Definition Language (IDL) is used to define the interface between CORBA-compliant parts of a distributed application. Our article that redeploys our distributed application as a CORBA-compliant application will use IDL to define the interfaces between the distributed components.


The example programs we will provide in this article series will take the form of distributed applications (simple databases like API_INFO, for example), utilities to install and administer the distributed applications, and network management utilities.

Next Month

Next month, we will take Larry's distributed application and make it accessible from a Java-enabled browser. This rearchitecture of the program will not require any change to the NLM that provides the service (API_INFO). We will do this by implementing an NLM that handles the communication between the web server and the service provider NLM using Java's Native Method Interface (NMI).

Quo Vadis?

We'd love to hear your thoughts on

  • Novell's direction,

  • How you plan to use the emerging technologies described in this article,

  • Information you need from Novell to do your job.

Please direct your comments to:

Morgan B. Adair

Lawrence V. Fisher

Thanks. See you next month.

* Originally published in Novell AppNotes


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