|
Technical management, engineers, and developers can read this high-level
document.
|
WARNING:
This document is the copyright of Deutsche Bank (UK) ©
January 2001. The document is "AS-IS" an evaluation of
a software product or third-party programs. It should not taken
as an endorsement, validation, approval, or any such special merit
thereof of the software or the software vendor. The information
contained in this document should not taken as a confidential action,
or privileged information financial or otherwise, or as an official
press release, or construe any present, past or future, direction
of the Bank itself. Moreover, the Bank reserves the right to change
its direction, motivation or evaluation at anytime, whenever and
whereever it sees fit to do so regardlessly of the opinions, notices,
remarks, quotes or text expressed inside this document.
|
Enjoy.
Model/View/Controller is a name given to a
software design pattern. If you are familiar with design patterns, a collection
of common strategies used in software development then you will know about the
benefits of this design already. A discussion of design patterns is
out-of-scope of this document, however, I will summarise the benefits for those
who are unfamiliar.
Combining Model/View/Controller into one
class or using global variables did not scale.
- The model is unstable due to the requirement to have more than one view
- Sometimes a different controller is
required.
Separation eases maintenance in the long
run.
- Easy to add a new view later.
- Easy to change the relationship to a brand new view or controller later.
Java MVC design is
not really difficult.
The basic concept of
Model/View/Controller has been proven since the early 1980’s with research and
implementation in Smalltalk 80.
Do we need to write
our own MVC architecture?
There are several “kits” for templating
HTML output with server side Java development. All of the best known frameworks
are built MVC to some degree. At best they are immature products, the WebMacro
framework seems to be the most mature, however it is incompatible with Java
Server Pages. All of the them are non-standard, and are competiting with each
other. None of them can be considered the de-facto standard. Therefore it would
be best to avoid the wrong investment, and vendor lock-in, until the market and
software practice says otherwise. The frameworks are actively being developed,
and therefore are continually evolving. Moreover, it is difficult to find
information about their support to the next phase of Enterprise Java Beans.
For the short term I think we need to write
our own simple MVC architecture since we will able to adapt it quicker to our
own applications. We do not want to invest time in the wrong package. We also
should avoid falling victim to the “bleeding
edge”.
Web Macro
http://www.webmacro.org/
Version: 0.94
License: Open source and pure Java
Description: An HTML template scripting language and engine with a framework for implementing server-side Java applications. Servlets work by separating programming work from pagedesign: Page designers create HTML templates with the script language. Programmers work in clean Java code, free of HTML and other presentational clutter.
Rating: The most mature of the framework kits. It is appears to be an alternative to Java Server Pages.
Struts
http://jakarta.apache.org/struts/index.html
Version: 0.50
License: Apache open source
Description: Struts encourages appliation architectures based on the Model-View-Controller (MVC) design paradigm, colloquially known as Model 2. Struts has acontroller servlet that dispatches requests to appropriate Action classes provided by the application developer. It supports JSP custom tag libraries, forms, XML, and internalization.
Rating: A framework that does support Java Server Pages. Like the
Carphone Warehouse catalogue “too new to comment.”
Velocity
http://jakarta.apache.org/velocity/index.html
License: Apache open source
Version: No release yet
Description: The Apache Jakarta Project’s implementation of the WebMacro templating concept.
Rating: It is not original, because WebMacro has done it, so why reinvent the same wheel again. An another alternative to JSP. Poses more questions than answer an like the Carphone Warehouse catalogue “too new to comment.”
Tapestry
http://tapestry.primix.com/
http://sourceforge.net/projects/tapestry
Version: 0.2.2
License: Open source
Description: Tapestry is a new, powerful, all-Java framework for creating leading edge web applications in Java developed by Howard Ship of Primix Solutions. Tapestry is positioned primarily as an alternative to JavaServer Pages.
Rating: A framework that does not support Java Server Pages, plus an
incredibly slow home page. Like the Carphone Warehouse catalogue “too new to
comment.”
Expresso
http://www.jcorporate.com/
Version: 2.11
License: Apache open source
Description: The Expresso Framework is a library of servlet components for creating dynamic web-based applications. Premium commercial support cost from USD1000/year.
Expresso can work in conjunction with JSP and an extension of the Expresso
kit does support EJBs. The framework provides an object-relational database
mapper for persistent Java objects. Home page appears to well maintained
and presented. Installation documentation is sparse.
Rating: Commercially supported. Like the Carphone Warehouse catalogue “too new to comment.”
Turbine
http://java.apache.org/turbine/index.html
Version: No release yet
License: Apache open source
Description: Turbine is a Servlet based framework that allows experienced Java developers to quickly build secure web applications. Turbine is a collection of ready-made Java code and make it easy to create re-usable components (such as parameter parsing, database connection pools, job scheduling, global caches, integration with other tools such as Castor, Velocity, WebMacro, etc.) all under a license (Apache). It claims to integrate well with JSP and follows the Model 2 architecture.
Rating: Like the Carphone Warehouse catalogue “too new to comment.”
Here are email correspondences, which I had
on the SERVLET-INTEREST@java.sun.com
and JSP-INTEREST
@ java.sun.com mailing lists.
From peter.pilgrim@db.com
Subject: Re: Which is the best framework WebMacro,
Struts, or Tapestry?
To: JSP-INTEREST@java.sun.com, SERVLET-INTEREST@java.sun.com
Hi
Has anyone carried out a survey , review, or
detailed examination of these frameworks?
1) WebMacro
2) Jakarta Struts
3) Tapestry
I am interested if they work with Java
Server Pages?
Are there any others that I have missed?
Sandra Cann
scann@jcorporate.com
Peter,
I hope that
you'll check out the open source Expresso Framework too at
www.javacorporate.com. It has more than
25,000 downloads and a strong community of well over 2000 on the listserv.
Sometime ago Adam
Rossi requested information from this list, as he was doing research on
Frameworks in preparation for a presentation in Baltimore. You might have a
look at what he has on his site.
Adam Rossi,
PlatinumSolutions, Inc.
adam.rossi@platinumsolutions.com
I had similar questions about a year ago.
After creating a persistence and presentation framework for a project, I knew
there must be a better way already out there.
I compared all the major frameworks at the
time, and choose the Expresso framework at http://www.jcorporate.com. I
chose Expresso because I wanted a framework that encouraged tight adherence to
the Servlet and JSP specs, and I did not want to get locked in to a proprietary
framework that utilised, for example, templates. Not that there is anything
wrong with templates...I think they are very powerful, but our various projects
required J2EE methodologies, and it was easier to find programmers familiar
with the specs.
After exploring Expresso, I found a lot of
extra functionality that we have found very useful on our projects. The
security capabilities are excellent, including nested security groups that
allow very fine-grained access control to database objects, controller objects,
and Servlets/JSPs. Logging, server
health, persistence, and XML messaging are some of the services that are
included in the framework. These services allow you to avoid reinventing the
wheel on your projects and concentrate on business logic.
Our company has since contributed code to
the Expresso project, and it has evolved a great deal over the past year. A new
version (2.11) is now available and I would urge you to check it out. There is
an active mailing list and developer community behind Expresso if you have any
questions.
I gave a presentation at the Harbor Java
Users Group (http://www.harborjava.org) in August, which compared a few
different frameworks, including Struts, WebMacro, and Expresso. You can
download the slides from the presentation at
http://www.platinumsolutions.com/resources.html
if you are interested.
Petr, petr.jiricka@netbeans.com
WebMacro is not only a MVC framework, but
also a template language, so it's not compatible with JSP. There is a new
project called Velocity which is
basically a complete rewrite of WebMacro -
look at http://jakarta.apache.org/velocity/index.html.
Struts is a really good framework designed
on top of servlets and JSPs. It is a reference implementation of the
"Model 2" architecture described in the J2EE blueprints document.
This would definitely be my recommendation.
I don't know much about Tapestry, but
considering that the front page says that it is an alternative to JSP, I
wouldn't hope in using this with JSPs.
Craig.McClanahan@eng.sun.com
Peter Pilgrim wrote:
"Have anybody done any work with or had experience with Apache Turbine?
style='color:navy; Also I have just invested in "Web Development with
Java Server Pages" book style='color:navy'> by Fields & Klob
, Manning. Some of these framework kits are running __against__ grade by
being alternatives to JSPs. What is the deal here? Are they being anti-Sun?"
I don't think of them as being anti-Sun :-);
however there are people in the world that have legitimate issues with some of
the things that JSP allows you to do (like scriptlets, which I don't
particularly like either, and is one of the major reasons I created Struts).
In particular, some template framework
developers take the philosophical position that the development environment
should *prevent* you from mixing business logic and presentation logic.
Therefore, they reject JSP because it
*allows* such use, even though recommended development practices encourage you
not to go that way.
You might also want to remember that some of
the templating solutions were actually in existence before JSP was created and
standardized -- and in particular before JSP 1.1 made it possible to use custom
tags in a powerful, portable, way.
Won't some of these
"kits" fall off the edge of the earth in a year because they are
anti-JSP?
Some will ... some won't.
Does the market leader win 100% of the
time? If so, we'd all be running
Windows :-). If you go with one of
these frameworks (JSP-based or not), however, you definitely want to make sure
you're using an open source version so that you can continue to support your
existing applications in case the developers of your framework decide to
depart.
That all being said, Struts is going to stay
focused on developers who want to use JSP and servlet based technologies.
That combination is very powerful, and
(courtesy of the standardisation of the specifications) very portable across
different servlet container and application server environments, especially
those that also support other J2EE technologies like Enterprise JavaBeans.
Craig McClanahan
Justin Wells,
justin@webmacro.org jwells@av.com
In my view JSP has many problems. I believe
that it has more merits as a marketing effort than as a development engine. In
particular, I believe it was added to the Java platform in order to attract
people familiar with ASP. I don't believe the ASP model is a suitable one for a
language like Java.
There have been long threads here in the
past, and in other places, about the specific problems. The short story is that
JSP lets you put your business logic into your template, and that's bad. When
you try and work in a cleaner way the syntax JSP forces on you is much clumsier
than that provided by the template solutions, so you wind encouraged to do the
wrong thing.
Most of the template solutions allow you a
much cleaner separation of concerns than is possible in JSP.
WebMacro in particular expects you to
develop all of your program logic in back end JavaBeans, independent of the
fact that you may use them in a servlet. It uses bean-like introspection to
pull properties out of those beans and drop them into the template view.
As for whether it will disappear--I doubt
it, it's an open-source project with a large following. Even if the entire
development team dropped off the face of the planet the community would
continue to support it.
Yes, we are going against the grain. But
that's because the grain, JSP in this case, is flawed. Though it is a pretty
good marketing campaign and it will likely result in lots of ASP folk moving to
Java. I suppose there is some good in that.
Justin Wells
AltaVista Company, WebMacro Project
www.altavista.com, www.webmacro.org
Craig.McClanahan@eng.sun.com
Justin Wells wrote: [snip] Most of the template solutions allow you a much cleaner separation
of concerns than is possible in JSP.
Among the many threads of conversation you
will find in the archives on this topic, you will find that I disagree with
Justin on this point :-).
JSP, because it includes custom tags, can
easily *support* the same separation of concerns that template environments
like WebMacro and Velocity provide. The
philosophical difference that Justin and others articulate is whether the
developer should be *restricted* to only that approach.
This is an entirely different kettle of
fish.
[snip] WebMacro in particular expects you to develop all of your program logic
in back end JavaBeans, independent of the fact that you may use them in
a servlet. It uses bean-like introspection to pull properties out of those
beans and drop them into the template view.
See, for example, Struts
(<http://jakarta.apache.org/struts>) for a JSP based framework that has
analogous (but not identical) approach.
[snip] As for whether it will disappear--I doubt it, it's an open source project
with a large following. Even if the entire development team dropped off
the face of the planet the community would continue to support it.
The only point I would add here is that JSP
provides you choices of implementation of the specification, not just in the
functionality provided by the language. For example, if you think that Tomcat's
JSP engine is too slow, go use a servlet container that is faster without
having to give up the language in which you wrote your pages in the first
place.
Craig McClanahan
Justin Wells,
justin@webmacro.org jwells@av.com
Quoting
Peter Pilgrim (peter.pilgrim@DB.COM): I appreciate WebMacro predates JSP and we will review the frameworks by
trying them out.
Correction on
this: WebMacro does not predate JSP as a whole, it only predates the current
incarnation of JSP, and any notion of JSP having a model/view/controller
option.
I don't agree
that tag libraries are an acceptable substitute for a sound templating system,
but I don't want to get into a raging flame war with Craig again--check the
list archives for a very long discussion on the relative merits. There's lots
of room for opinion.
WebMacro Project:
www.webmacro.org
Justin
All of the "kits" are free as in open source. There is very little
commercial support for all but one of them, which is not to say that any
of these tools are bad. You cannot really compare these frameworks to proper
close source development where there is funding and guaranteed chain of
support as would expect if money changed hands. Most of open source projects
have version numbers that rarely reach near 1.0. It is not unheard of that
many a project will fall to the way side. Also many of the kits are apparently
deliberately running against grade by being alternatives to Java Server
Pages. It is difficult for small company to run against a giant like Sun
Microsystems, so what chance does a small-time developer with a little
framework have? What will decide these tools is their adoption by the Server-Side
Java communities, those developers who use these framework and then out
of their own good contribute quality enhancements and bug fixes to the
various kits. For instance to support XML or Enterprise Java Beans. The
best-supported kits will survive in a nutshell. It is, perhaps, too early
to tell which one will become the winner or be in the winner's circle in
a years time after the Java Servlets and JSP technologies have matured
more. To paraphrase an old IT procurement statement: no one ever got fired
for buying Java Server Pages.
All of the "kits" are free as in open source. There is very little
commercial support for all but one of them, which is not to say that any
of these tools are bad. You cannot really compare these frameworks to proper
close source development where there is funding and guaranteed chain of
support as would expect if money changed hands. Most of open source projects
have version numbers that rarely reach near 1.0. It is not unheard of that
many a project will fall to the way side. Also many of the kits are apparently
deliberately running against grade by being alternatives to Java Server
Pages. It is difficult for small company to run against a giant like Sun
Microsystems, so what chance does a small-time developer with a little
framework have? What will decide these tools is their adoption by the Server-Side
Java communities, those developers who use these framework and then out
of their own good contribute quality enhancements and bug fixes to the
various kits. For instance to support XML or Enterprise Java Beans. The
best-supported kits will survive in a nutshell. It is, perhaps, too early
to tell which one will become the winner or be in the winner's circle in
a years time after the Java Servlets and JSP technologies have matured
more. To paraphrase an old IT procurement statement: no one ever got fired
for buying Java Server Pages.
Gain Experience
It was decided to that we should get our toes wet.
- We should fully understand the implications of Model/View/Controller.
- We should get-to-know the technology, gain experience and under the issues
involved.
- Evaluate the best applications that would help to deliver the eMIS web
application.
We decided that WebMacro and Expresso looked to be best-of-breed of tools
in term of features, popularity, and suitability. We intended to build
on Java Server Pages with an application server. We decided to also check
out the latest Apache Jakarta Tomcat Servlets and JSP container.
The Location Web Application
I have written a sample web application that utilises Model/View/Controller
adapted to Java Server Pages and WebMacro Template Engine. There are available
online on the cedar machine. I concocted the simplest web application that
I think of, called Location. This application has a list of countries and
a list of cities. The single business rule of location is that a country
maps to the cities that are available in it. For instance if we have the
countries France and Spain, and the cities Barcelona, Paris, Granada, and
Grenoble, then Paris and Grenoble are members of France and the cities
Barcelona and Granada are associated with the country Spain.
The Model object is thus simple object that maintains a list of available
countries and a list of available cities that belong to a particular country.
The View is a JSP or WebMacro Template that renders two pulldowns (HTML
Select elements). The primary pulldown is the country and the secondary
is the city. The View fills the pulldowns with the list of countries and
the list of cities. Behind the scenes is a Controller servlet that informs
the Model when the user selects one of the options in the pull down. The
Model simply changes the available cities when the country is changed.
This examples are unfortunately are not available. However the location
model was posted as an Expresso example.
Comparison table JSP versus WebMacro
| . |
Java Server Pages
|
WebMacro
|
| Pros |
Full power of the Java language platform is available |
A template solution |
| JSPs are compiled into Java Servlets |
Precompiled into intermediate form |
| Can separate presentation and business logic |
Absolutely separates presentation and logic |
| Implemented through extended HTML tags (therefore HTML editing tools need to recognise JSP tags) |
Implemented through special token evaluation |
| Support for custom tags and libraries |
Any object, which is a Java Bean, is accessible, if it is placed in the special Context object. |
| Support for Java Beans through basic introspection. Java Bean aid the separation of presentation from logic |
Intelligent introspection of objects. Support for aggregate objects such as simple arrays, enumerations, iterators, and collections |
| Can support MVC if programmed that way |
Implemented using a MVC architecture |
| JSP is part of J2EE (Java 2 Enterprise Edition) specifications |
Syntax is very easy & simple to understand |
| A JSP can appear in normal HTML document root directory of a web server. (The web server recognised the suffix of the file.) |
. |
| Cons |
By default does not properly separate presentation from business logic |
No Java code at all is allowed in a template |
| If misused can produce illegible JSP files - an unreadable mix-up of HTML and JSP scriptlets |
HTML Presentation can only be made through a WebMacro servlet or interface |
| Syntax can be tedious |
The HTML Template is not part of J2EE specification |
| Current JSP tag have no support index Java Bean properties |
. |
| No support for aggregate Java objects |
Errors and debugging message can be poor |
| . |
Access is only allowed through the WebMacro servlet |
| . |
A web macro can never appear in HTML document root directory of the web server |
Closer look at Expresso Framework
See Expresso Framework Review
The best solution seems apparently to be Expresso Framework because it
is compatible to Java platform 2 Enterprise Edition, which is the direction
that the company seems to be heading. It supports the Java Server Pages
and the Sun recommendations of MODEL 2 architecture. Web Macro therefore
looks disadvantaged because it does not support JSP of course, and has
no built in support for J2EE. Although Web Macro can be extended to support
Enterprise Java Beans and Server Side applications it would mean a solution
that we have to carry as a passenger. In other words we would have to support
these customisation and extension. On the other hand Expresso seems to
have active list of developers and contributors who already acknowledging
J2EE support and compatibility. This means we can leverage of them and
conversely we can return the favour. Struts in more a web application toolkit
and is not a web application framework. For example there is no database
object persistence in Struts. The other web frameworks like Tapestry and
Turbine could also be decent frameworks. However their sponsors seem to
be too busy fighting the "big fight" and egos. They could be
good or have considerable much better technology than Expresso, but their
situation is marred when they stipulate they are indifferent to Sun's
vision.
http://ootips.org/mvc-pattern.html
A good read for the Model View Controller
design pattern
http://www.object-arts.com/EducationCentre/Overviews/MVC.htm \ This is another on-line paper about MVC
with illustrations.
http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc_p.html
This page has a comprehensive explanation
of the pros and cons of MVC with JSP. This approach is also known as the
so-called Model 2 Architecture.
http://www.flashline.com/components/appservermatrix.jsp
This page takes ages to download but is
worth it because it is Application Server features matrix.
http://java.apache.org/turbine/model2+1.html
This page about MVC in relation to the
Turbine web application framework.
http://jakarta.apache.org/tomcat/index.html
This is the home page of Apache Jakarta Tomcat project. This is the reference
Servlet container for JSP 1.1 and Servlets 2.2.
The End
|
