Thursday, November 23, 2006

A REST hall of shame...

More GET madness!
You might think I am looking for examples of the misuse of GET but they just keep appearing, and from Apache products too. This time it is Tomcat which can be managed, and even parts of it undeployed, with HTTP GET. Maybe there should be a REST hall of shame.

The GETs are ment to be used from scripts written by sys admins. In a universe far, far away Grid people are trying to solve this using WS-Management or WSDM, which without looking at either I can guarantuee are going to pretty complex. There must be some middle ground.

Wednesday, November 22, 2006

There is no reference implementation of WSRF

There is NO reference implementation of WSRF.
Reading this paper on co-allocation presented at SC06 I came across this:

We have implemented a prototype of the proposed system
as a set of cooperative Grid services using Globus Toolkit 4
(GT4) [Globus ], that is a reference implementation of WS-
Resource Framework [WSRF ],...


GT4 is not a reference implementation of WSRF, there is no reference implementation and GT4 is not WSRF compliant. The reviewers should have caught this.

Bruno Blogs

Bruno Blogs
Bruno from Manchester Computing has started bloging with a salvo at WSRF

Monday, November 20, 2006

The Lost Update and HTTP

The Lost Update and HTTP
This is a very good description of how to handle the "lost updates" problem when using HTTP. I have never understood etags until now: Editing the Web - Detecting the Lost Update Problem Using Unreserved Checkout. WS-RF and WS-RT of course do not have support for this, you would need to compose with WS-AtomicTransaction or WS-BA.

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 :-)

Axis2: This Ain't REST

This Ain't REST
I have been playing around with Axis2 to create some sample services for the Taverna people to chew on when I looked closer at the "REST support"....


Running the Client
==================
- From your browser, If you point to the following URL:
http://localhost:8080/axis2/rest/StockQuoteService/getPrice?symbol=IBM

You will get the following response:
42.0

- If you invoke the update method like so:
http://localhost:8080/axis2/rest/StockQuoteService/update?symbol=IBM&price=100

And then execute the first getPrice url. You can see that the price got updated.


So you use GET to update the price! I think not. GET is safe, it should have no
side effects. This is bad because it is a toolkit advocating an approach, and
to think that it comes from the Apache foundation.

Beta Thoughts

Taverna Meeting
Had a good meeting with June and some of the developers of Taverna to discuss security and the requirements. They are keen to improve support for security within Taverna but will be doing it on a case by case basis, ie you provide a service that uses some form of security and they will add support for it to Taverna.

I will create a service that uses HTTPS with mutual authenication and WS-Addressing EPRs and see if the Taverna guys can connect to it. Maybe later decorate the WSDL with some WS-SecurityPolicy.

Friday, November 10, 2006

Three weeks down, two to go....

Three weeks down, two to go

Elise as completed her third week of radiotherapy! The time has flown by so fast it is hard to believe, only two more weeks to go. She has had no side effects yet: skin damage, bowel problems, eating problems nor tiredness, which is great. And to think how worried we were at the start...

Preview doesn' work too good...

Beta Thoughts
Mmmh, looking at my last post it seems the preview doesn't work too well. Must find something better...

Taverna and Security

What does Taverna need to support security?

Read over 200 pages of WS-* specs to try and understand what is required for Taverna to support security. The horror, the horror.

Taverna is a workflow tool that came out of the MyGrid project that
has got a lot of good press. We are thinking about using it for the NanoCMOS project. Unfortunately Taverna doesn't do security, and we have a strong requirement for security; the good news is that they are working on it!

Downloaded and played with Taverna, and it looks pretty good.
Noticed that many of the services for which Taverna is pre-configured have lots of get* type operations. We need one GET to rule them all!

I have been asked to look into what is needed by Taverna to support
security given my experience implementing WS-Security for Perl.
Beyond support for WS-Security, WS-SecureConversation and HTTPS it looks like the following specs are important:

WS-Addressing (signed SOAP Headers for end-2-end security, also
policy can be stuck in the  meta-data of the WS-Addressing EPRs),

WS-Policy and WS-SecurityPolicy(the language for declaring security policy, I thought this was pretty cool as it included support for saying things like "I want mutual authentication over HTTPS" etc.),

WS-PolicyAttachments
(were you find policy, for example tells you how to extend WSDL to include policy)

WS-MetaDataExchange (policy can be found and retrieved using WS-MEX, unfortunate dependence on WS-RT which is getting a rough reception at the W3C).


Of course WS-SecurityPolicy had no support for declaring policy with
respect to Proxy certificates, more work for the OGF then. Other specs that may have an impact, but which I haven't looked at are
SAML, WS-Trust, and I am sure there are others.


If all this stuff worked and the tools consumed it with eash then it would be pretty powerful stuff, big if though.

Globus GT 4.0.3 Not WSRF compliant!

Downloaded Globus GT4.0.3 to evaluate it for the NanoCMOS project. Unfortunately it uses really old versions of the WSRF and WS-Addressing specifications. This means that GT 4.0.3. is not WSRF compliant. It also means that services developed with GT 4.0.3 are not WSRF compliant either!

I asked when it would become compliant, but have got no response yet.

I cannot recommend that we use GT4 until we know what its timelines are. Once it does become compliant there is a strong chance older versions will not interoperate, making existing code and services obselete. Also many other WS-* tools are using the correct version of WS-Addressing, so they won't play nicely with GT4.