Service Oriented Architecture in Mobile Devices: … · JAX-RPC Java API for XML-based RPC JCP Java Community Process JMS Java Message Service JSR Java Speciﬁcation Request, speciﬁcations

HELSINKI UNIVERSITY OF TECHNOLOGYDepartment of Computer Science and EngineeringLaboratory of Information Processing Science

Oskar Ojala

Master’s thesisSupervisor: Professor Jorma TarhioInstructor: M.Sc. Eero Penttinen

Service Oriented Architecture inMobile Devices: Protocols and Tools

Helsinki, 7th November 2005

TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ

Tekijä: Oskar OjalaOsasto: TietotekniikkaPääaine: OhjelmistojärjestelmätSivuaine: Digitaalisten tuotteiden kehittäminenTyön nimi: Palvelusuuntautunut arkkitehtuuri mobiililaitteissa:

protokollat ja työkalutEnglish title: Service Oriented Architecture for Mobile Devices:

Protocols and ToolsSivumäärä: x + 80Professuuri: T-106 OhjelmistotekniikkaTyön valvoja: Professori Jorma Tarhio

Palvelusuuntautunut arkkitehtuuri (SOA) edustaa uutta tapaa rakentaa väljästikeskenään sidonnaisia hajautettuja järjestelmiä. Siinä korostuvat hyvin määritel-lyt palvelurajapinnat ja karkeajakoinen tiedonsiirto, joiden tarkoituksena onmahdollistaa toiminta heterogeenisessä verkkoympäristössä, jossa palvelujen jaasiakassovellusten kehittäminen eivät ole toisiinsa kytkettyjä. Mobiililaitteet,jotka ovat helposti kannettavia, aina päällekytkettyjä sekä kykeneviä suorit-tamaan nykyaikaisia käyttöjärjestelmiä, ovat yleistymässä, tulossa edullisem-miksi ja kykenevät enenevissä määrin suorittamaan monimutkaisia ohjelmistoja.Laitteiden koko, akkukapasiteetti ja hinta asettavat kuitenkin rajoituksensa lait-teille, joten mahdollisuus hajauttaa tietojenkäsittely ja hyödyntää ohjelmistojenetäkäyttöä on toivottava. SOAn käsitteen yhdistäminen mobiililaitteisiin mah-dollistaa käytännöllisiä, helposti laajennettavia ja helposti toteutettavia hajautet-tuja sovelluksia.

Tässä työssä pyritään vastaamaan kysymyksiin onko SOAa noudattavienohjelmistojen toteutus mobiililaitteille mahdollista, mikä on vaadittu ja tämän-hetkinen kieli- ja työkalutuki SOAlle, miten nykyiset toteutustekniikat, kutenprotokollat, soveltuvat mobiililaitteille ja miten erilaiset arkkitehtuurinäkymätkuten Representational State Transfer (REST) pitäisi ottaa huomioon palveluitasuunnitellessa. Tilanteen arvioimiseksi tarkastellaan Web service -tekniikoitarajapintojen ja tietorakenteiden määrittelyyn sekä tiedonsiirtoon. Työssätarkastellaan Web service- ja XML-tekniikoiden tukea C++-, Python- ja Java-ohjelmointikielten mobiililaiteversioissa. Lisäksi toteutetaan REST:n toteuttavatja Web service -tekniikoita hyödyntävät asiakasohjelmistot erilaisia työvälineitäkäyttäen ja tehdään suorituskykymittauksia. SOAa noudattavien ohjelmistojentoteuttaminen osoittautuu mahdolliseksi, mutta työvälineiden ja määrittelyjenkypsyyden kehittämisessä riittää vielä työtä.

Avainsanat:

Hajautettu tietojenkäsittely, ohjelmistonuudelleenkäyttö, palvelusuuntautunut arkkite-htuuri, Web services, sulautettu ohjelmointi,representational state transfer, XML-skeemakielet,rajapintakuvaus, palvelusuuntautunut tiedonkäsit-tely

i

HELSINKI UNIVERSITY OF TECHNOLOGY ABSTRACT OF MASTER’S THESIS

Author: Oskar OjalaDepartment: Department of Computer ScienceMajor: Software SystemsMinor: Development of digital productsTitle: Service Oriented Architecture in Mobile Devices:

Protocols and ToolsNumber of pages: x + 80Chair: T-106 Software TechnologySupervisor: Professor Jorma Tarhio

Service Oriented Architecture (SOA) represents a new way to build loosely cou-pled distributed systems. It emphasises well-defined interfaces and coarse-grained data transfer to be able to operate in network environments with hetero-geneous clients and decoupled client and service development. Mobile devicesthat are highly portable, always turned on and being able to run modern oper-ating systems are becoming increasingly common, increasingly affordable andincreasingly capable of running complex software. However, size, battery powerand cost place limits on device capabilities, so that being able to distribute com-puting effort and use remote software is desirable. Combining the concept ofSOA with mobile devices promises to deliver convenient, easily extendable andquick to implement distributed computing applications.

This thesis attempts to answer whether implementing SOA-conformant softwareon mobile devices is feasible, what the required and current level of languageand tool support is, how the current implementation technologies such as pro-tocols are suited for mobile devices and how various architectural views such asRepresentational State Transfer (REST) should be taken into account in designingservices. To assess the situation, Web service technologies for describing serviceinterfaces, data formats and for transporting data are discussed. Web service andXML-technology support is evaluated in the C++, Python and Java programminglanguages for mobile devices. A REST-compliant client and a Web service clientare implemented using various tools and performance measurements are made.Implementing SOA-conformant software proves possible, but there remains sub-stantial work in improving tool and specification maturity.

Keywords:

Distributed computing, software reuse, Service Ori-ented Architecture, Web services, embedded pro-gramming, representational state transfer, XMLschema languages, interface description, service ori-ented computing

ii

TEKNISKA HÖGSKOLAN SAMMANDRAG AV DIPLOMARBETET

Utfört av: Oskar OjalaAvdelning: Avdelningen för datateknikHuvudämne: MjukvarusystemBiämne: Utveckling av digitala produkterArbetets namn: Tjänstinriktad arkitektur i mobila apparater:

protokoll och verktygSidoantal: x + 80Professur: T-106 MjukvaruteknikÖvervakare: Professor Jorma Tarhio

Tjänstinriktad arkitektur (SOA) representerar ett nytt sätt att bygga löst koppladedistribuerade system. Den understryker väldefinierade gränssnitt och grovin-delad dataöverföring för att kunna fungera i nätomgivningar med heterogenaklienter och klient- och tjänstutveckling som är avkopplade från varandra. Mo-bila apparater som är mycket portabla, alltid påkopplade och som kan köra mod-erna operativsystem håller på att bli vanligare, billigare och kapablare på att körainvecklad mjukvara. Storlek, batterikapacitet och kostnader utgör dock begrän-sningar på apparaternas kapabiliteter, vilket innebär att det är önskvärt att kunnafördela beräkningsarbetet och fjärranvända mjukvara. Kombineringen av SOA-konceptet med mobila apparater utlovar att möjliggöra behändiga, lätt förlängdaoch snabbt verkställbara distribuerade databehandlingstillämpningar.

Detta arbete försöker besvara om genomförandet SOA-mjukvara på mobila ap-parater är möjligt, vilken är den fordrade och den nuvarande nivån av språk-och verktygsstöd, hur ämnar sig nuvarande implementeringstekniker, såsomprotokoll, för mobila apparater och hur borde olika arkitekturella syner så-som Representational State Transfer (REST) beaktas då tjänster planeras. Föratt utvärdera situationen analyseras Web service-tekniker för att planera tjänst-gränssnitt, dataformat och för att överföra data. Stöd för Web service och XML-tekniker utvärderas i C++, Java och Python-programmeringsspråken för mobilaapparater. En REST-enlig klient och en Web service-klient implementeras an-vändande olika verktyg och mätningar på prestanda utförs. Implementering avSOA-kompatibel mjukvara förefaller möjligt, men det kvarstår substantiellt ar-bete inom förbättring av verktygens och specifikationernas mogenhet.

Nyckelord:

Distribuerad databehandling, återanvändning avmjukvara, tjänstinriktad arkitektur, Web services,programmering av inbyggda system, representa-tional state transfer, XML-schemaspråk, gränssnitts-beskrivning, tjänstinriktad databehandling

iii

Contents

Contents iv

List of Figures vi

List of Tables vii

1 Introduction 11.1 Research goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 32.1 Mobile Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Hardware capabilities . . . . . . . . . . . . . . . . . . . . 42.1.2 Networking technologies . . . . . . . . . . . . . . . . . . 62.1.3 Operating Systems . . . . . . . . . . . . . . . . . . . . . . 72.1.4 Programming environments . . . . . . . . . . . . . . . . 82.1.5 Business environment . . . . . . . . . . . . . . . . . . . . 13

2.2 Service Oriented Architecture and Web Services . . . . . . . . . 142.2.1 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.2 Software reuse aspects . . . . . . . . . . . . . . . . . . . . 16

2.3 XML concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4 XML handling considerations . . . . . . . . . . . . . . . . . . . . 182.5 Frameworks for parsing XML data . . . . . . . . . . . . . . . . . . 18

3 SOA and Web service implementation 203.1 XML schema definition . . . . . . . . . . . . . . . . . . . . . . . . 203.2 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 RPC over the Internet . . . . . . . . . . . . . . . . . . . . . 243.2.2 Document-style use of SOAP . . . . . . . . . . . . . . . . . 25

3.3 Service description: WSDL . . . . . . . . . . . . . . . . . . . . . . 253.4 Service discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5 REST and WWW architecture . . . . . . . . . . . . . . . . . . . . . 273.6 REST based Web Services . . . . . . . . . . . . . . . . . . . . . . . 293.7 The Role of HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.7.1 Push and Pull . . . . . . . . . . . . . . . . . . . . . . . . . 313.7.2 HTTP as a Web service protocol . . . . . . . . . . . . . . . 32

3.8 Messaging systems and middleware . . . . . . . . . . . . . . . . 333.9 Web Services in Java ME: JSR-172 . . . . . . . . . . . . . . . . . . . 343.10 Web Services in Series 60 native environment . . . . . . . . . . . 35

4 General SOA observations 374.1 Various styles of Service Oriented Architecture (SOA) . . . . . . 374.2 Separation of content from presentation . . . . . . . . . . . . . . 384.3 Weaknesses of current specifications . . . . . . . . . . . . . . . . 404.4 Web service efficiency considerations . . . . . . . . . . . . . . . . 414.5 SOAP service implementation considerations . . . . . . . . . . . 434.6 Current use of REST . . . . . . . . . . . . . . . . . . . . . . . . . . 43

iv

5 RSS: a REST-based Web service 465.1 The RSS format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2 Implementation experiences . . . . . . . . . . . . . . . . . . . . . 475.3 Support for multiple schemas . . . . . . . . . . . . . . . . . . . . 505.4 Performance considerations . . . . . . . . . . . . . . . . . . . . . 515.5 Tool development possibilities . . . . . . . . . . . . . . . . . . . 57

6 SOAP based SOA implementation 586.1 Current status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.2 Environment requirements . . . . . . . . . . . . . . . . . . . . . . 586.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.4 A dictionary service . . . . . . . . . . . . . . . . . . . . . . . . . . 606.5 Strengths and weaknesses . . . . . . . . . . . . . . . . . . . . . . 61

7 Discussion 637.1 RPC compared to document oriented techniques . . . . . . . . . 637.2 The relation of SOAP-based services to REST . . . . . . . . . . . . 647.3 Tool and library support . . . . . . . . . . . . . . . . . . . . . . . 657.4 Performance issues . . . . . . . . . . . . . . . . . . . . . . . . . . 66

8 Conclusions 67

References 68

A RSS Reader performance measurements 77

v

List of Figures

1 The Java platform architecture. The height of the bars indicatethe extensiveness of the provided Application Programming Interfaces(APIs) of the respective platform. The lower boxes indicate thevirtual machine that is used for the platforms above them. . . . 10

2 Java Mobile Edition (ME) architecture. The vertical dimensionindicates abstraction layers. . . . . . . . . . . . . . . . . . . . . . 10

3 Various aspects a SOA implementation could have. Aspects thatare opposite one another in the figure are conceptually differentfeatures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 File reading and parsing speed depending on the number of at-tempts performed . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5 Parse times for different sized feeds averaged over several at-tempts and with standard deviations shown. . . . . . . . . . . . 53

6 Parse times for different sized feeds averaged over several at-tempts and with standard deviations shown. The tests wheredone on a later date and newer libraries than those used for Fig-ure 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7 Reading and parsing a network stream of 35 196 bytes duringnon-frequent intervals interspersed over two days. The totaltime is the sum of the time it takes to connect to the service andthe time it takes to read and parse the stream. . . . . . . . . . . . 55

8 The dictionary client user interface, shown in a Java ME emula-tor. A word has been typed and the mode is set to do a dictionarylookup. The result is displayed, along with a sponsor name,which could also be a link to additional information about theword searched. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

vi

List of Tables

1 Memory capacities (in MB) for some current phone models, or-dered by brand and cost. The data was gathered from [FN] and[MC]. The prices were the average prices of several retailers inFinland on June 20th, 2005 and they are in euros. . . . . . . . . . 5

2 Different Really Simple Syndication (RSS) feeds on the WorldWide Web (WWW). Note that the feeds may have different en-codings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3 Mean connecting times and their standard deviations. The lastthree results were obtained at a later date and with newer li-braries than the four first results. It is worth noting that the lastthree feeds were all served from the same server. . . . . . . . . . 54

4 Mean connecting and parsing times and standard deviations fora 30 572 byte feed. The Python version use was 1.1.6 alpha andtwo sessions with several attempts each were made in Python tominimise random variations. . . . . . . . . . . . . . . . . . . . . 56

vii

List of acronyms

AJAX Asynchronous JavaScript and XML

API Application Programming Interface

BP Basic Profile

CDC Connected Device Configuration

CLDC Connected Limited Device Configuration

CORBA Common Object Request Broker Architecture

COTS Commercial Off-The-Shelf

CRUD Create, Retrieve, Update and Delete, the common Web methods thatREST defines for manipulating network resources

DCOM Distributed Component Object Model

DOM Document Object Model

DTD Document Type Definition

ESB Enterprise Service Bus

GPRS General Packet Radio Service

GSM Global System for Mobile Communications

GUI Graphical User Interface

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

HTTPS HTTP Secure

IANA Internet Assigned Number Authority

IEEE Institute of Electrical and Electronics Engineers

ID-WSF Identity Web Services Framework, a set of Web service specificationsby the Liberty Alliance, somewhat similar to WS-I profiles

IDE Integrated Development Environment

IDL Interface Definition Language

IO Input/Output

IP Internet Protocol

ISV Independent Software Vendor

J2EE Java 2 Enterprise Edition

J2ME Java 2 Mobile Edition. Note that Sun announced during the Sun JavaOne2005 conference that the name is changed to Java ME

viii

J2SE Java 2 Standard Edition

JAR Java Archive, a format for packaging Java classes in a ready-to-run form

JAXB Java Architecture for XML Binding

JAXP Java APIs for XML Processing

JAX-RPC Java API for XML-based RPC

JCP Java Community Process

JMS Java Message Service

JSR Java Specification Request, specifications that Java platform implementersmay support

JVM Java Virtual Machine

KVM K Virtual Machine, a minimal implementation of JVM designed for mobiledevices along with CLDC

LAN Local Area Network

ME Mobile Edition, see J2ME

MIDP Mobile Information Device Profile

MIME Multipurpose Internet Mail Extensions

MMS Multimedia Messaging Service

OASIS Organization for the Advancement of Structured Information Standards

OS operating system

PDA Portable Digital Assistant

RELAX NG Regular Language description for XML Core, New Generation

REST Representational State Transfer

RMI Remote Method Invocation

RPC Remote Procedure Call

RSS Really Simple Syndication

SAX Simple API for XML

SDK Software Development Kit

SGML Standard Generalized Markup Language

SIP Session Initiation Protocol

SMIL Synchronized Multimedia Integration Language, used for MMS messag-ing

SMS Short Message Service

ix

SOA Service Oriented Architecture

SOAP Simple Object Access Protocol, but as of SOAP v1.2 “SOAP” is no longeran acronym, but a name

SSL Secure Sockets Layer

StAX Streaming API for XML

TAG Technical Architectural Group

TLS Transaction Layer Security

UDDI Universal Description, Discovery, and Integration

UI User Interface

UMTS Universal Mobile Telecommunications System

URI Uniform Resource Identifier

URL Uniform Resource Locator

VB Visual Basic

W3C World Wide Web Consortium

W-CDMA Wideband Code Division Multiple Access

WAN Wide Area Network

WiMAX Worldwide Interoperability for Microwave Access

WLAN Wireless Local Area Network

WSDL Web Services Description Language

WS-I Web Services Interoperability Organization

WS-IL Web Services Inspection Language

WWW World Wide Web

XML eXtensible Markup Language

XMLP XML Protocol

XSD XML Schema Definition

XSLT eXtensible Stylesheet Language Transformations

x

1 Introduction

In the late 1990s, the WWW and all things related to it were among the hottestthings around, even attracting the interest of many persons with a non-technicalbackground. During this time, the evolution of the WWW was rapid, in partic-ular due to the public pressure and large business opportunities involved. Atthis point, eXtensible Markup Language (XML) was becoming more mature anda number of people began using XML as a common markup style for encodingdata to be machine-processed. Soon, the term “Web services” was coined byMicrosoft and later IBM to denote a host of technologies and software to enableheterogeneous clients to communicate with each other over the WWW, withthe data intended for machine processing to build new kinds of applications[Box01]. The “Web service” hype of transferring machine-processed data thatwould be fully platform independent and flexible, globally between complexapplications was born.

Today, years later, the hype has largely faded and the standards and tech-nologies matured. Out of this have on one hand emerged architectural-leveldefinitions, such as SOA [BJK03] and Representational State Transfer (REST)[Fie00], and on the other hand implementation-level technologies, such as ma-ture WWW application container frameworks, a number of protocols and meta-languages for describing the data to transmit. Most importantly, significantpractical experience has been gained and successful deployments of these tech-nologies have been made.

At the same time as WWW technologies have evolved, mobile devices havegone from simple text-only electronic notepads to full-featured pocket com-puters with graphical screens, advanced wireless networking capabilities andpowerful operating systems. In order to support new features, packet data net-working has been added to mobile devices. Packet networking combined withopen programming environments are the enablers needed to build SOA con-formant systems. Since these features are now present in a number of mobiledevices, we can expect to see more interest towards using SOA to build newkinds of distributed systems where mobile devices are involved.

1.1 Research goals

In this thesis, the goal is to find out the current technical status of developingand employing SOA-based networked services on mobile devices. Specifically,the attempt is to assess whether current mobile devices are capable enoughas platforms for the implementation technologies that SOAs typically use andwhether the programming environments and tools are mature enough to sup-port efficient development of such software.

1.2 Related work

Zimmerman et al. have studied the use of SOA in a heterogeneous network inthe finance industry and found the results encouraging [ZMCO04]. Sindersonet al. have analysed the use of an information portal designed using SOA fordistributing information collected during the Mars Rover mission [SMM04].Christensen et al. have studied how Java could be extending for better abstrac-tion in constructing Web services [ClS03]. Nyholm did in her thesis investigate

1

how to design systems that can handle message variation in systems that useXML messaging [Nyh04]. Mahan gives in [Mah04a] an introduction to SOA, Webservices and the different technologies and specifications that are currently inuse in Web service implementations.

1.3 Organisation

In Chapter 2, the background for the current status is clarified and the con-cepts related to this thesis’ subject are explained. In Chapter 6, the differentmajor implementation techniques for SOA are explained, with the focus on themost common technologies. In Chapter 4, different aspects to consider thenimplementing SOA are discussed, different general usage scenarios are recog-nized and some considerations about choosing implementation techniques aremade. In Chapter 6, a simple RSS client is implemented to follow a typicaluse of REST, performance measurements are made and analyzed and some ob-servations about implementation issues and tool support are made. In Chap-ter 3, simple clients and servers are made in the traditional way of doing Webservices using Simple Object Access Protocol (SOAP). Observations are madeabout ease of implementation and tool support. In Chapter 7, the findings areanalysed and discussed. The findings of this thesis are concluded in Chapter 8.

2

2 Background

In this chapter, background information is presented on the software and hard-ware environment of mobile devices, on the key issues concerning Service Ori-ented Architectures and implementing them on the Internet.

2.1 Mobile Devices

Mobile devices have become highly popular in recent years. A computing de-vice is usually considered a mobile device when it is small enough so thatcarrying it around is effortless. Traditionally, this could be considered theonly constraint, but with the considerable rise in in the use of radio com-munications, particularly cellular phone networks and Wireless Local AreaNetworks (WLANs), mobile devices are typically expected to have some sortof wireless networking technology. SOAs deal with networked communicationand require some sort of network access from the participants. Furthermore,mobile devices are meant to be mobile, not wired, so the focus here is specif-ically on mobile devices with wireless network access. For these reasons, themobile devices discussed here will be assumed to have some sort of meansfor wireless networking and being able to access the Internet regardless of theunderlying wireless networking technology.

The question of at which point a device is small and light enough to bea mobile device clearly demonstrates the problems with the mobility crite-ria presented. To demonstrate the problem, modern laptop computers typ-ically have wireless network connections and some laptops are quite small,weighing in at about 1 kg. In contrast, mobile phones and Portable DigitalAssistants (PDAs) tend to weigh less than 300 grams and have wireless net-working which work at higher ranges. Small laptops are the size of large books,while mobile phones are usually smaller than pocket-sized books. Should lap-tops, phones and PDAs all be considered mobile devices? However, one mustconsider that laptops, PDAs and mobile phones vary considerably in size, espe-cially when older models are compared to current ones, and phones and PDAsoffer much better standby times than laptop computers. Due to these factors,it becomes increasingly difficult to determine what are the requirements for amobile device, particularly since the sizes and wireless capabilities of laptopshave been improving, while the processing capabilities and software sophisti-cation of mobile phones have improved significantly in recent years.

From the viewpoint of this thesis, devices with Internet connectivity are ofparticular interest, as well as the low power requirements of battery operationand the limited processing power of smaller devices. Considering this view-point, the actual nature of the device is not so important, particularly since im-plementing SOAs demands sophisticated software capabilities. However, longstandby time and good portability are key concerns to users of mobile devicesand by sheer market share, mobile phones are the most popular devices in usetoday and will continue to be so for the foreseeable future. Given these con-siderations, this thesis focuses primarily on mobile phones, but the results andconclusions should be easily applicable to PDAs also.

In the following sections the hardware and software capabilities, as well asprogramming considerations, will be outlined for the mobile phones availableat the time of writing. Particular focus is given to the emerging smartphone-

3

segment, which could be best characterized as phones which are essentiallylike pocket-size computers equipped with wireless network connections. Thesmartphone segment is currently small compared to the size of the entire mo-bile phone market, but rapidly increasing hardware capabilities are makingsmartphone-features possible even in low-end models.

2.1.1 Hardware capabilities

In the previous section, it was noted that the categorisation of mobile devices isnot entirely clear. Not only is the definition of a mobile device slightly vague,but there is some overlap between categories; for example, the Nokia Commu-nicator phone is very much a phone and a PDA in the same package. Even if weonly consider the mobile phone market, it will be evident that there are consid-erable differences in device capabilities. Table 1 lists memory capacities, retailprices and operating systems (OSs) for some phone models for sale in Finlandduring June in the year 2005.

4

Tabl

e1:

Mem

ory

capa

citi

es(i

nM

B)fo

rso

me

curr

entp

hone

mod

els,

orde

red

bybr

and

and

cost

.Th

eda

taw

asga

ther

edfr

om[F

N]a

nd[M

C].

The

pric

esw

ere

the

aver

age

pric

esof

seve

ralr

etai

lers

inFi

nlan

don

June

20th

,200

5an

dth

eyar

ein

euro

s.M

odel

OS

Max

heap

size

Shar

edst

orag

eM

axJA

Rsi

zeA

nnou

nced

App

r.re

tail

pric

eN

okia

9300

Seri

es80

∞76

∞8

sep

0468

0N

okia

N90

Seri

es60

∞30

∞27

apr

0568

0N

okia

6630

Seri

es60

∞10

∞14

jun

0444

0N

okia

3230

Seri

es60

∞6

∞2

nov

0433

0N

okia

6060

Seri

es40

0.5

30.

137

13ju

n05

over

100

Nok

ia26

50Se

ries

400.

20.

980.

0614

jun

0411

0M

otor

ola

A10

00U

IQ2.

1∞

24∞

2004

920

Mot

orol

aE1

000

Mot

orol

a1.

5∞

0.2

2004

520

Mot

orol

aR

azrV

3M

otor

ola

0.8

50.

120

0446

0M

otor

ola

V63

5M

otor

ola

0.8

50.

120

0539

0M

otor

ola

V18

0M

otor

ola

0.8

1.8

0.1

2004

140

5

