Michael has posted 1 posts at DZone. View Full User Profile

Choosing a Framework for the Enterprise

  • submit to reddit
My company has just created an architecture team to help standardize our programming tools and application design. It’s a small but growing financial company and we have 50 or so developers on staff. Most of our Java apps are built using Struts 1.x with a custom ORM and hibernate handling the data. Recently it was decided to add Spring MVC to the mix but nothing much has been developed using it. We tried once before to agree on a web framework but could only agree to allow Flex to be used for some apps. Since then, we’ve built 2 Flex apps, with another one in development. We also have some .Net apps that use the entire MS data stack SSRS, SSAS, SQL Server and the Telerik controls.  

Our architecture team has proposed a json web service model utitlizing jQuery and JSPs for constructing the view. ExtJS is also being considered but currently not approved. This model makes the server side framework less important and takes us toward writing more JavaScript on the client side.

I should add that some of the apps we are creating and maintaining have been around for as long as 10 years or so and are expected to be around indefinitely. Also, we’re mostly talking about internal web applications.

The opposition to the architecture team's proposal contends that the jQuery and JSPs are not a comparable replacement for Flex and not even ExtJs is a comparable replacement. What’s being asked for is Flex for applications needing rich UIs and a full stack framework (Grails, Play, Stripes, Struts2 , etc, pick one) when Flex is not a good fit  or a full stack framework with a rich component library and component model - something like Seam or Vaadin. There are additional concerns about maintaining large codebases of JavaScript and the debugging and profiling of JavaScript heavy applications - as compared to something like ActionScript and Flex, or a JSF based component model.

I have a few questions that I’d like to get feedback on.

Is jQuery (and all of its plugins) a comparable replacement for a component library (and component model) provided via something like JSF, Vaadin or the components available in Flex ?

Secondly, have you adopted the restful model w/an ajax frontend for large internal projects ? If so, how did it go ?  Is this model well suited for enterprise development ?

What would you propose for an organization with demands for all type of applications: large, small, reporting, charting, dashboarding, some needing really quick turn arounds, others needing a high level of testing, some needing rich responsive UIs, some having short lives, while some could be around for many years.
Published at DZone with permission of its author, Michael Ellison.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mihai Dinca - P... replied on Tue, 2011/09/13 - 2:16am

First I think you should consider your people knowledge. Do they know better JavaScript? Are they more comfortable working with OOP? There is no single answer for a set of projects. The best solution, if your number of developers is big enough, is to have have at least two different web frameworks used inside the company. Not all web applications need rich UI. Some management tools or even some business applications do not need those.

I like Wicket framework , because it offers a lot of advantages for Java developers. It was succesfully used in big projects.

Because you talked about reporting, charting, dashboarding, you can see NextReports Server (created with wicket)

René Jahn replied on Tue, 2011/09/13 - 2:47am

I agree partly - Mihai. But sometimes you have to use different technologies to solve your problems. It is important to know who the users are and what problem your software solves. If you need desktop like web apps, it is possible to use vaadin, qooxdoo or extjs/gxt but you need a lot of development time, a framework mix (and you need many developers with different know how) compared to Flex or Java RIA development.

If you write frontends, it should be a browser based solution. The "right choice" depends on your needs (performance, UI controls, scaling, ...). For backend apps, the technology does not matter, use a full stack app framework that saves time.

Decide what kind of apps will be created. Determine the user group. Define teams with concrete evaluation results. Reduce complexity. Don't mix all available technologies because it is so difficult to maintain. And do not overlook the migration effort of existing apps

The full stack application framework JVx would perhaps also worth a look. Have you seen VisionX in action?

Guido Amabili replied on Tue, 2011/09/13 - 2:49am

I can speak for myself and for my personal web application projects I have choosen Wicket and JQuery.

The feature I like the most of Wicket is the templating capabilities. Basically there is a clear separation between the markup and the logic. 

And JQuery is an incredibly powerful Javascript framework. Plus you have the jquery ui components.

