IF YOU BUILD IT

... Will they Come?

July 2007

I just got back from Chicago where I attended Dr. Dobb's Architecture & Design World. The event was great. It had many interesting talks and sessions which I'll blog about in upcoming posts. (I'll also upload the slides from my sessions later this week.) One session I was really looking forward to was Ivar Jacobson's Keynote on "Next Generation Process with Essential Modeling".

Ivar, you recall, is one of the "Three Amigos" and a father of Use cases. I had the chance to attend a couple of his presentations several years ago and he had a very interesting and convincing appearances. But alas, this session was nothing like those previous events.

Ivar talked about his new methodology. The basic idea behind the essential software process is (in my opinion) correct. That is, instead of big bang prescribed processes, it is better to tailor a process from a set of practices to get something that fits the organization/project at hand. It might be a little unnerving to hear this from one of the people who brought us the RUP, but I guess it is good to see people who are constantly learning.

The problem was that while the main idea can be summed up in one line, Ivar went on to explain how cool it was that his base set of practices comes on a set of que cards that can be sorted and arranged. He also went on to explain the game board (or something to that effect) where you can lay different cards to both describe your current process as well as the bunch of practices you want to use for your future process.

If that wasn't enough, when he (briefly) showed us the cards that describe the architecture and architecture description practices, the advice/guidance there was very general. Frankly, I expected much more from someone of the stature of Ivar Jacobson.

On the upside this was only one keynote and the other sessions I listened to where great. Again I'll blog about few of them in upcoming posts. You can find out more about Ivar's Essential Unified Processhere.

Posted by Arnon Rotem-Gal-Oz at 05:01 PM  Permalink |

I'm flying to Chicago today to attend A&D World 2007.

I'll be presenting both SOA Patterns (Thursday @ 10:15) and the SPAMMED Architecture Framework (Friday @ 15:30). However there are also some really interesting people lecturing so you may want to come anyway :)

Here are just a few examples from the lectures on my listening agenda (in no particular order):

• UI Principle in API Design -- Elliotte Rusty Harold
• Creating a Domain Specific Language -- Juha-Pekka Tolvanen
• Clean Code -- Robert C. Martin
• Agile Model Driven Development -- Scott Ambler
• The Art of Telling Your Design Story -- Rebecca Wirfs-Brock

And there are many many others. So if nothing else, I am sure I'll have a lot to blog about when I'll return....
Anyway, I am looking forward to the event, see you all there (okay, okay, at least those of you who are attending).

Posted by Arnon Rotem-Gal-Oz at 06:15 AM  Permalink |

I've received email from people who asked about the commit and consensus protocols (Paxos, 3PC etc.) mentioned in the previous post. I was going to write up something, but then I ran across a very good overview by Mark McKeown which provides A brief history of Consensus, 2PC and Transaction Commit.

This short writeup provides links to the most important papers like the Fischer, Lynch, and Paterson (FLP) Impossibility of distributed consensus with one faulty process, Jim Gray (who, unfortunately, was lost at see earlier this year), and Leslie Lapmort's Consensus on Transaction Commit. In addition to Mark's post and all the papers there you may want to check out the presentation Jim and Leslie made on paxos commits.

If on the other hand, you already know all this (and a little more) then check out Werner Vogel's (Amazon's CTO) blog as there's an interesting job opening for you there.

Posted by Arnon Rotem-Gal-Oz at 06:20 PM  Permalink |

Subsequent to my previous post, I had a chance to exchange email with Mark Little , director of engineering in the JBoss division of Red Hat. Mark thinks the topic of transactions and SOA has been beaten to death already and wonder's why it needs to resurface (see his post Is anyone out there?). I don't see a problem with discussions resurfacing when new people are faced with situations others already solved (but that's a matter for another post.)

Anyway, the reasons we're here is that Mark made a few interesting observations and I think the end result is pretty interesting. I decided (with his permission) to post it here. (It is only minimally edited; no deletions, few additions (in []) and a few time shifting to make it more coherent as a single conversation)

Mark : From what I can see it's [the arguments on transaction and services -- are] the same old arguments that have gone round and round, ignoring the important fundamental issues and not doing enough background research.

Sagas are transactional -- it's just an Extended Transaction model and not an ACID transaction model. Don't get hung up on the word "transaction", which is way to overloaded in our industry to actually mean anything by itself. Plus, 2PC is a consensus protocol too; it does not impose any other aspect of ACID than the A. Even the D is optional until/unless you want to tolerate failures.

Arnon: I know this is an old argument, but that doesn't mean it isn't worthwhile

Mark: It isn't worthwhile if people aren't going to listen ;-) I've been involved in these debates so many times over the past 7 years (for Web Services transactions) and longer for extended transactions, that it gets a bit old after a while. Maybe we should create a wiki page and point people at that ;-)?

