RE: Can anyone point us to information on WS-Reliability

I've been chatty all day long, and of course I can't pass the opportunity to
comment on this spec.

At first glance it appears to meet all the requirements for reliable
messaging, especially in the implementation of B2B scenarios. Great work.

A few comments/clarifications:

2.2.2 Would be great to know if there is a recommended retry
interval/count/back-out policy, or a way to specify one.

2.2.3 There are cases where message loss is not an issue and therefore
persistence is not required (best-effort). Would be great to have
best-effort guarantee that does not require any persistence.

3.1.3 There seems to be a lot of redundancy which gets compounded when you
add port type, operation, SOAP action, WS-Routing, to and service fields,
etc. Too many ways to get the same message to the same service. The more
options we have the more likely you are not never achieve interoperability.
I can think of one use case where you would benefit form having a service
element (i.e. no redundancy), but the spec does not clarify why/when this
element should be used.

3.2.4 No clear why you would want an asynch ack if you are using a
synchronous protocol, or how you could get synch ack when using an
asynchronous protocol. From an implementation perspective, when would I want
to use this operation?

3.3.1 I'm not a big fan of the start/continue/end approach as presented
here. I think it actually makes implementation using a process engine less
efficient, especially if your conversations are open-ended, and we are
starting to see more and more of that in business scenarios. Of course you
can always have arbitrary sequences (e.g. week long sequence with
removeAfter set to true at the end of the week), but then you can't tolerate
message loss in the sequence and you need
yet-another-state-management-thingy. Alternative approach for sequencing
(e.g. m' follows m) would be much easier to support and tolerate message
loss.

3.4.1 Would prefer different elements to distinguish ack from fault rather
than using the MessageType element.

For issue 4, receiver should hold to out-of-sequence message until it
decides to expire it at which point it should not process any previous
message. That would require a denied fault which the received should be able
to communicate indicating it received the message, there's nothing wrong
with the message, it simply has no intention of processing it.

For issue 6, being able to piggyback acks on top of subsequent request would
be great, but I believe that would require the messages to be sent/received
over a short period of time, in which case HTTP 1.1 persistent connections
could provide the same performance without complicating the specification.

arkin


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Jeff Mischkinsky
> Sent: Thursday, January 09, 2003 12:23 AM
> To: Champion, Mike; www-ws-arch@w3.org
> Subject: Re: Can anyone point us to information on WS-Reliability
>
>
>
> At 09:38 PM 1/8/2003, Champion, Mike wrote:
>
> >http://news.com.com/2100-1001-979779.html is all I can find about this:
> >
> >"A group of information technology companies published a specification
> >Thursday designed to improve the reliability of business
> applications that
> >use Web services. WS-Reliability, if accepted as a standard and
> adopted by
> >Web services providers, will let a company ensure that a message sent
> >between two different applications is delivered reliably. "
>
>
> Try:
> http://otn.oracle.com/tech/webservices/htdocs/spec/ws-reliability.html
>
> or, alternatively:
>
> http://xml.fujitsu.com/en/about/ws_r.html
> http://www.hitachi.co.jp/soft/wsrm/
> http://www.nec.co.jp/press/ja/0301/WS-ReliabilityV1.0Public.zip
> http://www.sonicsoftware.com/wsreliability
> http://sunonedev.sun.com/platform/technologies/technologies_mv.html
>
> They should all be live (assuming I can type correctly) sometime today, 9
> Jan 2003.
>
> cheers,
>    jeff
>

Received on Thursday, 9 January 2003 23:20:01 UTC