Methods for the specification and

verification of business processes

MPB (6 cfu, 295AA)
Roberto Bruni

http://www.di.unipi.it/~bruni

23 - Business process execution

language
1
marted 13 dicembre 2011

Object

We overview the key features of BPEL

2
marted 13 dicembre 2011

3
marted 13 dicembre 2011

BPEL

4
marted 13 dicembre 2011

Business process
execution language
Also known as
Web Services Business Process Execution Language
(WS-BPEL)
and also as
Business Process Execution Language for Web Services
(BPEL4WS)
is a standard executable language for orchestrating the use
of Web Service within business processes:
import / export information, remote invocation, correlation,
fault handling, compensation
5

marted 13 dicembre 2011

Origins
A long time ago in a galaxy far,
far away....

WEB
SERVICES
6
marted 13 dicembre 2011

Web services
Web services fix a standard for interoperability
between heterogeneous, loosely coupled, remote
software applications
(separately developed, running on different platforms)
over (not only) the HTTP protocol
Informally:
web services are for software
what web sites are for human
7
marted 13 dicembre 2011

WS basics
Services must be made available on the web
(need a server)
Services must be advertised over the web
(need some repositories)
Service repositories must be queried
(need service description)
Services must be invoked
(need standard communication format)
8
marted 13 dicembre 2011

XMLification
WSFL, BPEL, ...

UDDI

Service composition
Service discovery
Service publication

WSDL

Service description

SOAP

XML based messaging

HTTP, HTTPS, SMTP

Network
9

marted 13 dicembre 2011

WS-*

10
marted 13 dicembre 2011

Messaging Specifications
SOAP 1.1

Business Process Execution

Language for Web Services 2.0
(BPEL4WS) 2.0
OASIS, BEA Systems, IBM, Microsoft, SAP,
Siebel Systems Committee Draft

! Business Process Execution Language for Web Services

2.0 (BPEL4WS) provides a language for the formal

specification of business processes and business interaction
protocols using Web Services.

and structure of the (SOAP) messages that are exchanged,

and the sequence and conditions in which the messages
are exchanged.

! Web Service Choreography Interface (WSCI) describes

how Web Service operations can be choreographed in the

context of a message exchange in which the Web Service
participates.

Business Process Management

Language (BPML)

! Web Service Choreography Description Language

! Web Service Distributed Management: Management Using ! Web Service Distributed Management: Management Of

(CDL4WS) is to specify a declarative, XML based language

that defines from a global viewpoint the common and
complementary observable behaviour, where message
exchanges occur, and when the jointly agreed ordering
rules are satisfied.

Web Services (WSDM-MUWS) defines how an IT resource

connected to a network provides manageability interfaces
such that the IT resource can be managed locally and from
remote locations using Web services technologies.

XML Process Definition

Language (XPDL)

1.1
BPMI.org
Final Draft

provides a meta-language for expressing business

processes and supporting entities.

Web Services (WSDM-MOWS) addresses management of

the components that form the network, the Web services
endpoints, using Web services protocols.

protocol for managing systems such as PCs, servers,

devices, Web services and other applications, and other
manageable entities.

WS-Addressing Core

Security

WS-Addressing WSDL Binding

WS-Addressing SOAP Binding

" Web Services for Remote Portlets (WSRP) defines a

WS-Eventing

set of interfaces and related semantics which standardize

interactions with components providing user-facing
markup, including the processing of user interactions with
that markup.

WS-Enumeration

Metadata Specifications
WS-Policy

! Servcie Modeling Language (SML) is used to model

XML file format that can be used to interchange process

models between tools.

complex IT services and systems, including their structure,

constraints, policies, and best practices.

WS-PolicyAssertions
WS-PolicyAttachment

! Basic Profile The Basic Profile 1.2 builds on Basic Profile

WS-Discovery

1.1 by incorporating Basic Profile 1.1 errata, requirements

from Simple SOAP Binding Profile 1.0, and adding support
for WS-Addressing and MTOM.

WS-MetadataExchange
Universal Description, Discovery and Integration
Web Service Description Language 1.1

Basic Security Profile

1.0
WS-I
Board Approval Draft

! WS-MetadataExchange enables a service to provide

! Basic Security Profile defines the WS-I Basic Security

Profile 1.0, based on a set of non-proprietary Web services

specifications, along with clarifications and amendments
to those specifications which promote interoperability.

REL Token Profile

1.0
WS-I
Working Group Draft

! REL Token Profile is based on a non-proprietary

Web services specification, along with clarifications and

amendments to that specification which promote
interoperability.

SAML Token Profile

1.0
WS-I
Working Group Draft

! SAML Token Profile is based on a non-proprietary

Web services specification, along with clarifications and

amendments to that specification which promote
interoperability.

metadata to others through a Web services interface. Given

only a reference to a Web service, a user can access a set
of WSDL /SOAP operations to retrieve the metadata that
describes the service.

Web Service Description

Language 2.0
SOAP Binding

1.1
OASIS
Committee Draft

! WS-Discovery defines a multicast discovery protocol for

dynamic discovery of services on ad-hoc and managed
networks.

enhancements to SOAP messaging to provide message

integrity and confidentiality. Specifically, this specification
provides support for multiple security token formats, trust
domains, signature formats and encryption technologies.
The token formats and semantics for using these are
defined in the associated profile documents.

! Web Services ReliableMessaging Policy Assertion

(WS-RM Policy) describes a domain-specific policy assertion

for WS-ReliableMessaging that that can be specified within
a policy alternative as defined in WS-Policy Framework.

Universal Description,
Discovery and Integration (UDDI)

defines a set of services supporting the description

and discovery of businesses, organizations, and other Web
services providers, the Web services they make available,
and the technical interfaces which may be used to access
those services.

! WS-Security: Kerberos Binding defines how to encode

Kerberos tickets and attach them to SOAP messages. As

well, it specifies how to add signatures and encryption to the
SOAP message, in accordance with WS-Security, which
uses and references the Kerberos tokens.

SOAP messages with guaranteed delivery, no duplicates,

and guaranteed message ordering. WS-Reliability is
defined as SOAP header extensions and is independent of
the underlying protocol. This specification contains a
binding to HTTP.

WS-Security:
SAML Token Profile

2.0
W3C
Candidate Recommendation

2.0
W3C Working Draft

! Web Service Description Language SOAP Binding

1.1
OASIS
Public Review Draft

! Web Service Description Language 2.0 Core is an XML-

describes the concrete details for using WSDL 2.0 in

conjunction with SOAP 1.1 protocol.

WS-Atomic Transaction

a Web Service consumer can supply a Username Token as a

means of identifying the requestor by username, and
optionally using a password (or shared secret, etc.) to
authenticate that identity to the Web Service producer.

! WS-Security: SAML Token Profile defines the use of

based language for describing Web services and how to

access them. It specifies the location of the service and the
operations (or methods) the service exposes.

Security Assertion Markup Language (SAML) v1.1 assertions

in the context of WSS: SOAP Message Security including
for the purpose of securing SOAP messages and SOAP
message exchanges.

Web Service Description

Language 1.1

WS-Federation

WS-ServiceGroup (WSRF)

! WS-Security: X.509 Certificate Token Profile describes

language for describing Web services and how to access

them. It specifies the location of the service and the
operations (or methods) the service exposes.

the use of the X.509 authentication framework with the

WS-Security: SOAP Message Security specification.

1.2
OASIS
Working Draft

Services and WS-Resources can be aggregated or grouped

together for a domain specific purpose.

WS-ResourceProperties
1.2
OASIS
Working Draft

! WS-Composite Application Framework (WS-CAF) is a

collection of three specifications aimed at solving problems

that arise when multiple Web Services are used in combination. It proposes standard, interoperable mechanisms for
managing shared context and ensuring business processes
achieve predictable results and recovery from failure.

trust relationships in a heterogeneous federated

environment including support for federated identities.

1.0
Arjuna Technologies, Fujitsu, IONA, Oracle
and Sun Microsystems
Committee Draft

BEA Systems, Computer Associates, IBM, Layer 7

Technologies, Microsoft, Netegrity, Oblix,
OpenNetwork, Ping Identity Corporation,
Reactivity, RSA Security, VeriSign and Westbridge
Technology Initial Draft

! WS-Context (WS-CTX) is intended as a lightweight mechanism

for allowing multiple Web Services to share a common context.

! WS-Trust describes a framework for trust models that enables

WS-Coordination

Web Services to securely interoperate. It uses WS-Security base

mechanisms and defines additional primitives and extensions
for security token exchange to enable the issuance and
dissemination of credentials within different trust domains.

Framework (WS-CF)
1.0 Arjuna Technologies, Fujitsu, IONA,
Oracle and Sun Microsystems
Committee Draft

WS-SecureConversation

! WS-Coordination Framework (WS-CF) allows the

BEA Systems, Computer Associates, IBM,

Layer 7 Technologies, Microsoft, Netegrity,
Oblix, OpenNetwork,
Ping Identity Corporation, Reactivity,
RSA Security, VeriSign and Westbridge
Technology Public Draft

management and coordination in a Web Services interaction

of a number of activities related to an overall application.

definition of the properties of a WS-Resource may be declared

as part of the Web Service interface. The declaration of the
WS-Resource properties represents a projection of or a view
on the WS-Resource state.

1.0 Arjuna Technologies, Fujitsu, IONA,

Oracle and Sun Microsystems
Committee Draft

! WS-SecureConversation specifies how to manage and

authenticate message exchanges between parties including

security context exchange and establishing and deriving
session keys.

WS-ResourceLifetime
1.2
OASIS
Working Draft

! WS-Transaction Management (WS-TXM) defines a core infrastructure

service consisting of a Transaction Service for Web Services.

concepts, message exchanges, WSDL and XML needed to

monitor the lifetime of, and destroy WS-Resources.
Additionally, it defines resource properties that may be used
to inspect and monitor the lifetime of a WS-Resource.

WS-Transfer

W3C
Recommendation

! Resource Representation SOAP Header Block (RRSHB)

complements MTOM by defining mechanisms for

