An Alternative Approach to Service Repositoriesand Automatic Service Composition

Adrian Fiech1, Matthias Tilsner1,2, Guangyao Zhan1, and Thomas Specht2

1 Memorial University of Newfoundland, St. John’s, Canadaa.fiech,matthias.tilsner,gzhan@mun.ca

2 Hochschule Mannheim, Mannheim, Germanym.tilsner,t.specht@hs-mannheim.de

Abstract. Service-oriented Software Engineering embraces the construc-tion of software systems from available modules that can be acquiredfrom service providers and assembled into a complete system. Usually,a mechanism for service publication and discovery is provided. In thispaper we propose a curated approach to service repositories, which areclosed collections of well chosen service specifications. Only services thatimplement one of the contained specifications can be registered. We for-mally define service repositories and show how our approach can be usedfor automatic service compositions.

Keywords: service repositories, web composition models and languages,service-oriented software engineering

1 Introduction

In the field of Software Engineering, software reuse has become one of the majorissues for both industry and research. New architectural concepts such as Service-Oriented Architecture (SOA) embrace reuse as their primal agenda. Rather thanaiming at implementing one piece of software, developers split the applicationinto smaller parts, called services. Each service concentrates on a single aspectand thus can be reused in future applications.

Unfortunately, simply reusing web services is not as easy as one would hope.First, we must be able to find the appropriate services, which is not trivial. Searchqueries must be formulated in some language and the behavior of the desiredservices captured. Also, automatic composition of services is challenging.

As of now only few repositories (others call them service registries) have beenestablished that provide consumers with a list of available services. One of the mostpopular examples is ProgrammableWeb [1]. This website allows service providersto register their services, called APIs. It also lists existing applications thatuse these APIs. Such repositories provide users with an overview over availableservices and the tools for building compositions of their own. In ProgrammableWebany kind of services can be added. When searching for a particular service usersare aided by service categories. These categories resemble semantic entities thatput services into context and approximate the semantic meaning of the service.

While these entities do carry a limited amount of semantic information, thecorresponding services require extensive analysis from service consumers beforethey can be used.

Unfortunately this approach does not satisfy our requirements. We strivefor repositories where we can formally reason about the behavior of servicesand provide operational guarantees about their functioning. Another goal of ourapproach is the automatic selection of services that satisfy clients’ requirements(either a direct match or composition of several services).

In our approach, we embrace unambiguous specifications that define the precisefunctionality of services. At the same time we see it as counterproductive to affordservice providers the latitude to develop their own specifications. In such scenariowe end up with a number of services with closely related, but nevertheless distinctspecifications. Instead, we propose the definition of a finite set of standardizedspecifications for each problem domain. As a direct result, any service in therepository must behave consistently with one of the specification standards. Toreiterate, our repositories are primarily collections of service specifications andnot collections of services per se. The loss in flexibility on part of service providersis compensated by a rather simple and intuitive framework for automatic servicecomposition (once we abstract from the formalism).

In section 2 we draw inspiration from a traditional “brick and mortar” ap-proache to selling products (services). Section 3 introduces a small case study,where we investigate questions arising during configuration of a repository for aflight planning domain. Section 4 provides us with formalization of the presentedconcepts. In Section 5 we discuss service compositions and specification matching.We compare our approach to related work in section 5 and conclude in section 6.

2 Brick and Mortar Analogy

In this section we provide our perspective on service repositories. We drawparallels to the standard “brick and mortar” model of warehouses and investigatehow approaches found there can be transferred into purely web based repositories.We use a small case study, where the “brick and mortar” warehouses deal inbicycle parts. On the other hand we look at repositories of flight schedulingservices. Although it may appear that these two cases have little in common, webelieve that comparing them will be helpful in arriving at proper understandingof what service repositories should be about.

2.1 Management

In the brick and mortar world of bike part warehouses, the warehouse has completecontrol over the kind and variety of parts offered to customers, the part suppliers,pricing, etc. Here we make the claim that the successful warehouses distinguishthemselves from the failed ones through the right selection of provided parts, easyaccess and search of the parts, well specified catalogs and reasonable choice ofparts’ suppliers. It is our opinion that similar idea applies to service repositories.

We reject the idea of repositories open to everybody, which try to catalog everyavailable service/service provider available on the Web. Choices (sometimesdifficult) must be made and a healthy balance between vast offering and usability(e.g. easy search functions, behavioral matching that can be accomplished inreasonable time) must be achieved.

2.2 Parts Specifications

