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
> > --
> >
> >
> >
