Efficient SOAP processing for tiny embedded servers

Transcription

1 Efficient SOAP processing for tiny embedded servers Jan Janeček Dept. of Computer Science and Engineering, Czech Technical University in Prague This text gives a survey of activities in the project supported by the grant of Microsoft Research Cambridge, which has been aimed to the following areas: - development of an effective framework for applications running on tiny microcontrollers, giving them ability to communicate by the SOAP protocol, - development of an HW/SW framework that allows integration of cryptographic functions implemented in FPGA into PDA/Windows CE architecture, - use of the operating system Windows CE as a development tool for students projects in the course Application of Microcomputers. The report presents results obtained in the first and third area till 30/07/2004, the second area is covered by a separate material prepared by Dr. Jan Schmidt. Idea of a tiny SOAP server/application Middleware technologies based on the well standardised XML-based SOAP protocol are widely used for web services. Servers are powerful computers, which provide access to huge data sources, clients provide primarily a (graphical) user interface, and are available on desktops, notebooks, PDAs and smartphones. Communication between a client and server is generally limited to exchange of several messages, effectiveness is not therefore as important as non-restricted interoperability. Readability of data transferred in XML format can be advantage in some cases, but a simple and well-defined syntax of messages is more important: a common XML parser can be used to convert SOAP messages of different applications into data structures. The goal of our research has been to explore possibility of using SOAP communication in systems, where more small sensors are providing information to clients, which are, similarly as with web services, providing the user interface and evaluating/storing data, and in systems, where clients are sending commands to small controllers (Fig.). clients sensors / controllers web services Fig. System with tiny SOAP servers Advantage of SOAP in systems of this type is evident, development tools designed for web service clients can be used without changes. On the other side, technologies used in current web servers have system requirements, which small sensors/controllers cannot accomplish. Moreover, real-time behaviour of classical web server technology does not correspond to requirements of many control systems.

2 2 Structure of the SOAP analyser Any XML document/message, e.g. a SOAP request/ response and WSDL definition, can be described by a suitable language model: tree and hedge grammars are frequently used by theoreticians. Respecting requirements of effective implementation we selected a string based model: XML grammars. XML grammars form a subset of the context-free class, and we could use obvious compiler-compiler technologies (e.g. yacc/lex, JavaCC) to create a suitable validating parser. However, some features of XML (as defined by W3C, specifically common use of namespaces) and regular structures of XML grammar productions allow designing of more efficient analysers (from the viewpoint of the code length and space required) and analyser generating tools without enormous initial effort. The language of XML documents can be described in two layers by two grammars: - G t = {N t, T t, P t }, that describes the structure of XML tags, - G v = {N v, T v, P v }, that describes parenthetic structure of XML expressions/elements. The alphabet of tags T, which serve as terminal symbols for the grammar G v, contains opening tags a A and closing tags a A, i.e. T = A A. Each symbol a A has a corresponding counterpart a A. Tags are recognised by a tag analyser, which function corresponds, from the G v grammar viewpoint, to a lexical analyser in the standard compiler architecture. The tag analyser accepts words of the language generated by the rules of the grammar G t : T < ns : tname P > < /ns : tname > 2 < ns : tname P / > 3 < tname P > < /tname > 4 < tname P / > 5 P ns:aname = aval 6 aname = aval. Nonterminals T and P of the grammar G t represent tags and attributes. Terminals ns, tname, aname, and aval represent identifiers of namespaces, tag names, attribute names, and values correspondingly. The rules describe empty tags (lines 2 and 4 in the above definition) in addition to opening and closing tags. To simplify the description, empty tags can be eliminated omitting the corresponding lines and replacing each empty tag by the sequence of the corresponding opening and closing tag. The set of nonterminal symbols N v of the grammar G v has one-to-one correspondence with the set of opening tags A. If we denote these nonterminals X a N v, all productions of the grammar G v have one of the forms: X a a µ a a, X a a ν a a, µ a R a, R a N v ν a V al a where R a is a regular set over N v and V al a is set of strings that represents values of atomic elements. The production selected when an opening tag is presented by the tag analyser depends only on this opening tag. We have a single production for each opening tag, the set of opening tags and the set of productions is constructed from the WSDL document and used during a SOAP message reception. Since SOAP messages contain no type definitions, which are defined in the corresponding WSDL document, the set of productions is static. However, support for dynamic enhancement of the production set does no complicate significantly the implementation of the analyser, this fact is useful when documents with type definitions are analysed (e.g. WSDL documents). 3 SOAP analyser The overall structure of the engine that analyses SOAP messages, based on the G v grammar, is described in Fig.2. Each production entered during the parsing process is represented by a finite automaton plane bound to the element in the stack. The structure of each finite automaton, which is defined by the corresponding regular expression µ a is stored as a constant only once. All necessary state information (i.e. automaton state, namespace information, and variables required to prepare the invocation) is accessible through the stack. Therefore, the stack is the only dynamic structure required to analyse SOAP messages and prepare parameters for method invocations. All the overhead required by dynamic memory management of a standard DOM parser can be avoided, our SOAP analyser respects the pulling SAX model. Moreover, if SOAP is not used to transfer recursively defined data structures (this condition is obviously fulfilled), no automaton is referenced more than once from the stack and all the state information may be allocated memory space statically.

