Oracle® Fusion Middleware

Oracle Service Busコンセプトおよびアーキテクチャ

11gリリース1 (11.1.1.9)

B61433-08(原本部品番号:E15020-09)

2014年12月

Oracle Service Bus (OSB)の概念および機能の概要を紹介するドキュメント。

Oracle Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ, 11gリリース1 (11.1.1.9)

B61433-08

Copyright © 2008, 2014, Oracle and/or its affiliates.All rights reserved.

原本著者:  Oracle Corporation

原本協力著者:

原本協力者:

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 はじめに

- 1.1 サービス指向のITトレンド

- 1.1.1 サービス指向アーキテクチャ

- 1.1.1.1 サービス仲介の課題

- 1.1.1.2 複合アプリケーションとサービスのレイヤー化

- 1.1.2 SOAのService Busコンポーネント

- 1.2 Oracle SOA製品スイート

- 1.3 Oracle Service Bus

- 1.3.1 適応的なメッセージング

- 1.3.2 サービス・セキュリティ

- 1.3.2.1 セキュリティ機能

- 1.3.3 サービス仮想化

- 1.3.3.1 条件付きルーティング

- 1.3.3.2 メッセージ変換

- 1.3.3.3 サービス・コールアウト

- 1.3.3.4 プロキシ・サービスからのデータベースの検索

- 1.3.3.5 データ変換ツール

- 1.3.3.6 EJBおよびJEJBトランスポート

- 1.3.3.7 分割-結合

- 1.3.4 サービス管理

- 1.3.4.1 カスタム・オペレーション・コンソール

- 1.3.4.2 サービス・レベル合意

- 1.3.4.3 サービス・バージョン管理

- 1.3.4.4 レポートおよび管理フレームワーク

- 1.3.5 構成フレームワーク

- 1.3.5.1 チェンジ・センター

- 1.3.5.2 テスト・コンソール

- 1.3.5.3 リソース管理

- 1.3.5.4 リソースのカスタマイズ

- 1.3.5.5 UDDIサービス・レジストリ

- 1.3.5.6 エラー処理

- 1.3.6 機能の利点

- 1.3.7 SOAランドスケープの重要性

- 1.3.7.1 Oracle Service Busの使用例

- 1.3.8 Oracle Service Busおよびサービス・ライフ・サイクル

- 1.3.8.1 サービス・サイクルでのOracle Service Busの役割

- 1.3.9 関連トピック

2 Oracle Service Busアーキテクチャ

- 2.1 アーキテクチャの概要

- 2.2 アーキテクチャの主要なコンセプト

- 2.2.1 メッセージ処理

- 2.2.1.1 バインディング・レイヤー

- 2.2.1.2 トランスポート・レイヤー(インバウンド)

- 2.2.1.3 トランスポート・レイヤー(アウトバウンド)

- 2.2.2 プロキシ・サービス

- 2.2.2.1 メッセージ・コンテキスト

- 2.2.3 メッセージ・フローの定義

- 2.3 Oracle Service Busのデプロイメント

- 2.3.1 デプロイメント・トポロジ

- 2.3.2 大規模デプロイメントでの分散構成

- 2.3.3 開発ドメイン、ステージング・ドメイン、本番ドメイン

- 2.3.4 構成メタデータのエクスポートおよびインポート

- 2.3.4.1 メタデータのエクスポート

- 2.3.4.2 メタデータのインポート

- 2.3.5 スクリプトのサポート

- 2.3.6 関連トピック

3 サービス統合

- 3.1 適応的なメッセージング

- 3.1.1 サービス

- 3.1.2 サービス・タイプ

- 3.1.3 転送プロトコル

- 3.1.4 サービス・インタフェース

- 3.1.5 メッセージング・モデル

- 3.1.6 メッセージ・フォーマット

- 3.1.7 メッセージ・コンテキスト

- 3.1.8 コンテンツ・タイプ

- 3.2 Oracle Service Busのリソース

- 3.2.1 スキーマとデータ型

- 3.2.1.1 タイプ・システム

- 3.2.2 変換マップ

- 3.2.3 JAR

- 3.2.4 WSDL

- 3.2.5 プロキシ・サービス

- 3.2.6 サービス・キー・プロバイダ

- 3.2.7 アラート宛先

- 3.2.8 JNDIプロバイダ

- 3.2.9 SMTP サーバー

- 3.2.10 JCAバインディング

- 3.3 Oracle Service Busのセキュリティ

- 3.3.1 Oracle Web Services Manager

- 3.3.2 WS-Policy

- 3.3.3 サービス・アカウント

- 3.3.4 セキュリティ・レベル

- 3.3.4.1 インバウンド・セキュリティ

- 3.3.4.2 アウトバウンド・セキュリティ

- 3.3.4.3 IDの伝播のオプション

- 3.3.4.4 ユーザー管理

- 3.3.4.5 管理セキュリティ

- 3.3.4.6 トランスポート・レベルのセキュリティ

- 3.3.4.7 メッセージ・レベルのセキュリティ

- 3.3.5 カスタム・セキュリティ資格証明

- 3.3.6 関連トピック

4 サービス構成

- 4.1 リソース編成

- 4.1.1 プロジェクト・エクスプローラ

- 4.1.2 プロジェクトとフォルダ

- 4.1.3 リソース・キャッシュ

- 4.2 変更管理

- 4.2.1 チェンジ・センター

- 4.2.2 セッション

- 4.2.3 同時変更

- 4.2.4 構成の変更の追跡

- 4.2.5 依存関係の追跡

- 4.2.6 セマンティクスの整合性

- 4.2.7 リソースとセッションに対する変更の取消し

- 4.2.7.1 リソース変更の取消し

- 4.2.7.2 セッションのアクティブ化の取消し

- 4.3 サービス検出

- 4.3.1 UDDIレジストリ

- 4.3.2 UDDIレジストリの利点

- 4.3.2.1 UDDIレジストリへのプロキシ・サービスのパブリッシュ

- 4.3.2.2 UDDIレジストリからのサービスのインポート

- 4.3.2.3 UDDIを使用したサービスの自動同期

- 4.3.3 関連トピック

5 サービス・コンポジション

- 5.1 動的なコンテンツ・ベースのルーティング

- 5.1.1 ビジネス・サービスとプロキシ・サービス

- 5.1.1.1 プロキシ・サービス

- 5.1.1.2 ビジネス・サービス

- 5.1.1.3 プロキシ・テンプレート

- 5.2 メッセージ・フローの作成

- 5.2.1 メッセージ・パイプライン

- 5.2.1.1 オペレーション・パイプライン

- 5.2.1.2 ブランチ・ノード

- 5.2.1.3 ルート・ノード

- 5.2.1.4 パイプライン・ペア

- 5.2.1.5 パイプライン実行ステージおよびアクション

- 5.2.1.6 オペレーション分岐

- 5.2.1.7 サービス・コールアウト

- 5.3 変換

- 5.3.1 変換マップ

- 5.3.2 メッセージ操作

- 5.4 エラー処理

- 5.4.1 メッセージ検証

- 5.4.1.1 エラー処理パイプライン

- 5.4.2 関連トピック

6 サービス管理

- 6.1 サービスのモニター

- 6.1.1 ダッシュボード

- 6.1.2 メトリックの集約

- 6.1.3 アラート経由のSLAの適用

- 6.2 メッセージ・レポート

図一覧

- 1-1 SOAの概念アーキテクチャ

- 1-2 サービスの無秩序化の課題

- 1-3 Enterprise Service Bus

- 1-4 ESBのアーキテクチャ

- 1-5 SOAのエンタープライズ統合

- 1-6 Oracle Service Busによる仲介

- 1-7 Oracle Service Busの機能

- 1-8 Oracle Service Busの適応的なメッセージング

- 1-9 最適化されたプラガブル・セキュリティ・レイヤー

- 1-10 Oracle Service Busの埋込みサービス管理

- 1-11 UDDIでのサービスのパブリッシュおよび検出

- 1-12 Oracle Service BusのSOAアーキテクチャにおける重要性

- 1-13 サービス・ライフ・サイクル

- 2-1 Oracle Service Busのサービス対話機能

- 2-2 Oracle Service Busのバインディング・レイヤーおよびトランスポート・レイヤー

- 2-3 Oracle Service Busのメッセージ処理

- 2-4 メッセージ・フローのサンプル

- 2-5 Oracle Service Busのデプロイメント

- 2-6 クラスタリングと高可用性

- 3-1 Oracle Service Busの適応的なメッセージング

- 4-1 Oracle Service Busプロジェクトとフォルダのプロジェクト・エクスプローラ・ビュー

- 4-2 チェンジ・センターでのセッション管理

- 4-3 Oracle Service BusとUDDIの統合

- 5-1 メッセージ・フローのコンポーネント

- 5-2 オペレーション・パイプラインの例

- 5-3 メッセージ・フローのブランチ・ノード

- 5-4 サービスと通信するプロキシ・サービスのルート・ノード

- 5-5 ステージ、ノード、およびサービス・レベルのエラー・ハンドラ

- 6-1 Oracle Service Busダッシュボード

- 6-2 レポート・アクションの例

- 6-3 Oracle Service Busダッシュボードでのメッセージ・レポートの概要の例

表一覧

- 1-1 Oracle Service Busの特徴と利点

- 3-1 メッセージのマッピング

- 5-1 Oracle Service Busの通信アクション

- 5-2 Oracle Service Busのフロー制御アクション

- 5-3 Oracle Service Busのメッセージ処理アクション

- 5-4 Oracle Service Busのレポート・アクション

- 6-1 Oracle Service Busサービスのメトリック

はじめに

ここでは、『Oracle Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ』で使用されるアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要

この章では、現在注目されているサービス駆動型のIT戦略、サービス指向アーキテクチャ(SOA)イニシアティブの主要なビジネス・ドライバ、およびEnterprise Service Bus (ESB)コンポーネントの戦略面での重要性について簡単に説明します。Oracle Service Busのインフラストラクチャ・ソリューションとSOAを達成する要因として特徴付ける機能について概念的な概要を説明します。この説明は、SOAイニシアティブを担当する管理部門の関係者、統合を目的とするIT設計者、サービス・モデル作成者または設計者、およびシステム管理者を対象としています。

この項の内容は以下のとおりです。

- 1.1項「サービス指向のITトレンド」

- 1.2項「Oracle SOA製品スイート」

- 1.3項「Oracle Service Bus」

1.1 サービス指向のITトレンド

今日の競争の激しいグローバル・マーケットでは、ビジネスは非常に流動的な環境で展開され、そこでは情報が最も戦略的な意味を持つ資産になります。競争やマーケットの動向、規制の定めなどの変化に対して時宜を得た情報によって迅速に対応することは、ビジネスが効率的に機能し、全体的な成功をもたらすための鍵となっています。急速に変化するマーケットの要求を満たすために、ビジネスは顧客やパートナとやり取りする方法と、ITインフラストラクチャの設計および構築方法の両方において、サービス駆動型にシフトしてきています。

ROIの達成に努めるためにビジネスが機敏性と鋭敏性を高めていくにつれて、組織では新しいコスト効率のよい手段を発見し、新しいサービスを提供し、組織内の情報とビジネス・プロセスの自由な流れを促進するために、企業のITグループへの依存を深めてきました。次に示すビジネス・ドライバは、サービス指向のITアーキテクチャを今日の企業において経済的に現実性のあるものにしています。

- 新しいサービスおよび従来のサービスを迅速に公開して利用可能にするWebサービスの業界による採用

- アプリケーションからユーザーに広がるシステムを中心にしたプロセス構築の必要性

- プロセスをサービスとして迅速に公開することの必要性

- ミッション・クリティカルなプロセスのトランザクションの整合性を保つ、安全で一貫した実行

- きめ細かく統合されたアプリケーションとプロセス制御の開発

- 見通しのよい処理によるパフォーマンスの高い実行の実現

1.1.1 サービス指向アーキテクチャ

サービス指向アーキテクチャ(SOA)は、サービスの提供を最適化し効率的なビジネス・プロセス管理を確実にするためのインフラストラクチャ改革のITにおける主要な課題として出現してきました。SOAによるパラダイム・シフトの一部はITインフラストラクチャの設計方法に根本的な変化をもたらし、アプリケーション・インフラストラクチャから集中したサービス・インフラストラクチャへと移行しました。サービス指向アーキテクチャではエンタープライズ・アプリケーションに含まれる個別の機能を、相互運用性のある、標準に基づいた共有「サービス」のレイヤーとして編成することにより、複合アプリケーションおよびプロセスとしての組合せや再使用が可能になります。

さらに、このアーキテクチャによるアプローチでは、外部サービス・プロバイダによって提供されたサービスをエンタープライズITアーキテクチャに取り込むことができます。その結果、企業は異なる場所に格納された主要なビジネス情報をコスト効率のよい方法で解放することができます。エンタープライズITをアプリケーションではなくサービスを中心として編成することで、SOAはサービスが可能になるまでの時間を短縮し、急ピッチで進むビジネス要件の変化により柔軟に対応できます。

近年では、多くの企業でパイロット・プロジェクトによる暫定的なSOAへの適応から進展して、企業全体での最適化されたSOAのデプロイメントを実現する、定義済みの繰返し可能なアプローチへと拡大しています。プレゼンテーション・サービス、ビジネス・プロセス、ビジネス・サービス、データ・サービス、および共有サービスからなるIT SOAアーキテクチャのすべてのレイヤーがサービスに対応しています。

図1-1 SOAの概念アーキテクチャ

1.1.1.1 サービス仲介の課題

SOAイニシアティブに関する主な課題は、多くの企業で種類の異なる複数ベンダが存在するITのランドスケープと、その結果としてビジネス情報が個々の場所に格納されることに起因しています。レガシー・インフラストラクチャの異なるコンポーネントの置換えに手間とコストをかけるよりも、企業では既存のビジネス・アプリケーションをサービスとして拡張して、他のビジネス・プロセスやアプリケーションでの使用を選択することがよくあります。

Webサービス・インタフェースの既存のパッケージ・アプリケーションへの流入によって、確立済みのサービスや準拠するガイドラインに忠実でないサービスが導入されることが少なくありません。これは、サービスがCRM、データ・ウェアハウス、ERPなどのエンタープライズ・システムの中核からパブリッシュされたサービスで顕著です。

堅牢で包括的なサービス・インフラストラクチャ・ソリューションがない場合、開発者は、オブジェクト・リクエスト・ブローカ(ORB)、メッセージ指向ミドルウェア(MOM)、リモート・プロシージャ・コール(RPC)などのプログラム間の通信をサポートする各種の「ミドルウェア」テクノロジを使用していました。最近では、ITインフラストラクチャ開発者は、種類の異なるアプリケーションとプロセスを統合するために、Webサービスへのポイント・ツー・ポイント接続を複雑な統合ロジックとしてハード・コーディングしています。これは当然の結果としてサービスがエンタープライズIT環境内で複雑および無秩序に広がっていきます。次の図に、静的なサービス統合のシナリオの典型例を示します。

図1-2 サービスの無秩序化の課題

種類の異なるITアーキテクチャに起因するこれ以外のサービス関連の課題には次のものがあります。

- 複雑で固定化したハード的な接続による緊密に連結されたビジネス・サービスの統合

- 種類の異なるプロトコルとこれに関連するアプリケーションによるデプロイされたサービスの管理の難しさ

- 企業の所有にかかる総コストの高さ

- サービスの再使用機能の低下

- トランスポート、変換、セキュリティ、およびルーティングに固有の詳細についての繰返し

- サービス・エンドポイントのインタフェースに変更があった場合に再開発と再デプロイメントにかかる労力の急激な増大

- サービス・コンシューマに大きな影響を与える避けられないサービス障害

ITインフラストラクチャの効率化を目指す企業のアーキテクチャ設計者とWebサービス作成者は、次のITのニーズに応えるエンタープライズ・サービス機能を現在必要としています。

- 異なるソースにあるデータへのアクセスと更新の簡素化

- 企業全体にわたる開発されたサービスの再使用とそのライフ・サイクルの効率的な管理

- 複雑な統合ロジックとメッセージ・ルーティング動作に関する動的な構成の提供

- サービス・インフラストラクチャの実行時構成機能の有効化

- エンタープライズ・サービスの使用方法の統一

- エンタープライズ・サービスの安全性とITポリシーへの準拠

- サービス使用状況のモニターおよび監査とシステム障害の管理

1.1.1.2 複合アプリケーションとサービスのレイヤー化

SOAイニシアティブでは、構成は高位の機能にある既存の資産を利用してビジネスの柔軟性を達成するための統合の一部です。成熟したSOA環境では、ビジネスのニーズを迅速に満たすために既存のサービスを使用してすべてのビジネス・アプリケーションが構成されます。サービス・プロビジョニング・プロセスの柔軟性は、サービスの実装においてロジックのコーディングを避けることによって達成されます。

多くの組織では、サービスを非常に細かいレベルで開発しており、多数の小さな固有サービスが増殖すると、幅広い論理サービスへの構成が難しくなります。サービスのレイヤー化は、一体化されたアプリケーションの制限を破り、開発、リリース、およびテスト・サイクルの短縮化を行うための方法の1つです。サービスの定義と作成にレイヤー化されたアプローチを取ることにより、サービス・インフラストラクチャ・チームは、現在および将来のビジネス要求に対して必要なきめ細かさに調整したサービスを達成できます。

サービス・レイヤーは通常、次のサービスからなります。

- 物理サービス:データを生の形式で取得する機能を表します。

- 標準サービス:情報の表示についての組織の標準が定義されており、業界標準のフォーマットを使用し、幅広いデータ・フットプリントをサポートします

- 論理サービス:よりクライアント固有の粒度に合わせた情報の表示を提供します。高度に最適化された問合せを使用してコンパイル時に生成されます。

- アプリケーション・サービス:アプリケーションによって、業種に依存する方法で直接利用され、プレゼンテーション・サービスを通して公開される場合もあります。

1.1.2 SOAのService Busコンポーネント

SOAの成功の鍵を握るのは、ビジネス・プロセスの対話機能の動的な相乗効果および調整、既存のサービスの継続的な進化と新しいサービスの迅速な追加をサポートするEnterprise Service Bus (ESB)です。SOAの利点を実現化するには、今日の企業で多く見られる種類の異なるIT環境におけるサービス統合の複雑性を隠すために抽象的なレイヤーを提供する堅牢でインテリジェントなサービスの仲介機能がIT組織に含まれていることが絶対に必要です。中間的な抽象化レイヤーは、以前はエンタープライズ・アプリケーションのカスタマイズのためのプラットフォームであることを意味していましたが、現在ではサービス・カスタマイズのためのツール・キットであり、サービスの仲介に着目して疎結合されたサービスの対話機能をサポートするためのスケーラブルなインフラストラクチャであることを意味しています。

図1-3 Enterprise Service Bus

ESBは、従来のテクノロジによる機能に、メッセージ検証や変換、コンテンツ・ベースのルーティング、セキュリティ、ロード・バランシングといった新しいサービスを組み合せることによって、統合化されたミドルウェア・インフラストラクチャ・テクノロジが進化するための手段です。ESBは提供するサービスの大半で業界の標準を使用しているため、プラットフォーム間の相互運用性を推進し、SOAの実装を検討中の会社にとって論理的な選択の1つになっています。

ESBはエンタープライズSOAを構築してデプロイするための効率的な方法を提供します。ESBは、SOAに共通するサービスの編成、アプリケーション・データの同期、およびビジネス・アクティビティ・モニタリングに関する障害を乗り越える効果的なアプローチを提供するため、設計者や開発者の注目を集めつつある概念です。多くの基本的な形式の場合、ESBでは次の主要機能が提供されます。

- Webサービス:普及しつつある標準であるWS-Reliable MessagingやWS-Securityに加えて、SOAP、WSDL、およびUDDIをサポートします。

- メッセージング:複数のサービスの品質を持つ非同期のストア・アンド・フォワードによる配信です。

- データ変換: XMLからXMLへ変換します。

- コンテンツ・ベースのルーティング:ソースと宛先の複数の種類にわたってルーティングをパブリッシュおよびサブスクライブします。

- プラットフォーム中立: Java、.Net、メインフレーム、データベースなど、どのようなテクノロジにも接続します。

図1-4 ESBのアーキテクチャ

堅牢なSOAスイートは以下を提供します。

- 主要なテクノロジに加えて、パッケージおよびカスタマイズされたエンタープライズ・アプリケーションへの接続に対応したアダプタ

- 種類の異なるデータ・ソースから容易にデータ・サービスの作成を可能にする分散問合せエンジン

- 長期実行プロセス(ステートフル)および短期実行プロセス(ステートレス)の両方に対応したサービス編成エンジン

- ユーザーが使用するアプリケーションの迅速な作成を可能にするアプリケーション開発ツール

- 複数のソースからサービスを集約するパーソナライズされたポータルの作成を可能にするプレゼンテーション・サービス

