Web Services Glossary

W3C Working Draft 8 August 2003

This version:
Latest version:
Previous version:
Hugo Haas, W3C
Allen Brown, Microsoft (until June 2002)


This document is a glossary of terms found in the Web services architecture [WS Arch]. Additionally, it is intended for use by the other Working Groups in 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.

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 9 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. 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 the third public Working Draft 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. Since the last publication, the definition of Web service has been updated. Future work on this document will be spent merging concepts and definition from [WS Arch] and this document. 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.

Publication as a Working Draft 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.'

Table of Contents

1 Introduction: Terminology Process
2 General Terms
3 Core concepts
4 Choreography definitions
5 Service Properties
6 SOAP Specific Definitions
6.1 Protocol Concepts
6.2 Data Encapsulation Concepts
6.3 Message Sender and Receiver Concepts
7 Security and Privacy Related Terms
8 Management Terms
9 References


A Acknowledgements (Non-Normative)
B Web Services Glossary Change Log (Non-Normative)

1 Introduction: 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 General Terms

Editorial note
The Web Services Description Working Group changed some its terminology. This needs to be reflected.
  1. A legal entity — such as a person or a corporation — that may be the owner of agents that either seek to use Web services or provide Web services.

  2. 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.


Program acting on behalf of another person, entity, or process. [Web Arch]

architectural element

Generic term referring to a part of an architecture such as a component, connector, or data. Relationships between elements are constrained in order to achieve a desired set of architectural properties.

  1. 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])

  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. [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.


In the context of Web services, the term "asynchronous" is used informally to describe certain message exchange patterns. See synchronous for a more detailed treatment of this topic.


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]

  1. 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]

  2. The mapping of an interface and its associated operations to a particular concrete message format and transmission protocol.

  3. See also SOAP binding.


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]

  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. [Fielding]

  3. A component is a unit of architecture with defined boundaries.


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


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


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


A logical sequence of messages exchanged between communicating parties.


The act of locating a machine-processable description of a Web service that may have been previously unknown and that meets certain functional criteria.


Any data that can be represented in a digital form. [UeB Glossary]

Electronic Data Interchange (EDI)

The automated exchange of any predefined and structured data for business among information systems of two or more organizations. [ISO/IEC 14662]

end point
Editorial note
What is the relationship with a node?

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]

end user

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

  1. An abstract piece of functionality.

  2. See also SOAP feature.

Editorial note
Needs to be clarified. Is the relationship with proxy accurate?

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.


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.


Realization of a specification. [NIST]

  1. The boundary between components through which they interact.

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

  1. A node is an intermediary if a message from the service requester to the service provider (or vice versa) passes through the node.

  2. See SOAP intermediary.

loose coupling

Coupling is the dependency between interacting systems. Dependency can be decomposed into real dependency and artificial dependency:

  1. Real dependency is the set of features or services that a system consumes from other systems. Real dependency always exists and cannot be reduced.

  2. 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 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.

  1. 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]

  2. See also SOAP message.

message exchange pattern (MEP)
  1. A MEP is a template that establishes a pattern for the exchange of messages between SOAP nodes. A MEP MAY be supported by one or more underlying protocol binding instances.

    This section is a logical description of the operation of a MEP. It is not intended to describe a real implementation or to imply that a real implementation needs to be similarly structured.

    In general the definition of a message exchange pattern:

    Underlying protocol binding specifications can declare their support for one or more named MEPs.

    The terms synchronous and asynchronous are sometimes used to characterize MEPs. Such usage is informal, and it is recommended that documents should not rely on these terms in any normative specification. See synchronous for a more detailed discussion of this.

  2. See SOAP message exchange pattern (MEP).

  1. A sytem entity which takes part into a message exchange. Examples are: requester, Web service, an intermediary, a gateway, a proxy, etc.

  2. See SOAP node.


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

  1. See end point. [WSD Reqs]

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

port type

See interface. [WSD Reqs]


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]

