W3C

Web Services Glossary

W3C Working Draft 14 November 2002

This version:
http://www.w3.org/TR/2002/WD-ws-gloss-20021114/
Latest version:
http://www.w3.org/TR/ws-gloss/
Editors:
Allen Brown, Microsoft (until June 2002)
Hugo Haas, W3C

Abstract

This document is a glossary of Web services terms intended to be used to describe the Web services architecture [WS Arch], and across the Web Services Activity.

It is expected, especially in the first drafts, that the definitions contained in this document may conflict with other definitions, and that the reader may not agree with some of them. The process used to develop this document is explained in 1 Introduction: Terminology Process.

Some definitions in this document are derived verbatim from external documents. In such cases, the source is indicated as a reference, listed in the 10 References section.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This is the first public Working Draft of the Web Services Glossary for review by W3C members and other interested parties. It has been produced by the W3C Web Services Architecture Working Group, which is part of the W3C Web Services Activity. This document is a work in progress and is still incomplete in many respects. Although the Working Group agreed to request publication of this document, this document does not represent consensus within the Working Group.

A list of open issues against this document is maintained by the Working Group.

Comments on this document should be sent to www-wsa-comments@w3.org (public archive). It is inappropriate to send discussion emails to this address.

Discussion of this document takes place on the public www-ws-arch@w3.org mailing list (public archive) per the email communication rules in the Web Services Architecture Working Group charter.

The process used to develop this document is explained in 1 Introduction: Terminology Process.

Patent disclosures relevant to this document may be found on the Working Group's patent disclosure page.

This is a public W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of all W3C technical reports can be found at http://www.w3.org/TR/.

Table of Contents

1 Introduction: Terminology Process
2 Architectural Terms
3 General Terms
4 Choreography Definitions
5 Roles
6 Service Properties
7 SOAP Specific Definitions
7.1 Protocol Concepts
7.2 Data Encapsulation Concepts
7.3 Message Sender and Receiver Concepts
8 Security and Privacy Related Terms
9 Management Terms
10 References
10.1 Normative References
10.2 Informative References

Appendix

A Acknowledgements (Non-Normative)


1 Introduction: Terminology Process

Editorial note
This section is based on Dave Hollander's email about terminology process.

Terminology, and naming things in general, is always difficult. The Web Services Architecture Working Group's goal is to develop the architecture of Web services. After the Working Group gets a better understanding of the framework and context for a term, the naming discussion ought to be more straight forward.

Therefore, rather than get into terminology debates now, the following process is being followed:

  1. As shared insight is gained into the nature of the architecture, it will be necessary to add specific detail to concepts, much as "choreography" and "routing" is being discussed now:

    • Focus these discussions on adding understanding.

    • Agree to the descriptive paragraphs, that is good enough for creating Working Drafts. Editors will capture the agreed paragraph and include it in Working Drafts. (Later, the text may be moved later to the glossary.)

    Terminology can be debated just before we approve any text. To challenge terminology, cite a Working Draft usage of a term and propose alternatives, in email. If dictated by the need for timely progress, text may be approved and an issue posted against it using the email for reference.

    The chairs will not consider usage of a term in unapproved materials as significant in establishing consensus on preferred terminology--in other words, prior Working Group use will not be considered as setting precedence.

  2. Everyone should keep a personal glossary, either on paper or on your favorite computer. In your personal glossary, keep track of interesting definitions; they will help the editors when time comes to add the term to the team glossary.

  3. In general, try not to use contested terms. At worse, make the term stand our with quotes "artifact" or d-artifact if it refers to a definitive paragraph.

    Specifically, try not to use the term "artifact", at least not too much. While artifact is used in some circles for our purpose, it obviously is not universally understood as intended. Meanwhile, if terms are used that seem wrong or ill defined, add them to your glossary for discussion later.

  4. If anyone or sub-group would like to work on a naming strategy, great. This would allow the Working Group to agree on principles of naming before having lots of point debates.

2 Architectural Terms

Architecture
  1. The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. [Soft Arch Pract]

  2. A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture. [RoyFieldingThesis]

Architecture Metamodel

@@@