ESBを使用すると、不安定で常にメンテナンスを必要とするポイント・ツー・ポイント接続の必要性がなくなるため、企業は種類の異なるリソースを接続する上でより大きな柔軟性を得ることができます。サービス・コンシューマとサービス・プロバイダの間にESBの仲介機能を追加することによって、下位にあるサービス・エンドポイント・インタフェースの実装の詳細が両者から隠され、再開発や再デプロイメントが与える影響をサービス・コンシューマ・レベルで削減またはなくすことができます。

業界でもトップの企業では、サービス仲介機能とビジネス・プロセスの管理機能を戦略的に統合する、企業に対応した高速のESB仲介機能を利用することでSOAの成功を達成しています。サービスの操作管理の重要性がSOAの成功要因として決定的であることを認識することで、これらの企業はエンタープライズ・クラスのサービス・スケーラビリティ、カスタマイズ、およびセキュリティを提供するソリューションを実装しました。SOAサービスのライフ・サイクルの管理とガバナンスのために特に構築されたこのようなソリューションを採用することで、これらの企業は次のようなビジネス上の利点を手にしました。

- SOAの開発イニシアティブを加速することによるコストの最小化

- サービスの連続した可用性を保証することによる顧客の満足

- サービス・エンドポイントを仮想化することによるサービス・インフラストラクチャの変化からのサービス・コンシューマの保護

- 共有サービス・インフラストラクチャの利用と統一されたモデリング方法によるROIの最大化

- サービス対話機能の簡素化による統合にかかる負荷の軽減

- 共有サービスの正確な実行時制御によるSOAイニシアティブの効率の改善

- インベントリおよび実行時サービスの追跡によるSOA支出の正当化

- SOAの導入による便益または費用削減の測定による正確な費用便益の決定

図1-5 SOAのエンタープライズ統合

1.2 Oracle SOA製品スイート

Oracleは、サービス指向アーキテクチャとして一から作成された最初のサービス・インフラストラクチャ製品ファミリであり、SOAの組織全体へのデプロイと、ビジネスの機敏性とITの効率性の達成を成功するために統一された製品のセットをITにもたらします。

Oracle SOA Suiteとそのコンポーネント製品の概要は、『Oracle Fusion Middleware Oracle SOA Suiteスタート・ガイド』を参照してください。

1.3 Oracle Service Bus

Oracle Service Busは、SOAライフ・サイクル管理のために一から作られた、実績を持ちマーケットをリードするEnterprise Service Bus (ESB)であり、サービス検出と仲介、迅速なサービス・プロビジョニングとデプロイメント、およびガバナンスのための基礎的な機能を提供します。

このサービス・インフラストラクチャ・ソフトウェアは、大まかで緩やかに結合された標準ベースのサービスの構築と、ビジネス機能をサービス・コンシューマとバックエンド・ビジネス・サービスに接続できる中立コンテナの作成を、基盤となるインフラストラクチャとは無関係に行うというSOAの原則に基づいています。次の図にエンタープライズIT SOAランドスケープにおけるOracle Service Busのサービス仲介者としての役割を示します。

図1-6 Oracle Service Busによる仲介

信頼性、可用性、スケーラビリティ、およびパフォーマンスの厳格な基準を満たすように作成されたOracle Service Busは、Enterprise Service Busの統合機能を操作サービス管理とユニークに組み合せた、レイヤー化された機能アーキテクチャを持つ単一のエンタープライズ・クラスのソフトウェア製品です。

図1-7 Oracle Service Busの機能

1.3.1 適応的なメッセージング

Oracle Service Busでは、前例のないレベルでの種類の相違をサポートしており、標準を使用して任意のサービスに信頼性のある接続を行えます。既存のミドルウェア、アプリケーション、およびデータ・ソースはSOAイニシアティブで最上級の扱いを受け、既存のITへの投資を保護し、種類の異なるエンドポイント、フォーマット、およびプロトコルを使用して、ITによるサービスの接続、仲介、および管理を行えるようにします。

適応的なメッセージングは、柔軟性のあるメッセージ処理と、クライアントとサービス間の操作を提供します。たとえば、クライアントはOracle Service Busを介してHTTP上でSOAPメッセージを送信し、そこでメッセージを変換してバックエンドEJBを呼び出すことができます。適応的なメッセージングでは、リクエスト/レスポンス、同期と非同期、分割-結合、パブリッシュ/サブスクライブなどの様々な通信パターンもサポートされ、さらに単一のメッセージ・ライフ・サイクル内のインバウンドおよびアウトバウンド・メッセージに対して異なるパターンを使用できます。

図1-8 Oracle Service Busの適応的なメッセージング

Oracle Service Busは、従来のメッセージング・プロトコルと次のようなメッセージング・パラダイムを操作することにより、効率的なメッセージ編成をプロモートします。

- 同期リクエスト/レスポンス

- 非同期パブリッシュ1対1

- 非同期パブリッシュ1対多

- 非同期リクエスト/レスポンス(同期と非同期のブリッジング)

業界でも最先端のWebサービスのサポートに加えて、Oracle Service Busでは、MQ Series、CICS、.NET、C/C++、Javaアプリケーションへのネイティブの接続性が用意されています。これにより、カスタム・トランスポート・ソフトウェア開発キット(SDK)とOracle Data Service Integratorのネイティブ・トランスポートを使用した企業に固有のカスタム・トランスポートの作成と構成が可能になります。テンプレートを使用して、任意のSOAPまたはXMLメッセージを受け入れることができる汎用のプロキシ・サービスを作成する機能があります。

Oracle Service Busでは、高いパフォーマンスと信頼性を実現するために、SOA全体に対する最適化されたデータベース問合せをサポートしています。.NET、Tibco EMS、IBM MQ、IBM WebSphere、Apache Axis、Cyclone B2B Interchange、およびiWayアダプタを含むWebサービス統合テクノロジと相互運用性があります。

Oracle Service Busの相互運用性については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の相互運用性のシナリオと考慮事項に関する項およびhttp://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlのOracle Fusion Middlewareでサポートされるシステム構成に関する項を参照してください。

1.3.2 サービス・セキュリティ

Oracle Platform Security ServicesとOracle WebLogicセキュリティ・フレームワークに基づいて、Oracle Service Busではサービスのセキュリティをすべてのレベルで保証しています。組込みセキュリティに対応する包括的な一連のコンポーネントにより、顧客は大きな柔軟性と選択の幅を与えられています。ユーザーはカスタムまたはサード・パーティ製のセキュリティ・コンポーネントをプラグインすることもできます。組込み機能によって、セキュリティをすべてのレベルで有効にすることにより、実装における柔軟性が確保されています。例:

- トランスポート・セキュリティ - SSL/基本認証およびカスタム・セキュリティ資格証明

- メッセージ・セキュリティ - WS-Policy/WS-Security、SAML、ユーザーIDとパスワード、X509、署名と暗号化、およびカスタム・セキュリティ資格証明

- コンソール・セキュリティ - Webシングル・サインオンとロール・ベースのアクセス

- ポリシー・セキュリティ - WS-Security、Oracle Web Services Manager、およびWS-Policy

1.3.2.1 セキュリティ機能

Oracle Service Busには、次のセキュリティ機能が用意されています。

- Web Services Managerとの統合

- Webサービス・セキュリティ(WS-Security)仕様に定義された認証、暗号化と復号化、およびデジタル署名

- SSLを使用したHTTPおよびJMS転送プロトコルの従来のトランスポート・レベルのセキュリティのサポート

- 証明書に基づく一方向および双方向の認証

- HTTP基本認証

- ユーザー名およびパスワードを含むリソース(サービス・アカウント、サービス・キー・プロバイダ、UDDIレジストリ、SMTPプロバイダ、JNDIプロバイダなど)の暗号化とエクスポート

- セッション内でのサービス・アカウントおよびサービス・キー・プロバイダの作成と、同じセッション内でのユーザー名、パスワード、および資格証明別名バインディングの追加

- ユーザーIDとパスワード資格証明のパススルーと、ビジネス・サービスに対して提供された新しいユーザーIDおよびパスワードのユーザーへのマップを行うサービス・アカウントの構成

- トランスポート・レベルとメッセージ・レベルのインバウンド・リクエストに対するクライアント指定のカスタム認証資格

Oracle Service Busのセキュリティ・モデルには次のものが含まれます。

- インバウンド・セキュリティ

- アウトバウンド・セキュリティ

- IDの伝播のオプション

- 管理セキュリティ

- WebLogicセキュリティ・フレームワークの構成

- サポートされる標準とセキュリティ・プロバイダ

図1-9に、メッセージ・ライフ・サイクルの様々なポイントでのセキュリティ機能を示します。

図1-9 最適化されたプラガブル・セキュリティ・レイヤー

詳細は、3.3項「Oracle Service Busのセキュリティ」および『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のセキュリティに関するトピックを参照してください。

1.3.3 サービス仮想化

サービス仮想化は、メッセージの操作と制御を通じて機敏性を提供します。

Oracle Service Busでは、検証、変換、メッセージの内容に基づくルーティング、メッセージ内の複数の項目の並列処理、アラートのトリガー、およびエラー処理を使用して、メッセージ・フローの様々なポイントでメッセージを柔軟に制御できます。たとえば、Oracle Service Busには次の機能があります。

- メッセージ・ルーティングの外部サービスに対するXQueryベースのポリシーまたはコールアウト。

- ポイント・ツー・ポイントおよび1対多の両方のルーティング・シナリオ(パブリッシュ)に適用するルーティング・ポリシー。パブリッシュの場合、ルーティング・ポリシーはサブスクリプション・フィルタとして機能します。

- プロキシ・サービスの定義を再構成せずにルートを変更できる、プロキシ・サービスから抽象化されたルーティング表。

- クライアントのユーザー定義のグループへの分類およびそれらのグループに基づいたルーティング・ポリシーの適用を行うためのIDベースのルーティング。

1.3.3.1 条件付きルーティング

サービス・エンドポイントとの通信に関連するすべてのルーティング・ロジックは、構成されたプロキシ・サービスで処理されます。これにより、サービス・コンシューマがバックエンド・サービスとの通信でその複雑性を認識する必要がなくなります。ルーティング、変換、セキュリティ、およびトランスポートの詳細をサービス・コンシューマおよびプロバイダから分離して、これらを構成可能なプロキシ・サービスに置くことで、サービスの統合がより柔軟に行えます。

Oracle Service Busでは、動的なコンテンツ・ベースのメッセージ・ルーティングおよびプロトコルの実行時選択がサポートされています。これらの機能は、エンドポイントのビジネス・サービスとは独立したプロキシ・サービスのインタフェースの構成を可能にすることにより実現しています。汎用のプロキシ・テンプレートを使用することにより、メッセージのコンテンツに基づいてメッセージを動的に適切なビジネス・サービスにルーティングするルーティング・ロジックを持つメッセージ・フローの定義としてプロキシ・サービスを構成できます。

1.3.3.2 メッセージ変換

Oracle Service Busではメッセージの変換または処理において、次の機能がサポートされています。

- 受信メッセージのスキーマに対する検証

- メッセージのコンテンツまたはヘッダーに基づいたターゲット・サービスの選択

- ターゲット・サービスに基づいたメッセージの変換

- XQueryまたはXSLTに基づいたメッセージの変換

- XMLメッセージとMFLメッセージの両方に対する変換のサポート

- メッセージへの情報の追加

- 変換のための追加データ(国コード、完全な顧客レコードなど)を収集するWebサービスへのコールアウトのサポート

1.3.3.3 サービス・コールアウト

Oracle Service Busには、複雑な動的ルーティング処理を行うため、またはメッセージへの情報の追加を実行するために、より洗練されたメッセージ・フローを実現して高い柔軟性を提供するサービス・コールアウト・アクションが用意されています。サービス・コールアウト・アクションはメッセージ・フローのルーティング・ステージ内で使用され、メッセージについての何らかのアクションを実行するために宛先のサービスを呼び出します。サービス・コールアウト機能では、RPCエンコーディングやURL置換などの機能をサポートし、JavaコールアウトとPOJOを使用してOracle Service Busの機能を拡張します。サービス・コールアウトの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のサービス・コールアウト・メッセージの作成に関する項を参照してください。

1.3.3.4 プロキシ・サービスからのデータベースの検索

Oracle Service Busでは、Oracle XQueryエンジンの新しいXQuery関数を使用したデータベース検索関数が用意されています。この関数を使用して、メッセージへの情報の追加、ルーティングの決定、プロキシ・サービスの動作のカスタマイズを行うことができます。プロキシ・サービスからデータベースへの読込みアクセスを行うために、カスタムEJBまたはカスタムJavaコードを作成したり、Oracle Data Service Integratorなどの独立したデータベース製品を使用する必要はありません。

これはexecute-sql()関数を使用して実装されており、データベースへのJDBC呼出しを実行することで、データベース読取りを簡単に実行できます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Busでのメッセージ・フローのモデリングに関する項にあるXQueryを使用したデータベースへのアクセスに関する項を参照してください。

1.3.3.5 データ変換ツール

Oracle Service BusおよびEclipseをインストールすると、EclipseとFormat Builder用のOracle XQuery Mapperプラグイン(データ変換ツール)がインストールされます。EclipseおよびFormat Builderは、Windowsプラットフォームでのみサポートされています。

1.3.3.6 EJBおよびJEJBトランスポート

Oracle Service Busのビジネス・サービスまたはプロキシ・サービスは、EJBまたはJEJBトランスポートを使用するように設計できます。トランスポートは両方とも、Oracle Service Bus管理コンソールおよびテスト・コンソールに完全に統合されています。EJBトランスポートを使用して構築されたビジネス・サービスは、パブリッシュ、サービス・コールアウト、およびサービスの呼出しに使用できます。

EJBは、ツールを使用したり、EJBをホストするアプリケーション・サーバーのレガシー・コードを変更したりすることなく、Webサービスとして公開できます。

また、JEJBトランスポートでは、plain old Java object (POJO)を使用してOracle Service Bus経由でサービスを呼び出すことができます。

1.3.3.7 分割-結合

分割-結合機能は、メッセージ・ペイロードを分割し、メッセージ内の複数の操作を逐次にではなく同時に処理してすべての結果を結合することにより、サービスのパフォーマンスを向上させます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の分割-結合によるサービス・パフォーマンスの向上に関する項を参照してください。

1.3.4 サービス管理

サービス管理には、モニタリング、アラート、およびレポート用の実行時構成ツールの強力なセットが含まれます。Oracle Service Bus管理コンソールのサービス管理機能の完全なセットに加えて、Oracle Service BusはSOA全体を管理するためにOracle Enterprise Managerとも完全に統合されます。

Oracle Service Busにはサービス管理機能が埋め込まれており、すべてのメッセージングに対して最適化されたガバナンスを提供します。この機能の先進的なサポートにより、ビジネスに対する要求、要件、および作業量が変化した場合でも、ミッション・クリティカルなビジネス・プロセスの顧客ニーズへの対応が継続されることが保証されます。

Oracle Service Busでは、サービスの監査とモニターで次の機能が使用できます。

- メッセージ呼び出し、エラー、パフォーマンス特性、渡されるメッセージおよびSLA違反について統計値を収集します。

- サード・パーティESMソリューションとの統合を可能にするため、SLAベースのアラートをSNMPトラップとして送信します。

- システム処理とビジネス監査の両方を目的として、メッセージの選択された部分に対するロギングをサポートします。

- メッセージの主要情報を抽出して検索索引として使用する検索機能があります。

1.3.4.1 カスタム・オペレーション・コンソール

Oracle Service Bus管理コンソールではオペレータ(IntegrationOperator)ロールのユーザーによるタスクの実行をサポートしています。これにより、操作関連の機能や設定が提供され、ユーザーは、スマート検索機能を使ってリソースを簡単に検索できます。また、SLAアラート、パイプライン・アラート、ログ、レポートをモニターしたり、トレースやサービスを有効および無効にすることもできます。

メトリックの通知がOracle Service Bus管理コンソール上の場合とJMXモニタリングAPIを使用した場合とで区別されるようになったため、SLAアラートとパイプライン・アラートとの識別が容易になりました。サービス・レベル・フラグとグローバル・フラグにより、アラート(SLAとパイプライン)、レポート、ロギングの制御が支援されます。オペレータには、操作設定の編集、新しいSLAアラート・ルールの作成、およびアラート宛先リソースの作成と編集を行う権限があります。

Oracle Service Bus管理コンソールにはクラスタ全体のサービスのステータスと統計が表示されます。ビジネス・サービスとOracle Service Busプロキシ・サービスの両方で、レスポンス回数、メッセージ数、エラー数がモニターされます。

Oracle Service Busダッシュボードには、すべてのアプリケーションの開発と管理、サービスのモニターと管理に対して統一されたデータ・サービス・インタフェースが提供されており、操作面でのサポートが向上しました。ダッシュボードでは、エラーおよびパフォーマンス・メトリックのモニター、および集約された概要の表示が行えます。ルーティングの関係、変換、およびポリシーの動的な定義と管理が行えます。ダッシュボードの詳細は、第6章「サービス管理」の6.1.1項「ダッシュボード」を参照してください。

図1-10 Oracle Service Busの埋込みサービス管理

Oracle Service Bus管理コンソールの操作タスクの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』を参照してください。

1.3.4.2 サービス・レベル合意

Oracle Service Busでは、モニターしている統計値はローカルで収集され、一元的に集約されます。集約されたデータに対してSLAルールが実行され、有効または無効にできるサービスに従って、システムによってアラートが生成されます。管理者は次のプロキシ・サービス属性にサービス・レベル合意(SLA)を設定できます。

- サービスの平均処理時間

- 処理量

- エラー、セキュリティ違反、およびスキーマ検証エラーの数

- 管理者はSLAルール違反のアラートを構成可能

SLAの構成の詳細は、第6章「サービス管理」の「アラート経由のSLAの適用」を参照してください。

1.3.4.3 サービス・バージョン管理

Oracle Service Busでは、サービスの新しいバージョンのデプロイを可能にし、WSDLやスキーマなどのメッセージ・リソースの複数のバージョンを使用できる機能が提供されています。各バージョンに、WSDL、メッセージ・スキーマ、ヘッダー、およびセキュリティ・パラメータへの変更を含めることができます。

1.3.4.4 レポートおよび管理フレームワーク

Oracle Service Busでは、カスタムのエンタープライズ・システム管理フレームワークに加えて、サード・パーティ製のレポート・ツールに幅広く対応しています。さらに、操作とデプロイメントのカスタマイズ用のオープン・インタフェース、JMXモニタリング・インタフェース、およびSNMPアラートもサポートしています。レポート機能の詳細は、第6章「サービス管理」の6.2項「メッセージ・レポート」を参照してください。

1.3.5 構成フレームワーク

構成フレームワークでは、Oracle Service Bus本番環境を完全に制御できます。

1.3.5.1 チェンジ・センター

Oracle Service Bus管理コンソールのチェンジ・センターは、サービス・バス内で構成の変更を行う場合の基本となります。チェンジ・センターには、変更が行われている最中に現在の構成をロックするというユニークな機能があり、管理コンソールで構成の変更が行われている間でも、サービス・バスはサービスに対するリクエストの受信と処理を継続できます。

変更中の構成がアクティブ化されるまで、現在のシステムの構成は影響を受けません。変更がアクティブ化されると、Service Busでは新しいサービスとリソースの構成を使用します。このようにして、進行中の変更はサービスに影響を与えることなく実行できます。

構成およびリソースに対して行った変更が追跡され、変更を元に戻すまたは再実行、競合の解決、リソース間の依存関係のメンテナンス、およびテスト・コンソールでの変更のテストを行うことができます。

チェンジ・センターの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のチェンジ・センターの使用に関する項を参照してください。

Oracle Service Busには、個々のリソースおよびOracle Service Bus構成全体のインポートおよびエクスポート機能があり、リソース依存関係のメンテナンスおよび環境間での環境変数の保持を行うことができます。

1.3.5.2 テスト・コンソール

Oracle Service Busに組み込まれているテスト・コンソールは、メッセージ・フローで使用されるリソースおよびインラインXQuery式の検証を行うブラウザ・ベースのテスト環境です。これは、Oracle Service Bus管理コンソールの拡張機能です。テスト・コンソールを使用すると、テスト・オブジェクトの構成(プロキシ・サービス、ビジネス・サービス、XQuery、XSLT、MFLリソース)、テストの実行、テスト結果の表示が行えます。サービスのテスト時には、指定されたトレース・ポイントでメッセージの状態を調べるために、メッセージ・フローのトレースができます。

設計時テストを行うことで、構成を本番環境にデプロイする前に設計上の問題を割り出すことができます。テスト・コンソールでは、システムの特定部分を切り分けてテストしたり、システムを1つの単位としてテストしたりできます。テスト・コンソールは、次のような様々な方法でOracle Service Bus管理コンソールから起動できます。

- プロジェクト・エクスプローラ

- リソース・ブラウザ

- XQueryエディタ

詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のテスト・コンソールの使用に関する項を参照してください。

1.3.5.3 リソース管理

Oracle Service Busには次のリソース管理機能が用意されています。

- サービス、スキーマ、変換、WSDL (Web Service Definition Language)、およびWSポリシーに関する情報を格納します。

- リソースとサービスの一元的な管理と分散アクセスを提供します。

- Oracle Service Busに登録されているサービスを表示し、Eclipseまたは他のアプリケーションからリソースをインポートできます。

- 異なる環境間で(たとえば、開発ドメインからテスト・ドメイン、さらに本番ドメインへ)構成データを伝播できます。システムはインポート時に環境固有の設定をオーバーライドできます。

- より高度な同期および通知機能を利用できます。

1.3.5.4 リソースのカスタマイズ

Oracle Service Busには、プログラム・インタフェースを介してサービス定義、WSDL、スキーマ、XQuery、およびその他の設計時のリソースをカスタマイズするための多くのAPIが提供されています。サポートされているAPIを使用すると、リソース、フォルダ、およびプロジェクトの移動、名前変更、クローン作成、または削除に加え、リソースが含まれているZIPファイルをロードできます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Bus APIに関する項を参照してください。

1.3.5.5 UDDIサービス・レジストリ

構成フレームワークには、Oracle Enterprise RepositoryおよびOracle Service RegistryなどのUDDIレジストリを使用してサービスの検出、パブリッシュ、および同期を行うためのメタデータ駆動のインタフェースも含まれます。

図1-11 UDDIでのサービスのパブリッシュおよび検出

サービスの整合性を確認し、デプロイメントを行う前に競合を調停するための検証を可能にする、UDDIレジストリを使用するサービスの自動的なインポートと同期。UDDIレジストリの詳細は、第4章「サービス構成」の4.3.1項「UDDIレジストリ」を参照してください。

Oracle Service Busで開発されたプロキシ・サービスは、UDDIレジストリにパブリッシュできます。Oracle Service Busは、Oracle Service Registryを含めたUDDI準拠の任意のレジストリに対応しています。

Oracle Service Busのサービス定義は、UDDIのサービス定義と(双方向で)同期できます。Oracle Service Busでサービスを作成または変更した後、サービスをUDDIに自動的にパブリッシュできます。また、UDDIからビジネス・サービスの定義をインポートできます。

Oracle Service Busのビジネス・サービスも、元のサービスがUDDIで変更されると自動的に(作業する必要なしに)更新されます。または、UDDIレジストリ内のサービスが変更されたときは同期するかどうかの承認をユーザーに求めるように、Oracle Service Bus管理コンソールを構成することもできます。UDDIレジストリの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のUDDIに関する項およびOracle Service Registryのドキュメントを参照してください。

1.3.5.6 エラー処理

Oracle Service Busでは、次のエラー処理機能をサポートしています。

- 同期レスポンスを待機するサービス・コンシューマに対して、エラー・メッセージをフォーマットして送信したり、メッセージを返すようにシステムを構成します。

- パイプライン・ステージ、パイプライン全体、およびプロキシ・サービスに対するエラー処理ロジックを構成します。

- パイプラインのメッセージ・コンテキストに基づいてアラートを生成し、アラート宛先に送信します。

1.3.6 機能の利点

次の表に、Oracle Service Busの機能の特徴と、各機能で対処するビジネス要件のポイントについてまとめます。

表1-1 Oracle Service Busの特徴と利点

機能

機能の特徴

ビジネス上の利点

メッセージ・ルーティング

構成駆動型のインテリジェントでコンテンツ・ベースおよびIDベースのルーティングです。

ビジネス・ルールや既存のITシステムに対する変更に基づいて、コーディングを行わずにすばやくルーティング・ルールを構成することで、ビジネスのニーズに迅速に対応します。

メッセージ変換

XQueryまたはXSLTに基づく、複数のメッセージ・フォーマットをサポートする動的なメッセージ変換です。

簡単または複雑なルーティング・ルールやメッセージ・ペイロードを使用してサービスを動的に変換およびルーティングすることによって、進化し続けるSOAおよび統合プロジェクトのシナリオに柔軟に対応します。

サービス・レジストリ

サービスのパブリッシュと再使用を行うための、自動化された、または管理者駆動型のUDDI V3レジストリによる相互運用性です。

自動的に既存のサービスを検出し、新しいサービスをサービス・レジストリにエクスポートすることで、再使用がより簡単になっています。

サービス・プロビジョニング

簡素化されたサービス・プロビジョニングです。

ビルド-テスト開発サイクルをなくすことにより、サービスの複数バージョン管理がより容易になり、デプロイメントをより簡単にすばやく行えます。

メッセージ・セキュリティ

最適化されプラガブルな、ポリシー駆動型のトランスポート・レベルおよびメッセージ・レベル・セキュリティです。

セキュリティ・インフラストラクチャへの既存の投資を活用して、複数のセキュリティ・フレームワーク間をシームレスにブローカリングします。

サービス・エンドポイントの相互運用性

エンドポイントがサポートする拡張性と拡張されたサービスです。

複数の標準、プロトコル、およびベンダでの相互運用性を保証するインフラストラクチャを使用してユニークなIT要件に対応するためにソリューションを拡張します。

サービス・レベル合意

ルール駆動型の構成可能なサービス・レベル・アグリーメント(SLA)を実施します。

SLAが満たされていない場合に、多数の要因とアラートに基づくSLAをユーザーが設定できることにより、可視性とコントロールが増します。

メッセージ・トランスポート

カスタム・トランスポートSDKによるカスタム・トランスポートも含め、サービス・エンドポイント間の異機種トランスポートのサポートを拡張します。

種類の異なるシステムに対する既存の投資を利用し、旧システムから新システムへのスムーズな移行を保証するための柔軟性があります。

適応的なメッセージング

複数のトランスポート・タイプとメッセージ・フォーマットをサポートするWS-I準拠のインテリジェントなメッセージング・ブローカリングです。

システムやスタイルを変更せずに種類の異なるメッセージング・プロトコルを持つ既存のITシステムからサービスを編成する機能によって既存のインフラストラクチャを活用して投資を保護します。

サービスの可用性

JMXおよびSNMPによる積極的なインフラストラクチャ・ヘルスと可用性のモニターです。

機能が充実した組込みのダッシュボード、またはサード・パーティ製のパフォーマンス管理システムを使用して、パフォーマンス・メトリックとSLAのサポートを簡単に構成することによってSOAのヘルスと可用性を維持します。

サービスのモニターのダッシュボード

柔軟性がありグラフィカルな埋め込み式の管理とモニターのダッシュボードです。

機能が充実した組込みのダッシュボード、またはサード・パーティ製のパフォーマンス管理システムを使用して、パフォーマンス・メトリックとSLAのステータスを自動でモニターおよび管理します。アラートに基づいて対応策を積極的に実行します。

サービス・デプロイメント

使いやすく、カスタマイズ可能なプログラムによる、または管理コンソール駆動によるデプロイメントです。

ガバナンスの実施と迅速なデプロイメントを行う機能があります。

1.3.7 SOAランドスケープの重要性

Oracle Service BusはOracleの総合的なビジネス統合ソリューションの中心であり、Oracle Messaging製品ラインに属しています。Oracle Service Busは異なる種類のサービスを管理することを主要な目的としており、従来型のメッセージ・ブローカリングが種類の異なるIT環境全体にわたって行われていることを前提としています。

Oracle Service Busと集中的なインテリジェントなメッセージ仲介およびサービスのライフ・サイクル管理機能のアーキテクチャは動作が軽くステートレスで高パフォーマンスであるため、分散サービス・ネットワークの中核となるコンポーネントとして理想的なものになっています。

ITの幅広いサービス指向アーキテクチャ(SOA)ランドスケープに分散サービス管理の仲介機能として適合するように設計されており、種類の異なる分散デプロイメントにおいてOracleの他のビジネス・プロセス管理ソリューションと統合することができます。

図1-12 Oracle Service BusのSOAアーキテクチャにおける重要性

1.3.7.1 Oracle Service Busの使用例

Oracle Service Busは強力で動作が軽くコスト効率の高いテクノロジであり、次のような場合にサービス開発者や設計者が使用できます。

- 企業全体のSOAの構築: サービス・コンシューマとサービス・プロバイダの間でリクエスト/レスポンス・メッセージ・フローの構成を行う企業全体のメッセージ・トランスポートとルーティングのバックボーンです。

- 再使用可能な最小単位のサービスの作成: 組織の柔軟性の向上、アプリケーション統合の促進、複数アプリケーション間でのデータの同期を容易にします。

- 複合アプリケーションの作成: 既存のアプリケーションのサービスにアクセスする新しいアプリケーションを共有サービスのカタログから迅速に作成することで、再使用による販売までの時間を短縮します。

- ビジネス・アクティビティ・モニタリング(BAM): ビジネス・ユーザーが、主要なパフォーマンス指標へのアクセス、ビジネス・アラートへの対処、インフラストラクチャ内を流れるビジネス・イベントのリスニング、これらのイベントに対応するサービスの編成を行えるようにします。これには、エンタープライズ・サービスのパーソナライズされた表示を提供するポータルを使用します。

1.3.8 Oracle Service Busおよびサービス・ライフ・サイクル

サービスのライフ・サイクルは、次の2つのフェーズで構成されます。

- 設計フェーズ: サービス・アーキテクチャのチームが組織のビジネス・ニーズを識別し、このニーズをサポートするために多数のサービスとアプリケーションを作成します。

- 実行時フェーズ: ビジネス・ニーズのカタログを使用して作成されたサービスはサービス作成のロードマップとして使用され、実行時の提供物として組織内で公開されます。

図1-13 サービス・ライフ・サイクル

Oracle Service Busは、サービス・ライフサイクルの実行時フェーズの重要な部分です。サービス・ライフ・サイクルで次の重要な機能を促進します。

- 実行時フェーズにおいて設計とプロビジョニングのレイヤー化サービスを可能にすることで、システムの論理的または概念的なレイヤー化を促進します。これにより、実行時の柔軟性とプロビジョニング時に機敏性が失われないことが保証されます。

- コンシューマとプロバイダ間のメッセージのフローを管理してモニターします。

- サービスを抽象化し共有されている統合ロジックをサービス・エンドポイントから削除することで、ユーザーとプロセスをサービスの変更から分離します。

- プロトコル、メッセージ・スタイル、セキュリティとデータの形式をブリッジすることで、サービスの変換、検証、情報の追加、およびルーティングを提供します。

- コンシューマが使用できるようにサービスをエクスポーズすることで、可視性と操作サービス管理を提供します。

1.3.8.1 サービス・サイクルでのOracle Service Busの役割

Oracle Service Busの設計思想のポイントは、管理機能とサービス実装を物理的に分離することにあります。Oracle Service Busは、会社のメッセージング構成の一部として、多くのアプリケーションおよびシステムで共用でき、異なるチームによって構築されたサービス実装を異なる部署で統合して適用することも可能です。

サービスが作成されると、後でその他のサービスまたはプロセスが使用できるように、登録および公開されます。サービスは、ローカル・サービス・レジストリでOracle Service Busに直接登録することも、またはOracle Service Registryなどのエンタープライズ・サービス・レジストリからインポートすることもできます。サービスが登録されると、Oracle Service Busは、それらのサービスと通信するためのメッセージ・フローを定義するプロキシ・インタフェースを構成します。

このフローには、適用すべき変換とセキュリティに関する要件、およびメッセージのサービスへのルーティングについての仕様が含まれます。サービスがOracle Service Busに登録されると、Oracle WebLogic Integrationを使用して作成されたビジネス・プロセスなどが、それらのサービスを使用したり、それらを連携させて様々なビジネス・コンテキストをサポートできるようになります。これらの連携されたプロセスは、サービスが使用される方法やビジネス要件に適用される方法、およびより詳細なビジネス・プロセスを定義します。その後、これらのビジネス・プロセスは、ユーザー・インタフェース(UI)を介してエンド・ユーザーが使用できるように公開されます。ユーザー・インタフェースには、Oracle WebLogic Portalなどのトランザクション・ポータル、またはOracle Interactionなどのコラボレーティブ・ポータルがあります。

Oracle Service Busは、再びライフ・サイクルに入ってメッセージ・フロー、システム・ヘルス、およびサービス・エンド・ポイント間の可用性をモニターおよび管理します。この情報は、動作のパターンを分析して改善が必要な部分を示すことができるビジネスおよびオペレーション・アナリストにレポートできます。サービスが進化し、新しいバージョンがリリースされると、ライフ・サイクルが再び開始します。

1.3.9 関連トピック

- Oracle Fusion Middleware Oracle Service Bus開発者ガイド

- Oracle Fusion Middleware Oracle Service Bus管理者ガイド

- Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド

2 Oracle Service Busアーキテクチャ

この章では、Oracle Service Busアーキテクチャの概要について説明し、サービスの迅速な統合、プロビジョニング、異なるITインフラストラクチャ間の管理を可能にする操作上の機能について取り上げます。統合を目的とするIT設計者で、メッセージングとサービス指向アーキテクチャ(SOA)の担当者を対象としています。

この章の内容は以下のとおりです。

- 2.1項「アーキテクチャの概要」

- 2.2項「アーキテクチャの主要なコンセプト」

- 2.3項「Oracle Service Busのデプロイメント」

2.1 アーキテクチャの概要

Oracle Service BusはEnterprise Service Busを中心としたアーキテクチャです。このバスでは、SOAP、HTTP、およびJavaメッセージング・サービス(JMS)を含む標準に基づいたメッセージ配信サービスが提供されます。これは、通常、高スループットを保証するメッセージ配信を各種サービスのプロデューサおよびコンシューマに提供するために設計されるものです。ネイティブのデータ型としてXMLがサポートされており、他のデータ型を処理するために、その他のデータ型も提供されます。

Oracle Service Busはポリシー駆動型であり、「サービス・クライアント」と「ビジネス・サービス」との間に疎結合を確立する一方で、セキュリティ制御とモニターを一元的に管理できます。ステージングによって開発環境から本番環境へ必要に応じてカスタマイズおよび伝播可能なメタデータとして、ポリシー、プロキシ・サービス、および関連するリソース構成を永続化して保存します。メッセージ・ブローカリング・エンジンは、メタデータ・キャッシュからこの構成情報にアクセスします。

Oracle Service Busは、着信するサービス・リクエスト・メッセージを処理して、ルーティング・ロジックを決定し、メッセージを他のサービス・コンシューマと互換性があるように変換を行う仲介機能です。HTTP (S)、JMS、ファイル、FTPなどの転送プロトコルを介してメッセージを受信し、同じ転送プロトコルまたは別の転送プロトコルを使用してメッセージを送信します。サービスのレスポンス・メッセージは、これと逆のパスを辿ります。Oracle Service Busによって処理されるメッセージは、プロキシ・サービスの「メッセージ・フローの定義」によって指定されるメタデータによって駆動されます。

図2-1 Oracle Service Busのサービス対話機能

次の上位レベル・アーキテクチャ・ダイアグラムは、Oracle Service Busとその機能サブシステムを示しています。

2.2 アーキテクチャの主要なコンセプト

この項では、Oracle Service Busのアーキテクチャの主要なコンセプトについて説明します。

2.2.1 メッセージ処理

メッセージには、アプリケーション・プロセスについてのデータまたはステータス情報や、受信側に対する指示などが含まれます。Oracle Service Busでは、コンテンツに基づいてメッセージをルーティングし、コンテンツに対して変換を実行できます。この処理は、Oracle Service Busのトランスポート・レイヤーおよびバインディング・レイヤーを介して実行されます。

図2-2 Oracle Service Busのバインディング・レイヤーおよびトランスポート・レイヤー

メッセージの処理では、次の一連のイベントが実行されます。

1. インバウンド・トランスポートの処理

2. メッセージ・フローの実行

3. アウトバウンド・トランスポートの処理

エンドポイント(ビジネス・サービスまたは別のプロキシ・サービス)にメッセージが送信されると、Oracle Service Busは上記のイベント・シーケンスと同様のモデルでレスポンス・メッセージを処理します。

次の図にOracle Service Busにおけるインバウンド・エンドポイント(プロキシ・サービス)からアウトバウンド・エンドポイント(ビジネス・サービスまたは他のプロキシ・サービスであるサービス・トランスポートURL)までの上位レベルのメッセージ・フロー処理を示します。

図2-3 Oracle Service Busのメッセージ処理

以降の項では、このメッセージ処理に関連する各レイヤーについて説明します。

2.2.1.1 バインディング・レイヤー

バインディング・レイヤーでは次の処理が行われます。

- 必要に応じたメッセージをパックおよびアンパックします。

- メッセージのセキュリティを扱います。

- メッセージを渡してメッセージ・フローを開始します(リクエストおよびレスポンス)

2.2.1.2 トランスポート・レイヤー(インバウンド)

インバウンド・トランスポート・レイヤーは、クライアント・サービス(またはサービス・コンシューマ)とOracle Service Busとの間にある通信レイヤーです。サービス・クライアント・エンドポイントと通信を処理して、Oracle Service Busへのメッセージのエントリ・ポイントとして機能します。インバウンド・トランスポート・レイヤーは主に入力または出力ストリームのメッセージ・データを生のバイトとして処理します。

トランスポート・レイヤーは、HTTP(S)、JMS、FTP、ファイル、および電子メールを含む互換性のあるトランスポート・プロトコルをサポートします。データ処理には関与しませんが、レスポンス・メッセージをサービス・コンシューマに返し、エンドポイントURIやトランスポート・ヘッダーなどのメッセージのメタデータを処理します。

2.2.1.3 トランスポート・レイヤー(アウトバウンド)

アウトバウンド・トランスポート・レイヤーは、ビジネス・サービス(またはサービス・プロデューサ)とOracle Service Busとの間の通信機能を担います。Oracle Service Busからビジネス・サービスまたはプロキシ・サービスにメッセージを渡し、サービスからレスポンスを受信します。トランスポート・レベルでは、メッセージ・データは入力または出力ストリームの形式の生のバイトです。アウトバウンド・トランスポート・レイヤーは、HTTP(S)、JMS、FTP、ファイル、電子メールを含む互換性のあるトランスポート・プロトコルをサポートします。データ処理には関与しませんが、エンドポイントURIやトランスポート・ヘッダーなどのメッセージのメタデータを処理します。

2.2.2 プロキシ・サービス

プロキシ・サービスは、Oracle Service Busのアーキテクチャで基礎となるコンセプトです。プロキシ・サービスは、サービス・コンシューマが管理対象のバックエンド・サービスに接続するために使用するインタフェースです。プロキシ・サービスは、Service Busがローカルに実装する仲介Webサービスの定義になっています。Oracle Service Bus管理コンソールではプロキシ・サービスの構成が可能で、Web Services Description Language (WSDL)でそのインタフェースを定義し、また使用されるトランスポートの種類も定義することができます。メッセージの処理ロジックは、プロキシ・サービスの定義時に「メッセージ・フローの定義」で指定されます。プロキシ・サービスの詳細は、5.1.1.1項「プロキシ・サービス」を参照してください。

2.2.2.1 メッセージ・コンテキスト

プロキシ・サービスのコンテキストは、リクエスト・フローとレスポンス・フローとで共有される一連のXML変数です。コンテキストに新しい変数を動的に追加したり、または削除できます。あらかじめ定義されたコンテキスト変数には、メッセージに関する情報、トランスポート・ヘッダー、セキュリティ・プリンシパル、現在のプロキシ・サービスのメタデータ、およびプロキシ・サービスから呼び出されるプライマリ・ルーティング・サービスとパブリッシュ・サービスのメタデータが含まれます。

コンテキストは読み込まれて、XQuery式による変更や、変換やインプレース更新アクションによる更新が行われることがあります。コンテキストの中核は、$header、$body、$attachments変数で構成されます。これらのラッパー変数には、Simple Object Access Protocol (SOAP)ヘッダー要素、SOAP本体要素、およびMultipurpose Internet Mail Extensions (MIME)添付がそれぞれ含まれます。コンテキストによって、すべてのメッセージがSOAPメッセージであり、非SOAPメッセージがこのパラダイムにマップされるように見えます。

プロキシ・サービスはメッセージを複数のビジネス・サービスにルーティングできるため、プロキシ・サービスは通信先のビジネス・サービスとは独立したインタフェースで構成できます。汎用のプロキシ・テンプレートを使用すると、コンテンツ・ベースのルーティング・ロジックに基づいてメッセージを適切なビジネス・サービスに動的にルーティングするメッセージ・フローの定義としてプロキシ・サービスを構成できます。プロキシ・サービスは、メッセージ・データをエンドポイントのビジネス・サービスによって必要とされる適切なプロトコル形式にマッピングすることもでき、その結果、動的な実行時プロトコル切替えが可能になります。

プロキシ・テンプレートの詳細は、第5章「サービス・コンポジション」を参照してください。

2.2.3 メッセージ・フローの定義

