アプリケーションサーバにおけるリクエスト処理とページレイアウトの分離(株)東芝 情報・社会システム社
SI技術開発センター SI技術担当
松尾尚典
Copyright © 1999 by Toshiba Corporation

目次• 1 Webアプリケーション開発の問題点• 2 リクエスト処理とページレイアウトの分離• 3 リクエスト処理オブジェクト• 4 ページレイアウトオブジェクト• 5 まとめ

Copyright © 1999 by Toshiba Corporation

1 Webアプリケーション• よく見かけるCGIなアプリケーション– 掲示板、ユーザ登録、情報サービス…

• 画面遷移が少ないものが殆ど– 一つの画面で入力、もう一つの画面で出力• 一般のGUIアプリケーションなら数十、数百の画面を扱っているのに…
• もう少し画面数の多い、役に立つアプリケーションを作りたい
Copyright © 1999 by Toshiba Corporation

サーバアプリケーションの処理
ブラウザ
ID:
PASS:

リクエスト
get /login?id=...
ページ<html><head>...

サーバアプリケーション① リクエストの処理② 対応するページの生成• 多くは①と②を一緒に記述– 教本のサンプルコード等殆ど全て• 単純なアプリケーションではそれで十分• しかし、リクエストやページの種類、関連数が多くなると、途端に開発が難しくなる
Copyright © 1999 by Toshiba Corporation画面遷移例
こんな小さな遷移図でもlogin[NG]ログインダイアログ
login[OK]– ページ数:7– リクエスト数:13– 関連:多数

メニュー
goDialogSelectToEntry

goMenugoMenugoDialogCreate
goDialogSelectToEdit

create[NG]新規作成ダイアログ

設定選択ダイアログ goMenu

goMenu

参加選択ダイアログ
goMenucreate[OK] selectedit

設定変更ダイアログ

entry
goDialogEntry
goDialogEdit

Copyright © 1999 by Toshiba Corporationselect

参加設定ダイアログ

リクエストとページ• リクエストとページは多対多– リクエストとページを、1対1として一緒に処理するアプローチでは対応できない– 一部のリクエストとページは密接に結びついているので、うまい工夫が出来そう– だが全てを奇麗に解決する手段は?

• 多数の画面を扱うのはやっぱり面倒– みんないろいろ工夫している
Copyright © 1999 by Toshiba Corporation

アプリケーションサーバでは• 一つの解として、リクエストとページの分離– リクエストの処理とページレイアウトを分離出来る構造、メカニズムを提供– もちろんこれで全て解決できるわけではない– アプリケーションサーバのメリットがこれだけという訳でもない

Copyright © 1999 by Toshiba Corporation

2 リクエストとページの分離
ブラウザ
ID:
PASS:

リクエスト r,x
get /login?id=...
ページ p<html><head>...

サーバアプリケーション
r を処理する関数 fr
p = fr ( x )• データ x を持つリクエスト r に対応したページ p を選択する関数 fr• 関数 fr とページ p は明確に分離出来る– fr :リクエスト処理オブジェクト– p :ページレイアウトオブジェクト
Copyright © 1999 by Toshiba Corporation分離することのメリット
ページレイアウト

リクエスト処理*ビジネスロジック*• 責任と処理内容の明確化– 誰が何をするのか• 開発効率、分業化、保守性– ページレイアウトはデザインの専門家に– リクエスト処理はプログラマに– ビジネスロジックは業務の専門家に
Copyright © 1999 by Toshiba Corporation

アプリケーションサーバにおけるリクエストとページの分離• リクエスト処理とページレイアウト– 例えば Servlet / JSP、VBScript / ASP、
Requestオブジェクト / Pageオブジェクト• どちらもプログラムだから、やろうと思えばなんでも出来る• だが、責任範囲以外のことはやるな!
– わざわざ分離したんだから…
Copyright © 1999 by Toshiba Corporation

フレームワーク利用の心構え• そもそもフレームワークは制約の塊– あれをしてはいけない、これをしてもいけない– このフォーマットに従え、範囲を逸脱するな…

• しかしその制約に従って初めて便利– 制約があるから迷わずに済む、ありがたい– 分業化、パターン化、コンポーネント化• 開発では、制約に誠実に従うが吉– 現実には、構造だけ提供される場合が多い– 制約(=ノウハウ)部分は別売
Copyright © 1999 by Toshiba Corporation

3 リクエスト処理オブジェクト• ① データを受け取り、• ② 対応するビジネスロジックを実行し、• ③ ページレイアウトオブジェクトを選択する

Copyright © 1999 by Toshiba Corporation

責任– 渡されたデータをビジネスロジック用に正規化する– ビジネスロジックを実行する– 正常系、準正常系、異常系で分岐する– ページレイアウトオブジェクト用にデータを正規化する– ページレイアウトオブジェクトを呼び出す– その他のことはやっては *いけない*
Copyright © 1999 by Toshiba Corporation

コードのパターン化(Ruby版)
begin # Java なら try - catch< データの正規化(ビジネスロジック用) >< ビジネスロジックの実行 >< データの正規化(ページレイアウトオブジェクト用) >< 正常系のページレイアウトオブジェクﾄの呼び出し >rescue BusinessLogicException
case $!.to_s
when < 例外X >< データの正規化(ページレイアウトオブジェクト用) >< 例外Xのページレイアウトオブジェクトの呼び出し >when...
else
raise # 処理できなかった例外は再発生させる
end
end# rescue されなかった例外はスルーされる
Copyright © 1999 by Toshiba Corporation

正常系

準正常系

異常系

4 ページレイアウトオブジェクト• 与えられたデータを用いて、HTML文字列を生成する– これだけ– デザイナがデザインに集中できる– データで表現可能な範囲なら、変更も容易

Copyright © 1999 by Toshiba Corporation

責任– 渡されたデータをページとして表現する– リクエストオブジェクト名をリンク先とする– その他のことはやっては *いけない*• 前提条件– 必要十分なデータが渡される– データは表示用に正規化されている– 必要なら、データは表示用の構造にパックされている
Copyright © 1999 by Toshiba Corporation

ページのパターン化• 表示すべきデータは全て与えられているので、プログラミングレス→ デザイナの手持ちのパターンが使える• パターンの集積が可能→ どんどん再利用

Copyright © 1999 by Toshiba Corporation

5 まとめ• Webアプリケーション開発では、リクエスト処理とページレイアウトを明確に分離するとよい• アプリケーションサーバは、分離するための構造を提供している• 開発においては、分離する意義を十分理解して、与えられた構造を利用すべきである
Copyright © 1999 by Toshiba Corporation