precious battery life time. The two requirements are also conflicting, in order to minimize the number of requests the only thing that can be done is to stuff more information into a single request. That on the other hand, increases the number 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 the actual output of a request to the need at each time. Meaning that the response type would define as large scope of return values as feasible to fulfill the first requirement, having as many of them as possible optional. The client of the service could then, through an input parameter, specify the actual parameters wanted for its response. The service would read the input parameter, process the request but only return the desired output variables requested, other would not be set at all and dismissed in the output. On the receiving end they would be undeclared or empty. In this way, a filter variable in the input controls the actual output. This filter variable would be optional and omitting it would result 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 most well known and supported of those are:
• Java, Micro Edition: Offers various functionality through published JSR libraries.
• 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 and Parlay 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 interfaces
PresenceandMessaging. The presence service is further divided intoavailabil-
ity,devicestateandlocation. Theavailabilityresource indicates whether the user
is currently available in terms of: the selected profile, whether in a call or hav- ing active calendar entries. The devicestate publishes the battery level, local time and connection type. The location resource publishes latitude, longitude, accuracy and location method.
Themessageresource 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_
68 CHAPTER 6. MOBILE WEB SERVICES API DESCRIPTION
in functionality and application developers are encouraged to implement new services as needed. It only utilizes the POST and GET HTTP methods.
The Parlay X standard is divided into the following functional parts: Third Party 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 would also 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 the mobile device has an active call.
• Call Notification - Web service that would register a call back handler that would be requested when receiving an incoming call, dialling a number and 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 when messages where received or sent. Also operations to push ring tones and logos 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 parameter specifying the device or devices the operation applies to. That is obviously not applicable in the case of a mobile hosted service where each request is made to a specific device. Many also take in a billing argument, specifying who should be charged for the usage, the application developer or the mobile subscriber. That does not apply in mobile device hosted services, since, it is always the subscriber that will be charged for usage.
The interfaces described by Parlay X and the REST API are used as much as possible 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 System
information,Device UtilitiesandData Management.
• Presence and System Information: All information related to the user of the
device and underlying system of the devices. Such as getting the current location, battery level, display size, IMEI number, OS version and such.