Choreography component meeting agenda (16th March): 1. Actions from last meeting: - Antony should put the choreography docs on website (rather than in the plugin CVS) - Joe will try to get in touch with his contacts in IBM to ask about mapping WSDL bindings to UML - Koustubh will talk to Jim about joining the BPEL TC 2. Recent developments: - SOAP binding (invocations only) + examples - Choreography properties page 3. Discuss enhancements 50076 and 50080 4. Revisit Choreography UI: test type + launch configs - propose to have launch configs for general behaviours (we provide APIs and Web Tools can provide UI) and more specific sample tools which use choreography can produce specific test types (so no generic 'choreography' test suite type) 5. Review of test execution architecture and discussion of the possibility of a choreography based TPTP test execution 6. Discuss BPEL process distribution and deployment / load balancing presentation to user 7. Discuss what is planned for 4.0 and what dependencies there are on the Agent Controller Attending: Antony Miguel (Scapa) Srinivas P Doddapaneni (Intel) Koustubh Parwar (CA) Shobhit Maini (CA) Augustus Kalimuthu (CA) Diana Vega (Fokus) Absent: Harm Sluiman (IBM) Serge Lucio (IBM) Jim Saliba (CA) Kent Siefkes (IBM Rational) Joe Toomey (IBM Rational) George Din (Fokus) Scott Schneider (IBM Rational) George Christelis (Scapa) Paul Brown (Fivesight) Tejas Patel (CA) Point 1 discussion: Antony has not attempted to get the choreography documents on the website yet. Sri has problems getting docs on website too. Antony will talk to Melanie about getting access to the website and posting documents and let Sri know the results. Joe is unable to attend today but has been in touch with his contacts in IBM about mapping WSDL bindings to UML2. It seems that this is a large job - more discussion on this in point 3. Koustubh has not yet spoken to Jim about joining the BPEL TC but will try to speak to him by next week. Point 2 discussion: The recent developments are in CVS today. The SOAP binding should be able to deal with RPC and Document bound SOAP web services but only via invocations. We do not yet implement a SOAP server to translate , and bound as SOAP. Point 3 discussion: Joe, Marius and Antony discussed this in the test model yesterday and there will more more discussion of this point in the mailing lists in the coming days but the gist of the proposal is: Producing a BPEL to UML2 mapping (and vice versa) appears to be far too much work and it would appear no-one actually requires / wants the mapping. As such, it is proposed that a different solution is sought to fix the test model's deficiencies and eventually produce a modeled behaviour execution engine. It is therefore also proposed that the choreography component will not run modeled behaviours and only run BPEL behaviours. For users that wish to run arbitrary behaviours that use TPTP's APIs (e.g. statistical monitoring and aggregation) we will have the Launch Configurations. In addition to this, future or existing exemplary tools which are specific to a particular test type can make use of the choreography component by having their own test type which uses an external BPEL behaviour or uses a modeled behaviour which they then specifically translate to BPEL. So for the UI for the forseeable future, we will produce only the launch configurations. Exemplary test tools which wish to use the choreography component will provide their own specific testsuite editors. Users in the future that wish to create non test related behaviours will eventually be able to use the editors in the Web Tools Platform to build BPEL processes which use TPTP APIs. We can also provide simple BPEL examples which users can edit (either by hand in the short term or via the Web Tools Platform in the long term) to run common behaviours (e.g. simple load tests) Point 4 discussion: see Point 3 discussion above. Point 5 discussion: Scott Schneider isn't here today but this also ties in with Point 3 and 4 discussion above. Exemplary tools that wish to build on the choreography component could all do it in the same way. So given that new tools can build on top of the choreography, the old tools could potentially be ported. This may or may not be worthwhile. Point 6 discussion: The way distribution works in the engine is that if there is a single BPEL process that contains a flow, then all the activities in that flow are distributed evenly to run in parallel on all the hosts that make up the engine instance. Therefore to run a distributed load test it is only necessary to have and launch a single BPEL process which contains a flow with enough activities to run one activity on each of the hosts in the set of available hosts. However, in BPEL as the specification currently stands, it is necessary to statically define each invocation under the flow. It is not possible to dynamically specify the number of copies of an activity that should run in parallel. This means that if a user wanted to run a load test with 100 users in parallel, they would have to fully specify 100 activities under the BPEL flow. Issues 4 and 147 in the BPEL issues list are attempts to rectify this and are the main reason why TPTP needs some representation on the BPEL TC. Issues 147 specifies the concept of a parallel foreach, where it would be possible to specify the number of copies of an activity that should occur as an XPATH expression or as a variable. This would allow us to specify based on a variable how many users the load test should contain. This also brings up the issue of deployment of the threads created in the flow or in the parallel foreach. At the moment the engine evenly distributes any parallel threads across whatever hosts are available to the program. Ideally, the user should be able to specify whether they want activity A in flow F to run on host H1 or H2. When Issue 4/147 is fixed the user should also be able to specify how they want the dynamic number of users to be distributed (e.g. place 75% of users on host H1 and 25% of users on host H2). Antony proposes that this should be an extension to the BPEL which our engine can pick up. The extension could work something like: the activities under a flow can have an element which specifies weighting across machine distributions or even a specific host to run on. This could even be an XPATH expression or variable. Koustubh proposes that the weighting information could be in the Launch Configurations. Antony agrees that weighting information in the launch configurations is a good idea but that different vendors may want to do deployment differently. Weighting and load balancing information should therefore be in the Launch configurations for people that wish to not have any deployment information in their BPEL process but the engine should pick up on BPEL extensions and override the launch configuration weighting if the extensions are there. This caters for everyone. Koustubh mentions that in the current load testing example, the number of iterations each user makes is statically defined but that this information could be picked up from a BPEL variable. Antony agrees and will make this change in the future. Point 7 discussion: What dependencies does the Choreography have on the Agent Controller for 4.0? The Choreography engine is a separate entity to the Agent Controller, so as far as running BPEL processes it has no dependencies on the Agent Controller. However, the Choreography component is supposed to produce bindings for agents in 4.0. This means the agents need to be ported to new Agent Controller in 4.0 in time for the choreography bindings to be produced. Sri will produce Agent Variable Interface around halfway through i3. Other discussion: Actions: - Antony should put the choreography docs on website (rather than in the plugin CVS) and let Sri know about progress - Antony should Speak to Melanie about being able to commit docs to website and let Sri know about results - Koustubh will talk to Jim about joining the BPEL TC - Antony should edit the load testing example to make the number of iterations variable - Antony should produce a document discussing the distribution and deployment issues so that we can work towards agreement on how the deployment and the engine specific deployment extensions should work etc.