Having been involved in the "REST vs Web services" debate for quite a while, I've steadfastly believed that a "Generic"-only or a "No Generic" operation architecture isn't the "right" and "only" way. WS-Transfer and WS-ResourceFramework are great ways to bridge the gap between two very different architecture styles. As Don says, "Why would I ever author another WSDL PortType".
Reads and Writes
To answer, any distributed architecture has to deal with 2 primary types of operations: Reading things and Writing things. When doing either of these two types of operations, an architecture typically uses either generic operations (ala REST/WS-Transfer) or specific operations (much of Web services).
My belief is that most customers need an architecture that combines both generic and specific operations. Read operations using a generic protocol (ie GET) hits the 90/10 point. In the Write operation case, it's a little more difficult. In many cases, the thing being accessed is what WebDAV calls a "dead" property, where there are no side-effects of it being written. In these cases, a generic "Create/Delete/Update" works well. Where the thing being accessed is a "live" property, that is it has side-effects, then a thing specific "Create/Delete/Update" operations are needed.
Let's take an example, a time-out property of a resource. WS-ResourceFramework correctly allows reads using the generic "getProperty" operations. It also correctly does not provide a "setProperty" operation on the time-out value, rather it provides a "setTimeout" operation.
If the timeout was done as a "setProperty", then it could be set as part of a multi-property set operation. The problem is that the time-out value could be an invalid value, or unacceptable. In which case, the multi-property set will fail, and the other properties will be in an undetermined state. Did they get set or not? The client will have to troll through property specific result codes to figure out each properties result. In which case, it's an operation specific return and it's roughly "lied" about it's ability to compose with other properties!
This is an example of a fine grained control flow that is not appropriate for generic operations. But let's take a look at the flip side, that generic read.
I believe a main reason for "generic" operations is for loose coupling, particularly extensibility and versioning. In previous lives, I've regularly deployed enterprise systems that had "specific" operation middle-tiers. A good example is integrating a large entrprise system with another system. The problem with "specific" operation middle-tiers is that they are incredibly brittle. If there's a property that isn't available from the middle-tier, a new set of "get/set" operations have to be written. For performance reasons, you invariably need to do complex reads across business objects, so you need to provide for "pushing" the complex reads into the business objects. SQL Join statements are a classic way of dealing with performance, and the same is needed for middle-tiers.
Imagine that I've got my business object layer that knows about .... oh let's imagine something... Names that have First and Last names. If I add a Middle name and I want to allow a query for it, in a "specific" interface I need to add findName operations for each of the combinations of Names that I allow - or I make a generic findName operation, ie findName(first,last); findName(first, middle,last); findName(prefix,first,middle,last); etc.
Generic Reads AND Specific Writes
What would be *really* great is if we could provide a Web service middle tier that allowed generic read operations that were easy to evolve in addition to the current specific operation architecture style. I could add a Middle into my schema, and then the query operations don't change! This is what I mean about evolvability of the interface and why a generic interface is required. I wrote about this in WebXQuery
I followed through on the first action item as I tried to get some of this into the WSDL 2.0 HTTP binding, but I wasn't very successful. My experiements in using WSDL 2.0 to describe a generic interface (a Music service) showed that the current structure of WSDL 2.0 optimizes for custom operations across a few URIs, and doesn't optimize for generic operations across a complex URI space that is defined by a schema. I boldly predict that these limitations will hinder the adoption of WSDL 2.0 to describe generic HTTP interactions.
The current transfer mechanisms - WS-Transfer and WS-ResourceFramework - are better as they define the property space based upon a schema, but they are very limited or don't specify how the queries on the properties can evolve. For example, WS-RF allows me to add a property (foo) into a resource and then I can do a "getProperty(foo)". But modelling the world as a set of flat properties effectively destroys XML and the Web's hierarchical structures. We still need full featured query operations, ala SQL/XQuery.
What's missing from the debate is the discussion is the properties of the distributed systems we are deploying and have deployed. One propertyis evolvability, that is what has to be changed and what components will break when an interface is extended or versioned. I wish the REST folks would admit that generic updates have limitations, and the "specific operation" folks would admit that evolvability of interfaces could be *a lot* easier.
Another couple properties are performance and re-use of existing infrastructure. It that would be good from a Web services perspective is if generic Web service interactions (like WS-Transfer) had a binding that made full utilization of HTTP. It certainly easier to get performance improvements by caching HTTP representations now rather than waiting for the deployment of EndpointReference caches (which will have specify how to canonicalize an XML structure for cache comparison). WS-MetadataExchange has bare-bones support for this with the scheme specific dereferencing operation when a MetadataSection contains a Location. But there's much more work to be done.
We've work to do, but I'm hopeful that we are moving towards a future round of Web services specs will combine generic and specific operations in a more evolvable and performant architecture. The publication of WS-Transfer shows that the Web service architecture understands the problems of evolvability in deploying large numbers of operations. The downside is that it takes time as people often redo the mistakes of earlier systems and customers pay the price.