On Mon, Apr 21, 2008 at 5:18 PM, Steve Chamberlain <
[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> 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 <
> [EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
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

Reply via email to