Re: Adding SPIs to handle policies, was: Re: Policy Handlers ?
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: > 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: > >> 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. > >> >
Re: Adding SPIs to handle policies, was: Re: Policy Handlers ?
Please see my comments below. Thanks, Raymond -- From: "Venkata Krishnan" <[EMAIL PROTECTED]> Sent: Tuesday, March 25, 2008 4:20 AM To: 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. - 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? 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: 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: > 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.globalimplementation.java >> 2. managedTransaction.globalimplementation.bpel >> 3. suspendsTransaction a reference or service with >> binding.sca
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 ? - 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 ? 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: > 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: > > 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.globalimplementation.java > >> 2. managedTransaction.globalimplementation.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
Re: Adding SPIs to handle policies, was: Re: Policy Handlers ?
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: 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: 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.globalimplementation.java 2. managedTransaction.globalimplementation.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: 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 calle
