Experiences with WSRF
About a year ago, I was new to the world of Web Services (WS-*). I wasn't new to the world of the Web, although I can admit I hadn't read much literature about it (such as Architecture of the World Wide Web, Volume One or Roy Fielding's PhD dissertation). Being involved in Grid Computing, it seemed natural that I spent some time learning what WS-*, SOAP and the Web Service Resource Framework (WSRF) were.
I wanted to develop a system where I could represent tasks and queues of tasks independently of the actual location on which these tasks would be allocated and executed. Had I not been in a WS-* world, I would have used what I already knew: I would have served some XML (or perhaps even some plain text) dynamically over an HTTP server, probably using a combination of Apache+PHP+MySQL. But then I thought: "That's what I would have done at the time I used to program at home, based on various tutorials found in linux magazines. I'm a grown-up now; I should investigate these fancy WS-* stuff that promise wonders".
If one reads articles and books about Web Services, they sound really good. Having mechanisms that are both flexible and interoperable (including language independent, which I've always liked) sounds great. I bought "Web Services Platform Architectures" by Sanjiva Weerawarana et al. It's a good book and it gives a good overview of the whole thing. Then, I started to play with WSRF (using WSRF::Lite, but also experimenting with Apache WSRF).
WSRF::Lite was really good to develop a quick prototype of my application. The mapping of HTTP GET to GetResourcePropertyDocument (possible since WSRF::Lite uses URI-only EPRs) was great for debugging as well, since it was easy to see what the properties were using just a web browser. Since interoperability was what I was really after, I started developing clients in C (using gSOAP) and Java (using Axis' wsdl2java). Writing the right WSDL that would work with both turned out to be a bit of a pain, but it worked (Wireshark was a very useful tool for this). Most of this fiddling was about namespace issues and rpc vs. document style in WSDL/SOAP.
Benefits of WS tooling support
The pro-WS talks I was reading and hearing about were praising the tool support that Web Services had, but what were the benefits, really? As a developer, the main problem I face when designing an application is to find a programming model. On the one hand. what I was saying earlier about using simply Apache+PHP+MySQL+XML would have left me with the task writing some clients manually. On the other hand, tools like gSOAP and wsdl2java can provide you with stubs quite easily.
However, the resulting programming model is very much that of distributed objects (there's not that much difference between the way you program as stub-based WSDL client and the way you do it using RMI or CORBA), except that WS-Resources are distributed objects that have the magical property of going through firewalls. WSRF operations such as GetResourceProperty and their stub mappings return some XML infoset. The typing system of C and Java make it useful (and often necessary) to map such XML infosets to types known by the client applications. Both gSOAP and wsdl2java generate type structures from the XML schemas defined in a WSDL document, but it is still up to the programmer to handle more or less manually the mapping of those XML infosets. Fair enough, I don't argue with that. However, this leads me to wonder what the point of these tools is. Thinking back to what I knew before entering the world of WS-*, it doesn't really bring anything compared with what I would have done using something like XmlBeans on the client side.
Benefits of SOAP over HTTP+XML
''With SOAP, you can access Web services through loosely coupled infrastructure that provides significant resilience, scalability, and flexibility in deployment using different implementation technologies and network transports" (quote from S. Weerawarana's book). That sounds cool! I could use SOAP for having the same message abstraction over HTTP and e-mail for example?
In practice, the vast majority of the example I've seen were using SOAP over HTTP. I can understand the motivation for leaving the door open to protocols other than HTTP. It might indeed not be the best for all applications. But would SOAP really help for what HTTP cannot handle well? I doubt so. SOAP over HTTP uses exclusively HTTP POST, thus preventing the use of many cool features of HTTP, in particular caching. SOAP in an e-mail? Why not, but that's going to be a big e-mail. I was able to achieve the same thing about 10 years ago via HTTP to e-mail gateways. Same principle, except the the overhead of putting an HTTP header in an e-mail is probably less than that of putting the whole SOAP packaging.
Benefits of interoperability and standards
Interop. Really? Later on in the project, perl's total disrespect for the typing information related to remote entities and, more importantly, SOAP::Lite's complicated and often inconsistent handling of complex XML types made me want to trade my WSRF implementation for another. WSRF had become a 'standard' since then, so it shouldn't have been a problem. Ideally, I could have reused the WSDL for my WS-Resources in Apache WSRF (or any other for that matter). Sadly, it turned out that WSRF::Lite was using an rpc/literal style whereas Apache WSRF was using a document/literal style. This simply meant that I couldn't just rewrite the server, but that I had to rewrite the clients as well, since the stubs were now different too. All the time I spent fixing my WSDL: wasted!
I think the final drop was the move to WS-RT. I spent all that time reading the WSRF specs, experimenting with various WSRF implementations that were not really interoperable (I mean by this that I wanted to swap one for another). The thing becomes a standard, and it's made obsolete just after a few months.
Fed up with all this I decided to drop WSRF and to use an solution based on serving XML over HTTP. I took the time to read some of the REST literature as well. I developed a similar system using Servlets and XmlBeans in about 1/10th of the time spent on WSRF. The only features of WSRF that have been lost are the resource lifetime and the fault handling. Not a great loss as they were not that well defined or useful anyway. What I've learnt is that using technologies that were available 10 years ago (plus some more recent tools like XmlBeans), I was able to have a stable system, better than what I had using WSRF. This HTTP+XML based system is even more robust than the WSRF system I had; it makes use of idempotent properties of HTTP PUT for example, thus making it possible to recover from a message loss.
Before learning about these WS-* technologies, I was sceptical about their added value. Now I know. WSRF is just not worth it. I'd like to see a good use-case for using SOAP at all one day.