Choreography component meeting agenda (18th May): 1. Actions from last meeting: - Koustubh will continue to track BPEL TC progress on issue 147 etc. 2. Discuss recent developments in BPEL TC with regard to specification finalisation and Issue 147. 3. Discuss availability of hardware for testing and possible development - Windows (OK) - Linux (OK) - Solaris (OK) - AIX (unavailable) - HP-UX (unavailable) - other TPTP supported hardware/os? 4. Discuss how a BPEL process can interact with the client side workbench - Add discussion to the FAQ 5. Go over an example BPEL file which uses the proposed Issue 147 Attending: Antony Miguel (Scapa) Koustubh Parwar (CA) Augustus Kalimuthu (CA) Diana Vega (Fokus) Apologies: 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) Srinivas P Doddapaneni (Intel) George Christelis (Scapa) Shobhit Maini (CA) Tejas Patel (CA) Paul Brown (Fivesight) Marc Erickson (IBM) Point 1 & 2 discussion: Koustubh is continuing to track Issue 147. Discussion in the call today and examples of using Issue 147 will hopefully make more clear the requirements we have on the issue. Point 3 discussion: Scapa has certain hardware available for development and testing, namely: Windows Linux Solaris It is not at this time clear what hardware it is necessary for the choreography component to be tested and supported on. Koustubh's team is testing the URL test code only on Windows and Linux so it may be the case that developing and testing on Windows, Linux and Solaris is acceptable. Point 4 discussion: Marc Erickson brought up the question earlier on in the week of how a BPEL process can potentially interact with the workbench. Antony has added two entries in the FAQ which describe two ways a running BPEL process could interact with the client Workbench. The first of these is a description of how a BPEL process can (and will) connect to the workbench to exercise TPTP (or any other) APIs. First of all a WSDL file would be created which describe an API which maps to the actual API on the Workbench side. There are then two possible ways the BPEL process could gain access to these APIs using invocations. The first would be to access the APIs via a java binding. This would require the engine to have some part of the process running on the workbench machine and it would also require that the workbench APIs can be accessed by a separate JVM, outside of the Eclipse Workbench framework. The other possibility is that the choreography component client side code in the Eclipse Workbench could run a SOAP server which acted as a proxy to the implemented APIs. The best bet out of these two at the moment seems to be the SOAP server approach as it places no requirements on the placement of threads within the engine or on the engine deployment. The second FAQ entry describes how the user could potentially interact with a running BPEL process. This is much like a reverse version of the above. The BPEL process could implement a WSDL file and act as a web service, waiting for invocations using a or . The BPEL process would effectively be running a SOAP server as part of it's behaviour. The Eclipse Workbench client side could then connect to this SOAP server to pass data to the running BPEL process. The BPEL process could then react to this new data in any way it wished (e.g. copying data from the workbench into BPEL variables to modify the process behaviour). It should be noted that the BPEL process could either block for this information or the thread implementing the WSDL file (doing the or ) could be in a flow to make it listen for workbench input asynchronously with the rest of the process behaviour. Point 5 discussion: The new example file which demonstrates use of Issue 147 can be found at CVS HEAD org.eclipse.tptp.choreography examples test_bucket test_usecase_HttpLoadTest_ISSUE147.bpel The comments marked 'ISSUE 147' in the file describe the modifications but the basic requirements for a resolution to Issue 147 the component has are: 1. Without Issue 147, in order to run 1000s of copies of threads concurrently (e.g. as part of a load test), a flow must be created that has 1000s of copies of the same behaviour. This results in an unmanageably large BPEL file. 2. Issue 147 allows the number of copies of a parallel behaviour to be specified at runtime. This means the number of parallel threads in say a load test can be specified via a datapool endpoint or via some other part of the BPEL process behaviour. Other discussion: Koustubh asks how a BPEL process will gather data for storage in a TPTP model. For gathering data about the test, the BPEL threads running the test should take whatever measurements necessary or gather any information required such as how long a particular SUT invocation took (e.g. a URL request). This information can then be passed to another part of the BPEL engine by having a separate asynchronous thread implement a web service bound using the engine internal messaging binding. This means the thread that has gathered the data can speak to another part of the process as if it were a web service and can pass data into it for aggregation. This single thread receiving information from all the other threads can then aggregate the data and use the mechanisms described above to export the data into TPTP data models. In the case of data collection agents, the BPEL process could have threads which create and speak to data collection agents as WSDL bound endpoints in order to gather data from remote systems or APIs. This data can then be passed into the aggregation thread for exporting into the TPTP models in the same way as the test data. Diana has written a document requested on the website. She will email this to Antony for review and publishing to the website. Actions: - Koustubh will continue to track BPEL TC progress on issue 147 etc. - Antony will write an example BPEL file which demonstrates test data aggregation and data collection - Antony will write an example BPEL file which demonstrates Eclipse Workbench interaction (e.g. pause a running test)