Distributed Matter - Blog

To content | To menu | To search

Friday, July 27 2007

A look at WS-Notification

I'm having a look at the WS-Notification (WS-BaseNotification 1.3 OASIS Standard). I usually find reading some of these specs laborious (and little rewarding), but I'm trying to put some good will towards Web Services (in the WS-* specifications sense). However, shortly after beginning, I found a few caveats that would probably make it difficult for all compliant implementations to interoperate.

Here is an excerpt of the introduction to Section 3 (the NotificationConsumer interface):

WS-BaseNotification allows a NotificationConsumer to receive a Notification in one of two forms:
1. The NotificationConsumer MAY simply receive the “raw” Notification (i.e. the application-specific content).
2. The NotificationConsumer MAY receive the Notification data as a Notify message as described below.
[...]
When a Subscriber sends a Subscribe request message, it indicates which form of Notification is required (the raw Notification, or the Notify Message). The NotificationProducer MUST observe this component of the Subscription and use the form that has been requested, if it is able. If it does not support the form requested, it MUST fault.

At a first glance, a NotificationConsumer (i.e. the recipient of the notification) can be compliant with the WS-Notification standard so long as it can receive the message, whether-or-not it complies with the format described in the following pages. There are subsequent mentions of the raw format, but its use seems to imply the use of SOAP (in a context that uses MAYs and SHOULDs).

Later on, in Section 4.2 (NotificationProducer/Subscribe):

The NotificationProducer should specify via WSDL, policy assertions, meta-data or by some other means, the information it expects to be present in a ConsumerReference. If a ConsumerReference does not contain sufficient information, the NotificationProducer MAY choose to fault or it MAY choose to use out of band mechanisms to obtain the required information.

In addition, WS-Notification relies on WSRF (which more or less re-invents HTTP-based resources, but that's another story). The WSRF specification defines a set of accessors to get and set resource properties, but leaves the door open regarding how these should behave, especially when setting multiple properties in one request. Fair enough, HTTP leaves this responsibility to the applications that use it too. Interestingly, though, WS-Notification doesn't say much either about what should happen when using SetResourceProperties.

To sum this up, I think the core concepts of NotificationConsumer, NotificationProducer, etc. are sound, but the two excerpts produced above make me doubt it can actually achieve some sort of interoperability. It almost sounds like "do what you want so long as you use SOAP and WS-Addressing". I'm yet to be convinced that these two add any value for achieving the goals of Web Services (SOAP for security, maybe?).

Wednesday, November 22 2006

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!

Conclusions

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.