Component
  1. A component is a software object, meant to interact with other components, encapsulating certain functionality or a set of functionalities. A component has a clearly defined interface and conforms to a prescribed behavior common to all components within an architecture. [CCA T&D]

  2. A component is an abstract unit of software instructions and internal state that provides a transformation of data via its interface. [RoyFieldingThesis]

Configuration

Configuration is the structure of architectural relationships among components, connectors, and data during a period of system run-time. [RoyFieldingThesis]

Connector

A connector is an abstract mechanism that mediates communication, coordination, or cooperation among components. [RoyFieldingThesis]

Element

Software architecture is defined by a configuration of architectural elements--components, connectors, and data--constrained in their relationships in order to achieve a desired set of architectural properties. [RoyFieldingThesis]

Reference Architecture

A reference architecture is the generalized architecture of several end systems that share one or more common domains. The reference architecture defines the infrastructure common to the end systems and the interfaces of components that will be included in the end systems. The reference architecture is then instantiated to create a software architecture of a specific system. The definition of the reference architecture facilitates deriving and extending new software architectures for classes of systems. A reference architecture, therefore, plays a dual role with regard to specific target software architectures. First, it generalizes and extracts common functions and configurations. Second, it provides a base for instantiating target systems that use that common base more reliably and cost effectively. [Ref Arch]

3 General Terms

Attribute

A distinct characteristic of an object. An object's attributes are said to describe the object. Objects' attributes are often specified in terms of their physical traits, such as size, shape, weight, and color, etc., for real-world objects. Objects in cyberspace might have attributes describing size, type of encoding, network address, etc. Salient attributes of an object is decided by the beholder. [WSIA Glossary]

Asynchronous

Property of an interaction which isn't synchronous.

Binding

An association between an Interface, a concrete protocol and a data format. A Binding specifies the protocol and data format to be used in transmitting messages defined by the associated Interface. [WSD Reqs]

Connection

A transport layer virtual circuit established between two programs for the purpose of communication. [RFC 2616]

Conversation

A logical collection of messages exchanged between communicating parties.

See long-running interaction and long-running transaction.

Correlation

The assocation of one message to another.

Discovery

The exchange of the Web service description details necessary to interact with the service.

EndPoint

@@@ Currently synonym of port; confusion possible.

An association between a Binding and a network address, specified by a URI, that may be used to communicate with an instance of a Service. A Port indicates a specific location for accessing a Service using a specific protocol and data format. [WSD Reqs]

Feature

Preferred: An abstract piece of functionality.

See also SOAP Feature.

Identity

The unique identifier for a person, organization, resource, or service. [WSIA Glossary]

Interaction

The act of doing an operation.

Interface

A logical grouping of operations. An Interface represents an abstract Service type, independent of transmission protocol and data format. [WSD Reqs]

Introspection

@@@

Long-Running Interaction

A series of operations between a client and a Web service.

See conversation and long-running transaction.

Metric

A metric is an attribute of an architectural component that may be defined during the configuration of the architectural component, can be measured during the use of this architecture component, and whose value may be evaluated.

Message

The basic unit of communication between a Web service and a Client: data to be communicated to or from a Web service as a single logical transmission. [WSD Reqs]

Message Exchange Pattern

@@@

For now, see SOAP message exchange pattern (MEP).

Operation

A set of messages related to a single Web service action. [WSD Reqs]

Orchestration

@@@ In progress

Port
  1. See end point.

  2. An identifier used to differentiate the data streams that a TCP can handle. [RFC 793]

Reliable messaging

The ability:

  1. of a sender of a message to be able to determine whether a given message has been received by its intended receiver and to take compensating action in the event a given message has been determined not to have been received.

  2. of the intended receiver of the message to be assured that it receives and processes a given message once and only once.

  3. of both sender and receiver of a message to carry out (1) and (2) with a high probability of success in the face of inevitable, yet often unpredictable, network, system, and software failures.

Service
  1. Component performing a task.

  2. See Web Service.

Service Agreement

Contract between a service provider and a client regarding the attributes of a Web service and its usage.

Session

A lasting interaction between system entities, often involving a user, typified by the maintenance of some state of the interaction for the duration of the interaction. [WSIA Glossary]