プロキシ・サービスの実装は、「メッセージ・フローの定義」によって指定されます。メッセージ・フローの定義は、プロキシ・サービスを通過するリクエスト・メッセージとレスポンス・メッセージのフローを定義します。メッセージ・フローには、次の4つの構成要素があります。

- パイプライン・ペア。一方はリクエストで使用され、他方はレスポンスで使用されます。パイプラインは、要求処理または応答処理で実行されるアクションを指定する一連のステージで構成されます。

- ブランチ・ノード。メッセージまたはメッセージ・コンテキストの指定部分の値に基づいて分岐するか、呼び出されたオペレーションに基づいて分岐するために使用されます。

- ルート・ノード。メッセージの宛先の定義に使用されます。デフォルト・ルート・ノードは、リクエストそのものをレスポンスとして返すエコー・ノードです。

- 開始ノード。

図2-4 メッセージ・フローのサンプル

メッセージ・フロー要素を任意で組み合せて、「開始ノード」をルート(root)位置に必ず(1つだけ)配置し、ルート(route)ノードを持つツリー構造を形成します。ブランチの最後のノード(リーフ・ノード)は、ルート・ノードまたはエコー・ノードになります。

リクエスト・メッセージは開始ノードから始まり、リクエスト・パイプラインのアクションを実行しながらリーフ・ノードまでの経路を辿ります。リーフがルート・ノードの場合、応答が生成されます。一方向のサービスの場合は空の応答になることがあります。リーフがエコー・ノードの場合、要求そのものが応答として扱われます。応答では、ブランチ・ノードのアクションをスキップしながらツリーの経路を逆に辿ります。ただし、応答パイプラインのアクションは実行されます。

インタフェースまたはオペレーションがリクエスト/レスポンスであれば、最後にツリーの一番上からレスポンスが送信されます。それ以外の場合、レスポンスは破棄されます。メッセージ・フローの定義の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Busでのメッセージ・フローのモデリングに関する項を参照してください。

コンテキスト変数に影響する一連の変換は、選択したエンドポイントへのメッセージの送信前、またはレスポンスの受信後に定義できます。XQueryまたはXSLT変換のかわりにWebサービス・コールアウトを使用して、コンテキスト変数を設定できます。Oracle Service Bus変換マップを構成する方法については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。

WS-Securityの処理も認可と同様に、WS-Policyを使用するビジネス・サービスの呼出し時に開始ノードで透過的に実行されます。Oracle Service Busのセキュリティの構成方法については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のセキュリティに関する項を参照してください。

2.3 Oracle Service Busのデプロイメント

この項では、Oracle Service Busのデプロイメント機能について説明します。

2.3.1 デプロイメント・トポロジ

Oracle Service Busは、多数の分散サービス・エンドポイントを集中的に管理して制御するように設計されています。Oracle Service Busは、次の構成にデプロイできます。

- 管理サーバーとしても機能する単一サーバー。

- 複数のサーバーで構成されるクラスタ。

図2-5 Oracle Service Busのデプロイメント

Oracle Service Busを使用することで、自律的なESBインスタンスを企業全体に構成できます。これらのインスタンスは、サービスや変換などの、構成アーティファクトの独自のセットを持っています。通常、このようなデプロイメントでは、組織内の様々なIT部門にマップします。異なる部門間の通信は、多くの場合ファイアウォールを介して互いにやり取りする、ESBの連携ネットワークを介して行われます。Oracle Service Busのデプロイメントの詳細は、『Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド』を参照してください。

2.3.2 大規模デプロイメントでの分散構成

Oracle Service Busでは多数の分散サービス・エンドポイントを管理および調整できるため、企業内の集中管理が可能になります。さらに、基になるOracle WebLogic Serverをクラスタリングすることで異種のOracle Service Busハブを水平方向に拡大し、分散Oracle Service Busネットワークを作成できます。

クラスタは、メッセージを処理する一連のクラスタリングされた管理対象サーバーで構成されます。1つのドメインに含まれるOracle Service Busをデプロイしたクラスタは1つに限られます。このクラスタは、Oracle Service Bus以外にも他のアプリケーションをホストできます。管理サーバーはクラスタ・ドメインごとに1つだけあります。クラスタリングの詳細は、『Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド』のOracle Service Busクラスタに関する項およびOracle Service Busデプロイメント・トポロジに関する項を参照してください。

この場合、Oracle Service Busの中央のデプロイメントがガバナンスと調整を処理し、ネットワーク内のすべてのESBは、中央のESBを介して通信します。管理対象サーバーに構成とメタデータを自動的に伝播してローカルでの取得時間を節約し、モニター用のメトリックをすべての管理対象サーバーから自動的に収集して、Oracle Service Bus管理コンソールで集約して表示します。

次の図は、基本的なOracle Service Busクラスタ・トポロジでのメッセージ・データ・フローを示します。

図2-6 クラスタリングと高可用性

Oracle Service Busは、JMSストア・アンド・フォワードを使用して、連携ネットワーク間の信頼性の高い、保証されたメッセージングを可能にします。また、動的ルーティング機能も、このネットワークの構成を簡略化します。メッセージングの負荷をクラスタ内のサーバー間で均一に分散することで、システムのボトル・ネックを取り除くことができます。

2.3.3 開発ドメイン、ステージング・ドメイン、本番ドメイン

Oracle Service Busでは、制御された環境でのリソースおよびサービスの構成により、エンタープライズ・システムの変更管理のベスト・プラクティスをサポートします。システムの構成をテスト用に別のステージング・ドメインにエクスポートして、プロモーションの最終準備を行ってから、本番ドメインにエクスポートできます。JavaプログラムやJavaスクリプトを使って、アプリケーションのデプロイメントを自動化したり、構成をステージング環境から本番環境に移行したりすることができます。

Oracle Service Bus管理コンソールでは、多数のデプロイメント・カスタマイズ・オプションを選択することができます。様々な環境変数を使用して、環境を移行する際の設定を保持または調整することが可能です。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の環境値の検索と置換およびカスタマイズ・ファイルの作成に関する項を参照してください。

2.3.4 構成メタデータのエクスポートおよびインポート

大規模な開発では、リソースの開発、テスト、ステージング、および本番システムへのデプロイを行う機能が重要です。Oracle Service Bus管理コンソールでは、Oracle Service Busリソース構成をメタデータとして保存し、他のOracle Service Busドメインへのインポート用にJARファイルとしてエクスポートできます。この機能により、Oracle Service Busリソース構成の環境を、ステージング、テスト、本番という順序に従って移行していくことができ、各種のデプロイメント・シナリオを達成するために必要となる専門知識、時間、リソースを最小限に抑えることができます。

リソースのエクスポートとインポートに加えて、プロジェクト全体のエクスポートとインポートも可能です。既存のソース・コード・コントロール・システムの機能と構成JARファイルを組み合せると、Oracle Service Bus構成のバージョン管理および変更管理を行うことができます。

2.3.4.1 メタデータのエクスポート

エクスポート機能では、JARファイルを使用して、既存の構成を他のOracle Service Busドメインにエクスポートできます。この機能では、Oracle Service Busのソース・ドメインにデプロイメントされたリソースのすべて、またはサブセットをエクスポートすることで、システム構成をOracle Service Busのあるインスタンスから別のインスタンスに伝播できます。エクスポート可能なデータに制限はありません。1つまたは複数のプロジェクト、または1つまたは複数のプロジェクトから選択したリソースをエクスポートできます。

Oracle Service Bus管理コンソールでは、依存関係の追跡機能により、特定のリソースとそのリソースが依存している他のすべてのリソースをエクスポートすることもできます。構成をエクスポートするには、セッションの外部で作業する必要があります。有効化されている(実行時にデプロイされている)構成のみがエクスポート可能です。

操作値には、グローバル操作設定と、プロキシ・サービスおよびビジネス・サービス用の操作値の2種類があります。グローバル操作設定はシステム・プロジェクト・フォルダにあるリソースで、他のすべてのリソースと同様にエクスポートできます。インポートしているドメインの操作設定がインポート中に上書きされないように保持することが可能です。これはPreserve Operational Values設定を指定することで実現されます。Preserve Operational Valuesが指定されていない場合は、インポートするJARファイルの値がドメインに設定されます。

2.3.4.2 メタデータのインポート

インポート機能では、リソース構成を別のOracle Service Busドメインのセッションにインポートできます。このインポート機能を使用するには、構成JARファイルがインポートされるセッションで作業を行う必要があります。多数の構成の更新と複数のJARファイルのインポートは1つのセッション内で許可されます。また、エクスポートされたデータのサブセットのみをインポートすることもできます。

Oracle Service Busには、Oracle Service Bus管理コンソールのチェンジ・センターを使用して、インポートするドメインの要件を満たすように環境に固有の再構成を行う機能があります。このカスタマイズ機能を使用して、インポートされたリソースはアクティブ化する前に新しいドメインに合わせて調整できます。

インポート機能と検索および置換機能をと同時に使用することで、リソースに対する環境に固有の属性のグローバルな変更がサポートされます。これは、同様の多くの環境値を変更するときに便利です。この機能による置換は、複雑なデプロイメント・シナリオで構成を慎重に調整する必要がある場合には適しません。詳細は、『Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド』を参照してください。

Oracle Service Bus管理コンソールを使用して、構成メタデータをエクスポートおよびインポートする方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のカスタマイズに関する項を参照してください。Oracle Service Bus管理コンソールのチェンジ・センターを使用して、新しい環境用に構成を変更する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のチェンジ・センターの使用に関する項を参照してください。

2.3.5 スクリプトのサポート

Oracle Service Busの構成とデプロイメントはOracle Service Bus管理コンソールを使用してすべて実行することができますが、Oracle WebLogic Server Scripting Tool (WLST)を使用するとデプロイメント・タスクを自動化できます。WLSTの詳細は、Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのWLSTコマンドおよび変数リファレンスに関する項を参照してください。

2.3.6 関連トピック

- 『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Busでのメッセージ・フローのモデリングに関する項

- 『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Bus APIに関する項

- Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド

3 サービス統合

この章では、Oracle Service Busのサービス統合と適応的なメッセージングの概念、その高速で信頼できるサービス仲介とプロビジョニング機能について説明します。SOAにおいてサービスの構成を担当するITデプロイメントのスペシャリストを対象としています。

この章では、以下のトピックについて説明します。

- 3.1項「適応的なメッセージング」

- 3.2項「Oracle Service Busのリソース」

- 3.3項「Oracle Service Busのセキュリティ」

3.1 適応的なメッセージング

Oracle Service Busには、アプリケーションをエンタープライズ・クラスのサービス(Webおよびレガシー)に拡張して統合する機能があります。また、インテリジェントなブローカリング機能による再利用のためにサービスの仲介と公開を容易にする機能も備わっています。

図3-1 Oracle Service Busの適応的なメッセージング

Oracle Service Busを使用すると、サービス・プロバイダとクライアントが互いに直接メッセージを交換するかわりにプロキシ・サービスを仲介するようになるので、種類の異なる通信プロトコルやメッセージ・フォーマットにより生じる複雑さをなくすことができます。次のオペレーション機能を利用することで、高速で信頼できるサービスの仲介機能が提供されます。

- 複数のWebサービス・トランスポート(HTTP/SOAP、WS-I、WS-Security、WS-Policy、WS-Addressing、SOAP v1.2およびv1.1)のサポート

- 従来のメッセージング・トランスポート(JMS、MQ、EJB/RMI、Tuxedo、FTP、SMTP、ファイル、WebSphere上のEJB/RMI)のサポート

- Javaメッセージングのサポート

- データベース検索の容易さ

- Oracle Data Service Integratorのネイティブ・トランスポートのサポート

- Oracle Service BusトランスポートSDKを使用したエンタープライズ固有のカスタム・トランスポート作成のサポート

- 汎用プロキシ・テンプレートを使用した、任意のSOAPまたはXMLメッセージを受け入れる汎用プロキシ・サービスの作成と構成の支援

- Webサービス統合テクノロジ(.NET、Tibco EMS、IBM MQ、IBM WebSphere、Apache Axis、Cyclone B2B Interchange、iWay 5.5アダプタなど)との相互運用性

Oracle Service Busは、Webサービスや従来のメッセージング・プロトコル、レガシーおよび専用の統合テクノロジとの互換性について、業界でも最高水準のサポートを行っており、理想的なサービス統合および適応的なメッセージング・ソリューションです。以下のトピックでは、Oracle Service Busを使用したサービス統合と適応的なメッセージングに関係する概念について説明します。

3.1.1 サービス

Oracle Service Busでは、サービス統合の関係は、ポリシーとプロキシ・サービスを構成することにより動的に実装されます。プロキシ・サービスとビジネス・サービスはどちらもプロキシ・サービスによって呼び出され、次の属性を持つサービスとして作成されます。

- 「ポート」と呼ばれる一連の具象インタフェース(「エンドポイント」とも呼ばれます)。それぞれがトランスポート・アドレスと関連構成を持ちます。一連のポートは、ビジネス・サービスのロード・バランシングおよびフェイルオーバーの代替機能を果たします。プロキシ・サービスは、単一のポートしか持ちません。

- 単一の抽象インタフェース(任意指定)。インタフェースのメッセージ部の構造が定義され、必要に応じて、オペレーション別に定義できます。オペレーションは、Javaインタフェースのメソッドと同等です。

- 具象メッセージへの抽象インタフェースのメッセージ部のパッケージングを定義する単一のバインディング。

- Webサービス・セキュリティ(WS-Security)のポリシー。

3.1.2 サービスのタイプ

Oracle Service Busは、従来のWebサービス(WSDLでXMLまたはSOAPバインディングを使用)から非XMLサービスや汎用サービスまで、多くのサービス・タイプに対応しています。サービス・タイプは、ビジネスおよびプロキシ・サービスが作成されるときにサービスの登録を行うことで個別に選択され、サービス・エンドポイントとの通信で使用できるプロトコルが定義されます。Oracle Service Busのサービス・タイプには次のものがあります。

- SOAPサービス: SOAPメッセージは、<soap:Envelope>要素内のheader変数およびbody変数のコンテンツをラップすることで作成されます。body変数に参照XMLが格納されている場合、現状のまま送信されます。つまり、参照されているコンテンツはメッセージに追加されません。attachments変数で添付が定義されている場合は、メイン・メッセージと添付データからMIMEパッケージが作成されます。各添付部分のコンテンツの処理方法は、メッセージング・サービスのコンテンツの処理方法に類似しています。

- XMLサービス(非SOAP): XMLベースのサービスへのメッセージはXMLですが、プロキシ・サービスの構成で許可された任意の型を使用できます。添付を含むメッセージの場合、そのコンテンツは、プライマリXMLペイロードをその一部として(通常は最初の部分、または最上位のContent-Typeヘッダーで指定される部分)含むMIMEパッケージです。

- メッセージング・サービス: メッセージング・サービスは、あるデータ型のメッセージを受信し、レスポンスとして別のデータ型のメッセージを返すことができます。サポートされるデータ型には、XML、メッセージ・フォーマット言語(MFL)、テキスト、型なし、バイナリ、およびインタフェースがWSDLで記述されていない添付などがあります。

Oracle Service Busでは、HTTPとJMSの非同期転送プロトコルの双方向(リクエストとレスポンス)および一方向のパラダイムがサポートされます。基底のトランスポートが順序付きメッセージ配信に対応している場合、Oracle Service Busでも同様の拡張で対応できます。

3.1.3 転送プロトコル

Oracle Service Busでは、以下のサービス・トランスポートプロトコルがサポートされます。

- EJB/RMI

- 電子メール(POP/SMTP/IMAP)

- ファイル

- (S)FTP

- HTTP(S)

- JCA

- JEJB

- JMS (JMSを使用したMQおよびJMS/XAを含む)

- ローカル(ESB間通信用にOracleが独自開発)

- MQ (WebSphere MQ)

- SB (RMIサポート)

- SOA-DIRECT (Oracle SOA Suite)

- Tuxedo (Oracle Tuxedo)

- WS (WSRM、Web Services Reliable Messaging)

選択したサービス・タイプによってサービス・エンドポイントとの通信で使用されるプロトコルが定義されます。次の表にサービス・タイプとサポートされるトランスポートを示します。

サービス・タイプ

転送プロトコル

SOAP WSDLまたはXMLnic

HTTP(S)、JCA、JMS、ローカル、SB、SOA-DIRECT、WS
JMSリクエストとJMSレスポンスは、WS-Securityが有効になっているとサポートされません。

SOAP (WSDLなし)

HTTP(S)、JMS、ローカル、SB
JMSリクエストとJMSレスポンスは、WS-Securityが有効になっているとサポートされません。

トランスポート・タイプ

EJB、Flow (分割結合)、JEJB

XML (WSDLなし)

電子メール、ファイル、FTP、HTTP(S)、JMS、ローカル、MQ、SB、SFTP、Tuxedo
HTTP GETは、WSDLがないXMLだけでサポートされます。

メッセージ・タイプ(バイナリ、テキスト、MFL、XML)

電子メール、ファイル、FTP、HTTP(S)、JMS、ローカル、MQ、SFTP、Tuxedo

Oracle Service Busでは、ネイティブのカスタム接続オプションを追加するために、トランスポートSDKも用意されています。

Oracle Service Bus管理コンソールを使用して、プロキシ・サービスのトランスポートを構成する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のプロキシ・サービスの作成および管理に関する項を参照してください。

Oracle Service Bus管理コンソールを使用して、ビジネス・サービスのトランスポートを構成する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のビジネス・サービスの作成および管理に関する項を参照してください。

3.1.4 サービス・インタフェース

Oracle Service Busは、Webサービスの正式な記述の部分ではWSDLに依存します。Webサービスの場合、WSDLにはWebサービスのインタフェース、場所、および呼出し方法が記述されます。Oracle Service BusではWSDLに関する以下の2つの性質を考慮して、プロキシ・サービスおよびビジネス・サービスが定義されます。

- インタフェース内のオペレーション、およびオペレーションのシグネチャのメッセージ部のタイプを定義する抽象WSDLインタフェース

- メッセージ部のメッセージへのバインディング(パッケージング)、およびメッセージのトランスポートへのバインディングを定義するバインディングWSDLインタフェース

WSDLは、Oracle Service Bus管理コンソールを使用してWSDLリポジトリにインポートできます。WSDL内の参照が解決されるようにOracle Service Bus管理コンソールを使用して、すべてのスキーマとWSDLが正しくリンクされていることを確認できます。WSDLのリポジトリへの格納が終了すると、プロキシ・サービスおよびビジネス・サービスの追加時に使用できるようになります。Oracle Service Busではメッセージング・サービスに対して、独自のインタフェース表現が使用されます。

Oracle Service Bus管理コンソールを使用して、WSDLをインポートおよび解決する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のWSDLの追加に関する項を参照してください。

3.1.5 メッセージング・モデル

Oracle Service Busには複数のメッセージング・パラダイムが採用されており、次の種類の通信をサポートします。

- 同期リクエスト/レスポンス

- 非同期パブリッシュ1対1

- 非同期パブリッシュ1対多

- 非同期リクエスト/レスポンス(同期と非同期のブリッジング)

同期と非同期のブリッジングでは、同期クライアントが非同期プロバイダにリクエストを発行します。このパターンの場合、Oracle Service Busにはレスポンスをリスニングするときのタイムアウト値を使用して1つ目のJMSでメッセージをパブリッシュし、2つ目のJMSのレスポンス・キューを構成する機能があります。このタイプのサービスは、サービス・コンシューマからは同期サービスに見えます。非同期リクエスト/レスポンス・メッセージを使用すると、次のような利点があります。

- 多数のブロックされているリクエスト/レスポンスの呼出しによって発生する可能性のあるスレッド管理の問題が解消され、リクエスト・スレッドによるブロッキングがなくなります。

- メッセージングの信頼性が向上します。

3.1.6 メッセージ・フォーマット

Oracle Service Busでは、次のメッセージ・フォーマットがサポートされます。

- 添付ファイルなしまたは添付ファイル付き電子メール

- ヘッダー付きJMS

- MFL (メッセージ・フォーマット言語)

- 生データ(既知のスキーマを持たない不明確な非XMLデータ(MFLファイルなし))

- テキスト

- SOAPおよび添付ファイル付きSOAP (WSDLで記述されたSOAPまたは記述されないSOAP)

- XMLおよび添付ファイル付きXML (WSDLまたはスキーマで記述されたXMLまたは記述されないXML)

3.1.7 メッセージ・コンテキスト

プロキシ・サービスによって送受信されるすべてのメッセージは、プロキシ・サービスの内部で一連のプロパティによって定義されます。これらのプロパティは、メッセージ・データや、そのメッセージに関連するメタデータを保持していますこの一連のプロパティは、メッセージ・コンテキスト(コンテキスト)と呼ばれ、コンテキスト変数を使用して実装されます。メッセージ・コンテキストはXMLスキーマによって定義されます。各コンテキスト変数は異なるプロパティに関連します。コンテキスト変数には、事前定義された変数とユーザー定義の変数があります。プロキシ・サービスの中核となるのが「コンテキスト」です。メッセージ・フローで使用されるメッセージ・コンテキストおよびコンテキスト変数の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のメッセージ・コンテキストに関する項を参照してください。

