Service Composition With Consistency-based Matchmaking: A CSP-based Approach

Transcription

1 Fifth European Conference on Web Services Service Composition With Consistency-based Matchmaking: A CSP-based Approach Rajesh Thiagarajan Markus Stumptner Advanced Computing Research Centre University of South Australia Mawson Lakes, South Australia {cisrkt,mst}@cs.unisa.edu.au Abstract Automated discovery and composition of Web services and the representation of service semantics required to automate these tasks are active research areas that play a large role in current work on service oriented architectures. In this paper, we investigate the feasibility of service composition powered by a consistency-based approach for candidate selection during composition. The modeling restraints imposed by the existing proposals for candidate selection often result in undesired implications in the form of unintuitive candidates during composition. We formulate a consistency-based candidate selection procedure, which uses specifications based on classical software engineering notations (UML and OCL), and use the selection procedure within a configuration based web service composition setting. The consistency-based matchmaking technique is robust in handling overspecified profiles, assumes a closed world by default and provides provisions to include nonexistence semantics in addition to the standard formalisms. Finally, we formulate service composition as a constraint satisfaction problem (CSP) and provide a CSP based algorithm which uses the consistency-based semantic matchmaking scheme while enabling interactive operation. 1. Introduction The concept of a Service-Oriented Architecture is driven by the loose coupling between applications and their clients. While Web services are not the only way to implement SOA, due to their use of web-based protocols and data interchange formats they currently see the greatest research interest due to their promise of flexibility and interoperability. A key concern in the development of Web service interactions is the need to provide automated support in the location of services that satisfy particular application needs and the ability to use such services in concert to solve more complex application problems. Preplanning and manual combination of Web services into complex structures is a significant bottleneck on the way to establish dynamic interactions and interoperability, an ability which is one of the main perceived advantages of the service-oriented approach over other paradigms. The goal of providing automated support for Web service discovery and combination has led to the development of more advanced service description approaches that employ languages which permit defining not just inputs and outputs but also parts of the semantics of the service. The automated discovery of such Semantic Web services, based on their functionality, is a crucial and an active research area for realizing the functional reuse and automated composition of Web services. A number of different paradigms such as planning formalisms [19, 5, 20, 15] and ontology-based service descriptions [17, 9, 16] have previously been proposed for use in the semantic web, one approach that has recently gained interest is the use of constraint-based technology [1, 11] as an alternative to the standard approaches. Our work was originally driven by the realisation of shortcomings in other approaches, in particular OWL-S 1 with respect to profile matching [3]. Existing specification proposals based on OWL-S have undesired reasoning implications during matchmaking. Contrary to providing supplementary tweaks to OWL-S to overcome its shortcomings, we approach the authoring of service descriptions from a model driven software engineering perspective, using standard SE engineering notation as the starting point, in this case OCL (the Object Constraint Language) defined as part of the UML standard. OCL is a critical supplement to UML because it provides a formal syntax for defining constraints, such as business rules, that cannot be easily captured by UML models in model driven architectures (MDA). OCL syntax closely resembles object oriented programming syntax, and thus is more amenable to developers who are often not trained or at least not fluent in formal meth- 1 OWL-S /07 $ IEEE DOI /ECOWS

