是否值得将应用程序服务器与富/胖客户端一起使用？
我知道在 Web 应用程序方面应用程序服务器被大量使用。在这里，您有一个瘦客户端（浏览器）与 tomcat 或 jboss 等应用程序服务器进行通信。
我现在仔细研究了一个商业软件，它也使用应用程序服务器和富客户端。 （<100 个用户）这里，富客户端与应用程序服务器上运行的服务器软件（例如 tomcat、jboss，...）进行通信。
我看不出为什么有人将应用程序服务器与富客户端一起使用的好处。
解决方案 b 相对于解决方案 a 有何优势？
a) 富客户端 <->在 jvm 中运行的简单服务器
b) 富客户端 <->服务器运行在应用程序服务器上，如 tomcat 或 jboss
谢谢
I know application servers are heavily used when it comes to web applications. Here you got a thin client (browser) communicating with an application sever like tomcat or jboss.
I now took a closer look at a commercial software, which is also using an application server together with a rich/fat client. (<100 users) Here a rich client commuicates with server software running on application server (e.g. tomcat, jboss, ...)
I cannot see the benefits why somebody would use an application server together with a rich client.
What benefits has solution b over solution a?
a) Rich client <-> Simple server running in jvm
b) Rich client <-> Server running on application server like tomcat or jboss
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
具有胖客户端的应用程序服务器提供与具有 Web 应用程序的应用程序相同的功能。如果应用程序服务器仅对 Web 应用程序有用，那么即使对 Web 应用程序使用它们也是没有意义的：一个简单的 Tomcat 或 Jetty 服务器就足够了。
完整的 Java EE 应用服务器的优点如下：
无论 UI 是否基于 Web，所有这些功能都很有用。如果您的应用程序没有使用所有这些功能，那么您不需要应用程序服务器。如果您不需要所有这些，并且更喜欢自己集成各种组件（事务管理器、JPA 引擎、JMS 服务器等），那么您可以只使用 Spring，无论是否带有 Tomcat 或 Jetty 等 Web 容器。
An application server with a fat client provides the same features as an application with a web app. If application servers were only useful for webapps, there would be no point in using them even for webapps: a simple Tomcat or Jetty server would be sufficient.
The advantages of a full Java EE app server are the following ones:
All these features are useful, whether the UI is web-based or not. If your application doesn't have any use of all these features, then you don't need an app server. If you don't need all of this, and prefer integrating various components (a transaction manager, a JPA engine, a JMS server, etc.) yourself, you could just use Spring, with or without a web container like Tomcat or Jetty.
服务器有三个目的：
如果客户端自己完成所有事情，并且不需要彼此直接通信，那么您实际上不需要应用程序服务器。但您拥有的用户越多，他们就越需要相互协调自己的操作。过了某个特定于应用程序的点，客户互相践踏工作的风险就超过了去中心化模型的大部分好处。到那时，混合使用服务器就更有意义了。
如果您需要示例，请以 Microsoft Access 为例。我们可能会同意它是一个胖客户端数据库应用程序。它或多或少地直接修改数据库（无论如何，在 Jet/ACE 数据库的情况下），并且可以与其他进程共享数据库。但由于用户太多，特别是通过网络访问共享数据库文件，损坏几乎迫在眉睫。但是，如果您引入 SQL Server 来处理数据库，并让 Access 执行 UI 工作并生成查询等，您将获得大部分相同的好处，并且破坏数据库的风险要小得多。
至于独立服务器是否比 Tomcat 中的 Web 应用程序更好或更差或其他什么：这些容器之一中的应用程序与在 Tomcat 中运行的 Web 应用程序相比于独立的 Java Web 应用程序具有大部分相同的优点......不必太担心低级细节。您处理的是请求和响应，而不是套接字和数据包。此外，使用 HTTP 等已知标准协议可以让其他软件（包括您自己软件的新版本）更轻松地与您通信。但作为回报，您必须使应用程序的通信符合特定容器的工作方式。您是否可以或应该这样做完全取决于您。
The server would have three purposes:
If the clients do everything on their own, and have no need to communicate directly with each other, then you don't really need an application server. But the more users you have, the more they'll need to coordinate their actions with each other. Past a certain app-specific point, the risk of clients trampling on each other's work outweighs most benefits of a decentralized model. At that point, having a server in the mix makes more sense.
If you need an example, take Microsoft Access. We can probably agree that it's a fat-client database application. It modifies the database more-or-less directly (in the case of Jet/ACE databases, anyway), and can share a database with other processes. But with too many users, particularly accessing a shared database file over the network, corruption is all but imminent. However, if you introduce SQL Server to handle the database, and let Access do the UI work and generate the queries and such, you have most of the same benefits with far less risk of trashing the database.
As for whether a standalone server is better or worse than a web app in Tomcat or whatever: An app in one of those containers has most of the same benefits that a web app running in Tomcat has over a standalone Java web app...you don't have to worry as much about the low-level details. You deal in terms of requests and responses rather than sockets and packets. Also, using a known and standard protocol like HTTP makes it easier for other software (including new versions of your own sofware) to communicate with you. In return, though, you have to fit your app's communications within how your particular container does stuff. Whether you can or should do that is entirely up to you.