| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.2.1) E69914-01 |
|
 前 |
 次 |
この章では、Service Busの概要、そのアーキテクチャとコンポーネント、およびService Busを使用したサービスの開発方法について説明します。また、Service Busアプリケーションの開発手順と、様々な開発方法についても説明します。
この章の内容は次のとおりです。
Oracle Service Busは、SOAライフ・サイクル管理用に設計された、構成ベースでポリシー駆動のEnterprise Service Busです。Oracle Service Busは、サービスの検出と仲介、迅速なサービス・プロビジョニングとデプロイメント、およびガバナンスに関する基盤機能を提供します。Service Busでは、スケーラビリティと信頼性の高いサービス志向の統合やサービス管理、また、異なる環境に対して従来のメッセージ・ブローカリングを提供します。さらに、インテリジェントなメッセージ・ブローカリングに、メッセージのルーティングや変換機能、およびサービスの監視や管理が融合されています。Service Busでは、業界標準を利用してサービスを接続し、高度な異質性、既存のミドルウェア、アプリケーションおよびデータ・ソースの接続、さらに既存の投資の保護に対応します。
Service Busは、大まかで緩やかに結合された標準ベースのサービスの構築と、ビジネス機能をサービス・コンシューマとバックエンド・ビジネス・サービスに接続できる中立コンテナの作成を、基盤となるインフラストラクチャとは無関係に行うというSOAの原則に基づいています。次の図にエンタープライズIT SOAランドスケープにおけるService Busのサービス仲介者としての役割を示します。
適応的なメッセージングは、柔軟性のあるメッセージ処理と、クライアントとサービス間の操作を提供します。たとえば、クライアントがHTTPでService Busを介してSOAPメッセージを送信し、次にService Busがそのメッセージを変換してバックエンドEJBを呼び出します。あるいは、クライアントがHTTPでREST/JSONメッセージを送信し、Service Busがそのメッセージを変換してバックエンドSOAP/XMLサービスを呼び出します(または利用可能ないずれかのアダプタを使用します)。適応的なメッセージングでは、リクエスト/レスポンス、同期および非同期、分割-結合、パブリッシュ/サブスクライブなどの様々な通信パターンもサポートされます。単一のメッセージ・ライフ・サイクルで、インバウンド・メッセージとアウトバウンド・メッセージに異なるパターンを使用できます。
Service Busでは、Webサービスに対して、Oracle Platform Security ServicesおよびOracle Web Services Manager (OWSM)に基づき、すべてのレベルのサービス・セキュリティが保証されます。カスタムまたはサード・パーティ製のセキュリティ・コンポーネントをプラグインできます。組込み機能によって、セキュリティを次のレベルで有効にすることにより、実装における柔軟性が確保されています。
SSL、基本認証およびカスタム・セキュリティ資格証明などのトランスポート・レベルのセキュリティ
WS-Security、SAML、ユーザーIDとパスワード、X509、署名と暗号化、およびカスタム・セキュリティ資格証明などのメッセージ・レベルのセキュリティ
シングル・サインオンとロール・ベースのアクセスなどのコンソール・セキュリティ
ポリシー・セキュリティ
サービス仮想化は、メッセージの操作と制御を通じて機敏性を提供します。Service Busでは、検証、変換、メッセージの内容に基づくルーティング、メッセージ内の複数の項目の並列処理、アラートのトリガー、およびエラー処理を使用して、メッセージ・フローの様々なポイントでメッセージを柔軟に制御できます。たとえば、Service Busには次の機能があります。
メッセージ・ルーティングの外部サービスに対するXQueryベースのポリシーまたはコールアウト。
ポイント・ツー・ポイントおよび1対多の両方のルーティング・シナリオ(パブリッシュ)に適用するルーティング・ポリシー。パブリッシュの場合、ルーティング・ポリシーはサブスクリプション・フィルタとして機能します。
パイプラインを再構成せずにルートを変更できる、パイプラインから抽象化されたルーティング表。
クライアントのユーザー定義のグループへの分類およびそれらのグループに基づいたルーティング・ポリシーの適用を行うためのIDベースのルーティング。
動的なコンテンツ・ベースのメッセージ・ルーティングおよびプロトコルの実行時選択などの条件付きルーティング。
メッセージの情報追加、ルーティングの決定またはパイプラインの動作のカスタマイズに使用できるデータベース・ルックアップ。
XQueryまたはXSLTマップを使用した変換。
構成フレームワークにより、Service Bus本番環境とその関連リソースを完全に制御できます。フレームワークには、セッション管理、テスト・コンソールおよびインポート/エクスポート・ツールが含まれます。Service Bus構成はセッションで管理されるため、変更を行いながら現在の構成をロックする一意の機能が提供されます。Service Busでサービスについてのリクエストの受信と処理を継続しながら、セッションで構成の変更が行われます。現在のセッションをアクティブ化するまで、これらの変更がランタイム構成に影響を与えることはありません。このようにして、進行中の変更はサービスに影響を与えることなく実行できます。構成およびリソースに対して行った変更が追跡され、変更を元に戻すまたは変更のやり直し、競合の解決、リソース間の依存関係の維持、およびテスト・コンソールでの変更のテストを行うことができます。
組込みのテスト・コンソールは、パイプラインまたは分割-結合で使用されるリソースおよびインライン式の検証を行うブラウザ・ベースのテスト環境です。テスト・コンソールを使用して、テスト・オブジェクト(パイプライン、ビジネス・サービスまたはXQuery式など)の構成、テストの実行、テスト結果の表示を行います。サービスのテスト時には、指定されたトレース・ポイントでメッセージの状態を調べるために、メッセージ・フローのトレースができます。
Service Busでは、リソースやプロジェクトをエクスポートおよびインポートして、異なる環境間で構成データを伝播できます。たとえば、開発ドメインからテスト・ドメイン、さらに本番ドメインへ構成を転送できます。インポート機能とエクスポート機能を使用すると、環境間でリソースの依存関係を維持して、環境変数を保持できます。
構成フレームワークには、UDDIレジストリを使用したサービスの検出、パブリッシュおよび同期(UDDIによるサービスの自動インポートやサービスの同期など)を行うためのメタデータ駆動のインタフェースも含まれます。
サービス管理には、監視、アラートおよびレポート用のランタイム構成ツールの強力なセットが含まれます。Service Busは、SOA全体のサービスを管理するためにFusion Middleware Controlに完全に統合されています。サービス管理では、次の操作が可能です。
メッセージ呼出し、エラー、パフォーマンス特性、渡されるメッセージおよびSLA違反について統計値を収集します。
SLAと、SNMPトラップとしてのパイプライン・アラートを送信し、サード・パーティのエンタープライズ・システム管理ソリューションとの統合を可能にします。
システム処理とビジネス監査の両方を目的として、メッセージの選択された部分をログに記録します。
メッセージの主要情報(検索索引として使用可能)を抽出してメッセージ・レポートを検索します。
広く採用されているサード・パーティ製のレポート・ツールおよびカスタムのエンタープライズ・システム管理フレームワークと統合します。
操作とデプロイメントのカスタマイズ用のオープン・インタフェース、JMX監視インタフェース、およびSNMPアラートをサポートします。
Service Busは、着信するサービス・リクエスト・メッセージを処理して、ルーティング・ロジックを決定し、そのメッセージを他のサービス・コンシューマと互換性があるように変換を行う仲介機能です。HTTP(S)、JMS、ファイル、FTPなどのトランスポート・プロトコルを介してメッセージを受信し、同じトランスポート・プロトコルまたは別のトランスポート・プロトコルを使用してメッセージを送信します。サービスのレスポンス・メッセージは、これと逆のパスを辿ります。Service Busによるメッセージ処理は、メタデータによって駆動され、メッセージ・フローの定義(パイプライン)で指定されます。
Service Busは、SOAP、HTTPおよびJava Messaging Service (JMS)などの基準に基づいて、メッセージ配信サービスを提供します。ネイティブのデータ型としてXMLがサポートされており、他のデータ型を処理するために、その他のデータ型も提供されます。Service Busでは、サービス・クライアントとビジネス・サービスとの間に疎結合を確立する一方で、セキュリティ制御とモニターを一元的に管理できます。ステージングによって開発環境から本番環境へカスタマイズおよび伝播可能なメタデータに、ポリシー、サービスおよび関連するリソース構成を永続化して保存します。メッセージ・ブローカリング・エンジンは、メタデータ・キャッシュからこの構成情報にアクセスします。
メッセージには、アプリケーション・プロセスについてのデータまたはステータス情報や、受信側に対する指示などが含まれます。Service Busでは、コンテンツに基づいてメッセージをルーティングし、コンテンツに対して変換を実行できます。この処理は、Service Busのトランスポート・レイヤーおよびバインディング・レイヤーを介して実行されます。
Service Busを介したメッセージの処理では、次の一連のイベントが実行されます。
クライアントは、特定の転送プロトコルを使用してService Busにメッセージを送信します。
トランスポート・プロバイダは、インバウンド・メッセージを処理します。サービス・クライアント・エンドポイントとの通信を処理し、Service Busへのメッセージのエントリ・ポイントとして機能します。
バインディング・レイヤーは、メッセージの圧縮と解凍、メッセージのセキュリティ処理、パイプラインへのメッセージの引渡しを行います。
パイプラインは、変換、検証、ロギングおよびレポート作成を行い、メッセージをエンドポイント(ビジネス・サービスまたは別のプロキシ・サービスのいずれか)にルーティングします。
Service Busは、前述の手順と同様にレスポンス・メッセージを処理します。
次の図に、インバウンド・エンドポイント(プロキシ・サービス)からアウトバウンド・エンドポイント(この場合はビジネス・サービス)までの、Service Busを介したデータ・フローを示します。示されているトランスポートは、Service Busで利用可能なトランスポートのサブセットです。
以降の項では、このメッセージ処理に関連する各レイヤーについて説明します。
プロキシ・サービスは、サービス・コンシューマが管理対象のバックエンド・サービスに接続するために使用するインタフェースです。プロキシ・サービスは、Service Busがローカルに実装する仲介Webサービスの定義になっています。プロキシ・サービス・インタフェースは、Web Services Description Language (WSDL)またはWeb Application Definition Language (WADL)、およびそれが使用するトランスポートのタイプを考慮して定義されます。
インバウンド・トランスポート・レイヤーは、クライアント・サービス(またはサービス・コンシューマ)とService Busとの間にある通信レイヤーです。サービス・クライアント・エンドポイントとの通信を処理して、Service Busへのメッセージのエントリ・ポイントとして機能します。インバウンド・トランスポート・レイヤーは主に入力または出力ストリームのメッセージ・データを生のバイトとして処理します。トランスポート・レイヤーは、HTTP(S)、JMS、FTP、ファイル、電子メールなど、互換性のあるトランスポート・プロトコルをサポートします。データ処理には関与しませんが、レスポンス・メッセージをサービス・コンシューマに返し、エンドポイントURIやトランスポート・ヘッダーなどのメッセージのメタデータを処理します。
インバウンドおよびアウトバウンドどちらのバインディング・レイヤーも、メッセージ処理で次の機能を実行します。
必要に応じたメッセージの圧縮および解凍
メッセージのセキュリティの処理
メッセージを渡してパイプラインを開始(リクエストとレスポンス)
パイプラインでは、ルーティング、変換、検証、パブリッシュ、レポート作成および例外管理など、Service Busを介したリクエスト・メッセージおよびレスポンス・メッセージのフローを定義します。これは、プロキシ・サービスのバインディング・レイヤーからメッセージを受け取り、変換または検証を実行して、アウトバウンド・サービス(プロキシまたはビジネス・サービスのいずれか)のバインディング・レイヤーにそのメッセージを転送します。その途中で、パイプラインは、その他のサービス、JavaオブジェクトまたはPOJOにコールアウトを行うことができます。
アウトバウンド・トランスポート・レイヤーは、外部サービス(またはサービス・プロデューサ)とService Busとの間の通信機能を担います。Service Busからビジネス・サービスまたはプロキシ・サービスにメッセージを渡し、サービスからレスポンスを受信します。トランスポート・レベルでは、メッセージ・データは入力または出力ストリームの形式の生のバイトです。アウトバウンド・トランスポート・レイヤーは、HTTP(S)、JMS、FTP、ファイル、電子メールなど、互換性のあるトランスポート・プロトコルをサポートします。データ処理には関与しませんが、エンドポイントURIやトランスポート・ヘッダーなどのメッセージのメタデータを処理します。
Service Busでは、外部サービス(エンタープライズ・サービスやデータベースなど)とサービス・クライアント(プレゼンテーション・アプリケーションやその他のビジネス・サービスなど)との間でメッセージをルーティングします。Service Busプロジェクトで作成するサービス・コンポーネントとフロー・コンポーネントは、Service Busのローカル・リソースおよびシステム・リソースに依存して、ユーザー名やパスワード、キーストア資格証明、サーバー接続および変換などのその他の情報を定義します。
Service Busのリソースとは、再利用可能なエンティティ定義であり、通常はそれらのエンティティのメタデータが含まれています。リソースは複数のサービスで使用可能で、企業や部署全体で使用できるように標準化された定義または記述を持ちます。
プロキシ・サービスとビジネス・サービスでは、Service Busシステムでエンドポイントを定義します。たとえば、バインディング・レイヤーやトランスポート・レイヤーがあり、これらは、Service Busがプロデューサやコンシューマなどの外部サービスと通信する場合のポイントになります。
プロキシ・サービスとは、Service Busでローカルにホストされる汎用の仲介WebサービスのService Bus定義です。プロキシ・サービスは、インタフェースを通じて外部サービスと通信しますが、このインタフェースはサービス・プロバイダやサービス・コンシューマのビジネス・サービスと同一である場合も、同一でない場合もあります。パイプラインを介して、構成済の独立したインタフェースを使用して、メッセージをプロキシ・サービスから複数のビジネス・サービスにルーティングできます。
プロキシ・サービスの構成には、そのインタフェース(サービス・タイプ)、クライアント・サービスと接続するためにインタフェースが使用するトランスポートのタイプと構成、セキュリティ要件、およびサービス・レベル合意(SLA)のアラート・ルールなどが含まれます。プロキシ・サービスが複数のビジネス・サービスとのインタフェースを行う場合、その関連パイプラインは、メッセージが適切なビジネス・サービスにルーティングされ、メッセージ・データがビジネス・サービスのインタフェースで必要なフォーマットにマップされるように構成されます。
詳細は、「プロキシ・サービスの作成と構成」を参照してください。
ビジネス・サービスとは、ビジネス・プロセスにおいてメッセージを交換するエンタープライズ・サービスのService Busによる定義です。ビジネス・サービスの構成には、そのインタフェース(サービス・タイプ)、サービス・プロデューサと接続するためにインタフェースが使用するトランスポートのタイプと構成、セキュリティ要件、メッセージ処理、パフォーマンス・チューニング、およびSLAのアラート・ルールなどが含まれます。ビジネス・サービスでは、エンドポイントURIも指定し、ロード・バランシングと高可用性のための複数のエンドポイントを指定できます。ビジネス・サービス定義は、プロキシ・サービスの定義と似ていますが、メッセージ処理、エンドポイントのスロットルおよび結果キャッシュの追加オプションがあるため、パフォーマンスの改善に役立ちます。
ビジネス・サービスへの接続時に認証を行うサービス・アカウントを作成できます。これは要求されるユーザー名とパスワードのペアの別名リソースとして機能します。また、Oracle WebLogic Serverを使用して、資格証明レベルの検証を要求するビジネス・サービスのセキュリティ資格証明を直接管理することもできます。
詳細は、「ビジネス・サービスの作成と構成」を参照してください。
メッセージ・フローでは、サービス間でのメッセージのルーティング、検証および変換方法を定義します。メッセージ・フローは、通常パイプラインで定義されますが、並列処理の場合は分割-結合で定義することもできます。
パイプラインでは、メッセージのルーティングと変換ロジックを定義し、さらにメッセージ処理のオプションも定義します。このロジックには、変換、パブリッシュ、ロギング、レポート作成、アラートおよび例外管理などのアクティビティが含まれます。各アクティビティは個別のアクションとしてメッセージ・フロー内に構成されます。JDeveloperとOracle Service Busコンソールのどちらにも、パイプラインのモデル化に役立つグラフィカル・モデリング・ツールが用意されています。
パイプラインの構築には、次の主要要素が使用されます。
開始ノード。
パイプライン・ペア。一方はリクエストで使用され、他方はレスポンスで使用されます。ペアの各パイプラインは、リクエスト処理またはレスポンス処理で実行するアクションを指定する一連のステージで構成されます。
ブランチ・ノード。メッセージまたはメッセージ・コンテキストの指定部分の値に基づいて分岐するか、呼び出された操作に基づいて分岐するために使用されます。
ルート・ノード。メッセージの宛先の定義に使用されます。デフォルト・ルート・ノードは、リクエストそのものをレスポンスとして返すエコー・ノードです。
エラー・ハンドラ。ノードまたはステージで発生する可能性のあるエラーを処理するために、そのノードまたはステージにアタッチできます。
少なくとも、開始ノードとルート・ノードが必要です。エラー・ハンドラは必須ではありませんが、使用することをお薦めします。インスタンスが失敗してエラー・ハンドラが定義されていない場合、そのエラーは回復できません。パイプライン要素を任意で組み合せて、開始ノードをルート(root)位置に必ず(1つのみ)配置し、ルート(route)・ノードを持つツリー構造を形成します。ブランチの最後のノード(リーフ・ノード)は、ルート・ノードまたはエコー・ノードになります。
パイプラインはメッセージを複数のビジネス・サービスにルーティングできるため、パイプラインは通信先のビジネス・サービスとは独立したインタフェースで構成できます。汎用のテンプレートを使用することにより、コンテンツ・ベースのルーティング・ロジックに基づいてメッセージを動的に適切なビジネス・サービスにルーティングするよう、パイプラインを構成できます。パイプラインは、メッセージ・データをエンドポイントのビジネス・サービスによって必要とされる適切なプロトコル形式にマップすることもでき、動的な実行時のプロトコルの切替えを実現しています。
詳細は、「Oracle Service Busパイプラインの操作」を参照してください。
パイプラインでは、リクエスト・メッセージは開始ノードから始まり、リクエスト・パイプラインのアクションを実行しながらリーフ・ノードまでの経路を辿ります。リーフがルート・ノードの場合、レスポンスが生成されます。リーフがエコー・ノードの場合、要求そのものが応答として扱われます。レスポンスでは、ブランチ・ノードのアクションをスキップしながらツリーの経路を逆に辿ります。ただし、レスポンス・パイプラインのアクションは実行されます。インタフェースまたは操作がリクエスト/レスポンスであれば、ツリーの一番上からレスポンスが送信されます。それ以外の場合、レスポンスは破棄されます。
コンテキスト変数に影響する一連の変換は、選択したエンドポイントへのメッセージの送信前、またはレスポンスの受信後に定義できます。XQueryまたはXSLT変換のかわりにWebサービス・コールアウトを使用して、コンテキスト変数を設定できます。
パイプラインのコンテキストは、リクエスト・フローとレスポンス・フローとで共有される一連のXML変数です。新しい変数は動的にコンテキストに追加したり、コンテキストから削除でき、これらの変数は複数のパイプライン間で共有することも、1つのパイプライン内でローカルに使用することもできます。あらかじめ定義されたコンテキスト変数には、メッセージに関する情報、トランスポート・ヘッダー、セキュリティ・プリンシパル、現在のパイプラインのメタデータ、およびパイプラインから呼び出されるプライマリ・ルーティング・サービスとパブリッシュ・サービスのメタデータが含まれます。
コンテキストは読み取られて、XQuery式またはXSLT式による変更や、変換およびインプレース更新アクションによる更新が行われることがあります。コンテキストの中核は、$header、$bodyおよび$attachments変数で構成されます。これらのラッパー変数には、Simple Object Access Protocol (SOAP)ヘッダー要素、SOAP本体要素、およびMultipurpose Internet Mail Extensions (MIME)添付がそれぞれ含まれます。コンテキストによって、すべてのメッセージがSOAPメッセージであり、非SOAPメッセージがこのパラダイムにマップされるように見えます。
分割-結合メッセージ・フローでは、メッセージ・ペイロードを分割し、メッセージ内の複数の操作を同時に処理してすべての結果を組み合せる(結合する)ことにより、サービスのパフォーマンスが向上します。標準のパイプラインでは、次々に操作が処理されます。
分割-結合でのメッセージ・フローの構築には、次の主要な要素が使用されます。
開始ノード。WSDL操作からイントロスペクトされるリクエスト変数およびレスポンス変数が含まれています。
受信ノード。着信リクエスト・メッセージを受信します。
返信ノード。レスポンス・メッセージを送信します。
スコープ。囲まれた要素の動作に影響を与えるコンテキストを作成するコンテナです。
パラレル・ノード。固定数の処理ブランチのプレースホルダであり、各ブランチには、それぞれのスコープがあります。
利用可能な要素を任意で組み合せて、開始ノードをルート(root)位置に必ず(1つのみ)配置するツリー構造を形成します。最後のノードは常に返信になります。
詳細は、「分割-結合によるサービスのパフォーマンスの向上」を参照してください。
Service Busでは、各種トランスポートを介して外部システムへの接続が提供されます。それぞれのトランスポートは、外部システムのタイプに固有です。Service Busでは、最適化されたデータベース問合せをサポートし、.NET、IBM MQ Series、IBM WebSphere、Apache AxisおよびiWayアダプタなどのWebサービス統合テクノロジと相互運用性があります。JCAトランスポートでは、Oracle JCAテクノロジやアプリケーション・アダプタを使用して外部システムに接続できるため、サポート対象テクノロジのリストが拡張されます。さらに、Service BusではRESTバインディングをサポートしているため、HTTPトランスポートを使用してRESTfulサービスに接続できます。
トランスポートの処理および接続情報は、プロキシまたはビジネス・サービス内で直接構成します。Oracleアダプタは、各アダプタに固有の構成ウィザードを使用して構成します。
詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください。
Service Busでは、次のサービス・トランスポート・プロトコルがサポートされます。
DSP (Oracle Data Service Integrator)
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)およびBPEL
Tuxedo (Oracle Tuxedo)
WS (Web Services Reliable Messaging)
Service BusはCustom Transport SDKも備えているため、新しいトランスポートを作成して、前述以外のシステムとの接続が可能になります。
Service Busは、従来のWebサービス(WSDLファイルでXMLまたはSOAPバインディングを使用)から非XML(汎用)サービスまで、様々なサービス・タイプに対応しています。ビジネス・サービスまたはプロキシ・サービスを作成する場合、サービス・タイプを選択して構成します。プロキシ・サービスやビジネス・サービスに使用できるサービス・タイプは、使用するトランスポートによって異なります。Service Busでは、HTTPとJMSの非同期トランスポート・プロトコルのリクエストとレスポンスおよび一方向のパラダイムがサポートされます。基底のトランスポートが順序付きメッセージ配信に対応している場合、Service Busでも同様の拡張で対応できます。
すべてのサービス・タイプをすべてのトランスポート・プロトコルで使用できるわけではありません。次の表に、サービス・タイプと、そのタイプでサポートされるトランスポート・プロトコルを示します。
| サービス・タイプ | トランスポート・プロトコル |
|---|---|
WSDLベースのサービス |
BPEL-10g、DSP、HTTP(S)、JCA、JMS、ローカル、SB、SOA-DIRECT、WS JMSリクエストとJMSレスポンスは、WS-Securityが有効になっているとサポートされません。 |
任意のSOAPサービス(非WSDL) |
HTTP(S)、DSP、JMS、ローカル、SB JMSリクエストとJMSレスポンスは、WS-Securityが有効になっているとサポートされません。 |
任意のXMLサービス(非WSDL) |
DSP、電子メール、ファイル、FTP、HTTP(S)、JMS、ローカル、MQ、SB、SFTP、Tuxedo HTTP GETは、WSDLがないXMLだけでサポートされます。 |
メッセージング・サービス |
電子メール、ファイル、FTP、HTTP(S)、JMS、ローカル、MQ、SFTP、Tuxedo 電子メール、ファイル、FTPまたはSFTPトランスポートを使用するビジネス・サービスでは、一方向のメッセージング・サービスのみをサポートし、レスポンス・メッセージのタイプは |
ネイティブRESTサービス |
HTTP(S)、ローカル |
BPEL-10g、DSP、EJBおよびSOA-DIRECTトランスポートは、ビジネス・サービスでのみサポートされます。
メッセージ・フロー・アクションにインラインXQuery式を直接作成する以外に、ソース・サービスと宛先サービス間の複雑なマッピングを定義するトランスフォーメーション・マップを参照できます。ソースと宛先のサービスでタイプの異なるメッセージのデータ型が存在する場合、データ・マッピングによってサービスの互換性が確保されます。Service Busは、XQueryとeXtensible Stylesheet Language Transformation (XSLT)標準、およびXPath式を使用したデータ・マッピングに対応しています。また、相互参照表とドメイン値マップを使用して、サービス間のフィールド値をマップすることもできます。
メッセージは、次の方法で変換できます。
メッセージ構造の再フォーマットにXQueryまたはXSLTを使用します。
特定のデータ要素を追加、削除または置換することで、メッセージのコンテンツを操作します。
システム間のエンティティのマップに相互参照表またはドメイン値マップ表を使用します。
JDeveloperのXQueryマッパーはXML、非XMLおよびJavaデータ型の間のデータを変換するマッピングを定義できるグラフィカル・ツールであるため、異種アプリケーションの速やかな統合を実現します。たとえば、あるスキーマに対して有効なXMLを異なるスキーマに対して有効なXMLに変換できます。データは、XMLスキーマ、Web Service Definition Language (WSDL)ファイルおよびMessage Format Language (MFL)ファイルに基づいたデータを使用できます。XQueryマッピングをJDeveloperで作成して、Oracle Service Busコンソールで、マッパーによって生成される.xqyファイルをXQueryリソースにアップロードできます。XQueryマッピングはService BusのXQueryリソースに格納されます。これは、メッセージ・フロー・アクションで式エディタを使用して作成する式から参照できます。
XQueryマッパーの出力はXQuery言語で記述された問合せです。XQuery言語はWorld Wide Web Consortium (W3C)により定義されています。W3CおよびXQuery言語の詳細は、http://www.w3.org/XML/Query/を参照してください。
詳細は、「XQueryでのデータの変換」およびOracle SOA SuiteでのSOAアプリケーションの開発のXQueryマッパーによる変換の作成に関する項を参照してください。
eXtensible Stylesheet Language Transformation (XSLT)マップでは、XML間のマッピングを記述します。JDeveloperのXSLTマッパーは、スキーマ・ルート要素、Web Services Description Language (WSDL)メッセージ部またはWSDLメッセージ間のマッピングを定義できるグラフィカル・ツールです。スキーマ・ルート要素は、XSDスキーマ・ファイルまたはWSDLファイルをソースにできます。直接マップできるのは、単一のメッセージ・パートを含んでいるWSDLメッセージのみです。
JDeveloperのXSLTマッパーでは、メッセージ本文全体に適用される変換を定義して、1つのXMLスキーマから別のXMLスキーマにメッセージを変換できるため、異なるスキーマを使用するアプリケーション間でのデータのやり取りが可能です。XSLTマッピングをJDeveloperで作成して、Oracle Service Busコンソールで、マッパーによって生成される.xslファイルをXSLTリソースにアップロードできます。XSLTマッピングはService BusのXSLTリソースに格納されます。これは、メッセージ・フロー・アクションで式エディタを使用して作成する式から参照できます。
詳細は、「XSLTでのデータの変換」、およびOracle SOA SuiteでのSOAアプリケーションの開発のXSLTマッパーによる変換の作成に関する項を参照してください。
相互参照表は、複数のアプリケーションにわたる同等のオブジェクトを表す識別子をマップし、異なる外部アプリケーションで作成された同様のオブジェクトを関連付けます。これらは、Service Busを介してデータを共有する各種アプリケーション間での実行時相関の管理に使用されます。たとえば、相互参照を使用して、複数の顧客管理システムで作成されたレコードの顧客IDをマップできます。相互参照の値は実行時に更新できるため、システム間で値を動的に統合できます。実行時に更新された相互参照データは、データベースに保持されます。相互参照は、複数のOracle SOA Suiteコンポーネント間で使用できます。Service Busでは、JDeveloperとOracle Service Busコンソールの両方で相互参照表を作成できます。
Service Busには、相互参照の値をルックアップおよび変更するためのXPath関数のセットがあります。これらの関数は、メッセージ・フロー・アクションで式エディタを使用して作成する式で使用する場合に利用できます。詳細は、「相互参照でのデータのマッピング」を参照してください。
ドメイン値マップによって、同じエンティティを記述する様々なドメインで使用される用語が関連付けられるため、複数のボキャブラリまたはシステム間での用語のマッピングが可能になります。たとえば、各ドメインで、国コード、市区町村コードまたは通貨コードなどに異なる専門用語を使用できます。これらの値をマップに入力して実行時に値を検索すると、あるドメインから別のドメインにデータを渡すときにそのデータを変換できます。ドメイン値マップは相互参照と似ていますが、動的にではなく静的に定義されます。ドメイン値マップは、デザインタイムに作成して移入し、ランタイムにデプロイします。ドメイン値マップ・データは相互参照のように実行時アクティビティによって変更されることはなく、ドメイン値マップはルックアップのためのみに使用されます。
ドメイン値マップは、複数のOracle SOA Suiteコンポーネント間で使用できます。Service Busでは、JDeveloperとOracle Service Busコンソールの両方でドメイン値マップを作成できます。Service Busには、ドメイン値マップの値をルックアップするためのXPath関数のセットがあります。これらの関数は、メッセージ・フロー・アクションで式エディタを使用して作成する式で使用する場合に利用できます。詳細は、「ドメイン値マップでのデータのマッピング」を参照してください。
一部のトランスポートは、JavaScriptおよびJARファイルまたはMQ接続などの特定タイプのファイルに依存します。JCAトランスポートには、それが参照するJCAファイルおよび任意のファイル(WSDLファイルなど)が必要です。この項では、特定のトランスポートに固有のリソースについて説明します。
Service BusのJCAバインド・リソースを使用すると、Oracle SOA Suite JCAアダプタを介して外部サービスと相互作用するビジネス・サービスとプロキシ・サービスを作成できます。JCAバインドは、サービスWSDLドキュメントと、Oracle JDeveloperで作成された対応するJCAファイルで構成されます。JDeveloperでは、Service Bus概要エディタを使用してService Busプロジェクトに直接JCAアダプタを追加できます。このためには、アダプタ・タイプを「コンポーネント」ウィンドウからエディタのキャンバスにドラッグ・アンド・ドロップします。プロキシ・サービスまたはビジネス・サービスは、JCAアダプタ構成から自動的に生成され、JCAトランスポートに基づきます。Oracle Service Busコンソールで、該当のJCAアダプタに基づきビジネス・サービスやプロキシ・サービスを作成するには、JCAファイルをJCAバインド・リソースにアップロードする必要があります。インポート機能を使用して、JCAファイルとその関連WSDLファイルをインポートすることもできます。
詳細は、「JCAバインド・リソースの操作」を参照してください。
JAR (Java Archive)ファイルとは、Javaクラスを含むzipファイルです。コンパイルされたJavaクラスと、プログラムを構成する関連メタデータの保存に使用します。JARファイルはJavaコード要素用のコール可能なプログラム・ライブラリのように機能します(それぞれの要素に対して個別にバインディングを要求するのではなく、単一のコンパイル・リンクが複数要素へのアクセスを提供します)。
JDeveloperでは、ファイル・システムからJARファイルをプロジェクトやコンポーネントに直接追加できますが、Oracle Service Busコンソールでは、プロジェクトに追加する各JARファイルをアーカイブ・リソースにアップロードする必要があります。Service Busでは、JARファイルは、次のコンポーネントで使用されます。
Java終了メカニズムを提供する(パイプライン内の)Javaコールアウト・アクション
EJBベースのビジネス・サービス
JEJBベースのビジネス・サービスおよびプロキシ・サービス
Tuxedoベースのプロキシ・サービスとビジネス・サービス
詳細は、JARファイルの操作を参照してください。
JavaScriptファイルは、ハンドシェイクを扱うためのメカニズムとしてJCAソケット・アダプタで使用されます。XSLTおよびカスタムJavaコードも、サポート対象のハンドシェイク・メカニズムです。JDeveloperでは、JavaScriptファイルを作成してから、JCAソケット・アダプタの構成時にそのファイルを選択できます。また、アダプタの構成時にJavaScriptを作成することもできます。Oracle Service Busコンソールでは、既存のJavaScriptファイルをJavaScriptリソースにアップロードするか、JavaScriptのテキストをコンソールのテキスト・エディタで作成できます。あるいは、コンソールのインポート機能を使用して、ソケット・アダプタのJCAファイルとその依存関係(WSDLファイルやJavaScriptファイルなど)をインポートできます。
Service Busでは、インバウンド・ソケット・アダプタとアウトバウンド・ソケット・アダプタの両方に対して、および一方向とリクエスト/レスポンスのメッセージングに対してJavaScriptハンドシェイクをサポートしています。リクエスト/レスポンス・ハンドシェイクでは、リクエストとレスポンスに対して個別のJavaScriptファイルが必要になります。
詳細は、「JavaScriptリソースの操作」を参照してください。
MQ接続リソースは、MQキュー・マネージャに接続するために必要な接続パラメータを提供します。これらは、MQトランスポートを使用するように構成されるプロキシ・サービスおよびビジネス・サービスで使用され、複数のサービス間で共有および再利用できます。MQプロキシ・サービスおよびビジネス・サービスは、MQキューにアクセスする前に、MQキュー・マネージャに接続する必要があります。各MQ接続リソースでは接続プールを使用し、同じMQ接続リソースを使用してキュー・マネージャに接続するすべてのビジネス・サービスまたはプロキシ・サービスでも、同じ接続プールを使用します。つまり、複数のビジネス・サービスまたはプロキシ・サービスで、同じキュー・マネージャを使用して、接続プールを共有できます。
Oracle Service BusコンソールでMQ接続を作成するには、WebSphere MQクライアント・ライブラリをService Busドメインにインストールする必要があります。これについては、「MQ接続の作成方法」で説明します。
Service Busサービスは、各種ドキュメント・タイプに依存して、メッセージ構造やWebインタフェースなどの情報を定義します。これらのドキュメントには、データを記述するXMLスキーマ、MFLファイルおよびXMLファイルや、インタフェースを記述するWSDLドキュメントおよびWADLドキュメントなどがあります。
Service Busには、設計時に使用できるタイプ・システムが組み込まれています。条件、インプレース更新アクション、または変換のそれぞれについてXQuery式を作成するとき、エディタで変数の型を任意に宣言できるため、XQueryの作成が容易になります。使用できる型は以下のとおりです。
XMLスキーマ型または要素
WSDL型または要素
MFLタイプ
XMLスキーマとは、XMLドキュメントの基本データや構造化データの有効なコンテンツを定義するドキュメントです。XMLスキーマでは、ドキュメントの構造、ドキュメントに含まれる各要素や属性のデータ型、およびXMLビジネス・データが従う必要があるルールを指定します。XMLスキーマには、他のXMLスキーマをインポートまたは含めることができます。スキーマは、Service Busで変換されるメッセージにXML情報を追加する場合に使用され、XQuery式、WSDLファイルなどに必要です。
詳細は、「XMLスキーマの使用」を参照してください。
XMLドキュメントのリソースは、プロキシ・サービスやビジネス・サービスの構成時に参照できるXMLファイルを格納します。たとえば、JCA準拠のシステムと通信するJCAのプロキシ・サービスまたはビジネス・サービスに必要なTopLinkマッピング・ファイルに対するXMLドキュメントを使用するとします。
XMLドキュメントは、JDeveloperの標準機能です。Oracle Service BusコンソールでXMLドキュメントを作成するには、インポート機能を使用する方法が最も簡単です。たとえば、JCAリソース(JCAファイル、および関連付けられているWSDLファイルとマッピング・ファイル)をインポートする場合、Service Busによって、マッピング・ファイルからXMLドキュメント・リソースが自動的に生成され、リソース・ファイル間の依存関係が保持されます。また、XMLドキュメント・リソースを作成し、XMLファイルのコンテンツをリソースにアップロードすることもできます。
詳細は、「XMLドキュメントの操作」を参照してください。
WSDL (Web Service Definition Language)インタフェースは、SOAPサービスまたはXMLサービスのサービス・インタフェースを定義します。Webサービスの場合、WSDLドキュメントには、Webサービスのインタフェースとその場所、およびその呼出し方法が記述されます。Service Busでは、次の2つのWSDLエンティティの観点で、プロキシ・サービスおよびビジネス・サービスが定義されます。
インタフェース内の操作、および操作の署名のメッセージ部のタイプを定義する抽象WSDLインタフェース。
メッセージ部のメッセージへのバインディング(パッケージング)、およびメッセージのトランスポートへのバインディングを定義するバインディングWSDLインタフェース。
さらに、WSDLファイルでは、サービスの具象インタフェース(たとえば、トランスポートURL)を記述することもできます。
プロキシ・サービスやビジネス・サービスの定義は、既存のWSDLファイルに基づき作成できます。これにより、サービスの部分が自動的に構成されます。サービスの定義の基になるWSDLファイルは、Service Busのリソースとして格納されます。JDeveloperでは、組込みのWSDLエディタを使用してWSDLファイルを作成できます。その後、これらのWSDLファイルと、ファイルで使用されるスキーマをOracle Service Busコンソールにインポートできます。コンソールを使用すると、WSDLファイルでの参照も解決できるため、すべてのスキーマとWSDLファイルが正しくリンクされます。Service Busではメッセージング・サービスに対して、独自のインタフェース表現が使用されます。
詳細は、「WSDLドキュメントの操作」を参照してください。
Web Application Definition Language (WADL)ドキュメントは、前述のWSDLドキュメントと似ていますが、RESTプロキシ・サービスまたはビジネス・サービスのインタフェースを記述する場合に特に使用されます。RESTバインディングに基づいてプロキシ・サービスまたはビジネス・サービスをJDeveloperで作成する場合、バインディングに指定したWSDLドキュメントから必要なWADLドキュメントが自動で生成されます。WADLファイルには、1つのWSDLファイルおよび1つ以上のXMLスキーマに対する依存関係を含めることができます。
Oracle Service Busコンソールを使用する場合、WADLドキュメントを作成するには、ドキュメントをインポートするかWADLリソースを作成します。詳細は、「WADLドキュメントの作成」を参照してください。
Service Busでは、Message Format Language (MFL)を使用して、型付きの非XMLデータの構造を記述します。MFLは、フォーマットされたバイナリ・データをXMLデータに変換するルールを定義する場合に使用されるOracle独自の言語です。MFLドキュメントは、非XMLデータ・レコードのインスタンスをXMLドキュメントのインスタンス(またはその逆)に変換するために実行時に使用されます。
JDeveloperでFormat Builderツールを使用してMFLドキュメントを作成します。Format Builderでは、非XMLデータのレイアウトと階層を、XMLと相互に変換できるように記述できます。Format Builderを使用して、データの型やサイズ、フィールドの名前、デリミタなどのメッセージの各フィールドを定義します。また、フィールドの繰返しの有無や、フィールドがオプションと必須のどちらであるかも指定できます。
詳細は、「Message Format Languageによるデータ構造の定義」を参照してください。
セキュリティ情報は、ユーザー名やパスワードの取得方法を定義するサービス・アカウント、または暗号化資格証明を定義するサービス・キー・プロバイダを使用して、プロキシ・サービスやビジネス・サービスに渡すことができます。
サービス・キー・プロバイダ・リソースには、プロキシ・サービスがインバウンドSOAPメッセージの復号化やアウトバウンド認証およびデジタル署名に使用する公開鍵インフラストラクチャ(PKI)資格証明が含まれます。PKI資格証明とは、デジタル署名や暗号化(Webサービス・セキュリティ)、およびアウトバウンドSSL認証に使用できる証明書とペアになった秘密鍵です。この証明書には、秘密鍵に対応する公開鍵が含まれています。
Service Busでは、サービス・キー・プロバイダを使用して、プロキシ・サービスに次のタイプの資格証明レベルの検証を提供します。
SSLクライアント認証
デジタル署名
暗号化
Webサービス・セキュリティX509トークン
詳細は、「サービス・キー・プロバイダの操作」を参照してください。
サービス・アカウント・リソースでは、サービスやサーバーに接続するときに、Service Busが認証に使用するユーザー名とパスワードが提供されます。サービス・アカウントは、プロキシ・サービスとビジネス・サービスがアウトバウンド認証を行うとき、またはプロキシ・サービスとビジネス・サービスがFTPサーバーやJMSサーバーなどのローカルまたはリモート・リソースを認証するときに使用します。サービス・アカウントは、特定のユーザー名とパスワードのペア、および着信リクエストから受信するユーザー名とパスワードを使用するように構成したり、クライアントで提供されるユーザー名とパスワードを、指定したユーザー名とパスワードにマップするように構成したりすることができます。1つのサービス・アカウントを複数のビジネス・サービスおよびプロキシ・サービスに使用できます。
詳細は、「サービス・アカウントの操作」を参照してください。
以前のバージョンでは、WS-Policyリソースは、カスタムWebサービス・ポリシーを格納する場合に使用されていたため、複数のWSDLドキュメントで参照できていました。12c以降では、Oracle Web Services Manager (OWSM)ポリシーによりWLS9ポリシーが置き換えられるため、WSDLベースのWLS9ポリシーで新しいサービスを作成するオプションがなくなっています。WS-Policyリソースは引き続きインポートされたプロジェクトで表示できますが、関連付けられたWebサービスは、OWSMポリシーを使用するように更新する必要があります。ただし、引き続き、WS-Policyリソースを使用する以前のバージョンからプロジェクトをインポートしてアクティブ化できます。
アラート宛先リソースは、Service Busからのアラート通知を受信できる受信者のリストを定義します。たとえば、サービス・レベル合意(SLA)またはパイプライン・アラートを生成する場合、特定の電子メール・アドレスやJMSキューに通知が送られるように指定できるため、関係者のみが通知を受け取ることができます。アラート宛先には、宛先タイプ(Service Busレポート・データ・ストリーム、SNMPトラップ、アラート・ログ、電子メール、JMSキューまたはJMSトピック)を1つ以上を含めることができます。電子メールおよびJMS宛先の場合は、宛先リソースはそれぞれ電子メール・アドレスまたはJMS URIのリストを含む場合があります。
詳細は、「アラート宛先の操作」を参照してください。
スロットルは、トラフィックの多いビジネス・サービスでのメッセージの過負荷を防ぐことによって、パフォーマンスおよび安定性の向上に役立ちます。ビジネス・サービスへのメッセージのフロー制御とバックログの回避を行うために、Service Busアプリケーションでビジネス・サービスまたはビジネス・サービスのグループに対してメッセージのスロットルを有効にして構成できます。メッセージがスロットルされると、ビジネス・サービスは、指定した数のメッセージのみを同時に処理できます。その容量に達すると、メッセージは、ビジネス・サービスがそれ以上のメッセージの処理の準備ができるまでメモリー内キューに格納されます。
詳細は、『Oracle Service Busの管理』のメッセージのスロットルに対するビジネス・サービスの構成に関する項を参照してください。
システム・リソースは、Service Busインスタンス内のすべてのプロジェクトで共有できる、グローバルに使用可能なリソースです。これらは、サーバー接続と認証の情報を定義します。たとえば、次のリソースがあります。
Oracle Service Busコンソールでは、システム・リソースは、個別のプロジェクト名の付いたシステムに格納されます。JDeveloperでは、システム・リソースは、「アプリケーション・リソース」パネルの「Service Busシステム・リソース」に格納されます。
JNDIプロバイダ・リソースは、JNDI名のオブジェクトへのアクセスに必要な接続および認証情報を定義します。これらは、Service Busで使用されるJNDIプロバイダのURL (またはクラスタ化されたデプロイメントの場合はURLのリスト)を記述します。たとえば、EJBの起動に使用されるビジネス・サービスで、エンドポイントURIにJNDIプロバイダ・リソースの名前を含めます。ビジネス・サービスが起動されると、Service Busでは参照されたJNDIプロバイダ・リソースの詳細を使用して、JNDIプロバイダへの初期接続が行われます。
JNDIプロバイダが保護されている場合、JNDIプロバイダ・リソースでは、アクセスに必要なユーザー名とパスワードも定義されます。JNDIプロバイダは高度な柔軟性を備えています。JNDI接続が変更された場合、JNDIプロバイダ・リソースのみを修正すればよく、JNDIプロバイダを参照するそれ以外の要素は、更新された構成を自動的に使用します。
詳細は、「JNDIプロバイダ・リソースの操作」を参照してください。
SMTPサーバー・リソースは、電子メール宛先、ポート番号および必要な場合に認証資格証明に対応するSMTPサーバーのアドレスを定義します。これらは、Service Busで使用されるSMTPサーバーのURLを記述します。SMTPサーバーが保護されている場合、SMTPサーバー・リソースの記述には、アクセスに必要なユーザー名とパスワードも含まれます。SMTPサーバー・リソースは、アラート宛先リソースおよび電子メール・トランスポートベースのビジネス・サービスの構成を行う際に参照されます。
詳細は、「SMTPサーバー・リソースの操作」を参照してください。
プロキシ・サーバー・リソースは、JNDI名のオブジェクトへのアクセスに必要な接続および認証情報を定義します。これらは、Service Busで使用されるプロキシ・サーバーのURLを記述します。プロキシ・サーバーが保護されている場合、プロキシ・サーバー・リソースの記述には、アクセスに必要なユーザー名とパスワードも含まれます。プロキシ・サーバーを使用すると、クライアント・アプリケーションからリクエストをプロキシできます。Service Busがファイアウォールの後ろにある場合は、通常プロキシ・サーバーを使用します。メッセージをプロキシ・サーバー経由でルーティングするようにビジネス・サービスを構成する場合、プロキシ・サーバー・リソースとそのビジネス・サービスを関連付けます。これにより、Service Busが、構成されたプロキシ・サーバーを使用してビジネス・サービスへの接続を行います。
各プロキシ・サーバー・リソースに複数のプロキシ・サーバーを構成できます。この場合、Service Busでロード・バランシングが実行され、構成されたプロキシ・サーバー間でフォルト・トレランスが可能になります。
詳細は、「プロキシ・サーバー・リソースの操作」を参照してください。
Universal Description, Discovery and Integration (UDDI)レジストリは、Webサービスを共有するために使用されます。UDDIは、企業のビジネス、ビジネス・サービス、および公開するサービスの技術的な詳細を分類するためのフレームワークを提供します。UDDIレジストリ・リソースは、サービスの検出、パブリッシュおよび同期の目的でService BusがアクセスするUDDIレジストリに関する情報を格納します。UDDIレジストリ・リソースを構成すると、関連付けられたレジストリにService Busプロキシ・サービスをパブリッシュしたり、プロキシ・サービスで使用するビジネス・サービスをレジストリからインポートしたりできます。UDDIレジストリ・リソースでは、照会URL、パブリッシュURLおよびサブスクリプションURLと、レジストリへのアクセスに必要なユーザー名およびパスワードを定義します。
詳細は、「UDDIレジストリの操作」を参照してください。
この項では、Service Busでサポートされるメッセージングのタイプ、メッセージ・フォーマット、およびService Busプロジェクトのコンポーネントによって渡される(コンポーネントによってオプションで変更される)コンテキスト変数について説明します。
Service Busには複数のメッセージング・パラダイムが採用されており、次のタイプの通信をサポートします。
同期リクエスト/レスポンス
非同期パブリッシュ1対1
非同期パブリッシュ1対多
非同期リクエスト/レスポンス(同期と非同期のブリッジング)
同期と非同期のブリッジングでは、同期クライアントが非同期プロバイダにリクエストを発行します。このパターンの場合、レスポンスをリスンするときのタイムアウト値を使用して、1つ目のJMSキューにメッセージをパブリッシュし、レスポンス用の2つ目のJMSキューを構成できます。このタイプのサービスは、サービス・コンシューマからは同期サービスに見えます。非同期リクエスト/レスポンス・メッセージを使用すると、次のような利点があります。
多数のブロックされているリクエスト/レスポンスの呼出しによって発生する可能性のあるスレッド管理の問題が解消され、リクエスト・スレッドによるブロッキングがなくなります。
メッセージングの信頼性が向上します。
Service Busでは、次のメッセージ・フォーマットがサポートされます。
添付ファイルなしまたは添付ファイル付き電子メール
Java
ヘッダー付きJMS
MFL (メッセージ・フォーマット言語)
生データ(既知のスキーマを持たない不明確な非XMLデータ)
テキスト
SOAPおよび添付ファイル付きSOAP (WSDLドキュメントで記述されたSOAPまたは記述されないSOAP)
XMLおよび添付ファイル付きXML (WSDLドキュメントまたはスキーマで記述されたXMLまたは記述されないXML)
プロキシ・サービスによって送受信されるすべてのメッセージは、内部で一連のプロパティによって定義されます。これらのプロパティは、メッセージ・データや、そのメッセージに関連するメタデータを保持しています。この一連のプロパティは、メッセージ・コンテキストと呼ばれ、コンテキスト変数を使用して実装されます。コンテキストは、XMLスキーマによって定義されます。コンテキスト変数には、事前定義された変数とユーザー定義の変数があります。
あらかじめ定義されたコンテキスト変数には、メッセージに関する情報、トランスポート・ヘッダー、セキュリティ・プリンシパル、現在のプロキシ・サービスのメタデータ、およびプロキシ・サービスから呼び出されるプライマリ・ルーティング・サービスとパブリッシュ・サービスのメタデータが含まれます。通常は、メッセージがService Busを介して移動すると、パイプラインでXQuery式を使用して、コンテキスト変数を操作します。変換およびインプレース更新アクションを使用してコンテキスト変数を変更することもできます。
メッセージ・フローで使用されるメッセージ・コンテキストおよびコンテキスト変数の詳細は、「メッセージ・コンテキスト」を参照してください。
Service Busでは、種類の異なるエンドポイントとの相互運用性をサポートするために、サービスの構成で、使用するコンテンツ・タイプ、JMSタイプおよびエンコーディングを制御できます。外部クライアントやサービスで必要になるものについては仮定を行わず、かわりにプロキシ・サービスやビジネス・サービスの構成を使用します。Service Busでは、アウトバウンド・メッセージのコンテンツ・タイプを、サービス・タイプとインタフェースから導出し、次の仕様を使用します。
XMLまたはSOAPの場合(WSDLファイルの有無を問わない)、コンテンツ・タイプはtext/XML。
インタフェースがMFLまたはバイナリのメッセージング・サービスの場合、コンテンツ・タイプはbinary/octet-stream。
インタフェースがテキストのメッセージング・サービスの場合、コンテンツ・タイプはtext/plain。
インタフェースがXMLのメッセージング・サービスの場合、コンテンツ・タイプはtext/XML。
RESTバインディングを使用するサービスの場合、コンテンツ・タイプはapplication/xmlまたはapplication/json。
サービスを呼び出すパイプラインのアウトバウンド・コンテキスト変数($outbound)のコンテンツ・タイプ、およびパイプライン・レスポンスのインバウンド・コンテキスト変数($inbound)のコンテンツ・タイプはオーバーライドできます。さらに、サービスが定義される場合に構成できるJMSタイプ(バイトまたはテキスト)があります。すべてのアウトバウンド・メッセージについて、サービス定義でエンコーディングが明示的に構成されます。
Service Busでは、Oracle WebLogic Serverワーク・マネージャを使用して、パフォーマンスを最適化して、サービス・レベル合意を維持します。ワーク・マネージャでは、定義したルールに基づいて、さらには実行時パフォーマンスによって、作業の優先順位を決定してスレッドを割り当てます。ワーク・マネージャを作成して構成する場合、使用するスレッドの最大数と最小数、サーバー容量、およびスケジューリング・ガイドラインを表すリクエスト・クラスとレスポンス・クラスを定義します。デフォルトのワーク・マネージャが1つ用意されていますが、サービスの最適化に必要な分のワーク・マネージャを作成できます。Service Busでは、トランスポート構成の「ディスパッチ・ポリシー」プロパティで、プロキシ・サービスやビジネス・サービスのワーク・マネージャを指定します。
ワーク・マネージャの詳細は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。Service Busでのワーク・マネージャの詳細は、「Service Busでのワーク・マネージャの使用」を参照してください。
Service Busでは、Oracle Platform Security Services (OPSS)およびOracle Web Services Manager (OWSM)を使用して、より高度なセキュリティ・サービスを構成します。これには、認証、IDアサーション、認可、ロール・マッピング、監査、資格証明マッピングなどが含まれます。Service Busアクセス・セキュリティを構成するには、最初にOracle WebLogic Serverセキュリティを構成する必要があります。Service BusでOWSMを使用すると、組織全体で一貫性のあるWebサービスの管理と保護のためのポリシー・フレームワークが提供されます。
Service Busには、次のセキュリティ機能が用意されています。
OWSMおよびOPSSとの統合
Webサービス・セキュリティ(WS-Security)仕様に定義された認証、暗号化と復号化、およびデジタル署名
HTTPおよびJMSトランスポート・プロトコルの従来のトランスポート・レベルのセキュリティをサポートするSSL
証明書に基づく一方向および双方向の認証
HTTP基本認証
ユーザー名およびパスワードを含むリソース(サービス・アカウント、サービス・キー・プロバイダ、UDDIレジストリ、SMTPプロバイダ、JNDIプロバイダなど)の暗号化とエクスポート
ユーザー名、パスワードおよび資格証明別名バインディングを定義するサービス・アカウントとサービス・キー・プロバイダ
トランスポート・レベルとメッセージ・レベルのインバウンド・リクエストに対するクライアント指定のカスタム認証資格証明
Service Busサービスは、そのインタフェース内のメッセージに適用されるセキュリティ・ポリシーによって保護できます。セキュリティ・ポリシーの適用対象として、サービスを指定することも、サービスのオペレーションに関連する個々のメッセージを指定することもできます。サービスに対してセキュリティ・ポリシーを指定した場合、そのサービスのすべてのメッセージにポリシーが適用されます。
Service Busサービスは、次のタイプのセキュリティを使用して保護できます。
インバウンド・セキュリティ
アウトバウンド・セキュリティ
IDの伝播のオプション
管理セキュリティ
サポートされる標準とセキュリティ・プロバイダ
図1-4に、メッセージ・ライフ・サイクルの様々なポイントでのセキュリティ機能を示します。
Service Busサービスは、Oracle Web Services Manager (OWSM)ポリシーをアタッチすることで保護できます。OWSMは、Oracle Enterprise Manager Fusion Middleware Controlのコンポーネントで、Oracle SOA Suite環境とアプリケーションの集中管理および制御を提供するランタイムのフレームワークです。これには、セキュリティ、信頼性のあるメッセージング、MTOMおよびアドレス・ポリシーなどのWebサービス・ポリシーを構築、施行、実行および監視できる機能があります。OWSMは、開発者が設計時に使用したり、システム管理者が本番環境で使用したりすることができます。OWSMにより、ローカル施行によるWebサービスのポリシー駆動集中管理が可能になります。OWSMには、組織全体で一貫性のあるWebサービスの管理と保護のためのポリシー・フレームワークがあります。
Oracle Platform Security Services (OPSS)には、Java Standard Edition (Java SE)およびJava Enterprise Edition (Java EE)アプリケーション向けの、標準ベースで移植可能な、エンタープライズ級の統合セキュリティ・フレームワークが用意されています。OPSSでは、標準ベースのAPIの形式で抽象化レイヤーが提供されているため、開発者はセキュリティやID管理の実装についての詳細を意識する必要がありません。開発者は、暗号鍵管理や、ユーザー・リポジトリおよびその他のID管理インフラストラクチャとの相互作用について詳しく理解する必要はありません。
OWSMによって、Service BusセキュリティはWebサービス・ポリシー(WS-Policy)仕様をサポートします。これは、それぞれ1つ以上のアサーションが含まれるポリシーを使用してWebサービスのセキュリティ制約と要件を定義するための標準ベースのフレームワークです。WS-Policyアサーションにより、デジタル署名や暗号化に対するWebサービスの要件、および必要なセキュリティ・アルゴリズムや認証メカニズムが指定されます。
WS-Policyのポリシーは、直接WSDLドキュメントに含めることも、参照により含めることも可能です。WSDLドキュメントは、WS-Policyのポリシーを含むか、これを参照する他のWSDLドキュメントをインポートできます。実行時環境では、抽象的なWS-Policy文と具象的なWS-Policy文の両方を認識します。抽象WS-Policy文では、セキュリティ・トークンを指定しません。具象WS-Policy文では、認証、暗号化およびデジタル署名のためのセキュリティ・トークンを指定します。抽象ポリシーが受け取るセキュリティ・トークンのタイプは、Service Busの実行時環境で決定します。
WS-Policy仕様の詳細は、次の場所にあるWeb Services Policy Framework (WS-Policy)とWeb Services Policy Attachment (WS-PolicyAttachment)に関する記述を参照してください: http://specs.xmlsoap.org/ws/2004/09/policy/。
次の項では、Service Busのセキュリティ・モデルで使用できるセキュリティ機能について説明します。
インバウンド・セキュリティによって、プロキシ・サービスは認可されたクライアントから出されたリクエストのみを処理し、クライアントからデータが送信されたときに、認可されていないユーザーがそのデータを参照または変更していないことが保証されます。外向きのプロキシ・サービス(サービス・コンシューマからリクエストを受信します)の場合は、双方向SSL over HTTPSなどの厳密なセキュリティ要件を使用します。プロキシ・サービスで、デジタル署名、暗号化またはSSL認証に対して公開鍵インフラストラクチャ(PKI)テクノロジを使用する場合は、証明書とペアの秘密鍵を提供するサービス・キー・プロバイダを作成できます。
アウトバウンド・セキュリティは、プロキシ・サービスとビジネス・サービス間の通信を保護します。プロキシ・サービスを構成するタスクの大半は、ビジネス・サービスが指定するトランスポート・レベルのセキュリティまたはメッセージ・レベルのセキュリティの要件に準拠しています。ビジネス・サービスでデジタル署名にSSL認証またはPKIテクノロジが必要な場合は、証明書とペアの秘密鍵を提供するサービス・キー・プロバイダが必要です。
IDの伝播用にService Busで提供されるオプションでは、クライアントが提示するIDの伝播方法など、セキュリティを設計するときの判断を行うことができます。Service Busは、クライアントで提供される資格証明を認証して認可チェックを実行し、資格証明をそのまま渡して資格証明をマップするように構成できます。
Service Busユーザー管理はWebLogic Serverセキュリティに基づきます。これは、任意のグループまたは個々のユーザーに割り当てられたロールに関連付けられているセキュリティ・ポリシーを基にしたタスク・レベルの認可をサポートします。Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用して、Service Busのユーザー、グループおよびロールを管理します。
プロキシ・サービスなどのリソースの作成といった機能にユーザーがアクセスできるようにするには、事前定義済のアクセス権限を持つ、事前定義済の1つ以上のセキュリティ・ロールにユーザーを割り当てます。Service Busの管理セキュリティ・ロールのアクセス特権は変更できませんが、それらのロールのいずれかにユーザーまたはグループを入れるための条件は変更できます。デフォルトでは、Service Busドメインで最初に作成されるユーザーはWebLogic Server管理者です。このユーザーは、Service Busのすべてのオブジェクトおよび機能にアクセスでき、ユーザー管理タスクを実行してService Bus機能へのアクセス制御を行うことができます。
詳細は、『Oracle Service Busの管理』のOracle Service Busのアクセス・セキュリティの定義に関する項を参照してください。
Service Busでは、トランスポート・レベルの機密性、メッセージの整合性、および一方向のリクエストまたはリクエスト/レスポンスのトランザクションでのクライアント認証がHTTPS経由でサポートされます。HTTP(S)プロキシ・サービスまたはビジネス・サービスは、基本認証、クライアント証明書(双方向SSL)認証、カスタム認証が必要になるように構成するか、クライアント認証をまったく行わないように構成できます。Service Busでサポートされる、HTTP以外のトランスポート方式でのトランスポート・セキュリティは次のとおりです。
電子メール・トランスポートおよびFTPトランスポートでは、FTPサーバーまたは電子メール・サーバーへの接続に資格証明を使用してセキュリティが提供されます。
ファイル・トランスポートでは、ファイルが存在するマシンへのログイン・コントロールを使用したセキュリティが提供されます。
Service Busでは、OASIS Web Services Security (WSS) 1.0をサポートしています。WSSは、メッセージの機密性、整合性、およびSOAPメッセージでのセンダー認証を実現するためのフレームワークを定義します。Service BusでWSSを使用することにより、デジタル署名または暗号化、あるいはその両方を使用するメッセージを保護できます。WSSは、トランスポート・レベルのセキュリティとしては使用できませんが、エンド・ツー・エンドのメッセージで機密性および整合性を確保するのに適しています。WSSは、SOAPエンベロープの一部の要素のみに署名または暗号化、あるいはその両方を適用し、残りの要素には署名または暗号化を適用しないことが可能であるため、SSLよりも柔軟性に富んでいます。これは、Service Busの機能と結合されると、メッセージのコンテンツに基づいてデータのルーティングの決定およびデータの変換を行うための強力な機能になります。Service Busでは、HTTP(S)およびJMSを介したWSSがサポートされます。
WSS仕様の詳細は、次の場所にあるOASIS Web Services Security TCを参照してください: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss。
Service Busは、トランスポート・レベルおよびメッセージ・レベルのインバウンド・リクエストに対して、クライアント指定のカスタム認証資格証明をサポートします。カスタム認証資格証明は、トークン、またはユーザー名とパスワードのトークンの組合せになります。Service Busでは、次の認証を承認して試行します。
HTTPヘッダー、SOAPヘッダー(SOAPベースのプロキシ・サービスの場合)、またはペイロード(非SOAPプロキシ・サービスの場合)でプロキシ・サービスに渡されるカスタム・トークン。
SOAPヘッダー(SOAPベースのプロキシ・サービスの場合)またはペイロード(非SOAPプロキシ・サービスの場合)で渡されるユーザー名およびパスワードのトークン。
アウトバウンド・リクエストの場合、カスタム認証は、作成するカスタム・オーセンティケータJavaクラスに基づきトランスポート・レベルでサポートされます。カスタム認証メカニズムは、単独で機能するか、またはWebサービスのメッセージ・レベル・セキュリティと組み合せて機能します。カスタム・セキュリティ資格証明の詳細は、「カスタム認証の構成」を参照してください。
Service Busサービスを作成するとき、Oracle Service Busコンソールを使用するか、JDeveloperを使用するかにより、その構築方法を選択できます。JDeveloperでは両方の方法をサポートしますが、コンソールではボトムアップの方法のみがサポートされます。
トップダウン: この方法では、プロセスを分析し、このプロセスを支援するアクティビティを特定します。Service Bus概要エディタにより、Service Busアプリケーションおよびプロジェクトを作成し、Service Busコンポーネントを定義します。
ボトムアップ: この方法では、既存のアプリケーションおよびアセットを分析し、サービスとして使用できるものを特定します。Service Busアプリケーションを作成する際に、必要に応じてサービスを構築します。この方法は、ITが変更に応じる必要がある場合に有効です。
Service Busサービスを開発するこの方法では、Service Bus概要エディタを使用して、すべてのプライマリ・コンポーネントを一度に作成できます。たとえば、プロキシ・サービス、ビジネス・サービス、パイプライン、分割-結合およびJCAアダプタなどがあります。エディタにより、プロジェクト・コンポーネントの作成と構成が簡素化され、データ・フローの構造全体のグラフィック表示が可能です。これらのコンポーネントを作成してワイヤリングすると、それぞれの構成オプションを定義して、パイプラインや分割-結合でメッセージのルーティングや変換を定義できます。
次の表に、手順の概要と、詳細情報へのリンクを示します。
表1-1 Service Bus開発ロードマップ - トップダウン方法
| 手順 | 説明 | 詳細 |
|---|---|---|
1 |
サービス・アカウント、WSDLファイルまたはXQueryマップなど、必要なサポート・リソースを作成します。 |
各タイプのリソースのリンクについては、「Oracle Service Busの概要」に示しています。 |
2 |
プロキシ・サービス、パイプライン、ビジネス・サービスおよび分割-結合(オプション)を作成します。 |
|
3 |
コンポーネントをまとめてワイヤリングします。 |
|
4 |
プロキシ・サービスとそのトランスポートを構成します。 |
|
5 |
パイプラインと分割-結合を構成します。 |
|
6 |
ビジネス・サービスとそのトランスポートを構成します。 |
|
7 |
ビジネス・サービスおよびプロキシ・サービスのセキュリティを構成します。 |
|
8 |
サービスとリソースをテストしてデバッグします。 |
|
9 |
サービスをデプロイします。 |
|
10 |
ランタイムを監視して管理します。 |
Oracle Service Busの管理 |
Service Busサービスを開発するこの方法では、各プロジェクト・コンポーネントを個別に作成して構成します。システムを介したメッセージのフローは、プロキシ・サービス、ビジネス・サービス、パイプライン、分割-結合などのプロジェクト・コンポーネント間で作成した参照によって定義されます。この方法ではService Bus概要エディタを使用しないため、コンポーネントのグラフィカル表示では作業できません。ただし、JDeveloperで作業する場合、作成したコンポーネントは、概要ファイルに追加され、Service Bus概要エディタに表示されます。
次の表に、手順の概要と、詳細情報へのリンクを示します。
表1-2 Service Bus開発ロードマップ - ボトムアップ方法
| 手順 | 説明 | 詳細 |
|---|---|---|
1 |
サービス・アカウント、WSDLファイルまたはXQueryマップなど、必要なサポート・リソースを作成します。 |
各タイプのリソースのリンクについては、「Oracle Service Busの概要」に示しています。 |
2 |
プロキシ・サービスとパイプラインを作成します。パイプラインの作成時にプロキシ・サービスを生成できます。 |
|
3 |
プロキシ・サービスとそのトランスポートを構成します。 |
|
4 |
パイプラインでメッセージ・フローを定義します。 |
|
5 |
オプションで、並列処理の分割-結合を作成して構成します。 |
|
6 |
ビジネス・サービスを作成して構成します。 |
|
7 |
サービスのセキュリティを構成します。 |
|
8 |
サービスとリソースをテストしてデバッグします。 |
|
9 |
サービスをデプロイします。 |
|
10 |
ランタイムを監視して管理します。 |
Oracle Service Busの管理 |
Service Busプロジェクトでディレクトリまたはリソースに名前を付ける場合、許可される文字は次のとおりです。
Javaキーワードを含むすべてのJava識別子文字。Java Language Specification (http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.8)の「Identifiers」と「Keywords」のセクションを参照してください。
名前の先頭または末尾以外の場所のブランク、ピリオドおよびハイフン。
/ \ * : " < > ? | などの文字は使用できません。
次の項で説明しているURLを使用して、このドキュメントに記載されているService Busのリソースの一部を標準のWebブラウザから表示できます。
WSDLドキュメントを表示するURL:
http://host:port/sbresource?WSDL/project_path/wsdlname
WSDLベースのHTTPプロキシ・サービスのWSDLドキュメントを表示するURL:
http://host:port/proxy_service_endpoint_URI?WSDL
WSDLベースのプロキシ・サービスのWSDLドキュメントを表示するURL:
http://host:port/sbresource?PROXY/project_path/proxyname
Oracle Web Services Managerのポリシーがアタッチされているプロキシ・サービスのWSDLドキュメントを表示するURL:
http://host:port/sbresource?ORAPROXY/project_path/proxyname
WSDLベースのビジネス・サービスのWSDLドキュメントを表示するURL:
http://host:port/sbresource?BIZ/project_path/bizname
Oracle Web Services ManagerのポリシーがアタッチされているWSDLベースのビジネス・サービスのWSDLドキュメントを表示するURL:
http://host:port/sbresource?ORABIZ/project_path/bizname
WSセキュリティ・ポリシーを表示するには、次のURLを使用します。
http://host:port/sbresource?POLICY/project_path/policyname
MFLファイルを表示するには、次のURLを使用します。
http://host:port/sbresource?MFL/project_path/mflname
XMLスキーマを表示するには、次のURLを使用します。
http://host:port/sbresource?SCHEMA/project_path/schemaname
Oracle Web Services Managerポリシーを含むWSDLドキュメントを取得して、このポリシーが、サポートされるWS-PolicyおよびWS-Security Policy標準に準拠するようにすることもできます。詳細は、「WS標準をサポートするためのWSDLファイルの通知」を参照してください。
リソース名に特殊文字を使用する場合、Service Busでリソースの公開に使用するURLは、特殊文字をエスケープするためにUTF-8でエンコードする必要があります。
Service Busでは、開発にJDeveloperとOracle Service Busコンソールの両方を使用します。次の項では、両環境でのアクセシビリティ・オプションについて説明します。
JDeveloperには、スクリーン・リーダー、スクリーン拡大鏡、キーボード移動用の標準のショートカット・キーなどのアクセシビリティ・オプションが用意されています。さらに読みやすくするため、フォントのサイズや色、オブジェクトの色や形など、JDeveloperをカスタマイズすることもできます。JDeveloperでのアクセシビリティについて、およびこれを構成する手順は、『Oracle JDeveloperによるアプリケーションの開発』のOracle JDeveloperのアクセシビリティ情報に関する項を参照してください。
スクリーン・リーダー・モードが有効な状態でOracle Service Busコンソールにログインする場合、プロジェクト・ナビゲータからコンテキスト・メニューを選択するには追加の手順が必要です。プロジェクト・ナビゲータでプロジェクトおよびコンポーネントのコンテキスト・メニューにアクセスするには、[Tab]キーを使用してコンポーネントに移動し、[Enter]を押してコンポーネントを選択してから、[Ctrl]+[Alt]+[M]を押してメニューを起動します。メニューのオプションを移動するには、下矢印および上矢印を使用します。
アクセシビリティ設定は、アプリケーションのすべてのコンポーネントを読むのに役立ちます。Oracle Service Busコンソールでのアクセシビリティ・オプションの設定は、現在のインスタンスのみに対して行うことができます。コンソールでは、ログイン・ページに「アクセシビリティ」メニューが表示され、ログインする前にアクセシビリティを構成できます。
アクセシビリティ・オプションを設定するには:
次に示す「アクセシビリティ設定の編集」ページが表示されます。
注意:
このページは、ログイン後に「プリファレンス」オプションでも設定を変更できることを示しています。現在、アクセシビリティ・オプションは、「アクセシビリティ設定」ページからのみ構成できます。
この開発者ガイドに加え、Service Busを最大限活用できるようにするため、次のリソースも用意しています。
Oracle SOA Suiteの理解では、Oracle SOA SuiteおよびOracle Service Busを紹介し、このスイートにより実行できることについて、おおまかに理解できるようにします。
Oracle Service Busサービスの管理では、実行中のサービスをモニターし、実行時環境を更新する方法について説明しています。
Oracle Service Busのサンプルにはその他の学習ツールが用意されており、Service Bus機能の開始に役立ちます(http://www.oracle.com/technetwork/middleware/service-bus/learnmore/index.html)。
Oracle Fusion Middlewareドキュメント・ライブラリには、すべてのService Busドキュメントのリストが提供されています。
