New job

I mentioned that Sacha was leaving. Well I can now mention who is taking over.

Analyze your blog

According to this blog analyzer I'm a doer.

"The active and playful type. They are especially attuned to people and things around them and often full of energy, talking, joking and engaging in physical out-door activities. The Doers are happiest with action-filled work which craves their full attention and focus. They might be very impulsive and more keen on starting something new than following it through. They might have a problem with sitting still or remaining inactive for any period of time."

Sacha is leaving

If you don't know by now, Sacha is leaving JBoss. There's not a lot more I can add to what Bob has said, except that I'll miss out almost daily interactions. Sacha started as a colleague (when he, Bob and Marc persuaded me to move from Arjuna) but grew to be a good friend and I wish him and his family all the best in the future. Today begins a new chapter in his life as well as that of JBoss. Good luck Sacha!

First dive of the season

It may only have been Ellerton again, but we managed to get the first dive of the season in today. It was a bit like swimming in tea (less than 2 metres visibility) and cold (8 degrees Centigrade), but it was worth it. Everyone else there was in dry suits but we managed to struggle through in our wet suits. I just wish someone would invent a spray-on suit, because I'm sure I get more of a workout putting the darn thing on that actually swimming afterwards.

RPC is dead?

From what Steve says it certainly sounds like this year's QCon London was fun. This year Steve was talking on the history of RPC, which has some overlaps with what I was saying at QCon London last year. But Steve goes in to a lot more detail and I recommend people checking it out.

One slight caveat though: as I've said many times in the past (so many that I leave it as an exercise to the reader to find the entries in my blog) RPC isn't dead and isn't something you should ignore. (I don't think Steve thinks that either.) Look around you and you'll see examples of old and new systems based on it. Are they all wrong to do so? No, of course not. Are some of them wrong to do so? Most probably yes. I know of several small and large-scale systems that are being developed in academia (no vendor pressure there) and industry (maybe some pressure) that are being based on RPC. In all cases those guys did their homework and understand the trade-offs that they're making in using RPC.

BTW I'm not a RPC fanboy by any means. Yes, I've used them and helped develop them, but I've also used and developed other approaches too.

What I'm trying to say is that RPC has its place. But a bit like ACID transactions, it can be (and has been) easily misused. There are better approaches these days for many of the things we'd once have considered the domain of RPC. But that doesn't mean RPC can't and shouldn't be used. As with everything, such as which language to use, which database, which communication protocol etc., you need to be aware of the pros and cons. This is an education problem more than a technical problem.

I also agree with Steve around Erlang (in fact it was Steve who put me on to it a while back). A very nice language. Now if only I could find the time to get back to it.

Congratulations Barbara!

Barbara Liskov won the Turing Award! This is really good news. I met Barbara a few times, starting during my PhD days. At that point she was leading the Argus project in transactions and replication, which was relevant to my own research. Thoroughly deserved. Well done Barbara.

DOA 2009

I'm co-chairing DOA again. Check out the CfP for 2009.

HPTS 2009

HPTS is probably my favourite workshop/conference. I've been lucky enough to be able to attend every one since the 1990's and hopefully this year will be no different. The CfP is now up, so take a look.

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.

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!

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 (128.240.150.1)

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 
compilers:

        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 (128.240.150.1)

        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 
distribution.


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.

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!

Made my day

This article just made my day. Fantastic!

SOA Design Patterns released

I've been writing a book on SOA and ESB for a while with a couple of friends. It's due to be part of Thomas Erl's SOA series later this year. While writing it Thomas asked us to produce some patterns for his book on SOA. Well the finished book, SOA Design Patterns, is now out and it's well worth a read. A number of people throughout the industry have helped to contribute some of the patterns within it so this is definitely a cross-industry collaborative effort. Thomas also wants it to be a live-work in as much as new patterns can be contributed by anyone. So take a look at the book and if you see something missing consider contributing it.

Star Trek interlude

Anyone who's known me for long enough knows that I'm a Star Trek fan. (Not the variety that dresses up as Andorians or learns Klingon!) Being born in the late sixties sci-fi was fairly influential to me in one way or another, with my fondest TV memories coming from shows like Star Trek, Space 1999, Dr Who, The Six Million Dollar Man and Blakes 7.

I still say that the first couple of seasons of The Original Series were better than much of what was created in recent years. So it's with some apprehension that I look ahead to the new movie. I'm definitely not going to prejudge, but I had hoped they would retain some of the look-and-feel of the original.

On thing that has stayed with me over the past few years is a quote from Kirk to Picard from Star Trek Generations (watch the film if you want to understand the context):

"Don't let them transfer you... don't let anything take you off the bridge of that ship... Because while you're there, you can make a difference."

I've found that it applies to more than just starship captains!

Virtual conference

We're doing a virtual conference next month. I'm recording some sessions at the moment. Very strange, but I think it'll be fun to attend. Maybe this will encourage me to look into SecondLife.

SOA is dead (again?)

For the umpteenth time SOA is dead apparently. It's been shot so many times over the past year or so that you'd think it had a role in a Sam Peckinpah movie! However, maybe it's got 9 lives or you need to use a silver bullet, because each time it dies it keeps coming back.

This time it's my friend Anne who is reporting the demise of SOA. I've known Anne for many years and respect her, so unlike a few other obituaries I take note of this one. However, like Duane I have to disagree that SOA is dead. OK, the term may have been overloaded over the past few years almost to the point of being meaningless (analysts are as much at fault as anyone in the industry) but the concepts behind it are still very much alive and relevant (more so in today's economy.) Where we have lost our way is perhaps in having an agreed architectural definition for SOA: it is the 'A' after all, so surely we can agree on what that means (REST doesn't suffer this problem) as well as pushing the mantra that "SOA is not just a technology" (though given the number of people who have been saying this over the years I suspect that this is more a case of individuals simply not listening, certain vendors muddying the waters or it being lost in the noise.)

There is no global panacea for IT woes. There never has been and I doubt there ever will be one. For the most part software engineering practices evolve over time (Darwin would be proud). There are a few evolutionary dead ends on the way. I doubt we'll see any extinction-level events though (not unless they're associated with human extinction.) But these things take time (I'm sure the dinosaurs laughed at the evolutionary path that created the Coelacanth, but who's laughing now?)

We can't afford to keep jumping from one lifeboat to another just because some use cases don't match, or someone didn't quite understand that you need to think about how to use SOA before coding. The underlying requirements of loose coupling, security, federation, reliability etc. date back decades. The term SOA should have been good enough. It still is as far as I'm concerned. If it's not SOA then are we in for yet another round of acronym generation, like SOA 2.0, WOA etc? None of which really add much to help the people at the sharp end of IT problems!

I think in Anne's recent SOA obituary she is trying to indicate that the principles are fine but it's the term that needs to go. In the first case we can agree. In the second I don't think it's worth the industry wasting another 4 years to disagree on yet another acronym (if we do, I'd like to nominate XYZZY.) As I said above, for people actually using these principles and associated technologies it won't make a difference to them. (It may be good for analysts though.) So let's just stop this madness and start concentrating on where it really matters.

In this case I think it's definitely more a case of what Mark Twain once said, "The reports of my death have been greatly exaggerated".