How to design a 2/3 tier distributed application in Java?

Question

I got the task to design a distributed system that basically consists of one centrally shared database and multiple fat clients (Swing based GUIs) that should interact with this database. I basically want to administrate some addresses, deadlines, tasks, etc. I am currently using Java 6 SE, JPA (eclipse-link) and a MySQL database. Now I am facing some problems:

• How is client 2 informed about data changes committed to the database by client 1 ? Is it a good idea to use an RMI approach for messaging ?

• I am dealing with stale data, since the JPA EntityManager caches the query results. Does it make sense to broadcast "db-change"-messages to all active clients that they may refresh the locally cached entity objects ?

• Is there a much simpler approach to achieve these goals by using an application server like GlassFish ? Or is the usage of Java EE application servers only convenient for web development ? (sorry for these newbie questions, but I really didn't found any clear answers by reading the Java EE docs, or I simply didn't got it :-/ ...)

Any help is highly appreciated - many thanks in advance!

Answer 1

Is there a much simpler approach to achieve these goals by using an application server like GlassFish ?

That is the precise point of an application server (which is distinct from a web-server) in a 3-tier setup. Certainly you can poll and/or use messaging to provide additional hooks for meta-data (eg db change event) communication, but you will end up poorly reinventing a very well known (and non-trivial) wheel (eg data synchronization in a distributed tier).

If you can live without caching query results in the client and latencies of accessing the server (2nd tier) for data access are acceptable, then clearly that is the way to go.

[below is a fairly late ps but happened to read this and the question again today and personally felt it required clarification.]

Java EE is a distributed container/component based architecture for the enterprise tier. Putting aside the failure of a component market to emerge for J2EE (though some did try) what is remains is the fact of its COA and its inherent support for distribution as a foundational concern of the architecture. Note that the web profile (eg "web-server") of Java EE is also part of the same architecture.

So what do you get when you use one of these Java EE application servers and how would it address your requirement/design concerns.

Two important key aspects of the support for distribution offered by Java EE are its (a) distributed name-space (JNDI), and (b) its menu of offerings for connectivity across tiers (pure RMI (where you roll your own distributed RPC based system), Enterprise Beans aka EJBs (remotely and locally exposed component interfaces with well defined semantics in terms of lookup and life-cycle in distributable containers). Of the EJB flavors, in terms of connection semantics, you have messaging (JMS) and straight-up RPC.

For your case, you could, for example, opt for a JMS message bus with both fat-client JMS end-points and MessageDrivenBean EJBs. You c/would design a messaging domain with both topic/subscription based and straight up Queues. These can be declaratively configured to be durable, or not, etc.

Your application server c/would provide this JMS provider, or you could opt for a best of breed, eg TIBCO, for your needs, per your requirements.

You are not reinventing any of the above very non-trivial concerns. Your focus remains your domain requirements, and you have all the tools you need to create, within certain reasonable SLAs, your platform.

A viable alternative to this is to compose what boils down to the same exact thing minus the COA approach of Java EE (which both gets you declarative magic and pita development ceremony) with stand alone OSS software eg ØMQ for your bus, REST remote RPC, and possibly REDIS for beefing up persistence guarantees for your messages and for coordinating (no JNDI ..) your distributed balls in the air.

I personally prefer that latter, given that it is more fun for me. Also efficiencies gained due to more direct control over the distribution layer allows for scalability gains given very stringent requirements (eg a tiny minority of requirements out there).

A distributed system design for the enterprise ("have been tasked") needs to consider business requirements beyond merely the application domain. That is part of the equation.

Hope this is helpful (and timely ;)

Answer 2

Your clients conceptually connect to a "middle-tier" which contains the "business logic".

You clients send all requests to the "middle-tier" and the "middle-tier" preforms them. This means that if a middle tier cares about coordinating clients, the middle-tier can remember which clients have "looked at" an important object, and (provided the technology supports it) can transmit an update to the appropriate clients.

Clients mainly contain code to present the data under this scenario, and the code they contain to accept requests mostly proxies the request to the middle tier.

Answer 3

Since you are using JPA you could benefit from its entity locking and concurrency mechanisms .

There are two main concepts for JPA (Quoted from Java EE 6 tutorial):

Optimistic locking:

By default, persistence providers use optimistic locking, where, before committing changes to the data, the persistence provider checks that no other transaction has modified or deleted the data since the data was read. This is accomplished by a version column in the database table, with a corresponding version attribute in the entity class. When a row is modified, the version value is incremented.

Pessimistic locking:

Pessimistic locking goes further than optimistic locking. With pessimistic locking, the persistence provider creates a transaction that obtains a long-term lock on the data until the transaction is completed, which prevents other transactions from modifying or deleting the data until the lock has ended. Pessimistic locking is a better strategy than optimistic locking when the underlying data is frequently accessed and modified by many transactions.

Choose the strategy that fits best to your application behavior and functional requirements.

Answer 4

the fat clients can poll on a configured interval. This is similar to mail clients like outlook, which poll for new e-mail messages.