We've been working a lot on updating the REST transactions work for Bill's REST-* initiative. The latest drafts aren't up there at the moment but are accessible through the mail archives. The current draft 3 of the atomic model is still called REST-ACID due to some WS-ACID history, but the next draft will see a name change to REST-Atomic Transaction to more clearly call out what the model defines. Then of course there's the compensation based model that will see a new draft going up soon.
On a slight side note it's good to see others thinking about the same problem. Though I think this model has some issues it's good that others have recognized that the problem remains undefined within REST. Of course Eric and Phil wrote about some of this in their updated book (worth a read).
Thursday, January 7, 2010
Tuesday, January 5, 2010
Someone at IBM needs to do their homework!
I have a lot of respect for IBM, with many good friends and colleagues who work there, or have worked there over the years. I've collaborated with them for a long time on various transaction standards, articles and books. They know a thing or two about transactions, being the home of CICS.
However, sometimes they slip up as do we all. Case in point is this quality article (yes, I'm being sarcastic) from some anonymous author(s) over there in IBM Land. It's a good example of FUD and a really bad example of scientific investigation. I'm not going to help them improve their act on getting those two things to work together, but I will point out a few areas that quickly made me consign the document to the trash.
For a start, making statements like "JBoss AS has a relatively new integration with a third-party transaction manager." and "Public forums seem to indicate that this transaction manager is not proven" could easily be fixed by just reading the community pages. But then I get the impression that the author(s) didn't go near the community pages much except to find "facts" to fit their aims, carefully ignoring anything that didn't fit (not good scientific method!)
Then they concentrate on a specific AS issue which is about configuring AS to automatically recover datasources. Manual editing of files is required at the moment. The author(s) didn't do their homework (or even bother posting on the free forums as far as I can tell) to locate the information they needed. Now maybe they're relatively new to open source and didn't realise you don't have to buy a support contract or buy the software in order to talk with the developers! Maybe even reading the documentation might have helped, although perhaps there was just far too much of it for the author(s).
But does this mean that there are fundamental problems with JBossAS or JBossTS around data integrity? Not that we're aware of and there are enough QA tests and samples to justify that position. The code for any tests that would suggest otherwise is conveniently absent from the author(s) document. If anyone has it or something similar then be a good community member and send it our way. Of course there may be things we've missed (even CICS has issues to this day). Until then I suggest doing your bit for the environment and not waste paper, ink or energy on this article. Your Carbon Footprint will thank you.
However, sometimes they slip up as do we all. Case in point is this quality article (yes, I'm being sarcastic) from some anonymous author(s) over there in IBM Land. It's a good example of FUD and a really bad example of scientific investigation. I'm not going to help them improve their act on getting those two things to work together, but I will point out a few areas that quickly made me consign the document to the trash.
For a start, making statements like "JBoss AS has a relatively new integration with a third-party transaction manager." and "Public forums seem to indicate that this transaction manager is not proven" could easily be fixed by just reading the community pages. But then I get the impression that the author(s) didn't go near the community pages much except to find "facts" to fit their aims, carefully ignoring anything that didn't fit (not good scientific method!)
Then they concentrate on a specific AS issue which is about configuring AS to automatically recover datasources. Manual editing of files is required at the moment. The author(s) didn't do their homework (or even bother posting on the free forums as far as I can tell) to locate the information they needed. Now maybe they're relatively new to open source and didn't realise you don't have to buy a support contract or buy the software in order to talk with the developers! Maybe even reading the documentation might have helped, although perhaps there was just far too much of it for the author(s).
But does this mean that there are fundamental problems with JBossAS or JBossTS around data integrity? Not that we're aware of and there are enough QA tests and samples to justify that position. The code for any tests that would suggest otherwise is conveniently absent from the author(s) document. If anyone has it or something similar then be a good community member and send it our way. Of course there may be things we've missed (even CICS has issues to this day). Until then I suggest doing your bit for the environment and not waste paper, ink or energy on this article. Your Carbon Footprint will thank you.
Subscribe to:
Posts (Atom)