sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] Issue 132: Sanjay's Proposal - Discussion
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: sca-assembly@lists.oasis-open.org
- Date: Wed, 28 Oct 2009 14:24:32 +0000
Folks,
We had an interesting but short discussion
of this proposal on our TC call yesterday. I'd like to follow up
on that discussion.
I think that the main points that have
been made about this proposal concern the term "publicly available"
that is used in relation to
both the Description Document for the
new implementation type and in relation to the Modified Assembly Test Suite
that uses the
new implementation type for all of its
low-level implementation artifacts.
There was also a point made about any
limitations with respect to functionality that a new implementation type
might have and
how these might be handled.
1) "Public Availability" of
the Description Document and the Test Suite
This has been at the heart of my concerns
relating to relaxing the current requirements.
With everything published as OASIS,
we are assured of the kind of public availability that we desire. Once
we move away from
that, things get harder to pin down.
Remember that the reason for making
these stipulations is to allow for the "court of public opinion"
to be used as a
method of policing any claim made for
conformance. Only by having the materials on which the claim is based
openly
available to anyone will it really be
possible for this mechanism to work.
"Public Availability" of the
Description Document. This I think is tough to organise. My
thought is that we want the capability for
anyone to obtain a copy of the Description
Document without being tangled up in needing to agree any restrictive license
terms.
We could stipulate that the Description
Document:
- must be available on a public website
- must be available for anyone to read
without charge
- must be available on license terms
which are equivalent to the OASIS license for the SCA Assembly specification,
or which are more permissive
However, I recognise that this is not
so easy to specify in a way which can guarantee the kind of open access
that we might
desire.
Regarding the Test Suite code, we could
attach a form of open source license to the current Assembly test suite
artifacts which
requires publication of any modified
test suite under the same license (eg GPL or LGPL). This might seem
heavy handed but
it would give certainty about the availability
of the code of a modified test suite. The alternative would be to
choose a less
onerous license (eg Apache 2.0) but
then require that the modified test suite is made available under that
same license in order
for the implementation type to qualify
as "conforming" to SCA Assembly.
I note that in either case, we must
be clear that there is absolutely no requirement for the SCA runtime relating
to the implementation
type to be made available - the terms
applying to the runtime itself can be whatever (commercial) terms the company
concerned
might choose.
2) Handling of Limitations of Functionality
of a new Implementation Type
This is a tough question, since we have
not really faced an implementation type which has restrictions.
The problem I forsee is that if (say)
we had an implementation type that could not provide SCA properties, then
there is a set
of the Assembly testcases that such
an implementation type would inevitably fail. The failures imply
that the runtime using that
implementation type as its (only) implementation
type would not be able to claim conformance to SCA Assembly.
I am not sure that we are ready to deal
with this at the moment. I think that we shall have to wait until
we are presented with an
implementation type with restrictions.
At that point, we can properly assess the restrictions and I think
that the best idea would
be to create a "profile" -
define a set of function that applies to that style of implementation and
a subset of the Assembly test
suite that it would have to pass. This
is for some future version of the test suite. I think we should ignore
it for the present and
require that all the test suite is passed.
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
From:
| "Patil, Sanjay" <sanjay.patil@sap.com>
|
To:
| <sca-assembly@lists.oasis-open.org>
|
Date:
| 21/10/2009 00:56
|
Subject:
| [sca-assembly] Issue 132: Proposal |
With the current conformance
criteria for SCA Runtime (section 13.2 of the SCA Assembly specification),
it is not possible
for vendors to claim
conformance with
SCA by using runtimes
that support
only proprietary
SCA implementation
types (and do
not support any
of the OpenCSA defined
standard implementation types).
I think it is in the interest of
the OpenCSA
member companies
to promote a
broader adoption
of the SCA standard and not introduce
any hurdles that are not absolutely necessary. As it was apparent
(at least to me)
from the
discussion on today’s
(10/20) SCA Assembly TC’s conference
call, we are ourselves
not fully convinced that the
current conformance criteria is
necessary. It seems
that we are ready
to maintain the status quo of the current conformance criteria
primarily because
the alternative of
defining a well thought
out and commonly agreed upon solution
along with all the right legalese is going to be challenging and time consuming.
While I agree with
this concern, I don’t think maintaining the status quo
provides us the right
path forward.
If we must come up with a quick
solution, I would
propose that we
take the route of
relaxing the conformance requirements
and make the SCA standard more accessible (from a conformance perspective)
now -- in its
very first release. As
part of a future release, we can then
think about how
to set up
a level playing field by imposing the
same IP terms for both the OpenCSA defined implementation types and the
vendor defined implementation types.
Please see below for
my proposal for resolving
the Issue
132. The language of
the proposal many
need some tweaking but I hope that
it has sufficient clarity to be considered as a formal proposal.
Thanks,
Sanjay
Proposal:
Resolve the Issue 132 by replacing the current
text of Section 13.2 (SCA Runtime) with the following (which essentially
removes the item 4 and updates the item 3 of the current text)
:
An implementation that claims to conform
to the requirements of an SCA Runtime defined in this specification MUST
meet the following conditions:
1. The
implementation MUST comply with all statements in Appendix C: Conformance
Items related to an SCA Runtime, notably all MUST statements have to be
implemented.
2. The
implementation MUST conform to the SCA Policy Framework v1.1 Specification
[Policy].
3. The
implementation MUST support at least one implementation type standardized
by the OpenCSA Member Section or comply with the following rules for at
least one of the other implementation types:
a. The
implementation type is defined in compliance with the SCA Assembly Extension
Model (Section 10 of the SCA Assembly Specification).
b. A
document describing the mapping of the constructs defined in the SCA Assembly
specification with those of the implementation type is made publicly available.
Such a document should help in understanding how SCA components can be
developed using the implementation type, how these components can be configured
and assembled together
(as instances of Components in SCA compositions).
To get an idea about the purpose and
scope of such a document that
describes the implementation type, see
the Client and Implementation specifications for the implementation types
standardized by the OpenCSA Member section.
c. An
adapted version of the SCA Assembly Test Suite for testing the implementation
type is created and is made publicly available.
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]