あらかじめ定義されたコンテキスト変数には、メッセージに関する情報、トランスポート・ヘッダー、セキュリティ・プリンシパル、現在のプロキシ・サービスのメタデータ、およびプロキシ・サービスから呼び出されるプライマリ・ルーティング・サービスとパブリッシュ・サービスのメタデータが含まれます。通常は、XQuery式を使用して、メッセージ・フローのコンテキスト変数を操作します。変換およびインプレース更新アクションを使用してコンテキスト変数を変更することもできます。

メッセージ関連のコンテキスト変数である$header、$bodyおよび$attachmentsは、メッセージ・フロー内のメッセージの標準書式を表します。これらはSOAPヘッダー要素、SOAP本体要素、およびMIME添付を含むラッパー変数です。コンテキストによって、すべてのメッセージがSOAPメッセージであり、非SOAPメッセージがこのパラダイムにマップされるように見えます。次の表に、メッセージ・タイプごとのマッピングを示します。

表3-1 メッセージのマッピング

メッセージ・タイプ

説明

XML

$bodyのBody要素にXMLドキュメントが含まれます。添付は$attachmentsに含まれます。

バイナリ

$bodyのBody要素に参照XMLドキュメントが含まれます。

添付は$attachmentsに含まれます。

MFL

ドキュメントは、XMLとの相互変換が透過的に行われ、$bodyのBody要素ではXMLドキュメントとして表示されます。

添付は$attachmentsに含まれます。

テキスト

$bodyのBody要素にテキストが含まれます。

添付は$attachmentsに含まれます。

ファイル、FTPおよび電子メール

参照渡しドキュメントの場合、$bodyのBody要素に含まれる参照XMLドキュメントは、トランスポートによってファイル・システムに格納されたドキュメントのURIを参照します。

添付は$attachmentsに含まれます。

SOAP

$bodyのBody要素にSOAP本体が含まれます。$headerのHeader要素にSOAPヘッダーが含まれます。

添付は$attachmentsに含まれます。

各添付の$attachmentsには、次のものが含まれます。

- 添付ファイル:添付ファイルがXMLの場合

- 参照XML :添付ファイルがバイナリの場合

- テキスト:添付ファイルがテキストの場合

3.1.8 コンテンツ・タイプ

Oracle Service Busでは、種類の異なるエンドポイントとの相互運用性をサポートするために、サービスの構成で、使用するコンテンツ・タイプ、JMSタイプ、およびエンコーディングを制御できます。外部クライアントやサービスで必要になるものについては仮定を行わず、かわりにこの目的のために構成されているサービス定義の情報を使用します。Oracle Service Busのアウトバウンド・メッセージのコンテンツ・タイプは、サービス・タイプとインタフェースから派生し、次の仕様を使用します。

- XMLまたはSOAPの場合(WSDLの有無を問わない)、コンテンツ・タイプはtext/XML

- インタフェースがMFLまたはバイナリのメッセージングの場合、コンテンツ・タイプはbinary/octet-stream

- インタフェースがテキストのメッセージングの場合、コンテンツ・タイプはtext/plain

- インタフェースがXMLのメッセージングの場合、コンテンツ・タイプはtext/XML

サービスを呼び出すプロキシ・サービスのアウトバウンド・コンテキスト変数($outbound)のコンテンツ・タイプ、およびプロキシ・サービス・リクエストのインバウンド・コンテキスト変数($inbound)のコンテンツ・タイプはオーバーライドできます。さらに、サービスが管理コンソールで定義される場合に構成できるJMSタイプ(バイトまたはテキスト)があります。すべてのアウトバウンド・メッセージのエンコーディングも、サービス定義で明示的に構成します。

3.2 Oracle Service Busのリソース

Oracle Service Busのリソースとは、再利用可能なエンティティ定義またはエンティティ記述であり、通常はそれらのエンティティのメタデータが含まれています。リソースは複数のサービスで使用可能で、企業や部署全体で使用できるように標準化された定義または記述を持ちます。

Oracle Service Busのリソースおよびサービスは一連のプロジェクトとしてグループ化され、各プロジェクトはフォルダ構造を持ちます。リソースおよびサービスをプロジェクトにまとめることで、名前の競合を回避でき、ビジネス・カテゴリごとにリソースおよびサービスをまとめたり検索したりするのに便利です。

この項では、次のOracle Service Busのリソースについて説明します。

- 3.2.1項「スキーマとデータ型」

- 3.2.2項「変換マップ」

- 3.2.3項「JAR」

- 3.2.4項「WSDL」

- 3.2.5項「プロキシ・サービス」

- 3.3.3項「サービス・アカウント」

- 3.2.6項「サービス・キー・プロバイダ」

- 3.2.7項「アラート宛先」

- 3.2.8項「JNDIプロバイダ」

- 3.2.9項「SMTPサーバー」

3.2.1 スキーマとデータ型

スキーマとは、基本データや構造化データのタイプを表すものです。XMLスキーマは、XMLビジネス・データが従う必要のあるルールを表すXML用語集です。XMLスキーマは、ドキュメントの構造、およびドキュメントに含まれる各要素と属性のデータ型を指定します。XMLスキーマには、他のXMLスキーマをインポートまたは含めることができます。Oracle Service Bus管理コンソールを使用してスキーマを作成する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のXMLスキーマの追加に関する項を参照してください。

Oracle Service Busでは、メッセージ・フォーマット言語(MFL)というメタデータ言語を使用して、型付きの非XMLデータの構造を記述します。Oracle Format Builderツールを使用すると、MFLドキュメントと呼ばれるデータ・ファイルとしてメタデータを作成および管理できます。MFLドキュメントの作成方法については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。

3.2.1.1 タイプ・システム

Oracle Service Busには、設計時に使用できるタイプ・システムが組み込まれています。条件、インプレース更新アクション、または変換のそれぞれについてXQuery式を作成するとき、エディタで変数の型を任意に宣言できるため、XQueryの作成が容易になります。使用できる型は以下のとおりです。

- XMLスキーマ型または要素

- WSDL型または要素

- MFLタイプ

3.2.2 変換マップ

変換マップは、2つの種類の異なるデータ型のソースと宛先サービス間のマッピングを記述したものです。Oracle Service Busは、XQueryまたはeXtensible Stylesheet Language Transformation (XSLT)標準のどちらかを使用したデータ・マッピングに対応しています。また、MFLで記述されたデータは自動的に同等のXMLに変換され、XQueryまたはXSLTでの変換で使用できます。ターゲット・サービスで必要な場合、結果のXMLは自動的にMFLに変換されます。

3.2.3 JAR

JAR (Java ARchive)ファイルとは、Javaクラスを含むzipファイルです。コンパイルされたJavaクラスと、プログラムを構成する関連メタデータの保存に使用します。JARはJavaコード要素用の呼出し可能なプログラム・ライブラリのように機能します(それぞれの要素に対して個別にバインディングを要求するのではなく、単一のコンピレーション・リンクが複数要素へのアクセスを提供)。

JARファイルは再使用可能なOracle Service Busリソースとして登録できます。Java終了メカニズムを提供するJavaコールアウト・アクション、EJBベースのビジネス・サービス、およびTuxedoベースのビジネス・サービスで使用されます。JARリソースの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のJARに関する項を参照してください。

3.2.4 WSDL

WSDL (Web Service Definition Language)インタフェースは、SOAPサービスまたはXMLサービスのサービス・インタフェースを定義します。それは、インタフェース内のオペレーションを含むサービスの抽象インタフェース、およびオペレーションのシグネチャのメッセージ部の型を記述します。また、メッセージ部のメッセージへのバインディング(パッケージング)、およびメッセージのトランスポートへのバインディングを記述できます。さらに、WSDLでは、サービスの具象インタフェース(たとえば、トランスポートURL)を記述することもできます。

Oracle Service Bus管理コンソールを使用して、WSDLを構成する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のWSDLの追加に関する項を参照してください。

3.2.5 プロキシ・サービス

プロキシ・サービスは、Oracle Service Busのローカルにホストされた複数のビジネス・サービスにメッセージをルーティングするのに使用される仲介WebサービスのOracle Service Busでの定義です。プロキシ・サービスは汎用のサービスであり、インタフェースを使用してビジネス・サービスとは独立して構成できます。汎用のプロキシ・テンプレートを使用すると、プロキシ・サービスをインタフェース、メッセージ・フローの定義、およびポリシーの観点から定義することができ、コンテンツ・ベースのルーティング・ロジックに基づいてメッセージを適切なサービスに動的にルーティングします。プロキシ・テンプレートの詳細は、第5章「サービス・コンポジション」の5.1.1.2項「ビジネス・サービス」を参照してください。

プロキシ・サービスは、メッセージ・データをエンドポイントのビジネス・サービスによって必要とされる適切なプロトコル形式にマッピングすることもでき、その結果、動的な実行時のプロトコルの切替えを実現します。プロキシ・サービスで資格証明レベルの検証が必要な場合は、サービス・キー・プロバイダを作成して、Oracle Service Bus管理コンソールを使用したセキュリティ資格証明の管理が行えます。

Oracle Service Bus管理コンソールを使用して、プロキシ・サービスを構成する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のプロキシ・サービスの作成および管理に関する項を参照してください。

3.2.6 サービス・キー・プロバイダ

サービス・キー・プロバイダ・リソースには、プロキシ・サービスがインバウンドSOAPメッセージの復号化、アウトバウンド認証およびデジタル署名に使用する公開鍵インフラストラクチャ(PKI)資格証明情報が含まれます。PKI資格証明とは、デジタル署名や暗号化(Webサービス・セキュリティ)、およびアウトバウンドSSL認証に使用できる証明書とペアになった秘密鍵です。この証明書には、秘密鍵に対応する公開鍵が含まれています。Oracle Service Bus管理コンソールを使用して、サービス・キー・プロバイダを構成する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のサービス・キー・プロバイダの追加に関する項を参照してください。

3.2.7 アラート宛先

アラート宛先リソースは、Oracle Service Busからのアラート通知を受信できる受信者のリストを取り込みます。このリストは、メッセージ・フローで設定されたアラート・アクション、およびSLAアラート・ルールで使用されます。アラート宛先は、レポート・データ・ストリーム、SNMPトラップ、電子メール、JMSキュー、JMSトピックなど1つまたは複数の宛先のタイプを含むことがあります。電子メールおよびJMS宛先の場合は、宛先リソースはそれぞれ電子メール・アドレスまたはJMS URIのリストを含む場合があります。アラート宛先は、サービスのアラート構成全体で再利用できます。

アラート宛先リソースの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のアラート宛先に関する項を参照してください。

3.2.8 JNDIプロバイダ

Oracle Service BusのJNDIプロバイダはグローバルに使用可能なリソースで、JNDI名のオブジェクトへのアクセスに必要な接続および認証の詳細を提供します。たとえば、EJBの起動に使用されるビジネス・サービスで、エンドポイントURIにJNDIプロバイダ・リソースの名前を含めます。ビジネス・サービスが起動すると、Oracle Service Busでは参照されたJNDIプロバイダ・リソースの詳細を使用して、JNDIプロバイダへの初期接続が行われます。

JNDIプロバイダは高度な柔軟性を備えています。JNDI接続が変更された場合、修正する必要があるのはJNDIプロバイダ・リソースのみで、JNDIプロバイダを参照するそれ以外の要素は、更新された構成を自動的に使用します。

JNDI プロバイダの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のJNDI プロバイダの追加に関する項を参照してください。

3.2.9 SMTPサーバー

SMTPサーバー・リソースは、電子メール宛先、ポート番号および必要な場合に認証資格に対応するSMTPサーバーのアドレスを指定します。それは、Oracle Service Busドメインにあるプロジェクト間で、アラート宛先リソースで使用されるグローバル・リソースです。

SMTPサーバー・リソースの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のSMTPサーバーの追加に関する項を参照してください。

3.2.10 JCAバインディング

Oracle Service BusのJCAバインディング・リソースを使用すると、Oracle SOA Suite JCAアダプタを介して外部サービスと相互作用するビジネス・サービスとプロキシ・サービスを作成できます。JCAバインディングはサービスWSDLとOracle JDeveloperで作成された対応する.jcaファイルで構成されます。

詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のJCAバインディングに関する項を参照してください。

3.3 Oracle Service Busのセキュリティ

Oracle Service Busでは、実績のあるOracle Service BusのOracle WebLogicセキュリティ・フレームワークを使用して、より高度なセキュリティ・サービスを構成します。これには、認証、IDアサーション、認可、ロール・マッピング、監査、資格証明マッピングなどが含まれます。Oracle WebLogic Serverのセキュリティを構成した後、コンソールを使用してセキュリティを構成できます。

コンソールには事前定義されたルールがあります。これによりOracle WebLogic Serverセキュリティ・プロバイダの使用がオペレーションのいくつかの異なるレベルにおいて簡素化されます。サポートされるセキュリティ・レベルの詳細は、3.3.4項「セキュリティ・レベル」を参照してください。

Oracle Service Busのセキュリティ機能の詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のセキュリティに関する項を参照してください。

3.3.1 Oracle Web Services Manager

Oracle Service BusサービスとともにOracle Web Services Managerのポリシーを使用することで、サービスを保護できます。Oracle Web Services Managerは、Oracle Enterprise Manager Fusion Middleware Controlのコンポーネントで、Oracle SOA Suite環境およびアプリケーションの集中管理および制御を可能にする実行時フレームワークです。

詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のOracle Web Services ManagerでのOracle Service Busの保護に関する項を参照してください。

3.3.2 WS-Policy

Webサービス・ポリシー(WS-Policy)は、Webサービスのセキュリティ制約と要件を定義するための標準ベースのフレームワークです。それは、それぞれ1つまたは複数のアサーションを含む、ポリシーと呼ばれるXML文の集合でセキュリティ制約と要件を表します。Oracle Service Busでは、WS-Policyアサーションを使用して、デジタル署名や暗号化に対するWebサービスの要件、および必要なセキュリティ・アルゴリズムや認証メカニズムを指定します。

WS-PolicyポリシーはWSDLドキュメントに直接、または参照によって含まれます。WSDLドキュメントは、WS-Policyポリシーを含むか参照する他のWSDLドキュメントをインポートできます。これらのポリシーを含むXMLファイルは、複数のプロキシ・サービスまたはビジネス・サービスから使用できます。WebLogic Webサービス実行時環境では、2つのタイプのWS-Policy文を認識します。

- 具象WS-Policy文では、認証、暗号化、およびデジタル署名のために使用されるセキュリティ・トークンを指定します。必要な認証のタイプ(X.509またはSAMLトークンの使用など)、暗号化やデジタル署名に使用されるキーストアからの複数の秘密鍵と証明書のペアが実行時にわかっている場合は、これらのWS-Policy文が作成されます。

- 抽象WS-Policy文ではセキュリティ・トークンを指定しません。

抽象ポリシーが受け取るセキュリティ・トークンのタイプは、Oracle Service Busの実行時環境で決定します。実行時環境の構成については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のOracle Service Busのプロキシ・サーバーとビジネス・サービスでのWS-Policyの使用を参照してください。

ポリシーはURIによって参照され、WSDL、HTTP URI、またはポリシーURIのいずれかに埋め込まれます(例: policy:myPolicy)。ポリシーURIでは組み込まれたポリシーを参照できます。WS-Policyの詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。

3.3.3 サービス・アカウント

サービス・アカウント・リソースは、ユーザー名とパスワードを提示します。このユーザー名とパスワードは、プロキシ・サービスとビジネス・サービスがアウトバウンド認証を行うとき、またはプロキシ・サービスとビジネス・サービスがFTPサーバーやJMSサーバーなどのローカルまたはリモート・リソースを認証するときに使用します。たとえば、ビジネス・サービスがWebサービスによるトランスポート・レベルの認証でユーザー名とパスワードを提示する必要がある場合、サービス・アカウントを作成してユーザー名とパスワードを指定できます。次にビジネス・サービスを構成して、サービス・アカウントの資格証明がアウトバウンド・リクエストに含まれるようにします。1つのサービス・アカウントを複数のビジネス・サービスおよびプロキシ・サービスに使用できます。サービス・アカウント・リソースの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のサービス・アカウントに関する項を参照してください。

3.3.4 セキュリティ・レベル

Oracle Service Busには、次の種類のセキュリティ機能が用意されています。

- 認証

- IDアサーション

- 認可

- 監査

- 資格証明マッピング

次のトピックでは、Oracle Service Busのセキュリティ・モデルで使用できるセキュリティ機能について説明します。

3.3.4.1 インバウンド・セキュリティ

インバウンド・セキュリティによって、Oracle Service Busプロキシ・サービスは、認可されたクライアントからのリクエストのみを処理することが保証されます(デフォルトでは、すべての匿名ユーザーまたは認証ユーザーがプロキシ・サービスに接続できます)。また、クライアントからデータが送信されたときに、認可されていないユーザーがそのデータを参照または変更していないことが保証されます。

プロキシ・サービスは、サービス・コンシューマと他のプロキシ・サービスという2つのタイプのクライアントを持つことができます。インバウンド・セキュリティは、プロキシ・サービスの作成時に設定され、セキュリティ要件の変化によって決定されます。外向きのプロキシ・サービス(サービス・コンシューマからリクエストを受信します)の場合は、双方向SSL over HTTPSなどの厳密なセキュリティ要件が設定されます。他のOracle Service Busプロキシ・サービスからのみリクエストを受信することが保証されているプロキシ・サービスの場合は、これよりセキュリティの低いプロトコルが使用されます。プロキシ・サービスで、デジタル署名、暗号化、またはSSL認証に対して公開鍵インフラストラクチャ(PKI)テクノロジを使用する場合は、証明書とペアの秘密鍵を提供するサービス・キー・プロバイダを作成します。

各プロキシ・サービスに対し、次のインバウンド・セキュリティのチェックを構成できます。

- トランスポート・レベルのセキュリティは、クライアントとプロキシ・サービス間の接続確立の一部としてセキュリティ・チェックを適用します。トランスポート・レベルのセキュリティによって適用できるセキュリティ要件は、プロキシ・サービスで使用するように構成するプロトコルによって異なります。サポートされる各プロトコルに対するトランスポート・レベルのセキュリティの構成については、「トランスポート・レベルのセキュリティの構成」を参照してください。詳細は、3.3.4.6項「トランスポート・レベルのセキュリティ」を参照してください。

- カスタム認証は、メッセージ・レベルのセキュリティ用で、トランスポート・レベルおよびメッセージ・レベルのインバウンド・リクエストでのクライアント指定のカスタム認証資格証明のためのものです。カスタム認証資格証明は、カスタム・トークン、またはユーザー名とパスワードの形式になります。詳細は、3.3.5,項「カスタム・セキュリティ資格証明」を参照してください。

- メッセージ・レベルのセキュリティは、Webサービスであるプロキシ・サービスのためのものです。これはWS-Security仕様の一部です。メッセージ・レベルのセキュリティでは、SOAPメッセージまたはSOAPメッセージの特定の部分を処理する前にセキュリティ・チェックを適用します。詳細は、3.3.4.7項「メッセージ・レベルのセキュリティ」を参照してください。

3.3.4.2 アウトバウンド・セキュリティ

アウトバウンド・セキュリティは、プロキシ・サービスとビジネス・サービス間の通信を保護します。プロキシ・サービスを構成するタスクの大半は、ビジネス・サービスが指定するトランスポート・レベルのセキュリティまたはメッセージ・レベルのセキュリティの要件に準拠しています。ビジネス・サービスでデジタル署名またはSSL認証のためにPKIテクノロジを使用する必要がある場合は、証明書とペアの秘密鍵を提供するサービス・キー・プロバイダが作成されます。詳細は、 『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のサービス・キー・プロバイダに関する項を参照してください。

3.3.4.3 IDの伝播のオプション

IDの伝播のオプションでは、クライアントが提示するIDの伝播方法など、Oracle Service Busのセキュリティを設計するときの判断を行うことができます。Oracle Service Busの構成によって、次のことを実行できます。

- クライアントが提供する資格証明を認証します。

- 認可チェックを実行します。

- クライアント資格証明を変更せずにビジネス・サービスに渡します。

- ビジネス・サービスが認証および認可できる別の資格証明にクライアント資格証明をマップします。

- セキュリティ・テクノロジ間を橋渡しします。

これらのOracle WebLogic Serverセキュリティ・プロバイダおよびOracle WebLogic Serverセキュリティ・アーキテクチャ全般の詳細な説明は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』を参照してください。

