View source for 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:

{| class="wikitable" border="1" style="width:75%;"
|-
! 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:
# 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)?


== 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?