Recently I have been helping my company develop a model for a two-tier
architecture which will be easily migrated to an EJB multi-tier environment.
We have created the attached document which details the architecture we are
going to be working with. I'd like to solicit comments from this mailing
list, as well as make it available to others. It is loosely based on some
various MVC design pattern articles.
In this scenario (see the doc), the http request comes into the servlet,
which is the controller. The controller checks security (this eliminates
having security dependant on calling a bean directly from the jsp). The
controller then does any site setup, and calls a 'header' document.
Next, the 'data frame' JSP is invoked. This JSP is called by either having
the previous JSP post a name value pair (template='test.jsp'), or by
invoking a workflow component. The JSP will call a bean to get it's
content. The bean itself does not do any JDBC or other types of lookups, it
will call a class file which will do any low level queries. The class file
might return a vector of results to the bean, which will then format the
results into html, and pass this to the JSP.
This way if we have resources which need to be retrieved by non-html
queries, we have a set of classes which we can use, while the beans are
really there to turn data into html which is then encapsulated in the
calling JSP page. Also these class files can eventually be turned into
EJBs, easing migration.
So once the 'data frame' jsp is complete, the servlet then calls a footer
document, and results are returned to the browser.
There are a number of rules to the system.
1st- the servlet acts as a 'dumb' controller. It does not 'generate' new
html, but rather calls JSP pages (or other servlets) to create new html.
2nd- navigation logic resides in the JSP. Now I know this goes against
many of the articles I have seen of late which suggest that all navigation
be determined in the servlet, by say, basing decisions on the user session
or form information. I personally find this to be a very cumbersome system,
and prefer to leave any decision making to the JSP page. Some of our JSP
pages are extremely complex, and have different presentation anyway
depending on the context in which they are called (for example forms which
are pre-populated or not depending on if they are editing or creating a
record). Also this fits more in line with other tag-markup languages such
as Cold Fusion.
3rd- beans format information into HTML, which is configurable based on
which bean parameters are invoked. Beans never do low level queries, these
are left to class files (typically running in another JVM)
4th- Security is always invoked by the servlet. JSP pages would be blocked
by the web server from direct invocation to insure that all JSP pages have
security. Security might need to be reinvoked at the Application server
level as well for redundancy (in case the request is from a non-http
source).
I know this is a reasonably long email but I'd like to get some reaction
from anyone who has the time to read all this! I am especially interested
in the ability of pages created in this architecture (which is really
two-tier) to be migrated to and EJB multi-tier architecture.
Josh Lannin
------------------------------------------
Soon we'll be saying 'Back in my
millennium we still used Microsoft...'
_|_|_| _|_|_| _|_|_|
_| _| _|
_| _|_| _| _|_|
_| _| _| _|
_|_|_|lobal _|_|_|ommerce _|_|_|ystems
Joshua D. Lannin 4840 Pearl East Circle
Software Engineer Suite 301-W
[EMAIL PROTECTED] Boulder, CO, 80301
------------------------------------------
architecture.doc