2 ods. UML models have the potential to be synthesized into reasonable domain ontologies on the semantic web either based on association semantics [6] or meta-model analysis [18]. While the base UML notation can be used to capture structural features of ontologies such as hierarchies, OCL is suitable (and in fact was designed) to express pre- and post conditions for software engineering purposes - the semantics of software components. OCL features yield better expressiveness of critical knowledge about services which are not easily captured through OWL-S, and build on experience of using OCL specifications for declarative encoding of semantics of complex systems and solving the resulting configuration problem with general constraint solvers (such as ILOG JConfigurator) [8, 1]. In a nutshell, OCL along with UML can be used to represent service semantics. For a detailed discussion on the feasibility of using OCL and UML to describe service semantics see [21]. In this paper, we present a matchmaking scheme based on the combination of modeling (UML) and constraint specification language (OCL) to author service semantics, compare it to existing, in particular description logic (DL)-based matchmaking approaches, and use this as the basis for a composition approach. The rest of this paper is organized as follows. A travel booking scenario with complex requirements presented in Section 2 is used to motivate the proposed research. An account of the consistency-based matchmaking scheme along with a use interactive function for candidate selection is presented in Section 3. Service composition is formulated as a CSP in Section 4. This section also includes a discussion on the user interactive CSP-based composition algorithm. The composition of the example requirements is demonstrated in Section 5. A review of existing related work is provided in Section 6 and the contributions and future work is summarized in Section A Travel Booking Scenario We use the following travel booking scenario to explain the approach. A travel booking consists of a set of airline reservation and hotel booking tasks, in different possible combinations. A task is an atomic activity that can in general be carried out by a web service which advertises a similar function to the task. A task is distinguished by its functional requirements and parameters. For example, an airline reservation task is different from a hotel room booking task and a hotel booking task at location Adelaide is different from a hotel booking task at Melbourne. A travel agent is able to make room bookings and airline reservations. Hotels and airline companies delegate their web based reservation process to external service providers. Service providers or actors expose their reservation process as web services. Service providers may provide a property called creditlevel to indicate their reliability. (Higher is better.) The service providers can furnish any amount of information in their profile or advertisement. The travel agents can search for services with certain (restricted) properties and functionality. The creditlevel value can only be determined after a certain number of transactions with the service providers. Therefore new operators will not be able to give creditlevel information. Generally, new operators will give introductory discounted prices on their services. The agents might take advantage of this fact and search for services that do not yet have a creditlevel, in hope of getting cheaper rates. All the advertisements or profiles are represented as OCL invariants and travel agent queries are represented as OCL queries. A travel agent, being an expert in the travel domain, is able to identify tasks from a customer request for travel booking. Each task has some distinguishable functional requirements and additional general non-functional requirements. Requirement 1 The following tasks t i and nonfunctional requirements or constraints c i are the requirements of our travel booking as identified by the travel agent. t 1 : Make an airline booking starting from Adelaide on the 13/07/2007 to Melbourne and do not spend more than $200. The reliability of the service provider should at least be 5. t 2 : Make an hotel reservation for stay at Melbourne. Checking in on 13/07/2007, checking out on 14/07/2007 and do not spend more than $300. t 3 : Make an airline booking starting from Melbourne on the 14/07/2007 to Sydney and do not spend more than $75.The reliability of the service provider should at least be 5. t 4 : Make a hotel reservation for stay at Sydney. Checking in on 14/07/2007, checking out on 15/07/2007 and do not spend more than $1000 but spend at least $600. t 5 : Make an airline booking starting from Sydney on the 15/07/2007 to Adelaide and do not spend more than $300.The reliability of the service provider should at least be 7. c 1 : The overall travel costs should not exceed $1000. c 2 : The total hotel expenditure should not exceed $

3 3. Consistency-based Candidate Selection Candidate selection is the process of discovering web services from one or more registries by performing a matchmaking operation on the advertisement of the web service capabilities against a set of user specified requirements which in general represents the functionality a user expects the web service to offer. In this section, we present a matchmaking approach that checks for consistency between an advertisement and an user request. The advertisements are expressed through Service Profiles. Definition 1 (Service Profile) A service profile P is defined as a pair P = P attr, P invs where P attr is a set of attributes describing the profile and P invs is a set of invariants of the profile class P. The profile of a service is an advertisement of the capabilities or functionality that the service claims to offer. Its two parts (functional properties or attributes on one hand and invariants on the other) should be satisfied by all the concrete service instances which are advertised using this profile. Example 1 A sales service profile P to advertise sales of some kind of a Book at a price of at-most $30 is modeled as P attr = {item, price} P invs = {item.oclist ypeof(book), price <= 30}. All the concrete services that use the profile P as their advertisement should satisfy P invs. Intuitively all the services that advertise P are services that sell some kind of Book worth at-most $30. To access advertised services, we assume the existence of a registry (e.g., UDDI or semantic registry) that publicizes service profiles. To hide implementation details, we define this abstractly. We refer to this registry as an environment for a service request. Definition 2 (Environment) An environment E is defined as a tuple E model, E state where, E model is a set of service profiles in the environment p ; p E model the symbol allinst E (p) denotes the finite set of concrete services in the environment which satisfies p invs s p (s E state p E model s = allinst E (p)). An environment is a set of service profiles and a set of concrete services. All the concrete services use one of the profiles within the environment as their advertisement. An example environment to demonstrate a travel booking scenario is presented in Section 5. Definition 3 (Service Matchmaking Request) A service matchmaking request R is a set of constraints R cons usually representing the functionality of a web service that a user of the matchmaking procedure is searching for. Example 2 A matchmaking request R for a book selling service which sell a book for less than $30 is modeled as R cons = {s.ocliskindof(salesservice), s.oclast ype(salesservice).item.ocliskindof(book), s.oclast ype(salesservice).price < 30)}. Definition 4 (Constraint Satisfaction Problem) A constraint satisfaction problem (CSP) is defined as a triple V, D, C where V is a set of variables {v 1, v 2,...v n } domain(v i ) denotes the set of allowable values the variable v i can be assigned with. D is a set of domains {D 1, D 2,...D n } such that the D i = domain(v i ) C is a set of constraints that need to be satisfied for any given assignment to the variables in V. Definition 5 (Consistent Service Profiles) Given a service matchmaking request R and an environment E, the function symbol consistent E (R) denotes a set of consistent service profiles such that consistent E (R) E model and p consistent E (R) holds iff R cons p invs is satisfiable. The consistency check (Definition 5) ensures that relevant properties (modeled as OCL invariants) of profile types and request constraints (modeled as OCL queries) do not contradict each other. For a trivial example, for a request R where R cons = {price > 300} and a service profile type T where T invs = {price < 100}, T is inconsistent with R hence T / consistent E (R). The consistency check is performed using a constraint solver such as ILOG JConfigurator [1]. The consistency check of a request R with a profile type T, where T E model, is defined as a triple V, D, C where, V is a set of variables {v 1,..v n } which is constrained in both R cons and T invs. D is a set of domains {D 1,..D n } of variables in V such that each domain D i holds either an enumeration of all permissible values the respective variable data type can take, or a pre-defined range or set. C is a set of constraints {R cons T invs } such that R cons R cons T invs T invs and R cons and T invs have constraints only on variables from V. If there is at least one solution for the CSP V, D, C then T consistent E (R) otherwise T / consistent E (R). Definition 6 (Non Contradictory Services) Given an environment E and a request for web service matches R and a set of profile types P, where P E model and r 1,..., r n denotes the free variables in R cons, we write nc E (R, P ) to denote a set of non contradicting concrete services such that (nc E (R, P ) allinst E (P ) nc E (R, P ) = select E (allinst E (P ), r 1,..., r n )) holds. The first order symbol allinst E (P ) is used to represent a finite set of instances of the profile class P within 25

