SOCADOI 10.1007/s11761-013-0150-6

ORIGINAL RESEARCH PAPER

A semantic selection approach for composite Web servicesusing OWL-DL and rules

Amel Boustil · Ramdane Maamri · Zaidi Sahnoun

Received: 17 May 2012 / Revised: 23 July 2013 / Accepted: 4 December 2013© Springer-Verlag London 2013

Abstract Most of the studies on the semiautomated com-posite Web services select concrete services based on thefunctional and/or non- functional attributes. However, theydo not consider relationships between these attributes inthe description of services or the user constraints. In thiswork, we propose an approach, which relates services toobjects (resources) maintained by these services. The usercan impose his constraints on the objects affected by therequested services. The affected object and their relation-ships are described in an intermediate ontology using OWL-DL and SWRL languages. Our selection strategy consid-ers the relationships between services by looking for thedependent instances (conforming objects values) of affectedobjects that satisfy the user constraints and by combiningthe related services to get conforming composite services.The proposed selection approach of conforming compositeservices is implemented by using semantic Web tools andlanguages.

Keywords Abstract service · Concrete service · OWL ·SPARQL query

1 Introduction

Web services composition is a highly active studied researchdirection. It provides a mechanism to aggregate a multipleservices into one composite service. In contrast to the tra-ditional Web service composition based on IA planning orworkflow, there are a lot of Web services offered by differentproviders providing the same functionality; however, these

A. Boustil (B) · R. Maamri · Z. SahnounLire Laboratory, University Constantine 2, 25000 Constantine, Algeriae-mail: boustil1710@yahoo.fr

services that have different values of attributes describingfunctional or non-functional properties (NFP) could be gath-ered into a collection of Web services (category, task, type,community, abstract service) and used to select and to deter-mine the most appropriate concrete (instance) service.

The ultimate goal of the composition research is to pro-vide a fully automatic process. Such semiautomatic Web ser-vice compositions are essentials when for example consid-ering user constraints for each abstract service where spe-cific Web services are not predefined. All semiautomaticapproaches [1–14] are based on an existing abstract com-position and on instantiating this abstract composition byselecting the most appropriate concrete Web services withrespect to user constraints and service properties.

Selection for the purpose of the composition processdepends on user constraints imposed on functional properties(FP) (for example, the user seeks a three stars hotel) or NFP(for example, the user seeks a service with high availability).It has to take care of the difference between conforming com-posite Web service when we talk about constraints on the FPand the optimized composite service when we impose con-straints on NFP. Most of the solutions [1,15–18] that calculatethe optimized composite service are generally syntax-basedapproaches, focusing on the optimization problem and usesome optimization algorithms such as Integer programmingor genetic algorithms. When we consider the problem of con-forming composite services [3,4,6,7,9,10], semantic-basedapproaches are generally used to locate and match functionalattributes describing individual concrete services.

Describing services by considering only input and outputinformation cannot guarantee that the composed service willprovide the requested functionality as mentioned in [19,20].There have been some studies on the automated discov-ery and composition [9,10,19–21] of Web services that addobjects in the description of the functional semantics of ser-

123

SOCA

vices. They focus on objects describing resources maintainedby Web services and extracted from the constraints imposedon FP.

While several approaches as mentioned above use func-tional attributes and/or non-functional attributes in the selec-tion process, other approaches like [9,10] add objects toincrease the expressiveness description of the individual ser-vices. However, these approaches focus on describing andlocating single services. Thus, they cannot capture rela-tionships between services that are essential information todetermine their compatibility and their dependency when weselect concrete services for the purpose of the composition.

In our work, we focus on the objects (resources) main-tained by the concrete services and their semantic relation-ships described in an independent ontology. Therefore, ser-vices are indexed according to these affected objects, and userconstraints are imposed on the affected objects. Our selectionstrategy considers the relationships between services whenit takes into account the relationships between their relatedobjects. To relate services to their affected objects, we pro-pose a semantic framework called abstract services ontologythat clusters concrete services into different abstract servicesaccording to their functional characteristics and the type ofmanipulated objects. Based on imposing constraints on theaffected objects, our selection approach generates dynami-cally SPARQL [22] queries to infer dependent instances ofaffected objects (conforming objects values) and related ser-vices that will be combined in order to form conformingcomposite services.

Let us consider a simple scenario to illustrate the issuesthat have to be addressed in this paper. A woman wantsto do a cesarean birth surgery. Before the surgery, she willhave to create a medical record (CMR) in a hospital whereher doctor works; she will have an appointment with herdoctor and run some blood tests in a laboratory recom-mended by the hospital. These conditions involve the fol-lowing functionalities: CMR, make an appointment with herdoctor (RDV_D) and make an appointment with a laboratory(RDV_L). For each functionality (abstract service), severalservice providers (concrete services) are available. Further-more, some conditions of compatibility must be verified suchas, doctor works in the hospital where patient has created hismedical record, blood tests have to be performed in a lab-oratory recommended by the hospital, or hospital and labo-ratory must to be in the same location. In order to supportthe description of the affected objects (hospital, laboratory,doctor, etc.) and their semantic relationships (doctors workin hospitals, hospitals are near to the laboratories, etc.), weuse an independent intermediate ontology allowing inferenceof the direct or indirect relationships. Concrete services areindexed according to the values of the affected objects in theabstract services ontology. The selection mechanism mustchoose CMR concrete service to CMR and RDV_D concrete

service to have an appointment with a doctor by consideringhospitals where the doctor works in. The hospitals of theselected CMR service must also be compatible (near, recom-mended, etc.) with the laboratories of the selected RDV_Lservice.

In this paper, we present a semantic selection approachof conforming composite Web services. Our contributionsare threefold. First, we propose an ontology framework thatallows bundling concrete services to their abstract servicesaccording to their functionality and their affected functionalobjects. An intermediate independent ontology has been pro-posed in order to provide a shared and common descriptionof affected objects and their relationships. Second, we showhow the user can draw a new kind of constraints, semanticconstraint by considering the relationships between objects.Third, we propose and implement a semantic approach forthe selection using semantic Web tools to locate conformingcomposite concrete services.

The rest of this paper is organized as follows. Section 2presents previous works related to the semiautomated com-position and selection of Web services. In Sect. 3, we presentthe global architecture of the proposed approach. We alsodefine the intermediate ontology and explain how to orga-nize both the abstract and concrete services. Section 4 givesa formal specification of the proposed selection approachcompared to the naîve approach. Section 5 is a practicalimplementation of the proposed approach using semanticWeb languages. The different components of the developedapplication, the discussion, and the performance evaluationare presented in Sect. 6. Finally, we conclude this paper andgive some perspectives.

2 Related work

In this section, we present different related works that arebased on an existing abstract composition and on instanti-ating this abstract composition by selecting the most appro-priate concrete Web services with respect to the user con-straints. A classification of different related works has beenmade in [23] according to some important criteria that haveto be considered when comparing service selection for thecomposition of Web services. In this work, we focus on themost important requirements and we will show the very clos-est works according to these requirements.

2.1 Requirement 1: expressive services description

Define an expressive description for service and theirfunctionality by defining the abstract service level,adding Qos attributes and the affected objects todescribe concrete services. Relationships between ser-vices have also to be considered.

123

SOCA

Atomic or composite Web services are typically describedby using languages like BPEL [24] or OWL-S [25], whichprovide mechanisms for the description of Web service com-position. However, the process of Web service compositionis intended to be static in the sense that the composition flowis generated off-line. Unfortunately, the main impedimentto current Web service standards is their limited support todynamic automated composition and selection [26,27].

