Choreography component meeting agenda (25th May):

1. Actions from last meeting:
	- 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)

2. Discuss any recent developments in BPEL TC with regard to specification finalisation and Issue 147.

3. New documents on the website
	- Beginners tutorial

4. New additions to the choreography component
	- SOAP <receive> and <reply>

5. Discuss API documentation etc and exposed APIs


Attending:
	Antony Miguel (Scapa)
	Diana Vega (Fokus)
	Augustus Kalimuthu (CA)


Apologies:
	Koustubh Parwar (CA)


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 cannot make the call today but there has been no important activity on issue 147.  Issue 147 is still open
according to the BPEL issues list and will still hopefully be resolved before the current BPEL specification is 
finished.

Antony has not yet written the example BPEL files to demonstrate data aggregation, data collection and Eclipse 
workbench interaction.  Antony will attempt to write these by next week.


Point 3 discussion:

Diana's beginner's tutorial has been added to the choreography documentation site.  Augustus will take a look at the
doc and provide any feedback.


Point 4 discussion:

The choreography engine SOAP binding can now translate SOAP bound <receive> and <reply> activities.  There is a new
example in the test bucket 'test_soapserver' which demonstrates one thread in flow acting as a SOAP client to another
thread in the same flow acting as a SOAP server.

If anyone has time then it would be great if they could test the SOAP client or server against existing SOAP clients 
or servers.


Point 5 discussion:

The choreography component must specify all it's provisional API in a subpackage marked 'provisional'.  These APIs
must be fully javadoc'd and example files which use the APIs must be provided.  Automated tests must be provided to 
test the APIs wherever possible.

The choreography engine external APIs will therefore be moved to a 'provisional' package and example files which use
the APIs will be added.

These will hopefully be ready some time this week so if everyone should take a look at the APIs to spot any problems 
and more importantly ***to identify any deficiencies or missing functionality in any APIs which they plan to build on***

If anyone is planning to build on the choreography component in 4.1 then they should take a look at the provisional
APIs to make sure they are sufficient.


Other discussion:

Augustus: A Runner currently appears to have a unique runner ID associated with it but also a 'waiter ID'.  Is it
possible to use the same ID for both of these purposes?

Each runner is assigned a unique ID composed of the controller's (host's) index in the engine, and the runner thread's 
index in the controller.  This is used as a general unique identifier for the runner.  The waiter ID is not a separate
ID owned by the Runner but it is a temporary assigned to any thread that uses the ControllerConnection messaging
methods (e.g. sendAndReceiveMessage).  When any thread uses these methods it is assigned a waiter ID so that it can be
easily and efficiently identified for receipt of the return message.  The reason the waiter ID does not use the runner 
ID is firstly because it is not only runners that use these methods (the ControllerConnector class which is a client
side implementation of ControllerInterface uses them), and secondly because the UIDPool which is used to assign waiter
IDs always assigns ids from 1 to N where N is the number of concurrent IDs in use.  This means that the ID can be used
as an index to an array of waiting threads rather than having to use the ID as a hashmap key to a waiting thread 
(which would mean a much more expensive hashmap index instead of a practically free array index).


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)
	- Augustus will take a look at the new beginners tutorial on the choreography documentation page
	- Antony will commit API changes before the next meeting