Mobile devices as Web service providers

Master Thesis Mobile devices as Web service providers Magnus Agust Skulason, s061720@student.dtu.dk Kongens Lyngby 2008 IMM-MSC-2008-89

Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 reception@imm.dtu.dk www.imm.dtu.dk

Summary Although mobile devices are capable of requesting Web services, little has been done in serving Web services from mobile devices. In this thesis the possibilities of serving Web services from mobile devices are explored and a framework for managing services and controlling access to Web services is proposed. Also an interface for describing the characteristics of a mobile phone through services and operations is suggested. Further, the thesis discusses how communication with the device can be optimized through the use of Web services. Finally a case study application using the Web service framework and standard interface is illustrated. Keywords Mobile, Mobile Device, SOA, Web Services, Mobile Web, Mobile hosted Web services.

Preface This thesis was prepared in the Department of Informatics and Mathematical Modelling at the Technical University of Denmark, in partial fulfillment of the requirements for acquiring the M.Sc. degree in engineering. This M.Sc. thesis is the result of work carried out in the period from 10th of March 2008 until 10th of September 2008, with the amount of 30 ECTS points workload. Kongens Lyngby, Denmark, September 2008 Magnus Agust Skulason

Acknowledgements First and foremost, I would like to thank my supervisors at DTU, professor Hubert Baumeister and professor Jakob Eg. Larsen, for their time and help during the thesis period. I especially thank them for their advise and guidance both in our meetings and through email. I would also like to thank all my other teachers both at DTU and the University of Iceland for all their good guidance and interesting lectures over the years. I would also like to thank the people at Nokia who are working on the Mobile Web Server project, both for their support and the project in general. Special thanks go to Johan Wikman for his good replies on various questions. Also I would like to thank all the other contributors on the Nokia developer discussion forum. Last but not least I would like to thank my family that has always supported and encouraged me during my education.

Contents Contents 6 List of Figures 8 1 Introduction 1 1.1 Mobile Hosted Web Services..................... 1 1.2 Preconditions............................. 2 1.3 Problem statement.......................... 3 1.4 Thesis outline............................. 3 2 Web Services 5 2.1 Architecture.............................. 5 2.2 Extensible Markup Language (XML)................ 7 2.3 SOAP.................................. 8 2.4 WSDL.................................. 10 2.5 UDDI.................................. 13 2.6 Other WS-* standards......................... 13 2.7 REST.................................. 15 3 Mobile Hosted Web Services 18 3.1 Use Cases............................... 18 3.2 Mobile Web Service Framework Requirements.......... 20 3.3 Related work.............................. 21 3.4 Mobile Web Servers.......................... 23 3.5 Web Service Processing Engines................... 28 3.6 Trends in mobile software development.............. 30 4 Mobile Web Service Framework Design 33 4.1 Functional Requirement....................... 33 4.2 Architecture.............................. 34 4.3 Extending the Mobile Web Service Framework.......... 38 4.4 Securing the Mobile Web Service Framework........... 38 5 Mobile Web Service Framework Implementation 44 5.1 Introduction.............................. 44 5.2 PyS60 SOAP processing....................... 44 5.3 Overview................................ 48 5.4 Database................................ 50 5.5 SOAPServer Interface......................... 50 6

5.6 Webservices module......................... 52 5.7 Common Classes........................... 52 5.8 Service Implementations....................... 57 5.9 Thread launcher............................ 60 5.10 Management interface........................ 61 5.11 WSDL Interface............................ 62 5.12 Create Policy.............................. 62 5.13 Limitations of the platform..................... 63 6 Mobile Web Services API Description 65 6.1 Interface requirements........................ 66 6.2 Functionality.............................. 67 6.3 Interface Design............................ 69 6.4 Implemented services........................ 72 6.5 Future directions........................... 79 7 Extending the Gateway 81 7.1 Server responsibilities........................ 81 7.2 Architecture.............................. 82 8 A case study: mobcal 87 8.1 Introduction.............................. 87 8.2 Application description....................... 87 8.3 Design................................. 88 8.4 Implementation............................ 92 8.5 Future directions........................... 93 9 Conclusion and further work 95 A Mobile Web Service Interface 98 B WSDL Interface 101 C Install services 127 D Packing and Installing 128 D.1 Packing................................. 128 D.2 Installation............................... 129 E Screen shots 131 E.1 Management interface........................ 131 E.2 mobcal.com.............................. 133 F Bibliography 140 G Acronyms 145

