[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [stp-dev] Discussion on policy support in STP
|
Hi Johnson,
Regarding policy model: as I understood service creation
will operate with whole ws-policies files, not with ws-policy model elements
(policy category attribute was a little bit confusing for me, because one
ws-policy file could contain assertions belonging to different categories).
Is my understanding correct?
Regarding mapping between services and policies
(service.policy file):
1. Is it one to many or many to many
relation?
2. Are all service
operations always mapped to the same policy(ies) or user will
have a possibility to map some of service operations to
one policy and some of them to another? (it is useful if, for example,
operations in one service have different communication patterns and use
different physical transports)
Regards,
Andrei.
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
