Was ist die beste Architektur, um zu XMPP zu überbrücken?

Question

Wenn ich ein separates System mit einem eigenen Konzept von Benutzern und Anwesenheit habe, was ist die am besten geeignete Architektur für die Erstellung einer Brücke zu einem XMPP-Server-Netzwerk? Soweit ich sagen kann gibt es drei Hauptwege:

1. Als ein Server handeln. Dies erzeugt einen Berührungspunkt, aber ich befürchte, dass dies Auswirkungen auf die Kompatibilität hat und möglicherweise in meinem System zur Emulation eines Servers eine Komplexität erzeugt.

2. Als Kunde handeln. Dies scheint zu implizieren, dass ich eine Verbindung pro Benutzer in meinem System benötige, die einfach nicht gut skalieren wird.

3. Ich habe von einem XMPP-Gateway-Protokoll gehört, aber es ist unklar, ob dies besser als die Client-Lösung ist. Ich kann auch nicht sagen, ob das Standard ist oder nicht.

Alle Vorschläge oder Kompromisse würden geschätzt. Zum Beispiel würde irgendeine dieser Lösungen erfordern, Code innerhalb des Ziel-XMPP-Servers auszuführen (was ich wahrscheinlich nicht tun kann).

Answer 1

Das XMPP-Gateway-Protokoll, von dem Sie schon gehört haben, ist höchstwahrscheinlich mit Transporten zu tun. Ein Transport ist ein Server, der sowohl mit einem XMPP-Server als auch mit einem Nicht-XMPP-Server verbunden ist. Mit einem Transport kann ich meinen Jabber-Client verwenden, um mit jemandem zu sprechen, der beispielsweise MSN Messenger verwendet.

Ein Transport verbindet sich normalerweise einmal mit dem entfernten Netzwerk für jede JID, die er online sieht. Das heißt, es ist Ihre Option 2 in umgekehrter Reihenfolge. Dies liegt daran, dass zwischen dem Transport- und dem Nicht-XMPP-Netzwerk keine spezielle Beziehung besteht. Der Transport verhält sich einfach wie ein Haufen Stammkunden. Damit dies funktioniert, müssen XMPP-Clients sich zuerst bei dem Transport registrieren, Anmeldeinformationen für das Remotenetzwerk eingeben und dem Transport ermöglichen, ihre Anwesenheit anzuzeigen.

Der einzige Grund, warum dies eine bessere Skalierung ermöglicht, ist, dass es viele Transporte für das gleiche entfernte Netzwerk geben kann. Zum Beispiel könnte mein Jabber-Server einen Transport zu MSN ausführen, ein anderer Jabber-Server könnte einen anderen ausführen und so weiter, wobei jeder Verbindungen für eine andere Teilmenge von XMPP-Benutzern bereitstellt. Während dies die Last auf der Jabber-Seite ausbreitet und der Lastenausgleich auf Ihrem System die Last ebenfalls verteilen kann, sind immer noch viele Verbindungen zwischen den beiden Systemen erforderlich.

In Ihrem Fall, weil (ich nehme an) die Nicht-XMPP-Seite der Dinge zusammenarbeitet, ist eine XMPP-Server-Schnittstelle auf dem Nicht-XMPP-Server wahrscheinlich Ihre beste Wette. Diese Serverschnittstelle eignet sich am besten für die Verwaltung der Zuordnung zwischen XMPP-JIDs und wie diese JID in ihrem eigenen Netzwerk angezeigt wird, anstatt XMPP-Benutzer zur Registrierung zu zwingen und so weiter.

Falls Sie diese nicht gesehen haben, können Sie sie nützlich finden:

• http://www.jabber.org/jabber-for-geeks/technology-overview
• http://www.xmpp.org/protocols/
• http://www.xmpp.org/extensions/

Hoffnung, das hilft.

Answer 2

Ich arbeite auch an einem ähnlichen System.

Ich gehe mit der Gateway/Komponenten-Route. Ich habe mir verschiedene Möglichkeiten angeschaut und bin mit dieser übereingekommen.

Das Gateway ist im Grunde eine Komponente mit dem speziellen Zweck, Jabber/XMPP mit einem anderen Netzwerk zu verbinden. Sie müssen die meisten Dinge, die Sie als selbstverständlich betrachten, wenn Sie XMPP als Client verwenden. Dinge wie Dienstplankontrolle.

Es gibt sehr wenig Hilfe online auf dem tatsächlichen Entwurf und Aufbau einer Komponente. Wie bei der obigen Antwort habe ich festgestellt, dass die xmpp-Protokolle/-Erweiterungen hilfreich sein können. Die wichtigsten sind:

• Basic Client 2008
• Basic Server 2008
• Intermediate Client 2008
• Intermediate Server 2008

durch diese Lese wird Ihnen zeigen, was XEPs werden Sie zu handhaben zu können erwartet werden. Ignoriere die Dinge, die von dem Server gehandhabt werden, an den deine Komponente gebunden ist.

Es ist eine Schande, dass Djabberd hat so schlechte Dokumentation als ihr System von "alles ist ein Modul" gab die Möglichkeit, Back-End des Servers direkt mit dem anderen Netzwerk-Schnittstelle. Ich bin damit nicht vorangekommen.

Answer 3

Ein anderer Ansatz besteht darin, mit Ihrem XMPP-Server-Anbieter zusammenzuarbeiten. Die meisten verfügen über interne APIs, die das Präsentieren von Anwesenheit aus Anwendungen von Drittanbietern ermöglichen. Zum Beispiel bietet Jabber XCP eine API, die wirklich einfach zu benutzen ist.

