[jdev] Mil XMPP to replace SOAP?

[Jones Alasdair]

Thanks for your help, I'll take a look at the archives.

If I use XMPP I will be ditching SOAP. The data is all XML, so it could be
put straight into the XMPP message.

I mentioned speed, because I have had experience using the Jabberd sever and
my clients (using MUSE API) with a large number of (small) messages and it
seemed to queue them up and send them in batches. In some cases, messages
took about a minute to arrive which is not good enough.

Any comments about security. What is the support for this in XMPP? It would
be preferable to have multiple security layers to allow clients to specify
which other clients have access to their data.

Alasdair Jones
ajones5 at dstl.gov.uk <mailto:ajones5 at dstl.gov.uk> 
Office: +44 (02392) 217663
Lab:    +44 (02392) 217488
Fax:    +44 (02392) 217535



> -----Original Message-----
> From: Fabio Forno [mailto:fabio.forno at polito.it]
> Sent: 14 April 2005 12:04
> To: Jabber software development list
> Cc: AJONES5 at mail.dstl.gov.uk
> Subject: Re: [jdev] Mil XMPP app to replace SOAP?
> 
> 
> Jones Alasdair wrote:
> > Could anyone give me some advice on whether XMPP would be a 
> sensible option
> > to use as an inter-application communication method to replace SOAP?
> >
> 
> SOAP and XMPP cover different aspects of communication. The former 
> concerns data representation and econding, while XMPP is a transport, 
> like HTTP. Thus I wouldn't say that I want to replace SOAP with XMPP, 
> but XMPP can either be an additional transport for SOAP (see JEP 72 
> http://www.jabber.org/jeps/jep-0072.html), i.e. SOAP messages within 
> XMPP messages, or it can carry your property-encoded data, 
> provided it 
> is valid XML.
> 
> > The current implementation I intend to replace, centres on 
> a single database
> > to which n clients can submit and retrieve XML data. The 
> idea is that each
> > client will submit military situational awareness data for 
> it's area of
> > coverage to the database. Each client can then retrieve all the data
> > submitted by all the other clients. The key is to ensure 
> that each client
> > will be able to receive the same data, at the same time. The current
> > limitations of this system means that every client has to 
> poll the database
> > for updates and there is no inherent security. I'm hoping 
> that by using
> > XMPP, I could write a client that can use it's Pub Sub and security
> > features. 
> 
> This is a scenario where XMPP beats other transports, since it can 
> efficiently push data to clients, and pubsub will help you 
> delivering it 
> without complicating too much your business logic.
> 
> But I don't know if there are any inherent limitations of this
> > approach, in particular, the data transmission must be 
> guaranteed and very
> > fast (<1sec).
> 
> Time constraints are not a major problem, both XMPP servers 
> and pubsub 
> components can be scaled accordingly to the load.
> Guaranteed trasmission may be a problem under certain circumstances. 
> AFAIK at present you may count only on the raliability of TCP, but if 
> there are disconnections some messasges may be lost. In the 
> past there 
> have been several discussions on this topic, you may search 
> the archives
> Anyway this could be generally solved by adding message 
> sequence number 
> and acks in your application.
> 
> -- 
> Fabio Forno, Ph.D.
> *** Employer line for sale ***
> Phone: +39 011 2276 102 - JabberId: sciasbat at jabber.linux.it
> 

"This e-mail is intended for the recipient only.  If you are not the
intended recipient you must not use, disclose, distribute, copy, print,
or rely upon this e-mail. If an addressing or transmission error has
misdirected this e-mail, please notify the author by replying to this e-mail."

"Recipients should note that all e-mail traffic on MOD systems is
subject to monitoring and auditing."