describing and conveying non-XML resource representations
in a SOAP 1.2 message.

! Reliable Asynchronous Messaging Profile (RAMP) is a

Metadata

Reliability

WS-ServiceGroup
WS-ResourceProperties
WS-ResourceLifetime

Resource Representation SOAP Header Block (RRSHB)

Management Specifications
Management Using Web Services
Service Modeling Language

Business Process Specifications

Business Process Execution Language for Web Services
Web Service Choreography Description Language
Web Service Choreography Interface

Business Process Management Language

Business Process Execution Language for Web Serv. 2.0
XML Process Definition Language

SOAP

Messaging Specifications

Transaction Specifications
WS-Business Activity

" WS-Notification is a

family of related white

papers and specifications
that define a standard
Web services approach to
notification using a topicbased publish/subscribe
pattern.

WS-Notification
1.3
OASIS
OASIS-Standard

profile, in the fashion of the WS-I profiles, that enables,

among other things, basic B2B integration scenarios using
Web services technologies.

WS-Enumeration

" WS-BrokeredNotification

WS-BrokeredNotification
1.3
OASIS
OASIS-Standard

" WS-Enumeration describes

Systinet, Microsoft, Sonic Software, BEA

Systems and
Computer Associates
Public Draft

a general SOAP-based
protocol for enumerating
a sequence of XML
elements that is suitable
for traversing logs, message
queues, or other linear
information models.

defines the interface for

the NotificationBroker.
A NotificationBroker is an
intermediary, which, among
other things, allows
publication of messages
from entities that are not
themselves service
providers.

" WS-BaseNotification

WS-BaseNotification
1.3
OASIS
OASIS-Standard

standardizes the terminology,

concepts, operations, WSDL
and XML needed to express
the basic roles involved in
Web services publish and
subscribe for notification
message exchange.

" WS-Topics defines three

WS-Topics

1.3
OASIS
OASIS-Standard

" WS-Eventing defines a

WS-Eventing
W3C
Public Draft

WS-Addressing WSDL
Binding

topic expression dialects

that can be used as subscription expressions in
subscribe request messages
and other parts of the
WS-Notification system.

1.0
W3C
Candidate Recommendation

baseline set of operations

that allow Web services to
provide asynchronous
notifications to interested
parties.

" WS-Addressing Core

provides transport-neutral
mechanisms to address
Web services and messages.
This specification defines
XML elements to identify
Web service endpoints and
to secure end-to-end
endpoint identification in
messages.

WS-Addressing Core

" WS-Addressing WSDL

Binding defines how the

abstract properties defined
in Web Services Addressing
Core are described using
WSDL.

1.0
W3C
Recommendation

WS-Addressing
SOAP Binding

SOAP

1.2
W3C
Recommendation

" WS-Addressing SOAP

1.0
W3C
Recommendation

Binding provides transportneutral mechanisms to

address Web services and
messages.

SOAP Message
Transmission Optimization
Mechanism (MTOM)
1.0 W3C
Recommendation

" SOAP Message

Transmission
Optimization
Mechanism
describes an
abstract feature for
optimizing the
transmission and/or
wire format of a
SOAP message.

" SOAP is a lightweight,

SOAP
1.1
W3C
Note

XML-based protocol for

exchange of information
in a decentralized,
distributed environment.

WS-Atomic Transaction
WS-Coordination
WS-Composite Application Framework
WS-Transaction Management
WS-Context
WS-Coordination Framework

Presentation Specifications
Web Services for Remote Portlets

Standards Bodies

Version 3.0 February 2007

Messaging

WS-BaseFaults

WS-Choreography Model Overview

! Conformance Claim Attachment Mechanism (CCAM)

1.0
WS-I
Working Draft

WS-Reliable Messaging Policy Assertion

Resource Specifications

Management Of Web Services

accessing XML representations of Web service-based resources.

1.0
WS-I
Final Specification

Reliable Asynchronous
Messaging Profile (RAMP)

WS-Reliability

WS-Management

W3C
W3C Member Submission
! WS-Transfer describes a general SOAP-based protocol for

Conformance Claim
Attachment Mechanism (CCAM)

catalogues mechanisms that can be used to attach WS-I

Profile Conformance Claims to Web services artefacts
(e.g., WSDL descriptions, UDDI registries).

WS-SecureConversation

Reliability Specifications

WS-Transfer

! WS-ResourceLifetime is to standardize the terminology,

Resource Representation
SOAP Header Block (RRSHB)

WS-Transaction
Management (WS-TXM)

WS-Federation

Web Service Resource Framework

! WS-ResourceProperties specifies the means by which the

WS-Context (WS-CTX)

WS-Trust

WS-SecurityPolicy

WS-ReliableMessaging

! WS-ServiceGroup (WSRF) defines a means by which Web

1.0 Arjuna Technologies, Fujitsu, IONA,

Oracle and Sun Microsystems
Committee Specification

! WS-Federation describes how to manage and broker the

1.1
OASIS
Public Review Draft

! Web Service Description Language 1.1 is an XML-based

WS-Composite Application
Framework (WS-CAF)

1.0
IBM, Microsoft, BEA Systems,
RSA Security, and VeriSign
Initial Draft

WS-Security: X.509
Certificate Token Profile

1.1
W3C
Note

that may appear in fault messages. WS-BaseFaults defines an

XML schema type for base faults, along with rules for how
this base fault type is used and extended by Web Services.

1.1
OASIS
Committee Draft

WS-Security: Username Token Profile

WS-Trust

! WS-BaseFaults (WSRF) defines a base set of information

! WS-Atomic Transaction defines protocols that enable existing

1.0
Microsoft, IBM, OASIS
Working Draft

! WS-Reliability is a SOAP-based protocol for exchanging

Web Service Description

Language 2.0 Core

coordination type that is to be used with the extensible coordination

framework described in the WS-Coordination specification.

! WS-Security: Username Token Profile describes how

WS-Security:
Kerberos Binding

1.1
OASIS
OASIS-Standard

! Universal Description, Discovery and Integration (UDDI)

! WS-Business Activity provides the definition of the business activity

transaction processing systems to wrap their proprietary protocols

and interoperate across different hardware and software vendors.

WS-Reliability

3.0.2
OASIS
OASIS-Standard

1.2
OASIS
Working Draft

Metadata

1.1
BEA Systems, Computer Associates,
IBM, Microsoft, SAP, Sun Microsystems and
webMethods
Public Draft

! WS-Security: SOAP Message Security describes

1.1
OASIS
Public Review Draft

WS-Security: X.509 Certificate Token Profile

Messaging

WS-MetadataExchange

WS-Reliable Messaging
Policy Assertion (WS-RM Policy)

WS-BaseFaults (WSRF)

1.1
OASIS
Working Draft

Security

Profile consists of those Basic Profile 1.0 requirements

related to the serialization of the envelope and its
representation in the message.

mechanisms for associating policies with the subjects to

which they apply; the policies may be defined as part
of existing metadata about the subject or the policies may
be defined independently and associated through an
external binding to the subject.

1.1
OASIS
Public Review Draft

specifications for accessing stateful resources using Web Services.

WS-Business Activity

WS-Security:
Username Token Profile

WS-Security: Kerberos Binding

WS-Security: SAML Token Profile

! Web Services Resource Framework (WSRF) defines a family of

Messaging

! Simple SOAP Binding Profile The Simple SOAP Binding

Microsoft, BEA Systems, Canon,

Intel and webMethods
Draft

! WS-PolicyAttachment defines two general-purpose

! WS-Coordination describes an extensible framework for providing

WS-Security: SOAP Message Security

Reliability

1.0
WS-I
Final Specification

to various features defined in the WS-Security specification.

WS-Security:
SOAP Message Security

Web services to communicate reliable in the presence of

software component, system, or network failures. It defines
a SOAP binding that is required for interoperability.

WS-Discovery

1.2
W3C
W3C Member Submission

! WS-SecurityPolicy defines how to describe policies related

1.2
OASIS
OASIS-Standard

Basic Profile

! WS-ReliableMessaging describes a protocol that allows

WS-PolicyAttachment

WS-Security

protocols that coordinate the actions of distributed applications.

complements the Basic Profile 1.1 to add support

for interoperable SOAP Messages with attachments-based
Web Services.

Simple SOAP
Binding Profile

means for applying security to Web Services.

Web Services
Resource Framework (WSRF)

1.1
OASIS
Working Draft

Security

to address some common needs of Web Services

applications.

! WS-Security is a communications protocol providing a

WS-Coordination

Security

the policies on intermediaries and endpoints (e.g. business

rules, required security tokens, supported encryption
algorithms, privacy rules).

1.1
OASIS
Committee Draft

! WS-PolicyAssertions provides an initial set of assertions

1.1
IBM, Microsoft,
RSA Security, VeriSign
Public Draft

1.1
OASIS
OASIS-Standard

Messaging

! WS-Policy describes the capabilities and constraints of

WS-SecurityPolicy

WS-Security

WS-ReliableMessaging

Secur.

! Attachments Profile The Attachment Profile 1.0

1.1
BEA Systems,
IBM, Microsoft, SAP
Public Draft

1.5
W3C
Working Draft

Web Service Description Language 2.0 SOAP Binding

Security Specifications

Transaction

1.0
WS-I
Final Specification

WS-PolicyAssertions

WS-Policy

Web Service Description Language 2.0 Core

Transaction

Attachments Profile

Resource
Specifications

Meta

BP that includes a profile of SOAP 1.2.

Transaction
Specifications

Resource

! Basic Profile The Basic Profile 2.0 is an update of WS-I

Security Specifications

Security

Reliability
Specifications

Reliability

Metadata Specifications

Metadata

2.0
WS-I
Working Group Draft

Reliab.

Basic Profile

Metadata

WS-BrokeredNotification

2.0
OASIS
Committee Draft

! WS-Management describes a general SOAP-based

IBM, BEA, BMC, Cisco, Dell, HP, Intel,

Microsoft, Sun
Draft Specification

! XML Process Definition Language (XPDL) provides an

