The Caché WebLink Network Service Daemon
Chris Munt
InterSystems Corporation
17 March 1999
Caché WebLink – The Standard Architecture
Caché WebLink provides web connectivity to Caché (and other M databases) using the
high-performance web server APIs supplied by Microsoft (ISAPI) and Netscape (NSAPI).
The following diagram illustrates the relationships between the various software
components used in data transmissions between web browsers and Caché.
Client
Browser
Web Server
Host
Web Server
(Microsoft ISAPI
or Netscape NSAPI)
ISAPI/NSAPI
Interface
WebLink
Caché System Host
Caché System
Client Caché
Process
Copyright 1999 by InterSystems Corporation
1
The close relationship between WebLink and its hosting web server provides a number of
important advantages:


High performance. WebLink runs in the same address space as the web server.
Easy to install and configure.
However, there has been much demand to bring the benefits of WebLink to a wider range
of web servers and alternative web architectures. WebLink’s new Network Service
Daemon (NSD) is designed to meet this demand and the following design objectives were
set for its development:



Support for a wider range of web servers. Standard WebLink functionality is highly
dependent upon the multi-threaded APIs provided by Microsoft’s ISAPI and
Netscape’s NSAPI. Not all web servers support this style of interface. For example,
Apache web servers do not.
Support for large UNIX-based Netscape web servers. These servers are currently
forced to use the multi-threaded model in order to support WebLink. This has a
potentially negative impact on performance, particularly as the throughput of the site
increases.
Support for the Common Gateway Interface (CGI). Most, if not all, web servers
support CGI. WebLink should be accessible through CGI, but in a way which doesn’t
result in the notoriously poor performance which has bedeviled many other CGIbased solutions.
The Caché WebLink Network Service Daemon (NSD)
WebLink NSD offers exactly the same functionality as the standard WebLink libraries,
but delivers its services in a way that is totally independent of the web server. This
‘stand-alone’ version of WebLink allows us to retain the high-performance characteristics
of the standard version whilst giving the extra flexibility required in order to achieve the
stated objectives. The interface between the web server and WebLink NSD has been kept
as simple as possible. This simplicity makes WebLink eminently accessible to
interpretive scripting languages such as Perl, or straightforward shell scripting.
For the purposes of this discussion we will refer to the current version of WebLink as
‘standard’ WebLink and the new version as WebLink NSD. References to ‘WebLink
applications’ include those generated by ‘WebLink Developer’.
The following diagram illustrates the key features of the new architecture provided by
WebLink NSD:
Copyright 1999 by InterSystems Corporation
2
Client
Client
Browser
Browser
Web Server
Host
Web Server
(Apache)
Web Server
Host
CGI
Interface
WebLink
Module
CGI
Interface
ISAPI/NSAPI
Interface
Web Server
(Microsoft ISAPI
or Netscape NSAPI)
WebLink
Client
WebLink
NSD
Caché System
Host
Caché System
Client Caché
Process
The key features may be summarized as follows:


WebLink NSD is accessible via CGI scripts and executables. Most web servers
support the CGI interface so, in principle, WebLink is now accessible to most web
servers. This is a high-performance CGI solution. CGI applications have a reputation
for being slow, largely because of the overhead involved in starting-up the CGI
process which, in many cases, must then identify and connect to a suitable data
source. WebLink’s CGI executable is small and simple – it doesn’t take long to start.
WebLink NSD maintains a persistent pool of Caché processes ready for use so there
is no additional overhead in connecting to the database.
Web servers not offering a multi-threaded API can be supported. WebLink can now
be used with Apache servers – the world’s most popular web server. Apache does
provide an API, but adding an extra ‘module’ (i.e. a WebLink module) involves
rebuilding Apache. The CGI option allows WebLink functionality to be added to an
Copyright 1999 by InterSystems Corporation
3






