What's in a name, part II
by CBDi Forum
In our Newswire WHAT'S IN A NAME, August 22nd, we commented that Web services have been widely described as the worst possible naming convention for an important new concept. A simple Web search illustrates the problem. But more importantly the term "Web service" is actually fast becoming an oxymoron, only relevant to a subset of the behaviors that it purports to describe. We suggest the industry must embrace a simple naming system that is semantically accurate, and also useful in providing the basis for a meaningful classification system.
The issue was picked up by the SearchWebServices.com site, and they asked their subscribers to vote on the capitalization of the naming. They offered options Web Services, web services or Web services. Whilst this is useful, it is perhaps trivializing the issue a little because this is much more than a syntactical matter.
Bernard Libbrecht made the point that we forgot to mention the option of making the term one word such as webservice, which would certainly help with the search issues. He observes that we are probably stuck with the WS part of the various W3C specifications such as WSDL, WS-I etc etc. However, this wouldn't be the first time that the literal translation of an acronym became rapidly irrelevant. Richard Gilyead also suggested a similar idea with webService.
Brian Connell of West Global says, "I agree that the current naming of Web Service is very flawed. Here at WestGlobal, we've always made the point that the key emphasis is on the word Service, with a capital "S", rather than the word Web. From the early days, we supported Services in all their forms and protocols, not just SOAP-based services only."
Brian also identified a consistency error in the StockQuote example we used in the earlier Newswire. Conventional OO thinking would make StockQuote the service and GetPrice the operation. But in the Service (sic) world, StockQuote is the name of the provider and GetPrice is the Service. More examples might include InterFlora/SendFlowers, Hertz/RentCar etc
However, whilst this syntactical debate is very interesting, in our original Newswire on the topic we did suggest that there needs to be a more logical foundation for the naming convention. We introduced ideas from Mark Potts of Talking Blocks, in which he suggested a namespace approach, which might be a where/what/how framework.
Recently (September) IBM published a paper on the developerWorks site titled "Back to the basics Part I." In this paper the authors addressed very similar issues. Their solution is complementary to the namespace ideas; they suggest a framework using Description/Message/Transport, which we think is a sensible proposition. They then go on to define three sub classes of the Web service. These are:
- Enterprise Web service (use WSDL but may use proprietary messaging or transport)
- Internet Web service (must use open messaging and transport)
- XML Web service (must use SOAP,HTTP,SMTP,TCP/IP)
CBDi to IBM
I sent a note to all the authors of the paper as follows:
Gentlemen, We are in broad agreement on, and highly supportive of the need to broaden the scope of the concept currently referred to as the web service, (aka Web service, Web Service or XML Web Service) and the need for greater precision in naming. However, we are at a loss to understand your logic on domain naming, and hence your overall naming strategy . . .
1. If a Service doesn't use the Web, why use Web in the qualification?
2. If all Services use XML (for description), why qualify a narrow subset as XML Web Services? Surely they are all XML Web Services if they all use XML? The only differentiator in that subset seems to be SOAP. So why not SOAP Web Services? Or if the qualification is conformance to W3C protocols, why not W3C Services?
In our commentary (reference below), we make suggestions that might be seen as complementary to your own, differing only in the above matters and perhaps the detail of the namespace construct, where we would happily agree on any sensible suggestion, and your proposition (description/message/transport) is a practical extension. Like you, we believe the industry needs to harmonize on a single naming convention, but we believe it needs to be founded on logical consistency in order for it to become universally accepted.
IBM response to CBDi
I received a response from Dan Gisolfi of IBM as follows:
"David, As we articulated in our article . . . much of the confusion around Web Services stems from the poor naming convention. We spent much time wrestling over the same issues you have recently inquired about. Allow us to address your concerns.
Your first question was, "if a Service doesn't use the Web, why use Web in the qualification?" Clearly the term "Web" should not be used to describe the entire domain of services that we attempt to categorize in our article. Our proposition to separate domain areas based on description, message and transport does not require an association with the type of network (Intranet, Internet). So your question is well founded. However, our approach to addressing this issue stemmed from a pragmatic belief that we were not going to change the industry. The damage was already done. We needed to work within the boundaries of the existing nomenclature. As such we promoted the term "Web Services" to classify the entire domain and then applied logic using our proposition to establish sub categories. It is not perfect, but our goal was to establish a semantic framework to add clarity to discussions. It was not our objective to redefine the domain.
Your second question was, "if all Services use XML (for description) why qualify a narrow subset as XML Web Services? Surely they are all XML Web Services if they all use XML? The only differentiator in that subset seems to be SOAP. So why not SOAP Web Services? Or if the qualification is conformance to W3C protocols, why not W3C Services?"
Using our proposition, we put a stake in the ground stating that an XML-based service description such as WSDL is a minimum requirement for a software component to be considered in the domain of Web Services. Stemming from this minimum requirement, we were able to create subcategories that became more narrow in scope as more and more open technologies were used. The term XML Web Services, which we used for the most narrow category, is another example of us working within the boundaries already specified by the industry. Specifically, MS.NET has promoted the combination of WSDL+SOAP+HTTP using the term "XML Web Services", this term has taken root and would be difficult, if not impossible to change."
We are really encouraged by the huge response we have had to this issue, and would like to thank all the correspondents, even if your comments were not included in this wire.
We are however saddened and puzzled by IBM's position. We think this position is probably driven by marketing-oriented thinking that is unable to contemplate changing terminology around which there has already been huge investment. This is actually a curious position for IBM to take.
a) At this juncture, actually no damage has been done YET. The term Web Services has only been used for Web Services. The issue we have is that what IBM is proposing will "do damage" by using the term Web Service to describe a far broader set of Services, and thereby creating confusion.
b) IBM of all the vendors has a great deal to gain from broadening the footprint of the Service concept to legacy applications and proprietary environments, in which they are indisputably pre-eminent. Notwithstanding the excellent collaboration on the WS specifications, they seem bent on trying to marginalize the Microsoft position with XML Web Services (Microsoft's preferred name), not so subtly suggesting that Microsoft is really only able to address a small part of the overall problem domain.
We think that the industry will gravitate to logical naming systems, and given half a chance, will do so. We recommend as follows:
1. Start using the term Service as the generic name for all forms of Web Service, Enterprise Service, Internet Service etc. We are already doing this in much of our writing and it makes complete sense.
2. Use Web Service (capitalization of the Service is important) when you mean a Web Service. Otherwise, be more precise.
3. When you need to be more precise, use the namespace (description/message/transport) prefix, each element is optional dependent on whether it is significant to the purpose of the communication.
Please let us have your comments and feedback on this debate and the new round of proposals. Please send to firstname.lastname@example.org
Please circulate this newswire as widely as possible, in order to increase the awareness of the issue and obtain the widest possible feedback. Thanks.
CBDI NEWSWIRE Thu 22 Aug:
COMMENTARY - WHAT'S IN A NAME?
(please note you will need to log-in to view this newswire)
Best practices for Web services: Back to the basics, Part 1
Copyright CBDi Forum Limited 2002. The CBDi Forum is an analysis firm and think tank, providing insight on component and web service technologies, processes and practices for the software industry and its customers. To register for the weekly newswire click here.
For more information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.