Oracle Service Busセキュリティでは、WS-Policy仕様がサポートされます。WS-Policy仕様の詳細は、次の場所にあるWeb Services Policy Framework (WS-Policy)とWeb Services Policy Attachment (WS-PolicyAttachment)に関する記述を参照してください: http://specs.xmlsoap.org/ws/2004/09/policy/。

Oracle Service Bus管理コンソールでは、サービスにセキュリティ・ポリシーを構成し、そのインタフェース内のメッセージにセキュリティ・ポリシーを適用できます。セキュリティ・ポリシーの適用対象として、サービスを指定することも、サービスのオペレーションに関連する個々のメッセージを指定することもできます。サービスに対してセキュリティ・ポリシーを指定した場合、そのサービスのすべてのメッセージにポリシーが適用されます。

Oracle Service Busでは、オペレーションのレベルごとに異なるOracle WebLogic Serverセキュリティ・プロバイダを使用できます。次のセキュリティのレベルがサポートされます。

- 3.3.4.4項「ユーザー管理」

- 3.3.4.5項「管理セキュリティ」

- 3.3.4.6項「トランスポート・レベルのセキュリティ」

- 3.3.4.7項「メッセージ・レベルのセキュリティ」

セキュリティ・レベルの詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。

3.3.4.4 ユーザー管理

Oracle Service Busのユーザー管理は、Oracle WebLogic Serverの統合されたセキュリティ・フレームワークに基づいて作成されています。このフレームワークにより、Oracle Service Bus管理コンソールでは、任意のグループまたは個々のユーザーに割り当てられたロールに関連付けられているセキュリティ・ポリシーを基にしたタスク・レベルの認可がサポートされます。Oracle WebLogic Serverのセキュリティ・フレームワークの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』を参照してください。

Oracle Service Bus管理コンソールはOracle Service Busのユーザー、グループおよびロールの管理に使用されます。Oracle Service Bus管理コンソールを使用して、Oracle Service Busのユーザー、グループおよびロールを管理する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のセキュリティ構成に関する項を参照してください。

3.3.4.5 管理セキュリティ

プロキシ・サービスの作成などの管理機能にユーザーがアクセスできるようにするため、事前定義されたアクセス権限を持つ4つのセキュリティ・ロールのいずれかにユーザーを割り当てることができます。セキュリティ・ロールは、実行時に評価される条件に基づきユーザーまたはグループに動的に与えることのできるIDです。Oracle Service Bus管理セキュリティ・ロールのアクセス権限は変更できませんが、どのユーザーまたはグループをあるロールにするための条件は変更できます。

デフォルトでは、Oracle Service Busドメインで最初に作成されるユーザーはOracle WebLogic Server管理者です。このユーザーは、Oracle Service Busのすべてのオブジェクトおよび機能にアクセスでき、ユーザー管理タスクを実行してOracle Service Bus管理コンソールの機能へのアクセス制御を行うことができます。

Oracle Service Busユーザーに割り当てることのできるデフォルトのロールを次に示します。

- IntegrationAdmin

- IntegrationDeployer

- IntegrationMonitor

- IntegrationOperator

管理セキュリティの構成については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』の管理セキュリティの構成の主な手順に関する項を参照してください。

Oracle Service Bus管理コンソールを使用して、Oracle Service Busのユーザー、グループおよびロールを管理する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のセキュリティ構成に関する項を参照してください。

3.3.4.6 トランスポート・レベルのセキュリティ

Oracle Service Busでは、トランスポート・レベルの機密性、メッセージの整合性、および一方向のリクエストまたは双方向(リクエスト/レスポンス)の(クライアントからOracle Service Busへの)トランザクションでのクライアント認証がHTTPS経由でサポートされます。次のいずれかのクライアント認証を要求するように、HTTP(S)のプロキシ・サービスまたはビジネス・サービスを構成できます。

- 基本(ユーザー名/パスワード)クライアント認証

- クライアント証明書(双方向SSL)によるクライアント認証

- クライアント認証なし

プロキシ・サービスがアクティブになると、シンWebアプリケーションが生成されます。Oracle Service Busは、セッション管理、クライアント証明書の検証および認証、信頼性の管理、およびサーバーのSSLキー/証明書の操作といったサーバー側SSLの部分でOracle WebLogic Serverに依存します。

Oracle Service Busでサポートされる、HTTP以外のトランスポート方式でのトランスポート・セキュリティは次のとおりです。

- 電子メール・トランスポートおよびFTPトランスポートでは、FTPサーバーまたは電子メール・サーバーへの接続に資格証明を要求することでセキュリティが確保されます。

- ファイル・トランスポートでは、ファイルが存在するマシンへのログイン・コントロールを使用したセキュリティが提供されます。

詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。

3.3.4.7 メッセージ・レベルのセキュリティ

Oracle Service Busでは、OASIS Web Services Security (WSS) 1.0をサポートしています。WSS仕様の詳細は、次の場所にあるOASIS Web Services Security TCを参照してください: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss。

WSSは、メッセージの機密性、整合性、およびSOAPメッセージでのセンダー認証を実現するためのフレームワークを定義します。Oracle Service BusでWSSを使用することにより、デジタル署名または暗号化、あるいはその両方を使用するメッセージを保護できます。WSSは、トランスポート・レベルのセキュリティとしては使用できませんが、エンド・ツー・エンドのメッセージで機密性および整合性を確保するのに適しています。

SOAPエンベロープの一部の要素のみに署名または暗号化、あるいはその両方を適用し、残りの要素には署名または暗号化を適用しないことが可能であるため、SSLよりも柔軟性に富んでいます。これは、Oracle Service Busの機能と結合されると、メッセージのコンテンツに基づいてデータのルーティングの決定およびデータの変換を行うための強力な機能になります。現在Oracle Service Busでは、HTTP/SおよびJMSを介したWSSがサポートされます。

3.3.5 カスタム・セキュリティ資格証明

Oracle Service BusのクライアントのIDを認証するには、基本認証、クライアント証明書(双方向SSL)、およびWebサービス・セキュリティという複数の方法があります。ビジネス・サービスおよびプロキシ・サービスに関連付けられたクライアント資格証明は、Oracle WebLogic Serverを使用して直接管理されます。トランスポート・レベルとメッセージ・レベルのインバウンド・リクエストに対するクライアント指定のカスタム認証資格証明もサポートされています。カスタム認証資格証明は、トークン、またはユーザー名とパスワードのトークンの組合せになります。

Oracle Service Busでは、以下の認証をサポートしています。

- HTTPヘッダー、SOAPヘッダー(SOAPベースのプロキシ・サービスの場合)、またはペイロード(非SOAPプロキシ・サービスの場合)でプロキシ・サービスに渡されるカスタム・トークン。

- SOAPヘッダー(SOAPベースのプロキシ・サービスの場合)またはペイロード(非SOAPプロキシ・サービスの場合)で渡されるユーザー名およびパスワード・トークン。

- カスタム認証メカニズムは、単独で使用するか、またはWebサービスのメッセージ・レベル・セキュリティと組み合せて使用できます。

カスタム・セキュリティ資格証明の詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のカスタム認証の構成に関する項を参照してください。

3.3.6 関連トピック

- Oracle Service Busセキュリティに関するFAQ

- 『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のセキュリティ構成に関する項

- 『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のOracle Service Busのプロキシ・サービスとビジネス・サービスでのWS-Policyの使用に関する項

- 『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』の本番環境でのOracle Service Busの保護に関する項

4 サービス構成

この章では、Oracle Service Busが提供するサービス構成とリソース編成機能について説明します。サービス検出と変更管理をサポートしている機能を取り上げます。この項は、SOAにおいてサービスの構成を担当するITデプロイメントのスペシャリストを対象としています。

この章の内容は以下のとおりです。

- 4.1項「リソース編成」

- 4.2項「変更管理」

- 4.3項「サービス検出」

4.1 リソース編成

Oracle Service Busにはリソースの作成と編成、構成を行うための堅牢なリソース構成および編成フレームワークがあり、リソース依存関係間でのセマンティクスの整合性が保たれています。リソースを迅速にテストおよびデプロイし、必要に応じてリソース構成の更新を元に戻す機能が備わっています。

4.1.1 プロジェクト・エクスプローラ

Oracle Service Busに組み込まれているプロジェクト・エクスプローラでは、Oracle Service Busエンティティの論理的なグループ化ができるので、開発者や管理者は大きな開発プロジェクトにおいて関係のある部分をより適切に編成できます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のプロジェクト、フォルダおよびリソースの使用に関する項を参照してください。

4.1.2 プロジェクトとフォルダ

Oracle Service Busのリソースは独立したプロジェクトに編成することができます。プロジェクトは階層化されない、独立した最上位のグループ構造です。サービス、WS-Policy、WSDL、XQuery変換などすべてのリソースは、1つの重複しないプロジェクトのみに含まれます。

リソースはプロジェクトの直下に作成することも、整理用にフォルダを作成したうえで、フォルダ内に作成することもできます。フォルダはプロジェクトの中に作成されることも、他のフォルダの中に作成されることもあり、プロジェクト・レベルをルート・ディレクトリとするファイル・システムのディレクトリに似ています。すべてのプロジェクトおよびフォルダには、ナビゲーションをさらに容易にするために、説明を追加することができます。図4-1に、Oracle Service Bus管理コンソールのプロジェクトとフォルダのビューを示します。

図4-1 Oracle Service Busプロジェクトとフォルダのプロジェクト・エクスプローラ・ビュー

リソースをプロジェクト間またはフォルダ間で移動したり、リソースの名前を変更することができます。Oracle Service Busのすべてのリソース、プロジェクト、またはフォルダは、クローンを作成して、指定されたターゲットIDを使用してリソースのコピーを作成できます。プロジェクトまたはフォルダのクローンを作成すると、そのプロジェクトまたはフォルダのすべてのアーティファクトが別の場所にコピーされます。

プロジェクト内のリソースから、別のプロジェクトで定義されたリソースを参照および使用できます。リソースの名前を変更したり、リソースを移動したりしても、依存関係は維持されます。名前を変更されたリソースまたは移動されたリソースに対するすべての参照は自動調整されます。プロジェクト・エクスプローラには、現在のフォルダの外側にあるどのリソースが、フォルダ内にあるリソースから参照されているかを追跡する追加の機能があります。この参照を表示することで、参照されているリソースがある場所(<project name>/<folder name>/<resource name>の形式)と、参照されているリソースの種類の両方を知ることができます。参照されているリソースの詳細は、4.2.5項「依存関係の追跡」を参照してください。

4.1.3 リソース・キャッシュ

Oracle Service Busには、リソース・キャッシュ内の大量のリソースを整理するためのいくつかの機能があります。Oracle Service Busリソース・キャッシュに保持されるリソースには、WSDL、XMLスキーマ、XQuery、XSLT、MFL、WS-Policy、ビジネス・サービス、プロキシ・サービスなどがあります。Oracle Service Busでは、メッセージの処理方法を決定する際に、リソースおよびサービスに関するユーザー構成メタデータに依存します。

Oracle Service Busは、リソース・キャッシュ内のリソースやサービスの管理を担当する信頼あるIT部門スペシャリストを支援することに重点を置いています。このようなユーザーはすべてIntegration AdministratorまたはIntegration Deployerとして定義され、リソース・キャッシュ内のすべてのリソースを変更するための完全なパーミッションが与えられます。Integration Monitorユーザーにはリソース・キャッシュに対する完全な読込みアクセス権が与えられますが、リソースの変更はできません。通常、それはリソースやサービスの検索や参照を行うユーザーです。Integration Operatorユーザーには、リソース・キャッシュに対する完全な読込みアクセス権が与えられ、サービスの動作特性だけを変更できます。

Oracle Service Busのユーザーとロールの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のセキュリティ構成に関する項を参照してください。

4.2 変更管理

この項では、Oracle Service Busの変更管理について説明します。

4.2.1 チェンジ・センター

チェンジ・センターは、Oracle Service Busの最も重要な機能の1つであり、サービス・バス内で構成の変更を行うための鍵となります。チェンジ・センターには、変更を行っている最中に現在の構成をロックするというユニークな機能があります。この機能により、サービス・バスでサービスについてのリクエストの受信と処理を継続しながら、Oracle Service Bus管理コンソールから構成の変更を行うことが可能になっています。

さらに、変更中の構成が「アクティブ化」されるまで、現在のシステムの構成は影響を受けません。アクティブ化が行われると変更は即座に有効になり、Oracle Service Busでは直ちに新しい構成が使用されます。

注意:
負荷の高い状況下では、プロキシ・サービス・パイプラインをアクティブ化するプロセス中にリクエスト・メッセージを受信するとエラーが発生する場合があります。プロキシ・サービス・パイプラインのアクティブ化が完了すると、新規のリクエストは正常に処理されます。

アクティブ化された変更によって、予期しない不都合なイベントが発生した場合に備えて、チェンジ・センターには任意のセッションで行われた変更を取り消す機能も用意されています。「タスクの詳細」には、変更されたリソース、変更を行ったユーザー、および変更が行われた時間についての情報が表示されます。セッション全体またはセッション内の個別の変更をロール・バックすることが可能なので、Oracle Service Busでは影響を受けた構成を以前の状態にロール・バックできます。

チェンジ・センターの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のチェンジ・センターの使用に関する項を参照してください。

4.2.2 セッション

Oracle Service Busでリソースを変更する前に、セッションを作成する必要があります。Oracle Service Bus管理コンソールでのすべての変更は、特定のセッション内で行います。

図4-2 チェンジ・センターでのセッション管理

セッションは、変更を行っているユーザー以外にはその変更内容が公開されないサンドボックス環境と考えることができます。つまり、変更内容は、変更を行っている他の同時ユーザーからは見えません。セッション内で行われた変更は、セッションがアクティブ化されるまではサーバーにデプロイされません。一度にアクティブ化できるセッションは1つに限られるため、Oracle Service Bus管理コンソールへのログインは1つのブラウザのみで行ってください。

特定のセッションで変更されたリソースと実行時にデプロイされているリソースを比較するには、セッションを一時的に終了し、デプロイされているリソースを参照してからセッションを再開し、変更されたリソースを参照します。セッション内のすべてのリソースを見ることができます。セッション内のすべてのリソースを表示するビューをセッション・ビューと呼びます。セッション・ビューは、デプロイされている未変更のリソースのビューと現在のセッションで変更されたリソースのビューを結合したビューです。セッションがアクティブ化されていれば、セッション・ビューには常に構成の状態が示されます。セッションの外部のリソースのビューは、デプロイされているリソースのビューです。

セッションの個々の変更、アクティブ化、およびセッションの取消し操作はトランザクションとして行われ、障害時のデータ消失を防ぎます。セッションは永続的で長時間継続でき、サーバーを再起動してもアクティブなセッションは失われません。そのため、必要に応じて、1つのセッションでの構成の変更を、数日間にわたって継続できます。ユーザーごとに固有のセッションを持ち、他のユーザーをシステムからロック・アウトする必要もなく、独立して操作を行うことができます。

別のユーザーがセッションのアクティブ化を実行しているときにセッションをアクティブ化することはできません。別のユーザーがセッションのアクティブ化を実行していると、「アクティブ化」ボタンが無効になり、そのセッションのアクティブ化が完了するまでは、セッションをアクティブ化できません。ページを更新していない場合や直接MBeanを使用している場合には、「アクティブ化」ボタンが無効にならないことがあります。この場合はやがてタイムアウトします。

管理者には、他のユーザーのセッションにアクセスし、変更中の内容を参照して、セッションを更新または破棄する権限があります。

詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のチェンジ・センターの使用に関する項を参照してください。

4.2.3 同時変更

セッションでは、競合にオプティミスティック方式を使用します。セッションをアクティブ化すると、そのセッションで行ったリソースの変更が他のセッションにすぐに表示されます。別のユーザーのアクティブなセッションで開いている、変更されたリソースをデプロイすると、そのユーザーのセッションでユーザーが変更をしてから、デプロイされているリソースが実行時に変更されたことを示すメッセージがチェンジ・センターで受信されます。ここで、アクティブなセッションのユーザーは次の操作を実行できます。

- 現在のセッションでのそのリソースに対する変更を破棄します。セッションのリソースは、新しくデプロイされたリソースで更新されます。

- 現在のセッションをアクティブ化します。これにより、実行時のリソースは現在のセッションの変更内容で上書きされます。これはデフォルトの動作です。

詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のチェンジ・センターの使用に関する項を参照してください。

4.2.4 構成の変更の追跡

セッションをアクティブ化したすべてのユーザー、およびセッションで変更されたリソースと変更日時のログがシステムで保持されます。このログは、特定のリソースまたはプロジェクトの変更履歴となるだけでなく、企業における監査および追跡にも使用できます。このログはOracle Service Bus管理コンソールのチェンジ・センターで表示できます。

4.2.5 依存関係の追跡

大量のリソースを管理するうえで重要な要素として、リソース間の依存関係の設定と調査があります。たとえば、サービスが実装するWSDLや、メッセージ・フローの構成で使用されるXQueryが識別されると便利です。Oracle Service Busにはリソース間の参照を自動追跡し、依存関係のグラフを作成する機能があります。Oracle Service Bus管理コンソールのセッション・ビューおよびデプロイされたビューでは、特定のリソースに関する次の情報が表示されます。

- 参照先リソース

- 参照元リソース

また、Oracle Service Bus管理コンソールでは、プロジェクトおよびフォルダごとに、選択されたプロジェクトまたはフォルダ内のリソースを参照する外部リソースが表示されます。Oracle Service Bus管理コンソールは特定のプロジェクトまたはフォルダが参照するリソースも表示します。Oracle Service Bus管理コンソールで参照されているリソースの名前をクリックするだけで依存関係のグラフを簡単に辿ることができます。

この機能を使用して、リソース・キャッシュ内の部門プロジェクト間の依存関係や、部門プロジェクトと全社的な共有プロジェクトとの依存関係を識別することができます。

リソースの名前を変更したり、リソースを移動したりしても、依存関係は維持されます。名前を変更されたリソースまたは移動されたリソースに対するすべての参照は自動調整されます。

4.2.6 セマンティクスの整合性

Oracle Service Busでは、セッション・ビュー内のすべてのリソースの整合性が保護されます。セッション・ビュー内のすべてのリソースの現在の検証エラーのすべてを一覧表示するには、チェンジ・センターで「競合の表示」リンクをクリックします。参照先リソースを変更すると、参照元のリソースで検証エラーが発生する可能性があります。

Oracle Service Busでは、ほとんどのセマンティクス・エラーでリソースを作成できます。ただし、セッションをコミット可能にするには、このようなエラーをすべて修正する必要があります。

検証エラーの一部のクラスは一切許容されません。許容されない検証エラーがあるリソースを更新しようとすると、更新は失敗します。たとえば、構成でXQueryの使用が指定されている箇所で、XQueryのかわりに任意のテキストを入力することはできません。任意のテキストを入力すると、更新は失敗します。Oracle Service Bus管理コンソールのXQueryエディタおよびXPathエディタには、式を検証する機能があります。設計時にXQuery式およびXPath式を検証するには、「検証」をクリックします。検証により、無効な構成が原因となる実行時エラーが発生する可能性が低くなります。

4.2.7 リソースとセッションに対する変更の取消し

現在のセッションのOracle Service Bus構成で実行したタスクを取り消したり、セッションの外部で行った、セッションのアクティブ化を取り消すことができます。

4.2.7.1 リソース変更の取消し

セッションでの作業時に、そのセッションで行った変更のリストを表示するには、チェンジ・センターで「変更の表示」をクリックします。特定のタスクをチェンジ・センターで取り消すことができます。取消し操作を実行すると、オブジェクトのセマンティクスが無効になる場合があります。たとえば、WSDLのオペレーション名の変更を取り消すと、そのWSDLを使用するサービスの該当オペレーションにルーティングするプロキシ・サービスのセマンティクスは無効になります。これらの検証エラーは、チェンジ・センターで「競合の表示」リンクをクリックすると、すぐに表示されます。

タスクの取消しはどのような順序でも(個々の取消し操作を行った結果のデータが有効である限り)実行できますが、取り消す順序によって最終的な構成が異なる場合があります。取消し操作によって、リソースの値が、そのリソースを変更する前の値に設定されます。取り消そうとしているタスクがオブジェクトを作成したタスクである場合、そのオブジェクトには戻すことができる前の状態がありません。つまり、このタスクを実行する前は、オブジェクトが存在しませんでした実際には、取消し操作により、セッションから作成したオブジェクトが削除されます。この場合、削除されるオブジェクトを参照するオブジェクトにエラーが発生します。このようなエラーは、チェンジ・センターの「競合の表示」ページで確認できます。

4.2.7.2 セッションのアクティブ化の取消し

セッションで作業していないときに、セッションのアクティブ化のリストを表示するには、チェンジ・センターで「変更の表示」をクリックします。セッションのアクティブ化をチェンジ・センターで取り消すことができます。セッションを取り消すと、そのセッションのアクティブ化が取り消され、そのセッションで実行された操作がすべて取り消されます。セッションのアクティブ化を取り消す操作によって実行時構成にエラーが発生する場合は、セッションのアクティブ化を取り消すことはできません。

