Get on the Internet of Things fast with an embedded Web app server: Part 1
Embedded web applications generally must be able to let the web functionality affect the device operation. In other words, 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 interacts directly with system hardware is typically written in C and, because these routines are so system-specific, they need to be written during development no matter how the web connectivity is implemented. However, a web server has no way of accessing these routines, so some way of connecting the two must be built.
The two high-level elements created are:
- A way for the web browser to invoke another program
- A program that can take an HTTP request and, from the request contents, invoke the appropriate C code in the embedded application (Figure 3).
Figure 3: An environment is needed that allows the web server to hand off to a high-level script, which accesses low-level C routines.
These two functions are conceptually simple, but the details of what amounts to a translation from a web conversation into device action are tedious and error-prone. Developers frequently underestimate by a wide margin the amount of time required to produce this code. For this reason, using only a web server results in months of additional coding working on nitty-gritty details that an application server framework already has in place.
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 a variety of application scripts and executables that can handle requests for things other than simple resources. This means that an application server provides real-time decision making and business logic, invoking other scripts or programs and, if appropriate, dynamically creates response pages in real time.
Most important 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 to recognize and parse requests and generate responses for functions handled outside the web server. By contrast, the framework accompanying an application server typically has a library that includes request and response objects. The low-level generic work is already done, and the code can focus on adapting the requests and responses to your specific technology, whether to move the hydraulics, position the satellite dish, or sequence the lasers.
Each application server may provide a different set of resources for its targeted programming environments and languages.
Figure 4. The Barracuda Application Server includes a development framework and libraries for easily managing scripts (such as Lua scripts), C/C++ code, and system resources.
Figure 4 illustrates the elements provided as a part of such an application server. The application server can handle C/C++ code in addition to scripts. It includes support for plug-ins, secure transactions, various types of I/O, file storage, and even database functionality. The API that remains consistent between different operating systems guarantees ease of portability.
Selecting a development language
With an application server to ease the coding burden of translating a web conversation into device action and with C source code accessing the hardware interfaces, it initially appears best to stick with the familiar. If there is some C anyway, why not stick with it throughout? Why go to the trouble and expense of learning a new language?
To figure that out, let’s look at what needs to be done. Development work can be broken down into the following categories:
- Managing data
- Parsing requests
- Assembling responses
All of this needs string manipulation. String manipulation in C isn’t rocket science, but it’s tedious and extremely easy to get wrong. Everything must be strictly typed, and memory must be explicitly reserved and released as needed, requiring scrupulous attention to every detail and making maintenance difficult. Assembling a C server page requires string concatenation on a grand scale.
On the other hand, with Web scripting environments such as Lua, much of this work has already been done. The application server abstracts the web server details, giving access to request and response objects and their associated APIs. This means that the application specific code has to deal only with high-level behavior and data.
A single line of script can implement the entire string concatenation. The lower-level machinations are automatically handled. Scripts also access and manipulate data without the need to worry about data organization or type definition.
Another important distinction is that scripting languages use just-in-time compilation while the system is operating. Whenever the user navigates or refreshes the browser, the virtual machine compiles any changed script before it sends the requested page to the browser, thereby automating the host of compilation, linking, and other developer overheads associated with an equivalent C-based application. Figure 5 illustrates the development process.
Figure 5: Scripting languages ensure that the scripts are compiled just-in-time when requested by the browser. The diagram relates to the Lua language (Lua Server Page).
So the bottom line becomes clear. Web applications can be developed in as little as 1/30th of the time if, instead of using custom written C, scripts and pre-built infrastructure are used wherever possible.
Scripts don’t totally eliminate C from the equation. C is retained for what it does best (Figure 6). Scripting environments intentionally restrict scripts from getting down to the hardware level, so C routines (similar to drivers) connect the hardware to the web application.
Figure 6: Lua to C/C++ access is called a Lua binding and can be created manually or by using an automatic Lua Binding Generator.
Maintaining sharp user response
It would be easy to suppose that the overhead of compilation ‘on the fly’ would impact the user experience, but that is far from the case. In fact, the impact on response time is negligible compared with the overhead of the network connection. Lua web applications typically respond with lightning speed, even when run in small, web-based embedded devices.
That experience can be further enhanced by writing user interface applications that can send data to, and retrieve data from, a server asynchronously, in the background, without interfering with the display and behavior of the existing page.
Embedded is not the same
The difference in the embedded environment and the restraints it imposes make a massive difference to the optimal deployment of HTTP communication technology.
In the end, what really matters is that end users experience the system in a way that matches what they expect. By using web or application servers designed to work on small embedded systems along with an appropriate scripting language, you can focus on your key application development, giving your users the interface they want while letting you dedicate most of your energy to doing the things that you do best.
In Part 2 we will describe how to use the Lua Web scripting language to integrate Internet Protocol connectivity into your C-language application code.
Wilfred Nilsen, Founder & CTO of Real Time Logic,( http://realtimelogic.com/) has 25 years' experience in designing embedded software. Powered by a vision of a connected embedded systems, he designed the Barracuda Application Server, tailoring it for the small footprint, real-time needs of embedded microcontrollers and microprocessors.