Code Generation Techniques for Developing Web Services For
Total Page:16
File Type:pdf, Size:1020Kb
Published in the proceedings of the ACM SIGAPP SAC Conference, 2004 (Embedded Systems track) Code Generation Techniques for Developing Light-Weight XML Web Services for Embedded Devices ∗ Robert van Engelen Department of Computer Science Florida State University, Tallahassee, FL 32306-4530 [email protected] ABSTRACT ner prescribed by its definition, using XML based messages This paper presents specialized code generation techniques conveyed by Internet protocols.” [22]. This definition is often and runtime optimizations for developing light-weight XML refined to the use of the Web Services Description Language Web services for embedded devices. The optimizations are (WSDL) [23] for describing and advertising Web services, implemented in the gSOAP Web services development envi- SOAP [4] as the XML-based message packaging format, and ronment for C and C++. The system supports the industry- HTTP (HyperText Transport Protocol) [12] as the transport standard XML-based Web services protocols that are in- protocol. tended to deliver universal access to any networked appli- The ubiquity of HTTP and XML enables a high-level of cation that supports XML. With the standardization of the transport interoperability. The internal logic of an applica- Web services protocols and the availability of toolkits such as tion can be securely exposed to the Internet or local network gSOAP for developing embedded Web services, new oppor- as a service [20]. Such networked applications can actively tunities emerge to integrate embedded systems into larger participate in various forms of Internet transactions, rang- frameworks of interconnected applications and systems ac- ing from simple information services, such as checking flight cessing dynamic resources on the Web ranging from hand- status information with a cell phone, to more elaborate ap- held and embedded devices to databases, clusters, and Grids. plications such as Google searches [10], the controlling of “smart” buildings [17], and Grid systems [2, 9] for collabo- rative scientific research. However, the complexity and verbosity of XML Web ser- Keywords vices protocols creates a whole new set of design tradeoffs Networking, XML, Web Services, Embedded Systems and issues for developing Web services applications for em- bedded systems. Embedded systems rarely have enough memory and processing power to run an HTTP Web server, 1. INTRODUCTION SOAP engine, and XML parser. The verbosity of XML and Recent developments in Internet protocol standardization HTTP increases RAM usage, bandwidth requirements, and have led to the publication of a collection of XML-based pro- operating costs. Current Web services implementations do tocols that are meant to enhance cross-language and cross- not adequately address these issues [5, 6, 19]. platform interoperability, thereby encouraging systems in- This paper presents specialized code generation techniques tegration. More specifically, a Web service, as defined by and runtime optimizations for developing light-weight XML the W3C Web Services Architecture Working Group, is “a Web services for embedded devices. The techniques aim software system identified by a URI, whose public interfaces to reduce memory, network, and processing requirements and bindings are defined and described using XML. Its def- of SOAP/XML over HTTP. The optimizations are imple- inition can be discovered by other software systems. These mented in the gSOAP [21] Web services development envi- systems may then interact with the Web service in a man- ronment for C and C++, available from SourceForge and included in the IBM alphaWorks Web Services Tool Kit for ∗This material is based upon work supported by NSF Grants CCR-9904943, CCR-0105422, CCR-0208892, and by Mobile Devices (WSTKMD) [11]. DOE Grant DEFG02-02ER25543. Any opinions, findings, The remainder of this paper is organized as follows. Sec- and conclusions or recommendations expressed in this mate- tion 2 presents a brief overview of the most widely used rial are those of the author(s) and do not necessarily reflect systems and protocols for application-level communications. the views of the National Science Foundation. Several Web services implementations for embedded systems are also presented. Section 3 introduces Web services basics. Section 4 presents the gSOAP Web services toolkit followed in Section 5 by the presentation of the optimizations and Permission to make digital or hard copies of all or part of this work for code generation methods. The paper is summarized with personal or classroom use is granted without fee provided that copies are results in Section 6 and conclusions in Section 7. not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific 2. RELATED WORK permission and/or a fee. SAC ’04, March 14-17, 2004, Nicosia, Cyprus Several systems and protocols have been proposed and Copyright 2004 ACM 1-58113-812-1/03/04 ...$5.00. developed since the early 1980s for inter-application data exchange. This section briefly reviews some of the most The IBM alphaWorks Web Services Tool Kit for Mobile widely used systems and protocols, and presents Web ser- Devices (WSTKMD) for Java, C, and C++ includes the vices development toolkits for embedded systems. kSOAP and gSOAP toolkits. The gSOAP toolkit [20, 21] Sun Microsystems’ RPC (Remote Procedure Call) com- is the only Web services development environment that in- piler generates code that is used by client and server ap- cludes a fully automated RPC compiler supporting pure plications to exchange data over a network. The runtime C and C++ Web services applications. The goal of the RPC parameter encoding and decoding mechanism is re- gSOAP project is to develop an easy-to-use portable Web ferred to as parameter marshaling and demarshaling, respec- services software development toolkit that fully automates tively. The marshaling routines convert application data the development and deployment cycle of efficient C/C++ into XDR (External Data Representation) [13] for transmis- Web services. The gSOAP compiler selectively generates sion. XDR does not support pointer-based data structures, code to limit application code size and to reduce run-time such as graphs. It only describes the most commonly used memory, network, and processing requirements of Web ser- data-types of high-level languages such as C so that applica- vice applications. The gSOAP 2.3 release is WSDL1.1 and tions written in these languages will be able to communicate. SOAP1.1/1.2 compliant and includes an HTTP1.0/1.1 Web CORBA is a platform-independent architecture for ORB server, an XML parser/generator, an RPC compiler, and (Object Request Brokerage) [15]. CORBA uses the IIOP a WSDL importer (compiler preprocessor). gSOAP 2.3 is (Internet Inter ORB Protocol) for data transmission be- portable to most platforms, including Linux, Unix (e.g. AIX, tween CORBA applications. CORBA’s IIOP supports a BSD, HP-UX, Irix, Solaris), Cygwin, Windows, Mac OS X, wide variety of data types that can be specified in the IDL Palm (OS 3,4 and 5), Pocket PC, Symbian, and cell phones. (Interface Description Language). CORBA is a heavy weight The gSOAP toolkit will be further discussed in Section 4. product and not very well suitable for embedded devices. Microsoft’s DCOM protocol is similar to IIOP and en- 3. WEB SERVICES BASICS ables COM objects on different Windows-based systems to Figure 1 shows the layered Web services architecture model. communicate. Although DCOM is a platform-independent protocol, it is mainly used within Windows environments. The transport layer is at the bottom of the model. The Sun Microsystems’ Java RMI (Remote Method Invoca- firewall-friendly HTTP (HyperText Transfer Protocol) tion) automatically marshals objects for communication be- and secure HTTPS are used to invoke Web services tween Java applications. There is no limit on the type of with HTTP POST request-response message exchanges. data objects that can be exchanged, since Java has built-in data serialization capabilities. Java supports the serializa- The packaging layer uses the XML-based SOAP protocol. tion of arbitrarily complex data structures such as graphs. Figure 2 depicts a SOAP 1.1 message transported with A large number of Web service implementations for var- HTTP/1.1. A SOAP message consists of an Enve- ious languages are available. A few of these support em- lope root element, an optional SOAP Header to encode bedded systems. Note that the “standard” embedded Web meta-information (such as authentication data, signa- servers [3, 18] do not support Web services standards but tures, routing points, and transaction tokens), encod- merely offer an HTTP interface. ing rules defining how messages should be processed, The following light-weight Web services implementations and an RPC representation in the SOAP Body that are suitable for embedded systems. Most implementations defines how to represent remote procedure calls and include an (embedded) HTTP Web server. They also typ- responses, such as the RPC method name and its pa- ically offer a library-based API (Application Programming rameters. The SOAP encoding style uses both scalar Interface) for SOAP/XML packaging. SOAP/XML mes- types (strings, integers, floats, and so on) and com- sages are constructed using a C++ or Java class library. pound types (structures and arrays) that can be used The micro-services framework [16] considers a subset of to carry application data. The values of these types the Web services protocols, with a scaled down Web server appear as XML elements within the method parame- and SOAP library with limited support for SOAP/XML ters of the SOAP Body. A SOAP Fault element (not data types. Only a subset of the SOAP/XML primitive shown) is used to carry error information to transfer types and compound types is supported. remote exceptions. The eSOAP [8] toolkit for C++ and Java, developed by EXOR International, is a proprietary SOAP implementation for embedded systems with an API based on a class library.