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

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.

2 WSDL Define WSDL extensions profiling the use of RM SOAP extensions
(e.g.,align Service element with WSDL-SOAP binding)

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.

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?"

5 Persistence requirements
The specified persistence requirements are high. These requirements
could be reduced and full support made configurable.

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.

7 Sync/Async Clarify whether sync HTTP binding is required for servers
implementing the HTTP binding for WS-Reliability.

8 Negotiation Add a negotiation mechanism (e.g., message exchange,
notification message for flow control and restart of messaging after
failure, etc.).

9 From and To Clarify the use of the From and To Elements

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.

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]