A Novel Specification and Composition Language for Services

George Baryannis

Computer Science Department

Institute of Computer Science

PhD Defense Presentation

University of Crete

Foundation for Research & Technology - Hellas

Introduction

• Service Specifications• Service Composition• Synopsis of

contributions

Background

• Motivating Scenario• Representation

Problems• Composition

Requirements

Web Service Specification

Language (WSSL)

• Fluent calculus foundations

• Language syntax• Language extensions

2

Outline

WSSL Composition and Verification

Framework

•Implementation in FLUX•Functional and non-functional components

Experimental Evaluation

•Individual components•Overall evaluation

Conclusions and Future Research

•Contribution and Impact•Future research directions

3

Dissertation WordCloud

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• Research on service description has led to– Simple interface descriptions, possibly

semantically annotated – (SA)WSDL– Descriptions of inputs, outputs, preconditions and

effects (IOPEs) of a service, linked to ontology concepts – OWL-S, WSMO, USDL

• Move towards specifications of service behavior, accounting for any possible circumstance

4

Service Description

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• Service construction based on a set of requirements

• Conformance checks based on agreements between provider and consumer

• Auditing processes for third party or legacy code• Service verification against a property (e.g.,

liveness, safety)• Evaluation of service adaptation/evolution

results5

Why do we need Service Specifications?

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• Combining a set of services to achieve value-added functionality, unrealizable by existing services

• Can also benefit from specifications– Deduce composability by detecting

inconsistencies among specifications of participating services

– Make composite services available in the same way as atomic ones

6

Service Composition

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• Service specifications are vulnerable to the effects of the frame, ramification and qualification problems– Due to relying on conditions before and

after service execution– Largely disregarded in service science

• Service composition approaches– ignore these problems and their effects– focus on a specific subset of composition

requirements, disregarding others7

Research Challenges

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• WSSL: Novel service specification language– Addresses frame, ramification, qualification problems– Supports service composition, quality specification and

partial observability – Offers grounding, translation and integration mechanisms to

existing description languages• WSSL/CVF: Design-time composition and verification

framework– Relies on WSSL and inherits its features– Implements specification-based matchmaking– Supports QoS-awareness, non-determinism and partial

observability, among others8

Synopsis of Contributions

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

Background

• Motivating Scenario• Representation Problems• Composition Requirements

9

Outline

Introduction Web Service Specification Language (WSSL)

Experimental Evaluation

WSSL Composition and Verification Framework

Conclusions and Future Research

• Design a composite service and specification for a vehicle assistance process– Side-effects: credit card deactivation, mechanic log creation– Specify and explain results even under partial knowledge or

unforeseen circumstances– Satisfy local and global non-functional requirements

10

Motivating Scenario

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• How to represent succinctly that nothing else changes apart from what is stated

“Payment form “Credit card charged is completed” and invoice created”

• How do we express the guarantee that no other credit cards are charged, apart from the one included in the input payment form?

11

Representation Problems (1/4): The Frame Problem

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• How to adequately represent knock-on and indirect effects that might accompany primary ones

”Credit card charged and invoice created”

”Credit card deactivated”

• How do we express such ramifications?– In correlation with the frame problem solution– Preserving the distinction between primary and

secondary effects12

Representation Problems (2/4): The Ramification Problem

“Daily limit reached”

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• How to deal with preconditions that are external or unforeseen and result in contradicting the specified effects

”Report delivered via e-mail”

”Report delivered via traditional mail”

• How do we explain an execution where all specified preconditions are satisfied but no report is actually delivered to the user?

13

Representation Problems (3/4): The Qualification Problem

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• Specifications that act as a guarantee of behavior under any known circumstance– Especially important in case of information sensitivity

or critical domains• Prevent inconsistent behavior rooted in

ramifications• Provide explanations for unexpected

observations after executing a service• Equally important in the case of composite

specifications and service composition14

Representation Problems (4/4): Why deal with them?

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

15

Requirements for Automated Service Composition

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

Web Service Specification Language (WSSL)

• Fluent calculus foundations• Language syntax• Language extensions

16

Outline

Introduction

Experimental Evaluation

WSSL Composition and Verification Framework

Conclusions and Future Research

Background

• Representation problems adequately addressed in the formalisms of the fluent and event calculi, and temporal action logic

• Service specification requires a non-narrative-based formalism– No need for an explicit representation of time

