One way is to use SOAP/JMS where transactions should work. If you
combine this with a JTA transaction you should be able to get real
transactional behaviour.
One problem with http is that you do not even have guaranteed delivery.
For example you might send a request, then the connection breaks and
still the call will
do it´s effect. A very important best practice here is to use idempotent
service contracts. So you can retry the call and it will only be
executed once. For example you can create a unique id before the call.
So if the call fails to return a result but has an effect on the server
you can retry and the second call can be ignored by the server.
If rollbacks need to be done only very seldomly you can do them
manually. You just log the failure for a human to correct the problem.
This sounds weird for us developers but is quite common in business.
Christian
Am 06.02.2012 21:30, schrieb rouble:
CXF Gurus, and Users,
How are developers implementing SOAP web services that are
transactional. For instance, if I have a bank web service that does:
api call: debit savings $10
api call: credit checkings $10
I need to be able to begin a transaction before the api calls, and
commit it after. If either one of the apis fails, I need to be able to
rollback.
I understand there are standards such WS-AtomicTransaction,
WS-Coordination and such. But how are people implementing these kinds
of functions in the absence of those standards being implemented in
CXF?
Obviously, one way would be to re-write the above api calls as one api call:
api call: transfter savings checkings $10
But that is not always an option depending on the API.
tia,
rouble
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
