[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] Issue 132: Proposal
The proposal sounds very good to me. Actually it would resolve also Siemens comment (JIRA #149) Thanks, Philipp From: Patil, Sanjay
[mailto:sanjay.patil@sap.com] With the current conformance criteria for SCA Runtime
(section 13.2 of the SCA Assembly specification), it is not possible for vendors to claim conformance with SCA by using runtimes that support only
proprietary SCA implementation types (and do not support any
of the OpenCSA defined
standard implementation
types). I think it is
in the interest of the
OpenCSA member companies to promote a broader adoption
of the SCA standard and not
introduce any hurdles that are not absolutely necessary. As it was apparent
(at least to me) from the discussion
on today’s (10/20) SCA Assembly TC’s conference
call, we are ourselves
not fully convinced that the
current conformance criteria is
necessary. It seems
that we are ready to
maintain the status quo of the current conformance criteria primarily because the alternative of defining a well thought out and commonly agreed upon
solution along with all the right legalese is going to be challenging and time
consuming. While I
agree with this concern, I don’t think maintaining the status quo provides us the right path forward. If we must come up with a
quick solution, I would
propose that we take the route of relaxing the conformance
requirements and make the SCA standard more accessible (from a conformance
perspective) now -- in
its very first release.
As part of a future release,
we can then think
about how to set up a level playing field by imposing the same IP terms for
both the OpenCSA defined implementation types and the vendor defined
implementation types. Please see below for
my proposal for resolving
the Issue 132. The language of the proposal many need some tweaking but I hope
that it has sufficient clarity
to be considered as a formal proposal. Thanks, Sanjay Proposal: Resolve the Issue 132 by
replacing the current text of Section 13.2 (SCA Runtime) with the following (which
essentially removes the item 4 and updates the item 3 of the current text)
: 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 of the
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. 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). 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]