• The fluent calculus is implemented as a logic programming system (FLUX – FLUent eXecutor)– Can be used to implement composition and

verification processes17

Why employ the Fluent Calculus?

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• Models service behavior based on fluent calculus notions– Fluent: a single atomic property, that may change

after a service execution– State: a snapshot of the environment, as a fluent

set• : a macro denoting state z contains fluent f

– Action: a service execution– Situation: a history of service executions

18

WSSL Syntax Overview (1/5):Fluent Calculus Foundations

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• WSSL specification: a 7-tuple

• service: set of identifiers offering general information

• input/output: service interface defined as formulas containing special / fluents:

19

WSSL Syntax Overview (2/5):Service Interface

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• WSSL specification: a 7-tuple

• pre: set of action precondition axioms

• post: set of state update axioms

a provably correct solution to the frame problem, provided that and are disjoint

20

WSSL Syntax Overview (3/5):Preconditions and Postconditions

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• WSSL specification: a 7-tuple

• causal: set of causal relationships linking effects to ramifications

• post: state update axioms rewritten using macro that denotes ramification inference

21

WSSL Syntax Overview (4/5):Solving the Ramification Problem

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• WSSL specification: a 7-tuple

• External or unforeseen qualifications modeled as accidents of the form

• default: default theory to assume away accidents– e.g., containing a single rule of the form

• Accidents integrated into pre- and postcondition axioms

22

WSSL Syntax Overview (5/5):Solving the Qualification Problem

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

• Extend WSSL to support control and data flow– Special function symbols to denote control

constructs

– Foundational axioms to express control and data flow semantics, e.g.,

23

WSSL Extensions (1/3):Service Composition

Sequence AND Split/Join

OR Split/Join

XOR Split/Join

Conditional Iteration

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

24

WSSL Extensions (2/3):Quality of Service

• Quality profiles incorporated in WSSL specifications– Sets of logical expressions expressing constraints of the

form <term> <operator> <value>– Language alphabet extended to support decimal values

and comparison operators• Correctness of profiles ensured by a pairwise

check of constraints, in terms of operators and values– QoS goal matching against profiles in the same manner

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

25

WSSL Extensions (3/3):Partial Observability

• Support for incomplete state specification using constraints on fluents, e.g.,– Negation: – Disjunction:

• Constraints included in state update axioms

with a set of fluents and Φ a set of constraints

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

26

WSSL Placement

Grounding to (SA)WSDLGenerating (SA)WSDL

OWL-S –to– WSSL WSML –to– WSSL

Integrate WSSL into USDLFunctional & Technical modules

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

WSSL Composition and Verification Framework

• Implementation in FLUX• Functional and non-

functional components

27

Outline

Introduction

Experimental Evaluation

Conclusions and Future Research

Background

Web Service Specification Language (WSSL)

28

Implementing WSSL in FLUX (1)

• Two customized versions of the original Prolog FLUX kernel that implement WSSL– With and without support for partial observability

(constraint handling)• WSSL planning problem: how to reach goal state ,

starting from initial state • WSSL plan: a sequence of service executions,

which is a solution to the problem iff – supports sequential-only plans– does not address issues of termination and

computation complexityIntroduction Background WSSL WSSL/CVF Evaluation Conclusions

29

Implementing WSSL in FLUX (2)

• Heuristic encoding of a WSSL planning problem: a FLUX program describing how to reach the goal state from the initial state– more restrictive heuristics decreased planning

complexity– Parallel, conditional and iterative execution can be

expressed• Clauses to handle control and data flow based on

the equivalent foundational axioms, e.g.,– poss_and(A,B,Z):-poss(A,Z), poss(B,Z), A\==B, A@<B.– state_update_and(Z,A,B,Z_PR):-state_update(Z,A,Z_1), state_update(Z_1,B,Z_PR).

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

30

WSSL/CVF (1/5):Satisfying Requirements

• Automation: via planning in FLUX• Dynamicity: WSSL plans are abstract• Semantics: all WSSL elements can be

associated to ontology concepts through IRIs• QoS-awareness, Nondeterminism and Partial

Observability: via WSSL’s extensions• Correctness: thanks to WSSL’s strong logic

foundations• Scalability: proven by experimental evaluation

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

31

WSSL/CVF (2/5):Functional Composition and Verification

• Functional composition through WSSL planning– Depends on designer’s expertise in defining heuristic

