Content uploaded by Ingo Weber
Author content
All content in this area was uploaded by Ingo Weber on Jul 03, 2017
Content may be subject to copyright.
Automated Derivation of Executable Business Processes from
Choreographies in Virtual Organizations∗
Ingo Weber, Jochen Haller Jutta A. M¨ulle
SAP Research IPD, Universit¨at Karlsruhe (TH)
Karlsruhe, Germany Karlsruhe, Germany
{ingo.weber|jochen.haller}@sap.com muelle@ipd.uka.de
Abstract
In this article, we address the challenge of deriving both, executable WSBPEL processes and their respective
WSDL interface specifications from choreographies written in WS-CDL for business processes in Virtual Organiza-
tions (VOs). The major issues hereby are the differences in the vocabulary of WS-CDL and WSBPEL as well as
the information gap between a choreography and an executable orchestration. The information gap results from
the requirement imposed by the VO environment to establish a process-based collaboration in a top-down fashion.
High-level choreography descriptions are hereby the basis for the derivation of detailed executable processes. The
first issue is addressed with a detailed translation table; the second one requires the use of a role specific knowledge
base. This knowledge base delivers process subsets modeling detailed role internal activities while avoiding their
exposure to collaborating roles. The combined solution is a CDL2BPEL algorithm.
1 INTRODUCTION
In today’s business world, there is a strong need for information technology integration across organizational bound-
aries. Following the trend of Service Oriented Architectures (SOAs), enterprises will continue exposing well-defined
communication interfaces to their respective business partners, in order to enable the information exchange and thus
the co-operation of applications on geographically distributed information systems. Emerging standards mainly from
OASIS1and W3C2, especially in the Web service area, allow for a cross-domain business collaboration based on open
standards. However, there is a need for coherency in the interactions between the collaborating systems and a com-
mon understanding of the several partner roles’ business responsibilities: For application interoperation, a non-legally
binding contractual agreement has to be followed, guaranteeing a common understanding of which information has to
be communicated and when. This contractual agreement can take the form of a choreography, specifying the interac-
tions and local activities between all roles involved in a collaborative business process at a higher level. I.e., only the
interaction points and their respective order are defined in the choreography and not the details of the local activities.
A sample motivating scenario from the Collaborative Engineering application domain is shown in Figure 1. The
graph, modelled as an UML activity diagram3, shows an excerpt of a choreography that involves the roles of Analysis
(AP) and Storage Partner (SP). Assume the Analysis Partner receives the request to perform an analysis on engineering
data stored within the Storage Partner’s domain. The raw data is referenced uniquely, and AP has the reference
information. Now, AP requests data from SP, who retrieves it from the local storage facility and sends it to AP.AP
then locally performs the actual analysis work. The results are transmitted back to SP, who in turn stores them in
the local database. This example will be further developed throughout the remainder of the article.
At the choreography level, the partners specify the global view of their co-operation instances. That is, each
time when a business opportunity arises, a new instance of a collaborative business process in the context of a newly
bootstrapped VO is created and executed by each collaborating role involved in the choreography template. However,
a choreography can be seen as the combination of a set of public interfaces and is not executable as process: it only
contains the public knowledge for all roles required to participate in a collaboration, but not the private knowledge
specifying the detailed activities performed by each single role within its own domain. E.g., in Figure 1 the interactions
between the two roles are stated, but the knowledge on how for instance the activity ’Analyze Data’ is to be done
∗A previous version of this article has been published as [Weber et al., 2006]
1http://www.oasis-open.org/
2http://www.w3.org
3Unified Modeling Language, see http://www.uml.org/
1
Figure 1: The Analysis-Storage choreography part
is of no relevance to the choreography and thus not modelled at this level. Therefore, an executable representation
of the business process of each role or partner needs to be created. In any of the cases, the local business process
representations have to contain the local knowledge that is not present in the choreography.
Business application logic is hereby assumed to be encapsulated in a service implementation. Therefore, the local
knowledge includes in particular the knowledge which business services to call, which of course is partner-specific. The
local, executable business process captures the local, role specific view on the joint business processes, which orders the
calls on available services and guarantees a defined execution order. In contrast, the choreography view concentrates
on the interactions between the involved roles.
This research work was conducted in the context of Virtual Organizations (VOs) within the European Union
funded IST project TrustCoM, which imposes specific requirements with respect to collaborative business processes:
A VO is formed in response to a business opportunity that can not be addressed by just one partner alone. In
reaction to the emerging business need, swift partner consortium formation, and quick, automatic adaptation of IT
infrastructures are of essence. Thus, an automated solution deriving executable business processes from a choreography
was desired, following a top-down approach which is aligned with the VO formation and partner selection processes
[Robinson et al., 2005].
Given a choreography, the presented approach generates executable processes for each role along with pub-
lic views on them. The underlying process model follows the view based process model as introduced in
[Schulz and Orlowska, 2002], where private, executable processes maintain their confidentiality by only exposing views
in terms of public processes to collaborating roles. The required local knowledge for role specific processes is intro-
duced via a Knowledge Base (KB). Although the approach focuses on the specific needs of virtual organizations, it
is applicable in most other scenarios as well. The VO environment imposes in many respects more challenges on the
solution, since all aspects of executable processes, including the local knowledge of the partners, have to be specified
and included already at derivation time.
The remainder of this article is structured as follows: The problem statement, i.e., choreography support for VOs
along with basic definitions form Section 2. Section 3 describes our solution comprising the local knowledge bases,
the translation table show in the Appendix, and the CDL2BPEL algorithm. Related work is presented in Section 4.
Section 5 outlines future work and concludes.
2 CHOREOGRAPHY SUPPORT FOR VOS
Since Virtual Organizations serve as the motivating problem domain for collaborative business processes in this article,
they are defined and introduced below.
Definition 1: AVirtual Organization is a combination of various parties (persons and/or organisations or indi-
viduals) located over a wide geographical area which are committed to achieve a collective goal by pooling their core
competencies and resources. The partners in a Virtual Organisation enjoy equal status and are dependent upon elec-
2
tronic connections (ICT infrastructure) for the co-ordination of their activities. (From [Bultje and van Wijk, 1998]).
The life cycle of a VO is typically divided into four phases (from [Strader et al., 1998]):
•During the VO Identification Phase, the opportunity is identified, evaluated, and selected.
•The VO Formation Phase comprises partner identification, evaluation, and selection.
•In the VO Operation & Evolution Phase, services and resources of the single VO partners are integrated,
and VO-wide collaborative processes aim at the achievement of shared business objectives. Membership and the
structure of VOs may evolve over time in response to changes of objectives or to adapt to new opportunities in
the business environment.
•The VO Dissolution Phase is initiated when the market opportunity is fulfilled or has ceased to exist. Here,
the distribution of results and products takes place, along with billing and the like.
Initially, in the Identification and Formation phases the VO is assembled. This involves that a VO initiator, e.g.
an aerospace industry system integrator, selects suitable partners to fill the roles required for enacting a joint business
process during the operational phase. Such roles may range from simple data storage providers to experts specialised in
certain subsystems, for instance wing, fuel tank or antenna design and manufacturing. The partners are not required to
have an existing business relationship of any kind. Departing from the highest level, fitting real partner organisations to
roles during identification phase, the subsequent VO formation becomes more detailed when ICT, security, trust, and
various other infrastructures and systems of the partners have to be connected [Robinson et al., 2005]. Consequently,
the top-down approach also holds for the establishment of collaborative business processes. Departing from a high-
level choreography description designed or chosen by the VO initiator, the requirement is to derive executable business
processes for each participating role. Since VOs are dynamic environments that are intended to act and form fast
upon emerging business opportunities, an automatic derivation methodology is highly desired.
Definition 2: Achoreography describes collaborations of parties by defining from a global viewpoint their com-
mon and complementary observable behaviour, where information exchanges occur, when the jointly agreed ordering
rules are satisfied. [...] The choreography offers a means by which the rules of participation within a collaboration
can be clearly defined and agreed to, jointly. Each entity may then implement its portion of the choreography as
determined by the common or global view. (from [W3C, 2005]).
In TrustCoM, the view based collaborative business process model is used, as presented in
[Schulz and Orlowska, 2002, Schulz and Orlowska, 2001], which, in turn, is based on the specifications of the
WfMC4. There, the needs for confidentiality of entire processes or workflows of the respective partners and the
integration of multiple private workflows into a global view are identified as critical for successful operation of virtual
enterprises, extended enterprises and VOs. On the one hand, an organization may not be willing to share detailed
information about a complete business process, since the information in it represents an asset to its owner. On the
other hand, enough information has to be provided to the coalition (or the VO in our context) in order to get a coher-
ent and stable public workflow. The approach is refined in [Schulz and Orlowska, 2002, Schulz and Orlowska, 2001]
through the introduction of a coalition model with three tiers: private processes, public views of these processes, and
a (global) public process. These three tiers correspond to the notions of private business processes, the behavioural
interfaces of these processes, and choreographies, respectively, used in this work.
Applying the collaborative business process model to the VO environment, the collaborating members are informed
about the VO objective through the shared choreography. They can thus infer the behaviour that is expected from
them during the VO operation phase which corresponds to their public process. A partner is only required to expose
the public process to the VO which serves as the interface for the confidential private process.
With respect to the Service Oriented Architecture (SOA) paradigm, implemented modular pieces of application
logic are assumed to be available as services. Therefore, the private business process can be seen as a stateful wrapper
around the services, guaranteeing the defined order of calls to the services. Thus, it is also called orchestration,
providing a local, role specific view on a private/public process pair, in contrast to the choreography which captures
the global view on a collaboration among different roles.
2.1 The Information Gap
The information gap is our term for the different levels of detail within the described collaborative business process
model. Choreographies model the interplay between the multiple parties in a collaborative business process and are
not concerned about the details of each individual role’s activities. Orchestrations, however, need to contain all details
required for the execution of a single partner’s business process. Thus, the sum of the orchestrations contains more
knowledge than the respective choreography.
4Workflow Management Coalition, among others see [WfMC, 1999] and [WfMC, 2002]
3
In detail, the information gap entails the following points of information differences between the choreography and
the orchestrations:
1. The internal or private actions for each role, which are of no interest to the choreography.
2. Branching conditions in the orchestration, which are not observable on the collaborative level.
3. Extensions, e.g. annotating security requirements and transactional behaviour.
4. Details in error and compensation handling, which are not treated at the choreography level.
5. Runtime details, such as initial and glueing activities, which monitor e.g. service endpoint behaviour.
While the points 1 and 2 are addressed by the work presented in the following section, 3 is subject to future work.
Point 4 should in our opinion be addressed by best practices for choreography design, and 5 tackles runtime behaviour
which is considered out of scope for the presented work but dealt with in [Weber, 2005].
2.2 Language Differences
From the extensive set of available languages5, we made the following three choices addressing the requirements and
constraints as presented above in this section:
•The Web Service Choreography Description Language (WS-CDL) [W3C, 2005] is used to specify chore-
ographies. Although it is still in the process of standardization and severe structural critique was expressed
[Barros et al., 2005], it represents the most promising and expressive approach currently available.
•For executable (private) processes, the Web Service Business Process Execution Language (WSBPEL)
[Andrews et al., 2003] is employed. All generated private processes are executable BPEL processes. This lan-
guage was chosen, because it is mature, widely known and used, and draws strong attention from industry.
•The public views are expressed in the Web Service Description Language (WSDL). Other possibilities such
as abstract BPEL processes were considered and would have been more flexible than static WSDL descriptions.
This choice was taken, since WSDL is a rather mature and stable standard, at the same time supporting the
choice of executable BPEL. Abstract BPEL is specified, but its intended usage and coherent runtime mapping
to executable BPEL is still under discussion in the OASIS Technical Group standardizing WSBPEL.
In order to qualify elements and functions in the remainder of this article, the following prefixes are employed: cdl
refers to language items from WS-CDL, bpel refers to WSBPEL, and wsdl to WSDL language elements.
Although the WS-CDL specification intends to be compliant with executable process languages as WSBPEL, the
language elements differ in many respects. Where BPEL offers a set of atomic activities which can be combined ele-
gantly to the desired behaviour, WS-CDL knows certain elements which are far from being atomic: The cdl:interaction
activity combines actual interactions with transactionality, timeouts, and assignments. cdl:WorkUnits are the sum of
loops, conditional execution, variable value evaluation, and potential partial ordering of parallel activities. These and
other differences make the actual derivation of executable BPEL processes hard, since the complex semantics of very
expressive WS-CDL activities are not matched in the goal language. In certain cases, workarounds are possible. But
in a subset of these cases, the workarounds cannot guarantee that the behaviour of the generated processes is fully
equivalent to the intended behaviour from the choreography. The resulting semantic differences are outlined in the
evaluation section.
In this section, the introduced terms were defined and the problems addressed by this article were stated. Namely,
there is the issue of the information gap as a result of the different points of view taken by choreographies and
orchestrations, and the problem of language differences resulting from the chosen set of languages. The next section
is concerned with the solutions to these problems.
3 TECHNICAL SOLUTION
In order to achieve an automated derivation of executable processes, the elements of a WS-CDL document are trans-
lated in a depth-first search through the XML tree. For each role in the choreography, a process is derived. Each
element in the source document is added only to the processes of the roles for which it is relevant. If a part of the
5As for XML-based standard languages (or languages in the process of becoming standardized), there are multiple alternatives for each
category, such as WSCI, WSCL, BPSS, and WfXML for choreographies and BPML, XPDL, XLANG, WSFL, and BPDM for executable
private processes.
4
choreography cannot be translated, i.e. it falls into one of the categories of the information gap, it is sent as a request
to a Knowledge Base (KB). In the KB, the private, local, or confidential details of a private process are placed. If
there are elements of a choreography which still cannot be translated, a list of these elements (and potentially other
errors) is returned.
Figure 2 shows a graphical representation of the outcomes of the BPEL derivation from the choreography in
Figure 1. The executable process for the AnalysisPartner role is shown on the left side, the process for the Storage-
Provider role on the right side. Light gray lines between the processes show the cross-organizational communication.
Clearly, the orchestrations are far more detailed, and the local substitutes for the high-level, private activities from
the choreography are in place (the local service calls, which are provided by the organization responsible for their
execution).
Synchronous
Store Result Data (locally)
Receive Data Address
Initial Receive
StoragePartner
Initial Assignment
Synchronous
Get Raw Data (locally)
Receive Raw Data
Reply ACK
Initial Receive
AnalysisPartner
Initial Assignment
Synchronous
Init StoragePartner
Receive ACK
Scope
Request Raw Data from SP
Receive Raw Data
Synchronous
Analyze Data (locally)
Receive Results
Assign After Receive
Assign Before Send
Send Result Data to SP
Receive Result Data Address
Assign After Receive
Assign Before Send
Scope
Send Raw Data to AP
Receive Result Data
Assign After Receive
Assign Before Send
Send Result Data Address
Assign Before Send
Receive Raw Data Request
Assign After Receive
Figure 2: The generated BPEL processes.
Also, the executable processes are concerned with initialization of the processes, which always means incoming
messages in BPEL6, as well as gluing activities. The latter ones are runtime requirements, such as variable and
message initialization and apparent assignment statements.
The derivation of BPEL and WSDL from WS-CDL is achieved in a 5-step algorithm, which is outlined in Section 3.2.
In short, the algorithm is an extended compiler, in that it reads a source document and generates an object tree for
it, performs validation and transformation on the tree, and serializes the resulting object trees to a set of documents
in the target languages. We call it ’extended’, because it includes a dynamic part - the Knowledge Base - in addition
to the static program code.
3.1 The Knowledge Base
The unobservable or private parts of a choreography, summarized as the information gap, are activities that are only
mentioned in the choreography. That is, for these parts the choreography states only what needs to be done, but
6Note, that here only the AnalysisProvider’s process needs to be invoked from outside. It then calls the SP’s process synchronously in
order to assure that instances of all processes are available before the actual work is started.
5
not how. A translation aiming at BPEL stubs for further manual specification would copy the comment from the
choreography. But the goal here is full automation; therefore, a way to insert the actual activities into the private
processes was required. This part is played by the Knowledge Base (KB).
The KB is a service as well, containing CDL patterns and their respective private counterparts. The latter
encompass BPEL activities as well as optional WSDL elements and even deployment artefacts for all roles of interest.
When queried with a CDL pattern, the KB tries to find the matching private counterparts. In our VO setting, the
CDL2BPEL service acts as the service requestor. If a matching pattern is found, the respective BPEL and WSDL
parts and the deployment information are retrieved and returned as the query results. Since the patterns can be
generic in that they contain placeholders for variable or partner names, the KB then replaces these placeholders with
the instances from the query, given a consistent mapping can be found. Subsequently, the results are returned to the
CDL2BPEL algorithm, which weaves them into the goal documents. The KB service hereby supports the CDL2BPEL
service in overcoming most importantly points one to three of the information gap, as described in Section 2.1.
The introduced pattern matching feature can be implemented by one of several mechanisms with varying level
of sophistication. The mechanism which is currently used is simple equality checking of CDLs XML elements and
attributes in conjunction with assignment of values to variables. A far more advanced approach is Semantic Web
service discovery based on OWL-S or the WSMO framework, which is discussed in the future work section. XSLT
2.0-based template matching with multiple result documents could be used as well, but it does not fit the usage here
directly. Thus, the overhead over simple pattern matching would be substantial while there are few additional gains.
Using the Knowledge Base encourages the reuse of both choreographies and patterns and introduces a dynamic
element into the derivation. That means that one choreography can be used for many VOs, and the pattern for a
specific business service often requires only little adaptation to make it applicable to a certain choreography. Also,
standardised choreographies can be bound into other choreographies to solve different purposes, thus offering a way
- comparable to design patterns - to rely on often used choreographies for standard parts of a choreography. This
technique is enabled by the KB, because the private activity substitutions change with the respective usage and
partners of the current choreography. Additionally, pre-specified sub-processes7could be bound into BPEL via the
KB.
When the Knowledge Base is deployed and accessed solely locally in each member’s domain of a VO, it helps
satisfying the confidentiality requirement that comes with optimized process parts and internal implementation. The
KB also enables a late binding-like way to connect local services to a process. In a way, the Knowledge Base can be
seen as the material filling up the information gap.
3.2 The CDL2BPEL Algorithm
The CDL2BPEL algorithm describes how the CDL document is traversed and how the translation is applied to the
elements by performing the KB from the preceding section and the translation rules in the Appendix. Figure 3 shows
the various steps of the algorithm graphically. In detail, the five steps are:
3
<process>
…
</process>
BPEL
5
4
WSDL
<definitions>
…
</definitions>
5
<package>
<choreography>
…
</choreography>
</package>
WS-CDL
1
2
ErrorLog
Failure
Notification
5
33
CDL-KB
3
3
Figure 3: The five steps of the CDL2BPEL algorithm
7See [Kloppmann et al., 2005] for a suggestion on how sub-processes may be specified in BPEL.
6
1. Read the choreography, create and initialize memory objects according to the WS-CDL elements.
2. Validate the choreography (Correct variable and channel usage, the correct number of child elements with
appropriate attributes and conditions such as guards).
3. Translate from CDL to BPEL and WSDL
•Traverse the XML tree from the root choreography, adding each activity to the BPEL process of involved
roles (Structuring activities, such as sequence or parallel, are added to the processes of all roles).
•If the current element cannot be translated directly, try a KB lookup with the non-translatable part as
input.
•For activities or sets of activities which still can not be transformed, make an error note (Report all errors
back after traversing the whole tree, see step 5).
•Extract WSDL files from interactions and tokens / token locators (Generate operations, port types, message
schemas, bpel:partner link types, bpel:properties).
4. Revise, optimize, and validate the generated BPEL processes from the holistic perspective.
•Add necessary gluing activities where obvious, e.g. assignments.
•Remove superfluous structuring activities (e.g. a sequence with one child) which are leftovers from step 3).
•Optimization to a chosen level, such as replacing sequences containing one activity by their child.
•Static checks ensure schema validity of the processes and that the set of BPEL processes can be executed
together based on their message exchange protocol.
5. Generate the BPEL and WSDL code from the objects OR return failure note
The results of this algorithm are a set of documents, namely for each cdl:roleType a private, executable BPEL
process and the public view on it as a WSDL definition. Note, that WS-CDL knows an element called participant,
which groups together multiple role types that, during execution, must be played by a single entity. Therefore, another
approach could be to generate one process per participant. However, we decided on the above solution, because one
organization representing a participant with multiple roles could work with multiple BPEL engines internally for
organisational reasons. E.g. in a buyer-seller-shipper choreography where the seller and shipper roles have to be
played by one entity, the company who plays these roles could have distinct departments with each maintaining an
own BPEL engine. Thus, this decision can be seen as enabling more flexibility, but shifting the enforcement of the
participant-role constraints to another spot.
We did not use XSLT8for the transformations, the straight-forward choice for transformations between XML
documents in different formats, due to its limitations e.g. with respect to validation. In contrast, our transformation
mechanism, the CDL2BPEL algorithm, can be seen as an extended compiler as argued before.
The translation is shown in the translation table in the appendix. For most of the WS-CDL elements, a match in
BPEL was found, some of which are discussed in the following.
The translation of certain CDL elements is fairly obvious, e.g. a cdl:sequence is translated to a bpel:sequence. In
others, such as the cdl:interaction, the translation is much more extensive. Due to its various additional attributes,
the number of BPEL elements required for an execution semantics-preserving translation of the cdl:interaction can
become comparatively high. E.g. alignment and record sets together imply that the data transmission and the related
variable manipulations are basically subject to atomic transactionality: Either all those activities succeed or none of
them has an effect. Thus, our translation approach includes backup variables with the original variable values, and
acknowledgement exchange. In the case of a fault this allows for a rollback, i.e. all changes are undone.
Besides the cases where a direct translation is possible, the cdl:silentAction and cdl:choice with a non-observable
branching condition are cases for which, by design of WS-CDL, no match can be found in BPEL. These elements only
specify what needs to be done at this point of the process, but not how. Their implementation is partner-specific, e.g.
calls to business applications, and is inserted into the executable processes via the KB.
The bpel:switch realises data-driven choices, i.e. the question which branch of a process needs to be taken from a
certain point on can be answered right away once this point is reached. In contrast, the bpel:pick is good for deferred
choices, that is, at such a branching point the process will wait for one of several events to happen. In CDL, the data-
driven choice is expressed as a non-blocking cdl:workUnit, and the event-based version as a blocking cdl:workUnit,
in both cases inside a cdl:choice. These branching constructs are distinct in BPEL, whereas in WS-CDL they can
be combined. If they are not combined, the translation of cdl:choices is mostly feasible. But a cdl:choice with both,
8Extensible Stylesheet Language Transformations, see XSLT 1.0 [W3C, 1999] and XLST 2.0 (http://www.w3.org/TR/xslt20/ , work in
progress)
7
blocking and non-blocking cdl:workUnits as children can only be translated to a workaround - a set of activities in
BPEL which can differ in their exact execution semantics from the intended behaviour in the choreography. This
is only the case if certain complex interdependent sets of guard conditions fall together with events taking place at
particular points in time. The details of the workaround and the issues can be found in [Weber, 2005]. It is the
most challenging case of language differences between WS-CDL and BPEL, and for that we did not find a perfectly
satisfying solution.
Also, cdl:workUnits outside of cdl:choices can be hard to translate. One case not shown in the translation table
is a blocking, non-repeating work unit with the guard condition set to cdl:isVariableAvailable, which we translate to
a number of links in a bpel:flow: Every BPEL activity in the process which may occur before the (translated) child
activity of the work unit and writes to the variable from the cdl:guard condition becomes the source of a link to the
mentioned child activity. The join expression over the input links is the boolean “or” connector.
For further reading, all in-depth details of the translation, including an extended translation table for elements
and an additional one for functions in WS-CDL, can be found in [Weber, 2005].
3.3 Prototypical Implementation and Evaluation
For both, the CDL2BPEL algorithm and the KB, a proof-of-concept prototype has been implemented as Java Web
Services based on Axis (1.2RC3) ([Apache Software Foundation, 2005]). The Knowledge Base builds on a relational
database. A detailed description of the implementation and further third party software in use can be found in
[Weber, 2005]. The business processes in Figure 2 demonstrate graphically the result of applying the implementation
to the CDL document belonging to the choreography from Figure 1.
The CDL2BPEL service implements the algorithm and the translation table in order to derive executable processes
and their interfaces from choreographies. When needed, it queries the Knowledge Base. The prototype proves the
validity of this approach for the addressed problem by applying the implementation to a set of Collaborative Engi-
neering choreographies within a TrustCoM VO. The outputs are processes which are indeed executable. This is shown
in conjunction with another service, which packages the BPEL, WSDL, and other related documents for deployment
in an execution environment. In the case at hand, the open source ActiveBPEL (http://www.activebpel.org) engine
was chosen after careful testing due to its stable implementation and sensible architecture.
However, for certain cases of the cdl:choice element, no semantically equivalent construct was found. That is, a
possible workaround could differ in its behaviour as follows:
•Timing issues can switch the order of condition evaluation, since there are no event-based BPEL constructs
matching the cdl:isVariableAvailable and cdl:variablesAligned functions.
•Communication delays in Web Service invocations can cause a duration-based timeout to happen later than
intended or, for the same reason, an event can even be missed completely.
A solution to these issues requires basically changes or extensions in BPEL, such as user-defined events in the
bpel:switch and bpel:pick constructs.
Other issues may arise with the use of the cdl:align attribute in cdl:interactions which expresses required trans-
actional behaviour. While BPEL alone can cope with simple transactions, we believe that in complex collaborations
involving for instance long running or dynamic transactions among multiple roles would require the use of other WS
standards such as WS-Transaction in conjunction with WS-Coordination. Another exception is the channel concept
in WS-CDL which has no direct counterpart in BPEL.
Furthermore, tokens can be declared in WS-CDL which relate to correlation sets in BPEL. In contrast to CDL,
an activity which initialises a correlation set has to be defined explicitly. While, in general, this is a mismatch in the
languages, it does not disturb the translation in the VO setting, since the CDL2BPEL implementations can handle it
in a consistent way [Weber, 2005].
The KB strongly depends on its contents, which must first be inserted and then maintained over time. If the
patterns do not fit the remainder of the process, runtime behaviour is undefined and will most likely result in a fault.
Thus, test-runs of the generated processes are highly encouraged.
As already mentioned above, the implementation was tested with TrustCoM choreographies, stemming from col-
laborative engineering examples. The choreographies we used departed from simple examples with two roles and
eleven activities up to more complex examples with five roles and 40 activities, not counting interactions. In principle,
the approach of the CDL2BPEL algorithm is valid beyond the TrustCoM related samples. The translation table is
independent of any application scenario as is the Knowledge Base concept. To apply a particular implementation
instance in an application scenario, the only application specific dependency relates to the Knowledge Base content.
An occurring cdl:silentAction, such as “Analyze data” in the example, will be resolved by a Knowledge Base query
and therefore, its content has to deliver the fitting process part. “Analyze data” may be relevant for an aerospace
8
choreography as wells as an automotive one, but the implementing private process parts will differ depending on the
context in terms of the industry and the executing organization.
The validity of the approach, in particular the translation table, manifests itself in the executability of the output
BPEL processes. The question, if a process will be executable in reality and under all circumstances, can never be
answered positively due to the nature of the environment: if a linked service becomes unavailable, future process
instances will fail. In other words: it will always be possible to trick the system, yielding BPEL processes that are
not executable. However, both BPEL9and CDL rely on the modularity of the nesting principle for activities from
πcalculus, where e.g. a sequence is an activity that contains other activities. Our approach translates each single
concept in a execution semantics-preserving way, and thus we can infer (without formal proof) that in theory the
outcomes of the translation process are executable, given the input choreography allowed for it.
The evaluation has shown, that in most practically relevant cases the approach yields executable processes.
4 RELATED WORK
The main issue of this article is to derive executable public and private business processes specified in WSBPEL and
WSDL from WS-CDL modelled business choreographies in an interorganisational environment.
There are several publications on issues related to interorganisational workflows ([Alonso et al., 2004,
Cabrera et al., 2004, van der Aalst, 2000, van der Aalst and Weske, 2001]). The overlapping and differing aspects of
orchestrations and choreographies were already identified in [Peltz, 2003], but focusing on WSCI [W3C, 2002] and not
on WS-CDL. Our approach adopts the view based process model with public, private, and executable views, which
was introduced in [Schulz and Orlowska, 2002].
The transformation of choreographies to WSBPEL may be arranged as part of a comprehensive design methodology.
Several approaches exist that propose such architectures for business process modelling. As one of these, [Havey, 2005]
provides an exemplary BPM architecture, which is built on three standards: WS-CDL, the Business Process Modeling
Notation (BPMN), and BPEL. This theoretical architecture envisions automated mappings from WS-CDL to BPMN
(and compliance checks in the opposite direction), as well as from BPMN to BPEL. The approach is motivated
as a suitable BPM solution for single companies, whose processes must comply to agreed-upon choreographies for
the interaction with business partners. However, it is a purely theoretical suggestion without any tangible results
on the transformations. The design methodologies in [Martens, 2004, van der Aalst et al., 2005] present different
concepts to check choreography conformance of private processes and to proof the correctness of BPEL processes.
Both methodologies use Petri Nets in order to represent semantics of the interfaces and processes. Semantics is not
yet addressed in our approach but may be used in a elaborated version of the Knowledge Base to choose applicable
executable processes, and to check the result of the derivation process in a more sophisticated way.
The ebXML BPSS10 offers a public view on business processes during design time, which shows some similarities
to the choreographies used in our approach. In contrast to WS-CDL, the ebXML business processes can only specify
binary relations, posing restrictions to the expressive power for ordering constraints of multi-party choreographies.
Furthermore, ebXML does not explicitly address executable business processes, e.g., modelled in BPEL. Businesses
mutually agree to follow a BPSS in a CPA11. Instead of striving for automation in setting up a collaboration, ebXML
rather expects people to agree upon a CPA, taking existing executable processes into account, i.e. their general
approach is bottom-up and not top-down as in our case.
In [Mendling et al., 2004], 15 different XML-based specifications for business process modeling are compared. The
authors state that WSBPEL is one of the most complete languages in terms of available features, which supports our
choice of WSBPEL as target language.
Transformation of business process languages exist on various levels and for several purposes. [Ouyang et al., 2005]
investigates a transformation from the more powerful process modeling language BPMN [OMG, 2006] to WSBPEL.
However, BPMN has a totally different scope than WS-CDL: it is rather focused on single party processes. The
transformation from block-oriented languages (such as WSBPEL) and graph-oriented languages (such as EPCs) is the
topic in [Mendling et al., 2006], which shows some basic insights into the language elements of languages of both types
and respective transformations.
A conceptual model for the mapping from WSBPEL to WS-CDL is presented in [Mendling and Hafner, 2005].
Additionally, a proof-of-concept implementation of the mapping was realized with the Extensible Stylesheet Language
Transformations (XSLT), enabling the generation of BPEL stubs from WS-CDL documents. Although the objectives
seem similar to our approach at a first glance, there are notable differences: our goal is to derive executable BPEL
9This is not the case for all constructs in BPEL. Particularly, bpel:flows are not related to πcalculus. But since BPEL is the target
and not the source language, this is not a problem here.
10ebXML: Electronic Business using eXtensible Markup Language (http://www.ebxml.org/), BPSS: Business Process Specification
Schema. See [Irani, 2001], [Marchal, 2003], and [Nickull et al., 2001]
11Collaboration Protocol Agreement, part of ebXML
9
processes that can be deployed without human interaction and are executable in the sense that they usually complete
successfully when called. We also provide a complete translation table, in contrast to [Mendling and Hafner, 2005].
Besides, the prototypical implementation of our mapping is implemented as an extended compiler, offering dynamic
translation opportunities and sophisticated consistency and correctness validation – qualities that XSLT cannot provide
without extensions.
In order to overcome the information gap, a knowledge base has been introduced. This approach may be enhanced
with semantic descriptions of the private and executable processes, see also the next section. Semantic Web Services
and composition support of services as in [K¨uster et al., 2005] offer a formal method to specify services as part of
processes or, as in [Ortiz et al., 2005], processes themselves in a semantic way. [Wombacher et al., 2005] proposes an
approach to support B2B e-commerce in a more flexible way by representing the semantics of business (sub-)processes
with conjunctive finite state automata yielding to support searching and matching adequate processes.
5 CONCLUSION AND FUTURE WORK
This article describes the task of deriving executable public and private processes from a high-level choreography,
and presents a solution in form of the CDL2BPEL algorithm. The main challenges initially pointed out, namely the
language differences and the information gap, which arises when departing from high-level choreography descriptions,
could be solved with a translation table and the introduction of the Knowledge Base, respectively. The latter fills
the gaps between the global and the local collaboration perspective with partner-internal local knowledge. Together,
the Knowledge Base, the translation table and the Web service-oriented implementation of the CDL2BPEL algorithm
achieve the goal of an automated derivation approach within highly dynamic VO environments.
Future work will build incrementally upon the presented derivation approach. Currently, the communication of
faults and coordination with respect to the outcome of the choreography are achieved by explicit message trans-
mission in the BPEL processes. A preferred solution would externalise this communication, e.g. by employing
WS-Coordination. This is subject to ongoing work in our group.
TrustCoM aims at provisioning of secure collaborative business processes. The confidentiality of private processes
can be supported through their deployment environment. Further security requirements demand that process execution
at runtime needs to be reactive to security subsystem decisions taken outside the process execution environment, but
within the same administrative domain. A security control concept for collaborative business processes is already
available and was published by one of the authors [Haller et al., 2005]. It will be implemented based on the presented
work.
A different improvement of the described approach could also include set up the knowledge base on Semantic Web
service technology, such as OWL-S or WSMO. The tasks to be fulfilled locally at the partners could be described by
WSMO goals or OWL-S service profiles, and their replacement – currently implemented as pattern matching – would
then essentially become Semantic Web service discovery, which builds on Semantic Web reasoning. This approach
would make the choreographies and patterns very generic, in that the derivation of executable processes would in many
cases not require fitting the KB’s content to the choreography at hand. The opportunity of a learning Knowledge
Base could also be explored, especially in conjunction with semantic pattern descriptions.
References
[Alonso et al., 2004] Alonso, G., Casati, F., and et al. (2004). Web Services - Concepts, Architectures and Applications.
Springer.
[Andrews et al., 2003] Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F., Liu, K., Roller,
D., Smith, D., Thatte, S., Trickovic, I., and Weerawarana, S. (2003). Business Process Execution Language for Web
Services. 2nd public draft release, Version 1.1.
[Apache Software Foundation, 2005] Apache Software Foundation (2005). Web services - axis.
http://ws.apache.org/axis/.
[Barros et al., 2005] Barros, A., Dumas, M., and Oaks, P. (2005). A Critical Overview of the Web Services Choreog-
raphy Description Languages (WS-CDL). BPTrends Newsletter, Vol. 3.
[Bultje and van Wijk, 1998] Bultje, R. and van Wijk, J. (1998). Taxonomy of Virtual Organisations, based on defini-
tions, characteristics and typology. VoNet: The Netwsletter @ http://www.virtual-organization.net/.
[Cabrera et al., 2004] Cabrera, L., Copeland, G., Johnson, J., and Langworthy, D. (2004). Coordinating Web Services
Activities with WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity.
10
[Haller et al., 2005] Haller, J., Robinson, P., and Karabulut, Y. (2005). Security Controls in Collaborative Business
Processes. In 6th IFIP Working Conference on VIRTUAL ENTERPRISES (PRO-VE’05).
[Havey, 2005] Havey, M. (2005). Essential Business Process Modeling. Copyright 2005 O’Reilly Media, Inc.
[Irani, 2001] Irani, R. (2001). Collaborative Electronic Business is here to stay: An Introduction to ebXML.
http://www.webservicesarchitect.com/content/articles /irani02.asp.
[Kloppmann et al., 2005] Kloppmann, M., Koenig, D., Leymann, F., Pfau, G., Rickayzen, A., von Riegen, C., Schmidt,
P., and Trickovic, I. (2005). WS-BPEL Extension for Sub-Processes: BPEL-SPE. White Paper.
[K¨uster et al., 2005] K¨uster, U., Stern, M., and K¨onig-Ries, B. (2005). A Classification of Issues and Approaches in
Automatic Service Composition. In In: Ch. Zripins, G. Ortiz, W. Lamersdorf, W. Emmerich (eds.): Proc. of the
First International Workshop on Engineering Service Compositions (WESC’05), IBM Research Report RC23821
(W0512-008) December 2005, pages 25–33.
[Marchal, 2003] Marchal, B. (2003). An Introduction to the ebXML CPP.
http://www.developer.com/xml/article.php/2247851.
[Martens, 2004] Martens, A. (2004). Analysis and re-engineering of web services. In Proc. of the 6th International
Conference on Enterprise Information Systems (ICEIS), 2004, pages 419–426.
[Mendling and Hafner, 2005] Mendling, J. and Hafner, M. (2005). From Inter-Organizational Workflows to Process
Execution: Generating BPEL from WS-CDL. In Proceedings of OTM 2005 Workshops. Lecture Notes in Computer
Science 3762, pages 506–515. Springer Verlag.
[Mendling et al., 2006] Mendling, J., Lassen, K. B., and Zdun, U. (2006). Transformation Strategies between Block-
Oriented and Graph-Oriented Process Modelling Languages. In In: F. Lehner, H. N¨osekabel, P. Kleinschmidt (eds.):
Multikonferenz Wirtschaftsinformatik 2006 (MKWI 2006), Band 2, XML4BPM Track, GITO-Verlag Berlin, pages
297–312.
[Mendling et al., 2004] Mendling, J., N¨uttgens, M., and Neumann, G. (2004). A Comparison of XML Interchange
Formats for Business Process Modelling.
[Nickull et al., 2001] Nickull, D., Dubray, J.-J., Evans, C., van der Eijk, P., Chopra, V., Chappell, D. A., Harvey, B.,
Noordzij, M., Vegtand, J., McGrath, T., and Peat, B. (2001). Professional ebXML Foundations. Wrox Press.
[OMG, 2006] OMG (2006). Business Process Modeling Notation – BPMN 1.0. http://www.bpmn.org/. Final Adopted
Specification, February 6, 2006.
[Ortiz et al., 2005] Ortiz, G., Hernandez, J., and Clemente, P. J. (2005). Reusable Web Service Choreography and
Orchestration Patterns. In In: Ch. Zripins, G. Ortiz, W. Lamersdorf, W. Emmerich (eds.): Proc. of the First
International Workshop on Engineering Service Compositions (WESC’05), IBM Research Report RC23821 (W0512-
008) December 2005, pages 43–50.
[Ouyang et al., 2005] Ouyang, C., Dumas, M., Breutel, S., and ter Hofstede, A. (2005). Translating Standard Process
Models to BPEL. Bpm center report bpm-05-27, BPMcenter.org.
[Peltz, 2003] Peltz, C. (2003). Web Services Orchestration and Choreography. Computer, 36(10):46–52.
[Robinson et al., 2005] Robinson, P., Karabulut, Y., and Haller, J. (2005). Dynamic Virtual Organization Management
for Service Oriented Enterprise Applications. In to appear: The First International Conference on Collaborative
Computing: Networking, Applications and Worksharing (CollaborateCom 2005).
[Schulz and Orlowska, 2001] Schulz, K. A. and Orlowska, M. E. (2001). Architectural Issues for Cross-Organisational
B2B Interactions.
[Schulz and Orlowska, 2002] Schulz, K. A. and Orlowska, M. E. (2002). Towards a Cross-Organizational Workflow
Model. In PRO-VE ’02: Proceedings of the IFIP TC5/WG5.5 Third Working Conference on Infrastructures for
Virtual Enterprises, page 652. Kluwer, B.V.
[Strader et al., 1998] Strader, T. J., Lin, F.-R., and Shaw, M. J. (1998). Information Infrastructure for Electronic
Virtual Organization Management. Decis. Support Syst., 23(1):75–94.
11
[van der Aalst et al., 2005] van der Aalst, W., Dumas, M., Ouyang, C., Rozinat, A., and Verbeek, H. (2005). Chore-
ography Conformance checking: An Approach based on BPEL and Petri Nets. Bpm center report bpm-05-25,
BPMcenter.org.
[van der Aalst and Weske, 2001] van der Aalst, W. and Weske, M. (2001). The P2P Approach to Interorganizational
Workflows, pages 140–156. Springer.
[van der Aalst, 2000] van der Aalst, W. M. P. (2000). Loosely Coupled Interorganizational Workflows: Modeling and
Analyzing Workflows Crossing Organizational Boundaries. Information and Management, 37:67–75.
[W3C, 1999] W3C (1999). XSL Transformations (XSLT) Version 1.0. W3C Recommendation 16 November 1999.
[W3C, 2002] W3C (2002). Web Service Choreography Interface (WSCI) 1.0. W3C Note 8 August 2002.
[W3C, 2005] W3C (2005). Web Services Choreography Description Language, Version 1.0. W3C Recommended Draft
9 November 2005.
[Weber, 2005] Weber, I. (2005). Automation in Collaborative Business Process Instantiation. Master thesis at the
department of informatics, Universit¨at Karlsruhe (TH), Germany.
[Weber et al., 2006] Weber, I., Haller, J., and M¨ulle, J. A. (2006). Automated Derivation of Executable Business
Processes from Choreograpies in Virtual Organizations. In In: F. Lehner, H. N¨osekabel, P. Kleinschmidt (eds.):
Multikonferenz Wirtschaftsinformatik 2006 (MKWI 2006), Band 2, XML4BPM Track, GITO-Verlag Berlin, pages
313–327.
[WfMC, 1999] WfMC (1999). Interface 1: Process Definition Interchange Process Model. Document number wfmc-
tc-1016-p version 1.1 final, Workflow Management Coalition.
[WfMC, 2002] WfMC (2002). Workflow Process Definition Interface - XML Process Definition Language. v1.0 Final
Draft. Document number wfmc-tc-1025, Workflow Management Coalition.
[Wombacher et al., 2005] Wombacher, A., Fankhauser, P., Mahleko, B., and Neuhold, E. (2005). Matchmaking for
business processes based on conjunctive finite state automata. Int. J. Business Process Integration and Management,
1(1):3–11.
APPENDIX A: TRANSLATION TABLE
The following table contains the rules for the derivation of BPEL processes. Although all WS-CDL elements and
supplied functions are contained, not all details of the actual implementation are listed here, due to space limitations.
The conceptual translation for the WS-CDL supplied functions has been developed as well, but is omitted here for
the same reason.
12
WS-CDL Attributes &
Children
BPEL Remarks
Package Process with initial interac-
tions
The root choreography becomes a scope
Choreogra-
phy
possibly with Error
Handlers / Finaliz-
ers
Scopes with Fault / Compen-
sation Handlers
Note that uncaught faults will terminate the bpel:process’ execution.
Information
Type
xsd:complexType in the WSDL
Token Correlation Set and references at usage p oints
Token Lo-
cator
Property in the WSDL
Role Type One process per role type Also a role in Partner Link Types
Relationship
Type
Partner Link & Type Partner Link Types are specified in the WSDL
Participant
Type
— Not translated, see Section 3.2
Channel
Type
— Not used here.
Variable Variable Additional message variables for variables used in interactions.
Interaction Invoke and Receive per
cdl:exchange
If the cdl:action is ’request’, a bpel:invoke at the cdl:fromRole and a
bpel:receive at the cdl:toRole, for a ’respond’ switch the roles.
timeout or align scope around the invoke / re-
ceive
Also acknowledgement exchange, fault and compensation handlers
realizing timeout and rollback
record assign The cdl:when specifies the location of the bpel:assign
Sequence Sequence
Parallel Flow
Work Units (WUs)
with certain guards
Links in the Flow If the WUs form a partial order of two activities1
Choice Switch or Pick or complex combination
only non-blocking
WUs
Switch The cdl:workUnits translate to bpel:switchCases
only non-blocking
WUs with enclosed
interaction2
Sender: Switch, receiver:
Pick
The receiver learns which branch is chosen through incoming mes-
sages3(onMessage event). The sender can observe the conditions
directly.
only blocking WUs Pick bpel:pick implements an event-based choice
blocking and non-
blocking WUs
See Section 3.2 for such hybrid cases
children of any
other type than
WU
CDL-KB lookup The branching conditions are non-observable here.
Work Units guard6=’ ’,
repeat=false,
block=false
Switch with Switch Case en-
closing the WU children and
an Otherwise containing an
Empty
Only valid in non-effecting contexts of the Work Unit (not inside a
choice, an exception block or similar). The bpel:switchCase’s condi-
tion is the (converted) cdl:guard condition for the respective role(s).
repeat 6= false While Set the condition with respect to the semantics4
guard=’ ’,
repeat=false
— Such WUs have no effect.
Silent Ac-
tion
CDL-KB look-up
No Action Empty
Assign Assign
causeException
=true
Throw after the Assign
Perform bind Two Assigns: at the start and
the end
At the beginning from the enclosing to the enclosed scope, at the end
in the opposite direction.
Exception
Block
Fault Handlers cdl:exceptions must be propagated to all parties of the Choreography,
therefore the bpel:catch triggers the communication for the current
scope explicitly5.
Exception
Work Unit
Catch
Finalizer
Block
Compensation Handler at the process with enableInstanceCompensation=true
Finalizer
Work Units
Switch or Pick in the process’ Compensation Handler
Finalize Compensate
Coordina-
tion
Communication in the Com-
pensation Handler
Given its availability, WS-Coordination could solve this issue as well.
1E.g. cdl:isVariableAvailable with block=true
2Any set of structuring activities with an interaction as starting point of the activities at the receiving role.
3Each case must use a different message type.
4Note, that the bpel:while is a do ... until cond where cond is the content of the bpel:condition attribute, whereas the cdl:workUnit is a if
cond1 do ... while (cond1 && cond2) with cond1 being the cdl:guard condition and cond2 being the cdl:repeat condition. Thus, the boolean
statement of the cdl:guard has to be inverted.
5WS-Transaction and/or WS-Coordination can help here, given they are available in the runtime environment. Otherwise, the communication
is specified in a compensation handler, which is called from the various fault handlers.
1
13
