Hi Scott, Kevin,
My own comments intermixed...
Kevin Duffey wrote:
>
> 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.
You could help avoiding major changes in your architecture if you
follow, more or less,
the EJB architecture and then make smart use of interfaces. One
eaxample: in your program,
instead of creating the beans directly using SQL calls, use a method
hidden under an
interface(like EJB does with EJBHome) to get the new Beans from the
database. This
way you won't have to recode all your bean creation routines all over
your code, but just
change the implementation of this interface so it calls the appropriate
EJB method.
> 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.
We, OTOH, follow the Model 2 approach. I agree with kevin that the
auto-population
could be a nice feature but you then have to use the same names in html
and in Java.
We don't have forms big enough to make us change to Model 1.5 for this
reason and if
that was the case, I would create a method to do that myself through
reflection to stay
with model 2. But I still prefer, most of the times, checking and
setting the parameters
explicitly as it prevents some "phantom bugs" to appear when some names
change... But
that's just my opinion.
> 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.
I agree that this can be also a problem but we face it differently. We
prefer to
use frames, stylesheets in static html pages. If they are dynamic
somehow, we always
use model 2 approach as our controller servlet takes care also of
security and
application wide events. This way we have a central point of management
that is sometimes
quite useful. Note: If we used url-rewriting session management, we'd
have to turn our
html pages into JSP pages, we know. But so far, we use either Http
authentication or
cookies.
> (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?
As I explained above, we do link all dynamic pages to the controller
servlet because
ALL the business logic is implemented following the action pattern,
managed by
the controller servlet.
> 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.
If you want to keep working until you start playing EJB, you might start
using
the model 2 & action pattern approach with plain Beans and a connection
pool, but
taking into account what I mentioned above about mapping EJB behaviour.
If you do
so, you might keep the connection pool(CP) in the servlet context and
pass this context
as a parameter to your business logic classes. They can get the CP from
the context,
get a connection, execute the business logic, return the connection to
the CP. Then,
it would be great for you to have application-wide even control, as you
should start
your connection pool at application-init time so it's available for all
your action classes,
and close it at application-stop time. We perform this control at the
controller servlet,
hence the model 2 approach and the name "controller" ;). When you get
into EJB, instead
of keeping the CP in the context, you would probably would want to keep
a reference
to the EJBHome objects, but the functioning will be the same. If you
hide the CP
under an appropriate interface, similar to your future EJBHome, from the
beginning,
you might even get away with the change to EJB without changing a single
line in your
action classes(be careful with exception handling though :) ).
> 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.
That's exactly what we do, we have two applications running this way and
I'm pretty happy
with them. The only problem we had was RMI related as we used EJB with
RMI under
digital unix and RMI is pretty sensitive to heavy network load and/or
unreliability.
> 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?)
We are not there yet because I haven't had time to play with taglibs (I
want
the spec & the implementations to be a little more stable before I start
with it).
And I also want to investigate using JSP to generate XML and then use
XSL to
generate the UI. This way the designers would have just toplay with XML,
which
can be easily faked, and XSL. The business logic would stay at the EJB
and JSP's
would have the UI logic, which means isUserInRole() calls, if's
else's...
Although, we haven't tried it yet.
> 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?
Servlets are more or less like any other java program, the only question
I think
you have to be careful with, is their special lifecycle: Until JSDK2.2,
there's no
way of forcing a servlet to be inited before another one, they can be
destroyed
and recreated, more or less, at will by the container...
We take care of that using the controller servlet approach, if it is not
inited,
then you don't have your application running so no problem :), as all
the calls
go through it, you can make sure in one central location that all the
required
global resources have been initialized before allowing any request that
uses it.
Just my 2c,
Dan
PD: Scott, I already went through this "first-connection-pool-then-EJB"
process with
our applications and if you follow the "mapping EJB way of doing it"
approach, it's
not that bad. Good luck with it.
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
> 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