たとえば、デプロイメントを取り消すと他のオブジェクトによって参照されているオブジェクトが削除される場合は、このデプロイメントの取消し操作は実行できません。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のタスクの取消しに関する項を参照してください。

4.3 サービス検出

この項では、Universal Description, Discovery and Integration (UDDI)を使用するOracle Service Busのサービス検出機能について説明します。

4.3.1 UDDIレジストリ

UDDIレジストリは、企業でWebサービスを共有するために使用されます。UDDIサービスを使用することで、企業はこれらのWebサービスを整理およびカタログ化し、企業内または信頼できる外部のパートナと共有および再利用できます。

Web サービスのUDDIレジストリ・サービスは、http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3にあるUDDI仕様で定義されています。

UDDIレジストリは、この仕様に基づいています。この仕様には、UDDIを使用してWebサービスの情報をパブリッシュおよび検索する方法の詳細が記載されています。仕様はサービスの実行時の様相は定義していません(それは、サービスの単なるディレクトリです)。UDDIは、企業のビジネス、ビジネス・サービス、および公開するサービスの技術的な詳細を分類するためのフレームワークを提供します。

レジストリへサービスをパブリッシュするには、サービス・タイプと、レジストリ内でそのサービスを表すデータ構造の知識が必要です。レジストリ・エントリには、特定のプロパティが関連付けられ、これらのプロパティ・タイプはレジストリの作成時に定義されます。レジストリにサービスをパブリッシュして、他の組織がそのサービスを検出して使用できるようにすることが可能です。

Oracle Service Busで開発されたプロキシ・サービスは、UDDIレジストリにパブリッシュできます。Oracle Service Busは、Oracle Service Registryを含めたUDDI 3.0準拠の任意のレジストリに対応しています。

図4-3 Oracle Service BusとUDDIの統合

4.3.2 UDDIレジストリの利点

UDDIを使用することにより、コードの再利用が増えるなど、設計時にも実行時にもIT管理者にとって様々な利点があります。開発者にも次のような利点があります。

- UDDIにより、プロキシ・サービスの情報をレジストリにパブリッシュすることでインフラストラクチャ管理が改善され、サービスを検索しやすいように分類できます。そのため、サービス・ポートフォリオの増大と共に、サービス間の関係、コンポーネントのバージョン管理、および依存関係の把握および管理が容易になります。

- UDDIサービスをレジストリからインポートして、Webサービスを呼び出すために必要なパラメータ、および必要な転送プロトコルとセキュリティ・プロトコルを構成できます。

- 規格準拠のWebサービスの使用およびビジネス・アプリケーションでのビジネス・サービスの開発を促進し、Webサービス開発者にリソース・ライブラリへのリンクを提供します。これによって、開発のライフ・サイクルが短縮され、生産性が向上します。また、規格準拠のリソースを共有することで、ビジネス・アプリケーション間の相互運用性の実現の可能性が増加します。

- Webサービスの検索と検出のためのユーザー・フレンドリなインタフェースを提供します。ユーザーが指定した条件で検索できます。

Oracle Service Registry

Oracle Service Registryは、バージョン3に準拠したUDDIレジストリでOracle Service Busでの動作が認定されています。それはOracle Service Busには付属していません。

Oracle Service Registryについては、Oracle Service Registry製品のドキュメントを参照してください。

Oracle Service Bus管理コンソールでは、使いやすいOracle Service Registryまたはバージョン3に準拠したUDDIレジストリにアクセスできます。Oracle Service BusをUDDIと組み合わせて使用することにより、規格ベースのWebサービスの再利用が促進されます。この方法で、広範囲に分散したユーザーがOracle Service Busリソースを検索および検出し、利用できるようになります。すべてのWebサービスおよびUDDIは一連の規格に基づいて構築されているため、再利用により、テスト済で受け入れ可能なWebサービスやアプリケーション開発の規格の使用が企業全体で促進されます。Webサービスとインタフェースは、タイプ、機能、または分類に応じてカタログ化すると、検索や管理がさらに容易になります。

Oracle Service Registryのパーミッションは、管理者がユーザーのパーミッションをOracle Service Registryで管理し、様々なユーザー・タイプのニーズに合わせたビューをレジストリに作成するために開発されました。Oracle Service Busに設定されたユーザー・パーミッションによって、レジストリへのアクセス、レジストリの内容、および使用できる機能が管理されます。

4.3.2.1 UDDIレジストリへのプロキシ・サービスのパブリッシュ

Oracle Service Bus管理コンソールを使用して、Oracle Service Registryにプロキシ・サービスをパブリッシュできます。すべてのプロキシ・サービスをUDDIレジストリにパブリッシュできます(サービスのタイプは、WSDL、メッセージング、すべてのSOAP、すべてのXMLです)。プロキシ・サービスをUDDIレジストリにパブリッシュする方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のUDDIレジストリへのプロキシ・サービスのパブリッシュに関する項を参照してください。

4.3.2.2 UDDIレジストリからのサービスのインポート

レジストリにあるサービスをOracle Service Busビジネス・サービスとしてインポートできます。サポートされるサービスのタイプは、SOAP over HTTPバインディングのWSDLサービスおよびOracle Service Busプロキシ・サービス(主にマルチ・ドメイン・デプロイメントで使用される)です。ビジネス・サービスをOracle Service Busにインポートする方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のUDDIレジストリからのビジネス・サービスのインポートに関する項を参照してください。

4.3.2.3 UDDIを使用したサービスの自動同期

Oracle Service Busのサービス定義は、UDDIのサービス定義と(双方向で)自動的に同期できます。Oracle Service Busで作成または変更されたサービスを、自動的にUDDIレジストリにパブリッシュできます。また、ビジネス・サービス定義をUDDIからインポートし、元のサービスがUDDIで変更された場合に自動的に更新できます。また、サービスがUDDIレジストリで変更された場合に同期の承認を求めるメッセージを表示するよう、Oracle Service Bus管理コンソールを構成できます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のUDDIレジストリの構成に関する項を参照してください。

4.3.3 関連トピック

- 『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のUDDIに関する項

- http://www.oasis-open.org/committees/uddi-spec/doc/tns.htmの技術ノート。特にUDDIレジストリでのWSDLの使用に関する記述を参照してください。

- UDDI製品および開発ツールの情報は、http://uddi.org/solutions.htmlのOASIS UDDIソリューション・ページを参照してください。

- UDDI仕様については、http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htmを参照してください。
この仕様により定義される内容は以下のとおりです。

- アプリケーションがUDDIレジストリに対して情報の照会やパブリッシュを行うために使用するSOAP API

- レジストリ・データ・モデルのXML SchemaスキーマとSOAPメッセージ・フォーマット

- SOAP APIのWSDL定義

- UDDI登録の識別や分類に使用できる様々なIDやカテゴリ・システムのUDDIレジストリ定義(tModel)

- UDDIレジストリを効率よくデプロイおよび使用するための、技術ノートとベスト・プラクティス・ドキュメントは、http://uddi.orgのOASIS UDDI Webサイトにあります。

5 サービス・コンポジション

この章では、Oracle Service Busのサービス・コンポジション機能について説明します。サービス構成を可能にする操作機能、メッセージ構造とメッセージ・フローの作成に関連する主要な概念について取り上げます。統合を目的とするIT設計者で、メッセージングとサービス指向アーキテクチャ(SOA)の担当者、サービス・モデル作成者または設計者を対象としています。

この章の内容は以下のとおりです。

- 5.1項「動的なコンテンツ・ベースのルーティング」

- 5.2項「メッセージ・フローの作成」

- 5.3項「変換」

- 5.4項「エラー処理」

5.1 動的なコンテンツ・ベースのルーティング

Oracle Service Busは種類の異なるサービス・エンドポイント間でサービス・リクエストとレスポンス・メッセージを仲介し、これらの間でメッセージをインテリジェントにルーティングします。コンテンツ・ベースのルーティングは、Oracle Service Busが条件付きメッセージの処理と変換機能に基づいてサポートする仲介機能です。このルーティング機能により、SOAのエンドポイントを疎結合できるのが特に有益であり、また変換とルーティング機能を組み合せることによってサービスへの情報の付加と再利用を可能にします。

Oracle Service Busでは、サービスまたはレスポンスを複数の宛先サービスに転送する必要がある場合や、異なるバージョンのサービスをビジネス・サービスのリクエストに基づいてプロビジョニングする必要があるシナリオでは、メッセージのコンテンツに基づいた動的なメッセージのルーティングを行います。動的なルーティングは、ビジネス要件によって、リクエストの特定の条件により処理を行う場所が指定される場合に有効です。たとえば、金融機関が顧客の信用に関するレポートをリクエストするときは、その顧客または組織がある場所に基づいて複数の信用サービスを使用することになります。

動的なルーティングでは、ルーティングのロジックを決定する1つまたは複数のデータ要素の値を取得するために、メッセージは条件付き分岐文の条件チェックを使用して分析されます。この条件チェックの結果、異なる値の組合せに、異なるビジネス・サービスの宛先が割り当てられます。メッセージは、このデータ要素の値に基づいて、複数の宛先ビジネス・サービスのいずれか1つに動的にルーティングされます。ビジネス・サービスの要件に応じて、これらの1つまたは複数の宛先に向かうレスポンス・メッセージに変換が適用されることがあります。

5.1.1 ビジネス・サービスとプロキシ・サービス

Oracle Service Busでは、ビジネス・サービス(エンタープライズ・サービスやデータベースなど)とサービス・クライアント(プレゼンテーション・アプリケーションやその他のビジネス・サービスなど)との間でプロキシ・サービスを介してメッセージをルーティングします。次の項では、コンテンツ・ベースのルーティングをサポートするプロキシ・サービスの設計と実装に利用できるOracle Service Busの機能について詳しく説明します。

5.1.1.1 プロキシ・サービス

プロキシ・サービスとは、Oracle Service Busでローカルにホストされる汎用の仲介Webサービスを定義したものです。プロキシ・サービスはITインフラストラクチャ内の他のサービスとインタフェースを通じて通信しますが、このインタフェースはサービス・プロバイダやサービス・コンシューマのビジネス・サービスと同一である場合も、同一でない場合もあります。プロキシ・サービスでは、構成済の独立したインタフェースを使用して、メッセージを複数のビジネス・サービスにルーティングできます。プロキシ・サービスの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のプロキシ・サービス: 作成および管理に関する項を参照してください。

プロキシ・サービスはOracle Service Bus管理コンソールを使用して定義と構成を行うことができます。プロキシ・サービスは、インタフェース、使用するトランスポートのタイプ、関連付けられるメッセージ処理ロジックを指定することで構成されます。プロキシ・サービスのメッセージ処理機能は、メッセージ・フローの定義を使用して実装されます。メッセージ・フローの定義の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Busでのメッセージ・フローのモデリングに関する項を参照してください。

プロキシ・サービスが複数のビジネス・サービスとのインタフェースを行う場合、メッセージ・フローの定義は、メッセージが適切なビジネス・サービスにルーティングされ、メッセージ・データがビジネス・サービスのインタフェースで必要なフォーマットにマップされるように構成されます。プロキシ・サービスの構造の詳細は、5.2項「メッセージ・フローの作成」を参照してください。

5.1.1.2 ビジネス・サービス

ビジネス・サービスとは、ビジネス・プロセスにおいてメッセージを交換するエンタープライズ・サービスのOracle Service Busによる定義です。ビジネス・サービスとそのインタフェースは、Oracle Service Bus管理コンソールを使用して定義および構成できます。ビジネス・サービスを構成するには、インタフェース、使用するトランスポートのタイプ、セキュリティ要件、およびその他の特性を指定します。ビジネス・サービスの定義はプロキシ・サービスと似ていますが、パイプラインを持ちません。Oracle Service Bus管理コンソールを使用して、ビジネス・サービスを構成する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のビジネス・サービスの作成および管理に関する項を参照してください。

サービス・アカウントは、ビジネス・サービスに接続するときに認証を提供するために作成できます。サービス・アカウントは要求されるユーザー名とパスワードのペアの別名リソースとして機能します。Oracle WebLogic Serverを使用して、資格証明レベルの検証を要求するビジネス・サービスのセキュリティ資格証明を直接管理できます。ビジネス・サービスのセキュリティに関する考慮事項については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。

5.1.1.3 プロキシ・テンプレート

Oracle Service Busには、任意のSOAPまたはXMLメッセージを受け入れる汎用のプロキシ・サービスを作成する機能があります。これにより、背後にあるプロトコル仕様の複雑さをサービス・コンシューマから隠すことができます。プロキシ・サービスは、受信するSOAPまたはXMLメッセージを分析して、コンテンツ・ベースのルーティング・ロジックによって動的にルーティングするように構成できます。汎用テンプレートからプロキシ・サービスを生成すると、動的なプロトコルの切替えも促進され、実行時にエンドポイント・プロトコルを選択することが可能になります。

5.2 メッセージ・フローの作成

メッセージ・フローとは、Oracle Service Busでプロキシ・サービスの実装に使用される定義です。メッセージ・フローの作成には、プロキシ・サービスのメッセージ・フローの定義におけるメッセージ処理ロジックの構成が関係します。このロジックには、変換、パブリッシュ、レポート、例外管理などのアクティビティが含まれます。各アクティビティは個別のアクションとしてメッセージ・フロー内に構成されます。EclipseとOracle Service Bus管理コンソールではグラフィカルなモデリング・ツールが使用でき、このツールでメッセージの作成を行うことができます。

Oracle Service Busのプロキシ・サービスの実装はメッセージ・フローの定義において、パイプラインやブランチ・ノード、ルート・ノードなどのコンポーネントを使用して定義されます。次の図は、メッセージ・フロー定義のコンポーネントの概要を示しています。

メッセージ・フローの作成の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Busでのメッセージ・フローのモデリングに関する項を参照してください。

図5-1 メッセージ・フローのコンポーネント

5.2.1 メッセージ・パイプライン

パイプラインとは、分岐しない一方向の処理の流れを表す名前付きのステージ・シーケンスです。パイプラインは、サービスのリクエストとレスポンスに対するメッセージ・フローを指定するために使用します。パイプラインは次の3つのカテゴリのいずれかに分類されます:

- リクエスト・パイプライン: メッセージ・フローのリクエスト・パスの処理に使用されます。

- レスポンス・パイプライン: メッセージ・フローのレスポンス・パスの処理に使用されます。

- エラー・パイプライン: エラー・ハンドラとして使用されます。

5.2.1.1 オペレーション・パイプライン

ステージにある1つのサービス・レベル・リクエスト・パイプラインは、オプションで複数のオペレーション・パイプラインに分岐します(オペレーションにつき最大で1つ、およびオプションとしてデフォルトのオペレーション・パイプラインが1つ)。オペレーションはユーザーが選択する条件によって決定されます。レスポンス処理は関連するオペレーション・パイプラインから開始され、1つのサービス・レベル・レスポンス・パイプラインに結合されます。次の図に、プロキシ・サービスのオペレーション・パイプラインの例を示します。

図5-2 オペレーション・パイプラインの例

一方向のオペレーションでは、レスポンス・パイプラインは空のメッセージで実行されます。これにより、プロキシ・サービスにレスポンスを作成でき、双方向(リクエスト/レスポンス)と一方向のオペレーションの間のブリッジングが可能になります。ブリッジング・メカニズムとは、プロキシ・サービスの入力が一方向であっても、出力は双方向(リクエスト/レスポンス)になること(またはその逆)を意味します。プロキシ・サービスは、呼び出したサービスからのレスポンスを取得するか、クライアントへのレスポンスを生成します。メッセージがビジネス・サービスまたはプロキシ・サービスにルーティングされてから、レスポンス・フローのアクションを使用してメッセージの後処理を実行することもできます。

5.2.1.2 ブランチ・ノード

ブランチ・ノードを使用すると、可能ないくつかのパスのうちの1つに限定して処理を進めることができます。分岐は、各ブランチに簡潔ながらユニークな文字列値のタグを付けた単純なルックアップ表を基に実行されます。メッセージ・コンテキストの変数がノードのルックアップ変数として指定され、その値を使用してどのブランチに進むかが決定されます。ルックアップ変数に一致するブランチがない場合は、デフォルトのブランチに進みます。ルックアップ変数の値は、ブランチ・ノードに到達する前に設定する必要があります。このアプローチにより、そのブランチ・ノード自体の中での例外の発生を防ぐことができます。ブランチ・ノードでは、メッセージ・フロー・ツリー内にいくつかの子孫を持つことができます(デフォルトのブランチを含め各ブランチに1つずつ)。

図5-3 メッセージ・フローのブランチ・ノード

5.2.1.3 ルート・ノード

ルート・ノードは他のサービスとのリクエスト通信とレスポンス通信に使用されます。ルート・ノードはプロキシ・サービスのリクエスト処理とレスポンス処理の境界を表すので、メッセージ・フロー・ツリー内に子孫を持つことはできません。ルート・ノードがリクエスト・メッセージをディスパッチすると、リクエスト処理が終了したとみなされます。ルート・ノードがレスポンス・メッセージを受信したときに、レスポンス処理が始まります。

ルート・ノードの仕様には非常に柔軟性があり、アウトバウンド変換、レスポンス変換、および条件付きルーティングに対応します。if構造とcase構造を結合(およびネスト)することができ、メッセージをルーティングするための単一のエンドポイントおよびオペレーションを定義できます。ルート・ノードの構成の方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のメッセージ・フローへのルート・ノードの追加に関する項を参照してください。

図5-4 サービスと通信するプロキシ・サービスのルート・ノード

エコー・ノードはリクエスト・パイプラインの末尾からレスポンス・パイプラインの先頭にメッセージをルーティング(エコー)するルート・ノードです。メッセージは、プロキシ・サービスから別のサービスへルーティングされずに、プロキシ・サービス内に留まります。

5.2.1.4 パイプライン・ペア

パイプライン・ロジックは、「リクエスト・パイプライン」定義と「レスポンス・パイプライン」定義で構成される1組の定義です。リクエスト・パイプライン定義は、ビジネス・サービスまたは別のプロキシ・サービスを呼び出す前に、プロキシ・サービスへのリクエスト・メッセージに対してOracle Service Busが実行するアクションを指定します。レスポンス・パイプライン定義は、プロキシ・サービスがレスポンスを返す前に、プロキシ・サービスによって呼び出されたサービスからのレスポンスに対してOracle Service Busが実行する処理を指定します。ルーティングは、メッセージ・フローの最後にルート・ノードによって実行されます。

リクエスト・パスおよびレスポンス・パスを作成するには、リクエスト・パイプラインとレスポンス・パイプラインを合わせてペアにして、単一ルートのツリー構造に編成します。ブランチ・ノードを使用すると、これらのパイプライン・ペアを条件付きで実行して、ブランチ末尾のルート・ノードでリクエストとレスポンスのディスパッチを実行できます。パイプライン・ツリーは、パイプライン・ペア・ノード、ブランチ・ノード、ルート・ノード、またはエコー・ノードの最上位コンポーネントのインスタンスを連鎖させます。

パイプライン・ペア・ノードは、1つのリクエスト・パイプラインと1つのレスポンス・パイプラインを1つの最上位要素に結び付けたものです。リクエストの処理中にはリクエスト・パイプラインのみが実行され、レスポンス処理のためにパスを逆に辿るときにはレスポンス・パイプラインのみが実行されます。

5.2.1.5 パイプライン実行ステージおよびアクション

各パイプラインは、アクションを含む一連のステージで構成されます。1つのステージは、変換やパブリッシュなどの、ユーザーが構成する処理手順です。メッセージ・フローに送られるメッセージには、メッセージのコンテンツを含む一連のメッセージ・コンテキスト変数が付けられ、パイプライン・ステージのアクションによってアクセスしたり変更することができます。

次の表に、Oracle Service Busのパイプライン・ステージ、ブランチ、およびルート・ノードでサポートされるアクションを示します。構成方法など、アクションの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のプロキシ・サービス: アクションに関する項を参照してください。

表5-1 Oracle Service Busの通信アクション

アクション

説明

動的にパブリッシュ

Xquery式によって識別されたサービスにメッセージをパブリッシュします。

パブリッシュ

静的に指定されたサービスにメッセージをパブリッシュします。

パブリッシュ表

ゼロまたはそれ以上の静的に指定されたサービスにメッセージをパブリッシュします。切替え式の条件ロジックを使用して、どのサービスをパブリッシュに使用するか実行時に決定します。

ルーティング・オプション

アウトバウンド・リクエストのURI、サービスの品質、モード、および再試行パラメータの一部またはすべてを変更します。

サービス・コールアウト

Oracle Service Busに登録済みのプロキシ・サービスまたはビジネス・サービスの同期(ブロック)コールアウトを構成します。

トランスポート・ヘッダー

メッセージのトランスポート・ヘッダーの値を設定します。

表5-2 Oracle Service Busのフロー制御アクション

