[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly-comment] Microsoft's response for Public Review of SCA Assembly Model v1.1 - 15 day review
hi mike, some responses inlined: On Mar 03, 2010, at 8:49 PM, Michael Champion wrote: > I am very sorry to learn that the Assembly TC chose to abandon the > productive discussion that our comment [1] had initiated by taking > no action [2]. I am particularly distressed to see the Microsoft > comment characterized as a request for "loosening" the conformance > requirements, since the request was to do the opposite -- Microsoft > asked the TC to clarify the *technical* criteria implementers could > use to check the conformance of an implementation of SCA Assembly, > and to do so in a language/implementation-independent manner. I don't understand how this doesn't loosen the conformance requirements. Part of the *technical* criteria for an implementation is that it be actually be implemented in some real live concrete language. By definition that means specifying that language binding (a C&i). Currently the SCA specifications are quite clear on the conformance requirements for a C&I. The way I understand the microsoft request, you'd like for there not to be a specification requirement for a C&I, so that any proprietary C&I will do. How does this not loosen a conformance requirement? Before I had requirements for a C&I, so that my artifacts would be portable. After i have none. > > The net effect of rejecting Microsoft's comment is that no one > outside the small community that has drafted the SCA Assembly > specification for the given four languages may claim conformance - > even though the specification is supposedly language neutral. The SCA Assembly is language neutral (actually it defines its own language, so properly it is implementation language neutral.) SCA conformance consists of Assembly plus Policy plus Bindings plus Language Bindings. You need them all to build a composite application. > > > As it stands now, it is not possible to claim that SCA is a language > independent standard that supports open platforms because it > explicitly restricts conformance to those implementation that use an > arbitrary set of languages (C/C++/Java/BPEL). If one programs in > Python, PHP, Ruby, C# or Visual Basic, for example, there is no way > for them to build a conformant implementation. Why would OASIS > create an "open" standard and then restrict "conformant" > implementations to just a few programming languages? > I think you are mischaracterizing the SCA platform. It is language neutral, not language independent. Part of the SCA standard includes programming language bindings. In order to actually build a composite application, you have to implement it in some concrete language. Those language bindings need to be standardized just as much as any other portion of the SCA. For example, what if one vendor does a proprietary language binding for part of the SCDL in one way, and another decides to do a language binding differently for a different subset of the SCA Assembly. What if they don't provide bindings for all Assembly and Policy constructs? This is no different than the Policy spec, e.g. picking a particular policy language. Are you going to argue that the SCA is not "open" because it "restricts" policy declarations to a particular defined language and doesn't allow one to be conformant by using any other of the various extant policy languages? I believe the intent of the SCA community, which is open to all comers including MS, to build and approve C&I's for whatever languages are of interest to the SCA community. If one wants to use, say Python, there is currently no standard SCA Python binding under development. If and when that exists, it will be added to the list of acceptable implementation types for conformance. This is in the interest of ensuring that SCA continues to provide customers the reasonable expectation that they have regarding portability of artifacts. You might have a case if, e.g. you wanted to add python to the list of supported languages, and the OpenCSA Steering Committee refused to allow an Python TC to be chartered in the Member Section. The language binding TCs that were originally chartered were those that were of interest to the opensoa collaboration, to which MS was invited to participate, but chose not to. OASIS is an open standards body. Microsoft has been repeatedly invited to join and participate in the development and of the SCA specifications. If you believe that there are other languages that should be included in the SCA family of language bindings, I would invite you to start a TC to do that work. I just don't see how you can claim something is "standard" without it being approved by a standards body. Open doesn't mean any proprietary thing goes. It means developed on an open, level, playing field, where all the stakeholders may participate. > In discussions of our proposal, the TC expressed a mandate that > implementers pass a test suite before they can claim conformance > [7]. We have a major concern that OASIS should not take a position > regarding conformance of each implementation of an OASIS Standard, > other than to specify the conformance requirements in the Standard. > In the past, OASIS has ratified specs, and implementers implemented > them and claimed conformance as appropriate. The ultimate > conformance judgment has been in the eyes of the users and > customers. Test suites are useful artifacts which can improve the > implementation process, but it is up to the marketplace to hold the > implementers accountable for the quality and conformance of their > implementations. I don't believe that anywhere in the SCA specs does it require one to pass a particular set of test suites. If it does, this is a mistake and should be fixed. Your reference [7] is to an individual's email expressing his personal opinion. How do you jump from one person's email to "TC mandate". The conformance requirements are expressed, quite precisely, I hope, using standard RFC 2116 language in the specifications themselves. There are no other conformance requirements. The TCs have a mandate to produce a test suite which companies are free to make use of as they see fit. The TCs also have as an exit criteria that there be at least 2 implementations that pass the test suites, before the specs can become OASIS Final Deliverables. I don't see how this is related to your complaint. > > I believe that SAP's proposal [3] to modify SCA Assembly conformance > criteria to address the Microsoft [5] and Siemens [6] issues could > meet both the TC's needs and our concerns, > as long as the TC makes the following changes in that proposal: > (remember the SAP's proposal called for removal of the item "3. The > implementation MUST support and comply with at least one of the > OpenCSA Member Section adopted implementation types."): > > 1) The TC creates language-independent test suites [4], and provides > them freely to the public with no licensing requirements. > 2) The TC recommends that the implementers use the freely available > tests to validate their implementation. > 3) The TC can recommend that the implementers provide documentation > to their customers that demonstrate how their derived Implementation > Type has used the SCA Assembly extensibility mechanism. To > facilitate that, the TC could create a template for such > documentation which will again be freely available to the community, > with no licensing requirements. I disagree. > > With all these suites and documents, it is between the marketplace > and the implementers to make the best use of such documentation. > OASIS cannot be in the position of reviewing implementers' test > results and assigning scores or pass/fail evaluations. AFAIK, OASIS does not do that. Certainly the SCA TCs and the OpenCSA MemberSection has not done that. > > Providing detailed and accurate product documentation and tests are > increasingly important aspects of modern software engineering that > OASIS can evangelize, but not legislate. And it is important to note > that it is ultimately up to the customers, and not OASIS, to demand > conformance or pass judgment. Surely, whether or not OASIS should get into the business of trying to enforce conformance claims that are made about its specifications, is a subject for the Board, not a TC which is developing a specification. cheers, jeff > > Sincerely, > Michael Champion > > [1] http://lists.oasis-open.org/archives/sca-assembly-comment/200906/msg00001.html > [2] http://lists.oasis-open.org/archives/sca-assembly/201001/msg00222.html > [3] Sanjay Patil's proposal: http://lists.oasis-open.org/archives/sca-assembly/200910/msg00047.html > [4] http://lists.oasis-open.org/archives/sca-assembly/200910/msg00070.html > [5] JIRA 132 (Microsoft): http://www.osoa.org/jira/browse/ASSEMBLY-132 > [6] JIRA 149 (Siemens): http://www.osoa.org/jira/browse/ASSEMBLY-149 > [7] http://lists.oasis-open.org/archives/sca-assembly/200910/msg00072.html > > > > -- > 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/ > -- Jeff Mischkinsky jeff.mischkinsky@oracle.com Director, Oracle Fusion Middleware +1(650)506-1975 and Web Services Standards 500 Oracle Parkway, M/S 2OP9 Oracle Redwood Shores, CA 94065
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]