# An Improved Abstract State Machine Based Choreography Specification and Execution Algorithm for Semantic Web Services

Authors: Shahin Mehdipour Ataee; Zeki Bayram
Journal: Scientific Programming
 (2018)

---

## Abstract

We identify significant weaknesses in the original Abstract State Machine (ASM) based choreography algorithm of Web Service Modeling Ontology (WSMO), which make it impractical for use in semantic web service choreography engines. We present an improved algorithm which rectifies the weaknesses of the original algorithm, as well as a practical, fully functional choreography engine implementation in Flora-2 based on the improved algorithm. Our improvements to the choreography algorithm include (i) the linking of the initial state of the ASM to the precondition of the goal, (ii) the introduction of the concept of a final state in the execution of the ASM and its linking to the postcondition of the goal, and (iii) modification to the execution of the ASM so that it stops when the final state condition is satisfied by the current configuration of the machine. Our choreography engine takes as input semantic web service specifications written in the Flora-2 dialect of F-logic. Furthermore, we prove the equivalence of ASMs (evolving algebras) and evolving ontologies in the sense that one can simulate the other, a first in literature. Finally, we present a visual editor which facilitates the design and deployment of our F-logic based web service and goal specifications.


---

## Body

## 1. Introduction

The idea of using service oriented architecture (SOA) to form an IT infrastructure for carrying out business-to-business interactions has gained a lot of attention in the last 15 years. In this context, service composition has been studied and analyzed in many researches. Two important and complementary aspects of service composition areservice orchestration andservice choreography.Service orchestration is the process of coordinating two or more services for the purpose directing them toward the accomplishment of a specific task in a centralized way. Service choreography however (as pointed out in [1–3] as well) does not have a unique understanding among researchers. In the Business Process Modeling (BPM) community, choreography is known as a general predefined collaboration scenario that should be agreed upon and adhered to by two or more web services in order to accomplish a business goal, without the presence of a central coordinator (unlike orchestration). The choreography engine checks whether the participants are passing proper messages at the right time and in the correct order specified by the choreography designers [4]. In this paradigm, choreography is considered as a global collaboration, rather than bidirectional interaction between a service requester and a service provider.The global collaboration view forms the basis of modeling languages such as WSCI [5], WS-CDL [6], BPEL4Chor [7, 8], Let’s Dance [9], Multi-Agent Protocol (MAP) [10], and BPELgold [11]. The dominant common features of this type of choreography languages are(i)
being process-driven: a service is modeled as a process composed of series of milestones,(ii)
having no role for goals: there is no concept of a service requester,(iii)
staticity: the overall sequence of events is specified at design time,(iv)
being nonsemantic: no ontology is used, which is the main feature of a semantic system [12],(v)
not having any inferencing capability.In contrast, the concept of choreography among semantic web service developers is understood as the behavioral interface of asingle web service when it is interacting with its client (so-calledgoal), which results in an automatic, flexible conversation (dialog) between the two. In other words, it is the implicit communication protocol between two (and only two) counterparts that should be dynamically carried out in order to realize a conversation. The role of choreography engine is to dynamically control the conversation and see whether it is successful or not. This concept has been namedchoreography interface in [13].In the rest of this article, we use the termchoreography only in the semantic web sense. Our work also falls strictly in the semantic web view of choreography and consequently is not directly comparable to choreography languages adapted by the BPM community.To fully automate service choreography, there is the need for unambiguous, computer processable semantics that can be used for automated reasoning [13]. A well-known semantic web service framework is Web Service Modeling Ontology (WSMO) [14]. In WSMO, the specification and behavior of the service provider (web service) and the service requester (goal) are described using a rich semantic notation. WSMOchoreography is a component of WSMOinterface that deals with choreographing of WSMO-based web services and goals.Although WSMO based its choreography algorithm on the well-founded theory ofAbstract State Machines (ASMs) [15, 16], the algorithm is less than perfectly suited for the job at hand. In fact, our literature search has failed to reveal any choreography engine that implements it exactly as specified. For example, current implementations (such as WSMX [17] and IRS-III [2]) do not fully adhere to the ASM theory. Our own investigation into the algorithm has revealed certain important shortcomings which make it unsuitable for driving the correct interaction between goal and web service choreographies, and helps explain its lack of proper adaptation in existing choreography engine implementations.In previous work [18], we used F-logic [19] for the WSMOcapability specification of web services and goals. A capability involvespre- andpostconditions of web services and goals. Capabilities are used in theservice discovery stage. In the current work, we focus on WSMOinterfaces, which mainly include choreography specification and are used in theservice interaction stage. Our main contributions here can be summarized as (i) rectifying the original ASM-based choreography algorithm, (ii) proposing an F-logic specification of WSMO goal and web service choreographies as an effective alternative to the current specifications in WSML [20] and OCML [21], (iii) implementing the rectified choreography algorithm in Flora-2 [22, 23] with novel technics that adhere to theory of ASMs (missing in other implementations), (iv) validating the implemented Flora-2 engine through several realistic scenarios, (v) developing a visual editor to facilitate the design and deployment of semantic web services in a subset of the Flora-2 language that we adopted as our specification language, and (vi) proving the equivalence of ASMs (also known asevolving algebras [24]) and WSMO choreography specifications (commonly calledevolving ontologies [25]) by providing appropriate mappings between them.The rest of this article is organized as follows. In Section2, the preliminaries are briefly explained, including ASM theory, F-logic, Flora-2, and WSMO choreography concepts, which are needed to understand the subsequent sections. In Section 3, we give the existing WSMO choreography execution algorithm, point out its weaknesses, and present a rectified version. In Section 4, the general form of goal and web service specifications in F-logic is given, as well as the implementation details of the improved algorithm, which works on the specifications. In Section 5, we provide a realistic choreography example and explain it. Section 6 is the discussion, where we describe how our choice of Flora-2 as the specification language helps resolve the data granularity mismatch problem that can occur between the goal and web service. Section 7 contains related work on choreography specification, matching, and execution, with appropriate comparison with our approach. Finally, in Section 8 we have the conclusion and future research directions. In Appendix A in the Supplementary Materials, we illustrate the developed visual editor for semantic web service specification in a subset of Flora-2. In Appendix B in the Supplementary Materials, we give the grammar of the web service and goal specifications in EBNF [26] notation. Appendix C in the Supplementary Materials contains seven more choreography scenario examples, demonstrating the capabilities of the proposed choreography specification and engine. Appendix D in the Supplementary Materials contains a description of the predicates used in the implementation, which itself is available for download at [27]. Lastly, in Appendix E in the Supplementary Materials we describe a scheme for converting JSON content into its Flora-2 equivalent, a step that will be useful in grounding Flora-2 specified semantic web services into RESTful web services.


## 2. Preliminaries

In this section, essential concepts that have been used in this work are briefly reviewed.


### 2.1. Abstract State Machine (ASM)

ASMs or evolving algebras were first introduced by Gurevich [15, 16]. ASM theory says that every algorithm can be modeled as a step-by-step evolving system containing two main components: a state signature which represents the current status of the system and a finite set of transition rules which determine the next state of the system based on the current one. Finite State Machines (FSMs) [28] can be seen as a specific instance of ASMs. An important point about ASMs is that transition rules are applied in parallel at each evolution step and they are categorized into three types:if-rule(-else),forall-rule, andchoose-rule [29].ASMs are generally categorized into Basic ASMs and Multiagent ASMs. The discussion here is based on Basic ASMs, similarly to WSMO which configured and extended Basic ASMs to model choreographies. In WSMO, evolving ontologies (ontologized ASM [30]) are used to represent the state of the choreography, instead of the evolving algebra of ASMs. It turns out that evolving ontologies are equivalent to evolving algebras, and we prove this in Section 3.2. For further reading about ASMs, the reader is referred to [24, 31, 32].


### 2.2. WSMO and WSMO Choreography

Web Service Modeling Ontology (WSMO) is a comprehensive framework that has the aim of enabling automatic service discovery, invocation, and composition [14]. It identifies four major concepts in semantic service oriented architecture:ontology (provides the common terminology between goals and web services),web service (models the functionality of the web service at a high, semantic level),goal (models the request of client at a high, semantic level), andmediator (resolves different types of possible incompatibilities, including process and terminological, between goals and web services).The concept of web service in turn containsnonfunctional properties,ontologies,mediators,capability, andinterface elements. The functionality of a WSMO web service is described by thecapability element which containsprecondition, postcondition,assumption, andeffect.Precondition specifies what the web service requires from the goal before it can start execution.Postcondition specifies what the web service can provide to the client (i.e., goal) upon successful completion of its execution. Assumption is the state of the world which must hold true before the web service can be called.Effect is the change(s) caused to the state of the world through the execution of the web service. A WSMO web service guarantees its postcondition and effect if its precondition and assumption are true. This feature of WSMO web services is used for automatic discovery purposes.Choreography is part of web serviceInterface element which specifies the behavioral interaction of the web service with its client.


### 2.3. F-Logic

Introduced by Kifer and Lausen, Frame Logic [19] or in short F-logic is a formalism that integrates first-order logic and the object-oriented paradigm [19]. Equipped with predicate calculus [33], F-logic can easily model concepts, facts, rules, and specially ontologies in a very declarative fashion and is considered a rule-integrated ontological language [34]. In F-logic, classes and subclasses are modeled as concepts and subconcepts, respectively. Also, data members are represented by attributes and their assigned values. Detailed discussion about F-logic can be found in [35–37].


### 2.4. Flora-2

Flora-2 is a powerful, integrated system based on F-logic, HiLog [38, 39], and Transaction Logic [40]. It offers syntax similar to F-logic and by using the XSB inferencing engine [41], it can do reasoning on the facts and knowledge represented in F-logic or HiLog. The variety and multiplicity of logic and predicate operators make Flora-2 a powerful reasoning system. Moreover, Flora-2 is being continuously extended and developed [42, 43] and it can be integrated with Java through the provided APIs [44]. We use the latest version of Flora-2 [22] to implement a new semantic web service choreography engine.


#### 2.4.1. Flora-2 Syntax Summary

In Table1, some of the more prominent constructs of Flora-2 syntax, which we use in the choreography engine implementation, are given.Table 1
Summary of Flora-2 syntax [45] used in the implementation.
Flora-2 syntax
Meaning
concept[|attribute => type|].
Defines a concept, its attributes, and their types
object[attribute -> value].
Specifies the value of an instance attribute
subconcept::concept.
Defines inheritance between two concepts
object:concept
.
Instance declaration
$
…
Reifies any kind of object in Flora-2
~
Metaunification operator
∖
object
Top-most object in Flora-2
∖
if…
∖
then…
∖
else
If-then-else formula
Predicate(parameters)
A tabled predicate
%
Predicate(parameters)
A nontabled predicate
?variable
Logic variable
?_
Don’t care logic variable
?_name
Don’t care identifiable logic variable
,(
∖
and)
;(
∖
or)
∖
+
Logical AND, Logical OR, Negation as Failure
L
:-
R
Clause definition
!
The cut operator
∖
prolog
Module containing Prolog predefined predicates
∖
btp
Module containing embedded base-types or predicates
setof
{
?X
∣
any formula containing variable ?X}
Generates the list of all X’s such that the formula where it occurs as a free variable is true
//comment
/
c
o
m
m
e
n
t
∗
∗
/
Comments


#### 2.4.2. Flora-2 Main, Built-In, and User Modules

Flora-2 keeps knowledge in logical storage places namedmodules. By default, all the information and knowledge is stored in themain module. The user can create an arbitrary number of independent modules for organizing knowledge (referred to asuser-defined modules). Flora-2 also hasbuilt-in modules which contain predefined predicates, such as the ∖prolog module where useful Prolog [46] utility predicates are kept.


## 2.1. Abstract State Machine (ASM)

ASMs or evolving algebras were first introduced by Gurevich [15, 16]. ASM theory says that every algorithm can be modeled as a step-by-step evolving system containing two main components: a state signature which represents the current status of the system and a finite set of transition rules which determine the next state of the system based on the current one. Finite State Machines (FSMs) [28] can be seen as a specific instance of ASMs. An important point about ASMs is that transition rules are applied in parallel at each evolution step and they are categorized into three types:if-rule(-else),forall-rule, andchoose-rule [29].ASMs are generally categorized into Basic ASMs and Multiagent ASMs. The discussion here is based on Basic ASMs, similarly to WSMO which configured and extended Basic ASMs to model choreographies. In WSMO, evolving ontologies (ontologized ASM [30]) are used to represent the state of the choreography, instead of the evolving algebra of ASMs. It turns out that evolving ontologies are equivalent to evolving algebras, and we prove this in Section 3.2. For further reading about ASMs, the reader is referred to [24, 31, 32].


## 2.2. WSMO and WSMO Choreography

Web Service Modeling Ontology (WSMO) is a comprehensive framework that has the aim of enabling automatic service discovery, invocation, and composition [14]. It identifies four major concepts in semantic service oriented architecture:ontology (provides the common terminology between goals and web services),web service (models the functionality of the web service at a high, semantic level),goal (models the request of client at a high, semantic level), andmediator (resolves different types of possible incompatibilities, including process and terminological, between goals and web services).The concept of web service in turn containsnonfunctional properties,ontologies,mediators,capability, andinterface elements. The functionality of a WSMO web service is described by thecapability element which containsprecondition, postcondition,assumption, andeffect.Precondition specifies what the web service requires from the goal before it can start execution.Postcondition specifies what the web service can provide to the client (i.e., goal) upon successful completion of its execution. Assumption is the state of the world which must hold true before the web service can be called.Effect is the change(s) caused to the state of the world through the execution of the web service. A WSMO web service guarantees its postcondition and effect if its precondition and assumption are true. This feature of WSMO web services is used for automatic discovery purposes.Choreography is part of web serviceInterface element which specifies the behavioral interaction of the web service with its client.


