index.html
63.8 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
<?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>