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:]
> 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:]
> > 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.
>
>
