Conversational Web Applications with Spring Micha Kiener Mimacom AG Jürgen Höller VMware
AGENDA > Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions 2
AGENDA > Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions 3
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) > micha.kiener@mimacom.com 4
AGENDA > Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions 5
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
AGENDA > Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions 7
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
AGENDA > Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions 12
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
AGENDA > Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions 18
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 conversation management 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
AGENDA > Introduction > Definition of Scoping > Necessity for Window Management > Window Management Architecture > Conversations Explained > Wrap up > Questions 27
Recommend
More recommend
