mobile devices as web service providers - dtu electronic theses
TRANSCRIPT
Master Thesis
Mobile devices as Web serviceproviders
Magnus Agust Skulason, [email protected]
Kongens Lyngby 2008IMM-MSC-2008-89
Technical University of DenmarkInformatics and Mathematical ModellingBuilding 321, DK-2800 Kongens Lyngby, DenmarkPhone +45 45253351, Fax +45 [email protected]
SummaryAlthough mobile devices are capable of requesting Web services, little has beendone in serving Web services from mobile devices. In this thesis the possibili-ties of serving Web services from mobile devices are explored and a frameworkfor managing services and controlling access to Web services is proposed. Alsoan interface for describing the characteristics of a mobile phone through ser-vices and operations is suggested. Further, the thesis discusses how commu-nication with the device can be optimized through the use of Web services.Finally a case study application using the Web service framework and stan-dard interface is illustrated.
Keywords Mobile, Mobile Device, SOA, Web Services, Mobile Web, Mobilehosted Web services.
PrefaceThis thesis was prepared in the Department of Informatics and MathematicalModelling at the Technical University of Denmark, in partial fulfillment of therequirements for acquiring the M.Sc. degree in engineering.
This M.Sc. thesis is the result of work carried out in the period from 10th ofMarch 2008 until 10th of September 2008, with the amount of 30 ECTS pointsworkload.
Kongens Lyngby, Denmark, September 2008Magnus Agust Skulason
AcknowledgementsFirst and foremost, I would like to thank my supervisors at DTU, professor Hu-bert Baumeister and professor Jakob Eg. Larsen, for their time and help duringthe thesis period. I especially thank them for their advise and guidance bothin our meetings and through email. I would also like to thank all my otherteachers both at DTU and the University of Iceland for all their good guidanceand interesting lectures over the years.
I would also like to thank the people at Nokia who are working on the MobileWeb Server project, both for their support and the project in general. Specialthanks go to Johan Wikman for his good replies on various questions. Also Iwould like to thank all the other contributors on the Nokia developer discus-sion forum.
Last but not least I would like to thank my family that has always supportedand encouraged me during my education.
Contents
Contents 6
List of Figures 8
1 Introduction 11.1 Mobile Hosted Web Services . . . . . . . . . . . . . . . . . . . . . 11.2 Preconditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Web Services 52.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Extensible Markup Language (XML) . . . . . . . . . . . . . . . . 72.3 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 Other WS-* standards . . . . . . . . . . . . . . . . . . . . . . . . . 132.7 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Mobile Hosted Web Services 183.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Mobile Web Service Framework Requirements . . . . . . . . . . 203.3 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4 Mobile Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5 Web Service Processing Engines . . . . . . . . . . . . . . . . . . . 283.6 Trends in mobile software development . . . . . . . . . . . . . . 30
4 Mobile Web Service Framework Design 334.1 Functional Requirement . . . . . . . . . . . . . . . . . . . . . . . 334.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3 Extending the Mobile Web Service Framework . . . . . . . . . . 384.4 Securing the Mobile Web Service Framework . . . . . . . . . . . 38
5 Mobile Web Service Framework Implementation 445.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2 PyS60 SOAP processing . . . . . . . . . . . . . . . . . . . . . . . 445.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.4 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.5 SOAPServer Interface . . . . . . . . . . . . . . . . . . . . . . . . . 50
6
5.6 Webservices module . . . . . . . . . . . . . . . . . . . . . . . . . 525.7 Common Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.8 Service Implementations . . . . . . . . . . . . . . . . . . . . . . . 575.9 Thread launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.10 Management interface . . . . . . . . . . . . . . . . . . . . . . . . 615.11 WSDL Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.12 Create Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.13 Limitations of the platform . . . . . . . . . . . . . . . . . . . . . 63
6 Mobile Web Services API Description 656.1 Interface requirements . . . . . . . . . . . . . . . . . . . . . . . . 666.2 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.3 Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.4 Implemented services . . . . . . . . . . . . . . . . . . . . . . . . 726.5 Future directions . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7 Extending the Gateway 817.1 Server responsibilities . . . . . . . . . . . . . . . . . . . . . . . . 817.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8 A case study: mobCal 878.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878.2 Application description . . . . . . . . . . . . . . . . . . . . . . . 878.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928.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 128D.1 Packing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128D.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
E Screen shots 131E.1 Management interface . . . . . . . . . . . . . . . . . . . . . . . . 131E.2 mobCal.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
F Bibliography 140
G Acronyms 145
List of Figures
2.1 The Service Oriented Architecture (SOA) Triangle [5] . . . . . . 62.2 Basic structure of WSDL 1.1 . . . . . . . . . . . . . . . . . . . . . 11
3.1 PAOS Request-Response MEP [31] . . . . . . . . . . . . . . . . . 233.2 Mobile Web Server security architecture [27, p. 137] . . . . . . . 26
4.1 Mobile Web Services Framework Architecture . . . . . . . . . . 354.2 Mobile Web Services Framework Architecture . . . . . . . . . . 36
5.1 S60 Mobile Web Services Framework . . . . . . . . . . . . . . . 495.2 Database structure . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1 Maintaining and serving cache . . . . . . . . . . . . . . . . . . . 847.2 Serving WSDL files . . . . . . . . . . . . . . . . . . . . . . . . . . 857.3 Overall gateway architecture . . . . . . . . . . . . . . . . . . . . 86
8.1 Send meeting request to user, interaction . . . . . . . . . . . . . 90
E.1 Management Interface, users and operations . . . . . . . . . . . 131E.2 Management Interface, installed services and service installation 132E.3 User has logged in and his calendar entries for the current month
are displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133E.4 Creating a new calendar entry . . . . . . . . . . . . . . . . . . . 134E.5 Updating an existing calendar entry . . . . . . . . . . . . . . . . 135E.6 Changing user settings . . . . . . . . . . . . . . . . . . . . . . . . 136E.7 Request a meeting with the user . . . . . . . . . . . . . . . . . . 137E.8 After meeting has been successfully accepted . . . . . . . . . . 138E.9 If user not available at the desired time . . . . . . . . . . . . . . 139E.10 Meeting request sent to user . . . . . . . . . . . . . . . . . . . . 139
Chapter 1
Introduction
Today, Web services are widely used to realize loose coupling and provide dis-tributed access between different information systems. More precisely, Webservices are used to provide an abstract interface to information systems. Theusual convention today is that an enterprise or a central service provider usesWeb services to provide access to its infrastructure. Consumers of the Web ser-vices are then usually other entities within the organization, business partnersor consumers, depending on the occasion.
1.1 Mobile Hosted Web Services
Web Services are being used on mobile devices, where mobile device applica-tions request a service on the Internet to access information, such as a stockquote. This has been possible for some time now and has been used in devel-oped applications. At this point in time though, little has been done in pro-viding Web services from mobile devices, called mobile hosted Web services,where an external application requests a Web service provided by the mobiledevice. 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 serviceand 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 interop-erable machine-to-machine interaction over a network. It has aninterface 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 a XML serialization in conjunction withother Web-related standards.
2 CHAPTER 1. INTRODUCTION
In addition to the above definition a mobile hosted Web service resides on andis served by a mobile device, operating over a wireless network. Services arerequested by an external client that initiates the request on demand. No spe-cial limitations should be put on the device, meaning that it should be regularconsumer mobile device. In this thesis, work has been conducted on a NokiaN95 Smartphone device.
1.2 Preconditions
The main limiting factor in providing mobile hosted Web services has been as-sociated with addressability of the device. Mobile devices have only been ad-dressable through their phone number assigned by mobile operators. For mo-bile hosted Web services to be viable, the devices must be addressable throughthe same methods as commonly used by todays Web service implementations.This means that the device needs to be addressable through an IP address orURL and be able to receive incoming HTTP requests.
Although mobile devices have data connections and can request Web sitesfrom the Internet, the reverse, accessing mobile devices from the Internet, isusually not possible. Mobile devices are generally connected to the Interneteither through the mobile operators GPRS/3G network or through a WLAN.Network connections provided by operators are usually guarded by a firewallthat is often configured to drop all traffic originating from outside the network.Network Address Translation (NAT) is also usually employed so devices getassigned an internal IP address and not a publicly addressable IP address. Therouter at the edge of the network then applies the network address translationand 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 con-figured otherwise. Devices get local IP addresses assigned from the routersDHCP server and the router employs NAT to provide network access to theinternal addresses. The exception is that static NAT rules can be created inrouters, mapping a certain incoming port to a certain local host. Also if theowner of the network has enough public IP addresses at his disposal, he canchoose to assign a public address to every host. A special characteristic of mo-bile network TCP connections is that they are prone to become stale, meaningthat after being ideal for some time the connection will be blocked and will onlybe activated again by a message sent from the device [26]. Furthermore, mobileIP addresses change frequently as the device owner travels between cells andnetworks. To summarize, networks are optimized for out-bound traffic and toprotect the device from in-bound traffic.
Previous work such as [24, 35, 29] has already elaborated on the technical fea-sibility of mobile hosted Web services in terms of speed and processing power,without tackling the addressability problem. A solution to the addressabil-ity problem has been proposed by Nokia in [26], the solution is based on anintermediary gateway maintaining a connection to the mobile device. Thedevice 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 for-wards incoming HTTP request to the appropriate mobile device. The solutionhas been realized in the form of http://www.mymobilesite.net/, pro-viding a mobile Web server running on the mobile device addressable fromthe 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 ex-plores the possibilities in serving Web services from a mobile device and howtheir requirements differ from traditional Web services. Focus is not on whethertechnically possible, since previous work and an available mobile Web serveralready has given a good indication on that, rather on how such a solutionwould be realized. Today Web services are mainly provided by corporationsand managed by their IT professionals. Clearly, deployment on a mobile de-vice comes with a different set of requirements and capabilities.
The mobile device is a feature rich personal device that the user constantlycarries with him. Web services can be used to provide an abstract interface tothose features and the user itself. This becomes especially interesting if differ-ent devices expose the same set of functionality through a unified interface.
The goal is to build a framework for easily publishing Web services and con-trolling access to them on the mobile device. Investigate how current standardscan be applied and what new possibilities are brought with the mobile device.Create an interface describing how the features and functionality of the mo-bile device can be expressed as Web services. Finally, implement a subset ofservices providing access to device functionality and create an application uti-lizing 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 andfrom them the requirements for the Web service framework are drawn. Previ-ous work that has been conducted in the field will be introduced and possiblecandidates for the main building blocks to realize the framework will be out-lined.
The design of the framework is illustrated and its implementation for the mo-bile 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 ofthe device suggested.
To better utilize the data connection and the limited resources of the mobiledevice, an extension to the connection gateway is proposed and described. Itis based on the use of mobile Web services, defining a set of functionality thatcan be carried out by the gateway to limit the amount of needed requests to thedevice.
A case study application has been implemented, utilizing Web services of themobile Web service framework to access calendar information on a device. Thecase study is about synchronizing the calendar information with another cal-endar service and implement a use case where the owner of a device can allowvisitors on a Web site to order a meeting with him. Because of the scope ofthe case study the usage of the device calendar is in focus throughout the the-sis, for example when describing use cases and Web services that have beenimplemented.
Chapter 2
Web Services
Web service technologies and standards began to emerge around 2000 due towork and contributions from industry leaders, like IBM and Microsoft, to solvethe need for distributed loose coupling between information systems. Theyhave since been taken on by official standardization bodies like W3C [8] andthe 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 isa service oriented approach to building information systems based on looselycoupled components (services) and dynamic binding. It has emerged over thelast two decades out of key technology and business drivers such as the need tooutsource noncore operations and the importance of business process reengi-neering.
SOA achieves loose coupling through two architectural constraints: Firstly,interfaces of the system are defined with a universally available simple andubiquitous interface that defines generic semantics for the system. Secondly,descriptive messages written with a constrained extensible schema are used tocommunicate through the interfaces [7].
Services are thus described in a uniform way and can be discovered and con-sumed of arbitrary clients. Generally a service is a well defined, self containedfunctionality encapsulated in a form that is readily consumable and under-standable by clients. Services should possess the following basic attributes[7]:
• Services are consumer driven, implementing a function for the user. Theuser has no direct influence on specifically how the task is carried out bythe service.
6 CHAPTER 2. WEB SERVICES
• A service should be self-describing. Users can learn by themselves howto construct messages for communicating with the service and fulfill thenecessary requirements of the service.
• Independent of underlying technology. The service interface is indepen-dent of the specific technology run-time of the service provider and theservice consumer. Thus parties are not constrained to specific hardwareor software platforms.
• Discoverable. Consumers can automatically discover available servicesto use.
The process of publishing, finding and binding to a service can be graphicallyillustrated 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 op-erations, operational characteristics and details on how to access the service.Requesters in need of a specific service issue a Find operation on the DiscoveryFacility that results in a list of available services and their published interface.The requester uses the information from the interface to bind to the appropriateservice. The overall process of discovering and binding to a service can happendynamically at run time. Binding is the act of constructing and serializing themessage to communicate with the service into the appropriate form which theservice understands, and mapping it to the appropriate transportation protocolused by the service.
Web services are a realization of the abstract SOA architectural principles. WebService Description Language (WSDL) and SOAP are used to provide the ba-sis of Web service technologies and handle the most fundamental aspects ofdescribing the interface and providing the message format. Both of them limitthemselvs to their fundamental functionality but support additional function-ality through the use of extensions. The result is a flexible and scalable ar-chitecture able to handle different, complex and heterogeneous needs. Manyadditional standard extensions have evolved to address common needs likesecurity and policy definition.
2.2 XML 7
2.2 XML
XML is an abstract meta-language for describing markup languages, designedfor delivering structured content over the Web. It does not define a fixed struc-ture but rather few fundamental elements that can be used to define everyother structure. It thus provides a general facility to define tags, their struc-tural relationships and schematics. The current version of XML is 1.1 althoughthe 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. Usingthose basic building blocks every arbitrary data structure can be realized anddistributed in a XML document. XML documents start with a processing in-struction line <?xml version="1.0"?> indicating the XML version of thedocument.
XML Schema
XML Schema is a document structuring and type definition specification basedon XML being standardized by the W3C [11]. XML Schema makes it possibleto define and restrict the structure of XML documents. Additionally it definesa set of primitive data types that can be used for constraining the data of ele-ments and attributes. The simple data types can be extended and combined todefine arbitrary complex type structures.
The SOAP and WSDL specifications use XML Schema to constrain the mes-sages and definitions. That is, to be a valid SOAP message, the XML mustcohere to the SOAP XML Schema. Similarly a valid WSDL description mustcohere to the WSDL XML Schema.
XML Namespace
Since various domains and applications use XML to define their data languagesit is inevitable that many of those languages use the same tag names to rep-resent different things. To differentiate between tags in each language XMLuses Namespaces to scope elements. This introduces the concept of a Qual-ified Name (QName) where a QName is the combination of the namespacename and a local name. Namespaces are represented in the forms of UniformResource Identifier (URI)s. This ensures that an element defined in one names-pace is treated differently than an element defined in another namespace.
XML Infoset
It is important to differentiate between the abstract notion of a XML documen-tation structure and the exact serialization of that structure into the well knownanchor bracket textual encoded XML format. The reason is that the textualanchor XML representation is not very efficient in regarding to size and pro-cessing speed. Serializing the data into the textual representation and parsingthat representation again into an object model introduces significant processingover 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 bemuch more efficient. Especially when working with devices that have limitedcomputational power, memory and low speed data connections like a mobiledevice.
W3C XML Infoset Recomendation [12] is a specification that defines the ab-stract data set named XML Information Set (Infoset). XML Information Set isthe abstract data model of a well-formed XML document. The XML 1.0 andXML 1.1 specifications can simply be viewed as a specific serialization of theInfoset. Other specifications that serialize the XML Infoset to binary format arebeing proposed, for example the Efficient XML by W3C Efficient XML Inter-change Working Group [13], Fast Infoset by International TelecommunicationUnion - Telecommunication Standardization Section (ITU-T) [14] and the WAPBinary 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 canbe extremely space efficient and fast to parse, such serialization address thebiggest criticisms of XML while preserving its qualities [5].
2.3 SOAP
SOAP is a simple lightweight messaging mechanism based on XML for ex-changing structured and typed information between services.
The use of a standardized XML protocol for messaging between endpoints isthe biggest differentiator that sets Web services apart form older distributedcomputing frameworks. Previous solutions like Common Object Request Bro-ker Architecture (CORBA), Java 2 Platform, Enterprise Edition (J2EE) (RMI andJMS), and Distributed Component Object Model (DCOM) were all based ondifferent and incompatible object models at the messaging level. Resulting inincompatible or cumbersome communication between a requester on one plat-form 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 SOAPEnvelope. Within the envelope SOAP defines two sub elements; an optional<Header> element and a mandatory <Body> element. Those elements areall defined within the SOAP namespace that is registered on the envelope tag.SOAP defines how a SOAP node should process the elements but not theircontent, that is specific to the application using them. Each element withinthe <header> tag is called a header block, no standard header blocks are de-fined by SOAP. Header blocks are an extension mechanism that provides a wayfor information to be passed within a SOAP message that are not part of themain application message payload. They usually contain requests on how themessage should be processed or contain additional information needed for theprocessing, commonly security and policy information. Applications can de-fine their own extension headers or use previously defined headers from otherstandards 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> ele-ment used to indicate a failure in processing a SOAP message on either appli-cation 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> thatmust contain one of the following codes: VersionMismatch, MustUnderstand,DataEncodingUnkown, Sender, Reciver their meaning is explained in the SOAPVersion 1.2 Part 1: Messaging Framework [16, 5.4.6 SOAP Fault Codes, Table4]. All those elements should be defined in the SOAP namespace.
A simple SOAP message looks like:
<soapenv:Envelopexmlns: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 in-tended final receiver the ultimate SOAP receiver. A SOAP message might notreach the ultimate SOAP receiver if processing at an intermediary fails. TheSOAP Body contains the message that is intended from the initial sender tothe ultimate sender. Header blocks are used to supply additional informationon the processing. There are tree standard attributes that are used to controlhow/where headers are processed within the message path: Role, mustUn-derstand and Relay. They can be used to target the header block at a specificnode, force nodes to process a header block or relay it to another node in themessage path.
SOAP is defined independently of the underlying messaging transport mech-anism and can be transmitted over different network protocols such as HTTP,SMTP and TCP/IP. A SOAP binding specifies how to serialize and map theSOAP Infoset to the specific transportation protocol used, so that it can beconveyed to the next node in the message path and restructured correctly. Abinding is specified between each hop in the message path but not the entirepath. The SOAP Infoset though is preserved throughout the entire messagepath while even being serialized to multiple transport protocols. The mostcommonly used SOAP binding is the HTTP Binding included in the SOAPspecification [17]. It specifies the serialization of SOAP Infoset to XML 1.0 mes-sages and mapping to HTTP methods.
10 CHAPTER 2. WEB SERVICES
2.4 WSDL
WSDL (Web Service Description Language) is a XML based description lan-guage used to describe the interface of a Web service. It forms a contract be-tween the service and its clients allowing authors to provide information abouthow to invoke the service. WSDL consists of two basic parts, abstract and con-crete. 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 partdescribes how and where to access a service implementation.
WSDL does not describe or define the schematics of services, operations ordata. That is WSDL by itself provides no information on the meaning of theoperations or their data. This is an intentional limitation of the specification asit is meant to by simple, widely used and a common basis for service descrip-tion. WSDL is instead extensible, and specific domain schematics are meantto be specified and standardized within each domain on top of WSDL. Morespecifically WSDL only specifies the message formats, the message interactionpatterns, the way messages are represented on the wire, where and how mes-sages should be sent.
A WSDL description can by used to create code for both server and client in-terfaces, this can be done either manually or automatically by tools and frame-works. Web service implementation frameworks such as Apache Axis can reada WSDL description and generate the appropriate code stubs for the service.For service invocation they can also fetch the WSDL at runtime and create adynamic binding.
Two version exist of WSDL; 1.1 and 2.0, at the time of writing not all imple-mentations support 2.0 as it is still quite new compared to the predecessor. Toease interoperability, WSDL 1.1 will be used in this project but in the followingdiscussion relevant changes in WSDL 2.0 will be highlighted. Figure 2.2 showsthe basic structure of a WSDL 1.1 document.
The top level element is the <definitions> tag that contains all other defi-nitions within the document. The definitions tag defines the targetNamespaceattribute, the target namespace defines a relationship assertion among the def-initions within the document. Namespaces used on other tags and attributeswithin the document can also be declared in the definitions tag. In WSDL 2.0the top level element is named <descriptions>.
Within <definitions> items of <types>, <messages>, <portType>, <binding>and <service> are defined. The <types> and <messages> elements definethe used data types and how they are mapped to messages. <portType>defines the operations for the service and what messages it takes in and re-turns, this could be described as what the service does. How the service is tobe 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 sincethey 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 andthe server. The defined data types are referred to when constructing the mes-sages for the operations. The types can be defined in data structure descriptionlanguage 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 contain-ing zero or multiple part elements. The part elements represent a single itemthat is to be sent or received. The part element has an optional type attributethat indicates the type of the part, it can reference XML Schema types directlyand 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 sup-ports, with the <operation> element. Each operation groups together themessages from the <message> part that are exchanged in the operation. The<input> tag defines an incoming message and the <output> tag defines anoutgoing message, each operation can at maximum have one of each but doesnot need to have any. Thus four kinds of operations are supported one-way(client request), request-response (client request / service response), solicit-response (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 referdirectly to XML Schema element declarations [5].
Binding
The <binding> element defines the protocol and data format details of howmessages are to be formatted to interact with the operations of a specific port-Type (interface). WSDL is most commonly used to describe bindings to SOAPover HTTP POST. In WSDL 2.0 the HTTP binding has been extended to sup-port all methods of the HTTP protocol, making it more suitable for REST styleservices.
The SOAP over HTTP binding specifies how the <input> and <output>mes-sages of an operation are formatted into a SOAP envelope and how the SOAPenvelope 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 ofthe <soap:Body> element will be structured. Document style is the defaultone. 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 orencoded. That is used to specify the serialization rules that SOAP clients andservers should perform to interpret the contents of the elements in the SOAPmessage. Literal means that the type definitions literally follow a XML schemadefinition. Encoding refers to the representation of application data in XML,and additional information might be needed to decode it. The encoding rulesshould be available at an URL specified by an encodingStyle attribute. Of thesechoices the document/literal provides the best interoperability, and is mostrecommended 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 everysingle <service> element, each defining where a single portType is offeredvia a given binding. Each <port> thus refers to a binding and defines theaddress at which that binding is offered.
2.5 UDDI
Universal Description, Discovery, and Integration (UDDI) provides the role ofa common place where services can be registered by providers and discoveredby potential clients. UDDI has been implemented for finding and binding toappropriate services at run time. UDDI was meant for both public and privateuse. In public use companies could advertise their services and how clientscould bind to them on a well known UDDI, working in a similar fashion towell known search engines. In private use companies could use UDDI withinthe enterprise to maintain the list of its Web services and possibly making itavailable to its partners. Of the two, UDDI has had greater success as a privateregistry within enterprises.
2.6 Other WS-* standards
WS-Policy
WS-Policy is a XML protocol specification to describe the policies of entitiesand enabling services and service consumers to specify their policy require-ments. Policies include for example security requirements for services andquality 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 toWeb services developed via committee in Oasis-Open [18]. WS-Security de-scribes how user name tokens, SAML tokens, signatures, certificates and en-cryption headers can be attached to SOAP messages. It will be described inmore detail and its usage shown in chapter 4.4.
Security Assertion Markup Language (SAML)
SAML is a XML protocol for exchanging authentication and authorization databetween identity providers and service providers. It is being standardized bythe OASIS Security Services Technical Committee.
In SOA architecture everything should be implemented as a service, SAMLtakes this assertion to the security domain by making it possible to implementsecurity as a service. The service requester requests a SAML assertion tokenfrom 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 secu-rity service. SAML thus provides single sign on capabilities to the domain andeases the implementation and enforcement of security across the domain.
WS-Trust
Describes interfaces for security services that issue, validate, renew and cancelsecurity tokens such as SAML assertions.
WS-Trust describes a service called Security Token Service (STS) that providesa generic protocol for security token issuing, validation, renewal and cancella-tion. Clients authenticate themselves with WS-Security to the STS and describethe kind of token needed when requesting a token.
SAML Protocol
Describes the interface that a security service provides that returns its findingsusing 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 indus-try forum creating recommendations on the usage of Web service standards toease interoperability between different partners. WS-I publishes profiles thatcontain a set of recommendation. By adhering to a WS-I profile Web serviceimplementors increase the interoperability of their solutions. A WS-I profilethus 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 RemoteProcedure Call (RPC) style bindings
– Receivers must handle envelopes in such a way that it appears thatall checking of mandatory header blocks is performed before anyactual 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 onlyhave one part
2.7 REST
Representational State Transfer (REST), is a different style to design Web ser-vices and distributed systems than described above. REST is not a standardnor a protocol. It is an architectural style first put forth in 2000 by Roy ThomasFielding in his Phd thesis, Architectural Styles and the Design of Network-based Software Architectures [20]. There Roy defines REST as an architecturalstyle for distributed hypermedia systems. The key difference between RESTand Web services as described here above reflects in the use of the hypermediakeyword. That is REST Web services are designed for the Web and its protocolsand 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 SOAPis designed to be tunneled through any transportation protocol all necessary in-formation are convened within the SOAP envelope. As has been demonstratedit supports headers within the message, and the actual operation to conduct isstated within the envelopes body. The most common method of transferringSOAP 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 pro-tocol of the Web, and thus it is the only viable transportation method. Insteadof convening all necessary information within the REST message it utilizes thefeatures of the HTTP protocol.
The REST architecture is centralized around using URLs to address entitiesand 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 Lan-guages [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 Webservices, is given in [22, p. 221];
Addressability means that every interesting aspect of your serviceis immediately accessible from outside. Every interesting aspect ofyour service has a URI: a unique identifier in a format that’s familiarto every computer-literate person.... Addressability makes it possi-ble for others to make mashups of your service: to use it in waysyou never imagined.
Clients of the service then inter operate with the various resources, representedby 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 andPOST is used to create a new resource. This is very well in line with the originalintention of those methods when they were created for the Web. What to acton is thus encoded in the URL of the resource and how to act on it is encodedin the HTTP method used. By contrast in SOAP, every message to the serviceis directed to one endpoint. What entity to act on in which way is encoded intothe SOAP message in an application specific way.
Further REST supports the use of linking between resources, that is one re-source can link to one or multiple other resources. Thought of as a libraryservice, this means that the resource at the URL of the library service wouldlist links of available books in the library, the resource for each book wouldcontain links to its authors and possibly pages within the book.
REST does not go into specific details about the format of the messages ex-changed, 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 ofJavaScript objects into text form, and is beneficial when working with JavaScriptclients. Then objects can quickly and easily be serialized to and from thetextual representation. JSON format has been used extensively in Web sitesdriven by AJAX (Asynchronous JavaScript and XML) where JavaScript clientsin browsers are used to fetch and update content after the page has been loaded.JSON serializes have also emerged for other programming languages like Javaand Python.
It is thus evident that REST architecture has more to do with the architecturaldesign of applications for the Web than attempting to be a general architecturefor distributed programming as traditional Web services with SOA. It is thusmaybe understandable that REST architecture concepts have received quite amomentum and use on the Web. REST APIs in many cases better aligns withthe traditional use of a service delivered through a Web site. Programmable
2.7 REST 17
Web1, is a directory listing publicly known Web APIs, at the time of writing has874 available APIs, 503 where classified as REST and 207 as SOAP. It should benoted though that many services publish both SOAP and REST APIs.
However since REST is only a loosely defined architectural concept and not aprecise standard, many variations exist and many of the classified REST APIsdo not strictly follow the architectural style. In fact this is the case for mostof the REST APIs of today. Those are for example services that fail to conveythe method information within the HTTP method and use application specificquery parameters. The result is that HTTP is simply used as an envelope forthe message but not a part of the message. Another common deviation is toalter server state through a GET method and other improper use of the HTTPmethods. Many services only use GET and POST and fail to utilize DELETEand PUT methods. The result ending up being an inconsistent service exchang-ing information through the use of HTTP query parameters and some arbitrarydata structure like XML [22]. Development on REST frameworks in Ruby onRails, Restlet (for Java) and Django (for Python) is likely to help impose morestructure on developers creating RESTful Web services.
It should also be noted that today REST based Web services do not have thesame sophistication as SOAP based services when it comes to matter of ad-vanced topics like security. There, SOAP hugely benefits from its extensiblenature and open standards which have been built on top of it to solve com-monly needed tasks. However the SOAP header extension standards couldalso 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 de-scription, WSDL 1.1, as described above is unfit for describing REST APIs sinceit does not support binding to all HTTP methods. Web Application Descrip-tion Language (WADL) is a standard format that has been proposed to describeREST Web Services and Web applications in general. It has though not caughton and is not widely supported or used. Presently REST APIs are most com-monly described in human readable documentations or providers, as Googlerelease their own client libraries for their APIs. Thus they have not been goodcandidates for dynamic discovery and binding, described at the heart of SOA.As mentioned above, WSDL 2.0 has been improved to support bindings to allHTTP methods and can be used to describe REST APIs, WSDL design thoughtends 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 theactual message format used, making it more of an implementation flavor deci-sion rather than the focal point of the service in question.
1See http://www.programmableweb.com/apis/directory/
Chapter 3
Mobile Hosted Web Services
This chapter turns the focus on serving Web services from mobile devices, byoutlining their possible use cases. The Nokia Mobile Web Server project willbe introduced as a solution to the addressability problem, making devices ad-dressable by a URL. Other similar projects and SOAP processing engines suit-able for mobile devices will also be introduced. Finally, two ongoing trendsin mobile software development and how they relate to mobile hosted Webservices will be discussed.
3.1 Use Cases
In describing the possible use cases realizable through mobile web services thediscussion here is concentrated around features related to the users calendar.Use cases for other perspectives can then be derived in a similar manner. Themost obvious use of Web services in regards to the calendar services is to ex-pose the calendar as a Web service with operations to retrieve, create, updateand delete entries. They could then be used to implement another user inter-face 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 cal-endar sources and create backups of the calendar entries.
Combining the previously described calendar service with services exposingdifferent functionality of the mobile device opens up a new array or possibleuse cases. As an example, using a Web service to get approval from the mobiledevice owner, a new service could be created that enabled people to book ameeting with the owner of a device. Through an interface users could entera meeting title, start and end date and send a ”Meeting request” to the deviceowner. The service would check the owners calendar to see if the device owneris available at the specified time and if available, probe the device owner withthe meeting request. If accepted, a new calendar entry would be created andthe 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 ap-propriate time.
In the device calendar today, it is possible to get a reminder about a meetingX minutes in advance. Meetings usually take place at a specific location andthat location can also be registered in the calendar entry. Through combinationwith a service exposing the current position of the device, it would be possibleto extend the reminder to also contain information on how to get to the meet-ing. Further, by estimation of travelling time, the time of the reminder couldbe adjusted to it. This would be realized by using an external geological/-navigation service to get the travelling instructions and estimated travellingtimes. If other participants have been invited to a meeting, they could be sentan SMS notification in case it is foreseen that the device owner will be runninglate, realized using a Send SMS service and a contact book service to get theinformation about participants.
Entries in the calendar usually contain a meaningful description (tags) pro-vided 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 exampletake a photo of a black board, record a conversation or save a contact card. Inan external client these information could be conveniently archived within thecalendar entry.
Marking a calendar event as public has many interesting perspectives. By elab-orating on the previous use case, creating a public entry could be used to createa public media gallery with pictures, videos and recordings made within theentry time limits being automatically published. Creating a public event couldalso be used to propose a meeting or a ”get together” with friends. Friendsgetting 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 functional-ity, service on the other hand is used to refer to the consumer of the Web servicesthat implements the use case to a user. The consumer of mobile hosted Webservices can either be a centralized server application, PC application client,or a client on another mobile device. When a client resides on the mobile de-vice 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 cutdefinition of the difference between the two modes, but a P2P environmenthas no fixed assignment of client and servers, allowing all nodes to act equally[35]. Previous work [35] proposes an architecture for enabling mobile P2P Webservices and concludes that Web services are a promising technology to sim-plify mobile P2P systems. When using Web services in a P2P fashion, servicediscovery is an interesting subject. Todays mobile P2P applications either relyon a central discovery server or built in support of the wireless network tech-nologies, infrared, WLAN and Bluetooth for node discovery [49, 50]. Anothersimple approach would be to use the address book to store URLs to friendsmobile devices, todays devices provide the possibility of associating a WebsiteURL with a contact. This would allow for direct interaction from a client on one
20 CHAPTER 3. MOBILE HOSTED WEB SERVICES
device with a Web service on other, for example to create a common calendarentry.
Once nodes have been identified applications need to know how services shouldbe invoked to deliver the needed functionality. In centralized service discovery,the discovery service could relay WSDL service descriptions between nodes.Otherwise it could be handled by serving the WSDL from a common location,or a known service discovery Web service. The emergence of mobile hostedWeb services is likely to increase interest in using Web services in a P2P fash-ion, which has until this point in time not had much significant meaning.
3.2 Mobile Web Service Framework Requirements
The use cases derived in the last section are in many ways similar or identicalto the use cases that can be realized with a general personal server or a mobileWeb site and described in works like [28, 25]. Meaning that it is in fact theability to publicly address the mobile device and get a generic data connection,that makes the use cases realizable. Web services however, enable easily pub-lishing concrete functionality through an abstract, interoperable, discoverableand reusable interface. In contrast, Web sites tend to publish functionality inan application specific manner which is not easily usable by a different appli-cation. Moreover, new services can be realized by combining different existingservices in new ways. Further, Web services enable fetching just the neededinformation in each context and easily work on the data in a programmableway. Combined with methods like binary serialization of XML they shouldalso provide greater efficiency than serving traditional Web sites over the wire-less medium, as long as such methods do not compromise the interoperability.
Application developers could implement and publish Web services solvingtheir specific needs to realize a service. The re-usability and platform indepen-dence features of Web services, along with the fact that every mobile deviceessentially has the same features, can be utilized. Thus, Web services have theadvantage that each application developer should not be required to imple-ment every functionality for every device platform. Reusing standard servicespublished by platform providers, developed through open source collabora-tion or by other application providers, would be very beneficial. This hintsthat it would be highly desirable to have a standard set of Web services pub-lished by devices. This can be realized by classifying the functionality of themobile device into set of Web services and operations providing a specific con-crete functionality. Application developers can then implement use cases bycombining existing Web services and create their own extension Web serviceswhere needed.
Due to the personal nature of the mobile device, communication need to besecure and security restrictions on services and operations variable. Interoper-ability is a major concern in every SOA architecture and its importance evenrises when transformed from the enterprise environment to the personal mo-bile environment. Unlike in the enterprise environment, operators of mobile
3.3 Related work 21
devices are not likely to be experts that can adjust and negotiate on securityprotocols to use for specific services. Clients of a service thus need to be in-formed of the service policies.
For service developers, security should be transparent, that is the service devel-oper should only need to implement the service, when deployed in the systemthe framework applies the security restrictions.
From the discussion so far, the requirement for a mobile device hosted Webservices framework can be drawn out.
• Client initiated requests addressed through an URL need to be possible
• Common Web service standards shall be supported
• Web services need to be able to interact with device data, device entitiesand the device user
• Standard interface to device common functionality is desirable
• Custom extensions should be possible
• Web services should be easily installable
• Each device needs to publish its own WSDL interface for supported ser-vices
• Services and operations should be secured in a custom manner
• Information exchange between clients and the service needs to be possi-ble in a secure manner
• Restricting Web service access to authorized parties should be possible
• Restrictions and access rules, should be changeable by the device user
• Automatically setting access rules is feasible where possible
• Security implementation should be transparent to service implementors
In order to implement the above requirements, two core functionalities areneeded. The device needs to be addressable through an URL and the deviceplatform needs to have XML and SOAP processing capabilities.
3.3 Related work
At this point in time, little work has been done by standardization bodies andindustry working groups to standardize and specify the use of mobile hostedWeb services. Two are though worth mentioning.
22 CHAPTER 3. MOBILE HOSTED WEB SERVICES
Liberty Alliance
The Liberty Alliance Project is specifying a framework for network identitymanagement and single sign-on solutions, where individuals and businessescan easily and securely conduct transactions while protecting their privacy[30]. Liberties single sign-on solutions are supposed to be independent on ac-cess and thus account for the use of mobile devices as service consumers.
An interesting specification from the Liberty Alliance in relation to mobilehosted Web services is the Liberty Reverse HTTP Binding for SOAP Specifica-tion, PAOS (SOAP spelled backwards) [31]. The PAOS Binding specifies howto deliver a SOAP request to a none addressable device like a mobile device,by delivering the SOAP request in the HTTP response, that follows a requestto the server by the client. The PAOS user agent is typically a Web browser oran application running on an unaddressable device accessing a HTTP server.The client indicates to the HTTP server that it exposes services through PAOSby adding a PAOS header and include the PAOS MIME type in the value ofthe HTTP Accept header, in the initial request to the server. To request a ser-vice the HTTP server responds by adding a SOAP message to the body ofthe HTTP response. The SOAP message must contain a <paos:Request>header block to instruct the client where the SOAP response should be sent.The user agent, receiving the SOAP request in the HTTP response message,processes it and POSTs the SOAP response message to the address indicated in<paos:Request>. The HTTP server responds to that message with a HTTPrespond message, for instance HTTP 200 OK. The message exchange pattern isoutlined in figure 3.1.
The PAOS binding can be used for instance to request information about theusers location after he visits a site. Its purpose is to reduce the amount ofinformation that the user has to type in on the limited mobile device interface.It is an attempt at circumventing the addressability problem but is limited dueto the fact that the device needs to initiate the communication. Also in order towork, both the client and HTTP server need to be PAOS enabled, and even ifso, the server does not have any idea of precisely what services the client offersover PAOS.
Parlay X Web Services
The Parlay Group is an industry consortium including members from the ITand service applications domain, the network operators domain and equip-ment manufactures for both domains. Its main purpose is to link IT and serviceproviders with the opportunities and capabilities of the telecommunicationsworld, more precisely, to define standard interfaces allowing service providersto utilize Telecom Operator Infrastructure.
Parlay X Web Services is a Web service interface to Mobile Network operatorservices for use by external application developers and providers. It is speci-fied as part of the OSA/Parlay activities that is a joint effort between European
3.4 Mobile Web Servers 23
Figure 3.1: PAOS Request-Response MEP [31]
Telecommunications Standards Institute (ETSI), The 3rd Generation Partner-ship Project (3GPP) and The Parlay Group. The current released specificationis Parlay X 2.1 [33] but work on 2.2 and 3.0 is ongoing [34]. It is significant inthis context because it is a similar standard interface description as would bebeneficial to have for mobile hosted Web services, described above. Moreover,the user group of this interface is essentially the same as for a mobile hostedWeb service interface, namely external application providers utilizing telecom-munication features to provide service to customers.
3.4 Mobile Web Servers
Nokia Mobile Web Server Project
In [26] a mobile Web server and a solution to the addressability problem ofmobile devices is presented. The addressability problem is solved by using acentralized gateway to bridge the connection between a requesting Web clientand the mobile device. A realization of the solution has been created by Nokiaat http://www.mymobilesite.net. There Nokia device owners can reqis-ter for a URL and download the Nokia Mobile Web Server application to theirphones. When the Mobile Server is started, the server registers with the gate-way and the device becomes addressable through a public URL in the form of
24 CHAPTER 3. MOBILE HOSTED WEB SERVICES
https://username.mymobilesite.net.
The Mobile Web Server consists of several components [27]:
• S60 port of the Apache HTTP Server, named Raccoon, responsible forserving dynamic and static content.
Nokia choose Apache for the porting because of its active community, itsmodular architecture allowing additional features to be added and un-needed features to be removed and its platform independence design.The Apache httpd runs on top of the Apache Portable Runtime (APR),a software library that provides a predictable and consistent interfaceto an underlying platform-specific implementation. The Apache serverincludes the mod python module that integrates PyS60 with the Webserver and makes it possible to create dynamic Web pages with PythonServer Pages and Python modules. All Python modules available on thedevice can be used through the Mobile Web Server.
• Connector, maintains connectivity with the gateway.
The Mobile Web Server is addressable in three different ways: By ad-dressing its public URL through the gateway, by addressing the device IPaddress and by addressing the device internal loop back address (127.0.0.1).Typically the URL is addressable from the public Internet, the IP address-able from within a local network (for example if connected through Wire-less Local Area Network (WLAN), this is of course with the exception ofthe device being assigned a public IP address) and the internal loop backaddressable by applications running on the device itself.
The Connector is responsible for setting up and maintaining the connec-tion between the Mobile Web Server and the gateway. Thus when ad-dressed through the public URL, the gateway directs the traffic throughthe connection to the Connector which then forwards the traffic to theApache server. When addressed directly through its IP address or throughthe loop back address, the connection goes directly to the HTTP serverand not through the Connector.
The assumption on the direct IP address only being addressable within alocal network is based on the previous discussion in Chapter 1 about thelimitations of mobile data connections.
• User Interface: A simplified interface for the management of the serverand setting up the connection to the gateway.
• Web content: Comes with a sample site, providing access to some of thedevice functionality, additional sites can be created by the user or down-loaded.
Security model of the mobile Web server
Of the addressing scenarios outlined above, global Internet addressing pro-vided through the gateway proposes the greatest security threat to the Mobile
3.4 Mobile Web Servers 25
Web Server since requests can be made by anyone anywhere. It is thus naturalthat in the security architecture of the Mobile Web Server the gateway plays acentral role, performing the following functions [27]:
• Firewall: To mount against distributed denial of service (DDoS) attacks,such attacks would easily bring a mobile devices to its knees and need tobe handled at the gateway.
• Secure Connectivity: The gateway provides a secure connection pathfrom the requesting client to the Mobile Web Server. The connection fromthe client to the gateway is secured by HTTPS and the connection fromthe gateway to the connector on the mobile device is secured by SSL.The SSL connection is terminated at the connector, not at the Mobile WebServer itself. HTTPS and SSL provide transport level security at each linkbut since the connections are terminated at the gateway, data are not pro-tected at the gateway itself. From the end users perspective, the securitysolution is transparent and behaves like a HTTPS connection from theclient to the Mobile Web Server.
• Filtering Malware: The Mobile Web Server system is designed to be ableto handle malware where known security threads are filtered at the gate-way or on the device.
• Updating Server Software Modules: The gateway can keep track of, andupdate individual software components which are installed on a clientMobile Web Server. The gateway can also hinder the use of any poten-tially insecure service until a patch is available.
An overview of the gateway and its security architecture is shown in figure 3.2.
From the above it can be concluded that communications are reasonably securewhen requests are made through the gateway, if the gateway provider and thesecurity of the gateway itself is trusted. On the other hand, direct requeststhrough a WLAN propose a security thread since the communication link isnot protected and the device is not shielded behind a firewall. This can be aconsiderable thread to the device since local area networks can both be largeand unsecure, meaning they are not protected with a strong encryption. It doesnot seem to be possible to connect through WLAN but reject direct connectionsto the Mobile Web Server. The user thus has to be aware of the security threadwhen using a WLAN connection.
The mobile device itself is protected by the native platform, through certifiedsigning and assignment of capabilities [46]. No additional protection is pro-vided by the Mobile Web Server to device data. This means that every datathat can be accessed through a PyS60 function can also be exposed throughthe Mobile Web Server if the server is signed with proper capabilities. It is notpossible to grant specific capabilities to, or remove granted capabilities, fromdeployed scripts. They are always executed with the same set of capabilitiesas the parent process, that is the Mobile Web Server. It is thus essential to trustthe scripts that are deployed on the Mobile Web Server and the mobile device
26 CHAPTER 3. MOBILE HOSTED WEB SERVICES
Figure 3.2: Mobile Web Server security architecture [27, p. 137]
in general. The device itself has to be treated as a trusted domain and it isvirtually impossible to take measures against attacks conducted on the actualdevice or with applications running on the device.
New additions
Two remarkable additions have recently been added to the project: A RESTWeb Service Application Programming Interface (API) [43] and the PersonalApache MySQL and PHP (PAMP) stack [44]. At the time of writing the RESTAPI is very limited, exposing two services. One to get presence informationand another to send messages to the mobile device terminal inbox. Developersare encouraged to create their own interfaces for additional features but likely,the API will be extended in the future to provide more functionality.
No specific reasons have been stated as of why a REST interface has been cho-sen. A straight forward reason could be that providing the interface is simple.Define a XML Schema and publish it through a Python Server Page. An ad-vantage of such a simple solution on a mobile device is that there is no needto parse an incoming SOAP message, saving processing time. Since the re-sponse can also be created from a Python Server Page Template it should alsobe lighter to process than creating it from an abstract data structure. All in-formation needed is contained in the requested URL and Hyper Text Transfer
3.4 Mobile Web Servers 27
Protocol (HTTP) headers, an obvious disadvantage is though that it is depen-dent on the Mobile Web Server. As the mobile device has multiple connectionmodes, serving requests by an alternative method, like Multimedia MessagingService (MMS), email or Bluetooth, could be beneficial in case the Mobile WebServer is not available. Such a request could also be used to start and set upthe Mobile Web Server and continuing requests served through it. The reasonfor favoring a REST interface could also be related to another ongoing technol-ogy trend outlined in the next section. As pointed out in the previous chapter,whether an interface uses SOAP or REST messaging should probably not be themain issue. An optimal solution would probably be a common service engineproviding access to its services through different interfaces. Utilizing advan-tages of different methods as appropriate, with future interfaces described inWSDL 2.0, that could become realistic.
In PAMP the MySQL database system and the PHP programming language,one of the most popular programming languages used on the Web today, havealso been ported to S60. On the Web the combination of Apache, MySQL andPHP is referred to as the AMP solution stack and PAMP thus refers to using itto power a personal server. The PAMP stack is at the moment only released asa separate packet with its own interface on the device. It can both be installedas stand alone or on top of the Mobile Web Server, augmenting its Apache httpd,allowing the two to coexist on a single device. At the beginning of work onthis thesis the PAMP stack was still at a very early stage, and for instance hadreported errors in handling POST requests.
On the Mobile Web Server wiki page1 there is a Frequently Asked Questions(FAQ) section, answering among others, questions about the possibilities andviability of a mobile hosted Web site. There, an interesting remark is made:
”In general, it is better not to think Web server that happens to beon a mobile device but instead personal context-rich mobile devicewith HTTP access to it. Technically they say the same thing, but thelatter alternative describes much better what this is all about.”
This reflects well upon the previous assumption in the requirements section ofthis chapter that it is in fact the addressability and the HTTP connection to thedevice that is truly interesting.
Web servers for other platforms
Apart from the Nokia Mobile Web Server there are various other mobile Webserver projects for other platforms. For Windows Mobile there are two prod-ucts, both commercial, Chili Compact Web Server2 and Sphinx Mobile WebServer3, having a free alternative. Sphinx Mobile Web Server is also available
1See http://wiki.opensource.nokia.com/projects/MWS:FAQ2See http://www.chilisoftware.net/CompactWebServer/3See http://www.sphinx-soft.com/MWS/index.html
28 CHAPTER 3. MOBILE HOSTED WEB SERVICES
for regular Windows systems and is thus a personal Web server for laptopsand mobiles. Http4mobile 4 is a Web server for Java Platform, Micro Edition.Android is a new open source mobile platform initiated by Google. It is stillin development with first devices expected to appear in the fourth quarter of2008. Already though the Jetty Web server has been ported to the platformunder the name i-Jetty5. Apache, Python and PHP have also been ported andcompiled on the iPhone platform but due to its locked nature such attemptsare hacks which are only available through unconventional methods [52].
From those projects it is evident that there is a lot of interest in a personal mo-bile server and already there are available servers for every major mobile de-vice platform. Of those implementations the Nokia Mobile Web Server seemsto be the most capable solution at the moment and the only one with a devicemanufacturer support. The other solutions, except from Sphinx Mobile WebServer, make no attempts at solving the addressability problem. Sphinx pro-vides an access service in beta mode6, but provides no information about howthat service is realized.
3.5 Web Service Processing Engines
Python SOAP Engines
The Nokia S60 platform supports development in Python with Nokia port ofPython to S60 (PyS60). Python is a very powerful and flexible scripting lan-guage and ideal for rapid prototyping development. The port of mod pythonto S60 has further made it easy to serve Python driven content with the Mo-bile Web Server. PyS60 is a scaled down version of Python 2.2.2, but usuallymissing modules can be added as needed.
Python has two Web service toolkits, Zolera SOAP Infrastructure (ZSI) andSOAPpy. Today ZSI is the primary and more active one. However, since PyS60is still based on Python 2.2.27 that proposes a serious limitation. Python 2.2.2was released on October 14. 2002, at the time of writing the latest version ofPython is 3.0a5 and thus Python 2.2.2 is getting relatively old. There are noindications or announcements from Nokia that the Python version of PyS60will be upgraded anytime soon.
At the time of writing the latest version of ZSI is 2.0 and requires Python 2.3or later and PyXML version 0.8.3 or later [1]. The latest version of SOAPpy is0.12.0, actually still a release candidate but has been so for a long time. SOAPpyreadme and release notes do not mention a required Python version, only thattwo packets fpconst 0.6.0 and PyXML 0.8.3 are required.
4Available at http://www.tools4mobile.eu/httpd4mobile.html5See http://code.google.com/p/i-jetty/6See http://www.sphinx-soft.com/MWS/register.html7Available at http://www.python.org/download/releases/2.2.2/
3.5 Web Service Processing Engines 29
Both ZSI and SOAPpy come with stand alone servers that can be started, lis-tening to incoming SOAP messages on a specific port. Additionally ZSI claimsto come with mod python support.
Java Platform, Micro Edition - JSR 172
Java Platfrom, Micro Edition (Java ME), also known as J2ME, is a scaled downJava platform for mobile devices, being available now on almost any shippeddevice for a few years. It contains interfaces to manage device data and interactwith device interfaces. Java code is always executed within a Java virtual ma-chine and has access to the core system through various extension APIs pub-lished as Java Specification Request (JSR)s, for example the Wireless MessagingAPI to send text messages.
The Web Service API (WSA) published as JSR 172 is such an extension to pro-vide Web service client support on Java Platform, Micro Edition. It is composedof two optional packets [38]:
• Remote Service Invocation API: Based on a strict subset of Java 2 Plat-form Standard Edition (J2SE)’s Java API for XML-Based RPC (JAX-RPC)v1.1, providing SOAP message processing and remote method calls abil-ities.
• XML parsing API: Based on a strict subset of the Simple API for XML,version 2 (SAX2) parser, providing processing of XML messages.
JSR 172 does not include WSDL processing and client stub generation, theyhave to be generated in external tools at development time and included in theapplication packet. Dynamic service discovery and binding is thus not sup-ported. It does not support Attachments, message handlers, UDDI and pub-lishing services. It is a high level API that enables invoking methods on pregenerated stubs but does not provide access to the underlying core functional-ity [38]. No attempts have been found on trying to use JSR 172 to serve Webservices.
As an application platform for mobile devices, Java has mainly suffered fromtwo drawbacks: Limited access to device capabilities and incompatible inter-faces between devices. The former is due to that Java code is always executedwithin a Java virtual machine and as mentioned, only has access to the coresystem through various APIs. In many cases implementation of those APIsare not interoperable between different device models. To further complicatematters, the devices have very different interfaces in matter of screen size andlayout. The Java promise of write once run everywhere has thus not been as fittingas hoped in the mobile environment.
30 CHAPTER 3. MOBILE HOSTED WEB SERVICES
Nokia Mobile Web Service Framework
The Nokia Mobile Web Service Framework is probably the most comprehen-sive of the existing Mobile Web Service Frameworks. The framework is avail-able for S60 and S80 Symbian devices. On S60 it is named SOA for S60 andcomes as a native platform in 3rd Edition devices, on S80 it is called the NokiaWeb Service Framework for S80. The framework provides API libraries fornative Symbian C++ and Java to ease the development of Web Service applica-tions for Nokia mobile devices. Currently the framework only supports imple-menting Web service clients but holds up the possibility of supporting servicepublishing in the future [39].
Features of the framework: Compliant to the WS-I basic profile, XML parsing,SOAP 1.1, WS-Security and authentication through the Liberty Alliance WebService Framework.
Other toolkits
• kSOAP now kSOAP 28 is a light weight SOAP Web service Java clientlibrary for limited environments such as Applets and Java 2 Platform Mi-cro Edition (J2ME). It uses kXML another lightweight Java library forXML parsing.
Although kSOAP itself does not support Web service provider function-alities, it provides low level access to XML parsing and SOAP messagemarshaling that have been utilized in tests to implement Web serviceproviders, such work is explained in [24, 35, 29].
• eSOAP9 is a small lightweight SOAP 1.1 toolkit for embedded systems. Itis implemented as an ANSI C++ library and only has a memory footprintof 150KB.
• gSOAP10 is a toolkit for Web service development in C and C++. It pro-vides tools to map C and C++ data types to XML Schema data types andcreate Web service stubs from WSDL. gSOAP is suitable for embeddedsystems and integration with native C or C++ based environments [23].gSOAP is used on Sony Ericsson UIQ 3 devices to support Web servicerequests and has been used in IBMs Web Services Tool Kit for Mobile Devicesfor similar purposes on Palm and Symbian devices [36].
3.6 Trends in mobile software development
Currently there are two noticeable trends in mobile device software develop-ment: First, open source mobile device platforms and secondly, application
8Available at http://www.ksoap.org9Available from http://esoap.ultimodule.com/bin/esoap/templates/splash.asp
10Available from http://www.cs.fsu.edu/ engelen/soap.html
3.6 Trends in mobile software development 31
development based on Web standards. Although they will not be explainedin detail here, it is appropriate to discuss how they touch upon mobile Webservices.
Historically, mobile device operating systems have been proprietary platforms,either developed by device manufacturers or by an external software providersuch as Microsoft and Symbian. The emergence of open platforms like Open-Moko11, Android12, the LiMo Foundation13 and Nokia takeover of Symbian,with the intent of open sourcing the platform, is clear evidence of upcomingchanges. In the changed landscape multiple device manufacturers are likelyto use a common open platform to provide the basic functionality and thentry to differentiate themselves at a higher layer in user interface, functionalityand services. This evolution is likely to shift development of core functional-ity to specific interest groups, maintaining their development. Development ofWeb servers and Web service frameworks has been proven to be such a corefunctionality. That is best maintained within an interest group like the Apachefoundation. Receiving support from companies using its product as the basisfor other products creating business value. This trend is likely to repeat itselfon mobile devices. That is already evident by the fact that the core buildingblocks of the Nokia Mobile Web Server have from day one been open sourced,namely the Raccoon Apache Port and a gateway implementation.
The latter trend is that applications for mobile devices are increasingly be-ing developed by the same methods as Web applications, based on Exten-sible HyperText Markup Language (XHTML), Cascading Style Sheets (CSS),JavaScript and Asynchronous JavaScript and XML (AJAX). Either used di-rectly from the device browser or within a special container like the NokiaWeb Runtime (WRT), Widgets container14. Widgets are known from the desk-top world and are essentially small focused Web applications fitting the limitedmobile device interface well. A widget application contains XHTML, CSS andJavaScript files packed into an installation file. After install it is accessible in thesame manner as any other S60 application, the user interface of the applicationis specified in the XHTML and CSS files and the application logic controlled bythe JavaScript file. The user interface can be created in exactly the same man-ner as any other Web page. Through a JavaScript extension API provided inthe WRT, it can be made to look and behave like any other native S60 applica-tion. Widgets can fetch content and interact with services through the Internetconnection.
Through a JavaScript library, a widget can also gain limited access to the deviceresources. At the time of writing, the API though is very limited. As an alterna-tive it has been proposed to use the Mobile Web Server to expose device func-tionality, at least until an updated WRT is released [45]. This may even havebeen a major stimulus for providing the Mobile Web Server REST API. OtherWeb Runtimes and browser engines being developed for mobile devices, suchas the Opera browser, also contain JavaScript libraries that can be used to gain
11See http://www.openmoko.com/12See http://www.openhandsetalliance.com/index.html13See http://www.limofoundation.org/14See http://nokia.com/widgets
32 CHAPTER 3. MOBILE HOSTED WEB SERVICES
access to device resources and can of course also use the mobile Web server toaccess such resources [51, p. 108].
Advantages of such Web based applications is of course that previous Web de-velopers are familiar with the technologies and do not need to learn new pro-gramming languages. The Web already contains enormous amount of contentand services that can easily be transformed to the mobile medium. The corefunctionality of the service can be served from a central server and a scaleddown interface provided to the mobile, simplifying the maintenance of the coreapplication. The technologies behind the Web are well standardized in matterof how content is to be displayed, thus an application for one WRT shouldeasily be portable to the next. The problems of course are that the specificJavaScript APIs within each WRT are being developed independently and thusnot interoperable. That is a similar problem as browser incompatibility prob-lems of today that have to a large extend be solved with open source JavaScriptlibraries as Prototype15, and script.aculo.us16 [51]. In attempt to solve the in-teroperability problem between JavaScript APIs, a mobile task force has beenfounded at the OpenAJAX Alliance17, at the time of writing, it is though stillonly in its early stages.
In the use cases presented in the beginning of this chapter, although not explic-itly stated, the natural way of thinking about the device Calendar applicationwould be to think of it as a native application with the calendar database storedon the device itself. However, when thinking of it from the perspective of wid-gets, the device calendar application could very well become a widget interact-ing with a central service where the calendar entries are actually stored. Thecentral service would then interact back to device through Web services, forexample with a meeting remainder. Today there is though not much that sup-ports or rationalizes such an extreme way of making the devices a thin clientterminal to access service, rather the trend is to transfer data to the device forstorage. More reliable always active networks at a cheap rate could though turnthe evolution around, as it certainly would have benefits for software develop-ment.
Although widgets are gaining momentum they are not in direct competitionwith application platforms like J2ME, C++ and Python, as they are by theirnature limited to only provide the user interfaces. The other application plat-forms will be used to implement core routines and applications not suitable forsuch a Web interface. Cooperation between those categories is likely to emergein some form.
15See http://www.prototypejs.org/16See http://script.aculo.us/17See http://www.openajax.org/member/wiki/Mobile_TF
Chapter 4
Mobile Web ServiceFramework Design
This chapter presents a high level design of a mobile Web service frameworkin order to realize the requirements put forth in chapter 3.2.
4.1 Functional Requirement
In order to realize the requirements in chapter 3.2 a solution like the Nokia Mo-bile Web Server and a SOAP processing library are fundamental. Additionallya persistent storage, like a database is required on the mobile device to storeinformation about installed services, authorized parties and their access priv-ileges. The database also needs to link to the actual code implementing thoseservices and new code libraries need to be installable.
Implemented services further require access to device data, functionality andthe user of the device. Mobile application platforms usually contain librariesmaking such functionality available. Web services involving user feedback,have different requirements than Web services accessing data or functionalitybecause of two things: First, a service like a Web server is commonly running ina dedicated server thread within the operating system and does not have accessto graphical user interface functionality; secondly, users can take arbitrary longtime to respond to a request, from seconds to hours, a HTTP connection is notsuitable for such a long delay. Those considerations need to be accounted forand handled by the framework.
When receiving a request the SOAP processing library needs to be set up andpublishing the available services in the database. Before executing the requestthe SOAP processor should run needed handlers, such as an authenticationhandler. The authentication module extracts authentication information from
34 CHAPTER 4. MOBILE WEB SERVICE FRAMEWORK DESIGN
the request and evaluates according to conditions stored in the database. Ac-cess is only granted if the request meets the authentication requirements.
SOAP message processing is only one of three interfaces to the system. Ad-ditionally the framework also needs to serve interface descriptions for ser-vices, WSDLs, and provide a management interface for the device owner. Themanagement functionality should also be available through a Web service. Acommon module implementing the core management functionality is thus ad-visable. The system also needs to communicate its service policies to callingparties, in the WSDL or through a service. Policies can change as the ownerchanges the requirements for a service, typically whether it requires authenti-cation or secure transport layer.
The Mobile Web Server security architecture, through transport level encryp-tion, provides data confidentiality, data integrity and protection against at-tacks. When requests are made through the gateway, it has the limitation that itis not true end to end security. Clearly authentication and authorization need tobe provided by the mobile Web service framework and be used to limit accessand provide additional privacy and data confidentiality.
4.2 Architecture
To meet the requirements the system is divided into functional entities of:SOAP Server Interface, WSDL Interface, Manager Interface, SOAP processing,Service Implementations, Handlers, Database, Thread launcher and Commonmodules. Figure 4.1 shows an overview of the proposed architecture.
Interfaces
Web Service Request
When a SOAP request is received, the SOAP processing module is set up andoperations registered. The incoming request is then passed to the SOAP pro-cessing module. The SOAP message is processed and the authentication methodexecuted. It validates the requester and checks whether it is authorized to pro-ceed. If so the service implementation is executed, carrying out its functional-ity, possibly using the Device API. If an external thread for user interaction ora time consuming operation is required, the service implementation uses theframework classes to setup an external thread. It specifies a method to execute,the method is executed and carries out its functionality. It can then possibly re-ply back to the original caller by initiating a SOAP request to a specific locationgiven by the original requester. The process is outlined in 4.2.
4.2 Architecture 35
Figure 4.1: Mobile Web Services Framework Architecture
Get Interface Description
Service interface descriptions, WSDLs, are commonly requested through a GETrequest to the server. WSDLs can be generated in two ways: Dynamically, fromthe actual code of implemented services or code annotations, or manually bythe service creator. In the case of a dynamically created WSDL it could becreated each time it is requested. That is though not very efficient in the case ofa mobile device. It is thus recommended that the WSDL is created or uploadedwhen a new service is installed on the server.
Multiple services can be installed in the framework and each of them has itsown WSDL description. A common WSDL description can be created by im-porting the WSDLs for all services in one file with an import element like:<wsdl:import namespace="..." location="..."></wsld:import>Policy descriptions can be included as a part of a WSDL, WS-PolicyAttachmentdescribes how a WS-Policy assertion is attached to a WSDL. For each serviceand operation, blocks of Policy assertions should be created, like:
36 CHAPTER 4. MOBILE WEB SERVICE FRAMEWORK DESIGN
Figure 4.2: Mobile Web Services Framework Architecture
<wsp:Policy wsu:id="serviceNamePolicy" xmlns:wsp="...">...</wsp:Policy><wsp:Policy wsu:id="operationNamePolicy">...</wsp:Policy>
They can either be stored in a file, created when policy changes, or createddynamically when requested. They are then imported into the WSDL and at-tached to the appropriate elements in the WSDL. By adding the appropriatereferencing tags<wsp:PolicyReference URI="#servicePolicy" wsdl:required="true"/>and<wsp:PolicyReference URI="#operationNamePolicy" wsdl:required="true"/>as child elements of the service and operation elements. The references couldbe done either manually when creating the WSDL or automatically by theframework when the WSDL is installed on the server [2, p. 378].
4.2 Architecture 37
Management Interface
The management interface is an interface for the owner of the device to man-age the framework. There, new services can be installed, installed servicesremoved and access to services restricted. Although it is necessary for the userto be able to make those modifications, it is also necessary that they can hap-pen effortless when needed. This functionality should therefore also be pub-lished as a service, Management Web service. The interface could be built uponthat service, or both could use a common same standard class provided by theframework.
Database
Database systems on mobile devices are normally very limited in functionality,although this is changing. Allowing only the most simple queries and imposeon doing advanced features in code. This needs to be taken into mind whenthe database for the framework is designed. The design should be optimized sothat the fewest possible requests to the database are needed in each scenario.With a simple database this basically means that all information needed foreach request should be stored in the same table. Tables are thus not optimizedfor the standard normalized form. Due to the different capabilities on differentplatforms, the exact database design is left as an implementation issue.
It though needs a table to store services and their information like class imple-menting the service, name of the service and its wsdl location. A table to storeoperations of services, a table to store users, their user name and password anda table to link users to allowed operations / services.
Thread launcher
The thread launcher should be an application on the mobile device that can bestarted in its own thread. It can be used to execute code that requires capabili-ties beyond those of the underlying server, such as displaying a user interface,and to execute time consuming operations to prevent stalling the HTTP con-nection.
Common classes
Common classes are classes provided by the framework to ease developmentof services, such as authentication handling, interface to the thread launcher,service management class and so on.
38 CHAPTER 4. MOBILE WEB SERVICE FRAMEWORK DESIGN
Service repository
The service repository contains the actual service implementations, stored onthe device. The service repository stores the implementation files for the ser-vice and additional information about it is stored in the database. From theinformation in the database it has to be possible to get a reference to the actualservice implementation so that it can be registered on the SOAP processingengine. The framework itself publishes on Web services a Management Webservice that exposes the same functionality as the Management Interface.
4.3 Extending the Mobile Web Service Framework
The architecture could be extended with more interfaces, additionally to theSOAP processing interface, a JSON processing interface could for example beadded. In order to realize that, a JSON interface would have to be created us-ing a JSON deserializer/serializer to convert from/to the JSON structures. TheWSDL descriptions could be extended, also specifying a binding to the JSONinterface. Work in [53] has suggested that JSON might be an efficient serial-ization for mobile terminals. Usually, client stubs for JSON are created andhosted by the serving end so the JSON interface should be capable of generat-ing such clients stubs. An example of how a JSON service is commonly createdand requested is available at https://jax-ws-commons.dev.java.net/json/.
4.4 Securing the Mobile Web Service Framework
Password Authentication
Username and password authentication is probably the most widely used au-thentication scheme and the one users are most familiar with. When requestinga Web service a username and password can be communicated in the followingways.
By using HTTP Authentication in basic or digest mode, the username and pass-word are sent in the header of the HTTP request. Most Web service frameworkssuch as Apache Axis support and make this method easily available.
By using the WS-Security specification, a username token is sent as a SOAPheader. Username tokens also support sending the password either as a plaintext or as a digest, the latter being more secure. The idea behind passworddigest is that instead of sending the actual password, a value is sent that canonly be computed by someone who has the password. Two additional valuesare sent, the nonce (n) and the creation timestamp (c). They should have theproperty that the UTC value of the timestamp can only differ from the servers
4.4 Securing the Mobile Web Service Framework 39
timestamp by some predefined limit. That is, the message is only valid in apredefined time window and each nonce can only be used once within thistime limit [2].
The listing below shows a WS-Security header. The WS-Security header con-tains one element; UsernameToken, which contains the necessary elementsUsername, Password, Nonce and Created. The password is indicated to bea PasswordDigest by the type attribute on the Password element. The Encod-ingType attribute on the Nonce element indicates that the element value isBase64Binary encoded and has to be decoded before calculating the digest.
<wsse:Security soapenv:actor="..." soapenv:mustUnderstand="0"xmlns:wsse="..."><wsse:UsernameToken><wsse:Username>USERNAME</wsse:Username><wsse:Password Type="...#PasswordDigest">cUOHqo8mVw2sgQkG9OlW11FDM7E=</wsse:Password><wsse:Nonce EncodingType="...#Base64Binary">/pMTBqYfaWLQxLiMZtBwgQ==</wsse:Nonce><wsu:Created xmlns:wsu="...">2008-07-06T11:06:24.591Z</wsu:Created></wsse:UsernameToken></wsse:Security>
The WS-Security UsernameToken Profile 1.0 [3] specifies the password digestfunction as follows.
Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )
That is the nonce, created timestamp and password are concatenated and hashedwith the SHA-1 function and then base64 encoded for transmission. When aplain text password is sent only the Username and Password elements are re-quired.
Since password authentication is so popular, individuals have username/pass-word accounts in various places, and they tend to reuse the same passwordsin multiple places. This makes passwords vulnerable to repurposing attacks,where administrators of one service use the registered password to access theusers account in another service [2]. This vulnerability becomes even greaterwhen the administrator personally knows the user, as is likely in the case ofmobile Web services with friends requesting services from each other devices.It is also generally not considered a good practice to store passwords in theiroriginal form in the password store, here the device database. A hash func-tion should be used to transform the password, to protect the actual passwordin case the stores security is compromised. Storing a hash transformation inthe password store however complicates matters when using password di-gest since the client would have to know and perform the same transformationfunction on the password before computing the digest to send.
40 CHAPTER 4. MOBILE WEB SERVICE FRAMEWORK DESIGN
Usually Web services are not used directly by the user, they are more frequentlyused indirectly through some Web service enabled client. The demo applica-tion that has been constructed in this thesis is for example an online service thatuses the Web services on the mobile device. Obscuring the password wouldprobably be better handled by the user client. That is, the client would gen-erate an abstract password for the user that it would use to authenticate itselfand the user to the Web services. This abstract password could be a hash of thepassword the user uses to authenticate to the client, or totally random gener-ated. Obscuring the password would then take place on the client side insteadof the server side and the device password store would be treated as unsafe.
Through the manager interface the device owner is able to create users andassign them privileges. The management Web services should also make itpossible for clients to request a username and access to a service or operation.
Using encryption and digital signatures
A username scheme only provides authentication but does not provide anymessage integrity. The message could be tampered with during transmissionor its content read by a third party. The gateway provides message integrity toan extent since all requests through the gateway are secured on the transportlayer by HTTPS and SSL. As mentioned, the weakness is that the connectionsare terminated at the gateway and thus do not provide true end-to-end secu-rity, it can only be trusted if the gateway is trusted. When one client is directlyrequesting services from another this is probably sufficient. Another possiblescenario is two clients exchanging data between a third party service, and theclients wanting to protect the integrity of data which they pass through theservice. An example of such a service could be a calendar synchronization ser-vice, allowing synchronization of events between parties. In the current setupthe calendar service would request events from one party and relay it to thenext one. In the process it would be able to do anything with the data, withoutthe parties knowing. To protect the data integrity the parties would have tosign their data with a digital certificate before sending it through the service orencrypt parts of the message such that only the intended recipient can decryptit.
WS-Security supports both message level encryption, where selected parts ofthe SOAP message can be encrypted, and the usage of X.509 Public Key Infrastructure(PKI) certificates to sign messages or parts of message. Selective encryptionof XML elements is specified by the XML Encryption W3C specification andused by WS-Security. It defines how the encrypted element and informationabout the encryption, such as encryption method and key, should be trans-mitted. Commonly, the data is encrypted by using a symmetric-key and thesymmetric-key encrypted with the recipients public-key. The recipient thenuses his own private key to decrypt the symmetric key and can then decryptthe message. The information about the keys are contained in a<xenc:EncryptedKey ...>...</xenc:EncryptedKey>XML block and the actual encrypted content is replaced and transmitted in a
4.4 Securing the Mobile Web Service Framework 41
<xenc:EncryptedData ...>...</xenc:EncryptedData>, XML block.The Encrypted Data block is given a unique id and in the Encrypted Key blockthere is a reference to the ids encrypted with this key. It thus becomes possibleto encrypt multiple blocks within the same message with multiple or the samekey, where one encrypted block can even contain another encrypted block.
When a message is encrypted with the recipients public asymmetric key, onlythe intended recipient can decrypt it with his public key. The same propertyholds true in reverse, if a sender encrypts a message with its private key, it canbe decrypted with his public key. This property is used in digital signing ofmessages. The sender of a message creates a hash of the message (to reduce sizeof information that need to be encrypted) and then encrypts the signed hashwith its private key. The intended recipient can then validate that the messagedid in fact come from the sender by calculating the same hash of the message,decrypt the signed hash with the senders public key and check if they match.PKI provides a trusted key distribution framework, a PKI X.509 certificate con-tains the owners public key, identity of the owner and other information likeexpiry date signed by a trusted Certificate Authority (CA) with its own privatekey. WS-Security with the XML Signature specifies how a SOAP message canbe signed and the signature transmitted within the message. Instead of a User-nameToken as shown above, the senders certificate chain is carried in a Bina-rySecurityToken element. The signature of the message is carried within a Sig-nature element, both contained in the WS-Security <wsse:Security ...>header.
Signing a message with a digital signature also proves that the message couldonly have originated from the owner of the digital certificate that was usedto sign the message and could thus be used to replace username/passwordauthentication. This would be especially useful when authenticating a wellknown central service provider like for example Google Calendar. When mak-ing a request to a users device, Google Calendar would sign the messages withits digital certificate. Upon receiving the incoming message with the digital sig-nature, the framework would verify the certificate and ask the user if the ownerof the certificate signed to www.google.com issued by Thawte SGC CA should begranted access to the service and operation in question. Then a rule could beset to automatically grant this access in the future. The framework would in-clude a certificate store containing certificates of trusted certificate authoritieslike Thawte and VeriSign.
Other security approaches
Mobile devices have some other interesting properties in regards to securitythat can be used. First of all their location and use of network connections vary.An option in the mobile Web service security configuration, could be to chooseon a network by network basis what services should be available. Allowingdifferent set of services to be requested through the gateway, from within theworkplace network, a hot spot in the mall and the home network.
42 CHAPTER 4. MOBILE WEB SERVICE FRAMEWORK DESIGN
Mobile devices also have the advantage that it is easy to simply ask the user.Users could mark specific services so that they would be asked each time theservice is being requested, or they could be asked the first time a user requestsa Web service he has not been granted access to, followed by an option to createa rule for future access.
Security as a service
In SOA architecture everything should be implemented as a service, includ-ing the security. The different services that an enterprise publishes are verylikely to be spread around various servers with different run times. A centralsecurity service brings the benefits of just implementing and enforcing securityrestrictions in one place for every service. Clients then request a security tokenfrom the service and use it to authenticate themselves to other services. Eachservice then only needs to validate the security token. If clients do not providea security token, the service can forward the request to the security service ordeny it.
This scheme is not very optimal when transferred to the mobile device. First ofall, services are published from the same location and in the same run time, ifpublished through the same framework. Clients would still need to know howto identify themselves with the service but they would not have to provide theauthentication details in each request, instead they would have to provide thetoken. Burden would be added on the framework/security implementationsince it would have to maintain information about valid tokens additionally tothe authentication information. A much simpler approach is to simply imple-ment the security constraints in a central function/class that can be applied toeach service. However if the gateway is trusted, a security service could be im-plemented at the gateway. Further discussion on that possibility is in chapter7.
Code integrity
As the previous discussion about the Nokia Mobile Web Server security modelin 3.4 indicated, all security measures are breached if malicious code is de-ployed on the device. To further increase the integrity of code published asWeb services, the framework could offer a method to get hash checksums ofinstalled services and the checksums could be compared to checksums of theservice implemented by a trusted repositories / implementations of the sameservice for the platform. This comparison could be done by the gateway orrequesters. This would also be a method to validate that the needed version ofthe service was installed.
4.4 Securing the Mobile Web Service Framework 43
Security recommendations
To summarize the discussion the following recommendations and best prac-tices should be followed:
• The gateway provider has to be trustworthy, just like mobile networkoperators also have to be trusted.
• Interoperable authentication methods should be used to restrict access toservices.
• Methods accessible through a direct WLAN request could be limited toonly those that do not transmit sensitive data.
• Avoid password reuse.
• Use Web service clients to create obscure or hashed passwords for usersand limit the exposure of real passwords to a mobile server.
• Creating username and password accounts and assigning privileges tousers should be possible through services.
• Access to services could be based on real time user consent, by asking theuser directly and then possibly creating an appropriate access rule.
• Hash checksums of installed services should be made available and becomparable to a central trusted repository.
Chapter 5
Mobile Web ServiceFramework Implementation
5.1 Introduction
The Mobile Web Service Framework has been implemented for Nokia S60 de-vices on top of the Nokia Mobile Web Server project. The Mobile Web Serversolution is used to solve the addressability problem and makes the Nokia plat-form feasible as a test case platform. Due to its easy integration with the MobileWeb Server through mod python and its feature rich API, PyS60 has been cho-sen as the application development platform.
5.2 PyS60 SOAP processing
As mentioned in 3.5, Python has two SOAP processing implementations; ZSIand SOAPpy. Since ZSI is newer, more active and has integrated support formod python, it was first attempted to port it to PyS60. During the work, it wasdiscovered that ZSI needs to run with the C based XML parser Expat. Expatcan be run from python with the python module pyexpat extending and usingthe C module. Pyexpat has been ported to S601 but is only supported for 2ndEdition devices although a port to 3rd Edition devices has been submitted tothe developers forum2. In 3rd Edition devices the matter is further complicatedby the Symbian security, requiring that pyexpat has to be signed with at leastthe same capabilities as the process making the call to pyexpat. This meansthat pyexpat would have to be signed with the same set of capabilities as themobile Web server. Signing pyexpat with a developer certificate, having all the
1Available from http://pdis.hiit.fi/pdis/download/pyexpat/2Available from http://discussion.forum.nokia.com/forum/showthread.php?t=
97293\&page=1
5.2 PyS60 SOAP processing 45
necessary capabilities was tested. However it did not work correctly, with ZSIgiving an error, ”AttributeError: ’model’ object has no attribute ’Reader’”. Thatindicates a missing required feature in the pyexpat for PyS60 implementation.Looking for solutions to this problem and asking on the forums did not giveany positive result. After further discovering that the mod python implemen-tation in ZSI does not seem to work properly it was decided to stop workingon ZSI and turn to the simpler and lighter SOAPpy implementation.
Using SOAPpy with PyS60 and mod python
The first step was to adapt SOAPpy to retrieve and return requests throughmod python instead of a stand alone server. Code listing 5.1 shows a simpleexample from the SOAPpy documentation on how the normal server is startedand a method registered.
Listing 5.1: SOAPpy simple server example
1 import SOAPpy2
3 def echo(s):4 return s + s # repeats a string twice5
6 server = SOAPServer(("localhost", 8080))7 server.registerFunction(echo)8 server.serve_forever()
In the code above the SOAPServer class in the SOAPpy.Server module is usedto forge a server on localhost, listening on port 8080. The SOAPServer in-herits from the SOAPServerBase class also in the SOAPpy.Server module andthe python standard library class SocketServer.TCPServer. SOAPServerBase pro-vides functions as registerObject, registerFunction and unregisterObject, while Sock-etServer.TCPServer handles the TCP/IP connectivity of the server. The initial-izer of SOAPServer initializes an instance of SocketServer.TCPServer with aninstance of the SOAPRequestHandler class, also in the SOAPpy.Server module.When the server receives a new request on the specified port, it will be passedto this instance of SOARequestHandler that takes care of processing the request.SOAPRequestHandler has two methods; do GET and do POST. do GET is usedto execute a method for serving the WSDL description while do POST pro-cesses the request. It uses basic classes and functions from the SOAPpy packetto parse the incoming headers, parse the incoming SOAP message, processheaders, execute the desired operation and build a SOAP response.
To serve Web services through mod python, a new class with the name mod-SOAPServer was created in the SOAPpy.Server module. Like SOAPServer, italso inherits methods from SOAPServerBase to register and unregister functionsand objects to the server. modSOAPServer resembles the original SOAPServerclass as much as possible and sets up the same basic environment. However, itdoes not inherit or create an instance of SocketServer.TCPServer. Instead a newmethod is defined, handleRequest, that takes a mod python request object as an
46CHAPTER 5. MOBILE WEB SERVICE FRAMEWORK
IMPLEMENTATION
argument. It then creates an instance of a new class modSOAPRequestHandler,forwards the request object to it and returns the result. Similarly as above itis in the modSOAPRequestHandler class where the actual request is processedand a response created. The functionality of modSOAPRequestHandler is deliv-ered by calls to SOAPpy basic functions and classes, that are left unchanged. Itgreatly resembles the original SOAPRequestHandler included with SOAPpy.
Since the code for modSOAPRequestHandler is rather long it is omitted herebut is available on the companion CD within in the file\webservices\py\SOAPpy\Server.pyIts tasks are realized through two functions:
• do GET, forward the request to the location where WSDL files are stored
• do POST
– Read HTTP headers in the request
– Read and parse the incoming SOAP message into header, body andattributes
– Extract the methodname, arguments and argument values
– Look for a registered function for the operation requested in theSOAP request
– Look for a registered authentication method and execute it, pass-ing it the SOAPContext containing: headers, body, attributes, data,request object and request header
– Execute the desired function if the authentication method was suc-cessful
– Build the SOAP response from the output
The PyS60 distribution is a scaled down version of Python and does not includeall modules from the python standard library. However missing libraries canusually be copied to the python path on the device. When trying to run theSOAPpy code on the device it became clear that the following modules wheremissing: BaseHTTPServer.py, cgi.py, dis.py, ftplib.py, gopherlib.py, hmac.py, in-spect.py, mimetypes.py, pickle.py, posixpath.py, smtplib.py, SocketServer.py, thread-ing.py, token.py, tokenize.py, urllib2.py and UserList.py.
These modules along with the full XML library for Python where copied fromthe official Python 2.2.2. release to the device. The required fpconst 0.7.2was downloaded from http://pypi.python.org/pypi/fpconst/0.7.2 and also copied to the device. A date/time class module was obtainedby following instructions at http://snippets.dzone.com/posts/show/1614, downloading a library from pythonweb.org, http://www.pythonweb.org/projects/webmodules/release/0.5.3/PythonWeb.org-0.5.3-src.zip, and extracting its datatime.py module. For convenience all the files can bestored along with the mod python handler setting up the SOAPpy server, in afolder under the htdocs Web server folder.
5.2 PyS60 SOAP processing 47
Few modifications had to be made to the code in order to get it to work cor-rectly on the device. How to check the type of a variable has changed inpython over the years and type comparisons in SOAPpy were incompatiblewith PyS60. Type checks on variables is used extensively in parsing the incom-ing SOAP message to python structure and again when building the SOAPresponse. The change had to be applied in files responsible for parsing theincoming SOAP message and generating the response: Types.py, Parser.py andSOAPBuilder.py.
Statements like:if type(sample) == InstanceType:needed to be changed to be like:isinstance(sample,type)and statements like:if type(rules) not in (NoneType, DictType):needed to be changed like:if type(rules) != type(None) and type(rules) != type({}):
That is, instead of using the name of the type to check against the variable asample instance of the type is used. Thus, to check if type(rules) is not NoneTypeand Dict, it is checked against a None (NoneType instance) and {} an emptyDict. Changes like these had to be applied in various places in those files.Full list of python type names and sample instances can be found at http://docs.python.org/lib/module-types.html.
A bug was discovered in SOAPpy Parser.py module at the following codeblock on line 245:kind = (self._prem[kind[:i]], kind[i + 1:]).Throwing a KeyError: xsd exception. A patch was found on http://osdir.com/ml/python.pywebsvcs.general/2005-08/msg00016.htmland successfully applied.
48CHAPTER 5. MOBILE WEB SERVICE FRAMEWORK
IMPLEMENTATION
Finally the code in listing 5.2 can be used to publish a function as a Web servicethrough mod python.
Listing 5.2: SOAPpy simple server example
1 import SOAPpy2
3 def echo(s):4 return s + s # repeats a string twice5
6 def handler(req):7 from mod_python import apache8
9 # set the output content header10 req.content_type = 'text/xml'11
12 server = SOAPpy.Server.modSOAPServer()13 server.registerFunction(echo, 'http://www.example.org/
samplenamespace/')14
15 req.write(server.handleRequest(req))16
17 # send out a 200 OK response18 return apache.OK
When a request is received, the handler function is executed (done by mod pythonconfiguration), passing it an instance of the mod python request object as ar-gument. The request object contains all information about the request, such asheaders and data. In the handler function the output content header is set totext/xml, a new instance of SOAPpy.Server.modSOAPServer is created and thefunction echo registered on the SOAPpy server. The request object is thenpassed to the modSOAPServer.handleRequest method from where it is passedto SOAPpy.Server.modSOAPRequestHandler. There it is parsed, the correct func-tion depending on the input SOAP message executed (echo being the only op-tion in this example), and the appropriate SOAP response message created.Finally the response message is written to the mod python response and a 200OK response sent to the caller.
5.3 Overview
SOAPpy provides the SOAP processing model module to the Mobile Web Ser-vice Framework. Figure 5.1 shows the overview of the framework again, im-plemented on S60, running on top of the Mobile Web Server. All requestscome through the Mobile Web Server, from clients either within the S60 plat-form or from external requesters, directly or through the gateway. Throughthe mobile Web server the framework publishes the three specified interfaces:soapserver.py, WSDL and manager.py.
5.3 Overview 49
Figure 5.1: S60 Mobile Web Services Framework
File structure
All files of the implementation are stored in a folder named webservices residingin the htdocs folder of the Mobile Web Server. The contents under the webser-vices have the following directory structure.
• install - Contains files that are used the first time the framework is runon a device. Now only WSDL files for services that are shipped with thedistribution.
• manager - Contains the manager interface implementation.
• py - Python implementation for serving the Web services, missing PyS60modules and framework implementation classes.
– SOAPpy - The SOAPpy proccessing module.
50CHAPTER 5. MOBILE WEB SERVICE FRAMEWORK
IMPLEMENTATION
– webservices - Implementations of installed Web services.– xml - the python XML library.
• policy - A script to create policy assertions.
• wsdl - WSDL files for published services.
5.4 Database
The Database is an essential central part of the system which other parts useto perform their functions. The Database is a native Symbian S60 database,Symbian S60 databases are very primitive. They allow for storing data in ta-bles and perform the simplest SQL statements on those tables. The database,shown in 5.2, contains four tables: Services (stores information about publishedservices), operations (stores information about each operation published by theservices), users (stores information about the users of the system) and userpriv-ileges (stores what operations users have access to). It is not designed withoptimal normalization in mind but rather to cope with Symbian database lim-itations and making the needed information accessible in as few and simpleStructured Query Language (SQL) statements as possible.
Figure 5.2: Database structure
5.5 SOAPServer Interface
The SOAPServer Interface is implemented as a python module, soapserver.py,based on the code from section 5.2. It is located at https://username.mymobilesite.net/webservices/py/, and handles all requests to that lo-cation with the .py ending. When a GET request is received it is redirected tothe WSDL interface at https://maggi.mymobilesite.net/webservices/wsdl/index.wsdl. Otherwise the SOAP server is set up and the incomingrequest processed by SOAPpy. When sending a SOAP request to a servicethe endpoint should be set to https://username.mymobilesite.net/webservices/py/Servicename.py, where Servicename is the actual nameof the service to be requested. Information about operations are read from thedatabase and used to set up the server. The code in listing 5.3 shows the mainoutline of soapserver.py
5.5 SOAPServer Interface 51
Listing 5.3: soapserver.py
1 def handler(req):2 ...3 # Get Service name4 uri = req.uri5 serviceName = uri[uri.rfind('/')+1:uri.rfind('.')]6 ...7 if req.subprocess_env['REQUEST_METHOD'] == 'GET':8 # Redirect to WSDL interface9 req.headers_out['location'] = str('https://' + req.
headers_in['host'] + mwsConstants.wsdlwebpath + 'index.wsdl')
10 return apache.HTTP_MOVED_TEMPORARILY11 else:12 # set the output content header13 req.content_type = 'text/xml'14 try:15 # Initialize server object16 server = SOAPpy.Server.modSOAPServer()17 server.setNamespace('http://www.example.org/
mobilewebservices/')18 #Open db19 ...20 # Get operations from the database21 result = SQLSelect(db,u"SELECT operation,
namespace, classname FROM operations WHEREservicename = '" + unicode(serviceName) + u"'")
22 #get the service class23 className = result[0][2]24 # Get a reference to the serviceClass with the
className from the database25 serviceClass = webservices.__dict__[className](
)26 # set web service host attribute on the service
class27 serviceClass.setWebserviceHost(req.headers_in['
host'])28 namespace = ""29
30 for i in range(0, len(result)):31 row = result[i]32 if hasattr(serviceClass, row[0]):33 namespace = row[1]34 #row[0] contains the operation
from the database35 #gets a refrence to the method
with the name in operationimplemented in the classserviceClass
36 #registers the method refrenceon the SOAP server in theappropriate namespace
52CHAPTER 5. MOBILE WEB SERVICE FRAMEWORK
IMPLEMENTATION
37 server.registerKWFunction(getattr(serviceClass, row[0]),row[1])
38
39 # register the authentication method on theserver
40 server.registerKWFunction(getattr(serviceClass,'isAuthenticated'), namespace)
41 except Exception, e:42 # Handle exception43 ...44 ...45 # Call the request handler and return the output46 req.write(server.handleRequest(req, serverConfig))47 ...
The interesting part in the code in listing 5.3 is how the name of the operationand class from the database is converted into a reference to the implementedcode with the Python standard __dict__ method andgetattr(class, ’functionname’) function. In order for this to work allservice classes have to be members of the webservices python packet, explainedin the next section.
5.6 Webservices module
The webservices packet contains the service implementations, it is implementedas a folder stored under /webservices/py/webservices/ in the servershtdocs folder. There, a python file for every installed service is stored in afile named Servicename.py. The folder is made into a Python packet with an__init__.py file importing all the services. This file has to be recreated ev-ery time a service is installed or removed. By registering all service classes inthe webservices packet, a reference to the implemented code can be obtainedthrough the standard python __dict__ method as shown above. Calling thedict method on the Packet with a classname, likeserviceClass = webservices.__dict__[className]() returns a ref-erence to the class in the serviceClass variable. Then callinggetattr(serviceClass, "methodName") returns a reference to the method-Name method of that class. This reference is registered on the server.
5.7 Common Classes
mwsAuthentication
mwsAuthentication is a class implementing the code needed for authenticatingrequests to services. Each implemented service should extend mwsAuthenti-
5.7 Common Classes 53
cation and its isAuthenticated method is registered on the server as the authen-tication method.
When processing a request, SOAPpy will call the isAuthenticated method, pass-ing it the current SOAPContext that contains all information about the re-quest. isAuthenticated checks if valid authentication information is providedin the SOAPContext and whether access to the requested operation is allowed.Whether to allow a request to a service depends on the fields public and require-https from the database. They control if the method is public or private and ifit allows direct requests or only requests through the gateway. isAuthenticateduses the validateUser method of mwsAuthentication to authenticate the requester.It checks the SOAPContext for authentication information and validates the in-formation against the information stored in the Users table in the database. Atthe time of writing, it has been implemented to support HTTP Basic authenti-cation and WS-Security UsernameToken, both basic and digest as shown in theprevious chapter. Unfortunately PyS60 has very limited cryptographic capabil-ities, only containing an implementation of the MD5 hash function. AlthoughMD5 can be used to implement password digest, SHA-1 is specified in the to-ken profile as discussed in the previous chapter. PyS60Crypto3 is a small thirdparty cryptographic library for PyS60. It provides implementations of SHA224and SHA256 hash functions, but does not SHA-1. No other PyS60 library wasfound that implemented SHA-1, but a pure python implemented function wasfound4. Testing it on a device turned out to work well. Due to the limited cryp-tography support no attempts have been made to support digital certificates ormessage signing. The basic outline of validateUser is shown in listing 5.4.
Listing 5.4: Validating a user using HTTP Basic Authentication
1 def validateUser(self, _SOAPContext):2 ...3 if _SOAPContext.header != None and "Security" in
_SOAPContext.header._keys():4 # SOAP Security header is set5 WSSecurityHeader = _SOAPContext.header.
__getitem__("Security")6 if "UsernameToken" in WSSecurityHeader._keys():7 # Get attributes and other values8 passwordTagAttributes = _SOAPContext.
attrs[id(WSSecurityPassword)]9 ...
10 # Check password type11 if cmp(passwordType, u'http://docs.
oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#PasswordDigest') == 0:
12 # Handle password digest13 ...14 else:15 # Handle PasswordText type16 ...
3Available from http://www.lfdm.net/thesis/index.php/dlm/274Available from http://codespeak.net/pypy/dist/pypy/lib/sha.py
54CHAPTER 5. MOBILE WEB SERVICE FRAMEWORK
IMPLEMENTATION
17 else:18 # Security not in header keys19
20 # No WS-Security header, check HTTP headers as before21 (authenticationtype, username, password) = self.
parseHttpHeaders(_SOAPContext.httpheaders)22 if authenticationtype != None and username != None and
password != None:23 # Authenticate user using HTTP Basic24 sqlQuery = unicode("SELECT id FROM users WHERE
username = '%s' AND password = '%s'" % (username,password))
25 result = self.SQLSelect(sqlQuery)26 if (len(result) != 0):27 self.username = username28 return True29 else:30 return False31 # If nothing above then not authenticated32 return False
The _SOAPContext variable contains both the SOAP headers and HTTP head-ers. validateUser first checks for a WS-Security header in the SOAP header andif found, it checks whether it contains a UsernameToken. If a UsernameTo-ken is found it checks whether it is a password digest or a plain text token.If no UsernameToken is found in the SOAP Headers, the HTTP headers arechecked next. The function parseHttpHeaders is used to get the required valuesfrom the HTTP header. They are then compared against the values stored inthe database. The code for Handle PasswordText type is very simple and basi-cally identical to the HTTP Basic Authentication. The only difference is thatthe username and password need to be taken from the WS-Security usernametoken.
The code within the Handle password digest needs to extract the required val-ues from the WS-Security username token and then check that the timestampvalue is within the allowed window. The window has been defined to be 3600sec (accounting for mobile device clocks not always very accurate). This checkis done by a simple function digestCheckCreated. Then the nonce is decodedbased on the encoding type. After it has been decoded the nonce is checkedagainst previous used nonce values, implemented by the function mwsAuthen-tication.digestCheckNonce. Nonce values that have been used are stored in a filewith their timestamp. Finally, if both of the above checks finish successfully,the digest password is calculated by the getPasswordDigest function using thestored password, sent nonce and sent timestamp. The calculated digest is thencompared against the sent digest.
5.7 Common Classes 55
The code for getPasswordDigest is shown in 5.5.
Listing 5.5: mwsAuthentication.py, getPasswordDigest
1 def getPasswordDigest(self, nonce, WSSecurityCreate,WSSecurityUsername):
2 # Computes a digest on the password from the database3
4 # Fetch the password for this user from the database5 result = self.SQLSelect(unicode("SELECT password FROM
users WHERE username = '%s'" % (WSSecurityUsername)))
6 password = result[0][0]7
8 # Compute the digest for this password9 s = sha.new()
10
11 s.update(nonce)12 s.update(WSSecurityCreate)13 s.update(password)14 digest = s.digest()15
16 # Base64 hash the digest, we get it transmitted in thisformat
17 base64digest = base64.encodestring(digest)18
19 # remove newline char20 base64digest = base64digest[:-1]21
22 return base64digest
mwsGeneral
Every service should extend the mwsGeneral class and it implements commonmethods for every service. It can be used by the framework to pass generalinformation to the service implementation for example the host name (user-name.mymobilesite.net) which the service is being accessed through. It canalso be used to implement standard operations that every service should im-plement, for example getModuleVersion and getModuleAuthor.
mwsManager
In mwsManager common management functionality for the framework is im-plemented. This management functionality is then used by a published Man-agement service and the Management interface. mwsManager implementsthe following functions: getUsers, getInstalledServices, getInstalledOperations, ge-tUserPrivileges, deleteUser, createUser, checkIfUserExists, getServiceName, getOp-erationId, setPrivate, setPublic, allowHTTP, requireHTTPS, grantUserAccessToSer-
56CHAPTER 5. MOBILE WEB SERVICE FRAMEWORK
IMPLEMENTATION
vice, deleteUserAccessToService, grantUserAccessToOperation, deleteUserAccessTo-Operation, setServicePrivate, setServicePublic, setServiceAllowHTTP, setServiceRequire-HTTPS, deleteService, createInitLinkingFile, installService. Most of them changesettings in and maintain the database used by the framework.
The installService method is responsible for installing new services into theframework. It takes two python file object as arguments; one containing theservice implementation code and another containing the WSDL description.The interfaces using the method are responsible for uploading the files andpassing them to the function. The source file needs to be a python class filewith a name of Sampleservice.py defining the python class Sampleservice. In theWSDL file the endpoint address should be defined as MWSENDPOINT, thatwill be replaced with the appropriate value when installed on the server.
When a service is installed its source file is saved to the locationwebservices\py\webservices\ and its WSDL file to the location webservices\wsdl\,under the mobile Web servers htdocs folder. The servicename, classname andnamespace are saved to the services table in the database. The classname isthe name of the sourcefile without the ending, the servicename is the name ofthe WSDL file without the .wsdl ending and the namespace is read from thetargetNamespace attribute in the WSDL file. Next the WSDL file is searched for<wsdl:operation> decelerations, the operation names extracted and savedto the operations table.
In order to be able to link the class name in the database to the actual code im-plementation, thewebservices\py\webservices\ folder is defined as a Python packet containing allthe service classes, as described above. The createInitLinkingFile function isused to create the needed __init__.py in the webservices directory. It im-ports all the service class files with statements like:from Servicename import * It also creates the index.wsdl file that is servedfrom the WSDL directory. Importing the WSDL files of all installed services.This function is also called when a service is removed from the framework,recreating those files.
Launch external thread
The Mobile Web Server runs in a Symbian server thread. Server threads arenone User Interface (UI) threads and can not interact with the UI of the device.The object launchExternalThreadObject and the functions launchExternalThreadand getLaunchExternalThreadObject, within the mws mdoule, implement the codeneeded to pass execution to a UI thread.
The launchExternalThreadObject is used to contain the information that need tobe passed between the two threads, the module, object and function to executeand the variables to pass it. The two functions then define how the object ispassed and execute the new thread. Currently, Pythons pickle module is usedto serialize the launchExternalThreadObject to a file. Then the pyLaunch appli-cation, explained below, is executed with the following Symbian statement:
5.8 Service Implementations 57
e32.start_exe(u’c:\\sys\\bin\\pyLaunch_0xe8f72d57.exe’,’’)pyLaunch then uses the function getLaunchExternalThreadObject to get the orig-inal object.
mwsConstants
mwsConstants defines various common constants which are used within theframework, for example the location of the database and paths to files.
5.8 Service Implementations
As already stated, every service class should extend the mwsAuthentication andmwsGeneral classes. Authentication and authorization is handled by mwsAuthen-tication with the isAuthenticated method registered as the authentication methodfor each service on the server.
Implemented services can expose every PyS60 code as a Web service. Throughthe PyS60 API, The service can utilize and expose device functionality. Theservices created for this project have mainly been wrapping features from thePyS60 API as Web services.
The only requirement to create and publish a new Web service is to create thePython class file and a corresponding WSDL file. The python class file canbe as simple as the file shown in listing 5.6 and its corresponding WSDL inSampleService.wsdl, shown below.
Listing 5.6: SampleService
1 import mws2
3 class SampleService(mws.mwsAuthentication,mws.mwsGeneral):4
5 version = "v1.0" #Version number of the class6 author = "Tester" #The author of the class7
8 def sayHello(self, name):9 return "Hello: " + name
<?xml version="1.0" encoding="UTF-8" standalone="no"?><wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:tns="http://www.example.org/webservices/SampleService/"xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"xmlns:xsd="http://www.w3.org/2001/XMLSchema"name="SampleService"targetNamespace="http://.../webservices/SampleService/">
<wsdl:types>
58CHAPTER 5. MOBILE WEB SERVICE FRAMEWORK
IMPLEMENTATION
<xsd:schematargetNamespace="http://.../webservices/SampleService/"><xsd:element name="sayHello">
<xsd:complexType><xsd:sequence>
<xsd:element name="in" type="xsd:string"/></xsd:sequence>
</xsd:complexType></xsd:element><xsd:element name="sayHelloResponse">
<xsd:complexType><xsd:sequence>
<xsd:element name="out" type="xsd:string"/></xsd:sequence>
</xsd:complexType></xsd:element>
</xsd:schema></wsdl:types><wsdl:message name="sayHelloRequest">
<wsdl:part element="tns:sayHello" name="parameters"/></wsdl:message><wsdl:message name="sayHelloResponse">
<wsdl:part element="tns:sayHelloResponse" name="parameters"/></wsdl:message><wsdl:portType name="SampleService">
<wsdl:operation name="sayHello"><wsdl:input message="tns:sayHelloRequest"/><wsdl:output message="tns:sayHelloResponse"/>
</wsdl:operation></wsdl:portType><wsdl:binding name="SampleServiceSOAP" type="tns:SampleService">
<soap:binding style="document"transport="http://schemas.xmlsoap.org/soap/http" /><wsdl:operation name="sayHello">
<soap:operationsoapAction="http://.../webservices/SampleService/sayHello" /><wsdl:input>
<soap:body use="literal" /></wsdl:input><wsdl:output>
<soap:body use="literal" /></wsdl:output></wsdl:operation>
</wsdl:binding><wsdl:service name="SampleService">
<wsdl:port binding="tns:SampleServiceSOAP" name="SampleServiceSOAP">
5.8 Service Implementations 59
<soap:address location="MWSENDPOINT"/></wsdl:port>
</wsdl:service></wsdl:definitions>
In the WSDL the target namespace is defined: http://www.example.org/webservices/SampleService/. It is thus unique for every service so thatdefinitions for one service do not conflict with another. Under the service de-scription the port binding address location is simply set to MWSENDPOINT.That string will be replaced with https://hostname/webservices/py/SampleService.py when installed on the server. After the files have beencreated they can be installed by uploading them with the manager interface asexplained in section 5.10.
The example above returns a simple string, which SOAPpy automatically se-rializes into a XSD:String. Complex data structures can be returned by usingpython dictionary structures and SOAPpy data types defined in Types.py. Seethe services implemented for this project as an example.
All services published by the framework are defined in this way, This meansthat all services are published through the plug-in architecture. After the fileshave been created they can be installed on the server through the MangementInterface or the management service.
Through the use of launchExternalThread and launchExternalThreadObject, a ser-vice can execute code in a UI thread if needed. The code example in 5.7 il-lustrates their use. A launchExternalThreadObject is created, the module, objectand function that should be executed is set along with parameters to pass tothe function. Then the thread is launched with the launchExternalThread func-tion. The actual method of how the parameters are passed are hidden from theservice implementer.
Listing 5.7: Execute code in UI thread
1 def sayHello(self, name):2 try:3
4 # Launches an external program that displays themessage to the user of the phone
5 # Parameter passing is done through a simple text file6
7 leto = mws.launchExternalThreadObject()8 leto.setModule("Sampleservice") # The module with the
UI code9 leto.setObject("SampleService") # The object with the
UI code10 leto.setFunction("sayHelloUI") # The function with the
UI code11
12 leto.addParameter("message",message) # Add a parameter13
14 mws.launchExternalThread(leto) # Execute the function
60CHAPTER 5. MOBILE WEB SERVICE FRAMEWORK
IMPLEMENTATION
15
16 return "success"17 except Exception, e:18 raise faultType("SOAP-ENV:Server","sayHello failed.",e)19
20 def sayHelloUI(self, name):21 import appuifw22 # The function that gets executed23
24 # Displays the message25 appuifw.note(u'Hello: ' + name, "info")
5.9 Thread launcher
pyLaunch is the actual application that is executed when an external thread isstarted. It is implemented in Python and has to be installed on the device as anapplication.
When started, pyLaunch uses the getLaunchExternalThreadObject function tounpickle the launchExternalThreadObject from the file. It then uses __dict__and getattr in a similar manner as the SOAP server to get a callable referenceto the function to be executed. The full code for pyLaunch is shown in listing5.8.
Listing 5.8: pyLaunch
1 import os2 import os.path3 import sys4
5 # Put Web service store into path6 for path in ('c:\\Data\\Web server\\htdocs\\webservices\\py\\
webservices','e:\\Data\\Web server\\htdocs\\webservices\\py\\webservices','c:\\Data\\Web server\\htdocs\\webservices\\py','e:\\Data\\Web server\\htdocs\\webservices\\py'):
7 if os.path.exists(path):8 sys.path.append(path)9
10 import webservices11 import mws12
13 #Get the object14 launchExternalThreadObject = mws.getLaunchExternalThreadObject(
)15 #Get arguments to call function with16 args = launchExternalThreadObject.getArgs()17
18 #Get a reference to the function19 function = getattr(webservices.__dict__[
launchExternalThreadObject.getObject()](),launchExternalThreadObject.getFunction())
5.10 Management interface 61
20
21 #Call the function22 apply(function,args)
Code executed with pyLaunch can communicate result back to the originatingcaller by using the SOAPpy packet to initiate a call back request. That is simpleand robust when a long wait is required and has been used in this project.Another approach would be to stall the Web Server thread by implementing aloop after calling mws.launchExternalThread. Then wait for a result to bewritten to a file, break out of the loop after the result is received and return itto the originating caller.
5.10 Management interface
The management interface has been implemented in python and python serverpages. It is served from the mobile phone as a Web site, using functions frommwsManagement introduced above to perform its operations. After installingthe mobile Web services on a device, the management interface should be avail-able through https://username.mymobilesite.net/webservices/manager/.py. When accessed, the interface prompts for the administrator user nameand password which by default is ”admin” and ”admin”. Authentication takesplace through HTTP basic authentication. Using HTTP basic authentication isthe suggested approach by Nokia when securing mobile Web sites [27]. The de-fault password can of course be changed and doing so is highly recommended.
After logging in, the user sees an interface that is roughly divided into threesections; see screen shots in Appendix E.1:
• Set admin password
By typing a new password in Admin password and Confirm admin pass-word, the admin password to the interface can be changed.
• Mobile Web Services Users
Under this section new users for published Web services can be createdby typing in a user name, password, confirming the password and clickCreate user. Users created in this manner should not be confused withthe admin user to the management interface. They can only be grantedaccess to specific Web services, not the management interface. As wellthe admin user which is used to gain access to the management interfacecan not be used for authentication to a specific Web service.
It is possible to delete installed users by clicking on the Delete link besidetheir name. To change a users password the user can be recreated. If theuser exists the password is overwritten.
• Web services
62CHAPTER 5. MOBILE WEB SERVICE FRAMEWORK
IMPLEMENTATION
Installed services on the system are displayed along with informationabout them (Servicename, Classname, Operation, Namespace, Public orPrivate and whether HTTPS is required or not). The Public column stateswhether the operation is accessible to everyone, or only to granted users.Its status can be changed by clicking the Make private or Make public linksbeside it. When set to Private a list of granted users are displayed belowthe service or No users have been added! if no user has yet been grantedaccess. Installed users can be granted access by choosing the user namefrom a drop down box and clicking the Grant access button. By clickingthe Require HTTPS link beside an operation it can be set to be only acces-sible through the gateway, denying local requests. Getting informationabout the active network connection requires capabilities beyond thoseof the Mobile Web server. Therefore it is not possible to further controlfrom within what networks the operation is accessible.
Below all the operations, all installed service classes are listed. Everyoperation belongs to some service class and here the entire class can bemade private or public with a single click similar as described above.Further, a service class can be deleted and removed completely.
• Install a new service
New services can be installed by uploading their source file, WSDL fileand click the Install service button. The files will then be uploaded tothe server, placed into a python file object and passed to the installservicemethod of mwsManagement.
5.11 WSDL Interface
WSDL files for installed services are stored in the folder \webservices\wsdl\andaccessible through https://username.mymobilesite.net/webservices/wsdl/index.wsdl. When a new service is installed, its WSDL file is pub-lished to this location and the endpoint in the WSDL set to point to the correctmobile Web site. The index.wsdl imports the WSDL files of all installed ser-vices and is created each time a new service is installed.
Since Python is a loosely typed language, automatically creating the WSDLfrom code is very difficult, some solutions exist that are based on code anno-tations. Generally though, WSDL creation in Python is immature and badlysupported. Thus in the work related to this thesis, WSDLs where created in anexternal tool and uploaded with the service description to the file.
5.12 Create Policy
Create policy is a simple script that reads the policy information from thedatabase and creates policy assertion statements accordingly. Policy assertions
5.13 Limitations of the platform 63
are created depending on whether the service or operation requires requests tobe made over HTTPS and whether it is public or requires a UsernameToken.
The policy script is located in the folder webservices\policy and can be re-quested through https://maggi.mymobilesite.net/webservices/policy/.py?service=Calendar, taking the service name as input parameter. Its as-sertions can be imported into the corresponding WSDL description for a ser-vice with an import element like:
<wsdl:import namespace="..."location="../policy/.py?service=Calendar"></wsdl:import>
The assertions created are named with ids serviceNamePolicy and operationName-Policy and can be attached to the corresponding elements with a PolicyReferenceelement like [2, p. 378]:
<wsp:PolicyReference URI="#serviceNamePolicy"wsdl:required="true" />
Forcing the import of the policy script and creating the appropriate attach-ments could be done automatically when a new service is installed on the sys-tem. That has though not been done now and is thus the responsibility of theservice implementor.
Through a request to http://username.mymobilesite.net/webservices/wsdl a client can thus get information about all installed Web services in theframework and their policies.
5.13 Limitations of the platform
The main limitations of the platform are associated with the Symbian signingprotection. Scripts executed by the Mobile Web Server only have the same setof capabilities as the Mobile Web Server. This is though also a good thing, sinceit helps protect the resources of the mobile device from unwanted access.
The overall request time when requesting services through the framework isusually around 4-7 seconds, depending on the amount of transferred data andthe connection strength at each time. Although this can not be considered fast,it is well within the endurance level in most occasions. A natively compiledSymbian C++ implementation should decrease the execution time on the de-vice and bring the request time close to the limitations of the mobile connec-tion.
As demonstrated, PyS60 hardly has any cryptography capabilities and thus ithas not been able to implement certificate authentication and message decryp-
64CHAPTER 5. MOBILE WEB SERVICE FRAMEWORK
IMPLEMENTATION
tion and encryption. Symbian C++ and J2ME have more sophisticated cryp-tographic libraries and should be able to provide this functionality. This func-tionality could also be implemented as a Python extension module to SymbianC++ cryptographic library.
SOAPpy is a very raw implementation of the SOAP processing model and doesnot support well advanced features. For instance it has no support for attach-ments. It is though very flexible and such add-on features should be easy toimplement.
Chapter 6
Mobile Web Services APIDescription
Using the framework presented in the last two chapters, application develop-ers can create and publish Web services. As stated in 3.2, requiring every ap-plication developer to create and maintain Web services for every platform, isclearly not very feasible. It is even less feasible when security and managementconsiderations are taken into the picture. Publishing numerous application de-veloper specific services, with unclear description or meaning, lowers securitybarriers. Furthermore, the precise task and function of the service becomes un-clear. Current Web service standards give a uniform way of accessing servicesbut convey no information about the schematic of published services.
A standard Web service interface description is beneficial in a setting where aWeb service requester is likely to be requesting services from multiple differentWeb service providers. Although mobile devices are the providers of Web ser-vices; the service hosts, their owners are likely to be clients of a service createdby an application developer/provider providing a service. The service mostlikely has to request Web services from multiple devices in order to deliver itsservice to device owners.
Chapter 3.3 introduced the Parlay X specification, solving the same need in pro-viding application developers a uniform interface to telecommunication oper-ators systems. This chapter will make an attempt at creating the basis for sucha uniform interface for mobile hosted Web services. Starting with defining therequirements of the interface, identify the functionality needed, group func-tionality into services, create a WSDL description of those services and finally,implement a set of services for the mobile web service framework on S60. Atbest, those outlines can be a starting point for further standardization withinthe field. In order to reach a usable common interface, proper standardization,involving different interest parties in the field needs to take place.
66 CHAPTER 6. MOBILE WEB SERVICES API DESCRIPTION
6.1 Interface requirements
Before designing and describing an actual interface it is worth to consider thegoals that a uniform mobile interface would have to cohere. In order to beusable and feasible, the interface should have the following characteristics.
• Interoperable
Mobile devices and their platforms are different, provide different meth-ods and functions, use different data types and are based on differentoperating systems and programming languages. The interface shouldnot be bound to a specific device platform, it should be implementablefor every platform and not favor one at the cost of others.
• Describe all relevant general parts
It should describe an interface to all general parts of a mobile device.Meaning, that it should provide an interface to all needed common func-tions of mobile phones. Common functions are for example the ability todial a number, take a picture, work with contacts and manage calendarentries. Those are features that are generally considered to be providedby every mobile device.
• Leverage on existing standards
The interface should leverage on existing standards as much as possibleand limit itself to describe the schematics of the general mobile deviceplatform.
• Simple
The interface should be simple to use and descriptive. Simplicity is pro-vided by describing and publishing the interface in a valid WSDL lan-guage that can be automatically interpreted by Web service tools andframeworks to generate client and service code. Furthermore, names ofinterfaces (portType), operations and data types also have to be mean-ingful and understandable.
• Minimize number of needed requests
In order to utilize the mobile channel efficiently the interface should at-tempt to limit the number of needed request when fetching information.
• Minimize amount of data in each request
In order to utilize the mobile channel efficiently the interface should at-tempt to limit the amount of data in each request. Meaning it shouldattempt to minimize the amount of unnecessary data in each request.
Most of those goals are common goals and best practices for useful and de-scriptive interface. The usage of common Web service standards goes a longway in providing interoperability, leveraging on existing standards and sim-plicity. The last two goals are more specific to the mobile environment, withexpensive data cost rates, high request response time, limited CPU power and
6.2 Functionality 67
precious battery life time. The two requirements are also conflicting, in orderto minimize the number of requests the only thing that can be done is to stuffmore information into a single request. That on the other hand, increases thenumber of data sent in each request and likely the number of unnecessary data.
One way to solve this dilemma would be to allow the possibility of varying theactual output of a request to the need at each time. Meaning that the responsetype would define as large scope of return values as feasible to fulfill the firstrequirement, having as many of them as possible optional. The client of theservice could then, through an input parameter, specify the actual parameterswanted for its response. The service would read the input parameter, processthe request but only return the desired output variables requested, other wouldnot be set at all and dismissed in the output. On the receiving end they wouldbe undeclared or empty. In this way, a filter variable in the input controls theactual output. This filter variable would be optional and omitting it wouldresult in the largest available data set.
6.2 Functionality
In order to determine the needed functionality for a mobile Web service inter-face a good starting point is to look at existing mobile application program-ming environments and the functionality provided by their APIs. The mostwell known and supported of those are:
• Java, Micro Edition: Offers various functionality through published JSRlibraries.
• PyS60: Has a feature rich API library allowing access to device features[4].
• Symbian C++: For development on S60, S680 and UIQ devices.
Its also essential to look at other related interfaces, as the Nokia REST API andParlay X Web service interface, here they are explained in some more detail.The Nokia REST API1, was introduced in version 1.3 of the Mobile Web Server,at the time of writing it is very limited. It only defines two main interfacesPresence and Messaging. The presence service is further divided into availabil-ity, devicestate and location. The availability resource indicates whether the useris currently available in terms of: the selected profile, whether in a call or hav-ing active calendar entries. The devicestate publishes the battery level, localtime and connection type. The location resource publishes latitude, longitude,accuracy and location method.
The message resource takes in a message with the maximum length of 500 char-acters and inserts it into the device Inbox. Obviously the API is very limited
1Described at http://wiki.forum.nokia.com/index.php/Mobile_Web_Server_APIs#REST_APIs_.28since_MWS_1.3.2C_Location_updated_in_MWS_1.4.29
68 CHAPTER 6. MOBILE WEB SERVICES API DESCRIPTION
in functionality and application developers are encouraged to implement newservices as needed. It only utilizes the POST and GET HTTP methods.
The Parlay X standard is divided into the following functional parts: ThirdParty Call, Call Notification, Short Messaging, Multimedia Messaging, Pay-ment, Account Management, Terminal Status, Terminal Location, Call Han-dling, Audio Call, Multimedia Conference, Address List Management and Pres-ence. Of those parts, the following conform to similar functionality that wouldalso be expected to be provided by a mobile Web service interface.
• Call handling - Web services to set up and tear down call and check if themobile device has an active call.
• Call Notification - Web service that would register a call back handler thatwould be requested when receiving an incoming call, dialling a numberand ending a call.
• Short Messaging - Web service to send SMS messages from the device,saving a message in the device Inbox, deleting a message from the de-vice inbox and register a call back handler that would be requested whenmessages where received or sent. Also operations to push ring tones andlogos to the device.
• Multimedia messaging - Same as for the SMSs.
• Terminal status - Information about the status of the mobile device.
• Terminal location - Information about the location of the mobile device.
• Presence - Web services to get the presence information of the devices.
There is though a big difference in requesting a service from the mobile net-work or a single device. Most of the services take in a required parameterspecifying the device or devices the operation applies to. That is obviously notapplicable in the case of a mobile hosted service where each request is made toa specific device. Many also take in a billing argument, specifying who shouldbe charged for the usage, the application developer or the mobile subscriber.That does not apply in mobile device hosted services, since, it is always thesubscriber that will be charged for usage.
The interfaces described by Parlay X and the REST API are used as much aspossible as guidelines in describing the new interface. Investigating the fea-tures of the above mentioned APIs it becomes clear that broadly, the function-ality needed can be split into three high level categories, Presence and Systeminformation, Device Utilities and Data Management.
• Presence and System Information: All information related to the user of thedevice and underlying system of the devices. Such as getting the currentlocation, battery level, display size, IMEI number, OS version and such.
6.3 Interface Design 69
• Device Utilities: All methods that use the mobile device to perform somekind of function can be classified. Such as send a message, dial a number,record and play an audio clip.
• Data Management: All device data management functionality is provided.Such as manage and retrieve calendar entries, contacts and device logdata.
Additionally to the above parts the interface also has to provide features forWeb services management.
Classifying the functionality of the above mentioned APIs into those categoriesand further classifying them into entities and operations/methods performedon those entities brings the foundation for needed services and their opera-tions. See table A.1 in Appendix A.
6.3 Interface Design
The interface is described as WSDL documents, declaring data types in XMLSchema. To increase interoperability the interface will be based on WSDL 1.1.However guidelines from section 2.4 will be followed as appropriate to makeit as compliant and easy to convert to WSDL 2.0 as possible. Each derived Webservice from table A.1 will be defined with its own WSDL file.
In a similar manner, the Parlay X API breaks its interface down into multipleservices, defined in separate WSDL files. The Parlay X API though goes fur-ther and declares that type decelerations, faults, service interfaces and servicebindings should all be defined in separate files. That is not very optimal for themobile medium as transmission delay usually greatly increases by the numberof files transmitted. Requiring that four separate files need to be transmittedeach time the service definition is requested, is not feasible. As illustrated inchapter 4.2 the WSDL can be used to publish policies for the service in a stan-dardized way. Policies on mobile hosted services can change very frequentlyand thus probably lead to WSDLs being requested more often. To ease man-ageability, common types have been defined in a separate file, common.xsd,that can be imported into interfaces that need them. It contains common typessuch as a type for specifying a call back service. This should prevent a man-agement nightmare and keep the number of fetched files within 2-3 for eachservice. Further optimization could be done before publishing the interface onthe mobile device by copying the needed data types, from common.xsd, intothe files that need them. That could be done automatically by a tool.
Parlay X specifies a separate part for each input message, as noted in chapter2.4, messages and parts have been deprecated in WSDL 2.0. To support thatand help making the interface easy to extend to support REST based services,each message is defined only with one part element for each message direction.Each part then contains a XML Schema definition specifying the input.
70 CHAPTER 6. MOBILE WEB SERVICES API DESCRIPTION
Element Type Multiplicityid int [0..1]content string [0..1]location string [0..1]startTime dateTime [0..1]endTime dateTime [0..1]lastModified dateTime [0..1]alarm dateTime [0..1]priority int [0..1]replication string [0..1]asVcalendar string [0..1]entryType string [0..1]crossOutTime double [0..1]crossedOut boolean [0..1]
Table 6.1: calendarEntry
The next step in the interface definition is to define the input and output mes-sages and the types used in them as XML Schema types. Map these typesto elements in the message structures, and define the message structures asincoming and outgoing messages of an operation. Here the definition of theCalendar service will be outlined in more detail. The full WSDL interface isavailable on the companion CD and from the Internet at http://mobilews.mobcal.com/wsdl/. Appendix B also contains tables describing the port-Type and data types for each service. Their purpose at this time is to helpunderstanding the possible features and data that should be available throughmobile Web services. All design was carried out with the WSDL editor in theWeb Tools Platform (WTP) for Eclipse2.
The Calendar service specifies the calendarEntry type, shown in table 6.1, usedto represent a calendar entry in various input and output messages.
The input and output messages for each operation in the calendar service areshown in table 6.2. The resultFilter variable is used to vary the output of thecalendarEntry type. The reason for defining it as a string is just that it can beconveniently set. Setting it to content would result in only the content elementof calendarEntry being returned. Setting it to content,id would result in that bothcontent and id elements of calendarEntry would be set. The user can specify hisown delimiter to use between keywords, the service simply searches for thesubstring of the element name in the resultFilter before setting it. PortTypesand elements of other services are described in similar tables in Appendix B.
2See http://www.eclipse.org/webtools/
6.3 Interface Design 71
Direction Element Type MultiplicitygetEntriesAtDay: Fetch entries at a certain date
input year int [1..1]month int [1..1]day int [1..1]resultFilter string [0..1]
output out calendarEntry [0..*]getEntriesInMonth: Fetch entries within a month
input year int [1..1]month int [1..1]resultFilter string [0..1]
output out calendarEntry [0..*]insertEntry: Create a new calendar entry and returnes attributes of the created entry
input entryDetails calendarEntry [1..1]output out calendarEntry [1..1]
updateEntry: Update a calendar entry and returnes the last modified timestamp from the deviceinput entryDetails calendarEntry [1..1]output lastModified dateTime [1..1]
deleteEntry: Delete a calendar entryinput id int [1..1]output out boolean [1..1]
insertVCalendar: Takes in the VCal format and creates entries, returns ids of created entriesinput vcalendar string [1..1]output out int [0..*]
getEntry: Retrives a specific entry from the deviceinput id int [1..1]
resultFilter string [0..1]output out calendarEntry [0..1]
getEntries: Search for entries on the deviceinput startDate dateTime [1..1]
endDate dateTime [0..1]searchStr string [0..1]resultFilter string [0..1]
output out calendarEntry [0..*]
Table 6.2: Calendar portType
72 CHAPTER 6. MOBILE WEB SERVICES API DESCRIPTION
6.4 Implemented services
Of the described interface in table A.1 the following services have been im-plemented: Calendar, Contacts, Logs, MediaFiles, TerminalLocation, Generaland Management. Of those, the Calendar and Management services will beexplained in more detail.
Calendar Service
Listing 6.1 outlines the code for the calendar Web service, first needed mod-ules and types from SOAPpy are imported. Then, the main class CalendarMWSis declared inheriting from mws.mwsAuthentication and mws.mwsGeneral. Thename CalendarMWS is used because Calendar would conflict with the calendarclass from the PyS60 API. The class name implementing the service can be any-thing, and does not imply the name of the actual service. The service name isdefined in the WSDL document as described in 5.7 under mwsManagement. Theclass then defines two variables to indicate its version and author.
Published operations are defined as methods of the class taking in appropriatearguments to fulfill the function. The following methods are defined withinthe class and plublished as operations: getEntriesInMonth, getEntriesAtDay, in-sertEntry, updateEntry, deleteEntry, insertVCalendar, getEntry and getEntries.
Finaly three private methods are defined within the class and not published asoperations: parseEntryDetails , createOutputItem and dateTimeToEpoc .
Listing 6.1: Calendar Web service, python implementation
1 import time2 import calendar3 import SOAPpy4 import mws5 from SOAPpy.Types import faultType, voidType, simplify,
booleanType6
7 class CalendarMWS(mws.mwsAuthentication,mws.mwsGeneral):8
9 version = "v1.0"10 author = "Magnus Agust Skulason, [email protected]"11
12 def getEntriesInMonth(self, year, month, resultFilter = ""):
13 # Fetch entries in the specified month14 try:15 ...16 return output17 except Exception, e:18 raise faultType("SOAP-ENV:Server","Fetching
calendar entries failed.",e)19
6.4 Implemented services 73
20 def getEntriesAtDay(self, year, month, day, resultFilter =""):
21 # Fetch entries on the specified day22 try:23 ...24 return output25 except Exception, e:26 raise faultType("SOAP-ENV:Server","Fetching
calendar entries failed.",e)27 ...28 def __parseEntryDetails__(self, entryDetails):29 # Converts an incomming calendarEntry XML Schema type
to its python variables30 ...31 return (id,content,location,start_time,end_time,id,
last_modified,alarm,priority,replication,as_vcalendar,entryType,cross_out_time,crossed_out)
32
33 def __createOutputItem__(self, entryObject, resultFilter):34 # Creates a PyS60 Calendar Entry Object to the XML
Shcema type calendarEntry35 ...36 return itemOut37 def __dateTimeToEpoc__(self, input):38 # Converts an incomming dateTime string to epoc seconds39 ...
When executing a function SOAPpy delivers all simple types as strings andcomplex types as Python dictionary or array of dictionary. A Python dictionaryis a built-in data type that defines a one-to-one relationship between keys andvalues. It is thus necessary to cast the incoming parameters to their correct datatypes before using them. The calendarEntry type defined in the last section thusis delivered to the intended function as a dictionary with the element namesas keys and their values as names. The parseEntryDetails function is used tomap an input argument dictionary representing a calendarEntry XML Schematype to its Python variables. The createOutputItem function is used to cre-ate an output dictionary structure representing the calendarEntry XML Schematype from a PyS60 calendar entry object. The functions also convert to andfrom the appropriate types on the elements.
In general the operations are very simple, they convert incoming variables tothe appropriate Python types, use the calendar class of PyS60 to deliver theneeded functionality and create the result. The full code for the insertEntryoperation is shown in listing 6.2. On line 3 the input parameter entryDetails isconverted with the function parseEntryDetails to a tuple of its Python types.
On line 7 the calendar database is opened and on line 8 the calEntry variable isdefined. Lines 10-19 check the incoming type variable, create an new entry ofthe requested type and store it in the calEntry variable. Lines 21-44 assign theincoming values to calEntry type and on line 46 it is committed to the calendardatabase. Lines 48-52 create the output; a calendarEntry type containing only
74 CHAPTER 6. MOBILE WEB SERVICES API DESCRIPTION
the inserted id and lastModified timestamp of the entry. Finally lines 53-57 thenhandle exceptions.
Listing 6.2: Calendar Web service, insertEntry Operation
1 def insertEntry(self, entryDetails):2 # Insert the entry specified in entryDetails3 (id,content,location,start_time,end_time,id,
last_modified,alarm,priority,replication,as_vcalendar,type,cross_out_time,crossed_out) = self.__parseEntryDetails__(entryDetails)
4 try:5 # Open the calendar database6 cal = calendar.open()7 calEntry = None8
9 if type == 'appointment':10 calEntry = cal.add_appointment()11 elif type == 'event':12 calEntry = cal.add_event()13 elif type == 'anniversary':14 calEntry = cal.add_anniversary()15 elif type == 'todo':16 calEntry = cal.add_todo()17 else:18 raise faultType("SOAP-ENV:Server","
Creating calendar entry failed.","Unsuported type")
19
20 if calEntry != None:21 if content != None:22 calEntry.content = content23 if location != None and
location != "":24 calEntry.location =
location25 if end_time != None and
end_time != "":26 calEntry.set_time(
start_time,end_time)27 else:28 calEntry.set_time(
start_time)29 if alarm != None:30 calEntry.alarm = alarm
#float31 if priority != None:32 calEntry.priority =
priority #(1 = high,2 = normal, 3 = low
)33 else:34 calEntry.priority = 235 if type == 'todo':36 if crossed_out != None:
6.4 Implemented services 75
37 calEntry.crossed_out=crossed_out# ( TRUE ||FALSE )
38 else:39 calEntry.
crossed_out= False
40 if replication != None:41 calEntry.replication =
replication # open,private, restricted
42 else:43 calEntry.replication =
'private'44
45 calEntry.commit()46
47 itemOut = {}48 itemOut['id'] = calEntry.id49 itemOut['lastModified'] =
SOAPpy.dateTimeType(calEntry.last_modified)
50
51 return itemOut52 else:53 # Raise an exception54 raise faultType("SOAP-ENV:
Server","Creating calendarentry failed.","typeincorrect or missing")
55 except Exception, e:56 raise faultType("SOAP-ENV:Server","
Creating calendar entry failed.",e)
Listing 6.3 shows the full code for the getEntries operation, searching for anentry based on dates and a string. On lines 5-10 the input arguments areconverted to the appropriate values, DateTime variables to floats representingepoc seconds, and the search string to a unicode string. On line 13 the calen-dar database is opened and on line 16 a search on the database is performedwith the PyS60 API function find instances. Lines 18-22 loop through the re-sult and create an array of output entries created with createOutputItem .
createOutputItem actually creates a Python dictionary structure with the keynames and values corresponding to the XML Schema type definition.
Listing 6.3: Calendar Web service, getEntries Operation
1 def getEntries(self, start_date, end_date, search_str = '',resultFilter = ""):
2 # Get entries satisfying the search conditions3 try:
76 CHAPTER 6. MOBILE WEB SERVICES API DESCRIPTION
4 #convert start_date and end_date5 floatStart_date = self.__dateTimeToEpoc__(
start_date)6 floatEnd_date = self.__dateTimeToEpoc__(
end_date)7
8 # convert the search string to unicode9 search_str = unicode(search_str)
10
11 # Open the calendar database12 cal = calendar.open()13
14 #execute the search15 entriesList = cal.find_instances(
floatStart_date, floatEnd_date, search_str)16
17 output = []18 for n in range(0, len(entriesList)):19 entryObject = cal[entriesList[n]['id']]20 itemOut = self.
__createOutputItem__(entryObject, resultFilter)
21 output.append(itemOut)22
23 return output24 except Exception, e:25 raise faultType("SOAP-ENV:Server","getEntries
entries failed.",e)
Other methods are fundamentally similar to the two shown here in detail andthe same goes for other services as well. With the exception though the map-ping to and from different data types are required.
Management Service
The management service differs from most of the other services since it doesnot expose features from the PyS60 API. Instead, it exposes features that arespecified in the mwsManagement class. Publishing those features as servicesis meant to ease management of services, users and their policies. Allowingexternal parties to request a user account, access to a service and possibly in-stalling a missing service, takes management burden of the device owner. Itis thus likely that the device owner would like to allow access to those oper-ations, but be informed and take final decision on what is allowed. This isaccomplished by asking for user confirmation for each request.
The Management service class is defined in the same way as the CalendarMWSservice class in the last section. It imports neccessary modules and inheritsfrom mws.mwsAuthentication and mws.mwsGeneral. It specifies version infor-mation and author information in a variable. Then every published opera-tion is defined as a method of the class, every operation that should ask for
6.4 Implemented services 77
user consent, further needs a method to handle the UI part. That applies toinstallService, deleteService, updateService, createUser, deleteUser, grantUserAccess,deleteUserAccess, setServicePublic, setOperationPublic, setServicePrivate and setOp-erationPrivate. All of them have a corresponding installServiceUI, deleteServiceUIand so on.
The installService operation will now be explained in detail. The outline forthe two methods is shown in listing 6.4. The installService method checks if theservice that is about to be installed is already installed on the device. If not, ituses the launchExternalThreadObject to launch the installServiceUI method. TheinstallService method takes in location, service, classname and receiptRequestas arguments. The location can be any Web URL with two sub directories mod-ules, containing a file classname.py, and wsdl, containing a file service.wsdl. TheinstallServiceUI method prompts the user if he wishes to install the service, withinformation about the location, service name, classname and requesting user.If the user provides a valid username token in the request, his username will bedisplayed. If the user allows the service install, the service class file and WSDLfile are fetched from the location, read into two file objects and passed to theinstallservices method of mwsManager. Finally the service reports back to thecaller using the information in the argument receiptRequest. receiptRequest spec-ifies a location for a Web service getUserConfirmation that takes in a string and acorrelation value. The string indicates the result of the operation and the corre-lation value can be used to identify the request, for example with a unique id.The caller needs to implement and publish this service at his end3. The ParlayX API handles call back functions in a similar way as described here.
Listing 6.4: Management Web service, installService Operation
1 def installService(self, location, service, classname,receiptRequest):
2 import ...3 ...4
5 # Check if service is installed6 ...7 if serviceInstalled == False:8
9 leto = mws.launchExternalThreadObject()10 leto.setModule("Management")11 leto.setObject("Management")12 leto.setFunction("installServiceUI")13
14 leto.addParameter("location",location)15 leto.addParameter("service",service)16 leto.addParameter("classname", classname)17 leto.addParameter("webservicehost", self.
getWebserviceHost())18 leto.addParameter("user", self.getUser())19 leto.addParameter("receiptRequest", receiptRequest)
3Such a test service has been implemented and is awailable at http://www.mobcal.com/mwstester/services/CallBackHandlerSOAP?wsdl and its output can be viewed herehttp://www.mobcal.com/mwstester/Index?wsMethod=viewCallBackResult
78 CHAPTER 6. MOBILE WEB SERVICES API DESCRIPTION
20
21 mws.launchExternalThread(leto)22
23 return "Request sent"24 else:25 return "Service or class already installed"26
27 def installServiceUI(self, location, service, classname,webservicehost, user, receiptRequest):
28 import ...29 ...30
31 # Parse info about receipt location, call back32 endpoint = receiptRequest['endpoint']33 correlator = receiptRequest['correlator']34
35 # Ask if user wishes to install the service36 try:37 managerObj = mwsManager.mwsManager()38 if user != None and user != '':39 queryString = u'Incoming request from user: %s to
install service: %s in class: %s, from location:%s. Allow?' % (unicode(user), unicode(service),unicode(classname), unicode(location))
40 else:41 queryString = u'Incoming request to install service
: %s in class: %s, from location: %s. Allow?' %(unicode(service), unicode(classname), unicode(location))
42
43 result = appuifw.query(queryString, 'query')44
45 if (result == True):46 # Fetch files from server47 ...48 # Move files from the temp location to the actual
location49 ...50
51 managerObj.installservices(sourcefile, wsdlfile,webservicehost)
52 appuifw.note(u'Service installed, restart webserver for the changes to take effect.', 'info')
53
54 # Send success to caller55 receiptServer = SOAPpy.SOAPProxy(endpoint)56 receiptServer.getUserConfirmationResult("success",
correlator)57 else:58 ...59 except Exception, e:60 ...61 sys.exit()
6.5 Future directions 79
Of course users should not install services from untrusted locations, but how tomake the location trusted is omitted by now. Ideally the service location shouldbe managed by a trusted entity like the gateway provider, requesters couldthen use a service repository of the device owner gateways when requestinginstall of a new Web service. Further, the service location could have somekind of rating mechanism where users could rate services. Users would bemore likely to trust and install a service rated positively by many users. ASOAP message to initiate a service install request is shown in Appendix C.
Other operations in the management service work in a similar way and are thusnot detailed. The Management service shows how the user can be promptedbefore a service is executed. Here, that has been implemented on an operationby operation basis but this could be extended as an available authenticationmethod, provided by the mwsAuthentication class. When an operation wouldbe configured for user confirmation, mwsAuthentication would use launchEx-ternalThreadObject to launch a dedicated method to get user consent, passingit all information of the original request. The method would display a dialogbox requesting the confirmation, upon receiving confirmation, the original in-tended method would be executed. The result from the operation would bereturned back to the method of mwsAuthentication that queried the user, andfrom there, would have to be returned back to the initial caller. This could bedone through a call back service as above, if mwsAuthentication terminated theoriginal thread. Additionally mwsAuthentication could be implemented to letthe initial thread wait for the response and then return the result back. Com-munication between the two threads could happen through a file, database oreven an internal socket. If the original thread would be terminated, the re-quester would have to provide a receiptRequest variable when calling serviceswhich require user approval.
Test application
A simple test application for the implemented services has been created and isavailable from http://www.mobcal.com/mwstester/. On the site a ser-vice and operation can be chosen and a request sent to a service on a devicethrough a form on the site.
6.5 Future directions
This area is probably the one that needs most work and collaboration in thefield of mobile hosted Web services. The definite goal would be to have aninteroperable standard representation interface, supported by various devicemodels. That can only be achieved through open common standardizationwith representatives from all parties involved.
Of current active standardization bodies, no one seems fully optimal to take upthe standardization. Although the Parlay X specification as described above
80 CHAPTER 6. MOBILE WEB SERVICES API DESCRIPTION
partly covers a similar area, it has been developed from a different perspective.Device manufactures are currently not members of the Parlay X group andthat would have to be considered a major drawback [6]. On the positive sideParlay X currently describes an interface to IT application developers, many ofwhom are likely to also be users of mobile device hosted services, a commonor interoperable interface would therefore be beneficial.
Further a possible scenario is that the gateway or a similar entity would beprovided by operators. The gateway could then act as a Web service proxy,forwarding requests to the appropriate entities at each time, network hostedservices or device hosted services. Depending on the context, an incomingWeb service request would be forwarded to the most appropriate source ateach time. In that case, interoperability would be of great importance, enablingthe proxy to easily convert between the data types as needed.
The Open Mobile Alliance (OMA) is another standardization body suited totake on standardization of mobile hosted Web services. Members of OMAspan the whole mobile value chain and include operators, device and networkmanufacturers and IT companies. Its goal is to be a central point, hosting stan-dardization within the mobile domain.
Chapter 7
Extending the Gateway
Previous chapters have demonstrated how to serve Web services from the mo-bile device, only using the gateway to provide addressability and handle theconnection to the device. That is of course not very efficient in the unreliable,slow and expensive mobile network. A much more efficient scheme would beto handle as much as possible on the gateway server side and limit the numberof requests to the device as much as possible. That would though need to bedone without compromising the interoperability or the feeling that the inter-action is with the device itself. This chapter presents an architecture of howresponsibility could be shifted to the gateway serving side, without compro-mising usability and interoperability. The architecture is described at a highlevel, identifying entities, their tasks and interfaces between them. Implemen-tation details are left out remaining as further work.
7.1 Server responsibilities
First it is necessary to define the responsibilities that could be better tackledat the serving / gateway end. One such task is to manage a cache that canbe served from the gateway server without requesting the actual device. Thecurrent gateway provides caching for static content, since serving static contentfrom a mobile device is not that interesting, its usefulness is limited. It does noteven seem to work for media files which in their nature are static. Consequentrequests to an image file stored in the device htdocs folder resulted in the imagebeing downloaded from the device each time. With Web services, since thegateway can interpret ongoing transactions to and from the mobile, a moreusable caching mechanism can be implemented.
Chapter 5 pointed out limitations of the mobile device to handle sophisticatedsecurity mechanisms using encryption and digital signatures. Further, it wouldbe more economical if unauthorized requests would not have to be processed atthe mobile device. Assuming that the gateway is operated in a secure domain
82 CHAPTER 7. EXTENDING THE GATEWAY
and by a trusted party, like a mobile operator, authentication and validation ofthe content could be performed at the gateway and then delivered to the clientover the secure transport level connection.
Serving interface descriptions, WSDLs, for the device could easily be done atthe gateway and would be more appropriate.
Since not all Web services are necessarily installed on the device, a centralizedservice repository could install missing Web services when needed. In case thegateway would notice a request for a service that is not installed on the device,it could do a service install request before requesting the intended service. Ifthe user chooses to install the service the original request would then be madeafter the install process finishes. If the central service repository does not havethe requested service, the requester would be notified, without invoking themobile device.
7.2 Architecture
The extension of the gateway can be done in a SOA manner by defining sev-eral service components and the interfaces between them. Even though this isreferred to as a single entity, it would be composed of multiple services not nec-essarily operated within the same network. The original gateway that managesthe connection to the device would simply be one component. Such a schemewould increase flexibility, management and scalability of the solution. To ac-complish this few entities are defined and described as:
• Client
The client of the system is as before a consumer of Web services mak-ing requests to the public URL of the device, for example https://username.mymobilesite.net.
• Connection Gateway
The Connection Gateway is responsible for managing the connection tothe mobile device and in principal functions like the present gatewaywith the exception that within it, a new entity Proxy has been defined.
• Proxy
The Proxy resides within the Connection Gateway and all requests gothrough it. It performs tasks depending on the context of the request. Ifthe request is a regular HTTP request, nothing is done and the request issimply forwarded to the Mobile Device. If the request is a SOAP requestor a request for a WSDL the Proxy takes specific actions.
• Security Service
The Security Service is responsible for authentication, authorization, val-idation and data encryption/decryption. The Security Service is able to
7.2 Architecture 83
take full advantage of standard security implementations such as sup-port for X.509 certificates. It should be able to process messages withWS-Security headers and issue SAML assertions to its clients and exposethe WS-Trust and/or SAML Protocol interfaces. The security service getspolicy informations for each service in question from the Profile ServiceWS-Policy interface.
• Cache Service
The Cache Service is responsible for maintaining a cache of the data. Ev-ery request through the Proxy is also sent to the Cache Service, the CacheService thus implements the same interface as the Mobile Device itselfand maintains the cache.
• Profile Service
The profile service is responsible for maintaining information about theuser profile, that includes general settings like how caching should beperformed, registration information about the users, maintaining a list ofinstalled services on each device and policy information for the services.Additionally the Profile Service should maintain information about au-thorized users for each service and how they should be authenticated.
• WSDL Server
Serves WSDL descriptions for the user based on information about in-stalled services and their security settings from the Profile service.
• Service repository
Maintains a list of services, information about their interfaces and possi-bly their code for some or all platforms.
• Mobile device
As before the mobile device runs the Mobile Web Server and serves Webservices. The mobile device treats the connection with the ConnectionGateway as trusted. Requests that require authentication and come throughthat connection can be treated as authenticated and trusted. If the mobiledevice receives a request that requires authentication and validation overa non-trusted connection, it can authenticate it with its own resources ordeny it and inform the requester to go through the Connection Gateway.Which approach would be used would depend on a user setting. Ser-vice implementations on the mobile device that implement changes tothe information stored in the Profile Service are responsible for publish-ing changes made to the Profile Service. Additionally the Profile Serviceshould regularly sync itself to the device settings.
Use case: Caching
When receiving a SOAP request the Proxy checks if the request is a data re-trieval or an update request. If it is a data retrieval request, it forwards it to the
84 CHAPTER 7. EXTENDING THE GATEWAY
Cache Service that consults the Profile Service for user Cache settings. Depend-ing on users cache settings and the current available cache, the Cache servicedecides whether to serve the cache or send the request to the mobile device.If the cache is to be served it simply returns its cache to the Proxy. Otherwisethe Proxy forwards the request to the mobile device and then updates the cachewith the response received. The sequence diagram in 7.1 illustrates the process.If the incoming request is a data manipulation or security settings change, the
Figure 7.1: Maintaining and serving cache
Proxy forwards the request directly to the mobile device and then sends anupdate to the cache if the request was successful.
The client should be able to influence the cache decision through a SOAP header,stating how time sensitive the request is, or order that no cache should be used.Through a SOAP header in the response the client could be noticed whether heis receiving a cache or not. Further, the client could initially be sent back a cacheand notified through the response header when to submit the request again, inthe meantime the information would be requested from the mobile device andthe cache updated.
7.2 Architecture 85
Use case: Security service
When receiving a SOAP request the Proxy fetches the service policy from theProfile Service. If authentication is required the request is forwarded to theSecurity Service. The Security Service authenticates the request based on theinformation in the request and notifies the Proxy. If the authentication is suc-cessful the Proxy then forwards the request to the mobile device. If authenti-cation failed a fault is returned to the client. Similarly, if the request requiresdecryption or the response requires encryption, the Proxy forwards the mes-sages to the Security Service.
Use case: Serve WSDL
By hosting a copy of WSDL files for installed services of clients, the gatewaycan serve WSDL requests without sending the request to the mobile device.Upon receiving a WSDL request the Proxy forwards the request to the WSDLService. The WSDL Service consults the Profile Service for information aboutinstalled services on the mobile device and security policies. It then fetches theWSDL description for the service/services from the Service Repository Service,constructs the WSDL, and returns it to the Proxy. The sequence diagram 7.2illustrates the process.
Figure 7.2: Serving WSDL files
Use case: Install missing services
When receiving a SOAP request the Proxy can check the Profile Service whetherthe requested service is installed on the mobile device or not. If installed, the
86 CHAPTER 7. EXTENDING THE GATEWAY
request is simply forwarded, but if not, the Proxy can send a request to the Ser-vice Repository Service to install the requested service on the mobile device.If the Service Repository Service has an implementation of the requested ser-vice it sends an installation request to the device. After a successful install theService Repository Service notifies the Proxy service which then forwards therequest.
Overview
The above use cases indicate that for each SOAP request the Proxy requiresinformation about whether the mobile device has the service installed and itspolicy from the Profile Service. Both could be acquired in a single request to theProfile Service. Further, the Proxy might need to consult the Cache Service andthe Security Service. Those services could be invoked asynchronously and thenallowed to proceed if successfully authenticated. An overview of the completearchitecture is presented in figure 7.3.
Figure 7.3: Overall gateway architecture
Chapter 8
A case study: mobCal
8.1 Introduction
A case study application was developed during the course of the project. Thepurpose of the case study application was twofold; first show and demonstratethe usage of mobile hosted Web Services and secondly help form the require-ments for mobile hosted Web services and the framework. Work on the demoapplication began after SOAPpy had been ported to the mobile device and fewbasic Web services been created.
8.2 Application description
MobCal is a calendar service extending the calendar of the mobile device. Theapplication uses the Web service framework on the device to access the devicecalendar. The application is a Web based system having a public front end, lo-cated at http://www.mobcal.com. Calendar entries of users are displayedafter logging into the system with a username and password. There, userssee their calendar entries fetched from the mobile device. New entries can becreated and existing ones deleted or updated. Users can also choose to havetheir calendar entries synchronized with their Google calendar. When savingcalendar entries on the device they can be marked as either public or private.Entries that are marked as public will be displayed on the Web site and on theusers profile. Through a form on the Web site visitors can request a meetingwith the user, the system checks if the user is available, and if so, prompts himwith a meeting request. This is a use case that demonstrates well the poten-tials of mobile hosted Web services and would be difficult and cumbersome toimplement by other means.
All interaction with the device take place through the Web service interfacepublished in the Web service framework on the device, already explained.
88 CHAPTER 8. A CASE STUDY: MOBCAL
Implemented User stories
To summarize the above discussion the following user stories have been im-plemented at this point in time.
• Users should be able to login
• Show calendar entries for the user
• Manage calendar entries (insert new, delete existing, update existing)
• Synchronize with another calendar application (Google calendar)
• Allow site visitors to see publicly available calendar entries of users
• Allow people to request a meeting with the user
8.3 Design
Overview
The application is divided into three entities: Firstly, The Web based user inter-face encoded in XHTML, CSS and JavaScript. Secondly, controllers that controlthe execution flow of the application. Finally, classes that the controllers use todeliver the desired functionality. The classes wrap implementation of interact-ing with external entities like the mobile device, the Google calendar and thedatabase and provide the controllers with methods like synchronize, createEntry,deleteEntry, fetchMonth and getCalendarEntry.
Database
In its database the system stores information about installed users, their set-tings, access information to the mobile Web services and their Google Calendar.In the database calendar entries that have been fetched from the user device arestored along with information used in the synchronization process. It links to-gether ids of the calendar entries stored in the database, on the mobile deviceand in the Google calendar.
Interactions
Notice that all interaction requires the mobile Web service framework to be setup on a device and the mobile Web server running. Screen shots of the systemare available in Appendix E.2.
8.3 Design 89
Login
When on the front page, users can login with a username and password througha form on the left side of the page. In case not having an account, one can becreated through the Register link. Once logged in, the users calendar entries aredisplayed in the main area of the site. By navigating a calendar module on theleft side, the user can change the view on what entries are displayed. Initiallythe system displays cached entries already stored in the database but also ini-tiates a fetch for new entries from the device. When they have been fetchedthe view is automatically updated. By clicking on the title of an entry, detailedinformation about the entry can be viewed.
Create Entry
By clicking the Add new entry link in the main content area, a form opens thatcan be used to create a new entry. Clicking Save saves the new entry to thedevice.
Update Entry
By clicking on the Update link beside an entry, the entrys details are opened ina form and its information can be changed.
Delete Entry
Clicking the Delete link beside an entry deletes the entry.
Change settings
By clicking the Settings link on the left side on the site, settings like mobile WebServer URL, username/password for mobile authentication, username/pass-word for Google authentication and whether the application should automati-cally synchronize entries, can be changed.
Request meeting
On the bottom of the left side of the page, under the title Users profile the profileof a user can be selected. The corresponding profile will open in the mainarea of the site showing public calendar entries of the user and also the formRequest meeting with USERNAME. There, a form including Subject, Location,Start time, End time, Your name and Your mobile number can be filled out to
90 CHAPTER 8. A CASE STUDY: MOBCAL
send a meeting request to the user. The activity diagram in figure 8.1 showsthe interactions when a site visitor requests a meeting with a user.
Figure 8.1: Send meeting request to user, interaction
• Site visitor sends a meeting request with subject, location, start time, endtime, name and his mobile number
• RequestMeeting controller checks if user is synchronized to the database
– If synchronized to the database it checks if there are any items in therequested time slot
* If there are no entries in the database at the same time the cal-endar on the mobile device is checked next
· If the calendar on the mobile device also has no entries thedevice owner is prompted with the meeting request
· If the user acknowledges the meeting the entry is created inthe calendar on the mobile device
· The site visitor is notified that the meeting has been acceptedand created
· If the calendar on the mobile has an entry on the same timean error message is sent back: Not available at this time, pleasechoose another time
* If the user has an entry on the same time in the database anerror message is sent back: Not available at this time, please chooseanother time
– If not synchronized to the database check the mobile device calendardirectly
* If the calendar on the mobile device also has no entries the de-vice owner is prompted with the meeting request
8.3 Design 91
· If the user acknowledges the meeting the entry is created inthe calendar on the mobile device
· The site visitor is notified that the meeting has been acceptedand created
* If the calendar on the mobile has an entry on the same time anerror message is sent back: Not available at this time, please chooseanother time
If communication with the device fail at any time the request is saved to databaseso that it can be replayed and the site visitor is notified that the device is un-reachable, that the request will be retried later and he notified through SMS. Atthis point in time the sending of the SMS message has not been implementedyet, that could though be done by simply using the sendSMS operation of theSMSmessage service on the users mobile device. A similar form using the sys-tem could be created and copy/pasted on a users personal website, submittingrequests to the system.
Synchronization
If set to synchronize entries, synchronization happens automatically once anhour. The Mobile device and the Google calendar are each defined as an ori-gin for database entries. Then depending on user settings each origin is syn-chronized to the mobCal database. The synchronization works on a month bymonth basis, synchronizing the current month. The synchronization processbetween each origin and the database is as follows:
• Fetch all calendar entries ids and last modified times from the origin,within this month
• Fetch all calendar entries ids and last modified times from the database,within this month
• Go through all entries from the origin and verify that they are in thedatabase
– If the entry is found in the database
* Compare last modified dates· If equal do nothing· If newer in the database update the origin, get the new last
modified timestamp from the origin and save it in the database· If newer in the origin fetch the full entry from the origin and
update the database
– If the entry is not found in the database
* Check if it has been marked as deleted in the database, if sodelete the entry from the origin. If it is not marked as delete indatabase fetch the full entry details from the origin and create itin the database
92 CHAPTER 8. A CASE STUDY: MOBCAL
• Entries that are missing in the origin, but are in the database, should bemarked as deleted in the database. This is because they have been deletedfrom the device.
• If entries are in the database, but not in the origin and have not beenmarked as deleted in the database they should be created in the origin.
8.4 Implementation
The application has been implemented as a Java EE Web application developedand tested on an Apache Tomcat 6.0 container. MySQL 5 has been used as theunderlying database and the Axis Web service framework1, has been used foraccessing the mobile Web services. All development has been conducted usingthe Eclipse IDE.
The user interface is based on JSP/JSTL pages generating the XHTML code andJavaScript code. Servlets are used to implement the controllers and drive themain logic of the application. Information about the logged in user is stored ina userData class and made available to the JSP pages and Servlets as a sessionbean. Database Connection Pool (DBCP) is used to set up, maintain and makeconnections to the underlying database available. A DatabaseHelper class isused to implement common needed database functionality such as getting adatabase object from the pool.
The interesting part of the implementation is in a packet named calendar, whichwraps all functionality used to manage the calendar information. There arethree sources of calendar entries in the system, the mobile device, the Googlecalendar and the systems own database. The calendar packet defines classesimplementing management of all the the sources and a main class implement-ing a unified interface to all the sources. Its classes are:
• Commons.java: Implements routines needed by the other classes withinthe packet
• DatabaseCalendarManager.java: Implements management of the calen-dar entries stored in the database
• GoogleCalendarManager.java: Implements management of entries storedin the Google calendar
• MobileDeviceCalendarManager.java: Implements management of entriesstored on the mobile device
• GeneralCalendarEntryType.java: An object to contain calendar entries
• CalendarManager.java: Provides a unified implementation to the otherclasses easily usable by the controllers to provide the desired functional-ity. It provides methods such as addEntry, deleteEntry, fetchDay, getCalen-darEntries and synchronizeMonth.
1http://ws.apache.org/axis/
8.5 Future directions 93
Apache Axis 1.4 is used to request the mobile hosted Web services through pregenerated stubs from the WSDL interface. For communication with the GoogleCalendar, the Java client library of Google Data APIs Client Libraries2 is used.
8.5 Future directions
Obviously mobCal is still in its infancy, the project time only made room forimplementing few of the possible use cases. Consequently, many interestinguse cases are left for future work. Here are listed some possible features thatcan be a starting point for future implementation on the project.
• Map calendar entries to location: Associating a calendar entry with alocation creates metadata information about the entry that can be usedto realize more user stories. The calendar interface on the device has alocation field that can be filled out. The system could use the contentof that field as the input into a geological search query on a service likemaps.google.com, in order to map it into an actual location. Through theinterface users could define the location of an event and define locationsfor ambiguous entries like Home and Work.
• Get directions to a meeting: When able to map a location string into anactual location, the location information can be used to replace the stan-dard alarm with an alarm with directions to the location.
• Flexible alarm time: Depending on location, the alarm time could be var-ied and calculated by the system.
• Link different users together: Linking different users together providesanother set of usable metadata to implement new services. Linking theusers together can happen through use of the system, for example byquerying the address book or some social network service. Of course alllinking must be done with users consent.
• Organize meetings: A meeting usually has many participants. Whenplanning a meeting, the owner of an entry could invite other users tojoin the meeting. Invited users would get a confirmation request theycould accept. Users could also opt into a meeting, leading to the ownergetting a confirmation request.
• Send change request notifications to meeting participants: If a partici-pant in a meeting would like to change the meeting time he could simplydo so in the calendar application on his device. The system noticing thechanged time entry would consult the calendar entries of other partici-pants and in a case of a collision report it back to the changer, possiblywith a suitable suggested time. In case of no collision other users wouldbe sent a changed meeting time request and if successfully accepted byeveryone the meeting times would be changed automatically.
2Available from http://code.google.com/p/gdata-java-client/downloads/list
94 CHAPTER 8. A CASE STUDY: MOBCAL
• Notify delays: In combination with the location information above, par-ticipants in a meeting could receive notifications in case a participant isrunning late with an estimated arrival time.
• Suggest meeting: Through the public / private tag on entries, users couldcreate meeting suggestions that would replicate to their friends. Userscould choose to subscribe to other users public entries, have them repli-cate to their device or get notifications. They could then even opt into aspecific entry.
• Archive media files: Information from the calendar could be used to tagmetadata to media files on the mobile device. Calendar entries definemetadata such as time and can be used to archive media files. As an ex-ample of that is displaying images taken and recordings made in a meet-ing, on the web site.
As shown, there are possibilities in creating new use cases and services for thestandard calendar application, which is available on every mobile device today.It can be done without any modifications or programming on the device, giventhat the device is publishing the appropriate set of Web services.
Chapter 9
Conclusion and further work
As has been demonstrated, providing HTTP connectivity to a mobile deviceopens new ways in interacting with the device and enables new use cases. Inthe report, use cases relating to the calendar of the mobile device have beenderived. The focus has been on the calendar since it is personal, present inevery device and its use is commonly understood.
Using Web services allows publishing functionality in a more structured andcontrollable manner. Further it enhances reuse of services, reducing the im-plementation needed for applications. Web services also help utilizing thecommunication channel in a more efficient way. Only fetching the requiredinformation from the device instead of a full web page including markup in-formation. Binary serialization of the XML data can also be used to reduce theamount of transmitted data. Further, by introducing a proxy in the messagepath data can more efficiently be cached and the number of requests to thedevice limited.
In the project, a framework for publishing and managing Web services is sug-gested. This framework has been successfully implemented on a commercialmobile device. The framework makes it easy to publish normal Python classesas services and works well with established Web services standards. It hasbeen shown that the added processing needed to handle service management,user management and validation of users, does not significantly impact theresponse time for the Web services. Even despite the fact that it has been im-plemented in Python, an interpreted language. A native C++ implementationshould press the processing speed further down, bringing it close to the limi-tations of the wireless link.
Whether or not, mobile hosted Web services will succeed and propose any sig-nificant change in the mobile domain, in my opinion, depends upon two fac-tors.
First of all, it depends on the uptake of a solution providing HTTP connectivityto the devices. That is whether it will become common and natural for a mo-
96 CHAPTER 9. CONCLUSION AND FURTHER WORK
bile device to be addressable in this manner. As discussed in the first chapter,todays mobile networks are optimized for out-bound traffic. That proposes athread to operators willingness for a large scale uptake of such a solution. To-day operators have direct contact with customers and have a lot of influenceon the market and on the uptake of new solutions. Technologies like HSPA En-hanced Uplink, promising up to 5.8 Mbps on the uplink, should help makingnetworks being optimized further for uplink access, and limit this thread. An-other influencing factor on the uptake of HTTP addressing is of course pricingon data usage. Todays rates are too high to stimulate such usage. That how-ever, seems to be changing with flat rate data subscriptions being introduced.
Secondly for Web services to truly become beneficial and usable, depends onthe industry capability to standardize the usage of Web services. Thus makingthem easily available and reducing the amount of Web services needed to bedeveloped and maintained for each application. Most Web service interfacesin use to day seem to be based on an application specific interface. This is dueto the fact that Web services are usually published by a central entity and usedby multiple clients, where clients are implemented to utilize the interface ofthe service. Automatically searching for new service providers and bindingto them, for example through a public UDDI discovery service, seemingly hasnot prevailed. This is supported by the fact that in 2006 IBM, Microsoft andSAP announced that they were closing their public UDDI nodes. Today UDDIis mostly used within organizations to maintain services and publish them topartners. Whether this will be any different for mobile hosted Web servicesremains to be seen. It is though necessary to bear in mind that standardizationis at the heart of the telecommunication and mobile industry. Various aspectsof the mobile devices are already standardized and capable standardizationbodies like the Open Mobile Alliance (OMA), European TelecommunicationStandards Institute (ETSI) and the 3rd Generation Partnership Project (3GPP)are already in place. It thus might not be fair to compare the standardizationcapabilities of the mobile industry with other industries that do not thrive onsuch common standardization. The effect of those standardization bodies isalready demonstrated with the presence of the previously introduced Parlay XWeb service standard.
The current framework has implemented a SOAP messaging interface, serializ-ing XML in the normal textual angle bracket form. It could be further extendedto support binary XML serialization. In order to do so the SOAP parser andbuilder would have to be modified to support the binary XML serialization.The framework can also be extended with new interfaces, JSON serializationhas been mentioned as an example. This could even be taken a step furtherto an interface making functionality available through a browser plug-in. Thishints at a common service engine on the mobile device, providing access to de-vice functionality. The service engine whould be accessible through multipleinterfaces, one being Web services communicating through SOAP messaging.
This should enable development of applications for mobile devices that wouldhave access to device functionality through a consistent set of services accessi-ble in a practical way for each scenario. The server based application controllerwould request Web services through SOAP messaging. The server based con-
97
troller delivers its interface in the form of XHTML/JavaScript/CSS to its clientsthat either reside on a personal computer or on the mobile device itself. Theinterface makes request back to the server controller, but additionally can alsohave access to device functionality through JavaScript calls. Based either onJSON services, if the interface is loaded on a remote client such as laptop, oron a browser plug-in calls, if the interface is loaded on the target device itself.This would enable creating truly interoperable and independent of access Webapplications to for the mobile medium.
The mobile industry has proven that it is capable and willing to come togetherin open standardization to help new technologies and services to prevail. Be-cause of those conditions such a service framework and a standard service in-terface seems more like a logical next step rather than drastically new direction.
Appendix A
Mobile Web Service Interface
Table A.1: Mobile Web Services Interface
PresenceServices OperationsAvailability getAvailabilityDeviceStateInfo getDeviceState
setVolumesetLocalTime
SystemInfo getSystemInfogetMemoryInformation
TerminalLocation getLocationgetTerminalDistancegetGSMLocationgetGPSLocation
TerminalLocationNotificationManager startGeographicalNotificationstartPeriodicNotificationendNotification
Device UtilitiesServices OperationsCamera getInformation
takePhotoPlayAudio playTextMessage
playAudioMessageplayVoiceXmlMessage
SMSMessaging sendSMSsendSmsLogosendSmsRingTonegetSmsDeliveryStatus
SMSNotificationManager startSmsNotificationstopSmsNotification
MMSMessaging sendMessage
99
getMessageDeliveryStatusMMSNotificationManager startMessageNotification
stopMessageNotificationTelephone dialNumber
hangUpanswerIncomingCall
TelephoneNotificationManager startCallStateNotificationendCallStateNotificationgetActiveCallStateNotifications
Data ManagementServices OperationsContacts getContacts
insertContactupdateContactdeleteContactgetContactsfindContactsimportVCardcreateGroupdeleteGroupgetGroupsmoveToGroup
Calendar getEntriesInMonthgetEntriesAtDayinsertEntryupdateEntrydeleteEntrygetEntryinsertVCalendargetEntries
Logs getRawLogDatagetSMSsgetCallsgetFaxesgetDatagetEmailsgetLogDatagetScheduler
100 APPENDIX A. MOBILE WEB SERVICE INTERFACE
Mobile Web Service FrameworkServices OperationsGeneral restartServer
displayMessagegetUserConfirmationlaunchApplication
Management installServicedeleteServiceupdateServicecreateUserdeleteUsergrantUserAccessdeleteUserAccesschangePasswordcheckIfUserExistsgetServicePolicysetServicePublicsetOperationPublicsetServicePrivatesetOperationPrivategetUsersgetInstalledServices
Appendix B
WSDL Interface
commons.xsd
Variable Element name Type MultiplicityDeliveryInformation
address anyURI [1..1]deliveryStatus deliveryStatus [1..1]
SimpleReferenceendpoint anyURI [1..1]interfaceName string [1..1]correlator string [1..1]
TimeMetricmetric metricType [1..1]units init [1..1]
Table B.1: Complex types
102 APPENDIX B. WSDL INTERFACE
Variable Enumeration valuedeliveryStatus DeliverdToNetwork
DeliveryUncertainDeliveryImpossibleMessageWaitingDeliveredToTerminalDeliveryNotificationsNotSupported
metricType MillisecondsSecondsMinuteHourDayWeekMonthYear
Table B.2: Simple types
103
Availability.wsdl
Direction Element Type MultiplicitygetAvailability: Information about the availability of the device ownerinput resultFilter string [0..1]output Profile ProfileType [0..1]
CalendarAvailability boolean [0..1]ReservedForSec int [0..1]
Table B.3: Availability portType
Variable Enumeration valueProfileType general
silentmeetingoutdoorpagerofflinedrivecustom
Table B.4: Types
104 APPENDIX B. WSDL INTERFACE
Camera.wsdl
Direction Element Type MultiplicitygetInformation: Retrieves information about device camerasinput resultFilter string [0..1]output camerasAvailable cameras availableType [0..*]
imageModes imagesModes [0..1]imageSizes imageSizesType [0..*]flashModes flashMode [0..*]maxZoom int [0..1]exposureModes string [0..*]whiteBalanceModes string [0..*]
takePhone: Takes a photo with a camera on the deviceinput mode imageModes [1..1]
size imageSizesType [1..1]flash flashMode [1..1]zoom int [1..1]exposure string [1..1]whiteBalance string [1..1]position int [1..1]
output out anyURI [1..1]
Table B.5: Camera portType
Variable Enumeration valuecameras availableType generalimageModes RGB12
RGBJPEG ExifJPEG JFIFRGB16
imageSizeType 1280x960640x480160x120
Table B.6: Simple types
105
Variable Element name Typecameras availableType
id intdescription string
imageSizeTypewidth intheight int
Table B.7: Complex types
106 APPENDIX B. WSDL INTERFACE
Contacts.wsdl
Direction Element Type MultiplicitygetContact: Retrieves a contactinput id int [1..1]
resultFilter string [0..1]output out contactDetails [0..1]insertContact: Creates a contactinput contactDetails contactDetails [1..1]output id int [1..1]updateContact: Updates a contactinput contactDetails contactDetails [1..1]output out string [1..1]deleteContact: Deletes a contactinput id int [1..1]output out string [1..1]getContactsinput resultFilter string [1..1]output out contactDetails [0..*]findContactinput searchTerm string [1..1]
resultFilter string [1..1]output out contactDetails [0..*]importVCardsinput vcards string [1..1]output out string [1..1]createGroupinput name string [1..1]output out string [1..1]deleteGroupinput id int [1..1]output out string [1..1]moveToGroupinput contactId int [0..1]
contactName string [0..1]groupId int [0..1]groupName string [0..1]
output out string [1..1]
Table B.8: Contacts portType
107
Variable Element name Type MultiplicitycontactDetails
city string [0..1]companyName string [0..1]country string [0..1]date dateTime [0..1]dtmfString string [0..1]emailAddress string [0..1]extendedAddress string [0..1]faxNumber string [0..1]firstName string [0..1]jobTitle string [0..1]lastName string [0..1]mobileNumber string [0..1]note string [0..1]pagerNumber string [0..1]phoneNumber string [0..1]poBox string [0..1]postalAddress string [0..1]postalCode string [0..1]state string [0..1]streetAddress string [0..1]url anyURI [0..1]videoNumber string [0..1]wvid string [0..1]firstNameReading string [0..1]lastNameReading string [0..1]picture base64Binary [0..1]speedDial string [0..1]thumbnailImage base64Binary [0..1]voiceTag base64Binary [0..1]id int [0..1]synchronization string [0..1]asVCard string [0..1]title string [0..1]lastModified dateTime [0..1]
groupDetailsid int [0..1]name string [0..1]
Table B.9: Complex types
108 APPENDIX B. WSDL INTERFACE
DeviceStateInfo.wsdl
Direction Element Type MultiplicitygetDeviceStateinput resultFilter string [0..1]output battery level battery levelType [0..*]
localtime dateTime [0..1]connection type connection typeType [0..*]signal bars signal barsType [0..*]signal dbm int [0..1]audio volume int [0..*]max volume int [0..*]available networks available networksType [0..*]
setVolumeinput volume int [1..1]output out string [1..1]setLocalTimeinput time dateTime [1..1]output out string [1..1]
Table B.10: DeviceStateInfo portType
Variable Element name Type Multiplicityavailable networksType
name string [1..1]type connection typeType [1..1]
connection typeTypeconnection type string [0..1]
Table B.11: Complex types
109
General.wsdl
Direction Element Type MultiplicityrestartServerinput resultFilter string [0..1]output battery level battery levelType [0..*]
localtime dateTime [0..1]connection type connection typeType [0..*]signal bars signal barsType [0..*]signal dbm int [0..1]audio volume int [0..*]max volume int [0..*]available networks available networksType [0..*]
setVolumeinput volume int [1..1]output out string [1..1]setLocalTimeinput time dateTime [1..1]output out string [1..1]
Table B.12: General portType
110 APPENDIX B. WSDL INTERFACE
Logs.wsdl
111
Direction Element Type MultiplicitygetFaxesinput startLog int [0..1]
numOfLogs int [0..1]mode modeValues [0..1]resultFilter String [0..1]
output out logsType [0..*]getDatainput startLog int [0..1]
numOfLogs int [0..1]mode modeValues [0..1]resultFilter String [0..1]
output out logsType [0..*]getEmailsinput startLog int [0..1]
numOfLogs int [0..1]mode modeValues [0..1]resultFilter String [0..1]
output out logsType [0..*]getRawLogDatainput resultFilter String [0..1]output out logsType [0..*]getLogDatainput logType typeValues [0..1]
startLog int [0..1]numOfLogs int [0..1]mode modeValues [0..1]resultFilter String [0..1]
output out logsType [0..*]getSMSsinput startLog int [0..1]
numOfLogs int [0..1]mode modeValues [0..1]resultFilter String [0..1]
output out logsType [0..*]getCallsinput startLog int [0..1]
numOfLogs int [0..1]mode modeValues [0..1]resultFilter String [0..1]
output out logsType [0..*]getSchedulerinput startLog int [0..1]
numOfLogs int [0..1]mode modeValues [0..1]resultFilter String [0..1]
output out logsType [0..*]
Table B.13: Logs portType
112 APPENDIX B. WSDL INTERFACE
Variable Enumeration valuemodeValues in
outfetchedmissedin altout alt
Table B.14: Simple types
Variable Element name Type MultiplicitylogsType
number string [0..1]name string [0..1]description string [0..1]direction string [0..1]status string [0..1]subject string [0..1]id int [0..1]contact int [0..1]duration int [0..1]durationType int [0..1]flags int [0..1]link int [0..1]time dateTime [0..1]data string [0..1]
Table B.15: Complex types
113
Management.wsdl
114 APPENDIX B. WSDL INTERFACE
Direction Element Type MultiplicityinstallServiceinput location string [1..1]
service string [1..1]classname string [1..1]receiptRequest SimpleReference [1..1]
output out string [1..1]deleteServiceinput service string [1..1]output out string [1..1]updateServiceinput location string [1..1]
service string [1..1]classname string [1..1]receiptRequest SimpleReference [1..1]
output out string [0..*]deleteUserinput username string [1..1]output out string [1..1]grantUserAccessinput username string [1..1]
service string [1..1]operation string [1..1]
output out string [1..1]deleteUserAccessinput username string [1..1]
service string [1..1]operation string [0..1]
output out string [1..1]changePasswordinput newPassword string [1..1]output out string [1..1]checkIfUserExistsinput username string [1..1]output out boolean [1..1]checkIfUserExistsinput username string [1..1]output out boolean [1..1]checkIfUserExistsinput username string [1..1]output out boolean [1..1]checkIfUserExistsinput username string [1..1]output out boolean [1..1]
Table B.16: Management portType
115
MediaFiles.wsdl
Direction Element Type MultiplicitygetPictureinput startDate dateTime [0..1]
endDate dateTime [0..1]resultFilter string [0..1]
output out mediaFileType [0..*]deletePictureinput deviceFile string [1..1]output out string [1..1]getAudioFilesinput startDate dateTime [0..1]
endDate dateTime [0..1]resultFilter string [0..1]
output out mediaFileType [0..*]deleteAudioFilesinput deviceFile string [1..1]output out string [1..1]
Table B.17: MediaFiles portType
Variable Element name Type MultiplicitymediaFileType
file string [0..1]size string [0..1]lastModified dateTime [0..1]deviceFile string [0..1]
Table B.18: Complex types
116 APPENDIX B. WSDL INTERFACE
MMSMessaging
Direction Element Type MultiplicitysendMessageinput subject string
priority intrecicptRequest SimpleReference
output result stringrequestIdentifier string
getMessageDeliveryStatusinput requestIdentifier stringoutput result DeliveryInformation
Table B.19: MMSMessaging portType
117
MMSNotificationManager.wsdl
Direction Element Type MultiplicitystartMessageNotificationinput reference SimpleReference
criteria stringoutput correlator stringstopMessageNotificationinput correlator stringoutput result string
Table B.20: MMSNotificationManager portType
118 APPENDIX B. WSDL INTERFACE
PlayAudio.wsdl
Direction Element Type MultiplicityplayTextMessageinput text string
language stringoutput out stringplayAudioMessageinput audioUrl anyURIoutput out stringplayVoiceXmlMessageinput voiceXmlUri anyURIoutput out string
Table B.21: MMSNotificationManager portType
119
SMSMessaging.wsdl
Direction Element Type MultiplicitysendSmsinput message string
priority intrecicptRequest SimpleReference
output result DeliveryInformationrequestIdentifier string
sendSmsLogoinput image base64Binary
smsFormat smsFormatTypeoutput result DeliveryInformation
requestIdentifier stringsendSmsRingToneinput requestIdentifier stringoutput result DeliveryInformation
requestIdentifier stringgetSmsDeliveryStatusinput requestIdentifier stringoutput result DeliveryInformation
Table B.22: SMSMessaging portType
120 APPENDIX B. WSDL INTERFACE
SMSNotificationManager.wsdl
Direction Element Type MultiplicitystartSmsNotificationinput reference SimpleReference
criteria stringoutput correlator stringstopMessageNotificationinput correlator stringoutput result string
Table B.23: SMSNotificationManager portType
121
SystemInfo.wsdl
Direction Element Type MultiplicitygetSystemInfoinput inputFilter stringoutput os version string
sw version stringdisplay pixels display pixelsTypeimei imeiType
getMemoryInformationinput inputFilter stringoutput free drivespace free drivespace
max ramdrive sizetotal ram intfree ram inttotal rom int
Table B.24: SystemInfo portType
Variable Element name Type Multiplicitydisplay pixelsType
width intheight int
free drivespaceTypedrive stringfree space int
Table B.25: Complex types
122 APPENDIX B. WSDL INTERFACE
Telephone.wsdl
Direction Element Type MultiplicitydialNumberinput number anyURI
divertToSIPAddress anyURIoutput callReference stringhangUpinput callReference stringoutput result stringanswerIncomingCallinput divertToSIPAddress anyURIoutput callReference string
Table B.26: Telephone portType
123
TelephoneNotificationManager.wsdl
Direction Element Type MultiplicitystartCallStateNotificationinput reference SimpleReferenceoutput correlation stringendCallStateNotificationinput correlation stringoutput result stringgetActiveCallStateNotificationsinput correlation string
username stringoutput result callStateNotification [0..*]
Table B.27: TelephoneNotificationManager portType
Variable Element name Type MultiplicitycallStateNotification
username stringreference SampleReferencestate stateTypecorrelation string
Table B.28: Complex types
124 APPENDIX B. WSDL INTERFACE
Variable Enumeration valuestateType in
EStatusUnknownEStatusIdleEStatusDialingEStatusRingingEStatusAnsweringEStatusConnectingEStatusConnectedEStatusReconnectPendingEStatusDisconnectingEStatusHoldEStatusTransferringEStatusTransferAlerting
Table B.29: Simple types
125
TerminalLocation.wsdl
Direction Element Type MultiplicitygetLocationinput requestedAccuracy int [0..1]
acceptedAccuracy int [0..1]maximumAge int [0..1]tolerance toleranceType [0..1]
output out LocationInfo [1..1]getTerminalDistanceinput latitude float [1..1]
longitude float [1..1]output result int [1..1]getGSMLocationinputoutput out LocationInfo [0..*]getGPSLocationinputoutput result LocationInfo [1..1]
Table B.30: TerminalLocation portType
Variable Element name Type MultiplicityLocationInfo
latitude float [1..1]longitude float [1..1]altitude float [1..1]accuracy int [1..1]verticalAccuracy int [1..1]horizontalAccuracy int [1..1]timestamp dateTime [1..1]mcc int [1..1]lac int [1..1]cellid int [1..1]
Table B.31: Complex types
126 APPENDIX B. WSDL INTERFACE
TerminalLocationNotificationManager.wsdl
Direction Element Type MultiplicitystartGeographicNotificationRequestinput reference SimpleReference
latitude floatlongitude floatradius floattrackingAccuracy floatcriteria criteriaTypecheckImmediate booleanfrequency TimeMetricduration TimeMetriccount int
output out stringstartGeographicNotificationRequestinput reference SimpleReference
requestedAccuracy intfrequency TimeMetricduration TimeMetric
output out stringendNotificationinput correlator stringoutput result stringgetGSMLocationinputoutput out LocationInfo [0..*]getGPSLocationinputoutput result LocationInfo [1..1]
Table B.32: TerminalLocation portType
Appendix C
Install services
<soapenv:Envelopexmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:man="http://www.example.org/mobilewebservices/Management/"xmlns:com="http://www.example.org/common">
<soapenv:Header/><soapenv:Body>
<man:installService><location>http://mobilews.mobcal.com</location><service>Logs</service><classname>LogsMWS.py</classname><receiptRequest>
<com:endpoint>http://www.mobcal.com/mwstester/services/CallBackHandlerSOAP</com:endpoint><com:interfaceName></com:interfaceName><com:correlator>installservice0000</com:correlator>
</receiptRequest></man:installService>
</soapenv:Body></soapenv:Envelope>
Appendix D
Packing and Installing
D.1 Packing
For easy install and setup on a device all files can be packed into a .zip archivethat can be downloaded from the device Web browser and extracted to the ht-docs folder. Two archives have been created containing both the source andcompiled python files and another containing only the compiled files. Allfiles are stored within a directory named webservices that is preserved in thearchive, the following script compiles all files within the directory (requiresPython 2.2.2):
Listing D.1: Compile script
1 import compileall2 import re3
4 # Compile all in directory but skip SVN directory5 compileall.compile_dir('webservices', rx=re.compile('/[.]svn'),
force=1)
pyLaunch needs to be packed into a .sis file and installed as an application,ensymble1 is used to create the .sis packet with the following command linecommand:
ensymble.py py2sis --caps=NetworkServices pyLaunch.py pyLaunch.sis
By default ensymble signs the generated .sis file with a self signed certificate,a self signed certificate is sufficient for the most basic things like displayinga user interface. However if more capabilities are required, for example tosend response back, the NetworkServices capability is required. The .sis fileneeds to be signed with those capabilites. Then the self signed certificate can
1Available at http://www.nbl.fi/˜nbl928/ensymble.html
D.2 Installation 129
be removed with the command line instruction signsis -u pyLaunch.sisand can then be signed with a developer certificate through Symbian onlinesigning2.
D.2 Installation
1. Register your device with the Nokia Mobile Web Server gateway
Register for a mobile url like http://yourname.mymobilesite.netby filling out the form at https://secure.mymobilesite.net/register/
2. Download Nokia Mobile Web Server
The Nokia Mobile Web Server can be downloaded by pointing the devicebrowser to http://download.mymobilesite.net or by download-ing a .SIS file from https://secure.mymobilesite.net/download/.The .SIS file can then be transferred to the device through Nokia PC Suite.
3. Install Nokia Mobile Web Server
If the Mobile Web Server was downloaded through the device browser,accept the installation request when the download completes.
If .SIS file was downloaded through PC, use PC Suite to transfer it to thedevice. PC Suite will ask if the application should be installed, acceptthat request.
Simply follow the installation process, but note that the mobile Web serverhas to be installed to the c: drive, main memory, of the device for the Webservices to work.
4. Download Mobile Web Services distribution
The Mobile Web Services distribution can be downloaded from http://mobilews.mobcal.com/webservices_distro_source.zip, eitherby pointing the device browser to that location or by downloading it to aPC and then transfer it to the device with PC Suite.
5. Unpack Mobile Web Services distribution
If downloaded with the device browser, the device ZIP utility will openthe file automatically when the download finishes.
If the zip file was downloaded to a PC and then transferred to the devicewith PC Suite, PC Suite will display an information message on wherethe file was saved. Open the file by opening"Menu" -> "Tools" -> "File mgr."and navigate to the location of the file and open the file. It should openin the device ZIP utility.
Once the ZIP file is opened choose"Options" -> "Mark/Unmark" -> "Mark all".When all the files are marked choose "Option" -> "Extract".
2Available at https://www.symbiansigned.com/app/page/public/openSignedOnline.do
130 APPENDIX D. PACKING AND INSTALLING
You will then be asked where to extract the files, choose"Phone memory" -> "Web server" -> "htdocs" and press Select.The archive will then be unzipped into a folder webservices under the ht-docs folder.
6. Download pyLaunch.sis
In order for the mobile Web services to use GUI functionality and func-tionality beyond the capabilities assigned to the Mobile Web Server, thepyLaunch application has to be installed.
A self signed .sis can be downloaded from http://mobilews.mobcal.com/pyLaunch_selfsigned.sis and is sufficient to enable GUI func-tionality. Simply download and install that by pointing the device browserto the URL or download it to PC and install it with PC Suite.
However to enable functionality beyond the capabilities assigned to theMobile Web Server, an unsigned .sis needs to be downloaded and thensigned with a certificate from Symbian. In that case download http://mobilews.mobcal.com/pyLaunch_unsigneddevcert.sis to yourPC and follow the instructions in the next step.
7. Symbian sign pyLaunch
If the self signed pyLaunch .sis was downloaded in the previous step thisstep can be skipped.
To enable functionality beyond the capabilities assigned to the MobileWeb Server, pyLaunch has to be signed with a certificate with the re-quired capabilities. The easiest way to do that is to sign the unsignedpyLaunch .sis file with a development certificate from Symbian Signed.That can be done through the online service https://www.symbiansigned.com/app/page/public/openSignedOnline.do.
To get the IMEI number of your device simply enter
*#06#
Location is needed to read information about the device location from GPSutility.ReadDeviceData is needed to read the Cell-id.NetworkServices is used to allow the application to use data services tosend response back to the calling application, for example when askingthe user a question.
8. Start Nokia Mobile Web Server
To start the Mobile Web Server open ”Menu” -¿ ”Applications” -¿ ”WebServer” -¿ ”Options” -¿ ”Start server”
After completing the above steps the Mobile Web Server with Web service sup-port should be setup and ready to use. WSDL files for installed services cannow be retrieved through https://maggi.mymobilesite.net/webservices/py/.py
Appendix E
Screen shots
E.1 Management interface
Figure E.1: Management Interface, users and operations
132 APPENDIX E. SCREEN SHOTS
Figure E.2: Management Interface, installed services and service installation
E.2 mobCal.com 133
E.2 mobCal.com
Figure E.3: User has logged in and his calendar entries for the current month are displayed
134 APPENDIX E. SCREEN SHOTS
Figure E.4: Creating a new calendar entry
E.2 mobCal.com 135
Figure E.5: Updating an existing calendar entry
136 APPENDIX E. SCREEN SHOTS
Figure E.6: Changing user settings
E.2 mobCal.com 137
Figure E.7: Request a meeting with the user
138 APPENDIX E. SCREEN SHOTS
Figure E.8: After meeting has been successfully accepted
E.2 mobCal.com 139
Figure E.9: If user not available at the desired time
Figure E.10: Meeting request sent to user
Appendix F
Bibliography
[1] Salz, R; Blunck, C., February 1. 2007, ZSI: The Zolera Soap Infras-tructure Developer’s Guide Release 2.0.0, Zolera Systems, Inc., availablefrom Internet http://mesh.dl.sourceforge.net/sourceforge/pywebsvcs/zsi-2.0.pdf [cited 18. Jun. 2008; 14:17]
[2] Kanneganti, R.; Chodavarapu, P., 2008, SOA Security, Manning Publica-tions, Greenwich.
[3] Organization for the Advancement of Structured InformationStandards, March 2004, Web Services Security UsernameToken Pro-file 1.0, OASIS Standard 200401, 2004, Organization for theAdvancement of Structured Information Standards, availablefrom Internet http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf [cited 9.Jul. 2008; 11:17]
[4] Nokia, 10. January 2008, PyS60 Library Reference, Release 1.4.2 final, NokiaCorporation, Finland.
[5] Weerawarana, S.; Curbera, F.; Leymann, F.; Storey, T.; Ferguson, D., March2005, Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More, Prentice Hall PTR.
[6] The Parlay Group, Our members, The Parlay Group, available fromInternet http://www.parlay.org/en/about/members.asp [cited09.10.08; 12:30]
[7] He, H., September 30, 2003, What is Service-Oriented Architecture, xml.com,awailable from Internet http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html [cited 10.08.08; 16:46]
[8] World Wide Web Consortium, Web Service Activity, W3C, available fromInternet http://www.w3.org/2002/ws/ [cited 10.08.08; 18:46]
141
[9] Organization for the Advancement of Structured Information Stan-dards (OASIS), OASIS Commitees by Category: Web Services, avail-able from Internet http://www.oasis-open.org/committees/tc_cat.php?cat=ws
[10] World Wide Web Consortium, 16. August 2006, Extensible Markup Lan-guage (XML) 1.1 (Second Edition), W3C, available from Internet http://www.w3.org/TR/xml11/ [cited 11.08.08; 13:23]
[11] World Wide Web Consortium, XML Schema, W3C, http://www.w3.org/XML/Schema [cited 11.08.08; 17:00]
[12] World Wide Web Consortium, 4. February 2004, XML Infoset, W3C, avail-able from Internet http://www.w3.org/TR/xml-infoset/ [cited11.08.08; 22:48]
[13] World Wide Web Consortium, Efficient XML Interchange Working Group,W3C, available from Internet http://www.w3.org/XML/EXI/ [cited11.08.08; 22:57]
[14] ITU-T, May 2005, Fast Infoset, ASN.1 - X.891, ITU-T, available from Internethttp://www.itu.int/rec/T-REC-X.891-200505-I/en
[15] World Wide Web Consortium, April 2007, SOAP Version 1.2 Part 0: Primer(Second Edition), W3C, available from Internet http://www.w3.org/TR/2007/REC-soap12-part0-20070427/ [cited 12.08.08; 11:05]
[16] World Wide Web Consortium, April 2007, SOAP Version 1.2 Part 1:Messaging Framework (Second Edition), W3C, available from Internethttp://www.w3.org/TR/2007/REC-soap12-part1-20070427/[cited 12.08.08; 11:06]
[17] World Wide Web Consortium, April 2007, SOAP Version 1.2 Part 2:Adjuncts (Second Edition), W3C, available from Internet http://www.w3.org/TR/2007/REC-soap12-part2-20070427/ [cited 12.08.08;11:07]
[18] Organization for the Advancement of Structured Information Standards,2004, Web Services Security v1.0, OASIS 200401, Oasis-Open, avail-able from Internet http://www.oasis-open.org/specs/#wssv1.0[cited 12.08.08; 17:07]
[19] World Wide Web Consortium, September 2007, Web Services Policy 1.5- Framework, W3C, available from Internet http://www.w3.org/TR/ws-policy/ [cited 12.08.08; 18:28]
[20] Fielding R., 2000, Architectural Styles and the Design of Network-based Soft-ware Architectures, PhD thesis, University of California, Irvine, avail-able from Internet http://www.ics.uci.edu/˜fielding/pubs/dissertation/top.htm [cited 12.08.08; 23:09]
[21] Yee, R., February 2008, Apress Pro Web 2.0 Mashups Remixing Data and WebServices, Apress.
142 APPENDIX F. BIBLIOGRAPHY
[22] Richardson, L.; Ruby, S., May 2007, RESTful Web Services, O’Reilly, Se-bastopol.
[23] Chande, S., December 2006, Mobile Web Services, Department of ComputerScience, University of Helsinki, Finland, available from Internet http://www.cs.helsinki.fi/u/chande/MobileWebServices.pdf [cited09.10.08; 14:00]
[24] Srirama, S.; Jarke, M., Prinz, W., 2006, Mobile Web Service Provisioning ,RWTH Aachen, Informatik V, Fraunhofer FIT.
[25] Wikman, J.; Dosa, F.; Tarkiainen, M, May 24, 2006, Personal Websiteon a Mobile Phone, Nokia Research Center, Helsinki, available from in-ternet http://research.nokia.com/tr/NRC-TR-2006-004.pdf[cited 14.08.08; 12:49]
[26] Wikman, J.; Dosa, May 24, 2006, Providing HTTP Access to Web Servers Run-ning on Mobile Phones, Nokia Research Center, Helsinki, available from in-ternet http://research.nokia.com/tr/NRC-TR-2006-005.pdf[cited 14.08.08; 12:51]
[27] Ilkka, J.; Vainio, C., 2007, Nokia Mobile Web Server, Nokia Corporation,Readme.fi, Finnland, available from Internet http://mymobilesite.net/files/MobileWebServer_Book_en.pdf [cited 18.08.08; 17:27]
[28] Bylund, M and Segall, Z, 2004, Towards seamless mobility with personalservers, Emerald Group Publishing Limited, vol. 6, no. 3, pp. 172-179
[29] Laukkanen, M, Mobile Web Services, Department of ComputerScience, University of Helsinki, available from Internet http://www.cs.helsinki.fi/u/chande/courses/cs/WSA/seminar/MikkoLaukkanen/MobileWebServices-SeminarPaper.pdf [cited15.08.08; 18:23]
[30] The Liberty Alliance, http://www.projectliberty.org/ [cited16.08.08; 11:00]
[31] Aarts, Robert, eds. Liberty Reverse HTTP Binding for SOAP Specification,Version 1.1, Liberty Alliance Project (14 December 2004). Availablefrom Internet http://www.openliberty.com/liberty/content/download/1219/7957/file/liberty-paos-v1.1.pdf [cited16.08.08; 13:16]
[32] The Parlay Group, http://www.parlay.org/en/index.asp [cited16.08.08; 14:59]
[33] ETSI OSA Parlay X, Parlay X 2.1 Specifications, ES 202 391 V1.2.1,ETSI, available from Internet http://portal.etsi.org/docbox/TISPAN/Open/OSA/parlayx21.html [cited 16.08.08; 16:02]
[34] ETSI Open Service Access (OSA), Overview & Status of OSA API Speci-fications, available from Internet http://portal.etsi.org/docbox/TISPAN/Open/OSA/Overview.html [cited 16.08.08; 16:01]
143
[35] Gehlen, G.; Pham, L., 3-6 Jan. 2005, Mobile Web Services for Peer-to-Peer Ap-plications, Consumer Communications and Networking Conference, pp.427-433
[36] IBM, Web Services Tool Kit for Mobile Devices, available from Internet http://www.alphaworks.ibm.com/tech/wstkmd [cited 16.08.08; 18:07]
[37] Sun Developer Network, J2Me Web Services APIs (WSA), JSR 172, avail-able from Internet http://java.sun.com/products/wsa/ [cited16.08.08]
[38] C. Enrique Ortis, April 2004, Introduction to J2ME Web Services, Sun De-veloper Network, available from Internet http://developers.sun.com/mobility/apis/articles/wsa/ [cited 16.08.08; 18:10]
[39] Hirsch, F.; Kemp, J.; Ilkka, J., 2006, Mobile Web Services Architecture andImplementation, John Wiley & Sons, Ltd., England.
[40] Web Services Interoperability Organization, http://www.ws-i.org/[cited 17.08.08; 11:15]
[41] Web Services Interoperability Organization, 2006, Basic Profile Ver-sion 1.1, available from internet http://www.ws-i.org/Profiles/BasicProfile-1.1.html
[42] Banaei-Kashani, F.; Chen, C-C; Shahabi, C., 2004, WSPDS: Web ServicesPeer-to-peer Discovery Service, Computer Science Department, Universityof Southern California, Los Angelse, California, available from Inter-net http://infolab.usc.edu/DocsDemos/isws2004_WSPDS.pdf[cited 17.08.08; 16:58]
[43] Forum Nokia, 6. July, 2008, Mobile Web Server APIs, Developer Com-munity, Wiki, Nokia, Finland, available from Internet http://wiki.forum.nokia.com/index.php/Mobile_Web_Server_APIs [cited19.08.08; 10:50]
[44] Nokia, PAMP, Personal Apache MySQL PHP, OpenSource.nokia.com,available from Internet http://wiki.opensource.nokia.com/projects/PAMP [cite 19.08.08; 13:43]
[45] Nokia, March 2008, How to utilize device resources from a WRT widget,Forum Nokia, available from Internet http://wiki.forum.nokia.com/index.php/How_to_utilize_device_resources_from_a_WRT_widget [cited 19.08.08; 18:15]
[46] Morris, B.; Godwin, A., March 2008, A guide to Symbian Signed, Sym-bian Software Limited, available from Internet http://developer.symbian.com/ssguide [cited 24.08.08; 15:51]
[47] W3C, 11. February, 2004, Web Services Architecture, available from In-ternet http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#whatis [cited 26.08.08; 17:17]
[48] W3C, 24. June, 1999, WAP Binary XML Content Format, available from In-ternet http://www.w3.org/TR/wbxml/ [cited 26.08.08;17:17]
144 APPENDIX F. BIBLIOGRAPHY
[49] Fitzek, F.; Reichert, F., 2007, Mobile Phone Programing and its Applications toWireless Networking, Springer, Dordrecht, The Netherlands
[50] Wang, A.; Sorensen, C-F., Fossum, T., 2005, Mobile Peer-to-Peer Technol-ogy used to Promote Spontaneous Collaboration, Norsk Informatikkonferanse,available from Internet http://www.nik.no/2005/Wang.pdf [cited26.08.08; 20:00]
[51] Jaokar, A.; Fish, T., 2006, Mobile Web 2.0 The innovator’s guide to developingand marketing next generation wireless/mobile applications, Futuretext Lim-ited, London, UK
[52] Lukaszewski, A., Oct. 15, 2007, Python and Apache on the iPhone,python.about.com, available from Internet http://python.about.com/b/2007/10/15/python-and-apache-on-the-iphone.htm[cited 03.09.08];
[53] Bartolomeo, G.; Casalicchio, E.; Salsano, S.; Blefari Melazzi, N., 2007, De-sign and Development Tools for Next Generation Mobile Services, InternationalConference on Software Engineering Advances
Appendix G
Acronyms
3GPP The 3rd Generation Partnership Project
AJAX Asynchronous JavaScript and XML
API Application Programming Interface
APR Apache Portable Runtime
CA Certificate Authority
COBRA Common Object Request Broker Architecture
CSS Cascading Style Sheets
ETSI European Telecommunications Standards Institute
FAQ Frequently Asked Questions
HTTP Hyper Text Transfer Protocol
IP Internet Protocol
ITU-T International Telecommunication Union - TelecommunicationStandardization Section
J2ME Java 2 Platform Micro Edition
J2SE Java 2 Platform Standard Edition
JAX-RPC Java API for XML-Based RPC
JSR Java Specification Request
LAN Local Area Network
MMS Multimedia Messaging Service
NAT Network Address Translation
146 APPENDIX G. ACRONYMS
NRC Nokia Resource Center
OASIS Organization for the Advancement of Structured InformationStandards
OBEX OBject EXchange
OMA Open Mobile Alliance
OWSER OMA Web Services Enabler Specification
P2P Peer-To-Peer
PAMP Personal Apache MySQL and PHP
PKI Public Key Infrastructure
QName Qualified Name
RMI Remote Method Invocation
RPC Remote Procedure Call
SAML Security Assertion Markup Language
SAML Security Assertion Markup Language
SAX2 Simple API for XML, version 2
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
SOAP SOAP, (previously Simple Object Access Protocol, but that acronymhas been dropped and today its name is simply SOAP)
SOA Service Oriented Architecture
SQL Structured Query Language
STS Security Token Service
TCP Transport Control Protocol
UI User Interface
URI Uniform Resource Identifier
URL Uniform Resource Locator
W3C World Wide Web Consortium
WAP Wireless Application Protocol
WAP Wireless Application Protocol
WBXML WAP Binary XML
WLAN Wireless Local Area Network
147
WRT Web Runtime
WS-I Web Services Interoperability Organization
WS-Security Web Services Security
WSA Web Service API
WSDL Web Service Description Language
WSP Wireless Session Protocol
WTP Web Tools Platform
XHTML Extensible HyperText Markup Language
XML Extensible Markup Language