TOWARDS A META-MODEL FOR WEB SERVICES’ PREFERENCES

Zakaria Maamar

, Ghazi Al-Khatib

, Said Elnaffar

and Youcef Baghdadi

Zayed University, Dubai, U.A.E

Princess Sumaya University of Technology, Amman, Jordan

United Arab Emirates University, Al-Ain, U.A.E

Sultan Qaboos University, Muscat, Oman

Keywords:

Membership, Policy, Preference, Privacy, Web service.

Abstract:

This paper presents a meta-model for describing preferences of Web services. Two types of preferences are

examined namely privacy and membership. Privacy restricts the data that Web services exchange, and mem-

bership restricts the peers that Web services interact with. Both types have risen lately with force in response

to the open and dynamic nature of the Internet. While most of the research work on Web services has been

driven by the concerns of users, this paper stresses out the concerns of providers of Web services. Differ-

ent meta-classes like Web service, functionality, and WSDL are included the meta-model for Web services’

preferences. To guarantee the satisfaction of these preferences, policies are developed in this paper.

1 INTRODUCTION

Over the last few years, the research community ex-

amined Web services from different perspectives such

as composition, semantic mediation, and context-

awareness. Recently, a new perspective that empha-

sizes privacy concerns has risen with force in re-

sponse to the open and dynamic nature of the In-

ternet. Web services are expected to handle users’

personal details in compliance with existing privacy

standards (WSP, 2009; W3C, 2003) and public leg-

islations (Commission, 2008). Some countries like

Canada have even set up a dedicated body to imple-

ment and enforce these legislations.

It is worth mentioning that the majority of Web

services R&D projects are user-centric; the priority

is always given to users’ concerns: how to look for

Web services to satisfy a user’s needs, how to person-

alize a Web service with respect to a user’s proﬁle,

how to protect a user from malicious Web services,

how to ease the discovery of Web services as per a

user’s needs, etc. Although it is critical to guaran-

tee user satisfaction towards Web services use, a few

R&D projects look at the other side of the spectrum,

which emphasizes providers’ concerns. Providers

are put on the ﬁrst line of satisfying Web services’

promises (i.e., loosely-coupled application develop-

ment) on top of their regular duties of developing and

maintaining Web services. In the literature, it is al-

ways guaranteed that Web services always accept to

engage in composition scenarios, process users’ re-

quests, and interact with other peers. This should not

always be the case as Web services (in accordance

with their providers’ policies) could reject process-

ing users’ requests due to current high-load or non-

appealing rewards, propose peers with whom they

would like to partner during composition, review their

internal use policies without prior notice, and initi-

ate some sort of negotiation with other peers in or-

der to satisfy the most of their preferences. In (Maa-

mar et al., 2004), we discuss how Web services per-

formance can be restricted because of lack of com-

puting resources upon which these Web services will

run. In this paper, we show how providers set pref-

erences that would let their Web services postpone

or cancel their participations in compositions if their

preferences are not satisﬁed, as well as relax these

preferences if needed. TypeOfPeer and DataQuality

are examples of preferences associated with Web ser-

vices, but additional examples are provided later.

To ease the exercise of modeling preferences of

Web services, we develop in this paper a meta-model

that structures the types of preferences, the relation-

ships (e.g., cause-effects, complementary, etc.) that

could exist between these preferences, the restrictions

that could be put on these preferences, and ﬁnally

the mechanisms that would support (automatically if

possible) the mapping of these preferences onto ex-

113

Maamar Z., Al-Khatib G., Elnaffar S. and Baghdadi Y. (2010).

TOWARDS A META-MODEL FOR WEB SERVICES’ PREFERENCES.

In Proceedings of the 5th International Conference on Software and Data Technologies, pages 113-118

DOI: 10.5220/0002888901130118

 SciTePress

ecutable policies. Such policies will be triggered to

guarantee that Web services’ preferences are satisﬁed

