[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [stp-dev] Discussion on policy support in STP
|
Hi Andrei,
I got better understanding about the policy support in service creation after talked with David last week. I will update the wiki to reflect some latest changes.
Here are some of my answers:
1. policy data model
The ws-policy file is only handled by policy editor. So other parts of service creation will not understand those ws-policy model elemens, such as assertion and alternative.
The policy data model referenced in the wiki is not for the ws_policy file. It is part of the service model used in the service editor. Please reference the service editor proposal[1] I am working on.
Indeed, It will maps to two files:
*policy.registry file
registry file is used to manage policy schemas and policy snippets across the workspace.
*service.policy file
This file is used to save the mapping between one service and its policy file. Thus we can setup the policy editor page in the service editor.
2. policy attributes
Those policy attributes are attributes of policy schemas or policy snippets, which are managed by the policy registry.
The XEF policy editor define ISchemaProvider interface to allow users to register new policy schema.
In service creation, we may build a policy registry based on that:
* preference page to allow user to add/remove policy schema (or policy snippet)
* Define a PolicySchemaProvider extension point. Then We will provide a FileSchemaProvider by default, which is used to load schemas from working directory. User may write a database schema provider to load schems from db in more complicated situation.
3. policy editor
IMHO, the XEF policy editor doesn't have those restrictions, such as normal form, custom assertions.
Am i right on this, David?
4. Policy Validation.
I was been told that, the XEF policy editor already comes with validation support. You can add annotations in the schema for policy validation. However, i am not sure if this validation works for assertions and alternatives.
I will update the policy wiki to use the xef policy validation instead of trying to define a new mechanism for now.
5. Generic validation framework.
Cool. That will be a very useful component.
And i think it can be used in both service creation and runtime governance?
Thanks
Johnson
[1]http://wiki.eclipse.org/Service_Editor
On 10/25/07, Andrei.Shakirin@xxxxxxxxxxxxxxx
<Andrei.Shakirin@xxxxxxxxxxxxxxx> wrote:
Hi Johnson and David,
I have also some comments and questions on the Policy Framework
published in wiki (http://wiki.eclipse.org/Policy_Framework_in_STP
).
Could we discuss them?
1. Policy Data Model.
As I can see, proposed policy data model has no equivalents for two
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.
2. Policy Attributes.
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:
<wsp:Policy
Name="
http://fabrikam123.example.com/policies/P1"
wsu:Id="P1"
xmlns:wsp="
http://schemas.xmlsoap.org/ws/2004/09/policy" >
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
urity-utility-1.0.xsd" >
<!-- Details omitted for readability -->
</wsp:Policy>
3. Policy Editors.
My vision here is the same as David's: 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?
a) 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).
b) 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).
c) Are we going to proceed policy references?
4. Policy validation.
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)?
5. Generic validation framework.
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?
Regards,
Andrei
-----Original Message-----
From: stp-dev-bounces@xxxxxxxxxxx [mailto:stp-dev-bounces@xxxxxxxxxxx
]
On Behalf Of David Bosschaert
Sent: Donnerstag, 11. Oktober 2007 21:58
To: STP Dev list
Subject: Re: [stp-dev] Discussion on policy support in STP
Doh, forgot the link:
The following page contains quite a number of example XML-Schemas and
also example Policy instances that could be created from them:
http://wiki.eclipse.org/Policy_editor_documentation
David Bosschaert wrote:
> Some more details:
>
> The ISchemaRegistry assumes PolicyTemplates to be XML Schemas, where
> each policy template is identified by its namespace.
> The XML Schema is used to define the form of the actual policy
> content, but can also contain other such as Display Name,
> Documentation, Short Description & Category. For Documentation the
> standard <xs:documentation> annotation is used, for the other metadata
> new annotations were defined, see here:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.servicecreati
> on/org.eclipse.stp.xef/schema/xef.xsd?root=STP_Project&view=co
>
>
> There seems to be quite a bit of overlap between the metadata that the
> policy editor currently reads from the XML Schema and the requirements
> in
http://wiki.eclipse.org/Policy_Framework_in_STP
>
> The following page contains quite a number of example XML-Schemas and
> also example Policy instances that could be created from them.
>
> Additionally, the ISchemaProvider can use pieces of XML (non-Schema)
> as a template for a policy. This is to provider blueprints instead of
> XML Schema. This is called a Snippet in this interface, in case you're
> wondering. The purpose for the snippets is to allow an end user to
> define a Template based on existing XML-Schema based template(s) with
> a number of values filled in, which could then be registered with the
> Policy Registry and reused as if it was a policy later. This is a
> convenience mechanism which allows the user to define things like 'My
> Company's Security Policy' which would internally contain a number of
> other policies with certain values filled in...
>
> Cheers,
>
> David
>
>
> David Bosschaert wrote:
>> Johnson Ma wrote:
>>> Gerald Preissler wrote:
>>>>
>>>> Do you propose to actually add a Policy Registry to STP or do you
>>>> want to provide the interface definition that an actual registry
>>>> has to conform to?
>>>
>>> Yes, i was thinking about adding a policy template registry to stp.
>>> Then, policy developers can create policy template and add to the
>>> registry.
>> FYI, the XEF-based policy editor already contains an interface (and a
>> simple implementation) of a Policy Template Registry. It's
>> org.eclipse.stp.xef.ISchemaProvider in the org.eclipse.stp.xef
>> plugin. The idea behind this interface is that it could be backed by
>> anything. A simple URLSchemaProvider is part of the STP code, but one
>> could also implement this over another system, e.g. a database
>> backend...
>>
>> See
>>
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.servicecreat
>> ion/org.eclipse.stp.xef/src/org/eclipse/stp/xef/ISchemaProvider.java?
>> root=STP_Project&view=markup
>>
>>
>> Cheers,
>>
>> David
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland) Registered Number:
> 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin
> 4, Ireland _______________________________________________
> stp-dev mailing list
> stp-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/stp-dev
>
----------------------------
IONA Technologies PLC (registered in Ireland) Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland _______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
