RSS 2.0 New Entries Syndication Feed Atom 0.3 New Entries Syndication Feed

Show blog menu v



Use it



Sibling projects

RIFE powered

Valid XHTML 1.0 Transitional

Valid CSS!

Blogs : Archives

< Upgraded to Groovy JSR1 in RIFE   Embedding images inside the source of a HTML page >
Continuations != continuations

Congrats to Keith for releasing the next preview of Spring Web Flow. The announcement highlights that it supports continuations. Since RIFE was the first web framework to offer native web continuations in plain Java, I downloaded the source of this release to look at the samples. It's always interesting to see how others approach the same problem.

Much to my surprise, the Spring Web Flow continuations support was totally not what I expected. Every framework that claims to support continuations, offers this on the level of the implementation language, like this RIFE example snippet (full source):

    while (guess != answer) 
        // print the guess form and wait for a response 
        // obtain the guess 
        guess = getParameterInt("guess", -1);


The main benefit of this is that you don't have to manually declare or handle any kind of flow anymore. You just rely on the control flow and scope of the implementation language and with special statements (pause() in RIFE), you break out of it and provide control again to the user. At the next request, the local variable stack will be automatically restored and the application will resume right where it left off (more in our presentation about this).

Spring Web Flow however only provides continuations in the flow declaration (can be both in XML and in Java), thus lacking what in my opinion is the single most interesting feature of continuations.

It seems that continuations are becoming a buzz-word, and like with all other buzz-words you should really check what is meant when people claim support for the technology. You might not get what you expected!

posted by Geert Bevin in RIFE on Apr 11, 2005 4:58 PM : 18 comments [permalink]


Re: Continuations != continuations
Re: Continuations != continuations

We never said we provide "native web continuations" in the manner in which you describe them. Spring Web Flow provides continuations support at the flow execution level. In Spring Web Flow, the flow definition is always explicitly defined as you say (which has its advantages, particularly for things like wizards, as you well know) In SWF, the Flow is king :-)

More specifically, the FlowExecutionStack -- which maintains the state of an ongoing web flow for a client, is serialized and restored on every request using a continuation-driven strategy. This results in proper browser navigation button use (back, refresh, new window) for ongoing flows, among other things.

Please note our continuations support has nothing to do with XML! The XML-based definition you're linking to is just one strategy for defining a flow definition. Flow definitions in plain java are supported and are quite elegant.

We'll post more about the fundamental architecture in play here shortly. In the mean time, enjoy playing with SWF. Perhaps we can learn from each other here, we really believe we've brought something innovative to the table (as have you guys.)

Re: Continuations != continuations
Thanks for the clarifications Keith, I updated the post to reflect the fact your SWF is not dependent on XML.
Re: Continuations != continuations
Another point I would like to make is that at its core, SWF is not related to continuations at all. It is at the user's discretion to look at a FlowExecutionStack as if it were a continuation by configuring the appropriate flow execution storage strategy. In the case of SWF, continuations are basically just a way of supporting free navigation in the browser, which can be elegantly supported by continuations (as you undoubtably know).


Re: Continuations != continuations
Hi Erwin, continuations aren't part of RIFE's flow either. We pushed them onwards to language level since that's where they make the most sense to us. I think in SWF they're totally different however than what people think of when they hear the word 'continuations'. As you say it yourself it looks like it's merely a way to associate state data with a state transition and keep those in sync when users use free navigation (which is where sessions create a problem). I think that in this case continuations aren't really the appropriate name. Well one could debate that you have a 'continuation calling style' for the SWF, but it looks to me that what it in reality does, is making the SWF use traditional HTTP request with state stored on the client side. In that case, many systems would have 'continuations'.
Re: Continuations != continuations
What we provide is:
  • a client side, continuation-based flow execution storage strategy. This strategy serializes the FlowExecution out to the client, and yes, deserialization and reconstruction happens on subsequent requests to the server. This restores the state of the flow to what the user expects.
  • a server-side continued-based flow execution strategy, where each request results in copies of the FlowExecution being managed in the HttpSession to support as-needed restoration for back/reload/new window, etc - so the client can go pick up any place they left off.
These strategies are realized by the "ClientContinuationFlowExecutionStorage" and "HttpSessionContinuationFlowExecutionStorage" classes in PR2, respectively.

Please note together this capability is much more than "what many systems have", as the deserialized FlowExecution object maintains the state AND behaivior that is the heart of the web flow system - and is where the power in this system comes from. So by itself, the continuations support may seem basic compared vis-a-vis a language that has built in support for such, but when leveraged with the rest of web flow, what we have is something quite powerful.

If not the use the term "continuation" here, then what? I agree continuations is a buzzword and means different things to different people. But in reality what we see this feature as a continuation, where a continuation is defined as follows:

"A continuation is a saved snapshot of the executable state of a program at any given point in time. It is possible to restore this state and restart the execution of the program from that point onward, such that the stack trace, all the local variables, and the program counter can reclaim their old values." (Taken from

Cheers, Keith

Re: Continuations != continuations
Hi Keith, your quote says it very well: "… snapshot … of a program at any given point in time ..."

SWF doesn't allow for the 'any', it only allows this to happen at certain points in time, namely those that are declared in the flow definition. Keith, just look over the web and look at everything that talks about continuations, it's always about the actual language implementation and to be able to suspend the state anywhere.

I think you have implemented a nice feature and tried to find a name for it, and 'continuations' made a nice match when checking most (but not all) of its definition. In RIFE we have actually something similar, which we simply call the data flow with configurable state storage.

Re: Continuations != continuations
Does this work?

"… snapshot of a <b>flow</b> at any given point within its execution.."

So we have "flow continuations" :-)

