Re: [sca-assembly] Issue 132: Proposal

[Mike Edwards <mike_edwards@uk.ibm.com>]

Folks,

Some comments inline...

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From:	Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:	"Patil, Sanjay" <sanjay.patil@sap.com>
Cc:	sca-assembly@lists.oasis-open.org
Date:	03/11/2009 07:34
Subject:	Re: [sca-assembly] Issue 132: Proposal

---

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.

<mje>
I agree that we would need to make this clear
</mje>

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.

<mje>
The point of public availability of an ImplementationType
document and of a Test Suite
is that it provides for public inspection
of the claim of compatibility.  Without this, how can
anyone evaluate the claim that is being made
to conformance with the SCA Assembly
specification?  If everything can be
kept private, then I forsee that the claim to
conformance will have no meaning.  Indeed
the point of publishing the requirements that
you describe in 1) above also becomes moot
- if no-one can compare the requirements
against the claimed capabilities of the new
implementation type, then why bother
publishing the requirements?
</mje>


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.

<mje>
The real question is whether we can have
a middle point between the current strictly
controlled style of conformance, which discourages
new implementation types, and a
free for all where conformance can be claimed
on the flimsiest of grounds.  In the
free for all case, there is no real purpose
to "conformance".

We can impose simple requirements which don't
imply much in the way of legalese.
We can say that to be conformant that there
must be available a test suite which is
under the Apache 2.0 license, for example.
 We can also require that there is a document
describing the implementation type (with
minimal information requirements) which is
available under an open license.  

Someone can choose not to do these things,
but then they are open to having any 
claim to conformance challenged.
</mje>


-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.
> 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU