Modeling and Respecting Privacy Specification when Composing DaaS Services*

Modeling and Respecting Privacy Specification when Composing DaaS Services*

Salah-Eddine Tbahriti (Department of Computer Science, Claude Bernard Lyon1 University, Villeurbanne, France), Brahim Medjahed (Department of Computer and Information Science, University of Michigan-Dearborn, Dearborn, MI, USA) and Chirine Ghedira (Magellan Research Laboratory, IAE-Jean Moulin Lyon3 University, Lyon, France)
Copyright: © 2012 |Pages: 21
DOI: 10.4018/jwsr.2012100102
OnDemand PDF Download:
No Current Special Offers


The concept of Web service composition has undergone many evolutions and improvements including especially the apparition of new category of services, on which the composition process is made, called “Data-As-A-Service (DaaS). However, privacy is still among the key challenges that keep hampering DaaS service composition solution. Indeed services may follow different, conflicting privacy specifications with respect to the data they use and provide within a composition. In this paper, the authors propose an approach for privacy- aware composition of DaaS services. The authors’ approach allows verifying the compatibility of privacy specifications of services involved in a composition. In the case when any composition will be incompatible in terms of privacy, the authors introduce a novel approach based on negotiation to reach compatibility of concerned services. The negotiation approach is cautiously operated with without any privacy damaging of services. The authors validate the applicability of their proposal through a set of experiments.
Article Preview

1. Introduction

The concept of DaaS Service Composition becomes an excellent tool to elicit integration of a wealth of information sources and to response complex and personalized queries (Roman Vaculín 2008). It allows organizations to share costs, skills, and resources by enabling remote interactions between their applications and information systems. Simply put, this concept refers to the aggregation and combination of data and/or functionalities to create value-added business processes (i.e., composite applications). While the ability of the Web service composition to integrate heterogeneous data sources and to provide customized information has boosted personal and business productivity, it has raised significant concerns regarding individuals’ and organizations’ privacy. Indeed, despite important efforts aimed at preserving privacy (Fung 2010), privacy leakage incidents on the Web continue to make the headlines. Besides, the emergence of analysis tools makes it easier to analyze and synthesize huge volumes of information, hence increasing the risk of privacy violation. Ensuring the privacy within service composition is more challenging task. Let us illustrate some privacy challenges through the following scenario1.

1.1. Privacy Challenges in Service Composition

We consider the following epidemiologist’s query Q: “What are the ages, genders, zip, DNA and salaries of patients infected with H1N1; and what are the global weather conditions of the areas where these patients reside?” and a subset of services shown in Table 1. To answer this kind of queries, we use a mediator-based approach to compose DaaS services (Mahmoud Barhamgi 2010) in which, a mediator component selects, combines and orchestrates (i.e., gets output data from a service and uses it as input data to call another service) services to answer queries. It also carries out all the inter- actions between composed services (i.e., relays exchanged data among interconnected services in the composition). The result of the composition process is a composition plan (CP), which consists of a set of services that must be executed in a particular order depending on their input and output parameters. Input parameters are identified with a first “$” character and output parameters with a “?”. Hence, service S($a, ?b) requires an input value a and provides an output value b. Thus, the following CP can answer the query Q; CP ={S1.1, S4.1, S2.2, S3, S5.1}. S1.1 is invoked with H1N1, then for each obtained value of SSN, the services S4.1, S2.2 and S3 are invoked to obtain the corresponding values of DNA, DoB (i.e., date-of-birth), Zip and salary. Finally, S5.1 is invoked with the patients’ Zip to get information about the weather-conditions (note that other CP can be found with the services of Table 1).

Table 1.
Web services subset
DaaS ServicesSemantics Services Description
S1.1 ($x, ?s)
S1.2 ($x, ?s)
Returns “SSN” of patient infected with a disease= “x
S2.1 ($s, ?d, ?g)
S2.2 ($s, ?d, ?g)
Returns d =“DoB”, and g =“gender” of patient identified by s =“SSN”
S3.1 ($s, ?z, ?r)Returns z =“zip”, and r =“salary” of patient identified by s =“SSN”
S4.1 ($s, ?n)
S4.2 ($s, ?n)
Returns n =“DNA” of patient identified by s =“SSN”
S5.1 ($z, ?w)Returns w = “Weather-condition” of address z =“zip

Complete Article List

Search this Journal:
Volume 19: 4 Issues (2022): 1 Released, 3 Forthcoming
Volume 18: 4 Issues (2021)
Volume 17: 4 Issues (2020)
Volume 16: 4 Issues (2019)
Volume 15: 4 Issues (2018)
Volume 14: 4 Issues (2017)
Volume 13: 4 Issues (2016)
Volume 12: 4 Issues (2015)
Volume 11: 4 Issues (2014)
Volume 10: 4 Issues (2013)
Volume 9: 4 Issues (2012)
Volume 8: 4 Issues (2011)
Volume 7: 4 Issues (2010)
Volume 6: 4 Issues (2009)
Volume 5: 4 Issues (2008)
Volume 4: 4 Issues (2007)
Volume 3: 4 Issues (2006)
Volume 2: 4 Issues (2005)
Volume 1: 4 Issues (2004)
View Complete Journal Contents Listing