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

11g リリース1 (11.1.1.6.2)

B61432-05(原本部品番号:E15022-06)

目次

図一覧

表一覧

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

はじめに

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

- 表記規則

このガイドでのリリース11.1.1.6.xの新機能

1 はじめに

- 1.1 デプロイメントの目標

- 1.2 Oracle Service Busデプロイメント・トポロジ

- 1.2.1 Oracle Service Busデプロイメント・トポロジとOracle Service Busドメイン拡張テンプレート

- 1.3 主要なデプロイメント・タスク

- 1.4 Oracle Service Busのデプロイメントにおける役割

- 1.4.1 デプロイメント・スペシャリスト

- 1.4.2 Oracle WebLogic Server管理者

- 1.4.3 データベース管理者

- 1.5 主要なデプロイメントのリソース

- 1.5.1 Oracle WebLogic Serverリソース

- 1.5.1.1 クラスタリング

- 1.5.1.2 Java Message Service

- 1.5.1.3 EJBプールとキャッシング

- 1.5.1.4 JDBC接続プール

- 1.5.1.5 実行スレッド・プール

- 1.5.1.6 J2EEコネクタ・アーキテクチャ

- 1.5.2 Oracle Service Busの構成リソース

- 1.5.2.1 ビジネス・サービス

- 1.5.2.2 プロキシ・サービス

- 1.5.2.3 WSDL

- 1.5.2.4 スキーマ

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

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

- 1.5.2.7 WS-Policy

- 1.5.2.8 XQuery変換とXSLT変換

- 1.5.2.9 MFL

- 1.5.2.10 JAR

- 1.5.2.11 アラート宛先

- 1.5.2.12 UDDIレジストリ

- 1.5.2.13 JNDIプロバイダ

- 1.5.2.14 SMTPサーバー

- 1.5.3 リレーショナル・データベース管理システムのリソース

- 1.5.4 ハードウェア、オペレーティング・システム、およびネットワーク・リソース

2 非クラスタ・デプロイメントの構成

- 2.1 手順1. JMSレポート・プロバイダ・データ・ストア用データベースの構成

- 2.2 手順2. Oracle Service Busドメインの準備

- 2.2.1 Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成

- 2.2.2 JMSリソースの構成

- 2.3 手順3. Oracle Service Busセキュリティの構成

- 2.4 手順4. Oracle Service Bus構成のデプロイ

- 2.5 手順5. 本番環境の変更にあわせたドメインの更新

- 2.5.1 ビジネス・サービスの変更

- 2.5.2 新しいバージョンのプロキシ・サービスのインストール

- 2.5.3 構成のオンライン更新

- 2.5.3.1 構成のオンライン更新のベスト・プラクティス

3 Oracle Service Busクラスタについて

- 3.1 Oracle Service Busクラスタについて

- 3.2 クラスタ・デプロイメントの設計

- 3.2.1 Oracle Service Busドメインについて

- 3.2.1.1 ドメインの作成

- 3.2.1.2 クラスタ・サーバー

- 3.2.2 Oracle Service Busデプロイメントのリソース

- 3.2.2.1 シングルトン・リソース

- 3.2.2.2 クラスタのモニター・リソースとアラート・リソース

- 3.2.2.3 クラスタ構成の変更およびデプロイメント・リクエスト

- 3.3 Oracle Service Busクラスタのロード・バランシング

- 3.3.1 クラスタにおけるHTTP機能のロード・バランシング

- 3.3.2 クラスタにおけるJMS機能のロード・バランシング

- 3.4 Oracle Service Busクラスタの高可用性

- 3.4.1 Oracle Service Bus用の高可用性を備えたJMS

- 3.5 構成のデプロイ

4 クラスタ・デプロイメントの構成

- 4.1 手順1. 構成の前提条件への準拠

- 4.2 手順2. Oracle Service Busドメインの準備

- 4.2.1 Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成

- 4.2.1.1 プロキシ・サーバーまたはファイアウォール情報のドメイン構成への追加

- 4.2.2 JMSリソースの構成

- 4.3 手順3. Oracle Service Busセキュリティの構成

- 4.4 手順4. 管理対象サーバーの起動、停止、モニター

- 4.4.1 管理対象サーバーの起動と停止

- 4.4.2 サーバーのモニター

- 4.5 手順5. Oracle Service Bus構成のデプロイ

- 4.6 手順6. 本番環境の変更にあわせたドメインの更新

- 4.6.1 管理対象サーバーの追加

- 4.6.1.1 拡張したクラスタのためのビジネス・サービス構成の更新

- 4.6.1.2 拡張したクラスタのためのプロキシ・サービス構成の更新

- 4.6.2 管理対象サーバーの削除

- 4.6.3 クラスタのビジネス・サービスの変更

- 4.6.4 クラスタへの新しいバージョンのプロキシ・サービスのインストール

5 Oracle Service Busの高可用性について

- 5.1 Oracle Service Busの高可用性について

- 5.1.1 推奨ハードウェアおよびソフトウェア

- 5.1.1.1 JMSファイル・ストアについて

- 5.1.2 サーバー障害時の処理

- 5.1.2.1 ソフトウェア・フォルト

- 5.1.2.2 ハードウェア・フォルト

- 5.1.2.3 サーバーの移行

- 5.1.2.4 メッセージ・レポーティング・パージャー

- 5.2 Oracle Service Busの障害とリカバリ

- 5.2.1 透過的なサーバー再接続

- 5.2.2 EISインスタンスのフェイルオーバー

- 5.3 ポーラー・ベースのトランスポートの高可用性

- 5.3.1 JMSキュー

- 5.3.2 クラスタの高可用性

- 5.3.2.1 ロード・バランシング

6 デプロイメントのベスト・プラクティスおよびその他のトピック

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

- 6.1.1 開発システムとQAシステム

- 6.1.2 ステージ・システムと本番システム

- 6.1.3 共有プロジェクト

- 6.2 デプロイメント・タイプ

- 6.3 デプロイメントの役割

- 6.4 カスタマイズ・ファイル

- 6.4.1 環境値の置換

- 6.5 リソースのエクスポート

- 6.5.1 エクスポート時のリソースのカスタマイズ

- 6.6 リソースのインポート

- 6.6.1 インポート時のリソースのカスタマイズ

- 6.6.2 操作値のインポート

- 6.6.3 アクセス制御ポリシーのインポート

- 6.6.4 Oracle WebLogic Serverアーティファクトのデプロイ

- 6.7 グローバル・リソースの移行

- 6.8 基本的なデプロイメントのベスト・プラクティスの概要

- 6.9 UDDI

- 6.9.1 UDDIデプロイメント・トポロジ

- 6.9.1.1 開発専用レジストリ

- 6.9.1.2 本番専用レジストリ

- 6.9.1.3 開発および本番レジストリ

- 6.9.1.4 個別ドメイン別レジストリ

- 6.9.2 UDDIデプロイメントのベスト・プラクティスの概要

- 6.9.3 複数のシステム間でのリソースのインポートとエクスポート

- 6.9.3.1 開発専用レジストリ

- 6.9.3.2 本番専用レジストリおよび開発および本番レジストリ

- 6.10 仮想環境へのデプロイ

A デプロイメントAPIの使用

- A.1 プログラムとスクリプトを使用したセッションの管理

- A.1.1 セッションの作成、アクティブ化、破棄、検索

- A.1.1.1 例

- A.2 プログラムとスクリプトを使用した構成タスクの管理

- A.2.1 構成のインポート、エクスポートおよび問合せ

- A.2.2 環境固有の情報の更新

- A.2.2.1 例

- A.2.3 関連トピック

B Oracle Service Busデプロイメントのリソース

- B.1 Oracle Service Busドメイン拡張テンプレート

- B.1.1 生成されるドメイン出力

C 静的IPアドレスを使用した仮想環境の構成

- C.1 手順1: ディレクトリ構造の作成

- C.2 手順2: プロパティ・ファイルの作成

- C.3 手順3: 構成ファイルの作成

図一覧

- 2-1 オンライン更新のサンプル・シナリオ

- 5-1 クラスタの概略図

- 6-1 複雑なトポロジ

- 6-2 複雑なトポロジ - UDDI

表一覧

- 1-1 EJB調整パラメータ

- 2-1 サンプル・システムの最初の構成と更新された構成

- 3-1 Oracle Service Busシングルトン・リソース

- 5-1 Oracle Service Busに対して構成されるJMSキュー

- A-1 セッション管理メソッド

- B-1 Oracle Service Bus拡張テンプレート適用後のドメイン

Oracle® Fusion Middleware

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

11g リリース1 (11.1.1.6.2)

B61432-05(原本部品番号:E15022-06)

2012年3月

このドキュメントでは、高可用性(HA)を必要とする開発者ドメイン、クラスタ・ドメインおよび管理専用ドメインについて、Oracle Service Bus(OSB)のデプロイメント・トポロジおよびベスト・プラクティスを説明します。

Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド, 11gリリース1(11.1.1.6.2)

B61432-05

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

原本著者:  Carol Thom、旧版の著者

原本協力著者:  Floyd Jones

原本協力者:

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

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

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

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

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

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

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

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

はじめに

ここでは、このガイド『Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド』のドキュメントのアクセシビリティ機能および規則について説明します。

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

オラクル社のアクセシビリティへの取組みの詳細は、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、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドでのリリース11.1.1.6.xの新機能

リリース11.1.1.6.xについて、このガイドの一部が更新されています。次の表には、追加または変更された項が示されています。11.1.1.6.xの最初のリリースで使用できない機能があった場合は、最後の列に更新が含まれるドキュメントのリリースが示されています。

既知の問題のリスト(リリース・ノート)については、http://www.oracle.com/technetwork/middleware/docs/soa-aiafp-knownissuesindex-364630.htmlの「Known Issues for Oracle SOA Products and Oracle AIA Foundation Pack」を参照してください。

項

変更

11.1.1.6.0

11.1.1.6.1

第6章「デプロイメントのベスト・プラクティスおよびその他のトピック」

6.10項「仮想環境へのデプロイ」

Oracle Virtual Assembly Builderを使用したOracle VMでのOracle Service Busの実装方法についての追加

X

1 概要

この章では、本番環境にOracle Service Bus構成をデプロイする方法について説明します。

次の項では、組織でOracle Service Busをデプロイする場合の主要な概念と操作について説明します。

- 1.1項「デプロイメントの目標」

- 1.2項「Oracle Service Busデプロイメント・トポロジ」

- 1.3項「主要なデプロイメント・タスク」

- 1.4項「Oracle Service Busのデプロイメントにおける役割」

- 1.5項「主要なデプロイメントのリソース」

このドキュメントでは、主にOracle Service Busソフトウェアのライフサイクルのデプロイメント段階について説明します。Oracle Service Busの概要については、『Oracle Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ』を参照してください。

1.1 デプロイメントの目標

Oracle Service Busでは、インテリジェントなメッセージ・ブローカリングとサービスのモニターおよび管理を統合しているため、1つのソフトウェア製品でサービス指向アーキテクチャ(SOA)の実装とデプロイを行うことができます。Oracle Service Busの構成をデプロイするときは、次の目標を考慮します。

- 高可用性: ハードウェアやネットワークの障害時のフェイルオーバーに備えて、デプロイメントには、十分な可用性とアクセシビリティが要求されます。

- パフォーマンス: デプロイメントでは、負荷のピーク時や閑散時に関係なく十分なパフォーマンスが必要になります。

- スケーラビリティ: デプロイメントでは、コード変更ではなく、ハードウェア・リソースの追加により、予期される負荷の増加に対処できなければなりません。

- セキュリティ: デプロイメントでは、権限のないアクセスやデータの改ざんからデータを確実に保護できなければなりません。

Oracle Service Bus構成では、常にこれらの目標を達成できます。

1.2 Oracle Service Busデプロイメント・トポロジ

トポロジという用語は、ドメイン内のサーバー、クラスタ、アプリケーション、製品の特定の構成、およびアプリケーションや製品がデプロイされる場所を指します。Oracle Service Busデプロイメント・トポロジという用語は、Oracle Service Bus製品がデプロイされるサーバー/クラスタを指します。

Oracle Service Busは、ドメイン内にOracle Service Bus以外のサーバー/クラスタが共存するトポロジなど、様々なデプロイメント・トポロジをサポートしています。次に、Oracle Service Busでサポートされているデプロイメント・トポロジを示します。

- 管理サーバーのみトポロジ - このトポロジでは、Oracle Service Busは管理サーバーにのみデプロイされます。

- 管理サーバーおよび管理対象サーバー・トポロジ - このトポロジでは、Oracle Service Busは管理サーバーと1つの非クラスタ(スタンドアロン)管理対象サーバーにデプロイされます。管理機能は管理サーバーにデプロイされ、ランタイム機能は管理対象サーバーにデプロイされます。

- クラスタ・トポロジ - このトポロジでは、Oracle Service Busは管理サーバーと1つのクラスタにデプロイされます。管理機能は管理サーバーにデプロイされ、ランタイム機能はクラスタにデプロイされます。ドメインでは1つのOracle Service Busクラスタのみ使用できます。

注意:

管理対象サーバーとクラスタ・トポロジを混在することはできません。どちらか一方を使用する必要があります。

Oracle Virtual Assembly Builderを使用してOracle Service Busを仮想環境にデプロイする場合、管理サーバーおよび管理対象サーバー・トポロジはサポートされません。

最初の2つのトポロジ、「管理サーバーのみ」と「管理サーバーおよび管理対象サーバー」は、非クラスタOracle Service Busトポロジと呼ばれることもあります。

Oracle Service Busデプロイメント・トポロジでは、Oracle Service Bus以外のサーバー/クラスタも共存できます。いずれかのOracle Service Busデプロイメント・トポロジを使用してドメインを作成し、必要な数のOracle Service Bus以外のスタンドアロン管理対象サーバーまたはクラスタを作成できます。これらのOracle Service Bus以外のサーバー/クラスタには、他のOracle製品やユーザー・アプリケーションを含めることができます。

Oracle Service Busを他のOracle製品とコロケートすることもできます(ただし、制限があります)。コロケートとは、2つの製品を同じサーバー/クラスタにデプロイすることです。現在、「管理サーバーおよび管理対象サーバー」トポロジを使用する場合のみ、Oracle Service BusをOracle SOA Suiteとコロケートできます。

1.2.1 Oracle Service Busデプロイメント・トポロジとOracle Service Busドメイン拡張テンプレート

Oracle Fusion Middleware構成ウィザードのユーザー・インタフェースまたはスクリプトを使用して、Oracle Service Busドメイン拡張テンプレートを適用することで、特定のOracle Service Busトポロジを作成できます。ドメイン拡張テンプレートを使用することにより、ほとんどのデプロイメント作業が自動化され、ドメイン作成が大幅に簡易化されます。

Oracle Service Busには2つのドメイン拡張テンプレートが用意されています。

- Oracle Service Bus - このテンプレートでは、すべてのOracle Service Busデプロイメント・トポロジを作成できます。

- Oracle Service Bus for developers - このテンプレートは、開発環境などで管理専用Oracle Service Busトポロジを作成するための便利な方法として提供されています。

Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成については(Oracle SOA Suiteとのコロケートを含め)、Oracle Fusion Middleware Oracle Service Busインストレーション・ガイドの「Oracle Service Bus 11gのインストールと構成」を参照してください。

1.3 主要なデプロイメント・タスク

Oracle Service Busをデプロイするときは、次の作業の一部または全部を完了する必要があります。

1. 1.1項「デプロイメントの目標」の説明に従って、Oracle Service Busデプロイメントの目標を定義します。

2. 第1章「Oracle Service Busデプロイメント・トポロジ」の説明に従って、デプロイメント・トポロジを作成します。

3. このガイドの説明に従って、Oracle Service Bus構成をデプロイします。

4. 『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のセキュリティに関する項の説明に従って、Oracle Service Busデプロイメントのセキュリティを設定します。

1.4 Oracle Service Busのデプロイメントにおける役割

統合型ソリューションを正しくデプロイするためには、デプロイメント・チームに、次の役割を果たすメンバーを加える必要があります。

- 1.4.1項「デプロイメント・スペシャリスト」

- 1.4.2項「Oracle WebLogic Server管理者」

- 1.4.3項「データベース管理者」

一人で複数の役割を兼任することもできます。デプロイメントのすべてのシナリオに全員が等しく関わることはありません。ただし、正しくデプロイするためには、各担当者の参加が必要です。

1.4.1 デプロイメント・スペシャリスト

デプロイメント・スペシャリストは、デプロイメント作業を調整します。デプロイメント・スペシャリストには、Oracle Service Bus製品の機能に精通していることが要求されます。デプロイメント・スペシャリストは、1つまたは複数のサーバーに様々なOracle Service Bus機能を構成してきた経験を基に、専門知識を活かして、ESBソリューションのデプロイメント・トポロジを設計します。デプロイメント・スペシャリストには、次の分野の経験が要求されます。

- リソース要件の解析

- デプロイメント・トポロジの設計

- プロジェクトの管理

1.4.2 Oracle WebLogic Server管理者

Oracle WebLogic Server管理者は、組織内のOracle WebLogic Serverデプロイメントに関する技術と操作について深い知識を持っている必要があります。次の領域の経験と専門知識が要求されます。

- ハードウェアとプラットフォームの知識(Hardware and platform knowledge)

- インストール、構成、モニター、セキュリティ、パフォーマンス・チューニング、トラブルシューティングなど、Oracle WebLogic Serverデプロイメントのすべての側面の管理

1.4.3 データベース管理者

データベース管理者は、組織内にデプロイされたデータベース・システムに関する技術と操作について深い知識を持っている必要があります。次の領域の経験と専門知識が要求されます。

- ハードウェアとプラットフォームの知識(Hardware and platform knowledge)

- インストール、構成、モニター、セキュリティ、パフォーマンス・チューニング、トラブルシューティングなど、リレーショナル・データベース(RDBMS)のすべての側面の管理

1.5 主要なデプロイメントのリソース

この項では、デプロイメントの段階で変更可能なリソースの概要について説明します。リソースという用語は、このドキュメントでは主に技術的な資産を指します。セキュリティについては例外的に、セキュリティ・ロールとセキュリティ・ポリシーを使用して無許可のアクセスから保護するOracle WebLogic Serverエンティティのことのみを指します。

デプロイメントの段階で変更可能な主なリソースには、次のものがあります。

- 1.5.1項「Oracle WebLogic Serverリソース」

- 1.5.2項「Oracle Service Busの構成リソース」

- 1.5.3項「リレーショナル・データベース管理システムのリソース」

- 1.5.4項「ハードウェア、オペレーティング・システムおよびネットワーク・リソース」

1.5.1 Oracle WebLogic Serverリソース

この項では、Oracle Service Busソリューションのデプロイメントに最も関係するOracle WebLogic Serverリソースの一般情報について説明します。これらのリソースはOracle WebLogic Server管理コンソールで直接構成することも、J2EEとWebLogicのリソース記述子を通じて構成することもできます。

Oracle WebLogic Serverには、多くの構成オプションと調整可能な設定があり、サポートされている任意の環境でOracle Service Busソリューションをデプロイするために使うことができます。Oracle Service Busのデプロイメントに最も関係する、構成可能なOracle WebLogic Server機能には、次のものがあります。

- 1.5.1.1項「クラスタリング」

- 1.5.1.2項「Java Message Service」

- 1.5.1.3項「EJBプールとキャッシング」

- 1.5.1.4項「JDBC接続プール」

- 1.5.1.5項「実行スレッド・プール」

- 1.5.1.6項「J2EEコネクタ・アーキテクチャ」

1.5.1.1 クラスタリング

クラスタは、単体ユニットとして管理可能なサーバーのグループです。クラスタリングにより、単一サーバーよりもスケーラビリティの高いデプロイメント・プラットフォームを構築できます。作業負荷に対する許容量を増やすために、Oracle WebLogic Serverをクラスタで実行できます。クラスタリングの詳細は、第3章「Oracle Service Busクラスタについて」を参照してください。

1.5.1.2 Java Message Service

WebLogic Java Message Service (JMS)により、Javaアプリケーションでメッセージ・システムを共有し、メッセージを交換(作成、送信、受信)できます。WebLogic JMSは、http://java.sun.com/products/jms/docs.htmlにあるJava Message Service Specification version 1.0.2に準拠しています。

JMSサーバーはクラスタリングが可能です。また、接続ファクトリはOracle WebLogic Serverの複数のインスタンスにデプロイできます。WebLogic JMSの詳細は、次のトピックを参照してください。

- 『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』のWebLogic JMSについてに関する項。

- 『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のWebLogic JMSクラスタリングの構成およびJMS統計のモニターとメッセージの管理に関する項。

1.5.1.3 EJBプールとキャッシング

Oracle Service Busデプロイメントでは、EJBの数がシステムのスループットに影響します。システムのEJBの数は、EJBのタイプに応じて、EJBプールまたはEJBキャッシュを使用して調整できます。次の表に、EJBのタイプと関連する可変パラメータを示します。

表1-1 EJBの調整用パラメータ

EJBタイプ

調整可能なパラメータ名

調整可能なパラメータの説明

メッセージドリブンBean

max-beans-in-free-pool

キューから作業を取り出すリスナーの最大数

ステートレス・セッションBean

max-beans-in-free-pool

作業リクエストに対応できるbeanの最大数

ステートフル・セッションBeanとエンティティBean

max-beans-in-cache

一度にアクティブにできるbeanの数。設定が小さすぎると、CacheFullExceptionsになります。.設定が大きすぎると、メモリーを過度に消費します。

スループットの制御の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使い方に関する項を参照してください。

1.5.1.4 JDBC接続プール

JDBC (Java Database Connectivity)は、JavaアプリケーションからDBMSに格納されているデータにアクセスするために使用します。データベース接続を確立する際のオーバーヘッドを減らすために、WebLogic JDBCにはすぐに使用できる接続プールが用意されています。

JDBC接続プールは、DBMS接続の最適化に使用します。Oracle Service Bus JMSレポート・プロバイダを使用している場合、JDBC接続プールのサイズを構成することで、Oracle Service Busのパフォーマンスを調整できます。設定が小さすぎると、接続可能になるまでのOracle Service Busの待機時間が長くなる可能性があります。設定が大きすぎると、DBMSのパフォーマンスが低下する可能性があります。

WebLogic JDBC接続プールの詳細は、次を参照してください。

- 『Oracle Fusion Middleware Oracle WebLogic Server JDBCのプログラミング』の「JDBCアプリケーションのパフォーマンス・チューニング」にある接続プールによるパフォーマンスの向上に関する項。

- 『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』の「JDBCデータ・ソースの構成」にある接続プールの機能に関する説明。

1.5.1.5 実行スレッド・プール

実行スレッド・プールによって、Oracle WebLogic Serverで同時に実行可能なスレッド数を制御できます。設定が小さすぎると、処理が同時に行われなくなり、さらにデッドロックが発生する可能性があります。設定が大きすぎると、メモリーを過度に消費し、スラッシングが発生する可能性があります。

また、実行スレッドの数によって、受信ソケット・メッセージを読み込むスレッド数(ソケット・リーダー・スレッド)が決まります。デフォルトでは、この数は、実行スレッド数の1/3です。この数が小さすぎると、ソケットを読み込むスレッドが競合して、デッドロックが発生する可能性が高くなります。

実行スレッド・プールは、予想されるスレッドの合計数を実行できる程度に設定してください。ただし、システム内のコンテキストの過度の切替えによってパフォーマンスが低下してしまうほど高く設定しないでください。実行しているシステムをモニターし、様々な値を試して実行スレッド・プールに最適な値を決めてください。

注意:

ほとんどの本番アプリケーションでは、実行スレッド・カウントをデフォルト値より大きくする必要があります。一般的に使用されるスレッド・カウント値は50です。実際のスレッド・カウント値に合わせてJDBC接続プールを調整してください。

1.5.1.6 J2EEコネクタ・アーキテクチャ

WebLogic J2EEコネクタ・アーキテクチャ(JCA)により、J2EEプラットフォームを異機種のエンタープライズ情報システム(EIS)と統合できます。WebLogic JCAは、Sun Microsystems, IncのJ2EEコネクタ仕様、バージョン1.0に準拠しています。

WebLogic J2EE-CAについては、『Oracle Fusion Middleware Oracle WebLogic Serverリソース・アダプタのプログラミング』のJ2EEコネクタ・アーキテクチャに関する項を参照してください。

1.5.2 Oracle Service Busの構成リソース

Oracle Service Busの構成リソースには、構成を新しいドメインにデプロイするときに変更または調整可能な環境固有の設定があります。次の項では、構成のデプロイ後に再構成が必要なリソースについて説明します。

1.5.2.1 ビジネス・サービス

ビジネス・サービスは、メッセージの交換先となるエンタープライズ情報サービスのOracle Service Busでの定義です。本番環境のビジネス・サービスでは、ロード・バランシングと高可用性のため、複数のエンドポイント(URL)を指定できます。ビジネス・サービスにエンドポイントを追加する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のビジネス・サービスの構成の編集に関する項を参照してください。既存のエンドポイントの値を更新する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の環境値の検索と置換に関する項を参照してください。

1.5.2.2 プロキシ・サービス

プロキシ・サービスとは、Oracle Service BusによってOracle WebLogic Serverのローカルに実装される仲介WebサービスのOracle Service Busでの定義です。プロキシ・サービスを定義する大部分のメタデータは、新しい環境にデプロイする際に変更する必要はありませんが、次の情報の更新が必要になることがあります。

- プロキシ・サービスのメッセージ・フローでは、指定された宛先(ビジネス・サービス、他のプロキシ・サービスなど)にメッセージをルーティングします。新しい環境で、メッセージ・ルーティング定義の更新が必要になることがあります。

- ファイル、FTPおよび電子メール・メッセージのタイプを持つプロキシ・サービスの定義では、クラスタでのポーリング実行時コンポーネントのデプロイメント用に単一の管理対象サーバーを指定する必要があります。管理対象サーバーのリストは、Oracle Service Busクラスタ・ドメインに対してのみOracle Service Bus管理コンソールに表示されます。

- プロキシ・サービス定義に含まれるディレクトリ名は、新しい環境で更新が必要になることがあります。このリソースを使用環境にあわせて構成する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の環境値の検索と置換に関する項を参照してください。

- プロキシ・サービスの定義には、他のOracle Service Busリソースへの参照が含まれます。新しい環境で、参照の有効性を確認することが重要です。

- プロキシ・サービスURLのJMSキューおよびJMS接続ファクトリは、更新が必要になることがあります。

- 各プロキシ・サービスは、ディスパッチ・ポリシーでOracle WebLogic Serverワーク・マネージャのインスタンスに依存します。ワーク・マネージャのインスタンスを本番環境の要件にあわせて調整できます。
ワーク・マネージャの詳細は、次の説明を参照してください。

- 『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する説明

- 『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Busでのワーク・マネージャの使用に関する説明

プロキシ・サービスの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のプロキシ・サービス: 作成および管理に関する項を参照してください。

1.5.2.3 WSDL

Oracle Service BusではWSDL (Web Service Definition Language)を使用して、プロキシ・サービスとビジネス・サービスを記述します。WSDLはWebサービスの内容、場所、呼出し方法の記述に使用されます。

プロキシ・サービスとビジネス・サービスは既存のWSDLファイルに基づいて定義することができ、Oracle Service Bus管理コンソールでサービスの構成を完了できます。サービスの定義の基になるWSDLファイルは、Oracle Service Busのリソースとして格納されます。これらのリソースを新しい環境にデプロイする場合、リソースを更新する必要はほとんどありません。Oracle Service Busでは、WSDLファイル内のURLを実行時に使用しないためです。

注意:

Oracle Service Busでは、HTTPプロキシ・サービスごとに新しいWSDLファイルが作成されます。サービスのエンドポイントに?wsdlを追加すると、このWSDLファイルの内容を表示できます。たとえば、Oracle Service Bus Examples Serverを起動すると(「スタート」>「すべてのプログラム」>「Oracle Service Bus」>Examples >Examples Serverの起動)、loangateway2プロキシ・サービスのWSDLをhttp://localhost:7021/crejws_basic_ejb/loangateway2?wsdlで表示できます。

1.5.2.4 スキーマ

スキーマとは、XMLドキュメントの有効なコンテンツを定義するドキュメントです。スキーマはOracle Service Busで交換されるメッセージにXML情報を追加するときに使用されます。これらのリソースを新しい環境にデプロイする場合、更新の必要はほとんどありません。

1.5.2.5 サービス・アカウント

Oracle Service Busでは、サービスやサーバーに接続するときに、サービス・アカウントを使用して認証が行われます。このリソースを本番環境で適切に使用する方法については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のセキュリティに関する項を参照してください。

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

Oracle Service Busでは、サービス・キー・プロバイダを使用して、プロキシ・サービスに資格証明レベルの検証を提供します。次のセキュリティ・タイプを使用できます。

- SSLクライアント認証

- デジタル署名

- 暗号化

- Webサービス・セキュリティX509トークン

このリソースを使用環境にあわせて構成する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のサービス・キー・プロバイダに関する項を参照してください。

1.5.2.7 WS-Policy

Oracle Service Busでは、Webサービス・ポリシー(WS-Policy)を使用して、Webサービス・セキュリティ・ポリシーをプロキシ・サービスとビジネス・サービスに関連付けます。このリソースを本番環境にあわせて構成する方法については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のセキュリティに関する項を参照してください。

これらのリソースを新しい環境にデプロイする場合、更新の必要はほとんどありません。

1.5.2.8 XQuery変換とXSLT変換

トランスフォーメーション・マップは、2つのデータ型の間のマッピングを記述したものです。Oracle Service Busは、XQueryまたはeXtensible Stylesheet Language Transformation (XSLT)標準のどちらかを使用したデータ・マッピングに対応しています。これらのリソースを新しい環境にデプロイする場合、更新の必要はほとんどありません。

1.5.2.9 MFL

メッセージ・フォーマット言語(MFL)は、フォーマットされたバイナリ・データをXMLデータに変換するルールを定義するOracle独自の言語です。MFLドキュメントを新しい環境にデプロイする場合、更新の必要はほとんどありません。

1.5.2.10 JAR

JAR (Java ARchive)は、一連のJavaクラスを含むzipファイルです。プログラムを構成する、コンパイル済のJavaクラスと関連メタデータの格納に使用します。JARはJavaコード要素用の呼出し可能なプログラム・ライブラリとして機能します(それぞれの要素に対して個別にバインディングを要求するのではなく、単一のコンピレーション・リンクが複数要素へのアクセスを提供します)。JARを新しい環境にデプロイする場合、更新の必要はほとんどありません。

1.5.2.11 アラート宛先

アラート宛先リソースは、Oracle Service Busからのアラート通知を受信できる受信者のリストを取り込みます。一般的なシステム・モニター・コンテキストでは、Oracle Service Busにより生成されたアラートは、限られたユーザーのセットに対して非常に有用です。Oracle Service Busでは、指定されたコンテキストに応じて、それぞれのアラート宛先リソースに受信者のセットが含まれるよう設定できます。アラート宛先は、メッセージ・フローで構成されたアラート・アクション、およびSLAアラート・ルールで使用されます。アラート宛先には、1つまたは複数の宛先のタイプ(コンソール、レポート・データ・ストリーム、SNMPトラップ、電子メール、JMSキュー、JMSトピック)を含めることができます。電子メールおよびJMS宛先の場合は、宛先リソースに電子メール・アドレスまたはJMS URIのリストをそれぞれ含めることができます。アラート宛先を新しい環境にデプロイする場合、更新の必要はほとんどありません。

1.5.2.12 UDDIレジストリ

UDDIレジストリ・リソースは、Oracle Service Busで使用するUDDIレジストリの情報を格納するグローバル・リソースです。UDDIレジストリ・リソースを構成すると、対応するレジストリにOracleプロキシ・サービスをパブリッシュしたり、Oracleプロキシ・サービスで使用するビジネス・サービスをそこからインポートしたりできます。UDDIレジストリ・リソースを構成するには、アクティブ・セッションで作業する必要があります。UDDIレジストリ・リソースを新しい環境にデプロイする場合、更新または再構成を行う必要があります。デプロイメントの際のUDDIレジストリ・リソースの更新方法については、6.7項「グローバル・リソースの移行」を参照してください。

1.5.2.13 JNDIプロバイダ

JNDIプロバイダ・リソースは、Oracle Service Busで使用するJNDIプロバイダのURL(クラスタ・デプロイメントの場合はURLのリスト)を記述する、JNDIプロバイダの定義です。グローバル・リソースであり、Oracle Service Busドメインを持つプロジェクト間で再利用できます。JNDIプロバイダが保護されている場合、JNDIプロバイダ・リソースの記述には、アクセスに必要なユーザー名とパスワードも保持されます。JNDIプロバイダ・リソースを新しい環境にデプロイする場合、更新または再構成を行う必要があります。デプロイメントの際のJNDIプロバイダ・リソースの更新方法については、6.7項「グローバル・リソースの移行」を参照してください。

1.5.2.14 SMTPサーバー

SMTPサーバー・リソースは、Oracle Service Busで使用するSMTPサーバーのURLとポートを記述する、SMTPサーバーの定義です。グローバル・リソースであり、Oracle Service Busドメインを持つプロジェクト間で再利用できます。SMTPサーバーが保護されている場合、SMTPサーバー・リソースの記述には、アクセスに必要なユーザー名とパスワードも保持されます。SMTPサーバー・リソースは、アラート宛先リソースおよび電子メール・トランスポート・ベースのビジネス・サービスの構成を行う際に使用されます。SMTPサーバー・リソースを新しい環境にデプロイする場合、更新または再構成の必要があります。デプロイメントの際のSMTPサーバー・リソースの更新方法については、6.7項「グローバル・リソースの移行」を参照してください。

1.5.3 リレーショナル・データベース管理システムのリソース

Oracle Service Busでは、JMSレポート・プロバイダによるメッセージ・レポート・データの格納はデータベース・リソースに依存します。データベースのパフォーマンスは、Oracle Service Bus全体のパフォーマンスを決定する要因の1つです。

データベースの調整の詳細は、データベース・ベンダーのドキュメントを参照してください。

1.5.4 ハードウェア、オペレーティング・システムおよびネットワーク・リソース

ハードウェア、オペレーティング・システムおよびネットワーク・リソースは、Oracle Service Busパフォーマンスにとって重要な役割を果たします。デプロイメントでは、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlにある「Oracle Fusion Middleware Supported System Configurations」に記述されたハードウェア要件とソフトウェア要件に従う必要があります。

2 非クラスタ・デプロイメントの構成

この章では、非クラスタOracle WebLogic ServerドメインでOracle Service Busをデプロイするための構成に必要な作業について説明します。非クラスタOracle Service Busデプロイメントとは、「管理サーバーのみ」または「管理サーバーおよび管理対象サーバー」のいずれかのOracle Service Busデプロイメント・トポロジを指します(第1章の「Oracle Service Busデプロイメント・トポロジ」を参照)。

非クラスタ構成でOracle Service Busを設定およびデプロイするには、次の手順を実行します:

- 2.1項「手順1. JMSレポート・プロバイダ・データ・ストア用データベースの構成」

- 2.2項「手順2. Oracle Service Busドメインの準備」

- 2.3項「手順3. Oracle Service Busセキュリティの構成」

- 2.4項「手順4. Oracle Service Bus構成のデプロイ」

- 2.5項「手順5. 本番環境の変更にあわせたドメインの更新」

2.1 手順1.JMSレポート・プロバイダ・データ・ストア用データベースの構成

Oracle Service Busでは、JMSレポート・プロバイダ用のデータベースが必要です。Oracle WebLogic ServerとともにインストールされるApache Derbyデータベースのローカル・コピーを本番で使用することはお薦めできません。

Oracle Service Bus JMSレポート・プロバイダ用のデータベースの構成については、Oracle Fusion Middleware Oracle Service Busインストレーション・ガイドを参照してください。

サポートされているデータベースの詳細なリストについては、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlにある「Oracle Fusion Middleware Supported System Configurations」を参照してください。

注意:

データベースを本番用に適切に構成することが重要です。メッセージをログに記録するための十分な領域を用意し、データベース管理のベスト・プラクティスに従う必要があります。

2.2 手順2.Oracle Service Busドメインの準備

Oracle Service Bus環境を準備するには、次の項で説明する作業を行う必要があります。

- 2.2.1項「Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成」

- 2.2.2項「JMSリソースの構成」

2.2.1 Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成

Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成の詳細は、Oracle Fusion Middleware Oracle Service Busインストレーション・ガイドの「Oracle Service Bus 11gのインストールと構成」を参照してください。

2.2.2 JMSリソースの構成

Oracle Fusion Middleware構成ウィザードでJMSファイル・ストアを構成するとともに、JMSを使用するプロキシ・サービスおよびビジネス・サービスに、次のリソースを構成する必要があります。

- JMS接続ファクトリ。JMSを使用して実装されたすべてのビジネス・サービスとプロキシ・サービスに、XAまたは非XAのJMS接続ファクトリを構成する必要があります。

- JMSキューまたはトピック。Oracle Service Busでは、JMSを使用して実装されたプロキシ・サービスに自動的にJMSキューが構成されます。JMSを使用するすべてのビジネス・サービスおよび非JMSを使用して実装されたプロキシ・サービスには、JMSキューまたはトピックを構成する必要があります。

すべてのOracle Service Bus JMSリソースを単一のJMSモジュールにまとめる場合、Oracle WebLogic Server管理コンソールを使用して、プロキシ・サービスのエンドポイントとして使用する宛先を含む新しいJMSモジュールを作成します。

JMSリソースの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSリソースの構成方法に関する項を参照してください。

2.3 手順3.Oracle Service Busのセキュリティ構成

Oracle Service Busでは、Oracle WebLogic Serverのセキュリティ機能を利用して、メッセージの機密性と整合性を確保し(メッセージ・レベルのセキュリティ)、クライアントとOracle WebLogic Serverの間の接続を保護し(トランスポート・レベルのセキュリティ)、認証と認可(アクセス制御)を行います。Oracle Service Busのセキュリティの構成方法については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のセキュリティに関する項を参照してください。

注意:

各Oracle Service Busドメインに別々にセキュリティを構成する必要があります。Oracle Service Busでは、セキュリティ構成のエクスポートおよびインポートは行いません。

2.4 手順4.Oracle Service Bus構成のデプロイ

Oracle Service Busドメインの構成と保護を終え、サービスに必要なJMSリソースを追加すると、Oracle Service Bus構成が入ったJARファイルをインポートできます。構成メタデータをインポートした後、ドメインの環境固有の情報を更新できます。

次に、構成JARファイルの内容をデプロイする基本手順を示します。

1. Oracle Service Busでセッションを作成します。

2. 構成JARファイルからすべてのオブジェクトまたは選択したオブジェクトをインポートします。

3. サービス・エンドポイントURI、ディレクトリ名などの環境固有の情報を更新します。

4. セッションをアクティブ化します。

この手順は手動で行うことも、プログラムで実行することもできます。

- 構成を手動でインポートおよび更新するには、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の次の説明に従って、Oracle Service Bus管理コンソールを使用します。

