ArchiteCloud 2010

I have the pleasure of bring on the ArchiteCloud 2010 program committee. If you've any papers hiding in your "to do" lists then get them in, as this promises to be a great event! Maybe I can use this as an excuse to visit Australia next year too!

Santa is an architect

It's drawing near to that time of the year again when thoughts turn to snow, presents, turkeys and all things festive. So it was that I was watching a program on TV yesterday where Santa was the main character and my 7 year old and I began to discuss the ways in which Santa manages to get presents to all of the good little girls and boys around the globe in a single night. Of course we covered all of the usual ideas, such as time dilation, wormholes and even time travel. My son thought that magic was the solution, but I pointed out that these days what with global warming and the fact that it's been shown that continual use of magic harms the environment, it's doubtful. Let's also not forget that magic reindeers produce a lot of CO2 as well as other effluent.

So where does that leave us (apart from with a rapidly disillusioned child)? The answer was obvious: although in the past he's probably used a combination of all of the above techniques (have to placate child), today he's taken a software architecture course and figured out that federation works well and scales. He has millions (billions?) of proxies in each country who do his work for them. He sends them information about what needs getting (in advance of course) and relies on them to buy the presents and distribute them locally. Those proxies may themselves have proxies in a recursive manner. Yes we all know it's the elves who build and distributed the toys to the shops, but it's the masses of proxies that get the delivery work done. And of course these helpers are parents, grand-parents etc.

So next time the question arises you'll know the answer: Santa is a coordinator and we're all interposed coordinators in the grand scheme of things ;-)

In-memory durability and HPTS

Back in the 1980's when I was writing the proposal for my PhD work I was looking at various uses for replication (at that point strong consistency protocols). There are a number of reasons for replicating data or an object, including high-availability, fault tolerance through design diversity and improving application performance. For the latter this could include reading data from a physically closer replica, or one that resides on a faster machine available through a faster network path.

But in terms of how replication and transactions could play well together it was using replicas as "fast backing store" aka a highly available in-memory log that seemed the logical thing to concentrate on. We certainly had success in this approach, but the general idea of replication for in-memory durability didn't really seem to take off within the industry until relatively recently. I think one of the important reasons for this is that improvements in network speeds and faster processors have continued to outstrip disk performance, making these kinds of optimization less academic and more mainstream. So it was with a lot of interest that I listened to presentation after presentation at this year's HPTS about this approach. Of course there were presentations on improving disk speeds and using flash drives as a second-level cache too, so it was a good workshop all round.

A great tribute to Jim

Congratulations to Tony, Savas and everyone else involved. This is a great tribute to both the person and scientist that is Jim Gray.

Interesting discussion on SOA Manifesto

I mentioned earlier that I'm on a group collaborating to create a SOA Manifesto along with Steve. Well as part of the effort to inform the public and solicit feedback I produced something for InfoQ. The result of that is a very useful discussion on the comments to that article, which I encourage anyone interested in the SOA Manifesto to check out. Unfortunately I was in Boston last week in meetings so didn't have much chance to participate in the discussion, but as Steve points out, we'll certainly take it to the working group. Thanks to everyone who participated!

SOA Manifesto Working Group

As a member of this working group I can only really second what Steve has to say on the subject.

SOA transactions and reservations

Arnon and I have spoken about SOA transactions in the past, so it was interesting to read his latest article (book chapter?)

It's a nice paper to read, though I disagree with several things he has to say. For instance, I don't like the term "semi-state" or that somehow the use of compensations increases the service's contract footprint. Furthermore compensations (not just Sagas) don't have to use locks. As we kept saying during BTP development, that's a back-end service implementation choice that doesn't have to be exposed to users.

The reservation pattern is important and it's something that's been described several times before, particularly in the area of specific implementation approaches such as BTP, WS-TX and WS-CAF. So although I haven't seen Arnon's book, I can appreciate why he's including this chapter and I liked the discussions on possible risks when using the pattern. However, it would be good to see the aforementioned approaches referenced, particularly since there's a discussion about how you could do this with EJB3.

But the one thing (the elephant in the room) that is glossed over in the discussion (which isn't if you read about the reservation approach elsewhere) is that there's something in the environment directing the flow of interactions across many services. If it looks like a coordinator, behaves like a coordinator and smells like a coordinator then chances are it's a coordinator.