XEP-xxxx: Discovery and Integration of XMPP Services

This XEP defines a mechanism for Services (in the SOA sense) to exist on the XMPP Network. This includes client discovery, load balancing and redundancy across multiple instances of the Service.


WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.


Document Information

Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.0.1
Last Updated: 2007-03-17
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0030
Supersedes: None
Superseded By: None
Short Name: SOA Discovery
Wiki Page: <http://wiki.jabber.org/index.php/Discovery and Integration of XMPP Services (XEP-xxxx)>

Author Information

Chris Mullins

Email: chris.mullins@coversant.com

JD Conley

Email: jconley@coversant.net

Legal Notice

This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy <http://www.xmpp.org/extensions/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Table of Contents


1. Introduction
2. Glossary
3. Requirements
4. Use Cases
    4.1. Service Comes Online
    4.2. Client Discovers a Services
       4.2.1. Discovering a Service Provider On a Server
       4.2.2. Finding a Concrete Service
       4.2.3. Verifying the Service
       4.2.4. Tracking the Service
5. Implementation Notes
6. Internationalization Considerations
7. Security Considerations
8. IANA Considerations
Notes
Revision History


1. Introduction

Specialized Services that run on the XMPP network are becomming increasingly common. As these services are deployed on a large scale or with Service Level Agreements, it's important to have a mechanism for load balancing, redundancy, and dynamic discovery.

Services have no dependency upon internal server knowledge. They're intended to provide specialized services such as language translation, customer billing, large scale algorithmic processing, or other standalone tasks. Services should be easy to create, and should have no dependencies upon the internal working of any particular XMPP Server. Services should be able to run in a geographically distributed manner.

To meet these goals, Services are built as XMPP clients. Presence, and specifically priorities, are used by Services to announce their ability to do work in near real time.

This XEP makes no attempt to define what a Service is, or how it interacts with clients or other Services. This XEP simply defines how to use dynamic Service Discovery. This XEP is analogous to UDDI in the Web Services world - it provides discovery only.

2. Glossary

Table 1: Glossary

Term Definition
Service This is an entity on the federated XMPP network that has the ability to do work. A Service fits the generally accepted definition of a Service as defined by a Service Oriented Architecture.
Load Balancing The ability of the server, based on presence priority, to choose which of many identical Services a particular work item is routed to. This allows an arbitrary amount of work to be done simply by logging in more Services and having them announce presence.
Redundancy The ability of a Service to unexpectedly go offline without affecting overall processing on the XMPP network. Requests are routed to other, available, resources with no signifigant interruption of services.

3. Requirements

The protocol defined herein addresses the following requirements:

  1. Enable an arbitrary number of identical Services to make themselves available.

  2. Enable a client to use the Server to discover an instance of the Service that's available for use.

  3. Enable mechanism by which a client can (optionally) determine if a Service has gone offline.

4. Use Cases

The following use cases show the behavior required between a client and a Service

4.1 Service Comes Online

A service comes online and logs into a pre-determined XMPP Server. This case follows standard XMPP login semantics.

4.2 Client Discovers a Services

A server that plans to offer support for a particular service needs to be configured for the service via a static discovery mechanism. Future versions of this XEP may descibe a dynamic mechanism based on something similar to client capabilities, but for now, this is a static discovery mechanism.

4.2.1 Discovering a Service Provider On a Server

When connected to a server, a client can locate services that provide the desired features through Discovery. When the client finds a Discovery item that is in a Bare JID form, the echo message mechanism described below is used.

Example 1. Entity sends discovery request to server

					
<iq to="demo.soapbox.net" id="disco1" type="get">
	<query xmlns="http://jabber.org/protocol/disco#items" />
</iq>      
				

Example 2. Server returns items, including translation providers

					
 <iq to="user@demo.soapbox.net/SoapBox" from="demo.soapbox.net" id="disco1" type="result">
	<query xmlns="http://jabber.org/protocol/disco#items">
	    ...
		<item jid="translator@demo.soapbox.net" name="SoapBox Interpreter and Translation Service" />
		...
	</query>