アクション

説明

For Each

一連の値の反復処理およびアクションのブロックを実行します。

If... Then...

XQuery式のブール結果に基づき、1つまたは複数のアクションを条件付きで実行します。

エラーを発生させる

指定したエラー・コードと説明を使用して例外を発生させます。

返信

呼出し元に即時に返信されるように指定します。成功時または失敗時の返信を選択できます。

再開

エラー・ハンドラによってエラーが処理された後、メッセージ・フローを再開します。

スキップ

実行時に現在のステージの実行がスキップされ、処理がメッセージ・フローの次のステージに進むように指定します。

表5-3 Oracle Service Busのメッセージ処理アクション

アクション

説明

割当て

コンテキスト変数にXQuery式の結果を割り当てます。

削除

コンテキスト変数や、XPath式で指定されたノードのセットを削除します。

挿入

XPath式で選択したノードを基準に、指定した位置にXQuery式の結果を挿入します。

Javaコールアウト

パイプラインからJavaメソッドを呼び出します。

MFL変換

パイプラインで非XMLからXML、またはXMLから非XMLに変換します。

名前変更

コンテンツを変更せずに、XPath式で選択した要素の名前を変更します。

置換

XPath式で指定されたノードまたはノードのコンテンツを置換します。

検証

XMLスキーマ要素またはWSDLリソースに対して、XPath式で選択した要素を検証します。

表5-4 Oracle Service Busのレポート・アクション

アクション

説明

アラート

パイプラインのメッセージ・コンテキストに基づいて、アラート通知を送信します。

ログ

ログに記録するメッセージを作成します。

レポート

プロキシ・サービスのメッセージ・レポートを有効にします。

5.2.1.6 オペレーション分岐

メッセージ・フローは通常WSDLベースのサービスで使用されるため、操作に固有の処理は頻繁に実行されます。Oracle Service Busでは、オペレーションに基づく分岐ノードを手動で構成する必要はなく、自動的に分岐する構成不要の分岐ノードが用意されています。つまり、サービス・エンドポイント用にオペレーション分岐が構成されていない場合、メッセージの処理はメッセージ・コンテキストで指定されたオペレーションに基づいて自動的に適切なオペレーションに分岐します。

5.2.1.7 サービス・コールアウト

Oracle Service Busには、より洗練されたメッセージ・フローを実現して高い柔軟性を提供するサービス・コールアウト・アクションが用意されています。サービス・コールアウトは、Oracle Service Busに登録されている他のサービスを呼び出す、メッセージ・フローからのメッセージ処理のリクエスト・アクションです。このアクションは一般に、複雑な動的ルーティング処理で行われる判断へのレスポンスで使用されるか、またはメッセージへの情報の追加を実行するために使用されます。サービス・コールアウト・アクションはメッセージ・フローのルーティング・ステージ内で使用され、メッセージについての何らかのアクションを実行するために宛先のサービスを呼び出します。呼び出されたサービスはメッセージ・フローにレスポンスを返し、これはローカル変数に割り当てられます。この変数は現在のメッセージ・フロー内で条件付き分岐のために使用されます。

サービス・コールアウト機能については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Busでのメッセージ・フローのモデリングに関する項にあるサービス・コールアウト・メッセージの作成に関する項を参照してください。

サービス・コールアウトを使用すると、カスタムJavaコードをプロキシ・サービス内から呼び出すことができます。Oracle Service Busでは、POJO (Plain Old Java Object)へのコールアウトを可能にするJavaコールアウト・アクションを使用したJava終了メカニズムがサポートされます。POJOからは静的メソッドにアクセスすることが可能です。POJOおよびそのパラメータは、設計時にOracle Service Bus管理コンソールに表示されます。このパラメータは、メッセージ・コンテキスト変数にマップできます。POJOへのJavaコールアウトの構成については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のJavaコールアウト・アクションの追加に関する項を参照してください。

5.3 変換

変換は、ソースと宛先のサービスで種類の異なるメッセージのデータ型が存在し、サービスの互換性を保つためにデータのマッピングが必要となる場合に使用されます。Oracle Service Busは、XQueryおよびeXtensible Stylesheet Language Transformation (XSLT)標準を使用したデータ・マッピングに対応しています。メッセージは、次の2とおりの方法で変換されます。

- メッセージ構造の再フォーマットにXQueryまたはXSLTを使用します。

- 特定のデータ要素を追加、削除、または置換することで、メッセージのコンテンツを操作します。

変換は開発者によって外部で作成され、Oracle Service Busにインポートされるか、またはOracle Service Bus管理コンソールのXQueryを使用してスクリプトが作成されます。変換はプロキシ・サービスのメッセージ・フロー構成に応じて、様々な場所で発生します。

Oracle Service Busにおけるメッセージ・フローは、プロキシ・サービスの実装を定義します。Oracle Service Bus管理コンソールでOracle Service Busのプロキシ・サービスを構成します。この方法は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』に説明されています。

Oracle Service Busは、XQueryおよびeXtensible Stylesheet Language Transformation (XSLT)標準を使用したデータ・マッピングに対応しています。XSLTマップは、XMLからXMLへのマッピングを記述するのに対して、XQueryマップでは、XMLからXML、XMLから非XML、非XMLからXMLへのマッピングを記述できます。変換の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のメッセージ・フローでの変換の実行に関する項を参照してください。

詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のXQuery変換に関する項およびXSL変換に関する項を参照してください。 を使用してXQueryを作成する方法については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。

5.3.1 変換マップ

変換マップは、2つの互換性のないデータ型の間のマッピングを記述したものです。Oracle Service Busは、XQueryまたはeXtensible Stylesheet Language Transformation (XSLT)標準のどちらかを使用したデータ・マッピングに対応しています。XSLTマップは、XMLからXMLへのマッピングを記述するのに対して、XQueryマップでは、XMLからXML、XMLから非XML、非XMLからXMLへのマッピングを記述できます。また、MFLで記述されたデータは自動的に同等のXMLに変換され、XQueryまたはXSLTでの変換で使用できます。ターゲット・サービスで必要な場合、結果のXMLは自動的にMFLに変換されます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のXQuery変換に関する項およびXSL変換に関する項を参照してください。Oracle XQuery Mapperを使用してXQueryを作成する方法については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。

5.3.2 メッセージ操作

メッセージ操作は変換の一種で、メッセージの構造全体ではなくメッセージのコンテンツを操作して、メッセージを宛先のサービスと互換性のあるものにします。これは、メッセージ・フローのリクエスト・パイプラインまたはレスポンス・パイプラインに対して、追加、置換、または削除アクションを実行することによって行われます。コンテンツの操作によってメッセージを変換する場合に使用可能なアクションを次の表に示します。

アクション

説明

挿入

メッセージにデータ要素を挿入します。この挿入は構成中に、メッセージ・コンテキストの指定された任意の場所で、発生する可能性があります。

削除

メッセージからデータ要素を削除します。これは、目的の宛先でメッセージの特定のデータ要素が必要でない場合に使用されます。

置換

メッセージ内の一連のテキストを別のテキストで置換します。これは、たとえば、メッセージのネームスペースを置換するときに使用されます。

5.4 エラー処理

Oracle Service Busには構成されたサービスに対する堅牢で柔軟性のあるエラー処理が用意されています。エラーは次の方法で処理されます。

- アサーションがtrueであることをテストし、リクエスト・パイプラインまたはレスポンス・パイプラインに失敗時の返信を送信します。

- ステージ、ルート・ノード、パイプライン、またはサービス・レベルを含む複数のレベルでエラーを捕捉して処理できるようにサービスを構成します。エラーを捕捉するために構成されるレベルは、必要なサービスの動作によって変わります。

- デフォルトのシステム・エラー・ハンドラでエラーを処理します。

5.4.1 メッセージ検証

Oracle Service Busには、検証アクションを使用して、着信または発信するメッセージをWSDLまたはXMLスキーマに対して検証する機能が用意されています。このアクションは、メッセージ・フロー内でいつでも発生する可能性があり、着信または発信するメッセージが送信先サービスのコンシューマまたはプロバイダの予期するフォーマットであることを保証します。検証でエラーとなったメッセージは、エラーをログに記録するか、またはエラーを生成できます。エラーを生成する場合、エラー・ステージを使用して他のアクションを適用することもできます。

メッセージ検証は、スキーマやWSDLの異なるバージョンに対してメッセージを検証することで、サービスのバージョン管理にも使用できます。これにより、メッセージがサービス・エンド・ポイントの適切なバージョンにルーティングされることが保証されます。または、メッセージの送信前に変換を適用する必要があるかどうかをチェックできます。

5.4.1.1 エラー処理パイプライン

Oracle Service Busにはエラー・ハンドラを定義することで、エラー処理を行うメカニズムが用意されています。エラー・ハンドラは、ロギング、変換、パブリッシュなどの各種アクションを実行し、適切にエラーを処理するためのパイプラインです。ステージ内でエラーが発生すると、一連の手順が実行されます。この一連の手順がそのステージのエラー・パイプラインを構成しています。

このエラー・パイプラインによってエラーを処理できる方法は以下のとおりです。

- 元のメッセージを代替エンドポイントにパブリッシュします。

- エラー・レスポンス・メッセージを作成して、プロキシ・サービスの呼出し元に返します。

- メッセージをログに記録します。

- コンテキストを変更した後、パイプラインに従ってメッセージの処理を続行します。

- 例外を送出します。例外を送出することによって、その次に小さいスコープで指定されたエラー・パイプラインに制御が移されます。

メッセージ・フローの処理中には、様々な原因でエラーが発生します。たとえば、ユーザー名が正しく確認または認証されない場合は、セキュリティ・エラーが発生します。また、Oracle Service Busがメッセージを正常に変換または検証できない場合は、変換エラーが発生します。ルーティング・サービスが使用不能であるために、ルーティング・エラーが発生する場合などもあります。たいていのメッセージ・フロー・ロジックは特定のステージ、ルート・ノード、またはプロキシ・サービスで実行されるため、一般的に、これらのエラーは特定のステージ、ルート・ノード、またはプロキシ・サービスに起因しています。

各ステージは、ステージでエラーが発生した場合に実行される一連の手順を持つことができます。この一連の手順がそのステージのエラー・パイプラインを構成しています。また、エラー・パイプラインは、パイプライン(リクエストまたはレスポンス)またはプロキシ・サービス全体に対して定義することができます。最も小さいスコープで指定されたエラー・パイプラインがエラー時に呼び出されます。

図5-5 ステージ、ノード、およびサービス・レベルのエラー・ハンドラ

メッセージ・フローの正確な状態を把握するためにOracle Service Bus管理コンソールを使用してメッセージを追跡することができます。これにより、エラーを目で確認できるようになります。たとえば、処理を行うために送信されたことを示す、最初にレポートされたメッセージを表示してから、このメッセージが正しく処理されなかったことを示す、次にレポートされたエラーを表示することができます。これにより、メッセージ・フローとエラー・フローの両方を完全に表示することができます。

5.4.2 関連トピック

- 『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Busでのメッセージ・フローのモデリングに関する項

- 『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のXQuery Mapperに関する項

- 『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のXQuery変換に関する項およびXSL変換に関する項

- 『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のJavaコールアウト・アクションの追加に関する項

6 サービス管理

この章では、Oracle Service Busのサービス・モニターとサービス管理機能について説明します。Oracle Service Busの管理とモニターに携わるシステム管理者およびオペレータを対象としています。

この章の内容は以下のとおりです。

- 6.1項「サービスのモニター」

- 6.2項「メッセージ・レポート」

6.1 サービス・モニター

サービスのルーティングや変換といったEnterprise Service Busの機能に加えて、Oracle Service Busには、サービス・モニターとサービス管理機能が用意されており、この機能によってIT組織が期待する適切なオペレーションが確実に行われるようになります。以下のトピックでは、Oracle Service Busのサービス管理とサービス・モニターの機能について説明します。

6.1.1 ダッシュボード

Oracle Service Busは、実行時統計を集計してカスタマイズ可能なダッシュボードにリアルタイムに表示し、システム運用のヘルス状態をモニターしてメッセージング・サービスでの問題にフラグを付け、問題発生時にこれを迅速に隔離して診断できます。また、Oracle Service Bus管理コンソールを使用してシステムのパフォーマンスに応じたサービス・レベル・アグリーメント(SLA)を確立でき、SLAに違反した場合に自動的にレスポンスするアラートをトリガーするためのルールを構成できます。

図6-1 Oracle Service Busダッシュボード

システムのオペレーションについてのヘルス情報は、サーバーとサービスによって編成されます。ドメイン全体のステータス、またはドメイン内の個別のサーバーのステータスを色分けされた円グラフで表示することができます。サービスの概要も表示され、アラートの数や、定義されたアラートが発生しモニターが有効になっているすべてのサービスで対応する重大度が表示されます。

ダッシュボードに加えて、Oracle Service Busには個別のサービス・レベルでオペレーションとパフォーマンスの統計を表示する機能もあります。これらの統計値は、ドメイン内にある個別のサービス、または指定したサーバーのものになります。より詳細な分析のために、オペレーション・レベルでのサービスのパフォーマンス統計も表示されます。

Oracle Service Bus管理コンソール・ダッシュボードの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のモニタリングに関する項を参照してください。

6.1.2 メトリックの集約

ダッシュボードに表示される情報は、システム処理時に収集されるデータの非同期集約に基づきます。Oracle Service Bus本番クラスタ・ドメインでは、Oracle Service Busデータ集約機能はクラスタ内のいずれかの管理対象サーバー上でシングルトン・サービスとして実行されます。サーバー固有のデータ集約は、ドメインの各管理対象サーバーで実行されます。集約機能は、一定間隔(構成可能)ですべての管理対象サーバーからデータを収集および集約します。

サービスごとにダッシュボードに表示できるメトリックを次の表に示します。

表6-1 Oracle Service Busサービスのメトリック

メトリック

説明

平均実行時間

プロキシ・サービスの場合、トランスポートにおけるメッセージの受信時から例外処理時またはレスポンス送信時までの時間の平均を示します。

ビジネス・サービスの場合、アウトバウンド・トランスポートにおけるメッセージの送信時から例外受信時またはレスポンス受信時までの時間の平均を示します。

メッセージの総数

サービスに送信されたメッセージの数です。JMSプロキシ・サービスで、例外によってトランザクションが中断され、メッセージが失われないようにキューに戻された場合、デキューが再試行されるたびに別々のメッセージとしてカウントされます。同様に、アウトバウンド・トランザクションの場合、再試行またはフェイルオーバーのたびに別々のメッセージとしてカウントされます。

エラーによるメッセージ

エラー・レスポンスを伴うメッセージの数です。

プロキシ・サービスの場合、システム・エラー・ハンドラまたは返信失敗アクションによって終了される原因となったメッセージの数を示します。エラーがサービス内で処理され、返信が成功するか再開アクションが行われる場合、エラーとして扱われません。

ビジネス・サービスの場合、トランスポート・エラーまたはタイムアウトの原因となったメッセージの数を示します。再試行およびフェイルオーバーは別々のメッセージとして扱われます。

成功/失敗比率

(メッセージの総数 - エラーが発生したメッセージの数)/エラーが発生したメッセージの数

セキュリティ

WS-Securityエラーを伴うメッセージの数です。このメトリックは、プロキシ・サービスおよびビジネス・サービスの両方で計算されます。

検証

フロー内の検証アクションで失敗した数です。このメトリックは、プロキシ・サービスにのみ適用されます。

これらのメトリックは、構成された集約時間ごとに、クラスタ全体で集約されます。ダッシュボードにはシステム全体のヘルス情報が表示され、一定間隔で表示が更新されます。

6.1.3 アラート経由のSLAの適用

Oracle Service Busには、ビジネス・サービスおよびプロキシ・サービスにサービス・レベル・アグリーメント(SLA)を設定する機能が用意されています。これらのSLAは、ビジネス・サービスおよびプロキシ・サービスで期待されているサービスの正確なレベルと品質を定義します。SLAの測定に基づいてアラートをトリガーするルールを構成できます。アラートには、通常、警告、軽度、重要、重大、致命的という複数のレベルの重大度を構成できます。ビジネス・サービスまたはプロキシ・サービスに対して、複数のアラート条件を組み合せることができます。各アラートは、次のパラメータに基づいています。

- 成功割合、成功率、失敗率

- メッセージ数

- エラー数

- フェイルオーバー/再試行回数

- 検証エラー数

- WSSエラー数

- レスポンス時間、最小レスポンス時間、最大レスポンス時間

SLAアラートは、オペレーション・チームに対してビジネスおよびプロキシ・サービスのヘルスに関する問題や、示されたサービスの品質に関する問題を通知するために設定されます。

Oracle Service Busにはサービス・レベル・アグリーメント(SLA)が実装されており、許容できないサービス・パフォーマンス状態と、そのような状態において必要なシステム・レスポンスを指定する「ルール」を使用することにより、SLAに違反した場合のレスポンスを自動化できます。ルールは、Oracle Service Bus管理コンソールを使用して定義および作成されます。Oracle Service Busで集約されたメトリック・データが更新されるたびに、そのデータに対してルールが評価されます。

ルールの評価がTrueの場合は、アラートが発生します。Oracle Service Bus管理コンソール・ダッシュボードでアラートに関する情報を表示する以外に、Oracle Service Busは、ルールの評価がTrueの場合に指定されたアクションを実行します。ルールには次の任意のタイプのアクションを割り当てることができます。

- 電子メール通知の送信

- JMSメッセージの送信

- Oracle WebLogic Serverロガーへのアラートの送信

アラートには、処理時間帯を構成することもできます。ルールとアラートの処理は、Oracle Service Bus アラート・マネージャが行います。アラート・マネージャは、システムのメトリック集約機能と同じ管理対象サーバー上で稼働します。

Oracle Service Busを使用すると、SLAアラートの他に、メッセージ・フロー内からアラート・アクションを構成することもできます(パイプライン・アラート)。これらのパイプライン・アラート・アクションは、パイプラインのメッセージ・コンテキストに基づいてアラートを生成し、アラート宛先に送信します。アラート・アクションには、アラート名、説明($orderなどのメッセージ要素を含めることができる)、アラート宛先、またはアラート重大度を構成できます。

Oracle Service Busアラートの構成方法の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のモニタリングに関する項を参照してください。

6.2 メッセージ・レポート

Oracle Service Busでは、メッセージがプロキシ・サービスを介して渡すメッセージ・データについてレポートできます。レポートは、レポート・アクションによって行われます。レポート・アクションは、リクエスト/レスポンス・パイプラインまたはエラー・パイプライン・ステージの任意の場所に配置できます。レポート・アクションは、メッセージがプロキシを通過するときのメッセージ情報のフィルタとして使用できます。レポート・アクションによって取得されたデータは、レポート・プロバイダを経由してアクセスできます。レポート・アクションは、問題がメッセージの変換前と変換後のどちらにあるのか、ルーティング中にあるのかなどを判断する場合に役立ちます。

レポート・アクションでは、Oracle Service Busのレポート・データ・ストリームに書き込む必要がある各メッセージについての情報を指定できます。次の図に、レポート・アクションの例を示します。

図6-2 レポート・アクションの例

Oracle Service BusにはJMSレポート・プロバイダが組み込まれています。それによって、レポートされたデータが取得され、レポート・データ・ストアの役割を果たすメッセージ・レポート・データベースに格納されます。Oracle Service Busには、独自のレポート・プロバイダの使用を予定する顧客のためにJava APIも用意されています。

Oracle Service Bus管理コンソールのメッセージ・レポート・モジュールには、概要情報も含めて、レポート・データ・ストアの情報が表示されます。メッセージ・レポート画面では、特定のメッセージに関する概要情報を表示できるほか、詳細情報も表示できます。

図6-3 Oracle Service Busダッシュボードでのメッセージ・レポートの概要の例

特定のレポート要件を満たすようにデータをフィルタおよびソートすることで、表示されるメッセージ・レポートの情報をカスタマイズすることが可能です。レポート・アクションの構成方法の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のメッセージ・フローでのアクションの追加と編集に関する項を参照してください。

注意:
メッセージ・レポート画面に表示される情報は、レポート・アクションを含むパイプラインを通過するメッセージに限定されます。

Oracle Service Bus管理コンソールには、メッセージ・データの管理に便利なパージ機能が備わっています。その他のデータ管理機能については、レポート・データ・ストアのホストに使用しているデータベースに対して標準的なデータベース管理手続きを適用できます。レポート・データ・ストア用にサポートされるデータベース・プラットフォームの一覧については、次の場所にあるOracle Fusion Middlewareのサポートされるシステム構成を参照してください: http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html。

Oracle Service Busのモニター、SLAアラート、およびレポート機能を使用すると、ITオペレーション部門はリアル・タイムでサービス・インフラストラクチャのヘルスと可用性を管理することができ、SLAの遵守を計測して、効果的で効率のよい報告を管理チームや経営者に行うことができます。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。