Re: [sca-assembly] Issue 132: Proposal

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Overall, the direction of the proposal looks promising. But I do have 
two comments:

1) We do need to say which parts of the assembly spec are 
optional/mandatory for the implementation type extension.
For example, assembly defines the wiredByImpl feature. Obvious 
implementation types don't have to implement this (Java POJO/Spring C&I 
do not offer this feature). What other features are optional? 
References/properties, cardinality of references? Does it have to allow 
all kinds of schema types/elements for properties? Is everything 
optional? If we are going to loosen the criteria for conformance, we 
should say which parts are optional. If we don't, it could be assumed 
that an implementation type can choose what it wants to support.

I assume all the features that do not depend on a particular 
implementation type are mandatory for the runtime. Eg: recursion, 
promotion, interface.wsdl.

2) I'm not sure why we need to talk about 'publicly available' or a 
specific license (like Apache or GPL/LGPL). If the aim is to enable all 
kinds of implementation types that want to use assembly/policy then we 
should not have such a requirement. If someone wants to implement an SCA 
implementation type for C#, plsql, abap, JCL, for which there will 
likely be only one implementation and sell a product based on that, 
what's the point of making it "publicly available" and/or "freely 
available" under ASL/GPL/whatever. The actual runtime would be sold in 
some product form and nobody else can implement it (no patent grants to 
the underlying language). The test suite may be bundled with the product 
CD and there may not be a spec for the implementation type other than 
the tools/runtime documentation.
Why would we want to go through, what seems to be a nasty legalese maze, 
to figure this out when it doesn't seem to (at least to me) serve any 
purpose.
I think the question is, do we want the assembly spec to be widely 
implemented by various runtimes that support all kinds of language? If 
we go down this path, I think, for customers just plain SCA assembly 
conformance isn't going to be about portability (of artifacts). It would 
be about the model (and perhaps some skills portability). If customers 
are interested in portability of artifacts, they would not just insist 
on SCA assembly conformance but conformance to a specific impl type like 
POJO/Spring/BPEL.
Alternately, if we are really interested in preventing any dilution of 
the conformance claim to SCA assembly (and provide some portability 
guarantees) we should keep the conformance section as is.

-Anish
--


On 10/20/2009 4:50 PM, Patil, Sanjay wrote:
> 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.
>