Services: A Broader View

For all of the current focus, hype, and coverage of the minutiae of the heavyweight WS-* stack, I feel at times as if I’m one of the only people in the industry that thinks of Gmail (or Hotmail, or Yahoo Mail, for that matter) as a service (that’s delivered and accessed over the web). Of course that’s nonsense – it’s clear that Bosworth, at least, sees service as a broader descriptive term, as I discuss here, as does Tim Bray, and many other intelligent individuals. But I can hardly be blamed for thinking this way, given that nearly every conversation I have with the media, or even enterprises, conflates services and Web services into a narrow definition of an application function exposed via SOAP/WSDL/(and infrequently, UDDI)/etc. I just don’t see it that way.

Now I may not go as far as Bray does in decrying the formal stack [1], because I do think that in certain settings (e.g., enterprise to enterprise) the WS-* stack has a useful role to play, but I am at least mildly irked by the fact that services has come to mean – in many contexts – Web services, and the stack that implies. That myopic focus on the quote unquote formal stack to the exclusion of more generalized (and yet – typically – more popular) web services, seems to me immensely shortsighted. Tim Bray gives the best evidence as to why:

I look at Google and Amazon and EBay and Salesforce and see them doing tens of millions of transactions a day involving pumping XML back and forth over HTTP, and I can’t help noticing that they don’t seem to need much WS-apparatus.

As far as I’m concerned, web based email is as legitimate a web service as anything the WS-* stack has to offer.

I do recognize, of course, that comparing GMail to the WS-I Basic Profile, as an example, is an exercise of limited utility. Ok, no utility. But that’s not the level of conversation I’m talking about here. I’m talking about the high level conversations we have with organizations that are trying to determine how a services-based approach fits within their enterprise planning. At that level, I think the WS-* stack should be just one approach among many.

If one takes a broader view of what a service is, it seems clear to me that many organizations have been implementing small scale SOAs for years. The exposure of mainframe applications via a portal interface is one common scenario – there are many others.

Why is this definition important? Well, because if we as analysts, media, and vendors continue to espouse differing (broad vs narrow) definitions of what constitutes a legitimate service, we run the risk of enterprise confusion. And more importantly – from a vendor perspective anyhow, that may impact adoption. I might argue that it already has, but don’t have the time to dig up evidence for that at the moment.

Anyhow, I (I won’t put words in my colleague’s mouth here) believe in a broad definition of services, and indeed this underpins our COA concept. In that piece, I made some rather radical – even heretical – arguments about services. More specifically, I make the case that a data warehouse, at some level, is simply a collection of services to be consumed. It provides retention (among other things), and I argue that that functionality can be exposed horizontally within an organization as a service.

But even if you think that’s going too far, and that it blurs the definition of service to the point of uselessness, I urge you to take a long look at your own definition with an eye towards revision. Because if we as an industry can move towards a Bosworth-style definition of a service, we can begin to ponder all sorts of interest composite applications composed of formal and informal services, internal and external, WS-* and otherwise. And that would be pretty interesting.

Update: Speaking of my notion of data warehousing of the service, see the feedback my colleague got from the DSS vendor WhiteCross.

=====================

[1] “No matter how hard I try, I still think the WS-* stack is bloated, opaque, and insanely complex. I think it’s going to be hard to understand, hard to implement, hard to interoperate, and hard to secure.” (link)