XTP

Have been doing some thinking and planning around what Extreme Transaction Processing should be. Now all I need do is fine time to do something about it!

A tribute to Jim

Not a lot more I can say. He is missed by all those who knew him.

OPENflow deserves another chance

While we were dutifully working on Arjuna, Arjuna2, JavaArjuna, OTSArjuna and other things, Stuart and Santosh (amongst others) were also hard at work on OPENflow. As with many things we did back then it began life as an attempt to improve standards: this time workflow in collaboration with Nortel (and was better received by users than the competitor specification from the WfMC). Over the next few years it went much further than the original submission and became one of our product offerings. Although the research and development took a bit of a back-seat to the JTS development when we were acquired by Bluestone, it still managed to be cutting edge.

Unfortunately when we were acquired by HP they already had a workflow product (Process Manager Interactive). The decision was taken to stop OPENflow and that was essentially that. (It was also the point that HP Middleware, a predominately Java-based division, decided to mothball our C++ transaction service.) But even today OPENflow offers capabilities that modern equivalents could benefit from. Quite a few capabilities to be perfectly honest. I think it's time to revisit past decisions and re-learn forgotten techniques!

I haven't even begun to blog about B2B Objects yet, either.

Degrees of coupling

Over the past few years we've seen the distributed system industry moving to embrace loose coupling as though it's a global panacea to all of the woes of the previous decades. I've said on many occasions that coupling (loose or close) is something that cannot be taken in isolation: as with most things there's a trade-off to be made and there are degrees of coupling (no innuendos intended). I made that point again with my first presentation of 2008 and as recently as QCon, also taking that opportunity to point out again that loose coupling isn't something discovered or invented by the distributed systems community. It's a general software engineering pattern that has been used since Noah used his ZX76BC.

Now what makes me write about this again, when it's old hat? Well Jim's written a nice piece on coupling and cohesion. It's worth a read, but what prompted me to add this entry wasn't the subject itself but the fact that it references Pete Lee. As with Jim, Pete was one of my undergraduate teachers and took me through two years of software engineering. And it was this course that first brought loose coupling and cohesion (and many other things) to my attention. When I was preparing my presentation for the winter school I wanted to pull some specific references from the software engineering book we used during that undergraduate course, but it's stuck up in the loft and I was too lazy to go and find it. It's been over 20 years since I last saw it, but I'm pretty sure it was the first edition of Ian Sommeville's excellent book. Maybe time to buy the latest edition!

Winter School presentation

Back in January I make a two day presentation on the evolution of distributed systems at CUSO Winter School. The audience was a mixture of students and professors with a variety of backgrounds (most not in distributed systems research). So I had a great opportunity to start with a blank slate and try to give an historical background as well as comparing and contrasting with different approaches. The feedback during the event was great, but also the act of just sitting down and having to create the presentation helped coalesce a lot of things that I've worked through over the past 20 years.

QCon London 2008

It's a bit late, but here's a quick summary of QCon London 2008. Although I've been an InfoQ editor for a couple of years, this was my first time at a QCon and I was impressed. The presentations I saw were all packed and technically very good: there was none of the "product placement" that you tend to see more and more at conferences. Even the vendor pavilion was less of a car salesroom and more another opportunity to share technical discussions. I was impressed.

I jumped across the tracks during the days I wasn't presenting. However, on the Thursday I stayed with my track. Given what I'd heard about the same track at the last QCon, I was expecting a lot of controversy. However, this time I think the community has moved on and accepted that one size doesn't fit all, which coincidentally was the subject of my presentation. The entire day of the track went well and I thought all of the presentations came together very cohesively.

Diving at long last

It's been really difficult to find the time and the weather to go diving. With the 6 month clock ticking, we finally bit the bullet and got wet. The weather wasn't great, so we opted for Ellerton again. Although my dive computer said it was 9C certain parts of my body registered much lower! Whereas others were diving in dry suits, we were roughing it in our 5mm wet suits. We managed to get nearly an hour dive time despite the temperature. And I'm sure my hands were blue when I started!

I love diving for a number of reasons. Not least of which is the silence and ability to think about things while I'm down there. I managed to resolve a few issues I haven't been able to get to during my normal working day and a couple of new blog entries will be coming as a direct result. Now it had better not be another 6 months before my next dive!

Another blast from the past

I was in Neuchatel this week for some meetings and one of our conversations moved on to failure detection/failure suspecting: the fact that you cannot reliably detect failures until (and unless) those failures are eventually recovered from. Typical "detection" uses timeouts and if you use the wrong value you can end up in a world of pain. That's where failure suspectors come in: the idea is that if you think something has failed then you make sure everyone else agrees with you so even if you are wrong you don't end up with split-brain syndrome. This reminded me of some work I did back in the 90's around quantum mechanics and failure detectors.