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.  

On Jun 23, 2009, at 4:03 PM, Mike Edwards wrote:

Jim, 
 
Thanks for your comments. 
 
First, I would like to point out that we have built the Assembly testcase suite along the lines that you 
want to see.  It is built in a way that is language independent with all top level materials being 
wholly composite based, and then with replaceable language-specific implementations at the 
bottom. 
 
Availability of the testcase suite in each of the OASIS supported language types is not a "convenience" 
- it is a requirement.  We already have Java, and C, C++ and BPEL are well advanced.  Others will be 
added as their specifications come forward to public review. 
 
The second point about the testcase suite is that it is not just a matter for the SCA runtime implementers. 
The idea is that the conformance testcase suite is available to all - anyone can take it and use it to  
verify that some SCA runtime conforms to the specifications.  It is the open nature of the test suite that 
is the biggest guarantee that SCA runtime vendors will take it seriously - no one can bend their way 
around it without facing the possibility that users will catch them out. 
 
 
The second question to address is what you really think it means to "conform" to the SCA specifications. 
 
One important thing is that SCA is extensible and can accommodate the use of pretty well any implementation 
technology and implementation language.  Any vendor can do this at any time.  So SCA is very much open, 
as you desire. 
 
However, claiming conformance is something else.  What does "claiming conformance" really mean? 
To me, it means that the SCA runtime meets the requirements of the relevant SCA specifications.   
I am sure there is real value to end users in a claim of conformance - the end users can have  expectations 
of a conforming system that it will work in a certain way - and that the end users knowledge of SCA will apply 
to the conforming system.  It is clear that vendors also attach importance to claiming conformance too. 
 
If conformance is to have any real meaning, I believe that this must mean adhering to the letter of the spec. 
Our current approach to this is to require the passing of the test suite - as a minimum check.  There will always 
be things that the test suite does not check - and for those, the wording of the conformance points in the spec 
is the tool that people can use. 
 
So, let us say that we want a more "open" approach to claiming conformance for a runtime that supports  
one or more implementation languages not specified by any of the OASIS TCs.  How might we do this while 
still retaining some meaning to the term "conformance"?  Some thoughts: 
 
- Might we allow a claim of conformance for language "X" as long as there is a Test Suite for Assembly that 
uses implementation language "X"? 
 
- Might we allow a claim for conformance for language "X" as long as there is a specification for SCA component 
implementations written in lnaguage "X"?  Without such a specification and in particular without a definition of 
how the componentType is calculated for an implementation artifact written in language "X", how would it be 
possible to know that the test suite was a valid test suite? 
 
- Should it be required that the test suite and the specification for language "X" is available publicly with some 
form of open terms?  I note that the current OASIS TC specs and test suite are available to anyone on open 
terms - so that anyone can take them and run them. 
 
 
What are your thoughts on this? 

 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:   
 
 
  
 From: Jim Marino <> 

 To:  

 Cc: OASIS Assembly <> 

 Date: 10/06/2009 02:07 

 Subject: [sca-assembly] Rebuttal: Against the use of portability and functions as reasonsfor requiring one of the existing 4 languages
 
  
 
 
Hi,
 
 I haven't had much time lately to participate in TC discussions on  
 language conformance due to other commitments. However, I did have the  
 opportunity to discuss the technical merits of this issue at length  
 with people from Microsoft. I think I understand where they are coming  
 from and believe there may be a way to accommodate Microsoft's  
 concerns while also improving the SCA specifications.
 
 Coupling conformance to the Assembly specification with one of the  
 "official" TC languages places an unneeded and expensive burden on  
 potential implementors that may not support one of those languages.  
 This is particularly evident given the OASIS requirement for two  
 independent conformant implementations. The original spirit of  
 assembly was language independence and that can be maintained. It  
 seems the main sticking point is with conformance testing: namely, how  
 can language independent tests be created that verify assembly  
 assertions?
 
 As a proposal, I believe it is feasible to use composite  
 implementations to create language independent verification tests. The  
 tests would make extensive use of the implementation.composite type as  
 well as service and reference promotions. The actual implementations  
 would be contained in a separate contribution (or contributions) and  
 made available to the using composite via the contribution import/ 
 export mechanism. The verification tests would be run against the  
 components using the composites and their promoted services, which  
 would result in language independent conformance checks.
 
 As a convenience, composites which used "official" language types such  
 as implementation.java or implementation.bpel could be made available.  
 However, it would also be possible for a vendor to supply their own  
 composites that used a proprietary language.
 
 Making assembly truly language independent would have two significant  
 benefits, specifically portability and expanding SCA's relevance.  
 Realistically, the best chance of achieving portability for SCA is at  
 the assembly level. The further one goes "down" - e.g. into policy,  
 component implementations, and actual application code - portability  
 becomes problematic. For example, policy is not likely to be portable  
 given the ability to use different policy languages. The Java  
 specification also does not address many of the areas required to  
 write portable applications such as database access and using managed  
 threads. If Java EE is any indicator, achieving portability of  
 application code is likely to require years of effort, and even then  
 the results are likely to be incomplete. However, in my opinion,  
 portability at the assembly level is a realistic goal and should be  
 pursued by making it as language independent as possible.
 
 Language independence would also expand the relevance of assembly to  
 areas Java EE could never touch. Assembly can be used across a host of  
 proprietary programming languages, essentially providing a portable  
 blueprint of systems, regardless of the technologies they run on. In  
 my opinion, this may prove to be the most important contribution SCA  
 has to make.
 
 Jim
 
 
 ---------------------------------------------------------------------
 To unsubscribe from this mail list, you must leave the OASIS TC that
 generates this mail.  Follow this link to all your TCs in OASIS at:
 https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
 
  
 

  

  
 
 
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