Editorial note
Needs to be clarified; see gateway

A node that relays a message between a requester and a Web service, appearing to the Web service to be the the requester.

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]


A system entity that provides service and service provider information.

reliable messaging
Editorial note
This definition is out of sync with the architecture document definition and needs to be reworked.

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.


Electronic store of structured information. [UeB Glossary]


An abstract entity that has a particular set of responsibilities or behaviors. A role must be implemented by one or more actors. Compare actor.


Property of an interaction which does not have any significance of taking an action other than retrieval of information. [RFC 2616]

  1. Component capable of performing a task.

  2. WSDL service: A collection of end points. [WSD Reqs]

  3. See Web service.

service agreement

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

service provider

A legal entity that provides a Web service.

service-oriented architecture

A set of components which can be invoked, and whose interface descriptions can be published and discovered.

service requester / service requestor

The entity that is responsible for requesting a service from a service provider.


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.


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


In the context of Web services, the term "synchronous" is used informally to describe certain message exchange patterns (MEPs).

In principle, MEPs may be arbitrarily complex, and may include various temporal relationships between messages. In practice, there is a small number of patterns for which the temporal relationships are well (if informally) understood. MEPs which describe temporally coupled or "lock-step" interactions are frequently referred to as "synchronous". Examples include RPC-style request-response interactions and some kinds of transactional exchanges. Other MEPs allow messages to be sent without precise sequencing, and these are described as "asynchronous". Examples include a flow of sensor event messages which need not be individually acknowledged, and an auction in which parties may submit bids at any time during the auction.

The terms "synchronous" and "asynchronous" are descriptive, and do not correspond precisely to properties of MEPs. Occasionally the terms may be associated with particular message transport features, such as the re-use of a session. While specific implementations may support such notions, a dependency on such a feature would violate protocol independence, and therefore be problematic.

It is also worth noting that in some computing platforms or message transport systems the terms "synchronous" and "asynchronous" are perfectly well defined. For example many APIs include "asynchronous I/O" support, and certain message-oriented middleware systems offer synchronous and asynchronous notification and delivery modes. However, Web services are defined as platform- and transport- independent, and relying on implementation-specific terms is likely to result in confusion.

Many (most?) Web services do not use published MEP's, but instead rely on more or less informal patterns and techniques. In such cases, the terms "synchronous" and "asynchronous" are sometimes used to indicate the type of informal pattern being used. They may indicate whether or not coordination and synchronization techniques such as correlation data and particular transport bindings are to be used.

In view of the informal way that the terms are used, it is recommended that documents should not rely upon the use of "synchronous" or "asynchronous" in any normative specification.

system entity
Editorial note
Relationship with component?

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]


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]


See end user.

Web site

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

Web service

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.

3 Core concepts

Editorial note2003-04-17
The definitions in this sections were extracted from the refactored version of the architecture document dated 2003-04-01. Work is underway to consolidate the two documents. Definitions have been omitted when identical. Not all of the definitions below belong to the glossary. This section is being reworked.
Editorial note
In glossary and being worked on by the WSCWG

Choreographies define how multiple web services are used together, specifying the linkages and usage patterns involved. The linkages between Web Services consist of interactions between those services implemented by sending messages between those Web Services, for example by invoking operations as defined in WSDL.

Editorial note
Missing from the glossary

Correlation is the association of matching messages. Correlation ensures that the agent requesting a service execution can match the reply with the request, especially when multiple replies may be possible.

deployed resources
Editorial note
Proposal: keep out of the glossary

A deployed resource is a resource that exists in the physical world.

discovery service
Editorial note
Proposal: keep out of the glossary

A discovery service is a service that performs discovery.

Editorial note
Slightly different from the current glossary one, but close; defs need to be merged

A registry contains service descriptions that service providers publish.

Editorial note
Relates to existing glossary defininition; defs need to be merged

A feature is a subset of the architecture that relates to a particular requirement or larger scale property. A key aspect of features is that they may have realizations, possibly within the architecture itself.

