Ad-Hoc Collaboration Between Messengers: Operations and Incentives Zakaria Maamar

Qusay H. Mahmoud

Abdelouahid Derhab

Wathiq Mansoor

Zayed University, U.A.E

University of Guelph, Canada

CERIST, Algeria

Zayed University, U.A.E

[email protected]

[email protected]

[email protected]

[email protected]

Abstract This paper discusses how ad-hoc collaboration boosts the operation of a set of messengers. This discussion continues the research we earlier initiated in the MESSEN GER project, which develops data management mechanisms for UDDI registries of Web services using mobile users and software agents. In the current operation mode of messengers, descriptions of Web services are first, collected from UDDI registries and later on, distributed to other UDDI registries. This distribution mode of Web services descriptions does not foster the tremendous opportunities that both wireless technologies and mobile devices offer. When mobile devices are in the vicinity of each other, they can form a mobile ad-hoc network, which enables the exchange of data between these devices without any preexisting communication infrastructure. By authorizing messengers to engage in collaboration, collecting additional descriptions of Web services from other messengers can happen, too. Keywords. Web service, UDDI, Ad-hoc, Collaboration.

1. Introduction In [10], we described our MESSEN GER project that aims at developing mechanisms for supporting data management among a set of distributed UDDI registries. Unlike other initiatives on Web services, this project’s concerns are as follows: several UDDI registries are deployed, there is no pre-defined communication infrastructure between the UDDI registries (although a wireless infrastructure was privileged), and absence of a central component for coordinating the UDDI registries. The MESSEN GER project’s proposal is to integrate users and software agents [1] into what we refer to as messengers. Initially, software agents reside in users’ mobile devices (i.e., handheld) and cache the descriptions of the Web services that satisfied the needs of these users. Whenever a user is in the vicinity of an UDDI registry her software agent interacts with that UDDI registry, so details stored in her mobile device on the used Web services are submitted. These details feed the content of the UDDI registries. Hereafter data and details mean the description of a Web service.

Web services are among the technologies that help organizations connect their business processes to other peers’ processes [8]. In a typical Web services scenario, a UDDI registry performs two operations. The first operation is about receiving the announcements of Web services (also called services in the rest of this paper) from providers. And the second operation is about searching the UDDI registry for the services that satisfy users’ needs. However, since the providers’ announcements of services are submitted to separate UDDI registries, this results in a different content among them. The development of mechanisms to support the exchange of content among UDDI registries is required. Targeting the data management challenge of several UDDI registries has some similarities with the challenge of data replication in a distributed environment. An immediate proposal to achieve data management of separate UDDI registries is to flood the communication infrastructure with the new content of any UDDI registry that has lately been subject to changes. Changes in UDDI registries may become frequent as the number of announced Web services continues to grow [13]. Though the flooding solution fits quite well a wired configuration, the lack of a reliable and permanent connection in a wireless configuration, as is in the MESSEN GER project, is an obstacle to this solution. In the current operation mode of messengers [10], descriptions of Web services are first, collected from UDDI registries and later on, distributed to other UDDI registries subject to satisfying multiple policies (Section 2.2). This distribution mode of Web services descriptions does not foster the tremendous opportunities that both wireless technologies and mobile devices offer [2]. For instance, when mobile devices are in the vicinity of each other (i.e., reachable), they can on the spot form a mobile ad-hoc network (i.e., non-planned), which enables the exchange of data between these devices without any preexisting communication infrastructure. In such a network devices serve as routers for others, which permits data to flow from one device to another according to a specific routing protocol [5]. In this paper we discuss the way ad-hoc collaboration between messengers happens and the way this collaboration is integrated into the operation of messengers. By authorizing

messengers to engage their peers in collaboration situations, the exchange of data among UDDI registries is boosted. This not only allows collecting descriptions of Web services from UDDI registries as it is currently happening [10], but also permits collecting additional descriptions of Web services from other messengers. This way of doing has several advantages, but at the same time arises various issues, which in fact highlight the complexity introduced by the dynamic and volatile nature of ad-hoc networks. Section 2 presents the MESSEN GER project. Section 3 describes the ad-hoc collaboration among messengers. Section 4 presents how messengers are rewarded in ad-hoc collaboration sessions. Prior to concluding in Section 7, some simulation results and related research projects are discussed in Section 5 and Section 6, respectively.