In Table 1 a set of models from Nokia and Motorola are presented. Sincethese companies together control approximately 50% of the mobile phone mar-ket, the selection of models should be fairly representative. The average retailprices are included in the table to show the price and capability variation cur-rent phone models have. There are even cheaper phones available than theones listed, but devices in the lowest end category cannot be expected to be rep-resentative of future phone capabilities and they may not be able to run thirdparty software. The maximum heap size and maximum Java Archive (JAR)size refer to the heap size and total binary package size respectively when run-ning Java software on the phone. To clarify, a Java MIDlet is packaged in aJAR for deployment on a phone and the JAR can run directly without the needfor unpacking. For a property that has a maximum of infinity there is no ar-tificial limitation on that quantity, i.e. maximum sizes are as large as availablememories permit. The Motorola E1000 has expandable memory and selectablestorage area, which is why the shared storage area is marked as being infinite.This is a somewhat misleading practice, as removable memory cards are thenorm in higher end phones, which would give them “infinite memory” usingthe same criteria.

An essential thing to note from Table 1 is that capabilities vary significantlybased on the phone’s price point. High-end models have tens of megabytesof memory, but the simpler models restrict the size of programs significantly.The software feature differences are not presented, except for the operatingsystems, discussed in Section 2.1.3, as the comparison would require a signifi-cant amount of background knowledge to comprehend and it is not necessaryfor understanding mobile devices from a SOA-viewpoint. What can be saidof software features is that higher end models offer increasingly sophisticatedprogramming tools and they offer more extensive standard libraries for the de-veloper. Specific information on Nokia’s models can be found from [FN] andon Motorola’s models from [MC].

Most phones sold are in the lower end segment of the market. The lowerend phones are too limited to constitute a good platform for developing SOAbased applications, particularly since their library support is minimal and theirlimited memories and processing power seriously limit the scope of applica-tions. Only through the advanced capabilities available in the higher end mod-els has SOA become an interesting proposition for mobile phones. The situationin other mobile devices is similar, one can consider how limited the PDAs of thelate 1990s were from Antero Taivalsaari’s efforts to port Java to them [Tai99].PDAs have actually for a few years offered powerful enough hardware to buildSOAs on them, but their network connectivity has been seriously limited.

2.1.2 Networking technologies

A mobile device requires some sort of wireless network interface to beable to connect to computer networks, particularly the Internet. Tradition-ally, phones have used cellular networks, such as Global System for MobileCommunications (GSM), to connect to networks. One GSM radio channel has abandwidth of 9.6 kbps, which was fairly limited even in the late 1990s. TheGeneral Packet Radio Service (GPRS) technology does provide, as its name im-plies, a packet networking capability over GSM radio networks. It has the abil-ity to use all free radio channels, i.e. channels not in voice communication use

6

at the moment, of a network cell to transmit data with a bandwidth up to 57.6kbps [Buc00].

Radio communications do, however, have some drawbacks compared tofixed networks, mainly the packet loss being substantial and the inherent dif-ficulties with maintaining fast radio links over significant distances. Conse-quently, latency is typically quite poor and link quality can vary considerably,leading to poor bandwidth. Additionally, as GPRS only uses available chan-nels for data, bandwidth can drop back to 9.6 kbps in a congested radio cell[Buc00]. However, radio network technology has advanced very rapidly inrecent years, with a number of improvements to cellular data networks hav-ing been deployed. The most significant of these is the switch to third gen-eration networks that replace GSM. Third generation networks are based onWideband Code Division Multiple Access (W-CDMA) radio channel technologyon a higher frequency than GSM. The implementations vary a bit around theworld, the European version being called Universal Mobile Telecommunica-tions System (UMTS).

W-CDMA cellular networks are designed to offer packet data bandwidths upto 384 kbps, in part due to the higher frequency and in part due to the moreefficient radio channel use that W-CDMA does. However, there are two draw-backs to this. First, increasing frequency decreases operating range and thusmakes packet loss and signal quality a bigger problem. Second, the efficientW-CDMA algorithms used have far more processing overhead than GSM radiocommunications, leading to poorer battery longevity.

The introduction of WLAN in personal computers has lead to some degreeof mobile revolution, with WLAN technology being a standard feature in mostnew laptop computers. WLAN has advanced quickly, with initial 1 Mbps perfor-mance having quickly been phased out in favour of the IEEE 802.11b standardand its 11 Mbps bandwidth. This development has already caught all segmentsof networked mobile devices, WLAN looking to become more common with theintroduction of devices such as the Nokia 9500 Communicator with built-inWLAN. The next-generation of WLAN seems to be Worldwide Interoperabilityfor Microwave Access (WiMAX) (IEEE 802.16), a complex microwave networktechnology operating on 10-66 GHz frequencies [WiM]. WiMAX is designed tooffer a theoretical maximum transfer rate of 15 Mbps in a typical cell with athree kilometer radius, being thus almost two orders of magnitude faster thancurrent cellular technologies.

A key aspect of the user experience is to present delay-free user interfacesto the user. SOAs require, per definition, data network connections, but theperformance of such connections has not always been very good in mobiledevices. To determine whether or not this poses an obstacle for useful SOAimplementation, some performance tests are performed. The test setup andresults are discussed in Section 5, page 46.

2.1.3 Operating Systems

The smartphone market is currently split between two incompatible OSs, Sym-bian OS and Microsoft Windows Mobile, with Symbian clearly dominating thephone market. The mobile version of Windows has a very strong market inPDAs, but the PDA market itself is under threat from rapidly evolving smart-

7

phones. Most phones, however, are not smartphones and they tend to run OSsthat are proprietary to the phone manufacturers.

Symbian OS constitutes the basic OS of the device, on which manufactur-ers provide additional features, such as a Graphical User Interface (GUI) andprogramming libraries offering more extensive features than Symbian OS of-fers alone. Table 1 lists a number of mobile phones and their OSs, where Series60 is the product that Nokia builds on the Symbian OS, UIQ being a similaroffering from UIQ Technology. In Table 1, “Motorola” stands for Motorola’sproprietary OS and Series 40 is the name of Nokia’s proprietary OS. These arebased on older, proprietary OSs, which were designed in the 1990s when mo-bile phones were more limited. Series 80 is a product from Nokia that is alsobased on Symbian OS and it is used in the PDA-like Communicator series ofphones.

The development of mobile device OSs has followed a somewhat similarpath as in microcomputers: first, very limited manufacturer specific systemsare introduced, then more abstraction enabling clean OS interfaces and featuressuch as multitasking and finally the spread of multi-platform OSs with sev-eral abstraction layers, security features and advanced features, such as virtualmemory. Implementing SOAs is far more convenient on advanced OSs that offertrue multitasking, modern network stacks, XML tools and other useful libraries.Also, adding support for new programming languages is a lot easier and eco-nomic on an advanced OSs, so consequently implementing SOA support is de-sirable only on more advanced phones, such as those running Symbian OS orWindows Mobile. In the next section, programming on these operating sys-tems will be evaluated.

2.1.4 Programming environments

Symbian C++ The base language of the Symbian Series 60 environment isC++, also known as Symbian C++ to highlight that using C++ on Symbian hasslightly different requirements than using it in modern microcomputer envi-ronments. These stem from the fact that Symbian OS was designed for mobiledevices, where computing resources and memory are scarce. An area of pe-culiarity is the error handling. Symbian introduces a trap harness for catchingexceptions – “leaving” in Symbian parlance – from functions, instead of us-ing the C++ exception mechanism that was introduced in standard C++ lateron. In addition to the trap harness, a special cleanup stack is provided. It isintended that automatic variables allocated on the heap (typically object point-ers) be pushed onto the cleanup stack so that if an exception occurs, the al-located space can be freed by looking at the stack contents. This mechanismintends to make it easier to recover from exceptions, as heap memory can beautomatically freed. This system requires some manual labour, as is typicalwith C and C++, and in order to work, many classes need to implement atwo-stage constructor. The purpose is for the normal constructor to do onlyoperations that cannot cause exceptions, while the second constructor is calledafter the normal constructor and it can throw an exception (“leave”), which isin turn caught in the instantiating code.

Another major difference from standard C++ is the handling of strings. In-stead of using C-style character arrays or fully automatic string classes, Sym-bian C++ uses a set of macros, classes and templates to implement what is

8

called string descriptors. The idea is to provide complete protection from writ-ing past the end of the string and from memory leaks. However, descriptorsare essentially a low-level way of implementing strings, since they leave it upto the programmer to decide whether a string should be a literal or go on thestack or the heap, as these cases all require different macros and class instan-tiations. All strings are Unicode and all string storage needs to be allocatedseparately.

In addition to the distinctive aspects of Symbian C++ described above, thereare a few others too. Instead of using explicit threads for event handling, Sym-bian uses active objects. Active objects are, in practice, event handler objectsthat implement a certain interface. An active object is registered as an eventhandler for a particular type of event, after which the object is called in casethe event occurs. This way, the programmer need not implement separatethreads for event handling. Symbian OS is designed to run on a multitude ofplatforms, so certain assumptions must be made for datatypes. Thus, certaintypes are defined to replace basic datatypes; for example, integers are definedto be always 32-bit wide and little-endian in Symbian C++, so that porting isfacilitated. Symbian C++ strongly discourages multiple inheritance and pri-vate inheritance. It also imposes a naming convention, where, for example, thefirst letters of the class name contain information about what kind of class it is.Finally, the standard template library has not been ported to Symbian C++.

It should be noted that future intentions are to develop Symbian C++ toconform better to standard ISO C++. The Symbian OS is implemented in C++

and thus Symbian C++ is the language for accessing the Symbian OS on thelowest possible level. While the Symbian OS provides basic services and APIs,third-party extensions, such as Series 60, make it useful by adding decent UserInterface (UI) functionality and supporting libraries. Series 60 3rd Edition plansto introduce some XML and Web Services functionality for Symbian C++ devel-opers to use.

Java Java is currently a very popular language for many applications, in-cluding applications for mobile devices. It is an object-oriented, dynamicallybound, strongly and statically typed language. The variant of Java used in mo-bile environments is Java ME, previously Java 2 Mobile Edition (J2ME). The Javaplatform architecture is depicted in Figure 1, where Java 2 Standard Edition(J2SE) refers to the desktop and Java 2 Enterprise Edition (J2EE) to the server ver-sions of Java. Java ME consists of the Connected Limited Device Configuration(CLDC) (the newest version is 1.1) and Mobile Information Device Profile (MIDP)(the newest version is 2.0) specifications for defining the libraries and capabili-ties that are supported by the Java Virtual Machine (JVM) implementation. De-vices that are more powerful may use Connected Device Configuration (CDC)instead of CLDC, as it supports more powerful language features. CLDC definesrequirements for a virtual machine (JVM) and a set of basic APIs that a mobile de-vice should support. CLDC 1.1 is defined in Java Specification Request (JSR)-139.The relation of the Java ME components to the rest of the system is illustratedin Figure 2.

While CLDC and MIDP form a base language and API set to build on, mobiledevices frequently offer more advanced features to use, such as cameras andpersistent storage. Interfaces to such features are defined in JSRs in the Java

9

J2EE J2SE

JVM

CDCCLDC

KVM

Java Card

CardVM

Figure 1: The Java platform architecture. The height of the bars indicate theextensiveness of the provided APIs of the respective platform. The lower boxesindicate the virtual machine that is used for the platforms above them.

Community Process (JCP), a process in which individuals and organisationsmay participate in defining open Java APIs [JCP]. One such JSR, JSR-172 J2MEWeb Services Specification [EY03], is very useful for service oriented applica-tions and it will be discussed more closely in Section 3.9.

CDC is less restricted than CLDC, offering more advanced virtual machinefeatures and libraries to use. It is intended for PDAs and high-end phones, buthas not yet been deployed in mobile phones. However, with increasing phonecapabilities it can be expected that CDC-enabled smartphones will sooner orlater enter the market. Indeed, at the JavaOne 2005 conference in San Fran-cisco, Nokia did announce the introduction of a host of new, powerful featuresfor mobile Java, including CDC support for Series 60 [Nic05, Sch05, Osw05,Cla05, Cor05]. It should, however, be kept in mind that CDC will be graduallyintroduced, first in high-end models and thus it is impossible to say how themarket penetration will progress. In other words, developers will be workingwith CLDC-based platforms for a considerable time to come.

Hardware

OS and system libraries

CLDC

softwareNative

MIDP

Java ME applications

Figure 2: Java ME architecture. The vertical dimension indicates abstractionlayers.

10

The virtual machine that runs Java ME was originally called the K VirtualMachine (KVM) [Mah04b], but since then, the naming has changed. For con-sistency, the term JVM will be used throughout this thesis, and references tothe different Java platforms will be mentioned explicitly if not referring toJava ME. The development of Java ME is based on work by Antero Taival-saari [Tai98, Tai99] and constitutes a significant milestone in that it providesthe mobile environment with a way to run the same binary on different devicesand OSs. This is particularly important since CLDC support is present even onmany lower-end phones running closed OSs. However, the steadily increas-ing amount of JSRs and bugs in the platforms’ Java implementations makescross-platform development more difficult than one would initially think, par-ticularly since there are literally hundreds of different CLDC supporting phonemodels in use.

Python for Series 60 Python is a popular interpreted programming language.The Python implementation for the Series 60 platform is fairly new [S60a]. Likeother popular modern interpreted languages, Python is dynamically typed andoffers a fair amount of useful features in the base implementation, such aseasy Unicode string manipulation and regular expression support. Python isweakly typed so that when sending a message to an object, the recipients abil-ity to receive the message is resolved completely at runtime, making separateinterface definitions such as those used in Java and C++ redundant. Pythonalso has limited facilities for reflection, such as being able to query runtime ob-jects and properties and the ability to set an object’s attributes based solely onstrings containing the names of the attributes.

Python offers good built-in support for networking-related tasks and somesupport for handling XML, with several free XML processing libraries available.However, Python for Series 60 does not come bundled with any library supportfor implementing Web services. Series 60 Python is still in development, withthe Python interpreter and some documentation available to the public, but theruntime is not included in shipping mobile devices.

Microsoft C++ The Windows Mobile environment has – like Symbian – C++

as its base language. Naturally, Microsoft C++ is somewhat different fromSymbian C++ and offers features tailored for the Windows Mobile platform.The Microsoft C++ for Windows Mobile discussed here is different from Mi-crosoft Visual C++, as it is tailored for the mobile environment. It has requireda Software Development Kit (SDK) of its own to develop software, instead ofusing Microsoft Visual Studio. Visual Studio can be used to produce softwarefor Windows Mobile, but C# or Visual Basic (VB) cannot be run natively on Win-dows Mobile, as they will need adaptation layers. This is somewhat similar toJava ME and Python for Series 60.

Crossfire and .Net AppForge Inc. makes a product called Crossfire, which en-ables platform-independent mobile software development in C#, VB .Net andVB version 6. Crossfire integrates with a number of Microsoft’s Integrated De-velopment Environments (IDEs), most notably Visual Studio .Net, which pro-vides a fairly rich development environment. In order to run Crossfire-written

11

software, the Crossfire client software needs to be installed on the mobile de-vice.

Comparison It can be seen that environments and languages are split be-tween platform independent options – Java, Python, C# – and heavily platformdependant options – Symbian C++, Microsoft C++. In practice, there are over700 million Java ME supporting devices made to date, according to Sun Mi-crosystems [Cla05]. This can be contrasted to the Series 60 platform, which hasbeen shipped by Nokia alone in over 25 million units [Cor05]. Since Nokia iseasily the largest maker of Series 60 devices and Series 60 is clearly the mostpopular platform for higher end platforms, it can be seen that Java ME has quitea lead in adoption ratings.

There are, however, a few caveats. First, the Python for Series 60 platformis not yet complete and made into a product. Second, while Crossfire offers aninteresting platform for developer, it requires using the Crossfire platform onboth mobile device and development environment, which easily becomes lo-gistically and financially unfeasible for Independent Software Vendors (ISVs) tosupport in Commercial Off-The-Shelf (COTS) software. Thus, Crossfire is mostuseful for network operators making applications for their subscribers. Finally,while Java ME has huge deployment ratios and most mobile device COTS soft-ware popularly advertised seems to be made with Java, there are significantinteroperability issues. One basic problem is that different devices support dif-ferent APIs and profiles and thus contain libraries with differing feature sets.Thus, the latest and greatest features may only be available on high-end smart-phones, while mass-marketed consumer phones have much more limited pro-gramming libraries available.

To combat the fragmentation of the Java platform, new initiatives have beenstarted. Specifically, the JSRs 248 and 249 specify “Mobile Service Architec-tures” for CLDC and CDC respectively [Cor05]. What these actually define is aset of base profile and JSRs that a device should support. Two major new intro-ductions are the JSR-232 [Nic05, Cla05], which provides means for augmentinga device’s capabilities by loading new libraries on the fly, and the introductionof CDC to mobile phones [Sch05, Osw05, Cor05]. These are fairly large changes,since a mobile device, especially a phone, has been a fairly static platform,with all software capabilities supported installed during manufacturing andnot changed thereafter. In the future, however, JSR-232 permits the basic capa-bility set of the phone to be modified by the user, even quite transparently, topermit non-technical users to have new fundamental features installed. Fromthe IBM Corporation’s viewpoint, this is a major enabler for bringing powerfulSOAs to the mobile platform [Cla05].

JSR-232 is targeted for the CDC configuration of Java ME. CDC permits fea-tures to be supported that are more advanced than those of CLDC are. Thus, itenables the software developer to make more complex programs for the plat-form than was previously possible. It is worth to note that while Series 60 willeventually receive CDC support, the majority of mobile phones will still be sup-porting the CLDC platform, so the fragmentation of the Java ME platforms willlikely increase for some time despite the efforts to curb it.

12

2.1.5 Business environment

In the course of evaluating SOAs for mobile devices, one cannot help but torun into constraints set up by the business environment in which mobile de-vices operate. The reason for this is that traditionally, the telephone networkhas been an intelligent network with dumb terminals (telephones), where thenetwork operators have played a considerable role in developing, maintainingand charging for the network services. Consequently, this business model hascarried over to the mobile world, where considerable capital assets and legis-lation on distribution and use of radio frequencies give the network operatorsa considerable role, even if terminals have grown much smarter.

This thesis focuses on the technical aspects of SOAs in a mobile environmentand thus does not address the constraints placed by the business environment.However, designers cannot work in a vacuum and ignore the users of the tech-nology. Thus, a few words about the business environment are in place.

In the current environment, network operators have a lucrative business inthe growing mobile networks. However, voice services alone cannot accountfor endless growth, so there is an interest in building up business on data ser-vices. At this point, SOAs for particular uses offer one possibility for buildinguseful services cost-efficiently. For example, a restaurant locating service im-plemented as a Web service could work in different countries with differentservice providers, so that the travelling consumer could seamlessly roam be-tween networks and use the service.

The user’s perspective to SOAs is slightly different and perhaps more real-istic: how to make valuable networked services available cost-efficiently formobile users? A possible scenario could be roaming the intranet in differentsites of the same corporation using a smartphone – fetching meeting minutes,floor plans for meeting rooms and calendar appointments could be practicallyautomatic. It is worth to note that this scenario is greatly facilitated if the mo-bile device has a WLAN network connection, since it offers higher speeds thanthe typical GPRS cellular connection and the costs are flat rate instead of de-pending on the amount of data transmitted. Operators do not typically allowserver ports to be opened to mobile phones when using GPRS, which furtherplaces limitations on what can be currently done.

To realise these business goals, technical feasibility is required, which is dis-cussed in the course of this thesis, but also a profitable business model. A keyaspect here is charging models for Web services, something which Taylor et al.have studied through a public sector system implemented in Sydney [TAC05].Their system is fairly elaborate, having been strongly influenced by phone net-work charging systems. Simpler models could suffice for many services andone could expect services that were free or funded by advertising or similarmeans of indirect charging.

In terms of charging for services, more research is needed, but undoubt-edly more studies will be made in this field. Enabling efficient and transparentcharging systems with low usage costs would attract more service providersinto the market. The subject of charging methods will not be further discussedin this thesis, however when evaluating protocols and architectures, the possi-bility of implementing charging systems needs to be taken into account, as thisis an important feature for many parties.

13

2.2 Service Oriented Architecture and Web Services

Service Oriented Architecture (SOA) is a fairly new term, but the architecture itdescribes has firm roots in earlier technologies. Indeed, both SOA and Web ser-vices are largely coined as marketing terms, but nowadays definitions that aremore precise and mature technologies are being identified with these terms. Todefine SOA loosely, it aims at designing software systems to offer well definedand discoverable public interfaces to the services that the systems offer [BJK03].SOAs are distributed systems offering atomic and self-contained services to oneanother [Mah04a]. More precisely, Brown and Johnston list in [BJK03] six keycharacteristics for efficient SOAs:

Coarse-grained The service provider offers relatively large services and datatransfer is done with large entities in order to minimize the frequencyand amount of communication.

Defined interfaces The interfaces to the services are clearly defined and pub-lic, so that both service providers and requesters can inter-operate in aheterogeneous service environment.

Discoverable Services can be found, especially at run time, based on somecriteria for the service.

Single instance The service forms a single instance, whose life cycle does notdepend on the service, and the service has a single access point for com-municating with several different requesters.

Loosely coupled Services are loosely coupled with the requesters and they usestandard protocols and data formats for communicating.

Additionally, Brown and Johnston identify that in general, services com-municate asynchronously, but this is not always the case [BJK03]. Whether ornot asynchronous communication is a desirable feature depends on the typeof service offered. Thus, asynchronous communication cannot necessarily beconsidered a characteristic feature of SOA, as the number of services using syn-chronous communication is hardly insignificant.

It can be seen that the characteristics loose-coupled and coarse-grained aresomewhat intertwined with one another. Specifically, loose coupling does re-quire in practice that the messages passed and operations performed betweenthe participants are fairly large and coarse grained, as otherwise communica-tion latency would have a significant negative impact on performance. This is aclassical problem in distributed systems; higher latencies and lower bandwidthnecessitate the use of looser coupling and increasing local processing of data.This is a significant issue in mobile devices, since radio communications tendto have high latency, low bandwidth and highly varying quality. Loose cou-pling combined with defined interfaces do help facilitate service reuse [He03].

Initially, the SOA concept was developed for the Internet and the personalcomputers connected to it, which differs significantly from tightly controlledLocal Area Networks (LANs). Thus, SOAs need not only be loosely coupledand have coarse-grained communication, but also the interfaces must be welldefined and made public so that service requesters can use the service. Sometypical characteristics that are required from SOA interfaces can be identified:

14

Well-defined interfaces Interfaces are defined clearly, preferably in a widelyaccepted format

Published interfaces Interfaces are published so that service requesters candiscover them, identify them and use them

Public interfaces Interfaces are publicly defined, so that the details about whatthe service offers and how it is used are publicly available

Universal access methods to interfaces Interfaces can be discovered and ac-cessed by the use of standard protocols and tools

Making good interfaces is tricky and thus a lot of the work around SOA isabout interfaces and defining them. However, this is necessary in the homo-geneous Internet environment, as there will be multiple systems and program-ming languages in use on the same network. Consider Java Remote MethodInvocation (RMI) – it is really designed for performing Remote Procedure Calls(RPCs) on a controlled network between different applications of a Java sys-tem. On the Internet, there are several programming languages, programmingparadigms and operating environments in use, so clearly a solution designedfor finer-grained communication using RPC on Java will not be flexible enough,as a service requester might want to program in Perl and use more coarse-grained communication. Thus, SOA interfaces should be platform independent.For example, an airline company might serve its WWW site using Microsoft’s.Net platform, programmed in C# and a service requester client for a mobilephone is implemented using Java ME. In a SOA, the choice of implementationlanguage and platform should be invisible to the participants in the commu-nication, which is made possible by using the defined interfaces and agreedprotocols. In fact, a SOA service provider cannot know of all possible client im-plementations at design time, so SOA implementations must provide protocolsthat are independent enough to enable interoperability with future systemsthat might be implemented with entirely new tools.

SOA is not only targeted at providing an interoperability framework for fu-ture services and service requesters, but also to enable interfacing legacy sys-tems with newer ones using standard tools. Middleware plays a role here, asmiddleware can be used to provide a SOA service to a legacy system. The ideais to improve system interoperability and flexibility by using a standard set oftools and a single architecture for all systems, instead of using several incom-patible interfaces, protocols and architectures to interface with all the differentsoftware systems that an organisation has.

2.2.1 Web Services

The term “Web services” actually predates SOA, at least in popular usage. Anexplanation comes from the fact that while SOA defines the basic architecturefor providing services in a loosely-coupled, heterogeneous network, Web ser-vices is more about the concrete implementation technologies, i.e. protocolsand data formats. Web services are thus an implementation of SOA [Mah04a].

The World Wide Web Consortium (W3C) has created the Web services ar-chitecture document [BHM+04], where it tries to define Web services and therelated architectures:

15

A Web service is a software system designed to support inter-operable machine-to-machine interaction over a network. It hasan interface described in a machine-processable format (specificallyWSDL). Other systems interact with the Web service in a mannerprescribed by its description using SOAP messages, typically con-veyed using HTTP with an XML serialisation in conjunction withother Web-related standards.

In common usage, the term “Web services” has become a bit muddled, asREST-based Web services have been increasingly discussed in recent years onthe Internet (see Section 3.6, page 29). Due to the slight naming inconsistencies,this thesis will refer to REST-based Web services as those defined in Section 3.6and SOAP-based Web services, or plainly Web services if there is no risk of con-fusion, when referring to Web services implementation technologies that aremore in line with the definition in [BHM+04].