Editorial note
Relationship with identification; should merge both

An identifier is a preferably opaque string of bits that may be used to associate with a resource.

legal entity
Editorial note
Missing from glossary although it is used in several places; synonym of actor in the glossary.

A legal entity such as a person or a corporation -- may be the owner of agents that provide or request Web services.

manageable element
Editorial note
Very close to the definition of manageable; should probably be dropped from the glossary.

A manageable element is a deployed element that is manageable, i.e., a physically existing resource that is capable of being managed. A key attribute of manageable elements is that they provide an interface to allow their management.

manageability interface
Editorial note
Different from the definition of the MTF

A manageability interface is a description of the means by which a management system can manage a manageable element.

Editorial note
This is the glossary definition with an additional description of the role of messages in the architecture; the glossary should probably keep its current one, leaving additional description to the architecture document

A message is the basic unit of interaction with Web services. The architecture defines an interaction between software agents as an exchange of messages.

message exchange pattern
Editorial note
Significantly different from the glossary; MEPs need to be worked on by the WG

A message exchange pattern is a minimal set of messages, together with their sender and receivers, that constitutes a single use of a service.

message header
Editorial note
Missing from the glossary; unsure about the second statement (e.g. SOAP headers just verify the first property); there is no definition of the concept of an intermediary in the architecture document

A message header is the part of the message that is available to any potential intermediaries and contains information about the message, such as its structure and the identity of the service provider.

message description language
Editorial note
Missing from the glossary; suggestion: do not include in the glossary

A message description language allows the structure of messages to be described.

message identifier
Editorial note
Missing from the glossary

A message identifier is an identifier that uniquely identifies a message.

message recipient
Editorial note
Missing from the glossary

A message recipient is the agent that is intended -- by the message's sender -- to consume the message.

message sender
Editorial note
Missing from the glossary

A message sender is the agent that originates a message.

Editorial note
Missing from the glossary

A representationis a data object that represents or describes a resource state, and is the vehicle for conveying the meaning of a resource. A resource is an abstraction for which there is a conceptual mapping to a (possibly empty) set of representations.

Editorial note
Missing from the glossary

A resource is defined by [RFC 2396] to be anything that has an identifier.

Editorial note
Should probably be merged with glossary definition number one

A service is a set of actions that form a coherent whole from the point of view of a service provider.

service description


service provider
Editorial note
Defined in the glossary


service semantics
Editorial note
Relationship with service agreement and service level agreement? Fairly close to service agreement

The semantics of a service is the contract between the service provider and the service requestor that 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 requestor.

Editorial note
Missing from the glossary; the two sentences should probably be swapped.

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. Transaction is a feature of the architecture that supports the coordination of results or operations on state in a multi-step interaction.

4 Choreography definitions

Editorial note: HH
This section holds choreography-related definitions. Eventually, it will be moved elsewhere. It is being worked on by the Web Services Choreography Working Group and their result will be integrated to this document, replacing the definitions below.
Editorial note
Definition in progress: the above definition was the original proposal.

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.

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 Service Properties

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

@@@ From AR024.3







6 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].

6.1 Protocol Concepts


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.

6.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.

7 Security and Privacy Related Terms


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]


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]


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

security 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.


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]


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]


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


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

digital signature

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]


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]


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

login (also: 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]


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


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 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 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 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

8 Management Terms

Editorial note: HH
Need to work on consistency. See comments to the MTF.

Configuring and/or securing entities.

administration interface

Interface through which administration capabilities are offered.

Editorial note
Needs more work; in progress.

The property that a service offered by a service provider can be consumed by a service consumer. The service is said to be available to the consumer.


Being able to respond to a new request for service.


A measurement interval type such that a measurement is calculated relative to the last time the service status was changed to "Up".


A collection of properties which may be changed. A property may influence the behavior of an entity.


To cause a desired change in state. Management systems may control the lifecycle of entities or information flow such as messages.


