Comments on: Role of the Database in a J2EE Architecture – Dumb Data Store? Only Data Tier? Also Business Tier? Friends of Oracle and Java Sun, 31 Aug 2014 06:57:42 +0000 hourly 1 By: daryl fong Fri, 09 Sep 2005 03:41:10 +0000 /?p=759#comment-2386 Interesting comments. I find that you are a bit frustrated that some Java developers are
not familiar to the database funtionality. The decisions on what features to use
should have been made by the application architect who should have broad awareness
of the selected product’s capabilities.

One of the ideas of J2EE is to seperate the business logic and the data tier
depending on the requirements & complexity of the application. It should stop you
from leveraging the database features to give better performance or productivity.

I think 100% database independance is not feasible but by using good
development practice (eg. DAO Pattern), work can be isolated and reduced
when porting from one DB to another.

By: Toon Koppelaars Tue, 06 Sep 2005 10:50:27 +0000 /?p=759#comment-2385 I could not agree more here, especially in the area of data integrity rules.
They should be enforced at the RDBMS-level, period (no discussion possible).

Regarding J2EE, there is one aspect that you do not touch: its (immense) complexity.
Don’t get me wrong, I love Java, it is a beautiful programming language. But I still get
amazed by how complex this whole J2EE monster on top of Java, has been made.
The amount of knowledge a simple developer must have to be productive in this area, is
orders of magnitudes more than used to be. And it is even worse when maintaining (ie. not
building new) existing software.
How does this benefit ‘the customer’, who just wants a part of the business supported by some
IT application system…

By: Mike Friedman Sat, 03 Sep 2005 01:24:27 +0000 /?p=759#comment-2384 Honestly, your arguments above have already (a long time ago) convinced me that the whole J2EE approach is wrong.

Oracle should take another look at PL/SQL and DB objects and “J2EEify” it. Why shouldn’t I be able to build an application using database objects the same way I can build an object using J2EE?

Unfortunately, Oracle seems to be drinking the Java Koolade… have you noticed that many of their newer products (ie. Collaboration Suite and iFS no longer have PL/SQL APIs?

By: Robert Gauf Fri, 02 Sep 2005 23:26:10 +0000 /?p=759#comment-2383 Well stated Lucas. You’re very right in that the key isn’t “database independence”
(no reliance on the database doing anything). Rather it is “optimal independence without
giving up on the real power of databases”.

One past experience stands out. In a mixed skills shop, we actually had the old Forms folks,
the DBAs, and the new Java folks sit down with a taxonomy of business rule types (yes, from
Rule Frame). And decided, as a project standard, what types of rules should be implemented where.
And how. Everyone learned. And learned to appreciate the capabilities of other layers (like not
having to deal with mutating data in triggers — do it in the middle tier!!).

It’s all about the best use that gets the best result. Not about the dogma!!

By: Ben C Fri, 02 Sep 2005 13:05:41 +0000 /?p=759#comment-2382 Great post! I knew most of the db features that you mentioned, but the “communication from the database” section really caught my attention. You’re right though in that if you’ve spent several thousand dollars on a db, you better use it. I think the problem with a lot of development companies is that they didn’t invest in good DBA’s who know of these features. I’ve been fortunate in that the company I work for has three awesome DBA’s who really go out of their way to educate us Java developers. They’ve also saved our butts (mine included) on several occasions. A good DBA is worth his/her weight in gold!