Web services were originally a set of technologies for solving distributedcomputing over the Internet, mainly developed by Microsoft and IBM. Duringthis decade, both SOAP and Web Services Description Language (WSDL) havebecome publicly drafted standards to ensure wide support and improve inter-operability. The technologies themselves are discussed in Section 3.2, page 21.The aim, as an implementation of SOA is twofold:

• To enable reusing existing services on the Internet or on intranets by pro-moting interoperability

• To enable connecting legacy systems to each other by wrapping thembehind standard interfaces

The key benefits of Web services compared to distributed computing tech-nologies such as Distributed Component Object Model (DCOM) or CommonObject Request Broker Architecture (CORBA) are that Web services are basedon open standards which are widely used, they are designed to operate onnetworks where speed and reliability cannot be guaranteed [BHM+04] andwhen systems on different platforms and from different vendors need to inter-operate [BHM+04]. With mobile devices in mind, it can be seen that all ofthese advantages are quite beneficial: mobile devices are frequently from dif-ferent vendors, employing different platforms and different platform versionsand wireless networks are frequently unreliable.

2.2.2 Software reuse aspects

SOA essentially defines an architecture where different clients can use services,either to provide the results to the user or to construct aggregate services andserve these further. A classic example is the airfare service, where one servicecomputes the cheapest airfares by using the services of airline and travel com-panies and aggregating the results into a single service.

From the use cases presented, one can see that a key aspect of SOAs is soft-ware reuse. Specifically, a service requester can use a service over the networkinstead of implementing this functionality internally. Further, the fact that in-terfaces are defined and made public makes it possible to reuse services of thirdparty service providers. This also makes it possible for several clients and client

16

providers to use the services of several different service providers and serviceimplementations, provided that they use the same interfaces. Thus, serviceprovider and requester implementations form a many-to-many connection ofservice relationships.

In order to find the services to use, universal service discovery is needed.If the interfaces provided by the services are defined in a standardized way,service discovery is greatly facilitated and thus reuse is much easier since po-tential service providers can be found with ease.

It is obvious that the reuse potential presented by SOA provides many ex-citing prospects for software development. Naturally, attaining perfect ser-vice interoperability is hard. Brown and Johnston have compared SOA withcomponent-based development and the reuse aspects of both in [BJK03] andconclude that SOA offers a number of benefits but requires the designers andimplementers to be familiar with the new technology and design specificallyfor SOA. Since software development is increasingly expensive and is still quiteerror-prone, new means for reuse are certainly interesting. Thus, SOA may pro-vide a new tool for building applications faster and cheaper.

2.3 XML concepts

In the field of SOA, Web services and many WWW technologies, XML and asso-ciated technologies play a key role. XML is a markup language for describingdocuments in a text-encoded form. XML documents consist of elements, whichmay be nested, and they may have attributes associated with them. Elementsalways have an opening and closing tag and the data or additional elementsare contained between the opening and closing tags. Because of this, elementsare often referred to as “tags” in more informal circumstances. It is importantto note that XML defines the format and encoding of the data and not the struc-ture or semantics of it. There are two versions of XML in use, versions 1.0 and1.1. The changes are relatively minor and XML 1.0 is sufficient for the majorityof needs. See [BPSM+04a] and [BPSM+04b] for further reference.

XML documents are usually bound to one or several namespaces. The pur-pose of the namespaces is to define specific vocabularies to identify differentelements and attributes in an XML document. An element can be bound to anamespace, which makes it possible to identify what the element or its sub-elements refer to. This is important, since different namespaces may containelements with the same name, thus making combining data from these name-spaces ambiguous. Using the namespace mechanism, elements in a combineddocument can be identified to associate with a specific namespace. However,unnecessary sue of this mechanism should be avoided so as not to unneces-sarily complicate the document definitions and structure. See [BHLT04] forfurther reference.

In order to enable data exchange using XML, mechanisms for defining dif-ferent data formats are needed. This is done using schemas, which describe thestructure of the XML document. Traditionally, Document Type Definition (DTD)was the schema definition language of choice, but it is being superseded by theXML Schema Definition (XSD) (“W3C XML Schema”) and the Regular Languagedescription for XML Core, New Generation (RELAX NG) definition languages.Schema definition is discussed in more detail in Section 3.1.

17

Using schemas and namespace definitions, XML documents can be vali-dated automatically to test them for conformance to the document definitions.This is particularly important to be able to ensure interoperability.

There are several XML-based languages and data formats related to Webservices and several standard tools for processing XML available. These will bediscussed throughout this document.

2.4 XML handling considerations

SOAs are based on loose coupling and open, transparent communication inter-faces. To achieve these goals, the dominant choice for building SOAs has beenthe use of XML technologies for data transfer. Consequently, tool support forbuilding SOAs must be based on XML handling capabilities. As described inSection 2.3, full use of XML requires the knowledge of several different dataformats and specifications. However, the typical uses in data processing aremost dependent on having basic XML parsing capability in order to be able toretrieve the relevant data from an XML document. Different APIs for parsingXML are discussed in the following section.

In typical data transfer and in XML handling in particular, the ability to con-veniently do string manipulations usually helps the programming effort bya significant amount. The ability to have string objects supporting Unicodecharacter sets with easy to use syntax along with native support for regularexpressions and other string functions makes string handling easier for theprogrammer and the gains in productivity and reductions in error rates shouldnot be overlooked.

String handling requires fairly much work in C++, in particular becauseUnicode support tends to be a fairly new feature but also because the way ofimplementing strings and native library support differ between implementa-tions. Symbian C++ makes no exception to this, with string handling beingmuch more tedious and error-prone than in Java. Dynamic languages tend,by their nature of being oriented towards high-level tasks, to have good stringsupport. Python makes no exception to this with a very easy to use syntax andnative regular expression support, the only negative side being that Unicodesupport depends on how Python is configured at the interpreter’s compile time[vR05, chapter 3.2]. Java has platform-independent Unicode support [GJSB05,chapter 3.1], but due to its string literal syntax, using regular expressions isharder than in Python. In Python, string literals can be defined in several ways,including both single and double quoting, whereas both Java and C++ onlysupport double quoted string literals. This is not only relevant for regular ex-pressions, which frequently use the backslash (“\”) character for escaping reg-ular expression wildcards, but also for low-level XML, where element attributevalues are surrounded by double quotes. Naturally, higher-level libraries re-move the need to write raw XML by the developer, but on mobile devices, suchhigh-level libraries might not be available.

2.5 Frameworks for parsing XML data

XML processing libraries are generally required for two different uses when im-plementing SOAs: for processing raw XML and for implementing the Web ser-vices libraries that implement SOAP and possibly other communication func-

18

tionality. It should be noted that by using the Web services model using SOAP,the application developer does not necessarily need to touch any XML at all,unless the application being developed uses XML as an internal data format.Similarly, XML libraries are not required for implementing SOAP or any otherhigh-level functions when the SOA is implemented as a REST based Web service(see Section 3.5, page 27), but the XML libraries are instead needed for handlingXML directly.

Since XML began gaining popularity in the late 1990s, the need for commonXML parsing APIs and libraries have become evident as no one wants to reinventthe wheel. A number of schemes have been proposed and four main styles forhandling XML have emerged. The main styles are the event-based push, event-based pull, tree and data-binding models [Har03b]. The event-based mod-els are streaming, which means that they can operate incrementally on a datastream, whereas tree models require that the entire data structure is in mem-ory before processing can commence. Event-based push models scan and parsethe incoming XML stream and perform callbacks when certain events, such asa new element, are encountered. This behaviour is somewhat similar to theObserver design pattern (documented in [GHJV95]) [Har03a]. The pull modelrequires requesting the tokens that the parser creates from the stream, makingit more similar to the Iterator pattern (documented in [GHJV95]) [Har03a] andit closely resembles the interface provided by lexers generated by the popularlex program.

Push based APIs are more dominant than pull based. The most popularpush API is Simple API for XML (SAX), which was originally made for Java, buthas since been implemented in a number of languages [SAX]. Pull based mod-els have evolved more slowly, with XMLPULL having mostly been a proof ofconcept API and implementation [Har02], until Streaming API for XML (StAX)began to be mature around 2003 [Har03a]. StAX is defined in JSR-173 [JSR03]and despite not being as popularly implemented as SAX, it seems as a techni-cally viable alternative for parsing XML documents.

Tree based models build a document tree out of the XML document, thusrequiring the entire document to be loaded into memory before data process-ing by the application can commence. Thus, the memory requirement is sig-nificantly higher for tree-based models than it is for event-based ones. Han-dling large documents will require a fair amount of overhead for process-ing the data into a tree, whereas an event based framework can, if the ap-plication domain allows, start to display results as soon as the start of thestream is parsed, leading to a potentially better user experience. The mostpopular document tree XML parser interface is Document Object Model (DOM)[ABC+98, HHW+00, HHW+04], which is, along with SAX, one of the most pop-ular XML parsing APIs. However, DOM has been criticized, one main reason be-ing that it is not fully object oriented [Har03b]. In part due to this, other treebased APIs have been developed, among them JDOM [JDO] and XOM [XOM].

From a mobile device point of view, processing speed and especially mem-ory consumption are of high importance. The programming interfaces shouldbe easy to use, but it should also be possible to implement them in a relativelysmall amount of space, as both fixed and dynamic storage spaces are quite lim-ited on mobile devices. Event based frameworks are far better than tree basedin terms of runtime memory usage and can be implemented in a small amountof space. This can be seen as one of the main design decisions behind JSR-172,discussed in Section 3.9, page 34.

19

3 SOA and Web service implementation

In this chapter, the currently used implementation techniques for SOAs are dis-cussed. The focus is on the traditional model of Web services, using SOAP fortransferring data, WSDL for describing the services and Universal Description,Discovery, and Integration (UDDI) for service discovery. In order to evaluateservice description, the current status of XML schema description languages isdescribed. The description of the traditional Web service model is augmentedwith a description of the REST architecture and the use of the REST model inbuilding SOAs. The issue of underlying protocol stack is taken up with con-sidering how Web services implementations need to interact with lower levelprotocols, in particular HyperText Transfer Protocol (HTTP). Finally, a brief de-scription of the Java ME Web services specification, JSR-172, is made.

3.1 XML schema definition

XML was designed to provide a simple, logical structuring to documents. In away, it can be considered to be a common alphabet in which XML processors cancommunicate. In order to describe documents, some form of structure must beimposed on them, as noted in Section 2.3. To fill this need, various XML schemalanguages have been developed.

Originally, XML structure was defined in the DTD format, which was inher-ited from Standard Generalized Markup Language (SGML) [CEM03]. DTD isrelatively simple, offering only a limited set of data type support, structuraldefinition and it does not support namespaces [LC00, vdV01]. Furthermore,DTD syntax is not XML, which necessitates understanding its syntax in additionto that of XML and it also means that XML tools cannot be used to manipulate orparse DTD. In addition to the listed reasons, Lee and Chu consider XML basedsyntax to be desirable because the schema can then be stored in an XML storagesystem and the schema language is extensible as XML is [LC00].

To extend the features of DTD, a number of schemes have been proposed.Lee and Chu compared six different languages in [LC00], of which three (DTD,XML Schema and Schematron) are still viable today. Eric van der Vlist did amore recent comparison, comparing some of the features between DTD, XMLSchema, RELAX NG, Schematron and Examplotron in [vdV01]. As Lee andChu observed in [LC00], schema languages could be roughly divided intotwo camps, the first one being the grammar-based, definition- and structure-oriented camp, of which DTD and XML Schema are typical examples, and thesecond one being the pattern-based, validation- and constraints-oriented camp,of which Schematron is the typical example.

Recognizing the need for a more powerful schema definition language thanDTD, the W3C came up with XML Schema [TBMM04, BM04], which has been arecommendation since 2001. XML Schema is a fairly complex and verbose lan-guage, which features a fairly powerful data typing system and much betterstructure definitions than DTD. Lee and Chu note that while DTD supports 10built-in types, XML Schema supports 37 [LC00]. Similarly, XML Schema sup-ports practical features such as explicit null values, user-defined types, un-ordered element sequences, occurrence bounds and namespaces [LC00]. SinceXML Schema is the W3C recommendation, it has been gaining vendor supportsteadily.

20

Despite having a number of useful features that the DTD format does nothave, XML Schema is not entirely without criticism. A point that Bex et al. makeis that even in 2004, not too many of the advanced features in XML Schema seemto be in real world use [BNdB04]. In particular, datatype definitions are madeuse of, but the structural definitions in actual use are relatively simple, whichBex et al. rightly point out that it could be due to knowledge of the new featuresnot yet being very widespread or the level of sophistication in XML Schema isunnecessarily high for real-world applications [BNdB04]. Whatever the rea-sons are, it should be noted that XML Schema has tried to reconcile severalcompeting formats and suggestions, which makes it a compromise in terms offeatures [CEM03, vdV01].

Entirely different approaches to schema definition have been proposed,most notably RELAX NG [CM01] and Schematron [Jel02]. Schematron is a rule-based language that can be used to write rules for checking structure anddatatypes. Lee and Chu point out that it is a language focusing on validatingschemas, rather than defining schemas [LC00]. Thus, as van der Vlist pointsout in [vdV01], Schematron could be combined with XML Schema, so that thedatatype and structure definitions of XML Schema and the rule definitions ofSchematron would be used. This would make for an interesting combination,as XML Schema is notably rigid in its structure definitions.

RELAX NG attempts to be easier to understand and has more powerful fea-tures for expressing constraints and structure than XML Schema. These featuresmake it possible to express a larger number of document structures in RELAXNG than in XML Schema [vdV01]. RELAX NG does not define datatypes; instead,it can be used with external datatype definitions, such as those of XML Schema,defined in [BM04]. RELAX NG is fairly verbose, due to which James Clark hasalso specified a compact syntax for RELAX NG [Cla02], which however is notXML. In certain circles, RELAX NG has gained popularity and it has also beenmade into a standard, ISO/IEC 19757 [RNG02], but wider popularity is yet tobe seen, especially since XML Schema is recommended by the W3C.

In comparing schema languages, one will observe that there is no languageclearly superior to others. Instead, a number of good ideas have been pro-posed, which manifest themselves in different languages. With this background,a language mix and match approach that van der Vlist suggests [vdV01] soundstempting, but it has some problems for developers in terms of tool supportand additional skills required. However, these problems can be mitigated ifconversion tools are used, such as those mentioned in [Cow03]. Schema lan-guages have a significant role for the description of data transfer formats inlarge scale Web services, which we shall see when discussing WSDL and Webservice design.

3.2 SOAP

SOAP is a protocol for exchanging structured information in a decentralized en-vironment [GHM+03a]. Originally named Simple Object Access Protocol, thename was changed to simply SOAP by version 1.2. As Mahan notes, while theprotocol can be defined as simple based on the fact that it attempts to solveonly a limited set of the issues of distributed computing, it is not particularlyobject-oriented [Mah04a]. In fact, SOAP was originally designed as an imple-mentation for RPC to operate over the Internet, but soon wider usage scenarios

21

were envisioned. Don Box outlines a brief history of SOAP in [Box01], fromwhich it is worthwhile to note that progress was rapid until 2001, after whichSOAP has been fairly stable. Thus, there are a number of fairly mature imple-mentations around for different programming languages. Indeed, Rich Salzargues that the currently most widely implemented standard versions shouldbe frozen as the “Web service core”, since they are relatively stable, relativelywidely implemented and they demonstrably work [Sal05].

SOAP has not evolved much from version 1.0 to version 1.2. The most com-mon version in use is still 1.1 despite 1.2 having been a W3C recommendationsince 2003. Some of the differences between these two versions will be dis-cussed shortly. Closely related to the development of SOAP was the develop-ment of a metalanguage, later to become WSDL. While SOAP is the protocol inwhich Web services may communicate and a schema language is used to de-fine the structure of the data to be sent, WSDL is used to describe the serviceinterfaces and SOAP message encoding.

SOAP is a stateless protocol, with the SOAP messages themselves being validXML. A SOAP message consists of an envelope, which contains optional headersand a mandatory body. The envelope must be scoped to a namespace, whichdeclares which version of SOAP the message corresponds to [Mah04a]. Thebody element inside the SOAP envelope contains the information itself that istransmitted. The information is encoded based on the WSDL specification forthe given service, discussed later in this chapter. A core concept is the bindingof SOAP into an underlying transport protocol, with SOAP being protocol neu-tral, but usually being sent over HTTP. Binding will be more closely discussedin Section 3.7, as it requires some understanding of REST and WSDL.

The optional headers are used to pass ancillary or control information aboutthe message; typical applications include handling transactions, authenticationand load distribution. The Web Services Interoperability Organization (WS-I) has defined several different usage models, commonly referred to as WS-*,which define common message exchange patterns and header use for certainuse case scenarios, such as transactions, that are intended to improve inter-operability between various implementations. The W3C SOAP Primer [Mit03]demonstrates a fictitious but canonical example of doing ticket reservation us-ing SOAP. In this example, headers are used to identify the user and the pre-vious message to which the current message relates. Another use of headersis as processing instructions for intermediaries, such as caching instructions[Mah04a].

In order to support sending binary information with SOAP, an attachmentmechanism for SOAP has been devised [NR04]. Naturally, binary informationcan be encoded as a part of the SOAP message, but it presents a burden for theXML processor and consumes a fair deal of bandwidth in encoded form. Toovercome this, the SOAP with attachments mechanism was developed, whichsends the SOAP message and its attachments using Multipurpose Internet MailExtensions (MIME) multipart technology [Mah04a], in a similar manner as pop-ular e-mail.

Security is a common concern for all network technologies, not the leastfor SOAP, which is designed to operate on highly distributed networks such asthe Internet, where there might easily be third parties interested in compromis-ing the data. SOAP can be encrypted by encrypting and securing a lower levelprotocol, such as with using HTTP with Secure Sockets Layer (SSL)/Transaction

22

Layer Security (TLS). However, there is a significant drawback to these ap-proaches, which is that for the header processing by intermediary nodes, as de-scribed above, the message must naturally be decrypted so that the headers canbe understood. To solve this issue, major software companies have worked outat the Organization for the Advancement of Structured Information Standards(OASIS) the SOAP Message Security specification, which addresses these prob-lems, with further work being done by the WS-I Basic Security Profile workinggroup [Mah04a]. These specifications add significant complexity to the secureprotocol implementations. Because radio communications must be encryptedanyway and in many situations the service that is to be used would be pro-vided by the network operator itself, secure SOAP is not always necessary formobile use, even when passing data that might normally be encrypted on aninsecure connection. Due to the significant complexity of mobile security, it isnot investigated in this thesis.

Don Box notes that the evolution of SOAP was strongly tied to the devel-opment of schema languages, particularly the development of XML Schema atW3C [Box01]. The main motivation for this was the common definition of use-ful datatypes. In SOAP, the information to be sent is in XML form and is encodedin a predefined way in order for the recipient to be able to interpret the datacorrectly. Since SOAP is not tied to any particular programming language orenvironment, the type system must support a common set of datatypes usedin major programming languages. For encoding typed data, SOAP 1.1 defineda set of datatypes and corresponding encoding to support RPC style procedurecalls over the Internet, which are called “Section 5 encoding” [Mah04a]. Thealternative to “Section 5” encoding is to use XML Schema encoding, which usesdatatypes defined in XML Schema [BM04] for encoding the typed data in a SOAPmessage [Mah04a]. The encoding rules are set by using the encodingStyleattribute in a SOAP message, which is usually set for the entire message, butcould be set for subcontainers separately. Don Box notes that better array andstructure types than what were available in XML Schema would have been use-ful [Box01], as these are very common and often needed constructs in morecomplex service interfaces.

Due to some room for interpretation present in earlier specifications, theWeb service software market was soon full of software that was not quite inter-operable. In order to unify the use of SOAP from different software makers, WS-Icame out with the Basic Profile (BP) definition. BP defines a set of technologiesto use and not use, for example, “Section 5” encoding is deprecated in BP infavour of XML Schema encoding.

While SOAP 1.1 remains the most common version, the specification for 1.2has been finalized for quite some time. On a conceptual level, the differencesare fairly significant, but on a practical level they are minor. A compact listof changes is presented in [Mit03, Section 6]. One significant conceptual dif-ference is on the reliance on XML Infoset [CT04] for defining the protocol inversion 1.2 instead of using XML document syntax, the implication of this beingthat the information of a SOAP message can be mapped to an arbitrary transportprotocol [Mah04a, Sal03]. More minor, but in practice significant changes, arethe SOAP specific media type of application/soap+xml and the omissionof the SOAPAction header from the HTTP binding [Sal03]. Version 1.2 definestwo new roles (named actors in 1.1) for headers that target SOAP processingnodes in the message path, as well as clearing up some ambiguities in header

23

processing [Sal03]. Finally, fault processing has been updated, fault messagescan be multilingual [Sal03] and the way SOAP is bound to HTTP has been devel-oped to a somewhat clearer direction [Mit03].

As already hinted earlier, there are two fundamentally different ways ofusing SOAP, namely RPC style and document style. RPC style is older, beingbasically just an extension of traditional RPC to work over the Internet, whiledocument-style is a newer way of use. Below, the different strengths and weak-nesses of these styles are explained

3.2.1 RPC over the Internet

RPC refers to a mechanism to be able to call a procedure over a network just asthe procedure would be a regular procedure in the current program, runningon the same computer as the caller. This has proved very popular in LANs dueto the simplicity of programming and good separation of application and net-work logic. However, over a large, heterogeneous Wide Area Network (WAN)such as the Internet, the disadvantages of the RPC model gain more promi-nence. Traditionally, procedure calls pass relatively small amounts of infor-mation to the callee, with the callee returning a single value based on the call.This works well inside a single program, since passing few values decreasesdependencies versus passing a large number of parameters, and call overheadis fairly manageable. In a heterogeneous network, call overhead may rise byseveral orders of magnitude, both in the form of communication latency andin bandwidth requirements. Furthermore, in traditional RPC implementations,one party typically writes both the client and server implementation, often inthe same language. For a SOA, the requirement is for well-defined, public in-terfaces, to support the fact that service providers and consumers are oftenwritten by different parties. Finally, any kind of pointer type can obviouslynot be passed and even general types need to agree on a common structure,hence the SOAP requirement of being able to define structures and arrays. Im-plementing true, platform independent object-oriented programming over aheterogeneous network and doing it well is still a significant challenge, whichin practice restricts protocols such as SOAP to operate on more traditional pro-cedure calls, only passing and receiving data, not objects. Hence the notionthat SOAP is not actually object oriented.

An important issue to note with RPC is the dispatching of operations. Someprogramming languages support overloading, which can create additionalproblems in dispatching remotely. Due to this, WSDL 2.0 doesn’t support over-loading at all and if version 1.2 is used, care must be taken to get everythingworking as intended. On the other hand, overloading is a common feature inmany object-oriented languages, which may make describing their interfacesin WSDL 2.0 non-trivial. Characteristic of SOAP is that the name of the calledmethod may be passed in the SOAP message or it may not, depending on thebinding mode in the WSDL description.

RPC works well in simple applications, which naturally follow a request-response communication pattern. The canonical Web service example, thestock ticker, works largely in this way: a call is made, passing the stock symbol,and a return value in form of the stock value is received. However, it would befar more desirable to solve much more complicated problems with SOAs, andthose typically require complex data types and messaging patterns.

24

3.2.2 Document-style use of SOAP

The document style use of SOAP is newer than the RPC use. At first, the differ-ences seem minor, but the distinction is architecturally important and is basedon sound theoretical ideas. Document style usage is based on transmitting en-tire documents between participants. The participants are supposed to analysethe documents and act accordingly, for example filling in parts of the documentand returning it, producing a new document based on it and returning the newdocument or simply updating system status based on it. The main strengths ofthe document-based model is that it is coarse-grained by design, reducing thequantity of messages sent between the participants and thus reducing latencyimpact and the fact that sending complete documents removes the dispatch-ing problems of the RPC model, introducing a more REST-like approach to SOAPimplementation (see Section 3.5 for a description of REST).

In addition to the benefits mentioned, McCarthy identifies four distinct ben-efits of document style [McC02]:

Supports XML data Unlike RPC style, the data itself can be XML in document-style, without the need to be escaped.

Does not require a rigid contract RPC mandates rigid procedure interface de-scriptions, while document style permits changing the document struc-ture without affecting dispatching or the service contract.

Suits asynchronous processing better Asynchronous communication can bedesirable in a SOA. Per definition, RPC mandates a synchronous commu-nication pattern, while asynchronous messaging is much easier to designand implement with a document-style service.

More flexible object exchange Objects (or documents) can be exchanged with-out binary or implementation compatibility, as long as a common dataexchange format is agreed upon.

Naturally, document-style services tend to have some overhead in the trans-mitted data. This is because not all parts of the document sent are necessar-ily needed for each service operation. However, this issue can be mitigatedby careful document format and service interface design, aiming to keep theamount of overhead low at least for the most popular services.

3.3 Service description: WSDL

In order to define service interfaces, some agreed convention is required. Thepredecessor of SOAP, the XML-RPC protocol, uses plain English for service def-initions. CORBA, which is very common for middleware communication anddistributed computing in corporate environments, uses Interface DefinitionLanguage (IDL) for describing the interfaces of the systems. In order to be ableto define the interfaces of Web service providers, Microsoft and IBM developedWSDL, defined in [CCMW01], which was then submitted to the W3C [Mah04a].SOAP and WSDL go hand in hand as the protocol and the interface definition fora Web service, but WSDL can be bound to other protocols than SOAP. The WSDLspecification defines bindings for SOAP, HTTP and MIME [CCMW01].