(Disclosure: Ich arbeite für Jabber, Inc., das Unternehmen hinter Jabber XCP)

Answer 4

Es gibt grundsätzlich zwei Arten von Server zu Server (S2S) Verbindungen. Die erste wird entweder Gateway oder Transport genannt, aber sie sind dasselbe. Das ist wahrscheinlich die Art, nach der Sie suchen. Ich konnte keine spezifische Dokumentation für die Nicht-XMPP-Seite finden, aber wie XMPP darüber nachdenkt, Übersetzungen zu Legacy-Servern durchzuführen, ist unter http://xmpp.org/extensions/xep-0100.html. Die zweite Art wird wirklich nicht in irgendwelchen zusätzlichen XEPs erklärt - es sind normale XMPP s2s Verbindungen. Suchen Sie nach "Server-zu-Server-Kommunikation" in RFC 3920 oder RFC 3920bis für das neueste Entwurfsupdate.

Da Sie Ihre eigenen Benutzer und Präsenz auf Ihrem Server haben und es nicht XMPP ist, werden die Konzepte nicht vollständig auf das XMPP-Modell abgebildet. Hier kommt die Arbeit des Transports ins Spiel. Sie müssen die Übersetzung von Ihrem Modell zum XMPP-Modell durchführen. Während dies etwas Arbeit ist, musst du alle Entscheidungen treffen.

Das bringt uns direkt zu einer der wichtigsten Design-Entscheidungen - Sie müssen wirklich entscheiden, welche Dinge Sie XMPP von Ihrem Service zuordnen und was Sie nicht sind. Diese Merkmale und Anwendungsfälle werden die Gesamtstruktur bestimmen. Zum Beispiel, ist das wie ein Transport, um mit AOL oder MSN Chat-Diensten zu sprechen? Dann benötigen Sie eine Möglichkeit, das Äquivalent von Anwesenheitslisten zu protokollieren und Sitzungsinformationen zusammen mit Benutzernamen und Kennwörtern von Ihren lokalen Benutzern zum Remote-Server zu speichern. Dies liegt daran, dass Ihr Transport sich als diese Benutzer ausgeben muss und sich für sie anmelden muss.

Oder vielleicht bist du nur eine s2s-Brücke zu einem anderen XMPP-basierten Schachspiel, also brauchst du keine Anmeldung auf dem Remote-Server und kannst genauso wie ein E-Mail-Server agieren und die Informationen zurück und weitergeben her. (Bei normalen s2s-Verbindungen wäre die einzige Sitzung, die gespeichert werden würde, die SASL-Authentifizierung, die mit dem Remote-Server verwendet wird, aber auf der Benutzerebene behält s2s nur die Verbindung und nicht die Anmeldesitzung bei.)

Andere Faktoren sind Skalierbarkeit und Modularität an Ihrem Ende. Sie haben einige Bedenken hinsichtlich der Skalierbarkeit geäußert. Werfen Sie einen Blick auf mehrere Transporte, um die Last auszugleichen. Sehen Sie anhand der Modularität, wo Sie entscheiden möchten, was mit den einzelnen Paketen oder Aktionen geschehen soll. Zum Beispiel, wie behandeln und verfolgen Sie Abonnementdaten? Sie können es auf Ihren Transport setzen, aber das macht die Verwendung mehrerer Transporte schwieriger. Oder, wenn Sie diese Entscheidung näher an Ihrem Hauptserver treffen, können Sie einfachere Transporte durchführen und einen gemeinsamen Code verwenden, wenn Sie mit anderen Diensten als XMPP sprechen müssen. Der Trade-Off ist ein komplexerer Core-Server mit mehr Schwachstellen.

Answer 5

Welche Architektur Sie verwenden sollten, hängt vom Nicht-XMPP-System ab.

1. Betreiben Sie das Nicht-XMPP-System? Wenn ja, sollten Sie eine Möglichkeit finden, eine XMPP-S2S-Schnittstelle zu diesem System hinzuzufügen, also als XMPP-Server fungieren. AOL verwendet diesen Ansatz für AIM. Leider haben sie ihr Gateway auf GoogleTalk beschränkt.

2. Sie betreiben das Nicht-XMPP-System nicht, aber es verfügt über eine Verbundschnittstelle, die Sie verwenden können - i. e. Ihr Gateway kann mit dem anderen System als Server sprechen und hat einen eigenen Namensraum. In diesem Fall können Sie ein Gateway erstellen, das auf beiden Seiten als Server mit föderierten Datenbanken fungiert. Ich kenne kein Beispiel für ein Gateway, das diesen Ansatz verwendet, aber Sie könnten es verwenden, wenn Sie eine öffentliche XMPP-zu-SIP-Bridge erstellen möchten.

3. Wenn das Nicht-XMPP-System keine Föderationsschnittstelle bietet, haben Sie keine andere Möglichkeit, als eine Gruppe von Clients zu agieren. In der XMPP-Welt wird dies als "Transport" bezeichnet. Die Unterschiede zwischen einem Transport und einem normalen Server sind im Grunde:

   • die JIDs des Transports werden von einem anderen System abgebildet -
   (zB john.doe \ 40example.net@msngateway.example.org wirklich hässlich!)
   • XMPP-Benutzer, die den Transport verwenden möchten, müssen ein Konto auf dem Nicht-XMPP-System erstellen und dem Transportdienst die Anmeldeinformationen dieses Kontos mitteilen. Das XMPP-Protokoll verfügt sogar über eine Protokollerweiterung, mit der XMPP-Benutzer Transportregistrierungen im Band durchführen können.