Video game character

I tried What Video Game Character Are You? and here's the result:

I am a Gauntlet Adventurer. I strive to improve my living conditions by hoarding gold, food, and sometimes keys and potions. I love adventure, fighting, and particularly winning - especially when there's a prize at stake. I occasionally get lost inside buildings and can't find the exit. I need food badly.

Not sure I'd agree with all of that - I can't remember the last time I got lost inside a building ;-)

Grid BOF at JavaOne

I'm here at JavaOne sitting on a panel for a BOF on the Grid; Building Tomorrow's Grid. Well that was last night (9:30pm, but it was surprisingly well attended, with standing room only) and I think it went very well. There was a lot of audience participation and it definitely seemed like there was a lot of interest in grid (small 'g') computing. Overall the panel pretty much agreed with one another; the main exception was when it came to the subject of Java's role in the grid (small 'g' again): the panel split down the middle, with Richard Nicholson and Dan Hushon saying the JINI is the way forward, whilst Greg and I disagreeing. As Greg pointed out, it's unrealistic to assume that the world will be purely Java, and the bridging/wrapping approach to embedding non-Java services into Jini seems like a hack if the real answer is to simply use the right tool (aka language) for the right job.

During our individual presentations at the start of the session, we were asked to answer the following questions and I think my answers were similar to those of the rest of the panel:

(i) What is grid computing? I made the distinction between grid (small 'g') and Grid/GRID computing. I think grid has been around for many years and people simply haven't collected all of these massively parallel and distributed applications under a single categorisation. Take a look at SETI@home for example. I remember installing this when it first came out back in the early 1990's. The statistics for it today are astonishing: 3 million computers, 14 Teraflops average, 500000 years of processing power in 18 months - the equivalent of several supercomputers. It's got to be one of the most successful grids around. GRID on the other hand, is IMO an effort to try to standardise on practices, patterns and infrastructure in building grids: a great idea when you consider the number of grid toolkits that are around.

(ii) What problem does it solve? Pretty simple - not many organisations can afford supercomputers, but there are a lot of massively parallel applications out there and many computers that simply aren't used most of the time. (One member of the audience came up to me afterwards and said that his company is thinking about building a grid to use the power of 14000 machines that they've got, which are idle 40% of the time.) Using someone elses resources to do your work seems like a good idea - it's cost effective for a start!

(iii) Where is it on the hype scale? grid (small 'g') has been around for many years and most certainly isn't hype. Compared to that, GRID is more hype than reality but that's just a timing thing.

Overall I think it was a great BOF and I was pleasantly surprised to see how many people turned out. Now it's off for a book signing and definitely some session tracks.

SOAP: slow or fast?

There's an interesting discussion going on here between Michi and Jim about the performance of SOAP. I wasn't going to get involved in what could easily become a "PC verus Mac, Unix versus Windows" debate, but I'll add my 2 cents worth.

I agree with them both, to a point.

I'm sure ICE is fast (I too haven't used it). I do know that CORBA implementations these days are very fast too and message service implementations (for example) like AMS are built for speed. When I started out doing my PhD back in the mid 1980's, my first task was to help write and improve Rajdoot, one of the first RPC mechanisms around. Even then, when a fast network was 10 mbps (if you were lucky) and we used Whitechapels or Sun 360's, we could regularly get round trips on 5ms for messages up to 1K in size (packet fragmentation/re-assembly happens above this, so this was the maximum critical packet size). Not fast by today's standards, but fast back then. Having been working with SOAP and Web Services for 5 years now, I know it's slow compared to what we had in 1986, so it simply doesn't compare to what's possible these days. So, I agree with Michi's point that on that (yes, we have tried compression over the years too, and got the same results as Michi - it works, but you've got to use it carefully.)

