Choreography component meeting agenda (16th Feb): 1. Discuss volunteers to join Oasis.org BPEL Technical Committee on behalf of TPTP choreography component 2. Discuss the design of enhancement 50076 3. Compare current execution of TPTP test types with choreography Attending: Antony Miguel (Scapa) Joe Toomey (IBM) George Din (Fokus) Diana Vega (Fokus) Koustubh Parwar (CA) Absent: Harm Sluiman (IBM) Serge Lucio (IBM) Jim Saliba (CA) Kent Siefkes (IBM) Point 1 discussion: Koustubh knows two people in CA that are already on the BPEL TC but are disengaged. He will get in touch with these people and try to get (one of?) them to represent us on the TC, potentially including representation on the BPEL TC calls. This would be great as it would give us access to the BPEL TC mailing list and leeway to clarify parts of the spec, but also potentially the ability to influence parts of the specification which are important to us (e.g. Issue 4 / 147) Point 2 discussion: Joe has not been in touch with his contacts in IBM about mapping WSDL bindings to UML. He will try to get in touch with them for next week. Point 3 discussion: How does BPEL test creation look to the user? There are two main areas of enhancements relating to the generation of Web Services tests. The first is the implementation of the BPEL engine to provide a platform to run the behaviours. The second is the implementation of the bindings so that the behaviours can do useful things and generate test results in the same way any other TPTP tests do. Current thinking is that we would keep the launch configuration as a part of Platform so that users could use the bound APIs we provide in combination with non-test related behaviours and we would also provide a testsuite editor which allowed users to do basically the same thing but to run more test-oriented behaviours. Joe wonders that, given that the functionality provided by the launch configurations may conflict with vendor's functionality, what is the purpose in TPTP of providing the launch configurations to run arbitrary BPEL behaviours? The launch configurations allow users to run arbitrary behaviours that use our APIs (e.g. profiling and logging) without having to wrap them up as a test. What are some examples of these non-test behaviours (given that they should still fall within the scope of TPTP / logging / profiling etc) ? Some time ago there was discussion about having information in the statistical model to aggregate metrics (e.g. produce a single observation to represent the average of two other observations). The result of these discussions showed that it would be necessary to have a full programming language in the statistical model to properly fulfil this requirement. BPEL provides an answer for this. If we expose the statistical model APIs to the BPEL then the BPEl can perform any aggregations we like for us (e.g. we could monitor the CPU on machines A and B and store an average CPU in the statistical model). Agreement that the launch configurations should be a part of TPTP. How are we intending to expose TPTPs APIs such as the model APIs? Regardless of how we choose to access the APIs we can just wrap a WSDL interface around them at some point and write the binding to access them underneath. Are we expecting to expose these in 4.0? Yes, there are enhancement requests for creating WSDL bindings for standard TPTP APIs. Have the relevant committers been notified they have to produce these APIs in 4.0 (e.g. Joe has not heard of any request for a binding to the execution history API)? The Test Model team has produced EMF APIs that other components can use. It is therefore the job of the choreography component to come up with its own bindings to any of these APIs in order to expose them in the BPEL. Therefore there are no dependencies - the choreography component will come up with all standard WSDL bindings for TPTP APIs. Back to the original question, this leaves us with a launch configuration to run non-test behaviours and a testsuite editor to run "Web Services" tests (Some discussion about the name "Web Service" test type as this may imply to most people that it can only speak to what most people think of as web services over SOAP/HTTP. Essentially a naming issue, can be resolved later). Most obvious way forward for choreography test type is to reinstate prototype testsuite editor in a test project plugin that uses the choreography plugin in platform. Is everyone happy with the concept of a choreography plugin for this purpose in the test project? Yes. Is everyone happy with the initial functionality of the testsuite editor being similar to the launch configurations? Yes. In the future when the choreography component is more mature it may be beneficial to think about providing templates for certain types of tests via the choreography testsuite editor. Koustubh wonders if we could have the URL test type use BPEL instead of it's current behaviour? Joe is uncertain about the benefit to the user of such a scheme. Koustubh agrees that there is no benefit to the user but there are benefits to the developer as they only have to generate BPEL instead of writing a whole test-type-specific execution engine. There is also the benefit that the production of a test-type specific binding means any BPEL behaviour can use that test type. Some uncertainty as to whether this would mean replacing the URL test's behaviour with BPEL or just the execution step but: Could we have the URL test generate to BPEL to take advantage of the generic BPEL engine instead of generating to a URL test specific engine? Joe raised some concerns about BPEL's flexibility to recreate the behaviour of the URL test engine to generate load accurately. Antony expects that BPEL would be flexible enough to use to generate complex load tests as Scapa expects to recreate their load test logic in BPEL. Does the current engine run BPEL on the workbench client using multithreading etc? There are two implementations of the BPEL engine at present. One is a simple, local implementation that uses multithreading and runs in the workbench JVM. The other is a distributed engine that is capable of sharing load across multiple machines. Does the distributed engine work via the AC? No, the distributed engine has it's own daemon and communication systems. There was some discussion some time ago about the AC and the Choreography engine sharing a transport layer but it never got much traction. At some point it may be necessary to hook up the launch of the choreography engine daemon to the AC so that the AC can be used to start the choreography daemon on any required machines. This will reduce problems of users having to maintain two daemons on their machines. Actions: - Joe will try to get in touch with his contacts in IBM to ask about mapping WSDL bindings to UML