5

Pro Spring MVCという本のSpring Web Flowの章を読んでいます。残念ながら、フロー実行中の状態が保持される明示的な情報はありません。JVMヒープに保存され、セッションに関連付けられていると思います。

現在、HTTP はステートレス プロトコル (REST...) であり、サーバーに状態を保存せずに Spring Web Flow を使用したいと考えています (セッションが認証される可能性がある唯一の状態以外に)。

1 つの戦略は、フローのすべての HTTP 要求 (隠し入力) でフロー全体のすべてのパラメーターを送信し、フローが終了するまで必要なすべてのパラメーターを蓄積することです。

パラメーターの再検証のオーバーヘッドは、既に検証済みのパラメーターに対する署名を使用して回避できます。

このように Spring Web Flow を使用できるかどうか知っていますか? 誰かがすでにこれを行っていますか？

更新：なぜですか？

永続的な状態は、ステートレス プロトコルとしての HTTP の原則に違反するだけでなく、実際的な問題もあります。

  • ユーザーが複数のブラウザー タブでブラウジングすると、状態の不一致、競合状態、またはデータ損失が発生する可能性があります。
  • サーバーに状態を保存すると、複数のサーバー間での負荷分散がより複雑になります。
  • リクエストを分離してテストまたは分析することはできず、以前のリクエストのコンテキストでしかテストまたは分析できないため、テストとデバッグはより複雑になります。
  • サーバー セッションを要求に関連付けるために、Cookie を有効にする必要があります。
  • サーバーは、サーバー側の状態へのアクセスを同期する必要があります。
  • サーバーの状態にも依存するリクエストの URL には、フロー内の状態をブックマークしたり、バグ レポートで状態を理解するために必要なすべての情報が含まれているわけではありません。

私はまだ Web Flow の詳細を調べていませんが、同じプログラミング経験があれば、すべての情報を要求パラメーターに保持できると確信しています。

更新:要求されたフロー処理のスタイルの名前がContinuationsであることを知りました。継続という用語は、関数型プログラミングではより一般的ですが、この考え方を HTTP の相互作用に適応させることは珍しくないようです。

4

1 に答える 1

0

私の Bean Flow FSM プロジェクト (restflow) を確認してみてください: https://github.com/alfonso-presa/restflow

Spring WebFlow は使用していませんが、ステートレス サーバー オーケストレーション フローの実装が可能になるため、質問の趣旨に答えるのに役立つと思います。spring WebFlowであなたとほぼ同じものを作りたかったのでこのプロジェクトを始めましたが、状態がセッションに保存されているため（またREST / jsonのシリアル化が組み込まれていないため）不可能であることがわかりました。

主な目的はステートマシンを作成することです (WebFlow と同じように) が、その状態を Bean に格納することで、分散ストアに保持したり、簡単に署名または暗号化して、次のリクエストの継続としてクライアントに送り返すことができます。

お役に立てば幸いです。

編集: ここにショーケース プロジェクトを作成しました: https://github.com/alfonso-presa/restflow-spring-web-sample

于 2015-08-19T19:12:18.510 に答える