Computer Networks 51 (2007) 4634–4654

www.elsevier.com/locate/comnet

XML messaging for mobile devices: From requirementsto implementation

Jaakko Kangasharju *, Tancred Lindholm, Sasu Tarkoma

Helsinki Institute for Information Technology, P.O. Box 9800, 02015 TKK, Finland

Available online 23 June 2007

Abstract

In recent years, both the number and capabilities of mobile devices have increased rapidly to the point where the mobileworld is becoming a significant part of the Internet. Another recent trend is the increase in XML use for communicationbetween applications. However, the mobile world has been reluctant to adopt XML due to its verbosity and processingneeds.

We consider here the problem of providing an XML-based messaging system for mobile devices. We analyze therequirements that the environment places on such a system and elaborate on these requirements by concentrating on threecomponents that seem most amenable to improvements, namely XML processing interfaces, XML serialization, and mes-sage transfer protocols. In tandem with the analysis we also present the design and implementation of our messaging sys-tem that addresses these requirements.

Our experimentation of this system is extensive and performed completely on real devices and real wireless networks.Based on our implementation and experimentation we conclude that there is potential for improvement in XML messag-ing. The largest gains are achieved by using an asynchronous programming style and by using a compact serialization for-mat. The improvements are also individually integratable into existing systems.� 2007 Elsevier B.V. All rights reserved.

Keywords: XML messaging; Mobile devices; XML processing interface; XML serialization format; Messaging protocol

1. Introduction

The number of Internet-connected mobiledevices has increased rapidly in recent years. Cur-rently, network applications on such devices aremostly limited to Web browsing and mobile-specific

1389-1286/$ - see front matter � 2007 Elsevier B.V. All rights reserved

doi:10.1016/j.comnet.2007.06.008

* Corresponding author. Tel.: +358 50 384 1518; fax: +358 9694 9768.

E-mail addresses: jkangash@hiit.fi (J. Kangasharju), tancred.lindholm@hiit.fi (T. Lindholm), sasu.tarkoma@hiit.fi (S. Tarko-ma).

URL: http://www.cs.helsinki.fi/u/jkangash/ (J. Kangasharju).

services like WAP and i-mode. However, with thecapabilities of mobile devices increasing, their userswill also want to use the more sophisticated distrib-uted applications being built over the Internettoday, so the technologies used in these applicationswill need to be mobile-friendly.

The foremost unifying technology of modernWeb applications is XML [1]. Web services, basedon the SOAP protocol [2,3], are a prominent plat-form for wide-scale distributed interoperable ser-vices. Interactive and multimedia applications,using XML-based technologies such as XForms

.

J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654 4635

[4] and SMIL [5], are expected to become a largerpart of the future, and they are already usable onmobile devices [6]. Finally, future mobile users willnot be merely clients of fixed-network services, butalso providers of services, such as Web pages [7].

However, the mobile community has not beenenthusiastic about using XML. Mobile devices areweak in processing power and their wireless net-work connections can be very slow and expensive,while XML is very verbose and has considerableprocessing requirements. To solve this apparentincompatibility, improvements will need to be madebefore XML can be fully adopted by the mobilecommunity.

We focus on the cornerstones of distributed XML-based applications, the transmission of (mostlysmall) XML documents over wireless networksand conversions between XML and application-specific data, which can be summed up as XML

messaging. Our work has taken the form of anXML-based messaging system that forms the basisfor communication in our Fuego middlewareplatform [8]. The full middleware platform, whichincludes this messaging system, is available underan Open Source license at the Fuego Core projectWeb site.1

Our implementation process was largely iterative,driven by the needs of the other components of themiddleware platform. There was little actual workwith available implementations for mobile devices,so we needed to implement practically all of the sys-tem by ourselves. An exception to this was XMLparsing and serialization, for which there does exista widely-used implementation for mobile phones.This is fortunate, as implementing an XML parseris not a trivial undertaking, and having to do thatwould have distracted us from the goal of providinga complete messaging system.

The presentation in this paper takes a whole-sys-tem approach, with individual components not cov-ered in depth, but rather from the point of view ofhow they fit into the system. Similarly, all experi-ments are performed for the whole system and nonefor the individual components. Earlier we havepresented an overview of the system design withoutsystem-level experimentation [9]. Additionally, pre-vious publications have treated in more depth theXML processing interface [10] and the XML serial-ization format [11].

1 http://hoslab.cs.helsinki.fi/homepages/fuego-core/

We first introduce the environment of mobiledevices and its challenges in Section 2. The require-ments analysis for the system and the description ofour implementation begins in Section 3 with anoverview of the whole messaging system, and iscontinued in Sections 4–6 by concentrating on thesystem components. We present extensive perfor-mance measurements on actual mobile devices in areal environment in Section 7. Issues that weencountered in putting our ideas into practice onreal devices are covered in Section 8. Related workin the area is reviewed in Section 9 and Section 10concludes the paper.

2. Background

The world of mobile devices is significantly differ-ent from the world of desktop computers and serverson a fixed network. The main qualitative difference isthat the source of power for mobile devices is aportable rechargeable battery integrated into thedevice. The energy from the battery is consumedwhenever the device is turned on, and computationand especially network communication increaseenergy usage. As users are reluctant to recharge theirdevices too often, saving energy by reducing bothprocessing and data transmission is the paramountconcern of efficiency for mobile devices.

There are a variety of network-capable mobiledevices, ranging from mobile phones to PDAs andlaptop computers. We have chosen to focus onmobile phones, as they are the cheapest, most wide-spread, as well as being the weakest, so a systemworking on them should also work well on otherdevices. High-end mobile phones are also the mostversatile in the number of ways to connect to othercomputers, so they provide a good platform forcomparing different network technologies.

Processors on mobile devices typically use anARM architecture, with mobile phones having100–200 MHz models. Available memory on mostphones is typically a few megabytes, with the mostrecent high-end models having 10–20 megabytes leftfor application use. Permanent storage is flash mem-ory, so there is no paging or virtual memory. Thepermanent storage may appear to programmers asa hierarchical file system, but this is not alwaysthe case.

Networking on mobile devices is based on wire-less technologies. Bluetooth [12] is an energy-effi-cient short-range networking protocol, most oftenused as a replacement for connecting appliances

Fig. 1. A generic messaging system structure.

4636 J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654

with wires, but also usable for general-purpose com-munication. Mobile phone networks such as GPRS[13] and the later UMTS [14] are built on networksof base stations, and they support long-range com-munication with roaming wherever the base stationnetwork extends, but with an energy cost severalorders of magnitude more than Bluetooth. Finally,Wireless LAN (WLAN) [15] is also available onhigh-end phones, usually with no roaming but alonger range than Bluetooth, and average energyconsumption roughly equal to mobile phone net-works but with much less variation.

To consider other characteristics of these net-working technologies, we note that the bandwidthachievable with Bluetooth is approximately700 kb/s, with WLAN 2 Mb/s, and with GPRS170 kb/s (these are theoretical numbers; in reality,e.g., GPRS bandwidth is rarely above 40 kb/s).UMTS promises 2 Mb/s, but only when stationary;with mobility the bandwidth can drop even to128 kb/s. Network-layer latency in Bluetooth isaround 50 ms, and in WLAN 10 ms. With GPRSand UMTS latency is typically on the order of onesecond and is highly variable.

The term ‘‘mobile computing’’ is commonly usedfor two different concepts. One is the case of a cli-ent–server architecture where the client is mobileand the server is on a fixed network. This modelalready brings out many of the issues in mobilecomputing, so it is often sufficient to focus onlyon this aspect. The other case is where communica-tion occurs between two mobile devices, either in aclient–server or a peer-to-peer manner. The lattercase also includes mobile ad-hoc networking(MANETs) [16], where a group of mobile devicesform a network with routing requirements. We donot see any MANET-specific issues in XML mes-saging, so we will limit ourselves to point-to-pointcommunication between mobile devices.

For actually writing programs for mobile devicesthere are several alternatives, but the most commonones on mobile phones are C++ for the Symbianoperating system [17] and the Java Mobile Informa-tion Device Profile (MIDP) [18]. We elected to useJava despite it being much slower because JavaMIDP programming is much closer to regular Javaprogramming than Symbian C++ is to regularC++, and because, based on our experience, wejudged the development tools for Java to be muchmore mature than for Symbian, which reduces thetime spent battling the quirks of the developmentenvironment.

3. System composition

The outside interface of a messaging system con-sists of two parts: the API provided to programmersand the protocol used with other systems. The pro-tocol is further divided into the syntax of applica-tion messages and the communication semantics.Finally, as we have selected XML as the messagesyntax, we will also consider the API used forXML processing separately. Fig. 1 shows thesecomponents in a generic structure, with an exampleof how a message is passed from sender to receiverand what forms it takes during processing andtransmission.

3.1. Requirements on the system API

The most common programming interface ofWeb services today follows the strict single-request-response model of HTTP [3,19]. However,in mobile networks, synchronous operation is oftenunacceptable due to the high latencies, so there ismuch interest in asynchronous communication pat-terns like publish/subscribe [20,21]. In our view, fullpublish/subscribe should be implemented on higherlayers, and the messaging system should concentrateon point-to-point communication. Even so, thereare a variety of message exchange patterns (MEPs),the most common of which are shown in Fig. 2.

