fluent calculus-based semantic web service composition and verification using wssl

Fluent Calculus-based Semantic Web Service Composition and Verification using WSSL

George Baryannis and Dimitris Plexousakis

Computer Science Department, University of Crete

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

December 2nd 2013, Berlin, GermanySWESE 2013

OutlineIntroduction• Service Specifications in the Semantic Web• Web Service Specification Language• Motivating Scenario

Composition and Verification of WSSL services• WSSL for Composition• Planning with WSSL• Verification capabilities

Experimental Evaluation• Implementation with FLUX• Evaluation

Conclusions & Future Work2

Service Specifications in the Semantic Web (1)

• Service behavior can be formally modeled using semantic specifications– in the form of Inputs, Outputs, Preconditions and

Effects (IOPEs)– using concepts defined in ontologies

• Such specifications drive the complete service lifecycle– Automated and effective composition based on

accurately defined service behavior– Verification of (composite) service properties against

such specificationsFluent Calculus-based Semantic Web Service Composition and Verification using WSSL George Baryannis and Dimitris Plexousakis 3


• Specifications including pre/postconditions are prone to three well-known problems in AI literature

1. Frame Problem: how to effectively express what doesn’t change, apart from what’s changed, based on a specification– e.g., how to answer definitively whether a money

withdrawal service doesn’t affect other accounts

2. Ramification Problem: how to represent knock-on and indirect effects (ramifications)– e.g., invalidate a credit card after the latest transaction

causes a daily limit to be reached 4Fluent Calculus-based Semantic Web Service Composition and Verification using WSSL George Baryannis and Dimitris Plexousakis


3. Qualification Problem: how to deal with qualifications that are outside our knowledge and result in inconsistent behavior– e.g., all preconditions hold for a money

withdrawal service but no effects occur after executing it

• We addressed all three problems by defining the Web Service Specification Language (WSSL), a formal semantic language based on the fluent calculus 5Fluent Calculus-based Semantic Web Service

Composition and Verification using WSSL George Baryannis and Dimitris Plexousakis

WSSL Overview (1)

• Service behavior is modeled using the following 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

6Fluent Calculus-based Semantic Web Service Composition and Verification using WSSL George Baryannis and Dimitris Plexousakis

WSSL Overview (2)

• Action Precondition Axiom: , i.e. A is possible at situation s iff holds – used to represent service preconditions

• State Update Axiom: – used to represent service postconditions

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

• Inputs and Outputs: represented by input and output formulas


WSSL Overview (3)

• Causal relationships to solve the ramification problem:

• Accident modeling to solve the qualification problem– Action precondition axioms are rewritten as , to express

the default case, where no accident has taken place– State update axioms now include a disjunct for each

accident case (apart from the default no-accident case)

• WSSL specifications can be translated to FLUX programs, a fluent calculus implementation in logic programming with constraint handling


WSSL Placement

9

WSDLGround

Semantics/Behavior

Higher-level

SAWSDL

OWL-S WSMO

WSSL

USDL

SoaML

Fluent Calculus-based Semantic Web Service Composition and Verification using WSSL George Baryannis and Dimitris Plexousakis

Motivating Scenario (1)

10

• Service-based process of assisting vehicle drivers– Users contact road assistance via call or SMS– Driver’s location and vehicle status are retrieved and a search for

the most suitable mechanic is conducted– After resolving the issue a payment process follows and a report is

sent to the driver by post or e-mail• Given a set of service specifications, we want to automatically

create a composite process that realizes the scenario– Taking into account ramifications of services– Determining execution results even under unforeseen

circumstances– Verify the composability and correctness of a candidate composite

processFluent Calculus-based Semantic Web Service Composition and Verification using WSSL George Baryannis and Dimitris Plexousakis

Motivating Scenario (2)


WSSL for Composition (1)

• Extend WSSL to support control and data flow– : , denoting sequence, AND-Split/AND-Join, OR-

Split/OR-Join, XOR-Split/XOR-Join– , denoting conditional execution– , denoting iterative execution

• Preconditions and postconditions governed by foundational axioms, e.g.:

• Foundational axiom for data flow: 13Fluent Calculus-based Semantic Web Service


Planning with WSSL (1)

• Service composition is realized via WSSL planning

• WSSL planning problem: how to reach goal state defined by , starting from initial state defined by – e.g., FLUX encoding of the motivating scenario

