A question on 2-tiered architecture.

Hello,

I am very new to distributed computing and mySQL, so *kindly* forgive
my ignorance.

Has anyone recently (or, ever) attempted this, or is planning to
attempt this in near future... with mySql (or, any other RDBMS for
that matter)?

Writing an enterprise-class application...
... NOT with the typical architecture of a J2EE/.NET application;
... but rather, with the 2-tier, client/server architecture (popular
in the 1980's);
... with the RDBMS acting as the application server ;
... with *ALL* the business logic coded via stored procedures;
... with Tomcat/Jsp as the presentation/client tier;
... with clustering / load balancing to be achieved via Tomcat/RDBMS/
xyz? ;
... with JDBC calls to raw sql statements or stored procedures from
servlets;
... that scales to at most a few thousand (not millions of)
concurrent users?

I'm very well aware that sql and stored procedures are not portable
between RDBMSes. But RDBMS-independence is not at all my goal here
(let's say). Let's say, my goal is to stick to only a single RDBMS
(mySql), and then fully and completely leverage every bit of power
offered by sql and the procedural/relational paradigm for extremely
rapid enterprise application development.

What I'm hearing from typical J2EE peers of mine is...
* that the (JBoss-like) application server is where you should put
all your business logic;
* that you must use (kodo-/hibernate-like) framework to convert from
relational to OO;
* that this approach helps offload the computation load from the
database server to the application server;
* that J2EE architecture allows you to scale out and throw in more
app servers to handle increased user loads in future.

What I don't understand is that even if you use kodo/hibernate and
scale out in app server tier, wouldn't the database tier still remain
a bottleneck if you don't scale it out as well (via clustering)? For
example, if in the kodo/hibernate layer you need to perform the
equivalent of a join over N tables, the individual rows of these N
tables (during the join) will still come ultimately from the N
'select' statements executed in the database tier?

I read somewhere on the Net... that the 2-tier client/server
architectures have long been discarded in favor of 3-tier or N-tier
architectures. The explanation typically involves use of an
intermediate application server. But if I decide to use my clustered
RDBMS as my application server, do you see any problems with runtime
application performance? Do you see any other problem (other than
portability problems, non-object-oriented biz logic, ...)?

Would greatly appreciate if you could also point me to any relevant
info / links on this subject. J2EE / .Net books won't tell me anything
other than what they have to offer.

Regards,
/SD.

On May 10, 3:10 pm, SomeDeveloper <somedevelo...@gmail.com> wrote:
> Hello,
>
> I am very new to distributed computing and mySQL, so *kindly* forgive
> my ignorance.
>
> Has anyone recently (or, ever) attempted this, or is planning to
> attempt this in near future... with mySql (or, any other RDBMS for
> that matter)?
>
> Writing an enterprise-class application...
> ... NOT with the typical architecture of a J2EE/.NET application;
> ... but rather, with the 2-tier, client/server architecture (popular
> in the 1980's);
> ... with the RDBMS acting as the application server ;
> ... with *ALL* the business logic coded via stored procedures;
> ... with Tomcat/Jsp as the presentation/client tier;
> ... with clustering / load balancing to be achieved via Tomcat/RDBMS/
> xyz? ;
> ... with JDBC calls to raw sql statements or stored procedures from
> servlets;
> ... that scales to at most a few thousand (not millions of)
> concurrent users?
>
> I'm very well aware that sql and stored procedures are not portable
> between RDBMSes. But RDBMS-independence is not at all my goal here
> (let's say). Let's say, my goal is to stick to only a single RDBMS
> (mySql), and then fully and completely leverage every bit of power
> offered by sql and the procedural/relational paradigm for extremely
> rapid enterprise application development.
>
> What I'm hearing from typical J2EE peers of mine is...
> * that the (JBoss-like) application server is where you should put
> all your business logic;
> * that you must use (kodo-/hibernate-like) framework to convert from
> relational to OO;
> * that this approach helps offload the computation load from the
> database server to the application server;
> * that J2EE architecture allows you to scale out and throw in more
> app servers to handle increased user loads in future.
>
> What I don't understand is that even if you use kodo/hibernate and
> scale out in app server tier, wouldn't the database tier still remain
> a bottleneck if you don't scale it out as well (via clustering)? For
> example, if in the kodo/hibernate layer you need to perform the
> equivalent of a join over N tables, the individual rows of these N
> tables (during the join) will still come ultimately from the N
> 'select' statements executed in the database tier?
>
> I read somewhere on the Net... that the 2-tier client/server
> architectures have long been discarded in favor of 3-tier or N-tier
> architectures. The explanation typically involves use of an
> intermediate application server. But if I decide to use my clustered
> RDBMS as my application server, do you see any problems with runtime
> application performance? Do you see any other problem (other than
> portability problems, non-object-oriented biz logic, ...)?
>
> Would greatly appreciate if you could also point me to any relevant
> info / links on this subject. J2EE / .Net books won't tell me anything
> other than what they have to offer.
>
> Regards,
> /SD.

Hello again,

The above question of mine probably is best articulated via this
paper: http://web.inter.nl.net/users/T.Kopp...DB_CENTRIC.doc

The only problem is that this paper talks about Oracle :-( .

Would really, *really* appreciate if folks who have implemented the
thin / thin / fat model with mysql (or, if they have not implemented
it but can readily see some red flags) can share their experiences /
insights.

Regards,
/SD