The simplest basis for messaging is the asynchro-nous one-way message, where a sender sends onemessage to a receiver and then forgets about it.An often-desired extension of this is reliability toensure that a message reaches the receiver and isprocessed only once when it arrives. This needs

Fig. 2. Message exchange patterns.

Fig. 3. The implemented messaging system structure.

J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654 4637

some scheme for acknowledgments and retransmis-sions, and is most efficient to provide at the messag-ing system level.

While any MEP could be implemented on top ofone-way messaging, some MEPs are useful enoughthat they should be supported directly by the mes-saging system. Of these, request-response is the sim-plest two-way pattern, and the most common one aswell. In this pattern, a client sends a single messageand receives a single response from the server. Thesystem should support both asynchronous and syn-chronous versions of this, as asynchronous mode ismore efficient in mobile computing, but synchro-nous mode is still commonly used. However, webelieve that for mobile computing, it would be bet-ter to rewrite applications to be based on asynchro-nous messaging rather than porting fixed-networksynchronous applications directly to mobile devices.

Other encountered message exchange patternsare subscribe-notify (also known as single-request-multiple-responses), in which the client sends asingle message and receives multiple responses atvarying times, and conversation, in which the recei-ver of a message may always send a new message.The former can be used for simple event notifica-tion, and the latter for two-party computation.These patterns are not as common as the simplerequest-response, but especially subscribe-notifyrequires the ability to persistently identify a messagesender, which is why we consider it a useful patternto support.

3.2. The messaging interface

Fig. 3 shows the way in which we have imple-mented the generic structure of Fig. 1. The pro-grammer of a messaging application sees two maincomponents, message and endpoint. The former ofthese represents a message containing generic datathat knows how to serialize and parse itself through

the XML API (XAS, described in Section 4) usingeither XML or the Xebu format (described in Sec-tion 5). The endpoint is then responsible for deliver-ing these messages to other devices, using thecommunication protocol described in Section 6.

Conceptually, an endpoint represents a target ofmessages. Endpoints are divided into two catego-ries: local endpoints are for applications to registertheir own receivers for incoming messages, andremote endpoints act as targets of messages to send.As an optimization, it is also possible to send a mes-sage to a local endpoint, which acts as a methodcall.

Internally, an endpoint consists of one or morenetwork addresses for the device on which the end-point is situated and a name to distinguish betweendifferent endpoints on the same device. This is sim-ilar to an HTTP URL where the http scheme andthe host-port pair correspond to one networkaddress and the path corresponds to the endpointname. The difference is that an endpoint can includeseveral network addresses, to permit selecting thenetwork best suited for communication dependingon the current conditions.

Any sending of a message to a remote endpointtriggers the opening of a messaging connection toa suitable network address of that endpoint. Thisconnection persists independently of the sent mes-sages, and any closing (e.g., to save resources) andreopening is transparent to the application.

The basic operations for sending messages are aone-way send when a response is not expected anda two-way callback-based asynchronous send. Thelatter registers a local endpoint for the response witha specified name at the sending time, and when theresponse arrives, the messaging system invokes onthe object registered to listen at that endpoint. Ontop of the callback interface, we also have anasynchronous interface using promises [22], and a

2 http://kxml.sourceforge.net/

4638 J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654

synchronous interface that acquires a promise andimmediately claims it.

The implementation of the request-response andconversation patterns is simple: a receiver of a mes-sage may always return a message that is treated asa response to the received message, and the messag-ing system will send any such response back. Fur-thermore, if a received message contains a sendername, the messaging system will construct a remoteendpoint from it that is passed to the application.Since the application can save the endpoint refer-ence, this can be used to implement the subscribe-notify pattern.

4. XML processing

There exists a variety of generic XML processingAPIs, each suitable for some needs. For the pur-poses of a messaging system, the API needs to sup-port efficient conversions of the system’s messagesfrom and to XML. Here, a message refers to a typ-ically small piece of structured data expressed in aform native to the programming language, or a col-lection of such pieces.

4.1. Requirements

XML processing APIs can roughly be dividedinto two classes: streaming ones like SAX [23] andin-memory ones like DOM [24]. When XML is usedonly as the message syntax, with an application-spe-cific structure for actual processing, an in-memorymodel would at least double the memory require-ments, since both the application data and theXML structure would need to be held in memory.Therefore a streaming API is more suitable forXML messaging.

Originally, our system used the SAX API, butthere emerged an additional requirement concerningthe mapping between the structure of applicationdata and the structure of XML. Namely, SAX is apush-style API where the parser is in control andpasses to the application SAX events representingsmall parts of the XML document. This requiresthe application to implement a state machine orthe like to keep track of the structure being pro-cessed. In contrast, in a pull-style API, such as Xml-Pull [25] or StAX [26], the application requests theevents one by one from the parser, and sufficientstate is kept by the program counter and local vari-ables. Therefore, a pull-style API is more natural forXML messaging.

However, handling of structured data is not suf-ficient for messaging needs. The primitive data inthe leaves of the structure is typed content such asintegers, dates, or floating-point numbers. InXML these are always represented as strings, butwhen an alternate serialization format is used, theremight be a more efficient way of representing suchdata. Therefore, the processing API should directlysupport inserting and acquiring these primitivetypes, and implement the necessary encoding anddecoding functions as specified in the data typedescription such as XML Schema datatypes [27].

Finally, one problem that we had when using theSAX API was that there is no standard way to seri-alize a sequence of SAX events. We have recentlytried to use a variety of SAX-based XML serializersand the amount of bugs we encountered shows thatXML serialization is not a trivial matter, in particu-lar when it comes to correct handling of XMLNamespaces [28]. Therefore we place a requirementon the API that it must include a mandatory serial-ization component, to at least mitigate the difficul-ties in XML serialization.

4.2. The XAS API

Of the available pull-style APIs, we selected Xml-Pull as the basis for our API work, mainly becausethe kXML2 implementation for mobile phonesimplements that API, and we had no wish to imple-ment XML processing ourselves. The XmlPull APIcontains APIs for both pull-style parsing and serial-ization, but there are no facilities for typed content.We extended the API with this feature, and imple-mented an XML processing library that we callXAS [10].

The XmlPull API is based on events, where a sin-gle event represents a small piece of XML content(start tag, attribute, end tag, etc.). The serializerAPI has a method for each possible type of event,with parameters being the information required tooutput the event properly. The parser API hasmethods to move to the next event and to accessthe type of the current event. After the type has beendetermined, other methods can be invoked to accessthe information in the event.

To patch the deficiency in typed content han-dling, we added a new type of event, containing atype identifier and a generic value, and added recog-

Fig. 4. XML fragment with XAS representation.

J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654 4639

nition of this new event type to kXML. In XAS,typed content can be either primitive, which inXML is serialized as text content, or complex, whichis serialized with structure of its own. In addition tothe primitive types defined in XML Schema [27],XAS supports user-defined typed content encoding,for both primitive and complex content. In the caseof primitive typed content, implementations forencoding and decoding need to be provided for allsupported serialization formats, whereas the encod-ing of complex content is described in terms ofXML structure and typed content events, makingit independent of the underlying format.

An XML document or a fragment of one is mod-eled as a sequence of XAS events. An example ofthis is provided in Fig. 4, which shows a simpleXML fragment containing two pieces of informa-tion about a person. We did not clutter the figurewith namespaces, but XAS is fully namespace-aware. The XAS representation shows four differentkinds of events: a start tag (SE), an attribute (A),3

an end tag (EE), and a typed content event (TC).While in XML messaging XML is used only as

the message syntax, other applications and middle-ware services may need to process XML as XML,and therefore require an in-memory model ofXML. In XAS the basic in-memory model is a listof events, which in our experience suffices for manyapplications. However, for applications requiringstructured XML processing, XAS also implementsa tree-like view, built on an as-needed basis, ontop of the event list representation.

5. XML serialization

As we noted in Section 2, energy consumption isthe most significant concern on mobile devices, and

3 In our later work we have noticed that XML applications aresimpler to write when attributes are part of the start tag eventinstead of separate events, but XmlPull treats them as separateevents, so XAS, at this point, does too.

the largest consumer of energy is often transmissionof data over a network. As XML is very verbose,this translates into a requirement to representXML in a more compact form. Furthermore, whilegeneric text compression usually works well forXML, there are two features of mobile messagingthat make it less desirable: first, messages may bequite small, and generic compression does not workthat well on small data, and second, adding a com-pression layer increases the amount of needed pro-cessing, which also consumes energy.

Because of these issues, the mobile communityhas long had an interest in alternate serializationformats, dubbed ‘‘binary XML’’, the oldest exampleof which is WAP Binary XML [29]. However, thisformat is specific to the XML used in WAP anddoes not support even such a basic feature asXML Namespaces. Because of this, another formatis required for general XML-based messaging.

5.1. Requirements

The requirements for an alternate serializationformat for XML have been extensively charted bythe XML Binary Characterization (XBC) WorkingGroup4 of the World Wide Web Consortium(W3C). In our context the main use cases that thisgroup identified [30] are called Web Services forSmall Devices and Multimedia XML Documentsfor Mobile Handsets, the latter more for its focuson mobile devices than for the XML it uses. Still,the requirements of these use cases have an exten-sive overlap with each other.

The obvious requirements that are at the top ofevery list are naturally compactness and processingefficiency. On mobile devices the latter requirementhas to include both time and memory spent on pro-cessing. Finally, it must be possible to implementthe format in a small amount of code, again dueto the limited available memory. However, theserequirements are in conflict with each other in thatoptimizing one too much will often worsen the oth-ers, so format design consists mostly of judging thetradeoffs between these properties.

To be usable in an XML-based system, the for-mat should also be a drop-in replacement forXML. This translates into two requirements. First,applications need to be provided with a standardXML processing API so that current XML-using

4 http://www.w3.org/XML/Binary/

4640 J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654

applications can be ported easily. This does not pre-clude the possibility of also providing a format-spe-cific, potentially more efficient, API. The otherrequirement is that the format needs to be able torepresent arbitrary XML. This may not affect alluse cases, but it is present in Web services, sincethere is no rigid structure in a Web service messageapart from some wrapper elements in SOAP.

It is well known that the more information onthe potential messages there is available, the morethey can be compressed. In the XML world, thisinformation usually takes the form of a schemain some schema language [31,32], which restrictsthe structure and content of XML documents. InWeb services, the SOAP message syntax [2] andWSDL definitions [33] provide restrictions on theallowed content as well. Because of this, the alter-nate format should also be able to use a schemato achieve improved compactness. However, inthe real world, not all messages will actually con-form to the claimed schema, so the format will alsoneed to be able to handle common deviations fromthe schema.

5.2. The basic Xebu format

The format we implemented, called Xebu [11], isbased on the sequence of events model of XASdescribed in Section 4.2. The basic format, whichsupports arbitrary XML, is a simple one, based onassigning one-byte tokens to the strings (name-spaces, names, values) appearing in XAS events.The token is assigned on a string’s first appearancein a sequence and later appearances are thenreplaced by that token.

Xebu also includes binary encoding of primitivetyped content represented in the XAS model. Inour experience, the largest benefits of this come inbinary data that needs to be represented in Base64in XML, and date values that have a complexXML representation. Floating-point values are alsoencoded and decoded much faster, but since mostmobile phones do not support floating point, thebenefits of this in real applications are likely toremain small.

The main interesting feature of the basic Xebuformat is that the token size is exactly one byte,i.e., at most 256 tokens can exist at any given time.This means that no matter how large the processeddocuments or message streams are, memory usage isbounded. This technique is further simplified byhaving the token appear explicitly when it is first

assigned to a string. There is thus no need to specifywhich token gets evicted when a new token needs tobe added to a full mapping, so the serializer can usewhichever eviction policy it wants. Furthermore, ifthe serializer and parser fall out of synch, the serial-izer can simply flush its mapping and everythingkeeps working without the parser needing to doanything except inform the serializer to flush itsmapping.

5.3. Xebu schema extensions

According to the requirements identified in Sec-tion 5.1, we also included extensions to Xebu forwhen a schema is available. The simplest extensionis to extract element and attribute names from theschema and pre-tokenize them. We have observedsize reductions of more than 50% with pre-tokeniza-tion and usually, even in the worst case, messagesize will decrease by at least a third.

The special encoding of typed content mentionedabove can also be used as a schema-aware tech-nique. In this way, the type information for theXAS model is extracted from the schema. At themoment, however, our implementation does notsupport type information extraction on mobiledevices, and on the fixed network side it is only sup-ported in our DOM compatibility API. These omis-sions are due to the lacking support for typeinformation in standard XML processing APIs, aswell as their lack of need when everything goesthrough our messaging system that can provide typeinformation directly when serializing.

The final schema extension, called Codec Omis-sion Automata (COA), is also the most complexone. We pre-process the schema into two finite auto-mata, one for the serializer side and another for theparser side. These automata work at the XAS eventsequence level, i.e., their inputs and outputs areboth XAS event sequences. The basic concept is thatthe serializer-side automaton will omit certainevents from the serialized event sequence. Theseomitted events are such that their presence can bedetermined when the schema is known. Thus theparser-side automaton is able to reinsert them intoits output when it is processing the incomingdocument.

We recall the example XML fragment fromFig. 4. In Fig. 5 we have included a schema for it(shown in RELAX NG compact syntax [34]) andshow how the example event sequence is processedon the right side. In this case the schema is com-

Fig. 5. Event omission in Xebu.

J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654 4641

pletely linear, so the event omission automaton willomit all structure from the fragment, leaving onlythe typed content. The parser automaton, on seeingthe typed content events, knows to insert the miss-ing structure back into the event sequence.

This technique achieves its best performancewhen the schema is mostly linear, i.e., consists of asequence of elements. In such a case the serializerautomaton is able to omit practically all start andend tags, leaving only the content. However, if theorder of elements is mostly free, there is little thatthe automata can do, so there is no improvementwith this technique in those cases.

The main feature of this approach that is missingin most other schema-based approaches is that itcan handle certain deviations. Namely, when anunexpected event is encountered, both automatawill pass it through as is without changing theirinternal state. This permits, e.g., adding elementsand attributes in most places without affecting theachieved compactness of other parts. Deletions arealso possible, but if an expected element is deleted,it may happen that the serializer side automaton willsimply be stuck, and therefore make no event omis-sions for the rest of the document. Furthermore, it isnot feasible to detect this condition, since theautomaton could simply be processing unexpect-edly-added events, so detection is possible only atthe end of a document by checking whether theparsing automaton reached its end state.

6. The protocol layer

As the messaging system is intended to be a verygeneral one, its protocol will also need to support avariety of communication patterns. For implement-ing the actual communication we need to take intoaccount the peculiarities of the different wirelessconnection types. Finally, even the facilities avail-able for programming on the device as well as the

characteristics of the network access may need tobe taken into account.

6.1. Requirements

HTTP, the main protocol used today with XMLmessaging, is strictly a client–server protocol andnot very well suited for general messaging. The mes-saging protocol of the system needs to follow moreof a peer-to-peer model rather than a client–serverone. In particular, if the protocol is connection-ori-ented, there should be no client and server rolesafter opening the connection, but either side mustbe able to send a message at any time.

For reliable communication on the fixed Internet,TCP usually provides sufficient reliability. However,when one party is mobile, this can lead to networkaddress changes that break all existing TCP connec-tions. Such a connection break may cause messagessent over the old connection to be lost. Thereforeeither the network must provide unchanging net-work addresses, e.g., with Mobile IP [35], the proto-col needs to implement this reliability itself, or itsmodel provided to the messaging system will bebased on unreliable messaging.

In an application protocol, it is often useful forapplications to be able to specify arbitrary metadatato be able to implement additional functionality. Aparticular case of this is HTTP headers, but theirproblem is the size of the header part. In Webbrowsers the size of the header part can easily reachseveral kilobytes, but even with HTTP libraries onekilobyte is not an uncommon size. With the headerbeing this large, there is little reason to compress thedata in the message beyond a certain point, so arequirement on the protocol is to provide a compactgeneric metadata mechanism.

Mobile devices also have a variety of networkingtechnologies available to them. Current mobilephones support phone networks like GPRS orUMTS as well as Bluetooth, and high-end models

Fig. 6. Example of the HTTP Transfer mapping.

4642 J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654

also support WLAN. The messaging protocolshould therefore be independent of any particularnetworking technology. Furthermore, when a devicemoves, the best networking technology to use willchange. This information is also useful to applica-tions, e.g., so that they can adapt their communica-tion pattern to the current conditions, so theprotocol layer needs to provide network characteris-tics to higher layers.

6.2. The transfer layer

The requirement to support a variety of underly-ing networking technologies was a driving force inour overall design of the protocol layer. This isbecause in the programming environment these dif-ferent technologies are accessed through differentAPIs, requiring an implementation of pluggableprotocol modules, each used when the correspond-ing network is being used. To ease implementation,we selected a two-layer approach where the lower,Transfer, layer provides a uniform API with a verysimple semantics and is implemented separately foreach different networking API.

The transfer layer provides an abstraction of apoint-to-point connection to its user, the top layerof the protocol. The connection is further dividedinto pipes to provide a uniform multiplexingcapability, which may avoid the need to open newconnections when new communication targets areused, and hence avoid a network round trip. Allmessages are sent on the pipes. The number ofpipes per connection is not limited, and the Transferlayer usually does not need to keep any pipe-specificstate.

As the abstract model for messages we adoptedthe one also used by HTTP: a message consists ofa header and a body. The header is a collection ofname-value pairs and the body is a piece of opaquebinary data. We emphasize that this is an abstractmodel: a Transfer layer implementation does notneed to use the same message syntax as HTTP,but can use whatever mapping seems natural forthe underlying protocol layer.

The messaging channel provided by the pipeabstraction is full-duplex, meaning that either sidecan send a message at any time, one-way, meaningthat there are no response or acknowledgment mes-sages, and unreliable, meaning that messages may bedropped, but we do assume that messages are notcorrupted. Furthermore, messages may arrive outof order at the receiver. Since the Transfer layer

needs to be implemented for each different network-ing API, we intentionally kept the guarantees it pro-vides as minimal as possible.

In total, we have three different implementationsof the Transfer layer, for each of TCP, Bluetooth,and HTTP. Of these, the TCP and HTTP mappingscan be run on top of any network that provides IP,such as WLAN or GPRS. The TCP implementationis the simplest one, consisting of a core for genericstream-based protocols and a wrapper that handlesconnection establishment. The headers are encodedwith binary identifiers for names and binary num-bers used in values where applicable.

