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:
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> "Ashok Malhotra" <> 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:]
> > 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:
> > blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> > phone: +1 508 377 9295
> >
> > Anish Karmarkar <> 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
> > > --
> > >
> > >
> > >
