Embedded Web Servers and Application Servers: What's the Difference?

Embedded systems have traditionally been isolated, self-contained systems; at most, they might have communicated with other systems within a limited range on a local network. This is no longer the case: embedded systems — especially small, very deeply embedded devices — increasingly use the Internet as a way to communicate with each other and with the people managing them.

Whereas desktop-based web applications typically provide information or entertainment, embedded web applications can actually cause something to happen on the device. For example, you might change the direction of an antenna; you might start a motor; you might open or close a valve. The hard buttons that would normally be built into the system are effectively replaced by - or duplicated by - virtual buttons in a browser-based form.

Using the Internet to control an embedded system has a direct impact on the cost of building and maintaining the system. Physical controls like buttons mean additional components and cost as well as a design that must accommodate access to the controls. Even more importantly, embedded systems are increasingly being deployed in remote locations. In those applications, the cost isn't dominated by components, but rather by the people that must go out to maintain and operate the system. This makes remote access critical to the cost-effectiveness of the system. The Internet is the most straightforward way of getting to the target system because worldwide infrastructure already exists.

This means that such an embedded system must include integrated web connectivity so that it can respond to browser requests. Such Internet functionality can be acquired in a variety of forms from a variety of sources, both open-source and commercial. These generally fall into one of two categories: small, simple web servers and application servers having greater functionality.

Because a more specific distinction between these two types of server is rarely clear, it can be tempting to go with a free or cheap web server in an attempt to save money. But there is a tradeoff between the amount of server functionality and the amount of further development required to implement the complete web capability for a specific system. Money saved up front can easily be overwhelmed by coding time and product release delays, turning what appeared initially as savings into higher total cost of ownership (TCO).

Alternatively, one might be concerned that an application server is too large to be embedded in a device with limited resources, making a web server the only viable choice. The server footprint, however, is not a reliable distinguishing characteristic; application servers in particular can be large or small.

To be clear, the differences between a web server and an application server have blurred over time, so let's look at the classic distinction and the implications of each, both for operation and for development, before addressing points of overlap.

Web Servers

A web server has one role: to implement the HTTP protocol. This protocol allows a browser to issue a request to which a server will respond. Today's web is highly sophisticated, featuring elaborate graphics and streaming media, yet surprisingly, HTTP is a very simple protocol. All it does is transport requests and responses. Because HTTP is a stateless protocol, there is no intelligence in the operation: there is no decision-making or context, and there are no scripts or code to execute. There is also no concept of dynamic page creation; if a page is going to be created dynamically, some other program has to do that work and put the result where the web server expects it to be.

HTTP understands only nine operations (typically called "methods" or "verbs"), of which the most important are GET and POST. GET is used to download a "resource" (typically a file) located at a specified location (the "uniform resource locator", or URL). The response to a GET request contains the resource, accompanied by HTTP header information (Figure 1). When someone clicks a link in a web browser to go to a new page, they are sending a GET request to the server asking for the HTML page located at the URL they clicked.

Figure 1. A GET request simply results in a static file being returned.

POST is used to submit data from the web browser back to the server. This is the request that is generated when someone hits the "Submit" button on a filled-out form. A basic web server cannot process a POST request, since it will have no idea what to do with the data in the request. It must rely on some other program or utility to process the data.

On older standard websites, that utility might be a Common Gateway Interface (CGI) plug-in: the web server would simply hand any POST requests over to be handled by CGI. While CGI isn't appropriate for most embedded applications due to its size, performance, and inability to exist in a monolithic architecture, the fact remains that the web server needs something else to handle data returned by a web browser (Figure 2).

Figure 2. POST requests must be handed off to some other utility that will determine an appropriate response.

Most web-based applications need much more than this. In particular, embedded web applications generally must be able to let the web functionality affect the device operation - the remote browser has to be able to "talk" to the system. A web server has no such capability, so everything beyond the simple processing of HTTP must be written as a part of system development.

The low-level code that will interact directly with the system hardware will likely be written in C, and, because these routines are so system-specific, they will need to be written during development no matter how the web connectivity is implemented. The challenge is that a web server has no way of accessing those routines, meaning that some way of connecting the two must be built.

The two high-level elements that must be created are:

• A way for the web browser to invoke some other program;
• A program that can take an HTTP request and, from the request contents, invoke the appropriate C code (Figure 3).

Figure 3. An environment is needed to allow the web server to hand off to a high-level script, which accesses low-level C routines.

These two functions sound deceptively simple. Conceptually, they are simple, but the details of what effectively amounts to a translation from a web conversation into device action are tedious and error-prone. Developers frequently underestimate the amount of time required to produce this code by a wide margin. For this reason, using only a basic web server will result in months of additional coding. You end up spending many weeks of time working on nitty-gritty details, things that an application server framework has already put in place.

Application Servers

Application servers build onto web servers a much broader range of configurable functionality. At the very least, they provide a way for the web server to hand off tasks to any of a variety of plug-ins that can handle requests for things other than simple resources. This means that an application server will allow real-time decision making and business logic, invoking other scripts or programs and, if appropriate, dynamically creating response pages in real time.

Most importantly for developers, however, is the fact that application servers tend to come with complete frameworks for use in developing code for the system. For example, if only a web server is used, then one must write custom code for recognizing and parsing requests and generating responses for functions being handled outside the web server. By contrast, the framework accompanying an application server will typically have a library that includes request and response objects. The low-level generic work is already done, and your coding can focus on adapting the requests and responses to your specific technology.

Each application server may provide a different set of resources targeted for its targeted programming environments and languages. While C is familiar to many systems engineers, and is generally better for low-level code, there are higher-level languages that simplify the programming and eliminate the need to handle numerous low-level details.

Real Time Logic's Barracuda Application Server is a good example of an application server designed specifically for use on deeply embedded systems. It supports the Lua scripting language and its associated Lua Server Pages, providing a dramatic speed-up in code development. You can learn more about Lua in the Lua Whitepaper.

Figure 4. The Barracuda Application Server includes a development framework and libraries for easily managing Lua scripts, C/C++ code, and system resources.

Figure 4 illustrates the elements provided as a part of the Barracuda Application Server product. The application server can handle C/C++ code in addition to Lua programs. Support for different plug-ins, secure transactions, various types of I/O and file storage, and even database functionality are included. Greater transportability is afforded by an API that remains consistent between different operating systems.

It's Not Black and White

The differences outlined here between a web server and an application server apply in most cases, although, over time, the boundaries between the two have begun to blur. Typical basic web servers are more likely to focus on HTTP, while others may add a few features that were once associated only with application servers.

As an example, if all you need is a way to connect a web server to C/C++ functionality, the Barracuda Web Server provides web server capability and a C/C++ application framework for invoking C and C++ programs. While C programs take longer to develop and require that the server be taken down and restarted for updates (as opposed to Lua-based application server programs that are compiled on the fly), they do remain an option for embedded systems having limited web connectivity requirements.

Summary

Web servers and application servers both offer a way to provide an embedded system with an Internet presence. The difference lies in the amount of programming required to adapt the server to the system. Classic web servers simply process HTTP requests and responses; anything else must be developed from scratch. Much of that work amounts to spending time and money "reinventing the wheel" for common functions and infrastructure that aren't supported by a web server.

By contrast, application servers include frameworks that dramatically shorten the development cycle. Choosing an application server means that you don't have to write commonly-used communication and user interface functions or their underlying infrastructure for each system. Programming resources can instead be focused on functionality that is specific to the system.

In short, application servers will ultimately provide the lowest total cost of ownership by removing months of development time, dramatically reducing the risks of overly-optimistic project scoping, and reducing the possibility of unanticipated debugging delays.

An application server with high level scripting support provides a development environment that enables full-stack developers to design web based user interfaces for devices. This is possible thanks to the scripting language integrated in the application server . A full-stack developer can design web interfaces for devices -- something that they would normally not be able to do since they are not C programmers. Your embedded engineers can then focus on your device and only need to provide a device API for the full-stack developer(s).

The term full-stack means developers who are comfortable working with both back-end and front-end technologies. To be more specific, it means that the developer can work with LSP, HTML, CSS, JavaScript and everything in between, including Ajax and REST.

Learn more about how an application server with scripting support can help your team fast track the development and lower total cost of ownership.