Comment

Above in this comment thread: The Elevator Pitch for Web Based Continuations » Wrong Idea » dead wrong » Continuations:Web :: Sequential/Modal:GUIs

More on continuations

Posted by Anonymous User at 2003-11-24 12:52 AM

> First, a "continuation ID" means there has to be a continuation > stored on the server (or else you'd be saying "continuation state", > not "continuation ID"). This is still stateful, even if the application > in question doesn't always need it.

Of course the continuations approach is for stateful applications. Which serious business orientated applications do you want to write without state?

> Second, the existence of a "sitemap" indicates a centralized architecture. > A decentralized web object framework wouldn't have such a thing as a "site map". > Take a look at this site... objects nest within objects, as is visible by their > URLs. And as data is added, the trees grow and change. That's not > possible with a single static "site map".

As you refer to the Cocoon sitemap: It's not one single static sitemap. You can nest as many sitemaps as you need. Then the sitemap is "only" a mapping between URI space and applications (in Cocoon we use pipelines) which serve this URI. We do it explicitly and not implicitly (like the file/script to URL mapping of e.g. httpd.)

> URLs should represent persistent things, or methods upon persistent things. > That's what the web is.

As long as you can rely on stateless applications fine - but what happens if your requirements grow? How can you implement the fact "a user is logged in" without a state on the server in a safe way?

> Trying to use continuations for a web application > just means you don't really understand what the web is for,

What is the web for? (just curious)

> like a programmer > who writes a highly-modal GUI, fighting the event-driven model every step of > the way. Like GUIs, Web apps naturally fit to an event-driven asynchronous > messaging model. Even better, they usually fit a transaction-per-event model, > which makes them even easier to write than GUIs.

For simple requirments you can use simple technologies but once again, how do you handle states or if you say we don't need state at all how to you implement things like "a user is logged in" in a safe way?

> To me, the only legitimate

Sorry, I don't like your wording here: "legitimate" sounds like the one and only allowed solution and all others are wrong/idiots/...

... our world doesn't work this way ...

> use of cross-event continuations in a web application > is to model the state machines of published persistent objects. For example, > a web workflow object might use continuations to track the stage of the workflow > instance. But, that is something that occurs behind the REST representation of > the workflow instance, because the continuation is shared for everyone referencing > that instance. In other words, such a continuation is not part of the UI view, > it's part of the application domain model.

Cheers, Reinhard

PS You're of course welcome to join dev@cocoon.apache.org!!

UI state <> Business Object state

Posted by Anonymous User at 2003-11-24 09:28 AM

"""Of course the continuations approach is for stateful applications. Which serious business orientated applications do you want to write without state?"""

You're not distinguishing between stateful UI and stateful objects. Business applications have to have stateful objects. They do not have to have server-side UI state.

"""As long as you can rely on stateless applications fine - but what happens if your requirements grow? How can you implement the fact "a user is logged in" without a state on the server in a safe way?"""

Ummm, how about...

A cookie containing a server-signed ticket
Basic auth over HTTPS
Client-side HTTPS certificates

Just to name a few. How many ways do you need?

By its nature, HTTP doesn't put state on the server side. This is good, because it allows scalability through caching and clustering - and the caching and clustering can be much simpler than they would be if there was UI state to store along with business object state.

Web applications are easiest to build when you design the UI such that all state is divided into either persistent business objects, or client-side state, and client-side state consists solely of URLs and perhaps a cookie or two to identify a relevant business object.

If you don't follow this division, you end up duplicating persistence mechanisms, and important business data may not be properly backed up because it's living in the web tier.

So, to sum up, I believe that putting state in the web tier is a bad idea because:

Users are better off with client-side state, where they can control, bookmark, forward, re-purpose as web services, etc.
The web tier is more scalable when state is stored either in the client or the DB tier
The business is better off with its business objects identified as part of the business model, and put in the enterprise's data tier.
It's duplication of effort to create two persistence mechanisms, one for business objects and one for UI state, especially when it's always possible to model a piece of state as either client-side state or as a business object.