'''''<nowiki>&nbsp;&nbsp;&nbsp;</nowiki>Johnson Ma''': After reconsidered, i don't think we need a policy model during service creation. The interaction between policy editor and service creation is through ws-policy file. That ws-policy file will be treated as regular xml file in service creation.''

−

The Policy Schema/Snippet Registry will be used to hold all policy Schemas and Policy Snippets to share cross projects.

+

+

== Policy Registry ==

+

The Policy Registry will be used to hold all policy Schemas and Policy Snippets to share cross projects.

Line 79:

Line 81:

=== Policy Registry Preferences ===

=== Policy Registry Preferences ===

+

Each SchemaProvider extension should comes with a preference page for configuration.

+

The preference page of FileSchemaProvider will looks similar to the validation rule set preference page below:

+

It consists of two parts:

+

Schema dir/file list, with add/remove button to allow users to add/remove schema/snippets to the provider

+

schema/snippets table, which will list name and description of all schemes and snippets retrieved from this provider.

−

=== Policy Templates Database ===

+

[[Image:Validator_preference.PNG]]

−

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 Template Set Extension Point ===

−

Extension point to allow users to add pre-defined policy Template set to the registry. We will load those pre-defined policy sets

−

during startup, and add them to the policy template database.

−

== Policy Creation ==

== Policy Creation ==

−

It means to create policy instance with policy editor from policy template (or policy schema ) and associate policies to service component

+

It means to create policy instance with policy editor from policy schema (or policy snippets ) and associate policies to service component

=== Policy Editor ===

=== Policy Editor ===

Line 115:

Line 115:

# ''Are we going to proceed policy references?''

# ''Are we going to proceed policy references?''

−

=== Policy Association / Policy View ===

+

=== Policy Editor inside Service Editor ===

−

Policy View will list all of the policies associated with a service component.

+

During Service creation, the multiple pages Service Editor will be the central place to setup service attributes, add/remove policies,

−

It allows users to add/remove policy.

+

and config assemble and deployment information. So the policy editor will be one page of the Service Editor. Please reference the screenshot below.

−

The add action will bring up the policy editor.

+

−

Here is the screenshot:

+

==== Screenshots ====

+

[[Image:Service_policy.PNG]]

−

[[Image:Policy_view.PNG‎]]

+

==== Setup policy editor within Service Editor ====

+

To create policy editor page, we will setup

−

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

+

'''''CompositeSchemaProvider''''', which implements the ISchemaProvider interface from XEF and will load all SchemaProvider extentions,

−

=== Policy Association during Deployment ===

+

'''''service.policy file''''', which is used to save the mapping between service component and policy file.

−

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

+

+

For example, if user associated the hello_world.policy as policy file for the hello_world service. We will save this information in the service.policy file under service folder. Based on this, we will create XMLProviderEditorInput for the policy editor, and like to the hello_world.policy file.

−

== Policy Validation ==

+

Another example, if user keep policy in the hello_world.wsdl file, we will create XMLProviderEditorInput, and link to the hello_world.wsdl as well.

−

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

+

== Policy Validation ==

−

Define the subject set which the policy may apply

+

−

For example:"

+

−

<validation>

+

−

<rule>

+

−

<!-- policy A can apply to both endpoint and message -->

+

−

<subjects policy_id = "policy A">

+

−

<subject>endpoint</subject>

+

−

<subject>message</subject>

+

−

</subjects>

+

−

</rule>

+

−

<rule>

+

−

<!-- policy B can only apply to message -->

+

−

<subjects policy_id = "policy B">

+

−

<subject>message</subject>

+

−

</subjects>

+

−

</rule>

+

−

</validation>

+

−

+

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

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

Line 207:

Line 165:

'''''<nowiki>&nbsp;&nbsp;&nbsp;</nowiki>Andrei Shakirin''': I am missing the alignment with WS-Policy model also for validation. Described constraints basically can be applied also to policy assertions and policy alternatives, not only to policies themself. Are you going to check compatibility and dependencies on policy assertion and policy alternatives levels (inside one policy)?''

