XML Web Services for Invisible Computing

XML Web Services for Invisible Computing Johannes Helander Researcher Microsoft Research

Outline • The goals of Invisible Computing • Why Web Services? • Our approach • Table driven serialization • Distributed real-time • Trust and secure discovery • Componentized RTOS • Real-time C# • Developing code for small devices • Educational & research opportunities • Availability

Why Invisible Computing? • The computers stay out of sight and do their job. • No setup hassles • Make everyday objects better by adding computation and communication • Natural user interface – not screen and mouse • Rudimentary autonomous operation – added value from services • Incremental deployment • Devices communicate with each other • Devices communicate with big computers as needed

Sample Applications • Home appliances, security, lighting • Medical electronic devices • Wearable Computers • Robotics, Industrial Control, National Infrastructure • Sensor networks • Wireless communication gadgets • Audio Net • Disaggregated PC, smart I/O cards • Toys

Hardware trends • 32 bit microcontrollers are as cheap and power efficient as 8 bit MCUs • Single chip computer is a reality • Cost close to $5 (“Home depot” price point) • No need to aim at lowest point  sweet spot • Aggregate of medium volume market is huge  Partially reconfigurable hardware • Make hardware easy for software people

[VCR] XP Embedded [Pacemaker] • Interoperability • Security • Data analysis [watch] • Power • Bandwidth • Processing • Routing • Security • Real-Time • Non-graphical UI • Zero-configuration An Invisible Computing Scenario

What are Web Services? • The general-purpose solution to communication, in XML • Convergence of EDI, RPC, MSMQ, app specific protocols and formats Agnostic to underlying transport • All about interoperation. Allows partial understanding • Across-the-board presentation layer • Common protocols obviate need for proxies • Builds on critical mass and momentum

Do they Scale? • XML Web Services conceived to solvee-business interop problem • Implementations geared towards high-end computers • The same interop problem is the crux of Ubiquitous computing • Critical mass required in any business • Resource constraints: • Silicon – footprint • Energy – parsing overhead • Bandwidth – size of messages  Efficient implementation and compression

SOAP example "Add" request, from PC to NTU simulator, via HTTP then forward to EB63 via encrypted UDP <soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/ > <soap:Header soap:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ > <rp:path xmlns:rp=http://schemas.xmlsoap.org/ws/2002/05/routing > <rp:fwd> <rp:via >http://172.31.46.26/COB/calc.cob </rp:via> <rp:via reservation=“sensor/button">x-udp-aes-soap://172.31.41.244/COB/calc.cob</rp:Via> </rp:fwd> <rp:rev><m:via vid="1"/></rp:rev> </rp:path> </soap:Header> <soap:Body soap:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ > <m:Add xmlns:m=http://tempuri.org/Calc/message/ > <A>14</A> <B>28</B> </m:Add> </soap:Body> </soap:Envelope> The calculator is a popular interop test

Yes, it Works! Implementation shows you can successfully: • Realize web services on small low-cost devices, providing good interoperability with PCs and other devices • Achieve a high level of security and privacy on those devices • Integrate security, discovery, and functional assignment into a hassle-free user experience • Setup your home completely independently, yet securely federate with external entities such as e-business • Use web services for real-time tasks Demoed at booth #31

Microsoft Invisible Computing A software platform for low cost embedded systems that communicate with each other and with big computers • Flexible development for multiple platforms • Interoperation with small and big computers • Web services and .NET • Security and privacy • Real-Time • Energy aware • Low parts cost (targeted for <= $5 computer) • Sweet spot: enough for real use and critical mass but no frills • XML Web Services: interoperability, tuned for performance • Component Based RTOS • Standard protocols: TCP/IP, SOAP, PKCS#1, etc. • .NET virtual machine for C# games or other extensions

Invisible continued • Interoperates with ASP+ and SOAP Toolkit on Windows XP • Client and server, P2P • Complete TCP/IP, HTTP, SOAP, Automation, discovery, trust & security, RTOS (dynamic memory, threads, etc), drivers, application with complex data.  Runs in computer with 32KB of RAM, 256KB of ROM. Fewer components  smaller footprint. TCP/IP is biggest hog. Crypto not optimized for size.

Table Driven Serialization • Processes messages automatically according to description • XML metadata description • Compiled offline into compact description • Extensible at runtime • Process while receiving • Zero copy networking • Serializer & parser share buffers with network stack & crypto • COM-Lite automation • Turns messages into object calls • Multiple methods in one message • Multiple transports and encodings • UDP, HTTP, Encryption, Compression • Routing, roles, and conversion

Scheduling Scheduling Sampling Sensor readings Distributed Real-Time • Experiment in distributed scheduling • Real-time data-flow Instigator Producer Consumer

Real-Time continued • Serialize scheduling trees into XML • Reservations pre-declare future activity at each node • Instigator of activity orchestrates and tunes reservations based on feedback samples • Worker nodes accept/reject schedules  Merge of trees. Location independent. Could write scheduler in XSL. • Coordinated schedules allow shared resource scheduling. Could turn off radio. • Statistical decision making • Confidence test, quality control sampling schedules, probability based admission control • Concept demo shown at booth #31

