Deﬁning and Prototyping a Life-cycle for Dynamic

Service Composition

Eduardo Silva, Jorge Mart´ınez L´opez, Lu´ıs Ferreira Pires and Marten van Sinderen

Centre for Telematics and Information Technology, University of Twente

P.O. Box 217, 7500 AE Enschede, The Netherlands

Abstract. Since the Internet has become a commodity in both wired and wire-

less environments, new applications and paradigms have emerged to explore this

highly distributed and widespread system. One such paradigm is service-orienta-

tion, which enables the provision of software functionality as services, allowing

in this way the construction of distributed systems with loosely coupled parts.

The Service-Oriented Architecture (SOA) provides a set of principles to create

service-oriented systems, by deﬁning how services can be created, composed,

published, discovered and invoked. In accordance with these principles, in this

paper we address the challenge of performing dynamic service composition. The

composition process and its associated tasks have to be precisely deﬁned so that

the different problems of dynamic service composition can be identiﬁed and tack-

led. To achieve this, this paper deﬁnes a life-cycle for dynamic service composi-

tion, which deﬁnes the required phases and stakeholders. Furthermore, we present

our prototype in which the different phases of the dynamic service composition

life-cycle are being implemented. This prototype is being used to experiment with

and validate our initial ideas on dynamic service composition.

1 Introduction

During the last years we have observed an increased use of the Internet, on both wired

and wireless environments. Nowadays cellular phones are often sold with a data com-

munication contract, which allows phone users to access numerous applications. Re-

cent studies [1] show that in the upcoming years the continuously increasing use of

small portable communication devices, referred as Internet-centric pocketable devices,

will overcome the use of laptops, especially for users with high mobility. This tendency

brings the Internet always and everywhere, triggering new opportunities and application

areas. As a consequence, many of the biggest software industry companies are invest-

ing in new developments in Internet-based application service provisioning. Software

as a Service (SaaS) [2] is a concrete example that is being adopted by some major

software companies. This Internet-based methodology for software delivery provides

the means to deliver services on-demand, as the user requires them, moving away from

some classical approaches to software distribution, such as license-based. These new

developments are based on the Service-Oriented Architecture (SOA) [3], which pro-

vides a set of principles to address the creation, share and use of services. A service is

Silva E., MartÍnez López J., Ferreira Pires L. and van Sinderen M. (2008).

Deﬁning and Prototyping a Life-cycle for Dynamic Service Composition.

In Proceedings of the 2nd International Workshop on Architectures, Concepts and Technologies for Service Oriented Computing, pages 79-90

DOI: 10.5220/0001899900790090

 SciTePress

realized by a given application, or system, and represents the external behaviour of the

application, or system. This is the basic deﬁnition of service, which is going to be used

throughout this paper.

With the emergence of Internet-based application services and open principles for

service creation and use, such as SOA, new opportunities and approaches for service

creation are appearing. One of these approaches is service composition, which focus

on the creation of value-added services from existing services. Service composition

should in principle reduce the development time of new services, while promoting the

re-use of available application services. Furthermore, by using service composition it

should be possible to create personalised services on-demand, based on speciﬁc user re-

quirements. The creation of service compositions on-demand based on particular user

requirements, context and preferences, characterizes dynamic service composition. Dy-

namic service composition will possibly support service developers at design-time, eas-

ing their task on service creation, and end-user, at runtime. Many people are working on

different aspects of service composition in general, and much effort is being spent on

some issues concerning dynamic service composition in particular. However, not much

effort is being spent on the precise deﬁnition of the dynamic service composition life-

cycle. A more precise deﬁnition of the dynamic service composition life-cycle should

allow one to identify and reason about the concerns and requirements of this problem.

In this paper we focus on the deﬁnition of such a life-cycle, and identify the research

challenges that need to be addressed in each phase of this life-cycle. This paper also

presents the prototype we are building to support dynamic service composition, which

implements the life-cycle phases we have identiﬁed. This prototype should allow us to

identify new problems that need to be tackled in this area.

The paper is organized as follows: Section 2 motivates dynamic service composi-

tion by discussing a target application scenario; Section 3 presents a service composi-

tion life-cycle, aiming at identifying and addressing the different phases of the dynamic

service composition process; Section 4 presents the prototype we are developing to im-

plement the phases of the dynamic service composition life-cycle; Section 5 discusses

