I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Architect This! Implementing a Java Based Survey Tool

11.03.2008
| 11619 views |
  • submit to reddit

I thought it would be interesting to get community feedback on the following problem. The basic requirement is to write a web based survey tool. Of course, my preference for this would be Java, and I jumped to some conclusions on what frameworks I should use to implement it.

What It Needs To Do

A simple list of requirements for this application is as follows:

  • An administration interface for the creation of new surveys
  • A reporting tool for survey results - exporting to PDF or Excel
  • Graph based reports
  • Different question types such as multiple-choice and free text
  • The ability to change the sequence of the questions
  • Copy and deletion of questions
  • Email notifications when a survey is filled in
  • User login (and registration) for participating in surveys
  • A snappy user interface for users to do the survey

 

Initial Thoughts

First on my list was Spring Web Flow - it definitely suits certain types of application, but does it fit here? There's good tooling available with the SpringSource Tool Suite. Options I instantly disregarded was plain old Servlets or JSPs - but this was because I knew there were "better frameworks" out there. Did I make the wrong assumption?

Your Turn

So, I'm leaving it open to the community now. What would your technology stack be for such an application? Of course, I'd like to see reasons why for any of your choices.

I'd like to point out that I'm not asking anyone to do my homework for me here! I think it's an interesting way of seeing what frameworks are in fashion at the moment.

Comments

Schalk Neethling replied on Mon, 2008/11/03 - 11:57am

Interesting topic James. Obviously you have the option of starting from scratch here so as your framework I would suggest either Wicket or Grails and for the reporting aspects BIRT.

Porter Woodward replied on Mon, 2008/11/03 - 1:54pm

Start with your model first.  Come up with the simplist object model that could possibly work for storing a survey and it's associated set of questions - and model the behaviors you want.  Write tests for the model - ignore UI and reporting issues (at least at first).  The basic model for storing the model of a survey - and it's responses should be pretty re-usable no matter what framework you decide to hook it into.

Now - refactor that model (and tests) to account for the users (surveyors and surveyees).  You may discover you don't always want a user registration / login (some surveyors may want to do anonymous surveys that automatically know if the surveyee has already answered).

In parallel with that process - mock up some wireframes of the user experience.  You can do it with paper and pencil to help reinforce the idea that this is not a working application, and the user interface is not "final" (the danger of HTML mock-ups is people often assume the prototype is functional - and people often get "attached" to the invested time in making the mock-up).

Stripes, Wicket, etc. Are all good choices for "view" components.  You can glue them to a back end using Spring or Guice.  Slap in some JPA for persistence (or just use Hibernate directly).  Reports and Graphics are tricky.  BIRT or Jasper work for reports - although I expect you may want to do simple graphs on the fly as users respond to surveys (e.g. 48% yes, 52% no with a cute little pie chart).  That's a more difficult prospect as you'll probably want a Flash applet to handle that.

You might also look at JAX-RS - it might be enough to make a lot of the survey API RESTful - and use tools on top of that.

Slava Imeshev replied on Mon, 2008/11/03 - 2:11pm

James,

My recommendation would be to follow the normal OOA/D practices. The resulting analisis and the design will  tell you if or what framework to use. Jumping to the selection of a web user interface framework without working through basics may cause unnecessary complexy, time overspent and other troubles and finally the failure of the project.

Also, the idea of developing a survey tool, Java or not, seem to be a bit too late (AKA wheel-reinvening :). There are plenty of great web survey tools around, free and commercial. Look at SurverMoney for an exmaple.

Hope this helps.

Regards,

Slava Imeshev

 

Taylor Gautier replied on Mon, 2008/11/03 - 4:19pm

James,

It's interesting, the requirements you list are really really similar to a reference web application we built at Terracotta called the Examinator.  The Examinator is a test (exam) taking application, and has nearly the same exact functionality and requirements you listed.

The stack we came up with was:

  • Spring Webflow and Spring MVC
  • JPA (Hibernate)
  • ServiceMix
  • MySQL
  • Tomcat (though can be run with most any servlet container)

And a bunch more (for testing and the like e.g. Cargo Maven etc.).

What's more, since this application is designed to demonstrate how best to design and build a scalable web application, the requirements include the ability to scale out to 16 nodes, handle 20k concurrent users, and no response time may be greater than 10ms.

If that sounds interesting, you can read more about Examinator on Terracotta.org »  

Silvio Bierman replied on Mon, 2008/11/03 - 6:09pm

Are you sure you want to build this from scratch yourself? My company happens to provide such a system (written in Java, of course) and therefore I dare to call myself an expert on the subject.

I do not want to discourage you but have you (or they) considered: routing (if-like constructs, optional questions etc), randomization features (to even out sequence dependencies), masking answer options (leaving out what can not apply based on previous answers), non-combinable answer options in multiple option questions, images and multi-media, drag&drop etc.etc.etc.

