Working Group home page · Meeting records
Present:
--------
Apple
Mike Brumbelow
BEA Systems
David Orchard
ChevronTexaco
Roger Cutler
Cisco Systems Inc
Sandeep Kumar
Compaq
Yin-Leng Husband
Computer Associates
Igor Sedukhin
DaimlerChrysler Research and Technology
Mario Jeckle
Digital Island
Joseph Hui
EDS
Mike Ballantyne
Waqar Sadiq
Hewlett-Packard Company
Zulah Eckert
IBM
Heather Kreger
IONA
Eric Newcomer
Steve Vinoski
Intel Corporation
Sharad Garg
Joel Munter
MITRE Corporation
James Davenport
Microsoft Corporation
Allen Brown
Nokia
Michael Mahan
Nortel Networks
Abbie Barbir
SAP
Sinisa Zimek
SeeBeyond Technology Corp
Alan Davies
Software AG
Michael Champion
Sun Microsystems, Inc.
Doug Bunting
W. W. Grainger, Inc.
Daniel Austin
Tom Carroll
W3C
Hugo Haas
webMethods, Inc.
Prasad Yendluri
Regrets
-------
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.
Deferred until we're sure that Chris has reviewed them
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?
But
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
definition.
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,
selfdescribed,
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.
None.
See also the list of pending action items.