A lot of existing Web services provides similar function-ality. However, there is currently little effort on abstract-ing these similar services into high-level common services.Although the OWL-S language provides a way to describethe hierarchical relationship between services, the recom-mended ontology framework is still limited to one root-levelabstract service [25,27] and there is no capturing of similarservices as concrete services for the described abstract ser-vice. In [26,28], authors propose an extension to the OWL-sontology framework, which enables defining the compositeservices at the abstract service level. They include a serviceinstance pool that allows filtering and plugging in candidateservices at runtime. However, the candidate services in theinstance pool are described by their FP (input, output, precon-dition, and effect) and some predefined NFP. However, theseFP and the selected NFP are not sufficient to define com-pletely the functionality of a service. Furthermore, their com-position process based on a planning algorithm doesn’t con-sider conforming concretes services or the optimized solu-tion.

Several studies on the discovery and composition [9,10,19–21] add objects in the description of the functional seman-tics of services. In [9,10], authors index services accordingto the value of attributes of the affected objects describedin the requested services for the problem of selecting con-forming composite services after matching heterogeneousattributes. But their defined meta-ontology does not use anabstract service level and they do not consider relationshipsbetween objects in the selection process because match-ing phase (named leveling attributes) considers semanticrelationships only between single-service attributes and notbetween objects. Another main difference with our work liesin the fact that our selection algorithm focuses on the valuesof affected objects described in independent ontology. There-fore, we can manage relationships between these objects andmanage several user constraints.

In [12], authors propose an ontology framework fordescribing Web services based on NFP, which is structuredin three parts: the generic services ontology, the domain-specific service ontology, and the service instance layer. Theyshow how planning and pricing mechanisms for dynamicWeb scenarios can be implemented to construct complexservices considering technical as well as economic servicesaspects. In their framework, the authors separate betweenthe abstract and the concrete layers. They also define, in the

abstract service level (generic services ontology), some inter-dependencies between services given in SWRL rules such asexclude, substitute, and requirement. These rules must beverified by using an inference engine once the compositeservices are determined. It can also be seen that the type ofthese rules is more abstract and static for a given applica-tion in the sense that they must be generated in off time andonly for the abstract service level. In our work, we determineinterdependencies dynamically in the selection process.

2.2 Requirement 2: expressive user constraints

Services are described by their FP (input, output, pre-condition, and effect), functional attributes, and theirNFP. User can impose constraints on FP, functionalattributes, and/or NFP. He can also impose seman-tic constraints by specifying semantic relationshipsbetween services attributes.

Most existing work of service composition and selectionare based on NFP. Zeng et al. [1] address the issue of select-ing Web services for the purpose of their composition ina way that maximizes user satisfaction expressed as utilityfunctions over quality-of-service (QoS) attributes, while sat-isfying the constraints set imposed by the user and by thestructure of the composite service. Two selection approacheswere described and compared: one based on local selectionof services and the other based on global optimization usinginteger programming. The set of user and composition con-straints defined in [1] was the background for other studiesusing other models of optimization like mixed integer pro-gramming [18], genetic algorithm [16,29], Ant colony opti-mization [17], and constraint programming [14].

In METEOR project [13,15], authors define constraints onQoS attributes. They use optimization technique and apply aninference rule engine to determine service interdependencies.The inference rule engine based on SWRL language uses aset of rules describing dependencies between non-functionalattributes like compatibly between providers. In our work,interdependencies can be defined on functional or NFP.

The choice of when composition happens is betweenoffline (at design time) or online (during runtime). It dependson the use of dynamic functional attributes or static func-tional attributes. An attribute is static if its value is inde-pendent of the execution of the service. Generally, onlineapproaches [2,5–8] exploit data/control flow in the selectionwhere values of outputs can affect the rest of the compositionplan. In [7], Gamha et al. impose some constraints on inputsand outputs properties, their selection locate individual ser-vices and impose their execution before selecting anotherservice according to the composition flow. The problem iswith the effect-providing services where the backtracking isnot a good solution for payment services for example. It was

123

SOCA

also the same problem with Shop2 in [6] where Serin et al. usesimulations for this type of services with planning to predictthe non-deterministic behaviors of services especially to pre-dict values of outputs services. It is the reason why the mostof the existing works use independent functional attributesand learning about services properties in order to avoid exe-cution of service with backtracking mechanism.

Gooneratne et al. [9,10] classify constraints on functionalattributes as local or global. The former restricts the val-ues of a particular attribute of a single service, whereas thelater simultaneously restricts the values of many attributesof a multiple constituent services and global constraints canalso be dependent or independent [10]. A global constraint isstrictly dependent if the values that should be assigned to allremaining restricted attributes can be uniquely determinedonce a value is assigned to one attribute. Any global con-straint that is not strictly dependent is independent [10]. Inour work, we classify constraints as local, global, or seman-tic. The latter is added because we focus on imposing con-straints around affected objects described in an intermediateontology.

The use of affected objects to satisfy user constraints issimilar to use data constraints such as in [30,31]. In theseworks, the authors address the problem of automatic compo-sition and represent abstractly services (clients or provider)as a transition system having states, describing the “realworld,” viewed as a database instance over a relational data-base schema. In our work, services (client and provider) aredescribed by relating them to a real world of objects, viewedas an ontology written in OWL-DL language and rules. Theontology allows inference and maintains its consistence (realworld) based on the description logic reasoning.

Using an intermediate ontology has been addressed in [11]for querying and automatically composing a specified typeof Web services called data providing information services(DP). Firstly, authors model DP services as resource descrip-tion framework (RDF) views over a mediated ontology. EachRDF view contains concepts and relations from the medi-ated ontology to capture the semantic relationships betweeninput and output parameters. Secondly, they propose queryrewriting algorithms for processing queries over DP services.The query mediator automatically transforms a user’s query(during the query rewriting stage) into an automatic com-position of DP services. In our work, we address the prob-lem of selection for the purpose of the composition. Theabstract/concrete levels considered in our model index overthe mediated ontology services by capturing type/values ofthe affected objects. Our mediated ontology defines alsosome SWRL rules to describe inferred properties betweenobjects. Querying concrete services from the abstract ser-vices ontology uses SPARQL query language in order toinfer dependant instances, which can guide the selectionalgorithm.

2.3 Requirement 3: efficient selection strategy

Define selection strategy that takes into considerationservices description, their interdependencies, and dif-ferent user constraints.

For selection mechanism, authors use many strategies ininstantiating abstract services by concrete services in orderto find the best solution that meets all criteria defined by theuser according to services properties. We distinguish betweenglobal solvers [1,2,9,10,12,13,16,14] and local solvers [3–5,7,8]. Global solvers are well suited for global constraints.When authors use local solvers, they also define backtrackingand propagation process to find alternatives to some previ-ously chosen node instantiation solution. Once the backtrack-ing process execution terminates, the composition solutionmust be recomputed and may require the propagation of thenewly chosen solution to the higher level in the hierarchi-cal order of the composition flow. Monfroy et al. [3,4] andZahoor et al. [5] involve backtracking when selection processneeds to choose dependency (conforming) services describedby specifying added properties called (WorkWith, link, etc.).The class of composite services solutions that use a backtracksearch [32] is known as NP-hard [1,10,32].

Authors in [5] introduce the use of SQWRL [33] selectionrules in the composition process and for each abstract service,a selection SQWRL rule is generated dynamically and incor-porated with a backtracking and a propagation selection algo-rithm. Our approach proposes generating dynamically withone SPARQL rule-dependent services through the inferenceof conforming values of their affected objects then the con-forming services. We do not need backtracking and propa-gation in our work. Using a separate independent ontologyfor services dependencies is another difference with [3–5].