encodings• Verification focuses on answering questions about

composition behavior– Liveness properties: e.g., verify that plan realizes goals, by

proving that either emailed(report) or delivered(report)hold in the final state z.

– Safety properties: e.g., ensure that payment is performed for the correct payment form by proving holds(hasinput(payform), z_in), holds(paycompleted(payform), z_out)

– Explanations for unexpected behavior, e.g., no report delivery after executing the composition plan means accident failure(deliv)has occurredIntroduction Background WSSL WSSL/CVF Evaluation Conclusions

32

WSSL/CVF (3/5):Specification-based Functional Discovery

• Each task in abstract plans linked to one or more implementations, by comparing their specifications (S and T, respectively)– T must contain all fluents in the action

precondition axiom of S– All positive and negative effects in the state

update axiom of S must be in T’s as well– T must include all causal relationships of S

• Raises discovery to a higher level, relying only on the accompanying specifications– Results in a set of extended plans

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

33

WSSL/CVF (4/5):Extended Plan Pruning and Ranking

• Number and size of extended plans depends on– Size of the subset of abstract plans that are realizable– Number of concrete services per task

• Pruning to attempt to decrease complexity– Any concrete service that violates a local QoS goal is

discarded• Ranking to order remaining plans based on three

criteria1. Maximum plan length2. Total number of tasks per plan3. Domain/problem-dependent features

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

34

WSSL/CVF (5/5):QoS-based Selection

• Executed for each one of the ranked plans, until one is found that satisfies all global QoS goals– Best-case scenario: QoS-based selection executed

only for the top-ranked plan • Employ the algorithms defined in [Kritikos and

Plexousakis 2009] or [Mello Ferreira et al. 2009]– Depending on knowledge of execution path

probabilities for each plan• The optimal concrete plan can then be converted to

BPMN and executed

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

Experimental Evaluation

• Individual components• Overall evaluation

35

Outline

Introduction

Conclusions and Future Research

Background

Web Service Specification Language (WSSL)

WSSL Composition and Verification Framework

36

Experiments Setup

• Existing service descriptions and service test sets are unsuitable for our evaluation– Vast majority are in WSDL– Few use OWL-S, but are too simplistic

• We generated synthetic WSSL specifications– of complexity depending on the needs of each

experiment• Evaluation performed on an Intel® Core™ i7-

740QM, @1.73GHz, 6GB RAM• Computation time values are an average of 20 runs

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

37

Functional Planning Performance:Alternating Sequential / Parallel

Sequential-only Parallel-only

Specifications of1 or 2 IOPEs each

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

38

Functional Planning Performance:Parallel Compositions w/ Ramifications

Sequential-only

Using 50% of repository,ramifications forhalf of them

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

39

Functional Planning Performance:Alternating Seq/Par w/ Ramifications

Overall

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

40

Functional Discovery Performance

Matching a singlespecification against1000 ones

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

41

Pruning Performance:Success rate/No. of implementations per task

Exper. 1 Exper. 2 Exper. 3

100 plans (sequential)100 tasks per plan5 local goals

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

42

Ranking Optimality for different heuristics

Based on running exampleCase 1: no problem-dependent criteriaCase 2: preferring plans with both report delivery methodsCase 3: Case 2 + preferring plans with both SMS and call support

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

43

Overall Evaluation: Performance of first three phases

• Repository of 200 specifications– 45%: 1 IOPE, 30%: 2 IOPEs,

15%: 3 IOPEs, 7%: 4 IOPEs, 3%: 5 IOPEs

– 50% of all specs contain a ramification

• Planner resultsCase Plans Length1 3 92 5 9-103 20 9-124 112 10-145 2167 10-17

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

44

Overall Evaluation: QoS Selection Performance

• Using the algorithms of [Mello Ferreira et al. 2009]

• Cases 1-3: sequential plan with 9 tasks

• Cases 4-5: sequential plan with 10 tasks

• In all cases: 3 implementations per task, 3 QoS profiles per implementationIntroduction Background WSSL WSSL/CVF Evaluation Conclusions

Conclusions and Future Research

• Contribution and Impact• Research directions

45

Outline

Introduction

Background

Web Service Specification Language (WSSL)

WSSL Composition and Verification Framework

Experimental Evaluation

46

Contribution and Impact (1/2)

• Illustrate the effects of the frame, ramification and qualification problems in service description

