OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] i021 Proposal


Optional, as in you don't have to support it?
If so, +1. All of policy is optional isn't it?

-Anish
--

Christopher B Ferris wrote:
> 
> Anish,
> 
> Then I would have to insist that it be OPTIONAL.
> 
> Cheers,
> 
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
> 
> Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote on 03/02/2006 
> 01:24:14 PM:
> 
>  > I don't understand why we would do that.
>  > MPS is meant to attach policies with the message. That is it, nothing
>  > more. Your requirement that this should require that the binding/port
>  > support RM for all messages (in/out/fault) for that port/binding does
>  > not provide the granularity that is needed.
>  >
>  > For example, if an endpoint/port has an in-out operation it should be
>  > able to assert that RM is supported/required on the in message and not
>  > make any stmt about the out message or other message in other operations
>  > supported at that port/endpoint/portType.
>  >
>  > Instead, I quite like Sanjay's proposal.
>  >
>  > -Anish
>  > --
>  >
>  > Christopher B Ferris wrote:
>  > >
>  > > If we added the following, IBM could support this proposal.
>  > >
>  > > If an RM policy assertion is attached to any of:
>  > >
>  > >     * wsdl:binding/wsdl:operation/wsdl:input
>  > >     * wsdl:binding/wsdl:operation/wsdl:output
>  > >     * wsdl:binding/wsdl:operation/wsdl:fault
>  > >
>  > > then an RM policy assertion, specifying wsp:Optional=true MUST be
>  > > attached to the corresponding wsdl:binding or wsdl:port, indicating 
> that
>  > > the endpoint supports WS-RM. Any messages, regardless of whether they
>  > > have an attached Message Policy Subject RM policy assertion, MAY be 
> sent
>  > > to that endpoint using WS-RM. Additionally, the receiving endpoint 
> MUST
>  > > NOT reject any message belonging to a Sequence, simply because 
> there was
>  > > no Message Policy Subject RM policy assertion attached to that message.
>  > >
>  > > Cheers,
>  > >
>  > > Christopher Ferris
>  > > STSM, Software Group Standards Strategy
>  > > email: chrisfer@us.ibm.com
>  > > blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
>  > > phone: +1 508 377 9295
>  > >
>  > > "Patil, Sanjay" <sanjay.patil@sap.com> wrote on 02/23/2006 12:02:39 AM:
>  > >
>  > >  >  
>  > >  > First of all, I hate to call the proposal as my proposal because it
>  > >  > is really building upon ideas of several TC members :)
>  > >  >  
>  > >  > On your point about clarifying the message level applicability when
>  > >  > EPS is involved, I personally prefer that we do not duplicate (and
>  > >  > risk conflicting with) the semantics described (should I say alluded
>  > >  > to) in the policy framework. However, I am open to suggestions for
>  > >  > adding clarification text.
>  > >  >  
>  > >  > -- Sanjay
>  > >  >
>  > >  > From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
>  > >  > Sent: Wednesday, Feb 22, 2006 16:38 PM
>  > >  > To: Patil, Sanjay; wsrx
>  > >  > Subject: RE: [ws-rx] i021 Proposal
>  > >
>  > >  > Hi Sanjay:
>  > >  > In this proposal, unlike your previous one, you do not specify that
>  > >  > if the RM assertion is applied
>  > >  > to a WSDL message definition it applies to that message alone and if
>  > >  > it is applied to a port or a binding
>  > >  > it applies to all messages under that port/binding definition.
>  > >  >  
>  > >  > You probably did that to avoid duplication, but WS-PolicyAttachment
>  > >  > is famously vague about this and
>  > >  > it would be better to spell it out clearly in the WS-RX spec.
>  > >  > All the best, Ashok
>  > >  >  
>  > >  >
>  > >  > From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
>  > >  > Sent: Wednesday, February 22, 2006 12:33 PM
>  > >  > To: wsrx
>  > >  > Subject: [ws-rx] i021 Proposal
>  > >
>  > >  >
>  > >  > Here is an updated proposal for resolving the long pending issue
>  > >  > i021. The key difference in comparison to what exists in the WS-RM
>  > >  > Policy specification today is that -- the proposal allows Message
>  > >  > Policy Subject (in addition to the Endpoint Policy Subject) for the
>  > >  > RM Policy assertion.
>  > >  > I would also like to bring to your notice that this proposal:
>  > >  > -- Avoids text that would repeat the semantics already addressed in
>  > >  > WS-PolicyAttachment, for example, an Endpoint Policy Subject applies
>  > >  > to behaviors associated with all the message exchanges of the
>  > >  > endpoint, and applies to aspects of both communicating with as well
>  > >  > as instantiating the endpoint. So the proposal would seem a bit
>  > >  > short and dry to some people!
>  > >  > -- Does not include any recommendations for which wsdl elements
>  > >  > (among those that are allowed by the proposal - wsdl:port Vs. wsdl:
>  > >  > binding Vs.binding level messages) are more appropriate for policy
>  > >  > attachment, since this may simply be a matter of best practices and
>  > >  > there are no strong technical reasons for the specification to
>  > >  > promote one approach over another, IMO.
>  > >  > -- Does not include any text related to whether and how EPR
>  > >  > contained policies may interact with the WSDL attached policies,
>  > >  > since I couldn't arrive at any precise and useful (normative) text
>  > >  > in this regard.
>  > >  > Please try to send in your comments before the conf-call tomorrow
>  > > (2/23)!
>  > >  > -- Sanjay
>  > >  >
>  > >
>  > 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  > >
>  > >  > Replace the entire content of section 2.3 (Assertion Attachment) in
>  > >  > the WS-RM Policy specification with the following:
>  > >  > The RM policy assertion is allowed to have the following Policy
>  > >  > Subjects [WS-PolicyAttachment]:
>  > >  > Endpoint Policy Subject
>  > >  > Message Policy Subject
>  > >  > WS-PolicyAttachment defines a set of WSDL/1.1 [WSDL 1.1] policy
>  > >  > attachment points for each of the above Policy Subjects. Since an RM
>  > >  > policy assertion specifies a concrete behavior, it MUST NOT be
>  > >  > attached to the abstract WSDL policy attachment points.
>  > >  > The following is the list of WSDL/1.1 elements whose scope contains
>  > >  > the Policy Subjects allowed for an RM policy assertion but which
>  > >  > MUST NOT have RM policy assertions attached:
>  > >  > wsdl:message
>  > >  > wsdl:portType/wsdl:operation/wsdl:input
>  > >  > wsdl:portType/wsdl:operation/wsdl:output
>  > >  > wsdl:portType/wsdl:operation/wsdl:fault
>  > >  > wsdl:portType
>  > >  > The following is the list of WSDL/1.1 elements whose scope contains
>  > >  > the Policy Subjects allowed for an RM policy assertion and which MAY
>  > >  > have RM policy assertions attached:
>  > >  > wsdl:port
>  > >  > wsdl:binding
>  > >  > wsdl:binding/wsdl:operation/wsdl:input
>  > >  > wsdl:binding/wsdl:operation/wsdl:output
>  > >  > wsdl:binding/wsdl:operation/wsdl:fault
>  > >  > If the RM policy assertion appears in a policy expression attached
>  > >  > to a wsdl:binding as well as to the individual wsdl:binding level
>  > >  > message definitions(wsdl:binding/wsdl:operation/wsdl:input, wsdl:
>  > >  > binding/wsdl:operation/wsdl:output, wsdl:binding/wsdl:
>  > >  > operation/wsdl:fault), the parameters in the former MUST be used and
>  > >  > the latter ignored.
>  > >  > If the RM policy assertion appears in a policy expression attached
>  > >  > to a wsdl:port as well as to the other allowed WSDL/1.1 elements,
>  > >  > the parameters in the former MUST be used and the latter ignored.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]