However, and this is where I also agree with Jim, SOAP performance can be improved. The sorts of things that go on under the covers today in terms of XML parsing, for example, are pretty inefficient. Next time you want to see, just pop up something like OptimizeIt and watch what happens. I'm pretty confident that developers can and will improve on this. As an analogy, back when IONA released the first version of Orbix it was the market leader but its performance was terrible compared to later revisions. (Opcodes were shipped as strings, for a start!) I'm not singling out IONA - this is a pattern that many other ORB providers followed. So, I agree with Jim: SOAP doesn't have to be this slow - it can be improved.

But this is where I stop agreeing and come back to the fact that it's beginning to sound like the "PC verus Mac, Unix versus Windows" debates of old. You're not comparing like with like.

This is definitely a case of using the right tool for the right job, combined with some unfortunate commercial realities. If you want interoperablity with other vendors (eventually pretty much any other vendor on the planet), then you'd go the SOAP route: there is no logical argument to the contrary. CORBA didn't get mass adoption, DCE failed before it, and despite Microsoft's power, so did DCOM. Eric has some interesting things to say on the subject here, but the reason SOAP works well is because of XML, HTTP (IMO) and pretty much universal adoption. I can't see that changing. In the forseeable future, I can't see the likes of Microsoft, IBM, Oracle, BEA etc. agreeing on a single protocol and infrastructure as they have with SOAP. To be honest, I think they were forced into the current situation because of the mass take-up of the original Web: they like vendor lock-in and had managed to maintain it for decades prior to Tim's arrival on the scene.

But you pay a heavy price for this kind of interoperability. There are inherent performance problems in SOAP that I just can't see going away. We may be able to chip at the surface and perhaps even make bit dents, but fundamentally I'm confident that SOAP performance versus something like ICE (or CORBA) will always be a one-sided contest. However, a contest of interoperability will be just as one-sided, with SOAP winning. From the moment I got into Web Services, I've said that I can't see it (and SOAP) replacing distributed environments like CORBA everywhere. It frustrates me at times when I see clients trying to do just that though and then complaining that the results aren't fast enough! If I want to go off-road, I'll buy a Land Rover; but if I want speed, give me a Ferrari any day! Distributed systems such as CORBA have been heavily optimised over the years and use binary encodings as much as possible - with the resultant impact on interoperability and performance. But that is fine. That's what they're intended for. Certainly if I was interested in high performance, I wouldn't be looking at SOAP or Web Services, but at CORBA (or something similar).

So in summary: of course there will be performance improvements for the SOAP infrastructure. There may even be a slow evolution to a pure binary, extremely efficient distributed invocation mechanism that looks similar to those systems that have gone before. But it's not strictly necessary and I don't see it happening as a priority. Use SOAP for interoperability. It lowers the integration barrier. But if you are really interested in performance and/or can impose a single solution on your corporate infrastructure, you may be better off looking elsewhere, to something like CORBA, or maybe even ICE.

Savas on the move

It's official now: Savas is on the move to Microsoft and Don Box's team. Savas and I have talked about his moving from Paul's group for quite a while, so it's fair to say that it's not a surprise. I'm doubly happy for him and sad - where do I find a coffee buddy now!

Savas and I have known each other for many years as friends and colleagues: while at HP, he was in my transactions team and was a star! I'm absolutely sure that Savas will make the most of this opportunity, and it's a good move for him and Microsoft. Though I still think the other job was just as good Savas ;-)

Anyway, good luck my friend and at the very least we'll be able to catch up at HPTS.

EPR rules of engagement

William, an ex-HP colleague, has some interesting things to say about EPRs and how people tackle them. I'm broadly in agreement with what he has to say; he even references our paper, which is nice. Unfortunately there are a couple of places where he's wrong:

(i) on the implication that WS-Coordination is the same as WS-Context. However, I think Greg has responded to that here (though since his blog seems down I can't check).

(ii) on the implication that this formal objection we've raised is somehow against EPRs and ReferenceParameters. It isn't (though that's not to say I don't believe the latter is inherently wrong, but that is a completely different issue). As I say here this is about keeping EPRs symmetrical. To summarise, the current state of affairs is that EPRs are encapsulated entities until you need to use them, and in what case their constituent elements (e.g., the endpoint URI, ReferenceParameters etc.) appear as first-class elements in the SOAP header). As the objection describes, this can lead to a number of problems and we believe it's worth fixing now rather than try to retro-fit something later.

