Suggestions for designing large Java webapps from scratch

I'm about to start developing a large system, and I'm trying to move in which direction I have done a lot of Java Web applications before. I have a lot of experience in servlet container and GWT, as well as some experience in spring The problem is that most of my webapps are thrown together just to become a proof of concept. What I'm trying to solve is what kind of framework to use I need both browser based applications and web services designed to support access from mobile devices (Android and iPhone) Ideally, I want to design this system in such a way that I won't rewrite all servlets for each client (browser and mobile phone), although I don't mind doing some small checks there to format the data correctly

In addition, although I am the only developer now, this is not necessarily the case in the future. I want to design something that can scale well in terms of traffic and the number of developers (not just a nightmare)

So I'm planning to use GWT to design a browser based interface, but I'm trying to solve how to reuse the code to render the interface of mobile devices (probably XML) I think using GWT RPC will make all Ajax in the browser relatively easy, but it may make it difficult for mobile phones to generate XML In addition, I like the idea of using persistence such as hibernate and spring security to protect the whole thing Again, I'm not sure about the degree of cooperation with GWT (I think hibernate should be ok...)

Obviously, it's much more than I'm introducing here, but I'll try to give you a five minute overview I'm a little sad to know if anyone in the community has any experience from this place Does what I want to do make sense? Is this realistic? I have no doubt that I can make all these frameworks speak the same language. I just want to know if it's worth the time to fight them Besides, did I miss a really useful framework?

I would like to thank and apologize for the relatively wide range of questions

Chris

Solution

Because I have some relevant experience, I will be very specific Not everything I write applies, but I hope to make a difference

My advice is to keep any code that directly depends on any framework as "stupid" If you can, consider that these codes are more or less one-time (implementation wise, API contracts exposed to customers certainly need to be stable)

Focus on what makes your application unique and try to make it independent of GWT, etc I can recommend facade pattern – it's useful for us to keep application specific logic in one and expose it by connecting the presentation layer to it If your backend relies on third-party infrastructure (through web services, etc.), use adapter pattern to separate these dependencies from your code

Over the past five years, I have spent most of my working time building things that match what you describe in many ways Today it's more like an application framework, then an application – it has some different browser interfaces (WAP / standard web Ajax / Facebook applications), an interface for two-way SMS use, and a rest / XML interface for fat mobile clients – brew, iPhone, Android and blackberry

When it comes to frameworks, we use hibernate for persistence All the different code is bundled with spring The browser interface has been migrated from struts (1. X) to wicket SMS and mobile client interfaces are built on restlet

Using multiple different presentation layer frameworks (such as our wicket and restlet) is not a problem, as long as the code remains concise and the business rules are not limited (as far as possible) Nothing suggests that your browser interface must be packaged in the same war as your mobile client interface – with spring, you can easily connect multiple web applications with the same look and feel This is very helpful to us, especially to allow multiple developers to deal with well isolated applications

In my opinion, trying to maximize code reuse in the presentation layer has done more harm than good This has always been the most unstable part of our application, exceeding our expectations