For Bluetooth, we selected the BluetoothRFCOMM protocol that provides a stream inter-face to applications, and use the same core as theTCP mapping. In the Bluetooth case the additionalcode needed was much more than in the TCP case,since with Bluetooth connection establishment isoften accomplished through the Bluetooth servicediscovery process. This discovery process allowsthe application not to know any addresses of itspeers, which gives Bluetooth more dynamism thanTCP.

Since HTTP is the only protocol guaranteed tobe available to Java programs on mobile phones,we also needed to provide a Transfer mapping forit. Furthermore, operators may still be reluctant tolet non-HTTP protocols through their networks,even though the phone would support them. Wedo not consider HTTP a good base for building auseful messaging system, but due to real-world con-siderations we have to live with its limitations. Toencode the headers, we use HTTP’s regular headers,mapping the header names to compact identifiers,but keeping all values as strings.

The Transfer mapping is implemented by run-ning two threads on the client side, the token thread

and the data thread, and is illustrated in Fig. 6.When the Transfer connection is opened, the tokenthread sends an HTTP GET request, a token, to theserver. The server does not respond to this requestimmediately, so when the server needs to send amessage, this token is waiting for a response, and

Fig. 7. Measurement of round-trip times.

J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654 4643

the server sends its message as the HTTP response.On the other hand, when the client has a message tosend, it is sent by the data thread as an HTTP POSTrequest. The server’s response in this case is oftenempty, denoted as a token in the figure (if the tim-ings on the server side happen to coincide suitably,the response to the data thread can also contain amessage).

6.3. Mobility modules

The top layer of the protocol, called AMME,implements most of the requirements. Theserequirements turned out to be largely independentof each other, so we implemented a set of modules,each of which defines a group of header namesand their processing. The module components inthe implementation add and process these headersin messages. However, there is no general moduleplug-in interface, since the functionality providedby the modules requires that they be closely inte-grated into the communication flow.

Reliability in the protocol is provided by thesequence number module. This defines three headers,for including sequence numbers, for acknowledgingconsecutive sequence numbers, and for selectiveacknowledgment. This last one is important inmobile computing, since at times of mobility thereis often a burst of lost messages, but otherwise theunderlying protocol may provide sufficient reliabil-ity. We also use sequence numbers to ensure ordereddelivery of messages to applications, which is a use-ful property for many distributed applications.

The Transfer layer is conceptually connection-oriented, and the persistent connections moduleallows connections to persist across client mobility.The server side persistent connections moduleincludes a unique identifier for the connection toits initial message. If a connection is terminated,e.g., due to client mobility or a desire to conserveresources, the client side persistent connectionsmodule will automatically include the server-pro-vided identifier to continue the same logical connec-tion. This permits the use of connection-specificstate independently of what is happening at theactual network level (in our system, this stateincludes the Xebu tokenization values that persistbetween messages sent over the same connection).

We also provide a message bundling module toaddress the requirement of small protocol metadata.Our protocol headers are already smaller than withstandard HTTP, but this can reduce their impact

even more. Message bundling permits inserting sev-eral application layer messages into a single Trans-fer layer message. A header in such a bundledmessage identifies the boundaries of the messages,permitting the receiver to unbundle them and passthem to the application one by one.

Finally, to partially address the requirement ofconnection monitoring, we measure round-triptimes. This provides a gross estimate of the qualityof the network, permitting the application to adaptits behavior somewhat. The round-trip time mea-surement, illustrated in Fig. 7, requires that theclocks of both sides advance at the same rate, butthe clocks do not need to be synchronized in anymanner. Furthermore, the measurement is basedon piggybacking information on one-way messagesand does not require immediate responses fromthe other side. These features make it similar to Pin-Point [36], except that our system still requires thesame advancing rate for the clocks.

To measure round-trip times, peer A will includeits own timestamp tA in a message. Then, when thereceiving peer B sends a message, it will include anestimate t0A of the other end’s time with the message.This estimate is computed by taking the timestampcontained in the last timestamped message and add-ing to it the time that has passed since then. Thuswhen the measuring end receives the estimate, itknows that the estimate is wrong by exactly theround-trip time (the time interval marked with rtt

in Fig. 7).One issue with this method is that the sent mes-

sage of the round-trip time is not based on the cur-rent connection, but on the one that was used tosend the last timestamp. Therefore a side measuringround-trip times should send its own timestampperiodically to make sure that both parts of themeasured round-trip time reflect the currentconditions.

4644 J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654

7. Experiments

To test our implementation and to verify that itsatisfies the requirements we identified, we imple-mented a collection of experiments that are intendedto mirror realistic use cases of the system. In ourexperience, data collected from running on regularcomputers is not indicative of performance onmobile phones, so we ran all of our measurementson real phones, using real networks.

7.1. Experimental setup

The devices we used in our experiments were twoNokia 9500 communicators and one desktop com-puter named ‘‘brattain’’ with a 1500 MHz AMDAthlon processor, 512 MB of memory, and runningDebian GNU/Linux 3.1r3 with Sun’s Java 2 Run-time Environment 1.5.0. We used the communica-tors, since they support all of Bluetooth, GPRS,and WLAN, but they are not significantly morepowerful than other modern phones. While thecommunicator also supports the more featurefulFoundation Profile of Java [37], our messaging sys-tem is usable on MIDP devices, so we also imple-mented the measurement applications using onlyMIDP features.

The communicator does not support UMTS, andwe did not have available a mobile phone thatwould support both UMTS and WLAN. Since thelatency and many other characteristics of UMTSare similar to those of GPRS, we believe that a com-parison between GPRS and WLAN is more illumi-nating than one between GPRS and UMTS, eventhough UMTS bandwidth is higher than that ofGPRS.

We used a number of networks and protocols inour experiments; these combinations are givennames in Table 1. The devices used in the experi-ments are given in the form client! server. TheInfra WLAN is an infrastructure-based WLANconnection to the Internet while the Ad-hoc WLAN

Table 1The connections used for the experiments

Name Devices Network Protocol

HTTP-G 9500! brattain GPRS HTTPHTTP-W 9500! brattain Infra WLAN HTTPTCP-G 9500! brattain GPRS TCPTCP-W 9500! 9500 Ad-hoc WLAN TCPBT 9500! 9500 Bluetooth BT

is an ad-hoc WLAN network containing just thetwo communicators. We selected the connectionsto get useful comparisons between protocols: thetwo HTTP protocols illustrate the differencebetween WLAN and GPRS for Internet access,the two GPRS connections illustrate the differencebetween HTTP and TCP, and the two connectionswith the communicator as the server illustrate thedifference between two different ad-hoc networkingtechnologies.

For our main measurements we implemented asimple messaging application capable of synchro-nous and asynchronous request-response communi-cation. The messages themselves were extremelysimple, consisting only of a single integer valueinside a SOAP message with appropriate headers.We performed a single synchronous request-response interaction, as well as a sequence of 50interactions as quickly as possible both synchro-nously and asynchronously. All of our measure-ments were made on the client side of theapplication, using 20 replications, and measure-ments are given with a 95% confidence interval.

7.2. Component sizes

As one requirement of a messaging system is itssmall size, we began by measuring the memory foot-print of the different components of the system.Since Java linking is based on names, use of descrip-tive names increases the size of the compiled appli-cation and decreases runtime efficiency due to thelonger name lookup times. Because of this, a realdeployment process for mobile phones alwaysincludes an obfuscation phase where all the class,method, and variable names are automaticallyshortened to minimum length. So, to get realisticnumbers for code size, we obfuscated our code withthe popular Proguard,5 which also eliminates classesand methods that are not used by the mainapplication.

The size of each component is shown in Table 2.Alongside the size of the Xebu format and its XASAPI we also show the size of the kXML implemen-tation for XML serialization and parsing that iscommonly used on mobile devices. Similarly, weshow the size of the SOAP implementation kSOAP6

with the generic message service code, marked MTS,

5 http://proguard.sourceforge.net/6 http://ksoap2.sourceforge.net/

Table 2Component sizes

Component kXML Xebu XASSize (B) 30,959 26,837 28,686

kSOAP MTS AMME23,473 11,841 12,594

Stream BT TCP HTTP8750 8338 3366 11,699

System MTS + TCP MTS + All kSOAPSize (B) 84,549 104,586 54,432 Fig. 8. Connection establishment times.

J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654 4645

and the common AMME protocol code. The othertable shows the Transfer layer mapping implemen-tations. Here the Stream component is code that isused by both the BT and TCP mappings; theseimplementations also contain some protocol-spe-cific code. We also show the total sizes for both sys-tems, MTS with AMME, Xebu, and XAS, andkSOAP with kXML. For the MTS we measuredboth the case where only TCP is included and thecase where all protocols are included.

We note that our MTS implementation is notmuch larger than the kSOAP-kXML combinationthat is commonly used for SOAP messaging onmobile devices. Furthermore, our messaging servicesupports different message exchange patternswhereas kSOAP is limited to request-response. Wenote that the XAS API in our system appears tobe somewhat large. A significant amount of this sizeis due to typed content handling, and in particular,almost 6 kilobytes are consumed by encoding anddecoding of the basic XML Schema types. ThisXML type handling would not be needed if we com-piled the MTS without any XML support, so thispart of XAS is not included in the total sizemeasurements.

7.3. Connection establishment

Connection establishment on a mobile device canbe divided into two phases. On an IP-based net-work, the first part is establishing link-layer connec-tivity to WLAN or GPRS, and the second part isestablishing the connection at the transport orapplication layer. On Bluetooth there are similarlytwo parts. The first part consists of discovering allBluetooth devices that are available in the neighbor-hood. After the devices have been discovered, a ser-vice discovery is performed on each to locate thedesired service.

