conversational web applications with spring - jazoon.com file– a servlet filter will check the...

34
Conversational Web Applications with Spring Micha Kiener Mimacom AG Jürgen Höller VMware

Upload: truongtruc

Post on 15-Feb-2019

214 views

Category:

Documents


0 download

TRANSCRIPT

Conversational Web Applications with Spring

Micha KienerMimacom AG

Jürgen HöllerVMware

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)

> [email protected]

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

[email protected]

[email protected]

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