Recently we have decided to port an old application into 100% java. That old application was weird to say the least: it had ASP front end and Java server side logic. The communication was done through RMI. Having to fix a simple cosmetic problem was like trying to swim in a warm noodle soup. Relying on that app is a disaster waiting to happen.
A little background: we already ported a web app in the same condition. The new app was re-written in Spring MVC. It works ok for this app since it is a more point-and-click app. It wasn’t perfect, but it worked. (Read the article on which types of apps suite best to which MVC frameworks here)
The app we are porting is more like a desktop application and is all about business process to the core.
So… since we already have Spring MVC in place and ready to go, it was only natural for us to go one step further and get WebFlow. Now, WebFlow and Spring MVC don’t have support for AJAX and we really want for our users to enjoy the benefits of tiny background server requests that make their experience seem like a magic show. Having worked with component based framework before and realizing the potential, I suggested Wicket.
Unfortunately, not all the people felt the same way. So, we decided to 1) brainstorm a list of things that are important for us in a framework. Then 2) we had 1-7 points out of 7 points to assign any feature that was more important to us (i.e any feature can get 1-7 points, each person has 7 points to spend) This gives us the list of 3-4 features most important to us. Then 3) we evaluate the frameworks based on the most important feature set. The way we evaluate is by taking a small module from existing webapp (the one we are porting) and re-writing it using SWF and Wicket. In our scenario it was creation of a business object that has the following properties: name, description and list of email addresses. Here is the scoop of what had to be done.
List of things that are important in a web framework
- Handle complexity of a work-flow
- How easy it is to create a new feature? Flexibility with changing requirements
- Learning curve: Learning to use the framework and learning the web app from the stand point of a new developer
- Testability
- Ease of development, debugging including integration
- Re-usability/Components
- Support/Ease AJAX
- Security
- Support for other frameworks
- Separation of View (HTML) and logic (Java)
Vote: which things are important the most. Preliminary analysis.
The results of the vote were interesting you would think that some “preached” about features would be chosen. (I.E testability or even re-usability) I have to say that the rest of the group was leaning more towards SWF, because they knew Spring MVC and it was a short leap. I, myself was trying to push wicket.
So here is the results of our vote (doesn’t really give wicket a good chance, but you have to deal with what you got)
Handle complexity of work-flow
SWF
It seems like in order to create something in web-flow we have to come-up with the diagram right away. Since XML is not a very friendly way of creating prototypes it might be a problem to create a fresh flow using round-trip engineering :
(UML <-> Code)
However, when porting an existing web app with preexisting flow, it might be easier because all you have to do is create a structure using XML definition and then write your logic.
Also, at the end it is easier to get the “birds-eye” view of the flow then it is if you had to read multiple Java source files: everything is in one configuration.
Wicket
It easier to whip out a web app from scratch in wicket. You can create a prototype very easily just by creating wicket links in markup files. It is very easy to simulate complex dynamic behavior so. Then we could potentially use some UML toolkit to create diagram and do (UML <-> Code) loop much easier! So, in this process wicket contributes to a more productive, learning experience what OO programming should be. It is much more fun (speaking for myself)
However, at the end you end up with a multiple java files that are not connected with each other only by means of links embedded in code. You don’t have have the “bird’s-eye” view.
Now, to people that now a little bit about wicket, I know that you are going to disagree with that. Wicket provides a wizard that can be used to connect pages together.
To this I can say that is true – it can, but…
Wizard only provides linear state transition behavior. That is to say that it IS NOT a state diagram. A state diagram resembles a tree. A wizard resembles a vector. There is a little comfort pillow in the wizard is that you could conditionally skip steps. That would be perfect for a some less complex business models, but not for others.
Ease of development/debugging including integration
SWF
In SWF we go from XML to java to jsp (not necessarily in that order). JSP and XML are 2 things you want to avoid as much as possible during development because they are
a) hard to test b) hard to develop in
There is advantage in debuging a production application if it uses JSP/XML., because you could switch jsp files dynammically of fix a bug in XML without redeploying in production.
Some people might lean towards that pillar when defending JSP, however there is inherent wrong assumption that JSP contains business logic that need to be changed. If that is the case, the problem is more of a bad design of the application.
Wicket
You deal with java in wicket 90-100 % of the time. The only time you have to touch a mark up file is when you want to create layout for you component. All the data modeling and business logic is done in java code. So, time distribution for every layer for SWF would be something like this:
jsp-25 -33%
xml- 25 -33%
java – 33-50%
That is of course depends on how well you know spring and jstl
Meanwhile for wicket it more like:
xml – 25-33% *
html – 5%
java – 62-70%
*Yes you can have spring with wicket!
If you assume that productivity and satisfaction increases with working with a real programming language, you see why wicket wins here.
Also, should mention that java is much easier to debug than a jsp.
How easy is it to create a new feature? Flexibility with changing requirements
If the requirements include changes enhancing user interface and anything to do with ui I think Wicket would be a winner. If the requirements would include business changes to work flow I think WebFlow would win because that is what it is made for. Let me clarify: I mean “out-of-the-box”. You could write your own workflow model in wicket easily. In fact I wrote one, just to prove the point.
If the requirements would include anything else, I would say they would be roughly the same (I mean in the scope of an average web application with business services, persistent layers and other good stuff like config files, deployment scripts) I am not aware of any differences that either Spring MVC + WebFlow or Wicket has
Support/Ease of AJAX
There is no doubt that Wicket wins here hands down. And here is why. The heart of Spring MVC and WebFlow are controllers. So in a sense you are tied into using them for the client-server communication required for AJAX. However that is not all you have to do. You have to write some javascript or use some library (prototype, yui) to call the server for data. The weakness of this approach is
You have to keep your server model and your javascript in synch
Because javascript domain the DOM and server domain are the business objects. Javascript’s task hence should be to keep the form state up-to-date with the server business model. Therefore, this approach is not modular because javascript has to know how to map the server state into the gui, form state as seen by the user. This is a mess. There are approaches to handle it, such as jason. It does solve the problem, however the solution is too complex from my perspective.
So why do we need javascript? Because controller doesn’t provide a call back mechanism. It does provide you the binding to the model when the user changes something in the form. However, if an event occurs on the server, there is no way to change the form as seen by the user. So, controller works only one way. By the way this is the way it is suppose to work as follows from MVC architecture.
What follows is that if you want to develop rich, stateful web applications MVC approach is not your friend. The reason is the same as the reason why MVC is a great architecture in the first place. It separates the view from controller. What you really need to accomplish the task is something that ties View and Controller into one. Not one like ModelAndView class, because that class doesn’t really help with the behavior of the view. But something like a Component that has hooks inside for you to get the behavior that you need without compromising your design.
Why do we grab onto the MVC approach then? Why is this a default architecture to use in web application development? Why are we scared to get away from it?
I think (and I know several people who agree with me) is because way back in the dawn of the web application development the pages consisted of ugly macaroni goo of display logic mixed with business logic. That is why MVC came into place to separate the concerns and give every domain to it’s rightful owner. However, the usual jsp, java mix doesn’t really accomplish the task, because jsp is not strictly speaking a view only resident. It is a controller as well. And sometimes (and it is very bad) it is the business model.
So, what does Component based approach offer you that MVC approach doesn’t in terms of rich web applications?
Ability to reuse your code
If you adopt the Component view attitude, you can greatly improve your code reuse. If I write a class called SuperCoolAjaxPageNavigator i can reuse anywhere in my application. Wicket provides a very easy way to integrate components into your pages by simply specifying “wicket:id” tag on your page. You don’t have to configure your widget from the view (”jstlTag:formatDate fmt=”X%DI^&*()U@*”) – what a pain! You simply do the same thing only in java code and your parameters become your unique class, which can be reused anywhere! You don’t have to import the libraries and worry about forgetting importing them will cause an unknown problem which will take you couple valuable boring hours to discover just because it is hard to debug jsp pages! You don’t have to worry about incompatibility of jars that contains the tag definitions!
Speed of development complex components though using OO principals
You can truly exercise the power of OO that is in your hands when you design a component. Hence the speed of development. Also, speed of development comes from the fact you are using a high-level programming language an mostly just use that. You don’t use any extra technologies, with exception of a little HTML. I think utilizing OO is only useful when it really helps, otherwise what is the motivation to go through all this pain of breaking the system into Objects and interactions between them, just create a workflow and then write methods to handle them. However, we know that with increasing complexity of application, that approach will not work because it produces high-coupling and causes the system to be virtually unmodifiable without breaking a little part of it every time it is modified. So, it is good to use OO if you are doing something long term. It is good to use a technology that has a degree of freedom sufficient enough to allow it.
Code-off: Flow diagram of a sample module
Tags: Frameworks, WebFlow, Wicket
