j2ee without ejb

[Kather Basha]

Hello everyone,

we are planning to develop a web module which doesn't have any EJB, instead is having ordinary Java Bean Components. we have some idea in our mind, pl tell me is it suitable or any changes/suggesions on it.

architecture:

MVC -
presentation - jsp pages
- FormBean to accept user inputs(communicate between jsp and servlet)
controller - servlet
single - FontController(to process user request, JNDI lookup to get db connection, reading property file to invoke action classes)
Model -
java beans(getter and setter methods getting populated from db processor classes, travelling between database and servlet)
java processor classes doing db manipulation.

we planning to go for reflection - using single interface for all action classes and at runtime to get the appropriate class. and also singleton design pattern to get db connection using JNDI lookup.and valueobject pattern for javabean(ordinary bean) ie.MODEL.

is it ok?

Regards

Kather Basha.

[Seetesh Hindlekar]

Hi Kather,

Question : How are you planning to handle concurrent users trying to access your web-site considering U using Singleton pattern to db access?
Wont the process slow down if multiple users try to post some data simultaneously in the database.

Seetesh

[Mandira Preety]

we are planning to use Apache tomcat server, so i think tomcat will take care of multi-users by its connection pooling.

Regards

kather Basha

Originally posted by Seetesh Hindlekar:
Hi Kather,

Question : How are you planning to handle concurrent users trying to access your web-site considering U using Singleton pattern to db access?
Wont the process slow down if multiple users try to post some data simultaneously in the database.

Seetesh

[Peter den Haan]

Originally posted by Kather Basha:
we are planning to develop a web module which doesn't have any EJB, instead is having ordinary Java Bean Components. we have some idea in our mind, pl tell me is it suitable or any changes/suggesions on it. [...] is it ok?

Hmmm... what I would suggest entirely depends on where you are right now. I know the stack I would probably attack this problem with, but that's not of much use to you: too much new stuff, probably.

presentation - jsp pages

JSP 2.0, preferably, seeing that you're using Tomcat anyway; and certainly making use of the JSTL.

FormBean to accept user inputs(communicate between jsp and servlet)
controller - servlet
single - FontController(to process user request, JNDI lookup to get db connection, reading property file to invoke action classes)

The controller should never be looking up the database connection; that's something you would prefer to postpone 'till the DB layer or, if you need to control transactions explicitly, the business logic layer.

we planning to go for reflection - using single interface for all action classes and at runtime to get the appropriate class.

Please tell me you're going to use an existing MVC framework such as Struts or Spring MVC. The last thing the world needs is another MVC framework!

Model -
java beans(getter and setter methods getting populated from db processor classes, travelling between database and servlet)
java processor classes doing db manipulation.

Ok, I guess. Do not, I repeat not, ever, try to write raw JDBC code though. Writing solid JDBC code is both very hard and very boring, and consequently most JDBC code that gets written isn't solid. Use at least a JDBC library such as the Spring JDBC template and friends. Consider using an O/R mapping tool such as Hibernate or JDO.

I hear you thinking "well, wiseass, what would you use then"? Without knowing more about the problem you're trying to solve I cannot say for sure, but my weapon of choice at the moment is the "better, faster, lighter" Spring/Hibernate stack:

The Spring bean container to glue all application components together. No Singletons-as-global-variables in my design. No ad hoc configuration. No more boring JNDI lookup code and whatnot. No putting lots of different stuff in one incoherent class for convienience sake. Just simplicity and good OO design bliss.

JSP 2.0, the JSTL and the Spring MVC framework to for the front end. I might settle for the lesser Struts framework if the team is more familiar with that. Given the right problems, JSF, Tapestry or Echo are worth considering as well.

Ordinary JavaBeans (POJOs) for the business layer, with Spring AOP declarative transactions: all the familiar EJB transactional control and more with none of the fat. Of course, once you get the hang of it you'll be using aspects for security, business constraints, templating, logging, debugging, caching and lots of other stuff as well, but initially you can just ignore AOP and simply declare the transactional behaviour you want.

A thin DAO layer backed by the Hibernate O/R mapping tool marshalling a POJO object model to and from the database. Depending on the problem, JDO or the Spring JDBC templates might be appropriate instead.

Keep in mind that this is what I would use, not necessarily what I would recommend to you right now. If you have none of these tools in your toolbox, going the whole hog would be too much at once. In the long term though I would recommend you get acquainted with all of these technologies.