2. The MESSEN GER project 2.1. Background In the MESSEN GER project, each UDDI registry is part of a structure known as cluster of Web services. Several clusters exist across the communication infrastructure, so providers of Web services can connect to the most appropriate cluster using criteria like proximity and bandwidth. The connection between providers and clusters is of type wired (could be of type wireless, too). For tracking purposes a provider only connects to a single cluster. Thus, it cannot announce its services in multiple UDDI registries. The cluster on which a provider posts its Web services for the first time is known as master. Interesting are the situations where providers have similar Web services but announce them in distinct UDDI registries, respectively. Unless some mechanisms are developed, an UDDI registry would never be aware of the existence of similar services in other UDDI registries. Furthermore, for a user wishing to satisfy her needs by triggering services, she should be given the opportunity to use the existing Web services regardless of where they are advertised. Web services similarity is given in [9]. While residing in the user’s mobile device, her software agent caches the descriptions of the Web services that served for satisfying the needs of this user. Later on and acting on behalf of providers, users announce the Web services in various UDDI registries to be now associated with clusters referred to as slaves. Because users are equipped with mobile devices, mobile support stations manage these devices by identifying their physical location, handling their incoming/outgoing messages/calls, etc. A mobile support station communicates with mobile users within its radio coverage area called wireless cell. When a user enters a new cell (i.e., she is now under the coverage of a new mobile support station), an exchange of details happens between the agent of the user and the UDDI registry. This exchange is about updating the UDDI registry content ac-

cording to various scenarios described in [10]. Because a UDDI registry receives descriptions of Web services from two sources (providers of Web services and software agents of users), the services are classified as internal and external. Internal services are announced in an UDDI registry of a master cluster (providers do the announcements). External services are always announced in an UDDI registry of a slave cluster (agents do the announcements).

2.2. Messengers in action The agentification of the data management of UDDI registries resulted in three types of software agents (Fig. 1): provider-agent, UDDI-agent, and user-agent. Usually, the coverage areas (represented by circles in Fig. 1) of the mobile support stations overlap. However, to keep the figure clear the overlapping is not represented. Since the clusters of Web services are wirelessly connected, a continuous and reliable exchange of the content of the different UDDI registries is to a certain extent difficult to guarantee. Fig. 1 also depicts the notion of messenger: (user,user-agent) on the move. Users with their mobile devices are always under the management of a particular mobile support station. Whenever a user moves to a new place, which is outside the coverage area of a mobile support station, a handover occurs between this station and the new mobile support station that is responsible for this new place. A provider-agent identifies a provider (i.e., a business) that posts its Web services on the UDDI registries of the multiple clusters. However, a provider is only authorized to connect to one cluster of type master. The services announced in the UDDI registry of a master cluster are labelled as internal. This type of labelling helps (i) identify the UDDI registry where the services are announced for the first time, (ii) know the identity of the providers to whom the services belong in case this identity can be revealed, (iii) deny attempts of user-agents to update the descriptions of services, and (vi) name the UDDI-agent that guarantees the execution parameters of the services (e.g., execution cost, availability rate) during execution. Since a provider only announces its Web services in one UDDI registry, messengers take care of the UDDI registries of the remaining clusters of type slave. For announcement purposes in slave clusters, the messengers ought to bind to various policies [10]. The services posted on the UDDI registry of a slave cluster are labelled as external. This type of labelling helps (i) indicate that a third entity (i.e., a certain messenger) has announced the services, (ii) inform that the services can always be subject to unpredicted changes at the level of their respective providers, and (iii) state that the UDDI-agent cannot guarantee the execution parameters (e.g., execution cost, response time) of the services. Because users are engaged in announcing external Web services, the agreement of the respective providers of these Web services is required. For different reasons such as pri-

Cluster 1 of Web services

user +

Cluster 2 of Web services

user +

+ user

Retrievals Announcements

n An

Messenger

An

nts

no

me

ce

n ou

UDDI

+ user

Retrievals Announcements

+ user

un

1

cem

Messenger

en ts

no

me

ce

n ou

UDDI

n An

Web services

An

nts

+ user

2

un

cem

en

ts

Web services

Legend provider-agent

UDDI-agent

User-agent

Mobile support station

Wired connection

Wireless connection

Figure 1. Architecture of the MESSEN GER approach

if then

trustworthiness: user agent:

(provider agenti , uddi registryj ) < 0.5 not(announce(web service, in(uddi registryj )))

