The NCF Programming Model: A Developer's Perspective

From EDM2
Jump to: navigation, search

by Michael H. Conner

The Network Computing Framework (NCF) is a comprehensive software roadmap for implementing e-business solutions. IBM and its subsidiary, Lotus Development Corp., announced plans for NCF in April of this year. Some of the IBM components of NCF are nearing completion, for example, tools like the VisualAge Generator for Java, and systems management using Tivoli components, and are discussed in other articles in this magazine. Still other components are scheduled for completion in the next few months and will be highlighted in future issues, for example the San Francisco project (object-oriented functions to build industry specific business applications). Working with customers over the last year, IBM has delivered some of the industry's most ambitious network computing solutions. The IBM Network Computing Framework is based on the lessons learned from that experience.

The Internet and private intranets represent great new opportunities to tackle fundamental business problems. Based on easily adopted Internet standards, applications can connect disparate systems and decentralized technologies. These standards are very good news for anyone who is trying to make sense of a diverse, multi-vendor technology world.

The NCF provides an integrated development and execution environment based on the Java programming language that allows developers to leverage all of the great new opportunities coming from the World Wide Web. The NCF allows developers to work in a single programming language and yet exploit all of the features of browser-based clients, and have full access to their preexisting application and data resources. This article is a brief introduction to programming in the NCF.

An Overview of NCF

The Network Computing Framework is a comprehensive framework for Web-based applications, consisting of:

  • An open, pluggable framework.
  • A set of Web application servers that are accessed through standard protocols and JavaBean component interfaces.
  • A set of clients that exploit "just in time" components like Kona Beans.
  • Tools that exploit the JavaBean component standard.
  • Standard technologies to link components (e.g. HTTP, IIOP).
  • A set of built-in groupware solutions and a foundation for e-business applications.
  • A set of "connectors" to existing data and transactions.

The elements of the NCF are shown in Figure 1.

Figure 1. The NCF model

Designing NCF Applications

Designing NCF applications is like designing other applications. One must design the user interface and the application logic (sometimes called the application model). Sometimes it is best to start with the user interface design and let that drive the design of the application logic and sometimes it is better to reverse the process and start with the application logic (or model) and then design one or more user interfaces to go with it. This section briefly illustrates a possible design approach for a simple NCF application to look up names in a company directory.

In this example, one might start with designing a JavaBean that wraps access to the company's directory application. This bean would be a pure Java class definition with properties that allow it to be configured. For example, it might have a property for the domain name of the server where the directory application runs and it might have several properties that control how name matching is to be done or that set the default company location, etc. It would likely have a property for the ookup name pattern and other access qualifiers such as location, department, etc. It also would be likely to have a read only property that contains the result of a look up, say in the form of a two dimensional array of strings where each row is one directory entry and each column is a different aspect of the directory information like first name, employee id, etc.

It would probably support a method to look up directory information based on its current property settings.

It might also support a number of event listener interfaces to make it more usable in traditional graphical user interfaces, but this is not necessary in our example where it will only be used by a servlet (a Java class derived from javax.servlet.GenericServlet).

