OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrm] Futures List for Discussion at Next WSRM Call


All, Here are some updates of the recent discussion and some proposed resolutions for some issues to be discussed. [Updates] *These resolution should be updated in the list. REL-2 Title: Request/Response MEPs Description: The WS-RM spec v1.0 currently includes only the one-way message pattern. [see email] Proposal: Includes Request/Response MEP in the requirement list. Resolution: The above proposal was accepted at the last telecon. -- REL-24 Title: Flow control Description: Messages may be going no where because the far end is congested. Congestion control is a reliability issue. Transmitter throttles back, from back pressure. TCP can do retransmissions, and HTTP can do retransmissions. This can exacerbate heavy load situations. Details in meeting minutes. Proposal: From Alan J. Weissberger email At first thought, it seems that some form of WS-RM congestion/flow control would be required to throttle back the transmitter during such an "overload condition." On further examination, however, WS-RM flow control would NOT be practicable. The reason is that there is no Congestion Indication/ Congestion Experienced passed to the WS-RM layer from a layer below. Hence, there is no way for WS-RM layer to distinguish between a (repeat) failed connection and a network overload situation. As WS-RM entities can NOT DISTINGUISH BETWEEN TRANSPORT CONNECTION FAILURE(s) and NETWORK OVERLOAD CONDITION(s), it is NOT practicable to consider WS-RM FLOW/CONGESTION CONTROL. Resolution: This was closed with no action at the telecon. -- [Proposed resolutions] *These proposal should be discussed. REL-9 Title: Pull model Description: Useful in situations when a user can only initiate an HTTP request, i.e. behind a firewall or using a limited (mobile) device. [see email] Proposal: Include a requirement to support of limited device and firewall. Resolution: -- REL-10 Title: Attachment support Description: Must be able to use attachments, MIME or WS-Attachments. [see email] Proposal: Include attachments support in the requirement list. The technology to realize this will be an open standard technology. Eg. MIME or SOAP with attachments seems to be the technologies at this point. Other technologies will be considered also if it is an open standard specification. Resolution: -- REL-19 Title: sync/async http binding Description: Clarify whether sync HTTP binding is required for servers implementing the HTTP binding for WS-Reliability. [see original spec] Proposal: Add "Sync HTTP binding support" in the requirement list. Whether the sync binding is mandatory or optional should be discussed and decided later. Resolution: -- REL-18 Title: Combined message types Description: The current specification explicitly prevents bundling an acknowledgment for an earlier message with a request for an acknowledgment (and the associated payload). This restriction reduces the efficiency of long running message exchanges and should be lifted. [see original spec] Proposal: Add a support of reference to the previous message with the Req/Res MEP. Resolution: -- Thanks, Iwasa -- > These are the source for some of the current items (REL-13 to REL-23) on the issue list <http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/1812/wsrm-re qm-issues.html>. References for each of the items below to the corresponding issue list item are inline as <marcg/> below. The same text > as below is present in the issue list descriptions. > > Regards, > Marc g > > -----Original Message----- > From: Tom Rutt [mailto:tom@coastin.com] > Sent: DFri, May 02, 2003 7:59 AM > To: wsrm > Subject: [wsrm] Futures List for Discussion at Next WSRM Call > > > I extracted this list from the appendix 2 of ws-reliability. > > I suggest we discuss this list along with the requirements issues on > Tuesday. > -------------- > Appendix 2 - Futures List > > The features and issues in below are listed as forward-looking statements regarding possible enhancements or the evolution of the WS-Reliability specification. > > <marcg>REL-13</marcg> > 1 Application ofdefined elements and attributes beyond RM > The existing specification contains a number of elements that may apply to many use cases beyond reliable messaging. For example, From / To may be useful for (unreliable) routing through an intermediary. Alignment on a set of common components meeting these general requirements across use cases > should be sought. > > <marcg>REL-14</marcg> > 2 WSDL Define WSDL extensions profiling the use of RM SOAP extensions (e.g.,align Service element with WSDL-SOAP binding) > > <marcg>REL-15</marcg> > 3 Faults Fault handling is from receiver back to the sender. There is no notion of a central Fault location equivalent to a dead message queue or dead letter queue. This would be useful in the case where a missing message in message ordering and sequencing is "never" received. > > <marcg>REL-16</marcg> > 4 Order and sequencing > The behavioral semantics of senders and receivers need to be further defined with regard to the tracking of sequence numbers for the purpose of detecting duplicate or out of order messages. For example: How long should a receiver hold on to out-of-sequence messages in anticipation of a missing > message?" > > <marcg>REL-17</marcg> > 5 Persistence requirements > The specified persistence requirements are high. These requirements could be reduced and full support made configurable. > > <marcg>REL-18</marcg> > 6 Combined message types > The current specification explicitly prevents bundling an acknowledgment for an earlier message with a request for an acknowledgment (and the associated payload). This restriction reduces the efficiency of long running message exchanges and should be lifted. > > <marcg>REL-19</marcg> > 7 Sync/Async Clarify whether sync HTTP binding is required for servers implementing the HTTP binding for WS-Reliability. > > <marcg>REL-20</marcg> > 8 Negotiation Add a negotiation mechanism (e.g., message exchange, notification message for flow control and restart of messaging after failure, etc.). > > <marcg>REL-21</marcg> > 9 From and To Clarify the use of the From and To Elements > > <marcg>REL-22</marcg> > 10 Optionality The use of the term OPTIONAL needs to be revisited particularly in a specification of this nature where interoperability is an explicit goal and RFC 2119 has been referenced. > > <marcg>REL-23</marcg> > 11 Security A reply (ACK or Fault) is required for reliable messaging, either synchronously or asynchronously. Possible denial of service issues should be considered. > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 >

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]