Rule description. provider-agenti forbids to any user-agent to announce its Web services in UDDI-registryj , if the trustworthiness value between this provider and this UDDI registry is less than 0.5. Trustworthiness calculation. The trustworthiness of a provider of Web services towards an UDDI registry is defined by the number of times an UDDI registry suggests with success external services of a provider (announced as internal services in other UDDI registries) to be involved in composition vs. the number of composition processes that are devised to satisfy users’ needs (by success, it is meant services being triggered). We recall that a UDDI-agent does not have full control over the external services. It may happen that a service is announced in a UDDI registry of a slave cluster, but its provider has pulled the service out for maintenance. Figure 2. Example of a provider-defined policy

vacy (e.g., a provider does not want to announce all its services in a certain UDDI registry) and trustworthiness (e.g., a provider is not confident in the security mechanisms of a certain UDDI registry), a provider clearly states in the description of a Web service whether this Web service can be announced in the UDDI registries of slave clusters. These statements of a provider are done through a set of policies. The statements are intended to the messengers that will roam the different clusters. It should be noted that all Web services of a provider have to be posted on at least one cluster of type master. Fig. 2 is an example of a providerdefined trustworthiness policy. A user-agent resides in a mobile device (e.g., cell-phone) of a user constituting both a messenger. The main duty of a user-agent is to satisfy its user’s needs (e.g., car rental) after identifying and selecting the relevant Web services with the help of an UDDI registry. To this purpose, the user-agent initiates interactions with the UDDI-agent of an UDDI registry. The selection of a specific UDDI registry is dependent on the current location of the user with regard to the mobile support station that manages her mobile device. Once the services are identified and triggered for execution, the useragent caches in the user’s mobile device various details like the identifier of the services, the UDDI registry with whom the user-agent has dealt with in order to obtain the services, and the providers of services and their location according

to the master clusters. These details can be potentially announced to distinct UDDI registries of slave clusters for further processing upon verification of the announcements’ authorization policies (Fig. 2).

3. Messengers in ad-hoc collaboration According to Ishibashi and Boutaba [6], mobile devices in a mobile ad-hoc network have a different role than in a conventional local-area network. In this network type, communications are centered around base stations. The infrastructure up to a base station is mostly fixed, so the topology is stable. In an ad-hoc network, mobile devices act not only as end-systems but also as routing components. In this part of the paper, we look into the value-added of motivating messengers to engage in ad-hoc collaboration with peers.

3.1. Motives and challenges The mutual awareness of distant messengers supports the emergence of an ad-hoc network upon which mechanisms for conducting collaboration between these messengers can operate. As a prerequisite to this collaboration, we assume first, that messengers have the necessary authorizations to collaborate of their respective users and second, that messengers are in the vicinity of each other. Currently routes of users and announcement policies limit the messengers in their exchange of service descriptions with UDDI registries [10]. This exchange will be boosted by allowing mes-

sengers to collect additional descriptions from their peers so they can distribute these descriptions to other UDDI registries. Prior to take part in any ad-hoc collaboration, we assume that a messenger has already exchanged descriptions of Web services with at least one UDDI registry. In Fig. 1, the current scenario to manage data among distributed UDDI registries highlights a messenger that conveys data on behalf of a single provider. The scenario that is targeted through the ad-hoc collaboration is to enable messengers to convey data on behalf of several providers at a time. In Fig. 3, messengers1,2,3 are in close proximity and agree on establishing an ad-hoc network. After exchanging data to be detailed in Section 3.2, each messenger possesses extra descriptions of Web services that it has obtained from the other two messengers. During the lifetime of an ad-hoc network, messengers may move around within the network, altering the topology by setting or breaking links between devices. In addition, messengers may also enter or leave the ad-hoc network. Messenger1

Messenger2

+ user 1

user 2 + Ad-hoc network

Cluster 1 UDDI Web services

Cluster 2 + user 3 Messenger3

UDDI Web services

Legend UDDI-agent

User-agent

Service desciption exchange

Announcement

Figure 3. Messengers in ad-hoc collaboration