Fig. 8 shows connection establishment times,split into the two parts, for the GPRS-based connec-tions and Bluetooth. In the case of WLAN, link-layer connectivity times are similar to GPRS, andestablishment of the higher layer connection takesnegligible time, so we omitted it from the figure.We notice that HTTP takes slightly over twice theamount of time as TCP. This is to be expected, sincean HTTP request-response requires two network-level round trips.

In the Bluetooth case the time spent in device dis-covery remained constant with no noticeable devia-tion from one measurement to the next, indicatingthat there is probably a timeout somewhere. Onething to note is that these figures were achievedunder optimal conditions where the two communi-cators used were the only Bluetooth devices inrange. In noisier conditions we observed that thecomplete discovery phase can often last even oneminute.

7.4. Throughput

We continued our experiments by measuring thethroughput of the various connections, with boththe XML and Xebu formats. The client of thisapplication continuously sent requests asynchro-nously to the server, which responded to eachrequest. The client then measured the inter-arrivaltime of the responses. We eliminated a number ofinitial responses from consideration until the appli-cation achieved a steady state; the precise numberwas determined by inspection in each case. Theinter-arrival times as well as the number of messagesprocessed in one second are shown in Table 3.

From these numbers we note that on the GPRSnetwork with its high latency Xebu achieves a signif-icantly higher throughput than XML, and at thisconfidence level the difference between the XMLand Xebu times is independent of the protocol. This

Table 3Throughput

Connection Xebu XML

Time (ms) Thru (1/s) Time (ms) Thru (1/s)

HTTP-G 214.1 ± 8.6 4.7 278.7 ± 9.9 3.6HTTP-W 82.0 ± 3.0 12.2 83.7 ± 3.7 11.9TCP-G 51.3 ± 1.9 19.5 145.6 ± 7.9 6.9TCP-W 38.3 ± 1.0 26.1 45.4 ± 1.2 22.0BT 55.3 ± 1.7 18.1 –

4646 J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654

translates into an especially pronounced effect inratio for the TCP case where there is no additionalconnection opening overhead. Based on the resultsof the WLAN cases where there is little or noimprovement we can conclude that most of Xebu’sadvantage in the GPRS case comes from the smallersize of the messages, and not from gains in process-ing efficiency.

In the Bluetooth case we were not able to mea-sure throughput for XML messages. Evidently thethroughput-measuring application was trying tosend data too quickly, since the virtual machinecrashed after only a few messages had been pro-cessed. Bluetooth performance appears to be quitepoor, as even TCP over GPRS is better than it,but we believe this to be an artifact of the problemsin the phone’s Bluetooth implementation, and wesay more about that in Section 8.

7.5. Transmitted data

The amounts of data transmitted per interactionin the 50-interaction case are shown in Table 4 forall connections, formats, and invocation styles,

Table 4Amounts of transmitted data in bytes

Connection Format Style Pure TCP

HTTP-G XML Asynch 145Xebu Asynch 112

Synch 882

HTTP-W XML Asynch 155Xebu Asynch 70

Synch 979

TCP-G XML Asynch 41Xebu Asynch 5

Synch 76

TCP-W XML Asynch 26Xebu Asynch 4

Synch 1

averaged for a single invocation. The amounts aredivided into three components: Pure TCP refers toTCP segments that do not carry any data, Messageis the size of the actual SOAP message, and Headersis the rest of the TCP segments carrying SOAP data.

We can see from this table that reducing messagesize ripples through to all layers of the communica-tion, since with smaller messages there are fewerTCP segments to send. Since the figures in the tableare per-application-message averages, this translatesinto reduction in the TCP and Headers columns aswell. We can also see clearly the benefit of asynchro-nous communication that allows the message bun-dling module to provide benefits, since in thesynchronous case the non-message part takes morethan 70% of the space for Xebu, making the benefitsof reducing XML size very slight indeed.

To highlight an interesting point, the synchro-nous case with TCP-W only has 1 byte per messageof pure TCP traffic. The low latency and speedyprocessing combine in this case to produce a situa-tion where practically no pure TCP segments areexchanged during communication, but all acknowl-edgements manage to piggyback on applicationdata.

7.6. Memory consumption

A visible lack in many presented measurements isthat they only consider the time it takes and not thememory that gets consumed. On mobile deviceswith low available memory both are important con-siderations, especially when we note that memoryallocation and deallocation will also increase thetime that is taken. Table 5 shows the results,

Headers Message Total

181 963 1289142 124 378905 124 1911

184 963 130292 124 286

886 124 1989

135 963 113939 124 168

348 124 548

101 963 109038 124 166

293 124 418

Table 5Memory usage

Connection Xebu (kB) XML (kB)

HTTP-G 339.3 ± 36.7 370.5 ± 26.8HTTP-W 338.1 ± 27.4 378.0 ± 17.6TCP-G 271.7 ± 23.6 294.4 ± 25.0TCP-W 240.8 ± 20.1 307.8 ± 25.7BT 261.6 ± 20.8 –

J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654 4647

averaged for one synchronous invocation. For thesame reasons as in the throughput measurementswe did not manage to get useful measurements forBluetooth with XML.

Based on these measurements we cannot withconfidence say that memory consumption withXebu is lower than with XML, but the results dostrongly point in that direction. Additional experi-ments to shorten the confidence interval might con-firm this guess. What we can note from these resultsis that the type of the underlying network, GPRS orWLAN, makes no difference, and that using HTTPconsumes more memory than using either of thestream-based protocols. This latter is at least par-tially explainable by our use of HTTP headers forprotocol metadata instead of streaming it directlyinto a binary format as we do for the other twomappings.

Fig. 10. Comparison to synchronous invocations on GPRS.

7.7. Single request

We begin considering the timings by looking atthe single-request-response case in Fig. 9. Thisshows the time taken for all the connections andfor both formats. We did not measure with XMLin the WLAN or BT cases, since the lower latencythere makes the numbers practically equal to thoseof Xebu. We note that Xebu is significantly better

Fig. 9. Times for one request-response.

than XML, which comes from the reduction ofthe number of TCP round trips due to the smallersizes of the messages. It would also seem as thoughTCP is better than HTTP, but we cannot say thiswith confidence (recall that in the WLAN case theunderlying connections of the two protocols arenot the same).

7.8. Multiple requests

We present the timings from the 50-interactioncases by looking at one or two variables at a time.First, Fig. 10 shows the total times with Xebu forboth synchronous and asynchronous invocationson the two GPRS-based connections. In this high-latency case asynchronous messaging benefits vastlyby the ability to send new messages even if responsesto older messages have not yet arrived.

Next, we look at XML and Xebu over theGPRS- and WLAN-based connections in Fig. 11.These are total times for the full 50 interactions withasynchronous messaging. We note that indepen-dently of the underlying network and protocol,

Fig. 11. Comparison to XML.

Fig. 12. Comparison between ad-hoc networks.

4648 J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654

Xebu achieves a clear improvement over XML.With GPRS much of this improvement comes fromthe smaller message size of Xebu which reduces thenumber of round trips required, but with WLANthe latency is so low that the differences are moredue to the higher efficiency of Xebu processing.

Finally, we look at the two ad-hoc networkingtechnologies, WLAN and Bluetooth, using Xebu,in Fig. 12. Here, with the lower latency, we beginto see how badly suited HTTP is to two-way mes-saging, illustrated by the long time it takes to com-plete the synchronous experiment. The reason forBluetooth’s abysmal performance is due to the pre-viously-mentioned problems with the phone’s Blue-tooth stack.

Since often a lot of interest is expended on the pre-cise times of XML processing, we also took separatemeasurements of Xebu and XML processing times.These are presented in Fig. 13, for both serializationand parsing. We note that Xebu is clearly faster (thisis consistent with our previous measurements [11]that indicate Xebu improving over kXML whenmoving to higher-end devices). Furthermore, thistime spent processing is a significant percentage of

Fig. 13. Message serialization and parsing times.

the total time in the asynchronous communicationcases over the low-latency connections.

7.9. Round-trip times

We also verified our round-trip time measure-ment accuracy. This was feasible to do with theHTTP Transfer mapping, since that mapping hasa natural round trip for every HTTP POST request(i.e., the ones where the client is sending a message).We measured over the GPRS connection and got around-trip time at the HTTP level of 1.86 s while thetime measured by AMME’s RTT module was1.84 s. Since the RTT module of AMME discountssome of the local processing (i.e., between the read-ing of the incoming timestamp and the writing ofthe outgoing timestamp), it was to be expected thatthe AMME figure would be slightly lower.

However, these round-trip times were measuredin the synchronous invocation case. We noticed thatin the asynchronous case the measured round-triptimes fluctuated widely and were much higher,climbing easily up to 6 or 7 s. This is to be expected,since the times are measured at the application leveland in the asynchronous messaging case there ismuch more network activity going on, which takesprocessing time away from the application. In asense this is realistic, as the measured time is stillthe time that it would take for a response to comeback, but high network latency is a different prob-lem from high load, so we would need an additionalmodule to keep track of the number of messagesbeing received and to determine from this informa-tion the true network latency.

8. Practical issues

When implementing software for real devices andrunning it under real conditions, there are alwaysissues that cannot be anticipated during develop-ment. Programming networked applications onmobile devices is especially rife with such problems,since networking capabilities of these devices arestill underused, and therefore do not appear to besufficiently tested.

