mark nottingham

Is there a Web Services Architecture?

Wednesday, 29 September 2004

Web Services

As I’m sure many others were, I was intrigued to see that Microsoft published their idea of an Introduction to the Web Services Architecture and Its Specifications the other week.

What struck me more than anything was that it’s long on specifications and short on architecture. This isn’t a view that’s specific to Microsoft, either; when you step back and look at Web services as a whole, it’s hard to pin down many architectural principals at all.

In his thesis, Roy Fielding points out:

A software architecture is defined by a configuration of architectural elements — components, connectors, and data — constrained in their relationships in order to achieve a desired set of architectural properties.

If Web services is a bag of specifications that only constrain you by accident (“it must be XML,” “it’s message-based,” “the basic unit of interaction is the ‘operation’”) then Web services has no architecture, at least in this sense of software architecture*; it’s just flinging messages around.

To stretch the metaphor, Web services gives you bricks and mortar and steel and glass, but no plans or guidelines on how to build something that will be functional and last; it’s up to you as to what you do with them. SOAP really is just a protocol construction toolkit. If Web services has an architecture of its own, it’s just the tool manufacturers’ design plans for the saws, screwdrivers and drills that they sell — things that their users can be safely and completely ignorant of.

In other words, while Web services might have an internally-focused “architecture” that’s of interest to the few people writing the specs, from a user / application standpoint, you can design an architecture that includes Web services, but it doesn’t bring its own along. So, telling end users about the Web services architecture isn’t doing them too much good, to be honest.

Of course, this isn’t to say that you can’t impose an architectural style on top of Web services, which is what many people are trying to do. That’s a different thing entirely, and it can help end users create successful applications.

The front-runner in most peoples’ minds is Service Oriented Architecture, or SOA. This isn’t exactly a new concept, but it’s revolutionary to some. What’s interesting is that there isn’t really a good definition of what SOA is out there yet; while we have SOA blueprints (interesting stretch of the metaphor!) we don’t yet have an agreed-upon, well-documented definition of the principles that they’re drawn to (DavidO had a go a while back, but it didn’t catch on).

Another architectural style that’s very popular with some Web services folks is Remote Procedure Call or RPC. This is really just a sort of a client/server style; it’s very tightly coupled, which most people agree is a Bad Thing, in most situations.

Others are trying to impose the Representational State Transfer, or REST, architectural style on top of Web services. This topic is worth at least one completely separate essay, so I’ll avoid the details for now.

What I’m wondering about now is how the architectural style that’s imposed upon Web services affects the toolkits that attempt to make them usable; I can only imagine that using the same APIs for SOA and REST would be sub-optimal, and that we’re likely to see differentiation there.

It also gets interesting when you consider the effects of the WS-* specs; there are some that obviously impose an architecture (or a style) when they’re in use, like WS-Transfer, WS-Enumeration and UDDI. Then there are tricker ones like WSDL; although it doesn’t impose a particular architectural style, it certainly was designed with certain things in mind, so it encourages some and discourages others. Are there other specs with latent architectural styles? Which ones have styles that are at cross purposes?

At any rate, I’ve come to think that “Web services architecture” is a misleading phrase; of course, it’s just words, and we all know that words’ usage changes their meaning, but I think this use confuses the issues more than it clarifies them, much in the same what that calling everything a “protocol” does. What does everyone else think?

• To be precise, it doesn’t impose an architectural style. However, this is a distinction that’s lost on most people, and I think the greater point remains; Web services, in and of itself, doesn’t bring much in the way of constraints to the table.