Profile-Based Discovery

Razieh Niazi

Mobile Service

• Recently, demand for access to web services via mobile phones is strongly increasing. This has been due to the various parameters such as:– Ubiquitous Internet access – Advancement in wireless technology – Improvement in mobile devices.

• However, due to the variety and great diversity of mobile devices, there are some concerns which should be considered.

• One of these concerns is the client’s ability to find relevant mobile services and ones that can work within the constraints of the mobile device.

• As we know mobile devices are considered as limited-consumer device with different capability in size, power, screen size, resolution, bandwidth, processing power and so on. In fact, they have limited performance and interface.

• Hence, customizing applications and services for various devices for different users is a tedious work.

• By the way, the user preference and mobile capability is changing time by time.

• In fact, we need some dynamic methods to deliver mobile capabilities and user preferences to the particular servers.

• Thus, in our project we design and implement a middleware that collects mobile device profile information plus user preference automatically and discovers the relevant mobile web services based on the accumulated information in an intelligent way. This is done using CC/PP (Composite Capabilities/ Preference Profiles ).

• This is in contrast with traditional wireless mobile service oriented computing paradigm in which clients discovers services, select ones that are suitable, and then invoke services. In this paradigm, clients will determine if services will function properly within their mobile devices only after they already have selected or invoked these services.

CC/PP Background

• CC/PP is a W3C standard for expressing capabilities and preferences which is based on XML serialization that itself uses the Resource Description Framework.

• CC/PP defines a model for personalization and customization device profiles.

• Different handheld devices have different capabilities in input, output, hardware, software, network and browser.

• In order for a web server or service provider to provide optimized and customized content to different clients it requires a description of the client capabilities.

• Recently two new compatible standards have been created for describing delivery context based on the Resource Description Framework (RDF): – Composite Capabilities / Preferences Profile (CC/PP)

created by the W3C– User Agent Profile (UAProf)

Vocabulary=“http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#" Hardware

ImageCapable = Yes InputCharSet = {US-ASCII,ISO-8859-1] Model = SomeModelNumber ScreenSize = 120x102 SoftKeysCapable = Yes Vendor = SomeVendorName

Software CcppAccept = {application/vnd.wap.wml,image/vnd.wap.wbmp} OSVendor = SomeOtherVendorName

BrowserUA BrowserName = SomeBrowserName

BrowserVersion = 1.1

A CC/PP profile Example

• One of the important thing to note in a CC/PP profile is vocabulary.

• Vocabulary is a a set of valid component names, valid attribute names, data types of the attributes, and so on .

• In other words, the vocabulary defines the format and the language used to communicate profile information between senders and receivers.

One important vocabulary is UAProf.

• because the majority of CC/PP-capable devices use UAProf .

• UAProf vocabulary consist of six components:– HardwarePlatform– SoftwarePlatform– NetworkCharacteristics – BrowserUA– WapCharacteristics– PushCharacteristics. These components contain attributes.

The following shows an Nokia’s UAProf profie :

• <rdf:Description rdf:ID="MyDeviceProfile">• <prf:component>• <rdf:Description rdf:ID="HardwarePlatform">• <prf:ScreenSize>121x87</prf:ScreenSize>• <prf:Model>R999</prf:Model>• <prf:ScreenSizeChar>15x6</prf:ScreenSizeChar>• <prf:BitsPerPixel>2</prf:BitsPerPixel>• <prf:ColorCapable>No</prf:ColorCapable>• <prf:TextInputCapable>Yes</prf:TextInputCapable>

</rdf:Description>• </prf:component>• <prf:component>•

• <rdf:Description rdf:ID="SoftwarePlatform">• <prf:CcppAccept-Charset>• <rdf:Bag>• <rdf:li>US-ASCII</rdf:li>• <rdf:li>ISO-8859-1</

rdf:li>• <rdf:li>UTF-8</rdf:li>• </rdf:Bag>• </prf:CcppAccept-Charset>• ……• <rdf:Description rdf:ID="NetworkCharacteristics">

……

• It's important to note that the CC/PP is independent of any particular vocabulary and therefore doesn't define what components and attributes must be used in a profile

• Device vendors are responsible for authoring the reference profile describing the base capabilities of each type of device. In addition, vendors must provide browser support so that applications can attach a CC/PP profile to the HTTP request. Finally, vendors must ensure that all profiles are in valid CC/PP or UAProf syntax.

