by Brett g Porter
Manufacturers of embedded systems, once happy to provide command line interfaces and perhaps SNMP, have been moving steadily toward web-based management interfaces. The reasons for this are obvious: ubiquitous thin clients, the availability of development tools (and web developers), and lower end user support costs.
Unfortunately, the client/server call/response model imposed by the HTTP protocol leads to interfaces that do not always provide the level of control and interaction desired by engineers, or the richness of experience desired by marketing managers.
Attempting to overcome these limitations, engineers would sometimes add Java applets. But this typically leads to the same problem that has reduced the popularity of client-side Java in the rest of the web world -- the promise of 'write once, run anywhere' has turned out to mean 'write once, debug everywhere' due to a proliferation of almost-but-not-quite compatible Java Virtual Machines.
One other option that has been explored is the creation of standalone management applications, often using CORBA or some homebrewed protocol (or more recently, using a custom XML format). This works well in many cases, but at the expense of duplicating effort on the device side to support both a web interface and the custom application.
The emergence of two related protocols in the last few years provides embedded engineers with standardized, supported options for creating richer management interfaces for their devices. XML-RPC [1] and SOAP [2] were created by the same small group of engineers and serve similar needs. Both protocols are XML-based and provide a Remote Procedure Call interface that is routed over HTTP (meaning that it moves through firewalls easily). Being XML-based, both are relatively easy to parse and process.
Of the two, XML-RPC is much lighter, both in terms of the bandwidth required to carry its messages, and in the difficulty of implementing at both the client and server ends. At the time of this writing, there are 65 implementations available [3] of either client or server libraries of the XML-RPC protocol for languages including C/C++, Java, Python, and Perl (as well as less widely used languages such as REBOL, Pike, Squeak, and Ruby). Art & Logic has been using the ActionScript language included with Macromedia Flash [4] to create highly interactive management interfaces [5] that communicate with devices using XML-RPC. Many people assume that Flash is only useful for creating annoying introductions to web sites, but it's also a very efficient cross-platform vector graphics system that can be used to build great user interfaces. Macromedia claims that there are over 414 million installed copies of the Flash player, including all the recent releases of the major web browsers on all platforms (including handheld devices running Windows CE). Flash's vector-based design means that interfaces automatically scale themselves to the screen resolution of the player being used. Vector-based graphics are also more compact than traditional HTML approaches, an advantage that is significant in embedded applications where memory resources may be scarce.
The wide availability of client-side XML-RPC libraries also simplifies development when a standalone application is needed, or when it is useful to add device monitoring to an existing standalone application.
SOAP (Simple Object Access Protocol) was a follow-up to XML-RPC; since its initial introduction, it has grown enough that the 'simple' part of its name has become a misnomer. SOAP has been brought under the umbrella of the World Wide Web Consortium [6], the organization responsible for maintaining the standards used on the web. Microsoft has adopted SOAP as the protocol underlying its .NET Web Services architecture. This means that any of the .NET languages (including VB.NET, C#, Managed C++, J#, and Eiffel) may be used to create clients that can connect to SOAP servers and place calls to functions exposed by the server. Several other languages (including Java, Python, and Perl) also have libraries that enable SOAP access.
One potential downside of SOAP at the moment is that the complexity of the protocol and its refusal to specify a single way to do some important things (there are several schemes to encode data values, for example) have led to interoperability problems. As the tools and servers used with SOAP evolve, these growing pains will no doubt subside. Also, SOAP messages are typically larger than the equivalent XML-RPC messages.
Other applications for XML-RPC and SOAP include:
Links:
Brett g Porter is Art & Logic's Chief Engineer of Development Practices. Before Art & Logic, he worked in the broadcast electronics industry designing software to monitor FM stations, broadcast data, and distribute audio via satellite, picking up a patent along the way. Before that, he got two degrees in Composition, but decided to become a productive member of society.