Venkata Krishnan wrote:
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...
I'll propose a scenario in a separate email.
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?
Good question for the spec group. On one hand it'd be nice to support
multiple definitions.xml files. On the other hand I trust that a system
administrator can do something like 'cat *.xml > definitions.xml' to put
multiple definitions in one file.
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 ?
I'd prefer one of the policy modules, but we need to clearly understand
(1) before going there I think.
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'm not sure I understand the issue here, if there is an issue but it'd
be nice for a custom policy language to be described with an XSD or some
form useful to the administrator.
B) Perspective of Binding/Impl type developer ...
---------------------------------------------------------------------
- defines the intents and xsds for the policy model that the binding/impl
type will use
In most cases the intents are probably defined separately, the binding
declares which ones it supports.
- 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.
+1 for leaving it to the binding/impl type.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
