Web services are coming to the enterprise, and embedded use can't be far behind. Here are the basics.
Technologies originally designed for scientific and enterprise computing often find their way into embedded systems. For example, the very first electronic computer, ENIAC, was designed to calculate artillery and missile trajectories. Today's missiles contain embedded computers that not only calculate but also control those same trajectories. Other examples of technologies originally developed for mainframe and server systems that have filtered down to embedded systems include RS-232, virtual memory, instruction/data caches, operating systems, graphical displays, and TCP/IP.
Perhaps the only change in this trend over the years is that technologies are adopted with increasing speed. Any organization that wants to stay abreast of developments in the embedded world should keep at least one eye on what is happening in the enterprise and desktop computing space. Right now, the biggest developing story in the enterprise space is web services. It is unusual to see the likes of Microsoft, Sun, IBM, Oracle, HP, and others agree on anything, yet they all agree that web services will soon be the native language of business applications.
When you hear about Microsoft's .NET, Sun's ONE, HP's e-services and IBM's WebSphere, you are hearing about web services. Most of these organizations speak of web services in the context of Business-to-Business (B2B) and Business-to-Consumer (B2C) information exchange and e-commerce. As you will discover in this article, web services are just as powerful for connecting embedded systems and other distributed intelligent assets into the business enterprise. They can help provide such valuable services as automatically generated service requests, remote diagnostics, and automatic consumables reordering.
A web service is a programmable component that provides a service and is accessible over the Internet. Web services can be standalone or linked together to provide enhanced functionality. Buying airline tickets, accessing an online calendar, and obtaining tracking information for your overnight shipment are all business functions that have been exposed to the outside world as web services.
Web services consist of methods that operate on messages containing either document-oriented or procedure-oriented information. An architecture that is based on web services is the logical evolution from a system of distributed object-oriented components to a network of services. Web services provide a loosely coupled infrastructure that enables cross-enterprise integration.
Web services differ from existing component object models and their associated object model specific protocols, such as CORBA and IIOP, COM and DCOM, and Java and RMI, in that the distributed components are interfaced via non-object-specific protocols. Web services can be written in any language and can be accessed using the familiar and firewall-friendly HyperText Transport Protocol (HTTP).
Figure 1: Web services stack
As shown in Figure 1, web services consist of multiple layers that, when stacked together, form the basis for a standard mechanism for discovering, describing, and invoking the functionality provided by a standalone web service.
At the bottom of the layered architecture model, any of the standard Internet protocols may be used to invoke web services over the network. The initial definition focuses specifically on HTTP/1.1 (and the encrypted HTTPS).
HTTP/1.1 is a text-based “request-response” style protocol, which specifies that a client opens a connection to a server, then sends a request using a very specific format. The server responds and, if necessary, keeps the connection open. Other request-response style protocols, such as FTP and SMTP can also be used, though they are not yet defined in the standards around web services.
Simple Object Access Protocol (SOAP) is a lightweight protocol designed for the exchange of information. Focused on distributed, decentralized environments, it provides a framework to invoke services across the Internet. It also provides the mechanism for enabling cross-platform integration independent of any programming language and distributed object infrastructure.
SOAP represents the evolution of xml-rpc and has been adopted as an Internet standard. SOAP is text based (eXtensible Markup Languge, or XML) and can run over HTTP, making it better able to operate in the face of firewalls than DCOM, RMI, or IIOP. SOAP is also easy to implement on an embedded device, unlike ORBs.
SOAP does not define a programming model or implementation. Instead, it defines a modular packaging model and the encoding mechanisms for encoding data within modules. This allows SOAP to be used in any number of systems ranging from message passing systems to remote procedure calls.
A SOAP message is XML-encoded and consists of three parts:
- An envelope, which provides the framework for packaging message information
- Encoding rules that define how messages should be processed
- An RPC representation that defines how to represent remote procedure calls and responses
The SOAP specification also defines bindings to transport SOAP messages using the HTTP protocol. SOAP messages are uni-directional. Individual messages are typically combined to form a request/response mechanism.
Listing 1: SOAP request message example
POST /a2b/EventService HTTP/1.1Host: a2b.example.questra.comContent-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: /a2b/EventService#SubmitEvent
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Header>A2B Header</SOAP-ENV:Header> <SOAP-ENV:Body> <SubmitEventRequest> <Source>Copier54321</Source> <Description>MotorFailure</Description> </SubmitEventRequest> </SOAP-ENV:Body></SOAP-ENV:Envelope>
Listing 1 shows an example SOAP message. This example shows the request message for an “Event” web service, where the information of the message is XML content, and the packaging is accomplished using SOAP. The result of the SubmitEventRequest is returned as another SOAP message, as shown in Listing 2. This message is packaged as part of the HTTP response.
Listing 2 SOAP response message example
HTTP/1.0 200 OKContent-Type: text/xmlContent-Length: 316<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Body> <SubmitEventResponse> <Status>OK</Status> </SubmitEventResponse></SOAP-Env:Body>
The SOAP message exchange model requires that applications receiving a SOAP message execute the following sequence of actions:
- Identify all the components of the SOAP message that are intended for this particular application. Applications may act as SOAP intermediaries and pass parts of the message on to other applications.
- Verify that all the mandatory parts specified in the SOAP message are supported by the application, and process them accordingly.
- If the SOAP application is not the end destination of the message, it should remove all the parts that the application consumes and then forward the message to the next application the message is intended for.
The SOAP encoding style uses both scalar types (strings, integers, and so on) and compound types (structures and arrays). These types appear as elements in an XML document. The data types defined in the XML schema specification, along with types derived from those, can be used directly as SOAP elements.
Any robust messaging system must expect that faults may occur; SOAP is no exception. SOAP has a built-in fault element that is used to carry error and status information. Because it is based on XML, the fault-reporting system of SOAP is highly extensible and quite flexible.
The SOAP specification details the mechanisms used to make remote procedure calls (RPC). The example in Listing 1 actually invokes a remote procedure (in this case a web service called EventService) by packaging the parameters the procedure requires as a structure. The response to a method invocation is also modeled as a structure that contains the return value and possibly the parameters (in the same order they were passed).
Web services and SOAP are two different things. SOAP is simply one way to package and bind the information required to invoke a web service. It happens to be the method that is most commonly associated with web services, but web services can be invoked using other encoding techniques, such as simple URL-encoded messages for bandwidth-constrained scenarios. In addition, SOAP itself is not strictly relegated to web services. SOAP can be used as an access mechanism for any type of remote objects or procedures or as a simple message passing mechanism.
XML is a meta-language that enables cross-platform data interchange using a standard method for encoding and formatting information. Unlike HyperText Markup Language (HTML), XML lets you publish information not only about how your data is structured, but also about what it means (that is, its context). In addition, significant benefits accrue through maintaining an XML document's structure, content, and presentation as three distinct components. For example, part of the content of an HTML document may look as follows:
This instructs a browser to display the text string “Motor Failure” as bold text. HTML is purely about formatting and display. XML takes it much further and provides information about what the content is describing, not just about how it looks. For example, an XML document may take the same text but actually apply a data type to it as follows:
This format gives the interpreter of this document a clearer understanding of what the text signifies. (For more information than anyone could possibly absorb about XML, go to www.xml.org.)
Some people will tell you that all you need to do is support XML in your devices to solve all of the world's problems. But XML is only a markup language; supporting XML does not magically integrate you into a host of business applications or make for a complete solution. XML may provide a description of an event as a fault, but it does not provide the device or business logic that says what to do when that fault occurs or how to ensure that the fault indication is properly captured in one or more enterprise applications. That is why the higher-level concept of web services, which are based on XML, is so important.
The interface to web services is defined in the XML-based Web Services Description Language (WSDL), which provides all of the information necessary for an application to access the specified service.
A WSDL document is an XML description of a web service. WSDL takes great pains to promote reusability. Several abstract and concrete elements are combined to define the functionality and access mechanisms of a web service. The following list enumerates the elements used to define a web service:
- types-containers for data type definitions can be scalar or complex, currently based on the XML schema
- message-an abstract, typed definition of the data being communicated
- operation-an abstract description of an action supported by the web service
- port type-an abstract set of operations supported by one or more end points
- binding-a concrete protocol and data format specification for a particular port type
- port-a single endpoint that is an instantiation of a port type in combination with a binding and a network address
- service-a collection of related ports
A web service is defined in a collection of ports, which, in turn, are a collection of abstract operations and messages. Keeping the operations and messages abstract allows them to be bound to different protocols and data formats such as SOAP, HTTP GET/POST, or MIME.
Listing 3 (available at ftp://ftp.embedded.com./pub/2002/02canosa.zip) contains an example WSDL document. It describes an Event Service that might be invoked by some remote device wanting to indicate a fault condition. Section 1 of the document describes the data types used by the event service. Of particular interest is the complex type “Event,” which contains information useful to the processing of the fault including the ID of the device submitting the event, a description of the event, and a timestamp.
Section 2 of the document describes the messages that are involved in invoking a service.
In this simplified case there are two messages-one to actually invoke the service (SubmitEventRequest ) and a response message sent from the service to the requestor (SubmitEventResponse ).
Section 3 describes the abstract ports available. This example has one port that supports one operation. The operation is accessed through a SubmitEventRequest message. When the operation completes, it sends out a SubmitEventResponse message. If an error occurs during processing, the operation sends out an a2bdt:Exception message that is detailed in a separate data type definition document.
Section 4 of the document defines an abstract binding of an operation (SubmitEvent ) to a SOAP remote procedure call (RPC) mechanism using HTTP as the transport mechanism. Both the input and output messages of this operation are SOAP encoded.
Finally, Section 5 ties everything together to create a concrete service. What makes it real is the inclusion of a location where the service can be accessed, in this case a URL.
While this looks like a complex document at first glance, it is, in fact, no more intimidating than some of the API documents that exist for making operating system calls or accessing functions from a software library. Code generation tools also exist that can read in a WSDL document like this and output skeleton interfaces and classes for your choice of programming language. These code modules enable transparent access to a web service through a local proxy mechanism. Accessing a web service then becomes as simple as making a local function call.
The final, and optional, piece in the web services protocol stack is the Universal Description, Discovery, and Integration (UDDI) specification. UDDI offers a way to publish information about web services, as well as provide a mechanism to discover what web services are available. In essence, UDDI is a registration system instantiated as a series of XML files, and associated schema, which contain a description of a business entity and the web services that it offers. It is envisioned that there will ultimately be many public UDDI registration servers distributed about the Web that continually replicate data amongst themselves.
The UDDI specification provides a programmatic interface that allows a business to register a web service and/or search through the registry for a specific web service. Once the desired web service is identified, a pointer to the location of the WSDL document is provided. It is important to note that UDDI is entirely optional. Companies with web services that want to limit specific functionality to people or devices of their choosing need not advertise their service externally.
A couple of concrete examples should help clarify how an embedded device might use or provide a web service.
A digital copier has detected a failure condition in one of its motors. In the prehistoric era of intelligent devices, the best the copier might do is write to a log file and display a message on its LCD interface to indicate that service is 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 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 pre-defined 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 this use of web services and enterprise application integration, a device's self-diagnosis of an error condition requiring a replacement part may trigger a variety of actions within the supportive enterprise. A simple component failure can 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 the problem and a high degree of customer satisfaction.
Outbound invocation of a web service makes sense for some devices, but what about communication in the other direction? Might an embedded system 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 connect to the copier to perform a set of diagnostic routines. All too often this diagnostic sequence suggested that the proper fix involved a part that the technician did not have with him and a trip to a warehouse lengthened the process of repair. In a web services world, the technician might use his PDA to remotely invoke the diagnostic routines, letting his PDA be the client to a web service offered up by the device. Other functions such as firmware upgrades and remote control could also be provided using the web services standards.
Supporting embedded systems
Each new technology seems to bring with it a whole new set of design tradeoffs and issues. Web services are no different. Embedded systems exacerbate the problem in the following areas.
Complexity. As with object-oriented programming and C++, people tend to confuse the concept of web services with a specific implementation and deem that, while fine for desktop computers, these technologies are not appropriate for embedded systems. Implementing the networking, XML parsing, and SOAP encapsulation can be a bit intimidating, but much of the complexity can be abstracted away through the use of proxy services. 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(MotorFailure). Proxy software simply receives that function call, wraps it in a SOAP message, and sends it out over the network to be handled remotely.
Resource constraints. The main characteristic that defines an embedded system seems to be that you rarely have enough memory, processing power, and other resources. The thought of adding an XML parser and SOAP-encoding engine to a system seems problematic at best. However, a well-pared XML parser that fully supports SOAP can be under 20KB in size. For those truly constrained devices that can't handle even that much code, web services can 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. Web service frameworks targeted towards embedded systems that include an HTTP client and server, support URL encoding, and consume less than 6KB of code space are available.
Verbosity. The verbosity of HTTP increases RAM usage, bandwidth requirements, and operating costs. XML is a text-based language that provides the significant advantage of making platform independence a trivial task. The downside is that text-based systems are inherently less efficient than binary systems. This leads to more data being transmitted and larger buffers being 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 a factor five to 10 are easily achievable.
8- and 16-bit support. Many software packages that claim to support embedded systems really only support 32-bit systems running an RTOS from a small supported list. What about the billions of 8- and 16-bit processors out there-are they doomed to proprietary networking at best or standalone operation at worst? With the support of the growing number of small TCP/IP stacks, 8-bit applications that can invoke two different web services over a TCP/IP stack (with full gateway routing support) have been demonstrated in under 20KB of code on an 8051 type architecture.
Enterprise applications are quickly moving to the web services model. There's no better way to ease the integration of an embedded device into an enterprise than to have it speak the proper language. The true impact of networking an embedded system cannot be felt without taking advantage of the information the device makes available. Enterprise systems are the engine that turns this information into actionable knowledge, which translates into increased revenue and profit for your company.
John Canosa is the chief scientist at Questra. He is also a contributing editor of Embedded Systems Programming. He earned a BSEE from Clarkson University and an MSEE from Rochester Institiute of Technology. Contact him at .