meteor-s project entry for sws challenge phase ii using planning for process mediation
DESCRIPTION
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. Mediator. Client. Service Provider. - PowerPoint PPT PresentationTRANSCRIPT
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