flow수행은 특정한 때 대화(conversation)의 상태(state)를 표시한다. 런타임시 병렬적으로 활성화된 대화(conversation)의 수가 될수도 있다. 같은 시점에 진행중인 같은 사용자에 의해 초기화되는 다중 대화(conversation)가 될수도 있다(예를 들어, 사용자가 다중 창이나 브라우저내 탭을 작동할때를 위한)
많은 대화(conversation)는 다중 요청을 서버로 뻗치고 하위 요청에서 다시 시작될수 있기 때문에 저장되어야만 한다. 사용자가 기대하는 것과 일치하는 상태(state)에서 복구된 대화(conversation)에 포함되는 요청을 위한 안정된 기법이 존재해야만 하는 것처럼, 이 프로세스는 기술적인 과제(challenge)를 나타낸다. 이 문제는 많은 애플리케이션이 브라우저의 탐색기능을 가지는 버튼의 사용을 요구하고 그것들의 사용은 서버에 알리는 것 없이 로컬 히스토리를 업데이트하는것을 생각할 때 좀더 어렵다.
대화 영속성(conversation persistence)의 문제는 Spring Web Flow의 흐름 수행 저장소 하위시스템(flow execution repository subsystem)에 의해 할당된다. 이 장에서 당신은 안정적인 관리자에서 활성화된 웹 대화(conversation)의 저장을 관리하기 위한 시스템을 사용하는 방법을 배울것이다.
다음 부분은 흐름 수행(flow execution)이 ViewState에 들어갈때 발생하는 것을 가리킨다고 다시 생각해보자.
흐름 수행(flow execution)이 ViewState에 도달할때, 이것은 제공되기 위한 사용자 입력을 위한 state에서 기다리는 잠시중지(paused)를 말한다. 반환되는 ViewSelection를 잠시중지한후 요구되는 입력을 모으기 위한 도구를 제공하는 사용자를 위해 응답을 이슈화하기 위해 사용된다.
사용자 입력은 잠시중지된 ViewState에서 흐름수행(flow execution)을 다시 시작하는 이벤트를 알리다(signaling an event)에 의해 제공된다. 입력 이벤트는 가져온 사용자 action와 통신한다.
활성화된 흐름수행(flow execution)이 paused될때마다 이것은 저장소 밖으로 저장된다. 다음 요청이 흐름수행(flow execution)을 위해 들어올때, 저장소로부터 복구되고, 다시 시작하며, 지속된다. 이 프로세스는 흐름수행(flow execution)이 저장소로부터 제거되는 종료 상태(state)에 도달할때까지 지속된다.
이 프로세스는 다음의 두개의 그림에서 형상화된다.
요청 1 (1) - 흐름수행(flow execution) 영속성을 잠시멈춤
요청 2 (2) - 흐름수행(flow execution) 복구를 잠시멈춤, 종료된 대화(conversation) 무효상태
흐름수행(flow execution)이 생성될때, 이것은 브라우저와 서버간의 새로운 대화(conversation)의 시작을 표시한다. 개요를 말한것처럼, 새로운 흐름수행(flow execution)은 시작 프로세스가 하나 이상의 요청을 확장하고 저장될 필요가 있는 대화(conversation)의 시작을 표시한후에 여전히 활성화된다. 이 경우, 흐름수행(flow execution)은 두가지 부분으로 구성된 복합키(composite key)를 구성하는 저장소에 의해 영속성 식별(persistent identity)에 할당된다. 이 키(key)는 하위 요청에서 흐름수행(flow execution)을 복구하기 위해 클라이언트에 의해 사용된다.
흐름수행(flow execution)의 영속성 식별의 첫번째 부분은 유일한 대화(conversation) 식별자이다. 이것은 브라우저와 방금 시작된 서버간의 논리적인 대화(conversation)에 인덱스를 제공한다.
흐름수행(flow execution)의 영속성 식별의 두번째 부분은 지속성 식별자이다. 이 식별자는 특정한 때 대화(conversation)의 상태(state)로 인덱스를 제공한다.
대화 id와 지속성 id와 함께 특정한 때 대화의 상태를 식별하는 유일한 두개의 부분을 가진 흐름수행 키를 만든다. 다음 요청에서 이 키를 서브밋하여, 브라우저는 그 지점에서 대화를 복구하고 지속할수 있다.
So on a subsequent request the conversation is resumed by restoring a flow execution from the repository using the two-part key. After event processing, if the flow execution is still active it is saved back out to the repository. At this time a new flow execution key is generated. That key retains the same conversation identifier, as the same logical conversation is in progress; however the continuation identifier changes to provide an index into the state of the flow execution at this new point in time.
By submitting this new key in a subsequent request a browser can restore the conversation at that point and continue from there. This process continues until a flow execution reaches an end state during event processing signaling the end of the conversation.
When a flow execution reaches an end state it terminates. If the flow execution was associated with a logical conversation that spanned more than on request, it is removed from the repository. More specifically, the entire conversation is invalidated, resulting in any flow executions associated with the conversation being purged. This process is dubbed conversation invalidation after completion.
Once a conversation has been invalidated the conversation identifier is no longer valid and cannot ever be used again.
The next section looks at the repository implementations that are available for use with Spring Web Flow out-of-the-box.
The simplest possible repository and the default implementation. This repository is stateful, managed in the user session, and stores exactly one flow execution instance per conversation, invalidating it when its end state is reached. This repository implementation has been designed with minimal storage overhead in mind.
It is important to understand that use of this repository consistently prevents duplicate submission when using the back button. If you attempt to go back and resubmit, the continuation id stored in your browser history will not match the current continuation id needed to access the flow execution and access will be disallowed.
This repository implementation should generally be used when you do not have to support browser navigational button use; for example, when you lock down the browser and require that all navigation events to be routed through Spring Web Flow.
This repository is stateful, managed in the user session, and stores one to many flow execution instances per conversation, where each flow execution represents a restorable state of the conversation at a point in time. This repository implementation is considerably more flexible than simple but incurs more storage overhead.
It is important to understand that use of this repository allows resubmission when using the back button. If you attempt to go back and resubmit while the conversation is active, the continuation id stored in your browser history will match the continuation id of a previous flow execution in the repository. Access to that flow execution representing the state of the conversation at that point in time will be granted.
Like simple, this repository implementation provides support for conversation invalidation after completion where once a logical conversation completes (by one of its FlowExecutions reaching an end state), the entire conversation is invalidated. This prevents the possibility of resubmission after completion.
This repository is more elaborate than the simple repository, offering more power (by enabling multiple continuations to exist per conversation), but incurring more storage overhead. This repository implementation should be considered when you do have to support browser navigational button use; for example, you cannot lock down the browser and have all navigation events to be routed explicitly through Spring Web Flow.
This repository is entirely stateless, and its use entails no server-side state.
This is achieved by encoding a serialized flow execution directly into the flow execution continuation key that is sent in the response.
When asked to load a flow execution by its key on a subsequent request, this repository decodes and deserializes the flow execution, restoring it to the state it was in when it was serialized.
Note this repository implementation does not currently support conversation invalidation after completion, as this capability requires tracking active conversations using some form of centralized storage, like a database table. This implementation will be likely enhanced in a future release to provide this capability.
Also note that storing state (a flow execution continuation) on the client entails a certain security risk that should be evaluated.