- Peter
[ August 30, 2004: Message edited by: Peter den Haan ]

[Peter den Haan]

Originally posted by Seetesh Hindlekar:
Question : How are you planning to handle concurrent users trying to access your web-site considering U using Singleton pattern to db access?
Wont the process slow down if multiple users try to post some data simultaneously in the database.

No, unless the DAO would be so stupidly written as to require synchronization. Other than that there is no limit to the number of threads that can execute against a single DAO; each would get their own connection drawn, as Mandira notes, from the Tomcat connection pool.

- Peter

[Peter den Haan]

Forgot - Rod Johnson and Juergen Hoeller have written a book with exactly this title (j2ee without EJB) and it comes highly recommended. I am prejudiced, though, having been one of the book's tech reviewers.

- Peter

[Kather Basha]

Thanks Mr.Peter for your inputs, but i'm already very new to J2EE environment. so i think i can't directly go for DAO/Hibernate/Spring framework.

At present we are only using jsp for both presention and serverside validation. and some java reusable components for major database validations and updations.
be frank we are all very new to java and j2ee so we need correct architecture and design patterns to work on j2ee.
we planned to use

jsp - for presentation
servlets- for processing requests/generating responses
java beans(not ejb) - for communication between jsp and servlet(if we need from servlet to db)
java resuable components - for database manipulation.

pl ge me the right solution or any sample we application site that matches my requirement.

Regards

Kather Basha.

Originally posted by Peter den Haan:
Forgot - Rod Johnson and Juergen Hoeller have written a book with exactly this title (j2ee without EJB) and it comes highly recommended. I am prejudiced, though, having been one of the book's tech reviewers.

- Peter

[Peter den Haan]

Originally posted by Kather Basha:
Thanks Mr.Peter for your inputs, but i'm already very new to J2EE environment. so i think i can't directly go for DAO/Hibernate/Spring framework.

Probably not. But do get the book anyway (no, I'm not getting any commission ). I think my recommendation would be:

be frank we are all very new to java and j2ee so we need correct architecture and design patterns to work on j2ee. Expect to make mistakes, then. Rod Johnson's J2EE 1-on-1 book would be a good read as well, although it might stretch you. Do not take all "official" J2EE patterns as gospel; in particular, don't feel that you have to use EJBs. But you had already worked that one out.

jsp - for presentation Given your choice for Tomcat, I stand by my JSP 2.0 recommendation. Don't permit any Java code - scriptlets - in your JSPs.

servlets- for processing requests/generating responses Don't. Use an MVC framework. Don't you have anyone familiar with, for example, Struts? Although it's by no means the best framework around IMHO, it's easiest to get information and people for. If you buy J2EE 1-on-1, Spring MVC is a viable (and superior) alternative, but its greater freedom and flexibility might dazzle you initially.

java beans(not ejb) - for communication between jsp and servlet(if we need from servlet to db) If for 'servlet' I read 'controller', I think you're on the right track here, but you're a bit too skimpy on the detail so say for sure. Use JavaBeans to implement business and data access logic. The controller (Actions if you use Struts, Controllers if you use Spring MVC) should have very little code; it should provide the "glue" between business logic beans, the request, and the JSP.

java resuable components - for database manipulation. Use a framework. I strongly recommend the Spring JDBC template and supporting classes. Do not code directly against the JDBC API.

Despite your status as Java/J2EE greenhorns, I feel the use of the Spring bean factory (or Pico, or similar) might be useful.

pl ge me the right solution or any sample we application site that matches my requirement.

Download Spring 1.0.2 and have a look at samples/petclinic/, specifically with the JDBC data access implementation. It uses the Spring bean container, MVC framework, declarative transactions, and JDBC support. It demonstrates proper use of JSPs, separation of concerns in an MVC architecture, validation, and a simple object model. You will also get to know the essential Log4J, Ant, and JUnit tools a bit. It's small enough that you stand a fighting chance of making sense of it, and large enough to demonstrate what you need to know. Feel free to ask questions.

Brace yourself for a steep learning curve. Your instinct might tell you to avoid all these complex frameworks because you already have enough to learn, but that would be a mistake. Those frameworks embody a vast amount of knowledge and experience that you don't have, and implement a vast amount of work that you do not want to do. Without them, you will learn your lessons the hard way.

- Peter
[ September 02, 2004: Message edited by: Peter den Haan ]