• WSSL plan: a sequence of service executions, which is a solution to the problem iff



• Introduce heuristics to – produce more than sequential-only plans– address issues of termination and computation

complexity• Heuristic encoding of a WSSL planning problem: a

FLUX program describing how to reach the goal state from the initial state

• As the heuristics grow more and more restrictive, the complexity of the planner decreases (and termination probability increases)



• The most restrictive example encoding for the motivating scenario:assist_plan(Z,[A|P],Z_PR) :- A1=receivesms(_,_), A2=receivecall(_,_), A=xor(A1,A2), poss_xor(A1,A2,Z), state_update_xor(Z,A1,A2, Z_1), assist_plan1(Z_1,P,Z_PR).assist_plan1(Z,[A|P],Z_PR) :- A1=retrievelocation(_,_,_), A2=retrievediagnostics(_,_,_), A=and(A1, A2), poss_and(A1,A2,Z), state_update_and(Z,A1,A2,Z_1),assist_plan2(Z_1,P,Z_PR).assist_plan2(Z,[A|P],Z_PR) :- A=findmech(_,_,_), poss(A,Z), state_update(Z,A,Z_1), assist_plan3(Z_1,P,Z_PR).assist_plan3(Z,[A|P],Z_PR) :- A=receivepay(_, _), poss(A,Z), state_update(Z,A,Z_1), assist_plan4(Z_1,P,Z_PR).assist_plan4(Z,A,Z_PR) :- F=req_deliv(REPORT), A1=ereport(_,_),A2=mreport(_,_), A=if(F,A1,A2), poss_if(F,A1,A2,Z), state_update_if(Z,F,A1,A2,Z_PR).

• Any answer to the FLUX query assist_plan([callcenterup, gpsactive(user1), systemactive(vehicle1), req_deliv(report1)], P, Z_PR).

yields a plan that realizes the goals of the scenario


Verification Capabilities

• Focus mainly on answering questions about the behavior of produced compositions– Liveness properties: e.g., to prove that the produced plan realizes

the goals, we prove that either holds(emailed(report,z) or holds(delivered(report, z) in the final state z.

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

– Explanations for unexpected behavior, thanks to WSSL’s accident modeling, e.g., no report delivery after executing the composition plan means accident failure(deliv) has occurred


Implementation with FLUX

• Composition (and verification) goals and candidate service specifications expressed in WSSL are translated into FLUX – JAVA used for the translation mechanism– the ECLiPSe CLP system to execute FLUX queries


Evaluation (1)

• To investigate scalability of the composition process we varied planning problem complexity– by increasing service repository size (at the same time

increasing the difficulty of achieving the goal)– by allowing for more elaborate plans

• Experiments relied on synthetically generated specifications containing an IOPE quad (plus a causal rule for the final experiment)

• Composition plans examined contained sequential, parallel and alternating combination of sequential and parallel constructs


Evaluation (2)

• Runtime stays at reasonable levels for up to 500 services and peaks to 4sec for 1000 services and sequence/parallel combinations

• The inclusion of ramifications (a 50% increase in the size of specifications) leads to a significant increase in runtime)– In real-world problems only some postconditions are expected to be linked

to a ramification21

Conclusions

• We proposed a service composition and verification framework using WSSL, a novel specification language for Web services based on the fluent calculus– satisfying significant requirements such as automation, dynamicity,

and non-determinism– supporting rich, semantic behavioral descriptions of services and

compositions– exploiting WSSL’s solutions to the frame, ramification and

qualification problems• The framework is an effective demonstration of

– the benefits of semantic specifications in the context of service science

– the way to exploit such specifications for the purposes of service composition and verification 23Fluent Calculus-based Semantic Web Service


Future Work

24

Support knowledge states and comprehensive modeling of partially observable behavior, asynchronous service execution, and derivation of executable business processes

Future

Improve efficiency by investigating complexity for different heuristics, limiting search space before planning, exploring graph-based rule optimization

Next

Extending WSSL to support quality aspects so as to achieve QoS-aware service composition and verification

Currently

Fluent Calculus-based Semantic Web Service Composition and Verification using WSSL George Baryannis and Dimitris Plexousakis

Questions

George Baryannis and Dimitris Plexousakis 25

http://www.csd.uoc.gr/~gmparg/research.htmlFluent Calculus-based Semantic Web Service Composition and Verification using WSSL

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