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]
