Writing Web Applications With WAI: Netscape Enterprise Server/FastTrack Server, Version 3.0/3.01

[Contents] [Previous] [Next] [Index]

Chapter 1
Understanding WAI

The Web Application Interface (WAI) is one of the programming interfaces that allow you to extend the functionality of Netscape web servers.

WAI is a CORBA-based programming interface that defines object interfaces to the HTTP request/response data and server information. Using WAI, you can write a web application in C, C++, or Java that accepts an HTTP request from a client, processes it, and returns a response to the client. You can also write your own server plug-ins for processing HTTP requests.

Understanding Version Differences

The process for setting up and running WAI applications differs between versions 3.0 and 3.01 of the Netscape web servers:

In general, features or instructions specific to a release are noted in the manual.

Understanding CORBA

The Common Object Request Broker Architecture (CORBA) provides a distributed object infrastructure that supports interoperability across networks, languages, and operating systems.

A CORBA Object Request Broker (ORB) is a mechanism that allows client objects to make requests and receive responses transparently, regardless of the server object's location, operating system, or implementation language. (With an ORB, you can design your object interfaces in a neutral language called the Interface Definition Language, or IDL).

Netscape includes a CORBA ORB with the Netscape web servers. WAI was designed in IDL and includes Java, C++, or C "wrappers". You can call functions in these wrappers when writing your own CORBA-compliant applications that interact with the server via this ORB. (For more details, see the next sections, "Understanding IDL" and "WAI Wrapper Classes".)

The CORBA architecture is a standard developed by the Object Management Group, Inc. (OMG), an international consortium of more than 500 computer industry companies. For more information about CORBA, IDL, or OMG, see the OMG publication entitled The Common Object Request Broker: Architecture and Specification at http://www.omg.org.

Understanding IDL

Interface Definition Language (IDL) is a generic, descriptive language used to define interfaces between client objects and object implementations. An interface described in IDL can be implemented in any language.

WAI describes a set of objects and methods that let you access HTTP requests and server information as well as return results to a browser. The description of WAI is detailed in an Interface Description Language (IDL) specification. IDL is a language that allows you to describe an interface in a generic way and then allows you to compile that specification to a target language such as Java or C++.

Each interface definition specifies the operations that can be performed and the input and output parameters required. For example, the interface definition for an HTTP request describes how clients can access request headers and set response headers.

(The interfaces are defined in *.idl files, which are located in the server_root/wai/idl directory on UNIX and the server_root\wai\idl directory on Windows NT.)

Because the interfaces are described in a generic language rather than in a specific programming language, you can use the description of an interface to implement client/server applications in a variety of languages.

WAI Wrapper Classes

WAI includes wrapper classes (classes that implement the interfaces) for C++ and Java and a C interface. You can use C, C++, or Java to write your own applications that access HTTP request objects through the defined interface.

You can also write server plug-ins in C or C++ that use the functions and classes defined in WAI.

For example, one of the methods of the HTTP request interface describes how clients can add a header to the response sent to the client. This method is described in IDL:

Interface described in IDL:
HttpServerReturnType addResponseHeader(in string header,
   in string value);

WAI provides wrapper classes in Java and C++ (and a C interface) that implement this interface:

Function call in C:
NSAPI_PUBLIC WAIReturnType_t WAIaddResponseHeader(ServerSession_t p,
   const char *header, const char *value);

Method in C++:
WAIReturnType addResponseHeader(const char * header,
   const char * value);

Method in Java:
public abstract netscape.WAI.HttpServerReturnType addResponseHeader(java.lang.String
   header,java.lang.String value);

In your application or plug-in, you can call these methods to add the response header. The methods (in Java and C++) and C function implement the interface specified in IDL; they share the same parameters (except the C function, which has an additional argument for the server session object) and return the same type of value.

How Web Application Services Work

Using WAI, you can write a server plug-in or a web application service. For example, you can write a web application service that processes posted data from forms. These web application services work in the following way:

  1. You write a web application service with WAI.
    In your application or server plug-in, you define a class derived from the WAIWebApplicationService base class provided with WAI.

  2. On startup, your application/server plug-in registers with a web server.
    When writing your application or server plug-in, you register it by calling the RegisterService method of the WAIWebApplicationService base class.
    You register your application/server plug-in under a unique instance name. Netscape web servers include a built-in name service that keeps track of these instance names.

  3. End users access your web application service.
    To access a web application service, end users visit URLs in the following format: 
       http://server_name:port_number/iiop/service_name
    For example, if your server is named mooncheese, it is on port 80, and your application/server plug-in registers under the name MyWebApp, users can access your web application service by visiting the following URL: 
       http://mooncheese:80/iiop/MyWebApp

  4. The web server runs the appropriate method in your web application service class.
    The web server invokes the Run method of your web application service class. You write this method to process the incoming HTTP request, retrieve data from the request, and send a response back to the client.
The rest of this manual describes this process in more detail.

[Contents] [Previous] [Next] [Index]

Last Updated: 12/04/97 16:11:49

Copyright © 1997 Netscape Communications Corporation

Any sample code included above is provided for your use on an "AS IS" basis, under the Netscape License Agreement - Terms of Use