Just What is a Service?

Last November, I expressed some frustration with the generally accepted (in the media, anyway) meaning of the term “service.” The view of a service as something defined and delimited by the boundaries of SOAP, WS-* and so forth was something I saw as not only artificially limiting, but blind to the realities of a world increasingly driven by services over a variety of protocols. This certainly was not the only missive in my campaign to blur the conventional wisdom of what constitued a service: underlying publications like the COA and pleas on behalf of the developer community, it’s been a common theme in these parts.

Fast forward eight months, and what has changed? Very little. Vendors still tout their abilities to generate WSDL for services to be piped from one machine to another via SOAP, which although eminently appopriate in some settings, are just as inappropriate in others. Very little attention is given to non WS-* approaches. To give credit where credit is due, however, Microsoft seems to be not only hearing the call for less heavyweight services, but answering it as well. Whether the support for REST within the Indigo stack is new as Dare implies or has been there all along, as Don Box asserts, it amounts to the same thing: Microsoft is ensuring that web service developers have a choice in what kinds of services they develop, and how they assemble them. This is what I’ve been stressing to vendors all along; it’s about choice, and if you don’t provide that choice developers will route around you. Sometimes the best choice will be the heavyweight stack, but sometimes it won’t. Kudos to Microsoft for recognizing that – this is an excellent move, IMO.

But I still think the definition of what is a service can and should be pushed further, and I was reminded of this while speaking with Michael Baum of Splunk yesterday. For those unfamiliar with these guys, they were written up by BusinessWeek’s Steve Hamm here and essentially are turning search engine like technology loose on the myriad forms and high volume of log files generated in the modern datacenter – or even the modern small home or office network. It’s an interesting concept, and one I find tremendously appealing not least because it seems eminently positionable as a drop in service, akin to what we’ve discussed with our COA Core Services. While there are a variety of ways Splunk can consume data, one approach is simply to setup a cron that drops log files onto the Splunk server. What could be simpler? No installation of agents, listeners, daemons or otherwise – just a simple log transport. Even better, the Splunk folks have done a good job of not only providing the means for third parties and individual developers to create additions and extensions to their platform, but to contibute these back to a common community (go figure – an ISV gets that it’s about community ;).

To me, Splunk’s log traversal and distillation is a service just as identity is a horizontal service used by applications all over the enterprise to provide a singular function (and as such might be very closely aligned with Aspect oriented logging, but that’s another matter). Whether or not it should be positioned that way depends on whether or not you (or your customers) believe in broader notions of services or prefer the WS-* definition, but I’d certainly give it some thought.