Suggestions for designing large-scale Java webapp from the ground up

Question

Hi all,

I'm about to start developing a large-scale system and I'm struggling with which direction to proceed. I've done plenty of Java web apps before and I have plenty of experience with servlet containers and GWT and some experience with Spring. The problem is most of my webapps have been thrown together just to be a proof of concept and what I'm struggling with is what set of frameworks to use. I need to have both a browser based application as well as a web service designed to support access from mobile devices (Android and iPhone for now). Ideally, I'd like to design this system in such a way that I don't end up rewriting all of my servlets for each client (browser and phone) although I don't mind having some small checks in there to properly format the data.

In addition, although I'm the only developer now, that won't necessarily be the case down the road and I'd like to design something that scales well both with regards to traffic and number of developers (isn't just a nightmare to maintain).

So where I am now is planning on using GWT to design the browser-based interface but I'm struggling with how to reuse that code with to present the interface (most likely xml) for the mobile devices. Using GWT RPC would, I think, make it relatively easy to do all of the AJAX in the browser, but might make generating xml for the mobile phones difficult. In addition, I like the idea of using something like Hibernate for persistence and Spring Security to secure the whole thing. Again, I'm not sure how well those will cooperate with GWT (I think Hibernate should be fine...)

There's obviously a lot more to this than I've presented here, but I've tried to give you the 5-minute overview. I'm a bit stumped and was wondering if anybody in the community had any experience starting from this place. Does what I'm trying to do make sense? Is it realistic? I have no doubt I can make all of these frameworks speak the same language, I'm just wondering if it's worth my time to fight with them. Also, am I missing a framework that would be really beneficial?

Thanks in advance and sorry for the relatively broad question...

Chris

Answer 1

I'll be pretty specific here since I have some related experience. Not all of what I'll write will apply, but I'm hoping something does.

My 1. advice would be to keep any code that's directly dependent on any framework as "stupid" as possible. If you can, consider such code more or less disposable (implementation wise, API contracts exposed to clients needs to be stable of course).

Focus on what makes your application unique, and try to make that independent of GWT etc. The facade pattern is something I can recommend - keeping the app-specific logic behind one and exposing it by wiring the presentation layer with it has served us well. If your back-end depends on third party infrastructure (via web services etc), decouple those dependencies from your code with the adapter pattern.

I have spent most of my working time during the past 5 years on building something that matches what you described in many ways. Today it's more an app framework then an app - it has a few different browser interfaces (WAP/standard web+ajax/Facebook app), an interface for 2-way SMS usage, and a REST/XML interface for thick mobile clients - BREW, iPhone, Android and Blackberry.

When it comes to frameworks, for persistence, we have used Hibernate. All the different pieces of code are tied together with Spring. The browser interfaces have been ported from Struts (1.x) to Wicket. The SMS and mobile client interfaces are built on top of Restlet.

Using multiple different presentation layer frameworks (such as Wicket and Restlet in our case) has not been a problem, as long as that code is kept lean and business rules are kept out of it (to the extent possible). There is nothing that says that your browser interface has to be packaged into the same WAR as your mobile client interface - with Spring you can easily wire several web applications with the same facade. This has been helpful to us especially in allowing multiple developers to work on well isolated pieces of the application.

In my opinion, trying to achieve maximal reuse of code in the presentation layer has caused more harm than good. That has always been the most volatile part of our application, beyond what we have been able to expect.