Web Services Architecture Working Group
28-Feb-2002 meeting minutes

Working Group home page · Meeting records


          Mike Brumbelow
   BEA Systems
          David Orchard
          Roger Cutler
   Cisco Systems Inc
          Sandeep Kumar
          Yin-Leng Husband
   Computer Associates
          Igor Sedukhin
   DaimlerChrysler Research and Technology
          Mario Jeckle
   Digital Island
          Joseph Hui
          Mike Ballantyne
          Waqar Sadiq
   Hewlett-Packard Company
          Zulah Eckert
          Heather Kreger
          Eric Newcomer
          Steve Vinoski
   Intel Corporation
          Sharad Garg
          Joel Munter
   MITRE Corporation
          James Davenport
   Microsoft Corporation
          Allen Brown
          Michael Mahan
   Nortel Networks
          Abbie Barbir
          Sinisa Zimek
   SeeBeyond Technology Corp
          Alan Davies
   Software AG
          Michael Champion
   Sun Microsystems, Inc.
          Doug Bunting
   W. W. Grainger, Inc.
          Daniel Austin
          Tom Carroll
          Hugo Haas
   webMethods, Inc.
          Prasad Yendluri

  Chris Ferris (Sun Microsystems -- Chair)
  Mark Baker (Planetfred, Inc.)
  Anne Thomas Manes (Systinet)
  Tom Bradford (XQRL)
  Timothy N. Jones (CrossWeave, Inc.)
  Krishna Sankar (Cisco)
  Mark Hapner (Sun Microsystems)
  Gerald Edgar (The Boeing Company)
  Nilo Mitra (Ericsson, Inc.)
  Himagiri(Hima) Mukkamala (Sybase, Inc.)
  Paul Denning (MITRE)
  Srinivas Pandrangi (Ipedo Inc.)
  Suresh Damodaran (Sterling Commerce, Inc.)
  Kevin Perkins (Compaq)


See agenda posted by the Chair.

Detailed minutes

Review of outstanding action items

Approve minutes

Deferred until we're sure that Chris has reviewed them

Definition of Web Service

Daniel Austin:  Can we really do this?  

Steve from Iona:  2 camps -- broad definition vs requirements centered.

Joe Hui: Strawman requirements defintion intended to be less controversial
Can we define definition by properties?

Roger (Chevron) - Observing convergence ... into separate streams

1- Describe how thing works
2 - Describing what kind of environment it participates in functionally

?  Need definition that is abstract should be general, our definition should 
meet requirements.,

Tom Carrol -- start with requirements, distill out definition.

? Requirements should feed back into defintion.

Joe - Try to be as specific as possible

Steve Vinoski - Don't want to rule out valid implementations by too-specific

Roger - Definition should be specific enough to tell whether something is a
webservice or not, e.g. orchestration.

Daniel - distinguish web service from ws architecture ... servicies are
components within architecture.
Need to provide defintions of both.

Daniel - If I'm given a reference architecture, I can test my service to
see if it is conformant.  It shoudl define components and communication paths.

Mike Champion - Ann Thomas Manes had a definition that I thought was
a good starting point:

> A "web resource" is a resource (an electronic construct, such as a file,
network, processor, application, or service) that is identifed by a URI and
accessed through web protocols.

> A "service" is a resource that exposes its functionality through a
programmatic interface (understood by software rather than by humans). The
method of invocation and the possible results of that invocation are
described by a contract.

> A 'web service" is a service that is identified by a URI and is accessed
through web protocols in accordance with the contract that describes its
interface. The specification of the contract is a web resource.

Yin-ling - Charter mentions XML protocols, should definition include it? 

Abbie - don't mix definition with enabling technology.

Roger - second point  "programmatic interface" is too vague.

Mike - humans and machines distinction is important in many journalistic
accounts of what "web services" are.

?? - This is Way too fuzzy to be useful to us.  

Steve Vinoski:  What's important is that a web service is
- Identified by URI
- Accessed by Standard protocols
- Interactions do not require human involvement.

Joe - Description and Discovery are not important?   
Let's define methodology first, definition will fall out

???? Don't need discovery to define web service

??? Don't confuse architecture with definition ...

Steve - web service definition must be broad and minimal, more you
put in, more you exclude. Lots of people have web services that
are not defined in W3C terms.  XML-RPC people would say

Abbie - Agrees with Steve .... VPN is an example of something
that people understand, but definition is broad. Keep it abstract
and simple.

Heather IBM - Separate out defining service and what it takes to plug into
architecture.  Also needs to be described, wants description and discovery
put into defintion of web service, although WSDL per se not necessary.

