The audio recordings from InfoWorld's SOA Executive Forum unfortunately weren't good enough to use on ITConversations, but I've been piecing together some excerpts. The first one, on debugging SOA, is here. In today's 13-minute podcast, four experts -- Microsoft's John Shewchuk, Cape Clear's Annrai O'Toole, Oracle's Edwin Khodabakchian, and Mindreef's Tim Ewald -- debate the always perplexing issue of synchronous versus asynchronous communication models.
My conclusion, which is that synchrony and asynchrony are networking's version of the wave/particle duality in physics, was reinforced by Jim Gray, whose appeareance on MSDN's Channel 9 I finally transferred to MP31 and listened to on a bike ride recently. Here's the part that stuck in my head:
Anybody who's written asynchronous code knows that the first question you ask yourself is, how could I avoid writing this code. Now, we live in a disconnected world, an occasionally connected world, you have to have queued programming, you have to have asynchrony, but you can program asynchrony as though it's synchronous, and in fact that's what I try to do. One of the early things I did was to work on locking and concurrency control, and developed the theory of serializability, and I got a Turing Award for figuring that stuff out, and...there are theorems there, and if you challenged me right now I could probably state them and probably prove them, but most people couldn't. The whole thing about that theory is that if you do this, it's as though there's no concurrency. Almost everybody operates above that theory and just counts on the SQL guys to make all the concurrency go away. You say Begin Transaction, you party on the data, you say Commit, and you don't have to worry about somebody changing the data underneath you. That's not concurrent.
The whole business about asynchrony, what makes it complicated is the following, and it's not obvious that this is what makes it complicated but I think it's what makes it complicated, is that in a sequential program you think of a state machine, and you're in this state and then this state, and the number of states you can be in is n. Now you have two computers that are operating asynchronously, they each have n states, the problem is that the state space of the pair is n times n. The combinatorics is what drives you crazy. It makes testing really tough. It just makes conceptualization hard. So in fact the way people deal with it is to make it sequential. They put in locks, and say you do this and then I'll do this, and they cut that state space down to something they can get their head around.
Given that we're driving toward loosely-coupled services in software layer, and commodity clusters in hardware, this question of how to blend asynchrony with synchrony becomes paramount.
1 The mplayer solution I mentioned here works for both RealAudio and Windows Media. I subsequently got a tip about this free utility which works nicely to extract MP3 audio from Windows Media Video.
Former URL: http://weblog.infoworld.com/udell/2005/08/31.html#a1292