We are proud to announce version 1.6 of the Mentawai framework now featuring sticky actions, the Mentawai approach for continuations. There are also new tags for ajax, paginator tag, support for configuration in Groovy, and more. An explanation of "sticky actions:" take the classical Number Guess game, where you try to guess a number between 0 and 100 while the computer tells you if your guess is higher or lower. (An example can be found at http://rifers.org/03_numberguess.) There can be a lot of state that needs to be mantained such as:

• The secret number (game solution)
• How many guesses have I done so far
• How long have I been trying to guess

The standard solution to this problem is to place everything inside the user session (HttpSession), but Mentawai offers a different solution: Sticky Actions. Sticky Actions will persist its state across multiple invocations from the time you call adhere() until you release the action by calling disjoin(), in other words, the same action instance will be used for sucessive action requests. You can also trap the onRemoved() callback for those cases where the session expires or gets invalidated before the disjoin() method was called. (Ex: User leaves the page or closes the browser). Below is an example of how you could implement the Number Guess game using the session. Then we show an example of the same implementation using a sticky action. Code: public class NumberGuess extends BaseAction implements Validatable { public static final String BINGO = "bingo"; public static final String FIRST = "first"; public static final String WRONG = "wrong"; private static final Random random = new Random(); private void incrementGuesses() { Integer i = (Integer) session.getAttribute("guesses"); session.setAttribute("guesses", new Integer(i.intValue() + 1)); } public void initValidator(Validator val, String innerAction) { val.add("guess", new IntegerRule(0, 100), "Invalid guess!"); } public String execute() throws Exception { // Check if a game is in progess, by fetching the current answer... int answer = -1; if (session.getAttribute("answer") == null) { answer = random.nextInt(101); session.setAttribute("answer", new Integer(answer)); session.setAttribute("guesses", new Integer(0)); } else { answer = ( (Integer) session.getAttribute("answer")).intValue(); } if (input.getValue("guess") != null) { incrementGuesses(); int guess = input.getIntValue("guess"); if (answer == guess) { output.setValue("answer", session.getAttribute("answer").toString()); output.setValue("guesses", session.getAttribute("guesses").toString()); session.removeAttribute("answer"); session.removeAttribute("guesses"); return BINGO; } else { if (guess < answer) { addMessage("Number is higher!"); // of course this can be i18n... } else { addMessage("Number is lower!"); // of course this can be i18n... } return WRONG; } } return FIRST; } } Here's the version using sticky actions: public class NumberGuessSticky extends BaseAction implements Validatable { public static final String BINGO = "bingo"; public static final String FIRST = "first"; public static final String WRONG = "wrong"; private int answer = -1; private int guesses = 0; private static final Random random = new Random(); public void initValidator(Validator val, String innerAction) { val.add("guess", new IntegerRule(0, 100), "Invalid guess!"); } public String execute() throws Exception { System.out.println("Executing action: " + this.toString()); // Check if a game is in progess, by fetching the current answer... if (answer == -1) { answer = random.nextInt(101); guesses = 0; adhere(); } if (input.getValue("guess") != null) { guesses++; output.setValue("guesses", String.valueOf(guesses)); int guess = input.getIntValue("guess"); if (answer == guess) { output.setValue("answer", String.valueOf(answer)); disjoin(); return BINGO; } else { if (guess < answer) { addMessage("Number is higher!"); // of course this can be i18n... } else { addMessage("Number is lower!"); // of course this can be i18n... } return WRONG; } } return FIRST; } }What do you think of the continuations-based approach? Message was edited by: joeo@enigmastation.com

I'm really curious how much more bastardizations of continuations we're going to see. What Mentawai does is simply allow you to re-use the instance of an action for the next requests and give it up later. There's no capturing of local state, there's no continuation tree, hence there's no implicit back-button support, no concept of a conversation, ... It doesn't even support suspend and resume from any program location!!! All it does is this: (http://svn.sourceforge.net/viewvc/mentaframework/mentawai/src/org/mentawai/core/Controller.java?revision=148&view=markup) static void adhere(StickyAction action, Class actionClass) { Context session = action.getSession(); StickyActionMap map = (StickyActionMap) session.getAttribute(STICKY_KEY); if (map == null) { map = new StickyActionMap(new HashMap()); session.setAttribute(STICKY_KEY, map); } map.put(actionClass, action); } static void disjoin(StickyAction action, Class actionClass) { Context session = action.getSession(); StickyActionMap map = (StickyActionMap) session.getAttribute(STICKY_KEY); if (map != null) { map.remove(actionClass); } } Sergio, there's no doubt that Sticky Actions can be useful for people and that there are valid use-cases. Please, don't portrait it as continuations while they aren't. You'll be doing everyone a favor (yourself, your users and the community).

Hey Geert, I checked your RIFE "number guess with continuations" example [1], and must say that it's the most elegant solution for this (trivial) problem i'v seen, ever. The Mentawai way seems also very functional, although i'm not sure if it handles some of the more complex issues like browser back buttoning and multiple browser windows. Now, if all you smart people would start consolidating your efforts under couple of major platforms (JSF would be one candidate) there might actually be some hope for enterprise java, and significant amount of users for your code. -Henri [1] RIFE number guess

Thanks a lot Henri! While these are indeed trivial problems, native Java continuations become very interesting when you start using it for more complex flow control. Like for example this simple checkout process: source live examble This is again of course a slimmed dowm example, but it has some nice features such as 'step back' buttons in the form with partial model object submits and conversation invalidation at the end of the process (transactionality). I'll be open-sourcing a continuations-based real-world checkout process that I wrote for Greenpeace soon. About standardization, you'll be happy to know that I reserved a number of weeks specially for this in November and December. I'll submit a JSR and a draft of a fully functional standalone reference implementation. This will most probably also be the library that will be used by Struts Action 2. Take care, Geert

I am sorry if we passed up this impression in our post, but we are not trying to bastardizate continuations. We are just trying to offer a simple solution to persist state across requests in a way more natural than the http session object. Perharps you could help us describing the particular situations where extra complexity is desirable and justified. Again this is just a very straighforward and easy way to mantain state across requests in a way more natural than the session http object. Nothing too much ambitious, but for simple cases, where we believe are the majority, this will be a welcome, simple solution.

I am sorry if we passed up this impression in our post, but we are not trying to bastardizate continuations. We are just trying to offer a simple solution to persist state across requests in a way more natural than the http session object.

Sure, just don't say that it's equivalent to continuations then. It's simply not true, you don't have any of the benefits that continuations provide.

Perharps you could help us describing the particular situations where extra complexity is desirable and justified.

Again this is just a very straighforward and easy way to mantain state across requests in a way more natural than the session http object. Nothing too much ambitious, but for simple cases, where we believe are the majority, this will be a welcome, simple solution.

Which extra complexity? RIFE's version is actually extremely simple. To use the core functionalities of continuations you only have to use the pause() call wherever you find it appropriate. That's just one method! If you wonder about the benefits of continuations for the web, just search the web, there's enough information available about it. You could also look at one of my presentations on the subject: http://uwyn.com/resources/flow_with_continuations_tssjs_2006.mov http://uwyn.com/resources/flow_with_continuations_tssjs_2006.pdf I can quickly repeat some of the obvious things that Sticky Actions are missing: no notion of flow control (you don't pause and resume anywhere you want), no local variable state capturing and restoring, no versioning of states to support back button support, no step back support, no call and resume support (kind of like modal dialogs, as opposed to pause and resume), ... Actually your solution has nothing to do with continuations at all. It's a solution to a certain kind of state management problem, period. I don't see why you have to latch onto the name of something that it totally isn't.

Geert, After reading your presentation I now understand that the name continuations was wrongly used by me. As you said it describes a much broader concept than simple state management and persistence across requests in a web application. I will correct the Mentawai website not to refer to this definition for sticky actions. HOWEVER, let me share my impression that continuations is being overvalued for web applications. I may be wrong so feel free to throw in some arguments against this statement. The RIFE continuations example is very simple and does not re-inforce all the other features/advantages you claim here. That's why I was wrongly led to believe that continuations were something simple.

no notion of flow control (you don't pause and resume anywhere you want), no local variable state capturing and restoring, no versioning of states to support back button support, no step back support, no call and resume support (kind of like modal dialogs, as opposed to pause and resume)

Why do you need to persist the state of local variable when you have instance variables of the action ????????? Where do you need to pause and resume when you can accomplish that with actions ? Every action is a step, then you pause and wait for the other action. Maybe because RIFE has a component model instead of a MVC model, it makes more sense to have continuations with pause and resume? I don't understand (and here i think I am missing something) how continuations can help with the back button problem. Do you have links that may clarify this issue? To conclude, at least for the classical problems like the Number Guess game or the multi-page registration, where state needs to be managed over multiple requests, STICK ACTIONS seems to do the same job with a more natural and simple approach that does not need all the complexity (like Byte Code modification, context switch, etc) that continuations inquire. So I was led to believe that sticky actions were enough to solve the majority of problems that continuations address.

Geert,

After reading your presentation I now understand that the name continuations was wrongly used by me. As you said it describes a much broader concept than simple state management and persistence across requests in a web application. I will correct the Mentawai website not to refer to this definition for sticky actions.

Thanks a lot Sergio. It's wonderful that you take this position and plan to update your website. The concept of continuations is easily wrongly or only partially understood by people. By not referring to them anymore with regards to Sticky Actions, you will prevent others from being confused also.

HOWEVER, let me share my impression that continuations is being overvalued for web applications. I may be wrong so feel free to throw in some arguments against this statement.

The RIFE continuations example is very simple and does not re-inforce all the other features/advantages you claim here. That's why I was wrongly led to believe that continuations were something simple.

no notion of flow control (you don't pause and resume anywhere you want), no local variable state capturing and restoring, no versioning of states to support back button support, no step back support, no call and resume support (kind of like modal dialogs, as opposed to pause and resume)

Why do you need to persist the state of local variable when you have instance variables of the action ?????????

Where do you need to pause and resume when you can accomplish that with actions ? Every action is a step, then you pause and wait for the other action.

Maybe because RIFE has a component model instead of a MVC model, it makes more sense to have continuations with pause and resume?

I don't understand (and here i think I am missing something) how continuations can help with the back button problem. Do you have links that may clarify this issue?

To conclude, at least for the classical problems like the Number Guess game or the multi-page registration, where state needs to be managed over multiple requests, STICK ACTIONS seems to do the same job with a more natural and simple approach that does not need all the complexity (like Byte Code modification, context switch, etc) that continuations inquire.

So I was led to believe that sticky actions were enough to solve the majority of problems that continuations address.

Sergio, what does the complexity of the implementation have to do with any kind of complexity towards the user of the feature? Support for pause and resume anywhere with local state capturing makes it possible to leverage the control statements in Java for flow control. In fact, this approach makes everything immensely more simple. All people have to know is Java. Whenever they need information from the user, they just pause the execution, which will resume when the response comes in. It really creates a one-to-one communication channel between to user and the application. In terms of complexity to the developer, it reduces an anynomous stateful multi-user model to a private stateful single user model like in the old days where readline() was sufficient to pause the execution and retrieve the answer from a user in a desktop application. They can use local variables to skope state, just as in Java. They can use while to loop conditionally, if to branch out, etc. etc. Without having to split up the flow artificially into multiple actions if the process is just a single transactional one. This makes development a huge amount more simple since complex stateful flow control only requires the knowledge of the Java language. Browser back button support is achieved through the cloning of each continuation step by default (this can be easily turned of if this behavior is not wanted). Each state transition is thus cleanly isolated and a continuation 'conversation' really consists of a tree where peoply can freely open multiple browser windows, navigate back, branch out, etc. This has all nothing to do with the component model/action model (I suppose you meant action model, since I don't see what MVC comes doing in this picture: it's not unrelated to components or actions). WebWork is using RIFE's continuations in an action based framework. To conclude, already for simple classical problems, your approach requires people to handle flow control and state transitions with a custom approach. Using continuations this simply requires them to know Java. I personally think that the amount of simplification that this allows, warrants any kind of complexity in the implemention of the feature in the framework. Isn't that what frameworks are for, to take care of the complex stuff and make everything even easier for developers?

Gah, sorry for the typos above, I pressed Post instead of Preview: skope = scope, not unrelated to components or actions = not related to components or actions.

Spring 2.0 has added new scopes for their bean. they have 1. singelton 2. prototype 3. request 4. session 5. global session and 6. custom scope "custom scope" can help to have a simple implementation of "continuations".

Geert can correct me if I am wrong, but it looks like Spring 2.0 custom scopes has only to do with state persistence and not continuations. I guess we all are thinking about continuations as continuing a task across multiple requests, turning the stateless characteristic of the HTTP protocol and making it stateful. But not using the ancient and awkward http session...

Geert can correct me if I am wrong, but it looks like Spring 2.0 custom scopes has only to do with state persistence and not continuations.

I guess we all are thinking about continuations as continuing a task across multiple requests, turning the stateless characteristic of the HTTP protocol and making it stateful. But not using the ancient and awkward http session...

1. It was not Geert who mentioned Spring, but Khalil 2. The concept of continuations is often misunderstood, but I don't think anyone in this thread, besides you, thinks of continuations as a sequence of action calls I think that what Khalil tried to say is that your aproach is more like (a less powerful version of) Spring's scoped beans than RIFE's continuations.

1. It was not Geert who mentioned Spring, but Khalil

Thanks, but I was aware of that. I mentioned Geert, because from what I have read from his work, now I have concluded that if there are somebody here that can speak about continuations with authority is him. Not me and definitely not you.

2. The concept of continuations is often misunderstood, but I don't think anyone in this thread, besides you, thinks of continuations as a sequence of action calls

I have already said (please read above) that after reading Geert's presentation I now understand that continuations is something broader that applies even in areas outside web development. My point here is that Sticky Actions seems to solve the majority of problems that continuations solve for web projects with a less powerful but more simple approach, although of course simplicity is most of the times is a subjective opinion.

I think that what Khalil tried to say is that your aproach is more like (a less powerful version of) Spring's scoped beans than RIFE's continuations.

It would be great if you could show an example where Spring's custom scope bean would work and Sticky Actions would not work! After all the hype about RoR, dynamic languages, blah blah blah is already clear to me that development it is not about power. It is about simplicity.

Oh, reading my post again, it sounded more aggressive than I intended, sorry.

My point here is that Sticky Actions seems to solve the majority of problems that continuations solve for web projects with a less powerful but more simple approach, although of course simplicity is most of the times is a subjective opinion.

Mentawaii's Sticky Actions, RIFE's Continuations, HttpSession, Spring's scoped beans, SFSBs, Struts' ActionForms, Rails' flash table, static HashMaps+Cookies... they all solve the same problem. But some of them solve many others. And yes, simplicity is very subjective :)

It would be great if you could show an example where Spring's custom scope bean would work and Sticky Actions would not work!

Where you need other scopes: singleton, call, session, request, thread, 'conversation' (a là Seam), 5 minutes, day, month, persistent, cached, whatever. I think that Sticky Actions is a clever trick, but Spring's Scoped Beans and RIFE's continuations are design options.

After all the hype about RoR, dynamic languages, blah blah blah is already clear to me that development it is not about power. It is about simplicity.

Simplicity where it fits, power where it needs. When will the Rails guys start building applications that need distribution, 2PC and legacy databases? :)

Nice reply Ronald! :)

Where you need other scopes: singleton, call, session, request, thread, 'conversation' (a là Seam), 5 minutes, day, month, persistent, cached, whatever.

Mentawai has scopes for IoC components. For simple continuations where you need to persist some information across multiple requests, you can explicit define where the scope starts and where the scope ends by calling adhere and disjoin. For a 5 minutes scope you could implement a timer to call disjoin for you. Maybe the next step for Sticky Actions is to accept a timer/scope that would automatically take care of calling disjoin at some time. Not sure if that makes sense but is something to think about it!

Mentawai has scopes for IoC components. For simple continuations where you need to persist some information across multiple requests, you can explicit define where the scope starts and where the scope ends by calling adhere and disjoin.

Ah, you're using the word 'continuation' again! These are not continuations! The concept of Sticky Actions is more like Seam's conversations ('this method starts a stateful sequence of requests, and this one ends it') than continuations (where there is a block of real code with the algorithm of the flow to be executed). Have you taken a look at it?

Ah, you're using the word 'continuation' again! These are not continuations!

Hehe, I wanted to make the same remark.

"custom scope" can help to have a simple implementation of "continuations".

I don't think you should use the word continuations here either, even in between quotes. :-)

By the way, the Mentawai site does not mention continuations anymore: http://www.mentaframework.org/sticky.jsp

By the way, the Mentawai site does not mention continuations anymore:

http://www.mentaframework.org/sticky.jsp

Thanks a lot Sergio, I really appreciate that you updated your documentation!

By the way, the Mentawai site does not mention continuations anymore:

http://www.mentaframework.org/sticky.jsp

Sergio, This is a very honest thing to do and I applaud you for it. I have had a look at Mentawai before and it seems to do the simple things well, and I think StickyActions is a good approach to conversation state. On the subject of continuations, imagine describing a number guessing game like this: public void runGame() { int answer = getRandomNumber(); nextPage = "guessNumber.jsp"; int guess = displayAndWait(nextPage); // This is where the magic happens while (guess != answer) { int guess = displayAndWait(nextPage); } } Ok, much detail missed out, but each call to "displayAndWait()" sends the page back to the user and waits for a response. The midflow state of the method is the continuation. I hope you can see how this helps complex ui development. The coder never has to leave the method to handle multiple request/responses. The user interface really does become a conversation between the user and the code. Kit

Ah, you're using the word 'continuation' again! These are not continuations!

I appoligize for this sin, but i said: "simple continuations". Now I will use "simple conversations", but then Seam people will throw stones at me. So please when I said: "simple continuations" or "continuations" read "state manatement across requests". But what did you think about Stick Actions with timer/scope?

But what did you think about Stick Actions with timer/scope?

Well, I could suggest you to add support for pluggable scopes, or just say 'use Spring' instead :D

Well, I could suggest you to add support for pluggable scopes, or just say 'use Spring' instead :D

Mentawai supports Spring, so maybe this can be done by integrating with Spring. (http://www.mentaframework.org/spring.jsp) I think that most of the times you don't need scopes. You are defining when something start and when something ends in your code. You know when a registration starts and when a registration ends. You know when a Number Guess game starts and when it ends. And the session timeout should be enough to get rid of the abandoned/forgotten ahered actions. The Sticky Action implementation already takes care of that by calling onRemoved, but nothing holds you from putting another timer somewhere to separate session timeout from sticky action timeout.

Well, I could suggest you to add support for pluggable scopes, or just say 'use Spring' instead :D

Hi, Mentawai has some features like Hibernate integration and Transaction managment that some people tolds us to not do because Spring has already done that... The problem is that Spring is not as simple and as intuitive as we want. We wanna a framework that you need to read the documentation by only few minutes to understand how to do something. Take a look in the Hibernate Integration, IoC API, Transaction Managment and you will understand what I am saying. But I admit that it does not cover all the cases that Spring do, but I'm sure that it handles 80% of the cases. For example, the transaction managment. Mentawai has a simple and easy to learn way to manage transactions. It is enough for most cases. If you really need a more precise transaction managment, it's very easy to switch betwen Mentawai Spring transaction. We believe that Stick Actions cover most of cases. But if you really think that a important and common case is not covered by Mentawai, we invite you to use our forum: http://forum.mentaframework.org

HOWEVER, let me share my impression that continuations is being overvalued for web applications. I may be wrong so feel free to throw in some arguments against this statement.

Sergio, if you really want to know more, you might want to read this also: http://www-128.ibm.com/developerworks/java/library/j-cb03216/ and this: http://rifers.org/wiki/display/RIFE/Web+continuations http://rifers.org/wiki/display/RIFE/Step-back+continuations http://rifers.org/wiki/display/RIFE/Parallel+and+simultaneous+continuations http://www.seaside.st/Documentation/CallandAnswer/ and maybe this: http://beta4.com/seaside2/tutorial.html