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 15:57:07 UTC