Skip to main content
Jump to: navigation, search

Policy Framework in STP

Revision as of 05:45, 4 October 2007 by (Talk | contribs) (Policy Subject Constraints)


This doc is aimed to define a framework to enforce SOA policy during developing and deploying service component. It includes

*Policy Model
*Policy Registry
*Policy Creation
*Policy Validation
*Policy Processor 

Use Cases

Design Map

STP Policy Design.png

Policy Data model

The policy model used here is different from policy defined in ws_policy or sca policy framework. It will focus more on the policy metaphor used during service creation and deployment.

   David Bosschaert: How is it different? Is it only different in what it is used for? Regardless I think we should stick to the WS-Policy format for expressing policies.

Name, the name of the policy

Description, policy description

Category, such as transport, binding, security, and etc...

Version, policy version. We should support versioning in the policy framework

Metadata, the represented underline policy. It maybe a policy file or policy ID in the registry. For the policy file, it maybe a WS-Policy file or user proprietary xml file.

(Add Policy Model to STP Intermedia Metadmodel?)

   David Bosschaert: We would also need a policy namespace; from my experience the namespace is the most convenient way of identifying policies. Additionally we might also consider describing dependencies and having a way of providing documentation.

   David Bosschaert: One of the things that I'm really missing in this proposal is the difference between a Policy Template (or Policy Schema) and a Policy Instance. Policies instances are generally pieces of XML that are embedded in a WS-Policy document. These pieces of XML can (and should) be defined by an XML-Schema which one could call the Policy Schema. The Schema can contain basic XML-Schema supported validation constraints, but can also be used to hold other metadata, e.g. XML-Schema has a built-in annotation <xs:documentation> that can be used for documentation text. You add additional annotations if you wish to extends the XML-Schema with further metadata. I think that the above attributes should be obtainable from the Policy Schema. A Policy Instance is embedded in a WS-Policy document and takes the form of any XML tag (with sub tags and attributes) as long as it refers to the schema for its namespace.

Policy Registry

The Policy Registry will be used to hold all policies to share cross projects. It will provide following functions:


Due to the resource nature of the registry, we will implement it as a REST full service. We are looking for a generic tool to expose database table to REST service. If we can't find one, we may develop such a tool in STP.

Policy Database

In the first version, it will be implemented as XML file for simplicity. Later on, we will move to use embedded database (like Apache Derby) for better performance.

Policy Set Extension Point

Extension point to allow users to add pre-defined policy set to the registry. We will load those pre-defined policy sets during startup, and add them to the policy database.

Policy Creation

It means to create policy with policy editor and associate policies to service component

Policy Editor

There are two policy Editors in STP:

XEF Policy Editor: It is a generic schema based policy editor.
See here for a screen shot.
WTP based Policy Editor: provides a look & feel that is based on the WTP WSDL editor, supports WS-Policy documents with compositors (wsp:ExactlyOne, wsp:All)

The goal is to merge these two contributions into one editor that provides

  • flexible editing of any WS-Policy document
  • the ability to select between the views (schema based, wtp based, text)
  • extension points to register new policy assertions schemas and optionally specialized GUI parts

   David Bosschaert: I think the main difference between the XEF and the WTP based policy editors is how they present their information to the user. So I think it may make sense to merge them such that they represent different pages in a single multi-page editor.

Policy Association / Policy View

Policy View will list all of the policies associated with a service component. It allows users to add/remove policy. The add action will bring up the policy editor.

Here is the screenshot:

Policy view.PNG

When a user add/move policy from service component, the policy validator will be called.

Policy Association during Deployment

Maybe the deployment profile editor needs to be extended to support applying policies at deployment stage.

Policy Validation

The policy validation framework is used to define a validation mechanism when applying policies to a service component. Similar to policy editor. We will provide a policy validation rule editor for users to dynamicly add/remove validation rules as well.

The validation rules will cover the following categories:

Policy Dependency

Define dependency relationship between policies. For example:

    <dependency policy_id = "policy A">
      <on policy_id="policy B", version="2.0"/>
      <on policy_id="policy C"/>

Policy Conflict

Define conflict relationship between policies For example:

    <conflict policy_id = "policy A">
           <with policy_id="policy D", version="2.0" />
           <with policy_id="policy E" />

Policy Subject Constraints

Define the subject set which the policy may apply For example:"

    <subjects policy_id = "policy A">
    <subjects policy_id = "policy B">

   David Bosschaert: FWIW, the XEF-based policy editor already supports some of these constraints. They are specified through annotations in the XML-Schema, which is then enforced by the Policy Editor. Here are some examples that come from the test .xsd files in the org.eclipse.stp.xef.test fragment.

   Dependency: Here's an example HTTPS policy that depends on the HTTP and SOAP policies. It is currently used by the Policy Editor to only allow the HTTPS policy to be added if you already have a HTTP and a SOAP policy. It doesn't explicitly mention a version number, but as you can see the version is addressed through the namespace of the policy templates referred to.

<xs:element name="https">

There is also another type of constraint that is currently handled by the policy editor around what policies should be allowed when. The following example uses a <code> qualifier annotation to qualify a policy in a certain category. The HTTP policy is put in the 'transport' category. The multiple="false" attribute tells the code that only one policy of this category can be applied, thus is prevents a user from applying a http and an ftp policy at the same time. Some policy categories allow multiple policies to be applied of the same type, e.g. QoS type policies.

<xs:element name="http">
      <xef:qualifier multiple="false">transport</xef:qualifier>

Policy Validation Engine Implementation

Need to write an engine to support the above validation rules. When users add/remove a policy, we will call the engine to do the validating, then give error message if applicable.


Need to looking into the emf.validation to see if we can use use it here. User defines the validation rules from GUI. How to translate those rules to emf validator class on the fly is a problem in that case.

rule based xml validator in stp

Alternative, we may think about extend the current rule based xml validator to support policy validation here.

Policy Artifact Processor

Policies will be translated into different runtime artifacts at various stages.

Policy to Artifact Mapping

Policies maybe be mapped to:

configuration file
@Policy annotation


When is the policies processed? I don't have the clear picture about the timing yet. I think we need to clearly divide the service creation and deployment into several stages. Then allow user to add customized processor at any stage by extension point.


Since the policy to runtime artifacts mapping is runtime specific. we will a provide processor extension point to allow users to hook the process function.

User Roles

 *Policy Developer -- write policies and policy validation rules. write policy processor.
 *Service Developer -- write policy, config and apply existing policy to service component.
 *Deployment Assembler -- apply policies to services during deployment
 *Operator -- dynamicly config/modify policies at runtime.

Runtime Support



Relations with SCA Policy Framework?

The SCA policy association framework allows policies and policy subjects specified using WS-Policy and WS-PolicyAttachment, as well as with other policy languages, to be associated with SCA components.


Copyright © Eclipse Foundation, Inc. All Rights Reserved.