You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
859 lines
64 KiB
859 lines
64 KiB
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /><title>Web Services Glossary</title><style type="text/css">
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
li p { margin-top: 0.3em;
|
|
margin-bottom: 0.3em; }
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
div.figure { text-align: center; }
|
|
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css" /></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a></p>
|
|
<h1><a name="title" id="title"></a>Web Services Glossary</h1>
|
|
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Group Note 11 February 2004</h2><dl><dt>This version:</dt><dd>
|
|
<a href="http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/">http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/</a>
|
|
</dd><dt>Latest version:</dt><dd>
|
|
<a href="http://www.w3.org/TR/ws-gloss/">http://www.w3.org/TR/ws-gloss/</a>
|
|
</dd><dt>Previous version:</dt><dd>
|
|
<a href="http://www.w3.org/TR/2003/WD-ws-gloss-20030808/">http://www.w3.org/TR/2003/WD-ws-gloss-20030808/</a>
|
|
</dd><dt>Editors:</dt><dd>Hugo Haas, W3C</dd><dd>Allen Brown, Microsoft (until June 2002)</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2004 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p></div><hr /><div>
|
|
<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>This document is a glossary of Web services
|
|
terms defined and used in the Web Services Architecture
|
|
<a href="#WSA">[WS Arch]</a>. It is intended for use by
|
|
Web services spefications in order to refer to a common
|
|
coherent framework.</p></div><div>
|
|
<h2><a name="status" id="status"></a>Status of this Document</h2><p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a> at
|
|
http://www.w3.org/TR/.</em></p><p>This is a public <a href="http://www.w3.org/2003/06/Process-20030618/tr.html#q71">Working
|
|
Group Note</a> of the Web Services Glossary. It has been
|
|
produced by the <a href="http://www.w3.org/2002/ws/arch/">W3C
|
|
Web Services Architecture Working Group</a>, which is part of
|
|
the <a href="http://www.w3.org/2002/ws/Activity">W3C Web
|
|
Services Activity</a>. This publication as a Working Group
|
|
Note coincides with the end of the Working Group's charter
|
|
period.</p><p>Discussion of this document is invited on the public mailing list <a href="mailto:www-ws-arch@w3.org">www-ws-arch@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/www-ws-arch/">public
|
|
archives</a>).</p><p>Patent disclosures relevant to this document may be found
|
|
on the Working Group's <a href="http://www.w3.org/2002/ws/arch/2/04/24-IPR-statements">patent
|
|
disclosure page</a>.</p><p>Publication as a Working Group Note does not imply
|
|
endorsement by the W3C Membership. This is a draft document
|
|
and may be updated, replaced or obsoleted by other documents
|
|
at any time. It is inappropriate to cite this document as
|
|
other than work in progress. Other documents may supersede this document.</p></div><div class="toc">
|
|
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1 <a href="#intro">Introduction</a><br />
|
|
2 <a href="#defs">Definitions</a><br />
|
|
3 <a href="#ref">References</a><br />
|
|
</p>
|
|
<h3><a name="appendices" id="appendices"></a>Appendix</h3><p class="toc">A <a href="#id2273823">Acknowledgements</a> (Non-Normative)<br />
|
|
</p></div><hr /><div class="body"><div class="div1">
|
|
<h2><a name="intro" id="intro"></a>1 Introduction</h2><p> This document contains a list of Web
|
|
services terms that are part of a coherent
|
|
framework defined in the Web Services
|
|
Architecture <a href="#WSA">[WS Arch]</a>.
|
|
The relationships between the terms
|
|
are defined in the concepts and
|
|
relationships section of <a href="#WSA">[WS Arch]</a>.
|
|
</p><p>Terms are capitalized when it is meaningful, or otherwise are defined in lowercase.</p><p>Some definitions in this document are derived verbatim from
|
|
external documents. In such cases, the source is indicated as
|
|
a reference, listed in the <a href="#ref"><b>3 References</b></a> section.</p></div><div class="div1">
|
|
<h2><a name="defs" id="defs"></a>2 Definitions</h2><dl><dt class="label"><a name="access" id="access"></a>access</dt><dd><p>To interact with a <a title="" href="#systementity">system
|
|
entity</a> in order to manipulate, use, gain
|
|
knowledge of, and/or obtain a representation of some
|
|
or all of a system entity's resources. <a href="#RFC2828">[RFC 2828]</a>
|
|
</p></dd><dt class="label"><a name="ac" id="ac"></a>access control</dt><dd><p>Protection of resources against unauthorized access; a
|
|
process by which use of resources is regulated according
|
|
to a
|
|
<a title="" href="#securitypolicy">security policy</a>
|
|
and is permitted by only authorized system
|
|
entities according to that policy. <a href="#RFC2828">[RFC 2828]</a>
|
|
</p></dd><dt class="label"><a name="acinformation" id="acinformation"></a>access control information</dt><dd><ol type="1"><li><p>Any information used for <a title="" href="#ac">access
|
|
control</a> purposes, including contextual
|
|
information. <a href="#X812">[X.812]</a>
|
|
</p></li><li><p>Contextual information might
|
|
include source IP address, encryption strength, the
|
|
type of
|
|
operation being requested, time of day, etc. Portions
|
|
of
|
|
<a title="" href="#ac">access control</a> information
|
|
may be specific to the request
|
|
itself, some may be associated with the <a title="" href="#connection">connection</a> via which
|
|
the request is transmitted, and others (for example,
|
|
time of
|
|
day) may be "environmental". <a href="#RFC2829">[RFC 2829]</a>
|
|
</p></li></ol></dd><dt class="label"><a name="accessrights" id="accessrights"></a>access rights</dt><dd><p>A description of the type of authorized interactions a
|
|
subject
|
|
can have with a resource. Examples include read, write,
|
|
execute, add, modify, and delete. <a href="#WSIAG">[WSIA Glossary]</a>
|
|
</p></dd><dt class="label"><a name="actor" id="actor"></a>actor</dt><dd><ol type="1"><li><p>A <a title="" href="#poo">person or organization</a> that may be the owner of <a title="" href="#agent">agents</a> that either seek to use <a title="" href="#webservice">Web services</a> or provide Web services.</p></li><li><p>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.
|
|
</p></li></ol></dd><dt class="label"><a name="agent" id="agent"></a>agent</dt><dd><p>An agent is a program acting on behalf of a <a title="" href="#poo">person or organization</a>. (This
|
|
definition is a specialization of the definition in
|
|
<a href="#webarch">[Web Arch]</a>. It corresponds to the notion of
|
|
software agent in <a href="#webarch">[Web Arch]</a>.)</p></dd><dt class="label"><a name="anonimity" id="anonimity"></a>anonymity</dt><dd><p>The quality or
|
|
<a title="" href="#state">state</a> of being anonymous,
|
|
which is the
|
|
condition of having a name or identity that is unknown or
|
|
concealed. <a href="#RFC2828">[RFC 2828]</a>
|
|
</p></dd><dt class="label"><a name="architecture" id="architecture"></a>architecture</dt><dd><ol type="1"><li><p>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
|
|
<a href="#SAP">[Soft Arch Pract]</a>)</p></li><li><p>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. <a href="#RoyFieldingThesis">[Fielding]</a>
|
|
</p></li></ol></dd><dt class="label"><a name="artifact" id="artifact"></a>artifact</dt><dd><p>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.</p></dd><dt class="label"><a name="asynchronous" id="asynchronous"></a>asynchronous</dt><dd><p>An interaction is said to be asynchronous when the
|
|
associated messages are chronologically and procedurally
|
|
decoupled. For example, in a request-response interaction, the client
|
|
agent can process the response at some indeterminate point in the
|
|
future when its existence is discovered. Mechanisms to do this include
|
|
polling, notification by receipt of another message, etc.</p></dd><dt class="label"><a name="attribute" id="attribute"></a>attribute</dt><dd><p>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. <a href="#WSIAG">[WSIA Glossary]</a>
|
|
</p></dd><dt class="label"><a name="auditguard" id="auditguard"></a>audit guard</dt><dd><p>
|
|
An audit guard is a mechanism used on behalf of an owner
|
|
that monitors actions and <a title="" href="#agent">agents</a> to verify the satisfaction
|
|
of <a title="" href="#obligation">obligations</a>.
|
|
</p></dd><dt class="label"><a name="authentication" id="authentication"></a>authentication</dt><dd><p>Authentication is the process of verifying that a
|
|
potential partner in a conversation is capable of representing a <a title="" href="#poo">person or organization</a>.</p></dd><dt class="label"><a name="authorization" id="authorization"></a>authorization</dt><dd><p>The process of
|
|
determining, by evaluating applicable <a title="" href="#acinformation">access
|
|
control information</a>, 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. <a href="#STG">[STG]</a>
|
|
</p></dd><dt class="label"><a name="binding" id="binding"></a>binding</dt><dd><ol type="1"><li><p>An association between an <a title="" href="#interface">interface</a>, a concrete
|
|
<a title="" href="#protocol">protocol</a> and a data
|
|
format. A binding specifies the
|
|
protocol and data format to be used in transmitting
|
|
messages defined by the associated interface. <a href="#WSDReqs">[WSD Reqs]</a>
|
|
</p></li><li><p>The mapping of an <a title="" href="#interface">interface</a> and its associated <a title="" href="#operation">operations</a> to a particular concrete message
|
|
format and transmission <a title="" href="#protocol">protocol</a>.</p></li><li><p>See also <a title="" href="#soapbinding">SOAP
|
|
binding</a>.</p></li></ol></dd><dt class="label"><a name="capability" id="capability"></a>capability</dt><dd><p>A capability is a named piece of functionality (or
|
|
feature) that is declared as supported or requested by an
|
|
<a title="" href="#agent">agent</a>.</p></dd><dt class="label"><a name="choreography" id="choreography"></a>choreography</dt><dd><ol type="1"><li><p>A choreography defines the sequence and conditions
|
|
under which multiple cooperating independent <a title="" href="#agent">agents</a> exchange messages in
|
|
order to perform a task to achieve a goal state.</p></li><li><p> Web Services Choreography concerns the
|
|
interactions of services with their users. Any user of a Web service,
|
|
automated or otherwise, is a client of that
|
|
service. These users may, in turn, be other Web
|
|
Services, applications or human beings. Transactions
|
|
among Web Services and their clients must clearly be
|
|
well defined at the time of their execution, and may
|
|
consist of multiple separate interactions whose
|
|
composition constitutes a complete transaction. This
|
|
composition, its message protocols, interfaces,
|
|
sequencing, and associated logic, is considered to be
|
|
a choreography. <a href="#WSCWGreqs">[WSC Reqs]</a></p></li></ol></dd><dt class="label"><a name="component" id="component"></a>component</dt><dd><ol type="1"><li><p>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. <a href="#CCATD">[CCA T&D]</a></p></li><li><p>A component is an abstract unit of software
|
|
instructions and internal state that provides a
|
|
transformation of data via its interface. <a href="#RoyFieldingThesis">[Fielding]</a></p></li><li><p>A component is a unit of architecture with defined
|
|
boundaries.</p></li></ol></dd><dt class="label"><a name="confidentiality" id="confidentiality"></a>confidentiality</dt><dd><p>Assuring information will be kept secret, with <a title="" href="#access">access</a>
|
|
limited to appropriate persons. <a href="#NSAG">[NSA Glossary]</a>
|
|
</p></dd><dt class="label"><a name="configuration" id="configuration"></a>configuration</dt><dd><p>A collection of properties which may be changed. A
|
|
property may influence the behavior of an entity.</p></dd><dt class="label"><a name="connection" id="connection"></a>connection</dt><dd><p>
|
|
A transport layer virtual circuit established between
|
|
two programs for the purpose of communication.
|
|
<a href="#RFC2616">[RFC 2616]</a>
|
|
</p></dd><dt class="label"><a name="control" id="control"></a>control</dt><dd><p>To cause a desired change in state. Management systems
|
|
may control the life cycle
|
|
of <a title="" href="#manageableservice">manageable Web services</a> or information flow such as messages.</p></dd><dt class="label"><a name="conversation" id="conversation"></a>conversation</dt><dd><p>A Web service conversation involves maintaining some state during an
|
|
interaction that involves multiple <a title="" href="#message">messages</a> and/or participants.</p></dd><dt class="label"><a name="credentials" id="credentials"></a>credentials</dt><dd><p>Data that is transferred to establish a claimed
|
|
principal
|
|
identity. <a href="#X800">[X.800]</a>
|
|
</p></dd><dt class="label"><a name="delpol" id="delpol"></a>delivery policy</dt><dd><p>A delivery policy is a <a title="" href="#policy">policy</a> that constrains the methods
|
|
by which <a title="" href="#message">messages</a> are
|
|
delivered by the message transport.</p></dd><dt class="label"><a name="dsig" id="dsig"></a>digital signature</dt><dd><p>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.)
|
|
<a href="#RFC2828">[RFC 2828]</a></p></dd><dt class="label"><a name="discovery" id="discovery"></a>discovery</dt><dd><p>The act of locating a machine-processable description
|
|
of a <a title="" href="#webservice">Web
|
|
service</a>-related resource that
|
|
may have been previously unknown and
|
|
that meets certain functional criteria. It involves
|
|
matching a set of functional and other criteria with a set
|
|
of resource descriptions. The goal is to find an
|
|
appropriate Web service-related resource.</p></dd><dt class="label"><a name="discoveryservice" id="discoveryservice"></a>discovery service</dt><dd><p>A discovery service is a <a title="" href="#service">service</a> that enables agents to retrieve
|
|
<a title="" href="#webservice">Web services</a>-related
|
|
resource description.</p></dd><dt class="label"><a name="document" id="document"></a>document</dt><dd><p>Any data that can be represented in a digital
|
|
form. <a href="#ueb">[UeB Glossary]</a></p></dd><dt class="label"><a name="edi" id="edi"></a>Electronic Data Interchange (EDI)</dt><dd><p>The automated exchange of any predefined and structured
|
|
data for business among information systems of two or more
|
|
organizations. <a href="#ISOIEC14662">[ISO/IEC 14662]</a></p></dd><dt class="label"><a name="domain" id="domain"></a>domain</dt><dd><p>
|
|
A domain is an identified set of <a title="" href="#agent">agents</a> and/or
|
|
resources that is subject to the constraints of one of
|
|
more <a title="" href="#policy">policies</a>.
|
|
</p></dd><dt class="label"><a name="encryption" id="encryption"></a>encryption</dt><dd><p>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. <a href="#RFC2828">[RFC 2828]</a></p></dd><dt class="label"><a name="endpoint" id="endpoint"></a>end point</dt><dd><p>An association
|
|
between a <a title="" href="#binding">binding</a> and
|
|
a network address,
|
|
specified by a URI,
|
|
that may be used to
|
|
communicate with an
|
|
instance of a
|
|
<a title="" href="#service">service</a>. An end point
|
|
indicates a specific
|
|
location for accessing
|
|
a service using a
|
|
specific <a title="" href="#protocol">protocol</a> and
|
|
data format. <a href="#WSDReqs">[WSD Reqs]</a>
|
|
</p></dd><dt class="label"><a name="gateway" id="gateway"></a>gateway</dt><dd><p>An agent that terminates a
|
|
<a title="" href="#message">message</a> on an inbound
|
|
<a title="" href="#interface">interface</a> with the
|
|
intent
|
|
of presenting it through an outbound interface as a new
|
|
message. Unlike a <a title="" href="#proxy">proxy</a>, 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.</p><p>Note: a gateway may or may
|
|
not be a <a title="" href="#soapnode">SOAP node</a>;
|
|
however a gateway is never a <a title="" href="#soapintermediary">SOAP intermediary</a>,
|
|
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.</p></dd><dt class="label"><a name="idempotent" id="idempotent"></a>idempotent</dt><dd><p>Property of an interaction whose results and
|
|
side-effects are the same whether it is done one or multiple
|
|
times. <a href="#RFC2616">[RFC 2616]</a></p><p><a title="" href="#safe">Safe</a> interactions are
|
|
inherently idempotent.</p></dd><dt class="label"><a name="identifier" id="identifier"></a>identifier</dt><dd><p>An identifier is an unambiguous name for a resource.</p></dd><dt class="label"><a name="isoapsender" id="isoapsender"></a>initial SOAP sender</dt><dd><p>The <a title="" href="#soapsender">SOAP
|
|
sender</a> that originates a <a title="" href="#soapmessage">SOAP message</a> at the starting
|
|
point of a <a title="" href="#soapmessagepath">SOAP message
|
|
path</a>.</p></dd><dt class="label"><a name="integrity" id="integrity"></a>integrity</dt><dd><p>Assuring information will not be accidentally or
|
|
maliciously altered or destroyed. <a href="#NSAG">[NSA Glossary]</a>
|
|
</p></dd><dt class="label"><a name="loosecoupling" id="loosecoupling"></a>loose coupling</dt><dd><p>Coupling is the dependency
|
|
between interacting systems. This dependency can be decomposed
|
|
into real
|
|
dependency and artificial dependency:</p><ol type="1"><li><p>Real dependency is the set of features or
|
|
services that a system consumes from other
|
|
systems. The real dependency always exists and cannot be reduced.</p></li><li><p>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.</p></li></ol><p>Loose coupling describes the configuration in which
|
|
artificial dependency has been reduced to the minimum.</p></dd><dt class="label"><a name="manageableservice" id="manageableservice"></a>manageable service</dt><dd><p>
|
|
A <a title="" href="#webservice">Web service</a>
|
|
becomes a manageable service with additional semantics,
|
|
policy statements, and monitoring and control (or
|
|
management) capabilities (exposed via a <a title="" href="#mgmti">management interface</a>) all for the purpose of managing the service.
|
|
</p></dd><dt class="label"><a name="mgmt" id="mgmt"></a>management</dt><dd><p>The utilization of the management capabilities by the
|
|
management system in order to perform monitoring of
|
|
values, tracking of states and control of entities in order to
|
|
produce and maintain a stable operational environment.</p></dd><dt class="label"><a name="managementcapability" id="managementcapability"></a>management
|
|
capability</dt><dd><p>Capabilities that a <a title="" href="#webservice">Web service</a> has for the purposes of controlling or monitoring the service, and that can be exposed to a management system for the sole purpose of managing the service.</p></dd><dt class="label"><a name="mgmti" id="mgmti"></a>management interface</dt><dd><p><a title="" href="#interface">Interface</a> through
|
|
which the <a title="" href="#managementcapability">management capabilities</a> of a service are exposed.</p></dd><dt class="label"><a name="managementpol" id="managementpol"></a>management policy</dt><dd><p><a title="" href="#policy">Policy</a> associated with
|
|
a Web service solely for the purpose of describing the management
|
|
<a title="" href="#obligation">obligations</a> and <a title="" href="#permission">permissions</a> for the service.</p></dd><dt class="label"><a name="mgmtsem" id="mgmtsem"></a>management semantics</dt><dd><p>The management semantics of a service augment the
|
|
<a title="" href="#ssem">semantics of a service</a> with
|
|
management-specific semantics. These management semantics form the
|
|
contract between the <a title="" href="#providerentity">provider
|
|
entity</a> and the <a title="" href="#requesterentity">requester entity</a> that expresses the effects and requirements pertaining to the management and management policies for a service.</p></dd><dt class="label"><a name="message" id="message"></a>message</dt><dd><ol type="1"><li><p>A message is the basic unit of data sent from one
|
|
<a title="" href="#webservice">Web services</a> <a title="" href="#agent">agent</a> to another in the context of Web services.</p></li><li><p>The basic unit of
|
|
communication between
|
|
a <a title="" href="#webservice">Web service</a> and
|
|
a
|
|
<a title="" href="#requesteragent">requester</a>: data to
|
|
be
|
|
communicated to or
|
|
from a Web service as
|
|
a single logical
|
|
transmission. <a href="#WSDReqs">[WSD Reqs]</a>
|
|
</p></li><li><p>See also <a title="" href="#soapmessage">SOAP
|
|
message</a>.</p></li></ol></dd><dt class="label"><a name="correlation" id="correlation"></a>message correlation</dt><dd><p>Message correlation is the association of a <a title="" href="#message">message</a> with a context. Message correlation
|
|
ensures that the <a title="" href="#requesteragent">requester agent</a> can match the reply with the request, especially when multiple replies may be possible.</p></dd><dt class="label"><a name="mep" id="mep"></a>message exchange pattern (MEP)</dt><dd><ol type="1"><li><p>A Message Exchanage Pattern (MEP) is a template,
|
|
devoid of application semantics, that describes a
|
|
generic pattern for the exchange of <a title="" href="#message">messages</a> between <a title="" href="#agent">agents</a>. It describes the
|
|
relationships (e.g., temporal, causal, sequential, etc.) of multiple
|
|
messages exchanged in conformance with the pattern, as
|
|
well as the normal and abnormal termination of any
|
|
message exchange conforming to the pattern.</p></li><li><p>See <a title="" href="#soapmep">SOAP message
|
|
exchange pattern (MEP)</a>.</p></li></ol></dd><dt class="label"><a name="mr" id="mr"></a>message receiver</dt><dd><p>A message receiver is an <a title="" href="#agent">agent</a> that receives a <a title="" href="#message">message</a>.</p></dd><dt class="label"><a name="mreliability" id="mreliability"></a>message reliability</dt><dd><p>Message reliability is the degree of certainty that a
|
|
<a title="" href="#message">message</a> will be delivered and that
|
|
<a title="" href="#msender">sender</a> and <a title="" href="#mr">receiver</a> will both have the same understanding of the delivery status.</p></dd><dt class="label"><a name="msender" id="msender"></a>message sender</dt><dd><p>A message sender is the <a title="" href="#agent">agent</a> that transmits a
|
|
<a title="" href="#message">message</a>.</p></dd><dt class="label"><a name="mtransport" id="mtransport"></a>message transport</dt><dd><p>A message transport is a mechanism that may be used by
|
|
<a title="" href="#agent">agents</a> to deliver <a title="" href="#message">messages</a>.</p></dd><dt class="label"><a name="nonrepudiation" id="nonrepudiation"></a>non-repudiation</dt><dd><p>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. <a href="#INFOSECG">[INFOSEC Glossary]</a>
|
|
</p></dd><dt class="label"><a name="obligation" id="obligation"></a>obligation</dt><dd><p>
|
|
An obligation is a kind of <a title="" href="#policy">policy</a> that prescribes actions and/or states of an agent and/or resource.
|
|
</p></dd><dt class="label"><a name="operation" id="operation"></a>operation</dt><dd><p>A set of <a title="" href="#message">messages</a>
|
|
related to a single
|
|
<a title="" href="#webservice">Web service</a>
|
|
action. <a href="#WSDReqs">[WSD Reqs]</a>
|
|
</p></dd><dt class="label"><a name="orchestration" id="orchestration"></a>orchestration</dt><dd><p>
|
|
An orchestration defines the sequence and conditions in
|
|
which one <a title="" href="#webservice">Web service</a> invokes other Web services in
|
|
order to realize some useful function. I.e., an
|
|
orchestration is the pattern of interactions that a Web
|
|
service agent must follow in order to achieve its goal.
|
|
</p></dd><dt class="label"><a name="permission" id="permission"></a>permission</dt><dd><p>
|
|
A permission is a kind of <a title="" href="#policy">policy</a> that prescribes the
|
|
allowed actions and states of an agent and/or resource.
|
|
</p></dd><dt class="label"><a name="permissionguard" id="permissionguard"></a>permission guard</dt><dd><p>
|
|
A permission guard is a mechanism deployed on behalf of
|
|
an owner to enforce <a title="" href="#permission">permission</a> policies.
|
|
</p></dd><dt class="label"><a name="poo" id="poo"></a>person or organization</dt><dd><p>A person or organization may be the owner of <a title="" href="#agent">agents</a> that provide or request <a title="" href="#webservice">Web services</a>.</p></dd><dt class="label"><a name="policy" id="policy"></a>policy</dt><dd><p>A policy is a constraint on the behavior of <a title="" href="#agent">agents</a> or <a title="" href="#poo">person
|
|
or organization</a>.</p></dd><dt class="label"><a name="policyguard" id="policyguard"></a>policy guard</dt><dd><p>
|
|
A policy guard is a mechanism that enforces one or more
|
|
<a title="" href="#policy">policies</a>. It is deployed
|
|
on behalf of an owner.
|
|
</p></dd><dt class="label"><a name="principal" id="principal"></a>principal</dt><dd><p>A <a title="" href="#systementity">system entity</a>
|
|
whose identity can be authenticated. <a href="#X811">[X.811]</a>
|
|
</p></dd><dt class="label"><a name="privacypolicy" id="privacypolicy"></a>privacy policy</dt><dd><p>A set of rules and practices that specify or regulate
|
|
how a <a title="" href="#poo">person or organization</a> collects, processes
|
|
(uses) and discloses another party's
|
|
personal data as a result of
|
|
an interaction.
|
|
</p></dd><dt class="label"><a name="provideragent" id="provideragent"></a>provider agent</dt><dd><p>
|
|
An <a title="" href="#agent">agent</a> that is capable
|
|
of and empowered to perform the actions associated with
|
|
a <a title="" href="#service">service</a> on behalf of
|
|
its owner — the <a title="" href="#providerentity">provider
|
|
entity</a>.
|
|
</p></dd><dt class="label"><a name="providerentity" id="providerentity"></a>provider entity</dt><dd><p>
|
|
The <a title="" href="#poo">person or organization</a>
|
|
that is providing a <a title="" href="#webservice">Web service</a>.
|
|
</p></dd><dt class="label"><a name="protocol" id="protocol"></a>protocol</dt><dd><p>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. <a href="#foldoc">[FOLDOC]</a></p></dd><dt class="label"><a name="proxy" id="proxy"></a>proxy</dt><dd><p>An <a title="" href="#agent">agent</a> that relays a
|
|
message between a <a title="" href="#requesteragent">requester agent</a> and
|
|
a <a title="" href="#provideragent">provider agent</a>,
|
|
appearing to the <a title="" href="#webservice">Web service</a> to be
|
|
the
|
|
requester.
|
|
</p></dd><dt class="label"><a name="qos" id="qos"></a>quality of service</dt><dd><p>
|
|
Quality of Service is an <a title="" href="#obligation">obligation</a> accepted and
|
|
advertised by a <a title="" href="#providerentity">provider entity</a> to service consumers.
|
|
</p></dd><dt class="label">reference architecture</dt><dd><p>A reference architecture is the generalized
|
|
<a title="" href="#architecture">architecture</a> 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. <a href="#RA">[Ref Arch]</a>
|
|
</p></dd><dt class="label"><a name="registry" id="registry"></a>registry</dt><dd><p>Authoritative, centrally controlled store of
|
|
information.</p></dd><dt class="label"><a name="requesteragent" id="requesteragent"></a>requester agent</dt><dd><p>
|
|
A software <a title="" href="#agent">agent</a> that
|
|
wishes to interact with a <a title="" href="#provideragent">provider agent</a> in order to
|
|
request that a task be performed on behalf of its owner
|
|
— the <a title="" href="#requesterentity">requester entity</a>.
|
|
</p></dd><dt class="label"><a name="requesterentity" id="requesterentity"></a>requester entity</dt><dd><p>
|
|
The <a title="" href="#poo">person or organization</a>
|
|
that wishes to use a <a title="" href="#providerentity">provider entity</a>'s
|
|
<a title="" href="#webservice">Web service</a>.
|
|
</p></dd><dt class="label"><a name="safe" id="safe"></a>safe</dt><dd><p>Property of an interaction which does not have any
|
|
significance of taking an action
|
|
other than retrieval of information. <a href="#RFC2616">[RFC 2616]</a></p></dd><dt class="label"><a name="securityadministration" id="securityadministration"></a>security
|
|
administration</dt><dd><p>Configuring, securing and/or deploying of systems or
|
|
applications enabling a <a title="" href="#securitydomain">security
|
|
domain</a>.</p></dd><dt class="label"><a name="securityarch" id="securityarch"></a>security architecture</dt><dd><p>A plan and set of principles for an administrative
|
|
domain and
|
|
its <a title="" href="#securitydomain">security
|
|
domains</a> that
|
|
describe the <a title="" href="#securityservice">security
|
|
services</a> 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. <a href="#RFC2828">[RFC 2828]</a>
|
|
</p></dd><dt class="label"><a name="auditing" id="auditing"></a>security auditing</dt><dd><p>
|
|
A <a title="" href="#service">service</a> 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.
|
|
</p></dd><dt class="label"><a name="securitydomain" id="securitydomain"></a>security domain</dt><dd><p>An environment or
|
|
context that is defined by <a title="" href="#securitymodel">security models</a>
|
|
and a <a title="" href="#securityarch">security
|
|
architecture</a>, including a set of resources and
|
|
set of system entities that are <a title="" href="#authorization">authorized</a> to <a title="" href="#access">access</a> 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. <a href="#RFC2828">[RFC 2828]</a>
|
|
</p></dd><dt class="label"><a name="securitymechanism" id="securitymechanism"></a>security mechanism</dt><dd><p>
|
|
A process (or a device incorporating such a process)
|
|
that can be used in a system to implement a <a title="" href="#securityservice">security service</a> that is
|
|
provided by or within the system.
|
|
</p></dd><dt class="label"><a name="securitymodel" id="securitymodel"></a>security model</dt><dd><p>
|
|
A schematic description of a set of entities and
|
|
relationships by which a specified set of <a title="" href="#securityservice">security services</a> are
|
|
provided by or within a system. <a href="#RFC2828">[RFC 2828]</a>
|
|
</p></dd><dt class="label"><a name="securitypolicy" id="securitypolicy"></a>security policy</dt><dd><p>A set of rules and practices that specify or regulate
|
|
how a
|
|
system or organization provides <a title="" href="#securityservice">security services</a> to protect
|
|
resources. Security policies are components of <a title="" href="#securityarch">security
|
|
architectures</a>. Significant portions of security
|
|
policies are
|
|
implemented via security services, using <a title="" href="#securitypolicyexpr">security policy
|
|
expressions</a>. <a href="#RFC2828">[RFC 2828]</a>
|
|
</p></dd><dt class="label"><a name="securitypolicyexpr" id="securitypolicyexpr"></a>security policy
|
|
expression</dt><dd><p>A mapping of
|
|
<a title="" href="#principal">principal</a> identities
|
|
and/or attributes thereof with
|
|
allowable actions. Security policy expressions are often
|
|
essentially access control lists. <a href="#STG">[STG]</a>
|
|
</p></dd><dt class="label"><a name="securityservice" id="securityservice"></a>security service</dt><dd><p>A processing or
|
|
communication <a title="" href="#service">service</a>
|
|
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 <a title="" href="#securitypolicy">security policies</a> and
|
|
are implemented via <a title="" href="#securitymechanism">security mechanisms</a>. <a href="#RFC2828">[RFC 2828]</a>
|
|
</p></dd><dt class="label"><a name="service" id="service"></a>service</dt><dd><ol type="1"><li><p>A service is an abstract resource that represents a
|
|
capability of
|
|
performing tasks that form a coherent functionality
|
|
from the point of view of <a title="" href="#providerentity">providers entities</a> and
|
|
<a title="" href="#requesterentity">requesters
|
|
entities</a>. To be used, a service must be realized by a
|
|
concrete <a title="" href="#provideragent">provider agent</a>.</p></li><li><p>WSDL service: A collection of <a title="" href="#endpoint">end points</a>. <a href="#WSDReqs">[WSD Reqs]</a>
|
|
</p></li><li><p>See <a title="" href="#webservice">Web
|
|
service</a>.</p></li></ol></dd><dt class="label"><a name="sdesc" id="sdesc"></a>service description</dt><dd><p>A service description is a set of documents that
|
|
describe the <a title="" href="#interface">interface</a> to and
|
|
<a title="" href="#ssem">semantics</a> of a <a title="" href="#service">service</a>.</p></dd><dt class="label"><a name="interface" id="interface"></a>service interface</dt><dd><ol type="1"><li><p>A service interface is the abstract boundary that a
|
|
<a title="" href="#service">service</a> exposes. It
|
|
defines the types of <a title="" href="#message">messages</a> and the <a title="" href="#mep">message
|
|
exchange patterns</a> that are involved in interacting with the service, together with any conditions implied by those messages.</p></li><li><p>A logical grouping of <a title="" href="#operation">operations</a>. An interface
|
|
represents an abstract service type, independent of
|
|
transmission <a title="" href="#protocol">protocol</a> and data format.
|
|
<a href="#WSDReqs">[WSD Reqs]</a></p></li></ol></dd><dt class="label"><a name="intermediary" id="intermediary"></a>service intermediary</dt><dd><ol type="1"><li><p>A service intermediary is a <a title="" href="#webservice">Web service</a> whose main
|
|
role is to transform <a title="" href="#message">messages</a> in a value-added
|
|
way. (From a messaging point of view, an intermediary
|
|
processes messages en route from one agent to
|
|
another.) Specifically, we say that a service
|
|
intermediary is a service whose outgoing messages are
|
|
equivalent to its incoming messages in some
|
|
application-defined sense.</p></li><li><p>See <a title="" href="#soapintermediary">SOAP
|
|
intermediary</a>.</p></li></ol></dd><dt class="label"><a name="provider" id="provider"></a>service provider</dt><dd><p>See <a title="" href="#provideragent">provider
|
|
agent</a> and <a title="" href="#providerentity">provider entity</a>. See also
|
|
the <a href="http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#wordonspr">discussion about
|
|
service provider</a> in <a href="#WSA">[WS Arch]</a>.</p></dd><dt class="label"><a name="requester" id="requester"></a>service requester</dt><dd><p>See <a title="" href="#requesteragent">requester
|
|
agent</a> and <a title="" href="#requesterentity">requester entity</a>. See also
|
|
the <a href="http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#wordonspr">discussion about
|
|
service requester</a> in <a href="#WSA">[WS Arch]</a>.</p></dd><dt class="label"><a name="servicerole" id="servicerole"></a>service role</dt><dd><p>An abstract set of tasks which is identified to be
|
|
relevant by a <a title="" href="#poo">person or organization</a>
|
|
offering a <a title="" href="#service">service</a>. Service roles
|
|
are also associated with particular aspects of <a title="" href="#message">messages</a> exchanged with a service.</p></dd><dt class="label"><a name="ssem" id="ssem"></a>service semantics</dt><dd><p>The semantics of a <a title="" href="#service">service</a> is the behavior expected
|
|
when interacting with the service. The semantics expresses
|
|
a contract (not necessarily a legal contract) between the
|
|
<a title="" href="#providerentity">provider entity</a> and the
|
|
<a title="" href="#requesterentity">requester
|
|
entity</a>. It expresses
|
|
the effect of invoking the service. A service semantics
|
|
may be formally described in a machine readable form,
|
|
identified but not formally defined, or informally defined
|
|
via an out of band agreement between the provider and
|
|
the requester entity.</p></dd><dt class="label">service-oriented architecture</dt><dd><p>A set of <a title="" href="#component">components</a>
|
|
which can be invoked, and whose <a title="" href="#interface">interface</a> descriptions can be published and
|
|
<a title="" href="#discovery">discovered</a>.</p></dd><dt class="label"><a name="session" id="session"></a>session</dt><dd><p>A lasting interaction between <a title="" href="#systementity">system entities</a>, often
|
|
involving a user, typified by the maintenance of some
|
|
<a title="" href="#state">state</a> of the interaction
|
|
for the duration of the interaction. <a href="#WSIAG">[WSIA Glossary]</a>
|
|
</p><p>Such an interaction may not be limited to a single
|
|
<a title="" href="#connection">connection</a> between
|
|
the system entities.</p></dd><dt class="label">SOAP</dt><dd><p>The formal set of
|
|
conventions governing the format and processing rules of
|
|
a <a title="" href="#soapmessage">SOAP message</a>. These
|
|
conventions include the interactions among
|
|
<a title="" href="#soapnode">SOAP nodes</a>
|
|
generating and accepting SOAP messages for
|
|
the purpose of exchanging information along a <a title="" href="#soapmessagepath">SOAP
|
|
message path</a>.</p></dd><dt class="label"><a name="soapapp" id="soapapp"></a>SOAP application</dt><dd><p>A software entity that produces, consumes or
|
|
otherwise acts upon <a title="" href="#soapmessage">SOAP
|
|
messages</a> in a manner
|
|
conforming to the SOAP processing model.</p></dd><dt class="label"><a name="soapbinding" id="soapbinding"></a>SOAP binding</dt><dd><p>The formal set of
|
|
rules for carrying a <a title="" href="#soapmessage">SOAP
|
|
message</a> 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.</p></dd><dt class="label"><a name="soapbody" id="soapbody"></a>SOAP body</dt><dd><p>A collection of zero or
|
|
more <em>element information items</em> targeted at an
|
|
<a title="" href="#usoapreceiver">ultimate SOAP
|
|
receiver</a> in the <a title="" href="#soapmessagepath">SOAP message
|
|
path</a>.</p></dd><dt class="label"><a name="soapenvelope" id="soapenvelope"></a>SOAP envelope</dt><dd><p>The outermost
|
|
<em>element information item</em> of a <a title="" href="#soapmessage">SOAP message</a>.</p></dd><dt class="label"><a name="soapfault" id="soapfault"></a>SOAP fault</dt><dd><p>A SOAP
|
|
<em>element information item</em>
|
|
which contains fault information generated by a <a title="" href="#soapnode">SOAP
|
|
node</a>.</p></dd><dt class="label"><a name="soapfeature" id="soapfeature"></a>SOAP feature</dt><dd><p>An extension of the SOAP messaging framework typically
|
|
associated with the exchange of messages between
|
|
communicating <a title="" href="#soapnode">SOAP
|
|
nodes</a>. Examples of features
|
|
include "reliability", "security", "correlation",
|
|
"routing", and the concept of message exchange
|
|
patterns.</p></dd><dt class="label"><a name="soapheader" id="soapheader"></a>SOAP header</dt><dd><p>A collection of zero
|
|
or more <a title="" href="#soapheaderblock">SOAP header
|
|
blocks</a> each of which might be targeted
|
|
at any SOAP
|
|
receiver within the <a title="" href="#soapmessagepath">SOAP
|
|
message path</a>.</p></dd><dt class="label"><a name="soapheaderblock" id="soapheaderblock"></a>SOAP header block</dt><dd><p>An
|
|
<em>element information item</em> used to delimit
|
|
data that logically constitutes a single computational
|
|
unit within the <a title="" href="#soapheader">SOAP
|
|
header</a>. The type of a SOAP header block is
|
|
identified by the fully qualified name of the header block
|
|
<em>element information item</em>.</p></dd><dt class="label"><a name="soapintermediary" id="soapintermediary"></a>SOAP intermediary</dt><dd><p>A SOAP intermediary
|
|
is both a <a title="" href="#soapreceiver">SOAP
|
|
receiver</a> and a <a title="" href="#soapsender">SOAP
|
|
sender</a> and is targetable
|
|
from within a <a title="" href="#soapmessage">SOAP
|
|
message</a>. It processes the <a title="" href="#soapheaderblock">SOAP header
|
|
blocks</a> targeted at it and acts to forward a SOAP
|
|
message
|
|
towards an <a title="" href="#usoapreceiver">ultimate SOAP
|
|
receiver</a>.</p></dd><dt class="label"><a name="soapmessage" id="soapmessage"></a>SOAP message</dt><dd><p>
|
|
The basic unit of communication between <a title="" href="#soapnode">SOAP
|
|
nodes</a>.</p></dd><dt class="label"><a name="soapmep" id="soapmep"></a>SOAP message exchange pattern
|
|
(MEP)</dt><dd><p>A template for the exchange of <a title="" href="#soapmessage">SOAP messages</a>
|
|
between <a title="" href="#soapnode">SOAP nodes</a>
|
|
enabled by one or more underlying
|
|
<a title="" href="#soapbinding">SOAP protocol
|
|
bindings</a>. A SOAP
|
|
MEP is an example of a <a title="" href="#soapfeature">SOAP
|
|
feature</a>.</p></dd><dt class="label"><a name="soapmessagepath" id="soapmessagepath"></a>SOAP message path</dt><dd><p>The set of <a title="" href="#soapnode">SOAP
|
|
nodes</a> through which a single <a title="" href="#soapmessage">SOAP
|
|
message</a> passes. This includes the initial
|
|
<a title="" href="#soapsender">SOAP sender</a>,
|
|
zero or more <a title="" href="#soapintermediary">SOAP
|
|
intermediaries</a>, and an <a title="" href="#usoapreceiver">ultimate
|
|
SOAP
|
|
receiver</a>.</p></dd><dt class="label"><a name="soapnode" id="soapnode"></a>SOAP node</dt><dd><p>The embodiment of
|
|
the processing logic necessary to transmit, receive,
|
|
process and/or relay a <a title="" href="#soapmessage">SOAP
|
|
message</a>, 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 <a title="" href="#soapbinding">SOAP
|
|
bindings</a>.</p></dd><dt class="label"><a name="soapreceiver" id="soapreceiver"></a>SOAP receiver</dt><dd><p>A
|
|
<a title="" href="#soapnode">SOAP node</a> that accepts a
|
|
<a title="" href="#soapmessage">SOAP message</a>.</p></dd><dt class="label"><a name="soaprole" id="soaprole"></a>SOAP role</dt><dd><p>A <a title="" href="#soapnode">SOAP node</a>'s
|
|
expected function in
|
|
processing a message. A SOAP node can act in multiple
|
|
roles.</p></dd><dt class="label"><a name="soapsender" id="soapsender"></a>SOAP sender</dt><dd><p>A
|
|
<a title="" href="#soapnode">SOAP node</a> that transmits
|
|
a <a title="" href="#soapmessage">SOAP message</a>.</p></dd><dt class="label"><a name="state" id="state"></a>state</dt><dd><p>A set of <a title="" href="#attribute">attributes</a>
|
|
representing the properties of a <a title="" href="#component">component</a> at some point in
|
|
time.</p></dd><dt class="label"><a name="synchronous" id="synchronous"></a>synchronous</dt><dd><p>An interaction is said to be synchronous when the
|
|
participating agents must
|
|
be available to receive and process the associated
|
|
messages from the time
|
|
the interaction is initiated until all messages are
|
|
actually received or
|
|
some failure condition is determined. The exact meaning
|
|
of "available to receive the message" depends on the
|
|
characteristics of the
|
|
participating agents (including the transfer protocol it
|
|
uses); it may, but
|
|
does not necessarily, imply tight time synchronization,
|
|
blocking a thread,
|
|
etc.</p></dd><dt class="label"><a name="systementity" id="systementity"></a>system entity</dt><dd><p>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. <a href="#RFC2828">[RFC 2828]</a>
|
|
</p></dd><dt class="label"><a name="transaction" id="transaction"></a>transaction</dt><dd><p>Transaction is a feature of the
|
|
architecture that
|
|
supports the coordination of results or operations on
|
|
state in a multi-step
|
|
interaction. The fundamental characteristic of a transaction is the
|
|
ability to join
|
|
multiple actions into the same unit of work, such that the
|
|
actions either
|
|
succeed or fail as a unit.</p></dd><dt class="label"><a name="usoapreceiver" id="usoapreceiver"></a>ultimate SOAP receiver</dt><dd><p> The <a title="" href="#soapreceiver">SOAP
|
|
receiver</a> that is a final destination of a
|
|
<a title="" href="#soapmessage">SOAP message</a>. It is responsible
|
|
for
|
|
processing the contents of the <a title="" href="#soapbody">SOAP body</a> and any <a title="" href="#soapheaderblock">SOAP
|
|
header blocks</a> targeted at it. In some
|
|
circumstances, a
|
|
SOAP message might not reach an ultimate SOAP receiver,
|
|
for
|
|
example because of a problem at a
|
|
<a title="" href="#soapintermediary">SOAP
|
|
intermediary</a>. An
|
|
ultimate SOAP receiver cannot also be a SOAP
|
|
intermediary for the same SOAP message.</p></dd><dt class="label"><a name="usageauditing" id="usageauditing"></a>usage auditing</dt><dd><p><a title="" href="#service">Service</a> 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.</p></dd><dt class="label"><a name="webservice" id="webservice"></a>Web service</dt><dd><p>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:</p><p>
|
|
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.
|
|
</p></dd></dl></div><div class="div1">
|
|
<h2><a name="ref" id="ref"></a>3 References</h2><dl><dt class="label"><a name="CCATD" id="CCATD"></a>CCA T&D</dt><dd><a href="http://www.cca-forum.org/glossary.shtml">
|
|
<cite>CCA Terms and Definitions</cite>,
|
|
CCA Forum, Kate Keahey</a> (See http://www.cca-forum.org/glossary.shtml.)</dd><dt class="label"><a name="RoyFieldingThesis" id="RoyFieldingThesis"></a>Fielding</dt><dd><a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">
|
|
<cite>Architectural Styles and
|
|
the Design of Network-based Software Architectures</cite>, PhD dissertation, R. Fielding, 2000</a> (See http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.)</dd><dt class="label"><a name="foldoc" id="foldoc"></a>FOLDOC</dt><dd><a href="http://www.foldoc.org/"><cite>The Free On-line Dictionary of Computing</cite>, D. Howe</a> (See http://www.foldoc.org/.)</dd><dt class="label"><a name="INFOSECG" id="INFOSECG"></a>INFOSEC Glossary</dt><dd>
|
|
<cite>National Information Systems Security
|
|
(INFOSEC) Glossary</cite>,
|
|
National Security Telecommunications and Information Systems Security
|
|
Instruction (NSTISSI) No. 4009, 5 June 1992</dd><dt class="label"><a name="ISOIEC14662" id="ISOIEC14662"></a>ISO/IEC 14662</dt><dd><a href="http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=25154">
|
|
<cite>Information technology -- Open-edi reference model</cite>,
|
|
International Standard, ISO/IEC 14662:1997</a> (See http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=25154.)</dd><dt class="label"><a name="NSAG" id="NSAG"></a>NSA Glossary</dt><dd>
|
|
|
|
<cite>NSA Glossary of
|
|
Terms Used in Security and
|
|
Intrusion Detection</cite>,
|
|
NSA, April 1998
|
|
</dd><dt class="label"><a name="SAP" id="SAP"></a>Soft Arch Pract</dt><dd>
|
|
<cite>Software Architecture in Practice</cite>,
|
|
ISBN 0201199300, L. Bass, P, Clements, R. Kazman, 1997</dd><dt class="label"><a name="RA" id="RA"></a>Ref Arch</dt><dd><a href="http://www.sei.cmu.edu/publications/documents/00.reports/00tn007/00tn007.html">
|
|
<cite>Using the Architecture Tradeoff Analysis
|
|
Method(SM) to Evaluate a Reference Architecture: A Case
|
|
Study</cite>,
|
|
B. Gallagher, June 2000</a> (See http://www.sei.cmu.edu/publications/documents/00.reports/00tn007/00tn007.html.)</dd><dt class="label"><a name="RFC2616" id="RFC2616"></a>RFC 2616</dt><dd><a href="http://www.ietf.org/rfc/rfc2616.txt">
|
|
<cite>Hypertext Transfer Protocol --
|
|
HTTP/1.1</cite>,
|
|
IETF RFC 2616, R. Fielding, J. Gettys, J. Mogul,
|
|
H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee
|
|
June 1999</a> (See http://www.ietf.org/rfc/rfc2616.txt.)</dd><dt class="label"><a name="RFC2828" id="RFC2828"></a>RFC 2828</dt><dd><a href="http://www.ietf.org/rfc/rfc2828.txt">
|
|
<cite>Internet Security Glossary</cite>,
|
|
IETF RFC 2828, R. Shirey, May
|
|
2000</a> (See http://www.ietf.org/rfc/rfc2828.txt.)</dd><dt class="label"><a name="RFC2829" id="RFC2829"></a>RFC 2829</dt><dd><a href="http://www.ietf.org/rfc/rfc2829.txt">
|
|
<cite>Authentication Methods for LDAP</cite>,
|
|
IETF RFC 2829, M. Wahl, H. Alvestrand, J. Hodges,
|
|
R. Morgan , May
|
|
2000</a> (See http://www.ietf.org/rfc/rfc2829.txt.)</dd><dt class="label"><a name="STG" id="STG"></a>STG</dt><dd><a href="http://www.garlic.com/~lynn/secure.htm">
|
|
<cite>Security Taxonomy and Glossary</cite>,
|
|
L. Wheeler</a> (See http://www.garlic.com/~lynn/secure.htm.)</dd><dt class="label"><a name="SOAP1" id="SOAP1"></a>SOAP12 Part1</dt><dd><a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/">
|
|
<cite>SOAP Version 1.2 Part 1:
|
|
Messaging Framework</cite>, W3C Recommendation,
|
|
M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau,
|
|
H. Nielsen, 24 June 2003</a> (See http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.)</dd><dt class="label"><a name="ueb" id="ueb"></a>UeB Glossary</dt><dd><cite>UN/CEFACT eBusiness Glossary</cite>, UN/CEFACT Working Draft Revision 0.53, 13 December 2002</dd><dt class="label"><a name="webarch" id="webarch"></a>Web Arch</dt><dd><a href="http://www.w3.org/TR/2003/WD-webarch-20031209/">
|
|
<cite>Architecture of the World Wide Web, First Edition</cite>,
|
|
W3C Working Draft, I. Jacobs, 9 December 2003
|
|
</a> (See http://www.w3.org/TR/2003/WD-webarch-20031209/.)</dd><dt class="label"><a name="WSA" id="WSA"></a>WS Arch</dt><dd><a href="http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/">
|
|
<cite>Web Services
|
|
Architecture</cite>, W3C Working Group Note,
|
|
D. Booth, H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, D. Orchard,
|
|
11 February 2004</a> (See http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/.)</dd><dt class="label"><a name="WSIAG" id="WSIAG"></a>WSIA Glossary</dt><dd><a href="http://www.oasis-open.org/committees/wsia/glossary/wsia-draft-glossary-03.htm">
|
|
<cite>Glossary for the OASIS WebService
|
|
Interactive Applications (WSIA/WSRP)</cite>,
|
|
OASIS draft, 3 May 2002</a> (See http://www.oasis-open.org/committees/wsia/glossary/wsia-draft-glossary-03.htm.)</dd><dt class="label"><a name="WSCWGreqs" id="WSCWGreqs"></a>WSC Reqs</dt><dd><a href="http://www.w3.org/TR/2003/WD-ws-chor-reqs-20030812/">
|
|
<cite>Web Services Choreography Requirements 1.0</cite>, W3C Working Draft,
|
|
D. Austin,
|
|
A. Barbir,
|
|
E. Peters,
|
|
S. Ross-Talbot, 12 August 2003</a> (See http://www.w3.org/TR/2003/WD-ws-chor-reqs-20030812/.)</dd><dt class="label"><a name="WSDReqs" id="WSDReqs"></a>WSD Reqs</dt><dd><a href="http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028/">
|
|
<cite>Web Service Description
|
|
Requirements</cite>, W3C Working Draft,
|
|
J. Schlimmer, 28 October 2002</a> (See http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028/.)</dd><dt class="label"><a name="X800" id="X800"></a>X.800</dt><dd><a href="http://www.itu.int/itudoc/itu-t/rec/x/x500up/x800.html">
|
|
<cite>Information processing systems Open Systems Interconnection Basic Reference Model Part 2: Security Architecture</cite>,
|
|
ISO 7498-2:1989, ITU-T Recommendation X.800 (1991)</a> (See http://www.itu.int/itudoc/itu-t/rec/x/x500up/x800.html.)</dd><dt class="label"><a name="X811" id="X811"></a>X.811</dt><dd><a href="http://www.itu.int/itudoc/itu-t/rec/x/x500up/x811.html">
|
|
<cite>Security Frameworks for Open Systems:
|
|
Authentication Framework</cite>,
|
|
ITU-T Recommendation X.811 (1995 E), ISO/IEC 10181-2:1996(E)</a> (See http://www.itu.int/itudoc/itu-t/rec/x/x500up/x811.html.)</dd><dt class="label"><a name="X812" id="X812"></a>X.812</dt><dd><a href="http://www.itu.int/itudoc/itu-t/rec/x/x500up/x812.html">
|
|
<cite>Security frameworks for open systems: Access control framework</cite>,
|
|
ITU-T Recommendation X.812 (1995 E), ISO/IEC 10181-3:1996(E)</a> (See http://www.itu.int/itudoc/itu-t/rec/x/x500up/x812.html.)</dd></dl></div></div><div class="back"><div class="div1">
|
|
<h2><a name="id2273823" id="id2273823"></a>A Acknowledgements (Non-Normative)</h2><p>This document has been produced by the <a href="http://www.w3.org/2002/ws/arch/">Web Services
|
|
Architecture Working Group</a>.</p><p>
|
|
Members of the Working Group are
|
|
(at the time of writing, and by alphabetical order):
|
|
Geoff
|
|
Arnold
|
|
(Sun Microsystems, Inc.), Mukund
|
|
Balasubramanian
|
|
(Infravio, Inc.), Mike
|
|
Ballantyne
|
|
(EDS), Abbie
|
|
Barbir
|
|
(Nortel Networks), David Booth
|
|
(W3C), Mike
|
|
Brumbelow
|
|
(Apple), Doug
|
|
Bunting
|
|
(Sun Microsystems, Inc.), Greg
|
|
Carpenter
|
|
(Nokia), Tom
|
|
Carroll
|
|
(W. W. Grainger, Inc.), Alex Cheng
|
|
(Ipedo), Michael
|
|
Champion
|
|
(Software AG), Martin
|
|
Chapman
|
|
(Oracle Corporation), Ugo
|
|
Corda
|
|
(SeeBeyond Technology Corporation), Roger
|
|
Cutler
|
|
(ChevronTexaco), Jonathan
|
|
Dale
|
|
(Fujitsu), Suresh
|
|
Damodaran
|
|
(Sterling Commerce(SBC)), James
|
|
Davenport
|
|
(MITRE Corporation), Paul Denning
|
|
(MITRE Corporation), Gerald
|
|
Edgar
|
|
(The Boeing Company), Shishir Garg
|
|
(France Telecom), Hugo Haas
|
|
(W3C), Hao He
|
|
(The Thomson Corporation), Dave
|
|
Hollander
|
|
(Contivo), Yin-Leng
|
|
Husband
|
|
(Hewlett-Packard Company), Mario Jeckle
|
|
(DaimlerChrysler Research and Technology), Heather
|
|
Kreger
|
|
(IBM), Sandeep
|
|
Kumar
|
|
(Cisco Systems Inc), Hal Lockhart
|
|
(OASIS), Michael
|
|
Mahan
|
|
(Nokia), Francis
|
|
McCabe
|
|
(Fujitsu), Michael
|
|
Mealling
|
|
(VeriSign, Inc.), Jeff
|
|
Mischkinsky
|
|
(Oracle Corporation), Eric Newcomer
|
|
(IONA), Mark
|
|
Nottingham
|
|
(BEA Systems), David
|
|
Orchard
|
|
(BEA Systems), Bijan Parsia
|
|
(MIND Lab), Adinarayana
|
|
Sakala
|
|
(IONA), Waqar
|
|
Sadiq
|
|
(EDS), Igor
|
|
Sedukhin
|
|
(Computer Associates), Hans-Peter
|
|
Steiert
|
|
(DaimlerChrysler Research and Technology), Katia Sycara
|
|
(Carnegie Mellon University), Bryan
|
|
Thompson
|
|
(Hicks & Associates, Inc.), Sinisa
|
|
Zimek
|
|
(SAP).</p><p>Previous members of the Working Group were: Assaf
|
|
Arkin (Intalio, Inc.), Daniel Austin (W. W. Grainger, Inc.), Mark Baker (Idokorro Mobile, Inc. / Planetfred, Inc.),
|
|
Tom Bradford (XQRL, Inc.), Allen Brown (Microsoft Corporation), Dipto
|
|
Chakravarty (Artesia Technologies), Jun Chen (MartSoft Corp.), Alan Davies
|
|
(SeeBeyond Technology Corporation), Glen Daniels (Macromedia), Ayse Dilber
|
|
(AT&T), Zulah Eckert (Hewlett-Packard Company), Colleen Evans (Sonic Software), Chris Ferris (IBM), Daniela
|
|
Florescu (XQRL Inc.), Sharad Garg (Intel), Mark Hapner (Sun Microsystems,
|
|
Inc.), Joseph Hui (Exodus/Digital Island), Michael Hui (Computer Associates),
|
|
Nigel Hutchison (Software AG), Marcel Jemio (DISA), Mark Jones (AT&T),
|
|
Timothy Jones (CrossWeave, Inc.), Tom Jordahl (Macromedia), Jim Knutson
|
|
(IBM), Steve Lind (AT&T), Mark Little (Arjuna), Bob Lojek (Intalio, Inc.), Anne Thomas Manes
|
|
(Systinet), Jens Meinkoehn (T-Nova Deutsche Telekom Innovationsgesellschaft),
|
|
Nilo Mitra (Ericsson), Don Mullen (TIBCO Software, Inc.), Himagiri Mukkamala (Sybase, Inc.), Joel Munter (Intel), Henrik Frystyk Nielsen (Microsoft
|
|
Corporation), Duane Nickull (XML Global Technologies), David Noor (Rogue Wave
|
|
Software), Srinivas Pandrangi (Ipedo), Kevin Perkins (Compaq), Mark
|
|
Potts
|
|
(Talking Blocks, Inc), Fabio Riccardi (XQRL, Inc.), Don Robertson
|
|
(Documentum), Darran Rolls (Waveset Technologies, Inc.), Krishna Sankar
|
|
(Cisco Systems Inc), Jim Shur (Rogue Wave Software), Patrick Thompson (Rogue
|
|
Wave Software), Steve Vinoski (IONA), Scott Vorthmann (TIBCO Software, Inc.),
|
|
Jim Webber (Arjuna), Prasad Yendluri (webMethods, Inc.),
|
|
Jin Yu (MartSoft Corp.) .</p><p>The people who have contributed to discussions on the <a href="http://lists.w3.org/Archives/Public/www-ws-arch/">www-ws-arch
|
|
public mailing list</a> are also gratefully acknowledged.</p></div></div></body></html>
|