Revision as of 08:33, 23 November 2007 by Andrei.shakirin.sopera.de (Talk | contribs) (→Agenda of STP Policy Meeting 22.11.2007 (integration Policy Editors and Policy Framework))
Agenda of STP Policy Meeting 22.11.2007 (integration Policy Editors and Policy Framework)
Integration WTP-based Policy Editor and XEF Policy Editor
I see following alternatives to integrate editors:
|1||Editors will be developed independently. Each editor provides functionality to manage ws-policy structure (alternatives and assertions) and to edit assertions themselves as well. Synchronization will be achieved via serialization /deserialization in/from xml policy file. Editors will provide different representation of policy file based on Eclipse views.||low efforts; relative small changes in both editors; independent development of editors||some functionality will be duplicated; only persistence based synchronization will be possible; integration of editors will be not “native”: they use different models, different representations, different structures|
|2||Editors will be developed accordingly MVC pattern: they use common model (Neethi or another one) and provides different views of this model. Editors can shared also some representation functionality property pages.||dynamic synchronization will be possible; relative small changes in both editors; independent development of editors||higher efforts; dependencies between editors|
|3||Editors will provide different levels of policy representation: WTP-based policy editor will represent and process policy structure elements (alternatives, assertions, policy references, relationships, etc); XEF policy editor will be responsible for representation and edition of assertions content based on XML schema. In this case user can work with two representations: graphical and text xml. Graphical representation will provide GUI (in different views) to edit policy structure element (WTP-based) and content of every assertion (XEF-based).||no duplicated functionality; relative small changes in both editors; independent development of editors||higher efforts; dependencies between editors|
I see following benefits of using Neethi model:
- Model will abstract code from ws-policy format and make it less critical to future format changes
- Developers can work directly with policy structure elements: alternatives, assertions, references
- Neethi provides serialization, deserialization, intersection and merging functionality
- Neethi provides interface and basic implementation of Policy Registry
General topics of Policy Framework
Mapping between services and policies (service.policy file)
- Is it one to many or many to many relations?
- Are all service operations always mapped to the same policy(ies) or user will have a possibility to map some of service operations/bindings/messages to one policy and some of them to another?
- Will we use WS-Policy Attachment standard or other approaches (like mapping file)?
- Which solution will be used for policy registry?
In our opinion, the first step should be to define a good API for the registry, the maybe with a simple sample implementation. That way, we would reduce the effort for a first version that can be used to collect experiences. Maybe the Neethi registry API would be a good starting point
- How the validation framework will look like?
- Will we support rules based validation?
- How to make logical restrictions in policy structure available in GUI?