RE: [oasis-charter-discuss] Proposed Charter for OASIS Service ComponentArchitecture Assembly (SCA-Assembly) TC

Folks,

Issue accepted.  Proposed change
to the SCA Assembly TC charter as follows:

Change the bullets at the end of the in-scope section
to read as follows:

11. The handling of service interfaces including the nature
of the message exchange patterns and the handling of synchronous, asynchronous
and one-way interactions.

12. Support for Eventing, Publish/Subscribe and Queueing
models 

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.

IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.

Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  

Email:  

"Martin Chapman"
<> 

10/07/2007 12:39

To

<>,
<>

cc

Subject

RE: [oasis-charter-discuss] Proposed
Charter for OASIS Service Component Architecture Assembly (SCA-Assembly)
TC

The proposed SCA Assembly TC charter as currently worded implies a solution
to eventing, and also conflates eventing with sync/async

invocations.

Bullet 11 of the in-scope section says:

  11.                
The handling of service interfaces, including the nature of the 

  message exchange patterns and the handling of synchronous, asynchronous

  and one-way interactions. Techniques including Pub/Sub and Queue

  handling form part of this description.

I think it would be better to remove the "Techniques..." sentence
and to add a new bullet at the end of the in-scope list

  * Support for eventing, pub/sub and queuing systems within the assembly

    model.

Cheers,

   Martin.

>-----Original Message-----

>From: Mary McRae [mailto:] 

>Sent: Friday, June 29, 2007 4:57 PM

>To: ; 

>Cc: 

>Subject: [oasis-charter-discuss] Proposed Charter for OASIS 

>Service Component Architecture Assembly (SCA-Assembly) TC - 1 of 6

>

>

>To OASIS Members:

>

>  A draft TC charter has been submitted to establish the OASIS

>Service Component Architecture Assembly (SCA-Assembly) 

>Technical Committee. In accordance with the OASIS TC Process 

>Policy section 2.2: 

>(http://www.oasis-open.org/committees/process.php#2.2) the 

>proposed charter is hereby submitted for comment. The comment 

>period shall remain open until 11:45 pm ET on 13 July 2007. 

>

>  OASIS maintains a mailing list for the purpose of submitting

>comments on proposed charters. Any OASIS member may post to 

>this list by sending email to: 

>mailto:. All 

>messages will be publicly archived at: 

>http://lists.oasis-open.org/archives/oasis-charter-discuss/. 

>Members who wish to receive emails must join the group by 

>selecting "join group" on the group home page: 

>http://www.oasis-open.org/apps/org/workgroup/oasis-charter-disc

uss/. Employees of organizational members do not >require primary representative
approval to subscribe to the 

>oasis-charter-discuss e-mail.

>

>  A telephone conference will be held among the Convener, the

>OASIS TC Administrator, and those proposers who wish to attend 

>within four days of the close of the comment period. The 

>announcement and call-in information will be noted on the 

>OASIS Charter Discuss Group Calendar.

>

>  We encourage member comment and ask that you note the name 

>of the proposed TC (SCA-Assembly) in the subject line of your 

>email message. 

>

>Regards,

>

>Mary

> 

>---------------------------------------------------

>Mary P McRae

>Manager of TC Administration, OASIS

>email:   

>web: www.oasis-open.org

>phone: 603.232.9090

> 

>

>===========

>PROPOSED CHARTER FOR REVIEW AND COMMENT

>

>OASIS SERVICE COMPONENT ARCHITECTURE 

>ASSEMBLY TC

>

>1. Normative Information

>a. Name

>

>OASIS Service Component Architecture Assembly (SCA-Assembly) Technical

>Committee (TC)

>

>Member Section Affiliation

>

>Open CSA Member Section

>

>b. Statement of Purpose

>

>The purpose of the Service Component Architecture Assembly 

>Technical Committee 

>is to define the core composition model of Service Component 

>Architecture.  Service 

>Component Architecture (SCA) defines a model for the creation 

>of business solutions 

>using a Service-Oriented Architecture, based on the concept of 

>Service Components 

>which offer services and which make references to other 

>services. SCA models 

>business solutions as compositions of groups of service 

>components, wired together in a configuration that satisfies 

>the business goals.  SCA applies aspects such as 

>communication methods and policies for infrastructure 

>capabilities such as security 

>and transactions through metadata attached to the compositions.

>

>This work will be carried out through continued refinement of 

>the Service Component 

>Architecture Assembly Specification Version 1.0 [1] as 

>published by the Open SOA 

>collaboration in March 2007.

>

>

>c. Scope

>

>The TC will accept as input the March 2007 Version 1.0 of the 

>Service Component 

>Architecture (SCA) Assembly Specification as published by the Open
SOA 

>collaboration [1].

>

>The TC will also accept as input for reference the March 2007 

>Version 1.0 of the 

>other SCA Specifications which were published at the same time 

>as the SCA 

>Assembly Specification [2].

>

>Other contributions and changes to the input documents will be 

>accepted for 

>consideration without any prejudice or restrictions and 

>evaluated based on technical 

>merit in so far as they conform to this charter. OASIS members 

>with extensive 

>experience and knowledge in these areas are particularly 

>invited to participate.

>

>The scope of the TC's work is to continue further refinement 

>and finalization of the 

>Input Documents to produce as output specifications that 

>standardize the concepts, 

>XML documents and XML Schema renderings of the areas described below.

>

>1.                
A model for the composition of systems based on a 

>service-oriented 

>architecture, based on the concepts of a) service components  and
b) 

