Swing rich client in a multi tier context

Answer 1

This sounds like an app tailor made for a web services implementation. Your front end calls the web service for data or returns data for persisting. The business tier runs on the server and takes care of packing up data for the clients.

1. For non-technical people the best way I've found is to impress them with outside experts. Find white papers on the web about Service Oriented Architecture and Web Services (probably about ten years old at this point) to show them that what you are proposing is accepted architecture. You are going to write the code - one way or other the functionality has to be there - make sure it is written in a way that can be maintained.

You can also explain that testing will be easier, coding will be easier, and addition of features in the future will be easier and more straight-forward.

\2. and 3. The apache.org site has lots of functionality already written, ready to use (when you come up to speed on how to use it.) Check out the Jakarta and Web Services project groups.

Answer 2

I am by no mean an expert on this, but I have some thoughts that may be helpful.
1)It is a standard practice to separate code that handles the presentation layer with code that handles business logic. Swing framework itself enforces this via the MVC pattern. Having said this, why are you thinking of a remote server interacting with the DB? It is certainly an option, but you have to take into account the various network delays. Do you care about how fast the GUI is updated for instance? You could have a presentation tear i.e. design and structure your project so that you have a layer(separate from presentation layer) interacting with the DB that is local and not in a remote server. In your question concerning arguments to non-techical people, I assume for using the remote server. If you think it must be remote you could present the benefits of decoupling, performance and the overall design.
2) If you want to have a remote business tier you could use web services. Although must it be remote?

Answer 3

A 2-tier architecture (your Swing client connecting directly to the database) is usually simpler, easier to implement and less expensive since it involves less code, fewer systems and fewer technologies (you don't need to learn about web services, JEE etc.)

A 3-tier architecture (Swing client, application server, database server) can be beneficial if one of the following reasons apply:

1. If it is easier to implement the security (authentication, authorization) on the application server than on the database server. In a 2-tier architecture, you need to setup a database user for each end user and you need to properly protect all your tables and procedures. In a 3-tier architecture, you can usually use a single technical user to connect to the database.

2. If it is not possible to directly connect to the database from a client because the security policy forbids it or the network infrastructure (firewalls) prevents it.

3. If it is difficult to deploy a new version of the client software on each desktop. In a 3-tier architecture, 50% - 70% of the bugs can be fixed by just deploying a new version on the application server.

If you have to go for a 3-tier architecture, you probably want to look at JEE (Java Enterprise Edition) and at the application servers implementing it (JBoss, GlassFish, WebLogic etc.). There's a lot of literature about JEE best practice. But be aware that JEE is complex and has a steep learning curve.

For the database access, I'd look at Hibernate. Besides being very well suited for database access without having to deal with the niffty JDBC details, it also supports mechanisms for preventing lost updates.