Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search


Minutes of STP Policy Meeting 22.11.2007


  • David Bosschaert
  • Johnson Ma
  • Andrei Shakirin
  • Jerry Preissler

TOP 1: Integration of policy editors (XEF editor and WTP-like editor)

Andrei explained the integration options that were outlined in an advance document (will be available via wiki shortly). The discussion showed that both editors have strong points:

  • The XEF editor supports the definition of new policy assertion types by providing a correspondig xml schema
  • The WTP-like editor provides a flexible way to view/edit complex policy documents with multiple compositors

It was agreed that the solution that is outlined as option 3 in the referenced message provides a way to combine the strengths of both tools: use the WTP-like editor to view and edit the policy document as a whole and the XEF editor as a detail editor when fragments in the policy document that contain individual assertions need to be edited.

The models between both editors would be synchronized by passing the xml representation and an xpath expression identifying the fragment to be edited. The XEF editor already supports this mechanism, so this would be pretty straightforward to implement, whereas using the same model in both editors would be substantial work with little benefit.

Regarding the gui representation, it was decided to try to mimic the behaviour already implemented in the WTP WSDL editor, where the selection of certain components in a document opens a detail editor in the same composite.

The possibility to add an extension point to register custom editors for specific policy assertions was discussed and added as an option for the future.

Development on the joint editor should start soon, most probably in early December. It was agreed to try a "scrum-like" approach, where features will be described on one wiki page, with the necessary tasks listed with each feature and linked to one corresponding bugzilla entry per task.

As next tasks were defined:

  1. Design GUI look & feel.
  2. Design of interfaces and extension points in editor for integration.

TOP 2: Policy models and registry

As mentioned above, the XEF editor will stay with the current model for policies. For the WTP-like editor, two options that might make sense as an internal model were discussed:

  • internally using Neethi ( as a model. This would provide the capability to use the policy operations as defined in the WS-Policy standard that are implemented in Neethi without additional work.
  • using an EMF-based model of WS-Policy. This would enable us to use some of the facilities that are available for EMF-based models (e.g., OCL-based validation), but would require to implement the policy operations manually.

The topic will be investigated further.

Another aspect that was discussed is the issue of a policy registry. One (API and in-memory implementation) is provided by Neethi, another one is already present in the XEF editor. It was agreed that the main focus regarding a registry should be a good API definition, complemented by a corresponding extension point and a sample implementation.

As next tasks were defined:

  1. Analyse and compare both modeling possibilities (Neethi and EMF) and make final decision.
  2. Design policy registry interface (on the base of Neethi or XEF editor).

TOP 3: misc

The topic of validation mechanisms was discussed. There already is a validation component in the XEF editor that uses annotations in XML schemas to extend the validation rules that can be specified with XSD. There is also a validation implementation in the annotation components of the JAX-WS packages. The SOPERA participants (Andrei and I) mentioned the validation framework that has been discussed as a possible contribution by SOPERA. It was agreed that SOPERA will provide an overview about the ideas that are connected with this proposal in the wiki and the issue will be discussed in a further telco.

As next task was defined:

  1. Present SOPERA validation framework in more details, discuss and make final decision.

Thanks to all participants for a very interesting and productive discussion!

Back to the top