Re: Is This a Web Service?

I feel obliged to throw my $0.02 and an alternative definition

A Web service - A service that can be incorporated into a larger 
interconnected structure (a web) or services that can grow infinitely 
unlimited by the capabilities of a particular communication mechanism.


An OO language adds a lot of capabilities to procedural languags. 
Abstraction, encapsulation, etc. But OO languages do not flat out reject 
procedural languages - they extend them with new capabilities but do not 
reject any existing capabilities. A SOAP-based Web services that 
supports XML content, enveloping of transaction context in the header, 
and WSDL-based end-point definition is a novel use of Web service 
technologies. This is something we could not have done a few years back. 
But the legacy CGI's of yore are also Web services. They don't take 
advantage of all the new capabilities, surely they can be extended, but 
they are still Web services.

A Web service doesn't change its skin because it decides to offer a 
service with less "XML" in it. A Web service may provide you with the 
latest XML qoute, or just stream back an MPEG file, or give you access 
to a PDF document. If it offers the service you request it should be 
considered a Web service. We can't ignore useful services that return 
data just because the data is not XML. And in fact, an XML document may 
just as well be purely binary content (see XML Schema 1.0). So when does 
it stop becoming XML?


Interoperability is key. But interoperability is more about semantics 
and common languages that it is about medium. If I talk about a new 
business opportunity for Wi-Fi and you expect me to talke about the 
chemical makeup of a new miracle drug - we're not talking the same 
language. We're not communicating.

On the other hand, if we're both exploring the same business opportunity 
I may call you from my CDMA cell-phone and you may be using a land-line 
phone. Or I may use VoIP on my end and you may be using GSM on your end. 
All I need is a rudimentary medium adapter to allow the both of use to 
converse over any number of topics. We don't need a specific adapter for 
each and every topic of discussion. And that's when interoperability is 
realized - because we distinguish between the information that is 
communicated and the mediums of communication.

So let's carry that analogy back to Web services. Let's say we both 
agree on the semantics of our exchange - what information we exchange 
and what is the outcome of that exchange. We can use any number of 
protocols at the same time. Perhaps on my end I send a SOAP/HTTP message 
and on your end you find it easier to do DIME/TCP and we have some very 
generic and dumb adapter in the middle. But we agreed on the semantics 
we use in our discussion. We can interoperate, can't we?


WSDL and SOAP are just means to represent information. They have a lot 
of utility and I expect them to be widely used. But what we care about 
is not the particular representation - it's the information. We can pick 
other representations, maybe DIME or an alternative to WSDL, but if we 
must dissociate representation from model.

If there's anything we should have learned from XML is to stop depending 
on a particular presentation. XSLT gives us one of the most powerful 
tools to transform information to any number of alternative 
representations. It's time we learn that it's not about representation 
but about the information model.

I think the power of Web services will be fully realized when we define 
Web services as a SOA that is not dependent on the limitations of a 
particular syntax, language, implementation or protocol. They are not 
just for Interent use, neither are they limited to just Intranet use. 
They do B2B with the same level of success as A2A. They can support XML 
content as well as MIME content.


And what is the Web? When I first started using HTML/HTTP I frowned upon 
any non-techie who failed to understand that the Web is the Interent and 
not just two connected computers, it's HTTP and not SMTP, it's Web 
servers and not just file servers. But over time I realized that the 
pure techie point of view may be too narrow to capture the essence of 
the Web. I began to recognize that perhaps the people who best 
understand the nature of the Web are my non-techie friends and 
relatives. That ones who can't read the HTTP specification if their life 
dependent on it. It took a shift in perspective, but I've finally 
accepted their utilitarian non-techie perception of the Web.

People I know would say "I'm on the Web" when they're using e-mail or 
IM. The perceive the Web in its most basic sense - a complex 
interconnected structure of things you can touch electronically.  They 
care less about protocols. With the click of a mouse they can easily 
traverse from an e-mail to an HTML page to an IM conversation. They can 
use all three to get information and services. They don't use VoIP, they 
use Web phones. To them that's what the Web is all about and damn the 
protocols.


I would define a Web service as nothing more than a service that, having 
selected from a variety of available protocols and encodings, can be 
incorporated into a larger web of services. It is not a Web service if 
for any particular reason that has nothing to do with the nature of the 
service itself - and by that I mean artificial issues like limited 
protocol selection - cannot be incorporated into a lager web of services.

If I can make it part of a larger interconnected structure of services, 
maybe by using SOAP or by using DIME or other protocols, then I perceive 
it as a Web service. And if I am limited to using one protocol, be it 
IIOP or DCOM, and can only fit it with other same-protocol services, 
then it's not a Web service. It's a service of limited utility.

The Web service revolution is not about using XML and SOAP and WSDL. The 
Web service revolution is about utilizing all these technologies to 
create an interconnect of services that can grow infinitely across the 
boundaries of businesses, countries and communication networks.

arkin

Received on Tuesday, 15 April 2003 15:18:21 UTC