Wine Vaughn wrote:
> I've been monitoring this list server for several weeks now, and several
> people have commented that they like using Model 2. (There are two JSP
> approaches mentioned in JSP spec 0.92. They are refereed to as Model 1 and
> Model 2.)
>
> Why? What advantages does Model 2 have over Model 1?
>
> I've used Model 1 in several scenarios, and I cannot see what advantage
> Model 2 would provide. The only thing that comes to mind is Model 2
> separates the logic a little bit more. However, I prefer to have the bean
> do the processing with processRequest, instead of dividing the work between
> a servlet and bean....
>
> Comments?
>
> Vaughn Wine
--- BACKGROUND ---
Being one of those who has advocated the "Model 2" approach, it is probably
appropriate for me to take a crack at this one. But first, you need a little
background information about the kinds of problems I am facing.
I am currently in design phase for a large scale application, to be deployed
on the public Internet, that will be based on Java and JSP technologies. In
particular, I've got several needs driving the design:
* Total page count on the site will be upwards of 1000 pages
(over time -- initial site will have ~100 pages).
* Integration of content and applications from multiple content
providers and developers.
* Approximately 80% of the pages will be dynamically generated,
the remainder pretty much static HTML.
* Majority of the site will be more akin to traditional client/server
applications systems in its business logic complexity, rather than
the typical web site that has very little processing logic.
* Must be deployed in multiple languages (initially English, French,
Spanish, Dutch, and German).
I am not "anti" Model 1 for applications of a certain scope, except for one
particular feature (described futher below). However, there are a bunch of
reasons that I am planning on exploiting a Model 2 architecture for this
application that are worth discussion.
Many people have asked for tutorials and white papers on JSP, and in
particular on web application design concepts. The best one I have found so
far is by IBM, entitled "The Web Application Programming Model". I highly
recommend that serious students of web application design download and study
this paper, which can be found at:
http://www.software.ibm.com/ebusiness/pm.html
(No, I don't work for IBM. It is not necessarily likely that I will even use
IBM's products to build this site. But this is a pretty good overview of the
technological underpinnings of web based applications.)
The remainder of this discussion is divided (somewhat arbitrarily) between
more high level strategic concerns (entitled "philosophical issues") and lower
level tactical concerns (entitled "practical issues"). I am not going to
discuss at all why JSP is a good idea in the first place -- it is :-) -- the
focus is on the differences between Model 1 and Model 2 JSP-based designs.
--- PHILOSOPHICAL ISSUES ---
SEPARATION OF PRESENTATION DEVELOPMENT AND BUSINESS LOGIC DEVELOPMENT. In
many large scale web application environments, the look-and-feel part of the
design is done by experts in HTML (who may have some light programming
experience, particularly with JavaScript), while the heavy duty business logic
programming is done by experts in Java and databases (who may have some light
HTML experience, having probably developed simple servlet based applications,
or equivalents with ASP or other technologies, in the past). It is much
easier to focus developers who are expert in one technology or the other in a
"Model 2" approach, whereas this is not as easy in a Model 1 approach. In the
latter case, it is much more likely that you see logic and presentation mixed
(especially due to scriptlets), meaning that you need someone who is expert in
both technologies to maintain them. How many developers out there (given the
current market demands) can you find that are good at both of these?
MODEL-VIEW-CONTROLLER ARCHITECTURE. The history of complex application
systems design has proven that the fundamental MVC paradigm, even though it
might be more complex in the early stages, leads to better designs from the
long term business viewpoint (ROI, lower cost-of-ownership, and so on). The
"Model 2" approach lends itself directly to this architecture (JSP and
formatting beans = view, servlets = controller, command beans and business
logic = model). This strict separation of roles is blurred in a "Model 1"
environment.
REUSE OF COMPONENTS. A JavaBean to provide business logic for a "Model 1" web
based application is pretty intimate with the fact that it is invoked in a
servlet environment (for example, the argument to processRequest() is an
HttpServletRequest). With a "Model 2" approach, it is very easy to design
pure JavaBean components to encapsulate the business logic that are reusable
in non-servlet/JSP applications as well, because they communicate strictly
through standard JavaBeans techniques (properties and events), with no tie to
the servlet request/response paradigm.
For example, consider a session EJB that represents a set of complex business
logic. It is almost effortless to integrate such a bean in a "Model 2"
application, whereas using it in a "Model 1" application requires you to build
an interface layer into your beans that understands servlet semantics.
THE COMPLEXITY ARGUMENT. One of the most common recent arguments
against Model 2 on the JSP-INTEREST mailing list has been that it is so much
more complex than Model 1. For a simple-to-moderately-complex web site, this
may have some merit, but on the whole it strikes me as a cop-out.
Consider the "ancient" days of three years ago, when HotDog was a
revolutionary HTML editor because it color coded and syntax checked your HTML
tags as you wrote them. When is the last time you met an HTML page designer
that even knew what a tag looked like? That is what the power of tools does
-- it makes what was once the work of a master craftsman something that
non-geeks can excel at. JSP is very early in its technology life cycle, but
there are already a few tools around that deal with the complexity issues, and
let you focus on the design (for example, IBM has a tool that takes an
application outline and builds you an entire "Model 2" based application
template). The trend towards developing more sophisticated tools to support
application development in this style is unmistakable It seems pretty lame to
me that complexity becomes a excuse for not understanding what it takes to
build large scale application systems that are maintainable, scalable, and
growable.
COMPATIBILITY WITH FUTURE TECHNOLOGY DIRECTIONS. A large amount of attention
is currently being given to XML (with associated XSL stylesheets) as a means
of separating logical content from presentation, even in "static content"
applications. The missing link in XML+XSL is the dynamism that JSP makes
easy. IMHO, future developments will see an integration via the addition of a
formal "logic processing" link between the XML description of content, and the
XSL description of presentation. JSP "Model 2" architecture applications will
have a natural evolution path in this direction -- "Model 1" architecture
applications are going to have a much tougher time.
--- PRACTICAL ISSUES ---
SEPARATION OF DEVELOPMENT SPECIALTIES. Even on the pure Java development
side, there is often a specialization between developers focused on user
interface and presentation components, versus business logic and database
interaction components. Model 2 architectures let you exploit these
differences in expertise in a natural way, while Model 1 architectures
encourage a blending of different component types in single beans.
EVOLUTION OF THE SERVLET API. The 2.1 version of the servlet API is only the
starting point towards turning servlets into a very useful deployment platform
for web-based applications. The fact that a JSP page is normally compiled
into a servlet (this is *not* mandated by the spec) is deliberately hidden
from the page designer, making it very difficult to take advantage of these
technology changes in the future.
SCRIPTLETS ARE BAD. The single worst feature of the JSP 0.92 specification,
IMHO, is the inclusion of <% %> scriptlets, that encourage you to mix business
logic into your presentation. Consider, for example, what this means in the
light of my multilinguism requirements. Clearly, I need to have five versions
of the presentation logic (as JSP or HTML pages) -- but I can utilize a single
copy of the business logic, as long as it is designed with this need in mind.
Now, a need comes along to revise the business logic for some reason, with no
change to the presentation. With a strict model 2 approach, I make one change
and I'm done. If I use scriptlets heavily, I have to change it five times for
five language versions, and ensure that I've stayed in synch!
FLOW OF CONTROL ISSUES. A very common application requirement is that the
system should check whether the user has logged in, and redirect him/her to a
login page if not. In a Model 2 environment, this is really easy -- you get
to construct the path that is passed to the getRequestDispatcher() call with
program logic. It is not easy to do without scriptlets, even when using
processRequest(), because the bean does not have access to the servlet
response or the servlet context, and can therefore not use request dispatchers
or the sendRedirect() method of the servlet response. You are forced to use
scriptlets to do these kinds of things -- thereby limiting yourself to
JSP implementations where the page is in fact compiled to a servlet.
In addition, the spec says that processRequest() gets called if you have
defined it, but what happens if you've got lots of beans with processRequest()
methods defined? They *all* get called! Who is in charge of the final
output? The typical result, in the hands of the typical developer, is a
spaghetti factory.
--- SUMMARY ---
Model 1 architectures can be useful in simple designs, but they simply don't
cut it for large scale, complex, application systems. For applications that
don't model well as a set of HTML pages (albeit dynamically generated) with a
few server side includes sprinkled in, you need a more powerful paradigm. In
the JSP environment, "Model 2" is it. The fact that it will be portable
across server environments (versus the many very nice template-based but
proprietary application development systems that are around) is incredibly
nice.
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