## 2.3. F-Logic

Introduced by Kifer and Lausen, Frame Logic [19] or in short F-logic is a formalism that integrates first-order logic and the object-oriented paradigm [19]. Equipped with predicate calculus [33], F-logic can easily model concepts, facts, rules, and specially ontologies in a very declarative fashion and is considered a rule-integrated ontological language [34]. In F-logic, classes and subclasses are modeled as concepts and subconcepts, respectively. Also, data members are represented by attributes and their assigned values. Detailed discussion about F-logic can be found in [35–37].


## 2.4. Flora-2

Flora-2 is a powerful, integrated system based on F-logic, HiLog [38, 39], and Transaction Logic [40]. It offers syntax similar to F-logic and by using the XSB inferencing engine [41], it can do reasoning on the facts and knowledge represented in F-logic or HiLog. The variety and multiplicity of logic and predicate operators make Flora-2 a powerful reasoning system. Moreover, Flora-2 is being continuously extended and developed [42, 43] and it can be integrated with Java through the provided APIs [44]. We use the latest version of Flora-2 [22] to implement a new semantic web service choreography engine.


### 2.4.1. Flora-2 Syntax Summary

In Table1, some of the more prominent constructs of Flora-2 syntax, which we use in the choreography engine implementation, are given.Table 1
Summary of Flora-2 syntax [45] used in the implementation.
Flora-2 syntax
Meaning
concept[|attribute => type|].
Defines a concept, its attributes, and their types
object[attribute -> value].
Specifies the value of an instance attribute
subconcept::concept.
Defines inheritance between two concepts
object:concept
.
Instance declaration
$
…
Reifies any kind of object in Flora-2
~
Metaunification operator
∖
object
Top-most object in Flora-2
∖
if…
∖
then…
∖
else
If-then-else formula
Predicate(parameters)
A tabled predicate
%
Predicate(parameters)
A nontabled predicate
?variable
Logic variable
?_
Don’t care logic variable
?_name
Don’t care identifiable logic variable
,(
∖
and)
;(
∖
or)
∖
+
Logical AND, Logical OR, Negation as Failure
L
:-
R
Clause definition
!
The cut operator
∖
prolog
Module containing Prolog predefined predicates
∖
btp
Module containing embedded base-types or predicates
setof
{
?X
∣
any formula containing variable ?X}
Generates the list of all X’s such that the formula where it occurs as a free variable is true
//comment
/
c
o
m
m
e
n
t
∗
∗
/
Comments


### 2.4.2. Flora-2 Main, Built-In, and User Modules

Flora-2 keeps knowledge in logical storage places namedmodules. By default, all the information and knowledge is stored in themain module. The user can create an arbitrary number of independent modules for organizing knowledge (referred to asuser-defined modules). Flora-2 also hasbuilt-in modules which contain predefined predicates, such as the ∖prolog module where useful Prolog [46] utility predicates are kept.


## 2.4.1. Flora-2 Syntax Summary

In Table1, some of the more prominent constructs of Flora-2 syntax, which we use in the choreography engine implementation, are given.Table 1
Summary of Flora-2 syntax [45] used in the implementation.
Flora-2 syntax
Meaning
concept[|attribute => type|].
Defines a concept, its attributes, and their types
object[attribute -> value].
Specifies the value of an instance attribute
subconcept::concept.
Defines inheritance between two concepts
object:concept
.
Instance declaration
$
…
Reifies any kind of object in Flora-2
~
Metaunification operator
∖
object
Top-most object in Flora-2
∖
if…
∖
then…
∖
else
If-then-else formula
Predicate(parameters)
A tabled predicate
%
Predicate(parameters)
A nontabled predicate
?variable
Logic variable
?_
Don’t care logic variable
?_name
Don’t care identifiable logic variable
,(
∖
and)
;(
∖
or)
∖
+
Logical AND, Logical OR, Negation as Failure
L
:-
R
Clause definition
!
The cut operator
∖
prolog
Module containing Prolog predefined predicates
∖
btp
Module containing embedded base-types or predicates
setof
{
?X
∣
any formula containing variable ?X}
Generates the list of all X’s such that the formula where it occurs as a free variable is true
//comment
/
c
o
m
m
e
n
t
∗
∗
/
Comments


## 2.4.2. Flora-2 Main, Built-In, and User Modules

Flora-2 keeps knowledge in logical storage places namedmodules. By default, all the information and knowledge is stored in themain module. The user can create an arbitrary number of independent modules for organizing knowledge (referred to asuser-defined modules). Flora-2 also hasbuilt-in modules which contain predefined predicates, such as the ∖prolog module where useful Prolog [46] utility predicates are kept.


## 3. ASM-Based Choreography in WSMO

The state-based model of WSMO choreography is inspired by ASM theory. Choreography working group has chosen ASM because of the following features [47]:(i)
Minimality: ASMs are based on a small assortment of modeling primitives.(ii)
Expressivity: ASMs can model arbitrary computations.(iii)
Formality: ASMs provide a formal framework to express dynamics.Moreover, steps of evolution in ASM match the stepwise nature of interaction between a web service and its users.To apply ASM theory in practice, WSMO choreography authors modified Basic-ASM concepts in several aspects. The concept of signature in ASM has been replaced by the concept of WSMO ontology, which involvesconcepts,attributes,relations, andaxioms. The concept of dynamic functions in ASM has been replaced by dynamic changes of instances and their attribute values, effectively, replacing the concept of evolving algebra [15] by the concept of evolving ontology [25]. This replacement, however, has not been formally justified so far, so in Section 3.2, we prove the equivalence ofevolving algebras andevolving ontologies, filling this gap.


### 3.1. Specification of Choreographies in WSMO

In WSMO, the choreography concept has four components:nonFunctionalProperties,stateSignature,state, andtransitionRules.nonFunctionalProperties refers the nonfunctional properties of the choreography, such as its author, date of creation, and other metainformation about the choreography, described in detail in [48].


#### 3.1.1. The Modes of Concepts

Modes are used to define precise access rights on instances of concepts to be exercised by the environment (the client in this context) and the machine (the web service in this context). Five modes are defined in WSMO choreography, namely,static,controlled,in,shared, andout, which control reading and writing access of the machine and the environment. Table 2 summarizes the encapsulation effect of each mode [14].Table 2
The modes of concept in WSMO choreography.
If the concept is
Static
Controlled
In
Shared
Out
Web Service can
Read
Read/Write
Read
Read/Write
Read/Write
Goal can
Read
-
Read/Write
Read/Write
Read


#### 3.1.2. State

State component of WSMO choreography represents the dynamic part of the ongoing choreography instance and consists of actual objects, that is, instances of concepts, as well as instances of relations. The state is changed through the insertion of new instances, deletion of instances, or the update of attribute values in concept instances.


#### 3.1.3. Transition Rules

In WSMO, transition rules are in the form of the following expressions:(i)
If guardthen do rules.(ii)
Forall variableswith guarddo rules.(iii)
Choose variableswith guarddo rules.In (i), guard should be an arbitrary logic formula without free variables; if the guard is true, then the rules on its right-hand side are executed. In (ii), the list of variables afterForall should be free in the guard and the scope of these variables extend to the rules on the right-hand side. For every value of the variables such that the guard becomes true, the actions on the right-hand side are executed in parallel. In (iii), for only one instantiation of the free variables in the guard (chosen at random), the actions on the right-hand side are executed [49].In accordance with the original ASM definition, all rules at the top level, as well as rules on the right-hand side, are meant to be executed in parallel. Note that, in the case of aForall rule, an extra level of parallelism is introduced through the different instantiations of the variables listed after theForall keyword.Rules on the right-hand side, also calledactions, are categorized into three basic update functions as follows:(i)
Adding a fact(ii)
Deleting a fact(iii)
Updating a fact (changing the values of the attributes).


### 3.2. Relationship between Evolving Algebras (ASMs) and Evolving Ontologies

In ASM theory, functions can be partial and can evolve as time passes. For a function, not only can its previous range change, but also members of the domain that were not mapped to values in the codomain under the function can be mapped to a value at a later stage. For example, iff(a) is 1, f(b) is 2, and f(c) is undefined, after a while (based on the transition rules) f might change in a way that f(a) remains 1, but f(b) is mapped to 3 and f(c) is mapped to 4.Evolving ontologies deal with objects, attributes, and values of attributes, as well as relations. The state of the system at a given moment is determined by the objects that exist at that moment, the specific values of the attributes of each existing object, and instances of relations. Ontologies evolve through the insertion/deletion of objects and relations, as well as updates to the values of object attributes.It turns out that evolving algebras and evolving ontologies are in fact equivalent to each other in the sense that, through appropriate mappings, a choreography engine can simulate ASM, and vice versa. Below, we give a brief formal definition of Abstract State Machines, evolving ontologies, and the mappings between the two that allow each one to simulate the other.Definitions [50]. In an ASM state,domains (also calleduniverses) contain data, with functions defined over the domains. Thesuperuniverse is the union of all domains. Relations are treated as Boolean valued functions, and domains are used interchangeably with characteristic functions (e.g., if b∈A, then A(b) = True). AvocabularyΣ is collection function names. Nullary function names (those with zero parameters) are calledconstants. The pair f,(a1,…,an), where f is a function name and a1,…,an are parameters that the function can be applied to, is called alocation. Every ASM vocabulary is assumed to contain the static constantsundef,True, andFalse. AstateU of the vocabulary Σ consists of (i) thesuperuniverse of U (which we shall call X or U) and (ii)interpretations of the function names in Σ. For any n-ary function name f in Σ, its interpretation fU is a function from Xn into X. If c is a constant of Σ, cU is an element of X.undef is the default value X and represents and undetermined object. The notions ofterms,formulas,substitutions,quantifiers,logical connectives, andinterpretations of terms and formulas are exactly the same as in first-order logic. Eachstate is analgebra in the mathematical sense of the word, with the exception that, for f in Σ, fv1,…,vn=undef is permitted (i.e., functions can be partial). Furthermore, as the ASM is executing its transition rules, function interpretations can change over time, leading to the termevolving algebras. We should note, however, that the update rule in ASMs is of the form f(t1,…,tn)≔tn+1, where both the arguments and result of the function application areterms, notvalues in U. From a logic programming point of view, where we use terms to represent data, we can reasonably assume that U is nothing more than H∞, the Herbrand universe (i.e., the set of all ground terms) [51], and functions really map (tuples of) terms to other terms in H∞.On the ontology side, we haveconcepts (classes in programming language parlance),instances (also calledindividuals) that are members of concepts,attributes that are used to describe properties of instances,relations that relate instances to one another, andaxioms (logic statements that say what is true in the domain of application). C is the set of concepts, T is the set of all terms, I⊆T is the set of object identifıers denoting instances, R is the set of relation names, and A is the set of attributes. The termevolving ontologies comes about because update rules are used to change the values of object attributes and add/delete relation or concept instances to/from theworking memory to obtain a modified working memory. The complete contents of the working memory represent a state.


#### 3.2.1. Simulation of Choreography Engine Execution via ASM

One way to view members ofA is as functions with domain I and codomain T; that is, a∈A:I→T. Since I⊆T, it is also true that a∈A:T→T, with the provision thatife∈T-IthenAe=undef; that is, A is not defined for elements of T that are not in I. For any ontology with attribute set A, the actions of the choreography execution engine can be simulated by an ASM with vocabulary Σ=R∪A. Table 3 gives the action to be performed by an ASM that simulates the choreography engine execution. Remember that predicates in ASMs can be represented as Boolean valued functions.Table 3
Simulating a move of the choreography engine with an ASM.
Choreography engine action
ASM action
Insertion ofb[a->c]
a(b)
≔
c
Deletion ofb[a->c]
a(b)
≔
undef
Update of thea attribute of b to value c
a(b)
≔
c
Insertion of relation instancer(a1,…,an)
r(
a
1
,
…
,
a
n
)
≔
True
Deletion of relation instancer(a1,…,an)
r(
a
1
,
…
,
a
n
)
≔
FalseDefinition 1.
An ASM stateSA is said tocorrespond to an ontological state SCiff(i)
wheneverb∈I and a∈A and b[a->c] is true in SC, then a∈Σ and a(b)=c in SA,(ii)
wheneverr∈R and ra1,…,an is true in SC, then r∈Σ and r(a1,…,an) = True in SA.Definition 2 (move of an ASM).
σ ~> ρ denotes one step move of an ASM when it goes fromabstract state σ toabstract state ρ. σ  ~>nρ denotes the fact that an ASM goes fromabstract state σ toabstract state ρ in n moves.Definition 3 (move of a choreography engine).
μ =>β denotes one step move of the choreography engine when it goes fromontological state µ toontological state β. μ =>nβ denotes the fact that the choreography engine goes fromontological state µ toontological state β in n moves.Theorem 4 (simulation of choreography engine execution by ASM actions).
Let
σ be a state of an ASM and µ be an ontological state. Let Σ=R∪A. If σ corresponds to µandμ =>nβthenσ  ~>nρandρ corresponds to β, provided that each action of the choreography engine is replaced by its corresponding action as specified in Table 3.Proof.
Straightforward induction can be done on the number of moves performed by the choreography engine (omitted).


#### 3.2.2. Simulation of ASM Execution via Choreography Engine

