The Choice of the Web Framework

The Choice of the Web Framework
Aaron Yuan/2005.12.26


0. Preface
Now, the web frameworks bloom in every aspects[1]. This is can be a good thing, but on the other hand, this also make people confused on choosing the correct one to be based on for their application. So how to do the choice? This article tries to give some useful hints.

1. Category
We can classify all the the framework as the browser-centric and java-centric. Of course, we will build the business layer and database layer using java, such as spring and hibernate or EJB3. The key point lay on the presentation layer. Now we have many choice, the most common is :Struts(Action), JSP(JSF), Tapestry, Applet, WingS(webonswing,etc.), webstart. We can draw a line from java-centric to browser-centric,
and every framework should be one position.

JWS(Xito,JDNC,JDIC) Applet WingS(webonswing) wicket JSF(spring MVC,Struts), Tapestry
java----------------------------->----------------------->---------------------->------------Broswer

Note: Broswer-centric mean the most presentation job is fulfilled by XML/HTML. And this is the mainstream of the world now.

2. Compare
Here is a compare matrix which I come across on the net. Sorry I just can not figure out the specific location.

Factors Applet XML/HTML based JWS

User Interface moderate-sophicated simple-moderate moderate-sophicated
Offline Support No No Yes
UI Response Network Independent Network dependent Network Independent
Interactivity Broswer Limited Broswer/Make-up limited Open
First Use Response Minutes Seconds Minutes
Subsequent use response Minutes Seconds Seconds
Bandwidth Usage Variable Fixed Flexible
Lightweight client support Limited Open Limited

From the matrix above, we can see many advantes the JWS plan over the others. So why people sitll insist on developing the web service based on the XML/HTML? We can see that that's only one reason: make the user the most convenient. For they do not need to install the java SDK or waiting for a while before they start an application caused by the limit of bandwidth. And from these analysis, we also can understand why AJAX(Asynchronous JavaScript And XML) will populate today. Javascirpt is ugly from my
view although some guys will laught at me for that. I love the pure java system. It can be rapidly development and if the architecture is elegant enough, the maintance can be a kind of joy. We can imagine we can develop the same system like what we have, just get rid of so much jsp, xml, html ,css....

3. Thinking
Html and Browser is made to present the static the text and the Http protocol is also sessionless. So we will make overhead use of it if we just wanna build the application based on it. Why not shift to java platform? I just can not fiugred out. Ruby on Rails? Asp.Net? LAMP? maybe... I just think if the java community is more unify...maybe the world will be better.....

In my opition, with the bandwidth growing, the downloading will not a burden, so my choice will be: RIA. On how to do with it, there are
FLEX
XUL(Lazlo)
Swing
AJAX
I need write the action script for FlEX or javascipt for AJAX, I do not like that style. As for Lazlo, I still need do that job. I choose Swing. But there are sitll two methods,to use swing: on the server or on the cilent. The reprents of the former is:
Echo(Echo2)
WingS
SwingWeb
WebOnSwing
This type solution is cool, but not so applicable. Basicly, They all wrap the servelet using all kinds of method. So when the http requests arrive, the response will generate the html to form the swing-like web. this will comsume a lot of time and brandwidth.
The reprents of the latter is so many, so only superstar will be choosed here:
SwiXML(SwiNG,SwiAT)
CookSwing(CookXML)
JDNC(JDIC SwingX)

I still choose JWS, but with a little XUL to do the form designer like cookSwing or Thinlet project.

another concern: If we give up the based j2ee server or even webserver(at now, we still use it). Where is the socket? Because the client side have been located in the romote client machine, not like jsp like file (which located in the server), so how to fulfil the basci communication? HTTP? socket? RPC? RPC in fact in based on the socket. While HTTP will still be used. According to the spring spec, it can support the following
4 choice:

Remote Method Invocation (RMI). Through the use of the RmiProxyFactoryBean and the RmiServiceExporter Spring supports both traditional RMI (with java.rmi.Remote interfaces and java.rmi.RemoteException) and transparent remoting via RMI invokers (with any java interface).

Spring's HTTP invoker. Spring provides a special remoting strategy which allows for java serialization via HTTP, supporting any java interface (just like the RMI invoker). The corresponding support classes are HttpInvokerProxyFactoryBean and HttpInvokerServiceExporter.

Hessian. By using the HessianProxyFactoryBean and the HessianServiceExporter you can transparently expose your services using the lightweight binary HTTP-based protocol provided by Caucho.

Burlap. Burlap is Caucho's XML-based alternative for Hessian. Spring provides support classes such as BurlapProxyFactoryBean and BurlapServiceExporter.

JAX RPC. Spring provides remoting support for Web Services via JAX-RPC.

JMS (TODO).


if they have not so.. i will try one: cookSwing+JWS+spring+hibernate.
______________
[1]: Echo Cocoon Millstone OXF
Struts SOFIA Tapestry WebWork
RIFE Spring MVC Canyamo Maverick
JPublish JATO Folium Jucas
Verge Niggle Bishop Barracuda
Action Framework Shocks TeaServlet wingS
Expresso Bento jStatemachine jZonic
OpenEmcee Turbine Scope Warfare
JWAA Jaffa Jacquard Macaw
Smile MyFaces Chiba JBanana
Jeenius JWarp Genie Melati
Dovetail Cameleon JFormular Xoplon
Japple Helma Dinamica WebOnSwing
Nacho Cassandra Baritus