Such an interaction is not limited to a single connection between the system entities.

State

A set of attributes representing the properties of a component at some point in time.

Synchronous

Property of an interaction whose results are directly following the interaction.

Time-Out

A period of time after which some condition becomes true if some event has not occurred. For example, a session that is terminated because its state has been inactive for a specified period of time is said to "time out". [WSIA Glossary]

Web service
  1. A Web service is a software system identified by a URI [RFC 2396], whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols.

  2. A collection of EndPoints. [WSD Reqs]

4 Choreography Definitions

Editorial note: HH
This is a header to hold all the choreography definitions. Eventually, it will be moved elsewhere. This grouping is intended to provide an easy to view place for choreography.
Choreography

The specification of the ordering of messages from one node's perspective or a collection of nodes. May or may not include Turing complete logic in determination of the message exchange pattern.

@@@ Definition in progress: the above definition was the original proposal.

Declarative

@@@

Procedural

@@@

Turing Complete

@@@

Abstract (Choreography) Business Processes

These are definitions that are designed to describe the ordering of business activities that send and/or receive messages. The definition of the flow between activities is not computationally complete (i.e., it cannot be executed). All of the messages are between independent business entities (participants). The participants may be across companies or within a company. There are two types of these processes: Interface Business Processes and Collaboration Business Processes.

Interface Business Processes

This is an abstract business process that defines how outside participants can expect to interact with a service of a business entity. This service can be implemented as any type of application, including an executable business process. If the interface is for an executable business process, then all activities within the interface business process will also exist within the executable business process-that is, the interface business process will be a sub-set of the executable business process. Example of specifications to define these types of processes: WSCI and the abstract part of BPEL4WS

Collaboration Business Processes

This is an abstract business process that defines how two or more interface business processes interact with each other. Even if these business processes were executable, there could be no central control mechanism that could run one of these processes. These processes are dependent on the implementations of the interface business processes to act in coordination. Example of specifications to define these types of processes: WSCI global model and BPSS

Executable (Orchestration) Business Processes

These are definitions that are designed to describe the ordering of business activities that send and/or receive messages. The definition of the flow between activities is computationally complete (i.e., it can be executed). The messages may be sent to/from: a) an independent business entity to itself and b) an independent business entity to another (participant). These could be called internal or workflow business processes. The business activities that interact with another participant will also appear in a derived abstract business process. In fact, the definition of an executable business process is a superset of the definition of an abstract business process. Example of specifications to define these types of processes: executable part of BPEL4WS and BPML

5 Roles

Browser

A system entity that is used by an end user to access a Web site. A browser provides a run-time environment for distributed application components on the client's device. [WSIA Glossary]

Client

A system entity making use of a Web service.

End User

A natural person who makes use of resources for application purposes. [X.800]

Gateway

A node that terminates a message on an inbound interface with the intent of presenting it through an outbound interface as a new message. Unlike a proxy, a gateway receives messages as if it were the final receiver for the message. Due to possible mismatches between the inbound and outbound interfaces, a message may be modified and may have some or all of its meaning lost during the conversion process. For example, an HTTP PUT has no equivalent in SMTP.

Note: a gateway may or may not be a SOAP node; however a gateway is never a SOAP intermediary, since gateways terminate messages and SOAP intermediaries relay them instead. Being a gateway is typically a permanent role, whilst being a SOAP intermediary is message specific.

Node

Relationship with SOAP node and party?

@@@ Better term than party?

Party

Any system entity taking part into an interaction.

Proxy Server

A computer process that relays a protocol between client and server computer systems, by appearing to the client to be the server and appearing to the server to be the client. [RFC 2828]

Provider

A business entity that sells access to or use of Web services. [WSIA Glossary]

Registry

A system entity that provides Service and Service Provider information.

Service Provider

The organizational entity that provides the service. [WSIA Glossary]

System Entity

An active element of a computer/network system. For example, an automated process or set of processes, a subsystem, a person or group of persons that incorporates a distinct set of functionality. [RFC 2828]

User

See end user.

User Agent

A system entity operated by a user, that is capable of accessing Web resources.

Web Site

A collection of interlinked Web pages, including a host page, residing at the same network location. [Web Term]

6 Service Properties

Editorial note: HH
These should probably be migrated to the architecture document.
Capability

@@@ From AR024.3

Evolvability

@@@

Reliability

@@@

Stability

@@@

7 SOAP Specific Definitions

Editorial note: HH
The SOAP definitions and the other definitions need to be made consistent.

This section contains definitions of SOAP-specific terms that were taken from [SOAP12 Part1].

7.1 Protocol Concepts

SOAP

The formal set of conventions governing the format and processing rules of a SOAP message. These conventions include the interactions among SOAP nodes generating and accepting SOAP messages for the purpose of exchanging information along a SOAP message path.

SOAP node

The embodiment of the processing logic necessary to transmit, receive, process and/or relay a SOAP message, according to the set of conventions defined by this recommendation. A SOAP node is responsible for enforcing the rules that govern the exchange of SOAP messages. It accesses the services provided by the underlying protocols through one or more SOAP bindings.

SOAP role

A SOAP node's expected function in processing a message. A SOAP node can act in multiple roles.

SOAP binding

The formal set of rules for carrying a SOAP message within or on top of another protocol (underlying protocol) for the purpose of exchange. Examples of SOAP bindings include carrying a SOAP message within an HTTP entity-body, or over a TCP stream.

SOAP feature

An extension of the SOAP messaging framework typically associated with the exchange of messages between communicating SOAP nodes. Examples of features include "reliability", "security", "correlation", "routing", and the concept of message exchange patterns.

SOAP message exchange pattern (MEP)

A template for the exchange of SOAP messages between SOAP nodes enabled by one or more underlying SOAP protocol bindings. A SOAP MEP is an example of a SOAP feature.

SOAP application

A software entity that produces, consumes or otherwise acts upon SOAP messages in a manner conforming to the SOAP processing model.

7.3 Message Sender and Receiver Concepts

SOAP sender

A SOAP node that transmits a SOAP message.

SOAP receiver

A SOAP node that accepts a SOAP message.

SOAP message path

The set of SOAP nodes through which a single SOAP message passes. This includes the initial SOAP sender, zero or more SOAP intermediaries, and an ultimate SOAP receiver.

Initial SOAP sender

The SOAP sender that originates a SOAP message at the starting point of a SOAP message path.

SOAP intermediary

A SOAP intermediary is both a SOAP receiver and a SOAP sender and is targetable from within a SOAP message. It processes the SOAP header blocks targeted at it and acts to forward a SOAP message towards an ultimate SOAP receiver.

Ultimate SOAP receiver

The SOAP receiver that is a final destination of a SOAP message. It is responsible for processing the contents of the SOAP body and any SOAP header blocks targeted at it. In some circumstances, a SOAP message might not reach an ultimate SOAP receiver, for example because of a problem at a SOAP intermediary. An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message.

8 Security and Privacy Related Terms

Access

To interact with a system entity in order to manipulate, use, gain knowledge of, and/or obtain a representation of some or all of a system entity's resources. [RFC 2828]

Access Control

Protection of resources against unauthorized access; a process by which use of resources is regulated according to a security policy and is permitted by only authorized system entities according to that policy. [RFC 2828]

Access Control Information
  1. Any information used for access control purposes, including contextual information. [X.812]

  2. Contextual information might include source IP address, encryption strength, the type of operation being requested, time of day, etc. Portions of access control information may be specific to the request itself, some may be associated with the connection via which the request is transmitted, and others (for example, time of day) may be "environmental". [RFC 2829]

Access Rights

A description of the type of authorized interactions a subject can have with a resource. Examples include read, write, execute, add, modify, and delete. [WSIA Glossary]

Account

The set of attributes that together define a user's access to a given service. Each service may define a unique set of attributes to define an account. An account defines user or system access to a resource or service. [ProvServ Glossary]

Anonymity

The quality or state of being anonymous, which is the condition of having a name or identity that is unknown or concealed. [RFC 2828]

Auditing

A service that reliably and securely records security-related events producing an audit trail enabling the reconstruction and examination of a sequence of events. Security events could include authentication events, policy enforcement decisions, and others. The resulting audit trail may be used to detect attacks, confirm compliance with policy, deter abuse, or other purposes.

Authentication

To positively verify the identity of a user, device, or other entity in a computer system, often as a prerequisite to allowing access to resources in a system. [X.811]

Authorization

The process of determining, by evaluating applicable access control information, whether a subject is allowed to have the specified types of access to a particular resource. Usually, authorization is in the context of authentication. Once a subject is authenticated, it may be authorized to perform different types of access. [STG]

Confidentiality

Assuring information will be kept secret, with access limited to appropriate persons. [NSA Glossary]

Credentials

Data that is transferred to establish a claimed principal identity. [X.800]

Integrity

Assuring information will not be accidentally or maliciously altered or destroyed. [NSA Glossary]

Login, Logon, Sign-On

The process whereby a user presents credentials to an authentication authority, establishes a simple session, and optionally establishes a rich session. [WSIA Glossary]

Logout, Logoff, Sign-Off

The process of presenting credentials to an authentication authority, establishing a simple session, and optionally establishing a rich session. [WSIA Glossary]

@@@ Is that correct? Shouldn't it be to terminate a session?

Non-Repudiation

Method by which the sender of data is provided with proof of delivery and the recipient is assured of the sender's identity, so that neither can later deny having processed the data. [INFOSEC Glossary]

Persistent Authentication

@@@ From reqs

Principal

A system entity whose identity can be authenticated. [X.811]

Privacy policy

A set of rules and practices that specify or regulate how a system entity or organization collects, processes (uses) and discloses users' personal data as a result of the interaction with a service.

Security Architecture

A plan and set of principles for an administrative domain and its security domains that describe the security services that a system is required to provide to meet the needs of its users, the system elements required to implement the services, and the performance levels required in the elements to deal with the threat environment. A complete security architecture for a system addresses administrative security, communication security, computer security, emanations security, personnel security, and physical security, and prescribes security policies for each. A complete security architecture needs to deal with both intentional, intelligent threats and accidental threats. A security architecture should explicitly evolve over time as an integral part of its administrative domain's evolution. [RFC 2828]

Security Model

A schematic description of a set of entities and relationships by which a specified set of security services are provided by or within a system. [RFC 2828]

Security Domain

An environment or context that is defined by security models and a security architecture, including a set of resources and set of system entities that are authorized to access the resources. One or more security domains may reside in a single administrative domain. The traits defining a given security domain typically evolve over time. [RFC 2828]

Security Mechanism

A process (or a device incorporating such a process) that can be used in a system to implement a security service that is provided by or within the system.

Security Policy

A set of rules and practices that specify or regulate how a system or organization provides security services to protect resources. Security policies are components of security architectures. Significant portions of security policies are implemented via security services, using security policy expressions. [RFC 2828]

Security Policy Expression

A mapping of principal identities and/or attributes thereof with allowable actions. Security policy expressions are often essentially access control lists. [STG]

Security Service

A processing or communication service that is provided by a system to give a specific kind of protection to resources, where said resources may reside with said system or reside with other systems, for example, an authentication service or a PKI-based document attribution and authentication service. A security service is a superset of AAA services. Security services typically implement portions of security policies and are implemented via security mechanisms. [RFC 2828]

Transient Authentication

@@@ From reqs

Username/User Identity

The unique identity for a user with a system [WSIA Glossary]

9 Management Terms

Editorial note: HH
Need definitions for all of those. Sent a request to MTF.
Availability

@@@

Configuration

@@@

Control

@@@

Management Capability

@@@

Management Operation

@@@

Performance Monitoring

@@@

Resource Accounting

@@@

Security Administration

@@@

Security Auditing

@@@ Relationship with auditing?

Service Level Agreements

@@@

Usage Auditing

@@@

Usage Tracking

@@@

10 References

10.1 Normative References

RFC 793
Transmission Control Protocol: DARPA Internet Program Protocol Specification, IETF RFC 793, J. Postel, September 1981 (See http://www.ietf.org/rfc/rfc793.txt.)
RFC 2396
Uniform Resource Identifiers (URI): Generic Syntax, IETF RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, August 1998 (See http://www.ietf.org/rfc/rfc2396.txt.)
RFC 2616
Hypertext Transfer Protocol -- HTTP/1.1, IETF RFC 2616, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee June 1999 (See http://www.ietf.org/rfc/rfc2616.txt.)
RFC 2828
Internet Security Glossary, IETF RFC 2828, R. Shirey, May 2000 (See http://www.ietf.org/rfc/rfc2828.txt.)
RFC 2829
Authentication Methods for LDAP, IETF RFC 2829, M. Wahl, H. Alvestrand, J. Hodges, R. Morgan , May 2000 (See http://www.ietf.org/rfc/rfc2829.txt.)
RoyFieldingThesis
Architectural Styles and the Design of Network-based Software Architectures, Roy T. Fielding, 2000 (See http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.)
SAML Glossary
Glossary for the OASIS Security Assertion Markup Language (SAML), OASIS Committee Specification 01, J. Hodges, E. Maler, 31 May 2002 (See http://www.oasis-open.org/committees/security/docs/cs-sstc-glossary-01.pdf.)
X.800
Information processing systems Open Systems Interconnection Basic Reference Model Part 2: Security Architecture, ISO 7498-2:1989, ITU-T Recommendation X.800 (1991) (See http://www.itu.int/itudoc/itu-t/rec/x/x500up/x800.html.)
X.811
Security Frameworks for Open Systems: Authentication Framework, ITU-T Recommendation X.811 (1995 E), ISO/IEC 10181-2:1996(E) (See http://www.itu.int/itudoc/itu-t/rec/x/x500up/x811.html.)
X.812
Security frameworks for open systems: Access control framework, ITU-T Recommendation X.812 (1995 E), ISO/IEC 10181-3:1996(E) (See http://www.itu.int/itudoc/itu-t/rec/x/x500up/x812.html.)

10.2 Informative References

CCA T&D
CCA Terms and Definitions, CCA Forum, Kate Keahey (See http://www.acl.lanl.gov/cca/terms.html.)
INFOSEC Glossary
National Information Systems Security (INFOSEC) Glossary, National Security Telecommunications and Information Systems Security Instruction (NSTISSI) No. 4009, 5 June 1992
NSA Glossary
NSA Glossary of Terms Used in Security and Intrusion Detection, NSA, April 1998 (See http://www.sans.org/newlook/resources/glossary.htm.)
ProvServ Glossary
OASIS Provisioning Services TC Glossary, OASIS individual draft, D. Rolls, G. Sodhi, 15 December 2001 (See http://www.oasis-open.org/committees/provision/docs/draft-rolls-glossary-02.doc.)
Soft Arch Pract
Software Architecture in Practice, ISBN 0201199300, L. Bass, P, Clements, R. Kazman, 1997
Ref Arch
Using the Architecture Tradeoff Analysis Method(SM) to Evaluate a Reference Architecture: A Case Study, B. Gallagher, June 2000 (See http://www.sei.cmu.edu/publications/documents/00.reports/00tn007/00tn007.html.)
STG
Security Taxonomy and Glossary, L. Wheeler (See http://www.garlic.com/~lynn/secure.htm.)
SOAP12 Part1
SOAP Version 1.2 Part 1: Messaging Framework, W3C Working Draft, M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Nielsen, 26 June 2002 (See http://www.w3.org/TR/2002/WD-soap12-part1-20020626.)
TIC Glossary
Trust in Cyberspace Glossary, ISBN 0-309-06558-5, F. Schneider, Editor; Committee on Information Systems Trustworthiness, National Research Council, 1999 (See http://www.nap.edu/readingroom/books/trust/trustapk.htm.)
Web Term
Web Characterization Terminology & Definitions Sheet, W3C Working Draft, B. Lavoie, H. Nielsen, 24 May 1999 (See http://www.w3.org/1999/05/WCA-terms/01.)
WS Arch
Web Services Architecture, W3C Working Draft, M. Champion, C. Ferris, E. Newcomer, D. Orchard, 14 November 2002 (See http://www.w3.org/TR/2002/WD-ws-arch-20021114/.)
WSIA Glossary
Glossary for the OASIS WebService Interactive Applications (WSIA/WSRP), OASIS draft, 3 May 2002 (See http://www.oasis-open.org/committees/wsia/glossary/wsia-draft-glossary-03.htm.)
WSD Reqs
Web Service Description Requirements, W3C Working Draft, J. Schlimmer, 29 April 2002 (See http://www.w3.org/TR/2002/WD-soap12-part1-20020626.)

A Acknowledgements (Non-Normative)

This document has been produced by the Web Services Architecture Working Group.

Members of the Working Group are (at the time of writing, and by alphabetical order): Daniel Austin (W. W. Grainger, Inc.), Mukund Balasubramanian (Infravio, Inc.), Mike Ballantyne (EDS), Abbie Barbir (Nortel Networks), David Booth (W3C), Allen Brown (Microsoft Corporation), Mike Brumbelow (Apple), Doug Bunting (Sun Microsystems, Inc.), Greg Carpenter (Nokia), Dipto Chakravarty (Artesia Technologies), Jun Chen (MartSoft Corp.), Alex Cheng (Ipedo), Tom Carroll (W. W. Grainger, Inc.), Michael Champion (Software AG), Martin Chapman (Oracle Corporation), Ugo Corda (SeeBeyond Technology Corporation), Roger Cutler (ChevronTexaco), Jonathan Dale (Fujitsu), Suresh Damodaran (Sterling Commerce(SBC)), Glen Daniels (Macromedia), James Davenport (MITRE Corporation), Alan Davies (SeeBeyond Technology Corporation), Paul Denning (MITRE Corporation), Ayse Dilber (AT&T), Zulah Eckert (Hewlett-Packard Company), Gerald Edgar (The Boeing Company), Colleen Evans (Progress Software Corp.), Chris Ferris (IBM), Daniela Florescu (XQRL Inc.), Shishir Garg (France Telecom), Yaron Goland (BEA Systems), Hugo Haas (W3C), Mark Hapner (Sun Microsystems, Inc.), Hao He (The Thomson Corporation), Dave Hollander (Contivo), Yin-Leng Husband (Hewlett-Packard Company), Nigel Hutchison (Software AG), Mario Jeckle (DaimlerChrysler Research and Technology), Mark Jones (AT&T), Tom Jordahl (Macromedia), Heather Kreger (IBM), Sandeep Kumar (Cisco Systems Inc), Hal Lockhart (OASIS), Michael Mahan (Nokia), Francis McCabe (Fujitsu), Michael Mealling (VeriSign, Inc.), Jens Meinkoehn (T-Nova Deutsche Telekom Innovationsgesellschaft), Jeff Mischkinsky (Oracle Corporation), Nilo Mitra (Ericsson), Himagiri Mukkamala (Sybase, Inc.), Eric Newcomer (IONA), Henrik Nielsen (Microsoft Corporation), Mark Nottingham (BEA Systems), David Orchard (BEA Systems), Srinivas Pandrangi (Ipedo), Fabio Riccardi (XQRL Inc.), Don Robertson (Documentum), Waqar Sadiq (EDS), Krishna Sankar (Cisco Systems Inc), Igor Sedukhin (Computer Associates), Jim Shur (Rogue Wave Software), Hans-Peter Steiert (DaimlerChrysler Research and Technology), Katia Sycara (Carnegie Mellon University), Patrick Thompson (Rogue Wave Software), Steve Vinoski (IONA), Scott Vorthmann (TIBCO Software, Inc.), Prasad Yendluri (webMethods, Inc.), Jin Yu (MartSoft Corp.), Sinisa Zimek (SAP).

Previous members of the Working Group were: Mark Baker (Idokorro Mobile, Inc. / Planetfred, Inc.), Tom Bradford (XQRL, Inc.), Sharad Garg (Intel), Joseph Hui (Exodus/Digital Island), Marcel Jemio (DISA), Timothy Jones (CrossWeave, Inc.), Jim Knutson (IBM), Bob Lojek (Intalio, Inc.), Anne Thomas Manes (Systinet), Joel Munter (Intel), David Noor (Rogue Wave Software), Kevin Perkins (Compaq), Darran Rolls (Waveset Technologies, Inc.).

The people who have contributed to discussions on the www-ws-arch public mailing list are also gratefully acknowledged.