25

WSDL does not define service semantics, but it does define the interfacepoints themselves, the locations of the interface points and the message datastructure and data types. This is done by the three different parts of WSDL: mes-sage data, operations and bindings definitions [Mah04a]. Message data refersto defining the structure and data types of the message, using either the en-coded (SOAP “Section 5” encoding) or literal (XML Schema datatype encoding)encoding style, as discussed in Section 3.2.

Port type refers to the set of abstract operations that can be performedon the service, with each operation defining input and output messages[CCMW01]. In WSDL 2.0, port type is actually renamed to interface, whichmakes the terminology a bit more intuitive. WSDL defines four operations[CCMW01]:

One-way The endpoint receives a message

Request-response The endpoint receives a message and responds to it

Solicit-response The endpoint sends a message and receives a response

Notification The endpoint sends a message

In WSDL, these are supported by specifying appropriate inputs and outputsand specifying the message formats that they are to use. For RPC style messag-ing, a parameter order may additionally be specified for each operation.

Bindings define the binding of the messages and their operations to a con-crete transport protocol and thus also the location of the service. It is impor-tant to note that message data and operations are completely abstract and thusprotocol-independent and only the bindings define how these are realized ina concrete protocol. Thus, WSDL is quite extensible, with the possibility to addnew concrete bindings.

In Section 3.2 it was discussed how Web services can be used in two differ-ent communication styles, RPC and document-style. Somewhat related to thisis the concept of WSDL style, which can be either RPC or document. In additionto this, there is the choice of encoding as discussed earlier. Thus, the WSDL def-inition can be rpc/encoded, rpc/literal, document/literal or document/literalwrapped [But03]. Butek provides an excellent description of the strengths andweaknesses of each style in [But03]. The document/literal wrapped style isvery similar to document/literal, with the difference being that the methodname in the SOAP body is that of a wrapper in the wrapped-style, with thewrapper bound to an operation of the same name [But03]. Unfortunately, thewrapped style is not defined in any specification [But03].

Butek notes that the style of the WSDL definition itself does not in any waymandate using a certain communication pattern. Instead, the choice of WSDLstyle can be regarded as an independent decision based on the relative meritsof the different styles.

The current version of the WSDL specification is 1.1, which is quite well es-tablished in the Web service community. Version 2.0 is currently being final-ized by the W3C. However, strong criticism has been directed towards earlierversions of this specification, among others by Salz in [Sal04], with well over200 issues about the specification proposal registered to the W3C. Salz explainssome of his main criticisms with the specification proposal in [Sal04], including

26

the lack of defining a formal syntax, defining a new data model and restrict-ing one service to one interface (port type). Some of the complaints have beenaddressed, but the long process of finalising the specification along with therather high number of issues and some objections raised, do warrant the ques-tion of what the fate of version 2.0 will actually be.

3.4 Service discovery

A widespread adoption of public Web services over the Internet requires theusers to be able to find and access the services. Consequently, service discoveryis a key concern. The situation is somewhat analogous to the WWW, wheresearch engines are playing an increasingly important role in finding documentsof interest. Clearly, technologies for enabling this in the Web service space areneeded.

Traditionally, UDDI has been the technology to enable service discovery.UDDI is based on a registry that stores metadata about the services offered,along with business metadata about the service providers [Mah04a]. UDDIworks as both an intra-enterprise discovery solution as well as an inter-enterprise one, but a key point is that it requires the service requester to knowthe API of the service requested beforehand. Alas, no semantic description fea-tures are present, as these would essentially require the deployment of the se-mantic web first.

WS-I has attempted to help service discovery by developing the Web Ser-vices Inspection Language (WS-IL). WS-IL describes a decentralized discoverymodel that can cooperate with UDDI registries [Mah04a]. It attempts to describehow a service provider exposes its offered services [Mah04a]. The key conceptis inspection documents, which are XML documents referring to a provider’savailable service descriptions, i.e. typically descriptions in WSDL format. WS-ILspecifies how the introspection documents are defined and how they can beretrieved from the service provider.

3.5 REST and WWW architecture

REST refers to the fundamental architecture of the WWW. The name was coinedand the architecture explained in Roy Fielding’s doctoral thesis, [Fie00]. REST isa network architecture that combines elements from several other architecturesand it has been developed in a somewhat pragmatic way to fulfil the needs ofthe WWW.

The key constraints of REST are according to Fielding [Fie00]:

Client-Server The network is based on a client-server architecture, with mul-tiple clients and servers.

Statelessness The protocol is stateless, which simplifies the system since theserver does not need to keep a record of client states.

Cacheability The communication is mostly cacheable, which can be used toimprove performance and for load balancing.

Interface uniformity The interfaces between clients and servers are uniform,so that implementations can be decoupled from the services that they

27

provide and clients and servers can be evolved independently from oneanother.

Layered system The system is layered so that each layer operates indepen-dently of the other layers and need not be aware of how other layerswork.

Code-on-demand Client functionality can be extended dynamically by down-loading executable components, for example JavaScript and ActiveX. Itshould be noted, though, that this constraint on the REST architecture isoptional, since arbitrary code cannot be expected to work on every clientin a heterogeneous network.

It is worth to note that Fielding identifies both advantages and disadvan-tages with these constraints. However, aspects such as statelessness combinedwith cacheability and interface uniformity make REST very scalable and easyto implement. In practice, statelessness eases client and server implementa-tion considerably, while the drawbacks mostly affect complicated WWW appli-cations. Statelessness does not support transactions, so Web services, whichrequire transaction support, must extend the REST model.

The REST model has been further formalized by the W3C [BLBC+04] and thetask of the Technical Architectural Group (TAG) is to further work on formal-izing and developing the WWW architecture. The W3C has published a recom-mendation titled “Architecture of the World Wide Web” [BLBC+04]. In thisrecommendation, Berners-Lee et al. identify three key aspects of the architec-ture of the WWW, which are as follows:

Identification Distinct global Uniform Resource Identifiers (URIs) identify dis-tinct resources on the WWW

Interaction Agents have many ways of interacting with a server, typically toretrieve a representation of a resource. A resource that is identified by anURI can be shared and linked to.

Data formats Using well-defined, widely available data formats informationcan be shared easily. Data formats may be text or binary encoded data,but they must be documented. In order to support further evolution,formats should be associated with some version of the format specifica-tion and the format should have some mechanism, such as an extensiblenamespace, for dealing with future feature additions.

An important point about REST is that the key aspects outlined above areorthogonal in the context of REST and the WWW. Consider that HTTP head-ers can be used to specify the content type of the encapsulated data, as de-scribed in [FGM+99]. The content types themselves are defined separately andmaintained in a registry by Internet Assigned Number Authority (IANA) [Med].Thus, the content types themselves may be developed separately from the HTTPspecification, allowing content types to be added without modifying the un-derlying protocol. Similarly, the Internet naming mechanism consisting of URIsneed not know anything about the interactions that are performed using URIs.This principle of orthogonality has thus wide implications for the further evo-lution of Internet protocols, as new technologies constantly emerge requiringold technologies to adapt.

28

Both Fielding and the W3C identify resources and representations as thecore concepts of the REST architecture. The term “resource” may refer to anykind of distinct piece of data. However, in the context of the WWW and Webservices, we restrict ourselves to discussing information resources. An infor-mation resource might be a textual document or a photographic image. Therepresentation of the resource is the information that the resource representsencapsulated into some sort of data format; for example, a textual documentcould have a representation in XML form, naturally associated with some well-known schema, as described in Section 2.3. As described above, HTTP, whichis closely associated with REST, permits the encoding of the content type in themetadata (headers) of the message. This implements the REST model: the clientdoes not know the internal representation or nature of a resource, but it needsto know how to render the different content types in which a representation ofthe resource is provided by the server.

It is important to note that when representations of two resources are iden-tical, it does not imply that the two resources they represent are, in fact, iden-tical. Rather, the two representations mentioned are merely identical for theresources they represent at that given point in time. No guarantees are madefor another set of representations of the aforementioned resources to be identi-cal or for the two original representations to remain identical at another pointin time.

In order to be able to provide clients with representations that they canunderstand, the protocol implementing REST needs some mechanism for con-tent negotiation. There are several schemes for performing content negotiation,even when using HTTP alone [GT02]. Content representation and negotiationhave a significant impact on Web services and constructing SOAs using RESTarchitecture, as we shall see later on.

3.6 REST based Web Services

The term “Web Services” has been nearly synonymous with using SOAP as theprotocol and WSDL as the description language for implementing Web services.In recent years, however, criticism has been expressed in several articles onthe WWW of the drawbacks and problems in using SOAP, [Asa02, Prery, Cos03,He04]. The main targets of the criticism are the complexities of SOAP and WSDL,the significant overhead of using SOAP over HTTP and the way SOAP breaks theREST model, particularly in SOAP 1.1. However it should be noted that SOAP1.2 can, if desired, be used according to REST, which will be discussed in Sec-tion 3.7. Consequently, many have advocated the development and use of RESTbased Web services. It should, however, be noted that SOAP based Web serviceshave been moving towards REST, so the distinction is not as clear as it used tobe.

The term “REST based Web service” is somewhat misleading, since it doesnot actually tell us anything about the actual protocols and data formats useand is thus a very general concept. Indeed, as Fielding points out in [Fie00,page 100],

REST does not restrict information to a particular protocol, butit does constrain the interface between components, and hence the

29

scope of interaction and implementation assumptions that might beotherwise be made between components

Thus, REST based Web services could be made with virtually any protocolfor communication and any data formats that fulfil the REST criteria as laidout by Fielding and the W3C. In practice, however, REST based Web servicesseem to use HTTP as the transport protocol, as it is ubiquitous and provides therelevant REST facilities. A closer look at HTTP and the facilities it provides forimplementers of SOAs is given in Section 3.7, page 31.

While HTTP can be seen as some sort of de facto standard for the transportlayer protocol for REST based Web services, the definition of data formats to beused is not quite as evident. The use of XML as the base markup language isquite common, in part due to the wide availability of mature XML processingtools. However, as mentioned in Section 3.1, the choice of a schema languageis not obvious and neither is the choice of means for defining the exact syntaxand semantics of service interface. There are a number of software tools to sup-port a multitude of technologies, but coexisting technologies place the burdenon the developer to learn and use different technologies. Another drawback isthat not all technologies might be supported on the mobile platform that is go-ing to be used and certainly not all tools are factory preinstalled on mobile de-vices. Thus, it would be desirable to restrict Web services to a set of simple yetpowerful technologies. For the sake of argument, the REST Web services nowconsidered will use XML over HTTP for data transmission, free-form format, ser-vice and interface descriptions and defined namespaces, with the possibility touse a schema language for defining the data to transfer if so desired.

Since REST is an architecture, not an implementation as the Web servicesthat were defined earlier, the term “REST based Web services” merely reflectsthat the services should be compliant to the REST architecture. While thereare advantages of binding SOAP to an underlying, fundamentally REST-orientedprotocol (HTTP) in a way that tries to preserve REST characteristics, it does notnecessarily provide benefits to restrict new service implementations to conformstrictly to REST. Furthermore, a clear set of implementation technologies to use,as is the case with Web services, would be highly desirable for developers.

The definition of REST essentially mandates the use of document-style Webservices, as RPC-style would require a clear set of protocols to define the call-ing behaviour and for describing the interfaces offered. However, REST advo-cates typically see this as a positive aspect [He04, Mah04a, Ude04], as it pro-motes larger granularity reducing the impact of network latency, although it in-creases bandwidth requirements, and, more importantly, because technologiessuch as CORBA and DCOM have failed on the Internet scale and are in practiceconstricted to private networks [Mah04a]. The REST architecture for buildingdocument-style Web services may well be made to fit into the definition of SOA,and some popular WWW sites can indeed be considered to be services with de-fined interfaces.

The REST Web services have a few advantages compared to SOAP, but alsodisadvantages. Due to the popularity of the WWW and XML, tool support isgood and the basic technologies, such as XML and HTTP, are mature. Theo-retically, performance should also increase, as no SOAP layer is needed in theprotocol stack. The question of security comes up, as there is no elaborate se-curity framework as with SOAP, but in practice, SSL and IPsec can be used to

30

provide good security. The REST model also benefits from the existing HTTP in-frastructure, which makes it possible to use existing proxies and WWW caches.However, the lack of a clear, universal data format definition for the services tobe deployed may be a significant weakness.

Given that the separation between REST based Web services and Web ser-vices that do not require conformance to REST is narrowing, many technologiescan be shared between SOAP and REST based Web services. Due to the factthat REST based Web services are not clearly defined in terms of what proto-cols and specifications they use, it would be more clear if future discussion ofWeb services would refer to SOAP based Web services and SOAPless Web ser-vices. Since SOAP is no longer an acronym in SOAP version 1.2 [GHM+03a],this would even be grammatically feasible.

3.7 The Role of HTTP

In the rest architectures of today, HTTP [FGM+99] plays a prominent role asthe main transport layer protocol on the WWW. SOAP is designed as protocolindependent, but in practice, it is often implemented on top of HTTP. Thus, itcan be said that the ubiquity, maturity and simplicity of HTTP has made it a verypopular protocol for highly distributed applications that are not performancecritical.

The SOAP specification defines bindings to HTTP and e-mail, with the for-mer obviously being more popular. The relation between SOAP and HTTP hasbeen an interesting one. In SOAP version 1.1, all messages were sent using thePOST command in HTTP, which was criticised by REST supporters for misus-ing the protocol mechanisms. Consequently, the HTTP binding defined in SOAP1.2 makes use of GET and uses HTTP fault codes in a better way. A signifi-cant aspect in protocol binding is that SOAP 1.2 is, as mentioned in Section 3.2,represented using XML Infoset, which enables SOAP to map to virtually anykind of transport protocol as long as the Infoset is preserved. Features notsupported by the underlying protocol can be supported in SOAP using headerblocks [Mit03]. Another useful feature in SOAP 1.2 is the Web Method feature,which allows a SOAP binding to take advantage of all the Create, Retrieve, Up-date and Delete (CRUD) methods defined by the underlying protocol, or GET,POST, PUT and DELETE in case of HTTP [GHM+03b, Section 6.4]. These newfeatures in SOAP 1.2 do, in fact, enable a far more REST compatible approach tobuilding Web services.

3.7.1 Push and Pull

In terms of the different communication patterns offered by WSDL and some ofthe REST based services currently employed, it can be seen that there would beuses for push-based communication. Current approaches, which are mainlybased on HTTP, are strictly pull-based. This approach works very well formany services, such as retrieving Web pages, using search services or usinge-commerce applications. However, push-based services – where the serversends content to the client when the server sees the need – would be useful ina number of applications, such as delivering news, e-mail and RSS feeds (seeSection 5).

31

The idea of developing push-based services on the Internet is not new.Netscape and Microsoft tried to make content push a major feature in theirWWW browsers in the late 1990s, without too much success. More recently,push-based e-mail has gained a decent amount of popularity for mobile deviceusers, particularly with the BlackBerry product by Research In Motion. Black-Berry encompasses both phone-PDA and server software for pushing the user’se-mail directly to the device. Essentially, this makes e-mail messages work a bitlike Short Message Service (SMS) messages.

Push messaging is more useful in mobile devices than desktop computerssince the user is expected to have the device, powered on, with him all thetime. It can then be expected that the user would want to have a service suchas e-mail being pushed to the mobile device, particularly since SMS provides aprecedent in working that way. In contrast, a user will not be at a particulardesktop computer all the time and with a desktop computer, e-mail is typi-cally checked when the user logs on. However, push is certainly not withoutproblems. Consider that the user subscribes to a news service, only to growtired of it and forgetting to cancel the subscription when switching to a newmobile device and operator subscription, leaving the news service “pushes”to go nowhere. Thus, the server would need a policy of identifying when toend the pushing service to a client. Furthermore, for non-operator providedservices, a mechanism is needed for the server to determine where to push.Internet Protocol (IP) addresses of devices cannot be used, as these may wellbe dynamic, so obviously a system where the operator is involved is neededfor identifying the device or user. Finally, the question of cost is important, asservices such as e-mail do not have a payment system set up for the senderto pay, so in the most likely scenario the recipient pays for the bandwidth ofhaving messages pushed. This becomes a problem with spam, or non-essentialservices whose bandwidth requirements vary significantly, as the user wouldhave to pay for unneeded services. The push of content could also take up allnetwork bandwidth when the user might wish to use it for some other purpose.

RSS syndication is somewhat clumsy in that client software needs to poll theservers at frequent intervals for updates. However, the reasons given abovemake it fairly complicated to implement a syndication system based on pushmessaging. Since this situation applies to a number of applications, pullingcontent is probably desirable for most mobile device applications for the timebeing.

3.7.2 HTTP as a Web service protocol

SOAP tries to be transport protocol independent, but this has lead to some du-plication of HTTP features in SOAP for earleir versions of the protocol. Also, theprotocol stack is getting complicated, with a considerable number of protocollayers in use when a Web service request is made on a mobile device – theperformance penalty of this complexity is significant. This situation begs thefollowing questions: what features does SOAP offer that plain XML data overHTTP does not and what benefits does HTTP have as a SOAP transport?

While XML over HTTP has less overhead and is simpler to support than SOAP,the latter does have some features to its advantage. The clue lies with the WS-*profiles; SOAP can use special headers to support transactions, authenticationand sessions. It can be argued that all of these can be supported in HTTP alone,

32

but transaction support is contrived at best [Cow05], authentication implemen-tation and mechanism quality tends to vary and session support does largelyrely on security-wise unreliable cookies. Considering authentication, there isno standard way to authenticate a user using a certificate from a trusted source,as HTTP authentication relies on the server already having the identity informa-tion to match with the user [GT02]. Naturally, the seriousness of these prob-lems must be assessed for each case separately, as there are potentially manyservices, which do not make use of these features. For example, Hogg et al.note that there are effective workarounds for missing functionality in Web ser-vices when supporting transactions, but they also note that there are manychallenges when implementing transactions [HCNS04].

While HTTP is an extremely popular protocol, its popularity is largely basedon the popularity of the WWW and its simplicity, especially in earlier versions[GT02]. This simplicity means that there are no provisions for multicasting,reliable delivery or asynchronicity. To solve these issues, messaging systemshave been developed, which are described in Section 3.8. However, it shouldbe noted that the listed features lacking from HTTP are hard to implement; it isnot due to the lack of research that they are not commonplace on the Internet.Consequently, implementing these might not even be desirable for large-scalenetworks, so again, the designer of a service should bear in mind the targetaudience of the service and the technical limitations placed by the operatingenvironment. After all, HTTP is one of the few universal packet protocols that amobile device can be expected to support.

Finally, the choice of HTTP gives one advantage to service construction: con-tent negotiation. By good design and implementation, the HTTP content nego-tiation mechanism could be used to deliver SOAP or plain XML from the serviceendpoint depending on the preferences of the requester. Using this mecha-nism, the service implementer can thus reserve the right to change his mindabout data binding to the transport protocol if new requirements arise.

3.8 Messaging systems and middleware

In recent years, some major software providers have begun promoting messag-ing frameworks and entire middleware systems for implementing SOAs. Onequite popular messaging framework is Java Message Service (JMS), which is apart of J2EE [ABB+05]. The basic idea with messaging systems is to provide anasynchronous, loosely coupled and reliable network setup to connect severalnodes in a system. The idea is somewhat similar to SOAP used with document-style messaging, but SOAP is not in itself reliable. JMS essentially enables theintegration of messaging into J2EE applications and provides more powerfulfeatures than plain HTTP. The key aspects of JMS are reliability and asynchronic-ity. Taken together, they enable a node to send a message to another node andit may immediately resume processing without having to wait for a reply andit can be expected that the message has been delivered.

A JMS installation consists primarily of clients that can produce and con-sume messages and providers that implement the JMS messaging systems. In[ABB+05], there are two major communication styles listed that JMS must sup-port; point-to-point and publish/subscribe, which correspond to unicast andmulticast communication respectively. It is obvious that for such requirements,

33

the providers need to implement a relatively sophisticated logic in the form ofcaching messages and keep records on destinations and nodes on the network.

A more sophisticated and larger scale approach than JMS has been devel-oped by IBM and is called Enterprise Service Bus (ESB). While JMS defines animplementation of a messaging system, ESB refers to an entire architecture forimplementing a SOA using messaging systems and a service bus [EAA+04].An ESB is essentially middleware that handles the communication between thenodes in the network, transforming data and converting formats when nec-essary. The principal idea is to cure some of the shortcomings of basic Webservices, which include client modification when the service interface is mod-ified, the limitations of point-to-point communication patterns and the neces-sity of the client to have protocol adapters for each provider [EAA+04]. ESBsolves this by automatically transforming data and messages when necessaryand allowing other communication patterns than point-to-point. Service dis-covery and load distribution can be improved by using service brokers, whichthe requester contacts instead of the service itself to use the service [Woo05]. Inaddition, advanced features such as event notification can be supported in anESB [Woo05].

ESBs can be implemented using various tools, for example, WSDL could beused for service description and SOAP over JMS as the protocols for service mes-saging.

3.9 Web Services in Java ME: JSR-172

In a mobile device environment, several libraries are available for supportingWeb service technologies. Naturally, it would be most desirable to developagainst libraries which are preinstalled in the devices, so that neither the de-veloper nor user need to worry about installing the right library into the de-vice in order to run the Web service application. One such library which canbe expected to be widely preinstalled is the J2ME Web services 1.0 definition(JSR-172) [EY03], which defines a set of APIs for the Java ME platform. Despitebeing finalized in 2004, support for this specification is still relatively rare onthe market; for example Nokia’s Series 60 2nd Edition, Feature Pack 3 includesit, but phones installed with this OS version are still quite rare at the time ofwriting.

JSR-172 does actually consist of two independent APIs, namely a Java APIsfor XML Processing (JAXP) 1.2 subset and a Java API for XML-based RPC (JAX-RPC)1.1 subset. The specification mandates that the latter should not depend onthe former. JSR-172 targets CLDC 1.0 as the lowest common denominator with atarget size of 35 kB and as such, it does not offer any complex features, althoughit is worth to note that this is tiny compared to the capabilities of the higher endphones listed in Section 2.1.1.

The JAXP part of JSR-172 requires support for SAX 2.0 and XMLnamespaces, but forbids support for DOM and eXtensible Stylesheet LanguageTransformations (XSLT) [EY03], mainly due to runtime memory and process-ing requirements. These requirements seem fairly intuitive, due to the limita-tions of mobile devices already discussed. More interesting is that a validatingparser may be supported, but it is not required. Whether or not validation isneeded in a client implementation is debatable, but being optional, the pres-

34

ence of this feature cannot be relied on by developers, so if validation is re-quired by the application, then problems arise.

The JAX-RPC part is, as the name implies, designed to enable RPC calls us-ing SOAP from Java ME. An important point is that only client behaviour issupported, with the mobile device acting as a Web service provider seemslike a somewhat remote possibility at this time, although no technical obsta-cle for enabling server behaviour exists. The programmer’s view of the libraryis that upper level objects and methods from the interface abstract the net-work communication, with the library handles actual SOAP message creationand networking details. To make this possible, method stubs for calling theWeb service need to be created with a separate stub generator using the WSDLdescription of the service. Naturally, the stub could be done by hand, as it isJava code as defined by JSR-172, but generating it from the service descriptionis well suited for a software generator.

Implementations must generate stubs that use the document/literal modelof SOAP and they may only support the literal-style of encoding [EY03]. This ispractical, since it decreases complexity, but does on the other hand not supportusing some already existing services. Implementations are to be compatiblewith WS-I BP and the protocols that must be supported are SOAP 1.1 with HTTP1.1 binding [EY03]. Other protocol bindings are allowed, and the implemen-tation may support HTTP Secure (HTTPS), but does not need to do so [EY03].This does severely limit the ability to use Web services securely, as the soft-ware developer cannot rely on a particular device to have support for securityfeatures – unless security is implemented in lower-level protocols. The onlyrequired application level interaction mode is synchronous request-response[EY03], which is the communication pattern that RPC conforms to.

As the specification work has been done mostly during the years 2002 and2003, it can already be seen that parts of this API are getting a bit old, which isquite telling of how quickly the Web service field has advanced.

3.10 Web Services in Series 60 native environment

In Section 2.1.3 it was noted how the Symbian OS is the dominant OS on thesmartphone market and how Series 60 is the most common extension to Sym-bian OS deployed. Series 60 add not only UI features to Symbian OS, but also anumber of useful libraries for developers. Among these are the libraries, whichintend to make the development of Web services easier, namely the XML andWeb services libraries. The native language of the Symbian OS is C++, as notedin Section 2.1.4.

Symbian OS version 8.1a1 offers an XML interface to a parser that constructsa DOM tree from XML data. This interface was designed to provide supportfor the Synchronized Multimedia Integration Language (SMIL) format, whichis mainly used as a data format for Multimedia Messaging Service (MMS) mes-sages. However, it also works as a general DOM implementation. Additionally,the parser can, if desired, validate the data against a DTD. [Sym]

Series 60 3rd Edition adds some useful libraries for developing Web ser-vices. Specifically, it adds a SAX parser and libraries for handling SOAP mes-

