OASIS Charter Submission Discuss

Proposed Charter for OASIS Service Component Architecture Assembly (SCA-Assembly) TC - 1 of 6

  • 1.  Proposed Charter for OASIS Service Component Architecture Assembly (SCA-Assembly) TC - 1 of 6

    Posted 06-29-2007 15:57
    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-discuss/. 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