WS-Context and XML 2004

I'm here at XML 2004 in Washington DC for a couple of reasons. The first is that we're doing an interoperability demonstration with Oracle and IONA Technologies of our respective WS-Context implementations, just to prove that it is an interoperable spec. and (hopefully) soon-to-be standard.

This is cool, because I've been working on this notion of context for the best part of a decade, starting with some nice work I did with my friend Stuart Wheater and friends/colleagues at IBM Hursely (Ian Robinson, Tom Freund, Tony Storey and Iain Houston to name a few) and IONA Technologies (Eric Newcomer) on the OMG Activity Service (aka Additional Structuring Mechanisms for the OTS specification - bit of a mouthful!) and moving through J2EE to Web Services. So it's nice to see the fruits of your work, so to speak. However, it's morphed quite a bit over the years, particularly over the past couple. And it's nice to see a wider adoption (and constructive input) by companies such as Oracle.

It's also nice to see more and more specifications coming out that use context. WS-Enumeration, WS-Security, WS-Reliability to name a few. Now if only we could encourage these guys to use a standard context format rather than developing ad hoc solutions.

Although Web Services are as much about interoperability as they are the Web, it's interesting to note that interoperability isn't something that's a given for Web Services specifications. It's like anything: unless you design with it in mind from the outset, you can quickly end up with a closed system. For example, without naming names, there are several WS specifications out there that define extensibility elements (##other to you and me). Now that isn't necessarily a bad thing (hey, we do the same in WS-Context). It becomes a bad thing when either the specification requires you to use them (and doesn't provide concrete rules for the contents) or implementations require them to be filled with vendor specific information (and again, often don't externally publish this information for other vendors to use). IMO this is an easy route back to vendor lock-in.

We had the same issue back in the OMG OTS days, where the transaction context defines an extensibility element (a CORBA any). The intention was that an implementation could fill this with whatever information it needed to provide optimizations for itself (e.g., build up a subordinate transaction hierarchy in a downstream node when a request is made on a service on that node and then pass it back up to the parent when the response is delivered, rather than call back to the parent as you build up the hierarchy before executing the request), but if that information wasn't present then heterogeneous implementations could still interact, albeit in a possibly less efficient manner. However, it quickly got hijacked and implementations required the CORBA::any to be present and filled with specific information in order for them to work. Quite nice it you want to prevent interoperability and encourage lock-in.

Anyway, I digress. The WS-Context interoperability demo hosted by OASIS went well. We used two local implementations (Arjuna's running on my laptop and IONA's running on their own laptop) and a remote on (Oracle). It'd be nice to say that that's the configuration we always intended, because it shows us talking form DC to Philadelphia, where the Oracle endpoint is located, but I'd be lying. The reason we did this was that poor Simeon (Green) from Oracle had his laptop die on him an hour before the demonstration! Sods law!!

Tomorrow Doug Bunting (Sun) and I are presenting on WS-CAF and how it fills some of the gaps in the current Web Services architecture. Hopefully that will go as well as the interop. demo.