[jfriends-ml 11038] EJB デザインパターンの version と Struts token との類似性

[Yasushi Inoue <y.inoue@xxxxxxxxxxxx>]

井上泰です。


第２回EJBデザインパターンの、versionの途中で時間切れになりました。
言いたかったことを整理し、説明を補いました。

「EJBデザインパターンのversionとStruts tokenとの類似性について」


疑問

versionは、Strutsのtokenに似ている。同じパターンとみなせないだろうか？


シナリオの共通点

* サーバーは、ある時点のステートを示すオブジェクトを作成する
* サーバーは、このステートをメモリ(DB)に保存し、クライアントに渡す
* クライアントは、ステートをそのままサーバーに返す
* サーバーは、返却ステートと保存ステートを照合する
　- 一致すれば、処理を許可する。保存ステートを破棄/変更する
　- 不一致ならば、処理を拒否する

# ステートを循環させ元のステートと照合するのは同じ
# クライアントにとってステートは不変Objectなので、mementoパターンに似ている

意味の相違点

* 目的
tokenは、画面遷移の順序を管理する
versionは、データ項目の整合性を管理する。(最初の更新だけを許すので順序性？)

* ステート
tokenの場合、実はクライアントのステートである
versionの場合、モデルのステートである

実装の相違点

* 永続性
tokenはメモリに存在するのでサーバー停止時に消失 (以前、根本さんが指摘さ
れました)
versionはDBに存在するのでサーバーの停止後も存在する

* 同期化
tokenはクライアント単位にスレッドセーフにする (Single Thread Modelの場合
は課題)
versionは更新前にDBのユーザで排他制御する

課題

似たようなパターンを調べてみたい
同じパターン、別のパターンとする、理由を考えたい


皆さんは、どう思われますか？



参考

Synchronizer Token （StrutsのTokenが引用されています）
Core J2EE Patterns 2nd Edition
http://www.amazon.co.jp/exec/obidos/ASIN/0131422464/qid=1078049012/sr=1-1/ref=sr_1_10_1/250-1021153-8339448
「J2EEパターン―明暗を分ける設計の戦略」 第1版
http://www.amazon.co.jp/exec/obidos/ASIN/4894714345/ref=sr_aps_b_3/250-1021153-8339448


Extension for Struts (tokenのクライアント単位の同期化の例です)
http://www-6.ibm.com/jp/software/websphere/developer/download/wasstx.html
com.ibm.jp.swg.stx.action.WsxSessionSyncTemplateAction