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: <[email protected]>
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: <[email protected]>
> 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: <[email protected]>
>> 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]
