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.
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 are service orchestration and service 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 [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 a single web service when it is interacting with its client (so-called goal), 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 named choreography interface in [13].
In the rest of this article, we use the term choreography 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. WSMO choreography is a component of WSMO interface that deals with choreographing of WSMO-based web services and goals.
Although WSMO based its choreography algorithm on the well-founded theory of Abstract 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 WSMO capability specification of web services and goals. A capability involves pre- and postconditions of web services and goals. Capabilities are used in the service discovery stage. In the current work, we focus on WSMO interfaces, which mainly include choreography specification and are used in the service 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 as evolving algebras [24]) and WSMO choreography specifications (commonly called evolving ontologies [25]) by providing appropriate mappings between them.
The rest of this article is organized as follows. In Section 2, 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, and choose-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), and mediator (resolves different types of possible incompatibilities, including process and terminological, between goals and web services).
The concept of web service in turn contains nonfunctional properties, ontologies, mediators, capability, and interface elements. The functionality of a WSMO web service is described by the capability element which contains precondition, postcondition, assumption, and effect. 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 service Interface 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 Table 1, some of the more prominent constructs of Flora-2 syntax, which we use in the choreography engine implementation, are given.
2.4.2. Flora-2 Main, Built-In, and User Modules
Flora-2 keeps knowledge in logical storage places named modules. By default, all the information and knowledge is stored in the main module. The user can create an arbitrary number of independent modules for organizing knowledge (referred to as user-defined modules). Flora-2 also has built-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 involves concepts, attributes, relations, and axioms. 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 of evolving algebras and evolving ontologies, filling this gap.
3.1. Specification of Choreographies in WSMO
In WSMO, the choreography concept has four components: nonFunctionalProperties, stateSignature, state, and transitionRules. 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, and out, which control reading and writing access of the machine and the environment. Table 2 summarizes the encapsulation effect of each mode [14].
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 guard then do rules.(ii)Forall variables with guard do rules.(iii)Choose variables with guard do 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 after Forall 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 a Forall rule, an extra level of parallelism is introduced through the different instantiations of the variables listed after the Forall keyword.
Rules on the right-hand side, also called actions, 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, if f(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 called universes) contain data, with functions defined over the domains. The superuniverse is the union of all domains. Relations are treated as Boolean valued functions, and domains are used interchangeably with characteristic functions (e.g., if , then = True). A vocabulary is collection function names. Nullary function names (those with zero parameters) are called constants. The pair , where is a function name and are parameters that the function can be applied to, is called a location. Every ASM vocabulary is assumed to contain the static constants undef, True, and False. A state of the vocabulary consists of (i) the superuniverse of (which we shall call or ) and (ii) interpretations of the function names in . For any -ary function name in , its interpretation is a function from into . If is a constant of , is an element of . undef is the default value and represents and undetermined object. The notions of terms, formulas, substitutions, quantifiers, logical connectives, and interpretations of terms and formulas are exactly the same as in first-order logic. Each state is an algebra in the mathematical sense of the word, with the exception that, for in , 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 term evolving algebras. We should note, however, that the update rule in ASMs is of the form , where both the arguments and result of the function application are terms, not values in . From a logic programming point of view, where we use terms to represent data, we can reasonably assume that is nothing more than , the Herbrand universe (i.e., the set of all ground terms) [51], and functions really map (tuples of) terms to other terms in .
On the ontology side, we have concepts (classes in programming language parlance), instances (also called individuals) that are members of concepts, attributes that are used to describe properties of instances, relations that relate instances to one another, and axioms (logic statements that say what is true in the domain of application). is the set of concepts, is the set of all terms, is the set of object identifıers denoting instances, is the set of relation names, and is the set of attributes. The term evolving ontologies comes about because update rules are used to change the values of object attributes and add/delete relation or concept instances to/from the working 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 of is as functions with domain and codomain ; that is, . Since , it is also true that , with the provision that if then ; that is, is not defined for elements of that are not in . For any ontology with attribute set , the actions of the choreography execution engine can be simulated by an ASM with vocabulary . 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.
Definition 1. An ASM state is said to correspond to an ontological state iff(i)whenever and and b[a->c] is true in , then and in ,(ii)whenever and is true in , then and = True in .
Definition 2 (move of an ASM). ~> denotes one step move of an ASM when it goes from abstract state to abstract state . ~ denotes the fact that an ASM goes from abstract state to abstract state in moves.
Definition 3 (move of a choreography engine). = denotes one step move of the choreography engine when it goes from ontological state to ontological state . = denotes the fact that the choreography engine goes from ontological state to ontological state in moves.
Theorem 4 (simulation of choreography engine execution by ASM actions). Let be a state of an ASM and be an ontological state. Let . If corresponds to and = then ~ 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 Section 3.2.1 (i.e., whenever in then -> is true in ) does not always work, since a function may be -ary, where . One possibility is to map functions of the ASM to relations of the ontology. Specifically, every -ary function of the ASM can be considered an -ary predicate of the ontology. Another possibility is to have an object called func, with locations as attribute names, and the value associated with the location as the value of the attribute. For example, if in the ASM, then -> 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 state is said to correspond to an ASM state iff whenever and f in SA then and and -> is true in .
Theorem 6 (simulation of ASM execution by choreography actions). Let be an ontological state and be a state of an ASM. Let be a location of the ASM}. Let . If ~ and corresponds to then = and corresponds to , provided that each action of the ASM is replaced by its corresponding action as specified in Table 4.
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 Algorithm 1, exactly as it is in [49]. In the algorithm, an update set is not consistent if it contains an insertion and a deletion of the same data simultaneously; otherwise it is consistent. A run is terminated if either (a) there is an update set associated with , , and such that is not consistent with with respect to , or (b) there is an update set associated with , , and such that , where denotes the state obtained after the actions specified in the update set are implemented.
| ||||||||||||||||||||||||||
3.4. Problems with the WSMO Choreography Algorithm
The algorithm presented in Section 3.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 () 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 the capability 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 Section 3.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 a successful 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 Algorithm 1. 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.
| ||||||||||||||||||||||||||||||||||||||||||
Our 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 a valid choreography interface run is replaced by a successful 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 a valid choreography interface run, which says nothing about the actual suitability of the web service to satisfy the goal demand, is abandoned in favor of a successful 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 a successful 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 elements ontology, capability, and choreography. Ontology contains frames and relations that represent knowledge used by the web service and goal. Capability element encloses two subelements, pre and post, 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 an if-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.
Appendix B 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 the main module and two Flora-2 user modules: WM for keeping the current state signature of the choreography and DeltaWM for keeping the actions for modifying the current state into a new state. The main 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, and DeltaWM) are interconnected, as shown in Figure 1.
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 Section 3.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 the choose 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 modules WM and DeltaWM 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.
| ||||||||||||||||||
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)).
| ||||||||||||||||||||||||||
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.
Listing 3 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 of forall rules, if the rule antecedent contains only ground facts, it models the ASM if-then transition rule type. If the antecedent contains free variables, it acts like the ASM forall transition rule type. In the case of a choose rule, the predicate invokeChoose randomly selects exactly one ground instance of the free variables existing in the antecedent of the rule.
| ||||||||||||||||||||||||||||||
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.
| ||||||||||||||||||
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 has in 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.
Listing 5 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.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 Appendix D 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.
Listings 6 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.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 choreography wsRule(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 type choose, 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, rule wsRule(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.
Table 5 shows what new knowledge is added to WM in each choreography round of a successful choreography, effectively tracing the execution of the choreography engine.
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 the Choose rule type,(iv)in the case of if-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 the Forall or Choose 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, and publisher. 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 the actor which has the initiative 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 predicate init-choreography to start the chain of rule firing and the action end-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 ASM if-then(-else), forall, and choose 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 C in 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.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Supplementary Materials
Appendix A: visual editor for Flora-2 based SWS specifications (VSCHOR). Appendix B: E-BNF grammar for Flora-2 goal and web service specifications. Appendix C: more choreography examples. Appendix D: choreography engine predicate list. Appendix E: converting JSON to flora-2. (Supplementary Materials)
Endnotes
- The meaning of the term consistent is essentially the same as in the original algorithm, but involves accessibility checks required by the declared modes of concepts as well.
- In Flora-2, logical implication can be shown by either p~~>q or ∖if p ∖then q. It is equivalent to ; however, Flora-2 also offers ∖if ∖then ∖else r which is equivalent to ; so in this case, if is not true, the proposition’s value depends on the value of .
- Due to space considerations, we only discuss the major predicates of the choreography engine implementation. Appendix in the Supplementary Materials contains the list of all predicates and their functionalities. Moreover, complete choreography engine source code is available in [27].