TheServerSide at JavaOne 2005 - Day 4

Day Four at JavaOne includes a case study on handling rapidly changing load characteristics, and the web framework shootout.

Day 1 | Day 2 | Day 3 | Day 4

June 2005

Discuss this Article

Day Four includes a case study on handling rapidly changing load characteristics, and the web framework shootout.

Case study: The daily planet

The Daily Planet hosts more than 20 major different news sites on the internet, and has more than 10 million unique users/month. One of the challenging characteristics is that the site has very quick changing load characteristics, many spikes when controversial news happens.

Some of their systems requirements - which the presenter advocated we should always think about upfront - were:

  • How to scale with big spikes
  • How to scale when adding more applications (news sites)
  • how to achieve no single point of failure
  • how to handle system abnormalities
  • how does application isolation in a clustered environment effect reliability and utilization

The topology of their deployment consisted of load balancers serving a cluster of web servers and, separately, a cluster of oracle application servers with session state shared, and a layer of database servers.

“Think about high availability and scalability as cause and effect, one affects the other!” He suggested that there be a lot of questions asked, even during the design process.

The presenter went over a number of decisions they made, explaining many pros and cons for each, almost debating himself:

Hardware configuration.

Should we add a couple of big boxes or many small boxes? “If you have the right tools, management and provisioning, I think it’s more efficient to have a lot of small boxes-”, but looking at scalability, if you have only 2 big boxes, when you need to scale you’ll need to incur a big box for a third.  Many smaller boxes give more flexibility in scaling, both in costs and in ability to tier an architecture.  However, if you are going to have 100 servers, you better have some good tools, either built yourself or buy them. 

The choice they ended up going with was having many smaller servers, each server containing multiple instances of appservers or web servers on them.

Layered Architecture – the funnel effect

When you have a layered architecture, it gives a lot of flexibility, both in how you can deploy it and scale it. However, it also has brings more challenges. When you have a layered architecture, layers can affect each other. When lower layers can’t scale as well as those above, then you can run into problems unless you have some kind of choking/throttling ability. This is the funnel effect.

Eg: for x # of users hiting the web tier will result in y amount of connections to the J2EE layer and Z amount of resources being consumed from the back end.

The presenter found that a lot of people just stop performance testing after saying, “OK, I can support 10,000 at a time, I’m done.” But what about when there is a spike? At the end of the day, you don’t know how the system will behave.

The solutions to the funnel effect presented were to put a throttle at the web server layer. If your SLA is to serve 10K people, then make sure you can serve those and throttle the rest and try to serve them if possible, or serve 503 pages.  He recommend throttling the number of connections as early as possibly once you know that back end resources are being all used up.

Second, he said to implement time outs, be careful not to let threads infinitely build up waiting for some back end resources and bringing the system to a stand still.

In terms of load balancing and fail over, the best practices advocated was making sure that load is evenly distributed across your cluster during normal and abnormal times. “Round robin usually does the job well,” or if you do a metric-based system, “Keep it simple!” In addition, test to get even fail over of sessions as well. 

With regards to the goal of getting the “right” distribution when something abnormal happens:  Specifically, when some kind of metric happens, such as abnormal CPU, connections use, he wants to be able to change the routing of traffic away from those resources to the rest of the cluster in an even manner.

Another challenge is giving servers the right amount of ramp-up time to let them get ready before funneling traffic to them.  The solution is some kind of choke functionality as well, and some smart metric-based load balancing.

About session affinity, the presenter explained the problem of what happens when a server goes down, it’s state is failed over to other systems, and then it comes back up? How do you immediately put traffic back to it?  He recommends (yet again), some kind of metric-based load balancing that can re-fail over session state back to it.  He began to sound a bit like broken record at this point. J

On the management side, they needed a way to dynamically do updates, configuration, and such.  Their solution was that all the servers would connect to one NFS mounted system, where the applications were hosted as exploded directory. This allowed a ‘hot updates’ effect. 

For configuration changes, they had scripts that would propagate any config file changes to all nodes automatically.

After the presentation was over, a number of people gathered to ask more questions. One of the questions was why the presentor advocates multiple VM’s per box. The presenter said that in his experience, having 3 VM’s on one machine is the best way to utilize CPU power, and if you have good tools to automatically provision the machines and and an appserver with a low footprint, then you can do it. Oracle’s appserver and management tools provided him with such features.

