PROPOSED RESOLUTION: Issues 132 and 149 - Update to Sanjay'sProposal

Colleagues,

The 60-day public review period for the Test Suite Adaptation and Implementation Type Documentation Requirements for SCA Assembly Model v1.1 described at [1] has completed. We received one comment from Michael Champion of Microsoft described at [2] prior to the close of the public review period and it was a favorable comment without request for change to these specifications. We also received a positive comment on initiating these specifications in support of obtaining broader adoption of the SCA-Assembly model from Philipp Konradi of Siemens which can be found at [3] with the originating note from Martin Chapman at [4].

It is my strong believe that completion of this review cycle affords us an opportunity to propose a relatively small update to the SCA-Assembly Model v1.1 specification prior to moving forward to full OASIS standardization, recognizing this would likely require another 15-day review of an updated committee specification. This proposal has been submitted in the past by suggesting to reopen Issues 132 and 149 together with some recommended update language to the conformance Section 12.2 SCA Runtime (see proposal below). In addition, we would need to add references to the two new specifications in Section 1.2 Normative References. Therefore, I would like to propose this as a topic for discussion at our next SCA-Assembly telecon.

Regards…

- Jeff E., NASA/JPL

[1] http://lists.oasis-open.org/archives/sca-assembly/201008/msg00089.html

[2] http://lists.oasis-open.org/archives/sca-assembly-comment/201010/msg00000.html

[3] http://lists.oasis-open.org/archives/sca-assembly-comment/201008/msg00001.html

[4] http://lists.oasis-open.org/archives/sca-assembly-comment/201008/msg00000.html

Raiser: Jeff A. Estefan

Target: SCA Assembly Model Specification Version 1.1

Description: Update to Sanjay’s Proposal in Response to Issues 132 and 149

Proposal: The following is a recommended update to Sanjay’s original proposal to address Issues 132 (http://www.osoa.org/jira/browse/ASSEMBLY-132) and 149 (http://www.osoa.org/jira/browse/ASSEMBLY-149) by replacing the current text of Section 13.2 (SCA Runtime) in the SCA Assembly Model Spec with the language provided below. The original text of Sanjay’s proposal is included as well as the inline updates showing recommended updates. Note that this proposal also comes with the accompanying documentation attached. Justification for reopening these issues is articulated in the Justification section that follows the proposal.

Justification: The SCA assembly model should be made agnostic to specific implementation technology to the maximum extent possible so that it may be used as THE industry standard model for component and composite assembly. Not all implementation technologies are “open,” “standards-based,” and/or “non-proprietary.” It’s simply not realistic. If the TC has a moral objection to such solutions, then that is a personal bias and it should be clearly stated at the beginning of each SCA-* specification.

Revised Sanjay Proposal:

An implementation that claims to conform to the requirements of an SCA Runtime defined in this specification MUST meet the following conditions:

1. The implementation MUST comply with all statements in Appendix C: Conformance Items related to an SCA Runtime, notably all MUST statements have to be implemented.

2. The implementation MUST conform to the SCA Policy Framework v1.1 Specification [Policy].

3. The implementation MUST support at least one implementation type standardized by the OpenCSA Member Section or comply with the following rules for at least one ~~of the~~ other implementation types:

a. The implementation type is defined in compliance with the SCA Assembly Extension Model (Section 10 9 of ~~the~~ this SCA Assembly Specification).

b. A document describing the mapping of the constructs defined in the SCA Assembly specification with those of the implementation type is made ~~publicly~~ available to its prospective development community. Such a document should help in understanding how SCA components can be developed using the implementation type, how these components can be configured and assembled together (as instances of Components in SCA compositions). A template for such a document entitled "Implementation Type Documentation Requirements for SCA Assembly Model Version 1.1 Specification" [SCA-IMPLTYPDOC] has been provided by this Technical Committee. The contents outlined in this document template MUST be completed in order for an implementation type to claim compliance with the SCA Assembly Specification. ~~To get an idea about the purpose and scope of such a document~~ ~~that~~ ~~describes the implementation type, see the Client and Implementation specifications for the implementation types standardized by the OpenCSA Member section~~.

c. An adapted version of the SCA Assembly Test Suite for testing the implementation type is created and is made ~~publicly~~ available to its prospective development community. A template for such a document entitled "Test Suite Adaptation for SCA Assembly Model Version 1.1 Specification" [SCA-TSA] has been provided by this Technical Committee. The contents outlined in this document template MUST be completed in order for an implementation type to claim compliance with the SCA Assembly Specification.

4. The implementation MUST support one or more binding types. If only one binding type is supported, it MUST be the default SCA binding type, binding.sca.

sca-assembly message