W3C home > Mailing lists > Public > www-ws-arch@w3.org > June 2002

RE: Tool support goal

From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
Date: Fri, 28 Jun 2002 16:34:50 -0400
Message-ID: <9A4FC925410C024792B85198DF1E97E403735AE9@usmsg03.sagus.com>
To: www-ws-arch@w3.org

> -----Original Message-----
> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
> Sent: Friday, June 28, 2002 4:05 PM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: Tool support goal
> The problem here is the `double PhD' problem -- sure, anyone with a 
> sufficiently deep understanding of the protocols, 
> architectures, support  etc etc. can build a web service 
> by hand. But, in practice,  the number 
> of sufficiently experienced professional programmers who haven't been 
> kicked up into management is always going to be low.
> The real goal here is to keep an eye on the folks who will 
> have to write  web services for a living,  
> and who will need all the help that they can 
> get. 

I accept that most web services (and schemas, and Java programs, etc.) are
written with the assistance of power tools, and expect that to continue, and
the tool vendors to prosper.  What I'm concerned about is the situation,
well-exemplified by Google's SOAP API, where what was once simple enough
even for any web-literate person to do (e.g. construct a URI to perform a
query) became both very easy to do with the WSDL file and a tool, but a
significant programming challenge to do by hand.  Sure, it's tempting to
just surrender to the tool imperative ("Feel the power of the Dark Side,
Luuuuke"), but I think we want to resist the idea that it's OK to make it
too complicated for anyone to build a web service by hand because everybody
will do it with a tool anyway.

Maybe we're talking past each other, but I get VERY uncomfortable with the
idea that the WSA should designed to support tools, although I expect (and
plan to use myself) the tools that support the WSA.

Also, the discussion of discouraging ANY content models raises another red
flag for me. I recognize that relatively tightly coordinated "distributed
object" web services are an important part of our usage scenarios, but so
are more loosely coupled "document exchange" web services. These are
admittedly less amenable to automation because the semantics of the
documents are going to be less well defined than the semantics of
programming objects ... but on the other hand, these should more closely
mimic human business processes so it will be less necessary to use tools to
build these services automatically.

So, my concern here is that our goals and CSF's don't too heavily favor any
one of the web services paradigms, but encourage us to focus on what is
common across paradigms and to draw a picture of how they all relate to one
Received on Friday, 28 June 2002 16:34:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:34 UTC