- リソースのインポートに関する項

- 環境値の検索と置換に関する項

- プログラムで構成のインポートと更新を行うには、付録A「デプロイメントAPIの使用」で説明されているようにWebLogic Scripting Tool (WLST)とOracle Service BusのdeploymentMBeanを使用します。

サービス・エンドポイントURI、ディレクトリ名、およびセキュリティ構成に加え、Oracle Service Bus構成には、新しい環境で正しく動作するように更新する必要のある設定が含まれていることがあります。通常、次の項目は更新が必要です。

- サービス参照
サービス参照の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のリソースへの参照の表示に関する項を参照してください。

- ルーティングの宛先
ルーティングの構成については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のプロキシ・サービス: メッセージ・フローに関する項を参照してください。

- ロード・バランシング設定
ロード・バランシングについては、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のトランスポート構成ページに関する項を参照してください。

必要に応じて、Oracle Service Bus管理コンソールを使用して構成の確認と変更を行います。

2.5 手順5.本番環境の変更にあわせたドメインの更新

本番環境は、時間の経過や、アプリケーション使用の増加に伴って変化します。この項では、一般的な本番環境の変化に応じてドメインを更新する方法を説明します。

- 2.5.1項「ビジネス・サービスの変更」

- 2.5.2項「新しいバージョンのプロキシ・サービスのインストール」

- 2.5.3項「構成のオンライン更新」

2.5.1 ビジネス・サービスの変更

既存のエンタープライズ情報システム(EIS)インスタンスが徐々に少なくなり、新しいインスタンス(EISソフトウェアの新しいバージョン、新しいハードウェアなどで使用可能)がオンラインで提供される場合があります。このような場合、Oracle Service Bus管理者は、影響を受けるOracle Service Busサービスを変更して新しいEISインスタンスに適切に移行する必要があります。

これは、EISインスタンス障害に似ていますが、緊急な対処は必要ありません。デプロイメントに関する考慮事項については、5.2.2項「EISインスタンスのフェイルオーバー」を参照してください。Oracle Service Bus管理コンソールを使用したビジネス・サービス用のエンドポイントURIの変更については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「トランスポート構成」ページに関する説明を参照してください。

2.5.2 新しいバージョンのプロキシ・サービスのインストール

ビジネス要件の変化に伴い、プロキシ・サービスの変更が必要になることがあります。変更に下位互換性がある場合、Oracle Service Bus管理コンソールを使用してオンラインで動的に変更を行い、新しいバージョンのプロキシ・サービスを作成できます。次のいずれかの条件を満たす場合、変更には下位互換性があります。

- 変更対象オブジェクトのインタフェースは変更しません。

- 新旧混在のクライアントがインタフェースを使用します。

必要な変更に下位互換性がない場合、オンラインで変更できるようにする2つの代替方法があります。

- 以前のバージョンとは異なる名前とURLを持つ新しいプロキシ・サービスを作成し、デプロイします。クライアントは新しいプロキシ・サービスにアクセスすることでアップグレードされます。この場合、プロキシ・サービスの新旧のバージョンを並行して実行し、新しいプロキシ・サービスに段階的に移行できます。

- プロキシ・サービスのインタフェースを変更して新しいインタフェースと古いインタフェースの両方をサポートするようにし(たとえば、XMLスキーマchoiceを使用)、受信されるドキュメントに基づいてメッセージ・フローで異なるロジックを実行することで、下位互換性を強制的に実現します。クライアントは、引続き元のURLを使用してプロキシ・サービスにアクセスできます。

さらに、Oracle Service Busクラスタ・ドメインでは、下位互換性のないプロキシ・サービスのデプロイメントについてのシステム管理要件があります。詳細は、4.6.4項「クラスタへの新しいバージョンのプロキシ・サービスのインストール」を参照してください。

2.5.3 構成のオンライン更新

Oracle Service Busでは、システムの構成情報を動的に変更できます。変更内容を有効にするためにサーバーを再起動する必要はありません。

Oracle Service Bus管理コンソールで次の手順を実行して、リソースやプロジェクト、または複数の(関連する、あるいは関連しない)リソースを変更できます。

1. セッションを作成します。Oracle Service Busの構成を変更する場合は、必ずセッションが必要です(セキュリティ関連の変更は例外です)。

2. セッションでリソースを変更するか、構成JARファイルからすべてのオブジェクトまたは選択したオブジェクトをインポートします。

3. サービス・エンドポイントURI、ディレクトリ名などの環境固有の情報を更新します。

4. セッションをアクティブ化します。
変更がまとめられ、すべてのサーバー(クラスタ環境を使用している場合は管理サーバーと管理対象サーバー)に送られます。このような変更によって、永続構成データが更新され、また、他の実行時タスク(プロキシ・サービスやJMSキューの作成、XQueryのコンパイルなど)も実行されます。

この手順は手動で行うことも、プログラムで実行することもできます。

- 構成を手動でインポートおよび更新するには、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の次の説明に従って、Oracle Service Bus管理コンソールを使用します。

- リソースのインポートに関する項

- 環境値の検索と置換に関する項

- プログラムで構成のインポートと更新を行うには、付録A「デプロイメントAPIの使用」で説明されているようにWebLogic Scripting Tool (WLST)とOracle Service BusのdeploymentMBeanを使用します。

図2-1は、システムでのメッセージの処理中に構成が更新された場合に、システムがメッセージを処理するためにどのように動作するかを示します。表2-1は、図2-1に示されているサンプル・システムのリソースのバージョンを示します。

表2-1 サンプル・システムの最初の構成と更新された構成

リソース

最初のバージョン

更新されたバージョン

プロキシ・サービス

X

A

MFL

Y

B

XQuery

W

C

図2-1 オンライン更新のサンプル・シナリオ

「図2-1 オンライン更新のサンプル・シナリオ」の説明

この図のメッセージ処理では次の点に注意してください。

- メッセージ1は、t1 (構成の更新時)にはすでにシステムに届いている

- メッセージ1は、元(更新前)のリソース(X、Y、W)を使用して処理を完了する

- メッセージ2は、新しい構成(リソースA、B、C)を使用して処理を開始して完了する

Oracle Service Busは、メッセージがプロキシ・サービスに届いた時点で使用可能なバージョンのプロキシ・サービスとアーティファクトを使用して、メッセージを実行しようとします。

これにより、メッセージのアーティファクトの一貫性が保たれます。メッセージ・プロセッサが、メッセージに対してこの動作を保証できない場合は、誤って処理しないようにメッセージを拒否します。拒否されたメッセージをシステムで再試行するには、再試行機能のあるJMSプロキシ・サービスを使用します。

2.5.3.1 構成のオンライン更新のベスト・プラクティス

この項では、実行中のOracle Service Busシステムで構成を更新するときに従うベスト・プラクティスと注意する必要のある制約について説明します。

- Oracle Service Busによるメッセージの拒否が心配な場合は、再試行機能のあるJMS転送プロトコルを使用します。互換性のあるリソースでの処理をシステムが保証できないためにメッセージが拒否されることがありますが、この場合はそのようなメッセージがすべて再試行されます。

- システムでは、セキュリティ関連の構成更新を最初に実行してから、Oracle Service Busのリソースを更新する必要があります。セキュリティ・リソースの更新の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のセキュリティ管理の概要に関する項を参照してください。

- 更新内容は、システムを使用する既存のクライアントと互換性を持つ必要があります。2.5.2項「新しいバージョンのプロキシ・サービスのインストール」を参照してください。

- クラスタの構成を更新する場合、管理対象サーバーごとに更新のタイミングが異なる可能性があります。結果として、メッセージを取得して処理する管理対象サーバーに応じて、メッセージを処理するプロキシ・サービスのバージョンが異なることがあります。これは、管理対象サーバー間のロード・バランシングに依存します。

- オンライン・デプロイメントの際に、Oracle Service Busで、正しいバージョンの参照リソースがメッセージ処理に使用されているかどうかを確認します。一時的に正しいバージョンの参照リソースが使用されていない場合は、エラーが返されます。ただし、呼び出されたサービスのインタフェース・アーティファクト(MFL、WSDLなど)が変更されている場合、プロキシ・サービスのバージョンと相関しないアーティファクトのバージョンが一時的に確認されても、呼出しを行うプロキシ・サービスではエラーを返さない場合があります。

3 Oracle Service Busクラスタについて

この章では、クラスタ環境にOracle Service Busを構成およびデプロイする方法について説明します。

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

- 3.1項「Oracle Service Busクラスタについて」

- 3.2項「クラスタ・デプロイメントの設計」

- 3.3項「Oracle Service Busクラスタのロード・バランシング」

- 3.4項「Oracle Service Busクラスタの高可用性」

- 3.5項「構成のデプロイ」

3.1 Oracle Service Busクラスタについて

クラスタリングによって、Oracle Service Busをサーバーのグループで実行でき、そのグループを単体ユニットとして管理できます。クラスタ環境では、複数のマシンが負荷を分担します。Oracle Service Busにはロード・バランシング機能があるので、リソース・リクエストはすべてのマシンに均等に分散されます。Oracle Service Busデプロイメントは、クラスタリングとロード・バランシングを使用してノードに負荷を分散させることにより、スケーラビリティを向上できます。クラスタリングにより、単一サーバーよりもスケーラビリティの高いデプロイメント・プラットフォームを構築できます。

Oracle WebLogic Serverクラスタのドメインは、1台の管理サーバーと、1つまたは複数の管理対象サーバーで構成されます。Oracle Service Busドメインの管理対象サーバーを1つのクラスタにまとめることができます。Oracle Service Busのクラスタリング可能リソースを構成する場合、通常はそのリソースのデプロイ・ターゲットとするクラスタを指名します。クラスタをリソース・デプロイメントのターゲットとして指定すると、管理対象サーバーをクラスタに追加することによって容量を動的に増大できるという利点が得られます。

注意:

Oracle Service Busドメインでは単一のクラスタをサポートでき、ドメイン内のすべての管理対象サーバーがそのクラスタに属する必要があります。

ここでは、クラスタ環境でOracle Service Busを構成する場合に必要な情報について説明します。Oracle WebLogic Serverでサポートしているクラスタリングについての予備的な情報も含まれていますが、主に、クラスタ環境でOracle Service Busを構成する手順を説明します。

読み進む前に、次のOracle WebLogic Serverドキュメントの項の内容を確認し、クラスタリングについて十分に理解しておくことをお薦めします。

- 『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』

- 『Oracle Fusion Middleware Oracle WebLogic Serverのサーバー環境設定』

3.2 クラスタ・デプロイメントの設計

次の項では、クラスタ・デプロイメントの設計に必要な情報について説明します。

- 3.2.1項「Oracle Service Busドメインについて」

- 3.2.2項「Oracle Service Busデプロイメントのリソース」

- 3.3項「Oracle Service Busクラスタのロード・バランシング」

3.2.1 Oracle Service Busドメインについて

クラスタリングされたドメインに合わせてアーキテクチャを設計する前に、Oracle WebLogic Serverクラスタがどのように運用されるかを知っておく必要があります。

3.2.1.1 ドメインの作成

ドメインおよびクラスタの作成は、Oracle Fusion Middleware構成ウィザードを使用して基本および拡張ドメイン・テンプレートからドメインを生成することにより、簡単に実行できます。ユーザー問合せに対するレスポンスを基に、構成ウィザードによって、ドメイン、サーバー、エンタープライズ・アプリケーションが、事前構成された適切なコンポーネントおよび資産を含めて生成されます。Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成については、Oracle Fusion Middleware Oracle Service Busインストレーション・ガイドを参照してください。

3.2.1.2 クラスタ・サーバー

サーバーには、管理対象サーバーと管理サーバーがあります。管理サービスを実行しているOracle WebLogic Serverは管理サーバーと呼ばれ、Oracle WebLogic Server管理コンソールのホストとなります。複数のOracle WebLogic Serverが稼働しているドメインでは、そのうち1つのみが管理サーバーで、他のサーバーは管理対象サーバーと呼ばれます。各管理対象サーバーは、起動時に管理サーバーから構成を取得します。

注意:

管理サーバーなしで起動する管理対象サーバーは、管理対象サーバー独立(MSI)モードで稼働します。MSIモードの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』の管理対象サーバー独立モードに関する項を参照してください。

管理サーバーのSSLポート、HTTPクリア・テキスト・ポート、またはそれら両方のポートを有効にできます。セキュア・インストールでは、HTTPクリア・テキスト・ポートを無効にできます。ただし、Oracle Service BusをUDDIレジストリ(Oracle Service Registryなど)と組み合せて使用する場合は、サーバーのHTTPクリア・テキスト・ポートを有効にする必要があります。

WebLogicクラスタの一般情報については、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。このドキュメントでは、推奨される基本、多層、およびプロキシ・アーキテクチャの詳細について説明されています。WebLogicクラスタ設計のセキュリティに関する考慮事項については、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のクラスタ・アーキテクチャのセキュリティ・オプションに関する項を参照してください。

3.2.2 Oracle Service Busデプロイメントのリソース

クラスタリングされたドメインの各サーバーに対して、そのドメイン内のサーバーの機能を定義する様々な属性を構成できます。これらの属性は、Oracle Fusion Middleware構成ウィザードでOracle Service Busドメインを作成すると、自動的に構成されます。また上級ユーザーの場合は、Oracle WebLogic Server管理コンソールの「サーバー」ノードを使用して手動で構成することもできます。

構成可能なOracle Service Busデプロイメント・リソースについては、付録B「Oracle Service Busデプロイメントのリソース」を参照してください。ここでは、クラスタリングされたOracle Service Busドメインの各リソースのデフォルトのターゲット指定について説明し、Oracle WebLogic Server管理コンソールの各リソースへの移動方法を示しています。

3.2.2.1 シングルトン・リソース

Oracle Service Busで使用されるほとんどのリソースはクラスタ内に均一にデプロイされますが、正しく動作させるには単一の管理対象サーバーに固定する必要があるリソースがあります。次の表に、これらのコンポーネント、そのターゲット指定の方法、および詳細情報へのリンクを示します。

表3-1 Oracle Service Busのシングルトン・リソース

リソース

ターゲット指定方法および指定先

参照先

プロキシ・サービスのファイル、FTP、および電子メール・ポーラー

Oracle Service Bus管理コンソールを使用してプロキシ・サービス定義に手動で指定されます。ポーラーはすべての管理対象サーバーにデプロイされますが、特定のプロキシ・サービスには1つの管理対象サーバーにあるポーラーがポーリングします。

Oracle Fusion Middleware Oracle Service Busインストレーション・ガイド

ALSBドメイン・シングルトン・マーカー・アプリケーション

Oracle Fusion Middleware構成ウィザードでターゲット指定する

Oracle Fusion Middleware Oracle Service Busインストレーション・ガイド

SLAマネージャ

Oracle Fusion Middleware構成ウィザードでターゲット指定する

Oracle Fusion Middleware Oracle Service Busインストレーション・ガイド

各管理対象サーバーのOracle Service Bus JMSサーバー

wlsbJMSServer_auto_1-n

Oracle Fusion Middleware構成ウィザードでターゲット指定する

Oracle Fusion Middleware Oracle Service Busインストレーション・ガイド

3.2.2.2 クラスタのモニター・リソースとアラート・リソース

ALSBドメイン・シングルトン・マーカー・アプリケーション(domainsingletonmarker.ear)は、クラスタ内の1台の管理対象サーバーでシングルトン・サービスとして実行されます。データの収集は、ドメインの各管理対象サーバーで実行されます。ALSBドメイン・シングルトン・マーカー・アプリケーションは、ドメインのすべての管理対象サーバーからデータを収集し、集約します。集約されたデータは処理され、Oracle Service Bus構成ごとに分類されます。

Oracle Service Bus構成には、システム・パフォーマンスのサービス・レベル合意(SLA)を定義するルールを含めることができます。アラート・マネージャではルールを格納し、集約されたクラスタ・データについてルールを評価します。ルールがtrueと評価された場合、アラート・マネージャではルールに関連付けられているアクションに従って、電子メール・メッセージの送信、JMSキューへのメッセージのポスト、またはメッセージのロギングを行います。

これらの機能の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のモニターに関する項を参照してください。

3.2.2.3 クラスタ構成の変更およびデプロイメント・リクエスト

セッションのアクティブ化処理中に管理対象サーバーがダウンした場合、そのサーバーには、アクティブ化による構成の変更は反映されません。また、セッションのアクティブ化についてのタスクのステータスは、部分的にアクティブ化されましたとして示され、すべての管理対象サーバーでアクティブ化処理が完了しなかったことを示します。管理対象サーバーを再起動すると、管理対象サーバーは、管理サーバーから入手可能な情報と同期し、アクティブ化されていないすべての変更内容が管理対象サーバーでアクティブ化されます。セッションのアクティブ化の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のチェンジ・センターの使用に関する項を参照してください。

クラスタの再構成(クラスタへの新しいノードの追加やビジネス・サービス構成の変更など)を行うことができるのは、その管理サーバーがアクティブな場合のみです。

あるクラスタの管理サーバーが使用できなくなると、デプロイ・リクエストやアンデプロイ・リクエストは中断されますが、管理対象サーバーはリクエストの処理を続行します。各管理対象サーバーは、必要な構成ファイル(msi-config.xml、SerializedSystemIni.datおよびオプションのboot.properties)がその管理対象サーバーのルート・ディレクトリに存在するかぎり、既存の構成を使用して起動および再起動できます。

3.3 Oracle Service Busクラスタのロード・バランシング

Oracle Service Busアプリケーションをクラスタリングする目的の1つは、スケーラビリティの実現です。クラスタをスケーラブルなものにするには、各サーバーを十分に活用する必要があります。ロード・バランシングにより、クラスタ内のすべてのサーバー間で負荷が均等に分散され、各サーバーがそれぞれ最大能力で動作できるようになります。次の項では、Oracle Service Busクラスタのインバウンド・メッセージ処理のロード・バランシングについて説明します。

- 3.3.1項「クラスタにおけるHTTP機能のロード・バランシング」

- 3.3.2項「クラスタにおけるJMS機能のロード・バランシング」

インバウンド・メッセージのロード・バランシングについては、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』の「クラスタでのロード・バランシング」を参照してください。ビジネス・サービスのロード・バランシングの構成については、 『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のトランスポート構成に関する項を参照してください。

3.3.1 クラスタにおけるHTTP機能のロード・バランシング

Webサービス(SOAPまたはXML over HTTP)では HTTPロード・バランシングを使用できます。外部ロード・バランシングは、WebLogic HttpClusterServlet、WebServerプラグインまたはハードウェア・ルーターによって実現できます。ロード・バランシングを含むクラスタ・トポロジの概要については、図5-1を参照してください。Oracle WebLogic ServerはHTTPセッションの状態およびクラスタ・オブジェクトのロード・バランシングをサポートしています。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のクラスタでの通信に関する項を参照してください。

3.3.2 クラスタにおけるJMS機能のロード・バランシング

Oracle Service Busで使用されるほとんどのJMSキューは分散宛先として構成されています。例外は、単一の管理対象サーバーに割り当てられているJMSキューです。

JMSロード・バランシングの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』のJMSサーバーおよび宛先のメッセージのフロー制御に関する項を参照してください。

3.4 Oracle Service Busクラスタの高可用性

メッセージドリブンBeanは、JMS宛先からのメッセージを消費します。多くのメッセージドリブンBeanが、Oracle Service Busの各宛先にデプロイされます。

3.4.1 Oracle Service Bus用の高可用性を備えたJMS

