locked
Distributed Transactions and Services RRS feed

  • Question

  • Are distributed transactions (ie.. WS-Transaction) a violation of the "Autonomous" tenant of service orientation?   Yes or No and Why?  Kudos if you can address concurrency and scalability (in an enterprise with multiple interacting services).

     

    I have a very strong opinion on this, let's see if any of you lurking architects take the bait.. ;-)

    Tuesday, July 10, 2007 1:15 PM

Answers

  • When the WS-Transaction specification was first proposed, back in 2002, I wrote an article explaining why I thought the idea of allowing true transactions to span services was a bad idea. I published the article in The ObjectWatch Newsletter, #41: http://www.objectwatch.com/newsletters/issue_41.htm. Nothing since then has changed my mind. Atomic transactions require holding locks, and spanning transactions across services requires allowing a foreign, untrusted service to determine how long you will hold your very precious database locks. Bad idea. Just because IBM and Microsoft agreed on something doesn't make it good!

     

    Best wishes,

    Roger Sessions (MVP - Architecture)

     

     

    Tuesday, July 10, 2007 4:53 PM
  • I think it is a very bad idea to have cross-service transaction esp. if you also flow transactions.
    I wrote about it here after reading Juval's article...
    If you need transaction-like behavior between services you should either rethink your service boundaries or use better approaches like the Saga pattern

    Arnon
    Tuesday, July 10, 2007 6:25 PM
  • I read this discussion with a lot of interest, from my experience and implementation the use of transactions across the service boundary is a bad idea and leads to tight coupling of services with to much internal knowledge of said services, when you start to throw SLAs into the mix it can become very convoluted.

     

    In the past I have designed services around the idea of a 2 phase commit process that incorporates some SLAs parameters, i.e. an ordering service (internally & externally use) that allows a service customer to place an order but requires the service customer to commit the order in a specified time period (SLA), if the time period elapsed then the uncommitted order would be purged from the system (end of day) by a maintenance schedule.

    If an order was to be cancelled (non committed or committed) this was viewed as a single (binary) operation that did not require a commit stage.

     

    Just my 2 pence worth...

     

    Ollie Riches

     

    Wednesday, July 11, 2007 10:44 AM
  • Hi;

     

    Transactions are required to be short to minimize the duration of holding locks on transactional resources. Holding locks is expensive. Best practices of transactions tell us to make them short, optimized and independent from user control.

     

    Now,  will you make a transaction using WS-AT between your head office in NY and branch in South Africa and they both use dial-up connection or low speed ADSL!!! Will you make transaction at all or go for some compensation scenario?

     

    WS-AT is useful to apply transactions between systems where connectivity is reliable and fast. Imagine distributing your software components over multiple servers and manage transaction between these components over 100MB network. Does this make sense? Does it scale your appication? does it allow you to run part of your application on Apache Server and coordinate with WS in IIS?!!!

     

    I had similar discussion here, there are number of parameters that tells you which technology or standard to use in implementing transactions. I'm sure that there's no 100% winner solution all the line (Not even WS-AT nor optimized COM+ transactions), you need to pick the right one .

     

    All standards and technologies can be argued in the same way and can simply be pointed as useless. Just identify the context in which you can make the best out of them.

    Wednesday, July 11, 2007 1:42 PM
  • Congratulations - your post has been selected for an ARCast.TV Rapid Response!



    To listen to Architect MVP Juval Löwy and Ron Jacobs address your question click here


    Hope this helps,

    Ron Jacobs

    Wednesday, July 11, 2007 5:54 PM
  • I have a lot of respect for Juval - but I think Juval is dead wrong thinking that ACID transactions between services is a good option. He can probably pull this off on a closed system - but when the services in that system evolve and/or inter-connect with "the world" (other services) it will ultimately fail.

    Anyway, I blogged about this in more detail here
    Friday, July 13, 2007 8:51 PM
  • "I think Juval is dead wrong thinking that ACID transactions between services is a good option. He can probably pull this off on a closed system - but..."

    Well, that's pretty much what he said - sometimes you can pull this off, and when you can, you should.  Often you can't, in which case you shouldn't. <s>

    I do think the notion of the trusted partner got a bit muddled in the interview.  To implement cross-service transactions, it is certainly necessary that all the services be trusted, but it is not at all sufficient.  The service must be also be capable of responding within, say, a second or so.

    Leo






    Tuesday, July 17, 2007 3:47 AM

