STPPolicyMeetingAgendaNov22th

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:

N	Description	Benefits	Drawbacks
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

Neethi model

I see following benefits of using Neethi model:

1. Model will abstract code from ws-policy format and make it less critical to future format changes
2. Developers can work directly with policy structure elements: alternatives, assertions, references
3. Neethi provides serialization, deserialization, intersection and merging functionality
4. 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)?

Policy Registry

• 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

Validation

• How the validation framework will look like?
• Will we support rules based validation?
• How to make logical restrictions in policy structure available in GUI?