桥接到XMPP的最佳体系结构是什么？
如果我有一个单独的系统，并具有其自己的用户和状态概念，那么创建到XMPP服务器网络的桥接最合适的架构是什么？据我所知，主要有三种方法：桥接到XMPP的最佳体系结构是什么？
充当服务器。这会创建一个接触点，但我担心它会影响兼容性，并可能会在我的系统中模拟服务器时产生复杂性。
充当客户。这似乎意味着我需要在我的系统中为每个用户建立一个连接，这只是不能很好地扩展。
我听说过XMPP网关协议，但尚不清楚这是否比客户端解决方案更好。我也不知道这是否标准。
任何建议或权衡，将不胜感激。例如，这些解决方案是否需要在目标XMPP服务器内部运行代码（不太可能是我可以做的事情）。
您听说过的XMPP网关协议最可能与传输有关。传输是连接到XMPP服务器和非XMPP服务器的服务器。通过运行交通工具，我可以使用我的Jabber客户端与使用MSN Messenger的人交谈。
对于每个看起来像在线的JID，传输通常会连接一次到远程网络。也就是说，这是您的选项2的反向。这是因为传输和非XMPP网络之间没有特别的关系;交通工具只是一群普通的客户。为此，XMPP客户端必须先注册到传输设备，为远程网络提供登录凭据，并允许传输设备查看它们的存在。
这个可能扩展性更好的唯一原因是同一个远程网络可能有很多传输。例如，我的Jabber服务器可以运行一个传输到MSN，另一个Jabber服务器可以运行另一个，等等，每个服务器都为不同的XMPP用户子集提供连接。虽然这会在Jabber端扩展负载，并且系统上的负载平衡也可能分散负载，但它仍然需要两个系统之间的许多连接。在你的情况下，因为（我认为）事物的非XMPP方面正在合作，所以在非XMPP服务器上放置一个XMPP服务器接口可能是你最好的选择。该服务器接口最适合管理XMPP JID之间的映射以及该JID将如何显示在其自己的网络上，而不是强制XMPP用户注册等。
如果你还没有看到这些，你会发现它们非常有用：
- http://www.jabber.org/jabber-for-geeks/technology-overview
- http://www.xmpp.org/protocols/
- http://www.xmpp.org/extensions/
希望有所帮助。
我也在类似的系统上工作。
我正在与网关/组件路线。我已经看了几个选项，并与这一个解决。
网关是基本上具有桥接的Jabber/XMPP与另一网络的特定目的的成分。在使用XMPP作为客户端时，您将不得不构建您认为理所当然的大部分内容。东西像名册控制。
有一个组件的实际设计和建筑非常少的在线帮助。像上面的答案一样，我发现xmpp协议/扩展是有帮助的。其中主要有：
通过这些阅读会告诉你，你将有望能够处理什么XEPs。忽略将由您的组件将被处理的服务器处理的内容。
这是一个耻辱，Djabberd有这样差劲的文档作为自己的“一切都是一个模块”的一声服务器的后端的可能性可以直接连接到其他网络系统。我在这方面没有取得任何进展。其他
一种方法是用您的XMPP服务器供应商合作。大多数都有内部API，可以从第三方应用程序注入。例如，Jabber XCP为此提供了一个非常易于使用的API。
（披露：我对Jabber等公司，该公司背后的Jabber XCP工作）
基本上有两种类型的服务器的服务器（S2S）的连接。第一个要么称为网关，要么称为运输工具，但它们是一回事。这可能是你正在寻找的那种。我找不到非XMPP方面的具体文档，但XMPP认为如何翻译到旧版服务器的方式是http://xmpp.org/extensions/xep-0100.html。第二种类型在其他任何XEP中都没有解释 - 它是常规的XMPP s2s连接。在RFC 3920或RFC 3920bis中查找最新草案更新的“服务器到服务器通信”。
既然你有你的服务器上你自己的用户和存在，它不是XMPP，这些概念都不会完全映射到XMPP模型。这就是运输工作的地方。您必须从模型到XMPP模型进行翻译。虽然这是一些工作，但您确实可以做出所有决定。
这给我们带来正确的按键设计的选择之一 - 你需要真正决定你要去哪些东西从你的服务映射到XMPP，你是不是有什么。这些功能和用例描述将推动整体结构。例如，这就像一个交通工具可以与AOL或MSN聊天服务交谈吗？然后，您需要一种方法来映射其等值的名单，状态，并将会话信息以及本地用户的登录名和密码保存到远程服务器。这是因为您的交通工具需要伪装成这些用户，并且需要登录才能使用。
或者，也许你只是通向别人基于XMPP的国际象棋游戏的桥梁，所以你不需要在远程服务器上登录，并且可以采取与电子邮件服务器类似的行为，并将信息传回给向前。 （对于正常的s2s连接，唯一可以存储的会话将是与远程服务器一起使用的SASL认证，但在用户级别，s2s仅维护连接，而不是登录会话。）
其他因素包括可扩展性和模块化。你注意到了一些可扩展性问题。看看放在多个运输平衡负载。对于模块化，请参阅您想要决定如何处理每个数据包或操作的位置。例如，您如何处理和跟踪订阅数据？你可以把它放在你的运输工具上，但是这会使得使用多个运输工具变得更困难。或者，如果您将此决策更靠近核心服务器，则您可以使用更简单的传输方式，并在需要与XMPP以外的服务通信时使用一些通用代码。权衡是一个更复杂的核心服务器，具有更大的漏洞潜力。
您应该使用哪种体系结构取决于非XMPP系统。
您是否使用非XMPP系统？如果是，您应该找到一种方法将XMPP-S2S接口添加到该系统，换句话说，使其充当XMPP服务器。美国在线对AIM使用这种方法。不幸的是，他们限制了通往GoogleTalk的门户。
您不操作非XMPP系统，但它有一个联合接口，您可以使用-i。即您的网关可以与另一个系统作为服务器进行通信，并拥有自己的名称空间。在这种情况下，您可以构建一个充当联合服务器的网关。因为我不知道使用这种方法的网关的任何示例，但是如果要构建公共XMPP到SIP网桥，则可以使用它。
-
如果非XMPP系统不给你一个联邦接口，那么你没有别的选择，只能作为一群客户端。在XMPP世界中，这被称为“运输”。运输和正常的服务器之间的差别基本上是：
- 运输的JID的是从其他系统映射 - （如john.doe \ [email protected]真难看！）
- 希望使用传输的XMPP用户需要在非XMPP系统上创建帐户，并将该帐户的登录凭据提供给传输服务。 XMPP协议甚至有一个协议扩展，允许XMPP用户在带内进行传输注册。