W3C home > Mailing lists > Public > public-ws-addressing@w3.org > April 2007

RE: Consolodated changes for alterngive G prime

From: David Orchard <dorchard@bea.com>
Date: Wed, 4 Apr 2007 09:20:57 -0700
Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C037EEB1B@repbex01.amer.bea.com>
To: "Ashok Malhotra" <ashok.malhotra@oracle.com>, "Maryann Hondo" <mhondo@us.ibm.com>, <tom@coastin.com>
Cc: "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, "David Illsley" <david.illsley@uk.ibm.com>, "WS-Addressing" <public-ws-addressing@w3.org>, <public-ws-addressing-request@w3.org>
Anything for V.Next of Policy on how to write those?
 
Dave

	 

	The usecase of using anon for some responses (say replyTo) and
non-anon for others (say fault) was, I believe, rejected by the WG.
That's good, because it involves message level policies in conjunction
with endpoint policies and I don't see how to write that :-)

	 

	All the best, Ashok 

	
________________________________


	From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Maryann Hondo
	Sent: Wednesday, April 04, 2007 7:30 AM
	To: tom@coastin.com
	Cc: Anish Karmarkar; David Illsley; WS-Addressing;
public-ws-addressing-request@w3.org
	Subject: Re: Consolodated changes for alterngive G prime

	 

	
	Tom, 
	I meant two different policy expressions. 
	I apologize if I  have introduced any confusion, I have as we
say in Boston, a "wicked" head cold :-) 
	
	My point was just that  supporting all response types seems to
cover all "alternatives". Rather than starting up more threads here, 
	 I think what will be most productive is for the ws-policy group
to review what the ws-addressing group has sent 
	and then for the ws-policy group to reply....wow a message
exchange pattern :-) 
	I've been trying to follow all the mail, but perhaps I have
missed some of the exchanges. 
	
	Since you're in both groups, perhaps we can discuss this on the
call today. 
	
	Maryann 
	
	
	

Tom Rutt <tom@coastin.com> 
Sent by: public-ws-addressing-request@w3.org 

04/03/2007 06:56 PM 

Please respond to
tom@coastin.com

To

Maryann Hondo/Austin/IBM@IBMUS 

cc

Anish Karmarkar <Anish.Karmarkar@oracle.com>, David Illsley
<david.illsley@uk.ibm.com>, WS-Addressing <public-ws-addressing@w3.org>,
public-ws-addressing-request@w3.org 

Subject

Re: Consolodated changes for alterngive G prime

 

 

 

	
	
	
	
	I am not sure what it means to have two different endpoint
policies.
	
	How is this different than one policy with three alternatives?
	
	Tom
	
	Maryann Hondo wrote:
	>
	> Tom,
	>
	> In my opinion, negation is part of the policy framework when
there are 
	> alternatives within a policy vocabulary, which is what you
currently
	> have in your example.  I think you will need 2 different
endpoint 
	> policies to support the variations you want.
	>
	> endpoint 1
	> <wsp:Policy>
	>         <wsp:All>
	>            <wsam:Addressing> <-- supports all response types
-->  
	>          </wsp:All>
	> </wsp:Policy>
	>
	> endpoint 2
	> <wsp:Policy>          
	>  <wsp:ExactlyOne>
	>         <wsp:All>
	>             <wsam:Addressing> <-- requires Anonymous responses
--> 
	> Alternative 1
	>                 <wsp:Policy>
	>                     <wsp:ExactlyOne>
	>                        <wsp:All>
	>                              <AnonymousResponses />
	>                          </wsp:All>
	>                      </wsp:ExactlyOne>
	>                  </wsp:Policy>
	>             </wsam:Addressing>
	>         </wsp:All>
	>         <wsp:All>
	>             <wsam:Addressing> <-  requires nonAnonymous
