Choreography component meeting agenda (23rd Feb):

1. Actions from last week:
	- Joe will try to get in touch with his contacts in IBM to ask about mapping WSDL bindings to UML
	- Koustubh will talk to contacts in CA that are already on the BPEL TC about representing TPTP

2. Discuss the design of enhancement 50076

3. Review of test execution architecture, choreography architecture and discussion of the possibility of a choreography based TPTP test execution


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

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)




Point 1 discussion:

Joe is unable to make the call today but he has been in contact with the people he mentioned in IBM who are doing the UML->BPEL mapping.  They will send him some of their work to help us understand how we can map WSDL bindings to UML.


Koustubh was unable to get in contact with his contacts in CA about representing us on the BPEL TC.  He will try to get in touch with them and let everyone know when he has.



Point 2 discussion:

Koustubh: can you elaborate on the UML to BPEL mapping issues?  The original purpose of the choreography component was to produce an execution framework whereby we could run native TPTP behaviours.  TPTP's behavioural model is based on UML and the idea was that given that BPEL is a well defined standard including the concepts of a testability interface, the choreography component would move forward using the BPEL specifications with the eventual goal of producing a UML to BPEL mapping which would allow us to define TPTP behaviours in UML and then run them as BPEL processes.  The issue we are trying to resolve at the moment is whether we should try to have binding information in the model.  The basic problem is if we don't then we will need extra information to actually run the behaviours and if we do it is potentially a lot of work and duplication of an existing solution (WSDL bindings).


Point 3 discussion:

Scott Schneider brought up the possibility of using the choreography component as TPTP's test execution framework earlier on in the week but it may be difficult to discuss this more without someone with a sound grasp of the existing TPTP test execution framework.  

We touched on this last week while talking about the choreography component replacing the TPTP HTTP execution engine.  The main question is do we think BPEL is flexible enough to support each of the test types in TPTP?  As we discussed last week it would appear that we can replace the HTTP execution engine but can we potentially replace the JUnit and Manual Test types too?  Antony: my feeling is that we must surely be able to define an API at some point to run these test types.  Even if the API is very high level and we end up with a lot of the work being done in the binding of the endpoint (e.g. "RunJUnitTest" operation) then still benefit from running everything in the same framework and being able to mix test types.


Other discussion:

Koustubh: Are there likely to be problems in trying to represent XSD as Java in the engine (e.g. XSD choice)?  What do we get out of the mapping?  The purpose of the mapping from XSD to Java in the engine is efficiency.  If the engine were to use XML to represent it's internal types we would suffer large performance hits in things like XPATH expressions.  Given that we intend to use the engine as a load testing engine we must remain as performant as possible.  We do support most of XSD in the engine at the moment but not everything.  We support things like XSD any type though which is a similar problem to XSD choice.  Although XSD cannot map directly to Java types (e.g. complex type = java class) we can create Java classes that represent XSD types accurately.  For example, we support multiple elements (maxOccurs="unbounded") inside a complex type by using arrays in the Java class which represents that complex type.  There are still areas of XSD we don't support properly such as namespaces but the problems do not seem insurmountable.

There will be no choreography meeting next week as many of the attendees will be at EclipseCon.



Actions:
	- Joe will continue to look into the UML to BPEL mapping and the possibility of having binding information in the model
	- Koustubh will continue to try to get us representation on the BPEL TC