The Bluetooth protocol stack proved to be espe-cially problematic. First of all, despite the JavaBluetooth discovery API being asynchronous andbased on callbacks, the phone only allowed one out-standing discovery invocation at a time, necessitat-ing an unnatural serialization of the discoveryinvocations. In addition, when placed under heavy

J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654 4649

communication load with Bluetooth, the virtualmachine of the phone crashed consistently, makingit impossible to obtain XML measurements forTable 3.

The reason for the poor results of Bluetoothshown in Fig. 12 was the inability of the Bluetoothstack to correctly handle a streaming connection.Namely, reading from the input stream frequentlyreturned an end-of-file indication even though therewas data left. This we managed to work around byretrying a failed read after a sleep period, but wehad to set this sleep period to several hundreds ofmilliseconds to get sufficient reliability. We are notcertain why this happened, but suspect it to be someform of interaction between the input and outputsides of the connection.

Finally, we noted that the HTTP connections forthe token requests in the HTTP Transfer mappingwere abruptly terminated after a relatively shorttime. This is caused by the NAT device of the GPRSoperator resetting unused TCP connections, whichis common practice among operators. We workedaround this by having the server timeout and sendback an empty response. The client does not processthis, but it will recreate the token request, thus reset-ting the operator timeout.

9. Related work

We can split consideration of the related workinto a few different areas. The oldest one has lookedat the performance of regular communication pro-tocols in wireless networks. Further on, we can lookat extending middleware, either object- or message-oriented, to support mobile nodes and wirelessconnections. Finally, work on improving XMLperformance is of interest.

9.1. Wireless communication

It has long been known that TCP congestion con-trol causes problems when TCP is used on wirelesslinks [38]. A basic assumption in TCP is that alllosses are due to congestion, so packet loss will trig-ger a reduction in the amount of sent data. How-ever, on wireless networks, losses are more oftendue to transmission errors, so TCP’s congestioncontrol proves to be actually harmful instead ofhelpful.

Many proposals to improve TCP’s performanceover wireless links have been made [39], many ofthem based on ‘‘splitting’’ TCP connections in two

with a proxy between the wireless and fixed net-works [40]. In particular, the WAP architecture[41] is heavily based on this kind of approach atall levels of the network stack. However, there areconcerns that a proxy-based approach could violateTCP’s end-to-end semantics, potentially leading todecreased robustness.

Going up in the stack, the poor performance ofWeb services in wireless networks has been notedbefore [42]. As is to be expected, the bottleneckwhen running over GSM is the network and theprocessing time is a minor part of the total. How-ever, the opposite turns out to be the case overWLAN, especially for complex messages. There-fore, improvements are welcome in both networkuse as well as in message processing.

PURE [43] is a UDP-based protocol binding forSOAP that relies on SOAP headers for addressing[44] and reliability [45], allowing it to keep its ownheader very simple. PURE fragments SOAP mes-sages into multiple UDP datagrams and includesretransmission functionality to counter UDP’s unre-liability. However, PURE does not include flowcontrol, and since the mobile computing environ-ment may have a large disparity between peers’capabilities, flow control functionality in the proto-col is a necessity. Finally, PURE is a SOAP-levelapproach, with no consideration of the differingtypes of networks between SOAP intermediaries,so its reliability is purely end-to-end and it doesnot have functionality for hop-by-hop reliability.

9.2. Mobile middleware

It is not sufficient to solve the problems of thewireless network only at the transport layer, sincehigher layers can always degrade performance byusing the underlying protocols in a suboptimal man-ner, as evidenced by the original Java RMI imple-mentation [46]. Furthermore, mobility issues cannot be solved only at the networking layer, whichis the view often espoused by Mobile IP [35] pro-moters, since applications in the future are expectedto adapt to their environment, so they, including themiddleware layer, need to be aware of mobility.

CORBA [47] is a well-known object-orientedmiddleware platform that also has a standardizedextension for wireless access and mobility [48],based on the proxy concept. A notable feature ofthis system is the use of CORBA notifications toinform interested parties of a terminal’s movements.Publish/subscribe middleware has also been

4650 J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654

extended with mobility features, both generically[49] as well as with a specific mobility protocol[50] that is much more efficient.

Both of these approaches take an existing fixed-network system and extend it with mobility features.In contrast, the one.world system [51] is a compre-hensive middleware platform for pervasive com-puting [52] that is firmly rooted in the mobilecomputing world. One.world rejects XML as toocomplex and instead uses nested tuples to providea hierarchical data model. Their messaging system,similar in design to ours, uses Java serializationfor its message syntax. This is not available onMIDP platforms, and in our experience Java serial-ization is often less efficient to process than a well-designed XML format.

Unlike most other systems, the XMIDDLE plat-form [53] is explicitly designed around the use ofXML. However, it is not a conventional messagingsystem, but is rather based on manipulating sharedXML documents through the use of XML address-ing technologies like XPath [54]. It is thereforesomewhat similar to the file synchronizer in ourFuego middleware [8], with the difference that inXMIDDLE changes are automatically propagatedwhen they are made.

9.3. XML performance

Improvements in XML processing performancecould be used to mitigate XML processing costs,possibly by making compressed XML sufficientlyefficient to avoid a binary format. A common wayto improve XML performance comes from notingthat information from a schema, either explicit orimplicit, can be used to streamline the processingof conforming documents.

An available explicit schema can be pre-compiledto either code for a high-performance parser [55] orinto parsing tables of a generic parser [56]. Both ofthese approaches, however, suffer from the fact thateach different schema requires it first to be transmit-ted, then compiled, and finally used in memory.This increases the amount of transmitted data, aswell as used time and memory, especially if thereare many schemas, though similar considerationsapply to our COA approach in Xebu.

At the limit, a schema can be pre-compiled intoan integrated parser that also does conversion intoapplication data [57]. Such an approach producesa very high-performance parser due to minimizingthe number of times each character in an XML doc-

ument is touched. With these techniques, even ageneric SAX-compatible parser that used a fullypermissive schema was able to outperform modernhigh-performance parsers.

However, an explicit schema is not always avail-able. In spite of this, messages to a specific targetoften resemble each other to some degree, implicitlyfollowing a schema. This leads to an approach [58]where the parser remembers the sequences of bytesthat it has read and which results it produced fromthose bytes. When the same bytes are later encoun-tered in the same context, the parser can simplyreplay the previous results. However, if there aremany differences between documents, this approachleads to quite large memory consumption.

None of these techniques have been implementedfor mobile devices, and some of them require toomuch memory to be usable. For embedded andmobile devices the gSOAP toolkit for C and C++can be used to generate very efficient service-specificcode [59]. This combines data binding with lower-layer XML processing similarly to XML Screamer[57], achieving efficient processing. General XMLis handled by converting it to DOM, which we con-sider suboptimal in XML messaging.

9.4. XML binary serialization

As the method of reducing the size of XML mes-sages we chose binary XML instead of more tradi-tional compression methods. One reason is that weexpect many messages to be quite small and in suchcases generic compression like gzip [60] does notprovide very much reduction in size. In addition,while XML-specific compression methods [61,62]perform very well in terms of compression ratio,we considered their processing time and memoryrequirements to be prohibitive on mobile devices.

When considering general-purpose formats app-licable to any XML, the tokenization approach thatour format Xebu uses has been a popular one[63,64]. Conceptually there is little differencebetween such formats, and the amount of compres-sion achieved is very similar for all. The use of abounded space for tokens to allow bounded mem-ory consumption is, to our knowledge, unique toXebu. This benefit is rarely seen in performancemeasurements, since measuring either processorfootprint or dynamic memory consumption appearsto be rare in performance measurements.

In schema-aware formats there is more variety. Aformat standardized by ITU-T is based on mapping

Table 6Messaging system requirements

Component Requirements

System API Asynchronous one-way and two-way messaging, Support various message exchange patterns, Reliable messagingXML API Streaming processing, Encoding and decoding of structured and typed data, Mandatory output interfaceXML format Compact, Efficient to process, Compatible with an XML API, Support for arbitrary XML, Potential to leverage schema

information, Ability to handle deviations from a schemaProtocol Peer-to-peer model, Ability to send at arbitrary times, Compact metadata

J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654 4651

XML Schemas to ASN.1 schemas and then usingASN.1 as the XML format [65]. Another recentapproach [66] uses automata like our technique,but instead of producing events, these automatadirectly produce the bits that comprise the encodedform. Neither of these techniques, however, canhandle any deviations from the schema.

To our knowledge, there is no other schema-aware technique that works purely at the datamodel level, which gives our schema automata adegree of independence from the underlying format.This independence is not complete, since the formatneeds to be able to serialize arbitrary sequences ofXAS events, which, e.g., XML is not able to do.Furthermore, the separation of different schema-aware techniques into independent componentsseems to be rarely noted, though as an idea it seemsobvious.

7 http://www.w3.org/XML/EXI/

10. Conclusions

We summarize the requirements that we identi-fied for the system in Table 6. We can consider theserequirements arising from a few different causes thatwe have brought up. Considerations of networklatency require the system to be based on asynchro-nous communication to avoid blocking. Networkbandwidth, combined with battery life, leads torequiring compact messages and message-relatedmetadata. Slow processors and low memory necessi-tate fast processing and small memory use at all lev-els. Using XML as the message syntax requires theability to support arbitrary XML, or if a schema isused to compress, potentially schema-invalid XML.Finally, there are general considerations that wouldapply to any messaging system.