The execution of any ASM can be simulated by a choreography engine using evolving ontologies. The requirement is that functions need to be represented somehow in the ontology. The reverse of the mapping given in the previous Section3.2.1 (i.e., whenever a(b)=c in SA then ba -> c is true in SC) does not always work, since a function may be n-ary, where n>1. One possibility is to map functions of the ASM to relations of the ontology. Specifically, every n-ary function of the ASM can be considered an (n+1)-ary predicate of the ontology. Another possibility is to have an object calledfunc, with locations as attribute names, and the value associated with the location as the value of the attribute. For example, if fa,b,c=d in the ASM, then funcfa,b,c -> d is its representation in the ontology. We use the second approach, since we can update objects in an atomic manner, but relation instances are not updatable in one step.Definition 5.
An ontological stateSC is said tocorrespond to an ASM state SAiff whenever f∈Σ andf(b1,…,bn)=bn+1 in SA then func∈I and fb1,…,bn∈A and funcfb1,…,bn -> bn+1 is true in SC.Theorem 6 (simulation of ASM execution by choreography actions).
Let
µ be an ontological state and σ be a state of an ASM. Let A={f(a1,…,an)∣(f,(a1,…,an))be a location of the ASM}. Let I=func. If σ  ~>nρandµ corresponds to σthenμ =>nβandβ corresponds to ρ, provided that each action of the ASM is replaced by its corresponding action as specified in Table 4.Table 4
Simulating a move of the ASM with a choreography engine.
ASM action
Choreography engine action
f
b
1
,
…
,
b
n
≔
b
n
+
1
(
b
n
+
1
≠
undef
)
Update thefunc object’sfb1,…,bn attribute to bn+1 (if the attribute fb1,…,bn does not exist for func, it is created in the update procedure)
f
b
1
,
…
,
b
n
≔
undef
Deletefuncfb1,…,bn->?_, where ?_ is a free variable (if fb1,…,bn does not exist in func, nothing is done in the delete procedure)Proof.
Straightforward induction can be done on the number of moves performed by the ASM (omitted).


### 3.3. Choreography Matching Algorithm in WSMO

The original algorithm of WSMO choreography is about validation of a choreography interface run. As such, it provides only indirect operational semantics of how a choreography engine should run. For the sake of completeness, it is given in Algorithm1, exactly as it is in [49]. In the algorithm, an update set isnot consistent if it contains an insertion and a deletion of the same data simultaneously; otherwise it isconsistent. A run isterminated if either (a) there is an update set U associated with Sn, O, and T such that U is not consistent with Sn with respect to O, or (b) there is an update set U associated with Sn, O, and T such that Sn=USn, where USn denotes the state obtained after the actions specified in the update set U are implemented.Algorithm 1:The original WSMO choreography algorithm [49].
A choreography interface runρ is defined as a sequence of states S0,…,Sn.
Given a choreography interfaceCI=(O,T,S) such that S is consistent with O, a
choreography interface runρ=S0,…,Sn is valid for CI iff
(i) S0=S,
(ii) for 0≤i≤n-1,
(a) Si≠Si+1,
(b) U = {add(a)∣a∈Si+1∖Si}∪{delete(a)∣a∈Si∖Si+1} is an update
set associated with Si, O and T,
(c) Si+1 is consistent with O, and
(iii) the run is terminated.
CI: Choreography InterfaceO: Ontology
T: Set of Transition-rulesS: Original State-signature


### 3.4. Problems with the WSMO Choreography Algorithm

The algorithm presented in Section3.3 verifies whether the choreography run is valid without addressing the role of the client of the web service. Indeed, by definition, choreography should model the interactive behavior of a web service from the client’s point of view, which is not truly addressed by the algorithm.This algorithm has three major missing ingredients that make it an incomplete way of specifying client interaction with the web service.(i)
Choreography specification of the goal is completely ignored.(ii)
It is not clear what the initial state (S0) should be. In the context of choreography, it should be state of the world, together with what the client can provide as input through its precondition component.(iii)
Its termination condition happens either when there are no more valid actions to take, or when it reaches a stable state, that is, no more changes are possible to the current state. A terminated run, however, does not allow one to draw any conclusions regarding the suitability of the web services for a given client, since it is possible that the client requirements are not satisfied by the state in which the run terminated (whatever the reason for termination is). On the other hand, suppose a run is infinite, but at the same time an intermediate state reached in the execution is satisfactory from the client’s point of view, at which point the execution should actually stop. This highlights the fact that the present algorithm overlooks the obvious link between thecapability required by the goal and web service choreography.Inability of the present algorithm to determine whether the client and web service are compatible can be summarized with the observation that no formal relationship is established between what the client provides and the initial state of the choreography, as well as the requirements of the client and the termination condition.These deficiencies in the algorithm are rectified in Section3.5 by (i) taking into account the client choreography specification in addition to the web service choreography specification, (ii) establishing the connection between the initial state of the world plus the input provided by the client and initial state, and (iii) defining what asuccessful run is by taking into account the requirements of the client.


### 3.5. Improved Choreography Execution Algorithm