Web Frameworks Shootout

Editor’s Note: This is contributed content, and doesn’t always reflect TSS’ neutrality in such matters. TSS is made up of human editors, of course, and as such, we have biases, but we’d not express them quite this way, nor are we willing to say exactly what those biases are – and no, they’re not often what you might suspect. Let’s leave it at “each framework has its strengths and weaknesses, and each is appropriate for various uses. Thus, we’d be unwilling to stand behind any one framework over another, without detailed and specific requirements for a given implementation.

One of the more interesting talks at Wednesday's JavaONE was the Web Frameworks Shootout hosted on the Esplande level of the Moscone center.  We’ll begin our coverage of this event with an overview of the shoot-out contenders and format.  We will then provide a brief description of the distinguishing points of each framework, followed by a collection of the top quotes and one-liners from the shoot-out.  Finally, we’ll conclude by presenting you with's own scorecard of how each of the web frameworks faired in the shootout, proclaiming our winners for "Best Business Case" and "Best Technical Case".

The Shoot-Out Contenders:

Frameworks Present:
JavaServer Faces, championed by Ed Burns
Webwork, championed by Jason Carreira
Shale, championed by David Geary
Tapestry, championed by Howard Lewis Ship
Wicket, championed by Eelco Hillenius

Frameworks Conspicuously Absent:
Struts 1.x
Ruby on Rails

The Shoot-Out Format:

Round 1: Each contender gets 3 minutes to introduce their framework.

Round 2: Questions from the moderator.

Round 3: Questions from the audience.

The Fight Bell: The moderator, Kevin Osborn, controls a fight-bell.  The fight-bell is rung for any “hits below the belt ” or when a contender has used their allowed amount of time.                                                                                                        

Our Commentary:

One of the major trends we noticed during this shootout was the intense focus on components.  Each framework introduced its own flavor of how a web component should work.  The message to the audience is that reusable web components are all the rage… the major point of contention now is what these components should look like.  We couldn’t help notice, however, that Struts was conspicuously missing.  Still, even while Struts wasn’t formally represented, it was clear all represented frameworks were struggling to free themselves from Struts’ shadow, highlighting how they were “different” and “better”.  While web-framework technology may be advancing and leaving Struts behind, Struts is still the present incumbent as the tried and true framework with thousands of successful projects under its belt.  We couldn’t help noticing that Struts doesn’t include this idea of a web component, so for developers looking for reasons to consider these other frameworks, understanding the idea of a web component is a good place to start.

Framework Overviews (Round 1)

