First, we should switch to Ode in the near future.
I haven't checked how it integrates with ServiceMix
transaction support yet, but the BPEL engine has been
designed to support all the needed use cases for transactions,
so we will be able to have a clean tx support using
both sync and async.
However, I don't really see why transactions should be controlled
by the BPEL process itself. Imho (but I may miss some use case,
so please correct me), you have two different use of transactions:
* the bpel process receives a transacted synchronous exchange,
so it needs to run the full bpel process in this very transaction,
enlisting other components inside the transaction
* the bpel process receives a transacted asynchronous exchange
(using jca flow): a process instance will be created when the
transaction is commited, and the bpel engine will then run the
process.
On 10/9/06, Ramon Buckland <[EMAIL PROTECTED]> wrote:
Hi Peoples,
After some comments and feedback ..
We are currently doing some research into an enhancement we need
to make to our solution on ServiceMix to support JTA transactions
through BPEL.
The BPEL spec for 1.1 and 2.0 does not really cover the concept of a
transaction other than to say that if you have a problem on an endpoint,
tell them to rollback :-)
We have been busily toying with the idea of the following type of
layout.
<scope>
<faultHandler>
<invoke ... transactionController operation="rollback-tx">
</faultHandler>
<invoke ... transactionController operation="begin-tx">
<!-- obtain txID -->
<!-- pass this txID to A and B -->
<invoke partnerLink="myPartnerA" ..>
<invoke partnerLink="myPartner" ..>
<!-- tell txController to commit for txID -->
<invoke ... transactionController operation="commit-tx">
</scope>
1. TransactioController is a component which can be invoked to
start a transaction (begin) , commit , or rollback
2. Each component that (we own) will have a "fronting" EIP
or some such other way that will intercept the "intended" messaqe
for A and inject the correct transaction in as the expected
JBI property. Then the component itself can see if it needs to
work with the TX or not.
Our concerns/point to date.
- We are currently using servicemix-bpe (mini ODE :-) which
only uses sendSync( ) for all it's invokes. This logically means
to us that we need to use SEDA due to the limitation of
transaction support and synchronous messaging.
- We will need to switch to JCA at a later stage, but this will
involve using PXE or some other BPEL engine, other than BPE.
- Just trying to get our head around the TX support in SM and
how it all pans out.
Can anyone shed any thoughts on the use of BPEL and JTA ?
How would you go about it knowing that business txn support
is not there (unless it is)
http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue53
http://www.oasis-open.org/committees/download.php/3263/BPEL.and.Business.Transaction.Management.Choreology.Submission.html
Can anyone comment on the use of PXE ?
Cheers,
Sorry if it's a bit loose on details, just trying to geta a topic
starter.
Thanks
Ramon
--
Cheers,
Guillaume Nodet