複数の物理宛先を1つの分散宛先グループのメンバーとして構成できるため、WebLogic JMSを実装にきわめて高い可用性がもたらされます。具体的には、管理者がクラスタ内の各ノードに対して、各分散宛先に物理宛先を1つ構成する必要があります。クラスタ内のノードに障害が発生して、そのノードの物理宛先が使用できなくなった場合、分散宛先のメンバーとして構成された他の物理宛先が、JMSのプロデューサとコンシューマにサービスを提供することができます(この方法で、Oracle Fusion Middleware構成ウィザードはクラスタのドメインを生成します)。

メッセージドリブンBeanは、分散宛先からのメッセージを消費します。分散宛先には、Oracle WebLogic Serverのインスタンスごとに1つの物理宛先が含まれます。分散キューの各メッセージ・プロデューサは、それぞれ1つの物理宛先にバインドされています。メッセージドリブンBeanは、デプロイ先のサーバー内の物理宛先にバインドされています(サーバー親和性)。

詳細は、第5章「Oracle Service Busの高可用性について」を参照してください。

3.5 構成のデプロイ

構成をデプロイするには、Oracle Service Bus管理コンソールからエクスポートされた1つまたは複数のJARファイルの内容をインポートします。クラスタ環境にOracle Service Bus構成をデプロイするときは、非クラスタ・デプロイメントと同じ手順に従います。デプロイメント手順については、2.4項「手順4. Oracle Service Bus構成のデプロイ」を参照してください。

本番クラスタ環境へのOracle Service Bus構成のデプロイメントを準備するときは、非クラスタのテスト環境またはステージング環境の場合より多くのシステム管理タスクが必要になります。本番クラスタ・デプロイメントで必要な手順の詳細は、第4章「クラスタ・デプロイメントの構成」を参照してください。

4 クラスタ・デプロイメントの構成

この章では、クラスタ環境でOracle Service Busをデプロイするための構成に必要な作業について説明します。

注意:

Oracle Service Busを非クラスタ環境の管理対象サーバー上で実行する場合は、第2章「非クラスタ・デプロイメントの構成」を参照してください。

クラスタ・ドメインのアーキテクチャを、3.2項「クラスタ・デプロイメントの設計」の説明に従ってプランニングしたら、Oracle Service Busをクラスタ環境に設定できます。そのためには、管理サーバーと管理対象サーバーを構成し、Oracle Service Busリソースをサーバーにデプロイする必要があります。インバウンドHTTPロード・バランシング機能が必要な場合は、ルーター(ハードウェアまたはソフトウェア)も必要です。Oracle WebLogic Serverインスタンスとクラスタのドメインの永続構成は、Oracle Service Busドメインのルート・ディレクトリのconfigディレクトリにあるXML構成ファイル(config.xml)に格納されます。

クラスタ・ドメインでOracle Service Busを設定およびデプロイするには、次の手順を実行します:

- 4.1項, 「手順1. 構成の前提条件への準拠」

- 4.2項「手順2. Oracle Service Busドメインの準備」

- 4.3項「手順3. Oracle Service Busセキュリティの構成」

- 4.4項「手順4. 管理対象サーバーの起動、停止、モニター」

- 4.5項「手順5. Oracle Service Bus構成のデプロイ」

- 4.6項「手順6. 本番環境の変更にあわせたドメインの更新」

Oracle Service Busの非クラスタ環境へのデプロイについては、第2章「非クラスタ・デプロイメントの構成」を参照してください。

4.1 手順1.構成の前提条件への準拠

この項では、クラスタ環境で実行されるOracle Service Busを構成するための次の前提条件について説明します。

- そのクラスタで使用する管理サーバーのIPアドレスを取得します。
1つのクラスタ内のすべてのOracle WebLogic Serverインスタンスは、構成およびモニターに同じ管理サーバーを使用します。サーバーをクラスタに追加する場合、各サーバーが使用する管理サーバーを指定する必要があります。

- 各クラスタにマルチキャスト・アドレスを割り当てます。

注意:

Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成時に、マルチキャスト・アドレスの割当てが要求されます(4.2項「手順2. Oracle Service Busドメインの準備」を参照してください)

マルチキャスト・アドレスは、クラスタ・メンバー間の通信に使用されます。クラスタリングされたサーバーは、1つの専用マルチキャスト・アドレスを共有する必要があります。ネットワーク上の各クラスタに対して、一意のマルチキャスト・アドレスとポート番号の組合せを割り当てる必要があります。ネットワーク上の2つのクラスタが同じマルチキャスト・アドレスを使用する場合、異なるポートを使用する必要があります。クラスタのマルチキャスト・アドレスが異なる場合は、同じポートを使用するか、またはデフォルトのポート(7001)をそのまま使用することもできます。マルチキャスト・メッセージをサポートするため、1つのクラスタ内の管理サーバーおよび管理対象サーバーを同じサブネット上に配置する必要があります。

- クラスタ内のサーバーのIPアドレスを定義します。アドレス定義には、次のように、いくつかの方法があります。

注意:

Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成時に、サーバーのリスニング・アドレスの割当てが要求されます(4.2項「手順2. Oracle Service Busドメインの準備」を参照してください)

- クラスタ内のサーバーに対して1つのIPアドレスと異なるリスニング・ポート番号を割り当てる方法。
1つのIPアドレスとサーバーごとに異なるポート番号をクラスタ・サーバーに割り当てることにより、1つのマシンに、そのマシンをマルチ・ホーム・サーバー化することなくクラスタ環境を設定できます。

クライアントからこのようなIPアドレスにアクセスできるようにするには、次のいずれかの方法で、IPアドレスとポート番号でURLを構成します。

- ipAddress:portNumber-portNumber - ポート番号が連番になっている場合。例:
127.0.0.1:7003-7005

- ipAddress:portNumber+...+portNumber - ポート番号が連番ではない場合。例:
127.0.0.1:7003+7006+7008

- ipAddress:portNumber,ipAddress:portNumber,... - 冗長で明示的な指定。例:
127.0.0.1:7003,127.0.0.1:7004,127.0.0.1:7005

- クラスタ内の各マシン上で起動するOracle WebLogic Serverインスタンスごとに静的IPアドレスを割り当てる方法。
この方法では、複数のサーバーが1つのマシン上で実行されている場合、そのマシンはマルチ・ホーム・サーバーとして構成する必要があります。つまり、複数のIPアドレスが1つのコンピュータに割り当てられます。この場合は、クラスタ・アドレスをカンマ区切りのIPアドレスのリストの形にします。

たとえば、次のリストは、config.xmlファイルで指定されているクラスタ・アドレスの例です。MyClusterという名前のクラスタ内の、4つのサーバーのそれぞれに対して、静的IPアドレスが指定されています。

<Cluster ClusterAddress="127.0.0.1:7001,127.0.0.2:7001,127.0.0.3,127.0.0.4:7001" Name="MyCluster"/>

またDNSを使用してもサーバーを指定できます。

アドレス指定の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』の「WebLogicクラスタの設定」にあるリスニング・アドレスの問題の回避に関する項を参照してください。

注意:

テスト環境では、1台のマシンに複数のOracle WebLogic Serverインスタンスを割り当てることもできます。この場合、一部のOracle WebLogic Serverインスタンスを同一ノード上に異なるポート番号で配置し、他のOracle WebLogic Serverインスタンスを別の複数のノードに同一のポート番号で配置することができます。

- クラスタ・ドメイン用の次のいずれかのデータベースを構成します。

- Microsoft SQL Server

- Oracle

注意:

Oracle WebLogic ServerとともにインストールされるApache Derbyデータベースのローカル・コピーは、評価のみを目的としています。

データベースを本番用に適切に構成することが重要です。データおよびログ・メッセージを格納するための十分な領域を用意し、データベース管理のベスト・プラクティスに従う必要があります。

注意:

同時アクセス機能を使用するようにデータベースを構成できます。

特定のデータベースに関する最新情報については、製品のリリース・ノートを参照してください。

- 共用ファイル・システムを組み込みます。共用ファイル・システムは、高可用性が求められるあらゆるクラスタに不可欠です。ストレージ・エリア・ネットワーク(Storage Area Network : SAN)またはマルチ・ポート型のディスク・システムをお薦めします。
高可用性クラスタの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』にある「高度なJMSシステム・リソースの構成」のWebLogic JMSクラスタリングの構成に関する項を参照してください。

- システム用のルーター(ハードウェアまたはソフトウェア)を構成します。ロード・バランシングは、組込みロード・バランシング機能かWebLogicプロキシ・プラグインのいずれか、または別個のロード・バランシング用ハードウェアを使用して実現されます。
ハードウェアおよびソフトウェア・ルーターについては、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

注意:

1つまたは複数のファイアウォールを含めるようにドメインを設計する場合は、この他にも要件があります。ドメイン構成ファイルへのファイアウォール情報の追加方法については、4.2.1.1項「ドメイン構成へのプロキシ・サーバーまたはファイアウォール情報の追加」を参照してください。追加情報については、『Oracle Fusion Middleware Oracle WebLogic Serverのクラスタの使用』の「クラスタでの通信」を参照してください。

- Oracle Service Busでは、クラスタの管理対象サーバー間でファイル、電子メール、およびFTPトランスポート処理のロード・バランシングを行います。クラスタのすべての管理対象サーバーが、ファイル、電子メール、FTPの各プロキシ・サービス構成で指定されたアーカイブ、ステージ、エラーの各ディレクトリにアクセスできるようにします。これらのディレクトリは、NFSなどの共有ファイル・システムに構成します。共有ファイル・システムを使用することで、ユーザーとプログラムはリモート・システムにあるファイルにローカル・ファイルと同じようにアクセスできます。

クラスタリングされたOracle WebLogic Serverインスタンスの設定の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のWebLogicクラスタの設定に関する項を参照してください。

4.2 手順2.Oracle Service Busドメインの準備

Oracle Service Busドメインを準備する際には、各管理対象サーバーの定義をドメイン構成ファイル(config.xml)に追加し、すべての管理対象サーバーをクラスタに割り当て、Oracle Service Busコンポーネントをドメイン上のサーバーに指定する必要があります。

クラスタリング・ドメインでOracle Service Bus環境を準備するには、次の項で説明する作業を行う必要があります。

- 4.2.1項「Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成」

- 4.2.2項「JMSリソースの構成」

4.2.1 Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成

Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成の詳細は、Oracle Fusion Middleware Oracle Service Busインストレーション・ガイドの「Oracle Service Bus 11gのインストールと構成」を参照してください。

4.2.1.1 プロキシ・サーバーまたはファイアウォール情報のドメイン構成への追加

プロキシ・サーバーまたはファイアウォールの背後でWebサービスを使用する場合は、config.xmlファイルを編集して、そのプロキシ・サーバーまたはファイアウォールに関する情報を追加する必要があります。

プロキシ・サーバーまたはファイアウォールの情報をドメイン構成に追加するには、次の手順を実行します:

1. テキスト・エディタでconfig.xmlを開きます。

2. config.xmlファイルで、次のタグで始まる行を検索します。

<Cluster

3. 次の3つの属性をCluster属性リストに追加します。

FrontendHTTPPort="proxyPort" FrontendHTTPSPort="proxySSLPort" FrontendHost="proxyServerHost"

たとえば、次のリストは、config.xmlファイルで指定されているクラスタ・アドレスとファイアウォールの例です。クラスタ名はMyCluster、プロキシ・サーバー名はMyProxyです。

<Cluster ClusterAddress="127.0.0.1:7001,127.0.0.2:7001,127.0.0.3,127.0.0.4:7001" FrontendHTTPPort="7006" FrontendHTTPSPort="7007" FrontendHost="MyProxy" MulticastAddress="127.0.0.5" MulticastPort="7010" Name="MyCluster"/>

4. 変更内容を保存し、config.xmlファイルを閉じます。

4.2.2 JMSリソースの構成

Oracle Fusion Middleware構成ウィザードでJMSファイル・ストアを構成するとともに、JMSを使用するプロキシ・サービスおよびビジネス・サービスに、次のリソースを構成する必要があります。

- JMSキューまたはトピック。Oracle Service Busでは、JMSを使用して実装されたプロキシ・サービスに自動的にJMSキューが構成されます。JMSを使用するすべてのビジネス・サービスおよび非JMSを使用して実装されたプロキシ・サービスには、JMSキューまたはトピックを構成する必要があります。
プロキシ・サービスでは、異なるドメインのリモート・キューからのメッセージを消費できます。この場合、Oracle Serviceでは自動的にキューが作成されません。プロキシ・サービス用のJMSキューを作成できるのは、キューが同じローカルOracle Service Busドメインにある場合に限ります。

- JMS接続ファクトリ。JMSを使用して実装されたすべてのビジネス・サービスとプロキシ・サービスにJMS接続ファクトリを構成する必要があります。

JMSリソースの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』の高度なJMSシステム・リソースの構成に関する項を参照してください。

4.3 手順3.Oracle Service Busのセキュリティ構成

Oracle Service Busでは、Oracle WebLogic Serverのセキュリティ機能を利用して、メッセージの機密性と整合性を確保し(メッセージ・レベルのセキュリティ)、クライアントとOracle WebLogic Serverの間の接続を保護し(トランスポート・レベルのセキュリティ)、認証と認可(アクセス制御)を行います。必要な作業については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のセキュリティに関する項を参照してください。

注意:

各Oracle Service Busドメインに別々にセキュリティを構成する必要があります。Oracle Service Busでは、セキュリティ構成のエクスポートおよびインポートは行いません。

クラスタにSSLを構成するには、ドメインの作成時に行うか、またはOracle WebLogic Server管理コンソールを使用します。セキュリティ機能がマルチ・ノード・クラスタにデプロイされているドメインの場合は、クラスタ内の各マシンに対して、キーストア、サーバー証明書、秘密鍵なども構成する必要があります。各マシンに独立したキーストアを使用するか、すべてのマシンで利用可能な場合は単一のキーストアを使用します。

4.4 手順4.管理対象サーバーの起動、停止、モニター

この項では、クラスタ・ドメインの管理対象サーバーに対する基本管理タスクについて説明します。

- 4.4.1項「管理対象サーバーの起動と停止」

- 4.4.2項「サーバーのモニター」

4.4.1 管理対象サーバーの起動と停止

ノード・マネージャは、Oracle WebLogic Serverインスタンスの起動、停止、および移行に使用できるユーティリティです。Oracle WebLogic Server管理コンソールとともにノード・マネージャを使用して管理対象サーバーを起動するか、または、WLSTスクリプトを作成してノード・マネージャの機能を自動化できます。

ヒント:

起動されたサーバーでOracle Service Busクラスが使用できるように、setDomainEnvスクリプトを実行してからstartNodemanagerスクリプトを実行してください。または、サーバーを起動する前に、Oracle WebLogic Server管理コンソールでクラスパスを明示的に設定してください。

デフォルトでは、Oracle Fusion Middleware構成ウィザードでOracle Service Busクラスタ・ドメインが生成されるときに、次の処理が行われます。

- ドメイン・シングルトン・マーカー・アプリケーション(domainsingletonmarker.ear)がクラスタの最初の管理対象サーバーに割り当てられます。データ集約を正しく実行するには、domainsingletonmarker.earが指定されたサーバーを最初に起動し、他の管理対象サーバーが起動するときに使用できるようにする必要があります。

- PurgingMDB(msgpurger.ear)がクラスタの最初の管理対象サーバーに割り当てられます。メッセージ・パージを正しく実行するには、msgpurger.earが指定されたサーバーが使用可能であることが必要です。

ノード・マネージャの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。管理対象サーバーの起動方法と停止方法の概要については、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』の「サーバーの起動と停止」を参照してください。

4.4.2 サーバーのモニター

起動が完了したら、Oracle Service Bus管理コンソールを使用してサーバーのステータスを確認できます。Oracle Service Bus管理コンソールを使用したサーバーの監視については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「監視」で、サーバーの表示および配置に関する説明を参照してください。

4.5 手順5.Oracle Service Bus構成のデプロイ

クラスタ環境にOracle Service Bus構成をデプロイするときは、非クラスタ・デプロイメントと同じ手順に従います。デプロイメント手順については、2.4項「手順4. Oracle Service Bus構成のデプロイ」を参照してください。

注意:

非クラスタ環境から構成をインポートし、その構成にファイル、FTP、または電子メール・トランスポートを使用するプロキシ・サービスが含まれている場合、それらの各プロキシ・サービスに管理対象サーバーを指定する必要があります。管理対象サーバーのリストは、Oracle Service Busクラスタ・ドメイン内のOracle Service Bus管理コンソールのみに表示されます。

4.6 手順6.本番環境の変更にあわせたドメインの更新

本番環境は、時間の経過や、アプリケーション使用の増加に伴って変化します。この項では、一般的な本番環境の変化に応じてドメインを更新する方法を説明します。

- 4.6.1項「管理対象サーバーの追加」

- 4.6.2項「管理対象サーバーの削除」

- 4.6.3,項「クラスタのビジネス・サービスの変更」

- 4.6.4項「クラスタへの新しいバージョンのプロキシ・サービスのインストール」

4.6.1 管理対象サーバーの追加

Oracle Service Busの使用が増加するに従って、Oracle Service Busクラスタに新しい管理対象サーバーを追加して容量を増やすことができます。詳細な手順は、『Oracle Fusion Middleware高可用性ガイド』のトポロジのスケール変更に関する項を参照してください。

トポロジをスケール変更した後で、次のトピックの指示に従い、ビジネスおよびプロキシ・サービスを更新します。

4.6.1.1 拡張したクラスタのためのビジネス・サービス構成の更新

Oracle Service Bus構成に、JMSリクエスト/レスポンス機能を使用する1つまたは複数のビジネス・サービスがある場合、新しい管理対象サーバーをクラスタに追加した後、Oracle Service Bus管理コンソールを使用して次の手順も実行する必要があります。

1. 「チェンジ・センター」で「作成」をクリックし、セッションを作成します。

2. 「プロジェクト・エクスプローラ」を使用し、JMSリクエスト/レスポンスを使用するビジネス・サービスを検索して選択します。この種類のビジネス・サービスの「サービスの種類」には、「メッセージング・サービス」と表示されています。

3. 「詳細の表示」ページの一番下で「編集」をクリックします。

4. エンドポイントURIにクラスタ・アドレスがある場合、クラスタ・アドレスに新しいサーバーを追加します。

5. 「ビジネス・サービスの編集 - サマリー」ページで「保存」をクリックします。

6. JMSリクエスト/レスポンスを使用する残りの各ビジネス・サービスに対して、前の手順を繰り返します。

7. チェンジ・センターで「アクティブ化」をクリックします。

ビジネス・サービスは拡張したドメインでの処理用に構成されました。

注意:

ビジネス・サービスでJMS MessageID相関スキームを使用している場合、接続ファクトリ設定を編集して、管理対象サーバーをキューにマッピングする表にエントリを追加する必要があります。キューとトピックの宛先を構成する方法については、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSサーバーのターゲット指定に関する項を参照してください。

4.6.1.2 拡張したクラスタのためのプロキシ・サービス構成の更新

Oracle Service Bus構成に、クラスタ・アドレスを持つJMSエンドポイントを使用する1つまたは複数のプロキシ・サービスがある場合、新しい管理対象サーバーをクラスタに追加した後、Oracle Service Bus管理コンソールを使用して次の手順も実行する必要があります。

1. 「チェンジ・センター」で「作成」をクリックし、セッションを作成します。

2. 「プロジェクト・エクスプローラ」を使用し、クラスタ・アドレスを持つJMSエンドポイントを使用するプロキシ・サービスを検索して選択します。

3. 「詳細の表示」ページの一番下で「編集」をクリックします。

4. エンドポイントURIにクラスタ・アドレスがある場合、クラスタ・アドレスに新しいサーバーを追加します。

5. 「プロキシ・サービスの編集 - サマリー」ページで「保存」をクリックします。