at run-time. The rest of this paper is organized as fol-

lows. Section 2 presents some related work. Section 3

discusses the preferences of Web services. Section 4

introduces the meta-model of these preferences. Fi-

nally, Section 5 concludes the paper.

2 BRIEF LITERATURE REVIEW

In (Benbernou et al., 2007b), Benbernou et al. pro-

pose a privacy-agreement model for Web services.

They point out that despite the increasing number

of privacy policies that businesses advertise, Internet

users are not convinced yet with the way their per-

sonal details are handled and how compliant these

businesses are with these policies. As a result, users

continue to be reluctant to disclose such details. The

privacy-agreementmodel of Benbernou et al. consists

of rights and obligations that can be used to accom-

modate new business strategies and changes in per-

sonal data-related laws and regulations.

In (Xu et al., 2006), Xu et al. mention that pri-

vacy concerns should be handled during the develop-

ment phase of a composite Web service. The num-

ber of people who access the Web continues to grow,

which has exacerbated these concerns. To address

this exacerbation and the Platform for Privacy Prefer-

ences’ (P3P) shortcomings, Xu et al. propose a frame-

work for the development of privacy-conscious com-

posite Web services. When a user provides data to a

Web service, she needs guarantees that these data will

be manipulated in accordance with her privacy pref-

erences. The user can request to check the model of a

Web service so that she can know how this Web ser-

vice processes and shares data. In the framework of

Xu et al., automated techniques check the compliance

of a Web service’s model with a user’s privacy prefer-

ences.

In (Park et al., 2005), Park et al. incorporate

preferences into Web services conversations in or-

der to accommodate users who are on the move

and thus, dependent on wireless network availability

and reliability. Park et al.’s framework called WS-

CPP for Web Services Conversations Preference Pro-

ﬁle deﬁnes documents that include a speciﬁc element

known as preference. This speciﬁc element governs

the interaction behavior of both service provider and

client. A preference may contain zero or more of

the following entities: interactionSkip, choicePrior-

ity, and orderPriority.

In (Carminati, B. and Ferrari, E. and Hung, P.C.

K., 2005), Carminati et al. discuss privacy in the

context of agencies dedicated to Web services discov-

ery. These agencies (e.g., built upon UDDI registries)

need to have access to some Web services’ sensitive

information for various reasons like identifying ap-

propriate Web services with respect to users’ needs.

However, some providers of Web services could be

reluctant to give discovery agencies free access to

these sensitive information.

3 PREFERENCE DEFINITION

Prior to discussing how a Web service controls its par-

ticipations in composition scenarios through prefer-

ences, we show ﬁrst, how to include preferences in

the description of the Web service. To this end, we

decompose this description into two parts: function-

ality and preference. The functionality part consists

of the “service” that the Web service offers to users

and peers for invocation. The preference part con-

sists of concrete types of preferences that the Web

service makes sure of their satisfaction at run-time.

Each preference type is related to a category, which

we denote by either privacy or membership.

3.1 Running Example

Our running example is a university student who

would like to organize a cookout party for his recent

graduation. We identify some potential Web services

that could be in charge of the logistics of this party.

CateringWS: looks for and contacts catering com-

panies according to some criteria like allocated bud-

get, number of expected guests, and type of cuisine.

GuestWS: sends invitees invitations, keeps track

of conﬁrmed invitations, and follows-up on uncon-

ﬁrmed invitations through reminders.

PlaceBookingWS: looks for a place to host the

cookout party, books the place, and completes the

necessary paperwork like payment.

WeatherWS: checks weather forecast for the day

of the cookout party. In case of bad weather, the party

takes place at the student’s place.

3.2 Privacy-based Preferences

In Wikipedia, privacy is “... the ability of an in-

dividual or group to seclude themselves or infor-

mation about themselves and thereby reveal them-

selves selectively. The boundaries and content

of what is considered private differ among cul-

tures and individuals, but share basic common

themes...” (en.wikipedia.org/wiki/Privacy). Privacy are

ICSOFT 2010 - 5th International Conference on Software and Data Technologies

114

related to different themes such as data, ﬁnancial, In-

ternet, and political.

Research on privacy through the P3P and Enter-

prise Privacy Authorization Language (EPAL) ini-

tiatives is still conﬁned to user-Web site interac-

tions (Benbernou et al., 2007a). A user needs to know

among other things why she submitted her credit card

number to a Web site, how long this Web site will

retain this number, and how she could verify that this

number was effectivelydeleted as the Web site claims.

In the following, we brieﬂy go over P3P and EPAL.

P3P: In (Hua Li et al., 2006), Hua Li et al. pro-

vide a concise summary of P3P, which we adopt in

this paper. XML-based P3P is the most signiﬁcant ef-

fort that gives Internet users the opportunity to gain

control over their personal details. A privacy policy

in P3P is a set of statements. Each statement has four

different components: data group, purpose, recipient,

and retention.

EPAL: It “... is a formal language for writing

enterprise privacy policies to govern data handling

practices in IT systems according to ﬁne-grained pos-

itive and negative authorization rights” (EPAL’s Web

site). An EPAL policy deﬁnes (i) lists of hierarchies

of data-categories, user-categories, and purposes, and

(ii) sets of (privacy) actions, obligations, and condi-

tions.

The above initiatives/standards are user-centric;

the data collected concern users, only. In the fol-

lowing, we discuss privacy-based preferences from

the perspective of a provider that would like to have

control over the data that its Web service manipu-

lates. These data are part of the business logic that

underpins the functioning of the Web service. First of

all, we identify some privacy-based preference types

that apply to Web services and then, show if any

correspondence exists between these types and P3P

or EPAL components.

1. DataSource: a Web service speciﬁes a list of di-

rect peers (i.e., other Web services) from which it

accepts input data without for example checking

their credentials (Li et al., 2007).

2. DataDestination: a Web service speciﬁes a list

of direct peers for which it forwards output data

without for example checking their credentials (Li

et al., 2007).

3. DataRetentionPeriodAtDestination: a Web ser-

vice sets an appropriate duration for direct desti-

nation peers to retain its output data whether these

data are updated or not at the destination level.

When this duration elapses, the data should be ei-

ther deleted or forwarded as long as the privacy-

based preferences of the sender and destination

peers are satisﬁed. It is expected that the recipi-

ent Web services to a Web service announce their

respective DataRetentionPeriodAtReception pref-

erences as a counter-part of the DataRetentionPe-

riodAtDestination preference of this Web service.

4. DataDisclosureDistance: a Web service sets the

maximum distance for its data to be disclosed (or

forwarded) from one peer to another without seek-

ing its direct approval. For example, distance 2

would mean the peers that are directly connected

to a Web service and the next direct peers that

are connected to these peers. In any case, the

peers have to take into account their own Data-

Source/DataDestination preferences prior to re-

ceiving/forwarding data. It is expected that the

recipient Web services to a Web service announce

their respective DataDisclosureDistance prefer-

ences in response to the DataDisclosureDistance

preference of this Web service.

Table 1 suggests correspondences between our

proposed types of privacy-based preferences and P3P

and EPAL components. In the list of privacy types

