Mark Baker discovered our work on the
Web Services Grid Application Framework (WS-GAF) and
he thinks it’s interesting. I am glad. We think our work from back in August
was influential in all the recent changes in the Grid community world (i.e., making
WS-RF
Web Services-friendly and moving away from
OGSI) although no one mentioned it in public.
Mark uses a quote from our paper
that refers to REST. He’s absolutely right in
his comments. Since the original publication of that paper, Mark, Jim Webber,
and I have had interesting conversations through private message exchanges on different
topics. I really enjoyed them. It was through those message exchanges we realised
that Mark was correct in that REST does not rely directly on HTTP.
We are currently working on a revised version of that paper which we hope to
publish soon. We have already corrected that particular paragraph and we have acknowledged
Mark for his help in better understanding REST. We were hoping to surprise him but
he caught us first :-) Here’s the paragraph as it stands in the current version.
I hope it’s more appropriate now...
There have
been proposals for naming and uniformly providing access to resources, such as the
REpresentational State Transfer (REST) [24] model. However, since REST depends on
HTTP (or more accurately a protocol with HTTP-like semantics)1 it is
protocol specific and hence unsuitable for heterogeneous systems like the Grid.
It also requires a particular interface to be used with the exposed resource, hence
coupling identity and interface.
1In practical terms, this means that HTTP
proxies must be placed in front of non-HTTP aware resources (e.g. FTP).
I do hope this is closer to what REST is all about. Of course, we are prepared
to further refine the above if necessary. I still stand with my assertion, though,
that both REST and WS-RF couple identity, state, and interface and that’s bad for
the loosely coupled world in which we want to build applications. The Web works
because of the sharing of standards like HTML and the flexibility of browsers in
dealing with bad implementations of those standards. It is also the case that the
human factor is involved, so broken links (coupling of identity and state) do not
matter in many cases. When building distributed applications in such a world, we
need something more. I think this is the gap that Web Services and SOA are trying
to fill. Of course, I may be wrong. As always, I am interested in Mark’s views.
(Note to self... must implement
trackback. Perhaps this weekend.)