The Spring Framework offers many ways to ease application development and maintenance, but one that gets my interest really going is its dynamic language support.
codehaus: Dynamic language beans in Spring
codehaus: Groovy and JMX
raible designs: Using Dynamic Languages with Spring with Rod Johnson and Guillaume LaForge
organic thoughts: Spring Meets Groovy!
Looks like a tutorial I want to take: “Flex, Spring and BlazeDS: the full stack! (Part 1)”
One of the largest concerns when developing an infrastructure for a site as large as Comcast.net is determining smart ways to scale. By smart, I mean requiring the least amount of effort to launch new channels or services. Each new channel or page can draw thousands, if not millions of page views. You need to plan for it.
When growing Cofax at Knight Ridder, we hit a nasty bump in the road after adding our 17th newspaper to the system. Performance wasn’t what it used to be and there were times when services were unresponsive.
A project was started to resolve the issue, to look for ‘the smoking gun’. The thought being that the database, being as well designed as it was, could not be of issue, even with our classic symptom being rapidly growing numbers of db connections right before a crash. So we concentrated on optimizing the application stack.
I disagreed and waged a number of arguments that it was our database that needed attention. We first needed to tune queries and indexes, and be willing to, if required, pre-calculate data upon writes and avoid joins by developing a set of denormalized tables. It was a hard pill for me to swallow since I was the original database designer. Turned out it was harder for everyone else! Consultants were called in. They declared the db design to be just right – that the problem must have been the application.
After two months of the team pushing numerous releases thought to resolve the issue, to no avail, we came back to my original arguments. The terrific thing was that restructuring the database was a no pain affair – we had a terrific service layer between the main web tier and the db that hid its schema. We were able to deliver a release of the database that did not require any code changes on the web tier.
There is no silver bullet here, for smaller sites you are adding a great degree of complexity taking this route and it is, most likely, not advisable. However, if you have a large site that is thrashing – dealing with the demands of growth – take a hard look.
Related – and supporting of this:
High Scalability: “How I Learned to Stop Worrying and Love Using a Lot of Disk Space to Scale”.
High Scalability: Scaling Secret #2: Denormalizing Your Way to Speed and Profit
Dare Obasanjo: When Not to Normalize your SQL Database
infoq: SpringSource Launches New Application Server without Java EE
SpringSource Team Blog: Introducing the SpringSource Application Platform
SpringSource: http://www.springsource.com/web/guest/products/suite/applicationplatform”>SpringSource Application Platform
Not directly related at all, but has everything to do with it:
The Daily Profeth: Google App Engine & eclipse (PyDev) – a nice getting started guide.
.It was both educational and fun to read the NYTimes interview with Khoi Vinh, their Design Director.
Blog at trepca.si: Java, Python and defaults – Sure is true enough.
Code To Joy: Open-Source group announces jJavaM – It was an April fools, but a good one for the sarcasm.
Python-by-example – Will come in handy.
Better Programming With Java EE: A Conversation With Java Champion Adam Bien – Dispels some myths.
An Army of Solipsists: Blog Archive: Using Spring MVC Controllers in Grails – Might come in handy if I ever get around to experimenting with Grails.
Anil Dash: Atom Wins: The Unified Cloud Database API: “I want every program that thinks of itself today as a “blogging client” to reimagine their market as being a front-end to a database in the cloud. I want all the apps built on smart database abstractions to think about this new unified cloud API as an option they must support. And most of all, I want geeks to make something cool with this that we couldn’t do before.”
Hosting Java Web Applications: Why Is It Still So Hard? | Javalobby
Sun’s hiring of two of the biggest names in Python-land – Ted Leung and Jython’s Frank Wierzbicki – and my experiments with Django – has encouraged me to dip my toes in Jython. Here’s a few decent starting points:
IBM developerWorks: Charming Jython
IBM developerWorks: alt.lang.jre: Get to know Jython
ONJava: Tips for Scripting Java with Jython
JythonWiki: Learning Jython (just starting this one, but this looks most comprehensive)
And of course the home page: The Jython Project
Bill de hOra posted an interesting question the other day, that has to do with mapping views to requests, cleanly, in a RESTful way, as Sam Ruby framed it:
it’s easy to forget that Servlets were Java’s response to CGI, way back when. Here’s is the link for Stefan’s entry:
http://www.innoq.com/blog/st/2007/08/15/java_web_frameworks.html
I’m wondering how would one produce a URL space for a blog style archive, using Servlets+JSP, and do so in a way that isn’t a CGI/RPC explicit call? That is, the URLs don’t end up like this:
http://www.innoq.com/blog/entry.jsp?id=java_web_frameworks
with one constraint – “just a servlet” that pulls java_web_frameworks.html direct from a “2007/08/15” folder on the filesystem and byapsses JSP is out. All the response is to be generated via JSP. Would we need to a create framework, however ‘micro’?
In Django world, answering such a question is rather easy. And for PHP hackers, you’re probably saying, hey, use .htaccess to route requests, but in Java, this question becomes a bit more complicated.
A Java developer would want solve two problems here: enable “clean” RESTful URLs, and do as little Java coding as possible by distributing responsibility for defining views to a templating language. Hopefully empowering someone who knows just HTML/CSS to work their magic. The benefits to such an approach can’t be underestimated. We we went down such a path at Knight Ridder with the Cofax CMS and it empowered a lot of creativity with little resources on hand (lots of folks know HTML/CSS/JS, few know Java).
Carbon Five discusses an approach that decomposes path info into parameters for Spring MVC controllers: Parameterized REST URLs with Spring MVC. This solves problem one. It still routes requests to a Controller defined in Java, and I’ve seen far too many not solve problem two, which leaves a design where you have a Request, that maps to a Controller that maps to a single View. But this leaves you with an *excellent* foundation to solve the second problem.
Sam Ruby points to URLRewriteFilter as one possible solution. This potentially solves both problems.
Stefan Tilkov explains how to decompose path info and use RequestDispatcher as a solution. In Sam Ruby’s comments, I suggested just such an approach and it’s worked great for me in previous (and current) projects. This potentially solves both problems.
BTW, if you’re interested in a templating language, outside of JSP (and who isn’t?), consider FreeMarker. A huge project I’m helping design and develop is having terrific success with it and Spring MVC. Real magic starts to happen when you decouple Requests from Views. A shortcut to this in Spring MVC is implementing a RequestToViewNameTranslator.
Paul Tyma, a senior engineer at Google, developed and maintains Mailinator, a nifty service that helps you avoid the hassle of associating your personal email address with services you never intend to revisit during registration.
A few months ago he posted about the architecture behind Mailinator and the decisions that went into it. It’s a great read.