Me, A Web Fundamentalist!
Web Fundamentalist
I think I might be one of Ian's Web Fundamentalists!
I will take it as a complement :-)
His defintion of fundamentalism is worth repeating:
Fundamentalism is a continuing historical phenomenon, characterized by a sense of embattled alienation in the midst of the surrounding culture, even where the culture may be nominally influenced by the adherents' religion. The term can also refer specifically to the belief that one's religious texts are infallible ...
Within in the Web community I guess that is a good way to catagorise the REST people: they think a lot of the Web is being done badly eg cookies and GETs with side effects. We also have our religious texts, which we think is infallible.
However Ian is mixing the MEST heads (aka POST everything through the one URL) with the REST people, and tarring them with the one brush. Sorry Ian, REST v MEST is a seperate battle ;-)
Unfortunately Ian doesn't 'get' REST. The unifrom interface is not just a set of HTTP methods, first HTTP is just protocol to which REST has been applied to the design of, not REST itself, and second the uniform interface goes beyond just operations; it includes things such as how you identify resources|objects|Grid services. Many of the ideas behind OGSI can be mapped to REST, it was just a question of
application. Ian your a RESTafarian, you just don't know it ;-)
In the end there is not much difference between OGSI, WS-RF and WS-RT; as if to illustrate the point people are even talking about using XSLT to create interoperability between WS-RF and WS-RT! There is not enough difference to waste all those years on anyway. In fact the point could be made that OGSI is better than WS-RF/WS-RT because it has support for identification which the others lack.
The whole stateful/stateless argument was a red herring. OGSI is a stateless protocol, just like HTTP and NFS. If you needed stateful interactions on top of OGSI you could compose with WS-Context, just like you can use cookies with HTTP.
Is REST the right approach to Grid computing? For some parts yes, for others no (Jabber is an interesting option that we have been playing with). REST is an architectural style for building a large scale distributed hyper-media system, where that overlaps with Grid computing it should be used, where it does not a different approach should be used. Would it be possible for a Grid architectural style? That is the huge challenge which I guess the OGSA group is facing.
For me, I have demonstrated that for RealityGrid a REST approach was better than the WSRF approach: Combining AJAX and WSRF for Web-browser based Grid clients. I have also demonstrated that REST can be used to solve
complex Grid problems like the co-allocation problem in a fault tolerant way that is beyond the fu
nctionality provided by the WS-* specs:
Co-Allocation, Fault Tolerance and Grid Computing, addressing the charge that it is only suitable for trivial problems.
Well at least Ian called me a Web fundamentalist in a RESTful way. I might use it in my e-mail signature, maybe he could include it in a reference for me too :-)
I think I might be one of Ian's Web Fundamentalists!
I will take it as a complement :-)
His defintion of fundamentalism is worth repeating:
Fundamentalism is a continuing historical phenomenon, characterized by a sense of embattled alienation in the midst of the surrounding culture, even where the culture may be nominally influenced by the adherents' religion. The term can also refer specifically to the belief that one's religious texts are infallible ...
Within in the Web community I guess that is a good way to catagorise the REST people: they think a lot of the Web is being done badly eg cookies and GETs with side effects. We also have our religious texts, which we think is infallible.
However Ian is mixing the MEST heads (aka POST everything through the one URL) with the REST people, and tarring them with the one brush. Sorry Ian, REST v MEST is a seperate battle ;-)
Unfortunately Ian doesn't 'get' REST. The unifrom interface is not just a set of HTTP methods, first HTTP is just protocol to which REST has been applied to the design of, not REST itself, and second the uniform interface goes beyond just operations; it includes things such as how you identify resources|objects|Grid services. Many of the ideas behind OGSI can be mapped to REST, it was just a question of
application. Ian your a RESTafarian, you just don't know it ;-)
In the end there is not much difference between OGSI, WS-RF and WS-RT; as if to illustrate the point people are even talking about using XSLT to create interoperability between WS-RF and WS-RT! There is not enough difference to waste all those years on anyway. In fact the point could be made that OGSI is better than WS-RF/WS-RT because it has support for identification which the others lack.
The whole stateful/stateless argument was a red herring. OGSI is a stateless protocol, just like HTTP and NFS. If you needed stateful interactions on top of OGSI you could compose with WS-Context, just like you can use cookies with HTTP.
Is REST the right approach to Grid computing? For some parts yes, for others no (Jabber is an interesting option that we have been playing with). REST is an architectural style for building a large scale distributed hyper-media system, where that overlaps with Grid computing it should be used, where it does not a different approach should be used. Would it be possible for a Grid architectural style? That is the huge challenge which I guess the OGSA group is facing.
For me, I have demonstrated that for RealityGrid a REST approach was better than the WSRF approach: Combining AJAX and WSRF for Web-browser based Grid clients. I have also demonstrated that REST can be used to solve
complex Grid problems like the co-allocation problem in a fault tolerant way that is beyond the fu
nctionality provided by the WS-* specs:
Co-Allocation, Fault Tolerance and Grid Computing, addressing the charge that it is only suitable for trivial problems.
Well at least Ian called me a Web fundamentalist in a RESTful way. I might use it in my e-mail signature, maybe he could include it in a reference for me too :-)
posted by Mark Mc Keown at 8:59 AM
0 Comments:
Post a Comment
<< Home