Hi Raymond, Thanks. Please see my questions / comments inline.
- Venkat On Tue, Mar 25, 2008 at 9:01 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Please see my comments below. > > Thanks, > Raymond > -------------------------------------------------- > From: "Venkata Krishnan" <[EMAIL PROTECTED]> > Sent: Tuesday, March 25, 2008 4:20 AM > To: <tuscany-dev@ws.apache.org> > Subject: Re: Adding SPIs to handle policies, was: Re: Policy Handlers ? > > > Hi Raymond, > > > > - How do applications add policy handlers ? For example if an > > application > > is wanting to provide some other flavour of logging or authentication > how > > does it get a hook to do this ? > > Can you explain why we need application-level policy handlers? What is the > scope/visibility of these handlers? Are they global to the hosting SCA > node? > IMO, we need to contribute policy handlers via tuscany extension modules > instead of applications. I am imagining a scenario where an application would like to use its own flavour of logging or authentication mechanism. Is this a valid scenario and if so how can the application do this. Yes this handler is scoped to the node on which this application is running. > > > > > > - Also, looking at fixing > > https://issues.apache.org/jira/browse/TUSCANY-2125I am trying to keep > > the PolicyProvider mechanism as well as the > > JavaPolicyRuntimeWireProcessor thing co-existing so that we our bigbank > > demo > > going because that demo implements its own PolicyHandler for > authorization > > function. > > > > One way of doing this could be if in the JavaPolicyRuntimeWireProcessor > I > > am able to run thro all the interceptors in the invocation chain and see > > if > > it has a PolicyInteceptor that handles a particular policySet. If there > > is > > one, then I can skip adding the interceptor for this policyset. But I > > can't > > figure out a way to do this, since the PolicyInterceptor does not have a > > marker interface or a accessor method to get the PolicySet name that it > > handles. Is there a way out for this ? > > > > I don't think we should keep two machineries. Why should the java > implementation runtime be responsible for the policy handling? What if > there > is no java component? Agreed about have a single mechanism for this. I was just about trying this out for this release alone since in the bigbank I have tried to use some custom authorization and so need to have a PolicyHandler for this. I'd certainly like to move to one consistent mechanism in the trunk. > > Can you help migrate the rest of the policy handlers into the Policy > Provider SPI? If we see deficiencies, we can enhance the SPI. > > > Thanks > > > > - Venkat > > > > On Sat, Mar 8, 2008 at 1:36 AM, Raymond Feng <[EMAIL PROTECTED]> > wrote: > > > >> Hi, > >> > >> I checked in changes that integrate the core with these new SPIs and > >> converted logging and transaction policies under r634776. Can some of > you > >> look into the policy security too? > >> > >> Thanks, > >> Raymond > >> -------------------------------------------------- > >> From: "Raymond Feng" <[EMAIL PROTECTED]> > >> Sent: Thursday, March 06, 2008 10:51 PM > >> To: <tuscany-dev@ws.apache.org> > >> Subject: Adding SPIs to handle policies, was: Re: Policy Handlers ? > >> > >> > Hi, > >> > > >> > I'm adding the following SPIs to provide pluggable implementations to > >> > various policies in Tuscany. See [1]. > >> > > >> > 1) Define a PolicyProviderFactory that can be contributed to the > >> > ProviderFactoryExtensionPoint by policy extensions. This is similar > to > >> our > >> > BindingProviderFactory and ImplementationProviderFactory. > >> > > >> > 2) Define a PolicyProvider that can be created by > PolicyProviderFactory > >> > for the following policy attach points: > >> > > >> > (component, reference, binding) for reference policies > >> > (component, service, binding) for service polices > >> > (component, implementation) for implementations > >> > > >> > Please note that we leave the PolicyProviderFactory to decide if it > >> > will > >> > create a PolicyProvider based on the resolved policy sets. For some > >> > policies, even if there is no intent declared, some default behaviors > >> are > >> > desired. > >> > > >> > 3) Define a PolicyImplementor interface that can be optionally > >> implemented > >> > by Binding/Implementaiton Provider to indicate if the > >> > binding/implementation > >> > extension will handle the policies by themselves. > >> > > >> > 4) The runtime will iterate through all the policies in the resolved > >> > policySets, if a policy is NOT implemented by binding/implementation > >> > provider (not on the PolicyImplementor.getImplementedPolices() list), > >> then > >> > call PolicyProvider.createInterceptor() to add an interceptor. > >> > > >> > I also have the logging policy and transaction policy converted into > >> these > >> > new SPIs locally. I'll check them in if we agree the SPIs are the > right > >> > way to go. > >> > > >> > Thanks, > >> > Raymond > >> > > >> > [1] http://svn.apache.org/viewvc?rev=634558&view=rev > >> > > >> > -------------------------------------------------- > >> > From: "Raymond Feng" <[EMAIL PROTECTED]> > >> > Sent: Thursday, November 29, 2007 9:01 AM > >> > To: <tuscany-dev@ws.apache.org> > >> > Subject: Re: Policy Handlers ? > >> > > >> >> Hi, > >> >> > >> >> Let's take the transaction policy as an example to understand the > >> >> responsibilities of the players. > >> >> > >> >> Assuming the following intents are declared against the binding or > >> >> implementation types, what code are needed to enforce the semantics? > >> >> > >> >> Intent > >> Binding/Implementation > >> >> Type > >> >> ---------------------------------- > >> ------------------------------------- > >> >> 1. managedTransaction.global implementation.java > >> >> 2. managedTransaction.global implementation.bpel > >> >> 3. suspendsTransaction a reference or service with > >> >> binding.sca (local in-VM case) > >> >> 4. suspendsTransaction a reference with binding.ws > >> >> 5. propagatesTransaction a reference with binding.ws > >> >> 6. propagatesTransaction a service with binding.ws > >> >> > >> >> In case 1 & 2, an transaction interceptor can be added to the > >> invocation. > >> >> The interceptor interacts with the transaction manager to make sure > a > >> >> global > >> >> transaction is demarcated before the control hits the component > >> >> implementation. The interceptor can be independent of the > >> implementation > >> >> types. > >> >> > >> >> In case 3 & 4, an transaction interceptor can be added to the > >> invocation > >> >> to > >> >> suspend the current transaction before delegating to the next > invoker > >> and > >> >> resume the transaction after the control is returned. > >> >> > >> >> In case 5, the binding.ws provider will have to deal with > >> >> WS-AtomicTransaction to make sure the transaction context can be > >> >> propagated > >> >> over the SOAP protocol. > >> >> > >> >> In case 6, if there is an incoming transaction from the WS-AT, the > >> >> binding.ws provider will need to import the transaction. > >> >> > >> >> It seems that the logic that enforces the intents could be a joint > >> effort > >> >> of > >> >> a policy interceptor and the binding/implementation provider. > >> >> > >> >> Thanks, > >> >> Raymond > >> >> > >> >> ----- Original Message ----- > >> >> From: "Venkata Krishnan" <[EMAIL PROTECTED]> > >> >> To: <tuscany-dev@ws.apache.org> > >> >> Sent: Wednesday, November 28, 2007 9:05 AM > >> >> Subject: Policy Handlers ? > >> >> > >> >> > >> >>> Hi, > >> >>> > >> >>> Sebastien and Raymond, thanks for your responses on the other > >> thread... > >> >>> I > >> >>> will follow up the issues there one by one. Here I want to discuss > >> >>> about > >> >>> PolicyHandlers. > >> >>> > >> >>> Every policyset encapsulate policies that could follow a standard > >> model > >> >>> such > >> >>> as ws-policy or could follow a custom model as in the case of our > >> >>> axis2-config-param policy and jdkLogging policy. > >> >>> > >> >>> Each implementation and binding type could have its own way of > >> >>> interpretting > >> >>> these policy models and affecting them accordingly in the binding > or > >> >>> implementation. For example the axis2 binding simply injects the > >> >>> ws-policy > >> >>> into the axis configuration. Some other binding that works with > >> >>> ws-policy > >> >>> might handle this differently. > >> >>> > >> >>> This sort of 'policy handling' is what I had initially thought of > as > >> >>> something that can be dealt by PolicyHandler classes. Now I find > >> >>> that > >> >>> how > >> >>> these classes look and what they do inside it entirely upto the > >> binding > >> >>> and > >> >>> implementation types including when they are called i.e. during > start > >> or > >> >>> stop of the binding/implementatoin or during invocation of service > >> >>> methods > >> >>> etc. > >> >>> > >> >>> Given that the PolicyHandler is getting to be something internal to > >> the > >> >>> binding or implementation do we ever have to define an SPI for it ? > >> >>> I > >> >>> am > >> >>> basically questioning the current implementation of defining > >> >>> PolicyHandler > >> >>> classes in a services sort of file in META-INF directory, loading > and > >> >>> instantiating them, invoking them and so on. > >> >>> > >> >>> Is there a view-point I am missing here? > >> >>> > >> >>> Thanks > >> >>> -Venkat > >> >>> > >> >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
