Is it worth using an application server together with rich/fat client?

Question

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

Answer 1

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:

• declarative transaction management
• distributed transactions (across several databases, and/or a database and a JMS server, for example)
• declarative and programmatic security
• thread pooling
• concurrency handling
• JPA support for persistence
• JMS support for asynchronous communications
• resources management (connection pools, etc.)
• ability to expose session beans as web services
• dependency injection
• etc.

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.

Answer 2

The server would have three purposes:

• to act as a gatekeeper and make sure the clients are acting sanely;
• to do any processing you don't entrust to the clients; and
• to provide a hub of sorts -- a centralized place where the relevant data is kept, and where clients can meet up to communicate with each other if need be.

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.