What's in a name?
by CBDi Forums Limited
Expanding applicability of Web services
First, Web services are not transport protocol-specific or restricted to the Web. SOAP messages can be sent using many different protocols including SMTP, raw TCP, instant messaging protocols or any other protocol you like.
Very soon we will see widespread support for a broader range of behaviors and transports for Web services. We recently reported on moves by IBM to use WSDL throughout its tools and technologies, and to bring service based behaviors to conventional, proprietary infrastructures, together with WSIF, the Web Service Invocation Framework, enabling representation of Web services which are not dependent on SOAP. Earlier this year we reported on Talking Blocks that specialize in simplifying the tasks of providing and consuming services based on existing software assets.
These moves to broaden the applicability of the services oriented approach are good news, because they allow us to bring a wide range of technologies directly into service based architectures. If you have a huge investment in a variety of technical infrastructures it may make sense to retrofit the service description to provide common, standards-based meta data that can be used in many ways including service reuse, assembly, process design, management and configuration.
In our commentary "Morphing the Web Services Concept" (CBDI Newswire 25th July), we made the point that important new concepts generally go through a process of morphing and evolution before they stabilize, and Web services are no exception. The key evolution taking place right now is the centralization of WSDL, and the pervasive applicability of the service description meta data.
What's in a name?
From the earliest days when the idea was forming, the Web service was always recognized as a sub-optimal name. A simple Web search just doesn't work on Web services, because of the multiplicity of meanings that can be applied to each part of the naming construct. Worse still, no one can agree on the way we should use the term in writing. The W3C and many others use Web services. However many others use XML Web Services, Web Services or plain old Web services. Strangely few use Web Services, which would we think would intuitively emphasize the more important part of the name.
It's been clear for some time that the term Web service was a stretch. However, now that we are taking practical moves to apply the term across a much broader sphere of activity, the absurdity of the situation becomes obvious. The real issue is that as the scope of the service-based approach expands, the applicability diminishes. This is not just a matter of providing search engines with more suitable raw material. It's about being reasonably accurate in how we name important concepts.
Our original definition of the Web service was as follows: "A Web service provides programmable access to a capability that can be used independently of its implementation via a self-describing interface based on open Internet standards"
Obviously, this doesn't apply to using services across proprietary protocols, where you have some specific endpoint technology dependencies. It's clearly a very sensible move to increase the scope of the service oriented architecture, recognizing the potential for limitations, and it makes sense therefore to have a commonly accepted naming system that doesn't just apply the term "Web services" (in whatever syntactical variant you prefer) to every instance of a service. We need a nomenclature that allows us to reflect this accurately and efficiently which everyone can easily buy into.
The basic service definition
We need to separate the generic service concept from the implementation specifics. As an industry we need to use the term Service as a first order construct, that is then qualified according to how it is used. We might define this generic service as, "A service provides programmable access to a capability that can be used independently of its implementation via an XML-based self-describing interface".
The extended service definition
Beyond the basic definition it is clear we need more granularity to differentiate between differing forms and types of service. We require a classification system that allows varying (and evolving) levels of description. These should take the form of optional arguments, which might include transport, domain, container/binding and usage. For example:
This naming convention has the advantage, just like XML, of providing optionality and openness, within a rigid framework. It makes it very clear that options are subsets of the broad definition, and allows users to use the naming system flexibly in order to minimize double speak and acronym overload.
Talking Blocks suggest a name space construct could be applicable here, where we use XML to classify and define Services within a where/what/how framework. For example:
What: StockQuote (service)/ (version) 2.0/ (operation) GetPrice
How: SOAP1.1 over HTTP
The advantage of a namespace based construct would be the uniqueness of the naming. However, by definition it would require a namespace authority. Realistically the industry will continue to use Web services generically in a variety of guises, but progressively we will all come to recognize the value of the underlying service architecture in many different environments, not just the Web. Moving to emphasize the Service concept, and allowing the prefix to be evolved gradually seems to be a pragmatic approach that most people might find acceptable. Indeed, even the marketing folk might like this, as it will allow them to differentiate from others. However we would caution, that even if we don't have a namespace authority, a guiding principle should be accuracy.
We invite comment and feedback on these matters:
A. Does it matter that the Web service is so badly named?
B. What should we do to address this?
C. Do you already have naming systems to address this issue?
Please let us have your feedback, ideas and models and we will be pleased to respond and publish. Send feedback to firstname.lastname@example.org.
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.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.