将应用服务器与富/胖客户端一起使用是否值得？

Question

我知道在 Web 应用程序方面，应用程序服务器被大量使用。在这里，您有一个瘦客户端（浏览器）与应用程序服务器（如 tomcat 或 jboss）进行通信。

我现在仔细研究了一个商业软件，它也使用应用服务器和富/胖客户端。 （

我看不出有人将应用程序服务器与富客户端一起使用的好处。

解决方案 b 比解决方案 a 有什么好处？

a) 富客户端 在 jvm 中运行的简单服务器

b) 富客户端 运行在应用服务器上的服务器，例如 tomcat 或 jboss

谢谢

Answer 1

带有胖客户端的应用程序服务器提供的功能与带有 Web 应用程序的应用程序相同。如果应用服务器只对 webapps 有用，那么即使 webapps 也没有必要使用它们：一个简单的 Tomcat 或 Jetty 服务器就足够了。

完整的 Java EE 应用服务器的优点如下：

• 声明式事务管理
• 分布式事务（例如，跨多个数据库和/或一个数据库和一个 JMS 服务器）
• 声明式和程序式安全
• 线程池
• 并发处理
• JPA 对持久性的支持
• JMS 支持异步通信
• 资源管理（连接池等）
• 能够将会话 bean 公开为 Web 服务
• 依赖注入
• 等

无论用户界面是否基于网络，所有这些功能都很有用。如果您的应用程序没有使用所有这些功能，那么您不需要应用服务器。如果您不需要所有这些，并且更喜欢自己集成各种组件（事务管理器、JPA 引擎、JMS 服务器等），则可以只使用 Spring，无论是否使用 Tomcat 或 Jetty 等 Web 容器。

Answer 2

服务器有三个目的：

• 充当看门人并确保客户行为正常；
• 进行您不委托给客户的任何处理；和
• 提供各种类型的中心 - 一个保存相关数据的集中位置，并且客户可以在需要时会面以相互交流。

如果客户端自己做所有事情，并且不需要直接相互通信，那么你就不需要应用服务器。但是你拥有的用户越多，他们就越需要相互协调他们的行动。在某个特定于应用程序的点之后，客户践踏彼此工作的风险超过了去中心化模型的大部分好处。在这一点上，混合使用服务器更有意义。

如果您需要示例，请使用 Microsoft Access。我们可能会同意它是一个胖客户端数据库应用程序。它或多或少地直接修改数据库（无论如何，在 Jet/ACE 数据库的情况下），并且可以与其他进程共享一个数据库。但由于用户太多，尤其是通过网络访问共享数据库文件，损坏几乎迫在眉睫。但是，如果您引入 SQL Server 来处理数据库，并让 Access 完成 UI 工作并生成查询等，您将获得大部分相同的好处，而破坏数据库的风险要小得多。

关于独立服务器是否比 Tomcat 中的 Web 应用程序更好或更差，或者其他什么：在这些容器中的一个应用程序具有与在 Tomcat 中运行的 Web 应用程序相比独立 Java Web 应用程序所具有的大部分相同的好处。 ..您不必担心低级细节。您处理的是请求和响应，而不是套接字和数据包。此外，使用 HTTP 等已知的标准协议可以让其他软件（包括您自己的软件的新版本）更容易与您通信。但是，作为回报，您必须使应用程序的通信适应特定容器的工作方式。您是否可以或应该这样做完全取决于您。