[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] issue i021 requirements
Gilbert Pilz wrote: > 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. > How does one ensure that 'an implementation of RMS that *does* support message-level granularity.' is always used? -- by specifying in our spec. If we say that "true" message level granularity (pre Chris' proposal) is not allowed by our spec, then one cannot do that. The problem with the proposal is that it is left to the RMS as to whether getStatus operation is reliable or not and RMD has not say in it. Interestingly, if an RMS does not support message-level granularity (not sure why it would recognize port- binding-level granularity but not message-level granularity -- since both of them would be defined in the same spec), then it would not recognize/process the RM assertion with the message subject in WSDL and would not even know that the endpoint/message supports WSRM. -Anish -- > - 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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]