1Even though the version of Symbian OS discussed here is 8.1a, Series 60 3rd Edition requiresSymbian OS version 9.1. However, the newer version does not change the XML functionality

35

sages and support for the WS-I BP and Identity Web Services Framework (ID-WSF) frameworks [Nok]. The ID-WSF framework is somewhat analogous to theWS-I BP frameworks and WS-* profiles. It is defined by the Liberty alliance [Lib]and defines a set of specifications, which an implementation must conform to.The included specifications are mainly defined by the Liberty Alliance itself.These specifications cover similar things as the WS-I BP, but with a special em-phasis on user authentication, secure messaging and non-UDDI based servicediscovery (see [KCVG+04] for details).

It can be seen that feature-wise, the C++ API in Series 60 is similar to thatof JSR-172 on Java ME, with the notable exception of DOM support in Symbianand the ID-WSF support in Series 60. JSR-172 only offers XML parsing and SOAPWeb service consumer features, nothing extra. However, the Series 60 API onlydefines the classes and interfaces [Nok], not high-level tool implementation.Thus, SOAP service bindings and their generation programmatically is not asobvious in the Series 60 C++ API as they are in JSR-172.

36

4 General SOA observations

In this chapter, some observations of use and theory surrounding Service Ori-ented Architectures and Web services will be presented. The different aspectsand potential implementations of SOAs will be discussed, along with the differ-ences of Web services and modern HyperText Markup Language (HTML) basedpresentational technologies for service provision. Some critical observations ofthe current technologies are made. SOA and REST implementations and produc-tion use will be discussed through a few examples of real-life service deploy-ments.

4.1 Various styles of SOA

Service Oriented Architecture, while representing one defined architecturalmodel for distributed computing, can be implemented in a number of differ-ent environments and with varying requirements. Thus, the implementation ofSOA is not always made with the same technologies and distribution: it coulduse JMS or HTTP for transport; it could make extensive use of asynchronouscommunication or only support synchronous communication, etc. A servicecould implement a complex caching architecture in a fully private network orit could rely on HTTP infrastructure and be a fully public service on the Internet.These represent just few of the options available.

fully public

service

serviceprivate

global providerlocal provider

point−to−point single provider

multiple providers message bus

Figure 3: Various aspects a SOA implementation could have. Aspects that areopposite one another in the figure are conceptually different features.

Figure 3 illustrates different aspects that a SOA implementation might have.Those features, which are opposite one another in the figure, represent differ-ent approaches to one aspect of the implementation. To explain, a messagebus protocol can implement multipoint and point-to-point communicationswith both synchronous and asynchronous messaging. In contrast, a protocolsuch as HTTP offers only point-to-point synchronous communication. A serviceprovider could offer services globally, for example, a dictionary or a phone-book service, or locally, for example, a restaurant order service or a company’ssite services. A service could have a single provider, or multiple providers

37

could provide the same or similar services. A service could be offered to thepublic, for example, a search or a shop service, or it could be private, for exam-ple, a company’s internal billing system. These aspects can then be combinedin a service, for example, a global, private service with a single provider op-erating on a message bus would be appropriate for a company’s personnelmanagement system.

It is important to note that many different requirements can be satisfiedwith a SOA and this will invariably lead to different feature sets in the vari-ous implementations. From an interoperability standpoint, only aspects suchas choice of transport protocol and asynchronous versus synchronous messag-ing are important. Even these can be made compatible with a suitable bridgebetween the servers and this may well be necessary in a mobile environment,where the mobile device might not support a protocol with all the desired fea-tures.

4.2 Separation of content from presentation

In the present day, a considerable number of services are offered on the WWW,be they related to, for example, e-commerce, communication or gaming. De-spite this, most of these services do not use Web service technologies. Rather,they use HTML [RHJ99] and its forms specifically for the UI, possibly mixing insome client-executable code for better usability. For the application logic, theyuse dynamic, server generated pages. The key aspect is that HTML provides astandard platform for representing the data, so that the service provider can as-sume that the prospective client has a WWW browser installed. In other words,the service provider may assume that the potential service requester does notneed to install any additional software to use the service, thus lowering thebarrier for using the service. In contrast, the Web service technologies thathave been discussed so far require that the requester’s software can interpretthe data format used for communication, which may not be universally sup-ported.

Despite the obvious advantage of having a large installed client base, usingHTML to implement a service interface has some serious disadvantages. Specif-ically, content cannot be separated from presentation, which in practice makesmost WWW pages unsuitable for mobile devices due to much smaller screensused. In addition, the UIs created with HTML tend to be clumsier than thosemade with widget toolkits, which is also a problem on the rather limited in-put capabilities of a mobile device. Sending the presentation along with thedata also significantly increases the need for bandwidth, compared to sendingonly the data as is done with Web service technologies. Finally, SOAs can be farmore complicated than typical HTML-based services, with the use of messagingsystems and complex message exchange patterns.

There are several techniques for implementing features in the client repre-sentation not possible with plain HTML. Lately, Asynchronous JavaScript andXML (AJAX) [Gar05] has received a lot of publicity, while in practice AJAX is onlya new name for an old technology, as it refers loosely to combining HTML andJavaScript with some server-communication done in JavaScript, using XML asthe data format. This is also referred to as “rich client” technology, as muchmore of the processing logic is placed in the client software, as opposed tobeing a dumb terminal as with a plain HTML presentation. The newness in

38

this technology is mostly due to the asynchronous communication model per-mitted by the now reasonably mature HTTP request interfaces in JavaScript.Proprietary solutions with binary client software (as opposed to interpretedscripts), mainly Macromedia’s Flash and Shockwave, have also gained popu-larity. While they require plugins to be installed and proprietary tools to makethe client applications, they have better performance and support more im-pressive features than AJAX.

Current rich client applications are fairly developed compared to those thatwere made during the Internet boom in the late 1990s. Google Maps [GM], asearchable map and route application that also provides satellite images of theregions viewed, has gained a fair degree of publicity in recent months. It re-lies heavily on client-executable JavaScript for providing the UI and the maps.The images that it shows are loaded from the server by the JavaScript codeusing an XML data format for communicating with the server and HTTP trans-port. This method is what is referred to as AJAX and it contrasts sharply to thetraditional way of doing the same thing in HTML, namely doing separate HTTPpage requests when a new image is required and reloading the HTML presenta-tion – most map and route services still use the latter approach. Compared tothe traditional approach, the AJAX approach requires less server resources as UIprocessing is up to the client and operations such as panning are smooth, sincethe page does not need to be reloaded when the view is changed. One draw-back is that the system is performance intensive; the interpreted nature of thecode and unaccelerated graphics makes the service very heavy to run, requir-ing a powerful computer for zooming and panning the map in real-time. Con-sequently, this application is not directly portable to a mobile device, particu-larly since the UI is designed for a relatively large screen and it requires drag-ging with a mouse. Another significant problem is that WWW clients (browsers)tend to offer varying levels of standards conformance and feature support, tothe point that an AJAX developer needs to spend significant time on testing andtuning the application for different browsers in order to avoid significantly dif-ferent behaviour on different platforms.

In light of looking at a well-known AJAX application, Google Maps, it maybe argued that with current, higher end HTML rich client services there is nomajor difference to the SOAs that have been discussed in this thesis. GoogleMaps merely uses a new way of implementing the client functionality, but thedata is still fetched separately from the server. However, while the data transfercould use SOAP, the page itself and requests for route searches are transferredin HTML. Architecturally, this is a somewhat peculiar combination, as someparts of it are similar to a SOA, but neither true SOA nor REST-compliance canalways be claimed. This comes from the facts that the interface is not reallydefined or discoverable by anything else than one specific client and they arenot loosely coupled. In addition, there is no strict requirement on using XMLfor data transport. However, AJAX could be made to be a SOA if the serverinterface was defined separately from the HTML representation and the AJAXclient would present one interface to the data; with a public, clearly definedinterface it would be possible to make a different client, for example, in Java ME.Indeed, REST compliance could be relatively easy to achieve by good design.

AJAX and similar technologies offer an interesting opportunity for client im-plementation, but the poor performance can be restrictive in some applicationsand considerable development time needs to be used for making the client

39

fully compatible with different WWW browsers. It could be imaginable that aservice would have a published interface along with an AJAX client interfacefor those users who do not have specific client software for the service’s in-terface installed. It would then be easy to think of AJAX as an alternative inimplementing a client, rather than a full end-to-end system.

4.3 Weaknesses of current specifications

In the previous chapters, some points have been made about the different spec-ifications for Web services and XML-technologies and how their versions com-pare with each other. To elaborate this further, it is worth pointing out someweaknesses with the current technologies.

An obvious issue to note is that while there are a number of specifications tomake the Web services interfaces as interoperable as possible, there is no com-mon way to define service semantics. The REST architecture does, at least whenimplemented in HTTP, place a number of restrictions on how resources can bemanipulated, such as the use of only the four CRUD operations. Naturally, thereare ways to use these techniques to make non-REST-compliant services on theWWW, as we shall see later on, but the use of only four operations makes the ser-vice access semantics more intuitive. In contrast, SOAP, especially when usedas RPC, gives the implementer practically free hands on service access. How-ever, these limitations do not apply to the data formats transmitted, for whichthere exists a number of schema languages to describe structure, but no com-mon way to address semantics. Naturally, free-form English can be used, buthaving it in free form as opposed to some common template form creates a lotof room for confusion, especially if the description is to be translated to otherlanguages.

In Sections 3.2 and 3.3 it was described how a WSDL description can havetwo different styles, RPC and document, and two different encodings, encodedand literal. In addition to this, there is the wrapped mode [But03]. All theseoptions serve to confuse the implementer and make it more difficult to developinteroperable services. The JSR-172 specification only supports literal encoding,which reduces interoperability with existing services, but also serves to sensi-bly limit the options of the implementer and simplify the library.

Service description is also made more complicated by the fact that thereare competing schema description formats. In WSDL, the choice is betweenthe WSDL encoded form and XSD (literal form), with XSD now being preferable.However, it has been discussed whether not RELAX NG and Schematron com-bined might be a better choice than XSD [Cow03]. In particular, interpretingXSD constraints can be difficult, the extension mechanisms might make it hardto understand what is actually valid and processing requirements can be highwith poorly implemented schemas. In addition, RELAX NG offers a compactform that is easier for a human to read and write than the XML form and theformats can be freely converted to one another. XSD does not offer such anoption.

In terms of SOAP, the 1.1 version is still prevalent, despite the fact that 1.2has been around for a number of years. This is a bit problematic, since the 1.1version does underuse the features of the underlying protocol and may conflictwith it, as described in Section 3.2. This results in two problems, namely thatthere is unnecessary overhead since features are duplicated in both protocols

40

and it breaks some presumptions on how HTTP is expected to work, whichdoes, for example, defeat the purpose of some caches and proxies. SOAP version1.2 is a step in the right direction, with clearer error reporting, the use of GETrequests and better extendibility to various protocols.

While REST imposes some useful restrictions on implementations and it isquite widely used, it is still often forgotten that REST is an architecture, not animplementation [Cow05], for better or for worse. For this reason alone, theterm “REST Web services” is muddy, as was mentioned in Chapter 3. This leadsto the problem that in order to offer an alternative to using SOAP and WSDL,alternative technologies should be proposed. Some might argue that XML overHTTP is the only necessary implementation constraint, while service descrip-tion, both syntactically and semantically, can be done in English. In later chap-ters, we shall see that this approach easily leads to more work in implementingthe communication interface. Non-formal descriptions may also lead to in-teroperability problems, which significantly increase the cost of implementingclients due to longer development times and quality problems.

A potential problem with using the XML over HTTP approach is that it has noobvious or elegant way for handling asynchronous communication. This is notan issue for a number of service scenarios, but for some it can be significant.In a mobile environment, devices may be turned off at some point in time andthey sometimes have problems with connectivity due to insufficient networkcoverage or congestion. For these situations, a caching scheme such as Terryet al. suggest in [TR03] or a similar asynchronous delivery mechanism mightbe desirable. At this point, however, asynchronous communication is difficultto implement due to device and network restrictions, but the situation mightchange in the future.

Finally, there is the question of service discovery. Service discovery is nothandled in detail in this thesis, yet one must ask whether current specificationsin this field are sufficient. In a mobile environment, discovering services isparticularly useful due to the fact that known services might not be used dueto the geography or bandwidth restrictions in the current location. Variousoptimisation strategies for finding a suitable provider would thus be required,such as minimising hop count, physical distance or total load.

4.4 Web service efficiency considerations

One of the central criticisms against Web service technologies is that they areinefficient. First, HTTP has variable length headers in plain text, rather thanheaders more suited to machine processing such as those used in IP. In addi-tion, HTTP agents often send headers that are irrelevant to the request in ques-tion. Second, XML is a fairly verbose format, with both starting and ending tags,everything in plain text and a syntax that frequently requires many elementsfor representing data. Processing can get slow because of the bandwidth alone,but also in matching the syntax rules. Encapsulating the data into a SOAP enve-lope adds overhead and, if transported over HTTP, may duplicate functions ofthe transport protocol. Third, using the more advanced SOAP features such ascache-control headers and encryption complicates the work of intermediariesand adds to message encoding and decoding overhead.

Given the somewhat limited processing and memory capabilities of mobiledevices, the concern for Web service efficiency is substantiated. Agrawal et al.

41

have in [ABGP01] proposed their custom solution for a markup language andimplement Java and C++ interfaces for their system. They proceed to comparetheir system in various configurations using SOAP over HTTP and RMI and con-clude that their system has a service invocation overhead comparable to RMI,being an order of magnitude better than SOAP. They did find load balancing tobe very useful for service implementation.

Nakamura et al. study a SOA for a home appliance network in [NITiM04].Their system is essentially a peer-to-peer network of embedded devices pro-viding services with standardized discoverable interfaces and using each oth-ers’ services, which they compare to an approach with a centralized serverhandling all service orchestration. This leads to good load balancing, easy ad-dition of new devices and better fault-tolerance. However, it was noted thatappliance cost goes up for being more intelligent and overhead is an issue inhard real-time service invocation.

Sinderson et al. have built a portal service for distributing data accumulatedon their Mars Exploration Rover mission in 2003 to the engineers and scientistsneeding it [SMM04]. Their portal was implemented using a SOA, implementingit in Java using a number of cutting edge technologies. They found reliability tobe high, performance to conform to requirements and JMS to have been a goodchoice for integrating their data acquisition components due to its flexibility[SMM04]. They did recommend clustering the service provider to have thepossibility to use that for increasing reliability if necessary.

From these results gained through various groups using SOAs in their dis-tributed computing implementations, it can be said that while a SOAP-basedplatform may not be particularly efficient, it should provide sufficient perfor-mance for many tasks. In particular, it should be noted how the flexibilitygained through designing software to be a SOA and implementing well-definedinterfaces using standard tools was generally found to be good. The customtools that Agrawal et al. propose in [ABGP01] have the problem of not havingextensive tool support, while the less efficient XML techniques are more widelyaccepted. This limits design decisions in a way that higher performance can begained with considerable sacrifices in flexibility.

In the context of mobile devices, the problems lie with network limita-tions inherent to current radio technology, but also with the somewhat lim-ited processing capabilities. To alleviate the former, various caching strategieshave been proposed. Terry et al. have proposed using a transparent cache toimprove Web service usability on unreliable low-bandwidth network connec-tions [TR03]. They acknowledge that there are several hurdles in designingan efficient cache, but the user experience was significantly improved by theuse of a cache. Specific to Web services is that caching SOAP messages mightnot be trivial. This would favour using a REST-conformant design for serviceaccess and dispatching, so that the interfaces to services (or resources) wouldcloser resemble file system operations. In such a situation, the designer of thecaching system could draw from the significant pool of contemporary knowl-edge on file-based caching systems that is available. A problem with cachingfor mobile devices is the rather limited storage capacity of the device itself.Whether or not this is a problem would depend on the application in question,but nevertheless it is a more serious issue than with microcomputers.

42

4.5 SOAP service implementation considerations

Many REST proponents have criticised SOAP for not obeying REST principles,particularly because SOAP uses the HTTP POST message for performing everyaction, instead of using the CRUD model. This situation was somewhat reme-died in SOAP version 1.2 by the introduction of the use of GET, but it still doesnot make use of the four CRUD operations.

This issue can be looked at in two ways. First, this is an issue of dispatching,as HTTP has defined the four operations, which can all be sent to the same URL,thus giving means for performing different actions on a select resource. SOAP,on the other hand, performs dispatching of the operation to perform primarilyin the SOAP data binding itself, not as part of the underlying protocol. This canbe seen as an attempt to make SOAP protocol independent and more flexible,particularly since it was noted that the features of a messaging bus protocolmight be desirable. Nevertheless, the developer does not necessarily need thisflexibility and it brings some problems, mainly the lack of transparency in dis-patching, making such features as caching difficult to implement.

Even though SOAP introduces some additional complexity into the protocolstack, there are a number of positive experiences from implementing SOAs us-ing SOAP. Zimmerman et al. implemented a central service core of a bankingsystem, which could be accessed through a Web service interface [ZMCO04].They found that the completed system had very good flexibility and was thuswell suited for their operating environment. Similarly, Sinderson et al. foundthat using a message bus SOA for their data distribution portal handling a rel-atively large amount of data was a successful design choice [SMM04]. Thus, itseems that despite criticism, SOAP is not overly limiting for implementers.

Christensen et al. have taken an approach more radical than building gen-erators for constructing Web services, namely extending the Java language tosupport session and easier dynamic construction of Web pages than what ispossible with Java. This approach does both increase programmer productiv-ity and it makes it possible to do static analysis during compilation to catcherrors in the Web service code . Christensen et al. do present sophisticatedprogram analysis means for efficiently catching errors in programs. [ClS03]

The approach proposed by Christensen et al. is interesting and technolog-ically sophisticated, but has some problems. The problems are that they re-quire changes to the actual language, which would require a standardisationprocess and a new implementation to be widely offered. Furthermore, extend-ing a general-purpose language for special needs is not usually good design,as it unnecessarily complicates implementation. Luckily, program generationcan in many cases involving Web services offer similar benefits as the pro-posed language extension. In addition, it might be worthwhile to considerspecial-purpose languages for Web service implementation that could be usedas a basis for generation into the final implementation language. Such toolscould provide significant benefits without the problems of extending existinggeneral-purpose languages.

4.6 Current use of REST

REST has been the subject of some interest ever since Fielding came up withthe term in [Fie00]. In theory, the entire WWW should be constructed by REST

43

principles, but in practice, the more complex services on the WWW often do notreally conform to REST by improper use of Uniform Resource Locators (URLs)and the CRUD operations for dispatching operations. Thus, it is worthwhile toconsider a few popular REST-based interfaces in the present day, when ampleknowledge of WWW service construction and architectural principles is avail-able.

The Atom Publishing Protocol [GS05] is a part of the Atom specificationsfor a feed format, auto discovery of the feed and the publishing protocol [Ato].The feed format is based on experiences gained during the use of RSS, whichis discussed in more detail in Chapter 5. The publishing protocol is designedwith editing weblogs, wikis and Web journals in mind [GS05].

A site implementing the Atom Publishing Protocol is supposed to have alisting of available resources, which can be retrieved by a client by request-ing what is called an introspection document. The introspection documentcontains information about collections of related resources and URLs to them.Collection contents can be retrieved or collections updated using the protocol.[GS05]

The Atom Publishing Protocol makes full use of the CRUD operations ofHTTP in a way that can be expected from the REST model (from [GS05]):

GET retrieves a representation of a resource,

POST creates a new resource,

PUT updates an existing resource,

DELETE removes a resource.

From a SOA point of view, resource URLs and the CRUD operations are usedas the service endpoint and the service request respectively. The publishingprotocol requires support for use of XML over HTTP but also SOAP over HTTP.Using SOAP requires using a Web-Method property for indicating what the re-quested operation actually is, as described in Section 3.7.

Chapter 5 discusses the RSS content syndication format in more detail. TheAtom syndication format is intended to replace RSS, but RSS still holds a domi-nant position in the number of feeds offered on the WWW.

The Amazon Web Service offers interfaces in both SOAP and REST to theAmazon Web store [Ama]. The terminology is somewhat misleading; whileSOAP access indeed means using SOAP over HTTP with a provided WSDL de-scription, the REST does, in fact, refer to precisely using XML over HTTP in amanner that is somewhat different from that used in Atom Publishing Proto-col above. Specifically, following the REST model usually involves identifyingresource representations with URLs and manipulating the resources by usingthe CRUD operations in the application protocol, typically HTTP. This is par-ticularly convenient, since HTTP, in part designed by Fielding, who describedREST, offers the CRUD operations for manipulating resources pointed to by URLs[FGM+99]. Amazon, however, changes this by encoding the actual operationand identification details in the URL rather than using HTTP for this. This is asomewhat peculiar approach, particularly since the identification data is nowpassed as plain text in the headers. This is a problem primarily in the architec-tural sense, as full use of HTTP features is not done, nor is SOAP used instead.

44

In the Amazon Web service, URLs basically serve as commands to the service,rather than resource identifiers, which cannot be considered an elegant meansfor service access.

45

5 RSS: a REST-based Web service

In this chapter, RSS is analysed and RSS reader implementations for Java MEand Python are described. As a service, it is quite simple with only synchro-nous request-response messaging and the client does not need to send data.However, it is very widely deployed and gives a good insight into the imple-mentation issues that arise when implementing a client for a service that usesXML over HTTP with no formal interface description. This chapter will thus dis-cuss implementing the RSS client and the performance that it has in an actualmobile phone.

5.1 The RSS format

Really Simple Syndication (RSS) is an XML data format for representing syndi-cated content [Pil02]. An RSS feed contains information about the syndicatedsite, headlines, publishing dates, links to the full articles, various metadataabout the syndicated site and possibly even news item content. The format ini-tially became popular among weblog (blog) writers (bloggers), who wanted aneasy way to communicate to their audience of new entries in their blogs. Fromthis need, the RSS format was born and started to gain popularity at the turn ofthe decade. Subsequently, RSS has become popular among major new sources;for example, BBC, CNN and Washington Post all have several RSS feeds.

An RSS feed is essentially a Web resource, represented by an URL. The rep-resentation of the resource is XML data in text form, corresponding to a RSSschema. Thus, it can be seen that the RSS model of content syndication followsthe REST model described in Section 3.5 (page 27). Indeed, one will notice thatthe terms “RSS feed” and “XML feed” being used interchangeably on the WWW.

The RSS data format itself is quite simple, but matters are complicated by thefact that there are essentially nine different, incompatible schemas for definingthe RSS format [Pil04]. The original formats were defined by Netscape, whilethe later formats were specified by Userland. While the early schema redefi-nitions can be defended by the fact that Netscape was merely experimentingwith the technique and it was not in widespread use, the later redefinitions andnew schemas are somewhat indicative of bad design, particularly since the RSSformat is quite simple. The latest version is 2.0, specified in [Win]. It should benoted that the sepcification is by no means clear on all points.

RSS consists of a root element that contains a number of metadata elementsof the feed, followed by a number of feed items. The feed item elements them-selves correspond to the syndicated content, for example news items or siteupdates. The items contain a number of elements containing data and meta-data about the item in question, such as a link to a web resource that the feeditem is derived from.

The multitude of RSS schemas present difficulties for parsing the feed. Aquick survey of the feeds of some popular media and technology outfits re-vealed the results in Table 2. From this it would appear that the 2.0 schema ismost popular, however, as Pilgrim indicates [Pil04], it is not entirely clear towhich schema 2.0 refers to. It should also be noted that there must obviouslybe a number of sites not using the 2.0 version (in Table 2 we should assumethat YLE’s feed is of the Userland 0.91 format, as there was no reference to aDTD as Netscape’s format would require). Adding to the confusion, the Sun

46

Table 2: Different RSS feeds on the WWW. Note that the feeds may have differentencodings.

Feed Schema NamespaceBBC News 2.0CNN Top Stories 2.0Frankfurter Allgemeine 2.0IBM developer: SOA 2.0Sun Labs Tech Reports 2.0 http://backend.userland

.com/blogChannelModuleThe Inquirer NS 0.91Washington Post 2.0YLE 0.91

Labs feed is entirely in a certain namespace, which requires the developer tobe aware of differences between “plain” RSS and RSS that is expanded with adifferent namespace. Thus, a RSS reader that targets a mass audience will needsome significant amount of extra code to support all these different formats.

In an ideal situation, there would be one schema definition – or several, ifthey are properly versioned – and one namespace definition for the RSS docu-ment. There could be additional namespaces for extending the features, similarto the current use of the http://purl.org/dc/terms/ namespace for ex-tending some versions of RSS. This way, RSS would work as intended and offerrelatively painless extension mechanisms by being namespace-aware.

For the writer of software for mobile devices there is, however, some sortof rescue. The RSS format contains a fair amount of metadata, a lot of whichcannot be conveniently displayed on the small screen of the mobile device andwhich is usually not interesting to the user in the first place. In the RSS readermade as a part of this thesis, this aspect was utilized so that only the most im-portant data from the RSS feed was retrieved and presented to the user. Giventhis, the parsing of the RSS format became very simple and thus liberal in thesense that it works with many different RSS formats, as Pilgrim notes [Pil02].When the liberal parsing approach is used, it is still possible to show all themetadata of the feeed by storing it into a hash table and serializing it into astring representation for output. Naturally, this is not as convenient as content-aware output formatting, but viewing all the metadata would be consideredrelatively rare.

