baryannis c ai-se2013_wssl_

WSSL: A Fluent Calculus-based Language for Web Service Specifications

George Baryannis and Dimitris Plexousakis

Computer Science Department, University of Crete

Institute of Computer Science, Foundation for Research & Technology - Hellas

June 17-21 2013, Valencia, Spain

OutlineIntroduction• The Need for Service Specifications• Motivating Example• The Frame, Ramification and Qualification Problems

Web Service Specification Language• The Fluent Calculus• WSSL Syntax• Decidability & Applicability

WSSL Validation Tool• WSSL to FLUX• Evaluation

Conclusions & Future Work2

The Need for Service Specifications (1)

• Service specifications can be employed for– Constructing a service based on a set of

requirements, provided as a specification

– Checking conformance of an existing service to a specification agreed upon by the parties involved

– Auditing processes that check third party or legacy code conformance

WSSL: Web Service Specification Language George Baryannis and Dimitris Plexousakis 3

The Need for Service Specifications (2)


• Service specifications can be employed for– Verification techniques: checking whether a

service satisfies a property (e.g. termination or temporal ordering of actions)

– Evaluation of the results of service adaptation or service evolution

– Detecting inconsistencies in a composite service

Motivating Example (1)


• Behavioral service specifications employ the precondition/postcondition notation– Prone to the well-known family of frame problems

• Service-based process for obtaining government-issued documents

Motivating Example (2)


The Family of Frame Problems (1)

• Frame Problem: how to effectively express what doesn’t change, apart from what’s changed– e.g. can we answer definitively that is the

only change caused by CheckPayment?• Ramification Problem: how to represent

knock-on and indirect effects (ramifications)– e.g. may lead to credit card invalidation if a

limit is reachedWSSL: Web Service Specification Language George Baryannis and Dimitris Plexousakis 7

The Family of Frame Problems (2)

• Qualification Problem: how to deal with qualifications that are outside our knowledge and result in inconsistent behavior (exogenous aspect)– e.g. preconditions of ExecutePayment are true before

execution, but postconditions aren’t after execution• All three problems adequately addressed by the

formalisms of the fluent and event calculi, and temporal action logic– largely ignored in the field of service science


Outline

9

Introduction• The Need for Service Specifications• Motivating Example• The Frame, Ramification and Qualification Problems



Conclusions & Future Work

WSSL Placement


WSDLGround

Semantics/Behavior

Higher-level

SAWSDL

OWL-S WSMO

WSSL

USDL

SoaML

Why employ the Fluent Calculus?

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

• The fluent calculus is bundled with FLUX, a logic programming implementation– Extremely valuable for creating tools related to

service specifications


Fluent Calculus Overview (1)

• Fluent: a single atomic property that may change– e.g. due to a service execution

• State: a snapshot of the environment– : state z contains fluent f

• Action: a high-level operation– e.g. a service execution

• Situation: a history of action performances


Fluent Calculus Overview (2)

• Action Precondition Axiom: – i.e. A is possible at situation s iff holds

• State Update Axiom:

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

• Inputs and Outputs: undefined in the fluent calculus– Introduce unary function symbols HasInput and

HasOutput and input/output formulasWSSL: Web Service Specification Language George Baryannis and Dimitris Plexousakis 13

WSSL Abstract Syntax (1)

• A WSSL specification is a 5-tuple , where:– : set of identifiers offering general information, e.g.

name, invocation details etc.– : set of input formulas– : set of output formulas– : set of action precondition axioms defining service

preconditions– : set of state update axioms defining service

postconditions– All elements are defined using WSSL logical expressions



• A WSSL logical expression is defined using the following alphabet:– A countable set of sorts: fluents, states, actions,

situations, boolean values– Logical connectives: – Quantifiers and equality: for every sort – A countably infinite set of variables– Nonlogical symbols: constants, function symbols (at

least Do, State, HasInput, HasOutput), predicate symbols (at least Poss)


WSSL Extensions (1)

• Causal relationships to solve the ramification problem: – E.g.

• State update axioms are rewritten as , with Ramify denoting the inference of ramifications

– E.g. )


WSSL Extensions (2)

• Accident modeling to solve the (exogenous) qualification problem, – : accident C occurs in situation s.

• To assume away accidents, a default logic theory must be employed – E.g. , under observations O and domain

axiomatization Σ.– a single universal default on the non-occurrence

of all accidentsWSSL: Web Service Specification Language George Baryannis and Dimitris Plexousakis 18

WSSL Extensions (3)

• Accidents are then integrated in specifications:– Action precondition axioms are rewritten as – State update axioms become disjunctive• E.g.


Decidability and Applicability

• WSSL’s design goal: high expressivity• Decidability results for the fluent calculus:– Situation calculus decidability results can be ported to the

fluent calculus– The two-variable fragment with counting, of the situation

calculus is decidable in NExpTime• WSSL at the same level as OWL-S or WSML– WSDL (or SAWSDL) can be used as ground languages– Existing OWL-S or WSML descriptions can be translated to

WSSL and annotated– WSSL can facilitate service validation, verification and

compositionWSSL: Web Service Specification Language George Baryannis and Dimitris Plexousakis 20

Outline

21





WSSL to FLUX

• A validation tool was implemented, that:– Parses a WSSL document (in WSSL/XML)– Translates it into FLUX– Validates a user goal (WSSL or FLUX) against the

specification• Translation to FLUX obeys the following mapping:

22

Evaluation (1)

• The validation tool was implemented using:– JAVA for the translation mechanism– the ECLiPSe CLP system for the validation process

• We investigated the scalability of the translation process – Synthetic WSSL specifications, ranging from 1 to

500 pairs of pre- and postconditions


Evaluation (2)

• Runtime stays under 600ms and memory consumption under 8000 KBs.

• The overhead of the translation process is insignificant.WSSL: Web Service Specification Language George Baryannis and Dimitris Plexousakis 24

Outline

25


Web Service Specification Language• The Fluent Calculus• WSSL Syntax• Complexity, Decidability & Applicability



Conclusions

• We proposed WSSL, a novel specification language for Web services based on the fluent calculus, that– accurately expresses the behavior of a service– expresses causal relationships between conditions– Accounts for and explaining unsuccessful executions

• A validation tool shows some initial capabilities– Validation goals can be checked against a given WSSL

specification– The tool, as well as all WSSL-related material can be

found online at http://www.csd.uoc.gr/~gmparg/research.html


http://www.csd.uoc.gr/~gmparg/research.html

Future Work


Integrate behavior specification and formality in service description in the lifecycle of Cloud-based services deployed on multiple Cloud providers (the Multi-Cloud approach)

Future

Support compatibility with other service description languages through suitable translation and annotation mechanisms

Next

Definition and development of a service composition and verification framework based on WSSL

Currently

Questions




baryannis c ai-se2013_wssl_

Technology

service specifications

wssl placement wssl

wssl extensions

field of service science

service evolution

wssl document

composite service

existing service