LargeSiteModel2

Assuming the following:-

You have a dynamic servlet-based web application that interacts with a backend tier (not necessarily a database). You want to be J2EE compliant. You want easy deployment. You have a number of application property files. Your content changes far more rapidly than your logic. You have a large number of independent, load-balanced servers.

How do you tackle it?

Some thoughts (drawn shamelessy from my own situation):-

Most of the code and libraries can go into a WAR file. This should make deployment easy. Its not too much extra effort to bundle it into an EAR, although not strictly needed at the moment - the backend is a CGI contacted by your app. via a Java URLConnection and returning XML. Some other solution (EJB, AltRMI, SOAP yada yada) may be used in future.

The XML is parsed, processed etc. and the data weaved into HTML via some templating method (eg. Velocity, XSLT, or JSP custom tags etc) and the resulting page returned to the browser.

Content

Issues to consider:

• You may have a whole hierarchy of templates with different 'skins'
• Your templates are changed far more rapidly than your code.
• You don't want to rebuild, retest and redeploy an EAR everytime a style change is made.
• You have lots of servers that you want to keep in sync.

Where do you put your content templates? The simplest solution is to include them in the WAR/EAR file, but that becomes problematic when your presentation changes much more rapidly than your code, and you don't want to tie up a developer building and deploying your whole app. everytime a designer decides a 2pt font increase on one page is essential for the site. Not to mention ensuring that the right code version is deployed and that every server gets the new file and has picked up the changes (hot deploy still being somewhat dodgy for a lot of app servers).

One possible solution is to place your templates in a single common location (eg. an internal web server), and have all your app servers load and cache them when they start up. This is probably not great. The app. has to know where to get the data from, and if the templates change, how do you inform the app. that it needs to reload? It also introduces a point of failure, although redundancy can mitigate that.

Properties

You want to be able to easily configure your application. Property files seem like a good way to go. Where do you put them? Inside the WAR? How do you edit them? How do you ensure every server has the same properties? Answers on a postcard (or preferably, on this page).

Persistence / Load balancing

Stateful web applications are my enemy. HTTP wasn't designed for this sort of thing. Load balancers never send you to the right server, especially if you are a freeserve customer, with their funky multiple source IP superhuge mega-proxy. Sticky sessions go up the spout if your apparent IP address is different every request. We've tried using all the cool features of hardware load balancers, (URL switching, cookie switching, sticky sessions blah blah), but I'm coming to the conclusion that the most robust solution is to make the load balancer dumb (or possibly just use basic sticky persistence), and use a decent distributed session app. server. Maybe I like this cos it gives me (as the developer) more control and leaves me less at the mercy of network engineers. I like the look of Resin in this regard. Concerned about how shared sessions will scale on 10-50 app servers though. 50 odd machines all chattering away to each other to keep their sessions in sync. might use a fair bit of bandwidth on a busy site.

--DarrenH

--DarrenH