>composites. This model is independent of implementation languages and

>technologies and also independent of communication technologies.

>

>2.                
Describing the characteristics of a service component 

>in terms of its externally 

>visible features including services offered, service 

>references made and 

>configurable properties. Includes the configuration aspects of 

>the services, 

>references and of the implementation used by the component. 

>

>3.                
Describing the externally visible characteristics of a 

>component 

>implementation in terms of its componentType 

>

>4.                
Describing the design aspects of a component in terms 

>of a constrainingType.

>

>5.                
Describing the characteristics of composites including 

>the external aspects of 

>services, references and configurable properties, plus the 

>aspects of internal 

>wiring of the composite, including autowiring. 

>

>6.                
Use of Composite as implementations.  Use of Composites 

>through inclusion. 

>

>7.                
Definition of the nature of interfaces as used by 

>services and references, 

>including local and remote interfaces, bidirectional and 

>conversational 

>interfaces, oneway operations, plus the message flow patterns 

>involved.  

>Rendering of these concepts in terms of WSDL is in-scope, including

>necessary additional annotations of WSDL documents to hold SCA 

>concepts. 

>

>8.                
Declaration and setting of property values, including 

>simple and complex 

>types.

>

>9.                
Rendering of the model in terms of XML documents and 

>their associated 

>XML Schemas.  Defining the model in terms of XML Infoset to 

>permit other 

>parties to render the model in other serialization forms is 

>also regarded as in- scope. 

>

>10.                
Describing the extension points of the model, including 

>implementation types, 

>binding types, interface types.  The relationship of the model

>to these types is 

>part of the scope, but the details of individual types will be 

>dealt with 

>elsewhere, except for the handling of the composite 

>implementation type, the 

>SCA ("default") binding type and the WSDL interface type.
Specific 

>extensions to WSDL are in-scope for the purposes of making a WSDL 

>document contain information relevant to its usage in an SCA context.

>

>11.                
The handling of service interfaces, including the 

>nature of the message 

>exchange patterns and the handling of synchronous, 

>asynchronous and one- way interactions. Techniques including 

>Pub/Sub and Queue handling form 

>part of this description. 

>

>12.                
Description of SCA Bindings in general terms, plus a 

>definition and 

>description of the SCA Binding. 

>

>13.                
The SCA Domain and its characteristics and contents, 

>including Domain-level 

>composite.

>

>14.                
Packaging and deployment of SCA related artifacts, 

>including the relationship 

>to a runtime and characteristics of the runtime are part of 

>the specification.    

>SCA Artifact resolution, plus the use of existing non-SCA 

>mechanisms. SCA 

>Contributions and their metadata.  SCA packaging format.

>

>15.                
The place in the model for the attachment of Intents 

>and Policies are described 

>in general terms.  Specifics of Intents and Policies are 

>handled in another TC. 

>

>16.                
Portability and interoperability of SCA artifacts and 

>SCA components between 

>different SCA runtimes. 

>

>17.                
Diagrammatic representation of SCA composites and components.

>

>

>Upwards Compatibility

>

>There are no formal requirements for upwards compatibility 

>from the input documents 

>to this TC. This is to ensure that the TC has maximum freedom 

>of action in defining 

>the OASIS standard. However it is recognized that there will be early

>implementations in the marketplace based upon these input 

>documents and careful 

>consideration must be applied to any change of 

>feature/function that would cause 

>incompatibilities in the OASIS standard at:

>

>*                
Source Code level

>*                
Compiled Object Code

>*                
XML data definitions

>

>At minimum, known enhancements to the input documents that will cause

>compatibility issues with early implementations in the 

>marketplace will be specified 

>in a chapter in the specification offering migration guidance.

>

>Conformance

>

>In line with the OASIS TC process, the TC will produce 

>normative conformance 

>information describing the normative characteristics of the 

>specification and specific 