Roger - More pedestrian definition: WS is a resource identified by URI, 
interacts with participants identified by URI, gets requests and sends 
responses as XML.  

How about URI as invocation?  Steve thinks that XML in, XML back 
is integral to most definitions.

Heather - can we abbreviate this?  

Doug - likes distinguishing between WS and WS architecture; if we are just
defining "service" STeve is close.  Available over web, CAN interact with
software component.  Disagrees with Heather that Architecture *must* include
Description component.  Sees no requirement to identify client by URI.

Sandeep - Likes Steve's definition.  Human intervention may or may not be 
needed, e.g. purchase order approval.  Discover and Description is important
because "hard wiring" these implies that no standard protocol is involved
in interaction. 

Joe - D&D goes hand in hand with web service, but can happen offline.

Abbie  -- would say "resource" not "identified by physical URL"
Steve's item 2 "wants 'may be accessed in a secure fashion" too.

 ?? - Don't feel like all components of architecture should
be rolled into definition.  STart with Steve's definition. We should
capture baseline capabilities.

Sherad (intel)- simple definition "WS are self-contianed, loosely coupled,
that CAN BE described and discovered using standard protocols.  

?? Let's not bind ourselves to specific technology, but don't
put loosely coupled in definition.  It is part of architecture.

Roger - Worries him that it doesn't matter than URI and XML is
integral to defintion.  Would a remote controlled dam qualify as a
web service.

Joe -  Identification has to be globally unique, doesn't matter how.
No matter what verbiage is, if we look at our defintion, it doesn't
add much 

Hugo -- URI identification issue -- it matters whether your 
service is identified by a URI, not client.

Discussion of whether an IP address is a URI ... no.

Is Steve's definition a reasonable starting point ....
message 0142 .... Mark Baker added something

25 Feb 10:53 -- "web" changed to "internet" protocols.
"standard" protocol captures both. 

Steve - we don't want to exclude SOAP over SMTP.

Dave Orchard - One thing would be to just say "standard protocols".
Don't get into URI, Web, internet, etc. adjectives.

If we say URI in part one, we can be less explicit in part 2.
"Web" components include SMTP, according to tag.

We need at least "internet" to specify scope without being 
overly limited.

Mike C. - Can we limit WS to "internet" 

Various people - "Standard protocols" would be better.

Joe - We don't have to be limited to "internet" because this
is essentially a transport layer issue.  
Wants D&D in definition.

Roger - working definition too broad.  #2 should explicitly
say "accessed via XML messages" This unambiguously distinguishes
WS from random website.

Abbie - "machine understandable and processable format"  

Joe - Isn't HTML machine processable?

Dave - Issue is that we can go down 2 roads - describe formats
like "XML vocabularies" or try to describe software that could
use this stuff. Leans toward latter. Human vs machine is key
point here in concept of web service; WS is app to app communication.

Steve - Agree with Dave Orchard.  Standards need to be clear with
SHALL and MUST but this definition can be looser. Our definition
can be more ambiguous and natural language-ish.

Heather - Agrees that it is applicaiton oriented rather than 
human oriented ... can we say it has an API? 

Hugo - how about Sherad's proposal as a starting point?

? - Agrees to drop "web protocols" and just say "standard protocol." 

Dave - How do we preclude limiting where WS may go in the future.
All we can really say is that a WS is something we currently agree
is a WS.  A tight definition may be hard, and pointless. 

Steve - Sherdt's definition has problems "self contained" is
vague ...  "self describing" too loaded ... "loosely coupled"
is a problem.  Doesn't mention "URI."   We need to  stick
with URI, protocol, machine processable.

Makara - Doesn't like "self describing" or "loosely coupled"

Sharad - "self contained" means that it does what it does without
depending on anything else.  "self describing" means that it doesn't
depend on D&D system.  "loosely coupled" means to exclude ONLY RPC,
not exclude tightly coupled.  Agrees that "standard protocol" OK

Roger - Broad definition makes him uncomfortable because it's hard to
exclude anything as NOT a web service.

Sandeep - putting "maybe" before Sharad's terms puts us more or less
where Steve's definition starts. 

Daniel Austin - What's important is the fact that a web service has an
interface and a protocol, the rest can become clear (or stay ambiguous)
as we refine the requirements.  Let's focus on that now.

Summary of new action items


See also the list of pending action items.

Chairs: Hugo Haas <hugo@w3.org> & Mike Champion <Mike.Champion@SoftwareAG-USA.com>
Scribe: Mike Champion <Mike.Champion@SoftwareAG-USA.com>