[standards-jig] SOAP over Jabber

Fabio Forno f.forno at kamin.polito.it
Wed Jan 29 17:31:25 UTC 2003

Fabio Forno wrote:

> moving nature it cannot be always reached). Therefore imho <message/> 
> elements with <x/> data would fit better.

Before facing the JEP, I'd like to know if there is consensus about some 
points. SOAP defines just a bag for messages, giving a common and 
standardized way to exchange information between peers in distributed 
environments. It intentionally doesn't state anything about the 
underlying protocols, thus it doesn't force to adopt any communication 
pattern. More precisely it explicitly says that SOAP messages are 
unidirectional, even if usually they are coupled in request/response 
So, why should somebody prefer to supply web services using jabber as 
transport? Because it can do something more SOAPely then http or other 
protocols can do. Two are the features of jabber that can be very 
interesting for web services vendors:
- the ability to deliver asynchronous messages to any entity with a jid 
in a reliable way; for example, with the traditional web services 
infrastructure it's almost impossible to implement event alert services 
in a general network: you must where  is the other end point or base 
everyting on SMTP, with all its problems
- the presence information

The first point can be exploited splitting the SOAP transport in two 
distinct protocols, through <iq/> elements as in xml-rpc, and through 
<message/> elements with </x> data. Then it will up to developers to 
chose the most appropriate protocol. For rpc like interaction use <iq/>, 
<messages/> for the others. Therefore, copying from JEP-009:

<iq type='set' to='responder at company-a.com/soap-server' id='1'>
   <query xmlns='jabber:iq:soap'>
     <soapaction>someaction</soapaction> /* just to be able carry the
                                            HTTP SOAPAction header*/
     <SOAP-ENV:Envelope ...>

and for messages:

<message to='responder at company-a.com/soap-server' id='1'>
   <x xmlns="http://www.jabber.org/protcols/soap/">
     <soapaction >someaction</soapaction>
     <SOAP-ENV:Envelope ...>

If SOAP messages have attachments, any number of
<attachment url="someurl"/> elements can be added for oob transfer like 
DTCP, or <attachment encoding="encoding name">encoded data</attachment> 
for in band transfer

Since I'd like to be able to keep the option of sending also long soap 
messages with in band transmissions (in some circumnstances Jabber may 
be the only proctocol a cliant can speak), without compromising too much 
the global latency in s2s connections, SOAP transports implementations 
and gateways should be able to split and reconstruct long messages. For 
this task a mechanism similar to JEP-0047, in band bytestreams could be 
good starting point.

Finally two words about presence information. There is no such a concept 
in any SOAP specification, but we luckily have it and jabber peers can 
use it to send SOAP messages in a more intelligent way. It would be 
valuable to to export this information to the external world with a 
simple SOAP interface. A jabber server could send presence information 
also to some extern entities. For example fabio at jabber.org could decide 
to send his presence information to his jabber contacts, but also 
http://dot.com/some-soap-based-service if this site supports the 
presence interface.
Instead I don't know whether it is good idea the dual service, to export 
presence information with a soap interface, since users should be able 
to control who has access to their presence; moreover I don't see the 
usefulness to poll for somebody's presence.

So, if there aren't objections or other ideas, I'd like start preparing 
the first version of the JEP for SOAP transport with the double <iq/> 
<message/> transport.

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