Tuesday, February 10, 2009

The ultimate Christmas dinner

OK it's a little late but then I didn't realise this video was online! I watched it for the first time over Christmas 2007 and then again last year. Heston Blumenthal has quickly become a favourite to watch and someday I hope to be able to get to his restaurant. Until then I'll sit and watch in awe!

Zakim paper

I've been using Zakim for a few years through various W3C standards committees. Nice paper.

Wednesday, February 04, 2009

Arjuna and the OTS

A couple of comments on my last reminiscence post got me thinking again. One of the things we use to go on about a lot in the early days of the company was the influence we'd had on standards and particularly the Object Transaction Service from the OMG. If you ever compare the two you'll see that by the time the OTS started Graeme, who co-created the Arjuna project (upon which he also got his PhD), was working for Transarc and involved in the standards definition. I remember visiting him in Pittsburgh a few times during that period and hearing a few horror stories about this brain-dead approach being pushed by vendor X and that dumb idea from vendor Y. But I'm sure it was all fun; it was definitely influential on the industry and me personally. When I came to start pushing the OTS in the OMG I did understand what Graeme had been on about with standards processes!

Tuesday, February 03, 2009

OMG where did the time go?

While writing the previous entry concerning building transactional applications I came across that HP paper by Nigel Edwards. That sent shivers down my spine because I can recall Nigel sharing the office with Stuart and I for months while he got to grips with Arjuna. We were both still doing our PhDs and also in the throws of making the first code release of Arjuna to the world. Here's the announcement for Release 2 (it would appear that our first release predates the web!):

Arjuna (Distr Prog System)

What: Release 2 of Arjuna Distributed Programming System
From: arjuna@newcastle.ac.uk (Arjuna Project)
Date: Mon, 17 May 1993 12:37:34 GMT

We are pleased to announce the availability of a new version
of Arjuna: a programming system for reliable distributed computing,
and the Arjuna mailing list.

The software and the manual for the Arjuna system can be
obtained by anonymous ftp: arjuna.ncl.ac.uk (

Arjuna System

This beta release of ArjunaPR2.0 fixes all known bugs present
in ArjunaPR1.2B that have been reported to us or that we have found,
and contains only minimal information about how to use the new features
provided. This release should be compilable with the following

AT&T Cfront Release 2.1, on SunOS 4.1.x,
(using Sun supplied lex and yacc).
AT&T Cfront Release 3.0.1, on SunOS 4.1.x and Solaris 2.1,
(using Sun supplied lex and yacc).
GCC versions 2.1, 2.2.2, on SunOS 4.1.x,
(using flex(v2.3.x) and bison).
Patched GCC version 2.3.3 on SunOS 4.1.x and Solaris 2.1,
(using flex(v2.3.x) and bison).
Sun C++ 2.1, on SunOs 4.1.x,
(using Sun's lex++ and yacc++).
HP C++ (B2402 A.02.34), HP-UX 8.07,
(using HP supplied lex and yacc or lex++ and yacc++).

The major new features are:

- Faster object store.
- Support for replicated objects.
- Memory resident object store.
- Support for ANSAware (not available via ftp)

Arjuna supports nested atomic actions (atomic transactions) for
controlling operations on objects (instances of C++ classes), which can
potentially be persistent. Arjuna has been implemented in C++ to run on
stock platforms (Unix on SUNs, HPs etc). The software available
includes a C++ stub generator which hides much of the details of
client-server based programming, plus a system programmer's manual
containing details of how to install Arjuna and use it to build
fault-tolerant distributed applications. The software and the manual
can be obtained by anonymous ftp: arjuna.ncl.ac.uk (

Several enhancements and ports on various distributed
computing platforms are in progress. We would be pleased to hear from
researchers and teachers interested in using Arjuna. The programmer's
manual contains the e-mail addresses for sending your comments and
problem reports.

ANSAware version of Arjuna

The ANSAware version of Arjuna is available from:

Architecture Projects Management Limited
Poseidon House
Castle Park Phone +44 223 323010
Cambridge Fax +44 223 359779
CB3 0RD Internet apm@ansa.co.uk
United Kingdom UUCP ...uknet!ansa!apm

Arjuna Mailing List

To enable us to help people using Arjuna, an electronic mail list has
been setup. You can join the Arjuna mailing list by sending an e-mail
message to "mailbase@mailbase.ac.uk" containing:

join arjuna

For example : join arjuna John Smith

Mail messages can then be sent to "arjuna@mailbase.ac.uk", for

Arjuna Project Team
The Department of Computing Science,
The University,
Newcastle upon Tyne.
NE1 7RU, UK.

The work we did with Nigel still seems so fresh in my mind and yet it is so long ago.

Then I also remembered the work on Stabilis that some of our Brazilian PhD students did a few years later. We'd always talked about how the programming model we had in Arjuna was good for building complex applications (and Nigel's work agreed with that), but it took us all by surprise when they presented Stabilis: here was the largest and most complex system (a full relational database) built entirely on Arjuna! This was an impressive demonstration of what was possible with what we'd spent the last 6 years working on.

Definitely a time to reminisce!

Transactions and AIT/TOJ

Jonathan pointed me to a recent discussion on TSS concerning writing transactional resources for non-transactional objects. It expanded into the more general topic of how to write XAResources, which it topical at the moment within Red Hat. Anyway it got me thinking that many of these requests aren't necessarily for "How do I write an XAResource?" but more for "How do I make my data transactional?" These are two different questions: the former infers the latter, but the latter doesn't infer the former. Yes believe it or not but transactions existed before XA came on the scene.

So it got me thinking and I realised that what many of them they really want is something akin to what we did in the original Arjuna system. It didn't have a name back then, since it was the whole reason for doing the Arjuna research, but eventually it became known as Arjuna Integrated Transactions (AIT), or Transactional Objects for Java (TOJ). The use of "it" has not been pushed much (at all) over the past few years, which is a shame because I still think it's a great model. So it may be time to dust it off and bring it back into the light.

Sunday, February 01, 2009

Sock and Anti-Sock Pairs

Back when I was hard at work doing my Physics undergraduate degree (a quarter of a century ago!) I remember a few of us finding creative ways to spend the time during the 4 hour practical sessions we had twice a week. Well there are only so many times you can do Millikan's experiment or kill a cat in an enclosed box with a stray beta particle. (OK that last one is something we planned but never quite did for obvious reasons and it still scores high on the "what if?" discussions at reunions.) So what we often did was end up spending hours reading New Scientist.

The one article that has stuck in my mind for that length of time was a brief description of why you end up with odd socks in the wash and usually a piece of fluff. From what I can recall, it talked about spontaneous creation of anti-socks and sock/anti-sock annihilation. To us physics students it appealed on at least two levels: the obvious physics analogies concerning matter and anti-matter, but also the fact that for most of us this was the first time we'd been away from home and having to worry about doing our own washing, much of which was full of fluff and stray socks that we were sure weren't our own! Many times over the years I wish I'd kept that article. I had hoped that the wonder of the digital age would help, but this is the closest I've found.

DOA Program Committee and Topics

I'm chairing DOA 2009 and my co-chairs (Jean-Jacques Dubray and Fabio Panzieri) and I have been finalizing the program committee. Fortunately most of last year's PC have agreed to stay on so we've only had to add a couple of new people. Next step is to figure out the Call for Papers. If you've any thoughts on things you'd like to see at DOA 2009 that maybe weren't covered in the DOA 2008 CfP, let me know. After that we'll have to determine the invited speakers and keynotes. Fun fun fun!