Comments
Transcript
プレゼンテーション層設計 1 日本アイ・ビー・エム（株）ソフトウェア事業部 塩谷充
03. プレゼンテーション層設計
プレゼンテーション層設計
日本アイ・ビー・エム（株）ソフトウェア事業部
塩谷充
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
1
03. プレゼンテーション層設計
Disclaimer
この資料は日本アイ・ビー・エム株式会社ならびに
日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式なレビューを
受けておりません。
当資料は、資料内で説明されている製品の仕様を保証するものではありません。
資料の内容には正確を期するよう注意しておりますが、この資料の内容は2009
年12月現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様
が変わる可能性があるのでご注意下さい。
今後国内で提供されるリリース情報は、対応する発表レターなどでご確認くださ
い。
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
2
2
03. プレゼンテーション層設計
システム・レイヤー上の本研修のセッションの位置付け
クライアント層 プレゼンテーション層
ビジネス層
インテグレーション層
02.フレームワーク
02.フレームワーク
03.プレゼンテーション層
03.プレゼンテーション層
設計
設計 (Ajax/Dojo）
(Ajax/Dojo）
Resource Tier
Integration Tier
Business Tier
Presentation Tier
Client Tier
01.Webアプリケーション設計概要
01.Webアプリケーション設計概要
リソース層
04.Webサービス設計
04.Webサービス設計
05.非同期処理&キャッシング設計
05.非同期処理&キャッシング設計
06.データ・アクセス設計
06.データ・アクセス設計
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
3
3
03. プレゼンテーション層設計
もくじ
前提条件（設計方式/ブラウザー選定とその理由）
Ajaxの意義と特徴
非同期の動き
具体的手法
Web
APIを使うに当たっての考慮点(Mashup)
Same origin policy
サーバーによる回避策
クライアント側による例外的手法
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
4
4
03. プレゼンテーション層設計
デモ一覧（２点）
非同期のデモ
目的：JSPと違い毎回読みに行くわけではないことを体感
Google mapのXHRリクエストのやりとり
Dojo/Dijitを用いた画面
目的:Dijitを用いた場合の生産性の高さを示す（HTMLとの比較）
カレンダーからの日付入力（マウスカーソルによる選択）
HTML+JavaScriptを用いて作ったケース
z
z
ブラウザーの差異をJavaScriptで吸収
かなり長い
Dijitを用いて作ったケース
z
マークアップ１行で完結
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
5
5
03. プレゼンテーション層設計
1章
前提条件（設計方式/ブラウザー選定とその理由）
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
6
6
03. プレゼンテーション層設計
従来のサーバーサイドJava Webアプリケーション開発
クライアント
Web アプリケーションサーバー
(Controller)
HTTP
GET/POST
ブラウザ
HTTP
(View)
(Model)
(ビジネスロジック/業務ロジック)
Servlet
(HttpServlet)
JSP
EJB/POJO
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
7
従来の手法で最もオーソドックスな手法、画面が都度、フルに遷移する構造になっています。
プレゼンテーションロジックもサーバー側でJSPを使って行うパターンです。アプリケーションステート
もサーバー側で管理を行います。
7
03. プレゼンテーション層設計
Web2.0のアプリケーション開発(JSONを用いたケース)
Webアプリケーションサーバーの基本機能はWeb1.0の時と変わらない
クライアント
JSON=Java Script Object Notation
AMF Action Message Format
ブラウザ
HTML
JavaScript
Web アプリケーションサーバー
HTTP
GET/POST
(Controller)
Servlet
(HttpServlet)
(Model)
Ajax
JSON or XML
Dojo
rpc
JSON
RPC
アダプター
EJB/POJO
(Model)
Flash等
カスタム
Servlet
JSON4J
EJB/POJO
AMF等(XMLも可能）
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
8
前ページで従来の方式の構造を説明しましたが、このページではWeb2.0におけるクライアントと
サーバーの構造を説明します。
ここの図では
クライアント側が何でできているか、何を受け取っているかという観点で記してあります。
同時にサーバー側の構造がどうなっているかという点を記してあります。またクライアントからサー
バーに対する要求はHTTP/POST/GETで行うという前提で
記しています。(RESTも徐々に増えてきていますが。)
最初にサーバー側の構造について説明します。
BL(ビジネスロジック）としては、従来どおりEJBあるいはシンプルなPOJOでサーバー側で保持してい
ます。 この部分は従来の方式と変わりません。
クライアントとのやりとりは、JSON/XMLの両方をサポートしていますが、JSONをお勧めします。JSON
の概要となぜお勧めするかという理由は次のページ以降で
ご説明します。
JSONでもXMLでもクライアントに対して送れるようにRPC (Remote Procedure Call)アダプターは2タ
イプのRPCをサポートしています。それは、HTTP RPC / JSON-RPC
になります。
またカスタムサーブレットの背後にいるJSON4JもXML/JSONの変換機能を備えています。JSON4Jの
機能については９ページ以降でご説明します。
このページで最も重要なことは、この図で示した構造を使う限り、Webアプリケーションサーバーの機
能はWeb1.0の時と同じであるとご理解ください。
（クライアント側の構造についてはp32,33で再度詳しく述べます。)
8
03. プレゼンテーション層設計
JSONとは
RFC 4627で定義
シンプルなデータフォーマット
JSONの記述例
[
{
"業種": "米国政府",
データ型
"フィールド": {
キーは文字列
文字列
（ダブルクォーテーションで括った文字列）
数値（10進表記整数、浮動小数点）
真偽値
配列（データのシーケンス）
オブジェクト（キーと値のペア）
null
"名称"
: "連邦政府",
"責任者"
: "オバマ"
}
},
{
"業種": "野球チーム",
"フィールド": {
文字コードはUnicode
(デフォルトはUTF-8)
"名称"
: "ヤンキース",
"背番号"
: 55
}
}
MIMEタイプ application/json
]
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
9
このページでは前のページで出てきたJSONとは何かについて説明をします。
JSONとはデータフォーマットの規格です。
RFC4627で定義されておりXMLと比較して構造がシンプルです。ストリングの形態が基本であり、特
にキーは文字列である必要があります。
JSONは文字列だけではなく数値そのものを扱うことが可能です。JSONの記述例の下段の配列をご
覧ください。
フィールドの中に、”名称” :”ヤンキース”という記述があり、ストリングになっていますが、その次の
フィールドである”背番号”には55という数値が入っています。
但し扱える数値は十進数のみになります。１６進数や８進数などは扱えません。
9
03. プレゼンテーション層設計
JSON4J
JSONオブジェクト操作の為のJava
API
RPCアダプターを利用せず、JSONオブジェクトを扱うカスタムサーブレットを作
成する際などに有用
XMLからJSONへの変換機能も備える
互換性や処理効率の観点で有利なJSONに変換したうえでAjaxクライアント
にレスポンスを返却可能
XMLサービスとJavaScriptの仲立ちとして活用
JSON
Controller
Servlet
Java/XML
JSON4J
Ajaxクライアント
JavaBean
EJB
Webサービス
(Model)
DB
JSON to Java(or XML)
jarファイルをアプリケーションに含める形で利用(JSON4J.jar)
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
10
P9からP11までP7の図でサーバー側で出てきたJSON4Jについての概要を説明します。
JSON4JとはFP for Web 2.0で提供されるJSONオブジェクト操作の為のライブラリです。
RPCアダプターを利用せず、JSONオブジェクトを扱うカスタムサーブレットを作成する際などに有用
です。
また、JSON4JライブラリはXMLからJSONフォーマットへの変換機能を備えます。
これを利用してAjaxクライアントとのやりとりは一般に互換性や処理効率の観点でJavaScriptにおける
処理で有利なJSONを利用し、
バックエンドへはサーバーサイドでの開発効率に優れるXMLに変換してリクエストするための仲介処
理を簡単に実装することができます。
JSON4JライブラリはRPCアダプター同様にjarの形で提供されます。
<WAS_ROOT>¥web2fep¥optionalLibraries¥JSON4J
・JSON4J.jar
10
03. プレゼンテーション層設計
JSON4J JSONオブジェクトの操作
JSONオブジェクトの操作、シリアライズ
ublic void demoJson()
{
String JSON = “{¥”attribute¥“:¥”foo¥“, ¥”number¥“:100.959}”;
JSON文字列のデシリアライズ
try
JSONObjectの生成
{
JSONObject obj = JSONObject.parse(JSON);
Double dbl = (Double)obj.get(“number”);
Nameをキーとした値の取得
if (dbl == null || dbl.doubleValue() != 100.959)
{
throw new Exception(“Numeric value was incorrect”);
}
Nameをキーとした値の取得
String str = (String)obj.get(“attribute”);
if (dbl == null || !str.equals(“foo”))
{
throw new Exception(“String attribute was incorrect”);
}
obj.put(“addnum", new Double(111.111));
JSONObjectへの追加
String jsonStr = obj.serialize(true);
}
catch (Exception ex)
{
ex.printStackTrace();
}
JSONObjectのシリアライズ
}
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
11
チャートはJSON4Jライブラリの基本的なAPIの利用方法をまとめています。
JSONObjectクラスを利用してJSON文字列のシリアライズ/デシリアライズやプロパティのゲット/セット
が行えます。
APIの詳細は以下のjavadocのリンクをご参照ください。
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.json.help/javad
oc/index.html
11
03. プレゼンテーション層設計
JSON4J XMLコンバーター
com.ibm.json.xml.XMLToJSONTransformer transformメソッド
改行/インデントを含まないデフォルトの形式と、デバッグ用にこれを含む形式
を指定
JSONからJavaオブジェクトに変換
JAXB等のXML<->Java APIによりXML生成
JSON
Controller
Servlet
XML
Webサービス
DB
JSON4J
Ajaxクライアント
//例１：InputStreamでXMLを受けJSON文字列に変換
String jsonmsg = XMLToJSONTransformer.transform(new ByteArrayInputStream(xmlmsg.getBytes()));
//例２：InputStreamでXMLを受けJSONのInputStreamに変換
XMLToJSONTransformer.transform(xmlstream, jsonstream);
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
12
com.ibm.json.xml.XMLToJSONTransformerのtransformメソッドを用いることでXMLからJSONに
フォーマット変換が行えます。
JSON<->XMLデータフォーマット変換プロキシーの一例としては、
フロントエンドから受けたJSONメッセージからJSONObjectを利用してJavaオブジェクトに変換し、
JAXB等のJavatoXMLマッピングAPIを利用してバックエンドの
XMLサービスにリクエストを投げるためのデータ変換処理を行います。
XMLで受けたレスポンスをXMLToJSONTransformerを利用してJSONへ変換し、Ajaxクライアントへ
返却します。
12
03. プレゼンテーション層設計
JSONとXML –どちらを選ぶか・その理由
JSON
XML
データサイズがコンパクト
データサイズが大きい
JavaScriptで扱いやすい・シンプル
JavaScriptでの処理が煩雑
基本はXMLが標準化進んでいる、よ
り汎用的、いろんな言語でサポート
eval()関数でOK
JSONは異なるプログラミング言語の
間でのデータ受け渡しにも向いている
C, C++, C#, Perl, PHP, Python, Ruby etc
拡張ライブラリーが必要
.最近拡張が進んでいる
というのは・・・DOM/SAX標準化
FlashなどもXMLを扱うことも可能
データ型がきちんと定義されている
定義が厳密
Namespace, validation (JSONにはない）
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
13
P7でJSONをお勧めするという理由をこのページで説明をします。
結論としては、通常はJSONを使ってリターンを受け取るのがお奨めです。
理由としては、二つあります。
JSONはXMLと比較してデータサイズがコンパクトです。
二番目の理由では、扱いがXMLと比較してシンプルでわかりやすいと言うことになります。JSONは
JavaScriptのeval()関数で
ストリングとして扱うことができるので、扱いやすいといえます。
但し実際の構築でJSONをeval()で扱うに当たってはご説明します。
eval関数で扱うと実際にはcode injectionなどのセキュリティー上の問題が発生するので、次ページ
で補足説明をします。
このページの点線より下の部分は、JSON・XMLそれぞれの特徴という意味合いであって選定理由の
決定的な要素ではありませんが、JSON
はいろいろな言語で使えるようになってきています。
13
03. プレゼンテーション層設計
参考 JSONの取り扱い セキュリティ上の問題
コードインジェクションによるセキュリティの問題
eval()でJSONを受け取るとストリングの関数をそのまま実行してしまう可能性
回避策
Dojoのメソッドを使用する Dojo.fromjason
parseJSON() を使用 etc
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
14
JSONを実際に受け取るに当たってのセキュリティ上の配慮点について補足説明をします。
前のページではJSONはストリングなのでJavaScriptのeval()を使用して受け取りができると説明をしま
したが、実際にはeval()関数でJSONを受け取ってしまうとストリング内に関数が入っていた場合その
まま実行されてしまうので、セキュリティ上の問題（コードインジェクション）により認証のすり抜けなど
の問題が発生する可能性があります。
このため回避策として新しいメソッドである
parseJSON()を用いたり
DojoのメソッドであるDojo.formjason
などの実装を使うことをお勧めします。これらの方法だとストリングの中に仮に関数が入っていても関
数としては扱わずに文字列として扱うのでコードインジェクションを防ぐことが可能になります。
14
03. プレゼンテーション層設計
プレゼンテーション層設計の前提（ブラウザーの選定）
クライアント側はブラウザーを使用する(下記の順番で開発すること
が望ましい）
FireFox+Firebug(Java Scriptのデバッグツール）
z
z
z
z
Console API, (console.log, console.debug, console.time etc.)
Command Line API
XHR parameter, header, response, リターンの解析が可能
ブレークポイントの設定が可能
IE6/7/8
IE6の問題点（特にJavaScriptに関して）
z
JavaScriptについて
○
○
z
IE6はJavaScriptの実装（準拠度）に問題がある
JavaScript処理のスピード
ＣＳＳの問題
上記以外
Google Chrome,Safari
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
15
クライアント側の実装に関しての前提を説明します。
クライアント側の実装に当たってはWeb browserを使用することを前提とします。
Browserの開発順番に関しては、この資料で書いてある順番で行うことをお勧めします。
最初のFirefoxですが、JavaScript処理に関して標準準拠性が高い、debugging toolとしてFirebugの
機能が充実しておりXHRとのやりとりだけでなく、ブレークポイントや、クライアント側として重要な要
素であるJavaScriptの処理速度パフォーマンスの測定も可能です。
Firebugの動き・機能の概要については次のページでデモを交えて説明します。
もう一つの代表的なbrowserであるInternet Explorerを二番目のプラットフォームとして開発するのが
よいと思います。IEは最も多く使われているbrowserなので、はずすことはできませんが、firefoxなどと
比べて以下のような問題があります。
特にIE6はJavaScriptの処理に関して
のJavaScript処理に関するパフォーマンス（FirefoxやChromeとのベンチマークの比較において）が
いいとはいえない。
JavaScriptの解釈に関してW3Cの準拠度が良くない。
CSS（カスケードスタイルシート）の問題
これらについてはこの後P16,17で説明をします。
開発順番としては最後にGoogle Chrome, Safariなどを使うといいと思います。
15
03. プレゼンテーション層設計
各ブラウザーのScript処理ベンチマーク
出典
http://www.opensp
c2.org
単位はmsec
古籏一浩氏の許可
を得て掲載
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
16
P14でご説明したとおり、JavaScriptの処理ごとにIEとFirefoxとで速度を比較してみました。
おおむねIE6についてはFirefoxと比較して処理スピードが遅いということがおわかりいただけると思
います。
16
03. プレゼンテーション層設計
IE6固有の問題例（CSS)
ボックスの幅や高さを算出するときにパディングやボーダーのサイズを
含めてしまう
閲覧領域からはみ出す要素がない状態でもスクロールバーが表示
されることがある
body要素の内容領域をはみ出す部分がレンダリングされない
背景色が指定された要素内にフロートがあるときに要素内の文字
が消える
マージンに負数が指定された要素でボーダーがずれてゆく
親要素からはみ出した子孫要素の一部が消える
left, topが指定された要素ではright, bottomを認識しない
インライン要素に指定したパディングやボーダーの上下が消える
etc・・・
参考URL
http://web.archive.org/web/20071011033201/http://cssbug.at.infoseek.co.jp/detail/winie.html
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
17
P14で説明したIE6の問題として上げたCSS（カスケードスタイルシート）の代表的な問題をここに上げ
ておきます。
17
03. プレゼンテーション層設計
Ajax開発管理のポイント
サーバー側でのビジネスロジック部分は以前と同じ
Controllerの肥大化を避ける
アプリケーションステートもサーバー側で保持
アプリケーションステートと画面コントロール情報をきれいに切り分けしておく
適切にコンポーネント分割を行い、Controllerはコンポーネント間の制御に専念する。
また、Controllerの実装は、Ajax Toolkitを適用することで汎用化を図る。
Dojo Toolkitなどの積極的利用
Façade(ファサード）による管理
コードのメンテナンス性の向上
重複する処理を共通化し、無駄なコードを省く
上記に加えて、以下の効果が挙げられる。
Facadeのスタブをクライアント側に作ることにより、サーバーを必要としないローカル開
発が可能となる
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
18
このページではプロジェクトマネジメントの観点からみてWeb2.0ベースがどのように異なるのか、
Ajax向けの管理注意点を説明します。
先ほどもふれたとおりWebアプリケーション側での管理は従来の方式と同じです。つまりアプリケー
ションステートをサーバー側で保持するようにします。
クライアント側で画面をある程度面倒をみる場合には、アプリケーションステートと画面コントロール
情報は、切り分けが難しい場合もあるのでプロジェクト毎にアプリケーションの設計基準・ガイドを作
成し明確化を計ることが望ましいです。（開発効率アップ、品質アップ）
18
03. プレゼンテーション層設計
2章
Ajaxの意義と特徴
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
19
19
03. プレゼンテーション層設計
まとめ 非同期(Ajax)の特徴とメリット
メリット
ユーザビリティーの向上
XMLHttpRequestなどを活用し、JavaScriptを通じてサーバーと通信
その結果として
⇒クライアントはデータの読み込み時間に待たされることなく、インタラ
クティブな操作が可能
⇒クライアントからの入力最中に検索を行うといったように、非同期的な
動きが可能
⇒スクロール機能が高速化、(サーバーとの通信無しで）データのフィルタ、
ソート機構追加可能
考え方の特徴
元の発想はActiveXやJavaアプレットを使った考えと同様⇒クライアントでや
れるところは、クライアント側でやってしまおうと言う発想
Ajax（Asynchronous JavaScript And Xml)
クライアントサイドのJavaScriptを使用
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
20
非同期を使うメリットをまとめます。
メリットとしては、XHRを使うことで結果としてユーザビリティの向上を図ることが可能になります。
具体的には、
クライアント側はサーバーからのデータを待つことなくインタラクティブな操作ができる。
クライアントからの入力最中に検索を行うと言うことや、スクロールの高速化、データのフィルタ、ソー
トなどが
手早くできるようになります。
画面などのすべてをサーバーに頼るのではなくJavaScript(Ajax)でできるところはクライアント側で
やってしまおうという方針が基本にあります。
20
03. プレゼンテーション層設計
3章
具体的手法
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
21
21
03. プレゼンテーション層設計
クライアントサイドのデザイン
Service
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
22
機能面で見たクライアント側のコンポーネント分割
①Controller
コンポーネント間の連携の制御
②Service Invocation
Ajax Callなどのサービス呼び出しを実行する
サービス呼び出し結果を受け取る（同期／非同期）
③Application State
Application StateにアクセスするためのAPIを提供する
Application Stateのライフサイクルを管理する
④View
View ComponentsにアクセスするためのAPIを提供する
View Componentsのライフサイクルを管理する
View Componentsにバインドするデータを管理する
⑤Event Handler
Client上のComponents間でのイベント送受信を管理する
22
03. プレゼンテーション層設計
デザイン上の考慮点 1
画面変更に対して柔軟なデザインの考慮
Ajaxを利用したリッチクライアントでは、画面構成や機能が複雑になりやすく、変
更頻度も比較的高い傾向
具体的解決策
Widgetの活用
・Widget
・部品化されたWeb画面部品
・主にDHTML+CSS+JavaScriptで構成
・Presentation Manager
・Widgetの配置を制御する
・Widgetのレンダリング(Look&Feel)を制御する
・Connector
・Widget間を接続し、イベントを伝搬する
考慮点
WidgetをホストするPresentation Manager
z
Dijit: Dojo Toolkitが提供、ConnectorはDojoのイベント機構を利用
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
23
次に、JavaScriptで非同期（Ajax)のリッチなクライアント機能を実現するに当たってのデザイン上の考
慮点を記します。
Ajaxを使用してリッチクライアントを作成する場合、一般的に画面構成や機能が複雑になりやすく、
変更頻度も比較的高い傾向があります。
そのためプロプラエタリーな書き方をするのではなく、共通化された部品、部品同士のコントロール
を行うPresentation Manager, ConnectorなどはWidgetを使用することで共通化することが大事です。
23
03. プレゼンテーション層設計
デザイン上の考慮点 2
View実装上の考慮点
具体的解決策・・・
汎用化
クライアントサイドのレンダリング
AjaxはIDEが比較的まだ弱い
FlashだとIDEが比較的充実
Webアプリの制限
Flash/Java Applet
DHTML+JavaScriptで実現が難しい場合、無理をしないでFlash/Java Appletを併用するなどのオプショ
ンも考慮するべき
理由・背景
Dojo ToolkitなどのAjax Toolkitを積極的に採用する
例 ローカルファイル・プリンタの利用、ファイルアップロード（UIの向上）、ドラッグアンドドロップ対応
Eclipse
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
24
Ajaxの部品、制御のコントロールを行う手段として具体的にはDojo Tool Kitがあります。
AjaxはまだIDEなど開発ツールがあまり充実していませんが、Dojo (Dojo Tool Kit)はWidgetも充実し
ており部品、connectorなどもそろっており
開発しやすいという点があります。またDojoは、基本的にマークアップ一行で部品を呼び出せるとい
う記述の容易性もあります。
（Dojoでの記述は後ほどサンプルと記述のデモをお見せします。）
またケースによってはAjaxでやるばかりではなく、FlashやJava Appletなどを使った方が効率的に開
発できる場合もあります。
具体的には、ローカルの資源をさわる場合（ローカルプリンタの利用など）、ファイルアップロードなど
を行う場合などがそれに該当します。
24
03. プレゼンテーション層設計
Dojo 選択の理由1 (Javascriptでの開発の課題)
ブラウザー間で挙動・実装方法が異なる
ブラウザー間で同様に動作する
アプリケーションを実装するのは煩雑
EventハンドリングやDOM操作など
Dojoがブラウザー間の差異を吸収
マルチ・ブラウザー対応の
アプリケーション開発が容易に
但し、Dojoがサポートするブラウザーの使用が前提
ユーザー
アプリケーション
ユーザー
アプリケーション
Internet Explorer
Mozilla Firefox
ユーザー
アプリケーション
ユーザー
アプリケーション
DOJO
DOJO
Internet Explorer
Mozilla Firefox
Internet Explorer 6.0以上
Firefox 1.5以上/Mozilla
Konqueror 3.5以上
Safari (currently 3.0.x), 2.0 はMac OS10.5のリリースより、サポートせず。
Opera (currently 9.0+)は、Dojoコアのみのサポート、Dijitはサポートせず。
Cf. http://dojotoolkit.org/support/faq/what-browsers-does-dojo-support
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
25
ではDojoを選択する理由を三つご説明します。
JavaScriptでアプリケーションを開発する際の課題として、ブラウザー実装に挙動が依存してしまい、
複数のブラウザーで同様に挙動するアプリケーションを構築するには、ブラウザー毎に実装を分け
たコードを用意するなど煩雑な手続きが必要でした。
Dojoを利用してアプリケーションを開発することにより、ブラウザー間の差異をDojoが吸収するため、
ユーザーはマルチ・ブラウザー対応のアプリケーションをより容易に実装することが可能になりました。
但し、Dojoがサポートするブラウザーの使用が前提となります。
25
03. プレゼンテーション層設計
Dojo 選択の理由２ (Dojoの記述の容易性)
宣言的マークアップによる画面部品の再利用が可能
タグを書くだけで利用可能
デモ・サンプル
日付テキストボックスを表示、マウスクリックで日付入力が可能
Dojo tool kitパス指定
CSS設定
Dijitの前準備
<script src="dojo¥dojo.js" djConfig="parseOnLoad: true">
@import "dojo¥resources¥dojo.css";
dojo.require("dojo.parser");
dojo.require("dijit.form.DateTextBox");
部品の呼び出し
<div id="button" dojoType="dijit.form.DateTextBox"> </div>
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
マークアップ一行で
26
Dojo選択の理由の二番目として記述の容易性があります。
P25でふれましたがDojoの部品が基本的に一行のマークアップで利用できることをお見せします。
実際にエディターを使って作成とデモを行います。
デモでは日付テキストボックスを表示して、マウスクリックで日付入力が可能な画面を作成します。
マウス入力の場合ブラウザー毎に差異を考慮する必要がありましたが、Dojoの場合、それを意識し
なくても作成可能です。
部品を呼び出す部分は一行のマークアップですが、事前準備として以下の三つをscriptとして書い
ておく必要があります。
Dojo tool Kitのパスの指定
CSSの設定（Dojoを使う場合CSSの設定は必須です。)
部品呼び出しのためのメソッドの呼び出し
をあらかじめ行っておきます。
26
03. プレゼンテーション層設計
Dojo作成のポイント（一部省略）
<html>
<head>
<title>Dojoのテスト</title>
<meta http-equive="Content-Type" content="text/html;charset=UTF-8"/>
<script src="dojo¥dojo.js" djConfig="parseOnLoad: true"> Dojo tool kitパス指定
<style type="text/css">
@import "dojo¥resources¥dojo.css";
@import "dijit¥themes¥hogehoge¥tundra.css"; CSS設定(Seria, nihilo)
</style>
<script type="text/javascript">
<!-- dojo.parser -->
dojo.require("dojo.parser");
Dijitの前準備
<!-- widget load -->
dojo.require("dijit.form.DateTextBox");
</script>
<div id="button" dojoType="dijit.form.DateTextBox"> </div>部品の呼び出し
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
27
実際に作ってみたDojoを用いてポイントを説明します。
ポイントは前のチャートにもある通り、
①Dojo tool kitパス指定（これはページの５行目で行っています。)
②CSS設定 (styleタグを用いて、CSSの設定を行います。)
③Dijitの前準備（scriptタグを用いて行います。）
④Dijitの呼び出し
これは一番下の行で行っています。実際にボタンを呼び出して表示するのはこのマークアップ一行
になります。
27
03. プレゼンテーション層設計
DojoのGUIコンポーネントの例
チェック・ボックス
コンボ・ボックス
日付テキスト・ボックス
インライン編集ボックス
通貨テキスト・ボックス
数値スピナー
フィルタリング選択
数値テキスト・ボックス
スライダー
テキスト・エリア
テキスト・ボックス
時間テキスト・ボックス
検査テキスト・ボックス
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
28
Dojoの部品をDijitと呼びますが、Dijitで提供される部品の例の一覧を示します。
28
03. プレゼンテーション層設計
ご参考 DojoX
先進的、実験的なモジュールを提供
安定度に関しては様々
サポートの条件やレベルも様々
将来的にはdojoコア/dijitとして提供されることもあり得る
例：dojox.charting
例：dojox.grid(実際にはよく使用されている）
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
29
DojoXは、先進的、実験的なモジュールを提供しているコンポーネント群。dojoコアやdijitと異なり、
モジュールの安定度に関しては千差万別です。
Dojoのv0.4ではdojoコアのモジュールとして提供されていたモジュールが、V1.0リリースとなるタイミ
ングでdojoXに移されたモジュールもありますが、モジュールによってはα版のようなレベルのものも
ありますので、使用する場合には事前に検証が必要です。
また、DojoXのモジュールは現在も更新が続けられており、現在DojoXとして提供されているモ
ジュールであっても、将来的にはdojoコアやdijitとして提供される可能性があります。
29
03. プレゼンテーション層設計
Dojo 選択の理由3 (国際化対応の問題)
ハードコーディングしないで三つのステップで対応可能
具体的手法1:ロケール指定
具体的手法2:リソースバンドル
使用するロケールの宣言
翻訳ファイルの指定
JSON, UTF-8で記述
nlsディレクトリに格納 nls=native language support
具体的手法3：関連ファイルの相互関連づけ
Javaのjava.util.ResourceBundleに似た国際化フレームワーク
メソッド dojo.requireLocalization()
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
30
Dojo選択の理由の第三番目として国際化対応があります。
Dojoはハードコーディングをしないで、国際化対応が可能です。
ロケールの具体的な切り替え方法は、ここにあるとおり
ロケールの宣言
ロケールを変更するためのリソース指定
を行う必要があります。
使用しているロケールを通知するにはBrowserのaccept langを用いて切り替えを行っています。
30
03. プレゼンテーション層設計
画面遷移の考慮点1(Ajaxデラックス）
クライアント
ブラウザ
JavaScript
Ajax
コントローラー
HTML
Web アプリケーションサーバー（同一サーバー）
HTTP
GET/POST
(Model)
JSON or XML
Dojo
rpc
JSON
Flash等
(Model)
RPC
EJB/POJO
(Model)
RPC
アダプター
EJB/POJO
(Model)
アダプター
RPC
EJB/POJO
(Model)
カスタムアダプター JSON4J
EJB/POJO
(Model)
カスタム
Servlet
EJB/POJO
JSON4J
Servlet
カスタム
EJB/POJO
JSON4J
Servlet
画面遷移なし
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
31
Ajaxでクライアント側を作成するに当たっては、さらに分けるとAjaxデラックスとAjaxライトがあります。
ここではAjaxデラックスとAjaxライトの比較説明を行います。
最初にAjaxデラックスの概念図と特徴を説明します。
AjaxデラックスとAjaxライト両者ともにweb serverとの受け渡し、送受信方式は共通です。
異なる点は以下の通りです。
①クライアントサイドでのViewおよびControlの実装が必要です。
②サービスとして提供されるサーバーサイドのModelをWebリモート・パターンで利用する。
③クライアント側でのアプリケーションステートの保持の必要があります。
アプリケーションステートの保持に関してはさらに以下の考慮点があります。
WebブラウザーではStateを格納する方法や格納可能なデータサイズに制限がある。 具体的手法と
しては、
①in-memory (JavaScriptのObject)
②cookie
③offline storage
長所としてはサーバー側の負担が軽くなるが、欠点としてクライアント側のコントローラー肥大化に繋
がりパフォーマンスへの影響が出る場合もあります。
また、この方式を用いた場合には、サーバー側での管理対象がWeb1.0の時と異なるので、現時点
ではこの方式はとらない方がよいと思われます。
また結果として、クライアント側は基本的に画面の遷移がなくなります。
31
03. プレゼンテーション層設計
画面遷移の考慮点2 (Ajaxライトの採用）
クライアント
ブラウザ
HTML
Web アプリケーションサーバー
HTTP
(Controller)
GET/POST
Servlet
(HttpServlet)
JavaScript
(Model)
Ajax
JSON or XML
Dojo
rpc
JSON
EJB/
POJO
RPC
アダプター
(Model)
Form submit
カスタム
Servlet
JSON4J
EJB/
POJO
Flash等
Form submit
クライアント
クライアント
ブラウザ
ブラウザ
HTML
HTML
JavaScript
JavaScript
Ajax
Ajax
Dojo
rpc
Dojo
rpc
Flash等
Flash等
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
32
このページではもう一つの方式であるAjaxライトを説明します。
結論から先に申し上げるとWeb1.0から移行する場合にはこの方式を使われることをお勧めします。
この方式を使う限りWebアプリケーションサーバーで管理する単位、画面遷移単位はWeb1.0と変わ
りません。
チャートはAjaxライトをサーバーサイドの視点から図式化したものです。
一般に従来のStrutsやJSF等のMVCフレームワークはページ遷移を管理するための機構を持ち、
サーバー側でステートを管理します。
フォーム情報がサブミットされるとHTTP POSTメソッドで入力情報がサーバー側に引き渡され、サー
ブレットベースのControllerが定義に基づいてバックエンドのModel層にデータを引き渡し結果を受
けます。ControllerはJSP等の技術を利用してブラウザにページ単位で情報を返します。
AjaxライトではサーバーサイドでのMVCの仕組みを維持しつつ、ユーザビリティーを向上させるため
利用可能な範囲でDijit等の高機能UI部品や
Webリモート・パターンを採用したリッチなユーザー・エクスペリエンスの取り込みを行います。
既存のJava EEアプリケーションに含まれるビジネスロジックをAjaxクライアントから利用できるように
公開する上では後述するRPCアダプターや
JSON4J、もしくはWebサービスの活用が考えられます。
32
03. プレゼンテーション層設計
Ajax開発用ツールのご紹介1
RAD V7.5 AJAX: Dojoツールキット
JavaScriptリッチUI構築のためのツー
ルキット
オープン・ソース + IBM拡張
ファセットによるプロジェクトへの容易
な導入
パレットからドラッグ＆ドロップでページ
に配置
ページ・デザイナー上で可視化される
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
33
Ajax, Dojoで開発するに当たってRational Application Developer V7.5も対応しているので簡単に紹
介します。
33
03. プレゼンテーション層設計
Ajax開発用ツールのご紹介2
RPCアダプターによるWebリモーティング
サーバーサイドのPOJOメソッドをHTTP URL形式で公開
結果をJSONもしくはXMLで応答
応答のデータ・
フォーマットを指定
（JSON or XML）
HTTPメソッドを指定
（GET or POST）
当該POJOメソッドを
呼び出すためのURL
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
34
34
03. プレゼンテーション層設計
4章
Web APIを使うに当たっての考慮点(Mashup)
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
35
次にWeb APIを使用するに当たっての考慮点を説明します。
35
03. プレゼンテーション層設計
Same Origin Policyとは
クライアントは、GET/POSTを
行った相手のWebアプリケー
ションからサービスを受け続け
ないといけない
標準的回避方法
Proxy server
Server side mashup
JavaSｃript上の制限
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
36
クライアントをAjax (JavaScript, Dojo)で作成する場合webサーバーの利用に関してSame Origin
Policyという制限があります。
これは、クライアントはGET/POSTを行った相手のWebアプリケーションサーバーからサービスを受
け続けないといけないという制限です。
他のWebサーバーのサービスを利用したい場合には、推奨されうる標準的な回避方法としては
Proxy serverをたてる
Server side Mashupを利用する
という方法があります。
36
03. プレゼンテーション層設計
標準的な手法Proxy/Server side mashupについて
複数の Web サービスの API を組み
合わせ、あたかも一つの Web サービ
スのようにする機能のこと
PHP, Ajaxなどスクリプトを使用
製品などの例
WebSphere sMash (Project ZERO)
Project ZeroおけるServer side
Mashupの例
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
37
標準的な回避方法としてServer side Mashupがあります。製品としてはProject ZEROをベースにした
WebSphere sMashがあります。
37
03. プレゼンテーション層設計
例外的手法としてのClient sideマッシュアップ
実装方法
①JSONP
②IFlame
③(Adobe)Flash
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
38
これに対してクライアント側でsame origin policyを回避する方法について説明をします。
サーバー側で回避する方法に比較してこの方式は例外的な手法になります。
方法としては大きく三つあります。
①JSONP
②IFlame
③Flash
を用いる方法になります。
以降のページでこの手法を使うケースとそれぞれの三つの手法ついて説明をします。
38
03. プレゼンテーション層設計
クライアント側からのSame Origin Policyを回避するケース
z
背景
Client-side Mashupを実行する際、Base Server以外のServerに対して
Clientからリクエストを送信する必要がある
z
具体的な適用例
Client-side mashupが必要となるサービスを利用する場合は必須
¾
MapsView Componentを提供するサービスを利用する場合
¾
例 Google Map
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
39
クライアント側からsame origin policyを回避しないといけないケースについて説明をします。
Client-side Mashupを実行する際、Base Server以外のServerに対してClientからリクエストを送信す
る必要があるがそれに該当します。
具体的にはGoogle mapなどMap Viewコンポーネントを提供するサービスを利用したいケースがそれ
に該当します。
39
03. プレゼンテーション層設計
Client mashupの具体的方法
JSONP
Scriptタグの内側は、same origin server外も利用可能なので、これを利用
する
Scriptの中身を動的に生成することで、Web browserの制限外となる
Dynamic Script Tagの説明
Hidden
(JSON with Padding)
Iframe
インラインフレームはsame origin policyの制限外なのでそれを利用
Flashの利用
Adobe Flashのクロスドメイン機能を利用する
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
40
JSONPとはJSON with Paddingの略です。
この方式はscriptタグの内側はsame origin policyの制限外なのでそれを利用しようという方式です。
Hidden Iframeはインラインフレームはsame origin policyの制限外なのでそれを利用しようという方式
です。
AdobeFlashはFlashのクロスドメインの機能を利用してsame origin policyを回避しようとする方式です。
40
03. プレゼンテーション層設計
Avoiding Same Origin Policyの例(1/2)
z
JSONP (JSON with Padding)
<script>タグの読込先は、ベース・サーバーに限定されない
<script>タグの中身を動的に生成することで、実質的にクロスドメイン呼
び出しが実現できる
⇒Dynamic Script Tag
例）
<script type="text/javascript"
src="http://s.hatena.ne.jp/blog.json/http://d.hatena.ne.jp/hatenastar/?call
back=callback"></script>
⇒この<script>タグは、次のような関数を生成する
callback({"title":"¥u306f¥u3066¥u306a¥u30b9¥u30bf¥u30fc¥u65e5¥u8a18
","star_count":"72048","uri":"http://d.hatena.ne.jp/hatenastar/"});
⇒この関数を呼び出すようにコーディングしておく
参照
¾
¾
http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/
http://zapanet.info/blog/item/1084
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
41
JSONPの動きを補足します。
先ほども説明したようにscriptタグの読込先は、ベース・サーバーに限定されません（same origin
policyを回避できる）
<script>タグの中身を動的に生成することで、実質的にクロスドメイン呼び出しが実現可能です。
ここの例にあるようにscriptタグの中身を動的に生成することでクロスドメインを実現できます。
41
03. プレゼンテーション層設計
Avoiding Same Origin Policyの例(2/2)
z
IFrame
z
IFrame(インラインフレーム)は、別ウィンドウ扱い
⇒ベースサーバーとは別のサーバーを参照可能
ブラウザに埋め込んだ隠しIFrameからHTTPリクエストを送受信することで、
擬似的にクロスドメイン呼び出しが可能
Flash
アクセス先サーバーにcrossdomain.xmlを配置
⇒クロスドメインアクセスを認めるアクセス元を指定する
ブラウザに埋め込んだFlashクライアントから、クロスドメイン呼び出しが可
能
参考
¾
http://gihyo.jp/dev/serial/01/web20sec/0004
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
42
Hidden IFrame(インラインフレーム)は、別ウィンドウ扱いなのでベースサーバーとは別のサーバーを
参照可能です。結果としてブラウザに埋め込んだ隠しIFrameからHTTPリクエストを送受信することで、
擬似的にクロスドメイン呼び出しが可能になります。
Adobe Flashの場合は、アクセス先サーバーにcrossdomain.xmlを配置してクロスドメインアクセスを認
めるアクセス元を指定することでクロスドメインの実現が可能になります。
42
03. プレゼンテーション層設計
クロスドメイン機能実装の考慮点
セキュリティの問題
z
考慮すべき点
セキュリティ脆弱性を引き起こすリスクを伴うことを認識して利用すべきパター
ン
Client-sideでの制御が複雑になる場合が多い
¾
ライセンス上、Client-side mashupが必須となる場合（例：広告表示な
ど）
Client
sideの実装の問題
やや処理が複雑になる
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
43
最初にお伝えしたとおりクライアント側でクロスドメインを行うには問題があります。
具体的には
セキュリティ脆弱性を引き起こすリスクがある。
Client-sideでの制御が複雑になる場合が多い。
という二点を十分に考慮するべきです。
43
03. プレゼンテーション層設計
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
44
44
03. プレゼンテーション層設計
まとめ
クライアントの操作性向上
Ajaxライトでの開発
クライアント側はWeb browser, JavaScript
z
FireFox+Firebug, IE, Chromeの順番
DojoのWidgetを使用
画面遷移に変更はないため、サーバー・サイドは従来通り
サーバーとのやりとり - JSONを使用
Web APIを使うに当たっての考慮点
Same Origin Policyの回避
z
z
Proxy/Server side mashupでなるべく実装
Clientで実装する場合
○ JSONP
○ IFlame
○ (Adobe)Flash
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
45
最後にまとめです。
クライアント側の設計方針は
クライアント側は、まずはFirefox+firebugで開発をしていきましょう。
Ajaxライトを採用し、Dojoを積極的に用いていきましょう。この方式であればweb application serverの
管理単位は以前と変わりません。
サーバーとのやりとりはJSONを用いればデータ量も少なく、扱いも楽です。
Same origin policyに関しては、なるべくproxyやserver side mashupでやるようにしておきますが、や
むを得ない場合のみ
JSONP, IFlame, Flashを使うこととしてください。その中でもJSONPが一番いいと思われます。
45
03. プレゼンテーション層設計
参考資料
WAS
Feature Pack for Web 2.0 ワークショップ資料 2008/4
http://www.ibm.com/developerworks/jp/websphere/library/was/was_web20fep_ws/
Overview
Dojo
Java EEの拡張 RPCアダプター、JSON4J、ESB
「ブラウザーの種類ごとのJavaScript処理速度比較」
古籏一浩
http://www.openspc2.org
http://www.thinkit.co.jp/free/books/2/1/1/
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
Joshua Eichorn
46
46