WASD VMS Web Services - Features and Facilities
1 - Introduction
next previous contents full-page
With the installation, update and detailed configuration of the WASD Web
Services package provided in
WASD Web Services - Install and Config
why have an
introduction in this subsequent document? After getting the basics up and
running (often the first thing we want to do) it's time to stop and consider
the tool and what we're trying to accomplish with it. So this section provides
an overview of the package's design philosophy, history and significant
features and capabilities by topic.
The document assumes a basic understanding of Web
technologies and uses terms without explaining them (e.g. HTTP, HTML, URL,
CGI, SSI, etc.) The reader is refered to documents specifically on these
topics.
Objectives
WASD Web Services originated from a 1993 decision by
Wide Area Surveillance Division (WASD) management (then High Frequency Radar
Division, HFRD) to make as much information as possible, both administrative
and research, available online to a burgeoning personal desktop workstation
and PC environment (to use the current term ... an
intranet) using the then emerging Web technologies.
It then became the objective of this author to make all of our
systems' VMS-related resources available via HTTP and HTML, regardless of the
underlying data or storage format. An examination of the WASD package will
show that this objective is substantially achieved.
Reasons For Yet Another Web Package
Reasons for developing (remember; back in 1994!) a local HTTP server were
few but compelling:
- The WASD Web implementation began mid-1994.
- It was prefered to support this environment on a VMS platform;
at the time the most widely used and accessible environment within WASD.
- At that time servers (and even then there were quite a few
variations) were largely Unix based, although it was being supported (to a
greater or lesses extent) across a wide range of platforms. Ports to VMS, if
they existed, were often in-progress or half-baked, employing
Unixisms that don't translate elegantly to the VMS environment.
- The VMS version of the CERN server (3.0-6) was evaluated during mid-1994:
- It was (still is) not multi-threaded under VMS (i.e. cannot support
concurrent clients). For example, a lengthy search may delay other clients
for unacceptable periods.
- The performance was good with document transfers, but became poor when
running a script.
- It is acknowleged in the release notes that it cannot handle a client
cancelling a data transfer (a not-uncommon action). This was confirmed
experimentally.
- An early version of the OSU server was evaluated via documentation
mid-1994. The author considered that the DECthreads of the time to have
limitations (including frequent, show-stopping bugs) and OSU had a number of
implementation idiosyncracies (e.g. DECnet based scripting).
- HTTP, in the then standard implementation (HTTP/1.0, RFC1945), was
relatively simple to implement to the level required to support
intra-Divisional requirements.
- Since that time ...
- As of December 1995 the server has worked extremely
well and has a number of facilities tailored for the VMS environment. It can
continue to be utilized until there are overwhelming reasons for implementing
something else.
- June 1997 the server and associated software
continues to evolve and provide a stable and effective VMS Web environment,
even with the advent of a small number of commercial VMS Web products.
- October 1999 the package is beginning to mature as
an HTTP/1.0 solution, providing not only a fast and stable server but an
increasingly extensive collection of applications and tools.
- July 2002 it continues to be refined and extended.
A greater emphasis on "commercial" functionality has occured over the
past couple of years.
- December 2004 it now complies with the HTTP/1.1
specification (RFC2616) and provides a very respectable range of functionality
and the fastest and most efficient serving environment for VMS.
- A decade on (2014) it continues to be adopted by
sites wanting fast, efficient, capable and often philosophically VMS
infrastructure. WASD continues to be enhanced and bug-fixed two
decades after its initial, tentative steps into the World-Wide information
Web.
- May 2016 brings HTTP/2 (RFC 7540, RFC 7541) to WASD.
A replacement for how HTTP is expressed "on the wire", it is not a
ground-up rewrite of the protocol; HTTP methods, status codes and semantics are
the same. The focus of the protocol is on performance; specifically, end-user
perceived latency, network and server resource usage.
next previous contents full-page