some related work; and Section 6 presents our conclusions and topics for future work.

2 Motivation

Service composition is mainly motivated by the principles provided by the Service-

Oriented Architecture (SOA) [3]. The Organization for the Advancement of Structured

Information Standards (OASIS) deﬁnes SOA as [4]:

A paradigm for organizing and utilizing distributed capabilities that may be

under the control of different ownership domains. It provides uniform means

to offer, discover, interact with and use capabilities to produce desired effects

consistent with measurable preconditions and expectations.

According to the SOA principles, service developers can create new services, and make

them available to potential service users. To make a service available, a service descrip-

tion document has to be produced, which describes the service properties, operations

and how the service can be invoked. Fig. 1 shows the basic interactions in a service-

oriented architecture and the different parties involved in the architecture. SOA is not

an implementation technology, but rather a set of concepts that can be implemented

using different concrete technologies. Currently, the most popular technology to imple-

ment SOA is Web services [5,6]. Many aspects of Web services have been standardized,

making this technology mature and highly accepted by the industry.

Service Registry

Service

Provider/Developer

Service

User

Service

Description

Service

Description

i) publish service

description

ii) request service

iii) retrieve service

descriptions

iv) invoke service

Fig.1. Service-Oriented Architecture elements and interactions.

SOA fosters the re-use of available services as components in service compositions.

Traditionally, service composition is performed during design-time, resulting in service

compositions that have to be used during runtime as they have been designed. How-

ever, new application scenarios have been identiﬁed that could beneﬁt from dynamic

service composition. We deﬁne dynamic service composition as the process of creating

a service on demand (at design or at runtime) to match speciﬁc user requirements and

preferences by composing existing services.

Amongst the scenarios in which dynamic service composition can be beneﬁcially

applied is mobile computing, which is presented in [6]. This scenario involves two main

system parts, namely the user’s mobile device and the back-end application server. Ser-

vices in this scenario are called Field Web services. The user has a ﬁeld mobile device,

which is used to input the user’s service request, store the user’s proﬁle and service

preferences. The user’s mobile device is also used as a sensor for the user’s context.

Provided with such a ﬁeld mobile device, the user can create a service request and for-

ward this request to the back-end server system. The back-end server system performs

all the necessary operations to provide the user with a service that matches the require-

ments expressed in the service request. This architecture allows advanced functionality

and added-value services to be provided to the user on small pocketable devices. An-

other potential beneﬁt is the increase of the battery life-time of the mobile devices, since

some power-consuming processing is shifted to the back-end server system. Saving bat-

tery life-time is a key issue in mobile computing nowadays.

3 Dynamic Service Composition Life-cycle

The life-cycle of dynamic service composition deﬁnes the required phases and the

stakeholders that participate in the service composition process. Fig. 2 presents the

life-cycle for the dynamic service composition process considered in our work.

Service creation

End-user

Service

developer/provider

Service registry

Service request

Service discovery

and composition

Service publication

Service composition

selection

Service Delivery

Service developer

Service Deployment

Fig.2. Dynamic service composition life-cycle.

We assume that three stakeholders participate in the life-cycle: Service developers, Ser-

vice providers, and End-users. The life-cycle depicted in Fig. 2 consists of two main

ﬂows, namely creation and publication of (atomic) services, to be performed by service

developers and service providers, and (dynamic) service composition, to be performed

by end-users on demand, at runtime, or by service developers, at design-time. Each one

of these ﬂows is discussed below in terms of the phases and the issues to be solved in

each phase.

3.1 Services Creation and Publication

Although the service provider and the service developer are two different stakehold-

ers with well-deﬁned roles, in this discussion we do not discern them. We assume that

the service provider/developer is usually a professional user or company, which fo-

cus on creating and providing services for a potential set of users. Application Service

Providers (ASPs) [7] are organizations that play the combined roles of these stakehold-

ers. A service provider/developer creates services, which may be built from scratch by

programming new applications and making them available as services. A service may

also be built by hand by re-using existing services in a composition, making the com-

position available as a service. The service creation phase consists on the construction

of the service functionality and the respective service description document.

The service description document is used in the service publication phase to pub-

lish the necessary information to allow potential service users to discover the service.

Furthermore, the service description document also has to contain all the required in-

formation to deal with the invocation of the service, such as the address of the service

end-pointsand speciﬁc technical details (protocols,encoding, etc.). The service descrip-

