Re: [sca-assembly] Issue 132: Proposal

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:  

From:
Anish Karmarkar <>

To:
"Patil, Sanjay" <>

Cc:


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