RE: [ws-rx] issue i021 requirements

["Abbie Barbir" <abbieb@nortel.com>]

Yup,

 

I agree with Chris proposal.

PS: It is time to move on this issue.

 

Abbie

 

---

From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
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: 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
> > --
> > 
> > 
> >