To OASIS Members:
A draft TC charter has been submitted to establish the OASIS Service Component Architecture Policy (SCA-Policy)
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-Policy) 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 POLICY
FRAMEWORK TC
a. Name
OASIS Service Component Architecture Policy (SCA-Policy) Technical Committee (TC)
Member Section Affiliation
Open CSA Member Section
b. Statement of Purpose
The purpose of the Service Component Architecture Policy (SCA-Policy) Technical
Committee is to define a Policy Framework and policies Reliable Messaging, Security
and Transactions for the 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 allows abstract requirements and concrete policies for
infrastructure capabilities such as security and transactions to be specified through
metadata attached to the compositions.
This work will be carried out through continued refinement of the Service Component
Architecture Policy Specification Version 1.0 [2] 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) Policy Framework Specification as published by the Open SOA
collaboration [2].
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 Policy
Specification [1,3].
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.
Specific aims of the SCA Policy TC shall be as follows:
1. The TC shall address both interaction policies that apply to messages passed
between SCA components as well as implementation policies that influence the
behavior of SCA components and composites.
2. The TC shall develop mechanisms to define new abstract QoS requirements
(intents) and associate them with SCA constructs. (See SCA Assembly Model
[1].) Users must be able to customize such abstract requirements i.e. select the
exact policies they want to fulfill a particular requirement. The definition of
specific intents is in-scope.
3. The TC shall develop mechanisms to associate concrete policies with SCA
constructs. Policies may be expressed and attached using WS-Policy or other
policy mechanisms.
4. The TC shall specify how abstract requirements are mapped into concrete
policies. A single requirement may map to multiple policies, for example the
WS-I profiles, BP, BSP, RSP. Multiple abstract requirements may map to a
single policy. The capability for a set of one or more concrete policies to declare
which abstract requirements that the set satisfies shall be specified.
5. For interaction policies, defining how policies on services and references may be
matched on an SCA wire through static analysis, is in scope.
6. The TC shall define how a binding type implementation or component
implementation type can declare intents that it is capable of supporting either
natively or through configuration/attachment of concrete policy.
7. The TC shall specify intents for, but not limited to, Reliable Messaging, Security
and Transactionality. It may also specify intents for common usage profiles such
as the WS-I profiles.
8. The TC may specify concrete policies for, but not limited to, Reliable Messaging,
Security and Transactionality. It may also specify concrete policies for common
usage profiles such as the WS-I profiles.
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 and concrete policies may form part of
the test suite, and are only provided as working samples which can be replaced by
other specific implementations and bindings and policies.
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 messaging middleware,
nor to specific network transports.
The following items are specifically out of scope of the work of the TC:
1. Creation of a new concrete policy expression language, including modification to
existing policy languages. That is, the semantics of existing policy language(s)
used cannot be altered by the work of the TC.
2. Requirement to use any specific policy expression language, such as WS-Policy.
3. 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.
d. Deliverables
The TC has the following set of deliverables:
1. A Service Component Architecture Policy Framework Specification and
associated Schema which encompasses the following items. A Committee
Specification is scheduled for completion within 12 months of the first TC
meeting.
a. A set of XML structures to specify abstract requirements and policy
wrappers and associate them with SCA constructs.
b. Semantics for the use of the above structures.
c. A set of commonly used intents and policies that every SCA
implementation must support to be compliant.
d. Conformance statements
2. A complete Test Suite specification for the SCA Policy Framework Specification,
including a document and the related materials described in the scope section. A
Committee Specification is scheduled for completion within 12 months of the first
TC meeting.
3. For each deliverable listed above, the TC shall define a concrete exit criteria as
early as possible after the TC starts operating. The exit criteria should include
measures to ensure that the specifications produced by the TC are implementable,
the test suite produced by the TC is useful to test the compliance of the
implementations, and the stated goal of the specifications (such as
interoperability, portability, etc) is demonstratably achieved by the
implementations.
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 an 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
* Software architects and programmers, who design, write, integrate and deploy
applications using a service-oriented architecture
* Policy administrators who create and govern policy for services in a service-
oriented architecture
* End users implementing solutions that require the ability to express abstract policy
requirements in an portable fashion
* 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, WS-Policy. 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 (e.g. to define specific implementation types for artifacts such as JEE
EJBs).
b. Proposed date, time, and location of first TC meeting
Date: Sept 3
Time: 12:00 EDT
Duration: 1 hour
Mode: Teleconference
Telephone: Dial-in TBC, along with e-Meeting facilities
Sponsor: BEA
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: BEA
c. On-going schedule
Weekly 60 Minute teleconferences sponsored by TBD.
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. Proposers
The following eligible individuals are in support of this proposal:
Ashok Malhotra, Oracle, ashok.malhotra@oracle.com
Sabin Ielceanu, TIBCO Software, sabin@tibco.com
Michael Rowley, BEA Systems, Inc., mrowley@bea.com
Nicole Wengatz, Siemens AG, nicole.wengatz@siemens.com
Patrick Leonard, Rogue Wave Software, pleonard@quovadx.com
David Booz, IBM Corporation, booz@us.ibm.com
Sanjay Patil, SAP, sanjay.patil@sap.com
Ron Ten-Hove, Sun Microsystems, ronald.ten-hove@sun.com
e. Convener:
Michael Rowley, BEA Systems, Inc., mrowley@bea.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 Policy Framework 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-P TC.
h. Draft FAQ Document
Intentionally left empty.
i. Proposed working title
Service Component Architecture Policy Framework Specification
REFERENCES
[1] SCA Assembly Model Specification Version 1.0
http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf
[2] SCA Policy Framework Specification Version 1.0
http://www.osoa.org/download/attachments/35/SCA_Policy_Framework_V100.pdf
[3] SCA Java Common Annotations and APIs Specification Version 1.0.
http://www.osoa.org/download/attachments/35/SCA_JavaAnnotationsAndAPIs_V100.pdf