RE: [ws-rx] issue i021 requirements

["Ashok Malhotra" <ashok.malhotra@oracle.com>]

This is exactly where we disagree.  In our view,
if the RMS is a conforming implementation it MUST understand message-level granularity.

> .... it's just that there 
> may be implementations of the RMS that are not capable of 
> supporting message-level granularity.



All the best, Ashok
 

> -----Original Message-----
> From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] 
> Sent: Thursday, March 09, 2006 1:40 PM
> To: Anish Karmarkar; wsrx
> Subject: RE: [ws-rx] issue i021 requirements
> 
> I think all of these requirements are reasonable, but I have 
> a comment about this last sentence:
> 
> "The capabilities provided in (1) - (4) above should not 
> force the port to support reliability for the getStatus operation."
> 
> If I understand Chris' position no one is forcing RM 
> semantics on the getStatus operation, it's just that there 
> may be implementations of the RMS that are not capable of 
> supporting message-level granularity. If the overhead of 
> using RM for getStatus is completely unacceptable to you, 
> then you would be well advised to use an implementation of RMS that
> *does* support message-level granularity. The point is that 
> the RMD should be flexible enough to support RMS 
> implementations that both do and do not support message-level 
> granularity.
> 
> - gp
>  
> 
> > -----Original Message-----
> > From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> > Sent: Thursday, March 09, 2006 5:01 AM
> > To: wsrx
> > Subject: [ws-rx] issue i021 requirements
> > 
> > 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
> > --
> > 
> > 
> > 
> > 
> ______________________________________________________________
> _________
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
> 
>