Workflow Early Start Pattern and Future's Update Strategies in ProActive Environment E. Zimeo, N. Ranaldo, G. Tretola University of Sannio - Italy

Outline Introduction Workflow Early Start Pattern Future’s Update Strategies Conclusions

Early Start Workflow Pattern

Background A Workflow Management System is able to execute distributed applications described as processes composed of a set of activities Activities are functionalities provided by participants distributed in the Internet Workflow engine is the component delegated to coordinate the process execution

Introduction Objective: to improve the Workflow management system  Improvement of performance  Easiness of modelling Focus: distributed applications composed with resources handled as services or sub- processes that are coarse-grained modelled

Problem In the majority of workflow languages, processes can be seen as the combination of:  Serial activities (Sequence pattern)  Parallel activities (And-split pattern) Sequences are the critical point for performance improvement Several researches are involved in enhancing performance by improving sequential execution Anticipation of activities is a key issue to obtain performance enhancement Anticipation means that an activity is enacted before the prefixed time of enactment

State of Art Two approaches: Improve process execution changing it at design time  Coo-Flow allows for modelling task anticipation and intermediate results propagation Improve process enactment modifying the way processes are executed  Micro Workflow introduces future objects in workflow management  SWFL exploits multilevel parallelism in workflow enactment

Design Time Approach The former approach requires analysis of activities at greater level of detail: fine-grained analysis If the activities could not be considered atomic their internal structure could be analysed to improve performance Intrinsic parallelism could be exploited Activity B could be decomposed in two sub-activities: B’ is the independent sub-activity B’’ is the dependent sub-activity

Equivalent Flow The process description may be modified Partial overlapping of process. This shorten the total process time

Consequences Fine-grained analysis can be used to obtain anticipation at design-time At least a point exists, in the depending activity, that signals the beginning of data dependencies from the preceding activity Problems:  Additional design effort  Finding dependence point could be difficult or could be impossible  The internal structure is not accessible  Several dependence points could exist  The modified process could become more complex

Solution Our proposal is to use a run-time approach to relax the sequence constraints:  Partial concurrency could be obtained overlapping execution of activities at run-time  A lot of modelling situations could be seen as intermediate between serial and parallel  Use of data flow synchronization during execution Fine-grained concurrency at run-time

Resulting Execution Sequence Fine-grained concurrency

Modelling technique To ease modelling, we have defined a new workflow description pattern: Early Start Pattern Activity in the pattern could be executed by the engine with fine-grained concurrency … <xsd:attribute name="FlowType" type="xsd:string" use="optional"/> …

Requirements Use of a system that could dynamically discover the dependence point  Asynchronous invocation, returning a placeholder for the result not computed yet  Placeholder could be forwarded to subsequent activities as actual parameter to satisfy the activation conditions and so anticipating the activation  Activities that receive the placeholder and try to access to the data must be stalled until the data is ready to be used  The placeholder must be updated as soon as possible to each activity that uses it

ProActive To implement Early Start we used ProActive It satisfies the four requirements:  Invocation on Active Object returns a symbolic placeholder: the Future Object  Future Object could be forwarded  Threads trying to access to Future Object, before it is updated, are placed in waiting state  The Future Object is updated with the computed result

Evaluation Worst case: 3,5% Best case: 43% … … <Transition Id="AB" From="A" To="B" FlowType="early"/> public void process() { String resultString; resultString = A.elaborateString(); C.printString(resultString); }

Evaluation (2) Improvement 15%

Considerations Fine-grained analysis at design time is more difficult and could be even impossible Fine-grained concurrency could be used to improve performance, without increasing the modelling effort Early Start pattern keeps the modelling simple and ensures automatic optimization at run-time

Implementation Issues Ideal enacting Real enacting

Eager Forward strategy Future Engine B A A (run) A Future B (run) Value B Current ProActive implementation

On demand strategy Central Memory Future Engine B A A (run) A B (run) Value B

Future’s Update Strategies

Future updating techniques Forward vs Home (Who?)  Forward: updating is responsibility of the object that forwards the future  Home: updating is responsibility of the object that computes the value of the future Eager vs Lazy (When?)  Eager: all the futures are updated as soon as the value is computed  Lazy: the futures are updated only for the object that requires the value

Value_r1 UPDATE ACB Future_r1 Future_r2 UPDATE Value_r1 UPDATE Value_r2 Eager Home-Based The AO that computes the value is responsible of updating it to all the futures

Further Consideration ABCDE Future_r1 All the AOs that receive a Future Object ask for updating but not all of them use the value Updating Value_r1 Only E uses the value of theFuture Object Is it worth to update all nodes? F r1 = b.create(size)

Lazy Home-Based ABCDE Future_r1 Request Updating Value_r1 Only E is updated Updating only who needs the value Value_r1 Proposal: updating only the nodes that use the value of the Future Object

Experimentation (1) Testing application ABC2C1C3 Future_r1 Future_r1 = b.create(size) c1.use(r1) C4 c2.use(r1) c3.use(r1) c4.use(r1) We have measured the time needed to update value to the object C1, C2, C3 and C4 in different cases

Experimentation (2) All nodes require updating AB C2 C1 C3 C4 Future Object 1MB Lazy-Home and Eager- Home perform the same Both of them are better than Eager-Forward

Experimentation (3) Only 1 node needs update AB C2 C1 C3 C4 Future Object 1Mb Lazy Home is better than Eager Home by 29% Lazy Home is better than Eager Forward by 36% Eager Home is better than Eager Forward by 1,5%

Conclusions Workflow and Web Services composition:  Improving performance with run-time concurrency  Easy modelling with Early Start Pattern ProActive middleware:  Eager-Home & Lazy-Home updating strategies  Experimentation and comparison of the different strategies

Future works Workflow and Web Services composition:  Extension of asynchronous call to Web Services, with a client side based invoker  Web service model extension to transfer ProActive features to Web Services  Introducing the possibility of “partial result return” ProActive middleware:  Eager-Home strategy with multicast  Lazy-Home with distributed garbage collection

Thank you for your attention