[standards-jig] SOAP over Jabber
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