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



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]