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
I want to
do
something
Mediator
This is how to
do it.
First step,
second step,
etc.
Service Provider
I can
give you
these
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
No Plan
No Plan
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
Mediator
Requirement
Service Provider(s)
WSDL-S
Planning
Validation
Execute
Create
Interaction
Protocol
Interaction
Protocol
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 Approach
Consists of four phases:
1. Client presents requirements via semantic
template
2. Provider creates a (set of) valid pseudooperations
3. Planner synthesizes processes using provider
defined interaction protocol (pseudooperations) 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 Approach
Besides the semantic annotation for “regular”
operatioins, Service Provider specify the
Interaction Protocol which is a set of pseudooperations
<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
operations
Initial
state
Goal
A
A
O1
A
A
O1
O1
B
B
B
C
C
B
literal
operation
O2
O3
C
O2
D
D
Plan → O1,O2,O4
O4
E
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
A
PO1
O1
O2
C
A
A
B
B
O3
C
C
literal
O4
Atomic operation
Psuedo operation
D
D
Plan → PO1, O4
E
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
O1
Output
Input
O2
Interaction Protocol Approach
• GraphPlan extracts a sequential “backbone”
execution path that can be converted to BPEL
– Includes pseudo-operation conversion
Plan w/ IP
Plan w/ Atomic
Operations
O1
PO1
BPEL
…
<Invoke O1>
O2
O4
<Invoke O2>
<Invoke O3>
O4
…
• Solution
– Process synthesized
using client’s
requirements and
internal planning.
– Service provider
provides pre-defined
pseudo operations to
make planning easier.
Service Provider 1
(CRM)
CompanyName
Search
Customer
CustId
Service Provider 2 (POM)
authToken
Contact
shipTo
Create
orderId
billTo
authToken
orderId
item
authToken
orderId
Add
orderId
lineItemId
orderId
Close
ItemNo
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 End
Thanks