A change in state.

event description
Editorial note
In progress.

Messages that indicate a problem, a lifecycle state change or a state change.

Editorial note
In progress; why uniquely?

Read-only data that uniquely identifies the element. This data may include information that is not required for unique identification as well.


The set of stage between creation and demise of a component.


Property whereby the possessor of the property provides a sufficient set of management capabilities such that it is manageable.

manageability interface

Interface through which management capabilities are offered.


Capable of being managed by a management system.

Editorial note

Being actively managed by a management system.

Editorial note
Circular definition; still under work

The utilization of the management capabilities by the management system. A management system may perform monitoring (of values), tracking (of states) and control of entities in order to produce and maintain a stable operational environment.

management endpoint
Editorial note

Endpoint for management purposes.

management capability

Capability in either providing information or performing actions for management purposes. Management capabilities include providing identification, configuration, metrics, status, notifications of events, and performing operations for management purposes.

management operation
Editorial note
Is that needed?

An operation that performs management.

management system


Editorial note
There was some discussions about using another term for this; in progress. Note that metric is already defined.

Raw atomic, unambiguous, information, e.g. number of invocations.

Editorial note
In progress

Value calculated with a formula based on metrics, e.g. the verage response time during the last hour of execution.

performance monitoring

The monitoring of an entity to ascertain its operational speed, utilization, and efficiency.

resource accounting

The monitoring and tracking of resources used by a running entity.

security administration

Configuring, securing and/or deploying of systems or applications enabling a security domain.

service level agreements

Agreement between a service provider and a service consumer concerning the quality and usage of the service provided.

sliding window

A measurement interval type such that a measurement is calculated for a time interval relative to now, i.e. the last 10 minutes, the last hour.

Editorial note
In progress.

Information about the operational state of an element.

time interval
Editorial note

A measurement interval type such that a measurement is calculated for a time interval between two time stamps.

usage auditing

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.

usage tracking
Editorial note
What is the difference with usage auditing?

Tracking of the usage of a specific resource.

9 References

CCA Terms and Definitions, CCA Forum, Kate Keahey (See http://www.acl.lanl.gov/cca/terms.html.)
Architectural Styles and the Design of Network-based Software Architectures, PhD dissertation, R. Fielding, 2000 (See http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.)
The Free On-line Dictionary of Computing, D. Howe (See http://www.foldoc.org/.)
INFOSEC Glossary
National Information Systems Security (INFOSEC) Glossary, National Security Telecommunications and Information Systems Security Instruction (NSTISSI) No. 4009, 5 June 1992
ISO/IEC 14662
Information technology -- Open-edi reference model, International Standard, ISO/IEC 14662:1997 (See http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=25154.)
NSA Glossary
NSA Glossary of Terms Used in Security and Intrusion Detection, NSA, April 1998 (See http://www.sans.org/newlook/resources/glossary.htm.)
What is this thing called Conformance? (See http://www.itl.nist.gov/div897/ctg/conformance/bulletin-conformance.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.)
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.)
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 Recommendation, M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Nielsen, 24 June 2003 (See http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.)
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.)
UeB Glossary
UN/CEFACT eBusiness Glossary, UN/CEFACT Working Draft Revision 0.53, 13 December 2002
Web Arch
Architecture of the World-Wide Web, W3C Working Draft, I. Jacobs, 27 June 2003 (See http://www.w3.org/TR/2003/WD-webarch-20030627/.)
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, D. Booth, H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, D. Orchard, 8 August 2003 (See http://www.w3.org/TR/2003/WD-ws-arch-20030808/.)
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, 28 October 2002 (See http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028/.)
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.)
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.)
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.)

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): Geoff Arnold (Sun Microsystems, Inc.), Daniel Austin (W. W. Grainger, 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.), Jun Chen (MartSoft Corp.), 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)), Glen Daniels (Macromedia), James Davenport (MITRE Corporation), Paul Denning (MITRE Corporation), Zulah Eckert (Hewlett-Packard Company), Gerald Edgar (The Boeing Company), Chris Ferris (IBM), 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), Mark Jones (AT&T), Tom Jordahl (Macromedia), Heather Kreger (IBM), Sandeep Kumar (Cisco Systems Inc), Steve Lind (AT&T), Mark Little (Arjuna), Hal Lockhart (OASIS), Michael Mahan (Nokia), Francis McCabe (Fujitsu), Michael Mealling (VeriSign, Inc.), Jeff Mischkinsky (Oracle Corporation), Himagiri Mukkamala (Sybase, Inc.), Don Mullen (TIBCO Software, Inc.), Eric Newcomer (IONA), Mark Nottingham (BEA Systems), David Orchard (BEA Systems), Srinivas Pandrangi (Ipedo), Leo Parker (Computer Associates), Mark Potts (Talking Blocks, Inc), Waqar Sadiq (EDS), Igor Sedukhin (Computer Associates), Hans-Peter Steiert (DaimlerChrysler Research and Technology), Katia Sycara (Carnegie Mellon University), Bryan Thompson (Hicks & Associates, Inc.), Steve Vinoski (IONA), Jim Webber (Arjuna), Prasad Yendluri (webMethods, Inc.), Jin Yu (MartSoft Corp.), Sinisa Zimek (SAP).

