METEOR-S Project Entry for SWS Challenge Phase II Using Planning for Process Mediation

1. 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

2. The problem of Process Mediation Mediator Client Service Provider This is how to do it. First step, second step, etc. I can give you these I want to do something

3. Process Mediation –SWS Challenge 2006

4. 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

5. 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

6. Interaction Protocol Approach for Process Mediation Mediator Service Provider(s) Client Requirement WSDL-S Planning Create Interaction Protocol Validation Execute Interaction Protocol

7. 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.

8. Interaction Protocol Approach Consists of four phases: • Client presents requirements via semantic template • Provider creates a (set of) valid pseudo-operations • Planner synthesizes processes using provider defined interaction protocol (pseudo-operations) as well as other operations • Final plan validated and used by consumer (final BPEL process is deployed)

9. Compose the solution on the fly • Constraints for planning come from: • Semantic requirements (preconditions, post-conditions, input, and output ) from the client (WSDL-S) • Precondition, effect, input, and output from the providers (WSDL-S) • Interaction protocol from the providers

10. 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>

11. Interaction Protocol Approach Besides 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>

12. 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

13. 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 A A O1 O1 O1 B B B O3 B C C C O2 O2 D literal D O4 operation Plan → O1,O2,O4 E

14. 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 A A PO1 O1 B B O3 O2 C C C D literal D O4 E Atomic operation Plan → PO1, O4 Psuedo operation

15. 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 Output Input O1 O2

16. 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 BPEL … O1 PO1 <Invoke O1> O2 <Invoke O2> O4 <Invoke O3> … O4

17. Service Provider 1 (CRM) CompanyName Search Customer • Solution • Process synthesized using client’s requirements and internal planning. • Service provider provides pre-defined pseudo operations to make planning easier. CustId Service Provider 2 (POM) authToken Contact shipTo billTo Create orderId authToken orderId item orderId lineItemId Add orderId ItemNo authToken orderId Close

18. Architecture

19. 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

20. The EndThanks