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]