There are numerous standard software products out there. Unless you have a very specific need that can not be met by any of them it does not seem to make sense to build your own product. It may seem simple enough at first sight but you can believe me that anything full-featured not totally blown away by even the most modest (and cheap) standard products out there is easily a multi-man-year endeavour.

1) Specify requirements
2) Check for standard products, use if available
3) Check again
4) Really check
5) Rethink requirements based on what you did find
6) If any of steps 1-5 was performed by a programmer goto step 1
7) Build your own

Silvio Bierman


 

James Sugrue replied on Tue, 2008/11/04 - 2:19am in response to: Taylor Gautier

Hi Taylor

That sounds quite interesting, and a similar stack to what I would expect for a web app these days. I will definitely take a look at this.

James

Soren Davidsen replied on Tue, 2008/11/04 - 2:47am

I also assent on the above, tool selection is usually not something I want to get done by my architect.

For a first prototype, it would be good to know if all the tools to solve the task are available given the language has been selected (Java).  However, all the topics/features you list are quite straight-forward, so tool selection is only about finding the best match, given your design - so, maybe better to start with that :-) Your features are quite basic, they do not tell about eg. how many users to service, complexity of surveys, number of surveys, etc. Tool selection would probably depend on that too.

  • Administration interface, something easy to setup, like component based JSF could maybe be useful here?
  • Reporting, already Jasper Reports and BIRT have been proposed. Depending on your need maybe also somethingsimple like google charts? Or in the more advanced department, the Pentaho suite.
  • Graph based reports, I'm not sure what that means exactly?
  • Different question types, depends on your design, ALL web/html frameworks can do this! If you're into more advanced, like graphical entry etc, maybe Flex is your direction to go.
  • Change sequence, copy and deletion, again, this does not require a specific tool. Probably Hibernate or JPA with some clever querying?
  • Email notifications, Apache commons email or Spring's email convenience wrappers are probably a good direction.
  • User login, Spring Security for more flexibility? Depending on how much you need to register for each user, possibly just use openid (comes with Spring Security).
  • Snappy user interface, simple HTML, per-question pages, distribution (possibly Terracotta like Taylor suggests), GWT to load all client-side in one shot?

If it is a real project or a pet project, maybe for a real project, go for a readymade solution if a such exists, like Silvio suggests.

Regards,

Soren

Naresh Kapse replied on Tue, 2008/11/04 - 5:47am

Hey James,

 It is quite interesting to know that you are on the same page as i am. I am also currently working on a suryvey tool, which has also the same requirements as yours.

 Initially, I thought of doing with Rails, made a demo app with very basic features. But, with long term plans(performance, scalability and security issues), I thought of developing the tool using Java Technology (As i am more familier with Java). I am currently validating my design schema before getting started.

I would like to thank "Soren Davidsen" and "pwoodward" for suggesting on how to go with this kind of project.

- Naresh Kapse

Manuel Jesús R... replied on Tue, 2008/11/04 - 6:54am

Hey,

I am also working on a survey tool [1][2].

Regards,

[1] Opina: survey manager
[2] http://www.ohloh.net/projects/8797

Mike Funk replied on Tue, 2008/11/04 - 6:58am

James,

I was asked to develop a web app 4 years ago that would handle surveys, polls and exams. It turned out to be an extremely challenging project, especially when one accounts for resuable typed questions as well as answered questions. I would urge you to start with a domain-driven domain model, coupled with unit tests that heavily test all use cases. Once completed, you can then wrap your domain model in any technology set you so desire. It's a fun problem space. Enjoy.

 Regards, Mike

 

Tracy Nelson replied on Tue, 2008/11/04 - 9:01am

I did this a long time ago using a "courseware authoring system".  You might want to check out something similar (search for "plato tutor language").  It's not Java, but it'll have a lot of the functionality you need right there in the box.

Guillaume Jeudy replied on Tue, 2008/11/04 - 10:14am

JBoss Seam has a superior conversational model if you compare against Spring Web Flow. Moreover it's default view layer: facelets with JSF is alot better than the crippled JSP technology.

Okay JSF has many flaws but Seam fixes most of them.

