Choosing a JVM Web Framework
I plan on rewriting my "Comparing Java Web Frameworks" presentation for this year's Colorado Software Summit. Rather than "Comparing Java Web Frameworks", I'm going to make it into more of a "Choosing a JVM Web Framework" presentation. I think this opens it up to more possibilities such as Grails, JRuby on Rails, Flex and GWT.
One of the things I hope to talk about is choosing the right tool for the job. I think there's 3 types of web applications you can develop:
- Consumer-facing, high-traffic, stateless applications
- Internal, more desktop-like applications that are stateful
- Media-rich applications that require a RIA framework like Flex
Once you've decided on which of these you're developing, it's much easier to narrow down the choices:
- Struts 2, Spring MVC, Stripes
- JSF, Tapestry, Wicket
- GWT, Flex, OpenLaszlo
I'm not sure if GWT fits in the RIA category. I'm not sure where Rails or Grails fit either. They more closely resemble category #1 than any other, yet there's a lot of speculation about their scalability. I think if that perception can be changed, they'll fit into the first category quite well. However, I don't think they compete with component-based or RIA because they don't hold state or offer rich-media capabilities.
Sidenote: I find the scalability debate quite interesting. There's a fair amount of propaganda in Javaland that scalability can be achieved with appservers and clustering tools like Terracotta. If this is true, I've yet to read good solid proof of it. Most of the "how to scale" information out there suggests "share nothing" architectures that shard data and applications across several servers. Of course, there's scalability and then there's massive scalability. Can appservers and clustering solve massive scalability like Google and Amazon require?
The 2nd and 3rd categories have someone of a blurry line, so I'm hoping to figure out how to clarify that. There's also a lot of other factors that will go into choosing a web framework. What if you're simply trying to replace a home-grown framework with an open-source one? If you want to keep your backend and all its logic, does it make sense to use something like Seam, Grails, JRuby on Rails or even AppFuse? Probably not - all their wizbang features and CRUD generation doesn't mean much if all you're using is the web framework. Also, if your application requires support for non-JavaScript browsers (for 508 compliance), then GWT and JSF can be easily eliminated. I know that there are many claims that JSF doesn't require JavaScript, but I've yet to see a real-world application developed with JSF that expects JavaScript to be turned off. Progressive enhancement is a requirement by many of my clients these days.
What's your opinion? How can we make it easier for developers and companies to choose a web framework? Is categorizing application types a good technique?
I really think you are on to something here. One of the key issues I keep coming back to when dealing with management types is that there is never any one tool for development. Besides the obvious tie to what you are dsicussing, I'm convinced that the minute that any developer or team of developers keys in on any one tool set they are then going to head down to road to oblivion. For example, the cost to change directions clearly go through the roof when a retool becomes necessary.
Learning to love learning seems to be the biggest key to stave off burnout. To me one of the most attractive things about AppFuse is the Swiss Army approach to being able to learn whatever is interesting you at the time. So, to further that mindset by fleshing out the need to look for appropriateness of toolsets depending on the type of project at hand is a very groovy thing.
Posted by Rance Shields on August 07, 2007 at 11:46 AM MDT #
Posted by Jobless on August 07, 2007 at 12:40 PM MDT #
Posted by Matt Raible on August 07, 2007 at 12:46 PM MDT #
I'm in the process of making the decision on a UI framework right now. I wish I could have the goodies of Grails but I think it's necessary to have a common persistence layer in front of data for an enterprise. I can't seem to easily get that with Grails. I would accept either dumping my generated persistence layer (GORM) to something I could use in Java land or somehow making Grails aware of my own domain objects.
Posted by Demian Neidetcher on August 07, 2007 at 12:47 PM MDT #
Posted by Gregg Bolinger on August 07, 2007 at 02:34 PM MDT #
"Once you've decided on which of these you're developing, it's much easier to narrow down the choices:
1. Struts 2, Spring MVC, Stripes
2. JSF, Tapestry, Wicket
3. GWT, Flex, OpenLaszlo"
I would be very interested to hear your thoughts on those options. There is definitely a lot of confusion on that area today. Unfortunately i will not be able to make it to your presentation so I'll appreciate if you could share your thoughts among those who can't make it:)
Most of the "how to scale" information out there suggests "share nothing" architectures that shard data and applications across several servers. Of course, there's scalability and then there's massive scalability. Can appservers and clustering solve massive scalability like Google and Amazon require?"
I think that any discussion on new frameworks need to cover the scalability aspect. Scalability clearly becomes one of the more difficult (and interesting) challenges in almost any web 2.0 application. The following presentations Webapps scalability is a good indication to that.
The "scalability pattern" article on infoq portal summarizes the main scalability patterns and provide good intro to those interested to learn more about this topic.
"I've yet to read good solid proof of it."
You can find some references from our customers experience here.
Obviously the best proof is trying it yourself. I invite you to play with our openspaces spring framework yourself and see that scalability can be made quite simple as well.
Nati S.
GigaSpaces
Write Once Scale Anywhere
Posted by Nati Shalom on August 07, 2007 at 02:48 PM MDT #
Wicket scares me a little because of stuff like "add(new Label("footer", "This is in the footer"));" just seems ugly to me. Whats your take on Seam? I haven't really looked into yet too deeply. Geert is trying to get me to look at RIFE too.
Posted by Dan Diephouse on August 07, 2007 at 03:41 PM MDT #
Posted by Restless on August 07, 2007 at 03:58 PM MDT #
Interesting point. One framework that I would encourage you to add to your list though - and I'm not involved other than being a highly impressed user - is Seam. That's the EJB3/JSF/Facelets glue layer currently under JBoss guidance. I know that you tossed it off with a "probably not [worth it]" comment, but one thing that it does really, really well is handle stateless, database backed apps.
It works very well at both layers (1) and (2) in that list. While it contains a ton of stateful improvements, basic (even RESTful) stateless apps are pretty trivial and easy to work with. The mere fact that it solves the lazy loading exception means that its a lot easier to work with even in a stateless app than the others you mentioned.
On top of that, some of the Facelets tie-in improvements such as doing seamless PDF and Email generation are really nice to work with - not a feature that was particularly compelling until we started working with it, especially with facelets templating allowing our designers to work on PDF/Email templates easily. Sure, there are other solutions, but this one seems to be a whole lot simpler.
As for scalability, it builds on EJB3 and thus has some pretty decent cluster-awareness built in. This goes from handling the failover of an EntityManager that had modified beans associated with it, to minimizing the scope of Session objects, etc. The biggest advantage that I've found (and its one they like to brag about, but it is valid) is that by formalizing a conversational scope its possible to use (and cluster) items in that scope without hitting the backend database - and yet its easy to have those items removed to avoid Session creep. Even nested conversations work as you'd expect them to. Its really pretty cool.
Yeah, the "just as easy as RAILS" CRUD stuff is interesting, but I know that we're not even using it. Some of the advocation makes it hard to look past that at the core, though.
Posted by Richard Stanford on August 07, 2007 at 06:40 PM MDT #
For category #3 - RIA, one thing we've been finding is that to truly scale client use cases with rich interactions, you might as well cross off an HTML/JavaScript based solution. The reasoning is that if you make a commitment to change your development methods and deployment strategies and or paradigms, then you might as well pick a technology that goes beyond the limitations of HTML/JavaScript.
It scares me sometimes when I read AJAXIAN and some of the practices they advertise with behavior decoration and HTML widgets-- some of it just doesn't scale at all beyond toy examples.
An example-- client-side sorting and filtering of data really is capped at a max of 200-300 items if you statistically take the most common hardware/browser combination out there with reasonable execution times.
So if you are committing to a browser-based solution, you might as well pick a solution which allows the server to maintain slices of data in an efficient manner within traditional page paradigms and a touch of AJAX. Going 'balls-out' AJAX as an RIA solution can quickly contradict the desired ubiquity and reachability of your solution in my experience. That's not to say you can code in performance accommodations, but then why choose that route in the first place?
Solutions like SOA-based AJAXish JSON and XML data passing uber architectual hub-bub might sound like a good idea, but while you can marshall state from Java to JavaScript for browser-based RIA, you can't marshall behavior. I've raised this question with many and no one's been able to give me a good answer as to what they've gained besides possibly duplicating logic in Java and in JavaScript.
Posted by Jacob Hookom on August 07, 2007 at 07:14 PM MDT #
Posted by Rob on August 07, 2007 at 08:39 PM MDT #
Well, I guess it's hard to argue about taste. But take something like:
add(new TextField("name", new PropertyModel(person, "userName")); add(new Button("save") { public void onSubmit() { personService.save(person); } });I think that is clean and explcit, and as close to normal Java programming (and HTML for that matter) as you can get. Pretty elegant imho.
I can understand that many people want a programming model that lets them avoid writing any code as much as they can (typically declarative programming models, though you'll pay in terms of out-of-the-box flexiblity) and/ or prefer a framework that lets them script in their templates. But writing code like this 'ugly'? Nah, I completely disagree with that.
Posted by Eelco Hillenius on August 07, 2007 at 09:20 PM MDT #
Imho GWT should be placed in category #2.
It is good you make the distinction between (potentially) high traffic public facing applications and intranet applications (I'd argue that any application that requires logging in before being able to operate it can be put in the latter category).
The interesting thing is that most of the attention in discussions on frameworks focus on public facing/ high traffic. But my hunch is that 90% of the people who read this discussion are *not* building applications that have to scale well beyond a few thousand concurrent sessions. Imho, if you're building for the ultra scale, you do what the big guys do: write something completely tailored for you situation. But if you're not operating on that scale, use frameworks that give you the best trade offs between developer productivity and maintainability of the code you produce, and just make sure it scales good enough.
You could poll your readers: is the web application you are building now public facing or internal, what is the average load (concurrent sessions), and what is the peak and what does your cluster look like (if any)? That would be very interesting to know imho.
Posted by Eelco Hillenius on August 07, 2007 at 09:49 PM MDT #
The "big guys" had to invest lots of $$$ and effort to achieve that. They have done so simply since there was no available alternative at the time.
For them the effort was worth the investment even if that led to huge investment since there was simply no other choice. There are many others that are not that big and there are even more that want to become the next YouTube sometime in their future. The challenge then is that they can't afford putting the same level of investment as the "big guys" could and are therefore often find themselfs compromise on the type of architecture they are using knowing that at later stage they will probably be required to build it from scratch. As the problem becomes more and more common new framework emerges, those framework reduces the effort and level of investment required to address the scalability challenge and therefore makes it much more affordable and simpler than it used to be in the past - so the question IMO is why wouldn't you build your application for scalability from the get to go (assuming that its already been made simple through those frameworks) and not the opposite way around.
For me its enough to see the level of complexity and work that need be done to build even small-medium site as described here to justify looking at the new approaches.
Keep an open mind
Nati S
GigaSpaces
Posted by Nati Shalom on August 08, 2007 at 03:11 AM MDT #
Few points about Grails. First of all its a Spring MVC + Hibernate app under the covers with a thin Groovy layer. Scalability has not been an issue on any live deployments yet, but if worse comes to worse you can fallback to Spring MVC controllers for the bottlenecks ( a situation that rarely arises in 95% of apps).
Second, I can't speak for Rails, but your comment about "..I don't think they compete with component-based or RIA because they don't hold state or offer rich-media capabilities.." is false for a couple of reasons. Firstly, in Grails 0.6 we have integration with Spring webflow which provides for stateful applications and services: http://grails.org/WebFlow.
Also, want RIA with Grails? We have a Open Lazslo plugin (http://grails.org/OpenLaszlo+plugin) and a recently released GWT plugin (http://grails.org/GWT+Plugin). GWT is a client-side framework that can be used with any server side, including Grails.
Regarding CRUD, any Grails or Rails user will tell you that CRUD is not what makes the framework what it is and is only a small part of the picture. In fact i would go as far as saying it is great for demos, but in the real world rarely useful.
@Demian - You can use GORM with domain models written in Java and mapped with Hibernate, you're not restricted to Groovy for your domain models (see http://grails.org/Hibernate+Integration)
Finally, no offense Matt, but I fear you are a grossly inappropriate person to be writing such a study given your past history of claiming frameworks like Grails are competitors to AppFuse (http://raibledesigns.com/rd/entry/appfuse_and_groovy_grails). Any such study will come laced with doubts over its honesty and I'm sure this doesn't just apply to Grails.
Posted by Graeme Rocher on August 08, 2007 at 07:15 AM MDT #
Posted by Dave Hodson on August 08, 2007 at 08:50 AM MDT #
> no offense Matt, but I fear you are a grossly inappropriate person to be writing such a study given your past history of claiming frameworks like Grails are competitors to AppFuse. Any such study will come laced with doubts over its honesty and I'm sure this doesn't just apply to Grails.
Graeme - I've written up a response in a separate post titled AppFuse vs. Grails vs. Rails. I hope this clears up any confusion.
As far as a study, I'm simply writing a presentation, not any sort of whitepaper, article or book. I'm (honestly!) just trying to figure out a way to help companies (and developers) choose the write tool for the job. From your comments, you seem to imply that Grails is the ultimate web framework, capable of doing anything you want it to do and suitable for any type of web applications. Do you really believe that? There has to be at least some types of applications it's not suitable for.
If not, then perhaps my "application categorization" is a flawed view. If Grails is truly the Holy Grail, then is its only flaw is that it's written in Groovy? I realize many view this as a strength, I'm just trying to figure out if there's anything wrong with it. Maybe there isn't and I should just get off my duff and start learning it and recommending it to all my clients. ;-)
Posted by Matt Raible on August 08, 2007 at 10:32 AM MDT #
I'd suggest adding a category:
2.a. Internal applications that are stateful.
The distinction is that not all internal apps need desktop-like features and not all require a lot of scalability. (I won't quibble on the definition of "stateful".) I'd keep the existing category 2, for internal apps that need desktop-like features.
For toolkits, I'd suggest enhancing your list:
2.a. Struts 2, Spring MVC, Stripes, JRuby on Rails, Groovy/Grails.
This recommends toolkits for more "normal" or "old school" web applications, that is, web apps without needs for desktop-like components nor for rich interaction. (And, I don't mean to imply anything regarding the suitability for any toolkit, such as Grails, for any task.)
-Eric
Posted by Eric Foster-Johnson on August 08, 2007 at 10:48 AM MDT #
Nati, I'm not saying scalability is not something to consider. I believe it is something you should plan for right from the start. It is important you'll always have 'a way out' if the need arises. And if that can be done with off-the-shelve technology so that you can save money and/ or keep focussed on the business problem you are trying to solve, that's only good. In fact my point about 'the big boys' concerned *extreme* scaling, where a little inefficiency can mean the difference of a couple of thousand extra servers. As most people are not operating on that scale, OTS products to help them scale are a much better idea.
What I am arguing against however, is the idea that scalability always has to be everyone's #1 concern. Many organizations bought into EJBs (1 & 2) because it was supposedly the only way to scale Java applications to the enterprise scale. They wasted millions and millions on extra development. Much in the same way, many people often make the assumption that 'stateless programming' (read: procedural programming) is the only way to create scalable web applications. Many are willing to go through extra pain upfront to have a warm fuzzy feeling about how their application will scale if it ever needs to, in the processing completely killing the scalability of their development effort.
Scalability should be a consideration in web frameworks, but alongside, not above other considerations. In my experience and from what I read, the major part of money spent on (web) applications is spent after the 1.0 version a.k.a the maintenance phase. Sometimes that concerns the efforts of scaling it (and in my experience this is often related to data handling), but often it concerns bug fixing, refactoring and implementing new issues; and for these things it is very important you have a maintainable code base. Unfortunately, maintainability and scalability of the development effort seems to be not nearly as interesting to talk about as it is to talk about scalability and whether frameworks are 'agile' and support rich user interfaces.
Posted by Eelco Hillenius on August 08, 2007 at 11:38 AM MDT #
Posted by Ray Davis on August 08, 2007 at 12:44 PM MDT #
Posted by Matt Raible on August 08, 2007 at 12:47 PM MDT #
Or is it that many web applications try to act like desktop applications? If that is the case - like I think it is -, why not pick a framework that supports that :) Obviously, such frameworks will have to deal with reality and have solid answers for things like concurrency. But the ones I know of do.
Posted by Eelco Hillenius on August 08, 2007 at 01:15 PM MDT #
Eelco: It may sound eccentric, but really I _don't_ want my web applications to try to act like a single-state desktop application. Are you saying that it's easy for Wicket to support multiple concurrent request-to-request flows from a single browser? Or are you saying that it's not impossible to manage something like that on the rare occasions when a Wicket developer wants it? If it's the former, I'm suddenly even more interested in Wicket. :)
Posted by Ray Davis on August 08, 2007 at 02:14 PM MDT #
Maybe you can state what exactly you mean by 'multiple concurrent request-to-request flows'. Can you give use case(s)/ example(s)?
Posted by Eelco Hillenius on August 08, 2007 at 03:02 PM MDT #
Matt,
You call Terracotta "propaganda", but I want to state that your concerns and assertions line up with my thinking--basically, I agree with you. Unlike lots of vendors out there now talking about "grids" and "linear scale" and "infinite" such and such, I think that sharding and share-nothing is Amazon's (as an archetype) only approach. There should be no debate. The scale is huge. And the uptime has been phenomenal on these Web Giants. Their architectures are consistent in that those architectures are autonomic, linear scale, share nothing architectures.
Everyone I have spoken to on Wall Street says that no vendor sells off the shelf multi-thousand-node scalability solutions (and those users have actually tried several products). Terracotta does not try to claim infinite linear scale. Our customers have tens of nodes, up to 150 nodes. And, those customers use us to get simple scalable high availability. No propaganda. Just a different definition of scale in your usage than mine, Matt.
Would love to talk further..
Posted by Ari Zilka on August 08, 2007 at 03:43 PM MDT #
I fully understand that at early stages of the development and deployment cycles there are things like testability, the ability to deploy changes rapidly that becomes a more tangible value.
Interestingly enough i think that there is correlation between all those aspects since they comes back to the architecture - as i discussed here: Testability ? the orphan child in distributed systems
Posted by Nati Shalom on August 08, 2007 at 05:16 PM MDT #
<quote> Graeme - I've written up a response in a separate post titled AppFuse vs. Grails vs. Rails. I hope this clears up any confusion. </quote>
Thanks for clearing that up.
<quote> From your comments, you seem to imply that Grails is the ultimate web framework, capable of doing anything you want it to do and suitable for any type of web applications. Do you really believe that? There has to be at least some types of applications it's not suitable for. </quote>
No of course not, it is what makes the Java space so interesting. It would be a shame if we only had one framework (especially if it was Struts ;-). I definitely see cases where if you need a more specialised framework maybe for XML processing then something like Cocoon may be a good fit or if you are in a corporate situation where the business is not to fussed about how it looks then maybe Seam/JSF with its WYSIWIG editors and components is the way to go.
What I am saying though is you can't lump Grails into a category (and the same applies to some others) as you can do stateful applications and you can use it in combination with RIA tools like Flex, Ext, GWT and Lazslo. You can even use Wicket as a view layer with Grails (http://grails.org/Wicket+Plugin)
And yes some will regard being in Groovy a flaw whilst others will say its a blessing. Everyone has an opinion ;-)
Posted by Graeme Rocher on August 09, 2007 at 02:44 AM MDT #
Too early to alter your statement about no-javascript ruling out GWT but http://code.google.com/p/gwt-html/ might one day undermine it.
I've just started a new project where I've been asked to use struts 2. It feels _very_ painful after GWT.
Posted by Sam Hough on August 10, 2007 at 08:08 AM MDT #
Sam - it's probably too early to consider GWT-HTML.
;-)
I'd be curious to hear your thoughts on why you like GWT so much. Is it the programming API or the development model? I think a lot of projects suffer from difficult and over complicated test/deployment models. They end up blaming their framework when it often has nothing to do with the framework.
I'm definitely excited to learn GWT. However, I don't know how much client work will result from my GWT knowledge.
Posted by Matt Raible on August 10, 2007 at 08:18 AM MDT #
After GWT it strikes me that matching up entry fields, buttons etc with manipulation of the model and managing scope (request, session etc) feels very tedious and error prone. We are using Struts 2 with JSP/JSTL and tiles so compared to GWT it is also much less consistent.
Perhaps another framework like Wicket would feel less clunky but my tech lead wanted to use something he could recruit for easily.
A few years ago I would have loved Struts 2. I like that my actions can be POJOs, wildcards are very handy etc etc I think I can write a nice enough application but it won't be as good, will take me longer and will be more difficult maintain than a GWT app.
Another pressure is that users and clients expect much more dynamic website. I think I can deliver these better given GWT.
btw I was dubious about your "con" of difficult to search for "Struts 2" but it is a real pain.
Cheers SamPosted by Sam Hough on August 10, 2007 at 08:59 AM MDT #
Saddens me to read that. Not because you're not using Wicket (or GWT which I agree is a very nice framework), but that people (your lead) are making technical decissions based on how easy it *supposedly* is to find people for a certain technology.
Hire good people. Any good programmer will be able to pick up any framework in a few days, especially if you already have someone in the team who knows it and have some code to build on.
Posted by Eelco Hillenius on August 10, 2007 at 11:53 AM MDT #
I'm probably doing my lead an injustice. Presumably part of his thinking is trying to pick a framework that is going to have a healthy community for years to come.
Hiring good people is not easy. I'm working at a small publishing company near to the financial heart of London. So if you have the right CV you can earn twice as much a mile down the road. Presumably it is also a great strain on their time to interview enough people to find the good ones.
Maybe he will be better off hiring people who can bash out struts code. Although looking at one of the biggest jobs sites in the UK their is only one hit for "struts 2"
Posted by Sam Hough on August 11, 2007 at 02:54 AM MDT #
Matt,
I am really looking forward to this presentation as I think given the number of selections available to both Architects/Lead Developers and Management they really need some guidance so that they do not go astray. I took a short trip over to the SOA consulting side which is just a fraught with mis-information, confusion and just plain bad technology designs and decisions as the presentation side. It is shocking the number of companies that have selected a technology for some reason and now are struggling with scalability, deployment, testing, compatibiity issues as well as they have selected technologies for which no source of local development talent exists.
I hope you will consider both the technology side as well as the soft side of the selections. By "Soft Side" I mean availability of resources locally, documentation, support and maintenance, mailing lists and blogs for best practices, history of usage in their specific industry.
I look forward to your presentation. I hope someone does something similar in the SOA world as well as it is sorely needed and is experiencing as much turmoil as the Web 2.0 world.
Have you considered an alternative that uses no web framework at all but it purely ajax, xhtml and css?
Scott Ryan
Posted by Scott Ryan on August 12, 2007 at 02:52 PM MDT #
Thought I'd add that we are going with Wicket after a flirtation with Struts 2. I'd still rather have gone with GWT but because of a wish to support old browsers and a concern about how the HTML coder would work with Java coders it was dropped.
For what it is worth my first impressions are mixed. The coupling of HTML fragments with code is lovely. A breath of fresh air after struts 2. We also have a wiz-bang Ajax version where Wicket does look poor compared to GWT.
As of now I think my biggest concern is the complexity of Wicket. Trying to manage a component based UI on the server is not a simple task and a lot of that seems to creep through to the developer.
Don't want to detract from what a well thought out framework Wicket is. For a web app using Ajax lightly it does everything very nicely.
Posted by Sam Hough on August 23, 2007 at 02:49 AM MDT #
Posted by Joshua Java on August 24, 2007 at 02:39 AM MDT #
I would just add that another possibility is not to choose at all. After all there can be parts of applications that are stateless, media-rich or desktop-like (a big scale example is a front-end and a back-end application which manage more or less the same thing and would be cheaper to build as one application broken in parts).
Perhaps you should take a brief look at Aranea Integration (that allows to use several approaches (with appropriate frameworks) at once. At the moment we support Struts 1, GWT and JSF with WebWork (+ Struts 2) and Spring MVC coming next month. And of course more will come as time passes (Wicket and Tapestry are next on the list).
Aranea itself is an MVC framework that falls into the 2nd category and is heavily Object-Oriented, but I wouldn't dare suggesting it if you haven't found it yourself. Aranea Integration on the other hand is a completely novel approach that isn't found elsewhere at the moment.
Posted by Jevgeni Kabanov on August 26, 2007 at 10:18 AM MDT #
JQuery has changed my view on web application development. As I look at code snippets of GWT and Wicket and Tapestry for say an onclick action, I notice that JQuery just seems better. Grab the element using the great JQuery selectors (CSS or XPath) and then add the click method.
And then of course, you can debug the JQuery javascript using Firebug.
Has anyone else changed their view of application development after using JQuery?
Posted by Tom on August 26, 2007 at 10:21 AM MDT #
Posted by Tom on August 26, 2007 at 10:23 AM MDT #
I'm a month-and-some late in answering Eelco's question, but what's a month-and-some between friends? :)
Most non-Java web sites would be examples. To put a bit more nuance on it, it should be possible to tear off a new window or browser-tab from any link that doesn't post updates to the DB, and then maintain parallel workflows complete with back-button. Experienced users and developers of sticky wide-ranging sites want to support this for all sorts of reasons ranging from "what if?" comparisons, to context-specific event monitoring, to simple convenience. Amazon doesn't keep me from sorting through a DVD search in one window while I check out a book excerpt in another window; similarly, I don't want to restrict university instructors to viewing one discussion section at a time.
Scalability issues aside, from a functional point of view, too many Java-powered websites use session scope when they should really either be using persistent storage (to save drafts or user defaults, for example) or request-to-request work flows.
Anyway, off to look at the state of stateless and bookmarkable Wicket....
Posted by Ray Davis on September 21, 2007 at 10:14 AM MDT #
Posted by nazar on September 30, 2007 at 04:03 AM MDT #
Posted by Steve on September 30, 2007 at 09:54 AM MDT #
Posted by Max on December 16, 2007 at 09:02 AM MST #
However, I think there is another category:
- Applications/Components living inside a portal (a la JSR 168) or web content management solution.
Also, I think the point about 'Stateless' and 'Staetful' should be described more accurately in terms of:
1. Pattern A: Stateful browser/ stateless server tier/ stateful database
2. Pattern B Stateless browser / stateless server tier / staeful database
3. Pattern C: Stateless browser / stateful server tier / stateful database
Just my 2 cents.
Yuval Goldstein.
Posted by Yuval Goldstein on November 11, 2008 at 06:15 AM MST #