The big lines
Mixing framework, assembling stack
The "stack" maybe what will drive attention, we are seeing
consolidations around SUN, RedHat, SpringSource (ECM), Apache, IBM and Oracle stacks. Maybe we
won't choose a Web Framework, but a stack. It is simple and reassuring
to choose a "SUN stack" or a "RedHat stack". You get a clean way from
the OS to the IDE, but since it is standard based, you are not locked
in. Note that there is a emerging Google Stack that would be GWT,
Guice,
SiteBricks ...
Some frameworks can work together : they are not a single block of code. Some other focuses just on a part of the solution (like JPA for persistence) and you have to wire them together.
For example : Seam is provided with a JSF frontend, but you can use Flex or JavaFX instead with
Flamingo (Exadel). GWT, WaveMaker or JavaFX are just a frontends : you have to wire them with a server backend.
There is a market to help you wire up and supports your custom stack:
- AppFuse is a quick start templating system. It will allow you to quickly start an application using a mix of some of the Java Framework.
- SpikeSource provides and supports a certain set of stacks
- SourceLabs too.
Each framework advertise its capability to use and integrate with other components. It would be fun to make a kind of integration matrix.
Action or Request based
In essence they give you the ability to map URLs to activities and code on the back end. Here, the layout and workflow tends to be more page oriented. As a developer you tend to interact with the HTTP request cycle directly.
Action frameworks tend to be much "thinner" in how they stand between your code and the raw HTTP request compared to component frameworks.
Old School HTTP wranglers may simply be more comfortable with action frameworks, simply because they've been through the crucible of understanding how HTTP requests are structured.
It is also known as the "command pattern oriented" architectural style, where you flow all incoming requests through a processing pipeline.
Component based
In a component framework, artifacts that are rendered on the page are initially developed as individual components, much like in modern GUI libraries. You have components, they have events, and your code is written to work with those events against the components.
Most of the time, in mainstream development, your code is pretty much ignorant of the HTTP request cycle and processing.
For those people just cutting their teeth on web development, the component frameworks (especially with good tooling) can be much more approachable, as the tools tend to hide the heavy weight nature of the component frameworks.
Component mustn't be confused with taglibs and jstl. They don't offer the granularity of control or events that a full bore component framework offers. And also, tag libs are JSP specific, whereas JSP is a only one of many rendering options. With the action frameworks, the rendering mechanism can more easily by separated from the actual back end framework.
Conversation or stateless
Some framework features "conversation": it is the ability for the client to open multiple browser windows or tab without messing around the server. Seam, Shale, Spring MVC and Oracle ADF provides conversations. It means that the server has to know the client's state. Then there is a debate: how and where to manage this state. Either keep the Java Tier stateless and put the load on the database tier (and the network) (advocate: Rod Johnson/SpringSource). Or use a stateful Java Tier (eventually with JavaEE help: cluster, session replication ...) and don't communicate about user's session with the Database Tier (advocate: Gavin King/Hibernate/Seams/JBoss). Also note that has memory gets cheaper, the stateful solution looks more and more appealing. There are even solution like
Terracotta that builds big Java cluster.
Note also that "conversation" is only one way of naming a feature. Spring MVC has "Web Flow" that allow the same feature, but with a different way of expressing it.
RIA framework
This is where the line is blurred between server side and client side. Some are "pure client" technologies, some are "server side".
Client Side plateforms:
-
Browser:
- developed with Javascript: WaveMaker, Tibco GI.
- developed with Java: would GWT and ZK fit in this category ??
- developed with XUL specific to Mozilla
-
Flash: Flex (not fully open source)
-
Java: JavaFX, Swing
- Curl
Choosing an Ajax Framework by Matt Raible 01/2009.
A comparison http://spreadsheets.google.com/pub?key=pp3jFs585J_Uf-qN3IKDEFw&gid=0 .
Note that OpenLaszlo target both Browser and Flash with a single source code.
Some are server side techno that generates client side code :
-
JSF: IceFace, RichFaces
- ZK
The features
Overall application architecture
Basically they all share MVC or at least a front controller.
On the MVC pattern
The term MVC is a bit
overused in the web Framework area. Basically it means separation of
concern and loose coupling, but not more. Some may try to give more
precise pattern, like front controller or MVC type 1 or 2 or passive
MVC ... whatever. It becomes a problem when it is use as a "quality
label": Good MVC architecture.
MVC depends on how close you look
at the system (think about fractals) : typically you will find MVC on
the AppServer : EJB / JSP / Servlet. And on the Browser you could find
: REST / HTML+CSS / Javascript. Even at a high level (it is more layers
architecture than MVC design pattern) : Database / Browser /
Application Server.
GUI Architectures
from Martin Fowler (2006) "There have been many different ways to
organize the code for a rich client system. Here I discuss a selection
of those that I feel have been the most influential and introduce how
they relate to the patterns." A reflection on what is the MVC pattern
and some variants.
Design Patterns for Building Flexible and Maintainable J2EE Applications from Vijay Ramachandran (2002, Sun) : MVC pattern from a J2EE point of view.
Removing The Model-View-Controller Straitjacket
Static and dynamic markup (Tag Soup problem and template solution)
This is a recurring problem in the HTML case. I will shamelessly point to Web development as tag soup.
Let's say straight that Servlet and JSP are dead.
Solution proposed :
-
Typical HTML templates. (Note that if the graphic designer remove the "unknown" attributes, you are screwed) :
-
Template Attribute Language : TAL (mostly Python, but there are Java implementations)
-
XMLC (Java).
-
Tapestry offers an HTML template with custom attributes that can be manipulated by graphic designers and developers.
-
JSF with Clay : "... Clay unabashedly copies Tapestry's innovations ... mockup HTML tied to JSF components ..."
-
Wicket templates
- General purpose Java template solutions:
-
Google XML Pages (GXP) Not very impressive yet. Would have to be coupled with some tools or IDE to be compelling.
-
-
more declarative language : XForms ...
-
Use an all in one IDE + framework (JSF, JSTL ...) : Netbeans, ... This is great if the developper is the graphic designer too.
This problem happen only if you generate XHTML on the serverside. You
avoid this by using JavaFX, Curl, Flex or pure Javascript clients
(Wavemaker, Tibco GI ...).
There may still be an XML generation problem, but it is an order of
magnitude simpler, since generally the XML data will be much simpler
and specialized than the XHTML one.
View
tier component model
How are view tier element represented ;
How are
they bound to the model ;
How about validation and conversations
See also RIA .
Mapping requests to business logic
Logical mapping from request URL to logic classes ;
request processing lifecycle
Model tier resource access
like JNDI for standard JavaEE or dependency injection
Page navigation
Logical outcomes ; view identifiers ; centralized XML config file ; direct URL
Form validation
like reusing Hibernate annotation
RestFull style
How easy it is to develop RESTFUL services.
For example early version of JSF wasn't well suited for RESTFUL interfaces.
Presentation, layout management
This can be "plugged" in
almost every kind of framework. It concerns just the "last"
presentation layer what we could call "decoration".
Layout Management:
-
SiteMesh (OpenSymphony) It acts as a filter.
-
Tiles (Apache) mainly used by Struts and Shale.
CSS decoration:
Multiple clients (web, mobile ...)
i18n
Association and possible combinations with others frameworks ...
RAD and developers goodness
Testability
mockup, out of container testing ..
Round trip latency
Remember when you had to compile the whole application and redeploy just to see a tiny HTML adjustment ? Groovy do not need to reload ..
Debug
How easy it is to debug and step through the code ?
How
clear are the error messages ? Do they point you to the right line of
code ? (and not to an intermediate auto-generated servlet ?)
For example GWT allow to step through your Java code even if it is the Javascript that is executing on the client.
IDE
An IDE can help for:
- Graphically designing JSF pages (drag and drop components from a palette)
- Graphically defining the "page flow" or "navigation flow"
- Auto-completion for XML formats and Code.
Be careful, the IDE or the plugins are generally not free.
Non functional requirements
Deployment
Scalability
cluster, EBJ3 ...
Security
Does it provides out-of-the-box: CSRF, XSS, XSRF protection ?
How authentication and authorization are addressed?
Fail-over/clustering
The paradigm shift : SOFEA (SOUI, TSA), XRX
The home would be :
Thin Server Architecture where you will find articles and examples.
Graphic from the Matt Raible presentation :
Hope the graphic allow to quickly get the idea. Notice that the client could be JavaWebStart,
JavaFX, XUL, XForms/XHTML, Flash, AJAX (typically
WaveMaker and
Tibco GI ) ...
There is an interesting debate : See
SOFEA/SOUI Raible Design, with headlines like "Web frameworks peaking toward obsolescence ?"
InfoQ asks Does the rise of Service Oriented UI (SOUI) means the death of server-assisted MVC? A similar thread was started on JavaLobby last week: Web frameworks peaking toward obsolescence. A month ago, TSS posted a whitepaper titled Life above the Service Tier.
Another article surfaced :
Rationalizing the Presentation Tier in InfoQ by
Ganesh Prasad, Peter Svensson on Jul 04, 2008.
Jersey implements JAX-RS and it may be the only server side component you need to expose your application to the web.
RestLet : Lightweight REST framework for Java.
Appcelerator : Message Oriented Architecture : ALL behavior is governed by simple lightweight messages
Flex and GWT also fit in this category.
XRX : XForms+REST+XQuery.
XRX: Simple, Elegant, Disruptive seminal article May 2008, towards declarative programming.
Leaded by
Dan McCreary see his
blog on O'Reilly and also
Google Code Wikibook.
I am not really convinced with XQuery. All this XML handwritten and mixed in the code is ugly, heavy weight and error prone. If you look at the new JavaFX or RelaxNG syntax for example, it shows that things doesn't have to be this way.
The framework "short" list
See Spreadsheet:
Java Web Framework .
Not in the list
-
WebObject isn't Open Source and his Open Source clone Wotonomy is almost dead.
-
Oracle ADF is based on JSF. But is not OpenSource. Note that there is a free (to download) IDE too: JDeveloper.
-
Cocoon (Apache) is more an XSLT and XML pipeline framework than a Java one.
-
AppFuse is a quick start templating system. It will allow you to quickly start an application using some of the Java Framework.
-
And many more ...
Model driven architecture on rails
makes creating Java EE applications as easy as ruby-on-rails, but with
all the power of JEE and UML. Business models are defined using
simplified UML diagrams following well-defined conventions. These
models are then used to generate the exact same ejb3/portlet code your
would write by hand. Then use the code as is or modify it as you see
fit and your changes will be preserved. Taylor
consists of a set of Eclipse plugins for simplified UML modeling and
the generation of JEE code such as: EJB3 entity and session beans,
JSR-168 Portlets, and JMS-based business processes. It leverages many
other open-source tools instead of reinventing the wheel. Mainly Seams.
JMatter
A Swing / Web Start framework on the way to becoming a Web Framework. Again a MDA approach.
Short History
Struts 1 (Apache)
The most successful framework that ever existed. One would argue that it may be more due to industry conservatism than technological qualities.
While coding, the developer has to look and take care of, at least, three files at the same time. And how these three files are connected? With
SOP -
String Oriented Programming. Yeah. He/She has to create an ActionForm (Java) and/or an Action (Java), declare it in struts-config (XML) and code/maintain the webpage (JSP: Java, Tag Libraries, HTML, etc...). And all properties, names, etc, are binded by typing their names/ids in fields, like:
struts-config: [..] name="myProperty"
Java: getMyProperty()
JSP:
JavaServerFaces
References :
Wikipedia ;
Sun's Home ;
Implementations ;
JSF 2.0 Specification JSR-314 (
JSF 1 Specification JSR 127) ;
SUN Reference implementation (Mojarra) ;
Apache MyFaces implementation ;
JSF is a framework by itself, but it is integrated in a number of other frameworks like Seam, Shale, Struts-Faces integration library for Struts 1.x, JSF integration plugins to the controller for Struts 2.x ...
The support is great : IDE (Eclipse, Netbeans, JDeveloper) ; Web sites ; forums ; ...
Availability of ready made components in JSF based rich frameworks (ICEFaces, RichFaces and a few others) is where it pays off. You can't easily mix and match components from different JSF based frameworks yet, but hopefully it will move towards that.
The criticism that you need other frameworks to make JSF usable completely misses the point. JSF was designed for extensibility, and frameworks like Facelets and Seam take full advantage of that to add new features to the framework, such as advanced view composition, binding UI components to EJBs, and much more.
JSF 1.0 started in 2001. On the slowliness of the JSF standard : at this point, JSF's advantages and disadvantages are very well known. And, OSS has done so much to help JSF (Facelets, Seam, Orchestra, Spring Web Flow, Shale, etc.) . Even though JSF as a whole must go through the standards process, OSS has build an amazing set of capabilities _on top of a standard_. Some of these fill in deficiencies (like many parts of Shale), and others add whole new capabilities (Comet features of ICEfaces).
Conclusion
Hope that you learned something. Obviously I won't make any recommendation : choosing a framework involve some work of you. Documenting and discussing the rationale of your choice is part of that process. Reading at least the 3 presentations from Matt Raible in 2007 is quick and fundamental.
Be careful : this document will be outdated in a few days ... So the most important is the following chapter: references !