HTTP over SOAP over HTTP

the W3C just launched a new working group to refine web services resource access specifications. i might be wrong here, because i do not really know the details of what this working group considers to be resource access, but last time i checked, the web was all about resource access, and HTTP was the protocol doing a pretty good job at it.

it really seems to me that the SOAP community is still busy rebuilding the complete internet and web protocol stack on top of the HTTP transport layer, and now they are rebuilding HTTP. i am sure this is not entirely true, but i am worried that it is not completely false, either. this is the beginning of the introduction from one of the deliverables of the new working group, WS-Transfer:

This specification defines a mechanism for acquiring XML-based representations of entities using the Web service infrastructure. It defines two types of entities: Resources, which are entities addressable by an endpoint reference that provide an XML representation, and Resource factories, which are Web services that can create a new resource from an XML representation. Specifically, it defines two operations for sending and receiving the representation of a given resource and two operations for creating and deleting a resource and its corresponding representation.

this sounds a lot like HTTP to me. and then there is this introduction from another one of the deliverables of the new working group, WS-ResourceTransfer (WS-RT):

This specification is intended to form an essential core component of a unified resource access protocol for the Web services space. The operations described in this specification constitute an extension to the WS-Transfer specification, which defines standard messages for controlling resources using the familiar paradigms of get, put, create, and delete. The extensions deal primarily with fragment-based access to resources to satisfy the common requirements of WS-ResourceFramework and WS-Management. This document constitutes WS-ResourceTransfer, hereafter referred to as WS-RT.

if that does not sound a whole lot like HTTP with the idea of fragment identifiers as established through URIs and media types, i don't know. like i said above, i am probably missing some of the finer points about this activity and the proposed specifications, but looking at the general tendency of SOAP to just use HTTP as a transport protocol, i also would not be surprised to see that to a large extent, this new activity is essentially building HTTP over SOAP over HTTP.

unfortunately, the specifications quoted above still use and claim ownership over the terms web services infrastructure and web services space, as if SOAP was the only way to do web services. it is not, and RESTful web services are becoming more and more important. but it is a pity that the web services term is still held captive by such a narrow concept of what a web service is. i am always struggling what to say when i am talking about the wider idea of web services, and often i am falling back to the term web-based services, but this mostly confuses people and many still think i am talking about SOAP. maybe we should start talking about SOAPfree web services or something along these lines...

i would love to be proven wrong here, so if i am missing something essential that would make it impossible to just use HTTP for the resource access specifications targeted in that new working group, i would be interested to learn about it.

Comments

[dret]

http://stage.vambenepe.com/archives/436 has some discussion about the same issue (and links here), but looks at it from a different perspective - more in terms of whos interested in these specifications and who is pushing them, and how that may affect the chances of success for this WG.