sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Fw: [sca-assembly-comment] 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, 9 Jun 2009 09:45:29 +0100
Folks,
In case any of the Assembly TC members
are not following the Public Review comments list, here is a copy of an
email received
there yesterday. A reply to the
response that the TC made to Microsoft's initial comment.
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
----- Forwarded by Mike
Edwards/UK/IBM on 09/06/2009 09:43 -----
From:
| Michael Champion <Michael.Champion@microsoft.com>
|
To:
| "sca-assembly-comment@lists.oasis-open.org"
<sca-assembly-comment@lists.oasis-open.org>
|
Date:
| 08/06/2009 15:32
|
Subject:
| [sca-assembly-comment] Rebuttal: Against
the use of portability and functions as reasons for requiring one of the
existing 4 languages |
Thank you for considering Microsoft's suggestion for
improving the SCA Assembly spec's conformance criteria (http://lists.oasis-open.org/archives/sca-assembly-comment/200905/msg00001.html).
We suggested that conformance to the Assembly Specification not be tied
to conformance to one of the Open CSA programming language specifications.
Making this change would promote openness of the standards. We believe
the Assembly Specification should have broad applicability to a variety
of technology platforms and that making it as inclusive as possible will
benefit end-users. The developer community would also derive greater
benefit from SCA if it were a more open standard.
The SCA Assembly TC responded by saying "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." In other works, the TC believes that unless
a runtime implements one of the four listed languages in section 13.2 of
the Assembly spec, it is not possible to determine if the runtime supports
SCA functions.
We respectfully disagree with the TC's claim that runtime functional conformance
can only be achieved by verifying conformance to one of the committee-designated
languages.
If the SCA committee wishes to enforce that runtimes support certain functions,
the specification can do so in a way that is independent of all runtime
implementation details while detecting the support of those functions. WS-Security
Core [1] specification is a good example of how to do this: WS-Security
asserts functional conformance by defining the model that implementations
must conform to and conformance requirements are written in terms of that
functional model.
Likewise, if the committee wishes to advance the OASIS goals of having
technologies able to be supported on the widest range of implementations,
then again, rather than listing four implementation languages, the specification
should state its functional model and also state that runtimes must implement
that functional model, as verified by conformance tests.
In fact, based on a straightforward reading, language-independence of conformance
tests is required by the SCA Assembly charter (http://www.oasis-open.org/committees/sca-assembly/charter.php).
See the following excepts from the "Test Suite" section:
"The TC will produce a test suite which can be used to test conformance
to the specification which will include:
. Describe a series of valid and invalid test cases which cover as much
as is practical of the conformance statements of the specifications produced
by this TC, with a description of each of the artifacts involved, constraints
on the environment, the test case characteristics and their expected behavior.
. The provided artifacts should be independent of implementation language
and binding type, and show clear mappings which allow the provision of
suitable concrete implementations and concrete binding type, with any required
policies. The artifacts may include SCA composites expressed in XML, WSDL
interface files, and XSD files, along with other similar files that express
the required characteristics of the environment for each test.
. Example implementations and bindings may form part of the test suite,
and are only provided as working samples which can be replaced by other
specific implementations and bindings."
Contrary to these charter requirements, the TC's rejection of the language-independence
suggestion we made directly limits conformance testing to implementations
that support one of the four languages picked by the TC.
Furthermore, upon reviewing the conformance statements from the assembly
specification, it appears that overwhelming majority of them are actually
independent of language and implementation type.
Our understanding was yet further confirmed when reviewing the conformance
testcases enumerated in the document "TestCases for the SCA Assembly
Version 1.1 spec, WD 21": http://www.oasis-open.org/apps/org/workgroup/sca-assembly-testing/download.php/32455/SCA_Assembly_TestCases_21.pdf. Again,
the overwhelming majority of the enumerated testcases are language/implementation
type-independent.
Therefore it appears that the Assembly TC has indeed been able to design
testcases that ensure SCA Assembly functions are supported, independent
of the language or the implementation type used. This confirms our belief
that it is indeed possible to ensure that the behavior of an implementation
is consistent with the requirements of SCA without requiring it to implement
one of the four, chosen languages (Java, BPEL, C/C++). And this change
will actually improve the Assembly spec's conformance to its own charter.
[1] http://www.oasis-open.org/specs/#wssv1.1 See the extension
point to permit the usage of security tokens. The WSS TC defined
5 different XML and binary tokens that use this extension point, but its
conformance testing is functional conformance, not conformance to one of
the 5 TC-defined tokens.
--
This publicly archived list offers a means to provide input to the
OASIS Service Component Architecture / Assembly (SCA-Assembly) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: sca-assembly-comment-subscribe@lists.oasis-open.org
Unsubscribe: sca-assembly-comment-unsubscribe@lists.oasis-open.org
List help: sca-assembly-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/sca-assembly-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-assembly
Join OASIS: http://www.oasis-open.org/join/
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]