Why WSDM isn't ready for primetime (yet)

So, the WS-DM TC are happy with their Committee Draft document and are now trying to get it adopted as an OASIS specification. STOP. DON'T DO IT! MOVE SLOWLY AWAY FROM THAT DOCUMENT!

As I've just explained in our vote to OASIS, we're happy with TC CD status, but the unfortunately the specification has dependencies on non-finalised and proprietary specifications, including WS-N and WS-Addressing. What's worse is that WS-N uses a different version of WS-Addressing than the WSDM specs do!

It's premature to elevate the spec. to the level of OASIS international specification. In particular WS-Addressing is currently being worked on and looks like the final version when it finally emerges will be significantly different from its various antecedent proprietary versions and won't be available until after July 2005. In particular, already we've seen that ReferenceProperties has been removed from the current draft of WS-Addressing in W3C, so this will have an immediate affect on WSDM. So you'd download the specification to implement it and find that it's pretty much broken!

I think to adopt this as a standard will set a dangerous precedent for OASIS. Specifications that attain the OASIS international specification level ought to be stable and have a certain amount of rigor and interop testing.

Let's hope the voting members see sense and send this back to the TC to correct.

The shape of things to come

Several years ago REM released a great song called It's the end of the world as we know it. That song seems quite appropriate in some ways at the moment, because we're about to release a GA version of the Arjuna Transaction Service 4.0. As I've said before, I've been working on Arjuna since 1987 and have seen it morph quite a bit over the years. As this paper shows, its seen a lot of changes and most of those have reflected changes in middleware architectures. So it's appropriate and in line with previous changes, that ArjunaTS 4.0 merges our formerly stand-alone Web Services transactions product ArjunaXTS with what has always been called the Arjuna Transaction Service and included JTA and OTS functionality.

There are several reasons why we took the approach back in 2002 to have two separate products and I'll mention a couple. When we were working as part of HP Middleware on the world's first Web Services transactions product it was a separate entity from what was then known as the HP Transaction Service; it also seemed unlikely that people would want Web Services transactions bundles with a transaction manager that required a CORBA ORB, despite the fact that you wouldn't use the ORB if you were working purely in the Web Services arena.

