Sometimes I wonder whether the web services model hasn't overreached itself in certain ways. As defined by WS-I Basic Profile, the WS-* stack, or just plain old SOAP, have we constructed a model of intermediation that does what we really need? In a world where most systems benefit hugely from being connected together, did we get things right when we started web services off?
Like n-tier architectures, and client server before it, the focus of the early web services revolution was really about getting away from the faults of the previous generation of approaches, in this case a focus on client-side distributing computing APIs like CORBA and DCOM. Much about early web services thinking may have been more about fixing flaws from the previous technology generation than it really was about building a services model that was fundamentally service-oriented.
And when I say service-oriented, I mean services that are designed from the beginning to be easily consumed, crisply and cleanly defined, and agnostic in terms of technology details like protocol, transport, or location. Web services as defined today can be all of these things, but not necessarily all at the same time.
Services that are service-oriented foster something called intermediation. Intermediation allows entities that would normally have no means of collaborating to do so easily, consistently, and robustly, even as their details change over time. Aspects of a service model that cause brittleness and make intermediation tenuous, precarious, or unreliable, are just not service-oriented. In this light, does the WS-* view of web services provide a good solution to intermediation?
Figure 1: The weighty WS-* stack imposes serious interoperability and implementation challenges
To answer that, we have to step back and ask what elements make communication between services clear, easy, yet robust? In many ways, it's the same argument that has been made recently about the evolution of computer languages. Simplicity is everything. After that, pre-designed extensibility mechanisms makes it possible to solve new problems in a well-defined way. In other words, since you can't predict how needs will change, make it small to begin with, but with plans to grow.
Recently I've been working with the details of WS-Policy, including the particulars of how to specify policy, the many complicated rules for elements, child elements, and how to put policy assertions into a contract (which is not standardized), and it gave me an insight into the issue. It's a classic Cathedral and Bazaar situation. The problem is that many of the additions to the web services stack are things that could only be loved by Cathedral builders, and are in fact Cathedrals, by virtue of their standards-body definition. Cathedral builders are the trusted central planners that try to anticipate what people need and build it from a single authority. Bazaars on the other hand are bustling marketplaces where one can pick up whatever one needs.
In my mind, it goes back to why agile methodologies work so much better than traditional ones. Letting the right ideas emerge from a series of rapid trial and errors (and not being afraid to throw a few away), and letting the right solution emerge out of real experience and the best mix of design decisions.
In this competitive way, REST has been giving SOAP a run for its money since it is the most inclusive of all web services models. But REST has an Achille's heel in that it may be the simplest, most straighforward approach, but it has no extensibility model. And to SOAP's great credit, the actual SOAP standard does not feel like the product of the Cathedral builders, and has the crucial elements of success: relative simplicity and terrific extendability potential.
It's easy to see the motivation with the endless layers of standards in the current WS-* stack though. Of course system designers want real security, predictably they'll want transactions and declarative policy, naturally they'll desire reliability, routing, orchestration, etc. And in order to have interoperability, these features must be standardized.
The problem is that these solutions aren't being driven by real experiences with service-orientation, or what Jon Udell likes to call "pervasive intermediation". Unfortunately, given the deft touch required to attain these goals, they need to be driven by success in the Bazaar after much experience, not imposed by the Cathedral builders. The permutations and number of axes imposed by combining the pieces of WS-* just does not foster good intermediation (at least based on my definition above), though some will probably disagree.
The trend that may cripple the full WS-* view of the world is the fact that we're probably in the twilight of monolithic development toolkits. With the rapid proliferation of alternative platforms, languages, and IDEs, the likelihood that a local toolkit will be able to support a particular Cathedral-like web services stack is slim. The chances are good however that service-oriented solutions from the bazaar will be available, the pieces carefully and precisely whittled down by the vagaries of hard-won experience to be easy to use and integrate. As Quoderat recently posted, Problem-First Design is likely the right answer.
Technorati: Enterprise Architecture, Computers and Internet, Programming, Web Services