tion document may also contain other non-functional information, such as quality-of-

service, Service Level Agreements (SLAs), and possibly contractual conditions to use

the service.

Service creation and publication are essential phases in the dynamic service com-

position life-cycle, since service composition can only take place if services that are

candidates to be used in compositions are available and can be discovered for usage.

3.2 Service Composition

We assume here that an end-user or a service developer wants a new service to satisfy

his speciﬁc needs. Fig. 2 shows an end-user, which usually has no technical skills on

service compositionand wishes a new service at runtime, and a service developer,which

has technical skills on service composition, but wants to create a new service in a faster

and more automated way given some speciﬁc requirements, usually at design-time.

The ﬁrst phase of this process is the speciﬁcation of a service request. The service

request should provide enough informationon the user requirements and preferences for

the service. In the case of an end-user, additional context information can also be gath-

ered to further adapt the service creation to the concrete user situation. In this phase,

the end-user or the service developer interacts with the system that performs the dy-

namic service composition, but most of the other phases are expected to be performed

transparently for these stakeholders. This is because we assume that dynamic service

composition should be an automated process in which a service is created without re-

quiring the direct intervention of a human user, as opposed to the service creation phase

discussed in Section 3.1.

After the service request is deﬁned, the service discovery and composition phase

starts. The different services that could be used in a composition are discovered accord-

ing to the composition algorithm. Service discovery is performed by invoking the inter-

face provided by the service registry, based on information contained in the published

service description documents. The service discovery phase depends on the publica-

tion phase discussed in Section 3.1. This implies that the information published in the

publication phase should be compatible with the information required in the discovery

and composition phase, which can be achieved by complying to open standards even if

different organizations implement their own publication and discovery mechanisms. In

the service discovery and composition phase, an algorithm is often performed that takes

the user service request to build candidate compositions of the services that have been

discovered previously or whenever the algorithm needs them.

As a result of the discovery and composition phase, several compositions may be

generated that match the service request, which means that the generated services may

have to be selected. This happens in the service composition selection phase. In the

case of an end-user, a single service (composition) should be returned, which implies

that this phase is performed by the system that supports the composition process. This is

because we have assumed that an end-user does not have the technical skills necessary

to select the most appropriate composition. However, the end-user may be asked to indi-

cate which properties should have the highest priority in the selection of a composition

(e.g., the aggregate cost of using the services in the composition, or the performance of

the composition in terms of response delay). In any case, this phase should be as trans-

parent as possible for the end-user, i.e., the resulting composition should be selected

only based on the service request and the user’s preferences and context. In the case of

a service developer, a list of services that match the service request may be returned.

Mechanisms to rank the generated service compositions may be used to facilitate the

selection of the composition that is ﬁnally used.

Service delivery is the phase that follows service composition selection, and it is

concerned with the activities that are necessary to allow the end-user to use the ser-

vice composition. This phase is necessary because the resulting composition may still

be represented in some (formal) technology-independent notation, while an executable

representation is necessary to deploy and execute the composition as a concrete ser-

vice. In the case of a service developer, a service composition description may also be

required to allow the composition to be published as a new service, so these issues are

also relevant to this phase.

Service deployment is a phase that applies only to the end-user case. The end-user

expects a running service, so the selected composition has to be deployed to allow its

instantiation and invocation by the end-user.

At the end of the life-cycle some actions may still occur, depending on the stake-

holder. In the case of an end-user, the service composition is invoked to deliver the

service requested by the end-user. In the case of a service developer, the list of services

is returned so that the most suitable composition the developer needs can be selected.

The service developer may possibly adapt the composition further, to include some

additional functionality. Fig. 2 shows an additional phase for the case of service devel-

opers, in which the service developer publishes the composed service so that it can be

used later by end-users or other developers.

4 Prototype for Dynamic Composition of Services

This section discusses the prototype we are building to implement the different phases

of the dynamic service composition life-cycle. We are mainly aiming at developing a

modular, scalable and extensible architecture, to address each of the life-cycle phases,

but also at supporting different concrete technologies, such as, for example, different

service description languages.

In our prototype we are currently using Spatel [8], which is a language developed

in the European project IST SPICE [9] in which this work is embedded. Spatel sup-

ports service description, creation, composition and execution. It also supports seman-

tic description of services, through references to ontologies. Ontologies are formal rep-

resentations of conceptualizations, and are necessary in our approach to automate the

