Re: [wsrm] comments and ideas

["iwasa" <kiwasa@jp.fujitsu.com>]

Paolo,

Thanks for your comments to WS-Reliability spec.
My comments are in-line.


> I am sending you some ideas and comments about the WS-reliability
> specification and Nokia Web Services Reliabilty document recently sent in
> the TC list.
>
>  1) Sending one acknowledgment for every single message exchanged results
> in a not minimal overhead, expecially if you keep into account XML
> verbosity. The natural, definitely not original solution is allowing a
> single acknowledgment for multiple messages. Did you see any other
> advantages, apart from implementation simplicity, in a one-one relation
> between message and ack? One issue may be that IBM&MS (et co.)
> WS-Reliable Messaging already proposes a similar mechanism, just like TCP
> does with well-known "sliding windows". I hope that neither TCP's authors,
> nor IBM & Microsoft will start a legal action if this TC should choose an
> analogous mechanism.

Actually that was Fujitsu's original proposal to ebXML MS Reliable Messaging
specification a couple years ago.
See http://lists.ebxml.org/archives/ebxml-transport/200008/msg00153.html
for reference. And I believe it was well-known technology as you mentioned.
So I believe we can choose better way for us, and allowing sending
back mupliple acks in a single ack message looks better.

> 2) Also keeping on re-sending the same message as long as an
> acknowledgment is received is an expensive mechanism, whose advantage is
> simplicity, but which may lead to severe overheads in case of loss of
> acknoledgments for large messages.
>  One solution may be defining an apposite "inquiry" message, which could
> be sent in case of failure suspect by any indoubt part. Note that such a

I personally like this idea. And I think we could consider to include this
suggestion in the requirement doc.
I think we need to be carefull to make sure that sender can guarantee
the delivery of all messages with this way, if sender intended to do so.
And it looks like no problem.

And the one way to include "inquiry" message would be just adding "inquiry"
message as optional function. And the other would be changing the way
to request Ack. It detail, sender can request multiple Acks when sender
want to do so. And it looks like what you are suggesting is the second one.
Actually I am not sure this way works all the time, since I didn't
simulate all kind of fault case, but it looks good at this point.
Anyway it is good to consider for this solution.

> message could also be useful in order to ensure end-hosts state
> synchronization: e.g. it could be used in a request-response mep to let
> the requester acknowledge the responder upon the receiption of the
> response message (see pag.10 Nokia_WebServicesReliability "Because
> Responder depends on Step 6, MEP must be extended for delivering
> information to Responder after step 4.") What do you think about it?

>"Because Responder depends on Step 6, MEP must be extended for
>delivering information to Responder after step 4."

This could mean we need to add Ack for Ack message,
which I'm not sure it is appropriate or not.
But if we can solve this requirement with the solution above,
it would be no problem, I believe.

> Comments about Nokia document
>
>
> 1 - pag 5: Instead of "physical machine failure"  I would rather say "
> host and network failures". Reliable messaging needs to deal with network
> errors as well as crashes.
>
> 2- pag.5 "State synchronization: If the MEP is cancelled for any reason
> then it is desirable for both nodes to set their state as if there were no
> communication between the parties."
> My idea of state synchronization in the messaging context is ensuring that
> both parties are eventually informed about the delivery of every exchanged
> message. IMO this idea captures the meaning of the requirement at
> pag.10, Guaranteed delivery for Request-Response MEP, "Because Responder
> depends on Step 6, MEP must be extended for delivering information to
> Responder after step 4."
>
> 3 - pag.13, I appreciate the proposal of distinguishing different levels
> of crash tolerance, as the availability of persistent storages on embedded
> mobile devices is not so common, yet.
> If I correctly understand what you mean for "replay" below in this page, I
> would rather say "possible delivery duplication- at most once delivery",
> or "no duplication - exactly once delivery".
>
>
> 4 - I believe that having several specifications around for reliable
> messaging may only confuse ultimate users and therefore slow down the
> Web-Services market. My (naive) hope is that since this is the first
> proposal for a WS Reliable Messaging Protocol to have been submitted to a
> standardization organization, any other alternative idea or proposal is
> openly discussed, compared and possibly integrated within this protocol.

I agree with you and I hope this happen without any IPR problems.
At least we need to make sure we won't violate other company's IPR, if any,
without their formal approval.
And I don't believe, but not sure, it is problem to compare WS-R spec with
other Reliability specs.

> On the other hand I see that Web Services and ebXML model are currently
> not interoperable, but I look forward for hearing any idea about the
> possible integration of the 2 messaging protocols. I think that a common
> ground does exist between ebXML MS and WS-RM and I am a supporter of
> future collaborations with the ebXML MS TC. First of all because the ebXML
> MS is a mature protocol which can not simply be ignored by this TC, second
> because I think the overlapping between the 2 protocols should be clear to
> everybody. Moreover, I think it would be a strenght for this protocol to
> be possibly integrated into a wider context, i.e. ebXML. My personal
> opinion about the possible integration between ebXML MS and WS-RM is to
> use a modular approach: WS-RM should clearly define the interface to the
> supported messaging features. Such functionalities are also required
> (and actually already provided) by ebXML MS. This way WS-RM could be used
> as it is in Web Services scenarios and as a module of ebXML-MS in the
> ebXML context.

I like this idea too. Since both TCs are in OASIS, I won't have a big
suprise when this happens.

Regards,

Iwasa
Fujitsu

>
> Best Regards,
> Paolo Romano
> Rome University
> La Sapienza
> Italy
>
>
>