Title: Servlets as part of a multi-tier DB application
Robert:
 
You might find the components in Expresso, an open-source app framework/component library, can help build the application you describe.
 
There is a set of security components that keep security out of the way of the problem domain objects, and that handles database security independantly of the underlying DBMS, so you can still use techniques like connection pooling.
 
The database objects are database-independant, so you don't tie yourself to any one RDBMS/OODBMS either, and the whole solution is "lighter" than EJB's, while at the same time allowing EJB's to be used as well if/when you need to.
 
Have a look at the examples on our site, and drop me a line if I can provide any further info.
 
Mike
Javacorporate Ltd
http://www.javacorporate.com
-----Original Message-----
From: A mailing list for discussion about Sun Microsystem's Java Servlet API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Martin
Sent: Wednesday, January 19, 2000 6:38 PM
To: [EMAIL PROTECTED]
Subject: Servlets as part of a multi-tier DB application
Importance: Low

I am designing a multi-tier application in which the User Interface interacts with Problem Domain objects, which interact with Data Management objects, which interacts with the database.  This will be a multi-user application, so users will access the system via a username and password, which will be used, in part for database connections.  Here is where I am running into problems - if my database connections require the username and password to access the database, how do I get this information down to the DM layer without passing it through the PD layer?  I don't want the PD objects to be polluted with the notion of users or an underlying database.  I know I can store any information I like in session variables, but how can the DM objects determine what session called them without session information being passed down through the PD layer?  I've started looking at Enterprise Java Beans as a possible solution, but it seems like there is a lot of overhead there that I don't necessarily need.  Thanks, and I look forward to your comments.

---
Robert S. Martin
First Quadrant, L.L.P.

Reply via email to