And it's easy to integrate with Wicket.

  Restful web services are on my radar, but didn't try to integrate some restful services but shouldn't be too complicated. The most work would go into authenticating and authorizing, sharing a session maybe between restful web services layer and the wicket layer.



Marcus Bosten replied on Tue, 2011/09/13 - 3:55am

We reached the same question in our Team (6 Developers) .
And as Mihai proposed we have taken a look into avialable developer skills - and decided to use Wicket.
Project development is ongoing since July - it looks really promising and we are all really happy with Wicket.

By the way:
You can easily mix in JQuery (or Wiquery) into Wicket.

Best Regards,

Andrea Del Bene replied on Tue, 2011/09/13 - 4:36am

I'm also very satisfied with Wicket. What I like most of it are:

  • easy integration with JQuery, both "manual" or via other frameworks (like Wiquery)
  • good object oriented abstraction of web entites like pages, form components, etc...
  • no special tags needed. You can use just plain HTML
  • VERY vivid community




David Walters replied on Tue, 2011/09/13 - 9:02am

After recently reviewing several traditional and also current frameworks, from Struts to GWT, I would absolutely go with Vaadin; Good community and updates, good UI components, many addons, pure java all the way, no JSP/HTML/javascript, no RPC/Ajax coding to do, simple setup, small footprint. Fast time to market, and simple to maintain. -There is also a side benefit that java Swing coders with little web experience can migrate with little effort, and legacy Swing apps can be migrated.

Henk De Boer replied on Tue, 2011/09/13 - 1:33pm

Of course everyone has his own favorite (web) framework.

We evaluated many frameworks lately, including some non-Java variants but came to the conclusion that JSF, especially as part of the Java EE stack is the best choice.

Templating with JSF via Facelets is very clean and powerful. Creating your own components is very simple by using the composite components feature. It's very simple to get into, and there is first class support for converting and validation incoming GET parameters. There are a huge amount of component libraries available, that cover a lot of basic and advanced needs.

Via the mentioned composite components together with the resources support, it's really easy to just put your own jquery code and markup in a simple template file and bless that as being a first class component. Very powerful stuff!

It's also possible to work completely in Java with JSF, see the link that was posted on Dzone yesterday: Authoring JSF pages in pure Java

Slava Imeshev replied on Tue, 2011/09/13 - 2:37pm


I think the best way to address that task is to apply common sense and select frameworks that would solve burning problems in development and production.

I agree with your concern regarding maintaining a large Javascript codebase, and I would like to expand it a bit.

  1. Javascript is not strongly typed, so the best way to detect errors is to actually run it.
  2. Javascript code is hard to unit test, particularly in multi-tier applications.
  3. Javascript is inherently insecure as it it exposed to the client that can do whatever it wants.

Also, it seems that your architecture team tries to use a top-down approach and dictate engineers what to use. This might be a problem as it may make things worse because people will have to learn a lot of new stuff and new often means bugs and frustration, especially when not called for.  I'd rather find what are the pain points in development and production and try to solve those. A lack of standardization doesn't sound like one.

Speaking of Spring MVC, you need to keep in mind that it adds another level of indirection, so there will be a steep learning curve. If you don't buy a support contract from VMWare, owner of Spring, your teams will end up scouting internet even when trying to solve trivial problems. Books on Spring cover only very basic cases for Spring MVC. Of course, YMMV, but I've been there and it wasn't fun.

Based on what you've told us, I'd recommend looking at Struts 2 with a combination of whatever Javascript libraries your engineers are comfortable with. Your organization is  already  using Struts 1, so they may like a cleaner, easier to work with architecture of Struts 2. Also, unlike Struts 1, Struts 2 actions are very easy to unit test which is a huge bonus. There is a great book on Struts 2, Struts 2 in Action.

I wouldn't try to limit use of Javascript frameworks - let developers use whatever they are most comfortable with, that is a good recipe for quality code.

I think if you apply common sense approach to this and try solve burning problems instead of just picking 'best frameworks', you will be fine.

Hope this helps.