Arnon: I guess, but you should keep in mind that people who are solely in the .NET camp only got WS-AT recently with Windows Communications Foundation so you can expect the issues to resurface. By the way a wiki might not be a bad idea.

[regarding 2PC.] 2PC is a distributed consensus protocol and in principle doesn’t have to be related to ACID transaction. But I think the common view and use of it is for ensuring distributed ACID behavior. Looking back at my experience with XA and COM+ transactions it seems it does a good job at achieving this ACIDness

Mark: This is an education issue. The literature is clear on this. People who know and understand transactional protocols don't make the mistake of equating 2PC to ACID properties.

Arnon :Yes it is an educational issue. But I am not sure that it is that common knowledge. It is expected that middleware vendors who build the tools to support these protocols to understand it better. I don’t think it is that widely known outside these circles. Most of the architects I know don’t (maybe It time to look for new friends ;-).)

By the way as 2PC is not resilient to failures of the coordinator so in a highly distributed environment like SOA it might have been a better idea to go with paxos commits if at all you go down that path.

Mark:The reason WS-AT and WS-ACID chose 2PC is: interoperability. All TP monitors support it. Try getting IBM, MSFT, Oracle, BEA, etc. to change to Paxos, 3PC, flat-commit, or anything else and you'll be waiting for the heat death of the universe.

Arnon: Can’t argue with that

Mark: [also] 2PC is resilient to failures if the coordinator eventually recovers. Paxos has its own failure assumptions too: Jim never disputed this. Same as 3PC and other consensus protocols. As with *any* fault tolerance approach (transactions, recovery blocks, replication, etc) it's always probabilistic. All we're doing is making it highly unlikely that the system cannot complete, but we can never make it entirely safe. Even in the airline industry they can "only" go to a probability that failures happen .000000001 ;-)

Arnon: You are probably right that in an SOA situations the chances of not getting an ACID transaction are worse than in a controlled environment -- which actually make the situation even worse since people using WS-AT perceive it as allowing them ACID interaction (e.g. Juval's podcast).

Mark: WS-AT is *all* about ACID, in the same way WS-ACID is about ACID transactions. It is *nothing* to do with SOA though. Web Services are not purely the domain of SOA implementations!

Arnon: I totally agree that Web-services and SOA are not directly related and can each exist independently of each other. Again this is an educational issue but, SOA=Web services is a very common misconception (I guess the word "service" in web-service doesn’t help ;-) )

[in any event] I think distributed transactions in general should be used carefully period.

Mark:Absolutely. They are not a global panacea and people who push them as such do more harm than good.

Arnon: WS-AT is more problematic than regular distributed transactions as by definition in an SOA you do not know who and how many other services will participate in your transactions so you are much more likely to run into problems.

Sagas which embrace the temporal shift don't give an illusion of ACIDness and allow to focus on achieving distributed consensus while keeping all parties involved consistent. I think that it is a much better option if you need transaction-like behavior