We have demonstrated that it is possible to fulfillthese requirements better than in commonly-usedsystems. Furthermore, in our system the compo-nents are independent of each other, separated bygeneric APIs, leading to the possibility of only usingsome of them if others are not needed. For instance,

as the XBC use cases show [30], there is widespreadinterest in efficient XML representation even out-side the context of messaging.

Regarding the question of whether an alternateserialization format for XML is needed, we cannotice two things from our measurements. First, itis imperative to decrease the sizes of messages, sincewireless communication is very costly, both in termsof power and (currently) money. Second, in somescenarios XML processing can be the bottleneckof the application. This means that XML needs tobe represented in a more compact format that doesnot have additional processing overhead (and pref-erably one that can be processed faster). Thereforeit seems that a compression layer on top of regularXML is not sufficient.

Latency considerations are definitely the majorissue in current mobile phone networks, and theredoes not appear to be any major improvement insight. We noted that not only does the use of asynchronous interface lead to slower applicationperformance, but it also leads to more data beingtransmitted over the network. Considering thatdata transmission is the major strain on the batteryon mobile devices, this provides a further incen-tive to use asynchronous interfaces for frequentcommunication.

Real-world deployment of solutions is always thelast hurdle to clear. We noted several practical prob-lems that come up when programs are run on realdevices using real networks and indicated how weworked around these issues. However, actualdeployment will also require acceptance of a mes-sage syntax and a protocol. On the syntax side, weare hopeful that the Efficient XML Interchangeeffort at the W3C7 can produce a common pointof agreement, and we are participating in this pro-cess based on our experiences in developing a binaryformat.

4652 J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654

On the protocol side we note that a protocol isunlikely to succeed unless it has a popular applica-tion driving the success. An example of such successseems to be XMPP [67] used for instant messaging.A less successful example is BEEP [68], intended tobe a general-purpose application-layer protocol,which seems to have stagnated after an initial flurryof interest.

In conclusion, the future of XML usage in themobile world does seem to be promising, as longas systems designed for fixed networks are notadopted as such. Based on our impressions weexpect the mobile world to at least adopt a stan-dardized approach to binary serialization of XML.Protocol changes on the application level we see asless likely, as it seems improvements there wouldrequire more effort to achieve in reality.

References

[1] World Wide Web Consortium, Cambridge, Massachusetts,USA, Extensible Markup Language (XML) 1.0, 4th ed.,W3C Recommendation, August 2006. <http://www.w3.org/TR/2004/REC-xml-20060816/>.

[2] World Wide Web Consortium, Cambridge, Massachusetts,USA, SOAP Version 1.2 Part 1: Messaging Framework,W3C Recommendation, June 2003. <http://www.w3.org/TR/soap12-part1/>.

[3] World Wide Web Consortium, Cambridge, Massachusetts,USA, SOAP Version 1.2 Part 2: Adjuncts, W3C Recommen-dation, June 2003. <http://www.w3.org/TR/soap12-part2/>.

[4] World Wide Web Consortium, Cambridge, Massachu-setts, USA, XForms 1.0, 2nd ed., W3C Recommendation,March 2006. <http://www.w3.org/TR/2006/REC-xforms-20060314/>.

[5] World Wide Web Consortium, Cambridge, Massachusetts,USA, Synchronized Multimedia Integration Language(SMIL) 1.0 Specification, W3C Recommendation, June1998. <http://www.w3.org/TR/1998/REC-smil-19980615>.

[6] M. Honkala, P. Cesar, P. Vuorimaa, A device independentXML user agent for multimedia terminals, in: Sixth IEEEInternational Symposium on Multimedia Software Engi-neering, 2004, pp. 116–123.

[7] J. Wikman, F.D. Racz, Mobile personal website, in: Mobi-Sys ’06: 4th International Conference on Mobile Systems,Applications, and Services: Demonstrations, 2006.

[8] S. Tarkoma, J. Kangasharju, T. Lindholm, K. Raatikainen,Fuego: Experiences with mobile data communication andsynchronization, in: 17th Annual IEEE International Sym-posium on Personal, Indoor and Mobile Radio Communi-cations (PIMRC), 2006. <http://dx.doi.org/10.1109/PIMRC.2006.254072>.

[9] J. Kangasharju, T. Lindholm, S. Tarkoma, Requirementsand design for XML messaging in the mobile environment,in: N. Anerousis, G. Kormentzas, (Eds.), Proceedings of theSecond International Workshop on Next Generation Net-working Middleware, 2005, pp. 29–36. <http://www.cs.hel-sinki.fi/u/jkangash/xml-messaging-mobile.pdf>.

[10] J. Kangasharju, T. Lindholm, A sequence-based type-awareinterface for XML processing, in: M.H. Hamza (Ed.),Proceedings of the Ninth IASTED International Conferenceon Internet and Multimedia Systems and Applications,ACTA Press, 2005, pp. 83–88. <http://www.cs.helsinki.fi/u/jkangash/xml-interface.pdf>.

[11] J. Kangasharju, S. Tarkoma, T. Lindholm, Xebu: A binaryformat with schema-based optimizations for XML data, in:A.H.H. Ngu, M. Kitsuregawa, E. Neuhold, J.-Y. Chung,Q.Z. Sheng (Eds.), Proceedings of the 6th InternationalConference on Web Information Systems Engineering,Lecture Notes in Computer Science, vol. 3806, Springer-Verlag, New York, USA, 2005, pp. 528–535. <http://www.hiit.fi/files/fi/fc/papers/wise05-xebu.pdf>.

[12] Bluetooth SIG, Specification of the Bluetooth System, CorePackage version 2.0, November 2004.

[13] J. Cai, D.J. Goodman, General packet radio service in GSM,IEEE Communications Magazine 35 (10) (1997) 122–131.

[14] D. O’Mahony, UMTS: the fusion of fixed and mobilenetworking, IEEE Internet Computing 2 (1) (1998) 49–56.

[15] Institute of Electrical and Electronic Engineers, Piscataway,New Jersey, USA, IEEE Std 802.11 – Wireless LANMedium Access Control (MAC) and Physical Layer (PHY)Specifications, March 1999.

[16] C.E. Perkins (Ed.), Ad Hoc Networking, Addison-Wesley,Boston, Massachusetts, USA, 2001.

[17] R. Harrison, Symbian OS C++ for Mobile Phones, vol. 1,Symbian Press, 2003.

[18] Sun Microsystems Inc. and Motorola Inc., Mobile Informa-tion Device Profile Version 2.0, November 2002.

[19] D. Winer, XML-RPC Specification (June) (2003). <http://www.xmlrpc.com/spec>.

[20] P.T. Eugster, P.A. Felber, R. Guerraoui, A.-M. Kermarrec,The many faces of publish/subscribe, ACM ComputingSurveys 35 (2) (2003) 114–131.

[21] Y. Huang, H. Garcia-Molina, Publish/subscribe in a mobileenviroment, in: S. Banerjee (Ed.), Proceedings of the 2ndACM International Workshop on Data Engineering forWireless and Mobile Access, ACM Press, 2001, pp. 27–34.

[22] B. Liskov, L. Shrira, Promises: Linguistic support forefficient asynchronous procedure calls in distributed systems,in: R.L. Wexelblat, (Ed.), Proceedings of the ACM SIG-PLAN Conference on Programming Language Design andImplementation, 1988, pp. 260–267.

[23] D. Brownell, SAX2, O’Reilly, Sebastopol, California, USA,2002.

[24] World Wide Web Consortium, Cambridge, Massachusetts,USA, Document Object Model (DOM) Level 3 CoreSpecification, W3C Recommendation, April 2004. <http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/>.

[25] A. Slominski, On using XML pull parsing Java APIs, OnXmlPull Web site, March 2004. <http://www.xmlpull.org/history/index.html>.

[26] BEA Systems Inc., San Jose, California, USA, JSR 173:Streaming API for XML, October 2003.

[27] World Wide Web Consortium, Cambridge, Massachusetts,USA, XML Schema Part 2: Datatypes, W3C Recommen-dation, May 2001. <http://www.w3.org/TR/xmlschema-2/>.

[28] World Wide Web Consortium, Cambridge, Massachusetts,USA, Namespaces in XML, W3C Recommendation, Janu-ary 1999. <http://www.w3.org/TR/REC-xml-names/>.

J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654 4653

[29] World Wide Web Consortium, Cambridge, Massachusetts,USA, WAP Binary XML Content Format, W3C Note, June1999. <http://www.w3.org/TR/wbxml/>.

[30] World Wide Web Consortium, Cambridge, Massachusetts,USA, XML Binary Characterization Use Cases, W3C Note,March 2005. <http://www.w3.org/TR/xbc-use-cases>.

[31] World Wide Web Consortium, Cambridge, Massachusetts,USA, XML Schema Part 1: Structures, W3C Recommen-dation, May 2001. <http://www.w3.org/TR/xmlschema-1/>.

[32] Organization for the Advancement of Structured Informa-tion Standards, Billerica, Massachusetts, USA, RELAX NGSpecification, December 2001. <http://www.relaxng.org/spec-20011203.html>.

[33] World Wide Web Consortium, Cambridge, Massachusetts,USA, Web Services Description Language (WSDL) 1.1,W3C Note, March 2001. <http://www.w3.org/TR/wsdl>.