JavaServer Faces (JSF)

  • Technical Features
    • First class UI component and event model
    • POJO Dependency Injection (aka Inversion of Control)
    • Client device independence
    • Use with or without tools
    • Externalized Navigation (similar to Struts Navigation)
    • Massively Extensible (witness Shale)
    • Completely Integratable (witness JSF integrated with Spring)
    • Localizable and accessible
  • Market/Business Distinctions
    • Widespread Adoption, including Sun, Oracle, IBM, BEA, Apache, EDS
    • Part of J2EE 5.0
    • Large 3rd party component market (iLog, Business Objects, Oracle, Sun, IBM)
    • Industry leading tools (Sun Java Studio, Oracle JDeveloper, IBM WSAD, NitroX plugin for Eclipse, Exadel Studio)
    • Many Books Available
    • 3 pages of JSF jobs on Monster (Author’s Note: Compare this to the dozens of pages of Struts jobs on Monster)


  • Core Values
    • Simplicity
    • Testability
    • Maintainability
    • Extensibility
  • View Technology agnostic, supporting JSP, Velocity, and other view technologies
  • Maps HTTP request to a logical (interceptable) action
  • Simple components via the hierarchical MVC and template mechanisms


  • A framework built on JSF technology and Jakarta
  • A proposal for Struts 2.0 (TSS Editor’s Note: Last we checked, there is quite a bit of uncertainty as to whether Shale will actually become Struts 2.0.)
  • A Struts sub-project
  • No direct connection with Struts Classic (ie Struts 1.x)
  • Described as JSF++:  “JSF 1.0 didn’t include everything we wanted to add due to time.  So Shale attempts to add it.  Features like client-side validation, AJAX, etc… are slated for JSF 2.0.  Meanwhile, Shale is a proving ground for those ideas.”
  • Shale Features:
    • Web Flow
    • Ajax
    • Spring and Tiles Integration
    • Client and Server-side Validation
    • Tapestry-like views and parameterized Subtree
    • Utilities: Back-Button abuse, file-uploads, JNDI API
  • Shale’s Extension Points
    • ShalePropertyResolver
    • ShaleVariableResolver
    • DialogNavigationHandler
    • ShaleViewHandler
    • TilesViewHandler
  • “If you know nothing about JSF itself, JSF is very, very extensible.” 


  • Core Values:
    • Simplicity - web applications shouldn't be rocket science!
    • Consistency - what works in pages should work in components. What works in small applications should work in large applications. Different developers should find similar solutions to similar problems.
    • Efficiency - applications should be performant and scalable
    • Feedback - when things go wrong, the framework should not get in the way; in fact, it should provide useful diagnostics
  • Tools:
    • Does not require the use of tools
    • Let you use the design tools you already know.
  • New Features in Tapestry 4.0 (subset):
    • Annotations Support
    • Really excellent integration
    • Much more flexibility in terms of how you manage serverside state.  Very efficient about what it stores in the session, if anything at all.
    • Portlets Support
  • Extensibility:
    • Over 180 extension points
    • Built around Component Object Model with many layers
    • Terrific ability to override, change, and customize
    • Great support for component libraries which are open source and available.
  • "Tapestry is a predecessor, almost a research project, for some of the other frameworks"


  • Wicket is the new kid on the block.
  • "Wicket is Easy, Wicket is Elegant", Wicket is Powerful."
  • Easy to Use:
    • Simple, Consistent, Obvious
    • Reusable Component
    • Non-Intrusive
    • Safe
    • Efficient/Scalable

Noteworthy Quotes:

Editors Note: The Q&A rounds were a bit like a peanut gallery where it was often difficult to tell which contender said which cheap-shot.  Furthermore, there was as much smack talk as there was bonafide technical commentary.  Short of who said what, what was most telling during this round was the overall interplay.  In an effort to capture this interplay without making our contenders feel their comments were misattributed, we’ve included a collection of quotes overheard during the round without necessarily attributing them to their origin.

  • "Everybody is knows that JSF is much better than Struts.  Meanwhile JSF is Neck and Neck with Tapestry"
  • "Struts is old school, so get over it."
  • "If you need a tool like that, your framework is probably too complex."
  • "You can talk about tools, but you can't make people use them."
  • "If you want to save your struts code-base, then JSF is the way to go."
  • “It's the fact you can extend your framework in a standard way and create an artifact that can extend this piece of functionality.  You can't really do that in Struts or Webwork.”  To which someone replied that you don’t need a fancy event model to obtain reuse in a web app.

Our Scorecard

TSS did its best to keep score during the shoot-out.  We decided to score each of the frameworks in a 5-point scale in two separate categories:

  • Technical Features
  • Business Case

Technical Features




JavaServer Faces (JSF)


JSF win’s major points for it’s 1 st class support for true web components.  Our analyst felt allegations of JSFs lack of simplicity and elegance to be unmerited.  JSF is simple to use, powerful, and revolutionary.  And the existence of Shale and Spring -JSF are a testament to the true extensibility of Faces.



Webwork’s hierarchical MVC model was revolutionary in it’s time and served as a fore-runner to many of the web-component models we are now witnessing.  However, we feel Webwork’s HMVC and template facilities are eclipsed by JSFs refinement of these ideas into JSFs truly 1 st class component model.



If Shale stands taller than the other frameworks, it’s because it stands on the shoulders of giants.  By extending JSF to include advanced web-flow, AJAX support, tiles integration, and client-side validation, our judge felt that Shale represents the future of where web-frameworks need to move technically.



