To Bean, Or Not To Bean
by
Dr. Frank Pittelli
frank@navius.com
August 2001

There are vastly more embedded computers in the world than general purpose computers, controlling everything from your alarm clock to the space shuttle. Without embedded computers, life would not be the same as we know it. Yet, it is still more difficult and time-consuming to develop software for embedded systems, than it is for general purpose systems. One of the primary reasons for these inherent difficulties is the fact that there are a vast number of embedded processor types, software kernels and operating systems for software developers to consider. Each variation poses new possibilities and new constraints, forcing developers into a lowest-common denominator approach to cope with everything.
Throughout my 20 years of experience in and around the process control world, I have worked closely with firmware engineers to bridge the gap between embedded computers and the computers of the general purpose world. Specifically, I have designed and developed server-based systems that interact with many different types of embedded systems (e.g., telecomm test equipment, switches, smart cards, etc.) As such, I see first-hand the problems that the embedded programmers tackle and understand how their realities impact the way that external support systems must be designed and built. Based on this experience, I believe that the software development world is currently undergoing a major transition towards an approach that has a good chance of wiping out many of the traditional problems plaguing the embedded programmer. Specifically, the era of true embedded objects has finally arrived.
In simplest terms, an embedded object is a tightly-coupled collection of data values and processing methods. Object developers specify how each of the data values and methods can be accessed by an application, essentially wrapping the object in a "self-defense shield" that prevents external software from improperly using or modifying object data. Object-oriented programming has been around for well over 25 years and is the fundamental approach for all commercial operating systems, and increasingly for all general-purpose software. There are a number of very mature object-oriented programming languages, such as SmallTalk, Ada and Java, each of which provides other object features, such as inheritance, scoping, etc. However, for the purposes of our discussion here, we focus on the fundamental characteristic of an object: data and code as a self-contained entity.
In a conventional distributed system, two processes communicate by sending data from one side of a network to the other. In my world, an embedded process is typically on one side of the network and a general purpose application on the other side. As such, both developers agree on a data format ahead of time and develop code independently to that format. If one developer wants a new feature added to the protocol, an agreement is reached and both code bases are modified. This adherence to a data-oriented protocol essentially locks-in both sides to a relatively small universe of operations. Furthermore, since the code on either side of the data protocol is written in a different environment, two different developers are usually needed to effect a change.
In an object-based distributed system, two processes communicate by sending objects from one side to the other. That is, a collection of data and processing methods are exchanged by the systems. (In practice, processing methods (ie. code segments) are cached and are only physically transmitted if the cached version is obsolete.) Since data is always accompanied by its corresponding methods, developers on either side of the network are free to change how data is processed on the other side of the network without assistance from the other developer. More importantly, if one system is deployed for a relatively long time and cannot be updated (usually the embedded system), the other system (usually the server-based system) can effectively enhance the operation of the embedded system by sending new processing methods as needed to support changes in the data being exchanged.
For example, consider a digital camera and corresponding photo workshop software that is initially sold with the ability to process photos using the JPEG format. Furthermore, suppose that a year later, the new JPEG-2 format is released with lots of more features and advantages. If the digital camera uses object-based techniques, then whenever the camera first communicates with new JPEG-2 based photo workshop software, it can immediately download the necessary encoding methods and complete the transfer. From that point on, the camera can work with both JPEG and JPEG-2 formats, even though JPEG-2 didn't even exist when the camera was produced.
The object approach also works well for server-based systems. For example, consider the photo workshop software in the example above (usually a software application on a general purpose PC). After purchasing my favorite photo workshop software, installing it and learning how to use it effectively with my JPEG camera, my wife purchases a slick new JPEG-2 camera. Do I have to get a new photo workshop program? No. If an object approach is used to exchange the photos, the JPEG-2 camera can provide the workshop software with the necessary decoding methods and instantly the workshop software can process JPEG-2 photos.
Clearly, by passing data and processing methods as objects systems can be designed to be self-supporting and self-enhancing over time, thereby reducing a large number of operational issues associated with embedded systems. So, if the object approach has been around for so long and it has so many benefits, why haven't we been using such an approach all along? Primarily because we've never had a commercially viable programming environment that could span the breadth of embedded and general-purpose systems ... that is, until Java came along.
Java was designed by Sun Microsystems in the early 90's to be the first truly portable virtual machine specification and language capable of supporting the widest range of embedded processors. Specifically, Java was aimed at the "set-top box" market which, at the time, was suppose to become the next great convergence market between computers and entertainment. Although the set-top box market never really met expectations, Java parachuted into the Web browser market, which was desperately in need of a portable programming model in its early days.
In that infant, but rapidly growing market, Java showed that its object-based approach for distributed processing was not only possible, but practical. Almost overnight, users were downloading Java objects (conveniently packaged as applets) into their Web browsers (essentially an application engine embedded in a general purpose computer). Regardless of the underlying hardware, operating system or browser software, the Java Virtual Machine (JVM) worked well (or as well as could be expected in the wild-west early Web days) and Java objects were traveling around the globe.
After Java's usefulness was proved in the Web-browser world, Java returned to its true roots, as an object processing engine for servers and for embedded processors alike. Java defines and provides everything needed to virtualize a hardware environment and make it look and act like any other. More importantly, once Java exists on both sides of a network link, object exchanges become second nature. In fact, Java handles all aspects associated with transferring objects (data and methods) from one machine to another, including the marshaling of data types, security, caching, and the actual transmission. Developers need only add a few words to an object specification to inform Java that an object can be transferred between systems. Moreover, Java now provides a number of different higher-level techniques for not only exchanging objects, but dynamically determining what the object can do. In short, Java has spent the last 6 years making it easy for developers to build systems that are self-supporting and self-enhancing. (One such approach is named Java Beans, from which the title of article is derived.)
Java has already proven its usefulness in the embedded world and it will continue to become the De-facto standard for embedded systems. Already, the majority of all smart cards produced in the world support a Java-based environment. On such small, low-powered, low-memory devices, Java has made it possible for smart card applications to continuously be revised as the market continues to grow.
Dallas Semiconductor markets a similar type of device, known as the iButton, that essentially combines an smart card and a battery into an extremely tough, tamper-proof, stainless steel case that is roughly the size of a watch battery. The iButton is used to maintain medical records for cattle (in which case it is literally attached to the animal's ear), as a cryptographically secure authentication device for computers (carried as a ring, key bob, or necklace) and in a host of other embedded applications.
Java is also increasingly the virtual machine of choice in next generation PDAs and cellular phones. In all of these environments, developers are exchanging true objects between systems, not just data, thereby gaining all of the benefits cited above. More importantly, developers can now focus primarily on meeting application and market requirements, not on figuring out how to get around the limitations of their operational environment.
To Bean, Or Not To Bean - There's no real question anymore.

About The Author
Dr. Frank Pittelli is the CTO of Navius Technologies and has been designing and developing process control systems for over 20 years in both the government and commercial sectors. Dr. Pittelli has been designing, developing and marketing Java-based software systems and products since the day Java was first announced. He believes that Java not only solves a number of critical software engineering problems, but that it also significantly increases the ability of designers and managers to develop truly powerful systems. For more information about Navius Technologies visit www.navius.com or contact Dr. Pittelli directly at frank@navius.com.

In his spare time, Dr. Pittelli builds radio-controlled large-scale model tanks that are equipped with Co2-powered paint ball markers. For more information about R/C Tank Combat visit www.rctankcombat.com.