200 likes | 543 Views
Repair and Planning. UNIKLAG Milano WP3 meeting, 30-11-2006 WS-DIAMOND. TOC. Repair as planning task Current approaches Repair Reasoner component Our inputs/outputs Assumptions Applying repair Demonstration (our view). Our dimension. Sustainability: Class repair Instance repair.
E N D
Repair and Planning UNIKLAG Milano WP3 meeting, 30-11-2006 WS-DIAMOND
TOC • Repair as planning task • Current approaches • Repair Reasoner component • Our inputs/outputs • Assumptions • Applying repair • Demonstration (our view)
Our dimension Sustainability: • Class repair • Instance repair Cooperation style: • Fully orchestrated • Choreography Level: • IT infrastructure • Service Repair of composite WS Controllability: • Interruptible • Non interruptible Design of processes: • Correct orchestration • Failure in orchestration Properties of service provision: • Functional • Non-Functional properties (QS, e.g. time, cost, …)
Repair as planning • 1 Compute repair plan - all the sets of redo, compensate, adjustment, skip actions; • 2 Select which repair actions shall be deactivated; • 3 Make ordering on the repair scheme and select the repair action to be executed first; • 4 Execute this repair action; • MIGRATE to new process (with includes repair actions and the rest of workflow) OR • insert repair actions to paused workflow and resume it • 5 Estimate the new state of the workflow instance; • 6 Select which repair actions shall be activated; • 7 If repair scheme contains no activated repair action - exit; • 8 If needed regenerate all repair plan - go to step 1; • 9 Go to step 3;
Assumptions • Some activities have WF behind • Actions: COMP, REDO, DO • Repair with concurrency is possible! • Each condition in repair plan corresponds to condition in the workflow model • Objects are not shared in parallel blocks
DLV-K and MBP(NuPDDL) • DLV-k: • Plans with concurrency (repair actions in parallel) • No conditions: need extra stage of business-logic or tricks • MBP: • PDDL-dialect based • Conditional plans • No concurrency • Linux-based • Works too slow……
Example x1_1, x2_1, g_1 are ok a1 x1_2 a2 x2_2 x2_2 a3 way2 way1 a4 x1_3 x1_2;x1_3 a5 g_2
Example plan : DLV-K Initially: x1_1, x2_1, g_1 are ok executed(a1). executed(a2). executed(a3). -executed(a4). executed(a5). -compensated(a1). -compensated(a2). -compensated(a3). -compensated(a4). -compensated(a5). actuell(x1_2). actuell(x2_2). actuell(g_2). -oka(a1). -oka(a2). okv(x1_1). okv(x2_1). okv(g_1). branchwillbetaken(w2). -branchwillbetaken(w1). branchwastaken(w1). -branchwastaken(w2). a1 ab x1_2 ab a2 x2_2 x2_2 a3 way2 way1 a4 x1_3 Correct solution: comp(a5), comp(a2), redo(a2), redo(a3), a4, redo(a5). Generated solution: x1_2;x1_3 a5 g_2 √
a1 a1 ab ab x1_2 x1_2 ab ab a2 a2 x2_2 x2_2 x2_2 x2_2 a3 a3 way2 way2 way1 way1 a4 a4 x1_3 x1_3 x1_2;x1_3 x1_2;x1_3 a5 a5 g_2 g_2 COMP(a2), REDO(a2), REDO(a3), ……………
WFMS (ActiveBPEL, JBPM) Global Diagnoser execute Exception info Execution log WF model Repair Reasoner append √ Repair plan ? ? jPDL code BPEL code Out inputs / outputs
Our inputs • WF model: • Diagnostic model as proposed by Torino • Which format is still unclear • BPEL code • We need an example to try to process • Execution log: • Proposal by Milano, OK ! • Exception info: • From Diagnosis • In which format? We need an example (Torino)
Our outputs • Plan: • We can generate: • BPEL code (on the base of activities & plan) • jBPM code • Any other format – which one is expected???
Applying repair • To perform this step one of two possibilities can be used: • stop the paused workflow, generate totally new one, migrate there the state of old workflow and start new one. • somehow tell the WFMS that before resuming the paused workflow the repair plan can be performed.
Repair Reasoner WS • RR is a usual web service with has some operations and as output generates plans in some form • Each session works with one workflow (there are NO general view, privacy guaranteed), there may be used many RR services for different partners’ workflows • Information about goal/infected objects is propagated between sessions as additional parameter • Type of repair action to be applied is propagated between sessions as additional parameter • ? : who invokes RR?
Propagations WF2 WF1 inf x5 a10 x7 y6 a0 gd ab x6 x5 gd inf a11 x5,x6 y2 inf a1 gd y1 x2 a12 x4 y3 a2 x3 y2 a13 inf gd x6 y5 way2 way1 a3 x6,y6 inf a14 x3 x2 y2 a4 a5 x1 x1 y2,y7 a15 inf x2
Repair Reasoner WS : operation “generate plan” Model, log, diagnose, [repair action, i/g obj] Also set of goal dependent/infected objects GPT/MBP: Linux, K-lang:Windows Repair Reasoner Web Service nuPDDL / k-lang ? Invoke external application Tomcat Axis ? ? BPEL plan Include IDs of session for low-level workflows BPEL ask/inform other sessions about goal/infected objects, repair actions
Repair Reasoner WS : operation “check plan” Plan, log, diagnose, SessionID Repair Reasoner Web Service Compare old/new values Check dependencies Eliminate non-goal/non-infected Tomcat Axis Ok / new needed
Repair Reasoner WS : operation “new goal dep/infect” SessionID, new set of goaldep/infect Repair Reasoner Web Service Restore model a) Model Already exists regenerate repair plan b) Model Not yet exists fix data (be ready for the future) Tomcat Axis BPEL
Demonstration process • WFengine started (ActiveBPEL/jBPM) • Detection started • Abnormal behaviour detected • Diagnosis provided • Repair Reasoner WS session invoked (by whom?) • Repair plan generated • Somehow(?) applied • Workflow changed/new created (??) • Workflow resumed (???) • ???? We need activity (collaboration) diagram