My view is a little biaised but I would recommend JBoss Seam. Don't forget to use seam-gen to kickstart your app development. As long as you are comfortable using Ant to build your project then seam-gen combined with hot deployment feature is very good for RAD.

 Moreover Seam has out of the box support to implement the following 3 of your requirements:

  • A reporting tool for survey results - exporting to PDF or Excel
  • Graph based reports
  • Email notifications when a survey is filled in
  • Alex(JAlexoid) ... replied on Tue, 2008/11/04 - 5:10pm

    Do the KIS approach and EVOLVE the architecture, don't overarchitect in advance.

    • Download NetBeans 6.5 RC2 *.
    • Create a new Java WebApp and select Visual JSF feature.
    • Click away :)
    • For Persistence you may use your favourite JPA implementation.

    Or a bit longer option of simple JSF+Facelets+Some AJAXy stuff thrown in, that might be cleaner in the end.

    For fun you may do an even more interesting thing:

    • Create a Ruby on Rails app for UI.
    • Do your data logic in java POJOs
    • Use those POJOs, from ruby code
    • Deploy everything using JRuby on Tomcat or Glassfish.

     There's Grails option out there also.

    * And you'd be helping to test, the thing :)

    James Sugrue replied on Wed, 2008/11/05 - 1:27am in response to: Alex(JAlexoid) Panzin

    Thanks Alex, sounds like a nice quick way to get going. I guess there's always a danger of over-architecting, especially with the wealth of web frameworks available.

     

    EG replied on Thu, 2008/12/04 - 3:42pm

    You may want to architect your application using design  patterns form the ground up (MVC,DAO, GoF, etc). You may also want to take a look at the Jt Pattern Oriented Framework:

     

     Jt3.0 has been released. Jt is a pattern oriented framework for the rapid implementation of Java applications. Jt has been utilized in several large mission critical systems. Jt implements many well-known patterns including Data Access Objects (DAO), GoF design patterns and J2EE patterns.

    Jt3.0 features several enhancements to the Jt components and a version of the Jt automated Wizard (JtWizard). The Jt Wizard is an application built on top of the Jt framework that provides automated capabilities for generating framework applications. The Jt Wizard is able to automatically generate application modules based on several design patterns including Jt Messaging, DAO, MVC and GoF. The current Jt Wizard implementation provides integration with MVC Struts and DAO Hibernate. DAO mapping files, Struts configurations files, Views (JSPs), Java classes are automatically built by the Jt Wizard. The Jt Wizard is also a reference web application implemented using the Jt framework.

    The framework addresses the following goals and requirements:
    A) The pattern oriented framework implements and/or facilitates the implementation of well-known design patterns like GoF design patterns and J2EE Design patterns. The framework itself is conceived and implemented based on design patterns (from the ground up). The framework facilitates and accelerates the implementation of applications based on design patterns.
    B) The framework architecture is based on a messaging design pattern: framework objects is able to interchange information and perform computations by sending, receiving and processing messages. A messaging API provides strong encapsulation and loose coupling; framework components can be easily plugged into complex framework applications using a “lego/messaging” architecture. The framework takes full advantage of the power and simplicity of the messaging design pattern.
    C) The framework lego/messaging architecture provides transparent access to remote components: remote framework objects is treated as local objects. Design patterns implemented by the framework (adapters, remote proxies and facades) make this posible by hiding the complexities associated with remote APIs.
    D) The framework provides transparent integration with other technologies via framework adapters, proxies and the implementation of related design patterns. These technologies include BPM, DAO implementations, MVC implementations, EJBs, JMS, XML and Web Services.
    E) The framework is designed to be lightweight and fast in terms of performance (low overhead).
    F) The framework messaging/lego architecture should improve and simplify design/development efforts. There should be a tight correspondence between UML design diagrams and the framework messaging based applications and components needed for the implementation. Ideally, the framework provides wizards and automated capabilities for generating framework applications. Framework components should be easily added to BPM process diagrams. In future versions of the framework, it should be possible for applications to be generated directly from the UML design diagrams.
    G) The framework messaging architecture facilitates testing and debugging efforts. The framework provides capabilities for testing components independently (each component as a unit) by sending messages and verifying the reply (output) messages.
    H) In order to provide additional productivity benefits, the framework is integrated with open source IDEs.

     

    Jt online documentation can be found at http://jt.dev.java.net/servlets/ProjectDocumentList

    For additional information please refer to http://jt.dev.java.net. You can join the Jt mailing list here.

     

    Ron Rea replied on Sat, 2013/11/02 - 5:17pm

     I don't know if you ever look here, but I'm trying to build exactly something that does exactly what the application in this article does.  Did you ever develop this or decide on the best way to go with developing this?  I've looked around for something open-source I could start with, but haven't had any luck.  Great article, by the way!

    Mouhcine Makroume replied on Wed, 2014/07/30 - 5:15pm

    Take a look at the GitHub repo for JD eSurvey https://github.com/JD-Software/JDeSurvey. It’s a survey web application built using the Spring.

    JD eSurvey is an open source online enterprise web application survey tool written in Java and based on the Spring Framework and Hibernate ORM and is packed with a variety of useful features, including survey statistics. Discover how quickly you can create, publish and analyze surveys literally within minutes.

    I work at JD Software the company that published JD eSurvey. I am disclosing this in accordance with the Federal Trade Commission’s 16 CFR, Part 255.

    Comment viewing options

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