While the overall approach in the system model follows existing Semantic Service frameworks in a number of respects, we have introduced several generalizations, namely the notion of representants and the precondition and effect systems. Moreover, we were able to seamlessly combine the different aspects of services: their execution, non-functional, change, and data semantics. The latter especially makes the data format aspect of services explicit by providing a characterization of the notion of data compati- bility. Finally, we have taken great care to formulate it in a general way so as to separate practical choices from the conceptual basis.
The main components and layers that are combined in the system model are sum- marized in Figure 4.7. Apart from the interpretation, all layers (vertical axis) are parametrized along one or more dimensions, which constitutes various degrees of free- dom on how the model can be instantiated. On the other hand, we made simplifications at two places that account for the fact that we are concerned with the service execution task. These are the reduction to the single process to be executed (though a service might specify multiple different processes) and the one profile/grounding on each operation
to be invoked in the course of process execution. In this regard, the system model might be seen as tailored for the service execution task.
K A
·
I·
DΔ
DΔ
I Individuals Eternals T aI CI vD drD RI TI t1 tjoin pi tfork pf t3 t4 t2 sub service Op fu time fchk Pr.P Pr.E fup U Sc1 Sc2 invo ca tion co m p le ti o n Scn fu conc urre ncy In te rpretati on Repr esen tation Spec ificatio n Executi o nFigure 4.7: Summary of the system model depicting its main layers.
The representation and specification layer are parametrized along DLs. Leaving aside decidability, computational complexity, and determinism properties of reason- ing especially over preconditions and effects, the model can be instantiated in principle with any DL that provides the basic subsumption inference. Yet it is precisely these aspects that limit the possibilities in theory as well as in practice. For example, a DL- based effect system that allows for disjunctive, existential, or universal restricted con- cepts as effects renders the change semantics of services/operations to be no longer deterministic in general (this would equally be introduced in the presence of TBoxes and the use of atomic concepts as effects that are defined possibly indirectly in terms of these three constructors). Furthermore, while for all “classical” DLs consistency is a prerequisite33 for the subsumption inference, it is widely recognized that inconsistent
33Or, as [PT09] put it more succinctly: “the contemporary logical orthodoxy has it that, from contradic- tory premises, anything can be inferred”.
knowledge may naturally appear in many domains. Not surprisingly, reasoning un- der inconsistency recently gained considerable momentum in Semantic Web research (e.g., [MH09, FH10, NS10, ZLW10]). The system model is in principle amenable for such a paradigm shift; its potential and ramifications have not been explored, how- ever, in this thesis. This applies equally to other reasoning paradigms such as statistical, probabilistic, inductive, or abductive reasoning.
Related to the choice of the actual DL is the choice for the OWA versus CWA. Also, whether the UNA is adopted or not. These are two more parameters of the model. In controlled and closed application environments where one can assume that all relevant information is available, adopting the CWA is fully satisfactory since negative infor- mation (e.g., ¬allergicTo(ALICE, PENICILLIN)) does not need to be maintained then. The picture is different, however, in open environments such as the Web. Ultimately, the answer to the question whether OWA or CWA should be used in an open environ- ment depends on what conclusions that are drawn from reasoning are used for. For instance, if a conclusion is the basis of a risky decision then the OWA (combined with the prudence principle) is supposably a better choice. Consequently, adoption of OWA versus CWA should be decided on a case by case basis, rather than making a general decision. This calls for flexibility in an implementation, meaning that the decision for OWA versus CWA should be a query-specific rather than a global fixed parameter.
The system model is further parametrized with precondition and effect systems. This is mainly motivated by the fact that there is (still) no general purpose framework on the change semantics and reasoning about change.
To complete this summary, the system model is neutral to how execution is orga- nized. In practice, an execution system can be centralized in the sense that a single instance is responsible for coordinating correct enactment of a service instance. Con- versely, a distributed and possibly decentralized execution system can as well be used in which multiple peers cooperate on fulfilling the task. The consequence of distributed execution is the need to support shared access to the KB as there are multiple peers that query and update it. The demand for distributing the KB itself might “naturally” arise in this case in addition. Finally, the conceptual basis of the system model does not rule out concurrency, which is natural in almost any domain, as no simplifying assumptions are made in this regard.
5
Forward Failure Handling using CFI
B
ASED ONthe system model for Semantic Service execution introduced in the previ- ous chapter, in this chapter, we describe our method to achieve optimistic while forward-oriented failure handling to the service execution task. We call it Control Flow Intervention (CFI), named after its main characteristic. The basic idea is to intervene in the control flow of a composite service execution in the presence of a failure by mod- ifying its process specification so as to get a semantically equivalent execution and to finally resume execution using the modified control flow. The change that the control flow undergoes is consequently made in the midst of execution and can therefore be classified as dynamic.Dynamic change within workflows or (business) processes is not a new research topic. Early works that address the problem on a conceptual level in the context of workflow systems date back to the mid-nineties (e.g., [EKR95]). What distinguishes CFI from conventional approaches is its second main characteristic of being optimistic and forward-oriented. Optimistic entails that what the change of a service in the presence of a failure will precisely be is determined ad hoc based on what failed rather than in ad- vance. The change made to recover from a certain kind of failure is thus not pre-defined. CFI thereby provides an additional level of flexibility. Forward-oriented, on the other hand, means that one aims at finding a replacement that results in a semantically equiv- alent (or similar) outcome when executed instead. These two properties make CFI com- plementary to conventional failure handling methods such as transactional rollback and compensation or pre-defined exception and fault handlers. The overall context classi- fied along (i) the time when recovery means are specified and (ii) what kind of recovery results can be modeled is depicted byFigure 5.1and shows where CFI is located.
A key element herein is the notion of a replacement that provides a semantically equivalent (or similar) execution. In order to achieve the goal of ad hoc creation of a replacement, mainly two problems need to be addressed. First, how to define a formal and decidable notion of equivalent (or similar) execution that meaningfully captures the intuition of humans. Second and closely connected, what techniques can be used to find or create a replacement. With respect to the former, we exploit the information on the semantics of services and their operations available through their profile, the pro- cess, and partly also the grounding. We propose two different notions of equivalent
inverse countervailing equivalent similar Recovery result backward-oriented forward-oriented rollback compensation ad -h o c-d efin ed pre -defi ned Recovery m ea n s CFI exception, fault, compensation handler transactional
Figure 5.1: CFI in relation to conventional failure handling approaches.
execution that are close from a semantic point of view, but differ with respect to the techniques used to find/create replacements. More specifically, the first notion relies on service matchmaking techniques by formulating the process of finding a replacement as an iterative matchmaking problem. The second is strictly more general and relies on AI planning techniques by formulating it as a planning problem. While semantic matchmaking and planning are prominent on their own in semantic services research, we are focused on streamlining existing methods in these fields to provide an integrated approach with our service model, which has it that, amongst other aspects, the change semantics is modeled as a query answering and a belief update problem over a DL knowledge base.
We will furthermore discuss how the notion of equivalent execution can be broad- ened towards similar execution. This is worthwhile especially for application domains in which one cannot assume that the notion of equivalence is appropriate in the sense that it is too strict to be effective. Conceptually, we see a close link to the area of planning with soft goals that involves an optimization problem. We therefore sketch a solution by reducing it to so-called net-benefit planning problems. As a side effect, the notion of similar execution thereby defined also allows to include non-functional properties.
The remainder of this chapter is organized as follows. We start by providing a high level overview on how CFI would work in practice in Section 5.1. The types of sys- tem environments and the types of failures to which CFI is applicable are detailed in
Section 5.2. In Section 5.3we then introduce the notion of a replacement from a syn- tactic point of view. The core part of this chapter is Section 5.4 in which we address the problem at the conceptual level from a semantic point of view. The two notions of functionally equivalent execution are introduced and corresponding techniques are de- scribed to search for respectively synthesize replacements. InSection 5.5we clarify how the proposed techniques affect the correctness property of guaranteed termination put
Instantiation Execution Completion resume replace detect pause find 1 2 4 5 3
Figure 5.2: Integral activities forming the Control Flow Intervention cycle.
forward by transactional processes. In Sections5.6 and5.7we discuss different related aspects. Finally,Section 5.8concludes.
5.1
The Basic Control Flow Intervention Cycle
From a high level procedural point of view, CFI is divided into a cycle of actions de- picted inFigure 5.2. Once a service has been instantiated by an execution engine, failure detectors monitor all relevant execution events (1). In case an event has been detected that is classified as a failure, the engine pauses execution at the earliest possible moment (2), meaning that it temporarily stops working off the control flow. While this is simple to implement for sequential control flows with a single execution thread, pausing a ser- vice instance with parallel flows involves a decision: pause all threads or just the one in which a failure event has been detected. The former is indicated if the recovery strategy includes the case that the entire service execution is to be aborted. The number of oper- ations that would need to rollback (or compensate) in this case is thereby reduced to a minimum. On the contrary, if the recovery strategy is purely forward and guaranteed to succeed, all non-faulty execution threads can continue without the need to pause them. The decision is therefore a matter of the recovery strategies.
The following step (3) is the core part. It comprises all the actions that are started then by the engine to find a qualifying replacement for a part of the service, which might minimally be a single operation up to subflows. Once a replacement has been found, the engine then carries out the substitution by modifying the control and data flow accordingly (4). Whether a replacement found is reviewed and accepted by a user prior to substitution is an aspect not in the center of this work. The case in which step (3) terminates in failure because a replacement does not exist and how this case is further handled is left out from Figure 5.2. It should be clear that this is the event in which a conventional recovery strategy would kick in.
Execution finally resumes with the new replacement (5). This last step of the cycle is equally straightforward to pausing the execution. To conclude, steps (1), (2), (4), and
(5) are accompanying management steps of secondary relevance and are therefore not further addressed in this chapter.