I am going with the gateway/component route. I have looked at several options and settled with this one.
The gateway is basically a component with the specific purpose of bridging Jabber/XMPP with another network. You will have to build most of the things you take for granted when using XMPP as a client. Stuff like roster control.
There is very little help online on the actual design and building of a component. Like the above answer I found that the xmpp protocols/extensions to be of help. The main ones being:
Reading through these will show you what XEPs you will be expected to be able to handle. Ignore the stuff that will be handled by the server that your component will be attched to.
It's a shame that Djabberd has such poor documentation as their system of "everything is a module" gave the possibility of backend of the server could interface directly to the other network. I made no headway on this.
There are basically two types of server to server (s2s) connections. The first is either called a gateway or a transport, but they're the same thing. This is probably the kind you're looking for. I couldn't find specific documentation for the non-XMPP side, but how XMPP thinks about doing translations to legacy servers is at http://xmpp.org/extensions/xep-0100.html. The second kind really isn't explained in any additional XEPs -- it's regular XMPP s2s connections. Look for "Server-to-Server Communication" in RFC 3920 or RFC 3920bis for the latest draft update.
Since you have your own users and presence on your server, and it's not XMPP, the concepts aren't going to map completely to the XMPP model. This is where the work of the transport comes in. You have to do the translation from your model to the XMPP model. While this is some work, you do get to make all the decisions.
Which brings us right to one of the key design choices -- you need to really decide which things you are going to map to XMPP from your service and what you aren't. These feature and use case descriptions will drive the overall structure. For example, is this like a transport to talk to AOL or MSN chat services? Then you'll need a way to map their equivalent of rosters, presence, and keep session information along with logins and passwords from your local users to the remote server. This is because your transport will need to pretend to be those users and will need to login for them.
Or, maybe you're just an s2s bridge to someone else's XMPP based chess game, so you don't need a login on the remote server, and can just act similarly to an email server and pass the information back and forth. (With normal s2s connections the only session that would be stored would be SASL authentication used with the remote server, but at the user level s2s just maintains the connection, and not the login session.)
Other factors are scalability and modularity on your end. You nailed some of the scalability concerns. Take a look at putting in multiple transports to balance the load. For modularity, see where you want to make decisions about what to do with each packet or action. For example, how do you handle and keep track of subscription data? You can put it on your transport, but then that makes using multiple transports harder. Or if you make that decision closer to your core server you can have simpler transports and use some common code if you need to talk to services other than XMPP. The trade off is a more complex core server with more vulnerability potential.
One other approach is to work with your XMPP server vendor. Most have internal APIs that make injecting presence possible from third party applications. For example, Jabber XCP provides an API for this that's really easy to use.
(Disclosure: I work for Jabber, Inc, the company behind Jabber XCP)
What architecture you should use depends on the non-XMPP system.
Do you operate the non-XMPP system? If yes, you should find a way to add an XMPP-S2S interface to that system, in other words, make it act as an XMPP server. AOL is using this approach for AIM. Unfortunately, they have restricted their gateway to GoogleTalk.
You don't operate the non-XMPP system but it has a federation interface that you can use - i. e. your gateway can talk to the other system as a server and has a namespace of its own. In this case, you can build a gateway that acts as a federated server on both sides. For I don't know of any example of a gateway that uses this approach but you could use it if you want to build a public XMPP-to-SIP bridge.
If the non-XMPP system doesn't give you a federation interface, then you have no other option but acting as a bunch of clients. In the XMPP world, this is called a "transport". The differences between a transport and a normal server are basically:
the JIDs of the transport are mapped from another system (e.g. john.doe\[email protected] - really ugly!)
XMPP users who want to use the transport need to create an account on the non-XMPP system and give the login credentials of that account to the transport service. The XMPP protocol even has a protocol extension that allows XMPP users to do transport registrations in-band.
The XMPP gateway protocol you've heard of is most likely to do with transports. A transport is a server that connects to both a XMPP server and a non-XMPP server. By running a transport, I can use my Jabber client to talk to someone using, say, MSN Messenger.
A transport typically connects once to the remote network for each JID that it sees as online. That is, it's your option 2 in reverse. This is because there is no special relationship between the transport and the non-XMPP network; the transport is simply acting as a bunch of regular clients. For this to work, XMPP clients must first register with the transport, giving login credentials for the remote network, and allowing the transport to view their presence.
The only reason this has a chance of scaling better is that there can be many transports for the same remote network. For example, my Jabber server could run a transport to MSN, another Jabber server could run another one, and so on, each one providing connections for a different subset of XMPP users. While this spreads out the load on the Jabber side, and load balancing on your system may spread out the load as well, it still requires many connections between the two systems.
In your case, because (I assume) the non-XMPP side of things is cooperating, putting a XMPP server interface on the non-XMPP server is likely your best bet. That server interface is best suited for managing the mapping between XMPP JIDs and how that JID will appear on its own network, rather than forcing XMPP users to register and so on.
In case you haven't seen these, you might find them useful:
发布评论
评论（5）
我也在开发类似的系统。
我将使用网关/组件路线。 我研究了几种选择并最终选择了这个。
网关基本上是一个组件，其特定目的是将 Jabber/XMPP 与另一个网络桥接。 当使用 XMPP 作为客户端时，您将必须构建大部分您认为理所当然的东西。 像名册控制之类的东西。
关于组件的实际设计和构建的在线帮助非常少。 就像上面的答案一样，我发现 xmpp 协议/扩展很有帮助。 主要有：
阅读这些内容将向您展示您预计能够处理哪些 XEP。 忽略您的组件将附加到的服务器将处理的内容。
遗憾的是，Djabberd 的文档如此糟糕，因为他们的“一切都是模块”系统使服务器后端可以直接连接到其他网络。 我在这方面没有取得任何进展。
I too am working on a similar system.
I am going with the gateway/component route. I have looked at several options and settled with this one.
The gateway is basically a component with the specific purpose of bridging Jabber/XMPP with another network. You will have to build most of the things you take for granted when using XMPP as a client. Stuff like roster control.
There is very little help online on the actual design and building of a component. Like the above answer I found that the xmpp protocols/extensions to be of help. The main ones being:
Reading through these will show you what XEPs you will be expected to be able to handle. Ignore the stuff that will be handled by the server that your component will be attched to.
It's a shame that Djabberd has such poor documentation as their system of "everything is a module" gave the possibility of backend of the server could interface directly to the other network. I made no headway on this.
服务器到服务器 (s2) 连接基本上有两种类型。 第一个称为网关或传输，但它们是同一件事。 这可能就是您正在寻找的类型。 我找不到非 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 以外的服务进行通信，则可以使用更简单的传输并使用一些通用代码。 代价是核心服务器更加复杂，潜在的漏洞也更多。
There are basically two types of server to server (s2s) connections. The first is either called a gateway or a transport, but they're the same thing. This is probably the kind you're looking for. I couldn't find specific documentation for the non-XMPP side, but how XMPP thinks about doing translations to legacy servers is at http://xmpp.org/extensions/xep-0100.html. The second kind really isn't explained in any additional XEPs -- it's regular XMPP s2s connections. Look for "Server-to-Server Communication" in RFC 3920 or RFC 3920bis for the latest draft update.
Since you have your own users and presence on your server, and it's not XMPP, the concepts aren't going to map completely to the XMPP model. This is where the work of the transport comes in. You have to do the translation from your model to the XMPP model. While this is some work, you do get to make all the decisions.
Which brings us right to one of the key design choices -- you need to really decide which things you are going to map to XMPP from your service and what you aren't. These feature and use case descriptions will drive the overall structure. For example, is this like a transport to talk to AOL or MSN chat services? Then you'll need a way to map their equivalent of rosters, presence, and keep session information along with logins and passwords from your local users to the remote server. This is because your transport will need to pretend to be those users and will need to login for them.
Or, maybe you're just an s2s bridge to someone else's XMPP based chess game, so you don't need a login on the remote server, and can just act similarly to an email server and pass the information back and forth. (With normal s2s connections the only session that would be stored would be SASL authentication used with the remote server, but at the user level s2s just maintains the connection, and not the login session.)
Other factors are scalability and modularity on your end. You nailed some of the scalability concerns. Take a look at putting in multiple transports to balance the load. For modularity, see where you want to make decisions about what to do with each packet or action. For example, how do you handle and keep track of subscription data? You can put it on your transport, but then that makes using multiple transports harder. Or if you make that decision closer to your core server you can have simpler transports and use some common code if you need to talk to services other than XMPP. The trade off is a more complex core server with more vulnerability potential.
另一种方法是与 XMPP 服务器供应商合作。 大多数都有内部 API，可以从第三方应用程序进行注入。 例如，Jabber XCP 为此提供了一个非常易于使用的 API。
（披露：我在 Jabber, Inc 工作，该公司是 Jabber XCP 背后的公司）
One other approach is to work with your XMPP server vendor. Most have internal APIs that make injecting presence possible from third party applications. For example, Jabber XCP provides an API for this that's really easy to use.
(Disclosure: I work for Jabber, Inc, the company behind Jabber XCP)
您应该使用什么架构取决于非 XMPP 系统。
您是否运行非 XMPP 系统？ 如果是，您应该找到一种方法向该系统添加 XMPP-S2S 接口，换句话说，使其充当 XMPP 服务器。 AOL 正在将这种方法用于 AIM。 不幸的是，他们限制了 GoogleTalk 的网关。
您不操作非 XMPP 系统，但它有一个您可以使用的联合接口 - 即您的网关可以作为服务器与其他系统通信，并拥有自己的命名空间。 在这种情况下，您可以构建一个网关，充当两侧的联合服务器。 因为我不知道有任何使用此方法的网关示例，但如果您想构建公共 XMPP 到 SIP 网桥，则可以使用它。
如果非 XMPP 系统没有为您提供联合接口，那么您除了充当一群客户端之外别无选择。 在 XMPP 世界中，这称为“传输”。 传输服务器和普通服务器之间的区别基本上是：
What architecture you should use depends on the non-XMPP system.
Do you operate the non-XMPP system? If yes, you should find a way to add an XMPP-S2S interface to that system, in other words, make it act as an XMPP server. AOL is using this approach for AIM. Unfortunately, they have restricted their gateway to GoogleTalk.
You don't operate the non-XMPP system but it has a federation interface that you can use - i. e. your gateway can talk to the other system as a server and has a namespace of its own. In this case, you can build a gateway that acts as a federated server on both sides. For I don't know of any example of a gateway that uses this approach but you could use it if you want to build a public XMPP-to-SIP bridge.
If the non-XMPP system doesn't give you a federation interface, then you have no other option but acting as a bunch of clients. In the XMPP world, this is called a "transport". The differences between a transport and a normal server are basically:
您听说过的 XMPP 网关协议很可能与传输有关。 传输是连接到 XMPP 服务器和非 XMPP 服务器的服务器。 通过运行传输，我可以使用 Jabber 客户端与使用 MSN Messenger 等工具的人交谈。
传输通常会为它认为在线的每个 JID 连接一次到远程网络。 也就是说，它是你的选项2的相反。 这是因为传输和非XMPP网络之间没有特殊的关系； 运输只是充当一群常客。 为此，XMPP 客户端必须首先向传输注册，提供远程网络的登录凭据，并允许传输查看其存在。
这有可能更好地扩展的唯一原因是同一远程网络可以有许多传输。 例如，我的 Jabber 服务器可以运行到 MSN 的传输，另一台 Jabber 服务器可以运行另一个，依此类推，每个服务器都为不同的 XMPP 用户子集提供连接。 虽然这会分散 Jabber 端的负载，并且系统上的负载平衡也可能会分散负载，但两个系统之间仍然需要许多连接。
就您而言，因为（我假设）非 XMPP 方面正在合作，所以将 XMPP 服务器接口放在非 XMPP 服务器上可能是您的最佳选择。 该服务器接口最适合管理 XMPP JID 之间的映射以及 JID 在其自己的网络上的显示方式，而不是强制 XMPP 用户注册等。
如果您还没有看到这些，您可能会发现它们很有用：
希望有帮助。
The XMPP gateway protocol you've heard of is most likely to do with transports. A transport is a server that connects to both a XMPP server and a non-XMPP server. By running a transport, I can use my Jabber client to talk to someone using, say, MSN Messenger.
A transport typically connects once to the remote network for each JID that it sees as online. That is, it's your option 2 in reverse. This is because there is no special relationship between the transport and the non-XMPP network; the transport is simply acting as a bunch of regular clients. For this to work, XMPP clients must first register with the transport, giving login credentials for the remote network, and allowing the transport to view their presence.
The only reason this has a chance of scaling better is that there can be many transports for the same remote network. For example, my Jabber server could run a transport to MSN, another Jabber server could run another one, and so on, each one providing connections for a different subset of XMPP users. While this spreads out the load on the Jabber side, and load balancing on your system may spread out the load as well, it still requires many connections between the two systems.
In your case, because (I assume) the non-XMPP side of things is cooperating, putting a XMPP server interface on the non-XMPP server is likely your best bet. That server interface is best suited for managing the mapping between XMPP JIDs and how that JID will appear on its own network, rather than forcing XMPP users to register and so on.
In case you haven't seen these, you might find them useful:
Hope that helps.