4 a given environment E. The symbol select E used to represent the set of concrete services, which uses the profile P to advertise its capability, that satisfy the R cons. The definition of non contradictory services in OCL terms is p 1 union(p 2 )... union(p n ).allinstances select(s R cons ). A detailed discussion on the first order symbols allinst E (C) and select E can be found in [4]. All the attributes of the profile instances p i allinst E (P ) are bound to a concrete value for the attribute or have InvalidT ype as its value indicating its non-existence. If no equality relationship is defined over an attribute then this implies the absence of any information about the attribute. The select E determines nc E (R, P ) by querying the attribute-value pairs of all the instances to shortlist the ones that satisfy R cons. The instances may be implemented as database tuples or they may be transcribed into firstorder logic as predicates. The execution of the function select E may be mapped to database search or automatic inference procedures such as resolution to check for logical entailment respectively. Definition 6 helps to filter the irrelevant profile instances from the search. For example, (p.oclist ypeof(salesservice) and p.price = 801) where p is a profile instance holds if and only if p is some kind of sales advertisement and its price is exactly $810. Definition 7 (Consistent Service Matches) Given a service matchmaking request R and an environment E, the functional symbol cmatches E (R) denotes the set of consistent service matches such that cmatches E (R) E state and cmatches E (R) = nc E (R, consistent E (R)). Consistent matches for a service matchmaking request (modeled as a set of constraints) are those instances from E state whose profile type properties are consistent (Definition 5) with the input constraints and instance properties do not contradict the input constraints (Definition 6). A service profile P is a semantic match for a given service matchmaking request R if and only if the profile P advertises the functionality requested in R. As per our matchmaking procedure, all the consistent matches for a given request are semantic matches (Definition 7) Closed World Semantics For Unspecified Values The Closed World Assumption (CWA) states that facts that are not part of the model are considered untrue. Previous works, in particular [10], have suggested that the general open world semantics of the matchmaking approaches, such as [16], that use OWL-S specifications may result in false positives being returned for a request. Consider two services {s 1, s 2 }: one selling a book (Book) and the other selling a computer (P C). Under the Open World Assumption (OWA), unless there is an explicit statement of disjointness Book P C 2 there is some world in which Book 2 It is tedious to state obvious facts and P C mean the same object in the universe of discourse. Under these circumstances, the matchmaking approaches are likely return both the services s 1,2 as matches even if the request only for say a P C sales service. The Book selling service s 1 is a false positive in this case. On the other hand, under the CWA s 1 will not be part of the resultant set. Since our approach assumes closed world semantics by default, when using the advertisement from Example 1, a book selling service that does not include price information will not be returned as a match, since the check price 30 fails Overspecified Profiles overspecified profiles are a problem while selecting candidates because the more information there is in the profile the less preferable the matches turn out to be [16]. This is quite contrasting to the character of advertisements or profiles. Generally, the vendors or service providers would like to put more information in their advertisements to make their services more salable. We take a critical standpoint and argue that overspecified profiles should not qualitatively affect the matchmaking procedure. Example 3 A sales service profile P to advertise sales of a Book at a price of at-most $30 is modeled as, P attr = {item, price, quantity} P invs = {item.oclist ypeof(book), price < 30, quantity < 5}. We demonstrate the robustness of our approach in handling overspecified profiles using the following example. Consider a set of book selling services {s 1, s 2 } which uses the profile P and P from Example 1 and Example 3 respectively as its advertisement. Assume that the service s 1 costs $17 and s 2 costs $15. Under these assumptions our matchmaking approach will return {s 1, s 2 } as the set of semantic matches for the matchmaking request R from Example 2. A subsumption-based matchmaking scheme will differentiate S 2 as being an intersection or weak match because of the presence of the additional information quality in P. On the other hand, our approach does not qualitatively differentiate the matches s 1 and s Non-Existent Semantics Drawing inspirations from the database research on null value semantics, we propose the so-called non-existent semantics for unspecified values in the web service specifications (both Profile and Request). Not specifying the value of a property in general means that such a property exists but it does not have any value yet. Qualifying a property as non-existent implies that such a property does not exist in the profile. We could potentially make the same distinction from the query side as well. Not specifying or restricting a property in the service request normally means that the 26

