Re: [DotGNU]Defining Web Services

[Norbert Bollow]

> That is most certainly true of the above quote.  But
> the article as a whole fleshes most of that out.  And
> the article, as a whole, points in a direction that
> many think of when discussing 'WebServeces'.

Ok... but since they seem to be using the term "webservice" in a
manner which cannot be defined precisely, the best thing we can
do is to adopt the closest possible reasonable definition, and
take that to be the true meaning of the term.

> At least, it's a benchmark to talk from.  How does DotGNU
> Web Services include and/or extend past this benkmark?

I disagree... unless what they mean can be defined in a precise
manner, it's not useful as a benchmark.  Rather we should adopt
a precise definition and then observe that many people use the
term "webservice" in a more limited context of services that are
meant to be accessed in a more complicated way than directly
from the end-user's web-browser. 

> We need a clear scope of what 'we' mean when talking
> with others outside the project.  From most of my
> reading, most people think of something like the
> article talks about.  We will only confuse if our
> semantics are out of synch.

I think those articles are confusing because they use semantics
and definitions which _don't_make_sense_ when analysed closely.

Here is the part of the article which is IMHO closest to
containing a useable definition:

: First, web services are reusable software components. Web
: services continue the long ascension of object-oriented design
: in software development. Rather than requiring programmers to
: write one start-to-finish set of instructions after another, the
: component-based model allows developers to reuse the building
: blocks of code created by others to assemble and extend them
: in new ways.

That doesn't say much... every chunk of GPL'd code meets this
definition of reusability.

: Second, these software components are loosely
: coupled. Traditional application design depends upon a tight
: interconnection of all subsidiary elements. The complexity of
: these connections requires that developers thoroughly understand
: and have control over both ends of the connection; moreover,
: once established, it is exceedingly difficult to extract one
: element and replace it with another. Loosely coupled systems, on
: the other hand, require a much simpler level of coordination and
: allow for more flexible reconfiguration.

This text does not propose any way through which it could be
decided in a specific example whether it is "loosely coupled" or
not.  This notion of "loosely coupled" is therefore not useful
in a definition.  (It may be useful however in an _explanation_ of
why there may be a business benefit of "webservices":  *Because*
in a "webservice model" different components of the application
talk to each other via standard protocols, chances are that it
will be reasonably easy to make certain kinds of modifications to
the system, and debug them, and a notion like "loosely coupled"
may be introduced to phenomenologically describe that kind of
situation.)

: Third, web services semantically encapsulate discrete
: functionality. A web service is a self-contained "applet" that
: performs a single task.

What is a "single task"?  I don't think that this can be made
precise.

: The component describes its own inputs
: and outputs in a way that other software can determine what it
: does, how to invoke its functionality, and what result to expect
: in return.

That expectation is totally ridiculous IMHO.

: Fourth, web services can be accessed programmatically. Unlike
: web sites and desktop applications, web services are not
: designed for direct human interaction

What is "direct human interaction"?  I don't think that this can
be made precise in any way that allows software to be "not
designed for direct human interaction" and still be useful.  

: and they do not have a graphical user interface. Rather, web
: services operate at the code level;

Huh?  "Operate at code level", what's that?  (A program which
will modify its own source code???)

: they are called by and exchange data with other software

This can be said about all server-side software

: Web services certainly will be incorporated into software
: designed for human interaction, however.

Now this is the best part of the "definition" because it says
that they want to say.  However this is again not useful as a
definition of "webservice" because a real definition must work
with properties of the object under consideration, and not with
speculation about what other programmers may choose to do with
it.

: Finally, web services are distributed over the Internet. Web
: services make use of existing, ubiquitous transport protocols
: like HTTP. By piggybacking on the same, well-understood
: transport as web content, web services leverage existing
: infrastructure and can comply with current corporate firewall
: policies.

Hence something which uses e.g. a variant of HTTP that did not
exist at the time when the above "definition" was written cannot
be a "webservice"?

Again, this kind of statement is not useful in a definition of
"webservice".  The remark about firewalls explains however why
webservices that are based on HTTP (or something that firewalls
cannot distinguish from HTTP) have a marketing advantage.

Greetings, Norbert.

-- 
A member of FreeDevelopers and the DotGNU Steering Committee: dotgnu.org
Norbert Bollow, Weidlistr.18, CH-8624 Gruet   (near Zurich, Switzerland)
Tel +41 1 972 20 59       Fax +41 1 972 20 69      http://thinkcoach.com
Your own domain with all your Mailman lists: $15/month  http://cisto.com