Quo Vadis
Articles and Tips: article
Senior Research Engineer
Developer Information
LAWRENCE V. FISHER
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.
Introduction
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.
Clients
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.
Services
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.
Communications
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.
Applications
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 madair@novell.com
Lawrence V. Fisher lfisher@novell.com
Thanks. See you next month.
* Originally published in Novell AppNotes
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.