Choreography component meeting agenda (24th 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 choreography plugin refactoring and packages before drop into TPTP 4.0 CVS including any issues that should be brought up at the architecture group meeting next week Attending: Joe Toomey Antony Miguel Absent: Koustubh Parwar Harm Sluiman Serge Lucio Jim Saliba Kent Siefkes Point 1 discussion: To clarify the existing 50076 proposal and the concept of an 'external' SUT similar to an 'external' behaviour. The concept of an 'external' SUT (simple file reference rather than a natively modeled SUT) brings about multiple possible combinations of external behaviours and external SUTs. In the case where there is an external behaviour and either an external or native SUT it is assumed that the external behaviour will know how to interpret the SUT (be it external or native). In the case where there is a native behaviour and a native SUT the native behaviour will have been designed to work with the native SUT. In the case where there is a native behaviour and an external SUT, will the native behaviour be able to understand and use or import the external SUT? The user will not want to go to the trouble of modeling their SUT in terms of our SUT model if they already have an existing SUT description such as a WSDL file describing their web service. It is therefore desirable that we in some way support the use of external SUTs with native behaviours, even if it is through the ability to statically import an existing SUT description such as WSDL into a native TPTP SUT description. (Some discussion as to whether we really need to support anything as generic and complex as WSDL when the user can potentially use an external BPEL behaviour to speak to their web services etc. Conclusion was that ideally we don't want the user to *have* to use an external behaviour for anything so out SUT model should be very generic and capable of describing any SUT) In order to make the native SUT in our current model useful it is necessary to expand it to accomodate the concepts found within interface description languages. Joe is reasonably comfortable with the modifications needed to support the import of a WSDL interface description file. The case of WSDL binding files and similar is not clear. There are multiple ways we could support use of external SUTs by a native behaviour: - option 1 = import interfaces and bindings In this case we would import both the interface description and the implementation description (binding) into our model. The con in this case is the difficulty of describing a binding in our model and the significant duplication of existing standards. - option 2 = import interface only In this case we would import only the interface description. The binding information would have to somehow be determined by the engine running the behaviour. This could be accomplished by keeping binding assets such as WSDL binding files as separate assets that the engine had references to. - option 3 = have utility usable by native behaviours that can invoke external SUTs In this case we would retain the ability to use specific interface description languages as SUTs but we would not import them. The native behaviour would invoke some operation on a static entity which was capable of using some external interface description languages to make the actual invocation. E.g. the native behaviour calls the 'TestabilityInterfaceBridge' object passing in references to WSDL files for interface definition and binding information along with the name of the operation to call and any other pertinent information such as parameters. The 'TestabilityInterfaceBridge' object then interprets this request in terms of the referenced WSDL files and calls the actual operation. When we have decided between the above options we may need to decide how usage of the external SUT is presented to the user. Does the user just get to statically import their SUT description file into a native SUT or can they reference an external supported SUT and use it as though it was native in their native behaviour? clear that we need more discussion on this point and we could do with other people's opinions. Point 2 discussion: - no specific questions Other discussion: Actions: Antony should add points from the discussion of point 1 to the design document of enhancement 50076