WS-BaseNotification
WS-Topics

Web Services for Remote

Portlets (WSRP)

Service Modeling Language

2.0
Final

! Business Process Management Language (BPML)

1.0
OASIS
OASIS-Standard

WS-Notification

Messaging

1.1(BPEL4WS) provides a language for the formal

specification of business processes and business interaction
protocols using Web Services.

! WS-Choreography Model Overview defines the format

1.0
OASIS
OASIS-Standard

(CDL4WS) 1.0 W3C

Candidate Recommendation

WS-Management

AMD, Dell, Intel, Microsoft and Sun

Microsystems
Published Specification

Messaging

Basic Profile

1.2
WS-I
Working Group Draft

! Business Process Execution Language for Web Services

Management Of
Web Services (WSDM-MOWS)

SOAP Message Transmission Optimization Mechanism

Transaction

implementation guidelines for how related set of nonproprietary Web Service specifications should be used
together for best interoperability.

(WSCI) 1.0 W3C

Sun Microsystems, SAP, BEA Systems
and Intalio Note

1.0 W3C
Working Draft

Management Using Web

Services (WSDM-MUWS)

Web Service Choreography

Description Language

SOAP 1.2

Security

! Basic Profile The Basic Profile 1.1 provides

(BPEL4WS) 1.1 BEA Systems, IBM,

Microsoft, SAP,
Siebel Systems OASIS-Standard

Web Service Choreography

Interface

WS-Choreography Model
Overview

Presentation
Specifications

Mess.

1.1
WS-I
Final Specification

Business Process Execution

Language for Web Services 1.1

Management Specifications

Resource

Basic Profile

Business Process Specifications

Security

Interoperability
Issues

The Organization for the Advancement of Structured Information

Standards (OASIS) is a not-for-profit, international consortium
that drives the development, convergence, and adoption of e-business standards. The
consortium produces more Web services standards than any other organization along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 4,000 participants representing
over 600 organizations and individual members in 100 countries.
The World Wide Web Consortium (W3C) was created in October 1994 to lead the
World Wide Web to its full potential by developing common protocols that promote
its evolution and ensure its interoperability. W3C has over 350 Member organizations from all over the world and has earned international recognition for its contributions to the
growth of the Web. W3C is designing the infrastructure, and defining the architecture and the core
technologies for Web services. In September 2000, W3C started the XML Protocol Activity to address
the need for an XML-based protocol for application-to-application messaging. In January 2002, the
Web Services Activity was launched, subsuming the XML Protocol Activity and extending its scope.
The Web Services Interoperability Organization (WS-I) is an open industry
organization chartered to promote Web services interoperability across platforms,
operating systems and programming languages. The organizations diverse community of Web
services leaders helps customers to develop interoperable Web services by providing guidance,
recommended practices and supporting resources. Specifically, WS-I creates, promotes and
supports generic protocols for the interoperable exchange of messages between Web services.
The Internet Engineering Task Force (IETF) is a large open international
community of network designers, operators, vendors, and researchers
concerned with the evolution of the Internet architecture and the smooth
operation of the Internet.

XML Specifications
" XML Extensible Markup

XML 1.1

1.1
W3C
Recommendation

Language is a pared-down
version of SGML, designed
especially for Web
documents. It allows one to
create own customized tags,
enabling the definition,
transmission, validation, and
interpretation of data
between applications and
between organizations.

" XML Extensible Markup

XML 1.0

1.0
W3C
Recommendation

Language is a pared-down
version of SGML, designed
especially for Web
documents. It allows one to
create own customized tags,
enabling the definition,
transmission, validation, and
interpretation of data
between applications and
between organizations.

" Namespaces in XML

Namespaces in XML
1.1
W3C
Recommendation

provides a simple method

for qualifying element and
attribute names used in XML
documents by associating
them with namespaces
identified by IRI references.

" XML Information Set is

XML Information Set

1.0
W3C
Recommendation

an abstract data set to

provide a consistent set of
definitions for use in other
specifications that need to
refer to the information
in a well-formed XML
document.

11
marted 13 dicembre 2011

" XML Schema XML

XML Schema
1.1
W3C
Working Draft

Schema Definition Language

is an XML language for
describing and constraining
the content of XML
documents.

XML binary Optimized

Packaging (XOP)
1.0
W3C
Recommendation

" XML binary Optimized

Packaging (XOP) is an XML

language for describing and
constraining the content of
XML documents.

Describing Media Content

of Binary Data in XML
(DMCBDX)
W3C
Note

" Describing Media Content

of Binary Data in XML

(DMCBDX) specifies how to
indicate the content-type
associated with binary
element content in an XML
document and to specify, in
XML Schema, the expected
content-type(s) associated
with binary element
content.

innoQ Deutschland GmbH

Halskestrae 17
D-40880 Ratingen
Phone +49 21 02 77 162 -100
info@innoq.com www.innoq.com

innoQ Schweiz GmbH

Gewerbestrasse 11
CH-6330 Cham
Phone +41 41 743 01 11

This poster is not to be reproduced or transmitted in any form or for any purpose without the express permission of innoQ Deutschland GmbH. Copyright

Dependencies

innoQ Deutschland GmbH. All Rights Reserved. The poster may also contain references to other company, organisation, brand and product names. These company, organisation, brand and product names are used herein for identification purposes only and may be the trademarks of their respective owners.

Web Services Standards Overview

Birth of BPEL
IBM was pushing for a standard called WSFL
Microsoft was pushing for a technology called XLANG
Intalio was pushing for BPML
IBM and Microsoft merged their efforts and pushed together
for BPEL (a hybrid WSFL+XLANG)
and BPEL was soon widely adopted
12
marted 13 dicembre 2011

Life of BPEL
BPEL4WS 1.0 (2002) by BEA, IBM, Microsoft
SAP + Siebel joined the effort
BPEL 1.1 (2003)
submitted to OASIS
Adobe + HP + NEC + Oracle + Sun + many more joined
WS-BPEL 2.0 (2005)

13
marted 13 dicembre 2011

The problem with BPEL

BPEL is not a graphical language
BPEL is an XML dialect
Machines like XML
Humans being should not like XML

14
marted 13 dicembre 2011

A typical BPEL tutorial

Turn to page 4 of any BPEL tutorial
(the first couple of pages are just a verbal introduction)
and you find the first small example...
... of about two pages of formatted XML code
(with all actual namespaces
to avoid any misunderstanding)

15
marted 13 dicembre 2011

BPELexample.xml

Page 1 of 2

BPELexample.xml

Page 2

48
1
!
!

<process name="purchaseOrderProcess" targetNamespace="http://example.com/ws-bp/

purchase" xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
xmlns:lns="http://manufacturing.org/wsdl/purchase">

!
!
49
50

2
3
4
5

<documentation xml:lang="EN">
A simple example of a WS-BPEL process for handling a purchase order.
</documentation>

51
52
53
54

6
7
8
!
9
!
10
!
11
!
12

<partnerLinks>
<partnerLink name="purchasing" partnerLinkType="lns:purchasingLT"
myRole="purchaseService" />
<partnerLink name="invoicing" partnerLinkType="lns:invoicingLT"
myRole="invoiceRequester" partnerRole="invoiceService" />
<partnerLink name="shipping" partnerLinkType="lns:shippingLT"
myRole="shippingRequester" partnerRole="shippingService" />
<partnerLink name="scheduling" partnerLinkType="lns:schedulingLT"
partnerRole="schedulingService" />
</partnerLinks>

!
55
56
57
58
59
60
61
62
!
63

13
14
15
16
17
!
18
19
20

<variables>
<variable name="PO" messageType="lns:POMessage" />
<variable name="Invoice" messageType="lns:InvMessage" />
<variable name="shippingRequest"
messageType="lns:shippingRequestMessage" />
<variable name="shippingInfo" messageType="lns:shippingInfoMessage" />
<variable name="shippingSchedule" messageType="lns:scheduleMessage" />
</variables>

64
65
66
67
!
68
69
70
71

21
22
23
!
24
!
!
25
26

<faultHandlers>
<catch faultName="lns:cannotCompleteOrder" faultVariable="POFault"
faultMessageType="lns:orderFaultType">
<reply partnerLink="purchasing" portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder" variable="POFault"
faultName="cannotCompleteOrder" />
</catch>
</faultHandlers>

72
73
74
75
!
76
77
78
!

27
28
29
!
30
31

<sequence>
<receive partnerLink="purchasing" portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder" variable="PO" createInstance="yes">
<documentation>Receive Purchase Order</documentation>
</receive>

79
80
81
82
83
!

32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

<flow>
<documentation>
A parallel flow to handle shipping, invoicing and scheduling
</documentation>
<links>
<link name="ship-to-invoice" />
<link name="ship-to-scheduling" />
</links>
<sequence>
<assign>
<copy>
<from>$PO.customerInfo</from>
<to>$shippingRequest.customerInfo</to>
</copy>
</assign>
<invoke partnerLink="shipping" portType="lns:shippingPT"

!
!

marted 13 dicembre 2011

84
85
86
87
88
89
90
91
92
93
!
94
95
96

16

operation="requestShipping" inputVariable="shippingRequest"
outputVariable="shippingInfo">
<documentation>Decide On Shipper</documentation>
<sources>
<source linkName="ship-to-invoice" />
</sources>
</invoke>
<receive partnerLink="shipping" portType="lns:shippingCallbackPT"
operation="sendSchedule" variable="shippingSchedule">
<documentation>Arrange Logistics</documentation>
<sources>
<source linkName="ship-to-scheduling" />
</sources>
</receive>
</sequence>
<sequence>
<invoke partnerLink="invoicing" portType="lns:computePricePT"
operation="initiatePriceCalculation" inputVariable="PO">
<documentation>
Initial Price Calculation
</documentation>
</invoke>
<invoke partnerLink="invoicing" portType="lns:computePricePT"
operation="sendShippingPrice" inputVariable="shippingInfo">
<documentation>
Complete Price Calculation
</documentation>
<targets>
<target linkName="ship-to-invoice" />
</targets>
</invoke>
<receive partnerLink="invoicing" portType="lns:invoiceCallbackPT"
operation="sendInvoice" variable="Invoice" />
</sequence>
<sequence>
<invoke partnerLink="scheduling" portType="lns:schedulingPT"
operation="requestProductionScheduling" inputVariable="PO">
<documentation>
Initiate Production Scheduling
</documentation>
</invoke>
<invoke partnerLink="scheduling" portType="lns:schedulingPT"
operation="sendShippingSchedule" inputVariable="shippingSchedule">
<documentation>
Complete Production Scheduling
</documentation>
<targets>
<target linkName="ship-to-scheduling" />
</targets>
</invoke>
</sequence>
</flow>
<reply partnerLink="purchasing" portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder" variable="Invoice">
<documentation>Invoice Processing</documentation>
</reply>
</sequence>
</process>

