[Standards] Proposed XMPP Extension: Discovery and Integration ofXMPP Services

Chris Mullins chris.mullins at coversant.net
Wed Mar 28 16:30:12 UTC 2007

[Discovery and Integration of XMPP Services]

-- Quote --
Once a bare JID for a particular service has been established via
an Echo message is sent to the bare JID of the Service. To facilitate
tracking an id attribute MUST be specified on the message "ping" sent by
client and it MUST be echoed in the "pong" response. If multiple "pong" 
responses are received it is up to the client to determine which to
-- end quote --

> I migth be missing something but.. why is the ping-pong mechanism 
> required besides discovering the resource (named "Concrete service" 
> - a bit strange, term not found in 2-Glosary).

The ping-pong is required to find a running service that is online and

Let's say you're looking for service "Archive Message to Tape" - there
may be only 1 instance of this service running, or there may be 500
instances of this service running. The services are load balanced by
presence priority. By sending a message to the bare JID of the service
you (the client) are assured to get a service that considers itself to
be available. Depending on the load on the service, that service may
then lower it's priority (from 100 to 95), and the next client to look
for an "Archive Message to Tape" service will get a different instance
of the service. 

The goal is to allow practical and effective load balancing of services.
A Busy service can reduce its presence priority, while an idle service
can raise its priority. 

> Also, when would a client receive multiple pongs, if (AFAIK) only 
> one resource receives the ping.

If a server is configured to have multiple services [Service A, Service
B, Service C] the client will send an echo message to each of the
services (and get a response), and then perform Discovery to determine
which service supports the required features. If all the services
support the required feature, then it's up to the client to pick between

-- Quote --
4.2.3 Verifying the Service
Once a service instance has been found, it's necessary to disco the
service to 
verify it supports the correct features:
-- end quote --

> I understand this, but what I don't understand why the X-Data form is 
> built-in the disco reply. According to the subchapter name and 
> example name, the disco only does a verification.

It doesn't need to be in the reply, but it's there to make things
easier. It could just as easily be done using a custom infrastructure
(or via ad-hoc commands) once the target features have been verified. 

> I haven't seen this being done in ad-hoc commands for example. 
> From what I've noticed reading this XEP, this XMPP Service should be
> * a provider for a subset (=1 command) of Ad-hoc commands

I agree that most services that will use this mechanism will end up
using ad-hoc commands for doing anything meaningful. This XEP is simply
to facilitate finding an available service using a mechanism that's
suitable for horizontal scaling, load balancing, and high availability.
The scope of this XEP very focused in order to make sure we didn't get
bogged down in the remote command execution mechanism -  I don't want to
debate XML-RPC, Ad-Hoc Commands, SOAP, X-Data Forms, Object Spaces, or
any of the other mechanisms. This XEP is discovery only...

A service could easily add Ad-Hoc Commands to it's Disco Response:
	<feature var='http://jabber.org/protocol/commands'/>

> * a generalization of jabber:iq:register

We're managing this using an out-of-band mechanism. Users sign up and
pay for services using a web page. The Service(s) & the Web Page share a
database, so verification of users can be easily done. This lets us
leverage the web for the heavy lifting of sign-up, including "Are you
really human?", "Authorize your Credit Card", "Chose you're Up-Sells",
etc. I believe the web is a better platform for this than a custom XMPP
solution, and choosing the right tools is key to any job... 

Chris Mullins

More information about the Standards mailing list