Hopefully given the pitfalls that William's original blog entry describes, he'll agree that this change we're after only makes things better.

HPTS 2005

I submitted 3 papers to this year's High Performance Transaction Systems workshop and have been invited to attend. The bi-annual HPTS workshop is probably my favourite workshop/conference, so I'm pleased to be accepted for the fifth successive time. The papers aren't up on the web site yet, but in summary:

(i) a paper on WS-CAF that I co-authored with Eric and Greg.

(ii) a paper on ArjunaCore that I co-authored with Santosh.

(iii) a paper on the different conceptual models of Web Services transactions: does the one-size fits all approach really work and if not, why not.

Once the papers are on some web site, I'll update the blog.

A musical interlude

At last year's WS-CAF f2f in New Orleans, Eric started to tell me about Professor Longhair and even gave me a few tracks to listen to. Wonderful music and it brings back good memories of New Orleans.

End of the Grid TX road?

There's been an effort going on at the GGF for a while now into transaction management for Grid applications. The initial idea was to clearly define the requirements space for transactions in Grid (are they different from Web Services, for example), then to take an objective look at efforts that have been going on elsewhere (e.g., Web Services) and finally to say whether or not those efforts are suitable. Ultimately, if the existing work wasn't deemed suitable for Grid transactions, the group would define a/some new transaction protocol(s); I think this last bit was always potentially the work on something that would come after us, rather than for this group.

Well, we're finally coming to the end of the road on this phase of the work. It looks like in the next few weeks we'll have a good report on everything up to, and including, recommendations for any future effort in this space by the GGF. It doesn't look like we'll be defining any new protocol(s) afterall, but if the GGF decide that some are needed after reading the report, hopefully it will be useful input to the next phase.

Chapter in MIT book on SOC

About 2 years ago I wrote a paper for a special issue of the CACM on Web Services and transactions. A little later, I was asked by the guest editors to write an extended version for an MIT Press book on service-oriented computing. It's taken a little longer than the editors or I expected, but finally it looks like the book is coming to fruition. I got some good feedback on the chapter (which tried to cover all of the efforts in this space in an objective manner) a few weeks ago and now need to finalise the work by the end of the month.

One thing this did bring to mind is precisely how long I've been working in this area (and transactions in general). Not sure if that's a good thing or a bad thing.

XTECH 2005

I did a day trip to XTECH 2005, where I was presenting on WS-CAF. A very long, but interesting day.

I wasn't presenting until later in the day, so Edd asked me to chair one of the earlier sessions of the day. The presentations I chaired were "Adoption of UBL in Denmark - business cases and experiences" and "Implementing Web Services for Healthcare - Lessons & Pitfalls", which were both very interesting for similar reasons. Firstly, they both talked about the use of ebXML in the public sector (ebXML is a big effort, so if you want to know which aspects of it they're using, I'd encourage you to read the papers), and secondly, the key to their success was pretty much the same: legislation! In one case, any Netherlands company wanting to send invoices to the government has to do it electronically and were given 8 weeks to implement the necessary support within their organisation. I forget the actual figures at the moment, but the government did a "time and motion" study of invoicing and reckoned they could say $100 million annually by doing this. And it all seems to be working!

They were both extremely interesting presentations and the audience asked some good questions that helped to pull more information from the presenters. Overall, I think this time I probably found the chairing experience more interesting than presenting!

WWW2006 update