A syntax called
semantics
Learning BPEL by looking at XML documents
is like
learning Petri nets by looking at PNML documents
or similar to
learning Java by looking at the bytecode
17
marted 13 dicembre 2011

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

<?xml version="1.0" encoding="UTF-8"?><pnml>

<net type="http://www.informatik.hu-berlin.de/top/pntd/ptNetb" id="noID">
<place id="p6">
<name>
<text>p6</text>
<graphics>
<offset x="430" y="270"/>
</graphics>
</name>
<graphics>
<position x="430" y="230"/>
<dimension x="40" y="40"/>
</graphics>
</place>
<place id="p5">
<name>
<text>p5</text>
<graphics>
<offset x="300" y="320"/>
</graphics>
</name>
<graphics>
<position x="300" y="280"/>
<dimension x="40" y="40"/>
</graphics>
</place>
<place id="p4">
<name>
<text>p4</text>
<graphics>
<offset x="180" y="320"/>
</graphics>
</name>
<graphics>
<position x="180" y="280"/>
<dimension x="40" y="40"/>
</graphics>
</place>
<place id="p3">
<name>
<text>p3</text>
<graphics>
<offset x="300" y="220"/>
</graphics>
</name>
<graphics>
<position x="300" y="180"/>
<dimension x="40" y="40"/>
</graphics>
</place>
<place id="p2">
<name>
<text>p2</text>
<graphics>
<offset x="180" y="220"/>
</graphics>
</name>
<graphics>
<position x="180" y="180"/>
<dimension x="40" y="40"/>
</graphics>
</place>
<place id="p1">
<name>
<text>p1</text>
<graphics>
<offset x="40" y="270"/>
</graphics>
</name>
<graphics>
<position x="40" y="230"/>
<dimension x="40" y="40"/>
</graphics>
<initialMarking>
<text>1</text>
</initialMarking>
</place>

PNMLnet.xml
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225

18

226
227
228
229
230
231

marted 13 dicembre 2011

<dimension x="40" y="40"/>

</graphics>
<toolspecific tool="WoPeD" version="1.0">
<time>0</time>
<timeUnit>1</timeUnit>
<orientation>1</orientation>
</toolspecific>
</transition>
<arc id="a9" source="t1" target="p4">
<inscription>
<text>1</text>
</inscription>
<graphics/>
<toolspecific tool="WoPeD" version="1.0">
<probability>1.0</probability>
<displayProbabilityOn>false</displayProbabilityOn>
<displayProbabilityPosition x="500.0" y="0.0"/>
</toolspecific>
</arc>
<arc id="a17" source="p3" target="t4">
<inscription>
<text>1</text>
</inscription>
<graphics/>
<toolspecific tool="WoPeD" version="1.0">
<probability>1.0</probability>
<displayProbabilityOn>false</displayProbabilityOn>
<displayProbabilityPosition x="500.0" y="0.0"/>
</toolspecific>
</arc>
<arc id="a14" source="p5" target="t4">
<inscription>
<text>1</text>
</inscription>
<graphics/>
<toolspecific tool="WoPeD" version="1.0">
<probability>1.0</probability>
<displayProbabilityOn>false</displayProbabilityOn>
<displayProbabilityPosition x="500.0" y="0.0"/>
</toolspecific>
</arc>
<arc id="a21" source="p3" target="t5">
<inscription>
<text>1</text>
</inscription>
<graphics/>
<toolspecific tool="WoPeD" version="1.0">
<probability>1.0</probability>
<displayProbabilityOn>false</displayProbabilityOn>
<displayProbabilityPosition x="500.0" y="0.0"/>
</toolspecific>
</arc>
<arc id="a13" source="t3" target="p5">
<inscription>
<text>1</text>
</inscription>
<graphics/>
<toolspecific tool="WoPeD" version="1.0">
<probability>1.0</probability>
<displayProbabilityOn>false</displayProbabilityOn>
<displayProbabilityPosition x="500.0" y="0.0"/>
</toolspecific>
</arc>
<arc id="a10" source="p4" target="t3">
<inscription>
<text>1</text>
</inscription>
<graphics/>
<toolspecific tool="WoPeD" version="1.0">
<probability>1.0</probability>
<displayProbabilityOn>false</displayProbabilityOn>
<displayProbabilityPosition x="500.0" y="0.0"/>
</toolspecific>
</arc>
<arc id="a24" source="t5" target="p2">
<inscription>
<text>1</text>

78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154

Page 3 of 4

<transition id="t3">
<name>
<text>t3</text>
<graphics>
<offset x="240" y="320"/>
</graphics>
</name>
<graphics>
<position x="240" y="280"/>
<dimension x="40" y="40"/>
</graphics>
<toolspecific tool="WoPeD" version="1.0">
<time>0</time>
<timeUnit>1</timeUnit>
<orientation>1</orientation>
</toolspecific>
</transition>
<transition id="t2">
<name>
<text>t2</text>
<graphics>
<offset x="240" y="220"/>
</graphics>
</name>
<graphics>
<position x="240" y="180"/>
<dimension x="40" y="40"/>
</graphics>
<toolspecific tool="WoPeD" version="1.0">
<time>0</time>
<timeUnit>1</timeUnit>
<orientation>1</orientation>
</toolspecific>
</transition>
<transition id="t1">
<name>
<text>t1</text>
<graphics>
<offset x="120" y="270"/>
</graphics>
</name>
<graphics>
<position x="120" y="230"/>
<dimension x="40" y="40"/>
</graphics>
<toolspecific tool="WoPeD" version="1.0">
<time>0</time>
<timeUnit>1</timeUnit>
<orientation>1</orientation>
</toolspecific>
</transition>
<transition id="t4">
<name>
<text>t4</text>
<graphics>
<offset x="360" y="270"/>
</graphics>
</name>
<graphics>
<position x="360" y="230"/>
<dimension x="40" y="40"/>
</graphics>
<toolspecific tool="WoPeD" version="1.0">
<time>0</time>
<timeUnit>1</timeUnit>
<orientation>1</orientation>
</toolspecific>
</transition>
<transition id="t5">
<name>
<text>t5</text>
<graphics>
<offset x="240" y="150"/>
</graphics>
</name>
<graphics>
<position x="240" y="110"/>

PNMLnet.xml
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307

</inscription>
<graphics/>
<toolspecific tool="WoPeD" version="1.0">
<probability>1.0</probability>
<displayProbabilityOn>false</displayProbabilityOn>
<displayProbabilityPosition x="500.0" y="0.0"/>
</toolspecific>
</arc>
<arc id="a1" source="p1" target="t1">
<inscription>
<text>1</text>
</inscription>
<graphics/>
<toolspecific tool="WoPeD" version="1.0">
<probability>1.0</probability>
<displayProbabilityOn>false</displayProbabilityOn>
<displayProbabilityPosition x="500.0" y="0.0"/>
</toolspecific>
</arc>
<arc id="a2" source="t1" target="p2">
<inscription>
<text>1</text>
</inscription>
<graphics/>
<toolspecific tool="WoPeD" version="1.0">
<probability>1.0</probability>
<displayProbabilityOn>false</displayProbabilityOn>
<displayProbabilityPosition x="500.0" y="0.0"/>
</toolspecific>
</arc>
<arc id="a5" source="p2" target="t2">
<inscription>
<text>1</text>
</inscription>
<graphics/>
<toolspecific tool="WoPeD" version="1.0">
<probability>1.0</probability>
<displayProbabilityOn>false</displayProbabilityOn>
<displayProbabilityPosition x="500.0" y="0.0"/>
</toolspecific>
</arc>
<arc id="a6" source="t2" target="p3">
<inscription>
<text>1</text>
</inscription>
<graphics/>
<toolspecific tool="WoPeD" version="1.0">
<probability>1.0</probability>
<displayProbabilityOn>false</displayProbabilityOn>
<displayProbabilityPosition x="500.0" y="0.0"/>
</toolspecific>
</arc>
<arc id="a18" source="t4" target="p6">
<inscription>
<text>1</text>
</inscription>
<graphics/>
<toolspecific tool="WoPeD" version="1.0">
<probability>1.0</probability>
<displayProbabilityOn>false</displayProbabilityOn>
<displayProbabilityPosition x="500.0" y="0.0"/>
</toolspecific>
</arc>
<toolspecific tool="WoPeD" version="1.0">
<bounds>
<position x="11" y="33"/>
<dimension x="755" y="490"/>
</bounds>
<treeWidth>2</treeWidth>
<verticalLayout>false</verticalLayout>
<resources/>
<simulations/>
<partnerLinks/>
<variables/>
</toolspecific>
</net>
</pnml>

A matter
of
abstraction
!"#$%&'"%$
!"#$%"()&*"%
!"#$%&'#$()#*&+,(-%$.&-$/#$(00#*#1$/2$&$3#/$%#*4,.#5$,-$&$
!"#$%&'"%$

!"#$%"()&*"%
'&.",-#67-1#*%+&-1&/8#$0(*'&+
A technology should never become THE model
<operation name = "CheckAvailability">
(though it can serve
as a= "CheckInDate"/>
source of inspiration)
< input message

"&'()"%this way of thinking can have a terrific impact