Slava Imeshev

Cacheonix | Reliable Clustered Java Cache

Bruce Phillips replied on Tue, 2011/09/13 - 2:44pm

I enjoyed programming in ActionScript 3 and Flex but because of Apple's continued opposition to Flash on the iPhone and iPad I've moved away from Flex.

I've had good experience with Spring on the backend and JQuery on the front-end. 

As HTML 5 becomes even more widely supported, the need for (and support for) Flex will likely lessen.

JSF 2 and JEE 6 are also good combinations.  There are several JSF 2 frameworks that are providing sophisticated user interface  components. 

With any of these combinations (including Flex) you can use a RESTful backend (Spring makes it pretty easy to implement).  One challenge you may encounter with REST is securing your RESTful services so only authorized apps can access them.  Spring also provides some built-in support for that.





Jonathan Fisher replied on Tue, 2011/09/13 - 4:44pm

Standards are worthless. They're the output of control Nazi's that no longer can contribute value to a company. Telling someone "Struts 1.0 is our standard" is like telling a mechanic "you can only use a screwdriver to fix my car, no wrenches. Sorry, but wrenches aren't approved"

Instead, gather your lead developers into a large conference room. Start by enumerating the types of challenges you will be facing in the future. Next, discuss the client technologies you would _wish_ to solve those with. Take notes from the feedback because those are your choices.

Finally, with your architecture team, develop a "Target Architecture". Push this to your developers and says, "your applications should be within 75% of this." Give them options. If someone needs to deviate from the architecture to meet requirements, let them.

What you'll end up with is applications that look extremely similar, rather than a ton of hacks slopped together because the "standard" wasn't up to spec.

Shay Shmeltzer replied on Tue, 2011/09/13 - 5:13pm

As people mentioned a lot depends on what you are actually building, what is your developers background, and also what companies are you willing to work with.

One thing that always bother me about this type of discussion is that people look at just one layer of their applicaiton when deciding on an architecture. So you get some people talking about the UI layer, some other about the controller layer, some about the O/R layer. And then when you choose a separate framework for each of those you are left with the integration headache and taking care of aspects like security across the layers.

One framework that does both component based RIA, advanced controller layer and simple O/R is Oracle ADF - you might want to give it a spin.

Basic ADF Demo here

More info here.


Nicolas Bousquet replied on Tue, 2011/09/13 - 6:26pm

In particular for the frontend, you can't have a standard. Differents needs, different technological choices.

I would try to concentrate on the applications you are building and their requirements. Things like number of connected users, level of interrection required.

For example Templates framework (Struts, JSP...) in general are good to render simple HTML and making public websites. But they tend to be somewhat limited for complex and responsive interractions. You can try to use Jquery or other JS libraries to fill the gap, but this very low level and is comes with all classical problem of javascript.

High level frontend libraries (like JSF, Vadiin or Zk) bet on the wigdet model. You hope that the fairly complex standard widget will provide nearly the functionnality you need, and you be able to have the behaviour you need with little code. Dispite being dynamic, they tend to be a little limited if you need something really different than the standard widget. They are hard to skin and are a designer nightmare. Performance is often a problem and so you are limited to LAN with really good network infrastructure and a limited number of concurrent users.

You also have a somewhat hybrid approach like GWT. GWT compile java to JS. You eliminate most of JS problem, have fine control to what you do with it and it heavily optimised for performance. You can either make fast public web site with it (this make sence only if they need lot of responsiveness and interraction) or intranet like web app. It is still a little too much low level, and more than that, you need to have a team of good developper to really benefit of it.

Well flex I can't say much on it because I never studied it. But it appear to be fast, reactive and able to handle advenced user interrections. Content can't be indexed easily so that can be a no go for public websites.

I would still say your developpers are right that ExtJS (or even GWT, JSF, JSP...) will not bring the same responsiveness as a flex application and the code might be more difficult to maintain. Productivity will decrease. So this would depend on how well flex is a good fit for what your are doing on other facets. If it is really a good fit, why not just stick with it? Why add complexity?

