Re: To be a Web service, or not to be a Web service ...

Champion, Mike wrote:

>Good point ... that post was a "brain dump before bed", which I should
>probably try harder to resist the temptation to do. 
>
>But here's an attempt to rework them:
>
These are exactly the sort of questions that led me to conclude that the 
definition of 'is this a Web service' depends not on the behavior of the 
service itself, or the behavior of a particular client, but the Web 
itself. We can find some scenarios where these examples could be 
rationalized as Web services if all clients/services decide to operate 
in the same way. On the other hand, we intuitively know that some of 
these scenarios would not allow such a Web to grow indefinitely, and so 
would consider these particular services/clients as hindering that 
growth and therefore not being Web services.

I don't think it has anything to do with what the client does. Consider 
example #1:

1) The "service" is an ordinary HTML Web page whose structure appears to
follow a predictable pattern but the underlying code/stylesheets are not
publicly available; a client agent "screen scrapes" the HTML to extract
information into a data structure for further processing.


Perhaps there is a lot of demand for a service that returns some HTML 
page for the purpose of displaying it or printing it. Maybe it's a CSS 
conformance Web page that clients extract and test. In such a Web of 
clients and servers you will definitely perceive this to be a Web 
service. You can add more servers to this Web as fast as you can make 
them discoverable.

On the other hand, perhaps there is a lot of demand for information in a 
particular domain, and this service like others return that information. 
However, instead of standardizing on some known schema to represent that 
information, each service picks up some schema it wants to use. Each 
client must be programmed to the peculiarities of each particular 
service. Such a Web cannot grow organically by simply adding new service 
to it.

So now you have a client and a service and they both operate with each 
other seamlessly. But you may have a larger Web of services and clients 
in that domain that all agree to use some common schema so the Web can 
grow as fast as you can discover new services. This service cannot 
easily participate in that Web, and as far as the Web is concerned will 
not be considered a Web service.

The only citeria I can see as usable for determining whether or not this 
is a Web service is the definition of the Web in which this service 
intends to take part. If it can be addmitted to the Web it's a Web 
service. If it cannot be addmited to the Web, it's not. I wouldn't use a 
specific client as the litmus test.

5) The "service" is some executable software accessed by a SOAP interface
whose only description is the Java code that actually implements it; the
client agent is hand-coded after a telephone conversation with the developer
of the "service."

How would you define the first few services put in place before there 
was reason to exchange WSDL definitions? What about a deployment cycle 
where at some point (usually in the early life) exchanging Java code 
definitions or hard-coding them is just as usable and applicable as 
using WSDL? What if everyone is satisfied with using the same piece of 
Java code to write their clients and servers?

If the nature of the Web is such that all service consumers and 
providers can leverage that definition, regardless of how you write it 
or communicate it, then it's a Web service. It may be a Web that is 
limited in scope to a single domain, say one company, because no one 
else in the world has any use for its services. Nothing wrong with that. 
On the contrary, if we are thinking of B2B collaboration on a larger 
scale we can't construct such a Web. If such a Web did exist this will 
not be one of its participants.

3) The "service" is a RESTful hypermedia application (e.g. an online travel
agency) designed to be used by either human agents or software agents and
the returned data is XHTML; the client agent was programmed after
consultation with the "service" developers to simulate the sequence of GETs
and POSTS -- checking the HTTP return codes and parsing the result data to
find the appropriate URI to go to the next state.

4) Same as 3) but there is no human-usability requirement and the syntax of
the returned data is XML that conforms to an agreed upon schema and the
rules for interpreting the results and moving to the next state are
well-defined in an XML-based format.

As above. But this time we feel more comfortable that this is a Web 
service and the reason for that is that we can easily imagine how this 
particular selection does allow such a Web to grow as easily as we can 
discover new Web services. There is no precise point at which we can say 
"this is a Web service, but #1 and #2 are not". The only difference here 
is that if we imagine a Web that happens to traverse network and 
platform boundaries that we can incorpoate such services into that Web.

I definitely agree with Roger that David's use cases are one way to 
indicate whether or not a service is a Web service. But David's use 
cases are looking at a Web of services that traverses across domains of 
control. And that means they need better mechanism to standardize on the 
exchange of information, such as SOAP and WSDL. I don't see how such 
Webs can be esatblished easily without using such technologies.

On the other hand, there are other valid uses for Web services. I may 
build two Web services that I intend to use in my application and are of 
no interest to the world. I can have more flexibility in electing which 
protocols/languages to use, while still retaining the notion of a Web. 
Perhaps all these Web services use DIME and not SOAP, but I can add more 
DIME services to the mix as easily as I can discover them. So it is a 
Web after all.

Comments?

arkin

Received on Wednesday, 16 April 2003 14:04:41 UTC