I'm wondering what thoughts people have on the best way to implement a 3 tier application.

I'm playing with the idea of multiple clients <---> server <----> database server <----> mysql database.

I'm not sure if the database server is a necessary step though.

My previous foray into java network progamming just used sockets, but I've read that RMI(?) is a better approach? What think ye? Does anyone know of a basic 3 tier code sample I can get my feet wet with?

11 Years
Discussion Span
Last Post by tonakai

J2EE is also designed for such things, but it can be a pretty heavy architecture for a simple client-server app.


Thanks for the suggestions! Isn't Hibernate an implementation of RMI?? anyway....

Hypothetically speaking, if an application need to scale from 50 to 500,000 users(disregarding hardware issues) would all three tiers really be necessary? Could we just go with:

many clients <----> Server <----> Database ???

Although I guess the 3rd Tier allows for better control of say, connecting to different types of databases though...

And although yes, Hibernate/RMI seams like the way to go, I think all would agree setting up a simple client server from scratch or playing with a code sample is probably better starting out to learn the bare bones first. At least I find that jumping into something more complex without first seeing the different parts in action just complicates the matter.


Depending on your application one of the 2 approaches can be chosen.. If you have enough complexity in DB parts OR more than one servers connecting to DB layer, you might want to have database server separately..
In anycase as Ezzarel pointed out J2EE is designed EXACTLY for this purpose.. See this architecture diagram.. it's not mandatory to have 2 physically different machines for J2EE and DB server, both can be on one machine..

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.