An ad-hoc collaboration session between messengers should satisfy various criteria like transparency (network configuration should not be a burden on users), autonomy (users’ decisions to join or withdraw from a network should not be motivated), and efficiency (data exchange over a network should not slow users’ devices). Prior to setting up this collaboration, multiple aspects need to be investigated: What are the mechanisms that need to embed mobile devices of users, so messengers can detect the opportunity of collaborating independently of the opportunity of detecting their proximity? What are the steps that messengers perform once they agree on collaborating, what are the steps to conduct in order to join/leave an existing ad-hoc collaboration session of messengers without disrupting this session, and what are the incentives for joining such a session and sharing descriptions of Web services with peers? Is there a need to distinguish between the description of a Web service that is directly submitted to UDDI registries and the description of a Web service that is indirectly submitted to UDDI registries through multiple messengers?

How to control/limit the number of messengers in an adhoc collaboration session, what are the reasons of this control, and how to avoid overloading messengers according to their computing and storage capacities? What are the benefits in terms of performance and efficiency that ad-hoc collaboration caters to the flow of service descriptions between messengers and UDDI registries?

3.2. Scenarios during ad-hoc collaboration In [10], we detailed the description of a Web service that is stored in a user’s mobile device and has the following content: service identifier, UDDI-registry identifier with regard to the master cluster where the service is announced as internal (this is required for invocation purposes), outcomes of announcement policies (e.g., list of UDDI registries wherein a service cannot be announced), and extra details for service selection purposes (e.g., efficiency, reliability). The description of a Web service that a user-agent caches in a mobile device is specified in XHTML. Besides the current content of a Web service description, two extra details are appended to this content. The first details is a timestamp that permits to distinguish old from recent descriptions. The timestamp changes each time a Web service description is updated by the provider. The second detail is a description-path that permits listing the messengers from which a particular Web service description has been collected. The description-path has a role in rewarding messengers (Section 4). Different description-paths may be associated with the same Web service, but only one copy of this description is stored by each UDDI registry and each messenger. To achieve this, we choose to store the Web service whose description-path has the largest number of messengers. In doing so, we encourage messengers to engage in ad-hoc collaborations, so they can increase their rewards. Ad-hoc collaboration between a set of cooperative messengers1 sheds the light on four scenarios that are separately approached because of the challenges each scenario poses and the operation mechanisms each scenario requires. In the following we assume that messengeri and messengerj engage in ad-hoc collaboration. Scenario 1. Both messengeri and messengerj have different descriptions of Web services, respectively. The adhoc collaboration has a positive impact on both messengers. They can now collect descriptions on new Web services. Each messenger reports the source, using the descriptionpath, from which it obtained the additional descriptions of Web services. Enriched with these descriptions, both messengers terminate the communication session and resume announcing these descriptions to other UDDI registries or exchanging these descriptions with other peers. 1 Messengers neither intend exchanging misleading descriptions of Web services nor attempt altering the descriptions of Web services of their peers.

Provider

UDDI registry 1

Messenger1

UDDI registry 2

Messenger2

WS posted WS WS description collected WS execution request submitted

Partial reward assigned Later on WS posted WS

WS description collected

WS execution request submitted Partial reward assigned Final reward assigned

Figure 4. Reward management in scenario 1

Scenario 2. Messengeri has descriptions of Web services that are not available at the level of messengerj . The ad-hoc collaboration has a positive impact on messengerj . Messengerj can now collect descriptions on new services, which were not included in its initial list of Web services. In the description of any extra Web service, messengerj indicates messengeri as the source of this description. Enriched with the descriptions of the new Web services, messengerj terminates its communication session with messengeri and starts announcing this description to other UDDI registries or exchanging these descriptions with other peers. Scenario 3. Messengeri and messengerj have similar descriptions of the same Web services. These messengers refrain from pursuing their communication and cancel the ad-hoc collaboration so resource consumption is avoided. This collaboration does not help enhance the descriptions of the Web services of both messengers. Scenario 4. Both messengeri and messengerj have inconsistent descriptions of the same Web services. An example of inconsistency is the execution cost of a Web service. Although a Web service originates from the same provider, a different execution cost is given in each description. A reason of this difference could be the date on which a messenger has collected the description of this Web service from either an UDDI registry or another messenger. As a solution the recent description based on the value of the timestamp is selected, which permits to one of the messengers to update the description of the Web service. When the conflicts are resolved, the rest of Scenario 4 occurs as per Scenario 3. The opportunity of collaboration between messengers is motivated by three elements. First, messengers expose a cooperative attitude through their willingness of sharing descriptions of Web services. Second, users can benefit from extra descriptions that could help satisfy their needs. Finally, providers reward the messengers that helped disseminate information on their Web services (Section 4). Assess-

