OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sca-assembly] Fabric3 Fulfillment of Assembly TC Exit Criteria


 

21st June 2011

 

https://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/42774/SCA%20Assembly%20minutes%202011-06-21.html

 

 

From: Eric Johnson [mailto:eric@tibco.com]
Sent: 25 March 2013 21:13
To: Bryan Aupperle
Cc: sca-assembly@lists.oasis-open.org
Subject: Re: [sca-assembly] Fabric3 Fulfillment of Assembly TC Exit Criteria

 

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

 

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]