5.2 Implementation experiences

In order to gain insights into the use of REST based Web services a RSS feedreader was implemented. The implementation was done in Java ME, makinguse of the JSR-172 API. For comparison, the RSS parsing and network connectionparts were re-implemented in Python.

As described earlier, a liberal approach was taken to parsing RSS feeds. Inpractice, this meant that headlines, item descriptions and the item URL linkswere parsed into a list of objects, one object per item. The resulting applicationhad an interface consisting of screens to select a feed, add a feed, view feeditems and view the item description and link.

47

The application is multithreaded so that displaying the UI happens in onethread and making network connections and parsing the feeds happens in an-other thread. This is mandated by the Java ME architecture, since the networkconnection and the UI cannot be processed in the same thread due to synchro-nisation. Consequently, the networking thread implemented a classic monitor,where the thread is signalled by the UI thread when a user request triggers anetwork action. This approach is rather necessary, since it enables displayinga graphic about the progress of the network download and displaying entriesas soon as they are parsed, both which significantly enhance the user’s ex-perience of program responsiveness. For performance testing, the entire feedwas downloaded and parsed before displaying, since this enabled separationof the UI updates from the network and parsing action. For the final version,intended to explore JSR-172 use in practice, the stream parsing abilities of SAXwere utilised in displaying entries to the user simultaneously as they were re-ceived from the network and parsed. This made the user experience muchmore pleasant, as the newest items could be seen practically instantly after thenetwork connection was formed.

The final, complete application was about 800 lines of code, not countingcomment or blank lines. Additionally, approximately 200 lines of code waswritten for running tests and for trying out how different approaches wouldwork out.

While the parsing implementation did not attempt to check for structuralvalidity, the parsing engine obviously does not accept malformed XML. It wasfelt that validating, especially since the schema to use would not necessarily beobvious or even available, would be unnecessarily heavy for a mobile client.During testing less than a dozen randomly chosen feeds, each feed was parsedsuccessfully. On this basis it could be argued that validation is probably notnecessary for a client, especially since the server should have the responsibilityto validate a feed before serving it in an application like this when a feed isseldom generated but often read.

It was found that using SAX with Java ME was very convenient due to thefact that the parsing logic could be written entirely in J2SE in an IDE and thenported to the Java ME MIDlet. For testing, a virtual machine supporting Java MEand the required libraries is needed. For this software, Sun Microsystems’ J2MEWireless Toolkit 2.2 was used. The Nokia Series 60 emulator for MIDP wouldhave been an alternative, but since Wireless Toolkit offered all the requiredlibraries and it was much faster, due to the fact that it doesn’t emulate anyactual device, made it a better choice for testing the MIDlet. In addition, itoffered quite practical, although limited, memory and network monitors. Eventhen, development of the core logic first in J2SE using the Eclipse IDE [Ecl] madedevelopment significantly easier, in part due to easy testability. The UI andInput/Output (IO) programming had to be done in the Java ME environment,which made testing slightly more tedious.

While having the SAX interface on both Java ME and J2SE made implemen-tation much faster, there were some features missing from MIDP 2.0 that wouldhave been practical. Namely, there was no built-in sort function offered, so suit-able sorting functionality had to be provided by the programmer. The lack ofcollection interfaces in MIDP did decrease the sophistication of program struc-ture, but on the other hand, the small amount of built-in datatypes made itfairly obvious to know which one to use. The GUI options were not very ad-

48

vanced, but for this kind of an application, the limited amount of GUI customi-sation was not found to be limiting. In fact, developing the software was quick,since issues such as layout management did not need to be considered in detail.For these reasons, the Java ME platform is relatively easy to learn for novices.However, the small screen and limited input devices do require some creativityin making the UI highly usable.

In terms of testing developed software, Python is one step ahead, since it isinterpreted and based on the full version of Python. The programmer needs tocheck that the desired libraries are supported in Python for Series 60, but de-velopment itself can be very conveniently made with an interactive interpreteron a desktop computer. Naturally, GUI programming must be tested on eitherthe Nokia Series 60 emulator or a phone.

It was already mentioned that the Java-implementation parsed the RSSstream into objects using SAX. The implementation relies on nested conditionalstatements to maintain the state of the parsing. The state is needed to knowwhat elements should be matched and stored and to which object. This issomewhat tedious and error-prone to implement and could be automaticallygenerated with a suitable tool. However, such a tool would need to be verygeneral and in Chapter 6, we shall see that code generation from WSDL is eas-ier. It must be noted that having several conditional statements for recognisingdifferent elements is computationally not efficient, as the complexity goes uplinearly in relation to the elements to be matched. However, for this particularapplication the different elements are so few and the nesting so shallow thatperformance is not a problem. In fact, hashing schemes or finite state automa-tons would probably be slower due to the overhead they require.

The Python implementation took a more radical approach, utilising the factthat Python is a fully dynamic language. The elements to capture were putin a dictionary and when matched, they were stored into objects using the el-ement names literally as the field names in the objects. This way, the pars-ing code became a fair amount shorter than in the Java version. This methodsacrifices a bit of program efficiency and error detection capabilities for pro-gramming convenience, but the advantages of simpler implementation shouldnot be overlooked, as it will lead to the software being completed quicker andin Section 5.4 we shall see that the performance penalties paid will not be ofsignificance in this application.

The Python-versions did total 500 lines of code for different implementa-tions, but an actual RSS reader without a GUI was only 73 lines in Python,demonstrating the very good code size efficiency attainable. Naturally, theJava and Python versions are not fully comparable as the UI of the Java versionwas much more complete and thus remniscient of an actual product. How-ever, the RSS parsing code was approximately 130 lines in Java, compared toapproximately 60 lines in Python.

Python for Series 60 is not fully complete, so an alpha version was used.This version did not have XML libraries, so the pyexpat library for Series 60 byHIIT [S60b] was installed on the phone and used. SAX support would haverequired porting a library written in C to Symbian C++, but the expat librarywas very similar in its interface and did not require any additional measures,so it was used instead. In practice, the port proved to be straightforward andthe use of Python’s features did make implementation quick and efficient.

49

5.3 Support for multiple schemas

Earlier it was mentioned that there are multiple, subtly incompatible schemasfor RSS in use. In the RSS reader produced for this thesis, different formats werenot treated differently, as the most interesting data, titles and links, was re-trievable in a similar manner in the most common RSS formats. However, foran extended version of the reader one might want to use the metadata pro-vided in the RSS feed. Moving beyond RSS, there is always the issue of using amore complex format, of which there would be several versions around – notnecessarily conflicting versions as with RSS, but instead schemas which haveevolved over time as a part of normal software evolution. This might easilybe the case in many real world applications, as the RSS format is relatively sim-ple and thus cannot be taken as representative for all data formats that a SOAwould wish to exchange.

To support multiple formats, the exact format of the XML data must be de-termined, unless it contains sufficient redundancy to fit in the variability ofknown formats. The SOA implementation could from the onset be designed tosupport a large variability, as described in [Nyh04]. If a schema definition islinked to, then it suffices to extract the schema URL and compare it or the entireschema to known schema definition URLs or schemas. Naturally, comparingthe known schemas has significant implications for performance and, unlesssoftware can be reused, programmer effort, so merely comparing URLs is desir-able. However, formats may well conform to some common structure withoutexplicitly specifying a schema and many see this as the preferred way to out-put XML, since validation should be against a known schema, not a schema thatthe data file provides [Cow03]. This makes better sense if the extendibility ofXSD is taken into account, as it can make it hard to know whether the schemaof the data file is the same as the expected schema.

In case when the schema is not explicitly defined, it would be easiest to ex-tract the version and namespace of the document and determine the schemato use based on these. Indeed, this would be the most desirable option, as itwould enable documents to be structured and versioned properly. If successiveversions of the format are designed to merely extend previous versions, not al-ter semantics, then the exact version might not be needed, as the parser maybe able to consider the newer features optional. In the case of RSS, this has notbeen done, RSS documents are typically not defined in any namespace and theremight be version numbering conflicts. In any case, the intent of defining ver-sioning, structure and semantics is clear, but there is still debate on the mechan-ics of how to perform this in practice. The use of versioning and namespaces isemerging as the preferred alternative for identifying a document, which is par-ticularly attractive since namespaces are needed anyway, due to being able toextend the document syntax in a controlled fashion. However, the approach ofnot changing semantics in successive versions and not removing features is thebest approach, since a format is then automatically backwards compatible andmultiple namespaces are not needed. Multiple namespaces complicate parserimplementation since they complicate the document structure, so they are bestavoided.

Due to JSR-172 not requiring a SAX parser to support validation, the pro-grammer may either assume that the data is valid or he needs to determinewhether or not validation is supported and possibly validate the data with

50

his own code. Needless to say, the latter option requires considerably moreimplementation effort and has a serious impact on application performance.However, one can often assume that a service provider would perform basictesting on the provided service, such as checking for XML validity. XML wellformedness is checked by definition by the parser, so that is not an issue.

A problem arises when the XML data does not define a schema that it cor-responds to, which is the case with Userland’s RSS 2.0. This would not be aproblem if the application writer would already know what format(s) the ser-vices to use have for their data, but in the case of RSS it can be plainly seenthat the numerous 2.0 versions cannot be programmatically distinguished, asPilgrim also notes [Pil04]. Thus, the application writer’s only option is to try todo a best effort guess on how the data should be parsed. If universally knownnamespaces are used, then they can be used to recognise interesting elements.Fully supporting namespaces adds to the implementation burden, but on theother hand, the namespace mechanism can be very useful for extending dataformats. Naturally, this requires the parser to be namespace-aware.

If the application can determine the format of the XML data, then parsing isfairly straightforward. Using SAX, the programmer might use different modesfor the SAX event handler for different content, essentially changing the pars-ing behaviour based on the data parsed. However, even a small sampling ofprominent news sources indicates that there is a considerable amount of vari-ation between the semantics of different RSS feeds. Generally, the variationsare not large, but nevertheless they add unnecessary complication to writingRSS feed readers. In practice, the parser can handle only a limited amount ofvariation before getting overly complex. When the variation becomes signifi-cant, several different parsers need to be implemented and a complex logic forselecting the right parser to use.

5.4 Performance considerations

A key question in deploying SOAs on mobile devices is whether the perfor-mance is good enough or not. Naturally, this depends on the needs of theapplication, as real-time communication using XML over HTTP is not a realisticidea in mobile devices at this time. However, many applications do not makeuse of real-time or high-bandwidth communications, so that does leave a largeamount of applications that could potentially use a SOA.

Performance testing was carried out by loading the program in a NokiaN90 handset and using an internal Nokia UMTS testing network for data trans-fer. During the time of writing, the N90 was a cutting-edge mobile phone andits software and firmware was still evolving quite rapidly. Nevertheless, thepurpose of performance testing is to determine whether or not XML technol-ogy would be efficient enough for typical applications and finding the primarybottlenecks of using service-oriented applications over the Internet. Thus, theuser experience is more important than absolute numbers.

The complete tables detailing the measurement data are found in Appen-dix A. A few issues made testing more difficult. First, the timing resolutionof the JVM was a mere 1/64th of a second, which however did not prove thatsignificant due to the magnitude of the measured times. Second, and more se-rious, was that there were no methods to construct streams from string literalsand the SAX interface required a stream for parsing. Because parsing can start

51

100

200

300

400

500

600

700

800

900

1 2 3 4 5 6

ms

Attempt number

File reading and parsing times for repeated reads

35 196 byte load14 797 byte load14 797 byte load

Figure 4: File reading and parsing speed depending on the number of attemptsperformed

as soon as the stream is handed over, meaning that the parser can block forthe stream of data, the speed of the parsing stage itself was quite difficult tomeasure. For this reason, a modified program was made, which loaded thedesired file from the phone’s file system and parsed it. The rationale was thateven if the file system does not have zero latency, the use of solid-state memo-ries makes it very fast and it should be possible to deduce some estimate abouthow many resources parsing takes.

The results of reading approximately 35 kB and 15 kB sized RSS feed fromthe phone’s file system and parsing it are presented in Figure 4. The testingmethodology was to start the application and repeating reading the feed andparsing it several times, which is seen on the horizontal axis. The applica-tion was then closed and restarted and the process was repeated. This way,the influence of similar reads inside the application and between applicationruns would be evident. As can be seen from Figure 4, the reading and pars-ing time does asymptotically approach a certain level, dependent on the sizeof the feed. Since the number of consecutive runs was relatively small and theJava ME JVM is not very complex, it can be expected that the parsing itself isnot programmatically optimised in any significant manner. Thus, the gradualreduction of reading and parsing times could be due to OS caches and similarmechanisms, which would reduce the loading times. From the user’s point ofview, the difference in loading and parsing times on consecutive attempts wascertainly noticeable.

From the measurements summarised in Figure 4, it can be concluded thatthe parsing time, even for a large feed such as the 35 kB feed, was in the regionof several hundreds of milliseconds. While this is certainly not close to real-time, it would be fast enough for many applications, especially if the operationthat required parsing would be such that the user would perceive it to require

52

0

2000

4000

6000

8000

10000

12000

0 5000 10000 15000 20000 25000 30000 35000 40000

ms

Bytes

Stream parsing times, standard deviation

MeanStDev

Figure 5: Parse times for different sized feeds averaged over several attemptsand with standard deviations shown.

a significant amount of time, thus meeting the expectations of the user.In Figure 5, the actual stream parse times when downloading from the net-

work are shown as a function of the stream size, along with the standard de-viation. All standard deviations are calculated with unbiased estimators, dueto the relatively low sample amount and high variance. The download andparsing time increases fairly close to linear as a function of the stream size. Itis interesting to contrast this with Figure 6, where a similar measurement hasbeen done, only now with a much later versions of the OS and libraries installedon the phone. In Figure 6, the size of the stream has much less impact on thedownloading and parsing time and the absolute times are far lower than pre-viously. It should be noted, though, that the standard deviations of the meanreading times are so significant, that the precise performance function cannotbe derived from the results, or even approximated very well. Even then, itshould be safe to assume that increase in loading and parsing time is linearlybound, or at least close to that.

While it is obvious that standard deviation is very high compared to themean times, it is similarly obvious that, even with a relatively small samplerate, the newer results presented in Figure 6 are far lower than the older onesin Figure 5. For the purpose of these measurements, the precise reasons are notsignificant, so the reasons for the discrepancy were not further investigated.However, it is somewhat gratifying to see that performance can be improvedsignificantly even with software modifications. One thing to note about thistesting is that different devices have different quality networking hardwareand the communication path to the base station might vary significantly. Thesetests were performed from the same spot, but in reality, even more deviationfrom the mean values could be expected when the radio link to the base stationis taken into account.

53

0

2000

4000

6000

8000

10000

12000

0 5000 10000 15000 20000 25000 30000 35000 40000

ms

Bytes

Stream parsing times, standard deviation

MeanStDev

Figure 6: Parse times for different sized feeds averaged over several attemptsand with standard deviations shown. The tests where done on a later date andnewer libraries than those used for Figure 5.

Table 3: Mean connecting times and their standard deviations. The last threeresults were obtained at a later date and with newer libraries than the four firstresults. It is worth noting that the last three feeds were all served from thesame server.

Feed Size (bytes) Mean time (ms) Standard deviation (ms)

IBM SOA 35196 2471 371BBC 14797 2390 332CNN 4467 2301 331WP 2400 2256 96

Java 37986 3450 527POWER 30572 2906 76Johnston 24107 3586 919

54

Phone network technologies have one significant usability issue when mak-ing packet data connections, namely that it takes some time to from the con-nection before transfer can begin. To get a grasp on how long this time is andhow it varied when the news software was installed, connection times weremeasured and averaged. The results are presented in Table 3, with the resultscorresponding to those in Figure 5 in the upper half of the table and those cor-responding to Figure 6 in the lower half of the table.

The hypothesis about connection times is that they do not depend on thestream size and the results in Table 3 tend to show that, when one considersthe standard deviation and the fact that servers might at times be a bit slow. Itis interesting to note that the newer software actually produces slower connec-tion times than the older one. It might be that the newer software downloadsmore data from the network before passing over control to the application thanthe older software did, which would also explain slight variation in connectiontimes depending on the size of the feed. Nevertheless, this means that the dif-ferences between the total connection, downloading and parsing times of theolder and newer system software are smaller than Figures 5 and 6 would leadto believe. This is actually worse for the usability of the program, since no datacan be displayed to the user while the connection is made, while data can bedisplayed when the parsing goes along. Longer parsing times are thus not asbad as longer connection times, since the user still has the newest entries tolook at while the older ones are loaded and parsed.

0

2000

4000

6000

8000

10000

0 2 4 6 8 10 12 14

ms

Attempt number

35kB stream reading and parsing times at long intervals

ConnectingParsing stream

Total

Figure 7: Reading and parsing a network stream of 35 196 bytes during non-frequent intervals interspersed over two days. The total time is the sum of thetime it takes to connect to the service and the time it takes to read and parsethe stream.

In order to gain insight into how much transfer speeds can vary in a fairlywell controlled environment, a single, 35 kB feed was read at the same spotin intervals of approximately one hour, with two attempts done every hour

55

Table 4: Mean connecting and parsing times and standard deviations for a 30572 byte feed. The Python version use was 1.1.6 alpha and two sessions withseveral attempts each were made in Python to minimise random variations.

Feed Mean time (ms) Standard deviation (ms)

Python 1 (POWER) 6618 1386Python 2 (POWER) 6891 3579

Java (POWER) 5960 215

in short succession to reduce the implications of random variation due to badconditions. The results are presented in Figure 7 and show times for connect-ing to the resource, downloading and parsing it and the total time for both.As can be seen, the variations in times are quite considerable, in both rela-tive terms and absolute time. From these results, it can be concluded that thesoftware developer should at least be prepared that messages arrive at highlyvarying intervals and thus only very general estimates on timings should bemade when implementing service clients on mobile phones.

Earlier it was mentioned that implementing the feed reader in Python wasrelatively easy. To gain insight into how much performance is lost when us-ing an interpreted language and language features that ease programming butare not computationally optimal, some performance tests were made with thePython RSS client. Table 4 shows a comparison of retrieving a feed with javaand with Python, having performed two separate measurement sessions withthe Python client to minimise the impact of random variations. It can be seenthat the Java client is faster in this test, although by an amount that is withinthe standard deviation of both Python tests. The results are interesting as theJava environment and libraries used were far more mature than those of thePython used and the difference in performance is not large.

In a feed reader application it would be useful if multiple feeds could beaggregated into one big feed, with entries sorted by date. This way, the userwould be presented with his favorite feeds, and finding recent, interesting en-tries would be easy. Additionally, unread entries might be highlighted. Theperformance figures presented here do, however, indicate that such an ag-gregation approach is not possible; it would take far too long to fetch evena modest amount of feeds simultaneously. Consequently, this approach wasnot pursued. Marking unread feeds would, however, probably be practical,as it depends mostly on computing speed and storage space and the require-ments for these would not be that great. There is an obvious solution, and thatis to sue a separate server for aggregating the feeds. This aggregating servercould have common features with the general caching service for mobile de-vices described by Terry and Ramasubmaranian [TR03], where the feed couldbe prefetched, cached and served to the mobile device efficiently as a new feed.In this scenario, the aggregating server would be itself offering a service, whichcould quite possibly be an individually tailored subscription service. Privacycontrols could also be used, to hide the feeds and items the user is reading fromthird parties.

56

5.5 Tool development possibilities

During the implementation of the RSS reader for Java ME, it became clear thatsignificant effort must be put into working with features which result in codethat is simple and predictable enough to benefit from code generation. Specif-ically, implementing a parser that uses a given parsing interface to generatethe desired data structures or events out of the received data could be madeeasier. However, using WSDL with a generator is probably a better solution,and this approach will be used in Chapter 6. Even then, both the more ad-hocservice interface client implementation described here and the more rigorousmeans of using SOAP with WSDL descriptions would both benefit from usingformal schemas for the data formats and tools for generating code based onthe schemas.

It should be noted that the RSS reader merely need to parse received data,not generate data of its own. A considerable number of clients will need togenerate XML data, even though not all REST clients need to do it, whereas prac-tically all SOAP clients need to. Consequently, consumers of complex serviceswould benefit greatly from tools that could bind schemas and service interfacesinto application code, as is possible with SOAP-based services using WSDL (seeSection 6).

The RSS reader implementation used the SAX interface in Java ME and ex-pat in Python, both that are event-based push interfaces. They are somewhatless intuitive to use than a pull-interface would have been, but the difference isnot major and learning to use the interfaces was found to be easy. In terms ofperformance and the ability to incrementally display results, the use of theseinterfaces was a very good choice. However, there are a number of applicationswhere more complex interfaces, such as DOM, would be desirable, even thoughthey may not be feasible to run on other than high-end mobile devices. Con-sidering this, code generation could be used to build abstractions over eventbased-interfaces that would allow accessing the relevant parts of a documentinto a datastructure.

In developing the RSS reader, it was found that improving tool support forthe generation of the GUI and IO code would be useful. These are not directlyrelated to SOA implementations, but do take a more significant part of the im-plementation time than designing and implementing the network interface it-self. This could also be seen as good, as implementing a SOA is not supposedto be a major burden on the programmer. It should be noted, though, that GUIimplementation in Java ME was far easier than GUI implementation with mostwidget toolkits for desktop systems.

In the end, developing a RSS reader is not particularly challenging, nor doesit offer many opportunities for automating the implementation process. Toolscould help in designing and implementing a GUI, but this applies to all appli-cations, not communication applications in particular.

57

6 SOAP based SOA implementation

In this chapter, we are going to look at real-life Web services implementationusing SOAP and WSDL. Some popular and public services are going to be con-sidered for requester implementation and the current status of Web servicesis analysed. An indigenous service is designed and a client, server and inter-face definitions are made for it. Finally, experiences gained of Web services areanalysed.

6.1 Current status

In chapter 3, it was noted that the roots of SOAP and thus Web services were inthe late 1990s. During the years around the turn of the decade, Web servicestechnologies developed quickly and the overall Internet hype of the time con-tributed to promoting Web services as “the next big thing”. In practice, eventhe protocols were immature until 2002, and obviously so was tool supporttoo. Since then, the Web services specifications have remained stable, whichhas in turn enabled the development of more mature and sophisticated tools.Currently, both commercial and free, open-source tools of good sophisticationare available.

While Web services have not had a turning point that would have led torapid growth of adoption, Web service technologies are being used in increas-ing amounts on different scales of services. For example, the Amazon Webservice interface makes extensive use of Web service technologies [Ama] andthe commercially highly successful Google AdWords advertising system has aWeb Service interface currently available as a beta version [Goob]. Companiesand communities also increasingly deploy Web services for internal use, suchas the banking system described by Zimmerman et al. [ZMCO04].

Despite the seemingly good status of Web services both in terms of sup-porting software and in terms of successful deployments, a number of prob-lems were encountered when interfacing with and developing Web services.The problems shall be noted in this chapter.

6.2 Environment requirements

In Section 2.1.4 it was noted how there are three manufacturer supportedprogramming environments for Series 60 devices, namely C++, Java ME andPython. The support for SOAP based service requester construction in theseenvironments varies. No particular language support for Web services areneeded, but library support is very useful. Series 60 will provide a numberof C++ libraries for supporting client construction in its 3rd edition. Most im-portantly, this includes classes to handle SOAP messages.

In Section 3.9 it was noted that JSR-172 supports binding to services thatcommunicate with SOAP. Unlike the Series 60 C++ API, no additional supportfor commonly known profiles, such as ID-WSF or WS-* are provided. In practice,this means that more complex services that require, for example, user identi-fication or transaction support will require significant understanding of SOAPand JSR-172 to implement correctly. Such features will also significantly raisethe programming and testing effort needed.

58

The Python environment does not come with any libraries for SOAP andthus any Web service support needs to be done using third party libraries, ifsuitable ones are found. As can be expected, no tool support is provided, butthe fact that mobile Python is fairly close to the Python interpreters that areused on larger computers makes library and tool porting easier.

It should be noted that language features themselves make Web serviceclient implementation easiest in Python, fairly easy Java and significantlyharder than those two in C++. However, this only applies if tool and librarysupport is not taken into account, but it should be noted as future tools and li-braries might tip developer interest towards programming environments thatmake more efficient development possible.

As mobile devices are currently intended to be only service requesters, notproviders, support for service construction is not present. In practice, serviceswill most often be created in a Unix or Windows environment, where a num-ber of tools such as Axis [Axi] and commercial products from major softwarecompanies are available.

6.3 Tools

In the previous chapters, it has already been hinted that implementing Web ser-vices benefits greatly from good tool support. As described in implementingan RSS reader in Chapter 5, the XML over HTTP approach required hand codingthe XML parsing and generation stages in order for the application to be able tocommunicate over the network. This is a tedious and error-prone process. Ifthere is no Web services tool support available, then using SOAP the situation isworse. This is because SOAP messages carry a fair amount of additional infor-mation beside the data itself and may encode the data in a non-obvious way.Interpreting this data may require some effort. In addition, SOAP tends to makeheavy use of different namespaces. Luckily, the Web service interface descrip-tion is documented in the WSDL definition of the service, which also documentsthe data structures used for the service. The WSDL description is particularlysuited as an input for machine generation, so Web service development does inpractice require a generator for generating the protocol bindings and datatypesdefined in a WSDL description into constructs in the programming language tobe used.