responses --> 
	> Alternative 2
	>                <wsp:Policy>
	>                    <wsp:ExactlyOne>
	>                         <wsp:All>
	>                             <NonAnonymousResponses />
	>                         </wsp:All>
	>                     </wsp:ExactlyOne>
	>                 </wsp:Policy>
	>             </wsam:Addressing>
	>         </wsp:All>
	>     </wsp:ExactlyOne>
	> </wsp:Policy>
	>
	> Maryann
	>
	>
	> *Tom Rutt <tom@coastin.com>*
	> Sent by: public-ws-addressing-request@w3.org
	>
	> 04/03/2007 05:01 PM
	> Please respond to
	> tom@coastin.com
	>
	>
	>                  
	> To
	>                  David Illsley <david.illsley@uk.ibm.com>
	> cc
	>                  Anish Karmarkar <Anish.Karmarkar@oracle.com>,
WS-Addressing 
	> <public-ws-addressing@w3.org>,
public-ws-addressing-request@w3.org
	> Subject
	>                  Re: Consolodated changes for alterngive G
prime
	>
	>
	>
	>                  
	>
	>
	>
	>
	>
	>
	> Negation is never mentioned in either alternative G or F.
	>
	> The idea for alternative G is unqualified "addressing"
assertion means
	> adressing supported, while the nested policy assertions are
	> expressing application restrictions (i.e., anon only or non
anon only).
	>
	> Alternative F states that empty implies no response eprs other
than NONE
	> may be used.  This is closer to negation, but still does not
use the word
	> :negation or negatory or whatever.
	>
	> Tom
	>
	> We are hoping to define this without discussion negation
whatsoever.
	>
	> Tom
	>
	> David Illsley wrote:
	> > Hi Anish,
	> > Unfortunately, in speaking to one of our policy experts,
there seems 
	> to be
	> > a negation concern with at least one scenario - the one in
the 
	> example in
	> > fact... consider the following
	> >
	> > What is the meaning of Alternative 1 in this situation?
	> >
	> > Example 3-8. Client looking for an endpoint which supports 
	> Addressing, and
	> > does not require support for responses (will intersect with
anything)
	> > <wsp:Policy>
	> >     <wsp:ExactlyOne>
	> >         <wsp:All>
	> >             <wsam:Addressing> <-- supports all response
types -->  
	> > Alternative 1
	> >                 <wsp:Policy>
	> >                 </wsp:Policy>
	> >             </wsam:Addressing>
	> >         </wsp:All>
	> >         <wsp:All>
	> >             <wsam:Addressing> <-- requires Anonymous
responses -->
	> > Alternative 2
	> >                 <wsp:Policy>
	> >                     <wsp:ExactlyOne>
	> >                         <wsp:All>
	> >                             <AnonymousResponses />
	> >                         </wsp:All>
	> >                     </wsp:ExactlyOne>
	> >                 </wsp:Policy>
	> >             </wsam:Addressing>
	> >         </wsp:All>
	> >         <wsp:All>
	> >             <wsam:Addressing> <-  requires nonAnonymous
responses -->
	> > Alternative 3
	> >                 <wsp:Policy>
	> >                     <wsp:ExactlyOne>
	> >                         <wsp:All>
	> >                             <NonAnonymousResponses />
	> >                         </wsp:All>
	> >                     </wsp:ExactlyOne>
	> >                 </wsp:Policy>
	> >             </wsam:Addressing>
	> >         </wsp:All>
	> >     </wsp:ExactlyOne>
	> > </wsp:Policy>
	> >
	> > My reading (of Framework, 3.2) is that because the
AnonymousResponses
	> > assertion is found in Alternative 2 that the negation rule
means that
	> > Alternative 1 includes a 'must not do AnonymousResponses
meaning'. And
	> > similarly that because of Alternative 3, Alternative 1
includes a 'must
	> > not do NonAnonymousResponses meaning'.  If so, Alternative 1
(in this
	> > context) does not mean "supports all response types", but in
fact
	> > "Addressing is supported but you must not send Anonymous or 
	> Non-Anonymous
	> > response EPRs".
	> >
	> > Do you agree with this interpretation?
	> > David
	> >
	> >
	> > David Illsley
	> > Web Services Development
	> > MP211, IBM Hursley Park, SO21 2JN
	> > +44 (0)1962 815049 (Int. 245049)
	> > david.illsley@uk.ibm.com
	> >
	> > public-ws-addressing-request@w3.org wrote on 04/03/2007