Previous members of the Working Group were: Assaf Arkin (Intalio, Inc.), Mark Baker (Idokorro Mobile, Inc. / Planetfred, Inc.), Tom Bradford (XQRL, Inc.), Allen Brown (Microsoft Corporation), Dipto Chakravarty (Artesia Technologies), Alan Davies (SeeBeyond Technology Corporation), Ayse Dilber (AT&T), Colleen Evans (Sonic Software), Daniela Florescu (XQRL Inc.), Sharad Garg (Intel), Joseph Hui (Exodus/Digital Island), Marcel Jemio (DISA), Timothy Jones (CrossWeave, Inc.), Jim Knutson (IBM), Mark Hapner (Sun Microsystems, Inc.), Michael Hui (Computer Associates), Nigel Hutchison (Software AG), Bob Lojek (Intalio, Inc.), Anne Thomas Manes (Systinet), Jens Meinkoehn (T-Nova Deutsche Telekom Innovationsgesellschaft), Nilo Mitra (Ericsson), Joel Munter (Intel), Henrik Frystyk Nielsen (Microsoft Corporation), Duane Nickull (XML Global Technologies), David Noor (Rogue Wave Software), Kevin Perkins (Compaq), 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), Scott Vorthmann (TIBCO Software, Inc.).

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

B Web Services Glossary Change Log (Non-Normative)

2003-07-30HHUpdated definition of Web service
2003-05-12HHUpdated definitions of synchronous and asynchronous and abstract.
2003-05-07HHIntegrated definitions of synchronous and asynchronous.
2003-05-06HHIntegrated comments from Roger.
2003-04-23HHMerged sections "Architecture Terms", "General Terms" and "Roles".
2003-04-17HHAdded core concepts from the architecture document.
2003-04-01HHChanged definition of binding as per Jean-Jacques's email; updated the definition of service requester to match the one in the Web Services Architecture draft in an attempt to fix the definition of client — will need a major reconciliation between the two documents.
2003-03-11HHIncorporated management definitions from the MTF. Removed prior information definition. Integrated comments from DaviB and from Jean-Jacques.
2003-02-17HH Renamed a-priori into prior. For details, see Hugo's email and issue 1.
2003-02-10HHebXML glossary review; incorporated changes: set 1, definition, set 2
2003-02-04HHAdded new definition of discovery from David Booth
2003-02-03HHAdded definition of loose coupling
2003-01-31HHAdded definition of safe and idempotent
2003-01-29HHIncorporated face-to-face changes
20021202DBOAdded "Agent"
2002-11-14HHFirst TR version