Choreography component meeting agenda (8th June):

1. Actions from last meeting:
	- Antony will write an example BPEL file which demonstrates test data aggregation and data collection
	- Koustubh will continue to track BPEL TC progress on issue 147 etc.
	- Everyone should take a look at the public APIs and provide any feedback in the next meeting
	- Antony should add explanations of the launch config types to the beginners tutorial.
	- Antony should add explanations of the mini and main engines to the beginners tutorial.

2. Discuss design of the new public APIs and requirements anyone has on the APIs

3. Discuss BPEL provider extension point concept for launch configurations
	-used to run static BPEL files
	-provision for Vendor BPEL generation
	-potentially providers for BPEL example files

4. Recent developments
	-HTTP client implementation with connection pooling and keepalive
	-SOAP server + client improvements and bugfixing

Attending:
	Antony Miguel (Scapa)
	Koustubh Parwar (CA)
	George Din (Fokus)
	Diana Vega (Fokus)


Apologies:
	Augustus Kalimuthu (CA)


Absent:	
	Harm Sluiman (IBM)
	Serge Lucio (IBM)
	Jim Saliba (CA)
	Kent Siefkes (IBM Rational)
	Joe Toomey (IBM Rational)
	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 discussion:

	Antony has asked Paul Slauenwhite about how to distribute static example files (BPEL examples).  Paul has suggested
	that we use the logging extension point to provide example files (New -> Example) but we may want to use a 
	BPEL provider to be discussed in point 3 of this meeting.
	
	Issue 147 has been finalised at the BPEL TC June F2F (1st-3rd).  One amendment seems to imply that the parallel 
	attribute has been dropped but according to a member of the BPEL TC, this amendment has not been accepted and the 
	forEach activity will include parallelism.
	
	(the source of this information is the issues list at 'http://www.choreology.com/external/WS_BPEL_issues_list.html')
	
	This is great news for us as it means this will almost certainly make it into the final BPEL 2.0 specification.
	
	Diana has added info about the various launch config types and distributions to the beginners tutorial.  These
	will be uploaded to the website soon.
	
	Antony has added requests for 2 more documents to the website - one on using the engine under Debug mode
	and another on engine distribution.  There will be a delay before these are written as the Debug mode
	facilities are not yet completely developed and missing functionality and the distribution tutorial may
	be affected by deployment and load balancing.

Point 2 discussion:

	George suggests that the API should provide support for managing the output from the engine differently (e.g.
	having the data sent to an output stream rather than always to an Eclipse console.
	
	Antony: This output is only really there for debugging purposes - for example it shouldn't be used to gather
	information about test results etc.  The client should communicate with the BPEL process via SOAP etc to get
	that kind of well defined information.
	
	George: I know we should be using the SOAP APIs but we might want to have the general engine output
	sent somewhere other than an Eclipse console.
	
	Everybody agrees.
	
	Antony will make this change to the APIs.
	
	Koustubh is just back off vacation and will look at the public APIs for next week's meeting.
	
Point 3 discussion:

	Antony proposes that the Assets tab of the choreography launch configuration is removed in favour of a
	'BPEL Provider' tree that is populated via an extension point.
	
	A standard example of a BPEL provider would be a static file provider.  The user would create a launch
	config instance and select the static file provider as the BPEL provider.  There would then
	be a series of further tabs specific to that BPEL provider where the user could configure it (e.g.
	select a BPEL file to run).
	
	This makes for a very easy way for vendors to extend the choreography component and provide BPEL files
	potentially as intermediate files rather than source files.
	
	E.g. If a vendor wanted to run their tests using the choreogrpahy component they could write a BPEL
	provider where the user selected their testsuite file.  When the user then hit the run button the BPEL
	provider extension would be asked for the BPEL source file (and probably base location URI) based on
	the configuration.  The BPEL provider could therefore generate arbitrary BPEL based on any source
	configuration or resource.  It would also allow vendors to execute any test specific setup required
	for a particular test run (e.g. setting up SOAP servers for the BPEL to speak to or runtime UIs).
	
	Group generally thinks this is a good idea.  Antony will post an outline and basic requirements to the 
	tptp-platform-dev mailing list so that the group can discuss it and try to come up with a draft for next week.
	
Point 4 discussion:

	SOAP client and server have had various additions over the week including implementation of an HTTP client.
	
	During some performance testing using a BPEL behaviour speaking as a SOAP client to another BPEL behaviour
	acting as a SOAP server there were issues with using the standard sun HTTP client.  It did not appear to be
	managing keepalive and the connecion pooling well under heavy lead the client returned connection refused 
	errors (the connection pool was constantly growing and eventually the OS ran out of sockets).
	
	The new HTTP client implementation supports HTTP 1.0 and 1.1 including HTTPS SSL connections.  Antony will
	test the client against a range of standard web servers at some point but if anyone else wants to test the
	SOAP client/server or HTTP client/server then please do.

Other discussion:

	Koustubh: Are we planning on providing any UI for the choreography component?  Like a generic BPEL UI?
	
	Antony: We may provide a generic BPEL UI at some point in the future but 4.0 and 4.1 have been planned
	to concentrate on the base choreography layer to get that to a decent state first.  I was hoping that the
	Web Tools Project might come up with a BPEL editor.  We may want to follow this up and create an
	enhancement request.
	
	Koustubh: Could have a UI which would expose the generic BPEL capabilities but also allow for more
	specific purposes?  Like in the current test UIs we have a simple user interface where users can specify
	loops and invocations?

	Antony: We should be able to use the BPEL providers for this purpose.  One could imagine building a UI
	which was specific to a test type which a BPEL provider was able to then generate a behaviour for.  In fact
	for example you could imagine having a BPEL provider for the current URL test testsuites.  The BPEL provider
	would allow you to specify a URL testsuite as it's configuration and would then be able to generate BPEL 
	behaviour based on the behaviour contained within the model.  The current URL test UI could then still be used
	to edit the tests but the choregraphy could be used (seamlessly) to run them.  Once we have the BPEL provider
	extension point we could build any other sample tools in this same way - with their own specific interfaces
	but making use of the generic BPEL execution engine.
		

Actions:
	- Antony will write an example BPEL file which demonstrates test data aggregation and data collection
	- Antony will engine output support to the public APIs
	- Antony will post a requirements and outline document for the BPEL provider extension point to the 
	  TPTP platform dev mailing list so that the group can discuss it and come up with a draft for next week.