| Mike,
Comments inline.
Jim On Jun 24, 2009, at 12:08 AM, Mike Edwards wrote:
Jim,
This is a good debate. We are getting to the heart of what "conformance" means and how it should be measured for SCA.
Yes this is a good debate as I think it is uncovering some issues that need to be clarified.
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.
Yes. Ideally, in my opinion, it would be beneficial to SCA if a runtime could claim conformance to Assembly without having to also conform to one of the sanctioned languages. 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.
Yes 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]
Yes and I think this can be done with namespaces. I'll describe more below. 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.
Yes. This would be very similar to how GPL and LGPL licenses work (except of course the provision in GPL requiring linked works to also be made available under GPL). I'm not a lawyer, but I think the terms that would most closely resemble this would by GPL + GNU Classpath extension.
I think it is important to note that we probably need to do this regardless of the outcome of the current date as I believe runtime "bridging" code is needed to run the tests. That code would be required for an independent to verify conformance.
Did I get that right?
I think so unless I am misinterpreting you :-).
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.
OK this is fair. I will take a look by next week and provide some concrete suggestions. In broad terms, I was thinking all of the assembly tests would be composed of components that used "implementation.composite". The name of the composites would fall under a specific namespace and be imported by the assembly contributions. The namespace would correspond to a scheme that identified it as being "modifiable". The imported composites may be fine-grained in that they only contain one child component configuration using the specific implementation language and they would promote appropriate services and references. Also, one way to enforce non-mutability would be to ship the OASIS contribution zip archives with an MD5 digest that was checked when the test suite is run (I guess someone could modify the code that checks the digest, but there will probably always be loopholes).
A vendor would then just have to define a set of contributions containing the composites imported by the assembly conformance tests. Since QName imports would be used, these contributions could be structured in anyway the vendor wants, including in a single contribution archive or multiple. Likewise, OASIS could provide archives for the sanctioned languages in this manner.
To take things a little further, this technique could potentially be used to verify multi-language conformance (e.g. BPEL and Java) by defining some of the imported composites using different implementation types.
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?
This is something I think we should look into. In order to make it concrete, perhaps a template document that needs to be filled out and submitted by the vendor to OASIS. One thing though is this should be "lightweight" in terms of not needing to be standardized.
[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.
I agree with this. Using a namespace scheme would make this clear.
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
Mike,
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?
Jim
[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
|