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


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-charter-discuss message

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

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


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:

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

<oasis-charter-discuss@lists.oasis-open.org>, <opencsa-ms@lists.oasis-open.org>
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

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


>-----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:
>Members who wish to receive emails must join the group by
>selecting "join group" on the group home page:
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.
>Mary P McRae
>Manager of TC Administration, OASIS
>email: mary.mcrae@oasis-open.org  
>web: www.oasis-open.org
>phone: 603.232.9090
>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
>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
>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
>interfaces, oneway operations, plus the message flow patterns
>Rendering of these concepts in terms of WSDL is in-scope, including
>necessary additional annotations of WSDL documents to hold SCA
>8.                 Declaration and setting of property values, including
>simple and complex
>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
>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.
>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
>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:
>*                 From the W3C, material on specification variability,
>test metadata &
>specification clarity:
>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
>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.
>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
>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
>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
>*                 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
>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
>[1] Service Component Architecture Assembly Specification
>Version 1.0
>[2] Service Component Architecture Version 1.0 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

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