[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]