< input message = "CheckOutDate"/>
< input message = "NRooms"/>
<output message = "Result"/>
</operation>

!"#$%&'#$()#*&+,(-%$.&-$/#$(00#*#1$/2$&$3#/$%#
)&0#1+232"$+'#"445)6"%).&$#7$)&0#%8+#
in the /2$%)#.,02,-9$&88$+"#$-##1#1$%2-+&.+,.$1#+&,8%$:()#*&+,(-$
near future (in training
technical personnel)
'&.",-#67-1#*%+&-1&/8#$0(*'&+
+&#$%"&'"('$#.D+(#"&#C&%+(&+%#4(.%.6.5#
-&'#5$,-)7+$&-1$(7+)7+$)&*&'#+#*%;
XML
SOAP
WSDL
UDDI

http://www.w3.org/XML/
http://www.w3.org/TR/soap/
http://www.w3.org/TR/wsdl20/
http://www.uddi.org/

5"67&
-..;%$,#03&4<=+>7
marted 13 dicembre 2011

<operation name = "CheckAvailability">

< input message = "CheckInDate"/>
< input message = "CheckOutDate"/>
< input message = "NRooms"/>
10
<output message = "Result"/>
</operation>

19
/2$%)#.,02,-9$&88$+"#$-##1#1$%2-+&.+,.$1#+&,8%$:()

The source of the

problem
BPEL is designed to work with WSDL documents
of the services required by the process
A process can itself be exposed as a service
which needs its own WSDL document
For us:
we can forget that WSDL documents are written in XML
we regard them as abstract interface descriptions
20
marted 13 dicembre 2011

BPEL guidelines

21
marted 13 dicembre 2011

Structured control vs
free flow
BPEL4WS should provide
both hierarchical and graph-like control regimes,
and allow their usage to be blended
as seamlessly as possible.

22
marted 13 dicembre 2011

About data handling

BPEL4WS provides limited data manipulation functions

that are sufficient for the simple manipulation of data
that is needed to define
process relevant data and control flow.

23
marted 13 dicembre 2011

Correlation
BPEL4WS should support an
identification mechanism for process instances
that allows the definition of instance identifiers
at the application message level.
Instance identifiers should be partner defined
and may change over time.

24
marted 13 dicembre 2011

Transactions
BPEL4WS should define a long-running transaction model
that is based on practically proven techniques
like compensation actions and scoping
to support failure recovery for parts of
long-running business processes.

25
marted 13 dicembre 2011

Abstract vs executable
BPEL4WS should define a set of Web service orchestration
concepts that are meant to be used in common by both
the external (abstract) and
internal (executable) views of a business process.
Such a business process defines the behavior of a single
autonomous entity, typically operating in interaction with
other similar peer entities.
It is recognized that each usage pattern (i.e. abstract
view and executable view) will require a few specialized
extensions, but these extensions are to be kept to a
minimum and tested against requirements
26
marted 13 dicembre 2011

WSDL preliminaries

27
marted 13 dicembre 2011

Service
A service can be thought of as a container
for a set of (logically related) operations
that are made available via web-based protocols
Roughly: a remote object

28
marted 13 dicembre 2011

PortType / Interface
The <portType> element,
renamed to <interface> in WSDL 2.0,
defines a web service,
the operations that can be performed,
and the messages that are used to perform the operation.
Roughly: a remote (abstract) class

29
marted 13 dicembre 2011

Operation
Each operation can be thought of as
a method or function call in some programming language.
Four kinds of operations
(one-way, request-response, notification, solicit-response)
Three kinds of parameters/arguments
(input, output, fault)
(not all combinations allowed)
Roughly: a remote (abstract) method
30
marted 13 dicembre 2011

Port / Endpoint
The <port> element,
renamed to <endpoint> in WSDL 2.0,
declares the address of a web service.
It typicaIly involves a name, a binding and a URL

31
marted 13 dicembre 2011

Binding

The binding specifies the interface as well as

the SOAP binding style (message format)
and SOAP transport protocol.

32
marted 13 dicembre 2011

WSDL (from wikipedia)

33
marted 13 dicembre 2011

PurchaseExample.wsdl
1
2
3
!
4
!
5
!
6
7
8
9
10
!
11
!
12
13
14
!
15
!
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
!
33
34

Page 1 of 2

PurchaseExample.wsdl

<?xml version="1.0" encoding="UTF-8"?>

<wsdl:definitions name="PurchaseExample"
targetNamespace="http://www.fluidimagination.com/
sams/PurchaseExample.wsdl"
xmlns:tns="http://www.fluidimagination.com/sams/
PurchaseExample.wsdl"
xmlns:soap="http://www.schemas.xmlsoap.org/wsdl/
soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

35
36
37
38
39
40
41
!
42
43

<wsdl:types>
<xsd:schema
targetNamespace="http://
www.fluidimagination.com/sams/productType.wsdl"
xmlns:xsd="http://www.w3.org/2001/
XMLSchema">
<xsd:complexType name="scannerType">
<xsd:all>
<xsd:element name="upc"
type="upcType"/>
<xsd:element name="isbn"
type="isbnType"/>
</xsd:all>
</xsd:complexType>
<xsd:simpleType name="upcType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="[0-9]{12}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="isbnType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="([0-9]- ){10}"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
</wsdl:types>
<!-- Adding a message that has two addresses -->
<wsdl:message name="purchaseMessage">
<wsdl:part name="productCode"
element="tns:scannerType"/>
</wsdl:message>
<!--create a port type with one operation -->

!
44
45
46
47
48
49
50
51
!
52
53
!
54
55
56
57
58
59
60

34
marted 13 dicembre 2011

Page 2 of

<wsdl:portType name="purchaseType">
<wsdl:operation name="purchaseOperation">
<wsdl:input name="tns:purchaseMessage"/>
</wsdl:operation>
</wsdl:portType>
<!--Bind the message to SOAP using HTTP -->
<wsdl:binding name="purchaseBinding"
type="tns:purchaseType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/
http"/>
<wsdl:operation name="tns:purchaseOperation">
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
</wsdl:operation>
</wsdl:binding>
<!--Bind the message to SOAP over SMTP -->
<wsdl:binding name="purchaseBindingSMTP"
type="tns:purchaseType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/
smtp"/>
<wsdl:operation name="tns:purchaseOperation">
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>

BPEL ingredients
(material partly stolen from Antonio Brogis slides
on Software Services, thanks!)

35
marted 13 dicembre 2011

BPEL ingredients
Data flow
(scoped variables)
Partner links and Message correlation
Message flow
(one-way, request-response, notify, solicit-response)
Control flow
(structured activities and synchronization links)
Handling events, faults, compensations
36
marted 13 dicembre 2011

Variable
Variables can be defined (within a local scope)
The activity <assign> can be used to copy data
(messages, part of messages, service references)
between variables
<assign>
<copy>
<from variable="PO" part="customerInfo"/>
<to variable="shippingRequest" part="customerInfo"/>
</copy>
</assign>

37
marted 13 dicembre 2011

Partner Link
A partner is a service that the process invokes,
or a client that invokes the process
A BPEL process interacts with a partner using a
<partnerLink> a (typed) connector
that the process offers to/requires from its partner
(to be declared in the BPEL document)
<partnerLinks>
<partnerLink name="shipping"
partnerLinkType="lns:shippingLT"
myRole="shippingRequester"
partnerRole="shippingService"/>
...
</partnerLinks>
38

marted 13 dicembre 2011

Stateless services,
stateful processes
When a message for (WS-BPEL) service arrives,
it must be delivered either to a new
or to an existing instance of the process
Stateful business processes are instantiated to act
according to interaction history
Messages should not only be delivered to the correct port,
but also to the correct instance of the business process
that provides that port
39
marted 13 dicembre 2011

Message correlation
Message correlation is the way to tie together
messages coming from different communications
A correlation set is a set properties such that
all messages having the same values of all properties
are part of the same interaction
The partner that first fixes the values of the properties
in the correlation set is the initiator of the exchange,
the other partners are called the followers
40
marted 13 dicembre 2011

Message flow
Basic activities are available
to send and receive messages to partners
Activity <invoke>: asynchronous (one-way) or
synchronous (request-response)
Activity <receive>: a request from a partner to execute
one of the (WSDL) operations implemented by the process
Activity <reply>: to return the result of a <receive>d
synchronous request-response operation
41
marted 13 dicembre 2011

Invoke
Needed information: the <partnerLink>,
the WSDL <portType> of the service to be invoked, and
the name and parameters of the <operation>
<invoke partnerLink="shipping"
portType="lns:shippingPT"
operation="requestShipping"
inputVariable="shippingRequest"
outputVariable="shippingInfo">
<source linkName="ship-to-invoice"/>
</invoke>

42
marted 13 dicembre 2011

Receive
Needed information: the <partnerLink>,
the WSDL <portType> of the exposed service, and
a <variable> where to copy the parameters of the
<operation>

<receive partnerLink="purchasing"
portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder"
variable="PO">
</receive>

43
marted 13 dicembre 2011

Reply
A process can <reply> to a message it <receive>d

<reply partnerLink="purchasing"
portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder"
variable="Invoice" />

Asynchronous operations do not use <reply>

If a reply must sent,
<invoke> is used to call back a client operation
44
marted 13 dicembre 2011

45
marted 13 dicembre 2011

Structured activities
only one branch
is selected

<sequence> for specifying sequential compositions

<switch> for (local) internal choices
(ordered list of conditional <case> branches,
possibly ended by an <otherwise> branch)

<pick> for (global) external choices

(set of event handlers of the form event activity,
<onMessage> arrival of a message or <onAlarm> timer)
<flow> for parallel composition
<while> for iterations (guards are XPath expressions)
46

marted 13 dicembre 2011

Link
A <link> expresses synchronisation dependencies
among activities in a process
Each <link> has a name,
one source activity, one target activity, and
it may be associated with a transition condition
(a predicate to be evaluated when the source activity ends)

47
marted 13 dicembre 2011