</iq>
      
				

4.2.2 Finding a Concrete Service

Once a bare JID for a particular service has been established via discovery, an Echo message is sent to the bare JID of the Service. To facilitate request tracking an id attribute MUST be specified on the message "ping" sent by the 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 further query.

Example 3. Entity sends Echo message to Service

					
<message to="translator@demo.soapbox.net" id="message1">
	<x xmlns="http://coversant.net/protocol/echomessage">
		<ping />
	</x>
</message>      
				

Example 4. The most available service instance responds

					
<message to="user@demo.soapbox.net/SoapBox" xml:lang="en-us" id="message1" from="translator@demo.soapbox.net/one" type="normal">
	<x xmlns="http://coversant.net/protocol/echomessage">
		<pong />
	</x>
</message>      
				

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:

Example 5. Entity queries service for further information

					
<iq to="translator@demo.soapbox.net/one" id="disco2" type="get">
	<query xmlns="http://jabber.org/protocol/disco#info" />
</iq>
      
				

Example 6. Service replies with details

					
<iq to="user@demo.soapbox.net/SoapBox" from="translator@demo.soapbox.net/one" id="disco2" type="result">
	<query xmlns="http://jabber.org/protocol/disco#info">
		<feature var="http://jabber.org/protocol/langtrans" />
		<identity category="automation" type="translation" />
		<x type="form" xmlns="jabber:x:data">
			<instructions>Please fill out the Form</instructions>
			<title>Translation Request Form</title>
			<field var="FORM_TYPE" type="hidden">
				<value>http://coversant.net/protocol/translationform</value>
			</field>
			...
			<field var="accesscode" type="text-single" label="Access Code">
				<desc>Access Code For Billing</desc>
				<required />
			</field>
		</x>
	</query>
</iq>
      
				

Note that the discovery response may have a large amount of X-Data or other Service specific items. In the Translation example shown above, many fields may be present, such as the language pairs offered for translation, the costs associated with translation, or any other requirements of the service.

Note also that the Discovery process may involve the xml:lang tag, so that data fields returned to the client are localized in the requesting user's language.

4.2.4 Tracking the Service

If the service needs to be notified when the client becomes unavailable, the client SHOULD send a directed presence stanza to the Full JID of the discovered Service. If the client needs to be notified when the service becomes unavailable the service SHOULD send its directed presence to the client. When the client no longer needs services provided by the Service it SHOULD send a directed presence stanza of type unavailable to the service. The service SHOULD then respond with its own unavailable stanza. Using presence in this way allows the appropriate endpoints to be notified by the server if the service or client go offline for an unexpected reason without the unnecessary state management overhead of Multi-User Chat or Roster subscriptions.

Example 7. Client directs available presence to the service

					
<presence to="translator@demo.soapbox.net/one" />

				

Example 8. Service directs available presence to the client

					
<presence to="user@demo.soapbox.net/SoapBox" />

				

5. Implementation Notes

Services have a signifigant amount of discression in their interaction with clients. The Echo Message infrastructure assures that the message will always be sent to the service that has the highest presence priority. A Service can, based on internal business rules, adjust it's presence priorty to affect its ability to be discovered by a client.

In many cases, Services will be tied to other services and dependencies will exist. This is addressed using Presence Subscriptions so that services are notified when their dependencies go online or offline.

For example, in Coversant's Language Translation implementation, human Interpreters all have the Translation Service in their roster, so that they immediately know if an instance of the service goes online or offline, and (conversly) the service knows if an Interpreter goes online or offline. The service itself maintains these roster subscriptions and has a full database behind it to track interpreters, billing information, and numerous other things.

6. Internationalization Considerations

7. Security Considerations

8. IANA Considerations

This XEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [1].


Notes

1. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.


Revision History

Version 0.0.1 (2007-03-17)

First draft.

(CLM)

END