Re: [ws-rx] issue i021 requirements

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Chris,

Aren't we talking about RM policy attachments in WSDL? If the RM enabled 
endpoint doesn't understand WS-Policy or RM assertions or the 
WSDL/Policy is not available then none of these questions arise (i.e. 
requiring that RM assertion with wsp:optional='true' on binding/port, 
per your proposal, is not going to help). It is only in the case where 
the policy/wsdl are available and understood that we have to figure out 
the behavior.

-Anish
--

Christopher B Ferris wrote:
> 
> Ashok,
> 
> Where does it say that an RM enabled endpoint MUST understand WS-Policy 
> and/or the
> WS-RM policy assertion?
> 
> I don't think it unreasonable at all.
> 
> 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
> 
> "Ashok Malhotra" <ashok.malhotra@oracle.com> wrote on 03/09/2006 
> 11:51:20 AM:
> 
>  > Chris, you said ...
>  >  
>  > > There are certain situations, such as a gateway, that may not have
>  > access to the
>  > > WSDL/policy to determine which messages should be included in an RM
>  > Sequence.
>  >  
>  > This is the contentious requirement.  You want the spec to cover
>  > situations where
>  > one of the participants does not adhere to the spec or does not have
>  > enough information
>  > to follow the spec.  I don't think this is reasonable.
>  > All the best, Ashok
>  >  
>  >
>  > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
>  > Sent: Thursday, March 09, 2006 8:24 AM
>  > To: Anish Karmarkar
>  > Cc: wsrx
>  > Subject: Re: [ws-rx] issue i021 requirements
> 
>  >
>  > Anish,
>  >
>  > I don't necessarily disagree with these requirements.
>  >
>  > However, as I indicated in my previous notes, and during the 
> discussion on
>  > last week's call, It isn't clear to me that every RM enabled
>  > endpoint will have
>  > the capacity to apply the RM semantics on a message-by-message basis.
>  >
>  > There are certain situations, such as a gateway, that may not have
>  > access to the
>  > WSDL/policy to determine which messages should be included in an RM
>  > Sequence. Further more, even if the WSDL/policy WERE available, there 
> may be
>  > considerable overhead involved in having to parse the messages (in the
>  > gateway scenario) to determine if they match those messages which have
>  > been annotated as needing to be sent reliably.
>  >
>  > In such cases where a source endpoint is just on/off for all messages 
> that
>  > pass though, I think that the corresponding destination endpoint 
> should NOT
>  > reject messages that are sent reliably yet are not indicated as being 
> required
>  > to be sent reliably in the WSDL/policy.
>  >
>  > Thus, adding to my proposed addendum to Sanjay's 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.
>  >
>  > I would offer the following explanation/rationale:
>  >
>  > There might be certain RM implementations that are incapable of
>  > applying RM QoS semantics on a per-message basis. In order
>  > to ensure the broadest interoperability, when an endpoint decorates
>  > its WSDL with RM policy assertions using Message Policy Subject,
>  > it must also be prepared to accept that all messages sent to that
>  > endpoint might be sent within the context of an RM Sequence, regardless
>  > of whether the corresponding wsdl:input, wsdl:output or wsdl:fault
>  > had an attached RM policy assertion.
>  >
>  > Rather than turn away messages that were unnecessarily sent with RM
>  > semantics, the receiving endpoint described by the WSDL
>  > must accept these messages.
>  >
>  > By attaching an RM policy assertion that specifies wsp:
>  > Optional="true" to the corresponding endpoint that has attached RM 
> policy
>  > assertions at the Message Policy Subject level, the endpoint is
>  > describing the above constraint in policy.
>  >
>  > 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/09/2006 
> 08:01:12 AM:
>  >
>  > > I took an action during last week's concall to send requirements for
>  > > what I see as the desired semantics for issue i021. Sorry for being 
> late
>  > > but I'm on vacation till 17th march (my regrets for the next 2 
> concalls).
>  > >
>  > > Requirements:
>  > >
>  > > 1) Provide the capability to specify in WSDL that a particular message
>  > > (input, output, or fault) MUST be sent reliably within a WSRM Sequence.
>  > >
>  > > 2) Provide the capability to specify in WSDL that a particular message
>  > > (input, output, or fault) MAY be sent using WSRM. The means that it is
>  > > the sender's choice (and not the receiver's) whether the message is 
> sent
>  > > reliably or not.
>  > >
>  > > 3) Provide the capability to specify in a WSDL binding/port that all
>  > > messages  sent using that binding/port MUST be sent reliably within a
>  > > WSRM Sequence (but not in the same Sequence). This potentially 
> could be
>  > > syntactic sugar based on how the capability in (1) is provided.
>  > >
>  > > 4) Provide the capability to specify in a WSDL binding/port that all
>  > > messages  sent using that binding/port MAY be sent reliably within a
>  > > WSRM Sequence (but not in the same Sequence). The means that it is the
>  > > sender's choice (and not the receiver's) whether the message is sent
>  > > reliably or not. This potentially could be syntactic sugar based on 
> how
>  > > the capability in (2) is provided.
>  > >
>  > > 5) The capability in (1) and (2) should not impose onerous 
> constrains on
>  > > other messages within the same portType/Binding/Port wrt reliability.
>  > > For example, one should have the ability to specify that a particular
>  > > in-message MUST be sent reliably without requiring any reliability
>  > > constrains on the out-message (supported or required).
>  > >
>  > > Consider a port which is a purchase order service providing 'submitPO'
>  > > and 'getStatus' operations. The submitPO operation is reliable, secure
>  > > and transacted operation which returns a PO number. Both the in and 
> out
>  > > messages for submitPO are sent reliably. The getStatus operations
>  > > requires the PO number and returns a status (pending, approved) -- 
> this
>  > > is not a secure, reliable or a transacted operation. The capabilities
>  > > provided in (1) - (4) above should not force the port to support
>  > > reliability for the getStatus operation.
>  > >
>  > > -Anish
>  > > --
>  > >
>  > >
>  > >