12:30:50 AM:
	> >
	> >  
	> >> On the negation of nested assertion issue that we talked
about 
	> today on
	> >> the call. I asked our internal policy expert (aka Ashok)
about this 
	> and
	> >> his explanation was that the proposal as it is written, wrt
the 
	> negation
	> >>    
	> >
	> >  
	> >> issue, is fine. I.e., we can say (as we have) that absence
of 
	> either of
	> >> the nested assertion means support for both (or that no
claim is made).
	> >>
	> >> Negation applies *only* when there are two (or more)
alternatives: 
	> P and
	> >>    
	> >
	> >  
	> >> Q. P contains an assertion A (either top-level or nested)
and Q does
	> >> not. If one chooses alternative Q, then that is equivalent
to negation
	> >>    
	> > of A.
	> >  
	> >> HTH.
	> >>
	> >> -Anish
	> >> --
	> >>
	> >> Tom Rutt wrote:
	> >>    
	> >>> attached is html showing all changes agreed today
	> >>>
	> >>> MarcG alternative G proposal:
	> >>>
	> >>>      
	> > 
	>
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/0043.ht
ml
	> >  
	> >>> as amended by Tom Rutt Email
	> >>>
	> >>>      
	> > 
	>
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/0053.ht
ml
	> >  
	> >>>
	> >>>      
	> >
------------------------------------------------------------------------
	> >  
	> >>>     3. Indicating Use of WS-Addressing
	> >>>
	> >>> This specification supports a mechanism for indicating, in
a WSDL
	> >>> description, that the endpoint conforms to the
WS-Addressing
	> >>> specification. That mechanism uses WS-Policy Framework [WS
Policy 1.5
	> >>>      
	> > -
	> >  
	> >>> Framework <#WSPolicy>].
	> >>>
	> >>>
	> >>>       3.1 WS-Policy Assertions
	> >>>
	> >>> The mechanism for indicating that a binding or endpoint
conforms to
	> >>>      
	> > the
	> >  
	> >>> WS-Addressing specification is through the use of the Web
Services
	> >>> Policy - Framework [WS Policy 1.5 - Framework <#WSPolicy>]
and Web
	> >>> Services Policy - Attachment [WS Policy 1.5 - Attachment
	> >>> <#WSPolicyAttachment>] specifications. This specification
defines
	> >>>      
	> > three
	> >  
	> >>> policy assertions.
	> >>>
	> >>> The wsam:Addressing policy assertion applies to the
endpoint policy
	> >>>      
	> > subject.
	> >  
	> >>> For WSDL 1.1, these assertions may be attached to
|wsdl11:port| or
	> >>> |wsdl11:binding|. For WSDL 2.0, they may be attached to
	> >>> |wsdl20:endpoint| or |wsdl20:binding|.
	> >>>
	> >>> A policy expression containing the wsam:Addressing policy
assertion
	> >>>      
	> > MUST
	> >  
	> >>> NOT be attached to a wsdl:portType or wsdl20:interface.
The
	> >>> wsam:Addressing policy assertion specifies a concrete
behavior 
	> whereas
	> >>>      
	> >
	> >  
	> >>> the wsdl:portType or wsdl20:interface is an abstract
construct.
	> >>>
	> >>>
	> >>>         3.1.1 Addressing Assertion
	> >>>
	> >>> The wsam:Addressing policy assertion is a nested policy
container
	> >>> assertion. The meaning of this assertion, when present in
a policy
	> >>> alternative, is that WS-Addressing is required to
communicate with 
	> the
	> >>>      
	> >
	> >  
	> >>> subject. The wsam:Addressing assertion indicates that
there are no
	> >>> restrictions on the use of WS-Addressing unless otherwise 
	> qualified by
	> >>>      
	> >
	> >  
	> >>> assertions in its nested policy expression.  In order to
indicate 
	> that
	> >>>      
	> >
	> >  
	> >>> the subject supports WS-Addressing but does not require
its use, an
	> >>> additional policy alternative should be provided which
does not
	> >>>      
	> > contain
	> >  
	> >>> this assertion. This may be done in WS-Policy compact form
by adding
	> >>>      
	> > the
	> >  
	> >>> attribute wsp:Optional="true" to the wsam:Addressing
assertion.
	> >>>
	> >>>
	> >>>
	> >>>
	> >>>         3.1.2 AnonymousResponses Assertion
	> >>>
	> >>> The wsam:AnonymousResponses element MAY be used as a
policy assertion
	> >>> nested within the wsam:Addressing assertion in accordance
with the
	> >>>      
	> > rules
	> >  
	> >>> laid down by WS-Policy Framework 1.5 section 4.3.2.
	> >>>
	> >>> The appearance of this element within a policy
alternativethe
	> >>> wsam:Addressing policy assertion indicates that the
endpoint 
	> expresses
	> >>>      
	> >
	> >  
	> >>> explicitrequires support for request messages with to use
response
	> >>> endpoint EPRs that contain the anonymous URI
	> >>> ("http://www.w3.org/2005/08/addressing/anonymous") as the
value of
	> >>> [address]. In other words, the endpoint guarantees support

	> forrequires
	> >>>      
	> >
	> >  
	> >>> the use of anonymous responses.
	> >>>
	> >>> The absence of the wsam:AnonymousResponses policy
assertion within a
	> >>> policy alternative does *not* indicate that the endpoint
will not
	> >>>      
	> > accept
	> >  
	> >>> request messages with response endpoint EPRs that contain
the
	> >>>      
	> > anonymous
	> >  
	> >>> URI as an address; it simply indicates the lack of any
affirmation of
	> >>> support for anonymous URIs.
	> >>>
	> >>> The None URI ("http://www.w3.org/2005/08/addressing/none")
may appear
	> >>>      
	> > as
	> >  
	> >>> the value of [address] in place of the anonymous URI; this
value MUST
	> >>>      
	> > be
	> >  
	> >>> accepted.
	> >>>
	> >>>
	> >>>         3.1.3 NonAnonymousResponses Assertion
	> >>>
	> >>> The wsam:NonAnonymousResponses element MAY be used as a
policy
	> >>>      
	> > assertion
	> >  
	> >>> nested within the Addressing assertion in accordance with
the rules
	> >>>      
	> > laid
	> >  
	> >>> down by WS-Policy Framework 1.5 section 4.3.2. The
	> >>> wsam:NonAnonymousResponses policy assertion MUST NOT be
used in the
	> >>>      
	> > same
	> >  
	> >>> policy alternative as the wsam:AnonymousResponses policy
assertion.
	> >>>
	> >>> The appearance of this element within a policy
alternativethe
	> >>> wsam:Addressing assertion indicates that the endpoint
expresses
	> >>>      
	> > explicit
	> >  
	> >>> support forrequires request messages with to use response
endpoint
	> >>>      
	> > EPRs
	> >  
	> >>> that contain something other than the anonymous URI as the
value of
	> >>> [address]. In other words, the endpoint guarantees support

	> forrequires
	> >>>      
	> >
	> >  
	> >>> the use of non-anonymous responses. This assertion is
deliberately
	> >>> vague; its presence indicates that some non-anonymous
addresses will
	> >>>      
	> > be
	> >  
	> >>> accepted but doesn't constrain what such an address might
look 
	> like. A
	> >>>      
	> >
	> >  
	> >>> receiver can still reject a request that contains an
address that it
	> >>> doesn't understand or that requires a binding it doesn't
support.
	> >>>
	> >>> As with the other assertions, the absence of the
	> >>> wsam:NonAnonymousResponses policy assertion within a
policy
	> >>>      
	> > alternative
	> >  
	> >>> does *not* indicate that the endpoint will not accept
request 
	> messages
	> >>>      
	> >
	> >  
	> >>> with response endpoint EPRs that contain something other
than the
	> >>> anonymous URI address; it simply indicates the lack of any

	> affirmation
	> >>>      
	> >
	> >  
	> >>> of support for them.
	> >>>
	> >>> The None URI ("http://www.w3.org/2005/08/addressing/none")
may appear
	> >>>      
	> > as
	> >  
	> >>> the value of [address] in place of a non-anonymous
address; this 
	> value
	> >>>      
	> >
	> >  
	> >>> MUST be accepted.
	> >>>
	> >>>
	> >>>         3.1.4 Examples (Compact Form)
	> >>>
	> >>> /Example 3-1.// Subject supports WS-Addressing, no
statement on
	> >>> supported response EPRs/
	> >>>
	> >>> <wsp:Policy>
	> >>>
	> >>>     <wsam:Addressing wsp:Optional="true">
	> >>>
	> >>>         <wsp:Policy/>
	> >>>
	> >>>     </wsam:Addressing>
	> >>>
	> >>> </wsp:Policy>
	> >>>
	> >>> /Example 3-2.// Subject requires WS-Addressing, no
statement on
	> >>> supported response EPRs/
	> >>>
	> >>> <wsp:Policy>
	> >>>
	> >>>     <wsam:Addressing>
	> >>>
	> >>>         <wsp:Policy/>
	> >>>
	> >>>     </wsam:Addressing>
	> >>>
	> >>> </wsp:Policy>
	> >>>
	> >>> /Example 3-3. Subject supports WS-Addressing, explicitly
(and
	> >>> optionally) supports anonymous and non-anonymous response
EPRs/
	> >>>
	> >>> <wsp:Policy>
	> >>>
	> >>>     <wsam:Addressing wsp:Optional="true">
	> >>>
	> >>>         <wsp:Policy>
	> >>>
	> >>>             <wsam:AnonymousResponses wsp:Optional="true"/>
	> >>>
	> >>>             <wsam:NonAnonymousResponses
wsp:Optional="true"/>
	> >>>
	> >>>         </wsp:Policy>
	> >>>
	> >>>     </wsam:Addressing>
	> >>>
	> >>> </wsp:Policy>
	> >>>
	> >>> /Example 3-4. Subject requires WS-Addressing, requires
explicit
	> >>>      
	> > support
	> >  
	> >>> of anonymous or non-anonymous response EPRs/
	> >>>
	> >>> <wsp:Policy>
	> >>>
	> >>>     <wsam:Addressing>
	> >>>
	> >>>         <wsp:Policy>
	> >>>
	> >>>             <wsp:ExactlyOne>
	> >>>
	> >>>                 <wsam:AnonymousResponses/>
	> >>>
	> >>>                 <wsam:NonAnonymousResponses/>
	> >>>
	> >>>             </wsp:ExactlyOne>
	> >>>
	> >>>         </wsp:Policy>
	> >>>
	> >>>     </wsam:Addressing>
	> >>>
	> >>> </wsp:Policy>
	> >>>
	> >>> /Example 3-53.// Subject requires WS-Addressing and
explicit
	> >>> supportrequires the use of non-anonymous response EPRs/
	> >>>
	> >>> <wsp:Policy>
	> >>>
	> >>>     <wsam:Addressing>
	> >>>
	> >>>         <wsp:Policy>
	> >>>
	> >>>             <wsam:NonAnonymousResponses/>
	> >>>
	> >>>         </wsp:Policy>
	> >>>
	> >>>     </wsam:Addressing>
	> >>>
	> >>> </wsp:Policy>
	> >>>
	> >>>
	> >>>         3.1.5 Examples (Normal Form)
	> >>>
	> >>> /Example 3-46. Subject supports WS-Addressing, no
statement on
	> >>>      
	> > supported
	> >  
	> >>> response EPRs/
	> >>>
	> >>> <wsp:Policy>
	> >>>
	> >>>     <wsp:ExactlyOne>
	> >>>
	> >>>         <wsp:All/>
	> >>>
	> >>>         <wsp:All>
	> >>>
	> >>>             <wsam:Addressing>
	> >>>
	> >>>                 <wsp:Policy>
	> >>>
	> >>>                     <wsp:ExactlyOne>
	> >>>
	> >>>                         <wsp:All/>
	> >>>
	> >>>                     </wsp:ExactlyOne>
	> >>>
	> >>>                 </wsp:Policy>
	> >>>
	> >>>             </wsam:Addressing>
	> >>>
	> >>>         </wsp:All>
	> >>>
	> >>>     </wsp:ExactlyOne>
	> >>>
	> >>> </wsp:Policy>
	> >>>
	> >>> /Example 3-57. Subject requires WS-Addressing, no
statement on
	> >>>      
	> > supported
	> >  
	> >>> response EPRs/
	> >>>
	> >>> <wsp:Policy>
	> >>>
	> >>>     <wsp:ExactlyOne>
	> >>>
	> >>>         <wsp:All>
	> >>>
	> >>>             <wsam:Addressing>
	> >>>
	> >>>                 <wsp:Policy>
	> >>>
	> >>>                     <wsp:ExactlyOne>
	> >>>
	> >>>                         <wsp:All/>
	> >>>
	> >>>                     </wsp:ExactlyOne>
	> >>>
	> >>>                 </wsp:Policy>
	> >>>
	> >>>             </wsam:Addressing>
	> >>>
	> >>>         </wsp:All>
	> >>>
	> >>>     </wsp:ExactlyOne>
	> >>>
	> >>> </wsp:Policy>
	> >>>
	> >>> /Example 3-8. Subject supports WS-Addressing, explicitly
(and
	> >>> optionally) supports anonymous and non-anonymous response
EPRs/
	> >>>
	> >>> <wsp:Policy>
	> >>>
	> >>>     <wsp:ExactlyOne>
	> >>>
	> >>>         <wsp:All/>
	> >>>
	> >>>         <wsp:All>
	> >>>
	> >>>             <wsam:Addressing>
	> >>>
	> >>>                 <wsp:Policy>
	> >>>
	> >>>                     <wsp:ExactlyOne>
	> >>>
	> >>>                         <wsp:All/>
	> >>> 
	> >>>                     </wsp:ExactlyOne>
	> >>>
	> >>>                 </wsp:Policy>
	> >>>
	> >>>             </wsam:Addressing>
	> >>>
	> >>>         </wsp:All>
	> >>>
	> >>>         <wsp:All>
	> >>>
	> >>>             <wsam:Addressing>
	> >>>
	> >>>                 <wsp:Policy>
	> >>>
	> >>>                     <wsp:ExactlyOne>
	> >>>
	> >>>                         <wsp:All>
	> >>>
	> >>>                             <wsam:AnonymousResponses/>
	> >>>
	> >>>                         </wsp:All>
	> >>>
	> >>>                     </wsp:ExactlyOne>
	> >>>
	> >>>                 </wsp:Policy>
	> >>>
	> >>>             </wsam:Addressing>
	> >>>
	> >>>         </wsp:All>
	> >>>
	> >>>         <wsp:All>
	> >>>
	> >>>             <wsam:Addressing>
	> >>>
	> >>>                 <wsp:Policy>
	> >>>
	> >>>                     <wsp:ExactlyOne>
	> >>>
	> >>>                         <wsp:All>
	> >>>
	> >>>                             <wsam:NonAnonymousResponses/>
	> >>>
	> >>>                         </wsp:All>
	> >>>
	> >>>                     </wsp:ExactlyOne>
	> >>>
	> >>>                 </wsp:Policy>
	> >>>
	> >>>             </wsam:Addressing>
	> >>>
	> >>>         </wsp:All>
	> >>>
	> >>>         <wsp:All>
	> >>>
	> >>>             <wsam:Addressing>
	> >>>
	> >>>                 <wsp:Policy>
	> >>>
	> >>>                     <wsp:ExactlyOne>
	> >>>
	> >>>                         <wsp:All>
	> >>>
	> >>>                             <wsam:AnonymousResponses/>
	> >>>
	> >>>                             <wsam:NonAnonymousResponses/>
	> >>>
	> >>>                         </wsp:All>
	> >>>
	> >>>                     </wsp:ExactlyOne>
	> >>>
	> >>>                 </wsp:Policy>
	> >>>
	> >>>             </wsam:Addressing>
	> >>>
	> >>>         </wsp:All>
	> >>>
	> >>>     </wsp:ExactlyOne>
	> >>>
	> >>> </wsp:Policy>
	> >>>
	> >>> /Example 3-9. Subject requires WS-Addressing, requires
explicit
	> >>>      
	> > support
	> >  
	> >>> of anonymous or non-anonymous response EPRs/
	> >>>
	> >>> <wsp:Policy>
	> >>>
	> >>>     <wsp:ExactlyOne>
	> >>>
	> >>>         <wsp:All>
	> >>>
	> >>>             <wsam:Addressing>
	> >>>
	> >>>                 <wsp:Policy>
	> >>>
	> >>>                     <wsp:ExactlyOne>
	> >>>
	> >>>                         <wsp:All>
	> >>>
	> >>>                             <wsam:AnonymousResponses/>
	> >>>
	> >>>                         </wsp:All>
	> >>>
	> >>>                     </wsp:ExactlyOne>
	> >>>
	> >>>                 </wsp:Policy>
	> >>>
	> >>>             </wsam:Addressing>
	> >>>
	> >>>         </wsp:All>
	> >>>
	> >>>         <wsp:All>
	> >>>
	> >>>             <wsam:Addressing>
	> >>>
	> >>>                 <wsp:Policy>
	> >>>
	> >>>                     <wsp:ExactlyOne>
	> >>>
	> >>>                         <wsp:All>
	> >>>
	> >>>                             <wsam:NonAnonymousResponses/>
	> >>>
	> >>>                         </wsp:All>
	> >>>
	> >>>                     </wsp:ExactlyOne>
	> >>>
	> >>>                 </wsp:Policy>
	> >>>
	> >>>             </wsam:Addressing>
	> >>>
	> >>>         </wsp:All>
	> >>>
	> >>>     </wsp:ExactlyOne>
	> >>>
	> >>> </wsp:Policy>
	> >>>
	> >>> /Example 3-610. Subject requires WS-Addressing and
explicit support
	> >>> ofrequires the use of non-anonymous response EPRs/
	> >>>
	> >>> <wsp:Policy>
	> >>>
	> >>>     <wsp:ExactlyOne>
	> >>>
	> >>>         <wsp:All>
	> >>>
	> >>>             <wsam:Addressing>
	> >>>
	> >>>                 <wsp:Policy>
	> >>>
	> >>>                     <wsp:ExactlyOne>
	> >>>
	> >>>                         <wsp:All>
	> >>>
	> >>>                             <wsam:NonAnonymousResponses/>
	> >>>
	> >>>                         </wsp:All>
	> >>>
	> >>>                     </wsp:ExactlyOne>
	> >>>
	> >>>                 </wsp:Policy>
	> >>>
	> >>>             </wsam:Addressing>
	> >>>
	> >>>         </wsp:All>
	> >>>
	> >>>     </wsp:ExactlyOne>
	> >>>
	> >>> </wsp:Policy>
	> >>>
	> >>>
	> >>>         3.1.6 Finding Compatible Policies
	> >>>
	> >>>
	> >>>         When a client is looking for an endpoint with
compatible
	> >>>      
	> > policy,
	> >  
	> >>>         one common method used is to take the policy
intersection
	> >>>         between the policy which the client is looking
for, and the
	> >>>         policy asserted in the WSDL document; a non-empty
intersection
	> >>>         is sought. The policy used by the client must be
written
	> >>>         carefully to avoid unexpected results. This is
most obvious
	> >>>      
	> > when
	> >  
	> >>>         the client is not looking for explicit support of
a particular
	> >>>         kind of response; failing to take care could mean
missing a
	> >>>         compatible policy.
	> >>>
	> >>> /Example 3-7. Client looking for an endpoint which
supports
	> >>>      
	> > Addressing,
	> >  
	> >>> and which supports anonymous responses/
	> >>>
	> >>> <wsp:Policy>
	> >>>
	> >>>     <wsp:ExactlyOne>
	> >>>
	> >>>         <wsp:All>
	> >>>
	> >>>             <wsam:Addressing>
	> >>>
	> >>>                 <wsp:Policy>
	> >>>
	> >>>                     <wsp:ExactlyOne>
	> >>>
	> >>>                         <wsp:All>
	> >>>
	> >>>                             <AnonymousResponses
Optional=?true? />
	> >>>
	> >>>                         </wsp:All>
	> >>>
	> >>>                     </wsp:ExactlyOne>
	> >>>
	> >>>                 </wsp:Policy>
	> >>>
	> >>>             </wsam:Addressing>
	> >>>
	> >>>         </wsp:All>
	> >>>
	> >>>     </wsp:ExactlyOne>
	> >>>
	> >>> </wsp:Policy>
	> >>>
	> >>> /Example 3-8. Client looking for an endpoint which
supports
	> >>>      
	> > Addressing,
	> >  
	> >>> and does not require support for responses (will intersect
with
	> >>>      
	> > anything)/
	> >  
	> >>> <wsp:Policy>
	> >>>
	> >>>     <wsp:ExactlyOne>
	> >>>
	> >>>         <wsp:All>
	> >>>
	> >>>             <wsam:Addressing> <-- supports all response
types -->
	> >>>
	> >>>                 <wsp:Policy>
	> >>>
	> >>>                 </wsp:Policy>
	> >>>
	> >>>             </wsam:Addressing>
	> >>>
	> >>>         </wsp:All>
	> >>>
	> >>>         <wsp:All>
	> >>>
	> >>>             <wsam:Addressing> <-- requires Anonymous
responses -->
	> >>>
	> >>>                 <wsp:Policy>
	> >>>
	> >>>                     <wsp:ExactlyOne>
	> >>>
	> >>>                         <wsp:All>
	> >>>
	> >>>                             <AnonymousResponses />
	> >>>
	> >>>                         </wsp:All>
	> >>>
	> >>>                     </wsp:ExactlyOne>
	> >>>
	> >>>                 </wsp:Policy>
	> >>>
	> >>>             </wsam:Addressing>
	> >>>
	> >>>         </wsp:All>
	> >>>
	> >>>         <wsp:All>
	> >>>
	> >>>             <wsam:Addressing> <-  requires nonAnonymous
responses -->
	> >>>
	> >>>                 <wsp:Policy>
	> >>>
	> >>>                     <wsp:ExactlyOne>
	> >>>
	> >>>                         <wsp:All>
	> >>>
	> >>>                             <NonAnonymousResponses />
	> >>>
	> >>>                         </wsp:All>
	> >>>
	> >>>                     </wsp:ExactlyOne>
	> >>>
	> >>>                 </wsp:Policy>
	> >>>
	> >>>             </wsam:Addressing>
	> >>>
	> >>>         </wsp:All>
	> >>>
	> >>>     </wsp:ExactlyOne>
	> >>>
	> >>> </wsp:Policy>
	> >>>
	> >>>
	> >>>
	> >>>
	> >>>
	> >>>
	> >>>
	> >>>
	> >>>         For more detailed descriptions of the use of
wsp:Optional,
	> >>>         wsp:Ignorable, and strict and lax intersection,
please refer
	> >>>      
	> > to
	> >  
	> >>>         the WS-Policy Primer [WS Policy 1.5 - Primer
	> >>>      
	> > <#WSPolicyPrimer>].
	> >  
	> >>>
	> >>>
	> >>>      
	> >
	> >
	> >
	> >
	> >
	> >
	> > Unless stated otherwise above:
	> > IBM United Kingdom Limited - Registered in England and Wales
with 
	> number
	> > 741598.
	> > Registered office: PO Box 41, North Harbour, Portsmouth,
Hampshire 
	> PO6 3AU
	> >
	> >
	> >
	> >
	> >
	> >
	> >
	> >  
	>
	> -- 
	> ----------------------------------------------------
	> Tom Rutt                 email: tom@coastin.com;
trutt@us.fujitsu.com
	> Tel: +1 732 801 5744          Fax: +1 732 774 5133
	>
	>
	>
	>
	
	-- 
	----------------------------------------------------
	Tom Rutt                 email: tom@coastin.com;
trutt@us.fujitsu.com
	Tel: +1 732 801 5744          Fax: +1 732 774 5133
	
	
	
	
Received on Wednesday, 4 April 2007 16:40:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:17 GMT