Conversational Web Applications with Spring - jazoon.com file– A servlet filter will check the...
-
Upload
truongtruc -
Category
Documents
-
view
216 -
download
0
Transcript of Conversational Web Applications with Spring - jazoon.com file– A servlet filter will check the...
2
AGENDA
> Introduction> Definition of Scoping> Necessity for Window Management> Window Management Architecture> Conversations Explained> Wrap up> Questions
3
AGENDA
> Introduction> Definition of Scoping> Necessity for Window Management> Window Management Architecture> Conversations Explained> Wrap up> Questions
Micha Kiener
> Head of Research and Innovation at Mimacom AG
> Initiator and main committer of the open source edoras framework
> Participating in the development of ICEfaces, an open source Ajax framework based on JSF
> Committer of Liferay, an open source portal solution> Committer of the Spring framework (co-lead for Spring 3.1
conversation and window management)
4
5
AGENDA
> Introduction> Definition of Scoping> Necessity for Window Management> Window Management Architecture> Conversations Explained> Wrap up> Questions
Definition of Scoping
> Scoping a bean means to define in which context it will be stored and made available
> Scoping is essential for effective memory management and sharing bean data
> Commonly known and used scopes:– Application / Singleton– Session– View (JSF 2.0)– Flash (JSF 2.0)– Request– Prototype
> The scope defines where to store bean values
6
7
AGENDA
> Introduction> Definition of Scoping> Necessity for Window Management> Window Management Architecture> Conversations Explained> Wrap up> Questions
Window Management Demo
Disruptive user experience without window management
The demo uses:> ICEfaces (Ajax JSF Library)> Spring 3.1
8
Necessity for Window Management
> Persisting state over multiple requests / views– By scoping beans in session scope– By using request parameters, encoded within the URLs
> Problems:– Using request parameters is quite limiting– Sessions are shared amongst multiple browser tabs– Session scoped bean values might be compromised, if shown and
changed in multiple browser tabs
> Solutions:– More scoping possibilities than just session and request– Window management by isolating browser tabs
9
Window Management Goals
> Goals to achieve
– Segmentation of the http session to isolate windows
– Mapping a request to a window id
– A window id represents one tab / window within the browser
– Creating a custom scope named “window”, binding bean values to the window id
– Reusing the same window id for a tab, even if it has been refreshed
– Avoiding the same window id being mapped to different browser tabs
10
Window Management Demo
Solving our disruptive user experience by using “window” scope instead of “session”
The demo uses:> ICEfaces (Ajax JSF Library)> Spring 3.1
11
12
AGENDA
> Introduction> Definition of Scoping> Necessity for Window Management> Window Management Architecture> Conversations Explained> Wrap up> Questions
Window Management Architecture
> Basic contract:– The window id must be made available through a request parameter
> Default behaviour:– The window id is encoded into the URL as a request parameter
– A servlet filter will check the existence of this parameter and send a redirect, including a newly created window id parameter
– After the redirect, the window id will be present within the URL and hence persists over a refresh
– A decorated servlet response will encode the window id through the encodeURL method
13
Problems and Solutions
> Frameworks not supporting the encodeURL method of the servlet spec:– They must provide their own mechanism to fulfil the basic contract– E.g. generically add the window id as a hidden field
> Cloning an URL with the window id parameter to a new tab:– Would be mapped to the existing window id– No window isolation between the two tabs
> Exposing the window id to “window.name”:– Compromised id detectable by comparing with the current one
through javascript
14
Window Management Demo
Extended demo> URL cloning> Bookmarking including the win-id> Nesting, Isolation of conversations
The demo uses:> ICEfaces (Ajax JSF Library)> Spring 3.1
15
Spring 3.1
> Supports window management as a first-class feature
> Window id as a request parameter (basic contract)
> Window id to be exposed through the RequestContextHolder.getWindowId method?
> Window management activation by adding the servlet filter to web.xml
> Finegrained configuration through filter and/or mvc namespace
> Sticking to the Servlet spec encodeURL mechanism
16
Spring 3.1
> Web frameworks can adapt either through manipulating the window id request parameter– E.g. automatically add a hidden field to a form
> Alternatively, they can hook into the filter to provide the window id– Pre invocation hook to expose the window id as a request
parameter– Post invocation hook to encode the window id within URLs of the
response or as a hidden field
> Segmented session is exposed through a new “window” (or “windowSession”?) scope
17
18
AGENDA
> Introduction> Definition of Scoping> Necessity for Window Management> Window Management Architecture> Conversations Explained> Wrap up> Questions
Conversation Explained
> The boundaries of scopes like session, window or request are all technically managed:– Pro: automatically handled by the framework– Drawback: maybe not enough to satisfy requirements
> Sometimes the boundaries should lie beyond technical limits to enable business requirements:– Boundaries given by a use case– Boundaries spanning the technical ones (multiple views, wizards)
> Conversations have boundaries managed by business logic rather than a technical mechanism
19
Conversation Explained
> Conversations have often been looked at in a Web-centric view only
> Why separate conversation and window management at all?– Two different problems to solve apart from each other– If solved apart from the Web, conversations can be used;
- for state management in state machines like webflow, workflow, process engines
- for stateful batches (Spring Batch)- for stateful conversations in Spring Integration
> After all, conversation and window management can still be combined for a Web environment
20
Demarcation of Conversations
> Different approaches possible– Automatic, fully controlled (arguably less flexible though), e.g. bound
to the boundaries of a web-flow– Semi-automatic, default creation / ending through conventions (like
starting on a GET or if first requested)– Only manual, could be through API, annotations or listeners
> A conversation management should support demarcation on a low level through an API in a first place
> A high level demarcation should be possible through annotations and conventions
21
Features of Conversations
> Multiple, concurrent conversations, identified by a unique id> Storage of conversations must be pluggable> Current conversation resolver (e.g. conversation id bound to the
window id in a web environment)> Switching between conversations> Conversation nesting, isolation and inheritance> Timeout management> Conversation event listeners> Conversation initialization callback with conversation types> Current conversation being exposed as a new “conversation” scope
22
Conversation Demo
Simple demo using conversation scoped beans and exposing the conversationmanagement API to buttons
The demo uses:> ICEfaces (Ajax JSF Library)> Spring 3.1
23
Persisted Conversations
> Conversations are typically transient, stored within the user’s session
> Persisted conversations can spawn multiple user sessions or even be used by more than one user
> Persisting a conversation must include all of its state, also including conversation scoped beans
> Tricky for instrumented beans
> Entity beans must only be referenced in a persistent conversation, not persisted on its own
> Conversations could be an addition to a workflow, bound to the workflow instance
24
Spring 3.1
> Supports conversation management as a first-class feature
> Implemented as a core (i.e. non web specific) component, featuring a fine grained API for integration with
> Conversation and window management combined for the Web environment– Also supporting simple annotations for conversation demarcation– Conversations embedded within windows (tabs)
25
Spring 3.1
> Extensible and embeddable through loosely coupled components:
– Conversation manager
– Conversation store
– Conversation resolver
– Conversation scope
26
27
AGENDA
> Introduction> Definition of Scoping> Necessity for Window Management> Window Management Architecture> Conversations Explained> Wrap up> Questions
Wrap Up
> Window management is solving the window isolation problem
> Thanks to the separation of window and conversation management;
– Either one can be used separately to solve the appropriate problem
– Conversations can be used as the base for state management generically, either transient or even persistent
– Conversations looked at in a more general way than just Web-conversations can be quite complex in its base
> Spring 3.1 M1 planned for Q3 2010
28
Questions
Any Questions?
Suggested, additional features?Now there is still time!
See http://jira.springframework.org/browse/SPR-6417 for the window management top level issue
See http://jira.springframework.org/browse/SPR-6416 for the conversation management top level issue
29
Micha Kiener www.mimacom.comMimacom AG [email protected]
Jürgen Höller www.vmware.comVMware [email protected]
Problems and Solutions
> Providing an URL opened in a new window:– Additional request parameter, creating a new window id
> Programmatically set a new window id:– Can be done using a simple API or specific request parameter
> Using window management in a portal:– URLs are being rewritten by the portal server– Window management filter to set on a global level, not a portlet level– Window id to be the same for every portlet on the same portal page
31
Window Id Generation Strategy
> Simple generation strategy:– Session scoped counter for a window starting with 1– Bookmarking URLs including the window id is problematic
> Sophisticated generation strategy:– Window id being combined with the hash of the current session id
and a session scoped counter– Bookmarked URLs including an old window id are detected as
invalid– Invalid window ids are ignored and re-mapped to a new one
including a redirect with the new window id
32
Conversations and JPA
> Scoping of a JPA EntityManager is somewhat tricky
– Loosing powerful caching features, if scoped too short
– Performance and memory troubles, if scoped too long
> JPA EntityManager scope handled by conversations
– Longer scope than transaction scoped EMs
– Shorter scope than extended EMs, bound to a HttpSession
> Needs careful handling of externally cached, detached entities
– Might need to be merged within conversation initialization
> Conversations typically spawn multiple requests and transactions
33
Wrap Up
Typical Scenario for scopes in a web environment
Segmented session through isolating tabs / windows
Conversations being stored within the session
Persisted conversation bound to a workflow instance
34
HttpSession
Window Scope Window Scope
Conversation Scope
View Scope
View Scope
Workflow Scope