Join condition
Any activity that is the target of one or more links
may have an explicit <joinCondition>,
(a predicate on the status values of the incoming links,
to be evaluated once all such values have been determined)
otherwise the implicit join condition is the OR
If the <joinCondition> evaluates:
TRUE the activity can be executed,
FALSE a <joinFailure> fault may be thrown
(depending on the <suppressJoinFailure> flag
48
marted 13 dicembre 2011

Scope
A scope provides fault and compensation handling
capabilities to the activities nested within it
A <scope> activity consists of:
a primary activity,
a set of (optional) fault handlers,
a single (optional) compensation handlers,
a set of (optional) event handlers
(executed concurrently with the process,
they enable a scope to react to messages and alarm events)
49
marted 13 dicembre 2011

Formal Semantics and Analysis of Control Flow in WS-BPEL!

(Revised Version)

Chun Ouyang1 , Eric Verbeek2 , Wil M.P. van der Aalst2,1 , Stephen Breutel1 ,
Marlon Dumas1 , and Arthur H.M. ter Hofstede1
1

Faculty of Information Technology, Queensland University of Technology,

GPO Box 2434, Brisbane QLD 4001, Australia
{c.ouyang,sw.breutel,m.dumas,a.terhofstede}@qut.edu.au
Department of Technology Management, Eindhoven University of Technology,
GPO Box 513, NL-5600 MB, The Netherlands
{h.m.w.verbeek,w.m.p.v.d.aalst}@tm.tue.nl

Formal semantics of
control flow in BPEL

Abstract. Web service composition refers to the creation of new (Web) services by combination of
functionality provided by existing ones. This paradigm has gained significant attention in the Web
services community and is seen as a pillar for building service-oriented applications. A number of
domain-specific languages for service composition have been proposed with consensus being formed
around a process-oriented language known as WS-BPEL (or BPEL). The kernel of BPEL consists
of simple communication primitives that may be combined using control-flow constructs expressing
sequence, branching, parallelism, synchronisation, etc. As a result, BPEL process definitions lend
themselves to static flow-based analysis techniques. This report aims at validating the feasibility of
using Petri nets for static analysis of BPEL processes. We present a comprehensive and rigorously
defined mapping of BPEL constructs into Petri net structures. This leads to the implementation
of a tool which operates by translating BPEL processes into Petri nets and exploiting existing
Petri net analysis techniques. The tool performs two useful types of static checks and extracts
meta-data to optimise dynamic resource management.
Keywords: Business process modelling, Web services, BPEL, tool-based verification, Petri nets.

Introduction

There is an increasing acceptance of Service-Oriented Architectures (SOA) as a paradigm for integrating

software applications within and across organisational boundaries. In this paradigm, independently
50
developed and operated applications are exposed as (Web) services that communicate with each other
marted 13 dicembreusing
2011 XML-based standards, most notably SOAP and associated specifications [3]. While the technology

Motivation
BPEL specification:
rigourous XML syntax
English prose semantics (of apparent clarity)
Consequences:
inconsistencies, ambiguities, incompleteness
try to google for WS BPEL issues list, e.g.
Issue 32 Link Semantics in Event Handlers (resolved)
Issue 39 Inconsistent syntax for query attribute values in spec examples (resolved)
...
Issue 42 Need for Formalism (resolved) YES
51
marted 13 dicembre 2011

Approaches
Promela (SPIN)
Process algebras
Abstract State Machines
Automata
Weakest preconditions / strongest postconditions
Axiomatic semantics
Petri nets
52
marted 13 dicembre 2011

Goal
Unveil ambiguities in BPEL specification
(reported to BPEL standardization committee)
Complete formalization of all control-flow constructs
Checking for unreachable activities
Checking for potential conflicting message receipt actions
Determining which messages can be eventually consumed
53
marted 13 dicembre 2011

lting
in ambiguities
and contradictions
inwill
thebe
wording
ofbecause
the BPEL
specification
[5].
Fo
<flow
name="FL"
suppressJoinFailure="yes">
e execution
of
this
process,
either
A1
or
A2
skipped
these
two
activities
are
Flow
<links>
sation
effort,
some
of
these
issues
were
reported
and
discussed
in
the
BPEL
different
of a switch and in any execution of a switch only one branch is
taken.standard
Thus,
<linkbranches
name="x1"/>
<link
name="x2"/>
changes
to the
proposed,
albeit
yetthat
adopt
e and
two</links>
control
links
x1 orspecifications
x2 will carry awording
negative have
token.been
On the
other hand,
we not
assume
Switch
<switch
name="SW">
ondition
attached to activity A3 (denoted by keyword AND) evaluates to true if and only if
.
<case>
shilst
x1 and
x2control
carry
positive
values. Hence,
this joinhave
condition
always evaluate
to
false
and t
Link
<invoke
name="A1">
the
flow constructs
of BPEL
beenwill
designed
inControl
a way
to
ensure
<source
linkName="x1"/>
</sources>
<sources>
A3 is always
skipped
(i.e.
it is unreachable).
5
ess execution
</invoke> can deadlock , some combinations of structured activities (in particular
</case>
with<process
control
links can lead to situations where some activities are unreachable.
Consi
name="unreachableTask"
<otherwise>
FL
targetNamespace="http://samples.otn.com"
<invoke name="A2">
ess definition
in<source
Fig. linkName="x2"/>
1 where both </sources>
the XML code and aLegend:
graphical representation are pr
suppressJoinFailure="yes"
<sources>
xmlns:tns="http://samples.otn.com"
SWbecause
</invoke>
xmlns:services="http://services.otn.com"
execution
of this process, either A1 or A2 will be skipped
these two activi
Basic
Activity
xmlns="http://schemas.xmlsoap.org/ws/2003/03/businessprocess/">
</otherwise>
<flow
name="FL"
suppressJoinFailure="yes">
ifferent
branches
of a switch and in any execution of a switch
c1 onlyc2one branch is taken
</switch>
Flow
<links>
name = "A3">
<link name="x1"/>
two<invoke
control
links x1 or x2 will carry a negative token. On the other hand, we assum
<targets>
<link name="x2"/>
A1
A2
<joinCondition>
</links>
ndition
attached
to
activity
A3
(denoted
by
keyword
AND)
to
true
if
and
Switch evaluates
bpws:getLinkStatus(x1)
and bpws:getLinkStatus(x2)
<switch
name="SW">
x1
<case>
</joinCondition>
x1 and
x2 name="A1">
carry positive values. Hence, this join condition
will
always evaluate to fa
Control
Link
<invoke
<target linkName="x1"/>
AND A3
<source linkName="x1"/>
</sources>
<sources>
is always
skipped
(i.e.
it
is
unreachable).
<target
linkName="x2"/>
</invoke>

Example: BPEL with

unreachable activity

x2
</targets>
</case>
</invoke>
<otherwise>
FL
<process
name="unreachableTask"
<invoke
name="A2">
</flow>
targetNamespace="http://samples.otn.com"
<sources> <source linkName="x2"/> </sources>
</process>
SW
Legend:
</invoke>
suppressJoinFailure="yes"
</otherwise>
xmlns:tns="http://samples.otn.com"
c1
c2
</switch>
xmlns:services="http://services.otn.com"
Basic Activity
<invoke
name
=
"A3">
Fig.
1.
Example
of
a
BPEL
process
with
an
unreachable
activity.
xmlns="http://schemas.xmlsoap.org/ws/2003/03/businessprocess/">
<targets>
<flow
name="FL" suppressJoinFailure="yes">
A1
A2
<joinCondition>
Flow
<links>
bpws:getLinkStatus(x1) and bpws:getLinkStatus(x2)
x1
<link
name="x1"/>
</joinCondition>
ble scopes
are not covered in this paper since they are not a control-flow
construct a
<link
name="x2"/>
<target
linkName="x1"/>
AND
A3
<target linkName="x2"/>
</links>
he <switch
scope
of this work. Instead, serializable scopes are fundamentally
related to data ma
x2 Switch
</targets>
name="SW">
</invoke>
<case>
h it has
not name="A1">
been formally proved that BPEL processes are deadlock-free,
to the best of ou
</flow>
Control
Link
<invoke
54
</process>
<source linkName="x1"/>
</sources>
<sources>
ple
of
a
deadlocking
BPEL
process
has been put forward. Also, Kiepuszewski et al.
marted 13
dicembre
2011
</invoke>

n Fig. 2, hiding the subnet enclosed in the

mapping for activities. This will be used i

Basic activity X
rX

to_skip X Y

sX
"skip"

marted 13 dicembre 2011

X
started

cX
skippedX

ready

55

completed

fX finished

performed multiple times as long

does not hold any more (z).

Sequence A;B
We show the binary version,
but it can be generalized to
an arbitrary number of
activities

rX
sX
rA

<sequence
name="X">
activity A
activity B
</sequence>

fA
rB
B

fB
cX
56
marted 13 dicembre 2011

fX

ormed multiple times as long as the while condition (z)

not hold any more (z).

Flow A|B

rX
X
We show the binary version,
but it can be generalized to
sX
an arbitrary number of
activities
rA

<sequence
name="X">
activity A
activity B
</sequence>

fA

rX
sX

<flow
name="X">
activity A
activity B
</flow>

rB

rA
A

fB

fA

rB

cX

fB
57
marted 13 dicembre 2011

fX
( b ) flow

fX

fX

flow

( c ) switch

While z do A

rX

sX
rB

fB

"~z"
<while name="X">
<condition>
z
</condition>
activity A
</while>

marted 13 dicembre 2011

"z"
rA
A

fA
cX

cX
fX

sX
e2

rX

58

fX

loops. In Fig. 3(e), activity X has a sub-activity A that

hile condition (z) holds and the loop will exit if the conditi

Switch (z1)A,(z2)B

rX
We show theXbinary
version, but it can be <switch name="X">
sX
<case>
generalized
to
<condition>
"z1"
an arbitrary number of
z1
</condition>
activities
rB
rA
>
activity A
rA

rB

B
Y

marted 13 dicembre 2011

59

just decorations
Y
Y fX
b ) flow

sX
"~z1 z2"

fA

X
V

</case>
A
B
In blue:
<case>
<condition>
alternative
flow
fB
fA
z2
to skip activities
</condition>
activity B
(also needed for links)
</case>
cX
</switch>

rX

cX
fX
( c ) switch

fB

fB

fX

Pick (e1)A,(e2)B

( b ) flow

<onMessage e1>
activity A
In blue:
</onMessage>
alternative flow
<onAlarm e2>
to skip activities
activity B
(also needed for links)
</onAlarm>
</pick>

e2

e1
rA

fA

marted 13 dicembre 2011

60

rB

cX

just decorations
Y

sX

We show the binary

fX
version, but it can be
( a ) sequence
generalized to
an arbitrary number of
<pick name="X">
activities

rX

cX

fX

fB

n Fig. 2, hiding the subnet enclosed in the

mapping for activities. This will be used i

Basic activity + skip

rX

to_skip X Y

ready

sX

started

Skip
path

"skip"

Regular
flow

completed

cX

marted 13 dicembre 2011

skippedX

61

fX finished

cking
g post-conditions
pre-conditions
fororactivities.
evaluating
The
post-conditions
skip path is used
for activitie
to facili
and skip
mapping
will be described
of controlinlinks,
Sect. which
3.2. Note
will that
be described
the to skip
in Sect.
3.2
ces
twoare
patterns
respectively
(a letter
decorated
Y and by
its two
upside-down
patterns image)
(a lettersoYthat
andt
2,
behiding
graphically
the subnet
identified.
enclosed
In Fig.
in the
2, hiding
box labeled
the subnet
x yields
enclosed
an absti
ng
phicforrepresentation
activities.
This
of
will
the
mapping
be
used
in
for
the
activities.
rest
of
the
This
paper.
will
be
u
The token arrives

Basic activity + skip

either here...

to_skip X Y

rX

... or here

to_skip X Y

sX
"skip"

"skip"

cX
skippedX
(but not both)

62
marted 13 dicembre 2011

fX

Fig. 2. A basic activity.

sX

cX
skippedX

rX

fX

Fig. 2. A basic activity.

tured activity (X) waits for all its sub-activities (X 1 to Xn ) to be

pped. In Fig. 4(a), when a non-sequence activity is skipped, all its
arallel. Whereas in Fig. 4(b), when a sequence activity is skipped, all
d in the same order as their normal occurrences in the sequence.

Sequence + skip
rX

to_skipX Y

rX
X

sX

sX

"skip"

.
..

X1
X
Skip
f
path
Y

X1

Xn

fX1

rX2
X2

skippingX I
Y

.
..

rXn

X1

rX1

.
..

..
.

.
..

Y
Y

subactivities
X.
marted 13 dicembreof
2011

"skip_fin"
skipped X

fXn
cX

uence

rXn

Xn

cX
fX

fX2

63

fX

Regular
flow

skipped before X itself can be skipped. In Fig. 4(a), when a non

sub-activities will be skipped in parallel. Whereas in Fig. 4(b), wh
its sub-activities need to be skipped in the same order as their no

Non-sequence + skip
rX

to_skipX Y

sX

"skip"
.
..

rX1
X1

skippingX I

Xn

fX1

fXn

Regular
flow

skippin

.
.
.

.
..

"skip_fin"

cX
Y

marted 13 dicembre 2011

rXn

.
..

skipped X

"ski

.
..

Skip
path

to_ski

64

fX

"skip_fi

What about control

links?
Control link are a non-structural element
that introduces control dependencies
An activity can be the source of many links
(it must evaluate the corresponding transition condition)
An activity can be the target of many links
(it must receive their boolean evaluation and
apply the join condition)

65
marted 13 dicembre 2011

Join condition failure

If the attribute suppressJoinFailure is set to no,
a join failure needs to be thrown,
which triggers a standard fault handling procedure
If the attribute suppressJoinFailure is set to yes,
the activity will not be performed,
will end up in the finished state,
(the processing of any following activity will not be affected)
and the status of all outgoing links will be set to false.
This is known as dead path elimination
(the false link status is propagated transitively along the
paths formed by control links, until a join condition is
reached that evaluates to true)
66
marted 13 dicembre 2011

links are non-structural constructs used to express control dependencies between ac

depicts the mapping of control links using an example of a basic activity. The given
specifies that activity X is the source of links X1out to Xnout and the target of links X1in
ntrol link has a link status that may be set to true or false, as represented by place ls
rue) or lsf (link status false).

Basic activity with

control links

..
.

<source linkname=" Xout

n ">
<transitionCondition>
tc out
n
</transitionCondition>
</source>
</sources>
<targets>
<joinCondition>
in )
X ( ls in
,
...
,
ls
1
m
</joinCondition>
<target linkname=" Xin1 ">

..
.

<target
</targets>
</activityX>

rX

in

LX
in

lst 1

lsf 1in

in
lst m

in
lsf m

..
.

jctX

boolean join condition true

net BN X
(mapping
of X )

jcfX

cX

join condition false

suppress join failure is selected

sX

"sjf"

..
.

LX

lst out
1

lsf out
1
transition conditions
(true / false)

tc nout

linkname=" Xinm">

lst out
n

lsf nout
in

[note] lsin
j is the status of control link Xj ,
where j=1, 2, ... , m.
marted 13 dicembre 2011

out

tc 1out

..
.

<activityX suppressJoinFailure="yes">
<sources>
<source linkname="Xout
1 ">
<transitionCondition>
tc out
1
</transitionCondition>
</source>

67

fX

sult will not affect the skipping behaviour of X. In this way,

activity X and the source activity of each of the incoming
the status of each of the outgoing links from X will be set t
ation as a result of skipping the activity.

Skipping a basic activity

with control links
rX

to_skipX Y

.
.
.
join condition false

join condition true

jctX
jcfX

sX

jcvX

in
LX

cX
"skip"

...

...

out
LX

...
...

fX

skippedX

68
marted 13 dicembre 2011

..
.

lsf out
1

link status false

lsf out
n

link status false

choice between the normal behaviour (Fig. 7 (a) and Fig. 8 (a)) and t
(Fig.Fig.
7 (b)
and Fig.
8 (b)),
the environment
a token
in eit
and
8 (b)),
because
thebecause
environment
puts a tokenputs
in either
place
rx