At the end of this section, we can conclude that exist-ing solutions for composite service selection lack expres-sive descriptions of abstract/concrete services descriptionand relationships between their functional attributes as wellas efficient service selection mechanisms using the semanticexpressive description of user’s constraints and services. Inthis work, we will propose an intermediate ontology writtenin OWL-DL and SWRL languages to describe relationshipsbetween functional attributes of the affected objects. Servicesare clustered into categories called abstract services accord-ing to a semantic framework using the OWL-DL formal-ism. The following section introduces a global architectureaddressing these issues.

3 Global architecture for service selectionand composition

A typical architecture of our system is shown in Fig. 1. Itinvolves four types of players: service providers, informa-

123

SOCA

Fig. 1 Global architecture for service selection and composition

tion agents, ontology provider, and the composer. Serviceproviders offer the atomic concrete services. The informa-tion agents crawl the Web to collect information about con-crete services from the atomic providers and index them intoa meta-ontology called abstract services ontology accord-ing to the specialized functionalities (abstract services). Thevocabulary shared by these abstract services called inter-mediate ontology is defined by the ontology provider. Theontology provider has also to define the offered functionali-ties (abstract services) and the information agent assigned toeach abstract service.

Each information agent is responsible for the automaticdiscovery at runtime/off time of the concrete services thatfulfill the corresponding abstract service functionality. Infor-mation agents gather information about concrete servicessuch as cost, price, type, and affected objects. This process issimilar to contacting travel agencies hotels by telephone ore-mail for learning about their characteristics such as pricesand whether they accept credit card or not, what type ofobject resource (hotel, motel, three stars, etc.) are special-ized, etc. The obtained information is saved in the abstractservices ontology and used by the composer to find themost suitable concrete services according to the intermediateontology.

The composer has to query ontologies, to select and exe-cute the best conforming composite concrete services. Beforedescribing the used ontologies, we will firstly give some def-initions to the used formalism.

3.1 Ontology formalism

We use Web Ontology Language OWL-DL [34] as a for-malism to represent our ontologies. OWL-DL is a decidablefragment of OWL, and based on description logics (DL) [35],it facilitates logical inference and allows reasoning on ontolo-gies. OWL-DL ontology contains individuals, properties, andclasses. Classes and properties can be organized into sub-sumption hierarchies. Furthermore, OWL allows to definecomplex classes by using inclusion axioms (�) or equivalentaxioms (≡).

We also use rule languages to express such additionalprimitives not provided by OWL. One of the earliest for-malisms combining OWL and rules is the Semantic WebRule Language (SWRL) [36,37]. Informally, each SWRLrule has the form B → H , where B and H are possibly emptyconjunctions of atoms. However, reasoning with an arbitrarySWRL expression usually becomes undecidable. We restrictourselves to DL-safe rules [38]. DL-safe rules maintain thereasoning decidable by imposing constraints on the formatof the rule, and this means that each variable occurring inthe rule must also occur in a non-DL-atom in the body of therule. This involves that all objects referred to in the rule haveto be known explicitly [38].

Until now, there is no standard query language specifi-cally for OWL and rules ontologies. The most commonlyused Semantic Web query language is SPARQL [22], whichis intended initially to be used for RDF. However, this defi-

123

SOCA

nition of SPARQL is allowed to be extended to OWL entail-ment. A semantic specification for SPARQL compatible withOWL-DL has been defined in SPARQL-DL [39,40] usingPellet [41] inference engine. So, to query and reason over ourontologies using OWL-DL language, we will use the Pelletinference engine that supports also DL-safe rules [37,38].

3.2 Intermediate ontology

Formally, the intermediate ontology (O) is defined by aTBOX [35] and an ABOX [35]. A TBox is a terminologi-cal component described by the tuple (C, D, DP, OP, CC, CP,POP, Rules) where

C is a set of primitive and defined concepts like (hos-pital, laboratory, and physician). Defined concepts aredescribed by using inclusion or equivalent axioms.D is a set of dataTypes like (string, integer).DP is a set of dataType property like (hasName).OP is a set of objectProperty like (workWith, workIn);each object property has its domain and range in C.CC is the classification relationship between classes likephysician is a subClass of Doctor.CP is the classification relationship between objectProp-erties or dataType properties like hasNamephysician is asubProperty of hasNameDoctorPOP are properties of objectPropeties like: Functional,transitive, and reflexive. WorkWith is a transitive Object-Property.

Rules are properties, which need to be inferred. Theexample presented in (1) indicates that the laboratoryis near to the hospital if they are located in the samecountry.

hospital(?x) ∧ has Adress(?x, ?z)

∧ laboratory(?y) ∧ has Adress(?y, ?w)

∧ located I n(?z, ?t)∧located I n(?w, ?t)→near(?x, ?y).

(1)

A portion of our example TBOX ontology is presented inFig. 2. It shows that Physician is a subclass of the Doctorwho works in Hospital. This latter interacts only with somelaboratories that do some recommended tests like IRM orRadio.

Hospital(h1), laboratory(l1) and workWith(h1,l1) areexamples of ABOX assertions associated with the TBOXdescribing compliant statements instances (individuals) andtheir relationships.

3.3 Abstract services ontology

In this section, we will show how the abstract services andconcrete services can be formalized using OWL-DL. We pro-pose an ontology framework based on the following ideas:

1. Separation between descriptions of abstract service andthat of concrete service. Concrete services are related totheir abstract services by an objectProperty of HasAb-stractService.

Fig. 2 Intermediate ontology example

123

SOCA

Fig. 3 Ontology model forservices description

2. Description of concrete services by using functionalattributes and non-functional attributes. NFPs are QoSattributes. Functional attributes are those of affectedobjects that are described independently in the interme-diate ontology. Each concrete service is related by thevalues of their affected object using an objectPropertycalled affects.

3. Concrete services are bundled according to their func-tional description (their abstract service) and the type ofthe affected objects by using inclusion/equivalent axiomsof OWL-DL.

Therefore, our ontology framework presented in Fig. 3 isstructured in three parts: categories, abstract services, andconcrete services. In the first part, the model is based on aclassification of available abstract services called categories.For example, if a user search a hospital, he may just requireto specify search_hospital_service or specify which type ofhospital he wants. So search_hospital_service is one cate-gory and search_maternity_hospital_service is another cat-egory. When the user asks a search_hospital_ services cat-egory, all abstract services of the sub-categories are addedto the requested abstract services. Abstract service describedby axiom (2) represents the description of the common FP ofservice, which defines in general relevant concepts to specifyservices (independent from a real service). The functionalityof a service is described by parameter types of its operations(inputs, outputs). The axiom (2) makes sure that each abstract

service has at least one category and at least one functionaloperation.

Abstract Service � � �∃hasCategory.Category

�∀hasCategory.Categor y

�∃hasCapabili t y.Operation

�∀hasCapabili t y.Operation.

(2)

Furthermore, a service may require external conditions to besatisfied. These conditions specify restrictions that apply tothe values used as inputs and outputs. Thus, the conditionsused to specify restrictions (a set of values) on (input, output,precondition, and effect) model a restriction on objects. Forexample, CMR is a provided service described by operationop1 (Name, NSS, location, ID_confirmation), the specifiedhospitals “h1” and “h2”of their affected objects are restric-tion on hospital concept indicating that this concrete servicereserves only in “h1” or “h2” hospitals. Other attributes inthe concrete services layer related to the QoS and providersattributes are added to describe the specific NFP of concreteservices as described in Fig. 3.

