与富/胖客户端一起使用应用程序服务器值得吗？

Question

我知道，当涉及到web应用程序时，应用服务器被大量使用。在这里，您有一个瘦客户机(浏览器)与像tomcat或jboss这样的应用程序服务器进行通信。

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

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

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

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

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

谢谢

Answer 1

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

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

声明性事务management

• distributed事务(跨多个数据库和/或一个数据库和一个JMS服务器)，用于example)

• declarative和编程security

• thread pooling

• concurrency处理

• JPA，支持对异步communications

• resources管理的persistence

• JMS支持(连接池，将会话bean公开为web services

• dependency injection

• etc.

)

无论用户界面是否基于web，所有这些特性都是有用的。如果您的应用程序没有使用所有这些功能，那么您就不需要应用服务器。如果您不需要所有这些，并且更喜欢集成各种组件(事务管理器、JPA引擎、JMS服务器等)您可以使用Spring，也可以使用Tomcat或Jetty这样的web容器。

Answer 2

服务器有三个目的：

• 扮演看门人的角色，确保客户行为正常；
• 负责做您不委托给客户的任何处理；
• 提供各种枢纽--一个保存相关数据的集中式场所，并在需要时客户可以在那里见面进行通信。

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

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

至于一个独立的服务器是否比Tomcat中的web应用程序更好还是更糟糕，在其中一个容器中的应用程序具有与运行在Tomcat中的web应用程序相对于独立的Java app...you没有那么多的低级别细节所具有的最大好处。您处理的是请求和响应，而不是套接字和数据包。此外，使用已知的标准协议(如HTTP )可以使其他软件(包括您自己软件的新版本)更容易与您通信。但作为回报，你必须把你的应用程序的通讯方式与你的特定容器的工作方式相结合。你能做还是应该做完全取决于你自己。