'''''<nowiki>&nbsp;&nbsp;&nbsp;</nowiki>Andrei Shakirin''': I am missing the alignment with WS-Policy model also for validation. Described constraints basically can be applied also to policy assertions and policy alternatives, not only to policies themself. Are you going to check compatibility and dependencies on policy assertion and policy alternatives levels (inside one policy)?''

−

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

+

'''''<nowiki>&nbsp;&nbsp;&nbsp;</nowiki>Andrei Shakirin''': As Jerry already announced in dev-list, we have plans to generalize the validation components that are currently integrated with our (sopera's) editors into a generic validation framework. This framework is independent from validation object and validation method (technology). It just defines set of interfaces for validation object and its dependencies, validator itself, error reporter, etc. Developer will implement and register his own validation engine as OSGi plug-in in framework. To validate the object it will be necessary to implement validation object context interface, provide implementation of error reporter, define the chain of validation plug-ins and invoke the framework. Framework itself do not have any restrictions to validation method: it could be everything. Currently we use schema and DOM-based logical validation for our ws-policies. Of course it could be extended/replaced by rule-based validation engine. Maybe it would be a good idea to contribute the code directly and work on the generalization together?''

−

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.

−

'''''<nowiki>&nbsp;&nbsp;&nbsp;</nowiki>Andrei Shakirin''': As Jerry already announced in dev-list, we have plans to generalize the validation components that are currently integrated with our (sopera's) editors into a generic validation framework. This framework is independent from validation object and validation method (technology). It just defines set of interfaces for validation object and its dependencies, validator itself, error reporter, etc. Developer will implement and register his own validation engine as OSGi plug-in in framework. To validate the object it will be necessary to implement validation object context interface, provide implementation of error reporter, define the chain of validation plug-ins and invoke the framework. Framework itself do not have any restrictions to validation method: it could be everything. Currently we use schema and DOM-based logical validation for our ws-policies. Of course it could be extended/replaced by rule-based validation engine. Maybe it would be a good idea to contribute the code directly and work on the generalization together?''

+

'''''<nowiki>&nbsp;&nbsp;&nbsp;</nowiki>Johnson Ma''':So, we will use the policy validation mechanism provided by the xef policy editor in the first release. And we will move on to use the gneneric validation framework from Jerry later on.

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.

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

Johnson Ma: The Metadata attribute of our policy data model is indeed WS-Policy document. So we are stick to the WS-Policy format for expressing policies in that case. However, we need more than that during service creation. Such as the dependencies you mentioned below, which will be used during policy validation. So we may want our policy model to cover those attributes as well.

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) which then refers to the schema through its namespace.

Johnson Ma: policy instance is saved together with service model (the STP intermediate metamodel). During service creation, maybe we cab create three files:

*Service.desc, Which is a service description and attributes. It is mapped to the service metamodel.*service.policy, WS-Policy document, holding all policies configured for this service*service.assemble, keep assembling information. Such as what image file, word doc should be packaged into deployable.

Furthermore, maybe we can have a multiple-tab service editor, which including:

--- service attributes editor tab.--- policy editor tab, add/remove policies to/from service--- service assembly editor tab. define what files should be included into the deployable package. such as icon, copyright...etc

Andrei Shakirin:

As I can see, proposed policy data model has no equivalents for WS-Policy model elements: policy assertion and policy alternative. Are you going to introduce them? I think it could be difficult to represent policy in WS-Policy format and interpret external WS-policies without definition of these elements/constructs.

How attributes name, namespace, version, PolicyID, PolicyURL are mapped to WS-Policy Name and Id? WS-Policy Name attribute is unique identifier of the policy (normally namespace + local name). Id attribute is local policy identifier inside the document:

Johnson Ma: After reconsidered, i don't think we need a policy model during service creation. The interaction between policy editor and service creation is through ws-policy file. That ws-policy file will be treated as regular xml file in service creation.

Policy Registry

The Policy Registry will be used to hold all policy Schemas and Policy Snippets to share cross projects.

XEF Policy Editor supports for registry

The XEF Policy Editor defined ISchemaProvider interface, which is used by the editor to lookup policy schema and snippets.
The policy registry will use ISchemaProvider interface to pass schema/snippets data to the editor.

Policy Registry Extension Point

We will define SchemaProvider Extension Point.
By default, stp will provide FileSchemaProvider extension, which is used to load schema/snippets from directory/files.
Users can write DBScheamProvider to retrieve schames from database in more complicated situation.

Before creating XEF policy editor, we will create a composite SchemaProvider to combine all SchemaProvider extensions, and pass this composite SchemaProvider to policy editor.

Policy Registry Preferences

Each SchemaProvider extension should comes with a preference page for configuration.
The preference page of FileSchemaProvider will looks similar to the validation rule set preference page below:

It consists of two parts:

Schema dir/file list, with add/remove button to allow users to add/remove schema/snippets to the provider
schema/snippets table, which will list name and description of all schemes and snippets retrieved from this provider.

Policy Creation

It means to create policy instance with policy editor from policy schema (or policy snippets ) 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)

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.