One of the important characterizations of the proposedframework is that each concrete service is plugged intoa class of concrete services that specifies the correspond-ing abstract service and the type of the affected objects aspresented in axiom (3). For example, CMR is a class ofconcrete services, which have functionality described bycmr_AbstractService instance and affects Hospital concept.

123

SOCA

This is formally defined by axiom (3’).

ConcreteServiceClass ≡ ConcreteService

� (∃has Abstract Service. {I nstance_Abstract Service})� (∃a f f ects.intermediate : a f f ected Object)

� (∀a f f ects.I ntermediate : a f f ecetd Object). (3)

C M R ≡ ConcreteService (3’)

� (∃has Abstract Service. {cmr_Abstract Service})� (∃a f f ects.intermediate : hospital)

� (∀a f f ects.I ntermediate : hospital).

The axiom (3) makes sure that each concrete service hasone abstract service instance and affects at least one value ofhospital concept.

Extracting information that describes abstract servicesand concrete services from the (OWL-s [25], BPML [24],UDDI [42], WSDL [43]) is done on off time by informationagents and it is out of the scope of this paper.

4 Overview of the service selection constraint model

Any semiautomatic approach for composition allows adeclarative specification of the composition flow by speci-fying abstract services (composite abstract service) and howthey are connected by operators (split_and, seq, split_or,

etc.) like in [4,5]. According to the abstract servicesontology, we can extract affected objects of each abstractservice that belongs to the composite abstract service.Furthermore, the user can also interact with the inter-face to specify his constraints on attributes describingthe affected objects or on their relationships as indicatedin Fig. 4. Hence, in our approach, instances of affectedobjects which satisfy the user constraints can be inferredover the intermediate ontology. We call these dependentinstances “conforming objects values.” Using conformingvalues was inspired from [9] and adapted to the affectedobjects.

As indicated in the Sect. 3, services related to their affectedobjects instances are described through the abstract servicesontology. The related services to the conforming objectsinstances are candidate services for its corresponding abstractservices. When we take into account the semantic relation-ships between objects, it amounts to consider the relation-ships between services. Only related services to the conform-ing objects instances can participate in the composition flowand their combination returns conforming composite ser-vices. To obtain all combinations, we would generate a Carte-sian product of candidate concrete services for all abstractservices of the user request. In this section, we will presentthe different types of constraints and define what are con-forming objects values. We will also present two approaches,naîve approach and our proposed approach, which includesobjects.

Fig. 4 User constraints on the affected objects

123

SOCA

Definition 1 (Request model) Constraints are included in therequest and imposed on objects. They can be local, global,or semantic.

The local constraint (LC) restricts values of attributes ofone object. For example, Hospital.type = {Maternity} is a LCwith parameters (Object, Attribute, value) = (Hospital, Type,“Maternity”).

Global constraint involves many attributes from differentobjects. A global constraint is described by binary attributecomparison (BAC) that describes a comparison relationshipthat must exist between attributes describing concrete ser-vices. For example, hospital.hospitalLocation = laboratory.labLocation is a BAC constraint using “=” operator. A com-parison operator can be either of =,<,>,≤,≥, �=, and ∈.In general, a global constraint has the following parameters:object1, attribute1, object2, attribute2, operator.

We can add some semantic object relations (SOR) thatdescribe the semantic relationships that exist between objectsdefined in the intermediate ontology. Imposing workInobjectProperty (See Fig. 4) for example, between Doctorand Hospital concepts can reduce significantly the numberof affected objects values. Therefore, semantic constraint hasparameters of object1, object2, semantic relationships.

So request template (RT) will be

RT = (C AS, C O, RM) and

RM = LC + B AC + SO R. (4)

where

CAS: composite abstract service.CO: composite object of CAS, which contains the set ofthe affected objects of its atomic abstract services.

Definition 2 (Conforming objects values) Conformingobjects values for a given RM are the set of tuples of instancesof a composite object (CO) where all constraints of a givenrequest model (RM) are satisfied.

COI(RM , CO) = {(i11, i12, . . . i1n), . . . (im1, im2, . . . imn)}W here

(i j1, i j2, . . . i jn) satisfy RM, ∀ j ∈ 1 . . . m. (5)

where

i j1 is an instance of the object O1, ∀ j ∈ 1 . . . m

i j2 is an instance of the object O2, ∀ j ∈ 1 . . . m

i jn is an instance of the object On, ∀ j ∈ 1 . . . mC O = {O1, O2, . . . On}

As an example, Fig. 5 shows that (d1, h1, l2) is a tupleof a COI(RM1, CO) where CO = (Doctor, Hospital, Labora-

tory) and RM1={Hospital.type = maternity, hospital.hospitalLocation = laboratory.labLocation, Doctor workIn Hospi-tal, laboratory workWith Hospital}. (d1, h2, l3) is nota conforming value for (RM1, CO), so (d1, h2, l3) /∈C O I (RM1, C O).

Definition 3 (The selection constraint model) The naîveselection of conforming concrete services for a compositeabstract service consists of finding all the combination ofconcrete services that satisfy user constraints as indicated in(6a).

Con f orming(C AS, RM) = {csc1, . . . cscm} (6a)

where{{

f or each aas j ∈ C AS,{

Discovery(aas j ) = AC Sj}

(6b)

V =⎧⎨

⎩calculate

|C AS|∏

j=1

AC Sj

⎫⎬

⎭}

(6c)

csci = x ∈ V where RM in x is_valid() (6d)}

where

aas j : atomic abstract service.csci : composite concrete service.AC Sj : set of atomic concrete services.CAS: composite abstract service.is_valid(): is a function that verifies satisfaction of con-straints on a csc.

When the conforming composite Web services returnsmore than one CSC, we apply an optimization algorithm toreturn the best composite concrete service that satisfies theuser non-functional preferences as indicated in (7).

Selection ({csc1, . . . cscn}) = csci

where

{csci = get Best ((csc1, Qos1) , . . . (cscn, Qosn))} . (7)

A naîve approach for selecting conforming composite con-crete services as described in (6a) would to be exponential. Ifwe assume that each atomic abstract service (aas j ) containsk concrete services and there are n abstract services, the naîveapproach will extract all concrete services for each abstractservice (6b), will generate kn composite concrete services bygenerating Cartesian product AC S1 ∗ AC S2 . . . ∗ AC Sn fora composite abstract service C AS = {aas1, aas2, . . . aasn}(6c), will verify whether the user constraints given by RMmodel are satisfied on each composite concrete service, andwill finally return only conforming CSC from the differentcombinations (6d).

123

SOCA

Fig. 5 Conforming objects values examples

Our proposed approach includes related objects to the RM(8a) and will firstly generate the conforming objects val-ues according to RM model (8b) and then will extract theonly related concrete services for each value of each con-forming objects tuple (8c). After that, it will combine theextracted concrete services for each tuple (8d) to add it, atthe end, to the conforming composite concrete services set(8e). Concrete services related to conforming values are com-bined by generating a Cartesian product for each tuple toobtain only conforming composite concrete services. Thismeans that our approach will not generate composite con-crete services for all existing concrete services as statedin (6b, 6c); however, only conforming objects values areconcerned.

Con f orming(C AS, C O, RM) = Set_C SC (8a)

where

{V = C O I (RM, C O) (8b)

f or each tuplek ∈ V do {f or each x ∈ tuplek and aas j ∈ C AS do

{discover y(aas j , x) = AC Sj

}(8c)

Pk = calculate|C AS|∏

j=1

AC Sj

} (8d)

Set_C SC =|V |⋃

k=1

Pk (8e)

}where

