Webアプリケーション設計 概要 1 ISE Webアプリケーション基盤 Webアドバンスド・ソリューション グループ
by user
Comments
Transcript
Webアプリケーション設計 概要 1 ISE Webアプリケーション基盤 Webアドバンスド・ソリューション グループ
Webアプリケーション設計 概要 ISE Webアプリケーション基盤 Webアドバンスド・ソリューション グループ 水野 雅裕（[email protected]） 1 01. Webアプリケーション設計概要 Webアプリケーション設計概要 Disclaimer この資料は日本アイ・ビー・エム株式会社ならびに 日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式なレビューを受けておりませ ん。 当資料は、資料内で説明されている製品の仕様を保証するものではありません。 資料の内容には正確を期するよう注意しておりますが、この資料の内容は2010年9月現在の情 報であり、製品の新しいリリース、PTFなどによって動作、仕様が変わる可能性があるのでご注意 下さい。 今後国内で提供されるリリース情報は、対応する発表レターなどでご確認ください。 2 WAS V7 アプリケーション・デザインWorkshop Part2 2 01. Webアプリケーション設計概要 Webアプリケーション設計概要 Agenda 1. ワークショップ概要 2. Webアプリケーション設計の全体像 3. Webアプリケーションの概要設計 4. アーキテクチャー・デシジョンのポイント － 提案フェーズ 5. アーキテクチャー・デシジョンのポイント － SOフェーズ 3 WAS V7 アプリケーション・デザインWorkshop Part2 3 01. Webアプリケーション設計概要 Webアプリケーション設計概要 １．ワークショップ概要 4 WAS V7 アプリケーション・デザインWorkshop Part2 4 01. Webアプリケーション設計概要 Webアプリケーション設計概要 ワークショップ概要 ワークショップの目的 – WASを使用したWebアプリケーション設計のポイントを説明する • 特に、製品選定や設計上のデシジョン・ポイントの、時期や判断基準を提示す る • 今回のワークショップでは、Feature Pack、先進技術、WASファミリー製品、 開発作業関連ツールについて取り上げる – フロントエンド設計 – サービス設計 – データ・アクセス設計 – イベント＆Javaバッチ設計 – アプリケーション開発管理 概要セッションの目的 – Webアプリケーション設計の概要を説明し、ソリューション・アウトライン フェーズ終了までに実施すべきアーキテクチャー・デシジョンのポイントを 概説する 5 WAS V7 アプリケーション・デザインWorkshop Part2 このワークショップの目的です。 WASを使用したWebアプリケーション設計のポイントを説明します。特に、製品選定や設計上のデ シジョン・ポイントの時期や判断基準について解説します。 概要セッションでは、Webアプリケーション設計の概要、アーキテクチャー・デシジョンのポイントにつ いて概説します。 5 01. Webアプリケーション設計概要 Webアプリケーション設計概要 Webアプリケーション設計時の課題 課題 既に決定している事 項が制約となり最適 なソリューションが選 択できない 全体設計が曖昧 先進テクノロジーを採 用したいが、いつ何を 検討すれば良いか分 からない 設計作業の後半 になってから検討 コスト増大 スケジュール遅延 トラブル発生 – ☆プロジェクトの早い段階から検討を開始すべき項目がある。 – このセッションでは、 • 提案フェーズ ： 以降のフェーズで大きな影響を及ぼすデシジョン・ポイントを 解説 • ソリューション・アウトラインフェーズ ： 注意すべきデシジョン・ポイントを概説 6 WAS V7 アプリケーション・デザインWorkshop Part2 Webアプリケーション設計時には、全体設計が曖昧だったり、先進テクノロジーを採用したいがいつ 何を検討すれば良いか分からないと言った事があります。これにより、検討が後のフェーズになって しまったり、検討漏れが発生したりします。その結果、既に決定している事項が制約事項となり最適 なソリューションが選択できなくなる事があります。仕方なく回避策をとることにより、コストが増大した り、作業が遅延したり、トラブルを誘発したりというマイナスな状況を発生させる事があります。 この課題を解決するには、プロジェクトの早い段階から検討を実施する必要があります。このセッショ ンでは、WASを使用したWebアプリケーション設計の際に実施すべきデシジョン・ポイントを示しま す。 6 01. Webアプリケーション設計概要 Webアプリケーション設計概要 ２．Webアプリケーション設計の全体像 7 WAS V7 アプリケーション・デザインWorkshop Part2 7 01. Webアプリケーション設計概要 Webアプリケーション設計概要 Webアプリケーション開発ライフサイクル このセッションの対象 このワークショップの対象 提案 提案 zヒアリング zソリューション決定 z製品選定 zシステム概要設計 zサイジング zシステム構成決定 リリース （要件定義） （外部設計） （内部設計） ソリューション・ ソリューション・ アウトライン アウトライン （SO） （SO） マクロ設計 マクロ設計 マイクロ マイクロ 設計 設計 zお客様環境の調査と分析 zソリューション要件のアウトライン作成 zアプリケーション・モデルのアウトライン作成 zアーキテクチャー・モデルのアウトライン作成 zビジネスへの影響評価 zソリューション戦略のアウトライン作成 8 z要件およびアプリケーション・モデルの洗練 zユーザー・インターフェースの設計 zアーキテクチャー・モデルの設計 z静的テストの実施（マクロ設計） zソリューション計画の設計 zテスト仕様の設計 z開発環境の構築 構築 構築 サイクル サイクル z要件およびアプリケーション・モデルの詳細化 zアーキテクチャー・モデルの洗練 z静的テストの実施（マイクロ設計） zユーザー・インターフェースの詳細化 z物理アプリケーション・モデルの定義 z研修およびユーザー・サポートの定義 z開発計画の作成 zサポート資料の作成 zテスト実施の準備 zプログラミング・サイクルの実施 z開発テストの実施 zシステム・テストの実施 z展開計画の作成 展開 展開 z受入れテストの実施 z本番環境のセットアップ zお客様側サポート体制の展開 z本番システムのサービスイン zソリューション計画のレビュー WAS V7 アプリケーション・デザインWorkshop Part2 このワークショップでは、Webアプリケーション開発のライフサイクルは以下の様なフェーズで構成さ れるものとします。ライフサイクルのフェーズ分けには他にも様々な方式がありますが、その場合は 適宜置き換えてください。 １．提案フェーズ お客様にシステムを提案するためのフェーズです。ここでは、提案書を作成するためにシステムの 概要を設計します。このフェーズは厳密には構築サイクルに入りませんが、Webアプリケーションを 開発する際には製品選定など重要な作業を行うので今回のワークショップでは対象フェーズの１つ として取り上げています。 ２．ソリューション・アウトラインフェーズ ソリューション・アウトライン（以下 SO）フェーズでは、詳細な要件を調査しシステムの全体設計しま す。要件定義フェーズと呼ばれるフェーズと同様の役割を果たします。 ３．マクロ設計フェーズ このフェーズでは各コンポーネントの概要を設計します。特に他コンポーネントとのインターフェー スを中心に設計します。外部設計フェーズと呼ばれるフェーズと同じ様な役割を果たします。 ４．マイクロ設計フェーズ このフェーズでは各コンポーネントの詳細を設計します。特にコンポーネントの内部を詳細に設計 します。内部設計フェーズと呼ばれるフェーズと同じ様な役割を果たします。 ５．構築サイクルフェーズ コーディング、単体テスト、結合／システムテストを実施します。ケースによっては構築サイクルを繰 り返えし実施する事もあります。 ６．展開フェーズ 実際にお客様に使用していもらい評価を行います。大きなシステムでは、システムを分割しマイク ロ設計以降のフェーズを繰り返すケースもあります。 8 01. Webアプリケーション設計概要 Webアプリケーション設計概要 Webアプリケーション設計作業（概要レベル） ソリューション・アウトライン （SO） 提案 お客様の要件 お客様の要件 調査 調査 お客様環境の お客様環境の 調査と分析 調査と分析 マクロ設計 マイクロ設計 テスト計画の作 テスト計画の作 成およびテスト 成およびテスト 仕様の作成 仕様の作成 テスト実施の テスト実施の 準備 準備 ソリューション ソリューション 概要の検討 概要の検討 ソリューション要 ソリューション要 件のアウトライン 件のアウトライン 作成 作成 システム概要 システム概要 検討 検討 アプリケーション・ アプリケーション・ モデルのアウトライ モデルのアウトライ ン作成 ン作成 要件およびアプリ 要件およびアプリ ケーション・モデルの ケーション・モデルの 洗練 洗練 ユーザー・インター ユーザー・インター フェースの設計 フェースの設計 アーキテクチャー・ アーキテクチャー・ モデルのアウトライ モデルのアウトライ ン作成 ン作成 開発管理製品 開発管理製品 の検討 の検討 9 開発／ビルド／ 開発／ビルド／ デプロイのフ デプロイのフ ロー設計 ロー設計 物理アプリケー 物理アプリケー ション・モデルの ション・モデルの 定義 定義 アーキテクチャー・ アーキテクチャー・ モデルの設計 モデルの設計 開発管理サー 開発管理サー バーの構築 バーの構築 WAS V7 アプリケーション・デザインWorkshop Part2 提案フェーズからマイクロ設計フェーズでのWebアプリケーション設計作業項目（概要レベル）です。 図の中にあるアプリケーション・モデルとは、クラス図など業務アプリケーションとデータに対する分 析・設計仕様を表現するモデルです。アーキテクチャー・モデルとは、コンポーネント・モデルなどエ ンタープライズ ・レベルのアーキテクチャーを表現するモデルです。 9 01. Webアプリケーション設計概要 Webアプリケーション設計概要 Webアプリケーション設計の成果物 提案 業務フロー/ 業務フロー/ 処理記述書 処理記述書 概要レベル 概要レベル ソリューション・アウトライン （SO） 業務フロー/ 業務フロー/ 処理記述書 処理記述書 システム構成 システム構成 アーキテクチャ アーキテクチャ 記述書 記述書 マイクロ設計 プロセス定義 プロセス定義 プロセス定義 プロセス定義 プロセス定義 プロセス定義 クラス図 クラス図 クラス図 クラス図 クラス図 クラス図 ユースケース ユースケース ・モデル ・モデル ユースケース ユースケース ・モデル ・モデル ユースケース ユースケース ・モデル ・モデル 非機能要件 非機能要件 定義 定義 非機能要件 非機能要件 定義 定義 システム・ システム・ コンテキスト コンテキスト システム・ システム・ コンテキスト コンテキスト コンポーネント コンポーネント ・モデル ・モデル コンポーネント コンポーネント ・モデル ・モデル コンポーネント コンポーネント ・モデル ・モデル シーケンス図 シーケンス図 シーケンス図 シーケンス図 UIガイドライン UIガイドライン 概念データ 概念データ モデル モデル 10 マクロ設計 UI設計仕様書 UI設計仕様書 トランザクション トランザクション 記述 記述 論理データ 論理データ モデル モデル 物理データ 物理データ モデル モデル WAS V7 アプリケーション・デザインWorkshop Part2 Webアプリケーション設計で作成する成果物の例です。上記は一例であり、プロジェクトにより異なり ます。 提案フェーズは、デリバリーフェーズではないので厳密には成果物はありません。 図中の成果物を結んでいる線は、概要レベルから始まりフェーズごとに内容をより詳細化していく作 業過程を表しています。 10 01. Webアプリケーション設計概要 Webアプリケーション設計概要 システムの層分割 プレゼンテーション層 ビジネス層 画面表示及びそのコントロールを担う フロントエンド層 画面表示 画面表示 画面生成 画面生成 入力データチェック 入力データチェック インテグ レーション 層 ビジネスロジックを実装する層 画面遷移コントロール 画面遷移コントロール 11 外部システム 外部システム セッション管理 セッション管理 コンポーネント間の 連携を行うのに必要 な機能の層 ルーティング ルーティング 非機能要件を実現する ための機能の層 開発関連項目 データベース データベース リソース層の呼び出し リソース層の呼び出し プロトコル変換 プロトコル変換 ワークフロー ワークフロー データアクセス データアクセス QoS層 システムで扱うデータを管 理する層 ビジネスロジック ビジネスロジック フォーマット変換 フォーマット変換 ビジネス層呼出しコントロール ビジネス層呼出しコントロール リソース層 アプリケーション管理 アプリケーション管理 認証 認証 アクセス制御 アクセス制御 メッセージ変換 メッセージ変換 バッチ バッチ 監査ログ 監査ログ メッセージング メッセージング イベント イベント サービス・インターフェース サービス・インターフェース トランザクション管理 トランザクション管理 エラー処理 エラー処理 キャッシュ キャッシュ 開発管理 開発管理 WAS V7 アプリケーション・デザインWorkshop Part2 このワークショップでは、システム内での各コンポーネントの役割と関係性を整理するために上記の 様な層分割を行います。それぞれの層の役割は下記の様になります。なお、層分割については上 記以外にも様々な層分割方法があります。 ・プレゼンテーション層 この層は、画面表示及びそのコントロールを担うシステムのフロントエンド層です。画面表示をコント ロールし、ビジネス層のロジックを呼び出す機能を持っています。この層では、クライアント側で表示 される画面の遷移を管理したり、必要に応じて単独もしくは複数のビジネス層のロジックを呼び出し たりします。その際、送受信するデータのチェックを実施したり、整形等のデータ操作も実施します。 また、セッション管理と言ったクライアント連携機能もこの層で実施します。 ・ビジネス層 この層は、業務の主要機能を実行するロジックで構成される層です。ロジックを実行するために必要 なリソース層の呼び出しも実施します。 ・リソース層 この層は、システムに必要なデータを扱うための層です。データを格納するためにデータベースやこ のシステムと連携する外部システムが該当します。 ・インテグレーション層 この層は、プレゼンテーション層、ビジネス層、リソース層を繋ぐためのインターフェースや機能の層 です。プレゼンテーション層とビジネス層を繋ぐWebサービスのインタフェースと言ったものが該当し ます。また、リソース層と繋ぐためのデータベースアクセス機能や各種システムと連携するためのメッ セージングもこの層にマッピングされます。 ・QoS層 QoS（Quality of Service）を実現するための機能の層です。この層の機能は、上記全ての層の機能 と連携して非機能要件を実現します。この層の代表的な機能は、認証／アクセス制御等のセキュリ ティーやトランザクション、キャッシュ等のパフォーマンスを向上させる機能があります。 ・開発関連項目 この部分はシステム層分割の範囲外です。システムを構成する機能ではなく、ワークショップで取り 上げる開発関連の項目となります。 11 01. Webアプリケーション設計概要 Webアプリケーション設計概要 ワークショップで取り上げる技術要素 プレゼンテーション層 Ajax（Dojo） Ajax（Dojo） ビジネス層 リソース層 PHP PHP // Groovy Groovy RDB RDB // XML XML DB DB // KVS KVS JavaBean JavaBean JSP JSP EJB EJB REST（JAX-RS） REST（JAX-RS） フレームワーク フレームワーク インテグ レーション 層 フレームワーク フレームワーク Webサービス Webサービス SCA SCA JDBC JDBC // ORマッパー ORマッパー イベント処理 イベント処理 Javaバッチ Javaバッチ 非同期処理 非同期処理 QoS層 開発関連項目 12 キャッシュ キャッシュ 認証／認可 認証／認可 アプリケーション管理 アプリケーション管理 メッセージング メッセージング エラー処理 エラー処理 トランザクション トランザクション 開発管理 開発管理 WAS V7 アプリケーション・デザインWorkshop Part2 上記は、前ページで示した層分割に、このワークショップで取り上げる技術要素をマッピングした図 です。 12 01. Webアプリケーション設計概要 Webアプリケーション設計概要 ３．Webアプリケーションの概要設計 13 WAS V7 アプリケーション・デザインWorkshop Part2 13 01. Webアプリケーション設計概要 Webアプリケーション設計概要 Webアプリケーション概要設計 ヒアリング（概要） 機能要件 ヒアリング（詳細） 非機能要件 機能要件 非機能要件 ソリューションの選定 ソフトウェア選定 システム概要 提案 提案 14 実装方式検討 洗練 実装方式の設計 システム設計 ソリューション・ ソリューション・ アウトライン アウトライン （SO） （SO） WAS V7 アプリケーション・デザインWorkshop Part2 Webアプリケーションの概要設計です。 提案フェーズでは、ヒアリング（概要レベル）を行い機能要件と非機能要件を整理します。そこからソ リューションを検討し、ソフトウェアの選定を行います。さらにサイジングを行いシステム概要を作成し、 お客様へ提案することになります。この段階で、システムの概要が決定してしまうので、特にソフト ウェア製品の選定は慎重に行う必要があります。 SOフェーズでは、提案フェーズで作成したシステム概要を元に、さらに詳細なヒアリングを行い実装 方式を検討しシステム設計を実施します。 14 01. Webアプリケーション設計概要 Webアプリケーション設計概要 非機能要件の検討 非機能要件の検討 • 非機能要件をどの様に実装するかを検討する。インフラだけでなく、アプリケーションも 合わせて実装させる方法もあるため、インフラと合わせて検討する必要がある。 – 耐障害性／信頼性 – サービス提供時間は？ 計画停止／計画外停止の許容時間はどのくらいか？ – 障害発生時のテイクオーバー構成は必要か？（同一処理能力／縮退） • 例 ： 信頼性向上のためSOAP/JMSの使用を検討 – 拡張性 – スケールアップか？ スケールアウトか？ – トランザクション量、データ量の増加はあるか？ • 例 ： 拡張性を考慮してDBにXML DB採用を検討 – セキュリティー – どの部分で暗号化が必要か？（通信／データ） – 認証・アクセス制御・監視が必要か？（ユーザーアクセス／データアクセス／ログ監視） • 例 ： Webサービス間でのend-to-endのセキュリティー確保のためWS-Securityを検討 – パフォーマンス／キャパシティ・プランニング – 同時ユーザー数は？ 想定トランザクション数は？（平常時／ピーク時） • 例 ： 応答時間を短縮するためパラレル処理を検討 – その他 • 15 バックアップ・リカバリー ／ 監視・システム管理 WAS V7 アプリケーション・デザインWorkshop Part2 要件には機能要件と非機能要件があります。非機能要件の実装方法にはインフラだけでなくアプリ ケーションも合わせて実現する方法もありますので、アプリケーション側でも早期に検討する必要が あります。 15 01. Webアプリケーション設計概要 Webアプリケーション設計概要 ソフトウェア選定のポイント 1/2 検討時期 提案フェーズ ・機能／非機能要件からどのソフトウェアで 実装するかを検討する。 ・一部の項目は実装方式の検討（仮決定）ま で行わないとソフトウェアが決定しない。 SOフェーズ ・ソフトウェアでの機能の実装方式を確定し、 実装方針／実装箇所などの設計を行う。 ・提案フェーズでソフトウェア選定が未決定 の部分は最終確定させる。 影響の大きいデシジョン・ポイント • システム構成／ソフトウェア選定に大きな影響を与えるため早期に検討する必要がある – 処理方式（同期／非同期／パラレル） • • 機能要件を実現するための処理方式を検討する 同時に非機能要件も考慮して使用する処理方式を決定し、ソフトウェアを選定する – 非機能件は主に信頼性、パフォーマンスを検討 – SOA • • • コンポーネントの再利用性を向上させるためSOA化するかを検討する Webサービスで実装する機能（ワークフロー等）／非機能要件によりソフトウェア選定が影響される 分散環境を採用する場合はシステム構成も検討する 次ページに続く 16 WAS V7 アプリケーション・デザインWorkshop Part2 ソフトウェア選定のポイントです。 ☆検討時期 ・提案フェーズ 主にシステムの要件をどのソフトウェアで実現するかを検討します。ソフトウェア選定においては、一 部の項目ではSOフェーズで行う実装方式の検討が必要となる項目があります。その場合は実装方 式の検討と仮決定を行い、SOフェーズで詳細検討を進めます。 ・SOフェーズ 詳細要件を調査し、提案フェーズで選定したソフトウェアを使用した実現方式の検討や設計を行い ます。 ☆影響の大きいデシジョン・ポイント 以下の様な項目は、システム構成／ソフトウェア選定に大きな影響を与えるため早期に検討する必 要があります。 ・処理方式（同期／非同期／パラレル） ・SOA （次ページに続く） 16 01. Webアプリケーション設計概要 Webアプリケーション設計概要 ソフトウェア選定のポイント 2/2 – データストア • 多くのケースではRDBが選択されるが、ケースによってはそれ以外の方式も採用される。方式を確 定させることによりソフトウェア選定が実施できる – イベント処理 • • イベントの処理パターン、非機能要件が重要なポイントとなる 他にも実績／開発生産性／コストも考慮する必要がある – バッチ • • 開発／オンラインシステムとの連携の観点からJavaバッチ採用の検討を行う Javaバッチを採用する場合は、コスト／開発生産性の観点からソフトウェア選定を行う – セキュリティー • 認証で他システムとの連携が必要であるかが重要なポイントとなる 17 WAS V7 アプリケーション・デザインWorkshop Part2 ☆影響の大きいデシジョン・ポイント （続き） ・データストア ・イベント処理 ・バッチ ・セキュリティー 各デシジョン・ポイントについての内容は、「４．アーキテクチャー・デシジョンのポイント － 提案 フェーズ」を参照してください。 17 01. Webアプリケーション設計概要 Webアプリケーション設計概要 サンプル：海外旅行予約システムの概要 旅行会社の海外旅行予約システム （販売担当者向け） ・販売担当者が海外パッケージ旅行の予約、及び予約状況の照会を実施 ・このパッケージ旅行は、ホテル、航空機を自由に選択可能 ・ホテルは旅行会社が一括購入、航空機は外部システムを利用してオンラインで実施 空室仕入れ 担当者 旅行情報及び空室情報を インターネット公開 旅行情報 検索 旅行 予約 販売担当者 予約状況 照会 連絡 旅行情報 空室 情報 予約通知 予約 情報 検索/予約 航空券 予約 システム 外部システム 海外旅行予約システム 18 ホテル ホテル WAS V7 アプリケーション・デザインWorkshop Part2 このワークショップで使用するサンプルシステムの概要です。 旅行会社の窓口販売担当者が、海外パッケージ旅行を予約処理するための社内システムです。こ の商品はホテルと航空機の便を自由に組み合わせる事が可能なパッケージ旅行です。このシステ ムは以下の機能を有しています。 旅行情報検索 ・・・ パッケージ旅行の内容、行き先、旅行会社が持っているホテルの空室情報を 検索 旅行予約 ・・・ パッケージ旅行の予約を実施。（ホテルと航空機を予約） 予約状況照会 ・・・ 予約された情報を参照。 ホテルの部屋は、旅行会社が一括確保して販売します。空室仕入れ担当者がホテルと交渉して空 室を仕入れます。仕入れられた空室はバッチでシステムの空室情報に反映されます。ホテル予約時 には、この空室を販売しホテル側には予約者の情報を送信します。 航空券は、既存の外部システムである航空券予約システム経由で検索／予約を実施します。予約さ れた情報は全て予約情報に反映されます。旅行情報（パッケージ旅行の内容、行き先、空き部屋） は、Web API を公開しインターネットからも自由に検索できます。 18 01. Webアプリケーション設計概要 Webアプリケーション設計概要 提案フェーズ ： システム概要 インターネット 予約Webアプリケーション・サーバー 外部システム ホテル ホテル SOAP 航空券 予約 システム SOAP /JMS データベース アクセス DB 予約状況 照会 クライアントPC 外部アクセス 旅行 予約 トランザクション管理 SOAP サービス・インターフェース アクセス制御 TAM フロントエンドコントロール 認証 旅行情報 検索 RDB KVS Ajax DB2 WXS IE 8 WAS バッチサーバー 空室仕入れ 販売担当者 空室仕入れ 担当者 19 WXD CG WAS V7 アプリケーション・デザインWorkshop Part2 提案フェーズでのシステム概要の例です。サンプルの海外旅行予約システムをWebサービス化した ものです。 上記に明示されていないデシジョン・ポイントとしては以下があります。 ・再利用性を考慮して、業務ロジックはWebサービス化する ・ユーザーの操作性向上を考慮して一部の画面でAjaxを採用 ・予約Webアプリケーション内では、全て同期処理で行われる ・トランザクション管理では、障害時引き継ぎのため共有ディスクを使用する ・空室／予約情報は、整合性を重視してRDBを使用。旅行情報は、パフォーマンスを重視して KVSを使用 ・バッチは、開発環境統一のためJavaバッチを使用。開発生産性を考慮してWXD CGを採用 ・外部システムは、既存を周到しSOAP Webサービスを使用。航空券予約システムは信頼性向上 のためSOAP/JMSを採用している 19 01. Webアプリケーション設計概要 Webアプリケーション設計概要 SOフェーズ ： システム詳細機能 プレゼンテーション層 ビジネス層 リソース層 セッション管理 ホテル 入力チェック 入力チェック サービス 呼び出し 画面表示管理 KVS 業務 ロジック フロントエンド 画面遷移 機能 管理 画面表示 業務 RDB 画面生成 航空券 予約 システム システム RDB 処理受付 インテグ レーション 層 SOAP Web サービス データ アクセス OR マッパー SOAP Web サービス メッセージ キュー Java バッチ 認証 QoS層 20 ユーザー レジストリ アクセス 制御 監査ログ 出力 エラーログ 出力 トランザ クション 制御 WAS V7 アプリケーション・デザインWorkshop Part2 SOフェーズで洗練化したシステムの詳細機能です。層分割の実施及び機能の詳細化を行っていま す。 20 01. Webアプリケーション設計概要 Webアプリケーション設計概要 SOフェーズ ： 使用するアーキテクチャー プレゼンテーション層 ビジネス層 リソース層 セッション管理 Dojo（Ajax） ホテル 入力チェック 入力チェック JavaBeans サービス 呼び出し 画面表示管理 KVS 業務 ロジック フロントエンド 画面遷移 機能 管理 業務 システム RDB RDB RDB フレームワーク 画面表示 航空券 予約 システム KVS 画面生成 処理受付 JAX-RS インテグ レーション 層 SOAP Web サービス JAX-WS データ アクセス OR マッパー 独自API JPA Java バッチ 認証 QoS層 21 TAM ユーザー レジストリ アクセス 制御 JavaEE 監査ログ 出力 Log4j SOAP Web サービス メッセージ キュー JAX-WS SOAP/JMS Javaバッチエンジン エラーログ 出力 トランザ クション 制御 Transaction API WAS V7 アプリケーション・デザインWorkshop Part2 前ページのシステム詳細機能に使用するアーキテクチャーをマッピングした図です。 21 01. Webアプリケーション設計概要 Webアプリケーション設計概要 SOフェーズ ： ソフトウェアへのマッピング プレゼンテーション層 ビジネス層 リソース層 セッション管理 WAS IE 8 WXS 入力チェック 入力チェック + サービス 呼び出し 画面表示管理 Dojo （FP Web2.0） 画面表示 ホテル WAS KVS 業務 ロジック 航空券 予約 システム FP Web2.0 フロントエンド 画面遷移 機能 管理 業務 RDB ＋ 画面生成 システム RDB DB2 Struts 処理受付 インテグ レーション 層 SOAP Web サービス OR マッパー JDBC 認証 22 メッセージ キュー WAS + Spring WXD CG QoS層 SOAP Web サービス ユーザー TAMレジストリ アクセス 制御 WAS 監査ログ 出力 Java バッチ エラーログ 出力 Log4j トランザ クション 制御 WAS WAS V7 アプリケーション・デザインWorkshop Part2 前ページに使用するソフトウェア（詳細）をマッピングした図です。 22 01. Webアプリケーション設計概要 Webアプリケーション設計概要 ４．アーキテクチャー・デシジョンのポイント － 提案フェーズ 23 WAS V7 アプリケーション・デザインWorkshop Part2 23 01. Webアプリケーション設計概要 Webアプリケーション設計概要 提案フェーズ ： デシジョン・ポイントのリスト 提案 デシジョン・ポイント No. カテゴリー 101 オープンソース使用の検討 全体 102 スクリプト言語によるアプリケーション開発の検討 全体 103 UIで採用するアーキテクチャーの検討 プレゼンテーション層 104 処理方式（同期／非同期処理／パラレル処理／イベント処理／バッチ処理）の検討 インテグレーション層 105 DB方式と製品の検討 リソース層 106 外部システムとの接続方式 リソース層 107 データストア領域の検討 システム構成 108 メモリー容量に関する検討 システム構成 109 キャッシュに関する検討 システム構成 110 バッチ製品の検討 インテグレーション層 111 認証の検討 QoS層 112 開発ツールの選定 開発関連 113 開発管理／テスト製品の選定 開発関連 24 WAS V7 アプリケーション・デザインWorkshop Part2 このページでは、提案フェーズで忘れずに検討して欲しいアーキテクチャー・デシジョンのポイントを リスト化してあります。主に製品選定、システム構成に関わるデシジョン・ポイントです。このリストの順 番はカテゴライズによる順番で、検討順序とは関係ありません。 各デシジョン・ポイントの内容は、次ページ以降で説明します。 24 01. Webアプリケーション設計概要 Webアプリケーション設計概要 提案フェーズ ： デシジョン・ポイント 提案 提案 101. オープンソース使用の検討 102. スクリプト言語によるアプリケーション開発の検討 お客様の要件調査 お客様の要件調査 103. UIで採用するアーキテクチャーの検討 104. 処理方式の検討 ソリューション概 ソリューション概 要の検討 要の検討 105. DB方式と製品の検討 106. 外部システムとの接続方式 110. バッチ製品の検討 111. 認証の検討 107. データストア領域の検討 システム概要 システム概要 検討 検討 108. メモリー容量に関する検討 109. キャッシュに関する検討 112. 開発ツールの選定 開発管理製品の 開発管理製品の 検討 検討 25 113. 開発管理／テスト製品の選定 WAS V7 アプリケーション・デザインWorkshop Part2 デシジョン・ポイントを提案フェーズでの作業項目にマッピングしたものです。 25 01. Webアプリケーション設計概要 Webアプリケーション設計概要 提案 WebSphere製品 ワークショップで説明するWebSphere製品 WAS FP SCA WAS FP Web 2.0 SCA 1.0をサポート ・SOAベースのコ ンポジッ ト・アプ リケーション WASにWeb 2.0の機能を追加 ・Dojo ・Webメッセージング ・JAX-RS WAS FP OSGi Applications and JPA 2.0 WXS ・最新JPA 2.0を実現 ・他にOSGiも実現可能 分散キャッシュによる 高速DBアクセスや KVSを実現する KVS RDB アプリケーションサーバー BPEL XML DB JPA SCA RESTful Webサービス XML アクセス 外部システム WPS BPELによるサー ビスのコンポジット を実現 WebSphere MQ 異機種間メッセージング基盤 WBE 高度なイベント処理を 容易に定義 イベントサーバー バッチサーバー イベント・ エンジン Java バッチ WXD CG Javaバッチを 実現 26 WAS FP XML XML関連の最新 仕様を実現 WAS V7 アプリケーション・デザインWorkshop Part2 このワークショップで取り上げているWebSphere製品です。 ・WAS Feature Pack Web 2.0 ・WAS Feature Pack SCA ・WAS Feature Pack OSGi Applications and Java Persistence API (JPA) 2.0 ・WAS Feature Pack XML ・WPS（WebSphere Process Server） V7.0 ・WebSphere MQ V7.0.1 ・WXS（WebSphere eXtreme Scale） V7.1 ・WXD CG（WebSphere Extended Deployment Compute Grid） V6.1 ・WBE（WebSphere Business Events） V7.0 26 01. Webアプリケーション設計概要 Webアプリケーション設計概要 【参考】 WAS V7 Feature Packとは WAS V7に特定のテーマに沿った最新機能を追加 – 拡張機能をアドオン ／ バージョンを上げずに新機能を追加 – WASのライセンスをお持ちのお客様に無償で提供 – Passport Advantageによる正式サポート対象 現在提供されているWAS V7 Feature Pack – Feature Pack for Web2.0 – Feature Pack for Dynamic Scripting – Feature Pack for OSGi Applications and Java Persistence API 2.0 – Feature Pack for Communications Enabled Applications – Feature Pack for SCA – Feature Pack for XML V7の現状機能を 維持したいお客様 Web 2.0をご利用 SCAをご利用にな になりたいお客様 りたいお客様 Web 2.0 Feature Pack SCA Feature Pack WebSphere V7.0 27 WAS V7 アプリケーション・デザインWorkshop Part2 WAS V7 Feature Packとは、特定のテーマに沿った最新機能を追加するためのアドオンです。 27 01. Webアプリケーション設計概要 Webアプリケーション設計概要 101. オープンソース使用の検討 提案 検討項目 101. オープンソース使用の検討 ／ 全体 検討内容 プロジェクト内でオープンソースのソフトウェアを使用することが可能かを検討する。 （製品内に組み込まれているものは別） 検討時期 提案フェーズ初期 選択候補 ①オープンソースを使用しない ②オープンソースを使用する 選択基準 製品として責任を持ったサポートをお客様が望む場合は、①使用しないとなる。 品質、サポート、問題の修正、将来のバージョンアップなどのリスクを承知の上で、開発期間の短縮や一定の品質の 確保のために②使用するを採用する。 考慮事項 ①の場合は、製品もしくは独自開発で該当部分を構築する必要があるため、コスト／期間への影響を考慮する必要 がある。②の場合は、リスクの観点からオープンソースの採用基準を検討する必要がある。 この選択は、製品選定や他のアーキテクチャー・デシジョンに大きく影響を及ぼすので、早期に確定する必要がある。 28 WAS V7 アプリケーション・デザインWorkshop Part2 提案初期にオープンソースのソフトウェアを使用するか検討します。 この項目は、主にお客様のシステムに対するポリシーで決まります。リスクを承知でオープンソースを 使用するか、サポートを重要視し製品／独自開発を行うかの方針をなるべく早期にお客様と合意を 得る必要があります。もし、オープンソースを使用する方針になった場合には採用基準も検討を行う 必要があります。 このデシジョンは、製品選定や他のアーキテクチャー・デシジョンに大きく影響を及ぼすので、早期 に確定する必要があります。 28 01. Webアプリケーション設計概要 Webアプリケーション設計概要 102. スクリプト言語によるアプリケーション開発の検討 提案 検討項目 102. スクリプト言語によるアプリケーション開発の検討 ／ 全体 検討内容 Webアプリケーション開発に、Java言語（JavaEE）を使用するか、スクリプト言語（PHP、Groovy）を使用するかを検 討する。 検討時期 提案フェーズ スクリプト言語を採用した場合、実行環境がWAS Feature Pack for Dynamic Scriptingとなり、システムの設計が大 きく変わってしまうため 選択候補 ①Java言語（JavaEE）による開発 ②スクリプト言語（PHP、Groovy）による開発 選択基準 多くの場合は、①Java言語を使用するが、以下の様な場合には、②スクリプト言語を採用する事も可能 ・シチュエーショナル・アプリケーションの開発 ・アジャイルな開発を実施する 考慮事項 WAS FP Dynamic Scriptingは、内部的にはWebSphere sMashと同等でWASのライセンスのみで使用可能。 ②スクリプト言語を採用した場合、WAS FP Dynamic Scriptingを使用する必要がある。その場合、高度なトランザク ション処理／高可用性を実現できない。また、外部システムとの接続方法が限定されてしまう。アーキテクチャーや開 発ツールも変わってきてしまう。 29 WAS V7 アプリケーション・デザインWorkshop Part2 WAS Feature Pack for Dynamic Scriptingを使用することによりスクリプト言語（PHP、Groovy）に よる開発が可能となります。スクリプト言語を採用することによりライトウェイトな開発が可能となります。 実態はWebSphere sMsahと同等で、WASのライセンスのみで使用可能です。ただし、WASとは構 成が大きく変わり制約事項もできてしまうので選択に当たっては十分な検討が必要となります。詳細 は、 WAS Feature Pack for Dynamic Scriptingのページを参照してください。 29 01. Webアプリケーション設計概要 Webアプリケーション設計概要 WAS Feature Pack for Dynamic Scripting 提案 WAS Feature Pack for Dynamic Scripting – Web 2.0 アプリケーションを構築するための軽量なWebアプリケーション・サーバー – WebSphere ｓMashと同機能 スピード 軽量かつ高速なアプリケーション開発 シンプル アプリケーションを素早く構築 Agility Web 2.0アプリケーションにマッチした実行環境 ◇動的スクリプト言語 ◇ REST、テンプレート、サービス・ライブラリ、コネクター ◇WebブラウザーもしくはEclipseによる開発 ◇RESTによるシンプルなインターフェース ◇アジャイル環境に最適化した素早い実行環境 ◇アプリケーションがサーバーである Application Server 戦略的、堅牢なアプリケーション アプリケーションで性質で使い分け Usage 「早く投入する」ことがより重要 Situational Applications Java Enterprise Edition FP Dynamic Scripting ☆実現できない事 ☆実現できない事 -SOAP -SOAPWebサービス Webサービスプロバイダー プロバイダー -2PCの様な高度なトランザクション -2PCの様な高度なトランザクション -クラスタリング環境での完全な高可 -クラスタリング環境での完全な高可 用性 用性 Dynamic Scripting Number of Applications 30 WAS V7 アプリケーション・デザインWorkshop Part2 WAS Feature Pack for Dynamic ScriptingはWASのFPの１つですが、他のFPとは多きく異なりま す。他のFPはあくまでも既存WASに対する機能の拡張ですが、このFPはWASをベースとしません。 実態は、WebSphere sMash（以下 sMash）と同等の実行環境となります。そのため、sMashと同様 に上記の様な特徴を持ちますが、同時にSOAPサーバーとなれない2PCトランザクションができない、 完全なクラスタ環境を構築できない、外部システムとの連携方法が限定されてしまうと言った制約が あります。また、JavaEEアプリケーションは実行不可なので、JavaEE用の既存モジュールの再利用 やオープンオープンソースも利用できないので注意してください（JavaSEのアプリケーションは稼動 可能です）。 30 01. Webアプリケーション設計概要 Webアプリケーション設計概要 103. UIで採用するアーキテクチャーの検討 提案 検討ポイント – 操作性が良くインタラクティブなUIを必要とするか検討する • 必要な場合は実装技術も選択する 選択肢 ①トラデショナルなWeb画面 ②Ajax ③その他のRIA ・HTML、CSSと簡単なJavaScript ・高度なJavaScript ・専用の技術 ・高い操作性を必須としない ・高い操作性を必要とする ・Webブラウザーのみで実現 ・高い操作性を必要とする ・別途実行環境が必要 ・パフォーマンス、開発ツールに 力を入れている物が多い ・開発生産性が高い ・従来の画面遷移を行う ・特別な仕掛けを必要としない ・パフォーマンス、ブラウザー間の 差異に注意 ・サーバーはRESTful Webサービ スで作成 ・製品選定を行う必要がある ・画面開発の難易度向上、開発／テスト工数の増加、必要とするスキルを考慮 する必要がある ・画面設計が従来と変わってくる部分がある 31 WAS V7 アプリケーション・デザインWorkshop Part2 最近では操作性の良いUI （ユーザーインタフェース）を求めるお客様が増えつつあります。お客様 の要件を満たすUIを構築にするために必要なアーキテクチャー／製品を選定します。 UIの操作性に高い要件がない場合は、 ①トラデショナルなWeb画面 を選択します。操作性が高くインタラクティブなUIを必要としている場合は、②Ajax か③その他 のRIAを使用します。ただし、これらを使用した場合、画面開発の難易度向上、開発／テスト工数の増加、必要とするスキルの違いが発生します。 ③その他のRIAを選択する場合には、この段階で要件に合わせて製品を選択する必要がああります。 （RIAに関しては次ページ参照） Ajax採用によるWebアプリケーションデザインへの影響は、「Ajax ＋ RESTful Webサービスによる 変化」のページ、及び「フロントエンド設計」セッションを参照してください。 31 01. Webアプリケーション設計概要 Webアプリケーション設計概要 【参考】 RIA 提案 RIA （Rich Internet Application） – インタラクティブ性が高く、ユーザーが使い易いWebアプリケーション・クライアント RIA Dojo（Ajax） ・RIAを作成するためのJavaScriptライブラリー ・OSSだがWAS FP Web2.0の機能として提供 ・主要なブラウザーでそのまま実行可能 ・便利なWidget（パーツ）を多数用意 AIR/Flex/Flash ・Adobeが開発したRIA及びコンテンツ技術 ・実行にはブラウザーのプラグイン、もしくは専 用ランタイムが必要 ・開発が容易 Silverlight ・Microsoftが開発したRIA ・実行にはIEのプラグインが必要 ・動画関連に優れている 32 ブラウザー JavaScript + Dojo HTTP HTML JavaScript 専用 フォーマット ブラウザー/ 専用ランタイム Flex/AIR /Flash ブラウザー WebSphere AS REST JSON or XML Silverlight WAS V7 アプリケーション・デザインWorkshop Part2 ここでは、主要なRIAの紹介をしています。 DojoはAjaxを利用しやすくするためのJavaScriptライブラリーです。オープンソースとして公開され ていますが、WAS FP for Web 2.0に組み込まれています。DojoはAjaxなので、Webブラウザーの みで利用可能です。 AIR/Flex/FlashとSilverlightは、実行環境の導入が別途必要です。 WASとの連携は、通常のHTTP/HTMLの他にRESTful Webサービスも使用します。Dojo以外は、 これ以外に専用の通信方法もありますが、その場合はサーバー側にその仕組みが別途必要になり ます。また、Dojo以外は専用フォーマットのファイルを使用することもあります。 32 01. Webアプリケーション設計概要 Webアプリケーション設計概要 104. 処理方式の検討 提案 検討項目 104. 処理方式（同期／非同期／パラレル／イベント）の検討 ／ インテグレーション層 検討内容 使用する処理方式を検討する。これらは、択一選択でなく複数選択が可能である。 同期処理は通常必須であり、必要に応じて他の処理方式も使用する。同期以外の処理方式を選択した場合は、実装 する製品の検討も行う必要がある。 検討時期 提案フェーズ 処理方式によりシステム全体のアーキテクチャーが大きく影響を受ける。また、処理方式によっては使用する製品も 選択する必要があるため提案フェースで実施する。 選択候補 ①同期処理 ②非同期処理 ③パラレル処理 ④イベント処理 選択基準 ①同期処理方式は必須。長時間処理等があり処理を分離したい場合は、②非同期処理を使用する。ユーザーに返 すまでの処理時間をトータルで短くしたい場合は、③パラレル処理を使用する。特定イベント発生時に処理を実施し たい場合は、④イベント処理を採用する。 考慮事項 ②－④を使用する場合、実装方式も考慮しないと製品選定が実施できないので、各処理方式の実装方式の方針も 検討する。 SOフェーズでは、それぞれの処理の対象とする業務の選定、詳細実装方式、実装箇所等さらに詳細に検討を詰め ていて確定していく必要がある。 詳細は、「サービス設計」、「イベント＆Javaバッチ設計」のセッションを参照。 33 WAS V7 アプリケーション・デザインWorkshop Part2 システム内で実現する処理方式を検討します。 製品へのマッピングは次ページを参照してください。詳細な情報は、「サービス設計」、「イベント＆ Javaバッチ設計」のセッションを参照してください。 33 01. Webアプリケーション設計概要 Webアプリケーション設計概要 処理方式と製品 同期処理 • 通常の処理方式 – WAS パラレル処理 • 処理時間短縮のための方式 – WAS – WebSphere MQ – WPS 提案 非同期処理 • 処理を分離する – WAS – WebSphere MQ イベント処理 • イベントの発生を通知する – WAS – WebSphere MQ – WBE (WebSphere Business Events) イベント 34 WAS V7 アプリケーション・デザインWorkshop Part2 各処理方式を実装できる製品です。 処理方式の実装方法には、各製品内で複数ある場合もあります。提案フェーズでは製品選定まで ですが、SOフェーズではさらに詳細な実装方式も検討する必要があります。 詳細は、「サービス設計」、「イベント＆Javaバッチ設計」のセッションを参照してください。 34 01. Webアプリケーション設計概要 Webアプリケーション設計概要 提案 105. DB方式と製品の検討 検討項目 105. DB方式と製品の検討 ／ リソース層 検討内容 システムで使用するDBの方式と製品をの検討を行う 検討時期 提案フェーズ 採用する方式により使用する製品が決まるため提案フェーズで検討 選択候補 ①RDB ②XML DB ③KVS （Key Value Store） 選択基準 大量のデータを整合性重視で処理する場合、通常の①RDB方式を採用する。 柔軟なデータ構造を取れるXML形式でデータを扱いたい場合は、XML DBを採用する。 整合性よりも処理性能を重視し、データ構造がキーバリュー型で問題ない場合はKVS方式を採用する。 また、複数の方式を採用しデータ項目の特性に合わせて使い分ける事も可能である。 考慮事項 検討するためには、データの特性を調査する必要がある。 処理方式により、データ分析手法、データアクセス方式、開発技術も違ってくるので、その点も考慮に入れて選択を 行う。 複数の方式を採用した場合は、インフラ構築や運用の工数が増加する点を考慮する。 次ページ及び「データ・アクセス設計」のセッションも参照。 35 WAS V7 アプリケーション・デザインWorkshop Part2 DB方式は、Webアプリケーションのデータ設計やシステム構成（製品選定）に影響を及ぼすため早 期に実施する必要があります。DB方式の主な選択候補としては、①RDB、②XMLDB、③KVSがあ ります。 選択ポイント等は次ページを参照してください。 35 01. Webアプリケーション設計概要 Webアプリケーション設計概要 提案 DB方式の選定 選定ポイント – 重要視する機能 RDB 整合性 • 整合性／拡張性／可用性／ パフォーマンス／保守性 – 影響ポイント • • • • データアクセス方式 データ分析手法 開発技術 既存データ移行 DB2 XMLDB 拡張性 DB2 KVS – 考慮点 • 既存データがある場合は移行可能か？ • 使用したいフレームワークがあるか？ 可用性 パフォーマンス WXS（WebSphere eXtreme Scale） 36 WAS V7 アプリケーション・デザインWorkshop Part2 DB方式を検討するには、データ特性を調査し、重要視する機能を見極わめる必要があります。その 上でDB方式を決定しますが、複数の方式を同時に使用することも可能です。その場合、SOフェー ズでどのデータがどの方式を使用するのか確定する必要があります。 多くの場合は、整合性が重要視されDB2によるRDB方式が選択されます。データ構造に柔軟性を 持たる等の理由によりXMLデータ形式を使用する場合はDB2のXML DB方式が選択されます。より パフォーマンス重視でデータ構造がキーバリュー型で問題ない場合はWXS（WebSphere eXtreme Scale）のKVS方式を採用します。 DB方式によって、データアクセス方式、データ分析手法、開発技術が影響を受けますが、DB方式 を選択することにより自動的に決まってくるものなので、選択時には影響ポイントよりも重要視する機 能の方をメインに選定します。ただし、既存データがあり移行が必要な場合移行が可能であるかを 検討する必要があります。また、データアクセスで使用したいフレームワークやツールがある場合は、 それが対応しているDB方式を選択することになります。 詳細は、「データ・アクセス設計」のセッションを参照してください。 36 01. Webアプリケーション設計概要 Webアプリケーション設計概要 106. 外部システムとの接続方式 提案 検討項目 106. 外部システムとの接続方式 ／ リソース層 検討内容 外部システムとの接続方式を検討する。また、接続方式によっては実装製品の検討を行う必要がある。 検討時期 提案フェーズ 選択候補 ①Gatewasy接続（Gatewayでプロトコル変換を行う） ： 各種製品から選定 ②DB連携 ： DB2 ③ファイル転送 ： 各種製品から選定 ④Webサービス ： WAS ⑤MQ接続 ： WebSphere MQ 選択基準 既存の外部システムと接続する場合、接続方式が決まっている事が多いのでその方法で実装する製品の選定を行 う。決まっていない場合は、外部システム側担当者とシステムの特性を考えながら検討を実施する。 プロトコル変換が必要な場合は①Gatewasy接続を行うが、対象プロトコルに変換するコンポーネントが必要になる。 ②DB連携では簡単にデータの連携を行う事が可能だが、両システムでデータの整合性を考慮する必要がある。バッ チ処理的な連携を行う場合は③ファイル転送を採用すると疎結合が行える。外部システムにMQインターフェースが ある場合は⑤MQ接続を、Webサービスインターフェースがある場合は④Webサービスでの連携を行う。 考慮事項 上記は主な接続方式で他にも接続方式はある。外部システムが既にある場合はその方式を使用し、そうでない場合 は、上記の方式から選択する。 ①と③については、複数の製品が存在し、実現する内容に応じた製品を選定する必要がある。 37 WAS V7 アプリケーション・デザインWorkshop Part2 ここでは、外部システムとの接続方式の検討と製品選定について述べています。 ①Gatewasy接続（Gatewayでプロトコル変換を行う） ： 各種製品から選定 ②DB連携 ： DB2 ③ファイル転送 ： 各種製品から選定 ④Webサービス ： WAS ⑤MQ接続 ： WebSphere MQ 37 01. Webアプリケーション設計概要 Webアプリケーション設計概要 外部システムとの接続方式の検討ポイント 提案 必要な変換を実行できる製品が必要 Gateway データ送受信 ・プロトコル変換 ・フォーマット変換 データ送受信 データの整合性 データ書き込み ／読み込み データ書き込み ／読み込み DB バッチ処理的に使用 WAS ファイル転送 インターオペラビリティー SOAP Webサービス 外部システム MQが必要 メッセージの get/put MQ 38 メッセージの get/put WAS V7 アプリケーション・デザインWorkshop Part2 前ページで挙げた外部システムとの接続方式を図示したものです。それぞれの方式には以下の様 な検討ポイントがあります。 ①Gatewasy接続 ： 必要な変換を実行できる製品が必要 ②DB連携 ： データの整合性を考慮する必要がある ③ファイル転送 ： バッチ的な処理で使用する ④Webサービス ： インターオペラビリティーを考慮する必要がある ⑤MQ接続 ： 両方がWebSphere MQを使用する環境が必要になる 38 01. Webアプリケーション設計概要 Webアプリケーション設計概要 107. システム・データストア領域の検討 ポイント ・下記項目の使用方法によって、必要と なるデータストアが変わってくる 選択肢 ①ローカル ディスク トランザクション ・2PCを実施する場合は、トランザクションログを書き込む 先が必要となる ・①ローカルディスクでも可能だが障害時にトランザクショ ンログの引継ぎが必要な場合は②共有ディスクが必要 となる ②共有 ディスク サーバーの一部で安価。 高可用性は構成による。 他のサーバーと共有できない。 高速で高可用性構成にする事ができる。 複数のサーバーで共有可能。 構成方法を検討する必要がある。 忘れずに検討 ③システム DB メッセージング ・メッセージングのパーシスタンスで、データストア領域が 必要となる ・障害時の引継ぎが必要なければ①ローカルディスク。 引継ぎが必要なら②共有ディスクか③システムDB ログ ・通常は①ローカルディスクだが、ログを集中管理するた めに②共有ディスクか③システムDBのケースもある 提案 DBMSを利用する。 複数のサーバーで共有可能。 ①、②に比べコスト、パフォーマンス で考慮が必要。 セッション ・メッセージングのパーシスタンスの方式に よってはデータストア領域が必要となる ・WASでは③システムDBを使用する 39 WAS V7 アプリケーション・デザインWorkshop Part2 特定の機能の使用方法によっては、システム用データストア領域が必要となる場合があります。デー タストア領域の選択肢としては、以下の３つがあります。特に②共有ディスクはシステム構成に追加 する必要があるので提案フェーズで忘れずに検討する必要があります。また、ここでは取り上げてい ませんが、これらのデータストア領域は使用量を検討して容量を見積もる必要があります。 ①ローカルディスク マシンに付属のHDDに書き込みます。RAID等の高可用性構成がされていない場合も多いのでそ の点は注意が必要です。また、そのままでは他のサーバーと共有できません。 ②共有ディスク ローカルディスクをNFS等で簡単に共有する方法から、専用の外部ディスク装置を使用する方法ま で様々です。方法により速度、高可用性、保守性が大きく変わりますが、コストが大きく変わります。 システム構成も影響を受けるため、提案フェーズでどの様な方法で構成するか検討する必要があり ます。 ③システムDB データストアにDBMSを利用します。当然複数のサーバーから共有可能です。単純にデータを書き 出すだけだとDBMSが稼動する分だけオーバーヘッドがありますが、検索／更新／削除がある様な ケースではトータルで有利なります。アプリケーションDBと共有することが可能ですが、パフォーマン ス上問題がないか検討が必要です。 下記の項目は使用方法によってはデータストア領域が必要となるので、提案フェーズで検討をする 必要があります。 ・トランザクション ： 2PCを使用 ・メッセージング ： メッセージングのパーシスタンスを実施 ・ログ ： 必ずデータストアを使用 ・セッション ： セッションのパーシスタンス 39 01. Webアプリケーション設計概要 Webアプリケーション設計概要 108. メモリー容量に関する検討 提案 検討項目 108. メモリー容量に関する検討 ／ インフラ 検討内容 WASで使用するメモリー容量を検討する必要がある 検討時期 提案フェーズ WASで使用するシステム構成に影響を与えるため提案フェーズで実施する 選択候補 N/A 選択基準 WASのメモリー容量は以下の3点が大きく影響するため、この3点を中心に検討を進める。 ①セッション 通常のWebアプリケーションでは、HTTPセッションに格納されるデータが一番メモリーを使用する。メモリー容量は、 「セッション数 × （1セッションの）データ量」となる。提案フェーズでデータ量を算出するのは難しいため仮のデータ量 を決め、それを設計時の制約する方法もある。 ②キャッシュ WASのキャッシュ機能を使用する場合は、キャッシュ容量を検討する。一般的にはキャッシュ容量が多いほどキャッ シュのヒット率があがり、パフォーマンスが向上する。 ③大容量データ １００MB単位の様な大容量データをWASで扱う場合は、処理内でどの程度メモリーが必要か検討する。 考慮事項 2GB超のメモリーが必要になる場合は、WAS 64bit版を使用するか、アプリケーション・サーバー（JVM）分割する必 要があり、システム構成に影響を与える。 40 WAS V7 アプリケーション・デザインWorkshop Part2 上記は、WASのメモリー容量に関する検討について記述しています。セッション、キャッシュ、大容 量データ使用でメモリー使用量が多くなる場合は、JVM分割を検討しなければいけないケースもあ るので、注意が必要です。 40 01. Webアプリケーション設計概要 Webアプリケーション設計概要 109. キャッシュに関する検討 提案 キャッシュに関する検討 – キャッシュするポイントを検討 • ユーザーに近いほど効果的だが、キャッシュの単位や更新を考慮する必要がある • 提案フェーズでは使用するキャッシュの選定を行いシステム構成を決める WAS ブラウザー Proxy Server JavaScriptや、ブラウ ザーの機能によるキャッ シュ。非常に高速で、複 数の画面で同じデータ を繰返し使用する場合 に有効。 キャッシュはファイル単 位となるため、静的な コンテンツ、更新頻度 が少ないデータで使用 される。 実行結果／オブジェクト単位での キャッシュを行う。 WXS Servlet/JSPキャッシュ データをオブジェクトと してキャッシュする。 Webサービスキャッシュ コマンドキャッシュ オブジェクトキャッシュ ブラウザー Proxy Server 41 WAS DB WXS (WebSphere eXtreme Scale) WAS V7 アプリケーション・デザインWorkshop Part2 パフォーマンスを向上させる有効な方法の１つとしてキャッシュがあります。キャッシュは複数の箇所 で実装できるので、どの箇所でどういったデータをキャッシュさせるかを見極めることが重要です。な るべくユーザーに近い部分でのキャッシュが効果的ですが、更新を適切に行うためにはデータによ り最適なキャッシュポイントは変わってくるのでキャッシュの単位が重要になります。キャッシュによっ てはアプリケーションの設計に影響を及ぼすものがあるので、インフラチームと共同でどのキャッシュ を使用するのかを検討する必要があります。 Proxy Serverは、WASと別のサーバーにすることも同一サーバー上に構築する事も可能です。 WASでは、４つのキャッシュの機能があります。 Servlet/JSPキャッシュ、Webサービスキャッシュはそれぞれの実行結果をキュッシュします。Web サービスキャッシュではJAX-RPCのみ使用可能で、JAX-WSでは使用できません。 コマンドキャッシュはコマンドパターンで作成したオブジェクトをキャッシュします。オブジェクト キャッシュは専用のAPIでコーディングされたオブジェクトをキャッシュします。両者ともキャッシュする 単位を考慮して設計する必要があります。 WXS(WebSphere eXtreme Scale)では、DBへの検索をキャッシュします。キュッシュの単位が最 小になるため、必要な物だけキャッシュ可能となります。 提案フェーズでは、使用するキャッシュを選定します。Proxy ServerやWXSを使用する場合は専用 のノードに配置することも可能なのでシステム構成に影響を与えます。SOフェーズでは使用する キャッシュの種類と配置場所を詳細に検討します。マクロ設計フェーズでは、キャッシュするデータ の洗い出しや更新タイミングの検討を行います。特に更新タイミングは画面遷移全体を見て矛盾が 発生しないように綿密に設計する必要があります。 41 01. Webアプリケーション設計概要 Webアプリケーション設計概要 1１0. バッチ製品の検討 提案 検討項目 113. バッチ製品の検討 ／ インテグレーション層 検討内容 バッチ処理に関して以下の検討を行う。 ・実装方法及び製品 検討時期 検討フェーズ 選択候補 ① シェル 及び ネイティブアプリ ② Javaバッチ - JavaSE／JavaEE上に独自実装 ③ Javaバッチ -オープンソース ④ Javaバッチ - WXD CG(WebSphere Extended Deployment Compute Grid） 選択基準 バッチは、処理方式によりオンラインバッチ、オフラインバッチに分かれる。多くのWebシステムでは両方の方式を採 用し使い分けている。方式ごとに実装方法を変える事も可能である。 実装方法としては、大きく2つに分かれる。パフォーマンスや開発容易性を重視する場合は従来の①シェル 及び ネイ ティブアプリの方式もある。Javaバッチを使用した場合、WASのJava環境が生かせるのでスキルの共有、アプリとの コードの共有等開発の面でメリットがある。Javaバッチ場合、Java環境だけで実装する方法と、バッチ実行環境用の オープンソースや製品を使用する方法がある。これらの選択基準については、 「イベント & Javaバッチ 設計」セッ ションを参照。 考慮事項 ジョブのスケジューリングを行う場合、TWS（Tivoli Workload Scheduler ）等のスケジューラー製品も検討する必要 がある。 42 WAS V7 アプリケーション・デザインWorkshop Part2 Javaのパフォーマンスが向上され、Javaバッチ環境の整備も整備されてきたため、最近ではJavaで バッチを作成するケースも増えてきています。Javaバッチは、WASとの開発環境／スキルの統合を 図れるのでトータルでの開発生産性を向上させることができます。 バッチの方式、実装方法及び製品についての詳細は、「イベント & Javaバッチ 設計」セッションを 参照してください。 42 01. Webアプリケーション設計概要 Webアプリケーション設計概要 111. 認証の検討 提案 ポイント – 既存の仕組みがある場合は、連携方法を検討 – 認証サーバーの検討 • – 使用する認証リポジトリー • 認証リポジトリー 他のシステムとの連携が必要か検討 OS LDAPサーバー ファイル WAS管理のファイル内でユーザー管理 WASでのみ使用可能 LDAP サーバー LDAPサーバーによるユーザー管理 通常はLDAPサーバーを使用 別途サーバーが必要 製品例 ： Tivoli Directory Server WAS WASのみで認証を行うパターン ・別の認証製品が必要ない ・LDAPサーバーは別途必要 ・SSO（Single Sign On）も可能 認証サーバーとしてTAMを使用して認証を行うパターン ・WAS以外の複数のシステムの認証 を集中して行える その他 ・Policyサーバーによる集中的な管理が システム が可能 TAM OSのユーザー認証の機能を使用 WAS Base構成でのみサポート LDAP サーバー TAM Policyサーバー WAS 認証サーバー 43 WAS V7 アプリケーション・デザインWorkshop Part2 認証の実現方式を検討します。既存の認証システムがある場合は、その方式に合わせた方式を採 用します。 新規に構築する場合は、大きく分けてWASで認証を行うパターンと、別途認証サーバーを構築して そこで認証を集中的に行うパターンがあります。WASのみで認証を行う場合は使用する認証リポジ トリーを選択する必要がありますが、ユーザー管理を共通化するため通常はLDAPサーバーを選択 します。既存LDAPサーバーがない場合は、Tivoli Directory Serverなどを使用して別途構築する 必要があります。 認証サーバーの使用は、他システムとのSSO（Single Sign On）が必要な場合に行います。WASの みでもSSOは可能ですが、認証処理を集中管理できる点では専用認証サーバー製品が優れてい ます。TAM（Tivoli Access Manager）を採用した場合は認証サーバー、LDAPサーバー、Policy サーバーが必要になります。 43 01. Webアプリケーション設計概要 Webアプリケーション設計概要 112. 開発ツールの選定 提案 検討項目 112. 開発ツールの選定 ／ 開発関連 検討内容 開発ツールの選定を行う。 検討時期 提案フェーズ 製品選定があるため提案フェーズで実施。納品物ではないがオープンソースを使用するケースもあるため、101.オー プンソース使用の検討を事前に行う必要がある。 選択候補 ①RAD （Rational Application Developer for WebSphere Software） ②WASに付属のアセンブルツール ③eclipse 選択基準 開発支援機能、開発管理製品との連携。 ①RAD 各種アプリケーション開発ウィザード等の開発生産性を向上させる開発支援機能や、チーム開発製品と連携する機 能を利用することが可能となる。また、ローカル環境でのWASを使用したテストを実施することが可能となる。 ②アセンブルツール WASに付属するツールで、①RADから便利な開発支援機能などのが省かれたツール。WASライセンスを所有して いる場合は、そのWAS向け開発で自由に使用することが可能。 ③eclipse コストや独自拡張を重要視する場合は選択することも可能だが、各種プラグインを整備して開発環境を整える必要が ある。また、単体テスト時にWASが使用できない点を工夫する必要がある。 考慮事項 44 WAS V7 アプリケーション・デザインWorkshop Part2 開発ツールの選定についてです。 44 01. Webアプリケーション設計概要 Webアプリケーション設計概要 113. 開発管理／テスト製品の選定 提案 検討項目 113. 開発管理／テスト製品の選定 ／ 開発関連 検討内容 開発管理／テストを行う製品を選定する。 ・ソースコード管理 ・コードビルド ・問題管理 ・各種テスト 検討時期 提案フェーズ 製品選定があるため提案フェーズで実施。納品物ではないがオープンソースを使用するケースも多いため、101. オープンソース使用の検討を事前に行う必要がある。 選択候補 選択候補は「アプリケーション開発管理」セッションを参照。 選択基準 機能、操作性、情報の入手容易性、運用コスト、ツール間の連携、既存スキルの活用などと言った点を総合的に考 慮して製品選定を行う。ただし、ライセンス料金を重要視し、メジャーなオープンソースを選択する事もある。 考慮事項 詳細については、「アプリケーション開発管理」セッションを参照。 45 WAS V7 アプリケーション・デザインWorkshop Part2 開発管理、テスト製品の選定を行います。 詳細は、「アプリケーション開発管理」セッションを参照してください。 45 01. Webアプリケーション設計概要 Webアプリケーション設計概要 ５．アーキテクチャー・デシジョンのポイント － SOフェーズ 46 WAS V7 アプリケーション・デザインWorkshop Part2 46 01. Webアプリケーション設計概要 Webアプリケーション設計概要 SOフェーズ ： デシジョン・ポイント SO ソリューション・アウトライン （SO） お客様環境の調 お客様環境の調 査と分析 査と分析 202. Ajax利用パターンの検討 203. REST実装方式の検討 201. Ajax ツールの検討 204. プレゼンテーション層の実装技術を検討 ソリューション要 ソリューション要 件のアウトライン 件のアウトライン 作成 作成 214. Webサービスのインターオペラビリティー検討 205. 非同期処理の処理パターン、実装方式の確定 217. データアクセス方式の検討 206. パラレル処理の実装方式の確定 207. サービス実装方式の検討 アプリケーショ アプリケーショ ン・モデルのアウ ン・モデルのアウ トライン作成 トライン作成 アーキテク アーキテク チャー・モデルの チャー・モデルの アウトライン作成 アウトライン作成 208. ビジネスロジック実装方式の検討 209. インターフェース実装方式の検討 210. コントローラー実装方式の検討 211. 大容量ファイル転送方式の検討 212. Webサービスのトランザクション検討 213. Webサービスのセキュリティー検討 215. イベント処理の実装の設計 216. Javaバッチの設計 開発／ビルド／ 開発／ビルド／ デプロイのフ デプロイのフ ロー設計 ロー設計 47 218. アプリケーション更新／バージョニングに関する検討 219. 開発－デプロイのフローに関する検討 ／ 開発関連 WAS V7 アプリケーション・デザインWorkshop Part2 デシジョン・ポイントをSOフェーズでの作業項目にマッピングしたものです。 47 01. Webアプリケーション設計概要 Webアプリケーション設計概要 フレームワークの選定 SO フレームワーク 使用理由 ： 開発生産性の向上と品質の統一 選定ポイント ： ・標準を重視するか、実績のあるオープン技術か ・プロジェクトで必要とする機能 プレゼンテーション層 インテグレーション層 ビジネス層 プレゼンテーション ビジネスロジック O/Rマッピング ・リクエスト処理の受付 ・画面処理コントロール Spring Spring (Web) (Web) ・DBへのアクセス処理 Spring Spring (Core) (Core) ＊1 ＊1 JPA JPA EJB EJB 3.0 3.0 Struts Struts Hibernate Hibernate DI/AOP JSF JSF ・インスタンス管理、接続プール、参照の注入、 トランザクション制御 オールインワン 48 Spring Spring Framework Framework RDB JavaEE JavaEE iBATIS iBATIS ＊2 WACs WACs WAS V7 アプリケーション・デザインWorkshop Part2 SOフェーズでは、Webアプリケーション開発に使用するフレームワークを選定します。 多くのWebアプリケーションでは何らかのフレーワークを使用して開発されます。フレームワークを採 用した場合、そのフレームワークに合わせたアプリケーションの設計が必要になるので、フレーム ワークの選定はSOフェーズで行っておく必要があります。 プレゼンテーションフレームワークに関しては、「フロントエンド設計」セッションを参照してください。 DI/AOPフレームワーク、O/Rマッピングフレームワークの部分に関しては、以前実施されたWAS V7 Webアプリケーション・デザイン Workshop の「フレームワーク」セッションを参照してください。 *1 ： Spring (Web) と Spring (Core)は、Spring Framework の構成要素の一機能です。 個々の部分の説明をするためにこの様な表記にしてあります。 *2： iBATISは開発が終了しています。2010/5にMyBatisが実質的な後継としてスタートしています。 48 01. Webアプリケーション設計概要 Webアプリケーション設計概要 WAS V7におけるフレームワーク選択指針 プレゼンテーション フレームワーク SO 標準重視 or オープン技術 － JSFは標準、Struts／Spring (Web)はオープンソース 成熟度・実績 － 実装の成熟度・実績では、(かなり)Strutsがリードしているが最近更新されていない StrutsとJSFの共存は可能。 O/Rマッピング フレームワーク 標準重視 or オープン技術 － JPAは標準、Hibernate/iBATISはオープンソース 成熟度・実績 － 実装の成熟度・実績では、(若干)Hibernateがリード － Hibernate 3.5ではJPA 2.0をサポートしている SQLの生成 － SQL文をより自由にチューニングしたい場合に、iBATISが向いている DI / AOP フレームワーク 標準重視 or オープン技術 － EJB3.0は標準、Springはオープンソース 成熟度・実績 － 実装の成熟度・実績では、Springがリード 分散システムの構築 －分散システムを構築する場合は、EJB 3.0 ・標準を重視するか、実績のあるオープン技術を選択するかを念頭に置き、 プロジェクト要件とフレームワークの特性を突き合わせる ・WAS V7では、Java標準であるJSF/EJB/JPAも十分な選択肢である 49 WAS V7 アプリケーション・デザインWorkshop Part2 WAS V7でのフレークワークの選択指針をまとめたページです。 WAS V7におけるフレームワーク の選択指針は、「標準を重視するか、実績のあるオープン技術を選択するかを念頭に置き、プロジェ クト要件とフレームワークの特性を突き合わせる」です。JDK1.4の時代と異なり、JavaEE 5である WAS V7ではJSF/EJB/JPAも十分な選択肢となります。アーキテクチャーだけを考慮すれば、オー プンソースよりも優れている標準のフレームワークもあります。また、今後は標準とオープンソースの フレームワークを組み合わせた事例も増えていくと思われます。 標準技術を採用した場合、WAS V7がその機能を実装しているので別途ソフトウェアを用意する必 要がありません。また、RADでも標準技術の開発支援機能が充実していますので、その点も考慮に 入れる必要があります。 49 01. Webアプリケーション設計概要 Webアプリケーション設計概要 【参考】 EJB 3.0 / Spring (Core)特徴比較 項目 EJB3.0 SO Spring (Core) サポート・開発 JCPで規定された標準。仕様は主要なJ2EEサーバー・ベンダーなど の関係者が合意。実装は各J2EEサーバー・ベンダーがサポート。 オープンな(Interface21 Inc)開発、管理。非標準 主目的 エンタープライズ・サービスに必要となる機能をコンテナとして提供す ることを目的とし、開発・テスト容易性にも対応 Dependency Injection (DI)をベースとしたアーキテクチャーによる、 軽量、開発/テスト容易なフレームワーク DBアクセス EJBの仕様として、JPAを使用 他のO/Rマッピング・ツールとの統合が容易(JPAもそのうちの一つ) トランザクション JTAトランザクション・マネージャーを使用 JTAトランザクション・マネージャーだけでなく、Spring独自や、O/R マッピング・ツールが提供するトランザクション・マネージャーも使用 可能 セキュリティ アノテーションまたはDDによる宣言的セキュリティーをサポート 宣言的セキュリティーをサポートするオープンソースのAcegiフレー ムワークとの統合をサポート リモートアクセス リモート・アクセスを主要な機能の一つとし、トランザクションやセキュリ ティー属性の伝播も可能 フレームワークとしては、もともとリモート・アクセスは重視していな い テスタビリティー ほとんどのコンポーネントは、コンテナ外でテスト可能 すべてのコンポーネントをコンテナ外でテスト可能 DI Java EE の特定の型 (EJBやデータソースなどのリソース) 任意のPOJOをInjection可能 AOP EJB (Beanまたはメソッド) のみがスコープ 任意のPOJOをスコープとできる 設定の特徴 アノテーションを多用(DD(XML)での設定も可) XMLの構成ファイルを多用(アノテーションでの設定も可)。 成熟度 まだ、実装は広くは使われていない 広く使われている 連携 ・MVCフレームからはEJB 3.0 APIを使用して呼び出し可能 ・O/Rマッピングフレームワーク呼び出しの制限はない。 ・Struts／JSFとの連携機能を提供。また、別の方法で構成を手作 業で行うことも可能。 ・JPA、Hibernate、iBATISを呼び出す機能を提供。 50 WAS V7 アプリケーション・デザインWorkshop Part2 EJB 3.0 / Spring (Core)の特徴比較です。 50 01. Webアプリケーション設計概要 Webアプリケーション設計概要 【参考】 JPA / Hibernate / iBATIS特徴比較 SO JPA （OpenJPA） Hibernate iBATIS 特徴 Hibernateの影響を強く受けた JCP標準 JavaEE5へ移行を予定している 場合JPAを選択する Open JPAは、JPAを実装した実 行環境でWAS V7のJPA実装の ベースとなっている 機能が豊富にあり、オブジェクトクエリ言 語の「HQL」や、シンプルで扱いやすい APIを提供 アノテーション機能がないJDK1.4環境を 利用している場合、Hibernateを選択する。 最新版は、JPA をサポートしているので JPAの実行環境としても使用可能。 SQL文をマッピングファイルに記述 2010年5月で開発終了宣言。実質的な 後継としてMyBatisを立上げ、今後はそ ちらを開発していく様であるので注意が 必要 メリット Hibernateに準じる Javaの標準 アノテーションでO/Rマッピングを 定義する 機能が豊富 Java開発者は、関連を意識しなくてもよ い SQLレスの開発ができる 永続化オブジェクトクラスのコードから、 O/Rマッピング定義を分離する SQLの機能が生かせる パフォーマンスチューニングなどの柔軟 な対応が可能 デメリッ ト Hibernateに準じる 実績が少ない 関連を多用するとパフォーマンスに影響 習得に時間が必要 マッピング･ファイルにSQL文を記述する ため、マッピング･ファイルの管理が煩雑 になる 情報が比較的少ない 項目 51 WAS V7 アプリケーション・デザインWorkshop Part2 JPA / Hibernate / iBATISの特徴比較です。 51 01. Webアプリケーション設計概要 Webアプリケーション設計概要 SO RESTful Webサービス 1/2 RESTful Webサービス – サーバーにあるリソース（情報の断片）に対してオペレーションを実行する（リソース指向） • 各リソースは、ユニークなURL により識別 • ステートレス（アプリケーション状態を持っていない） • HTTPを利用した統一インターフェース – 処理命令はHTTPメソッドを使用 – 処理結果はHTTPステータスコードを使用 – 状態の遷移をハイパーメディアで表現 – HTMLだけでなくXMLやJSON、RSS/Atomも使用 リソース： Aさんの社員情報 URL ： http://xxx.com/employee/A GET http://xxx.com/employee/A Aさんの 情報を取得 HTTP JSON Aさんの情報 リクエスター PUT http://xxx.com/employee/A XML Aさんの 情報を更新 HTTP リクエスター 52 Aさんの 社員情報 Aさんの情報 プロバイダー WAS V7 アプリケーション・デザインWorkshop Part2 RESTful Webサービスとは、RESTの考え方に基づいたWebサービスです。SOAP Webサービス と違いURLでリソース（情報の断片）を表し、HTTPのメソッドを使用してリソースを操作します。デー タフォーマットはJSONが使用されることが多いですが、XMLやRSS/Atomも使用する事があります。 52 01. Webアプリケーション設計概要 Webアプリケーション設計概要 SO RESTful Webサービス 2/2 リクエスト レスポンス – HTTPメソッドを使用 – HTTPステータスコードを使用 • よく使用されるHTTPステータスコード GET リソースの取得 POST リソースの追加 PUT リソースの更新 DELETE リソースの削除 HEAD リソースのメタデータ取得 • その他のメソッドもあるがあまり使用されな い • POST は要注意 – 全てをPOSTで処理しない – データが2重追加される可能性がある GET /employee/A HTTP/1.1 HTTP1.1 200 OK リクエスター 53 プロバイダー 200 正常終了 201 リソースの新規作成に成功 202 要求は受理されたが、完了していな い 204 処理は完了したが、返すデータはな い 303 他のURLを参照 304 リソースは未更新 307 一時的に他のURLに移動している 400 リクエストが不正である 401 認証が必要である 404 リソースが見つからない 500 サーバー内部エラー 503 サービスが一時的に利用不可 WAS V7 アプリケーション・デザインWorkshop Part2 RESTful Webサービスでは、HTTPメソッドを使用してリソースの操作を行います。実行結果は HTTPステータスコードで表します。今までのWebアプリケーションでは、エラー時にステータスコー ド200でリターンして画面にエラーを表示するような使用方法もありましたが、RESTful Webサービス ではエラー時は必ず500等のエラー内容に合ったステータスコードを返します。 53 01. Webアプリケーション設計概要 Webアプリケーション設計概要 SO RESTful Webサービス適用箇所 プレゼンテーション層 Ajaxからのアクセス Ajaxを使用した場合、サー バーへのアクセスは通常 RESTで行う。Ajax側は RESTful Webサービスが どこで実装されてるのか意 識しなくてもよい。 RESTful Webサービス REST クライアント サーブレットの様にブラウザーからのプレゼンテーション層の受付に 使用する。実装にはJAX-RS等を用いる。サーブレットと同じ様にビジ ネス層の呼びだしコントロールを行う。 RESTful Webサービスは、基本ステートレスである。アプリケーション はHTTPセッションを使用しないデザイン（毎回送信する／DBに保存 する）にする必要がある。 インテグレーション層 RESTful Webサービス ユーザー SOAPの変わりにRESTでサービスを公開する。 プレゼンテーション層、外部システムからアクセスされる。 SOAPと比較してシンプルに構築できるが、WS-*の様な応用性がない JAX-RSを使用して実装する。 別の選択候補 ： SOAP Webサービス リソース層 DB with RESTful Webサービス 外部システム DBの機能を使用してデータをRESTful Webサービスとして公開する。 データの公開のみでビジネスロジックはない。 外部システム、Ajaxからアクセスされる事を想定する。 データを直接公開するようなケースで使用可能。 WXSを使用して実装する。 考慮事項 ： セキュリティー・ポリシー 54 WAS V7 アプリケーション・デザインWorkshop Part2 RESTful Webサービスの適用箇所には3箇所あります。 プレゼンテーション層・・・ブラウザー（Ajax）からのアクセスされる インテグレーション層・・・様々なクライアントからアクセスされる リソース層・・・様々なクライアントからアクセスされる プレゼンテーション層／インテグレーション層でのRESTful Webサービスについては、「フロントエン ド設計」「サービス設計」セッションを参照してください。 DBでのRESTful Webサービスについては、「データ設計」セッションを参照してください。 54 01. Webアプリケーション設計概要 Webアプリケーション設計概要 Ajax ＋ RESTful Webサービス SO Webアプリケーション・デザインの変化 – Ajaxでブラウザー側にプレゼンテーション層／ビジネス層の機能も実装可能 • サーバー側の機能はRESTful Webサービスで提供 • ビジネスロジックまで実装した場合、DBだけあれば実現できるアプリケーションもある – 考慮事項 • 現時点では、Ajax（JavaScript）の開発環境（特にデバッグ）が整備されていない • JavaScriptのスキル保持者が必要 Ajax 画面表示コントロール 画面表示コントロール フォーマット変換 フォーマット変換 入力データチェック 入力データチェック ブラウザー ビジネスロジック ビジネスロジック ワークフロー ワークフロー メッセージング メッセージング バッチ バッチ RESTful Webサービス トランザクション管理 トランザクション管理 DB ＋ ビジネスロジック ビジネスロジック DB with RESTful Webサービス 考慮点 ： スキル、開発環境 55 WAS V7 アプリケーション・デザインWorkshop Part2 AjaxとRESTful Webサービスを使用することによって、ブラウザー側で今まで実装できなかったプレ ゼンテーション層、ビジネス層の機能も実装できるによりなります。インテグレーション層、QoS層の 多くの機能は、Ajax側で実装するのは困難です。 ただし現時点では、現実的にはスキルや開発環境のハードルがあるので、どの程度Ajax側で実装 するのかは慎重に判断する必要があります。 55 01. Webアプリケーション設計概要 Webアプリケーション設計概要 フロントエンド設計のデシジョン・ポイント 1/2 SO 検討項目 201. Ajax ツールの検討 ／ プレゼンテーション層 検討内容 Ajaxツールに何を使用するかを検討する AjaxはJavaScriptで実装するが、リッチなGUI作成には大量のコードが必要である。また、ブラウザー間の差異を補 完する必要もあるので、開発効率を上げるためにAjaxのツール（ライブラリー群）を利用するか検討する。 ①Dojo ②その他のツール（jQueryなど） IBM製品として提供される（サポートがある）ツールが必要な場合は、①Dojoを選択する。また、GUIパーツだけでなく、 多くの機能が必要な場合も①Dojoを選択する。オープンソースが使用可能で、目的に合致したツールがある場合は、 ②その他のツールを選択する。その他のツールの代表例としては、jQueryがある。 検討項目 202. Ajax利用パターンの検討 ／ プレゼンテーション層 検討内容 Ajaxを利用する場合、データ変換／画面表示管理の様な項目をAjax側で実装するのか、サーバー側モジュールで 実装するのかを検討する。 ①Ajax側だけで実装する ②サーバー側モジュールでも実装する この選択により各コンポーネントの役割分担が変わる。また、フレームワークの選択に影響を及ぼすケースもある。 検討項目 203. REST実装方式の検討 ／ プレゼンテーション層 検討内容 AjaxはRESTで処理を行う。その処理を受け付けるサーバー側モジュールの実装方式を検討する。 ①JAX-RS ②Servletを利用 ③RPCアダプター 通常のケースでは、①JAX-RSを採用する。既存モジュールをそのまま利用したい等の特別な理由がある場合は、他 の方法を選択する。 56 WAS V7 アプリケーション・デザインWorkshop Part2 フロントエンド設計のSOフェーズでのデシジョン・ポイントです。 詳細は、「フロントエンド設計」のセッションを参照してください。 56 01. Webアプリケーション設計概要 Webアプリケーション設計概要 フロントエンド設計のデシジョン・ポイント 2/2 SO 検討項目 204. プレゼンテーション層の実装技術を検討 ／ プレゼンテーション層 検討内容 プレゼンテーション層の実装技術の検討を行う。201. Ajax ツールの検討 でDojo以外を選択した場合は、選択肢③ がそのツールに変わる。 ①フレームワーク（ Struts ／ Spring MVC ／ JSF） ②JSP ③Dojo これらの実装技術は択一ではなく、組みあせて使用する事が可能。コンポーネント化などの開発効率を考慮して検討 する。①フレームワークの種類は択一なので、どのフレームワークを使用するか選択する必要がある。選択したフ レームワークによっては、使用できるDIコンテナー・フレーワークに制約がある可能性がある。 57 WAS V7 アプリケーション・デザインWorkshop Part2 フロントエンド設計のSOフェーズでのデシジョン・ポイントです。 詳細は、「フロントエンド設計」のセッションを参照してください。 57 01. Webアプリケーション設計概要 Webアプリケーション設計概要 サービス設計のデシジョン・ポイント 1/4 SO 検討項目 205. 非同期処理の処理パターン、実装方式の確定 ／ インテグレーション層 検討内容 非同期処理を使用する場合は、処理パターン及び実装方式を確定する。 処理パターン ・ポーリング ／ コールバック ／ 一方向 実装方式 ・JAX-WS、MDB、AsyncBean など 処理内容により処理パターンを選定し、処理パターンから実装方式を選定する。 検討項目 206. パラレル処理の実装方式の確定 ／ インテグレーション層 検討内容 パラレル処理を使用する場合は、実装方式を確定する。 ①JAX-WS ②AsyncBean ③JMS ④BPEL システム構築容易性、パフォーマンス、開発容易性など複数の検討項目を考慮して選定する。 検討項目 207. サービス実装方式の検討 ／ インテグレーション層 検討内容 SOAで使用されるサービスの実装方式を検討する。 ①SOAP ②REST 複雑なトランザクションやセキュリティー等で高度な処理が必要な場合は①SOAPを使用する。シンプル性を重視す るなら②RESTを採用する。 58 WAS V7 アプリケーション・デザインWorkshop Part2 サービス設計のSOフェーズでのデシジョン・ポイントです。 詳細は、「サービス設計」のセッションを参照してください。 58 01. Webアプリケーション設計概要 Webアプリケーション設計概要 サービス設計のデシジョン・ポイント 2/4 検討項目 208. ビジネスロジック実装方式の検討 ／ ビジネス層 検討内容 ビジネスロジックの実装方式を検討する。 ①JavaBeans ②EJB 検討項目 209. インターフェース定義の検討 ／ インテグレーション層 検討内容 ビジネスロジックを疎結合にするインターフェースを検討する。 ①WSDL ②Javaインターフェース 検討項目 210. コントローラー実装方式の検討 ／ インテグレーション層 検討内容 ビジネスロジックを呼び出しや、トランザクション制御等を行うコントローラーの実装方式を検討する。 ①Framework ②BPEL ③WS-BA ④Message Flow 59 SO WAS V7 アプリケーション・デザインWorkshop Part2 サービス設計のSOフェーズでのデシジョン・ポイントです。 詳細は、「サービス設計」のセッションを参照してください。 59 01. Webアプリケーション設計概要 Webアプリケーション設計概要 サービス設計のデシジョン・ポイント 3/4 SO 検討項目 211. 大容量ファイル転送方式の検討 ／ インテグレーション層 検討内容 Webサービスで大容量ファイルを転送する必要がある場合は、その転送方式を検討する。詳細な方式はWebサービ スの方式により変わるので、207. サービス実装方式の検討 を事前に検討する必要がある。 ①リンク形式 ②サービスとは別経由で転送する ③Webサービスで転送 SOAPを使用する場合は、base64Binary、SwA、MTOM方式から選択する必要がある。 検討項目 212. Webサービスのトランザクション検討 ／ インテグレーション層 検討内容 Webサービスのトランザクションに関して、以下を検討する。 ・トランザクションの範囲 ・WS-Transaction システム構成全体を見ながら、業務処理を実現できるトランザクションの設計を行う。Webサービス間でトランザク ション処理を行う場合は、WS-Transactionを使用する。 検討項目 213. Webサービスのセキュリティー検討 ／ インテグレーション層 検討内容 Webサービスのセキュリティーに関して、以下を検討する。 ・WS-Security end-to-endのセキュリティーが必要な場合は、 WS-Securityが必要となる。 60 WAS V7 アプリケーション・デザインWorkshop Part2 サービス設計のSOフェーズでのデシジョン・ポイントです。 詳細は、「サービス設計」のセッションを参照してください。 60 01. Webアプリケーション設計概要 Webアプリケーション設計概要 サービス設計のデシジョン・ポイント 4/4 SO 検討項目 214. Webサービスのインターオペラビリティー検討 ／ インテグレーション層 検討内容 Webサービスのインターオペラビリティーに関して検討を行う。 ・WS-I Basic Profile 1.1への準拠 ・WSDLの標準化 異機種環境でのSOAP Webサービスはインターオペラビリティーを考慮する必要がある。その場合、上記項目を実 施する必要がある。WSDLの標準化で行う内容については、「サービス設計」のセッションを参照。 61 WAS V7 アプリケーション・デザインWorkshop Part2 サービス設計のSOフェーズでのデシジョン・ポイントです。 詳細は、「サービス設計」のセッションを参照してください。 61 01. Webアプリケーション設計概要 Webアプリケーション設計概要 イベント & Javaバッチ 設計のデシジョン・ポイント 検討項目 215. イベント処理の実装の設計 ／ インテグレーション層 検討内容 イベント処理を使用する場合、実装方式を確定し設計を行う。 ①JMS（SOAP/JMS） ②WS-Notification ③Webメッセージング ④BEP(Business Event Processing) 要件を詳細に検討し、イベントの処理パターンを検討してから、実装方式を選定後設計を実施する。 検討項目 216. Javaバッチの設計 ／ インテグレーション層 検討内容 Javaバッチを使用する場合、以下の検討を行う。 ①障害対応 ②突き抜けの防止（オフラインバッチ） 62 SO WAS V7 アプリケーション・デザインWorkshop Part2 イベント ＆ JavaバッチのSOフェーズでのデシジョン・ポイントです。 詳細は、「イベント ＆ Javaバッチ設計」のセッションを参照してください。 62 01. Webアプリケーション設計概要 Webアプリケーション設計概要 データアクセス設計／アプリケーション開発管理のデシジョン・ポイント SO 検討項目 217. データアクセス方式の検討 ／ インテグレーション層 検討内容 提案フェーズ105. DB方式と製品の検討で採用するDBを確定してから、データアクセス方式を検討する必要がある。 ①JDBC ②O/Rマッパー ③KVS 独自API ④RESTful Webサービス 検討項目 218. アプリケーション更新／バージョニングに関する検討 ／ 開発関連 検討内容 アプリケーション更新／バージョニングに関して以下の選択肢を検討します。通常、アプリケーション更新は運用チー ム担当ですが、アプリケーションのパッケージングにも影響してくるので共同で検討します。 ①WAS NDのロールアウト・アップデート ②WVE（WebSphere Virtual Enterprise）のアトミック・ロールアウト ③OSGi 検討項目 219. 開発－デプロイのフローに関する検討 ／ 開発関連 検討内容 開発、ビルド、デプロイのフローをどの様にするのかを検討する。 各ツールを使用して実際にどの様な手順で開発し、最後にデプロイするまでどの様に開発を進めていくかのフローを 設計する必要がある。 63 WAS V7 アプリケーション・デザインWorkshop Part2 データアクセス設計／アプリケーション開発管理のSOフェーズでのデシジョン・ポイントです。 詳細は、「データアクセス設計」／ 「アプリケーション開発管理」のセッションを参照してください。 63 01. Webアプリケーション設計概要 Webアプリケーション設計概要 【参考】 その他のデシジョン・ポイント SO デシジョン・ポイント No. カテゴリー 220 ソリューション／製品構成に関する最終確定 詳細要件を調査し、提案フェーズで作成した構成に問題ないかを確認し最終確定する 全体 221 ログ出力方針と実装の検討 取得するログの種類／出力ポイント等の方針を検討し、実装方式（Log4j、Logging API）を検討する。 全体 222 HTTPセッションに関する検討 HTTPセッション使用の有無、実現方法 （Cookie / URL リライト）、使用するメモリー量、パーシスタント方式を検討する。 プレゼンテーション層 223 監査の実装ポイントに関する検討 セキュリティー担当者による監査の方針が決定したら、監査ログを出力するポイント及び出力内容の検討を行う QoS層 224 認証方式の検討 Basic認証／Form認証 QoS層 225 アクセス制御の実装方針検討 JavaEEによるロールベース／独自実装 QoS層 226 エラー処理に関する検討 エラーハンドリングのポイント、エラーログ、独自例外クラスなどのエラー処理に関する検討を行う。 QoS層 227 トランザクションに関する検討 UOWや2PC使用の有無などを検討する。 QoS層 228 入力チェック箇所と内容を設計 入力チェックを実行する箇所と、そこでどのようなチェックを行うのかを検討する。 全体 229 大量検索結果分割の検討 大量の検索結果が想定される場合、ブラウザーからDBの間のどの箇所で検索結果を分割するのかを検討する。 全体 230 共通処理の検討 システム全体の共通処理（例：監査ログ出力）とすべき項目があるか検討し、その実装箇所や方法を検討する。 全体 64 WAS V7 アプリケーション・デザインWorkshop Part2 SOフェーズの注意して欲しいその他のデシジョン・ポイントです。 64 01. Webアプリケーション設計概要 Webアプリケーション設計概要 まとめ 提案フェーズ • 機能／非機能要件からソフトウェア選定を行う – 影響の大きいデシジョン・ポイント • • • • • • 処理方式 SOA データストア イベント処理 バッチ セキュリティー SOフェーズ • 詳細な実装方式の検討し設計を行う – フレームワーク選定 • 標準を重視するか、実績のあるオープン技術を採用するか検討 – AjaxとRESTful Webサービス • 適用箇所によっては従来とWebアプリケーションのデザインが変わってくることがある ので、早期に検討 その他の詳細なデシジョン・ポイントは後続の各セッションで 65 WAS V7 アプリケーション・デザインWorkshop Part2 提案フェーズでは、機能／非機能要件からソフトウェア選定を行います。その際、システム全体に影 響する大きなデシジョン・ポイントとして上記があります。 SOフェーズでは、詳細な実装方式を検討し設計を行います。 詳細なデシジョン・ポイントについては、後続の各セッションを参照してください。 65