- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Fri, 28 Jun 2002 16:34:50 -0400
- 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 another.
Received on Friday, 28 June 2002 16:34:56 UTC