Specification errors for interaction models: Implications for the shape of the overall pattern
Pattern based property specification and verification for ...€¦ · In this paper, we present...
Transcript of Pattern based property specification and verification for ...€¦ · In this paper, we present...
Faculty of Information and Communication Technologies Centre for Information Technology Research
Research Program in Component Software and Enterprise Systems (CeCSES)
CeCSES Report: SUT.CeCSES-TR010
Pattern based property specification and verification for service composition Jian Yu, Swinburne University of Technology; Institute of Computing Technology Chinese Academy of Sciences Tan Phan Manh, Swinburne University of Technology Jun Han, Swinburne University of Technology Yan Jin, Swinburne University of Technology Version 0.9 01 June 2006
Pattern based property specification and verification for service composition Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
Abstract
Service composition is becoming the dominant paradigm for developing Web service applications. It is important to ensure that a service composition comply with the requirements for the application. A rigorous compliance checking approach usually needs the requirements being specified in properties specification formalisms like temporal logics, which are difficult for ordinary software practitioners to write. In this paper, we propose a property pattern based specification language PROPOLS and use it to verify BPEL service composition schemas. PROPOLS is easy to understand and use, yet is formally based. It builds on Dwyer et al’s property pattern system and extends it with the logical composition of patterns to accommodate the specification of complex requirements. PROPOLS is encoded in OWL to facilitate the sharing and reuse of domain knowledge. A Finite State Automata based implementation for the verification of BPEL schemas against PROPOLS properties is also discussed.
Pattern based property specification and verification for service composition Page i Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
Table of Contents
1. Introduction _________________________________________________________________ 1
2. An Example Scenario _________________________________________________________ 2
3. Property Specification Patterns _________________________________________________ 2
4. The PROPOLS Language ______________________________________________________ 4
4.1 Language Structure ________________________________________________________ 4
4.2 Composite Patterns ________________________________________________________ 5
4.2 PROPOLS Example ________________________________________________________ 9
5. Verification of BPEL___________________________________________________________ 10
5.1 An Example BPEL Schema __________________________________________________ 11
5.2 Verification Approach _______________________________________________________ 12
6. Related Work ________________________________________________________________ 16
7. Conclusion __________________________________________________________________ 16
Pattern based property specification and verification for service composition Page 1 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
Faculty of Information and Communication Technologies Higher Education Division
Pattern Based Property Specification and Verification for Service Composition
1. Introduction
Web service composition is emerging as a promising technology for the effective integration of
applications across globally distributed organizations [1, 2]. When encapsulating modular business
functions as standard Web services, cross-organizational business processes can be built with a
service composition language like BPEL [3] or BPML [4].
It is important to ensure the behavioral conformance between a service composition application and
the requirements. Unexpected application behaviors may not only lead to mission failure, but also
may bring negative impact on all the participants of this process. Model checking [5] is a formal
approach to software behavioral conformance checking. In this approach, a software application is
abstracted as a formal model like Labeled Transition Systems (LTS), Finite State Automata (FSA),
Petri nets, or process algebra. The behavioral requirements are specified as properties in formalisms
like Linear Temporal Logic (LTS), Computation Tree Logic (CTL), or Quantified Regular Expression
(QRE). Then the formal model can be verified against the specified requirements/properties through
exhaustive state exploration. A serious problem, however, prevents the wide adoption of this
approach. That is, the formal properties are surprisingly difficult to write for practitioners, who usually
don’t have solid mathematical backgrounds [6, 7].
In this paper, we present PROPOLS (Property Specification Pattern Ontology Language for Service
Composition) and an associated approach to the verification of BPEL schemas. PROPOLS is an
OWL-based high-level pattern language for specifying the behavioral properties of service
composition processes. PROPOLS is based on Dwyer et al.’s property patterns [6], which are high-
level abstractions of frequently used temporal logic formulae. The property patterns enable people
who are not experts in temporal logics to read and write formal specifications with ease and then
make model checking tools more accessible to common software practitioners [8]. Although, Dwyer
et al. claimed in [6] that patterns can be nested, no further work has been done on how to define
composite patterns and what are their semantics. PROPOLS refines/extends the original pattern
system in [6, 7] by introducing the logical composition of patterns. This mechanism enables the
definition of complex requirements in terms of property patterns, which is previously impossible.
PROPOLS uses the Web Ontology Language (OWL) as its base language. This makes PROPOLS
properties sharable and reusable.
In addition to the PROPOLS language, we present a verification framework for checking the
compliance of BPEL schemas against a group of PROPOLS properties. The key techniques used
include representing the semantics of PROPOLS properties as FSAs, representing the semantics of
a BPEL schema as LTS/FSA using Foster’s BPEL2LTS tools [9], and checking the language
inclusion between these two FSAs. The verification approach is illustrated using a non-trivial example.
Pattern based property specification and verification for service composition Page 2 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
This paper is structured as follows. In the next section, a motivating example scenario is presented.
Section 3 gives a brief introduction to the original property specification patterns. Section 4 presents
PROPOLS, including its syntax and semantics. Section 5 introduces the BPEL verification framework
and illustrates the verification approach based on the example scenario. Finally, we discuss the
related work in section 6 and conclude the paper in section 7.
2. An Example Scenario
Let’s assume a computer manufacturing company AdvantWise is to provide an online purchasing
service. The key requirements to this service are sketched as follows:
1. Customers can place purchase orders online. Any order should be checked before processing.
For an invalid order, the customer will get a cancellation notification. For a valid one, the
customer will get a confirmation.
2. The transactions between customers and AdvantWise follow a hard credit rule. That is, on the
one hand, the customer pays to AdvantWise only when she has received the ordered products.
On the other hand, AdvantWise processes the order only when it is confirmed that the customer
will pay if the order is fulfilled. For this to be possible, a third party, bank, is introduced. To let
AdvantWise start processing order, the customer must deposit the payment to the bank first.
Then the bank will notify AdvantWise that the payment for the order has been already kept in the
bank. Anytime when the order is canceled, the payment will be refunded by the bank. If the
order is fulfilled, the bank ensures that the payment is transferred to AdvantWise.
3. To fulfill an order, AdvantWise first check its inventory. If there are enough products in the
inventory, the products of the ordered quantity are packaged for shipping. If not, AdvantWise will
initiate an emergency production schedule.
Clearly, the above-stated requirements express certain business constraints that the system
implementation must follow. On the one hand, it’s not easy to translate the embedded behavioral
constraints into temporal logics in a straightforward manner. On the other hand, Dwyler’s patterns are
not expressive enough to state all the constraints, for example, the mutual exclusion between
cancellation notification and confirmation. After introducing PROPOLS in section 4, we will formulate
all these requirements as such properties, against which any of the behavioral constraints can be
decided.
3. Property Specification Patterns
Property specification patterns [6] were first proposed by Dwyer et al. These patterns include a set of
commonly occurring high-level specification abstractions for formalisms like LTL, CTL or QRE.
According to the data from [10], 92% of 555 specifications from different sources matched one of the
patterns. The specification pattern system enables people who are not experts in such formalisms to
read and write formal specifications and then bridges the gap between practitioners and model
checking tools [8].
A pattern specification/property consists of a pattern and a scope. The pattern specifies what must
occur and the scope specifies when the pattern must hold.
Pattern based property specification and verification for service composition Page 3 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
As shown in Fig. 1, Patterns are classified into occurrence patterns and order patterns. We briefly
describe the meaning of some important patterns below (the symbol P or Q represents a given
state/event). Details of these patterns can be found in [11].
Fig. 1. Pattern Hierarchy
Absence: P does not occur within a scope.
Universality: P occurs throughout a scope.
Existence: P must occur within a scope.
Bounded Existence: P must occur at least /exactly/at most k times within a scope.
Precedence: P must always be preceded by Q within a scope.
Response: P must always be followed by Q within a scope.
A scope defines a starting and an ending state/event for a pattern. There are five basic kinds of
scopes:
Globally: the pattern must hold during the complete system execution.
Before: the pattern must hold up to the occurrence of a given P.
After: the pattern must hold after the occurrence of a given P.
Between: the pattern must hold from the occurrence of a given P to the occurrence of a given Q.
Until: the same as "between", but the pattern must hold even if Q never occurs
The semantics of pattern properties may be given in LTL, CTL, QRE, or FSA [12, 13]. Fig. 2
illustrates the FSA semantics by three pattern properties. There, the symbol ‘O’ denotes any other
states/events than P and Q. Fig. 2(a) indicates that before P occurs, an occurrence of Q is not
accepted by the FSA. Fig. 2(b) states that if Q has occurred, an occurrence of P is necessary to drive
the FSA to a final state. Finally, Fig. 2(c) says that only occurrences of P can make the FSA reach a
final state.
Property Patterns
Occurrence Order
Universality
Existence
Bounded Existence Response
Precedence Chain Precedence BPEL
Semantic Mapping
Chain Response
Pattern based property specification and verification for service composition Page 4 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
Fig. 2. FSA Semantics of Example Pattern Properties
4. The PROPOLS Language
In this section, we first illustrate the structure and main components of the PROPOLS language.
Then we explain the syntax and semantics of the composite pattern, which are
refinements/extensions to the original pattern system. A composite pattern is built by connecting
pattern properties using logic operators. The main benefit of the composite pattern mechanism lies in
that it enables the specification of complex requirements. Finally, the PROPOLS properties for the
example scenario are given.
4.1 Language Structure
We designed PROPOLS as an ontology language for two purposes: First, ontology can be used to
define standard terminology for the pattern system. Second, practitioners like business experts can
use concepts from already-existing domain ontology to define pattern properties at a high level of
abstraction. The benefits include: The pattern properties themselves also become part of the shared
formal domain knowledge, so they can be reused in a wide scope, and off-the-shelf semantic Web
techniques can be used to map properties to related Web services automatically. In the present,
OWL is the most widely used Web ontology language. So we choose OWL as the base language of
PROPOLS.
Fig. 3 shows a graphical overview of the PROPOLS ontology. It is generated from Ontoviz [14], an
ontology visualization plug-in for an OWL editor tool Protégé. Its major elements are explained below.
OrderPattern: This class defines the set of order patterns as we discussed in section 2. We use the
name LeadsTo to replace the original Response. Here, P LeadsTo Q has the same semantics as Q
RespondsTo P.
OccurrencePattern: This class defines the set of occurrence patterns as we discussed in section
3.1. Note that BoundedExists is the subclass of Exists, it has additional equalBound, maxBound and
minBound property compared with Exists.
Scope: As discussed in section 2, every elemental pattern has a scope coming from globally, before,
after, between or until.
Pattern based property specification and verification for service composition Page 5 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
Fig. 3. PROPOLS Ontology
Operation: This is the class for service operations. An operation is considered as an event in the
pattern properties. It has a provider property linking to its provider and a conceptReference property
linking to the corresponding concept in some ontology. Later, the conceptReference can be used to
map an event in pattern properties to a Web service operation semantically.
Expression, Unary and Binary: Expression is a general class for patterns and operations. For the
succinctness of the PROPOLS ontology, all the patterns and scopes are the subclasses of Unary or
Binary. So they share the properties defined in Unary or Binary, either has an operand property
pointing to Expression or has a firstOperand property and a secondOperand property. For example,
Exists is a unary pattern and Between is a binary scope. Further restrictions are set for different
kinds of expressions. For example, any of the Scopes only accept operations as its operands.
ConstriantList:. As shown in Fig. 4, This class is a container for pattern properties/constraints.
Fig. 4. ConstraintList Class
4.2 Composite Patterns
As shown in Fig. 5, a composite pattern is the composition of pattern properties using Boolean logic
operators including Not, And, Or, Xor and Imply.
Pattern based property specification and verification for service composition Page 6 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
Fig. 5. Composite Pattern Structure
With composite pattern, complex properties can be stated in a straightforward manner. For example,
if we want to define a property according to “If the order is fulfilled, the bank ensures that the
payment transfers to AdvantWise”. We may write a composite pattern connected with the ‘And’
operator:
Customer.getOrderFulfilled Precedes Bank.transfer Globally
And
Customer.getOrderFulfilled LeadsTo Bank.transfer Globally
(1)
In this situation, both ‘getOrderFulfilled’ and ‘transfer’ should occur and must occur sequentially in
the program. This composite pattern is used frequently, so we add a stereotyped composite pattern:
PLeadsTo, to our pattern system.
Another more complex situation lies in the first requirement of the example scenario. This
requirement claims an ‘exclusive or’ relation between confirmation and cancellation. It also demands
the precedent occurrence of check order activity. Also, we may specify this requirement as a
composite pattern property:
(Customer.getConfirmNotification Exists Globally
Xor Customer.getCancelNotifcation Exists Globally)
And Manufacturer.checkOrder Precedes
Customer.getConfirmNotification Globally
And Manufacturer.checkOrder Precedes
Customer.getCancelNotifcation Globally
(2)
Every elementary pattern property has a corresponding FSA semantics; we define the semantics of
a composite pattern from the logical composition of its component pattern properties’ FSAs. For
example, Fig. 6 shows the resultant FSAs of 4 logical compositions between two properties: “P1
exists globally” and “P2 exists globally”. The states are the Cartesian product of the two property
FSAs’ states. The first number in a state label represents the state of the first property FSA, while the
second represents the state of the second property FSA. The final states of the composite pattern
are determined by the logic composition operator used. For example, the pairing of one final state
Pattern based property specification and verification for service composition Page 7 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
‘And’ one non-final state is a non-final state, and one final state ‘Xor’ one non-final state is a final
state. The final states for different compositions are described in Fig. 6.
Fig. 6. Logical Composition of Two ‘Exists’ Properties
With such definitions, we proved that the language set that can be accepted by a composite FSA is
the composition of the language set of the component elementary FSAs. For example, if we have a
composite pattern ‘pr1 And pr2’, then Language(pr1 And pr2) = Language(pr1) And Language(pr2).
Here, the ‘And’ between two sets Language(pr1) and Language(pr2) is the set for intersection
operator. This theorem proves the correctness of our semantics definition to composite patterns.
Next, we formally define the semantics of the And-composite pattern. The semantics of other
composite patterns can be derived accordingly.
The semantics of composite patterns are defined on deterministic and total FSA:
Definition 1(Total Deterministic FSA): A total Deterministic FSA or TDFA is a tuple (S, s0, L, δ, F)
where
S is a finite set of state,
s0 is the initial state with s0∈S,
L is a finite set of labels,
δ: S×L→S is a total function called the transition function,
F is a set of final states with F⊆S.
Definition 2(accepting run, word, and language): An accepting run of a TDFA (S, s0, L, δ, F) is a
finite run:
(s0, l0, s1)(s1, l1, s2)(s2, l2, s3)…(sn-1, ln−1,sn)
such that ∀0≤ i<n. (si, li, si+1)∈δ, sn∈F;
A word w of a TDFA A is the sequence of labels l0l1l2 … ln-1∈L* of an accepting run (s0, l0, s1)(s1,
l1, s2)(s2, l2, s3)…(sn-1, ln−1,sn) of A, where L* is the set of all finite length sequences of L;
The language L(A) of an TDFA A is the set of words of A:
L(A) = { w | w is word of A}.
Pattern based property specification and verification for service composition Page 8 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
Definition 3(complement): The complement of a TDFA A=(S, s0, L, δ, F) is a TDFA ¬A = (S’, s0’,
L’, δ, F) where
S’ = S, s0’=s0, L’=L, δ’=δ,
F’=S-F.
So the complement of a TDFA is constructed by making all non-final states final and vice versa.
Definition 4(intersection): The intersection of two TDFAs A and B is a TDFA A∧B such that A∧B =
(S, s0, L, δ, F)
where
S is the Cartesian product A.S × B.S,
s0 is the tuple (A.s0, B.s0),
L is the union A.L ∪ B.L,
δ is {((a1, b1), l, (a2, b2)) | (a1,l,a2)∈A.δ ∧ (b1,l,b2)∈b.δ},
F is {(s1, s2) ∈S | s1∈A.F ∧ s2∈B.F}.
Based on Definition 4, the intersection of two TDFAs is constructed by making a Cartesian product of
their states, and only the product of two final states makes a final state in the intersection TDFA.
Accordingly, we also define the union, exclusive or, and imply of two TDFA as the Cartesian product
of their states, the difference lies in the definition of final states:
- Union: F is {(s1, s2) ∈S | s1∈A.F ∨ s2∈B.F}.
- Exclusive Or: F is {(s1, s2) ∈S | s1∈A.F ⊕ s2∈B.F}.
- Imply: F is {(s1, s2) ∈S | s1∉A.F ∨ s2∈B.F}.
Theorem 1: L(A)∩L(B)= L(A∧B).
Proof: Suppose w: l0l1l2…ln-1 is a word of two TDFAs A and B, we can find a accepting run of A
(a0, l0, a1)(a1, l1, a2)…(an-1, ln-1, an) and a accepting run of B (b0, l0, b1)(b1, l1, b2)…(bn-1, ln-1,
bn) where ∀0≤ i<n. (ai,li,ai+1)∈A.δ and∀0≤ i<n. (bi,li,bi+1)∈B.δ, and
an∈A.F and bn∈B.F;
According to Definition 1, ∀0≤ i<n.((ai,bi),li, (ai+1,bi+1))∈(A∩B). δ, and (an,bn)∈(A∧B).F,
So l0l1l2…ln-1 is a word of L(A∧B).
Vice versa, we can get that if l0l1l2…ln-1 is a word of TDFA A∩B, then it is a word of two TDFAs A
and B.
Definition 5: The TDFA semantics of an And-composite pattern ‘pr1 And pr2’ is defined as:
TDFA(pr1 And pr2) = TDFA(pr1) ∧ TDFA(pr2).
Based on Theorem 1, L(TDFA(pr1 And pr2)) = L(TDFA(pr1))∩L(TDFA(pr1)), that means any
execution sequence s1 that is a word of (conforms to) a composite pattern property ‘pr1 And pr2’, is
also a word of pr1 AND a word of pr2.
Accordingly, we have:
- L(TDFA(Not pr1)) = ¬TDFA(pr1);
- L(TDFA(pr1 Or pr2)) = L(TDFA(pr1))∪L(TDFA(pr2));
- L(TDFA(pr1 XOR pr2)) =( L(TDFA(pr1))∩¬L(TDFA(pr2))) ∪(¬L(TDFA(pr1))∩ L(TDFA(pr2)));
Pattern based property specification and verification for service composition Page 9 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
- L(TDFA(pr1 Imply pr2)) = ¬L(TDFA(pr1))∪L(TDFA(pr2)).
4.2 PROPOLS Example
In this subsection, we use PROPOLS to describe the example requirements introduced in section 2.
For easy reading, we first write the pattern properties in a simple text format in Fig. 7.
In Fig. 7, the first property is for requirement 1. The second and third constraints are for requirement
2. The last property is for requirement 3. These pattern properties are quite intuitive and self-
explanatory.
Constraint List: Hard Credit Rule
1. (See property (2) in section 4.2) 2. Customer.getConfirmNotification PLeadsto Bank.deposit globally 3. Bank.depoist PLeadsto Manufacturer.startOrderProcessing globally 4. Customer.getOrderFulfilled PLeadsto Bank.transfer globally
5. Manufacturer.checkInventory Precedes Manufacturer.scheduleProducing globally
Fig. 7. Pattern Properties for the Example Requirements
To showcase the real definition of properties, we present part of the PROPOLS code for the first
property in Fig. 8.
<And rdf:ID="And_Property">
<secondOprand rdf:resource="#Pre_Canc"/>
<firstOprand rdf:resource="#And_inst_1"/>
</And>
<Precedes rdf:ID="Pre_Canc">
<scope><Global rdf:ID="Global_Inst"/></scope>
<firstOprand>
<Operation rdf:ID="checkOrder">
<provider rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI"
>#Manufacturer</provider>
<conceptReference
rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI"
>#CheckOrder</conceptReference>
</Operation>
</firstOprand>
<secondOprand rdf:resource="#getCancelNotifcation"/>
</Precedes>
<And rdf:ID="And_inst_1">
Pattern based property specification and verification for service composition Page 10 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
<firstOprand>
<Xor rdf:ID="Xor_Inst">
<secondOprand>
<Exists rdf:ID="Cancel_Exists">
<scope rdf:resource="#Global_Inst"/>
<operand rdf:resource="#getCancelNotifcation"/>
</Exists>
</secondOprand>
<firstOprand>
<Exists rdf:ID="Confirm_Exists">
<scope rdf:resource="#Global_Inst"/>
<operand rdf:resource="#getConfirmNotification"/>
</Exists>
</firstOprand>
</Xor>
</firstOprand>
<secondOprand>
<Precedes rdf:ID="Pre_Conf">
<secondOprand rdf:resource="#getConfirmNotification"/>
<scope rdf:resource="#Global_Inst"/>
<firstOprand rdf:resource="#checkOrder"/>
</Precedes>
</secondOprand>
</And>
<Operation rdf:ID="getConfirmNotification">
<conceptReference
rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI"
>#ConfirmNotification</conceptReference>
<provider rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI"
>#Customer</provider>
</Operation>
<Operation rdf:ID="getCancelNotifcation">
<conceptReference
rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI"
>#CancelNotification</conceptReference>
<provider rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI"
>#Customer</provider>
</Operation>
Fig. 8. An Example PROPOLS Property Definition
5. Verification of BPEL
In this section, we present an approach to the conformance checking of BPEL schemas against
PROPOLS properties. The presentation starts with a high-level description of a BPEL schema to
Pattern based property specification and verification for service composition Page 11 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
implement AdvantWise’s online purchase process in the aforementioned example scenario, and then
explains the principles and implementation framework using the example BPEL schema. A snapshot
of the verification tool is also presented.
5.1 An Example BPEL Schema
Fig. 9 shows the main structure of the BPEL schema as an implementation of the online purchase
process for AdvantWise. This diagram keeps all the message exchange primitives in the actual BPEL
schema. It uses black boxes to represent the other participants of the process, including the Customer
and the Bank.
<receive>
placeOrder
<invoke>
checkOrder
<invoke>
confirmNotif
<invoke>
cancelNotif
<receive>
depositConfir
mNotif
<invoke>
checkInventory
<invoke>
scheduleProdu
cing
<invoke>
orderFulfilled
Notif
<receive>
paymentTransf
feredNotif
<switch>
<switch>
ManufacturerCustomer Bank
End
Pattern based property specification and verification for service composition Page 12 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
Fig. 9. Example BPEL Schema Main Structure
5.2 Verification Approach
Fig. 10 illustrates our approach to BPEL verification.
Fig. 10. Principle of PROPOLS Verification Approach
Semantic Mapping. First of all, there is a semantic mapping relation between the operations defined in
PROPOLS and Web service operations. The mapping is based on the condition that both of these
operations refer to the same concept in the domain ontology. The PROPOLS operations can tell their
semantics via the conceptReference property. There are two typical ways in which one can add semantic
annotations to Web service operations: by using an external annotation file or directly appending
semantic annotations to the WSDL file. In this context, we use the latter approach. As exemplified in Fig.
11, we extend the Customer Web service’s operation definition with WSDL-S semantic extension element
wssem:modelReference.
<portType name="Customer>
<operation name="confirmNotif"
wssem:modelReference="
http://www.purl.org/onto/operationOnto#GetConfirmNotification>
…
<operation name="cancelNotif"
wssem:modelReference="
http://www.purl.org/onto/operationOnto#GetCancelNotification>
…
Fig. 11. Example Semantic Annotations to Web Service Operations in WSDL
P R O P O L S
P rop erty
S p ecs
B P E L
S ch em a
B P E L 2D F A
C o nv erter
P R O P O L S 2
D F A
C o nv erter
V erifica tion
M an ag er
P a tte rn
L ib rary
F S A
V erifie r
V erifica tio n
R ep o rt
V erifica tio n
F ram ew o rk
Pattern based property specification and verification for service composition Page 13 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
In the above example, the Web service operation confirmNotif and PROPOLS operation
getConfirmNotification refer to the same ontology concept, so we can use confirmNotif to replace
getConfirmNotification in the conformance checking process.
Accordingly, we have the following matching table between the PROPOLS operations and the BPEL
schema related Web service operations.
Tab. 1. Matching Between PROPOLS Operations and Web Service Operations
SBCL Operations Web Service Operations
Manufacturer.checkOrder Manufacturer.checkOrder
Customer.getCancelNotifcation Customer.cancelNotif
Customer.getConfirmNotification Customer.confirmNotif
Bank.deposit Manufacturer.depositConfirmNotif
Manufacturer.startOrderProcessing Manufacturer.checkInventory
Customer.getOrderFulfilled Customer.orderFulfillNotif
Bank.transfer Manufacturer.PaymentTranferedNotif
Manufacturer.checkInventory Manufacturer.checkInventory
Manufacturer.scheduleProducing Manufacturer.scheduleProducing
Verification Process. As shown in Fig. 9, the verification is conducted in 3 steps: (1) For every pattern
property, a semantic equivalent total and deterministic FSA (TDFA) is built. If the property is a composite
one, the corresponding TDFA is constructed by composing the TDFAs of its sub-properties according to
the composition semantics definition in section 4.2. (2) For the BPEL schema a finite and deterministic
LTS model is generated, from which a TDFA is built by introducing the set of final states and an error
state that collect all unacceptable transitions of each state. (3) The conformance of the BPEL schema to
the PROPOLS properties is then checked as a verification problem of whether the accepting event
sequence set of the BPEL TDFA is included in the accepting event sequence set of the property TDFA.
This is done by testing the emptiness of the intersection of the BPEL TDFA and the complement of the
property TDFA.
Following is a a brief explanation to this approach: We check the conformance between a BPEL schema
and a pattern property by checking whether L(TDFA(bpel))⊆L(TDFA(property)) is true. And according to
set theory,
L(TDFA(bpel))⊆L(TDFA(property))⇔ L(TDFA(bpel)) ∩¬ L(TDFA(property))= Φ;
And according to the FSA semantics defined in section 4.2,
L(TDFA(bpel)) ∩¬ L(TDFA(property)) = L(TDFA(bpel) ∧ TDFA(property));
So we have,
L(TDFA(bpel))⊆L(TDFA(property))⇔ L(TDFA(bpel) ∩¬ TDFA(property))= Φ.
Similar technique is also appeared in [15] for Buchi automata based model checking.
Next we illustrate the verification process using property 1 in Fig. 11.
Fig. 12 shows its TDFA where P1 stands for Customer.getConfirmNotification, P2 stands for
Customer.getCancelNotifcation, and S stands for Manufacturer.checkOrder.
Pattern based property specification and verification for service composition Page 14 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
Fig. 12. TDFA of the Example Property
Figure 13 is the LTS of our example BPEL schema, we generate it using Foster’s BPEL2LTS tool [9]]. For
succinctness, we don’t include the inventory checking and product scheduling part of the schema. The
LTS is deterministic for every transition from a specific state is distinctive according to Foster’s approach.
Fig. 13. LTS of the Example BPEL Schema
This BPEL LTS is then converted into a TDFA as shown in Fig. 14. We first mark the end states in the
LTS as final states, then introduce an error state that collect all unacceptable transitions at each state.
Usually, the alphabet of the BPEL FSA would contain a set of non Web services interaction events such
as the assignment of values between messages. Those events are not constrained by the patterns and
therefore, not considered in the checking process. We treated all those non Web services events as
internal events of the BPEL FSA. Based on Foster’s label abstraction method, we identify all Web
services events, thus public events, in the BPEL FSA by considering all the labels prefixing with BPEL’s
web services activities “invoke”, “reply” and “receive”. All other labels would then considered representing
internal (non Web services) events. When composing the BPEL FSA with the Pattern FSA, all transitions
Pattern based property specification and verification for service composition Page 15 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
Fig. 14. TDFA of the Example BPEL Schema
caused by internal events in the BPEL FSA would be mapped to a reflexive transition at every state of the
pattern FSA.
After obtaining the complement of the property TDFA, it is intersected with the BPEL TDFA. It turned out
that the resultant FSA has no final state. This means that the BPEL schema conforms to the example
pattern property. A snapshot of the final result is shown in Fig. 14.
We have implemented a prototype verification tool for BPEL Schema against PROPOLS properties. Fig.
15 is the snapshot of this tool. The left panel contains a list of properties, the logical operators, and the
BPEL schema waiting for verification. While composing a property and a BPEL schema according to the
above-stated approach, the resultant TDFA is shown in the right panel.
Fig. 15: The Verification Framework
Pattern based property specification and verification for service composition Page 16 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
Implementation. We have implemented a prototype verification tool for BPEL Schema against
PROPOLS properties. The architecture are shown in Fig. 16. A BPEL schema is mapped to TDFA via the
“BPEL2DFA Converter” module. “PROPOLS2DFA Converter” maps every PROPOLS property to a TDFA
by referencing to the “Pattern Library”. To every property, the “Verification Manager” will coordinate the
“FSA Verifier” to check the conformance between BPEL schema TDFA and this property. The final result
is a report on which properties are violated, if any.
Fig. 16: The Verification Framework
6. Related Work
Particularly relevant to the work presented in this paper are two streams of work: formal verification of
BPEL schemas and property specification patterns.
A body of work has been reported in the area of formal property specification and verification of BPEL
schemas. The main differences among them lie in the property specification language and the formal
semantic model for BPEL. In [16], Foster relies on Finite State Processes (FSPs) to both semantically
represent a BPEL schema and specify the properties. In [17], Stahl maps BPEL schema into Petri nets
and utilises a verification tool LORA (Low Level Petri net Analyzer) to verify CTL properties. In [18], the
authors maps BPEL into Promela, the input language of the model checker SPIN, and and checks for LTL
properties. The most significant difference between these approaches and our work is that we focus on a
practitioner-oriented approach to property specification. Compared to their heavy-weighted formal
property specification languages, our pattern-based PROPOLS language is easier to understand and use.
Also, its ontology-based nature helps in establishing a natural connection between pattern-based
properties and the domain knowledge.
The property specification patterns are originally proposed by Dwyer et al. in [6]. Since then they have
been applied and extended in many ways. Smith et al. [7] proposed a specification approach which
enables fine-tuning patterns to achieve more precise meanings, based on a combined use of a
“disciplined” natural language and a FSA template language. For example, six different templates were
identified to fine-tune the response pattern. Gruhn et al. [8] extended the patterns with time for describing
real-time related properties. Paun et al. [19] extended the patterns to deal with events in a state-based
formalism. Furthermore, the patterns are the foundation for the extensible specification language in the
Bandera system [20].
7. Conclusion
In this paper, we proposed a verification approach to BPEL schemas, which employs an ontology
language PROPOLS for the property specification. PROPOLS builds on and extends Dwyer et al’s
PROPOLS
Property
Specs
BPEL
Schema
BPEL2DFA
Converter
PROPOLS2
DFA
Converter
Verification
Manager
Pattern
Library
FSA
Verifier
Verification
Report
Verification
Framework
Pattern based property specification and verification for service composition Page 17 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
pattern system. Its pattern-based nature enables software practitioners to write formal behavioral
properties more easily. Its logical composite pattern mechanism allows to state complex requirements. Its
ontological foundation also facilitates their sharing and reuse as part of the domain knowledge.
In the future, we intend to develop a graphical interface for the PROPOLS language. We also intend to
apply the pattern properties to provide guidance in service composition.
Acknowledgments. We would like to thank Dr. Howard Foster of Imperial College London for his help in
translating BPEL schema to Labeled Transition Systems.
References
1. Papazoglou, M.P., Georgakopoulos, D.: Special Issue on Service Oriented Computing. Commun. ACM 46 (10) (2003) 24 –
28
2. Alonso, G., Casati, F., Grigori, Kuno H., Machiraju, V.: Web Services Concepts, Architectures and Applications. Springer-
Verlag (2004)
3. Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F., Liu, K., Roller, D., Smith, D., Thatte, S.,
Trickovic, I., Weerawarana, S.: Business Process Execution Language for Web Services version 1.1
http://www-128.ibm.com/developerworks/library/specification/ws-bpel/ (2003)
4. BPMI: Business Process Modeling Language. http://www.bpmi.org/ (2002)
5. Clarke, E.M., Moon, I., Powers, G.J., Burch, J.R.: Automatic Verification of Sequential Control Systems using Temporal
Logic. American Institute of Chemical Engineers Journal, 38 (1) (1992) 67 – 75
6. Dwyer, M.B., Avrunin, G.S., Corbett, J.C.: Property Specification Patterns for Finite-State Verification. In 2nd Workshop on
Formal Methods in Software Practice (1998) 7 - 15, Clearwater Beach, FL, USA
7. Smith, R. L., Avrunin, G.S., Clarke L. A., Osterweil L. J: PROPEL: An Approach Supporting Property Elucidation. In 24th
International Conference on Software Engineering (2002) 11-21, Orlando, FL, USA
8. Gruhn V. Laue R.: Specification Patterns for Time-Related Properties. In 12th Int. Symposium on Temporal Representation
and Reasoning (2005) 189 - 191, Burlington, Vermont, USA
9. Foster, H.: LTSA WS-Engineering. http://www.doc.ic.ac.uk/ltsa/bpel4ws/ (2006)
10. Dwyer, M.B., Avrunin, G.S., Corbett, J.C.: Patterns in Property Specifications for Finite state Verification. In Int. Conference
on Software Engineering (1999) 411-420, Los Angeles, CA, USA
11. Dwyer, M.B., Avrunin, G.S., Corbett, J.C.: A System of Specification Patterns. http://www.cis.ksu.edu/santos/spec-patterns,
(1997)
12. Jin, Y., Han, J.: Consistency and Interoperability Checking for Component Interaction Rules. In 12th Asia-Pacific Software
Engineering Conference (2005), Taipei, Taiwan
13. Li, Z., Han, J.,Jin, Y.: Pattern-Based Specification and Validation of Web Services Interaction Properties. In 3rd International
Conference on Service Oriented Computing (2005) Amsterdam, Netherland
14. OntoViz Tab: Visualizing Protégé Ontologies
http://protege.stanford.edu/plugins/ontoviz/ontoviz.html (2005)
15. Gribomont, E.P., and Wolper, P.: Temporal Logic. Thayse, A. (Ed.), From Modal Logic to Deductive Databases -
Introducing a Logic Based Approach to Artificial Intelligence. John Wiley & Sons, New York NY, USA, (1989) 165-233
16. Foster, H.: A Rigorous Approach to Engineering Web Services Compositions. PhD thesis, Imperial College London.
http://www.doc.ict.ac.uk/~hf1 (2006)
17. Stahl C.: A Petri Net Semantics for BPEL. Informatik-Berichte 188, Humboldt-Universitat zu Berlin, June 2005 (2005)
18. Fu, X., Bultan T., Su J.: Analysis of Interacting BPEL Web Services. In 13th World Wide Web Conference (2004) 621-630,
New York, NY, USA
19. Paun, D.O., Chechik, M: Events in Linear-Time Properties. In 4th Int. Conference on Requirements Engineering (1999)
Limerick, Ireland
Pattern based property specification and verification for service composition Page 18 Prepared by: Jian Yu, Tan Phan Manh, Jun Han and Yan Jin Thursday, June 01, 2006
20. Corbett, J.C., Dwyer, M.B., Hatcliff, J., Laubach', S., Pasareanu, C.S., Zheng, R., Zheng, H: Bandera: Extracting finite-state
models from Java source code. In 22nd Int. Conference on Software Engineering (2000) 439-448, Limerick, Ireland