0

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

我现在仔细研究了一个商业软件，它也使用了一个应用服务器和一个富/胖客户端。（<100 个用户）这里的富客户端与运行在应用服务器上的服务器软件进行通信（例如，tomcat、jboss，...）

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

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

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

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

谢谢

4

2 回答 2

1

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

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

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

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

于 2012-01-07T18:54:57.043 回答
0

服务器将具有三个目的：

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

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

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

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

于 2012-01-07T17:02:04.720 回答