different tasks of the service composition life-cycle, providing the abstraction and trans-

parency needed in the dynamic service composition process.

Fig. 3 shows our initial prototype for dynamic service composition by indicating

how each phase of our proposed life-cycle for dynamic service composition is mapped

onto the components of the prototype.

Service creation

End-user

Service

developer/provider

Service registry

Service request

Service discovery

Service publication

Graph-based

service composition

Sevice composition

selection

Service developer

Domain Ontologies

Imp: XML + Java

Imp: jUDDI

Imp: OWL

Imp: SPATEL-tools

Imp: Java + jUDDI API

CLM Construction

Imp: Java + FACT++

Service composition

Imp: Java

Imp: Java + SPATEL + EMF

Service delivery

Service deployment

Fig.3. Prototype for dynamic service composition.

4.1 Service Creation

The service creation process makes use of the Spatel tools, which offera graphical inter-

face to deﬁne the interface of services and the service end-points. This component also

allows one to semantically annotate service operations with inputs, outputs, precondi-

tions and effects, to deﬁne the service goal, which reﬂects the purpose of a service, and

to deﬁne non-functional properties of a service, such as, for example, cost and response

time. All these annotations refer to concepts formally deﬁned in ontologies, which in

our case have been produced in the scope of the SPICE project.

Other languages than Spatel may be used in the service creation phase as long as

these languages support semantic annotations.

4.2 Service Publication

The component responsible for service publication analyses the service description doc-

ument, extracting the necessary information to publish the service in the service reg-

istry. The operation of extracting the information from a service description document

depends on the used description language, which means that different interpreters have

to be available to parse the supported description languages. Since we use Spatel for

service description, in order to parse a Spatel service description document we generate

a Java API from the Spatel Ecore model with the Eclipse Modeling Framework (EMF).

This allows us to extract the semantically annotated properties from the Spatel service

description document, namely Inputs, Outputs, Preconditions, Effects, Goals and Non-

functional properties. These semantically annotated properties are always considered

for semantic service description in our prototype, so independently of the description

language a service is always published in the service registry in this same way.

The extracted information is organized and published in an UDDI-based registry.

We use jUDDI [10] as service registry, which is a Java-based implementation of the

Universal Description, Discovery, and Integration (UDDI) speciﬁcation [11] for Web

Services. Our purpose is to make use of the jUDDI API for publication and discov-

ery of services, creating the necessary UDDI models to store the semantic annotations

mentioned above.

4.3 Service Request

The service request component allows the speciﬁcation of a service request, using a set

of semantic annotations that describe the properties of the desired service. The prop-

erties considered are the same as those used for service publication: Inputs, Outputs,

Preconditions, Effects, Goals, and Non-functional properties. All these annotations re-

fer to ontologies that are valid in the application domain being considered, in our case

telecom services. This process is implemented using a simple interface that allows the

construction of a (XML-based) service request document with the following structure:

<Non-functional>..</Non-functional>

</ServiceRequest>

4.4 Service Discovery

In our approach the component responsible for service discovery is goal-based. The

list of candidate services for the service composition is established before the actual

composition is performed. The service request is analysed, and the goal annotations are

extracted. Given these annotations, the service registry is queried through the jUDDI

API Inquiry function for services with goals that are semantically related to the goal of

the service request. This is possible because both the services and the service request

are described using the same properties, and ontologies. When the service registry is

queried, not only semantically exact matches are retrieved, but other partial semantic

matches are also possible, such as Plugin, Subsume and Intersection [12].

4.5 Service Composition

Once the list of services with matching service goals is discovered, they are ﬁrst anal-

ysed and organized in a formalism called Causal Link Matrix (CLM) [12], and after that

they are composed using a graph-based algorithm [13].

CLM allows one to model all possible semantic connections, or causal links, be-

tween the discovered services. We use CLM

, which is an extension of CLM, in order

to capture the services’ non-functional properties as well. Non-functionalproperties are

used later in the composition, and in the selection phase.

To construct the CLM

matrix we use FACT++ [14], which is a reasoner for De-

scription Logics (DL). This reasoner is used to infer DL relations such as Consistency

and Subsumption. Based on these relations the CLM

matrix can be constructed, and

once the CLM

matrix is available the actual service composition process takes place.

In our prototype,the service composition process is implemented in Java, using a graph-

based composition algorithm. The algorithm dynamics consists of ﬁnding a combina-

