You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/05/25 20:04:26 UTC
Policy conundrum
I've been playing with the Node2 impl a bit with a composite that has
policies in it and getting really confused. I've had a fun(?) day scratching
my head but I now realize that Node2 doesn't seem to run the piece of code
that executes the policy set "appliesTo" XPath expressions so that policy
sets get attached to the model in the correct way. I was going to look at
fixing it but then also realized that I don't quite understand how this
process can really work. I seems that it's set up so that...
1. CompositeDocumentProcessor.read()
Apply all policy sets to the XML model using the "appliesTo" XPATH
2. XYZ.read()
read "requires" intents
read "policSets" policy sets
3. CompositeProcesor.resolve()
Inherit specified intents from composite to component
Inherit specificed policy sets from composite to component
Inhetit applicable policy sets from composite to component
Resolve the polcy sets between the implementation and component
4. Build
Shuffle all the intents/policy sets around to complete the set for each
implementation and binding
The fly in this particular ointment is that it's not until stage 4 that some
of the model artifacts are constructed, for example, binding.sca when it's
not specified. This is far too late (or stage 1 is far too early) to pick up
any of the "appliesTo" policy sets so you just end up with parts of the
model without the correct policy configuration.
It's quite likely that I'm missing something in this process. Can someone
put me straight?
Simon
Re: Policy conundrum
Posted by Simon Laws <si...@googlemail.com>.
More comments in line...
Simon
On Mon, May 26, 2008 at 3:52 PM, Venkata Krishnan <fo...@gmail.com>
wrote:
> Hi Simon,
>
> What you state sounds a logical conclusion but am not sure if non-existence
> a policyset with appliesTo="binding.sca" implies that binding.sca cannot
> have policies defined on it.
Maybe it does, maybe it doesn't. But to specify a policy set on binding.sca
without appliesTo you would have to include a binding.sca element in the
composite files and hence this is a different question.
>
> Infact in the example that you cite I'd expect the policyset
> TestPolicySet_1_binding to be applicable to all the services of
> FirstTargetComponent. But then as per the current implementation a
> PolicySet will get to apply on a binding only if the binding type is
> specified in the PolicySet's appliesTo attribute.
>
Yes, and from your previous post, binding.sca is not valid in appliesTo.
> Maybe some specs folks should throw some light with this.
>
> - Venkat
>
>
>
>
snip...
Re: Policy conundrum
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Simon,
What you state sounds a logical conclusion but am not sure if non-existence
a policyset with appliesTo="binding.sca" implies that binding.sca cannot
have policies defined on it.
Infact in the example that you cite I'd expect the policyset
TestPolicySet_1_binding to be applicable to all the services of
FirstTargetComponent. But then as per the current implementation a
PolicySet will get to apply on a binding only if the binding type is
specified in the PolicySet's appliesTo attribute.
Maybe some specs folks should throw some light with this.
- Venkat
On Mon, May 26, 2008 at 3:45 PM, Simon Laws <si...@googlemail.com>
wrote:
> On Mon, May 26, 2008 at 9:07 AM, Venkata Krishnan <fo...@gmail.com>
> wrote:
>
> > Hi Simon,
> >
> > So, is the problem that binding.sca doesn't seem to have any intents or
> > policySets configured on it ? How about simply inheriting the bunch of
> > intents and policysets attached to the service or reference to which the
> > binding.sca instance is getting added to ? As for applicablePolicySets,
> > thats something we need not worry about for binding.sca as the spec
> states
> > that there will never be a policySet that has appliesTo="binding.sca"
> >
> > There is reason why we have to deal with inheritance where they are
> handled
> > today. We have to deal with the reuse of implementation model instances.
> >
> > Does that help ?
> >
> > - Venkat
> >
> > On Sun, May 25, 2008 at 11:34 PM, Simon Laws <si...@googlemail.com>
> > wrote:
> >
> > > I've been playing with the Node2 impl a bit with a composite that has
> > > policies in it and getting really confused. I've had a fun(?) day
> > > scratching
> > > my head but I now realize that Node2 doesn't seem to run the piece of
> > code
> > > that executes the policy set "appliesTo" XPath expressions so that
> policy
> > > sets get attached to the model in the correct way. I was going to look
> at
> > > fixing it but then also realized that I don't quite understand how this
> > > process can really work. I seems that it's set up so that...
> > >
> > > 1. CompositeDocumentProcessor.read()
> > > Apply all policy sets to the XML model using the "appliesTo" XPATH
> > > 2. XYZ.read()
> > > read "requires" intents
> > > read "policSets" policy sets
> > > 3. CompositeProcesor.resolve()
> > > Inherit specified intents from composite to component
> > > Inherit specificed policy sets from composite to component
> > > Inhetit applicable policy sets from composite to component
> > > Resolve the polcy sets between the implementation and component
> > > 4. Build
> > > Shuffle all the intents/policy sets around to complete the set for
> each
> > > implementation and binding
> > >
> > > The fly in this particular ointment is that it's not until stage 4 that
> > > some
> > > of the model artifacts are constructed, for example, binding.sca when
> > it's
> > > not specified. This is far too late (or stage 1 is far too early) to
> pick
> > > up
> > > any of the "appliesTo" policy sets so you just end up with parts of the
> > > model without the correct policy configuration.
> > >
> > > It's quite likely that I'm missing something in this process. Can
> someone
> > > put me straight?
> > >
> > > Simon
> > >
> >
>
> Thanks Venkat
>
> I hadn't noticed that the Policy Framework spec says
>
> 715 @alwaysProvides lists. There are no policySets with
> appliesTo="binding.sca".
>
> So If I have the following compoiste.
>
> <component name="FirstTargetComponent">
> <implementation.java class="policy.TargetClientImpl"/>
> </component>
>
> <component name="SecondTargetComponent">
> <implementation.java class="policy.TargetClientImpl"/>
> <service name="Target">
> <binding.ws/>
> </service>
> </component>
>
> and the policyset.
>
> <sca:policySet name="TestPolicySet_1_binding"
> provides="ip:TestIntent_1"
> appliesTo="sca:service"
> xmlns:wsp="
> http://schemas.xmlsoap.org/ws/2004/09/policy">
> <wsp:Policy />
> </sca:policySet>
>
> After the read phase, we end up with an internal model that looks like
>
> <component name="FirstTargetComponent">
> <implementation.java class="policy.TargetClientImpl"/>
> </component>
>
> <component name="SecondTargetComponent">
> <implementation.java class="policy.TargetClientImpl"/>
> <service name="Target"
> applicablePolicySets="policy:TestPolicySet_1_binding">
> <binding.ws/>
> </service>
> </component>
>
> The service that gets created on FristTargetComponent (during build?) won't
> have applicablePolicySets="policy:TestPolicySet_1_binding" and that this
> doesn't matter as the only binding it will have is binding.sca which, as
> you
> point out, is not affected by applicablePolicySets.
>
> I think reference/service matching is also OK as even if the reference was
> specific in terms of binding.sca the "appliesTo" is still not important as
> it doesn't apply to binding,sca on the client side either.
>
> Does this sound right?
>
> Simon
>
Re: Policy conundrum
Posted by Simon Laws <si...@googlemail.com>.
On Mon, May 26, 2008 at 9:07 AM, Venkata Krishnan <fo...@gmail.com>
wrote:
> Hi Simon,
>
> So, is the problem that binding.sca doesn't seem to have any intents or
> policySets configured on it ? How about simply inheriting the bunch of
> intents and policysets attached to the service or reference to which the
> binding.sca instance is getting added to ? As for applicablePolicySets,
> thats something we need not worry about for binding.sca as the spec states
> that there will never be a policySet that has appliesTo="binding.sca"
>
> There is reason why we have to deal with inheritance where they are handled
> today. We have to deal with the reuse of implementation model instances.
>
> Does that help ?
>
> - Venkat
>
> On Sun, May 25, 2008 at 11:34 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
> > I've been playing with the Node2 impl a bit with a composite that has
> > policies in it and getting really confused. I've had a fun(?) day
> > scratching
> > my head but I now realize that Node2 doesn't seem to run the piece of
> code
> > that executes the policy set "appliesTo" XPath expressions so that policy
> > sets get attached to the model in the correct way. I was going to look at
> > fixing it but then also realized that I don't quite understand how this
> > process can really work. I seems that it's set up so that...
> >
> > 1. CompositeDocumentProcessor.read()
> > Apply all policy sets to the XML model using the "appliesTo" XPATH
> > 2. XYZ.read()
> > read "requires" intents
> > read "policSets" policy sets
> > 3. CompositeProcesor.resolve()
> > Inherit specified intents from composite to component
> > Inherit specificed policy sets from composite to component
> > Inhetit applicable policy sets from composite to component
> > Resolve the polcy sets between the implementation and component
> > 4. Build
> > Shuffle all the intents/policy sets around to complete the set for each
> > implementation and binding
> >
> > The fly in this particular ointment is that it's not until stage 4 that
> > some
> > of the model artifacts are constructed, for example, binding.sca when
> it's
> > not specified. This is far too late (or stage 1 is far too early) to pick
> > up
> > any of the "appliesTo" policy sets so you just end up with parts of the
> > model without the correct policy configuration.
> >
> > It's quite likely that I'm missing something in this process. Can someone
> > put me straight?
> >
> > Simon
> >
>
Thanks Venkat
I hadn't noticed that the Policy Framework spec says
715 @alwaysProvides lists. There are no policySets with
appliesTo="binding.sca".
So If I have the following compoiste.
<component name="FirstTargetComponent">
<implementation.java class="policy.TargetClientImpl"/>
</component>
<component name="SecondTargetComponent">
<implementation.java class="policy.TargetClientImpl"/>
<service name="Target">
<binding.ws/>
</service>
</component>
and the policyset.
<sca:policySet name="TestPolicySet_1_binding"
provides="ip:TestIntent_1"
appliesTo="sca:service"
xmlns:wsp="
http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:Policy />
</sca:policySet>
After the read phase, we end up with an internal model that looks like
<component name="FirstTargetComponent">
<implementation.java class="policy.TargetClientImpl"/>
</component>
<component name="SecondTargetComponent">
<implementation.java class="policy.TargetClientImpl"/>
<service name="Target"
applicablePolicySets="policy:TestPolicySet_1_binding">
<binding.ws/>
</service>
</component>
The service that gets created on FristTargetComponent (during build?) won't
have applicablePolicySets="policy:TestPolicySet_1_binding" and that this
doesn't matter as the only binding it will have is binding.sca which, as you
point out, is not affected by applicablePolicySets.
I think reference/service matching is also OK as even if the reference was
specific in terms of binding.sca the "appliesTo" is still not important as
it doesn't apply to binding,sca on the client side either.
Does this sound right?
Simon
Re: Policy conundrum
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Simon,
So, is the problem that binding.sca doesn't seem to have any intents or
policySets configured on it ? How about simply inheriting the bunch of
intents and policysets attached to the service or reference to which the
binding.sca instance is getting added to ? As for applicablePolicySets,
thats something we need not worry about for binding.sca as the spec states
that there will never be a policySet that has appliesTo="binding.sca"
There is reason why we have to deal with inheritance where they are handled
today. We have to deal with the reuse of implementation model instances.
Does that help ?
- Venkat
On Sun, May 25, 2008 at 11:34 PM, Simon Laws <si...@googlemail.com>
wrote:
> I've been playing with the Node2 impl a bit with a composite that has
> policies in it and getting really confused. I've had a fun(?) day
> scratching
> my head but I now realize that Node2 doesn't seem to run the piece of code
> that executes the policy set "appliesTo" XPath expressions so that policy
> sets get attached to the model in the correct way. I was going to look at
> fixing it but then also realized that I don't quite understand how this
> process can really work. I seems that it's set up so that...
>
> 1. CompositeDocumentProcessor.read()
> Apply all policy sets to the XML model using the "appliesTo" XPATH
> 2. XYZ.read()
> read "requires" intents
> read "policSets" policy sets
> 3. CompositeProcesor.resolve()
> Inherit specified intents from composite to component
> Inherit specificed policy sets from composite to component
> Inhetit applicable policy sets from composite to component
> Resolve the polcy sets between the implementation and component
> 4. Build
> Shuffle all the intents/policy sets around to complete the set for each
> implementation and binding
>
> The fly in this particular ointment is that it's not until stage 4 that
> some
> of the model artifacts are constructed, for example, binding.sca when it's
> not specified. This is far too late (or stage 1 is far too early) to pick
> up
> any of the "appliesTo" policy sets so you just end up with parts of the
> model without the correct policy configuration.
>
> It's quite likely that I'm missing something in this process. Can someone
> put me straight?
>
> Simon
>