Embedded "servelets"
Web concepts foster design, apps changes
EE Times, May 11, 1998
By Bernard Cole
With a speed that is startling even for accelerated Internet time, a variety of technologies developed originally for the integration of the desktop computer into the World Wide Web is moving quickly into a number of embedded designs. And-surprise!-it is not Java, either as a language, an operating system or a development environment, that is making its presence known.
Instead, the Web-derived technology that has embedded designers excited, said Chris Sontag, chief technical officer at EmWare Inc. (Midvale, Utah), is derived from the basic building blocks of the Internet and World Wide Web: TCP/IP, HTTP, HTML and CGI, among other things. But rather than use these building blocks in the traditional way to give desktops access to the variety of general-purpose and specialized servers out on the Internet via the ubiquitous browser, they are looking to embed "servelets" in a variety of applications to give them a view into the internal workings of a system once it has been deployed in the field. Meanwhile, on the Java front, even as more tools for its use in the embedded environment appear, designers are still dragging their feet.
So the buzz is about servelets. According to a number of vendors of embedded software, there has been a continuous stream of calls from existing and new customers about embedding them in both new and existing applications. The bigger vendors of real-time operating systems have 25 to 100 projects under way to investigate or implement such capabilities in embedded designs. "Within a year or so, I do not think there will be an embedded design of any significance, even those that do not necessarily need connectivity, which will not have some means of connection to an external network-in many cases, the Internet," said Sontag.
There are three reasons for the rapid proliferation. First is the ubiquity of embedded processors, which have penetrated almost every aspect of our lives. Second is the pervasiveness of the Internet and the common set of communications standards that it represents. And third is the pent-up desire among embedded designers and the users of their creations for some way to access such systems remotely for monitoring, debugging and repair.
"The applications to which Web technologies such as servelets are being put have existed for a long time," said Vaughn Orchard, marketing manager at Tasking Inc. (Dedham, Mass.). "Virtually everything embedded designers are doing with Web technology as far as providing remote connectivity was possible technically in the past with other alternatives." The problem was that without any universal set of protocols providing such connectivity was an expensive process, both in time and dollars, because everything had to be built from the ground up. In some cases it had to be specific to each design or, at best, to each particular application area or market: special communications lines; special networking protocols, special software on the embedded device for connectivity and specially designed graphical user interfaces, for which much of the code must be resident in the embedded device.
To match the growing demand for connectivity across every aspect of the embedded market, designers are using the standardized Web and Internet protocols for virtually every kind of application, albeit with some modification. An additional bonus when using Web technology is the free GUI available with the browsers used on the desktop to access Web sites. The same browser and interface can be used to access the servelets located in the embedded application. Moreover, unlike previous approaches, the burden of supporting the GUI is entirely borne by the browser host, not the application. Not only is the cost of developing the browser eliminated from the cost equation, but the additional processing power and memory required to run the GUI on the application is eliminated as well. "All that the embedded software need provide is the basic information about the application, properly formatted in the appropriate HTML format for presentation to the browser, on request," said Orchard.
That is where the embedded servelets-also known as daemons, microservers, pico servers, micro Web servers and other names-come into play. According to Bill Weinberg, director of technical marketing at Lynx Real Time Systems Inc. (San Jose, Calif.) they are capable of serving up static and dynamic HTML pages and/or Java applets to standard Web browser clients, like Netscape and Internet Explorer, over the Internet or via intranets. Such a client-server architecture simplifies user interface development and eliminates costly cross-platform porting of application-specific front-ends. An additional benefit of the shift from platform-dependent and hosted GUI-dependent interfaces is that HTML interfaces can be prototyped using readily available public-domain servers such as Apache and the same client browsers that will access the final product.
All of this capability does not come without cost in system resources. But well implemented, that capability can be bought at a low enough price for many deeply embedded designs. For example, an HTTP/1.1 server with the required TCP and IP can be implemented in less than 50 kbytes of memory and HTML is easily compressed by as much as 50 percent with almost no run-time memory required for decompression.
An additional advantage of the embedded Web servelet approach is that the designer need no longer depend on or develop a proprietary technique for communication with his or her application because HTTP 1.0 supports three primary communication methods. These include GET, which gets a specified document, resolving a URL, generating a set of headers to describe the served document and then the document itself. The second method, HEAD, returns the HTTP headers that the GET request would generate rather than retrieving the entire document; such metadata is used by a browser's display page or document-information summaries of modification date and size. And POST receives form content with a specified interface, usually an executable script or program.
From a protocol standpoint HTTP 1.1 adds a variety of features to the protocol, but those of principal interest to embedded systems are PUT and persistent connections. PUT allows for simpler uploading of content-so that when the client encounters the HTML tag INPUT TYPE=FILE ... , for example, an entire file can be PUT onto the server, as with FTP. Persistent connections allow the client to open a connection and the server to maintain that connection across multiple service requests, eliminating the onerous overhead of (re)opening and closing connections just to paint a single page with text and a few graphics.
The only other requirement for the designer to implement a servelet into an application is some understanding of the CGI (for Common Gateway Interface), said Ray O'Farrell, principal engineer at the Microtec Division of Mentor Graphics Corp. (San Jose, Calif.). CGI is a set of services that controls access to and communications with host resources. Its main focus is passing field names and content from HTML forms back to the server. Common applications include supplying criteria for queries to search engines, or in an embedded environment specifying configuration parameters or control information.
CGI solutions
There is much less to CGI programming than meets the eye-the input GUI processing is on the client, leaving embedded systems and their programmers to address more pressing tasks, like handling the data once received and acting upon it. However, for embedded Web applications CGI programming can constitute the meat of the application interface.
An alternative to a raw delivery method is to capture the form data stream and output the fields and values as environment variables. This allows a normal shell script or Perl program to process the input and optionally output a response, where standard output goes back out the socket, allowing for on-the-fly dynamic Web-page generation. Such an approach is very straightforward, albeit tedious, with a fully hosted public domain-free server like Apache, running under a Unix or Unix-like OS that offers shells, standard I/O and usually a file system; it will likely not function on a more deeply embedded system with more limited resources. Another way is to build complete HTML page images in system RAM and channel them byte by byte back out the socket, but such ad hoc approaches can also be resource- and compute-intensive.
Solutions based on CGI, but with C language interfaces, are emerging. Instead of having to parse the incoming amorphous stream of form data, these products present the programmer with options for receiving it, often already formatted and type-converted, into C structure fields, ready for program use. Servers offering this option include an "HTML compiler"-really a C preprocessor-that consumes either HTML or HTML/C hybrid source and produces C source code and headers for compilation and linking. This preprocessing also offers opportunities for optimization and compression of Web page content and tags.
As simple and relatively straightforward as the process of creating a servelet for use in an embedded application can be, said Ian Agranat, president of Agranat Systems Inc. (Waltham, Mass.), designers are quickly beginning to use commercially available ones for many of the same reasons that they have moved from building their own real-time kernels to commercial RTOSes: development and test time and expense, continuing support and the expense of continually modifying the software to meet new application requirements. "This shift, which took about 10 years to happen with RTOSes," said Dan Hildebrand, senior architect at QNX Software Systems Ltd., Kanata, Canada, "is occurring in the servelet market in a matter of just one or two years."
With this shift to commercial rather than proprietary servelets, vendors of embedded software are adapting the technologies to the particular markets they service. Companies such as Agranat, ISI, Microtec, QNX and Wind River are providing servelets to a wide range of their customers in telecom, datacom and networking who are looking for a lower cost but standardized alternative to the Simple Network Management Protocol (SNMP). Before embedded Web servelets, said Hildebrand, developers and users of bridges, routers and switches based on embedded processors had to use SNMP combined with proprietary front-end GUIs for each of their supported network management platforms.
Less time
Even simple product features could be delayed several months because of the significant effort needed. With servelet-based network-management schemes, said Agranat, time-to-market is considerably shortened. "Using the standardized servelets and tools now becoming available, developers can prototype and implement interactive HTML-based management schemes with browser-based GUIs in a matter of hours," he said. And unlike traditional SNMP management schemes that cost tens of thousands of dollars, the front-end GUI is free, there is no server hardware to purchase and the interface is easy to use.
Other companies, such as EmWare, are focusing on providing similar capabilities in the industrial, manufacturing and automotive areas where HTTP, HTML, CGI and TCP/IP can be used to complement or as an alternative to the control-oriented networking protocol. Some are adding servelets for standalone embedded apps with a degree of connectivity for monitoring and diagnostics.
Copyright (c) 1998 CMP Media Inc.
|
