- From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 19 Mar 2007 17:41:53 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv20995
Modified Files:
ws-policy-primer.xml
Log Message:
Implemented the resolution for issue 4103. Editors' action 193.
Index: ws-policy-primer.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.xml,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -d -r1.41 -r1.42
--- ws-policy-primer.xml 19 Mar 2007 13:47:57 -0000 1.41
+++ ws-policy-primer.xml 19 Mar 2007 17:41:51 -0000 1.42
@@ -167,8 +167,8 @@
<head>SOAP Message</head>
<eg xml:space="preserve"><soap:Envelope>
<soap:Header>
- <wsa:To>http://stock.contoso.com/realquote</wsa:To>
- <wsa:Action>http://stock.contoso.com/GetRealQuote</wsa:Action>
+ <wsa:To>http://x.example.com/realquote</wsa:To>
+ <wsa:Action>http://x.example.com/GetRealQuote</wsa:Action>
</soap:Header>
<soap:Body>...</soap:Body>
</soap:Envelope></eg>
@@ -180,9 +180,9 @@
namespaces and prefixes that are used in this document.)</p>
<p>Let us look at a fictitious scenario used in this document to illustrate the features of
the policy language. A Web service developer is building a client application
- that retrieves real time stock quote information from Contoso, Ltd. Contoso supplies real
- time data using Web services. The developer has Contoso’s advertised WSDL description of these Web
- services. Contoso requires the use of addressing headers for messaging. Just the WSDL
+ that retrieves real time stock quote information from Company-X, Ltd. Company-X supplies real
+ time data using Web services. The developer has Company-X’s advertised WSDL description of these Web
+ services. Company-X requires the use of addressing headers for messaging. Just the WSDL
description is not sufficient for the developer to enable the interaction between her client and
these Web services. WSDL constructs do not indicate requirements such as the use of
addressing.</p>
@@ -192,16 +192,16 @@
places, or events is intended or should be inferred.</emph>)</p>
<p>Providers have the option to convey requirements, such as the use of addressing, through
word-of-mouth and documentation – as they always have. To interact successfully with this
- service, the developer may have to read any related documentation, call someone at Contoso to
+ service, the developer may have to read any related documentation, call someone at Company-X to
understand the service metadata, or look at sample SOAP messages and infer such
requirements or behaviors.</p>
<p>Web Services Policy is a machine-readable language for representing these Web service
capabilities and requirements as policies. Policy makes it possible for providers to
represent such capabilities and requirements in a machine-readable form. For example,
- Contoso may augment the service WSDL description with a policy that requires the use of
+ Company-X may augment the service WSDL description with a policy that requires the use of
addressing. The client application developer can use a policy-aware client that understands this policy and engages
addressing automatically.</p>
- <p>How does Contoso use policy to represent the use of addressing? The example below
+ <p>How does Company-X use policy to represent the use of addressing? The example below
illustrates a policy expression that requires the use of addressing.</p>
<example>
<head>Policy Expression</head>
@@ -212,7 +212,7 @@
<p>
The policy expression in the above example consists of a Policy main
element and a child element wsap:UsingAddressing. Child elements of
- the Policy element are policy assertions. Contoso attaches the above
+ the Policy element are policy assertions. Company-X attaches the above
policy expression to a WSDL binding description.
</p>
<example>
@@ -243,7 +243,7 @@
</div2>
<div2 id="secure-message">
<head>Secure Message</head>
- <p>In addition to requiring the use of addressing, Contoso requires the use of
+ <p>In addition to requiring the use of addressing, Company-X requires the use of
transport-level security for protecting messages.</p>
<example>
<head>Secure Message</head>
@@ -255,18 +255,18 @@
<wsu:Expires>2006-01-19T02:54:53.914Z</u:Expires>
</wsu:Timestamp>
</wss:Security>
- <wsa:To>http://real.contoso.com/quote</wsa:To>
- <wsa:Action>http://real.contoso.com/GetRealQuote</wsa:Action>
+ <wsa:To>http://x.example.com/quote</wsa:To>
+ <wsa:Action>http://x.example.com/GetRealQuote</wsa:Action>
</soap:Header>
<soap:Body>...</soap:Body>
</soap:Envelope></eg>
</example>
<p>The SOAP message in the example above includes security timestamps that express creation
- and expiration times of this message. Contoso requires the use of security timestamps and
+ and expiration times of this message. Company-X requires the use of security timestamps and
transport-level security - such as <code>HTTPS</code> – for protecting messages. (The
prefixes <code>wss</code> and <code>wsu</code> are used here to denote the Web Services
Security and Utility namespaces.)</p>
- <p>Similar to the use of addressing, Contoso indicates the use of transport-level security
+ <p>Similar to the use of addressing, Company-X indicates the use of transport-level security
using a policy expression. The example below illustrates a policy expression that requires
the use of addressing and transport-level security for securing messages.</p>
<example>
@@ -289,14 +289,14 @@
</div2>
<div2 id="other-assertions">
<head>Other Assertions</head>
- <p>Thus far, we explored how Contoso uses policy expressions and assertions for representing
+ <p>Thus far, we explored how Company-X uses policy expressions and assertions for representing
behaviors that must be engaged for a Web service interaction. What is a policy assertion?
What role does it play? In brief, a policy assertion is a piece of service metadata, and
it identifies a domain (such as messaging, security, reliability and transaction) specific
- behavior that is a requirement. Contoso uses a policy assertion to convey a condition
+ behavior that is a requirement. Company-X uses a policy assertion to convey a condition
under which they offer a Web service. A policy-aware client can recognize policy
assertions and engage these behaviors automatically.</p>
- <p>Providers, like Contoso, have the option to combine behaviors for an interaction from
+ <p>Providers, like Company-X, have the option to combine behaviors for an interaction from
domains such as messaging, security, reliability and transactions. Using policy
assertions, providers can represent these behaviors in a machine-readable form. Web
service developers can use policy-aware clients that recognize these
@@ -354,10 +354,10 @@
<sp:TransportBinding>…</sp:TransportBinding>
</All></eg>
</example>
- <p>In addition to requiring the use of addressing, Contoso allows either the use of
+ <p>In addition to requiring the use of addressing, Company-X allows either the use of
transport- or message-level security for protecting messages. Web Services Policy language
can indicate this choice of behaviors in a machine-readable form. To indicate the use of
- message-level security for protecting messages, Contoso uses the
+ message-level security for protecting messages, Company-X uses the
<code>sp:AsymmetricBinding</code> policy assertion (see the example below).</p>
<example>
<head>Asymmetric Binding Security Policy Assertion</head>
@@ -369,7 +369,7 @@
1.0</emph> - for protecting messages. Policy-aware clients can recognize this policy
assertion, engage message-level security for protecting messages and use headers such
as <code>wss:Security</code> in SOAP Envelopes.</p>
- <p>To allow the use of either transport- or message-level security, Contoso uses the
+ <p>To allow the use of either transport- or message-level security, Company-X uses the
<code>ExactlyOne</code> policy operator. Policy assertions combined using the
<code>ExactlyOne</code> operator requires exactly one of the behaviors represented by
the assertions. The policy expression in the example below requires the use of either
@@ -381,7 +381,7 @@
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
</ExactlyOne></eg>
</example>
- <p>Contoso requires the use of addressing and requires the use of either transport- or
+ <p>Company-X requires the use of addressing and requires the use of either transport- or
message-level security for protecting messages. They represent this combination using
the <code>All</code> and <code>ExactlyOne</code> operators. Policy operators can be mixed
to represent different combinations of behaviors (capabilities and requirements). The
@@ -397,17 +397,17 @@
</ExactlyOne>
</All></eg>
</example>
- <p>Using this policy expression, Contoso gives the choice of mechanisms for protecting
+ <p>Using this policy expression, Company-X gives the choice of mechanisms for protecting
messages to clients (or requesters).</p>
</div2>
<div2 id="optional-policy-assertion">
<head>Optional Policy Assertion</head>
- <p>Through a customer survey program, Contoso learns that a significant number of their
+ <p>Through a customer survey program, Company-X learns that a significant number of their
customers prefer to use the Optimized MIME Serialization (as defined in the MTOM
- specification) for sending and receiving messages. Contoso adds optional support for the
+ specification) for sending and receiving messages. Company-X adds optional support for the
Optimized MIME Serialization and expresses this optional behavior in a machine-readable
form.</p>
- <p>To indicate the use of optimization using the Optimized MIME Serialization, Contoso uses
+ <p>To indicate the use of optimization using the Optimized MIME Serialization, Company-X uses
the <code>mtom:OptimizedMimeSerialization</code> policy assertion (see the example below).</p>
<example>
<head>Optimized MIME Serialization Policy Assertion</head>
@@ -420,7 +420,7 @@
messages. Policy-aware clients can recognize this policy assertion and engage Optimized
MIME Serialization for messages. The semantics of this assertion are reflected in
messages: they use an optimized wire format (MIME Multipart/Related serialization).</p>
- <p>Like Contoso’s optional support for Optimized MIME Serialization, there are behaviors
+ <p>Like Company-X’s optional support for Optimized MIME Serialization, there are behaviors
that may be engaged (in contrast to must be engaged) for a Web service interaction. A
service provider will not fault if these behaviors are not engaged. Policy assertions can
be marked optional to represent behaviors that may be engaged for an interaction. A policy
@@ -448,7 +448,7 @@
</ExactlyOne>
</All></eg>
</example>
- <p>Contoso is able to meet their customer needs by adding optional support for the Optimized MIME
+ <p>Company-X is able to meet their customer needs by adding optional support for the Optimized MIME
Serialization. Optional support is outlined in section 3.4 &framework.title; and
detailed in section 4.5.2, &guidelines.title;, specifically for Optimized MIME Serialization.
An optional policy assertion represents a behavior that may be engaged. When a
@@ -460,12 +460,12 @@
<div2 id="ignorable-policy-assertions">
<head>Ignorable Policy Expressions</head>
<p>
- Suppose Contoso decides that it will log SOAP messages sent and received in an exchange.
+ Suppose Company-X decides that it will log SOAP messages sent and received in an exchange.
This behavior has no direct impact on the messages sent on the wire, and does not affect interoperability.
- Some parties might have a concern about such logging and might decide not to interact with Contoso knowing
- that such logging is performed. To address this concern, Contoso includes a Logging assertion in its policy to enable
+ Some parties might have a concern about such logging and might decide not to interact with Company-X knowing
+ that such logging is performed. To address this concern, Company-X includes a Logging assertion in its policy to enable
such parties to be aware of logging. By marking the Logging assertion with the <att>wsp:Ignorable</att> attribute with a
- value of "true" Contoso indicates that a requester may choose to either ignore such assertions or to consider
+ value of "true" Company-X indicates that a requester may choose to either ignore such assertions or to consider
them as part of policy intersection. An assertion that may be ignored for policy intersection is called an
ignorable assertion.
</p>
@@ -514,10 +514,10 @@
<head>Nested Policy Expressions</head>
<p>In the previous sections, we considered two security policy assertions. In this section,
let us look at one of the security policy assertions in little more detail.</p>
- <p>As you would expect, securing messages is a complex usage scenario. Contoso uses the
+ <p>As you would expect, securing messages is a complex usage scenario. Company-X uses the
<code>sp:TransportBinding</code> policy assertion to indicate the use of transport-level
security for protecting messages. Just indicating the use of transport-level security for
- protecting messages is not sufficient. To successfully interact with Contoso’s Web
+ protecting messages is not sufficient. To successfully interact with Company-X’s Web
services, the developer must know what transport token to use, what secure transport to use, what
algorithm suite to use for performing cryptographic operations, etc. The
<code>sp:TransportBinding</code> policy assertion can represent these dependent
@@ -526,7 +526,7 @@
<p>A policy assertion – like the <code>sp:TransportBinding</code> - identifies a visible
domain specific behavior that is a requirement. Given an assertion, there may be other
dependent behaviors that need to be enumerated for a Web Service interaction. In the case
- of the <code>sp:TransportBinding</code> policy assertion, Contoso needs to identify the
+ of the <code>sp:TransportBinding</code> policy assertion, Company-X needs to identify the
use of a transport token, a secure transport, an algorithm suite for performing
cryptographic operations, etc. A nested policy expression can be used to enumerate such
dependent behaviors.</p>
@@ -591,11 +591,11 @@
</div2>
<div2 id="Referencing_Policy_Expressions">
<head>Referencing Policy Expressions</head>
- <p>Contoso has numerous Web service offerings that provide different kinds of real-time
+ <p>Company-X has numerous Web service offerings that provide different kinds of real-time
quotes and book information on securities such as
<code>GetRealQuote</code>, <code>GetRealQuotes</code> and
- <code>GetExtendedRealQuote</code>. To accommodate the diversity of Contoso’s customers,
- Contoso supports multiple WSDL bindings for these Web services. Contoso provides
+ <code>GetExtendedRealQuote</code>. To accommodate the diversity of Company-X’s customers,
+ Company-X supports multiple WSDL bindings for these Web services. Company-X provides
consistent ways to interact with their services and wants to represent these capabilities
and requirements consistently across all of their offerings without duplicating policy
expressions multiple times. How? It is simple - a policy expression can be named and
@@ -626,12 +626,12 @@
<p>In the example above, the <code>wsu:Id</code> attribute is used to identify a policy
expression. The value of the <code>wsu:Id</code> attribute is an XML ID. The relative IRI
for referencing this policy expression (within the same document) is <code>#common</code>.
- If the policy document IRI is <code>http://real.contoso.com/policy.xml</code> then the
+ If the policy document IRI is <code>http://x.example.com/policy.xml</code> then the
absolute IRI for referencing this policy expression is
- <code>http://real.contoso.com/policy.xml#common. (</code>The absolute IRI is formed by
+ <code>http://x.example.com/policy.xml#common. (</code>The absolute IRI is formed by
combining the document IRI, <code>#</code> and the value of the <code>wsu:Id</code>
attribute.)</p>
- <p> In addition to the Example 2-12, Contoso could have used either the xml:id or wsu:Id.
+ <p> In addition to the Example 2-12, Company-X could have used either the xml:id or wsu:Id.
An example of the use of xml:id similar to that of wsu:Id is shown in Example 2-13. </p>
<example>
<head>Common Policy Expression [xml:id]</head>
@@ -660,7 +660,7 @@
<head>PolicyReference to Common Policy Expression</head>
<eg xml:space="preserve"><PolicyReference URI="#common"/></eg>
</example>
- <p>For referencing a policy expression within the same XML document, Contoso uses the
+ <p>For referencing a policy expression within the same XML document, Company-X uses the
<code>wsu:Id</code> attribute for identifying a policy expression and an IRI to this ID
value for referencing this policy expression using a <code>PolicyReference</code> element.</p>
<p>The example below is a policy expression that re-uses the common policy expression within
@@ -685,10 +685,10 @@
resides in. As such, referencing a policy expression using the <code>Name</code> attribute
relies on additional out of band information. In the example below, the <code>Name</code>
attribute identifies the policy expression. The IRI of this policy expression is
- <code>http://real.contoso.com/policy/common</code>.</p>
+ <code>http://x.example.com/policy/common</code>.</p>
<example>
<head>Common Policy Expression</head>
- <eg xml:space="preserve"><Policy Name=”http://real.contoso.com/policy/common”>
+ <eg xml:space="preserve"><Policy Name=”http://x.example.com/policy/common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsap:UsingAddressing />
</Policy></eg>
@@ -696,7 +696,7 @@
<p>The example below is a policy expression that re-uses the common policy expression above.</p>
<example>
<head>PolicyReference to Common Policy Expression</head>
- <eg xml:space="preserve"><PolicyReference URI="http://real.contoso.com/policy/common"/></eg>
+ <eg xml:space="preserve"><PolicyReference URI="http://x.example.com/policy/common"/></eg>
</example>
<p>As policy expressions are composed from other policy expressions and
assertions from different domains are used in a policy expression,
@@ -712,14 +712,14 @@
</div2>
<div2 id="attaching-policy-expressions-to-wsdl">
<head>Attaching Policy Expressions to WSDL</head>
- <p>A majority of Contoso’s customers use WSDL for building their client applications.
- Contoso leverages this usage by attaching policy expressions to the WSDL binding
+ <p>A majority of Company-X’s customers use WSDL for building their client applications.
+ Company-X leverages this usage by attaching policy expressions to the WSDL binding
descriptions.</p>
<p>In the example below, the <code>SecureBinding</code> WSDL binding description defines a
binding for an interface that provides real-time quotes and book information on
securities. (The prefixes <code>wsdl</code> and <code>tns</code> are used here to denote
the Web Services Description language XML namespace and target namespace of this WSDL
- document.) To require the use of security for these offerings, Contoso attaches the secure
+ document.) To require the use of security for these offerings, Company-X attaches the secure
policy expression in the previous section to this binding description. The WSDL
<code>binding</code> element is a common policy attachment point. The secure policy
expression attached to the <code>SecureBinding</code> WSDL binding description applies to
@@ -734,11 +734,11 @@
…
</wsdl:binding></eg>
</example>
- <p>In addition to providing real-time quotes and book information on securities, Contoso
+ <p>In addition to providing real-time quotes and book information on securities, Company-X
provides other kinds of data through Web services such as quotes delayed by 20 minutes and
security symbols through Web services (for example <code>GetDelayedQuote</code>,
<code>GetDelayedQuotes,</code>
- <code>GetSymbol</code> and <code>GetSymbols</code>). Contoso does not require the use of
+ <code>GetSymbol</code> and <code>GetSymbols</code>). Company-X does not require the use of
security for these services, but requires the use of addressing and allows the use of
optimization.</p>
<example>
@@ -752,7 +752,7 @@
<p>In the example above, the <code>OpenBinding</code> WSDL binding description defines a
binding for an interface that provides other kinds of data such as quotes delayed by 20
minutes and security symbols. To require the use of addressing and allow the use of
- optimization, Contoso attaches the common policy expression in the previous section to
+ optimization, Company-X attaches the common policy expression in the previous section to
this binding description. As we have seen in the <code>SecureBinding</code> case, the
common policy expression attached to the <code>OpenBinding</code> WSDL binding description
applies to any message exchange associated with any <code>port</code> that supports this
@@ -766,7 +766,7 @@
security and optimization. Or, the service may not have such capabilities and
requirements. A policy aware client should not conclude anything
about the absence of policy expressions.</p>
- <p>Service providers, like Contoso, can preserve and leverage their investments in WSDL and
+ <p>Service providers, like Company-X, can preserve and leverage their investments in WSDL and
represent the capabilities and requirements of a Web service as policies. A WSDL document
may specify varying behaviors across Web service endpoints. Web service developers
can use a policy-aware client that recognizes these policy expressions in WSDL
@@ -778,7 +778,7 @@
<head>Policy Automates Web Services Interaction</head>
<p>As you have seen, Web Services Policy is a simple language that has four elements -
<code>Policy, All</code>, <code>ExactlyOne</code> and <code>PolicyReference</code> - and
- one attribute - <code>wsp:Optional</code>. In practice, service providers, like Contoso,
+ one attribute - <code>wsp:Optional</code>. In practice, service providers, like Company-X,
use policy expressions to represent combinations of capabilities and requirements. Web
service developers use policy-aware clients that understand policy expressions
and engage the behaviors represented by providers automatically. A sizable amount of
@@ -833,10 +833,10 @@
nested policy expression. Policy assertions can also be marked optional to represent
behaviors that may be engaged (capabilities) for an interaction. The optional marker is
the <code>wsp:Optional</code> attribute which is placed on a policy assertion element.</p>
- <p>Let us take a closer look at Contoso’s policy expression (see below) from the previous
+ <p>Let us take a closer look at Company-X’s policy expression (see below) from the previous
section.</p>
<example>
- <head>Contoso’s Secure Policy Expression</head>
+ <head>Company-X’s Secure Policy Expression</head>
<eg xml:space="preserve"><Policy>
<All>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
@@ -906,7 +906,7 @@
</example>
<p>A policy expression in the compact form can be converted to the normal form. Web Services
Policy language describes the algorithm for this conversion.</p>
- <p>Let us re-consider Contoso’s policy expression (see the example below). Contoso requires
+ <p>Let us re-consider Company-X’s policy expression (see the example below). Company-X requires
the use of addressing and either transport- or message-level security and allows the use
of optimization. This policy expression is in the compact form and has four policy
alternatives for requesters:</p>
@@ -925,7 +925,7 @@
</item>
</olist>
<example>
- <head>Contoso’s Secure Policy Expression in Compact Form</head>
+ <head>Company-X’s Secure Policy Expression in Compact Form</head>
<eg xml:space="preserve"><Policy wsu:Id=”secure”>
<All>
<PolicyReference URI=”#common”/>
@@ -941,14 +941,14 @@
<wsap:UsingAddressing />
</Policy></eg>
</example>
- <p>Let us look at the normal form for this policy expression. The example below is Contoso’s
+ <p>Let us look at the normal form for this policy expression. The example below is Company-X’s
policy expression in the normal form. As you can see, the compact form is less verbose
than the normal form. The normal form represents a policy as a collection of policy
alternatives. Each of the <code>All</code> operators is a policy alternative. There are
four policy alternatives in the normal form. These alternatives map to bullets (a) through
(d) above.</p>
<example>
- <head>Contoso’s Policy Expression in Normal Form</head>
+ <head>Company-X’s Policy Expression in Normal Form</head>
<eg xml:space="preserve"><Policy>
<ExactlyOne>
<All> <!-- - - - - - - - - - - - - - Policy Alternative (a) -->
@@ -988,7 +988,7 @@
<p>In the previous section, we considered the normal form for policy expressions. As we
discussed, the normal form represents a policy as a collection of policy alternatives. In
this section, let us look at the policy data model.</p>
- <p>Contoso uses a policy to convey the conditions for an interaction. Policy-aware clients,
+ <p>Company-X uses a policy to convey the conditions for an interaction. Policy-aware clients,
like the one used by the developer in our example (as explained earlier in <specref
ref="basic-concepts-policy-expression"/>), view policy as an unordered collection of
zero or more policy alternatives. A policy alternative is an unordered collection of zero
@@ -1058,20 +1058,20 @@
<head>Compatible Policies</head>
- <p>A provider, like Contoso, and a requester, like the policy-aware client used in our example, may represent
+ <p>A provider, like Company-X, and a requester, like the policy-aware client used in our example, may represent
their capabilities and requirements for an interaction as policies and want to limit their
message exchanges to mutually compatible policies. Web Services Policy defines an
intersection mechanism for selecting compatible policy alternatives when there are two or
more policies.</p>
- <p>The example below is a copy of Contoso’s policy expression (from <specref
- ref="normal-form-for-policy-expressions"/>). As we saw before, Contoso offers four
+ <p>The example below is a copy of Company-X’s policy expression (from <specref
+ ref="normal-form-for-policy-expressions"/>). As we saw before, Company-X offers four
policy alternatives. Of them, one of the policy alternatives requires the use of
addressing and transport-level security.</p>
<example>
- <head>Contoso’s Policy Expression</head>
+ <head>Company-X’s Policy Expression</head>
<eg xml:space="preserve"><Policy>
<ExactlyOne>
- <All> <!-- - - - - - - - - - Contoso’s Policy Alternative (a) -->
+ <All> <!-- - - - - - - - - - Company-X’s Policy Alternative (a) -->
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (c1) -->
<wsap:UsingAddressing/>
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (c2) -->
@@ -1082,7 +1082,7 @@
</Policy></eg>
</example>
<p>The client application developer's organization requires the use of addressing and transport-level security for any
- interaction with Contoso’s Web services. The developer represents these behaviors using a policy
+ interaction with Company-X’s Web services. The developer represents these behaviors using a policy
expression illustrated in the example below in normal form. This policy expression
contains one policy alternative that requires the use of addressing and transport-level
security.</p>
@@ -1099,10 +1099,10 @@
</ExactlyOne>
</Policy></eg>
</example>
- <p>The developer lets her policy-aware client select a compatible policy alternative in Contoso’s
+ <p>The developer lets her policy-aware client select a compatible policy alternative in Company-X’s
policy. How does this client select a compatible policy alternative? It is simple – it
uses the policy intersection. That is, the policy-aware client uses these two policy
- expressions (the client’s and Contoso’s) and the policy intersection to select a compatible
+ expressions (the client’s and Company-X’s) and the policy intersection to select a compatible
policy alternative for this interaction. Let us look at the details of policy
intersection.</p>
<p>For two policy assertions to be compatible they must have the same QName. And, if either
@@ -1113,16 +1113,16 @@
they have the same QName and their nested policies are compatible.</p>
<p>Two policy alternatives are compatible if each policy assertion in one alternative is
compatible with a policy assertion in the other and vice-versa. For example, policy
- assertions (c1) and (c2) in Contoso’s policy alternative are compatible with policy
- assertions (t2) and (t1) in tje client’s policy alternative. Contoso’s policy alternative (a)
+ assertions (c1) and (c2) in Company-X’s policy alternative are compatible with policy
+ assertions (t2) and (t1) in tje client’s policy alternative. Company-X’s policy alternative (a)
and the client’s policy alternative are compatible because assertions in these two alternatives
are compatible.</p>
<p>Two policies are compatible if a policy alternative in one is compatible with a policy
- alternative in the other. For example, Contoso’s policy alternative (a) is compatible with
- the client’s policy alternative. Contoso’s policy and the client’s policy are compatible because one
- of Contoso’s policy alternative is compatible with the client’s policy alternative.</p>
+ alternative in the other. For example, Company-X’s policy alternative (a) is compatible with
+ the client’s policy alternative. Company-X’s policy and the client’s policy are compatible because one
+ of Company-X’s policy alternative is compatible with the client’s policy alternative.</p>
<p>For this interaction, the developer’s policy-aware client can use policy alternative (a) to
- satisfy Contoso’s conditions or requirements.</p>
+ satisfy Company-X’s conditions or requirements.</p>
<p>Similarly, policy intersection can be used to check if providers expose endpoints that
conform to a standard policy. For example, a major retailer might require all their
supplier endpoints to be compatible with an agreed upon policy.</p>
@@ -1161,7 +1161,7 @@
</div2>
<div2 id="attaching-policy-expressions-to-wsdl2">
<head>Attaching Policy Expressions to WSDL</head>
- <p>In <specref ref="basic-concepts-policy-expression"/>, we looked into how Contoso attached
+ <p>In <specref ref="basic-concepts-policy-expression"/>, we looked into how Company-X attached
their policy expressions to the WSDL <code>binding</code> element. In addition to the WSDL
<code>binding</code> element, a policy expression can be attached to other WSDL elements
such as <code>service</code>, <code>port</code>, <code>operation</code>
@@ -1193,7 +1193,7 @@
that message.</p>
<p>In the example below, the policy expression is attached to an endpoint policy subject.</p>
<example>
- <head>Contoso’s Policy Expression Attached to WSDL binding Element</head>
+ <head>Company-X’s Policy Expression Attached to WSDL binding Element</head>
<eg xml:space="preserve"><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
<PolicyReference URI="#secure" />
<wsdl:operation name="GetRealQuote">…</wsdl:operation>
@@ -1275,7 +1275,7 @@
<div2 id="combine-policies">
<head>Combine Policies</head>
<p>Multiple policy expressions may be attached to WSDL constructs. Let us consider how
- Contoso could have used multiple policy expressions in a WSDL document. In the example
+ Company-X could have used multiple policy expressions in a WSDL document. In the example
below, there are two policy expressions <code>#common2</code> and <code>#secure2</code>
attached to the <code>SecureBinding</code> WSDL binding and <code>RealTimeDataPort</code>
WSDL port descriptions.</p>
@@ -1321,7 +1321,7 @@
the <code>SecureBinding</code> WSDL binding and <code>RealTimeDataPort</code> WSDL port
descriptions. The <code>#common2</code> policy expression has two policy alternatives. The
<code>#secure2</code> policy expression has two policy alternatives. The
- combination of these two policies is equivalent to Contoso’s secure policy in <specref
+ combination of these two policies is equivalent to Company-X’s secure policy in <specref
ref="basic-concepts-policy-expression"/> and has four policy alternatives. In other
words, the combination of two policies is the cross product of alternatives in these two
policies.</p>
@@ -1365,13 +1365,13 @@
<p>The <code>PolicyReference</code> element allows element and attribute extensibility.</p>
<p>Web Services Policy language enables simple versioning practices that allow requesters to
continue the use of any older policy alternatives in a backward compatible manner. This
- allows service providers, like Contoso, to deploy new behaviors using additional policy
+ allows service providers, like Company-X, to deploy new behaviors using additional policy
assertions without breaking compatibility with clients that rely on any older policy
alternatives.</p>
- <p>The example below represents a Contoso version 1 policy expression. This expression
+ <p>The example below represents a Company-X version 1 policy expression. This expression
requires the use of addressing and transport-level security for protecting messages. </p>
<example>
- <head>Contoso’s Version 1 Policy Expression</head>
+ <head>Company-X’s Version 1 Policy Expression</head>
<eg xml:space="preserve"><Policy>
<ExactlyOne>
<All>
@@ -1381,17 +1381,17 @@
</ExactlyOne>
</Policy></eg>
</example>
- <p>Over time, Contoso adds support for advanced behaviors: requiring the use of addressing
+ <p>Over time, Company-X adds support for advanced behaviors: requiring the use of addressing
and message-level security for protecting messages. They added this advanced support
without breaking compatibility with requesters that rely on addressing and transport-level
- security. The example below is Contoso’s version 2 policy expression. In this version,
- Contoso’s adds a new policy alternative that requires the use of addressing and
+ security. The example below is Company-X’s version 2 policy expression. In this version,
+ Company-X’s adds a new policy alternative that requires the use of addressing and
message-level security. The clients that rely on addressing and transport-level security
- may continue to interact with Contoso’s using the old policy alternative. Of course, these
+ may continue to interact with Company-X’s using the old policy alternative. Of course, these
clients have the option to migrate from using old policy alternatives to new policy
alternatives.</p>
<example>
- <head>Contoso’s Version 2 Policy Expression</head>
+ <head>Company-X’s Version 2 Policy Expression</head>
<eg xml:space="preserve"><Policy>
<ExactlyOne>
<All>
@@ -1405,7 +1405,7 @@
</ExactlyOne>
</Policy></eg>
</example>
- <p>When Contoso added support for advanced behaviors, they spent time to plan for the
+ <p>When Company-X added support for advanced behaviors, they spent time to plan for the
continued support for existing clients, the smooth migration from using current to
advanced behaviors, and the switch to use only the advanced behaviors in the near future
(i.e. sun-setting current behaviors). In this versioning scenario, policy can be used to
@@ -1414,7 +1414,7 @@
functionality when they choose to. This level of versioning support in policy enables the
same class of versioning best practices built into WSDL constructs such as service, port
and binding.</p>
- <p>Let us look at tooling for unknown policy assertions. As service providers, like Contoso,
+ <p>Let us look at tooling for unknown policy assertions. As service providers, like Company-X,
incrementally deploy advanced behaviors, some requesters may not recognize these new
policy assertions. As discussed before, these requesters may continue to interact using
old policy alternatives. New policy assertions will emerge to represent new behaviors and
@@ -1438,26 +1438,26 @@
useful to convey this information to help smooth the versioning process.
</p>
<p>
- Contoso could specify that the older policy alternative will expire at a
- certain point in time using a Contoso specific expiry assertion. The example
- below shows Contoso version 2 policy expression with a hypothetical ignorable EndOfLife
+ Company-X could specify that the older policy alternative will expire at a
+ certain point in time using a Company-X specific expiry assertion. The example
+ below shows Company-X version 2 policy expression with a hypothetical ignorable EndOfLife
Assertion.
</p>
<example>
- <head>Contoso's Version 2 Policy Expression with hypothetical ignorable EndOfLife
+ <head>Company-X's Version 2 Policy Expression with hypothetical ignorable EndOfLife
Assertion</head>
<eg xml:space="preserve">
<Policy>
<ExactlyOne>
<All>
- <contoso:EndOfLife wsp:Ignorable="true"/>Mar-31-2008</contoso:EndOfLife>
+ <company-x:EndOfLife wsp:Ignorable="true"/>Mar-31-2008</company-x:EndOfLife>
<wsap:UsingAddressing/>
<sp:TransportBinding>...</sp:TransportBinding>
</All>
<!-- NEW Policy Alternative -->
<All>
- <contoso:EndOfLife wsp:Ignorable="true">Mar-31-2999</contoso:EndOfLife>
+ <company-x:EndOfLife wsp:Ignorable="true">Mar-31-2999</company-x:EndOfLife>
<wsap:UsingAddressing/>
<sp:AsymmetricBinding>...</sp:AsymmetricBinding>
</All>
@@ -1472,10 +1472,10 @@
<p>
In a scenario such as this, where an assertion type is used for ignorable
information, the use of strict or lax mode and presence or absence of the
- assertion type in the first version are important decisions. If Contoso wishes
+ assertion type in the first version are important decisions. If Company-X wishes
clients to always be able to ignore the assertion, particularly those using
strict intersection, the first policy alternative offered should contain the
- policy assertion type. If Contoso adds the policy assertion type to a
+ policy assertion type. If Company-X adds the policy assertion type to a
subsequent alternative, then requesters using strict mode will not understand
the assertion type and the alternative with the ignorable information will not
be compatible with the older version of the alternative as per the intersection
@@ -1539,10 +1539,10 @@
<p>The <code>sp:IssuedToken</code> security policy assertion identifies a visible domain
specific behavior: the use of a security token – such as SAML token - issued by a third
party for protecting messages. This behavior is relevant to a Web service interaction. For
- the sake of discussion, let us assume that Contoso requires the use of a SAML token issued
- by a third party. Service providers, like Contoso, must convey this usage and all the
+ the sake of discussion, let us assume that Company-X requires the use of a SAML token issued
+ by a third party. Service providers, like Company-X, must convey this usage and all the
necessary information to obtain this security token for Web service developers. This is a
- key piece of metadata for a successful interaction with Contoso’s Web services.</p>
+ key piece of metadata for a successful interaction with Company-X’s Web services.</p>
</div2>
<div2 id="versioning-policy-language"><head>Versioning Policy Language</head>
<p>
@@ -2328,7 +2328,6 @@
<loc
href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/191">191</loc>).
</td>
-
</tr>
<tr>
<td>20070319</td>
@@ -2338,7 +2337,16 @@
<loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0076.html">as outlined.</loc>
Editors' action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/189">189</loc>.
</td>
- </tr>
+ </tr>
+ <tr>
+ <td>20070319</td>
+ <td>PY</td>
+ <td>Implemented the resolution for
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4103">issue 4103</loc>
+ <loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0033.html">as outlined.</loc>
+ Editors' action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/193">193</loc>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Monday, 19 March 2007 17:42:43 UTC