To facilitate the construction of Web services, several generators for differ-ent purposes may be available. The Apache Axis SOAP implementation hasgenerators for generating data structures and SOAP bindings in Java from pro-tocol descriptions and for generating WSDL from Java classes [Axi]. It is in-tended primarily for use in a J2EE environment. Sun’s Wireless Toolkit version2.2 [WTK] offers a stub generator to generate protocol interfaces in Java froma WSDL description. The creation of WSDL descriptions can be facilitated by theuse of editors made specifically for WSDL, making the creation of a service de-scription easier. Such software was not, however, available for testing for thisthesis. Since the application bindings and service descriptions are separatelydeveloped, a build environment is convenient for keeping them synchronized.This could consist of a simple script or a sophisticated build tool.

It is important to note that with proper tool support, the Web service devel-oper should be able to concentrate solely on defining interfaces, data structuresand application logic. Manually handling SOAP data should not be needed, as

59

there should be generators available for generating code to handle networkcommunication.

The Google APIs [Gooa] were tested using this approach. The programminglanguage Perl was used with the SOAP::Lite library [KR03] to use Google’sInternet search through a Web service interface. The code for performing net-work operations and interacting with the service was on the order of five to tenlines, depending a bit on error handling extensiveness and indentation. Usingthe library required passing the address of the WSDL description of the serviceto a runtime object, which created suitable objects for using the service. Thisresulted in a far shorter development time than with the RSS reader describedin Chapter 5, but if the generation from the WSDL description would have failedor had not been available, then not only the data but also the SOAP envelopewould have had to be processed by hand, resulting in a very tedious imple-mentation process.

6.4 A dictionary service

The intent was to build a Web service client to a somewhat well-known andwidely used service, in order to assess how good the interoperability is in prac-tice and to make a comparison to RSS in a somewhat similar deployment situa-tion. Google APIs seemed very good, as it is simple and the service of Internetsearch would be very useful in a mobile device. In addition, the UI could bebetter for a mobile device than that of the Google HTML interface. However, thisdid not work because the Google API used the rpc/encoded -scheme, which isnot supported in JSR-172 [EY03].

Another good candidate as a service to use was Amazon Web Services[Ama]. It is considerably more elaborate than the Google APIs and not in beta.It offers a system for interfacing to the Amazon Web store, enabling third partydevelopers to create alternative interfaces to the store and applications by us-ing Amazon technology. The Amazon Web Services did use a more modernWSDL style, but unfortunately the WSDL description was so large that Sun’s stubgenerator repeatedly crashed when trying to generate code from it.

It became apparent that Web services do, in practice, have many limita-tions on mobile platforms. A new approach was chosen, that is to constructa simple, yet useful dictionary service to be operated from a phone. The dic-tionary would include both a translation and a dictionary lookup service, aswell as displaying a link to information or products related to the query made.The WSDL description for the service was constructed by hand and it used thedocument/literal style. Sun’s stub generator did not understand attribute de-finitions in the schema, so all data was mapped to elements. The responsepattern was to be a synchronous request-response pattern, since obviously anasynchronous pattern does not make sense for a dictionary service.

The final dictionary description worked well with Sun’s stub generator, sothe Java ME client could be developed with relative ease. In order to developthe server software, Apache Axis 1.2 [Axi] was considered to be used alongwith the Apache Tomcat J2EE container. However, the service interfaces gener-ated by Axis from the WSDL description were unsuitable for the described com-munication pattern and no remedy for this situation was found. From prior ex-perience it was known that setting up a J2EE container and a servlet-based WWW

60

interface to it could be somewhat tedious. While using Axis would be desir-able for implementing the server in a manner resembling that which would beused in a production environment, it was felt that after constructing the stubs,this would provide little additional value in terms of acquiring experience ofWeb service implementation. Consequently, as no solution for having the inter-face work according to the specified communication pattern was found in theAxis manual, the service was instead implemented on a lower level in Python.Due to the simplicity of the formats used and the powerful abstractions of thePython language, this proved to be a relatively minor effort.

Figure 8: The dictionary client user interface, shown in a Java ME emulator.A word has been typed and the mode is set to do a dictionary lookup. Theresult is displayed, along with a sponsor name, which could also be a link toadditional information about the word searched.

The final dictionary client was small at a package size of just 5 kB. The UI isshown in Figure 8 and it was quite clear even on a mobile phone. Performancewas acceptable for this kind of an application, with the general impression ofperformance was similar to that of the RSS reader described in Chapter 5. Thedictionary client itself was only 400 lines of code, even with the generated partsfactored in, while the dictionary server and a substantial amount of test codeconstituted approximately 500 lines of Python code. The dictionary servicedefinition and datatype definitions accounted for 130 lines of code, althoughmuch of this was fairly elaborate and the final service description only usedabout 60 lines of specification code.

6.5 Strengths and weaknesses

Initially it was assumed that the biggest issues with SOAP-based Web serviceswere the performance implications of the additional overhead over XML overHTTP and the complexity of the specifications. In practice, the performanceof the dictionary client constructed was never an issue, so it could be expectedthat the performance be very similar to that of the RSS reader described in Chap-ter 5. In other words, performance is sufficient if real-time performance is notexpected and modest amounts of data are transferred.

61

The complexities of the specifications is an issue, but not in the way ex-pected. In an ideal environment, the client developer does not need to knowanything about SOAP or even WSDL: the bindings to the programming languageused can be generated from the WSDL description, so the programmer can dealdirectly with the data structures. In practice, tools still need to be developed,especially in terms of developing and deploying Web service software on mo-bile devices.

62

7 Discussion

In this chapter, findings based on the experimental results, specification analy-sis and studies of published literature will discussed. The styles in which theservice should be designed and the protocols used will be critically assessed.Web services based on using SOAP and on abiding to REST principles are dis-cussed. Tool and library support for implementing SOAs in different technolo-gies on mobile devices are discussed. Finally, performance of current imple-mentations is analysed.

7.1 RPC compared to document oriented techniques

In Section 3.2 it was mentioned how Web services have developed from thepoint where they were considered to be RPC implementations using XML overthe Internet to the current situation where more emphasis is put on document-oriented use of Web service technologies [Box01]. From the perspective of SOA,RPC does not quite fulfil the requirements of service providers and their re-questers being loosely coupled and the requirement for data transfers to becoarse grained even when compared to component-based design. These re-quirements lead to a design making use of RPC to not be SOA conformant. Fur-thermore, RPC has some problems in how to map functions in a programminglanguage naturally to RPC constructs – not all datatypes might be supportedand overloading might not work. Service use should not be dependent oncertain programming languages or operating environments, but the tight cou-pling present in RPC designs easily creates these kinds of dependencies.

In contrast to RPC, the document-oriented way to design Web services con-forms better to SOA. By exchanging documents instead of making procedurecalls, the coarse-grainedness property is easily satisfied. Similarly, definingdocuments in an XML form using widely used schema languages creates moreinteroperable services, as opposed to designing procedural interfaces. In doc-ument format design, specific language features are not as likely to influencethe designer as in the case with RPC, where the temptation is great to make theprocedural interface similar to what is typical in the language of the originalimplementation. This makes loose coupling of the service much more likelythan with an RPC design.

There are different opinions on whether SOAs should support asynchronouscommunication or not, with the answer usually depending on the usage sce-nario [BJK03]. It is worth to note that by definition, RPC is synchronous, un-less a fairly elaborate system of notifications to make non-blocking procedurespossible is implemented. In contrast, document oriented services are muchmore easier to think as asynchronous, particularly since loose-coupling fre-quently makes the service requester less dependent on receiving the responsevery quickly.

It is interesting to note that the properties of the HTTP protocol makes itsomewhat badly suited for RPC, since there is no standard way to advertise pro-cedural interfaces or to encapsulate procedure call data and datatypes for thearguments. Naturally, the situation could be changed, but one doesn’t reallysee REST conformant implementations trying to use a RPC model of operationin practice. Furthermore, HTTP creates some overhead, due to which it is better

63

suited to coarse-grained use. Thus it seems that REST conformant implementa-tions do tend to naturally use a document-oriented design for data transfer.

7.2 The relation of SOAP-based services to REST

It was noted in Section 3.6 that there has been criticism towards SOA and theuse of SOAP-based Web service implementations. In part, this criticism is di-rected towards SOA, in part towards the traditional Web service technologiesfor service communication; SOAP, WSDL and the WS-I specifications. The mainargument seems to be that these technologies make development harder, im-plementations less efficient and increase risk compared to REST.

When comparing different architectures and technologies related to SOAand Web services, two things need to be kept in mind. First, one should re-alise how restrictive an architecture is, what it tries to define and what arethe roles of different implementation technologies. REST is an architecture, forwhich HTTP is one preferred protocol. This does not directly compare to SOAP,which merely defines the implementation of an upper-layer protocol. Second,there are many misconceptions about different technologies and architectures.To demonstrate, SOAP is still largely associated with RPC-style communicationdue to its roots, even though, as was noted in Section 7.1, it is currently recom-mended to use a document-oriented communication model in order to build aSOA.

For the sake of argument, it is best to consider a typical REST implementa-tion to be XML data sent over HTTP. This implementation is somewhat lighterto process than SOAP, especially for the intermediaries. SOAP requires parsingthe envelope and headers of the message, which, on the basis of performancemeasurement presented in Chapter 5, should not be an issue as the additionaldata is not typically large in size. However, complex headers that need to beprocessed by SOAP intermediaries might create bottlenecks in the communica-tion. Also, SOAP makes heavy use of different namespaces, which complicateprocessing and use additional bandwidth. In contrast, HTTP processing is sim-pler.

In Section 3.7.2 it was noted how the features of HTTP might place limita-tions on Web services. The key issue is that these limitations are not necessarilya problem for a large number of services. Indeed, features such as asynchronic-ity or multicasting are hard to support in a large, non-centrally managed net-work such as the Internet. The most significant issue with HTTP is whether theuser authentication mechanisms it provides are sufficient. More research andpractical experience from using Web services on mobile devices is needed toanswer this.

In considering whether there is greater risk in implementing a Web serviceusing SOAP than implementing one without it depends on how hard imple-mentation is and how good the compatibility of different implementations is.Implementing clients to SOAP-based Web services is very easy provided thatone has the tools necessary and they work with the service description. If not,then implementation takes more time and is significantly more error-prone.Server implementation is generally harder than when using XML over HTTP, asone not only needs to know schema languages well enough to be able to mapone’s document datatypes in the programming language of choice into XML,but also to understand WSDL construction and styles. WSDL construction can be

64

facilitated by the use of tools, but this again means that suitable tools must beavailable.

Interoperability of implementations seems to be less rosy than anticipated,based on the experience on using different services in Chapter 6. However,investigating interoperability was not one of the aims of this thesis and no rashjudgements should be made on this point based on the limited amount of dataavailable. However, it can be safely noted that interoperability is somethingthat should be kept in mind when considering implementation choices. PlainXML over HTTP in a REST-conformant implementation has the advantage here,as the basic technologies are more mature and simpler than thus of SOAP-basedWeb services.

Regarding implementation, it is interesting to note that while WSDL definestwo different ways to define the schema of the data, it does not offer a wayto extend this mechanism. At this point, the literal encoding style that usesXSD for defining the schema can be considered as the preferred implementa-tion, but there is no extension mechanism to use an entirely different schemadescription language, should the need arise. Problems and limitations of XSDhave been debated, as it is a fairly complex format both to use and especiallyto implement [Cow03]. Since the ISO/IEC standard for document descriptionuses the RELAX NG language [RNG02], this begs the question whether WSDL isflexible enough for future demands. The different WSDL styles present certainlydo create confusion already, not least because the document/literal wrappedstyle is not publicly documented [But03]. Many of these alternatives do notmake WSDL better or just more flexible; they serve more as ballast from theearly days of Web services.

Finally, many variations of dispatching the service request have been seen,from the REST way of identifying an URL with a resource and using CRUD op-erations to operate on it, to the way Amazon uses in encoding the operationin the URL and to the traditional SOAP way of using the SOAP metadata to de-termine dispatching. Fortunately, even SOAP has been moving towards REST inthe use of underlying infrastructure and protocols. Perhaps the greatest assetwith REST is that it adds clarity to design and implementation by restricting theoperations and clearly separating dispatching of the operation from identify-ing the resource/service to operate on. Thus, keeping REST principles in mindwhen designing services for the Internet can be considered a sound practice.

7.3 Tool and library support

Throughout this thesis, tool support requirements have been discussed for var-ious implementation strategies. This can be summarised so that in Chapter 5it was noted that the typical REST service does not have much in the way oftool support, although library support is fairly good, with several mature XMLparsers available. As seen in Chapter 6, SOAP and WSDL based service con-struction is better supported by tools, but there are problems with tool ma-turity when developing clients for mobile devices. Library support is gettingmuch better now that new libraries are being added to smartphones, but theapproach is cautious at best: the basic library set seems to be a SAX parser andsome library support for SOAP. More abstract and cutting edge XML parsershave not been brought to mobile platforms.

65

For most service construction needs, library support can be considered suf-ficient, but tool support still needs development. Specifically, developing aSOAP-based service needs a stub generator that will generate stubs for the cho-sen mobile platform from a WSDL description. Additionally, tools for editingXML data, such as WSDL and schemas, could be considered to ease the servicedesign. However, it should be noted that the needs on the client side a signifi-cantly more modest than those of the service provider side.

It would be interesting to consider how REST service client constructioncould be facilitated by the use of tools. In practice, this would require generat-ing some network code to handle the HTTP connection and a parser to parse thereceived XML into an appropriate data structure. Preferable, the parser genera-tion should be done from a given schema. Cowan notes that there are alreadymany capable tools for manipulating RELAX NG [Cow03], so it should not bethat difficult to generate parser code from schemas, as there is already expe-rience of similar software and the most common schema formats can be con-verted to one another, so that the generator need only support one format. Ifa dynamic language with reflection capabilities was used for implementing aclient, it could dynamically construct a service binding from a given schema orWSDL description.

7.4 Performance issues

In Chapter 5, performance was evaluated to a limited degree in order to findout whether it poses problems for SOA implementation. The results indicatethat the time taken by XML parsing is tolerable, but network speed, especiallythe time it takes to form a connection, could be significantly improved to en-hance the user experience. Whether or not the performance is a problem de-pends entirely on the type of service implemented. For example, the feedreader was quite usable, but a fast paced computer game would not work wellin this environment.

In terms of binary size and memory footprint, the created applications weregood. The ability to utilise libraries provided with the phone proved to bothspeed up implementation and to keep binary sizes down. The ability to useservices significantly expanded the capabilities of the phone, as feed readingin Chapter 5 is a practical way to receive information and while the dictionaryin Chapter 6 could have been implemented on the phone alone, it would haveused enormous storage resources.

It should be remembered that no clients were implemented in C++, despitethe fact that it is the native language of Symbian OS. This is plainly because oflack of tool support and the immaturity of the C++ libraries at the time whenthe client implementations were done. A C++ client implementation can beexpected to be more efficient than one in Java or Python, but due to the featuresof C++ on Symbian, it would have taken much more time to implement.

66

8 Conclusions

In this thesis we have investigated the possibility of implementing SOA on mo-bile devices and what limitations are placed on the implementation. It wasfound that implementations using SOAP-based Web services or plain XML overHTTP implementations are possible to do, even with relative ease. However,current APIs place some limitations on implementation, such as the currentJava ME not permitting to use every HTTP CRUD operation, limited support fordifferent XML parsing APIs regardless of environment and limited support fordifferent WSDL styles. Despite this, some quite useful service clients can beconstructed, as has been demonstrated in this thesis.

Constructing SOAP-based Web services requires service interfaces to be spec-ified in WSDL. While this requires the service implementor to have a bit moreknowledge of Web service technologies, it does greatly facilitate constructingservices and clients. While the REST architecture is often proposed as an alter-native to SOAP-based Web services, REST is an architecture and does thus notdefine an implementation. In practice, plain XML over HTTP is typically used,which tends to make client construction harder since there are no widely avail-able tools for constructing REST-style clients from schema descriptions or for-mal descriptions for service interfaces. Thus, client implementation for SOAP-based Web services is generally easier than for XML over HTTP-based, if theWSDL and SOAP formats of the service match those supported by the servicestub generation tools.

SOAP does introduce overhead over sending plain XML over HTTP, but this is,in practice, negligible. The main performance issues lie with connection timesand not XML parsing times, although the performance is sufficient for manykinds of non-real-time services. Using SOAP has some advantages if very spe-cific needs for supporting transactions and cache controlling exist. In addition,SOAP can be used with the Liberty framework for authentication and security,which can be useful for a mobile environment. However, SOAP does increasecomplexity of the protocol stack and this combined with the fact that there areseveral different WSDL styles in use may cause interoperability problems withlibraries, services and tools.

Instead of HTTP, message bus architectures can be used for communication,for example, to build an ESB for service communication. Currently, there is nosupport for this on the mobile platform, but it does have potential advantages,such as asynchronous messaging and event notification requests. While suchfeatures are difficult to implement over the Internet, the mobile environmentoffers possibilities to use messaging systems, for example by the connection toa virtual private network.

Tool and library support for SOA construction on mobile devices is still lim-ited and care must be taken in choosing a programming environment and plat-form for the best possible support. Particularly stub generators that generatemethod stubs from WSDL definitions are needed due to their central role in con-struction SOAP-based clients. Tools for editing and converting between schemaformats, as well as for generating code from schema definitions could be ofgreat use. Service implementation requires more tool support than client im-plementation, such as WSDL editing tools and Web service server software. Allin all, implementing SOAs is possible to do on mobile devices, but developmentwould be significantly easier and faster if the tool support and maturity wouldimprove.

67

References

[ABB+05] Eric Armstrong, Jennifer Ball, Stephanie Bodoff, Debbie BodeCarson, Ian Evans, Dale Green, Kim Haase, and Eric Jendrock.The J2EE 1.4 Tutorial. Sun Microsystems, 2nd edition, June2005. Available from: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html [cited 28 September 2005].

[ABC+98] Vidur Apparao, Steve Byrne, Mike Champion, Scott Isaacs, IanJacobs, Arnaud Le Hors, Gavin Nicol, Jonathan Robie, RobertSutor, Chris Wilson, and Lauren Wood. Document objectmodel (DOM) level 1 specification. Technical report, W3C, Oc-tober 1998. Available from: http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/ [cited 3 October 2005].

[ABGP01] Rakesh Agrawal, Roberto J. Bayardo Jr., Daniel Gruhl, and SpirosPapadimitriou. Vinci: a service-oriented architecture for rapiddevelopment of web applications. In WWW ’01: Proceedings of the10th international conference on World Wide Web, pages 355–365,New York, NY, USA, 2001. ACM Press.

[Ama] Amazon Web services [online, cited 19 September 2005]. Avail-able from: http://www.amazon.com/gp/browse.html/104-5581766-7376723?node=3435361 .

[Asa02] Amit Asaravala. Giving SOAP a REST, October 2002. Availablefrom: http://www.devx.com/DevX/Article/8155 [cited28 September 2005].

[Ato] Atom publishing format and protocol (atompub) [online, cited19 September 2005]. Available from: http://www.ietf.org/html.charters/atompub-charter.html .

[Axi] Web services – Axis [online, cited 14 September 2005]. Availablefrom: http://ws.apache.org/axis/index.html .

[BHLT04] Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin.Namespaces in XML 1.1, February 2004. Available from: http://www.w3.org/TR/xml-names11/ [cited 28 September 2005].

[BHM+04] David Booth, Hugo Haas, Francis McCabe, Eric Newcomer,Michael Champion, Chris Ferris, and David Orchard. Web ser-vices architecture, February 2004. Available from: http://www.w3.org/TR/ws-arch/ [cited 28 September 2005].

[BJK03] Alan Brown, Simon Johnston, and Kevin Kelly. Usingservice-oriented architecture and component-based de-velopment to build Web service applications. Techni-cal report, IBM DeveloperWorks, 2003. Available from:http://www-106.ibm.com/developerworks/rational/library/content/03July/2000/2169/2169.pdf [cited 6June 2005].

68

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html

http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/

http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/

http://www.amazon.com/gp/browse.html/104-5581766-7376723?node=3435361

http://www.amazon.com/gp/browse.html/104-5581766-7376723?node=3435361

http://www.devx.com/DevX/Article/8155

http://www.ietf.org/html.charters/atompub-charter.html


http://ws.apache.org/axis/index.html

http://www.w3.org/TR/xml-names11/

http://www.w3.org/TR/xml-names11/

http://www.w3.org/TR/ws-arch/

http://www.w3.org/TR/ws-arch/

http://www-106.ibm.com/developerworks/rational/library/content/03July/2000/2169/2169.pdf

http://www-106.ibm.com/developerworks/rational/library/content/03July/2000/2169/2169.pdf

[BLBC+04] Tim Berners-Lee, Tim Bray, Dan Connolly, Paul Cotton, RoyFielding, Mario Jeckle, Chris Lilley, Noah Mendelsohn, DavidOrchard, Norman Walsh, and Stuart Williams. Architectureof the World Wide Web, volume one. Technical report, W3C,December 2004. Available from: http://www.w3.org/TR/webarch/ [cited 28 September 2005].

[BM04] Paul V. Brion and Ashok Malhotra. XML schema part 2: Datatypessecond edition, October 2004. Available from: http://www.w3.org/TR/xmlschema-2/ [cited 28 September 2005].

[BNdB04] Geert Jan Bex, Frank Neven, and Jan Van den Bussche. DTDsversus XML schema: a practical study. In WebDB ’04: Proceedingsof the 7th International Workshop on the Web and Databases, pages79–84, New York, NY, USA, 2004. ACM Press.

[Box01] Don Box. A brief history of SOAP, April 2001. Avail-able from: http://www.xml.com/pub/a/ws/2001/04/04/soap.html [cited 28 September 2005].

[BPSM+04a] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler,François Yergeau, and John Cowan. Extensible markup language(XML) 1.0 (third edition), February 2004. Available from: http://www.w3.org/TR/REC-xml/ [cited 28 September 2005].

[BPSM+04b] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler,François Yergeau, and John Cowan. Extensible markup language(XML) 1.1, February 2004. Available from: http://www.w3.org/TR/xml11/ [cited 28 September 2005].

[Buc00] Simon Buckingham. What is general packet radio service?,January 2000. Available from: http://www.gsmworld.com/technology/gprs/intro.shtml [cited 3 October 2005].

[But03] Russell Butek. Which style of WSDL should I use? Tech-nical report, IBM DeveloperWorks, October 2003. Avail-able from: http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/ [cited 28 Septem-ber 2005].

[CCMW01] Erik Christensen, Francisco Curbera, Greg Meredith, and San-jiva Weerawarana. Web services description language (WSDL) 1.1,March 2001. Available from: http://www.w3.org/TR/wsdl[cited 28 September 2005].

[CEM03] Charles E. Campbell, Andrew Eisenberg, and Jim Melton. XMLschema. SIGMOD Rec., 32(2):96–101, 2003.

[Cla02] James Clark. RELAX NG compact syntax, November 2002. Avail-able from: http://www.oasis-open.org/committees/relax-ng/compact-20021121.html [cited 28 September2005].

69

http://www.w3.org/TR/webarch/

http://www.w3.org/TR/webarch/

http://www.w3.org/TR/xmlschema-2/


http://www.xml.com/pub/a/ws/2001/04/04/soap.html

http://www.xml.com/pub/a/ws/2001/04/04/soap.html

http://www.w3.org/TR/REC-xml/

http://www.w3.org/TR/REC-xml/

http://www.w3.org/TR/xml11/

http://www.w3.org/TR/xml11/

http://www.gsmworld.com/technology/gprs/intro.shtml

http://www.gsmworld.com/technology/gprs/intro.shtml

http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/

http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/

http://www.w3.org/TR/wsdl

http://www.oasis-open.org/committees/relax-ng/compact-20021121.html

http://www.oasis-open.org/committees/relax-ng/compact-20021121.html

[Cla05] Gavin Clarke. Get serious, IBM and Nokia tell developers, June2005. Available from: http://www.theregister.co.uk/2005/06/30/nokia_ibm_mobile/ [cited 28 September 2005].

[ClS03] Aske Simon Christensen, Anders Møller, and Michael I.Schwartzbach. Extending java for high-level web service con-struction. ACM Trans. Program. Lang. Syst., 25(6):814–875, 2003.

[CM01] James Clark and Makoto Murata. RELAX NG specification, De-cember 2001. Available from: http://www.oasis-open.org/committees/relax-ng/spec-20011203.html [cited28 September 2005].

[Cor05] Nokia Corporation. Nokia announces next generation Java plat-form for Series 60, June 2005. Available from: http://press.nokia.com/PR/200506/1000239_5.html [cited 28 Septem-ber 2005].

[Cos03] Roger L. Costello. Building Web services the REST way,January 2003. Available from: http://www.xfront.com/REST-Web-Services.html [cited 28 September 2005].

[Cow03] John Cowan. RELAX NG: DTDs on warp drive [online]. 2003 [cited14 September 2005]. Available from: http://www.ccil.org/~cowan/relaxng.pdf .