Sequence activity with control links

X1

.
.
.. .
.

cX

..
.
Xn

Lout
X
...
...

fX

..
.

fX2

fX1

fX1

rX2

rX2

I
X2
skipping
X

..
.

rXn

..
.

Xn

fXn
cX
out

...

lsf out
n

...

..
.

lsf out
1

"skip_fin"

rXn

fXn

"skip_fin"

skippedXfX

..
.
Xn

...
...

skippedX

69

..
.

Lout
X

lsf out
n

fX

X2

fX2

cX

Lout
X

lsf 1

( a ) normal behaviour
( a ) normal behaviour
marted 13 dicembre 2011

skippingX I

rX1

X1

..
.

fXn

"sjf_fin"
..
.

rXn

..
.

.
.
.

Xn

fX2

X2

rX1

X1

..
.

rX2

X2 X
to_f

.
.
.

rX2

in

LX

"skip"

..
.

fX1

jcfX

fX1

..
.

in
LX

sX

jcvXsX

..
.

fX2
rXn
fXn
cX

lsf out
1

.
.

"skip"

rX

rX1

X1

fX

n"

rX1

jcfX

jctX

Y
Y

in

LX

"sjf"

.
jcvX.
.

jcfX

jctX

sX

sX

jf"

.
.
.

to_skipXrX

.
.
.

jctX

to_skipX

rX

rX

lsf out
n

fX

( b ) skipping behaviour
( b ) skipping behavio

Fig. 6. Mapping of skipping a basic activity with control links.

.
...

lsf out
n

Non-sequence
activity
with
f control links
r
r
X

skippedX

to_skipX Y

jctX

Fig. 6. Mapping of .. skipping a basic activity with control links.

jcvX

..
.

"sjf_fin"

..
.
.

"skip" ..

fXn

cX

X1

..
.

Xn
lsf out
n

cX

"skip_fin"

( b ) skipping behaviour

Lout
X

..
.

fX

rX1 Lout
X

skippingX I

skippedX

..
.

sX

...

..
.

fX1

..
.

..
.
..
.

.
.
.

Xnout
lsf
1

..
.

( a ) normal behaviour

fX1 . . .

..
.

Xn

f.X.1 .

..
.

.
.
.

X
lsf out
1 n

lsf out
n

cX

...

lsf out
1

...

lsf out
n

..
.

fX

...

jcvX

rXn

..
.

..
.

X1

in
L
"skip_fin" X

rXn

X1

rX

..
.

..
.

to_fX

Lout
XY

rX1

jcfX

rX1

..
.

..
.

..
.

..
.

cX

fin"

sX

..
.

..
.
..
.

fXn

.
.

Lin
X

.
"sjf" ..

skippingX. I

Xn

jcfX

fX1

jctX

to_skipX Y

.
.

X1

rXn

o_fX.

rX1

"skip"

Lin
X

rX

..
.

..
.

jcfX

jctX

sX

sX

"sjf"

..
Fig. 7. A non-sequence structured activity
with control links.
.

( a ) normal behaviour
marted 13 dicembre 2011

skippedX

70

fX

fX
( b ) skipping behaviour

Fig. 8. A sequence activity with control links.

The previous example

Basic Activity
As an example, Figure 9 depicts the mapping of the BPEL process shown in Fig
Flow
r FL

Switch

sFL

Control Link

r SW

"c1"

SW

A2

sA1

A2

A1
cA1

x1
x2

AND

an unreachable activity.

rA2

tcx2

cA2

A3
fA1

lstx2

sA2

A1

c2

c1

rA1

"~c1 c2"
v

FL

sSW

fA2

tc x1

"tt"

lsfx2
lstx1

cSW

rA3

sA3

"tf"

A3
jcfA3

cA3

fA3

fSW

re not a control-flow construct and thus fall

fundamentally related to data manipulation.71
marted
13 dicembre 2011
are
deadlock-free,
to the best of our knowledge