All replies

  • (double double bonus points if someone can get Juval Lowy on the phone for his opinion..lol)
    Tuesday, July 10, 2007 1:29 PM
  • Just to throw some more wood on the fire, would the monitoring and enforcement of SLA metrics change your answer in regard to distributed transactions?  Specifically in regards to latency and throughput..
    Tuesday, July 10, 2007 3:23 PM
  • When the WS-Transaction specification was first proposed, back in 2002, I wrote an article explaining why I thought the idea of allowing true transactions to span services was a bad idea. I published the article in The ObjectWatch Newsletter, #41: http://www.objectwatch.com/newsletters/issue_41.htm. Nothing since then has changed my mind. Atomic transactions require holding locks, and spanning transactions across services requires allowing a foreign, untrusted service to determine how long you will hold your very precious database locks. Bad idea. Just because IBM and Microsoft agreed on something doesn't make it good!

     

    Best wishes,

    Roger Sessions (MVP - Architecture)

     

     

    Tuesday, July 10, 2007 4:53 PM
  • I think it is a very bad idea to have cross-service transaction esp. if you also flow transactions.
    I wrote about it here after reading Juval's article...
    If you need transaction-like behavior between services you should either rethink your service boundaries or use better approaches like the Saga pattern

    Arnon
    Tuesday, July 10, 2007 6:25 PM
  • I read this discussion with a lot of interest, from my experience and implementation the use of transactions across the service boundary is a bad idea and leads to tight coupling of services with to much internal knowledge of said services, when you start to throw SLAs into the mix it can become very convoluted.

     

    In the past I have designed services around the idea of a 2 phase commit process that incorporates some SLAs parameters, i.e. an ordering service (internally & externally use) that allows a service customer to place an order but requires the service customer to commit the order in a specified time period (SLA), if the time period elapsed then the uncommitted order would be purged from the system (end of day) by a maintenance schedule.

    If an order was to be cancelled (non committed or committed) this was viewed as a single (binary) operation that did not require a commit stage.

     

    Just my 2 pence worth...

     

    Ollie Riches

     

    Wednesday, July 11, 2007 10:44 AM
  • Hi;

     

    Transactions are required to be short to minimize the duration of holding locks on transactional resources. Holding locks is expensive. Best practices of transactions tell us to make them short, optimized and independent from user control.

     

    Now,  will you make a transaction using WS-AT between your head office in NY and branch in South Africa and they both use dial-up connection or low speed ADSL!!! Will you make transaction at all or go for some compensation scenario?

     

    WS-AT is useful to apply transactions between systems where connectivity is reliable and fast. Imagine distributing your software components over multiple servers and manage transaction between these components over 100MB network. Does this make sense? Does it scale your appication? does it allow you to run part of your application on Apache Server and coordinate with WS in IIS?!!!

     

    I had similar discussion here, there are number of parameters that tells you which technology or standard to use in implementing transactions. I'm sure that there's no 100% winner solution all the line (Not even WS-AT nor optimized COM+ transactions), you need to pick the right one .

     

    All standards and technologies can be argued in the same way and can simply be pointed as useless. Just identify the context in which you can make the best out of them.

    Wednesday, July 11, 2007 1:42 PM
  • This is all really good stuff.. I don't disagree with anything said so far.

     

    Does anyone else have an opinion on this?  I'm going to do a writeup on my blog on this in the next couple of days.

     

    I promise to spread the "Answer" juice liberally.. ;-)

    Wednesday, July 11, 2007 4:30 PM
  • Congratulations - your post has been selected for an ARCast.TV Rapid Response!



    To listen to Architect MVP Juval Löwy and Ron Jacobs address your question click here


    Hope this helps,

    Ron Jacobs

    Wednesday, July 11, 2007 5:54 PM
  • Wednesday, July 11, 2007 6:19 PM
  • Sorry - fixed the link
    Wednesday, July 11, 2007 7:54 PM
  • I have a lot of respect for Juval - but I think Juval is dead wrong thinking that ACID transactions between services is a good option. He can probably pull this off on a closed system - but when the services in that system evolve and/or inter-connect with "the world" (other services) it will ultimately fail.

    Anyway, I blogged about this in more detail here
    Friday, July 13, 2007 8:51 PM
  • "I think Juval is dead wrong thinking that ACID transactions between services is a good option. He can probably pull this off on a closed system - but..."

    Well, that's pretty much what he said - sometimes you can pull this off, and when you can, you should.  Often you can't, in which case you shouldn't. <s>

    I do think the notion of the trusted partner got a bit muddled in the interview.  To implement cross-service transactions, it is certainly necessary that all the services be trusted, but it is not at all sufficient.  The service must be also be capable of responding within, say, a second or so.

    Leo






    Tuesday, July 17, 2007 3:47 AM
  •  LeoTohill wrote:
    "I think Juval is dead wrong thinking that ACID transactions between services is a good option. He can probably pull this off on a closed system - but..."

    Well, that's pretty much what he said - sometimes you can pull this off, and when you can, you should. Often you can't, in which case you shouldn't. <s>

    Not exactly - Juval said you should try to use transactions as much as you can - I say you shoudl rarely consider them

    Also what I am saying is that even if you can pull it off for a short while it will ultimately fail
    When I decide to use distributed transaction I plan this carefully and test throughly
    in an SOA you cannot plan who will use your service or how many services will be involved in the transaction

    Arnon
    Tuesday, July 17, 2007 4:43 AM