SOA Policy Tools
SOA Policy Tools
The SOA Policy Tools project is a proposed sub-project under the top level Eclipse SOA Platform Project. The proposal is written to solicit
additional participation and input from the Eclipse community. You are invited to comment on and join the project. Please send all
feedback to the SOA Policy Tools forum.
Policies provide a means to describe just about any property that can be applied to an entity. Corresponding standards, such as the WS-Policy family of standards published by the W3C, have been established to provide a machine-readable, standardized format to capture policies and apply them to selected entities. These standards are being used especially in the SOA context to capture non-functional aspects of services.
Currently, the STP project contains a component named STP Policy Editor. This component provides a GUI-based editor to create and edit XML documents that conform the the WS-Policy standard published by the W3C.
The aim of this proposal is to initiate a sub-project of the SOA Platform Project that builds on the current STP Policy Editor component to provide a more comprehensive toolkit for policy handling.
The charter of the SOA Policy Tools sub-project is the creation of extensible tools and exemplar implementations such as editors, connectors, repositories, libraries, storage, validation, management, manipulation and extraction related to policies. Of particular interest are the official WS-Policy standardized formats and assertions that conform to these standards. Beyond WS-Policy, non-XML based policy expressions such as SCA Policy assertions are also of interest for the project.
A secondary goal is to further re-use within the eclipse ecosystem by identifying aspects within the policy editor that could be of general interest to other eclipse projects and to provide them as seperate bundles.
We also aim to link the tools provided by the SOA Policy Tools project with other Eclipse tools that could apply WS-Policy within their problem domain, such as the STP SCA tools. STP Policy Editor will also interact with the Eclipse Mangrove component.
The SOA Policy Tools project will focus on providing advanced, user-friendly and extensible tools to
- specify concrete policy languages that describe policies in a user-defined problem domain and
- create, edit, manipulate and store policy documents that conform to these policy languages
- enable team-based functionality for sharing, versioning, comparing these policy documents
Internal components that provide generic functionality (i.e., that do not only apply to editing policies) will be provided as separate bundles to foster re-use. Where appropriate an integration with other projects such as Mangrove, SCA tools and BPMN modeler.
- Policy structure editor - the top-level editor component that is responsible for instantiating policy documents and display and manipulate their high-level structure
- XEF - an extensible framework for the dynamic creation of editors from annotated XML Schema. This will be used to provide a generic editor for user-defined policy assertion types
- Validation framework - an extensible framework to integrate validation mechanisms for arbitrary document types
Relationship with other Eclipse projects
The SOA Policy Tools project will be built on top of the Eclipse Platform and will have relationships with other Eclipse projects.
- The SOA Policy Tools project will aim to supply policy editing capabilities to any sub-project of the SOA Platform Project and components that requires this capability. At
the least, this would cover
- An EMF-based model will be used to create a model to represent WS-Policy documents for processing within
the Policy Editor and for interoperability with other EMF-based components.
- The Web Tools Platform project currently provides some internal code. In addition the Policy Editor's look & feel is modelled after the WTP WSDL editor.
Other projects will be added to this list when required.
We propose that this sub-project will take place under the top level SOA PLatform Project.
Proposed initial committers
The initial project team will consist of the current committers to the existing STP Policy Editor component:
- Gerald Preissler (lead) - SOPERA - STP Policy Editor component committer
- David Bosschaert - Individual - STP Policy Editor component committer, initial contributor of the XEF component
- Andrei Shakirin - SOPERA - STP Policy Editor component committer
- Oisin Hurley - Individual - STP Project lead
- Zsolt Beothy-Elo - SOPERA - SOA Platform Project lead
- Renat Zubairov - SOPERA - STP Policy Editor contributor. He has already initiated the Policy Editor GUI walkthrough and will work on the refactoring of the user interface.
The initial code contribution will consist of the following components:
- The XEF component as currently present in the STP Policy Editor
- The Policy Structure Editor as currently present in the STP Policy editor
- The Validation Framework as proposed by SOPERA (currently undergoing IP compliance processing)
- Policy structure editor - rework of the user interface look and feel and better integration of the XEF editor as outlined during the GUI walkthrough
- XEF -
Architectural extensions to add greater control over the construction of editors and processing of editor input, especially in the area of user-defined policy assertions. Exemplars for these extensions. Annotated schema and editors for standardized WS-Policy formats, for example WS-ReliableMessaging, WS-SecurityPolicy.
- EMF-based model to replace the current bespoke policy implementation. Shall support the current version of the WS-Policy standard and all defined policy operations.
- Extension framework - A framework to add user-defined policy assertion types via OSGi bundles
New wizards for the creation of policy documents using XEF, policy category in the wizards, policy preferences, documentation, etc.
- Policy operation support - provide integrated support for the policy operations defined in WS-Policy
Policy Team APIs -
For interaction with a policy repository, check in, check out, browse. How would this work...?
- M1 08/2010: First version of extension framework
- M2 12/2010: Rework of extension framework, user interface rework, EMF-based model