2520 Quarry Road, Suite 101
Austin, TEXAS 78703

Implementing The Netscape/Microsoft Server APIs For Btrieve

Why APIs, Why Not CGI?

APIs provide a closer fit to the server side than does CGI. CGI has to spawn a new process outside the servers process area for each invocation by each client. This could prove very costly in terms of resources as they cannot share data or communication resources. This also slows down the applications due to its startup/shutdown time.

The Netscape/Microsoft Server API (NSAPI ISAPI) is an extension that allows you to enhance and/or customize the core functionality of the Netscape/Microsoft server and provide a scalable, efficient mechanism for building interfaces between the HTTP server and back-end applications. Since these are implemented as shared libraries of DLLs, they can be resident in memory and the call/invocation/duplication overhead is eliminated. Since it resides in the server space, it can potentially have access to the servers internal data structures, functions, I/O operations.

ISAPI-ODBC ISAPI-ODBC

The NSAPI/ISAPI interfaces to Btrieve will consist of writing server side functions to handle web server operations that utilize Btrieve database functionality wherever appropriate.

We feel that this can be targeted to 3 different scenarios for each of the Netscape and Microsoft web server classes. For simplicity, we will define the process using NSAPI. The ISAPI will be discussed later highlighting where its different from NSAPI.

  1. The basic APIs implemented as a DLL (or shared library module). The users have full discretion on how to use it (Targeted for power users)
  2. The complete solution which includes the API DLL, a sample set of configuration files for a simple application (and maybe bundling the web-server itself)
  3. The LiveWire (or Microsoft) database integration solution using ODBC drivers.

1. The Basic NSAPI:

Implement the Server Applications Functions (SAF) for each of the Web Server operations listed below.

A Breakdown Of The HTTP Request-Response Process

After the client sends its request to a server, it is helpful to define a set of logical steps which the server must take before a response can be sent. The definition of these steps is taken from experience with the feature sets of common HTTP servers. The steps chosen should be as orthogonal as possible, with the result of one step affecting the next, but the methods employed in carrying out each step should not affect the next steps.

The following steps in the normal response process:

The Server Application Functions (SAF)

To accomplish each of these steps, a set of server functions must be applied. These functions take the request, and server configurations as input, and return a response to the client as output. The set of functions which are applied are determined by the inputs.

By changing the set of functions available to the server application, the set of features that server implements is changed. Further, the base code of the server may be upgraded, or even changed to implement a different protocol with minimal changes to the server application functions.

Server application functions are said to have a particular class, where the class corresponds to the request-response step it helps implement. There is an additional class of application function, the initialization function, which is executed upon daemon startup and performs static data initialization for the various server modules. Server application functions have a single class and are not informed by the server which class they are being used for.

The server keeps an internal table of available functions, and maps these function pointers to unique character strings which identify them. By using this string in the configuration database, a function can be called to carry out one of the above steps. In the initial release of the Netsite HTTP server, this mapping of function pointers to names is hard-coded into the server. A mechanism has been proposed by which these functions may be loaded at run-time through the use of shared objects.

2. The Bundled Solution:

This implementation would involve initially building all the pieces for API solutions. The servers could be bundled or not, but a set of configuration files will accompany the release (eg. magnus.conf, object.conf). This is important in situations where clients may need a plug-and-play solution. For them to be up and running quickly, a small application can be created using a sample database to go with the configuration files.

3. Database Connectivity using Netscapes LiveWire

Query results from the database are generated dynamically (and quickly) using LiveScript. LiveScript is an enhanced version of JavaScript developed by Netscape. Netscape includes direct connectivity to Informix and Oracle with its LiveWire solution. It also has ODBC connectivity to other databases. This could be another approach to web-enable btrieve databases without going through a complete NSAPI implementation.

The ISAPI Side Of Things

The ISAPI implementation of scenario 1. and 2. is very similar to that of NSAPI. The ISAPI applications and the HTTP server communicate through a data structure called the ECB. The client accessing an ISAPI does it very similar to a CGI URL. The .exe is replaced with a .dll or .isa. Similar to the NSAPI SAFs, ISAPI defines filters for the IIS. The filter is simply a DLL that the server calls for an HTTP request. Filters register with the server on startup and from there on, when the event occurs, gets invoked to process it.

Some of the different applications we can write filters for are:

Similar to NSAPIs configuration files, ISAPI uses the NT registry to store the filter references associated with the IIS.

  • Publishing Information and Using Microsofts Database Connector

    With the WWW service and the Open Data Base Connectivity (ODBC) drivers provided with Internet Information Server, you can:

    Web browsers submit requests to the Internet server by using HTTP. The Internet server responds with a document formatted in HTML. Access to databases is accomplished through a component of Internet Information Server called the Internet Database Connector. The Internet Database Connector, Httpodbc.dll, is an ISAPI DLL that uses ODBC to gain access to databases.

    odbc  

    This figure shows the components for connecting to databases from Internet Information Server.

    Httpodbc.dll uses two types of files to control how the database is accessed and how the output Web page is constructed. These files are Internet Database Connector (.idc) files and HTML extension (.htx) files.

    The Internet Database Connector files contain the necessary information to connect to the appropriate ODBC data source and execute the SQL statement. An Internet Database Connector file also contains the name and location of the HTML extension file.

    The HTML extension file is the template for the actual HTML document that will be returned to the Web browser after the database information has been merged into it by Httpodbc.dll.

     
     

      The following illustration shows a user posting an order to a database using the Internet Database Connector. The user completes a form, then clicks a button, which in turn sends the data in the form to the server. The server posts the data to a database, then confirms the order by sending an HTML page.

    odbc-ex

     

    The Proposal

    To summarize, we propose to provide to Pervasive Software, any or all of the 3 levels of functionality as listed above. The details of functionality required by Pervasive in the scenarios presented will have to be nailed down by members from both Pervasive and InferData before undertaking of this project.
    1. The basic NSAPI, ISAPI libraries to connect to Btrieve data sources. We propose to develop an NT and UNIX (Solaris) version for the NSAPI libraries and an NT version for the ISAPI.
    2. The bundled solution with the NSAPI, ISAPI, configuration setup, and sample database applications, demo for plug and play deployment. Includes all the libraries from above.
    3. The LiveWire or Microsoft database connector solutions using the ODBC drivers. Using the native btrieve interface is not addressed in this proposal. A sample application will also be built utilizing these solutions.
    Phone: 512-415-7678 Fax: 512-472-3062 URL: http://www.inferdata.com