The basic specs are well along. This Autumn, the W3C released working drafts of SOAP and WSDL 1.2, the protocols fundamental to Web services. And just last week, two more milestones were reached: The W3C published its Web services architecture usage scenarios and the UDDI directory specification, now in version 3, was officially submitted to the OASIS standards organisation.
The ascendancy of OASIS in the Web services standards process is welcome, mainly because it signals that Microsoft and IBM have decided not to ignore all the fine work done by rivals. (The big breakthrough was the submission of the WS-Security specification to OASIS on June 27.)
But now that the three basic Web services protocols are more or less final, the tower of proposed standards for Web services authentication, business processes, and security is already teetering--and could topple. The major challenges include ensuring that authentication works across various contexts, managing long-running multiparty transactions, and figuring out the rules for sharing user profile information in a federated identity model.
Dozens of committees and working groups are hammering out specifications, among them:
- Apache Axis (a.k.a., SOAP 3.0)
- Apache Web Services Inspection Language for Java API
- Business Process Management Initiative
- ebXML.org
- Internet Engineering Task Force LDAP Schema for UDDI
- Liberty Alliance
- OASIS Web Services for Interactive Applications
- OASIS Web Services for Remote Portals
- OASIS Web Services Security Technical Committee
- UDDI.org
- W3C Web Services Architecture Working Group
- W3C Web Services Description Working Group
- W3C Existing XML Protocol Working Group
The logical group to try would seem to be the Web Services Interoperability (WS-I) organisation, the only dot-org focused solely on Web services. Founded in February by IBM and Microsoft to "promote" Web services--and explicitly not to create standards--the WS-I has charged itself with developing sample Web services applications and ensuring tool compatibility. With only the basic Web services protocols to work with, the organisation doesn't have a whole lot to do right now. But when such monster specifications as WS-Security make their debut--and have to be reconciled with other security specs--the WS-I should be working overtime.
But can the WS-I be effective? Under the organisation's current bylaws, an unelected cadre of players sets the agenda. A source inside the WS-I told me he's sceptical that, as it stands, the organisation can ensure that "standards get applied and are judged on an impartial basis." He believes the WS-I could be the place where working groups reconcile standards from various organisations, but that the WS-I's "closed nature may prevent this from being truly credible."
For corroboration of this view, look no further than the fact that, amazingly, the issue of Sun's membership in the WS-I remains unresolved. Sun could still clinch one of two elected seats, but at this point, it's doubtful that any elected seat will have the power or longevity of those held by the organisation's founders.
Industry organisations don't need to be democratic, but they do need to be--to use my source's word--credible. IBM and Microsoft took a big step in the right direction when they invited OASIS into the standards process. Now, to ensure that interoperability testing isn't used as a means to favour certain vendors' software over others, the WS-I's founders need to open things up a bit.
The next phase of Web services standardisation promises to be mind-numbingly complex. Unless everyone has a seat at the table, we could be left with yet another lofty stack of protocols that nobody uses.
