[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]