Rhino in Spring now with Terracotta support


News: Rhino in Spring now with Terracotta support

  1. Rhino in Spring now with Terracotta support (5 messages)

    Rhino in Spring has now reached its next release, 1.2. Rhino in Spring aims to integrate the Mozilla Foundation's Rhino JavaScript interpreter for Java with the Spring Framework. The current release includes a controller component for the Spring Web MVC that allows you to express complex multipage web flows in your web applications as server-side JavaScript programs. The biggest new feature in the 1.2 release compared to the 1.1 release (on which TheServerSide.com has reported previously), based on requirements of the project being used in real-world enterprise systems, is that now it supports clustering of web flows with Terracotta. This means that the tremendous scalability advantages provided by Terracotta are now available to any web application that uses Rhino in Spring for its web flow, with no changes on the application's part. The distribution provides a Terracotta configuration module. Referencing this module from the Terracotta configuration file is all that is needed to enable Terracotta clustering of a Rhino in Spring based web application, no changes to existing flow definitions are required. For further detail please visit the Rhino in Spring project page.

    Threaded Messages (5)

  2. Example?[ Go to top ]

    Maybe I didn't look hard enough, but I wish I could see a simple example. This sounds a lot like Grails web-flow definitions (which I don't know if it is easily used outside of a Grails app ATM). If so, that's nice though. Whoever thought every god-damn thing should be defined in XML should be shot. Thank goodness projects like Rails+YAML started showing us that using a real language is a million times easier than frickin XML.
  3. Most of these web gui flow products can also store the conversation state in the HTTP Session in which case any clustering product that provides a Session manager will also work with it. This is kind of essential as otherwise the http session data would be out of sync possibly with the conversation state. ObjectGrid from IBM works fine with Spring WebFlow in the this way and I'd imagine with anything else that can store the conversation state in the session.
  4. Billy, storing conversational state in sessions without Terracotta imposes artificial restrictions that shouldn't have to bother developers. The most important one is that all the objects in the state should be serializable and should be maintained over time to properly deserialize and serialize, even when classes change over time. Using Terracotta this is not needed since serialization is not used to perform the state transfer to other nodes. It plugs in at byte-code level, which allows it to break everything down into primitive data structures and send this as fine-grained changes (batched up when needed of course). Given the fact that every variable that is reachable from the script's local and global scope is added to the state, not having to worry about serialization is a blessing. Also, since Terracotta can detect changes deep down in the graph, only individual data elements will be sent around without having the serialize the entire session over and over again. Finally, thanks to the internal data storage format that Terracotta uses together with its approach to applying state, classes can freely add and remove fields over time without causing the developers to have to worry about how older state will have to deserialize into the newer versions of the classes. Field renaming is not something that Terracotta handles automatically though, this still needs some efforts on the developer's behalf.
  5. I also wanted to add that there are many value-added web development frameworks and approaches for which session replication is not sufficient. Wicket - doesn't put its state in sessions Rife - doesn't put its state in sessions either And any Comet-style conversation needs more than just session replication; they need socket state replication so add Kaazing and Jetty w/ Comet to the list As Geert pointed out, session replication is not the same as using Terracotta. What I am saying is that not all frameworks need only session replication in order to be clustered. Anyways, this is very kewl Attila. I would very much like to talk offline about what you have achieved. --Ari
  6. Maven repository download[ Go to top ]

    Is there any maven repository providing download of this framework?