aas j : atomic abstract service.AC Sj : set of atomic concrete services.CAS: composite abstract service.CO: list of the affected objects of CAS.Pk : Cartesian product of related services calculated forone tuple of conforming objects values.Set_CSC: set of all conforming composite concrete ser-vices obtained by adding Cartesian product calculated foreach tuple.

Conforming instances of affected objects can be identifiedby querying independently the intermediate ontology, whichdescribes affected objects and their relationships. Based on

123

SOCA

Table 1 List of concrete services with their affected objects

Abstract service Concrete services Affected objects

AS_MR cs1 h1, h2cs2 h2

AS_RDVD cs3 d1, d2

cs4 d3

AS_RDVL cs5 l1, l3

cs6 l2

cs7 l1

Table 2 List of conforming objects values:COI(RM1,CO)

Doctor Hospital Laboratory

d1 h1 1l

d3 h1 l1

Table 3 List of related concrete services for each object value

Doctor Hospital Laboratory

{cs3} {cs1} {cs5,cs7}

{cs4} {cs1} {cs5,cs7}

the abstract services ontology where we index concrete ser-vices according to their affected objects, we can for eachinstance (x) of a given object find the related concretes ser-vices (discover y(aas j , x)) by querying the abstract servicesontology.

Let us consider the abstract services ontology for the abovescenario. Affected objects for each concrete service are listedin Table 1, showing how they are indexed by the objectProp-erty “affects.”

According to the following RM imposed by the user:RM1 = {Hospital.type = maternity, hospital.hospitalLocation= laboratory.labLocation, Doctor work_in Hospital, labora-tory work_with Hospital} and with a CO = {doctor, hospital,laboratory}, suppose that querying the intermediate ontologyby the RM1 generates only values presented in Table 2. Eachline of this table represents conforming objects tuple fromthe set COI(RM1, CO).

According to Table 1, the value l1 for Laboratory object isrelated to the two concrete services {sc5, cs7}, to be returnedby the function Discovery(RDV_L,l1). So for each value ofthe table Table 2, we would generate a list of related con-crete services according to the abstract services ontology asindicated in Table 3 (8c).

Each list of these related concrete services is consideredas a conforming candidate concrete services for one atomicabstract service. The Cartesian product of these lists is done(8d) for each line of table Table 3 to obtain the final set ofconforming CSC (8e): {cs3.cs1.cs5, cs3.cs1.cs7, cs4.cs1.cs5,cs4.cs1.cs7}, as indicated in Table 4. Each line in this tableis a conforming composite concrete service.

Table 4 List of conforming composite concrete services

AAS CMR AAS RDV_D AAS RDV_L

cs1 cs3 cs5

cs1 cs3 cs7

cs1 cs4 cs5

cs1 cs4 cs7

On the other side, if we consider the naîve approach, wewould generate 2*2*3 composite concrete services beforeverifying user constraints instead of 4 composite concreteservices located in the proposed approach.

In the next section, we will show how to realize ourproposed selection approach, based on the abstract servicesontology and the intermediate ontology.

5 Service selection constraints model using SPARQLqueries

Our approach for service selection constraints model forthe purpose of the composition requires (1) service descrip-tion as described in Sect. 3.3, (2) intermediate ontology thatdescribes related objects and their relationships, and (3) userrequests to be extracted from a user interface. Our approach iscomposed of three main phases: (1) preprocessing, (2) iden-tifying conforming objects values, and (3) identifying con-forming composite services. In the first phase, we use XMLfiles to structure RM of the user: list of the requested abstractservices, their affected objects, and the user’s constraints. Thesecond phase determines instances of the affected objectsthat are conforming to users constraints as shown in (8b). Todetermine these instances, we have to query the intermediateontology using SPARQL language. While user constraintson the affected objects can be structured and rewritten in aSPARQL query called SPARQL query1, the result returnedafter its execution at runtime is a table containing instancesof dependant affected objects, each line in this table is atuple of the conforming affected objects. The third phaselocates services that are related to each value returned bythe last SPARQL query1 (8c). According to the abstract ser-vices ontology where we index services to their affectedobjects, we need to query this ontology by another SPARQLquery said SPARQL query2 to return related services at eachinstance of the affected objects. Cartesian product of relatedservices for each tuple of COI will be doing to generate andreturn set of all composite conforming services (8a).

5.1 Preprocessing

In our approach, the semiautomatic composition processstarts when the user draws the composition flow using a set oftools in the interface for modeling the composition process as

123

SOCA

a combination of abstract services (or categories) and controlflow. Based on this module, a first XML file will be generatedcontaining a list of the different abstract services. We gen-erate a second XML file by adding automatically to the firstone the affected objects to each abstract service according tothe abstract service ontology, by considering axioms definedin Sect. 3 and the ObjectsProperty of “affects.”

<abstractService><name> . . .</name><affectedObject> . . .</ affectedObject>

</ abstractService>

Based on these affected objects and their properties, theuser can impose his constraints. Therefore, we add to the sec-ond XML file all LC imposed on attributes of each object,all the relationships between the different attributes (BAC)of affected objects and the semantic relationships (SOR)according to the intermediate ontology.

<localConstraint><Object: attribute_i> . . .

</ Object: attribute_i><value> . . .</value>

</ localConstraint>

<globalConstraint><Object1: attribute_i> . . .

</ Object1: attribute_i ><Object2: attribute_j > . . .

</ Object2: attribute_j ><binaryOperator> . . .</binaryOperator>

</ globalConstraint>

<semanticConstraint><Object1> . . .</Object1><Object2> . . .</Object2><ObjectProperty_k> . . .

</ObjectProperty_k ></ semanticConstraint>

Compared to the intermediate ontology components, wefind that LC is a restriction on a DataProperty, BAC is alsoa restriction on two DataProperty that must be compared,and SOR is an ObjectProperty that must exist between twoconcepts. Therefore, we will extract from the last XML fileand will generate automatically a SPARQL query containinguser restrictions explained in the Sect. 5.2.

5.2 Conforming object values determination

There will be one SPARQL query to generate for all the dif-ferent types of constraints. Based on the second XML file2generated in the previous phase, a generator will rewrite con-straints in SPARQL language as:

1 PREFIX onto:<http://www.owl-ontologies.com/IntermediateOntology.owl#>

2 SELECT ?object1 ?object2...?object_n3 WHERE {4 ?object1 rdf:type onto:Object1.5 ?object2 rdf:type onto:

Object2.....6 ?object_n rdf:type onto:Object_n.

7 ?object_k onto:ObjectProperty_j?object_k’.

8 ?object_i onto:DataProperty_l‘‘value_l’’.

9 ?object_i’ onto: DataProperty_l’?w.

10 ?object_i’’ onto: DataProperty_l’’?r.

11 FILTER(?w binaryOperator ?r ).}

where

2: object1, object2..., object_n are variables that correspondto the affected objects. After the execution of this query,these variables return instances of the affected objects (4–6), which satisfy the list of the constraints (7–11).4–6: Object1, Object2,... Object_n are the list of all affectedobjects listed in XML file2.7: ObjectProperty_j is the semantic relationships imposed bythe user in the SOR between the affected objects(object_kand object_k’).8: DataProperty_l is an attribute of the affected objectdescribed in the local constraints. value_l is its restrictionvalue imposed in LC of the XML file 2.9–10: DataProperty_l’ and DataProperty_l” are attributes oftwo objects (object_i’ and object_i”) to be compared accord-ing to the BAC, filtered in 11. We use FILTER construct ofSPARQL query to compare two attributes.

The role of this SPARQL query1 is to specify constraintson the affected objects and return after execution only con-forming objects values. The execution of this query overthe intermediate ontology will use Description logic andrules reasoning to infer direct or indirect instances valuesof object1, object2,...object_n that satisfy SPARQL queryconstraints listed in WHERE part of the query.

