LargeSiteModel2

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.

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

If you are really sure that the page style and templates will change frequently, then the "single common location" options sounds good. A web server would be fine, as would JNDI if you have a shared directory resource available, or even a database. As for "how do you inform the app?" I'd probably just write a dump-and-reload servlet, hang it on an unlinked URL, then make the redeployment process push that button on each live application.

The solution for the properties files seems broadly the same. It's easy enough to reload a Properties file from a remote stream, and the same sort of reload servlet approach should solve this too. You'd have to be careful never to keep hold of a value from the old properties in the code, though, if you plan to update these properties on a running application.

--FrankCarver

Don't put them in the WAR. Make them resource bundles with no locale then you can put them on the classpath of the server and change them at a different rate to the WAR file.

Or you could PutConfigurationInTheDatabase? - This is working well for us.

--TomA

--DarrenH

Would JavaSpaces? be a good technology fit for distributing new configurations and template styles? "Subscribing" to a particular line of templates might be a good idea, although it doesn't take away the bootstrapping problem of how each web app instance would connect to a source of configuration data in the first place.

--DafyddRees