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

[Mike Edwards <mike_edwards@uk.ibm.com>]

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:  mike_edwards@uk.ibm.com

"Martin Chapman" <martin.chapman@oracle.com>

10/07/2007 12:39

To	<oasis-charter-discuss@lists.oasis-open.org>, <opencsa-ms@lists.oasis-open.org>
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:mary.mcrae@oasis-open.org] 
>Sent: Friday, June 29, 2007 4:57 PM
>To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org
>Cc: oasis-charter-discuss@lists.oasis-open.org
>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:oasis-charter-discuss@lists.oasis-open.org. 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: mary.mcrae@oasis-open.org  
>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, mbgl@us.ibm.com
>Mike Edwards, IBM, mike_edwards@uk.ibm.com
>Michael Rowley, BEA, mrowley@bea.com
>Alex Miller, BEA, almiller@bea.com
>Martin Chapman, Oracle, martin.chapman@oracle.com
>Anish Karmarkar, Oracle, anish.karmarkar@oracle.com
>Ashok Malhotra, Oracle, ashok.malhotra@oracle.com
>Sanjay Patil, SAP, sanjay.patil@sap.com
>Henning Blohm, SAP, henning.blohm@sap.com
>Scott Vorthmann, TIBCO, scottv@tibco.com
>David Haney, RogueWave, haney@roguewave.com
>David Booz, IBM, booz@us.ibm.com
>Peter Walker, Sun Microsystems, peter.walker@sun.com
>Glen Daniels, Progress, gdaniels@progress.com
>Kimberly Palko, Progress,  kpalko@progress.com
>
>e. Convener:
>
>Jeff Mischkinsky, Oracle, jeff.mischkinsky@oracle.com
>
>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