An example of SPARQL query1 for the previous RM1 is

PREFIX onto:<http://www.owl-ontologies.com/IntermediateOntology.owl#>

SELECT ?doctor, ?hospital, ?laboratoryWHERE {

123

SOCA

?doctor rdf:type onto:Doctor.?hospital rdf:type onto:Hospital.?laboratory rdf:type onto:

Laboratory.

?doctor onto:workIn ?hospital.?hospital onto:workWith

?laboratory.?hospital onto:hasType \

‘‘Maternity’’.?hospital onto:hasAdress ?w.?laboratory onto:hasAdress ?r.

FILTER ( ?w = ?r).}

5.3 Conforming composite concrete services determination

The main idea to discover lists of candidate concrete services(8c) is to generate for each value returned by the above stepthe related concrete services according to the abstract serviceontology. For each value, we generate a simple SPARQLquery2 (line 6 of Algorithm 1). The result returned after theexecution of this query is a table with one column of concreteservices saved in a list (line 7). The SPARQL query2 has twoparameters [type of atomic abstract service (aas j ) and thespecified value (COI)] as indicated in (line 6). Its generalform is

PREFIX onto1: http://www.owl-ontologies.com/ AbstractServiceOntology.owl#

SELECT ?xWHERE {?x onto:hasAbstractService

Abstract_S[j].?x onto:affects onto1: A[i,j].}

As an example for the value of “h1” of the Hospital object,we generate the following query:

PREFIX onto1: http://www.owl-ontologies.com/AbstractServiceOntology.owl#

SELECT ?xWHERE {?x onto:hasAbstractService onto:

CMR.?x onto:affects onto1:h1.}

To avoid generating the same query more than one andbecause some values could be occurred in different linesof the table returned by SAPRQL query1, as indicated inTable 2, we create another list (TreatedValue) (line 1) to ver-ify if for a given value, we have not previously (line 5) gen-erate the corresponding query as described in lines 5 and10.

As described in Table 2, the table result of SPARQLquery1 indicates that each line (tuple) in this table is a con-

forming value for the different objects, so we initialize vectorlists (lines 4 and 12) and generate a Cartesian product (lines13–21) for each tuple before moving to the next tuple (lines3 and 22). Line 23 displays conforming concrete services.Moreover, algorithm1 use in lines 13–21 product of lists togenerate Cartesian product for a non-predefined abstract ser-vice number.

Algorithm 1: Algorithm of Locating conforming com-posite concrete services

Input: table A[1..n, 1..m]: result of the SPARQL Query1Input: Abstract_Services[1..m]: list of the abstract servicesResult: SC: list of the conforming concrete services

1 [TreatedValue]= null;2 A = result of SPARQL Query1;3 for i ← 1 to n do4 for j ← 1 to m do5 if A[i, j] /∈ [T reatedV alue] then6 S P ARQL_Quer y2 =

Generate_Quer y(Abstract_Service( j), A[i, j]);7 [Sj] = execute(S P ARQL_Quer y2);8 Add A[i,j] to [TreatedValue] ;9 else

10 [Sj]= Return [Sj] of A[i,j] from [TreatedValue];11 end12 end13 //Generate [S1]x[S2]x[Sm]: phase(8.d)14 for each service sa in [S1] do15 for each service sb in [S2] do16 ...;17 for each service sm in [Sm] do18 SC.add(sa, sb,...,sm);19 end20 end21 end22 end23 Display (SC)

6 Implementation, discussion, and evaluation

6.1 Implementation

The architecture of the composer for querying, selecting,optimizing, and executing is shown in Fig. 6, in whichabstract service ontology, and intermediate ontology are writ-ten in OWL-DL and SWRL languages. We have used ProtegeOWL Plugin [44] and Pellet [41] to develop these ontologiesand verify their consistence. Upon indexing a concrete ser-vice within the abstract services ontology, we assume that theinformation agent has to define manually affected objects andplaces it in their corresponding abstract service within theabstract services ontology with respect to the axioms definedin Sect. 3.3.

The developed prototype of the composer component pro-vides graphical tools to support services composition flow. Its

123

SOCA

Fig. 6 Composer application components

Fig. 7 Screenshot of the interface

interface generator module helps user to specify their queriesby presenting list of categories, available abstract services,type of their affected objects, and list of authorized operatorson these abstract services (Seq, Split-and, Split-or, etc.) asdescribed in Sect. 5.1. The mechanism that relates selectedabstract services with their affected objects and the corre-sponding portion of intermediate ontology where the user canimpose its constraints on the attributes of affected objects orrelations between these objects uses Jena and Pellet Reasonerto select and displays the related semantic from the interme-diate ontology (See Fig. 7). The requested abstract services,the affected objects, and the user constraints are saved in atemporary file; XML File2.

The generator C_values_Module uses SPARQL QueryEngine (Pellet) to query the intermediate ontology to deter-

mine conforming objects values. The Generator C_C_S_Module uses also SPARQL Query Engine to query theabstract service ontology to find related concrete services fora given object value and determines conforming compositeconcrete services.

Optimization module can use any optimization tool toidentify among the conforming concrete services the mostoptimized composite service as in [1,13]. Currently, we aretrying to implement Ant colony algorithm for optimizationwhere ants choose paths according to the result returned bySPARQL queries and values of QoS attributes. SPARQLquery in this case has to indicate satisfaction of functionaluser’s constraints. Finally, the service execution engine has toinvoke the optimized composite service and to return resultsto the user.

123

SOCA

6.2 Discussion

Both the naîve approach presented in Sect. 4 and our pro-posed approach are semantic-based. They locate conformingservices based on user’s constraints and semantic Web ser-vices description.

In our approach, we take into account dependencybetween services by considering the relationships betweenaffected objects. These relationships are directly inferredusing OWL-DL language or indirectly inferred using DL-safe rules. OWL-DL language and DL-safe rule offer a highlevel of expressivity while still being decidable. To query andinfer instances of affected objects satisfying user constraints,we have generated dynamically and at runime SPARQLqueries.

To compare the naîve approach with our proposed appr-oach, we have implemented it. Like our proposed approach,there are three major phases:

• Preprocessing (like in our approach)• Calculate Cartesian product for all requested abstract ser-

vices• For each combination, verify satisfaction of constraints.

The SPARQL queries generated in the naîve approach toverify the user constraints use ASK constructor instead ofSELECT constructor because in this case, we just need tocheck user constraints. In other words, the naîve approachconsists of retrieving all composite concrete services andthen verifies whether they are conforming according to theconstraints.

There are three main differences between these twoapproaches:

1. Number of generated SPARQL queriesThe naîve approach generates for each composite con-crete service a SPARQL query indicating satisfaction ofuser constraints. This implies that it generates an expo-nential number of SPARQL queries.Our selection strategy focuses on the objects and gen-erates only one query to verify the satisfaction of con-straints on objects. The result returned by this query istuples of conforming instances of the requested objects,which means matrix of n*m where n is the number ofaffected objects and m is the number of tuples. Becausewe do not generate treated values and because we deter-mine related services by generating SPARQL query2 foreach value returned by the result of the SPARQL query1,we generate n*m + 1 SPARQL queries, which means apolynomial number of SPARQL queries.

2. Number of generated composite concrete servicesAnother main difference between the two approachesis the number of retrieving composite concrete Web

services. Both the two approaches would generate anexponential number of composite services by calculatingCartesian product and eventually the exponential numberof them. However, our algorithm does not consider non-conforming composite services, which would be avoidedby the process of selecting only conforming object valuesusing the SPARQL query1.The naîve approach may consider an exponential num-ber of all composite concrete services before verifyingif user constraints are satisfied or not. This means that itgenerates all candidate composite services and then filtersconforming composite services among non-conformingcombinations.

