桥接到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协议/扩展名很有帮助。主要的是：
- 基本客户2008
- 基本服务器2008
- 中级客户2008
- 中间服务器2008
通读这些内容将为我们显示预期将能够处理的XEP。忽略将要添加组件的服务器处理的内容。
遗憾的是，Djabberd的文档如此差劲，因为他们的"一切都是模块"系统使服务器后端可以直接与其他网络接口。我对此没有任何进展。
回答
另一种方法是与XMPP服务器供应商合作。大多数都具有内部API，这些API使从第三方应用程序注入状态成为可能。例如，Jabber XCP为此提供了一个非常易于使用的API。
(披露：我为Jabber XCP背后的公司Jabber，Inc.工作)
回答
服务器到服务器(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桥梁，因此我们不需要在远程服务器上登录，而可以像电子邮件服务器一样操作并来回传递信息。 (对于普通的s2s连接，唯一要存储的会话将是与远程服务器一起使用的SASL身份验证，但是在用户级别s2s只是保持连接，而不是登录会话。)
其他因素是我们端的可伸缩性和模块化。我们钉住了一些可伸缩性问题。看一下放置多个运输工具以平衡负载。对于模块化，请参见要在哪里决定如何处理每个数据包或者每个操作。例如，我们如何处理和跟踪订阅数据？我们可以将其放在运输工具上，但这会使使用多种运输工具更加困难。或者，如果我们更接近核心服务器做出此决定，则在需要与XMPP以外的服务进行对话时，可以采用更简单的传输方式并使用一些通用代码。权衡是更复杂的核心服务器，它具有更大的潜在漏洞。