List of Figures 2.1 The Service Oriented Architecture (SOA) Triangle [5]...... 6 2.2 Basic structure of WSDL 1.1..................... 11 3.1 PAOS Request-Response MEP [31]................. 23 3.2 Mobile Web Server security architecture [27, p. 137]....... 26 4.1 Mobile Web Services Framework Architecture.......... 35 4.2 Mobile Web Services Framework Architecture.......... 36 5.1 S60 Mobile Web Services Framework............... 49 5.2 Database structure.......................... 50 7.1 Maintaining and serving cache................... 84 7.2 Serving WSDL files.......................... 85 7.3 Overall gateway architecture.................... 86 8.1 Send meeting request to user, interaction............. 90 E.1 Management Interface, users and operations........... 131 E.2 Management Interface, installed services and service installation 132 E.3 User has logged in and his calendar entries for the current month are displayed............................. 133 E.4 Creating a new calendar entry................... 134 E.5 Updating an existing calendar entry................ 135 E.6 Changing user settings........................ 136 E.7 Request a meeting with the user.................. 137 E.8 After meeting has been successfully accepted.......... 138 E.9 If user not available at the desired time.............. 139 E.10 Meeting request sent to user.................... 139

Chapter 1 Introduction Today, Web services are widely used to realize loose coupling and provide distributed access between different information systems. More precisely, Web services are used to provide an abstract interface to information systems. The usual convention today is that an enterprise or a central service provider uses Web services to provide access to its infrastructure. Consumers of the Web services are then usually other entities within the organization, business partners or consumers, depending on the occasion. 1.1 Mobile Hosted Web Services Web Services are being used on mobile devices, where mobile device applications request a service on the Internet to access information, such as a stock quote. This has been possible for some time now and has been used in developed applications. At this point in time though, little has been done in providing Web services from mobile devices, called mobile hosted Web services, where an external application requests a Web service provided by the mobile device. Such Web services and their usability are the main topic for this thesis. Before continuing, it is appropriate to define what is meant by a Web service and a mobile hosted Web services. The World Wide Web Consortium (W3C), Web Service Architecture working group, defines a Web service as [47]: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with a XML serialization in conjunction with other Web-related standards.

2 CHAPTER 1. INTRODUCTION In addition to the above definition a mobile hosted Web service resides on and is served by a mobile device, operating over a wireless network. Services are requested by an external client that initiates the request on demand. No special limitations should be put on the device, meaning that it should be regular consumer mobile device. In this thesis, work has been conducted on a Nokia N95 Smartphone device. 1.2 Preconditions The main limiting factor in providing mobile hosted Web services has been associated with addressability of the device. Mobile devices have only been addressable through their phone number assigned by mobile operators. For mobile hosted Web services to be viable, the devices must be addressable through the same methods as commonly used by todays Web service implementations. This means that the device needs to be addressable through an IP address or URL and be able to receive incoming HTTP requests. Although mobile devices have data connections and can request Web sites from the Internet, the reverse, accessing mobile devices from the Internet, is usually not possible. Mobile devices are generally connected to the Internet either through the mobile operators GPRS/3G network or through a WLAN. Network connections provided by operators are usually guarded by a firewall that is often configured to drop all traffic originating from outside the network. Network Address Translation (NAT) is also usually employed so devices get assigned an internal IP address and not a publicly addressable IP address. The router at the edge of the network then applies the network address translation and all requests from within the network seem to originate from the router [26]. The same is usually the case for local area networks unless explicitly configured otherwise. Devices get local IP addresses assigned from the routers DHCP server and the router employs NAT to provide network access to the internal addresses. The exception is that static NAT rules can be created in routers, mapping a certain incoming port to a certain local host. Also if the owner of the network has enough public IP addresses at his disposal, he can choose to assign a public address to every host. A special characteristic of mobile network TCP connections is that they are prone to become stale, meaning that after being ideal for some time the connection will be blocked and will only be activated again by a message sent from the device [26]. Furthermore, mobile IP addresses change frequently as the device owner travels between cells and networks. To summarize, networks are optimized for out-bound traffic and to protect the device from in-bound traffic. Previous work such as [24, 35, 29] has already elaborated on the technical feasibility of mobile hosted Web services in terms of speed and processing power, without tackling the addressability problem. A solution to the addressability problem has been proposed by Nokia in [26], the solution is based on an intermediary gateway maintaining a connection to the mobile device. The device connects to the gateway and the connection is maintained with reg-

1.3 Problem statement 3 ular keep-alive packets. The gateway then acts as an HTTP router and forwards incoming HTTP request to the appropriate mobile device. The solution has been realized in the form of http://www.mymobilesite.net/, providing a mobile Web server running on the mobile device addressable from the public Internet through a Uniform Resource Locator (URL) like https: //username.mymobilesite.net/. 1.3 Problem statement In the light of the addressability problem solved, the work in this thesis explores the possibilities in serving Web services from a mobile device and how their requirements differ from traditional Web services. Focus is not on whether technically possible, since previous work and an available mobile Web server already has given a good indication on that, rather on how such a solution would be realized. Today Web services are mainly provided by corporations and managed by their IT professionals. Clearly, deployment on a mobile device comes with a different set of requirements and capabilities. The mobile device is a feature rich personal device that the user constantly carries with him. Web services can be used to provide an abstract interface to those features and the user itself. This becomes especially interesting if different devices expose the same set of functionality through a unified interface. The goal is to build a framework for easily publishing Web services and controlling access to them on the mobile device. Investigate how current standards can be applied and what new possibilities are brought with the mobile device. Create an interface describing how the features and functionality of the mobile device can be expressed as Web services. Finally, implement a subset of services providing access to device functionality and create an application utilizing the services. 1.4 Thesis outline The thesis starts by introducing the main building blocks of Web services: XML, SOAP, WSDL and other related standards. Their application to mobile devices will be illustrated through use cases and from them the requirements for the Web service framework are drawn. Previous work that has been conducted in the field will be introduced and possible candidates for the main building blocks to realize the framework will be outlined. The design of the framework is illustrated and its implementation for the mobile device explained. Web services providing access to device functionality are then implemented

4 CHAPTER 1. INTRODUCTION for the framework and a Web service interface to the standard functionality of the device suggested. To better utilize the data connection and the limited resources of the mobile device, an extension to the connection gateway is proposed and described. It is based on the use of mobile Web services, defining a set of functionality that can be carried out by the gateway to limit the amount of needed requests to the device. A case study application has been implemented, utilizing Web services of the mobile Web service framework to access calendar information on a device. The case study is about synchronizing the calendar information with another calendar service and implement a use case where the owner of a device can allow visitors on a Web site to order a meeting with him. Because of the scope of the case study the usage of the device calendar is in focus throughout the thesis, for example when describing use cases and Web services that have been implemented.

Chapter 2 Web Services Web service technologies and standards began to emerge around 2000 due to work and contributions from industry leaders, like IBM and Microsoft, to solve the need for distributed loose coupling between information systems. They have since been taken on by official standardization bodies like W3C [8] and the Organization for the Advancement of Structured Information Standards (OASIS) [9]. 2.1 Architecture Web services are a realization of a broader architectural paradigm, SOA. SOA is a service oriented approach to building information systems based on loosely coupled components (services) and dynamic binding. It has emerged over the last two decades out of key technology and business drivers such as the need to outsource noncore operations and the importance of business process reengineering. SOA achieves loose coupling through two architectural constraints: Firstly, interfaces of the system are defined with a universally available simple and ubiquitous interface that defines generic semantics for the system. Secondly, descriptive messages written with a constrained extensible schema are used to communicate through the interfaces [7]. Services are thus described in a uniform way and can be discovered and consumed of arbitrary clients. Generally a service is a well defined, self contained functionality encapsulated in a form that is readily consumable and understandable by clients. Services should possess the following basic attributes[7]: Services are consumer driven, implementing a function for the user. The user has no direct influence on specifically how the task is carried out by the service.

6 CHAPTER 2. WEB SERVICES A service should be self-describing. Users can learn by themselves how to construct messages for communicating with the service and fulfill the necessary requirements of the service. Independent of underlying technology. The service interface is independent of the specific technology run-time of the service provider and the service consumer. Thus parties are not constrained to specific hardware or software platforms. Discoverable. Consumers can automatically discover available services to use. The process of publishing, finding and binding to a service can be graphically illustrated as in figure 2.1. Figure 2.1: The SOA Triangle [5] The provider of the service publishes the interface of the service to a directory, the Discovery Facility. The interface includes information about supported operations, operational characteristics and details on how to access the service. Requesters in need of a specific service issue a Find operation on the Discovery Facility that results in a list of available services and their published interface. The requester uses the information from the interface to bind to the appropriate service. The overall process of discovering and binding to a service can happen dynamically at run time. Binding is the act of constructing and serializing the message to communicate with the service into the appropriate form which the service understands, and mapping it to the appropriate transportation protocol used by the service. Web services are a realization of the abstract SOA architectural principles. Web Service Description Language (WSDL) and SOAP are used to provide the basis of Web service technologies and handle the most fundamental aspects of describing the interface and providing the message format. Both of them limit themselvs to their fundamental functionality but support additional functionality through the use of extensions. The result is a flexible and scalable architecture able to handle different, complex and heterogeneous needs. Many additional standard extensions have evolved to address common needs like security and policy definition.

2.2 XML 7 2.2 XML XML is an abstract meta-language for describing markup languages, designed for delivering structured content over the Web. It does not define a fixed structure but rather few fundamental elements that can be used to define every other structure. It thus provides a general facility to define tags, their structural relationships and schematics. The current version of XML is 1.1 although the original 1.0 is still widely used [10]. XML has few basic building blocks: Elements, Attributes, Entity References, Comments, CDATA Sections, Processing instructions and Documents. Using those basic building blocks every arbitrary data structure can be realized and distributed in a XML document. XML documents start with a processing instruction line <?xml version="1.0"?> indicating the XML version of the document. XML Schema XML Schema is a document structuring and type definition specification based on XML being standardized by the W3C [11]. XML Schema makes it possible to define and restrict the structure of XML documents. Additionally it defines a set of primitive data types that can be used for constraining the data of elements and attributes. The simple data types can be extended and combined to define arbitrary complex type structures. The SOAP and WSDL specifications use XML Schema to constrain the messages and definitions. That is, to be a valid SOAP message, the XML must cohere to the SOAP XML Schema. Similarly a valid WSDL description must cohere to the WSDL XML Schema. XML Namespace Since various domains and applications use XML to define their data languages it is inevitable that many of those languages use the same tag names to represent different things. To differentiate between tags in each language XML uses Namespaces to scope elements. This introduces the concept of a Qualified Name (QName) where a QName is the combination of the namespace name and a local name. Namespaces are represented in the forms of Uniform Resource Identifier (URI)s. This ensures that an element defined in one namespace is treated differently than an element defined in another namespace. XML Infoset It is important to differentiate between the abstract notion of a XML documentation structure and the exact serialization of that structure into the well known anchor bracket textual encoded XML format. The reason is that the textual anchor XML representation is not very efficient in regarding to size and processing speed. Serializing the data into the textual representation and parsing that representation again into an object model introduces significant processing over head and increases data size. Although the textual representation is con-

8 CHAPTER 2. WEB SERVICES venient to work with, a binary encoded representation would in many cases be much more efficient. Especially when working with devices that have limited computational power, memory and low speed data connections like a mobile device. W3C XML Infoset Recomendation [12] is a specification that defines the abstract data set named XML Information Set (Infoset). XML Information Set is the abstract data model of a well-formed XML document. The XML 1.0 and XML 1.1 specifications can simply be viewed as a specific serialization of the Infoset. Other specifications that serialize the XML Infoset to binary format are being proposed, for example the Efficient XML by W3C Efficient XML Interchange Working Group [13], Fast Infoset by International Telecommunication Union - Telecommunication Standardization Section (ITU-T) [14] and the WAP Binary XML (WBXML) a part of the Wireless Application Protocol (WAP) [48]. Since the real power of XML lies on the Infoset level and since binary data can be extremely space efficient and fast to parse, such serialization address the biggest criticisms of XML while preserving its qualities [5]. 2.3 SOAP SOAP is a simple lightweight messaging mechanism based on XML for exchanging structured and typed information between services. The use of a standardized XML protocol for messaging between endpoints is the biggest differentiator that sets Web services apart form older distributed computing frameworks. Previous solutions like Common Object Request Broker Architecture (CORBA), Java 2 Platform, Enterprise Edition (J2EE) (RMI and JMS), and Distributed Component Object Model (DCOM) were all based on different and incompatible object models at the messaging level. Resulting in incompatible or cumbersome communication between a requester on one platform and a service on another [5, 1.2.1]. The SOAP Schema defines that SOAP messages should have a root tag <envelope>, thus a SOAP message is commonly referred to as the SOAP Envelope. Within the envelope SOAP defines two sub elements; an optional <Header> element and a mandatory <Body> element. Those elements are all defined within the SOAP namespace that is registered on the envelope tag. SOAP defines how a SOAP node should process the elements but not their content, that is specific to the application using them. Each element within the <header> tag is called a header block, no standard header blocks are defined by SOAP. Header blocks are an extension mechanism that provides a way for information to be passed within a SOAP message that are not part of the main application message payload. They usually contain requests on how the message should be processed or contain additional information needed for the processing, commonly security and policy information. Applications can define their own extension headers or use previously defined headers from other standards like WS-Security to pass the information. The <header> element

