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
- From: "iwasa" <kiwasa@jp.fujitsu.com>
- To: "Goodner, Marc Andrue" <marc.andrue.goodner@sap.com>, <tom@coastin.com>, "wsrm" <wsrm@lists.oasis-open.org>
- Date: Thu, 15 May 2003 20:26:21 +0900
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]