RE: [wsrm] comments and ideas

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

> <paolo>
>  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.
> </paolo>
>
> A SOAP message is typically not analogous to a packet, except in cases
> where an application built using SOAP defines a message as being a piece
> of a larger unit. (e.g. ebXML Messaging's Message Order module).  How
> would you group the acks?  What if batching acks slows down the
> execution of a business process which is waiting for an acknowledgement
> before proceeding to its next step? "Ack!" is right, bad pun intended.

<paoloReply> I see your point, and I believe that a wise choice would be
allowing the sender to require immediate acknowledgment in case an urgent
ack was needed. Alternatively, if we agree that the latter is the most
common case, we could prescribe the opposite, i.e. ack batching in case of
ordered messages or not urgent acknowledgments.
</paoloReply>

>
> <paolo>
> 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?
> </paolo>
>
> ebMS' StatusRequest service does this, more or less.
>
> <snip />

<paoloReply>
If I remember well, ebMS' StatusRequest should not be employed for
reliable messaging, but only to discover availabilty of service. Please
correct me if i am wrong. I suggest to use this inquiry mechanism to avoid
retransmission of unacknowledged requests.
</paoloReply>

>
>
> <paolo>
> 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.
> </paolo>
>
> ebMS messages are valid SOAP w/ Attachments messages (therefore,
> technically interoperable with 'web services'), so I assume what you
> mean is that: "ebXML already has a working solution for much of what
> these RM specifications are just starting on, but ebXML is bad PR right
> now, so we have to characterize the issue as being 'interoperability',
> and do the work over again with a 'WS-' prefix."  This is a bit of a
> sticky subject for me, as you can probably see, because no one has given
> me a really good reason (beyond the WS-* label's ability to help TC
> participants round up funding to participate) for re-inventing this
> wheel.  I think it would have been more appropriate for the ebMS group
> to release an abstract, standalone RM spec based on their RM mechanism,
> which works reasonably well.

<paoloReply> I do not know if you will consider this reason a good one but
I'll it try anyway. ebMS is the messaging module of ebXML,and this latter
addresses issues which are currently undefined in WS. ebXML had a top-down
development, while WS are being built bottom-up. I hope one day the WS and
ebXML models will converge, but at this time ebMS can not be used as it is
for WS, this is the real point. They are just too much. One approach could
have been identifying a subset of ebMS features to be used by WS.
Instead a different proposal has been presented, but at this time, it
borrows almost everything (at least conceptually, not syntactically) by
the ebMS experience. I would take it  positively and consider this a
chance to have new people involved indirectly in the ebMS development
process as well.

</paoloReply>

>
>
> <paolo>
> 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.
> </paolo>
>
> If you look at this TC's roster, I think you'll notice that there is a
> preponderance of members who are also long time members of the ebMS TC,
> myself included.  I think that the likelihood of WSRM meeting the ebMS
> requirements for its Reliable Messaging protocol are extremely high, and
> I think its nearly a foregone conclusion that should requirements match
> up, WSRM will be adopted by ebMS.
>
>
> Best Regards,
>
> Matthew MacKenzie
> Editor, OASIS ebXML Messaging TC
>
>