meteor-s project entry for sws challenge phase ii using planning for process mediation

METEOR-S Project Entry for SWS Challenge Phase II

Using Planning for Process Mediation

John Harney, Karthik Gomadam, John Miller, Amit Sheth, Kunal Verma, Zixin Wu

LSDIS Lab,

University of Georgia

The problem of Process Mediation

Client Service Provider

I want to do

something

I can give you

these

Mediator

This is how to do it.

First step, second step,

etc.

Process Mediation –SWS Challenge 2006

Using Planning in Process Mediation• Planning Problem

– Find an execution path of services (tasks) given some state of the world to achieve a goal

– Classical planning algorithms use combinatorial search, backtracking and branching to secure a plan

Plan

No Plan

No Plan

Using Planning in Web Service Composition• Planning Problem

– With many operations available, planning using these techniques:

• Becomes computationally complex (at times infeasible)

• Gives less desirable plans

– Need a method that alleviates planner complexity and retrieves “smart” plans

Interaction Protocol Approach for Process Mediation

Client Service Provider(s)

Mediator

InteractionProtocol

Requirement

CreateInteractionProtocol

Planning

Execute

Validation

WSDL-S

Interaction Protocol Approach for Process Mediation• Bottom-up (Process Synthesization)

– Construct a plan given:• Client’s requirements

i.e. preconditions/input, postconditions/output (goals)• Provider’s available operations (preconditions/input,

effects/output)• “Pseudo”-operations – combined operations

determined by the provider; encapsulate human knowledge.

Interaction Protocol ApproachConsists of four phases:

1. Client presents requirements via semantic template

2. Provider creates a (set of) valid pseudo-operations

3. Planner synthesizes processes using provider defined interaction protocol (pseudo-operations) as well as other operations

4. Final plan validated and used by consumer (final BPEL process is deployed)

Compose the solution on the fly

Constraints for planning come from:

1.Semantic requirements (preconditions, post-conditions, input, and output ) from the client (WSDL-S)

2.Precondition, effect, input, and output from the providers (WSDL-S)

3.Interaction protocol from the providers

Interaction Protocol Approach• Client’s requirements can be captured in

Semantic Template (WSDL-S)

For the SWS Challenge 2006:

<wsdl:operation name="sendPO"> <wssem:precondition expression="haveCompanyInfo"/>

<wsdl:input message="impl:PIP3A4POR"/><wssem:postcondition expression="completeOrder ^ closeOrder"/>

</wsdl:operation>

Interaction Protocol ApproachBesides the semantic annotation for “regular”

operatioins, Service Provider specify the Interaction Protocol which is a set of pseudo-operations

<wssem:interactionProtocol><wssem:pseudoOperation name="placeOrder">

<wssem:precondition expression="haveCustomerID"/><wsdl:input message="impl:PlaceOrderRequestMessage"/><wsdl:output

message="impl:CloseOrderResponseMessage"/><wssem:effect

expression="haveOrderID^completeOrder^closeOrder"/><wssem:process>

mooncompany:OMServicePortType:createNewOrder ; mooncompany:OMServicePortType:addLineItem * ; mooncompany:OMServicePortType:closeOrder

</wssem:process></wssem:pseudoOperation>

</wssem:interactionProtocol>

Interaction Protocol Approach• Planner uses GraphPlan algorithm

– Represents possible plans using expandable graph data structure

– Alternating layers of ground literals and actions (ground instances of operators)

– Represents the literals and actions that might occur at each time step

– Attempts to extract plan when goal level of literals is reached

Interaction Protocol Approach

• GraphPlan example (Preconditions -> “A ^ B” Goal -> “E”)– If preconditions exist for operation:

• Operation placed in sequential path• Effects of operation placed in new state

– Expansion continues until goal is reached– Plan is composed by backtracking to the initial level through

operationsInitial state Goal

literal

operation

A

O1

O1

O2

O1

O2

O3

O4

A

B

C

D

E

A

B

C

D

B

A

B

C

Plan → O1,O2,O4

Interaction Protocol Approach• Graphplan Example with pseudo-operations

– Pseudo-operations reduce graph complexity (execution path length, number of actions, etc) with human defined super-operations

Initial state

Goal

literal

Atomic operation

Psuedo operation

O4

O3

O1

O2

A

CC

D

B

AA

B

C

D

E

PO1

Plan → PO1, O4

Interaction Protocol Approach• GraphPlan extended

– Must also check whether output of one operation semantically matches the input of the next operation in sequence

• Need to refer both to ontology

InputOutputO1 O2

Interaction Protocol Approach• GraphPlan extracts a sequential “backbone”

execution path that can be converted to BPEL– Includes pseudo-operation conversion

Plan w/ IP

PO1

O4

O1

O2

O4

Plan w/ Atomic Operations

BPEL

<Invoke O1>

…

<Invoke O2>

<Invoke O3>

…

Service Provider 2 (POM)

Create

Add

Close

authToken

Contact

shipTo

billTo

orderId

authToken

orderId

item

orderId

lineItemId

authToken

orderId

orderId

ItemNo

SearchCustomer

CompanyName

CustId

Service Provider 1 (CRM)• Solution

– Process synthesized using client’s requirements and internal planning.

– Service provider provides pre-defined pseudo operations to make planning easier.

Architecture

Demo

• Open ProcessMediator.swf in IE or Firefox (requires Flash)

• Inputs:– Client Template: Blue_SemanticTemplate.wsdls– Provider Services: CRMService.wsdls,

OMService.wsdls

• Output– generatedProcess.bpel

The EndThanks