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:
-
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.
-
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.
-
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.
-
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.
-
For interaction policies, defining how policies on services and references may be matched on an SCA wire through static analysis, is in scope.
-
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.
-
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.
-
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:
-
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.
-
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.
-
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:
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:
-
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.
-
Requirement to use any specific policy expression language, such as WS-Policy.
-
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.
Deliverables
The TC has the following set of deliverables:
-
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 set of XML structures to specify abstract requirements and policy wrappers and associate them with SCA constructs.
-
Semantics for the use of the above structures.
-
A set of commonly used intents and policies that every SCA implementation must support to be compliant.
-
Conformance statements
-
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.
-
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.
