You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Steve Chamberlain <St...@amdocs.com> on 2008/04/21 13:39:11 UTC
Query: invocation-time access to reference policies
Hi,
Could someone please give me a clue about invocation-time access to the
policies resulting from Intents and/or PolicySets attached to a custom
reference binding?
For implementation policies, I observe that the runtime sets up a
PolicyHandlingInterceptor in the invoker chain, which invokes relevant
PolicyHandlers (e.g. the JaasAuthenticationPolicyHandler) before and
after. But this model does not appear to apply to policies on
references or bindings: applying the JAAS policy to a reference or
binding appears to fail. The WS binding does not seem to include
anything equivalent to the policy handler, and how the
helloworld-ws-secure sample actually implements the computed policies is
so far a mystery to me.
Any pointers would be much appreciated.
Many thanks
Steve Chamberlain
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Re: Query: invocation-time access to reference policies
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Now we have a new set of SPIs to handle policies. Please see the ML
discussions on
http://markmail.org/message/gvz6pb2phvpqx7kb?q=tuscany+policyhandlers&page=1&refer=icgy2fce45g2ioze.
Please let us know if it fits your requirements.
Thanks,
Raymond
--------------------------------------------------
From: "Steve Chamberlain" <St...@amdocs.com>
Sent: Monday, April 21, 2008 4:39 AM
To: <tu...@ws.apache.org>
Subject: Query: invocation-time access to reference policies
>
> Hi,
>
>
>
> Could someone please give me a clue about invocation-time access to the
> policies resulting from Intents and/or PolicySets attached to a custom
> reference binding?
>
>
>
> For implementation policies, I observe that the runtime sets up a
> PolicyHandlingInterceptor in the invoker chain, which invokes relevant
> PolicyHandlers (e.g. the JaasAuthenticationPolicyHandler) before and
> after. But this model does not appear to apply to policies on
> references or bindings: applying the JAAS policy to a reference or
> binding appears to fail. The WS binding does not seem to include
> anything equivalent to the policy handler, and how the
> helloworld-ws-secure sample actually implements the computed policies is
> so far a mystery to me.
>
>
>
> Any pointers would be much appreciated.
>
>
>
> Many thanks
>
> Steve Chamberlain
>
>
>
>
>
>
>
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Query: invocation-time access to reference policies
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Apr 21, 2008 at 5:18 PM, Steve Chamberlain <
Steve.Chamberlain@amdocs.com> wrote:
>
> Simon,
> In terms of your question I mean the latter - to invoke the computed
> policies from a custom BindingInvoker (if the runtime isn't going to set
> up an interceptor to do it for me).
> But I was under the impression that the
> PolicySetAttachPoint.getPolicySets() API related only to the model, and
> that the result of computation/resolution was stored somewhere else -
> hence my question.
> Are you saying that the process of policy computation actually updates
> the policy sets attached to e.g. a Binding? If so, then there is no
> problem - my binding invoker can clearly get them at invocation time.
> But I find that surprising.
>
> Thanks
> Steve
>
>
> -----Original Message-----
> From: Simon Laws [mailto:simonslaws@googlemail.com]
> Sent: 21 April 2008 16:03
> To: tuscany-user@ws.apache.org
> Subject: Re: Query: invocation-time access to reference policies
>
> Hi Steve, some comments in line
>
> Simon
>
> On Mon, Apr 21, 2008 at 12:39 PM, Steve Chamberlain <
> Steve.Chamberlain@amdocs.com> wrote:
>
> >
> > Hi,
> >
> >
> >
> > Could someone please give me a clue about invocation-time access to
> the
> > policies resulting from Intents and/or PolicySets attached to a custom
> > reference binding?
> >
>
> When you say "invocation-time" access do you mean you need to access
> this
> information from a component implementation or are you trying to get at
> it
> from a new extension implementation.
>
> If the latter then you should be able to get at the resolved policy
> information using the binding object in question, for example, the SCA
> binding is defined as follows
>
> public class SCABindingImpl implements SCABinding, Extensible,
> PolicySetAttachPoint, OptimizableBinding {
> ...
> public List<PolicySet> getPolicySets() {
> return policySets;
> }
> ...
> }
>
> Once the model has gone through the composite build phase you can get
> the
> computed policysets for a binding directly.
>
> If the former then there is currently no API to get at information in
> the
> underlying model from the component implementation.
>
>
> >
> >
> > For implementation policies, I observe that the runtime sets up a
> > PolicyHandlingInterceptor in the invoker chain, which invokes relevant
> > PolicyHandlers (e.g. the JaasAuthenticationPolicyHandler) before and
> > after. But this model does not appear to apply to policies on
> > references or bindings: applying the JAAS policy to a reference or
> > binding appears to fail. The WS binding does not seem to include
> > anything equivalent to the policy handler, and how the
> > helloworld-ws-secure sample actually implements the computed policies
> is
> > so far a mystery to me.
> >
>
> Yes, I notice that there are several models that are used for enacting
> policy depending on how the policy is implemented. It's also not clear
> in my
> mind what dictates which policies can be applied where. I'm assuming
> someone
> is going to jump in here and share that information but I'll dig into it
> too
> as I'm interested to know the ins and outs of this.
>
>
> >
> >
> > Any pointers would be much appreciated.
> >
> >
> >
> > Many thanks
> >
> > Steve Chamberlain
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement,
> > you may review at http://www.amdocs.com/email_disclaimer.asp
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Hi Steve
I think maybe I misinterpreted your question. When I read "policies
resulting from Intents and/or PolicySets", I went off and described access
to the intents and policy sets that result from the process of resolving the
intents and policy sets that are provided by the user, by default and by
inheritance from higher level composite artifacts. The result of this
process is reflected in the model. There is a further step where these are
turned into runtime artifacts which is reflected in the configuration of the
wired and various providers.
Here is a little bit more detail of my understanding of the processing steps
that intents/policies go through. It may have moved on a little since I
looked at it last but hopefully someone will point out any inaccuracies.
- initially .composite file, written by an application developer, specifies
a series of intents and/or policy sets
- the .composite file artifact, provided within a contribution, is read and
policySets and requiredIntents fields are populated in the resulting model
- during the read process any "applies-to" expressions in policy sets in the
domain (which come from definitions.xml files in either contributions or
extension jars) are added to the model objects as a new or extended
"applicablePolicySets" field.
- the composite model is "resolved".
requiredIntents, policySets and ApplicablePolicySets are resolved to
point to the model objects of the real intents and policy sets
default and inherited intents and policy sets are added
implementation policies are copied up to the component
- the composite model is "built"
the intents and policy sets on the component are flowed back down to
the lower levels of the model implementation, service, reference
- the composite is "activated"
the policy providers (see Raymond's post) are used, based on the
information now updated in the model, to generate runtime interceptors and
other runtime configuration changes
Hope this helps
Simon
RE: Query: invocation-time access to reference policies
Posted by Steve Chamberlain <St...@amdocs.com>.
Simon,
In terms of your question I mean the latter - to invoke the computed
policies from a custom BindingInvoker (if the runtime isn't going to set
up an interceptor to do it for me).
But I was under the impression that the
PolicySetAttachPoint.getPolicySets() API related only to the model, and
that the result of computation/resolution was stored somewhere else -
hence my question.
Are you saying that the process of policy computation actually updates
the policy sets attached to e.g. a Binding? If so, then there is no
problem - my binding invoker can clearly get them at invocation time.
But I find that surprising.
Thanks
Steve
-----Original Message-----
From: Simon Laws [mailto:simonslaws@googlemail.com]
Sent: 21 April 2008 16:03
To: tuscany-user@ws.apache.org
Subject: Re: Query: invocation-time access to reference policies
Hi Steve, some comments in line
Simon
On Mon, Apr 21, 2008 at 12:39 PM, Steve Chamberlain <
Steve.Chamberlain@amdocs.com> wrote:
>
> Hi,
>
>
>
> Could someone please give me a clue about invocation-time access to
the
> policies resulting from Intents and/or PolicySets attached to a custom
> reference binding?
>
When you say "invocation-time" access do you mean you need to access
this
information from a component implementation or are you trying to get at
it
from a new extension implementation.
If the latter then you should be able to get at the resolved policy
information using the binding object in question, for example, the SCA
binding is defined as follows
public class SCABindingImpl implements SCABinding, Extensible,
PolicySetAttachPoint, OptimizableBinding {
...
public List<PolicySet> getPolicySets() {
return policySets;
}
...
}
Once the model has gone through the composite build phase you can get
the
computed policysets for a binding directly.
If the former then there is currently no API to get at information in
the
underlying model from the component implementation.
>
>
> For implementation policies, I observe that the runtime sets up a
> PolicyHandlingInterceptor in the invoker chain, which invokes relevant
> PolicyHandlers (e.g. the JaasAuthenticationPolicyHandler) before and
> after. But this model does not appear to apply to policies on
> references or bindings: applying the JAAS policy to a reference or
> binding appears to fail. The WS binding does not seem to include
> anything equivalent to the policy handler, and how the
> helloworld-ws-secure sample actually implements the computed policies
is
> so far a mystery to me.
>
Yes, I notice that there are several models that are used for enacting
policy depending on how the policy is implemented. It's also not clear
in my
mind what dictates which policies can be applied where. I'm assuming
someone
is going to jump in here and share that information but I'll dig into it
too
as I'm interested to know the ins and outs of this.
>
>
> Any pointers would be much appreciated.
>
>
>
> Many thanks
>
> Steve Chamberlain
>
>
>
>
>
>
>
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Query: invocation-time access to reference policies
Posted by Simon Laws <si...@googlemail.com>.
Hi Steve, some comments in line
Simon
On Mon, Apr 21, 2008 at 12:39 PM, Steve Chamberlain <
Steve.Chamberlain@amdocs.com> wrote:
>
> Hi,
>
>
>
> Could someone please give me a clue about invocation-time access to the
> policies resulting from Intents and/or PolicySets attached to a custom
> reference binding?
>
When you say "invocation-time" access do you mean you need to access this
information from a component implementation or are you trying to get at it
from a new extension implementation.
If the latter then you should be able to get at the resolved policy
information using the binding object in question, for example, the SCA
binding is defined as follows
public class SCABindingImpl implements SCABinding, Extensible,
PolicySetAttachPoint, OptimizableBinding {
...
public List<PolicySet> getPolicySets() {
return policySets;
}
...
}
Once the model has gone through the composite build phase you can get the
computed policysets for a binding directly.
If the former then there is currently no API to get at information in the
underlying model from the component implementation.
>
>
> For implementation policies, I observe that the runtime sets up a
> PolicyHandlingInterceptor in the invoker chain, which invokes relevant
> PolicyHandlers (e.g. the JaasAuthenticationPolicyHandler) before and
> after. But this model does not appear to apply to policies on
> references or bindings: applying the JAAS policy to a reference or
> binding appears to fail. The WS binding does not seem to include
> anything equivalent to the policy handler, and how the
> helloworld-ws-secure sample actually implements the computed policies is
> so far a mystery to me.
>
Yes, I notice that there are several models that are used for enacting
policy depending on how the policy is implemented. It's also not clear in my
mind what dictates which policies can be applied where. I'm assuming someone
is going to jump in here and share that information but I'll dig into it too
as I'm interested to know the ins and outs of this.
>
>
> Any pointers would be much appreciated.
>
>
>
> Many thanks
>
> Steve Chamberlain
>
>
>
>
>
>
>
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp