Definitely a step into the right
direction and follows fully the SCA vision IMHO, e a *technology independent*
component and composite model!
+1
Regards,
Philipp
From: Estefan, Jeff A
(3100) [mailto:]
Sent: Saturday, April 24, 2010 2:34 AM
To:
Subject: [sca-assembly] REOPEN ISSUES 132 and 149: Update to Sanjay's
Proposal
Raiser: Jeff A. Estefan / Mike Edwards
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.
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" 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" 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.
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.
