The last round of WS-* specifications are separate from the Web Architecture and are harmful to Web architecture.
These specifications (WS-Transfer, WS-ResourceTransfer, WS-MetadataExchange, WS-Eventing and others) are not guided by the web architecture nor by the W3C TAG. I'm not supportive of any work happening at the W3C that are not governed by the W3C TAG including the Web Architecture document. The harm is that many new resources are being created and used in a separate information space from the Web, reducing their utility and the utility of the web.
The WS-* specifications, particularly WS-Transfer, are fundamentally separate because they effectively make no use of URIs and they re-invent HTTP, HTTP cookies, and even fragment identifiers (part of WS-ResourceTransfer)
As a leading member of the WS-* community, I completely understand the motivations for multi-protocols (hence reinventing HTTP), QName based dispatch (SOAP headers and the WS-* additions), formal description languages for scaling #s of operations (WSDL, WS-Policy), discovery, etc. Much of the WS-* functionality will be recreated in Web land. For example, creating many resources that have varying security requirements around encryption and signing, that can be discovered and used without a human requires a description language, a security description language, description discovery, and description matching. This works now in WS-* toolkits.
It's just that they aren't part of the web, and they basically flipped the web architecture and the TAG the bird.
SOAP was the start. The TAG wanted a clean integration between the Web and SOAP services but XMLP didn't deliver it. Sam Ruby's proposal that an XML response could be interpreted as a SOAP body without any headers never got traction. My proposal for mapping SOAP-RPC into HTTP GET went nowhere. What we got was the SOAP-Response MEP, and nobody does it. It was the usual "too late in the process" argument, and fundamentally the major players weren't interested in a real solution.
Then WSDL came along and finished the job. The HTTP Binding in WSDL 1.1 is completely broken and not implemented. WSDL 2.0 has a great HTTP binding. WSDL 2 WG really took the integration to heart, but again the major vendors weren't interested. MSFT killed WSDL 2.0 by walking away from deploying it.
WS-Addressing came next and re-invented HTTP Cookies with the EndpointRefence's Reference Parameters/Properties. Here the TAG right at the outside pointed this out and it was even in the WG's charter the issue of URIs for identification. I proposed a bunch of QName to URI mappings that would allow binding the Reference Properties into the URI for HTTP Get. The WG, over my concerns, decided to simply drop Reference Properties and the related EPR comparision section. That just hosed anybody that wanted to use them for identifiers, like WS-ReliableMessaging anonymous endpoints. As a result, people came up with even worse hacks like adding attributes to Reference Parameters to indicate they really are identifiers!
Now we're at the final stages of the WS-* standardization. Given that any WS-Resource stuff WG at the W3C won't be guided by the Web architecture and they won't listen to the TAG, there is no technical reason why the work should ever happen at the W3C.
The obvious reason why the work would happen at the W3C is if the W3C Membership wants it. If enough people and companies want to work on this at the W3C, the W3C ought to listen to that.
Perhaps the W3C needs a separate section for vendors that want to do whatever they want with a W3C URI for their specifications and the awesome W3C tools (I <3 Zakim and RRSagent).
But the work shouldn't be able to claim that it has gone through the full W3C process including architectural oversight. And the TAG should not claim that it has had any oversight or review of the products.
These specifications (WS-Transfer, WS-ResourceTransfer, WS-MetadataExchange, WS-Eventing and others) are not guided by the web architecture nor by the W3C TAG. I'm not supportive of any work happening at the W3C that are not governed by the W3C TAG including the Web Architecture document. The harm is that many new resources are being created and used in a separate information space from the Web, reducing their utility and the utility of the web.
The WS-* specifications, particularly WS-Transfer, are fundamentally separate because they effectively make no use of URIs and they re-invent HTTP, HTTP cookies, and even fragment identifiers (part of WS-ResourceTransfer)
As a leading member of the WS-* community, I completely understand the motivations for multi-protocols (hence reinventing HTTP), QName based dispatch (SOAP headers and the WS-* additions), formal description languages for scaling #s of operations (WSDL, WS-Policy), discovery, etc. Much of the WS-* functionality will be recreated in Web land. For example, creating many resources that have varying security requirements around encryption and signing, that can be discovered and used without a human requires a description language, a security description language, description discovery, and description matching. This works now in WS-* toolkits.
It's just that they aren't part of the web, and they basically flipped the web architecture and the TAG the bird.
SOAP was the start. The TAG wanted a clean integration between the Web and SOAP services but XMLP didn't deliver it. Sam Ruby's proposal that an XML response could be interpreted as a SOAP body without any headers never got traction. My proposal for mapping SOAP-RPC into HTTP GET went nowhere. What we got was the SOAP-Response MEP, and nobody does it. It was the usual "too late in the process" argument, and fundamentally the major players weren't interested in a real solution.
Then WSDL came along and finished the job. The HTTP Binding in WSDL 1.1 is completely broken and not implemented. WSDL 2.0 has a great HTTP binding. WSDL 2 WG really took the integration to heart, but again the major vendors weren't interested. MSFT killed WSDL 2.0 by walking away from deploying it.
WS-Addressing came next and re-invented HTTP Cookies with the EndpointRefence's Reference Parameters/Properties. Here the TAG right at the outside pointed this out and it was even in the WG's charter the issue of URIs for identification. I proposed a bunch of QName to URI mappings that would allow binding the Reference Properties into the URI for HTTP Get. The WG, over my concerns, decided to simply drop Reference Properties and the related EPR comparision section. That just hosed anybody that wanted to use them for identifiers, like WS-ReliableMessaging anonymous endpoints. As a result, people came up with even worse hacks like adding attributes to Reference Parameters to indicate they really are identifiers!
Now we're at the final stages of the WS-* standardization. Given that any WS-Resource stuff WG at the W3C won't be guided by the Web architecture and they won't listen to the TAG, there is no technical reason why the work should ever happen at the W3C.
The obvious reason why the work would happen at the W3C is if the W3C Membership wants it. If enough people and companies want to work on this at the W3C, the W3C ought to listen to that.
Perhaps the W3C needs a separate section for vendors that want to do whatever they want with a W3C URI for their specifications and the awesome W3C tools (I <3 Zakim and RRSagent).
But the work shouldn't be able to claim that it has gone through the full W3C process including architectural oversight. And the TAG should not claim that it has had any oversight or review of the products.
Leave a comment