Hi,
1. Initially the entire application will run on the web server, on the same
machine as the db server. However, I foresee that in the future we may want
to use an appserver and Enterprise JavaBeans for the application logic. What
can I do in designing my regular beans today, that they will be easier to
replace with EJBs in the future? This may be more of a system architecture
question than about the interfaces my beans expose.
What we are doing to "get ready" is using JSP/JavaBeans on the web server. I
am using the Model 1.5 approach (JSP page is controller..but calls on beans
for all logic), but I am seriously considering the Model 2 approach. I think
the Model 2 is lacking in one area, and thats the "auto-populate" ability of
using a JavaBean on a JSP page with a form that has the same input field
names as that of the setXXX methods of the bean, and using the
<jsp:setProperty .. property="*" /> line. Other than that, I do believe
Model 2 is the right way to go, especially in the case of all requests going
to a servlet first. However, I dont see why "static" jsp pages need to do
this. By static, I mean, on our outside site I have the SAME menubar and
footer on every single page, and the same thing on the inside as well. For
this reason, I use ALL JSP pages, instead of html pages, because I dont
believe HTML has the ability to "include" pages. SHTML does, but we are
shying away from that to become J2EE compliant..so ALL pages will be JSP.
(note: if anyone has a better suggestion, I am all ears). None the less, I
believe all links should go to JSP pages "except" forms. Forms would be
routed to servlets, as in Model 2 approach. Tell me if I am wrong about
this, please, but does it make sense what I am doing..that is, all links on
our outside pages just point to other JSP pages (for the inclusion factor of
the header and footer, as well as a login table on some pages)? Or should
ALL links, requests, etc ALWAYS go to a servlet? I would think that only
"form" posts need to go to the servlet, right?
2. It might help and it seems to me a better separation of business-logic,
site-logic and presentation-logic, if the beans control database access. I'd
like to use a connection pool, like the DBConnectionBroker from
http://www.javaexchange.com/ <http://www.javaexchange.com/> . How can a
bean, instead of a servlet, maintain such a pool over the life of the
application in an elegant way, and how can another bean somewhere else in
the application get/free a connection from the dbpool bean, without the
controller servlet and JSPs ever needing to know about it?
A bean can easily do this..but why? Keep in mind, when you move to EJB and a
middle-tier, ALL the database pooling "should" be handled for you by your
application server, and/or your RDBMS. Normally, that is one of the benefits
of using EJB. It has transaction ability in it, and from what I have read
and learned, it takes care of transaction management and database
persistence for you. Infact, from what I have read, tools such as TopLinks
(if thats the name) are great because they allow you to Model your database
tables, then generate the template information that maps RDBMS tables to
objects for you. You then have your EJB logic use these classes it creates
to access the database (do correct me if I am wrong anyone) and send that
info back to the front end.
Now, I believe ideally you should have JSP/JavaBeans/Servlets on the web
server. Servlets would read in the form, create the EJB on the m-tier
server, and communicate the info to the ejb (session bean). The servlet
calls methods of the EJB's to perform the logic, and gets "data" returned to
it, which it in turn populates a JavaBean with, that the JSP page it
forwards to uses to display. This is probably the best MVC you could follow,
in that JSP pages are "solid" VIEW pages (ok..maybe a little bit of scriplet
code..but with JSP 1.1, taglibs should take care of this as well), where as
the JavaBean/Servlet perform the front end logic, and call on the EJB for
the back-end logic, which handles transactions, database management,
connection pooling, etc. Is this right (anyone that knows?)
3. Since Servlets and JSP are executed as multiple threads, what are the big
concurrency gotchas that I should look out for? I've read someplace that it
is quite common for database query methods to implemented as static methods
to cut creation overhead and to increase execution speed. Is this
thread-safe as long as all fields the static method manipulates are either
passed in as parameters or are local fields, as opposed to static class
fields, or instance member fields? For example, can a static method create a
new result/view bean on the fly and return it to the method caller without
the data being corrupted by other threads or causing a race condition?
I believe the "static" method in this case is often the "first" loading of
the class, such as a database connection pooling class, that it "creates"
all the connections to the database. This is a ONE time occurrence, but you
make a good point..if two or more people all connect at the same time
"before" the connections have been established in the pool, what happens?
The nice thing is JSP/Servlets are thread safe, but are not static
initializer blocks, even if they are in a servlet, done at the class
level..one time when its first loaded before any threads occur? What happens
when two or more requests come in?
Hope this helps..and I hope we see some good feedback on this thread...no
pun intended.
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