[Cow05] John Cowan. RESTful Web services [online]. 2005 [cited 14September 2005]. Available from: http://www.ccil.org/~cowan/restws.pdf .

[CT04] John Cowan and Richard Tobin. XML information set (secondedition), February 2004. Available from: http://www.w3.org/TR/xml-infoset/ [cited 28 September 2005].

[EAA+04] Mark Endrei, Jenny Ang, Ali Arsanjani, Sook Chua, PhilippeComte, Pål Krogdahl, Min Luo, and Tony Newling. Patterns: Ser-vice Oriented Architecture and Web Services. IBM Corporation, 1stedition, April 2004.

[Ecl] Eclipse project [online, cited 28 September 2005]. Available from:http://www.eclipse.org .

[EY03] Jon Ellis and Mark Young. JSR-172: J2METM webservices specification, October 2003. Available from:http://jcp.org/aboutJava/communityprocess/final/jsr172/index.html [cited 28 September 2005].

[FGM+99] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach,and T. Berners-Lee. Hypertext transfer protocol – HTTP/1.1,June 1999. Available from: http://www.ietf.org/rfc/rfc2616.txt [cited 28 September 2005].

70

http://www.theregister.co.uk/2005/06/30/nokia_ibm_mobile/

http://www.theregister.co.uk/2005/06/30/nokia_ibm_mobile/

http://www.oasis-open.org/committees/relax-ng/spec-20011203.html

http://www.oasis-open.org/committees/relax-ng/spec-20011203.html

http://press.nokia.com/PR/200506/1000239_5.html

http://press.nokia.com/PR/200506/1000239_5.html

http://www.xfront.com/REST-Web-Services.html

http://www.xfront.com/REST-Web-Services.html

http://www.ccil.org/~cowan/relaxng.pdf

http://www.ccil.org/~cowan/relaxng.pdf

http://www.ccil.org/~cowan/restws.pdf

http://www.ccil.org/~cowan/restws.pdf

http://www.w3.org/TR/xml-infoset/

http://www.w3.org/TR/xml-infoset/

http://www.eclipse.org

http://jcp.org/aboutJava/communityprocess/final/jsr172/index.html


http://www.ietf.org/rfc/rfc2616.txt

http://www.ietf.org/rfc/rfc2616.txt

[Fie00] Roy Thomas Fielding. Architectural Styles and the Design ofNetwork-based Software Architectures. PhD thesis, University ofCalifornia, Irvine, 2000. Available from: http://www1.ics.uci.edu/%7Efielding/pubs/dissertation/top.htm[cited 28 September 2005].

[FN] Forum Nokia [online, cited 28 September 2005]. Available from:http://www.forum.nokia.com .

[Gar05] Jesse James Garrett. AJAX: A new approach to web applications,February 2005. Available from: http://www.adaptivepath.com/publications/essays/archives/000385.php[cited 16 September 2005].

[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlis-sides. Design patterns: elements of reusable object-oriented software.Addison–Wesley, 1995.

[GHM+03a] Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-JacquesMoreau, and Henrik Frystyk Nielsen. SOAP version 1.2 part 1:Messaging framework, June 2003. Available from: http://www.w3.org/TR/soap12-part1/ [cited 28 September 2005].

[GHM+03b] Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-JacquesMoreau, and Henrik Frystyk Nielsen. SOAP version 1.2 part 2:Adjuncts, June 2003. Available from: http://www.w3.org/TR/soap12-part2/ [cited 28 September 2005].

[GJSB05] James Gosling, Bill Joy, Guy L. Steele Jr., and Gilad Bracha. JavaLanguage Specification. Addison–Wesley Professional, 3rd edition,2005. Available from: http://java.sun.com/docs/books/jls/index.html [cited 28 September 2005].

[GM] Google maps [online, cited 28 September 2005]. Available from:http://maps.google.com/ .

[Gooa] Google Web APIs [online, cited 15 September 2005]. Availablefrom: http://www.google.com/apis/ .

[Goob] Google adwords APIs [online, cited 14 September 2005]. Availablefrom: http://www.google.com/apis/adwords/ .

[GS05] J. Gregorio and R. Sayre. The Atom publishing proto-col, May 2005. Available from: http://www.ietf.org/html.charters/atompub-charter.html [cited 19 Septem-ber 2005].

[GT02] David Gourley and Brian Totty. HTTP: The Definitive Guide.O’Reilly Media Inc., September 2002.

[Har02] Elliotte Rusty Harold. The XMLPULL API, August 2002.Available from: http://www.xml.com/pub/a/2002/08/14/xmlpull.html [cited 28 September 2005].

71

http://www1.ics.uci.edu/%7Efielding/pubs/dissertation/top.htm

http://www1.ics.uci.edu/%7Efielding/pubs/dissertation/top.htm

http://www.forum.nokia.com

http://www.adaptivepath.com/publications/essays/archives/000385.php

http://www.adaptivepath.com/publications/essays/archives/000385.php

http://www.w3.org/TR/soap12-part1/




http://java.sun.com/docs/books/jls/index.html

http://java.sun.com/docs/books/jls/index.html

http://maps.google.com/

http://www.google.com/apis/

http://www.google.com/apis/adwords/



http://www.xml.com/pub/a/2002/08/14/xmlpull.html

http://www.xml.com/pub/a/2002/08/14/xmlpull.html

[Har03a] Elliotte Rusty Harold. An introduction to StAX, September2003. Available from: http://www.xml.com/pub/a/2003/09/17/stax.html [cited 28 September 2005].

[Har03b] Elliotte Rusty Harold. What’s wrong with XML APIs (andhow to fix them) [online]. 2003 [cited 28 September2005]. Available from: http://www.cafeconleche.org/XOM/whatswrong/ .

[HCNS04] K. Hogg, P. Chilcott, M. Nolan, and B. Srinivasan. An evalua-tion of web services in the design of a b2b application. In CR-PIT ’26: Proceedings of the 27th conference on Australasian computerscience, pages 331–340, Darlinghurst, Australia, Australia, 2004.Australian Computer Society, Inc.

[He03] Hao He. What is service-oriented architecture?, September2003. Available from: http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html [cited 3 October 2005].

[He04] Hao He. Implementing REST Web services: Best practicesand guidelines, August 2004. Available from: http://www.xml.com/pub/a/2004/08/11/rest.html [cited 28 Septem-ber 2005].

[HHW+00] Arnaud Le Hors, Philippe Le Hégaret, Lauren Wood, GavinNicol, Jonathan Robie, Mike Champion, and Steve Byrne. Doc-ument object model (DOM) level 2 core specification. Technicalreport, W3C, November 2000. Available from: http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/ [cited3 October 2005].

[HHW+04] Arnaud Le Hors, Philippe Le Hégaret, Lauren Wood, GavinNicol, Jonathan Robie, Mike Champion, and Steve Byrne. Doc-ument object model (DOM) level 3 core specification. Technicalreport, W3C, April 2004. Available from: http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/ [cited 3 Oc-tober 2005].

[JCP] The Java community process program [online, cited 28 Septem-ber 2005]. Available from: http://www.jcp.org .

[JDO] JDOM [online, cited 3 October 2005]. Available from: http://www.jdom.org/ .

[Jel02] Rick Jelliffe. The Schematron assertion language 1.5, October2002. Available from: http://xml.ascc.net/resource/schematron/Schematron2000.html [cited 28 September2005].

[JSR03] JSR-173: Streaming API for XML specification, October2003. Available from: http://jcp.org/aboutJava/communityprocess/final/jsr173/index.html [cited 28September 2005].

72

http://www.xml.com/pub/a/2003/09/17/stax.html

http://www.xml.com/pub/a/2003/09/17/stax.html

http://www.cafeconleche.org/XOM/whatswrong/

http://www.cafeconleche.org/XOM/whatswrong/

http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html

http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html

http://www.xml.com/pub/a/2004/08/11/rest.html

http://www.xml.com/pub/a/2004/08/11/rest.html

http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/




http://www.jcp.org

http://www.jdom.org/

http://www.jdom.org/

http://xml.ascc.net/resource/schematron/Schematron2000.html

http://xml.ascc.net/resource/schematron/Schematron2000.html



[KCVG+04] John Kemp, Carolina Canales-Valenzuela, Britta Glade,Paul Madsen, and Jason Rouault. Liberty ID-WSF ? aWeb services framework, 2004. Available from: https://www.projectliberty.org/resources/whitepapers/Liberty_ID-WSF_Web_Services_Framework.pdf [cited28 September 2005].

[KR03] Paul Kulchenko and Byrne Reese. Perl SOAP::Lite 0.60. CPAN,2003. Available from: http://search.cpan.org/~byrne/SOAP-Lite-0.60a/lib/SOAP/Lite.pm [cited 15 September2005].

[LC00] Dongwon Lee and Wesley W. Chu. Comparative analysis of sixXML schema languages. SIGMOD Rec., 29(3):76–87, 2000.

[Lib] Liberty Alliance Project [online, cited 28 September 2005]. Avail-able from: http://www.projectliberty.org/ .

[Mah04a] Michael Mahan. Fixed and Mobile Web Services, chapter 14. JohnWiley & Sons, Inc., 2004.

[Mah04b] Qusay H. Mahmoud. J2ME luminary antero taivalsaari.Sun Developer Network, January 2004. Available from:http://developers.sun.com/techtopics/mobility/midp/luminaries/taivalsaari/ [cited 28 September 2005].

[MC] Motocoder [online, cited 28 September 2005]. Available from:http://www.motocoder.com/motorola/pcsHome.jsp .

[McC02] James McCarthy. Reap the benefits of document styleWeb services. IBM Developer Works, June 2002. Avail-able from: http://www-128.ibm.com/developerworks/webservices/library/ws-docstyle.html [cited 28 Sep-tember 2005].

[Med] MIME media types [online, cited 28 September 2005]. Avail-able from: http://www.iana.org/assignments/media-types/index.html .

[Mit03] Nilo Mitra. SOAP version 1.2 part 0: Primer, June 2003. Avail-able from: http://www.w3.org/TR/soap12-part0/ [cited28 September 2005].

[Nic05] James Niccolai. JavaOne: Java spec promises better mobile expe-rience, June 2005. Available from: http://www.infoworld.com/article/05/06/24/HNjavamobile_1.html [cited 28September 2005].

[NITiM04] Masahide Nakamura, Hiroshi Igaki, Haruaki Tamada, and Kenichi Matsumoto. Implementing integrated services of networkedhome appliances using service oriented architecture. In ICSOC’04: Proceedings of the 2nd international conference on Service orientedcomputing, pages 269–278, New York, NY, USA, 2004. ACM Press.

73

https://www.projectliberty.org/resources/whitepapers/Liberty_ID-WSF_Web_Services_Framework.pdf



http://search.cpan.org/~byrne/SOAP-Lite-0.60a/lib/SOAP/Lite.pm

http://search.cpan.org/~byrne/SOAP-Lite-0.60a/lib/SOAP/Lite.pm

http://www.projectliberty.org/

http://developers.sun.com/techtopics/mobility/midp/luminaries/taivalsaari/

http://developers.sun.com/techtopics/mobility/midp/luminaries/taivalsaari/

http://www.motocoder.com/motorola/pcsHome.jsp

http://www-128.ibm.com/developerworks/webservices/library/ws-docstyle.html

http://www-128.ibm.com/developerworks/webservices/library/ws-docstyle.html

http://www.iana.org/assignments/media-types/index.html

http://www.iana.org/assignments/media-types/index.html


http://www.infoworld.com/article/05/06/24/HNjavamobile_1.html

http://www.infoworld.com/article/05/06/24/HNjavamobile_1.html

[Nok] Nokia Corporation. Series 60 3rd Edition API Reference Guide.Available with the Nokia Series 60 3rd Edition SDK for SymbianOS. Available from: http://www.forum.nokia.com/ .

[NR04] Henrik Frystyk Nielsen and Hervé Ruellan. SOAP 1.2 attachmentfeature, June 2004. Available from: http://www.w3.org/TR/soap12-af/ [cited 28 September 2005].

[Nyh04] Heli Nyholm. Variation-tolerant XML messaging in service-oriented systems. Master’s thesis, Helsinki University of Tech-nology, 2004.

[Osw05] Ed Oswald. Nokia to expand Java in mobile phones, June2005. Available from: http://www.betanews.com/article/Nokia_to_Expand_Java_in_Mobile_Phones/1119885488 [cited 28 September 2005].

[Pil02] Mark Pilgrim. What is RSS?, December 2002. Avail-able from: http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html [cited 28 September 2005].

[Pil04] Mark Pilgrim. The myth of RSS compatibility, February 2004.Available from: http://diveintomark.org/archives/2004/02/04/incompatible-rss [cited 28 September 2005].

[Prery] Paul Prescod. Second generation Web services, 2002 Febru-ary. Available from: http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html [cited 28 September 2005].

[RHJ99] Dave Raggett, Arnaud Le Hors, and Ian Jacobs. HTML 4.01 spec-ification, December 1999. Available from: http://www.w3.org/TR/html4/ [cited 4 October 2005].

[RNG02] Document schema definition languages (DSDL) – part 2: Reg-ular grammar-based validation – RELAX NG, 2002. Availablefrom: http://www.y12.doe.gov/sgml/sc34/document/0362_files/relaxng-is.pdf [cited 3 August 2005].

[S60a] Python for Series 60 [online, cited 28 September 2005].Available from: http://www.forum.nokia.com/main/0,,034-821,00.html .

[S60b] Python for Series 60 pyexpat [online, cited 28 September 2005].Available from: http://pdis.hiit.fi/pdis/download/pyexpat/ .

[Sal03] Rich Salz. SOAP 1.2, June 2003. Available from:http://webservices.xml.com/pub/a/ws/2003/06/10/salz.html [cited 28 September 2005].

[Sal04] Rich Salz. WSDL 2.0: Just say no, November 2004. Availablefrom: http://webservices.xml.com/pub/a/ws/2004/11/17/salz.html [cited 28 September 2005].

74

http://www.forum.nokia.com/

http://www.w3.org/TR/soap12-af/

http://www.w3.org/TR/soap12-af/

http://www.betanews.com/article/Nokia_to_Expand_Java_in_Mobile_Phones/1119885488



http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html

http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html

http://diveintomark.org/archives/2004/02/04/incompatible-rss

http://diveintomark.org/archives/2004/02/04/incompatible-rss

http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html

http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html

http://www.w3.org/TR/html4/

http://www.w3.org/TR/html4/

http://www.y12.doe.gov/sgml/sc34/document/0362_files/relaxng-is.pdf

http://www.y12.doe.gov/sgml/sc34/document/0362_files/relaxng-is.pdf

http://www.forum.nokia.com/main/0,,034-821,00.html

http://www.forum.nokia.com/main/0,,034-821,00.html

http://pdis.hiit.fi/pdis/download/pyexpat/

http://pdis.hiit.fi/pdis/download/pyexpat/

http://webservices.xml.com/pub/a/ws/2003/06/10/salz.html




[Sal05] Rich Salz. Freeze the core, January 2005. Availablefrom: http://webservices.xml.com/pub/a/ws/2005/01/12/salz.html [cited 28 September 2005].

[SAX] Simple API for XML [online, cited 28 September 2005]. Availablefrom: http://www.saxproject.org/ .

[Sch05] Ephraim Schwartz. Nokia and Sun prep Java for handsets,June 2005. Available from: http://www.infoworld.com/article/05/06/28/HNmobilejava_1.html [cited 28 Sep-tember 2005].

[SMM04] Elias Sinderson, Vish Magapu, and Ronald Mak. Middlewareand web services for the collaborative information portal ofNASA’s Mars exploration rovers mission. In Proceedings of the 5thACM/IFIP/USENIX international conference on Middleware, pages1–17, New York, NY, USA, 2004. Springer-Verlag New York, Inc.

[Sym] Symbian Ltd. Symbian OS SDK v8.1a Documentation. Availablefrom: http://www.symbian.com/developer/techlib/v8.1adocs/index.asp [cited 28 September 2005].

[TAC05] Kerry Taylor, Tim Austin, and Mark Cameron. Charging for in-formation services in service-oriented architectures. In BSN ’05:Proceedings of the IEEE EEE05 international workshop on Businessservices networks, pages 16–24, Piscataway, NJ, USA, 2005. IEEEPress.

[Tai98] Antero Taivalsaari. Implementing a JavaTM virtual ma-chine in the Java programming language. Technical re-port, Sun Microsystem Laboratories, March 1998. Avail-able from: http://research.sun.com/techrep/1998/abstract-64.html [cited 28 September 2005].

[Tai99] Antero Taivalsaari. The Spotless system: Implementing aJavaTM system for the Palm connected organizer. Technicalreport, Sun Microsystem Laboratories, February 1999. Avail-able from: http://research.sun.com/techrep/1999/abstract-73.html [cited 28 September 2005].

[TBMM04] Henry S. Thompson, David Beech, Murray Maloney, and NoahMendelsohn. XML schema part 1: Structures second edition,October 2004. Available from: http://www.w3.org/TR/xmlschema-1/ [cited 28 September 2005].

[TR03] Douglas B. Terry and Venugopalan Ramasubramanian. CachingXML Web services for mobility. Queue, 1(3):70–78, 2003.

[Ude04] Jon Udell. The beauty of REST. xml.com, March 2004. Availablefrom: http://www.xml.com/pub/a/2004/03/17/udell.html [cited 28 September 2005].

75



http://www.saxproject.org/

http://www.infoworld.com/article/05/06/28/HNmobilejava_1.html

http://www.infoworld.com/article/05/06/28/HNmobilejava_1.html

http://www.symbian.com/developer/techlib/v8.1adocs/index.asp

http://www.symbian.com/developer/techlib/v8.1adocs/index.asp

http://research.sun.com/techrep/1998/abstract-64.html






http://www.xml.com/pub/a/2004/03/17/udell.html

http://www.xml.com/pub/a/2004/03/17/udell.html

[vdV01] Eric van der Vlist. Comparing XML schema languages, December2001. Available from: http://www.xml.com/pub/a/2001/12/12/schemacompare.html [cited 28 September 2005].

[vR05] Guido van Rossum. Python Reference Manual. Python SoftwareFoundation, release 2.4.1 edition, March 2005. Available from:http://www.python.org/doc/2.4.1/ref/ref.html[cited 28 September 2005].

[WiM] WiMAX technical information [online, cited 28 September2005]. Available from: http://www.wimaxforum.org/technology .

[Win] Dave Winer. RSS 2.0 specification. Available from: http://blogs.law.harvard.edu/tech/rss [cited 3 October 2005].

[Woo05] Bobby Woolf. Why do developers need an enterprise ser-vice bus? IBM Developer Works, August 2005. Avail-able from: http://www-128.ibm.com/developerworks/webservices/library/ws-whyesb/ [cited 04 October 2005].

[WTK] Sun Java Wireless Toolkit [online, cited 20 September 2005].Available from: http://java.sun.com/products/sjwtoolkit/index.html .

[XOM] XOM [online, cited 3 October 2005]. Available from: http://www.xom.nu/ .

[ZMCO04] Olaf Zimmermann, Sven Milinski, Michael Craes, and FrankOellermann. Second generation Web services-oriented archi-tecture in production in the finance industry. In OOPSLA ’04:Companion to the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, pages283–289, New York, NY, USA, 2004. ACM Press.

76

http://www.xml.com/pub/a/2001/12/12/schemacompare.html

http://www.xml.com/pub/a/2001/12/12/schemacompare.html

http://www.python.org/doc/2.4.1/ref/ref.html

http://www.wimaxforum.org/technology

http://www.wimaxforum.org/technology

http://blogs.law.harvard.edu/tech/rss

http://blogs.law.harvard.edu/tech/rss

http://www-128.ibm.com/developerworks/webservices/library/ws-whyesb/

http://www-128.ibm.com/developerworks/webservices/library/ws-whyesb/

http://java.sun.com/products/sjwtoolkit/index.html

http://java.sun.com/products/sjwtoolkit/index.html

http://www.xom.nu/

http://www.xom.nu/

A RSS Reader performance measurements

The Symbian OS on the phone used has timer ticks of 1/64 second. This limitsthe accuracy of time measurements to a theoretical maximum of ±15.625 ms,but in practice the real time is at least the measured time but no more than 1/64second more than measured, due to the way timers work.

Feed names and the respective URLs. Note that the feeds change constantly,so the representations accessible from these URLs will most likely not be thesame as those that were used for measurements.

IBM SOA http://www-128.ibm.com/developerworks/views/webservices/rss/libraryview.jsp

BBC News http://news.bbc.co.uk/rss/newsonline_uk_edition/front_page/rss.xml

CNN http://rss.cnn.com/rss/cnn_topstories.rss

WP http://www.washingtonpost.com/wp-dyn/rss/linkset/2005/03/24/LI2005032400102.xml

Java http://www-128.ibm.com/developerworks/views/java/rss/libraryview.jsp

POWER http://www-128.ibm.com/developerworks/views/power/rss/libraryview.jsp

Johnston http://www-128.ibm.com/developerworks/blogs/dw_blog_rss.jspa?blog=352

Timings (ms) for different operations when using Nokia N90 handset. Theconnection time refers to the time it takes to set up a HTTP connection, parsetime refers to the time it takes to parse the stream, which includes both receiv-ing the data from the network and parsing it and enumeration refers to thetime needed to enumerate and display the contents of the feed.

77

http://www-128.ibm.com/developerworks/views/webservices/rss/libraryview.jsp

http://www-128.ibm.com/developerworks/views/webservices/rss/libraryview.jsp

http://news.bbc.co.uk/rss/newsonline_uk_edition/front_page/rss.xml

http://news.bbc.co.uk/rss/newsonline_uk_edition/front_page/rss.xml

http://rss.cnn.com/rss/cnn_topstories.rss

http://www.washingtonpost.com/wp-dyn/rss/linkset/2005/03/24/LI2005032400102.xml

http://www.washingtonpost.com/wp-dyn/rss/linkset/2005/03/24/LI2005032400102.xml

http://www-128.ibm.com/developerworks/views/java/rss/libraryview.jsp

http://www-128.ibm.com/developerworks/views/java/rss/libraryview.jsp

http://www-128.ibm.com/developerworks/views/power/rss/libraryview.jsp

http://www-128.ibm.com/developerworks/views/power/rss/libraryview.jsp

http://www-128.ibm.com/developerworks/blogs/dw_blog_rss.jspa?blog=352

http://www-128.ibm.com/developerworks/blogs/dw_blog_rss.jspa?blog=352

Feed Connection Parse EnumerationBBC News 12797 3937 1250BBC News 2078 4469 141BBC News 2859 3094 125BBC News 2344 3359 125BBC News 2281 3172 125IBM SOA 3219 8266 218IBM SOA 2250 7406 203IBM SOA 2406 8016 218IBM SOA 2265 13579 187IBM SOA 2328 9234 203IBM SOA 2359 7812 188CNN 2797 1218 44CNN 2157 1296 63CNN 2125 1750 47CNN 2125 1235 47WP 2344 234 32WP 2125 266 0WP 2328 250 0WP 2297 234 31WP 2187 250 0

Timings (ms) for different operations when using Nokia N90 handset, mea-sured later on with newer OS and library versions. The client software usedwas the same as in the previous table, as was the testing methodology.

Feed Connection Parse EnumerationJava 3703 4313 390

2953 3000 3603235 4640 3443031 3906 3444375 2890 3443407 3468 360

POWER 2828 3359 3603016 3203 3442906 2844 3442813 3171 3602937 2766 3442938 2984 359

Johnston 3516 2891 472844 3000 782734 3094 624313 1515 473062 2688 475047 3156 47

The number of items and the size (in bytes) of each feed tested.

78

Feed Items SizeInquirer 40 10022IBM SOA 50 35196BBC News 30 14797CNN 9 4467WP 3 2400

IBM Java 50 37986IBM POWER 40 30572Simon Johnston 5 24107

Speeds of opening a HTTP connection and downloading a 35 196 byte XMLfile, the IBM SOA feed. Connecting time is, as in the other tests, the time toset up a HTTP connection. The time to read the stream is simply measured asreading the data into memory a few kilobytes at a time, discarding old data aswe go along, until the stream is closed. Freeing resources is the time it takesto close all connections. Values separated by rules were measured with a largetemporal interval between them.

Day Connecting Reading stream Freeing resourcesDay 1 2859 4312 0

2875 3156 03109 5891 03047 4312 03094 4000 0

4187 4782 0

2969 4141 0

5860 4719 03328 3984 0

3360 3609 0

2781 3391 0

Day 2 2531 2953 01063 4812 0

Parse times for a XML file loaded from the phone’s file system on a N90.The IBM SOA feed was saved as a file in the phone and it was read in the ap-plication with a method similar to that used to download the same feed usingHTTP. A new session start means that the application was restarted betweenattempts.

79

Bytes Time (ms) Notes35 196 531

422359734 New session610688687 New session844421500500422

14 797 656375235187187625 New session312313187188

Times (ms) for different operations when using Nokia N90 handset, usinga Python client. The total time is the time used to both connect to the serviceand download and parse the feed.

Feed Total timePOWER 5950

9830613065505890641069105280

128401039036402800566063906520

80

Documents

Service Oriented Architecture in Mobile Devices: … · JAX-RPC Java API for XML-based RPC JCP Java Community Process JMS Java Message Service JSR Java Speciﬁcation Request, speciﬁcations