>statements about what an implementation must do to conform to 

>the specification, 

>what aspects are optional (if any).

>

>Test Suite

>

>The TC will produce a test suite which can be used to test 

>conformance to the 

>specification which will include:

>

>1.                
Describe a series of valid and invalid test cases which 

>cover as much as is 

>practical of the conformance statements of the specifications 

>produced by this 

>TC, with a description of each of the artifacts involved, 

>constraints on the 

>environment, the test case characteristics and their expected 

>behavior. 

>

>2.                
The provided artifacts should be independent of 

>implementation language and 

>binding type, and show clear mappings which allow the 

>provision of suitable 

>concrete implementations and concrete binding type, with any required

>policies.  The artifacts may include SCA composites expressed
in XML, 

>WSDL interface files, and XSD files, along with other similar 

>files that 

>express the required characteristics of the environment for each test.

>

>3.                
Example implementations and bindings may form part of 

>the test suite, and are 

>only provided as working samples which can be replaced by 

>other specific 

>implementations and bindings.

>

>The Test Suite shall be packaged separately from the 

>specifications produced by the 

>TC and will contain a set of materials including but not 

>limited to SCA composite and 

>related SCA files, WSDL files, XSD files.

>

>The TC shall develop the test suite in collaboration with 

>other TCs within the Open- CSA Member Section.

>

>The following material should be considered as best practice 

>for the preparation of 

>conformance and test suite materials:

>*                
From OASIS: material on specification conformance statements: 

>http://www.oasis- 

>open.org/committees/download.php/305/conformance_requirements-v1.pdf
 

>

>*                
From the W3C, material on specification variability, 

>test metadata & 

>specification clarity: 

>http://www.w3.org/TR/2005/NOTE-spec-variability-20050831/  

>http://www.w3.org/TR/2005/NOTE-test-metadata-20050914/  

>http://www.w3.org/TR/qaframe-spec/

>

>

>Out of Scope

>

>The following is a non-exhaustive list. It is provided only 

>for the sake of clarity. If 

>some function, mechanism or feature is not mentioned here, and 

>it is not mentioned in 

>the Scope of Work section either, then it will be deemed to be 

>out of scope. 

>

>The TC will not define a mapping of the functions and elements 

>described in the 

>specifications to any programming language, to any particular 

>middleware, nor to 

>specific network transports.

>

>The following items are specifically out of scope of the work 

>of the TC:

>

>1.                
Details of specific SCA implementation types other than 

>composites. These 

>are handled through separate TCs.

>

>2.                
Details of specific SCA binding types other than the 

>SCA binding.  These are 

>handled through separate TCs.

>

>3.                
Details of the Policy Framework or specific intents and 

>policies, other than 

>any intents and policies designed for use with composites as 

>implementation 

>types or with the SCA binding type or designed for the general 

>annotation of 

>interfaces with SCA-related features. 

>

>4.                
Aspects of Workflow, such as capability provided by the 

>WS-BPEL language, 

>other than the use of the BPEL language (or other similar 

>languages) as a 

>technology for implementing service components. 

>

>5.                
Areas of capability described by the various Web 

>services specifications.  

>SCA uses the Web services specifications, but is not intended 

>to define or 

>modify Web services functions, other than specific extensions 

>required to 

>capture SCA concepts identified in the in-scope section. 

>

>6.                
Concrete management interfaces or APIs for monitoring 

>and managing 

>domains, contributions, composites, and service components.

>

>

>d. Deliverables

>

>The TC has the following set of deliverables:

>

>1.                
A revised Service Component Architecture Assembly 

>Specification and 

>associated Schema, plus conformance statements. 

>A Committee Specification is scheduled for completion within 

>12 months of 

>the first TC meeting. 

>

>2.                
A complete Test Suite specification for the SCA 

>Assembly Specification, 

>including documents and the related materials described in the 

>scope section. 

>A Committee Specification is scheduled for completion within 

>12 months of 

>the first TC meeting.

>

>Exit Criteria

>

>The TC shall define concrete exit criteria that include at 

>least two independent 

>offerings that implement and are compliant with the all 

>normative portions of 

>specifications and demonstrate interoperability and 

>portability as appropriate. Note 

>that these are minimums and that the TC is free to set more 

>stringent criteria.

>

>Maintenance

>

>Once the TC has completed work on a deliverable and it has 

>become and OASIS 

>standard, the TC will enter "maintenance mode" for the deliverable.

>

>The purpose of maintenance mode is to provide minor revisions 

>to previously adopted 

>deliverables to clarify ambiguities, inconsistencies and 

>obvious errors.  Maintenance 

>mode is not intended to enhance a deliverable or extend its 

>functionality.

>