Parts available in the bike warehouse are described with several attributes.When warehouse operator is looking for new suppliers, he/she provides partspecifications to the prospective business associates. They in turn offer theirparts that satisfy the specifications and the warehouse makes the decision whichsuppliers to select. We don’t see things (much) different for service repositories.The parts are services that satisfy specification that were selected by the softwarewarehouse.

2.3 Inventory and Part Selection

The warehouse needs suppliers who provide parts found in the catalog. Forexample there will be many suppliers for 722-28 tiers (e.g. Vittoria, Continental).They will have different prices, quality attributes, reputation, etc. Similar appliesin the software world. Each service specification will have a number of servicesthat implement such specification. These services will be offered by differentproviders, at different cost, with varied performance and quality parameters andimplemented on different platforms and using different technologies.

Our developers will browse specification catalogs and then select services (e.g.allFlightsBetween(origin, destination)) based on some criteria (price, reliability),purchase the services (on a per access basis, flat rate, monthly, ...), integratethem into their web based application and offer the product to travel inspiredcustomers.

Here we want to emphasize again that as in the warehouse, it is the man-agements decision which specifications are included in the catalog and whichproviders supply the web services. It is also the management’s responsibility toassure that included services indeed satisfy these specifications.

2.4 Sound Advise

In the physical world, a solid advise provided to bike manufacturers (assemblers)is expected. If a bike manufacturer is searching for a complete 722-28 wheel/tirecombination (not available in the shop), it would benefit the warehouse to suggestthat such wheel can be assembled from a 722-19 rim, 722-28 tire, spokes and ahub that (incidentally) are available in the warehouse. Similarly, if a softwaredeveloped is searching for a service that provides the next flight (to somewhere)from a given city, but we only have services that provide flights from airports,a good repository should inform the developer that a combination of servicesnextFlightFromAirport and airportsInCity will fulfill the desired goal.

2.5 Summing-up