5 property is not part of the consistency check. But perhaps we want to specify that a certain property should not exist. Search engines such as Google and Yahoo are able to search the traditional web for documents which do not have a particular keyword. Search engines on the semantic web may be made to search for resources which does not define a particular property. The non-existent qualification of a property can be modeled in OCL using the special type called InvalidT ype that exists within an environment E. In the following example, we use symbol to denote the non-existence of a property. Definition 8 (Non-Existent) If A is an atom of the form P (x, y) and L is a literal of the form L = A or L = A then the evaluation semantics of P is as follows. If value(x) = value(y) = then P (x, y) = false L = false. Example 4 A sales service profile C that advertises sales of some kind of Book, at a price of at-most $200 and without the property quantity is modeled as, P attr = {item, price, quantity} P invs = {item.oclist ypeof(book), price < 30, quantity.oclist ypeof(invalidt ype)}. The introduction of the non-existent semantics leads to a number of different cases with different interpretations listed in Figure 1. Our observations on the execution of our consistency-based semantic matchmaking approach with various interpretation is summarized as well. The matches returned in our approach are consistent with the interpretation and assume closed world semantics An Interactive Algorithm for Candidate Selection Algorithm 1 candidates(e, R) Name: Semantic Candidate Selection Algorithm Parameters: E is an environment (Definition 2) R is a service matchmaking request (Definition 3) function candidates(e,r) 1: S cmatches E (R) 2: if S = then 3: R interact with user to relax constraints in R 4: if R R then 5: return candidates(e, R ) 6: else 7: return 8: end if 9: else 10: return S 11: end if Candidate selection is the process of discovering a set of concrete web services from within an environment E such that the discovered services meet the requirements laid our in a service matchmaking request R. Algorithm 1 is our interactive function for candidate selection which uses the consistency-based matchmaking approach defined earlier. The first step of the algorithm is to discover semantic matches for a given request R. If this yields an empty set then it implies that there are no services in the environment E that satisfy the constraints R cons. If smatches E (R) results in an empty set then the user is notified with a message stating that the request is over constrained. The user may then choose to relax some constraints and the original request R is revised into R. The function is then recursively invoked with the revised request R. 4. Service Composition as a CSP Consistency-based configuration has been widely studied and applied to a number of industrial problems (for example see [7]). Web service composition can potentially be modeled as a constraint satisfaction problem. In rudimentary terms, a composition consists of two stages. The first stage where a number of services are discovered from one or more registries such that the discovered services meet the requirements extracted out of user requests. The second stage where the discovered services are used to model a workflow with complete control constructs. Workflow modeling in general is performed by a modeler or a business process architect. Automating the workflow modeling is a complex process in itself hence we limit the scope of this paper and address only the first stage of the composition process. Previous works have suggested that constraintbased systems can be effectively used for service composition (see [1, 11]). However, these works did not address the need for a semantic candidate selection process that is crucial to avoid false positives in the form of functional mismatches while composing. In this section, we present an interactive composition function which uses CSP-based techniques along with a semantic candidate selection mechanism described in the previous section. Definition 9 (Service Composition) Given a complex user task T = {t 1, t 2,..., t n } and an environment E and a set of constraints C that the user requires that composition to satisfy, compositions = {c 1, c 2,...c p } is a set of successful service compositions such that every composition is of the form c i = {s 1, s 2,..., s n } where s i advertises the task requested by t i that is s i smatches E (t i ) An Interactive Algorithm for Service Composition The procedure compose(e, T, C) for composing web services is defined in Algorithm 2 where 27