WebServices and REST with JSON ? Why not. But this is not that important. What is important is that you stay stateless when possible. Simply because being stateless is simpler and make for a simpler architecture. REST embrace that, but is not required. REST is more for theologist that think they have to represent everything as standard HTTP documents and use only standard HTTP verb to represent any transaction. Be pragmatic, pick whatever suit your need and don't go too theologist. Before it was SOAP or even corba, now it is rest... Tomorow? you get it ?

Anyway, I prefer to stay simple and understand that if you backend might be still here in 30 years, it is likely that you'll do several redisign of your frontend to fit whatever will be most relevant at this time. So use a pragmatical solution and accept that you'll may need to change your UI every 10-15 years anyway. And a new UI is likely to require a new set of service optimised for it anyway.

For the backend, well, backend framework don't bring that much as one might think. Stay simple, avoid things that you don't really need. I'll tend to pick a few core JEE and spring technologies, as few as possible and use them only if necessary where you have no other choice. I'd try to avoid full application server and make standalone backend that can be deployed on a webcontainer like tomcat and so any webserver. I have seen many company stuck with an outdated application server years. Doing this way, you'll always be able to add a dependancy if needed, control your libraries version, and hopefully keep a clean and simple architecture.

The more pattern, frameworks and stuff you put in, the more you add accidental complexity. So be sure this is really needed. ORM for example, why not, if it is pragmatic and stick to CRUD operations. You don't gain much compared to raw SQL, but it can abstract some DB things to beginers and developper that lack RDBMS and SQL skill. Still for advenced queries and where performance matter, you'll need SQL/RDBMS expertise anyway.And that an important point. if you try to completely avoir RDBMS database design and optimisation, ORM will be more a liability than an asset. Data is a key point in any software. Respect it.

Be simple, be flexible. Avoid accidental complexity at all cost. If you are not aware you'll soon add some SOA, MDA and be coupled to a specific application servers or JMS broker. All kind of stuff that appear good at first but are made mainly to bring your client money outside of your pocket and back to the tooling vendor. And well your are not in the industry only to help VmWare, Oracle or RedHat grow no?



Paul Wong replied on Tue, 2011/09/13 - 7:19pm

In our company we are in a similar situation. Struts, Spring, Hibernate, EJBs, etc. Some of our applications still use EJB Entity Beans 1.1. Recently we embarked onto the journey to search for the next web framework to replace the ever ageing Struts and decided on Wicket. Served us pretty well, but there were definitely stumbling blocks. Learning curve was steeper than expected and developers were thrown into project without proper understanding for Wicket. Love the whole architecture for Wicket, but when people don't know what they are doing, can get pretty bad. I think I've finally found "Class Hell". Since then, I've a new found respect to simplicity. Stick to things that people know. JPA, HTML, jQuery... Therefore Play! Still early days, but I've got developers who are picking up Play! in a day, compared to trials and errors while learning something more complex, though elegant. Again, been loving Apache Wicket as a web development framework, but with the constant turnover of staff, and the shortage of Wicket skills, may not be the right technology choice.

Michael Ellison replied on Tue, 2011/09/13 - 8:32pm


Thanks for all of the great feedback. Regarding our skillset, I think we have small numbers that are good at variety of things(groovy, flex, grails, jsf, spring) but as a whole Struts 1.x and Javascript maybe the 2 things everyone knows. Personally, I see whatever framework chosen will present us with a nice learning curve to get back to good productivity.

Regarding the types of applications - literally anything you can think of that a financial services organization might need. Most of the apps will be used internally. That's to say, internal users are pushed any plugins (flash, jre, silverlight) they might need and IE 7 is the approved browser. This is what makes something like Flex acceptable for our internal apps.