How to Deliver Profiles?

• One of the major design aims of these standards is the efficient delivery of context to the server even via low bandwidth wireless networks.

• This is achieved by the use of profile references and profile differences that work as follows:– instead of sending an entire profile with every request

a client only sends a reference to a profile, stored on a third device known as a profile repository, along with a list of overrides specific to this particular client. The process of interpreting the profile references and differences is known as profile resolution

There are four broadly equivalent protocols defined for CC/PP profiles to deliver the content

• CC/PP exchange protocol (CCPPex) • Wireless profiles HTTP (W-HTTP) • Wireless session protocol (WSP) • The session initiation protocol (SIP)

• In our project we only implements one of these protocols: transport via W-HTTP (Wireless profiled HTTP)

• W-HTTP request is just like HTTP request plus two additional properties known as: – x-wap-profile

It refers to the profile reference ; plus there is a value

“1-Rb0sq/nuUFQU75vAjKyiHw==“ known as a profile-diff digest. • The first part of the profile-diff-digest, 1-, is the profile-diff

sequence number. This is used to indicate the order of the profile-diffs and to indicate which profile-diff the profile-diff digest refers to.

• The remainder of the profile-diff digest is generated by applying the MD5 message digest algorithm and Base64 algorithm to the corresponding profile-diff.

– x-wap-profile-diff

W-HTTP Request

- x-wap-profile-diff• This is another request header that has a profile-diff sequence number which

indicates the processing order and that this profile-diff corresponds to the previous profile-diff-digest.

• The profile-diff itself also consists of the XML fragment which spans the remainder of the request.

• Multi-line request header fields are permitted by the HTTP/1.1 specification as long as each subsequent line starts with either

a tab character or a whitespace. • Note not all servlet engines, for example early versions of

Tomcat, fully support the HTTP/1.1 specification so may not

allow multi-line request header fields. 

GET /ccpp/html/ HTTP/1.1Host: localhostx-wap-profile:"http://localhost:8080/ccpp/profiles/test09defaults.rdf",

"1-Rb0sq/nuUFQU75vAjKyiHw=="x-wap-profile-diff: 1;<?xml version="1.0"?> <rdf: RDF xmlns ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  xmlns: rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  xmlns: prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#">  < rdf : Description rdf : ID="MyDeviceProfile">     < prf : component>       < rdf : Description rdf : ID="HardwarePlatform">          < rdf : type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-     20010426#HardwarePlatform"/>              < prf: BitsPerPixel>16</ prf: BitsPerPixel >

</ rdf: Description>     </ prf: component>  </rdf: Description> </ rdf: RDF>

A W-HTTP Request Example

High-Level Architecture

Handheld DeviceMobile Web Services

1) Client in

vokes GUI a

nd

Perform

search request

2) Request is forwarded

to the server

Mobile Service Directory3) Connect to Directory

Search & Discovery

4) E

xecu

te S

earc

h

5) Send relevant results String

n-Tier Architecture

Client Tier

Database

Servlet as Presentation Logic Tier

View

JDBC

Data Access tier

using JDBCData tier

In order to implement, we should do the following steps:Client Side:• 1- Get Device Profile Reference (URL)• 2- Get User Preference• 3- Send keyword along with the above

information to the server as W-HTTP request

Implementation Steps

Server Side:• 4- Extract data from W-HTTP request by

server• 5- Stored Mobile Profile in Profile Repository• 6- Generate the profile-diff digest and

compare with the retrieved profile-diff digest to see whether the user preference has been changed.

• 7- Performing Profile Resolution

8- Performing query on the database and discovery available web services

9- Sending response back to the client with W-HTTP response

1. Get Device Profile Reference (a URL)• Device Profile which is specified as a URL

representing the default profile from the vendor-specific location.

• Hence, each Mobile device has its specific device profile URL

• In Our project, we add it as a property to the JAD file. (Java Application Descriptor )

• Whenever the midlet is started, the properties defined in JAD file are retrieved.

Client Side

2. Get User Preference• Users can enter their preferences through a

midlet. The default values gets from default mobile profile using XML parser, KXML, and the user modification will be stored as a XML inside RMS.

• J2ME record management system (RMS) provides a mechanism through which MIDlets can persistently store data and retrieve it later .

