Java Community News - Manage State with Continuation Servers

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Java Community News
Manage State with Continuation Servers

5 replies on 1 page. Most recent reply: Mar 23, 2006 12:09 PM by Sidharth Kuruvila

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 5 replies on 1 page

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Manage State with Continuation Servers

Posted: Mar 22, 2006 8:08 AM

Summary
While the stateless model of client-server interaction allows a servlet to service requests from any client, it also puts the burden of state management on the developer. Continuations, a feature of Ruby and other languages, can help ease state management chores. In a recent article Bruce Tate shows how to use this technique in Java.

In a recent article, Bruce Tate follows the evolution of client-server programming from applications where a server or servlet is dedicated to each client to the stateless Web application model that allows a servlet to service requests from any client. The latter approach allows Web applications to scale, but at the cost of shifting the onus of state management from a programming language to the developer.

Continuations, a feature of Ruby, Smalltalk, and other languages, offer a state management technique seldom used in Java. In his article, Tate introduces continuations, and shows how to use this approach in Java applications:

The basic idea is this: You can let your programming framework load your application's state before a request and save your application's state after each request. [...] Each time you implement the call, the continuation picks up where execution left off. So a Web development framework that uses continuations can capture a continuation after processing each request and store it in the session with an identifier. The framework can then restore the continuation from the session before each new request, using the same approach that you used to store user data.

Tate predicts that "in two years, most new Web development will use some continuation server or some simulation of continuations," and highlights the benefits of the continuation server approach:

The continuation-server approach in many ways lets you have your cake and eat it too -- a stateful programming model and a user experience with stateless performance. Drilling down, these are the approach's advantages:

It assures statelessness between requests. The framework can identify individual continuations within a URL and store that continuation in the session.

It gives you a stateful programming model. The framework can restore any continuation at any time. If the user submits a form a second time, the continuation can pick up processing at an earlier point in time.

You can invalidate continuations based on business rules, so it's easy to prevent a form from being submitted twice.

You get Back button support thrown in for free. Because you literally have the execution state at any point in time, the framework can simply restore the appropriate continuation if the user ever hits the Back button.

Threading becomes easy because no resources are shared. No resource contention means most threading problems go away.

What do you think of this approach to state management?

jamie mccrindle

Posts: 3
Nickname: dkfn
Registered: Apr, 2003

Re: Manage State with Continuation Servers

Posted: Mar 22, 2006 9:01 AM

> What do you think of this approach to state management?

*Shameless but relevent plug*

I think it's great but then I'm biased because this is exactly the approach that BpmScript (http://www.bpmscript.org) uses to do Business Process Management. It provides an alternative to the visual programming usually used by Workflow/BPM engines.

BPM is a classic scenario where Continuations are useful i.e.

* BPM Processes are typically long running
* BPM Processes need to be checkpointed / persisted
* BPM Processes may need to migrate in the event of hardware failure or for performance
* BPM Processes need to scale without holding onto resources such as threads
* BPM Processes may need to be passivated
* BPM Processes are stateful

There were discussions around the JVM supporting Continuations natively which would be ideal (as long as they were also Serialiseable).

Ivan Lazarte

Posts: 91
Nickname: ilazarte
Registered: Mar, 2006

Re: Manage State with Continuation Servers

Posted: Mar 22, 2006 3:30 PM

Continuation Servers, the return of the server side cookie?
I'd definitely agree it is a generally a hassle to deal with user state, unless your main goal isn't to interact with the user, but serve content instead.

I like the idea of being able to retrieve user state at any point in the chain though.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Manage State with Continuation Servers

Posted: Mar 22, 2006 8:38 PM

> Tate predicts that "in two years, most new Web development
> will use some continuation server or some simulation of
> continuations," and highlights the benefits of the
> continuation server approach:
>
> The continuation-server approach in many ways lets you
> have your cake and eat it too -- a stateful programming
> model and a user experience with stateless performance.
> Drilling down, these are the approach's advantages:
>
> It assures statelessness between requests. The
> framework can identify individual continuations within a
> URL and store that continuation in the session.</li>
>
I was confused as to what Bruce means by "statelessness between requests." Perhaps he means that I the developer don't need to worry about state, but surely the server is storing state. And that makes me wonder why the claim is that you get stateless performance. Why wouldn't I need to replicate this continuation state in case a server crashes? An how big is this state that's being stored for me behind the curtain? How does it get purged, etc.?

I did find a discussion along these lines here:

http://common-lisp.net/project/ucw/rest.html

But I'm curious if anyone can shed some more light on these questions.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Manage State with Continuation Servers

Posted: Mar 23, 2006 2:44 AM

Personally I think it is a bad idea, that will only confuse programmers.

> It gives you a stateful programming model. The
> framework can restore any continuation at any time. If the
> user submits a form a second time, the continuation can
> pick up processing at an earlier point in time.

If a user submits a form for a 2nd time, then he should be notified that the requested action has already been performed.

> You can invalidate continuations based on business
> rules, so it's easy to prevent a form from being submitted
> twice.

Aha...new framework for business rules is needed. More programming, to get around the problems of continuations. I see a lot of code written in the form of "...if this job has already been done, do nothing" inside and outside the code captured by continuations. New DSL for business rules, with the same old problems (who decides to apply the rule, who writes it, who executes it, who is maintaining it; both for persons and processes)

> You get Back button support thrown in for free.
> Because you literally have the execution state at any
> point in time, the framework can simply restore the
> appropriate continuation if the user ever hits the Back
> button.

Actually the problem lies with the back button: it should not exist in the browser, but in the HTML document. In other words, if a web page is browsable in the form of wizards "go back, go forward, etc", then it should provide a back/forward button, otherwise the web page itself must provide the way to navigate the application.

The real problem with the back button is that the web was originally for static html pages and not for interactive distributed applications.

>
> Threading becomes easy because no resources are
> shared. No resource contention means most threading
> problems go away.

Resource sharing could have been avoided in the current frameworks if each session had its own state of the web application. In fact, a web application environment is nothing more than a time-sharing multiuser operating system. Just like in a multiuser operating system processes do not share resources, unless they need to, so should instances of web applications.

Sidharth Kuruvila

Posts: 3
Nickname: sidkm
Registered: Sep, 2005

Re: Manage State with Continuation Servers

Posted: Mar 23, 2006 12:09 PM

One way to avoid worrying about storing the continuations on the server would be to serialize the program state and send it back to the client.

Links(http://homepages.inf.ed.ac.uk/wadler/links/) does this.

Flat View: This topic has 5 replies on 1 page

Previous Topic

Next Topic


	Web Artima.com