>The TC will collect issues raised against the deliverables and 

>periodically process 

>those issues.  Issues that request or require new or enhanced

>functionality shall be 

>marked as enhancement requests and set aside.  Issues that 

>result in the clarification or 

>correction of the deliverables shall be processed.  The TC 

>shall maintain a list of these 

>adopted clarifications and shall periodically create a new 

>minor revision of the 

>deliverables including these updates.  Periodically, but at 

>least once a year, the TC 

>shall produce and vote upon a new minor revision of the deliverables.

>

>e. IPR Mode

>

>The TC will operate under the RF on Limited Terms mode under 

>the OASIS IPR 

>Policy.

>

>f. Anticipated audience:

>

>The anticipated audience for this work includes:

>*                
Vendors offering products designed to support 

>applications using a service-

>oriented architecture

>*                
Other specification authors that need the assembly of 

>service components

>*                
Software architects and programmers, who design, write, 

>integrate and deploy 

>applications using a service-oriented architecture

>*                
End users implementing solutions that require an 

>interoperable, composable 

>solution using components that offer services and use services 

>provided by 

>others

>*                
Vendors making products used to integrate applications 

>and services (both 

>hardware and software), such as ESBs.

>

>g. Language

>

>The TC shall conduct its proceedings in English.

>

>

>2. Non-normative information regarding the startup of the TC

>

>a. Related and similar work

>

>The SCA specifications are intended to encompass a range of 

>technologies which are 

>useful in implementing service-oriented solutions.  These 

>include the range of Web- services related specifications such 

>as WSDL and SOAP, the various WS-Security 

>specifications, WS-Addressing, WS-Notification. The list is 

>extensive and there is no 

>limit to the relevance of these specifications to SCA.  SCA 

>does not intend to replace 

>these specifications, but to build upon them.

>

>Other existing technologies such as Java Enterprise Edition 

>and CORBA also have a 

>relationship to SCA and SCA anticipates optionally using these 

>in relevant parts of the 

>specifications (eg to define specific implementation types for 

>artifacts such as JEE 

>EJBs).

>

>

>b. Proposed date, time, and location of first TC meeting

>

>Date: Sept 4

>Time: 11:00 EDT

>Duration: 1 hour

>Mode: Teleconference

>Telephone: Dial-in TBC, along with e-Meeting facilities

>Sponsor: Oracle

>

>

>Date: Sept 18

>Time: 09:00 EDT

>Duration: 3 days (in parallel with F2F meetings of other TCs 

>affiliated with this 

>member section)

>Mode: F2F meeting in East-Coast USA location (location TBC)

>Telephone: Dial-in TBC, along with e-Meeting facilities

>Sponsor: IBM

>

>c. On-going schedule

>

>Weekly 60 Minute teleconferences sponsored by TBC.

>Time TBC by the TC.

>

>It is anticipated that the committee will meet face-to-face 

>once every quarter at a date 

>and venue to be decided by the TC, but with a commitment to 

>hold meetings in 

>different regions of the world so as to share the effort of travel.

>

>d. Supporters:

>

>The following eligible individuals are in support of this proposal:

>

>Michael Beisiegel, IBM, 

>Mike Edwards, IBM, 

>Michael Rowley, BEA, 

>Alex Miller, BEA, 

>Martin Chapman, Oracle, 

>Anish Karmarkar, Oracle, 

>Ashok Malhotra, Oracle, 

>Sanjay Patil, SAP, 

>Henning Blohm, SAP, 

>Scott Vorthmann, TIBCO, 

>David Haney, RogueWave, 

>David Booz, IBM, 

>Peter Walker, Sun Microsystems, 

>Glen Daniels, Progress, 

>Kimberly Palko, Progress,  

>

>e. Convener:

>

>Jeff Mischkinsky, Oracle, 

>

>f. Name of Member Section to which this TC is Affiliated

>

>Open CSA member section.

>

>g. Anticipated contributions

>

>It is expected that the existing SCA Assembly Specification 

>Version 1.00 as published 

>in March 2007 will be a contributions from the Open SOA 

>Collaboration (see [1]), 

>along with references to the other SCA Version 1.00 

>specifications (see [2]), plus any 

>work performed by the Open SOA collaboration between March 

>2007 and the start of 

>the work of the SCA-Assembly TC.

>

>h. Draft FAQ Document

>

>Intentionally left empty.

>

>i. Proposed working title

>

>Service Component Architecture Assembly Specification

>

>

>References

>

>[1] Service Component Architecture Assembly Specification 

>Version 1.0 

>http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf

>

>[2] Service Component Architecture Version 1.0 Specifications 

>http://www.osoa.org/display/Main/Service+Component+Architecture

+Specifications

 

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