Web Services Glossary

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:

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

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

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

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.

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.2 Data Encapsulation Concepts

SOAP message: The basic unit of communication between SOAP nodes.
SOAP envelope: The outermost element information item of a SOAP message.
SOAP header: A collection of zero or more SOAP header blocks each of which might be targeted at any SOAP receiver within the SOAP message path.
SOAP header block (or just header block): 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.
SOAP body: A collection of zero or more element information items targeted at an ultimate SOAP receiver in the SOAP message path.
SOAP fault: A SOAP element information item which contains fault information generated by a SOAP node.

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

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]

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