6 Case Interpretation Consistency-based Approach e-k-v An attribute with a known value exists and the query restricts its value potential match e-k-n An attribute with a known value exists and the query restricts its existence mismatch e-k-o An attribute with a known value exists and the query does not restrict it potential match e-u-v An attribute with an unknown value exists and the query restricts its value mismatch e-u-n An attribute with an unknown value exists and the query restricts its existence mismatch e-u-o An attribute with an unknown value exists and the query does not restrict it potential match n-u-v An attribute does not exists and the query restricts its value mismatch n-u-n An attribute does not exists and the query restricts its existence potential match n-u-o An attribute does not exists and the query does not restrict it potential match e existent, k known, v value, n nonexistent, u unknown, o open Figure 1. Interpretations E is the environment which consists of a repository of service profiles types and concrete service instances T is a set of user identified tasks T = {t 1, t 2,...t n } such that each task t i maps directly to a service matchmaking request (Definition 3).Each t i, apart from having a set of functional constraints (for example, booking a hotel room or making an airline reservation), could also have a set of constraints the user would like the candidate selector to satisfy such as the credit level of the service provider should at least be 5 C is a set of user specified constraints on composition. For example, the sum of hotel charges and flight ticket price should be less than $2500. A CSP can be solved using standard solution algorithms, e.g., as implemented in the ILOG JConfigurator [1]. The call CSP Solver(V, D, C) denotes the CSP solving procedure. The first step of the procedure compose(e, T, C) is to formulate a domain for each of the tasks (Algorithm 2, Line 3). The function candidates(e, t) defined in Algorithm 1 is used to formulate domain for a given user defined task t. Once the domains are created, the user tasks are chosen to represent the variables in the CSP. And finally, a CSP solver is invoked (Algorithm 2, Line 8) to solve the assignment of values to variables from their respective domain such that the constraints C are satisfied. The procedure compose(r, T, C) is also interactive. If the C is too restrictive and the CSP solver is unable to find a valid assignment then the user is notified with a message stating that the CSP is over constrained. The user may choose to relax the constraints in C (Algorithm 2, Line 10) and consequently C is revised as C. The revised constraints are not handled by a recursive call to compose(e, T, C) because the domain formation will then be redundant. Instead the constraint solver is invoked again with the revised constraints while retaining the formulated domains (Algorithm 2, Line10) Architecture The architecture of our system is shown in Figure 2. The semantic specification authoring is based on classical object oriented software engineering notations as we use standard languages such as UML and OCL in the authoring process. In our previous work [21], we have shown that the use of UML and OCL to model specifications results in higher expressiveness than traditional Semantic Web formalisms that have shown to exhibit a number of drawbacks. The resulting specifications also lend themselves directly to the composition task with constraint-based reasoning engines [1, 8]. OCL syntax closely resembles object oriented programming syntax thus developers not trained in formal methods are likely to be more open to accept it because such a setting places service specification modeling analogous to the general design procedures in classical object oriented software engineering platforms. 5. Composing a Travel Booking An ideal environment consists of a domain model and instances of classes within the model (Definition 2). The instances within an environment satisfy the constraints imposed on their type in the domain model. Previous works, in particular [18], have shown that UML models have the potential to be synthesized into domain ontologies for the Semantic Web. To compose our example requirements from Section 2, we assume an environment E represented in Figure 3 and assume its state E State = E hotel E airline from in Tables 1 and 2 respectively. For simplicity, we assume that all the airline services in Table 2 provide daily flights between the cities that are part of the example travel booking and all hotel booking services have room vacancies on the specified dates (see Requirements 1) at their facilities in both Melbourne and Sydney. Please recall the travel booking request from Requirement 1. As mentioned in the requirements, there are five tasks T = {t 1, t 2, t 3, t 4, t 5 } in the composition request and the task requirements are expressed in OCL as follows. t 1 = {s.ocliskindof(salesservice), s.oclast ype(salesservice). item.ocliskindof(t icket), s.oclast ype(salesservice).price < 200), s.creditlevel > 5}. 28

