Service-Oriented Architecture (SOA) has emerged as a prominent design style that enables an IT infrastructure to allow different applications to participate in business processes, regardless of their underlying features. In order to effectively discover and use the most suitable services, service description should provide a complete behavior model, describing the inputs and preconditions that are required before execution, as well as the outputs and effects of a successful execution. Such specifications are prone to a family of problems, known in the AI literature as the frame, ramification and qualification problems. These problems deal with the succinct and flexible representation of non-effects, indirect effects and preconditions, respectively. Research in services has largely ignored these problems, at the same time ignoring their effects, such as compromising the integrity and correctness of services and service compositions and the inability to provide justification for unexpected execution results. To address these issues, this thesis proposes the Web Service Specification Language (WSSL), a novel, semantics-aware language for the specification and composition of services, independent of service design models. WSSL's foundation is the fluent calculus, a specification language for robots that offers solutions to the frame, ramification and qualification problems. Further language extensions achieve three major goals: realize service composition via planning, supporting non-deterministic constructs, such as conditionals and loops; include specification of QoS profiles; and support partially observable service states. Moreover, an innovative service composition and verification framework is implemented, that advances state-of-the-art by satisfying several desirable requirements simultaneously: ramifications and partial observability in service and goal modeling; non-determinism in composition schemas; dynamic binding of tasks to concrete services; explanations for unexpected behavior; QoS-awareness through pruning and ranking techniques based on heuristics and task-specific goals and an all-encompassing QoS aggregation method for global goals. Experimental evaluation is performed using synthetically generated specifications and composition goals, investigating performance scalability in terms of execution time, as well as optimality with regard to the produced composite process. The results show that, even in the presence of ramifications in some specifications, functional planning is efficient for repositories up to 500 specifications. Also, the cost of functional discovery per single service is insignificant, hence achieving good performance even when executed for multiple candidate plans. Finally, optimality relies mainly on defining suitable problem-specific heuristics; thus, its success depends mostly on the expertise of the composition designer.

1. 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

2. 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. 3
Dissertation WordCloud
Introduction Background WSSL WSSL/CVF Evaluation Conclusions

4. • 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

5. • 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
results
5
Why do we need Service Specifications?
Introduction Background WSSL WSSL/CVF Evaluation Conclusions

6. • 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

7. • 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 others
7
Research Challenges
Introduction Background WSSL WSSL/CVF Evaluation Conclusions

8. • 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 others
8
Synopsis of Contributions
Introduction Background WSSL WSSL/CVF Evaluation Conclusions

9. 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

10. • 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

11. • 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

12. • 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 effects
12
Representation Problems (2/4):
The Ramification Problem
“Daily limit reached”

13. • 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

14. • 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 composition
14
Representation Problems (4/4):
Why deal with them?
Introduction Background WSSL WSSL/CVF Evaluation Conclusions

15. 15
Requirements for
Automated Service Composition
Introduction Background WSSL WSSL/CVF Evaluation Conclusions

16. 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

17. • 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 processes
17
Why employ the Fluent Calculus?
Introduction Background WSSL WSSL/CVF Evaluation Conclusions

18. • 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

19. • 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

20. • 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

21. • 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
𝐷𝑎𝑖𝑙𝑦𝐿𝑖𝑚𝑖𝑡𝑅𝑒𝑎𝑐ℎ𝑒𝑑 𝑝𝑎𝑦𝑓𝑜𝑟𝑚, 𝑐𝐶𝑟𝑑 ∧ 𝑝 = 𝐻𝑎𝑠𝑂𝑢𝑡𝑝𝑢𝑡 𝑖𝑛𝑣𝑜𝑖𝑐𝑒 +
𝑃𝑎𝑦𝐶𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑 𝑝𝑎𝑦𝑓𝑜𝑟𝑚 ∧ 𝑛 = 𝐻𝑎𝑠𝐼𝑛𝑝𝑢𝑡 𝑝𝑎𝑦𝑓𝑜𝑟𝑚
→ 𝐶𝑎𝑢𝑠𝑒𝑠 𝑧, 𝑝, 𝑛, 𝑧 + 𝐷𝑒𝑎𝑐𝑡𝑖𝑣𝑎𝑡𝑒𝑑 𝑐𝐶𝑟𝑑 , 𝑝 + 𝐷𝑒𝑎𝑐𝑡𝑖𝑣𝑎𝑡𝑒𝑑 𝑐𝐶𝑟𝑑 , 𝑛, 𝑠

