Hi,
Taking WS-Policy and WS-AtomicTransaction into consideration, I expect we
define policy sets in WS-Policy illustrated below:
<sca:policySet name="TransactedPolicySet1"
provides="sca:propagatesTransaction" ...>
<wsp:Policy xmlns:wsp="http://www.w3.org/ns/ws-policy"; >
<wsat:ATAssertion
xmlns:wsat="http://docs.oasis-open.org/ws-tx/wsat/2006/06/";>
</wsp:Policy>
</sca:policySet>
A policy assertion that specifies that an Atomic Transaction coordination
context MUST be flowed inside a requester's message. From the perspective of
the requester, the target service that processes the transaction MUST behave
as if it had participated in the transaction. For application messages that
use a SOAP binding, the Atomic Transaction coordination context MUST flow as
a SOAP header in the message.
Since WS-AtomicTransaction 1.1 [1], wsat:ATAssertion is the only assertion
defined. It seems that WS-AT only cares if the TX context is flowed inside
the WS message. I'm not sure how we define the policySets for the
implementation intents such as sca:managedTransaction.global.
[1] http://docs.oasis-open.org/ws-tx/wsat/2006/06
Thanks,
Raymond
--------------------------------------------------
From: "Raymond Feng" <[email protected]>
Sent: Thursday, January 21, 2010 2:56 PM
To: <[email protected]>
Subject: Re: Copying policy from 1.x to 2.x
Hi,
I was the one who wrote the prototype using Geronimo Transaction Manager.
I'll check out the 2.x code to refresh my memory. The brief idea was the
following:
1) There are transaction intents to control the TX for both interaction
and implementation. The interaction ones denote whether the TX context
should be propagated or suspended. The implementation one controls if a
Global TX, a local TX, or no TX should be demarcated for the component
implementation.
2) The intents are provided by a set of policySets which contains the TX
policies.
3) The policies are binding-specific, for example, binding.ws probably
uses WS-Atomic Transaction while others may use JTA.
4) Tuscany registers provider factories for the TX policies. The provider
either inserts an interceptor to enforce the TX behavior by delegating to
the TM APIs.
5) Binding Provider (or interceptor added to the binding invocation chain)
is responsible for interacting with the underlying protocol to propagate
TX context, such as WS-Atomic SOAP header or CORBA TX.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Thursday, January 21, 2010 1:50 PM
To: "tuscany-dev" <[email protected]>
Subject: Copying policy from 1.x to 2.x
I just checked in a lightly touched version of policy transaction from
1.x. It's another policy to consider as we fill in the gaps in the
policy support. I realize this wasn't 100% complete in 1.x. Not sure
who did this work originally but would be useful to have a quick run
through of the design. In particular there's an interesting
relationship between the original intents, the "Actions" and then the
transaction intents within the module. Be interested to understand
more about that.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
