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?


mike julier said:

I don’t think of the WS-* specs as an architecture in the sense that I think you are using the word. I think of it more like the x86 ISA (Instruction Set Architecture) which I claim is a SW architecture. The x86 ISA does not constrain developers, but rather defines an existing set of state and functionality which the developer can utilize in nearly limitless configurations (apps/solutions). I think it may have been Don B who pointed out that the WS-* specs are composable. In essence allowing each developer to construct the specific communications channel desired for each specific solution/app.

You use words like “constrain” and “impose”. I prefer architectures that “liberate” and “enable”. I also like puppy dogs, long walks on the beach, pina coladas, and … oh wait… sorry.

While I am not certain that there is in fact a coherent architecture to WS-* space and tend to not expect to find one, I hope that one can be evolved from what already exists and that the result can have the longevity of x86. I don’t hope that it places limitations on developers or users; only that it be self consistent, self obvious, and enable massive amounts of innovation.

Wednesday, September 29 2004 at 5:52 AM

Mark Baker said:

Mike, constraints do enable. Really, have a good read (or two or three) of the first section of Roy’s dissertation, linked by Mark.

Mark - nice.

Wednesday, September 29 2004 at 7:52 AM

Paul Sumner Downey said:

Something i’ve voiced for some time now is what use are all of these proprietary specs if: (a) they don’t interoperate and (b) there are no strong patterns of use.

(a) in no small way depends upon (b).

It’s useful to contrast the success of Wintel with Web services and remember it wasn’t the x86 alone that made the PC popular, but its use inside a working interoperable and evolvable product.

Thursday, September 30 2004 at 1:00 AM