"> mnot’s blog: The ‘Web’ in Web Services

mnot’s blog

Design depends largely on constraints.” — Charles Eames

Monday, 27 September 2004

The ‘Web’ in Web Services

I was very interested to see the reaction to WS-Transfer [PDF] over the last few days. While the SOAP Resource Representation Header had opprobrium heaped upon it (see previous discussion), Transfer passed by with nothing more than a few nodding heads and people saying “aha.”

That doesn’t make much sense to me; if anything, the Resource Representation Header tries to supplant MIME, not HTTP. Transfer, on the other hand, duplicates the semantics of HTTP in Web services.

Why would somebody want to do that?

As many have pointed out, Transfer seems like it’s a lot more trouble than it’s worth; running WS-Transfer on top of SOAP using XML on top of HTTP to get back to where you started wastes a lot of processor and bits on the wire. However, there are two areas that Web services have an advantage in — tool support and description — that might drive people towards Transfer.

Tool Support

The promise of Web services has always been that you’ll be able to pull some software tools out of the box and get full-functioned interoperability from the get go. That’s still pretty far away, but in the meantime, the tools are able to do a lot of cool things to make developers’ lives easier; just look at the newest from [insert major vendor of choice here] and you’ll see that it’s pretty much drag-and-drop, self-managing code that anybody can use.

This is the raison d’etre for Web services; the whole idea is to enable US$40,000-a-year programmers to design and implement their own network protocols. The tools make it possible to do that, guiding them down the right paths, and stopping them from doing stupid things (most of the time).

Contrast this with the state of the art in HTTP programming; the Java Servlet. Very developer-unfriendly, it encourages bad practice, by dispatching to the method instead of the URI. It’s so bad, in fact, that there is a huge variety of frameworks built on top of it, to hide it — and HTTP — from the developer. As a result, it’s difficult to use HTTP as a protocol if you’re not using it for serving HTML pages and forms (this has been discussed previously).

Furthermore, many (if not most) Web client and server libraries are deficient to brain dead when it comes to HTTP feature support. Whether it’s authentication, content-codings or caching, it’s difficult to configure them, and when you get them set up, the details usually aren’t implemented well (again, not exactly a new topic of discussion).

All of this makes it easy to understand why a novice (or even not-so-novice) developer will run screaming into the nice, safe, self-contained arms of an IDE that lets you build Web services.

Now, if tools can be built to make Web services easy, there’s no reason that usable, friendly tools for HTTP can’t be built as well. In fact, HTTP has an advantage; it’s already widely-deployed and proven.

Also, for Web services tools to offer a really good Transfer experience, they’ll need to be extended, because the basic abstraction of Web services using Transfer isn’t messages, it’s stateful resources.

Description

The other thing that supposedly differentiates Web services is the ability to describe a service, using WSDL. This is useful for configuring the tools, generating some code stubs, as well as for visualizing and agreeing upon the interactions that will take place.

There is no widely-recognized facility for the plain old Web (POW? Hmm), although I’ve mused on it before. That might be OK; upon closer examination, I don’t think the Web falls too far behind Web services here, because WSDL can’t describe stateful resources that well anyway.

How’s that? The Web, and specifically REST, thrives on identifiers; everything that’s interesting has its own URI. In WSDL, this is the “endpoint identifier,” and it’s a pretty sad thing; many Web services people go explicitly out of their way to avoid creating new endpoints. The Web, on the other hand, is all about having lots of endpoints, so that you can interact with anything that’s interesting using generic methods like GET, POST, PUT and DELETE.

WSDL doesn’t encourage this; each and every endpoint has to have its own binding, with its own concrete information about serializing the messages on the wire. When you’re putting a lot of application semantics into the methods, this isn’t a big deal, because you have one endpoint with a bunch of methods. However, when you want lots of endpoints with a few methods each, WSDL gets impractical and unmanageable pretty quickly.

A description format for Web resources would still be useful, but WSDL — as it sits today — isn’t that format. Previously, I’ve explored what would be a good description format, and it’s clear that there are lots of options, from something brand new to URISpace to extending WSDL with a new kind of Web-friendly binding.

I’m not yet sure what the best option is, but I’m building tools that will work with such a format, so I need something. My first thought is to leverage WSDL, but I wonder what the benefit of doing that is if no existing tools will support what I’m doing. It might be better to start fresh and come up with something optimal for the task, rather than trying to shove it into something designed for RPC and SOA.


Filed under: Web Web Services

2 Comments

Savas Parastatidis said:

Hey Mark,

This is an interesting post. Thanks! Here are few comments/questions...

Why treat "stateful resources" the same way as services? "Tooling" I hear some saying. But I don't feel this is a good enough reason.

On the Web, every resource has its own URI, that's true. But on the web, when a resource no longer exists in that location you get a 404 error. Humans can cope with that but for automated, machine-to-machine communication that doesn't say much.

Why not treat resources in the same way the world is modelled around us? You go to a bank and you talk _about_ your account, not _to_ your account. You go to a travel agent and you talk _about_ your booking and not _to_ your booking.

In a similar way (see Pat Helland's recent architecture paper), stateful resources could be given a name outside a service's boundaries. That name could be used in interactions with the service, rather than itself being a recipient of messages.

Furthermore, why do you suggest that Web Services have "methods"? I personally see Web Services as entities with which we can exchange messages rather than "callable" entities. A "method call" is usually associated with "request/response" semantics.

Some more comments on WS-Transfer...
http://savas.parastatidis.name/2004/09/17/7643978e-df83-45c3-89c4-988864f9ef24.aspx
.savas.

Tuesday, September 28 2004 at 3:30 AM +10:00

Mark Baker said:

I dunno, I thought I slagged it reasonably vociferously. 8-) It is, of course, a steaming pile of poo, but I didn't want to be too harsh in case folks missed the opportunity for enlightenment; that "Get" on an EPR is isomorphic to "GET" on a URI.

I also disagree that WS-Transfer "get[s] back to where you started". It doesn't, it's set you way back from where HTTP is today, both architecturally (no streaming, self-description problems, little or no standardized headers ... in fact, it's a lot like HTTP 1.0), and with respect to deployed infrastructure (doesn't work with existing intermediaries such as caches, firewalls, transcoders, etc..).

Regarding description, I still think you're bettter off with a forms language rather than a service/interface description language, since the former describes what is largely dynamic (state machine) rather than what is largely static (interface). That's why I developed RDF Forms. If there is a use case for interface description that I'm not familiar with, I'd much rather it be addressed as a special case with a forms language, rather than other way around.

Tuesday, September 28 2004 at 6:42 AM +10:00

Creative Commons