Issue 18: outline proposal

1) Propose that the Assembly spec introduces three targets:

i) Introspected Component Type (ICT): not testable on its own, but can be tested for a RUNTIME, if the rules for ICT target are not followed, then the RUNTIME would be non conformant

ii) Component Type side file (CTSF): testable target

ii) Effective Component Type (ECT): not testable on its own, but can be tested for a RUNTIME, if the rules for ECT target are not followed, then the RUNTIME would be non conformant)

The assembly spec would say whether there is an ICT associated with an implementation and the rules for such a ICT would be defined by the C&I associated with the implementation.

The assembly spec would also define rules and specify normative statements for how an ECT is calculated from an ICT and CTSF (http://www.osoa.org/jira/browse/ASSEMBLY-36).

Whether a CTSF is allowed to be used with a particular implementation is specified by the C&I associated with the implementation.

The assembly spec would have normative statements about the fact that the runtime must enable whatever is specified in the ECT.

2) BPEL C&I would specify normative statements and rules for generating the ICT using 2119 keywords.

For example:

If a partnerLink specifies a sca-bpel:service attribute, then a service MUST be generated for the Introspected Component Type. The name of the service MUST be the value of the attribute.

As Mike E mentioned on the call last week, we should take inspiration from the SCA J TC and borrow structure and style form there:

http://lists.oasis-open.org/archives/sca-j/200808/msg00006.html

In particular a rules section on plain ole bple and one on sca extended BPEL.

I hope this brings us a step forward.

Martin.

sca-bpel message