Web Services Architecture Working Group 28-Feb-2002 meeting minutes [1]Working Group home page · [2]Meeting records Attendance 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) Agenda See [3]agenda posted by the Chair. Detailed minutes Review of outstanding action items * Daniel Austin to add suitable text giving people expectations (not specific schedule) to the document; DONE: added text to document, modified language to be more appropriate, will post tomorrow. * Daniel to change permissions on the draft; DONE. * Hugo: Will add link from our public home page; PENDING: waiting for new version from Daniel. * Dave Hollander to start an issues list; IN PROGRESS: Dave has started list. * Dave Hollander Will draft a process for handling issues; PENDING. * Daniel Austin: Will remove Dave Hollander's and Mike Champion's names from the document; DONE. 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? 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. Summary of new action items None. See also the list of [4]pending action items. _________________________________________________________________ Chairs: Hugo Haas & Mike Champion Scribe: Mike Champion References 1. http://www.w3.org/2002/ws/arch/ 2. http://www.w3.org/2002/ws/arch/#records 3. http://lists.w3.org/Archives/Member/w3c-ws-arch/2002Feb/0064.html 4. http://www.w3.org/2002/ws/arch/2/02/28-minutes#curr-ai