|
|
この節では、Oracle Service Bus アーキテクチャの概要について説明し、サービスの迅速な統合、プロビジョニング、異なる IT インフラストラクチャ間の管理を可能にする操作上の機能について取り上げます。統合を目的とする IT 設計者で、メッセージングとサービス指向アーキテクチャ (SOA) の担当者を対象としています。内容は以下のとおりです。
Oracle Service Bus は Enterprise Service Bus を中心としたアーキテクチャです。このバスでは、SOAP、HTTP、および Java メッセージング サービス (JMS) を含む標準に基づいたメッセージ配信サービスが提供されます。これは、通常、高スループットを保証するメッセージ配信を各種サービスのプロデューサおよびコンシューマに提供するために設計されるものです。ネイティブのデータ型として XML がサポートされており、他のデータ型を処理するために、その他のデータ型も提供されます。
Oracle Service Bus はポリシー駆動型であり、「サービス クライアント」と「ビジネス サービス」との間に疎結合を確立する一方で、セキュリティ制御とモニタを一元的に管理できます。ステージングによって開発環境からプロダクション環境へ必要に応じてカスタマイズおよび伝播可能なメタデータとして、ポリシー、プロキシ サービス、および関連するリソース コンフィグレーションを永続化して保存します。メッセージ ブローカリング エンジンは、メタデータ キャッシュからこのコンフィグレーション情報にアクセスします。
Oracle Service Bus は、着信するサービス要求メッセージを処理して、ルーティング ロジックを決定し、メッセージを他のサービス コンシューマと互換性があるようにトランスフォーメーションを行う仲介機能です。HTTP(S)、JMS、ファイル、FTP などの転送プロトコルを介してメッセージを受信し、同じ転送プロトコルまたは別の転送プロトコルを使用してメッセージを送信します。サービスの応答メッセージは、これと逆のパスを辿ります。Oracle Service Bus によって処理されるメッセージは、プロキシ サービスの「メッセージ フローの定義」によって指定されるメタデータによって駆動されます。
次の上位レベルのアーキテクチャ図には、Oracle Service Bus と、その機能サブシステムであるサービス管理、メッセージ ブローカリング、コンフィグレーション フレームワーク、セキュリティ レイヤと転送レイヤ、およびメッセージング プロトコルが示されています。
メッセージには、アプリケーション プロセスについてのデータまたはステータス情報や、受信側に対する指示などが含まれます。Oracle Service Bus では、コンテンツに基づいてメッセージをルーティングし、コンテンツに対してトランスフォーメーションを実行できます。この処理は、Oracle Service Bus の転送レイヤおよびバインディング レイヤを介して実行されます。
エンドポイント (ビジネス サービスまたは別のプロキシ サービス) にメッセージが送信されると、Oracle Service Bus は上記のイベント シーケンスと同様のモデルで応答メッセージを処理します。
次の図に Oracle Service Bus における着信エンドポイント (プロキシ サービス) から発信エンドポイント (ビジネス サービスまたは他のプロキシ サービスであるサービス転送 URL) までの上位レベルのメッセージ フロー処理を示します。
以降の節では、このメッセージ処理に関連する各レイヤについて説明します。
着信転送レイヤは、クライアント サービス (またはサービス コンシューマ) と Oracle Service Bus との間にある通信レイヤです。サービス クライアント エンドポイントと通信を処理して、Oracle Service Bus へのメッセージのエントリ ポイントとして機能します。着信転送レイヤは主に入力または出力ストリームのメッセージ データを生のバイトとして処理します。
HTTP(S)、JMS、FTP、ファイル、および電子メールを含む転送プロトコルの互換性をサポートします。データの処理には関係しませんが、応答メッセージをサービス コンシューマに返し、エンドポイント URI や転送ヘッダなどメッセージのメタデータを処理します。
発信転送レイヤは、ビジネス サービス (またはサービス プロデューサ) と Oracle Service Bus との間の通信機能を担います。Oracle Service Bus からビジネス サービスまたはプロキシ サービスにメッセージを渡し、サービスから応答を受信します。転送レベルでは、メッセージ データは入力または出力ストリームの形式の生のバイトです。発信転送レイヤでは、HTTP(S)、JMS、FTP、ファイル、および電子メールを含む転送プロトコルの互換性をサポートします。データの処理には関係しませんが、エンドポイント URI や転送ヘッダなどメッセージのメタデータを処理します。
プロキシ サービスは、Oracle Service Bus のアーキテクチャで基礎となる概念です。プロキシ サービスは、サービス コンシューマが管理対象のバックエンド サービスに接続するために使用するインタフェースです。プロキシ サービスは、Service Bus がローカルに実装する仲介 Web サービスの定義になっています。Oracle Service Bus Console では、Web Services Description Languages (WSDL) についてのインタフェースと、使用する転送の種類を定義することで、プロキシ サービスをコンフィグレーションできます。メッセージの処理ロジックは、プロキシ サービスの定義時に「メッセージ フローの定義」で指定されます。プロキシ サービスの詳細については、「プロキシ サービス」を参照してください。
プロキシ サービスのコンテキストは、要求フローと応答フローとで共有される一連の XML 変数です。コンテキストに新しい変数を動的に追加したり、または削除できます。あらかじめ定義されたコンテキスト変数には、メッセージに関する情報、転送ヘッダ、セキュリティ プリンシパル、現在のプロキシ サービスのメタデータ、およびプロキシ サービスから呼び出されるプライマリ ルーティング サービスとパブリッシュ サービスのメタデータが含まれます。
コンテキストは読み込まれて、XQuery 式による変更や、トランスフォーメーションや同位置更新アクションによる更新が行われることがあります。コンテキストの中核は、$header、$body、$attachments 変数で構成されます。これらのラッパー変数には、Simple Object Access Protocol (SOAP) ヘッダ要素、SOAP 本体要素、および Multipurpose Internet Mail Extensions (MIME) 添付がそれぞれ含まれます。コンテキストによって、すべてのメッセージが SOAP メッセージであり、非 SOAP メッセージがこのパラダイムにマップされるように見えます。
プロキシ サービスはメッセージを複数のビジネス サービスにルーティングできるため、プロキシ サービスは通信先のビジネス サービスとは独立したインタフェースでコンフィグレーションできます。汎用のプロキシ テンプレートを使用すると、コンテンツ ベースのルーティング ロジックに基づいてメッセージを適切なビジネス サービスに動的にルーティングするメッセージ フローの定義としてプロキシ サービスをコンフィグレーションできます。プロキシ サービスは、実行時の動的なプロトコルの切り替えを有効にすることで、メッセージ データをエンドポイントのビジネス サービスに必要となる適切なプロトコル形式にマップすることもできます。
プロキシ テンプレートの詳細については、『概念とアーキテクチャ ガイド』の「サービス構成」を参照してください。
プロキシ サービスの実装は、「メッセージ フローの定義」によって指定されます。メッセージ フローの定義は、プロキシ サービスを通過する要求メッセージと応答メッセージの流れ (フロー) を定義します。メッセージ フローには、次の 4 つの構成要素があります。
メッセージ フロー要素を任意で組み合わせて、「開始ノード」をルート (root) 位置に必ず (1 つだけ) 配置し、ルート (route) ノードを持つツリー構造を形成します。ブランチの最後のノード (リーフ ノード) は、ルート ノードまたはエコー ノードになります。
要求メッセージは開始ノードから始まり、要求パイプラインのアクションを実行しながらリーフ ノードまでの経路を辿ります。リーフがルート ノードの場合、応答が生成されます。一方向のサービスの場合は空の応答になることがあります。リーフがエコー ノードの場合、要求そのものが応答として扱われます。応答では、ブランチ ノードのアクションをスキップしながらツリーの経路を逆に辿ります。ただし、応答パイプラインのアクションは実行されます。
インタフェースまたはオペレーションが要求/応答であれば、最後にツリーの一番上から応答が送信されます。それ以外の場合、応答は破棄されます。メッセージ フローの定義の詳細については、『Oracle Service Bus ユーザーズ ガイド』の「Oracle Service Bus でのメッセージ フローの作成」を参照してください。
コンテキスト変数に影響する一連のトランスフォーメーションは、選択したエンドポイントへのメッセージの送信前、または応答の受信後に定義できます。XQuery または XSLT トランスフォーメーションの代わりに Web サービス コールアウトを使用して、コンテキスト変数を設定できます。Oracle Service Bus トランスフォーメーション マップをコンフィグレーションする方法については、「XQuery Mapper を使用したデータの変換」を参照してください。
WS-Security の処理も認可と同様に、WS-Policy を使用するビジネス サービスの呼び出し時に開始ノードで透過的に実行されます。Oracle Service Bus のセキュリティのコンフィグレーション方法については、Oracle Service Bus の『セキュリティガイド』を参照してください。
ESB、メッセージ ブローカリング、および操作サービス管理の概念を 1 つの製品に融合することにより、Oracle Service Bus はメッセージとサービスの管理と統合をサービス ネットワーク全体で可能にしています。その中核となる機能は次のカテゴリに分類されます。
異なる環境をサポートするために、Oracle Service Bus では複数メッセージング パラダイムを採用しています。次の種類の通信がサポートされています。
パフォーマンスの高いメッセージ ブローカは、Oracle Service Bus の中核となるコンポーネントです。メッセージとデータ トランスフォーメーションのコンテンツ ベースのルーティングを可能にします。Oracle Service Bus のメッセージ ブローカリング機能には、次の操作機能が実装されています。
サービス エンドポイントとの通信に関連するすべてのルーティング ロジックは、コンフィグレーションされたプロキシ経由で処理されます。これにより、サービス コンシューマがバックエンド サービスとの通信でその複雑性を認識する必要がなくなります。ルーティング、トランスフォーメーション、セキュリティ、および転送の詳細をサービス コンシューマおよびプロバイダから分離して、これらをコンフィグレーション可能なプロキシ サービスに置くことで、サービスの統合がより柔軟に行えます。
Oracle Service Bus では、動的なコンテンツ ベースのメッセージ ルーティングと実行時のプロトコルの選択がサポートされています。これらの機能は、エンドポイントのビジネス サービスとは独立したプロキシ サービスのインタフェースのコンフィグレーションを可能にすることにより実現しています。汎用のプロキシ テンプレートを使用することにより、メッセージのコンテンツに基づいてメッセージを動的に適切なビジネス サービスにルーティングするルーティング ロジックを持つメッセージ フローの定義としてプロキシ サービスをコンフィグレーションできます。
Oracle Service Bus ではメッセージのトランスフォーメーションまたは処理において、次の機能がサポートされています。
Oracle Service Bus には、複雑な動的ルーティング処理を行うため、またはメッセージへの情報の追加を実行するために、より洗練されたメッセージ フローを実現して高い柔軟性を提供するサービス コールアウト アクションが用意されています。サービス コールアウト アクションはメッセージ フローのルーティング ステージ内で使用され、メッセージについての何らかのアクションを実行するために送り先のサービスを呼び出します。サービス コールアウト機能では、RPC エンコーディングや URL 置換などの機能をサポートし、Java コールアウトと POJO を使用して Oracle Service Bus の機能を拡張します。サービス コールアウトの詳細については、Oracle Service Bus の『ユーザーズ ガイド』の「サービス コールアウトの作成」を参照してください。
Oracle Service Bus では、Oracle XQuery エンジンの新しい XQuery 関数を使用したデータベース検索関数が用意されています。この関数を使用して、メッセージへの情報の追加、ルーティングの決定、プロキシ サービスの動作のカスタマイズを行うことができます。プロキシ サービスからデータベースへの読み込みアクセスを行うために、カスタム EJB またはカスタム Java コードを作成したり、Oracle Data Service Integrator などの独立したデータベース製品を使用する必要はありません。
これは execute-sql() 関数を使用して実装されており、データベースへの JDBC 呼び出しを実行することで、データベース読み込みを簡単に実行できます。詳細については、Oracle Service Bus の『ユーザーズ ガイド』の「Oracle Service Bus でのメッセージ フローの作成」を参照してください。
Oracle Service Bus には、ネイティブ転送を使用して Oracle Data Service Integrator データでサービスを呼び出す、一方向または双方向の通信に最適化された転送が用意されています。これにより、WebLogic Workshop および Java Web Services (JWS) を使用して Web サービスとしてエクスポーズするよりもデータ サービスへのアクセスが効率的かつ柔軟になり、セキュリティや ID の伝播もサポートされます。DSP 転送の詳細については、「Oracle Data Service Integrator と Oracle Service Bus の互換性一覧」を参照してください。
Oracle Service Bus および Workshop for WebLogic をインストールすると、Eclipse 3.1 と Format Builder 用の Oracle XQuery Mapper プラグイン (データ トランスフォーメーション ツール) がインストールされます。Eclipse 3.1 および Format Builder は、Windows プラットフォームでのみサポートされています。
SOAP、HTTP、JMS、SMTP/POP/IMAP、FTP、SSL、XML、XML スキーマ、WSDL、WSRP、WS-Security などのメッセージング標準への準拠のサポートに関する情報など、Oracle Service Bus の相互運用性の詳細については、「Oracle Service Bus 製品サポート情報」を参照してください。
Oracle Service Bus のビジネス サービスとプロキシ サービスは、EJB 転送を使用するように設計できます。EJB 転送は、Oracle Service Bus コンフィグレーション、管理、モニタ、およびテスト コンソールと完全に統合されています。EJB 転送を使用して構築されたビジネス サービスは、パブリッシュ、サービス コールアウト、およびサービスの呼び出しに使用できます。
EJB は、ツールを使用したり、EJB をホストするアプリケーション サーバのレガシー コードを変更したりすることなく、Web サービスとしてエクスポーズできます。EJB 転送には以下の機能があります。
Oracle Service Bus では、通信の整合性とプライバシを保証し、認可されたユーザだけが Oracle Service Bus ドメインのリソースにアクセスできるようにするために、オープンな業界標準をサポートしています。また、セキュリティ サービスの構成要素として、基になっている WebLogic セキュリティ フレームワークを使用します。WebLogic セキュリティ フレームワークでは、ドメインを保護するための作業が認証、認可、資格マッピング、監査などの複数のコンポーネント (プロバイダ) に分かれています。
Oracle Service Bus には、次のセキュリティ機能が用意されています。
Oracle Service Bus のセキュリティ モデルには次のものが含まれます。
Oracle Service Bus セキュリティ モデルの上記の機能の詳細については、「Oracle Service Bus のセキュリティ」を参照してください。
Oracle Service Bus でサポートされる標準については、Oracle Service Bus の『セキュリティ ガイド』の「サポートされる標準とセキュリティ プロバイダ」を参照してください。
Oracle Service Bus Console の Change Center は、サービス バス内でコンフィグレーションの変更を行う場合の基本となります。Change Center には、変更が行われている最中に現在のコンフィグレーションをロックするというユニークな機能があり、コンソールでコンフィグレーションの変更が行われている間でも、サービス バスはサービスに対する要求の受信と処理を継続できます。
変更中のコンフィグレーションが「アクティブ化」されるまで、現在のシステムのコンフィグレーションは影響を受けません。変更がアクティブ化されると、サービス バスでは新しいサービスとリソースのコンフィグレーションを使用します。このようにして、進行中の変更はサービスに影響を与えることなく実行することができます。
Change Center の詳細については、『Oracle Service Bus Console の使い方』の「Change Center の使用」を参照してください。
Oracle Service Bus に組み込まれているテスト コンソールは、メッセージ フローで使用されるリソースおよびインライン XQuery 式の検証を行うブラウザ ベースのテスト環境です。これは、Oracle Service Bus Console の拡張機能です。テスト コンソールを使用すると、テスト オブジェクトのコンフィグレーション (プロキシ サービス、ビジネス サービス、XQuery、XSLT、MFL リソース)、テストの実行、テスト結果の表示が行えます。サービスのテスト時には、指定されたトレース ポイントでメッセージの状態を調べるために、メッセージ フローのトレースができます。
設計時テストを行うことで、コンフィグレーションをプロダクション環境にデプロイする前に設計上の問題を割り出すことができます。テスト コンソールでは、システムの特定部分を切り分けてテストしたり、システムを 1 つの単位としてテストしたりできます。テスト コンソールは Oracle Service Bus Console の次の各種の部分から呼び出すことができます。
詳細については、Oracle Service Bus の『ユーザーズ ガイド』の「テスト コンソールの使用」を参照してください。
Oracle Service Bus には次のリソース管理機能が用意されています。
Oracle Service Bus には、プログラム インタフェースを介してサービス定義、WSDL、スキーマ、XQuery、およびその他の設計時のリソースをカスタマイズするための多くの API が提供されています。サポートされている API を使用すると、リソース、フォルダ、およびプロジェクトの移動、名前変更、クローン作成、または削除に加え、リソースが含まれている ZIP ファイルをロードできます。詳細については、Oracle Service Bus の『ユーザーズ ガイド』の「Oracle Service Bus API」を参照してください。
Oracle Service Bus で開発されたプロキシ サービスは、UDDI レジストリにパブリッシュできます。Oracle Service Bus は、Oracle Service Registry を含めた UDDI 3.0 準拠の任意のレジストリに対応しています。
Oracle Service Bus のサービス定義は、UDDI のサービス定義と (双方向で) 同期できます。Oracle Service Bus でサービスを作成または変更した後、サービスを UDDI に自動的にパブリッシュできます。また、UDDI からビジネス サービスの定義をインポートできます。
Oracle Service Bus のビジネス サービスも、元のサービスが UDDI で変更されると自動的に (作業する必要なしに) 更新されます。または、UDDI レジストリ内のサービスが変更されたときは同期するかどうかの承認をユーザに求めるように、Oracle Service Bus Console をコンフィグレーションすることもできます。UDDI レジストリの詳細については、Oracle Service Bus の『ユーザーズ ガイド』の「UDDI」および「Oracle Service Registry」のドキュメントを参照してください。
Oracle Service Bus では、次のエラー処理機能をサポートしています。
Oracle Service Bus では、サービスの監査とモニタで次の機能が使用できます。
Oracle Service Bus Console にはクラスタ全体のサービスの状態と統計が表示されます。ビジネス サービスと Oracle Service Bus プロキシ サービスの両方で、応答回数、メッセージ数、エラー数がモニタされます。
メトリックの取得を行うためのポーリング インタフェースとして JMX モニタリング API が提供されます。この API により、管理パートナの統合が可能になり、独自のモニタリング コンソールを使用しているユーザも、パフォーマンス解析のためにメトリックを表示できるようになります。
Oracle Service Bus Console ではオペレータ (IntegrationOperator) ロールのユーザによるタスクの実行をサポートしています。これにより、操作関連の機能や設定が提供され、ユーザは、新しいスマート検索機能を使ってリソースを簡単に検索できます。また、SLA アラート、パイプライン アラート、ログ、レポートをモニタしたり、トレースやサービスを有効および無効にすることもできます。
メトリックの通知がコンソール上の場合と JMX モニタリング API を使用した場合とで区別されるようになったため、SLA アラートとパイプライン アラートとの識別が容易になりました。サービス レベル フラグとグローバル フラグにより、アラート (SLA とパイプライン)、レポート、ロギングの制御が支援されます。オペレータには、操作設定の編集、新しい SLA アラート ルールの作成、およびアラート送り先リソースの作成と編集を行う権限があります。
コンソール操作タスクの詳細については、『Oracle Service Bus オペレーション ガイド』を参照してください。
Oracle Service Bus では、サービスの新しいバージョンのデプロイを可能にし、WSDL やスキーマなどのメッセージ リソースの複数のバージョンを使用できる機能が提供されています。各バージョンに、WSDL、メッセージ スキーマ、ヘッダ、およびセキュリティ パラメータへの変更を含めることができます。
Oracle Service Bus では、モニタしている統計値はローカルで収集され、一元的に集約されます。集約されたデータに対して SLA ルールが実行され、有効または無効にできるサービスに従って、システムによってアラートが生成されます。管理者は次のプロキシ サービス属性にサービス レベル アグリーメント (SLA) を設定できます。
Oracle Service Bus は、多数の分散サービス エンドポイントを集中的に管理して制御するように設計されています。Oracle Service Bus は WebLogic Server バージョン 9.0 以上で動作し、次のコンフィグレーションにデプロイできます。
Oracle Service Bus を使用することで、自律的な ESB インスタンスを企業全体にコンフィグレーションすることができます。これらのインスタンスは、サービスやトランスフォーメーションなどの、コンフィグレーション アーティファクトの独自のセットを持っています。通常、このようなデプロイメントでは、組織内のさまざまな IT 部門にマップします。異なる部門間の通信は、多くの場合ファイアウォールを介して互いにやり取りする、ESB の連携ネットワークを介して行われます。Oracle Service Bus のデプロイメントの詳細については、『Oracle Service Bus デプロイメント ガイド』を参照してください。
Oracle Service Bus では多数の分散サービス エンドポイントを管理および調整できるため、企業内の集中管理が可能になります。さらに、基になる WebLogic Server をクラスタ化することで異種の Oracle Service Bus ハブを水平方向に拡大し、分散 Oracle Service Bus ネットワークを作成できます。
クラスタは、メッセージを処理する一連のクラスタ化された管理対象サーバで構成されます。1 つのドメインに含まれる Oracle Service Bus をデプロイしたクラスタは 1 つに限られます。このクラスタは、Oracle Service Bus 以外にも他のアプリケーションをホストできます。管理サーバはクラスタ ドメインごとに 1 つだけあります。クラスタ化の詳細については、『Oracle Service Bus のデプロイメント ガイド』にある「Oracle Service Bus クラスタについて」を参照してください。
この場合、Oracle Service Bus の中央のデプロイメントがガバナンスと調整を処理し、ネットワーク内のすべての ESB は、中央の ESB を介して通信します。管理対象サーバにコンフィグレーションとメタデータを自動的に伝播してローカルでの取得時間を節約し、モニタ用のメトリックをすべての管理対象サーバから自動的に収集して、Oracle Service Bus Console で集約して表示します。
次の図は、基本的な Oracle Service Bus クラスタ トポロジでのメッセージ データ フローを示します。
Oracle Service Bus は、JMS ストア アンド フォワードを使用して、連携ネットワーク間の信頼性の高い、保証されたメッセージングを可能にします。また、動的ルーティング機能も、このネットワークのコンフィグレーションを簡略化します。メッセージングの負荷をクラスタ内のサーバ間で均一に分散することで、システムのボトルネックを取り除くことができます。
Oracle Service Bus では、制御された環境でのリソースおよびサービスのコンフィグレーションにより、エンタープライズ システムの変更管理のベスト プラクティスをサポートします。システムのコンフィグレーションをテスト用に別のステージング ドメインにエクスポートして、プロモーションの最終準備を行ってから、プロダクション ドメインにエクスポートできます。Java プログラムや Java スクリプトを使って、アプリケーションのデプロイメントを自動化したり、コンフィグレーションをステージング環境からプロダクション環境に移行したりすることができます。
Oracle Service Bus Console では、多数のデプロイメント カスタマイズ オプションを選択することができます。さまざまな環境変数を使用して、環境を移行する際の設定を保持または調整することが可能です。詳細については、『Oracle Service Bus Console の使い方』の「カスタマイズ」にある「環境値の検索と置換」および「カスタマイズ ファイルの作成」を参照してください。
大規模な開発では、リソースの開発、テスト、ステージング、およびプロダクション システムへのデプロイを行う機能が重要です。Oracle Service Bus Console では、Oracle Service Bus リソース コンフィグレーションをメタデータとして保存し、他の Oracle Service Bus ドメインへのインポート用に JAR ファイルとしてエクスポートできます。この機能により、Oracle Service Bus リソース コンフィグレーションの環境を、ステージング、テスト、プロダクションという順序に従って移行していくことができ、各種のデプロイメント シナリオを達成するために必要となる専門知識、時間、リソースを最小限に抑えることができます。
リソースのエクスポートとインポートに加えて、プロジェクト全体のエクスポートとインポートも可能です。既存のソース コード コントロール システムの機能とコンフィグレーション JAR ファイルを組み合わせると、Oracle Service Bus コンフィグレーションのバージョン管理および変更管理を行うことができます。
エクスポート機能では、JAR ファイルを使用して、既存のコンフィグレーションを他の Oracle Service Bus ドメインにエクスポートできます。この機能では、Oracle Service Bus のソース ドメインにデプロイメントされたリソースのすべて、またはサブセットをエクスポートすることで、システム コンフィグレーションを Oracle Service Bus のあるインスタンスから別のインスタンスに伝播できます。エクスポート可能なデータに制限はありません。1 つまたは複数のプロジェクト、または 1 つまたは複数のプロジェクトから選択したリソースをエクスポートできます。
Oracle Service Bus Console では、依存関係の追跡機能により、特定のリソースとそのリソースが依存している他のすべてのリソースをエクスポートすることもできます。コンフィグレーションをエクスポートするには、セッションの外部で作業する必要があります。アクティブ化されている (ランタイムにデプロイされている) コンフィグレーションのみがエクスポート可能です。
操作値には、グローバル操作設定と、プロキシ サービスおよびビジネス サービス用の操作値の 2 種類があります。グローバル操作設定はシステム プロジェクト フォルダにあるリソースで、他のすべてのリソースと同様にエクスポートできます。インポートしているドメインの操作設定がインポート中に上書きされないように保持することが可能です。これは [操作値を保持] を指定することで実現されます。[操作値を保持] が指定されていない場合は、インポートする JAR ファイルの値がドメインに設定されます。
インポート機能では、リソース コンフィグレーションを別の Oracle Service Bus ドメインのセッションにインポートできます。このインポート機能を使用するには、コンフィグレーション JAR ファイルがインポートされるセッションで作業を行う必要があります。多数のコンフィグレーションの更新と複数の JAR ファイルのインポートは 1 つのセッション内で許可されます。また、エクスポートされたデータのサブセットのみをインポートすることもできます。
Oracle Service Bus には、Oracle Service Bus Console の Change Center を使用して、インポートするドメインの要件を満たすように環境に固有の再コンフィグレーションを行う機能があります。このカスタマイズ機能を使用して、インポートされたリソースはアクティブ化する前に新しいドメインに合わせて調整できます。
インポート機能と検索および置換機能をと同時に使用することで、リソースに対する環境に固有の属性のグローバルな変更がサポートされます。これは、同様の多くの環境値を変更するときに便利です。この機能による置換は、複雑なデプロイメント シナリオでコンフィグレーションを慎重に調整する必要がある場合には適しません。詳細については、「Best Practices for Deploying AquaLogic Service Bus Resources」を参照してください。
Oracle Service Bus Console を使用したコンフィグレーション メタデータをエクスポートおよびインポートする方法については、『Oracle Service Bus Console の使い方』の「
カスタマイズ」を参照してください。Oracle Service Bus Console の Change Center を使用して、新しい環境用にコンフィグレーションを変更する方法については、『Oracle Service Bus Console の使い方』の「Change Center の使用」を参照してください。
Oracle Service Bus のコンフィグレーションとデプロイメントは Oracle Service Bus Console を使用してすべて実行することができますが、WebLogic Server Scripting Tool (WLST) を使用するとデプロイメント タスクを自動化できます。WLST の詳細については、『WebLogic Scripting Tool』の「WLST コマンドおよび変数リファレンス」を参照してください。
|