The varied nature of our apps make me think 1 solution might not be sufficient. Here's another use case: We have many important business functions happening in Access databases and Excel spreadsheets. Theses Excel/Access apps needs to be converted to real apps and made accessible to several people, but they are fundamentally simple. They often just request a data entry screen with security, basic search with the data going to our real RDBMS. Personally, I think Grails and even DJango (even though we're a Java shop) are perfect for these scenarios. Our other apps, that have hundreds of users with 4+ developers working simultaneously, that have complex business logic and elaborate UIs may require something like a full blown JEE container with services running Flex/BlazeDS or java based componenet base framework X on top.

The challenge is to get the arch team to be flexible, since we have all different types of development challenges.

Cloves Almeida replied on Tue, 2011/09/13 - 9:30pm in response to: Michael Ellison


Since most applications will be internal - and corporate software tend to be data-intensive - I'd recommend a higher-level component UI toolkit, that has good data-binding capabilities, and keep stuff server-side. Using simple HTML+JQuery+REST will require a lot of RPC/data-marshaling - the JavaBean-to-JSON-to-Form-to-JSON-to-JavaBean get tedious pretty fast. And you'd need to re-implement validation both client and server side.

And that's why I'd suggest either JSF 2 or Vaadin, at least for the internal apps.  Both are pretty good and I personally like Vaadin more - its so damn fast to develop! But if you're concerned about developer turnover, JSF might be a better choice since its a standard.

You can also do "simple stuff" in JEE 6 - things have changed a lot. The JBoss 7 appserver loads in 4 seconds and a simple servlet app deploys/redeploys in under 4 seconds in my machine. With a maven archetype, in seconds an skeleton app is up and running. CDI is a pretty good server component model, well integrated into the server and there are a number of useful plugins through the Seam 3 project. No app lives in isolation so deploying in an appserver gives JMS, JPA, management and other services "for free".

And if you ever need to expose your services through a REST interface for any "fancy" apps, you can do it through JAX-RS. Specially with CDI/Seam it's a breeze to do it.

Besides it's technical merits, EE being a standard guarantees top notch support through a lot of vendors and some suplly of developers.

Sivaprasadreddy... replied on Tue, 2011/09/13 - 11:28pm


As many people are suggesting the selection of technology stack should depend on your requirements and type of project.

If your project is going to contain a rich UI and based on even driven approach then you should look at GWT,Vaadin, Wicket etc.

If your project is more like request-driven form-centric then look at Struts2, SpringMVC etc.

For Web Layer : (GWT/Vaadin or Struts/SpringMVC) + (ExtJS/Dojo/YUI)

For Service Layer : Spring

For DAO Layer: Hibernate/IBatis.

I prefer IBatis over Hibernate. I agree that Hibernate is  more powerful than IBatis but you will understand why I am suggesting IBatis over HIbernate once your project is getting bigger. There are number of people using Hibernate for their huge projects happily but still I like IBatis.


If you don't want to loose your hair don't go for JSF :-)



Martijn Verburg replied on Wed, 2011/09/14 - 7:01am

I'll add two things: 1.) Having an architecture team dictate from on high can be an anti-patter - see http://www.codingthearchitecture.com/ for an alternative philosophy. It boils down to your teams needing to choose the right technology stack for them for a particular project. They'll be empowered and have a sense of ownership. 2.) Have a look at Matt Raible's presentations (http://www.slideshare.net/mraible) on comparing Java based web frameworks using weighted criteria. HTH, Martijn

Jose Smith replied on Wed, 2011/09/14 - 9:29am

+1 to Mihai's comment about the people knowledge.

At the office we're using: GWT, Grails, and JAX-RS.

... and I'm using GWT, Spring, and JAX-RS on a personal project.

I found the combination of GWT with JSON and REST services is ideal (IMHO) when working with GWT. There's a little bit more marshalling/unmarshalling on the server to and from JSON, but generally with GWT RPC you wind up using DTO's anyway so you're essentially doing the same work. In the GWT layer, we're using Javascript overlay types instead of pure Java objects for our client side domain representation so the compiled JS is extremely efficient. Normally, with GWT RPC in large GWT projects compile times start to become very large and if you change anything in the backend or dto layer you often need to do a full compilation.

