On-the-fly construction of provably correct service compositions – templates and proofs

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.1 (1-22)

Science of Computer Programming ••• (••••) •••–•••

Contents lists available at ScienceDirect

Science of Computer Programming www.elsevier.com/locate/scico

On-the-fly construction of provably correct service compositions – templates and proofs ✩ Sven Walther ∗ , Heike Wehrheim Department of Computer Science, Paderborn University, Germany

a r t i c l e

i n f o

Article history: Received 11 February 2015 Received in revised form 1 March 2016 Accepted 5 April 2016 Available online xxxx Keywords: Verification Hoare-calculus Templates Service compositions Correctness by construction

a b s t r a c t Today, service compositions often need to be assembled or changed on-the-fly, which leaves only little time for quality assurance. Moreover, quality assurance is complicated by service providers only giving information on their services in terms of domain specific concepts with only limited semantic meaning. In this paper, we propose a method for constructing service compositions based on preverified templates. Templates, given as workflow descriptions, are typed over a (domainindependent) template ontology defining concepts and predicates. Their meaning is defined by an abstract semantics, leaving the specific meaning of ontology concepts open, however, only up to given ontology rules. Templates are proven correct using a Hoare-style proof calculus, extended by a specific rule for service calls. Construction of service compositions amounts to instantiation of templates with domain-specific services. Correctness of an instantiation can then simply be checked by verifying that the domain ontology (a) adheres to the rules of the template ontology, and (b) fulfills the constraints of the employed template. © 2016 Elsevier B.V. All rights reserved.

1. Introduction Concepts like component-based software engineering (CBSE) or service-oriented architectures (SOA) ease the construction of software by combining off-the-shelf components or services to compositions. Today, such compositions often need to be assembled or changed on-the-fly, thereby imposing strong timing constraints on quality assurance, resulting from the need of fully automated verification and validation systems. “Quality” of service compositions might refer to either nonfunctional properties (like performance [1]), or functional requirements like adherence to protocols (e.g., [2]), to given preand postconditions [3], or to properties specified with temporal logic [4]. Quality assurance methods typically translate the composition (e.g., an architecture model, or a workflow description) into an analysis model, which captures the semantics of the composition. At the best, the quality analysis can be carried out automatically. Both the transformation into the analysis model and the analysis itself are time-costly and thus difficult to apply in onthe-fly composition scenarios. Additionally, depending on the analysis model, automatic analysis it not necessarily possible (e.g., when using theorem provers).

✩ This work was partially supported by the German Research Foundation (DFG) within the Collaborative Research Centre “On-The-Fly Computing” (SFB 901). Corresponding author. E-mail addresses: [email protected] (S. Walther), [email protected] (H. Wehrheim).

*

http://dx.doi.org/10.1016/j.scico.2016.04.002 0167-6423/© 2016 Elsevier B.V. All rights reserved.

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.2 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

2

Fig. 1. Standard scenario: Full analysis for every composition (a). Our approach: Full analysis for templates (b), then check side conditions during instantiation (c).

In this paper, we propose a technique for service composition and analysis based on templates. Templates can capture known compositional patterns, and thus allow for the generally proven principle of pattern usage in software engineering [5]. In this paper, templates are workflow descriptions with service placeholders, which are replaced by concrete services during instantiation. If a template is shown to be correct, then all of its (valid) instantiations will be correct by construction. Every template specification contains pre- and postconditions (with associated meaning “if precondition fulfilled then postcondition guaranteed”), and a correct template provably adheres to this specification. To verify correctness of templates, we provide a Hoare-style proof calculus as a means to prove their correctness. Fig. 1 gives an overview on the motivating scenario. The definition of “correctness” as well as giving a proof calculus for templates, however, poses a non-trivial task on verification. Since templates should be usable in a wide range of contexts and the instantiations of service placeholders are unknown at template design time, we cannot give a fixed semantics to templates. Rather, the template semantics needs to be parameterized in usage context and service instantiation. A template is only correct if it is correct for all (allowed) usage contexts. Similarly, a useful proof calculus has to be applicable in all possible contexts and service instantiations. We guarantee this by defining a proof calculus which is parameterized in usage contexts and template-specific constraints. Technically, we capture the usage contexts by ontologies, and the interpretation of concepts and predicates occurring therein by logical structures. A template ontology defines the concepts and predicates of a template. Furthermore, a template specification contains constraints defining additional conditions on instantiations. These constraints allow us to verify the correctness of the template despite unknown usage and unknown fixed semantics. A template instantiation replaces the template ontology with a homomorphous domain ontology, and the service placeholders with concrete services of this domain. Verification of the instantiation then amounts to checking whether the (instantiated) template constraints are valid within the domain ontology, and thus can be carried out on-the-fly. Section 2 describes ontologies and logical structures. Section 3 continues with the syntax of templates, and Section 4 proceeds with their semantics and correctness. Section 5 presents a proof calculus for templates, Section 6 an approach to utilize SMT solvers for proof automation. Section 7 explains instantiation and presents the central result of our approach: instantiation of correct templates yields correct service compositions, if constraints are respected. Section 8 discusses related work and an empirical approach to the same problem, and Section 9 concludes. This article is an extended version of [6], in addition giving a proof calculus for templates and proving soundness of this calculus with respect to the parameterized semantics of templates, as well as giving a translation to a SAT/SMT problem for automatic correctness checks. 2. Foundations We assume service compositions to be assembled of services which are specified by a signature and pre- and postconditions. Languages to describe signatures with pre- and postconditions are already in use (e.g., OWL-S [3]). Such service descriptions usually rely on domain specific concepts. Services in use in a tourism domain might use concepts like restaurant, hotel and flight while those being employed in a medical domain use concepts like patient, medication and therapy. Ontologies are used to formally specify conceptualizations of domain knowledge [7]; their semantics can for instance be defined by description logics [8]. Ontologies can thus serve as a precise means of specifying our usage context of service compositions. Simple notions of ontologies can be formalized using RDF (Ressource Description Framework, [9]), though typically the Web Ontology Language (OWL, [10,11]) is used. Basically, RDF allows for the specification of triples, relating two concepts with a role, or predicate. OWL is built on top of RDF, and comes with additional constructs for more high-level expressions like, e.g., transitivity of roles. Both RDF and OWL are W3C1 recommendations. There are complex relationships between concepts of an ontology which cannot be expressed by OWL. Therefore, rule languages of different expressivity are a topic of ontological research. A typical rule language is the Semantic Web Rule Language (SWRL, [12]), a W3C submission since 2004. It is built on top of OWL, and adds constructs to create implication-

1

World Wide Web Consortium, http://www.w3.org.

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.3 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

3

style rules.2 In our definition, we restrict ourselves to rules composed of negated and non-negated predicates, as this is a common restriction to keep reasoning in ontologies decidable [13]. For this paper, as ontological research topics are not in focus, we retain a high-level view of ontologies, and focus on concepts, roles, concept inclusions (relating concepts), and rules (formalizing additional knowledge). Complex properties like transitivity (for which there are dedicated constructs in OWL) can also be expressed using rules. However, as it might be confusing to list well-known relational properties as rules, we will loosely follow OWL notation:   Assuming a role (predicate) Pred, we will add functional(Pred) to the set of rules, instead of writing ∀a∃b : Pred(a, b) ∧   ∀a, b, c : Pred(a, b) ∧ Pred(a, c ) ⇒ b = c . If necessary, we use the same shorthand notation for other well-known properties. There is one exception to the handling of special roles: In ontologies, the notion of concept inclusion is an important one, and related to subtyping, e.g., concept SnackBar may be included in the more general concept Restaurant, that is, every snack bar is a restaurant, but not every restaurant is automatically a snack bar (but maybe a takeaway restaurant). Definition 1 (Ontology). Let C be a finite set of concept symbols, and P a finite set of role (or predicate) symbols, where every p ∈ P denotes an n-ary relation on concepts. Let  denote a partially ordered subconcept relation between concepts, that is,  ⊆ C × C . Let R be a set of rules of the form b0 ∧ · · · ∧ bn → h0 ∧ · · · ∧ hm , where b i , h i are (possibly negated) predicates denoting concepts of C , or roles from P . Then K = (C , P , , R ) denotes a rule-enhanced ontology. Please note that partiality of  includes reflexivity, that is, C 1  C 1 for every concept C 1 ∈ C . We will not explicitly list reflexive subtype relations in later examples. We assume every variable in the rules to be implicitly universally quantified, and rules to be consistent, i.e., not to contain contradictions. For details about ontologies and rules, we refer to [13,14]. In classical ontologies, predicates are always binary (e.g., Q : T × T ); however, roles (predicates) relating to boolean types can be used unary (e.g., use Q : T × Bool as Q (t ) instead of Q (t , true)), and n-ary predicates with n > 2 can be translated to binary predicates by introducing supplementary concepts. To avoid technicalities, we allow for a more general notion of predicates here. Ontology examples from the literature and the real world range from the QALLME Tourism ontology [15] (with a few dozens of concepts and roles) to the e-commerce taxonomy of schema.org [16,17], which is used by Google and others. Another popular example is the medical ontology OpenGALEN with tens of thousands of concepts and roles [18]. In the following we define two example ontologies: a short, generic one, and a larger, domain-specific one, which can be seen as a subset of the Tourism domain. Example 1 introduces a quite generic ontology. It will be used later in a “filter” template, which extracts “good” elements from a set using a filter predicate. (We occasionally use subscripts on our example ontologies to distinguish them from each other.) Example 1 (Template ontology). The ontology K T = (C T , P T ,  T , R T ) has two concepts, two predicates, no concept inclusions (subtyping), and no custom rules:

C T = {Elem, Value}, P T = {target : Elem × Bool, filter : Value × Bool},

T = {}, R T = {functional(isTarget), functional(filter )} . The ontology distinguishes two concepts, and both concepts have a relation to the (implicit) Boolean type (see below for implicit types). We use the subscript T as abbreviation for “template”, and refer to it as “template ontology” in later examples. The next example is domain-specific and has its roots in the domain of Tourism. In this paper, we just model selected concepts and roles from the Tourism domain to illustrate our technique of template verification. Example 2 (Domain ontology: tourism domain). The ontology K D = (C D , P D ,  D , R D ) formalizes a small excerpt from a domain of Tourism concepts, which we will use throughout this paper. We will use the subscript D for “domain-specific ontology”. The part formalized in this paper deals with the relation of restaurants, ratings and price values assigned to restaurants, and the predicates relating these concepts. Here, a Snack Bar is a special kind of Restaurant to demonstrate subtyping.

C D = {SnackBar, Restaurant, Rating, Michelin, Price, Location, Distance, Site, Event, Date}

2