tion of services, previously organized in the CLM

matrix, which makes it possible to

match the service request. The process starts by analysing the CLM

matrix for ser-

vices that provide the requested outputs. Once this is done, the algorithm proceeds with

a backwards composition strategy, resolving the inputs of the services of the graph.

The composition process consists of a matching the inputs of the services in the graph

with the outputs of services from the CLM

matrix. If multiple services match a given

service input, an alternative composition graph is created, representing an alternative

service composition. During each step in the algorithm, the aggregated non-functional

properties in the composition graph are checked, to verify whether they match the re-

quested non-functional properties. If a composition graph does not match the requested

non-functional properties, it is not further considered and is discarded from the set of

valid service compositions. The algorithm ﬁnishes (i.e., the composition is complete)

when all requested inputs and goals are resolved.

4.6 Service Composition Selection

In the service composition process, several alternative service compositions that match

the service request may be generated. This is possible since alternative services can pro-

vide the same (or similar) functionality. It is therefore necessary to rank the generated

composition graphs according to some criteria. The ranking of the generated compo-

sition graphs can be made based on the graphs’ aggregated non-functional properties

(e.g., total cost), and the semantic connections of the services in the composition graph.

For the end-user case the best service composition is selected, and for the service de-

veloper case all generated service compositions are stored in the ranked order.

4.7 Service Delivery

In our case, the service delivery phase consists of translating the service composition

from our graph formalism to Spatel. We do this by using the EMF and the Spatel Ecore

models. We have not yet addressed this issue in detail, but the objective is to create a

Spatel description of the generated composition service, so that the service developer

can further adapt it to his needs, and the end-user can invoke and execute the composi-

tion.

The service deployment phase will be considered in our future work.

5 Related Work

Service composition has received a lot of attention from industrial players and academia.

Different aspects of service composition are being addressed, including the (partial)

automation of service composition methodologies. However, the integration of the dif-

ferent parts of the life-cycle for dynamic service composition has not been addressed

that often. This is in our opinion a very important step to create and evaluate suitable

solutions to the dynamic service composition.

In [15] the problem of interleaving web service discovery and composition is ad-

dressed, by considering only simple workﬂows where web services have one input and

one output parameter. In this case the web service composition plan is restricted to a

sequence of limited web services corresponding to a linear workﬂow of web services.

In our framework we propose a formalism to support the composition of services with

multiple inputs and outputs, and also address the other phases of the life-cycle of the

service composition process.

In [16] an algorithm for automatic composition of services is presented. The service

composition is considered as a directed graph, where nodes are linked by the seman-

tic matching compatibility (Exact, Subsume, P lugIn, Disjoint) between input and

output parameters. Based on this graph, the shortest sequence of web services from

the initial requirements to the goal can be determined. This approach computes the

best composition according to the semantic similarity of output and input parameters

of web services, but it does not consider any non-functional properties of the service

composition. We consider this to be a very pertinent point to take into account, since

the selection of the most suitable service compositions is often based on such properties

(for example, costs and security).

In [17] a semi-automatic composition process is proposed to perform the compo-

sition of web services. This approach supports the system user in the selection of web

services during each step in the composition process, and to create ﬂow speciﬁcations to

link them. The discovery process consists of ﬁnding matching services, which consist of

web services that provide outputs that can be fed as input to the services of the service

composition. After selecting all the services, the system generates a composite process

[18]. The composition is executed by calling each service separately, and passing the

results between services according to the ﬂow speciﬁcations. This process allows more

control over the composition process, which is sometimes desirable for service devel-

opers. However, since the composition process is semi-automatic, end-users without

technical knowledge probably cannot make use of this approach. Our framework deals

with the composition process in a more abstract and automatic way, which allows its

usage by both service developers and end-users.

6 Conclusions and Future Work

In this paper we motivate the dynamic composition of services, focusing on how to

address all the necessary phases of the dynamic service composition life-cycle. We

propose a life-cycle following the SOA principles, further extended with the neces-

sary phases to perform dynamic and automatic composition of services. The life-cycle

focuses on creating new services (i.e., service compositions) based on a service user

service request. The discovery, composition and selection phases are transparent to the

end-user or service developer.

Based on the proposed life-cycle we are developing a prototype implementation.

The prototype is based on the use of ontologies to allow the automation of the ser-

vice discovery, matchmaking and composition processes. We propose a goal-based