3 Because of the facts mentioned above, all the common functionality of the stub can be concentrated into predefined library routines, a specific definition of an interface may be stored as nonvolatile data and all the state information of activated finite automata may be stored in a statically allocated memory. The SOAP engine starts with the empty stack and an automaton that accepts the envelope of the SOAP message. When an opening tag is accepted by the tag analyser, a reference to the corresponding automaton and its data space is pushed in the stack. A correct closing tag pops a reference from the stack. The automaton that controls response generation and the automaton used by the analyser have the same format. µ b b b µ a a a µ ε Fig. 2 Data structures for the tiny SOAP analyser The framework developed to test the approach consists of a compiler, which creates a description of the SOAP automata (receiver serves to analysis of requests, sender forms responses) from the WSDL description of the service. (The WSDL description is generated from the server code or interface description prepared in a suitable programming language, we utilised WSDL descriptions generated from C# in Visual.Net and from Java by java2wsdl tool from Axis). The description is completed by definition of structures and corresponding access/construction methods, and linked to the common code of the server, TCP/IP stack and real-time kernel (Fig 3a.). definitions SOAP automaton data types system support interface application code TCP/IP Ethernet R/T kernel Fig. 3a Structure of SOAP processor Fig. 3b Charon II module The size of generated description and the size of common system support limits usefulness of the technology for systems with small program/data memory. Our implementation requires about 5 kb of the code memory for the 8-bit Atmel s Atmega28 and about the same size for the Intel s PC. With a (restricted) TCP/IP stack and a simple real-time kernel the application fits into a small microcontroller, we tested the technology at the Charon-II module (Atmega28, 28 kb Flash, 32 kb RAM, Mbps Ethernet, egnite s NutOS and TCP/IP stack - Fig.3b). These requirements are significantly lower than requirements of other technologies developed for embedded servers (CE.Net SOAP, esoap, ksoap), and lower than gsoap, based on yacc/lex technology.

4 4 Example of a tiny SOAP server To illustrate usage of a compiled SOAP application we can describe the interface between a client, implementing, for example, a graphical user interface and a multichannel sensor. The interface of the multichannel sensor, playing a role of the server is: namespace Sensor { public class Sample { public int Channel; public int Value; public int TimeStamp; } public class Service: System.Web.Services.WebService { Sample[] storage=new Sample[storageSize];... public Service() public void Initialize(int Channel, int Range) public Sample GetSample() public void SetSample(Sample val) public Sample[] GetAll() } } The sensor converts samples from its analog inputs into integer values stored in a memory buffer storage. Since we require both, synchronous sampling controlled by an internal clock, and asynchronous sampling controlled by external events, values are stored together with time stamps (represented as integers) and channel numbers in records of the type Sample. Individual samples stored in memory can be transferred to the client by the method GetSample. In addition, the method GetAll returns sequence of samples. The method Initialize defines parameters of the A/D conversion and empties the memory buffer storage. Another method SetSample inserts a marker or remotely measured value (e.g. a value from another sensor playing the server s role) into the sequence. There is no method to synchronize the clock of the sensor, a conversion of time stamps to the real time is provided by the control system. 5 Performance evaluation To have some comparison for the compiled SOAP application, we measured response times on general (e-business) purpose web servers. The servers were running on the.3 GHz Centrino, the clients were running on the.09 Ghz Athlon. Machines have been directly interconnected by their Base-T interfaces. A sequence of 00 calls to the Initialize method of our example (two long parameters, an empty response) has been measured, no additional load has been presented to servers. The processor s cycle counter has been used to measure time, providing resolution lower than ns. Results obtained for the Axis server (Fig.4) illustrate influence of the bytecode JIT compiler and adjusting of multithreading inside JVM. Response time has a high variation during stabilization period, mainly due to the fact that calls are opening its own TCP connections.

5 The IIS server gives better results. After a rather high delay for the firsts call (due to compilation of the server s code), the IIS server provides a more stable service. The drawback of the implementation lies in the fact, that the SOAP request is passed to the server only after the server responds to the HTTP POST header by an HTTP O.K message carrying the Continue clause (the time required by the first phase of the remote call is represented in Fig.5 by smaller points - lower line ) Fig. 4 Axis SOAP - response time Fig. 5 IIS SOAP - response time Response time of the compiled SOAP application has been measured on the 8-bit microcontroller, Atmel s Atmega28, with the clock frequency MHz running NutOS real-time kernel. Response time of.57 ms (for Initialize call) has a very small deviation (Fig.6), analysis of the SOAP request consumes only 2.7 ms and is faster than generation of the response from short textual items. To compare performance and behaviour of our SOAP analyser with Axis and IIS servers we compiled the same application for PC (the same compiler, gcc, has been used). Response time, presented in Fig.7, is shorter and has much lower variation, the SOAP analyser itself consumes only 8 µs (represented by smaller points - lower line - in Fig.7) Fig. 6 Charon II - response time Fig. 7 Charon PC - response time Performance evaluation of the compiled SOAP application proved the ability of the method to give reasonable response time even for tiny servers. The real-time behaviour (variation of the response time) of the compiled application is better than behaviour of the same service running on a general web server. We would like to complete performance data with measurements over wireless connections (Bluetooth, WiFi) till September Use of Windows CE in students projects We included semestral projects aimed to Windows CE applications on embedded systems into the programme of the subject Applications of Microcomputers in the summer semester 2003/04. The projects were aimed to applications, which communicate over TCP/IP. The hardware used in projects was acquired with the help of the MSR grant.

6 Specifically, we have used the following hardware: AMD Alchemy DBAu Development Board ( piece) Configuration: AMD MIPS processor 64 MB SDRAM 32 MB Flash memory / Mbps Ethernet two PCMCIA slots USB host/device controller flexible LCD/CRT controller touch screen interface JTAG interface bsquare s CE.Net BSP VIA processor based book-size PC (2 pieces) Configuration: VIA Eden/C3 500 Mhz processor 256 MB DDR SDRAM three / Mbps Ethernets PCMCIA slot IDE/DiscOnChip interface USB host controller Voipac PXA255 Development Board (2 pieces) Configuration: Intel Xscale PXA 255/300 Mhz processor 64 MB SDRAM 32 MB Flash memory two / Mbps Ethernets two PCMCIA interfaces LCD interface and display touch screen interface JTAG interface The selection of HW respects requirements of the education: AMD is a nice high-performance MIPS board supported by CE.NET (bsquare), the book-sized PC is a low-price compact system suitable for embedded use, and PXA255 is a typical industry-level board equipped with widely used Xscale processor. Work on the project resulted in the definition of three diploma theses that will be finished and defended in February 2005.