We're in the process of finalising the PC for the XML & Web Services track of WWW2006. It's shaping up to be a good PC and I hope the quality of papers we get is good too. So, get your thinking hats on and start to write. Although the CFP hasn't gone out yet, and we'll be accepting papers on a wide range of XML & Web Service related topics, this year I'd like to see some papers on fault tolerance and reliability. That topic tends to get overlooked a lot in the early days of any distributed architecture "wave", but I think we're reaching the crest of this wave and things need to change.

Asymmetrical WS-Addressing

I have to admit that I like symmetry for a number of reasons. Nature prefers symmetry in a wide range of areas and it shows up all around us. So, symmetry is good. I know it's not a hard-and-fast rule, but we've followed nature before and I reckon it still has a lot to teach us. And more pragmatically, symmetry just makes sense. To paraphrase Occam's Razor: the simplest solution is probably the right one. So, why make things more complex than they need to be?

So how does this relate to WS-Addressing? Well ever since I started to use it when the Web Services Coordination and Transaction specifications, I've been annoyed by the fact that not everything is a WS-Addr End Point Reference (EPR). Basically in WS-Addr, an EPR is a delivery address for your message and contains the URI of the service as well as other information needed to ultimately deliver that message.

When sending a message, you can define wsa:ReplyTo, wsa:FaultTo and wsa:From all as EPRs. But the actual destination address isn't an EPR! Or more accurately, it's a broken apart EPR: as a receiver, you may have got it in a wsa:ReplyTo, but if you then want to us it to send a response, you have to do some work with it first.

For example, here's a valid wsa header for an input message:

<S:Header>
  <wsa:MessageID>http://example.com/someuniquestring
    </wsa:MessageID>
    <wsa:ReplyTo>
    <wsa:Address>http://example.com/business/client1
    </wsa:Address>
    <wsa:ReferenceParameters>
        <foo:dest objid=urn:1234:5678/>
    </wsa:ReferenceParameters>
    </wsa:ReplyTo>
    <wsa:To S:mustUnderstand="1">
        mailto:fabrikam@example.com</wsa:To>
    <wsa:Action>http://example.com/fabrikam/mail/Delete
    </wsa:Action>
  </S:Header>

Now in a symmetrical world, I should simply be able to take the wsa:ReplyTo EPR and put it (renamed as wsa:To of course) into the SOAP header of the response message like so:

<S:Header>
    <wsa:To>
    <wsa:Address>http://example.com/business/client1
    </wsa:Address>
    <wsa:ReferenceParameters>
        <foo:dest objid=urn:1234:5678/>
    </wsa:ReferenceParameters>
    </wsa:To>
  </S:Header>

But no, I can't do that. I have to take everything out of the wsa:ReplyTo and essentially promote the contents to the root, like so:

<S:Header>
    <wsa:To>
    <wsa:Address>http://example.com/business/client1
    </wsa:Address>
    </wsa:To>
    <foo:dest objid=urn:1234:5678/>
  </S:Header>

And as you can see, it's not actually as simple as that - I've got to break apart the ReferenceParameters (which could be arbitrary in size). Why can't I just use the EPR I received as an EPR? It can't be because of deficiencies in the SOAP processing model and I don't see how it adds anything to the architecture/model (if anything it detracts from it).

In short: It does not make sense!

java.net blog

I've had a blog on java.net for a while, but have found very little time to put something together for a first post. A conversation I had with Greg the other day around the importance of WS-RX and WS-Context got me thinking and I thought I'd write something about WS-Context for the readers of java.net.

Some more history

Just a couple of links to some things of historial interest to other ex-HP/Bluestoners out there.

Why transactions are often under used

Back here I mentioned that on many occasions I've come across companies and products that could/should be using transactions when they're not. Obviously the inverse is also the case: the use of transactions when they're simply not needed can leave people with a bad experience and hence averse to looking to transactions in the future, when perhaps they should. So, the reasons for people not using or considering transactions when they are in fact useful can be broken down into two broad categories:

(i) overhead: it's true that you can never get something for nothing. But as we showed here with regard to principles, and I mentioned here with regard to our specific implementation, it doesn't have to be the case that you have to pay dearly (in terms of overhead and cash) to get the guarantees transactions offer. There's always a trade-off to be considered in pretty much any additional functionality you may want to add to an application, whether it's transactions for reliability/consistency, replication for availability/performance, security etc. Rather than think about what negative impact this functionality is going to have on your system, you need to consider what the impact will be on not having it. Now with the likes of security and replication it's fairly evident what benefits they bring most of the time. With transactions it's always a little more difficult, because most of the time you don't see the benefit: it's typically only when a failure happens. Now it is true that failures are not common, but they do happen - network failures, disk failures, memory failures etc. But in that case you should think of transactions like an insurance policy: how often do you claim on your home, car or travel insurance? Probably not that often. But most people will still renew their policies year after year, even when some (e.g., holiday insurance) aren't mandatory. Why? Because you don't want to take the risk and in simple terms the cost of insurance is significantly less than the cost of whatever it is that you're insuring. I'd like to see a time when transactions are seen to be so cheap that they're just part of the infrastructure that people take for granted. I think with something like ArjunaCore and the transaction implementation in Indigo that's starting to look possible.

(ii) education: in some ways this follows on from the above discussion, where people (architects, engineers etc.) either have a bad previous experience of transactions or have heard rumours. However, there are at least a couple of other sides to this: first, people (biz-dev as well as engineers) simply not knowing that transactions exist (computer science is a large field, so it's not always the case that everyone knows about every one of its facets). More worrying though is the second aspect, which I've seen a few times - vendors of products that really could (and should) benefit from transactions not using them because they either don't understand the reasons why they need them (education again) or they don't want the perceived overhead in their products and are willing to take the risk (on behalf of all of their customers) that failures won't ever happen; and they may do it "silently". It's this last point that always annoys me and not simply because I've been working with transactions for a long time: if you go back to the insurance analogy, it's the equivalent of you buying insurance but the insurance company simply pockets the money and if/when you come to make a claim they feign ignorance, leaving you up the proverbial creek without a paddle. By the time you know there's a problem, it's already too late!

I think that there's a lot that we as a transaction industry can do to help this, through education, evangelising and improved product functionality/performance. But I also think there's a lot that the user can do, for instance by considering what the effects of failures might be in certain scenarios and, particularly in the case of 3rd party products/components where you might have been told failures "are handled", drill down into the "hows" and "whys" rather than just taking it for granted. You don't buy insurance from just anyone; you use trusted parties, such as banks, where trust is built up and the products assured and backed by the law. It's a shame we don't have something equivalent for software.

A belated review for Eric's latest book

I promised Eric a while back that I'd post a review of his latest book. I think it's a great book, but have been so busy I didn't find the time to do the review until today. Hopefully it's a case of "better late than never".

Web Services specification architecture book

Some of my friends/colleagues from IBM have finally gotten their book out. This gives a view of the Web Services architecture as IBM sees it, along with the specifications they see as fitting into it. Since most (all?) of the specifications are ones that IBM has been working on (in and predominately out of standards bodies), it may not be an objective view, but no one can argue that it's not important to the industry.

Now all I need do is write a review.

WWW 2006

I'm the chair of the XML and Web Services track of WWW2006, which next year is being held in sunny Edinburgh. Santosh is my deputy (kind of makes a change after all these years) and we're in the process of drawing up the list of PC members. I'm not sure when the CFP will go out, but I suspect it'll be around August time, with reviews happening over December as they did for this year's conference. So, get those thinking hats on!

Grid and Web Services work

Looks like a paper based on the work that Jim and Thomas did while working for us is now available; they did the work with Savas et al. Check it out. It sent a lot of ripples through the Grid world that are still being felt today.

The session concept for Web Services

Greg has posted about a paper we wrote at the end of last year. I won't repeat the whole story here, but I really hope the delays in publication are sorted out. Anyway, take a look at the paper. Greg is hopefully going to put up a pdf version shortly.