ing rewards is possible because of the invocation requests of users that providers receive for their Web services. We recall that these requests are used for setting the trustworthiness level of a provider (Fig. 2). Whenever a messenger receives a new description of a Web service from a peer, it adds at the end the identifier of the peer to the description-path. Because a mobile device on which a messenger is running, has a limited storage capacity, some new descriptions cannot be stored. Our proposed solution has two parts. The first part is to discard the descriptions of Web services that do not match users’ interests based on their profile (similarly to relevance functions in [3]). The second part is to remove the descriptions of Web services that are outdated. Because the collaboration between messengers is adhoc, this means that messengers can join and leave the collaborative network without prior notice. Disconnection and exchange interruption are some consequences of these actions. In a join scenario, a messenger might have to wait until it gets the approval from one of the messengers of the ad-hoc collaboration session. In a leave session, all messengers in contact with the departing messenger cancel their interactions with it and discard the descriptions of Web services they received from it.

4. Rewarding messengers In this part of the paper we discuss how messengers get rewarded because of their participation in carrying Web services descriptions using mobile devices to different UDDI registries. The following discussion resolves around the two scenarios that feature the operation of the MESSEN GER approach. The first and second scenarios correspond to Section 2 and Section 3 of this paper, respectively. By reward we mean any incentive that could encourage users to take over the role of messengers. Examples of incentives could be discounts on the execution cost of Web

services, and releases of restricted information on a Web service like successful/failure performance rate. It is the responsibility of a Web service provider to state the form of a reward (e.g., monetary, privilege) that he wishes to adopt. Although the way users and providers manage rewards is important, it is not further discussed in this paper. Scenario 1: single user-based distribution mode. Descriptions of Web services are strictly collected from UDDI registries. The reward process happens in two steps (Fig. 4): 1. If a user accepts posting the description of a Web service on UDDI registries, he gets partially rewarded for this acceptance by the Web service provider. Both user and provider are aware that the the reward is partial. 2. However, because the user could change his decision from acceptance to refusal without notifying the provider (i.e., announcements in other UDDI registries are not to occur as expected), the provider has to make sure that the announcement of the Web service has effectively occurred in at least an UDDI registry of type slave, before the reward gets finally confirmed. The confirmation occurs at the provider level and then notified to the messenger through SMS for example. The question that now arises is how the provider gets to know about the posting of a Web service description on another UDDI registry, and which messengers took care of the posting. This is made possible when the provider receives requests from users for invoking its Web service. A request states that the Web service is labelled as external in this UDDI registry. We recall that this labelling permits indicating for example that a third entity namely a certain messenger has announced the Web services [10]. In addition, a request contains information about the UDDI registry that has provided information on this Web service to the user. Relying on the content of a request, a provider can issue a final reward to a messenger. Scenario 2: multiuser-based distribution mode. Descriptions of Web services are collected from UDDI registries in addition to the descriptions that are collected from messengers (Fig. 5). The first case corresponds to scenario 1. To discuss the second case of scenario 2, let us assume an ad-hoc collaboration network of 3 messengers1,2,3 . Because messengers1,2,3 are already rewarded (regardless of the type whether partial or final) per scenario 1 (both steps successfully completed), they exchange their respective rewards among them. This leads to messengers1,2,3 being all entitled the same rewards. However any extra reward that a messenger collects from a peer is by default considered as partial. Only a provider has the right to turn a partial reward into a final one. The question that now arises is how to get the respective providers of Web services informed about the exchange of partial rewards between messengers1,2,3 , so these rewards can get finally confirmed as per step 2 of scenario 1. Our

response is as follows. When messengers post Web services descriptions on UDDI registries, they state from where they have collected (not an UDDI registry) these descriptions using the description-path of a Web service. When an invocation request of a Web service is submitted to a provider, this latter checks the request as previously described. If the provider is not aware of granting a reward to a messenger (e.g., messenger3 in Fig. 5), it creates a record for that particular messenger. This assumes that the messenger, which is the source of the reward (i.e., messenger1 in Fig. 5), is known to the provider as per successful execution of step 2 of scenario 1. As a result, both messengers (source and submitter) get their rewards completely finalized.

