Java component based Web frameworks - JSF, Wicket, RIFE etc


EJB design: Java component based Web frameworks - JSF, Wicket, RIFE etc

  1. What is the community experience regarding the component based Java web frameworks? It's definitely a deviation from the traditional web applications which are more based on simple MVC (Struts, Webwork etc).

    Has anyone used the component based web frameworks in production with heavy traffic? If you have, then please provide some numbers to validate.

    Here is what I saw on Wicket website:
    "What is the community experience regarding the component based Java web frameworks? It's definitely a deviation from the traditional web applications which are more based on simple MVC (Struts, Webwork etc)."

    I am not sure storing everything in session is such a good idea. I know of similar concerns regarding JSF. What's the rationale behind storing components in the session? How is this going to scale in a clustered environment with session replication?
  2. There's a long answer and a short answer to this question. The ultra-short answer is something like this:

    Why optimize prematurely? If you build your site and it scales (which the overwhelming majority of projects probably will), you saved lots of time. If your site doesn't scale, THEN locate the hotspots and tune:

    for (page : hotPages)

    To tune a page, investigate the situation:

    If the page is extremely hot, you can invest the effort to make it completely stateless ('bookmarkable' in Wicket lingo) by encoding state in the URL (either using query parameters or a url encoding feature).

    For pages that are only somewhat hot (probably everything but the home page and the most common destinations), you can invest a smaller amount of energy by reducing rather than eliminating the amount of session consumed: (a) make your models detachable (b) do smart things with dirty states to prevent unnecessary replication (c) implement a little static, nested class that recreates the page from a smaller amount of data (the session stores a map of IPageSource implementations, which don't HAVE to be full blown pages... they just have to be able to produce the page on demand) or (d) if none of this works, ask for client-side state in Wicket. For Wicket 2.0 we could easily implement different strategies for client-side state: URLs, cookies and POSTs. The code is definitely set up for it The question is really what priority this should be given versus other features. So far, nobody has demonstrated a real need for the feature and I honestly have questions about whether client-side state ultimately pays off. It introduces a lot of problems and increases bandwidth and CPU usage. The bottom line is that you don't get a free lunch.
  3. I should add one more thing... we have been paying close attention to the size of our components. There's no need to be scared about how big pages are. You can watch that as you develop. There is an 'inspector' tool that shows you the session. You can even look at it live on the web:

    Click on any example and then the little (i) icon in the upper left and you'll get the full details of how much space is being used for what purpose. We've really gone out of our way to make Wicket efficient this way. Most pages are on the order of a few KB. Not that much state to push around on a backplane that is probably far faster than the WAN connection (yet another reason i don't like client side state).
  4. What does this size information mean? I am looking the Library example and the what do these mean?

    Session Size: 704 bytes
    Session Size (Including PageMaps): 8.3K

    Also, if I look at the "Page" section, the addition of all the sizes is around 62k. Is this stored in session? If it is stored in the session, then it's a lot of stuff in the session for minimal functionality.
  5. I can't tell from your description exactly what's going on, but I would bet you a dollar that if you look at the columns more carefully you'll see that the repeated page (probably about 8KB in size) is actually not multiple pages but just different /versions/ of the same page (the id should be the same for each version). So the total session size really is 8.3KB here not 62KB.
  6. RIFE holds of well[ Go to top ]

    RIFE by default stores the state on the client-side, not using the session at all. This makes it very scalable. Even if you choose to store the state in the session, it's very lightweight and traditional distributed clustering solutions should just work.

    The site has been developed in RIFE and has been running stable on a single Redhat Linux 2.4 box for several years now. There are more than 70 thousand unique visitors and 11 million hits per month. The servlet container is Resin and it's running on Java 1.5 with a PostgreSQL 8 database.

    Everything goes through RIFE and content stored in the content management framework (like magazine covers, user avatars, uploaded files, ...) are all streamed straight out of the database through the framework and the servlet container.

    The site is totally built up using components.

    If you need more information, don't hesitate to ask.

    Best regards,

  7. Next time, please choose between posting on either the server side or javalobby. This is a cross post.