Choreography component meeting agenda (19th Jan):

1. Discuss any objections or queries about the design of enhancement 50076 in so far as it relates to the choreography component

2. Discuss requirements/architecture/end user scenarios of the current choreography BPEL engine

3. Discuss choreography plugin refactoring and packages before drop into 4.0 CVS



Attending:
	Antony Miguel	
	Kent Siefkes
	Koustubh Parwar
	Tejas Patel
	Shobhit Maini
	Augustus Kalimuthu


Absent:	
	Harm Sluiman
	Serge Lucio
	Jim Saliba




Point 1 discussion:

No-one attending has any comments on the 50076 design



Point 2 discussion:

What are the requirements for the choreography work? requirements are defined by the enhancement requests planned in TPTP 4.0.  The main two driving requirements are for a new Hyades test type to test web services and for the eventual development of a framework that will allow users to execute native TPTP test behaviours

What are the end user scenarios?  These are not well defined at the moment as there is design work to be done to define what the user experience should be for the various TPTP 4.0 enhancements.  Generally by end of 4.0 the user should be able to create a new Choreography test type similar to the HTTP test type, then specify and potentially create/edit a group of BPEL, WSDL and XSD files to run as a web services test.

Does the current engine generate execution histories or statistical models?  No, the choreography engine generates no TPTP assets or models at the moment but in the future we will provide standard WSDL endpoints to access these APIs, allowing BPEL programs to generate and populate execution histories and statistical models.

What problems are we likely to face as a result of our engine being able to distribute a single BPEL process over multiple machines?  This is mainly a problem defined by the bindings the engine uses.  Bindings can be split into two groups - those that are stateful and those that are not.  SOAP is an example of a binding that is not stateful.  As long as the correct information is passed in a conversation can be started on one machine and finished on another.  Java is an example of a binding which is stateful, if a an endpoint is used on one machine then it may not be possible to continue using that endpoint on another machine (that machine might have certain state in the JVM or machine's memory which precludes this).  The thing that defines whether it is ok to switch to a different machine is the existence of correlation sets across invocations.  If a number of invocations are correlated and the binding used is stateful then the threads performing those invocations must be on the same machine to ensure that the particular port implied by the correlation sets is available to all the threads.

Koustubh had connect exception errors when trying to distribute a run over multiple machines.
This was probably because the choreography daemon was not running on all machines.  Each machine must have a copy of the choreography engine and must be running the daemon in order to host part of a test run.

What happens under the covers when a user has created a test composed of BPEL, WSDL and XSD files and they launch the test? 
Firstly the BPEL, WSDL and XSD files that make up the test are translated into Java source code.  This Java source code is then compiled using the standard Eclipse JDT compiler into Java class files.   The workbench client then connects to the choreography daemon running on the machine specified as the major controller host (the engine uses a star topology where there is a single major controller coordinating one minor controller on each host that will run part of the test).   The workbench client sends across the class files which are then propagated to each sub controller.  The method in the compiled class files which maps to the initial sequence in the original BPEL is then run and the test is now running.

What is the overlap between the choreography engine and the Agent Controller?  Is the choreography engine expected to replace the Agent Controller?  The choreography engine is not expected to replace the Agent Controller.  The choreography engine will always deal with the Agent Controller as a web service wrapped and bound by WSDL.  This is also the case for all TPTP standard interfaces such as model generation APIs etc.  The engine must access all APIs via WSDL endpoints otherwise it will be using methods which are proprietary to our engine which will exclude the possibility of swapping in another BPEL engine implementation.



Point 3 discussion:

No-one attending has any comments regarding the plugin refactoring.  Koustubh would like more time to look at the packages and structure of the code in the light of new information from this meeting.  We can discuss this further in the next meeting.



Other discussion:

Everybody on the call is OK with Mondays at 2pm GMT




Actions:

Antony should update the doc to explain Koustubh's problem when running a distributed engine