| Oracle Fusion Middleware Oracle Service Busアップグレード・ガイド 11g リリース1 (11.1.1.7.0) B61434-04 |
|
 前 |
この章では、Oracle Service Busの様々な構成アーティファクトをOracle Service Bus 11g リリース1 (11.1.1.7.0)にアップグレードする上での考慮事項について説明します。
内容は次のとおりです。
AquaLogic Service Bus 2.6構成を使用している場合は、次の項をお読みください。
AquaLogic Service Busコンソールで使用可能な多くのデザインタイム機能は、Oracle Service Bus統合開発環境(IDE)であるOracle Enterprise Pack for Eclipseで使用できます。
コンソールのかわりにIDEを使用する場合、AquaLogic Service Bus 2.6構成JARを11g リリース1 (11.1.1.7.0) IDEに直接インポートします。JARファイルの11g リリース1 (11.1.1.7.0) IDEへのインポートは、 『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のリソースのインポートに関する項を参照してください。
|
注意: どの構成JARを11g リリース1 (11.1.1.7.0) IDEにインポートしても操作設定および管理設定が削除されます。これらの設定を保持するには、まず構成JARファイルをコンソールにインポートしてから前述の説明に従ってエクスポートして11g リリース1 (11.1.1.7.0) IDEにインポートします。後で構成をIDEからコンソールに移行するときに、操作設定の保持を有効にすると、最初の手順でインポートした操作設定が保持されるようになります。 |
JARファイルのエクスポートについては、「タスク2: セキュリティ構成のエクスポート」を参照してください。
AquaLogic Service Bus 3.0以降のサービス・レベル合意(SLA)アラート・ルール機能は、以前のリリースとは若干異なります。これらの変更は、実行時の評価やアラートの発行方法には影響しません。ただし、以下の変更点に注意してください。
AquaLogic Service Bus 2.6では、アラート・ルール・リソースは個々のリソースとして作成され、個別に保持されていました。Oracle Service Bus 11g リリース1 (11.1.1.6.0)では、アラート・ルールはサービス定義に含まれています。アラート・ルールがサービス定義に含まれ、リソースそのものではなくなっているため、これはAquaLogic Service Busコンポーネントの「参照」ページと「参照先」ページでのアラート・ルールの表示に影響を及ぼしています。参照の表示方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「参照」ページの表示に関する項を参照してください。
様々な宛先に関するアラートの内容が少し変更されていることに注意してください。アラート宛先については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のアラート宛先に関する項を参照してください。
AquaLogic Service Bus 3.0以降では、アラート・ルールの名前を変更すると、元の名前でこれまでに発行されたアラートについて、コンソールの「アラート・サマリー」ページと「拡張SLAアラート履歴」ページのルール定義にアクセスできなくなります。
AquaLogic Service Busコンソールでアラート・ルールの各エントリを区別できたAquaLogic Service Bus 2.6以前のバージョンでは、プロキシ・サービスおよびビジネス・サービスからアラート・ルールを介したアラート宛先への参照が保持され、1つの参照として表示されます。たとえば、プロキシ・サービスで、複数のアラート・ルールと複数のパイプライン・アラート・アクションが同じアラート宛先を使用する場合、そのアラート宛先の「参照元」ページには、アラート宛先のエントリが1つだけ表示されます。詳細については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のアラート宛先に関する項を参照してください。
AquaLogic Service Bus 3.0以降のリリースでは、アラートは個別のリソースではなくなっているため、アラートからアラート宛先への参照を表示する方法がAquaLogic Service Bus 3.0以降のリリースとは異なります。Consoleの2つのページが影響を受けます。「アラート宛先」ページの「参照元」フィールドに、宛先を参照しているアラート・ルールが表示されなくなります。かわりに、「参照元」フィールドにアラートを含むサービスが表示されます。この二次的な影響として、同じアラート宛先を参照する複数のアラート(SLAアラートまたはパイプライン・アラート)がサービスに含まれている場合、関連付けられたサービスが「参照元」フィールドに1回だけ示されます。このページには、参照情報が含まれなくなっています。かわりに、関連付けられたサービスの「サービス・サマリー」ページの「参照」フィールドに参照先のアラート宛先が含まれています。詳細については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のアラート宛先に関する項を参照してください。
AquaLogic Service Bus 2.6以前と同様に、SLAアラートが構成された宛先に発行されると、アラートの詳細にルールIDが含まれます。ただし、AquaLogic Service Bus 3.0以降のリリースでは、ルールIDの値は親サービスの親サービスのグローバル名とアラート・ルール名の組合せに設定されます。SNMPトラップの場合、AquaLogic Service Bus 2.6以前と同様に、ルールIDは64文字に切り捨てられます。
AquaLogic Service Bus 2.6では、インポート時にアラートを既存のアラートとマージしていましたが、AquaLogic Service Bus 3.0以降のリリースでは、保持/上書きのセマンティクスが提供されます。この機能により、アラートの名前が同じかどうかに関係なく、既存のすべてのアラートを保持することも、上書きすることもできます。
この項で説明する手順を実行する前に、セキュリティ・レルムを構成する必要があります。
AquaLogic Service Bus 2.6からエクスポートされたJARには、アクセス制御ポリシーは含まれていません。Oracle Service Bus 11g リリース1 (11.1.1.7.0)では、AquaLogic Service Bus 2.6リリースから構成JARをインポートする前に、「インポート前」アクセス制御ポリシーを使用し、11g リリース1 (11.1.1.7.0)へのJARのインプレース・アップグレードを実行します。インプレース・アップグレードを実行するために、プリプロセッサが各プロキシ・サービスに管理可能なすべての認可プロバイダを問い合せて、適用可能なアクセス制御ポリシーのリストを取得します。次に、これらのポリシーをプロキシ・サービスのサービス定義に挿入します。これは、ベスト・エフォート・ベースで実行されます。
管理可能な認可プロバイダとは、PolicyEditorMBeanインタフェースを実装する認可プロバイダです。このようなプロバイダはOracle WebLogic ServerおよびOracle AquaLogic Service Busコンソールで格納されたポリシーを追加、変更、または削除できるようにする読込み/書込みAPIを公開します。
トランスポート・レベルのポリシーと、デフォルトのメッセージ・レベルのポリシーの場合、システムはPolicyEditorMBeanを公開しているプロバイダだけを問い合せて、適用可能なポリシーを取得し、それらのポリシーをサービス定義に挿入します。
操作メッセージ・レベルのポリシーの場合、システムはPolicyListerMBeanを実装しているプロバイダを問い合せることができます。プロバイダがPolicyListerMBeanインタフェースを実装していない場合、操作レベルのポリシーは取得されません。
インプレース・アップグレードが完了すると、認可プロバイダから取得したアクセス制御ポリシーを含め、構成JARが11g リリース1 (11.1.1.7.0)タイプであるかのように、インポート・プロセスが進行します。表3-1に、適用可能なパラメータとインポート・プロセスの結果の様々な組合せを示します。この結果はインポート・プロセスの結果であり、構成のインポート後に実行された内容を示しているわけではありません。
表3-1 適用可能なパラメータとインポートの結果
| インポートするconfig.jarのバージョン | プロキシ | コア・リポジトリ内のACL | ポリシーを保持 | セッションのサービス定義内のACL | 説明 |
|---|---|---|---|---|---|
|
2.6 |
新規 |
該当なし(いいえ) |
該当なし(いいえ) |
管理可能な認可プロバイダから取得 |
JARを11g リリース1 (11.1.1.7.0)にアップグレードします。このアップグレードには、管理可能なすべての認可プロバイダから適用可能なすべてのACLを取得することが含まれます。セッションのサービス定義には、認可プロバイダから直接取得した構成JARのACLが含まれます。 |
|
2.6 |
既存 |
いいえ |
いいえ |
管理可能な認可プロバイダから取得 |
JARを11g リリース1 (11.1.1.7.0)にアップグレードします。セッションのサービス定義には、認可プロバイダから直接取得した構成JARのACLが含まれます。 |
|
2.6 |
既存 |
いいえ |
いいえ |
なし |
JARを11g リリース1 (11.1.1.7.0)にアップグレードします。セッションのサービス定義には、ACLは含まれていません。 |
|
2.6 |
既存 |
はい |
いいえ |
管理可能な認可プロバイダから取得 |
JARを11g リリース1 (11.1.1.7.0)にアップグレードします。セッションのサービス定義には、認可プロバイダから直接取得した構成JARのACLが含まれます。 |
|
2.6 |
既存 |
はい |
はい |
構成フレームワーク内のコア・リポジトリから取得 |
JARを11g リリース1 (11.1.1.7.0)にアップグレードします。セッションのサービス定義には、コア・リポジトリのACLが保持されます。 |
ターゲットのOracle Service Bus 11g リリース1 (11.1.1.7.0)システムに認可プロバイダが存在しない場合、インポート・プロセスは認可プロバイダ用のインポート済ACLを無視して、警告を表示します。この場合、セッションを破棄するか、インポート・タスクを元に戻し、認可プロバイダをサーバーに追加してから再度インポートできます。また、Oracle Service Busこそでセキュリティ・パラメータのダミー更新操作を実行することもできます。この場合、システムによってベスト・エフォート・ベースで競合が自動修正されます。これらの変更はアトミックであり、セッションを破棄すれば元に戻すことができます。
セキュリティ・パラメータの更新の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド 』のメッセージ・レベルのセキュリティ構成に関する項を参照してください。
次の変更は、Oracle Service Bus 構成に影響を及ぼすことがあります。
AquaLogic Service Bus 2.6では、メッセージの再試行回数は、ビジネス・サービスのURIのリストに適用されます。Oracle Service Bus 11g リリース1 (11.1.1.7.0)では、再試行回数は個々のURLエンドポイントに適用されます。アップグレード・プロセスでは、2.6の動作が次のように維持されます。
new_retries = N-1 + old_retries*N
ここで、NはURIの総数を表し、old_retriesは2.6の再試行回数を表します。
たとえば、AquaLogic Service Bus 2.6でビジネス・サービスの3つのURLを構成しており、再試行回数が1回であるとします。2.6の再試行メカニズムでは、3つのURLがすべて試行されます。再試行の遅延後、3つのURLがすべて再試行されます。3.0で同じ動作を実現するために、再試行回数が5回に変更されます。これは、(3 -1) + (1*3) = 5という式を適用して取得された値です。最終的な結果はまったく同じです。つまり、3つのURLが1回試行され(5回の再試行のうち、2回を使用)、再試行の遅延後、3つのURLがもう一度試行されます(5回の再試行のうち、残りの3回を使用)。
構成されているURLが1つしかない場合は、以前の動作と新しい動作は同じであり、アップグレード時に再試行回数が変更されることはありません。
詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド 』のビジネス・サービス: 作成と管理に関する項を参照してください。
ビジネス・サービスをOracle Service Bus 11g リリース1 (11.1.1.7.0)にインポートするときに、インポート・プロセスで2.6構成の重複URIが削除されます。URIがランダムな重みベースのロード・バランシング・アルゴリズムを使用し、重みが設定されている場合、重みは適宜調整されます。たとえば、ビジネス・サービスが以下のURIと重みで構成されているとします。
URI_A 1
URI_B 3
URI_A 1
ビジネス・サービスを11g リリース1 (11.1.1.7.0)にアップグレードすると、このURIのセットは次のように変更されます。
URI_A 2
URI_B 3
ビジネス・サービスが他のアルゴリズムで構成されている場合は、アップグレード時に重複URIが削除され、その他の変更は行われません。
ロード バランシング アルゴリズムのパラメータの設定の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド 』のビジネス・サービス: 作成と管理に関する項を参照してください。
アウトバウンド・リクエストの送信時に配信エラーが発生した場合、Oracle Service BusではSOAPフォルトなどのアプリケーション・エラーのエンドポイントURIを再試行するかどうかを指定できます。これは、通信エラーの再試行には影響を及ぼしません。この新しいオプションは、ビジネス・サービスの「トランスポート構成」ページに用意されています。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド 』の「トランスポート構成」ページに関する項を参照してください。再試行回数を超えるとエラーが発生します。
2.6の動作を維持するには、デフォルト値をtrueに設定して新しいタグを追加します。
<xs:element name="retry-application-errors" type="xs:boolean" minOccurs="0"/>
このタグは、プロバイダ構成でdeclare-application-errorフラグがtrueに設定されているトランスポート・エンド・ポイントにのみ追加されます。
AquaLogic Service Bus 3.0以降のコンソールでは、HTTPとHTTPSの切替えを簡略化するために、HTTPSトランスポート構成が削除され、その機能が3.0のインバウンドHTTPトランスポート・プロバイダに追加されています。11g リリース1 (11.1.1.7.0)のHTTPトランスポート構成ページには、HTTPSを有効にするチェック・ボックスがあります。
新しい要素であるuse-httpsがHTTPトランスポートのインバウンド・プロパティのスキーマに追加されます。
<xs:element name="use-https" type="xs:boolean" minOccurs="0"/>
既存のHTTPSトランスポート構成は、このフラグがtrueに設定されたHTTPトランスポートにアップグレードされます。
|
注意: この機能を適用できるのは、HTTPプロキシ・サービスのみです。 |
以前のリリースでは、AquaLogic Service BusのトランスポートはAquaLogic Service Busコンソールからしか構成できませんでした。ALSB 3.0では、Eclipseでトランスポートを設計できます。詳細は、Oracle Fusion Middleware Oracle Service BusトランスポートSDKユーザー・ガイドのWorkshop for WebLogic用のOracle Service Busトランスポートの開発に関する説明を参照してください。
AquaLogic Service Bus 3.0を使用している場合は、次の項をお読みください。
AquaLogic Service Bus 3.0ワークスペースをOracle Service Bus Oracle Enterprise Pack for Eclipseにアップグレードするには、次の手順を実行します:
|
注意: ワークスペースをアップグレードすると、ALSB 3.0のWorkSpace Studio 1.1では開けなくなります。 |
ALSB 3.0でWorkSpace Studio 1.1を開始してアップグレードするワークスペースを開きます。
ALSBパースペクティブとすべてのエディタを閉じます。
すべてのプロジェクトを閉じます。
WorkSpace Studio 1.1を閉じます。
ワークスペースをバックアップします。
11g リリース1 (11.1.1.6.0)でOracle Enterprise Pack for Eclipseを起動し、アップグレードするワークスペースを開きます。
アップグレードが開始するのを待ちます。Oracle Enterprise Pack for Eclipse for Oracle Service Bus 11g リリース1 (11.1.1.7.0)でAquaLogic Service Bus 3.0ワークスペースを開く場合、アップグレード・プロセスが開始されるまで少し時間がかかります。アップグレードが完了して確認ダイアログが表示されるまで、ワークスペースを編集しないでください。
プロジェクトをアップグレードしたら、Oracle Service Busパースペクティブを開き、新しくアップグレードしたプロジェクトとアーティファクトで作業を続けます。
Oracle Service Bus 11g リリース1 (11.1.1.7.0)では、jndi-service-accountは非推奨です。11g リリース1 (11.1.1.7.0)にアップグレードした後、Oracle Service Bus Java Message Service (JMS)ビジネス・サービスはJMSおよびJNDIの両方のためにjms-service-accountを使用します。
Oracle Service BusのJMSビジネス・サービスでどのようにJNDIアカウントとJMSアカウントを移行するかを次の表に示します。
11g リリース1 (11.1.1.7.0)にアップグレードした後、パイプラインでのすべてのアクションに一意のIDが割り当てられます。
11g リリース1 (11.1.1.7.0)のプロキシ・サービスでは、新しいモニタリング・フラグを使用して、収集する統計のレベルを制御します。次の3つのレベルがあります。
Service - 大まかな統計。
Pipeline - AquaLogic Service Bus 3.0で収集されていた統計と同じレベル。
Action - 詳細な統計。
モニタリング・フラグの値はアップグレードによりPipelineに設定されます。
Oracle Service Bus 11g リリース1 (11.1.1.7.0)から、次の領域で検証ルールがより厳格になっており、その結果、設計時エラーまたは実行時エラーが発生する場合があります:
WSDLおよびサービスの検証の強化: 以前のリリースからOracle Service Bus 11g リリース1 (11.1.1.7.0)にアップグレードすると、次のような競合メッセージが出力されることがあります。
[OSB Kernel:398022]該当するマッピングがWSDL操作のサービス定義内で見つかりません: OPERATION-NAME
[OSB Kernel:398034]2つの操作は同じ着信メッセージを予期しているため、メッセージ本文と異なるセレクタを使用する必要があります
この場合は、エラー・メッセージの指示に従ってWSDLまたはサービスを更新します。
分割-結合の検証の強化: AquaLogic Service Bus 3.0では、分割-結合で、初期化されていない変数への挿入アクションが許可されていました。Oracle Service Bus 11g リリース1 (11.1.1.7.0)では、このような挿入アクションは失敗し、次のエラーが表示されます。
Variable 'VARIABLE-NAME' is being referenced before it has been initialized with a value.: Fault [{http://docs.oasis-open.org/wsbpel/2.0/process/executable}uninitializedVariable]
分割-結合がAquaLogic Service Bus 3.0では機能するのにOracle Service Bus 11g リリース1 (11.1.1.7.0)では前述のエラーで失敗する場合、挿入前に変数を初期化するように分割-結合を編集します。
JMSプロキシ・サービスおよびビジネス・サービスURIの検証の強化: Oracle Service Bus 11g リリース1 (11.1.1.7.0)より前のバージョンでは、ホストおよびポートを指定せずにJMSプロキシ・サービスおよびビジネス・サービスURIを入力できました。Oracle Service Bus 11g リリース1 (11.1.1.7.0)では、次の検証が適用されます。
JMSプロキシ・サービスURIのホストとポートは省略できます。省略すると、実行前に確認ダイアログが表示されます。
JMSビジネス・サービスURIのホストとポートは必ず指定する必要があります。
Oracle Service Bus 10g リリース3メンテナンス・パック1 (10.3.1)またはOracle Service Bus 10gリリース3 (10.3)を使用している場合、次のアップグレードに関する考慮事項をお読みください。
アップグレードでは、既存の動作が次のように保持されます。
アラート・ログ有効フラグがアラート宛先にデフォルトで追加され、デフォルト値はtrueです。
アラート宛先がないSLA定義およびパイプライン・アラート定義は、次のようにアップグレードされます。
アップグレード・プロセスの一部として新しいアラート宛先が作成されます。アップグレードされるサービスと同じプロジェクトの下に作成され、AlertDestinationForLoggingという名前が付けられます。このアラート宛先は、アラート・ログのみが有効になっています。同じプロジェクトの下に、このアップグレード・ロジックに従うサービスが複数ある場合、これらのサービスは同じアラート宛先を共有します。
アラート宛先のないSLA定義およびパイプライン・アラート定義は、この新しいアラート宛先を参照するようにアップグレードされます。
JCAエンドポイント構成は、新規構成を使用するようにアップグレードされます。JCA WSIF拡張のあるWSDLは、Oracle Service Bus 11gアダプタ・アーティファクトにアップグレードされます。たとえば、JCAファイル、抽象WSDLおよび具体WSDLでは、JCA 10g wsdlをWSDL 11gおよびJCAファイルにアップグレードするためのインタフェースが提供されます。その他のアップグレードは次のとおりです。
構成JARのアップグレード
インポートされたOracle Service Bus config.jarファイルがJCAアップグレーダでスキャンされてから、JCA WSDL (WSIF JCA拡張のあるOracle SOA 10g WSDL)とconfig.jarファイル内のJCAサービスがアップグレードされます。
|
注意: JCAサービスに関連付けられているJCA WSDLのみアップグレードされます。どのJCAサービスでも使用されていないJCA WSDLは、アップグレードされません。 |
JCA WSDLのアップグレード
インポートされたconfig.jarファイル内のJCA WSDLはアップグレードされます。JCAリソースおよび抽象WSDLはJCA WSDLから生成されます。具体WSDLは抽象WSDLとJCAリソースから生成されます。具体WSDLは次のルールに基づいて生成されます。
ターゲット・ネームスペースは抽象WSDLと同じである必要があります。
WSIF JCAバインディングのある10g内のJCA(具体)WSDLは、JCAバインディングを含むJCAリソース、10g WSDLの抽象部分を含む抽象WSDL、および抽象WSDLで定義されているportTypeに基づくSOAPバインディングを含む具体WSDLにアップグレードされます。10gのJCA WSDLに基づくJCAサービスは、SOAPバインディングを含む具体WSDLに基づくようにアップグレードされ、JCAリソースへの参照も持つようになります。
バインディング・セクションにはSOAP 1.1バインディングが含まれます。
SOAP 1.1バインディング・スタイルはドキュメントです。
SOAP 1.1バインディング・セクションには抽象WSDLのすべての操作が含まれます。
各バインディング操作について、SOAP 1.1操作要素はsoapAction属性が操作名に設定された状態で生成されます。
各バインディング操作の入力および出力要素について、属性がリテラルを使用するように設定されたSOAP 1.1 body要素が生成されます。
抽象WSDLで定義されたヘッダー・メッセージを持つ特定のAQユースケースをサポートするために、SOAP header要素は操作の入力バインディング・セクションに対して生成されます。AQ抽象WSDLにはWSDLメッセージ名"Header_msg"が含まれ、メッセージには"Header"という名前の単一部分が含まれることが想定されます。
サービス・セクションは、生成されたバインディングのポートで作成されます。生成されるポートには、location属性が次のように設定されたSOAP 1.1 address要素が含まれます。
jca://<adapter_connection_factory_jndi>
|
注意: Oracle Service Bus 10gのJCA以外(http、jmsなど)のサービス・タイプ・プロキシ/ビジネス・サービスは、JCAバインディングを持つWSDLに基づき、同じWSDLがJCAサービス・タイプ・プロキシ/ビジネス・サービスで使用されていない場合、WSDLはアップグレードされないため、インポート時に競合します。SOAPバインディングなど、JCA以外のバインディングを持つようにWSDLを手動で修正して、競合を回避する必要があります。 |
例3-1 JCA具体WSDL
<?xml version="1.0"?>
<definitions name="db-inbound-concrete"
targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/db/db_inbound/"
xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/db/db_inbound/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<import namespace="http://xmlns.abc.com/pcbpel/adapter/db/db_inbound/"
location="inbound.wsdl"/>
<binding name="db-inbound_binding" type="tns:db-inbound_ptt">
<soap:binding style="document"
transport="http://www.abc.com/wli/sb/transports/jca"/>
<operation name="receive">
<soap:operation soapAction="receive"/>
<input name="receive">
<soap:body use="literal"/>
</input>
</operation>
</binding>
<service name="db-inbound">
<port name="db-inbound_pt" binding="tns:db-inbound_binding">
<soap:address location="jca://eis/DB/OSBJCADBConnection"/>
</port>
</service>
</definitions>
構成jar内の既存のJCA WSDLは具体WSDLで更新されます。
JCAサービスのアップグレード
構成JAR内の各JCAサービスは、JCAトランスポート固有の構成の変更で更新されます。生成されたJCAリソースへの参照は、JCAトランスポート固有の構成セクションに追加されます。エンドポイント構成で定義された他のすべてのプロパティは同じままになります。JCAサービスには、同じWSDLとバインディングに対する同じ依存関係が含まれますが、WSDLの内容は、生成された具体WSDLを含むように更新されます。
TopLinkマッピング・ファイルの内容
TopLinkマッピング・ファイルの内容は、エンドポイント構成から抽出されます。XMLリソースが作成され、エンドポイント構成から抽出されたTopLinkマッピング・ファイルの内容はXMLリソースの内容として格納されます。XMLリソースの名前は、エンドポイント構成内のアクティブ化/相互作用プロパティで指定されたTopLinkマッピング・ファイル名から「.xml」ファイル拡張子を除いたものになります。生成されたTopLinkマッピング・ファイルXMLリソースへの依存性は、このJCAサービスのJCAファイル・リソース内で生成されます。
ヘッダーのあるAQアダプタWSDLのアップグレード
SOA 11g より前は、AQアダプタWSDL内のHeader要素定義は、WSDL自体のターゲット・ネームスペースと同じネームスペースで定義されます。SOA 11g では、AQアダプタはWSDLのHeader要素のターゲット・ネームスペースを変更しました。新しいネームスペースは、次に示すように固定のネームスペースです:
http://xmlns.oracle.com/pcbpel/adapter/aq/headers/payloadheaders/
OSB JCAトランスポート・アップグレーダは、前述の新しい固定ターゲット・ネームスペースに一致するようにAQアダプタWSDLのHeader要素のターゲット・ネームスペースを自動的に変更します。
手動アップグレード
10gで使用されていたJCAアダプタ・ヘッダーは、NormalizedMessageプロパティで使用できます。AQアダプタにペイロード・ヘッダーが必要な場合、11g ではNormalizedMessageヘッダー・プロパティが使用されます。ペイロード・ヘッダーが必要な場合、キュー・ヘッダーとペイロード・ヘッダーはNormalizedMessageヘッダーを介して転送されます。
ヘッダー・サポートの変更により、一部のOracle Service Bus 10g構成は手動でアップグレードする必要があります。具体的には、パイプラインが11g に存在しないメッセージ・ヘッダー・タイプにアクセスしている場合は、トランスポート・ヘッダーを介してヘッダーにアクセスするように構成をアップグレードする必要があります。
リクエスト/レスポンス・パターンを使用するJMSビジネス・サービス(MessageIDおよびCorrelationIDベースの相関)は、新しい構成を使用するようにアップグレードされます。既存の「レスポンスが必要」フラグは、「レスポンス・キュー」プロパティ・オプションによって機能が拡張されました。「レスポンス・キュー」プロパティ・オプションの値には、「なし」、「リクエストURIごとに1つ」または「すべてのリクエストURIに対して1つ」を指定できます。次の表に、既存の値がどのようにアップグレードされたかを示します。
「レスポンスが必要」の値がtrueに設定されている場合、Oracle Service Bus 11gでも同じ値が使用され、「レスポンス・キュー」オプションは、すべてのリクエストURIに対して1つに設定されます。
アップグレード前のサービスで「レスポンスが必要」の値がtrueに設定されている場合、各ターゲットにおいて、「レスポンス・キュー」オプションは、新しい構成レスポンスURIを持つすべての「すべてのリクエストURIに対して1つ」に対して「1つ」に設定されます。スタンドアロン・ドメインでは、このターゲットは単一サーバーです。既存のコネクション・ファクトリおよびレスポンスJNDI名が新しいレスポンスURI構成にマージされます。レスポンスURIフォーマットは、ビジネス・サービスの最初のサービスURIの使用可能ホスト/ポート情報で作成され、コネクション・ファクトリおよびレスポンス・キューJNDI名が付加されます。ホスト/ポート情報は常に最初のサービスURIから取得されます。最初のサービスURIには、コネクション・ファクトリも含まれます。これは、レスポンスの構成済コネクション・ファクトリが空白の場合に取得されます。
レスポンスURIのフォーマットは、'jms://<ip>:<port>,<ip>:<port>/<connection-factory-jndi-name>/<response-queue-jndi-name>'です。
結果キャッシュ要素を含まないグローバル操作設定リソースをインポートする場合、デフォルト値がtrueの新しい結果キャッシュ要素が追加されます。
UDDI関連要素はServices.xsdのServiceEntry要素から新しい要素uddiConfigurationに移動しました。この要素は、UDDIからインポートされるビジネス・サービスに使用されます。
アップグレード後、同期中に古い名前のWSDLがある場合、この名前が使用されます。ただし、WSDLがない場合は、新しい命名規則で新しいWSDLが作成されます。
サービスのサービス・キーとサービス名は、uddiConfiguration要素の一部として保存されます。
XMLドキュメントでの復帰改行文字の処理を修正するために、Apache XMLBeansが更新されました。更新されたのは、XMLBeansが復帰改行文字(\r)を適切にエスケープしなかったためです。ドキュメントに が含まれる場合はXMLBeansへと解析される際に適切にエスケープ解除されて\rになりましたが、\rがストリーム・アウトされる際は、エスケープされませんでした。その結果、XMLでは\rが無効であるため、無効なXMLドキュメントが生成されていました。XMLBeansの修正後、\rは適切に にエスケープされるようになりました。
バージョン11g リリース1 (11.1.1.6.0)以降にアップグレードする場合、現在、前述の問題に対する回避策を実施しているのであれば、復帰改行文字の処理方法を修正する必要があります。たとえば、回避策として に2回のエスケープを行って&#13;に変換し、ストリーム・アウトの際に に戻るようにしている場合、検証エラーを回避するために2回目のエスケープを取り除く必要があります。