Mark: For SOA, yes. Although Sagas are only good for a certain type of use case. That's why we've always tried to develop "live documents" that allow people to add new models when/if needed. With a couple of exceptions during the BTP days, there has always been consensus that one size does not fit all (http://www.webservices.org/weblog/mark_little/blackadder_and_the_micro_kernel_approach_to_web_services_transactions).

Web Services *anything*, whether it's WS-AT, WS-Sec, or WS-Addressing all have their non-SOA aspects because Web Services aren't developed purely with SOA in mind. If that were to happen then Web Services as a technology would lose some of their important benefits immediately.

Arnon: This whole discussion is in the context of SOA (at least from my side) -- naturally there’s a place for ACID transactions for other uses.

Regarding Sagas -- calling them "Extended transactions that are not ACID" is just semantics. My point was that they are not ACID transaction. I think most people equate transactions with ACID transactions as well (but I may be wrong)

Mark: Many people do and that again is an education problem. The term Extended Transactions (don't need to say "that are not ACID") has a well defined meaning in the R&D community. There have been many good models and implementations around Extended Transactions. They really took off in the vendor community through the Additional Structuring Mechanisms for the OTS, back in the 1990s. If you check that out you'll see that it formed the basis of WS-TX and WS-CAF. Even in Jim's original technical report he discussed relaxing all of the ACID properties in a controller manner to get more flexibility. That was the first extended transaction. In fact, ACID transactions are just one type of extended transaction. There are many many others, including nested transactions, coloured actions, epsilon transactions, sagas etc.

Unless I qualify it beforehand, I try to never use the term "transaction" in isolation because it has different meanings to different people. For example, when talking to developers working in trading infrastructures, a "transaction" isn't an ACID transaction at all. In telecos it's different again.

Posted by Arnon Rotem-Gal-Oz at 06:15 PM  Permalink |

Evan H asked a question about distributed transactions and services in the MSDN architecture forum:

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 answerd this questions back in April when I wrote a couple of posts that explained why cross-service transactions are a bad idea:Cross-service Transactions and Some More Thoughts on Cross-service Transactions.

Roger Sessions also agrees with this view (well, it seems actually, he wrote about it well before I did :) ):

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!

The reason I am bringing this issue back is that Juval Lowy (who wrote the article that triggered my first post on the subject) has recorded an Arcast with Ron Jabobs, in which he re-iterated the idea that "Transactions is categoricaly the only viable programming model" and you should strive to use it whenever you can. It seems Juval admits you sometimes need to use Sagas (which he called "long running transactions" -- you can see in my link why I think that's a wrong name). He also agrees that you can also use a transactionable transport and then only do internal transactions from each service to the transport (a pattern I call "Transactional Service"). However, at the end of the day, he still thinks you should use WS-AtomicTransactions whenever you can.

I agree that transactional programming is important. I think it is the simplest programming model (from the developer's side). I would probably never write an interaction with a database that is not transactional; I look very favorably at initiatives for in-memory ACI (no Durability) transactions such as the one Ralf talks about. Until we get to Distributed Transactions...

First, we should note that transactions are not "the only viable" option. As Martin Fowler notes Ebay seems to be doing fine without distributed transactions. Not only that, they abandoned distributed transaction and went "transactionless"because they needed one simple thing... Scalable performance .

In most COM+ scenarios you have a single server or a few internal servers where the distributed transaction happen -- and even there you should plan your transactions carefully if you want to get any kind of decent performance. In SOA scenarios the situation is more complicated as the distribution level is expected to be higher (even if you don't involve services from other companies). More distribution means longer times to complete transactions (especially if a participant can flow the transaction and extend it). It also means increasing the chances of failure (see Steve Jones series of posts on five nines for SOA). In my opinion, the more distributed components you have the more you want their interaction to be decoupled in time; i.e. the opposite of transactions.

Juval also said he doesn't buy the denial of service problem I mentioned (supporting a transaction means you allow locks - if an external party doesn't commit you retain the lock). Juval said he assumes that a solutions has both authentication and authorization so this shouldn't be an issue. For one, I have seen too many projects where security was something that was neglected or quickly patched in at the latest moment -- so I would hardly assume security. Even with security on -- you increase your attack surface.

But that's just the half of it. Even if all your service consumers have good intentions -- you still don't know anything about their code. SOA is not like the "good old days" where you owned the whole application -- this means you cannot trust their security to be ample. Also you don't know anything about their code quality. Services are likely (in the general case) to be deployed on different machines, even if they start co-located. I think that a Service boundary should be treated as a trust boundary just like a tier boundary. I strongly believe you should have reduced assumptions on what's on the other side of the service's boundary -- transactions are not reduced assumptions

SOA and distributed transactions do not go hand in hand -- it isn't just autonomy at stake here. It is a problem for performance and scalability and even security period.

To finish this post - I would also highly recommend looking at Pat Helland's paper "Life Beyond Distributed Transactions: an Apostate's Opinion" and a post he recently made called "SOA and Newton's Universe", where he explains more eloquently than I ever could why SOA is not a good fit for distributed transactions.

Posted by Arnon Rotem-Gal-Oz at 04:52 PM  Permalink |

Steve Jones has (yet another) great post called Le Tour SOA - why support services are critical, but not important.

You should go read the article. In a nutshell, Steve explains that important services are the ones that bring business values, while critical services are the supporting ones that help keep the light on for the important services to function properly.

While the post has SOA in the title, I think it is more general than just SOA, and applicable to applications or any other IT-generated components. In fact, it can also be applicable to IT itself as Nicholas Carr noted in 2003 when he published IT Doesn't Matter. Nicholas argues that IT will become akin to electricity and as such be critical for the business to continue operating, but not important. As a side note, I'd say this might be true for traditional businesses, but not for businesses where the IT is the business (such as banks, insurance companies, etc.)

But back to critical vs. important... It is important for architects to make this distinction to be able to prioritize work and not confuse business value with semblance of business value due to criticality for operations. This doesn't mean you can neglect critical tasks (after all they are critical). It is the important stuff that brings your business the competitive edge.

Posted by Arnon Rotem-Gal-Oz at 05:57 PM  Permalink |

Returning from vacation, I saw that Jeff Atwood wrote a post on "rethinking design patterns" in which Jeff criticizes the GoF design patterns book.

Jeff says:

Design patterns are a form of complexity. As with all complexity, I'd rather see developers focus on simpler solutions before going straight to a complex recipe of design patterns.

If you find yourself frequently writing a bunch of boilerplate design pattern code to deal with a "recurring design problem", that's not good engineering -- it's a sign that your language is fundamentally broke.

I agree that these can be a problem with using design patterns in general and the GoF ones in particular. I would add that using design patterns just to be able to say you've used them is wrong too (this may sound obvious, but I have seen organizations where this was encouraged).

I don't think, however, any of those problems are problems with the patterns themselves. This is not to say that the GoF book is perfect. For instance, all the patterns don't stand the test of time. The most prominent example for that is the Singleton pattern, which I hardly recommend using these days. Singletons are problematic for testing and create a tight coupling for a specific instance. There are better ways to create a mono-instance if that's what you need (I think others have posted about it in the past but I can post about it separately if needed).

Also, newer languages sometimes provide better ways to tackle some of the design patterns solutions; see, for example, the recent post by Alex Miller where he talks about an alternative for Template Method. Not all the patterns are that useful (Flyweight comes to mind as an example).

Nevertheless, the GoF book is one of the most important books in computer science. First it is a seminal work which introduced the patterns thinking into software development. Today we have literally hundreds of patterns on all subjects and technologies. I think it is a very good think since the looking at a problem from a pattern perspective gives us more depth and understanding on both the problem and the solutions vs. other ways I've seen.

Even in itself, the GoF book is great, since many of the patterns are valuable and can help us solve real problems. We just need to keep in mind that the sample implementations in the book are just that -- samples. There can be more than one way to code a pattern and still gain the benefits (these are "design" patterns not "coding" patterns). A few weeks ago, someone asked a question on the Visitor pattern in one of the forums I monitor. The guy needed to add an additional parameter to the Visit method and asked if it wasn't a violation of the pattern. I told him that there isn't such a thing as "violating a design pattern". The patterns are a means to an end -- not some coding codex we should keep. If we treat the design patterns as pieces of knowledge rather then a holy script, they can really help avoid some stupid mistakes.

Thus, at the end of the day, I still think the Gof book is required reading for any new developer. But hey, that's just my two cents :)

Posted by Arnon Rotem-Gal-Oz at 05:43 PM  Permalink |

A couple of quick observations following my events and temporal coupling post.

Events, current data, and aggregated data all have time-to-live aspects:

• Events value usually diminishes over time until the TTL reaches
.
• Current data usually have a constant value while their TTL lasts (until a new value is the current data) -- unless we are talking about version data which is a component of or a step in the direction of aggregated data.
• Aggregated data has the longest TTL, it is interesting to note that its value increases over time.

Also while the current data TTL is determined by the producer, both events and aggregated data TTLs are determined by consumers.

Okay, I know these are not not earth shattering observations, but they're still interesting.

Posted by Arnon Rotem-Gal-Oz at 08:28 AM  Permalink |