3. Number of constraints One of our major contributionis the fact of imposing constraints on affected objects.When we infer conforming objects values by consider-ing all the constraints at once (SPARQL query1), weobtain all dependent instances between objects and soforth between services at once. This implies that when weincrease the number of constraints including the relation-ships (SOR) on the affected objects, we decrease automat-ically the number of conforming objects values. Hence-forth, we decrease the number of generated SPARQLqueries and the number of generated composite services.While increasing the number of constraints in the naîveapproach, it does not affect the number of extracted com-posite services because the verification of constraints isapplied after extraction of all composite services.

6.3 Evaluation

Using Java language and running on Intel Core Duo 2,13 GHzand 4 GB running Windows7, we conducted several exper-iments on our selection approach to evaluate their perfor-mance compared to the naîve approach and we examinedthe scalability as the number of services and affected objectsincrease.

The proposed approach depends on two phases: generat-ing conforming objects values and locating composite ser-vices. In the first phase, constraints play a very importantrole in identifying the conforming objects values. To showhow constraints affect the number of the conforming objectsvalues, we add at each experiment one constraint and wecalculate the number of conforming objects values and thenumber of composite services (experiment 1).

In our approach, only conforming composite services aregenerated and in the naîve approach, all the exponential com-posite concrete services are generated. In the experiment 2,we will test the effect of increasing the requested abstractservices on the number of located composite services. Exper-iments 3 and 4 will show effects of increasing numbers ofconcrete services and abstract services on the execution time.

123

SOCA

Fig. 8 Effect of increasing number of constraints on the extracted com-posite services

6.3.1 Experiment 1: the effect of increasing numberof constraints

To test effect of increasing the number of constraints onthe number of conforming values and the extracted com-posite services, we considered a simple flow model of theprevious example that includes three abstract services. Eachabstract service contains four concrete services. We show infigure Fig. 8 the effect of increasing number of constraintsimposed on the affected objects. The number of constraintsis increased by one at each run.

For each experiment, we generated the correspondingSPARQL query1 and we determined the number of lines(matrix A) returned after its execution. We can see that addinga constraint at each run, between affected objects, can reducesignificantly the number of conforming values. This alsoinvolves reducing the number of related services and so forththe number of located composite services. In the case whenwe have imposed more constraints and there are no conform-ing objects values, obtained in our experiment after addingfive constraints, the number of extracted composite serviceswas also zero. However, the naîve approach, which is notaffected by the number of the constraints, would generate allcombination and then verify satisfaction of the constraintseven in the case of no conforming objects values; it alwaysgenerates the same number of composite services before ver-ifying that at the end, there are no conforming services.

From these experiments, we can conclude that increas-ing number of constraints imposed on the affected objectsaffects efficiently both the number of conforming objectsvalues and the performance of our selection algorithm basedon the affected objects.

6.3.2 Experiment 2: the effect of increasing numberof services on located composite services

In the second set of experiments, we tested the effect ofincreasing the number of requested abstract services speci-

Fig. 9 Effect of increasing number of requested abstract services onnumber of extracted composite services

fied in the user request on the number of retrieved compositeconcrete services. Therefore, we conduct experiments for 3,5, 7, 10 abstract services.

As stated in the discussion section (See Sect. 6.2), thetotal number of composite concrete services identified in ourapproach is less than in the naîve approach, which identi-fies an exponential number of located composite services asshowed in Fig. 9.

6.3.3 Experiment 3: the effect of increasing numberof concrete services

It has been tested how increasing number of concrete Webservices affects the execution time under the flow model ofthe previous example that includes three abstract services.These experiments are conducted against 7, 20, 50, 100, 200number of concrete services. In these experiments, user con-straints and affected objects affecting the three abstract ser-vices are the same; thus, the number of generated SPARQLqueries (SPARQL query1 and SPARQL query2) is alsothe same. This means that execution time in our approachdepends only on the generation of composite concrete ser-vices where concrete services increase to every abstract ser-vice, as shown in the graph in Fig. 10. Time of naîve approachis slightly higher than our approach because as we explainedit in the discussion section (See Sect. 6.2), we eliminate non-conforming objects values before combining all candidateconcrete services, which means that we combine only con-forming candidates concrete services, a subset of combiningall concrete services.

6.3.4 Experiment 4: The effect of increasing numberof abstract services

It is also tested how increasing number of abstract servicesrequested by the user affects the execution time. We con-ducted experiments again for 3, 5, 10, 20. User requestfor each experiment generates SPARQL query1 containing

123

SOCA

Fig. 10 Effect of increasing number of concrete services on executiontime

Fig. 11 Effect of increasing number of abstract services on executiontime

all affected objects of the participated abstract services ofthe request. This means that execution times of these con-ducted experiments set depend on the times of generatingSPARQL queries and on times of generating conformingcomposite services. This explains why in Fig. 11 executiontime is higher of 0.5 seconds than in Fig. 10. It can also beseen that the execution time of naîve approach is slightlyhigher than our approach when we increase the number ofabstract services for the same reason, as indicated above (SeeSect. 6.3.3).

In addition to the experiments 3 and 4, which show theimpact of our approach on the execution time compared to thenaîve approach, experiments 1 and 2 show that our approachgives better results when we impose more constraints on theaffected objects by reducing the number of conforming val-ues and the number of located composite services. From theseresults and the comparison given in the discussion section,it is evident that the proposed approach is more efficient andscalable than the naîve approach.

7 Conclusion and future work

In this paper, we have proposed a semantic approach to selectconforming composite Web services based on imposing con-

straints on the affected objects of the requested services.Our selection for the purpose of the composition locatesdependent services by considering the relationships betweenaffected objects described in an intermediate ontology. Ourselection implementation generates dynamically SPARQLqueries to obtain conforming objects values and related con-crete services.

The main characteristics of our approach are the fact thatwe neglect non-conforming values and we generate a polyno-mial number of SPARQL queries to reduce execution time.Imposing constraints on the affected objects reduces signifi-cantly the number of conforming objects values and so forththe number of generated composite services. As a proof ofconcept, a prototype application has been implemented andevaluated based on the proposed ontology framework.

For our future work, the main challenge is to integrateoptimization phase and semantic selection of conformingWeb services; ants in Ant colony optimization follow pathswith conforming values of concrete services using SPARQLqueries. Furthermore, information agents shall extract auto-matically objects and index concrete services in the abstractservices ontology.

References

1. Zeng L, Benatallah B, Ngu A, Dumas M, Kalagnanam J, ChangH (2004) Qos-aware middle-ware for services composition. IEEETrans Softw Eng 30(5):311–327

2. Hassine AB, Matsubara S, Ishida T (2006) A constraint-basedapproach to horizontal web service composition. In: Internationalsemantic Web conference, pp 130–143

3. Monfroy E, Perrin O, Ringeissen C (2008) Dynamic web servicesprovisioning with constraints. In: Proceedings of 16th interna-tional conference on cooperative information systems, CooPIS’08,OTM conferences, Lecture notes in computer science, vol 5331.Springer, Berlin, pp 26–43

4. Monfroy E, Perrin O, Ringeissen C (2008) Modeling web ser-vices composition with constraints. In: Selected papers of thethird Colombian conference on computer science, special issueof Revista Avances en Sistemas e Informtica 5(1)