7 Figure 2. System Architecture Algorithm 2 compose(e, T, C) Name: Composition Algorithm Parameters: E is an environment (Definition 2) T is a set of identified tasks. C is a set of non-functional constraints. function compose(e,t,c) 1: D. 2: for all t such that t T do 3: D t candidates(e, t). 4: D D {D t }. 5: end for 6: if / D then 7: V {v i t i T } 8: compositions CSP Solver(V, D, C) 9: if compositions = then 10: C interact with user to relax constraints in C. 11: if C C then 12: return CSP Solver(V, D, C ) 13: else 14: return 15: end if 16: else 17: return compositions 18: end if 19: else 20: return 21: end if Service ID Service PM PS 1 Uni Lodge YHA Budget Motel Park Inn Rex Bay View Pacific Hyatt Taj Novotel Meriton Hilton PM Price at Melbourne, PS Price at Sydney Table 1. Hotel Reservation Services State: E hotel t 2 = {s.ocliskindof(salesservice), s.oclast ype(salesservice). item.ocliskindof(roombooking), s.oclast ype(salesservice).price < 300)}. t 3 = {s.ocliskindof(salesservice), s.oclast ype(salesservice). item.ocliskindof(t icket), s.oclast ype(salesservice).price < 75), s.creditlevel > 5}. t 4 = {s.ocliskindof(salesservice), s.oclast ype(salesservice). item.ocliskindof(roombooking), s.oclast ype(salesservice).price > 600), s.oclast ype(salesservice).price < 1000}. t 5 = {s.ocliskindof(salesservice), s.oclast ype(salesservice). item.ocliskindof(t icket), 29

8 Service ID Instance A-M M-S S-A CL 13 Jet Star Qantas Emirates A-M Adelaide to Melbourne, M-S Melbourne to Sydney, S-A Sydney to Adelaide, CL Credit Level Table 2. Airline Services State: E airline s.oclast ype(salesservice).price < 300), s.creditlevel > 7}. Due to space restrictions the locations properties are not mentioned in the OCL representations listed above, however, we assume the location properties from the individual task requirements themselves as given for our example composition. The function compose(e, T, C) defined in Algorithm 2 is invoked to begin the composition process. The first stage of the function is to formulate the domain D such that functional requirements of all the tasks t i are satisfied (Algorithm 2, Line 3). After this intermediate step the following are the values of T,D and C. Tasks T = {t 1, t 2, t 3, t 4, t 5 } Domain D = {D 1, D 2, D 3, D 4, D 5 } where - D 1 = {jetstar, qantas, emirates} - D 2 = {jetstar, qantas, emirates} - D 3 = {jetstar} - D 4 = {jetstar, qantas, emirates} - D 5 = {qantas, emirates} Constraints C = {c1, c2} Once a finite non-empty domain is formulated for every task, a set of variables V = {v 1, v 2, v 3, v 4, v 5 } is created. A CSP solving process CSP Solver(V, D, C) is then initiated (Algorithm 2, Line 8). Given the environment E, for this example there are no solutions such that all the constraints in C defined in Requirements 1 are satisfied thus the solver returns an empty set. After this intermediate step, the user is notified that the problem is actually overconstrained (Algorithm 2, Line 10). Assume that the user chooses to relax the overall expenditure constraint (c 1 ). The overall expenditure constraint c 1 is revised as The whole holiday should not cost more than $1110 (c 1). The revised set of constraints is C = {c 1, c 2 }. A CSP solution process is initiated again but this time with the function call CSP Solver(V, D, C ). For this example there exists a composition such that C is satisfied. The variable assignments of the composition are {v 1 = jetstar, v 2 = yha, v 3 = jetstar, v 4 = pacific, v 5 = qantas}. The travel agent interprets this composition in the following manner. Flying Jet Star from Adelaide on the 13/07/2007 to Melbourne. The cost of the flight is $115. Staying at YHA, Melbourne from 13/07/2007 to 14/07/2007. The cost of the booking is $90. Flying Jet Star from Melbourne on the 13/07/2007 to Sydney. The cost of the flight is $51. Staying at Pacific, Sydney from 14/07/2007 to 15/07/2007. The cost of the booking is $601. Flying Qantas from Sydney on the 15/07/2007 to Adelaide. The cost of the flight is $251. The total cost of the travel booking is $1108. The solution above was computed using our own CSP solver (implemented in Cincom Visualworks/Smalltalk). 6. Related Work Albert, Henocque, and Kleiner [1] studied the feasibility of composing workflow using configuration techniques. The configurator (JConfigurator) in their prototype uses backward chaining techniques to compose a workflow which is an instance of the constraint object model that is modeled by a modeler as an abstract workflow. The matches are determined based on types of inputs and outputs (using adapters if necessary) and thus the approach is rather syntactical; there is no explicit consideration of more complex semantics (although the possibility is considered). Hassine et al. [11] formulated the Web service composition problem as a constraint optimization problem (COP). In their approach the constraints are of two types namely soft (can be relaxed when the problem has no solution) and hard constraints (must be satisfied). Apart from this each service has a user preference (numeric value) associated with it. The set of variables in the problem denoted abstract workflow components that need to be allocated to concrete services from their respective domains. The constraints, in general, can be classified as parameters for the configuration process. For example, X1.Amount X3.Rate+X4.Rate where X i is a variable in the COP. The hard and soft constraints do not completely capture the notion of the desired functionality restriction. It is likely that services that satisfy hard and soft constraints are functional mismatches. On the other hand, user defined tasks are augmented with functionality restrictions in our approach. Furthermore, parameters for the compositional process may be modeled as non-functional constraints. A planning approach with casual link calculation between web services under the CWA was proposed in [15]. Again, the main focus here is to obtain a plan of web services such that any predecessor and its successor entity of the plan will have input and output compatibility in a variety of levels. The inference based on only input and output data types is rather weak because it is likely that services that match the input and output requirements are functional mismatches. This does not affect the generation of correct composition but during the process the approaches may produce a number of false positives. On the other hand, in our approach, capability description matchmaking is the distinctive feature and thus the composed services strictly satisfy the functionality requirements provided in the user task. Provisions for modeling input and output compatibilities are provided in the form of non-functional constraints. 30