22. • 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

23. • 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.,
• 𝑃𝑜𝑠𝑠 𝑎1 ⋅ 𝑎2, 𝑠 ≡ 𝑃𝑜𝑠𝑠 𝑎1 + 𝑎2, 𝑠 ≡ 𝑃𝑜𝑠𝑠 𝑎1 ⊕ 𝑎2, 𝑠 ≡
𝑃𝑜𝑠𝑠 𝑎1, 𝑠 ∧ 𝑃𝑜𝑠𝑠 𝑎2, 𝑠
• 𝑃𝑜𝑠𝑠 𝑎1 ⋅ 𝑎2, 𝑠 ⇒ 𝑆𝑡𝑎𝑡𝑒 𝐷𝑜 𝑎1 ⋅ 𝑎2, 𝑠 = 𝑆𝑡𝑎𝑡𝑒 𝑠 + 𝜃2
+
− 𝜃2
−
+ 𝜃1
+
− 𝜃1
−
• 𝐻𝑜𝑙𝑑𝑠 𝐻𝑎𝑠𝑂𝑢𝑡𝑝𝑢𝑡 𝑓 , 𝑧 ⇒ 𝐻𝑜𝑙𝑑𝑠(𝐻𝑎𝑠𝐼𝑛𝑝𝑢𝑡 𝑓 , 𝑧)
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. 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. 25
WSSL Extensions (3/3):
Partial Observability
• Support for incomplete state specification
using constraints on fluents, e.g.,
– Negation: ¬𝐻𝑜𝑙𝑑𝑠 𝑓, 𝑧
– Disjunction: 𝐻𝑜𝑙𝑑𝑠 𝑓1, 𝑧 ∨ ⋯ ∨ 𝐻𝑜𝑙𝑑𝑠(𝑓𝑛, 𝑧)
• Constraints included in state update axioms
– 𝑃𝑜𝑠𝑠 𝐴 𝑥 , 𝑠 →
∃𝑦 𝛥 𝑠 ∧ ∃𝑦 𝑆𝑡𝑎𝑡𝑒 𝐷𝑜 𝐴 𝑥 , 𝑠 = 𝝉 ∘ 𝒛 + 𝜃+ − 𝜃− ∧ 𝚽
with 𝜏 a set of fluents and Φ a set of constraints
Introduction Background WSSL WSSL/CVF Evaluation Conclusions

26. 26
WSSL Placement
Grounding to (SA)WSDL
Generating (SA)WSDL
OWL-S –to– WSSL WSML –to– WSSL
Integrate WSSL into USDL
Functional & Technical modules

27. 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. 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 𝑎1, … , 𝑎 𝑛 of service executions,
which is a solution to the problem iff
𝑃𝑜𝑠𝑠 𝑎1, … , 𝑎 𝑛 , Φ 𝑧 ∧ Γ{𝑧/𝑆𝑡𝑎𝑡𝑒 𝐷𝑜 𝑎1, … , 𝑎 𝑛 , Φ 𝑧 }
– supports sequential-only plans
– does not address issues of termination and computation
complexity
Introduction Background WSSL WSSL/CVF Evaluation Conclusions

29. 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. 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. 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 occurred

32. 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

33. 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 criteria
1. Maximum plan length
2. Total number of tasks per plan
3. Domain/problem-dependent features

34. 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

35. 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. 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. 37
Functional Planning Performance:
Alternating Sequential / Parallel
Sequential-only Parallel-only
Specifications of
1 or 2 IOPEs each

38. 38
Functional Planning Performance:
Parallel Compositions w/ Ramifications
Sequential-only
Using 50% of repository,
ramifications for
half of them

39. 39
Functional Planning Performance:
Alternating Seq/Par w/ Ramifications
Overall

40. 40
Functional Discovery Performance
Matching a single
specification against
1000 ones

41. 41
Pruning Performance:
Success rate/No. of implementations per task
Exper. 1 Exper. 2 Exper. 3
100 plans (sequential)
100 tasks per plan
5 local goals

42. 42
Ranking Optimality
for different heuristics
Based on running example
Case 1: no problem-dependent criteria
Case 2: preferring plans with both report delivery methods
Case 3: Case 2 + preferring plans with both SMS and call support

43. 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 results
Case Plans Length
1 3 9
2 5 9-10
3 20 9-12
4 112 10-14
5 2167 10-17

44. 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
implementation

45. 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. 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. 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. 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. 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

50. 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

51. 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