| Oracle SOA Suite開発者ガイド 10g（10.1.3.1.0） B31839-01 |
|
 前へ |
 次へ |
設計プロセスは、アプリケーション・スコープ内で完成します。 ここでは、プロジェクト・スコープで検出および定義した各コンストラクト（ビジネス・フロー、ESB、サービスなど）に対して、技術的な設計を作成します。 これらのコンストラクトは、Oracle SOA Suite内の製品を最適に使用してランタイム実行可能ファイルを作成する方法が確認できる設計段階まで、さらに詳細なコンストラクトに分解します。
第3.2.5項「プロジェクトの定義」で作成したプロセス・フロー定義を使用すると、プロセス・フローの実装詳細を追加できます。
プロセス・フローを設計する手順は、次のとおりです。
ユースケース分析およびビジネスの相互作用ダイアグラムを使用して、フローの各スコープ内のステップごとにアクティビティを設計します。
たとえば、第3.2.5項「プロジェクトの定義」で作成した定義に基づいて、フロー内の各スコープの設計を開始できます。 次のスコープに進むためには、該当するスコープの完成に必要なすべてのアクティビティを追加します。 アクティビティのタイプは、次のとおりです。
Assign: XML変数間でデータをコピーします。
Invoke: パートナ・リンクによって識別されたWebサービスに情報（通常はリクエスト）を送信し、そのWebサービスで実行する操作を指定します。
Partner Link: 対話において各サービスが果たす役割を定義し、各サービスが提供するポート・タイプを指定して、2つのサービス間の対話関係の特性を決定します。
Receive: クライアントからのメッセージ、または非同期Webサービスからのコールバック・レスポンス・メッセージを待機します。
Reply: 起動に対応してメッセージを送信します。
たとえば、図3-8に、CreditValidationスコープのアクティビティを示します。次のアクティビティが含まれています。
InitializeRequest: 顧客データからクレジット・カードの種類と番号をコピーし、その値を変数に割り当てます。
InvokeCreditService: クレジット・カードの種類と番号を含む同期コールを使用して、CreditValidatingService Webサービスを起動します。 このサービスは、有効または無効のレスポンスでリプライします。
汎用switchアクティビティ: switchタスクの式では、サービスからカードが無効であることを示すレスポンスが戻された場合は、エラーをスローする必要があることが示されます。 このswitchアクティビティには、次の2つのアクティビティが含まれています。
AssignFault: 値「Credit Problem」をstatus変数に割り当てます。
ThrowCreditFault: OrderBookingFaultスコープを起動します。
各アクティビティ（スコープ・アクティビティを含む）について、次のように定義します。
アクティビティ名: アクティビティの名前。
ビジネス・プロセス: アクティビティが属するプロセス・フロー。
アクティビティの説明: アクティビティが提供する機能の概要。
アクティビティ・タイプ: Webサービス、WSDL EJBバインディング、Javaコード、トランスフォーメーション、割当てなど。
アクティビティの詳細: アクティビティが提供する機能の詳細な説明。
トランスフォーメーションの詳細（適用可能な場合）: データ・マッピングの詳細。 詳細は、手順3を参照してください。
パラメータ: このアクティビティで変更または使用するプロセス・パラメータ。
例外: アクティビティによって生成されるフォルト。 例外処理ロジックを含みます。
表3-2に、CreditValidatingサービスを起動して顧客のクレジット・カードを検証するアクティビティの定義を示します。
表3-2 InvokeCreditServiceアクティビティの設計の説明
| 項目 | 説明 |
|---|---|
|
アクティビティ名 |
|
|
ビジネス・プロセス |
|
|
アクティビティの説明 |
|
|
アクティビティ・タイプ |
Webサービス。 |
|
アクティビティの詳細 |
|
|
トランスフォーメーションの詳細 |
なし。 |
|
パラメータ |
|
|
例外 |
クレジット・カードが無効な場合は、注文のステータスを |
必要なドキュメント・データのトランスフォーメーションの詳細を指定します。
通常、データ・トランスフォーメーションでは、以前プロセスに対して定義した変数にインバウンド・データを変換したり、変数を宛先システムで必要なアウトバウンド・データ構造に変換します。 これらの変数は、標準的なビジネス・オブジェクトを表します。 たとえば、SOAOrderBookingフローのTransformOrderアクティビティは、ESBから受信した注文情報（inputVariable変数）をorderRequest変数に変換します。この変数は、注文情報をデータベースに格納するために使用されます。 表3-3に示すように、データ・トランスフォーメーション仕様を作成して、詳細なノード間のマッピングを指定します。
表3-3 データ・トランスフォーメーション・マッピング要件
| 項目 | 説明 |
|---|---|
|
ソース・ノード名 |
ソース・オブジェクト内のノード名。 |
|
ソース・ノード・パス |
ソース・オブジェクト内のノードへのパス。 |
|
ソース・ノードの説明 |
ノードの説明。 |
|
ソース・データ形式の定義 |
データ型。 例: |
|
宛先ノード名 |
宛先オブジェクト内のノード名。 |
|
宛先ノード・パス |
宛先オブジェクト内のノードへのパス。 |
|
宛先ノードの説明 |
ノードの説明。 |
|
宛先データ形式の定義 |
データ型。 例: |
|
マッピング・タイプ |
直接: データ変換なし。 導出: 複数のインバウンド・ノードから導出。 複合: 複合マッピング・ロジック。データベース/表参照。 |
|
マッピング詳細 |
マッピング・ロジックの詳細な説明。 |
アクティビティが外部サービスを起動する場合は、その取引パートナについて次の内容をメモする必要があります。
交換プロトコル
ドキュメント・プロトコル
メッセージ・タイプ
選択したプロトコルの定数
エンドポイント（例: HTTPS、電子メール、FTP）
SLA障害の設計
連絡先情報
プロセス・フローがWebサービスとして起動される場合は、フローに対して認証または認可が必要かどうかを決定します。
たとえば、ユーザー・タイプに基づいてフローへのアクセスを制限する場合やデータを暗号化する必要がある場合などです。
サービスの技術設計を作成するには、第3.2.5項「プロジェクトの定義」で作成したサービス定義を使用して、詳細な技術要素を追加します。
サービスを設計する手順は、次のとおりです。
定義した各サービスに対して、次の項目を詳細に指定した技術設計を作成します。
メッセージの書式: インバウンドおよびアウトバウンド・オブジェクトに対するXML定義。
ビジネス・プロセス・ルール: ビジネス・プロセス・ルールに従ったコンポーネント設計。
データ・ソース: アプリケーションAPI、EJBメソッド、Javaクラス・メソッドなどと相互に作用するための詳細なシーケンス・ダイアグラム。
プロセス・セキュリティ: AppService JAASの構成、WS-Securityの使用など、サービス・セキュリティに関する構成詳細。
例外処理: エラー処理に必要な詳細なエラー処理オプションとコンポーネント。 可能な設計オプションには、エラーのトラッピング機能、編集機能、リプライ機能、および詳細なサービス・フォルト定義があります。
ヒューマン・ワークフロー: ヒューマン・ワークフロー・システムおよびビジネス・プロセスとの相互作用（適用可能な場合）の設計。 ユーザー・インタフェースの設計およびページ・フローを含みます。
第3.2.5「プロジェクトの定義」で作成した分類を使用して、定義した各サービスに設計パターンを割り当てます。
設計パターンを特定の分類に割り当てることによって、コーディングのベスト・プラクティスがシステム全体に準拠していることを確認します。
たとえば、次のサービスの分類に注意します。
注文: データ機能
顧客: 同期して起動した情報システムに対するラッパー
注文の承認: 非同期で起動したヒューマン・ワークフロー
図3-9に、これらの分類によって導かれる設計パターンの割当てを示します（赤色で示しています）。 同じ分類に属する他のすべてのサービスには、同じ設計パターンが割り当てられます。したがって、これらのサービスは、このパターンの設定標準とガイドラインに従います。
統合設計パターンの例を次に示します。
ファサード（ラッパーとも呼びます）
VETRO（Value-base（値ベース）、Enrich（情報付加）、Transform（変換）、Route（ルーティング）、Operation（処理））
EAI
ヒューマン・ワークフロー
ハイブリッド（自動ワークフローとヒューマン・ワークフローの混合）
サービス・ブローカ
ルール
起動
この設計は、標準的なコンポーネント設計プロセスに従うことができます。 ただし、設計を検討して、サービス間の依存関係が最小であること、および依存関係がコンポーネント自体ではなく契約（インタフェース）に記述されていることを確認する必要があります。 このインタフェースが、システムで使用するWebサービスになります。
たとえば、CreditValidationServiceには、Customerサービスで指定された情報が必要です。 Customerサービスとの直接的な相互作用ではなく、フローにアクティビティを追加し、必要なデータにアクセスしてそのデータを変数に格納します。 CreditValidationServiceは、この変数値を使用して検証処理を実行します。 将来は、サービス実装間の相互作用に影響を与えずに、いずれかの疎結合サービス実装を変更できる予定です。
当初のビジネス要件と操作要件がサービスによって満たされたことを確認します。
たとえば、受注記帳SOBAに特定のトランザクション要件がある場合は、該当するプロセスに含まれるすべてのサービス・エンドポイントでその要件を満たす必要があります。 要件を満たしていない場合は、特定の補正パターンを適用して、必要なトランザクション整合性を提供できます。
作成する必要があるものを適性に決定した後は、Oracle SOA Suiteを使用してフロー、ESB、サービスおよびサービス・コンポーネントをそれぞれ実装する方法を決定します。
物理設計を作成する手順は、次のとおりです。
設計の各コンストラクトを、コンストラクトの開発に使用できるOracle SOA Suiteの製品にマップします。 Oracle SOA Suiteには、SOA準拠のアプリケーションとプロセスを作成、デプロイおよび管理するためのサービス・インフラストラクチャ・コンポーネントの完全なセットが用意されています。
Oracle SOA Suiteでは、SOAシステムの実装に役立つ次のアプリケーションを提供しています。
Oracle JDeveloper: IDE機能を補完するためのISE（統合サービス環境）を提供します。 BPEL設計、ESBシステム設計およびXSLTマッピングの視覚的かつ宣言的なツールは、JDeveloperに統合されています。 また、JDeveloperは、アプリケーションを設計、モデル化、コーディング、デバッグ、テストおよびチューニングするための統合機能によって、開発ライフサイクル全体をサポートします。
JDeveloperを使用してEJBサービス・コンポーネントを作成する方法については、第4章「アプリケーション・サービスの作成と使用」を参照してください。 JDeveloperを使用してWebサービスを作成および管理する方法については、第5章「Webサービスの作成」を参照してください。 JDeveloperを使用してWebクライアントを開発する方法については、第9章「SOAシステムでのWebアプリケーションの開発」を参照してください。 JDeveloperは、ESBおよびBPELフローの設計と開発にも使用します。 詳細は次の説明を参照してください。
Oracle Business Rules: ビジネス・ルールを開発およびデプロイするためのインフラストラクチャを提供します。 Oracle Business Rulesは、ルールを定義するためのRule Authorツール、ルール・アクセスと埋込みプログラムの更新を提供するSDK、およびルールを実行するルール・エンジンで構成されています。 Oracle Business Rulesを使用してルールを作成およびデプロイする方法については、第8章「デシジョン・サービスに関するルールの作成と使用」を参照してください。
Oracle Enterprise Service Bus: 企業内外の複数のエンドポイント間でデータを移動します。 Oracle Enterprise Service Busでは、複数の異なるアプリケーション間でビジネス文書をXMLメッセージとして接続、変換およびルーティングするためのオープン標準が使用されます。 Oracle ESBは、JDeveloper内のESB Designerを使用して設計します。 ESBシステムの作成方法については、第6章「Oracle Enterprise Service Busの使用」を参照してください。
Oracle BPEL Process Manager: BPELビジネス・プロセスを作成、デプロイおよび管理するための包括的で使いやすいインフラストラクチャを提供します。 BPELプロセス・フローは、JDeveloper内のBPEL Designerを使用して開発します。 プロセス・フローの作成方法については、第7章「Oracle BPEL Process Managerの使用」を参照してください。
Oracle Web Services Manager: Webサービス操作（アクセス・ポリシー、ロギング・ポリシー、ロード・バランシングなど）を管理するポリシーを集中的に定義し、Webサービスを変更せずにそのポリシーでWebサービスをラップします。 ポリシーの作成方法については、第10章「システムの保護」を参照してください。
ここでは、実装のベスト・プラクティスと標準を、選択したツール、および割り当てた設計パターンに基づいて開発できます。
SOAシステムでは、すべてのプロジェクト・コンポーネントに対してネーミング規則を定義すること、および実装に使用する様々な製品にあわせてネーミング規則を調整することが重要です。 たとえば、サービス、サービス操作、BPELプロセスおよびBPELアクティビティの名前は、すべて標準化する必要があります。
SOAシステムに対する標準のコーディングは、採用した各設計パターン向けの内容である必要があります。 次に例をいくつか示します。
共通のWSDL設計標準。同期Webサービスやビジネス・プロセス用の標準フォルト・リプライなどがあります。
一般的なエラーの処理方法
共通のロギング方法
デプロイメント・トポロジを作成します。
このトポロジによって、各アプリケーション・コンポーネントがシステム・アーキテクチャにマップされます。 このトポロジでは、特定のソフトウェア、サーバー、サーバー構成およびIOサブシステム構成を識別する必要があります。 図3-10に、BPELプロセス・フローに対するデプロイメント・トポロジの例を示します。