Real-Time continued Serialized reservation example <rs:task xmlns:rs=http://tempuri.org/X-Reservation name=“sense1”> <rs:reservation name=“producer” deadLine=“2004-12-31T00:00:00.5Z“ tolerance="P456S“ duration="P0.1S"> <rs:resource name=“cpu"> <rs:quantity>2000</rs:quantity> </rs:resource> <rs:resource name=“RF-transmitter-1"> <rs:quantity>77</rs:quantity> </rs:resource> </rs:reservation> <rs:reservation name=“consumer" deadLine="2004-12-31T00:00:00.2Z“ tolerance="P82S" duration="P0.1S"> <rs:resource name=“RF-receiver"> <rs:quantity>100</rs:quantity> </rs:resource> </rs:reservation> </rs:task> Triggers, sub-reservations, resource estimates, tolerances

A Secure Invisible Home

Setting up a Secure Home • Create house authority, e.g. usbkey • Touch each device once with usbkey • Admits device into trust domain • Determines functional relationships heuristically • Discovery process finds device with desired function + does key exchange • House authority can be offline • RSA + AES • Write hash of house authority’s key on check to establish trust with bank  Federation of independent trust domains

Trust and Discovery • Simple SOAP based trust and service discovery for ad hoc networks • Integrate trust and functional setup • Integrate key exchange with discovery • Simple user interaction • No external CA required • Use Global XML Architecture when infrastructure present • Optimized for cluster of nodes. Base station (PC) deals with global issues • PKI works on small devices(but can be boosted) • 13s RSA decrypt, 0.03s AES on 25MHz Arm7 • FPGA takes times down by factors of 3000 and 10000 (3ms & 2µs) • Strong crypto necessary for marketability • Would people buy surveillance equipment against themselves?

RTOS Architecture Support for web services on a chip • General purpose in the abstract. Code and interface reuse. • Special in the concrete. Only take what you need. • Component Based • Objects everywhere • COM interfaces • Unified namespace • Same interfaces implemented by many components • Multiple implementations of any component • Specialized to task • Pay as you go • Late binding and mutation • Adaptive to changing requirements • Real-time scheduling with application feedback • XML based configuration and communication

RTOS continued • Hardware platforms • ARM (many), i386, H8, MIPS, TriMedia, Map1000, 68k, eCOG1 • Numerous development boards. Prototype gadgets. Smart I/O cards • Can be compiled with numerous compilers • ROM sizes e.g. 10KB, 20KB, 200KB on ARM; 26KB, 240KB on x86 • Power e.g. 40mW on 5x7 cm 2.8V ARM board with LCD when playing a simple game (snake)

It Still Has to be Small! WinXp Invisible

Real-Time C# • CLR desirable option for embedded systems • Great for extensions, games, apps • Not practical as the exclusive solution in embedded systems • Our real-time scheduling extensions • Prototype API implemented • Work Item Scheduler allows mixing native and managed threads • Native execution stacks are multiplexed

Developing Code for embedded systems using Microsoft Invisible Computing • Start with emulation, then simulation, and finally real hardware • Debugging on real embedded h/w painful  minimize time spent on this • All MS Invisible Computing environments have the same interfaces and basic configurations • Winbig • NTU • Giano • Boards

1 – Winbig • Runs on Windows XP • Uses XP sockets, threads, files • i386 binaries • Pleasant development underVisual Studio • Smallest SOAP stack for Windows XP • “big” is the configuration where everything is linked together usually used for ROM images

2 – NTU • Runs on Windows with i386 binaries • Implements its own threads and scheduling, etc. • Closer to real thing • One thread for “CPU”, one for “timer chip” • Enables debugging network stack and scheduler under Visual Studio

3 – Giano • Hardware simulator • Interprets ARM instruction set • FPGA simulation enables hardware- software co-design work • Easy to add new “hardware” peripherals • 14 MHz eb63 board on fast PC • Easier to work with than real boards • Extremely close to real hardware,except for real-world interactions (e.g. no A/D pins)

4 – Boards • Real boards test actual hardware– reality check • Development boards still not exactly the same as a real product Another step closer • Instrumentation and monitoring through FPGA co-board • JTAG debugging, still unpleasant • Most software development done in simulators – very little left to do here

Education and Research • Microsoft Invisible Computing is a research prototype • Experiments in seamless computing through embedded web services • Has been used by academia • Steve Liu at Texas A&M • Open invitation to participate

Availability • http://research.microsoft.com/invisible • Community Source License allows research and education use with few strings attached • New code will be added periodically • No support available at this time • The work presented in this talk was contributed by the MSR Invisible Computing Group Alessandro Forin, Johannes Helander,Behnam Neekzad, Stefan SigurdssonSpecial thanks: Paul Pham, Yong Xiong

XML Web Services for Invisible Computing