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