フロントエンド設計 1 ISE Webアプリケーション基盤 Webアドバンスド・ソリューション グループ
by user
Comments
Transcript
フロントエンド設計 1 ISE Webアプリケーション基盤 Webアドバンスド・ソリューション グループ
フロントエンド設計 ISE Webアプリケーション基盤 Webアドバンスド・ソリューション グループ 高橋 健太（[email protected]） 1 02.フロントエンド設計 02.フロントエンド設計 Disclaimer この資料は日本アイ・ビー・エム株式会社ならびに 日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式なレビューを受けておりませ ん。 当資料は、資料内で説明されている製品の仕様を保証するものではありません。 資料の内容には正確を期するよう注意しておりますが、この資料の内容は2010年9月現在の情 報であり、製品の新しいリリース、PTFなどによって動作、仕様が変わる可能性があるのでご注意 下さい。 今後国内で提供されるリリース情報は、対応する発表レターなどでご確認ください。 2 WAS V7 アプリケーション・デザインWorkshop Part2 2 02.フロントエンド設計 02.フロントエンド設計 Agenda 1. キーとなる技術要素 – – – – 2. 3. アーキテクチャー・デシジョン 1. Ajax・リッチクライアントを採用するか？ 2. Ajaxを採用する場合、利用パターンをど うするか？ 3. Ajaxの実装方式は何か？ 4. どのフロントエンド技術を採用するか？ マクロ設計の重要な考慮ポイント 1. 画面デザインとHTMLの分割方式 2. リッチクライアントのパフォーマンス 3. リッチアプリケーションの状態の保持・復 元 4. RESTful Webサービスの設計 5. JavaScriptの単体テスト方式 – 【参考】 画面部品のコンポーネント化方式 – 【参考】 カスタムタグの実装方式 – 【参考】 バリデーションの方針 JSP, JSF JavaScript, Dojo Toolkit, Ajax Feature Pack for Web 2.0 RESTful Webサービス, JAX-RS 4. マイクロ設計の重要な考慮ポイント – – 5. 3 JavaScriptのデザインパターン (MVPパターン) 【参考】 バリデーターの実装 まとめ WAS V7 アプリケーション・デザインWorkshop Part2 3 02.フロントエンド設計 02.フロントエンド設計 キーとなる技術要素 4 WAS V7 アプリケーション・デザインWorkshop Part2 4 02.フロントエンド設計 02.フロントエンド設計 JSP (JavaServer Pages) 概要 – HTML内にJSPタグを埋め込み、その出力結果を HTMLとして返すテンプレート化の技術 – Servletと連携して、Javaオブジェクトのインスタンス を容易に利用することが可能 – WAS v7ではJSP 2.1までが利用可能 ●JSPの連携イメージ コンテンツ部の生成 アクセス Servlet 処理の委譲 (forward) メリット – デザイン部とコントローラ部を分離することができる – テンプレートを分割することで、それぞれのデザイン 部分を分離することができる JSP HTML 単体ではできない（難しい）こと – ページ間の画面遷移の容易な変更 – 画面表示に関わるBeanのスコープ管理 JSP JSP 画面パーツの生成 5 WAS V7 アプリケーション・デザインWorkshop Part2 JSP (JavaServer Pages)は、HTML内にJSPタグを埋め込み、その出力結果を HTMLとして返すテンプレート化の技術です。 Servletと連携して、Javaオブジェクトのインスタンスを容易に利用することが可能に なります。 最新バージョンは2.2 (Java EE 6)で、WAS v7では2.1、WAS v6.1では2.0までが 利用可能です。 JSPの仕様は、 JSRにて規定されています（JSR 152 (JSP 2.0), JSR 245 (JSP 2.1, 2.2) ）。 一般には、デザイン部とコントローラ部を分離するために利用されます。また、デザイ ン部の中でも、ヘッダー部、フッター部、左右ペイン、コンテンツ部、などにテンプ レートを分割することで、それぞれのデザイン部分を分離することができます。 JSPだけでは実現が難しいこととして、ページナビゲーション（ページ間の画面遷移 の容易な変更）や、画面表示に関連するJavaBeansとの連携などが挙げられます。 こうした要件に対しては、フレームワークを用いて、設定ファイル化したり、アノテー ションを利用したりすることで実現可能になります。 5 02.フロントエンド設計 02.フロントエンド設計 【参考】 JSPの機能 (抜粋) JSP 1.xの機能 – スクリプトレット – ディレクティブ • • page, include taglib : カスタムタグを作成して読み込むための機能 – アクションタグ • ： 宣言なしで利用できるオブジェクト request, response, pageContext, session, application, out, config, page, exception – カスタムタグ • ： <jsp:xxxx>形式で提供されるカスタムタグ include, param, forword, getProperty, setProperty, useBean, plugin – 暗黙オブジェクト • ： <% %>で括った部分のJavaコードの実行 ： <%@ %>で括った部分に書かれた設定の読み込み ： 自作の処理を組み込んだ、新しいタグを定義できる タグハンドラクラスとTLDファイルを作成し、web.xmlへの設定を行う（クラシック・タグハンドラ） JSP 2.xの機能 – EL (Expression Language, 式言語)、Unified EL（統一式言語）の利用 • • – – – – 6 ${Bean.prop}形式、#{Bean.prop}でのBeanの持つプロパティーへのアクセス JSP2.2から、Beanのメソッド呼び出しも可能になる JSPフラグメント タグファイル シンプル・タグハンドラ アクションタグの追加 ： ： ： ： JSPの断片をJSPから利用できる JSPフラグメントなどのファイルをカスタムタグとして利用するための機能 より容易に利用できるカスタムタグの実装方式の追加 attribute, body WAS V7 アプリケーション・デザインWorkshop Part2 6 02.フロントエンド設計 02.フロントエンド設計 JSF (JavaServer Faces) ●JSFのGUIページ遷移管理 概要 – ViewやController部分を、より容易に作成するため のフレームワークを提供する – WAS v7ではJSF 1.2が利用可能 メリット – ページ間の画面遷移やBeanのスコープ等を設定 ファイル化できる – 画面部品のコンポーネント化が可能 単体ではできない（難しい）こと – 画面が表示された後に、画面の内容を書き換える – ブラウザーにリッチなユーザーインターフェースを追 加する • JavaScriptと組み合わせることで実現可能 7 WAS V7 アプリケーション・デザインWorkshop Part2 JSF (JavaServer Faces)は、ViewやController部分を、より容易に作成するための フレームワークで、画面部品のコンポーネント化の方式を提供する技術です。JSFは、 基本的にはJSPと組み合わせることが前提となっています。最新バージョンは2.0 (Java EE 6)で、WAS v7では1.2、WAS v6.1では1.1までが利用可能です。JSFの 仕様は、JSRにて規定されています（JSR 127 (JSF 1.0, 1.1), JSR 252 (JSF 1.2), JSR 314 (JSF 2.0)）。 JSFを利用することによって、JSFのカスタム・コンポーネント機能で、画面部品とロ ジックを分離しながらコンポーネント化することが可能になります。また、ページ間の 画面遷移やBeanのスコープ等を設定ファイル化できます。これによって、設計から 開発への成果物の関連性が高まり、フェーズ間の引継ぎが容易になる効果が得られ ます。JSF 2.0からはアノテーションでの指定も可能になっています。 単体ではできない（難しい）こととしては、画面がレンダリングされた後に、画面の内 容を書き換える処理や、ブラウザーにリッチなユーザーインターフェースの実現があ ります。これは、JavaScriptと組み合わせることで実現が可能になります。 7 02.フロントエンド設計 02.フロントエンド設計 【参考】 JSFの機能 (抜粋) JSF – – – – – – – JSF – – – 8 1.xの機能 タグライブラリーの提供（JSFタグ） 設定ファイルによるページ遷移の管理（ページナビゲーション） マネージドビーン ： アプリケーション起動時にインスタンス化され、容易に利用可能 • スコープが管理される カスタムコンポーネント ： カスタムタグを利用した、画面部品のコンポーネント化の方式 • コンポーネントとレンダラーを分離することで、ビューと処理を明確に分離し、分担することが可能に メッセージ ： メッセージを外部化し、国際化対応などを容易にする機能 • JSFではなくても利用できるが、より利用しやすい形で提供 バリデーター ： ユーザー入力の妥当性検証を行う機能 • 必須入力項目のチェック、値の範囲、数値、文字列等 • カスタムのバリデーターも作成可能 コンバーター ： BeanとHTMLタグの間の型変換を行う機能（BigDecimalなど） • カスタムのコンバーターを作成可能 2.xの機能 アノテーションベースの管理が利用可能になった Faceletの正式サポート 新しいスコープの提供、詳細なエラー表示など ： 設定ファイルの削減 ： カスタムコンポーネントの作成がより容易に WAS V7 アプリケーション・デザインWorkshop Part2 8 02.フロントエンド設計 02.フロントエンド設計 JavaScript ●JavaScriptによる処理イメージ 概要 – ブラウザ上で実行可能なスクリプト言語 – Javaとは完全に無関係 element.removeChild • 実行環境にJREは必要なく、ブラウザのみで 動作する メリット – HTML内で発生した各種のイベントに対す る各種処理の実行 – 動的にページの内容を書き換えることが可 能 – リッチなユーザーインターフェースの実現 document.createTextNode document.createElement 課題 – ブラウザによる仕様、動作の違いが大きい – Javaと比較して、開発、デバッグ、テストが 難しい – ブラウザーのアップデートに伴い、実行環 境が変化する 9 document.createTextNode document.createElement element.removeChild sample.html ※ この処理はページ遷移なしで実行可能 WAS V7 アプリケーション・デザインWorkshop Part2 JavaScriptは、ブラウザ上で実行可能なスクリプト言語で、言語仕様については ECMAScriptとして、DOM（Document Object Model）についてはW3Cが標準化し ています。ただし、様々な機能においては、実行環境（ブラウザ）により異なる点も多 く、クロスブラウザーへの対応を難しくする原因となっています。JavaScriptという名 前から誤解されることも多いですが、Javaとは完全に無関係で、実行環境にJREは 必要ありません。 JavaScriptはHTML内で発生した各種のイベント（ページ読み込み、ボタンのクリック、 マウスオーバーなど）に対して、処理を行うことができます。また、HTMLがレンダリン グされた後に、動的にページの内容を書き換えることができます。これによって、1 ページに収まりきらないフォームを、ダイアログなどで順番に表示させたり、検索結果 をページ遷移なしで表示させたりすることが可能になります。また、ツールチップ（吹 き出し）の表示、ドラッグアンドドロップ、ツリー表示、などのリッチなユーザーインター フェースを実現することができるようになります。 JavaScriptの持つ課題としては、上記の通り、ブラウザによる仕様、動作の違いが大 きいことが挙げられます。これに関しては、後述するJavaScript Toolkitを使うことで、 差異を吸収できます。また、 Javaと比較すると高級言語（動的スクリプト言語、緩い 型付け）であるため、開発、デバッグ、テストが難しいことも課題の一つです。言語仕 様に熟知している開発者が必要とされることになり、要員教育コストなどの課題にも 繋がります。また、ブラウザーのアップデートに伴い、実行環境が変化するため、新し いバージョンのブラウザーへのアップデートを難しくしてしまう懸念があります。 9 02.フロントエンド設計 02.フロントエンド設計 【参考】 JavaScriptの機能 (抜粋) HTMLノードの取得 – document.getElementById(${HTML要素のID属性}); HTMLノードの新規作成 – document.createElement(${HTML要素名}); 文字列の新規作成 – document.createTextNode(${文字列}); HTMLノードの追加 – element.appendChild(${HTMLノード}) HTMLノードの削除 – element.removeChild(${HTMLノード}) HTMLノードに属性を設定 – element.setAttribute(${属性名}, ${値}) HTMLノードから属性を取得 – element.getAttribute(${属性名}) 10 WAS V7 アプリケーション・デザインWorkshop Part2 10 02.フロントエンド設計 02.フロントエンド設計 Dojo Toolkit ●Dojoによる仕様の違いの吸収 概要 – JavaScriptのツールキット（ライブラリー）の1つ • その他 : jQuery, YUI, prototype.js, MooTools – Dojo Foundationが提供しているオープンソース – WASのFP Web 2.0に同梱されており、サポート対象 ユーザー アプリケーション メリット – JavaScriptをより容易に記述できる – ブラウザ間のJavaScript実装の違いを吸収できる – – – – 標準ライブラリーが非常に充実している アクセシビリティへの対応が容易 画面部品の国際化対応 画面部品のコンポーネント化の方式を提供 ユーザー アプリケーション Internet Explorer Mozilla Firefox ユーザー アプリケーション ユーザー アプリケーション DOJO DOJO Internet Explorer Mozilla Firefox ●Dojoの各モジュールの位置づけ dojox Dijit 課題 – Javaと比較して、開発、デバッグ、テストが比較的難しい – Dojo Toolkitのバージョンアップを考慮する必要がある 11 Core dojo WAS V7 アプリケーション・デザインWorkshop Part2 Dojo Toolkitは、 Dojo Foundationが提供しているオープンソースのJavaScriptの ツールキット（ライブラリー）の1つで、 IBM製品では、WASのFP Web 2.0とsMashで 提供されています。 JavaScriptのツールキットには、jQuery, YUI, prototype.js, MooToolsといったものがありますが、ここでは、IBM製品との関係性が深いDojo Toolkitを特に取り上げます。 11 02.フロントエンド設計 02.フロントエンド設計 その他のJavaScript Toolkitについて 現状、JavaScript Toolkitの中では、jQueryが一般的に最も使われている – 他の選択肢としては、 YUI, prototype.js, MooToolsなどがある Dojo Toolkit jQuery メリット 標準で豊富な機能を持っており、プラグイン要らず IBM製品が提供するので、WASをご利用の場合は IBMサポート対象 ⇒ Dojoで作成した拡張などもIBMサポート対象 デメリット 外部の情報が少なく、やや学習コストが高い IBM以外のプロジェクトの利用事例が少ない モジュールを読み込む度に、ページの初期表示が重 くなる ⇒ カスタムビルドを行うことにより、改善される（※ カスタムビルドについては後述） 共通項 12 外部の情報が多く、シンプルで容易に使える プロジェクトでの利用事例が多い プラグインという形で拡張が作りやすい IBM製品ではないため、WASをご利用の場合ではIBMサ ポートの対象外 標準で提供される機能は比較的少ないため、プラグイン を入れることがほぼ必須だが、プラグインは、個々の作者 がそれぞれのライセンスを適用した上で提供している ⇒ 個々のプラグインについて、ライセンスの確認が必要 ⇒ プラグイン間の衝突が発生する可能性がある ⇒ プラグインが原因と思われるバグや問題については、 プロジェクト側で解決する必要がある ページの初期表示に時間がかかる – Dojo Toolkitはdojo.requireを行う数によって、ロード時間がかかる（カスタムビルドでまとめることが可能） – jQueryは単体なら軽いが、プラグインを入れるので、徐々に重くなる上、プラグインをまとめることが不可能 単体テスト用のツールが提供される（Dojo ⇒ D.O.H、 jQuery ⇒ QUnit） 以降のスライドでは、Dojo Toolkitについてのみ説明する WAS V7 アプリケーション・デザインWorkshop Part2 その他のJavaScript Toolkitについてですが、現状、JavaScript Toolkitの中では、 jQueryが一般的に最も使われており、他の選択肢としては、 YUI, prototype.js, MooToolsなどがあります。本資料ではDojo Toolkitを取り扱いますが、ここに示され たメリット、デメリットを比較した上で、その他のJavaScript Toolkitの利用についても 検討しても良いと思われます。 12 02.フロントエンド設計 02.フロントエンド設計 【参考】 Dojoの機能 (抜粋) 下記のようなメソッドを利用することで、ブラウザ依存のコードを排除し、より簡素な記述が可能 – – – – – – – 加えて、画面部品を作るためのコンポーネント化の方式も提供する(dojo.declare) カレンダーによる日付入力フォーム 13 : dojo.byId(${HTML要素のID属性}); : dojo.create(${HTML要素名}); : dojo.doc.createTextNode(${文字列}); : dojo.place(${追加元HTMLノード}, ${追加先HTMLノード}); : dojo.destroy(${HTML要素のID属性, もしくはHTMLノード}); : dojo.attr(${HTMLノード}, ${属性名}, ${値}); : dojo.attr(${HTMLノード}, ${属性名}); メソッドだけではなく、下記のような画面部品を提供 (dijit, dojox) – HTMLノードの取得 HTMLノードの新規作成 文字列の新規作成 HTMLノードの追加 HTMLノードの削除 HTMLノードに属性を設定 HTMLノードから属性を取得 妥当性検査機能付きフォーム 上下左右のレイアウト作成や、タブ表示 並べ替え、編集機能を持ったテーブル また、JavaScriptの単体テストツール(D.O.H)や、JavaScript圧縮ツール(Shrinksafe)、Dojoのカスタムビルド ツール(buildscripts)なども提供 WAS V7 アプリケーション・デザインWorkshop Part2 13 02.フロントエンド設計 02.フロントエンド設計 Ajax (Asynchronous JavaScript + XML) 概要 ： ブラウザ上のJavaScript を使用した非同期通信を利用して、ユーザーエクスペリエン スの高いインターフェースを実現することを意味する概念 メリット ： レスポンスやユーザビリティーに優れたアプリケーションを構築可能 注意点 ： Ajaxを利用した処理フローの考え方など、考慮点が多くなる ●Ajaxアプリケーションと通常のWebアプリケーションの違い Ajaxアプリケーション 通常のWebアプリケーション クライアント クライアント サーバー サーバー HTML ？ JS Data#1 CSS ♪ JS HTML Data#1 CSS HTML Data#2 HTML Data#3 14 HTMLやCSSを何度も読み込む必要がある ページ遷移中は他の操作が不可能 データだけを読み込み可能で、ページ遷移は不要 バックエンド処理中にも、ユーザーは操作が可能 WAS V7 アプリケーション・デザインWorkshop Part2 Ajaxとは、ブラウザ上のJavaScript を使用した非同期通信を利用して、ユーザーエ クスペリエンスの高いインターフェースを実現することを意味する概念です。やり取り に用いるデータ形式には、JSONやXMLが良く利用されます。 通常のWebアプリケーションは、HTMLとCSSと少しのJavaScriptで構成され、ペー ジを遷移することで業務フローを実現しています。ページ遷移時にはHTMLやCSS は毎回やり取りされる必要があり、ユーザーは操作を行うことはできません。Ajaxを利 用することで、データだけを非同期に送受信できるため、レスポンスやユーザビリ ティーに優れたアプリケーションを構築することが可能になります。ただし、従来のア プリケーションとは異なる点が多く、Ajaxを利用した処理フローの考え方など、考慮 点が多くなる点に注意する必要があります。 14 02.フロントエンド設計 02.フロントエンド設計 Ajaxの注意点 - リッチクライアントとの違い Ajaxは、"JavaScriptによる非同期通信"を指す言葉で、 "JavaScriptを使ったリッチ な画面"、"ページ遷移なしでのコンテンツの大幅な切り替え"を指す言葉ではない 例 ： ドラッグアンドドロップが利用できるWebページ – ドラッグアンドドロップを実行したタイミングで、JavaScriptによってサーバーにHTTPを送信 し、DBのデータを書き換えていればAjax – ドラッグアンドドロップを実行して、最後にフォームのボタンで、ページの切り替え時に更新結 果を送信していれば、Ajaxではない ●Ajaxアプリケーションと通常のWebアプリケーションの違い 通常のWebアプリケーション DB 15 Ajaxアプリケーション DB WAS V7 アプリケーション・デザインWorkshop Part2 Ajaxでよくある誤解として、 "JavaScriptを使ったリッチな画面"があればAjax、"ペー ジ遷移なしでのコンテンツの大幅な切り替え"があればAjax、と認識されていることも 多いですが、これは誤りで、Ajaxは "JavaScriptによる非同期通信"を指す言葉です。 ただし、その結果、リッチな画面や、コンテンツの大幅な切り替えが実現されることも あります。 例として、ドラッグアンドドロップが利用できるWebページがある場合ですと、ドラッグ アンドドロップを実行したタイミングで、JavaScriptによってサーバーにHTTPを送信 し、DBのデータを書き換えていればAjaxアプリケーションと言えますが、ドラッグアン ドドロップを実行して、最後にフォームのボタンで、ページの切り替え時に更新結果 を送信しているような場合はAjaxアプリケーションとは言えません。 15 02.フロントエンド設計 02.フロントエンド設計 Feature Pack for Web 2.0 Feature Pack for Web 2.0 – WASへのWeb 2.0アプリケーショ ン関連の追加機能を提供する無 償パッケージ – 提供する機能 • Dojo Toolkit • RPCアダプター • Ajaxプロキシー • Webメッセージング • JAX-RS (WAS v6.1、7) • JSONライブラリー – 対応するWAS • WAS v6.0.2、v6.1、v7 – 詳細は以下のURLを参照 • http://www01.ibm.com/software/webserver s/appserv/was/featurepacks/we b20/index.html 16 FP Web 2.0の機能 ブラウザー Dojo Toolkit JSON/XML Atom FP Web2.0 JAX-RS POJO Ajax プロキシー 既存 クラス 外部Webサービス 外部Webサービス Web メッセー ジング RPC アダプター Feed Sphere JSON4J SIBus WAS V7 アプリケーション・デザインWorkshop Part2 Feature Packは、IBMが提供するWASへの追加機能を含む各種のパッケージです。 Feature Pack for Web 2.0では、Web 2.0アプリケーションを作成するための様々な 機能が提供されます。先述したDojo Toolkitも、この中に含まれています。 対応するWASのバージョンは上記の通りですが、JAX-RSはJava EE 5のアノテー ションを利用しているため、WAS v6.0では利用できませんのでご注意下さい。 16 02.フロントエンド設計 02.フロントエンド設計 RESTful Webサービス 概要 – REST※に基づいたWebサービスの方式の1つ – RESTful Webサービス自身は、実装が規定されているものではない メリット – クライアントを限定しない、汎用的なWebサービスを作成可能 – JavaScriptと組み合わせることで、Ajaxを実現できる ●特定の言語によらないシステム間連携 Java .NET Excel VBA HTTP RESTful Webサービス ●JavaScript Toolkitの機能の活用 JavaScript Toolkit RESTful Webサービス JavaScript 注意点 – エンタープライズ領域では先進的な技術であるため、リファレンスが少ない – 実装が規定されていないため、各利用者が設計を行う必要がある ※REST : Representative State Transfer 17 WAS V7 アプリケーション・デザインWorkshop Part2 RESTful Webサービスは、REST(Representative State Transfer)に基づいた Webサービスの方式の1つです。RESTful Webサービス自身は、実装が規定されて いるものではなく、方式を示す言葉です。この実装の1つに、後述するJAX-RSがあり ます。 RESTful Webサービスを利用することで、クライアントを限定しない、汎用的なWeb サービスを作成することが可能になります。HTTPライブラリーがあればどの言語でも 呼び出しが可能ですので、JavaScriptやJava、.NET、Excel VBAなど、様々な利用 形態が考えられます。また、JavaScriptと組み合わせることで、Ajaxを実現することが できます。JavaScript Toolkitとの連携により、リッチなユーザーインターフェースを実 現することが可能になります。 RESTful Webサービスを利用する場合の注意点としては、パブリックのインターネッ ト上のサービスではREST形式でサービスを提供しているところも多いですが、エン タープライズ領域では先進的な技術であるため、リファレンスが少ない点が挙げられ ます。また、実装が規定されていないため、実装がそれぞれの設計者によって異 なってしまうという点が課題ですが、Java EEにおいては、次に説明するJAX-RSを 利用することで、設計をより容易に進めることができます。 17 02.フロントエンド設計 02.フロントエンド設計 JAX-RS (Java API for RESTful Web Services) 概要 ●JAX-RSによる処理概要 – RESTful WebサービスをJavaによっ て実現するための仕様 RestServlet @Path("/books") HTTP GET メリット – RESTful Webサービスのクラス設計 が為されており、個々に設計の必要が ない – HTTPパラメータやURLを容易に処理 し、Javaのオブジェクトとして利用する ことが可能 XML, JSON HTTP GET XML, JSON – エンタープライズ領域では先進的な技 術であるため、リファレンスが少ない XML, JSON @POST HTTP PUT @PUT HTTP DELETE XML, JSON ：クラス 18 @GET HTTP POST XML, JSON 注意点 @GET @Path("/{id}") @DELETE ：メソッド WAS V7 アプリケーション・デザインWorkshop Part2 JAX-RS (Java API for RESTful Web Services)は、JSR 311 (JAX-RS 1.0, 1.1) にて規定されているRESTful WebサービスのJavaにおける実装を規定したもので、 Java EE 6に含まれる仕様です。JavaDocが提供されており、Apache Winkなどの 参照実装が存在します。WASのFP Web 2.0 1.0.1 では1.0が利用可能です。 JAX-RSでは、HTTPを直接操作することなく、抽象化されたAPIによって、RESTful Webサービスを容易に作成可能です。Java EEでREST形式のサービスを作成する 場合は、通常JAX-RSを利用することになると思われます。JAX-RSを採用する場合 の注意点としては、RESTful Webサービスと同様、エンタープライズ領域では先進 的な技術であるため、リファレンスが少ない点があります。 18 02.フロントエンド設計 02.フロントエンド設計 アーキテクチャー・デシジョン 19 WAS V7 アプリケーション・デザインWorkshop Part2 19 02.フロントエンド設計 02.フロントエンド設計 アーキテクチャー・デシジョン項目 提案フェーズ – Ajax・リッチクライアントを採用するか？ ソリューション・アウトラインフェーズ – Ajaxを採用する場合、利用パターンをどうするか？ • フロントエンド-バックエンドの連携方式 – Ajaxの実装方式は何か？ • サーバー側 ： JAX-RS, 自作Servlet, RPCアダプター • クライアント側 ： Dojo XHR、XMLHttpRequest – どのフロントエンド技術を採用するか？ • JSP、フレームワーク 、Dojo Toolkit • フレームワーク選定 – JSF、Struts、Spring MVC 20 WAS V7 アプリケーション・デザインWorkshop Part2 フロントエンドの設計に関するアーキテクチャー・デシジョンの項目としては、これらの 点が挙げられます。以降のページでは、これらについて説明していきます。 20 02.フロントエンド設計 02.フロントエンド設計 アーキテクチャー・デシジョン ～Ajax・リッチクライアントを採用するか？ （概要セッション 103. UIで採用するアーキテクチャーの検討） 21 WAS V7 アプリケーション・デザインWorkshop Part2 21 103. UIで採用するアーキテクチャーの検討 02.フロントエンド設計 02.フロントエンド設計 Ajax・リッチクライアントの採用 - 画面遷移の変化 下記のような処理フローを利用することができる – 検索結果を利用して、何らかの情報を登録するアプリケーションの場合 – ：ページ内切り替え ：ページ遷移 ●一般的なWebアプリケーションの処理フロー 旅行情報検索 検索結果 旅行予約 予約確認 実行結果 検索結果 旅行予約 予約確認 実行結果 ページ遷移なしで 検索結果を表示 ページ遷移なしで ダイアログ表示 ダイアログ内 のみ切り替え 成功時にのみ ページ移動 ●Ajaxを全面的に利用した処理フロー 旅行情報検索 22 WAS V7 アプリケーション・デザインWorkshop Part2 Ajaxとリッチクライアントを採用することによって、画面遷移のパターンが変化します。 Ajaxを利用することで、データベースからのデータをJavaScriptで取得できるため、 ページを切り替えることなく、業務フローを実現することができるようになります。 一般的なWebアプリケーションでは、情報を検索すると、ページが切り替わって検索 結果がテーブルなどで表示されますが、Ajaxの場合は、ページ遷移なしで、 JavaScriptのグリッド内にデータを表示させることができます。 登録処理においても、フォームが多すぎる場合や一旦サーバーでの確認処理が必 要な場合などは、通常、次の入力画面や確認画面を用意しますが、リッチクライアン トを利用することで、フォームをダイアログ内に表示し、ウィザードのようにダイアログ を切り替えて複数のフォームを同一ページ内に持ったり、サーバーでの確認を行うこ とができます。この場合、ページが切り替わらないため、"戻る"ボタンの対応として、 セッションにデータを書き込んでおく必要がなくなります。 登録の成否判断についても、サーバーでしか判定できない場合もありますが、これも 成功時にのみページ移動し、失敗時にはフォームデータを失わずに、ウィザードを 戻ることができます。また、JavaScriptでデータを送信しているため、"戻る"ボタンを 押した場合でも、ブラウザーでHTTP POSTを送信した場合に表示される再実行の 確認が表示されず、再実行の懸念がなくなります。 22 103. UIで採用するアーキテクチャーの検討 02.フロントエンド設計 02.フロントエンド設計 Ajax・リッチクライアントの採用 - メリット・デメリット メリット – – – – エンドユーザーに対して、ページ遷移時の真っ白な画面を見せなくて良くなる 戻るボタンによる再実行防止への対応を作らなくて良くなる タイムアウト処理を記述しなければならないフローが減る データのみのやり取りだけで良くなり、通信量が減る デメリット – 設計者、開発者は画面設計を行う際に、JavaScriptでできること・できないことを知らなけれ ばならない – JavaScriptは一般的に開発生産性が低く、単体テストの自動化が困難 ●一般的なWebアプリケーションにおける考慮点 検索結果 旅行予約 フォーム 再埋込 23 予約確認 別のページ 実行結果 再実行 戻る WAS V7 アプリケーション・デザインWorkshop Part2 前ページで説明した、Ajaxを採用することによって、従来のWebアプリケーションか ら変化する点についてのメリット・デメリットのまとめです。 23 103. UIで採用するアーキテクチャーの検討 02.フロントエンド設計 02.フロントエンド設計 Ajax・リッチクライアントの採用 - 注意点 画面設計を行う際に、何ができて、何ができないのか知らなければならない – ブラウザ上のJavaScriptでは実現不可能な要件がある – 例） 複数ファイルの一括選択によるアップロードなど "1画面＝1HTMLファイル"ではなくなることに注意する – 画面遷移図や、それ以外の設計成果物について影響がある（後述） • • 1ページ内の表示の切り替えによって、複数画面を実現することになる 例） タブの切り替え、ウィザード形式での処理フロー など – ページ遷移が減るため、ページ遷移管理機能や、セッションの重要性は低下 ブラウザーのJavaScriptレンダリング能力や開発サポート機能に注意する – IE 6は、その他ブラウザーよりもレンダリング能力が非常に低い – IE 6,7は開発者ツールがデフォルトで提供されず、IE 8でも機能が不足している 24 WAS V7 アプリケーション・デザインWorkshop Part2 Ajax・リッチクライアントを採用する際の注意点としては、まず、画面設計を行う際に、 ブラウザ上のJavaScriptでは実現可能/不可能な要件についての知識が必要となる 点があります。例を以下に挙げます（一部の先進的なブラウザーや、デフォルトから セキュリティ・ポリシーの変更を行ったブラウザーを除く）。 •複数ファイル、ディレクトリーの一括選択によるアップロード •ローカルファイルの読み込み •ファイルの出力処理（JavaScriptによるファイル受信） •ブラウザー外のアプリケーションに対する各種の処理 •クリップボードの読み込み・書き込み操作 これら以外にも可能・不可能の判断が難しい要件があるため、ある程度JavaScript やリッチクライアントに詳しい担当者がいることが望ましいと思われます。 "1画面＝1HTMLファイル"ではなくなることも注意点の一つです。画面遷移図の画面 数が、作成するページ数と大きく異なることになります。一方、ページ遷移が減るため に、ページ遷移管理機能や、セッションの重要性が低下するので、Javaフレーム ワークを採用しなくても良い場合も出てくることもあります。 ブラウザーが実行環境であるため、ブラウザーの処理速度や、開発ツールのサポー トの有無が重要になりますが、IEではこの点に注意する必要があります。 24 103. UIで採用するアーキテクチャーの検討 02.フロントエンド設計 02.フロントエンド設計 Ajax・リッチクライアントの採用 - 注意点 Ajax処理に関するエラーハンドリング、エラー表示方式に関して考慮が必要 – ページ遷移の際以外にもAjax通信でエラーが発生する可能性がある – 様々な表示方法が考えられるが、共通の方式を検討しておく必要がある • ユーザーエクスペリエンスを高めるため、エラーページ遷移はなるべく避ける ●通常のWebアプリケーションの エラー処理 ●AjaxアプリケーションのAjaxのエラー処理 エラー 発生 検索画面 エラー 発生 エラーページ JavaScriptで エラーページ遷移 25 ダイアログ 表示 メッセージ 領域に表示 WAS V7 アプリケーション・デザインWorkshop Part2 また、Ajax処理に関するエラーハンドリング、エラー表示方式に関しては、ページ遷 移以外でもバックエンドでサーバー通信を行うことがあるため、画面内に確保してお いたメッセージ表示域か、ポップアップダイアログによってエラー表示を行うなど、事 前に検討しておく必要があります。 25 103. UIで採用するアーキテクチャーの検討 02.フロントエンド設計 02.フロントエンド設計 【参考】 Ajax・リッチクライアントの採用 - 注意点 Ajaxを採用しない場合でも、DojoのリッチなGUIパーツのみを利用することも 可能 – サーバー側の処理によって、HTML内にデータの実体を書き出すことで、データ ベース内のデータと連携するパーツも利用可能 ブラウザでアクセス データを以下のような形式で 埋め込んだHTMLを返す HTML DBからデータを取得 データ Web App Server DB <script type="text/javascript"> var employee = {"identifier" : "id", "label" : "name", "items" : [ {"id":1, "name": "Takahashi"}, ... ]}; </script> <span dojoType="dojo.data.ItemFileReadStore" data="employee" > JSONの文字コードはUTF-8である必要がある 26 WAS V7 アプリケーション・デザインWorkshop Part2 Ajax・リッチクライアントを採用する際の注意点の続きです。よくある誤解の一つです が、Ajaxを採用しない場合でも、DojoのリッチなGUIパーツのみを利用することも可 能です。サーバー処理が関係しないパーツはもちろん、サーバー側の処理によって、 HTML内にデータの実体を書き出すことで、データベース内のデータと連携する パーツも利用可能になります。ただし、データのリフレッシュなどはサーバーサイド （ページリロード）で行わなければならないので、注意が必要です。 また、Ajax通信で主に用いられるJSONは、文字コードがUTF-8であることが仕様と して決まっています。これに関して、可能であればシステム全体もUTF-8化しておい た方が後々の課題が減ると思われますので、検討を行うことを推奨します。 26 103. UIで採用するアーキテクチャーの検討 02.フロントエンド設計 02.フロントエンド設計 Ajax・リッチクライアントの採用 - まとめ Ajaxを採用することで、下記のようなメリットが得られる – エンドユーザーの満足度の向上 • 画面遷移の減少、非同期処理によるユーザーの操作を妨げないUI – システムの簡素化 • 画面遷移の減少によるセッション利用の減少、タイムアウト対応の簡素化、ブラウザ バック対応の考慮が不要、サーバーとの通信量の減少 採用する場合、以下の点に注意する必要がある – JavaScriptで可能な処理、不可能な処理に関する知識が必要 – JavaScriptの開発生産性、単体テストの自動化などに関する問題 – 従来の設計成果物からの変化 • 画面遷移図、画面の詳細設計 – ブラウザーに関する配慮 – エラーハンドリングの方法 – 文字コード 27 WAS V7 アプリケーション・デザインWorkshop Part2 Ajax・リッチクライアントの採用に関するまとめのページです。 27 02.フロントエンド設計 02.フロントエンド設計 アーキテクチャー・デシジョン ～ Ajaxを採用する場合、利用パターンをどうするか？ 検討項目 202. Ajax利用パターンの検討 ／ プレゼンテーション層 検討内容 Ajaxを利用する場合、データ変換／画面表示管理の様な項目をAjax側で実装するのか、サーバー側モジュールで 実装するのかを検討する。 ①Ajax側だけで実装する ②サーバー側モジュールでも実装する この選択により各コンポーネントの役割分担が変わる。また、フレームワークの選択に影響を及ぼすケースもある。 28 WAS V7 アプリケーション・デザインWorkshop Part2 28 202. Ajax利用パターンの検討 02.フロントエンド設計 02.フロントエンド設計 Ajaxの利用パターン Ajaxを利用する事が決まった場合、利用パターンを決定する必 要がある 1. ページ遷移を全く行わない"完全なAjaxアプリケーション"か、一部の ページにAjaxを提供する"部分的なAjaxアプリケーション"か – ただし、初期表示の画面は1つだけでなくてもよい（タブやツリーなどの選択 状態の復元など） 2. データの表示フォーマット変換について、サーバーとクライアントの役割 分担を決定する必要がある – 表示フォーマット変換 : 元データからHTMLのハイパーリンクやボタン、テー ブルなどに変換する処理 29 WAS V7 アプリケーション・デザインWorkshop Part2 Ajaxを利用することが決まった場合、その利用パターンについて検討する必要があ ります。 1つは、ページ遷移の有無についてです。Ajaxとリッチクライアントの機能を利用する ことで、ページ遷移を全く行わないアプリケーションを作ることも可能になります。 もう1つは、サーバーとクライアントでのインターフェースについてです。サーバーが、 クライアントでの表示形式を意識したデータを返すか否かが重要な点になります。 29 202. Ajax利用パターンの検討 02.フロントエンド設計 02.フロントエンド設計 Ajaxの利用パターン - ページ遷移の有無 Ajaxを利用した場合、ページ遷移を完全になくすことが可能 – どこまでAjax化するかについて、決定が必要 1. ページ遷移を全く行わない"完全なAjaxアプリケーション" 2. 一部のページにAjaxを提供する"部分的なAjaxアプリケーション" – – – ユーザーエクスペリエンスは非常に高くできるが、構築は困難なため、考慮が必要 業務フローとして完結する単位などでAjaxアプリケーション化し、個々はページ遷移で繋ぐ ユーザーエクスペリエンスはそれほど低下しないが、ページ遷移とJavaScriptによる切り替 えを区別しながら設計を進める必要がある どちらの場合も、長時間処理がある場合は、状態保持についての考慮が必要（後述） ●Ajaxにおけるページ遷移の利用箇所の検討 トップメニュー 30 旅行情報検索 検索結果 旅行予約 予約確認 実行結果 WAS V7 アプリケーション・デザインWorkshop Part2 Ajaxとリッチクライアントの機能を利用することで、ページ遷移を全く行わないアプリ ケーションを作ることも可能になります。ただし、全てのビジネスロジックはJavaScript で記述することになるため、Javaフレームワークの機能などによる開発生産性の向上 などのメリットを得られず、Javaのクラスベースのオブジェクト指向による分業のやり やすさなどのメリットなどを得ることができないなど、考慮点は多くなります。 そうした要件がない場合には、一部のページをAjax化し、それらをページ遷移で繋 ぐ方式を利用することになります。ユーザーエクスペリエンスはそれほど低下しません が、ページ遷移とJavaScriptによる切り替えを区別しながら設計を進める必要がある ため、注意が必要です。主に、業務として完結する単位ではページ遷移なしで完結 するようにすると、Ajaxの恩恵を得やすいと思われます。 30 202. Ajax利用パターンの検討 02.フロントエンド設計 02.フロントエンド設計 Ajaxの利用パターン - データの表示フォーマット変換 主に以下の２つのパターンが挙げられる – ① : View側を考慮したデータを返すRESTful Webサービスを作成する • JavaScriptは、受信したデータを表示させる処理だけを記述するために利用 • スキルや開発生産性等の考慮点が減るが、RESTful Webサービスの再利 用性が低い – ② : データのみを返すRESTful Webサービスを作成する • JavaScriptによって、受信したデータの加工を行い、表示用の調整を行う • RESTful Webサービスの再利用性は高いが、要員のスキルや開発生産性 の低さについての考慮が必要 上記パターンの層分割の図 プレゼンテーション層 ① Ajax（Dojo） Ajax（Dojo） ② 31 ビジネス層 RESTful RESTful Webサービス Webサービス Ajax（Dojo） Ajax（Dojo） インテグレーション層 SOAP SOAP Webサービス, Webサービス, JDBC, JDBC, O/Rマッパー O/Rマッパー RESTful RESTful Webサービス Webサービス SOAP SOAP Webサービス Webサービス JDBC, JDBC, O/Rマッパー O/Rマッパー WAS V7 アプリケーション・デザインWorkshop Part2 サーバーとクライアントでのインターフェースについては、①View側を考慮したデータを返 すRESTful Webサービスを作成する方式と、②データのみを返すRESTful Webサービスを作成する 方式があります。 ①では、JavaScriptは、受信したデータを表示させる処理だけを記述するために利用 します。JavaScriptの開発が少なくなるので、スキルや開発生産性の低さなどの考慮 点が減ることになりますが、RESTful Webサービスの再利用性は低くなり、ほとんど の場合、自システムでのみ利用することになると思われます。そのため、データのみを 返すデータアクセス用コンポーネントは、別途切り出す必要があります。 ②では、JavaScriptによって、受信したデータの加工を行い、表示用の調整を行うこと になります。この場合、他システムとの連携を行うインターフェースとしてRESTful Webサービスを再利用することが可能ですが、JavaScriptでの開発が増えるため、 要員のスキルや開発生産性の低さについての考慮が必要となります。 31 02.フロントエンド設計 02.フロントエンド設計 アーキテクチャー・デシジョン ～ Ajaxの実装方式は何か？ 検討項目 203. REST実装方式の検討 ／ プレゼンテーション層 検討内容 AjaxはRESTで処理を行う。その処理を受け付けるサーバー側モジュールの実装方式を検討する。 ①JAX-RS ②Servletを利用 ③RPCアダプター 通常のケースでは、①JAX-RSを採用する。既存モジュールをそのまま利用したい等の特別な理由がある場合は、他 の方法を選択する。 32 WAS V7 アプリケーション・デザインWorkshop Part2 32 203. REST実装方式の検討 02.フロントエンド設計 02.フロントエンド設計 Ajaxの実装方式 - サーバー RESTful Webサービスのプロバイダーをどのように実装するか – – 1. JAX-RS – – 2. – 33 JSRにて規定されており、クラス設計を行う必要がなく、ライブラリーを導入するのみで良い WAS v7の場合は、Feature Pack for Web 2.0 v1.0.1を導入する必要がある 通常のServlet – 3. 基本的には、HTTPリクエストを受け付けて、JSONやXMLを返すことができれば良い ただし、インターオペラビリティーなどの観点での採用基準は存在する 通常のServletを用いて、そのレスポンスをJSONやXMLにすれば、RESTful Webサービス と言える 特にライブラリーを入れなくても良い点がメリットだが、実装はやや困難 RPCアダプター – WASのFeature Pack for Web 2.0によって提供される機能で、JavaBeansにHTTPのイン ターフェースを作成するための機能（RESTではなく、RPC形式の呼び出し） – – 様々な制約があるため、既存のクラスに適用する場合は制約条件を満たすか確認が必要 新規のクラスを作成する場合で、RPCアダプターを利用するメリットはあまりないと思われ る WAS V7 アプリケーション・デザインWorkshop Part2 Ajaxを採用する場合は、Ajaxを実現するための実現方法の選定を行う必要がありま す。まず、RESTful Webサービスのプロバイダーをどのように実装するか、ですが、 基本的には、HTTPリクエストを受け付けて、JSONやXMLを返すことができれば良 いので、特殊な方式がなくても、普通のServletで実装が可能です。ただし、インター オペラビリティーなどの観点で採用基準が存在します。 JAX-RSは既に説明したとおり、JSRにて規定されており、クラス設計を行う必要がな く、ライブラリーを導入するのみで良い点がメリットです。パス変数やクエリ変数、 HTTPヘッダーなどによってメソッドを振り分けるためのクラスなどが用意されていま す。WAS v7の場合は、Feature Pack for Web 2.0 v1.0.1を導入することで利用す ることが可能になります。 Feature Pack for Web 2.0 v1.0.1の導入が難しい場合は、通常のServletで代用す ることも可能です。通常のServletを用いて、そのレスポンスをJSONやXMLにすれば、 RESTful Webサービスと言えます。この場合、HTTPパラメータは、Servletの HttpServletRequestオブジェクトから取得することになります。特にライブラリーを入 れなくても良い点がメリットですが、抽象化されていないため、実装はやや困難と言 えます。 RPCアダプターはWASのFeature Pack for Web 2.0によって提供される機能で、 JavaBeansにHTTPのインターフェースを作成するための機能です。厳密には RESTとは言えず、RPC形式の呼び出しとなります。この利用には、Bean側に様々 な制約があるため、既存のクラスに適用する場合は制約条件を満たすか確認が必要 です。新規のクラスを作成する場合は、RPCアダプターを利用するメリットはあまりな いと思われます。 33 203. REST実装方式の検討 02.フロントエンド設計 02.フロントエンド設計 Ajaxの実装方式 - クライアント RESTful Webサービスのリクエスターをどのように実装するか – 基本的には、HTTPを送信できればリクエスターになれるが、RESTful Webサー ビスのリクエストを送るために設計されたライブラリーを利用すると、開発の際に 非常に便利 • ライブラリーの管理などの問題で、標準のAPIを利用するパターンもある 1. Dojo XHR (XMLHttpRequest) – Dojoが提供するAPI。Ajaxコールをキャッシュされないようにする機能や、JSON やXMLをパースしてJavaScriptのオブジェクトに変換する機能など、便利な機能 が提供されている 2. XMLHttpRequest – JavaScriptの（実質的な）標準APIで、HTTPリクエストを送信することができる （XML以外も送信できる） – Internet Explorer 6ではサポートされておらず、ActiveXがOnの状況でしか利用 できない 34 WAS V7 アプリケーション・デザインWorkshop Part2 次に、 RESTful Webサービスのリクエスターについてです。基本的にはHTTPを送 信できれば利用は可能ですが、RESTful Webサービスのリクエストを送るために設 計されたライブラリーを利用すると、開発の際に非常に便利です。 Dojoを採用している場合は、Dojoのdojo.xhrを利用すると様々な機能が提供されて おり、便利です。一方、JavaScriptにもXMLHttpRequestというAPIがありますが、 Internet Explorer 6ではサポートされておらず、ActiveXがOnの状況でしか利用でき ないなど、一部のシステムでは考慮が必要です。 34 203. REST実装方式の検討 02.フロントエンド設計 02.フロントエンド設計 Ajaxの実装方式 - 注意点 ブラウザー上のJavaScriptにはSame origin policyの制約があるため、ドメインが分 かれる場合などは注意する Feature Pack for Web 2.0 では、この問題を解決するためのAjaxプロキシー機能が 提供されている – Same originを判定する対象 ： ホスト名、ドメイン名、プロトコル、ポート番号 – リバース・プロキシーによって、同一のorigin内から、Webサービスを提供するURLへとリク エストを送り、結果を返す機能 http://www.example.com/work/hoge.html http://www.example.com/ index.html https://www.example.com/ http://www.example.com:8080/ http://app.example.com/ http://www.example.co.jp/ 35 ○ × × × × port: 80 port: 443 port: 8080 WAS V7 アプリケーション・デザインWorkshop Part2 Ajaxでは、JavaScriptからHTTPを送信することになりますが、ブラウザー上の JavaScriptにはSame origin policyの制約があるため、ドメインが分かれる場合など は注意する必要があります。 35 203. REST実装方式の検討 02.フロントエンド設計 02.フロントエンド設計 Ajaxの実装方式 - 注意点 Java/JavaScriptオブジェクトを渡すことは基本的にできない – 基本方針として、HTTPで送信可能なデータ形式のみを送ることを推奨 • テキストや、バイナリのストリーム – Java → JavaScript • JavaからはJSON4JによってJSON形式の文字列に変換してレスポンスを返す • JavaScriptではevalを行うことでJavaScriptオブジェクトに変換 – JavaScript → Java • JavaScriptからは、JSON形式の文字列を送信 • JavaではJSON4Jでオブジェクトに変換 ブラウザー（Dojo Toolkit） dojo.toJson, dojo.formToJson アプリケーション・サーバー JSON/HTTP JSON4J JavaScript オブジェクト dojo.fromJson, dojo.xhr 36 Java オブジェクト JSON/HTTP JSON4J WAS V7 アプリケーション・デザインWorkshop Part2 Webサービスは下位プロトコルにHTTPを利用するため、オブジェクトそのものを直 接渡すことはできません。 JavaScriptでは、JSONを表す文字列を受け取り、JavaScript側ではevalを行うこと で、オブジェクトへのシリアライズを行うことができるようになります。Dojoでは、 dojo.fromJson関数が用意されています。また、dojo.xhrのレスポンスがJSONの場 合は、handleAsプロパティーに"json"を指定することで、オブジェクトとして受け取る ことが可能です。また、dojo.toJsonを利用することで、JavaScriptオブジェクトを JSON形式の文字列に変換することが可能です。また、dojo.formToJsonでフォーム の値をJSONとして送信可能です。 JavaでJSON文字列を作成するには、JSON4Jを利用することで可能です。また、逆 にJSON形式の文字列をJavaオブジェクトにシリアライズすることも可能です。 36 02.フロントエンド設計 02.フロントエンド設計 アーキテクチャー・デシジョン ～どのフロントエンド技術を採用するか？ 検討項目 204. プレゼンテーション層の実装技術を検討 ／ プレゼンテーション層 検討内容 プレゼンテーション層の実装技術の検討を行う。201. Ajax ツールの検討 でDojo以外を選択した場合は、選択肢③ がそのツールに変わる。 ①フレームワーク（ Struts ／ Spring MVC ／ JSF） ②JSP ③Dojo これらの実装技術は択一ではなく、組みあせて使用する事が可能。コンポーネント化などの開発効率を考慮して検討 する。①フレームワークの種類は択一なので、どのフレームワークを使用するか選択する必要がある。選択したフ レームワークによっては、使用できるDIコンテナー・フレームワークに制約がある可能性がある。 37 WAS V7 アプリケーション・デザインWorkshop Part2 37 204. プレゼンテーション層の実装技術を検討 02.フロントエンド設計 02.フロントエンド設計 フロントエンド技術要素の組み合わせ 検討項目 – 機能要件 • ページデザインのテンプレート化 – ページデザインのヘッダー部やフッ ター部、左右ペイン、コンテンツ部な どの分離が容易か • 画面部品のコンポーネント化 – コンテンツ部の中身の表やフォーム 部品などを分離することが可能か • ページ遷移のコントロール – ページ遷移の制御を、コードや HTMLから分離することが可能か • Javaオブジェクトとの連携 – Javaオブジェクトのインスタンスとの 連携が可能か • Javaオブジェクトのスコープ管理 – 画面表示に利用されるJavaオブジェ クトについて、スコープ管理されるか • バリデーションチェック – バリデーションチェックを行う仕組み が提供されるか 38 – 非機能要件 • リッチなユーザーエクスペリエンス – リッチなユーザーインターフェースを実現 することが容易か • アプリケーションの互換性、保守容易性 – アプリケーションのバージョンアップや、メ ンテナンス性の高さ • 開発容易性、要員育成の容易性 – 開発ツールなどや言語仕様など、開発の 生産性は高いか – 開発メンバーにスキルが必要か • 大量の画面の開発生産性 – 画面数が多く、開発規模が大きい場合に 生産性が向上するか（低下しづらいか） • Java EE以外でのコンポーネントの再利用 – Java EE以外で、システムの再利用性が 高いか WAS V7 アプリケーション・デザインWorkshop Part2 フロントエンド技術の選定は、最も重要なデシジョン項目の一つです。本資料では、 これらの要件について比較検討します。 38 204. プレゼンテーション層の実装技術を検討 02.フロントエンド設計 02.フロントエンド設計 フロントエンド技術要素の組み合わせ どのようなパターンが存在するのか – JSPのみ利用 • HTML内にはJavaScriptはほとんど存在せず、リンクは固定で記述されている • 画面パーツはカスタムタグによって共通化し、フォームのバリデーションは手作り – JSP+フレームワーク • 設定ファイル/アノテーションベースでページ遷移が管理されており、外部化されている • フォームのバリデーションも外部化されている – JSP+Dojo • タブ等で画面切り替えが実現されており、リンクは固定だが、ページ遷移自体が少ない • フォームの送信はAjaxかHTMLのフォームのどちらかで、バリデーションは手作り – JSP+フレームワーク+Dojo • タブ等で画面切り替えが実現されており、ページ遷移がある場合も外部化されている • フォームの送信はAjaxかHTMLのフォームのどちらかで、バリデーションも外部化 39 WAS V7 アプリケーション・デザインWorkshop Part2 本資料では、これらの組み合わせについて、前ページの要件から比較検討します。 39 204. プレゼンテーション層の実装技術を検討 02.フロントエンド設計 02.フロントエンド設計 フロントエンド技術要素の組み合わせ - 比較 機能要件による比較 JSP JSP+フレームワーク JSP+Dojo JSP+フレームワーク +Dojo ページデザインの テンプレート化 ○ ○ ○ ○ 画面部品の コンポーネント化 ○ ○ ○ ○ ページ遷移の コントロール × ○ × ○ Javaオブジェクトとの 連携 ○ ○ ○ ○ Javaオブジェクトの スコープ管理 × ○ × ○ バリデーション チェック △ ○ △ ○ 40 WAS V7 アプリケーション・デザインWorkshop Part2 機能要件による比較結果です。 40 204. プレゼンテーション層の実装技術を検討 02.フロントエンド設計 02.フロントエンド設計 【参考】 機能要件を実現する技術要素 JSP JSP+フレームワーク JSP+Dojo JSP+フレームワーク +Dojo ページデザインの テンプレート化 JSP include JSP include JSP include ContentPane JSP include ContentPane 画面部品の コンポーネント化 カスタムタグ カスタムタグ カスタムコンポーネント (JSF) カスタムタグ カスタムコンポーネン ト(Dojo) カスタムタグ カスタムコンポーネント (JSF、Dojo) ページ遷移の コントロール 固定 設定ファイル アノテーション 固定 固定 設定ファイル アノテーション Javaオブジェクトとの 連携 タグ、JSP式、EL タグ、JSP式、EL、 ManagedBean(JSF) タグ、JSP式、EL タグ、JSP式、EL、 ManagedBean(JSF) Javaオブジェクトの スコープ管理 なし 設定ファイル アノテーション なし 設定ファイル アノテーション バリデーション チェック 手作り 設定ファイル アノテーション 手作り 設定ファイル アノテーション 41 WAS V7 アプリケーション・デザインWorkshop Part2 前ページの機能要件を実現する技術要素です。 41 204. プレゼンテーション層の実装技術を検討 02.フロントエンド設計 02.フロントエンド設計 【参考】 機能要件に関するマークの理由説明 ページデザインのテンプレート化 – JSPの機能でできるため、ほとんど大きな差はつかない – DojoのContentPaneのhref要素を利用しても同様のことが実現が可能だが、JSPがある場 合は、こちらを採用するメリットはない 画面部品のコンポーネント化 – JSFではカスタムコンポーネントが作れるが、JSF1では作成が困難なため、メリットは少ない – カスタムタグとDojoについては後述するが、利用パターンが異なるので単純比較はできない ページ遷移のコントロール – フレームワークを利用する大きなメリットの一つ – Ajaxアプリケーションの場合は、ページ遷移が少なくなるため、このメリットは小さくなる Javaオブジェクトとの連携 Javaオブジェクトのスコープ管理 – 基本的に、JSPの機能で連携ができるため、差はつかない – フレームワークを利用する大きなメリットの一つ – Ajaxアプリケーションの場合は、セッション利用が少なくなるため、このメリットは小さくなる バリデーションチェック – フレームワークで機能が提供されることが多いが、手作りしてもそれほど大変ではない 42 WAS V7 アプリケーション・デザインWorkshop Part2 前々ページの評価についての説明です。 42 204. プレゼンテーション層の実装技術を検討 02.フロントエンド設計 02.フロントエンド設計 フロントエンド技術要素の組み合わせ 非機能要件による比較 JSP JSP+フレーム ワーク JSP+Dojo JSP+フレームワーク +Dojo リッチなユーザーエクス ペリエンス × × ○ ○ アプリケーションの 互換性、保守容易性 ○ △ ▲ × 開発容易性、 要員育成の容易性 ○ △ ▲ × 大量の画面の 開発生産性 × ○ △ ○ Java EE以外での コンポーネントの再利用 × × ○ ○ (Dojo部分) ※ 評価の順序は ○ > △ > ▲ > × の順。 43 WAS V7 アプリケーション・デザインWorkshop Part2 非機能要件による比較結果です。 43 204. プレゼンテーション層の実装技術を検討 02.フロントエンド設計 02.フロントエンド設計 【参考】 非機能要件に関するマークの理由説明 アプリケーションの互換性、保守容易性 – 一般には技術要素がベーシックな機能であればあるほど、互換性は高くなる – フレームワークはJava EE標準か否かにもよるが、一般的に後方互換性が取られる – Dojoは実行環境（ブラウザ）の変化もあるため、完全な互換性の維持は難しい 開発容易性、要員育成の容易性 – 一般的には、Javaは言語仕様からして、ツールのサポートが行いやすい構造であり、普及度 も高い – Java EEのフレームワークは利用経験者も多く、技術情報もインターネットから得やすい – Dojoは開発ツールのサポートがあまり豊富ではなく、経験者や日本語の技術情報も少ない 大量の画面の開発生産性 – 画面数が多ければ多いほど、設定ベースであるフレームワークが有利で、生産性が高い – Dojoを利用することで、画面をタブやリッチなUIパーツで統合でき、大量ページの管理コスト が下がる Java EE以外でのコンポーネントの再利用 – JSPのカスタムタグなどはJava EEベースの技術であるため、基本的に再利用は不可能 – Dojoはブラウザーが実行環境になるため、Webアプリケーションであれば再利用が可能 44 WAS V7 アプリケーション・デザインWorkshop Part2 前ページの評価についての説明です。 44 204. プレゼンテーション層の実装技術を検討 02.フロントエンド設計 02.フロントエンド設計 技術要素の採用の方針 フローチャート 画面数が非常に多く（50-100以上） 、かつ画面遷移が複雑か？ / Ajax、もしくはリッチクライアント要件があるか？ No/No Yes/No No/Yes Yes/Yes 今後の拡張性が 重視されるか？ 次のうち、 どれを優先するか？ No ユーザー満足度 拡張性 コスト 次のうち、 どれを優先するか？ コスト 迅速性 JSPのみ 45 Yes ユーザー満足度 拡張性 拡張性 ユーザー満足度 JSP+フレームワーク JSP+Dojo JSP+Dojo +フレームワーク WAS V7 アプリケーション・デザインWorkshop Part2 ここまでの比較検討結果を踏まえた、採用方針を決定するためのフローチャートはこ のようになります。 45 204. プレゼンテーション層の実装技術を検討 02.フロントエンド設計 02.フロントエンド設計 【参考】 技術要素の採用の方針 リッチクライアント要件がある場合の一般的な注意点 – JavaScriptでは不可能な要件がないか確認する • 本資料内のAjaxの項を参照のこと – 存在する場合は、Flashなどのその他のRIAコンポーネントについて検討する • • IBMによるサポートは受けられない点に注意する必要がある ブラウザのFlashプラグインなどの展開方法や運用、バージョンアップについても検討しなければならない 画面数が少なく、リッチクライアント要件がない場合 – どれを選んでも大きな差はないため、プロジェクトの特徴によって選択する • • • • コストの圧縮や迅速な開発が重要であれば、JSPのみ利用パターンが最も容易 フレームワークの経験者がいれば、フレームワークを利用した方が柔軟性が上がり、結果的には工数削減に繋がる お客様満足度の向上のために、Dojoを採用してリッチクライアントを実現する 拡張性を考慮するのであれば、フレームワークを選定し、設定値をなるべく外部化することで、将来のシステム更改に 備える 画面数が少なく、リッチクライアント要件がある場合 – JSP+Dojoパターン • Ajaxによって、ページ遷移を減らすことが可能になり、ページ遷移管理が容易になるため、フレームワークを採用する 必然性はやや薄れる – JSP+フレームワーク+Dojoパターン • 46 Javaに特化されているお客様であれば、標準フレームワークに合わせてDojoを利用することも可能 WAS V7 アプリケーション・デザインWorkshop Part2 ここまでの比較検討結果を踏まえた、採用方針に関する説明になります。 46 204. プレゼンテーション層の実装技術を検討 02.フロントエンド設計 02.フロントエンド設計 【参考】 技術要素の採用の方針 画面数が非常に多く、リッチクライアント要件がない場合 – JSP+フレームワークパターン • • メリット : アプリケーションの互換性、保守容易性、開発生産性の向上、Javaとの連携が容易 デメリット : JavaScriptでの様々な処理が利用不可、Java EE以外での再利用不可 – JSP+Dojoパターン • • メリット : リッチクライアントによるお客様満足度の向上、コンポーネントの再利用が容易 デメリット : 開発生産性・保守性が低い、サーバーとの連携にはRESTful Webサービスが必要 – JSP+フレームワーク+Dojoパターン • • メリット : リッチクライアントによるお客様満足度の向上、Javaによるコンポーネント利用、Javaとの連携が容易 デメリット : 技術要素の増加によって、問題判別や要員教育が難しくなり、運用保守性は下がる 画面数が非常に多く、リッチクライアント要件がある場合 – JSP+Dojoパターン • • Java以外も利用されているお客様であれば、Dojoでコンポーネントを作ると共通化・再利用しやすい 画面遷移管理が弱いため、ページ間の情報のやり取りなどが存在する場合は避ける – 独立したWebページを遷移するのであれば大きな問題はない – JSP+フレームワーク+Dojoパターン • • • 47 Javaに特化されているお客様であれば、標準フレームワークに合わせて利用することも可能 コンポーネント化はフレームワークの機能によって行い、共通部品化することで、効率化する 技術要素の増加によって、問題判別や要員教育が難しくなり、運用保守性は下がる WAS V7 アプリケーション・デザインWorkshop Part2 ここまでの比較検討結果を踏まえた、採用方針に関する説明になります。 47 204. プレゼンテーション層の実装技術を検討 02.フロントエンド設計 02.フロントエンド設計 フロントエンドのフレームワーク選定 主に、JSF / Struts/ Spring のいずれかから選ぶことになることが多いと思われる JSF – MVCの中でもView層をより容易にするためのJava EE標準のフレームワーク – 最新版は2.0 (Java EE 6)で、WAS V7では1.2が利用可能 – 標準で豊富なカスタムタグライブラリーと、コンポーネント化の方式、サーバーサイドとの連携方法を提供 Apache Struts – MVCの中でもController層をより容易にするためのオープンソースのフレームワーク – Apacheが開発、公開している（ライセンスはApache License 2.0） – 最新版は2.1.8.1 (2010/08/09現在) Spring MVC (Spring Framework) – MVC全体を包括するオープンソースのフレームワーク – SpringSource(VMware)が開発、公開している（ライセンスはApache License 2.0） – 最新版は3.0.3 (2010/08/09現在) 機能や目的の違いがあるため、一概に言えないが、以下の方針で検討すると良いと思われる – Viewに関する要件が多い、重視される場合や、Java EEの標準技術を重視する場合はJSF – Controllerに関する要件が多い、重視される場合にはStruts – 上記の複数の要件が重なる場合はSpring、またはJSF+Struts、JSF+Spring等の組み合わせを検討 48 WAS V7 アプリケーション・デザインWorkshop Part2 フレームワークを利用する場合は、どのフレームワークを利用するか検討が必要です。 フレームワークの選定には、機能面以外にも、他のシステムでの採用例や、標準技 術かオープンソースかといった観点があります。一般的にはMVCモデルに沿ったフ レームワークが提供されますので、その中で、システムで重視される特徴やその他の 要件を含めて、検討する必要があります。 48 02.フロントエンド設計 02.フロントエンド設計 マクロ設計の重要な考慮ポイント 49 WAS V7 アプリケーション・デザインWorkshop Part2 49 02.フロントエンド設計 02.フロントエンド設計 画面デザインとHTMLの分割方式 ヘッダー部、フッター部、左右メニュー、コンテンツ部など、どのように外見を分離するか どのように1つのHTMLの中身を分割するか（どのように作業を分担しながら、共通化するか） 1. 外見は自作のCSSで、HTMLはJSPのincludeを用いて分割 フレームで分割 外見はDojoのBorderContainerで、HTMLはJSPのincludeを用いて分割 4. 外見はDojoのBorderContainerで、HTMLはDojoのContentPaneのhrefプロパティーで分割 2. 3. – 基本的には1.か3.を推奨、2.は非推奨 ●1、3の方式 ●2、4の方式 JSP JSP HTML JSP JSP 50 JSP JSP WAS V7 アプリケーション・デザインWorkshop Part2 マクロ設計では、画面デザインの実現方法とマークアップの分割方法について検討 する必要があります。 1.は、Webにおける標準技術による方法になります。ただし、クロスブラウザー要件が ある場合は、CSSの作成に注意する必要があります。JSPのincludeを用いることで、 HTMLのヘッダーを共通化できるため、後々ヘッダー部の変更が発生した場合に、 変更が容易になります。 2.は、ややレガシーな方法になります。この場合、フレームによって見た目が規定さ れてしまい、後々の変更が難しいため、基本的には推奨しません。フレーム自体が Webの標準技術としては非推奨になりつつあり、現在策定中の次期バージョンの HTMLではframeタグが削除される予定になっているため、今から採用するメリットは あまりないと思われます。 3.では、DojoのCSSを利用することになるため、自作する必要がなく、最初からクロス ブラウザー対応されている点がメリットです。かなり複雑な画面デザインも、マーク アップだけで実現できるため、開発スキルも必要ありません。BorderContainerの子 要素は、JSPのincludeで出力することになります。 4.ですが、DojoのContentPaneのHrefプロパティーを指定すると、指定したHTML ファイルを取得して、内部に表示できる機能を利用する方法です。これによってポー タルのようなものを容易に実現できますが、JSPなどのテンプレートエンジンがある場 合は、特に利用するメリットはないと思われます。また、Same-origin Policyについて も気をつける必要があります。 50 02.フロントエンド設計 02.フロントエンド設計 リッチクライアントのパフォーマンス プレーンなHTMLと比較して、リッチクライアントは初期表示に時間がかかる 1. JavaScriptのレンダリング処理 • JavaScriptがダウンロードされてから実行される処理に時間がかかる 2. JavaScriptのダウンロード時間 • JavaScriptのファイルをダウンロードする時間がかかる 3. Dojoモジュールの読み込み時間 • Dojoモジュールは同期呼び出しされるため、そのまま利用すると表示に時間 がかかる Dojoのカスタムビルドを行うことで、2.と3.の問題を回避できる – Dojoモジュールを1ファイルにまとめ、 JavaScript圧縮をかけてくれる – 利用するモジュール数が多い場合はカスタムビルドを行うことを推奨 – JavaScript圧縮とDojoカスタムビルドの実行環境は、FP Web 2.0で提 供される 51 WAS V7 アプリケーション・デザインWorkshop Part2 リッチクライアントを採用する場合は、プレーンなHTMLと比較して、リッチクライアント は初期表示に時間がかかるため、事前にパフォーマンスに関する配慮が必要です。 主に、JavaScriptのレンダリング処理、JavaScriptのダウンロード時間、 Dojoモ ジュールの読み込み時間の3種類に分けることができます。 JavaScriptのレンダリング処理は、JavaScriptがダウンロードされてから実行される 処理に時間がかかることによるものですが、ブラウザのレンダリング速度によるので、 設計での回避は難しくなります。実装において、パフォーマンス測定ツールを利用す るなどで多少改善できることもありますが、ほとんどがブラウザー自身の能力によるも のですので、ブラウザーがIE6の場合などは、JavaScriptの画面パーツをあまり利用 しないなどの配慮が必要です。 JavaScriptのファイルをダウンロードする時間については、JavaScriptの圧縮をかけ ることである程度回避できます。また、Dojoモジュールについてですが、Dojoではモ ジュール依存関係による順序性を保障しなければならないため、同期的に呼び出し されるため、そのまま利用すると表示に時間がかかってしまいます。これらの問題は、 Dojoのカスタムビルドを行うことで、回避することが可能です。利用するモジュール数 が多い場合は、カスタムビルドを行うことを推奨します。このDojoカスタムビルドを実 行するとデフォルトでJavaScript圧縮も行ってくれます。JavaScript圧縮とDojoカス タムビルドの実行環境は、FP Web 2.0で提供されます。カスタムビルドについては、 下記URLを参照してください。 •build/buildScript - DojoCampus - Docs •http://docs.dojocampus.org/build/buildScript 51 02.フロントエンド設計 02.フロントエンド設計 【参考】 Dojoカスタムビルドの作成 実行手順 1. 必要な環境とモジュールを準備する（FP Web 2.0の適用） 2. カスタム・プロファイル（下記）を作成する 3. ビルド・コマンドの実行 1. cd "<dojo-src root>/util/buildscripts" 2. build.sh(bat) profile=<name> action=release [その他オプション] カスタム・プロファイル – – 使用するDojoコンポーネントを指定したファイル "<dojo-src root>/util/buildscripts/profiles"に"<name>.profile.js"を作成 dependencies ={ layers: [{ name: "mydojo.js", dependencies: [ "dijit.Button", "dojox.wire.Wire", "dojox.wire.XmlWire" ] }], prefixes: [ [ "dijit", "../dijit" ], [ "dojox", "../dojox" ] ] }; 52 layersの中のnameには、生成するjsファイルの名前を指定 する。 layersの中のdependenciesには、使用するモジュールを記 述する。Dojoのジュール場合、dojo.require()で指定してい るモジュール名を指定する。自作のJavaScriptの場合ファン クション名を指定する。 prefixesには、対象のモジュールがある場所と名前を指定す る。Dojoのモジュールの場合は、例の通りに指定する。自作 JavaScriptも対象の場合は追記する。 その他の設定項目については通常は使用しない。詳細は DojoToolkitのサイトを参照。 WAS V7 アプリケーション・デザインWorkshop Part2 52 02.フロントエンド設計 02.フロントエンド設計 【参考】 Shrinksafe 概要 – JavaScriptコード圧縮ツールの1つ • コメントや不必要な改行や空白の削除や、長い関数名・引数名の短縮化を実施し、ファイ ルサイズをミニマイズするツール – メリット • ユーザーがダウンロードするJavaScriptファイルのサイズを低く抑えることができる – デメリット • コードの可読性が損なわれ、人がデバッグする事が非常に困難になる • 圧縮後のコードでテスト（単体、結合）を行うことを推奨 実行手順 1. 必要な環境とモジュールを準備する（FP Web 2.0の適用） 2. cd <shrinksafe root> 3. java -jar shrinksafe.jar <input>.js > <output>.js • 例） java -jar shrinksafe.jar infile.js > outfile.js 53 WAS V7 アプリケーション・デザインWorkshop Part2 53 02.フロントエンド設計 02.フロントエンド設計 リッチアプリケーションの状態の保持・復元 Ajaxや、リッチクライアントを利用したアプリケーションはページ遷移がない（少ない） – – ブラウザが終了した場合や、ページを移った場合に状態が失われないための配慮が必要 他のWebアプリケーションから遷移してくる際に、初期状態を復元しなければならない ブラウザの終了に対する対策 – – 1. 2. 何もしないと、フォーム入力中の値が失われる ページ遷移がないため、ページ遷移時にセッションに書き込むといった処理ができない 定期的にフォームの値をJavaScriptのHTTPリクエストで送信し、セッションに保存する Webブラウザーのストレージ領域を利用する（先進的なブラウザーに限る） 一時保存したい データ 成功/失敗 書込 HTTPSession 54 × Servletなど サーバーとの 通信は必要なし 書込 Web Storage WAS V7 アプリケーション・デザインWorkshop Part2 リッチクライアントの画面の保持・復元は、リッチなUIを持つWebアプリケーションで重 要な考慮点です。 まず、1ページに表示できる入力フォームが多く、滞在している時間が長いため、ブラ ウザが終了した時にフォーム入力中の値が失われ、ユーザーが全てのデータを再入 力しなければならなくなってしまいます。ここではページ遷移がないため、ページ遷 移時にセッションに書き込むといった処理ができません。ですので、定期的にフォー ムの値をJavaScriptのHTTPリクエストで送信し、セッションに保存するか、HTML5に よるWebブラウザーのストレージ領域を利用するなどの対策が必要です。 54 02.フロントエンド設計 02.フロントエンド設計 リッチアプリケーションの状態の保持・復元 ブラウザのページ遷移に対する対策、初期状態の復元 – – 1. 2. 誤って、ブラウザの"戻る"ボタンを押した場合に、全ての状態が失われる 何も考慮しないと、コンテンツが切り替えられた後の状態に、直接アクセスできない Dojoのdojo.backなどの機能を利用し、決まった箇所で状態を保持するようにする 初期状態は、dojo.addOnLoadやdojo.hashなどを利用して、復元処理を記述する 初期状態の復元 ステートの 保持 55 同一ページ WAS V7 アプリケーション・デザインWorkshop Part2 また、タブやツリーを選択することでページ内のコンテンツが切り替えられるページに おいて、誤って、ブラウザの"戻る"ボタンを押した場合に、全ての状態が失われてし まうのも問題です。また、タブを選択した画面に対してリンクを張りたい場合などが存 在します。前者はDojoのdojo.backなどの機能を利用し、決まった箇所で状態を保 持するようにする必要があります。そのためには、どのタイミングで状態を保持するか、 画面遷移図などから選定する必要があります。後者は、dojo.addOnLoadや dojo.queryToObject、dojo.hashなどを利用して、選択状態などの復元処理を明示 的に記述しなければなりませんので、どの画面がリンクされる可能性があるかの洗い 出しが必要です。 55 02.フロントエンド設計 02.フロントエンド設計 RESTful Webサービスの設計 基本的にはマクロ設計の完了時点でパラメータまで決定している必要がある – SOAPのWSDLの設計と作成に相当する作業 – Excelなどで作成した設計書が成果物となり、それを見ながら開発者はコーディン グを行うことになる 設計手順（ROA※による手法） – リソースの洗い出し、URLの決定 – リソースに対して実装するメソッドの決定 – 各パラメータの定義 ： リソース設計 ： オペレーション設計 ： 表現設計 • エラー時のメッセージや処理についても考慮する必要がある 注意点 – RESTful Webサービスは、メッセージのデータ形式をHTTPでやり取りする • HTTPで全てのデータを渡す必要があるので、メッセージとしては"文字列"しか使えない ※ ROA : Resource Oriented Architechture 56 WAS V7 アプリケーション・デザインWorkshop Part2 RESTful Webサービスの設計は、フロントエンドだけに関係しない場合もありますが、 Ajaxでの利用を考え、ここで説明します。フロントエンドからすると、データアクセスを 実現するコンポーネントですので、マクロ設計の完了時点で、ほぼ全ての設計が完 了している必要があります。 RESTful Webサービスは、ROA(Resource Oriented Architechture)に基づいて設 計を進めると、より良い設計になると言われています。ROAでの設計手法について は、次ページ以降で説明していますので、参照ください。 先述のとおり、Webサービスですので、HTTPで利用できるデータ形式のみがやり取 りされることになります。JavaのAPIなどとは異なるので注意してください。 56 02.フロントエンド設計 02.フロントエンド設計 【参考】 RESTful Webサービス設計の手順 1. リソース名を決定する。 ` ` リソースとは、 URLの末尾部分に相当する、操作の対象になる物体の名称のこと。 基本的には、リソース名は名詞の英単語（もしくはローマ字表記）であり、基本的に複数形とする。 ` ` 2. オペレーションを設計する。 ` 基本的には、以下のように定義する。 ` ` ` ` 57 URLの末尾をgetEmployeesなど、オペレーションにしてはならない。 返すデータを細かく制御するために、別のリソースを作成するべきではない。 HTTP GET ： 検索 ` http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3 ` URIによって特定されるコンテンツを取得する。（エンティティボディによってリソースを特定するべきではない） HTTP POST ： 新規作成 ` http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 ` エンティティボディに含めたデータでリソースを新規作成する。 HTTP PUT ： 更新/新規作成（存在しない場合） ` http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 ` URIによって特定されるリソースを新規作成・更新する。更新内容はエンティティボディに含める必要がある。 HTTP DELETE ： 削除 ` http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7 ` URIによって特定されるリソースを削除する。 （エンティティボディによってリソースを特定するべきではない） WAS V7 アプリケーション・デザインWorkshop Part2 57 02.フロントエンド設計 02.フロントエンド設計 【参考】 RESTful WebサービスのURL設計 3. 表現を設計する。 – 表現とは、パス変数、クエリ変数、HTTPヘッダ、ステータスコード、エンティティボディ等を指 す。 • • • • • • – 注意点 • • • • 58 パス変数（URLのスラッシュで区切られた文字列） クエリ変数（URLに ?${key}=${param} の形式で付加される文字列） マトリックス変数（URLに #${key}=${param} の形式で付加される文字列） – JAX-RSで定義されている HTTPヘッダー HTTPエンティティ・ボディ HTTPステータスコード エンティティボディには、基本的にデータの実体やメッセージを格納するためのみに利用し、独自のエ ラーコードなどを含んだドキュメントを送るために利用してはならない。 表現の中に、大きく処理内容を切り替えるようなパラメータを含めてはならない。 – 例） method=delete、action=updateなど クエリ変数・パス変数を利用する場合は、URIが長くなりすぎないように注意する。 日本語をURIに含めるときは、UTF-8としてURIエンコード（パーセントエンコード）する。 WAS V7 アプリケーション・デザインWorkshop Part2 58 02.フロントエンド設計 02.フロントエンド設計 JavaScriptの単体テスト方式の決定 JavaScriptで、単体テストは一般的には困難 – 型宣言や引数の数の指定などがないため、テストケースが増大する – 画面の操作を行うため、自動化による判断が難しい • 画面が書き換わったことを判断するロジックをテストケースとして記述しづらい – UIに紐づいた処理は、テストクライアントによるテストになる 基本方針 – モジュール化された共通ロジックや関数化された処理は、自動化された単体テス トの対象とする • • • 様々なページで利用される共通処理はモジュール化を行い、単体テストを実施 関数化されていれば、ある程度単体テストの自動化も可能 単体テストの自動化には、 FP Web 2.0に付属するD.O.Hを利用する – UIパーツは、テストケースを作り、テストクライアントで単体テストを行う • 59 テストケースによって例外系も洗い出した上で、画面を動かしながらテストを行う WAS V7 アプリケーション・デザインWorkshop Part2 Ajaxアプリケーションを作成する場合は、JavaScriptの成果物が増えることになりま す。この単体テストの方式は悩ましい問題です。これはプロジェクトの品質管理基準 などにも影響しますので、そうした要件とのすり合わせを行いながら検討を行ってくだ さい。 59 02.フロントエンド設計 02.フロントエンド設計 【参考】 D.O.Hによるテストの実行 概要 – – 機能 – – – Dojoに付属する、JavaScriptの単体テストツール（Dojoモジュール以外もテスト可能） WASのFP Web 2.0に同梱されている 非同期メソッドのテストも可能 任意の回数のループ実行を行わせることが可能（パフォーマンス測定） 任意のテストをまとめて実行したテストケースを作成可能（テストのコンポーネント化） 環境構築 – アプリケーション内にDojo ToolkitのUtilディレクトリーを配置する • util/dohディレクトリーが存在すればよい。 テストの実行 1. テストコードを記述する。（次ページ以降参照） 2. ブラウザからD.O.Hを実行する。 • 60 /util/doh/runner.htmlに、HTTPのクエリパラメータを与えてアクセスすれば良い。 – testModule : テストコードが書かれたファイルのパス – testUrl : テスト対象となるコードが書かれたファイルのパス – 例 ： /util/doh/runner.html?testModule=jsTests.commonTest&testUrl=/js/common WAS V7 アプリケーション・デザインWorkshop Part2 60 02.フロントエンド設計 02.フロントエンド設計 【参考】 D.O.Hによるテストの実行 テストコードの記述には、下記のサイトを参照すること。 – http://docs.dojocampus.org/util/doh シンプルなテストコードのサンプル（同期メソッドのテスト、シンプル版） dojo.provide("jsTests.sampleTest"); doh.register("jsTests.sampleTest", [ function assertTrueTest(){ doh.assertTrue(true); }, function assertFalseTest(){ doh.assertFalse(!true); }, function assertEqualTest(){ var hoge = "test"; doh.assertEqual("test", hoge); }, function assertNotEqualTest(){ var hoge = "test"; doh.assertNotEqual("qwerty", hoge); } ]); 61 WAS V7 アプリケーション・デザインWorkshop Part2 61 02.フロントエンド設計 02.フロントエンド設計 【参考】 D.O.Hによるテストの実行 テストコードのサンプル（同期メソッドのテスト、複雑版） dojo.provide("jsTests.sampleTest2"); doh.register("jsTests.sampleTest2", [{ name: "thingerTest", setUp: function(){ this.thingerToTest = new Thinger(); this.thingerToTest.doStuffToInit(); }, runTest: function(){ doh.assertEqual("blah", this.thingerToTest.blahProp); doh.assertFalse(this.thingerToTest.falseProp); // ... }, tearDown: function(){ } }]); var Thinger = function(){}; Thinger.prototype = { doStuffToInit : function() { this.blahProp = "blah"; }, blahProp : "", falseProp : false }; 62 WAS V7 アプリケーション・デザインWorkshop Part2 62 02.フロントエンド設計 02.フロントエンド設計 【参考】 画面部品のコンポーネント化 画面部品を共通化して、個々の画面から呼び出して使うための方式 大きく分けて、以下のような方式がある 1. JSPのカスタムタグの作成 – JSPのタグを新規作成し、そのタグを個々のJSP内に記述することで共通化を実現する – Ajaxによる処理が必要なカスタムコンポーネントは、JSPカスタムタグだけでは実現不可能 – 実現には様々な方式がある（後述） • • 2. Dojoのカスタムコンポーネントと組み合わせれば、実現は可能 Dojo (Dijitコンポーネント) – – – Dojoでは、HTML+CSS+JavaScriptのコンポーネント(Widget)を作成する方式を提供して いる 既存のDijitコンポーネントの拡張や、新規カスタムコンポーネントの作成が可能 HTML, CSS, JavaScriptで実行できる処理は何でもコンポーネント化できる • • 63 タグの出力結果をDojoのコンポーネントにすることで、リッチクライアント化も可能 単なるHTMLを出力するだけのパーツも作成できる 画面パーツだけではなく、JavaScriptの共通処理をパッケージングすることも可能 WAS V7 アプリケーション・デザインWorkshop Part2 画面部品の共通パーツ化も、重要な項目です。これによって、各画面での開発工数 が削減でき、また後々の変更への対応が容易になります。 JSPのカスタムタグは、マークアップ形式で記述することができ、Javaオブジェクトと の連携が容易な方法です。一方、DojoのDijitコンポーネントを自作する方法は、 JavaScriptでクライアント・サイドの処理を行うことできます。 これらの方式は、どちらかのみを採用するものではなく、また実現できる内容が異なり、 また組み合わせて利用することもできますので、それを踏まえて検討を行ってくださ い。 63 02.フロントエンド設計 02.フロントエンド設計 【参考】 既存のDijitコンポーネントの拡張 既存のDijitコンポーネントの値を固定にすることで、プロジェクト固有の設定、処理を共通化する ●メールアドレスのチェックを行うテキストボックス（dijit.form.ValidationTextBoxの拡張） if (!dojo._hasResource["com.ibm.MailValidationTextBox"]) { dojo._hasResource["com.ibm.MailValidationTextBox"] = true; dojo.provide('com.ibm.MailValidationTextBox') dojo.require('dijit.form.ValidationTextBox'); dojo.declareによってクラスを宣言し、 第2引数に拡張対象のクラスを指定 //RFCになるべく準拠したメールアドレスをチェックするテキストボックス dojo.declare('com.ibm.MailValidationTextBox', dijit.form.ValidationTextBox, { regExpGen : function(){ var atom = "[a-zA-Z0-9_!#¥$¥%&'*+/=?¥^`{}~|¥-]+"; var dot_atom = "(?:"+atom+")(?:¥.(?:"+atom+"))*"; var quoted = "(?:¥¥[^¥r¥n]|[^¥¥¥"])*"; //local部分 : 厳密には、クオートされている場合にのみ許可される文字のみを許可する必要がある var local = "(?:(?:(?:"+dot_atom+")|(?:¥""+quoted+"¥")))"; //domain部分 : 厳密には、IPアドレスなどを指定する場合の[xx.xxx.xx.xxx]形式なども許可する必要がある var domain = "(?:(?:[a-zA-Z0-9¥-¥.]+))"; var addr_spec = local+"¥@"+domain; 拡張対象のクラスのプロパティーに return "^"+addr_spec+"$"; それぞれ、好きな値を与える }, invalidMessage : "メールアドレスの形式が正しくありません。" }); } ●利用側の宣言（マークアップによる利用） <input type="text" dojoType="com.ibm.MailValidationTextBox"> 64 WAS V7 アプリケーション・デザインWorkshop Part2 64 02.フロントエンド設計 02.フロントエンド設計 【参考】 カスタムDijitコンポーネントの利用 基本的には、HTMLと既存のDijitコンポーネントの組み合わせだけで作成できる ●進行中を示すダイアログの作成 ○JavaScriptファイル（内部処理を規定） if (!dojo._hasResource["com.ibm.widget.ProcessingDialog"]) { dojo._hasResource["com.ibm.widget.ProcessingDialog"] = true; dojo.provide("com.ibm.widget.ProcessingDialog"); dojo.declareによってクラスを宣言し、 dojo.require("dijit._Widget"); 第2引数にdijit._Widgetとdijit._Templatedを指定 dojo.require("dijit.Dialog"); dojo.declare("com.ibm.widget.ProcessingDialog", [dijit._Widget, dijit._Templated],{ templatePath: dojo.moduleUrl("com.ibm.widget", "ProcessingDialog/ProcessingDialog.html"), widgetsInTemplate: true, processingDialogLabel : "進行中...", templatePathプロパティーに、 processingDialogMessage : "実行しています...", テンプレートとなるHTMLのパスを指定 //Flag to protect against accidental multi-startups. _started: false, startup: function() { if(!this._started){ this._started = true; }}, show : function() { this.processingDialog.show(); }, hide : function() { this.processingDialog.hide(); } }); HTMLで定義したプロパティーは、 }; thisオブジェクトに格納されている （次ページ参照） 65 WAS V7 アプリケーション・デザインWorkshop Part2 65 02.フロントエンド設計 02.フロントエンド設計 【参考】 カスタムDijitコンポーネントの利用（続き） 基本的には、HTMLと既存のDijitコンポーネントの組み合わせだけで作成できる ●進行中を示すダイアログの作成 ○HTMLファイル（レイアウトとパーツを規定） dojoAttachPoint属性を指定すると、指定した DOMノードがJSからアクセス可能になる dojoAttachEvent属性では、 DOMノードのイベントハンドラーを指定可能 <HTML> <HEAD><META http-equiv="Content-Type" content="text/html; charset=utf-8"></HEAD> <BODY><DIV> <div dojotype="dijit.Dialog" dojoattachpoint="processingDialog" title="${processingDialogLabel}" draggable="false" style="width:200px;"> <div style="margin-left:10px; margin-right:10px;text-align:center;"> <img src="/dojox/image/resources/images/loading.gif" /> <p>${processingDialogMessage}</p> </div> </div> </DIV></BODY> HTMLで${xxxxx}形式で書かれた値は、 </HTML> JavaScriptのプロパティーが出力される （前ページ参照） ●利用側の宣言（マークアップによる利用） <div dojoType="com.ibm.widget.ProcessingDialog" jsId="procdiag"> <button dojoType="dijit.form.Button" onClick="procdiag.show();"> 66 WAS V7 アプリケーション・デザインWorkshop Part2 66 02.フロントエンド設計 02.フロントエンド設計 【参考】 カスタムタグの実装方式 JSPのカスタムタグを作成する方式としては、以下の選択肢がある 1. タグ・ハンドラ（クラシック・タグ・ハンドラ） • JSP 1の機能で、カスタムタグを作成する機能 • 実装はやや複雑だが、細かいライフサイクルが規定されている 2. シンプル・タグ・ハンドラ • • JSP 2の機能で、クラシック・タグ・ハンドラよりも容易にカスタムタグを作成する機能 ボディ部にELが利用でき、より簡単にカスタムタグが作れるようになっている 3. タグ・ファイル • • JSP 2の機能で、JSPフラグメント等により、ファイルベースでのカスタムタグ作成機能 カスタムタグを作る機能の中では最もシンプルで作りやすく、JSP式やELも利用可能 4. JSFのカスタムコンポーネント • • 67 JSF 1の機能で、ビュー部分とロジック部分を分離する方式を提供している 作成はかなり困難で、設定ファイルを2つ作らなければならない等、設定や相関が煩雑 – ただし、JSF2から容易に作成するための機能が提供されている WAS V7 アプリケーション・デザインWorkshop Part2 先述のとおり、カスタムタグの実現方式は様々なものがあります。もっとも容易なのが、 タグ・ファイルを利用する方式ですが、その他の方式でしかできないこともありますの で、詳細な要件が出てきたときに変更になる可能性もあります。ただ、JSFを除き、別 の方式に変更することはそれほど難しくありませんので、この時点で一度仮決めして おくと良いと思われます。 67 02.フロントエンド設計 02.フロントエンド設計 【参考】 バリデーションの方針 バリデーションをどこで、どのように実行するか 1. クライアントで行い、サーバーでは行わない – メリット ： ユーザーにとって親切 – デメリット ： 外部公開するWebページでは利用不可 • JavaScriptがオフの場合や、User JSによって、検査なしで実行されてしまうため 2. クライアントでは最低限のチェックのみを行い、実行時にサーバーで行う – メリット ： 実装はやや困難、ユーザーにとって親切 – デメリット ： バリデーターのパターンチェックのロジックの共有が難しい • DRYの原則※に反する上、チェックロジックを同等にできない可能性があるので注意 3. クライアントでは行わず、実行時にサーバーで行う – メリット ： 実装が容易 – デメリット ： ユーザーにとって不親切 クライアント・サイドでのバリデーション ※ DRYの原則 : DRYはDon't Repeat Yourselfの略。 重複を避け、二重管理が必要にならないようにすること。 68 WAS V7 アプリケーション・デザインWorkshop Part2 入力フォームがある場合は、ほとんどの場合、バリデーションを何らかの形で実装す る必要があります。大きく分けて、クライアント・サイドでのバリデーションとサーバー・ サイドでのバリデーションの2通りがありますが、これらを両方とも同一のチェックを行 うことはDRYの原則から反するだけでなく、異なる言語でチェックロジックを同等にで きる保証がないことに注意する必要があります。 68 02.フロントエンド設計 02.フロントエンド設計 マイクロ設計の重要な考慮ポイント 69 WAS V7 アプリケーション・デザインWorkshop Part2 69 02.フロントエンド設計 02.フロントエンド設計 JavaScriptのデザインパターン - MVPパターン JavaScriptを利用する場合、HTMLとの役割分担が必要になる – ユーザーインターフェース（画面部品等）からの処理の分離、疎結合化が必要 • • JavaScriptを利用すると、HTMLをどこでも書き換えることができてしまう HTML内にJavaScriptでの処理を書き込んでしまうことで、後々の変更が難しい画面ができてしまう MVPパターンという考え方を持っておくと、設計ミスが起こりづらくなる – Model • • データモデルを持つコンポーネントで、ViewやPresenterに全く依存しない JavaScriptの場合、データを持つオブジェクトや、RESTful Webサービスなどを指す – View • • • ユーザーインターフェースを持つコンポーネント 可能な限り、処理を行うロジックを持たせない ユーザーインターフェースの操作が発生した際に、Presenterに処理を依頼する – Presenter • • Viewから処理依頼を受け取り、処理を実行するコンポーネント Modelを利用（生成・取得など）しても良い。また、処理の結果、Viewを書き換えても良い JavaScript+HTMLにMVPパターンを適用する ≒ マークアップから処理をなるべく分離する – HTML側に複雑な処理を持たせない、なるべく処理を記述しない • ただし、必ずしも View = HTML、Presenter＝JavaScript "ではない" – イベントベース・プログラミングモデルを生かした設計、コーディングを行う 70 WAS V7 アプリケーション・デザインWorkshop Part2 Ajaxアプリケーションを作成する場合は、マークアップとJavaScriptのロジックをどう 明確に分離していくか、という点が重要になります。JavaScriptはいろいろな書き方 ができ、全てをHTMLの中に書くことも可能ですので、コーディング規約がないと、メ ンテナンス性の低いページが大量生産されてしまうことになります。 MVPパターンは、GUIを持つアプリケーションにおいて有効な設計パターンです。 Webアプリケーションの設計としてはMVCモデルが有名ですが、その派生パターン の一つです。Presenterが一般にはJavaScriptの処理に相当することになります。 70 02.フロントエンド設計 02.フロントエンド設計 JavaScriptのデザインパターン - MVPパターン 良くない例 <script type="text/javascript"> dojo.require("dijit.Dialog"); function myclickfunc() { var dialog = new dijit.Dialog({ title : "My Dialog", contents : "<p>This is my dialog.</p>" }); dialog.show(); } </script> <button onClick="myclickfunc();"> Show Dialog </button> 良い例 <script type="text/javascript"> dojo.require("dijit.Dialog"); dojo.addOnLoad(function() { dojo.connect(dojo.byId("show_button"), "onClick", function(){ dijit.byId("mydiag").show(); }); }) </script> <button id="show_button">Show Dialog</button> <div dojoType="dijit.Dialog" id="mydiag" title="My Dialog"> <p>This is my dialog.</p> </div> 左の例では、HTMLの中にonClick要素として、JavaScriptの関数が指定されている – JavaScriptの関数名と、マークアップが密結合になってしまっている – 右の例では、dojo.connect関数を利用して、onClickイベントと関数の結びつけを行っており、変更は容易 左の例では、ダイアログをJavaScript内で生成して、それを表示している – マークアップを見ただけでは、画面にどういう表示コンポーネントが存在するのかわからない – 右の例では、ダイアログはマークアップで宣言しており、表示処理はJavaScript側で行っている 71 WAS V7 アプリケーション・デザインWorkshop Part2 MVPパターンの実際の例です。 71 02.フロントエンド設計 02.フロントエンド設計 【参考】 バリデーターの実装 クライアント・サイド 1. dijit.form.ValidationTextBox – Dojoが利用できることが前提 – 正規表現による指定が可能、ツールチップやマークによる警告表示 2. dijit.form.ValidationTextBoxの拡張コンポーネント – Dojoが利用できることが前提 – 正規表現の固定化が可能（共通パーツ化）なので、アプリケーションで共通する特殊な バリデーションは共通化する 3. 自作のJavaScript – Dojoを利用しない場合は、自作する必要がある サーバー・サイド 1. フレームワーク機能の利用 • JSFなどの機能により、フォームの値の必須や値の制限などが可能 2. 自作のバリデーター • 72 フォームを受け取る側で、必ずバリデーターを呼ぶような規約が必要となる WAS V7 アプリケーション・デザインWorkshop Part2 マクロ設計で決定した、バリデーションの方式にあわせて、バリデーターを実装しま す。クライアントサイドでは、Dojoを利用している場合は、 dijit.form.ValidationTextBoxを利用すると便利です。自作のdijitコンポーネントとし て、dijit.form.ValidationTextBoxのバリデーションロジックを共通化するのも有効で す。 サーバーサイドでは、フレームワークでバリデーション機能を持つものもあるので、そ れがある場合は利用すると便利です。 72 02.フロントエンド設計 02.フロントエンド設計 まとめ 本セッションでは、以下の点について説明しました。 – Java EEにおけるサーバーサイドのフロントエンド技術 • JSP、JSF – JavaScriptによるクライアントサイドのフロントエンド技術 • Ajax、JavaScript、Dojo Toolkit – これらをつなぐインターフェースに関する技術 • RESTful Webサービス、JAX-RS – 提案フェーズ、ソリューション・アウトラインフェーズにおけるアーキテクチャー・デシジョン • • • Ajaxを採用判断や利用パターンと、その接続方式について フロントエンド技術の採用に関する選定基準について フレームワークの選定基準について – マクロ設計、マイクロ設計における重要な考慮ポイント • • • • 画面やデザインの分離方法や、画面パーツの実装方式 バリデーションの方針や実装方法 リッチクライアントに関する考慮点、JavaScriptのデザインパターンと単体テスト方式 RESTful Webサービスの設計 73 WAS V7 アプリケーション・デザインWorkshop Part2 本セッションのまとめです。 73 02.フロントエンド設計 02.フロントエンド設計 参考文献 Dojo Toolkit : http://www.dojotoolkit.org/ ハイパフォーマンス Webサイト (Steve Souders 著, オライリー・ジャパン, 2008/04) スケーラブル Webサイト (Cal Henderson 著, オライリー・ジャパン, 2006/12) JavaScript 第5版 (David Franagan 著, オライリー・ジャパン, 2007/08) Webを支える技術 (山本陽平 著, オライリー・ジャパン, 2010/05) Apache Struts : http://struts.apache.org/ SpringSource.org : http://www.springsource.org/ Design Principles : http://www.slideshare.net/gelvan/design-principles ユーザビリティとは？ What's Usability? : http://www.usability.gr.jp/whatis/whatis001127- 1.html インターン講義5日目「ユーザインターフェース,HTML5」 - Hatena::Engineering : http://d.hatena.ne.jp/hatenatech/20100806/1281088801 JSFとSpring2の連携設定 - IT-Walker on hatena : http://d.hatena.ne.jp/Syunpei/20061109/1163043612 第10回 Spring＆Struts連携のベスト・プラクティスはこれだ！ - 今必要な人のための速習 Spring Framework：ITpro : http://itpro.nikkeibp.co.jp/article/COLUMN/20080929/315624/ 74 WAS V7 アプリケーション・デザインWorkshop Part2 74 02.フロントエンド設計 02.フロントエンド設計 End of Presentation 75 WAS V7 アプリケーション・デザインWorkshop Part2 75