One issue I've found in GWT projects is the UI code can often become messy, over complicated, or over engineered pretty quickly, especially if you have lots of hands touching the code. Something as simple as clicking a link to another part of the application should be just as simple as placeController.goTo(newPlace) if you're following GWT conventions, but in the GWT projects I've been brought into, this often involves drawing out a two page diagram just to see what's going on with MVC events being fired left and right. Sometimes, when looking at some of the complexity of the UI code you sit back and question the decision to use GWT in the first place "What have we gained by using GWT?" IMHO, there's much more complexity when dealing with single page interface websites. Google advocates MVP and all this confusing boiler plate code and I'm sure they have thousands of unit tests for Google Wave's GWT code. Yet if I log into Google Wave and do something simple like maximize a "wavelet" and click restore it crashes the whole application - every time. It really takes a small disciplined team to prevent your GWT UI layer from spiraling out of control.

I'm personally not a fan of Grails. There's way too much magic going on for me. The IDE support is also incredibly poor. With the eclipse plugin, you often run into situations where you start getting strange compile errors. So you have to close, reopen the project, eclipse clean, grails clean, refresh dependencies - repeat 10 times, say a prayer, and hope everything works. Through some unknown sequence of events, this will trigger eclipse to open every .gsp page in your project (and in grails). After a minute or two you have a thousand open groovy files, but now magically everything is working. We've had a few occasions on different developer machines where eclipse randomly alters every single source file - not fun when you have lots of local changes and you have to carefully revert thousands of files.

Joonas Lehtinen replied on Thu, 2011/09/15 - 1:12pm

What are your thought on Microsofts recent announcement on dropping plugin support from IE10 in Metro mode related to this discussion? IMO this has quite severe implications for Flex in the long run.

Lund Wolfe replied on Sat, 2011/09/17 - 2:30am

You seem to want a Rich User Interface for internal applications and you have plenty of Java skills so why not use Swing and JNLP like other financial institutions ? It's the right tool for the job. Using a web framework or tool is trying to "sew a silk purse from a sow's ear". If you need the power of a desktop thick client why try to substitute or fit it into a web framework, html, JSP, css, javascript, jquery, ajax. You might at least do one application as a proof of concept with a mid-level Swing developer. It's the easiest and most appropriate conversion for an Access app (and Excel if it is anything like an Access/VBA app). If it works out, the Swing developer can help the other java developers get up to speed. There is a somewhat steep learning curve at first, but then it's just variations on a theme.

For web apps you might want to restrict your web technologies to two popular choices that will stand the test of time so you don't end up having to maintain a gazillion different (and abandoned) technologies later. Struts 2 is a very good choice, as previously mentioned, and there is a little overlap with the Struts 1 experience you already have in house.

Moez Ben Rhouma replied on Sat, 2011/10/01 - 4:58pm

You can think of telerik. Net for reporting tool without having to write lots of code. Remember to PHP with extjs and with jquery, easy to integrate them ... For me, I use and I will use either or wicket or gwt, both framework does not require great skill in jsp, tag, js ... Just java skills. To use wicket just written simple html and java. For gwt java code automatically generates js. Both are easy to integrate with the Spring framework or EJB. Especially wicket, there is a community / forum very active ...

John David replied on Thu, 2012/01/26 - 3:12am

I enjoyed working all the comments threads and got lot of good ideas.

I have expertise and worked with many different frameworks.

I would prefer to work with the following choices.

1- Spring+Hibernate

2- JSF+Hibernate

Java Eclipse

Kirill Zhukov replied on Mon, 2014/09/22 - 10:31am

I can't agree with collegues who suggest choosing the framework you just have experience in. The question is much more complex and we were also searching for an answer in our company. Idea is that technologies are developing so fast that if you will choose the one you know good you have a risk to look like a specialist from a stone age very fast. Take a look on this  page for short notes about analytics we did during our choice. There's still no single answer. And from my point of view the most universal answer is that you should be technology agnostic. Avoid "falling in love" with only one framework.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.