In this section, a modified algorithm for choreography execution is presented that rectifies the deficiencies identified in the original algorithm given in Algorithm1. The rectified algorithm (Algorithm 2) takes into account the pre- and postconditions of the goal, making it stop when the goal can be satisfied with the current state. The original implicit style has been kept in order to highlight the differences better.Algorithm 2:Rectified choreography matching algorithm.
A choreography interface runρ is defined as a sequence of states S0,…,Sn.
Given a choreography interfaceCI = (Ocommon, Twebservice, Tgoal,Sweb_service, Sgoal) such
that bothSwebservice and Sgoal are consistent with Ocommon,a choreography interface
runρ=S0,…,Sn is successful for CI iff:
(i) S0 = Swebservice∪Sgoal∪Ocommon
(ii) for 0≤i≤n-1,
(a) Si≠Si+1,
(b) U = {add(a)∣a∈Si+1\Si∪  {delete(a)∣a∈Si\Si+1 is a consistent update
set associated with Si, Ocommon and Twebservice  ∪  Tgoal,
(c) Si+1 is consistent with Ocommon
(iii) Sn⊨goal.post
(iv) For all k<n, ¬ (Sk⊨goal.post)
CI: Choreography Interface
O
common: Common Ontology, possibly containing concept definitions, instances and axioms
T
webservice: Web Service Choreography Transition rules
T
goal: Goal Choreography Transition-rules
S
w
e
b
s
e
r
v
i
c
e: Local state of the web service, possibly consisting of instances and
axioms contributed to the commonworking memory (WM) of the choreography execution engine
S
goal: Instances implied by the goal pre-condition that are contributed to the common
working memory of the choreography execution engineOur algorithm starts with an initial state consisting of the facts and instances implied by the goal precondition, facts, instances, and axioms contributed by the local state of the web service, as well as the facts, instances, and axioms contained in the common ontology. Significantly, we note that the concept of avalid choreography interface run is replaced by asuccessful choreography interface run. At each iteration, the update set is computed, and provided that it is consistent1, the next state of the system is obtained through the application of the actions in the update set. The execution of the choreography engine terminates successfully at the earliest state which logically implies the goal postcondition. Any other termination signifies failure and can happen if (i) the execution engine reaches a stable state (i.e., the state remains unchanged by the application of the transition rules) which does not logically imply the goal postcondition, or (ii) the update set is not consistent at any stage, or (iii) a state is reached that is not consistent with the common ontology.The differences between the improved algorithm and the original algorithm stand out: the concept of avalid choreography interface run, which says nothing about the actual suitability of the web service to satisfy the goal demand, is abandoned in favor of asuccessful choreography interface run, which does give useful information regarding such suitability. The initial state of the system is linked directly to the input provided by the goal precondition, reflecting the actual state of affairs in the real world, and the final state is linked directly to the postcondition of the goal. Consequently, it becomes possible to show not only that a web service can satisfy the demands of the goal, but also that there is an actual interaction sequence between the client (i.e., goal) and the web service which results in such satisfaction. Furthermore, both goal and web service choreography specifications participate in the choreography execution run.Given the semantic specifications of a goal and web service, as well as imported ontologies, the job of the choreography engine is to determine if asuccessful run is possible.


## 3.1. Specification of Choreographies in WSMO

In WSMO, the choreography concept has four components:nonFunctionalProperties,stateSignature,state, andtransitionRules.nonFunctionalProperties refers the nonfunctional properties of the choreography, such as its author, date of creation, and other metainformation about the choreography, described in detail in [48].


### 3.1.1. The Modes of Concepts

Modes are used to define precise access rights on instances of concepts to be exercised by the environment (the client in this context) and the machine (the web service in this context). Five modes are defined in WSMO choreography, namely,static,controlled,in,shared, andout, which control reading and writing access of the machine and the environment. Table 2 summarizes the encapsulation effect of each mode [14].Table 2
The modes of concept in WSMO choreography.
If the concept is
Static
Controlled
In
Shared
Out
Web Service can
Read
Read/Write
Read
Read/Write
Read/Write
Goal can
Read
-
Read/Write
Read/Write
Read


### 3.1.2. State

State component of WSMO choreography represents the dynamic part of the ongoing choreography instance and consists of actual objects, that is, instances of concepts, as well as instances of relations. The state is changed through the insertion of new instances, deletion of instances, or the update of attribute values in concept instances.


### 3.1.3. Transition Rules

In WSMO, transition rules are in the form of the following expressions:(i)
If guardthen do rules.(ii)
Forall variableswith guarddo rules.(iii)
Choose variableswith guarddo rules.In (i), guard should be an arbitrary logic formula without free variables; if the guard is true, then the rules on its right-hand side are executed. In (ii), the list of variables afterForall should be free in the guard and the scope of these variables extend to the rules on the right-hand side. For every value of the variables such that the guard becomes true, the actions on the right-hand side are executed in parallel. In (iii), for only one instantiation of the free variables in the guard (chosen at random), the actions on the right-hand side are executed [49].In accordance with the original ASM definition, all rules at the top level, as well as rules on the right-hand side, are meant to be executed in parallel. Note that, in the case of aForall rule, an extra level of parallelism is introduced through the different instantiations of the variables listed after theForall keyword.Rules on the right-hand side, also calledactions, are categorized into three basic update functions as follows:(i)
Adding a fact(ii)
Deleting a fact(iii)
Updating a fact (changing the values of the attributes).


## 3.1.1. The Modes of Concepts

Modes are used to define precise access rights on instances of concepts to be exercised by the environment (the client in this context) and the machine (the web service in this context). Five modes are defined in WSMO choreography, namely,static,controlled,in,shared, andout, which control reading and writing access of the machine and the environment. Table 2 summarizes the encapsulation effect of each mode [14].Table 2
The modes of concept in WSMO choreography.
If the concept is
Static
Controlled
In
Shared
Out
Web Service can
Read
Read/Write
Read
Read/Write
Read/Write
Goal can
Read
-
Read/Write
Read/Write
Read


## 3.1.2. State

State component of WSMO choreography represents the dynamic part of the ongoing choreography instance and consists of actual objects, that is, instances of concepts, as well as instances of relations. The state is changed through the insertion of new instances, deletion of instances, or the update of attribute values in concept instances.


## 3.1.3. Transition Rules

In WSMO, transition rules are in the form of the following expressions:(i)
If guardthen do rules.(ii)
Forall variableswith guarddo rules.(iii)
Choose variableswith guarddo rules.In (i), guard should be an arbitrary logic formula without free variables; if the guard is true, then the rules on its right-hand side are executed. In (ii), the list of variables afterForall should be free in the guard and the scope of these variables extend to the rules on the right-hand side. For every value of the variables such that the guard becomes true, the actions on the right-hand side are executed in parallel. In (iii), for only one instantiation of the free variables in the guard (chosen at random), the actions on the right-hand side are executed [49].In accordance with the original ASM definition, all rules at the top level, as well as rules on the right-hand side, are meant to be executed in parallel. Note that, in the case of aForall rule, an extra level of parallelism is introduced through the different instantiations of the variables listed after theForall keyword.Rules on the right-hand side, also calledactions, are categorized into three basic update functions as follows:(i)
Adding a fact(ii)
Deleting a fact(iii)
Updating a fact (changing the values of the attributes).


## 3.2. Relationship between Evolving Algebras (ASMs) and Evolving Ontologies

In ASM theory, functions can be partial and can evolve as time passes. For a function, not only can its previous range change, but also members of the domain that were not mapped to values in the codomain under the function can be mapped to a value at a later stage. For example, iff(a) is 1, f(b) is 2, and f(c) is undefined, after a while (based on the transition rules) f might change in a way that f(a) remains 1, but f(b) is mapped to 3 and f(c) is mapped to 4.Evolving ontologies deal with objects, attributes, and values of attributes, as well as relations. The state of the system at a given moment is determined by the objects that exist at that moment, the specific values of the attributes of each existing object, and instances of relations. Ontologies evolve through the insertion/deletion of objects and relations, as well as updates to the values of object attributes.It turns out that evolving algebras and evolving ontologies are in fact equivalent to each other in the sense that, through appropriate mappings, a choreography engine can simulate ASM, and vice versa. Below, we give a brief formal definition of Abstract State Machines, evolving ontologies, and the mappings between the two that allow each one to simulate the other.Definitions [50]. In an ASM state,domains (also calleduniverses) contain data, with functions defined over the domains. Thesuperuniverse is the union of all domains. Relations are treated as Boolean valued functions, and domains are used interchangeably with characteristic functions (e.g., if b∈A, then A(b) = True). AvocabularyΣ is collection function names. Nullary function names (those with zero parameters) are calledconstants. The pair f,(a1,…,an), where f is a function name and a1,…,an are parameters that the function can be applied to, is called alocation. Every ASM vocabulary is assumed to contain the static constantsundef,True, andFalse. AstateU of the vocabulary Σ consists of (i) thesuperuniverse of U (which we shall call X or U) and (ii)interpretations of the function names in Σ. For any n-ary function name f in Σ, its interpretation fU is a function from Xn into X. If c is a constant of Σ, cU is an element of X.undef is the default value X and represents and undetermined object. The notions ofterms,formulas,substitutions,quantifiers,logical connectives, andinterpretations of terms and formulas are exactly the same as in first-order logic. Eachstate is analgebra in the mathematical sense of the word, with the exception that, for f in Σ, fv1,…,vn=undef is permitted (i.e., functions can be partial). Furthermore, as the ASM is executing its transition rules, function interpretations can change over time, leading to the termevolving algebras. We should note, however, that the update rule in ASMs is of the form f(t1,…,tn)≔tn+1, where both the arguments and result of the function application areterms, notvalues in U. From a logic programming point of view, where we use terms to represent data, we can reasonably assume that U is nothing more than H∞, the Herbrand universe (i.e., the set of all ground terms) [51], and functions really map (tuples of) terms to other terms in H∞.On the ontology side, we haveconcepts (classes in programming language parlance),instances (also calledindividuals) that are members of concepts,attributes that are used to describe properties of instances,relations that relate instances to one another, andaxioms (logic statements that say what is true in the domain of application). C is the set of concepts, T is the set of all terms, I⊆T is the set of object identifıers denoting instances, R is the set of relation names, and A is the set of attributes. The termevolving ontologies comes about because update rules are used to change the values of object attributes and add/delete relation or concept instances to/from theworking memory to obtain a modified working memory. The complete contents of the working memory represent a state.


### 3.2.1. Simulation of Choreography Engine Execution via ASM

One way to view members ofA is as functions with domain I and codomain T; that is, a∈A:I→T. Since I⊆T, it is also true that a∈A:T→T, with the provision thatife∈T-IthenAe=undef; that is, A is not defined for elements of T that are not in I. For any ontology with attribute set A, the actions of the choreography execution engine can be simulated by an ASM with vocabulary Σ=R∪A. Table 3 gives the action to be performed by an ASM that simulates the choreography engine execution. Remember that predicates in ASMs can be represented as Boolean valued functions.Table 3
Simulating a move of the choreography engine with an ASM.
Choreography engine action
ASM action
Insertion ofb[a->c]
a(b)
≔
c
Deletion ofb[a->c]
a(b)
≔
undef
Update of thea attribute of b to value c
a(b)
≔
c
Insertion of relation instancer(a1,…,an)
r(
a
1
,
…
,
a
n
)
≔
True
Deletion of relation instancer(a1,…,an)
r(
a
1
,
…
,
a
n
)
≔
FalseDefinition 1.
An ASM stateSA is said tocorrespond to an ontological state SCiff(i)
wheneverb∈I and a∈A and b[a->c] is true in SC, then a∈Σ and a(b)=c in SA,(ii)
wheneverr∈R and ra1,…,an is true in SC, then r∈Σ and r(a1,…,an) = True in SA.Definition 2 (move of an ASM).
σ ~> ρ denotes one step move of an ASM when it goes fromabstract state σ toabstract state ρ. σ  ~>nρ denotes the fact that an ASM goes fromabstract state σ toabstract state ρ in n moves.Definition 3 (move of a choreography engine).
μ =>β denotes one step move of the choreography engine when it goes fromontological state µ toontological state β. μ =>nβ denotes the fact that the choreography engine goes fromontological state µ toontological state β in n moves.Theorem 4 (simulation of choreography engine execution by ASM actions).
Let
σ be a state of an ASM and µ be an ontological state. Let Σ=R∪A. If σ corresponds to µandμ =>nβthenσ  ~>nρandρ corresponds to β, provided that each action of the choreography engine is replaced by its corresponding action as specified in Table 3.Proof.
Straightforward induction can be done on the number of moves performed by the choreography engine (omitted).


### 3.2.2. Simulation of ASM Execution via Choreography Engine

The execution of any ASM can be simulated by a choreography engine using evolving ontologies. The requirement is that functions need to be represented somehow in the ontology. The reverse of the mapping given in the previous Section3.2.1 (i.e., whenever a(b)=c in SA then ba -> c is true in SC) does not always work, since a function may be n-ary, where n>1. One possibility is to map functions of the ASM to relations of the ontology. Specifically, every n-ary function of the ASM can be considered an (n+1)-ary predicate of the ontology. Another possibility is to have an object calledfunc, with locations as attribute names, and the value associated with the location as the value of the attribute. For example, if fa,b,c=d in the ASM, then funcfa,b,c -> d is its representation in the ontology. We use the second approach, since we can update objects in an atomic manner, but relation instances are not updatable in one step.Definition 5.
An ontological stateSC is said tocorrespond to an ASM state SAiff whenever f∈Σ andf(b1,…,bn)=bn+1 in SA then func∈I and fb1,…,bn∈A and funcfb1,…,bn -> bn+1 is true in SC.Theorem 6 (simulation of ASM execution by choreography actions).
Let
µ be an ontological state and σ be a state of an ASM. Let A={f(a1,…,an)∣(f,(a1,…,an))be a location of the ASM}. Let I=func. If σ  ~>nρandµ corresponds to σthenμ =>nβandβ corresponds to ρ, provided that each action of the ASM is replaced by its corresponding action as specified in Table 4.Table 4
Simulating a move of the ASM with a choreography engine.
ASM action
Choreography engine action
f
b
1
,
…
,
b
n
≔
b
n
+
1
(
b
n
+
1
≠
undef
)
Update thefunc object’sfb1,…,bn attribute to bn+1 (if the attribute fb1,…,bn does not exist for func, it is created in the update procedure)
f
b
1
,
…
,
b
n
≔
undef
Deletefuncfb1,…,bn->?_, where ?_ is a free variable (if fb1,…,bn does not exist in func, nothing is done in the delete procedure)Proof.
Straightforward induction can be done on the number of moves performed by the ASM (omitted).


## 3.2.1. Simulation of Choreography Engine Execution via ASM

One way to view members ofA is as functions with domain I and codomain T; that is, a∈A:I→T. Since I⊆T, it is also true that a∈A:T→T, with the provision thatife∈T-IthenAe=undef; that is, A is not defined for elements of T that are not in I. For any ontology with attribute set A, the actions of the choreography execution engine can be simulated by an ASM with vocabulary Σ=R∪A. Table 3 gives the action to be performed by an ASM that simulates the choreography engine execution. Remember that predicates in ASMs can be represented as Boolean valued functions.Table 3
Simulating a move of the choreography engine with an ASM.
Choreography engine action
ASM action
Insertion ofb[a->c]
a(b)
≔
c
Deletion ofb[a->c]
a(b)
≔
undef
Update of thea attribute of b to value c
a(b)
≔
c
Insertion of relation instancer(a1,…,an)
r(
a
1
,
…
,
a
n
)
≔
True
Deletion of relation instancer(a1,…,an)
r(
a
1
,
…
,
a
n
)
≔
FalseDefinition 1.
An ASM stateSA is said tocorrespond to an ontological state SCiff(i)
wheneverb∈I and a∈A and b[a->c] is true in SC, then a∈Σ and a(b)=c in SA,(ii)
wheneverr∈R and ra1,…,an is true in SC, then r∈Σ and r(a1,…,an) = True in SA.Definition 2 (move of an ASM).
σ ~> ρ denotes one step move of an ASM when it goes fromabstract state σ toabstract state ρ. σ  ~>nρ denotes the fact that an ASM goes fromabstract state σ toabstract state ρ in n moves.Definition 3 (move of a choreography engine).
μ =>β denotes one step move of the choreography engine when it goes fromontological state µ toontological state β. μ =>nβ denotes the fact that the choreography engine goes fromontological state µ toontological state β in n moves.Theorem 4 (simulation of choreography engine execution by ASM actions).
Let
σ be a state of an ASM and µ be an ontological state. Let Σ=R∪A. If σ corresponds to µandμ =>nβthenσ  ~>nρandρ corresponds to β, provided that each action of the choreography engine is replaced by its corresponding action as specified in Table 3.Proof.
Straightforward induction can be done on the number of moves performed by the choreography engine (omitted).


## 3.2.2. Simulation of ASM Execution via Choreography Engine

The execution of any ASM can be simulated by a choreography engine using evolving ontologies. The requirement is that functions need to be represented somehow in the ontology. The reverse of the mapping given in the previous Section3.2.1 (i.e., whenever a(b)=c in SA then ba -> c is true in SC) does not always work, since a function may be n-ary, where n>1. One possibility is to map functions of the ASM to relations of the ontology. Specifically, every n-ary function of the ASM can be considered an (n+1)-ary predicate of the ontology. Another possibility is to have an object calledfunc, with locations as attribute names, and the value associated with the location as the value of the attribute. For example, if fa,b,c=d in the ASM, then funcfa,b,c -> d is its representation in the ontology. We use the second approach, since we can update objects in an atomic manner, but relation instances are not updatable in one step.Definition 5.
An ontological stateSC is said tocorrespond to an ASM state SAiff whenever f∈Σ andf(b1,…,bn)=bn+1 in SA then func∈I and fb1,…,bn∈A and funcfb1,…,bn -> bn+1 is true in SC.Theorem 6 (simulation of ASM execution by choreography actions).
Let
µ be an ontological state and σ be a state of an ASM. Let A={f(a1,…,an)∣(f,(a1,…,an))be a location of the ASM}. Let I=func. If σ  ~>nρandµ corresponds to σthenμ =>nβandβ corresponds to ρ, provided that each action of the ASM is replaced by its corresponding action as specified in Table 4.Table 4
Simulating a move of the ASM with a choreography engine.
ASM action
Choreography engine action
f
b
1
,
…
,
b
n
≔
b
n
+
1
(
b
n
+
1
≠
undef
)
Update thefunc object’sfb1,…,bn attribute to bn+1 (if the attribute fb1,…,bn does not exist for func, it is created in the update procedure)
f
b
1
,
…
,
b
n
≔
undef
Deletefuncfb1,…,bn->?_, where ?_ is a free variable (if fb1,…,bn does not exist in func, nothing is done in the delete procedure)Proof.
Straightforward induction can be done on the number of moves performed by the ASM (omitted).


## 3.3. Choreography Matching Algorithm in WSMO

The original algorithm of WSMO choreography is about validation of a choreography interface run. As such, it provides only indirect operational semantics of how a choreography engine should run. For the sake of completeness, it is given in Algorithm1, exactly as it is in [49]. In the algorithm, an update set isnot consistent if it contains an insertion and a deletion of the same data simultaneously; otherwise it isconsistent. A run isterminated if either (a) there is an update set U associated with Sn, O, and T such that U is not consistent with Sn with respect to O, or (b) there is an update set U associated with Sn, O, and T such that Sn=USn, where USn denotes the state obtained after the actions specified in the update set U are implemented.Algorithm 1:The original WSMO choreography algorithm [49].
A choreography interface runρ is defined as a sequence of states S0,…,Sn.
Given a choreography interfaceCI=(O,T,S) such that S is consistent with O, a
choreography interface runρ=S0,…,Sn is valid for CI iff
(i) S0=S,
(ii) for 0≤i≤n-1,
(a) Si≠Si+1,
(b) U = {add(a)∣a∈Si+1∖Si}∪{delete(a)∣a∈Si∖Si+1} is an update
set associated with Si, O and T,
(c) Si+1 is consistent with O, and
(iii) the run is terminated.
CI: Choreography InterfaceO: Ontology
T: Set of Transition-rulesS: Original State-signature


## 3.4. Problems with the WSMO Choreography Algorithm

The algorithm presented in Section3.3 verifies whether the choreography run is valid without addressing the role of the client of the web service. Indeed, by definition, choreography should model the interactive behavior of a web service from the client’s point of view, which is not truly addressed by the algorithm.This algorithm has three major missing ingredients that make it an incomplete way of specifying client interaction with the web service.(i)
Choreography specification of the goal is completely ignored.(ii)
It is not clear what the initial state (S0) should be. In the context of choreography, it should be state of the world, together with what the client can provide as input through its precondition component.(iii)
Its termination condition happens either when there are no more valid actions to take, or when it reaches a stable state, that is, no more changes are possible to the current state. A terminated run, however, does not allow one to draw any conclusions regarding the suitability of the web services for a given client, since it is possible that the client requirements are not satisfied by the state in which the run terminated (whatever the reason for termination is). On the other hand, suppose a run is infinite, but at the same time an intermediate state reached in the execution is satisfactory from the client’s point of view, at which point the execution should actually stop. This highlights the fact that the present algorithm overlooks the obvious link between thecapability required by the goal and web service choreography.Inability of the present algorithm to determine whether the client and web service are compatible can be summarized with the observation that no formal relationship is established between what the client provides and the initial state of the choreography, as well as the requirements of the client and the termination condition.These deficiencies in the algorithm are rectified in Section3.5 by (i) taking into account the client choreography specification in addition to the web service choreography specification, (ii) establishing the connection between the initial state of the world plus the input provided by the client and initial state, and (iii) defining what asuccessful run is by taking into account the requirements of the client.


## 3.5. Improved Choreography Execution Algorithm

In this section, a modified algorithm for choreography execution is presented that rectifies the deficiencies identified in the original algorithm given in Algorithm1. The rectified algorithm (Algorithm 2) takes into account the pre- and postconditions of the goal, making it stop when the goal can be satisfied with the current state. The original implicit style has been kept in order to highlight the differences better.Algorithm 2:Rectified choreography matching algorithm.
A choreography interface runρ is defined as a sequence of states S0,…,Sn.
Given a choreography interfaceCI = (Ocommon, Twebservice, Tgoal,Sweb_service, Sgoal) such
that bothSwebservice and Sgoal are consistent with Ocommon,a choreography interface
runρ=S0,…,Sn is successful for CI iff:
(i) S0 = Swebservice∪Sgoal∪Ocommon
(ii) for 0≤i≤n-1,
(a) Si≠Si+1,
(b) U = {add(a)∣a∈Si+1\Si∪  {delete(a)∣a∈Si\Si+1 is a consistent update
set associated with Si, Ocommon and Twebservice  ∪  Tgoal,
(c) Si+1 is consistent with Ocommon
(iii) Sn⊨goal.post
(iv) For all k<n, ¬ (Sk⊨goal.post)
CI: Choreography Interface
O
common: Common Ontology, possibly containing concept definitions, instances and axioms
T
webservice: Web Service Choreography Transition rules
T
goal: Goal Choreography Transition-rules
S
w
e
b
s
e
r
v
i
c
e: Local state of the web service, possibly consisting of instances and
axioms contributed to the commonworking memory (WM) of the choreography execution engine
S
goal: Instances implied by the goal pre-condition that are contributed to the common
working memory of the choreography execution engineOur algorithm starts with an initial state consisting of the facts and instances implied by the goal precondition, facts, instances, and axioms contributed by the local state of the web service, as well as the facts, instances, and axioms contained in the common ontology. Significantly, we note that the concept of avalid choreography interface run is replaced by asuccessful choreography interface run. At each iteration, the update set is computed, and provided that it is consistent1, the next state of the system is obtained through the application of the actions in the update set. The execution of the choreography engine terminates successfully at the earliest state which logically implies the goal postcondition. Any other termination signifies failure and can happen if (i) the execution engine reaches a stable state (i.e., the state remains unchanged by the application of the transition rules) which does not logically imply the goal postcondition, or (ii) the update set is not consistent at any stage, or (iii) a state is reached that is not consistent with the common ontology.The differences between the improved algorithm and the original algorithm stand out: the concept of avalid choreography interface run, which says nothing about the actual suitability of the web service to satisfy the goal demand, is abandoned in favor of asuccessful choreography interface run, which does give useful information regarding such suitability. The initial state of the system is linked directly to the input provided by the goal precondition, reflecting the actual state of affairs in the real world, and the final state is linked directly to the postcondition of the goal. Consequently, it becomes possible to show not only that a web service can satisfy the demands of the goal, but also that there is an actual interaction sequence between the client (i.e., goal) and the web service which results in such satisfaction. Furthermore, both goal and web service choreography specifications participate in the choreography execution run.Given the semantic specifications of a goal and web service, as well as imported ontologies, the job of the choreography engine is to determine if asuccessful run is possible.


## 4. Implementing the Improved Choreography Algorithm in Flora-2

In this section, we present the specification of semantic choreographies and implementation of the improved choreography algorithm in Flora-2. It has been tested on Flora-2 Reasoner 1.2, which is available since 2017-01-30 (rev: 1258b) [22], running on Microsoft Windows 7 (64-bit).The terms below are used in explanations in the following sections:(i)
Working memory (WM) is the main place for storing the state of the choreography. It keeps the whole knowledge produced by the choreography run in real time. The knowledge can be shrunk, expanded, and altered.(ii)
Choreography round is the sequence of actions: (i) starting with the current state of WM, (ii) determining which rules are applicable to this current state, (iii) determining the changes to WM that the application of these rules will cause, and (iv) in case there is no contradiction in the changes (to be explained later), actually implementing those changes in the current WM, leading to a new WM.(iii)
Delta Working Memory (ΔWM) is a temporary storage place for actions to be carried out on WM at each choreography round.


### 4.1. Semantic Specification of Goal and Web Service in Flora-2

As in WSMO, our Flora-2 specifications for goal and web service are composed of the elementsontology,capability, andchoreography.Ontology contains frames and relations that represent knowledge used by the web service and goal.Capability element encloses two subelements,pre andpost, which represent pre- and postconditions. Precondition of the goal can contain conjunctions of nonnegated frames and relations. Postcondition of the goal can be an F-logic expression (including all the logical connectives). Postcondition of the web service can contain conjunctions of nonnegated frames and relations. Precondition of the web service can be an F-logic expression (including all the logical connectives). Note the similarity between the precondition of the goal and the postcondition of the web service, as well as the similarity between the postcondition of the goal and the precondition of the web service.Choreography element is modeled by a set of transition rules. Each rule is specified by ruleId:ruleType  -> ruleBody. Goal’s ruleId is in form of gRule(OID) and web service’s ruleId is in form of wsRule(OID), where OID is any Flora-2 object identifier and is used as a label for the rule. ruleType can be either ForallRule or ChooseRule. ruleBody is a reified Flora-2 implication shown by anif-then(-else)2 statement. The implication antecedent (we refer to it as left-hand side) can be an F-logic expression, and the implication consequent (we refer to it as right-hand side) contains a set of update functions (actions). Box 1 depicts the general form of a goal specification. Specification of web services is also similar.Box 1:General form of goal specification in Flora-2.
goalName
:Goal.
goalName
[
importOntology
->
address of local ontology
,
capability ->
$
pre ->
$  Conjunction of frames and predicates  ,
post ->
$  F-logic expression
,
gRule
(
R01
):
ForallRule
->
$
∖
if (
F-logic expression
)
∖then (  Actions),
gRule
(
R02
):
ChooseRule
->
$
∖
if (  F-logic expression)
∖
then (
Actions
)
,
⋮
].AppendixB in the Supplementary Materials contains the EBNF grammar of goal and web service specifications.


### 4.2. Proposed Architecture

In this section, we describe the architecture of our choreography engine.


#### 4.2.1. Modules of the System

Our Flora-2 solution for implementing the choreography algorithm utilizes themain module and two Flora-2 user modules:WM for keeping the current state signature of the choreography andDeltaWM for keeping the actions for modifying the current state into a new state. Themain module contains the declaration of concepts, instances, and their modes provided by web service and goal, as well as the code for the choreography engine. These three modules (i.e.,main,WM, andDeltaWM) are interconnected, as shown in Figure 1.Figure 1
Architectural view of the choreography engine.


#### 4.2.2. Delta Working Memory (ΔWM): Realizing ASM Parallelism

An auxiliary and transient user module named Delta Working Memory (ΔWM) is used to temporarily keep single choreography round updating actions that should be applied to the main knowledge-base (WM). In each choreography round, all the updates are aggregated into ΔWM and then ΔWM is checked whether there exists any contradiction among the requested actions (explained below). If no contradiction is detected, then all the updates are carried out on the WM, evolving it into a new conflict-free state.


#### 4.2.3. Deterministic Choreography and Contradiction

As mentioned before, the transition rules must be applied in parallel. In the absence of any consistency checking, the rules can do contradictory actions which should be prevented.The three kinds of contradiction that can occur in a choreography round are as follows [1]:(i)
Inserting and deleting/updating the same knowledge simultaneously(ii)
Updating knowledge which does not exist(iii)
Deleting knowledge which does not exist.It is clear that such contradictory actions must be detected and the choreography execution must be stopped. In the case of nonexistent knowledge, it makes no sense to remove or modify it. In the case of simultaneous insertion/deletion of the same knowledge, if the choreography run is continued, then it becomes nondeterministic in an unintended way: even though theoretically updates are done in parallel, in reality they have to be done in a serial fashion, and the order in which they are carried out leads to different WM states.In each choreography round, in addition to testing for the above-mentioned issues, checking for any violation on the modes of concepts (explained in Section3.1.1) is performed as well. If one of the participants wants to do an action on a concept which violates the concept’s access mode, that action is prevented, leading to choreography execution failure.


### 4.3. Major Predicates of the Choreography Engine3

The main process is started through a call to%start predicate which is shown in Listing 1. The choreography engine execution begins with a call to the %initializations predicate on line (2), which currently resets the seed of the random number generator that is used to process thechoose rule type. On line (3), goal and web service rules are checked for mode violations before the choreography rounds start. On lines (4) and (5), the modulesWM andDeltaWM are created if they do not already exist. On lines (6) and (7), local ontologies of the goal and web service are loaded into WM. On line (8), the goal precondition is loaded into WM, becoming part of the initial state of the choreography run, followed by a call to the predicate %runChoreogarphy on line (9) which tries to satisfy the goal postcondition through repeated application of goal and web service transition rules.Listing 1:The top-level predicate of the choreography engine.
(1)   %start(?goal,?WS)  :-
(2)
%
initializations,
(3)
%
preProcessCheckings(?goal,?WS),
(4)
%
prepareModule
(WM),
(5)
%
prepareModule
(
DeltaWM
),
(6)
%
importOntology(?goal,WM),
(7)
%
importOntology
(?WS,WM),
(8)
%
insertGoalPre(?goal,WM),
(9)
%
runChoreography(?goal,?WS).%
runChoreography implements the improved choreography algorithm given in Section 3.5, employing recursion instead of iteration. The definition of the %runChoreography predicate is given in Listing 2. It attempts first to prove the goal postcondition with the current state of WM in lines (1)–(3); the cut (!) operator on line (2) prevents backtracking and a success message is shown to the user on line (3). If the goal postcondition is not satisfied, then the second definition of %runChoreography is called: ΔWM is emptied on line (5); web service and goal rules are applied, populating ΔWM with pending actions to be performed on the WM (lines (6) and (7)). On lines (8)–(11), ΔWM is checked for consistency (line (8)) as well as whether pending actions result in a new state of WM (line (10)). In the case of inconsistent changes or no change to WM, execution is stopped to prevent infinite recursion and a failure message is reported (lines (9) and (11)). Otherwise, the actions in ΔWM are applied to WM to obtain an updated WM (line (12)), and the process is repeated through a recursive call to %runChoreography (line (13)).Listing 2:
%
runChoreography predicate.
(1)
%
runChoreography(?goal, ?WS)  :-
(2)
%
proveGoalPost(?goal),
!,
(3)
%
watchln
([
＇
Success!
＇
-?goal-
＇
and
＇
-?WS-
＇
are
＇
-
＇
choreographed!
＇
]).
(4)
%
runChoreography(?goal, ?WS):-
(5)
%
eraseModule(DeltaWM),
(6)
%
runWsRules(?WS),
(7)
%
runGoalRules(?goal),
(8)
(  (%contradictory(WM,DeltaWM), !,
(9)
%
watchln
(
＇
Choreography failed due to CONTRADICTION.
＇
) )
∖
or
(10)
(  ∖+%deltaMakesAChange(WM,DeltaWM), !,
(11)
%
watchln(
＇
Choreography failed due to NO CHANGE.
＇
) )
∖
or
(12)
(  %mergeDeltaIntoWM,
(13)
%
runChoreography(?goal,?WS) )).


### 4.4. Running (Firing) the Rules

One of the key features of ASMs is that rules should be fired in parallel. We realize this by placing all the insertion, deletion, and update actions on the right-hand sides of the rules that match the current WM into ΔWM, checking them for consistency, and then applying them to the previous WM to get an updated WM. The predicates%deltaInsert, %deltaDelete, and %deltaUpdate represent tentative changes to WM, not actual ones, until they are verified to not cause any conflicts.Listing3 contains the predicates for running goal and web service rules. The Flora-2 setof operator is used to iterate over all rules in the choreography specification (lines (2), (5), (9), and (12)). In the case offorall rules, if the rule antecedent contains only ground facts, it models the ASMif-then transition rule type. If the antecedent contains free variables, it acts like the ASMforall transition rule type. In the case of achoose rule, the predicate %invokeChoose randomly selects exactly one ground instance of the free variables existing in the antecedent of the rule.Listing 3:Running the goal and web service rules.
(1)
%
runWsRules
(?WS)  :-
(2)
?_Temp =
setof
?ruleID
∣
(3)
?
WS:WebService
[
wsRule
(?
ruleID
):
ForallRule
->  ?ruleBody],
(4)
%
invoke(WEBSERVICE,  ?ruleBody),
(5)
?_Temp2 =
setof
?ruleID
∣
(6)
?
WS:WebService
[
wsRule
(?
ruleID
):
ChooseRule
-> ?
ruleBody
],
(7)
%
invokeChoose(WEBSERVICE,?ruleBody)
.
/
∗
-------------------------------------------------------
/
∗
(8)
%
runGoalRules
(?goal)  :-
(9)
?_Temp =
setof
?ruleID
∣
(10)
?
goal:Goal
[
gRule
(?
ruleID
):
ForallRule
-> ?
ruleBody
],
(11)
%
invoke(GOAL,?
ruleBody
)
,
(12)
?_Temp2 =
setof
?ruleID
∣
(13)
?
goal:Goal
[
gRule
(?
ruleID
):
ChooseRule
-> ?
ruleBody
],
(14)
%
invokeChoose(GOAL,?ruleBody)
.


### 4.5. Contradictions in Applying the Rules

Checks for contradictory actions are implemented by the definition of the predicate%contradictory in Listing 4. In lines (1)–(3), simultaneous insertion and deletion of the same item are detected; in lines (4)–(6), deletion of a nonexistent item is detected; finally in lines (7)-(8), update of a nonexistent item is detected.Listing 4:Contradictory cases.
(1)   %contradictory(?WM, ?DeltaWM)  :-
(2)
ins_action
(?A1)@?
DeltaWM
,
del_action
(?A2)@?
DeltaWM
,
(3)
%
contained(?X1,?A1),
%
contained(?X2,?A2),?X1 = ?X2,!.
(4)   %contradictory(?WM, ?DeltaWM)  :-
(5)
del_action
(?A)@?
DeltaWM
,
(6)
%
convertReifiedObjectModule(?A, ?
DeltaWM
, ?WM, ?
A_new
),
∖
+ ?
A_new
@?WM.
(7)   %contradictory(?WM, ?DeltaWM)  :-
(8)
update_action
(?
objOld
,?
objNew
)@?
DeltaWM
,
∖
+ ?
objOld
@?WM.


### 4.6. Access Control to Objects of Different Types

ASMs define access control modes for object manipulation. In the implementation, this access control has been enforced by checking whether a given manipulation is legal or not. This depends on the actor of the manipulation. For example, if an object hasin mode, then only a goal can change its attributes. While invoking the rules belonging to the goal or web service, the legality of the access to the object is verified before the real action.Listing5 depicts a part of the implementation of access control for a goal. Before the rule is tested against the current WM, its concepts and user predicates on its left-hand side and right-hand side are extracted through the %extractConcepts, %extractPredicates, and %filterOutPredicates predicates (lines (4)–(6)), and access rights of the goal are verified for those concepts via %checkAllFramesModes and %checkAllPredicatesModes (lines (7), (10), (18), and (21)). If a concept is on the right-hand side of a rule, the goal must have write access to it. On the other hand, if it is on the left-hand side, only read access is enough.Listing 5:Checking access mode.
(1)
%
check(?
gOrWs
,?X)  :-
(2)
?X ~
$
∖
if ?Y
∖
then ?Z
, !,
(3)
%
reformatToString
(?Y, ?
YStr
),
(4)
%
extractConcepts
(?
YStr
,
[
]
, ?
conceptsInY
),
(5)
%
extractPredicates(?YStr,
[
]
, ?termList1),
(6)
%
filterOutPredicates(?termList1,
[
]
,  ?predicatesInY),
(7)
∖
if (
∖
+
%
checkAllFramesModes
(?gOrWs,READ,?conceptsInY))
∖
then
(8)
(
writeln
([
＇
Error: Illegal access mode in
＇
-?
gOrWs
])@
∖
prolog,!,
(9)
∖
false),
(10)
∖
if (
∖
+
%
checkAllPredicatesModes
(?gOrWs,READ,?predicatesInY))
∖
then
(11)
(
writeln
([
＇
Error: Illegal access mode in
＇
-?
gOrWs
])@
∖
prolog,!,
(12)
∖
false),
(13)
%
decomposeRHS
(?Z,
[
]
, ?
allFsOrPs
),
(14)
%
reformatToString(?allFsOrPs, ?
allFsOrPsStr
),
(15)
%
extractConcepts(?allFsOrPsStr,
[
]
, ?
conceptsInZ
),
(16)
%
extractPredicates(?allFsOrPsStr,
[
]
, ?temp),
(17)
%
filterOutPredicates(?temp,
[
]
, ?
predicatesInZ
),
(18)
∖
if (
∖
+
%
checkAllFramesModes
(?gOrWs,WRITE,?conceptsInZ))
∖
then
(19)
(
writeln
([
＇
Error: Illegal access mode in
＇
-?
gOrWs
])@
∖
prolog,!,
(20)
∖
false),
(21)
∖
if (
∖
+
%
checkAllPredicatesModes
(?gOrWs,WRITE,?predicatesInZ))
∖
then
(22)
(
writeln
([
＇
Error: Illegal access in  ＇-?gOrWs])@∖prolog,!,
(23)
∖
false).
/
∗
-------------------------------------------------------------------
/
∗
(24)
%
checkAllFramesModes
(?
gOrWS
, ?
reOrWr
,
[
]
).
(25)
%
checkAllFramesModes(?gOrWS, ?
reOrWr
,[?F|?R]):-
(26)
%
checkFrameMode
(?
gOrWS
, ?
reOrWr
,?F),
(27)
%
checkAllFramesModes(?gOrWS, ?
reOrWr
,?R).
/
∗
-------------------------------------------------------------------
/
∗
(28)  %checkFrameMode(GOAL,READ,?F):-
(29)
(?
F:In  ∖or ?F:Out  ∖or ?F:Shared  ∖or ?F:Static), !.
(30)  %checkFrameMode(GOAL,WRITE,?F):-
(31)
(?
F:In  ∖or ?F:Shared), !.
(32)  %checkFrameMode(GOAL,READ,?F):-
(33)
writeln
([
＇
Illegal GOAL READ action for
＇  ,?F])@∖prolog, !,∖false.
(34) %checkFrameMode(GOAL,WRITE,?F):-
(35)
writeln
([
＇
Illegal GOAL WRITE action for
＇  ,?F])@∖prolog, !,∖false.%
checkAllFramesModes (lines (24) to (27)) checks modes for a list of extracted frames through calls to %checkFrameMode (defined on lines (28) to (31)). In case of failure, error messages are generated on lines (32) to (35).The complete list of predicates and their explanations are presented in AppendixD in the supplementary materials, and the full source code of the implementation is available in [27].


## 4.1. Semantic Specification of Goal and Web Service in Flora-2

As in WSMO, our Flora-2 specifications for goal and web service are composed of the elementsontology,capability, andchoreography.Ontology contains frames and relations that represent knowledge used by the web service and goal.Capability element encloses two subelements,pre andpost, which represent pre- and postconditions. Precondition of the goal can contain conjunctions of nonnegated frames and relations. Postcondition of the goal can be an F-logic expression (including all the logical connectives). Postcondition of the web service can contain conjunctions of nonnegated frames and relations. Precondition of the web service can be an F-logic expression (including all the logical connectives). Note the similarity between the precondition of the goal and the postcondition of the web service, as well as the similarity between the postcondition of the goal and the precondition of the web service.Choreography element is modeled by a set of transition rules. Each rule is specified by ruleId:ruleType  -> ruleBody. Goal’s ruleId is in form of gRule(OID) and web service’s ruleId is in form of wsRule(OID), where OID is any Flora-2 object identifier and is used as a label for the rule. ruleType can be either ForallRule or ChooseRule. ruleBody is a reified Flora-2 implication shown by anif-then(-else)2 statement. The implication antecedent (we refer to it as left-hand side) can be an F-logic expression, and the implication consequent (we refer to it as right-hand side) contains a set of update functions (actions). Box 1 depicts the general form of a goal specification. Specification of web services is also similar.Box 1:General form of goal specification in Flora-2.
goalName
:Goal.
goalName
[
importOntology
->
address of local ontology
,
capability ->
$
pre ->
$  Conjunction of frames and predicates  ,
post ->
$  F-logic expression
,
gRule
(
R01
):
ForallRule
->
$
∖
if (
F-logic expression
)
∖then (  Actions),
gRule
(
R02
):
ChooseRule
->
$
∖
if (  F-logic expression)
∖
then (
Actions
)
,
⋮
].AppendixB in the Supplementary Materials contains the EBNF grammar of goal and web service specifications.


## 4.2. Proposed Architecture

In this section, we describe the architecture of our choreography engine.


### 4.2.1. Modules of the System

Our Flora-2 solution for implementing the choreography algorithm utilizes themain module and two Flora-2 user modules:WM for keeping the current state signature of the choreography andDeltaWM for keeping the actions for modifying the current state into a new state. Themain module contains the declaration of concepts, instances, and their modes provided by web service and goal, as well as the code for the choreography engine. These three modules (i.e.,main,WM, andDeltaWM) are interconnected, as shown in Figure 1.Figure 1
Architectural view of the choreography engine.


### 4.2.2. Delta Working Memory (ΔWM): Realizing ASM Parallelism

An auxiliary and transient user module named Delta Working Memory (ΔWM) is used to temporarily keep single choreography round updating actions that should be applied to the main knowledge-base (WM). In each choreography round, all the updates are aggregated into ΔWM and then ΔWM is checked whether there exists any contradiction among the requested actions (explained below). If no contradiction is detected, then all the updates are carried out on the WM, evolving it into a new conflict-free state.


### 4.2.3. Deterministic Choreography and Contradiction

As mentioned before, the transition rules must be applied in parallel. In the absence of any consistency checking, the rules can do contradictory actions which should be prevented.The three kinds of contradiction that can occur in a choreography round are as follows [1]:(i)
Inserting and deleting/updating the same knowledge simultaneously(ii)
Updating knowledge which does not exist(iii)
Deleting knowledge which does not exist.It is clear that such contradictory actions must be detected and the choreography execution must be stopped. In the case of nonexistent knowledge, it makes no sense to remove or modify it. In the case of simultaneous insertion/deletion of the same knowledge, if the choreography run is continued, then it becomes nondeterministic in an unintended way: even though theoretically updates are done in parallel, in reality they have to be done in a serial fashion, and the order in which they are carried out leads to different WM states.In each choreography round, in addition to testing for the above-mentioned issues, checking for any violation on the modes of concepts (explained in Section3.1.1) is performed as well. If one of the participants wants to do an action on a concept which violates the concept’s access mode, that action is prevented, leading to choreography execution failure.


## 4.2.1. Modules of the System

Our Flora-2 solution for implementing the choreography algorithm utilizes themain module and two Flora-2 user modules:WM for keeping the current state signature of the choreography andDeltaWM for keeping the actions for modifying the current state into a new state. Themain module contains the declaration of concepts, instances, and their modes provided by web service and goal, as well as the code for the choreography engine. These three modules (i.e.,main,WM, andDeltaWM) are interconnected, as shown in Figure 1.Figure 1
Architectural view of the choreography engine.


## 4.2.2. Delta Working Memory (ΔWM): Realizing ASM Parallelism

An auxiliary and transient user module named Delta Working Memory (ΔWM) is used to temporarily keep single choreography round updating actions that should be applied to the main knowledge-base (WM). In each choreography round, all the updates are aggregated into ΔWM and then ΔWM is checked whether there exists any contradiction among the requested actions (explained below). If no contradiction is detected, then all the updates are carried out on the WM, evolving it into a new conflict-free state.


## 4.2.3. Deterministic Choreography and Contradiction

As mentioned before, the transition rules must be applied in parallel. In the absence of any consistency checking, the rules can do contradictory actions which should be prevented.The three kinds of contradiction that can occur in a choreography round are as follows [1]:(i)
Inserting and deleting/updating the same knowledge simultaneously(ii)
Updating knowledge which does not exist(iii)
Deleting knowledge which does not exist.It is clear that such contradictory actions must be detected and the choreography execution must be stopped. In the case of nonexistent knowledge, it makes no sense to remove or modify it. In the case of simultaneous insertion/deletion of the same knowledge, if the choreography run is continued, then it becomes nondeterministic in an unintended way: even though theoretically updates are done in parallel, in reality they have to be done in a serial fashion, and the order in which they are carried out leads to different WM states.In each choreography round, in addition to testing for the above-mentioned issues, checking for any violation on the modes of concepts (explained in Section3.1.1) is performed as well. If one of the participants wants to do an action on a concept which violates the concept’s access mode, that action is prevented, leading to choreography execution failure.


## 4.3. Major Predicates of the Choreography Engine3

The main process is started through a call to%start predicate which is shown in Listing 1. The choreography engine execution begins with a call to the %initializations predicate on line (2), which currently resets the seed of the random number generator that is used to process thechoose rule type. On line (3), goal and web service rules are checked for mode violations before the choreography rounds start. On lines (4) and (5), the modulesWM andDeltaWM are created if they do not already exist. On lines (6) and (7), local ontologies of the goal and web service are loaded into WM. On line (8), the goal precondition is loaded into WM, becoming part of the initial state of the choreography run, followed by a call to the predicate %runChoreogarphy on line (9) which tries to satisfy the goal postcondition through repeated application of goal and web service transition rules.Listing 1:The top-level predicate of the choreography engine.
(1)   %start(?goal,?WS)  :-
(2)
%
initializations,
(3)
%
preProcessCheckings(?goal,?WS),
(4)
%
prepareModule
(WM),
(5)
%
prepareModule
(
DeltaWM
),
(6)
%
importOntology(?goal,WM),
(7)
%
importOntology
(?WS,WM),
(8)
%
insertGoalPre(?goal,WM),
(9)
%
runChoreography(?goal,?WS).%
runChoreography implements the improved choreography algorithm given in Section 3.5, employing recursion instead of iteration. The definition of the %runChoreography predicate is given in Listing 2. It attempts first to prove the goal postcondition with the current state of WM in lines (1)–(3); the cut (!) operator on line (2) prevents backtracking and a success message is shown to the user on line (3). If the goal postcondition is not satisfied, then the second definition of %runChoreography is called: ΔWM is emptied on line (5); web service and goal rules are applied, populating ΔWM with pending actions to be performed on the WM (lines (6) and (7)). On lines (8)–(11), ΔWM is checked for consistency (line (8)) as well as whether pending actions result in a new state of WM (line (10)). In the case of inconsistent changes or no change to WM, execution is stopped to prevent infinite recursion and a failure message is reported (lines (9) and (11)). Otherwise, the actions in ΔWM are applied to WM to obtain an updated WM (line (12)), and the process is repeated through a recursive call to %runChoreography (line (13)).Listing 2:
%
runChoreography predicate.
(1)
%
runChoreography(?goal, ?WS)  :-
(2)
%
proveGoalPost(?goal),
!,
(3)
%
watchln
([
＇
Success!
＇
-?goal-
＇
and
＇
-?WS-
＇
are
＇
-
＇
choreographed!
＇
]).
(4)
%
runChoreography(?goal, ?WS):-
(5)
%
eraseModule(DeltaWM),
(6)
%
runWsRules(?WS),
(7)
%
runGoalRules(?goal),
(8)
(  (%contradictory(WM,DeltaWM), !,
(9)
%
watchln
(
＇
Choreography failed due to CONTRADICTION.
＇
) )
∖
or
(10)
(  ∖+%deltaMakesAChange(WM,DeltaWM), !,
(11)
%
watchln(
＇
Choreography failed due to NO CHANGE.
＇
) )
∖
or
(12)
(  %mergeDeltaIntoWM,
(13)
%
runChoreography(?goal,?WS) )).


## 4.4. Running (Firing) the Rules

One of the key features of ASMs is that rules should be fired in parallel. We realize this by placing all the insertion, deletion, and update actions on the right-hand sides of the rules that match the current WM into ΔWM, checking them for consistency, and then applying them to the previous WM to get an updated WM. The predicates%deltaInsert, %deltaDelete, and %deltaUpdate represent tentative changes to WM, not actual ones, until they are verified to not cause any conflicts.Listing3 contains the predicates for running goal and web service rules. The Flora-2 setof operator is used to iterate over all rules in the choreography specification (lines (2), (5), (9), and (12)). In the case offorall rules, if the rule antecedent contains only ground facts, it models the ASMif-then transition rule type. If the antecedent contains free variables, it acts like the ASMforall transition rule type. In the case of achoose rule, the predicate %invokeChoose randomly selects exactly one ground instance of the free variables existing in the antecedent of the rule.Listing 3:Running the goal and web service rules.
(1)
%
runWsRules
(?WS)  :-
(2)
?_Temp =
setof
?ruleID
∣
(3)
?
WS:WebService
[
wsRule
(?
ruleID
):
ForallRule
->  ?ruleBody],
(4)
%
invoke(WEBSERVICE,  ?ruleBody),
(5)
?_Temp2 =
setof
?ruleID
∣
(6)
?
WS:WebService
[
wsRule
(?
ruleID
):
ChooseRule
-> ?
ruleBody
],
(7)
%
invokeChoose(WEBSERVICE,?ruleBody)
.
/
∗
-------------------------------------------------------
/
∗
(8)
%
runGoalRules
(?goal)  :-
(9)
?_Temp =
setof
?ruleID
∣
(10)
?
goal:Goal
[
gRule
(?
ruleID
):
ForallRule
-> ?
ruleBody
],
(11)
%
invoke(GOAL,?
ruleBody
)
,
(12)
?_Temp2 =
setof
?ruleID
∣
(13)
?
goal:Goal
[
gRule
(?
ruleID
):
ChooseRule
-> ?
ruleBody
],
(14)
%
invokeChoose(GOAL,?ruleBody)
.


## 4.5. Contradictions in Applying the Rules

Checks for contradictory actions are implemented by the definition of the predicate%contradictory in Listing 4. In lines (1)–(3), simultaneous insertion and deletion of the same item are detected; in lines (4)–(6), deletion of a nonexistent item is detected; finally in lines (7)-(8), update of a nonexistent item is detected.Listing 4:Contradictory cases.
(1)   %contradictory(?WM, ?DeltaWM)  :-
(2)
ins_action
(?A1)@?
DeltaWM
,
del_action
(?A2)@?
DeltaWM
,
(3)
%
contained(?X1,?A1),
%
contained(?X2,?A2),?X1 = ?X2,!.
(4)   %contradictory(?WM, ?DeltaWM)  :-
(5)
del_action
(?A)@?
DeltaWM
,
(6)
%
convertReifiedObjectModule(?A, ?
DeltaWM
, ?WM, ?
A_new
),
∖
+ ?
A_new
@?WM.
(7)   %contradictory(?WM, ?DeltaWM)  :-
(8)
update_action
(?
objOld
,?
objNew
)@?
DeltaWM
,
∖
+ ?
objOld
@?WM.


## 4.6. Access Control to Objects of Different Types

ASMs define access control modes for object manipulation. In the implementation, this access control has been enforced by checking whether a given manipulation is legal or not. This depends on the actor of the manipulation. For example, if an object hasin mode, then only a goal can change its attributes. While invoking the rules belonging to the goal or web service, the legality of the access to the object is verified before the real action.Listing5 depicts a part of the implementation of access control for a goal. Before the rule is tested against the current WM, its concepts and user predicates on its left-hand side and right-hand side are extracted through the %extractConcepts, %extractPredicates, and %filterOutPredicates predicates (lines (4)–(6)), and access rights of the goal are verified for those concepts via %checkAllFramesModes and %checkAllPredicatesModes (lines (7), (10), (18), and (21)). If a concept is on the right-hand side of a rule, the goal must have write access to it. On the other hand, if it is on the left-hand side, only read access is enough.Listing 5:Checking access mode.
(1)
%
check(?
gOrWs
,?X)  :-
(2)
?X ~
$
∖
if ?Y
∖
then ?Z
, !,
(3)
%
reformatToString
(?Y, ?
YStr
),
(4)
%
extractConcepts
(?
YStr
,
[
]
, ?
conceptsInY
),
(5)
%
extractPredicates(?YStr,
[
]
, ?termList1),
(6)
%
filterOutPredicates(?termList1,
[
]
,  ?predicatesInY),
(7)
∖
if (
∖
+
%
checkAllFramesModes
(?gOrWs,READ,?conceptsInY))
∖
then
(8)
(
writeln
([
＇
Error: Illegal access mode in
＇
-?
gOrWs
])@
∖
prolog,!,
(9)
∖
false),
(10)
∖
if (
∖
+
%
checkAllPredicatesModes
(?gOrWs,READ,?predicatesInY))
∖
then
(11)
(
writeln
([
＇
Error: Illegal access mode in
＇
-?
gOrWs
])@
∖
prolog,!,
(12)
∖
false),
(13)
%
decomposeRHS
(?Z,
[
]
, ?
allFsOrPs
),
(14)
%
reformatToString(?allFsOrPs, ?
allFsOrPsStr
),
(15)
%
extractConcepts(?allFsOrPsStr,
[
]
, ?
conceptsInZ
),
(16)
%
extractPredicates(?allFsOrPsStr,
[
]
, ?temp),
(17)
%
filterOutPredicates(?temp,
[
]
, ?
predicatesInZ
),
(18)
∖
if (
∖
+
%
checkAllFramesModes
(?gOrWs,WRITE,?conceptsInZ))
∖
then
(19)
(
writeln
([
＇
Error: Illegal access mode in
＇
-?
gOrWs
])@
∖
prolog,!,
(20)
∖
false),
(21)
∖
if (
∖
+
%
checkAllPredicatesModes
(?gOrWs,WRITE,?predicatesInZ))
∖
then
(22)
(
writeln
([
＇
Error: Illegal access in  ＇-?gOrWs])@∖prolog,!,
(23)
∖
false).
/
∗
-------------------------------------------------------------------
/
∗
(24)
%
checkAllFramesModes
(?
gOrWS
, ?
reOrWr
,
[
]
).
(25)
%
checkAllFramesModes(?gOrWS, ?
reOrWr
,[?F|?R]):-
(26)
%
checkFrameMode
(?
gOrWS
, ?
reOrWr
,?F),
(27)
%
checkAllFramesModes(?gOrWS, ?
reOrWr
,?R).
/
∗
-------------------------------------------------------------------
/
∗
(28)  %checkFrameMode(GOAL,READ,?F):-
(29)
(?
F:In  ∖or ?F:Out  ∖or ?F:Shared  ∖or ?F:Static), !.
(30)  %checkFrameMode(GOAL,WRITE,?F):-
(31)
(?
F:In  ∖or ?F:Shared), !.
(32)  %checkFrameMode(GOAL,READ,?F):-
(33)
writeln
([
＇
Illegal GOAL READ action for
＇  ,?F])@∖prolog, !,∖false.
(34) %checkFrameMode(GOAL,WRITE,?F):-
(35)
writeln
([
＇
Illegal GOAL WRITE action for
＇  ,?F])@∖prolog, !,∖false.%
checkAllFramesModes (lines (24) to (27)) checks modes for a list of extracted frames through calls to %checkFrameMode (defined on lines (28) to (31)). In case of failure, error messages are generated on lines (32) to (35).The complete list of predicates and their explanations are presented in AppendixD in the supplementary materials, and the full source code of the implementation is available in [27].


## 5. A Realistic Choreography Example

In this section, we give the choreography specification for interacting with an online flight reservation service. An autonomous software agent, acting on behalf of a human, is used to make the purchase. The behavior of the agent is described semantically in the form of a goal, with a choreography component. Similarly, the behavior of the online reservation service is described semantically as a web service, with its own choreography component. A person who wants to use the service can just provide the required information to the agent and leave the scene. The agent then interacts with the web service in accordance with its choreography, provided that it is compatible with the web service’s choreography.The essence of this scenario has been inspired by the online ticket reservation website of an actual airline, similar to Virtual Travel Agency used in [52].The actual scenario between a human and a website providing flight reservation service is as follows. After opening the airline website, the user is able to set six items: departure city/airport, arrival city/airport, whether the trip is roundtrip or one-way (only roundtrips are considered in this case), departure date, return date, and the number of passengers. After the user submits this information, the reservation website offers some candidate flight numbers and their details, including date, time, airport, and price. The user has to choose one of the candidates. In the next step, the online ticket reservation site asks for passenger data, such as the full name, gender, and date of birth. After these items are provided by the user, the system asks for credit card information, including the holder’s name, credit card number, and its CVV code. After the user provides the card specifications, the online ticket service queries the bank to validate the card. Depending on the outcome of the bank query, the flight reservation service completes the transaction and issues a ticket to the user.Listings6 and 7 are Flora-2 specifications of the user (goal) and the web services (reservation system), respectively. We simulate the conversation which should take place between the reservation service and the bank because it is a third party and not directly involved in the choreography.Listing 6:Goal (the user).
/
∗
Local ontology stored in a separate file
Name(
＇
Peter
＇
).
DateOfBirth
(19830622).
Gender(
＇
Male
＇
).
CreditCardNo
(
＇
1234432156788765
＇
).
CreditCardHolder
(
＇
PETER JACKSON
＇
).
CreditCardCVV
(123).
/
∗
myGoal:Goal
[
importOntology
->
＇
../Flight/
GoalsOntology.flr
＇
,
capability ->
$
pre ->
$
myRequest:RequestFlight
[
From->
＇
Paris
＇
,
To->
＇
Chicago
＇
,
Departure->23,
Return->30]
,
post ->
$
(?
R:Reservation
[?X->?Y])
,
gRule
(R01):
ChooseRule
->
$
∖
if (
tripChoice
(?
fl_dep,?fl_ret,?P
),
(
∖
+
trip:Trip
) )@WM
∖
then (
%
deltaInsert
(
$
trip:Trip[
Dep->?
fl_dep
,
Ret->?
fl_ret
]
) )
,
gRule
(R02):
ForallRule
->
$
∖
if ( (?
Q:QuestionByWS
[
Name->?X,
DateOfBirth
->?Y,
Gender->?Z])@WM,
(Name(?N),
DateOfBirth
(?
DoB
), Gender(?G))@WM )
∖
then (
%
deltaInsert
(
$
answer:AnswerByGoal[
Name->?N,
DateOfBirth
->?
DoB
,
Gender->?G]
) )
,
gRule
(R03):
ForallRule
->
$
∖
if ( (?
Q:QuestionByWS
[
CreditCardNo
->?X,
CreditCardHolder
->?Y,
CreditCardCVV
->?Z])@WM,
(
CreditCardNo
(?CCN),
CreditCardHolder
(?CCH),
CreditCardCVV
(?CCCVV) )@WM
)
∖
then (
%
deltaInsert
(
$
answer:AnswerByGoal[
CreditCardNo
->?CCN,
CreditCardHolder
->?CCH,
CreditCardCVV
->(?CCCVV)]
) )
].Listing 7:Web services (the reservation system and the bank).
/
∗
Local ontology stored in a separate file
flight(F100,Paris,Chicago,23,250).
flight(F101,Paris,Chicago,23,350).
flight(F102,Paris,Chicago,25,400).
flight(F103,Chicago,Paris,29,150).
flight(F104,Chicago,Paris,30,200).
flight(F105,Chicago,Paris,30,150).
/
∗
FlightReservationService:WebService
[
importOntology
->
＇
../Flight/
WebServicesOntology.flr
＇
,
capability ->
$
pre ->
$
?Req:RequestFlight[?X1->?Y1]
,
post ->
$
(?Res:Reservation[?X2->?Y2])
,
wsRule
(R01):
ForallRule
->
$
∖
if ( (?
R:RequestFlight
[
From->?X,
To->?Y,
Departure->?Z,
Return->?W])@WM,
(flight(?fl_dep,?X,?Y,?Z,?
priceDep
))@WM,
(flight(?fl_ret,?Y,?X,?W,?
priceRet
))@WM,
(
%
sum(?priceDep,?priceRet,?priceTot)) )
∖
then (
%
deltaInsert
(
$
tripChoice (?fl_dep,?fl_ret,?priceTot)
) )
,
wsRule
(R02):
ForallRule
->
$
∖
if ( ?
T:Trip
[
Dep->?
fl_dep
,
Ret->?
fl_ret
] )@WM
∖
then (
%
deltaInsert
(
$
question:QuestionByWS[
Name->?X,
DateOfBirth
->?Y,
Gender->?Z]
) )
,
wsRule
(R03):
ForallRule
->
$
∖
if ( ?
A:AnswerByGoal
[
Name->?X,
DateOfBirth
->?Y,
Gender->?Z] )@WM
∖
then (
%
deltaInsert
(
$
q
u
e
s
t
i
o
n
:QuestionByWS[
CreditCardNo
->?XX,
CreditCardHolder
->?YY,
CreditCardCVV
->?ZZ
]
) )
,
wsRule
(R04):
ForallRule
->
$
∖
if ( ?
A:AnswerByGoal
[
CreditCardNo
->?X,
CreditCardHolder
->?Y,
CreditCardCVV
->?Z] )@WM
∖
then (
%
deltaInsert
(
$
validation:CreditCardValidation[
Number->?X,
Holder->?Y,
CVV->?Z
]
) )
,
wsRule
(R05):
ForallRule
->
$
∖
if ( (
BankYesNoAnswer
(
＇
Yes
＇
))@WM,
(
trip:Trip
[
Dep->?
fl_dep
,
Ret->?
fl_ret
])@WM )
∖
then (
%
deltaInsert
(
$
reservation:Reservation[
Number->11100,
Flight1->?
fl_dep
,
Flight2->?
fl_ret
]
) )
,
wsRule
(Bank_R01):
ForallRule
->
$
∖
if ( (?
R:CreditCardValidation
[
Number->?X, Holder->?Y, CVV->?Z])@WM,
(
DB_CreditCard
(?X,?Y,?Z) )@WM
)
∖
then (
%
deltaInsert
(
$
B
a
n
k
Y
e
s
N
o
A
n
s
w
e
r
(
＇
Yes
＇
)
) )
].In the precondition of the goal, the departure and arrival cities and days have been specified. The postcondition states that a reservation instance is demanded.On the flight web service side, the first rule of choreographywsRule(R01) checks if there is a request for a flight consisting of all the necessary items, searches for a roundtrip on the specified days, and if this search is successful inserts a new triple into the knowledge-base containing two flight numbers and their total price. On the goal side, the rule gRule(R01), which is of rule typechoose, is responsible for checking the existence of any choice on the knowledge-base. As soon as some flight choices become available in the knowledge-base, this rule selects just one of them randomly and inserts this selection into the knowledge-base. Note the condition (∖+ trip:Trip) which prevents the rule from being fired again.The rest of the rules in the goal cover the answers to the general questions such as name, date of birth, and credit card information. On the flight web service side, rulewsRule(R02) checks the knowledge-base for any trip choice by the user; as soon as this choice becomes available, it asks for all the passenger identities. After receiving the answers from the goal, it then asks for credit card information and checks its validity by querying the bank. If it receives a positive reply from the bank, it puts a reservation into the knowledge-base which satisfies the goal postcondition and the choreography terminates successfully; otherwise it fails.Table5 shows what new knowledge is added to WM in each choreography round of a successful choreography, effectively tracing the execution of the choreography engine.Table 5
Items added to WM at each choreography round.
Round 0
Name(
＇
Peter
＇
).
DateOfBirth
(19830622).
Gender(
＇
Male
＇
).
CreditCardNo
(
＇
1234432156788765
＇
).
CreditCardHolder
(
＇
PETER JACKSON
＇
).
CreditCardCVV
(123).
flight(F100,Paris,Chicago,23,250).
flight(F101,Paris,Chicago,23,350).
flight(F102,Paris,Chicago,25,400).
flight(F103,Chicago,Paris,29,150).
flight(F104,Chicago,Paris,30,200).
flight(F105,Chicago,Paris,30,150).
DB_CreditCard
(
＇
876543212345678
＇
,
＇
PAUL BROWN
＇
,123).
DB_CreditCard
(
＇
1234432156788765
＇
,
＇
PETER JACKSON
＇
,123).
Round 1
myRequest:RequestFlight
[From->Paris]
myRequest:RequestFlight
[To->Chicago]
myRequest:RequestFlight
[Departure->23]
myRequest:RequestFlight
[Return->30]
Round 2
tripChoice
(F100,F104,450)
tripChoice
(F100,F105,400)
tripChoice
(F101,F104,550)
tripChoice
(F101,F105,500)
Round 3
trip:Trip
[Dep->F101]
trip:Trip
[Ret->F105]
Round 4
question:QuestionByWS
[Name->_h592309]
question:QuestionByWS
[
DateOfBirth
->_h592309]
question:QuestionByWS
[Gender->_h592309]
Round 5
answer:AnswerByGoal
[Name->Peter]
answer:AnswerByGoal
[
DateOfBirth
->19830622]
answer:AnswerByGoal
[Gender->Male]
Round 6
question:QuestionByWS
[
CreditCardNo
->_h592309]
question:QuestionByWS
[
CreditCardHolder
->_h592309]
question:QuestionByWS
[
CreditCardCVV
->_h592309]
Round 7
answer:AnswerByGoal
[
CreditCardNo
->1234432156788765]
answer:AnswerByGoal
[
CreditCardHolder
->PETER JACKSON]
answer:AnswerByGoal
[
CreditCardCVV
->123]
Round 8
validation:CreditCardValidation
[Number->1234432156788765]
validation:CreditCardValidation
[Holder->PETER JACKSON]
validation:CreditCardValidation
[CVV->123]
Round 9
BankYesNoAnswer
(Yes)
Round 10
reservation:Reservation
[Number->11100]
reservation:Reservation
[Flight1->F101]
reservation:Reservation
[Flight2->F105]


## 6. Discussion

Flora-2 has been used not only as the specification language of semantic web service capability and interface components, but also as the implementation language of the choreography execution engine itself. This choice gives the choreography developer a concise, frame based logical syntax to work with, as well as all the functionality of the underlying Flora-2 system in terms of its built-in predicates and reasoner. This is in contrast to WSML, the class of languages developed for WSMO, which has a verbose syntax, and must rely on external reasoners for all semantic computing activities, including choreography execution.Our choice of Flora-2 as both the specification and implementation language also helps us in dealing with the granularity mismatch problem [17, 53]. As explained in [17], data granularity can be a barrier to reach a successful choreography. Authors of [2] demonstrate the data granularity mismatch issue with an example: one web service requires credit card details to be sent one at a time, whereas another requires that all details are sent in single message. Frame structures in Flora-2 intrinsically solve this type of granularity issue. For example, a credit card can be defined as follows:joeCreditCard:CreditCard[
number ->＇＇1234-5678-9012-3456＇＇,name ->＇＇Joe Brown＇＇,CVV -> 123].Internally, however, such a frame is represented as the composition of its data members, and each data member of a frame can be referred to individually, without the need to refer to other data members at the same time. Also, a frame can be built up incrementally through the addition of its data members. Consequently, the granularity level with which frames of a certain concept are handled by the goal or web service becomes insignificant: the web service or goal can provide the constituents of a frame either in piecemeal fashion in any order or as a whole at once, and its counterpart can consume it under both conditions.


## 7. Related Work

Semantic web service frameworks such as WSMO and OWL-S [54] use rich semantic reasoning systems to realize semantic web service choreography. They model the interaction between the client and the service as a bidirectional conversation, with implementations such as WSMX [1, 17, 55], WSMO Studio (a visual editor for WSML) [56], WSMO4J API [57], IRS-III [2, 58], and OWL-S tools [59].OWL-S is not well aligned with the WSMO framework. It “does not provide an explicit definition of choreography, but instead focuses on a process based description of how complex web services invoke atomic web services” [2]. In [60], WSMO and OWL-S are compared in detail and the author concludes that “WSMO presents some important advantages when compared to OWL-S.” Here, we point out some general issues about OWL-S:(i)
OWL-S does not properly decouple the viewpoint of service requester and service provider.(ii)
OWL-S service profile mixes the information of WSMO goal, WSMO capability, and nonfunctional properties.(iii)
In OWL-S, the requester has to formulate its request based on the descriptions of profiles.(iv)
OWL-S does not clearly define how logical expressions are used to describe conditions and results.(v)
In spite of its incompleteness, WSMO choreography provides ASM as its formal model, whereas a formal semantic OWL-S process model is still missing.WSMX is known as the reference prototype implementation of WSMO [55]. WSMX offers a flexible architecture that can accept different components as its plug-ins. The project has been implemented in Java, can handle service and goal specifications that are written in WSML [20, 61], and uses WSML2Reasoner [62], which converts WSML into the internal representation of external reasoning engines in order to do the reasoning tasks. KAON2 [63] is the external reasoner used to deal with choreography reasoning tasks [30].We have thoroughly investigated WSMX using publicly available documents, including published papers and source code [64, 65]. We have found that(i)
the implementation of choreography in WSMX was started but not completed,(ii)
the implementation does not support parallelism and consequently inconsistency checking is not even an issue,(iii)
the implementation does not support intentional nondeterministic behavior necessitated by theChoose rule type,(iv)
in the case ofif-then rules, if more than one left-hand side (antecedent) is satisfied by the current ontology state, right-hand sides of all matching rules are executed sequentially, without any consistency check of the actions performed, resulting in behavior that depends on the order of the rules.Furthermore, in the last version of WSML2Reasoner, which is used by WSMX to translate WSML logical expressions to the native language of the used reasoner, there is no translation of theForall orChoose rule types, confirming our findings. It is clear that several of the most fundamental features of ASMs remain unimplemented in WSMX.IRS-III (the Internet Reasoning Service: 3rd version) [2, 58, 66] provides an infrastructure that utilizes the WSMO framework. The IRS system is composed of three major components:server,client, andpublisher. Choreography between a client and a web service is not done directly, but through the IRS choreography engine, which acts as a broker between the available web services and user requests. IRS takes the responsibility of service discovery, mediation, communication, and invocation of the web services and provides the result for the goal; however, clients should formulate their needs to IRS in the specific representation language of IRS [58]. IRS uses the OCML ontology representation language and its server has been implemented in Lisp [67].IRS does not adhere to either original ASM, or WSMO choreography, because(i)
transition rules of IRS are not run in parallel. In the case that more than one transition rule applies to the current state of the choreography, only one is selected using an internal function for which no further details are available,(ii)
actions in the rules are tightly coupled with the actual messages sent to the web service, which makes the choreography specification inflexible; the actual call sequence of operations is predetermined for different kinds of requests,(iii)
goals are modeled by pre- and postconditions only and do not contain a choreography component at all. The interaction is between the IRS, acting on behalf of the goal, and the web service, using solely the choreography specification of the web service,(iv)
the concept of modes is completely absent; flexible interaction between the requester and service provider that is made possible by having modes is replaced by a rigid communication model where theactor which has theinitiative can update data.In comparison with our approach, IRS does not support parallel firing of transition rules and does not check for consistency of the updates. Consequently, the next state of the ontology is not unique and depends on the choice of the rule to be fired, leading to nondeterministic behavior. Whereas we make full use of modes and enforce their compliance, as already mentioned, IRS completely ignores them. Most importantly, it ignores the obvious connection between the initial choreography execution state and the precondition of the goal, as well as the final state of the choreography execution and the goal postcondition, relying instead on the built-in predicateinit-choreography to start the chain of rule firing and the actionend-choreography to terminate the choreography run. If the choreography is not designed carefully, the situation where the choreography run terminates without the goal postcondition being satisfied could arise.There are other notable works on the analysis, formalization, and modeling of choreographies. Roman et al. in [68] argue that choreographies specified in the original ASM model become quite involved when they contain contracting and enactment (additional policies and constraints imposed by web service and goal). In [68], they extend the current model of WSMO with Concurrent Transaction Logic (CTR) [69, 70] to simplify the representation; however, the CTR implementation is still in its prototype stage [71]. Bonner and Kifer in [40] discuss the main reasoning and mediation activities required for choreography and orchestration, both in general and in the context of WSMO. SWORD authors use rule-based expert systems to “determine whether a desired composite service can be realized using existing services” [72]. This approach is similar to ours in that it uses forward-chaining reasoning to develop knowledge in a stepwise manner, but for the purpose of web service composition, and not choreography.


## 8. Conclusion and Future Work

In this work, we identified important weaknesses in the original ASM-based choreography execution algorithm for WSMO, which prevented it from being useful in a practical way, and improved it in order to remedy the identified weaknesses. The improved ASM-based choreography execution algorithm establishes the missing connection between the capability and interface components of WSMO. We used F-logic and Flora-2 to specify ASM-based choreographies of semantic web services in a concise and logical manner and implemented a fully functional choreography execution engine based on our improved algorithm in Flora-2. The full functionality of Flora-2 and its underlying reasoning system is available for developing ontologies and writing transition rules in the choreography specification. To the best of our knowledge, this work is the first fully functional WSMO choreography implementation that fires rules in parallel, as required in the theory of ASMs, and models the ASMif-then(-else),forall, andchoose rule types authentically, while enforcing access modes of concepts and relations. We demonstrated the workings of our algorithm through a real-life example, concerning a flight reservation scenario, where both web service and goal choreographies were specified in our F-logic based syntax (seven more real-life examples are provided in Appendix Cin the Supplementary Materials). We also developed a visual tool that helps choreography engineers write specifications in a convenient manner, reducing the chance of mistakes in the specification.Another important contribution of our work is that we proved for the first time the equivalence of evolving algebras (ASMs) and evolving ontologies (the basis of semantic choreography engines) through the definition of bidirectional mappings between them.For future work, we are planning to develop our system through the addition of a grounding mechanism, as well as a mediation component. We also intend to identify and classify different types of general requests and general responses among software components and present them in the form of an ontology. Such a classification scheme will help in the development of accurate and commonly acceptable choreographic interactions.



---

*Source: 4094951-2018-01-24.xml*