Choreography component meeting agenda (15th June):

1. Actions from last meeting:
	- Antony will write an example BPEL file which demonstrates test data aggregation and data collection
	- Antony will add 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.

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. Discuss provision of example BPEL files to users
	- Should we expose BPEL to the users or should we generally expect to provide
	  more application specific sample tools which just use the choreography as an execution platform?
	  (should the BPEL examples be for developers rather than end users?)
	- If we do export examples to end users the end users will need to see and edit the BPEL
	  so might be better to use Import->Example and static file provider rather than an Example provider

5. Discuss need for public API other than BPEL providers
	- Is it necessary to have an API to run the engine separately from the providers launch configuration?

6. Discuss Daemon protocol changes
	- Daemon currently uses same protocol as engine instance
	- Daemon should use SOAP/HTTP or SOAP/HTTPS as it's only protocol
	- Although Daemon is not a public API it should have a different and more
	  standard protocol, otherwise development of the underlying engine instance
	  protocol will mean backwards compatibility issues for Daemon communication.

Attending:
	Antony Miguel (Scapa)
	Koustubh Parwar (CA)
	Augustus Kalimuthu (CA)


Apologies:


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

	Antony has not yet written the BPEL example to demonstrate test data collection and aggregation - moved to 
	an action for next week.
	
	Antony has not yet added engine output support to the public APIs as the public APIs are up for discussion
	in this meeting.

Point 2 & 3 discussion:

	Overview: 
	
	The BPEL provider extension point is an Eclipse extension point which allows plugins to register BPEL providers
	as tree nodes under the choreography launch configuration tabs.
	
	When the user clicks on one of these tree nodes the extension (BPEL Provider) will be loaded and asked to populate
	a number of tabs.  The user may then click on these tabs and use them to configure the BPEL provider.
	
	When the user has configured the provider to their satisfaction they can run the launch configuration.  When the 
	launch configuration is run the BPEL provider will be asked to provide a BPEL source file based on the user's
	configuration of that provider.
	
	Everybody is generally happy with this approach.
	
	
Point 4 discussion:

	General feeling is that some of our end users may be technical enough to want to play with BPEL and since we give
	them that opportunity we should provide them with examples.

	We cannot afford to support the behaviour in these examples in the case that it does not match the specification
	though so we MUST have a disclaimer at the top of each example file that states the BPEL specification as the 
	proper source of behaviour for any BPEL file, and that any deviations from that specification either in the 
	engine's interpretation of BPEL files or in the examples are considered bugs and will not be supported.

	Should talk to Harm or Tyler about whether this is OK.


Point 5 discussion:

	The current public APIs are a subset of the extension point and the more APIs we have the more APIs we have
	to maintain.  Given the new BPEL provider extension point, do we need the public APIs?

	Koustubh is probably ok with getting rid of public APIs but would like to give the matter some more thought.
	
	Antony will propose this on TPTP platform dev mailing list to get some discussion going before the meeting next
	week.
	

Point 6 discussion:

	Koustubh has another meeting to attend so this point will also be discussed on the platfom-dev mailing list.


Other discussion:
		

Actions:
	- Antony will write an example BPEL file which demonstrates test data aggregation and data collection
	- (Postponed pending discussions) Antony will add engine output support to the public APIs