29-08-2016, 10:53 AM
1451300253-33.PrivacyEnhancedWebServiceComposition.docx (Size: 242.6 KB / Downloads: 6)
ABSTRACT:
Data as a Service (DaaS) builds on service-oriented technologies to enable fast access to data resources on the Web. However, this paradigm raises several new privacy concerns that traditional privacy models do not handle. In addition, DaaS composition may reveal privacy-sensitive information. In this paper, we propose a formal privacy model in order to extend DaaS descriptions with privacy capabilities. The privacy model allows a service to define a privacy policyand a set of privacy requirements. We also propose a privacy-preserving DaaS composition approach allowing to verify the compatibility between privacy requirements and policies in DaaS composition. We propose a negotiation mechanism that makes it possible to dynamically reconcile the privacy capabilities of services when incompatibilities arise in a composition. We validate the applicability of our proposal through a prototype implementation and a set of experiments.
EXISTING SYSTEM:
A typical example of modeling privacy is the Platform for Privacy Preferences (P3P). However, the major focus of P3P is to enable only Web sites to convey their privacy policies. In privacy only takes into account a limited set of data fields and rights. Data providers specify how to use the service (mandatory and optional data for querying the service), while individuals specify the type of access for each part of their personal data contained in the service: free, limited, or not given using a DAML-S ontology.
DISADVANTAGES OF EXISTING SYSTEM:
Two factors exacerbate the problem of privacy in DaaS. First, DaaS services collect and store a large amount of private information about users. Second, DaaS services are able to share this information with other entities. Besides, the emergence of analysis tools makes it easier to analyze and synthesize huge volumes of information, hence increasing the risk of privacy violation. In the following, we use our epidemiological scenario to illustrate the privacy challenges during service composition.
Challenge 1: Privacy Specification.
Challenge 2: Privacy within compositions.
Challenge 3: Dealing with incompatible privacy policies in compositions.
PROPOSED SYSTEM:
We describe a formal privacy model for Web Services that goes beyond traditional data-oriented models. It deals with privacy not only at the data level (i.e., inputs and outputs) but also service level (i.e.,service invocation). In this paper, we build upon this model two other extensions to address privacy issues during DaaS composition. The privacy model described in this paper is based on the model initially proposed
ADVANTAGES OF PROPOSED SYSTEM:
Privacy-aware Service Composition: We propose a compatibility matching algorithm to check privacy compatibility between component services within a composition.
Negotiating Privacy in Service Composition: In the case when any composition plan will be incompatible in terms of privacy, we introduce a novel approach based on negotiation to reach compatibility of concerned services (i.e., services that participate in a composition which are incompatible).
MODULE DESCRIPTION:
e-Epidemiological Scenario
The first module is E-epidemiology scenario module. We develop the scenario of E-epidemiology. E-epidemiology is the science underlying the acquisition, maintenance and application of epidemiological knowledge and information using digital media such as the internet, mobile phones, digital paper, digital TV. E-epidemiology also refers to the large-scale epidemiological studies that are increasingly conducted through distributed global collaborations enabled by the Internet.
The traditional approach in performing epidemiological trials by using paper questionnaires is both costly and time consuming. The questionnaires have to be transformed to analyzable data and a large number of personnel are needed throughout the procedure. Modern communication tools, such as the web, cell phones and other current and future communication devices, allow rapidly and cost-efficient assembly of data on determinants for lifestyle and health for broad segments of the population.
The mediator selects, combines andorchestrates the DaaS services (i.e., gets input fromone service and uses it to call another one) to answerreceived queries. It also carries out all the interactionsbetween the composed services (i.e., relays exchangeddata among interconnected services in the composition).The result of the composition process is a compositionplan which consists of DaaS that must be executed ina particular order depending on their access patterns(i.e., the ordering of their input and output parameters).
Privacy Level
In this module we define two privacy levels: data and operation. Thedata level deals with data privacy. Resources referto input and output parameters of a service (e.g.,defined in WSDL). The operation level copes withthe privacy about operation’sinvocation. Informationabout operation invocation may be perceived asprivate independently on whether their input/outputparameters are confidential or not. For instance,let us consider a scientist that has found an inventionabout the causes of some infectious diseases, he invokesa service operation to search if such an invention isnew before he files for a patent. When conducting thequery, the scientist may want to keep the invocation ofthis operation private, perhaps to avoid part of his ideabeing stolen by a competing company. We give belowthe definition of the privacy level.
Privacy Rule
The sensitivity of a resource may be defined accordingto several dimensions called privacy rules. We call the setof privacy rules RulesSet(RS). We define a privacy ruleby a topic, domain, level and scope.The topic gives the privacy facet represented bythe rule and may include for instance: the resourcerecipient, the purpose and the resource retentiontime. The “purpose” topic states the intent for whicha resource collected by a service will be used; the“recipient” topic specifies to whom the collectedresource can be revealed. The level represents theprivacy level on which the rule is applicable. Thedomain of a rule depends on its level. Indeed, each rulehas one single level: “data” or “operation”. The domainis a finite set that enumerates the possible values thatcan be taken by resources according to the rule’s topic.For instance, a subset of domain for a rule dealing withthe right topic is {“no-retention”, “limited-use”}. Thescope of a rule defines the granularity of the resourcethat is subject to privacy constraints. Two rules at mostare created for each topic: one for data and another foroperations.