6. クラスタ・アドレスを持つJMSエンドポイントを使用する残りの各プロキシ・サービスに対して、前の手順を繰り返します。

7. チェンジ・センターで「アクティブ化」をクリックします。

プロキシ・サービスは拡張されたドメインでの処理用に構成されました。

4.6.2 管理対象サーバーの削除

Oracle WebLogic Server管理ツールを使用して、Oracle Service Busクラスタから管理対象サーバーを削除できます。管理対象サーバーの削除を決定する前に、次のことを考慮する必要があります。

- Oracle Service Bus構成に、クラスタから削除する管理対象サーバーにトランスポート・ポーラーを固定しているファイル、FTPまたは電子メール・トランスポートを使用するプロキシ・サービスがある場合、クラスタから管理対象サーバーを削除する前に、これらの各プロキシ・サービスに異なる管理対象サーバーを選択する必要があります。

- ドメイン・シングルトン・マーカー・アプリケーションをホストする管理対象サーバーはクラスタから削除してはなりません。ドメイン・シングルトン・マーカー・アプリケーションをホストする管理対象サーバーに障害が発生した場合、手動で移行を行う必要があります。

- メッセージ・レポーティング・パージャー・アプリケーションをホストする管理対象サーバーを削除する場合は、メッセージ・レポーティング・パージャーと関連するキュー(wli.reporting.purge.queue)のために別のマネージャ・サーバーを選択する必要があります。

次の手順では、管理対象サーバーに関連付けられているリソースを削除し、最終的に管理対象サーバー自体を削除します。影響を受けるリソースのほとんどは名前が_auto_xで終わり、xは削除する管理対象サーバーの番号を表します。たとえば、管理対象サーバー2のJMSレポート・プロバイダ・キューはwli.reporting.jmsprovider.queue_auto_2と呼ばれます。

注意:

Oracle WebLogic Serverコンソールには、デフォルトでリソースの部分的なリストのみ表示されます。リソースの完全なリストを表示するには、「この表のカスタマイズ」をクリックし、「1ページごとの表示行数」の値を増やします。

クラスタから管理対象サーバーを削除する手順:

1. この項で説明した考慮事項を読んだ後で、クラスタ内のすべての管理対象サーバーを停止します。管理サーバーは実行したままにします。

2. Oracle WebLogic Serverコンソールにログインし、「チェンジ・センター」の「ロックして編集」をクリックします。

3. 分散キューからすべての*_auto_xキュー・メンバーを削除します。

1. 「ドメイン構造」ペインで、「サービス」→「メッセージング」→「JMSモジュール」を選択してJMSモジュールのリストを表示します。

2. 「jmsResources」モジュールをクリックします。名前がdist_で始まる分散キューのリストが表示されます。たとえば、dist_QueueIn_autoなどです。

3. 分散キューをクリックし、その「メンバー」タブに移動します。管理対象サーバーのキューを削除します。たとえば、管理対象サーバー2を削除している場合は、dist_QueueIn_auto分散キューからQueueIn_auto_2を削除します。

4. 各分散キューについてこれらの手順を繰り返し、削除している管理対象サーバーの関連*_auto_xリソースを削除します。

4. すべての*_auto_xキューを削除します。

1. jmsResourcesモジュールのリソースのリストで、削除している管理対象サーバーのキューのうち、名前が*_auto_xで終わるキューをすべて削除します。たとえば、管理対象サーバー2を削除している場合は、wli.reporting.jmsprovider.queue_auto_2を削除します。

2. 削除している管理対象サーバーの「サービス」→「メッセージング」→「JMSモジュール」→「WseeJmsModule」からすべての*_auto_xキューを削除します。たとえば、管理対象サーバー2を削除している場合は、DefaultCallbackQueue-WseeJmsServer_auto_2とDefaultQueue-WseeJmsServer_auto_2を削除します。

5. 削除している管理対象サーバーのすべてのJMSサブデプロイメントを削除します。

1. 「サービス」→「メッセージング」→「JMSモジュール」を選択します。

2. 「configwiz-jms」モジュールをクリックし、「サブデプロイメント」タブをクリックします。
「ターゲット」列の*_auto_xターゲットに注目します。削除している管理対象サーバーの*_auto_xをターゲットとしているすべてのサブデプロイメントを削除します。

3. 前の手順と同様に、削除している管理対象サーバーのjmsResourcesおよびWseeJmsModuleモジュールからすべての*_auto_xサブデプロイメントを削除します。

6. 削除している管理対象サーバーをターゲットとしているすべてのJMSサーバーを削除します。

1. 「サービス」→「メッセージング」→「JMSサーバー」を選択します。

2. 削除している管理対象サーバーのすべての*_auto_x JMSサーバーを削除します。

7. 削除している管理対象サーバーをターゲットとしているすべてのストア・アンド・フォワード・エージェントを削除します。

1. 「サービス」→「メッセージング」→「ストア・アンド・フォワード・エージェント」を選択します。

2. 削除している管理対象サーバーのすべての*_auto_xストア・アンド・フォワード・エージェントを削除します。

8. 削除している管理対象サーバーをターゲットとしているすべての永続ストアを削除します。

1. 「サービス」→「永続ストア」を選択します。

2. 削除している管理対象サーバーのすべての*_auto_x永続ストアを削除します。

9. 削除している管理対象サーバーのすべての移行可能なターゲットを削除します。

1. 「環境」→「移行可能なターゲット」を選択します。

2. 削除している管理対象サーバーのserver_name(移行可能)を削除します。たとえば、削除している管理対象サーバーの名前がosb_server2の場合は、osb_server2(移行可能)を削除します。

10. ALSB Framework Starterアプリケーションから管理対象サーバーをターゲット解除します。

1. 「ドメイン構造」ペインで、「デプロイメント」をクリックします。

2. ALSB Framework Starterアプリケーションをクリックし、「ターゲット」タブをクリックします。

3. 「ALSB Framework Starterアプリケーション」チェック・ボックスを選択し、「ターゲットの変更」をクリックします。

4. デプロイメント・ターゲットとしての管理対象サーバーを削除します。

注意:

「クラスタのすべてのサーバー」ターゲット・オプションが選択されている場合は、管理対象サーバーのターゲットを解除する必要はありません。

11. クラスタから管理対象サーバーを削除します。

1. 「環境」→「クラスタ」を選択し、クラスタの名前をクリックします。

2. 「サーバー」タブをクリックし、クラスタから管理対象サーバーを削除します。

3. クラスタの「構成」→「一般」タブに移動します。
「クラスタ・アドレス」フィールドで、クラスタ・アドレスから管理対象サーバーを削除します。

「クラスタ・アドレス内のサーバー数」フィールドで、サーバーの数を1つ減らします。

12. 管理対象サーバーを削除します。手順については、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理対象サーバーの削除に関する項を参照してください。

13. 残りの管理対象サーバーを再起動します。

4.6.3 クラスタのビジネス・サービスの変更

ビジネス・サービスを変更する手順は、非クラスタ環境でもクラスタ環境でも同じです。ビジネス・サービスの変更方法については、2.5.1項「ビジネス・サービスの変更」を参照してください。

しかし、クラスタのビジネス・サービスへの変更をデプロイする手順は、ビジネス・サービスに行った変更の種類および同時にデプロイする他の変更の性質によって異なります。詳細は、次の項のインストール方針に関する説明を参照してください。

4.6.4 クラスタへの新しいバージョンのプロキシ・サービスのインストール

ビジネス要件の変化に伴い、プロキシ・サービスの変更が必要になることがあります。このような変更はオンラインで動的に行うことも、部分的または完全にオフラインで行うこともできます。変更に下位互換性がある(つまり、インタフェースは変更しない)場合、Oracle Service Bus管理コンソールを使用してオンラインで動的に変更できます。他の種類の変更は、部分的または完全にオフラインで行う必要があり、システム管理の追加手順が必要です。

オンライン更新の実行については、2.5.3項「構成のオンライン更新」を参照してください。

プロキシ・サービス・インタフェースへの下位互換性がない変更を含む変更を行うには、完全なオフライン・デプロイメントが必要です。新しいバージョンをインストールするには、すべてのサーバーが作動中に次の手順を実行します。

1. すべてのインバウンド・メッセージを休止します。

2. 非同期にバックログされたすべてのメッセージが処理されたことを確認します。

3. プロキシ・サービスで必要な変更を行い、テストして、プロキシ・サービスが要求どおり動作することを確認します。

4. インバウンド・メッセージの受信を再開します。

下位互換性とインストール方針の詳細は、2.5.2項「新しいバージョンのプロキシ・サービスのインストール」を参照してください。

5 Oracle Service Busの高可用性について

この章では、Oracle Service Busデプロイメントのクラスタリングと高可用性について説明します。

クラスタリングされたOracle Service Busドメインは高可用性を備えています。高可用性デプロイメントには、ハードウェアやネットワークに障害が発生したときのリカバリ処理が備えられており、障害発生時に制御をバックアップ・コンポーネントに移行させることができます。

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

- 5.1項「Oracle Service Busの高可用性について」

- 5.2項「Oracle Service Busの障害とリカバリ」

- 5.3項「ポーラー・ベースのトランスポートの高可用性」

注意:

高可用性を実現するためのOracle Service Busの構成の詳細は、Oracle Service Bus製品ページの高可用性およびサーバー全体の移行のためのOSBのアーキテクチャに関するドキュメントを参照してください(http://www.oracle.com/technetwork/middleware/service-bus/overview/index.html)。

5.1 Oracle Service Busの高可用性について

高可用性を提供するクラスタでは、サービス障害からのリカバリが可能です。Oracle WebLogic Serverでは、クラスタリングされたオブジェクト、およびクラスタ環境のサーバーに固定されたサービスのフェイルオーバーがサポートされます。Oracle WebLogic Serverでこのようなフェイルオーバーを処理する方法については、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のクラスタでの通信に関する項を参照してください。

5.1.1 推奨ハードウェアおよびソフトウェア

一般的なOracle Service Bus環境で使用できる基本コンポーネントは次のとおりです。

- 管理サーバー

- クラスタ内の一連の管理対象サーバー

- HTTPロード・バランサ(ルーター)

- 管理対象サーバー・データ用に物理共有された高可用性を備えたディスク・サブシステム - サーバー全体の移行では、管理対象サーバーのすべてのデータがマルチ・ポート・ディスクに置かれている必要があります。推奨される一般的な方法は、マルチ・ポートのディスク・サブシステムまたはSANを使用し、複数のサーバーでディスク・サブシステム内のファイル・システムをマウントできるようにすることです。ファイル・システムは同時に共有しないでください。1台のサーバーには、1回につき1つのファイル・システムしかマウントできません。

- クラスタ・マネージャを使用してフェイルオーバー用に構成されたMicrosoft SQL ServerまたはOracle Database - 商用クラスタ・マネージャの使用に加え、データベース・ベンダーから提供される高可用性またはフェイルオーバー・ソリューションも利用できます(データベース固有の情報については、データベース・ベンダーのドキュメントを参照してください)。

注意:

各種のJDBCドライバに関連する可用性とパフォーマンスの注意点については、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデータベース接続の構成に関する項を参照してください。

クラスタ・システムのネットワーク・トポロジのプランニングについての詳細説明は、この項で扱う内容の範囲を越えています。1つ以上のOracle WebLogic Serverクラスタを構成することにより、ロード・バランサ、ファイアウォール、Webサーバーとの関連で、Oracle Service Bus構成で、インバウンド・ロード・バランシング機能とフェイルオーバー機能を十分に活用する方法については、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のクラスタ・アーキテクチャに関する項を参照してください。アウトバウンド・ロード・バランシングの構成については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のトランスポート構成ページに関する項を参照してください。

クラスタの簡単な表示、HTTPロード・バランサの表示、高可用性データベースとマルチ・ポート・ファイル・システムについては次の図を参照してください。

図5-1 クラスタの概略図

「図5-1 クラスタの概略図」の説明

5.1.1.1 JMSファイル・ストアについて

デフォルトのOracle Service Busドメイン構成では、モニターとアラートの目的で収集されたメトリックをJMSの永続性用のファイル・ストアに格納します。この構成は、パフォーマンスを最適化するために管理対象サーバー間で共有可能な、高可用性を備えたマルチ・ポート・ディスクに依存します。通常、これはJDBCストアよりもパフォーマンスが高くなります。

JMSファイル・ストアの構成については、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使い方に関する項を参照してください。

5.1.2 サーバー障害時の処理

ソフトウェアまたはハードウェアの問題により、サーバーに障害が発生することがあります。次の項では、障害が起こったときに自動的に発生するプロセスと、手動で行わなければならない手順について説明します。

5.1.2.1 ソフトウェア・フォルト

ソフトウェア・フォルトが発生すると、ノード・マネージャはOracle WebLogic Serverを再起動します(再起動するように構成されている場合)。ノード・マネージャの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。セキュア・インストールのリカバリを準備する方法については、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』の障害リカバリのためのディレクトリとファイルのバックアップに関する項を参照してください。

5.1.2.2 ハードウェア・フォルト

ハードウェア・フォルトが発生すると、物理マシンの修理が必要になり、長期間使用できなくなることがあります。この場合、次のイベントが発生します。

- HTTPロード・バランサが、障害の発生したサーバーを検出し、他の管理対象サーバーにリダイレクトします。実際のアルゴリズムは、HTTPロード・バランサのベンダーにより異なります。

- すべての新しい内部リクエストが、別の管理対象サーバーにリダイレクトされます。

- 障害が発生したサーバーで実行中のすべてのトランザクションが終了します。

- すでに待ち行列に入っているJMSメッセージは、自動的に移行されないため、手動で移行する必要があります。詳細は、5.1.2.3項「サーバーの移行」を参照してください。

- Oracle Service Bus構成にファイル、FTPまたは電子メール・トランスポートを使用するプロキシ・サービスが1つまたは複数あり、そのトランスポート・ポーラーが障害のあった管理対象サーバーに固定されている場合に通常の処理を再開するには、これらの各プロキシ・サービスの定義内の異なる管理対象サーバーを選択する必要があります。

- 集約機能アプリケーションをホストする管理対象サーバーで障害が発生した場合、モニターおよびアラート用に収集されたメトリックは自動的には移行されません。これらは手動で移行する必要があります。詳細は、5.1.2.3項「サーバーの移行」を参照してください。

5.1.2.3 サーバーの移行

Oracle Service Busでは、Oracle WebLogic Serverのサーバー移行機能を利用して、システム間での管理対象サーバーのフェイルオーバーを透過的に行うことができます。Oracle WebLogic Serverのサーバー移行の詳細は、Oracle WebLogic Serverドキュメントの次の項を参照してください。

- 『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のクラスタのフェイルオーバーとレプリケーションに関する項

- 『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバー障害の回避とサーバー障害からのリカバリに関する項

5.1.2.4 メッセージ・レポーティング・パージャー

JMSメッセージ・レポーティング・プロバイダのメッセージ・レポーティング・パージャーは、クラスタ内の単一の管理対象サーバーにデプロイされます(付録B「Oracle Service Busデプロイメントのリソース」を参照)。

メッセージ・レポーティング・パージャー・アプリケーションをホストする管理対象サーバーで障害が発生した場合は、通常の運用を再開するために、メッセージ・レポーティング・パージャーとそれに関連するキュー(wli.reporting.purge.queue)のために別の管理対象サーバーを選択する必要があります。

障害が発生した管理対象サーバーで保留されているパージ・リクエストは、自動的には移行されません。これらは手動で移行する必要があります。または、メッセージ・レポーティング・パージャー・アプリケーションとそのキューを別の管理対象サーバーに割り当てて、パージ・リクエストを再び送信します。

5.2 Oracle Service Busの障害とリカバリ

Oracle WebLogic Serverの高可用性機能に加え、Oracle Service Busには、Oracle Service Busソリューションの実装と構成単位での障害リカバリ機能があります。次の項では、Oracle Service Busの障害とリカバリついて説明します。

- 5.2.1項「透過的なサーバー再接続」

- 5.2.2項「EISインスタンスのフェイルオーバー」

5.2.1 透過的なサーバー再接続

Oracle Service Busでは、外部サーバーおよびサービスが障害により再起動されたとき、それらへの再接続が透過的に行われます。接続が使用できない間にOracle Service Busから宛先にメッセージが送信されると、サーバー・コンソールに1つまたは複数の実行時エラー・メッセージが表示されることがあります。

次の種類のサーバーおよびサービスで透過的な再接続を行うことができます。

- SMTP

- JMS

- FTP

- DBMS

- ビジネス・サービス

Oracle Service Bus管理コンソールにはモニター機能もあり、サービスのステータスを表示したり、サービスの障害に対応するSLAとアラートのシステムを構築できます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のモニターに関する項を参照してください。

5.2.2 EISインスタンスのフェイルオーバー

本番環境のほとんどのビジネス・サービスは、ロード・バランシングと高可用性を目的として複数のEISインスタンスを指すように構成されます。EISインスタンスの障害が長引くか、ビジネス・サービスが障害のある単一のEISインスタンスを指すことが予期される場合、ビジネス・サービスを再構成し、代替のオペレーション可能なEISインスタンスを指定できます。この変更は動的に行うことができます。

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

5.3 ポーラー・ベースのトランスポートの高可用性

ポーラー・ベースのファイル、FTP、および電子メール・トランスポートの、障害からのリカバリを可能にするために、追加のJMSベース・フレームワークが作成されました。これらのトランスポートでは、JMSフレームワークを使用して、メッセージの処理が少なくとも1回は実行されることを保証します。ただし、処理が実行されても、サーバーがクラッシュしたり、トランザクションが完了する前にサーバーが再起動された場合は、同じファイルを再度処理できます。処理が再度実行される回数は、ドメインのポーラー・トランスポートに設定されている再配信制限によって異なります。

ターゲット(ファイルおよびFTPトランスポートの場合はディレクトリ、電子メール・トランスポートの場合はサーバー・アカウント)からの新しいメッセージは、ポーリングまたはパイプライン処理時に、ダウンロード(ステージ)ディレクトリにコピーされます。

注意:

FTPトランスポートの場合、ファイル名は、リモート・ディレクトリで<名前>.stageに変更されます。ファイルは、パイプライン処理時のみ、ステージ・ディレクトリにコピーされます。

ファイルおよびFTPトランスポートの場合、ターゲット・ディレクトリのそれぞれの新しいファイル応じてJMSタスクが作成されます。電子メール・トランスポートの場合、電子メール・メッセージはダウンロード・ディレクトリのファイルに格納され、これらの各ファイルに応じてJMSタスクが作成されます。

これらのJMSタスク・メッセージは、Oracle Service Busドメインの作成時にこれらのトランスポート用に事前に構成されるJMSキューに格納されます。

5.3.1 JMSキュー

Oracle Service Busドメインに対して構成されるポーラー・トランスポート固有のJMSキューを次に示します。

表5-1 Oracle Service Busに対して構成されるJMSキュー

トランスポート名

JMSキュー名

FTP

wlsb.internal.transport.task.queue.ftp

ファイル

wlsb.internal.transport.task.queue.file

電子メール

wlsb.internal.transport.task.queue.email

ドメイン全体のメッセージドリブンBean (MDB)がJMSタスクを受信します。MDBはメッセージを受信すると、XAトランザクションのパイプラインを呼び出します。パイプラインでの例外またはサーバーのクラッシュによってパイプラインでメッセージ処理が失敗した場合、XAトランザクションも失敗し、メッセージは再度JMSキューに格納されます。このメッセージは、キューに設定された再配信制限のパラメータに基づいて、MDBに再配信されます。デフォルトでは、再配信制限は1(メッセージは1回送信され、1回再試行される)に設定されています。メッセージが正常に配信されずに再配信制限に達した場合、メッセージはエラー・ディレクトリに移されます。この制限は、Oracle WebLogic Serverコンソールから変更できます。詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSトピック: 構成: 配信の失敗に関する項を参照してください。

注意:

単一のOracle Service Busドメインのトランスポートの場合、再配信制限は、ドメイン全体でグローバルです。たとえば、1つのドメイン内で、あるFTPプロキシで再配信制限を2に設定し、別のFTPプロキシで再配信制限を5に設定することはできません。

5.3.2 クラスタの高可用性

クラスタでは、これらのそれぞれのポーラー・ベースのトランスポートに関連付けられているJMSキューは、分散キューです(各管理対象サーバーは、分散キューのメンバーであるローカルJMSキューを持っています)。トランスポート用のJMSキューはドメイン全体をサポートします。タスク・メッセージは、分散キューに入れられ、管理対象サーバーの基底のローカル・キューに渡されます。管理対象サーバーにデプロイされているMDBがメッセージを取得し、実際のメッセージ処理のために、トランザクションのパイプラインを呼び出します。

JMSキューは、クラスタ・ドメイン内の分散キューであるため、Oracle WebLogic Serverの分散キュー機能を利用することで高可用性が実現します。すべての管理対象サーバーがメッセージのポーリングを行うのではなく、クラスタ内のいずれかの管理対象サーバーのみにメッセージのポーリングのジョブが割り当てられます。プロキシ・サービスの構成時に、いずれかの管理対象サーバーが新しいファイルまたは電子メール・メッセージをポーリングするように構成されます。

ポーラー・サーバーは新しいメッセージをポーリングし、個々のポーラー・トランスポートに関連付けられた共通分散キューに置きます。このキューから、メッセージが管理対象サーバーのローカル・キューに渡されます。管理対象サーバーは、これらのローカル・キューを介して、すべてのサーバーにデプロイされているMDBを使用してメッセージを受信します。

注意:

これらのそれぞれのポーラー・ベースのトランスポート用に、すべての管理対象サーバーにローカル・キューを持つ共通分散キューがあります。

分散キューがローカル・キューにメッセージを配信した後で管理対象サーバーがクラッシュした場合は、手動で移行する必要があります。詳細は、5.1.2.3項「サーバーの移行」を参照してください。

クラスタが作成されるときに、すべての管理対象サーバーにローカル・キュー・メンバーを持つ共通分散キューが作成されます。ただし、既存のクラスタに新しい管理対象サーバーが追加されるときは、これらのローカル・キューは自動的には作成されません。ローカル・キューを手動で作成し、共通分散キューの一部にする必要があります。

ローカル・キューを作成するには:

1. JMSサーバーを作成し、新しく作成された管理対象サーバーに割り当てます。

2. ローカルJMSキューを作成し、再配信回数を設定して、新しいJMSサーバーに割り当てます。

3. このローカルJMSキューを、トランスポートに関連付けられている共通分散キューのメンバーとして追加します。

注意:

分散キューのJNDI名は、wlsb.internal.transport.task.queue.file(ファイル・トランスポートの場合)、wlsb.internal.transport.task.queue.ftp(FTPトランスポートの場合)およびwlsb.internal.transport.task.queue.email(電子メール・トランスポートの場合)です。

5.3.2.1 ロード・バランシング

分散JMSキューを使用すると、分散キューに関連付けられているロード・バランシング・アルゴリズムに基づいて、メッセージが管理対象サーバーに分散されます。デフォルトでは、JMSフレームワークでは、ラウンド・ロビン・ロード・バランシングを使用します。Oracle WebLogic ServerコンソールでJMSモジュールを使用してアルゴリズムを変更できます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のJMSのロード・バランシングに関する項を参照してください。管理対象サーバーのいずれかで障害が発生した場合、残りのメッセージは、他のいずれかのアクティブな管理対象サーバーによって処理されます。

注意:

ポーラー・サーバーは常に動作している必要があります。ポーラー・サーバーに障害が発生した場合、メッセージ処理も停止します。

6 デプロイメントのベスト・プラクティスおよびその他のトピック

この章では、Oracle Service Busをデプロイする際に使用できるベスト・プラクティスと手順について説明します。このドキュメントは、デプロイメント用に自動化スクリプトやプログラムを記述する開発者ではなく、デプロイメントやトポロジをプランニングするデプロイ担当者または管理者を対象としています。

詳細は、付録A「デプロイメントAPIの使用」を参照してください。開発者がスクリプトまたはプログラムを記述する場合は、Oracle Fusion Middleware Oracle Service BusのJava APIリファレンスを参照してください。

この章では、次の項について説明します。

- 6.1項「デプロイメント・トポロジ」

- 6.2項「デプロイメント・タイプ」

- 6.3項「デプロイメントの役割」

- 6.4項「カスタマイズ・ファイル」

- 6.5項「リソースのエクスポート」

- 6.6項「リソースのインポート」

- 6.7項「グローバル・リソースの移行」

- 6.8項「基本的なデプロイメントのベスト・プラクティスの概要」

- 6.9項「UDDI」

- 6.10項「仮想環境へのデプロイ」

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

次の項では、一般的なデプロイメント・トポロジについて説明します。

6.1.1 開発システムとQAシステム

本番システムには、複数の開発システムが存在することがあります。たとえば、エンタープライズESB本番システムの各部門がそれぞれ別個のプロジェクトを持ち、そのプロジェクト・チーム用の開発システムがある場合などです。一般に、開発システムにはQAシステムが関連付けられています。2つのシステムの関係は、1対1です。

6.1.2 ステージ・システムと本番システム

一般に、ステージ・システムは本番システムに関連付けられています。2つのシステムの関係は、1対1です。ステージ・システムはできるだけ本番システムを反映するようになっています。通常、開発システム(またはQAシステム)と本番システム(またはステージ・システム)の関係は多対1です。

6.1.3 共有プロジェクト

より複雑なデプロイメント・トポロジでは(大規模組織で部門ごとに開発システムがある)、スキーマ、変換、共有サービスなどの全社的な標準を共有プロジェクトに入れることができます。このシナリオに対処するには、共有プロジェクト用の別個の開発システムを作成し、各部門の開発システムに共有プロジェクトの読取り専用コピーを用意します。共有リソースが変更された場合、必要なリソースをインポートおよびエクスポートすることで、すべての部門システムが更新されます。

リソースをステージ・システムまたは本番システムにデプロイする際は、デプロイメントの失敗を招く可能性のあるセマンティク・エラーを回避するために、共有プロジェクトとともに、影響を受けるすべての部門プロジェクトをデプロイする必要があります。

時として、共有プロジェクトが複数の本番システムで共有されていることがあります。各部門に別個の本番システムがあり、それが企業のESBネットワークに相互接続されていて、スキーマなどの全社的なアセットがすべての本番システムで共有されている場合などです。

図6-1 複雑なトポロジ

「図6-1 複雑なトポロジ」の説明

6.2 デプロイメント・タイプ

デプロイメントの標準的な単位は、プロジェクトと呼ばれます。プロジェクト・デプロイメントには2つのタイプがあります。

- 完全 - プロジェクト全体がデプロイされます。

- 増分 - 最後のデプロイメント以降のプロジェクトへの変更、または明示的に選択されたリソースのサブセットのみがデプロイされます。
増分デプロイメントは付加的なデプロイメントで、新規リソースおよび更新されたリソースのみがターゲット・システムにデプロイされます。プロジェクトで削除されたリソースは、ターゲット・システムからは削除されません。ただし、完全プロジェクト・デプロイメント時に削除されたプロジェクト・リソースは、ターゲット・システムからも削除されます。

注意:

この動作は、インポート時にカスタマイズできます。たとえば、アラート宛先は本番システムで本番システム・オペレータによって定義されますが、開発システムにはこれらのアラート宛先が存在しません。このため、プロジェクトの完全デプロイメントを行う際に、アラート宛先を削除する必要がありません。

このドキュメントでは、主として、基本的なデプロイメント・タイプについて説明します。共有プロジェクトを使用するユースケースは、基本的なユースケースを拡張したものです。このドキュメントでは、スクリプトやプログラムによってリソースのエクスポートとインポートを自動化するユースケースについても説明します。

6.3 デプロイメントの役割

エクスポート、インポートおよび環境のカスタマイズは、システムに応じて、および企業の方針に応じて、デプロイ担当者、オペレータまたは管理者によって行われます。

開発システムからのエクスポートは、一般にデプロイ担当者によって行われます。管理者、オペレータまたはデプロイ担当者は、ステージ・システムから本番システムへのリソースのエクスポートとインポートを担当できます。

リソースのエクスポートとインポートは、Oracle Service Bus管理コンソールを使用して、またはスクリプトやプログラム(開発者が記述可能)を使用して実行できます。

オペレータがシステムからのリソースのエクスポートを担当する場合、定義済の自動化スクリプトまたはプログラムを実行して、プロジェクト全体またはプロジェクト内の特定リソースをエクスポートできます。同様に、オペレータがシステムへのリソースのインポートを担当する場合、定義済の自動化スクリプトまたはプログラムを実行して、インポートを行うことができます。

6.4 カスタマイズ・ファイル

管理者はカスタマイズ・ファイルを使用して、環境値やリソース内の参照を変更します。カスタマイズ・ファイルには、選択したリソース内で使用されているすべての環境値に対するカスタマイズを含めることができます(たとえば、EnvValueTypesclass内で定義された複合型の環境値)。さらに、リソース内での依存関係を持つリソース参照を変更するための、参照型のカスタマイズも含めることができます。

カスタマイズのタイプを表すカスタマイズ・スキーマ(Customization.xsd)は、Oracle Service Busインストールの次の場所にあります。

OSB_ORACLE_HOME\modules\com.bea.common.configfwk_version.jar

Oracle Service Bus管理コンソールからサンプル・カスタマイズ・ファイルを作成できます。カスタマイズ・ファイルには、プロジェクトまたはプロジェクト内の個々のリソースを含めることができます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のカスタマイズ・ファイルの作成に関する項を参照してください。

エクスポートまたはインポート・プロセスで環境の実際値を指定することで、作成したサンプル・カスタマイズ・ファイルを、必要な変更を加えるための開始点として使用できます。

6.4.1 環境値の置換

デプロイメントの一環として、エクスポート・プロセスまたはインポート・プロセスで、ターゲット・システムで適用される値にあわせて、ソース・システム内のリソースの環境値を変更する必要があります。

環境値とは、多くの場合ドメイン間での構成の移動(テスト環境から本番環境への移動など)に伴って変化する値で、構成データに含まれる特定の事前定義されたフィールドです。環境値は、URL、URI、ファイル名、ディレクトリ名、サーバー名、電子メールなどのエンティティを表します。また、環境値は、アラート宛先、プロキシ・サービス、ビジネス・サービス、SMTPサーバーおよびJNDIプロバイダのリソース、UDDIレジストリ・エントリで検索できます。

一部の環境値は複合XMLオブジェクトであり、Oracle Service Bus管理コンソールの「検索置換」オプションでは検索と置換を実行できません。ただし、スクリプトからALSBConfigurationMBeanを使用して、これらの環境値を直接設定できます。ALSBConfigurationMBeanの詳細は、Oracle Fusion Middleware Oracle Service Bus Java APIリファレンスを参照してください。複合型の環境値は、APIで設定するほか、カスタマイズ・ファイルを使用して設定できます。

カスタマイズ・ファイルはXMLファイルで、任意のエディタで開いて、必要な環境値を置換できます。さらに、Oracle Service Bus管理コンソールまたカスタマイズ・ファイルで特定の環境値(複合XMLタイプでない)を検索して、新しい値と置換できます。これらの環境値を変数タイプまたはプロジェクトに基づいてフィルタリングして、検索範囲を調整できます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の環境値の検索と置換に関する項を参照してください。

注意:

環境値の置換後、カスタマイズ・ファイルを実行する必要があります。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のカスタマイズ・ファイルの実行に関する項を参照してください。

環境値の置換は、インポートまたはエクスポート・プロセスの一部として行うことができます。

6.5 リソースのエクスポート

エクスポート担当者は、増分デプロイメントを実行できるかどうかを確認する必要があります。実行できる場合、特定の時間以降(最後のデプロイメント後など)に変更または作成されたすべてのリソースを検索するスクリプトを記述して、リソースをエクスポートできます。

エクスポート担当者がOracle Service Bus管理コンソールを使用して、選択したリソースのみをエクスポートする場合(増分デプロイメントで)、リソースの最終更新時のタイムスタンプを確認して、エクスポートが必要なリソースのみを選択できます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のリソースのエクスポートに関する項を参照してください。

6.5.1 エクスポート時のリソースのカスタマイズ

リソースのインポートまたはエクスポート時には、リソースをカスタマイズできます(環境値の置換を含む)。リソースのエクスポート時に、次の手順を実行します。

1. セッションを開始します。

2. リソースをカスタマイズして、カスタマイズ・ファイルを実行します。

3. 必要なリソースをエクスポートします。

4. セッションを破棄して、元の値がソース・システムに保持されていることを確認します。エクスポートしたファイルには更新後の値が含まれるため、更新後の値がターゲット・システムに反映されます。

6.6 リソースのインポート

リソースは、Oracle Service Bus管理コンソールからインポートするか、またはスクリプトを使用してインポートできます。Oracle Service Bus管理コンソールを使用してリソースをインポートする方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のリソースのインポートに関する説明を参照してください。

スクリプトを使用する場合、スクリプトによってインポートJARがステージングされます。その後、ステージングされたインポートJARのデプロイ・プランをシステムから取得します。デプロイ・プランにはプロジェクト内のすべてのリソースを含める必要があります。また、これらのリソースをターゲット・システムで作成、削除、更新するのか、またはそのままの状態にするのかを指定する必要があります。一般にデプロイメント・プランは、環境固有のリソース(サービス・アカウントなど)をオーバーレイしないように、またはオペレータが管理するリソースをオーバーレイまたは削除しないように、スクリプトによってカスタマイズされます。

6.6.1 インポート時のリソースのカスタマイズ

リソースのインポートまたはエクスポート時には、リソースをカスタマイズできます(環境値の置換を含む)。リソースのインポート時に、次の手順を実行します。

1. セッションを開始します。

2. 必要なリソースをインポートします。

3. リソースをカスタマイズして、カスタマイズ・ファイルを実行します。

4. セッションをアクティブ化します。

インポート時に、環境変数を保持して、インポート時に作成されたリソースの環境値のみがカスタマイズ・ファイルでカスタマイズされるようにできます。

6.6.2 操作値のインポート

Oracle Service Busには、グローバル操作設定と、プロキシ・サービスとビジネス・サービスの操作値とアラート、の2つのタイプの操作値があります。グローバル操作設定は、システム・プロジェクト・フォルダの下にあるリソースです。グローバル操作設定リソースは、他のリソースと同じようにエクスポートできます。インポート時に、このリソースは更新のみ可能で、作成または削除はできません。

インポート時には、Oracle Service Bus管理コンソールで「操作値の保持」オプションを選択して、ターゲット・システムで操作値を保持できます。

注意:

時として、オペレータがSLAアラートのアラート宛先を定義することがあります。これらはオペレータが管理するリソースであり、デプロイメント時にオーバーレイまたは削除することはできません。

6.6.3 アクセス制御ポリシーのインポート

一般に、アクセス制御ポリシーは環境ごとに異なります。この場合、インポート時にアクセス制御ポリシーをオーバーレイしないオプションを指定して、インポート時にアクセス制御ポリシーが失われないようにします。ただし、正しいアクセス制御ポリシーがステージング環境で設定され、本番環境に適用されることもあります。このような場合、アクセス制御ポリシーはサービスとともにインポート/エクスポートされます。

6.6.4 Oracle WebLogic Serverアーティファクトのデプロイ

理想を言えば、構成を完了するのに必要なOracle WebLogic Serverアーティファクトが不足している場合、デプロイメントは失敗すべきです。

インポート時にチェックされるものもあれば、インポート時にチェックされず(ビジネス・サービスのリクエスト・キューなど)、実行時エラーが発生するものもあります。

ベスト・プラクティスは、デプロイされたサービスおよびアラート宛先の環境値をデプロイメント・スクリプトで取得し、特定リソースがOracle WebLogic Serverにあるかどうかをチェックすることです。ない場合、デプロイメントは失敗します。管理者は、オペレータがスクリプトを再実行する前に、これらのリソースを定義する必要があります。

より限定的な方法として、アーティファクトをセッションにインポートし、セマンティク・エラーを探すこともできます。セマンティク・エラーは、Oracle Service Busで設計時にOracle WebLogic Serverリソースの存在をチェックする場合に発生します。

6.7 グローバル・リソースの移行

グローバル・リソースにはUDDIレジストリ・リソース、JNDIプロバイダ・リソース、およびSMTPサーバー・リソースがあります。これらのリソースは、通常、テスト環境では、ステージング環境や本番環境とは異なる値を使用します。テスト環境から本番環境にデプロイメントを移行する場合、次の方法のいずれかを使用します。

1. 本番ドメインで、テスト環境と同じ名前で新しいグローバル・リソースを作成します。または、テスト環境からグローバル・リソースを直接インポートして、カスタマイズします(手動で作成するよりも時間がかかりません)。
同一環境リソース(SMTPサーバーなど)の名前が環境内で異なる場合があります。これは、インポート・スクリプトによって、インポート・プロセスの一部としてこれらのリソースへの参照をマッピングすることで対処できます。

2. テスト環境からアーティファクトをエクスポートするときに、グローバル・リソースを除外します。次にconfig.jarファイルだけインポートします。アラート宛先、JNDIプロバイダ、またはSMTPプロバイダを参照するconfig.jarファイルにリソースが含まれている場合、インポートが完了すると、これらの参照は所定の場所に配置されます。
ターゲット・システムに資格証明が上書きされないように、インポートに資格証明を保存するオプションを選択します。

3. または、すべてのアーティファクト(グローバル・リソースを含む)をエクスポートし、config.jarファイルをインポートするときに、グローバル・リソースを除外します。

6.8 基本的なデプロイメントのベスト・プラクティスの概要

Oracle Service Busリソースのデプロイメントで推奨される基本的なベスト・プラクティスの概要を、次に示します。

- プロジェクトの名前は変更しないようにします。名前の変更が必要な場合は、次のデプロイメントを行う前に、デプロイメント、QA、ステージおよび各本番システムで同時に変更します。

- 環境固有のリソースの操作は、インポート時にフィルタで適切に除去されます。管理者はインポート・プロセスを開始する前に、このようなリソース(インポート・ファイルで参照される)をターゲット・システムで定義できます。新たな環境固有のリソースをデプロイして、インポート後に環境にあわせてカスタマイズすることもできます。

- オペレータが管理する操作リソースが、インポートの影響を受けないようにします。インポート時にこうしたリソースを識別するために、ネーミング・ルールまたは専用フォルダを使用できます。

- 単一のカスタマイズ・ファイルにすべてのプロジェクト・リソースのカスタマイズが入っている場合、インポートされたリソースにのみカスタマイズを適用します。インポート時に環境値を保持して、インポート時に追加されたリソースにのみカスタマイズを適用することもできます。

- エクスポート時に、エクスポート担当者は、リソースが削除、名前変更または削除されているかどうか、および最後のエクスポート以降、アーティファクトのプロジェクト再編成があったかどうかを確認する必要があります。これらの作業が行われていた場合は、完全デプロイメントを行う必要があります。行われていない場合、エクスポートが必要なリソースのみを選択して、増分デプロイメントを行うことができます。

- 環境間でグローバル・リソース(UDDIレジストリ、JNDIプロバイダ、SMTPサーバーなど)を移行するのに適した方法を使用します。

6.9 UDDI

UDDIレジストリにデプロイされたサービスを使用する際には、特別に考慮すべき事項があります。この項では、UDDIにパブリッシュされた、またはUDDIからインポートされたプロキシ・サービスおよびビジネス・サービスに関する情報を説明します。UDDI本番レジストリを使用すると、本番システムへのインポートが複雑になるため、十分な注意が必要です。

6.9.1 UDDIデプロイメント・トポロジ

環境に応じて、次のUDDIデプロイメント・トポロジを使用できます。

- 6.9.1.1項「開発専用レジストリ」

- 6.9.1.2項「本番専用レジストリ」

- 6.9.1.3項「開発および本番レジストリ」

- 6.9.1.4項「個別ドメイン別レジストリ」

6.9.1.1 開発専用レジストリ

最も簡易なUDDIデプロイメントでは、リソースのパブリッシュと検出の両方を行う、単一の開発(設計)時レジストリを使用します。このレジストリは、承認コントロールを使用したガバナンスに使用されます。ただし、別個の設計時パブリッシュ・レジストリおよび検出レジストリを持つこともできます。設計時パブリッシュ・レジストリでの承認後、リソースを検出レジストリに昇格させることができます。

6.9.1.2 本番専用レジストリ

本番レジストリ・トポロジでは、単一の本番UDDIレジストリにすべての本番ビジネス・サービスとプロキシ・サービス、およびその場所(URL)が含まれます。本番レジストリは、すべての本番サービスの検出に使用されます。ただし、別個の本番パブリッシュ・レジストリおよび検出レジストリを持つこともできます。本番パブリッシュ・レジストリでの承認後、リソースを本番検出レジストリに昇格させることができます。

本番レジストリを持つ主な理由は、動的なエンドポイント管理が可能であることです。リソースの自動同期を有効にすることで、UDDIレジストリ内のビジネス・サービスの場所を変更し、それをOracle Service Bus本番システムに自動的に反映させることができます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のUDDIを使用したサービスの自動同期に関する項を参照してください。

一般に、プロキシ・サービスはパブリッシュ・レジストリに自動的にパブリッシュされます。UDDIでの承認手順でサービスが却下された場合、UDDI承認者はそれを開発者に手動で通知します。開発者は適切な変更を行って、ステージ・システムおよび本番システムでサービスを再エクスポートする必要があります。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の自動パブリッシュの使用に関する項を参照してください。

本番ビジネス・サービスは本番検出レジストリからインポートされます。リソースの自動同期を有効にして、UDDIレジストリの変更内容がOracle Service Busに自動的に反映されるようにできます。ただし、ビジネス・サービスを本番レジストリから開発レジストリに手動でインポートする場合は、開発システムの値に準拠するように環境値を変更する必要があります。開発ビジネス・サービスはUDDIレジストリと自動的には同期されません。開発環境値は多くの場合、本番レジストリとは異なるためです。

6.9.1.3 開発および本番レジストリ

もう1つのアプローチは、別個の開発および本番UDDIレジストリを持つことです。このトポロジでは、開発レジストリで承認手順を実行できます。追加の開発UDDIレジストリにより、サイクル内で承認が早めに行われるようになります。

図6-2 複雑なトポロジ - UDDI

「図6-2 複雑なトポロジ - UDDI」の説明

6.9.1.4 個別ドメイン別レジストリ

プロキシ・サービスは、POJOコールアウトを使用してUDDIレジストリの動的な検索を実施し、必要な検索基準を満たすサービスを選択して、動的ルーティングのURLを取得することがあります。このシナリオでは、Oracle Service BusでダミーURLを持つダミー・サービスが定義され、このURLが検索後に実際の値と置き換えられます。このシナリオでは、環境ごとにUDDIレジストリが必要です。また、Oracle Service Busのダミー・ビジネス・サービスはどのUDDIサービスにもリンクされません。

このシナリオは、パフォーマンスと可用性に影響を及ぼします。このため、動的ルーティングに使用できるルーティング表のXQueryリソースを使用して、ビジネス・サービスとOracle Service Busとの自動同期を有効にするアプローチが適しています。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の動的ルーティングの使用に関する項を参照してください。

6.9.2 UDDIデプロイメントのベスト・プラクティスの概要

UDDIレジストリにデプロイされたサービスの使用で推奨されるベスト・プラクティスの概要を、次に示します。

- 特定のUDDIレジストリに関連するビジネス・サービスを特定のフォルダにまとめて、インポート時にこれらのリソースを容易に識別できるようにします。

- そのUDDIレジストリを使用するすべてのシステムで、同じUDDIサーバー・リソース名を使用します。別個の開発および本番UDDIレジストリがある場合、別個のUDDIレジストリの開発および本番インスタンスに同じリソース名を使用します。これにより、サービスによるサーバーへの参照が、インポート中に自動的に解決されます。

- 開発および本番UDDIレジストリを使用する場合、2つのレジストリ間で同じサービス・キーを保持します。
一般に、本番プロキシ・サービスに対して自動パブリッシュ・オプションが有効化され、ビジネス・サービスに対して自動同期オプションが有効化されます。サービスをUDDIレジストリから開発システムに手動でインポートする場合、サービスには引き続きソース・レジストリのUDDIキー情報とレジストリ・リソースへの参照が含まれます。開発サービスはステージ・システムまたはQAシステムに通常の方法でインポートされます。ステージ・システムおよびQAシステムのサービスにも、UDDIキーおよびサービスのソース・レジストリへのレジストリ参照が含まれます。このため、これらのシステムで、「サービスが同期されていない」または「サービスを削除する必要がある」などのUDDI関連ステータス・メッセージが表示された場合は、無視してください。

2つのレジストリを使用する場合、開発レジストリと本番レジストリ内の同一サービスのキーが同じでないことがあります。同じキーを保持することが推奨されます。

- ビジネス・サービスの形状が変化した場合は、新しい形状で新たなUDDIサービスを作成します。

6.9.3 複数のシステム間でのリソースのインポートとエクスポート

Oracle Service Busで使用可能なUDDI関連リソースは、システム間でインポートまたはエクスポートできます。この項では、様々なUDDIデプロイメント・トポロジで考慮すべき情報を示します。すべてのトポロジにおいて、すべてのシステムで同じUDDIレジストリ・リソースが構成されています。ただし、ステージ・システムとQAシステムでは自動同期は有効化されません。

本番UDDIレジストリを使用する場合、いくつかの考慮事項があります。

- UDDIには、サービスの情報のサブセットのみが含まれます。このため、サービスに関する情報の中には、通常のインポート、エクスポート・プロセスを通じて本番システムに移動するものもあれば、UDDIレジストリとの同期から本番システムに移動するものもあります。この情報は、インポート時に注意深く管理する必要があります。

- サービスが設計時UDDIレジストリから開発システムに移動する際、本番UDDIレジストリ内の同等サービスを識別する方法があることが理想的です。これにより、インポート時に、サービスの情報を本番UDDIレジストリ内の同等サービスに確実にマージできます。

6.9.3.1 開発専用レジストリ

このシナリオでは、システム間で移動する際に、次の手順を実行する必要があります。

1. ビジネス・サービスをUDDIレジストリからデタッチします。

2. プロキシ・サービスの自動パブリッシュ・オプションを無効にします。これは、MBean APIを使用して、またはプロキシ・サービスの構成時にOracle Service Bus管理コンソールを使用して行います。

3. 必要に応じて、サービスに変更を加えます。

4. リソースを現在のシステムからJARに手動でエクスポートして、次のシステムにインポートします。

6.9.3.2 本番専用レジストリおよび開発および本番レジストリ

リソースを本番システムにインポートする場合、次のいずれかのシナリオを使用できます。

- 新しいサービスをシステムにインポートする(インポートJAR内のサービスのUDDIキーとUDDIレジストリは同じ)。

- 新しいサービスをシステムにインポートする(インポートJAR内のサービスのUDDIキーとUDDIレジストリは異なる)。

- 既存のサービスをシステムにインポートする

新しいサービスを本番システムにインポート。インポートJAR内のサービスのUDDIキーとUDDIレジストリは同じ

このシナリオでは、サービスをシステムにインポートし、次のいずれかを実行します。

- インポート・スクリプトを使用し、APIコールにより、現在のセッションで明示的にサービスのUDDI再同期を施行します。

- Oracle Service Busによるバックグラウンド再同期のために、インポートしたサービスにマークを付けます。
このオプションの欠点は、再同期が完了するまで、UDDI関連サービスのフィールドが不正確な可能性があることです。ただし、自動同期が有効化されている場合、不正確な時間は短くなります。

新しいサービスを本番システムにインポート。インポートJAR内のサービスのUDDIキーとUDDIレジストリは異なる

このシナリオでは、サービスをシステムにインポートし、次のいずれかを実行します。

- インポート・スクリプトで、APIコールにより、現在のセッションでサービスのUDDI再同期を明示的に施行します。サービスは、セッションがアクティブになった後で「同期保留」として表示されます。

- UDDIレジストリで一致するUDDIサービスが見つからなかったという理由で、サービスに削除マークを付けます。リソースを適切にカスタマイズしてから、カスタマイズ・ファイルを実行します。後で、Oracle Service Bus管理コンソールを使用して、UDDIレジストリからサービスをデタッチします。
このアプローチの欠点は、UDDIの他に、本番環境値もカスタマイズ・ファイルに含める必要がある点です。

レジストリからサービスをデタッチした後、UDDIレジストリからUDDI関連情報をダウンロードし、必要に応じて自動同期を有効にできます。

既存のサービスの本番システムへのインポート

このシナリオでは、次のいずれかを実行します。

- UDDIレジストリ(またはサービス・キーの面で同一のUDDIレジストリ)を使用する場合、インポート時に本番UDDIサービスをオーバーレイします。その後、APIコールにより、現在のセッションでサービスのUDDI再同期を施行できます。

- インポート・スクリプトを使用して、このサービスの本番システムへのインポートをスキップします。これは、UDDI本番キーが異なる場合のみのオプションです。
ただし、サービスのインポートをスキップすると、サービスの非UDDIソース・データが不正確な可能性があります。このため、最新のサービスをインポートするかわりに、本番サービス定義でこれらの情報を直接更新する必要があります。

6.10 仮想環境へのデプロイ

この項では、Oracle Virtual Assembly Builderを使用してOracle仮想環境(Oracle VM)にOracle Service Bus構成をデプロイする手順の概要を示します。

開始する前に、『Oracle Virtual Assembly Builderインストレーション・ガイド』および『Oracle Virtual Assembly Builderユーザーズ・ガイド』で説明されているように、Oracle Virtual Assembly Builderをインストールおよび構成します。『Oracle VM Managerインストレーション・ガイド』および『Oracle VM Serverインストレーション・ガイド』で説明されているように、Oracle VMをインストールおよび構成します。

インストールに次のコンポーネントが含まれていることを確認します:

- Oracle Virtual Assembly Builder Studio

- Oracle Virtual Assembly Builder Deployer

- Oracle VM Manager

- Oracle VMサーバー

仮想環境では、次のService Busデプロイメント・トポロジがサポートされています。

- 管理サーバーのみのトポロジ

- 管理サーバーおよび管理対象サーバー・トポロジ

- クラスタ・トポロジ

また、仮想環境では次のService BusおよびSOA Suiteドメイン・トポロジもサポートされています。

- 管理サーバー、Service Bus管理対象サーバーおよびSOA Suite管理対象サーバー

Service Busのデプロイメント・トポロジについては、1.2項「Oracle Service Busデプロイメント・トポロジ」を参照してください。クラスタ・トポロジについては、名前参照に失敗しないように、静的IPアドレスでホストを構成します。

Oracle Virtual Assembly Builderを使用して仮想環境にOracle Service Bus構成をデプロイするには:

1. Service Busドメインを使用してWebLogic ServerにService Bus構成を作成またはデプロイします。

2. Service Busドメインで構成ファイルのアーカイブを有効にします。
詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの構成ファイルのアーカイブに関する説明を参照してください。

3. Oracle WebLogic Server管理コンソールを使用して、ドメインのOracle WebLogic Serverに関する側面を構成します。
たとえば、必須のデータ・ソースを作成および構成します。正しく構成されていることをテストします。

4. 構成をエクスポートおよびバックアップします。

5. ドメインからService Bus構成を削除します。単なるアンデプロイはしないでください。それを削除する必要があります。

6. WebLogic Serverで信頼ストアを構成します。

注意:

現在サポートされている信頼ストアのタイプは、デモIDとデモ信頼のみです。WebLogic Serverの信頼ストアがカスタムIDまたはカスタム信頼の場合は、イントロスペクションの前にデモIDとデモ信頼に戻し、正しいキーストアまたは信頼ストアのタイプを各デプロイメント後に再構成する必要があります。

7. Service Busドメイン・ディレクトリから名前にスラッシュまたはバックスラッシュが入った一時ファイルを削除します。

8. 次のいずれかを実行します。

- Oracle Coherenceクラスタを使用しており、仮想マシンがDHCP IPアドレスを使用する場合は、Service Busがマルチキャスト・アドレス用に構成されていることを確認します(4.1項「手順1. 構成の前提条件への準拠」を参照してください)。

- Oracle Coherenceクラスタを使用し、仮想マシンが静的IPアドレスを使用する場合、ユニキャスト・アドレスに既知のアドレス(WKA)を構成します。詳細は、付録C「静的IPアドレスを使用した仮想環境の構成」を参照してください。

9. 現在ベース・ドメインにあるService Busプロジェクトをエクスポートします。エクスポートが完了してから、Service Busプロジェクトおよびリソース(UDDIレジストリ、JNDIプロバイダ、SMTPサーバーおよびプロキシ・サーバー・リソース)を削除します。
Service Busコンポーネントをエクスポートおよび削除する手順については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』(Eclipseを使用する場合)または『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』(Service Busコンソールを使用する場合)を参照してください。

10. Oracle Virtual Assembly Builder CLIコマンドまたはAssembly Builder StudioでWebLogic Serverイントロスペクション・プラグインを使用して、Service Busドメイン(Service Bus構成を削除したドメイン)の外部に新しいWebLogic Serverアセンブリを作成します。
コマンドライン・インタフェースおよびAssembly Builder Studioでの作業の手順は、『Oracle Virtual Assembly Builderユーザーズ・ガイド』を参照してください。

11. コマンドライン・インタフェースを使用する場合、次の手順を実行して、アセンブリを作成します。:

- introspectWLSコマンドを使用して、ドメイン情報を取得します。

- createAssemblyコマンドを使用して、空のアセンブリを作成します。

- addToAssemblyコマンドを使用して、イントロスペクトされたアセンブリを新しいアセンブリに追加します。

- createExternalResourcesコマンドを使用して、外部参照を外部リソース・エンドポイントにマッピングします。

- クラスタ・トポロジにOHSをイントロスペクトする場合、connectEndpointsコマンドを使用して、Oracle HTTP Server (OHS)およびWLS間でのエンドポイント接続を作成します。

12. Oracle Virtual Assembly Builderを使用して、デプロイメント・テンプレートを作成し、アセンブリ・アーカイブをアップロードし、Oracle VMにアーカイブを登録して、アセンブリをデプロイします。このプロセス中に、データベースおよび認証プロバイダなどの外部リソースへリンクする必要がある場合があります。
これらの手順については、『Oracle Virtual Assembly Builderユーザーズ・ガイド』を参照してください。

13. アセンブリがデプロイされてから、仮想環境のデプロイ済のWebLogic ServerアセンブリにService Bus構成を手動でデプロイします。

注意:

仮想環境のWebLogic Serverインスタンスは、localhostではなく、仮想マシンのIPアドレスのみをリスニングしている可能性があります。その場合、Service Bus構成でlocalhostを使用するURIを変更する必要がある場合があります。

14. 必要に応じて、前の手順でエクスポートしたService Busプロジェクトをインポートして、必須のリソースを再作成します。

A デプロイメントAPIの使用

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

Oracle Service Bus MBeansをJavaプログラムおよびWLSTスクリプトで使用すると、開発環境からテスト環境、ステージング環境を経て、最終的に本番環境に至るまで、Oracle Service Bus構成のプロモーションを自動化できます。次のOracle Service Bus MBeanを使用すると、デプロイメント処理をプログラムで実行できます。

- SessionManagementMBean: セッションの作成、アクティブ化、破棄、または既存のセッションの名前を返すために使用します。

- ALSBConfigurationMBean: Oracle Service Bus構成のインポートとエクスポート、環境固有の情報(エンドポイントURIなど)の更新、およびOracle Service Bus構成およびリソースの問合せに使用します。

後者のMBeanは、 com.bea.wli.sb.management.configuration パッケージのインタフェースです。

デプロイメント時に様々なカスタマイズ・オプションを適用できます。様々な環境変数を使用して、環境を移行する際の設定を保持または調整することが可能です。

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

- A.1項「プログラムとスクリプトを使用したセッションの管理」

- A.2項「プログラムとスクリプトを使用した構成タスクの管理」

ヒント:

Oracle Service Bus APIは、Oracle Fusion Middleware Oracle Service Bus Java APIリファレンスに説明されています。

A.1 プログラムとスクリプトを使用したセッションの管理

Oracle Service Busセッションを使用すると、異なるユーザーが相互に干渉することなく構成データの個々の部分を更新できます。セッションは基本的に名前付きのサンドボックスで、行った変更はアクティブ化されるまでは、他のユーザーおよびコア・データ(Oracle Service Busの動作の基盤となっているデータ)によって抽出されます。リソースとOracle Service Bus構成を変更するには、セッションを作成し、作成したセッションで変更を実行する必要があります。セッションをアクティブ化した場合にのみ、変更はコア・データに反映されます。セッションの名前が同じでない限り、複数のセッションを作成できます。セッションは、そのセッション・データで動作するSessionManagementMBeanのインスタンスを使用した場合のみアクティブ化できます。

各MBeanタイプ(SessionManagementMBeanを除く)には、セッションごとに1つのインスタンスがあります。セッションが作成されると、新しい一連のMBeanインスタンス(MBeanタイプごとに1つ)が自動的に生成されます。各MBeanタイプのインスタンスは、Oracle Service Busデータ・キャッシュに保存されているコア・データで動作します。セッションが破棄またはアクティブ化されると、セッションに作成されたMBeanインスタンスは破棄されます。ただし、コア・データで動作するMBeanインスタンスは破棄されません。コア・データで動作するMBeanインスタンスでは、更新操作はサポートされていません。

A.1.1 セッションの作成、アクティブ化、破棄、検索

Oracle Service Busセッションは、Oracle Service Bus管理コンソールを使用して作成されます。SessionManagementMBeanインタフェースのメソッドは、Oracle Service Bus管理コンソールで提供されている対話機能と同等の機能であり、対応するGUIと同じ順序で実行する必要があります。次の表に、SessionManagementMBeanインタフェースで使用できるメソッド、およびメソッドによって実行されるタスクを示します。

表A-1 セッション管理メソッド

内容

使用するメソッド

セッションをアクティブ化する

activateSession(String session, String description)

ユーザー指定の名前が付いた新しいセッションを作成します。

createSession(String session)

変更をアクティブ化せずにセッションを削除する

discardSession(String session)

指定のセッション名が付いたセッションが存在する場合、trueを返す

sessionExists(String session)

SessionManagementMBeanインタフェースのリファレンス資料、Javaの使用例、およびJavaクライアントやスクリプトでMBeanを使用する方法を示したサンプル・コードについては、Oracle Fusion Middleware Oracle Service Bus Java APIリファレンスのcom.bea.wli.sb.management.configurationパッケージにあるSessionManagementMBeanインタフェースを参照してください。

A.1.1.1 例

Oracle Fusion Middleware Oracle Service Bus Java APIリファレンスのcom.bea.wli.sb.management.configurationパッケージにあるSessionManagementMBeanインタフェースには、セッションの作成方法、セッションを作成するためのSessionManagementMBeanの取得方法、および作成されたセッションおよびコア・データで動作させるためのALSBConfigurationMBeanの取得方法などを示すサンプル・コードが含まれます。

A.2 プログラムとスクリプトを使用した構成タスクの管理

Oracle Service Bus ALSBConfigurationMBeanを使用すると、Oracle Service Busドメインで、リソースの問合せ、エクスポートおよびインポート、検証エラーの取得、環境値の取得と設定、およびリソース構成の全般的な管理をプログラムで行うことができます。Oracle Service Bus構成は、プロキシ・サービス、WSDL、ビジネス・サービスなど、Oracle Service Busリソースを含む単純なJARとしてパッケージ化されています。これらのリソースは、複数のプロジェクトにまたがるものにしたり、構成情報の一部だけを含めたりできます。たとえば、プロジェクトのサブセットだけをエクスポートしたり、プロジェクト全体をエクスポートしたり、多数のプロジェクトのリソースのサブセットをエクスポートしたりできます。

次の項では、ALSBConfigurationMBeanを使用してJavaクライアントからこれらのデプロイメント・アクティビティを実行する方法を説明します。

- A.2.1項「構成のインポート、エクスポートおよび問合せ」

- A.2.2項「環境固有の情報の更新」

ALSBConfigurationMBeanインタフェースのリファレンス資料については、Oracle Fusion Middleware Oracle Service Bus Java APIリファレンスのcom.bea.wli.sb.management.configurationパッケージにあるALSBConfigurationMBeanインタフェースを参照してください。

A.2.1 構成のインポート、エクスポートおよび問合せ

Oracle Service Bus構成はOracle Service Bus管理コンソールで作成され、エクスポートにより.jarファイルに格納されます。構成.jarファイルをエクスポートしたら、その構成を別のOracle Service Busドメインにインポートし、構成の環境固有の値を新しい環境の値にあわせて変更して、構成をプロモートできます。

ALSBConfigurationMBeanインタフェースのメソッドを使用すると、Oracle Service Busドメインで次のようなリソースの管理を行うことができます。

- リソースを問い合せ、エクスポート、およびインポートします(zipファイルからのリソースのインポート、およびプロジェクト・レベルでのリソースのエクスポートを含みます)。

- 環境値の取得と設定

- 新しいIDを持つプロジェクト、フォルダ、またはリソースのクローンを作成します。

- 指定したリストにあるすべてのリソースからの既存の参照を、新しい参照のセットに変更します。

- 複数のプロパティを同時にカスタマイズします。

- 検証エラーを取得します。

ALSBConfigurationMBeanメソッドの包括的なメソッド概要については、Oracle Fusion Middleware Oracle Service Bus Java APIリファレンスのALSBConfigurationMBeanを参照してください。

A.2.2 環境固有の情報の更新

ALSBConfigurationMBeanおよびCustomizationクラスのメソッドを使用して、環境固有の情報を更新できます。次の内容が含まれます。

- プロキシ・サービスとビジネス・サービスの構成のエンドポイントの値を更新します。

- ファイル、電子メール、およびFTPトランスポート構成のディレクトリ要素を更新します。

- 環境値を直接設定します。

- 問合せに指定されている環境固有の値を検索します。

- 問合せに指定されている環境値を検索し、環境値パターンに一致するすべての値を特定のパラメータに置き換えます。

メソッドの包括的なメソッド概要については、Oracle Fusion Middleware Oracle Service Bus Java APIリファレンスのALSBConfigurationMBeanおよびCustomizationクラスを参照してください。インポートのカスタマイズは ALSBImportPlanによってサポートされています。

セキュリティ構成と他のすべての環境固有の設定は、Oracle Service Bus管理コンソールを使用して対話的に更新する必要があります。環境固有の構成については、2.4項「手順4. Oracle Service Bus構成のデプロイ」を参照してください。

A.2.2.1 例

Oracle Fusion Middleware Oracle Service Bus Java APIリファレンスのcom.bea.wli.sb.management.configurationパッケージにあるALSBConfigurationMBeanインタフェースには、Oracle Service Busの構成のインポートおよびエクスポートの方法、環境値の変更方法、リソースの問合せ方法などを示すサンプル・コードが含まれます。

A.2.3 関連トピック

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

B Oracle Service Busデプロイメントのリソース

この章では、Oracle Service Busドメインの拡張テンプレートを使用してドメインを拡張したときに、ドメインに追加されるOracle Service Busデプロイメントのリソースについて説明します。

Oracle Service Bus管理コンソールとUDDIマネージャは、管理サーバー上で動作します。そのため、管理サーバーを実行して、Oracle Service Busを管理し、UDDIレジストリへのパブリッシュやUDDIレジストリからのインポートを容易に行えるようにする必要があります。

B.1 Oracle Service Busドメイン拡張テンプレート

Oracle Fusion Middleware構成ウィザードまたはWLSTを使用して、容易にベースのOracle WebLogic Serverドメインを拡張し、Oracle Service Busドメインを作成できます。これは、Oracle Service Bus拡張テンプレートで提供されているリソースおよびサービスを、ベースのOracle WebLogic Serverドメインに追加することで行えます。

注意:

グラフィカル・モードでOracle Fusion Middleware構成ウィザードを使用すると、「ドメイン・ソースの選択」ウィンドウの「Oracle Service Bus」チェック・ボックスを選択して、新しいOracle Service Busドメインを容易に作成できます。結果は、最初にベースのOracle WebLogic Serverドメインを作成してから、Oracle Service Bus拡張テンプレートを使用してそのドメインを拡張する場合と同じです。Oracle Service Busドメインの作成に必要なテンプレートの詳細は、『Oracle Fusion Middlewareドメイン・テンプレート・リファレンス』のテンプレート間の関係に関する項を参照してください。

B.1.1 生成されるドメイン出力

次の表は、Oracle Service Bus拡張テンプレートをベースのOracle WebLogic Serverドメインに適用することで生成される、デフォルトのディレクトリ構造とファイルを定義しています。特に指定がない限り、Oracle Fusion Middleware構成ウィザードではデフォルトでMW_HOME\user_projects\domains\base_domainディレクトリにこのドメインが作成されます。デフォルトの構成設定を変更すると、その出力ディレクトリ構造は、ここで示したディレクトリ構造と異なる場合があります。

表B-1 Oracle Service Bus拡張テンプレート適用後のドメイン

ディレクトリ

ファイル

説明

user_projects\domains\your_domain\

fileRealm.properties

互換性セキュリティの使用時にデフォルトのセキュリティ・レルムで使用可能なACL、ユーザー、およびグループを格納したファイル。

user_projects\domains\your_domain\

derby.ini

Apache Derby JDBCデータベースの初期化情報を格納したファイル。

user_projects\domains\your_domain\

startWebLogic.cmd

startWebLogic.sh

WindowsおよびUNIXシステムで管理サーバーを起動する際にそれぞれのシステムで使われるスクリプト。

user_projects\domains\your_domain\

URLs.dat

JDBCデータベースのURLを格納したファイル。

user_projects\domains\your_domain\

alsbdebug.xml

configfwkdebug.xml

ドメインのデバッグ・パラメータを格納したファイル。すべてのプロパティのデフォルト設定はfalseです。

autodeploy\

readme.txt

ディレクトリに関する情報を提供するファイル。このディレクトリは初期状態では自動デプロイメントのプレースホルダーとして機能します。

bin\

setDomainEnv.cmd

setDomainEnv.sh

WindowsおよびUNIXシステムの開発環境をそれぞれ設定するために使われるスクリプト。

bin\

startManagedWebLogic.cmd

startManagedWebLogic.sh

WindowsおよびUNIXシステムで管理対象サーバーを起動する際にそれぞれのシステムで使われるスクリプト。

bin\

startDerbyConsole.cmd

startDerbyConsole.sh

WindowsおよびUNIXシステムでApache Derbyコンソールを起動する際にそれぞれのシステムで使われるスクリプト。

bin\

startWebLogic.cmd

startWebLogic.sh

WindowsおよびUNIXシステムで管理サーバーを起動する際にそれぞれのシステムで使われるスクリプト。

bin\

stopManagedWebLogic.cmd

stopManagedWebLogic.sh

WindowsおよびUNIXシステムで管理対象サーバーを停止する際にそれぞれのシステムで使われるスクリプト。

bin\

stopWebLogic.cmd

stopWebLogic.sh

WindowsおよびUNIXシステムで管理サーバーを停止する際にそれぞれのシステムで使われるスクリプト。

config\

config.xml

管理サーバーで使用される構成情報を格納したファイル。

config\deployments\

readme.txt

ディレクトリに関する情報を提供するファイル。このディレクトリは初期状態ではプレースホルダーとして機能し、その後、アプリケーションのステージング・モードが「staged」の場合に、アプリケーションのステージング用に使用されます。

config\diagnostics\

readme.txt

ディレクトリに関する情報を提供するファイル。このディレクトリは初期状態ではプレースホルダーとして機能し、その後、WebLogic診断フレームワーク(WLDF)のインストゥルメンテーションに関連付けられたシステム・モジュールを格納するために使用されます。

config\jdbc\

readme.txt

ディレクトリに関する情報を提供するファイル。このディレクトリは初期状態ではプレースホルダーとして機能し、その後、(JSR-88とは異なり) JMXから直接構成できるグローバルJDBCモジュールを格納するために使用されます。

config\jdbc\

wlsbjmsrpDataSource-jdbc.xml

Oracle Service Busドメイン用のグローバルな非XA JDBCデータ・ソース・モジュール。

config\jms\

readme.txt

ディレクトリに関する情報を提供するファイル。このディレクトリは初期状態ではプレースホルダーとして機能し、その後、(JSR-88とは異なり) JMXから直接構成できるグローバルJMSモジュールを格納するために使用されます。

config\jms\

wseejmsmodule-jms.xml

Web Services Reliable Messaging (WS-RM)のJMSリソースを格納した構成ファイル。

config\jms\

xbusResources-jms.xml

Oracle Service Busドメイン用のグローバルJMSモジュール。

config\lib\

readme.txt

ディレクトリに関する情報を提供するファイル。このディレクトリは初期状態ではプレースホルダーとして機能し、その後、サーバーのJava仮想マシンが起動したときにサーバーのシステム・クラスパスに追加されるJARファイルを格納するために使用されます。

config\nodemanager\

nm_password.properties

ノード・マネージャ・パスワード・プロパティの値を含むファイル。

config\security\

readme.txt

ディレクトリに関する情報を提供するファイル。このディレクトリは初期状態ではプレースホルダーとして機能し、その後、セキュリティ・フレームワーク用のシステム・モジュールを格納するために使用されます。このディレクトリには、ドメインの現在のレルムにおける各タイプのセキュリティ・プロバイダごとにセキュリティ・プロバイダ構成拡張が1つずつ含まれます。

config\startup\

readme.txt

ディレクトリに関する情報を提供するファイル。このディレクトリは初期状態ではプレースホルダーとして機能し、その後、起動プランを含んだシステム・モジュールを格納するために使用されます。起動プランは、サーバー起動の一部に使用できるシェル・スクリプトを生成するために使用されます。

console-ext\

readme.txt

ディレクトリに関する情報を提供するファイル。このディレクトリは初期状態ではOracle WebLogic Server管理コンソールに対するカスタム拡張用のプレースホルダーとして機能します。

init-info\

domain-info.xml

ドメインの作成と拡張の情報を識別するために使用されるファイル。情報は、ドメイン内のコンポーネントのID、ドメインで使用されるJDKとアプリケーション・ディレクトリの場所、ドメインの作成と拡張に使用されるテンプレートなどです。

init-info\

security.xml

ドメイン・リソースへのIDとアクセスを確立するユーザー・グループとロールを作成するために使用されるファイル。

init-info\

startscript.xml

ドメインのルート・ディレクトリおよびbinディレクトリに配置される*.cmdファイルおよび*.shファイルを作成するために使用されるファイル。

init-info\

tokenValue.properties

起動スクリプトで指定されたトークンを置き換える実際の値を含んでいるファイル。

lib\

readme.txt

ディレクトリに関する情報を提供するファイル。このディレクトリは初期状態ではドメインのライブラリ用のプレースホルダーとして機能します。このディレクトリ内のJARファイルは、サーバー起動時にサーバー・クラスパスの最後に動的に追加されます。

rmfilestore\

なし

永続メッセージと恒久サブスクライバを格納する、ディスク・ベースのファイル・ストアとして機能するディレクトリ。

security\

DefaultAuthenticatorInit.ldift

DefaultAuthorizerInit.ldift

DefaultRoleMapperInit.ldift

XACMLAuthorizerInit.ldift

XACMLRoleMapperInit.ldift

認証(ユーザーとグループ)、認可、ロール・マッピングなどのブート・ストラップ処理で使用されるファイル。これらのファイルには、LDAP固有の情報が収められています。

注意: このリリースを使用して作成したWebLogicドメインは、デフォルトでXACMLプロバイダを使用します。それらのXACMLセキュリティ・プロバイダは、WebLogic認可プロバイダ(DefaultAuthorizer)およびWebLogicロール・マッピング・プロバイダ(DefaultRoleMapper)で作成したポリシーやロールに対して互換性があります。

security\

SerializedSystemIni.dat

暗号化されたセキュリティ情報を格納したファイル。

servers\AdminServer\security\

boot.properties

サーバーの起動に必要なユーザー名やパスワードなど、サーバーの起動プロパティを格納したファイル(暗号化形式)。このファイルは、起動モードとして開発モードを選択した場合にのみ生成されます。

このファイルによって、サーバーの起動サイクル時におけるユーザー名とパスワードの入力を省略できます。

C 静的IPアドレスを使用した仮想環境の構成

この付録では、Oracle Coherenceクラスタが含まれる仮想環境をデプロイし、仮想環境で静的IPアドレスを使用する場合のOracle Service Busの構成方法について説明します。

静的IPアドレスを使用する場合、クラスタのユニキャスト・アドレスに既知のアドレス(WKA)を構成する必要があります。また、サーバーの起動時に使用する引数にService BusのCoherenceオーバーライドが含まれていることを確認する必要があります。

C.1 手順1: ディレクトリ構造の作成

WebLogic Admin Serverが実行中のコンピュータのルート・ディレクトリに次のディレクトリ構造を作成します。

/ovab
/scripts.d
/properties
/post-config.d

ルート・ディレクトリの下にディレクトリを作成する際に権限上の問題が発生する場合、ルート資格証明を持つユーザーとしてディレクトリを作成します。ディレクトリおよびそこに配置したファイルは、OVABイントロスペクションを実行するユーザーが読取り可能である必要があります。

C.2 手順2: プロパティ・ファイルの作成

プロパティ・ファイルは、Service BusのCoherenceオーバーライドを指定する2つのプロパティを定義します。

プロパティ・ファイルを作成するには:

1. 手順1で作成した/ovab/scripts.d/propertiesディレクトリにosb.userpropsという名前のファイルを作成します。

2. WKAアドレスの実際のサーバーIPアドレスのカンマ区切りリストに置き換えて、ファイルに次のテキストを追加します。

coherence.wkaaddresses=Host1,Host2,Host3,Host4..,HostN
coherence.wkaport=7890

プロパティ

説明

coherence.wkaaddresses

Oracle Service BusクラスタのサーバーのIPアドレスのカンマ区切りリスト

coherence.port

7890

3. ファイルを保存して閉じます。

4. ずべてのユーザーが実行権限を持つようにファイルの権限を変更します。

これらのカスタム・プロパティは、アセンブリのすべてのアプライアンスのOVABデプロイ・プラン・エディタで使用できるようになります。これらのプロパティはService Busクラスタ・アプライアンス用に編集する必要があります。

C.3 手順3: 構成ファイルの作成

bashシェルにはサンプル構成スクリプトが提供されています。

構成ファイルを作成するには:

1. 手順1で作成した/ovab/scripts.d/post-config.dディレクトリにosb-postconfig.shという名前のファイルを作成します。

2. 例C-1「サンプル構成ファイル」にテキストを追加します。

3. ファイルを保存して閉じます。

4. ずべてのユーザーが実行権限を持つようにファイルの権限を変更します。

例C-1 サンプル構成ファイル

#!/bin/bash
DEBUG_FILE=/tmp/osb-postconfig-$$.debug
/bin/rm -f $DEBUG_FILE
DEBUG=1

debug() {
if [ x$DEBUG=x1 ]; then
echo $1 >> $DEBUG_FILE
fi
}

CUSTOM_PROPS_DIR=$AB_CUSTOMPROPS_DIR
debug "CUSTOM_PROPS_DIR=$CUSTOM_PROPS_DIR"
OSB_PROPS_FILE=$CUSTOM_PROPS_DIR/osb.userprops
debug "OSB_PROPS_FILE=$OSB_PROPS_FILE"
OPWD=$PWD
cd $CUSTOM_PROPS_DIR/../..
CONTENT_RESDIR=$PWD

debug "CONTENT_RESDIR=$CONTENT_RESDIR"
if [ ! -f ./rehydrate.properties ]; then
debug "Rehydrate properties not found"
exit 1
fi

DOMROOT=$(grep WlsDomainRoot ./rehydrate.properties | sed 's/^.*=//')
if [ -z "$DOMROOT" ]; then
debug "Domain root cannot be identified"
exit 2
fi

OSB_DOMENV_FILE=$DOMROOT/bin/setOSBDomainEnv.sh
if [ ! -f $OSB_DOMENV_FILE ]; then
debug "OSB domain env file $OSB_DOMENV_FILE not found"
exit 3
fi
# Change to root
cd /

MYIP=$(/sbin/ip -f inet addr | awk '/eth0:/ { getline; sub(/\/..*$/,"",$2); print $2}')

if [ -z "$MYIP" ]; then
echo "VM IP address cannot be found for the eth0 interface"
exit 4
fi

MYHOST=$(hostname)

debug "MYIP = $MYIP"

START_ARGS=$(awk -v ip=$MYIP -v host=$MYHOST '
BEGIN {nhosts = 0 }
/coherence.wkaaddresses[     ]*=/ {
sub(/coherence.wkaaddresses[    ]*=/,"", $0)
n = split ($0, addr, /,/)
for (i = 1; i <= n && i < 10; ++i) {
a = addr[i] ""
gsub(/[    ]*/,"",a)
wka_arg = sprintf("%s -DOSB.coherence.wka%d=%s ", wka_arg, i, a )
}
nhosts=i - 1
host_arg = " -DOSB.coherence.localhost=" ip

}
/coherence.wkaport[     ]*=/ {
sub(/coherence.wkaport[    ]*=/,"", $0)
port = $0
for (i = 1; i <= nhosts && i < 10; ++i) {
port_arg = sprintf("%s -DOSB.coherence.wka%d.port=%d ", port_arg, i, port )
}
port_arg = sprintf("%s -DOSB.coherence.localhost.port=%d ", port_arg, port )
}
END {
start_args=sprintf("\"$EXTRA_JAVA_PROPERTIES %s %s %s\"", wka_arg, host_arg, port_arg)
print start_args
}
' $OSB_PROPS_FILE)

debug "START_ARGS = $START_ARGS"

if [ -z "$START_ARGS" ]; then
debug "No updates needed - Coherence cluster configuration not desired"
exit 0
fi

debug "Updating $OSB_DOMENV_FILE"
echo "EXTRA_JAVA_PROPERTIES=$START_ARGS" >> $OSB_DOMENV_FILE
debug "Done"

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