discovery and graph-based composition algorithm, using non-functional properties for

service composition optimization and ranking of the generated service compositions.

The whole process of publication/discovery and composition is language-independent,

meaning that different description languages, supporting semantic annotations, can be

published. The generated service compositions can also be delivered in different execu-

tion languages.

The ideas and the prototype presented in this paper are still under development,

and several issues still need to be addressed. Apart from supporting service developers,

at design-time, we also intend to support end-users, providing runtime composition

of services. To achieve this we have to provide an even more abstract way to describe

service requests. The support of end-users also requires the deployment of the generated

service compositions. At the moment, the service discovery process is completely done

before the service composition process, and is goal-based. This approach has beneﬁts,

but also drawbacks. For example, during composition time it may turn out that the

previously discovered services cannot be combined to form a matching composition.

In this case, on-demand service discovery during composition time is necessary. The

proposed prototype is being ﬁnalized and further evaluations will be performed. We

are currently setting up a demo scenario to evaluate the performance of the proposed

prototype.

Acknowledgements

This work is supported by the European IST SPICE project (IST-027617) and the Dutch

Freeband A-MUSE project (BSIK 03025).

References

1. Gartner: Gartner highlights key predictions for itorganisations and users in 2008 and beyond.

http://gartner.com/it/page.jsp?id=593207 (January 2008)

2. O’Reilly, T.: The open source paradigm shift. In: Perspectives on Free and Open Source

Software, The MIT Press (July 2005) 461 – 481

3. Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall

(2005)

4. MacKenzie, C.M., Laskey, K., McCabe, F., Brown, P.F., Metz, R.: Reference model for

service oriented architecture 1.0. Technical report, OASIS (October 2006)

5. Alonso, G., Casati, F., Kuno, H., Machiraju, V.: Web services: concepts, architectures and

applications. Springer-Verlag (2004)

6. Papazoglou, M.P.: Web Services: Principles and Technology. Prentice Hall (2007)

7. Tao, L.: Shifting paradigms with the application service provider model. Computer 34(10)

(2001) 32 – 39

8. Almeida, J.P., Baravaglio, A., Belaunde, M., Falcarin, P., Kovacs, E.: Service creation in

the SPICE service platform. In: Wireless World Research Forum meeting on ”Serving and

Managing users in a heterogeneous environment”. (November 2006)

9. Cordier, C., Carrez, F., van Kranenburg, H., Licciardi, C., van der Meer, J., Spedalieri, A.,

Rouzic, J.P.L.: Addressing the challenges of beyond 3G service delivery: the SPICE plat-

form. In: 6th International Workshop on Applications and Services in Wireless Networks.

(2006)

10. Apache: Apache juddi. http://ws.apache.org/juddi/

11. Clement, L., von Riegen, A.H., Rogers, T.: Universal description discovery and integration

(uddi) version 3.0. http://uddi.org/pubs/uddi

v3.htm (October 2004)

12. L´ecu´e, F., L´eger, A.: A formal model for semantic web service composition. In: ISWC 2006.

LNCS, vol. 4273 (2006) 385–398

13. L´ecu´e, F., da Silva, E.M.G., Ferreira Pires, L.: A framework for dynamic web services com-

position. In: 2nd ECOWS Workshop on Emerging Web Services Technology (WEWST07),

Halle, Germany, Germany, CEUR Workshop Proceedings (November 2007)

14. Tsarkov, D., Horrocks, I.: Fact++. http://owl.man.ac.uk/factplusplus/

15. Lassila, O., Dixit, S.: Interleaving discovery and composition for simple workfows. In: First

International Semantic Web Services Symposium. (2004)

16. Zhang, R., Arpinar, I.B., Aleman-Meza, B.: Automatic composition of semantic web ser-

vices. In: 1st International Conference on Web Services. (2003) 38–41

17. Sirin, E., Hendler, J.A., Parsia, B.: Semi-automatic composition of web services using se-

mantic descriptions. In: 1st Workshop on Web Services: Modeling, Architecture and Infras-

tructure. (2003) 17–24

18. Burstein, M.H., Hobbs, J.R., Lassila, O., Martin, D.L., McDermott, D.V., McIlraith, S.A.,

Narayanan, S., Paolucci, M., Payne, T.R., Sycara, K.P.: Daml-s: Web service description for

the semantic web. In: International Semantic Web Conference. (2002) 348–363