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

["Goodner, Marc Andrue" <marc.andrue.goodner@sap.com>]

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-reqm-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