RE: 3-tier architecture

Tracy

        We are wrestling with the same issues that you raise. Still designing, so I can't speak from experience, just theory. I can't disagree with anything you say, but here are how I see some of the issues:

• You agree that PL/SQL in the database will usually be more maintainable (single point of code) and faster than Java outside.
• I feel this difference isn't quite as sharp as it would be if you were comparing client code running on a desktop. There is only a single web server and it probably has a fast network link to the database. There is probably a single app. server and with an object-oriented language like Java, code shouldn't be repeated, moderating the maintenance issue.
• In the projects I have been on, fundamental mistakes were usually made by saying up front "we're going to do it this way, period". As a developer, things like Java and PL/SQL are tools. A good developer should be willing to use the appropriate tools where needed to meet the project goals. You wouldn't tell a handyman to fix your house, "but don't use a screwdriver".
• There will probably be sections where PL/SQL will provide the performance boost needed. For many other sections, performance may not be that critical.
• App servers are capable of some sophisticated caching themselves. This may provide even greater performance for certain situations than PL/SQL could ever achieve. Specifically, I have heard of Web sites that are able to provide data right from the web server rather than making a database request.
• If this is a large project, the project leaders probably have some strong ideas about which language they will use to code the business language.
• Java in the database sounds great for certain situations. Doesn't require the developers to learn a new language. I would be interested in any tradeoffs people have found.

Dennis Williams
DBA, 20% OCP
Lifetouch, Inc.
dwilliams_at_lifetouch.com

-----Original Message-----
Sent: Wednesday, June 12, 2002 4:18 PM
To: Multiple recipients of list ORACLE-L

We're looking to implement a 3-tier architecture with websphere, java and oracle. My question is where should the code be deployed for oltp apps and batch processes? Are the business rules(components) deployed on the middle tier and that same logic (if applicable within batch) deployed as java within
the database? It would appear to me that batch would execute faster if the source resides in the database rather than the app server, but that we are gaining a maintenance(deployement) issue for the performance gain. Should the
business rules be deployed within java and the data access be written in pl/sql. Any thoughts?? What are others doing today and are there any papers available regarding these issues? Thanks

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Tracy Rahmlow
  INET: tracy.rahmlow_at_aexp.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: DENNIS WILLIAMS
  INET: DWILLIAMS_at_LIFETOUCH.COM

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).