Article in Embedded Systems Development
This article was published in December, 1998.
Java Works for Access and Control--If You Know the Ropes
Peter Dudley
Java has excited so much excitement in the past four years primarily because of its potential - not just for dancing text and little juggling cartoon characters, but also for dynamically displayi but also for dynamically displaying and working with data gathered over the network. Vendors of network infrastructure equipment such as routers, switches, telecom switches, etc., have discovered this first.
Now they're trying to figure out how to harness the promise and power of Java while continuing to ship reliable, on-time, within-budget products. Other industries are sure to follow this lead as more embedded systems gain network connectivity and control layers.
There are alternatives to embedding an entire Java Virtual Machine. Choosing the right architecture for a Java implementation is the key to success; taking the wrong tack can lead to critical problems down the road.
Benefits and Detriments
Java offers some significant benefits to vendors of embedded systems, but it also may have serious drawbacks. The first thing to remember about Java is that it brings application-level functionality into the Web browser. This means that besides the display and input (HTML), scripting (JavaScript), and messaging (E-mail) capabilities already built into browsers, there is now an additional application layer available. This application layer can collect, aggregate, and manipulate data and then pass that data either on to the screen (dynamic charts, tables, graphgraphs, and gauges) or to other applications (locally or remotely).
For monitoring and dynamic control of embedded devices, this is a powerful proposition. A single Java applet can collect data from an embedded system, make calculations using that data, and then take action-whether to reconfigure the embedded device, notify an external application of the data, or display a graph on the screen. This is, in fact, the best use of Java today for embedded devices: application-level control of the devices through a Java-enabled browser.
As embedded system engineers are well aware, however, Java has some inherent drawbacks that make implementing it a daunting task. Many of these drawbacks can be overcome by understanding the role Java should play in the embedded system today, as well as the proper architecture for implementing it.
There are three major approaches to Java-enabling embedded devices, each of which have advantages and drawbacks. Only one of the three-using a brokered applet architecture-provides the benefits of Java-based access and control while avoiding the pitfalls of the other two approaches.
Embedding JVMs
Embedding a Java Virtual Machine (JVM) is usually the first approach considered bered by engineers who design embedded systems and are assigned the task of implementing Java. This approach is fraught with difficulties, which is why most engineers look at it briefly, then dismiss the idea of using Java with their embedded systems. This mistake usually stems from not being exactly sure what Java should be used for, i.e., what problem it solves. Today, for embedded systems, Java can provide sophisticated access, configuration, monitoring, and control capabilities through a browser or on a Java terminal. This implies that the Java should be run on the terminal, not necessarily within the device itself.
Running Java within the embedded device presents many problems. First, it's a different language from the lingua franca of embedded programming, namely C.
Second, the Java Virtual Machine has a large enough footprint to eliminate it from being embedded into many devices.
Third, the JVM does not inherently work with all the application C code already built into the device-it would take months, possibly years to rewrite all that code to properly work with an embedded JVM.
Fourth, the JVM doesn't work "out of the box" with existing protocols like SNMP, protocols that are critical to many projects.
Fifth, Java applets can usurp precious bandwidth and processing power, leeching those assets from the embedded application. Sixth, embedded Java Virtual Machines have problems with real-time execution, primarily due to the garbage control mechanism.
That list is enough to turn many engineers away from Java before investigating it fully. But alternative architectures exist that allow you to harness the power of Java without embedding a Java Virtual Machine, and still maintain the performance of your device.
Applets that Use SNMP
Because many embedded engineers implement Java for device management, they naturally move to what is familiar: the simple network management protocol (SNMP). Nearly all network hardware has or will have an embedded SNMP agent. So what better way to offer Java support than to create applets that use the SNMP protocol to interact with the device and monitor its data? Not only is this comfortable for the engineer, but it allows the Java to sit outside the device, leaving the core application and embedded C code largely intact.
This approach would appear easy to implement because it doesn't touch the embedded code. Unfortunately, it also has serious, if not fatal, drawbacks.
First, the Java applets to be developed are likely to be custom-built for the developer. This results in an entire new code base for Java-based management. This needs to be maintained along with the embedded SNMP, command-line, and Web (HTML) code bases already being maintained.
Second, the applets either need to be embedded into the device to be served at run-time-requiring at least a minimal HTTP server, a basic file system, and additional memory-or they need to be housed outside the device on a proxy server. Because the goal is to leave the embedded system untouched by using the existing SNMP agent, the only solution is to introduce a proxy server for the applets. The introduction of a proxy server, and the need to maintain version compatibility between the Java applets and the embedded system, can provide real maintenance and support headaches.
Third, Java doesn't inherently support the SNMP protocol, so all of the connectivity with the device needs to be implemented in Java by the vendor. When coupled with the fact that different browsers support different versions of Java, this can provide a real problem.
Finally, and perhaps most important, is the fact that many corporations disallow SNMP traffic through their firewalls. However, they do allow HTTP tr traffic. If the embedded engineer can guarantee that no SNMP barriers exist between the browser and the embedded device, this may not cause any problems. It does, though, instantly eliminate many of the benefits of using a browser for access and control in the first place: improved tech support, improved customer interaction, and access from anywhere via the Internet.
At best, then, this approach simply allows a local browser to act as a simple one-to-one SNMP terminal for the given device. At worst, it introduces new points of failure (proxy servers), additional versioning and deployment headaches, and new pressures on the engineering staff (learn Java, support this new interface) while offering only limited value.
Using an Applet Broker
A third approach solves the problems inherent in the first two approaches by introducing two architectural concepts that interact to provide a "connectivity and control layer" within the device. These two concepts are a backplane that exposes the embedded data elements within the device, and a broker that manages the communication between the embedded backplane and the Java applets running in the browser.
The Embedded Backplane
Since the real purpose urpose of using Java with an embedded device is to access and control the embedded data within the device, the first step is to expose those embedded data elements so the Java applets can get and set them. Using a backplane eliminates the need to have the Java code hook directly into the application. Instead, it provides an abstraction layer between the application code and the external use of the data.
This abstraction layer provides several key benefits. First is the ability to "plug in" support for existing implemented protocols such as SNMP. By taking advantage of existing SNMP Management Information Bases (MIBs), network device vendors can instantly leverage all of the investment they've made in developing and testing those MIBs.
Without the ability to inherit those MIBs, the developer has to create an entire new code base to support a Java-based representation of those data elements. This means additional embedded footprint and adding new code to support in the future. That is, when a new data element is added to the application, the engineer would have to implement a representation in their command line interface, another as a MIB, and yet another for the Java management layer.
By using a backplane architecture, the engineer can use the same single code line in th the embedded application for all of the supported access technologies.
The second key benefit is the ability to "plug in" support for new access technologies. Although the task today is to implement a Java interface, a year from now there will be an additional requirement, perhaps CORBA or XML. Without a backplane architecture, a new code base for that new technology would have to be implemented. Instead, by using a backplane, developers can leverage all of the work already done. They can simply concentrate on the new interface rather than having to write all of the embedded code to support it as well.
The third key benefit of a backplane is that it completely separates the external representation of the data from its internal incarnation. This is key in ensuring that Java development can proceed in parallel with the embedded C code development. It also means that once the embedded code is finished, additional Java development can continue without interrupting the stable, embedded image. By completely separating the Java code from the embedded C code, the backplane makes the development process dramatically more efficient and fast. It also allows update of the Java interface after the product is deployed, allowing field customization of the Java interface.
The The Applet Broker
Although exposing the embedded data elements from within the application is a critical aspect of implementing Java, equally important is the architecture chosen for the Java itself.
As shown earlier, embedding a Java Virtual Machine fails to solve the problems at hand and, in fact, incurs tremendous overhead and implementation burdens. The other approach, then, is to use applets that run in the browser and interact with the embedded backplane. In this way, the applets can use any communication protocol supported by the backplane, which avoids having to hook directly into the embedded application's C routines.
Such a solution still has a communication problem, though. If a screen has multiple applets on it-for instance, six different gauges and graphs-then each of those applets will poll the embedded device continually for its own data. What results is six different HTTP requests constantly being built up and torn down. This turns into a significant resource drain on the monitored device and invites uncertainty about the data being delivered. The simple act of monitoring the device affects its performance.
Instead, a broker applet can be used to manage all communication between the applets on the management screen aen and the backplane in the embedded device. The broker should be downloaded to the browser with the other applets and must be able to control all of them. It acts as an information clearinghouse, multiplexing and demultiplexing all information requests and deliveries.
Of course, the broker still has to communicate with the embedded device, so it must use a protocol supported by the embedded system. At this point, the embedded system typically supports at least SNMP and HTTP, but neither of those is ideal for constantly passing embedded data to a Web browser, potentially through the Internet and firewalls.
The solution is for the embedded system to add a small connectivity layer that can support a lightweight protocol such as the user datagram protocol (UDP). The broker applet also can support that protocol for the Java applets on the client side, resulting in an efficient, reliable, non-intrusive communication scheme.
Implementation
The good news for embedded system engineers is that all three of these approaches can be either implemented as custom designs or built using commercial technology. The bad news is that if you choose an implementation that has downstream limitations, you can end up with much higher costs over the lihe life of your product. You also may end up with a heavy maintenance and support burden in your engineering organization.
It's important to remember that the approach you choose will be with you and your project for several revisions and releases. It must provide not only the immediate feature required but also the longer-term benefits of being easy to extend, easy to maintain, and easy to update. Specifically, the features you should incorporate are
- A backplane-like method of hooking into the embedded application and the embedded data; complete separation of the Java development from the embedded C code, allowing easy updating of the Java without requiring changes to the embedded code.
- Strong development tools to reduce or ideally eliminate the need to change development practices. It is a good idea to try to find a toolset that lets you build Java applets using components so that you don't have to learn Java if you lack the expertise.
- A lightweight protocol used over the wire between the applets and the embedded application.
This combination of features provides a powerful Java implementation today with little impact on the embedded code. It also creates strong integration with existing management technologies and offers benefits throughout the entire lifire life of the embedded product.