Difference between revisions of "Policy Framework in STP"
Line 1: | Line 1: | ||
== Introduction == | == Introduction == | ||
− | This doc is | + | This doc is aimed to define a framework to enforce SOA policy during developing and deploying service component. |
It includes | It includes | ||
*Policy Model | *Policy Model | ||
Line 14: | Line 14: | ||
== Policy Data model == | == Policy Data model == | ||
− | The policy model used here is different | + | The policy model used here is different from policy defined in ws_policy or sca policy framework. |
− | It will | + | It will focus more on the policy metaphor used during service creation and deployment. |
'''Name''', the name of the policy | '''Name''', the name of the policy | ||
Line 21: | Line 21: | ||
'''Description''', policy description | '''Description''', policy description | ||
− | '''Category''', such as transport, binding, security... | + | '''Category''', such as transport, binding, security, and etc... |
'''Version''', policy version. We should support versioning in the policy framework | '''Version''', policy version. We should support versioning in the policy framework | ||
− | '''Metadata''', the represented underline policy. It maybe a policy file or policy | + | '''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?) | (Add Policy Model to STP Intermedia Metadmodel?) | ||
Line 31: | Line 31: | ||
== Policy Registry == | == Policy Registry == | ||
− | The Policy Registry will used to hold all policies to share cross projects. | + | The Policy Registry will be used to hold all policies to share cross projects. |
It will provide following functions: | It will provide following functions: | ||
*addPolicy | *addPolicy | ||
Line 40: | Line 40: | ||
*getPolicy | *getPolicy | ||
− | + | 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. | |
Line 50: | Line 50: | ||
=== Policy Set Extension Point === | === Policy Set Extension Point === | ||
− | Extension point to allow | + | 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. | during startup, and add them to the policy database. | ||
== Policy Creation == | == Policy Creation == | ||
− | + | It means to create policy with policy editor and associate policies to service component | |
=== Policy Editor === | === Policy Editor === | ||
− | + | There are two policy Editors in STP: | |
XEF Policy Editor: It is a generic schema based policy editor. | XEF Policy Editor: It is a generic schema based policy editor. | ||
− | WTP based Policy Editor: | + | WTP based Policy Editor: It is used to create policy following ws-policyattachment? |
=== Policy Association / Policy View === | === Policy Association / Policy View === | ||
Policy View will list all of the policies associated with a service component. | 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. | The add action will bring up the policy editor. | ||
Line 73: | Line 73: | ||
[[Image:Policy_view.PNG]] | [[Image:Policy_view.PNG]] | ||
− | When user add/move policy from service component, the policy validator will be called. | + | When a user add/move policy from service component, the policy validator will be called. |
− | === Policy | + | === Policy Association during Deployment === |
Maybe the deployment profile editor needs to be extended to support applying policies at deployment stage. | Maybe the deployment profile editor needs to be extended to support applying policies at deployment stage. | ||
Line 81: | Line 81: | ||
== Policy Validation == | == Policy Validation == | ||
The policy validation framework is used to define a validation mechanism when applying policies to a service component. | 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 | + | 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 following | + | The validation rules will cover the following categories: |
=== Policy Dependency === | === Policy Dependency === | ||
− | Define | + | Define dependency relationship between policies. |
− | + | For example: | |
<validation> | <validation> | ||
<rule> | <rule> | ||
Line 99: | Line 99: | ||
=== Policy Conflict === | === Policy Conflict === | ||
Define conflict relationship between policies | Define conflict relationship between policies | ||
− | + | For example: | |
<validation> | <validation> | ||
<rule> | <rule> | ||
Line 112: | Line 112: | ||
=== Policy Subject Constraints === | === Policy Subject Constraints === | ||
Define the subject set which the policy may apply | Define the subject set which the policy may apply | ||
− | + | For example:" | |
<validation> | <validation> | ||
<rule> | <rule> | ||
Line 131: | Line 131: | ||
=== Policy Validation Engine Implementation === | === Policy Validation Engine Implementation === | ||
− | Need to write | + | 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, | + | to do the validating, then give error message if applicable. |
==== eclipse.emf.validation ==== | ==== eclipse.emf.validation ==== | ||
Line 145: | Line 145: | ||
Policies will be translated into different runtime artifacts at various stages. | Policies will be translated into different runtime artifacts at various stages. | ||
− | === Policy to Artifact | + | === Policy to Artifact Mapping === |
− | Policies maybe be | + | Policies maybe be mapped to: |
configuration file | configuration file | ||
@Policy annotation | @Policy annotation | ||
Line 152: | Line 152: | ||
=== When? === | === When? === | ||
− | When | + | 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. | 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. | Then allow user to add customized processor at any stage by extension point. | ||
Line 159: | Line 159: | ||
=== How? === | === How? === | ||
− | Since the policy to runtime artifacts mapping is | + | Since the policy to runtime artifacts mapping is runtime specific. we will a provide processor extension point |
− | to allow | + | to allow users to hook the process function. |
Line 167: | Line 167: | ||
*Service Developer -- write policy, config and apply existing policy to service component. | *Service Developer -- write policy, config and apply existing policy to service component. | ||
*Deployment Assembler -- apply policies to services during deployment | *Deployment Assembler -- apply policies to services during deployment | ||
− | *Operator -- | + | *Operator -- dynamicly config/modify policies at runtime. |
− | == Runtime | + | == Runtime Support == |
== Example == | == Example == | ||
Revision as of 04:29, 30 September 2007
Contents
Introduction
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
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.
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?)
Policy Registry
The Policy Registry will be used to hold all policies to share cross projects. It will provide following functions:
*addPolicy *removePolicy *updatePolicy *listCategories *listPolicies *getPolicy
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.
WTP based Policy Editor: It is used to create policy following ws-policyattachment?
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:
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:
<validation> <rule> <dependency policy_id = "policy A"> <on policy_id="policy B", version="2.0"/> <on policy_id="policy C"/> </dependency> </rule> </validation>
Policy Conflict
Define conflict relationship between policies For example:
<validation> <rule> <conflict policy_id = "policy A"> <with policy_id="policy D", version="2.0" /> <with policy_id="policy E" /> </conflict> </rule> </validation>
Policy Subject Constraints
Define the subject set which the policy may apply For example:"
<validation> <rule> <subjects policy_id = "policy A"> <subject>endpoint</subject> <subject>message</subject> </subjects> </rule> <rule> <subjects policy_id = "policy B"> <subject>message</subject> </subjects> </rule> </validation>
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.
eclipse.emf.validation
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 WS-Policyattachment
When?
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.
How?
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
Example
Questions
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.