Enhancing the Discovery of Mobile Services Eyhab Al-Masri and Qusay H. Mahmoud Department of Computing and Information Science University of Guelph, Guelph, ON, Canada
{ealmasri,qmahmoud}@uoguelph.ca ABSTRACT While several service discovery protocols and standards have been proposed for supporting service discovery from mobile devices, this remains a challenging problem. In many cases, mobile clients may discover services which they consider relevant but soon realize that such services are not completely usable on their mobile devices due to compatibility and interoperability issues. Without integrating device capabilities into the discovery process, or a device-aware mobile service discovery, it becomes extremely difficult to determine whether discovered services may or may not function properly within the device’s constraints. This paper introduces a solution to this problem and proposes MobiEureka, a mobile device-aware system for enhancing the discovery of mobile services using mobile devices. This paper presents experimental validation, results, and analysis of the presented ideas.
Categories and Subject Descriptors D.2.12 [Software Engineering]: Interoperability - Distributed objects, Interface definition languages; H.3.5 [Information Systems]: Online Information Services – Commercial services, Data sharing, Web-based services.
General Terms Management, Design, Measurement, Performance, Verification.
Keywords Mobile services, extending WSDL, middleware architecture, ranking mobile services, ranking, device-aware, CC/PP.
1. INTRODUCTION Mobile services are wireless computing applications or services that can be either pushed to user's handheld wireless devices or downloaded and installed, over the air, on handheld wireless devices [16]. Given the proliferation of mobile devices, the ability to handle this magnitude of mobile device types is no longer generic in terms of service discovery. In recent years, more emphasis on how to discover mobile services has increased significantly and prompted the need for exploring various methods on how to effectively allow clients to find relevant services. This has driven the demand for Web services through mobile devices (or mobile services) to flourish considerably and will continue to do so particularly as the number of mobile Internet users begins to multiply. Thanks to advancements in wireless technology, ubiquitous Internet access, and improvements to mobile device technology that are
Copyright is held by the author/owner(s). WWW 2008, April 21--25, 2008, Beijing, China.
increasing the demand for mobile services. In addition, the emergence of social networking trends using mobile devices in recent years has driven the demand to create mobile-specific services as in the cases of Facebook Mobile, YouTube Mobile, MySpace Mobile, and LiveJournal. Although many of these services offer some form of personal rich social networking, the proliferation of services may be overwhelming in terms of service discovery and differentiating between services from each other will become very complex, and time consuming. There are major challenges associated with discovering mobile services from mobile devices. Unfortunately, many of the current service discovery methods may not be practical enough to discover services from within mobile devices. Current discovery methods (i.e. UDDI Inquiry API) do not have the capability of enabling mobile clients to effectively discover mobile services from within their mobile devices. In addition, Fourth Generation (4G) wireless communication system has proven to become a promising solution that has the potential to provide many of the requirements other previous systems did not achieve such as high data transfer rates, and effective client control. Mobile devices such as cellular phones, PDAs, and other small mobile devices have become diverse in size, shape, targeted audience, functionality, and more importantly features or services. In fact, advances in low-power circuit design and development in wireless technologies have driven the creation of excessive amount of small mobile devices that vary in processor types, touch-screen capabilities, screen and memory sizes, to name a few. Therefore, discovery of mobile services is no longer generic in terms of mobile device types. To achieve device-aware mobile service discovery, we have developed a solution called MobiEureka that is capable of dynamically discovering mobile services that can work within device constraints (or considered relevant) by taking into consideration device capabilities defined in the device’s profile such as Composite Capabilities/Preference Profiles (CC/PP). By learning device-specific capabilities, MobiEureka can recommend relevant mobile services to clients. MobiEureka is based on a given input (i.e. keyword), and is capable of identifying and ranking highly relevant services using a degree of relevancy (or compatibility) based on device features that can be extracted from the device’s profile. Our solution has been tested and results show a high success rate of having the correct or most relevant mobile service of interest within top results. Results also demonstrate the effectiveness of using devicespecific parameters as constraints when performing a search request and as elements when outputting results. Incorporating device-specific properties when finding mobile services of interest provides adequate information to service requestors about service guarantees and gives them some confidence as to the
compatibility and quality of mobile services they are about to invoke. The rest of this paper is organized as follows. Section two discusses the related work. Motivations and an operating scenario of MobiEureka are discussed in Section three. The mobile device profile is discussed in Section four. The proposed system’s architecture (MobiEureka) and components are discussed in Section five. Proposed extension to WSDL (or WSDL Mobile) is discussed in Section six. Experimental results are discussed in Section seven, and finally the conclusion and future work are discussed in Section eight.
2. Related Work There have been numerous efforts designed to enhance and adapt viewing content of Web pages on small mobile devices [13,14,15]. They include device-specific authoring which takes into consideration client device capabilities into account in order to display Web pages properly [10]. Other approaches include automatic re-authoring and summarization-based [10]. Several systems focused on combining all of these approaches in an efficient manner [11] or introduced a dynamic content adaptation such as SmartWeb [12]. However, very little or no research has been conducted on adapting the discovery of mobile services to mobile devices [3]. Nonetheless, there have been several approaches that have been presented in literature that relates to the discovery of mobile services such as location-based context aware [1,2,3], wireless service provisioning using neural networks [4], and a proxy-based middleware [5]. Other approaches focused on the personalization of mobile services using the Virtual Home Environment (VHE) based on personal service environment portability across network terminals [6], and Personal Service Environment (PSE) for handling service discovery and profile management [7]. Other approaches focused on personalizing services using agents [16]. Many of the current approaches, however, do not provide a method for combining client and service features for the discovery and selection of mobile services. Therefore, it is of great importance to find a method that can alleviate the performance of dynamically discovering and selecting mobile services based on a combination of selected features or preferences. Although there have been numerous studies on the discovery and delivery of mobile services, little work has been conducted on obtaining an enhanced set of preferences and features in order to reduce the number of discovered services while maintaining accurate selection rate. Hence, it is desirable to include deviceaware features into the discovery process and enable clients to discover services that are highly relevant. A fundamental factor in achieving such task is primarily dependent on finding enough device-specific features that can be used or matched when a discovery request is initiated. In this paper we introduce MobiEureka, a system that enhances the discovery of mobile services by ranking most relevant mobile services based on a given query derived from device-aware information in addition to service features and client preferences.
3. Operating Scenarios As the number of mobile services increases, clients will soon face the challenge of differentiating between those that share similar functionalities particularly when operating via mobile devices.
Finding relevant mobile services will become time consuming and less productive using current discovery methods. In fact, clients may invoke or select mobile services that are not compatible with device capabilities. To illustrate this dilemma, consider multiple social networking service providers offering mobile clients various forms of mobile blogging during the 2008 Olympic Games. A client who is looking for a blogging service discovers that the majority of service providers can offer such service. The client selects one that he/she believes is the most popular blogging service then decides to subscribe and pay for that service. However, the client soon discovers that the subscribed service is not completely supported by the device since the builtin browser does not support XML using HTTP (or the SupportsXMLHTTP feature). In this case, this client has paid or subscribed to a service that is not usable, in addition to the time consumed for finding such service. Unfortunately, in many cases, service providers do not provide ways for clients to predetermine if client mobile devices will properly consume their services. On the other hand, clients do not have the necessary tools to acknowledge whether services they wish to subscribe to will be completely supported by their devices. Other issues related to the discovery of mobile services may also arise particularly if mobile devices partially support features offered by such services, that is, a service may require a set of recommended to-have features on mobile devices while a client’s device can only support a portion of these recommended features. To illustrate this scenario, consider a client that is looking for a mobile service that is capable of providing real-time stock quote information. Generally, a client would access an interface to search for mobile services using a service directory (i.e. UDDI), and discovers that there are at least five mobile services that can perform the same functionality. Which mobile service should this client choose? How much time and effort does this client has to invest to find relevant or compatible mobile services? The choice can become simple if it is assumed that service features are fully supported by a mobile device. In this case, mobile services that can be subscribed to should be chosen. The problem however, is that discovered mobile services may not always be completely compatible with all mobile devices. Unfortunately, current service discovery methods (i.e. UDDI) or service description standards (i.e. WSDL) do not provide the built-in capability to specify service characteristics or recommended to-have features for mobile devices, and in many cases, clients may subscribe to services that may not completely operate properly within the device’s constraints. It would be desirable if clients can selectively discover and subscribe to services that can function properly within the device’s constraints by taking into consideration the mobile device’s profile during the discovery process and prior to service invocations or subscriptions. Enabling the discovery of device capabilities and including such information during the discovery process can only return services that are relevant and can work within the device constraints. More specific, discovery of mobile services should be device-aware, that is, the ability to know the client’s device capabilities as this dictates much for systems understanding about current service compatibility and interoperability. Therefore, it would be desirable if there is a mechanism that can provide clients with ways to differentiate between services that share similar functionalities and provide them with those that can work within the device constraints.
The fact that mobile devices operate in a wireless environment imposes many constraints such as low bandwidth, risk of service degradation when performing handoffs, mobile services must be able to work within the daunting constraints of these devices, including input capabilities, screen size, installed runtime environments, operating system, memory, among many others. Furthermore, device-aware mobile service discovery is possible only if service providers can include device constraints as part of the publishing of service information within services registries (i.e. UDDI) or service interfaces (i.e. WSDL).
4. Types of Mobile Device Profiles One of the chief challenges when discovering mobile services is the inability to discover those services that operate or function properly within the device’s constraints. Many of the current discovery methods used for publishing and discovering services fail to address the need for having a highly customizable discovery process. To overcome these issues, we collect devicespecific features stored within the mobile device’s profile and use this information to rank mobile services that are relevant. The degree of relevancy depends on the compatibility level between what the service has to offer and what the device can support.
to collect a complete list of device capabilities. In fact, Microsoft MDP does include details such as HardwarePlatform, SoftwarePlatform, NetworkCharacteristics, WAPCharacteristics, and PushCharacteristics as the CC/PP or UAProf profiles. Many of the current device profile technologies share similar characteristics but may be named differently as shown in Figure 1. MobiEureka takes advantage of the mobile device profiles and extracts a set of features that characterizes the capabilities of the access mechanisms and the preferences of the client. These features are used as part of the data to discover and recommend services of interest, which is an integral part of the overall MobiEureka system.
5. MobiEureka Architecture The aim of our approach is to design an intelligent system that ranks highly relevant mobile services by taking advantage of client preferences, device capabilities, and service features. A high-level architecture of our system is shown in Figure 2. The S1 through Sn represent services that match a given search query (i.e. keyword-based).
The World Wide Web Consortium (W3C) has defined the Composite Capabilities/Preference Profiles (CC/PP) standard for representing device capabilities and user preferences. The CC/PP is based on the Resource Description Framework (RDF). When a content server receives an HTTP request containing a CC/PP reference, it processes the request, follows the URL to the profile, and uses the information it finds there to format content that is suited to the device and to the user’s preferences, all automatically. Another standard that is based on RDF is the User Agent Profile (UAProf). UAProf profiles consist of a set of components including: HardwarePlatform, SoftwarePlatform, NetworkCharacteristics, WAPCharacteristics, and PushCharacteristics.
Figure 2. MobiEureka Architecture
Microsoft has its own proprietary definition of mobile profiles that can only function on Microsoft-based technology called Mobile Device Profile (MDP). MDP is very similar in terms of vocabularies to those in the CC/PP, but differ in the method of deployment. Microsoft’s MDP does not involve any RDF and is written in plain XML language. Microsoft’s MDP depends on a browser object called HttpBrowserCapabilities which can be used
Microsoft Mobile Profile NumberOfSoftkeys MobileDeviceManufacturer MobileDeviceModel PreferredRenderingMime PreferredImageMime ScreenCharactersWidth ScreenCharactersHeight ScreenPixelsHeight ScreenPixelsWidth SupportsCss MaximumHrefLength CanInitiateVoiceCall IsColor InputType SupportsBold
(2) session variables HTTP request
(1) (3) HTTP response
CC/PP Server
NumberOfSoftKeys Vendor Model Push-Accept (text + images) ScreenSizeChar (width+height) ScreenSize SupportsCSS URLRequestLength VoiceInputCapable ColorCapable Keyboard TextFormatBoldSupported
Figure 1. Comparison between Microsoft Mobile Profile (MDP) and CC/PP capability attributes
Internet
Mobile Device
Figure 3. Overview of the MobiEureka Request/Response Processing Figure 3 shows an overview of how MobiEureka handles requests and responses from and to clients using the browser-based solution. Clients use their mobile devices to access the MobiEureka interface for searching for relevant mobile services using a browser through a URL (step 1). MobiEureka resides on an HTTP server that handles incoming requests and prepares response messages back to clients. MobiEureka takes advantage of using HTTP sessions in order to collect device profile information through the browser using objects such as HttpBrowserCapabilities and stores this information on the server using server session objects (step 2). MobiEureka begins
rankedresults
(usingsessionobject)
Storeentireprofileonserver Clients access a web page “detect.aspx”
search,aspx
Identify device capabilities
Figure 4. Flow diagram of a typical browser-based request/response processing collected information and prepares a response message which includes a list of pertinent or ranked mobile services (step 3). Through this design, most of the processing is achieved on the server-side and very little processing is performed on the mobile device. In cases where communication between HTTP server and mobile device is lost, MobiEureka caches client’s information for a limited period of time which may be used to continue processing once a new connection is established. Caching provides MobiEureka with a way to reduce the processing on the server side in the sense that for clients who utilize it for discovering mobile services, it does not have to load the device profile every time the system is accessed or less frequently. Caching enables MobiEureka to handle as many requests as possible simultaneously and handle discovery operations at a large-scale. Figure 4 shows a typical browser-based request and response discovery of mobile services using MobiEureka. MobiEureka is composed of six components: (1) MobiEureka Query Interface, (2) Database (DB), (3) Feature Extraction (FE), (4) Service Manager (SM), and (5) Device-aware Ranking (DaR). Each component within MobiEureka system has a specific task. The following sections describe in detail the responsibility for each of these components.
5.1 MobiEureka Interface In order to perform device-aware discovery, MobiEureka provides a browser-based interface that enables clients to execute mobile discovery requests. There are two possible solutions or technologies that are available for developing wireless mobile services: (1) Native, and (2) Browser-based. The native solution involves a compiled application that can be installed on the client’s mobile device, while the browser-based uses a built-in browser within the mobile device to contact the HTTP Web server which is responsible for collecting device capabilities. MobiEureka uses the browser-based solution for several reasons: (1) most mobile devices contain built-in browser support which does not require any system-related application storage on the mobile device, (2) it has less overhead in the sense that processing will take place on the server-side (no processing is required on the mobile device), (3) it can take advantage of session objects on HTTP servers to store session or application variables which may include device-specific capabilities (no space is required on the mobile device), (4) MobiEureka is compatible with any browser that supports HTML or WAP, and (5) it excludes any need for
any client applications to be installed which provides less work and processing for clients.
5.2 MobiEureka DB The DB is a database that serves as a business directory of services. Typically, service providers publish their services into a service registry such as the Universal Description, Discovery, and Integration (UDDI) and provide information about their services such: name of service, description, area of coverage, types of technologies supported, price information, among others. Service providers also provide an access point (or URL) to the location in which the service can be invoked. Services are syntactically described through XML-based interfaces such as the Web Service Description Language (WSDL). Although a WSDL interface outlines a description of the service that each service provider supports, it does not handle how a mobile device, for example, should interact with the service. The diversity of device capabilities might be different from those of what the service can support, therefore, a client might be paying for a service that is not available or is not supported. MobiEureka also stores service-specific or recommended to-have features (through WSDL-M – Section 6) into a central database to determine the degree of relevance to mobile devices based on device profiles.
5.3 Feature Extraction (FE) In order for MobiEureka to determine whether a service is appropriate for each mobile device or not, it is necessary to collect and store service features. Unfortunately, current WSDL interfaces and UDDI registries do not provide ways to include service features such as supported screen sizes, input type required, support for frames, support for cookies, supports call backs, to name a few. Table 1 shows some of the common device profile capabilities that are used in MobiEureka. To illustrate the importance of associating service-specific supported features in service interfaces, consider an example in which a client uses a mobile device that does not support call backs (SupportsCallback). Using callbacks, clients can make client-side scripts to invoke server-side events without having any postbacks (i.e. executing server-side code without the need to refresh a page). Assume that this client subscribes to a service that requires a callback and attempts to invoke that service. In this case, this client may not be able to invoke this service and may not be aware why the service does not function properly on the mobile device.
Table 1. Common device profile capabilities used in MobiEureka ID
Device Feature
ID
Device Feature
1
ScreenPixelsWidth
2
MaximumHrefLength
3
ScreenPixelsHeight
4
PreferredRenderingMime
5
IsColor
6
PreferredImageMime
7
InputType
8
CanSendMail
9
CanInitiateVoiceCall
10
SupportsImageSubmit
11
HasBackButton
12
SupportsSelectMultiple
13
SupportsCSS
14
SupportsBold
15
IsMobileDevice
16
SupportsItalic
17
Tables
18
SupportsFontColor
19
Frames
20
SupportsBodyColor
21
Cookies
22
SupportsCallback
23
BackgroundSounds
24
SupportsXmlHttp
25
MaximumRenderedPageSize
It would be desirable if a client is able to determine if his/her mobile device is “compatible” or that the service he/she would like to subscribe to can function properly within the device’s constraints. To achieve this, services must be described in such a way that allows the retrieval of features that must be supported or recommended to-have features in order to perform a matching to those features supported by the device and stored in the device profile (i.e. CC/PP, UAProf, or MDP). MobiEureka utilizes our Web Service Crawler Engine (WSCE) [8,18,20] for collecting service information available on the Web from various resources (i.e. public service registries, search engines, etc…) and stores them into a local repository. Device profiles such as CC/PP, UAProf, and MDP provide all types of information about the client’s device. These devicespecific features provide MobiEureka with information such as hardware type, display size, terminal software, terminal browser, software platform, to name a few. Device-specific features assure the discovery of services and avoid having a client requesting and/or selecting a service that might not be compatible with the mobile device. By this, MobiEureka will minimize the possibility of invoking incompatible services and provides an extent a high level of confidence to clients on the usability of mobile services they are about to invoke through mobile devices.
5.4 Service Manager (SM) The Service Manager (SM) is responsible for handling service requests and responses between internal and external parts of the system. For instance, if a client is looking for a car rental service, the client would initiate the service by specifying a request through an interface. This request will consist of an input (i.e. user enters car rental as keywords). The SM receives the request, retrieves and stores device-specific information into the server, and initiates a request to the Device-aware Ranking (DaR) to determine services that are pertinent. SM is also responsible for managing the extraction of supported features from collected services.
5.5 Device-Aware Ranking (DaR) MobiEureka collects device capabilities through the Service Manager (SM) and performs a matching technique to determine
services that are relevant to a client. DaR performs search queries to the MobiEureka DB and retrieves all services that match a specific search query such as matching a given keyword to a service name or description. DaR then begins a comparison check to determine features that are supported by the mobile device and matches them to the ones collected from the mobile device. MobiEureka uses the Device-aware Ranking Function (DaRF) to measure the relevancy ranking of a particular mobile service msi. A mobile service with the highest calculated value for DaRF is the most desirable and relevant for the client based on his/her preferences. Assuming that there is a set of mobile services that share the same functional attributes but vary in the values of device-specific features shown listed in Table 1 where MS ( MS = {ms1, ms2, ms3, ..., msi}) and D ( D = {d1,d2,d3,..., dj} ), a device-aware computation algorithm determines which msi is relevant based on device-specific features collected from a mobile device profile. Using j (same as ID from Table 1) criteria for evaluating a given mobile service, we obtain the following DaRF matrix where each row represents a single mobile service msi while each column represents a single device-specific feature.
⎡ m 1,1 ⎢ m 2 ,1 ⎢ ⎢ . S =⎢ ⎢ . ⎢ . ⎢ ⎣⎢ m i ,1
m 1, 2
...
m 2,2
...
.
.
. .
. .
mi,2
...
m 1, j ⎤ m 2 , j ⎥⎥ . ⎥ ⎥ . ⎥ . ⎥ ⎥ m i , j ⎦⎥
(1)
where mi,j represents that value of a mobile service’s particular device feature. Let conditions C specify the conditions c1 … cj on associated service feature and let fj(x,y) return a value in [0…1] indicating how related value x to y for values within the dj domain, and vj be the values specified for any dj ε D. Then
DaRF (C , D, ms ) = ∑ f (m( i , j ), vj ) dj∈D
(2)
In order to allow for different circumstances, there is an apparent need to weight each factor relative to the importance or magnitude that it endows upon ranking mobile services based on device-specific features. Therefore, we need to define an array that represents the weights contribution for each dj where w = {w1,w2,w3,...,wj}. Each weight in this array represents the degree of importance or weight factor associated with specific device property values. The values of these weights are fractions in the sense that they range from 0 to 1. In addition, all weights must add up to 1.0. Each weight is proportional to the importance of a device parameter to the overall mobile service relevancy ranking. The larger the weight of a specific parameter, the more important that parameter is to the client and vice versa. The weights are obtained from the client via a client interface. Introducing different weights to Equation 2 results in the following equation:
DaRF (C , D, ms ) = ∑ wj × f (m( i , j ), vj ) dj ∈D
(3)
The device-aware relevancy ranking function calculates the total number of accumulations each service receives when its device profile recommendations from Table 1 match the current device capabilities. MobiEureka computes the DaRF values for matching
services and ranks each mobile service based on the relevancy to a particular device-specific feature such as those listed in Table 1.
6. WSDL-Mobile (WSDL-M) The Web Services Description Language (WSDL) is used to describe services, but it does not address service compatibility issues between services and clients’ mobile devices. WSDL definitions simply contain interfacing information such as messaging, binding, operations, among others. The binding takes place once the service provider and the client’s device are capable of dynamically exchanging information. Clients in such cases assume that their mobile devices will begin the binding process with the service provider. However, what if the service provider’s service does not work within the device’s capabilities? For instance, mobile devices that do not have the download capability of standalone applications must be able to connect to mobile services in an alternative mode. In addition, constraints of mobile computing such as limited screen size, limited input capabilities (i.e. keyboard) and physical environment constraints (i.e. noisy location) adds another level of complexity to existing mobile service models. Although the WSDL file outlines description of the service that each service provider offers, it does not handle how the device should interact with the service provider. The diversity of device capabilities might be different from those of the service provider and thus a client might be paying for a service that is not available or is not supported. Therefore, it is imperative to amplify only those mobile services that can work within a device’s capability. Through MobiEureka, clients will minimize the likelihood of invoking services that are unusable. Based on our findings, we conclude that it is essential to provide clients through service interfaces (or WSDLs) a mechanism that specifies service characteristics or recommended to-have features. To achieve this task, we propose an extension to the current WSDL design such that it provides the necessary information that improves the discovery process and therefore rendering an effective selection process.
customizable set of objects within UDDI service registries. Extending WSDL interfaces will give more flexibility to service providers in terms of updating service information. In addition, extending WSDL files will enable clients to effectively perform a simple verification process (i.e. provide MobiEureka with a WSDL location) prior to service invocation, and therefore, reducing the overhead when compared to looking for this information on service registries (i.e. contact the UDDI, performing a query, locating a service, retrieving tModels, and then verifying device compatibility). WSDL-M does not only enable service providers to have a greater level of flexibility and usage analysis when providing interaction information, it also enables clients to effectively verify that services are compatible with their mobile devices prior to any service invocation. To illustrate how WSDL-M works, we use the following example: StockTrad Inc. offers a monthly subscription for $39.00 for a mobile service called “StockInfo” which provides real-time streaming quotes, charts, historical prices, and latest stock news. StockTrad’s mobile services are all WAP browser-based, that is, they are developed using Wireless Markup Language (WML). John is a financial advisor who follows stock information and wishes to subscribe to a service that can provide real-time stock information, as well as charts. John locates StockTrad’s “StockInfo” and wishes to subscribe to this mobile service. Assuming that John has already subscribed to the service and paid for its monthly subscription, he would then begin using the service. John attempts to view the chart information for a specific stock but then realizes that no stock charts are appearing on his WAP browser. John keeps on trying different stock symbols and attempts to view the real-time charts, but his mobile device would not display any graphics. As shown on Figure 5, John’s mobile device BrowserUA information indicates that the CCPPAccept only supports textual content type “text/plain” or WML MIME type, and therefore, his WAP browser does not support wireless bitmaps or “image/vnd.wap.wbmp” MIME type. John in this example has paid for a service that is not completely usable on his mobile device.
We have designed a device-aware discovery mechanism that extends the current WSDL definition called WSDL-M for WSDLMobile. WSDL-M represents a service definition that does not only contain how to interface with a service, but also any recommended to-have features. Through WSDL-M, clients would not have to worry about finding services that are relevant since the matchmaking or discovery tool used for finding services would be able to then amplify only those that are device compatible. In addition, WSDL-M provides service providers and/or developers to include technical information for multiple device types as well as current versioning information associated with a specific type of mobile devices. The diversity of mobile devices does not necessarily guarantee that services offered by service providers are all compatible and therefore, it is important that service providers provide sufficient information on how mobile devices should interact with their services. In addition, it is critical for mobile clients are able to verify that when invoking specific services their mobile devices are capable of using these services.
Figure 5. Example of Capabilities Identified by MobiEureka
The ability to provide interaction information is best defined within WSDL files. The extension of WSDL files to include information on how clients should interact with services has an advantage over extending technical models (or tModels),
Other interaction problems may also arise in cases when mobile services are classified as native, that is, compiled applications where the device has a runtime environment to execute the applications. StockTrad’s wireless mobile service “StockInfo”
provides the ability to download a MIDlet that can run on the mobile device as shown on Figure 6.
Figure 6. Selective Capabilities Identified Figure 6 shows a JAD file adopted from [17] which requires that CDLC version 1.0 and MIDP version 2.0 to be available on the device in order to download the *.JAR file. Going back to our example, John’s mobile device may not be able to use StockTrad’s MIDlet due to the fact that the SoftwarePlatform’s property AcceptDownloadable Software is set to No. In order for clients to avoid paying for services that are unusable, it would be ideal if there is a mechanism that can verify or only provide services that are compatible with mobile devices. Through WSDL-M, clients will not have to make any assumptions that mobile services may not work properly after an invocation. One way to avoid such situation is to inform clients about any possibilities that the service they are about to invoke may be unusable prior to the invocation of a service. Furthermore, in order to properly return results that are “relevant” to the clients’ needs, service providers must supply technical information in an open and transparent manner. Figure 7 shows an extended WSDL definition that contains compatibility information (similar to CC/PP) such as preferred hardware platforms, software platforms, WAP browsers, and any other processing instructions. The extended WSDL definition in Figure 7 contains a section called “WSDLM”. This section provides information that is supplied by the service provider on how to interact with mobile services. The WSDLM section contains information on the compatible hardware platforms, software platforms, Browser, and PushCharacteristics, for illustration purposes. The information contained within this section can serve as conditions or rules for the MobiEureka when performing
matching process or when filtering search results. In addition, this information can also be used by MobiEureka for verification or emulation purposes as discussed earlier. For instance, Figure 7 shows a PushCharacteristics section that contains information on the MIME media types which can be placed in the message body of WAP Push messages. Such information is be used by MobiEureka as a condition that mobile device can support certain types of WAP Push messages. Other supplied information such as hardware platform properties (i.e. character sets, screen sizes, and others) also provides significant details about the types of mobile devices that can interact with the service.
7. EXPERIMENTS AND RESULTS MobiEureka takes advantage of the data collected using the Web Service Crawler Engine (WSCE) [8,18,20] and stored in the Web Service Storage (WSS) of the WSRB framework [9]. Web services used for this paper are based on actual Web service implementation that are available over the Web and are listed in XMethods.net, XMLLogic, StrikeIron.com, search engines, among others. Through WSCE, we selectively collected 561 Web services from various domains (i.e. have different functionalities) and extended WSDL file to WSDL-M as shown in Figure 7 to include WSDLM section. The WSDLM section included 25 possible features shown in Table 1. The values of these features were randomly generated and take into consideration the differences in the expected values or datatypes. For example, the ScreenPixelsWidth property of the MDP profile can accept double values, while SupportsCallback only accepts Boolean values. The supported device-profile features (represented by tags in Figure 7) are based on features from device-profile standards (i.e. CC/PP, UAProf, etc.). MobiEureka uses a mapping method (via the Feature Extraction component) to map WSDL-M tags to those in device-profiles and vice versa. This provides MobiEureka with a greater level of flexibility in supporting multiple device profile standards. The testing of MobiEureka involved several programs written in the Microsoft VB.NET environment and takes advantage of the HttpBrowserCapabilities object to collect the Microsoft’s Mobile Profile (MDP) information via a built-in HTML or WAP
Figure 7. WSDL-M Example
browsers. The program checks to see whether a connecting device to MobiEureka is an actual mobile device through the IsMobileDevice property. To achieve the ranking, MobiEureka identifies the requesting device capabilities (i.e. device-specific features shown in Table 1), stores such information into the server’s session object, and determines the relationship of each of the determined device capabilities to a particular mobile service using Equation 3. Once each service is examined for all of the twenty five properties, a DaRF value is generated and mobile services with the highest DaRF value is the most relevant, compatible, and desirable to the device, or client.
For example, the first mobile service in Figure 8 is “Email verifier” while the same service using Siemens S45 5.0.2 is ranked third and “StrikeIron Mobile Email” is ranked first as shown in Figure 9. This is due to the fact that MobiEureka discovers that “StrikeIron Mobile Email” mobile service has a higher degree of relevancy and compatibility compared to the “Email verifier” mobile service. In addition, MobiEureka also determines that the Email verifier” mobile service is slightly less compatible than “DOTS Email Validation”. Running the same search query on Openwave V7 Simulator produces different results as shown in Figure 10.
For testing MobiEureka, we used mobile device simulators to demonstrate how it ranks mobile services based on device capabilities, or enabling device-aware mobile services discovery. Figure 8 shows the results from running MobiEureka using Openwave 5.0.2 using OpenWave SDK 5.1.
Figure 10. Results from running MobiEureka search query for “Mail” keyword on Openwave V7 Simulator
Figure 8. Results from running MobiEureka search query for “Mail” keyword on Openwave 5.0.2 Figure 8 shows Openwave’s 5.0.2 mobile device performing a search query using the keyword “Mail” and MobiEureka processes this request and obtains a set of ranked mobile services. Results shown in Figure 8 demonstrate that the most compatible mobile service is “Email Verifier” with the highest DaRF ranking. MobiEureka’s results are based on the device capabilities and their relationship to each of the matching mobile service. However, other mobile devices that are slightly different from Openwave’s 5.0.2 mobile device should yield different ranking of mobile services as in the case with Siemens S45 5.0.2 mobile device using Openwave SDK5.1. Results from running the same search query for the keyword “Mail” on Siemens S45 5.0.2 returns a set of mobile services that are ranked differently from those that were performed using Openwave 5.0.2 as shown in Figure 9.
Figure 9. Results from running MobiEureka search query for “Mail” keyword on Siemens S45 5.0.2
Results obtained from running MobiEureka’s search query for the keyword “mail” on Openwave’s V7 Simulator, as shown in Figure 10, has produced set mobile services that are different from the other previous mobile devices tested earlier. For example, MobiEureka’s DaR determines that “XWebEmailValidation” is more relevant to this device that the other mobile services returned. This is due to the fact that for this specific device, this mobile service match at least 18 devicespecific features (from Table 1) while the second matches 12, and the third only satisfies 8 features. Figures 11 and 12 show a sample output from MobiEureka when performing search query for the keyword “zip” in our MobiEureka DB using Siemens S45 5.0.2 and Openwave 5.0.2, respectively. Using Siemens S45, MobiEureka determines the order of relevant mobile services based on device-specific information contained within WSDL-M documents and collected within the MobiEureka DB. …
US Zip Validator Forecast by ZIP Code StrikeIron ZIP Code Information ZIP Code Given City and State City and State by ZIP ZipCodes Lookup Zip Codes StrikeIron ZIP Code Distance Information
Figure 11. Sample WML output result from MobiEureka using Siemens S45 5.0.2 for keyword “zip”
The use of profile capabilities for mobile services discovery can significantly improve the probability of having relevant and pertinent output results. The proposed solution has shown usefulness of incorporating device capabilities as part of the discovery process and in distinguishing mobile services from one another and that are suitable to work within the constraints of the mobile device. The proposed solution provides an effective mobile service relevancy function, DaRF that is used for ranking and finding most suitable mobile services.
- - - …..
US Zip Validator ZIP Code Given City and State StrikeIron ZIP Code Information City and State by ZIP Forecast by ZIP Code Zip Codes StrikeIron ZIP Code Distance Information ZipCodes Lookup
Figure 12. Sample WML output result from MobiEureka using Openwave 5.0.2 for keyword “zip” Figure 12 demonstrates a sample output result from running the same test but using a different mobile device, the Openwave 5.0.2. As can be seen from Figure 12, mobile service “Forecast by Zip Code” holds the 5th rank using Openwave 5.0.2. However, when using the Siemens S45 it was ranked as the second most relevant mobile service as shown in Figure 11. In addition, mobile service “Zip Code Given City and State” was ranked 4th using Siemens S45 mobile device, but was ranked 2nd using Openwave 5.0.2. To determine the success rate and accuracy of our DaRF ranking a test for precision and recall for three different queries was applied and results are shown in Figure 13. As can be seen in Figure 13, the precision level of MobiEureka decreases as recall increases and at all ranking operations, it keeps retrieving relevant services until it reaches 100% recall, that is having retrieved all relevant services. Results also demonstrate that having a reasonable set of searchable Web service attributes can significantly improve the performance and quality of search results.
Openwave 7.0
Siemens S45 5.0.2
This research was supported in part by the Natural Sciences and Engineering Research Council of Canada (NSERC) Discovery Grant No. 045635.
10. REFERENCES [1] Small, J., Smailagic, A., and Siewiorek, D., “Determining User Location for Context-Aware Computing through the Use of a WirelessLAN Infrastructure”, ICES CMU Report, December 2000.
[2] Kaasinen, E., “User Needs for Location-Aware Mobile Services”, Personal and Ubiquitous Computing, Vol. 7 No.1, pp.70-79, 2003.
[3] Al-Masri, E., and Mahmoud, Q. H., “A context-aware
[4] Lee, G., Bauer, S., Faratin, P., and Wroclawski, J., “Learning User Preferences for Wireless Services Provisioning”, In Proceedings of the Third International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS-04), pp. 480–487, 2004.
100% 80% Precision
9. ACKNOWLEDGMENTS
mobile service discovery and selection mechanism using artificial neural networks”, 8th International conference on Electronic commerce, pp. 594-598, 2006.
Performance of different ranking operations Openwave 5.0.2
For future work, we plan to extend the use of device-specific capabilities in addition to supporting UAProf and CC/PP profiles within the MobiEureka framework. In addition, we are working on differentiating between required and recommended-to-have features and prioritizing the importance of each during the ranking process. We are also working on associating Quality of Service (QoS) metrics [19] about services into our DaRF ranking so that clients are able to fully customize and interact with services which not only are compatible with their mobile devices, but also those that meet their non-functional requirements.
60% 40%
[5] Dragoi, O. A. and Black, J. P., “Discovering services is not
20% 0% 10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Recall
Figure 13. Performance of MobiEureka for three distinct queries
8. CONCLUSION AND FUTURE WORK A device-aware mobile service discovery and ranking has been presented in this paper for the purpose of finding the most suitable mobile service during mobile services’ discovery process. By learning device capabilities, MobiEureka can adapt the discovery of mobile services and rank those that are considered relevant to client’s needs. Data used for device-specific features were collected from available implementations of Web services that are accessible via the Web and used as search constraints in order to have mobile services with accurate ranking.
enough”, Technical Report CS-2004-36, School of Computer Science, University of Waterloo, August 2004.
[6] Roque, R., Soares, T., and Oliveira, J., “VESPER Project – Validation of VHE Concept”, Available http://citeseer.ist.psu.edu/459241.html
online
at:
[7] Lankhorst, M.M., Kranenburg, van H., Salden, A., Peddemors, A., “Enabling Technology for Personalizing Mobile Services”, In Proceedings of the 35th Hawaii International Conference on System Sciences, 2002
[8] Al-Masri, E., and Mahmoud, Q. H., “Crawling Multiple UDDI Business Registries”, the 16th International World Wide Web Conference, pp. 1255-1256, 2007.
[9] Al-Masri, E., and Mahmoud, Q. H., “A Framework for Efficient Discovery of Web Services across Heterogeneous
Registries”, In Proceedings of the IEEE Consumer Communications and Networking Conference (CCNC), pp. 415-419, 2007.
[10] Baudisch L., “Summary Thumbnails: Readable Overviews for Small Screen Web Browsers”, CHI 2005, pp. 681-690, 2005.
[11] Buyukkokten, O., Gracia-Molina, H., Paepcke, and Winograd, T, “Power Browser: Efficient Web Browsing for PDAs”, CHI 2005, pp. 430-437, 2000.
[12] Cserkúti P., Szabó Z., Eppel T., and Pál J., SmartWeb – Web Content Adaptation for Mobile Devices, SAMI 2006.
[13] Adipat, B. and Zhang, D., “Adaptive and Personalized Interfaces for Mobile Web”, In the Proceedings of the 15th Annual Workshop on Information Technologies and Systems (WITS'05), pp.21-26, 2005.
[14] Lum, W. and Lau, F., “User-centric content negotiation for effective adaptation service in mobile computing”, IEEE Transactions on Software Engineering 29, pp.1100-1111, 2003.
[15] Zhang, D. and Adipat, B., “Challenges, methodologies, and issues in the usability testing of mobile applications”, International Journal of Human Computer Interaction 18, pp. 293-308, 2005.
[16] Mahmoud Q.H., Al-Masri E., and Wang Z., “Design and implementation of a smart system for personalization and accurate selection of mobile services”, Requirements Engineering Journal, Vol. 12 No.4, pp. 221-230, 2007.
[17] Mahmoud Q.H., “Learning Wireless Java”, O’Reily, ISBN: 0596002432, 2002
[18] Al-Masri E, and Mahmoud Q.H., “WSCE: A crawler engine for large-scale discovery of web services,” ICWS, pp. 11041111, 2007.
[19] Al-Masri, E., and Mahmoud, Q. H., “QoS-based Discovery and Ranking of Web Services”, ICCCN, pp. 529-534, 2007.
[20] Al-Masri, E., and Mahmoud, Q. H., “Investigating Web
Services on the World Wide Web”, 17th International World Wide Web Conference, To Appear.
