Content Management Service
Bruce Gruenbaum:
The Context Management Service is designed to keep track of data that is needed to reestablish a logical session's context on subsequent interactions with a target. People will argue whether context should be stored on the client or the server or both. In my experience, a framework has to provide support for all three options - client, server and both. If one views a set of interactions with a set of targets as a set conversations, context management is about determining where you last left off in the conversation with a specific target.
Thomas Mercer-Hursh:
Or, in the case of AppServer agents, being able to continue the conversation even though you weren't the one who had the last exchange.
Bruce Gruenbaum:
Session management is about reducing the amount of time it takes to determine which target you are talking to.
Thomas Mercer-Hursh:
Agree that one needs all three. One of the interesting twists is supporting a uniform context management solution across multiple client types.
Initial content adapted from an Exchange on the PEG
- Printer-friendly version
- Login to post comments
Comments
Isn't it mostly an HTML UI required component ?
Isn't context management or state management mostly/mainly related to the UI ? or required for stateless UI's, specifically, HTML ?
When it comes to Business Logic components or services they're designed to be "coarse" grained and are mostly carried out in a single call and single transaction. Would you design Business Logic components or services that are carried out in multiple steps and multiple transactions ? In most cases all the required parameters including authentication are sent along with every request.
With stateaware UI's (decoupled or not from the BL/DA), like, GUI, ChUI, of course RIA like Flex, maybe Silverlight ? which are by definition a client with a persistent state ... state management isn't really needed, in any place, right ?
Now if you're building a web HTML UI even with AJAX because you probably won't do everything with AJAX state management has to be a part of it.
alon wrote: "With stateaware
alon wrote:
"With stateaware UI's (decoupled or not from the BL/DA), like, GUI, ChUI, of course RIA like Flex, maybe Silverlight ? which are by definition a client with a persistent state ... state management isn't really needed, in any place, right ?"
Depends on what you call "stateaware UI".
We have a C# front end (wpf)and a Progress backend. The mdi interface consists of folders, master detail screens, normal screens etc..
The interface itself is because of its nature perfectly capable of maintaining its own state, but we also got functionality like navigation. Go to next previous, last, first. This works only well if all data is already clientside. If that is not the case, like in a folder or a master detail screen, where the master allways consists of only one record, then the next record is something which needs to be handled server side. Unless offcource you are willing to store rowids client side, but IMO that is a bad idea.
So there comes the need for contextmanagent. Where was I with the last call? We store this information in a contextdatabase, which is maintained by a class called context.cls (what is in a name).
We also defined something like clientcontext, that is in our case a meachnism to interchange information between client and server (and vice versa offcourse).
We decied to use a temp-table instead of parameters because of the more uniform way you can handle the information streams between client and server.
Maybe a bit of a fuzzy story (after rereading this :-))
Casper.
Interesting. Putting aside
Interesting. Putting aside the simple case of queries that can be index-repositioned.
And focusing on "heavier" or complex queries that take a while to run and require manipuations, generating temp-tables etc. And queries that cannot be index-repositioned.
For a web UI the state manager we've designed stores the queries in a fixed row size flat file that later makes it very easy to scroll back and forth or jump to a specific page.
All you is needed is the page first/last row number or use the page number * rows per page and row size to reposition your place on the file. And of course no sensitive data is stored on the client side.
We usually limit these queries and the files we store to 4000 rows. And the state manager treats these files or queries like any other state resource that can also be timedout (nothing really special here or that hasn't been done before).
With a GUI, ChUI, RIA etc. client and "heavier" or "complex" queries would bumping up the batch size to a couple thousands rows and marshalling the whole, well, truncated query work ?
Not being able to scroll thousand pages isn't that much of a problem. The filter can always be used to refine the search.
The other thing I think maybe a problem with these kind of UI's and server side state management is problems like state resource timeouts which I don't really feel sure about with these type of UI's.