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

Question

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

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

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

解决方案b对解决方案有什么好处？

a）富客户端＆lt; - ＆gt;在jvm中运行的简单服务器

b）富客户端＆lt; - ＆gt;服务器在应用服务器上运行，如tomcat或jboss

由于

Answer 1

具有胖客户端的应用程序服务器提供与具有Web应用程序的应用程序相同的功能。如果应用程序服务器仅对Web应用程序有用，那么即使对于webapps也没有意义：使用简单的Tomcat或Jetty服务器就足够了。

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

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

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

Answer 2

服务器有三个目的：

• 充当守门人并确保客户表现得非常理智;
• 进行任何不委托给客户的处理;和
• 提供各种各样的中心 - 保存相关数据的集中位置，以及客户可以在必要时相互通信的地方。

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

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

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