2.3 SOAP 9 can contain multiple header blocks. SOAP only defines one standard Body element and that is the <Fault> element used to indicate a failure in processing a SOAP message on either application or middleware layer. The Fault element has two mandatory elements <Code> and <Reason> and three optional elements <Detail>, <Node> and <Role>. The <Code> element contains a mandatory element <Value> that must contain one of the following codes: VersionMismatch, MustUnderstand, DataEncodingUnkown, Sender, Reciver their meaning is explained in the SOAP Version 1.2 Part 1: Messaging Framework [16, 5.4.6 SOAP Fault Codes, Table 4]. All those elements should be defined in the SOAP namespace. A simple SOAP message looks like: <soapenv:envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:cal="http://www.example.org/mobilewebservices/calendar/"> <soapenv:header/> <soapenv:body> <cal:getentry> <id>10</id> </cal:getentry> </soapenv:body> </soapenv:envelope> SOAP is designed to be passed through and processed by several SOAP nodes. The creator and sender of a SOAP message is called the initial SOAP sender, SOAP nodes in the message path are called SOAP intermediaries and the intended final receiver the ultimate SOAP receiver. A SOAP message might not reach the ultimate SOAP receiver if processing at an intermediary fails. The SOAP Body contains the message that is intended from the initial sender to the ultimate sender. Header blocks are used to supply additional information on the processing. There are tree standard attributes that are used to control how/where headers are processed within the message path: Role, mustunderstand and Relay. They can be used to target the header block at a specific node, force nodes to process a header block or relay it to another node in the message path. SOAP is defined independently of the underlying messaging transport mechanism and can be transmitted over different network protocols such as HTTP, SMTP and TCP/IP. A SOAP binding specifies how to serialize and map the SOAP Infoset to the specific transportation protocol used, so that it can be conveyed to the next node in the message path and restructured correctly. A binding is specified between each hop in the message path but not the entire path. The SOAP Infoset though is preserved throughout the entire message path while even being serialized to multiple transport protocols. The most commonly used SOAP binding is the HTTP Binding included in the SOAP specification [17]. It specifies the serialization of SOAP Infoset to XML 1.0 messages and mapping to HTTP methods.

10 CHAPTER 2. WEB SERVICES 2.4 WSDL WSDL (Web Service Description Language) is a XML based description language used to describe the interface of a Web service. It forms a contract between the service and its clients allowing authors to provide information about how to invoke the service. WSDL consists of two basic parts, abstract and concrete. The abstract part defines the operational behavior of the Web service, describing the data that go in to and come out of operations. The concrete part describes how and where to access a service implementation. WSDL does not describe or define the schematics of services, operations or data. That is WSDL by itself provides no information on the meaning of the operations or their data. This is an intentional limitation of the specification as it is meant to by simple, widely used and a common basis for service description. WSDL is instead extensible, and specific domain schematics are meant to be specified and standardized within each domain on top of WSDL. More specifically WSDL only specifies the message formats, the message interaction patterns, the way messages are represented on the wire, where and how messages should be sent. A WSDL description can by used to create code for both server and client interfaces, this can be done either manually or automatically by tools and frameworks. Web service implementation frameworks such as Apache Axis can read a WSDL description and generate the appropriate code stubs for the service. For service invocation they can also fetch the WSDL at runtime and create a dynamic binding. Two version exist of WSDL; 1.1 and 2.0, at the time of writing not all implementations support 2.0 as it is still quite new compared to the predecessor. To ease interoperability, WSDL 1.1 will be used in this project but in the following discussion relevant changes in WSDL 2.0 will be highlighted. Figure 2.2 shows the basic structure of a WSDL 1.1 document. The top level element is the <definitions> tag that contains all other definitions within the document. The definitions tag defines the targetnamespace attribute, the target namespace defines a relationship assertion among the definitions within the document. Namespaces used on other tags and attributes within the document can also be declared in the definitions tag. In WSDL 2.0 the top level element is named <descriptions>. Within <definitions> items of <types>, <messages>, <porttype>, <binding> and <service> are defined. The <types> and <messages> elements define the used data types and how they are mapped to messages. <porttype> defines the operations for the service and what messages it takes in and returns, this could be described as what the service does. How the service is to be interacted with is described by <binding> and the <port> element of <service> describes where the service is located. The <types>, <messages> and <porttype> are often refered to as the abstract part of the service since they provide an abstract description of the data model and message exchanges. Similarly the <binding> and <port> are often referred to as the concrete part

2.4 WSDL 11 Figure 2.2: Basic structure of WSDL 1.1 as they describe a specific method of interacting with a specific service. Types Defines the data types that are used in the exchange between the client and the server. The defined data types are referred to when constructing the messages for the operations. The types can be defined in data structure description language like W3C XML Schema, a Schema can be embedded directly in a <xsd:schema> element within the <types> element. Message In the <message> element the messages that the Web service exchanges are

