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] Rebuttal: Against the use of portability andfunctions as reasons for requiring one of the existing 4 languages


This is a good debate.  We are getting to the heart of what "conformance" means and how it should be measured for SCA.

From your note below, I think I read the following (and please correct me if I've got it wrong, since I'm trying to put your ideas into a series of points):

1) The primary aspect of the claim of conformance to the SCA Assembly specification should be the ability of an SCA runtime to pass the SCA Assembly Conformance Test suite.

2) The SCA Assembly Conformance Test Suite should be structured in such a way that it can be rendered using any specific implementation type, not limited to the
set of implementation types covered by OASIS SCA specifications.

3) Vendors wanting to render the SCA Assembly Conformance Test Suite using a new specific implementation type should be given specific instructions in the base version of the test suite
as to which pieces of the test suite they are permitted to modify to adapt it to that implementation type and which pieces must be left unchanged. [1]

4) Once a vendor has created a version of the SCA Assembly Conformance Test Suite for a specific implementation type, they must make that version of the test suite freely
available on the same terms that are used for the base version of the test suite made available from OASIS.

Did I get that right?

Regarding the adapting of the Test Suite to any new implementation type, I'd like to ask you to take a look at the suite that we've got and judge where it falls short of
the goal that you see for the test suite. I will admit that at present, we don't have a set of rules for what can/should be changed and what must be left alone.  However,
the test suite already provides much of the separation between test suite and "low level" implementation artifacts that I think you desire.  If something more needs
doing, let us know what it is.

I have one other itch which I need to scratch.  That concerns some form of description of how the content of some implementation type artifact is interpreted by SCA
- perhaps it need not be called "specification" and perhaps it need not be anything standardized at OASIS.  However, it would seem odd to me for there to be a
runtime claiming conformance to SCA, for some "new" implementation type, without there being some form of description of how the features of that type of
implementation artifact are interpreted in terms of SCA.  This could be viewed as simply a statement of how the componentType of the implementation artifact
is determined and how a developer can influence that componentType.  We can take our inspiration for this from the SCA BPEL spec - which is pretty short and
to the point and can be described very straightforwardly as the mapping of BPEL to SCA.

Should conformance to SCA Assembly using some "new" implementation type make a requirement for the open publication of a document of this kind?
I would feel much happier if there were such a requirement - at the very least, it will enable an evaluation of the adapted test suite as to whether the adaptation is
a true one.

What is your view on this thinking regarding a description / specification (call it what you will) for a "new" implementation type?

[1] NOTE: I believe that one aspect of the passing of the conformance test suite is that no vendor (using ANY implementation language) can demand that
SCA Assembly artifacts MUST contain (proprietary) extension elements - only <implementation.xxx/> elements for the specific implementation type in question.

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: Jim Marino <jim.marino@gmail.com>
To: OASIS Assembly <sca-assembly@lists.oasis-open.org>, sca-assembly-comment@lists.oasis-open.org
Date: 23/06/2009 18:06
Subject: Re: [sca-assembly] [ISSUE 132] Rebuttal: Against the use of portability and functions as reasons for requiring one of the existing 4 languages


You did not addressed the points I was hoping you would. In fairness, I probably did not explain them clearly. Here's another try.

As background, I think we all agree on the value of strong, verifiable conformance and clear tests that can perform that task. No one is arguing that point. And no one is claiming vendors should be allowed to "invent" or otherwise modify portions of the conformance test suite with abandon :-). I'm sure we can safely assume everyone understands the virtues of conformance test suites and avoid rehashing them here.

Given that, my point is that a vendor should be able to claim conformance to the SCA Assembly specification without being required to be conformant with one of the official languages. One of the reasons given for not accepting Microsoft's request to change this requirement was, "If there were no requirement to support one of the implementation types covered by the Open CSA Member Section, this would mean that end users could have no assurance that the SCA runtime concerned really provides the functions laid down by the SCA specifications"[1]. In a nutshell, I don't think the statement is accurate and I believe conformance tests that do not rely on a specific implementation type (other than composites) can be developed for Assembly. The purpose of my email was to outline how that could be accomplished.

I would not characterize this approach as more "open" since it still hold vendors (or open source projects) accountable in very defined and verifiable ways. It is perhaps more "modular" and arguably will promote portability, which is lacking with SCA.

What would I like to see? Basically, I would like a runtime to be able to claim conformance to the SCA Assembly Specification without having any requirements by way of a programming language. In other words, it should be possible for a runtime to pass the Assembly conformance suite without having to support any of the sanctioned programming language specifications. One proviso which could be attached to claim conformance is that a vendor (or open source project) would be required to make any artifacts required to run the tests (excluding the runtime) available under the same license terms as the OASIS tests. Given the current test suite requires vendor-specific code, this probably should be a requirement regardless of the present proposal.

I believe this approach would address the concerns raised by a number of parties during the public review. What issues do you see with this approach or is it acceptable in your view?


[1] http://lists.oasis-open.org/archives/sca-assembly-comment/200905/msg00001.html.  

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]