Imagine that Web services becomes successful beyond the wildest dreams of anyone involved with the technology. Take your imagination even further and suppose that every single PC, workstation, and server on the face of the earth communicates using Web services.

While that sounds like a fantastic scenario, if it were true we'd still be at a point where significantly less than 1% of installed microprocessors would be using Web services. So where are the rest of these microprocessors? They're embedded in the intelligent devices that pervade our world. There are literally billions of microprocessors sold each year, ranging from the low-end 8- and 16-bit systems that can be had for under a dollar to the high-end 32- and 64-bit systems that perform complex processing and control algorithms. From office copiers to automobiles to manufacturing equipment, and even down to lowly air conditioning systems, intelligence in the form of one, two, or even more microprocessors is present.

It's somewhat humorous, but ultimately disappointing, that many of the proponents of pervasive computing who talk about supporting devices of all types immediately eliminate 80% of the microprocessors sold each year because of their architectural decisions. In terms of number of devices shipped, embedded 8-bit microprocessors still outsell the more powerful 32- and 64-bit systems by almost an order of magnitude. These lower-end devices collect information that's just as valuable as that collected by their more powerful brethren, and they have even more to gain by being connected to a powerful distributed computing environment.

All of these intelligent systems are capable of generating, collecting, and storing vast amounts of valuable information. Unfortunately, this information has often been trapped inside the devices because there was no way to communicate with the enterprise systems that could turn this information into actionable knowledge. Web services are a powerful mechanism for connecting distributed, intelligent assets to the business enterprise to provide such valuable services as automatically generating service requests, monitoring usage, performing remote diagnostics, and reordering consumables .

Web Services in the Embedded World
The lines between embedded devices and enterprise software are blurring rapidly. Intelligent devices in the field contain incredibly valuable data about status, historical usage, consumables needs, wear and tear, and other parameters. In their continuing evolution (see Figure 1), connected devices have moved from standalone systems to the many Internet-enabled devices that exist today.

However, most developers have stopped short of full evolution by providing simple Web browser-based interfaces or, at best, point solutions. The drawback of these systems is that they don't get the information into the enterprise systems that can extract the tremendous value that exists. That value may expose itself as reduced field service operating costs, usage-based billing, additional revenues through replenishment systems, or some other value-added service that can be provided through the device. To do this, an end-to-end solution must connect the devices into enterprise applications such as an e-commerce, ERP, or field service application. What better way to accomplish this goal than by speaking what is be coming the native language of these enterprise applications - namely, Web services? A couple of concrete examples should clarify how an embedded device might use a Web service.

Accessing Web Services
Dispensing systems are good examples of critical assets. Whether they're dispensing specialty gases and chemicals for the production of integrated circuits, pumping liquids in a manufacturing process, or dispensing cleaning chemicals in a commercial kitchen, the operation of these devices is absolutely critical to the end user's business. Let's use an example where a dispensing system has detected a failure condition in one of its motors. In the prehistoric era of intelligent devices, the best the dispenser might have been able to do was write to a log file and put a message on its LCD interface to indicate that service was required. In a Web services world, the device may execute the previous two steps, but also call what appears to be a local Event Notification function. Under the hood, a Web service proxy would take the notification, wrap it up in a SOAP-encoded message, and invoke a remote Event Web service. The Event Web Service would take this event, a motor failure, and process it according to its predefined workflow and business rules.

The result of that processing may be the invocation of other Web services, such as submission of a service request into a field service application, as well as a check on the availability of a spare motor from an inventory management system. Through the use of Web services and Enterprise Application Integration, this simple request may trigger a variety of actions within the enterprise, enabling a highly automated environment. The result is that a simple component failure has automatically set into motion a complex series of events (before the customer may even be aware of the problem) that ultimately results in a faster response to a problem and a high degree of customer satisfaction. This is only one example of a Web service that could provide value to an embedded system. Ordering consumables, usage metering, and operational efficiency monitoring are just some of the functions that could be provided with the proper Web services.