9 Figure 3. Environment: Domain Model and Instances A good representative of ontology-based resource matchmaking approaches is the description logic (DL) framework of [16]. Semantic Web advertisements and query descriptions are modeled using the DL SHOIQ which is roughly as expressive as OWL. The framework outlines a subsumption based reasoning procedure that would resolve advertisement matches for a given query. A semantic matchmaker that uses a subsumption based reasoning technique was deployed within a UDDI repository and its quantitative effects were studied in [14]. A similar matchmaker was devised in [13] to handle service specifications modeled using a variant of the web service modeling language (WSML) called WSML-MX based on F-logic. As pointed out in [13] the semantics of the WSML is currently open. This in-progress nature will affect the seamless integration of services as it will potentially lead to the development of a number of variants grounded with different semantics. On the contrary, we define service specifications with already standardized comprehensive languages. The need for visual means to develop ontologies at an abstract level hiding the verbose semantic web formalisms was argued in [12]. UML was used as a visual paradigm to develop service descriptions and service requests. The descriptions themselves were graph transformation rules that describe transformation of the output from the given inputs over a domain ontology. Matchmaking was performed by checking logical entailment between the descriptions and the request. While employing UML as a visual means is pragmatic especially considering the verbosity of the existing formalisms, UML is only able to represent structural semantics such as an Order is associated with a Bill. Complex semantics such as functional, attribute value restrictions and non-functional requirements are not representable in UML. Some of these requirements motivated the development of OCL. Our work benefits from the use of OCL along with UML by providing a standard language to represent the above mentioned semantics. Traditional DL-based approaches (such as [16]) suffers from the general open world semantics that is implicit within the specifications [10]. Extending the logic with an epistemic operator will force the treatment of unspecified values with closed world semantics. In such a setting any unspecified property is treated as unknown at this moment [10]. On the other hand, we have demonstrated in Section 3.1 that the local closed-world semantics is intuitively implicit in our matchmaking technique. Furthermore, we have explored additional nonexistence semantics to qualify unspecified properties. The absence of constructs in OWL-S to express additional stronger constraints, that restrict properties beyond a single service boundary, within a complex composition was pointed out in [2]. The extension of semantic web languages such as OWL-S with stronger semantics in the form of invariants in a composition was proposed. While this is a reasonable extension to the lan- 31

