Expert Takes a Stab at Defining Services

Remember a while back when it seemed the experts couldn't agree on a definition of a service -- that basic building block for Service-Oriented Architecture?

David Linthicum, SOA guru and now CEO of StrikeIron, took a stab at straightening out the problem late last week in an ebizQ article aptly titled, "So What the Heck is a Service Anyway?" You'll need to register as a Gold Member -- which is free -- to read the article.

As I've said before, a standard definition for services would be a good way for SOA to gain a bit of credibility among the non-converts. Apparently, I'm not the only one puzzled by this lack of a definition, since Linthicum writes that he's been asked to define services a lot of late.

He contends the question shouldn't just be "what is a service," but rather, "What is a service and how does it differ from information?"

He offers an answer, even if its something of a circular definition and not as simple as one would have hoped:

"When using a service, we leverage a remote method or behavior versus simply extracting or publishing information to a remote system. Moreover, we typically abstract this remote service into another application -- known as a composite application -- that is typically made up of more than one service."

He offers examples of services, but to me, the most concise, easy-to-understand explanation he gives is when he says programmers can construe an application service as subroutines or methods. In other words, services are "something you invoke to make something happen," he writes.

He differentiates this from information, saying "we leverage the behavior of this remote service more than the information it produces or consumes."

Possibly it's because I've had more training in programming than any other aspect of IT, but this explanation makes sense to me. It also helps explain why SOA can increase agility.

The question is whether others will agree. As I've said before, when SOA's explained by one person, it tends to make sense. The problem is the industry's inability to reach a consensus on what is and isn't SOA.

Still, this explanation does tend to raise the old question about whether SOA is really anything other than another term for object-oriented programming. Linthicum addresses this question, too, noting that objects are one of the four "functional primatives" into which you can break services. The others are Rules, Logic and Data.

He explains how objects differ from services:

"Objects are simply data and business services bound as objects. They are bundles of data encapsulated inside an object and surrounded by application services that act upon that data."

He discusses how objects function within SOA in more depth. In particular, what struck me is that objects are more tightly coupled than services, which, in turn, makes objects more difficult to use in integration.

It'll be interesting to see whether this lengthy and detailed article generates more debate over the meaning of services.

Maybe you're confident that you understand services enough to move forward with SOA, but, like the Marines, you're feeling a bit insecure about your progress. Maybe you're wondering how you're doing compared to others in your industry.

If that describes you, then consider signing up for "Are You Service-Oriented?," a free webinar at ebizQ Tuesday, April 29. It starts at 12 p.m., ET and features Christian Hastedt Marckwardt, Solution Marketing Director for SAP, and Joe McKendrick, ZDNet blogger and contributing editor and research consultant at ebizQ. Marchwardt and McKendrick will discuss the recent results of an ebizQ survey on SOA and governance practices.

You'll learn how far along other companies are in SOA adoption, how they're managing the SOA environment and the types of SOA governance companies are using.

It's free, but you'll need to register, which, again, requires a free Gold membership to the site.