[34] Organization for the Advancement of Structured Informa-tion Standards, Billerica, Massachusetts, USA, RELAX NGCompact Syntax, November 2002. <http://www.relaxn-g.org/compact-20021121.html>.

[35] C. Perkins, RFC 2002: IP Mobility Support, InternetEngineering Task Force October 1996. <http://www.iet-f.org/rfc/rfc2002.txt>.

[36] M. Youssef, A. Youssef, C. Rieger, U. Shankar, A.Agrawala, PinPoint: An asynchronous time-based locationdetermination system, in: P. Gunningberg, L.-A. Larzon, M.Satyanarayanan, N. Davies, (Eds.), Proceedings of Mobi-Sys ’06: 4th International Conference on Mobile Systems,Applications, and Services, Uppsala, Sweden, 2006, pp. 165–176.

[37] Sun Microsystems Inc., Santa Clara, California, USA, JSR46: Foundation Profile, [JCP Final], August 2002. <http://jcp.org/aboutJava/communityprocess/final/jsr046>.

[38] R. Caceres, L. Iftode, Improving the performance of reliabletransport protocols in mobile computing environments,IEEE Journal on Selected Areas in Communication 13 (5)(1995) 850–857.

[39] H. Balakrishnan, V.N. Padmanabhan, S. Seshan, R.H. Katz,A comparison of mechanisms for improving TCP perfor-mance over wireless links, IEEE/ACM Transactions onNetworking 5 (6) (1997) 756–769.

[40] J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby,RFC 3135: Performance Enhancing Proxies Intended toMitigate Link-Related Degradations, Internet EngineeringTask Force, June 2001. <http://www.ietf.org/rfc/rfc3135.txt>.

[41] WAP Forum, Wireless Application Protocol: ArchitectureSpecification, 2001.

[42] M. Laukkanen, H. Helin, Web services in wireless networks –what happened to the performance? in: L.-J. Zhang, (Ed.),Proceedings of the International Conference on Web Ser-vices, 2003, pp. 278–284.

[43] C. Werner, C. Buschmann, T. Jacker, S. Fischer, Bandwidthand latency considerations for efficient SOAP messaging,International Journal of Web Services Research 3 (1) (2006)49–67.

[44] World Wide Web Consortium, Cambridge, Massachusetts,USA, Web Services Addressing 1.0 – Core, W3C Recom-mendation, May 2006. <ttp://www.w3.org/TR/2006/REC-ws-addr-core-20060509/>.

[45] Organization for the Advancement of Structured Informa-tion Standards, Billerica, Massachusetts, USA, Web ServicesReliable Messaging: WS-Reliability 1.1, August 2004.<http://docs.oasis-open.org/wsrm/2004/06/WS-Reliability-CD1.086.pdf>.

[46] S. Campadello, O. Koskimies, K. Raatikainen, H. Helin,Wireless Java RMI, in: Fourth International EnterpriseDistributed Object Computing Conference, 2000, pp. 114–123.

[47] Object Management Group, Needham, Massachusetts,USA, Common Object Request Broker Architecture(CORBA/IIOP), version 3.0.3, March 2004.

[48] Object Management Group, Needham, Massachusetts,USA, Wireless Access and Terminal Mobility in CORBA,Version 1.2, May 2005.

[49] M. Caporuscio, A. Carzaniga, A.L. Wolf, Design andevaluation of a support service for mobile, wireless pub-lish/subscribe applications, IEEE Transactions on SoftwareEngineering 29 (12) (2003) 1059–1071.

[50] L. Fiege, F.C. Gartner, O. Kasten, A. Zeidler, Supportingmobility in content-based publish/subscribe middleware, in:M. Endler, D.C. Schmidt (Eds.), Proceedings of the 4thInternational Conference on Middleware, Lecture Notes inComputer Science, vol. 2672, Springer-Verlag, Rio deJaneiro, Brazil, 2003, pp. 103–122.

[51] R. Grimm, J. Davis, E. Lemar, A. MacBeth, S. Swanson, T.Anderson, B. Bershad, G. Borriello, S. Gribble, D. Weth-erall, System support for pervasive applications, ACMTransactions on Computer Systems 22 (4) (2004) 421–486.<http://www.cs.nyu.edu/rgrimm/one.world/papers/tocs04.pdf>.

[52] M. Satyanarayanan, Pervasive computing: vision and chal-lenges, IEEE Personal Communications 8 (4) (2001) 10–17.

[53] C. Mascolo, L. Capra, S. Zachariadis, W. Emmerich,XMIDDLE: A data-sharing middleware for mobile com-puting, Personal and Wireless Communications 21 (1) (2002)77–103.

[54] World Wide Web Consortium, Cambridge, Massachusetts,USA, XML Path Language (XPath) 1.0, W3C Recommen-dation November 1999. <http://www.w3.org/TR/xpath>.

[55] K. Chiu, W. Lu, A compiler-based approach to schema-specific XML parsing, in: First International Workshop onHigh Performance XML Processing, 2004.

[56] W. Zhang, R. van Engelen, A table-driven streaming XMLparsing methodology for high-performance web services, in:IEEE [69], pp. 197–204.

[57] M.G. Kostoulas, M. Matsa, N. Mendelsohn, E. Perkins, A.Heifets, M. Mercaldi, XML screamer: an integratedapproach to high performance XML parsing, validationand deserialization, in: L. Carr, D. De Roure, A. Iyengar,C.A. Goble, M. Dahlin, (Eds.), Proceedings of the 15thInternational World Wide Web Conference, Edinburgh,Scotland, 2006, pp. 93–102.

[58] T. Takase, H. Miyashita, T. Suzumura, M. Tatsubori, Anadaptive, fast, and safe XML parser based on byte sequencesmemorization, in: A. Ellis, T. Hagino, (Eds.), Proceedings ofthe 14th International World Wide Web Conference, Chiba,Japan, 2005, pp. 692–701.

[59] R. van Engelen, Code generation techniques for developinglight-weight XML Web services for embedded devices, in: H.

4654 J. Kangasharju et al. / Computer Networks 51 (2007) 4634–4654

Haddad, A. Omicini, R.L. Wainwright, L.M. Liebock,(Eds.), Proceedings of the 2004 ACM Symposium onApplied Computing, 2004, pp. 854–861.

[60] L.P. Deutsch, RFC 1952: GZIP File Format SpecificationVersion 4.3, Internet Engineering Task Force, May 1996.<http://www.ietf.org/rfc/rfc1952.txt>.

[61] H. Liefke, D. Suciu, XMill: an efficient compressor for XMLdata, in: W. Chen, J.F. Naughton, P.A. Bernstein, (Eds.),Proceedings of the 2000 ACM SIGMOD InternationalConference on Management of Data, 2000, pp. 153–164.

[62] J. Cheney, Compressing XML with multiplexed hierarchicalPPM models, in: Data Compression Conference, 2001, pp.163–172.

[63] P. Sandoz, A. Triglia, S. Pericas-Geertsen, Fast Infoset, OnSun Developer Network, June 2004. <http://java.sun.com/developer/technicalArticles/xml/fastinfoset/>.

[64] D.M. Sosnoski, XBIS XML Infoset encoding, in: W3CWorkshop on Binary Interchange of XML Information ItemSets, World Wide Web Consortium, 2003. <http://www.w3.org/2003/08/binary-interchange-workshop/09-Sos-noski-position-paper.pdf>.

[65] International Telecommunication Union, Telecommunica-tion Standardization Sector, Geneva, Switzerland, MappingW3C XML Schema Definitions into ASN.1, ITU-T Rec.X.694, 2004.

[66] C. Werner, C. Buschmann, Y. Brandt, S. Fischer, Com-pressing SOAP messages by using pushdown automata, in:IEEE [69], pp. 19–26.

[67] P. Saint-Andre, RFC 3920: Extensible Messaging andPresence Protocol (XMPP): Core, Internet Engineering TaskForce, October 2004. <http://www.ietf.org/rfc/rfc3920.txt>.

[68] M.T. Rose, RFC 3080: The Blocks Extensible ExchangeProtocol Core, Internet Engineering Task Force, March2001. <http://www.ietf.org/rfc/rfc3080.txt>.

[69] Institute of Electrical and Electronic Engineers, IEEEInternational Conference on Web Services. <http://confer-ences.computer.org/icws/2006/index.html>.

Jaakko Kangasharju is a doctoral stu-dent at the University of Helsinki, andworking as a researcher at the HelsinkiInstitute for Information Technology.His thesis research is concentrated onissues in XML messaging and processingon mobile devices. He is currently amember of the Efficient XML Inter-change Working Group at the WorldWide Web Consortium.

Tancred Lindholm is a doctoral student

at the Helsinki University of Technol-ogy, from where he received his M.Sc. in2001. He is currently working as aresearcher at the Helsinki Institutefor Information Technology, where heis researching and developing middle-ware for mobile devices with a focuson structured data access and synchro-nization.

Sasu Tarkoma received his M.Sc. and Ph.D. degrees in ComputerScience from the University of Helsinki, Department of Com-puter Science. He has managed and participated in national andinternational research projects at the University of Helsinki,Helsinki University of Technology, and Helsinki Institute forInformation Technology. He has also lectured several courses onmiddleware and data communications. He has over 50 refereedscientific publications and has also contributed to several bookson mobile middleware. His research interests include middlewareand distributed computing.