To summarize, we see significant parallels between the brick and mortar ware-houses and web service repositories. Parts available in the warehouse (e.g. crank,brake) correspond to web services provided by repositories (e.g. nextFlightFro-mAirport(airport) ). Part specifications (e.g. 11-28 cassette, 5 speed) correspondto description of service’s behavior (e.g. validAirport(input) ∧ flightOriginatesFro-mAirport(output,input). Responses to inquires are either sets of parts (Shimanoor Shram cassette) that satisfy the specification (including composed parts) orpaths of possible service compositions (nextFlightFromCity , airportsInCity +nextFlightFromAirport). The expertise of the warehouse staff should be encodedin a repository as well.

3 Configuration of a Flight-Planning Repository

In this section we turn our attention to configuration issues of a sample Flight-Planning repository (formal treatment is provided in the next section). Anextended discussion of design issues for the Flight Planning repository can befound in one of the authors’ thesis [15]. There are several stakeholders in therepository: repository operator, service providers, service consumers (developerswho assemble web applications from the provided services) and their clients (e.g.travel agencies). All of them have diverging needs.

As we mentioned before, our repository is basically a collection of specificationsplus a mapping from these specifications to concrete services. The first decisionwe make is the selection of a language for this specifications.

3.1 Specification Language

Data Types Data types describe the permissible values for inputs and inputsof a service. In the Flight-Planning domain the obvious candidates are: Airport,Flight, Connection, Itinerary, Date, Time, etc. We could include Citythere as well. This is a configuration decision that has implication on the kindof services that can be access via the repository. In both cases we can havethe service directAirportFlights(origin: Airport, destination: Airport) thatreturns a list of all direct flights from the origin airport to the destination airport.By including City, we make a similar service possible: directCityFlights(origin:City, destination: City). Per se, there is no right or wrong decision aboutincluding City as a type. We should understand though that our decisions haveconsequences.

Pre- and Post-Conditions Another part of the puzzle is the selection of properpredicates. They are used to describe pre- and post-conditions in service speci-fications. A selection of possible predicates could include: validAirport(airport:Airport), directFlight(flight: Flight), airportInCity(airport: Airport, city:City), nearby(airport1: Airport, airport2: Airport) or travelTimeBound(lst:

List[Airport], city: City, t: Minutes). We certainly hope that the predicate’smeaning can be implied from it’s name, but hope is fickle and we provide a modelfor our language later on. The art of repository configuration involves skillfulselection of the appropriate types and predicates in such way that the relativelysmall core puts us in position to specify a vast variety of useful services.

Encoding Human Knowledge Certain human knowledge should be encodedin the repository. For example in our case it might be beneficial to capture the fol-lowing information: (∀flight∀airport∀city flightFromAirport(flight, airport)∧airportInCity(airport, city) ⇒ flightFromCity(flight, city)). This informa-tion will aid us in identifying appropriate compositions of services that satisfyour clients’ demands.

3.2 Types and Predicates Model

Although we tried to select intuitive names for types and predicates, if we wantto formally reason about properties of our services and specifications, we needto be more specific what these terms actually mean. We do it by providingreference implementation for types and predicates. Let’s consider a predicateairportNearbyCity(airport, city, time). The reader might have concluded thatthis predicate returns true if the airport is close to the city. Now, how manyinterpretations of the term “nearby” do we hear? Which one is close by, an airport60 km away and reachable in 70 min by car or an airport 150 km away reachablein 30 min by train? In this case we configure our repository by deciding that thepredicate airportNearbyCity(airport, city, time) returns true if the airport canbe reached from the city by public transportation within time minutes. Mostdevelopers probably will be satisfied by the above description. We back it up byproviding a reference implementation of the predicate, which queries some databases for the travel time.

3.3 Specification Selection

The configuration decision about types and predicates affects the service specifica-tions that can be expressed in our framework. But selecting the right specificationsthat are “admitted” into our repositories is another configuration decision. Itis our postulate that repositories are not collections of arbitrary specifications,but catalogs of specifications deliberately selected by repository configurators(the way bike warehouse operator decides about the parts that are stored inthe warehouse). This important configuration decision affects how usable therepository will be. The goal is to include specifications that either match directlythe majority of likely service-consumer queries or that can be combined to obtainthe desired match.

In our case, we might include service specification for directFlights(origin, desti-nation) in our repository catalog, but omit specification for connectingFlights(origin,destination). The choice of the parts (or more precisely part specifications) to be

offered will be influenced by the product palette of the existing (service) suppliersas well as by the wishes/demands from (service) consumers. To arrive at the rightbalance, intense dialog between repository managers, part (service) suppliers andpart (service) consumers must take place.

3.4 Supplier Selection

After selecting the specifications included in the repository, the repository operatorwill settle on suppliers who will provide the services. Most likely the decisionwill be based, among others, on reputation, reliability and price. Here a subtledifference between physical warehouses and repositories exists. Where it may bethrilling for a bike assembler to find the desired 52 aluminum frame availablein 40 different brands, stockpiling all of them would be a nightmare for thewarehouse operator. For our repositories, the magnitude of service specificationsis dangerous, not the plethora of implementations satisfying the specification.There is very little that prevents us from “attaching” hundreds of services to agiven specification.

4 Repository Formalization

In this section we are going to provide the formal framework for our servicerepositories in a first-order language. (For the logical foundation of the treatmentthe reader is referred to [4].)

A service repository is a collection of service specifications. Each specificationhas a corresponding set of services that implement it. These actual servicesplay a rather secondary role in our discussions, though. Service specificationsprovide us with information about services’ input types, output types, pre- andpost-conditions that a service must satisfy.

Service repositories are domain-specific. When we formalize a service reposi-tory, we always consider a fixed set of objects (called the domain of discourse)and a fixed set of relations (called predicates) between these objects. We havea fixed first-order structure (called a model) M =

DM, PM, NM

for a service

repository with a fixed first-order language L, where DM is the domain of dis-course, PM is the set of predicates, and NM is a naming function that mapsconstant names in L to objects in DM. It should be noted that all semanticdefinitions introduced below will implicitly assume such a model M.

4.1 Data Types

Data types are fundamental building blocks of service repositories. A repositorywill have a finite set of basic data types denoted by TB . We construct T, the setof all possible data types with the help of a few type constructors.

Definition 1. Let TB be a finite set of basic data type names. We inductivelydefine T, the set of repository data type, as (a) TB ⊆ T (b) ∀t ∈ T : List[t] ∈ T(c) ∀t1, t2 ∈ T : Map[t1, t2] ∈ T (d) ∀t1, t2 ∈ T : Tuple[t1, t2] ∈ T

All data types are backed up by concrete implementations in a given hostlanguage chosen by repository designers. Here we will choose Scala as a hostlanguage. The operator (t) describes the reference implementation of t in thechosen host language. For example,

(Airport) = class Airport(name: String, code: String)

Definition 2. Let t ∈ T be a data type. We define the set of t-instances as

t = o | o is an instance of (t)

The union of all objects over all types defines the domain of discourse DM.

4.2 Services and Service Specifications

The actual services that providers host and consumers eventually invoke are notour primary concern in a service repository since we are interested only in theirspecification. Nevertheless, we define them formally in order to have a context todescribe service specifications later.

Definition 3 (Service). A service f in model M is a binary relation on thedomain of discourse DM, i.e. f ⊆ DM ×DM.

In practice, most services are defined only on some subsets of DM. Thebehavior of a service taking an input out of range is undetermined. The mostcommon way to describe the range of input a service accepts and the rangeof output a service produces is to specify the input and output type. Thecombination of input and output type of a service is called the service’s signature,or its syntactic interface. For example, a service that takes an airport and returnsa flight departing from that airport will have the signature Airport× Flightwhere Airport is its input type and Flight is its output type. We describe aset of services sharing the same signature, pre-condition, and post-condition witha service specification.

Definition 4 (Service Specifications). An L-service specification is a pairof formulas (φ, ψ) where φ contains one free variable in, and ψ contains twofree variables in and out. We write Π, Ω, φ, ψ as a syntactic sugar for anL-specification (τΠ(in) ∧ φ(in), τΩ(out) ∧ ψ(in, out)), where Π ∈ T is the inputtype, Ω ∈ T is the output type and τt is the type predicate. The meaning of anL-specification (φ, ψ) in M is defined by the set of services that implement thespecification. (φ,ψ)M = f ⊆ DM ×DM | ∀ x, y ∈ f M |= (φ ⇒ ψ)[in →x, out → y]

4.3 Service Repositories

Let SL be the set of all possible L-service specifications, and SLf ⊂ SL be

the set of all possible quantifier-free (no ∀ or ∃) L-service specifications. A

service repository consists primarily of service specifications. There are infinitenumber of quantifier-free service specifications in a first-order language L. Aservice repository can contain only a finite number of them. In addition, eachspecification in a repository must point to a number of concrete services thatimplement it.

A set of first-order sentences in L is called a theory. Each sentence in T mustbe evaluated true in M, in which case we say M satisfies T , denoted by M |= T .In each repository there is a fixed theory T (encoding of human knowledge).

Definition 5. A repository R is a tupleT,L, T ,M, SL

R,mR, where T is the

set of data types, L is a first-order language, T is an L-theory, M is a first-orderstructure for L such that M |= T , SL

R ⊂ SLf is a finite set of quantifier-free

L-service specifications and mR is a mapping from SLR to the power set of VR

such that mR(s) ⊂ s. Here VR =

s∈SLR

s is the set of concrete services.

5 Automatic Service Composition

In this section we are going to present the mechanism to automatically matchand compose specifications/services. A detailed discussion and proofs for thepresented theorems can be found in [15].

5.1 Matching of Service Specifications

Definition 6 (Matching). Let (φ1,ψ1) and (φ2,ψ2) be two L-service speci-fications. We say that (φ1,ψ1) matches (φ2,ψ2) under theory T , denoted by(φ1,ψ1) T (φ2,ψ2), if and only if T ∀in (φ2 ⇒ φ1) and T ∀in ∀out (φ2 ∧ψ1 ⇒ ψ2).

The operator T is reflexive and transitive. A detailed discussion of thedefinition can be found in [15].

Theorem 1 (Semantics of Matching). Let s1 and s2 be two L-service speci-fications. If s1 T s2, then s1 ⊆ s2.

5.2 Composition

Many services can be chained together to perform more complex operations. Wedesire a way to describe the behavior of these composed services by combiningtheir specifications.

Definition 7 (Composition of Specifications). Let (φ1,ψ1) and (φ2,ψ2) betwo L-service specifications with free variables in1, out1 and in2, out2, respectively.We say that (φ1,ψ1) can be composed with (φ2,ψ2) under T , denoted by (φ2,ψ2)T(φ1,ψ1), if and only if T ∀in1∀out1(φ1 ∧ψ1 ⇒ (φ2[in2 ← out1])). The result ofthe composition is a new specification (φ2,ψ2)T (φ1,ψ1) = (φ1, ∃tmp (ψ1[out1 ←tmp] ∧ ψ2[in2 ← tmp])) with the free variables in1 and out2. The variable tmpmust be chosen so that it does not cause name collisions with existing variablesin the formula.

Proposition 1 (Monotonicity of composition). Let s1, s2, s3 and s4 beL-specifications. Furthermore let s1 s3, s2 s4, s2 T s1 and s4 T s3. Thens2 T s1 s4 T s3.

Definition 8 (Composition of Services). Let f, g ⊆ DM ×DM be two ser-vices. The composition of f and g, denoted by g f , is a new service

g f = x, z ∈ DM ×DM| ∃y ∈ DM (x, y ∈ f ∧ y, z ∈ g)

Theorem 2. Let T be a first-order theory in L and let M be a structure for Lsuch that M |= T . Moreover let s2 T s1. If f1 ∈ s1M and f2 ∈ s2M, thenf2 f1 ∈ s2 T s1M.

5.3 Queries

Let R be our repository. A query q for R is a quantifier-free service specificationin SL

f . Theorem 1 states that if we have a specification that matches a query,all services that satisfy that specification also satisfy the query. Our matchingalgorithm introduced further down will follow this idea.

Service consumers submit queries to a service repository to retrieve matchingservice specifications so that they can in turn find actual services that implementthese service specifications. Therefore the result of submitting a query to a servicerepository should contain service specifications that directly match the query,as well as chains of service specifications such that the composition of eachspecification in a chain in the given order matches the query.

Definition 9. Let R be a service repository. With [s1, s2, ..., sn]T we describea sequence of specifications in SL

R such that (sn T (... T (s2 T s1))) holds.We write c :: sn+1 for the new sequence [s1, s2, ..., sn, sn+1]T . The functionCompose([s1, s2, ..., sn]T ) sequentially composes all specifications in the sequenceinto the specification (sn T (... T (s2 T s1))), whereby Compose([s]) = s.

Definition 10 (Querying Results). Let R be a service repository. The resultof submitting a query q to R is a set of sequences of composable specifications inSLR. For each sequence c in the result set, it must hold that Compose(c) q.

Theorems 1 and 2 assure us that if for any of the returned sequences weassemble a new service by combining services in the contained specifications, thataggregate service will satisfy our query. Service consumers then use metadatacontained in the matching specifications to get links to and invoke the actualservice implementations hosted by service providers. The exact sequence ofinteractions with a service repository and actual services hosted by serviceproviders after matching is beyond the scope of this paper.

5.4 Matching Algorithm

Upon receiving a query q , the repository R will first select service specificationsthat directly match the query. Thereafter we will try to find all sequences of

Algorithm 1 Matching Algorithm

Base := [s] | s ∈ SLR

Result := ∅while (predefined threshold not reached) do

Result := Result ∪c | (c ∈ Base) ∧ (Compose(c) T q)Base := c :: s | (c ∈ Base) ∧ (s ∈ SL

R) ∧ (s T Compose(c))end whilereturn Result

specifications such that their composition matches the query. The details arepresented in Algorithm 1.

A predefined threshold should be checked during each iteration of the loop. Forexample, we can restrict that the maximum length of a composition sequence beno longer than three. Other constraints based on different criteria can be utilizedas the repository configurators see fit. In [15] we show that the Compose(c) T qstep is decidable. The efficiency of the matching algorithm is not a concern here.Complexity and potential optimizations will be addressed in the future.

6 Related Work

The idea of semantically describing services to allow automated service discoveryis not brand new. Most existing approaches such as OWL-S, WSDL-s, [6], [10],Friesen and Borger [7] and [12] use a domain ontology to describe the semanticsof functions. In these ontologies, services are tagged with keywords that describetheir semantic meaning. Afterwards, these keywords are connected with oneanother to allow interpretation of relations between services. While ontologiesallow adding semantic information to services, they neither provide a formaltreatment nor allow service composition.

A basis for formal service description is provided by Liskov and Wing [11]. Intheir work they present a method for describing software components. Using anaxiomatic approach, they employ predicates to formulate pre- and post-conditionsthat specify the behavior of methods and explain how their definition can beused for subtyping relations. Zaremski and Wing [14] extend on that definitionand discuss different alterations.

A different approach is provided by Broy et al. [5]. In their work, services areunderstood as functions on input and output streams in order to facilitate timedependent calculations. This, however, requires the semantic specification usingmathematical functions. Since we aim at allowing consumers to query for services,this would require these consumers to specify the desired functionality in thesame way. In a similar manner, Arbab [3] uses time relations in order to describecommunication patterns between services. Just like Broy, he models channelsbetween components and the temporal behavior on these channels. While thistemporal argumentation does have its benefits, it is not required in our scenario,since classical services such as Web Services operate primarily sequentially.

Agarwal et al. [2] present a method of using π-calculus and description logicto describe software components. The authors establish a SQL-like languagethat allows users to semantically describe services and query for them. Syntacticinformation, however, is ignored. While the described method does allow thesemantic annotation of syntactic types, true interface matching that would enabledirect integration into common technologies is not possible..

Another approach is discussed by Lecue and Leger [9]. Unfortunately, allsemantics of a service is solely based on their parameters, rather than taking thebehavior into consideration. As a result, this solution does not allow for effectivesemantic matching, but simply extends the means of syntactic matching.

Helm et al [8] model the semantics of components using contracts that includepre-conditions for methods and a series of state changes that is achieved byinvoking them. While this series of state changes does allow service compositionquite easily, it requires an extensive understanding of the domain and the internalsof a service not only when describing, but also when querying for a service.

7 Conclusion

In this paper we discuss an approach to formal service specification and ser-vice matching. In addition, we provide a mechanism that enables automaticidentification of service composition possibilities.

Our approach allows service providers to expose their services by submittingthem to domain specific repositories that contain corresponding specifications.Service consumers can find these services by formulating search queries. The queryis treated as a service specification that is substituted by suitable composition ofsub-services. Substitution is modeled using behavioral subtyping concepts.

We diverge from the prevailing understanding of service registries that areopen to all providers. Our approach assumes a curated platform controlled bythe repository managers. The tight control over repository types, predicates andspecifications allows us to provide a clean formal definition of a repository andsignificantly simplifies the treatment of service composition.

The solution presented in this paper is by no means complete. While we havestarted an initial exploration of the specification composition topic, sequentialchaining presents but one of many possibilities. We are currently studying othermeans of combining specifications ([13]). Furthermore, several aspects such asmeta-data treatment and implementation details are still work in progress. Anempirical evaluation of our platform will commence shortly.

Acknowledgments. This work was partially supported by the German FederalMinistry of Education and Research (BMBF) under the COCKTAIL project(grant FKZ 01BS0823) and by the Natural Sciences and Engineering ResearchCouncil of Canada (grant OGP0170497).

References

1. Programmable web (http://www.programmableweb.com/), May 2011.2. S. Agarwal and R. Studer. Automatic matchmaking of web services. In Proceedings

of the IEEE International Conference on Web Services, pages 45–54, 2006.3. F. Arbab. Abstract behavior types: A foundation model for components and their

composition. In Science of Computer Programming, pages 33–70. Springer Verlag,2003.

4. J. Barwise and J. Etchemendy. Language, Proof and Logic. CSLI Publications,Leland Stanford Junior University, 2002.

5. M. Broy, I. H. Kruger, and M. Meisinger. A formal model of services. ACM on

Software Engineering Methodology, 16(1):5, 2007.6. I. Elgedawy. A conceptual framework for web services semantic discovery. In

On The Move to Meaningful Internet Systems, volume 2889 of Lecture Notes in

Computer Science, pages 1004–1016. Springer Berlin / Heidelberg, 2003.7. A. Friesen and E. Borger. A high-level specification for semantic web service

discovery services. In Workshop Proceedings of the Sixth International Conference

on Web Engineering, page 16, New York, NY, USA, 2006. ACM.8. R. Helm, I. M. Holland, and D. Gangopadhyay. Contracts: Specifying behavioral

compositions in object-oriented systems. SIGPLAN Notices, 25(10):169–180, 1990.9. F. Lecue and A. Leger. A formal model for web service composition. In Proceeding

of the 2006 Conference on Leading the Web in Concurrent Engineering, pages37–46, Amsterdam, The Netherlands, The Netherlands, 2006. IOS Press.

10. L. Li and I. Horrocks. A software framework for matchmaking based on semanticweb technology. In Proceedings of the 12th International Conference on the World

Wide Web, pages 331–339. ACM Press, 2003.11. B. H. Liskov and J. M. Wing. A behavioral notion of subtyping. ACM Transactions

on Programming Languages and Systems, 16:1811–1841, 1994.12. T. Pilioura and A. Tsalgatidou. Unified publication and discovery of semantic web

services. ACM Transactions on the Web, 3(3):1–44, 2009.13. M. Tilsner, A. Fiech, G. Zhan, and T. Specht. Patterns for service composition.

In Proceedings of Fourth International C* Conference on Computer Science and

Software Engineering, 2011.14. A. M. Zaremski and J. Wing. Specification matching of software components. ACM

Transactions on Software Engineering and Methodology, 6(4):333–369, October1997.

15. G. Zhan. Domain specific service repository design. Master’s thesis, MemorialUniversity of Newfoundland, 2011.