5. Zahoor E, Perrin O, Godart C (2009) Rule-based semi automaticweb services composition. In: Proceedings of the 2009 congresson services—I (SERVICES 09). IEEE Computer Society, Wash-ington, DC, pp 805–812. doi:10.1109/SERVICES-I.2009.77

6. Sirin E, Parsia B, Wu D, Hendler JA, Nau DS (2004) HTN plan-ning for web service composition using SHOP2. J Web Semant1(4):377–396

7. Gamha Y, Bennacer N, Vidal-Naquet G, El Ayeb B, Romdhane LB(2008) A framework for the semantic composition of web serviceshandling user constraints. In: ICWS 2008, pp 228–237

8. Yu HQ, Reiff-Marganiec S (2009) A backwards composition con-text based service selection approach for service composition.In: SCC, IEEE international conference on services computing,pp 419–426

9. Gooneratne N, Tari Z, Harland J (2007) Matching strictly depen-dent global constraints for composite web services. In: Proceedingsof the fifth European conference on Web services (ECOWS ’07).IEEE Computer Society, Washington, DC, pp 139–148

123

SOCA

10. Gooneratne N, Tari Z (2008) Matching independent global con-straints for composite web services. In: Proceeding of the 17thinternational conference on World Wide Web (Beijing). China.ACM, New York, NY, pp 765–774

11. Barhamgi M, Benslimane D, Medjahed B (2010) A query rewritingapproach for web service composition. IEEE Trans Serv Comput3(3):206–222

12. Blau B, Neumann D, Weinhardt C, Lamparter S (2008) Planningand pricing of service mashups. In: Proceedings of the 2008 10thIEEE conference on e-commerce technology and the fifth IEEEconference on enterprise computing, e-commerce and e-services(CECANDEEE 08). IEEE Computer Society, Washington, DC,pp 19–26

13. Aggarwal R, Verma K, Miller J, Milnor W (2004) Constraint drivenweb service composition in METEOR-S. In: Proceedings of the2004 IEEE international Conference on services computing (SCC’04). IEEE Computer Society, Washington, DC, pp 23–30

14. Karakoc E, Senkul P (2009) Composing semantic Web servicesunder constraints. Expert Syst Appl 36(8):11021–11029

15. Verma K et al. (2005) The METEOR-S approach for configuringand executing dynamic Web processes, Technical report, large scaledistributed information systems lab. University of Georgia

16. Canfora G, Di Penta M, Esposito R, Villani ML (2005) An approachfor QoS-aware service composition based on genetic algorithms.In: Beyer H.-G (ed) Proceedings of the 2005 conference on geneticand evolutionary computation (GECCO ’05). ACM, New York,NY, pp 1069–1075

17. Wang X-L, Jing Z, Yang H-Z (2011) Service selection constraintmodel and optimization algorithm for web service composition. InfTechnol J 10:1024–1030

18. Alrifai M, Risse T (2009) Combining global optimization withlocal selection for efficient QoS-aware service composition. In:Proceedings of the 18th international conference on World WideWeb (WWW ’09). ACM, New York, NY, pp 881–890

19. Shin D-H, Lee K-H, Suda T (2009) Automated generation of com-posite web services based on functional semantics. Web Semant7:332–343

20. Shin D.-H, Lee K.-H (2007) An automated composition of infor-mation web services based on functional semantics. In: IEEE SCW,pp 300–307

21. Ye L, Zhang B (2007) Discovering web services based on func-tional semantics. In: Proceedings of the 2006 IEEE Asia-Pacificconference on services computing (APSCC 06). IEEE ComputerSociety, Washington, DC, pp 348–355

22. SPARQL 1.1 Query Language. W3C Working Draft 05 Jan-uary 2012. Available at http://www.w3.org/TR/sparql11-query/.Accessed 16 May 2012

23. Boustil A, Sabouret N, Maamri R (2010) Web services composi-tion handling user constraints: towards a semantic approach. In:Proceedings of the 12th international conference on informationintegration and Web-based applications and services (iiWAS ’10).ACM, New York, NY, pp 913–916

24. WS-BPEL 2.0 Tutorial. Available at http://www.eclipse.org/tptp/platform/documents/design/choreography_html/tutorials/wsbpel_tut.html. Accessed 16 May 2012

25. OWL-S: Semantic Markup for Web Services. Available at http://www.w3.org/Submission/OWL-S/. Accessed 16 May 2010

26. Dong J, Sun Y, Yang S, Zhang K (2006) Dynamic Web servicecomposition based on OWL-S. In: Proceedings of science in Chinaseries F. information sciences, pp 843–863

27. Martin D et al. (2005) Bringing semantics to web services: theOWL-S approach. In: Cardoso J, Sheth A (eds) SWSWPC 2004.LNCS 3387, pp 26–42

28. Dong J, Sun Y, Zhao Y (2008) Hierarchical composition of OWL-sweb services. In: Proceedings of the 2008 sixth international con-ference on software engineering research, management and appli-cations (SERA 08). IEEE Computer Society, Washington, DC,pp 187–194

29. Ye Z, Zhou X (2011) Bouguettaya A (2011) Genetic algorithmbased QoS-aware service compositions in cloud computing. In: YuJX, Kim MH, Unland R (eds) Proceedings of the 16th internationalconference on database systems for advanced applications: part II(DASFAA’11). Springer, Berlin, pp 321–334

30. Berardi D, Calvanese D, De Giacomo G, Hull R, Mecella M (2005)Automatic composition of transition-based semantic web serviceswith messaging. In: VLDB, pp 613–624

31. Guermouche N, Godart C (2008) Toward data flow oriented ser-vices composition. In: EDOC, pp 379–385

32. Freuder EC (1982) A sufficient condition for backtrack-free search.J ACM 29(1):24–32

33. O’Connor M, Das A (2009) SQWRL: a query language for OWL.In: OWL: experiences and directions (OWLED), 6th internationalworkshop. Chantilly, VA

34. OWL Web Ontology Language Overview. Available at http://www.w3.org/TR/owl-features/. Accessed 16 May 2012

35. Baader F, Calvanese D, McGuinness D, Nardi D, Patel-SchneiderPF (2003) The description logic handbook: theory, implementation,and applications. Cambridge University Press, Cambridge, MA,pp 43–95

36. SWRL: A Semantic Web Rule Language Combining OWL andRuleML. Available at www.w3.org/Submission/SWRL. Accessed16 May 2012

37. Krisnadhi A, Maier F, Hitzler P (2011) OWL and rules. In: Lecturenotes in computer science vol 6848/2011, pp 382–415

38. Kolovski V, Parsia B, Sirin E (2006) Extending SHOIQ with DL-safe rules: first results. In: Proceedings of the international work-shop on description logic (DL-2006)

39. Motik B, Sattler U (2006) A comparison of reasoning techniquesfor querying large description logic aboxes. In: Hermann M,Voronkov A (eds) Proceedings of the 13th international conferenceon Logic for programming, artificial intelligence, and reasoning(LPAR’06). Springer, Berlin, pp 227–241

40. Kremen P, Sirin E (2008) SPARQL-DL implementation experi-ence. In: Proceedings of the fourth OWLED workshop on OWL:experiences and directions Washington, DC metro, vol 496 CEUR-WS.org

41. Pellet site. http://clarkparsia.com/pellet/. Accessed 16 May 201242. UDDI Spec Technical Committee Draft, Dated 20041019. Avail-

able at http://uddi.org/pubs/uddi_v3.htm. Accessed 17 April 201243. Web Services Description Language (WSDL) 1.1. W3C Note 15

March 2001. Available at http://www.w3.org/TR/wsdl. Accessed15 May 2012

44. Protege OWL plugin. Available at http://protege.stanford.edu/.Accessed 12 May 2012

123