Which gets to the heart of the question - can anyone quickly point
at the minutes where we resolved the exit criteria?
Eric.
On 3/25/13 1:59 PM, Bryan Aupperle
wrote:
First, I note that the test suite
for both
the POJO CI spec and the Spring CI spec are published by the
Java TC, so
that is not a concern.
You state the basic point with
the underlying
reasoning quite well. What I simply do not recall is if the
wording of
the exit criteria allows for the use of implementations that
conform by
the rules a - c below.
Bryan Aupperle. PhD
Executive Software Client Architect - Mid-Atlantic
Senior Technical Staff Member
Raleigh, NC
Mobile: 919-656-0018
aupperle@us.ibm.com
From:
Eric Johnson
<eric@tibco.com>
To:
Bryan
Aupperle/Raleigh/IBM@IBMUS,
Cc:
<sca-assembly@lists.oasis-open.org>
Date:
03/25/2013 04:40 PM
Subject:
Re: [sca-assembly]
Fabric3 Fulfillment of Assembly TC Exit Criteria
Hi Bryan,
I didn't get this at first, but then I tried to write up a
response saying
"what's the big deal?" And then I saw what I think might be your
point.
I think your point is that in order to satisfy 12.2 of the
Assembly CD05
spec (lines 4195-4196), which reads "The implementation MUST
support
at least one implementation type standardized by the OpenCSA
Member Section",
the Java implementation in question has to be a standard. And of
course,
they cannot be standards unless there are two implementations.
And since
there aren't two implementations, the Spring implementation type
can't
count towards being one of those implementation types
standardized by the
OpenCSA member section.
Which means we have to resort to the rest of sub-section 3) "or
at
least one implementation type that complies with the following
rules:"
a. The implementation type is defined in compliance with the SCA
Assembly
Extension Model (Section 9 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
exists and
is made available to its prospective user community. Such a
document describes
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). The form and content of such
a document
are described in the specification "Implementation Type
Documentation
Requirements for SCA Assembly Model Version 1.1 Specification"
[SCA-
IMPLTYPDOC]. The contents outlined in this specification
template MUST
be provided in order for an SCA runtime to claim compliance with
the SCA
Assembly Specification on the basis of providing support for
that implementation
type. An example of a document that describes an implementation
type is
the "SCA POJO Component Implementation Specification Version
1.1"
[SCA-Java].
c. An adapted version of the SCA Assembly Test Suite which uses
the implementation
type exists and is made available to its prospective user
community. The
steps required to adapt the SCA Assembly Test Suite for a new
implementation
type are described in the specification "Test Suite Adaptation
for
SCA Assembly Model Version 1.1 Specification" [SCA-TSA]. The
requirements
described in this specification MUST be met in order for an SCA
runtime
to claim compliance with the SCA Assembly Specification on the
basis of
providing support for that implementation type.
(a) & (b) are manifestly true, since this is presumably what
the Java
TC has been up to. Having the Java TC "accept" the
implementation
would certainly make this decision easier for the Assembly TC.
Perhaps
the question for Jim (Fabric 3) & Mike (Tuscany), then is
whether the
test suite is available to the public.
If (c) is true for both Tuscany & Fabric 3, then I don't see
the issue.
What am I missing?
Eric.
On 3/25/13 10:48 AM, Bryan Aupperle wrote:
I have raised some process
questions
on the Java TC mailing list about the potential timing of being
able to
accepting any Spring implementation as conforming at the current
time.
But there is also a question that this TC needs to consider
regarding our
exit criteria.
Provided the Java TC accepts the Fabric conformance submission,
there would
be one conforming implementation of the POJO CI spec (Tuscany)
and one
conforming implantation of the Spring CI spec (Fabric3). Does
this fulfill
the exit criteria for the Assembly spec? A case could certainly
be made,
but I would like to know what others think.
Bryan Aupperle. PhD
Executive Software Client Architect - Mid-Atlantic
Senior Technical Staff Member
Raleigh, NC
Mobile: 919-656-0018
aupperle@us.ibm.com
From: Jim
Marino <jim.marino@gmail.com>
To: sca-assembly@lists.oasis-open.org,
Date: 03/09/2013
01:35 AM
Subject: [sca-assembly]
Fabric3
Fulfillment of Assembly TC Exit Criteria
Sent by: <sca-assembly@lists.oasis-open.org>
All,
This message is intended to provide notice that Fabric3 meets
the conformance
and Exit Criteria requirements as defined by the Assembly
Specification
v.1.1 in Section 12.2 and the Assembly TC Charter respectively.
Specifically:
1. Fabric3 conforms to all mandatory and optional normative
statements
as defined by
a. The Assembly Specification, Section C. Proof of passing the
TC Assembly
Test Suite, including runtime source code, was submitted and
accepted via
resolution as detailed here: http://bit.ly/WMl9M4.
b. The SCA Policy Framework Specification v1.1, including all
normative
statements for direct and external attachment. Proof of passing
the TC
Policy Test Suite, including runtime source code, was submitted
to the
TC mailing list on March 6, 2013.
c. The Spring Component Implementation Specification v1.1. Proof
of passing
the TC Spring Test Suite, including runtime source code, was
submitted
to the TC mailing list on March 9, 2013.
d. The Web Services Binding Specification v1.1. Proof of passing
the TC
WS Binding Test Suite, including runtime source code, was
submitted to
the TC mailing list on March 3, 2013.
Along with Apache Tuscany conformance, I believe this evidence
of Fabric3
conformance fulfills the TC Exit criteria. Namely, that there
shall be
at least two independent runtimes which are compliant with all
normative
portions of the specifications in question and demonstrate
interoperability
and portability as appropriate.
Jim
|