凪瀬 Blog
Programming SHOT BAR

目次

Blog 利用状況
  • 投稿数 - 260
  • 記事 - 0
  • コメント - 36366
  • トラックバック - 192
ニュース
広告
  • Java開発者募集中
  • 経歴不問
  • 腕に自信のある方
  • 富山市内
  • (株)凪瀬アーキテクツ
アクセサリ
  • あわせて読みたい
凪瀬悠輝(なぎせ ゆうき)
  • Java技術者
  • お茶好き。カクテル好き。
  • 所属は(株)凪瀬アーキテクツ
  • Twitter:@nagise

書庫

日記カテゴリ

 

私はWebアプリケーションの開発を仕事でよくやっているわりにはWebアプリケーションが嫌いななのですが、 せっかくセッションについて書くことがあったのでWebアプリケーションネタを綴っておきましょう。

C言語およびその派生言語(C++, C#, Java)では文法上、ローカル変数はブロック(つまるところ{から}までの間)内でのみ有効です。 これを変数のスコープと呼ぶわけですが、Webアプリケーションでもこのようなことができないか?と考えたのが発端でした。

つまり、セッションに格納したデータが画面フローのある位置からある位置までと定められたブロックを抜ける際に セッションから自動的に削除されるような仕掛けが作れないか?ということです。

Webの画面フローは構造化定理に則していない

ここで大きな問題となるのは、Webにおける画面フローは構造化定理に則しているわけではないということです。
構造化定理(ベーム, ヤコピーニ 1966年)とは、 「全てのアルゴリズムは、 順次、選択、繰り返しの3つの基本制御構造を組み合わせて作ることができる」 というもので、goto文有害論の論拠のひとつとして挙げられることも多いですね。

Webにおける画面遷移はハイパーテキストでのリンクですから、整然としたフローにはならず、 あちこちにダイレクトに飛び回る無秩序なものとなってしまいます。

また、プログラムの実行に際して「今どこを実行中なのか」をあらわすプログラムカウンタ (マシン語の用語。現在実行されているアドレスを格納するレジスタ)が単一とは限らず、 複数の並走するマルチスレッドであること、また順次処理なのか、スレッド分岐なのかはブラウザで管理され サーバ側でとらえることが困難であることがWebの画面フローを完全に管理するフレームワークを作ることを困難にしています。

昔、このアイデアに取り憑かれ、いろいろ思索した際はフローの制御は不可能ではないかという結論でした。 興味がある方はぜひ、この難問に挑戦してみてください。

投稿日時 : 2007年10月5日 9:56
コメント
  • # re: Webの画面フローにスコープの概念を持ち込めないか?
    IIJIMAS
    Posted @ 2007/10/05 10:43
    継続(continuation)
    http://ja.wikipedia.org/wiki/%E7%B6%99%E7%B6%9A
    に関連するお話でしょうか…
  • # re: Webの画面フローにスコープの概念を持ち込めないか?
    かつのり
    Posted @ 2007/10/05 10:49
    JettyでContinuationが取り入れられていますね。
    これって実装しようと思うと、本当に難しいんですよ。

    前に非WEBでContinuationをスレッド切り替えで実装しましたが、
    これも結構コストが多いし難しいので、
    Commandパターンとかが流行っているんでしょうね。
    WEBでもStruts2やSpringWebFlowではCommandパターンですが、
    フローコントロールまででフローの停止はできません。

    JettyのContinuationはCometのためなので、
    非同期、ノンブロッキングIO辺りを駆使しています。
    WEBだと単に停止しつつもレスポンスを返さなきゃダメなんですね。
    そこが一番ネックかと。
  • # re: Webの画面フローにスコープの概念を持ち込めないか?
    凪瀬
    Posted @ 2007/10/05 11:13
    Webの画面遷移で継続を表現できるか、という話題でもアリですね。
    「Webで」ってところがミソです。HTTPによるリクエスト/レスポンスというやり取りを
    高級言語の1命令に対応付けたイメージで、ここにブロックの概念を当ててある範囲から
    プログラムカウンタが外れたらローカル変数を除去したい。

    しかし、ブラウザの「別のウィンドウで開く」のように、いつ何時
    新たなスレッド(つまるところウィンドウ)が開始されるかをサーバ側で検知することが困難。

    非Webでやるのであれば、まだマシなのでしょうが、「Webで」という条件がさらなる困難を招いています。
  • # re: Webの画面フローにスコープの概念を持ち込めないか?
    むら
    Posted @ 2007/10/05 13:30
    .NETではフローを強制する仕組みをサポートするUIPABと言うライブラリがあります。
    もちろん、Webにおけるフローも強制されます。
    UIPABでは画面間で受け渡す情報の保持に、セションの代わりにステートと呼ばれるものを使います。
    仰っているもののイメージに近いかと思うのですが...
  • # re: Webの画面フローにスコープの概念を持ち込めないか?
    凪瀬
    Posted @ 2007/10/05 15:34
    フローを制御する方法論があるのは知っていますよ。
    そこに「変数スコープ」のように「セッションのスコープ」を定義するというのが本題なのです。

    フローの強制はブラウザ側でのマルチウィンドウに対応していないものが通常だと思うのですが、
    それにも対応しようとして可能なのかどうか。
    ポップアップの別ウィンドウで何かするということが出来ないようでは困るわけで。
  • # re: Webの画面フローにスコープの概念を持ち込めないか?
    むら
    Posted @ 2007/10/05 16:09
    失礼しました。
    フローと状態保存を紐付けて管理する仕組みと言う事でUIPABを挙げましたが、UIPABでは「スコープ」の様に
    状態保存の範囲を限定するものではなく、逆に長期間の保存を可能にする仕組みとして提供していますので、
    確かに仰っているものとは違いますね。

    また、UIPABのフロー制御はマルチウィンドウに対応してはいません。

    う~ん、確かに難問ですね...
    マルチウィンドウに対応しつつ、スコープを実現するにはセション-ウィンドウ別に一意な何らかのキーが
    必要になるのでしょうが...しかもサーバー側からそれらの死活を監視したい...
  • # セッションに変数スコープを持たせる - 没案
    凪瀬 Blog
    Posted @ 2007/10/09 20:02
    セッションに変数スコープを持たせる - 没案
タイトル  
名前  
Url
コメント