Web Services and Transactions
This article sucks on so many different levels, I don’t feel like pointing them out in detail. The short version is: Mentioning XA in an SOA context is a dumb idea, and I consider WSIF to be fundamentally flawed.
This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.
This article sucks on so many different levels, I don’t feel like pointing them out in detail. The short version is: Mentioning XA in an SOA context is a dumb idea, and I consider WSIF to be fundamentally flawed.
Hello Stefan, Can you please elaborate a little bit more on why you believe WSIF is flawed Thanks
I believe the whole idea suggests that whether you use RMI/IIOP, HTTP, JMS or any other means of communication is just a low-level communication detail. I don’t think it is, and I think that standardizing on the programming language API level as opposed to the transport/communication level is a bad idea.
I agree - it sucks. I have never spoken with this lady who seems to have been listening to my presentation with less than her full attention.
I did mention XA in the context that in an SOA each component (executable) needs to be responsible for it’s unit of work so that it becomes an atomic unit. I stand by that because I need to co-ordinate MQ and local databases for each component of the service to make it easier to recover from failure. This was stated in an MQ context because many customers fail to realise that they issue MQGET, SQL Update, SQL Commit and then fail. The MQGET gets rolled back unless you have XA co-ordination enabled. The restart then processes the message again - voilla - a duplicate.
I apologize for the article.