Yup,
I agree with Chris proposal.
PS: It is time to move on this issue.
Abbie
From: Christopher B Ferris
[mailto:]
Sent: Thursday, March 09, 2006 12:09
PM
To: Ashok Malhotra
Cc: Anish Karmarkar;
wsrx
Subject: RE: [ws-rx] issue i021 requirements
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
> > --
> >
> >
> >