5. Simulation results In this section, we present some simulation results about the performance of the MESSEN GER approach using GloMoSim (Global Mobile Simulator) [14]. The simulation environment sets an area of 1500m×1500m and encompasses 4 mobile support stations and 16 mobile users. Each mobile user randomly selects a cell to whom he moves with a random speed uniformly distributed between 0 and a certain maximum speed Vmax . Then, the user suspends moving for about 30 seconds before resuming his movement to a new cell. The radio coverage area is set to 250m. Each simulation runs for 60 minutes. Initially, 10 descriptions of Web services are posted on each UDDI registry. For performance purposes, we define two metrics: description availability (ratio of the number of Web services descriptions stored in an UDDI registry over the total number of descriptions posted on all UDDI registries), and message overhead (total number of messages exchanged during the simulation). In Fig. 6, we notice that as time progresses, the movement of messengers towards different cells increases the availability of descriptions. Moreover, we notice that permitting ad-hoc collaboration among messengers gives higher description availability than the original operation mode of the MESSEN GER approach. In Fig. 7, as the maximum speed of mobile users increases, the number of exchanged messages increases between messengers and UDDI registries. This is due to the fact that messengers visit cells more frequently. Permitting ad hoc collaboration incurs additional message overhead.

6. Related work Along the line of permitting messengers to set-up adhoc collaboration sessions for data exchange purposes, we suggest in the following some related projects. iClouds (for Information Clouds) is an architecture that supports mobile user interaction, collaboration, and transfer data exchange [4]. The communication range of a user’s wireless device defines a sphere, which highlights to what extent interactions between distant devices could happen.

Ad-hoc collaboration session Provider

UDDI registry 1

Messenger1

Messenger2

Messenger3

UDDI registry 4

Messenger4

WS posted WS WS description collected WS execution request submitted

Partial reward assigned Later on Mutual exchange of WS descriptions Mutual exchange of partial rewards Later on WS posted WS WS description collected WS execution request submitted

Partial reward assigned Final reward assigned Final reward assigned

Final reward notified/if still in vicinity

Figure 5. Reward management in scenario 2

When several devices come close together, they can communicate with each other and exchange information depending on what information users provide and need. This exchange happens automatically and in two different modes known as pull or push. In iClouds it is assumed that all devices are trusted. This feature is similar to the cooperative attitude that messengers exhibit. As a continuation of the iClouds project, the reward element was investigated using an anonymous bonus point system for mobile commerce [12]. This system rewards a user who carries an advertisement on the way down from a vendor to potential buyers. The goal is to distribute digital advertisements with the help of interested consumers following the ”word-ofmouth” recommendation pattern. The vendor grants bonus points to all people in a recommendation chain provided the product in the advertisement is bought. 125 without ad-hoc collaboration with ad-hoc collaboration 120

115

message overhead

110

105

100

95

90

85

80 5

10

15 Vmax

20

25

Figure 7. Diagram showing message overhead

In [7], Kortuem et al. report that wearable computing facilitates a new form of human-computer interaction. Because of various properties associated with wearable devices like running continuously, being aware of their surrounding environments, and being proactive, these devices

are well suited for supporting ad-hoc collaboration in faceto-face situations. Interesting to note that Kortuem et al. identified a set of tasks that need to be executed during the development of ad-hoc collaborative applications. These tasks are as follows: identification of possible collaboration patterns, setting-up and maintaining a collaboration session, and reestablishing past collaboration sessions. A device in an ad-hoc collaboration session has been embedded with the following components: session manager, user manager, capability manager, and neighborhood manager. In [3], Cao et al. developed MOBI-DIC (MOBIle DIscovery of LoCal Resources) platform that is based on local communication in a peer-to-peer network. MOBI-DIC supports exchanging reports among moving objects, where each report is a resource description or discovery query of a resource. Reports are transitively spread across network nodes because of this exchange. Because of the local database of a moving object may continuously increase as new reports are generated, these reports are filtered and prioritized using relevance functions. A project reporting on the deployment of a federated environment of UDDI registries is presented in [11]. An ontology-based approach was used for classifying these registries based on different domains. This enables semantic analysis of users’ requirements to locate the relevant UDDI registries to use in Web services discovery. Three types of UDDI registries were suggested and referred to as private, semi-private, and public, respectively. An advantage of forming federations of registries is to allow businesses to share their data while maintaining their privacy.

7. Conclusion In this paper, we presented the second part of the MESSEN GER project, which is about having messengers

description availability in UDDI 1

description availability in UDDI 2

without ad-hoc collaboration with ad-hoc collaboration

1

0.8 description availability

