[standards-jig] SOAP over Jabber

Fabio Forno f.forno at kamin.polito.it
Mon Jan 27 19:48:04 UTC 2003

Peter Saint-Andre wrote:
> Heh, I sent my message before I checked mail in this folder today, so I
> didn't realize you already posted about this.

In fact I thought you were replying to my first post :)

> It seems to me that the only potential hurdle is the fact that SOAP
> requires a full document, whereas Jabber sends XML snippets that are not
> full documents. So a Jabber SOAP component or library might need to put
> the document headers back on after the SOAP call is received over Jabber.
> Other than that, it seems that SOAP over Jabber would be fairly simple
> (we'd just use a wrapper <query/> similar to what we do for Jabber-RPC).
> But maybe I'm missing something....

This would mimic just the transport of SOAP over HTTP, which is an 
intrinsic request/reply synchronous protocol. SOAP messages could be 
also one way  asynchronous messages, and Jabber would be the ideal 
transport in this case, specially for messages directed to end parts 
that cannot be always reached like in wireless networks (for example: an 
intelligent car exports some kind services through SOAP, but for its 
moving nature it cannot be always reached). Therefore imho <message/> 
elements with <x/> data would fit better.

Moreover I wouldn't bother too much about the complex infrastructure 
around SOAP, such as WS-Routing, Referral, Security, Transaction etc, 
since they are all based on SOAP messages, thus, if the underlying 
transport works for SOAP, it should wor also for all of them

A problem a can forsee is the dimension of SOAP messages. Jabber is 
designed to transport small text messages, SOAP (and also XML-RPC) 
envelops could be rather big. While requests are almost always few 
hundreds of bytes big, answers could have any size. In s2s channels this 
could lead great troubles in terms of QoS, since once a long message is 
sent no other messages could pass, with the risk of high latencies. 
There could be two solutions:
- some kind of karma also for components implementing SOAP, or 
application 2 application communications in general, that penalizes 
compoments sending too much data; thus they will be forced to send large 
results as attachments,  that's to say sending just the link and 
retrieving them out of band or with a file transfer mechanism
- cutting large SOAP messages into smaller chunks and reconstructing 
them at the receiver

I prefer the second solution, since the first, which is more efficient 
in terms of bandwidth, is not precluded, and it would allow to tranport 
any message anyway, without having to process it.

Fabio Forno - PhD Student
Politecnico di Torino - Dip. Automatica ed Informatica
C.so Duca degli Abruzzi 24 - 10129 Torino (Italy)
Phone: +39 011 564 7137 - JabberId: sciasbat at jabber.linux.it

More information about the Standards mailing list