12 CHAPTER 2. WEB SERVICES defined. Each message deceleration defines a single one-way message containing zero or multiple part elements. The part elements represent a single item that is to be sent or received. The part element has an optional type attribute that indicates the type of the part, it can reference XML Schema types directly and definitions from the <types> element. A sample message defining a part: <message name="getnamerequest"> <part name="name" type="xsd:string"> </message> PortType The <porttype> element defines the actual operations the Web service supports, with the <operation> element. Each operation groups together the messages from the <message> part that are exchanged in the operation. The <input> tag defines an incoming message and the <output> tag defines an outgoing message, each operation can at maximum have one of each but does not need to have any. Thus four kinds of operations are supported one-way (client request), request-response (client request / service response), solicitresponse (service request / client response) or notification (service request). A sample porttype deceleration defining an operation to request a name: <wsdl:porttype name="newporttype"> <wsdl:operation name="getname"> <wsdl:input message="tns:getnamerequest"/> <wsdl:output message="tns:getnameresponse"/> </wsdl:operation> </wsdl:porttype> In WSDL 2.0 the <porttype> element has been renamed to <interface> and the <message> element is eliminated, operation definitions instead refer directly to XML Schema element declarations [5]. Binding The <binding> element defines the protocol and data format details of how messages are to be formatted to interact with the operations of a specific port- Type (interface). WSDL is most commonly used to describe bindings to SOAP over HTTP POST. In WSDL 2.0 the HTTP binding has been extended to support all methods of the HTTP protocol, making it more suitable for REST style services. The SOAP over HTTP binding specifies how the <input> and <output> messages of an operation are formatted into a SOAP envelope and how the SOAP envelope is carried within HTTP. The SOAP binding has a style attribute that is used to choose between two

2.5 UDDI 13 possible binding styles; document and RPC. They define how the contents of the <soap:body> element will be structured. Document style is the default one. It is more flexible and provides a higher degree of interoperability. The input and output of an operation can also be defined by using literal or encoded. That is used to specify the serialization rules that SOAP clients and servers should perform to interpret the contents of the elements in the SOAP message. Literal means that the type definitions literally follow a XML schema definition. Encoding refers to the representation of application data in XML, and additional information might be needed to decode it. The encoding rules should be available at an URL specified by an encodingstyle attribute. Of these choices the document/literal provides the best interoperability, and is most recommended and supported. Service The <service> element specifies where a service is to be found using its <port> element. Multiple <port> elements can be contained within every single <service> element, each defining where a single porttype is offered via a given binding. Each <port> thus refers to a binding and defines the address at which that binding is offered. 2.5 UDDI Universal Description, Discovery, and Integration (UDDI) provides the role of a common place where services can be registered by providers and discovered by potential clients. UDDI has been implemented for finding and binding to appropriate services at run time. UDDI was meant for both public and private use. In public use companies could advertise their services and how clients could bind to them on a well known UDDI, working in a similar fashion to well known search engines. In private use companies could use UDDI within the enterprise to maintain the list of its Web services and possibly making it available to its partners. Of the two, UDDI has had greater success as a private registry within enterprises. 2.6 Other WS-* standards WS-Policy WS-Policy is a XML protocol specification to describe the policies of entities and enabling services and service consumers to specify their policy requirements. Policies include for example security requirements for services and quality of service needed by consumers [19].

14 CHAPTER 2. WEB SERVICES WS-Security WS-Security (WSS) is a standard for applying the common task of security to Web services developed via committee in Oasis-Open [18]. WS-Security describes how user name tokens, SAML tokens, signatures, certificates and encryption headers can be attached to SOAP messages. It will be described in more detail and its usage shown in chapter 4.4. Security Assertion Markup Language (SAML) SAML is a XML protocol for exchanging authentication and authorization data between identity providers and service providers. It is being standardized by the OASIS Security Services Technical Committee. In SOA architecture everything should be implemented as a service, SAML takes this assertion to the security domain by making it possible to implement security as a service. The service requester requests a SAML assertion token from the security service that he can use for identification to other services. Other services trust a token that can be validated to come from a trusted security service. SAML thus provides single sign on capabilities to the domain and eases the implementation and enforcement of security across the domain. WS-Trust Describes interfaces for security services that issue, validate, renew and cancel security tokens such as SAML assertions. WS-Trust describes a service called Security Token Service (STS) that provides a generic protocol for security token issuing, validation, renewal and cancellation. Clients authenticate themselves with WS-Security to the STS and describe the kind of token needed when requesting a token. SAML Protocol Describes the interface that a security service provides that returns its findings using SAML. It is simpler than WS-Trust working only with SAML assertions. WS-I The Web Services Interoperability Organization (WS-I) [40] is an open industry forum creating recommendations on the usage of Web service standards to ease interoperability between different partners. WS-I publishes profiles that contain a set of recommendation. By adhering to a WS-I profile Web service implementors increase the interoperability of their solutions. A WS-I profile thus defines a common ground for different Web service implementations. Some important specifications within the Basic profile are [41]: Messaging Usage of SOAP 1.1 at the messaging layer