0.8 description availability

without ad-hoc collaboration with ad-hoc collaboration

1

0.6

0.4

0.2

0.6

0.4

0.2

0

0 0

10

20

30 Time (min)

40

50

60

0

10

description availability in UDDI 3

40

50

60

without ad-hoc collaboration with ad-hoc collaboration

1

0.8 description availability

0.8 description availability

30 Time (min)

description availability in UDDI 4

without ad-hoc collaboration with ad-hoc collaboration

1

20

0.6

0.4

0.2

0.6

0.4

0.2

0

0 0

10

20

30

40

50

60

Time (min)

0

10

20

30

40

50

60

Time (min)

Figure 6. Diagrams showing description availability

engaged in ad-hoc collaboration. The aim of this project is to support the exchange of Web services descriptions among a set of distributed UDDI registries. This exchange happens in two different modes. The single-user based exchange mode resolves around a user who carries descriptions of Web services on behalf of a single provider of Web service [10]. And the multiuser-based exchange mode revolves around user who carries descriptions of Web services on behalf of several providers of Web service at a time. The second exchange mode fosters the multiple opportunities that both wireless technologies and mobile devices offer. When two mobile devices are in the vicinity of each other, they can form a mobile ad-hoc network. This feature has motivated continuing our research on the MESSEN GER project. We, also, discussed in the paper how messengers get reward for their work of distributing Web services descriptions among distributed UDDI registries.

References [1] N. Boudriga and M. Obaidat. Intelligent Agents on the Web: A Review. Computing in Science Engineering, 6(4), JulyAugust 2004. [2] I. Chlamtac, M. Conti, and J. Liu. Mobile Ad Hoc Networking: Imperatives and Challenges. Ad Hoc Networks Journal, Elsevier Science Publisher, 1(1), 2003. [3] C. H., O. Wolfson, B. Xu, and H. Yin. MOBI-DIC: MOBIle DIscovery of loCal Resources in Peer-to-Peer Wireless Network. IEEE Data Engineering Bulletin, 28(3), September 2005. [4] A. Heinemann, J. Kangasharju, F. Lyardet, and M. M¨uhlh¨auser. Ad Hoc Collaboration and Information Services Using Information Clouds, 2003.

[5] Q. Huang. Supporting Context-aware Computing in Ad Hoc Mobile Environments. Technical report, WUCS-02-36, Department of Computer Science and Engineering, Washington University, St. Louis, Missouri, 2002. [6] B. Ishibashi and R. Boutaba. Topology and Mobility Considerations in Mobile Ad Hoc Networks. Ad Hoc Networks Journal, Elsevier Science Publisher, 2005 (in press). [7] G. Kortuem, S. Fickas, and Z. Segall. Architectural Issues in Supporting Ad-hoc Collaboration with Wearable Computers, 2000. [8] K. J. Ma. Web Services: What’s Real and What’s Not. IEEE IT Professional, 7(2), March-April 2005. [9] Z. Maamar, D. Benslimane, C. Ghedira, Q. Mahmoud, and H. Yahyaoui. Tuple Spaces for Self-Coordination of Web Services. In Proc. of The 20th Annual ACM Symposium on Applied Computing (SAC’2005), Santa Fe, USA, 2005. [10] Z. Maamar, H. Yahyaoui, and Q. Mahmoud. Dynamic Management of UDDI Registries in a Wireless Environment of Web Services: Concepts, Architecture, Operation, and Deployment. Journal of Intelligent Information Systems, Springer Verlag, 2005 (forthcoming). [11] K. Sivashnmugam, K. Verma, and A. Sheth. Discovery of Web Services in a Federated Registry Environment. In Proc. of The IEEE International Conference on Web Services (ICWS’2004), San-Diego, California, USA, 2004. [12] T. Straub and A. Heinemann. An anonymous Bonus Point System for Mobile Commerce based on Word-of-Mouth Recommendation, 2004. [13] C. Sun, Y. Lin, and B. Kemme. Comparison of UDDI Registry Replication Strategies. In Proc. of The IEEE International Conference on Web Services (ICWS’2004), SanDiego, California, USA, 2004. [14] X. Zeng, R. Bagrodia, and M. Gerla. GloMoSim: a Library for Parallel Simulation of Large-Scale Wireless Networks. In Proc. of The Twelfth Workshop on Parallel and Distributed Simulation (PADS’1998), Banff, Canada, 1998.