Web Services Glossary

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

actor

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.

agent

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.

architecture

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]

artifact

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.

asynchronous

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.

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. [WSIA Glossary]

binding

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.

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]

component

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

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

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

configuration

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

connection

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

connector

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

conversation

A logical sequence of messages exchanged between communicating parties.

discovery

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

document

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]

feature

1. An abstract piece of functionality.

2. See also SOAP feature.

gateway

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.

idempotent

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.

implementation

Realization of a specification. [NIST]

interface

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]

intermediary

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.

metric

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

message

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:

   • Is named by a URI.

   • Describes the life cycle of a message exchange conforming to the pattern.

   • Describes the temporal/causal relationships of multiple messages exchanged in conformance with the pattern.

   • Describes the normal and abnormal termination of a message exchange conforming to the 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).

node

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.

operation

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

port

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]

protocol

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]

proxy

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]

registry

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.

repository

Electronic store of structured information. [UeB Glossary]

role

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

safe

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

service

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.

session

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

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

state

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

synchronous

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]

time-out

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

user

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

Editorial note
Need to reconciliate the definition of Web service and service (in particular with regards to the WSDL 1.2 definition).

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

2. See also service.

3 Core concepts

choreography

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.

correllation

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.

registry

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.

feature

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.

identifier

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.

message

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.

representation

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.

resource

Editorial note
Missing from the glossary

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

service

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.

transaction

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

choreography

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

capability

@@@ From AR024.3

evolvability

@@@

reliability

@@@

stability

@@@

6 SOAP Specific Definitions

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

7 Security and Privacy Related Terms

access

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

access control

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

access control information

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

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

access rights

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

account

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

anonymity

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

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.

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]

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]

encryption

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]

integrity

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]

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

administration

Configuring and/or securing entities.

administration interface

Interface through which administration capabilities are offered.

availability

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.

available

Being able to respond to a new request for service.

cumulative

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

configuration

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

control

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

event

A change in state.

event description

Editorial note
In progress.

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

identification

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.

lifecycle

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

manageability

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.

manageable

Capable of being managed by a management system.

managed

Editorial note
Circular

Being actively managed by a management system.

management

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
Obscure

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

@@@

metrics

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.

measurement

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.

status

Editorial note
In progress.

Information about the operational state of an element.

time interval

Editorial note
Circular.

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 T&D

CCA Terms and Definitions, CCA Forum, Kate Keahey (See http://www.acl.lanl.gov/cca/terms.html.)

Fielding

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

FOLDOC

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

NIST

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

STG

Security Taxonomy and Glossary, L. Wheeler (See http://www.garlic.com/~lynn/secure.htm.)

SOAP12 Part1

SOAP Version 1.2 Part 1: Messaging Framework, W3C Working Draft, M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Nielsen, 26 June 2002 (See http://www.w3.org/TR/2002/WD-soap12-part1-20020626.)

TIC Glossary

Trust in Cyberspace Glossary, ISBN 0-309-06558-5, F. Schneider, Editor; Committee on Information Systems Trustworthiness, National Research Council, 1999 (See http://www.nap.edu/readingroom/books/trust/trustapk.htm.)

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, 15 November 2002 (See http://www.w3.org/TR/2002/WD-webarch-20021115/.)

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, M. Champion, C. Ferris, F. McCabe, E. Newcomer, D. Orchard, 14 May 2003 (See http://www.w3.org/TR/2003/WD-ws-arch-20030514/.)

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

X.800

Information processing systems Open Systems Interconnection Basic Reference Model Part 2: Security Architecture, ISO 7498-2:1989, ITU-T Recommendation X.800 (1991) (See http://www.itu.int/itudoc/itu-t/rec/x/x500up/x800.html.)

X.811

Security Frameworks for Open Systems: Authentication Framework, ITU-T Recommendation X.811 (1995 E), ISO/IEC 10181-2:1996(E) (See http://www.itu.int/itudoc/itu-t/rec/x/x500up/x811.html.)

X.812

Security frameworks for open systems: Access control framework, ITU-T Recommendation X.812 (1995 E), ISO/IEC 10181-3:1996(E) (See http://www.itu.int/itudoc/itu-t/rec/x/x500up/x812.html.)