Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, November 26, 2007 2:51 AM
Subject: Policy Framework Scenarios.
Hi,
Most part of the core policy framework now implemented except for the
thing
that deals with evaluating the 'appliesTo' xpath against the SCDL which is
a
bit incomplete. I hope to wrap this too in a week.
IMO, it's a bit challenging from two perspectives to apply the xpath:
1) The xpath needs to apply to an XML sub tree in the SCDL.
2) We need to deal with XML inheritance/subsitutionGroup, for example, the
xpath "sca:implementation" will match "sca:implementation.java".
Meanwhile, I'd like to whet and evolve whatever has been done with
different
user perspectives... so here are some perspectives I could think of...
could
people kindly help with their opinions and inputs on this, please.... also
if any of you have other scenarios or ways of approaching this... please
pitch in...
A) Perspective of Policy Administrator ....
------------------------------------------------------------
- defines a bunch of intents and policysets for the domain, in the
definitions.xml
- profiles the various binding-types and implementation-types for the
various intents it 'mustProvide' and 'mayProvide'
1) How does the Policy-Admin know from a binding/impl type about the
intents that it provides for ? Should every binding/impl type have its
own
definitions.xml file where it publishes this information ? The specs says
that there is just this one file for the entire SCA domain - have I got it
wrong?
2)What about the bunch of intents that the spec states as something
that
would be supported by every SCA Runtime such as authentication,
confidentiality, integrity etc. Since it makes no sense to have every
binding/impl type to define this as well, should we have a global
definitions.xml in the core module where we define these ?
3) A binding / implementation type could have its own custom model of
representing policies within policysets and interpretting them. For
example
the ws-binding-axis2 use config param model (which is custom made) and
ws-policy assertion model (which is a standard) to represent policies.
How
should this model information be communicated to the Policy Admin in a
standard way that is consistent across binding/impl types? If we allow
every binding/impl type to have its own definitions.xml then could this
also
contain the xsd for the policy model?
I don't think a global definitions.xml will fly. There are a few players in
the picture:
a) Intent: Define the abstract requirements
b) PolicySet: Define the concrete configuration of policies that can be used
to realized one or more intents
c) ImplementationType and BindingType: Define the intents that an
implementation or binding type always provides or may provide.
a) should be provided by Tuscany core runtime and extensions, for example,
the policy-transaction module will package the intent definitions for
transactions.
b) should be contribution-based. Different contributions should be able to
configure an intent differently. For example, for authentication, we may
configure different userid/password pairs and for authorization, we may
select different roles.
c) should be provided by the Implementation/Binding extensions
B) Perspective of Binding/Impl type developer ...
---------------------------------------------------------------------
- defines the intents and xsds for the policy model that the binding/impl
type will use
- defines the StAX processors for loading the policy model that the
binding/impl type will use
- adds code to interpret various policies and exercise them.
1) Do we leave the design for this to every binding / implementation
type or do we put in a programming model that is to be common across all
binding/impl types? I'd feel it would be better to leave it to the
bindings/impl extension because each extension will have its own way of
implementing various QoS and how it would interface with a QoS
infrastructure as part of its (i.e. the extension's) lifecycle. For
example
the binding-ws-axis2 injects security related policies into the
axis2-config
during the service and client creation time and does nothing specific
during
invocation of service operations.
Sorry about making this very long.
Thanks
- Venkat
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
