Une application App Engine peut communiquer au moyen de messages instantanés avec tout service de messagerie instantanée compatible avec XMPP, tel que Google Talk. Une application peut envoyer et recevoir des messages de chat, envoyer des invitations à chatter et demander des informations sur la disponibilité des utilisateurs. Les messages XMPP entrants sont traités par des gestionnaires de requêtes, comme les requêtes Web.
Les utilisations possibles des messages instantanés comprennent les participants de chat automatisés ("chat bots" ou "robots de chat"), les notifications instantanées et les interfaces de chat des services. Un client riche disposant d'une connexion à un serveur XMPP (tel que Google Talk) peut utiliser XMPP pour interagir avec une application App Engine en temps réel, y compris recevoir des messages initiés par l'application. (Notez qu'un tel client utilisant Google Talk doit utiliser le mot de passe de l'utilisateur pour établir une connexion XMPP, et ne peut pas utiliser de cookie Google Accounts.)
À l'heure actuelle, une application ne peut pas participer à des chats en groupe. Une application peut uniquement recevoir des messages de type "chat" et "normal". Une application peut envoyer des messages appartenant à l'un des types définis dans la norme RFC 3921.
Une application peut envoyer des messages à une adresse XMPP quelconque en appelant l'API du service XMPP. Une application peut également utiliser l'API pour envoyer des invitations à chatter et interroger l'état d'un utilisateur (disponible pour chatter ou non disponible).
Un message de chat peut appartenir à l'un des cinq types définis dans la norme RFC 3921. Notez qu'une application peut uniquement recevoir des messages de type "chat" et "normal".
Le corps du message peut être constitué soit de texte brut visible par l'utilisateur, soit d'un bloc XML inclus dans les données XML XMPP. Vous pouvez utiliser les données des messages XML pour communiquer des données structurées à un client personnalisé.
L'exemple ci-dessous permet de tester la disponibilité d'un utilisateur et d'envoyer un message de chat.
import com.google.appengine.api.xmpp.JID;
import com.google.appengine.api.xmpp.Message;
import com.google.appengine.api.xmpp.MessageBuilder;
import com.google.appengine.api.xmpp.SendResponse;
import com.google.appengine.api.xmpp.XMPPService;
import com.google.appengine.api.xmpp.XMPPServiceFactory;
// ...
JID jid = new JID("[email protected]");
String msgBody = "Someone has sent you a gift on Example.com. To view: http://example.com/gifts/";
Message msg = new MessageBuilder()
.withRecipientJids(jid)
.withBody(msgBody)
.build();
boolean messageSent = false;
XMPPService xmpp = XMPPServiceFactory.getXMPPService();
if (xmpp.getPresence(jid).isAvailable()) {
SendResponse status = xmpp.sendMessage(msg);
messageSent = (status.getStatusMap().get(jid) == SendResponse.Status.SUCCESS);
}
if (!messageSent) {
// Send an email message instead...
}
Lorsqu'une application s'exécutant dans le serveur de développement envoie un message XMPP, les champs du message s'affichent sur la console et aucun message n'est envoyé. Le serveur de développement ne peut pas envoyer de messages XMPP pour le compte de l'application.
Les utilisateurs des services de chat compatibles avec XMPP peuvent envoyer des messages de chat aux applications App Engine. Pour qu'une application reçoive des messages de chat, le service de messagerie XMPP doit être activé dans la configuration de l'application.
Pour activer le service XMPP pour une application Java, ajoutez les lignes suivantes dans le fichier appengine-web.xml :
<inbound-services>
<service>xmpp_message</service>
</inbound-services>
Lorsqu'App Engine reçoit un message de chat pour l'application alors que le service XMPP est activé, il envoie une requête HTTP POST au chemin d'URL suivant :
/_ah/xmpp/message/chat/
Pour traiter les messages entrants, il vous suffit de créer un gestionnaire de requêtes qui accepte les requêtes POST à ce chemin d'URL.
Ce chemin d'URL est automatiquement réservé aux administrateurs de l'application. Le service XMPP se connecte à l'application avec le statut "administrateur" dans le but d'accéder à ce chemin d'URL. Si vous le souhaitez, vous pouvez configurer le chemin de sorte que cette restriction soit explicite, mais cela n'est pas nécessaire. Seul le service XMPP et les clients authentifiés comme administrateurs utilisant Google Accounts peuvent accéder à ce chemin d'URL.
Les données de requête POST représentent le message comme un message MIME comportant plusieurs parties (RFC 2388). Chaque partie correspond à un paramètre POST nommé :
from, l'adresse de l'expéditeur du messageto, l'adresse du destinataire, telle que décrite par l'expéditeur (voir ci-dessous)body, le corps du messagestanza, le message XMPP complet sous sa forme XML d'origineUne application peut recevoir des messages de deux types XMPP : "chat" et "normal". Si App Engine reçoit un message XMPP dont le type n'est pas pris en charge, le message est ignoré et le gestionnaire de requêtes n'est pas appelé.
L'API Servlet Java ne permet pas d'analyser directement les données POST MIME comportant plusieurs parties. L'API XMPP comporte une méthode helper permettant d'analyser ces données à partir de l'objet HttpServletRequest. L'exemple ci-dessous illustre l'utilisation de cette classe helper pour analyser les messages XMPP entrants.
import java.io.IOException;
import javax.servlet.http.*;
import com.google.appengine.api.xmpp.JID;
import com.google.appengine.api.xmpp.Message;
import com.google.appengine.api.xmpp.XMPPService;
import com.google.appengine.api.xmpp.XMPPServiceFactory;
@SuppressWarnings("serial")
public class XMPPReceiverServlet extends HttpServlet {
public void doPost(HttpServletRequest req, HttpServletResponse res)
throws IOException {
XMPPService xmpp = XMPPServiceFactory.getXMPPService();
Message message = xmpp.parseMessage(req);
JID fromJid = message.getFromJid();
String body = message.getBody();
// ...
}
}
Pour mapper ce servlet sur le chemin d'URL XMPP, placez la section suivante dans votre fichier web.xml, dans l'élément <web-app> :
<servlet>
<servlet-name>xmppreceiver</servlet-name>
<servlet-class>XMPPReceiverServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>xmppreceiver</servlet-name>
<url-pattern>/_ah/xmpp/message/chat/</url-pattern>
</servlet-mapping>
Une application peut envoyer et recevoir des messages en utilisant plusieurs types d'adresses Jabber. Un type d'adresse utilise l'identifiant de l'application et le domaine appspot.com, comme suit :
app-id@appspot.com
Une application peut également utiliser une adresse personnalisée au format suivant, où anything correspond à toute chaîne contenant des lettres, des chiffres et des tirets :
anything@app-id.appspotchat.com
(Vous remarquerez que le nom de domaine est différent pour les adresses personnalisées : appspotchat.com)
L'utilisation de domaines Google Apps dans les adresses XMPP n'est pas encore prise en charge pour les applications. Les utilisateurs qui possèdent des comptes Google sur votre domaine peuvent bien sûr continuer à utiliser ce domaine pour leurs adresses Google Talk.
L'application peut choisir quelle adresse utiliser en tant qu'adresse de l'expéditeur lorsqu'elle envoie un message. Tous les messages envoyés à toute adresse dans les formats pris en charge sont acheminés vers l'application.
L'adresse @appspot.com et les adresses @app-id.appspotchat.com font toutes référence à la version par défaut de l'application. Les messages envoyés à ces adresses sont acheminés vers la version par défaut. Lorsque la version par défaut d'une application envoie un message, l'adresse requise est utilisée comme expéditeur du message. Les réponses aux messages de l'application sont acheminées vers la version par défaut, même si la version par défaut a changé depuis que le message original a été envoyé.
Chacune des versions d'une application possède son propre ensemble d'adresses XMPP, au format suivant :
anything@version.latest.app-id.appspotchat.com
Si App Engine reçoit un message destiné à une adresse dans ce format, il est acheminé vers la version correspondante de l'application (si cette version existe toujours).
Si une version d'une application envoie un message et que cette version n'est pas la version par défaut, l'adresse de l'expéditeur du message est remplacée par une adresse dans ce format. Si l'expéditeur est app-id@appspot.com, l'adresse de l'expéditeur devient app-id@version.latest.app-id.appspotchat.com. Cela garantit que les réponses à un message envoyé par une version spécifique n'étant pas la version par défaut de l'application sont renvoyées vers cette version.
Une adresse XMPP, également appelée "adresse Jabber", est composée de plusieurs éléments : un nœud (tel que le nom d'un utilisateur d'un service de chat), un domaine (le nom de domaine du service) et une ressource facultative. Ces composants sont séparés par des signes de ponctuation : node@domain/resource
En général, lorsque vous établissez une conversation avec un utilisateur réel d'un service de chat, vous utilisez seulement les parties nœud et domaine de l'adresse Jabber. Il est possible que chaque client de chat que l'utilisateur a connecté au service possède sa propre ressource , un message envoyé à l'adresse Jabber sans cette ressource est donc transmis à tous les clients de l'utilisateur.
Une adresse Jabber sans ressource est appelée "adresse Jabber simple". Une adresse Jabber avec une ressource est une "adresse Jabber complète". Le service XMPP d'App Engine prend en charge à la fois les adresses Jabber simples et les adresses Jabber complètes pour les adresses des destinataires et des expéditeurs des messages.
Lors de l'envoi d'un message, si vous utilisez une adresse Jabber simple en tant qu'adresse de l'expéditeur, le service XMPP utilise automatiquement la ressource /bot. Si un autre utilisateur XMPP envoie un message à l'application en utilisant une adresse Jabber complète avec une ressource personnalisée, l'application peut voir quelle ressource a été utilisée en inspectant le champ to du message entrant.
Google Talk et les autres serveurs de chat acceptent uniquement les messages adressés aux utilisateurs "abonnés" auprès de l'expéditeur, soit parce que l'utilisateur a invité l'expéditeur à chatter, soit parce que l'utilisateur a accepté une invitation à chatter envoyée par l'expéditeur. Une application App Engine peut envoyer des invitations à chatter en utilisant l'API du service. Comme c'est le cas pour l'envoi d'e-mails, l'une des pratiques recommandées consiste à envoyer une invitation à chatter uniquement lorsque l'utilisateur le demande, en cliquant sur un bouton d'une page Web, par exemple. L'application peut également demander à l'utilisateur d'envoyer une invitation à l'adresse XMPP de l'application afin d'activer la réception des messages.
App Engine accepte automatiquement toutes les invitations à chatter, et ne communique pas les invitations à l'application. App Engine achemine tous les messages de chat vers l'application, que l'expéditeur ait précédemment envoyé une invitation à l'application ou non.
Si un utilisateur s'est "abonné" à une application (en acceptant une invitation ou en invitant l'application à chatter), l'application peut demander si un utilisateur de Google Talk possède un client de chat qui s'exécute à partir de l'API du service XMPP. L'application peut détecter deux valeurs d'état possibles : l'utilisateur est connecté, ou l'utilisateur n'est pas connecté. L'application ne peut pas déterminer l'état "absent", elle ne peut pas non plus déterminer le message d'état de l'utilisateur.
Une application peut uniquement interroger l'état des utilisateurs de Google Talk, et seulement de ceux qui se sont "abonnés" à l'application. Il n'existe aucun moyen pour un service XMPP d'interroger l'état des utilisateurs sur d'autres services XMPP.
App Engine indique un état connecté et disponible pour toutes les applications, que l'application soit compatible avec la réception de messages XMPP ou non. Il n'existe aucun moyen de définir un message d'état pour une application.
Chaque requête auprès du service XMPP est comptabilisée dans le quota XMPP API Calls (Appels vers l'API XMPP).
Chaque message de chat XMPP sortant est comptabilisé dans les quotas suivants :
Chaque invitation à chatter XMPP sortante est comptabilisée dans les quotas suivants :
Chaque message XMPP entrant est comptabilisé dans les quotas suivants :
Le calcul effectué dans un gestionnaire de requêtes pour les messages XMPP entrants relève des mêmes quotas que les requêtes Web et les tâches.
Pour plus d'informations sur les quotas, consultez la page Quotas, ainsi que la section "Détails relatifs aux quotas" de la Console d'administration.
En outre, les restrictions suivantes s'appliquent à l'utilisation du service XMPP :
| Restriction | Quantité |
|---|---|
| taille d'un message entrant | 100 Ko |
| taille d'un message sortant | 100 Ko |
Aucune restriction explicite ne s'applique au nombre de destinataires d'un message. Toutefois, chaque message est envoyé et mesuré séparément pour chaque destinataire. Un message adressé à 30 destinataires consomme 30 fois plus de ressources dans les quotas concernés qu'un message adressé à 1 destinataire. De plus, la taille totale de l'appel vers l'API est limitée à 1 Mo, liste des destinataires et corps du message inclus.