Conversational Web Applications with Spring Micha Kiener Mimacom - - PowerPoint PPT Presentation
Conversational Web Applications with Spring Micha Kiener Mimacom AG Jrgen Hller VMware AGENDA > Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations
Micha Kiener Mimacom AG Jürgen Höller VMware
2
> Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions
3
> Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions
> 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)
> micha.kiener@mimacom.com
4
5
> Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions
> 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
> Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions
Disruptive user experience without window management The demo uses:
> ICEfaces (Ajax JSF Library) > Spring 3.1
8
> 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
> 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
Solving our disruptive user experience by using “window” scope instead of “session” The demo uses:
> ICEfaces (Ajax JSF Library) > Spring 3.1
11
12
> Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions
> 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
> 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
Extended demo
> URL cloning > Bookmarking including the win-id > Nesting, Isolation of conversations
The demo uses:
> ICEfaces (Ajax JSF Library) > Spring 3.1
15
> 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
> 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
> Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions
> 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
> 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;
workflow, process engines
> After all, conversation and window management can still be combined for a Web environment
20
> 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
> 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
Simple demo using conversation scoped beans and exposing the conversation management API to buttons The demo uses:
> ICEfaces (Ajax JSF Library) > Spring 3.1
23
> 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
> 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
> Extensible and embeddable through loosely coupled components: – Conversation manager – Conversation store – Conversation resolver – Conversation scope
26
27
> Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions
> 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
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 micha.kiener@mimacom.com jhoeller@vmware.com
29
Micha Kiener www.mimacom.com Mimacom AG micha.kiener@mimacom.com Jürgen Höller www.vmware.com VMware jhoeller@vmware.com
> 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
> 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
> 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
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