Providing Web Services
Outbound invocation of a Web service makes sense, but what about the other direction? Why would a device want to be the provider of a Web service? To continue the previous example, let's say that the field service application has sent a wireless notification to a field technician's PDA. In the old days, the technician would call the customer to schedule a visit, arrive at the site, and plug into the dispenser to perform a set of diagnostic routines. All too often, this diagnostic sequence suggested that the proper fix involved a part that the technician didn't have with him, and a trip to a warehouse was in order. In a Web services world, the technician can use his PDA to remotely invoke the diagnostic routines; in essence, the PDA is the client to the Web services offered up by the device. The technician can perform the diagnosis remotely and arrive at the customer's site with the proper replacement parts in hand. Other functions, such as firmware upgrades and remote control, could also be provided using the Web services standards.

Furthermore, by allowing remote devices to "publish" their available services to public or private UDDI registries, the availability of services such as remote diagnostics or firmware upgrades can be determined dynamically. This provides greater flexibility and extensibility when creating applications that a typical field service technician would use. No longer does this functionality have to be hard-coded for specific device types.

Design Issues
Each new technology seems to bring with it a whole new set of design trade-offs and issues. Web services are no different. Embedded systems just seem to exacerbate the problem. Limited resources, severe cost constraints, and operational considerations combine to create a complex set of engineering trade-offs. A discussion of some of the purported issues surrounding Web services follows.

Security
Security is a major issue any time you're exposing device information to a public network. Security has many aspects, including encryption, authentication, and authorization. Unfortunately, the SOAP specification is noticeably silent about this issue. Any serious implementation of Web services must address such issues. Luckily, SOAP allows for an XML wrapper to be placed around the actual SOAP message. Within that message framework credentials can be presented and used to authorize a specific action. Fortunately, some Web service framework implementations targeted to the embedded world support authenticated access to authorized services. This works both ways in that only authorized people can access certain Web services provided by a device, while certain Web services provided by an enterprise may only be available to authorized devices.

Complexity
Just as when object-oriented programming (OOP) started to filter down into embedded systems, detractors may say that while Web services is fine for large systems, it just doesn't make sense for the embedded world. And, as with OOP and C++, people also tend to confuse the concept with a specific implementation. Web services is no different: it combines some of the best features of OOP and distributed computing. Let the processor best suited to a particular process or calculation handle that task but keep the actual inner workings of that task hidden behind a specific interface. Implementing the networking, XML parsing, and SOAP encapsulation can be a bit intimidating but there are tools designed to abstract away much of the complexity. For example, one company provides a WSDL compiler targeted specifically for embedded systems. Such a code generator takes an XML-based WSDL document as input and produces C++ code that implements a proxy for a Web service. For the application developer, this means that the Event Service (highlighted in the previous examples) is accessed with what appears to be a simple local function call such as Event.SubmitEvent(MotorFail ure). The proxy software takes that function call, wraps it in a SOAP message, and sends it out over the network. When the response to the SOAP message arrives, it is parsed and the result code is returned to the calling routine.

This is especially attractive when taking an existing design and giving it the capability to access Web services. Most existing devices write to a log file or output a diagnostic code when a fault is detected. Submitting that fault event to an enterprise application becomes a matter of adding one more function call in the fault handling routine.

Resource Constraints
One of the main features that defines an embedded system is that you don't have enough memory, processing power, or some other resource to do what you want to. The thought of adding an XML parser and SOAP encoding engine to a system seems problematic at best. In many cases that might be true - a full-blown XML parser can easily add over 180Kb of code. Fortunately, many of the features of the XML standard are not required for SOAP encoding. A well-pared XML parser that fully supports SOAP can be under 20 Kb in size. For those truly constrained devices that can't handle even that small amount of code, Web services can also be invoked without using SOAP at all. The WSDL specification also allows a port to be bound to an HTTP POST or GET verb targeted at a specific address. This allows the invocation of a Web service to be as simple as sending an HTTP POST or GET URL-encoded request to a specific URL as shown below:

POST /EventService/EventServlet HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: nnnn
[CR][LF]
operation=EventService&authenticationToken=xXXdDj2edph
&description=motot+failure&source=54321

Web service frameworks targeted towards embedded systems exist that provide an HTTP client and server and support URL encoding while consuming under 5Kb of code space.

Verbosity
The verbosity of the text-oriented HTTP solution has multiple system impacts, affecting RAM usage, bandwidth requirements, and operating costs. XML is a text-based language and provides the significant advantage of making platform independence a trivial task. The downside is that text-based systems are inherently less efficient than a binary system. This leads to more data being transmitted and larger buffers required to both prepare outbound messages and receive inbound messages. One approach to addressing this downside is a technique called Compact URL encoding. This encoding scheme builds on the URL encoding provision built into the WSDL specification but adds further compression to minimize both RAM usage and the amount of data sent over the network. Savings of 5x to 10x are easily achievable.

8- and 16-Bit Support
Many platforms that claim to support embedded systems really mean they support 32-bit systems that run a real-time operating system (RTOS). In other words, they support only about 15% of the processors out in the field. What about the other 85% of the processors, are they doomed to proprietary networking systems at best or standalone operation at worst? Certain proprietary networking software companies that say an 8-bit processor simply can't handle a full-blown TCP/IP stack have been proven wrong (there are at least a half-dozen 8-bit TCP/ IP solutions available today). Combining these stacks with the URL encoding technique mentioned above creates a whole new opportunity for connected systems.

If the view of Web services as a distributed computing model is subscribed to, many new applications and features become possible. For example, addressing the slowly deteriorating performance of an industrial compressor can be a complex statistical calculation based on historical data and current environmental factors. If a more capable application server has access to this information it can handle the calculations, generate a service request for a field technician, and also provide feedback to the device, such as going into a lower rpm mode to minimize vibrations in order to extend the life of the asset until help arrives. This gives the end customer continued use of that asset but perhaps at a lower capacity. Eight-bit applications that can invoke two different Web services over a TCP/IP stack (with full gateway routing support) have been demonstrated in under 20 Kb of code on an 8051 type architecture. Consider the impact of even the most mundane devices, such as a compressor or smart sensor, being able to participate in the community of a business enterprise.

Enterprise Integration
The large number of packaged and custom-developed enterprise applications is surpassed only by the incredible number of different types of embedded systems. The business rules surrounding specific events and actions add even more complexity. To extract the value of the information provided by these newly connected devices, it's critical that this information be accessible to the enterprise applications that can analyze the information and apply the business rules. Standalone visualization tools such as an HP OpenView only provide a view at the current point in time; historical information - which is extremely valuable - is often lost. Other solutions that provide a database to collect historical information along with a specific point application are also available. Unfortunately, these solutions provide little or no integration into existing enterprise solutions that often cost a company several million dollars.

The different data models and APIs make this integration an onerous task. In addition, devices may want to talk to multiple applications, such as both a field service application and a spare parts procurement system, making things even more complicated. By incorporating customizable workflow engines into an enterprise's Web service environment, end-to-end solutions can be created that benefit all aspects of both the service and supply chains. As mentioned earlier, enterprise applications are quickly moving to the Web services model. What better way to ease the integration of devices into this enterprise world than to speak the language!

Summary
Web services is rapidly becoming the native language of business applications. History shows that technologies designed for the enterprise often find their way into embedded systems and that the speed of adoption for these technologies is increasing. Capturing the real value of connecting devices to the Internet goes much further than providing a standalone database for collecting information or providing some proprietary XML interface.

As shown in Figure 2, a system-level Appliance-to-Business (A2B) approach results in the connection of the devices that contribute information, the enterprise systems that can analyze the information and apply the proper business rules, and the increasingly mobile workers who can act on the results of the aforementioned analysis as well as interact remotely with the devices. Only when these three constituencies are served will the tremendous value of the connected world be completely realized.

References

1. "A2B Technology Overview," Questra Corporation, June 2001, www.questra.com.
2. "SOAP Specification V1.1," W3C Note 08, May 2000, www.w3.org/SOAP.
3. "WSDL Specification," W3C Note 15, March 2001, www.w3.org/TR/wsdl.
4. "UDDI Specification," uddi.org, September 2000, www.uddi.org.

Author Bio:
John Canosa is chief scientist of Questra Corporation. He has more than 20 years of experience in the industry, including communications systems, analog circuit design, microprocessor and computer design through large software design efforts, and pretty much everything in-between. John has been a highly rated speaker at numerous conferences and has delivered training and tutorial sessions at many Fortune 500 companies. jcanosa@questra.com