BPEL for Semantic Web Services (BPEL4SWS)
Jo¨rg Nitzsche, Tammo van Lessen, Dimka Karastoyanova, and Frank Leymann
Institute of Architecture of Application Systems
University of Stuttgart
Universitaetsstrasse 38, 70569 Stuttgart, Germany
{joerg.nitzsche,tammo.van.lessen,dimka.karastoyanova,
frank.leymann}@iaas.uni-stuttgart.de
http://www.iaas.uni-stuttgart.de
Abstract. In this paper we present BPEL for Semantic Web Services
(BPEL4SWS) - a language that facilitates the orchestration of Seman-
tic Web Services using a process based approach. It is based on the idea
of WSDL-less BPEL and enables describing activity implementations se-
mantically which increases the flexibility of business processes. Following
an approach that uses a set of composable standards and specifications,
BPEL4SWS is independent of any Semantic Web Service framework. It
can be used to compose Semantic Web Services, traditional Web Services
and a mix of them.
1 Introduction
Web Service (WS) [1] technology is one implementation of a service oriented ar-
chitecture (SOA) [2,3]. It aims at integrating applications and has gained broad
acceptance in research and industry. Service composition is currently enabled
mainly by a process-based approach [4] embodied by the de facto standard BPEL
(Business Process Execution Language) [5]. BPEL is using WSDL [6] descrip-
tions to identify partner services, i.e. services are identified by port types and
operations in the process models. As a result only services that implement a
concrete interface can be used which is a major deficiency of BPEL.
One approach to addressing the rigidity of WSs has evolved from the Semantic
Web - the Semantic Web Service (SWS) technology. The most prominent SWS
frameworks are the Web Ontology Language for Services (OWL-S) [7] and the
Web Service Modeling Ontology (WSMO) [8]. SWS technology introduces an
additional level of abstraction and can be considered as an integration layer on
top of Web Services. Instead of a syntactic description of a WS a declarative
description of the service functionality is given.
In this paper we present BPEL4SWS, a language which enables describing
activity implementations in a machine processable manner using Semantic Web
technologies, as an alternative to specifying WS interfaces, i.e. it enables the use
of Semantic Web Services as well as traditional Web Services. The BPEL4SWS
framework exhibits and maintains the composability characteristics of the WS
technology. In this way, BPEL4SWS processes are able to use both semantic
R. Meersman, Z. Tari, P. Herrero et al. (Eds.): OTM 2007 Ws, Part I, LNCS 4805, pp. 179–188, 2007.
© Springer-Verlag Berlin Heidelberg 2007

180 J. Nitzsche et al.
WSs and conventional WSs intermixed within a single process, and independent
of any SWS framework. Additionally, BPEL4SWS processes can be exposed
both as Semantic Web Services and conventional Web Services. To enable this,
BPEL4SWS provides a grounding mechanism that contributes to maintaining
BPEL4SWS processes compliant to standard WS-based communication.
The paper is organized as follows. In section 2 the necessary background
information about BPEL is provided. BPEL4SWS is presented in section 3.
We focus on the main aspects of BPEL4SWS and explain how they make up
the functionality the language provides. These aspects are: (i) a WSDL-less
interaction model (BPELlight) for describing the process logic, (ii) the annotation
of SWS descriptions (such as WSMO and OWL-S) to support semantic discovery,
(iii) the usage of WS-* technology for the invocation of services and (iv) the
usage of SA-WSDL [9] to provide a seamless mapping between XML data and
ontological data. In section 4, an engine-prototype that implements BPEL4SWS
is presented. Finally related work is examined in section 5 and a conclusion is
given in section 6.
2 BPEL
BPEL is the de facto standard for specifying business processes in a WS world. It
enables both, the composition of WSs [1] and rendering the composition itself as
WSs. Thus, BPEL provides a recursive aggregation model for WSs. The compo-
sition of WSs can be specified as a flow between WS operations. Therefore BPEL
provides several so called structured activities that prescribe the control flow be-
tween the interaction activities that model interactions with other WSs. BPEL
does not support explicit data flow; instead, data is stored in shared variables
that are referenced and accessed by interaction activities and data manipulation
activities (e.g. <assign> activity). The control flow between activities can be
structured either in a block-based manner by nesting structured activities like
<sequence> (for sequential control flow), <flow> (for parallel control flow)
and <if> (for conditional branches in the control flow) activities, or graph-
based by defining <links> (i.e. directed edges) between activities in a <flow>
activity; both styles can be used intermixed.
In order to enable communication that is compliant to the Basic profile [10]
of the WS-Interoperability Organization (WS-I)1, i.e. without using WSDL op-
erations of type notification and solicit-response, BPEL introduces the concept
of a partner link type which is defined as an extension to WSDL. A partner link
type binds two port types, namely a port type the process offers to a partner
and a port type the process requires from the corresponding partner. This way it
defines a channel between two abstract business partners (roles) through which
the partners exchange messages; the roles correspond to port types. If a process
interacts synchronously with a partner, such a channel is just unidirectional, i.e.
the corresponding partner link type contains a single role.
1 http://www.ws-i.org/