Re: SOAP/XMPP

David Hull wrote:
> In a previous message [1] I mentioned some potential concerns with 
> SOAP/XMPP, but hadn't had a chance to look through the relevant specs in 
> detail.  Now that I have, I'd like to amplify what I said before just a bit.
> 
>     *  From the viewpoint of transport protocols (if it's not a sin to
>       view a Presence Protocol as a transport protocol :-) I see two
>       separate protocols: <iq/> and <message/>
>     * <iq/> is basically request-response oriented.
>     * <message/> is essentially one-way, even though it natively
>       supports to/from addressing and message id.
> 
> I'm reasonably happy with binding SOAP request-response to <iq/>.  I'm 
> less happy with binding it to <message/>.  On the other hand, I would 
> very much like to see a SOAP one-way MEP defined and bound to <message/>.
> 
> The description of the SOAP request-response MEP states that, "In the 
> absence of failure in the underlying protocol, this MEP consists of 
> exactly two SOAP messages [or a SOAP message and an ack, if we go that 
> way]."  If understand the SOAP/XMPP proposal correctly, the 
> <message/>-based binding does not guarantee either a response or a 
> failure.  It seems quite possible for me to send you a <message/> and 
> you to simply disregard it, essentially staying in the sending+receiving 
> state forever.  

That is accurate. The XMPP <message/> stanza is really fire-and-forget 
(or to use your more accurate phrase, "two correlated one-way messages") 
because it does not have guaranteed request-response semantics (as <iq/> 
does).

> The protocol is working fine, but I'm not.  For my 
> money, this is the primary distinction between "request-response" and 
> "two correlated one-way messages."
> 
> On the other hand, defining a one-way MEP over <message/>, which would 
> basically just mean getting rid of almost everything but the description 
> of how to put the SOAP envelope into a stanza, would allow for both 
> clean one-way SOAP messaging and for "asynchronous request-response".  
> If you're doing plain request-response (i.e., anonymous response 
> endpoints), you would use <iq/>.  If you're doing anything else, you'd 
> use <message/>.

I'll be happy to update JEP-0072 ("SOAP Over XMPP") to reflect whatever 
MEP consensus we reach here.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml