[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Defining Web Services

From: Norbert Bollow
Subject: Re: [DotGNU]Defining Web Services
Date: Thu, 8 Nov 2001 12:47:38 +0100

Daniel E Baumann <address@hidden> wrote:

> On Wed, Nov 07, 2001 at 07:22:28PM +0100, Norbert Bollow wrote:
> > 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.
> What they mean is you write reusable components that can be used in any
> application and that have a specific use, i.e. a bonobo component that
> renders html. Cool thing about OO is you do not just link to something
> but extend the object or component interface via inheritance thus not
> adding your new functionality without changing their code. No code
> pasting or anything...then again libraries also do the same thing.

Yes.  And if you're just planning to re-use a single, relatively
simple function or two, copy-and-paste is better for your
productivity than adding a dependance on an external library or
webservice.  The words "Rather than requiring programmers to
write one start-to-finish set of instructions after another"
make me wonder whether those venture capitalists know of any
programming paradigms besides "spaghetti code" and "webservices".

> > : 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.)
> heheh! I had an interview once where they said define loose coupling and
> high cohesion. Loose coupling is very descriptive it basically means you
> communicate at arms length and that the pieces can stand on their own.
> if Loose coupling can be defined then why would it not be good in a
> definition? Why would they ask me to define it if it could not be
> defined?

When the interviewers said "define", they probably meant
"explain the meaning".  (They may not have been aware of the
requirements of a rigourous definition.)

I don't really care whether it is possible to give a rigourous
and yet useful definition of "loosely coupled".  (As I said,
phenomenological terms can be useful even when they're not
made completely precise.)  The point is, when someone wants to
use the term in a definition, then this author should give the
notion a precise meaning first, in a way that allows to
non-ambiguously decide in every situation whether things are
"loosely coupled" or not.  One of my criticisms of this
attempted definition of "webservice" is that it relies on the
notion "loosely coupled" _without_giving_that_notion_a_sufficiently_

> > : 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.
> An html component renders html, an ftp component does the ftp protocol,
> etc. How is this confusing?

The problem is with the requirement that the webservice performs
"a single task".  So something which fetches a text file by ftp
can be a webservice, and something which converts the text file
from DOS to Unix conventions can be a webservice, but something
which does both cannot be considered a webservice, because it
performs two tasks and not one???

> > : 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.
> How do you figure? A bonobo component has a specific interface and
> provides a specific output. You can interrogate it to figure out what it
> does, etc.

But it still requires human intelligence to really determine
what the component does!  Even if the component advertises a
well-known standard service, you may want to check with someone
who reads Bugtraq before you believe it.  And it the component
does something that is at least a little innovative, it is
ridiculous to expect other software to be able to really
understand even what the component claims to be doing.

There is a reason why some webservices advocates are making
these ridiculous claims about other software being able to
determine what a webservice does.  The goal is that they try
to convince the world that it will be possible to completely
automate the decision of whether or not to use a given
webservice.  This comes from a few big companies who would like
to gain an effective control over the 'net.

If the decision of what webservice to use is put into the hands
of a computer program, then whoever controls those computer
programs controls the 'net.

Imagine that the end-user are given an operating system with a
hard-to-change default setting of "always trust webservices that
come with a digital signature from Microsoft."

That's the kind of thing that Microsoft's .NET is all about.
They want to gain control of the 'net.  And they will make
ridiculous claims when it suits their agenda.  We should not
allow this kind of ideas to infect our thinking.

It matters less for the authores of the currently-discussed
"definition" of webservices, they're venture capitalists,
i.e. they're not trying to develop any useful software, they're
just trying to attract investor $$$.  From their perspective,
want they write doesn't need to work, it's enough if the
mistakes are difficult enough to find that potential investors
won't notice them.

> I agree don't agree with the author as you can have bot UI components
> and non-UI components....maybe the majority of web services would be
> non-UI component based, but making that assumption is sorta naive.


Greetings, Norbert.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]