See, hoarding does make sense

I wish I could read this.

JavaOne 2005

I was about to write something about this year's JavaOne, but Greg got there first. So, rather than duplicate, go and check his blog entry.

New Orleans and diving

I was hoping to go to the next face-to-face meeting of WS-CAF in New Orleans. As last year, we've made it coincident with the annual OASIS Symposium in New Orleans. Last year was my first time in the city and I loved it: great food, great music and a great atmosphere. Myself, Eric, Greg and other friends and colleagues managed to find time from the slog of standards work (none of that sniggering at the back please!) to check out some of the Jazz festival last year, so I was looking forward to going back. That and hopefully producing another Committee Draft of WS-Context, maybe the first Committee Draft of WS-CF and trying to start on WS-TXM (a lot for a 2 day meeting, I know).

Unfortunately I won't be able to go :-( For Christmas my wife enrolled me on a PADI open water diving course. I've been talking about learing to SCUBA dive for many years, going back at least to when we spent a week in the Carribbean as guests of Bluestone for being a Bluestone President's Club Aware Winner. Several friends have also qualified over the intervening years, including Jim who kept pushing me to go do it. However, as with most things that aren't work related, I always managed to find a reason to put it off. Until this year that is. I have to say that since starting the course I've had a lot of fun and wish I'd done it earlier. Unfortunately, there are exams connected with the course, both written and practical (in the ocean - we've been doing everything in the local swimming pool so far), and some of them are coincident with the New Orleans face-to-face. I tried to postpone them, but it ain't going to happen, so I'm not going to be at the meeting in person. Which leaves me looking forward to 2 days of attending the meeting via the phone!

Web Services seminar

It's been a busy few weeks for us and our friends at CodeWorks. We're putting on a Web Services seminar for local businesses to help educate them on the benefits of Web Services. Fortunately we've been able to attract some good speakers for the event, including my old friend Werner Vogels from Amazon. Now that he's the CTO of Amazon he's finding it hard to spend time with us lesser mortals ;-) but I'm definitely going to make sure he has the opportunity to sample a few good pubs while he's here!

The trouble with transactions ...

The folks over at Microsoft working on Indigo have been doing some interesting stuff with their transaction engine. I've been keeping abreast on this as much as possible for some time, so it's nice to see it coming to fruition. What's even more interesting from a personal perspective, is that the architecture they've come up with and the requirements it fulfills, is very similar to what we've been using now for many years: basically a lightweight transaction engine that can be used in situations where not all of the ACID properties are required, but which can dynamically "step up to the plate" (as one Microsoft friend described it) if the need arises.

In some previous posts I've touched on the fact that we have in house something that fits that bill: ArjunaCore. This is a transaction coordinator (plus some associated tools and development frameworks) that has a very small footprint (hey, it runs on an old HP Jornada 720 in significantly less than 32 Meg of memory!) It took us several years of design and development to come to the current architecture, that allows it to be used within every transaction-related product we currently have. Without going into too many details (read the paper), it allows us to relax some or all of the various ACID properties in a controlled manner within products and is extremely fast and agile.

Note, this is not a "one-size fits all" protocol I'm talking about here: it's purely implementation. There's an important difference and the evolution of ArjunaCore has simply reinforced that distinction in my mind. I'm in the process of writing a paper on this, so will hold off saying too much more here.

Transaction processing is a difficult technology to implement well and also to convince people that they need. Terms such as "two-phase commit" and "persistence" are ingrained into people's minds as bad things, synonymous with "poor performance" and "high overhead". When talking to people about how they can use transactions, I've often heard reasons for them not using them begin with "Well, the trouble with transactions in our view is ..." But that needn't be the case and in many situations, the lack of transactions can lead to a much higher overhead if failures occur. Again, I'm writing a paper on this subject at the moment, but may blog on some aspects of it later.

I've had the opportunity to work for the Microsoft/Indigo crowd on several occasions but the timing has never been right. So it's nice to see two independent groups coming to the same ultimate conclusion about how to bring transactions to the masses.

There are many applications out there that don't use transactions and should; likewise, there are applications using transactions that really don't need to. I've believed for a long time that there are several things that we as an industry can (and should) do to help people understand where transactions fit into their architecture: education (why are transactions important? what happens if you don't have them? etc.), ease of use, flexibility (this crosses many different aspects, but includes what can be controlled, e.g., transactions existed before XA, so you don't have to limit yourself to XA-aware participants), performance etc.

We've managed to get a lot of the implementation-side of the equation into ArjunaCore and are constantly working on the education aspect. I know other companies and organisations are starting to look at a similar approach, and in the meantime it's always nice to get some implicit validation from a company like Microsoft.

A book that changed my life

While dusting the copious books shelves we have in our house, I came across a book that really did help me through a pretty difficult time in my life. My mother has had multiple sclerosis for many years and while it's a difficult enough ailment for the sufferer to cope with, because of it's nature (few outward physical signs to start with, the ability to put symptoms down to stress, or strain etc.) it's often hard for the family and friends of the sufferer to understand what's going on. This book helped at a time when neither my mother nor the doctors could really put the why's, how's and what if's into words. I'd recommend it for anyone else in a similar situation.

Research papers made easy

In my spare time (!) I'm a visiting research fellow at Newcastle University. I've written a few papers in my time and it's rarely an easy process. However, now some nice people at MIT have come up with a paper generator. It's fun to try out. Here's one I just tried, inputing a few friends names.

The scarey thing is, I'm sure one of the random ones it produced for me looked like a paper I did write ;-)

webservices.org news

WebServices.org has a piece on our deal with webMethods.

History of Web Services development

Eric's got some good things to say on Web Services over here. Definitely worth a look.

TSS update

Just been talking to Floyd Marinescu of TSS. He'd seen our press release about the OEM deal with webMethods and has written a piece. Nice work Floyd and thanks.

Arjuna, webMethods and Casablanca

It's taken a little longer than expected, but the news is finally out: we've done a licence deal for our ATS 4.0 product with one of the most important Web Service players, webMethods. It's been fun and informative working with those guys and I'm looking forward to the next steps.

The Casablanca reference? Well "I think this is the beginning of a beautiful friendship."

HP, WS-RF and Apache

'Nuff said.

It's out

The GA of the ATS 4.0 Suite is now available for download. You may find that some features aren't enabled by default in the 30 day evaluation software, but we believe this won't affect the majority of evaluators. If it does, mail us and we're always happy to work with prospective customers to make sure your evaluation period progresses smoothly. Based on any feedback we get, we may revisit the decision to disable some features in future releases.

If you've any general questions, then please use the forum, where our engineers will respond as soon as possible.

Some historical references

This may be worth a look. Some of it is historical now. And this.

Heuristics in WebServices.org

Back here I commented on the lack of heuristic support in some Web Services transactions specifications. Well I wrote a piece for webservices.org, that's been published here.

Submit those papers

I'm on the PC for the Web Services and Formal Methods workshop. So if you've anything relevant, I'd encourage you to submit.

REST versus SOAP

An interesting discussion going on here and here. I've watched these sorts of things happen over and over again for the past few years and it just seems to me like "use the right tool for the right job". Let's not have yet another "PC versus Mac" debate, or "C++ versus Java". Google use Web Services and Amazon support both approaches. There are good reasons for that.

Pat Helland moving

Pat Helland is moving jobs to Amazon. I know Pat from various HPTS workshops. A great guy who knows his stuff and has a wonderful voice. He's going to be joining the likes of Werner to create a great SOA+reliability group. Good luck Pat.

Funny

Savas just sent me this and a follow-up link, which is probably best checked out first. I found it funny, but I'd like to know who he was broadcasting the images too ;-)

POA policies for Web Services addresses

Steve discusses one of the few major changes to WS-Addressing that the TC has made since it's inception. There's potentially some overlap with policy here and it definitely smacks of POA attributes/policies. Not sure if it's a good thing or not at the moment. Time to go away and muse over it.