"ff"

"ft"

lsfx1

jctA3

cFL
fFL

Scope
Remind that a scope has a primary activity, and optionally:
a set of fault handlers,
a set of event handlers, and
one compensation handler.
To deal with them, four flags are attached to a scope:
to_continue (no exception, execution is in progress)
to_stop (an error occurred, activities need to stop)
snapshot (successfully completed, uncompensated)
no_snapshot (no compensation needed)
In the following, we just sketch the handling of faults
72
marted 13 dicembre 2011

dler associated
the scope
not included.
exception
occurs.
Scope
pped
(upon thewith
occurrence
ofistransition
skipAssume
fin orthat
sjf no
fin),
the status
indicating
status
of to continue
its snapshot
normal performance
(i.e. the Finally,
execution
of Qs
main
activ
cope snapshot
for Q during
(place no
)
will
be
recorded.
faults
may
occur
du
Q
completion of
of scope
activity
a snapshot
is preserved
scope
Q. to
Next,
consider
case
erformance
Q, A,
causing
the status
of Q to for
change
from
continue
to tothe
stop.
e Q further
(see Fig.in10(a))
or the case of suppressing a join failure for Q (see Fig. 10(b)). On
bed
Sect. 3.5.
been skipped (upon the occurrence of transition skip fin or sjf fin), the status in
rQ
nce of a scope snapshot
for Q (place no snapshotQ ) will be recorded.rQFinally, faults may
Y
Q continue to
normal performance of Qscope Q, causing .the
status
of
Q
to
change
from
to
. jctQ
be described further
.
sQ
sQ in Sect. 3.5.

Scope

"skip"

C to_continueQ

fA

"sjf"

"sjf_fin"
Lin
Q

rA

A
Y

( a ) skipping behaviour

cQ

10.fQ A
!
no_snapshotQFig.
( a ) skipping behaviour

marted 13 dicembre 2011

fQ

cQ

snapshotQ

..

( b ) suppressing join failure

scope
with
its main activity.
snapshot
no_snapshotQ
Q
73

..

fQ

:)

Handlers

no_snapshotQ !

snapshotQ

out

LX
A
C to_
...
lsf out
1
..
fA
. X to_
...
lsf out
n

"sjf_fin"

X to_stopQ

:)

skipped Q

fA

rA

:)

fQ

:)

"skip_fin"
no_snapshotQ !

C to_continueQ

X to_stopQ

..
.

cQ

to_fQ

..
.

skippingQ

Cs to_continueQ

fA
cQ

..
.

jcfQ

X to_stopQ

rQ

rA

.
jctQ
. to_f
. Q

sQ

"sjf"

..
.

rA

Lin
Q

rQ

to_skipQ Y

jcfQ

snapshotQ

( b ) suppressing join failure

Faults
BPEL defines three kinds of faults:
application faults (also service faults)
generated by invoked services
process-defined faults
generated by a <throw> activity
system faults
generated by the process engine, such as join failures
it is never possible to run more than one fault handler for
the same scope, under any circumstances
74
marted 13 dicembre 2011

Some assumptions
It is not shown entirely here, but the scope is encoded in
such a way that when the token is in to_stop
(instead of to_continue)
all active activities in the scope are by-passed:
they will be terminated reaching their finished state
We do not show the case of a fault occurred during the
faulty mode of a scope (it is handled by the parent scope)
Control links are only allowed to leave the boundary of a
fault handler: we do not show dead-path elimination for them
75
marted 13 dicembre 2011

ct a dry run of throwing join failure to scope Q when Q needs to stop. Re

run of throwing join failure to scope Q when Q needs to stop. Recall the m
a join failure fault in Fig. 15, where ejoinf may be triggered only within the n
ailure fault in Fig. 15, where ejoinf may be triggered only within the normal pro
to continue the dry run of activity X which attempts to throw a join failure
nue the dry run of activity X which attempts to throw a join failure during ter
Q, we add transition ignore to the mapping in Fig. 21 (b). This transiti
dd transition ignore to the mapping in Fig. 21 (b). This transition will fire
ccurs at X and X needs to terminate. As a result, the join failure is ignored
X and X needs to terminate. As a result, the join failure is ignored and the d
tinued.

By-pass a basic activity

cfX

n
X

rX

rX

jcfX

"sjf" LinX

to_stopQ

jcfX

"sjf"

LinX

sX

to_stopQ

to_continueQ to_continueQ
C

tc out

jcfX
"ignore"LinX

to_stopQ

"ignore"

sX

sX

"bypass"

out
lst
tc out

lst out

lsf out

lsf out

LX

fX

( a ) suppressJoinFailure
= yes
( a ) suppressJoinFailure
= yes

to_continueQ
C

cX

cX

out

marted 13 dicembre 2011

"bypass"

cX

cX

fX

rX

rX

jct X

jct X

sX

"bypass"

jct X

ct X

ignore join-failure
when to_stop

lst out
tc out

tc out

lsf out
out

out

LX

fX
76

LX

fX

( b ) suppressJoinFailure
= no
( b ) suppressJoinFailure
=

A fault handler (general case)

rQ
Q

efault is only enabled

while A is running
<scope name="Q">
<faultHandlers>
<catch faultName="fault">
activityHF
</catch>
</faultHandlers>

C
to_continue Q

sQ

to_invoke FH

rA

"efault"

invokedFH

activityA
</scope>

fA

rHF
HF

to_stop Q

fHF

cQ
FH

marted 13 dicembre 2011

fQ

:)

77

! no_snapshot Q

snapshot Q

! no_snapshot Q

:)

fQ

snapshot Q

Example: process-defined fault

Fig. 13. A fault handler (general mapping).

rQ

fault due to
throw activity

.
.
.

rA
C

rthrow
to_invokeFH

<activityA>

..
.

sthrow

invokedFH t

..
.

fA

HFt

[note] The above throw activity in A

is directly enclosed in scope Q.

fHFt
FHt

no_snapshot Q

cQ
fQ

:)

78
marted 13 dicembre 2011

cthrow
fthrow

rHFt

throw

<throw faultName="fault"/>
</activityA>
</scope>

sQ

.
.
.

<scope name="Q">
<faultHandlers>
<catch faultName="fault">
activityHF t
</catch>
</faultHandlers>

snapshot Q

Example: system fault

sQ

.
.
.

rA
rX

..
.

to_invokeFH

<activityX suppressJoinFailure="no">
<targets>
<joinCondition>

invokedFH

X
jf

"ejoinf "

..
.

jf

>

jct X
jcfX

sX
X

cX

..
.

</joinCondition>
<target linkname=
</targets>
</activityX>

fault due to
join-failure

<scope name="Q">
<faultHandlers>
<catch faultname="bpws: joinFailure">
activity HF jf
</catch>
</faultHandlers>
<activityA>

rQ

..
.

rHF

jf

fX

</activityA>
</scope>

fHF

.
.
.

HFjf

fA

jf

[note] X is directly enclosed in scope Q.

FH jf

marted 13 dicembre 2011

fQ

:)

79

cQ

Expressiveness...
not in the formal sense
(w.r.t. WF patterns)

80
marted 13 dicembre 2011

Basic Control Flow Patterns

Pattern 1 (Sequence)
Pattern 2 (Parallel Split)
Pattern 3 (Synchronization)
Pattern 4 (Exclusive Choice)
Pattern 5 (Simple Merge)

Advanced Branching and

Synchronization Patterns
Pattern 6 (Multi - choice)
Pattern 7 (Synchronizing Merge)
Pattern 8 (Multi - merge)
Pattern 9 (Discriminator)

Structural Patterns
Pattern 10 (Arbitrary Cycles)

Cancellation Patterns
Pattern 19 (Cancel Activity)

Pattern 11 (Implicit Termination)

Pattern 20 (Cancel Case)

Patterns involving Multiple Instances

State -based Patterns

Pattern 16 (Deferred
Choice)

Pattern 17 (Interleaved
Parallel Routing)
Pattern 18 (Milestone)

Pattern 12 (Multiple Instances Without

Synchronization)
Pattern 13 (Multiple Instances With a Priori
Design Time Knowledge)
Pattern 14 (Multiple Instances With a Priori
Runtime Knowledge)
Pattern 15 (Multiple Instances Without a Priori
Runtime Knowledge)
81

marted 13 dicembre 2011

Fig. 1. Overview of the 20 most relevant patterns.

Pattern-Based Analysis of BPML (and WSCI)

pattern
Sequence
Parallel Split
Synchronization
Exclusive Choice
Simple Merge
Multi Choice
Synchronizing Merge
Multi Merge
Discriminator
Arbitrary Cycles
Implicit Termination
MI without Synchronization
MI with a Priori Design Time Knowledge
MI with a Priori Runtime Knowledge
MI without a Priori Runtime Knowledge
Deferred Choice
Interleaved Parallel Routing
Milestone
Cancel Activity
Cancel Case
Request/Reply
82
One-Way

marted 13 dicembre 2011

24

standard
BPEL XLANG WSFL BPML WSCI
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

+/
+/

+
+
+
+
+
+
+
+
+
+
+
+
+

+
+

+
+
+/

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

Conclusion

83
marted 13 dicembre 2011

Requirements gone bad

84
marted 13 dicembre 2011

Requirements gone bad

84
marted 13 dicembre 2011

Requirements gone bad

84
marted 13 dicembre 2011

Requirements gone bad

84
marted 13 dicembre 2011

Requirements gone bad

84
marted 13 dicembre 2011

Requirements gone bad

84
marted 13 dicembre 2011

Requirements gone bad

84
marted 13 dicembre 2011

Requirements gone bad

84
marted 13 dicembre 2011

Requirements gone bad

84
marted 13 dicembre 2011

Requirements gone bad

84
marted 13 dicembre 2011

Conclusion
We have overviewed the iceberg tip of
business process management
more notation, theory, technology,
tools, methodology, encoding,
validation, verification, research
lie down there,
more or less deep,
below the surface...
...for all of us to explore

85
marted 13 dicembre 2011