savas parastatidis

The new paragraph on REST and some more comments

Following from my previous post, here is the revised (again) paragraph that Jim Webber and I agreed on.

There have been proposals for naming and uniformly providing access to resources, such as the REpresentational State Transfer (REST) [24] model. However, REST depends on a naming scheme for resources which couples the semantics of an interface with the identified state (e.g., http://domainname/resource-ID suggests that only the HTTP GET/PUT/POST/DELETE operations can be applied on the identified resource). The semantics of the interface are transfer-protocol-depended. We believe that this is unsuitable for heterogeneous systems like the Grid where resources may be accessed/modified by services in any number of complex ways.

I do hope that Mark is happier with the language now, although I don't expect us to agree on the approach for building loosely-coupled applications as he seems to like WS-RF. However, I think he's going to like our proposal even more since we accommodate REST as one of the possible ways service builders may like to provide access to their resources. Our proposal is about a framework for providing metadata information about a resource that is named outside the boundaries of a service. The paper that gives more details about our ideas is in the last stages of the editing process.

An initial message giving a hint about our ideas was sent to the WS-GAF mailing list today in order to start the discussions and get some feedback. If you want the attachments that are referred in my message, please drop me a line. The February archives of the WS-GAF mailing list are here. You can find out how to subscribe to the mailing list here.

3 responses to “The new paragraph on REST and some more comments”

  1. Mark Baker
    Ok, better, but I tried to explain before how resources identified by a URI in a particular scheme aren’t restricted to only being interacted with via the semantics associated that scheme (via the protocol). e.g. I can interact with ftp URI identified resources with FTP semantics or HTTP semantics, and perhaps some as-yet-undefined semantics which can engulf all or part of FTP. It seems that you’re set on concluding that a RESTful approach is insufficiently heterogenous. But unless your requirements are that no components are to be easily integrated, I don’t see how you can get any more heterogenous than the Web. Large scale integration *requires* an a priori agreed upon abstraction. It doesn’t have to be a rest:Resource, but it has to be something with a well defined interface. A tuple space perhaps. A message inbox. etc..
  2. Savas Parastatidis
    I agree that there has to be an agreement on the information that is exchanged between services. Otherwise, we are not going to achieve integration. But, you see, we are concentrating on the format of those messages rather than on operations on resources as it is the case with REST and WS-RF. Resources are usually hidden; they are not exposed outside the boundaries of a service. We see a difference in the conceptual model of how to build distributed applications. In our approach, we concentrate on the format of messages and the interaction patterns. In the REST and WS-RF approach, the focus is on operations on resources (from any protocol, not just HTTP… i understand that now).
  3. Mark Baker
    I understand, and I know we’ve talked about this, but just to sum up my position for your readers … I think it’s good to focus on message formats and interactions, just not to the exclusion of a shared abstraction; all are required for an Internet scale integration solution, yet pretty much every attempt at Web services has been to explicitly avoid the abstraction under the guise of “protocol independence”. It seems your efforts are avoiding that too, which is a shame, because I think you’ve nailed most of the rest of it (no pun intended 8-).