You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Venkata Krishnan <fo...@gmail.com> on 2007/08/17 08:49:08 UTC
Validating PolicySet attachments in SCA Artifacts.
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
Re: Validating PolicySet attachments in SCA Artifacts.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I just realized that passing CompositeProcessor to the Builder is not
possible since that results in a circular dependency. Maybe we could
consider moving the 'write' functions to an appropriate 'Util' class.
Also, I might need the xpath evaluate method in the PropertyUtil class of
the assembly module. This method is private now. I am intending it to
relax this to make it visible within package.
- Venkat
On 8/17/07, Venkata Krishnan <fo...@gmail.com> 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
>
Re: Validating PolicySet attachments in SCA Artifacts.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Mike / Sebastien,
I am reviving this discussion.
As far as validation is concerned, the specs mentions about errors to be
flagged if a policyset happens to be attached directly to an element to
which it does not apply. I am perceiving this a having to 'validate' the
SCDL - am I missing a view here ?
To clarify a bit on the validation that exists presently, I do not attempt
this validation against every element in the SCDL. I just do it for
implementation and binding elements alone since they are the ones to which
policies eventually apply. Virutally this come to simply verifying if
intents and policysets directly attached to a binding or implementation
element apply to the element in question and would like to flag errors if
they don't apply. For all others that have been inherited from ancestors, I
discard if they don't apply and aggregate it over the implementation or
binding if they do apply.
So there is still this bit of validation to be done and am yet to figure out
a clean way to do this from the CompostieBuilder since at that point I don't
have access to the SCDL fragments against which I should be running the
xpath specified in 'appliesTo'
Thoughts ?
Thanks
- Venkat
On 8/20/07, Mike Edwards <mi...@gmail.com> wrote:
>
> Folks,
>
> Jean-Sebastien Delfino wrote:
> >
> > 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.
> >
>
> Nope, the spec intention is only to "validate" against the SCDL -
> nothing else is involved.
>
> Really "validation" isn't what's going on here. Those @appliesTo
> attributes are used to say what kind of element the PolicySet is
> designed for. It is really simply a way of rejecting PolicySets not
> designed for the element you're processing.
>
> The example involving @impl="axis" is actually a poor one. It assumes
> that <binding.ws.../> is extended with an attribute @impl, which then
> has some range of values which reflect the available implementations of
> binding.ws - "axis" being one of them. But this attribute would have
> to be in the SCDL, for sure.
>
> What you do have to know is that when you are processing some element
> that can have intents / policySets applied, then both those on the
> element AND those in ancestor elements form a set which you have to scan
> in order to pick out the right one(s). So, you look upwards from the
> current place and pick out those that apply. XPath is used since not
> only the element itself can control whether to use the PolicySet, but
> also its attributes.
>
> The process is not so simple, I would certainly agree, but validation is
> not the issue - it's a "simple" case of selection that is going on here.
>
> Now, if I can help with more specific points of the algorithm, I'm happy
> to try to deal with them in other emails....
>
>
> Yours, Mike.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Validating PolicySet attachments in SCA Artifacts.
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
Jean-Sebastien Delfino wrote:
>
> 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.
>
Nope, the spec intention is only to "validate" against the SCDL -
nothing else is involved.
Really "validation" isn't what's going on here. Those @appliesTo
attributes are used to say what kind of element the PolicySet is
designed for. It is really simply a way of rejecting PolicySets not
designed for the element you're processing.
The example involving @impl="axis" is actually a poor one. It assumes
that <binding.ws.../> is extended with an attribute @impl, which then
has some range of values which reflect the available implementations of
binding.ws - "axis" being one of them. But this attribute would have
to be in the SCDL, for sure.
What you do have to know is that when you are processing some element
that can have intents / policySets applied, then both those on the
element AND those in ancestor elements form a set which you have to scan
in order to pick out the right one(s). So, you look upwards from the
current place and pick out those that apply. XPath is used since not
only the element itself can control whether to use the PolicySet, but
also its attributes.
The process is not so simple, I would certainly agree, but validation is
not the issue - it's a "simple" case of selection that is going on here.
Now, if I can help with more specific points of the algorithm, I'm happy
to try to deal with them in other emails....
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Validating PolicySet attachments in SCA Artifacts.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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
appliesTo=”binding.ws[@impl=’axis’]”.
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>>
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Validating PolicySet attachments in SCA Artifacts.
Posted by Venkata Krishnan <fo...@gmail.com>.
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.
Thanks
- Venkat
On 8/17/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Validating PolicySet attachments in SCA Artifacts.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org