permaculture playing cards
The moose likes OO, Patterns, UML and Refactoring and the fly likes Application Tiers and Data Access Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Application Tiers and Data Access" Watch "Application Tiers and Data Access" New topic

Application Tiers and Data Access

M Jay
Ranch Hand

Joined: Sep 21, 2004
Posts: 66
Hi there,

I am developing an application for university project, and here is the problem I am facing at the moment:

I have a Business Logic application, which acts as a backend system and handles all business logic. This will be used by a web application front end. It will also be queried by another application which is not a web application.

So basically I want my Business Logic application to handle all Data Access and database queries. This means that I won't be able to make use of the datasource features offered by the application server im using for my web application.

Is all the above ok? Does this architecture make sense? and if so, what is the best way to handle DA in my BL application? through connection pools?

Any help would be appreciated.


SCJP J2SE 1.4<br />SCBCD J2EE 1.3
Scott Ambler
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
Why can't you use an instance of the app server to implement your business logic server?

If that isn't viable, why can't you use an existing persistence framework? See Encapsulating DB Access for strategies and Design of a Persistence Layer for a list of options.

- Scott

<a href="" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I see several options coming from your own comments and Scott's suggestions. See if I boiled these down the same way you do ...

1) Use a single technique all the time, whether the code is running in the app server or as part of the standalone application. It might be straight JDBC, a framework of your own or an established tool like Spring or Hibernate. As you described it: don't use the features of the app server.

2) Build an abstract interface for data access with one implementation for the app server and another implementation for standalone use. The app-server one could use the server's datasource while the standalone one makes its own JDBC connections.

3) Make the standalone app call through the web server instead of directly calling the persistence package, making your business layer a web service. This is likely overkill; the urge to make every last thing a web service is sometimes just inappropriate. Or it may have value if it makes a "pointy haired boss" say "Ooooo, web services! I've heard of those! I see raises and promotions in your future!" Seriously, it is reuse of a running system rather than reuse of code. Sometimes that's a useful distinction.

Any of those sound worth digging into for more detail?

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I agree. Here's the link:
subject: Application Tiers and Data Access
It's not a secret anymore!