Manfred Bathelt, Ulrich Gall, Bernd Hindel, Christian Kurzke
3SOFT GmbH, Wetterkreuz 19a, 91058 Erlangen, Germany
IMMD IV, Department of Computer Science University of Erlangen-Nuernberg,
Germany
mdbathel@cip.informatik.uni-erlangen.de, gall@informatik.uni-erlangen.de,
hindel@dreisoft.de, cnkurzke@cip.informatik.uni-erlangen.de
The ubiquity of Web browsers makes them an ideal generic front end for simple client-server systems. A very suitable area of application is controlling embedded systems, such as network printers., where supporting standard Web browsers is a cost-effective and convenient alternative to developing custom client software for remote administration from different platforms.This paper describes the design and implementation of a flexible communication server to be run directly on the embedded system. It supports different protocols to allow remote access, including HTTP. Thus, the embedded system can be accessed with any Web browser. Its state is represented as a set of Web pages containing dynamically generated information. Java applets included in these Web pages can connect back to the server to subscribe to live data feeds for real-time visualization of the embedded system's state. A GUI builder implemented as a Java applet can be used to customize the visual appearance of these applets.
In the past, most remotely accessible embedded devices such as printers, routers, UPSs, and telephone systems required proprietary client software for configuration and maintenance. This client software had to be developed for many platforms, and users had to deal with different interfaces for configuring different devices.
Having the embedded system (the target) act as an HTTP [HTTP96] server makes it possible to access it using standard Web browsers. That way, the manufacturer of the device does not have to provide any external software to be installed by the end user. Also, the end user can access the device through the familiar Web browser user interface and take advantage of browser features such as bookmarks.
For example, if a printer manufacturer chooses to include an embedded Web server on the printer, the end users can simply direct their Web browser to the printer and view the number of pages already printed, the toner level, and its current settings. Using HTML forms, end users can change settings.
In contrast to most HTTP servers used in the Internet, the main purpose of an embedded server is generating preformatted HTML documents merged with dynamic contents rather than providing static information.
For visualizing live data, HTTP is not suitable because it is state- and connectionless. Using proprietary browser features that automatically refresh the page periodically is not a satisfying solution either. Instead, we suggest a publisher-subscriber protocol that can be used by Java applets included in the WWW pages to retrieve real-time data from the target and to visualize it. Using the ProWeb Builder, a visual user interface builder, these applets can be developed rapidly without Java programming. The ProWeb Builder allows interactive composition of the user interface using ProWeb Widgets, a set of predefined, customizable user interface components. The ProWeb Builder can be run as a stand alone application or as a Java applet included in the device.
The application domain imposes many unique restrictions on the server design; for example, hardware resources in embedded systems may be very restricted. There may be no file system, or only 20 KB of memory available. Using a modular architecture, software components that are not necessary can be excluded, allowing for code sizes between 7KB for a server supporting HTTP functionality only and 300 KB for a full-featured ProWeb Server providing real-time data to included Java Applets.
This paper is organized as follows: Section 2 discusses internal design aspects of the server. Section 3 presents some features of particular interest for embedded systems applications, and Section 4 concludes the paper.
The primary design goal of the ProWeb HTTP server is scalability and perfect integration in real-time embedded systems. For optimum scalability and code reuse the server functionality must be split into as many separate modules as possible without increasing code overhead for module interactions. To gain best possible integration in embedded systems with real-time capability, several restrictions have to be imposed on an HTTP server for embedded systems:
To accomplish this, the ProWeb HTTP server is divided into separate Request Processing Modules (RPMs). These modules are plugged into the server core as shown in Figure 1.
Figure 1. The ProWeb server core.
The core provides all functionality that is neccessary to handle the network connections, to initialize HTTP request processing, to call RPMs and to clean up at the end. In addition, it contains code that is shared among several RPMs. This code is included in the core only if one of the RPMs requires it. Thus, excluding RPMs will also reduce core size.
| Request Processing Modules (RPM) are functions called to process a request. Each RPM returns a status code to indicate whether the request has been processed successfully or that an error has occured. More detailed return codes are reserved to indicate that there is still some work to do for other RPMs. An RPM may even initiate restarting of the entire RPM invocation process (see Figure 2). Thus it is possible to execute several RPMs for one HTTP request in a defined order. RPMs can be divided into System RPMs and User RPM. Both of these have the same interface, so they can be called using the same code. | 
Figure 2. RPM dispatching. |
System RPMs are invoked for each HTTP request and are not attached to an URL. Any RPM may be appended to the list of System RPMs.
User RPMs are functions that are attached to certain URLs. This implies that a User RPM is not invoked if the URL of a HTTP request does not match one of the URLs attached to it. A good example for a User RPM is the ProWeb Filesystem RPM which is accessible via http://myhost/filesystem/pub/index.html but should not be invoked if http://myhost/custom/pub/index.html is requested. In this example the Filesystem RPM could get the information that it was invoked using the RPM identifier /filesystem/ and the RPM path data pub/index.html. Now it can use the RPM path data to open a file and return it to the client.
The RPM dispatcher calls the system RPMs from top to bottom (see Figure 1) until the resulting status code causes the execution to continue with the user RPMs. The processing stops if any RPM requests so. This is normally done by User RPMs which produce the full HTML response themselves, such as the file system RPM.
Several standard RPMs are available, including the Alias, Authentication, Password Checking, IP Address Checking, Access Control, CGI Support, Filesystem, Logging, MIME, FileUpload [NeMa95], Template and ProWeb Live RPMs.
We will describe the Template RPM in detail because it has proved very useful for embedded systems applications.
Templates are a useful tool for including dynamic data into static HTML pages, similar to the Server Side Include facility [UPenn] of the NCSA HTTP server. To use a template, a Template Function has to be implemented. This function can then be referenced in HTML pages containing Template Tags.
<TEMPLATE NAME="accessCount" 1>
When a client requests a HTML page containing a Template Tag, the server invokes the specified function which may replace the tag with dynamic data. The following example shows how to implement a counter using Templates.
STATUS accessCount ( HTTP_REQ * pReq,char *szArg )
{
static short i=0;
int inc = atoi(szArg);
httpPrintf ( pReq , "Value is currently %d!",i+=inc);
return (OK);
}
Note that the Template replacement function is part of the server core functionality and is used by the Template RPM. The application developer simply provides proper template functions and HTML files. Notice that the Template Tags never reach the client browser because they are replaced with concrete text by the server. Thus the file sent to the browser fully complies to the HTML specification [Ragg96].
The following example RPM will download 0x4000 bytes beginning at SOME_START_ADDRESS from the embedded system to the WWW client. This is useful to examine memory dumps or a data area.
short rpmDump( HTTP_REQ * pReq ) /* Handle of the active request, needed for all http - API function calls */
{
char * pStart = SOME_START_ADDRESS;
long lChunkSize = 0x4000;
long lIndex;
/* DOWNLOAD the contents of your RAM from pStart onwards */ /* Set the HTTP status code */ httpStatusSet (pReq, HTTP_OK); /* Set the HTTP document type */ httpMimeContentTypeSet (pReq, HDR_OUT, "application/octet-stream"); /* Set the Size of the Chunk */ httpMimeContentLengthSet (pReq, HDR_OUT, lChunkSize); /* Send HTTP header */ httpHeaderGenerate (pReq); /* send the memory chunk from pStart with lChunkSize bytes size */ httpBlockPut (pReq, (char *) pStart, lChunkSize); /* tell the dispatcher to stop RPM processing as this RPM finished successfully */ return (RPM_DONE); }
This example shows how the ProWeb API encapsulates the HTTP protocol. Output functions similar to standard C are available, for example, httpPrintf().
Access control is based on three separate RPMs which can be replaced or adapted to the needs of the developer. The provided default RPMs exploit the currently supported HTTP security mechanisms.
For many applications it is not sufficient to provide a hierarchy of user access levels, because they require mutual access locking between two user groups. This has been implemented using access control lists based on user and location groups. A location group is assigned to the client by determining its IP address and searching a list of IP patterns. The client's user group is determined by decoding the credentials sent by the browser (user ID and password) and comparing them to a list of user groups.
Based on the client's user and location group, the server determines whether the requested URL is accessible or not. The access lists for an URL can be built up from several combinations of access schemes such as 'user AND location' or 'user OR NOT location' .
Access parameters can be configured dynamically using IP and URL patterns including wild cards.
Figure 3. The symbol table.
The ProWeb Symbol Table provides a generic interface between applications and the HTTP server, using shared application variables. Access to these shared variables involves locking mechanisms and optional access control. The symbol table maps symbols to memory addresses and provides type and length information and a semantic description to the user.
ProWeb supports most of the common features of HTTP servers. In this section we focus on two features of particular interest for our application domain: DynaForms and live data feeds.
The main purpose of running an HTTP server on an embedded device is to provide dynamic information formatted as HTML documents and to handle HTML Form submissions for manipulation of the target. The traditional way of writing CGI scripts to parse the form input, perform actions, and generate HTML output mixes two separate tasks: HTML content design and script programming.
In embedded systems development, these tasks will usually done by developers with very different backgrounds: A programmer who develops the software running on th embedded system, and an HTML designer with skills in user interface design.
The CGI approach requires very close communication between these two parties, which can be very inefficient and error-prone. DynaForms solve these problems by separating these two tasks and providing a formal interface between them.
The programmer defines a set of variables which represent the device's state and implements functions which perform the actions that will be made available to the user. The initialization code of the embedded system registers these variables and functions in the ProWeb Symbol Table. The contents of the ProWeb symbol table are provided to the HTML designer as a specification of the device's functionality.
The HTML designer writes standard HTML documents describing the device's user interface, using any HTML editor. Form fields can be bound to entries of the ProWeb symbol table by specifing the symbol's name in the field's NAME parameter. A Field bound to a variable will automatically be preset to the variable's current value. If form data is submitted, the corresponding variables are set. If a function has been bound to the form, it is invoked to process the parameters in the fields.
To save resources on the embedded system, the HTML file is processed by a utility program before it is uploaded to the target.
When a document containing DynaForms is requested, the Template RPM sets the default values in each of the form's fields to the current values of the variables bound to the field.
If the user submits a form, the DynaForm RPM processes the request. If a form field is bound to a variable, that variable is set to the new value. If a function has been bound to the form, it is invoked with the parameters the user entered into the form.
Access control to the symbol table entries is enforced by allowing changes only to those variables and functions that have been bound to a form. Upon receipt of a form submission URL, the server re-reads the corresponding HTML document and checks that all variables that are to be changed are actually bound to a form in that document.
Since the URL for the form submission can be placed in a protected part of the WWW tree, the access control features of the HTTP server can be used to restrict access.
Since the server may process more than one request concurrently, and the embedded program may run at the same time, access to the entries in the symbol table has to be serialized. This is achieved by globally locking the whole symbol table when a variable is accessed or by locking only the accessed symbol. The latter requires more resources and is therefore optional.
Since HTTP is a stateless protocol, it is not possible to lock variables the entire time while a user views and possibly changes them. Thus, the user may decide to change a variable based on outdated information. To visualize and control dynamically changing variables such as measured data for temperature or water level, Java Applets should be used.
One of the key requirements for ProWeb is that no software has to be installed on the client systems. Since HTML does not provide any means of client side data processing, a dynamically generated HTML page can only provide a snapshot of the system's state. To react to live events from the server, active content such as ActiveX [MSC96] controls or Java [JaPl96], [GJS96] applets are required. Since ActiveX controls are much larger in code size and only supported on MS Windows Web browsers, Java has been chosen to visualize live data from a ProWeb server. Small Java applets require only a few kilobytes of code, yet they are platform independent and can be run on MS Windows, Apple Macintosh, and most Unix systems.
In this section we will describe how Java Applets can be customized and placed into the Web pages provided by the target device.
To include live data into a Web page on the device, a generic Java Applet is included into that page using the standard HTML applet tag.
Figure 4: The ProWeb Viewer Applet with a user interface containing set of ProWeb Widgets
When the browser displays this page, it automatically loads and starts the applet. The applet connects back to the ProWeb server and loads a user interface containing ProWeb Widgets, as shown in Figure 4. Each component visualizes the value of on or more of the variables in the symbol table of the target.
The user interfaces mentioned above can be designed interactively using the ProWeb Builder tool. It can either be run as a stand alone Java application or as a Java applet stored in the embedded device. The latter allows for customization of the device's user interface without any software installation on the clients, but it obviously requires more memory in the device.
The ProWeb builder lets the user create, position, resize, and configure the ProWeb components using an intuitive, visual user interface. This does not require any programming knowledge. The components are automatically preconfigured by the builder using the information available in the ProWeb Symbol Table provided by the developer of the embedded software. The symbol table can either be loaded from the target, if available, or from anywhere in the WWW. Modifications to the user interface can be uploaded [NeMa95] to the embedded system using Java's object serialization[JaSe96] features.
If the target is connected, the user can switch the ProWeb Builder between run- and design modes.
The ProWeb Widgets' communication functionality is implemented in a protocol-independent way. They obtain references to active proxy objects from an name service module contained in the applet. Each of these proxies replicates the value of a variable on the embedded system. For each variable to be observed, there is only one proxy object; the name service module returns a reference to that proxy rather than instantiating multiple proxies for the same variable. ProWeb Widgets can subscribe to events from a proxy, query the current value, and change it. Value changes can either be immediate or delayed; the latter saves network bandwidth.
Updating of the proxies can occur using different protocols; so far, only ProWeb Live, a lightweight proprietary protocol, have been implemented. An SNMP implementation is under way. ProWeb Live is a publisher-subscriber protocol that sends updates only when needed, with a configurable maximum refresh rate. Since it is based on HTTP, it can be tunneled through HTTP proxies.
ProWeb is a system that greatly simplifies the problems involved in developing remotely controllable embedded systems. Instead of developing and maintaining client software for many different platforms, standard software that is already available for all major platforms and widely spread among average computer users - WWW browsers - can be used.
This was achieved by using standard WWW technology in a way that accomodates the unique properties of the application domain. Current technical limitations of HTML and HTTP can be overcome by using Java applets that provide client side interaction and actively visualize live data feeds. These Java applets can be developed interactively using the ProWeb Builder, a visual application builder tool.
In the future, we expect that more and more networked devices will be Web-enabled. As the next step, devices that previously had their own physical control panel, such as VCRs, will be used remotely through a common interface. That way, we will be able to access all devices of our daily life from anywhere at any time, through a suitable user interface with a familiar look-and-feel. This interface will most likely be the WWW- or its successor.
[HTTP96] HTTP Working Group: "INTERNET-DRAFT:
Hypertext Transfer Protocol - HTTP/1.1", August 1996
<http://www.w3.org/pub/WWW/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-07.txt>
[Ragg96] W3C, Dave Raggett: "HTML 3.2 Reference
Specification", Proposed Recommendation, November 1996,
<http://www.w3.org/pub/WWW/TR/PR-html32-961105>
[JaPl96] JavaSoft: "The Java(tm) Platform",
1996,
<http://java.sun.com:80/aboutJava/index.html>
[GJS96] J. Gosling, B. Joy, G. Steele: "The
Java Language Specification", White Paper, August 1996,
<http://java.sun.com:80/doc/language_specification/index.html>
[JaSe96] JavaSoft: "Object Serialization
Specification", 1996,
<http://chatsubo.javasoft.com/current/doc/serial-spec/serialTOC.doc.html>
[MSC96] Microsoft Corporation: "ActiveX Resources
Area", November 1996,
<http://www.microsoft.com/activex/>
[NeMa95] E. Nebel and L. Masinter: "Form-based
File Upload in HTML (RFC1867)", Request for Comments, November 1995,
<ftp://ds.internic.net/rfc/rfc1867.txt>
[UPenn] University of Pennsylvania, Computer and
Educational Technology Services: "What are NCSA httpd server side
includes",
<http://www.seas.upenn.edu/cets/answers/httpd_includes.shtml>
[WRS96] Wind River Systems: "VxWorks 5.2",
<http://www.wrs.com/vxwks52.html>