ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ
11gリリース1(11.1.1.6.2)
B61433-05
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

1 概要

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

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

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

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

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

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

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

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

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

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

図1-1の説明が続きます
「図1-1 SOAの概念アーキテクチャ」の説明

1.1.1.1 サービス仲介の課題

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

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

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

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

図1-2の説明が続きます
「図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

図1-3の説明が続きます
「図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のアーキテクチャ

図1-4の説明が続きます
「図1-4 ESBのアーキテクチャ」の説明

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 共有サービスの正確な実行時ガバナンスによる効率的なSOAイニシアティブの改善

  • 棚卸しと実行時サービスの追跡によるSOA経費の正当化

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

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

図1-5の説明が続きます
「図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による仲介

図1-6の説明が続きます
「図1-6 Oracle Service Busによる仲介」の説明

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

図1-7 Oracle Service Busの機能

図1-7の説明が続きます
「図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の適応的なメッセージング

図1-8の説明が続きます
「図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 最適化されたプラガブル・セキュリティ・レイヤー

図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の埋込みサービス管理

図1-10の説明が続きます
「図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章「サービス管理」6.1.3項「アラート経由の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でのサービスのパブリッシュおよび検出

図1-11の説明が続きます
「図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-12の説明が続きます
「図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 サービス・ライフ・サイクル

図1-13の説明が続きます
「図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デプロイメント・ガイド』