OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [sca-assembly] Issue 132: Proposal


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.

I agree that we would need to make this clear

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.

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?

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

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.


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:

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]