Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document is a glossary of Web services terms defined and used in the Web Services Architecture [WS Arch]. It is intended for use by Web services spefications in order to refer to a common coherent framework.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a public Working Group Note of the Web Services Glossary. It has been produced by the W3C Web Services Architecture Working Group, which is part of the W3C Web Services Activity. This publication as a Working Group Note coincides with the end of the Working Group's charter period.
Discussion of this document is invited on the public mailing list www-ws-arch@w3.org (public archives).
Patent disclosures relevant to this document may be found on the Working Group's patent disclosure page.
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. Other documents may supersede this document.
1 Introduction
2 Definitions
3 References
A Acknowledgements (Non-Normative)
This document contains a list of Web services terms that are part of a coherent framework defined in the Web Services Architecture [WS Arch]. The relationships between the terms are defined in the concepts and relationships section of [WS Arch].
Terms are capitalized when it is meaningful, or otherwise are defined in lowercase.
Some definitions in this document are derived verbatim from external documents. In such cases, the source is indicated as a reference, listed in the 3 References section.
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]
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]
Any information used for access control purposes, including contextual information. [X.812]
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]
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]
A person or organization that may be the owner of agents that either seek to use Web services or provide Web services.
A physical or conceptual entity that can perform actions. Examples: people; companies; machines; running software. An actor can take on (or implement) one or more roles. An actor at one level of abstraction may be viewed as a role at a lower level of abstraction.
An agent is a program acting on behalf of a person or organization. (This definition is a specialization of the definition in [Web Arch]. It corresponds to the notion of software agent in [Web Arch].)
The quality or state of being anonymous, which is the condition of having a name or identity that is unknown or concealed. [RFC 2828]
The software architecture of a program or computing system is the structure or structures of the system. This structure includes software components, the externally visible properties of those components, the relationships among them and the constraints on their use. (based on the definition of architecture in [Soft Arch Pract])
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. [Fielding]
A piece of digital information. An artifact may be any size, and may be composed of other artifacts. Examples of artifacts: a message; a URI; an XML document; a PNG image; a bit stream.
An interaction is said to be asynchronous when the associated messages are chronologically and procedurally decoupled. For example, in a request-response interaction, the client agent can process the response at some indeterminate point in the future when its existence is discovered. Mechanisms to do this include polling, notification by receipt of another message, etc.
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. [WSIA Glossary]
An audit guard is a mechanism used on behalf of an owner that monitors actions and agents to verify the satisfaction of obligations.
Authentication is the process of verifying that a potential partner in a conversation is capable of representing a person or organization.
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]
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]
The mapping of an interface and its associated operations to a particular concrete message format and transmission protocol.
See also SOAP binding.
A capability is a named piece of functionality (or feature) that is declared as supported or requested by an agent.
A choreography defines the sequence and conditions under which multiple cooperating independent agents exchange messages in order to perform a task to achieve a goal state.
Web Services Choreography concerns the interactions of services with their users. Any user of a Web service, automated or otherwise, is a client of that service. These users may, in turn, be other Web Services, applications or human beings. Transactions among Web Services and their clients must clearly be well defined at the time of their execution, and may consist of multiple separate interactions whose composition constitutes a complete transaction. This composition, its message protocols, interfaces, sequencing, and associated logic, is considered to be a choreography. [WSC Reqs]
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]
A component is an abstract unit of software instructions and internal state that provides a transformation of data via its interface. [Fielding]
A component is a unit of architecture with defined boundaries.
Assuring information will be kept secret, with access limited to appropriate persons. [NSA Glossary]
A collection of properties which may be changed. A property may influence the behavior of an entity.
A transport layer virtual circuit established between two programs for the purpose of communication. [RFC 2616]
To cause a desired change in state. Management systems may control the life cycle of manageable Web services or information flow such as messages.
A Web service conversation involves maintaining some state during an interaction that involves multiple messages and/or participants.
Data that is transferred to establish a claimed principal identity. [X.800]
A delivery policy is a policy that constrains the methods by which messages are delivered by the message transport.
A value computed with a cryptographic algorithm and appended to a data object in such a way that any recipient of the data can use the signature to verify the data's origin and integrity. (See: data origin authentication service, data integrity service, digitized signature, electronic signature, signer.) [RFC 2828]
The act of locating a machine-processable description of a Web service-related resource that may have been previously unknown and that meets certain functional criteria. It involves matching a set of functional and other criteria with a set of resource descriptions. The goal is to find an appropriate Web service-related resource.
A discovery service is a service that enables agents to retrieve Web services-related resource description.
Any data that can be represented in a digital form. [UeB Glossary]
The automated exchange of any predefined and structured data for business among information systems of two or more organizations. [ISO/IEC 14662]
A domain is an identified set of agents and/or resources that is subject to the constraints of one of more policies.
Cryptographic transformation of data (called "plaintext") into a form (called "ciphertext") that conceals the data's original meaning to prevent it from being known or used. If the transformation is reversible, the corresponding reversal process is called "decryption", which is a transformation that restores encrypted data to its original state. [RFC 2828]
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. An end point indicates a specific location for accessing a service using a specific protocol and data format. [WSD Reqs]
An agent 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.
Property of an interaction whose results and side-effects are the same whether it is done one or multiple times. [RFC 2616]
Safe interactions are inherently idempotent.
An identifier is an unambiguous name for a resource.
The SOAP sender that originates a SOAP message at the starting point of a SOAP message path.
Assuring information will not be accidentally or maliciously altered or destroyed. [NSA Glossary]
Coupling is the dependency between interacting systems. This dependency can be decomposed into real dependency and artificial dependency:
Real dependency is the set of features or services that a system consumes from other systems. The real dependency always exists and cannot be reduced.
Artificial dependency is the set of factors that a system has to comply with in order to consume the features or services provided by other systems. Typical artificial dependency factors are language dependency, platform dependency, API dependency, etc. Artificial dependency always exists, but it or its cost can be reduced.
Loose coupling describes the configuration in which artificial dependency has been reduced to the minimum.
A Web service becomes a manageable service with additional semantics, policy statements, and monitoring and control (or management) capabilities (exposed via a management interface) all for the purpose of managing the service.
The utilization of the management capabilities by the management system in order to perform monitoring of values, tracking of states and control of entities in order to produce and maintain a stable operational environment.
Capabilities that a Web service has for the purposes of controlling or monitoring the service, and that can be exposed to a management system for the sole purpose of managing the service.
Interface through which the management capabilities of a service are exposed.
Policy associated with a Web service solely for the purpose of describing the management obligations and permissions for the service.
The management semantics of a service augment the semantics of a service with management-specific semantics. These management semantics form the contract between the provider entity and the requester entity that expresses the effects and requirements pertaining to the management and management policies for a service.
A message is the basic unit of data sent from one Web services agent to another in the context of Web services.
The basic unit of communication between a Web service and a requester: data to be communicated to or from a Web service as a single logical transmission. [WSD Reqs]
See also SOAP message.
Message correlation is the association of a message with a context. Message correlation ensures that the requester agent can match the reply with the request, especially when multiple replies may be possible.
A Message Exchanage Pattern (MEP) is a template, devoid of application semantics, that describes a generic pattern for the exchange of messages between agents. It describes the relationships (e.g., temporal, causal, sequential, etc.) of multiple messages exchanged in conformance with the pattern, as well as the normal and abnormal termination of any message exchange conforming to the pattern.
Message reliability is the degree of certainty that a message will be delivered and that sender and receiver will both have the same understanding of the delivery status.
A message transport is a mechanism that may be used by agents to deliver messages.
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]
An obligation is a kind of policy that prescribes actions and/or states of an agent and/or resource.
A set of messages related to a single Web service action. [WSD Reqs]
An orchestration defines the sequence and conditions in which one Web service invokes other Web services in order to realize some useful function. I.e., an orchestration is the pattern of interactions that a Web service agent must follow in order to achieve its goal.
A permission is a kind of policy that prescribes the allowed actions and states of an agent and/or resource.
A permission guard is a mechanism deployed on behalf of an owner to enforce permission policies.
A person or organization may be the owner of agents that provide or request Web services.
A policy is a constraint on the behavior of agents or person or organization.
A policy guard is a mechanism that enforces one or more policies. It is deployed on behalf of an owner.
A system entity whose identity can be authenticated. [X.811]
A set of rules and practices that specify or regulate how a person or organization collects, processes (uses) and discloses another party's personal data as a result of an interaction.
An agent that is capable of and empowered to perform the actions associated with a service on behalf of its owner — the provider entity.
The person or organization that is providing a Web service.
A set of formal rules describing how to transmit data, especially across a network. Low level protocols define the electrical and physical standards to be observed, bit- and byte-ordering and the transmission and error detection and correction of the bit stream. High level protocols deal with the data formatting, including the syntax of messages, the terminal to computer dialogue, character sets, sequencing of messages etc. [FOLDOC]
An agent that relays a message between a requester agent and a provider agent, appearing to the Web service to be the requester.
Quality of Service is an obligation accepted and advertised by a provider entity to service consumers.
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]
Authoritative, centrally controlled store of information.
A software agent that wishes to interact with a provider agent in order to request that a task be performed on behalf of its owner — the requester entity.
The person or organization that wishes to use a provider entity's Web service.
Property of an interaction which does not have any significance of taking an action other than retrieval of information. [RFC 2616]
Configuring, securing and/or deploying of systems or applications enabling a security domain.
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]
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.
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]
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.
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]
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]
A mapping of principal identities and/or attributes thereof with allowable actions. Security policy expressions are often essentially access control lists. [STG]
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]
A service is an abstract resource that represents a capability of performing tasks that form a coherent functionality from the point of view of providers entities and requesters entities. To be used, a service must be realized by a concrete provider agent.
WSDL service: A collection of end points. [WSD Reqs]
See Web service.
A service description is a set of documents that describe the interface to and semantics of a service.
A service interface is the abstract boundary that a service exposes. It defines the types of messages and the message exchange patterns that are involved in interacting with the service, together with any conditions implied by those messages.
A logical grouping of operations. An interface represents an abstract service type, independent of transmission protocol and data format. [WSD Reqs]
A service intermediary is a Web service whose main role is to transform messages in a value-added way. (From a messaging point of view, an intermediary processes messages en route from one agent to another.) Specifically, we say that a service intermediary is a service whose outgoing messages are equivalent to its incoming messages in some application-defined sense.
See SOAP intermediary.
See provider agent and provider entity. See also the discussion about service provider in [WS Arch].
See requester agent and requester entity. See also the discussion about service requester in [WS Arch].
An abstract set of tasks which is identified to be relevant by a person or organization offering a service. Service roles are also associated with particular aspects of messages exchanged with a service.
The semantics of a service is the behavior expected when interacting with the service. The semantics expresses a contract (not necessarily a legal contract) between the provider entity and the requester entity. It expresses the effect of invoking the service. A service semantics may be formally described in a machine readable form, identified but not formally defined, or informally defined via an out of band agreement between the provider and the requester entity.
A set of components which can be invoked, and whose interface descriptions can be published and discovered.
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 may not be limited to a single connection between the system entities.
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.
A software entity that produces, consumes or otherwise acts upon SOAP messages in a manner conforming to the SOAP processing model.
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.
A collection of zero or more element information items targeted at an ultimate SOAP receiver in the SOAP message path.
The outermost element information item of a SOAP message.
A SOAP element information item which contains fault information generated by a SOAP node.
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.
A collection of zero or more SOAP header blocks each of which might be targeted at any SOAP receiver within the SOAP message path.
An element information item used to delimit data that logically constitutes a single computational unit within the SOAP header. The type of a SOAP header block is identified by the fully qualified name of the header block element information item.
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.
The basic unit of communication between SOAP nodes.
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.
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.
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.
A SOAP node that accepts a SOAP message.
A SOAP node's expected function in processing a message. A SOAP node can act in multiple roles.
A SOAP node that transmits a SOAP message.
A set of attributes representing the properties of a component at some point in time.
An interaction is said to be synchronous when the participating agents must be available to receive and process the associated messages from the time the interaction is initiated until all messages are actually received or some failure condition is determined. The exact meaning of "available to receive the message" depends on the characteristics of the participating agents (including the transfer protocol it uses); it may, but does not necessarily, imply tight time synchronization, blocking a thread, etc.
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]
Transaction is a feature of the architecture that supports the coordination of results or operations on state in a multi-step interaction. The fundamental characteristic of a transaction is the ability to join multiple actions into the same unit of work, such that the actions either succeed or fail as a unit.
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.
Service that reliably and securely records usage-related events producing an audit trail enabling the reconstruction and examination of a sequence of events. Usage events could include resource allocation events and resource freeing events.
There are many things that might be called "Web services" in the world at large. However, for the purpose of this Working Group and this architecture, and without prejudice toward other definitions, we will use the following definition:
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
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): Geoff Arnold (Sun Microsystems, Inc.), Mukund Balasubramanian (Infravio, Inc.), Mike Ballantyne (EDS), Abbie Barbir (Nortel Networks), David Booth (W3C), Mike Brumbelow (Apple), Doug Bunting (Sun Microsystems, Inc.), Greg Carpenter (Nokia), Tom Carroll (W. W. Grainger, Inc.), Alex Cheng (Ipedo), Michael Champion (Software AG), Martin Chapman (Oracle Corporation), Ugo Corda (SeeBeyond Technology Corporation), Roger Cutler (ChevronTexaco), Jonathan Dale (Fujitsu), Suresh Damodaran (Sterling Commerce(SBC)), James Davenport (MITRE Corporation), Paul Denning (MITRE Corporation), Gerald Edgar (The Boeing Company), Shishir Garg (France Telecom), Hugo Haas (W3C), Hao He (The Thomson Corporation), Dave Hollander (Contivo), Yin-Leng Husband (Hewlett-Packard Company), Mario Jeckle (DaimlerChrysler Research and Technology), Heather Kreger (IBM), Sandeep Kumar (Cisco Systems Inc), Hal Lockhart (OASIS), Michael Mahan (Nokia), Francis McCabe (Fujitsu), Michael Mealling (VeriSign, Inc.), Jeff Mischkinsky (Oracle Corporation), Eric Newcomer (IONA), Mark Nottingham (BEA Systems), David Orchard (BEA Systems), Bijan Parsia (MIND Lab), Adinarayana Sakala (IONA), Waqar Sadiq (EDS), Igor Sedukhin (Computer Associates), Hans-Peter Steiert (DaimlerChrysler Research and Technology), Katia Sycara (Carnegie Mellon University), Bryan Thompson (Hicks & Associates, Inc.), Sinisa Zimek (SAP).
Previous members of the Working Group were: Assaf Arkin (Intalio, Inc.), Daniel Austin (W. W. Grainger, Inc.), Mark Baker (Idokorro Mobile, Inc. / Planetfred, Inc.), Tom Bradford (XQRL, Inc.), Allen Brown (Microsoft Corporation), Dipto Chakravarty (Artesia Technologies), Jun Chen (MartSoft Corp.), Alan Davies (SeeBeyond Technology Corporation), Glen Daniels (Macromedia), Ayse Dilber (AT&T), Zulah Eckert (Hewlett-Packard Company), Colleen Evans (Sonic Software), Chris Ferris (IBM), Daniela Florescu (XQRL Inc.), Sharad Garg (Intel), Mark Hapner (Sun Microsystems, Inc.), Joseph Hui (Exodus/Digital Island), Michael Hui (Computer Associates), Nigel Hutchison (Software AG), Marcel Jemio (DISA), Mark Jones (AT&T), Timothy Jones (CrossWeave, Inc.), Tom Jordahl (Macromedia), Jim Knutson (IBM), Steve Lind (AT&T), Mark Little (Arjuna), Bob Lojek (Intalio, Inc.), Anne Thomas Manes (Systinet), Jens Meinkoehn (T-Nova Deutsche Telekom Innovationsgesellschaft), Nilo Mitra (Ericsson), Don Mullen (TIBCO Software, Inc.), Himagiri Mukkamala (Sybase, Inc.), Joel Munter (Intel), Henrik Frystyk Nielsen (Microsoft Corporation), Duane Nickull (XML Global Technologies), David Noor (Rogue Wave Software), Srinivas Pandrangi (Ipedo), Kevin Perkins (Compaq), Mark Potts (Talking Blocks, Inc), Fabio Riccardi (XQRL, Inc.), Don Robertson (Documentum), Darran Rolls (Waveset Technologies, Inc.), Krishna Sankar (Cisco Systems Inc), Jim Shur (Rogue Wave Software), Patrick Thompson (Rogue Wave Software), Steve Vinoski (IONA), Scott Vorthmann (TIBCO Software, Inc.), Jim Webber (Arjuna), Prasad Yendluri (webMethods, Inc.), Jin Yu (MartSoft Corp.) .
The people who have contributed to discussions on the www-ws-arch public mailing list are also gratefully acknowledged.