Re: Continuations != continuations
Honestly Keith, I think continuations don't apply to your feature, though you would probably like to use the term for the momentum it has. Anybody that is interested in continuations will look at how to do it in an implementation language, not find how, and be disappointed that it's only limited to the flow. Of course, you can call it anything you like, but I don't think it's very responsible to use this term. It looks like you're trying to shoehorn it on top of an existing feature by lack of another appropriate other name.
Re: Continuations != continuations

for what it's worth, I mostly agree with you, as I have blogged here:

Re: Continuations != continuations
I woiuld agree that when most people (who've used them) think of continuations they will assume it works at the language level too. Certainly I do. That said, I think what SWF does is still a 'weaker' form of continuations. The flow definition is a form of code; you've got a complete Turing machine there and then some, and I don't think anybody's disagreeing that multiple snapshots/contexts can be saved and executing simultaneously.

However, let's step back and think about value here. In terms of a typical web app, and certainly the kinds of web-apps most Spring users are interested in writing. I think the SWF continuations (or whatever you want to call the stuff) functionality actually gets you the majority of the benefits that you'd be able to extract from 'real' (java or javascript language level) continuatons. That is because they can help you get around the browser back/forward button issues, and stale link issues, in the same places where 'real' continuations would actually be able to help you.

If you think about a java or javascript based continuation, it's not going to help you at all when some data has been written to the database in the meantime. And if you think about what a typical controller or group of controllers making up a wizard do, it's read and write and read and write data to the database. Very rarely can you get by with keeping everything in your program state. So as soon as another thread's modified the same logical data in the db, you get into a real question of data consistency/validity...

I actually know somebody who implemented a java based web framework with continuations support at the java language level, somewhat similar to what Rife can do, back in 2000/2001. They actually weren't able to use the stuff for a lot of the web code. I'd be curious to know in just how many cases, taking it to the language level (that the controller is written in), but not taking it to the database level, is going to be of much more use in a typical J2EE webapp, than the level which SWF supports?

Regards, Colin

Re: Continuations != continuations
I hate it when things start sounding like religious discussions :)… Considering the timeframe in which SWF has been developed, I think the ideas behind it are very solid. Obviously, there is always room for improvement, but the consideration for things like continuations support goes way beyond what most frameworks attempt so early on. IMHO.. let people develop real apps with it and see if it flies…
Re: Continuations != continuations
Colin, I'm not criticizing the features of SWF, and this particular feature definitely has a lot of value. I just think they'll have to come up with a proper name for it instead of using one that is really used in for a totally different purpose by quite some other systems already.

Colin, can you give me a reference to that web framework you're talking about? I'm interested in knowing more about it. You see, we're starting to get problems already since SWF doesn't support those continuations, so now you have to start saying all the time '… the level at which X supports and the level at which Y supports ...'. We use continuations a lot in multi-step processes that should only be written to the database at the end of all the steps. Sure, we don't use them everywhere, which is why we aren't a continuations framework (like seaside) but instead allow people to use it where they see fit. Btw, the behaviour that Keith implemented is also something we have and you can have many names for it, REpresentational State Transfer is already an existing one that comes a lot closer to it than continuations, I think.

Re: Continuations != continuations
Here is my reasoning (Colin already hints at this):
  • A flow definition is just a specialized 'domain specific lanuage' (your words Geert, taken from a comment on Keiths blog)
  • SWF continuations allow you to halt the execution of a flow at any view state in the flow, and continue from that point on at a later time. So a view state in SWF is similar to a "pause()" call in RIFE.
So I think we are actually correct in using the term "continuation": we have continuations at the level of the SWF flow definition language.


Re: Continuations != continuations
Erwin, you just explained exactly what I already said several times.

There is definately no need to start trying to pull your reasoning apart, I merely wanted to explain to people that as of now one has to be careful what to expect when looking the feature 'continuations'.

Just go ahead and call your feature 'continuations', I'm curious to see how many people wil start asking you how to actually use them, only to realize that it's not what they expected.

I still think it's not very reponsible to use it.

Re: Continuations != continuations
I agree it would be a bad idea to introduce confusion, so I'll add a FAQ entry explaining that the continuations support offered by the SWF system is at the "flow definition language" level, not at the Java level.

Re: Continuations != continuations
>> Colin, can you give me a reference to that web framework you're talking about?


This was a homegrown framework at a company called BorderFree (now owned by Canada Post, but still around as a separate company). To the best of my knowledge, they stoppped using the stuff; it didn't add much value for the kinds of web flows they needed to do, and was pretty complicated to program against, not just a pause() like in Rife...

Re: Continuations != continuations
Two excellent frameworks. They both solve the back button problem nicely. Put me in the camp that says that Spring Weebflow != continuations. It's more of a state machine. It's got some interesting advantages over other continuation-based frameworks, mostly dealing with easy integration with existing web MVC frameworks.

In theory, a continuation captures the future execution of a program...thus the term continuation. Continuation server to me strongly implies the ability to work in a native language, and support for the full richness of Java in terms of making flow decisions. I'd rather see the Web Flow stuff use different terminology.

Just my opinion.


Add a new comment

Comments on this blog entry have been closed.

< Upgraded to Groovy JSR1 in RIFE   Embedding images inside the source of a HTML page >
Google web