2.7 REST 15 Mandatory namespace qualification on the children of the <soap:body> element Only literal encoding is allowed both with document and Remote Procedure Call (RPC) style bindings Receivers must handle envelopes in such a way that it appears that all checking of mandatory header blocks is performed before any actual processing Encourages usage of HTTP 1.1 at the transport layer HTTP request message must use the HTTP POST method A message must not use the HTTP Extension Framework Specifies the usage of HTTP response codes Service Description WSDL 1.1 should be used for service description XML version 1.0 should be used in the WSDL description For document style operations the <message> constructs must only have one part 2.7 REST Representational State Transfer (REST), is a different style to design Web services and distributed systems than described above. REST is not a standard nor a protocol. It is an architectural style first put forth in 2000 by Roy Thomas Fielding in his Phd thesis, Architectural Styles and the Design of Networkbased Software Architectures [20]. There Roy defines REST as an architectural style for distributed hypermedia systems. The key difference between REST and Web services as described here above reflects in the use of the hypermedia keyword. That is REST Web services are designed for the Web and its protocols and limit themselves to that area. As both architectures use the concepts of nodes and messaging between them, their important differences lie at the messaging and addressing level. As SOAP is designed to be tunneled through any transportation protocol all necessary information are convened within the SOAP envelope. As has been demonstrated it supports headers within the message, and the actual operation to conduct is stated within the envelopes body. The most common method of transferring SOAP messages is to tunnel them within the POST body of a HTTP request. REST on the other hand is designed to work with HTTP, the transportation protocol of the Web, and thus it is the only viable transportation method. Instead of convening all necessary information within the REST message it utilizes the features of the HTTP protocol. The REST architecture is centralized around using URLs to address entities and resources. Every interesting aspect or entity of a service should be made

16 CHAPTER 2. WEB SERVICES available through a unique URL, thus REST APIs can be classified as URL Languages [21]. Each URL Languages then vary in terms of their addressability, granularity, transparency and persistence [22]. A good definition of what is meant by addressability, in relation to REST Web services, is given in [22, p. 221]; Addressability means that every interesting aspect of your service is immediately accessible from outside. Every interesting aspect of your service has a URI: a unique identifier in a format that s familiar to every computer-literate person... Addressability makes it possible for others to make mashups of your service: to use it in ways you never imagined. Clients of the service then inter operate with the various resources, represented by URLs, through the use of the HTTP standard methods: GET, HEAD, PUT, DELETE and POST. Where GET is used to get the current state of the resource, DELETE is used to delete the resource, PUT is used to overwrite a resource and POST is used to create a new resource. This is very well in line with the original intention of those methods when they were created for the Web. What to act on is thus encoded in the URL of the resource and how to act on it is encoded in the HTTP method used. By contrast in SOAP, every message to the service is directed to one endpoint. What entity to act on in which way is encoded into the SOAP message in an application specific way. Further REST supports the use of linking between resources, that is one resource can link to one or multiple other resources. Thought of as a library service, this means that the resource at the URL of the library service would list links of available books in the library, the resource for each book would contain links to its authors and possibly pages within the book. REST does not go into specific details about the format of the messages exchanged, only that they can be contained in the body of a HTTP messages. Commonly used structures include simple XML structures, Atom, RSS, XHTML, XML Schema and JSON. JSON (JavaScript Object Notation) is a serialization of JavaScript objects into text form, and is beneficial when working with JavaScript clients. Then objects can quickly and easily be serialized to and from the textual representation. JSON format has been used extensively in Web sites driven by AJAX (Asynchronous JavaScript and XML) where JavaScript clients in browsers are used to fetch and update content after the page has been loaded. JSON serializes have also emerged for other programming languages like Java and Python. It is thus evident that REST architecture has more to do with the architectural design of applications for the Web than attempting to be a general architecture for distributed programming as traditional Web services with SOA. It is thus maybe understandable that REST architecture concepts have received quite a momentum and use on the Web. REST APIs in many cases better aligns with the traditional use of a service delivered through a Web site. Programmable

2.7 REST 17 Web 1, is a directory listing publicly known Web APIs, at the time of writing has 874 available APIs, 503 where classified as REST and 207 as SOAP. It should be noted though that many services publish both SOAP and REST APIs. However since REST is only a loosely defined architectural concept and not a precise standard, many variations exist and many of the classified REST APIs do not strictly follow the architectural style. In fact this is the case for most of the REST APIs of today. Those are for example services that fail to convey the method information within the HTTP method and use application specific query parameters. The result is that HTTP is simply used as an envelope for the message but not a part of the message. Another common deviation is to alter server state through a GET method and other improper use of the HTTP methods. Many services only use GET and POST and fail to utilize DELETE and PUT methods. The result ending up being an inconsistent service exchanging information through the use of HTTP query parameters and some arbitrary data structure like XML [22]. Development on REST frameworks in Ruby on Rails, Restlet (for Java) and Django (for Python) is likely to help impose more structure on developers creating RESTful Web services. It should also be noted that today REST based Web services do not have the same sophistication as SOAP based services when it comes to matter of advanced topics like security. There, SOAP hugely benefits from its extensible nature and open standards which have been built on top of it to solve commonly needed tasks. However the SOAP header extension standards could also be ported to HTTP headers and that has in fact been done to some extent [22]. The main limitation of REST Web services has been within the service description, WSDL 1.1, as described above is unfit for describing REST APIs since it does not support binding to all HTTP methods. Web Application Description Language (WADL) is a standard format that has been proposed to describe REST Web Services and Web applications in general. It has though not caught on and is not widely supported or used. Presently REST APIs are most commonly described in human readable documentations or providers, as Google release their own client libraries for their APIs. Thus they have not been good candidates for dynamic discovery and binding, described at the heart of SOA. As mentioned above, WSDL 2.0 has been improved to support bindings to all HTTP methods and can be used to describe REST APIs, WSDL design though tends to favor the use of a single endpoint making it not as optimal for REST [22]. A unified description method proposes the gain of abstracting away the actual message format used, making it more of an implementation flavor decision rather than the focal point of the service in question. 1 See http://www.programmableweb.com/apis/directory/

