Venkata Krishnan wrote:
Hi Sebastien,
Yes its quite bizzare and thats probably to do with how I am seeing a way
out. Here it is...
- A policyset has this 'appliesTo' attribute that is an xpath expression
that should be evaluated against the scdl fragment which is parent element
to a binding or implementation element. If the result of the evaluation
includes the binding or implementation then the policyset is applicable to
that binding or impl.
- Having said that, its now a question of when this validation is to be
done. Since we need a complete PolicySet information that will include the
'appliesTo' attribute as well, this is something that we have to do
post-resolve which I think is the build phase.
- Now during the build phase, we have the binding instance and from it we
get the attached policyset (which is fully resolved) and from within that we
get the appliesTo attribute. But what we don't have is the scdl fragment
over which the xpath is to be evaluated i.e. the parent element of the
binding which is a composite service / reference or a component service or
reference
So thats the problem is about get hold of this scdl fragment.
OK I think I get it now :) If I understand correctly what you're suggesting:
- We need to validate the Xpath expression in the PolicySet.appliesTo
attribute, for example <policySet name="Foo" appliesTo="binding.ws"/>
means that we'll have to check that it's only applied to Web Service
bindings (in XML <binding.ws>).
- This can only be done once all policy declarations have been combined
/ overriden / aggregated etc. in the assembly "build" phase.
- You're thinking about evaluating the Xpath expression against the SCDL
representing the binding and the polices applied to it, and that's why
you're thinking about using the ArtifactProcessor write() methods to
produce that SCDL, then parse it back and give it to XPath...
If this is correct, then I have two comments:
- It is not clear to me that the intent of the spec is to evaluate the
XPath expression only against the SCDL. It says it, but it also seems to
contradict that statement in one of the samples, with
[EMAIL PROTECTED]
I would be surprised if impl="axis" was actually in the SCDL. Instead
I'd imagine that impl="axis" would be a characteristic of a particular
implementation of <binding.ws>, not exposed to app developers but used
by the policy framework to either select that axis-based implementation
over another one when it sees that policy, or validate that the
<binding.ws> implementation in use in your runtime configuration can
actually apply the requested policy.
So basically, an SCDL-only based approach may not work, and I'd suggest
to seek clarification from the SCA spec workgroup before going down that
route.
- The other comment is that this kind of validation is great... in a
tool, but I'm not sure that we need to perform all of it in the runtime,
specially if it means, read XML + combine policies + write XML back +
parse it back + Evaluate XPath on it... Do we really want to do all that
at application startup time??
Maybe we could check with the Eclipse SOA Tooling Platform project what
kind of Policy validation they're planning to do in the tooling?
Hope this helps...
Thanks
- Venkat
On 8/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Venkata Krishnan wrote:
Hi,
The PolicyFwk specs mentions that when checking out the applicability of
a
PolicySet over a binding or implementation, an xpath expression
specified in
the 'appliesTo' attribute of the PolicySet Defn, should be run against
the
parent element of the binding or implementation. Since this validation
is
done during the build phase, I am a bit lost of how I could get hold of
the
scdl fragment of the parent element of the binding or implementation.
One option I have in mind for this, is to split up the 'write' method in
the
CompositeProcessor into smaller methods such as writeComponent or
writeComponentService and so on. Then its a question of invoking one of
these methods from the build phase. But the problems I see with this
are :
-
- making the CompositeProcessor instance available to the
CompositeConfigurationBuilderImpl which could probably be done during
construction of CompositeConfigurationBuilderImpl
- the services or referneces or components that we might have at the
build
phase may not quite reflect exactly what was in the scdl as there is
quite a
bit of reconciliations and normalizations that they undergo. But for
the
current context, it should not matter much.
Thoughts ?
Thanks
- Venkat
I'm trying to to understand the issue, but I must be missing something,
could you please explain how "validating a PolicySet in the build phase"
could lead to "refactoring assembly XML write methods". We're not
writing anything when the runtime starts, so I'm a little lost...
Thanks
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
