使用Openfire，Smack和Play的聊天网站的架构！(Architecture for a chat website using Openfire, Smack and Play! Frame

使用Openfire，Smack和Play的聊天网站的架构！(Architecture for a chat website using Openfire, Smack and Play! Framework)

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

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

Openfire < - > Webserver < - >用户/浏览器。

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

Openfire < - > Webservice < - >网站< - >浏览器/用户。

Openfire < - > Webservice < - > Android App。

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

对上述任何建议都会有所帮助。 谢谢。

I am developing a chat website that makes use of the Openfire XMPP server, with the client side using Smack API. The web project that makes use of the Smack API is implemented using the Play! framework making it RESTful. I chose Play! because of its Asynchronous Programming offerings (Comet Sockets/WebSockets).

Basically, my architecture, so far, is like below:

Openfire <-> Webserver <-> User/Browser.

In order to support Android devices too, and to maximize code-reuse, should I implement the XMPP client side code as a RESTful webservice that is common for both the web site and the Android clients?

Openfire <-> Webservice <-> Website <-> Browser/User.

Openfire <-> Webservice <-> Android App.

I'm afraid of scalability issues, because of the introduction of an intermediate web service? Would I be introducing latency in the communication as a result of having to go through multiple components?

Any advice on the above would be helpful. Thanks.

最满意答案

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

考虑到这一点，现在让我们继续讨论您的具体用例。 层的层次仍然让我看到一些关于Java EE架构的噩梦。 它不仅会引入不必要的延迟，还会使查明问题变得更加困难。 如果您的服务失败，是由Web服务器，Android应用程序还是Web服务导致的失败？

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

The key to scalability is decoupling. So in an essence you can think of the problem in terms of "If one of the components fail, will the other components continue to work normally?". In addition to avoiding end of the world scenarios you can also independently scale horizontally each component.

With that in mind lets now move on to your specific use case. Layers for the sake of layers are what still make me see nightmares about some Java EE architectures around. Not only does it introduce unnecessary latency, it also makes it harder to pinpoint a problem. If your service fails, was the failure caused by the web server, android application or the web service?

If you want code reuse, reuse code instead of duplicating components. That`s what libraries are for. Take your common code and extract as a library and use it in both the web server and Android application.