Chapter 3 Mobile Hosted Web Services This chapter turns the focus on serving Web services from mobile devices, by outlining their possible use cases. The Nokia Mobile Web Server project will be introduced as a solution to the addressability problem, making devices addressable by a URL. Other similar projects and SOAP processing engines suitable for mobile devices will also be introduced. Finally, two ongoing trends in mobile software development and how they relate to mobile hosted Web services will be discussed. 3.1 Use Cases In describing the possible use cases realizable through mobile web services the discussion here is concentrated around features related to the users calendar. Use cases for other perspectives can then be derived in a similar manner. The most obvious use of Web services in regards to the calendar services is to expose the calendar as a Web service with operations to retrieve, create, update and delete entries. They could then be used to implement another user interface to the devices calendar, a Web based interface or a PC client application. As well they could be used to synchronize the device calendar with other calendar sources and create backups of the calendar entries. Combining the previously described calendar service with services exposing different functionality of the mobile device opens up a new array or possible use cases. As an example, using a Web service to get approval from the mobile device owner, a new service could be created that enabled people to book a meeting with the owner of a device. Through an interface users could enter a meeting title, start and end date and send a Meeting request to the device owner. The service would check the owners calendar to see if the device owner is available at the specified time and if available, probe the device owner with the meeting request. If accepted, a new calendar entry would be created and the requesting user notified. If not accepted, either the device owner (in his

3.1 Use Cases 19 reply) or the end user could specify a new time and try again to reach an appropriate time. In the device calendar today, it is possible to get a reminder about a meeting X minutes in advance. Meetings usually take place at a specific location and that location can also be registered in the calendar entry. Through combination with a service exposing the current position of the device, it would be possible to extend the reminder to also contain information on how to get to the meeting. Further, by estimation of travelling time, the time of the reminder could be adjusted to it. This would be realized by using an external geological/- navigation service to get the travelling instructions and estimated travelling times. If other participants have been invited to a meeting, they could be sent an SMS notification in case it is foreseen that the device owner will be running late, realized using a Send SMS service and a contact book service to get the information about participants. Entries in the calendar usually contain a meaningful description (tags) provided by the device owner of what activities he was conducting at that time. During a meeting the user might use other resources of the device, for example take a photo of a black board, record a conversation or save a contact card. In an external client these information could be conveniently archived within the calendar entry. Marking a calendar event as public has many interesting perspectives. By elaborating on the previous use case, creating a public entry could be used to create a public media gallery with pictures, videos and recordings made within the entry time limits being automatically published. Creating a public event could also be used to propose a meeting or a get together with friends. Friends getting each others public calendar feeds could opt-in to such a get together or meeting suggestion. In the above discussion the terms Web service and service are used alternately. Web service refers to a mobile hosted Web service exposing a certain functionality, service on the other hand is used to refer to the consumer of the Web services that implements the use case to a user. The consumer of mobile hosted Web services can either be a centralized server application, PC application client, or a client on another mobile device. When a client resides on the mobile device it could be acting through a centralized service or in a Peer-To-Peer (P2P) manner, directly requesting services from another device. There is no clear cut definition of the difference between the two modes, but a P2P environment has no fixed assignment of client and servers, allowing all nodes to act equally [35]. Previous work [35] proposes an architecture for enabling mobile P2P Web services and concludes that Web services are a promising technology to simplify mobile P2P systems. When using Web services in a P2P fashion, service discovery is an interesting subject. Todays mobile P2P applications either rely on a central discovery server or built in support of the wireless network technologies, infrared, WLAN and Bluetooth for node discovery [49, 50]. Another simple approach would be to use the address book to store URLs to friends mobile devices, todays devices provide the possibility of associating a Website URL with a contact. This would allow for direct interaction from a client on one