Tapestry pioneered the idea of a web-component and set the bar.  The claim during the debate that “Tapestry and JSF are neck-and-neck” isn’t too far off.  However, JSF’s standardized extension points and first-class support for portlet development is a truly compelling technical case against which Tapestry can’t yet compete.  We’ll be watching this race closely.  We’d love to see Tapestry support some of the JSF standard interfaces to support interoperability… specifically we’d love to be able to write JSF components using Tapestry and to use Tapestry components as JSF components.  We’ll be eagerly watching what Howard includes in the next release.



Wicket is the new kid on the block, only having reached 1.0 a few weeks prior to JavaONE.  Our judge didn’t feel it was fair to score Wicket without knowing a little more about it.  However, if Wicket is truly as simple as it claims to be we’ll certainly be keeping our eye on it.  We’d also like to extend to Wicket the same interoperability challenge we just extended to Tapestry.



While Struts wasn’t formally included in the shootout, as the incumbent Struts is the framework by which all other web frameworks are judged.  When Struts was released it revolutionized the web world with it’s inclusion of data-bound controls, action event handlers, and externalized navigation.  Since then, Struts has expanded to include tiles, the struts validator, and extensibility through dynabeans.  However, Struts has also been a victim of its own success, lacking a formal component model chiefly due to the necessity for backwards compatibility trump ing its ability continue to pioneer new ground.  This is why Craig McClanahan, the original creator of Struts, started Shale, in hopes that Shale may one day become the new defacto standard. (*Sorry, .tag files don’t count as web components, since they’re output-only reuse.)


Business Case




JavaServer Faces (JSF)


JSF is now an official Java Standard and will be an integral part of J2EE 5.0.  With endorsements from Sun, IBM, BEA, Oracle, and dozens of other companies, JSF shows a lot of promise.  However, we cannot ignore the limited numbers of deployments currently using JSF.  If JSF wants to win the heart of IT managers away from Struts, it’s going to need a plethora of success stories behind its belt.  Simply naming a few big names, such as FedEx, who have used JSF on a few select projects just doesn’t cut it here.  As strong as JSF is, we’ll be waiting to see those success stories come pouring in before we bet the business on it.  Yet, in comparison to the other frameworks presented at the shootout (remember, Struts was absent) JSF still came in first place with a score of 3.9.



When our judge stood up during the audience questions round and asked each framework for an order-of-magnitude estimate of the number of projects currently deployed using it’s framework, all the frameworks, including JSF hemmed and hawed and dodged the question.  But we simply LOVED Webwork’s answer “ Do I get to count each of Google’s server’s as its own deployment”… if GOOGLE is willing to bet the business on Webwork, that lends a huge vote of confidence.



While Shale builds on top of JSF and is in many ways technically superior, it is still unproven.  From a business risk management standpoint, it’s just too new and its is future too uncertain.  Sure, the claim to fame that Shale is a proposal for Struts 2.0 sounds impressive, but that’s just it, it is just one proposal far from being adopted.  Quite frankly there are a large number of barriers which must be overcome before it’s accepted by the Struts community at large.



Like Webwork, Tapestry is a framework that has been around the block quite a few times and is a robust, proven framework.  (It’s used to power  Tapestry 4.0 offers a whole new set of exciting features.  Yet we feel Tapestry creator Howard Lewis Ship said it best when he described Tapestry as a “research project” for the other web frameworks.  For small elite development teams who want all the latest innovations, Tapestry is great.  For large IT shops looking for wide industry adoption, a large community of experienced developers to choose from, and hundreds of successful deployments to point to, we just don’t feel Tapestry fits the bill (yet).  Our challenge to make Tapestry play nice with JSF still stands… standards compatibility may be just what Tapestry needs to ease the minds of risk-averse IT managers.



As strong as the case for Wicket’s simplicity may be, there are still less than 5 projects using Wicket, all of which belong to Wicket’s author s.  As the new kid on the block, Wicket’s innovations are warmly welcomed.  However Wicket still has a long way to go to prove itself.



With literally thousands of deployed projects using Struts, Struts has been adopted as the framework of choice by IT organizations large and small and won’t be leaving anytime soon.  Struts stuffers slightly from not being an official standard, but it’s status as a “defacto-standard” is nearly as good.  Almost every major vendor now includes Struts support in their products.  A risk-averse IT manager can’t go wrong adopting Struts.

Dig Deeper on Java server pages

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.