RE: Web Service Definition [Was "Some Thoughts ..."]

I think that the points that Heather are making are right on and should
be reflected in the definition of a web service!
- Edwin

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Heather Kreger
Sent: Friday, March 01, 2002 12:57 PM
To: Champion, Mike; www-ws-arch@w3.org
Subject: RE: Web Service Definition [Was "Some Thoughts ..."]


I like the three point defintion we have come up with, except that the
third point needs some wordsmithing.. but I get the gist of whats trying
to be conveyed. At lease we have consensus on the first two items!

I would like to contribute my two cents on a number of issues that have
been swirling:

1. IBM very much supports Web services that may in fact be
orchestrations or compositions under the covers. To the invoker of the
Web service, the fact that it is a composition (or calls any other back
end or resources for that matter), is completely hidden.  So, I believe
we must support Web services which 'are' orchestrations, but we must not
'expose' (in its
description) the fact that they are.
I think there is consensus that Web services can participate in
compositions and orchestrations, but it must not have to be 'exposed'
(in its description) that it can be part of a composition or
orchestration.

Therefore, its not necessary to mention that it is composable or capable
of being part of an orchestration as part of the definition. It gets
that capability because it is a component.  Certainly the architecture
will need to address composition and orchestration.

2. I think Discovery is a critical element of a Web services
architecture, but not an attribute of the Web service itself. In my
mind, the Web service is that bit of code that gets invoked in the end.
In order for it to plug into the Web services architecture (which we
will be defining) in must be described and discoverable.  You can
certainly interact with a web service without a programmatic discovery
step.

Within IBM, we loosened up the definition of publish and discover so
that it includes manual processes ... sneaker net, email, and ftp during
development, as well.  The conceptual capability must be there. The
mechanism by which this is done may vary according to needs.  So we say
publish is any way you make your description available to someone else
to use, and discover is any way you get ahold of someone else's Web
service description. We also say its valid to do this during development
or runtime. This makes it easier to say that publication and discovery
are required aspects of the architecture and Web services stack.  Would
taking this approach help here?

3. I think description of a Web service is one of the differentiating
factors between a web service and a web resource. That description is
what makes it callable by applications. I think that a web service must
be accompanied by a description in a standards based format.  This would
be recommended (speaking optimistically) to be WSDL in our
architecture.. but somehow and somewhere it must be described.  What
about "supports an application programming interface which is capable of
being described"
 for number three in Steve's definition?   This is essentially a simple
contract.  Notice I did not shorten it as API ... this has a lot of
programming implications, in this case it is an interface for use in
programming appliations which will use the Web service.  This gets
across that web services are program to program and that those
interfaces are described (I'm willing to compromise defining what
technology will be used to do this till architecture time).  I would
prefer to limit that description as being 'standards based' or
'XML-based' or 'language agnostic', but I'll err on the side of
generality along with everyone else.
:-)

Here's where someone's going to catch me... If the Web service is the
bit of code that gets invoked, then the description is not part of
that... This is true. Thats why I say it needs to be accompanied by a
description, and that "A Web service has the property of supporting an
application programming interface which is capable of being described".

This is a tough knife edge to walk... I understand that you can exchange
XML between two programs without description and the industry has been
doing this for quite a while, but I don't honestly think that that is a
Web service. Not everything we have ever done in the past should qualify
as a Web service. Some things will be left out. Some things should be
left out. We have to decide what we want a Web service to mean for the
future based on what we've learned about our past work. I believe the
difference is the description.

Given these examples, if you can describe (create a WSDL) for submitting
a Google search and the response, then Google is a web service. If you
have a description for the federal express application, that would be
the contract you were groping for, then it would be a web service. If
the gate controller has a URI, is accessible over the web, and has a
described interface that the WAP phone theoretically uses, its a web
service If a CORBA object was described, accessible via a URI over
TCPIP, I don't see why not. CORBA does have IDL which is language
agnostic and describes a programmatic interface, the difference between
that description and the web services descriptions today (besides the
fact that the format is XML) is that there is only interface
information, no binding information.

Which raises a point, do we need to say that the interface and the
binding of a web service should be described using a standards based
format?

The random web page is hard for me to make a web service out of... since
its very difficult to describe its application programming interface.

OK, everyone can open fire now. :-)
Heather


"Champion, Mike" <Mike.Champion@softwareag-usa.com>@w3.org on 02/28/2002
08:46:36 PM

Sent by:    www-ws-arch-request@w3.org


To:    www-ws-arch@w3.org
cc:
Subject:    RE: Web Service Definition [Was "Some Thoughts ..."]





> -----Original Message-----
> From: Srinivas Pandrangi [mailto:srinivas@ipedo.com]
> Sent: Thursday, February 28, 2002 7:53 PM
> To: Vinoski, Stephen
> Cc: www-ws-arch@w3.org
> Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
>

> Let me repeat that my only concern is if this definition is "too" 
> broad.... It should contribute towards better
> understanding the beast. It will be a disservice if we leave folks
> wondering if an ftp server is a web service, an smtp server is a web
> service etc. While conceptually they are services, they might not help
> anyone understand web services any better.

OK, let's address this point.  The definition we're calling "Steve's"
basically says that a web service is 1 - identified by a URI 2 - is
invoked via a standard protocol 3 - suitable for being "called" by an
application

What "non-web services" fit this definition?  Can we modify it a bit to
exclude them?

FTP has been mentioned -- I think we'd agree an FTP server is not a "web
service" even though it has a URI, is invoked by a standard protocol,
and can be called by an application.  I'd say it's not a web service
because the content of the result is not interpreted by most
applications, or "processed in a meaningful way."

Likewise, a random web page is not a web service even though it has a
URI and is invoked by HTTP, for the same reason.  A web browser does not
process the content returned by an HTTP server in a meaningful way.
[Yeah, I need help on what "meaninful" means ...this is vague, but gets
to the essence of what a web service is]

How about a DCOM or CORBA object?  Its result is generally processed in
a "meaningful" way (i.e., it's not just a bunch of bits, but some data
structure that usually represents something "understood" by the calling
program).  On the other hand, DCOM/CORBA objects are not identified by
Web URIs or invoked by Web standard protocols.  I think we *do* have to
be somewhat more restrictive about what "standard" means here, and that
we are talking about *internet* standards.  (I guess that could mean
"layered on IP" ... but that would exclude WAP, sigh ... I don't know
how to define "internet either, I guess).

How about the mythical sluice gate that can be controlled via commands
from a WAP phone, and the "result" is more or less water flowing.  I
guess I think that *is* a web service, because it's one application
calling another (let's say the gate controller is identified by a URI)
over an "internet" protocol  (WAP is more or less "the internet" IMHO).

How about something like the UPS package tracking tool?  It has a URI,
an internet standard protocol (an HTTP POST of an HTML form), and I
guess one could write an application that grokked the result and did
something useful with it.  I'm a bit uncertain whether this is a "web
service" because there's not a clear enough "contract" (or "schema", or
"definition") for easy application to application calling and
processing, but it's close, and could easily become a web service.

How about Google?  A query has a URI, it's sent via HTTP, and if Google
documented the result XML/HTML/XHTML format, I guess it's sortof a web
service ...  I don't know ...

Anyway, I think we'd make more progress toward either coming up with an
acceptable definition of "web service" OR defining the requirements for
a "web service architecture" if we think through some of these corner
cases.

Received on Friday, 1 March 2002 16:56:09 UTC