Figure 1: Example of the DIM-WWW output: Machine Status
DIM-WWW Implementation
A document in HTML consists of text with its structure, e.g. paragraphing and headers, represented by special tags. A DTD (Document Type Definition) [9] is used to specify and refer to the valid tags, and to define the attributes associated with each.
The HTML+ DTD was extended with a separate DIM DTD containing only one tag, <DIM>, as well as a set of relevant attributes. Whenever this tag is encountered by the gateway, it is replaced in the document by the required information from the DIM system. Any tag other than <DIM> is not processed by the gateway, but just copied to the client. Hence, once the <DIM> tags have been replaced, the document is normal HTML and can be viewed using a WWW browser.
Documents containing <DIM> tags (DIM files) are distinguished by a `.dim' suffix. This suffix is associated with a user-defined MIME [10] type, for which the gateway may call a converter to convert it to the MIME type www-present (HTML). The converter is an SGML parser which uses the DIM DTD to parse the `.dim' file, refer to figure 2.
The most common DIM attribute is SRC,
which is used to specify the name of the service that provides the required
information, e.g. <DIM SRC="service_name">. The gateway then calls a
DIM routine to subscribe to this service and wait for the information to
arrive, hence becoming a DIM client. The information is subsequently inserted
into the document in place of the tag.
Three conversion attributes IN, CONVERT, and OUT are provided. These can be
used in any
combination to control the formatting and appearance of the information.
The IN attribute must be used if the incoming information is of any data type
other than a string. The gateway converts from the original type (according
to the given format) to a string. The format is specified in the same way as
in formatted C input and output, e.g.
<DIM SRC="service_name" IN="%4.2f">.
CONVERT can be used to specify the name of a conversion routine, which is
called by the gateway to translate the incoming information of any data type
into a corresponding string for output, e.g. a mode number into a mode name,
or a number of seconds into a time and date.
The OUT attribute may be used to format the output string, usually to limit
its length, e.g. <DIM SRC="service_name" OUT="%5.5s">, which would
truncate the string returned by service_nameto 5 characters.
The method of subscribing to a service as its name is encountered, waiting for
the information to arrive, and then releasing the service proved to be quite
slow. The gateway was improved by the use of a cache [11].
The cache operates in much the same way as a normal cache, i.e. whenever
information from a service is required, the cache is searched to see if it
already contains the information. If so, this can be copied directly into the
document in place of the <DIM> tag, without having to subscribe, wait,
and release. If the required service is not found in the cache, it is
added.
However, because the value of the data from a service can be updated at any
time, simply caching the value from the most recent reference to the service
will result in out-of-date information being provided. Instead, the DIM
cache maintains subscriptions to the services, and so when a service is in the
cache, its value is updated whenever new information is available.
When the cache is full and a new item is to be added, a least-recently-used
algorithm [11] determines which of the current items is to be removed. When a
service is removed from the cache, its subscription to the DIM service is
released.
Support is provided for the creation of DIM files. If the gateway finds any
errors, e.g. format specifications without %signs, a numbered list of error
messages is given at the bottom of the page. A number corresponding to each
error is inserted in the position in the document where the error occurred,
and each number is a link to its error message. Also, if the writer
of the DIM file has specified a conversion routine which does not exist, a
link is provided to a page giving the name and description of all the defined
routines.
The HIPE system uses global shared memory to store its information. It consists
of a linear set of channels of different types, each of which may contain a
different set of information. A configuration file specifies how channels are
combined into groups of channels and other groups. On these groups functions
like `display' or `set' may be executed. Those functions are called from menus
and submenus which are also defined in the configuration file.
The HIPE-WWW gateway basically maps URLs onto the HIPE function and menu
system. The URL may specify the retrieval of a menu, in which case the gateway will
produce a list in HTML. Each element in this list will link to the same gateway
specifying the retrieval of a submenu or the execution of a function. The
latter will result in a list of channels, each containing specific
information, see figure 3. The formats of the menus, channel
and group display are all defined by the configuration file.
The HIPE-WWW gateway, see the dataflow diagram in figure 4,
reads all of its structural
information at startup time from a configuration file. Once started it knows
the grouping and formatting of the channels, the functions it may execute and
the menus from which these functions are called. The actual Online data is
stored by autonomous processes in global shared memory sections as a flat
series of channels.
The URL from the HTTP request is inspected by the URL Analyser. The URLs are of
the form:
for which the Menu Executor or Function Executor is called.
The Menu Executor constructs a menu from the menu definition, thereby creating
links in the form of URLs to functions it may call.
The Function Executor
sets up a stack from the given parameters and then calls the function by
looking it up in the Function Symbol Table. A function like `display' will take
the groupname, given as a parameter, and construct a list of channels. It uses
the Group and Format Definition together with the actual Channel Data to
do this. It also generates links into
other functions giving more details on each of the channels.
Both Executors write out lists in HTML-form along with information like menu
title or groupnames, which is subsequently forwarded by the
Output Formatter to the client. Since HTTP is a stateless protocol the
generated URLs contain all information for the next request.
The unstructured DIM gateway is very flexible, in the sense that all
configuration information is kept in DIM (HTML-like) files. The user of the
gateway can use the functionality of both DIM and HTML to give access to the
online
information, including images and links into static documents. The disadvantage
however is that one has to create all those DIM files. The gateway code, added
to the CERN-httpd, can
be kept very simple and clean.
The structured HIPE gateway is more static. The menus and lists it produces
can only be altered by reprogramming the gateway or changing the far more
complicated HIPE configuration files. The gateway code, also based on the
CERN-httpd, is more complicated than for the DIM gateway, but
the advantage of this type of gateway is that it uses an already existing
structure to provide output to WWW.
Both gateways have been running for a few months in DELPHI with a lot of
success. They play an important role in providing crucial information to
DELPHI members, like the operator crew and the people responsible for the
subdetectors. It also decreases the load on our network, since people
now use WWW to access the information instead of logging in.
We would like to thank everybody from the DELPHI Online System development team
for their support, in particular Clara Gaspar for the DIM system. We thank the WWW
Development Team at CERN, in particular Tim Berners-Lee for inventing WWW,
Henrik Frystyk for his support
of the WWW library of common code and Ari Luotonen for his support of the CERN-httpd. We are
grateful to Dave Raggett for using his unreleased browser to show the impact of tables
in HTML.
Mark Dönszelmann works currently both for the DELPHI experiment and the
World-Wide Web team at CERN. After finishing his masters thesis in
Electronics Engineering at the Delft University of Technology in 1989, he
started to work for NIKHEF at CERN on the Inner Detector of DELPHI. In 1992
he continued his work on control systems and user interfaces as a Fellow.
Since 1993 his work has moved towards the World-Wide Web.
Kerry Rodden worked as a summer student at CERN in Geneva from June to
September 1994. She is entering the final year of a BSc in Computer
Science at the University of Strathclyde in Glasgow, Scotland, and hopes
to continue her interest in World-Wide Web.
Mark Dönszelmann may be reached at e-mail address: duns@vxdeop.cern.ch.
Kerry Rodden may be reached at e-mail address: krodden@cs.strath.ac.uk.
Figure 2: DIM to WWW Data Flow Diagram
DIM-WWW Cache
DIM-WWW Additional functionality
HIPE-WWW Structured Gateway
Figure 3: Example of the HIPE-WWW output: High Voltage Channels
HIPE-WWW Implementation
Figure 4: HIPE to WWW Data Flow Diagram
http://gateway.domain/HIP/MENU/menu_name
or
http://gateway.domain/HIP/FUNCTION/function_name/par_1/.../par_n
Conclusions
Acknowledgements
References
Biographies