10 guages, it is to be noted that our approach provides provisions for the inclusion of constraints, that govern more than one service within a composition, in the form of nonfunctional restrictions. Both other constraint-based approaches [11, 1] catered for user preferences, but the constraints in both these approaches are mainly configuration parameters rather than full constraint consistency and hence fall short in achieving semantic candidate selection that is crucial for fulfilling the envisioned advantages of semantic service matching such as functional reuse. Our work can be seen as an extension to these approaches. The novelty of our work stems from the application of a consistency-based semantic matchmaking technique within the CSP-based algorithm to compose services. OCL, in combination with UML, enables the authoring of the types of descriptive semantics employed in semantic web service technology, in the guise of classical OO design notations, thereby creating a sense of familiarity to the notations for the developers or business experts. 7. Summary and Future Work We have presented a CSP based web service composition approach that is powered by a consistency-based matchmaking scheme. The notable features of the candidate selection procedure are the robustness in handling overspecified profiles, the implicit closed world assumption and the provision for expressing additional non-existence semantics while checking for consistency between service advertisements and user requests. The use of standard languages (UML and OCL) for defining service specifications and user requests gives better expressiveness, ease of use and the sense of familiarity with traditional notation in comparison with traditional semantic web languages, while the CSP-based formalization enables the use of standard CSP inference algorithms as implemented in our constraint solver (or commercial systems). Thus complex discovery and composition tasks can be effectively carried out using our approach. Further work in this direction is to extend the consistency-based matchmaking approach to handle multiple and distributed environments. References [1] P. Albert, L. Henocque, and M. Kleiner. Configuration Based Workflow Composition. In Proc. of ICWS 2005, July [2] V. Alevizou and D. Plexousakis. Enhanced specifications for web service composition. In Proc. ECOWS, pages , Zürich, Switzerland, Dec [3] S. Balzer, T. Liebig, and M. Wagner. Pitfalls of OWL-S: a practical semantic web use case. In Proc. ICSOC 2004, pages , New York, NY, USA, Nov [4] B. Beckert, U. Keller, and P. H. Schmitt. Translating the Object Constraint Language into first-order predicate logic. In Proc. of VERIFY at FLoC, Copenhagen, Denmark, [5] M. T. et al. ASTRO: Supporting Composition and Execution of Web Services. In Proc. ICSOC, pages , Amsterdam, The Netherlands, Dec [6] K. Falkovych, M. Sabou, and H. Stuckenschmidt. UML for the Semantic Web: Transformation-Based Approaches. In Knowledge Transformation for the Semantic Web, pages [7] A. Felfernig, G. Friedrich, D. Jannach, and M. Stumptner. Consistency based diagnosis of configuration knowledge bases. In Proceedings of the European Conference on Artificial Intelligence (ECAI), Berlin, Aug [8] A. Felfernig, G. Friedrich, D. Jannach, and M. Zanker. Configuration Knowledge Representation Using UML/OCL. In Proceedings UML 2002, LNCS 2460, pages 49 62, Dresden, Oct Springer. [9] A. Gómez-Pérez, R. González-Cabero, and M. Lama. ODE SWS: A Framework for Designing and Composing Semantic Web Services. IEEE Intelligent Systems, 19(4):24 31, [10] S. Grimm, B. Motik, and C. Preist. Matching Semantic Service Descriptions with Local Closed-World Reasoning. In Proc. of ESWC 2006, pages , Budva, Montenegro, June [11] A. B. Hassine, S. Matsubara, and T. Ishida. A Constraint- Based Approach to Horizontal Web Service Composition. In Proc. ISWC, Athens, GA, USA, Nov [12] J. H. Hausmann, R. Heckel, and M. Lohmann. Model-based Discovery of Web Services. In Proc. of ICWS 2004, pages , California, USA, [13] F. Kaufer and M. Klusch. WSMO-MX: A Logic Programming Based Hybrid Service Matchmaker. In Proc. ECOWS, pages , Zürich, Switzerland, Dec [14] T. Kawamura, J.-A. D. Blasio, T. Hasegawa, M. Paolucci, and K. P. Sycara. Public Deployment of Semantic Service Matchmaker with UDDI Business Registry. In Proc. ISWC, pages , Hiroshima, Japan, Nov [15] F. Lécué and A. Léger. Semantic Web Service Composition Based on a Closed World Assumption. In Proc. ECOWS, pages , Zürich, Switzerland, Dec [16] L. Li and I. Horrocks. A software framework for matchmaking based on Semantic Web technology. In Proc. of WWW 2003 Conf., pages , Budapest, May [17] S. A. McIlraith and T. C. Son. Adapting golog for composition of semantic web services. In Proc. KR, pages , Toulouse, France, Apr [18] H.-S. Na, O.-H. Choi, and J.-E. Lim. A Metamodel-Based Approach for Extracting Ontological Semantics from UML Models. In Proc. of WISE 2006, pages , Wuhan, China, Oct [19] M. Pistore, A. Marconi, P. Bertoli, and P. Traverso. Automated composition of web services by planning at the knowledge level. In Proc. IJCAI, pages , Edinburgh, Scotland, July [20] E. Sirin, B. Parsia, D. Wu, J. A. Hendler, and D. S. Nau. HTN planning for Web Service composition using SHOP2. Journal of Web Semantics, 1(4): , [21] R. Thiagarajan and M. Stumptner. A native ontology approach for semantic service descriptions. In Second Australasian Ontology Workshop (AOW), volume 72 of CRPIT, pages 85 90, Hobart, ACS. 32