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
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Tue, 23 Jun 2009 23:08:08 +0100
Jim,
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 |
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]