• Provide a unified language for specifying all aspects of service behavior– solving all three representation problems– including support for quality profiles, service composition and

partially observable states• Employ WSSL as a basis for a design-time composition and

verification framework that– produces dynamic, QoS-aware and semantic-aware composite

processes,– establishing correctness and supporting partial observability– in an automated and scalable way

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

47

Contribution and Impact (2/2)

• Service providers: able to provide complete specifications of what they are offering– More effective communicating of their products– More likely to be trusted

• Service consumers: informed of the exact way a service is expected to perform– Make knowledgeable choices and find the most suitable

matches• SBA designers/Composition architects: composition

design and modeling effort significantly reduced– At the cost of an increased effort in service specification

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

48

Directions for Future Research (1/2)

1. Tool Support• Create a tool set to assist in – creating WSSL specifications from scratch– translating existing descriptions in (SA)WSDL, OWL-S,

WSMO– filling up information exclusive to WSSL• Extend WSSL/CVF with a visualization

component– view resulting compositions (e.g., as BPMN processes)– modify and execute them

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

49

Directions for Future Research (2/2)

2. QoS aspects of WSSL/CVF• Explore alignment and normalization procedures• Consider QoS decomposition approaches• Support soft constraints

3. Introduction of adaptation features • based on the proactive cross-layer monitoring and

adaptation approach of [Zeginis et al. 2012], [Zeginis et al. 2013]

4. Application in Cloud environments• Extend WSSL to include deployment information• Integrate WSSL/CVF in a Cloud deployment framework

Introduction Background WSSL WSSL/CVF Evaluation Conclusions

Publications

• Baryannis G., Kritikos K., and Plexousakis D.: WSSL: A Novel Specification and Composition Language for Services. To be submitted to IEEE Transactions on Services Computing. (2014)

• Baryannis G., and Plexousakis D.: Fluent Calculus-based Semantic Web Service Composition and Verification using WSSL. In ICSOC 2013 Workshops, A. Lomuscio et al., Eds. LNCS Series, vol. 8377. Springer International Publishing Switzerland, 256-270. (2014)

• Baryannis G., and Plexousakis D.: WSSL: A Fluent Calculus-Based Language for Web Service Specifications. In CAiSE 2013, C. Salinesi, M. C. Norrie, and O. Pastor, Eds. LNCS Series, vol. 7908, Springer Berlin Heidelberg, 256-271. (2013)

• Baryannis G., Carro M., and Plexousakis D.: Deriving Specifications for Composite Web Services. In COMPSAC 2012. IEEE Computer Society, 432-437. (2012)

• Baryannis G., and Plexousakis D.: Towards Realizing Dynamic QoS-aware Web Service Composition. In Proceedings of the PhD Symposium at the 8th IEEE European Conference on Web Services, W. Zimmermann, Ed. Institute of Computer Science, University Halle-Wittenberg, 37-40. (2010)

50

References

• [Kritikos and Plexousakis 2009] Kritikos K., and Plexousakis D.: Mixed-Integer Programming for QoS-based Web Service Matchmaking. IEEE T. Services Computing 2, 2, 122-139

• [Mello Ferreira et al. 2009] Mello Ferreira A., Kritikos K., and Pernici B.: Energy-Aware Design of Service-Based Applications. In ICSOS-ServiceWave 2009, L. Baresi, C.-H. Chi, and J. Suzuki, Eds. Lecture Notes in Computer Science Series, vol. 5900. Springer Berlin Heidelberg, 99-114

• [Zeginis et al. 2012] Zeginis C., Konsolaki K., Kritikos K., and Plexousakis D., Towards Proactive Cross-Layer Service Adaptation. In Web Information Systems Engineering – WISE 2012, X. Wang, I. Cruz, A. Delis, and G. Huang, Eds. Lecture Notes in Computer Science Series, vol. 7651. Springer Berlin Heidelberg, 704-711

• [Zeginis et al. 2013] Zeginis C., Kritikos K., Garefalakis P., Konsolaki K., Magoutis K., and Plexousakis D.: Towards Cross-Layer Monitoring of Multi-Cloud Service-Based Applications. In Service-Oriented and Cloud Computing, K.-K. Lau, W. Lamersdorf, and E. Pimentel, Eds. Lecture Notes in Computer Science Series, vol. 8135. Springer Berlin Heidelberg, 188-195

51