Andrei Shakirin: It is exactly my vision. Both editors should be able to edit WS-Policy document, but will represent it differently for the user. But the question for me is: are we going to support any WS-Policy document without any restrictions?

Should editors process ws-policies that are not in normal form and, optionally, transform them into normal form? (wtp based editor supports at the moment only extended variant of normal form, it of course should be improved).

Are there any restrictions/requirements for custom assertions? (wtp based policy editor supports at the moment only predefined set of assertions, it should be extended as well).

Are we going to proceed policy references?

Policy Editor inside Service Editor

During Service creation, the multiple pages Service Editor will be the central place to setup service attributes, add/remove policies,
and config assemble and deployment information. So the policy editor will be one page of the Service Editor. Please reference the screenshot below.

Screenshots

Setup policy editor within Service Editor

To create policy editor page, we will setup

CompositeSchemaProvider, which implements the ISchemaProvider interface from XEF and will load all SchemaProvider extentions,

service.policy file, which is used to save the mapping between service component and policy file.

For example, if user associated the hello_world.policy as policy file for the hello_world service. We will save this information in the service.policy file under service folder. Based on this, we will create XMLProviderEditorInput for the policy editor, and like to the hello_world.policy file.

Another example, if user keep policy in the hello_world.wsdl file, we will create XMLProviderEditorInput, and link to the hello_world.wsdl as well.

Policy Validation

David Bosschaert: FWIW, the XEF-based policy editor already supports some of these constraints. They are specified through annotations in the XML-Schema, which are 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 expresses that the HTTPS policy can only 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.

There is also another type of constraint that is currently handled by the XEF policy editor around what policies should be allowed when. The following example uses a 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 it prevents a user from applying a http and an ftp policy at the same time. Some other policy categories allow multiple policies to be applied of the same type, e.g. QoS type policies.

Andrei Shakirin: I am missing the alignment with WS-Policy model also for validation. Described constraints basically can be applied also to policy assertions and policy alternatives, not only to policies themself. Are you going to check compatibility and dependencies on policy assertion and policy alternatives levels (inside one policy)?

Andrei Shakirin: As Jerry already announced in dev-list, we have plans to generalize the validation components that are currently integrated with our (sopera's) editors into a generic validation framework. This framework is independent from validation object and validation method (technology). It just defines set of interfaces for validation object and its dependencies, validator itself, error reporter, etc. Developer will implement and register his own validation engine as OSGi plug-in in framework. To validate the object it will be necessary to implement validation object context interface, provide implementation of error reporter, define the chain of validation plug-ins and invoke the framework. Framework itself do not have any restrictions to validation method: it could be everything. Currently we use schema and DOM-based logical validation for our ws-policies. Of course it could be extended/replaced by rule-based validation engine. Maybe it would be a good idea to contribute the code directly and work on the generalization together?

Johnson Ma:So, we will use the policy validation mechanism provided by the xef policy editor in the first release. And we will move on to use the gneneric validation framework from Jerry later on.

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.

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.