3. Send keyword along with the profiles information to the server as W-HTTP request

• As explained earlier it is like HTTP request plus 2 additional properties: x-wap-profile , x-wap-profile-diff.

• We behave with these two properties like other http request headers such as Host, Accept, Accept-Language, as long as we use HTTP 1.1 protocol.

• We use HTTPConnection.setRequestProperty to add these fields to Http header.

4. Extract data from W-HTTP request by server

Server Side

5- Stored Mobile Profile in Profile Repository• In order to improve performance, profiles are cached

in a profile repository in the server. • Our project only caches referenced profiles but not

profile-diffs due to the following reason:– Because referenced profiles are associated with a

unique identifier which is their URL, but profile-diffs do not have any URL.

– Plus profile-diffs which are user preferences, are changed time by time, it is better to store them in the user handheld device.

• Although, we have solution for caching both Mobile Profile and User Preference to make the system smart enough to recognize that a particular user has already used the system before and the request is coming from the same device .

• This can be done by allocating a unique id to each user when s/he signs on in order to login to the server and create a profile for each user which holds username, user id, mobile devices and user preferences and its message digest for each device.

6- Generate the profile-diff digest and compare with the retrieved profile-diff digest to see whether the user preference has been changed

7. Performing Profile Resolution• When the server receives a HTTP request with UAProf request

headers, it has to perform profile resolution.• Profile resolution is done by processing all profiles

and profile-diffs in the following order: – firstly it processes all referenced profiles in the order

they are present in the x-wap-profile request header. – It then processes all the profile-diffs. – This profile processing operation involves building an

RDF model for each profile or profile-diff and then extracting a list of attributes from the model.

– These attributes are then appended together in the order indicated (merged).

 

8. Performing query on the database and discovery and ranking available web services

9. Sending response back to the client with W-HTTP response• W-HTTP protocol adds an extension header in responses. • This header, x-wap-profile-warning indicates whether the

server has used the UAProf information when generating the response.

• This can take five possible values: not applied, content selection applied, content generation applied, transformation applied and not supported.

• The following shows the HTTP Response:

HTTP/1.1 200 OKx-wap-profile-warning: 202

• Optimised Usage of Bandwidth:– in order to gain optimized usage of wireless bandwidth, instead of

sending an entire mobile profile with every request a client only sends a reference to a profile, stored on a third device known as a profile repository, along with a list of overrides specific to this particular client.

• Security: – we consider it in different aspects as follow:

• User authentication and authorization when user wants to communicate with server,

• Data Encryption using cryptography methods for protecting user profile,

• Message digest using the MD5 message digest algorithm to generate profile-diff digest for x-wap-profile-diff property in W-HTTP request message.

• Caching:– Explained earlier

Highlights

• JSR188 to collect CC/PP description and information

• JSR 118 for MIDP 2.0• JSR139 for CLDC1.1 • JSR 177 for Security (SATSA)• JSR 172 for XML Parsing (KXML)• JSR 75 for using the FileConnection APIs

APIs

References:• [1]- Yeonghyo Jeon and Eenjun Hwang, “Personalizing Web Service Pages for

Mobile Users” • [2]- Qusay H. Mahmoud, “Getting Started With Composite Capabilities/Preference

Profiles and JSR 188”, http://developers.sun.com/techtopics/mobility/midp/articles/ccpp/

• [3]- Mark H. Butler,”DELI: A  DElivery context LIbrary for CC/PP and UAProf”,http://validator.openmobilealliance.org/cgi/deli-faq.html

• [4] Bill N. Schilit, Marvin M. Theimer, Brent B. Welch, Customizing Mobile Applications: In USENIX Symposium on Mobile and Location-Independent Computing (1993)

• [5] Henricksen, K., Indulska, J., Rakotonirainy, A.: Modeling context information inpervasive computing systems. In Mattern, F., Naghsineh, M., eds.: First

Interna- tional Conference on Pervasive Computing (Pervasive). Number 2414 in LectureNotes in Computer Science, Zurich, Switzerland, Springer (2002) 167–

180• [6] Tim Kindberg et al., People, places, things: web presence for the real world,

Mobile Networks and Applications, Volume 7 , Issue 5 (October 2002), Pages: 365 – 376

Template Design by PoweredTemplates.com'