That last point has, with the benefit of hindsight, proven wrong. Back in 2002, just before the finalisation of the end of the HP-Compaq merger, I wrote an internal document about what I called End-to-end Transactions. (Apparently Gartner calls them Multimodal Transactions these days.) It was a way of describing how Web Services transactions (and specifically the product we'd been working on for HP) could be used to glue together other transaction domains, from mobile phones to laptops to mainframes, and incorporating potentially different transaction models. Some of this went on to become the Business Process transaction model in WS-Transaction Management, but most of it got filed in the dark corners of my brain when we span out of HP. But the main concept was that Web Services transactions don't just start in the Web Services ether: they'll typically begin in some corporate intranet and span to other corporate internets, with Web Services as the glue.

Funnily enough, over the past couple of years we've seen precisely this kind of use case from the early adopters of ArjunaXTS. Many of them have been asking for this kind of capability: bridging between J2EE transactions and Web Services transactions and vice versa. As a result, because we had two separate products (and the glue to stick them together), these early adopters ended up taking them both, with the added maintenance, setup, management etc. costs that that implies. So, one product seemed like an obvious improvement. I see the bridging capability a little like Sauron's ring: "and in the darkness bind them".

Time to learn a new language

It's been a while since I learnt a new progamming language. The last one was C#, but that was 3 years ago. I've been looking around for a while and the one that's grabbed my interest is Ruby. There've been some interesting things said about it over the past year or so and it seems to have become fairly stable now. Time to take a dive into it, I think.

Web Services Coordination Framework on its way

Last week we had the second face-to-face WS-CAF meeting to concentrate pretty much soley on the Web Services Coordination Framework (WS-CF). The first was in Dublin last November, where we made some fairly significant modifications to the specification and in this meeting we went through the 76 issues, closing many of them down. Because WS-CF builds on WS-Context the core concept that we've developed is the activity group: such a group is created when a context of a specific type (e.g., a coordination context) is begun via the Context Service. Participants can then register with that group via the endpoint reference (EPR) that is embedded in the WS-CF augmented WS-Context structure.

Because WS-CF is meant to be a low-level, generic coordination infrastructure, there's not a lot we can do at this level in terms of specific coordination protocol, i.e., coordinator-to-participant and participant-to-coordinator interactions. (Actually, we did a lot more in our initial submission to OASIS than we do now, but the TC has decided to remove some of that stuff and punt it to the higher level users/specifications.) So, apart from adding and removing participants, and handling recovery (yes, believe it or not, things do fail in the Web) of both coordinator and participants, that's pretty much WS-CF in a nutshell.

You might ask what's the difference between WS-CF and the IBM, Microsoft, BEA WS-Coordination specification? If you'd asked that question a couple of years ago (when we first released them) as many analysts did, the answer would have taken a couple of pages to describe. Now it's a lot simpler, but would still take a page, so I'll mention only two differences: WS-CF builds on WS-Context, so in our opinion fits into the Web Services architecture more naturally; it also handles basic endpoint recovery at the level that makes sense rather than making everything a users responsibility to figure out.

Anyway, I think that everyone who attended the meeting thought it went very well. Certainly I came away from it last week happy that we'd made a lot more progress than I'd hoped for. With any luck we should have WS-CF finished and almost at Committee Draft by April (we have to produce a Primer, which is probably the most work between now and then) and then we can move on to transactions, which is something I'm looking forward to.

Before I forget though, thanks go to CodeWorks for sponsoring the meeting. We've been working with these guys for a couple of months on helping to educate companies in our region on the benefits of Web Services and their remit is to publicise Web Services and the region as widely as possible. I think this was a good opportunity for them (and us) to get that point across to companies who attended the face-to-face and I'm confident that there'll be some tangible benefit to CodeWorks and the region as a result.

Groundhog Day

On the trip over to New York the other week I watched GroundHog Day, which is still a great film. I have to admit that I always thought it was just a movie and that such an even didn't really happen (at least not in this day and age). So it was a bit of a surprise to overhear a couple of people on the 2nd of February discussing the events of the latest Day in all seriousness. You live and learn I suppose!

Flights are bad for your health

Time for a rant. Pretty much everytime I travel on a plane I end up
with a cold of one severity or another. So, I'm back from the Web
Services on Wall Street conference and guess what: I'm hold up in bed
with a flu. Without going into any of the gorey details, suffice it to
say that I'm sure there are tiny creatures in my head playing with
pneumatic drills.

I've been travelling for more years than I care to remember, but it
wasn't until Twelve Monkeys came out that I really thought about
this. (BTW, it's a great movie IMO.) What a fantastic way for viruses
to spread around the globe! Now is it just me or does this not seem
like an opportunity waiting to be exploited? You can take your
missile-shields, missile-detectors, early warning systems etc. Where's
the equivalent for a viral attack? I've never been asked to prove that
my aerosol contains deoderant and not some virulent strain of
botulinum bacteria. As the film shows, the perpetrators don't even need to be
on the same continent!

BTW, this isn't something I'm going to worry about any more than I do
other threats. It's just that I'm lying here in bed and the mind tends
to wander.

J2SE 5.0

I've just finished the first day at the Web Services on Wall Street conference. It's been interesting and strangely enough, probably the most interesting presentation was on J2SE 5.0 (Tiger). I have to admit that I haven't had time to look at this stuff since the previews I saw at last year's JavaOne. So it was good to get an overview of what Sun think are the most important changes to the language since the first version.

Generics (templates to you and me) have been coming for a while and not before time. I've used templates in C++ a lot and although I've always found them useful, they were probably one of the most un-portable features of the language I ever came across. Things have probably changed now though.

Autoboxing seems like a nice-to-have though not critical; keeps the language tidy (although maybe it's one step closer to allowing us to have operator overloading ;-). Same for the enhanced for loop and static imports.

Now type safe enums are cool. I've put up with integers in code since the first time I used Java and it really annoyed me that there was no natural way to do enumeration types. But what they've done in J2SE 5.0 with enums does seem to go one better than C++ and allow me to add functionality within an enum. This looks very interesting.

Ah varargs :-). What more can I say? At last!

Metadata looks like it could be very useful too. Certainly the presenter indicated that Sun intend to use this feature more and more as the language evolves.

Then they've added other things like printf/scanf. Nice and useful. However, as a whole, not good enough IMO. Java has always fallen short of C++ on I/O routines. You just have to look at the things you can do with cout and cin to see what I mean.

Anyway, all in all J2SE 5.0 looks like it could be a good addition to the Java family. Sun reckon that you could get 20% performance improvement just by running old code on it. I'll wait and see on that one. But I do wish I spent more of my time programming so I could find out. Oh well. Maybe next vacation!

Cool trains

This looks cool. I haven't played with trains since I was a kid and used Hornby. The details on the trains always impressed me, which is what you'll not be able to appreciate in this virtual equivalent. However, it saves on having to pack stuff away once you're finished.

New York taxis and quantum mechanics

There’s a generally held belief in theoretical and applied physics that nothing is continuous and everything comes in discrete packets (quanta). Light, atomic particles, even time, have their own quantum behaviour and their own sizes for a quanta. Furthermore, these entities possess both wave and particle natures. My old physics teacher used to call these wavicles. Now this discrete nature of things is only really "observable" at the microscopic level; where we live, on the macroscopic level, our eyes, senses and most machines simply can’t discern the individual quanta and we perceive them as continuous.

So where’s all this leading, you might ask? Well I’m in New York at the moment at the Web Services on Wall Street conference. I just flew into Kennedy and while waiting for a taxi at the airport I realised that every single time I’ve been here before it always goes the same way: you get off the plane, spend 50 minutes going through customs and then spend another 50 minutes waiting for a taxi; when they do arrive, they always turn up in fours. So, the size of an airport taxi-quanta is 4. My question is: why? Is there some physical process that does that, or is it some fundamental law of the universe? Whatever the reason, after travelling for over 12 hours, as Eric Cartman would put it, that extra wait p*sses me off! And let's not forget that there's always some taxi-rank "conductor" (sorry, can't think of the right term at the moment) who seems to think that blowing a whistle really loud will make things better. No, all it does it deafen the people standing in the queue!!

BTW, taxi’s also exhibit other quantum behaviour, specifically Heisenberg’s Uncertainty Principle, which in one of its incarnations says that you can’t measure position and momentum precisely. For taxis, if you need a taxi you can never find one though there are always plenty of empty ones speeding around; when you don’t want one, there are plenty parked in the road!

A real world example of context over object key

While writing this entry I got to thinking about what was a good real world example of the benefits of a context-based approach to sessions and state management. The one I came up with is fairly obvious (particularly with 20-20 hindsight): snail mail.

So how is this a good example of referencing via context? Well let's look at how we might model this architecture using two different approaches. In both cases, obviously the goal is to get some information (the content of the letter) to an entity that can deal with it (the person/organisation on the front of the envelope).

In the first approach (WS-RF) the address on the envelope is a hard reference to the ultimate receiver and therefore I would be required to deliver the message directly to that house. If the individual moved, then I'd need to figure out where he'd gone (maybe he would stick a redirect message on the front-door, but there are obvious limits to how much effort I'm going to go to there).

Now let's go back to the way the snail-mail post really works. I'm fairly sure mail delivery works pretty much the same throughout the world, but here in the UK when you've addressed and stamped a letter you stick it into a postbox - you never deliver it by hand. Now that letter doesn't go directly to the individual on the address; it is routed via a sorting office, which may then pass it to other offices in this country or even abroad. Ultimately it'll end up in a sorting office that is local to the final destination and a postman will be given the job of delivering the letter (probably at 1pm in the afternoon if my post is anything to go by!)

So, implicit with every address I put on a letter is the address of the local sorting office. They know where the ultimate receiver is and I don't need to (which is good because I'd hate to have to run something like MultiMap each time I wanted to find out where someone lived). If he's moved, he can arrange to have mail diverted to a new location simply by telling them. Obviously this can't go on forever and eventually becomes a matter of diminishing returns, but that's up to the householder.

In this case, the initial destination (service) for my letter is the post office (as I said, implicitly addressed in the physical world) and the context associated with the message is what I stick on the front of the envelope: it's my session information and is the same for all letters I write to that individual. How the post office "service" gets the content of my letter to the recipient is a backend implementation choice. They can (and have) changed that implementation many times over the years, but the way I write my envelopes (the context) never changes.

If the ultimate receiver does eventually move, I may get a new context from them (setting up a new session) or the equivalent of a 404 (Not Found) message.

Trying to be even handed, I suppose another way of approaching this would be to say that the binding of SOAP-to-PostOffice implicitly does all of this routing/redirecting for me, but that then relies on a specific medium. I'd like this to work no matter what carrier medium I use.

You could also argue that the post office (or actually the sorting office) that is implicitly addressed in the physical world suffers from the same static address problem. But it doesn't - as far as my letter is concerned it is stateless; the letter could just as easily be dealt with by any sorting office in the country (hey, the model allows me to post my letter anywhere after all). So this is an example of where any "service" that offers the same functionality (dealing with post in this case) can be used: I'm not tied to a specific instance.

Of course another way of looking at this is that it's all just
hierarchical naming again. However, I think it just shows that abstracting the *what* (my ultimate receiver) out of the *how* (the post office in this case), makes for a scalable system. (Except at Christmas, where they almost never guarantee delivery dates for postcards!)

Dave and Oil

Dave has a great post on oil reserves here. Definitely worth a look.

Long running sessions

I've been talking to some friends who are proponents of WS-RF and
embedding ReferenceProperties/ReferenceParameters into an EPR. By now we all know that RefProps have gone from the latest version of WS-Addressing, but the principle that they want is the same: an EPR points to a specific (stateful) resource instance of "within" a service.

I've mentioned before why I think this is a bad idea for SOA and so have others. However, the arguments I'm hearing now are based on the supposition that regardless of the merits of context and sessions via that route, you always need a way to refer to some specific instance of a service/state outside of a session. Hence the "object key" approach that WS-Addressing epitomises (and WS-RF uses).

However, I'm still not convinced. Afterall sessions are time dependant
entities: the information that you manipulate within a session is
inherently temporal in nature, even if the period associated with it
is arbitrarily large. So why not just say that there are such things
as sessions that have a lifetime as long as the age of the universe?
Seems to me that you then keep a single uniform model for accessing
and manipulating *back-end implementation specific information* that
is in line with the loosely-coupled nature of SOA we want to
maintain. Or am I missing something?

Here's an easy real-world example, based on the ubiquitous bank
account. I've had an account with my friendly bank since 1984 (nothing
ominous in that date!) and I've kept the same account number
throughout. When I go into any branch in the country I just give them
my account number and Hey Presto, I've got access to my
account. (Imagine if the account number was hard-coded into the branch
address, so I could only got to a specific branch!) If you think about
it, that's a pretty long running session, which we could model
trivially with WS-Context.

An overview of WS-CAF

For those of you who really want to know, here's an overview of WS-CAF from OASIS.

Blog on webservices.org

I've been given a blog on webservices.org. Worth checking out ;-)

Welcome Arnaud

My friend and colleague Arnaud Simon has started to blog. Arnaud's the architect/technical lead for our JMS product and is a keen runner, swimmer and ex-smoker. He's got a great understanding of messaging and transactions and I look forward to reading his blog.

Amazon's new CTO

OK, I'm a little late on this, but I've been busy! Amazon have just made my friend Werner Vogels their new CTO. Way to go Werner!

Werner and I have known each other for many years, going back to when I was a PhD student and he was working with Ken on the Isis project. I think Amazon have made a great choice: Werner's a nice guy who's got a good breadth of understanding and can usually hold his own when we have a few drinks together!

Interoperability of Web Services transactions

I mentioned the other day that I'm at the Web Services Transaction interoperability workshop here in Raleigh. We were at the first of these workshops back in April when we went over the various specifications to try to enhance them to improve interoperability. 9 months later, we're actually trying to make our product work with other implementations. Pretty cool, but also a very intense few days.

Unfortunately in order to attend we had to sign a fairly restrictive agreement that basically says we can't give much information about what happened. So I'm not even sure whether I can even say who was there beyond the usual suspects. But with that restriction in mind, I'll try to give an overview of what happened.

First of all, I had intended to post something before and during the actual event. However, it turned out to be way too busy. There were almost a half dozen different companies represented with nearly two dozen test scenarios! I talked to my friend Jorgen who was there with the Microsoft contingent and he said this was the most scenarios of any interoperability workshop: he should know, as it's his job to attend them all! Then each scenario has two possible actors: the initiator (basically who is the transaction coordinator) and the participant (who's being driven by the coordinator according to the specific protocol). So you can imagine the test matrix was pretty big - at a minimum we had to take part in nearly 300 tests!

Whoever thought that we could do this in two days needs their head examining. No individual specification, whether it's Web Services, CORBA, IETF or whatever, is ever going to be so carefully written that there's no scope for confusion or misinterpretation. Throw into that the fact that the transactions specifications build on the WS-Coordination specification and they all use WS-Addressing and that transaction protocols are inherently complex things to understand let alone implement, and you've got a potential state explosion for getting things wrong. So I'm actually pretty impressed by all the attendees that it worked out so well. Of course there were some hiccups, but everyone seemed to go into it with an open mind to just "get the job done" and I think we did. In fact, now that it's over and I look back, I'm really surprised by the lack of significant implementation and/or specification problems.

As I've said before, Web Services are as much about interoperability as they are about building internet-scale applications. However, that doesn't mean that a Web Services specification is inherently interoperable. So, something like these workshops, or the ones we did for WS-Context are necessary. I think other standards bodies such as the OMG could benefit from this approach.

So we spent two intensive days going round each scenario testing and being tested, updating and forcing updates and ultimately clarifying the specifications and agreeing on what interpretations made sense. I had some great help from back in our office, despite the timezone difference. A collective pat on the back!

The place this all happened was really nice. It has food of one sort or another constantly available, with drinks throughout the corridors. The perfect finishing touch came at about 2pm when they opened a sweet (candy for the Americans amongst you) "bar": a long table with different types of sweet-stuff. My dentist isn't going to be happy when I see him next, but when the going got tough, it was the gummi-bears and coke that kept me going!

Well I've been up at 4am every day since I got here (and 4am when I travelled here), so it's time to catch up on some sleep. Then it's a flight back home, assuming I don't get snowed in!

Busy busy busy

I can hardly believe it's only mid-January! Since the start of the year it just seems to have been one thing or another that's taken up so much time. Over the Christmas and New Year period I've been working on severalJavaOne proposals with colleagues here and Oracle. Still not finalised any of them, so we'll have to do that before the deadline.

Then there's been all the work on WWW 2005. As I've already mentioned, I'm co-chair on the Web Services and XML Track and we had a lot of papers to go through. Thanks to the many reviewers who helped. The quality of the papers was OK (maybe the bell-curve was shifted towards to origin a bit) and it was difficult to make the final selection (still not finalised at the time of writing this). I have been a little disappointed with the quality of the Web Services papers: in my book taking a paper on traditional Web *Servers* and changing Servers to Services doesn't cut it, and Semantic Web isn't Web Services either. In the end the papers submitted concentrated more on the XML side of things that the Web Services.

Now does that mean that there's no interesting R&D going on in Web Services, or that people don't see the WWW conferences as the most appropriate place to publish them? I've published several times in the earlier WWW conferences and they've always been good places to attend. OK, in the early days they were about Web Servers, caching, optimizations of HTTP interactions etc, but that's because there were no such things as Web Services. But as the Web has evolved, so has the conference (not a bad example of Darwinian theory in practice). Let's hope that in the future people see the conference as a much more inclusive venue.

Another area that's taken up time is the Web Services transactions interoperability workshop, which is where I am at the moment. More on that in a separate entry though.

Oh, and let's not forget the work we've been doing with customers of our products. Sometimes that can be frustrating, but more often than not it's interesting and informative to get feedback (positive as well as negative). Someday it would be interesting to produce a timeline of all of the products and show how they've evolved over the years and (where possible/allowed) indicate why they evolved in the way they did. We started to do this with the original Arjuna System, which went on to become the Arjuna Transaction Service, but even that paper is now out-of-date. (Santosh and I have been working on an update for a while, so this just reminds me that he has the token.)

Apologies for inconvenience

There've been a few spurious comments entered today by anonymous individuals. I've deleted the ones I've spotted and have decided to only allow comments from people who have an account on blogger.com (hopefully that'll help cut down on this sort of thing). Sorry for any inconvenience, but creating an account is free and simple.

Happy new year

Well, it's 2005 and not a lot to report at the moment. However, there's an interesting article on blogging here. Worth a look.