使用 Openfire、Smack 和 Play 的聊天网站架构！框架答案

【问题标题】：Architecture for a chat website using Openfire, Smack and Play! Framework使用 Openfire、Smack 和 Play 的聊天网站架构！框架
【发布时间】：2012-09-15 08:30:05
【问题描述】：

我正在开发一个使用 Openfire XMPP 服务器的聊天网站，客户端使用 Smack API。使用 Smack API 的 Web 项目是使用 Play！使其成为 RESTful 的框架。我选择玩！因为它的异步编程产品（Comet Sockets/WebSockets）。

到目前为止，我的架构基本上如下所示：

Openfire 网络服务器用户/浏览器。

为了也支持 Android 设备并最大限度地重复使用代码，我是否应该将 XMPP 客户端代码实现为网站和 Android 客户端通用的 RESTful Web 服务？

Openfire Web 服务网站浏览器/用户。

Openfire Web 服务 Android 应用程序。

我害怕可伸缩性问题，因为引入了中间 Web 服务？由于必须通过多个组件，我是否会在通信中引入延迟？

任何关于上述内容的建议都会有所帮助。谢谢。

【问题讨论】：

标签： java web-services playframework openfire smack

【解决方案1】：

可扩展性的关键是解耦。因此，从本质上讲，您可以从“如果其中一个组件发生故障，其他组件是否会继续正常工作？”来考虑问题。除了避免世界末日场景之外，您还可以独立水平扩展每个组件。

考虑到这一点，现在让我们继续讨论您的特定用例。为层而建的层仍然让我对周围的一些 Java EE 架构感到噩梦。它不仅引入了不必要的延迟，而且还使查明问题变得更加困难。如果您的服务失败，是由 Web 服务器、Android 应用程序还是 Web 服务引起的？

如果您想重用代码，请重用代码而不是复制组件。这就是图书馆的用途。将您的通用代码提取为库，并在 Web 服务器和 Android 应用程序中使用它。

【讨论】：

【解决方案2】：

我认为最好制作一个轻量级的网页，该网页在加载后直接从浏览器中使用 Web 服务（就像任何应用程序一样）。

所以App和Webpage唯一的区别就是用户每次访问时，浏览器都会加载网页。

【讨论】：