We use the Protégé tool from University of Stanford to model ontologies with SWRL rules (http://protege.stanford.edu, Aug. 11, 2015).

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.4 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

4

P D = {hasRating : Restaurant × Rating, isMinRating : Rating × Bool, hasPrice : Restaurant × Price, isMaxPrice : Price × Bool, goodRestaurant : Restaurant × Bool, cheap : Restaurant × Bool, hasLocation : Restaurant × Location, distFrom : Distance × Location, distTo : Distance × Location, distValue : Distance × Integer , hasEvent : Site × Event, startsAt : Event × Date}

 D = {(Restaurant, Site), (SnackBar, Restaurant), (Michelin, Rating)} R D = {hasRating (res, rat) ∧ isMinRating(rat) ⇒ goodRestaurant(res), hasRating (res, rat) ∧ ¬isMinRating(rat) ⇒ ¬goodRestaurant(res), hasPrice(res, price) ∧ isMaxPrice(price) ⇒ cheap(res), hasPrice(res, price) ∧ ¬isMaxPrice(price) ⇒ ¬cheap(res), functional(hasRating), functional(hasPrice), functional(isMinRating ), functional(isMaxPrice), functional(goodRestaurant), functional(cheap), functional(hasLocation), functional(starts At ), functional(distFrom), functional(distTo), functional(distValue)} Signatures and pre- and postconditions of service descriptions are specified using concepts and roles, viz. predicates, of ontologies. Together with standard types like integers, these make up the set of types of an ontology. Ontology languages may already include standard types for easier use, e.g., OWL includes XSD types as standard concepts. We also assume the commonly used types Bool and Integer as part of the ontology’s concepts. Definition 2 (Types). The set T K of types over an ontology K = (C , P , , R ), including Bool ∈ C , Integer ∈ C , is inductively defined as follows:

• c∈C →c∈T , • T ∈ T → set T ∈ T . In the context of types, we address the concept inclusion relation  as subtype relation. Types are used to specify the types of inputs and outputs of services; the predicates can occur in pre- and postconditions. For standard types (Integer, Bool) and set types we need common relations and operations. It is possible to define relations (e.g., =, <) as predicates of an ontology; just as we implicitly include Integer and Bool in C K , we assume all their relations to be included in P K . Additionally, we define P K with P K ⊂ P K to include all relations on set types. While it is possible to define relations (e.g., =, <) as predicates of an ontology, this is not the case for operations or functions like arithmetic or set operations (+, ∪, . . . ). Therefore, we additionally define F K to contain all functions of standard types and sets. From P K and F K , we construct first-order logic formulae in the usual way. To only get type-correct formulae, we assume a set of typed variables Var, i.e., given an ontology K we assume a typing function type : Var → T K . Note that the set of terms over different ontologies might only use different variables, but always use the same (standard) function symbols; also constants like true or 1 are nullary function symbols. Using typed terms, we define the set of first-order logic formulae over K . Definition 3 (First order formulae). Let K be an ontology with types T K , predicate symbols P K , and function symbols F K . The set of first order formulae over K ,  K , is inductively defined as follows:

• if p ∈ P K is a predicate symbol of arity n and type T 1 × . . . × T n → Bool and e 1 , . . . en are terms of type T 1 , . . . , T n , respectively, then p (e 1 , . . . , en ) ∈  K , • if F 1 , F 2 ∈  K , then ¬ F 1 ∈  K , F 1 ∨ F 2 ∈  K , F 1 ∧ F 2 ∈  K and F 1 ⇒ F 2 ∈  K , • if F ∈  K , then ∀x : F ∈  K and ∃x : F ∈  K .

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.5 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

5

As usual, we write free( F ) to denote the free and bound( F ) for the bound variables of a formula F . For example, for F := ∀x : (x > z ∨ x < 10) we have free( F ) = { z} and bound( F ) = {x}. The meaning of first-order logic is usually defined with respect to a logical structure. A logical structure defines the universe out of which elements of the types are taken as well as an interpretation of the predicate and function symbols. Definition 4 (Logical structure). Let K be an ontology with derived types T K , predicate symbols P K , and function symbols F K . A logical structure over K , SK = (U , I ), consists of

 • U = T ∈T K U T the universe of values with – U T 1 ⊆ U T 2 for T 1 , T 2 ∈ T K , T 1  T 2 , – U T 1 ∩ U T 2 = ∅ if T 1 , T 2 ∈ T K , T 1  T 2 ∧ T 2  T 1 , and • I an interpretation of the predicate and function symbols, i.e., for every p ∈ P K of type T 1 × . . . × T K → Bool and every f ∈ F K of type T 1 × . . . × T K → T we have a predicate I ( p ) : U T 1 × . . . × U T k → UBool and a function I ( f ) : U T 1 × . . . × U T k → U T , respectively. We assume standard domains and interpretations for integers, sets, and Booleans, e.g., UBool = {true, false}. Hence all logical structures of an ontology agree on standard types and their operations, but may differ on domain specific parts. To assign a semantics to formulae with free variables, in addition a valuation of variables needs to be given. We let σ : V → U be a valuation of V ⊆ Var with (type-correct) values from U . We write σ |=S F for a structure S and a formula F if S together with σ is a model for F (viz. F holds true in S under σ ); refer to, e.g., [19] for a formal definition. If the formula contains no free variables, we can elide σ and just write |=S F , or S |= F . We write σ [x := y ] to describe the valuation σ  which agrees with σ on all variables except x whose valuation is σ ( y ). We use a similar operator on formulae: F [x := y ] is the formula in which every free occurrence of x is replaced by y. Note that an ontology usually does not define a logical structure because it neither gives a universe nor an interpretation for its predicates. It does, however, define constraints on valid interpretations by the rules R. Definition 5. A logical structure S over an ontology K = (C , P , , R ) satisfies the rules R of the ontology, S |= R, if it satisfies every rule in R, i.e., ∀r ∈ R : S |= r. Note that all variables in rules are implicitly all-quantified, and therefore no valuation σ is needed here. Additionally, from Definition 4 it follows that rules which contain a predicate P 1 : T × T also apply to P 1 : T  × T  for T   T . 3. Services and templates The ontology and logical formulae over the ontology are basic building blocks for services and compositions. A service in our notation is an entity which generates outputs for given inputs. The signature defines the types of inputs and outputs. For easier reading, we assume in the following that services have just single inputs and outputs. A generalization to arbitrary numbers of inputs and outputs is straightforward. Definition 6. A service signature (Svc, T i , T o ) over an ontology K specifies the name Svc of the service as well as the type of its input T i and the type of its output T o , where both T i and T o are in T K . Additionally, a service is specified by its pre- and postcondition (also: effect). Both of these are given as first-order logic formulae. They are formulated over the input and output variable. Definition 7 (Service description). A service description (sig, i , o, preSvc , postSvc ) of a service named Svc over an ontology K consists of a service signature sig = (Svc, T i , T o ), an input variable i and an output variable o, a precondition preSvc and a postcondition postSvc , both elements of  K . Variables are typed according to the signature sig of Svc, that is, the type of i is T i and the type of o is T o . The precondition only describes inputs, the postcondition inputs and outputs: free(preSvc ) ⊆ {i } and free(postSvc ) ⊆ {i , o}. The following example defines a rating acquisition service for restaurants, which we will use again later in this paper. Example 3 (Service: Get Rating). Assume a service in our excerpt of the Tourism domain (Example 2). Its name is GetRating, and for a given restaurant it produces an associated rating value (by the hasRating predicate). According to the properties of hasRating (it is functional), there is always exactly one rating value associated with a restaurant. The service signature is

Sig = (GetRating, Restaurant, Rating) , and the service description is

(Sig, restaurant, rating , true, hasRating(restaurant, rating)) .

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.6 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

6

Table 1 Example service descriptions for the Tourism domain (Ex. 2). Service

Inputs

Output

Pre.

Post.

GetRating

Restaurant r

Rating t

true

hasRating(r, t)

GetStars

Restaurant r

Michelin m

true

hasRating(r, m)

GetPrice

Restaurant r

Price p

true

hasPrice(r, p)

GetFakedPrice

SnackBar r

Price p

true

isMaxPrice(p)

GetRestaurants

Location l, Distance d

set Restaurant s

true

∀Restaurantr ∈ s: ∃Locationl : ∃Distanced : ∃Integerv , v  : hasLocation(r , l ) ∧ distFrom(d , l) ∧ distTo(d , l ) ∧ distValue(d , v  ) ∧ distValue(d, v ) ∧ v ≤ v

GetEventsForSite

Site s

set Event e

true

GetEventsForDate

Date d

set Event e

true

∀Evente ∈ e: hasEvent(s, e  ) ∀Evente ∈ e: startsAt(e  , d)

The set of service descriptions over an ontology K is denoted SVC K . In a concrete service market, service descriptions would be published in a central or distributed repository to make them available for searching and matching processes. A service market can be realized in different ways, from classical registries in the Remote Procedure Call architecture over current cloud-based services like Amazon Web Services [20] to On-The-Fly markets [21]. While it is generally possible to use existing services and create runnable service compositions (e.g., [22]), our analysis is based on service descriptions only and therefore relies solely on service models, not actual executable services. Table 1 gives some example services based on the Tourism domain ontology from Example 2. Services are composed using a workflow describing the order of execution of the services. Workflows comprise control flow (using control structures) and data flow (using variables) between services. While different notations are in practical use (e.g., WS-BPEL [23], Service Effect Specifications [1,24]), we use a simple programming language style notation here. Definition 8 (Workflow). Let K be an ontology. The syntax of a workflow W over K is given by the following rules:

W ::= Skip | u := t | W 1 ; W 2 | u := Svc( v )

| if B then W 1 else W 2 fi | while B do W od | foreach a ∈ A do W od with variables u , v , a, A; expression t of type type(u ); A of type set T ; a of type T ∈ T K ; B ∈  K ; and Svc a service name. We let change( W ) denote the set of variables changed by a workflow, i.e., assigned to, and vars( W ) to be the set of variables used. In a foreach statement foreach a ∈ A do W od we require a ∈ / change( W ) and A ∈ / change( W ). We use E to stand for the empty workflow and define ( E ; W ) = ( W ; E ) = W (parentheses for clarification). Workflows are built over arbitrary sets of services, which, however, all need to be defined over the same ontology. For template workflows, we do not use concrete services but service placeholders. Formally, a service placeholder has a signature like a service (with an input i of type T i and an output o of type T o ), but instead of concrete formulae for presp sp and postconditions we just write preSvc and postSvc , with Svc as the name and sp indicating that we refer to a placeholder sp (and not a real service). We write SP K to denote the set of service placeholders over K and  K to denote the set of sp sp first-order logic formulae build over K and all placeholder pre- and postconditions preSvc and postSvc . We require that input variables are not modified in a workflow W , that is, no input variable is in change( W ).3 Example 4. We use the ontology K T from Example 1 to model a template which is able to filter a set of elements by a certain criterion. In Fig. 2 we present the template in a more readable fashion by labeling the different elements of the formal definition of template descriptions.

3 While this may be counter-intuitive, it helps by defining the semantics later in this chapter. If manipulation of input variables is necessary, it can easily be modeled by assigning them to a fresh variable, as Z in Fig. 2.

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.7 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–••• Name : Inputs : Outputs : Services : Precondition : Postcondition: Constraints :

7

Filter A with type( A ) = set Elem B with type( B ) = set Elem Get : Elem → Value sp {∀a ∈ A : preGet (a)} { B = {b ∈ A | target(b)}} sp { ∀x, y : postGet (x, y ) ∧ filter ( y ) ⇒ target(x), sp

∀x, y : postGet (x, y ) ∧ ¬filter( y ) ⇒ ¬target(x)}

1 Z := A; 2 B := ∅ ; 3 foreach z ∈ Z do 4 y := Get( z) ; 5 if filter( y ) then 6 B := B ∪ { z} 7 else 8 Skip 9 fi 10 od

Fig. 2. Template to filter a list, using a filter filter and a validation service Get.

The template accepts one input and produces one output, both of a set type with element type Elem. It uses one service placeholder, Get, and the predicates filter and target from Example 1. Its workflow initializes the output variable B, and then iterates over the input set A. Every element is given to the service placeholder Get, and then filtered by applying filter to the result of the service call. If filtering succeeds, then the element is put in the output set B. The constraints define the necessary relationship between the postcondition of the service placeholder Get, the filter predicate filter, and the predicate target, which defines the actually “interesting” elements of the input set. Like services, templates have pre- and postconditions: they define the correctness properties which we intend to achieve with the template, and allow us to treat instantiated templates as any other service. The last part we find in a template are constraint rules, or constraints for short. They define conditions on instantiations: if a template instantiation cannot guarantee these constraints, the postcondition of the template might not be achieved, i.e., the template concretization might not be correct. We will make this more precise in Section 7. Definition 9 (Workflow template). A workflow template

WT = ( N , I , O , SP K , pre, post, CR, W ) over an ontology K consists of

• • • • • •

a a a a a a

name N, list of typed input variables I and typed output variables O , set of services placeholders SP K ⊆ SP K , sp sp precondition pre ∈  K and a postcondition post ∈  K , set of constraint rules CR of the same form as ontology rules (Definition 1), and workflow description W .

Later, we see how templates get instantiated. To this end, we need concrete, existing services described by a domain ontology, to replace the service placeholders. However, our ultimate aim is to show correctness on the level of templates, and inherit their correctness onto instantiations. Thus, we will first define the semantics of templates, and afterwards their correctness. 4. Semantics of templates The key principle of our approach is to take correct templates, instantiate them, and afterwards be able to check correctness of instances by checking simple side-conditions. With “simple” we mean side-conditions which are effectively (or even efficiently) checkable. We ultimately aim at an on-the-fly instantiation of templates, and for this we need fast automatic checks of side-conditions. We start with the meaning of “correctness of templates”. Fig. 2 shows a template with pre- and postconditions and constraints. Basically, these state the property which the template should guarantee: if the precondition holds and the constraints are fulfilled, then the postcondition is achieved. All these parts contain undefined symbols: neither do we know the pre- and postconditions of the employed services (they are placeholders) nor the meaning of the predicates of the template ontology. The definition of a semantics of templates and their correctness therefore necessarily has to be abstract, i.e., defined modulo a concrete meaning. This meaning can only be defined once we have a logical structure. This is, however,

JID:SCICO AID:2000 /FLA

8

[m3G; v1.175; Prn:22/04/2016; 13:12] P.8 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

not given by an ontology; thus the logical structure is a parameter for our semantics. The second parameter to the semantics is the concretization of service placeholders with actual services, given by a mapping π : SP K → SVC K . Definition 10 (Concretization). Let K be an ontology, SP K a set of service placeholders over K , and SVC K be a set of service descriptions over K . Then π : SP K → SVC K is a concretization of service placeholders in K , if it respects signatures, i.e.

if π (sp) = svc and sp : T i → T o , then svc : T i → T o with T i  T i and T o  T o . We lift the definition of π to replace pre- and postconditions of service placeholders with their counterparts of the corresponding service, such that π (presp ) ∈  K with free(π (presp )) ⊆ {i }, and π (postsp ) ∈  K with free(π (postsp )) ⊆ {i , o}. We use π to replace placeholders in any formula, i.e., for a formula F , π ( F ) is F with all occurrences of presp replaced by π (presp ) and postsp replaced by π (postsp ). We define an operational semantics for workflows, much alike [19], however, always parameterized with a structure S and a concretization π . The semantics is defined by a transition relation between configurations. A configuration consists of a workflow to be executed and a state. Definition 11. Let S = (U , I ) be a structure of an ontology K , and Var a set of variables. A state σ over S is a type-correct mapping from Var to U . The set of all states over S is denoted S . For a formula F ∈  K we define the set of states satisfying F with respect to a structure S as J F KS = {σ ∈ S | σ |=S F }. A configuration  W , τ  consists of a workflow W over K and a state τ ∈  S . Later, the semantics of workflows J · K will map initial to final configurations. For this, we first define transitions between configurations by means of the set of axioms and rules given in Fig. 2, i.e., we define a structural (small-step) operational semantics (SOS). The main deviation from the standard semantics given in [19] is that we take two parameters into account: evaluation of conditions is parameterized in the interpretation of predicates as given in the structure S , and influenced by the concretization of placeholders, π . We also add rules for the foreach statement and for service calls. Note that both introduce nondeterminism into the transition system: foreach iterates over the set of elements in an arbitrary order, and service calls can have more than one successor state. For the semantics of the foreach statement we furthermore introduce an additional program statement called take. The statement take(a, A ) takes an arbitrary element from the set A, assigns it to a and removes it from A. Note that the variable A iterated over will be empty (more precisely, σ ( A ) = ∅) upon termination of the foreach statement. Note also for the sequential composition that – following [19] – E stands for an empty program and we let E ; W ≡ W ≡ W ; E. Consider, e.g., the transition rules for the then- and else-parts of Conditionals in Table 2: if a conditional statement is to be executed in state σ , then W 1 is selected as the next statement if and only if the condition B is true in the given structure S (with placeholders replaced); otherwise, W 2 is the next statement. In both cases, the state remains the same, as these rules only deal with the selection of the next workflow statement. The transition rules are used to derive the semantics of workflows. In this paper, we only define a partial correctness semantics, i.e., we do not specifically care about termination. If the workflow does not terminate or blocks (because a service is called outside its precondition), then the partial correctness semantics will not record this. Transitions lead to transition sequences, where a non-extensible transition sequence of a workflow W starting in σ is a computation of W . If it is finite and ends in  E , τ , then it terminates. We use the transitive, reflexive closure →∗ of → to describe the effect of finite transition sequences. The semantics of partial correctness is again parameterized with a logical structure and a concretization mapping for service placeholders. Definition 12 (Semantics of partial correctness). Let S be a logical structure and π a concretization mapping. The partial correctness semantics of a workflow W with respect to S and π maps an initial state to a set of possible final states S π∗ J W Kπ , with J W Kπ S : S → 2 S (σ ) = {τ |  W , σ →S  E , τ } .

We define a workflow template to be correct, if all computations starting in a state which satisfies the precondition, end in a state which fulfills the postcondition. Since services are only placeholders, correctness can only be stated when the template works correctly for arbitrary concretizations, as long as they obey the concretized constraints of the template. So far, we only operate on the template ontology, and thus arbitrary concretization means inserting arbitrary formulae for preand postconditions of placeholders. Therefore, our concretization mapping π : SP K → SVC K maps placeholders to arbitrary service descriptions over K .

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.9 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

9

Table 2 Transition axioms and rules for workflows.

skip, σ 

Skip

u := t , σ 

Assignment

take(a, A ), σ 

Take if and

→π S E, σ  →π S  E , σ [u := σ (t )]  →π S E, σ  σ  (a) ∈ σ ( A ), σ  ( A ) = σ ( A ) \ {σ  (a)}, σ (x) = σ  (x) for x = A , x = a

 W 1 , σ  →π S W 2 , τ 

Sequential comp.

 W 1 ; W , σ  →π S W 2 ; W , τ 

Cond. (then) if

if B then W 1 else W 2 fi, σ  →π S W 1 , σ  σ |=S B

Cond. (else) if

if B then W 1 else W 2 fi, σ  →π S W 2 , σ  σ |=S ¬ B

While (loop) if

while B do W od, σ 

While (end) if

while B do W od, σ 

Foreach (loop) if Foreach (end) if Service call if

→π S  W ; while B do W od, σ 

σ |=S B

→π S E, σ  σ |=S ¬ B

foreach a ∈ A do W od, σ  →π S take (a, A ); W ; foreach a ∈ A do W od, σ  σ |=S A = ∅ foreach a ∈ A do W od, σ   u := Svc( v ), σ  →π S E, σ 

and

→π S E, σ  σ |=S A = ∅

σ |=S π ( pre sp S vc [i := v ]), σ  |=S π ( post sp S vc [i := v , o := u ]), ∀x = u : σ  (x) = σ (x)

Definition 13 (Correctness). Let WT = ( N , I , O , S P K , pre, post, CR, W ) be a workflow template, and K = (C K , P K , R K ) the corresponding ontology. We say WT is correct if the following holds: ∀ logical structures S over K , ∀ concretizations π : SP K → SVC K s.t. S |= R K ∧ S |= π (CR):

J W Kπ S (J π (pre) KS ) ⊆ J π (post ) KS . When the workflow template W T is correct, we also write |= {pre} W T {post}. 5. A proof calculus for workflow templates Our objective is to prove correctness of workflows already on the level of templates and then inherit correctness to all (valid) instantiations. The correctness proof proceeds via the application of a number of axioms and proof rules of a proof calculus. The proof calculus closely follows Hoare-style proof calculi for imperative programs [19,25]. The proof calculus provides us with a way of proving correctness of workflow templates, i.e., provides reasoning techniques for showing |= { p } W T {q} where p and q will be the pre- and postcondition of a workflow template, respectively. Alike standard approaches, the correctness proofs of loops (while and foreach) require the construction of loop invariants. We write  { p } W T {q} (using invariants Inv) if we can derive { p } W T {q} via our proof calculus (when using Inv for the proof rules of loops). The proof calculus deviates from standard Hoare-style proof calculi in two ways: (a) it has extra rules for service calls and foreach statements, and (b) it has to reason about unknown concretizations of services and about predicates with unknown interpretation. As in the correctness definition of workflow templates (correct if sound for all structures and all concretizations), we aim at a proof calculus with rules which are valid for whatever kind of concretization and interpretation we will choose at the end. In the proof calculus this will manifest in the rule of consequence (rule 9 in Fig. 3) which uses implication between predicates. Here, we usually allow for all valid implications (like  p ⇒ ( p ∨ q) or x > 1 ⇒ x > 0). Our ontology and the workflow template, however, already declare some additional formulae which can be considered universally valid when reasoning about this specific workflow template and ontology, namely the rules of the ontology and the constraints of the workflow template. Thus for our example workflow template of Fig. 2 we for instance have a universally sp valid formula postGet ∧ filter( y ) ⇒ target(x). Definition 14. Let K be an ontology with rule set R K , CR a set of constraint rules of a workflow template and p , q be sp formulae from  K (including pre- and postconditions of service placeholders).

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.10 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

10 (1)

Skip

(3)

Service Call

(4)

Take

(5)

Sequential composition

(6)

Conditional

(7)

While

(8)

Foreach

(9)

Consequence

(2)

{ p } Skip { p }

Assignment

{ p [u := t ]} u := t { p }

{preSvc [i := v ] ∧ ∀ w s.t. postSvc [i := v , o := w ] : q[u := w ]} u := S vc ( v ) {q}

{ A = ∅ ∧ ∀b ∈ A : q[a := b, A := A \ {b}]} take(a, A ) {q} { p } W 1 {r }, {r } W 2 {q} { p } W 1 ; W 2 {q}

{ p ∧ B } W 1 {q}, { p ∧ ¬ B } W 2 {q} { p } if B then W 1 else W 2 fi {q}

{ p ∧ B } W { p} { p } while B do W od { p ∧ ¬ B } { p ∧ A = ∅} take(a, A ); W { p } { p } foreach a ∈ A do W od { p ∧ A = ∅} CR |=CR K ( p ⇒ r ), {r } W {s}, |= K (s ⇒ q ) { p } W {q}

Fig. 3. Proof rules for workflow templates over K with constraints C .

We say that p ⇒ q is universally valid wrt. K and CR, |=CR K p ⇒ q, if the following holds: ∀ logical structures S over K , ∀ concretizations π : SP K → SVC K such that S |= R K ∧ S |= π (CR):

S |= (π ( p ) ⇒ π (q)) . Note that we again assume standard interpretation of integers, sets, booleans, and their operations here. Fig. 3 shows the axioms and rules of our proof calculus. They follow standard proof rules for imperative programs, except for the three difference discussed above: the rules of consequence, foreach and service calls. The rule of consequence employs the definition of universal validity of implications, i.e., it includes the rules of the ontology and the constraints of the workflow template into reasoning. The foreach rule (rule 8) is a variant of a loop rule. For the premise of the rule, we need to incorporate the take statement into the proof since this implicitly happens first in all executions of the loop body. The axioms for the take statement and the service call have – like the assignment statement – their weakest precondition as the left-hand-side predicate. Note that – although we work with partial correctness here – we did not use the weakest liberal precondition. Thus these two axioms are also sound when we move to a semantics of total correctness. We use the standard technique of proof outlines [26] to depict proofs: we write intermediate assertions used in proofs directly into the programs, viz. workflows. A proof outline visualizes the assertions appearing in the proof tree of a correctness proof of a complete workflow within the workflow. Proof outlines need not incorporate all these assertions; e.g., so-called standard proof outlines only include one assertion per program statement. We do not use standard proof outlines here; instead also include intermediate assertions produced by the rule of consequence as proof trees would have. In the proof outlines, we tag loop invariants with the keyword inv. Furthermore, we explicitly add the take statement into the proof outlines of foreach loops as to make the assertion after take visible. Fig. 4 shows the proof outline for proving correctness of the workflow template of Fig. 2. Our first result now states that the proof calculus can actually be used to show correctness of workflow templates. Theorem 1 (Soundness). Let WT = ( N , I , O , S P K , pre, post, CR, W ) be a workflow template, and K = (C , P , , R ) the corresponding ontology. Then

 {pre} W T {post} implies |= {pre} W T {post} (Provability in the proof calculus implies validity in the semantics). Note that both the notion of provability and of correctness are parameterized by the ontology and the constraint of the workflow template (though these do not appear in the notation). The proof of soundness of our calculus closely follows other soundness proofs for Hoare-style proof calculi, e.g., in [19]. In general, soundness proofs proceed by induction on the applied rules; i.e., proves all axioms to be true in the semantics plus show for all proof rules that the correctness of the premises imply the correctness of the conclusion. The main deviation between our and Apt et al.’s proof calculus lays in the rules for service call, take and the foreach statement and in the modified rule of consequence. Thus we will only treat these here. Proof of Theorem 1. For the proof, we often omit quantification over all logical structure S and concretizations π satisfying the ontology rules and the constraints of the workflow template (as used in the definitions of correctness and universal validity) as they just need to be written along and never change.

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.11 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

11

sp

1 {∀ z ∈ A : preGet ( z)}



sp





sp



2 { A ⊆ A ∧ ∀u ∈ A : preGet (u ) ∧ ∅ = {b ∈ A \ A | target (b)}} 3 Z := A; 4 { Z ⊆ A ∧ ∀u ∈ Z : preGet (u ) ∧ ∅ = {b ∈ A \ Z | target (b)}} 5 B := ∅;



sp



6 {inv : Z ⊆ A ∧ ∀u ∈ Z : preGet (u ) ∧ B = {b ∈ A \ Z | target (b)}} 7 foreach z ∈ Z do 8 { Z = ∅ ∧ inv} 9 10 11 12 13 14 15 16 17 18

      sp sp { Z = ∅ ∧ ∀x ∈ Z : preGet (x) ∧ x ∈ A ∧ ∀u ∈ Z : preGet (u ) ∧ ( Z \ {x}) ⊆ A ∧ B ∪ {x} = {b ∈ A \ ( Z \ {x}) ∪ {x} | target(b)} ∪ {x} } take( z, Z );

  sp sp {preGet ( z) ∧ z ∈ A ∧ ∀u ∈ Z : preGet (u ) ∧ Z ⊆ A ∧ B ∪ { z} = {b ∈ A \ ( Z ∪ { z}) | target(b)}} y := V ( z);   sp sp {postGet ( z, y ) ∧ z ∈ A ∧ ∀u ∈ Z : preGet (u ) ∧ Z ⊆ A ∧ B ∪ { z} = {b ∈ A \ ( Z ∪ { z}) | target(b)} ∪ { z} if filter( y ) then   sp {target( z) ∧ z ∈ A ∧ ∀u ∈ Z : preGet (u ) ∧ Z ⊆ A ∧ B ∪ { z} = {b ∈ A \ ( Z ∪ { z}) | target(b)} ∪ { z}} B := B ∪ { z}   sp {target( z) ∧ z ∈ A ∧ ∀u ∈ Z : preGet (u ) ∧ Z ⊆ A ∧ B = {b ∈ A \ ( Z ∪ { z}) | target(b)} ∪ { z}} {inv}

19 20 21 22 23

else

24 25

fi {inv}

  sp {¬target( z) ∧ z ∈ A ∧ ∀u ∈ Z : preGet (u ) ∧ Z ⊆ A ∧ B = {b ∈ A \ ( Z ∪ { z}) | target(b)}} {inv} Skip {inv}

26 od 27 { Z = ∅ ∧ inv} 28 { B = {b ∈ A | target (b)}}

Fig. 4. Proof outline for correctness of the filter template.

• First, soundness of service calls. We need to show that

J u := Svc( v ) K(J preSvc [i := v ] ∧ ∀ w s.t. postSvc [i := v , o := w ] : q[u := w ] K) ⊆ JqK holds. For this, we now look at concretizations. Let π be a possible concretization and σ a state such that σ |= π (preSvc [i := v ] ∧ ∀ w .postSvc [i := v , o := w ] : q[u := o]) and u := Svc( v ), σ  →  E , σ  . Hence σ |= π (q[u := w ]) for all w such that postSvc [i := v , o := w ]. Furthermore, for σ  we get

σ  = σ [u := w ] for one such w. By induction one can furthermore prove that σ |= π (q[u := w ]) holds iff σ  |= π (q) holds which completes the proof. • Soundness of the take rule (4). We need to show that |= J take(a, A ) K(J A = ∅ ∧ ∀b ∈ A : q[a := b, A := A \ {b}] K) ⊆ J q K holds for all q. Thus let σ be a state satisfying A = ∅ ∧ ∀b ∈ A : q[a := b, A := A \ {b}]. When take(a, A ), σ  →  E , σ  , then by definition of the semantics of take we have σ  (a) ∈ σ ( A ) and σ  ( A ) = σ ( A ) \ {σ  (a)} and for all other variables x, σ  (x) = σ (x). Thus we get

σ  = σ [a := b, A := A \ {b}] for some b ∈ σ ( A ). By induction one can furthermore prove the following:

σ |= q[a := b, A := A \ {b}] iff σ [a := b, A := A \ {b}] |= q . Since σ satisfies q[a := b, A := A \ {b}] for all b ∈ σ ( A ), the desired property follows. • Next, we prove soundness of rule (8), the foreach statement. To this end, we need to show that the validity of |= { p ∧ A = ∅}take (a, A ); W { p } (premise of rule) implies the validity of |= { p }foreach a ∈ A do W od{ p ∧ A = ∅} (consequence of rule). Note that different from normal loops, foreach loops have a fixed number of executions of the loop body (the size of the set A) and thus always terminate. By the premise, the semantics of take and A ∈ / change( W ), we get

(i )

J take(a, A ); W K(J p ∧ A = ∅ ∧ # A = n K) ⊆ J p ∧ # A = n − 1 K

where # A is the size of A. We use this property to show that J foreach a ∈ A do W od K(J p K) ⊆ J p ∧ A = ∅ K. The proof proceeds by induction.

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.12 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

12

Base case # A = n = 0: By operational semantics of foreach we have

J foreach a ∈ A do W od K(J A = ∅ ∧ p K) = J A = ∅ ∧ p K Induction step # A = n + 1, and thus A = ∅:

J foreach a ∈ A do W od K(J p ∧ # A = n + 1 K) = { Definition of operational semantics and A = ∅} J take(a, A ); W ; foreach a ∈ A do W od K(J p ∧ # A = n + 1 K) = { Definition of sequential composition } J foreach a ∈ A do W od K(J take(a, A ); W K(J p ∧ # A = n + 1 K)) ⊆ { Property (i) of above and monotonicity of semantics} J foreach a ∈ A do W od K(J p ∧ # A = n K) ⊆ { Induction hypothesis } J A =∅∧ pK • Rule of consequence: |=CR π ( p ⇒ r ) means ∀S , π s.t. S |= R K ∧ S |= π (CR), we have S |= π ( p ) ⇒ π (r ). Furthermore, the premise gives us that ∀S , π : J W Kπ S (J π (r ) K S ⊆ J π (s) KS . Together this gives π J W Kπ S (J π ( p ) K) ⊆ J W KS (J π (r ) K) ⊆ J π (s) K ⊆ J π (q) K .

2

Thus, the proof outline in Fig. 4, constructed according to the proof calculus, indeed shows correctness of the workflow template of Fig. 2. 6. Proofs by SMT-solving Writing a proof outline manually is tedious, especially for larger templates. In this section, we explain a technique to prove (or disprove) correctness of a template (semi-) automatically (see also [27]). To this end, we encode the workflow of a template as first-order logic formula. This follows standard approaches for deriving verification conditions from programs which can then be discharged automatically using an SMT solver (e.g. [28,29]). The question of correctness of a template can also be encoded as a satisfiability problem, and answered by standard SMT solvers. The only exception to this desired full automation are – naturally – loops. For all loops in a workflow template, we require loop invariants to be a priori given. Alternatively, one could adapt techniques for inferring invariants like [30] or [31]. We define the logical formulae inductively, using the basic statements Skip, assignment, and service call as base cases. We use Var as the set of all variables occurring in a workflow. Every formula ϕ refers to variables “before” the statement and “after” the statement. In a formula definition we refer to the “before” variables with unprimed versions, to the “after” variables with primed versions. Sometimes we consider three states. Then, unprimed variables (and assertions) refer to the first state, primed to the second state, and doubly primed to the last (“after”) state (e.g, x, x , and x ). We also uses primes as operators on formulae, adding one prime to every variable. If formula ϕ thus uses variables x and x , ϕ  will use x and x . To derive logical formulae from workflow templates, we give a logical representation for every part of our syntax. After the definitions, we give a complete example based on the Filter template from Fig. 4. Definition 15 (Logical representation of workflows). Let W be a workflow. We define the logical representation of W , inductively on the structure of W .



ϕW ,

ϕSkip := x∈Var x = x. Skip Assignment ϕu :=t := u  = t ∧ x∈Var\{u } x = x. Service call Let Svc denote a service, pre its precondition, and  post its postcondition, i its input and o its output variable. ϕu:=Svc( v ) := (pre[i := v ] ⇒ post [i := v , o := u ] ∧ x∈ V ar \{u} x = x)  Take ϕtake(a, A ) := A = ∅ ⇒ (a ∈ A ∧ A  = A \ {a } ∧ x∈ V ar \{a, A } x = x). Sequential composition Let W 1 and W 2 be workflows, and ϕ W 1 and ϕ W 2 their representing formulae.  . ϕW 1 ;W 2 := ϕW 1 ∧ ϕW 2 Conditional Let W 1 and W 2 be workflows, ϕ W 1 and ϕ W 2 their representing formulae. ϕif B then W 1 else W 2 fi := ( B ∧ ϕW 1 ) ∨ (¬ B ∧ ϕW 2 ).

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.13 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

13

1 Z := A; 2 B := ∅ ; 3 foreach z ∈ Z do 4 y := Get( z) ; 5 if filter( y ) then 6 B := B ∪ { z} 7 else 8 Skip 9 fi 10 od

Fig. 5. Workflow of the Filter template, repeated.

While loop Let W be a workflow, ϕ W its representing formula and inv its already constructed loop invariant (see also below). ϕwhile B do W od := inv ⇒ (inv ∧ ¬ B  ) Note that the formula ϕ W , representing the inner workflow, is not (directly) part of the formula. Foreach loop Let W be a workflow, ϕ W its representing formula and inv its already constructed loop invariant (see also below). ϕforeach a∈ A do W od := inv ⇒ (inv ∧ A  = ∅) We illustrate this definition on our example template. For demonstration purposes, we repeat the code (Fig. 5) of the workflow of the Filter example in Fig. 2. We start with the topmost composition, and here use the indices of the line numbers to index the variables “before” and “after” the respective statements (as to treat a whole sequence of statements). Thus a formula ϕ (n, m) refers to the formula ϕ in which all unprimed variables x are replaced by xn and all primed variables x with xm . For a formula ϕ over unprimed variables only, we let ϕ (n) denote the formula with all variables x replaced by xn . Hence, what we are doing here is a sort of single static assignment (SSA) variable renaming [32]. As an invariant for the foreach loop, we again take sp

inv := Z ⊆ A ∧ (∀u ∈ Z : pre Get (u )) ∧ B = {b ∈ A \ Z | target(b)} . According to our definition, the formula for the Filter workflow is the following:

ϕFilter := ≡

ϕ Z := A (1, 2) ∧ ϕ B :=∅ (2, 3) ∧ ϕforeach (3, 10) Z 2 = A1 ∧



x2 = x1 ∧ B 3 = ∅ ∧

x= Z



x3 = x2

x= B

∧ (inv(3) ⇒ inv(10) ∧ Z 10 = ∅) Now, ϕFilter is a logical encoding of the Filter workflow. To automate the proof calculus technique of the last section, we use this formula as follows. In the end, we aim at proving { p } W {q}, where p is the pre- and q the postcondition of the template. For this, we carry out two sorts of proofs. First, we show that W establishes the postcondition at the end location n of the workflow when started in the precondition at location 1. We do so via showing the validity of

p 1 ∧ ϕ W ⇒ qn or, more precisely, by establishing the unsatisfiability of p 1 ∧ ϕ W ∧ ¬qn , where n is the number of the last statement in the workflow. For the Filter template this amounts to showing sp

∀a ∈ A 1 : preGet (a) ∧ ϕFilter ⇒ B 10 = {b ∈ A 10 | target(b)} which holds. Second, we need to show that all loop invariants used in the construction of ϕ W are actually invariants of the loop. If inv is a suggested invariant for a loop while B do W od with start location n and end location m, we show

inv(n) ∧ ϕ W (n, m) ⇒ inv(m) If inv belongs to a foreach loop, we use a similar check, namely that inv(n) ∧ ϕtake(a, A ); W (n, m) ⇒ inv(m) holds. In our example workflow template, the formula ϕtake(z, Z ); y :=Get(z);if filter( y ) then B := B ∪{z} else Skip if (3, 9) is



ϕtake(z, Z );... (3, 9) = Z 3 = ∅ ⇒ (z4 ∈ Z 3 ∧ Z 4 = Z 3 \ {z4 } ∧  



x4 = x3 )

x∈ V ar \{ z, Z } sp

sp

∧ preGet ( z4 ) ⇒ postGet ( z4 , y 5 ) ∧

 x∈ V ar \{ y }

x5 = x4



JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.14 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

14

∧







filter( y 5 ) ∧ B 9 = B 5 ∪ { z5 } ∨ ¬filter( y 5 ) ∧



x9 = x5



x∈ V ar

As we only encode a partial correctness semantics, checking for validity provides counterexamples relating to blocking sp executions, in this case, for Z 3 = ∅ and ¬preGet . False negatives put aside, checking validity of inv(3) ∧ ϕtake(z, Z );... (3, 9) ⇒ inv(9) succeeds. For these proofs we use established SMT solvers [33–35]. The new definition of universal validity of implications (Definition 14) is taken into account in the solvers using the technique of undefined functions plus the possibility of giving additional facts to solvers. Thus, all of the rules of the ontology and the constraints of the workflow template are given to the solver, and the type, predicate and function symbols of the ontology become undefined function symbols in the logic. Showing the above implications is thus always carried out modulo the rules of the ontology and the constraints of the template. While this example explains the encoding of correctness, it does not deal with an important difference between the type system defined in Definition 2 and the type system of SMT solvers. We derive our type system from the concepts C of an ontology K = (C , P , , R ): For every concept, we introduce a type. However, as we allow for concept inclusions, we effectively have a polymorphic type system: A variable may have more than one type. While this is desirable, a logical encoding in SMT-LIB [36], the SMT solver language standard, cannot be done with one-to-one encoding of types, as SMT-LIB features a monomorphic type system. Instead of introducing a type in SMT for every type derived by K , we introduce just a generic SMT type and encode our type system with predicates: For every type T , we introduce a predicate isOfT : T → Bool. Then, we encode type relations from  as additional assertions. 7. Template instantiation Templates are used to describe generic forms of service compositions, independent of concrete domains and thus concrete services. To describe templates we employ template ontologies which define the concepts usable in a template. For instantiation, we replace service placeholders with concrete services, which are typed over concrete domain ontologies. To this end, we define a mapping between a template ontology and a domain ontology. While general ontology mapping has to deal with different ontology conflicts [37,38], we assume a perfect mapping without conflicts. Definition 16 (Ontology mapping). Let K T = (C T , P T ,  T , R T ) be a template ontology and K D = (C D , P D ,  D , R D ) be a domain ontology. Then K T  f K D is an homomorphous ontology mapping from K T to K D by f , if f is a pair of mappings f = ( f C : C T → C D , f P : P T → P D ) such that

• f P preserves signatures with respect to f C , that is ∀ p ∈ P T with p : T 1 × · · · × T n → Bool we have f P ( p ) : f C ( T 1 ) × · · · × f C ( T n ) → Bool; • f preserves the rules R T , that is ∀r ∈ R T with r = b1 ∧ · · · ∧ bn → h1 ∧ · · · ∧ hm , there is r  ∈ R D with r  = f (b1 ) ∧ · · · ∧ f (bn ) → f (h1 ) ∧ · · · ∧ f (hm ). We assume the mapping pair f to map standard types to themselves, e.g., f (Bool) = Bool, f (set T ) = set( f ( T )). For brevity, we use f as a shorthand notation for the application of the correct mappings f C , f P . To replace service placeholders (typed over a template ontology K T ) with service descriptions (typed over a domain ontology K D ), we define an concretization π f for two ontologies with K T  f K D . Definition 17. Let K T and K D be ontologies with K T  f K D , SP T be the set of service placeholders over K T , and SVC D be the set of service descriptions4 over K D . Then π f : SP T → SVC D is a concretization of service placeholders from K T to K D , if it respects signatures with respect to f , that is,

if π f (sp) = svc and sp : T 1 → T 2 , then svc : T 1 → T 2 with f ( T 1 )  T 1 and T 2  f ( T 2 ) . We lift π f to pre- and postconditions of placeholders, such that π f (presp ) ∈  D and free(π f (presp )) ⊆ {i }, as well as π f (postsp ) ∈  D and free(π f (postsp )) ⊆ {i , o}. In short, π f maps placeholders to services, using the ontology mapping f of K T  f K D to translate types from the template to the domain ontology. As the semantics of workflows rely on logical structures, we need to clarify the relation of structures over K T to structures over K D : if a structure satisfies the rules of K D , then there exists a corresponding one satisfying the rules of K T .

4

Again, for easier reading, we assume one input and one output for services.

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.15 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

15

Proposition 1. Let K T = (C T , P T ,  T , R T ) and K D = (C D , P D ,  D , R D ) be ontologies and S = (U , I ) a logical structure over K D . If K T  f K D , and S |= R D , then we can construct a corresponding logical structure S  f , where

S  f = (U  f , I  f ), with

f

UT I

f

= U f (T ) and ( p ) = I ( f ( p )) for p ∈ PT

such that S  f |= R T . Later, we will reason about formulae containing placeholders, which are satisfied by a logical structure, and which follow from the rules of an ontology. Therefore, in addition to the construction of a corresponding logical structure, we construct a corresponding mapping from placeholders to service descriptions as well. Proposition 2. Let K T = (C T , P T ,  T , R T ) and K D = (C D , P D ,  D , R D ) be ontologies with K T  f K D , and S = (U , I ) a logical structure over K D . Let  ∈  T be a formula containing placeholders from SP T , and let π f : SP T → SVC D be a concretization with (we use superscripts T and D to refer to types derived from K T and K D )

sp ∈ SP T , svc ∈ SVC D , sp : T 1T → T 2T , svc : T 1D → T 2D , f ( T 1T )  T 1D , T 2D  f ( T 2T ) ,

π f (sp) = svc . If S satisfies the rules of K D and the concretized formula π f (), that is,

S |= R D ∧ π f () , f

then we can construct a corresponding concretization π f that

: SP T → SVC T within the template ontology in the following way such

svc ∈ SVC T , svc : T 1T → T 2T , 

π f f (sp) = svc , where svc and svc refer to the same name; then we also know, that

presvc ∈  T such that f (presvc ) = presvc , postsvc ∈  T such that f (postsvc ) = postsvc ; f

and we can conclude S  f |= π f

().

Proof. Consider some state σ |=S π f () with  ∈  T . Then, the interpretations I D are defined for every predicate. We can construct S  f by Proposition 1, where the interpretations of template predicates are by construction the same as the interpretations of the corresponding (by f ) domain predicates. The only predicates without interpretations are the pre- and f f sp sp postconditions of placeholders. We can construct π f such that f (π f (presvc )) = π f (presvc ) (same for postcondition). By definition, the interpretations are then mapped to the corresponding predicates, and The same is true for





σ |=S π f () ⇒ σ |=S  f π f f ().

σ |=S π f (), therefore σ |=S π f () ⇔ σ |=S  f π f f (). 2

We can conclude that the set of states satisfying a formula with instantiated placeholders under a structure S , is the same as for the corresponding S  f : Lemma 1. Let K T = (C T , P T ,  T , R T ) a template ontology and K D = (C D , P D ,  D , R D ) a domain ontology with K T  f K D , a concretization π f , a formula F ∈  T containing placeholders from SP T , and a structure S |= π f ( F ), then 

J π f ( F ) KS = J π f f ( F ) KS  f .

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.16 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

16 Name : Inputs : Outputs : Services : Precondition : Postcondition: Constraints :

RestaurantFilter A with type( A ) = set Restaurant B with type( B ) = set Restaurant GetRating : Restaurant → Rating {∀a ∈ A : } { B = {b ∈ A | goodRestaurant(b)}} {∀x, y: hasRating (x, y ) ∧ isMinRating( y ) ⇒ goodRestaurant (x), ∀x, y: hasRating ∧ ¬isMinRating( y ) ⇒ ¬goodRestaurant (x)}

1 Z := A; 2 B := ∅ ; 3 foreach z ∈ Z do 4 y := GetRating ( z); 5 if isMinRating( y ) then 6 B := B ∪ { z} 7 else 8 Skip 9 fi 10 od

Fig. 6. Instantiation of the Filter template with a restaurant ontology and a rating acquisition service.

Note that we do not need to give an interpretation for the standard function and predicate symbols since their interpretation is always the same. We continue our example with the Tourism domain ontology and the description of the service GetRating. Example 5. Let K T = (C T , P T ,  T , R T ) be the template ontology from Example 1, and K D = (C D , P D ,  D , R D ) the domain ontology from Example 2. We define a mapping f = ( f C , f P ) from K T to K D with K T  f K D as:

f C : Elem → Restaurant, Value → Rating f P : filter → isMinRating, target → goodRestaurant . Since the template ontology has no rules besides the functionality of predicates, f trivially preserves them. For our restaurant ontology, we assume the service GetRating to provide a lookup service for ratings of restaurants. Such services can replace service placeholders in the template. In addition, instantiation requires replacing Boolean conditions in the template workflow (because they use template predicates) with their counterparts in the domain ontology. To this end, we apply the ontology mapping f to the Boolean conditions. Definition 18 (Workflow instantiation). Let W T = ( N , I , O , SP T , pre, post, CR, W ) be a workflow template over a template ontology K T , K D be a domain ontology with set of services SVC D and K T  f K D with f = ( f C , f P ). Let π f : SP T → SVC D be a concretization of the service placeholders in W T to services of the domain ontology. The instantiation of the workflow W with respect to π and f , π f ( W ), is lifting π f to the level of workflows, inductively defined as follows:

π f (Skip) := Skip

π f (u := t ) := u := t

π f (u := Svc(i )) := u := π f (Svc)(i ) π f ( W 1 ; W 2 ) := π f ( W 1 ); π f ( W 2 ) π f (if B then W 1 else W 2 fi) := if f ( B ) then π f ( W 1 ) else π f ( W 2 ) fi π f (while B do W od) := while f ( B ) do π f ( W ) od π f (foreach a ∈ A do W od) := foreach a ∈ A do π f ( W ) od . The inputs and outputs of the template are subject to the ontology mapping f , that is, type T of an input or output variable of the template becomes f C ( T ) in the instantiation. Note that terms t do not need to be mapped by f since they only contain function symbols over standard types. When templates are instantiated, we get service compositions. Note that for the instantiation to be done in practice, we assume a set of implemented services to be existing so that our instantiation just needs to pick the right services. Currently, we do not automatically generate service implementations. Formally, a service composition is a workflow (over a domain ontology) without service placeholders. Fig. 6 shows an instantiation of the filter template, using the ontology mapping of Example 5 and π f (Get) = GetRating.

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.17 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

17

Fig. 7. Overview of the proof of Theorem 2, with main steps (1) to (5).

For the semantics of service compositions, we re-use the semantics definition of templates. This time, however, we can omit the parameter π f , since all services are concrete. Therefore, the only parameter left for the semantics is the logical structure: the interpretation of domain ontology predicates is still not defined. The correctness condition can thus directly be re-used, except that service compositions do not come with fixed pre- and postconditions (unlike templates). Definition 19. A service composition W over a domain ontology K is correct with respect to some precondition pre ∈  K and some postcondition post ∈  K if the following holds:

∀ logical structures S s.t. S |= R K : J W KS (J pre KS ) ⊆ J post KS . We have defined correctness of templates and service compositions as well as semantics for both. If a template and a composition are typed over the same ontology, we can conclude from the definitions that they have the same semantics. Lemma 2. Let W T be a template with workflow W , and π : SP K → SVC K be an instantiation with services over ontology K . Then the following holds:

∀ logical structures S :

J W Kπ S = J π ( W ) KS .

From the semantics and correctness definitions above, and assuming that the template is already proven correct, we state the following: To prove correctness of a service composition, it is sufficient to show that the instantiated constraints of the template can be derived from the rules of the domain ontology. Theorem 2 (Soundness of instantiations). Let W T = ( N , I , O , SP T , pre, post, CR, W ) be a correct workflow template over a template ontology K T , K D be a domain ontology such that K T  f K D with a mapping f = ( f C , f P ), and π f : SP T → SVC D be a concretization of service placeholders in the template with services of the domain ontology. If R D |= π f (CR), then π f ( W ) is correct with respect to π f (pre) and π f (post). Fig. 7 gives an overview of the proof: First, we select a structure which satisfies the concretized constraints of the template (1). Then, we construct the corresponding structure which satisfies the original constraints (2). By definition, we know the semantics of the template (3) and can conclude that its instantiation has the same semantics (4). As the template is correct, the instantiation is also correct (5). We will now give the formal proof. Proof. Let WT = ( N , I , O , SP T , pre, post, CR, W ) be a correct workflow template over a template ontology K T , and π f ( W ) be a service composition over a domain ontology K D with K T  f K D . We have to show that, for any concretization π f where the domain ontology satisfies the concretized template constraints, π f ( W ) is indeed a correct instantiation of template WT, that is, it is correct with respect to the concretized precondition and postcondition of WT . Formally: for all structures S D and instantiations π f the following has to hold:

S D |= R D ∧ R D |= π f (CR) : J π f ( W ) KS D (J π f (pre) KS D ) ⊆ J π f (post) KS D . To start, define S D and

π f such that

S D |= R D ∧ R D |= π f (CR) . If S D satisfies its rules, then it satisfies the subset of rules that is the range of the homomorphous mapping:

S D |= R D ⇒ S D |= f ( R T ) because f ( R T ) ⊆ R D (by Definition 16). Also, if both R D |= π f (CR) and S D |= R D , then S D |= π f (CR). Therefore

S D |= f ( R T ) ∧ S D |= π f (CR)

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.18 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

18

also holds. Now we “switch” to the template ontology; by K T  f K D , we can construct a corresponding structure over the template ontology (Proposition 1) along with a mapping f

∃S  f , ∃π f

f

πf

: SP T → SVC T (Proposition 2):



: S  f |= R T ∧ S  f |= π f f (CR) .

By Definition 13, and because WT is correct, we know f

∃S  f , ∃π f

: f

S  f |= R T ∧ S  f |= π f (CR) : J W K

f

πf S

f





(J π f f (pre) KS  f ) ⊆ J π f f (post) KS  f .

As we are currently solely in the template ontology, by Lemma 2 we know that a template and an instantiation have the same semantics, and therefore f

∃S  f , π f

: f

S  f |= R T ∧ S  f |= π f (CR) : 





J π f f ( W ) KS  f (J π f f (pre) KS  f ) ⊆ J π f f (post) KS  f . If we “switch back” to the domain ontology, by Lemma 1, we can use our original S D again:

S D |= R D ∧ S D |= π f (CR) : J π f ( W ) KS D (J π f (pre) KS D ) ⊆ J π f (post) KS D . It is therefore sufficient to show that R D |= π f (CR), if the template is already proven to be correct, and K T  f K D holds.

2

For our example template, we look at the instantiation π f (Get) = GetRating. It can easily be shown that the concretized constraints follow from the rules R D of the restaurant domain: The concretized constraints are

hasRating (res, rat) ∧ isMinRating(rat) ⇒ goodRestaurant(rat) hasRating(res, rat) ∧ ¬isMinRating(rat) ⇒ ¬goodRestaurant(rat) Again, they can be checked by an SMT solver when providing it with the ontology rules as additional facts. Thus the service composition as given by the instantiated template is correct with respect to the mapped pre- and postconditions of the template which are ∀a ∈ A : true (precondition) and B = {b ∈ A | goodRestaurant(b)}. The following two compositions use a slightly different ontology mapping. Example 6. Let K T = (C T , P T ,  T , R T ) be the template ontology from Example 1, and K D = (C D , P D ,  D , R D ) the domain ontology from Example 2. We define a mapping f = ( f C , f P ) from K T to K D with K T  f K D as:

f C : Elem → SnackBar, Value → Rating f P : filter → isMaxPrice, target → cheap . Since the template ontology has no rules besides the functionality of predicates, f trivially preserves them. For our restaurant ontology, we assume the service GetRating to provide a lookup service for ratings of restaurants, and GetPrice to provide a lookup service for price categories of restaurants. Fig. 8 illustrates a template instantiation which does not get a “good” but a “cheap” restaurant, using the ontology mapping from Example 6 and π f (Get) = GetPrice. With hasPrice being the postcondition of the GetPrice service, we can see that the concretization of predicates results in exactly the same rules which are given in the ontology, and therefore, they are not contradictory. In contrast, Fig. 9 presents a composition where the instantiation of constraint rules conflicts with the domain ontology. It uses the same ontology mapping, but a service mapping of π f (Get) = GetFakedPrice (cf. Table 1). The service GetFakedPrice delivers an arbitrary price for a given restaurant (or snack bar), using the postcondition postGetFakedPrice (r , p ) ≡ isMaxPrice( p ). It is easy to find a predicate interpretation (and therefore a logical structure) which satisfies the ontology, but not the instantiated constraints of this composition, e.g., a snack bar which is not cheap. Therefore, this instantiation is not correct; an SMT solver would find such a violating interpretation of predicates and provide it as a counterexample.

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.19 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–••• Name : Inputs : Outputs : Services : Precondition : Postcondition: Constraints :

19

SnackBarFilter A with type( A ) = set SnackBar B with type( B ) = set SnackBar GetPrice : Restaurant → Price {∀a ∈ A : } { B = {b ∈ A | cheap(b)}} {∀x, y : hasPrice(x, y ) ∧ isMaxPrice( y ) ⇒ cheap(x), ∀x, y : hasPrice(x, y ) ∧ ¬isMaxPrice( y ) ⇒ ¬cheap(x)}

1 Z := A; 2 B := ∅ ; 3 foreach z ∈ Z do 4 y := GetPrice( z); 5 if isMaxPrice( y ) then 6 B := B ∪ { z} 7 else 8 Skip 9 fi 10 od

Fig. 8. Instantiation of the Filter template with a restaurant ontology and a price acquisition service.

Name : Inputs : Outputs : Services : Precondition : Postcondition: Constraints :

SnackBarFilterFail A with type( A ) = set SnackBar B with type( B ) = set SnackBar GetFakedPrice : SnackBar → Price {∀a ∈ A : } { B = {b ∈ A | cheap(b)}} {∀x, y : isMaxPrice( y ) ∧ isMaxPrice( y ) ⇒ cheap(x), ∀x, y : isMaxPrice( y ) ∧ ¬isMaxPrice( y ) ⇒ ¬cheap(x)}

1 Z := A; 2 B := ∅ ; 3 foreach z ∈ Z do 4 y := GetFakedPrice( z); 5 if isMaxPrice( y ) then 6 B := B ∪ { z} 7 else 8 Skip 9 fi 10 od

Fig. 9. Instantiation of the Filter template with a restaurant ontology and a price acquisition service, which tries to relate price and quality.

8. Discussion Our approach contains the following aspects: (1) we have correct templates with a formal, parameterized semantics, (2) instantiate them with services of a concrete domain, and (3) show correctness of the instantiation by correctness of simple side-conditions. As instantiated templates come along with a full-fledged service description, they can be treated as services themselves, and therefore be re-used as services in other template instantiations. On a basic level, verification of service compositions is not fundamentally different from verification of programs. Reasoning about the correctness of programs using a Hoare-style proof calculus [25,26] is common [19], and similar calculi are used for reasoning about control-state abstract state machines [39], synchronous languages for reactive systems [40], or concurrent programs with higher-order concurrency [41]. However, especially the context of on-the-fly composition and verification comes with timing constraints, as on-the-fly scenarios are based on a fast (if not instant) reply to a user request. This requires not only fully automatic, but also fast quality analysis. We therefore believe that it is not always feasible to prove correctness of service compositions individually. Domain-independent templates can, on the other hand, be verified without timing constraints. This allows not only for the use of time consuming analyses (where time is typically correlated to the size and/or structure of the analysis model), but also for semi-automatic or even completely manual correctness proofs by domain experts (e.g., using theorem provers). Then, instantiations can be created on-the-fly, without the necessity of an additional complete verification: checking the validity of the instantiated constraints is sufficient. Working with templates in general is common in modular software design methods, component-based software development, and service-oriented architectures, either by dedicated modeling constructs, or by best-practices. However, templates are not necessarily verified. An early approach of compositional model checking, based on refinement, is [42], though they use temporal logic specifications and Moore automata. Closer to our approach of formally specifying a service composition as a parameterized template, and to get provably correct instantiations, is the CARE approach [43,44]. CARE follows a refinement-based approach of modeling, and generating, correct service compositions, using the Z modeling language [45] as a concise formal

JID:SCICO AID:2000 /FLA

20

[m3G; v1.175; Prn:22/04/2016; 13:12] P.20 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

notation. In CARE, so-called fragments are used for modeling: primitives with black-box descriptions, which are proven to be correct externally; and composites, which are used to model complex algorithms. Based on the multi-set theoretic semantics of Z , several proof obligations can be derived from specification of a composition. The CARE approach also supports a notion of templates, where parts of the specification – types and primitive fragments – are represented by parameters, that is, specifications without corresponding implementations [44]. This way, the concrete implementation can be instantiated later, as long as it meets the formal description used in the composition. In contrast to CARE, we define correctness for an incomplete (not instantiated) template. Once proven correct, we show that it is sufficient to proof that an instantiation adheres to some constraints, while in CARE, proof obligations derived from a final instantiation always contain a complete proof for the complete instantiation. Other approaches of modular analysis are rooted in the domain of software product lines. [46] re-uses verification results of programs with changing method call implementations, using method call contracts as black box descriptions. Similarly, but based on delta-oriented programming, [47] verifies a “core” program and combines the result with verification results of program refinements (“deltas”). [22] uses an early version of our approach to create large repositories of correct service compositions automatically. To this end, they implement our technique of constraint validation to create compositions which are correct by construction, starting with correct templates. This way, [22] complements the theoretical foundations of this paper with an empirical perspective. Though their evaluation has its focus on a search algorithm and the generation of service compositions, it becomes clear that the actual checks of side conditions are done in the range of milliseconds. Based on the development of adaptation techniques, [48] advocates the need for verification at runtime, to verify compositions which changed while already deployed. SimuLizar [49] extends the Palladio Component Model (PCM, [1]) with fuzzy requirements for adaptation using the temporal-logic-based RELAX language, targeting scalability analysis. While both focus on non-functional properties, it would be promising to apply our template- and constraint-based verification to similar runtime contexts. There is also more research to define formal semantics for existing industrial workflow languages. While [50] defines an event algebra for general workflows, [51] defines a semantic for WS-BPEL [23] based on abstract machines, and [52] based on Petri nets. [53] derives a data flow network from BPEL and translate it to a Promela [54] model. Also based on generalized data flow networks, the REO approach [55] focuses on communication between entities (e.g., services), by using channel-based communication models, and defining a semantics based on times data streams [56]. While we use a simple imperative programming style language to present our approach, we believe it is possible to apply our results to existing workflow or software architecture languages. To do this, the target language needs a notion of placeholders, and a proper mapping between the languages has to be defined. Our own ongoing experiments are based on an extension of PCM (esp. with pre-/postconditions, [24]), where we also work on SAT-based verification of the instantiation process. 9. Conclusion In this paper, we presented the theoretical foundation for an approach to create service compositions for different domains by instantiation of domain-independent templates. Moreover, if these templates are provably correct, we have shown that verification of service compositions can be reduced to verification of side-conditions of the instantiation: the instantiated template constraints have to hold in the target domain. To prove this, we defined an abstract semantics for workflow templates containing service placeholders, which is parameterized by concretizations (of placeholders), and logical structures (which fix the concrete meaning). We defined correctness with respect to pre- and postconditions based on this parameterized semantics. If templates formalize instantiation constraints in the form of rules, we have shown that all possible template instantiations are correct, if the (corresponding) instantiation of these constraints are correct. Additionally, we defined sound proof axioms and rules for service calls and foreach loops, and gave an example of automating proofs using SMT solvers. Therefore, using this approach to create service compositions, their verification can be reduced to verification of sideconditions. As fully automatic verification of service compositions is not always possible, but checking of side-conditions often is, we consider this an important step towards automatic verification in the context of on-the-fly scenarios. Acknowledgement We would like to thank our colleague Felix Mohr for several discussions about the use of templates in service compositions, as well as the anonymous reviewers for their feedback. References [1] S. Becker, H. Koziolek, R. Reussner, The Palladio component model for model-driven performance prediction, in: Special Issue: Software Performance – Modeling and Analysis, J. Syst. Softw. 82 (1) (2009) 3–22. [2] T. Bures, P. Hnetynka, F. Plasil, SOFA 2.0: balancing advanced features in a hierarchical component model, in: SERA, 2006, pp. 40–48. [3] D. Martin, M. Paolucci, S. McIlraith, M. Burstein, D. McDermott, D. McGuinness, B. Parsia, T. Payne, M. Sabou, M. Solanki, N. Srinivasan, K. Sycara, Bringing semantics to web services: the OWL-S approach, in: J. Cardoso, A. Sheth (Eds.), Semantic Web Services and Web Process Composition, in: LNCS, vol. 3387, Springer, 2005, pp. 26–42.

JID:SCICO AID:2000 /FLA

[m3G; v1.175; Prn:22/04/2016; 13:12] P.21 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

21

[4] A. Pnueli, The temporal logic of programs, FOCS (1977) 46–57. [5] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. [6] S. Walther, H. Wehrheim, Verified service compositions by template-based construction, in: I. Lanese, E. Madelaine (Eds.), Formal Aspects of Component Software, in: LNCS, Springer International Publishing, 2015, pp. 31–48. [7] T.R. Gruber, A translation approach to portable ontology specifications, Knowl. Acquis. 5 (2) (1993) 199–220. [8] F. Baader, I. Horrocks, U. Sattler, Description logics, in: V.L. Frank van Harmelen, B. Porter (Eds.), Foundations of Artificial Intelligence, vol. 3, Elsevier, 2008, pp. 135–179. [9] F. Gandon, G. Schreiber, RDF 1.1 XML syntax, W3C recommendation, W3C, http://www.w3.org/TR/2014/REC-rdf-syntax-grammar-20140225/, Feb. 2014. [10] G. Antoniou, F. Harmelen, Web ontology language: OWL, in: S. Staab, R. Studer (Eds.), Handbook on Ontologies, International Handbooks on Information Systems, Springer, Berlin, Heidelberg, 2009, pp. 91–110. [11] P. Patel-Schneider, B. Parsia, B. Motik, OWL 2 web ontology language structural specification and functional-style syntax (second edition), W3C recommendation, W3C, http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/, Dec. 2012. [12] I. Horrocks, P.F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M. Dean, SWRL: a semantic web rule language combining OWL and RuleML, http://www.w3.org/Submission/2004/SUBM-SWRL-20040521/, 2004. [13] E. Franconi, S. Tessaris, Rules and queries with ontologies: a unified logical framework, in: H.J. Ohlbach, S. Schaffert (Eds.), Principles and Practice of Semantic Web Reasoning, in: LNCS, vol. 3208, Springer, 2004, pp. 50–60. [14] N. Guarino, D. Oberle, S. Staab, What is an ontology?, in: S. Staab, R. Studer (Eds.), Handbook on Ontologies, International Handbooks on Information Systems, Springer, 2009, pp. 1–17. [15] Qallme tourism ontology, http://qallme.fbk.eu. [16] Good relations ontology project, http://www.goodrelations-vocabulary.org. [17] Schema.org e-commerce taxonomy, http://www.schema.org. [18] OpenGALEN ontology, http://www.opengalen.org. [19] K. Apt, F. de Boer, E.-R. Olderog, Verification of Sequential and Concurrent Programs, Springer, 2009. [20] Amazon Web Services, https://aws.amazon.com. [21] M. Happe, F. Meyer auf der Heide, P. Kling, M. Platzner, C. Plessl, On-the-fly computing: a novel paradigm for individualized it services, in: 2013 IEEE 16th International Symposium on Object/Component/Service-Oriented Real-Time Distributed Computing (ISORC), 2013, pp. 1–10. [22] F. Mohr, S. Walther, Template-based generation of semantic services, in: Proceedings of the 14th International Conference on Software Reuse (ICSR), in: LNCS, Springer, 2014, pp. 188–203. [23] OASIS, Web services business process execution language v2.0, http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf. [24] S. Arifulina, S. Walther, M. Becker, M.C. Platenius, SeSAME: modeling and analyzing high-quality service compositions, in: Proceedings of the 29th ACM/IEEE International Conference on Automated Software Engineering, ASE ’14, ACM, New York, NY, USA, 2014, pp. 839–842. [25] C.A.R. Hoare, An axiomatic basis for computer programming, Commun. ACM 12 (10) (1969) 576–580. [26] S. Owicki, D. Gries, An axiomatic proof technique for parallel programs I, Acta Inform. 6 (4) (1976) 319–340. [27] S. Walther, H. Wehrheim, Knowledge-based verification of service compositions – an SMT approach, in: ICECCS, 2013, pp. 24–32. [28] P. Godefroid, S.K. Lahiri, From program to logic: an introduction, in: B. Meyer, M. Nordio (Eds.), Tools for Practical Software Verification, LASER, International Summer School 2011, Elba Island, Italy, Revised Tutorial Lectures, in: Lecture Notes in Computer Science, vol. 7682, Springer, 2011, pp. 31–44. [29] C. Flanagan, J.B. Saxe, Avoiding exponential explosion: generating compact verification conditions, in: C. Hankin, D. Schmidt (Eds.), Conference Record of POPL 2001: The 28th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, London, UK, January 17–19, 2001, ACM, 2001, pp. 193–205. [30] S. Srivastava, S. Gulwani, Program verification using templates over predicate abstraction, in: PLDI ’09, ACM, New York, NY, USA, 2009, pp. 223–234. [31] I. Dillig, T. Dillig, B. Li, K. McMillan, Inductive invariant generation via abductive inference, in: Proceedings of the 2013 ACM SIGPLAN International Conference on Object Oriented Programming Systems Languages; Applications, OOPSLA ’13, ACM, New York, NY, USA, 2013, pp. 443–456. [32] R. Cytron, J. Ferrante, B.K. Rosen, M.N. Wegman, F.K. Zadeck, Efficiently computing static single assignment form and the control dependence graph, ACM Trans. Program. Lang. Syst. 13 (4) (1991) 451–490. [33] N. Bjørner, A. Blass, Y. Gurevich, M. Musuvathi, Modular difference logic is hard, CoRR, arXiv:0811.0987. [34] D. Detlefs, G. Nelson, J.B. Saxe, Simplify: a theorem prover for program checking, J. ACM 52 (3) (2005) 365–473. [35] A. Cimatti, A. Griggio, B.J. Schaafsma, R. Sebastiani, The mathsat5 SMT solver, in: Tools and Algorithms for the Construction and Analysis of Systems – Proceedings of the 19th International Conference, TACAS 2013, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2013, Rome, Italy, March 16–24, 2013, 2013, pp. 93–107. [36] C. Barrett, P. Fontaine, C. Tinelli, The SMT-LIB standard: version 2.5, Tech. rep, Department of Computer Science, The University of Iowa, 2015, available at www.SMT-LIB.org. [37] N.F. Noy, Ontology mapping, in: S. Staab, R. Studer (Eds.), Handbook on Ontologies, International Handbooks on Information Systems, Springer, 2009, pp. 573–590. [38] S.K. Kumar, J.A. Harding, Ontology mapping using description logic and bridging axioms, Comput. Ind. 64 (1) (2013) 19–28. [39] W. Gabrisch, W. Zimmermann, A hoare-style verification calculus for control state ASMs, in: Proceedings of the Fifth Balkan Conference in Informatics, BCI ’12, ACM, New York, NY, USA, 2012, pp. 205–210. [40] M. Gesell, K. Schneider, A hoare calculus for the verification of synchronous languages, in: Proceedings of the Sixth Workshop on Programming Languages Meets Program Verification, PLPV ’12, ACM, New York, NY, USA, 2012, pp. 37–48. [41] A. Turon, D. Dreyer, L. Birkedal, Unifying refinement and hoare-style reasoning in a logic for higher-order concurrency, in: Proceedings of the 18th ACM SIGPLAN International Conference on Functional Programming, ICFP ’13, ACM, New York, NY, USA, 2013, pp. 377–390. [42] O. Grumberg, D. Long, Model checking and modular verification, in: J. Baeten, J. Groote (Eds.), CONCUR ’91, in: Lecture Notes in Computer Science, vol. 527, Springer, Berlin, Heidelberg, 1991, pp. 250–265. [43] P.A. Lindsay, D. Hemer, An industrial-strength method for the construction of formally verified software, in: Proceedings Australian Software Engineering Conference, 1996, p. 27. [44] D. Hemer, P. Lindsay, Reuse of verified design templates through extended pattern matching, in: J. Fitzgerald, C. Jones, P. Lucas (Eds.), FME ’97: Industrial Applications and Strengthened Foundations of Formal Methods, in: LNCS, vol. 1313, Springer, 1997, pp. 495–514. [45] J. Woodcock, J. Davies, Using Z: Specification, Refinement, and Proof, Prentice Hall, 1996. [46] S. Soleimanifard, D. Gurov, Algorithmic verification of procedural programs in the presence of code variability, in: I. Lanese, E. Madelaine (Eds.), Formal Aspects of Component Software, in: Lecture Notes in Computer Science, vol. 8997, Springer International Publishing, 2015, pp. 327–345. [47] R. Hähnle, I. Schaefer, A Liskov principle for delta-oriented programming, in: T. Margaria, B. Steffen (Eds.), Leveraging Applications of Formal Methods, Verification and Validation. Technologies for Mastering Change, in: Lecture Notes in Computer Science, vol. 7609, Springer, Berlin, Heidelberg, 2012, pp. 32–46. [48] R. Calinescu, C. Ghezzi, M. Kwiatkowska, R. Mirandola, Self-adaptive software needs quantitative verification at runtime, Commun. ACM 55 (9) (2012) 69–77.

JID:SCICO AID:2000 /FLA

22

[m3G; v1.175; Prn:22/04/2016; 13:12] P.22 (1-22)

S. Walther, H. Wehrheim / Science of Computer Programming ••• (••••) •••–•••

[49] M. Becker, M. Luckey, S. Becker, Performance analysis of self-adaptive systems for requirements validation at design-time, in: QoSA, ACM, 2013, pp. 43–52. [50] M.P. Singh, Formal Aspects of Workflow Management – Part 1: Semantics, 1997. [51] R. Farahbod, U. Glässer, M. Vajihollahi, Abstract operational semantics of the business process execution language for web services, Tech. rep., 2005. [52] C. Ouyang, E. Verbeek, W.M.P. van der Aalst, S. Breutel, M. Dumas, A.H.M. ter Hofstede, Formal semantics and analysis of control flow in WS-BPEL, Sci. Comput. Program. 67 (2–3) (2007) 162–198. [53] M. Kovács, L. Gönczy, Simulation and formal analysis of workflow models, Electron. Notes Theor. Comput. Sci. 211 (2008) 221–230. [54] G.J. Holzmann, The model checker SPIN, IEEE Trans. Softw. Eng. 23 (5) (1997) 279–295. [55] F. Arbad, Reo: a channel-based coordination model for component composition, Math. Struct. Comput. Sci. 14 (2004) 329–366. [56] F. Arbab, J. Rutten, A coinductive calculus of component connectors, in: M. Wirsing, D. Pattinson, R. Hennicker (Eds.), Recent Trends in Algebraic Development Techniques, in: LNCS, vol. 2755, Springer, 2003, pp. 34–55.