existing Apache installation without having to rebuild the server. The code for a
‘WebLink module’ is supplied for those who are comfortable with Apache rebuilds
and wish to proceed with this option. Technically, the bound-in module ought to outperform the CGI option but, in practice, the performance appears to be comparable.
However, it would be reasonable to expect the bound-in approach to offer tangible
performance benefits on heavily loaded systems.
Microsoft (ISAPI) and Netscape (NSAPI) web servers can subscribe to the service
provided by WebLink NSD in addition to their tailor-made solutions provided by
‘standard’ WebLink. Of course, the libraries supplied by WebLink (named ‘WebLink
Client’ in the diagram) for the purpose of interfacing with WebLink NSD are trivial
compared to their ‘standard’ all-inclusive counterparts.
WebLink applications do not need to be changed. No matter which architecture you
choose to run with – ‘standard’ WebLink running with Microsoft ISAPI or WebLink
NSD operating with Apache via CGI – your WebLink application stays the same.
This property is particularly important for customers planning to develop and market
WebLink applications – they can be assured that their web application will run on
their customer’s web server setup, whatever that may be.
WebLink’s configuration procedures remain the same – all the systems management
forms are the same. Only the installation procedure is different.
As indicated in the diagram, WebLink NSD need not be installed on the same
machine as the web server. Whilst WebLink NSD is optimized to operate on the
same machine as the web server, there are at least two circumstances where the ability
to operate on a separate machine will prove to be invaluable:
 Supporting WebLink applications through independent Internet Service Providers
(ISPs). The problem here is persuading the ISP to accept WebLink as an add-on
to their web server and also provide local support for the Caché system to host the
application. Using the WebLink NSD model, both WebLink NSD and Caché
could be supported off-site – standard CGI could then be used as the vehicle for
communicating between the ISP’s web server and WebLink NSD. Most ISP’s
would be comfortable with this.
 Supporting a web server running in an operating environment not currently
supported by WebLink (e.g. Netware). WebLink connectivity can be brought to
such servers by installing WebLink NSD on a supported platform (UNIX or NT).
The web server running in the unsupported environment could then communicate
with WebLink NSD via CGI.
More than one web server can be supported by the same WebLink NSD installation,
as indicated in the diagram.
WebLink NSD can be managed independently of the web server and vice versa.
WebLink NSD can be temporarily taken out of service without disturbing the web
server. Also, the web server can be temporarily taken out of service without
disturbing WebLink NSD. This is particularly important if WebLink NSD is
providing support for more than one web server.
Copyright 1999 by InterSystems Corporation
4
What about performance ?
WebLink NSD has been tested in the following environment:
A single installation of WebLink NSD runs under Sun Solaris (Ultra 5). This supports:




Apache via CGI and via the bound WebLink module (Apache API) – Sun Solaris.
Apache via CGI and via the bound WebLink module (Apache API) – Linux/Intel.
Microsoft IIS via ISAPI and CGI – Windows NT (I).
Netscape FastTrack via NSAPI and CGI – Windows NT (II).
The WebLink applications are hosted on:

Caché – Windows NT (I)
The single WebLink NSD installation hosts four different web servers, each
communicating with WebLink NSD via two different means. The WebLink applications
are running under Caché/NT. Formal benchmarks haven’t been run as yet, but there is no
noticeable drag on performance relative to the standard WebLink equivalents. In fact,
Apache via CGI seems to be faster than Netscape/NSAPI running on the same platform
(Sun Solaris). As a rough guide it would be reasonable to expect the standard WebLink
solutions running under ISAPI/NSAPI to be slightly faster for small to medium
installations. However, as the throughput for a site increases, it is conceivable that the
NSD-based solution would begin to offer a performance advantage as it allows the load to
be more evenly distributed amongst more processes.
Where does this leave the standard versions of WebLink ?
There is no conflict between ‘standard’ WebLink and the WebLink NSD alternative. As
indicated previously, the standard version is, perhaps, a more appropriate solution for
small to medium sites using Microsoft or Netscape web servers. Users of Apache, or
other web servers not supporting an appropriate ISAPI-like API, must use WebLink NSD.
Users who prefer to access WebLink via CGI must also use WebLink NSD.
Copyright 1999 by InterSystems Corporation
5