Just a month ago, it looked as though all the effort put into developing web services standards was going to end shamefully. Although all the vendors involved started off in full support of one another, the spirit of co-operation seemed to have died over the all-important web services addressing standard – a vital bedrock for both future web services standards and service oriented architectures (SOA).
A combination of fierce negotiations, compromise and clever politicking has resulted in the end of this phoney war. WS-Addressing is becoming the likely basis for future web services standards as well as SOA developments – one the whole industry can seemingly get behind.
WS-Addressing was one of two proposed standards for developers to specify where a message should be delivered in a web services network, the other being WS-MessageDelivery. A group of companies led by Microsoft, IBM and BEA were firmly behind WS-Addressing, with another led by Sun, Oracle and Iona pushing WS-MessageDelivery equally firmly. Now the two groups have jointly submitted WS-Addressing to the World Wide Web Consortium (W3C).
Although WS-Addressing may seem like just another web services protocol, if it becomes adopted, it will be part of a foundation for SOA development and secure, transacted, asynchronous and reliable web services. IBM says WS-Addressing “establishes message information headers that will make new web services message flow patterns possible”, and will have “profound impact on SOAP [Simple Object Access Protocol] engines and the future of the SOAP protocol itself”. WS-Addressing is already the basis for other proposed standards, including WS-ReliableMessaging, WS-Federation and WS-AtomicTransaction, even though it is still only being considered by the W3C.
But only one standard would survive the head-to-head fight between the Microsoft and Sun groups: with so much effort going into making SOAP, WSDL and UDDI interoperable, to suddenly divide the momentum behind web services standardisation into two would have almost certainly pushed web services the way of CORBA and other failed interoperability standards.
Of the two, WS-Addressing looked more likely to triumph. BEA, IBM and Microsoft were behind it and it had with over a year’s head start in development time over WS-MessageDelivery. But the Microsoft contingent neglected to submit the proposed standard to the W3C, unlike Sun and its campaigners, which did so in May of this year. Ratification by the W3C together with support from Oracle, Iona and Sun, the force behind J2EE, could still have led WS-MessageDelivery to come through against the odds.
There are some obvious questions though: Why propose a standard that competes directly with another proposed standard, only to give in five months later? Why cite the maturity of WS-Addressing as a reason for the compromise, as Sun has done, when it already had a year’s head start from the outset and would therefore always be “more mature”?
It seems probable that WS-MessageDelivery was, in part, never considered as much more than a bargaining chip, designed to get WS-Addressing amended to better suit Sun’s group. WS-Addressing matched the Microsoft group’s technological interests far better than it did Sun’s, and with IBM, BEA, Microsoft steering the specification outside of a standards body, it was unlikely that that would change.
By proposing a less mature specification that overlapped with WS-Addressing but which contained additional capabilities better suited to their technology, it was possible for the Sun group to legitimately fail to support – and be railroaded by – WS-Addressing. And by submitting the standard to the W3C, WS-MessageDelivery could have ended up incorporating its rival, not vice versa, as is likely to happen now. The result? The two groups are one, and the Sun group can work from the inside to have its wish lists incorporated into the Microsoft group’s specification, rather than begging from the outside.
With the industry now backing a single proposal, a standard could be agreed by as early as 2005. The next phase of web services and SOA development and deployment can then begin in earnest.