(column #2), DataDestination and DataRetentionPe-

riodAtDestination preferences have direct counterpart

components in P3P and EPAL. The rest of prefer-

ences do not have because of their speciﬁc role in

composition scenarios. DataSource focusses on the

previous component Web services, and DataDisclo-

sureDistance focusses on the next component Web

services. It would be appropriate to add these two

privacy-based preference types to P3P and EPAL for

the following reasons:

1. A Web site could submit a user’s details to other

Web sites without the knowledge/approval of the

user; this could be prevented through DataDisclo-

sureDistance;

2. And, a Web site could use details from other Web

sites to satisfy a user’s request without the knowl-

edge/approval of the user; this could be prevented

through DataSource.

Example. We instantiate the proposed privacy-

based preference types using PlaceBookingWS.

• DataSource: null.

• DataDestination: GuestWS.

• DataRetentionPeriodAtDestination: up to

1 month from date of receipt.

• DataDisclosureDistance: 2 – CateringWS could

receive data of PlaceBookingWS from GuestWS

without the approval of PlaceBookingWS.

TOWARDS A META-MODEL FOR WEB SERVICES' PREFERENCES

115

Table 1: Privacy preference correspondences.

# Proposed privacy type P3P component EPAL component

1 DataSource null null

2 DataDestination Recipient User categories

3 DataRetentionPeriodAtDestination Retention Obligations

4 DataDisclosureDistance null null

3.3 Membership-based Preferences

Membership-based preferences reinforce the capac-

ity of a Web service to control its participations in

composition scenarios. By accepting to engage in

these scenarios, a Web service puts some restrictions

on its engagement by using preferences. Similarly

with privacy-based preferences, we identify some

membership-basedpreference types that apply to Web

services and then, show if any correspondence exists

between these types and P3P or EPAL components.

1. ParticipationDuration: because Web services can

engage in long-running composition scenarios

that sometimes last days and even weeks (Little,

2003), a Web service could set the maximum du-

ration it would remain committed to a certain sce-

nario whether the performanceof this Web service

is ﬁnished or not. ParticipationDuration gives a

Web service the possibility to automatically dis-

engage from composition scenarios that last more

than expected and engage in other compositions

if such opportunities arise. It would also allow a

Web service to stipulate another pricing model, if

it decides to relax this membership preference.

2. InvocationPeriod: to maintain a certain level of

QoS (Sun et al., 2007), a Web service could set

different time periods (e.g., off peak, peak) to re-

ceive and process execution requests. These pe-

riods could be driven by factors like service level

agreements, business hours, computing resource

availabilities, etc.

3. PaymentMode: in return to processing users’ re-

quests, a Web service could be ﬁnancially com-

pensated either instantly after satisfying these re-

quests or deferred until the successful completion

of the composition scenario in which this Web

service takes part now. In case of composition-

scenario failure, a Web service could request can-

celation fees on top of the regular fees that it

charges

. However, if a Web service is faulty, then

it will bear ﬁnancial penalties (when applicable).

4. BlackListedPeers: it is a list of Web services that

a Web service does not wish to deal with them di-

Cancelation fees are applicable when a Web service

that has completed its execution, needs now to cancel or

compensate this execution.

rectly, or even if they exist as part of a composi-

tion scenario. For example, a Web service does

not wish to deal with those Web services that may

degrade its QoS or threaten its privacy or security

measures.

5. FavoredPeers: this allows a Web service to se-

lectively choose to favor the participation in one

composition over the other due to the existence of

good peers. This preference may stem from the

positive experience with those favored Web ser-

vices.

Table 2 suggests correspondences between

our membership-based preference types and P3P

and EPAL components. In the list of membership

types (column #2), ParticipationDuration, Favored-

Peers, and BlackListedPeers have “Retention”,

“Recipient”, and “Recipient” P3P parameters as

counterparts. From a user perspective, “Retention”

component could mean the maximum time-period

that a user would be willing to spend interacting with

a Web site. If a user has to complete a 15 minute

survey while her next meeting is in less than 10 min-

utes, the Web site could be informed about the user’s

availability so that appropriate actions are taken.

“Recipient” component could mean both the Web

sites that a user would like to visit and not to visit. In

EPAL, “Obligations” component could be associated

with ParticipationDuration and “User categories”

component could be associated with FavoredPeers

and BlackListedPeers. From a user perspective,

“Obligations” component could refer to the actions

to take when the user decides to disengage from

an interactive session without prior notice. And,

“User categories” component could refer both to

the Web sites that a user would like to visit and

not to visit. Finally, it would appropriate to add

InvocationPeriod to both P3P and EPAL for a better

access management to Web sites.

Example. We instantiate the proposed

membership-based preference types using Cater-

ingWS.

• ParticipationDuration: 48 hours – if the execu-

tion of the cookout-party composition lasts more

than forty eight hours, CateringWS will automat-

ically disengage itself from this composition. A

remedy to this “expected” disengagement needs

ICSOFT 2010 - 5th International Conference on Software and Data Technologies

116

Table 2: Membership correspondence arguments.

# Proposed membership type P3P component EPAL component

1 ParticipationDuration Retention Obligations

2 InvocationPeriod null null

3 PaymentMode null null

4 BlackListedPeers Recipient null

5 FavoredPeers Recipient User categories

to be planned by the composition designer for

instance negotiating a longer engagement period

with CateringWS.

• InvocationPeriod: null.

• PaymentMode: deferred – CateringWS expects

payment after the whole composition is com-

pleted with success. In case of failure that re-

quires cancelation, CateringWS will charge addi-

tional fees.

• BlackListedPeers: null.

• FavoredPeers: PlaceBookingWS – CateringWS

has an excellent experience dealing with Place-

BookingWS.

4 META-MODELING

We propose a meta-model to describe Web services’

preferences and then show how this meta-model is

used to generate policies that guarantee these prefer-

ences satisfaction at run-time.

4.1 Proposed Meta-model

As Jegadeesan and Balasubramaniam report in (Je-

gadeesan and Balasubramaniam, 2009), the goal of

a meta-model is to have a minimum number of el-

ements with maximum expressivity, and reduce the

representational gap for domain experts to use it. Our

meta-model for Web services’ preferences is repre-

sented in Figure 1 and consists of the following meta-

classes: Web Service, Functionality, WSDL, Prefer-

ence, Privacy, Membership, Value, Single (Value),

and Multi (Value).

• A Web service is associated with a WSDL docu-

ment that is used among other things to identify

the functionality and preferences of the Web ser-

vice.

• A preference is identiﬁed with a name of type

String and a priority level of type Integer. This

priority level is a non-negative integer that shows

how strictly a preference should be satisﬁed. Zero

priority is the most restrictive level, which means

that satisfying this preference is mandatory. High

levels suggest that the preference is optional yet

prioritized according to its level; the higher the

level is the less important it is).

• A preference is specialized into privacy and mem-

bership types.

• A preference’s value could be either single

(e.g., DataRetentionPeriodAtDestination of type

Integer) or multiple (e.g., FavoredPeers of type

List of Peers). This is represented through the

value class.

• All peers that a Web service interact with are of

type Web service.

4.2 Policy Deﬁnition

Following the deﬁnition of a meta-model of prefer-

ences for Web services in Figure 1, we move now to

the generation of policies that guarantee the satisfac-

tion of these preferences at run time. We start by de-

veloping an XML schema of this meta-model. After-

wards, we instantiate this XML schema to illustrate

some concrete Web services’ preferences. This also

allows generating policies, which can be done using

XQuery or XPath. Examples of queries that could be

run over the XML model include: Query

: List the

priority for the payment mode preference for a given

WS, Query

: List the names of preferences who has

a positive priority, and Query

: List the peers for the

data source preference

5 SUMMARY

We presented our work on meta-modeling the pref-

erences of Web services. The objective is to iden-

tify which preferences could be associated with Web

services and how to structure these preferences in

terms of type, relationship, and restrictions. Two

types of preferences have been examined namely

privacy and membership. On the one hand, pri-

vacy restricts the exchange of data between Web ser-

vices. This happens using different arguments such

as DataSource, DataDestination, DataRetentionPeri-

odAtDestination, and DataDisclosureDistance. On

the other hand, membership restricts the interactions

between Web services. This happens using different

TOWARDS A META-MODEL FOR WEB SERVICES' PREFERENCES

117

1

describes

1

Web service

WSDL

1

Functionality

1..*

Preference

name: String

priority: Integer

MembershipPrivacy

1..* has 1

Value

Multiple

Single

value: String

1..*

1

a set of

peers

Figure 1: Meta-model for Web services’ preferences.

arguments such as BlackListedPeers, PaymentMode,

InvocationPeriod, and ParticipationDuration.

REFERENCES

Benbernou, S., Meziane, H., and Hacid, M.-S. (2007a).

Run-time monitoring for privacy-agreement compli-

ance. In Proceedings of the Fifth International

Conference on Service-Oriented Computing (IC-

SOC’2007).

Benbernou, S., Meziane, H., Li, Y. H., and S., H. M.

(2007b). A Privacy Agreement Model for Web Ser-

vices. In Proceedings of the 2007 IEEE International

Conference on Services Computing (SCC’2007), Salt

Lake City, Utah, USA.

Carminati, B. and Ferrari, E. and Hung, P.C. K. (2005).

Web service composition: A security perspective. In

Proceedings of the International Workshop on Chal-

lenges in Web Information Retrieval and Integra-

tion (WIRI’2005) in conjunction with the 21st Interna-

tional Conference on Data Engineering (ICDE’2005),

Tokyo, Japan.

Commission, F. T. (Accessed December 15, 2008). Fair

Information Practice Principles, Privacy Online: A

report to Congress (Part II). Technical report,

http://www.ftc.gov/reports/privacy3/fairinfo.htm.

Hua Li, Y., Benbernou, S., Paik, H.-Y., and Benattal-

lah, B. (2006). Formal Consistency Veriﬁcation Be-

tween BPEL process and Privacy Policy. In Pro-

ceedings of the Privacy, Security, and Trust Confer-

ence (PST’2006), Toronto, Canada.

Jegadeesan, H. and Balasubramaniam, S. (2009). A Model-

drievn Approach to Service Policies. Journal of Ob-

ject Technology, 8(2).

Li, Z., Su, S., and Yang, F. (2007). WSrep: A Novel Rep-

utation Model for Web Services Selection. In Pro-

ceedings of the First KES International Symposium

on Agent and Multi-Agent Systems: Technologies and

Applications (KES-AMSTA’2007), Wroclaw, Poland.

Little, M. (2003). Transactions and Web Services. Commu-

nications of the ACM, 46(10).

Maamar, Z., Sheng, Q. Z., and Benatallah, B. (2004). On

Composite Web Services Provisioning in an Environ-

ment of Fixed and Mobile Computing Resources. In-

formation Technology and Management Journal, Spe-

cial Issue on Workﬂow and e-Business, Kluwer Aca-

demic Publishers, 5(3).

Park, J., Lee, W., and Lee, K. (2005). Incorporating Pref-

erences into Web Service Conversations. In Proceed-

ings of the 14th International World Wide Web Con-

ference (WWW’2005), Chiba, Japan.

Sun, Y., He, S., and Leu, J. Y. (2007). Syndicating Web

Services: A QoS and User-driven Approach. Decision

Support Systems, 43(1).

W3C (2003). Platform for Privacy Preferences (P3P)

Project. http://www.w3.org/P3P/.

WSP (2009). Web Service Privacy. http://www.service

oriented.org/ws-privacy.html.

Xu, W., Venkatakrishnan, V. N., Sekar, R., and Ramakrish-

nan, I. V. (2006). A Framework for Building Privacy-

Conscious Composite Web Services. In Proceedings

of the 2006 IEEE International Conference on Web

Services (ICWS’2006), Chicago, Illinois, USA.

ICSOFT 2010 - 5th International Conference on Software and Data Technologies

118