[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: OASIS Call for Participation: OASIS Service Component Architecture / Assembly (SCA-Assembly) Technical Committee [1 of 6]
To: OASIS members & interested parties
A new OASIS technical committee is being formed. The OASIS Service Component Architecture / Assembly (SCA-Assembly)
Technical Committee has been proposed by the members of OASIS listed below. The proposal, below, meets the requirements
of the OASIS TC Process [a]. The TC name, statement of purpose, scope, list of deliverables, audience, and language
specified in the proposal will constitute the TC's official charter. Submissions of technology for consideration by the
TC, and the beginning of technical discussions, may occur no sooner than the TC's first meeting.
This TC will operate under our 2005 IPR Policy [b]. The eligibility requirements for becoming a participant in the TC
at the first meeting (see details below) are that:
(a) you must be an employee of an OASIS member organization or an individual member of OASIS;
(b) the OASIS member must sign the OASIS membership agreement [c];
(c) you must notify the TC chair of your intent to participate at least 7 days prior to the first meeting, which
members may do by using the "Join this TC" button on the TC's public page at [d]; and
(d) you must attend the first meeting of the TC, at the time and date fixed below.
Of course, participants also may join the TC at a later time. OASIS and the TC welcomes all interested parties.
Non-OASIS members who wish to participate may contact us about joining OASIS [c]. In addition, the public may access
the information resources maintained for each TC: a mail list archive, document repository and public comments facility,
which will be linked from the TC's public home page at [d].
Please feel free to forward this announcement to any other appropriate lists. OASIS is an open standards
organization; we encourage your feedback.
Regards,
Mary
---------------------------------------------------
Mary P McRae
Manager of TC Administration, OASIS
email: mary.mcrae@oasis-open.org
web: www.oasis-open.org
[a] http://www.oasis-open.org/committees/process.php
[b] http://www.oasis-open.org/who/intellectualproperty.php
[c] See http://www.oasis-open.org/join/
[d] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-assembly
CALL FOR PARTICIPATION
OASIS SERVICE COMPONENT ARCHITECTURE / ASSEMBLY TC
1. Normative Information
a. Name
OASIS Service Component Architecture / Assembly (SCA-Assembly) Technical Committee
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.
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. Consideration should be given to the use of the OASIS Solution
Deployment Descriptor work [3]
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.
18. Support for eventing, pub/sub and queuing systems within the assembly model.
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 5
Time: 11:00 EDT
Duration: 2 hours
Mode: Teleconference
Telephone: Dial-in TBD, 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 TBD location
Telephone: Dial-in TBD, along with e-Meeting facilities
Sponsor: IBM
c. On-going schedule
Weekly 60 Minute teleconferences sponsored by TBD.
Time TBD 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
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
Jeff Mischkinsky, Oracle, jeff.mischkinsky@oracle.com
Graham Barber, IBM, graham_barber@uk.ibm.com
e. Convener:
Jeff Mischkinsky, Oracle, jeff.mischkinsky@oracle.com
f. Name of Member Section to which this TC is Affiliated
This TC is affiliated with the 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
contribution 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
[3] OASIS Solutions Deployment Descriptor TC
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sdd
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]