You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Anto <an...@gmail.com> on 2010/07/20 14:04:59 UTC
WS-* specification for transaction
Hi,
Is there any way to use WS-* specifications related to transaction with
CXF? Both client and server should take part in the transaction.
In CXF roadmap support for these specifications are included?
Anto
--
View this message in context: http://cxf.547215.n5.nabble.com/WS-specification-for-transaction-tp1618539p1618539.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-* specification for transaction
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 20 July 2010 8:07:36 am Guy Pardon wrote:
> Hi Anto,
>
> You can try this: http://www.atomikos.com/Main/ExtremeTransactions
>
> It includes an independent WS-AT implementation (in beta) that should work
> in any JAXWS stack.
That's really interesting. Good to know about. I'd really be interested
in learning more about it. A simple search of the docs didn't reveal much of
anything, but if it's in beta, that's kind of expected.
In anycase, I'd love to hear about any experiences using it and CXF together.
Dan
>
> Best
> Guy
>
> On 20-jul-2010, at 14:04, Anto wrote:
>
>
> Hi,
>
> Is there any way to use WS-* specifications related to transaction with
> CXF? Both client and server should take part in the transaction.
>
> In CXF roadmap support for these specifications are included?
>
> Anto
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: WS-* specification for transaction
Posted by Guy Pardon <gu...@mac.com>.
Hi Anto,
You can try this: http://www.atomikos.com/Main/ExtremeTransactions
It includes an independent WS-AT implementation (in beta) that should work in any JAXWS stack.
Best
Guy
On 20-jul-2010, at 14:04, Anto wrote:
Hi,
Is there any way to use WS-* specifications related to transaction with
CXF? Both client and server should take part in the transaction.
In CXF roadmap support for these specifications are included?
Anto
--
View this message in context: http://cxf.547215.n5.nabble.com/WS-specification-for-transaction-tp1618539p1618539.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-* specification for transaction
Posted by Andrew Dinn <an...@googlemail.com>.
On 07/20/2010 08:16 PM, Daniel Kulp wrote:
> On Tuesday 20 July 2010 8:04:59 am Anto wrote:
>> Hi,
>>
>> Is there any way to use WS-* specifications related to transaction with
>> CXF? Both client and server should take part in the transaction.
>
> Not built into CXF itself right now, no. I think JBoss had started some
> work in this area as part of their transaction support, but it's completely
> tied to their transaction manager and such.
It's not being tied to the TX manager that it is the problem -- the TX
manager can be embedded in the app at little cost (it's _tiny_ and
easily embedded in any Java app). The difficulty is that at present the
WS-C, WS-AT and WS-BA implementations (n.b. the component which
implemets them is referred to as XTS) are tied to the JBossWS web
services implementation and JBossWS currently only runs inside JBoss AS.
JBossWS does come in two flavours and one of them uses CXF as the
underlying WS stack so, as long as you run inside JBoss AS you can run a
full WS-AT and WS-BA client, transactional web service and/or
coordination services on top of CXF and use all the underlying features
which are specific to CXF. The coordination services all employ JaxWS
for communications with the transactional client and with the
transactional web services so you can implement any (or all) of them in
JBoss AS/WS/CXF and interoperate with clients, services or coordinators
implemented by 3rd parties.
I have been looking at the possibility of packaging a subset of the XTS
libraries which can be used to allow WS-AT and WS-BA clients to manage
transactions and invoke transactional web services from a stand-alone
Java app. This would also require factoring out the relevant JBossWS and
underlying (WS/Native or WS/CXF stack code, Jaxb, HTTPClient etc)
libraries from the bundle that goes into the app server. This might be
tricky as far as managing versions of client libraries is concerned but
I don't think it presents problems beyond those of packaging/deployment.
It's harder to refactor things so that transactional web services can be
implemented outside of JBoss AS but that may also become an option at
some point. In theory our implementation is based on vanilla JaxWS and
should work anywhere. However, just getting our version to run over both
our own WS stack and CXF inside our AS involved fiddling with various
differences in the details of the two JaxWS implementations which the
spec does not pin down.
IN particular, the JaxWS committee failed to specify a standard way of
manipulating WSA headers and hence failed to force JaxWS implementors to
face the complexities that arise when some of the WSA options are
employed (i.e. using a ReplyTo/FaultTo endpoint rather than the HTTP
back channel to deliver replies/faults). I have resolved enough of these
issues to get XTS to run inside JBossWS on both stacks (modulo several
regressions as the JBossWS or CXF have been 'improved' :-). I have not
yet worked out how to solve these problems so that you can just deploy
our XTS code in any container/JVM which contains an arbitrary JaxWS
implementation. I'd be happy to share experience with anyone who has
tried or is trying to do the same.
>> In CXF roadmap support for these specimfications are included?
>
> WS-* stuff is always "on the roadmap", but whether they get implemented or not
> really depend on if someone steps up to do it (or if one of the companies that
> supports CXF has a paying customer that requires it). If you would like to
> contribute some work in this area, that would be great. :-)
Well, the JBoss XTS code would not be a bad place to start from in
trying to provide a version which runs on top of CXF outside of JBoss
AS. It's already a long way down that particular garden path.
regards,
Andrew Dinn
-----------
Re: WS-* specification for transaction
Posted by Guy Pardon <gu...@mac.com>.
Hi,
> Just curious, why no paying customers are not demanding it?
We (Atomikos) had support for it in JAX-RPC days and now in JAX-WS precisely because we experience demand.
> Is it that there
> are other ways to implement transactions other than WS-* specs? Or is it not
> a practical solution for transaction management?
O yes, there is a better one: http://www.atomikos.com/Publications/TryCancelConfirm
Guy
Re: WS-* specification for transaction
Posted by Andrew Dinn <an...@googlemail.com>.
On 07/21/2010 10:53 AM, Anto wrote:
> Just curious, why no paying customers are not demanding it? Is it that there
> are other ways to implement transactions other than WS-* specs? Or is it not
> a practical solution for transaction management?
JBoss has had an XTS implementation for quite a few years but it has
only been included in a supported product since early this year. Even so
we have clients who have used it in deployments from before it was
supported. IBM have also has a web service transactions implementation
based on WS-* for at least as long as JBoss and they have clients who
use it.
Part of the problem is that the WS spec leaves the web service
programmer to iplement the transactional lifecycle events such as
prepare, rollback, complete, compensate etc. This is not something a lot
of web programmers know how to do well. I suspect that has made take-up
of XTS rather slow.
One of the things we have investigated at JBoss in order to make this
simpler is transaction bridging i.e. automatically enlisting a WS-AT web
service in a subordinate JTA transaction. This allows the web service
implementor to just use XA data sources for managing web service data
and rely on it to handle the prepare/rollback of data. This is planned
for inclusion as a supported component in JBoss EAP 6 (EAP is our
product AS) but it is working with full recovery support in EAP 5 and
you can use it for free in the community AS 5/6 release.
We have also looked at ways of making it easier to implement WS-BA
clients. We presented a transaction framweork at JavaOne in 2008 which
provided automation support for handling compensation actions in WS-BA
web services which might be worth looking up.
regards,
Andrew Dinn
-----------
Re: WS-* specification for transaction
Posted by yinzara <yi...@gmail.com>.
I have to say I greatly disagree with opinions previously expressed that say
"just make you service more fine grained" so that you can do more in a
single operation.
This will not even come close to solving the problems fixed by
WS-Transaction in a real world setting.
Take this example:
I have a company that sells stuff and we maintain an inventory of the items
as I have a limited supply. My company also has a subscription service they
sell that is unrelated to the items themselves, but I still have to charge a
customer for the services.
I have a warehouse that has my supply of items and I have a system that
manages that inventory. It was a prebought system that I have the source
code for and it's written in .NET. Finally I have a system that stores my
customers accounts and does billing written in Java. This system is
utilized by other systems to bill customers for other services (such as the
subscription service). My customers use my website written in ASP.NET to
make their purchase.
So one day one of my customers decides he would like to buy something from
me. He visits my website, selects the product, enters his customer
information and clicks "Purchase".
Now my .NET web application has to contact the warehouse computer to first
check availability and remove the item from inventory. I cannot process the
payment first because if I processed the payment, then checked availability,
the item may not be available again (because someone else bought it).
Next I process the payment. If the payment is unsuccessful (mabye because
their account doesn't have any money in it or because of some other business
reason [maybe they've bought too much this month]), I want to roll back my
transaction all together. That way the inventory system has the product back
in inventory again. If you say "Well them make a call to the inventory
system to put it back", but what if the reason the payment processor failed
was because of an intermittent network issue which is still occuring, then
I'll have an item that was taken out of inventory and never put back. I'd
then have to write another process to check on inventory on some regular
basis and put unused inventory back. And if inventory is tight, then that
might prove to be costly and it's possible that the data in the system
wouldn't even differentiate these items from ones that should be removed.
Next step if the payment was successful is that I need to contact the
warehouse system to tell them to ship the item. If for some reason when I
went to contact the warehouse system, the transaction failed, I need to roll
back the payment and put the item back into inventory again. Same problem
as the previous issue. Finally I need to send an e-mail to them which I
definitely cannot do if any part of the previous transaction failed.
There is no option to "make coarser services" available as I already have
systems that need to be integrated that are all separate and the
functionality they provide can't be "inserted" into another application
(many times because it's written in a different language all together).
Since they're cross platform (some java some .NET), I have to use a platform
independent protocol such as SOAP. If all of them supported WS-Transaction
and WS-Coordinator (which IIS, Atomikos ExtremeTransactions, and JBoss AS
will support) then the system would function perfectly without the need for
additional application logic (which becomes extensive the more complex my
system becomes) and even if I did add the additional application logic, I
wouldn't get the disaster recovery I need in case of more extreme system
failures.
But yeah, let's make suggestions that violate the principals of SOA (i.e
fined grained services) because "it's easier" than doing it the right way.
Good luck making modifications to your 3000 "coarse grained services" when
you need to add a single parameter across all of them when you could have
wrote 6 fined grained services and integrated using distributed
transactions.
--
View this message in context: http://cxf.547215.n5.nabble.com/WS-specification-for-transaction-tp1618539p4366269.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-* specification for transaction
Posted by Andrew Dinn <an...@googlemail.com>.
On 07/21/2010 02:30 PM, Daniel Kulp wrote:
> In general, most people that are familiar with it generally recommend
> refactoring the services to avoid the need for the distributed transactions
> entirely (coarser grained services work well). It generally simplifies
> things quite a bit, but also helps with performance as it's really just the
> real data going across. Internally, the service uses transactions, but it's
> not really exposed outside the service. Using things like transactional
> beans or using JMS with it's transactions or even the spring transactional
> things all work quite well.
Yes, that's true for WSAT. It's not a great deal of use for integrating
services across multiple company domains because your web services can
become hostage to failures or performance lags in the ones they are
yoked too. Alternatively, if you have control of all the services then
you can usually implement them locally within one JVM/database and have
no real need to use distributed transaction coordination.
The shame is that there is no great take up of WSBA which attempts to
resolve these problems with integrating disparate web services,
providing a basis for more workflow oriented transactions. In
particular, it's relaxed isolation model allows participants to commit
early and compensate in case of failure by sluggish partner services,
thus boosting throughput. But WSBA, even more so than raw WSAT, requires
the web service programmer to manage the transaction lifecycle (cancel,
complete, close, compensate) as well as adding the need to conjure with
failure or read-only situations (exit, fail, cannotComplete). It's much
more complicated than WS-AT, especially WS-AT combined with JTA bridging
which can easily be reduced to a more simple programming model. WSBA
transactions don't easily map to JTA so you cannot easily implement WSBA
services using XA resources for the underlying data management. There's
probably a big opportunity out there for anyone who can simplify WSBA
(or equivalent protocol) enough to make it usable by non-transaction
heads while still benefiting from the ability to coordinate distributed
web services.
> In the few cases I've seen where they really needed to expose transactional
> things, most developers actually find it easier to just add methods like:
>
> TransactionId startTransaction(...);
> void commit(TransactionId ...);
> void rollback(TransactionId ...);
>
> to the service and just add the TransactionId to each method that requires the
> transaction, either as a param or soap header or something. Yes, it's not a
> full transaction API, but for simple cases, it may be enough and it would be
> completely interopable between stacks and such.
This is all very well but the key to any _real_ transaction
implementation is 'durability'. Implementing this sort of protocol so
that it can hanlde crash recovery and still guarantee atomicity,
consistency and isolation is _very_ hard. Most programmers get it wrong
many times before it is bullet-proof (speaking from experience here :-).
regards,
Andrew Dinn
-----------
Re: WS-* specification for transaction
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 21 July 2010 5:53:13 am Anto wrote:
> Daniel Kulp wrote:
> > WS-* stuff is always "on the roadmap", but whether they get implemented
> > or not
> > really depend on if someone steps up to do it (or if one of the companies
> > that
> > supports CXF has a paying customer that requires it).
>
> Just curious, why no paying customers are not demanding it? Is it that
> there are other ways to implement transactions other than WS-* specs? Or
> is it not a practical solution for transaction management?
As Andrew and Oliver kind of alluded to, the WS Transaction spec is a
relatively poorly written and specified spec. It exposes a lot of
transactional requirements to the web service client developers which, in
general, ends up not being a good idea. It's also relatively chatty causing
extra performance issues and such.
In general, most people that are familiar with it generally recommend
refactoring the services to avoid the need for the distributed transactions
entirely (coarser grained services work well). It generally simplifies
things quite a bit, but also helps with performance as it's really just the
real data going across. Internally, the service uses transactions, but it's
not really exposed outside the service. Using things like transactional
beans or using JMS with it's transactions or even the spring transactional
things all work quite well.
In the few cases I've seen where they really needed to expose transactional
things, most developers actually find it easier to just add methods like:
TransactionId startTransaction(...);
void commit(TransactionId ...);
void rollback(TransactionId ...);
to the service and just add the TransactionId to each method that requires the
transaction, either as a param or soap header or something. Yes, it's not a
full transaction API, but for simple cases, it may be enough and it would be
completely interopable between stacks and such.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
RE: WS-* specification for transaction
Posted by Oliver Wulff <ow...@progress.com>.
Hi Sergey
I only meant that service design can avoid or delay the need for WS-AtomicTransaction. WS-BA is another topic.
IMHO, from an layering/granularity point of view the service enabling layer sits between services using WS-BA (coarse grained services) and REST. REST perfect fits for fine grained CRUD operation style MEP. I would avoid the introduction of transient transaction resources (or similar pattern) to encapsulate an update of two resources in one call- of course, technically possible. If this must be done in a transactional manner, I'd go with a web service deployed in an application container which supports local transaction.
Thanks
Oliver
________________________________________
From: Sergey Beryozkin [sberyozkin@gmail.com]
Sent: 21 July 2010 13:30
To: users@cxf.apache.org
Subject: Re: WS-* specification for transaction
Hi Oliver
On Wed, Jul 21, 2010 at 12:18 PM, Oliver Wulff <ow...@progress.com> wrote:
> Hi Anto
>
> I know customers which use Web Services for about 9 years. They never had
> the requirement for WS-Transaction support because you could sort this out
> by the design of the service (WSDL) or they came to the conclusion that
> transaction support would have been a nice feature but not really required.
>
> Instead of calling for instance two operations of a service(s) (transaction
> context) you design a less fine grained service which does the work in one
> operation you wanted to seperate in two seperate operations. The webservice
> is deployed in a application runtime which supports local transactions like
> J2EE/EJB. For instance, you define the stateless session bean to create a
> new transaction for each incoming request.
>
> The above approach fits well as long as you don't combine (and tightly
> couple) different business components. In such a case, I would have some
> objections from an enterprise architecture point of view.
>
> But what about *business activities* (coordinated with the help of WS-BA or
some RESTful approach, does not matter) ? It's a higher level issue compared
to the one of creating the right service interface ?
cheers, Sergey
> Thanks
> Oliver
>
>
Re: WS-* specification for transaction
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Oliver
On Wed, Jul 21, 2010 at 12:18 PM, Oliver Wulff <ow...@progress.com> wrote:
> Hi Anto
>
> I know customers which use Web Services for about 9 years. They never had
> the requirement for WS-Transaction support because you could sort this out
> by the design of the service (WSDL) or they came to the conclusion that
> transaction support would have been a nice feature but not really required.
>
> Instead of calling for instance two operations of a service(s) (transaction
> context) you design a less fine grained service which does the work in one
> operation you wanted to seperate in two seperate operations. The webservice
> is deployed in a application runtime which supports local transactions like
> J2EE/EJB. For instance, you define the stateless session bean to create a
> new transaction for each incoming request.
>
> The above approach fits well as long as you don't combine (and tightly
> couple) different business components. In such a case, I would have some
> objections from an enterprise architecture point of view.
>
> But what about *business activities* (coordinated with the help of WS-BA or
some RESTful approach, does not matter) ? It's a higher level issue compared
to the one of creating the right service interface ?
cheers, Sergey
> Thanks
> Oliver
>
>
RE: WS-* specification for transaction
Posted by Oliver Wulff <ow...@progress.com>.
Hi Anto
I know customers which use Web Services for about 9 years. They never had the requirement for WS-Transaction support because you could sort this out by the design of the service (WSDL) or they came to the conclusion that transaction support would have been a nice feature but not really required.
Instead of calling for instance two operations of a service(s) (transaction context) you design a less fine grained service which does the work in one operation you wanted to seperate in two seperate operations. The webservice is deployed in a application runtime which supports local transactions like J2EE/EJB. For instance, you define the stateless session bean to create a new transaction for each incoming request.
The above approach fits well as long as you don't combine (and tightly couple) different business components. In such a case, I would have some objections from an enterprise architecture point of view.
Thanks
Oliver
________________________________________
From: Anto [antopaul.list@gmail.com]
Sent: 21 July 2010 11:53
To: users@cxf.apache.org
Subject: Re: WS-* specification for transaction
Daniel Kulp wrote:
>
> WS-* stuff is always "on the roadmap", but whether they get implemented or
> not
> really depend on if someone steps up to do it (or if one of the companies
> that
> supports CXF has a paying customer that requires it).
>
Just curious, why no paying customers are not demanding it? Is it that there
are other ways to implement transactions other than WS-* specs? Or is it not
a practical solution for transaction management?
Anto
--
View this message in context: http://cxf.547215.n5.nabble.com/WS-specification-for-transaction-tp1618539p1698737.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-* specification for transaction
Posted by Anto <an...@gmail.com>.
Daniel Kulp wrote:
>
> WS-* stuff is always "on the roadmap", but whether they get implemented or
> not
> really depend on if someone steps up to do it (or if one of the companies
> that
> supports CXF has a paying customer that requires it).
>
Just curious, why no paying customers are not demanding it? Is it that there
are other ways to implement transactions other than WS-* specs? Or is it not
a practical solution for transaction management?
Anto
--
View this message in context: http://cxf.547215.n5.nabble.com/WS-specification-for-transaction-tp1618539p1698737.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-* specification for transaction
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 20 July 2010 8:04:59 am Anto wrote:
> Hi,
>
> Is there any way to use WS-* specifications related to transaction with
> CXF? Both client and server should take part in the transaction.
Not built into CXF itself right now, no. I think JBoss had started some
work in this area as part of their transaction support, but it's completely
tied to their transaction manager and such.
> In CXF roadmap support for these specimfications are included?
WS-* stuff is always "on the roadmap", but whether they get implemented or not
really depend on if someone steps up to do it (or if one of the companies that
supports CXF has a paying customer that requires it). If you would like to
contribute some work in this area, that would be great. :-)
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog