I have watched this debate unfold at every client site I have visited in the past few years. There are several angles to this question. From a technical stand point, a service is a program that takes some type of input, performs a task, and return some type of output. This is vague. It can describe any number of things. From an implementation standpoint, a service could be a SOAP Web Service, REST Web Service, a Java Servlet that takes an XML request and returns an XML response, an EJB, an RPC program, DCOM, Cobol program running in CICS, CORBA service, etc. There are many, many examples of services running around the Internet today.
As the Internet & World Wide Web grew (along with the HTTP protocol), there were any number of implementations of the same basic theme: an input message passed via an HTTP Post, some processing on a Web Server, and a response return via an HTTP response. This is probably the earliest form of web service.
As the 1990s came to a close, work was underway introducing XML, SOAP, WSDL and other WS-* specifications that are quite common today in the world of SOAP Web Services-this work was done by Microsoft initially. SOAPs precursors exist in the EDI world. It didn’t become really common to see these technologies deployed in large companies until ~2003-2004. I’m sure there are many exceptions to that, but it was my experience. I’ve probably outlined this convention before-and it has been mentioned many places before now. In general, SOAP Web Services are referred to as Web Service (note the capitalization). Any number of other technologies could be called web services-denoting some type of client-server technology that uses the HTTP protocol.
I found this article when searching for “history of web services” on Google. If you are into history-I am-I’d encourage you to spend some time ready.
It’s important to understand where the industry came from for a topic like this. But, we need to focus on where we are at now. This post aims to define what is meant by the terms Service, web service, and Web Service.
A service is the server-side of a client-server implementation. A web service is the server-side implementation of a client-server interaction that uses the HTTP protocol. A Web Service is the server-side implementation of a SOAP-based Service Consumer–Service Provider interaction.
The Non-Technical Perspective
I started this post by mentioning the technical perspective. In shops that are trying to organize a SOA Governance effort or even formally embrace web services, there is almost always a very interesting conversation (more like pointless series of arguments) about services. Each person or group talks passed everyone else; none of them understands what the other is trying to convey. And, little of it makes sense to the casual observer. What am I talking about? Imagine a business group that wants to capture, manage, and track Business Services that implement Business Capabilities. These IBM WSRR terms that I rather like; though, I want to be careful to keep this discussion product agnostic. The important point is in SOA Governance effort there will generally be a group from “the business” that will use the word “service” to represent the idea those links describe-the ability to perform a specific business function. That is great. That is a corner stone of SOA Governance-a topic Thinkmiddleware.com will get to a little later.
Now, consider an systems monitoring group that is responsible for monitoring everything from server uptime to application URL synthetic transactions. To this group, a service is probably any application or system (above the OS instance level in the technology stack) that they can monitor. It may even be more basic than that. They may think of a service as a TCP port (often referred to as a “service”).
Likewise, the System Administration group and networking group might consider any TCP port that is in a listening state to be a service. Or, just any TCP port in the 2-1024 range to be a service.
The Windows Administrators might view Windows Services as “services”. I once witnessed an individual with a strong Windows background derail an entire development effort because he misunderstood the difference between a Windows Service and a Tuxedo Service (BEA Tuxedo, my first job)-couldn’t imagine why that would be done with a Windows service, which was never the plan.
A Middleware or Web Administrator might view a service as either a Web Service or a Web Server.
An ESB administrator probably views a Web Service as a SOAP Endpoint or interface that is described by a WSDL.
Are any of these wrong? No. But, they all require context. Without that context, you might as well have a United Nations meeting without any translators.
Each groups definition of a service needs to be discussed and documented. All human actors in the discussion need to have expectations level-set that “service” is a grossly overloaded term. A common definition of what a service is is a foundational component of SOA Governance-or anything involving a lot of Web Services. From there, each group’s view of what that service is can be defined.
Rather than reusing the same ambiguous term, I recommend qualifying “service” with something that is more meaningful-or, stop using the word service for things that aren’t SOAP or REST web services
.