Just What is a Service?

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

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.


  1. I share your frustration when it comes to service – but from a slightly different point of view, which has less to do with WS-*, REST, POX and the like and more to do with different perspectives on services. The vast majority of the service – and SOA for that matter – discussion focusses on a subset of IT services: business function services. What about infrastructure services, which encompass the identity management and log file search examples you refer to, and the lifecycle services which are responsible for the development, deployment and change of the business function and infrastructure services (and which are what users of IT tend to think of when they invest in IT)? A service-oriented approach to IT must consider all of these perspectives – and the functional, quality-of-service and commercial aspects of the contracts which govern their usage.

  2. Hey Steve…I'm with you. As you know, I speak to/write of "services" a lot, and I never get to "Web Services" until I'm 4 pages in…Because that's (dare I say) just an implementation technology. Here's a "report" of mine that's being excerpted, and you'll see technology didn't even land in part 1. http://www.nextslm.org/michelson1.shtml.

    I also agree with the sentiments of Neil who commented above…services do infrastructure functions (jobs). In addition, service-oriented architectural practices should be applied not just to business solutions, but also to infrastructure solutions…something shown in the recent JBI spec (JSR-208).

  3. Neil: in total agreement. i've been pushing enterprises and vendors i speak with on similar matters for a long time now, with little success. when i give my standard "identity is a service" pitch, i usually get some perplexed looks with a few nods. ah well, one thing at a time, i suppose 😉

    Brenda: i'm certainly aware of that ;), and thx for the link – good piece. i think you highlight is an important point, which to me is expressed as the notion that services ultimately are nothing more than the approach. technology is the means to that end, but there are a variety of such means. unfortunately, the definition of services has been coopted by certain parties, but if we all do our best maybe we can change a mind here or there 😉

Leave a Reply

Your email address will not be published. Required fields are marked *