comments and ideas

[Paolo Romano <romanop@dis.uniroma1.it>]

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.

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


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

Best Regards,
Paolo Romano
Rome University
La Sapienza
Italy