- From: Ashok Malhotra <ashok.malhotra@oracle.com>
- Date: Wed, 4 Apr 2007 07:47:44 -0700
- To: "Maryann Hondo" <mhondo@us.ibm.com>, "tom@coastin.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" <public-ws-addressing-request@w3.org>
- Message-ID: <20070404074744748.00000001392@amalhotr-pc>
I think we need to enumerate all the WS-Addressing usecases and try and write policies for them.
Anish and I came up with five usecases:
1. Use WS-Addressing
2. Use WS-Addressing with anonymous for all responses
3. Use WS-Addressing with non-anonymous for all responses
4. Use WS-Addressing with both anon and non-anon being allowed for all responses
5. Do not use WS-Addressing
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.html
> >
> >>> as amended by Tom Rutt Email
> >>>
> >>>
> >
> http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/0053.html
> >
> >>>
> >>>
> > ------------------------------------------------------------------------
> >
> >>> 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 14:49:26 UTC