This bean could be developed and tested without concern for HTML, or servlets, or other Web issues. Once the bean was developed, one could design a servlet that uses the bean to look up directory information and then format the information into an HTML table of the results. One way to design this servlet would be to define a method, say lookup, that takes appropriate parameters, does the lookup and writes the HTML table to an output stream that was passed in as a parameter. This method could be called from the servlet's service method, which would extract the required parameters (including the output stream) from the HTTP request, and then calls lookup to do the actual work. The advantage of this design is that one could add a main method so that the servlet class also could be used as a Java application for testing purposes. The main method could take command line arguments for the lookup parameters and then cause the output to go to System.out. This allows much of the servlet's logic, including the production of the HTML output, to be tested outside of a Web server and without use of a Web client. Once the servlet was working in this mode, it could be installed into the Web server (as little as putting it in the right place in the Web server's file system and possibly involving setting up an alias and/or access controls).

Once the servlet is finished, it would be necessary to design a Web page to invoke the servlet. This page would contain a form similar to the one shown in Figure 2. However, in this design example we choose to have our servlet produce only an HTML table with the results of the directory lookup. We still need to provide a way to generate an entire HTML page to send back to the client. There are a number of choices here. A wrapper servlet can be defined that writes the rest of the page with a call to the lookup servlet made at the appropriate point. (Servlets can invoke other servlets by just calling their service methods and forwarding the calling servlet's service method parameters to the called servlet.) Another alternative would be to use a ServletEmbed in an HTML page. ServletEmbeds are described in more detail later in this article. Briefly, they are HTML syntax that can be embedded into an HTML page. The ServletEmbed expression in the HTML page is replaced with the output of the called servlet while the Web server is sending the page to the client, so the client Web browser never sees the ServletEmbed, just the HTML that is produced by the called servlet.

Some Design Alternatives

There are many alternatives to this design. For example, one might have the lookup servlet generate the call to a Java applet rather than a simple HTML table. The applet could provide a more dynamic interface to the lookup results. Also, suppose that the amount of data returned from a lookup might be very large; then, one might want to design an applet that would use an IIOP session back to a servlet to access and display partial lookup results, fetching and displaying more results in response to user actions. These designs are clearly more complex, but given the power and completeness of the Java programming environment, it is possible to develop broadly usable applets, servlets and class libraries that greatly simplify these designs. For example, one of the Lotus Kona Beans is a spreadsheet-like Java applet. This would be used to display the query results as easily as generating an HTML table (just generate the call to the appropriate Kona Bean applet). However, you now have a live presentation of the lookup results.

Another alternative would be to add access control to a lookup servlet. This could be done by having the lookup servlet check the identity of the client user. If it is necessary to authenticate the user, then the servlet can be registered with the Web server so that it requires an HTTPS connection. Then the Web server and the Web browser can exchange certificates to verify the user's identity. This also ensures that the data flowing between the client and the server is not tampered with. It also is possible to request that the client/server communication be fully encrypted for privacy.

NCF provides tools that can help with each of the above steps. For example, VisualAge for Java can be used to define and test the lookup bean and then define and test (in application mode) the lookup servlet. NetObjects Fusion can be used to design the initial lookup Web page and the response Web page that contains the ServletEmbed. Also, the NCF programming model is based on widely adopted standards so there are a number of third party tools such as Symantec Cafe and Borland JBuilder that can be used to develop beans, applets and servlets. And, there are many tools that can be used to develop HTML and its supporting graphics.

The parts of an NCF Application

NCF applications consist of content (HTML, images, and such) and Web server based programs called servlets. The content is sent to the Web browser and processed by it. Therefore, NCF applications may leverage any features of HTML that are supported by their target Web browsers. In particular, they may leverage Java Applets. Servlets are Java objects that typically respond to HTTP requests coming from the client, usually a Web browser, and respond with HTML. Servlets are open-ended Java programs. They can use any Java library, communicate with programs on other machines, access both local and remote resources, etc.

The simple NCF application to look up names in a company directory consists of an initial HTML page with a simple form on it. The form would have a text entry field where a user could enter an employee name pattern. When the user submits the form, it would generate an HTTP get request and invoke a servlet on the Web server, passing the servlet the form data. Figure 2 illustrates how the form part of the HTML page might be coded.

Fraction of an HTML page that invokes a servlet with form data:

<FORM METHOD="GET"ACTION="/servlet/LookupNameServlet">

Employee Name: <INPUT TYPE="text"NAME="employeeName" SIZE=60> <p><INPUT TYPE="submit"Name="SubmitButton"Value="Submit"> </FORM> Figure 2. Code sample for a simple NCF application When the servlet, named LookupNameServlet in this example, is invoked, it can use the form data passed in the HTTP request to construct a request to an existing directory application (say, via a TCP/IP session), get the response from this application, and format it into HTML that it writes back to the client browser. This simple example illustrates four primary aspects of NCF applications: Content, Servlets, Client/Server communication and Backend access.


Content refers to MIME data that is sent to a client system to provide the user interface to an NCF application. NCF applications produce MIME data of various types, such as HTML, GIF, TIF, JPEG, etc. An NCF application's content can come from:

  • Static files.
  • Dynamic files: HTML files that contain references to Java servlets, called ServletEmbeds, that run as the file is being sent to the client and dynamically provide part of the file's content (these are discussed in more detail below).
  • Rich text format data in a Domino store that is dynamically converted to HTML by the Domino system.
  • Servlets that run in response to HTTP requests and generate MIME data.

The only restriction on the MIME data produced by an NCF application is that it must be processable by the client. NCF is open with respect to client systems. However, to fully leverage the NCF features and infrastructure, a client system should support both HTML and Java programs that run in the client system called applets. Clients are expected to fully support, at least, the features of Java 1.02, and some of the advanced client support in NCF requires that the client support Java 1.1.

NCF provides tools including NetObjects Fusion, Lotus BeanMachine, and VisualAge Java that can be used to construct content, especially applets. However, NCF leverages standard content types and, therefore, there are many third party tools that also can be used, especially in the generation of HTML, images, etc.


At the center of every NCF application is one or more Java servlets. Servlets are very similar to CGI-BIN programs and Web server plug-ins (programs written to Web server plug-in APIs like NSAPI, ISAPI, or ICAPI), except that they are written in Java and run in a Java Virtual Machine managed by the Web server. These servlets coordinate the steps of the application and provide most of its function. Servlets are Java classes that support the javax.servlet.Servlet interface.

Essentially, a servlet's job is to process a request (usually an HTTP or HTTPS request) and produce MIME data (usually HTML). Servlets are registered with the Web server and they can be named in URLs in HTML forms or even in simple HTML links. When the form is submitted or the link is followed, the Web browser will construct an appropriate HTTP or HTTPS request including parameters, and/or a query string as specified in the HTML. The Web server will receive this request and direct it to the appropriate servlet's service [1] method, first creating an instance of the servlet if necessary. The servlet's service method is passed two parameters, a javax.servlet.Request and a javax.servlet.Response. The request parameter gives the servlet convenient access to information in the HTTP request including:

  • The URL of the request, including the query parameters, and the query string.
  • The identity of the remote user and how the user was authenticated.
  • Context information about the client system and the server.
  • The types of the request (get, post, etc.).
  • Any cookies transmitted with the request.

The response parameter provides methods that allow the servlet to respond to the HTTP request. In particular, the response provides a stream to which the servlet can write. The stream delivers anything that the servlet writes (e.g., HTML) to the Web browser as the content of the HTTP response.

The details of the Java servlet interfaces and classes are defined in the standard Java packages javax.servlet and javax.servlet.http. JavaSoft provides the Java Servlet Toolkit which you can download from the JavaSoft Web site at This toolkit contains the interfaces and classes related to servlets. JavaSoft, also, has produced a white paper on servlets that can be found on the JavaSoft Web site. This JavaSoft white paper provides a good introduction to what servlets are and how to work with them.


One of the features of NCF is support for ServletEmbeds. ServletEmbeds allow one to separate the static parts of an HTML page from the dynamic parts. For example, if a page needed to contain a table with data extracted from a database but the rest of the page was always the same, then the static part of the page could be authored in HTML and a ServletEmbed used to generate the dynamic part. The HTML syntax for a ServletEmbed looks like:

<servlet name=Lookup
 <param name=foo1 value="bar">
 <param name=foo2 value="baz">

This would call the servlet registered under the name Lookup. The two named parameters are passed to the servlet just like form data parameters are passed. Other forms of the ServletEmbed syntax allow the class of the servlet to be specified and initialization parameters to be passed. In all cases, when the servlet is called, it receives the HTTP context of the page so it can inquire about the remote user and such, just like a top level servlet.

The Web server processes ServletEmbeds as it is sending their containing page to the client Web browser. When it gets to a ServletEmbed, it invokes the specified servlet and directs the servlets output HTML to the client Web browser so that it is inserted into the page in place of the ServletEmbed expression.

This allows a separation of concerns between programmers writing servlets and content developers writing HTML. It also allows one to leverage HTML editing tools to produce Web pages with dynamic content.

In a future release of the NCF technology, we expect to support full server-side scripting. This will extend the ServletEmbed mechanism by allowing fragments of programming logic to be inserted in the HTML page. While this does not enable servlets and ServletEmbeds to do anything more than they already do now, it does make servlets more generic and improves their reusability.

Client/Server Communication

NCF provides both client and server support for HTTP, HTTPS, and IIOP. HTTP is the standard protocol for client/server communication on the Web, however it is fairly inefficient and insecure. HTTPS is an industry standard extension to HTTP that adds security based on SSL version 3. This is a public-key/private-key based protocol that allows an untrusting client to set up a secure session with an untrusting server. In this session the server knows the client's identity and the client knows the server's identity. In addition, data is sent encrypted and noncorruptable.

NCF also supports the Object Management Group's CORBA IIOP standard for remote method call support. With this support an applet running in the client can establish a connection to a servlet running in the Web server and pass method calls back and forth. NCF supports IIOP in both a standard mode that allows interoperability with other IIOP clients and servers and an enhanced mode that allows IIOP requests to be carried over HTTP sessions (therefore, leveraging HTTP session setup) and to carry object parameters by value as well as reference (the norm). When objects are passed by value, a new object is created in the target process with a copy of the calling process' object's value. This allows the target process to call methods on the object without incurring the overhead of a remote method call as would be required if the object was passed by reference.

Figure 3 illustrates the two primary forms of client/server communication supported by NCF. Note that the IIOP form uses a standard NCF provided servlet to receive IIOP requests. This servlet dispatches IIOP requests to Java objects that the application designer has defined. The application supports the dispatch process by implementing a simple interface that maps object keys to objects, and objects to object keys. The IIOP servlet uses this interface to marshal and demarshal object references.

Backend Access

Most Web applications need to leverage external data or preexisting applications. NCF provides a comprehensive set of connectors (Java libraries and gateway programs) to access:

  • DB/2 and other relational databases
  • IMS
  • CICS
  • MQSeries
  • Encina and other DCE servers
  • Lotus Notes

Information about each of these connectors can be found at and at Information about access to the Notes store is still being developed, but it is precisely the same interface that is provided to server-side LotusScript programmers translated into Java, so you can refer to the Notes LotusScript documentation for insight about these interfaces.

In addition to access libraries, NCF provides JavaBean interfaces for some backend access. This is done in a variety of ways. For example, there are SQLBeans that leverage technology from the Net.Data product to provide high level, optimized access to SQL data sources. This support includes database connection management to reduce the overhead of setting up and taking down database connections. Some of the NCF tools also provide bean level support for backend access in the form of visual development tools that walk a developer through a series of dialogs to generate a bean that represents a specific query or interaction. This kind of support is currently available in VisualAge for Java for database access and CICS transaction access.

Access libraries also are provided for accessing standard Internet services like POP3, NNTP, FTP, NMTP, and LDAP.


The NCF supplies the underlying services needed by network applications, while providing an open, standards-based framework within which developers can integrate products from a variety of vendors. It provides a unified programming model based on Java and JavaBeans technology. Client-side and server-side functionality is enhanced by JavaBeans that provide access to all services. Its modular approach makes it very flexible. What starts as a simple online application can grow quickly and easily. As a developer you can leverage JavaBean components and object-oriented technologies to quickly build applications and systems.

By following the NCF model of building network computing solutions, developers can:

  • Leverage Internet standards to better serve end users.
  • Bring efficiency to all development efforts, consolidating all programming into one cohesive environment that addresses most users and platforms.
  • Quickly deploy new solutions throughout an organization or customer-base, with minimal hassle, while taking full advantage of existing enterprise systems.
  • Swiftly augment solutions to address new user needs and increase competitiveness.

Quite simply, the NCF provides a better way to program.

[1] Actually, there is a special servlet class, javax.servlet.http.HTTPServlet, that provides two specialized forms of the basic servlet service method, doGet and doPost, to reflect the two types of HTTP requests that are directed to servlets. However, these two methods get the same two parameters that are given to the general service method and work the same way except for the ways get and post operations are treated differently. For simplicity of discussion, this difference is not covered in this article. See javax.servlet.http.HTTPServlet.

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation