Oracle® Fusion Middleware

Oracle Service Busでのサービスの開発

12c (12.2.1.1.0)

E77239-02(原本部品番号:E67916-02)

2016年8月

このドキュメントは、開発者向けであり、Oracle Service BusコンソールおよびOracle JDeveloperを使用して、プロキシおよびビジネス・サービス、分割-結合およびパイプラインの作成と構成、XQuery、XSLTおよびMFLによるメッセージ変換の実行、トランスポートの構成、JCAアダプタの操作、カスタム・トランスポートの作成、WS-Securityを使用したセキュリティの構成、Service Bus APIの使用、およびグローバルJNDIリソースの作成を行う方法について説明しています。

Oracle Fusion Middleware Oracle Service Busでのサービスの開発, 12c (12.2.1.1.0)

E77239-02

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

原本著者:  Oracle Corporation

原本協力著者:

原本協力者:

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

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

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

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

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

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

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

目次

表一覧

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

はじめに

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

- 表記規則

このガイドでの新しい情報

- 12c (12.2.1.1.0)の新機能と変更された機能

- 12c(12.2.1.1.0)におけるドキュメントの重要変更事項

第I部 Oracle Service Busの紹介

1 Oracle Service Busについて

- 1.1 Oracle Service Busの概要

- 1.1.1 機能領域

- 1.1.2 適応的なメッセージング

- 1.1.3 サービス・セキュリティ

- 1.1.4 サービス仮想化

- 1.1.5 構成フレームワーク

- 1.1.6 サービス管理

- 1.2 Service Busアーキテクチャの概念

- 1.2.1 メッセージ処理

- 1.2.2 メッセージ処理でのプロキシ・サービスの役割

- 1.2.3 トランスポート・レイヤー(インバウンド)

- 1.2.4 バインディング・レイヤー

- 1.2.5 メッセージ処理でのパイプラインの役割

- 1.2.6 トランスポート・レイヤー(アウトバウンド)

- 1.2.7 メッセージ処理でのビジネス・サービスの役割

- 1.3 Service Busコンポーネント

- 1.3.1 サービス・コンポーネント

- 1.3.1.1 プロキシ・サービス

- 1.3.1.2 ビジネス・サービス

- 1.3.2 メッセージ・フロー

- 1.3.2.1 パイプライン

- 1.3.2.1.1 パイプラインを介したデータの流れ

- 1.3.2.1.2 メッセージ・コンテキスト

- 1.3.2.2 分割-結合

- 1.3.3 トランスポート、アダプタおよびバインディング

- 1.3.3.1 サポート対象のトランスポート・プロトコル

- 1.3.3.2 サービスのタイプ

- 1.3.4 変換リソース

- 1.3.4.1 XQueryマッピング

- 1.3.4.2 XSLTマッピング

- 1.3.4.3 相互参照

- 1.3.4.4 ドメイン値マップ

- 1.3.5 トランスポートおよびアダプタ関連リソース

- 1.3.5.1 JCAバインド

- 1.3.5.2 JARファイル(アーカイブ)

- 1.3.5.3 JavaScriptファイル

- 1.3.5.4 MQ接続

- 1.3.6 スキーマおよびドキュメント・リソース

- 1.3.6.1 XMLスキーマ

- 1.3.6.2 XMLドキュメント

- 1.3.6.3 WSDLドキュメント

- 1.3.6.4 WADLドキュメント

- 1.3.6.5 MFLリソース

- 1.3.7 セキュリティ・リソース

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

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

- 1.3.7.3 WS-Policyリソース

- 1.3.8 アラート宛先

- 1.3.9 グループ・リソースのスロットル

- 1.3.10 システム・リソース

- 1.3.10.1 JNDIプロバイダ

- 1.3.10.2 SMTPサーバー

- 1.3.10.3 プロキシ・サーバー

- 1.3.10.4 UDDIレジストリ

- 1.4 Service Busメッセージング

- 1.4.1 メッセージング・モデル

- 1.4.2 メッセージ・フォーマット

- 1.4.3 メッセージ・コンテキスト

- 1.4.4 コンテンツ・タイプ

- 1.5 Service Busでのワーク・マネージャの使用

- 1.6 Service Busのセキュリティ

- 1.6.1 Service Busのセキュリティ機能

- 1.6.2 Service Busサービス・セキュリティ・モデル

- 1.6.3 Oracle Web Services Manager

- 1.6.4 Oracle Platform Security Services

- 1.6.5 WS-Policies

- 1.6.6 セキュリティのタイプ

- 1.6.6.1 インバウンド・セキュリティ

- 1.6.6.2 アウトバウンド・セキュリティ

- 1.6.6.3 IDの伝播

- 1.6.6.4 ユーザー管理および管理セキュリティ

- 1.6.6.5 トランスポート・レベルのセキュリティ

- 1.6.6.6 メッセージ・レベルのセキュリティ

- 1.6.7 カスタム・セキュリティ資格証明

- 1.7 Service Busサービスの設計方法

- 1.7.1 Service Busトップダウン・ロードマップ

- 1.7.2 Service Busのボトムアップ・ロードマップ

- 1.8 Service Busコンポーネントのネーミング・ガイドライン

- 1.9 WebブラウザでのService Busリソースの表示

- 1.9.1 WSDLドキュメント

- 1.9.2 WSポリシー

- 1.9.3 メッセージ・フォーマット言語(MFL)リソース

- 1.9.4 スキーマ・リソース

- 1.9.5 WebブラウザでのService Busリソースの表示についてのメモ

- 1.10 アクセシビリティ・オプション

- 1.10.1 JDeveloperでのアクセシビリティ・オプションの設定

- 1.10.2 スクリーン・リーダー・モードに関する注意

- 1.10.3 Oracle Service Busコンソールでのアクセシビリティ・オプションの設定方法

- 1.11 その他のリソース

2 Oracle Service Busコンソールのスタート・ガイド

- 2.1 Oracle Service Busコンソールの概要

- 2.1.1 Service Busセッション

- 2.1.2 Oracle Service Busコンソールのレイアウト

- 2.1.3 Service Busプロジェクトおよびフォルダ

- 2.1.3.1 システム・プロジェクト

- 2.1.3.2 プロジェクトおよびフォルダの名前

- 2.1.3.3 プロジェクトとフォルダを使用した修飾リソース名

- 2.1.4 Service Busリソース

- 2.1.5 Oracle Service Busコンソール・エディタ

- 2.2 スタート・ガイド

- 2.2.1 Oracle Service Busコンソールへのアクセス方法

- 2.2.2 Oracle Service Busコンソールの終了方法

- 2.3 セッションの操作

- 2.3.1 セッションの作成方法

- 2.3.2 セッションのアクティブ化方法

- 2.3.3 セッションの終了方法

- 2.4 Oracle Service Busコンソールでのプロジェクト、フォルダおよびリソースの操作

- 2.4.1 サービスの検索方法

- 2.4.2 プロジェクトおよびフォルダの定義エディタの操作

- 2.4.2.1 プロジェクト、フォルダおよびリソース情報について

- 2.4.2.2 セッション内のすべてのプロジェクトの表示

- 2.4.2.3 プロジェクト内のフォルダおよびリソースの表示

- 2.4.2.4 フォルダ内のサブフォルダおよびリソースの表示

- 2.4.2.5 プロジェクトおよびフォルダの定義エディタでのコンポーネントのフィルタ方法

- 2.4.3 リソースの新しいプロジェクトおよびフォルダの作成

- 2.4.3.1 プロジェクト・ナビゲータでのプロジェクトの作成

- 2.4.3.2 プロジェクト・ナビゲータでのフォルダの作成

- 2.4.4 リソース・ギャラリを使用したリソースの作成

- 2.4.5 プロジェクト、フォルダおよびリソースのクローン作成方法

- 2.4.5.1 プロジェクトのクローン作成時の動作

- 2.4.5.2 フォルダのクローン作成時の動作

- 2.4.6 プロジェクト、フォルダおよびリソースの名前変更方法

- 2.4.7 プロジェクト、フォルダおよびリソースの移動方法

- 2.4.8 プロジェクト、フォルダおよびリソースの削除方法

- 2.4.8.1 プロジェクト・ナビゲータを使用したService Busコンポーネントの削除

- 2.4.8.2 エディタを使用したService Busコンポーネントの作成

- 2.5 競合の表示と解決

- 2.5.1 競合およびエラーの表示方法

- 2.5.1.1 Service Busコンソールでのすべての競合およびエラーの表示

- 2.5.1.2 デプロイされたリソースのための競合およびエラーの表示

- 2.5.2 競合およびエラーの解決方法

- 2.5.2.1 同時更新の競合の解決

- 2.5.2.2 エラーの競合の解決

- 2.6 履歴データの表示

- 2.6.1 現在のセッションで行われた変更の表示方法

- 2.6.2 既存のセッションの表示方法

- 2.6.3 アクティブ化されたセッションで行われた変更の表示方法

- 2.6.4 アクティブ化されたセッションのパージ方法

- 2.7 変更およびアクティブ化の取消し

- 2.7.1 現在のセッションの特定の変更を取り消す方法

- 2.7.2 セッションのアクティブ化を取り消す方法

- 2.8 参照の表示

- 2.8.1 リソース参照の表示

- 2.9 Oracle Service Busコンソールの外観のカスタマイズ

- 2.9.1 表ビューのカスタマイズ方法

- 2.9.1.1 表示する列の指定

- 2.9.1.2 表内の列のソート

- 2.9.1.3 表内の列の順序変更

- 2.9.1.4 表のフルスクリーン・モードでの表示

3 JDeveloperでのOracle Service Busのスタート・ガイド

- 3.1 Service Busに関するJDeveloperの概念

- 3.1.1 アプリケーション・ナビゲータ

- 3.1.2 Service Bus概要エディタ

- 3.1.3 リソース・エディタ

- 3.1.4 「コンポーネント」ウィンドウ

- 3.1.5 「リソース」ウィンドウ

- 3.1.6 「プロパティ」ウィンドウ

- 3.1.7 「構造」ビュー

- 3.1.8 「ログ」ウィンドウ

- 3.2 JDeveloperでのService Busコンポーネントの管理

- 3.3 JDeveloperでのService Busアプリケーションおよびプロジェクトの作成

- 3.3.1 アプリケーションおよびプロジェクトの作成ガイドライン

- 3.3.2 Service Busアプリケーションおよびプロジェクトの作成方法

- 3.3.2.1 プロジェクトのないService Busアプリケーションの作成

- 3.3.2.2 Service Busアプリケーションおよびプロジェクトの作成

- 3.3.2.3 Service BusプロジェクトへのService Busアプリケーションの追加

- 3.4 Service Busプロジェクト、フォルダおよびリソースのリファクタ

- 3.4.1 JDeveloperでのService Busフォルダまたはリソースの名前変更方法

- 3.4.2 JDeveloperでのService Busフォルダまたはリソースの移動方法

- 3.4.3 プロジェクトまたはリソースの削除方法

- 3.4.3.1 リソースの削除

- 3.4.3.2 プロジェクトの削除

- 3.4.4 プロジェクトまたはフォルダのクローン作成方法

4 JDeveloperの開発環境の設定

- 4.1 JDeveloperでのサーバー接続の作成

- 4.1.1 アプリケーション・サーバー接続の作成方法

- 4.1.2 SOA-MDS接続の作成方法

- 4.1.3 MDSリポジトリの場所の変更方法

- 4.2 Oracle JCAアダプタの接続ファクトリの作成

- 4.3 JMSレポート・プロバイダの無効化

5 JDeveloperでのOracle Service Busアプリケーションの開発

- 5.1 Service Bus概要エディタの概要

- 5.1.1 Service Bus概要エディタのコンポーネント

- 5.1.2 トランスポート、アダプタおよびバインディング

- 5.1.3 プロジェクトと概要ダイアグラムの同期

- 5.2 Service Busコンポーネントの追加

- 5.2.1 Service Bus概要エディタの起動方法

- 5.2.2 パイプラインの追加方法

- 5.2.3 分割-結合の追加方法

- 5.2.4 プロキシ・サービスの作成方法

- 5.2.4.1 アダプタを使用したプロキシ・サービスの作成

- 5.2.4.2 トランスポートを使用したプロキシ・サービスの作成

- 5.2.4.3 既存のパイプラインまたは分割-結合からのプロキシ・サービスの作成

- 5.2.5 概要での既存のプロキシ・サービスの再利用方法

- 5.2.6 ビジネス・サービスの作成方法

- 5.2.6.1 アダプタを使用したビジネス・サービスの作成

- 5.2.6.2 トランスポートを使用したビジネス・サービスの作成

- 5.2.7 概要での既存のビジネス・サービスの再利用方法

- 5.2.8 デプロイされたService BusおよびSOAアプリケーションの呼出し方法

- 5.2.9 コンポーネントの追加に関する必知事項

- 5.3 Service Bus概要エディタでのコンポーネントの変更および削除

- 5.3.1 Service Bus概要エディタからのコンポーネントの編集方法

- 5.3.2 Service Bus概要エディタでのコンポーネントの名前変更方法

- 5.3.3 Service Bus概要エディタでのコンポーネントの削除方法

- 5.4 概要ダイアグラムの同期

- 5.5 Service Busコンポーネントのワイヤリング

- 5.5.1 Service Busコンポーネントのワイヤリング方法

- 5.5.2 サービス間のワイヤの削除方法

- 5.6 Service Busコンポーネントへのセキュリティ・ポリシーのアタッチ

- 5.7 概要エディタでのService Busコンポーネントのテスト

- 5.7.1 Service Busコンポーネントのテスト方法

- 5.7.2 Service Busコンポーネントのデバッグ方法

- 5.8 Service Busアプリケーションのデプロイ

第II部 Oracle Service Busリソースの使用

6 プロジェクト・リソースの作成と構成

- 6.1 Service Busプロジェクト・リソースの概要

- 6.1.1 Oracle Service Busコンソールのプロジェクト・リソースおよびセッション

- 6.2 サービス・アカウントの操作

- 6.2.1 サービス・アカウント認証タイプ

- 6.2.1.1 静的

- 6.2.1.2 ユーザー名とパスワードのパススルー

- 6.2.1.3 ユーザー・マッピング認証

- 6.2.2 サービス・アカウントの作成方法

- 6.2.2.1 認証情報をパススルーするサービス・アカウントの作成

- 6.2.2.2 静的パスワードでのサービス・アカウントの作成

- 6.2.2.3 受信パスワードをマップするサービス・アカウントの作成

- 6.2.3 サービス・アカウントの編集方法

- 6.2.4 サービス・アカウントの削除方法

- 6.3 サービス・キー・プロバイダの操作

- 6.3.1 サービス・キー・プロバイダの作成方法

- 6.3.2 サービス・キー・プロバイダの編集方法

- 6.3.3 サービス・キー・プロバイダの削除方法

- 6.4 アラート宛先の操作

- 6.4.1 アラート宛先タイプ

- 6.4.1.1 電子メール

- 6.4.1.2 SNMPトラップ

- 6.4.1.3 レポート作成

- 6.4.1.4 アラートのロギング

- 6.4.1.5 JMS

- 6.4.2 アラート宛先の作成方法

- 6.4.3 アラート宛先の電子メール受信者の定義方法

- 6.4.4 アラート宛先のJMS受信者の定義方法

- 6.4.5 アラート宛先の編集方法

- 6.4.6 アラート宛先の削除方法

- 6.4.7 SNMPの操作

- 6.4.7.1 Service BusのSNMPエージェントを操作する場合のガイドライン

- 6.4.7.2 トラップのリスニングの開始方法

- 6.5 XMLスキーマの操作

- 6.5.1 XMLスキーマの作成方法

- 6.5.2 XMLスキーマの編集方法

- 6.5.3 XMLスキーマの削除方法

- 6.6 XMLドキュメントの操作

- 6.6.1 XMLドキュメントの作成方法

- 6.6.2 XMLドキュメントの編集方法

- 6.6.3 XMLドキュメントの削除方法

- 6.7 JARファイルの操作

- 6.7.1 JARファイルの追加方法

- 6.7.2 JARファイルの更新方法

- 6.7.3 JARファイルの依存関係の変更方法

- 6.7.4 JARファイルの削除方法

7 システム・リソースの作成と構成

- 7.1 JNDIプロバイダ・リソースの操作

- 7.1.1 JBossアプリケーション・サーバーのクラスパス要件

- 7.1.2 JBoss初期コンテキスト・ファクトリの環境プロパティについて

- 7.1.3 Oracle Service BusコンソールでのJNDIプロバイダ・リソースの表示方法

- 7.1.4 JNDIプロバイダ・リソースの作成方法

- 7.1.5 JNDIプロバイダ・リソースの編集方法

- 7.1.6 JNDIプロバイダ・リソースの削除方法

- 7.2 SMTPサーバー・リソースの操作

- 7.2.1 Oracle Service BusコンソールでのSMTPサーバー・リソースの表示方法

- 7.2.2 SMTPサーバー・リソースの作成方法

- 7.2.3 デフォルトのSMTPサーバーの構成方法

- 7.2.4 SMTPサーバー・リソースの編集方法

- 7.2.5 SMTPサーバー・リソースの削除方法

- 7.3 プロキシ・サーバー・リソースの操作

- 7.3.1 SSLでのプロキシ・サーバーの使用

- 7.3.2 Oracle Service Busコンソールでのプロキシ・サーバー・リソースの表示方法

- 7.3.3 プロキシ・サーバー・リソースの作成方法

- 7.3.4 プロキシ・サーバー・リソースの編集方法

- 7.3.5 プロキシ・サーバー・リソースの削除方法

8 プロキシ・サービスの作成と構成

- 8.1 プロキシ・サービスの概要

- 8.1.1 プロキシ・サービスの定義

- 8.1.2 プロキシ・サービスのサービス・タイプとプロトコル

- 8.1.3 SOAPまたは任意のXMLサービス・タイプを使用する場合

- 8.1.4 メッセージ・サービス・タイプを使用する場合

- 8.1.5 プロキシ・サービス・タイプのバインディング定義とランタイム変数

- 8.1.5.1 WSDLサービス・タイプ

- 8.1.5.2 メッセージング・サービス・タイプ

- 8.1.5.3 任意のSOAPサービス

- 8.1.5.4 任意のXMLサービス

- 8.1.6 プロキシ・サービスのトランスポート・プロトコル構成

- 8.2 プロキシ・サービスの保護

- 8.3 サービス・レベル合意のアラート・ルール

- 8.4 Webサービス相互運用性への準拠

- 8.5 プロキシ・サービスの作成

- 8.5.1 プロキシ・サービスの作成方法

- 8.5.2 Service Busコンソールを使用したプロキシ・サービスの作成方法

- 8.5.3 Service Busコンソールを使用した型付きRESTプロキシ・サービスの作成方法

- 8.5.4 JDevleoperを使用したプロキシ・サービスの作成方法

- 8.5.5 JCAバインド・リソースからのプロキシ・サービスの生成方法

- 8.5.5.1 JDeveloperでのJCAバインドからのプロキシ・サービスの生成

- 8.5.5.2 コンソールでのJCAバインドからのプロキシ・サービスの生成

- 8.5.6 JDeveloperでの既存のサービスからのプロキシ・サービスの生成方法

- 8.5.7 JDeveloperでのWSDLドキュメントからのプロキシ・サービスの生成方法

- 8.6 プロキシ・サービスの構成

- 8.6.1 プロキシ・サービスの全般情報の構成方法

- 8.6.2 プロキシ・サービスのトランスポートの構成方法

- 8.6.3 プロキシ・サービスのメッセージ処理の構成方法

- 8.6.4 プロキシ・サービスのセキュリティの構成方法

- 8.6.5 プロキシ・サービスのサービス・レベル合意のアラートの構成方法

- 8.7 プロキシ・サービスの削除

- 8.7.1 プロキシ・サービスの削除方法

- 8.8 JDeveloperでのWSILによるプロキシ・サービスの使用

- 8.8.1 JDeveloperでのWSILによるService Busプロキシ・サービスの使用方法

9 ビジネス・サービスの作成と構成

- 9.1 ビジネス・サービスの概要

- 9.1.1 ビジネス・サービスの定義

- 9.1.2 ビジネス・サービスのサービス・タイプとプロトコル

- 9.1.3 ビジネス・サービス・タイプのバインディング定義とランタイム変数

- 9.1.4 ビジネス・サービスのトランスポート・プロトコル構成

- 9.1.4.1 ロード・バランシング・アルゴリズムについて

- 9.1.4.2 ビジネス・サービスのURI再試行について

- 9.1.4.3 アプリケーション・エラー発生時の再試行の抑止

- 9.1.5 ビジネス・サービスのメッセージ処理

- 9.1.5.1 XOP/MTOMサポート

- 9.1.5.2 添付ファイル

- 9.1.5.3 Webサービス相互運用性への準拠

- 9.2 プロキシ・サーバーの使用

- 9.3 サービス・レベル合意のアラート・ルール

- 9.4 ビジネス・サービスのセキュリティおよびセキュリティ・ポリシー

- 9.5 ビジネス・サービスの作成

- 9.5.1 ビジネス・サービスの作成方法

- 9.5.2 Service Busコンソールを使用したビジネス・サービスの作成方法

- 9.5.3 Service Busコンソールを使用した型付きRESTビジネス・サービスの作成方法

- 9.5.4 SOAPからRESTウィザードを使用したSOAPサービスに基づくRESTビジネス・サービスの作成方法

- 9.5.5 JDeveloperを使用したビジネス・サービスの作成方法

- 9.5.6 JCAバインド・リソースからのビジネス・サービスの生成方法

- 9.5.6.1 JDeveloperでのJCAバインドからのビジネス・サービスの生成

- 9.5.6.2 コンソールでのJCAバインドからのビジネス・サービスの生成

- 9.5.7 JDeveloperでのプロキシ・サービスからのビジネス・サービスの生成方法

- 9.5.8 JDeveloperでのWSDLドキュメントからのビジネス・サービスの生成方法

- 9.6 ビジネス・サービスの構成

- 9.6.1 ビジネス・サービスの全般情報の構成方法

- 9.6.2 ビジネス・サービスのトランスポートの構成方法

- 9.6.3 ビジネス・サービスのメッセージ処理の構成方法

- 9.6.4 ビジネス・サービスのパフォーマンスの構成方法

- 9.6.5 ビジネス・サービスのセキュリティの構成方法

- 9.6.6 ビジネス・サービスのサービス・レベル合意のアラートの構成方法

- 9.7 ビジネス・サービスの削除

- 9.7.1 ビジネス・サービスの削除方法

- 9.8 ビジネス・サービスの結果のキャッシュによるパフォーマンスの改善

- 9.8.1 結果キャッシュの仕組み

- 9.8.1.1 キャッシュされた結果のフラッシュ

- 9.8.2 結果キャッシュのベスト・プラクティス

- 9.8.3 結果キャッシュのエントリの削除方法

- 9.8.4 結果キャッシュのメタデータ

- 9.8.4.1 キャッシュ・トークン

- 9.8.4.2 有効期限

- 9.8.4.3 リクエスト・メタデータ

- 9.8.4.4 レスポンス・メタデータ

- 9.8.5 結果キャッシュのテスト

- 9.8.6 結果キャッシュのビジネス・サービスの構成方法

- 9.8.7 結果キャッシュの高度な構成

- 9.8.7.1 ユニキャストおよびマルチキャストの操作

- 9.8.7.2 Service BusでCoherenceを無効にする方法

- 9.8.7.3 プロセス外Coherenceサーバーについて

- 9.8.7.4 プロセス外Coherenceキャッシュ・サーバーの使用方法

- 9.8.7.4.1 プロセス外Coherenceキャッシュ・サーバーの作成

- 9.8.7.4.2 プロセス外Coherenceキャッシュ・サーバーのサーバーの構成

- 9.8.7.5 Oracle Coherenceの構成方法および使用方法の追加情報

10 分割-結合によるサービスのパフォーマンスの向上

- 10.1 分割-結合の概要

- 10.1.1 静的分割-結合

- 10.1.1.1 静的分割-結合 - サンプル・シナリオ

- 10.1.2 動的分割-結合

- 10.1.2.1 動的分割-結合 - サンプル・シナリオ

- 10.1.3 分割-結合の操作

- 10.1.3.1 分割-結合の通信操作

- 10.1.3.2 分割-結合のフロー制御操作

- 10.1.3.3 分割-結合の割当て操作

- 10.1.4 SOAPヘッダー内のコンテンツでの分割-結合の使用

- 10.1.5 トランザクション・サポート

- 10.1.6 分割-結合のセキュリティ

- 10.1.7 分割-結合のリソース・タイプと環境変数

- 10.2 サービス・レベル合意のアラート・ルール

- 10.3 JDeveloperでの分割-結合の操作

- 10.3.1 JDeveloperでの分割-結合の作成方法

- 10.3.2 JDeveloperでのWSDLドキュメントからの分割-結合の生成方法

- 10.3.3 「コンポーネント」ウィンドウと「プロパティ」ウィンドウの表示方法

- 10.3.3.1 「コンポーネント」ウィンドウの表示

- 10.3.3.2 「プロパティ」ウィンドウの表示

- 10.3.4 開始ノードの構成方法

- 10.3.5 外部サービスの表示方法

- 10.3.6 グローバル変数とローカル変数の構成方法

- 10.3.6.1 グローバル変数とローカル変数の定義

- 10.3.6.2 グローバル変数とローカル変数の編集

- 10.3.7 受信操作の構成方法

- 10.4 JDeveloperでの通信操作の追加

- 10.4.1 サービスの呼出し方法

- 10.4.2 返信の構成方法

- 10.5 JDeveloperでのフロー制御操作の追加

- 10.5.1 コンテナ・ノードの作成方法

- 10.5.2 リクエストの数に応じた反復方法

- 10.5.3 固定数のリクエストの並行処理方法

- 10.5.4 If-Else条件付きロジックの定義方法

- 10.5.5 エラー・ハンドラの作成方法

- 10.5.6 エラーの生成方法

- 10.5.7 エラーの再生成方法

- 10.5.8 Trueに評価されるまでの操作の繰返し方法

- 10.5.9 Falseに評価されるまでの操作の繰返し方法

- 10.5.10 処理での一時停止の挿入方法

- 10.6 JDeveloperでの割当て操作の追加

- 10.6.1 割当て操作での変換および式について

- 10.6.2 割当て操作の式の解決

- 10.6.3 変数への式の割当て方法

- 10.6.4 ソース・ドキュメントから宛先ドキュメントへの値のコピー方法

- 10.6.5 一連のノードの削除方法

- 10.6.6 XQuery式の結果の挿入方法

- 10.6.7 分割-結合でのJavaメソッドの呼出し方法

- 10.6.8 分割-結合データのログの記録方法

- 10.6.9 ノードおよびそのコンテンツの置換方法

- 10.7 Oracle Service Busコンソールでの分割-結合の操作

- 10.7.1 コンソールへの分割-結合のインポート方法

- 10.7.2 コンソールでの分割-結合の構成方法

- 10.7.3 分割-結合に対するサービス・レベル合意のルールの定義方法

- 10.8 静的および動的分割-結合のサンプル

- 10.8.1 静的な分割-結合の設計

- 10.8.1.1 新しい分割-結合の作成

- 10.8.1.2 割当ての追加

- 10.8.1.3 パラレル・ノードの追加

- 10.8.1.4 各ブランチに対する割当ての追加

- 10.8.1.5 サービスの呼出しの追加

- 10.8.1.6 各ブランチに対する割当ての追加

- 10.8.1.7 分割-結合のエクスポートとテスト

- 10.8.2 動的な分割-結合の設計

- 10.8.2.1 新しい分割-結合の作成

- 10.8.2.2 割当ての追加

- 10.8.2.3 For Eachの追加

- 10.8.2.4 割当ての追加

- 10.8.2.5 サービスの呼出しの追加

- 10.8.2.6 割当ての追加

- 10.8.2.7 エラー・ハンドラの追加

- 10.8.2.8 分割-結合のエクスポートとテスト

11 WSDLドキュメントの操作

- 11.1 WSDLの概要

- 11.1.1 WSDLタイプ

- 11.1.2 WSDLメッセージ

- 11.1.3 WSDLポート・タイプ

- 11.1.4 WSDLバインド

- 11.1.5 WSDLのサービスとポート

- 11.2 Service BusでのWSDLドキュメント

- 11.2.1 Webサービス・タイプ

- 11.2.1.1 SOAPドキュメント・ラップのWebサービス

- 11.2.1.2 SOAPドキュメント・スタイルのWebサービス

- 11.2.1.3 SOAP RPC Webサービス

- 11.2.2 有効なWSDLドキュメントと生成されたWSDLドキュメントについて

- 11.2.2.1 有効なWSDLドキュメント

- 11.2.2.2 生成されたWSDLドキュメント

- 11.3 WSDLポートとWSDLバインドに基づくサービス

- 11.3.1 プロキシ・サービスの有効なWSDLドキュメント

- 11.3.2 非トランスポート型ビジネス・サービスの有効なWSDLファイル

- 11.3.3 トランスポート型ビジネス・サービスの有効なWSDLファイル

- 11.3.4 ポートとバインディングに基づくプロキシ・サービスの例

- 11.3.4.1 ポートの基づくサービス

- 11.3.4.2 バインディングに基づくサービス

- 11.4 WSDLリソースのインポートとエクスポート

- 11.5 JDeveloperでのWSDLドキュメントの操作

- 11.5.1 JDeveloperでのWSDLリソースの作成方法

- 11.5.2 JDeveloperでのサービスからのWSDLファイルの生成方法

- 11.5.3 JDeveloperでのWSDLドキュメントの編集方法

- 11.5.4 JDeveloperでのWSDLドキュメントの削除方法

- 11.6 Oracle Service BusコンソールでのWSDLドキュメントの操作

- 11.6.1 コンソールでのWSDLリソースの作成方法

- 11.6.2 コンソールでのWSDLファイルのエクスポート方法

- 11.6.2.1 コンソールでのWSDLファイルのプロジェクトまたはフォルダからのエクスポート

- 11.6.2.2 サービス定義エディタからのWSDLファイルのエクスポート

- 11.6.3 コンソールでのサービスからのWSDLファイルの生成方法

- 11.6.4 コンソールでのWSDLドキュメントの編集方法

- 11.6.5 コンソールでのWSDLドキュメントの削除方法

- 11.7 有効なWSDLドキュメントの表示

第III部 Oracle Service Busパイプラインの操作

12 Oracle Service Busでのメッセージ・フローの作成

- 12.1 パイプライン・コンポーネント

- 12.1.1 メッセージ・フローの構築

- 12.1.2 メッセージの実行

- 12.2 パイプラインの分岐

- 12.2.1 操作ブランチ

- 12.2.2 条件付きブランチ

- 12.2.3 RESTブランチ

- 12.3 ステージおよびルート・ノードでのアクションの構成

- 12.3.1 通信アクション

- 12.3.2 フロー制御アクション

- 12.3.3 メッセージ処理アクション

- 12.3.4 レポート・アクション

- 12.3.5 パイプラインでのトランスポート・ヘッダーの構成

- 12.3.5.1 グローバル・パススルー・オプションとヘッダー固有のコピー・オプション

- 12.3.5.2 ランタイムによってトランスポート・ヘッダーの設定が使用される仕組み

- 12.3.5.3 トランスポート・ヘッダー・アクションで指定するトランスポート・ヘッダーの値の制限

- 12.4 パイプラインでのトランスフォーメーションの実行

- 12.4.1 トランスフォーメーションとパブリッシュ・アクション

- 12.4.1.1 サービス品質におけるパブリッシュ・アクションの動作

- 12.4.2 トランスフォーメーションとルート・ノード

- 12.5 サービス・コールアウト・メッセージの作成

- 12.5.1 SOAPドキュメント・スタイルのサービス

- 12.5.2 SOAP RPCスタイルのサービス

- 12.5.3 XMLサービス

- 12.5.4 メッセージ・サービス

- 12.6 サービス・コールアウト・メッセージでの添付ファイルの使用

- 12.6.1 SOAPドキュメント・スタイル・サービスでの添付ファイルの使用例

- 12.6.2 SOAP RPCスタイル・サービスでの添付ファイルの使用例

- 12.6.3 MTOM/XOPサポート

- 12.6.4 添付ファイルのディスクへのページング

- 12.7 サービス・コールアウトの結果としてのエラー処理

- 12.7.1 トランスポート・エラー

- 12.7.2 SOAPフォルト

- 12.7.3 予期しないレスポンス

- 12.8 パイプラインでのエラー処理

- 12.8.1 エラー・メッセージの生成、レポート、および返信

- 12.8.2 Service Bus 11gと12cのセキュリティ・フォルトの処理の異なる動作

- 12.8.3 エラー・ハンドラでのアクションの構成の例

- 12.9 動的ルーティングの使用

- 12.9.1 動的ルーティングの実装

- 12.9.1.1 サンプルXMLファイル

- 12.9.1.2 サンプルXMLからのXQueryリソースの作成

- 12.9.1.3 動的ルーティングを実装するためのパイプラインの作成および構成

- 12.9.1.4 IDベースのルーティングの実装に関するガイドライン

- 12.10 XQueryを使用したデータベースへのアクセス

- 12.11 メッセージ・コンテキストの理解

- 12.11.1 メッセージ・コンテキストのコンポーネント

- 12.11.2 メッセージ・コンテキストを表示および変更するためのガイドライン

- 12.11.3 inboundからoutboundへのJMSプロパティのコピー

- 12.12 変数の構造での作業

- 12.12.1 インラインXQuery式エディタの使用

- 12.12.1.1 インラインXQuery

- 12.12.1.2 インラインXQuery式エディタの用途

- 12.12.1.2.1 タイプ依存の式のベスト・プラクティス

- 12.12.2 変数の構造の使用

- 12.13 サービスの品質

- 12.13.1 配信の保証

- 12.13.1.1 デフォルト要素属性のオーバーライド

- 12.13.1.2 配信の保証のルール

- 12.13.1.3 スレッド・モデル

- 12.13.1.4 プロキシ・サービスの分割

- 12.13.2 アウトバウンド・メッセージの再試行

- 12.14 JavaScriptアクションおよびJavaScript式の使用

- 12.14.1 JavaScriptアクションおよびメッセージ・コンテキスト変数

- 12.14.2 JavaScript式を使用したコンテキスト変数の更新

- 12.14.3 JavaScript式を使用した変数の作成

- 12.14.4 JavaScript式を使用した変数の削除

- 12.14.5 XQuery、XPath、およびJSON変数について

- 12.14.6 ストリーミング$body変数およびJavaScriptアクション

- 12.14.7 JavaScriptアクションおよびカスタムJava関数

- 12.14.8 JavaScript式の結果のロギングおよびレポート

- 12.15 Service Busでのワーク・マネージャの使用

- 12.16 コンテンツ・タイプ、JMSタイプ、およびエンコーディング

- 12.17 抑制パターン

- 12.18 WS-Iへの準拠

- 12.18.1 WS-I準拠チェック

- 12.19 SOAP 1.1とSOAP 1.2との間の変換

13 Oracle Service Busコンソールでのパイプラインの操作

- 13.1 Oracle Service Busコンソールのパイプライン・デザイナの概要

- 13.1.1 コンソールの「メッセージ・フローの編集」ページ

- 13.1.2 コンソールの「ステージ構成の編集」ページ

- 13.2 コンソールでのパイプラインの表示と編集

- 13.2.1 コンソールでのパイプラインの表示および編集方法

- 13.2.2 コンソールでのパイプラインへの共有変数の追加方法

- 13.2.3 パイプラインへのパイプライン・ペアの追加方法

- 13.2.4 コンソールでのパイプラインへの条件付きブランチの追加方法

- 13.2.5 コンソールでのパイプラインへの操作ブランチの追加方法

- 13.2.6 コンソールでのパイプラインへのRESTブランチの追加方法

- 13.2.7 コンソールでのパイプラインへのステージの追加方法

- 13.2.8 コンソールでのパイプラインへのルート・ノードの追加方法

- 13.3 ステージおよびルート・ノードの切取り、コピー、貼付け

- 13.4 コンソールでのリシーケンサの構成

- 13.4.1 コンソールでパイプラインでのリシーケンスを構成する方法

- 13.4.2 コンソールでのリシーケンス・レベルの選択方法

- 13.4.3 コンソールでのリシーケンス・モードの構成方法

- 13.4.3.1 標準リシーケンサの構成

- 13.4.3.2 FIFOリシーケンサの構成

- 13.4.3.3 ベスト・エフォート・リシーケンサの構成

- 13.5 変数の構造のマッピングの作成

- 13.5.1 サンプルWSDLドキュメント

- 13.5.2 例で必要なリソースの作成

- 13.5.2.1 リソースとしてのWSDLファイルの保存

- 13.5.2.2 プロキシ・サービスとパイプラインの作成

- 13.5.2.3 サンプル・パイプラインのメッセージ・フローの構築

- 13.5.2.4 ビジネス・サービスの作成

- 13.5.3 例1: 事前定義された変数の構造の選択

- 13.5.4 例2: 変数の型へのマッピング

- 13.5.5 例3: 変数の要素へのマッピング

- 13.5.6 例4: 変数の子要素へのマッピング

- 13.5.7 例5: 変数のビジネス・サービスへのマッピング

- 13.5.8 例6: 子要素の別の子要素へのマッピング

14 Oracle Service Busコンソールでのパイプライン・アクションの操作

- 14.1 コンソールでのパイプライン・アクションの追加と編集

- 14.2 コンソールでのパブリッシュ・アクションの追加

- 14.3 コンソールでのパブリッシュ表アクションの追加

- 14.4 コンソールでの動的パブリッシュ・アクションの追加

- 14.5 コンソールでのルーティング・オプション・アクションの追加

- 14.6 コンソールでのサービス・コールアウト・アクションの追加

- 14.7 コンソールでのトランスポート・ヘッダー・アクションの追加

- 14.7.1 アウトバウンドHTTPトランスポート・ヘッダーでのCookieの設定

- 14.7.1.1 複雑なXML式としてのCookieの設定

- 14.7.1.2 文字列式を使用したCookieの設定

- 14.8 コンソールでのルート・ノードへの動的ルーティングの追加

- 14.9 コンソールでのルート・ノードへのルーティング・アクションの追加

- 14.10 コンソールでのルート・ノードへのルーティング表の追加

- 14.11 コンソールでのFor-Eachアクションの追加

- 14.12 コンソールでのIf-Thenアクションの追加

- 14.13 コンソールでのエラーの生成アクションの追加

- 14.13.1 トランザクション

- 14.14 コンソールでの返信アクションの追加

- 14.15 コンソールでの再開アクションの追加

- 14.16 コンソールでのスキップ・アクションの追加

- 14.17 コンソールでの割当てアクションの追加

- 14.18 コンソールでの削除アクションの追加

- 14.19 挿入アクションの追加

- 14.20 コンソールでのJavaコールアウト・アクションの追加

- 14.21 コンソールでのJavaScriptアクションの追加

- 14.22 コンソールでのMFL変換アクションの追加

- 14.23 nXSD変換アクションの追加

- 14.24 コンソールでの名前変更アクションの追加

- 14.25 コンソールでの置換アクションの追加

- 14.26 コンソールでの検証アクションの追加

- 14.27 コンソールでのアラート・アクションの追加

- 14.28 コンソールでのログ・アクションの追加

- 14.29 コンソールでのレポート・アクションの追加

- 14.30 コンソールでのエラー・ハンドラの追加

- 14.30.1 コンソールでのパイプライン・エラー・ハンドラの追加

- 14.30.2 コンソールでのステージ・エラー・ハンドラの追加

- 14.30.3 コンソールでのルート・ノード・エラー・ハンドラの追加

- 14.30.4 コンソールでのエラー・ハンドラの編集

- 14.31 コンソールでのアクションまたはステージの無効化

- 14.31.1 パイプラインでのアクションの無効化

- 14.31.2 パイプラインでのアクションの再有効化

- 14.31.3 パイプラインでのステージの無効化

- 14.31.4 パイプラインでのステージの再有効化

15 Oracle Service Busコンソールでの式エディタの操作

- 15.1 インラインXQueryおよびXPath式の作成と編集

- 15.2 XQueryエディタのレイアウトとタスクの理解

- 15.2.1 パレット

- 15.2.2 ワークスペース

- 15.2.3 プロパティ・インスペクタ

- 15.3 エディタ・ワークスペースのテキスト・フィールドでの式の構築

- 15.4 インライン式で使用するネームスペースの作成

- 15.5 XQueryエディタによる変数の構造の作成

- 15.6 XQueryエディタでのカスタムXPath関数の作成

- 15.7 外部XQueryリソースのインラインXQueryへのバインディング

- 15.8 外部XSLTリソースのインラインXQueryへのバインディング

- 15.9 動的XQuery式のインラインXQueryへのバインディング

- 15.10 動的XSLT式のインラインXQueryへのバインディング

- 15.11 「ビルダー」オプションを使用したXQuery比較式の入力

- 15.12 「ビルダー」オプションを使用した単項式の入力

16 Oracle JDeveloperでのパイプラインの操作

- 16.1 JDeveloperでのパイプライン・コンポーネントの追加

- 16.1.1 JDeveloperでのパイプラインの追加方法

- 16.2 JDeveloperでのパイプラインの表示と編集

- 16.2.1 JDeveloperでのパイプラインの表示および編集方法

- 16.3 JDeveloperでのパイプラインへの共有変数の追加

- 16.3.1 JDeveloperでのパイプラインへの共有変数の追加方法

- 16.4 JDeveloperでのパイプラインへのパイプライン・ペア・ノードの追加

- 16.4.1 JDeveloperでのパイプラインへのパイプライン・ペア・ノードの追加方法

- 16.5 JDeveloperでのパイプラインへの条件付きブランチの追加

- 16.5.1 JDeveloperでのパイプラインへの条件付きブランチの追加方法

- 16.6 JDeveloperでのパイプラインへの操作ブランチの追加

- 16.6.1 JDeveloperでのパイプラインへの操作ブランチの追加方法

- 16.7 JDeveloperでのパイプラインへのRESTブランチの追加

- 16.7.1 JDeveloperでのパイプラインへのRESTブランチの追加方法

- 16.8 JDeveloperでのパイプラインへのステージの追加

- 16.8.1 JDeveloperでのパイプラインへのステージの追加方法

- 16.9 JDeveloperでのパイプラインへのルート・ノードの追加

- 16.9.1 JDeveloperでのパイプラインへのルート・ノードの追加方法

- 16.10 JDeveloperでのステージおよびルート・ノードの切取り、コピー、貼付け

- 16.11 JDeveloperでのリシーケンサの構成

- 16.11.1 JDeveloperでパイプラインでのリシーケンスを構成する方法

- 16.11.2 JDeveloperでのリシーケンス・レベルの選択

- 16.11.3 JDeveloperでのリシーケンス・モードの構成方法

- 16.11.3.1 標準リシーケンサの構成

- 16.11.3.2 FIFOリシーケンサの構成

- 16.11.3.3 ベスト・エフォート・リシーケンサの構成

17 Oracle JDeveloperでのパイプライン・アクションの操作

- 17.1 JDeveloperでのパイプラインのアクションの追加および編集

- 17.2 JDeveloperでのパブリッシュ・アクションの追加

- 17.3 JDeveloperでのパブリッシュ表アクションの追加

- 17.4 JDeveloperでの動的パブリッシュ・アクションの追加

- 17.5 JDeveloperでのルーティング・オプション・アクションの追加

- 17.6 JDeveloperでのサービス・コールアウト・アクションの追加

- 17.7 JDeveloperでのトランスポート・ヘッダー・アクションの追加

- 17.8 JDeveloperでのルート・ノードへの動的ルーティングの追加

- 17.9 JDeveloperでのルート・ノードへのルーティング・アクションの追加

- 17.10 JDeveloperでのルート・ノードへのルーティング表の追加

- 17.11 JDeveloperでのFor Eachアクションの追加

- 17.12 JDeveloperでのIf Thenアクションの追加

- 17.13 JDeveloperでのエラーの生成アクションの追加

- 17.14 JDeveloperでの返信アクションの追加

- 17.15 JDeveloperでの再開アクションの追加

- 17.16 JDeveloperでのスキップ・アクションの追加

- 17.17 JDeveloperでの割当てアクションの追加

- 17.18 JDeveloperでの削除アクションの追加

- 17.19 JDeveloperでの挿入アクションの追加

- 17.20 JDeveloperでのJavaコールアウト・アクションの追加

- 17.21 JDeveloperでのJavaScriptアクションの追加

- 17.22 JDeveloperでのMFL変換アクションの追加

- 17.23 JDeveloperでのnXSD変換アクションの追加

- 17.24 JDeveloperでの名前変更アクションの追加

- 17.25 JDeveloperでの置換アクションの追加

- 17.26 JDeveloperでの検証アクションの追加

- 17.27 JDeveloperでのアラート・アクションの追加

- 17.28 JDeveloperでのログ・アクションの追加

- 17.29 JDeveloperでのレポート・アクションの追加

- 17.30 JDeveloperでのエラー・ハンドラの追加

- 17.30.1 JDeveloperでのエラー・ハンドラのパイプラインへの追加方法

- 17.31 JDeveloperでのアクションまたはステージの無効化

- 17.31.1 アクションまたはステージの無効化

- 17.31.2 アクションまたはステージの再有効化

18 パイプライン・テンプレートの操作

- 18.1 パイプライン・テンプレートの追加

- 18.1.1 パイプライン・テンプレートの追加方法

- 18.2 パイプライン・テンプレートの編集

- 18.2.1 パイプライン・テンプレートの編集方法

- 18.2.1.1 外部サービスの表示方法

- 18.2.1.2 共有変数の表示方法

- 18.3 パイプライン・テンプレート・メッセージ・フローへのプレースホルダ・ブロックの追加

- 18.4 パイプライン・テンプレートでのアクションのロック

- 18.4.1 パイプライン・テンプレートでのアクションのロック方法

- 18.5 パイプライン・テンプレートからの具象パイプラインの作成

- 18.5.1 具象パイプラインの作成方法

- 18.6 具象パイプラインに対するメッセージ・フローの編集

- 18.6.1 具象パイプラインに対するメッセージ・フローの編集方法

- 18.7 具象パイプラインから通常のパイプラインへの変換

- 18.7.1 具象パイプラインに対するテンプレート・リンクの解除方法

第IV章 データの変換

19 XQueryでのデータの変換

- 19.1 XQuery変換の概要

- 19.2 XQueryエディタおよびマッパー

- 19.2.1 JDeveloperのエディタおよびマッパー

- 19.2.2 Oracle Service Busコンソール・エディタ

- 19.3 JDeveloperでのXQueryマップの作成

- 19.3.1 JDeveloperでのXQueryマッピングの作成方法

- 19.4 JDeveloperでXQuery 2004からXQuery 1.0に変換されたService Busプロジェクトのテスト

- 19.5 Oracle Service BusコンソールでのXQueryリソースの操作

- 19.5.1 コンソールでのXQueryリソースの作成方法

- 19.5.2 コンソールでのXQueryリソースの編集方法

- 19.5.3 コンソールでのXQueryリソースの削除方法

- 19.5.4 XQuery 1.0を使用したXQueryリソースのアップグレード方法

- 19.6 Service Bus XQuery関数

- 19.6.1 Oracleでサポートされる拡張関数

- 19.6.2 Service Busの関数拡張機能

- 19.6.2.1 fn-bea:lookupBasicCredentials

- 19.6.2.2 fn-bea:isUserInGroup

- 19.6.2.3 fn-bea:isUserInRole

- 19.6.2.4 fn-bea: uuid

- 19.6.2.5 fn-bea:execute-sql()

- 19.6.2.5.1 例1: 動的ルーティングのデータベースからのURIの取得

- 19.6.2.5.2 例2: データベースからのXMLTypeデータの取得

- 19.6.2.6 fn-bea:serialize()

- 19.6.2.7 fn-bea:binary-to-text

- 19.6.2.8 fn-bea:binary-to-xml

- 19.6.3 カスタムXPath関数の作成と使用

20 XSLTでのデータの変換

- 20.1 XSLTの概要

- 20.2 XSLTエディタおよびマッパー

- 20.2.1 JDeveloperのエディタおよびマッパー

- 20.2.2 Oracle Service Busコンソール・エディタおよびマッパー

- 20.3 JDeveloperでのXSLTマッピングの作成

- 20.3.1 JDeveloperでのXSLTマッピングの作成方法

- 20.4 Oracle Service BusコンソールでのXSLTリソースの操作

- 20.4.1 コンソールでのXSLTリソースの作成方法

- 20.4.2 コンソールでのXSLTリソースの編集およびXSL変換のアップロード方法

- 20.5 Service BusコンソールでのXSLTマッパーの使用

- 20.5.1 Service BusコンソールでXSLTマッパーを開く方法

- 20.5.2 Oracle Mapperの使用

- 20.6 XSLTリソースの削除方法

21 相互参照でのデータのマッピング

- 21.1 相互参照の概要

- 21.1.1 相互参照データベース表

- 21.1.2 相互参照関数

- 21.1.3 実行時の相互参照データの管理

- 21.2 JDeveloperでの相互参照表の作成

- 21.2.1 JDeveloperでの相互参照表の作成方法

- 21.3 Oracle Service Busコンソールでの相互参照リソースの操作

- 21.3.1 コンソールでの相互参照(XRef)リソースの作成方法

- 21.3.2 コンソールでの相互参照リソースの編集方法

- 21.3.3 コンソールでのカスタム・データベース表の作成方法

- 21.4 相互参照リソースの削除

- 21.4.1 相互参照リソースの削除方法

- 21.5 Oracle Service Busでの相互参照表への移入

22 ドメイン値マップでのデータのマッピング

- 22.1 ドメイン値マップの概要

- 22.1.1 ドメイン値マップ関数

- 22.2 JDeveloperでのドメイン値マップの作成

- 22.2.1 JDeveloperでのドメイン値マップの作成方法

- 22.3 Oracle Service BusコンソールでのDVMリソースの操作

- 22.3.1 コンソールでのDVMリソースの作成方法

- 22.3.2 ドメイン値マップへのドメインの追加方法

- 22.3.3 ドメイン値マップへのドメイン値の追加方法

- 22.3.4 コンソールでのドメイン値マップの編集方法

- 22.4 ドメイン値マップの削除

- 22.4.1 ドメイン値マップの削除方法

- 22.5 式および条件でのドメイン値マップの使用方法

23 Message Format Languageを使用したデータ構造の定義

- 23.1 Format Builderの概要

- 23.1.1 MFLファイルについて

- 23.1.2 フォーマット、フィールドおよびグループの有効な名前

- 23.1.3 サポートされる文字デリミタ

- 23.2 Oracle Service BusコンソールでのMFLリソースの操作

- 23.2.1 コンソールでのMFLリソースの作成方法

- 23.2.2 コンソールでのMFLリソースの編集方法

- 23.3 MFLメッセージ構造の作成

- 23.3.1 Format Builderでのドラッグ・アンド・ドロップの使用

- 23.3.2 JDeveloperでのMFLファイルの作成方法

- 23.3.3 グループを作成する方法

- 23.3.4 フィールドの作成方法

- 23.3.5 グループまたはフィールドの参照方法

- 23.3.6 コメントの追加方法

- 23.4 MFLメッセージ構造の構成

- 23.4.1 ノードの繰返しの作成方法

- 23.4.2 デリミタの定義方法

- 23.4.2.1 参照によるデリミタの指定

- 23.4.2.2 値によるデリミタの指定

- 23.5 メタデータのインポートと変換

- 23.5.1 ガイドラインXMLファイルの変換方法

- 23.5.2 XMLスキーマの変換方法

- 23.5.3 COBOLコピーブックの変換方法

- 23.5.4 C構造の変換方法

- 23.5.5 FMLフィールド表クラスの変換方法

- 23.6 MFLリソースの削除

- 23.6.1 MFLリソースの削除方法

- 23.7 フォーマット定義のテスト

- 23.7.1 Format Testerの起動方法

- 23.7.2 非XMLウィンドウを使用したテスト方法

- 23.7.2.1 データ・オフセット機能の使用

- 23.7.2.2 テキスト機能の使用

- 23.7.3 XMLウィンドウを使用したテスト方法

- 23.7.4 デバッグ・ウィンドウを使用したテスト方法

- 23.7.5 フォーマット定義のデバッグ方法

- 23.7.5.1 値の検索

- 23.7.5.2 オフセットの検索

- 23.7.5.3 デバッグ・ログの使用

- 23.7.6 Format Testerのコマンド・リファレンス

- 23.7.6.1 「ファイル」メニュー

- 23.7.6.2 「編集」メニュー

- 23.7.6.3 「表示」メニュー

- 23.7.6.4 「生成」メニュー

- 23.7.6.5 「変換」メニュー

- 23.8 パレットの使用

- 23.8.1 「パレット」ウィンドウの表示方法

- 23.8.2 パレットへの項目の追加方法

- 23.8.3 メッセージ・フォーマットへのパレット項目の追加方法

- 23.9 Format Builderのサポート対象のデータ型

- 23.9.1 MFLのデータ型

- 23.9.2 COBOL Copybook Importerのデータ型

- 23.9.3 サポートされていないC言語機能

- 23.10 Format Builderのフィールド参照

- 23.10.1 Format Builderウィンドウ

- 23.10.2 Format Builderのツール・バー

- 23.10.3 Format Builderのツリー・ペイン

- 23.10.4 フィールド構成ウィンドウ

- 23.10.5 グループ構成ウィンドウ

- 23.10.6 Format Builderの参照構成ウィンドウ

24 JavaコールアウトおよびPOJOの使用方法

- 24.1 Javaコールアウトの概要

- 24.1.1 Javaコールアウトの使用のガイドライン

- 24.1.2 JavaコールアウトまたはEJB

- 24.2 ストリーミング・コンテンツの操作

- 24.2.1 ストリーミング・コンテンツをJavaコールアウトに渡す方法

- 24.2.2 Javaコールアウトからコンテンツ結果をストリーミングする方法

- 24.3 JavaコールアウトおよびPOJOのベスト・プラクティス

第V部 JCAアダプタ、トランスポートおよびバインドの操作

25 JCAトランスポートとJCAアダプタの使用

- 25.1 JCAトランスポートの概要

- 25.1.1 サポートされるJCAアダプタ

- 25.1.1.1 AQアダプタ

- 25.1.1.2 Oracle BAM 11gアダプタ

- 25.1.1.3 Coherenceアダプタ

- 25.1.1.4 データベース・アダプタ

- 25.1.1.5 ファイル・アダプタ

- 25.1.1.6 FTPアダプタ

- 25.1.1.7 JDE Worldアダプタ

- 25.1.1.8 JMSアダプタ

- 25.1.1.9 LDAPアダプタ

- 25.1.1.10 MQ Seriesアダプタ

- 25.1.1.11 MSMQアダプタ

- 25.1.1.12 Oracle E-Business Suiteアダプタ

- 25.1.1.13 Salesforceクラウド・アダプタ

- 25.1.1.14 SAPアダプタ

- 25.1.1.15 ソケット・アダプタ

- 25.1.1.16 サード・パーティ・アダプタ

- 25.1.1.17 ユーザー・メッセージング・サービス・アダプタ

- 25.1.2 Oracle JCAアダプタの制約事項

- 25.1.2.1 すべてのJCAアダプタに適用される制約事項

- 25.1.2.2 ファイル/FTP用のOracle JCAアダプタの制約事項

- 25.1.3 JCAアダプタ・フレームワーク

- 25.1.4 JCAトランスポートのメッセージング

- 25.1.5 JCAトランスポートのセキュリティ

- 25.1.5.1 プロキシ・サービス

- 25.1.5.2 ビジネス・サービス

- 25.1.6 ロギング

- 25.1.6.1 Oracle BAM Adapterロギング

- 25.1.7 JCAトランスポートのエラー処理

- 25.1.8 JCAトランスポートでのURIリライト

- 25.1.9 JCAトランスポートのメッセージ・エンコーディング

- 25.1.10 拒否されたメッセージ

- 25.2 Service BusにおけるJCAアダプタ構成の推奨事項

- 25.2.1 JCAアダプタ接続の構成

- 25.2.2 データベースをポーリングするJCAアダプタの構成

- 25.2.3 データベース用のOracle JCAアダプタの構成

- 25.2.4 AQ用のOracle JCAアダプタの構成

- 25.2.5 Oracle JCA Adapter for Coherenceの構成

- 25.2.6 Salesforceクラウド・アダプタの構成

- 25.3 JCAバインド・リソースの操作

- 25.3.1 JDeveloperでのJCAアダプタの作成方法

- 25.3.2 Oracle Service BusコンソールでのJCAアダプタのインポート方法

- 25.3.3 Oracle Service BusコンソールでのJCAバインド・リソースの作成方法

- 25.3.4 コンソールでのJCAバインド・リソースの編集方法

- 25.3.5 JCAバインド・リソースの削除方法

- 25.3.6 カスタムJCAアダプタの使用

- 25.3.6.1 カスタム・アダプタの登録ファイルについて

- 25.3.6.2 Service BusでのカスタムJCAアダプタの登録および使用

- 25.4 JavaScriptリソースの操作

- 25.4.1 JavaScriptリソースの作成方法

- 25.4.2 JavaScriptリソースの編集方法

- 25.4.3 JavaScriptリソースの削除方法

- 25.5 JCAトランスポート構成のリファレンス

- 25.5.1 JCAトランスポートのエンドポイントURI

- 25.5.1.1 エンドポイント再デプロイメント

- 25.5.2 JCAトランスポート・ヘッダーおよび正規化メッセージ・プロパティ

- 25.5.3 JCAトランスポートのエンドポイント・プロパティ

- 25.5.3.1 標準のエンドポイント・プロパティ

- 25.5.3.2 動的エンドポイント・プロパティ

- 25.5.3.3 アクティブ化指定プロパティおよび相互指定プロパティ

- 25.5.4 JCAトランスポートの環境変数

- 25.5.5 JCAトランスポートを使用するプロキシおよびビジネス・サービスの構成

- 25.5.6 プロキシ・サービス操作の構成

26 Oracle Service BusでのRESTサービスの作成

- 26.1 Oracle Service BusおよびREST

- 26.1.1 Service BusにおけるREST機能

- 26.1.2 Service BusにおけるRESTの実装

- 26.1.3 ネイティブRESTサービスのサービス・タイプ互換性

- 26.1.4 ネイティブRESTサービスによってサポートされているペイロード

- 26.1.5 ネイティブRESTサービスのレスポンス・コードおよび失敗コード

- 26.1.6 未処理のエラーおよびネイティブRESTサービス

- 26.1.7 RESTセキュリティ

- 26.2 Service BusでのRESTサービスに関するWADLドキュメント

- 26.2.1 設計時および実行時のWADLドキュメント

- 26.2.2 入力済ネイティブRESTサービスによってサポートされているメディア・タイプ表現

- 26.2.3 WADLによる問合せ操作

- 26.2.4 問合せパラメータおよびテンプレート・パラメータ

- 26.2.5 リソース・メソッドの識別

- 26.2.6 WSDLベースRESTサービスのWADL制限事項

- 26.2.7 有効なWADLドキュメント

- 26.3 WADLドキュメントの作成

- 26.3.1 Oracle Service BusコンソールでのWADLリソースの作成方法

- 26.4 WADLドキュメントの変更

- 26.4.1 WADLドキュメントの編集方法

- 26.4.2 WADLドキュメントの削除方法

- 26.5 JDeveloperを使用したRESTサービスの作成

- 26.5.1 ネイティブRESTサービスの作成

- 26.5.2 JDeveloperを使用したService Bus用のWSDLベースRESTサービスの作成方法

- 26.5.3 JDeveloperを使用したService Bus用の入力済RESTサービスの作成方法

- 26.5.4 JDeveloperでのREST操作の作成または構成方法

- 26.5.5 JDeveloperでのRESTメソッドの作成または構成方法

- 26.5.6 HTTPのプロキシまたはビジネス・サービスをRESTとして公開する方法

- 26.5.7 RESTのURIパラメータの構成に関する必知事項

- 26.6 WebブラウザでのWADLドキュメントへのアクセス

- 26.6.1 WADLドキュメントのXML形式での表示

- 26.6.2 WADLドキュメントの読取り可能形式での表示

27 DSPトランスポートの使用

- 27.1 DSPトランスポートの概要

- 27.2 Service Busのデータ・サービスの有効化

- 27.3 DSPトランスポートの使用

- 27.3.1 Oracle Data Service IntegratorでのWSDLファイルの生成

- 27.3.1.1 ステップ1: サーバーの起動

- 27.3.1.2 ステップ2: データ・サービスからのWSDLファイルの生成

- 27.3.1.3 ステップ3: Webサービス・アドレスの取得

- 27.3.2 Service Busプロジェクトの作成

- 27.3.2.1 ステップ4: データ・サービスWSDLファイルのService Busへのインポート

- 27.3.2.2 ステップ5: ビジネス・サービスの作成

- 27.3.2.3 ステップ6: プロキシ・サービスの作成

- 27.3.2.4 ステップ7: パイプラインの作成

- 27.3.2.5 ステップ8: 設定のテスト

- 27.4 DSPトランスポート構成のリファレンス

- 27.4.1 DSPトランスポート・エンドポイントURI

- 27.4.2 DSPトランスポートを使用するビジネス・サービスの構成

28 EJBトランスポートの使用

- 28.1 EJBトランスポートの概要

- 28.2 EJBを呼び出すサービスを作成するための前提条件

- 28.2.1 JNDIプロバイダ・リソースの登録

- 28.2.2 EJBクライアントまたはコンバータJARリソースの登録

- 28.2.2.1 クライアントJARまたはコンバータJARファイルの追加

- 28.2.2.2 サービス・アカウントの作成(オプション)

- 28.2.2.3 JNDIツリーでのEJBの検索

- 28.3 EJBビジネス・サービスの呼出し

- 28.4 WebサービスとしてのEJBの公開

- 28.5 EJBトランスポートの詳細な説明

- 28.5.1 EJBトランスポートのトランザクション

- 28.5.2 EJBトランスポートの再試行およびフェイルオーバー

- 28.5.3 EJBトランスポートのエラー処理

- 28.5.4 サポートされる型およびコンバータ・クラス

- 28.5.4.1 XMLBeanサポートについて

- 28.5.4.2 ユーザー定義のJavaデータ型およびJAX-WSについて

- 28.5.4.3 カスタム・コンバータ・クラス

- 28.5.4.4 EJBビジネス・サービスでのコンバータ・クラスの使用

- 28.5.5 ビジネス例外クラス

- 28.6 EJBトランスポートのトラブルシューティング

- 28.6.1 WSDLの下位互換性

- 28.6.2 tempディレクトリ

- 28.6.3 デプロイ済アプリケーション

- 28.6.4 EJBトランスポートのエラー

- 28.7 EJBトランスポート構成のリファレンス

- 28.7.1 EJBのエンドポイントURI形式

- 28.7.2 EJBトランスポートを使用するビジネス・サービスの構成

29 HTTPトランスポートおよびポーラー・トランスポートの使用

- 29.1 ポーラー・トランスポートの概要

- 29.2 HTTPトランスポートの使用

- 29.2.1 HTTPセッションの固定

- 29.2.2 プロキシ・サービスでのHTTP認可ヘッダーの取得

- 29.2.3 圧縮済HTTPリクエストおよびレスポンスのペイロードのサポート

- 29.2.3.1 Accept-Encoding

- 29.2.3.2 Content-Encoding

- 29.2.3.3 Content-Length

- 29.2.3.4 Transfer-Encoding

- 29.2.3.5 ETag

- 29.2.3.6 サンプル・リクエストおよびレスポンス

- 29.2.4 HTTPトランスポートWS-RMのサポート

- 29.2.5 HTTPトランスポート構成のリファレンス

- 29.2.5.1 HTTPトランスポートのエンドポイントURI

- 29.2.5.2 HTTPトランスポートを使用するプロキシ・サービスの構成

- 29.2.5.3 HTTPトランスポートを使用するビジネス・サービスの構成

- 29.2.6 RESTサポート

- 29.2.6.1 プロキシ・サービスのREST

- 29.2.6.1.1 XQueryサンプル

- 29.2.6.1.2 ヘッダー

- 29.2.6.2 ビジネス・サービスのREST

- 29.2.7 HTTPビジネス・サービスのレスポンス・コードおよびエラー処理

- 29.3 電子メール・トランスポートの使用

- 29.3.1 電子メール・トランスポート構成のリファレンス

- 29.3.1.1 電子メール・トランスポートのエンドポイントURI

- 29.3.1.2 電子メール・トランスポートを使用するプロキシ・サービスの構成

- 29.3.1.3 電子メール・トランスポートを使用するビジネス・サービスの構成

- 29.4 ファイル・トランスポートの使用

- 29.4.1 ファイル・トランスポート構成のリファレンス

- 29.4.1.1 ファイル・トランスポートのエンドポイントURI

- 29.4.1.2 ファイル・トランスポートを使用するプロキシ・サービスの構成

- 29.4.1.3 NFSファイル・システムに関する特別な考慮事項

- 29.4.1.4 ファイル・トランスポートを使用するビジネス・サービスの構成

- 29.5 FTPトランスポートの使用

- 29.5.1 FTPトランスポート構成のリファレンス

- 29.5.1.1 FTPトランスポートのエンドポイントURI

- 29.5.1.2 FTPトランスポートを使用するプロキシ・サービスの構成

- 29.5.1.3 FTPトランスポートを使用するビジネス・サービスの構成

- 29.6 SFTPトランスポートの使用

- 29.6.1 SFTPトランスポートの機能

- 29.6.2 SFTP認証の一般原則

- 29.6.3 SFTPトランスポートの実行時の動作

- 29.6.4 SFTP認証の有効化

- 29.6.4.1 既知ホスト・ファイルの作成

- 29.6.4.2 ユーザー名/パスワード認証の有効化

- 29.6.4.3 ホスト・ベース認証の有効化

- 29.6.4.4 公開鍵認証の有効化

- 29.6.5 SFTPトランスポートのためのFIPS準拠について

- 29.6.5.1 FIPS準拠の有効化

- 29.6.5.2 FIPS準拠のアップグレードの考慮事項

- 29.6.6 SFTPトランスポートの通信エラーの処理

- 29.6.7 SFTPトランスポートのトラブルシューティング

- 29.6.8 SFTPトランスポート・サービスのインポート

- 29.6.8.1 SFTPトランスポートにより使用されるリソースのインポート

- 29.6.8.2 サービスのインポートとパブリッシュ: UDDIレジストリ

- 29.6.9 SFTPトランスポート構成のリファレンス

- 29.6.9.1 SFTPトランスポートのエンドポイントURI

- 29.6.9.2 SFTPトランスポートを使用するプロキシ・サービスの構成

- 29.6.9.2.1 トランスポート・ヘッダーとメタデータの構成

- 29.6.9.3 パイプラインでのトランスポート・ヘッダーの構成

- 29.6.9.4 テスト・コンソールでのトランスポート・ヘッダーとメタデータの構成

- 29.6.9.5 SFTPトランスポートを使用するビジネス・サービスの構成

- 29.6.9.6 SFTPトランスポートの環境値

30 JEJBトランスポートの使用

- 30.1 JEJBトランスポートの概要

- 30.1.1 JEJBトランスポートとEJBトランスポートの相違点

- 30.1.2 JEJBトランスポートによるWSDLの生成

- 30.1.3 JEJBトランスポートのエラー処理

- 30.1.3.1 レスポンスでの例外の伝播

- 30.1.3.2 アプリケーション・エラーおよび接続エラー

- 30.1.3.2.1 接続エラー

- 30.2 JEJBサービスを作成するための前提条件

- 30.2.1 クライアントEJB JARファイルの作成とパッケージ化

- 30.2.2 JNDIプロバイダ・リソースの登録(ビジネス・サービス)

- 30.3 使用例

- 30.3.1 外部サービスを呼び出すEJB

- 30.3.2 EJBを呼び出す非EJBクライアント

- 30.3.3 EJBを呼び出すEJB

- 30.4 UDDIの統合

- 30.4.1 UDDIのパブリッシュ

- 30.4.2 UDDIのインポート

- 30.5 JEJBトランスポート構成のリファレンス

- 30.5.1 JEJBトランスポートのエンドポイントURI

- 30.5.1.1 プロキシ・サービスのJEJBエンドポイントURI

- 30.5.1.2 ビジネス・サービスのJEJBエンドポイントURI

- 30.5.2 JEJBトランスポートを使用するプロキシ・サービスの構成

- 30.5.3 ビジネス・サービスの構成

- 30.5.4 JEJBトランスポートの環境値

31 JMSトランスポートの使用

- 31.1 JMSトランスポートの概要

- 31.1.1 サービスのJMSコンテンツ・タイプ

- 31.1.2 JMSトランスポートのセキュリティ

- 31.1.3 非同期のリクエスト/レスポンス・メッセージング

- 31.1.4 メッセージでのJavaオブジェクトの送信および受信

- 31.1.5 必要なJMSリソース

- 31.1.6 プラットフォームの相互運用性

- 31.1.6.1 WebLogic JMSとの相互運用性

- 31.1.6.2 WebSphere MQとの相互運用性

- 31.1.6.3 Tibco EMSとの相互運用性

- 31.2 SOAP Over JMSトランスポートの使用

- 31.2.1 WebLogic Serverとの相互運用

- 31.2.2 ドメイン間JMS呼出しのレスポンス・キューの構成

- 31.3 ドメイン、サーバーおよびURIの命名ガイドライン

- 31.3.1 JMSサーバー名

- 31.3.2 JNDI名とService Bus

- 31.4 プロキシ・サービスでのJMSクライアントID

- 31.4.1 クライアントIDおよびサブスクライバ名について

- 31.4.2 推奨される使用方法

- 31.5 JMSトランスポートのエラー処理

- 31.5.1 アプリケーション・エラー

- 31.5.2 通信エラー

- 31.5.3 Javaオブジェクトにおけるパイプライン例外

- 31.6 WSDL定義のSOAPフォルト・メッセージ

- 31.6.1 フォルトがService Busパイプライン内から作成される場合にSOAPメッセージにフォルトを追加

- 31.7 JMSリクエスト/レスポンスのメッセージIDと相関IDのパターン

- 31.7.1 JMSリクエスト/レスポンスと設計パターンの概要

- 31.7.1.1 メッセージングのパターン

- 31.7.2 JMSメッセージIDのパターン

- 31.7.2.1 JMSReplyToプロパティへのアクセス

- 31.7.2.2 クラスタでのJMSメッセージIDのパターン

- 31.7.3 JMS相関IDのパターン

- 31.7.4 メッセージIDと相関IDのパターンの比較

- 31.7.5 JMSでのJAX-RPCとの相互運用

- 31.7.5.1 JMSメッセージIDのパターンを使用したJAX-RPC Webサービスの呼出し

- 31.7.5.2 JAX-RPCクライアントからのJMSリクエスト/レスポンス・プロキシ・サービスの呼出し

- 31.7.6 JMSメッセージIDのパターン例

- 31.7.6.1 JMSメッセージIDを使用してリクエスト/レスポンス・メッセージの相関を行うMQサービス

- 31.7.6.2 プロキシ・サービスを使用したJAX-RPCクライアント

- 31.7.6.3 WebLogic Server JAX-RPCサービスのクライアントとしてのService Bus

- 31.8 JMSトランスポート構成のリファレンス

- 31.8.1 JMSトランスポートのエンドポイントURI

- 31.8.2 JMSトランスポートを使用するプロキシ・サービスの構成

- 31.8.3 JMSトランスポート・ヘッダー

- 31.8.3.1 トランスポート・ヘッダーの構成

- 31.8.4 JMSトランスポートを使用するビジネス・サービスの構成

32 ローカル・トランスポートの使用

- 32.1 ローカル・トランスポートの概要

- 32.1.1 ローカル・トランスポート・プロキシ・サービスの機能と特性

- 32.2 ローカル・トランスポート・プロキシ・サービスの使用

- 32.2.1 以前の使用方法からの変更点

- 32.3 プロキシ・サービス間でのSOAPフォルトの伝播

- 32.4 ローカル・プロキシ・サービスでのOWSMセキュリティの使用

33 MQトランスポートの使用

- 33.1 MQ転送について

- 33.1.1 MQトランスポートの機能

- 33.1.2 MQトランスポートの利点

- 33.1.3 メッセージング・パターン

- 33.1.4 MQ接続リソース

- 33.1.5 サービスの品質

- 33.1.6 マルチインスタンス・キュー・マネージャのサポート

- 33.1.7 MQクラスタとMQトランスポート

- 33.1.8 MQトランスポートの制限

- 33.2 MQトランスポートの環境の設定

- 33.2.1 環境へのMQクライアント・ライブラリの追加方法

- 33.2.2 環境変数の構成方法

- 33.3 MQ接続の操作

- 33.3.1 MQ接続の作成方法

- 33.3.2 MQ接続の編集方法

- 33.3.3 MQ接続の削除方法

- 33.4 MQトランスポートのエラー処理

- 33.5 WebSphere JMS MQインタフェースの使用

- 33.5.1 WebSphere MQ JMSインタフェースの使用

- 33.5.2 MQメッセージングのタイプ

- 33.5.2.1 非永続メッセージング

- 33.5.2.2 非XA永続メッセージング

- 33.5.2.3 XAメッセージング

- 33.5.3 WebSphere MQのチューニング

- 33.6 MQトランスポート構成のリファレンス

- 33.6.1 MQトランスポートのエンドポイントURI

- 33.6.2 MQトランスポートを使用するプロキシ・サービスの構成

- 33.6.3 MQトランスポートを使用するビジネス・サービスの構成

- 33.6.4 MQトランスポートの環境値

- 33.7 MQトランスポート・ヘッダー

- 33.7.1 トランスポート・ヘッダーの構成

- 33.7.2 RFH2ヘッダーについて

34 Oracle BPEL Process Managerトランスポートの使用

- 34.1 BPELトランスポートの概要

- 34.1.1 BPELトランスポートでのSOAPのサポート

- 34.1.2 BPELトランスポートでのトランザクション伝播

- 34.1.3 BPELトランスポートでのSSLのサポート

- 34.1.4 BPELトランスポートの環境値

- 34.2 BPELトランスポートの簡単な使用例(同期)

- 34.2.1 同期: Oracle BPEL Process Managerのプロセスの呼出し

- 34.2.1.1 サービスの作成と構成

- 34.2.2 同期: Oracle BPEL Process Managerからの外部サービスの呼出し

- 34.2.2.1 サービスの作成と構成

- 34.2.3 メッセージと正しい会話の関連付け

- 34.3 高度な使用例(非同期)

- 34.3.1 非同期: Oracle BPEL Process Managerのプロセスの呼出し

- 34.3.1.1 サービスの作成と構成

- 34.3.2 非同期: Oracle BPEL Process Managerからのサービス・プロバイダの呼出し

- 34.3.2.1 サービスの作成と構成

- 34.4 BPELトランスポートのセキュリティ

- 34.4.1 Oracle Service BusからOracleサーバーへの通信でのSSLの使用

- 34.5 BPELトランスポートのエラー処理

- 34.5.1 アプリケーション・エラー

- 34.5.2 接続エラー

- 34.5.3 その他のエラー

- 34.6 WS-Addressingのリファレンス

- 34.6.1 ReplyTo

- 34.6.1.1 Service Busを介したBPELプロセスの非同期コール

- 34.6.1.2 Service Busを介して外部サービスをコールするBPELプロセス

- 34.6.2 MessageID / RelatesTo

- 34.7 BPELトランスポートを使用するXMLメッセージングの例

- 34.7.1 会話IDの例

- 34.7.1.1 ポートとメッセージの定義

- 34.7.1.2 WS-Addressingでの会話IDの設定

- 34.7.1.3 メッセージ・ペイロード・データでの会話IDの設定

- 34.7.1.4 変換の例

- 34.7.2 Service Busを介したBPEL間非同期通信の例

- 34.7.2.1 ポートとメッセージの定義

- 34.7.2.2 BP1からP1 - 開始操作

- 34.7.2.3 P1/B1からBP2

- 34.7.2.4 BP2からP2 - onResult操作

- 34.7.2.5 P2/B2からBP1 - onResult操作

- 34.8 BPELトランスポート構成のリファレンス

- 34.8.1 BPELトランスポートのエンドポイントURI

- 34.8.2 BPELトランスポートを使用するビジネス・サービスの構成

35 SBトランスポートの使用

- 35.1 SBトランスポートの概要

- 35.1.1 SBトランスポートの機能

- 35.2 SBトランスポートのエラー処理

- 35.3 UDDIとSBトランスポート

- 35.3.1 サービスのパブリッシュ

- 35.3.2 サービスのインポート

- 35.4 SBトランスポート構成のリファレンス

- 35.4.1 SBトランスポートの環境値

- 35.4.2 SBトランスポートを使用するプロキシ・サービスの構成

- 35.4.3 SBトランスポートを使用するビジネス・サービスの構成

- 35.4.3.1 JNDIプロバイダ

36 SOA-DIRECTトランスポートの使用

- 36.1 SOA-DIRECTトランスポートの概要

- 36.1.1 SOA-DIRECTトランスポートの機能

- 36.1.2 サービス・バインディング・タイプ

- 36.1.3 SOA-DIRECTトランスポート用のWS-Addressing

- 36.1.4 SOA-DIRECTトランスポートのセキュリティ

- 36.1.5 SOA-DIRECTトランスポートのエラー処理

- 36.1.5.1 接続エラー

- 36.1.5.2 アプリケーション・エラー

- 36.1.5.3 一般エラー

- 36.2 Service BusでのSOA Suiteサービスの使用

- 36.2.1 簡単な使用例 - 同期

- 36.2.1.1 トランザクション境界

- 36.2.1.2 SOAコンポジットの同期呼出し

- 36.2.1.3 SOAコンポジットからの同期呼出し

- 36.2.1.4 メッセージと正しい会話の関連付け

- 36.2.2 高度な使用例 - 非同期

- 36.2.2.1 SOAコンポジットの非同期呼出し

- 36.2.2.2 SOAコンポジットからの非同期呼出し

- 36.3 SOA-DIRECTトランスポート構成のリファレンス

- 36.3.1 SOA-DIRECTのエンドポイントURI

- 36.3.1.1 クラスタ内のエンドポイントURIの形式

- 36.3.1.2 エンドポイントURIの例

- 36.3.2 SOA-DIRECTトランスポートを使用するビジネス・サービスの構成

- 36.3.3 SOA-DIRECTトランスポートの環境値

- 36.4 WS-Addressingのリファレンス

- 36.4.1 ReplyToヘッダー

- 36.4.1.1 SOAコンポジットの非同期コール

- 36.4.1.2 SOAコンポジットの非同期コール・バック

- 36.4.2 MessageID / RelatesToヘッダー

- 36.5 XMLメッセージングの例

- 36.5.1 会話IDの例

- 36.5.1.1 ポートとメッセージの定義

- 36.5.1.2 WS-Addressingでの会話IDの設定

- 36.5.1.3 メッセージ・ペイロード・データでの会話IDの設定

- 36.5.1.4 変換の例

- 36.5.2 Service Busを介したコンポジット間非同期通信

- 36.5.2.1 ポートとメッセージの定義

- 36.5.2.2 BP1からP1 - 開始操作

- 36.5.2.3 P1/B1からBP2

- 36.5.2.4 BP2からP2 - onResult操作

- 36.5.2.5 P2/B2からBP1 - onResult操作

37 Tuxedoトランスポートの使用

- 37.1 Tuxedoトランスポートの概要

- 37.1.1 Tuxedoトランスポートの機能

- 37.2 Oracle Tuxedo Connectorの構成

- 37.2.1 始める前に

- 37.2.2 Oracle Tuxedo Connectorの構成

- 37.3 Service BusでのTuxedoサービスの使用

- 37.3.1 Tuxedoベースのビジネス・サービスの構成

- 37.3.1.1 Tuxedoトランスポートのビジネス・サービスのエンドポイントURI

- 37.3.2 Tuxedoベースのビジネス・サービスのロード・バランシングおよびフェイルオーバー

- 37.3.3 Tuxedoベースのビジネス・サービスのエラー処理

- 37.3.4 構成のテスト

- 37.4 TuxedoでのService Busの使用

- 37.4.1 Tuxedoベースのプロキシ・サービスの構成

- 37.4.2 構成のテスト

- 37.5 Tuxedoトランスポートのバッファ変換

- 37.5.1 任意のXMLサービス・タイプの場合のバッファ変換

- 37.5.2 メッセージ・サービス・サービス・タイプの場合のバッファ変換

- 37.6 Tuxedoトランスポートのトランザクション処理

- 37.6.1 インバウンドTuxedoサービスのトランザクション処理

- 37.6.2 アウトバウンドTuxedoサービスのトランザクション処理

- 37.7 Tuxedoトランスポート構成のリファレンス

- 37.7.1 Tuxedoトランスポートを使用するプロキシ・サービスの構成

- 37.7.2 Tuxedoトランスポートを使用するビジネス・サービスの構成

38 WSトランスポートの使用

- 38.1 WSトランスポートの概要

- 38.1.1 Webサービスの信頼性のあるメッセージング

- 38.1.2 WSトランスポートの機能

- 38.1.3 メッセージング・パターン

- 38.1.4 WSトランスポートのWS-Policy

- 38.1.4.1 WS-Policyの構成

- 38.1.5 サイズの大きいメッセージ・コンテンツのストリーミング

- 38.1.6 Webサービスの相互運用性

- 38.2 サービスの認証と認可

- 38.2.1 プロキシ・サービスの認証

- 38.2.2 プロキシ・サービスの認可

- 38.2.3 ビジネス・サービスの認証

- 38.3 WSトランスポートの使用

- 38.3.1 Oracle Service BusコンソールへのWSDLドキュメントのインポート

- 38.3.2 WSポリシーの構成

- 38.3.3 サービスへのWSポリシーの付加

- 38.3.4 エラー・キューの構成

- 38.3.5 HTTPプロキシ・サーバーを経由するWSトランスポートのルーティング

- 38.3.6 WSトランスポートのエラー処理

- 38.3.7 リソースのインポートとエクスポート

- 38.3.8 UDDIレジストリを使用したサービスのインポートとパブリッシュ

- 38.4 WSトランスポート構成のリファレンス

- 38.4.1 WSトランスポートのエンドポイントURI

- 38.4.2 WSトランスポートを使用するビジネス・サービスの構成

- 38.4.3 WSトランスポートを使用するプロキシ・サービスの構成

第VI部 カスタム・トランスポート・プロバイダの作成

39 カスタム・トランスポート・プロバイダについて

- 39.1 トランスポート・プロバイダの概要

- 39.2 トランスポートSDKの概要

- 39.2.1 トランスポートSDKの機能

- 39.2.1.1 インバウンド・メッセージおよびアウトバウンド・メッセージの処理

- 39.2.1.2 トランスポート関連のアーティファクトのデプロイ

- 39.2.1.3 メッセージの非同期的な処理

- 39.2.2 トランスポート・プロバイダのモード

- 39.2.3 関連機能

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

- 39.2.3.2 モニターおよびメトリック

- 39.3 カスタム・トランスポート・プロバイダの開発の必要性

- 39.3.1 トランスポートSDKの使用が適している場合

- 39.3.2 別の方法を選択した方が良い場合

- 39.4 トランスポート・プロバイダのコンポーネント

- 39.4.1 設計時のコンポーネント

- 39.4.2 実行時のコンポーネント

- 39.5 トランザクション・モデル

- 39.5.1 トランスポート・エンドポイントのプロパティの概要

- 39.5.1.1 トランザクション対応のエンドポイントとトランザクション非対応のエンドポイント

- 39.5.1.2 サポートされているメッセージ・パターン

- 39.5.2 同期トランザクションのサポート

- 39.5.2.1 使用例1 (レスポンス・パイプラインの処理)

- 39.5.2.2 使用例2 (サービス・コールアウトの処理)

- 39.5.2.3 使用例3 (トランザクションの中断)

- 39.5.2.4 使用例4 (複数のURI)

- 39.6 トランスポートSDKセキュリティ・モデル

- 39.6.1 インバウンド・リクエストの認証

- 39.6.2 アウトバウンド・リクエストの認証

- 39.6.2.1 ユーザー名とパスワードによるアウトバウンド認証

- 39.6.2.2 アウトバウンドSSLクライアント認証(双方向SSL)

- 39.6.2.3 アウトバウンドJAAS Subject認証

- 39.6.3 リンクレベルまたは接続レベルの資格証明

- 39.6.4 プロキシ・サービスへの一貫したアクセス制御

- 39.6.5 IDの伝播および資格証明マッピング

- 39.7 トランスポートSDKおよびスレッド・モデル

- 39.7.1 インバウンド・リクエスト・メッセージのスレッド

- 39.7.2 アウトバウンド・レスポンス・メッセージのスレッド

- 39.7.3 非同期のサポート

- 39.7.4 パブリッシュおよびサービス・コールアウトのスレッディング

- 39.8 メッセージ・コンテンツの設計

- 39.8.1 SourceおよびTransformer

- 39.8.2 SourceおよびMessageContextオブジェクト

- 39.8.3 組込みのトランスフォーメーション

40 カスタム・トランスポート・プロバイダの開発

- 40.1 開発の流れ

- 40.1.1 計画

- 40.1.2 開発

- 40.1.3 パッケージ化とデプロイ

- 40.2 始める前に

- 40.3 開発の基本手順

- 40.3.1 ステップ1. トランスポート・フレームワーク・コンポーネントの確認

- 40.3.2 ステップ2. トランスポート・プロジェクトのディレクトリ構造の作成

- 40.3.3 ステップ3. トランスポート固有のアーティファクトのXMLスキーマ・ファイルの作成

- 40.3.4 ステップ4. トランスポート固有のアーティファクトの定義

- 40.3.4.1 EndPointConfiguration

- 40.3.4.2 RequestMetaDataXML

- 40.3.4.3 RequestHeadersXML

- 40.3.4.4 ResponseMetaDataXML

- 40.3.4.5 ResponseHeadersXML

- 40.3.5 ステップ5. TransportProviderConfiguration XMLBeanの定義

- 40.3.6 ステップ6. トランスポート・プロバイダのユーザー・インタフェースの実装

- 40.3.7 ステップ7. 実行時インタフェースの実装

- 40.3.8 ステップ8. トランスポート・プロバイダのパッケージ化とデプロイ

- 40.4 開発に関する重要事項

- 40.4.1 メッセージの処理

- 40.4.1.1 メッセージ・データの送受信

- 40.4.1.2 リクエスト/レスポンスのメタデータの処理

- 40.4.1.3 文字セット・エンコーディング

- 40.4.1.4 同じ場所に配置された呼出し

- 40.4.1.5 Service Busランタイムへのアウトバウンド・レスポンスの返信

- 40.4.2 メッセージの変換

- 40.4.3 TransportOptionsの操作

- 40.4.3.1 インバウンド処理

- 40.4.3.2 アウトバウンド処理

- 40.4.3.3 リクエスト・モード

- 40.4.4 エラー処理

- 40.4.4.1 発生例1: アウトバウンド呼出し前に例外が発生

- 40.4.4.2 発生例2: アウトバウンド呼出し中に例外が発生

- 40.4.4.3 発生例3: アウトバウンド呼出し後に例外が発生

- 40.4.4.4 アプリケーション・エラーの捕捉

- 40.4.4.4.1 アプリケーション・エラーの識別

- 40.4.4.4.2 アプリケーション・エラーの再試行の構成

- 40.4.4.5 接続エラーの捕捉

- 40.4.4.5.1 接続エラーの識別

- 40.4.5 カスタム環境の値タイプの定義

- 40.4.6 UDDIレジストリへのプロキシ・サービスのパブリッシュ

- 40.4.7 TransportWLSArtifactDeployerの実装が適している場合

- 40.5 カスタム・トランスポートのヘルプの作成

- 40.5.1 カスタム・トランスポート・オンライン・ヘルプについて

- 40.5.2 コンソールでのカスタム・トランスポートのヘルプの提供方法

- 40.5.2.1 CustomHelpProviderインタフェースの実装

- 40.5.2.2 起動するHTMLファイルの作成

- 40.5.2.3 拡張されたヘルプを表示する簡単なWebアプリケーションの作成(オプション)

- 40.5.2.3.1 META-INF/application.xml

- 40.5.2.3.2 WEB-INF/web.xml

- 40.5.2.3.3 ヘルプ・コンテンツとリソース

- 40.5.3 JDeveloperでのカスタム・トランスポートのヘルプの提供方法

- 40.5.4 トランスポート・プラグインのヘルプのパッケージ化

41 JDeveloper用のカスタム・トランスポート・プロバイダの開発

- 41.1 はじめに

- 41.2 サービスのランタイムとサービスの構成

- 41.2.1 オフライン・メソッド

- 41.2.2 オフラインで作業する場合の制限

- 41.2.3 オフライン(リモート・サーバーあり)での作業

- 41.2.4 オフライン・モードでのトランスポートのブートストラップ

- 41.3 JDeveloper用のトランスポートのパッケージ化

- 41.4 オフライン・ツール用のカスタム・トランスポート・プロバイダ・リファレンス

- 41.4.1 異なるモードでの動作

- 41.4.2 TransportProviderFactory

- 41.4.3 TransportManagerHelperメソッド

42 カスタム・トランスポート・プロバイダのパッケージ化とデプロイ

- 42.1 パッケージ化とデプロイメントの概要

- 42.1.1 カスタム・トランスポート・プロバイダのコンポーネント

- 42.1.2 カスタム・トランスポート・プロバイダのリソース

- 42.2 トランスポート・プロバイダのパッケージ化

- 42.2.1 トランスポートJARファイルのパッケージ化

- 42.2.2 トランスポートEARファイルのパッケージ化

- 42.2.3 JDeveloper用のカスタム・トランスポート・プラグイン登録

- 42.3 トランスポート・プラグインのインストール

- 42.4 トランスポート・プロバイダのデプロイ

- 42.4.1 トランスポートの登録

- 42.5 トランスポート・プロバイダのアンデプロイ

- 42.6 クラスタへのデプロイ

43 サンプル・ソケット・トランスポート・プロバイダの作成

- 43.1 サンプル・ソケット・トランスポート・プロバイダの設計

- 43.1.1 サンプルによって説明される概念

- 43.1.2 サンプルの基本アーキテクチャ

- 43.1.3 構成のプロパティ

- 43.2 サンプルの場所とディレクトリ構造

- 43.3 サンプルのビルドとデプロイ

- 43.3.1 環境の設定方法

- 43.3.2 サンプル・トランスポート・プロバイダの構築方法

- 43.3.3 サンプル・トランスポート・プロバイダのデプロイ方法

- 43.3.4 サンプル・トランスポート・プロバイダのJDeveloperへの登録

- 43.4 ソケット・トランスポートのサンプル・プロジェクトの作成

- 43.4.1 プロジェクトの作成

- 43.4.2 ビジネス・サービスの作成

- 43.4.3 プロキシ・サービスの作成

- 43.4.4 パイプラインの作成

- 43.4.5 プロキシ・サービスとパイプラインの接続

- 43.5 ソケット・トランスポート・プロバイダのテスト

- 43.5.1 テストするためのサンプルのサーバーとクライアントの使用

- 43.5.1.1 サンプルの外部サービスの起動

- 43.5.1.2 サンプルの初期化サービスの起動

- 43.5.2 テスト・コンソールの使用

第VII部 アーティファクトとサービスの共有

44 リソースおよび構成のインポートとエクスポート

- 44.1 リソースのインポートとエクスポートについて

- 44.1.1 リソースのエクスポートについて

- 44.1.1.1 エクスポート時のデータ暗号化

- 44.1.2 リソースのインポートについて

- 44.1.2.1 インポート・パフォーマンスの改善

- 44.1.2.2 サービス・アカウントまたはサービス・キー・プロバイダのインポート

- 44.1.2.3 インポート時の操作設定の保持

- 44.1.2.4 インポート時のセキュリティ構成の保持

- 44.1.2.4.1 セキュリティおよびポリシーの構成を保持

- 44.1.2.4.2 資格証明の保持

- 44.1.2.4.3 アクセス制御の保持

- 44.1.2.5 インポート後の環境値のカスタマイズ

- 44.2 JDeveloperでのリソースのインポートとエクスポート

- 44.2.1 Oracle JDeveloperで構成JARファイルにリソースをエクスポートする方法

- 44.2.2 Oracle JDeveloperでサーバーにリソースをエクスポートする方法

- 44.2.3 JDeveloperでリソースをインポートする方法

- 44.3 Oracle Service Busコンソールでのリソースのインポートとエクスポート

- 44.3.1 コンソールで構成JARファイルにリソースをエクスポートする方法

- 44.3.2 コンソールで構成JARファイルからリソースをインポートする方法

- 44.3.3 コンソールでZIPファイルからリソースをインポートする方法

- 44.3.4 コンソールでURLからリソースをインポートする方法

- 44.4 Service Bus構成のオフラインでのエクスポート

- 44.4.1 エクスポート・プロセスについて

- 44.4.2 Service Bus構成のエクスポートの準備

- 44.4.2.1 始める前に

- 44.4.2.2 エクスポート設定ファイルの作成

- 44.4.2.3 環境の構成

- 44.4.3 Service Bus構成のオフラインでのエクスポート

- 44.4.3.1 コマンド行を使用した構成のオフライン・エクスポート

- 44.4.3.2 Antを使用した構成のオフライン・エクスポート

- 44.4.3.3 WLSTを使用した構成のオフライン・エクスポート

- 44.4.4 エクスポート設定ファイルの形式、サンプルおよびスキーマ

- 44.4.4.1 エクスポート設定ファイルの形式

- 44.4.4.2 検証

- 44.4.4.3 包含ルールおよび除外ルール

- 44.4.4.4 エクスポート設定ファイルのサンプル

- 44.4.4.5 エクスポート設定ファイルのスキーマ定義

45 メタデータ・サービス・リポジトリを使用したデータの共有

- 45.1 Service BusおよびMDSリポジトリ

- 45.2 MDSリポジトリの管理

- 45.3 MDSリポジトリを使用したアーティファクトの共有

- 45.3.1 Service BusアーティファクトをMDSリポジトリにパブリッシュする方法

- 45.4 MDSリポジトリに格納されたアーティファクトの使用

- 45.4.1 リソース・ブラウザを使用してMDSリポジトリのアーティファクトを使用する方法

- 45.4.2 MDSリポジトリのアーティファクトをService Busプロジェクトに追加する方法

- 45.4.3 MDSリポジトリのWSDLファイルからビジネス・サービスを作成する方法

- 45.4.4 MDSリポジトリのWADLファイルからビジネス・サービスを作成する方法

- 45.4.5 MDSリポジトリのWSDLファイルをRESTサービスとして公開する方法

- 45.4.6 SOA-MDS接続を使用してプロジェクト概要ファイルを開く

46 UDDIレジストリの操作

- 46.1 UDDI、UDDIレジストリおよびWebサービス

- 46.1.1 UDDI仕様の基本概念

- 46.1.2 Service BusでUDDIレジストリを使用する利点

- 46.1.3 UDDIエンティティの概要

- 46.2 Service BusとUDDI

- 46.2.1 UDDIレジストリのURL

- 46.2.2 UDDIレジストリのセキュリティ構成

- 46.2.3 認証の構成およびUDDIレジストリ

- 46.2.4 UDDIレジストリへのプロキシ・サービスのパブリッシュについて

- 46.2.5 UDDIレジストリからのビジネス・サービスのインポートについて

- 46.2.5.1 ビジネス・エンティティおよびパターンについて

- 46.3 サービスの同期化の維持

- 46.3.1 プロキシ・サービスの自動パブリッシュ

- 46.3.1.1 デフォルト・レジストリの変更

- 46.3.1.2 同期プロセスの自動パブリッシュ

- 46.3.2 UDDIサービスの自動インポート

- 46.3.2.1 インポートされたサービスの同期

- 46.3.2.2 インポートされたサービスのリンク解除

- 46.4 関連リファレンス

- 46.5 UDDIレジストリ・リソースの操作

- 46.5.1 Oracle Service BusコンソールでのUDDIレジストリ・リソースの表示方法

- 46.5.2 UDDIレジストリ・リソースの作成方法

- 46.5.3 JDeveloper UDDI接続からUDDIレジストリ・リソースを作成する方法

- 46.5.4 UDDIレジストリ・リソースの編集方法

- 46.5.5 デフォルトのUDDIレジストリ・リソースを指定する方法

- 46.5.6 UDDIレジストリ・リソースの削除方法

- 46.6 JDeveloperでのUDDIレジストリ・サービスの共有

- 46.6.1 JDeveloperでのUDDIレジストリ接続の作成方法

- 46.6.2 UDDIレジストリ・サービスからのビジネス・サービスの作成方法

- 46.6.3 UDDIレジストリからサービスをダウンロードする方法

- 46.7 Oracle Service BusコンソールでのUDDIレジストリ・サービスの共有

- 46.7.1 UDDIレジストリへのプロキシ・サービスのパブリッシュ

- 46.7.1.1 UDDIレジストリにプロキシ・サービスを自動的にパブリッシュする方法

- 46.7.1.2 UDDIレジストリにプロキシ・サービスを手動でパブリッシュする方法

- 46.7.2 UDDIレジストリからリソースをインポートする方法

- 46.7.3 インポートしたサービスを自動的に同期する方法

- 46.7.4 インポートしたサービスを手動で同期する方法

- 46.7.5 インポートされたサービスをUDDIレジストリからリンク解除する方法

- 46.8 Service BusとUDDIのビジネス・シナリオの例

- 46.8.1 プロキシ・サービスとUDDIレジストリの基本的な通信

- 46.8.2 Service Busのドメイン間デプロイメント

- 46.9 Service Busプロキシ・サービスからUDDIエンティティへのマッピング

- 46.9.1 Service Busプロキシ・サービスのUDDIマッピングの詳細

- 46.9.2 トランスポート属性

- 46.9.3 サービス・タイプ属性

- 46.9.4 Service Busサービスをサポートする標準tModel

- 46.9.5 マッピングの例

第VIII部 セキュリティ

47 Oracle Service Busセキュリティの理解

- 47.1 インバウンド・セキュリティ

- 47.2 アウトバウンド・セキュリティ

- 47.3 IDの伝播のオプション

- 47.3.1 OWSMポリシーをアタッチする場合のビジネス・サービスでのサービス・アカウントの使用

- 47.3.2 例: ユーザー名トークンによる認証

- 47.4 管理セキュリティ

- 47.5 アクセス制御ポリシー

- 47.5.1 プロキシ・サービスのアクセス制御の構成

- 47.5.2 アクセス制御ポリシーの管理

- 47.5.2.1 プロキシ・サービスの削除

- 47.5.2.2 プロキシ・サービスに割り当てられているアクセス制御ポリシーの削除

- 47.5.2.3 プロキシ・サービスの移動または名前の変更

- 47.5.2.4 プロキシ・サービスの操作の名前の変更

- 47.6 Oracle WebLogicセキュリティ・フレームワークの構成: 主な手順

- 47.7 コンテキスト・プロパティがセキュリティ・プロバイダに渡される

- 47.7.1 HTTPトランスポートレベル認証用のコンテキスト・プロパティ

- 47.7.2 アクセス制御およびカスタム認証用のContextHandlerプロパティ

- 47.7.3 トランスポート固有のその他のコンテキスト・プロパティ

- 47.7.4 管理者が提供するメッセージレベル認証用のコンテキスト・プロパティ

- 47.7.5 セキュリティ・プロバイダはプロパティ名を認識している必要がある

- 47.7.6 WebLogic Server管理チャネルがサポートされている

- 47.7.6.1 管理チャネルの使用: 主な手順

- 47.8 セキュリティ・プロバイダの使用

- 47.8.1 認証プロバイダの構成

- 47.8.2 カスタム認証プロバイダによるService Busリソースの保護

- 47.8.2.1 WebLogic認可プロバイダの使用法について

- 47.8.2.2 ALSBProxyServiceResourceオブジェクト

- 47.8.2.2.1 ALSBProxyServiceResourceの例

- 47.8.2.3 ProjectResourceV2オブジェクト

- 47.8.2.4 ConsoleResourceオブジェクト

- 47.8.3 セキュリティ・プロバイダ・ポリシー使用時のエラーについて

48 Oracle Service Busのセキュリティに関するFAQ

- 48.1 Service BusとWebLogic Serverのセキュリティにはどのような関係がありますか。

- 48.2 トランスポート・レベルのセキュリティとは何ですか。

- 48.3 Webサービス・セキュリティとは何ですか。

- 48.4 Webサービス・ポリシーとは何ですか。

- 48.5 Webサービス・ポリシーのアサーションとは何ですか。

- 48.6 アクセス制御ポリシーとWebサービス・ポリシーは同じものですか。

- 48.7 Webサービス・セキュリティのパススルーとは何ですか。

- 48.8 Webサービス・セキュリティのアクティブな仲介とは何ですか。

- 48.9 アウトバウンドWebサービス・セキュリティとは何ですか。

- 48.10 SAMLとは何ですか。

- 48.11 SAMLアサーションのサブジェクトIDの形式はカスタマイズ可能ですか。

- 48.12 証明書検索および検証フレームワークとは何ですか。

- 48.13 Service Busでは、プロキシ・サービスでのIDの伝播はサポートされますか。

- 48.14 シングル・サインオンはService Busでサポートされますか。

- 48.15 セキュリティ・エラーはモニターされますか。

- 48.16 MBeanのセキュリティを構成できますか。

49 ビジネス・サービスとプロキシ・サービスの保護

- 49.1 ポリシーの概要

- 49.2 ビジネス・サービスとプロキシ・サービスのセキュリティおよびセキュリティ・ポリシー

- 49.2.1 Service Busのセキュリティ・ポリシー

- 49.2.2 ポリシーのオーバーライド

- 49.2.3 セキュリティ設定

- 49.2.4 グローバル・ポリシー

- 49.2.5 ビジネス・サービスのサービス・アカウント

- 49.2.6 アクティブなプロキシ・サービスのセキュリティ関連の検証

- 49.3 JDeveloperでのポリシーのアタッチと構成

- 49.3.1 JDeveloperでのOracle Web Services Managerポリシーのアタッチ方法

- 49.3.2 JDeveloperでポリシーのオーバーライド値を定義する方法

- 49.3.3 JDeveloperでプロキシ・サービスのカスタム認証を構成する方法

- 49.3.3.1 JDeveloperでのプロキシ・サービスのカスタム認証の構成

- 49.3.4 JDeveloperでプロキシ・サービスのサービス・キー・プロバイダを指定する方法

- 49.3.5 JDeveloperでWebサービスのポリシー施行を指定する方法

- 49.4 Oracle Service Busコンソールでのポリシーのアタッチと構成

- 49.4.1 コンソールでのOracle Web Services Managerポリシーのアタッチ方法

- 49.4.2 コンソールでポリシーのオーバーライド値を定義する方法

- 49.4.3 コンソールでプロキシ・サービスのカスタム認証を構成する方法

- 49.4.3.1 コンソールでのプロキシ・サーバーのカスタム認証の構成

- 49.4.4 コンソールでプロキシ・サービスのサービス・キー・プロバイダを指定する方法

- 49.4.5 コンソールでWebサービスのポリシー施行を指定する方法

- 49.5 Service Busクライアント・アクセス・セキュリティの構成

- 49.5.1 トランスポート・レベルのアクセス・ポリシーの構成方法

- 49.5.1.1 ポリシー・エディタを開くためのHTTP URLリンクの有効化

- 49.5.1.2 トランスポート・レベルでのアクセス・ポリシーの構成

- 49.5.2 メッセージ・レベルのアクセス・ポリシーの構成方法

- 49.5.3 ポリシー条件の追加方法

- 49.6 メッセージ内の個人情報の非表示

- 49.6.1 個人情報を非表示にする方法

- 49.6.1.1 JDeveloperを使用した個人情報の非表示

- 49.6.1.2 コンソールを使用した個人情報の非表示

50 Webサービスのメッセージ・レベルでのセキュリティの構成

- 50.1 メッセージ・レベルのセキュリティについて

- 50.1.1 メッセージ・レベルのセキュリティの一連のアクションのサンプル

- 50.2 プロキシ・サービスのメッセージ・レベルのアクセス制御ポリシー

- 50.3 プロキシ・サービスのメッセージ・レベルのセキュリティの構成

- 50.3.1 アクティブな仲介プロキシ・サービスの作成: 主な手順

- 50.3.2 パススルー・プロキシ・サービスの作成: 主な手順

- 50.4 ビジネス・サービスのメッセージ・レベルのセキュリティの構成:主な手順

- 50.5 サービス・アイデンティティ証明書拡張の使用方法

- 50.5.1 プロキシ・サービスの有効なWSDLの証明書ID拡張の発行

- 50.5.2 ビジネス・サービスでの証明書ID拡張の消費方法

- 50.6 カスタムWS-Policy文の例

- 50.6.1 例: SOAP本体およびヘッダー部分の暗号化

- 50.6.2 例: ビジネス・サービスの暗号化ポリシー

- 50.6.3 例:カスタムSOAPヘッダーの暗号化

- 50.6.4 例: メッセージ本体とヘッダーの署名

- 50.6.5 例: SAML Holder-of-KeyによるSOAP本体の署名

- 50.6.6 例: SAML Sender-Vouchesによる認証、署名および暗号化

- 50.7 アウトバウンドWS-Securityの無効化

51 トランスポート・レベルのセキュリティの構成

- 51.1 HTTPSのトランスポート・レベルでのセキュリティの構成

- 51.1.1 HTTPSの認証レベル

- 51.1.2 インバウンドHTTPSセキュリティの構成:主な手順

- 51.1.3 アウトバウンドHTTPSセキュリティの構成:主な手順

- 51.2 HTTPのトランスポート・レベルでのセキュリティの構成

- 51.2.1 インバウンドHTTPセキュリティの構成:主な手順

- 51.2.2 アウトバウンドHTTPセキュリティの構成:主な手順

- 51.2.3 アウトバウンドHTTPセキュリティのカスタム認証の使用

- 51.3 JMSのトランスポート・レベルでのセキュリティの構成

- 51.3.1 インバウンドJMSトランスポート・レベル・セキュリティの構成:主な手順

- 51.3.2 アウトバウンドJMSトランスポート・レベル・セキュリティの構成:主な手順

- 51.4 SFTPトランスポートのトランスポート・レベルでのセキュリティの構成

- 51.4.1 双方向認証の実行方法

- 51.4.2 known_hostsファイルの使用

- 51.4.3 SFTPトランスポート認証プロセス

- 51.4.3.1 プロキシ・サービスへの一方向のインバウンド・ダウンロード

- 51.4.3.2 ビジネス・サービスからの一方向のアウトバウンド・アップロード

- 51.4.4 インバウンドSFTPトランスポート・レベル・セキュリティの構成:主な手順

- 51.4.5 アウトバウンドSFTPトランスポート・レベル・セキュリティの構成:主な手順

- 51.4.6 インポート時に保持されるSFTPのセキュリティ属性

- 51.4.7 SFTP資格証明のライフサイクル

- 51.5 電子メール、FTP、およびファイル・トランスポート・レベルのセキュリティ

- 51.5.1 電子メールとFTPトランスポート・レベルのセキュリティ

- 51.5.2 ファイル・トランスポート・セキュリティ

- 51.6 SBトランスポートのトランスポート・レベルでのセキュリティの構成

- 51.6.1 サービス・バス(SB)トランスポートを使用したSAML認証の構成

- 51.7 WSトランスポートのトランスポート・レベルでのセキュリティの構成

- 51.7.1 Webサービスの信頼性のあるメッセージングの定義

- 51.7.2 WLS Consoleに表示されるWSトランスポート・リソース

- 51.7.3 Webサービスの信頼性のあるメッセージングを構成するためのWS-Policyファイルの使用

- 51.7.3.1 構成済のWS-RMポリシー・ファイル

- 51.7.4 アクティブ化の前に必要なRM WS-Policy

- 51.7.5 非同期レスポンス

- 51.7.6 プロキシ・サービスの認証

- 51.7.7 インポート時のセキュリティ構成の保持

- 51.7.8 インバウンド/アウトバウンドWSトランスポート・レベルのセキュリティの構成

- 51.8 WebSphereメッセージ・キュー・トランスポートのトランスポート・レベルでのセキュリティの構成

- 51.8.1 インバウンドMQトランスポート・レベル・セキュリティの構成:主な手順

- 51.8.2 アウトバウンドMQトランスポート・レベル・セキュリティの構成:主な手順

- 51.9 メッセージ・コンテキストでのトランスポート・レベルのセキュリティ要素

52 Oracle Web Services Managerを使用したOracle Service Busのセキュリティ

- 52.1 Oracle Web Services ManagerとOracle Service Busの統合について

- 52.1.1 セキュリティ・プロバイダ

- 52.1.1.1 JPSプロバイダ

- 52.1.1.2 CSSプロバイダ

- 52.2 Oracle Service BusでのOracle Web Services Managerの使用

- 52.2.1 Oracle Service BusサービスへのOracle Web Services Managerポリシーの付加

- 52.2.1.1 ポリシーのオーバーライド

- 52.2.2 SAMLの構成

- 52.2.3 WS標準をサポートするためのWSDLファイルの通知

- 52.2.3.1 WSポリシーのためのWSDL問合せパラメータ・リファレンス

- 52.2.4 デプロイメントに関する考慮事項

- 52.2.5 監査

- 52.2.6 統計のモニター

- 52.2.7 事前定義済ポリシーとサポートされないアサーション

- 52.2.7.1 事前定義済ポリシー

- 52.2.7.2 wss_http_token_*_policyのガイドライン

- 52.2.7.3 OWSM認証ポリシーのガイドライン

- 52.2.7.4 OWSMポリシーおよびSOAP with Attachments (SwA)

- 52.2.7.5 OWSMポリシーおよびMTOM形式のメッセージ

- 52.2.7.6 OWSMポリシーを使用したWS-ReliableMessagingのサポート

- 52.2.7.6.1 WS-RMポリシーを使用したプロキシ・サービスについて

- 52.2.7.6.2 WS-RMポリシーを使用したビジネス・サービスについて

- 52.2.7.6.3 エンドツーエンド・メッセージの信頼性

- 52.2.7.6.4 WS-RM相互運用性

- 52.2.7.6.5 WS-RMサブシステムのチューニング

- 52.2.7.7 サポートされないアサーション

- 52.2.8 カスタム・アサーション

- 52.3 OAuthを使用したRESTエンドポイントによるサービスの保護

- 52.3.1 サポートされているOAuthユースケース

- 52.3.2 Service BusでOAuthを使用するためのOracle Access Managementの構成

- 52.3.2.1 OAuthサーバーの構成

- 52.3.2.1.1 Oracle Access ManagementでのOAuthの有効化

- 52.3.2.1.2 IDMコンソールを使用した認可RESTコールバック・プラグイン・プロファイルの作成

- 52.3.2.1.3 IDM OAuthコンソールを使用したリソース・サーバー・プロファイルの作成

- 52.3.2.1.4 OAuth OWSMクライアント・プロファイルの作成

- 52.3.2.1.5 OAuthサーバー・プロファイル構成の更新

- 52.3.2.1.6 証明書のインポートとエクスポート

- 52.3.2.2 OWSMの構成

- 52.3.3 Service BusサービスへのOAuth OWSMポリシーのアタッチ

53 WS-PolicyによるOracle Service Busプロキシ・サービスおよびビジネス・サービスの保護

- 53.1 Webサービス・ポリシーについて

- 53.1.1 WS-SecurityとWS-Policyの関係

- 53.1.2 抽象および具象WS-Policy文

- 53.2 Oracle独自のセキュリティ・ポリシーのベスト・プラクティス

- 53.3 ポリシー・サブジェクトと有効ポリシー

54 Oracle Service BusでのSAMLの使用

- 54.1 IDのSAMLトークンへのマッピング

- 54.2 SAMLパススルーIDの伝播の構成

- 54.3 プロキシ・サービス・リクエストでのSAMLトークンの認証

- 54.4 サービス・バス(SB)トランスポートを使用したSAML認証の構成

- 54.5 SAMLのアイデンティティ切替えの使用

- 54.5.1 アイデンティティ切替えリソースの保護

- 54.6 Oracle Service BusにおけるSAMLのトラブルシューティング

55 カスタム認証の構成

- 55.1 Oracle Service Busのカスタム認証の概要

- 55.1.1 カスタム認証トークンの理解

- 55.1.2 カスタム認証トークンの使用とデプロイメント

- 55.1.3 トランスポート・レベルのカスタム認証の理解

- 55.1.3.1 インポート/エクスポートおよびトランスポート・レベルのカスタム・トークン認証

- 55.1.4 メッセージ・レベルのカスタム認証の理解

- 55.1.5 カスタム認証トークンから取得したIDの伝播

- 55.1.6 WS-Securityおよびカスタム・ユーザー名/パスワードとトークンの組合せ

- 55.2 XPath拡張の形式

- 55.3 カスタム・トークン用IDアサーション・プロバイダの構成

- 55.3.1 カスタム・トークンのオブジェクト・タイプ

- 55.3.2 IDアサーション・プロバイダでのカスタム・トークン・タイプの構成

- 55.3.2.1 IDアサーション・プロバイダでのカスタム・トークン・タイプの構成方法

- 55.3.2.2 MBeanでサポートするアクティブなタイプの設定

- 55.4 カスタム認証によるトランスポート・レベルのセキュリティの構成

- 55.4.1 アウトバウンド用のカスタム認証クラスの作成方法

- 55.4.2 トランスポート・レベルのカスタム認証の構成方法

- 55.5 メッセージ・レベルのカスタム認証の構成

- 55.5.1 プロキシ・サービスのメッセージ・レベルのカスタム認証の構成方法

56 .Net 2.0とメッセージ・レベルのセキュリティ

- 56.1 .NET 2.0とOracle Service Bus間のメッセージ・レベルのセキュリティ

- 56.2 .NETとは

- 56.3 .NETでのメッセージ・レベルのセキュリティ構成

- 56.4 Oracle Service Busの.NETとのメッセージ・レベルのセキュリティの構成

- 56.4.1 サンプルのWSDLファイル

第IX部 Oracle Service Busサービスの完了

57 Oracle Service Busアプリケーションのデバッグ

- 57.1 デバッガの概要

- 57.1.1 デバッグ・サーバー

- 57.1.2 ローカルおよびリモートでのデバッグ

- 57.1.3 ブレークポイントを使用したデバッグ

- 57.1.3.1 条件ブレークポイントについて

- 57.1.3.1.1 条件式の動作

- 57.1.3.1.2 条件式の実行時評価エラー

- 57.1.3.1.3 スレッド・オプションについて

- 57.1.3.1.4 パス数について

- 57.1.3.1.5 条件式およびパス数の同時使用

- 57.1.3.2 例外ブレークポイントについて

- 57.1.3.2.1 パイプライン例外ブレークポイント

- 57.1.3.2.2 分割-結合例外ブレークポイント

- 57.1.4 JDeveloperデバッグ・ウィンドウ

- 57.1.5 XSLTエディタのデバッグ・サポート

- 57.2 プロジェクトおよびデバッガの構成

- 57.2.1 リモート・デバッグ用に実行構成を作成する方法

- 57.2.2 デバッグ用の実行構成を作成する方法

- 57.3 デバッガへのアクセス

- 57.4 Service Busアプリケーションのデバッグ

- 57.4.1 Service Busコンポーネントにブレークポイントを設定する方法

- 57.4.2 Service Busコンポーネントに例外ブレークポイントを設定する方法

- 57.4.3 ブレークポイントを使用してデバッグする方法

- 57.4.4 デバッグ・セッションでのステップ実行方法

- 57.4.5 デバッグから終了または連結解除する方法

- 57.5 デバッガ・ウィンドウでの操作

- 57.5.1 ブレークポイント・オプションの編集方法

- 57.5.2 ブレークポイント・グループの作成方法

- 57.5.2.1 ブレークポイント・グループの作成

- 57.5.2.2 既存のグループへのブレークポイントの追加

- 57.5.3 ブレークポイントを削除または無効にする方法

- 57.5.4 無効なブレークポイントを有効にする方法

- 57.5.5 現在のブレークポイントの変数値の表示および変更方法

- 57.5.6 ウォッチの追加方法

58 テスト・コンソールの使用

- 58.1 テスト・コンソールの概要

- 58.1.1 プロキシ・サービス・テスト

- 58.1.2 パイプライン・テスト

- 58.1.2.1 テスト・コンソールを使用したパイプラインでのトレースの実行

- 58.1.3 ビジネス・サービス・テスト

- 58.1.4 サービスの推奨テスト・アプローチ

- 58.1.5 HTTPリクエスト

- 58.2 テスト・コンソールへのアクセス

- 58.2.1 前提条件

- 58.2.2 Oracle Service Busコンソールからテスト・コンソールへのアクセス方法

- 58.2.2.1 コンポーネントの定義エディタからのテスト・コンソールへのアクセス

- 58.2.2.2 プロジェクト/フォルダ定義エディタからのテスト・コンソールへのアクセス

- 58.2.3 Fusion Middleware Controlからテスト・コンソールへのアクセス方法

- 58.2.4 JDeveloperからテスト・コンソールへのアクセス方法

- 58.2.4.1 JDeveloperからテスト・コンソールへのアクセス

- 58.2.4.2 JDeveloperからのトランスフォーメーションのテスト・コンソールへのアクセス

- 58.3 プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合のテスト

- 58.3.1 Service Busサービスのテスト方法

- 58.3.2 サービス内の添付ファイルのテスト方法

- 58.3.3 パイプライン処理のトレース方法

- 58.3.4 サービスのテスト結果の表示方法

- 58.4 MFLトランスフォーメーションのテスト

- 58.4.1 テスト・コンソールでのMFLトランスフォーメーションのテスト方法

- 58.4.2 MFLテスト・コンソールの例

- 58.5 XSLTトランスフォーメーションのテスト(リソース)

- 58.5.1 テスト・コンソールを使用したXSLTトランスフォーメーションのテスト方法

- 58.5.2 JDeveloper XSLTマッパーでXSLTトランスフォーメーションをテストする方法

- 58.6 XQueryトランスフォーメーションのテスト(リソース)

- 58.6.1 XQueryトランスフォーメーションのテストの前提条件とガイドライン

- 58.6.2 テスト・コンソールでのXQueryトランスフォーメーションのテスト方法

- 58.7 インライン式のテスト

- 58.7.1 XQuery式をテストする方法

- 58.7.2 XPath式をテストする方法

- 58.8 OWSMセキュリティを含むサービスのテスト

- 58.8.1 サービスとポリシーの制限

- 58.9 セキュリティとトランスポートについて

- 58.10 テスト・コンソールのアンデプロイ

- 58.10.1 ドメイン作成前のテスト・コンソールの割当て解除

- 58.10.2 サーバーが実行されている場合のテスト・コンソールの割当て解除

- 58.10.3 サーバーが実行されていない場合のテスト・コンソールの割当て解除

- 58.11 サービスのテスト・コンソール・ページ参照

- 58.11.1 テスト構成テスト・コンソール・プロパティ

- 58.11.2 サービス操作テスト・コンソール・プロパティ

- 58.11.3 リクエスト・ドキュメント・テスト・コンソール・プロパティ

- 58.11.4 セキュリティ・テスト・コンソール・プロパティ

- 58.11.5 認証テスト・コンソール・プロパティ

- 58.11.6 トランスポート・テスト・コンソール・プロパティ

- 58.11.6.1 テスト・コンソールのトランスポート設定

- 58.11.6.2 テスト・コンソールでのランタイムによるトランスポート設定の使用方法

- 58.11.7 添付ファイル・テスト・コンソール・プロパティ

59 Oracle Service Busサービスのデプロイ

- 59.1 デプロイメントの概要

- 59.2 デプロイする前に

- 59.2.1 構成ウィザードを使用したService Busドメインの作成

- 59.2.2 競合の解決

- 59.2.3 JMSリソースの構成

- 59.2.4 セキュリティの構成

- 59.3 Oracle Service Busコンソールからのデプロイ

- 59.3.1 コンソールからデプロイする方法

- 59.4 JDeveloperからのデプロイ

- 59.4.1 WebLogic Serverへの接続の作成方法

- 59.4.2 デプロイメント・プロファイルの作成方法

- 59.4.3 Service Busデプロイメントをカスタマイズする方法

- 59.4.4 Service Busプロジェクトまたはアプリケーションのデプロイ方法

- 59.4.5 以前の構成を使用したプロジェクトまたはアプリケーションのデプロイ方法

- 59.4.6 JDeveloperを使用したデプロイ時の動作

- 59.5 Fusion Middleware ControlでのService Bus構成JARファイルのデプロイ

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

- 59.6.1 構成のオンライン更新のための前提知識

- 59.6.2 オンライン・ビジネス・サービスの変更

- 59.6.3 オンライン・プロキシ・サービスの変更

- 59.6.4 オンライン・パイプラインの変更

- 59.7 クラスタでのオンライン構成の更新

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

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

60 Oracle Service Bus開発Mavenプラグインの使用

- 60.1 Oracle Service Bus Mavenプラグインの概要

- 60.1.1 Mavenライフサイクルのフェーズとゴール

- 60.1.2 POMファイルとArchetype

- 60.2 Mavenのインストールと構成

- 60.2.1 Oracle Service Bus開発Mavenプラグインの構成方法

- 60.2.2 Mavenオンライン・ヘルプの使用方法

- 60.3 Oracle Service Bus開発Mavenプラグインの使用

- 60.3.1 Service BusプロジェクトのPOMファイルの生成方法

- 60.3.2 ArchetypeからService BusプロジェクトのPOMファイルを生成する方法

- 60.3.2.1 JDeveloperでのArchetypeからのService BusプロジェクトのPOMファイルの作成

- 60.3.2.2 コマンド行を使用したArchetypeからのService BusプロジェクトのPOMファイルの生成

- 60.3.3 ArchetypeからService Busシステム・リソースのPOMファイルを生成する方法

- 60.3.3.1 JDeveloperでのArchetypeからのService Busシステム・リソースのPOMファイルの生成

- 60.3.3.2 コマンド行からのService Busシステム・リソースのPOMファイルの生成

- 60.3.4 POMファイルの生成のためのパラメータ

- 60.4 Service Bus開発Mavenプラグインのゴール

- 60.4.1 パッケージ

- 60.4.2 デプロイ

- 60.5 Oracle Service Bus開発MavenプラグインPOMファイルのサンプル

付録

A メッセージ・コンテキスト

- A.1 メッセージ・コンテキスト・モデル

- A.2 事前定義されたコンテキスト変数

- A.3 メッセージ関連の変数

- A.3.1 header変数

- A.3.2 body変数

- A.3.3 attachments変数

- A.3.4 メッセージ・タイプおよびコンテキスト変数

- A.3.5 Body変数とAttachments変数内のバイナリ・コンテンツ

- A.3.5.1 ビジネス・プロセスへの添付付きSOAPの送信

- A.3.6 Body変数内のJavaコンテンツ

- A.3.7 Bodyコンテンツのストリーミング

- A.3.7.1 コンテンツ・ストリーミングを使用する際のベスト・プラクティス

- A.3.8 添付ファイルのストリーミング

- A.3.8.1 インバウンド・メッセージの処理

- A.3.8.2 発信応答メッセージの処理

- A.3.9 XOP/MTOMサポート

- A.3.9.1 パイプラインのXOP/MTOM

- A.3.9.1.1 参照によるバイナリ・オプション

- A.3.9.1.2 値によるバイナリ・オプション

- A.3.9.2 ビジネス・サービスのXOP/MTOM

- A.3.9.2.1 アウトバウンド・メッセージのXOP/MTOM

- A.3.9.3 XOP/MTOM添付ファイルのストリーミング

- A.3.10 カスタムMIMEヘッダー

- A.4 inbound変数とoutbound変数

- A.4.1 Inbound変数とOutbound変数の下位要素

- A.4.1.1 service

- A.4.1.2 transport

- A.4.1.3 security

- A.4.2 関連トピック

- A.5 operation変数

- A.6 fault変数

- A.6.1 エラー・コード

- A.6.2 エラーの詳細

- A.6.3 XML解析エラー(PayloadDetail)

- A.7 messageID変数

- A.8 コンテキスト変数の初期化

- A.8.1 Attachmentsコンテキスト変数の初期化

- A.8.2 HeaderおよびBodyコンテキスト変数の初期化

- A.8.2.1 SOAPサービス

- A.8.2.2 XMLサービス(非SOAP)

- A.8.2.3 メッセージ・サービス

- A.9 コンテキスト変数に対する操作の実行

- A.9.1 $body

- A.9.2 $header

- A.9.3 関連トピック

- A.10 ディスパッチするメッセージの作成

- A.10.1 SOAPサービス

- A.10.2 XMLサービス(非SOAP)

- A.10.3 メッセージング・サービス

- A.10.3.1 電子メール・メッセージでのバイナリ・コンテンツの送信について

- A.10.4 関連トピック

- A.11 メッセージ・コンテキスト・スキーマ

- A.12 エラー・スキーマ

B XPath拡張関数

- B.1 相互参照関数

- B.1.1 lookupPopulatedColumns

- B.1.2 lookupXRef

- B.1.3 lookupXRef1M

- B.1.4 markForDelete

- B.1.5 populateLookupXRefRow

- B.1.6 populateXRefRow

- B.1.7 populateXRefRow1M

- B.2 ドメイン値マップ関数

- B.2.1 lookup

- B.2.2 lookupValue

- B.2.3 lookupValue1M

- B.3 カスタムXPath関数の作成

- B.3.1 Service Busでのカスタム関数の登録

- B.3.2 カスタム関数のJavaクラスの作成とパッケージ化

- B.3.2.1 クラスとメソッドの作成

- B.3.2.1.1 1次元配列の使用

- B.3.2.2 カスタム関数クラスのパッケージ化

- B.3.3 カスタム関数の使用

- B.3.3.1 インラインXQuery式およびXQueryリソースでのカスタム関数

- B.3.3.2 XSLTリソースでのカスタム関数

- B.3.4 クラスタへのカスタム関数のデプロイ

C Oracle Service Bus API

- C.1 リソースの更新とカスタマイズ

- C.2 管理およびモニター

- C.3 デプロイメント

D トランスポートSDKのインタフェースおよびクラス

- D.1 はじめに

- D.2 スキーマで生成されるインタフェース

- D.3 汎用クラスおよびインタフェース

- D.3.1 汎用クラスのサマリー

- D.3.2 汎用インタフェースの概要

- D.4 SourceおよびTransformerクラスとインタフェース

- D.4.1 SourceおよびTransformerインタフェースの概要

- D.4.2 SourceおよびTransformerクラスの概要

- D.5 リクエストおよびレスポンス・メッセージのメタデータおよびヘッダーの表現

- D.5.1 メッセージ・コンテンツの実行時表現

- D.5.2 インタフェース

- D.6 ユーザー・インタフェースの構成

- D.6.1 UIインタフェースの概要

- D.6.2 UIクラスの概要

E トランスポートSDK UMLシーケンス・ダイアグラム

- E.1 Service Busランタイムの着信メッセージ

- E.2 Service Busランタイムの発信メッセージ

- E.3 設計時のサービスの登録

F XQuery-SQLマッピング・リファレンス

- F.1 IBM DB2/NT 8

- F.2 Microsoft SQL Server

- F.3 Oracle8i、8.1.x

- F.4 Oracle 9i以降

- F.5 Sybase 12.5.2 (およびそれ以上)

- F.6 ベース(汎用) RDBMSデータ型マッピング

G ワーク・マネージャとスレッド

- G.1 スレッドの主要な概念

- G.2 パイプライン・アクション

- G.2.1 ルート・アクション

- G.2.2 パブリッシュ・アクション

- G.2.3 サービス・コールアウト・アクション

- G.3 ワーク・マネージャ

- G.3.1 ワーク・マネージャの構成

- G.3.2 ワーク・マネージャの優先度

- G.4 ワーク・マネージャの指定

表一覧

- 1-1 Service Bus開発ロードマップ - トップダウン方法

- 1-2 Service Bus開発ロードマップ - ボトムアップ方法

- 3-1 Service Busプロジェクトのネーミングの制約

- 5-1 Service Bus概要エディタ

- 5-2 テクノロジ・コンポーネント

- 5-3 アプリケーション・コンポーネント

- 5-4 拡張コンポーネント

- 5-5 Service Bus概要エディタからのService Busエディタの起動

- 7-1 JBoss初期コンテキスト・ファクトリの環境パラメータ

- 10-1 分割-結合の通信操作

- 10-2 分割-結合のフロー制御操作

- 10-3 分割-結合の割当て操作

- 11-1 上位のWSDL要素

- 12-1 パイプライン・コンポーネント

- 12-2 メッセージ・フローでのリクエスト・メッセージのパス

- 12-3 メッセージ・フローでのレスポンス・メッセージのパス

- 12-4 通信アクション

- 12-5 フロー制御アクション

- 12-6 メッセージ処理アクション

- 12-7 レポート・アクション

- 12-8 トランスポート・ヘッダー・アクションで指定するトランスポート・ヘッダーの値の制限

- 12-9 エラー・ハンドラのスコープ

- 12-10 Service Busの事前定義されたコンテキスト変数

- 12-11 配信の保証のタイプ

- 12-12 配信の保証のルール

- 12-13 Service BusのWS-I準拠チェック

- 13-1 「メッセージ・フローの編集」ページのアイコンとオプション

- 13-2 標準リシーケンスのオプション

- 13-3 ベスト・エフォート・リシーケンスのオプション

- 14-1 パイプライン - 通信アクション

- 14-2 パイプライン - フロー制御アクション

- 14-3 パイプライン - メッセージ処理アクション

- 14-4 パイプライン - レポート・アクション

- 14-5 ステージ構成の編集タスク

- 14-6 サービス・コールアウトの構成オプション

- 14-7 ログ・アクションの重大度

- 14-8 エラー・ハンドラの表示と変更

- 15-1 パレット

- 15-2 エディタのテキスト・フィールドに項目を貼り付ける方法

- 15-3 新しい変数の構造の作成

- 16-1 標準リシーケンスのオプション

- 16-2 ベスト・エフォート・リシーケンス・オプション

- 17-1 パイプライン - 通信アクション

- 17-2 パイプライン - フロー制御アクション

- 17-3 パイプライン - メッセージ処理アクション

- 17-4 パイプライン - レポート・アクション

- 17-5 ステージ構成の編集タスク

- 17-6 ログ・アクションの重大度

- 23-1 文字デリミタ

- 23-2 「検索」のオプション

- 23-3 「移動先」のオプション

- 23-4 サポートされるMFLデータ型

- 23-5 COBOLのデータ型

- 23-6 Format Builderのフィールド説明プロパティ

- 23-7 Format Builderのフィールド出現プロパティ

- 23-8 Format Builderのフィールド属性

- 23-9 Format Builderの長さで定義されるフィールド終了プロパティ

- 23-10 Format Builderの埋め込み長で定義されるフィールド終了プロパティ

- 23-11 Format Builderのデリミタで定義されるフィールド終了プロパティ

- 23-12 Format Builderのリテラル・データ型のフィールド・プロパティ

- 23-13 Format Builderのグループ説明プロパティ

- 23-14 Format Builderのグループ出現プロパティ

- 23-15 Format Builderのグループ属性

- 23-16 Format Builderのグループ・デリミタ・プロパティ

- 23-17 Format Builderの参照説明プロパティ

- 23-18 Format Builderの参照説明プロパティ

- 25-1 JCAトランスポートのエンドポイント・プロパティ

- 25-2 JCAトランスポート・プロパティ

- 27-1 ビジネス・サービスのDSPトランスポート構成プロパティ

- 28-1 ビジネス・サービス用のEJBトランスポート・プロパティ

- 29-1 Accept-Encoding処理

- 29-2 プロキシ・サービス用のHTTPトランスポート・プロパティ

- 29-3 ビジネス・サービス用のHTTPトランスポート・プロパティ

- 29-4 HTTPビジネス・サービスのレスポンス・コード処理

- 29-5 プロキシ・サービス用の電子メール・トランスポート・プロパティ

- 29-6 ビジネス・サービス用の電子メール・トランスポート・プロパティ

- 29-7 プロキシ・サービス用のファイル・トランスポート・プロパティ

- 29-8 ビジネス・サービス用のファイル・トランスポート・プロパティ

- 29-9 プロキシ・サービス用のFTPトランスポート・プロパティ

- 29-10 ビジネス・サービス用のFTPトランスポート・プロパティ

- 29-11 UDDIレジストリからインポートされるプロパティ

- 29-12 プロキシ・サービス用のSFTPトランスポート・プロパティ

- 29-13 トランスポート・ヘッダーとメタデータ

- 29-14 ビジネス・サービス用のSFTPトランスポート・プロパティ

- 29-15 SFTPトランスポートの環境値

- 30-1 プロキシ・サービス用のJEJBトランスポート・プロパティ

- 30-2 ビジネス・サービスのためのJEJBトランスポート構成

- 31-1 メッセージIDと相関IDのパターンの相違点

- 31-2 プロキシ・サービス用のJMSトランスポート・プロパティ

- 31-3 JMSトランスポート・ヘッダー

- 31-4 ビジネス・サービス用のJMSトランスポート・プロパティ

- 33-1 プロキシ・サービス用のMQトランスポート・プロパティ

- 33-2 ビジネス・サービス用のMQトランスポート・プロパティ

- 33-3 MQトランスポートとMQ接続リソースの環境値

- 33-4 MQトランスポート・ヘッダー

- 34-1 BPELトランスポートの環境変数

- 34-2 エンドポイントURIの指定

- 34-3 ビジネス・サービス用のBPELトランスポート・プロパティ

- 35-1 SBトランスポートの環境変数

- 35-2 プロキシ・サービス用のSBトランスポート・プロパティ

- 35-3 ビジネス・サービス用のSBトランスポート・プロパティ

- 36-1 ビジネス・サービス用のSOA-DIRECTトランスポート・プロパティ

- 36-2 SOA-DIRECTトランスポートの環境値

- 37-1 Tuxedo例外

- 37-2 任意のXMLサービスの場合のバッファ変換

- 37-3 メッセージング・サービスの場合のバッファ変換

- 37-4 プロキシ・サービス用のTuxedoトランスポート・プロパティ

- 37-5 ビジネス・サービス用のTuxedoトランスポート・プロパティ

- 38-1 ビジネス・サービスのWSトランスポート・プロパティ

- 38-2 プロキシ・サービスのWSトランスポート・プロパティ

- 39-1 組込みのトランスフォーメーション

- 43-1 サンプル・トランスポート・プロバイダの重要なディレクトリ

- 46-1 UDDIエンティティの概要

- 46-2 プロキシ・サービスの属性とサービス・タイプ

- 46-3 トランスポート属性

- 46-4 サービス・タイプの属性

- 46-5 CategorizationGroup tModelのタイプ

- 46-6 Categorization tModelのタイプ

- 46-7 Transport tModelのタイプ

- 46-8 Protocol tModelのタイプ

- 47-1 IDの伝播のオプション

- 47-2 トランスポートレベルのセキュリティ要件の組合せ

- 47-3 メッセージレベルのセキュリティ要件の組合せ

- 47-4 認証プロバイダ

- 47-5 HTTPトランスポート認証用のContextHandlerプロパティ

- 47-6 カスタム認証およびアクセス制御用のContextHandlerプロパティ

- 47-7 HTTPプロキシ・サービスのその他のContextHandlerプロパティ

- 49-1 サポートされるポリシー・カテゴリ

- 49-2 条件の述部のオプション

- 51-1 WSトランスポートの認証一覧

- 52-1 &wspおよび&wsspの問合せパラメータの有効および無効な組合せ

- 52-2 HTTPトランスポートを使用するWSDL (非SOAP)、XMLおよびメッセージングの各サービス・タイプでサポートされるOWSM事前定義済ポリシー

- 52-3 oracle/reliable_messaging_internal_api_policyプロパティ

- 52-4 サポートされないアサーション

- 58-1 プロキシ・サービスのテスト結果

- 58-2 MFLテスト・コンソールのプロパティ

- 58-3 デジタル署名と暗号化のシナリオ

- 58-4 IDポリシーのシナリオ(ポリシーにIDアサーションが含まれている場合)

- 58-5 テスト・コンソール・プロパティ - サービス操作

- 58-6 テスト・コンソール・プロパティ - リクエスト・ドキュメント

- 58-7 テスト・コンソール・プロパティ - セキュリティ

- 58-8 テスト・コンソール・プロパティ - 認証

- 58-9 テスト・コンソール・プロパティ - トランスポート

- 58-10 テスト・コンソールで指定するトランスポート・ヘッダーとメタデータの値の制限

- 58-11 プロキシ・サービス・テスト・コンソール・プロパティ

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

- 60-1 Service BusのMavenライフサイクルのフェーズ

- 60-2 servicebus:packageゴールのパラメータ

- 60-3 servicebus:deployゴールのパラメータ

- A-1 Service Busの事前定義されたコンテキスト変数

- A-2 attachments変数の下位要素

- A-3 メッセージのマッピング

- A-4 service要素の下位要素

- A-5 transport要素の下位要素

- A-6 security要素の下位要素

- A-7 fault変数の下位要素

- A-8 コンテキスト変数の初期化

- B-1 カスタム関数登録ファイルのプロパティ

- B-2 カスタム関数でサポートされるJavaメソッドの型

- F-1 IBM DB2データ型マッピング

- F-2 SQL Server 2000データ型マッピング

- F-3 Oracle 8.1.xデータ型マッピング

- F-4 Oracle 9i以降のデータ型マッピング

- F-5 Sybase 12.5.2データ型マッピング

- F-6 RDBMSデータ型マッピング

はじめに

ここでは、このガイド『Oracle Service Busでのサービスの開発』の表記規則について説明します。

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

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

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、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドで説明する新機能

ここでは、Oracle Service Busの新機能と変更された機能、およびこのガイドに記載されているその他の重要な変更について紹介し、詳細情報へのリンクを提供します。

既知の問題のリスト(リリース・ノート)は、「Oracle SOA製品の既知の問題」(http://www.oracle.com/technetwork/middleware/soasuite/documentation/soaknowissues12211-2873928.html)を参照してください。

12c (12.2.1.1.0)での新機能と変更された機能

このガイドには、Oracle Service Bus 12c (12.2.1.1.0)について、開発に関する次の新機能と変更された機能が含まれています。

- Service Busに、結果キャッシュの単一または複数のエントリを削除するためのAPIが搭載されました。「結果キャッシュのエントリの削除方法」を参照してください。

12c (12.2.1.1.0)に関するドキュメントの重要な変更

このリリースでは、ドキュメントの重要な変更はありません。

注意:

使用しているスキンによっては、このガイドで示される画面は実装状態と異なる場合があります。相違点は軽微なものです。

第I部 Oracle Service Busの紹介

この部では、Oracle Service Busと、Service Busサービスの作成に使用できる2つのインタフェースの概要について説明します。また、Service Bus環境の設定方法、およびOracle JDeveloperでService Bus概要エディタを使用してService Busサービスを作成する方法についても説明します。

この部は、次の章で構成されています。

- Oracle Service Busについて

- Oracle Service Busコンソールのスタート・ガイド

- JDeveloperでのOracle Service Busのスタート・ガイド

- JDeveloperの開発環境の設定

- JDeveloperでのOracle Service Busアプリケーションの開発

1 Oracle Service Busについて

この章では、Service Busの概要、そのアーキテクチャとコンポーネント、およびService Busを使用したサービスの開発方法について説明します。また、Service Busアプリケーションの開発手順と、様々な開発方法についても説明します。

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

- Oracle Service Busの概要

- Service Busアーキテクチャの概念

- Service Busコンポーネント

- Service Busメッセージング

- Service Busでのワーク・マネージャの使用

- Service Busのセキュリティ

- Service Busサービスの設計方法

- Service Busコンポーネントのネーミング・ガイドライン

- WebブラウザでのService Busリソースの表示

- アクセシビリティ・オプション

- その他のリソース

1.1 Oracle Service Busの概要

Oracle Service Busは、SOAライフ・サイクル管理用に設計された、構成ベースでポリシー駆動のEnterprise Service Busです。Oracle Service Busは、サービスの検出と仲介、迅速なサービス・プロビジョニングとデプロイメント、およびガバナンスに関する基盤機能を提供します。Service Busでは、スケーラビリティと信頼性の高いサービス志向の統合やサービス管理、また、異なる環境に対して従来のメッセージ・ブローカリングを提供します。さらに、インテリジェントなメッセージ・ブローカリングに、メッセージのルーティングや変換機能、およびサービスの監視や管理が融合されています。Service Busでは、業界標準を利用してサービスを接続し、高度な異質性、既存のミドルウェア、アプリケーションおよびデータ・ソースの接続、さらに既存の投資の保護に対応します。

Service Busは、大まかで緩やかに結合された標準ベースのサービスの構築と、ビジネス機能をサービス・コンシューマとバックエンド・ビジネス・サービスに接続できる中立コンテナの作成を、基盤となるインフラストラクチャとは無関係に行うというSOAの原則に基づいています。次の図にエンタープライズIT SOAランドスケープにおけるService Busのサービス仲介者としての役割を示します。

図1-1 Service Busによる仲介

1.1.1 機能領域

次の図に、仮想化、メッセージング、セキュリティ、構成および実行時管理といったService Busの主な機能領域を示します。

図1-2 Service Busの機能

1.1.2 適応的なメッセージング

適応的なメッセージングは、柔軟性のあるメッセージ処理と、クライアントとサービス間の操作を提供します。たとえば、クライアントがHTTPでService Busを介してSOAPメッセージを送信し、次にService Busがそのメッセージを変換してバックエンドEJBを呼び出します。あるいは、クライアントがHTTPでREST/JSONメッセージを送信し、Service Busがそのメッセージを変換してバックエンドSOAP/XMLサービスを呼び出します(または利用可能ないずれかのアダプタを使用します)。適応的なメッセージングでは、リクエスト/レスポンス、同期および非同期、分割-結合、パブリッシュ/サブスクライブなどの様々な通信パターンもサポートされます。単一のメッセージ・ライフ・サイクルで、インバウンド・メッセージとアウトバウンド・メッセージに異なるパターンを使用できます。

1.1.3 サービス・セキュリティ

Service Busでは、Webサービスに対して、Oracle Platform Security ServicesおよびOracle Web Services Manager (OWSM)に基づき、すべてのレベルのサービス・セキュリティが保証されます。カスタムまたはサード・パーティ製のセキュリティ・コンポーネントをプラグインできます。組込み機能によって、セキュリティを次のレベルで有効にすることにより、実装における柔軟性が確保されています。

- SSL、基本認証およびカスタム・セキュリティ資格証明などのトランスポート・レベルのセキュリティ

- WS-Security、SAML、ユーザーIDとパスワード、X509、署名と暗号化、およびカスタム・セキュリティ資格証明などのメッセージ・レベルのセキュリティ

- シングル・サインオンとロール・ベースのアクセスなどのコンソール・セキュリティ

- ポリシー・セキュリティ

1.1.4 サービス仮想化

サービス仮想化は、メッセージの操作と制御を通じて機敏性を提供します。Service Busでは、検証、変換、メッセージの内容に基づくルーティング、メッセージ内の複数の項目の並列処理、アラートのトリガー、およびエラー処理を使用して、メッセージ・フローの様々なポイントでメッセージを柔軟に制御できます。たとえば、Service Busには次の機能があります。

- メッセージ・ルーティングの外部サービスに対するXQueryベースのポリシーまたはコールアウト。

- ポイント・ツー・ポイントおよび1対多の両方のルーティング・シナリオ(パブリッシュ)に適用するルーティング・ポリシー。パブリッシュの場合、ルーティング・ポリシーはサブスクリプション・フィルタとして機能します。

- パイプラインを再構成せずにルートを変更できる、パイプラインから抽象化されたルーティング表。

- クライアントのユーザー定義のグループへの分類およびそれらのグループに基づいたルーティング・ポリシーの適用を行うためのIDベースのルーティング。

- 動的なコンテンツ・ベースのメッセージ・ルーティングおよびプロトコルの実行時選択などの条件付きルーティング。

- メッセージの情報追加、ルーティングの決定またはパイプラインの動作のカスタマイズに使用できるデータベース・ルックアップ。

- XQueryまたはXSLTマップを使用した変換。

1.1.5 構成フレームワーク

構成フレームワークにより、Service Bus本番環境とその関連リソースを完全に制御できます。フレームワークには、セッション管理、テスト・コンソールおよびインポート/エクスポート・ツールが含まれます。Service Bus構成はセッションで管理されるため、変更を行いながら現在の構成をロックする一意の機能が提供されます。Service Busでサービスについてのリクエストの受信と処理を継続しながら、セッションで構成の変更が行われます。現在のセッションをアクティブ化するまで、これらの変更がランタイム構成に影響を与えることはありません。このようにして、進行中の変更はサービスに影響を与えることなく実行できます。構成およびリソースに対して行った変更が追跡され、変更を元に戻すまたは変更のやり直し、競合の解決、リソース間の依存関係の維持、およびテスト・コンソールでの変更のテストを行うことができます。

組込みのテスト・コンソールは、パイプラインまたは分割-結合で使用されるリソースおよびインライン式の検証を行うブラウザ・ベースのテスト環境です。テスト・コンソールを使用して、テスト・オブジェクト(パイプライン、ビジネス・サービスまたはXQuery式など)の構成、テストの実行、テスト結果の表示を行います。サービスのテスト時には、指定されたトレース・ポイントでメッセージの状態を調べるために、メッセージ・フローのトレースができます。

Service Busでは、リソースやプロジェクトをエクスポートおよびインポートして、異なる環境間で構成データを伝播できます。たとえば、開発ドメインからテスト・ドメイン、さらに本番ドメインへ構成を転送できます。インポート機能とエクスポート機能を使用すると、環境間でリソースの依存関係を維持して、環境変数を保持できます。

構成フレームワークには、UDDIレジストリを使用したサービスの検出、パブリッシュおよび同期(UDDIによるサービスの自動インポートやサービスの同期など)を行うためのメタデータ駆動のインタフェースも含まれます。

1.1.6 サービス管理

サービス管理には、監視、アラートおよびレポート用のランタイム構成ツールの強力なセットが含まれます。Service Busは、SOA全体のサービスを管理するためにFusion Middleware Controlに完全に統合されています。サービス管理では、次の操作が可能です。

- メッセージ呼出し、エラー、パフォーマンス特性、渡されるメッセージおよびSLA違反について統計値を収集します。

- SLAと、SNMPトラップとしてのパイプライン・アラートを送信し、サード・パーティのエンタープライズ・システム管理ソリューションとの統合を可能にします。

- システム処理とビジネス監査の両方を目的として、メッセージの選択された部分をログに記録します。

- メッセージの主要情報(検索索引として使用可能)を抽出してメッセージ・レポートを検索します。

- 広く採用されているサード・パーティ製のレポート・ツールおよびカスタムのエンタープライズ・システム管理フレームワークと統合します。

- 操作とデプロイメントのカスタマイズ用のオープン・インタフェース、JMX監視インタフェース、およびSNMPアラートをサポートします。

1.2 Service Busアーキテクチャの概念

Service Busは、着信するサービス・リクエスト・メッセージを処理して、ルーティング・ロジックを決定し、そのメッセージを他のサービス・コンシューマと互換性があるように変換を行う仲介機能です。HTTP(S)、JMS、ファイル、FTPなどのトランスポート・プロトコルを介してメッセージを受信し、同じトランスポート・プロトコルまたは別のトランスポート・プロトコルを使用してメッセージを送信します。サービスのレスポンス・メッセージは、これと逆のパスを辿ります。Service Busによるメッセージ処理は、メタデータによって駆動され、メッセージ・フローの定義(パイプライン)で指定されます。

Service Busは、SOAP、HTTPおよびJava Messaging Service (JMS)などの基準に基づいて、メッセージ配信サービスを提供します。ネイティブのデータ型としてXMLがサポートされており、他のデータ型を処理するために、その他のデータ型も提供されます。Service Busでは、サービス・クライアントとビジネス・サービスとの間に疎結合を確立する一方で、セキュリティ制御とモニターを一元的に管理できます。ステージングによって開発環境から本番環境へカスタマイズおよび伝播可能なメタデータに、ポリシー、サービスおよび関連するリソース構成を永続化して保存します。メッセージ・ブローカリング・エンジンは、メタデータ・キャッシュからこの構成情報にアクセスします。

1.2.1 メッセージ処理

メッセージには、アプリケーション・プロセスについてのデータまたはステータス情報や、受信側に対する指示などが含まれます。Service Busでは、コンテンツに基づいてメッセージをルーティングし、コンテンツに対して変換を実行できます。この処理は、Service Busのトランスポート・レイヤーおよびバインディング・レイヤーを介して実行されます。

Service Busを介したメッセージの処理では、次の一連のイベントが実行されます。

1. クライアントは、特定の転送プロトコルを使用してService Busにメッセージを送信します。

2. トランスポート・プロバイダは、インバウンド・メッセージを処理します。サービス・クライアント・エンドポイントとの通信を処理し、Service Busへのメッセージのエントリ・ポイントとして機能します。

3. バインディング・レイヤーは、メッセージの圧縮と解凍、メッセージのセキュリティ処理、パイプラインへのメッセージの引渡しを行います。

4. パイプラインは、変換、検証、ロギングおよびレポート作成を行い、メッセージをエンドポイント(ビジネス・サービスまたは別のプロキシ・サービスのいずれか)にルーティングします。

5. Service Busは、前述の手順と同様にレスポンス・メッセージを処理します。

次の図に、インバウンド・エンドポイント(プロキシ・サービス)からアウトバウンド・エンドポイント(この場合はビジネス・サービス)までの、Service Busを介したデータ・フローを示します。示されているトランスポートは、Service Busで利用可能なトランスポートのサブセットです。

図1-3 Oracle Service Busのメッセージ処理

以降の項では、このメッセージ処理に関連する各レイヤーについて説明します。

1.2.2 メッセージ処理でのプロキシ・サービスの役割

プロキシ・サービスは、サービス・コンシューマが管理対象のバックエンド・サービスに接続するために使用するインタフェースです。プロキシ・サービスは、Service Busがローカルに実装する仲介Webサービスの定義になっています。プロキシ・サービス・インタフェースは、Web Services Description Language (WSDL)またはWeb Application Definition Language (WADL)、およびそれが使用するトランスポートのタイプを考慮して定義されます。

1.2.3 トランスポート・レイヤー(インバウンド)

インバウンド・トランスポート・レイヤーは、クライアント・サービス(またはサービス・コンシューマ)とService Busとの間にある通信レイヤーです。サービス・クライアント・エンドポイントとの通信を処理して、Service Busへのメッセージのエントリ・ポイントとして機能します。インバウンド・トランスポート・レイヤーは主に入力または出力ストリームのメッセージ・データを生のバイトとして処理します。トランスポート・レイヤーは、HTTP(S)、JMS、FTP、ファイル、電子メールなど、互換性のあるトランスポート・プロトコルをサポートします。データ処理には関与しませんが、レスポンス・メッセージをサービス・コンシューマに返し、エンドポイントURIやトランスポート・ヘッダーなどのメッセージのメタデータを処理します。

1.2.4 バインディング・レイヤー

インバウンドおよびアウトバウンドどちらのバインディング・レイヤーも、メッセージ処理で次の機能を実行します。

- 必要に応じたメッセージの圧縮および解凍

- メッセージのセキュリティの処理

- メッセージを渡してパイプラインを開始(リクエストとレスポンス)

1.2.5 メッセージ処理でのパイプラインの役割

パイプラインでは、ルーティング、変換、検証、パブリッシュ、レポート作成および例外管理など、Service Busを介したリクエスト・メッセージおよびレスポンス・メッセージのフローを定義します。これは、プロキシ・サービスのバインディング・レイヤーからメッセージを受け取り、変換または検証を実行して、アウトバウンド・サービス(プロキシまたはビジネス・サービスのいずれか)のバインディング・レイヤーにそのメッセージを転送します。その途中で、パイプラインは、その他のサービス、JavaオブジェクトまたはPOJOにコールアウトを行うことができます。

1.2.6 トランスポート・レイヤー(アウトバウンド)

アウトバウンド・トランスポート・レイヤーは、外部サービス(またはサービス・プロデューサ)とService Busとの間の通信機能を担います。Service Busからビジネス・サービスまたはプロキシ・サービスにメッセージを渡し、サービスからレスポンスを受信します。トランスポート・レベルでは、メッセージ・データは入力または出力ストリームの形式の生のバイトです。アウトバウンド・トランスポート・レイヤーは、HTTP(S)、JMS、FTP、ファイル、電子メールなど、互換性のあるトランスポート・プロトコルをサポートします。データ処理には関与しませんが、エンドポイントURIやトランスポート・ヘッダーなどのメッセージのメタデータを処理します。

1.2.7 メッセージ処理でのビジネス・サービスの役割

ビジネス・サービスは、サービス・プロデューサに接続するインタフェースです。ビジネス・サービス・インタフェースは、Web Services Description Language (WSDL)またはWeb Application Definition Language (WADL)、およびそれが使用するトランスポートのタイプを考慮して定義されます。

1.3 Service Busコンポーネント

Service Busでは、外部サービス(エンタープライズ・サービスやデータベースなど)とサービス・クライアント(プレゼンテーション・アプリケーションやその他のビジネス・サービスなど)との間でメッセージをルーティングします。Service Busプロジェクトで作成するサービス・コンポーネントとフロー・コンポーネントは、Service Busのローカル・リソースおよびシステム・リソースに依存して、ユーザー名やパスワード、キーストア資格証明、サーバー接続および変換などのその他の情報を定義します。

Service Busのリソースとは、再利用可能なエンティティ定義であり、通常はそれらのエンティティのメタデータが含まれています。リソースは複数のサービスで使用可能で、企業や部署全体で使用できるように標準化された定義または記述を持ちます。

1.3.1 サービス・コンポーネント

プロキシ・サービスとビジネス・サービスでは、Service Busシステムでエンドポイントを定義します。たとえば、バインディング・レイヤーやトランスポート・レイヤーがあり、これらは、Service Busがプロデューサやコンシューマなどの外部サービスと通信する場合のポイントになります。

1.3.1.1 プロキシ・サービス

プロキシ・サービスとは、Service Busでローカルにホストされる汎用の仲介WebサービスのService Bus定義です。プロキシ・サービスは、インタフェースを通じて外部サービスと通信しますが、このインタフェースはサービス・プロバイダやサービス・コンシューマのビジネス・サービスと同一である場合も、同一でない場合もあります。パイプラインを介して、構成済の独立したインタフェースを使用して、メッセージをプロキシ・サービスから複数のビジネス・サービスにルーティングできます。

プロキシ・サービスの構成には、そのインタフェース(サービス・タイプ)、クライアント・サービスと接続するためにインタフェースが使用するトランスポートのタイプと構成、セキュリティ要件、およびサービス・レベル合意(SLA)のアラート・ルールなどが含まれます。プロキシ・サービスが複数のビジネス・サービスとのインタフェースを行う場合、その関連パイプラインは、メッセージが適切なビジネス・サービスにルーティングされ、メッセージ・データがビジネス・サービスのインタフェースで必要なフォーマットにマップされるように構成されます。

詳細は、「プロキシ・サービスの作成と構成」を参照してください。

1.3.1.2 ビジネス・サービス

ビジネス・サービスとは、ビジネス・プロセスにおいてメッセージを交換するエンタープライズ・サービスのService Busによる定義です。ビジネス・サービスの構成には、そのインタフェース(サービス・タイプ)、サービス・プロデューサと接続するためにインタフェースが使用するトランスポートのタイプと構成、セキュリティ要件、メッセージ処理、パフォーマンス・チューニング、およびSLAのアラート・ルールなどが含まれます。ビジネス・サービスでは、エンドポイントURIも指定し、ロード・バランシングと高可用性のための複数のエンドポイントを指定できます。ビジネス・サービス定義は、プロキシ・サービスの定義と似ていますが、メッセージ処理、エンドポイントのスロットルおよび結果キャッシュの追加オプションがあるため、パフォーマンスの改善に役立ちます。

ビジネス・サービスへの接続時に認証を行うサービス・アカウントを作成できます。これは要求されるユーザー名とパスワードのペアの別名リソースとして機能します。また、Oracle WebLogic Serverを使用して、資格証明レベルの検証を要求するビジネス・サービスのセキュリティ資格証明を直接管理することもできます。

詳細は、「ビジネス・サービスの作成と構成」を参照してください。

1.3.2 メッセージ・フロー

メッセージ・フローでは、サービス間でのメッセージのルーティング、検証および変換方法を定義します。メッセージ・フローは、通常パイプラインで定義されますが、並列処理の場合は分割-結合で定義することもできます。

1.3.2.1 パイプライン

パイプラインでは、メッセージのルーティングと変換ロジックを定義し、さらにメッセージ処理のオプションも定義します。このロジックには、変換、パブリッシュ、ロギング、レポート作成、アラートおよび例外管理などのアクティビティが含まれます。各アクティビティは個別のアクションとしてメッセージ・フロー内に構成されます。JDeveloperとOracle Service Busコンソールのどちらにも、パイプラインのモデル化に役立つグラフィカル・モデリング・ツールが用意されています。

パイプラインの構築には、次の主要要素が使用されます。

- 開始ノード。

- パイプライン・ペア。一方はリクエストで使用され、他方はレスポンスで使用されます。ペアの各パイプラインは、リクエスト処理またはレスポンス処理で実行するアクションを指定する一連のステージで構成されます。

- ブランチ・ノード。メッセージまたはメッセージ・コンテキストの指定部分の値に基づいて分岐するか、呼び出された操作に基づいて分岐するために使用されます。

- ルート・ノード。メッセージの宛先の定義に使用されます。デフォルト・ルート・ノードは、リクエストそのものをレスポンスとして返すエコー・ノードです。

- エラー・ハンドラ。ノードまたはステージで発生する可能性のあるエラーを処理するために、そのノードまたはステージにアタッチできます。

少なくとも、開始ノードとルート・ノードが必要です。エラー・ハンドラは必須ではありませんが、使用することをお薦めします。インスタンスが失敗してエラー・ハンドラが定義されていない場合、そのエラーは回復できません。パイプライン要素を任意で組み合せて、開始ノードをルート(root)位置に必ず(1つのみ)配置し、ルート(route)・ノードを持つツリー構造を形成します。ブランチの最後のノード(リーフ・ノード)は、ルート・ノードまたはエコー・ノードになります。

パイプラインはメッセージを複数のビジネス・サービスにルーティングできるため、パイプラインは通信先のビジネス・サービスとは独立したインタフェースで構成できます。汎用のテンプレートを使用することにより、コンテンツ・ベースのルーティング・ロジックに基づいてメッセージを動的に適切なビジネス・サービスにルーティングするよう、パイプラインを構成できます。パイプラインは、メッセージ・データをエンドポイントのビジネス・サービスによって必要とされる適切なプロトコル形式にマップすることもでき、動的な実行時のプロトコルの切替えを実現しています。

詳細は、「Oracle Service Busパイプラインの操作」を参照してください。

1.3.2.1.1 パイプラインを介したデータの流れ

パイプラインでは、リクエスト・メッセージは開始ノードから始まり、リクエスト・パイプラインのアクションを実行しながらリーフ・ノードまでの経路を辿ります。リーフがルート・ノードの場合、レスポンスが生成されます。リーフがエコー・ノードの場合、要求そのものが応答として扱われます。レスポンスでは、ブランチ・ノードのアクションをスキップしながらツリーの経路を逆に辿ります。ただし、レスポンス・パイプラインのアクションは実行されます。インタフェースまたは操作がリクエスト/レスポンスであれば、ツリーの一番上からレスポンスが送信されます。それ以外の場合、レスポンスは破棄されます。

コンテキスト変数に影響する一連の変換は、選択したエンドポイントへのメッセージの送信前、またはレスポンスの受信後に定義できます。XQueryまたはXSLT変換のかわりにWebサービス・コールアウトを使用して、コンテキスト変数を設定できます。

1.3.2.1.2 メッセージ・コンテキスト

パイプラインのコンテキストは、リクエスト・フローとレスポンス・フローとで共有される一連のXML変数です。新しい変数は動的にコンテキストに追加したり、コンテキストから削除でき、これらの変数は複数のパイプライン間で共有することも、1つのパイプライン内でローカルに使用することもできます。あらかじめ定義されたコンテキスト変数には、メッセージに関する情報、トランスポート・ヘッダー、セキュリティ・プリンシパル、現在のパイプラインのメタデータ、およびパイプラインから呼び出されるプライマリ・ルーティング・サービスとパブリッシュ・サービスのメタデータが含まれます。

コンテキストは読み取られて、XQuery式またはXSLT式による変更や、変換およびインプレース更新アクションによる更新が行われることがあります。コンテキストの中核は、$header、$bodyおよび$attachments変数で構成されます。これらのラッパー変数には、Simple Object Access Protocol (SOAP)ヘッダー要素、SOAP本体要素、およびMultipurpose Internet Mail Extensions (MIME)添付がそれぞれ含まれます。コンテキストによって、すべてのメッセージがSOAPメッセージであり、非SOAPメッセージがこのパラダイムにマップされるように見えます。

1.3.2.2 分割-結合

分割-結合メッセージ・フローでは、メッセージ・ペイロードを分割し、メッセージ内の複数の操作を同時に処理してすべての結果を組み合せる(結合する)ことにより、サービスのパフォーマンスが向上します。標準のパイプラインでは、次々に操作が処理されます。

分割-結合でのメッセージ・フローの構築には、次の主要な要素が使用されます。

- 開始ノード。WSDL操作からイントロスペクトされるリクエスト変数およびレスポンス変数が含まれています。

- 受信ノード。着信リクエスト・メッセージを受信します。

- 返信ノード。レスポンス・メッセージを送信します。

- スコープ。囲まれた要素の動作に影響を与えるコンテキストを作成するコンテナです。

- パラレル・ノード。固定数の処理ブランチのプレースホルダであり、各ブランチには、それぞれのスコープがあります。

利用可能な要素を任意で組み合せて、開始ノードをルート(root)位置に必ず(1つのみ)配置するツリー構造を形成します。最後のノードは常に返信になります。

詳細は、「分割-結合によるサービスのパフォーマンスの向上」を参照してください。

1.3.3 トランスポート、アダプタおよびバインディング

Service Busでは、各種トランスポートを介して外部システムへの接続が提供されます。それぞれのトランスポートは、外部システムのタイプに固有です。Service Busでは、最適化されたデータベース問合せをサポートし、.NET、IBM MQ Series、IBM WebSphere、Apache AxisおよびiWayアダプタなどのWebサービス統合テクノロジと相互運用性があります。JCAトランスポートでは、Oracle JCAテクノロジやアプリケーション・アダプタを使用して外部システムに接続できるため、サポート対象テクノロジのリストが拡張されます。さらに、Service BusではRESTバインディングをサポートしているため、HTTPトランスポートを使用してRESTfulサービスに接続できます。

トランスポートの処理および接続情報は、プロキシまたはビジネス・サービス内で直接構成します。Oracleアダプタは、各アダプタに固有の構成ウィザードを使用して構成します。

詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください

1.3.3.1 サポート対象のトランスポート・プロトコル

Service Busでは、次のサービス・トランスポート・プロトコルがサポートされます。

- DSP (Oracle Data Service Integrator)

- EJB/RMI

- 電子メール(POP/SMTP/IMAP)

- ファイル

- (S)FTP

- HTTP(S)

- JCA

- JEJB

- JMS (JMSを使用したMQおよびJMS/XAを含む)

- ローカル(ESB間通信用にOracleが独自開発)

- MQ (WebSphere MQ)

- SB (RMIサポート)

- SOA-DIRECT (Oracle SOA Suite)およびBPEL

- Tuxedo (Oracle Tuxedo)

- WS (Web Services Reliable Messaging)

Service BusはCustom Transport SDKも備えているため、新しいトランスポートを作成して、前述以外のシステムとの接続が可能になります。

1.3.3.2 サービス・タイプ

Service Busは、従来のWebサービス(WSDLファイルでXMLまたはSOAPバインディングを使用)から非XML(汎用)サービスまで、様々なサービス・タイプに対応しています。ビジネス・サービスまたはプロキシ・サービスを作成する場合、サービス・タイプを選択して構成します。プロキシ・サービスやビジネス・サービスに使用できるサービス・タイプは、使用するトランスポートによって異なります。Service Busでは、HTTPとJMSの非同期トランスポート・プロトコルのリクエストとレスポンスおよび一方向のパラダイムがサポートされます。基底のトランスポートが順序付きメッセージ配信に対応している場合、Service Busでも同様の拡張で対応できます。

すべてのサービス・タイプをすべてのトランスポート・プロトコルで使用できるわけではありません。次の表に、サービス・タイプと、そのタイプでサポートされるトランスポート・プロトコルを示します。

サービス・タイプ

トランスポート・プロトコル

WSDLベースのサービス

BPEL-10g、DSP、HTTP(S)、JCA、JMS、ローカル、SB、SOA-DIRECT、WS

JMSリクエストとJMSレスポンスは、WS-Securityが有効になっているとサポートされません。

任意のSOAPサービス(非WSDL)

HTTP(S)、DSP、JMS、ローカル、SB

JMSリクエストとJMSレスポンスは、WS-Securityが有効になっているとサポートされません。

任意のXMLサービス(非WSDL)

DSP、電子メール、ファイル、FTP、HTTP(S)、JMS、ローカル、MQ、SB、SFTP、Tuxedo

HTTP GETは、WSDLがないXMLだけでサポートされます。

メッセージング・サービス

電子メール、ファイル、FTP、HTTP(S)、JMS、ローカル、MQ、SFTP、Tuxedo

電子メール、ファイル、FTPまたはSFTPトランスポートを使用するビジネス・サービスでは、一方向のメッセージング・サービスのみをサポートし、レスポンス・メッセージのタイプはnoneである必要があります。

ネイティブRESTサービス

HTTP(S)、ローカル

BPEL-10g、DSP、EJBおよびSOA-DIRECTトランスポートは、ビジネス・サービスでのみサポートされます。

1.3.4 変換リソース

メッセージ・フロー・アクションにインラインXQuery式を直接作成する以外に、ソース・サービスと宛先サービス間の複雑なマッピングを定義するトランスフォーメーション・マップを参照できます。ソースと宛先のサービスでタイプの異なるメッセージのデータ型が存在する場合、データ・マッピングによってサービスの互換性が確保されます。Service Busは、XQueryとeXtensible Stylesheet Language Transformation (XSLT)標準、およびXPath式を使用したデータ・マッピングに対応しています。また、相互参照表とドメイン値マップを使用して、サービス間のフィールド値をマップすることもできます。

メッセージは、次の方法で変換できます。

- メッセージ構造の再フォーマットにXQueryまたはXSLTを使用します。

- 特定のデータ要素を追加、削除または置換することで、メッセージのコンテンツを操作します。

- システム間のエンティティのマップに相互参照表またはドメイン値マップ表を使用します。

1.3.4.1 XQueryマッピング

JDeveloperのXQueryマッパーはXML、非XMLおよびJavaデータ型の間のデータを変換するマッピングを定義できるグラフィカル・ツールであるため、異種アプリケーションの速やかな統合を実現します。たとえば、あるスキーマに対して有効なXMLを異なるスキーマに対して有効なXMLに変換できます。データは、XMLスキーマ、Web Service Definition Language (WSDL)ファイルおよびMessage Format Language (MFL)ファイルに基づいたデータを使用できます。XQueryマッピングをJDeveloperで作成して、Oracle Service Busコンソールで、マッパーによって生成される.xqyファイルをXQueryリソースにアップロードできます。XQueryマッピングはService BusのXQueryリソースに格納されます。これは、メッセージ・フロー・アクションで式エディタを使用して作成する式から参照できます。

XQueryマッパーの出力はXQuery言語で記述された問合せです。XQuery言語はWorld Wide Web Consortium (W3C)により定義されています。W3CおよびXQuery言語の詳細は、http://www.w3.org/XML/Query/を参照してください。

詳細は、「XQueryでのデータの変換」およびOracle SOA SuiteでのSOAアプリケーションの開発のXQueryマッパーによる変換の作成に関する項を参照してください。

1.3.4.2 XSLTマッピング

eXtensible Stylesheet Language Transformation (XSLT)マップでは、XML間のマッピングを記述します。JDeveloperのXSLTマッパーは、スキーマ・ルート要素、Web Services Description Language (WSDL)メッセージ部またはWSDLメッセージ間のマッピングを定義できるグラフィカル・ツールです。スキーマ・ルート要素は、XSDスキーマ・ファイルまたはWSDLファイルをソースにできます。直接マップできるのは、単一のメッセージ・パートを含んでいるWSDLメッセージのみです。

JDeveloperのXSLTマッパーでは、メッセージ本文全体に適用される変換を定義して、1つのXMLスキーマから別のXMLスキーマにメッセージを変換できるため、異なるスキーマを使用するアプリケーション間でのデータのやり取りが可能です。XSLTマッピングをJDeveloperで作成して、Oracle Service Busコンソールで、マッパーによって生成される.xslファイルをXSLTリソースにアップロードできます。XSLTマッピングはService BusのXSLTリソースに格納されます。これは、メッセージ・フロー・アクションで式エディタを使用して作成する式から参照できます。

詳細は、「XSLTでのデータの変換」、およびOracle SOA SuiteでのSOAアプリケーションの開発のXSLTマッパーによる変換の作成に関する項を参照してください。

1.3.4.3 相互参照

相互参照表は、複数のアプリケーションにわたる同等のオブジェクトを表す識別子をマップし、異なる外部アプリケーションで作成された同様のオブジェクトを関連付けます。これらは、Service Busを介してデータを共有する各種アプリケーション間での実行時相関の管理に使用されます。たとえば、相互参照を使用して、複数の顧客管理システムで作成されたレコードの顧客IDをマップできます。相互参照の値は実行時に更新できるため、システム間で値を動的に統合できます。実行時に更新された相互参照データは、データベースに保持されます。相互参照は、複数のOracle SOA Suiteコンポーネント間で使用できます。Service Busでは、JDeveloperとOracle Service Busコンソールの両方で相互参照表を作成できます。

Service Busには、相互参照の値をルックアップおよび変更するためのXPath関数のセットがあります。これらの関数は、メッセージ・フロー・アクションで式エディタを使用して作成する式で使用する場合に利用できます。詳細は、「相互参照でのデータのマッピング」を参照してください。

1.3.4.4 ドメイン値マップ

ドメイン値マップによって、同じエンティティを記述する様々なドメインで使用される用語が関連付けられるため、複数のボキャブラリまたはシステム間での用語のマッピングが可能になります。たとえば、各ドメインで、国コード、市区町村コードまたは通貨コードなどに異なる専門用語を使用できます。これらの値をマップに入力して実行時に値を検索すると、あるドメインから別のドメインにデータを渡すときにそのデータを変換できます。ドメイン値マップは相互参照と似ていますが、動的にではなく静的に定義されます。ドメイン値マップは、デザインタイムに作成して移入し、ランタイムにデプロイします。ドメイン値マップ・データは相互参照のように実行時アクティビティによって変更されることはなく、ドメイン値マップはルックアップのためのみに使用されます。

ドメイン値マップは、複数のOracle SOA Suiteコンポーネント間で使用できます。Service Busでは、JDeveloperとOracle Service Busコンソールの両方でドメイン値マップを作成できます。Service Busには、ドメイン値マップの値をルックアップするためのXPath関数のセットがあります。これらの関数は、メッセージ・フロー・アクションで式エディタを使用して作成する式で使用する場合に利用できます。詳細は、「ドメイン値マップでのデータのマッピング」を参照してください。

1.3.5 トランスポートおよびアダプタ関連リソース

一部のトランスポートは、JavaScriptおよびJARファイルまたはMQ接続などの特定タイプのファイルに依存します。JCAトランスポートには、それが参照するJCAファイルおよび任意のファイル(WSDLファイルなど)が必要です。この項では、特定のトランスポートに固有のリソースについて説明します。

1.3.5.1 JCAバインド

Service BusのJCAバインド・リソースを使用すると、Oracle SOA Suite JCAアダプタを介して外部サービスと相互作用するビジネス・サービスとプロキシ・サービスを作成できます。JCAバインドは、サービスWSDLドキュメントと、Oracle JDeveloperで作成された対応するJCAファイルで構成されます。JDeveloperでは、Service Bus概要エディタを使用してService Busプロジェクトに直接JCAアダプタを追加できます。このためには、アダプタ・タイプを「コンポーネント」ウィンドウからエディタのキャンバスにドラッグ・アンド・ドロップします。プロキシ・サービスまたはビジネス・サービスは、JCAアダプタ構成から自動的に生成され、JCAトランスポートに基づきます。Oracle Service Busコンソールで、該当のJCAアダプタに基づきビジネス・サービスやプロキシ・サービスを作成するには、JCAファイルをJCAバインド・リソースにアップロードする必要があります。インポート機能を使用して、JCAファイルとその関連WSDLファイルをインポートすることもできます。

詳細は、「JCAバインド・リソースの操作」を参照してください。

1.3.5.2 JARファイル(アーカイブ)

JAR (Java Archive)ファイルとは、Javaクラスを含むzipファイルです。コンパイルされたJavaクラスと、プログラムを構成する関連メタデータの保存に使用します。JARファイルはJavaコード要素用のコール可能なプログラム・ライブラリのように機能します(それぞれの要素に対して個別にバインディングを要求するのではなく、単一のコンパイル・リンクが複数要素へのアクセスを提供します)。

JDeveloperでは、ファイル・システムからJARファイルをプロジェクトやコンポーネントに直接追加できますが、Oracle Service Busコンソールでは、プロジェクトに追加する各JARファイルをアーカイブ・リソースにアップロードする必要があります。Service Busでは、JARファイルは、次のコンポーネントで使用されます。

- Java終了メカニズムを提供する(パイプライン内の)Javaコールアウト・アクション

- EJBベースのビジネス・サービス

- JEJBベースのビジネス・サービスおよびプロキシ・サービス

- Tuxedoベースのプロキシ・サービスとビジネス・サービス

詳細は、JARファイルの操作を参照してください。

1.3.5.3 JavaScriptファイル

JavaScriptファイルは、ハンドシェイクを扱うためのメカニズムとしてJCAソケット・アダプタで使用されます。XSLTおよびカスタムJavaコードも、サポート対象のハンドシェイク・メカニズムです。JDeveloperでは、JavaScriptファイルを作成してから、JCAソケット・アダプタの構成時にそのファイルを選択できます。また、アダプタの構成時にJavaScriptを作成することもできます。Oracle Service Busコンソールでは、既存のJavaScriptファイルをJavaScriptリソースにアップロードするか、JavaScriptのテキストをコンソールのテキスト・エディタで作成できます。あるいは、コンソールのインポート機能を使用して、ソケット・アダプタのJCAファイルとその依存関係(WSDLファイルやJavaScriptファイルなど)をインポートできます。

Service Busでは、インバウンド・ソケット・アダプタとアウトバウンド・ソケット・アダプタの両方に対して、および一方向とリクエスト/レスポンスのメッセージングに対してJavaScriptハンドシェイクをサポートしています。リクエスト/レスポンス・ハンドシェイクでは、リクエストとレスポンスに対して個別のJavaScriptファイルが必要になります。

詳細は、「JavaScriptリソースの操作」を参照してください。

1.3.5.4 MQ接続

MQ接続リソースは、MQキュー・マネージャに接続するために必要な接続パラメータを提供します。これらは、MQトランスポートを使用するように構成されるプロキシ・サービスおよびビジネス・サービスで使用され、複数のサービス間で共有および再利用できます。MQプロキシ・サービスおよびビジネス・サービスは、MQキューにアクセスする前に、MQキュー・マネージャに接続する必要があります。各MQ接続リソースでは接続プールを使用し、同じMQ接続リソースを使用してキュー・マネージャに接続するすべてのビジネス・サービスまたはプロキシ・サービスでも、同じ接続プールを使用します。つまり、複数のビジネス・サービスまたはプロキシ・サービスで、同じキュー・マネージャを使用して、接続プールを共有できます。

Oracle Service BusコンソールでMQ接続を作成するには、WebSphere MQクライアント・ライブラリをService Busドメインにインストールする必要があります。これについては、「MQ接続の作成方法」で説明します。

1.3.6 スキーマおよびドキュメント・リソース

Service Busサービスは、各種ドキュメント・タイプに依存して、メッセージ構造やWebインタフェースなどの情報を定義します。これらのドキュメントには、データを記述するXMLスキーマ、MFLファイルおよびXMLファイルや、インタフェースを記述するWSDLドキュメントおよびWADLドキュメントなどがあります。

Service Busには、設計時に使用できるタイプ・システムが組み込まれています。条件、インプレース更新アクション、または変換のそれぞれについてXQuery式を作成するとき、エディタで変数の型を任意に宣言できるため、XQueryの作成が容易になります。使用できる型は以下のとおりです。

- XMLスキーマ型または要素

- WSDL型または要素

- MFLタイプ

1.3.6.1 XMLスキーマ

XMLスキーマとは、XMLドキュメントの基本データや構造化データの有効なコンテンツを定義するドキュメントです。XMLスキーマでは、ドキュメントの構造、ドキュメントに含まれる各要素や属性のデータ型、およびXMLビジネス・データが従う必要があるルールを指定します。XMLスキーマには、他のXMLスキーマをインポートまたは含めることができます。スキーマは、Service Busで変換されるメッセージにXML情報を追加する場合に使用され、XQuery式、WSDLファイルなどに必要です。

詳細は、「XMLスキーマの使用」を参照してください。

1.3.6.2 XMLドキュメント

XMLドキュメントのリソースは、プロキシ・サービスやビジネス・サービスの構成時に参照できるXMLファイルを格納します。たとえば、JCA準拠のシステムと通信するJCAのプロキシ・サービスまたはビジネス・サービスに必要なTopLinkマッピング・ファイルに対するXMLドキュメントを使用するとします。

XMLドキュメントは、JDeveloperの標準機能です。Oracle Service BusコンソールでXMLドキュメントを作成するには、インポート機能を使用する方法が最も簡単です。たとえば、JCAリソース(JCAファイル、および関連付けられているWSDLファイルとマッピング・ファイル)をインポートする場合、Service Busによって、マッピング・ファイルからXMLドキュメント・リソースが自動的に生成され、リソース・ファイル間の依存関係が保持されます。また、XMLドキュメント・リソースを作成し、XMLファイルのコンテンツをリソースにアップロードすることもできます。

詳細は、「XMLドキュメントの操作」を参照してください。

1.3.6.3 WSDLドキュメント

WSDL (Web Service Definition Language)インタフェースは、SOAPサービスまたはXMLサービスのサービス・インタフェースを定義します。Webサービスの場合、WSDLドキュメントには、Webサービスのインタフェースとその場所、およびその呼出し方法が記述されます。Service Busでは、次の2つのWSDLエンティティの観点で、プロキシ・サービスおよびビジネス・サービスが定義されます。

- インタフェース内の操作、および操作の署名のメッセージ部のタイプを定義する抽象WSDLインタフェース。

- メッセージ部のメッセージへのバインディング(パッケージング)、およびメッセージのトランスポートへのバインディングを定義するバインディングWSDLインタフェース。

さらに、WSDLファイルでは、サービスの具象インタフェース(たとえば、トランスポートURL)を記述することもできます。

プロキシ・サービスやビジネス・サービスの定義は、既存のWSDLファイルに基づき作成できます。これにより、サービスの部分が自動的に構成されます。サービスの定義の基になるWSDLファイルは、Service Busのリソースとして格納されます。JDeveloperでは、組込みのWSDLエディタを使用してWSDLファイルを作成できます。その後、これらのWSDLファイルと、ファイルで使用されるスキーマをOracle Service Busコンソールにインポートできます。コンソールを使用すると、WSDLファイルでの参照も解決できるため、すべてのスキーマとWSDLファイルが正しくリンクされます。Service Busではメッセージング・サービスに対して、独自のインタフェース表現が使用されます。

詳細は、「WSDLドキュメントの操作」を参照してください。

1.3.6.4 WADLドキュメント

Web Application Definition Language (WADL)ドキュメントは、前述のWSDLドキュメントと似ていますが、RESTプロキシ・サービスまたはビジネス・サービスのインタフェースを記述する場合に特に使用されます。RESTバインディングに基づいてプロキシ・サービスまたはビジネス・サービスをJDeveloperで作成する場合、バインディングに指定したWSDLドキュメントから必要なWADLドキュメントが自動で生成されます。WADLファイルには、1つのWSDLファイルおよび1つ以上のXMLスキーマに対する依存関係を含めることができます。

Oracle Service Busコンソールを使用する場合、WADLドキュメントを作成するには、ドキュメントをインポートするかWADLリソースを作成します。詳細は、「WADLドキュメントの作成」を参照してください。

1.3.6.5 MFLリソース

Service Busでは、Message Format Language (MFL)を使用して、型付きの非XMLデータの構造を記述します。MFLは、フォーマットされたバイナリ・データをXMLデータに変換するルールを定義する場合に使用されるOracle独自の言語です。MFLドキュメントは、非XMLデータ・レコードのインスタンスをXMLドキュメントのインスタンス(またはその逆)に変換するために実行時に使用されます。

JDeveloperでFormat Builderツールを使用してMFLドキュメントを作成します。Format Builderでは、非XMLデータのレイアウトと階層を、XMLと相互に変換できるように記述できます。Format Builderを使用して、データの型やサイズ、フィールドの名前、デリミタなどのメッセージの各フィールドを定義します。また、フィールドの繰返しの有無や、フィールドがオプションと必須のどちらであるかも指定できます。

詳細は、「Message Format Languageによるデータ構造の定義」を参照してください。

1.3.7 セキュリティ・リソース

セキュリティ情報は、ユーザー名やパスワードの取得方法を定義するサービス・アカウント、または暗号化資格証明を定義するサービス・キー・プロバイダを使用して、プロキシ・サービスやビジネス・サービスに渡すことができます。

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

サービス・キー・プロバイダ・リソースには、プロキシ・サービスがインバウンドSOAPメッセージの復号化やアウトバウンド認証およびデジタル署名に使用する公開鍵インフラストラクチャ(PKI)資格証明が含まれます。PKI資格証明とは、デジタル署名や暗号化(Webサービス・セキュリティ)、およびアウトバウンドSSL認証に使用できる証明書とペアになった秘密鍵です。この証明書には、秘密鍵に対応する公開鍵が含まれています。

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

- SSLクライアント認証

- デジタル署名

- 暗号化

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

詳細は、「サービス・キー・プロバイダの操作」を参照してください。

1.3.7.2 サービス・アカウント

サービス・アカウント・リソースでは、サービスやサーバーに接続するときに、Service Busが認証に使用するユーザー名とパスワードが提供されます。サービス・アカウントは、プロキシ・サービスとビジネス・サービスがアウトバウンド認証を行うとき、またはプロキシ・サービスとビジネス・サービスがFTPサーバーやJMSサーバーなどのローカルまたはリモート・リソースを認証するときに使用します。サービス・アカウントは、特定のユーザー名とパスワードのペア、および着信リクエストから受信するユーザー名とパスワードを使用するように構成したり、クライアントで提供されるユーザー名とパスワードを、指定したユーザー名とパスワードにマップするように構成したりすることができます。1つのサービス・アカウントを複数のビジネス・サービスおよびプロキシ・サービスに使用できます。

詳細は、「サービス・アカウントの操作」を参照してください。

1.3.7.3 WS-Policyリソース

以前のバージョンでは、WS-Policyリソースは、カスタムWebサービス・ポリシーを格納する場合に使用されていたため、複数のWSDLドキュメントで参照できていました。12c以降では、Oracle Web Services Manager (OWSM)ポリシーによりWLS9ポリシーが置き換えられるため、WSDLベースのWLS9ポリシーで新しいサービスを作成するオプションがなくなっています。WS-Policyリソースは引き続きインポートされたプロジェクトで表示できますが、関連付けられたWebサービスは、OWSMポリシーを使用するように更新する必要があります。ただし、引き続き、WS-Policyリソースを使用する以前のバージョンからプロジェクトをインポートしてアクティブ化できます。

1.3.8 アラート宛先

アラート宛先リソースは、Service Busからのアラート通知を受信できる受信者のリストを定義します。たとえば、サービス・レベル合意(SLA)またはパイプライン・アラートを生成する場合、特定の電子メール・アドレスやJMSキューに通知が送られるように指定できるため、関係者のみが通知を受け取ることができます。アラート宛先には、宛先タイプ(Service Busレポート・データ・ストリーム、SNMPトラップ、アラート・ログ、電子メール、JMSキューまたはJMSトピック)を1つ以上を含めることができます。電子メールおよびJMS宛先の場合は、宛先リソースはそれぞれ電子メール・アドレスまたはJMS URIのリストを含む場合があります。

詳細は、「アラート宛先の操作」を参照してください。

1.3.9 グループ・リソースのスロットル

スロットルは、トラフィックの多いビジネス・サービスでのメッセージの過負荷を防ぐことによって、パフォーマンスおよび安定性の向上に役立ちます。ビジネス・サービスへのメッセージのフロー制御とバックログの回避を行うために、Service Busアプリケーションでビジネス・サービスまたはビジネス・サービスのグループに対してメッセージのスロットルを有効にして構成できます。メッセージがスロットルされると、ビジネス・サービスは、指定した数のメッセージのみを同時に処理できます。その容量に達すると、メッセージは、ビジネス・サービスがそれ以上のメッセージの処理の準備ができるまでメモリー内キューに格納されます。

詳細は、『Oracle Service Busの管理』のメッセージのスロットルに対するビジネス・サービスの構成に関する項を参照してください。

1.3.10 システム・リソース

システム・リソースは、Service Busインスタンス内のすべてのプロジェクトで共有できる、グローバルに使用可能なリソースです。これらは、サーバー接続と認証の情報を定義します。たとえば、次のリソースがあります。

- JNDIプロバイダ

- SMTPサーバー

- プロキシ・サーバー

- UDDIレジストリ

Oracle Service Busコンソールでは、システム・リソースは、個別のプロジェクト名の付いたシステムに格納されます。JDeveloperでは、システム・リソースは、「アプリケーション・リソース」パネルの「Service Busシステム・リソース」に格納されます。

1.3.10.1 JNDIプロバイダ

JNDIプロバイダ・リソースは、JNDI名のオブジェクトへのアクセスに必要な接続および認証情報を定義します。これらは、Service Busで使用されるJNDIプロバイダのURL (またはクラスタ化されたデプロイメントの場合はURLのリスト)を記述します。たとえば、EJBの起動に使用されるビジネス・サービスで、エンドポイントURIにJNDIプロバイダ・リソースの名前を含めます。ビジネス・サービスが起動されると、Service Busでは参照されたJNDIプロバイダ・リソースの詳細を使用して、JNDIプロバイダへの初期接続が行われます。

JNDIプロバイダが保護されている場合、JNDIプロバイダ・リソースでは、アクセスに必要なユーザー名とパスワードも定義されます。JNDIプロバイダは高度な柔軟性を備えています。JNDI接続が変更された場合、JNDIプロバイダ・リソースのみを修正すればよく、JNDIプロバイダを参照するそれ以外の要素は、更新された構成を自動的に使用します。

詳細は、「JNDIプロバイダ・リソースの操作」を参照してください。

1.3.10.2 SMTPサーバー

SMTPサーバー・リソースは、電子メール宛先、ポート番号および必要な場合に認証資格証明に対応するSMTPサーバーのアドレスを定義します。これらは、Service Busで使用されるSMTPサーバーのURLを記述します。SMTPサーバーが保護されている場合、SMTPサーバー・リソースの記述には、アクセスに必要なユーザー名とパスワードも含まれます。SMTPサーバー・リソースは、アラート宛先リソースおよび電子メール・トランスポートベースのビジネス・サービスの構成を行う際に参照されます。

詳細は、「SMTPサーバー・リソースの操作」を参照してください。

1.3.10.3 プロキシ・サーバー

プロキシ・サーバー・リソースは、JNDI名のオブジェクトへのアクセスに必要な接続および認証情報を定義します。これらは、Service Busで使用されるプロキシ・サーバーのURLを記述します。プロキシ・サーバーが保護されている場合、プロキシ・サーバー・リソースの記述には、アクセスに必要なユーザー名とパスワードも含まれます。プロキシ・サーバーを使用すると、クライアント・アプリケーションからリクエストをプロキシできます。Service Busがファイアウォールの後ろにある場合は、通常プロキシ・サーバーを使用します。メッセージをプロキシ・サーバー経由でルーティングするようにビジネス・サービスを構成する場合、プロキシ・サーバー・リソースとそのビジネス・サービスを関連付けます。これにより、Service Busが、構成されたプロキシ・サーバーを使用してビジネス・サービスへの接続を行います。

各プロキシ・サーバー・リソースに複数のプロキシ・サーバーを構成できます。この場合、Service Busでロード・バランシングが実行され、構成されたプロキシ・サーバー間でフォルト・トレランスが可能になります。

詳細は、「プロキシ・サーバー・リソースの操作」を参照してください。

1.3.10.4 UDDIレジストリ

Universal Description, Discovery and Integration (UDDI)レジストリは、Webサービスを共有するために使用されます。UDDIは、企業のビジネス、ビジネス・サービス、および公開するサービスの技術的な詳細を分類するためのフレームワークを提供します。UDDIレジストリ・リソースは、サービスの検出、パブリッシュおよび同期の目的でService BusがアクセスするUDDIレジストリに関する情報を格納します。UDDIレジストリ・リソースを構成すると、関連付けられたレジストリにService Busプロキシ・サービスをパブリッシュしたり、プロキシ・サービスで使用するビジネス・サービスをレジストリからインポートしたりできます。UDDIレジストリ・リソースでは、照会URL、パブリッシュURLおよびサブスクリプションURLと、レジストリへのアクセスに必要なユーザー名およびパスワードを定義します。

詳細は、「UDDIレジストリの操作」を参照してください。

1.4 Service Busメッセージング

この項では、Service Busでサポートされるメッセージングのタイプ、メッセージ・フォーマット、およびService Busプロジェクトのコンポーネントによって渡される(コンポーネントによってオプションで変更される)コンテキスト変数について説明します。

1.4.1 メッセージング・モデル

Service Busには複数のメッセージング・パラダイムが採用されており、次のタイプの通信をサポートします。

- 同期リクエスト/レスポンス

- 非同期パブリッシュ1対1

- 非同期パブリッシュ1対多

- 非同期リクエスト/レスポンス(同期と非同期のブリッジング)

同期と非同期のブリッジングでは、同期クライアントが非同期プロバイダにリクエストを発行します。このパターンの場合、レスポンスをリスンするときのタイムアウト値を使用して、1つ目のJMSキューにメッセージをパブリッシュし、レスポンス用の2つ目のJMSキューを構成できます。このタイプのサービスは、サービス・コンシューマからは同期サービスに見えます。非同期リクエスト/レスポンス・メッセージを使用すると、次のような利点があります。

- 多数のブロックされているリクエスト/レスポンスの呼出しによって発生する可能性のあるスレッド管理の問題が解消され、リクエスト・スレッドによるブロッキングがなくなります。

- メッセージングの信頼性が向上します。

1.4.2 メッセージ・フォーマット

Service Busでは、次のメッセージ・フォーマットがサポートされます。

- 添付ファイルなしまたは添付ファイル付き電子メール

- Java

- ヘッダー付きJMS

- MFL (メッセージ・フォーマット言語)

- 生データ(既知のスキーマを持たない不明確な非XMLデータ)

- テキスト

- SOAPおよび添付ファイル付きSOAP (WSDLドキュメントで記述されたSOAPまたは記述されないSOAP)

- XMLおよび添付ファイル付きXML (WSDLドキュメントまたはスキーマで記述されたXMLまたは記述されないXML)

1.4.3 メッセージ・コンテキスト

プロキシ・サービスによって送受信されるすべてのメッセージは、内部で一連のプロパティによって定義されます。これらのプロパティは、メッセージ・データや、そのメッセージに関連するメタデータを保持しています。この一連のプロパティは、メッセージ・コンテキストと呼ばれ、コンテキスト変数を使用して実装されます。コンテキストは、XMLスキーマによって定義されます。コンテキスト変数には、事前定義された変数とユーザー定義の変数があります。

あらかじめ定義されたコンテキスト変数には、メッセージに関する情報、トランスポート・ヘッダー、セキュリティ・プリンシパル、現在のプロキシ・サービスのメタデータ、およびプロキシ・サービスから呼び出されるプライマリ・ルーティング・サービスとパブリッシュ・サービスのメタデータが含まれます。通常は、メッセージがService Busを介して移動すると、パイプラインでXQuery式を使用して、コンテキスト変数を操作します。変換およびインプレース更新アクションを使用してコンテキスト変数を変更することもできます。

メッセージ・フローで使用されるメッセージ・コンテキストおよびコンテキスト変数の詳細は、「メッセージ・コンテキスト」を参照してください。

1.4.4 コンテンツ・タイプ

Service Busでは、種類の異なるエンドポイントとの相互運用性をサポートするために、サービスの構成で、使用するコンテンツ・タイプ、JMSタイプおよびエンコーディングを制御できます。外部クライアントやサービスで必要になるものについては仮定を行わず、かわりにプロキシ・サービスやビジネス・サービスの構成を使用します。Service Busでは、アウトバウンド・メッセージのコンテンツ・タイプを、サービス・タイプとインタフェースから導出し、次の仕様を使用します。

- XMLまたはSOAPの場合(WSDLファイルの有無を問わない)、コンテンツ・タイプはtext/XML。

- インタフェースがMFLまたはバイナリのメッセージング・サービスの場合、コンテンツ・タイプはbinary/octet-stream。

- インタフェースがテキストのメッセージング・サービスの場合、コンテンツ・タイプはtext/plain。

- インタフェースがXMLのメッセージング・サービスの場合、コンテンツ・タイプはtext/XML。

- RESTバインディングを使用するサービスの場合、コンテンツ・タイプはapplication/xmlまたはapplication/json。

サービスを呼び出すパイプラインのアウトバウンド・コンテキスト変数($outbound)のコンテンツ・タイプ、およびパイプライン・レスポンスのインバウンド・コンテキスト変数($inbound)のコンテンツ・タイプはオーバーライドできます。さらに、サービスが定義される場合に構成できるJMSタイプ(バイトまたはテキスト)があります。すべてのアウトバウンド・メッセージについて、サービス定義でエンコーディングが明示的に構成されます。

1.5 Service Busでのワーク・マネージャの使用

Service Busでは、Oracle WebLogic Serverワーク・マネージャを使用して、パフォーマンスを最適化して、サービス・レベル合意を維持します。ワーク・マネージャでは、定義したルールに基づいて、さらには実行時パフォーマンスによって、作業の優先順位を決定してスレッドを割り当てます。ワーク・マネージャを作成して構成する場合、使用するスレッドの最大数と最小数、サーバー容量、およびスケジューリング・ガイドラインを表すリクエスト・クラスとレスポンス・クラスを定義します。デフォルトのワーク・マネージャが1つ用意されていますが、サービスの最適化に必要な分のワーク・マネージャを作成できます。Service Busでは、トランスポート構成の「ディスパッチ・ポリシー」プロパティで、プロキシ・サービスやビジネス・サービスのワーク・マネージャを指定します。

ワーク・マネージャの詳細は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。Service Busでのワーク・マネージャの詳細は、「Service Busでのワーク・マネージャの使用」を参照してください。

1.6 Service Busのセキュリティ

Service Busでは、Oracle Platform Security Services (OPSS)およびOracle Web Services Manager (OWSM)を使用して、より高度なセキュリティ・サービスを構成します。これには、認証、IDアサーション、認可、ロール・マッピング、監査、資格証明マッピングなどが含まれます。Service Busアクセス・セキュリティを構成するには、最初にOracle WebLogic Serverセキュリティを構成する必要があります。Service BusでOWSMを使用すると、組織全体で一貫性のあるWebサービスの管理と保護のためのポリシー・フレームワークが提供されます。

1.6.1 Service Busのセキュリティ機能

Service Busには、次のセキュリティ機能が用意されています。

- OWSMおよびOPSSとの統合

- Webサービス・セキュリティ(WS-Security)仕様に定義された認証、暗号化と復号化、およびデジタル署名

- HTTPおよびJMSトランスポート・プロトコルの従来のトランスポート・レベルのセキュリティをサポートするSSL

- 証明書に基づく一方向および双方向の認証

- HTTP基本認証

- ユーザー名およびパスワードを含むリソース(サービス・アカウント、サービス・キー・プロバイダ、UDDIレジストリ、SMTPプロバイダ、JNDIプロバイダなど)の暗号化とエクスポート

- ユーザー名、パスワードおよび資格証明別名バインディングを定義するサービス・アカウントとサービス・キー・プロバイダ

- トランスポート・レベルとメッセージ・レベルのインバウンド・リクエストに対するクライアント指定のカスタム認証資格証明

1.6.2 Service Busサービス・セキュリティ・モデル

Service Busサービスは、そのインタフェース内のメッセージに適用されるセキュリティ・ポリシーによって保護できます。セキュリティ・ポリシーの適用対象として、サービスを指定することも、サービスのオペレーションに関連する個々のメッセージを指定することもできます。サービスに対してセキュリティ・ポリシーを指定した場合、そのサービスのすべてのメッセージにポリシーが適用されます。

Service Busサービスは、次のタイプのセキュリティを使用して保護できます。

- インバウンド・セキュリティ

- アウトバウンド・セキュリティ

- IDの伝播のオプション

- 管理セキュリティ

- サポートされる標準とセキュリティ・プロバイダ

図1-4に、メッセージ・ライフ・サイクルの様々なポイントでのセキュリティ機能を示します。

図1-4 最適化されたプラガブル・セキュリティ・レイヤー

1.6.3 Oracle Web Services Manager

Service Busサービスは、Oracle Web Services Manager (OWSM)ポリシーをアタッチすることで保護できます。OWSMは、Oracle Enterprise Manager Fusion Middleware Controlのコンポーネントで、Oracle SOA Suite環境とアプリケーションの集中管理および制御を提供するランタイムのフレームワークです。これには、セキュリティ、信頼性のあるメッセージング、MTOMおよびアドレス・ポリシーなどのWebサービス・ポリシーを構築、施行、実行および監視できる機能があります。OWSMは、開発者が設計時に使用したり、システム管理者が本番環境で使用したりすることができます。OWSMにより、ローカル施行によるWebサービスのポリシー駆動集中管理が可能になります。OWSMには、組織全体で一貫性のあるWebサービスの管理と保護のためのポリシー・フレームワークがあります。

1.6.4 Oracle Platform Security Services

Oracle Platform Security Services (OPSS)には、Java Standard Edition (Java SE)およびJava Enterprise Edition (Java EE)アプリケーション向けの、標準ベースで移植可能な、エンタープライズ級の統合セキュリティ・フレームワークが用意されています。OPSSでは、標準ベースのAPIの形式で抽象化レイヤーが提供されているため、開発者はセキュリティやID管理の実装についての詳細を意識する必要がありません。開発者は、暗号鍵管理や、ユーザー・リポジトリおよびその他のID管理インフラストラクチャとの相互作用について詳しく理解する必要はありません。

1.6.5 WS-Policy

OWSMによって、Service BusセキュリティはWebサービス・ポリシー(WS-Policy)仕様をサポートします。これは、それぞれ1つ以上のアサーションが含まれるポリシーを使用してWebサービスのセキュリティ制約と要件を定義するための標準ベースのフレームワークです。WS-Policyアサーションにより、デジタル署名や暗号化に対するWebサービスの要件、および必要なセキュリティ・アルゴリズムや認証メカニズムが指定されます。

WS-Policyのポリシーは、直接WSDLドキュメントに含めることも、参照により含めることも可能です。WSDLドキュメントは、WS-Policyのポリシーを含むか、これを参照する他のWSDLドキュメントをインポートできます。実行時環境では、抽象的なWS-Policy文と具象的なWS-Policy文の両方を認識します。抽象WS-Policy文では、セキュリティ・トークンを指定しません。具象WS-Policy文では、認証、暗号化およびデジタル署名のためのセキュリティ・トークンを指定します。抽象ポリシーが受け取るセキュリティ・トークンのタイプは、Service Busの実行時環境で決定します。

WS-Policy仕様の詳細は、次の場所にあるWeb Services Policy Framework (WS-Policy)とWeb Services Policy Attachment (WS-PolicyAttachment)に関する記述を参照してください: http://specs.xmlsoap.org/ws/2004/09/policy/。

1.6.6 セキュリティのタイプ

次の項では、Service Busのセキュリティ・モデルで使用できるセキュリティ機能について説明します。

- インバウンド・セキュリティ

- アウトバウンド・セキュリティ

- IDの伝播

- ユーザー管理および管理セキュリティ

- トランスポート・レベルのセキュリティ

- メッセージ・レベルのセキュリティ

1.6.6.1 インバウンド・セキュリティ

インバウンド・セキュリティによって、プロキシ・サービスは認可されたクライアントから出されたリクエストのみを処理し、クライアントからデータが送信されたときに、認可されていないユーザーがそのデータを参照または変更していないことが保証されます。外向きのプロキシ・サービス(サービス・コンシューマからリクエストを受信します)の場合は、双方向SSL over HTTPSなどの厳密なセキュリティ要件を使用します。プロキシ・サービスで、デジタル署名、暗号化またはSSL認証に対して公開鍵インフラストラクチャ(PKI)テクノロジを使用する場合は、証明書とペアの秘密鍵を提供するサービス・キー・プロバイダを作成できます。

1.6.6.2 アウトバウンド・セキュリティ

アウトバウンド・セキュリティは、プロキシ・サービスとビジネス・サービス間の通信を保護します。プロキシ・サービスを構成するタスクの大半は、ビジネス・サービスが指定するトランスポート・レベルのセキュリティまたはメッセージ・レベルのセキュリティの要件に準拠しています。ビジネス・サービスでデジタル署名にSSL認証またはPKIテクノロジが必要な場合は、証明書とペアの秘密鍵を提供するサービス・キー・プロバイダが必要です。

1.6.6.3 IDの伝播

IDの伝播用にService Busで提供されるオプションでは、クライアントが提示するIDの伝播方法など、セキュリティを設計するときの判断を行うことができます。Service Busは、クライアントで提供される資格証明を認証して認可チェックを実行し、資格証明をそのまま渡して資格証明をマップするように構成できます。

1.6.6.4 ユーザー管理および管理セキュリティ

Service Busユーザー管理はWebLogic Serverセキュリティに基づきます。これは、任意のグループまたは個々のユーザーに割り当てられたロールに関連付けられているセキュリティ・ポリシーを基にしたタスク・レベルの認可をサポートします。Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用して、Service Busのユーザー、グループおよびロールを管理します。

プロキシ・サービスなどのリソースの作成といった機能にユーザーがアクセスできるようにするには、事前定義済のアクセス権限を持つ、事前定義済の1つ以上のセキュリティ・ロールにユーザーを割り当てます。Service Busの管理セキュリティ・ロールのアクセス特権は変更できませんが、それらのロールのいずれかにユーザーまたはグループを入れるための条件は変更できます。デフォルトでは、Service Busドメインで最初に作成されるユーザーはWebLogic Server管理者です。このユーザーは、Service Busのすべてのオブジェクトおよび機能にアクセスでき、ユーザー管理タスクを実行してService Bus機能へのアクセス制御を行うことができます。

詳細は、『Oracle Service Busの管理』のOracle Service Busのアクセス・セキュリティの定義に関する項を参照してください。

1.6.6.5 トランスポート・レベルのセキュリティ

Service Busでは、トランスポート・レベルの機密性、メッセージの整合性、および一方向のリクエストまたはリクエスト/レスポンスのトランザクションでのクライアント認証がHTTPS経由でサポートされます。HTTP(S)プロキシ・サービスまたはビジネス・サービスは、基本認証、クライアント証明書(双方向SSL)認証、カスタム認証が必要になるように構成するか、クライアント認証をまったく行わないように構成できます。Service Busでサポートされる、HTTP以外のトランスポート方式でのトランスポート・セキュリティは次のとおりです。

- 電子メール・トランスポートおよびFTPトランスポートでは、FTPサーバーまたは電子メール・サーバーへの接続に資格証明を使用してセキュリティが提供されます。

- ファイル・トランスポートでは、ファイルが存在するマシンへのログイン・コントロールを使用したセキュリティが提供されます。

1.6.6.6 メッセージ・レベルのセキュリティ

Service Busでは、OASIS Web Services Security (WSS) 1.0をサポートしています。WSSは、メッセージの機密性、整合性、およびSOAPメッセージでのセンダー認証を実現するためのフレームワークを定義します。Service BusでWSSを使用することにより、デジタル署名または暗号化、あるいはその両方を使用するメッセージを保護できます。WSSは、トランスポート・レベルのセキュリティとしては使用できませんが、エンド・ツー・エンドのメッセージで機密性および整合性を確保するのに適しています。WSSは、SOAPエンベロープの一部の要素のみに署名または暗号化、あるいはその両方を適用し、残りの要素には署名または暗号化を適用しないことが可能であるため、SSLよりも柔軟性に富んでいます。これは、Service Busの機能と結合されると、メッセージのコンテンツに基づいてデータのルーティングの決定およびデータの変換を行うための強力な機能になります。Service Busでは、HTTP(S)およびJMSを介したWSSがサポートされます。

WSS仕様の詳細は、次の場所にあるOASIS Web Services Security TCを参照してください: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss。

1.6.7 カスタム・セキュリティ資格証明

Service Busは、トランスポート・レベルおよびメッセージ・レベルのインバウンド・リクエストに対して、クライアント指定のカスタム認証資格証明をサポートします。カスタム認証資格証明は、トークン、またはユーザー名とパスワードのトークンの組合せになります。Service Busでは、次の認証を承認して試行します。

- HTTPヘッダー、SOAPヘッダー(SOAPベースのプロキシ・サービスの場合)、またはペイロード(非SOAPプロキシ・サービスの場合)でプロキシ・サービスに渡されるカスタム・トークン。

- SOAPヘッダー(SOAPベースのプロキシ・サービスの場合)またはペイロード(非SOAPプロキシ・サービスの場合)で渡されるユーザー名およびパスワードのトークン。

アウトバウンド・リクエストの場合、カスタム認証は、作成するカスタム・オーセンティケータJavaクラスに基づきトランスポート・レベルでサポートされます。カスタム認証メカニズムは、単独で機能するか、またはWebサービスのメッセージ・レベル・セキュリティと組み合せて機能します。カスタム・セキュリティ資格証明の詳細は、「カスタム認証の構成」を参照してください。

1.7 Service Busサービスの設計方法

Service Busサービスを作成するとき、Oracle Service Busコンソールを使用するか、JDeveloperを使用するかにより、その構築方法を選択できます。JDeveloperでは両方の方法をサポートしますが、コンソールではボトムアップの方法のみがサポートされます。

- トップダウン: この方法では、プロセスを分析し、このプロセスを支援するアクティビティを特定します。Service Bus概要エディタにより、Service Busアプリケーションおよびプロジェクトを作成し、Service Busコンポーネントを定義します。

- ボトムアップ: この方法では、既存のアプリケーションおよびアセットを分析し、サービスとして使用できるものを特定します。Service Busアプリケーションを作成する際に、必要に応じてサービスを構築します。この方法は、ITが変更に応じる必要がある場合に有効です。

1.7.1 Service Busトップダウン・ロードマップ

Service Busサービスを開発するこの方法では、Service Bus概要エディタを使用して、すべてのプライマリ・コンポーネントを一度に作成できます。たとえば、プロキシ・サービス、ビジネス・サービス、パイプライン、分割-結合およびJCAアダプタなどがあります。エディタにより、プロジェクト・コンポーネントの作成と構成が簡素化され、データ・フローの構造全体のグラフィック表示が可能です。これらのコンポーネントを作成してワイヤリングすると、それぞれの構成オプションを定義して、パイプラインや分割-結合でメッセージのルーティングや変換を定義できます。

次の表に、手順の概要と、詳細情報へのリンクを示します。

表1-1 Service Bus開発ロードマップ - トップダウン方法

手順

説明

詳細

1

サービス・アカウント、WSDLファイルまたはXQueryマップなど、必要なサポート・リソースを作成します。

各タイプのリソースのリンクについては、「Oracle Service Busの概要」に示しています。

2

プロキシ・サービス、パイプライン、ビジネス・サービスおよび分割-結合(オプション)を作成します。

Service Busコンポーネントの追加

3

コンポーネントをまとめてワイヤリングします。

Service Busコンポーネントのワイヤリング

4

プロキシ・サービスとそのトランスポートを構成します。

プロキシ・サービスの構成

JCAアダプタ、トランスポートおよびバインドの操作

5

パイプラインと分割-結合を構成します。

Oracle Service Busパイプラインの操作

分割-結合によるサービスのパフォーマンスの向上

6

ビジネス・サービスとそのトランスポートを構成します。

ビジネス・サービスの構成

JCAアダプタ、トランスポートおよびバインドの操作

7

ビジネス・サービスおよびプロキシ・サービスのセキュリティを構成します。

ビジネス・サービスとプロキシ・サービスの保護

8

サービスとリソースをテストしてデバッグします。

Oracle Service Busアプリケーションのデバッグ

テスト・コンソールの使用

9

サービスをデプロイします。

Oracle Service Busサービスのデプロイ

10

ランタイムを監視して管理します。

Oracle Service Busの実行時モニター

1.7.2 Service Busのボトムアップ・ロードマップ

Service Busサービスを開発するこの方法では、各プロジェクト・コンポーネントを個別に作成して構成します。システムを介したメッセージのフローは、プロキシ・サービス、ビジネス・サービス、パイプライン、分割-結合などのプロジェクト・コンポーネント間で作成した参照によって定義されます。この方法ではService Bus概要エディタを使用しないため、コンポーネントのグラフィカル表示では作業できません。ただし、JDeveloperで作業する場合、作成したコンポーネントは、概要ファイルに追加され、Service Bus概要エディタに表示されます。

次の表に、手順の概要と、詳細情報へのリンクを示します。

表1-2 Service Bus開発ロードマップ - ボトムアップ方法

手順

説明

詳細

1

サービス・アカウント、WSDLファイルまたはXQueryマップなど、必要なサポート・リソースを作成します。

各タイプのリソースのリンクについては、「Oracle Service Busの概要」に示しています。

2

プロキシ・サービスとパイプラインを作成します。パイプラインの作成時にプロキシ・サービスを生成できます。

プロキシ・サービスの作成

Oracle Service Busパイプラインの操作

3

プロキシ・サービスとそのトランスポートを構成します。

プロキシ・サービスの構成

JCAアダプタ、トランスポートおよびバインドの操作

4

パイプラインでメッセージ・フローを定義します。

Oracle Service Busパイプラインの操作

5

オプションで、並列処理の分割-結合を作成して構成します。

JDeveloperでの分割-結合の操作

6

ビジネス・サービスを作成して構成します。

ビジネス・サービスの作成

ビジネス・サービスの構成

7

サービスのセキュリティを構成します。

ビジネス・サービスとプロキシ・サービスの保護

8

サービスとリソースをテストしてデバッグします。

Oracle Service Busアプリケーションのデバッグ

テスト・コンソールの使用

9

サービスをデプロイします。

Oracle Service Busサービスのデプロイ

10

ランタイムを監視して管理します。

Oracle Service Busの実行時モニター

1.8 Service Busコンポーネントのネーミング・ガイドライン

Service Busプロジェクトでディレクトリまたはリソースに名前を付ける場合、許可される文字は次のとおりです。

- Javaキーワードを含むすべてのJava識別子文字。Java Language Specification (http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.8)の「Identifiers」と「Keywords」のセクションを参照してください。

- 名前の先頭または末尾以外の場所のブランク、ピリオドおよびハイフン。

/ \ * : " < > ? | などの文字は使用できません。

1.9 WebブラウザでのService Busリソースの表示

次の項で説明しているURLを使用して、このドキュメントに記載されているService Busのリソースの一部を標準のWebブラウザから表示できます。

- WSDLドキュメント

- WSポリシー

- Message Format Language (MFL)リソース

- スキーマ・リソース

- WebブラウザでのService Busリソースの表示についてのメモ

1.9.1 WSDLドキュメント

- WSDLドキュメントを表示するURL:

http://host:port/sbresource?WSDL/project_path/wsdlname

- WSDLベースのHTTPプロキシ・サービスのWSDLドキュメントを表示するURL:

http://host:port/proxy_service_endpoint_URI?WSDL

- WSDLベースのプロキシ・サービスのWSDLドキュメントを表示するURL:

http://host:port/sbresource?PROXY/project_path/proxyname

- Oracle Web Services Managerのポリシーがアタッチされているプロキシ・サービスのWSDLドキュメントを表示するURL:

http://host:port/sbresource?ORAPROXY/project_path/proxyname

- WSDLベースのビジネス・サービスのWSDLドキュメントを表示するURL:

http://host:port/sbresource?BIZ/project_path/bizname

- Oracle Web Services ManagerのポリシーがアタッチされているWSDLベースのビジネス・サービスのWSDLドキュメントを表示するURL:

http://host:port/sbresource?ORABIZ/project_path/bizname

1.9.2 WSポリシー

WSセキュリティ・ポリシーを表示するには、次のURLを使用します。

http://host:port/sbresource?POLICY/project_path/policyname

1.9.3 メッセージ・フォーマット言語(MFL)リソース

MFLファイルを表示するには、次のURLを使用します。

http://host:port/sbresource?MFL/project_path/mflname

1.9.4 スキーマ・リソース

XMLスキーマを表示するには、次のURLを使用します。

http://host:port/sbresource?SCHEMA/project_path/schemaname

1.9.5 WebブラウザでのService Busリソースの表示についてのメモ

Oracle Web Services Managerポリシーを含むWSDLドキュメントを取得して、このポリシーが、サポートされるWS-PolicyおよびWS-Security Policy標準に準拠するようにすることもできます。詳細は、「WS標準をサポートするためのWSDLファイルの通知」を参照してください。

リソース名に特殊文字を使用する場合、Service Busでリソースの公開に使用するURLは、特殊文字をエスケープするためにUTF-8でエンコードする必要があります。

1.10 アクセシビリティ・オプション

Service Busでは、開発にJDeveloperとOracle Service Busコンソールの両方を使用します。次の項では、両環境でのアクセシビリティ・オプションについて説明します。

- JDeveloperでのアクセシビリティ・オプションの設定

- スクリーン・リーダー・モードに関する注意

- Oracle Service Busコンソールでのアクセシビリティ・オプションの設定方法

1.10.1 JDeveloperでのアクセシビリティ・オプションの設定

JDeveloperには、スクリーン・リーダー、スクリーン拡大鏡、キーボード移動用の標準のショートカット・キーなどのアクセシビリティ・オプションが用意されています。さらに読みやすくするため、フォントのサイズや色、オブジェクトの色や形など、JDeveloperをカスタマイズすることもできます。JDeveloperでのアクセシビリティについて、およびこれを構成する手順は、『Oracle JDeveloperによるアプリケーションの開発』のOracle JDeveloperのアクセシビリティ情報に関する項を参照してください。

1.10.2 スクリーン・リーダー・モードに関する注意

スクリーン・リーダー・モードが有効な状態でOracle Service Busコンソールにログインする場合、プロジェクト・ナビゲータからコンテキスト・メニューを選択するには追加の手順が必要です。プロジェクト・ナビゲータでプロジェクトおよびコンポーネントのコンテキスト・メニューにアクセスするには、[Tab]キーを使用してコンポーネントに移動し、[Enter]を押してコンポーネントを選択してから、[Ctrl]+[Alt]+[M]を押してメニューを起動します。メニューのオプションを移動するには、下矢印および上矢印を使用します。

1.10.3 Oracle Service Busコンソールでのアクセシビリティ・オプションの設定方法

アクセシビリティ設定は、アプリケーションのすべてのコンポーネントを読むのに役立ちます。Oracle Service Busコンソールでのアクセシビリティ・オプションの設定は、現在のインスタンスのみに対して行うことができます。コンソールでは、ログイン・ページに「アクセシビリティ」メニューが表示され、ログインする前にアクセシビリティを構成できます。

アクセシビリティ・オプションを設定するには:

1. Oracle Service Bus Consoleを起動します。

2. ログイン・ページで、画面の右下隅にある「アクセシビリティ」をクリックします。

次に示す「アクセシビリティ設定の編集」ページが表示されます。

図1-5 「アクセシビリティ設定の編集」ページ

注意:

このページは、ログイン後に「プリファレンス」オプションでも設定を変更できることを示しています。現在、アクセシビリティ・オプションは、「アクセシビリティ設定」ページからのみ構成できます。

3. 「スクリーン・リーダーの使用」オプションを選択します。

4. 「このセッションで使用」をクリックします。

1.11 その他のリソース

この開発者ガイドに加え、Service Busを最大限活用できるようにするため、次のリソースも用意しています。

- Oracle SOA Suiteの理解では、Oracle SOA SuiteおよびOracle Service Busを紹介し、このスイートにより実行できることについて、おおまかに理解できるようにします。

- Oracle Service Busサービスの管理では、実行中のサービスをモニターし、実行時環境を更新する方法について説明しています。

- Oracle Service Busのサンプルにはその他の学習ツールが用意されており、Service Bus機能の開始に役立ちます(http://www.oracle.com/technetwork/middleware/service-bus/learnmore/index.html)。

Oracle Fusion Middlewareドキュメント・ライブラリには、すべてのService Busドキュメントのリストが提供されています。

2 Oracle Service Busコンソールのスタート・ガイド

この章では、Oracle Service Busコンソールを使用して、サービスおよびその他のService Busリソースを構成する方法についての一般的な情報を提供します。これらは、主に、実行されているWebLogic Serverインスタンスを必要とする設計時アクティビティですが、コンソールを使用して実行時タスクを実行することもできます。

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

- Oracle Service Busコンソールの概要

- スタート・ガイド

- セッションの使用

- Oracle Service Busコンソールでのプロジェクト、フォルダおよびリソースの操作

- 競合の表示と解決

- 履歴データの表示

- 変更およびアクティブ化の取消し

- 参照の表示

- Oracle Service Busコンソールの外観のカスタマイズ

2.1 Oracle Service Busコンソールの概要

Oracle Service Busコンソールは、ほとんどのService Busリソースの作成および構成、リソースのテストおよびランタイムへの変更のアクティブ化を行うことができるWebベースのコンソールです。Service Bus構成JARファイルのインポートとエクスポートを行うこともできます。このコンソールでは、Weblogic Server管理コンソールに似た変更セッション・メカニズムを利用しており、セッション内で変更を完了でき、変更内容に満足したらそれらをランタイムに対してアクティブ化できます。リソースと呼ばれるService Busコンポーネントは、プロジェクトおよびフォルダとしてグループ化されます。

2.1.1 Service Busセッション

Oracle Service Busコンソールでの作業のほとんどは、オープン・セッション内で行います。Service Busコンポーネントおよびプロジェクトへの変更を行い、競合を解決して、その変更をランタイムに伝播する準備が整ったら、セッションをアクティブ化できます。セッションでは、Service Busでサービスおよびメタデータを構成する際に、チームのコラボレーションが可能です。各チーム・メンバーは、作業中の構成をバスのコア構成にチェック・インする準備が整うまで、サンドボックス・セッションで作業します。複数のユーザーが構成を操作するため、セッションでは複数の取消しレベルと競合の可視性が提供されます。

各ページで使用可能なオプションは、セッション内で作業しているかどうかによって異なります。たとえば、セッション外のリソースは編集できず、サービスをテストできるのはセッション外で作業している場合のみです。また、セッションでは、「履歴」タブを開いたときに表示される「変更」ページに、そのセッションで行ったすべての変更がリストされます。セッション外では、ページに変更はリストされません。

2.1.2 Oracle Service Busコンソールのレイアウト

Oracle Service Busコンソールでは、プロジェクト・ナビゲータのツリー・ビューにすべてのプロジェクト、フォルダおよびリソースが表示されます。ナビゲータでコンポーネントを選択すると、エディタにその構成が表示されます。ほとんどのエディタはタブ付きページに分類され、それぞれのページで、特定タイプのプロパティを構成できます。図2-1に、プロキシ・サービス定義エディタに表示されるプロキシ・サービスの例を示します。上部ツールバーには、WebLogic Server管理コンソール、Fusion Middleware Controlおよびオンライン・ヘルプ・トピックへのリンクが表示されます。エディタのツールバーでは、変更の保存、表示されたコンポーネントに関する情報の表示、テスト・コンソールやパイプライン・エディタの起動、およびサービスの基になるWSDLファイルのエクスポートを行うことができます。

図2-1 Oracle Service Busコンソールのプロキシ・サービス構成

ツール・アイコンから任意の補助タブを選択すると、競合、変更履歴およびアクティブ化を表示できます。これらのタブを使用して、変更をアクティブ化する前に競合を解決し、アクションまたはセッションのアクティブ化も取り消します。図2-2に、展開されたツール・メニューを示し、図2-3に、「履歴」タブで「変更」サブタブが選択された状態を示します。

図2-2 展開されたツール・メニュー

図2-3 「変更」サブタブが選択された「履歴」タブ

2.1.3 Service Busプロジェクトおよびフォルダ

プロジェクト・ナビゲータは、構成とリソースをプロジェクトとフォルダに整理します。ドメイン内のすべてのプロジェクトはすべてのプロジェクト定義エディタに、プロジェクト内のすべてのリソースはプロジェクト定義エディタに、フォルダ内のすべてのリソースはフォルダ定義エディタに表示できます。プロジェクトおよびフォルダの定義エディタでは、テスト・コンソールの起動やパイプライン・エディタの起動など、リソースに対してアクションを実行することもできます。これらのエディタのいずれかでプロジェクト、フォルダまたはリソースの名前をクリックすると、そのコンポーネントのエディタが表示されます。

Service Busリソース(サービス、WSDLファイル、XQuery変換など)はすべて、1つのプロジェクトにのみ存在します。複数のプロジェクトでリソースを共有することはありません。リソースはプロジェクトの直下に作成することも、整理用にフォルダを作成したうえで、フォルダ内に作成することもできます。ただし、すべてのリソースは、どのプロジェクトに含まれていても、自由に参照できます。

Service Busでドメインを作成すると、デフォルトのプロジェクトが自動的に作成されます。

2.1.3.1 システム・プロジェクト

プロジェクト・ナビゲータには「システム」という名前のデフォルトのプロジェクトが含まれ、ここには、JNDIプロバイダ、SMTPサーバー、プロキシ・サーバー、UDDIレジストリなどのグローバル・リソースのフラット・ファイルが含まれます。プロジェクトには、各種グローバル・リソースのフォルダが含まれます。システム・フォルダにはプロジェクトやフォルダを作成することはできません。グローバル・リソースのみとなります。システム・プロジェクト内に作成するグローバル・リソースは、作成するすべてのService Busプロジェクトのリソースが使用できます。

図2-4 コンソールの「システム」プロジェクト

2.1.3.2 プロジェクトおよびフォルダの名前

プロジェクト名およびフォルダ名は、最長64文字で、「Service Busコンポーネントのネーミング・ガイドライン」のガイドライン・リストに従う必要があります。

プロジェクトやフォルダの名前、長さ、ネストのレベルは最終的に、お使いのオペレーティング・システムの制限による影響を受けます。フォルダまたはプロジェクトの作成時に、非常に長い名前にしたり、フォルダのネスト・レベルを深くすると、オペレーティング・システムの制限により失敗する場合があります。

2.1.3.3 プロジェクトとフォルダを使用した修飾リソース名

プロジェクトおよびフォルダによりService Busリソースの名前が修飾されます。リソースへの参照は次のように構成されます。

project-name/folder/.../subfolder/resource-name

2.1.4 Service Busリソース

Service Busで作成されるコンポーネントはリソースと呼ばれます。リソースには、サービスのエンドポイントを定義するプロキシ・サービスやビジネス・サービス、およびサービスのメッセージ処理ロジックを定義するパイプラインや分割-結合が含まれます。リソースには、サービス・アカウント、WSDLドキュメント、JNDIプロバイダ、MQ接続などのサポート・リソースも含まれます。リソースは、作成されたプロジェクトおよびフォルダに格納されます。一部のリソースは、異なるプロジェクト間で共有することもできます。

2.1.5 Oracle Service Busコンソール・エディタ

各種リソースは、そのタイプのリソースに固有のコンソール内のエディタを使用して構成できます。プロジェクト・ナビゲータからリソースを開くと、そのリソースの定義エディタが表示され、そのリソースのプロパティを構成できます。定義エディタの右上のツールバーには、「保存」、「すべて保存」、「ヘルプ」、「閉じる」および「すべて閉じる」を含む標準のツール・セットが用意されています。さらに、各エディタには、構成されているリソースに固有のツールも含まれます。これらのツールにより、テスト・コンソールの起動、パイプライン・エディタの起動、WSDLファイルのエクスポート、参照の表示などの追加タスクを実行できます。次の図に、プロキシ・サービス定義エディタを示します。

図2-5 プロキシ・サービス定義エディタ

2.2 スタート・ガイド

Oracle Service Busコンソールの使用を開始するには、WebブラウザおよびログインIDとパスワードが必要です。

- Oracle Service Busコンソールへのアクセス方法

- Oracle Service Busコンソールの終了方法

2.2.1 Oracle Service Busコンソールへのアクセス方法

Oracle Service Busコンソールには、Webブラウザからアクセスします。

Oracle Service Busコンソールを起動するには:

1. Service Busドメインを起動します。

2. サーバーが起動したら、ブラウザに次のいずれかのURLを入力します。

http://hostname:port/servicebus

または、SSLの場合:

https://hostname:port/servicebus

hostnameはService Bus管理サーバーの名前、portはリスニングを行うポート番号を表します。

ログイン・ページが表示されます。

3. インストール時に指定したユーザー名とパスワードを入力します。

注意:

Service Busサンプル・ドメインのユーザー名とパスワードはweblogic/welcome1です。

4. 「ログイン」をクリックします。

2.2.2 Oracle Service Busコンソールの終了方法

Oracle Service Busコンソールからログアウトするには、右上付近のバナーにある「ログアウト」をクリックします。

2.3 セッションの操作

コンソールでService Busリソースを作成および変更する際は、セッションの中でこれを行います。リソースのテストの準備が整ったら、セッションをアクティブ化し、これらのリソースをランタイムに昇格します。セッションのアクティブ化または終了の前には、すべての変更を保存する必要があります。

セッションの履歴を表示するには、「既存のセッションの表示方法」を参照してください。

- セッションの作成方法

- セッションのアクティブ化方法

- セッションの終了方法

2.3.1 セッションの作成方法

Oracle Service BusコンソールでService Busプロジェクトに変更を加えるには、その前にセッション・ツールバーのボタンを使用して新しいセッションを開始するか、既存のセッションを編集する必要があります。これらのボタンは、セッションの状態によって変わります。アクティブなセッションがない場合、次の図の「編集」ボタンは「作成」になります。セッションを操作中の場合、「編集」ボタンは「アクティブ化」になります。

図2-6 「セッション」ツールバー

セッションを作成するには:

1. 次のいずれかを行います。

- 新しいセッションを開始するには、「作成」をクリックします。

- 既存のセッションを編集するには、「編集」をクリックします。

セッションの名前は画面の左上隅に表示されます。

2. セッション内で変更を行います。

3. 変更するコンポーネントごとに「保存」をクリックします。

4. 現在のセッションで行った変更を破棄するには、「破棄」をクリックします。

5. 変更が完了したら、「セッションのアクティブ化方法」の説明に従ってセッションをアクティブ化します。

2.3.2 セッションのアクティブ化方法

セッションの作成と破棄は、システムの他のアクティビティとは関係なく実行されます。ただし、別のセッションのアクティブ化が処理中である場合、WebLogic Serverの変更を保留しているユーザーを示すエラーが発生します。

すべてのエラー競合を解決するまで、セッションをアクティブ化することはできません。警告のみのセッションはアクティブ化できます。競合の解決の詳細は、「競合の表示と解決」を参照してください。

注意:

別のサーバー(作業しているサーバー以外の単一のサーバー、またはクラスタ内の管理対象サーバー)上のJMSエンドポイントのURIを使用してセッションをアクティブ化する場合は、宛先サーバーが使用可能であることを確認してください。Service Busでは、JMSエンドポイントのURLが指定する宛先に到達不能な場合、プロキシ・サービスをJMSトランスポートに登録できません。つまり、JMSサービスの場合、Service Busは指定された接続ファクトリが存在するかどうかを確認し、存在しない場合はセッションのアクティブ化エラーが発生します。

セッションをアクティブ化するには:

1. セッションの変更が完了したら、「アクティブ化」をクリックします。

2. 検証エラーがない場合は、手順5に進みます。

3. 検証エラーがある場合は、エラー・メッセージが表示されます。手順を進める前に、構成の競合を表示し、修正します。

既存の競合を表示している間に新しい競合が生じた場合は、新しい競合を知らせるメッセージが表示されます。

4. すべての競合が解決されたら、再度「アクティブ化」をクリックします。

5. 「説明」フィールドに、セッションを識別する簡単な説明を入力します。これは、セッションのアクティブ化によって発生した構成変更の履歴を表示すると、「説明」列に表示されます。

6. アクティブ化を完了するには、「アクティブ化」をクリックします。待ち時間に新しい衝突が発生しなければ、セッションが終了し、構成がランタイムにデプロイされます。

2.3.3 セッションの終了方法

セッションを終了しても、セッションが完了したり、ランタイムに対して変更がアクティブ化されるわけではありません。終了すると、コンソールには、ランタイムの状態でアクティブなコア構成が表示されます。セッションで行った変更で、アクティブ化されていないものは表示されません。これは、コンソールからログアウトする場合やブラウザを終了する場合にも当てはまります。セッション、およびセッションで行ったすべての変更は、ログアウトした場合やサーバーを再起動した場合でもそのまま残ります。「編集」をクリックしてセッションに戻ると、以前の変更が表示され、変更を続行できます。

セッションが完了するのは、セッションがアクティブにされたか、破棄された場合のみです。「セッションのアクティブ化方法」を参照してください。

セッションを終了するには:

- いつでも「終了」をクリックしてセッションを終了できます。

2.4 Oracle Service Busコンソールでのプロジェクト、フォルダおよびリソースの操作

Service Busリソースは、階層化されない、独立した最上位のグループ構造である、個々のプロジェクトに編成できます。サービス、WSDLファイル、XQuery変換などすべてのリソースは、厳密に1つの重複しないプロジェクトのみに存在します。

リソースは、プロジェクトの下に直接作成することも、プロジェクト内のフォルダに作成してさらにこれらを編成することもできます。各フォルダには、リソースのセットが含まれ、プロジェクト・レベルを最上位ディレクトリとするファイル・システムのディレクトリのように、さらにフォルダを含めることもできます。プロジェクト内のリソースから、別のプロジェクトで定義されたリソースを参照および使用できます。プロジェクトまたはフォルダ間でリソースを移動したり、リソースの名前変更やリソースの削除を行うことができます。Service Busでは、リソース、プロジェクトまたはフォルダのクローンを作成して、指定されたターゲットIDでそのリソースのコピーを作成することもできます。Service Busコンポーネントのクローンを作成すると、そのプロジェクトまたはフォルダのすべてのアーティファクトが別の場所にコピーされます。Service Busでは、リソースの名前変更または移動が行われても依存性は保持され、名前変更または移動されたリソースへの参照も調整されます。

2.4.1 サービスの検索方法

プロジェクト・ナビゲータでプロジェクトおよびフォルダを移動することによってOracle Service Busコンソールでサービスを見つけることができます。また、サービスの検索を実行することもできます。

注意:

検索ではワイルドカード文字を使用できます。複数の不明文字を表すにはアスタリスク(*)を使用し、1文字の不明文字を表すには疑問符(?)を使用します。検索では、大文字と小文字が区別されます。

任意のプロジェクトでサービスを検索するには:

1. 「Designer」タブの隣にある「検索」フィールドに、検索するプロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合の名前を入力し、「検索」アイコンをクリックします。

検索結果は、「検索結果」タブに表示されます。

図2-7 サービスの「検索結果」タブ

2. フル・ページで結果を表示するには、「デタッチ」をクリックします。

3. ビュー・オプションを変更するには、「表ビューのカスタマイズ方法」を参照してください。

2.4.2 プロジェクトおよびフォルダの定義エディタの操作

プロジェクト定義エディタおよびフォルダ定義エディタを使用して、Service Busセッションと構成フレームワークのプロジェクト、フォルダ、リソースに関する情報を表示します。これらのエディタから、セッション内の各プロジェクト、プロジェクト内の各フォルダおよびリソース、フォルダ内の各リソースを表示できます。リソースのテスト、パイプライン・エディタの起動など、特定のオブジェクトに対してアクションを実行することもできます。使用可能なアクションは、表示しているリソースのタイプによって異なります。

2.4.2.1 プロジェクト、フォルダおよびリソース情報について

プロジェクトおよびフォルダの定義エディタでは、Service Busのプロジェクト、フォルダおよびリソースに関する情報を表示する方法をカスタマイズできます。エディタの表ビューでは、列の表示および非表示、列の順序変更、および表示するプロジェクト、フォルダ、リソースの名前によるフィルタを行うことができます。

2.4.2.2 セッション内のすべてのプロジェクトの表示

セッション内のすべてのプロジェクトを表示するには:

1. プロジェクト・ナビゲータで、「すべてのプロジェクト」をクリックします。

すべてのプロジェクト定義エディタが表示され、「すべてのプロジェクト」表にプロジェクトのリストが示されます。

図2-8 すべてのプロジェクト定義エディタ

2. 表にリストされるプロジェクトを名前によりフィルタするには、「プロジェクトおよびフォルダの定義エディタでのコンポーネントのフィルタ方法」を参照してください。

3. 表内の情報の表示方法を変更するには、「表ビューのカスタマイズ方法」を参照してください。

2.4.2.3 プロジェクト内のフォルダおよびリソースの表示

プロジェクト内のフォルダおよびリソースを表示するには:

1. プロジェクト・ナビゲータで、プロジェクトの名前をクリックします。

プロジェクト定義エディタが表示され、選択したプロジェクトに含まれる各フォルダとService Busリソースのリストが示されます。

図2-9 プロジェクト定義エディタ

2. 表にリストされるフォルダおよびリソースを名前によりフィルタするには、「プロジェクトおよびフォルダの定義エディタでのコンポーネントのフィルタ方法」を参照してください。

3. 表内の情報の表示方法を変更するには、「表ビューのカスタマイズ方法」を参照してください。

2.4.2.4 フォルダ内のサブフォルダおよびリソースの表示

フォルダ内のサブフォルダおよびリソースを表示するには:

1. プロジェクト・ナビゲータで、表示するフォルダに移動し、その名前をクリックします。

フォルダ定義エディタが表示され、選択したフォルダに含まれる各サブフォルダとService Busリソースのリストが示されます。

図2-10 フォルダ定義エディタ

2. 表にリストされるフォルダおよびリソースを名前によりフィルタするには、「プロジェクトおよびフォルダの定義エディタでのコンポーネントのフィルタ方法」を参照してください。

3. 表内の情報の表示方法を変更するには、「表ビューのカスタマイズ方法」を参照してください。

2.4.2.5 プロジェクトおよびフォルダの定義エディタでのコンポーネントのフィルタ方法

Service Busでは、例による問合せ機能を提供しています。これにより、プロジェクトやフォルダの定義エディタに表示するプロジェクト、フォルダまたはリソースをフィルタし、リストされているすべてのコンポーネントをスクロールすることなく、必要なService Busコンポーネントのみを表示できるようにします。

プロジェクトおよびフォルダの定義エディタでコンポーネントをフィルタするには:

1. 「プロジェクト、フォルダおよびリソースの情報の表示について」の説明に従って、プロジェクトまたはフォルダの定義エディタを起動します。

2. 表の最初の行の上に「例示問合せ」バーが表示されない場合は、「例示問合せ」(フィルタ・アイコン)をクリックします。

3. 「名前」列の上のフィールドに、表示するプロジェクト、フォルダまたはリソースの名前を入力し、[Enter]を押します。

リストには、入力した名前に一致するコンポーネントのみが表示されます。

注意:

問合せではワイルドカード文字を使用できます。複数の不明文字を表すにはアスタリスク(*)を使用し、1文字の不明文字を表すには疑問符(?)を使用します。問合せでは、大文字と小文字が区別されます。

2.4.3 リソースの新しいプロジェクトおよびフォルダの作成

コンソール内のリソースは、プロジェクトごとにグループ化されます。Service Busリソースを作成する前に、プロジェクトを作成する必要があります。フォルダをプロジェクト内および他のフォルダ内に作成し、プロジェクト・コンポーネントをいくつかの論理グループに編成できます。

2.4.3.1 プロジェクト・ナビゲータでのプロジェクトの作成

プロジェクトを作成するには:

1. プロジェクト・ナビゲータで、「すべてのプロジェクト」を右クリックします。

2. 「作成」→「プロジェクト」を選択します。

「新規プロジェクトの作成」ダイアログが表示されます。

3. プロジェクトに対して一意の名前を入力し、必要に応じてで説明を追加します。

ネーミング・ガイドラインについては、「プロジェクトおよびフォルダの名前」を参照してください。

4. 「作成」をクリックします。

新しいプロジェクトが、プロジェクト・ナビゲータとプロジェクト定義エディタに表示されます。

2.4.3.2 プロジェクト・ナビゲータでのフォルダの作成

フォルダを作成するには、以下の手順に従います。

1. プロジェクト・ナビゲータで、新しいフォルダを追加するプロジェクトまたはフォルダを右クリックします。

2. 「作成」→「フォルダ」を選択します。

「新規フォルダの作成」ダイアログが表示されます。

3. フォルダに対して一意の名前を入力し、必要に応じてで説明を追加します。

4. 「作成」をクリックします。

新しいフォルダが、プロジェクト・ナビゲータとフォルダ定義エディタに表示されます。

2.4.4 リソース・ギャラリを使用したリソースの作成

リソース・ギャラリは、Service Busコンソールに追加できるすべてのリソースを収集します。Oracle Service Busのこのリリースでリソースを作成するには、リソース・ギャラリを使用します。

リソース・ギャラリを使用してコンソールにリソースを追加するには、次のようにします。

1. プロジェクト・ナビゲータから、リソースに追加するプロジェクトまたはフォルダを右クリックして、「作成」→「リソース」を選択します
リソース・ギャラリが表示されます。

2. リソース・ギャラリ内をナビゲートして、追加するリソースのタイプを見つけます。リソースを選択して、「OK」をクリックします。
選択したリソースの作成ダイアログが表示されます。必要な手順を実行して、リソースの作成を終了します。

2.4.5 プロジェクト、フォルダおよびリソースのクローン作成方法

プロジェクトまたはフォルダのクローンを作成すると、プロジェクトまたはフォルダのすべてのリソースが別の場所にコピーされます。個々のリソースのクローンを作成して、別のフォルダまたはプロジェクトにコピーすることもできます。Service Busでは、オブジェクトのクローン作成時の依存性が保持され、すべての参照が調整されます。

プロジェクト、フォルダおよびリソースのクローンを作成するには:

1. プロジェクト・ナビゲータで、クローンを作成するプロジェクト、フォルダまたはリソースに移動し、これを右クリックします。

2. 「クローン」をクリックします。

「クローン」ダイアログが表示されます。

3. オプションで、「新規 <Resource> 名」フィールドに、コンポーネントの新しい名前を入力します。

4. 「宛先」セクションで、選択したコンポーネントのクローンの作成先のプロジェクトまたはフォルダを選択します。

5. 「クローン」をクリックします。

クローン・コンポーネントが選択した場所に表示されます。すべての依存性は保持されます。

2.4.5.1 プロジェクトのクローン作成時の動作

新しいプロジェクトの名前および宛先により、プロジェクトをフォルダに降格したり、既存のプロジェクトと結合したり、既存のフォルダと結合することもできます。ルートの場所にプロジェクトのクローンを作成する場合、クローン・コンポーネントに対して新しい名前を入力する必要があります。次の方法でプロジェクトのクローンを作成できます。いずれの場合も、元のプロジェクトは不変です。

- プロジェクトのクローンを新しい名前を使用してすべてのプロジェクト・レベルで作成します。元のプロジェクトとそのクローンはピア・プロジェクトとして存在し、クローン・プロジェクトには元のプロジェクトと同じフォルダおよびリソースが含まれます。

- プロジェクトのクローンを、元のプロジェクト以外の既存プロジェクト名を使用して作成します。元のプロジェクトのフォルダおよびリソースは、クローンに名前が与えられたプロジェクトのフォルダおよびリソースと結合されます。

- プロジェクトのクローンを、既存のプロジェクトまたはプロジェクト・フォルダ内の新しい場所に、一意の名前で作成します。クローン・プロジェクトは新しい場所のフォルダに降格され、ここには元のプロジェクトと同じフォルダおよびリソースが含まれます。

- プロジェクトのクローンを、既存のプロジェクトまたはプロジェクト・フォルダ内の新しい場所に、既存フォルダと同じ名前で作成します。プロジェクトの内容(サブフォルダおよびリソース)は、ターゲット・フォルダ内のターゲット・フォルダの内容と結合されます。

2.4.5.2 フォルダのクローン作成時の動作

新しいフォルダの名前および宛先により、フォルダをプロジェクトに変換したり、既存のプロジェクトと結合したり、既存のフォルダと結合することもできます。現在の場所にフォルダのクローンを作成する場合、クローン・コンポーネントに対して新しい名前を入力する必要があります。次の方法でフォルダのクローンを作成できます。いずれの場合も、元のフォルダは不変です。

- フォルダのクローンを新しい名前を使用して元のフォルダと同じ場所に作成します。元のフォルダとそのクローンはピアとして存在し、クローン・フォルダには元のフォルダと同じサブフォルダおよびリソースが含まれます。

- フォルダのクローンを、元のフォルダ以外の既存フォルダ名を使用して作成します。元のフォルダのサブフォルダおよびリソースは、クローンに名前が与えられたフォルダのサブフォルダおよびリソースと結合されます。元のフォルダは不変です。

- フォルダのクローンを、既存のプロジェクトまたはプロジェクト・フォルダ内の新しい場所に作成します。この場合、クローン・フォルダには元のフォルダと同じフォルダおよびリソースが含まれます。元のフォルダは不変です。

2.4.6 プロジェクト、フォルダおよびリソースの名前変更方法

Service Busコンポーネントの名前を変更すると、すべての参照が自動的に更新されます。

注意:

UDDIレジストリからインポートされたビジネス・サービスの名前を変更すると、そのサービスはレジストリからデタッチされます。

Service Busコンポーネントの名前を変更するには:

1. プロジェクト・ナビゲータで、名前を変更するコンポーネントに移動します。

2. コンポーネントを右クリックし、「名前変更」を選択します。

3. コンポーネントの名前のテキストを選択し、新しい名前を入力します。ネーミング・ガイドラインについては、「プロジェクトおよびフォルダの名前」を参照してください。

4. [Enter]を押します。

コンポーネントの名前が変更されます。

2.4.7 プロジェクト、フォルダおよびリソースの移動方法

リソースを別の場所に移動する場合、Service Busでは、そのリソースに対するすべての依存性を保持します。プロジェクトを別のプロジェクトに移動する場合、Service Busでは、これを後者のプロジェクト内のフォルダに変換します。逆に、フォルダを「すべてのプロジェクト」ノードに移動する場合、Service Busでは、これをプロジェクトに変換します。

Service Busコンポーネントを移動するには:

1. プロジェクト・ナビゲータで、移動するプロジェクト、フォルダまたはリソースに移動し、これを右クリックします。

2. 「移動」をクリックします。

「移動」ダイアログが表示されます。

3. 「宛先」セクションで、選択したコンポーネントの移動先のプロジェクトまたはフォルダを選択します。

4. 「移動」をクリックします。

移動したコンポーネントが選択した場所に表示されます。すべての依存性は保持されます。

注意:

同じ名前のコンポーネントがすでに含まれているプロジェクトまたはフォルダにコンポーネントを移動することはできません。

2.4.8 プロジェクト、フォルダおよびリソースの削除方法

プロジェクトまたはフォルダを削除すると、そのフォルダの下にあるリソースがすべて削除されます。このフォルダの下にあるリソースが別のプロジェクトまたはフォルダの下にあるリソースから参照されている場合、リソースを削除することはできますが、確認のための警告が出されます。この場合、削除されたリソースへの未解決の参照が原因で、競合が発生する可能性があります。

Service Busコンポーネントは、プロジェクト・ナビゲータまたはプロジェクトやフォルダの定義エディタから削除できます。エディタから削除する場合は、同じコンテナ内の複数のコンポーネントを同時に削除できます。

警告:

パイプライン・テンプレート・リソースを含むプロジェクトまたはフォルダを削除する場合、そのテンプレートから派生したすべての具象パイプラインはリンク解除されます。

2.4.8.1 プロジェクト・ナビゲータを使用したService Busコンポーネントの削除

プロジェクト・ナビゲータを使用してService Busコンポーネントを削除するには:

1. プロジェクト・ナビゲータで、削除するコンポーネントに移動します。

2. コンポーネントを右クリックし、「削除」を選択します。

3. 表示される「確認」ダイアログで、「はい」をクリックしてプロセスを完了します。

コンポーネントがプロジェクト・ナビゲータとセッションから削除されます。

2.4.8.2 エディタを使用したService Busコンポーネントの作成

エディタを使用してService Busコンポーネントを削除するには:

1. プロジェクト・ナビゲータで、削除するコンポーネントを含むプロジェクトまたはフォルダに移動します。

2. プロジェクトまたはフォルダをクリックして、そのエディタを表示します。プロジェクトを削除するには、かわりに「すべてのプロジェクト」ノードをクリックします。

プロジェクトまたはフォルダの定義エディタが表示されます。

3. コンポーネントの表で、削除する各コンポーネントを選択し、「削除」アイコンをクリックします。

ヒント:

複数のコンポーネントを選択するには、[Ctrl]キーを押したまま、削除する各コンポーネントをクリックします。

4. 表示される「確認」ダイアログで、「はい」をクリックしてプロセスを完了します。

コンポーネントが、エディタ、プロジェクト・ナビゲータおよびセッションから削除されます。

2.5 競合の表示と解決

「競合」タブには、構成のエラーに関する診断メッセージが、セッション内で行った変更と他のアクティブ化されたセッションで行われた変更との間の競合とともに表示されます。競合は、Service Busリソースにセマンティック・エラーがある場合、または別のセッションですでに変更およびアクティブ化されたリソースを現在のセッションで変更する場合に発生します。2つのセッションによって同一リソースに対して2つの変更が行われた場合は、どちらか一方のセッションがアクティブになるまで競合は発生しません。「競合」アイコンをクリックしてアクセスできる「競合」タブから、競合を表示して解決できます。

ツールバーの「競合」アイコンには、セッション中の現在の競合の数が表示されます。

図2-11 ツールバーの競合アイコン

「競合」タブには、競合の種類に応じて次の情報セットが表示されます。

- エラー: 「エラー」アイコンは、変更をコミットできない重大な競合が構成内にあることを示します。競合を解決しないと、変更をコミットすることはできません。

- 同時更新: 「警告」アイコンは、変更のコミットが可能な重大ではない競合があることを示します。これらは、他のアクティブ化されたセッションと互換性のない変更があることを警告します。

- 情報メッセージ: 「警告」アイコンは、変更のコミットが可能な重大ではない競合が構成内にあることを示します。

2.5.1 競合およびエラーの表示方法

「競合」タブには、現在のService Bus構成内のエラー、および行った変更と他のアクティブ化との間の競合が反映されます。すべての競合を表示することも、現在のリソース・エディタに表示されているリソースの競合のみを表示することもできます。「競合」アイコンをっクリックして「競合」タブを表示します。

図2-12 「競合」タブ

2.5.1.1 Service Busコンソールでのすべての競合およびエラーの表示

すべての競合およびエラーを表示するには:

1. 次のいずれかを実行して「競合」タブにアクセスします。

- ツールバーの一番上の「エラー」アイコンをクリックします。

- ページの下部にある「競合」タブをクリックします。

2. 構成内のエラーを表示するには、「競合」タブの「エラー」をクリックします。

3. 他のアクティブ化の同時更新との競合を表示するには、「競合」タブの「同時更新」をクリックします。

4. 特定の競合の詳細を表示するには、その競合の「名前」列のリンクをクリックします。

2.5.1.2 デプロイされたリソースのための競合およびエラーの表示

Service Busリソースにエラーが含まれる場合、そのエディタにそのコンポーネントを表示すると、エディタの名前の横に競合アイコンが表示されます。

表示されたリソースの競合およびエラーを表示するには:

1. リソースをそのエディタに表示して、エディタ・タイトルの横(ビジネス・サービス定義の横など)の「競合」アイコンをクリックします。

ページの下部にある「競合」タブで、最初の競合が強調表示されます。

2. その競合を開き、競合の原因となったエラーに関する追加情報を表示します。

3. コンポーネントの競合をスクロールするには、「競合」アイコンの横の左矢印および右矢印をクリックします。

2.5.2 競合およびエラーの解決方法

セッションをアクティブ化する前に、そのセッション内のすべてのエラー競合を解決する必要があります。競合を解決するには、「競合」タブの「エラー」表および「同時更新」表に示された情報を使用して問題を理解し、競合の原因となっているコンポーネントを変更します。

2.5.2.1 同時更新の競合の解決

別のセッションですでに変更およびアクティブ化されたリソースを現在のセッションで変更したために競合が発生した場合、その競合は、次の2つの方法のいずれかにより解決できます。

- ランタイムに対して変更を保存し、競合するセッションにデプロイされた変更をオーバーライドするには、右上のツールバーの「アクティブ化」をクリックします。
競合するセッションのユーザーによりアクティブ化された変更は、このセッションの変更により上書きされます。

- このセッションのコンポーネントをランタイムに保存された状態に戻すには、「同時更新」表でコンポーネントを選択して、表の上の「同期」をクリックします。
セッション内のリソースは、競合するセッションでアクティブ化された変更内容で更新されます。これで、更新を行い、変更をアクティブ化できます。

2.5.2.2 エラーの競合の解決

エラーの競合を解決するには:

1. 「競合」タブの「エラー」表で、解決するリソースの左にある「展開」アイコンをクリックします。

リソースの下にエラー・メッセージが表示されます。

2. リソースの名前をクリックし、Service Busエディタでこれを開きます。

3. リソースを更新して、エラー・メッセージに示された情報に基づいて問題を修正します。

4. 「保存」をクリックします。

5. すべての競合が解決されるまで、これらの手順を繰り返します。

2.6 履歴データの表示

「履歴」タブには、「変更」、「セッション」および「アクティブ化」という3つの異なるビューがあります。

- 現在のセッションで行われた変更の表示方法

- 既存のセッションの表示方法

- アクティブ化されたセッションで行われた変更の表示方法

- アクティブ化されたセッションのパージ方法

2.6.1 現在のセッションで行われた変更の表示方法

「履歴」タブの「変更」ビューには、セッション内で作業しているかどうかによって異なる情報が表示されます。セッション内の場合は、現在のセッションで行われた構成の変更内容が「変更」ビューにリストされます。セッション外の場合は、「変更」ビューに変更内容は表示されません。

図2-13 「履歴」タブ

現在のセッションの変更を表示するには:

1. 次の図に示すように、ツール・アイコンをクリックして、「履歴」をクリックします。

「変更」ビューが選択された状態で「履歴」タブが表示されます。「変更」表には、行われた変更のタイプ、各変更が行われた時間、各変更を行った人、ステータス、および変更が取り消された場合にその取消しを行った人が表示されます。

2. リストされている変更を取り消すには、「現在のセッションの特定の変更を取り消す方法」を参照してください。

2.6.2 既存のセッションの表示方法

「履歴」タブの「セッション」ビューには、Oracle Service Busコンソール内に存在するすべてのセッションのリストが表示されます。これらのセッションは、セッション内にいる場合にもセッション外にいる場合にも表示できます。

すべてのセッションが表示されるのは、管理ロールでログインしている場合のみです。詳細は、『Oracle Service Busの管理』のOracle Service Busのアクセス・セキュリティの定義に関する項を参照してください。

既存のセッションを表示するには:

1. Service Busコンソールの左上から、ツール・アイコンをクリックし、「履歴」をクリックします。

「変更」ビューが選択された状態で「履歴」が表示されます。

2. 表の上の「セッション」をクリックします。

「セッション」表が表示され、セッション、各セッションの作成者、各セッションの作成および変更日時、および変更されたリソースの数がリストされます。

3. リスト内のセッションに切り替えるには、そのセッションを選択し、「セッションへの切替え」アイコンをクリックします。

注意:

同一ユーザーによる複数ブラウザへのログインはサポートされていません。そのような操作を行うと、コンソールで予期できない動作が生じるおそれがあります。

2.6.3 アクティブ化されたセッションで行われた変更の表示方法

「履歴」タブの「アクティブ化」ビューには、すべてのService Busアクティブ化のリストが表示されます。リストされているアクティブ化ごとに、アクティブ化された変更の履歴を表示できます。

アクティブ化されたセッションで行われた変更を表示するには:

1. Service Busコンソールの左上から、ツール・アイコンをクリックし、「履歴」をクリックします。

「変更」ビューが選択された状態で「履歴」が表示されます。

2. 表の上の「アクティブ化」をクリックします。

「アクティブ化」表が表示され、アクティブ化、その説明、各アクティブ化の発生時間、各セッションのアクティブ化を行った人、アクティブ化のステータス、およびアクティブ化が取り消された場合にその取消しを行った人が表示されます。

3. アクティブ化の各変更の情報を表示するには、「アクティブ化」列でそのアクティブ化をクリックします。

「タスクの詳細」ダイアログが表示され、選択したセッション内で行われた各変更のリストが示されます。

4. タスクの詳細にリストされたリソースまたは場所(パス)を表示するには、そのリソースまたは場所の名前をクリックします。

リソースまたは場所がService Busエディタで開かれます。

5. アクティブ化の取消しまたはアクティブ化のタスクのパージを行うには、次のトピックを参照してください。

- アクティブ化されたセッションのパージ方法

- セッションのアクティブ化を取り消す方法

- 現在のセッションの特定の変更を取り消す方法

2.6.4 アクティブ化されたセッションのパージ方法

アクティブ化されたすべてのセッション、または開始日と終了日で区切られた特定の期間にアクティブ化されたセッションのみをパージできます。このアクションはセッション外でのみ可能です。

警告:

セッションのアクティブ化履歴のパージには、複数レベルの取消しを可能にするデータの削除が含まれます。特定の期間について、セッションのアクティブ化履歴をパージすると、その期間中にアクティブ化されたセッションの取消しはできなくなるということです。

アクティブ化されたセッションで行われた変更を表示するには:

1. アクティブなセッション内で作業していないことを確認します。

2. Service Busコンソールの左上から、ツール・アイコンをクリックし、「履歴」をクリックします。

「変更」ビューが選択された状態で「履歴」が表示されます。

3. 表の上の「アクティブ化」をクリックします。

4. 表の上の「タスクのパージ」アイコンをクリックします。

「アクティブ化履歴のパージ」ダイアログが表示されます。

5. 「アクティブ化履歴のパージ」ダイアログで、次のいずれかを実行します。

- すべてのセッションのすべてのタスクをパージするには、「すべてのタスクのパージ」を選択します。

- 特定の期間のタスクをパージするには、「選択したタスクのパージ」を選択し、パージする期間の開始日時と終了日時を入力します。

6. 「パージ」をクリックしてから、「はい」をクリックしてパージすることを確認します。

選択したアクティブ化がリストから削除され、パージの説明とともに新しいエントリが表示されます。

2.7 変更およびアクティブ化の取消し

セッション内で作業している間は、タスクを任意の順序で取り消すことができます。取消し操作により、リソースの構成は、取り消す変更を行う前の構成に設定されます。取り消そうとしているタスクがリソースを作成したタスクである場合、そのリソースを戻すことができる前の状態がありません。つまり、このタスクを実行する前は、リソースが存在していませんでした。実際には、取消し操作により、セッションからそのリソースが削除されます。この場合、削除されるリソースへの参照があると、エラーが発生します。そのようなエラーは、「競合」タブで確認できます。Service Busでは、無制限の取消し操作をサポートしています。つまり、取消し操作の取消しも可能です。

セッションを操作していない場合は、以前にアクティブ化したセッションの履歴を表示できます。これらのセッションは取り消すこともできます。セッションを取り消すことでランタイム構成エラーが発生する場合は、以前にアクティブ化したセッションを取り消すことはできません。たとえば、セッションのアクティブ化を取り消すことによって、他のリソースが参照するリソースが削除対象になる場合は、この取消し操作を実行できません。

2.7.1 現在のセッションの特定の変更を取り消す方法

「履歴」タブの「変更」ビューで、現在のセッション中に実行した特定のタスクを取り消すことができます。現在のセッションでの変更を取り消すことができます。ただし、誤って取消し操作を実行したことに気付いた場合、そのアクションも取り消すことができます。

現在のセッションの特定の変更を取り消すには:

1. Service Busコンソールの左上から、ツール・アイコンをクリックし、「履歴」をクリックします。

「変更」ビューが選択された状態で「履歴」が表示されます。

2. 取り消す変更を選択し、表の上の「取消し」アイコンをクリックします。

変更が取り消されます。作成タスクを取り消すと、選択したリソースはセッションから削除され、プロジェクト・ナビゲータには表示されなくなります。削除タスクを取り消すと、選択したリソースは再度セッションに追加され、プロジェクト・ナビゲータに再表示されるようになります。

2.7.2 セッションのアクティブ化を取り消す方法

「履歴」タブの「アクティブ化」ビューで、セッションのアクティブ化を取り消すことができます。セッションのアクティブ化を取り消すことによりセマンティク・エラーが発生する場合は、アクティブ化の取消し操作を実行することはできません。かわりに、セッションのアクティブ化を取り消し、その変更結果を新しいセッションに移すという方法があります。その後、セマンティク・エラーを修正し、その新しいセッションをアクティブ化します。この元に戻してセッションに移動する機能を使用して、セッションのアクティブ化を取り消した場合の影響を調べることも可能です。結果的に生じる変化をすべて調べ、アクティブ化を取り消すかどうかを判断できます。Service Busでは、システム・リソースの制約のみで、複数レベルのセッションのアクティブ化を取り消すことができます。

セッションのアクティブ化を取り消すには:

1. Service Busコンソールの左上から、ツール・アイコンをクリックし、「履歴」をクリックします。

「変更」ビューが選択された状態で「履歴」が表示されます。

2. 表の上の「アクティブ化」をクリックします。

「アクティブ化」表に以前のアクティブ化が表示されます。

図2-14 「アクティブ化」タブ

3. アクティブ化を取り消すには、次を実行します。

- 取り消すセッションの右の空フィールドをクリックし、このセッションを選択します。

- 表の上の「取消し」アイコンをクリックします。
セッションのアクティブ化が取り消されます。

4. セッションへのアクティブ化を取り消すには、次を実行します。

- 取り消すセッションの右の空フィールドをクリックし、このセッションを選択します。

- 「セッションでの取消し」をクリックします。
セッションのアクティブ化が取り消され、セッションでアクティブ化された変更を元に戻すために必要なタスクを入力済の新しいセッションが作成されます。

2.8 参照の表示

「参照」タブには、他のリソースを参照するリソース、または他のリソースにより参照されるリソースについての情報が表示されます。プロジェクトおよびフォルダの場合、「参照」には次の内容がリストされます。

- プロジェクトまたはフォルダ内のリソースによって参照されている、現在のプロジェクトまたはフォルダ外のリソース。

- プロジェクトまたはフォルダ内のリソースを参照している、現在のプロジェクトまたはフォルダ外のリソース。

コンソール内のプロジェクト、フォルダまたはリソースの場合、エディタの右上の「参照」アイコンをクリックして、「参照」タブにこれらの参照に関する情報を表示します。

2.8.1 リソース参照の表示

リソースへの参照の表示は、セッション内でもセッション外でも実行できます。

リソース参照を表示するには:

1. プロジェクト、フォルダまたはリソースをそのService Busエディタで開きます。

2. エディタの右上にあるツール・アイコンをクリックして、「参照」を選択します。

「参照」ページが表示され、選択したリソースが太字で表示されます。「参照元」列には、選択したリソースを参照するリソースがリストされます。「参照」列には、選択したリソースが参照するリソースがリストされます。

図2-15 「参照」タブ

3. リソースの名前をクリックすると、そのエディタにそのリソースが表示されます。

4. 「参照元」列のリソースの横の左矢印をクリックすると、そのリソースの参照が表示されます。

5. 「参照」列のリソースの横の右矢印をクリックすると、そのリソースの参照が表示されます。

2.9 Oracle Service Busコンソールの外観のカスタマイズ

コンソール内のいくつかのエディタは表に情報を表示します。この情報を表にどのように表示するかをカスタマイズできます。

- 表ビューのカスタマイズ方法

2.9.1 表ビューのカスタマイズ方法

各表の上のメニュー・バーにより、どの列をどのような順序で表示するかを指定できます。列のソート順を指定したり、表をフルスクリーンで表示することもできます。

2.9.1.1 表示する列の指定

表示する列を指定するには:

1. 表の左上で「表示」をクリックし、「列」を選択します。

サブメニューに、使用可能な列のリストが表示されます。列の横にあるチェックは、その列が表示されることを示しています。

2. 使用可能なすべての列を表示するには、「すべて表示」を選択します。

3. 表示する列を指定するには、「列の管理」を選択します。

「列の管理」ダイアログが表示されます。

図2-16 「列の管理」ダイアログ

4. 表示されている列を非表示にするには、「非表示列」パネルで列名を選択し、右矢印ボタンをクリックします。

5. 非表示の列を表示にするには、「表示される列」パネルで列名を選択し、左矢印ボタンをクリックします。

アスタリスク(*)は必須列を示しています。

6. 表示するすべての列名が「表示される列」フィールドに表示されるまで繰り返します。

「表示される列」フィールドで上向き矢印と下向き矢印を使用し、列名の順序を変更することもできます。

7. 「OK」をクリックします。

2.9.1.2 表内の列のソート

表内の列をソートするには:

注意:

表のソートのデフォルトの順番は、表の先頭の列で決まります。

1. 表の左上で「表示」をクリックし、「ソート」を選択します。

2. 「拡張ソート」を選択します。

3. 「ソート基準」フィールドで最初のソート基準となる列名を選択し、「昇順」または「降順」を選択します。

4. 「次の基準」フィールドで、2番目のソート基準となる列名を選択し、「昇順」または「降順」を選択します。

5. 「OK」をクリックします。

2.9.1.3 表内の列の順序変更

表内の列の順序を変更するには:

1. 表の左上で「表示」をクリックし、「列の並替え」を選択します。

2. 「列の並替え」ダイアログで上向き矢印と下向き矢印を使用し、列の順序を変更します。

3. 完了したら「OK」をクリックします。

ヒント:

列見出しをクリックして表内の別の場所にドラッグすることで、列を移動することもできます。

2.9.1.4 表のフルスクリーン・モードでの表示

表をフルスクリーンで表示するには:

現在のページから表をデタッチし、それをブラウザのサイズに合せてページに表示するには、表の上の「表示」をクリックし、「デタッチ」を選択します。

3 JDeveloperでのOracle Service Busのスタート・ガイド

この章では、JDeveloperでService Busを使用して、サービスおよびその他のサービス・バス・リソースを構成する方法についての一般的な情報を提供します。構成は設計時アクティビティであるため、特に明記されていないかぎり、実行中のWebLogic Serverインスタンスは必要ありません。

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

- Service Busに関するJDeveloperの概念

- JDeveloperでのService Busコンポーネントの管理

- JDeveloperでのService Busアプリケーションおよびプロジェクトの作成

- Service Busプロジェクト、フォルダおよびリソースのリファクタ

JDeveloperの使用の詳細は、Oracle JDeveloperによるアプリケーションの開発を参照してください。

3.1 Service Busに関するJDeveloperの概念

Service Busでは、JDeveloperのエディタ、ウィザードおよびダイアログを使用して、Service Busアプリケーションを作成および構成します。これらは、Service Busコンポーネントに固有のものと、標準のJDeveloperツールのものがあります。たとえば、プロキシ・サービス・エディタとビジネス・サービス・エディタはService Busに固有ですが、XSLTマッパーとXQueryマッパーは、JDeveloperの他の製品で共有されます。Service Busは、JDeveloperのSOA Suiteコンポーネントと多くの機能を共有します。

次の図に、アプリケーション・ナビゲータのプロジェクト・ファイル、中央にあるService Bus概要エディタおよび右側の「コンポーネント」ウィンドウなど、JDeveloperのService Busアーティファクトを示します。Service Bus概要エディタは、サービスやメッセージ・フローを定義する場所です。「コンポーネント」ウィンドウには、概要エディタの設計キャンバスにドラッグできる様々なService BusおよびSOA Suiteコンポーネントがすべて表示されます。

図3-1 JDeveloperでのOracle Service Bus

3.1.1 アプリケーション・ナビゲータ

アプリケーション・ナビゲータには、Service Busプロジェクトに含まれるすべてのリソースおよびサービスの主要なファイルが表示されます。これには次のようなものがあります。

- Service Busプロジェクトの作成時に自動的に作成されるXMLファイル。このファイルは、サービス、リソース、参照、ワイヤなど、Service Busアプリケーション全体について説明しています。アプリケーション・ナビゲータでは、このファイルの名前はプロジェクトと同じになります。ファイル・システムでは、servicebus.sboverviewという名前になります。

- プロキシ・サービス・ファイル(service_name.proxy)。

- ビジネス・サービス・ファイル(service_name.bix)。

- パイプライン・ファイル(pipeline_name.pipeline)。

- 分割-結合ファイル(splitjoin_name.flow)。

- すべてのリソース・ファイル(サービス・アカウント、WSDLファイル、サービス・キー・プロバイダ、アラート宛先など)。

- クラス・ファイル、XSDファイル(スキーマ)およびXSLファイル(変換)の追加サブフォルダ。

3.1.2 Service Bus概要エディタ

Service Bus概要エディタでは、アプリケーションに含まれるコンポーネントのグラフィカル・ビューで、トップ・ダウン方式によりService Busアプリケーションを設計できます。パイプライン、分割-結合、トランスポート、アダプタおよびバインディングを「コンポーネント」ウィンドウからエディタのデザイナ・ウィンドウにドラッグします。デザイナ・ウィンドウにコンポーネントをドラッグ・アンド・ドロップすると、対応するウィザードが表示され、そのコンポーネントに関連する基本的な構成タスクを実行できます。たとえば、パイプラインをドラッグして、エディタの「パイプライン/分割結合」セクションにドロップすると、「パイプライン・サービスの作成」ウィザードが表示されます。ウィザードを完了すると、エディタにコンポーネントが表示されます。このコンポーネントをダブルクリックしてそのエディタを開くと、さらにその構成を定義できます。次の図に、サービス、パイプラインおよび分割-結合が混在する概要エディタを示します。

図3-2 Service Bus概要エディタ

3.1.3 リソース・エディタ

各種Service Busリソースは、そのリソースに固有のエディタで構成できます。ほとんどのエディタには複数のビューが用意されており、エディタの左下隅でこれらを選択できます。「構成」ビューはほとんどのリソースで利用可能で、ここでほとんどのリソース構成を実行できます。「設計」ビューは、Service Bus概要エディタ、パイプラインおよび分割-結合で利用可能で、メッセージの処理方法をグラフィカルに表します。設計モードでは、「コンポーネント」ウィンドウから直接分割-結合またはパイプラインに、アクティビティをドラッグ・アンド・ドロップできます。一部のリソースでは、「ソース」ビューを使用してソース・コードを表示できます。いくつかのエディタには、「履歴」ビューも含まれています。ここでは、表示されたリソースに対する変更の履歴を確認できます。次の図に、プロキシ・サービス定義エディタの「一般」構成ページを示します。

図3-3 JDeveloperのプロキシ・サービス定義エディタ

3.1.4 「コンポーネント」ウィンドウ

「コンポーネント」ウィンドウは、Service Bus概要エディタ、パイプライン・エディタまたは分割-結合エディタが開かれているときに表示されます。「コンポーネント」ウィンドウには、表示されるエディタにより、Service Busアプリケーション、パイプラインまたは分割-結合で使用できる様々なコンポーネントがリストされます。概要エディタの場合、「コンポーネント」ウィンドウには、リソース、アダプタ、トランスポートなど、アプリケーションに追加できるコンポーネントが表示されます。パイプラインおよび分割-結合の場合、「コンポーネント」ウィンドウには、サービス間のデータのフローの定義に使用できる、ルーティング、変換およびエラー処理のアクションが表示されています。

「コンポーネント」ウィンドウにリストされている要素は、「コンポーネント」ウィンドウから、表示されているエディタにドラッグ・アンド・ドロップできます。「コンポーネント」ウィンドウが表示されていない場合は、「ウィンドウ」メイン・メニューから「コンポーネント」を選択します。次の図に、Service Bus概要エディタの「コンポーネント」ウィンドウを示します。

図3-4 Service Busの「コンポーネント」ウィンドウ

3.1.5 「リソース」ウィンドウ

「リソース」ウィンドウで項目を選択すると、ダイアログが表示され、ここでローカル・リソースとリモート・リソースの両方を参照できます。たとえば、次のリソースにアクセスできます。

- 共有ローカル・アプリケーション・メタデータ(スキーマ、WSDLファイル、イベント定義、ビジネス・ルールなど)。

- HTTP接続、ファイルURLまたはアプリケーション・サーバー接続を介してアクセスできるリモート・リソースを使用するWSILブラウザ機能。

- Universal Description, Discover, and Integration (UDDI)レジストリに登録されるリモート・リソース。

「リソース」ウィンドウが表示されていない場合は、「ウィンドウ」メイン・メニューから「リソース」を選択します。

3.1.6 「プロパティ」ウィンドウ

「プロパティ」ウィンドウには、選択したService Busリソースまたはコンポーネントのプロパティが表示され、ここではパイプライン・アクションおよび分割-結合操作のプロパティを変更できます。構成できるプロパティについては、Service Busのオンライン・ヘルプおよびこのガイドの次の章を参照してください。

- 分割-結合によるサービスのパフォーマンスの向上

- Oracle Service Busコンソールでのパイプライン・アクションの操作

「プロパティ・インスペクタ」が表示されていない場合は、「ウィンドウ」メイン・メニューから「プロパティ・インスペクタ」を選択します。

3.1.7 「構造」ビュー

「構造」ウィンドウには、エディタ内に現在表示されているコンポーネントの構造ビューが用意されています。現在開かれているドキュメントにより、「構造」ウィンドウでは、下部付近のタブに示されている2つのモードでデータを表示できます。

- 「ソース」モードでは、エディタで現在開かれているファイルのコード構造が表示されます。これは、XMLなどのコード編集が可能なテクノロジに適用できます。たとえば、編集用にパイプラインが開かれている場合、このタブは利用できません。

- 「設計」モードでは、エディタで現在開かれているファイルのツリー構造が表示され、コンポーネントの様々なノードを移動できます。

「構造」ウィンドウは動的で、アクティブな現在の選択を常に追跡します。

3.1.8 「ログ」ウィンドウ

「ログ」ウィンドウには、アプリケーションのコンパイル、検証およびデプロイメントに関するメッセージが表示されます。

3.2 JDeveloperでのService Busコンポーネントの管理

JDeveloperでは、Service BusコンポーネントはService Busプロジェクトに含まれ、Service BusプロジェクトはService Busアプリケーションにまとめることができます。リソースはファイル・システム内でファイルとして格納されます。サービス、WSDLファイル、XQuery変換などすべてのリソースは、1つの重複しないプロジェクトに存在します。

リソースは、プロジェクトの下に直接作成することも、プロジェクト内のフォルダに作成してさらにこれらを編成することもできます。各フォルダには、リソースのセットが含まれ、ファイル・システムのディレクトリのように、さらにフォルダを含めることもできます。プロジェクト内のリソースから、別のプロジェクトで定義されたリソースを参照および使用できます。プロジェクトまたはフォルダ間でリソースを移動したり、リソースの名前変更やリソースの削除を行うことができます。Service Busでは、リソースの名前変更または移動が行われても依存性は保持され、名前変更または移動されたリソースへの参照も調整されます。

3.3 JDeveloperでのService Busアプリケーションおよびプロジェクトの作成

JDeveloperで、Service Busリソースはプロジェクトに編成され、プロジェクトはさらにフォルダに分割できます。Service BusプロジェクトはService Busアプリケーションにグループ化されます。

注意:

JDeveloperでService Busアプリケーションとプロジェクトを作成およびデプロイするには、Service Bus拡張機能をインストールする必要があります。この拡張機能をJDeveloperにインストールする手順は、Oracle JDeveloperのインストールのOracle JDeveloper拡張機能の有効化に関する項を参照してください。

3.3.1 アプリケーションおよびプロジェクトの作成ガイドライン

JDeveloperでService Busアプリケーションおよびプロジェクトを作成する際には、次のガイドラインに従ってください。

- アプリケーションおよびプロジェクトを作成する際は、関連付けられているファイルが格納されるディレクトリを指定できます。Service Busプロジェクトは、それらを含むアプリケーションと同じフォルダに作成する必要があります。

- アプリケーションまたはプロジェクトの名前には、空白を使用しないでください。

- 空白があるディレクトリ・パスにアプリケーションおよびプロジェクトを作成することはできません(例: c:\Program Files)。

- アプリケーションとコンポーネントの名前の組合せが500文字を超えることはできません。

- 同じインフラストラクチャにデプロイされるプロジェクトには、すべてのService Busアプリケーションで一意な名前を付ける必要があります。たとえば、表3-1に示すアクションは実行しないでください。デプロイメントでは、2番目にデプロイされるプロジェクトが最初にデプロイされるプロジェクトを上書きします。

表3-1 Service Busプロジェクトのネーミングの制約

作成するアプリケーションの名前

プロジェクトの名前

Application1

Project1

Application2

Project1

警告:

Service BusアプリケーションでSOA Tierコンポーネントを作成したり、SOA SuiteアプリケーションでService Bus Tierコンポーネントを作成したりしないでください。アプリケーション内でテクノロジが混在すると、エラーが生じます。

3.3.2 Service Busアプリケーションおよびプロジェクトの作成方法

新しいアプリケーションの構築での最初の手順は、そのアプリケーションへの名前の割当てとソース・ファイルを保存するディレクトリの指定です。JDeveloperにより提供されるアプリケーション・テンプレートを使用してアプリケーションを作成することにより、自動的に、プロジェクトにワークスペースが編成され、プロジェクト概要ファイルが生成されます。

Service BusアプリケーションをService Busプロジェクトとともに作成することも、アプリケーションのみを作成し、プロジェクトは別に作成することも可能です。次の図に、アプリケーションおよびプロジェクトを一緒に作成する際の作成ウィザードを示します。

図3-5 「Service BusプロジェクトによるService Busアプリケーションの作成」ウィザード

3.3.2.1 プロジェクトのないService Busアプリケーションの作成

始める前に:

エラーを回避するため、アプリケーションまたはプロジェクトを作成する前に、「アプリケーションおよびプロジェクトの作成ガイドライン」の情報を理解しておいてください。

プロジェクトのないService Busアプリケーションを作成するには:

1. Oracle JDeveloper Studio Editionを起動します。

2. 次のいずれかを実行して、新しいService Busアプリケーションを作成します。

- アプリケーションが開いていない場合は、アプリケーション・ナビゲータで「新規アプリケーション」をクリックします。

- JDeveloperツールバーで、「ファイル」をクリックして、「新規」を指し示し、「アプリケーション」を選択します。

- JDeveloperツールバーで、「アプリケーション」をクリックして、「新規」を選択します。

別のアプリケーション・コンポジットの作成を選択できる「新規ギャラリ」が開きます。

3. 「カテゴリ」ツリーで、「全般」→「アプリケーション」を選択します。

4. 「アイテム」ペインで、「Service Busアプリケーション」を選択し、「OK」をクリックします。

Service Busアプリケーションの作成ウィザードが表示されます。

5. 「アプリケーションの名前付け」ページで、アプリケーションの名前とディレクトリの場所を任意に変更します。

6. 「終了」をクリックします。

7. 「ファイル」メイン・メニューから「すべて保存」を選択します。

8. アプリケーションにプロジェクトを追加するには、"「Service BusプロジェクトをService Busアプリケーションに追加するには:」を参照してください。

3.3.2.2 Service Busアプリケーションおよびプロジェクトの作成

始める前に:

エラーを回避するため、アプリケーションまたはプロジェクトを作成する前に、「アプリケーションおよびプロジェクトの作成ガイドライン」の情報を理解しておいてください。

Service Busアプリケーションおよびプロジェクトを作成するには:

1. Oracle JDeveloper Studio Editionを起動します。

2. 次のいずれかを実行して、新しいService Busアプリケーションを作成します。

- アプリケーションが開いていない場合は、アプリケーション・ナビゲータで「新規アプリケーション」をクリックします。

- JDeveloperツールバーで、「ファイル」をクリックして、「新規」を指し示し、「アプリケーション」を選択します。

- JDeveloperツールバーで、「アプリケーション」をクリックして、「新規」を選択します。

別のアプリケーション・コンポジットの作成を選択できる「新規ギャラリ」が開きます。

3. 「カテゴリ」ツリーで、「全般」→「アプリケーション」を選択します。

4. 「項目」ペインで、「Service BusアプリケーションとService Busプロジェクト」を選択して「OK」をクリックします。

Service Busアプリケーションの作成ウィザードが表示されます。

5. 「アプリケーションの名前付け」ページで、必要に応じてアプリケーションの名前および場所を変更します。

6. 「プロジェクトの名前付け」ページで、必要に応じてService Busプロジェクトの名前を変更します。プロジェクト・ディレクトリがアプリケーション・ディレクトリ(これがデフォルトです)内にあることを確認します。

7. 「終了」をクリックします。

JDeveloperにより、Service Busプロジェクト・テクノロジ、Service Busアプリケーションについて説明するプロジェクトのXMLファイル、および必要なライブラリがプロジェクトに追加されます。

8. 「ファイル」メイン・メニューから「すべて保存」を選択します。

3.3.2.3 Service BusプロジェクトへのService Busアプリケーションの追加

始める前に:

エラーを回避するため、アプリケーションまたはプロジェクトを作成する前に、「アプリケーションおよびプロジェクトの作成ガイドライン」の情報を理解しておいてください。

Service BusプロジェクトをService Busアプリケーションに追加するには:

注意:

次の手順は、初めてService Busプロジェクトを作成する場合の手順です。その後のプロジェクトに対してこれらの手順を引き続き実行できますが、アプリケーション・ナビゲータを右クリックして「新規」を選択してもプロジェクト・オプションが表示されます。

1. Oracle JDeveloper Studio Editionを起動します。

2. 「アプリケーション」メニューを使用して、Service Busアプリケーションを開きます。

3. 「ファイル」をクリックし、「新規」をポイントしてから「プロジェクト」を選択します。

「新規ギャラリ」ダイアログが表示されます。

4. 「カテゴリ」パネルで、「Service Bus層」までスクロールし、これを選択します。

5. 「アイテム」パネルで「Service Busプロジェクト」を選択し、「OK」をクリックします。

Service Busプロジェクトの作成ウィザードが表示されます。

6. 「プロジェクトの名前付け」ページで、必要に応じてService Busプロジェクトの名前を変更できます。ディレクトリをデフォルト値のままにします。これはこのプロジェクトを含むアプリケーションのフォルダ内になります。

7. 「終了」をクリックします。

JDeveloperにより、Service Busプロジェクト・テクノロジ、Service Busアプリケーションについて説明するプロジェクトのXMLファイル、および必要なライブラリがプロジェクトに追加されます。

8. 「ファイル」メイン・メニューから「すべて保存」を選択します。

3.4 Service Busプロジェクト、フォルダおよびリソースのリファクタ

JDeveloperのリファクタ機能を使用して、JDeveloperでService Busリソースの名前変更、移動および削除が可能です。フォルダの名前変更および移動も可能です。リソースまたはフォルダを削除する場合を除き、リファクタでは変更するリソース間の参照を維持します。リファクタではまた、リソース・ファイルの移動、名前変更または削除を行い、Service Bus概要エディタで情報を更新します。JDeveloperのリファクタ機能に加え、Service Busでは、プロジェクトまたはフォルダのクローンを別の場所に作成できます。

リソースの名前変更および削除は、アプリケーション・ナビゲータまたはService Bus概要エディタから行うことができます。この項では、アプリケーション・ナビゲータの手順を説明します。概要エディタでのリファクタについては、「Service Bus概要エディタでのコンポーネントの名前変更方法」および「Service Bus概要エディタでのコンポーネントの削除方法」を参照してください。

3.4.1 JDeveloperでのService Busフォルダまたはリソースの名前変更方法

Service Busコンポーネントの名前を変更すると、すべての参照が自動的に更新されます。

注意:

UDDIレジストリからインポートされたビジネス・サービスの名前を変更すると、そのサービスはレジストリからデタッチされます。

フォルダまたはリソースの名前を変更するには:

1. アプリケーション・ナビゲータで、名前を変更するフォルダまたはリソースを右クリックします。

2. 「リファクタ」をポイントし、「名前変更」をクリックします。

3. リソースの場合、次を実行します。

a. 「名前変更」ダイアログの「変更後の名前」フィールドに、リソースの新しい名前を入力します。ファイル拡張子は変更しないでください。

b. リソースが別のリソースにより参照されている場合は、「使用方法の表示」をクリックしてこれらの参照を確認します。

c. 「OK」をクリックして新しい名前を確定します。

4. フォルダの場合、次を実行します。

a. 「ディレクトリ名の変更」ダイアログの「名前」フィールドに、フォルダのフルパスと新しい名前を入力します。

b. 変更を確定する前にファイルのリストを確認するには、「プレビュー」を選択します。

c. 「OK」をクリックします。

d. 「プレビュー」を選択したら、「ディレクトリ名の変更」ログでファイルのリストを確認します。「リファクタ」をクリックして、変更を完了します。

5. JDeveloperツールバーで「すべて保存」をクリックします。

3.4.2 JDeveloperでのService Busフォルダまたはリソースの移動方法

リソースを別の場所に移動する場合、Service Busでは、そのリソースに対するすべての依存性を保持します。プロジェクトを別のプロジェクトに移動する場合、Service Busでは、これを後者のプロジェクト内のフォルダに変換します。

フォルダまたはリソースを移動するには:

1. アプリケーション・ナビゲータで、移動するプロジェクト、フォルダまたはリソースを右クリックします。

2. 「リファクタ」をポイントし、「移動」をクリックします。

3. リソースの場合、次を実行します。

- リソースが別のリソースにより参照されている場合は、「使用方法の表示」をクリックしてこれらの参照を確認します。

- 「移動」ダイアログの「移動先」フィールドに、リソースの新しいディレクトリ・パスを入力し、「参照」をクリックして新しいディレクトリに移動し、これを選択します。

- 「OK」をクリックします。

4. フォルダの場合、次を実行します。

- 「ディレクトリの移動」ダイアログで、新しいフォルダの場所に移動し、これを選択します。

- 「選択」をクリックします。

5. JDeveloperツールバーで「すべて保存」をクリックします。

3.4.3 プロジェクトまたはリソースの削除方法

プロジェクトを削除すると、そのプロジェクトの下にあるリソースがすべて削除されます。このフォルダの下にあるリソースが別のプロジェクトまたはフォルダの下にあるリソースから参照されている場合、リソースを削除することはできますが、削除されたリソースへの未解決の参照により、競合が発生する場合があります。

警告:

パイプライン・テンプレート・リソースを含むプロジェクトまたはフォルダを削除する場合、そのテンプレートから派生したすべての具象パイプラインはリンク解除されます。

3.4.3.1 リソースの削除

リソースを削除するには:

1. アプリケーション・ナビゲータで、削除するプロジェクト、フォルダまたはリソースを右クリックします。

2. 「リファクタ」をポイントし、「削除」をクリックします。

3. リソースが別のリソースにより参照されている場合は、「使用方法の表示」をクリックしてこれらの参照を確認します。

4. 「はい」をクリックすると、リソースを削除できます。

3.4.3.2 プロジェクトの削除

プロジェクトを削除するには:

1. アプリケーション・ナビゲータで、削除するプロジェクトを右クリックします。

2. 「削除」をクリックします。

3. アプリケーションからプロジェクトのみを削除するのか、ファイル・システムからそのファイルおよびディレクトリもすべて削除するのかを選択します。

4. 「はい」をクリックします。

5. 「確認」ダイアログで、「はい」をクリックします。

3.4.4 プロジェクトまたはフォルダのクローン作成方法

プロジェクトまたはフォルダのクローンを作成すると、プロジェクトまたはフォルダのすべてのリソースが別の場所にコピーされます。Service Busでは、オブジェクトのクローン作成時の依存関係が保持され、すべての参照も調整されます。クローン作成プロセスについては、「プロジェクトのクローン作成時の動作」および「フォルダのクローン作成時の動作」を参照してください。

プロジェクトまたはフォルダのクローンを作成するには:

1. アプリケーション・ナビゲータで、クローンを作成するプロジェクト、フォルダまたはリソースを右クリックします。

2. 「Service Bus」をポイントし、「クローン」をクリックします。

3. 「クローン・ターゲットの選択」ダイアログで、クローン・コンポーネントの名前を入力します。

4. 次のいずれかを行います。

- このプロジェクトまたはフォルダのクローンをプロジェクトとして作成するには、「プロジェクトとして」を選択します。

- プロジェクトまたはフォルダのクローンをフォルダとして作成するには、「場所内のフォルダとして」を選択し、クローン・プロジェクトを配置するプロジェクトまたはフォルダを選択します。

5. 「OK」をクリックします。

4 JDeveloperの開発環境の設定

この章では、Service Busに関連する開発環境の設定(デフォルトのDerbyデータベースの使用やデフォルトのJMSレポート・プロバイダの無効化など)について説明します。

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

- JDeveloperでのサーバー接続の作成

- Oracle JCAアダプタの接続ファクトリの作成

- JMSレポート・プロバイダの無効化

4.1 JDeveloperでのサーバー接続の作成

JDeveloperからサービスをデプロイするには、使用するJDeveloper環境をOracle WebLogic Serverに接続する必要があります。このためには、アプリケーション・サーバー接続を作成します。Oracle Metadata Services (MDS)リポジトリへの接続を作成して、SOA Suiteアプリケーションとアーティファクトを共有することもできます。

- アプリケーション・サーバー接続の作成方法

- SOA-MDS接続の作成方法

- MDSリポジトリの場所の変更方法

4.1.1 アプリケーション・サーバー接続の作成方法

JDeveloperで開発する場合、Service Busアプリケーションがデプロイされるアプリケーション・サーバーへの接続を作成する必要があります。この接続を作成すると、アプリケーションをサーバーにデプロイでき、すでにそのサーバーにデプロイされている他のアプリケーションやアーティファクトにアクセスすることもできます。

手順については、Oracle JDeveloperによるアプリケーションの開発のターゲット・アプリケーション・サーバーへの接続の作成方法に関する項を参照してください。

4.1.2 SOA-MDS接続の作成方法

他のコンポジットとデータを共有するService Busアプリケーションをデプロイするには、「SOA-MDS接続の作成」ウィザードを使用して、データベースに基づくOracle MDSリポジトリ・サーバーへの接続を作成します。

SOA-MDS接続を作成するには:

1. 「ファイル」メイン・メニューから「新規」をポイントし、「ギャラリから」を選択します。

新規ギャラリ・ウィザードが表示されます。

2. 「全般」カテゴリで「接続」を選択します。

3. 「SOA-MDS接続」を選択し、「OK」をクリックします。

「SOA-MDS接続の作成」ダイアログが表示されます。

4. 接続フィールドに、環境に適した値を指定します。

各フィールドおよび入力する必要のある値に関する情報を入手するには、ダイアログの「ヘルプ」をクリックしてください。

5. 「OK」をクリックします。

これで、「リソース」ウィンドウ内の接続を参照し、/appsノードの下の共有アーティファクトを表示できます。

4.1.3 MDSリポジトリの場所の変更方法

デフォルトのMDSリポジトリ接続は、JDeveloperシステムの$JDEV_USER_DIR/soamdsまたはアプリケーション・データ・フォルダにあるデフォルトのリポジトリを使用します。必要に応じて、リポジトリの場所を変更できます。

MDSリポジトリの場所を変更するには:

1. 「リソース」ウィンドウをJDeveloperで表示できない場合、「ウィンドウ」メニューをクリックし、「リソース」を選択します。

2. 「リソース」ウィンドウで、SOA-MDSを展開し、リポジトリ名(デフォルト名はSOA_DesignTimeRepository)を右クリックし、「プロパティ」をクリックします。

「SOA-MDS接続の編集」ダイアログが表示されます。

図4-1 「SOA-MDS接続の編集」ダイアログ

3. 「MDSルート・フォルダ」フィールドで、リポジトリの新しいルート・ディレクトリを選択します。

注意:

任意のディレクトリを選択できますが、appsという名前のフォルダを直下に作成する必要があります。

4. 「接続のテスト」をクリックし、ディレクトリを確認します。

5. テストが正常に完了したら、「OK」をクリックします。

4.2 Oracle JCAアダプタの接続ファクトリの作成

Oracle JCAアダプタは、WebLogic Serverコンテナ内にJCAリソース・アダプタとしてデプロイされます。アダプタは、JAR形式を使用して、リソース・アダプタ・アーカイブ(RAR)ファイルとしてパッケージ化されます。アダプタがデプロイされる際は、RARファイルが使用され、アダプタがコネクタとしてWebLogic Serverまたは中間層プラットフォームに登録されます。RARファイルの内容は次のとおりです。

- ra.xmlファイル。これは、リソース・アダプタに関するデプロイメント固有の情報を含むデプロイメント記述子XMLファイルです。

- Oracle WebLogic Serverとリソース・アダプタ間の規約に関する宣言的な情報

アダプタは、接続ファクトリのエンドポイントを定義するweblogic-ra.xmlテンプレート・ファイルもパッケージ化します。接続ファクトリおよび接続プールの作成については、テクノロジ・アダプタの理解のアダプタ・フレームワークに関する項を参照してください。

4.3 JMSレポート・プロバイダの無効化

デフォルトでは、Service Bus JMSレポート・プロバイダは、Service Busドメインにデプロイされます。レポート・プロバイダは、データベースを使用してレポート・データを永続化します。開発ドメインでJMSレポート・プロバイダを使用しない場合、ドメイン作成プロセス中にJMSレポート・プロバイダを無効化するか割当て解除できます。

詳細は、『Oracle Service Busの管理』のJMSレポート・プロバイダを割当て解除する方法に関する項を参照してください。レポート・プロバイダを無効にすると、サーバーの起動時にJMSレポート・プロバイダの無害なエラーを抑制できます。

5 JDeveloperでのOracle Service Busアプリケーションの開発

この章では、JDeveloperで、Service Bus概要エディタを使用して、トップ・ダウンでService Busアプリケーションを開発する方法について説明します。ここでは、プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合を使用してService Busサービスを作成する基本的な手順と、セキュリティ・ポリシーのアタッチやコンポーネントのテストまたはデバッグなどの最終的な手順を示します。また、トランスポート、JCAアダプタおよびRESTバインディングの概要も示します。

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

- Service Bus概要エディタの概要

- Service Busコンポーネントの追加

- Service Bus概要エディタでのコンポーネントの変更および削除

- 概要ダイアグラムの同期

- Service Busコンポーネントのワイヤリング

- Service Busコンポーネントへのセキュリティ・ポリシーのアタッチ

- 概要エディタでのService Busコンポーネントのテスト

- Service Busアプリケーションのデプロイ

5.1 Service Bus概要エディタの概要

Service Bus概要エディタは、Service Busプロジェクトを設計および構成するためのグラフィカルなインタフェースを提供します。プロジェクトを作成すると、Service Busプロジェクトについて記載されたプロジェクト概要ファイルが自動的に生成されます。アプリケーション・ナビゲータでは、このファイルを表すノードには、そのプロジェクトと同じ名前が付けられます。ファイル・システムでは、これはservicebus.sboverviewという名前になります。このファイルをService Bus概要エディタで開き、Service Busコンポーネントを作成および構成できます。

概要ファイルを開くとService Bus概要エディタが起動されます。これはJDeveloperデザイナにタブとして表示されます。このファイルは、プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合のアプリケーション・アセンブリ全体について説明しています。Service Busプロジェクトごとに1つの概要ファイルがあります。

5.1.1 Service Bus概要エディタのコンポーネント

プロジェクト概要ファイルを操作するとき、主に使用するのは、概要エディタ・キャンバス、「コンポーネント」ウィンドウおよびコンポーネントの構成ウィザードです。エディタでは、WYSIWYG環境で多くのファイルを表示でき、宣言的に変更を行うことのできる概要エディタでファイルを表示したり、そのファイルのソース・コードを表示することが可能です。「構造」ウィンドウには、現在選択されているファイルの構造が示されます。

図5-1 Service Bus概要エディタ

表5-1で、Service Bus概要エディタについて説明します。

表5-1 Service Bus概要エディタ

要素

説明

アプリケーション・ナビゲータ

Service Busプロジェクトに含まれるコンポーネントの主要なファイルを表示します。

- project_nameノード(servicebus.sboverviewファイル)。Service Busプロジェクトの作成時に自動的に作成されます。このファイルは、プロキシ・サービス、ビジネス・サービス、パイプライン、分割-結合およびワイヤのコンポジット・アセンブリ全体について説明しています。Service Bus概要エディタでファイルを開くと、名前がそれを含むプロジェクトの名前に一致するように変更されます。

- パイプライン・コンポーネント・ファイル(pipeline_name.pipeline)

- プロキシ・サービス・コンポーネント・ファイル(proxy_name.proxy)

- ビジネス・サービス・コンポーネント・ファイル(business_name.bix)

- 分割-結合コンポーネント・ファイル(splitjoin_name.flow)

- アラート宛先、サービス・キー・プロバイダ、サービス・アカウントなど、Service Busコンポーネントについて説明する個々のファイル。

- クラス・ファイル、WSDLファイル、スキーマ定義、変換およびテスト・スイートのオプション・サブフォルダ。これらは、直接プロジェクトの下に作成することもできます。デフォルトで、アダプタ・ウィザードにより生成されるコンポーネントは、Resourcesという名前のサブフォルダに作成されます。

「構造」ウィンドウ

「構造」ウィンドウでは、アクティブ・ウィンドウで現在選択されているドキュメント内のデータの構造ビューを提供します。

概要エディタ

Service Busコンポーネントを、「コンポーネント」ウィンドウから概要エディタのキャンバスにドラッグします。デザイナにコンポーネントをドラッグ・アンド・ドロップすると、対応するウィザードが表示され、そのコンポーネントを作成および構成できます。

後続のすべての編集セッションでは、これらのコンポーネントをダブルクリックすると、そのエディタが再度開きます。

中央スイムレーン(パイプライン/分割-結合)

中央スイムレーンは、ルーティング・ロジックおよび変換ロジックを提供するコンポーネント用で、パイプラインおよび分割-結合に限定されます。

左スイムレーン(プロキシ・サービス)

左スイムレーンは、アプリケーションへのエントリ・ポイントを提供するサービス用で、プロキシ・サービスに限定されます。このレーンにJCAアダプタまたはトランスポートをドラッグすると、選択したアダプタまたはトランスポートに基づいてプロキシ・サービスが生成されます。

右スイムレーン(外部サービス)

右スイムレーンは、外部環境にある外部サービスにメッセージを送信する参照用で、ビジネス・サービスまたはプロキシ・サービスが該当します。このレーンにJCAアダプタまたはトランスポートをドラッグすると、ビジネス・サービスが生成されます。

このレーンに表示されるプロキシ・サービスは、実際には既存のプロキシ・サービスへの参照であり、JCAアダプタまたはトランスポートをキャンバスにドラッグすることにより、これらを追加することはできません。これらは、使用する既存のプロキシ・サービスを選択することによってのみ、追加できます。

「コンポーネント」ウィンドウ

「コンポーネント」ウィンドウでは、Service Busアプリケーションで使用できる様々なService Busコンポーネントを提供します。これには、パイプライン、分割-結合、テクノロジ・アダプタ、アプリケーション・アダプタ、トランスポートおよびRESTバインディングが含まれます。プロキシ・サービスおよびビジネス・サービスは「コンポーネント」ウィンドウには含まれませんが、これらは、アダプタ、トランスポートまたはバインディングをキャンバスの左または右スイムレーンにドラッグすることにより作成できます。

使用可能なコンポーネントの詳細は、JDeveloperの概要エディタのオンライン・ヘルプを参照してください。「コンポーネント」ウィンドウが表示されていない場合は、「表示」メイン・メニューから「コンポーネント」を選択します。

「リソース」ウィンドウ

「リソース」ウィンドウには、1つのダイアログが用意されており、ここからローカルなリソースとリモートのリソースの両方を参照できます。たとえば、次のリソースにアクセスできます。

- 共有ローカル・アプリケーション・メタデータ(スキーマ、WSDLドキュメント、イベント定義など)。

- HTTP接続、ファイルURLまたはアプリケーション・サーバー接続を介してアクセスできるリモート・リソースを使用するWSILブラウザ機能。

- Universal Description, Discovery, and Integration (UDDI)レジストリに登録されるリモート・リソース。

「リソース・ブラウザ」ダイアログを介してService Busアプリケーションのこれらのリソースを選択します。このダイアログには、様々な方法でアクセスできます。たとえば、パイプラインで使用するWSDLファイルを選択したり、「コンポーネント」ウィンドウからビジネス・サービスをドラッグすると、「リソース・ブラウザ」ダイアログが表示されます。このダイアログの上部の「リソース」をクリックし、使用可能なリソースにアクセスします。

「リソース」ウィンドウが表示されていない場合は、「表示」メイン・メニューから「リソース」を選択します。

「ログ」ウィンドウ

「ログ」ウィンドウには、アプリケーションのコンパイル、検証およびデプロイメントに関するメッセージが表示されます。

「プロパティ」ウィンドウ

「プロパティ」ウィンドウには、選択したService Busコンポーネントのプロパティが表示されます。「プロパティ」ウィンドウを使用すると、パイプラインおよび分割-結合アクションのプロパティを定義することもできます。

「プロパティ」ウィンドウが表示されていない場合は、「表示」メイン・メニューから「プロパティ」を選択します。

アプリケーション・リソース

「アプリケーション・リソース」パネルでは、「Service Busシステム・リソース」の下に、Service Busアプリケーションおよびプロジェクトのシステム・リソースがリストされます。システム・リソースには、UDDIレジストリ、プロキシ・サービス、JNDIプロバイダ、SNMPサーバーなどが含まれます。

5.1.2 トランスポート、アダプタおよびバインディング

Service Bus概要エディタを使用すると、Service Busトランスポート、Oracle JCAアダプタまたはRESTバインディングに基づき、プロキシ・サービスおよびビジネス・サービスを作成できます。Service BusはJCAアダプタと完全に統合されているため、概要エディタを使用して、JCAアダプタとそれに関連付けられたファイルをService Busプロジェクトに直接作成して構成できます。以前のバージョンでは、JCAアダプタを個々のSOA Suiteプロジェクトに作成してから、そのアダプタをService Busにインポートしていました。JCAアダプタを作成すると、具体的なWSDLファイルとプロキシ・サービスまたはビジネス・サービスが自動的に作成されます。RESTバインディングを使用してサービスを作成する場合も同様になります。つまり、関連付けられたWADLファイルとプロキシ・サービスまたはビジネス・サービスが自動的に作成されます。

Service Busでは、Oracle JCAアダプタを完全にサポートする以外に、各種トランスポートを介して外部システムへの接続が提供されます。それぞれのトランスポートは、外部システムのタイプに固有です。トランスポート、アダプタおよびRESTバインディングを組み合せてService Busにサービスを作成できます。

表5-2、表5-3および表5-4では、「コンポーネント」ウィンドウで利用可能なトランスポート、アダプタおよびバインディングについて説明します。詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください。

表5-2 テクノロジ・コンポーネント

コンポーネント

説明

AQ

AQアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracle AQアダプタを作成して構成し、その関連するサービスを作成します。AQアダプタを使用すると、Service Busは、単一コンシューマまたは複数コンシューマのキューと相互作用できます。

このアクションにより、「AQアダプタ構成ウィザード」が起動します。

AS/400

AS/400アダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、AS/400のOracle Databaseアダプタを作成して構成し、その関連するサービスを作成します。

このアクションにより、Databaseアダプタ構成ウィザードが起動します。

BAM

BAMアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracle BAMアダプタを作成して構成し、その関連するサービスを作成します。BAMアダプタを使用すると、Service Busは、Oracle Business Activity Monitoringと相互作用できます。

このアクションにより、「BAMアダプタ構成ウィザード」が起動します。

コヒーレンス

Coherenceアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracle Coherenceリソース・アダプタを作成して構成し、その関連するサービスを作成します。Coherenceリソース・アダプタを使用して、トランザクションでキャッシュ操作を実行します。

このアクションにより、「コヒーレンス・アダプタ構成ウィザード」が起動します。

データベース

Databaseアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Database JCAアダプタを作成して構成し、その関連するサービスを作成します。Databaseアダプタを使用すると、Service Busは、JDBCを介してOracleおよびその他のデータベースと通信できます。

このアクションにより、Databaseアダプタ構成ウィザードが起動します。

直接

Directトランスポートを「外部サービス」スイムレーンにドラッグして、SOA-DIRECTトランスポートを使用してビジネス・サービスを作成します。SOA DIRECTトランスポートを使用して、リモート・メソッド呼出し(remote method invocation: RMI)でメッセージをやり取りします。

このアクションにより、「ビジネス・サービスの作成」ウィザードが起動します。Directトランスポートは、ビジネス・サービスでのみ使用できます。

ファイル

ファイル・アダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracleファイル・アダプタを作成して構成し、その関連するサービスを作成します。ファイル・アダプタを使用すると、Service Busアプリケーションで、ローカル・ファイル・システムのファイルからのメッセージの読み書きが可能です。

このアクションにより、「ファイル・アダプタ構成ウィザード」が起動します。

FTP

FTPアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracle FTPアダプタを作成して構成し、その関連するサービスを作成します。FTPアダプタを使用すると、Service Busアプリケーションで、リモート・サービス・ファイルからのメッセージの読み書きが可能です。

このアクションにより、「FTPアダプタ構成ウィザード」が起動します。

HTTP

HTTPトランスポートを「プロキシ・サービス」スイムレーンにドラッグしてHTTPプロキシ・サービスを作成するか、「外部サービス」スイムレーンにドラッグしてHTTPビジネス・サービスを作成します。HTTPトランスポートを使用すると、HTTP POST操作およびGET操作でアプリケーションを起動できます。

このアクションにより、「プロキシ・サービスの作成」または「ビジネス・サービスの作成」ウィザードが起動します。

JEJB

JEJBトランスポートを「プロキシ・サービス」スイムレーンにドラッグしてJEJBプロキシ・サービスを作成するか、「外部サービス」スイムレーンにドラッグしてJEJBビジネス・サービスを作成します。JEJBトランスポートを使用すると、Service Busを介してPlain Old Java Object (POJO)を渡すことができます。

このアクションにより、「プロキシ・サービスの作成」または「ビジネス・サービスの作成」ウィザードが起動します。

JMS

JMSトランスポートを「プロキシ・サービス」スイムレーンにドラッグしてJMSプロキシ・サービスを作成するか、「外部サービス」スイムレーンにドラッグしてJMSビジネス・サービスを作成します。JMSトランスポートでは、Java Messaging Serviceと相互作用するサービスを構成します。

このアクションにより、「プロキシ・サービスの作成」または「ビジネス・サービスの作成」ウィザードが起動します。

LDAP

LDAPアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracle LDAPアダプタを作成して構成し、その関連するサービスを作成します。LDAPアダプタを使用すると、Service BusはLDAPディレクトリと相互作用できます。

このアクションにより、「LDAPアダプタ構成ウィザード」が起動します。

MQ

MQアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracle MQ Seriesアダプタを作成して構成し、その関連するサービスを作成します。MQ Seriesアダプタを使用すると、Service BusはMQ Seriesキュー・マネージャと接続して、キュー内のメッセージを追加および削除できます。

このアクションにより、「MQ Seriesアダプタ構成ウィザード」が起動します。

MSMQ

MSMQアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracle MSMQアダプタを作成して構成し、その関連するサービスを作成します。

このアクションにより、「MSMQアダプタ構成ウィザード」が起動します。

REST

RESTバインディングを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、RESTバインディング・コンポーネントを作成して構成し、その関連するサービスを作成します。

このアクションにより、「RESTバインディングの作成」ダイアログが起動します。

SB

SBトランスポートを「プロキシ・サービス」スイムレーンにドラッグしてSBプロキシ・サービスを作成するか、「外部サービス」スイムレーンにドラッグしてSBビジネス・サービスを作成します。SBトランスポートによって、Oracle製品でRMIを使用してプロキシ・サービスを同期的に呼び出すことができます。

このアクションにより、「プロキシ・サービスの作成」または「ビジネス・サービスの作成」ウィザードが起動します。

Socket

ソケット・アダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracleソケット・アダプタを作成して構成し、その関連するサービスを作成します。Oracleソケット・アダプタを使用すると、Service Busでクライアントやサーバー・ソケットを作成し、接続を確立できます。

このアクションにより、「SOCKETアダプタ構成ウィザード」が起動します。

Tuxedo

Tuxedoトランスポートを「プロキシ・サービス」スイムレーンにドラッグしてTuxedoプロキシ・サービスを作成するか、「外部サービス」スイムレーンにドラッグしてTuxedoビジネス・サービスを作成します。Tuxedoトランスポートを使用すると、Service BusからTuxedoドメインにアクセスできます。

このアクションにより、「プロキシ・サービスの作成」または「ビジネス・サービスの作成」ウィザードが起動します。

UMS

UMSアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracle UMSアダプタを作成して構成し、その関連するサービスを作成します。Oracle UMSアダプタを使用すると、Service Busで、電子メール、SMSまたはインスタント・メッセージを使用して通知を送受信できます。

このアクションにより、「UMSアダプタ構成ウィザード」が起動します。

WS

WSトランスポートを「プロキシ・サービス」スイムレーンにドラッグしてWSプロキシ・サービスを作成するか、「外部サービス」スイムレーンにドラッグしてWSビジネス・サービスを作成します。WSトランスポートでは、WSRMポリシーを使用するSOAP 1.1またはSOAP 1.2ベースのWSDLドキュメントから派生したサービスのリクエストが実装されています。

このアクションにより、「プロキシ・サービスの作成」または「ビジネス・サービスの作成」ウィザードが起動します。

表5-3 アプリケーション・コンポーネント

コンポーネント

説明

JDE World

JDE Worldアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracle JDE Worldアダプタを作成して構成し、その関連するサービスを作成します。このアクションにより、JDE Worldアダプタ構成ウィザードが起動します。

Oracle

Oracleアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracle Applicationsアダプタを作成して構成し、その関連するサービスを作成します。このアクションにより、「Oracle Applicationsアダプタ構成ウィザード」が起動します。

SAP

SAPアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracle SAPアダプタを作成して構成し、その関連するサービスを作成します。このアクションにより、Oracle SAPアダプタ構成ウィザードが起動します。

表5-4 拡張コンポーネント

コンポーネント

説明

BPEL 10g

BPEL 10gトランスポートを「外部サービス」スイムレーンにドラッグしてBPEL Process Managerビジネス・サービスを作成します。BPEL Processing Manager (BPEL-10g)を使用して、メッセージングをOracle SOA Suite 10g BPELプロセスで定義します。

このアクションにより、「ビジネス・サービスの作成」ウィザードが起動します。BPEL 10gトランスポートは、ビジネス・サービスでのみ使用できます。

注意: Oracle SOA Suite 11g BPELプロセスのメッセージングの場合、SOA_DIRECTトランスポートを使用します。

カスタム

カスタム・アダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracleカスタム・アダプタを作成して構成し、その関連するサービスを作成します。Oracleカスタム・アダプタを使用すると、外部システムに接続する、カスタマイズされたアダプタを作成できます。

このアクションにより、カスタム・アダプタ構成ウィザードが起動します。

DSP

DSPトランスポートを「外部サービス」スイムレーンにドラッグしてDSPビジネス・サービスを作成します。DSPトランスポートを使用して、Oracle Data Service Integratorと通信します。

このアクションにより、「ビジネス・サービスの作成」ウィザードが起動します。DSPトランスポートは、ビジネス・サービスでのみ使用できます。

EJB

EJBトランスポートを「外部サービス」スイムレーンにドラッグしてEJBビジネス・サービスを作成します。EJBトランスポートによって、Enterprise JavaBeansでSDOパラメータまたはJavaインタフェースを使用するためのEnterprise JavaBeansサービスを作成します。

このアクションにより、「ビジネス・サービスの作成」ウィザードが起動します。EJBトランスポートは、ビジネス・サービスでのみ使用できます。

電子メール

電子メール・トランスポートを「プロキシ・サービス」スイムレーンにドラッグして電子メール・プロキシ・サービスを作成するか、「外部サービス」スイムレーンにドラッグして電子メール・ビジネス・サービスを作成します。電子メール・アダプタを使用すると、Service Busは電子メール・サーバーと通信できます。

このアクションにより、「プロキシ・サービスの作成」または「ビジネス・サービスの作成」ウィザードが起動します。

ファイル・トランスポート

ファイル・トランスポートを「プロキシ・サービス」スイムレーンにドラッグしてファイル・プロキシ・サービスを作成するか、「外部サービス」スイムレーンにドラッグしてファイル・ビジネス・サービスを作成します。ファイル・トランスポートでは、ローカル・ファイル・システムのファイルからメッセージの読み書きを行うサービスを構成します。

このアクションにより、「プロキシ・サービスの作成」または「ビジネス・サービスの作成」ウィザードが起動します。

FTPトランスポート

FTPトランスポートを「プロキシ・サービス」スイムレーンにドラッグしてFTPプロキシ・サービスを作成するか、「外部サービス」スイムレーンにドラッグしてFTPビジネス・サービスを作成します。FTPトランスポートでは、リモート・サービス・ファイルからメッセージの読み書きを行うサービスを構成します。

このアクションにより、「プロキシ・サービスの作成」または「ビジネス・サービスの作成」ウィザードが起動します。

JCA

JCAトランスポートを「プロキシ・サービス」スイムレーンにドラッグして、既存のJCAアダプタに基づきプロキシ・サービスを作成するか、「外部サービス」スイムレーンにドラッグして、既存のJCAアダプタに基づきビジネス・サービスを作成します。

このアクションにより、「プロキシ・サービスの作成」または「ビジネス・サービスの作成」ウィザードが起動します。

JMS

JMSアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracle JMSアダプタを作成して構成し、その関連するサービスを作成します。JMSアダプタを使用すると、Service BusはJava Messaging Serviceと相互作用できます。

このアクションにより、「JMSアダプタ構成ウィザード」が起動します。

ローカル

ローカル・トランスポートを「プロキシ・サービス」スイムレーンにドラッグしてローカル・プロキシ・サービスを作成します。ローカル・プロキシ・サービスは、その他のプロキシ・サービスからのみ呼び出すことができ、外部のクライアントからは呼び出せません。

このアクションにより、「プロキシ・サービスの作成」ウィザードが起動します。ローカル・トランスポートは、プロキシ・サービスでのみ使用できます。

MQトランスポート

MQトランスポートを「プロキシ・サービス」スイムレーンにドラッグしてMQプロキシ・サービスを作成するか、「外部サービス」スイムレーンにドラッグしてMQビジネス・サービスを作成します。MQトランスポートにより、IBM WebSphere MQへのアクセスが提供されます。

このアクションにより、「プロキシ・サービスの作成」または「ビジネス・サービスの作成」ウィザードが起動します。

SFTP

SFTPトランスポートを「プロキシ・サービス」スイムレーンにドラッグしてSFTPプロキシ・サービスを作成するか、「外部サービス」スイムレーンにドラッグしてSFTPビジネス・サービスを作成します。SFTPトランスポートを使用すると、SSHファイル・トランスポート・プロトコル(SSH File Transfer Protocol: SFTP)でファイルを安全に転送できます。

このアクションにより、「プロキシ・サービスの作成」または「ビジネス・サービスの作成」ウィザードが起動します。

サード・パーティ

サード・パーティ・アダプタを「プロキシ・サービス」または「外部サービス」スイムレーンのいずれかにドラッグして、Oracleサード・パーティ・アダプタを作成して構成し、その関連するサービスを作成します。サード・パーティ・アダプタを使用すると、WSDLドキュメントがすでに定義されている場合、Service Busはサード・パーティのサービスと相互作用できます。

このアクションにより、「サード・パーティ・アダプタ・サービスの作成」ダイアログが起動します。

5.1.3 プロジェクトと概要ダイアグラムの同期

概要エディタの外部で特定のタスクを実行すると、Service Bus概要エディタ・ダイアグラムで自動的にコンポーネントが追加または変更されます。Service Bus概要エディタ外でプロキシ・サービス、パイプラインおよび分割-結合を作成すると(つまり、これらを作成ウィザードを使用してプロジェクト内で直接作成すると)、Service Busは、概要エディタ・ダイアグラムに生成されたコンポーネントを追加します。ビジネス・サービスを追加する場合にはこのようにはなりません。これは、ビジネス・サービスの場合、複数のプロジェクトにより使用される可能性があるためです。

新しいアウトバウンド・メッセージングまたはコールアウト・アクティビティをパイプラインまたは分割-結合に追加し、外部サービスをコールするようにアクティビティを構成すると、参照されるコンポーネントが概要ダイアグラムの「外部サービス」スイムレーンにまだ存在しない場合、Service Busはそのコンポーネントをこの場所に追加します。Service Busでは、パイプラインまたは分割-結合の参照されるコンポーネントへのワイヤリングも行います。外部サービスへの呼出しを削除すると、ワイヤも削除されます。プロキシ・サービス定義エディタでターゲット・サービスを追加、削除または変更すると、Service Busでは、それに従って概要ダイアグラムのワイヤが変更されます。

新しいService Busプロジェクトをインポートすると、Service Busはプロジェクト概要ファイルを生成し、Service Bus概要エディタのダイアグラムに導出可能なすべてのService Busコンポーネントを追加します。インポートにより既存のService Busプロジェクトが更新されると、概要ダイアグラムも新しいコンポーネントまたは更新されたワイヤリングで更新されます。

リソースを変更またはインポートすると、概要は同期されます。リソースを追加、更新または削除すると、次にそのリソースをリフレッシュするか開いたときに、その変更がService Bus概要エディタに表示されます。

5.2 Service Busコンポーネントの追加

Service Busアプリケーションおよびプロジェクトを作成したら、次に、アプリケーションのビジネス・ロジックまたは処理ルールを実装するService Busコンポーネントを追加します。Service Bus概要エディタの「コンポーネント」ウィンドウを使用して、概要エディタにコンポーネントをドラッグ・アンド・ドロップできます。Service Busコンポーネントをエディタにドラッグすると、対応する作成ウィザードが起動され、ここで、コンポーネントや、WSDLファイルおよびスキーマ定義などの関連リソースを作成できます。コンポーネントは、いずれかのスイムレーンを右クリックして、そのレーンで使用可能なオプションから選択することでも作成できます。コンポーネントを作成すると、対応するファイルがプロジェクトのディレクトリ構造に生成され、アプリケーション・ナビゲータに表示されます。

5.2.1 Service Bus概要エディタの起動方法

概要エディタには、servicebus.sboverviewファイルがグラフィカルに表示されます。アプリケーション・ナビゲータでは、このファイルはプロジェクトと同じ名前を持つノードで表されます。

注意:

概要エディタを開くと、Service Busは常にプロジェクト・コンポーネントの現在の状態にダイアグラムを同期させるように試みます。

プロジェクトの概要を開くには:

- 次のいずれかを行います:

- Service Busプロジェクト内の、プロジェクトと同じ名前のノードをダブルクリックします。

- Service Busプロジェクト内の、プロジェクトと同じ名前のノードを右クリックして、「開く」を選択します。

5.2.2 パイプラインの追加方法

パイプラインを追加して、プロジェクトのメッセージ・フローとデータ変換、エラー処理および検証を定義します。新しいパイプラインを作成すると、パイプライン構成からプロキシ・サービスを生成するオプションが追加されます。

パイプラインを追加するには:

1. 「コンポーネント」ウィンドウから、「Service Bus」を選択します。

2. 「リソース」リストからデザイナの「パイプライン/分割結合」レーンにパイプラインをドラッグします。

「パイプライン・サービスの作成」ウィザードが表示されます。

3. パイプラインの設定を構成します。

構成フィールドについては、「ヘルプ」をクリックするか、[F1]キーを押してください。パイプラインの作成の詳細は、「Oracle JDeveloperでのパイプラインの操作」を参照してください。

4. プロキシ・サービスを生成してパイプラインと関連付けるには、ウィザードの「タイプ」ページで「プロキシ・サービスとして公開」をクリックします。プロキシ・サービスのトランスポートを選択し、必要に応じて名前を変更します。

5. ウィザードの最後のページで、「終了」をクリックします。

パイプライン・ファイルがプロジェクトに追加され、デザイナの「パイプライン/分割結合」セクションにパイプラインが表示されます。プロキシ・サービスとしてパイプラインを公開すると、プロキシ・サービスも「プロキシ・サービス」スイムレーンに表示され、コンポーネントが自動的にワイヤリングされます。

6. パイプラインでメッセージ・フローを定義するには、「Oracle JDeveloperでのパイプライン・アクションの操作」を参照してください。

7. JDeveloperのツールバーで「すべて保存」をクリックします。

5.2.3 分割-結合の追加方法

分割-結合を追加して、同時処理を実行するメッセージ・フローを定義し、サービス・パフォーマンスを向上させます。分割-結合では、データ変換、検証、エラー処理およびレポートを定義することもできます。新しい分割-結合を作成すると、分割-結合構成からプロキシ・サービスを生成するオプションが追加されます。

分割-結合を追加するには:

1. 「コンポーネント」ウィンドウから、「Service Bus」を選択します。

2. 「リソース」リストからデザイナの「パイプライン/分割結合」レーンに分割結合をドラッグします。

「分割-結合サービスの作成」ウィザードが表示されます。

3. 分割-結合の設定を構成します。

構成フィールドについては、「ヘルプ」をクリックするか、[F1]キーを押してください。分割-結合の作成の詳細は、「JDeveloperでの分割-結合の作成方法」を参照してください。

4. プロキシ・サービスを生成して分割-結合と関連付けるには、ウィザードの「タイプ」ページで「プロキシ・サービスとして公開」をクリックします。プロキシ・サービスのトランスポートを選択し、必要に応じて名前を変更します。

5. ウィザードの最後のページで、「終了」をクリックします。

分割-結合ファイルがプロジェクトに追加され、デザイナの「パイプライン/分割結合」セクションに分割-結合が表示されます。プロキシ・サービスとして分割-結合を公開すると、プロキシ・サービスも「プロキシ・サービス」スイムレーンに表示され、コンポーネントが自動的にワイヤリングされます。

6. 分割-結合でメッセージ・フローを定義するには、「分割-結合によるサービスのパフォーマンスの向上」を参照してください。

7. JDeveloperのツールバーで「すべて保存」をクリックします。

5.2.4 プロキシ・サービスの作成方法

プロキシ・サービスは、Service Busアプリケーションへのデータのエントリ・ポイントです。Service Bus概要エディタを使用してプロキシ・サービスを作成する方法はいくつかあります。

- アダプタまたはトランスポートを「コンポーネント」ウィンドウから「プロキシ・サービス」レーンにドラッグします。アダプタおよびトランスポートは、「コンポーネント」ウィンドウの「テクノロジ」、「アプリケーション」および「詳細」の下にあります。

- パイプラインまたは分割-結合を作成したら、これをプロキシ・サービスとして公開します。これにより、パイプラインまたは分割-結合、プロキシ・サービス、およびそれら2つの間の接続ワイヤが作成されます。詳細は、「パイプラインの追加方法」および「分割-結合の追加方法」を参照してください。

- パイプラインまたは分割-結合を作成したら、入力アンカーを「プロキシ・サービス」スイムレーンにドラッグし、新しいプロキシ・サービスを作成します。

5.2.4.1 アダプタを使用したプロキシ・サービスの作成

JCAアダプタを使用してプロキシ・サービスを作成すると、Service Busでは、具象WSDLファイルがJCAベースのプロキシ・サービスとともに生成されます。JCAアダプタ用に生成されるWSDLファイルは抽象的です。具象WSDLファイルには、ファイル名にconcreteというテキストが付加されています。

アダプタを使用してプロキシ・サービスを作成するには:

1. 次のいずれかを行います。

- 「プロキシ・サービス」スイムレーンで右クリックし、「アダプタの挿入」をポイントして、オプションのリストから使用するアダプタを選択します。

- 「コンポーネント」ウィンドウから、「Service Bus」を選択し、アダプタを「プロキシ・サービス」レーンにドラッグします。

ヒント:

アダプタは、「コンポーネント」ウィンドウの「テクノロジ」セクションにある一意のアイコンで指定されます。

選択したアダプタの作成ウィザードが表示されます。

2. アダプタの設定を構成します。

構成フィールドについては、「ヘルプ」をクリックするか、[F1]キーを押してください。アダプタの構成方法の詳細は、テクノロジ・アダプタの理解のOracle JCAアダプタの汎用プロパティに関する項を参照してください。

3. ウィザードの最後のページで、「終了」をクリックします。

プロキシ・サービス、アダプタおよび関連付けられたWSDLファイルがプロジェクトに追加され、プロキシ・サービスがデザイナの「プロキシ・サービス」セクションに表示されます。JCAアダプタに対してプロキシ・サービスが構成され、使用されるJCAアダプタのタイプに基づいて名前が付けられます。

4. プロキシ・サービスを構成するには、「プロキシ・サービスの構成」および「JCAトランスポートとJCAアダプタの使用」を参照してください。

5. JDeveloperのツールバーで「すべて保存」をクリックします。

5.2.4.2 トランスポートを使用したプロキシ・サービスの作成

トランスポートを使用してプロキシ・サービスを作成するには:

1. 次のいずれかを行います。

- 「プロキシ・サービス」スイムレーンで右クリックし、「トランスポートの挿入」をポイントして、オプションのリストから使用するトランスポートを選択します。

- 「コンポーネント」ウィンドウから「Service Bus」を選択し、トランスポートを「プロキシ・サービス」レーンにドラッグします。

ヒント:

トランスポートは、「コンポーネント」ウィンドウの「テクノロジ」セクションおよび「詳細」セクションにあるプレーン・ギア・アイコンで指定されます。

「プロキシ・サービスの作成」ウィザードが表示されます。

2. プロキシ・サービスの設定を構成します。

構成フィールドについては、「ヘルプ」をクリックするか、[F1]キーを押してください。プロキシ・サービスの作成の詳細は、「プロキシ・サービスの作成方法」を参照してください。

3. ウィザードの最後のページで、「終了」をクリックします。

プロキシ・サービス・ファイルがプロジェクトに追加され、プロキシ・サービスがデザイナの「プロキシ・サービス」セクションに表示されます。

4. プロキシ・サービスおよびトランスポートを構成するには、「プロキシ・サービスの構成」および「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください

5. JDeveloperのツールバーで「すべて保存」をクリックします。

5.2.4.3 既存のパイプラインまたは分割-結合からのプロキシ・サービスの作成

既存のパイプラインまたは分割-結合からプロキシ・サービスを作成するには:

1. パイプラインまたは分割-結合の左アンカーをクリックし、これを「プロキシ・サービス」スイムレーンにドラッグします。

「プロキシ・サービスの作成」ウィザードが表示されます。

2. プロキシ・サービスの設定を構成します。

構成フィールドについては、「ヘルプ」をクリックするか、[F1]キーを押してください。プロキシ・サービスの作成の詳細は、「プロキシ・サービスの作成方法」を参照してください。

3. ウィザードの最後のページで、「終了」をクリックします。

プロキシ・サービス・ファイルがプロジェクトに追加され、プロキシ・サービスがデザイナの「プロキシ・サービス」セクションに表示されます。

4. プロキシ・サービスおよびトランスポートを構成するには、「プロキシ・サービスの構成」および「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください

5. JDeveloperのツールバーで「すべて保存」をクリックします。

5.2.5 概要での既存のプロキシ・サービスの再利用方法

プロキシ・サービスは、Service Busアプリケーションのパイプラインまたは分割-結合から外部サービスとしてコールできます。「外部サービス」コンテキスト・メニューから、または既存のパイプラインや分割-結合から、参照するプロキシ・サービスを追加できます。参照するプロキシ・サービスは、すでに現在のアプリケーションに作成されている必要があります。通常、プロキシ・サービスは参照されるため、そのロジックは公開されず、一般的にはローカル・トランスポートを使用します。

既存のプロキシ・サービスを参照として追加するには:

1. 次のいずれかを行います。

- 「外部サービス」スイムレーンで右クリックし、「選択」をポイントして、「プロキシ・サービス」を選択します。
「プロキシ・サービスの選択」ダイアログが表示されます。

- パイプラインまたは分割-結合の右アンカーをクリックし、これを「外部サービス」スイムレーンにドラッグします。
「リソース・チューザ」ダイアログが表示されます。

2. プロジェクトのリストで、プロジェクトおよび使用するプロキシ・サービスを含むフォルダを開きます。

3. 使用するプロキシ・サービスを選択し、「終了」をクリックします。

4. JDeveloperのツールバーで「すべて保存」をクリックします。

5.2.6 ビジネス・サービスの作成方法

ビジネス・サービスでは、データを共有する外部システムと通信を行います。ビジネス・サービスは、アダプタまたはトランスポートを「コンポーネント」ウィンドウから「外部サービス」レーンにドラッグすることにより作成できます。アダプタおよびトランスポートは、「コンポーネント」ウィンドウの「テクノロジ」、「アプリケーション」および「詳細」の下にあります。

5.2.6.1 アダプタを使用したビジネス・サービスの作成

JCAアダプタを使用してビジネス・サービスを作成すると、Service Busでは、具象WSDLファイルがビジネス・サービスとともに生成されます。JCAアダプタ用に生成されるWSDLファイルは抽象的です。具象WSDLファイルには、ファイル名にconcreteというテキストが付加されています。

アダプタを使用してビジネス・サービスを作成するには:

1. 次のいずれかを行います。

- 「外部サービス」スイムレーンで右クリックし、「アダプタの挿入」をポイントして、オプションのリストから使用するアダプタを選択します。

- 「コンポーネント」ウィンドウから「Service Bus」を選択し、アダプタをデザイナの「外部サービス」レーンにドラッグします。

ヒント:

アダプタは、「コンポーネント」ウィンドウの「テクノロジ」セクションにある一意のアイコンで指定されます。

選択したアダプタの作成ウィザードが表示されます。

2. アダプタの設定を構成します。

構成フィールドについては、「ヘルプ」をクリックするか、[F1]キーを押してください。アダプタの構成方法の詳細は、テクノロジ・アダプタの理解のOracle JCAアダプタの汎用プロパティに関する項を参照してください。

3. ウィザードの最後のページで、「終了」をクリックします。

ビジネス・サービス、アダプタおよび関連付けられたWSDLファイルがプロジェクトに追加され、ビジネス・サービスがデザイナの「外部サービス」セクションに表示されます。JCAアダプタに対してビジネス・サービスが構成され、使用されるJCAアダプタのタイプに基づいて名前が付けられます。

4. ビジネス・サービスを構成するには、「ビジネス・サービスの構成」および「JCAトランスポートとJCAアダプタの使用」を参照してください。

5. JDeveloperのツールバーで「すべて保存」をクリックします。

5.2.6.2 トランスポートを使用したビジネス・サービスの作成

トランスポートを使用してビジネス・サービスを作成するには:

1. 次のいずれかを行います。

- 「外部サービス」スイムレーンで右クリックし、「トランスポートの挿入」をポイントして、オプションのリストから使用するトランスポートを選択します。

- 「コンポーネント」ウィンドウから「Service Bus」を選択し、トランスポートをデザイナの「外部サービス」レーンにドラッグします。

ヒント:

トランスポートは、「コンポーネント」ウィンドウの「テクノロジ」セクションおよび「詳細」セクションにあるプレーン・ギア・アイコンで指定されます。

「ビジネス・サービスの作成」ウィザードが表示されます。

2. ビジネス・サービスの設定を構成します。

構成フィールドについては、「ヘルプ」をクリックするか、[F1]キーを押してください。ビジネス・サービスの作成の詳細は、「ビジネス・サービスの作成方法」を参照してください。

3. ウィザードの最後のページで、「終了」をクリックします。

ビジネス・サービス・ファイルがプロジェクトに追加され、ビジネス・サービスがデザイナの「外部サービス」セクションに表示されます。

4. ビジネス・サービスおよびトランスポートを構成するには、「ビジネス・サービスの構成」および「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください

5. JDeveloperのツールバーで「すべて保存」をクリックします。

5.2.7 概要での既存のビジネス・サービスの再利用方法

使用するビジネス・サービスがすでにプロジェクトに存在している場合は、概要エディタからそのビジネス・サービスを参照できます。「外部サービス」コンテキスト・メニューから、または既存のパイプラインや分割-結合からビジネス・サービスを追加できます。ビジネス・サービスは、すでに現在のアプリケーションに作成されている必要があります。

既存のビジネス・サービスを概要に追加するには:

1. 次のいずれかを行います。

- 「外部サービス」スイムレーンで右クリックし、「選択」をポイントして、「ビジネス・サービス」を選択します。
「ビジネス・サービスの選択」ダイアログが表示されます。

- パイプラインまたは分割-結合の右アンカーをクリックし、これを「外部サービス」スイムレーンにドラッグします。
「リソース・チューザ」ダイアログが表示されます。

2. プロジェクトのリストで、プロジェクトおよび使用するビジネス・サービスを含むフォルダを開きます。

3. 使用するビジネス・サービスを選択し、「終了」をクリックします。

4. JDeveloperのツールバーで「すべて保存」をクリックします。

5.2.8 デプロイされたService BusおよびSOAアプリケーションの呼出し方法

Service Busアプリケーションから、すでにOracle WebLogic Serverにデプロイされている別のService BusまたはSOAアプリケーションを呼び出すことができます。

デプロイされたService BusおよびSOAアプリケーションを呼び出すには:

1. Service Bus概要エディタで、トランスポートまたはアダプタを「プロキシ・サービス」または「外部サービス」スイムレーンにドラッグすることにより、「ビジネス・サービスの作成」ウィザードまたは「プロキシ・サービスの作成」ウィザードを起動します。

2. 「タイプ」ページで、「WSDL」を選択し、「既存のWSDLを検索します。」アイコンをクリックします。

「WSDLの選択」ダイアログが表示されます。

3. 上部のリストで「アプリケーション・サーバー」を選択します。

4. アプリケーションがデプロイされているOracle WebLogic Serverを選択します。

5. ツリーを開き、呼び出すService BusまたはSOAアプリケーションを表示します。

6. 呼び出すサービスが表示されるまで、アプリケーションを開きます。

7. サービスを選択して「OK」をクリックします。

「Service Busリソースのインポート」ダイアログが表示されます。

8. リソースおよび場所の情報を検証して、「次」をクリックします。

9. 「構成」ページでサービスおよび依存するすべてのリソース(スキーマなど)が選択されていることを確認し、「終了」をクリックします。

10. 「ビジネス・サービスの作成」ウィザードまたは「プロキシ・サービスの作成」ウィザードの「タイプ」ページで、バインディングまたはポート情報を確認して「次」をクリックします。

11. トランスポートおよびURI情報を確認し、「終了」をクリックします。

アプリケーション・サーバー接続の作成の詳細は、「Oracle Service Busサービスのデプロイ」を参照してください。

5.2.9 コンポーネントの追加に関する必知事項

コンポーネントの追加について、次の点に注意してください。

- コンポーネントは、Service Bus概要エディタ、またはプロジェクトやフォルダを右クリックしてアクセスする「アプリケーション・ナビゲータ」メニューのいずれかで作成できます。どちらの方法でも、コンポーネントが概要に追加され、コンポーネントのファイルがプロジェクトに追加されます。
次の章では、アプリケーション・ナビゲータからコンポーネントを追加する手順について説明します。

- プロキシ・サービスの作成と構成

- ビジネス・サービスの作成と構成

- 分割-結合によるサービスのパフォーマンスの向上

- Oracle Service Busパイプラインの操作

- また、Service Busコンポーネントは、ランタイムにデプロイされるWebサービスと、Metadata Services (MDS)リポジトリを使用して共有されるWebサービスから作成することもできます。Webサービスを参照するには、「リソース」ウィンドウを使用します。詳細は、「メタデータ・サービス・リポジトリを使用したデータの共有」を参照してください。

5.3 Service Bus概要エディタでのコンポーネントの変更および削除

Service Bus概要エディタから、コンポーネントの名前変更やコンポーネントの削除を行うことができ、またコンポーネントの定義エディタにアクセスしてその構成を更新できます。

- Service Bus概要エディタからのコンポーネントの編集方法

- Service Bus概要エディタでのコンポーネントの名前変更方法

- Service Bus概要エディタでのコンポーネントの削除方法

5.3.1 Service Bus概要エディタからのコンポーネントの編集方法

概要エディタでコンポーネントを作成したら、追加構成が必要です。コンポーネントの特定の詳細を構成するために、概要エディタからコンポーネントの定義エディタにアクセスできます。

Service Busコンポーネントを編集するには:

1. Service Bus概要エディタでコンポーネントをダブルクリックすると、表5-5に示すとおり、該当するエディタまたはデザイナが表示されます。

表5-5 Service Bus概要エディタからのService Busエディタの起動

コンポーネント

説明

パイプライン

Service Bus概要エディタでパイプラインをダブルクリックすると、パイプライン定義エディタが起動され、ここで、データ・フローおよび変換を定義できます。このエディタでは、グラフィカルな形式でステージ、アクションおよびエラー・ハンドラをメッセージ・フローにドラッグ・アンド・ドロップできます。

分割-結合

Service Bus概要エディタで分割-結合をダブルクリックすると、分割-結合定義エディタが起動され、ここで、メッセージ部分を並列処理するためのデータ・フローおよび変換を定義できます。このエディタでは、グラフィカルな形式で操作およびエラー・ハンドラをメッセージ・フローにドラッグ・アンド・ドロップできます。

プロキシ・サービス

Service Bus概要エディタでプロキシ・サービスをダブルクリックすると、プロキシ・サービス定義エディタが起動され、ここでさらにそのプロキシ・サービスのトランスポート、接続情報およびセキュリティ・ポリシーを構成できます。

ビジネス・サービス

Service Bus概要エディタでビジネス・サービスをダブルクリックすると、ビジネス・サービス定義エディタが起動され、ここでさらにそのビジネス・サービスのトランスポート、接続情報およびセキュリティ・ポリシーを構成できます。

2. プロキシ・サービスまたはビジネス・サービスの基になるJCAアダプタを編集するには、概要エディタでプロキシ・サービスまたはビジネス・サービスを右クリックし、「JCAの編集」を選択します。

関連付けられたアダプタの構成ウィザードが表示されます。

3. プロキシ・サービスまたはビジネス・サービスの基になるRESTバインディングを編集するには、概要エディタでプロキシ・サービスまたはビジネス・サービスを右クリックして、「RESTの編集」を選択します。

「RESTバインディング」ウィザードが表示されます。

4. Service BusコンポーネントのエディタからService Bus概要エディタに戻るには、アプリケーション・ナビゲータでproject_nameノードをダブルクリックするか、デザイナ上のproject_nameタブをクリックします。

サービス・コンポーネント・エディタについては、「ヘルプ」をクリックするか、[F1]キーを押してください。

5. 「ファイル」メイン・メニューから「すべて保存」を選択します。

5.3.2 Service Bus概要エディタでのコンポーネントの名前変更方法

Service Bus概要エディタからコンポーネントの名前を変更すると、そのファイルの名前とアプリケーション・ナビゲータで対応するノードの名前が、変更を反映して更新されます。名前が変更されたコンポーネントへの参照もすべて更新されます。

注意:

JDeveloperのリファクタ機能を使用してコンポーネントの名前を変更しても、同じ処理が行われます。

Service Busコンポーネントの名前を変更するには:

1. Service Bus概要エディタで、名前を変更するコンポーネントを右クリックします。

2. 「名前変更」をクリックします。

3. 「名前変更」ダイアログの「変更後の名前」フィールドに、コンポーネントの新しい名前を入力します。ファイル拡張子は変更しないでください。

4. コンポーネントが別のコンポーネントにより参照されている場合は、「使用方法の表示」をクリックしてこれらの参照を確認します。

5. 「OK」をクリックして新しい名前を確定します。

6. JDeveloperツールバーで「すべて保存」をクリックします。

5.3.3 Service Bus概要エディタでのコンポーネントの削除方法

コンポーネントが削除されると、それを指しているすべての参照が無効となり、すべてのワイヤが削除されます。これにより、コンポーネントを定義するファイルも削除されます。WSDLドキュメントやXMLスキーマなどの関連ファイルは削除されません。

Service Busコンポーネントを削除するには:

1. Service Bus概要エディタで、削除するコンポーネントを右クリックし、「削除」を選択します。

「削除の確認」ダイアログが表示されます。

2. プロジェクトでコンポーネントが使用されている場合、「使用方法の表示」をクリックして詳細を確認します。

3. コンポーネントの削除を進めるには、「はい」をクリックします。

5.4 概要ダイアグラムの同期

Service Bus概要エディタの内部と外部の両方から、Service Busコンポーネントを追加および編集できます。概要エディタ外からの変更は、概要エディタの起動時に自動的に概要ダイアグラムと同期されますが、ダイアグラムが適切に表示されているかどうかが疑わしい場合は、概要エディタのツールバーにダイアグラムをリフレッシュおよび更新するオプションが用意されています。

- ダイアグラムのリフレッシュ: コンポジット・ダイアグラムを、構成フレームワークで保存されているプロジェクト・コンポーネントの現在の状態に同期します。

- 検証状態のリフレッシュ: 検証チェックを実行して、コンポジット・ノード上のすべての競合インジケータを強調表示します。競合は、中央に「x」が付いた赤いアイコンで示されます。

プロジェクト・コンポーネントへの変更が保存されないうちにService Bus概要エディタを閉じると、保存する必要のあるファイルのリストが示されたダイアログが表示されます。エディタを閉じる前に保存するファイルを選択できます。保存しないファイルは、エディタが閉じられると、最後に保存された状態に戻ります。データの損失を防ぎ、プロジェクト・ファイルを同期された状態に保つため、作業内容は頻繁に保存することをお薦めします。

5.5 Service Busコンポーネントのワイヤリング

プロキシ・サービス、パイプライン、分割-結合および外部サービスをワイヤリング(接続)して、メッセージ処理中にコンポーネントが呼び出される順序を示します。Service Busコンポーネントのワイヤリング時には次のガイドラインが適用されます。

- プロキシ・サービスはインバウンド・サービスであるため、参照ハンドルは右側に表示されます。外部サービスはアウトバウンドであるため、サービス・ハンドルは左側に表示されます。パイプラインおよび分割-結合には両側にハンドルがあります。

- プロキシ・サービスは、他の任意のコンポーネントまたは参照タイプにワイヤリングできます。プロキシ・サービスから別のコンポーネントにワイヤリングすると、Service Busは、プロキシ・サービスの「ターゲット・サービス」フィールドを新しいターゲット情報で更新します。

- パイプラインおよび分割-結合は、他の任意のコンポーネントまたは参照タイプにワイヤリングできます。パイプラインまたは分割-結合から別のコンポーネントにワイヤリングすると、Service Busは、パイプラインまたは分割-結合の「外部サービス」ノードにコンポーネント情報を追加します。

- プロキシ・サービスがポストできるのは1つのコンポーネントまたは参照のみであるため、各プロキシ・サービスが持つことのできるアウトバウンド・ワイヤは1つのみです。

- ワイヤリングするソース・サービスと宛先サービスのバインディング・タイプに互換性がない場合、そのコンポーネントはワイヤリングできません。この検証は現在保存されている状態に基づきます。

5.5.1 Service Busコンポーネントのワイヤリング方法

プロキシ・サービスは、パイプライン、分割-結合または外部サービスにワイヤリングできます。パイプラインおよび分割-結合は、互いにワイヤリングすることも、外部サービスにワイヤリングすることもできます。たとえば、プロキシ・サービスをパイプラインにワイヤリングし、そのパイプラインを分割-結合にワイヤリングし、さらにその分割-結合をビジネス・サービスにワイヤリングできます。

Service Busコンポーネントをワイヤリングするには:

1. ワイヤリング元となるコンポーネントのハンドルをクリックし、ワイヤリング先となるコンポーネントにワイヤをドラッグします。

ヒント:

ワイヤをドラッグする際、必ずコンポーネントの受信ハンドルにドラッグするようにしてください。そうしないと、ワイヤは作成されない場合があります。

2. 「ファイル」メイン・メニューから「すべて保存」を選択します。

3. プロキシ・サービスのターゲット・サービスを検証するには、次を実行します。

a. プロキシ・サービスをダブルクリックします。

b. ワイヤリングされたコンポーネントが「全般」タブの「ターゲット・サービス」フィールドに表示されることを確認します。

4. パイプラインの外部サービスを検証するには、次を実行します。

a. パイプラインをダブルクリックします。

b. パイプライン定義エディタで、ルート・ノードの横の左矢印ボタンをクリックします。

c. 「外部サービス」を開きます。
ワイヤリングされたプロキシ・サービスがリストに表示されます。

5. 分割-結合の外部サービスを検証するには、次を実行します。

a. 分割-結合をダブルクリックします。

b. 分割-結合定義エディタで、ルート・ノードの横の左矢印ボタンをクリックします。

c. 「外部サービス」を開きます。
ワイヤリングされたビジネス・サービスがリストに表示されます。

5.5.2 サービス間のワイヤの削除方法

ワイヤを削除すると、リンクしている情報もすべてクリーンアップされ、削除されます。

- プロキシ・サービスからパイプライン、分割-結合またはビジネス・サービスへのワイヤを削除すると、Service Busはそのプロキシ・サービスの「ターゲット・サービス」フィールドからサービス情報を削除します。

- パイプラインまたは分割-結合から別のコンポーネントへのワイヤを削除すると、Service Busは、パイプラインまたは分割-結合の「外部サービス」ノードからコンポーネント情報を削除します。

- コンポーネント内のアクティビティが削除されたリンクとリンクされている場合、そのコンポーネントの検証でエラーが報告されるため、これを明確に修正できます。ワイヤの削除時に、Service Busが自動的にこれを修正することはありません。

サービス間のワイヤを削除するには:

1. 削除するワイヤを右クリックし、「削除」をクリックします。

2. 「削除の確認」ダイアログで、「はい」をクリックします。

5.6 Service Busコンポーネントへのセキュリティ・ポリシーのアタッチ

Service Bus概要エディタでService Busコンポーネントを作成すると、プロキシ・サービスやビジネス・サービスにセキュリティ・ポリシーをアタッチしてサービスを保護できます。セキュリティは、特定のサービスに対してメッセージ・レベルやトランスポート・レベルで定義することもできます。ポリシーの実装の詳細は、「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。

プロキシ・サービスまたはビジネス・サービスにセキュリティ・ポリシーをアタッチするには:

1. Service Bus概要エディタで、セキュリティを追加するプロキシ・サービスまたはビジネス・サービスを右クリックします。

2. 「OSB WSポリシーの構成」を選択します。

選択したサービスのエディタが表示され、「ポリシー」タブが示されています。

3. 「JDeveloperでのポリシーのアタッチと構成」の説明に従い、ポリシーをアタッチします。

4. 完了したら、JDeveloperツールバーで「保存」をクリックします。

5.7 概要エディタでのService Busコンポーネントのテスト

Service Bus概要エディタからJDeveloperの実行機能とデバッグ機能に直接アクセスして、作成したコンポーネントをテストおよびデバッグできます。エディタでコンポーネントの「実行」または「デバッグ」を選択すると、Service Busテスト・コンソールが起動し、このコンソールでテストの入力を行い、テスト用の追加オプションを構成できます。デバッグにより、パイプラインおよび分割-結合でブレークポイントを設定できるため、メッセージ・フローをステップ実行して、管理可能なセクションでそのフローをテストできます。

5.7.1 Service Busコンポーネントのテスト方法

概要エディタからテスト・コンソールに直接アクセスして、Service Busコンポーネントをテストします。

Service Busコンポーネントをテストするには:

1. Service Bus概要エディタで、テストするコンポーネントを右クリックし、「実行」を選択します。

テストするコンポーネントは、プロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合になります。Webブラウザにテスト・コンソールが表示されます。

2. テスト・コンソールで入力を行い、「実行」をクリックします。

テスト・コンソールの設定プロパティの詳細は、「サービスのテスト・コンソール・ページ参照」を参照してください。

3. テストが終了したら、JDeveloperツールバーで「終了」をクリックして、実行中のプロセスの名前を選択します。

5.7.2 Service Busコンポーネントのデバッグ方法

JDeveloperのデバッグ機能を使用して、パイプラインおよび分割-結合でブレークポイントを設定し、テスト・コンソールでブレークポイントをテストします。

Service Busパイプラインまたは分割-結合をデバッグするには:

1. 「Service Busコンポーネントにブレークポイントを設定する方法」に説明されているとおり、パイプラインまたは分割-結合のブレークポイントを設定します。

2. Service Bus概要エディタで、デバッグするパイプラインまたは分割-結合を右クリックし、「デバッグ」を選択します。

Webブラウザにテスト・コンソールが表示されます。

3. テスト・コンソールで入力を行い、「実行」をクリックします。

テスト・コンソールの設定プロパティの詳細は、「サービスのテスト・コンソール・ページ参照」を参照してください。

4. テストが終了したら、JDeveloperツールバーで「終了」をクリックして、デバッグ中のプロセスの名前を選択します。

5.8 Service Busアプリケーションのデプロイ

JDeveloperからService Busアプリケーションをデプロイするには、JDeveloperのインスタンスにOracle WebLogic Serverへの接続が必要です。Service Busプロジェクトをエクスポートし、これらをOracle Service Busコンソールにインポートして、コンソールからプロジェクトをアクティブ化することもできます。Service Busアプリケーションのデプロイの詳細は、「Oracle Service Busサービスのデプロイ」を参照してください。

第II部 Oracle Service Busリソースの使用

この部では、Service Busプロジェクトで作成および使用できる主要リソースについて説明し、そのリソースの作成および保守方法を示します。

この部は、次の章で構成されています。

- プロジェクト・リソースの作成と構成

- システム・リソースの作成と構成

- プロキシ・サービスの作成と構成

- ビジネス・サービスの作成と構成

- 分割-結合によるサービスのパフォーマンスの向上

- WSDLドキュメントの操作

パイプラインの詳細は、「Oracle Service Busパイプラインの操作」で説明されています。

6 プロジェクト・リソースの作成と構成

この章では、Service Busサービスをサポートするために作成できるプロジェクト・リソースの詳細について説明し、その他リソースへのリンクを示します。 プロジェクト・リソースは、セッション全体のサービス間で共有および再利用できます。たとえば、ローカル・リソースには、認証アカウント、JARファイル、MQ接続、電子メールまたはJMSアラート宛先、マッピングなどがあります。これらのリソースの一部は、プロキシ・サービスやビジネス・サービスから参照でき、リソースを使用するプロキシ・サービスやビジネス・サービスを構成する前に作成しておく必要があります。

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

- Service Busプロジェクト・リソースの概要

- サービス・アカウントの使用

- サービス・キー・プロバイダの操作

- アラート宛先の操作

- XMLスキーマの使用

- XMLドキュメントの操作

- JARファイルの操作に関する項

次のトピックでは、その他のタイプのローカル・リソースに関する情報と手順を示します。

- WSDLドキュメントの操作

- Service BusでのRESTサービスに関するWADLドキュメント

- XQueryでのデータの変換

- XSLTでのデータの変換

- 相互参照でのデータのマッピング

- ドメイン値マップでのデータのマッピング

- Message Format Languageを使用したデータ構造の定義

- JCAバインド・リソースの操作

- JavaScriptリソースの操作

- MQ接続の操作

- 『Oracle Service Busの管理』のビジネス・サービスのグループに対するスロットルの構成に関する項

6.1 Service Busプロジェクト・リソースの概要

Service Busプロジェクト・リソースとは、アプリケーションまたはセッション内のいくつかのコンポーネントから参照できるプロジェクト・リソースです。これらはローカル・リソースとも呼ばれ、リモート・サーバー、XMLドキュメントおよびスキーマ、JARファイル、XSLTマッピングおよびXQueryマッピング、WSDLファイルおよびWADLファイルなどの認証情報を定義するサービス・アカウントのようなリソースがあります。特定のService Busコンポーネントでは指定したプロジェクト・リソースへのアクセスが必要であり、そのプロジェクト・リソースは、リソースに依存するコンポーネントを作成する前に作成しておく必要があります。たとえば、電子メール・トランスポートでプロキシ・サービスを作成する場合、電子メール・サーバーのログイン情報を定義するサービス・アカウントを最初に作成しておく必要があります。MQプロキシ・サービスまたはビジネス・サービスを作成するには、まずMQ接続リソースを作成する必要があります。

6.1.1 Oracle Service Busコンソールのプロジェクト・リソースおよびセッション

Oracle Service Busコンソールでプロジェクト・リソースを作成、変更または削除する場合、アクティブ・セッションで作業する必要があります。セッションを破棄する場合、作成したプロジェクト・リソースや関連付けられたデータも破棄されます。リソースの作成または変更後にセッションをアクティブ化した場合、Service Busでは、その情報をランタイムで利用できるようにします。

6.2 サービス・アカウントの操作

サービス・アカウントは、プロキシ・サービスとビジネス・サービスが、アウトバウンド認証や、ローカルまたはリモート・リソース(FTPサーバーやJMSサーバーなど)への認証に使用するユーザー名とパスワードを提供します。Service Busアクセスに定義するユーザー名とパスワードは、インバウンド認証および管理リクエストの認証に使用されます。たとえば、ビジネス・サービスがWebサービスによるトランスポート・レベルの認証でユーザー名とパスワードを提示する必要がある場合、ユーザー名とパスワードを指定するサービス・アカウントを作成してから、サービス・アカウントの資格証明をアウトバウンド・リクエストに含めるようにビジネス・サービスを構成します。

6.2.1 サービス・アカウント認証タイプ

同じサービス・アカウントを複数のビジネス・サービスおよびプロキシ・サービスに使用することができます。サービス・アカウントが提示するユーザー名とパスワードを指定するには、次のいずれかのタイプを定義できます。

- 静的

- ユーザー名とパスワードのパススルー

- ユーザー・マッピング認証

6.2.1.1 静的

静的タイプの認証では、ユーザー名とパスワードをサービス・アカウント構成で保存します。サービス・アカウントはこのユーザー名とパスワードをアウトバウンド・リクエストでエンコードします。様々なメッセージに対してログイン情報が変わる必要がない場合は、このタイプの認証を使用します。

6.2.1.2 ユーザー名とパスワードのパススルー

パススルー・サービス・アカウントは、受信クライアント・リクエストで受け取ったユーザー名およびパスワードを提供します。たとえば、インバウンドHTTP基本リクエストにユーザー名「pat」とパスワード「patspassword」が含まれていた場合、サービス・アカウントはアウトバウンド・リクエストで「pat」および「patspassword」をエンコードします。

このタイプでは、クライアント・リクエストにクリア・テキストのユーザー名とパスワードが含まれている必要があるため、HTTP BASICプロトコル、クリア・テキスト・パスワードによるWebサービス・セキュリティのユーザー名トークン認証、またはカスタム・ユーザー名とパスワードのトークンを使用するクライアント・リクエストのみに使用できます。

この方法は、Service Busとエンドポイントが同じ認証ドメインに属する場合にのみ使用することをお薦めします。たとえば、この方法は単一の組織内でメッセージをルーティングし、Service Busとメッセージ・コンシューマの両方が共通のLDAPサーバーに対して認証される場合に使用します。

この方法には、次の制限が適用されます。

- FTPサーバーまたはJMSサーバーなどのローカルまたはリモート・サーバー、またはシステム・リソースに対してService Busを認証するアウトバウンド・リクエストには使用できません。

- fn-bea:lookupBasicCredentials XQuery関数とともに使用できません。詳細は、「Service Bus XQuery関数」を参照してください。

注意:

プロキシがアクティブなWSS仲介である場合は、WS-Securityを使用して、WS-Securityユーザー名トークンまたはカスタムのユーザー名とパスワードを暗号化できます。この場合、プロキシは最初にリクエストを復号化し、次にクリア・テキストのユーザー名/パスワードにアクセスするため、ユーザー名/パスワードのパススルーが機能します。

6.2.1.3 ユーザー・マッピング認証

マッピング認証を使用するサービス・アカウントは、認証された1つ以上のクライアントのユーザー名を、指定したユーザー名とパスワードにマップします。マッピング認証タイプの場合、クライアントからインバウンド・リクエストを認証することで取得されるユーザー名(ローカル・ユーザー名)を、指定したユーザー名とパスワード(リモートのユーザー名およびパスワード)に関連付ける(マップする)必要があります。サービス・アカウントはマップされている認証クライアントからのリクエストを受け取ると、ビジネス・サービス、またはプロキシ・サービスのアウトバウンド・リクエストに対して、適切なリモート・ユーザー名およびパスワードを提示します。

トランスポート・レベルおよびメッセージ・レベルの両方でクライアントが認証する場合、サービス・アカウントはメッセージ・レベルのユーザー名をリモートのユーザー名とパスワードにマップします。匿名のユーザー名をリモートのユーザー名およびパスワードにマップすることもできます。

マッピング認証には、次の制限事項が適用されます。

- FTPサーバーまたはJMSサーバーなどのローカルまたはリモート・サーバー、またはシステム・リソースに対してService Busを認証するアウトバウンド・リクエストには使用できません。

- fn-bea:lookupBasicCredentials XQuery関数とともに使用できません。詳細は、「Service Bus XQuery関数」を参照してください。

6.2.2 サービス・アカウントの作成方法

サービス・アカウントを使用して、アウトバウンド認証またはリソース認証(FTPサーバーやJMSサーバーなど)のプロキシ・サービスおよびビジネス・サービスに認証情報を提供します。サービス・アカウントは、次の方法で認証情報を定義できます。

- 静的ユーザー名およびパスワードを提供する。

- 受信ユーザー名とパスワードをサーバーに渡す。

- 受信ユーザー名とパスワードを、指定したユーザー名とパスワードにマップする。

これらの認証タイプの詳細は、「サービス・アカウント認証タイプ」を参照してください。サービス・アカウント・プロパティの詳細は、Service Busに付属のオンライン・ヘルプを参照してください。

6.2.2.1 認証情報をパススルーするサービス・アカウントの作成

認証情報をパススルーするサービス・アカウントを作成するには:

1. 次のいずれかを行います。

- JDeveloperの場合: アプリケーション・ナビゲータで、新しいサービス・アカウントを含めるプロジェクトまたはフォルダを右クリックして、「新規」をポイントし、「サービス・アカウント」を選択します。

- Oracle Service Busコンソールの場合: プロジェクト・ナビゲータで、新しいサービス・アカウントを含めるプロジェクトまたはフォルダを右クリックして、「作成」をポイントし、「リソース」を選択します。「セキュリティ」をクリックし、「サービス・アカウント」をクリックして「OK」をクリックします。

2. このサービス・アカウントの一意の名前と、必要に応じて説明を入力します。

3. 「作成」または「終了」をクリックします。

サービス・アカウント定義エディタが表示されます。デフォルトでは、タイプは「パス・スルー」になります。

4. 「保存」をクリックします。

サービス・アカウントが現在のセッションで作成および保存されます。

6.2.2.2 静的パスワードでのサービス・アカウントの作成

サービス・アカウントを静的パスワードで作成するには:

1. 前述のように、サービス・アカウントを作成します。

2. サービス・アカウント定義エディタで、タイプに「静的」を選択します。

ヒント:

Oracle Service Busコンソール内で作業している場合、初めてリソースを作成するときに、「サービス・アカウントの作成」ダイアログでそのタイプの「静的」を選択することもできます。

エディタにユーザー名とパスワードのフィールドが表示されます。

3. ユーザー名とパスワードを入力して、入力したパスワードを確定します。

4. ツールバーで、「保存」をクリックします。

6.2.2.3 受信パスワードをマップするサービス・アカウントの作成

受信パスワードをマップするサービス・アカウントを作成するには:

1. 前述のように、サービス・アカウントを作成します。

2. サービス・アカウント定義エディタで、タイプに「マッピング」を選択します。

ヒント:

Oracle Service Busコンソール内で作業している場合、初めてリソースを作成するときに、「サービス・アカウントの作成」ダイアログでそのタイプの「マッピング」を選択することもできます。

エディタにマッピング表が表示されます。

3. 「リモート・ユーザー」表で次のようにします。

a. 表の上にある「追加」アイコンをクリックします。

b. 表示された新しい行に、アウトバウンド・リクエストで送信するユーザー名とパスワードを入力します。

c. 追加するリモート・ユーザーごとに前述の手順を繰り返します。

d. リモート・ユーザーを削除するには、表の行を選択して「削除」アイコンをクリックします。

4. リモート・ユーザーとローカル・ユーザーをマップするには、「ローカル・ユーザー」表で次のようにします。

a. 表の上にある「追加」アイコンをクリックします。

b. 「ローカル・ユーザー名」列に、インバウンド・リクエストで認証されたクライアントを識別する名前を入力します。

c. 「リモート・ユーザー名」のオプション・リストから、「ローカル・ユーザー名」フィールドで指定した認証ユーザーに関してアウトバウンド・リクエストで送信するユーザー名を選択します。
オプションのリストは、「リモート・ユーザー」表で作成した値から移入されます。

d. 追加するローカル・ユーザーごとに前述の手順を繰り返します。

注意:

Fusion Middleware Controlでこれらのユーザーをまだ追加していない場合は、このマッピングを実行時環境で使用する前に追加します。それ以外の場合、マッピングが認証ユーザーに一致することはなく、使用されることもありません。ユーザーの追加の詳細は、『Oracle Service Busの管理』のOracle Service Busユーザーの作成に関する項を参照してください。

e. ローカル・ユーザーを削除するには、表の行を選択して「削除」アイコンをクリックします。

5. 特定のリモート・ユーザー・アカウントに匿名リクエストをマップするには、「匿名リクエストをリモート・ユーザーにマップ」を選択し、オプションのリストからユーザー名を選択します。
オプションのこのリストも、「リモート・ユーザー」表で作成した値から移入されます。

6. ツールバーで、「保存」をクリックします。

6.2.3 サービス・アカウントの編集方法

サービス・アカウントを作成すると、静的ログイン資格証明の更新、マップ済認証に関するリモート・ユーザーとローカル・ユーザーの追加や削除など、その説明と認証タイプを変更できます。

サービス・アカウントを編集するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、編集するサービス・アカウントを含むプロジェクトとフォルダを開きます。

2. サービス・アカウント名を右クリックして、「開く」を選択します。

3. 次の変更を行います。

- 説明を更新します。

- 認証タイプを変更します。「サービス・アカウントの作成方法」の説明に従い、認証情報を確実に再構成してください。

- マップ済認証タイプの場合: リモート・ユーザーとローカル・ユーザーの追加または削除、リモート・ユーザーのパスワード変更、ローカル・ユーザーのマッピング変更および匿名ユーザーのマッピング更新を行います。
これらのタスクの詳細は、「受信パスワードをマップするサービス・アカウントの作成」およびオンライン・ヘルプを参照してください。

サービス・アカウント名は変更できません。

4. 変更が終了したら、「保存」をクリックします。

5. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

注意:

変更したサービス・アカウントがWebLogic JMSサーバーの認証に使用されている場合、JMSサーバーが最大の60秒で変更を認識できない場合があります。デフォルトでは、WebLogic Server JMSは各宛先の許可を60秒間隔でチェックします。この動作を変更するには、システム・プロパティweblogic.jms.securityCheckIntervalがWebLogic Server JMSによって権限がチェックされる間隔(秒単位)に設定されるようにWebLogic Serverの起動コマンドを変更します。

このプロパティの値を0に設定すると、JMSリソースに対してsend、receiveおよびgetEnumerationアクションが実行されるたびに、許可チェックが行われます。

6.2.4 サービス・アカウントの削除方法

サービス・アカウントを削除すると、サービス・アカウントが定義するユーザー名、パスワード、またはローカル・ユーザーからリモート・ユーザーへのマッピング・データも削除されます。サービス・アカウントが他のリソースで参照される場合でも、そのアカウントを削除できますが、削除されたリソースに対する未解決の参照が原因で競合が生じることがあります。

始める前に:

そのサービス・アカウントを使用する構成のビジネス・サービス、またはプロキシ・サービスがある場合は、そのビジネス・サービス、またはプロキシ・サービスからサービス・アカウントを削除してください。Oracle Service Busコンソールの場合、サービス・アカウント定義エディタでサービス・アカウントを開き、右上のツール・アイコンをクリックし、「参照」を選択して、いずれかのサービスでそのサービス・アカウントを使用しているかどうかを確認します。JDeveloperで、サービス・アカウントを右クリックして、「依存性の参照」を選択します。

サービス・アカウントを削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するサービス・アカウントを含むプロジェクトとフォルダを開きます。

2. サービス・アカウントを右クリックして、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに、サービス・アカウントの参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

6.3 サービス・キー・プロバイダの操作

サービス・キー・プロバイダには、プロキシ・サービスがインバウンドSOAPメッセージの復号化、アウトバウンド認証、およびデジタル署名で使用する、公開鍵インフラストラクチャ(PKI)の資格証明情報が含まれます。PKI資格証明とは、デジタル署名や暗号化(Webサービス・セキュリティ)、およびアウトバウンドSSL認証に使用できる証明書とペアになった秘密鍵です。この証明書には、秘密鍵に対応する公開鍵が含まれています。

注意:

- サービス・キー・プロバイダを使用するには、PKI資格証明マッピング・プロバイダを構成する必要があります。この操作の詳細は、「Oracle WebLogicセキュリティ・フレームワークの構成: 主な手順」を参照してください。

- Service Busの以前のバージョンでは、サービス・キー・プロバイダは、プロキシ・サービス・プロバイダと呼ばれていました。

1つのサービス・キー・プロバイダに対して、次のPKI資格証明情報をすべて含めることができます。

- デジタル暗号化用のキー・ペア
プロキシ・サービスがWeb Services Policy文に従って暗号化されているインバウンドSOAPメッセージを復号化する場合に、このキー・ペアが使用されます。サービス・キー・プロバイダでデジタル暗号化をサポートする場合、PKI資格証明マッパーに関連付けられているキーストアには、暗号化をサポートするX.509資格証明が少なくとも1つ必要です。

- デジタル署名用のキー・ペア
プロキシ・サービスのエンドポイントがWebサービスであり、そのWebサービスでクライアントがSOAPエンベロープの1つまたは複数の部分に署名することが必要な場合に、この鍵ペアがプロキシ・サービスで使用されます。

- SSLクライアント認証方式(双方向SSL)用のキー・ペア
プロキシ・サービスは、アウトバウンドTLS/SSL (Secure Sockets Layer)接続時にクライアントとして動作するとき、つまり、クライアント証明書認証を必要とするHTTPSビジネス・サービスまたはプロキシ・サービスにメッセージをルーティングするときに、この鍵ペアを使用して認証します。

同じサービス・キー・プロバイダを複数のプロキシ・サービスに使用することができます。

6.3.1 サービス・キー・プロバイダの作成方法

暗号化鍵サービス・キー・プロバイダをプロキシ・サービスに関連付けると、Service Busにより、X.509証明書がプロキシ・サービスのWSDLファイルに組み込まれます。その後、プロキシ・サービスはこの証明書を使用してエンドポイントに送信するメッセージを暗号化します。プロキシ・サービスは、PKI資格証明情報に含まれる秘密鍵を使用して、エンドポイントから返されるメッセージを復号化します。

サービス・キー・プロバイダを作成するには:

1. 次のいずれかを行います:

- JDeveloperの場合: アプリケーション・ナビゲータで、新しいサービス・キー・プロバイダを含めるプロジェクトまたはフォルダを右クリックして、「新規」をポイントし、「サービス・キー・プロバイダ」を選択します。

- Oracle Service Busコンソールの場合: プロジェクト・ナビゲータで、新しいサービス・キー・プロバイダを含めるプロジェクトまたはフォルダを右クリックして、「作成」をポイントし、「リソース」を選択します。「セキュリティ」をクリックし、「サービス・キー・プロバイダ」をクリックして「OK」をクリックします。

2. このサービス・キー・プロバイダの一意の名前と、必要に応じて説明を入力します。

3. 「作成」または「終了」をクリックします。
サービス・キー・プロバイダ定義エディタが表示されます。

4. 暗号化鍵を構成するには、次のようにします。

a. 「暗号化鍵」の横にある「参照」アイコンをクリックします。
暗号化鍵の別名の選択ウィンドウに、レルムのPKI資格証明マッパーが使用しているキー・ストアに含まれる鍵の別名が表示されます。

b. キー・ストアへのアクセスをセキュリティで保護するために使用するパスワードを入力します。(このパスワードはキー・ストアの作成時に設定します。)

c. X.509証明書にマップして暗号化をサポートするキー・エイリアスを選択します。

d. 「発行」をクリックします。

5. デジタル署名鍵を構成するには、次のようにします。

a. 「デジタル署名鍵」の横にある「参照」アイコンをクリックします。
デジタル署名鍵の別名の選択ウィンドウに、レルムのPKI資格証明マッパーが使用しているキー・ストアに含まれる鍵の別名が表示されます。

b. キー・ストアへのアクセスをセキュリティで保護するために使用するパスワードを入力します。(このパスワードはキー・ストアの作成時に設定します。)

c. キー・エイリアスを選択します。

d. 「発行」をクリックします。

6. 双方向SSLのSSLクライアント認証キーを構成するには、次のようにします。

a. 「SSLクライアント認証キー」の横にある「参照」アイコンをクリックします。
SSLクライアント認証キーの別名の選択ウィンドウに、レルムのPKI資格証明マッパーが使用しているキー・ストアに含まれる鍵の別名が表示されます。

b. キー・ストアへのアクセスをセキュリティで保護するために使用するパスワードを入力します。(パスワードはキーストアの作成時に設定する)。

c. キー・エイリアスを選択します。

d. 「発行」をクリックします。

7. ツールバーで、「保存」をクリックします。

8. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

6.3.2 サービス・キー・プロバイダの編集方法

サービス・キー・プロバイダを作成すると、鍵の情報を再構成できます。

サービス・キー・プロバイダを編集するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、編集するサービス・キー・プロバイダを含むプロジェクトとフォルダを開きます。

2. サービス・アカウント名を右クリックして、「開く」を選択します。

3. フィールドを変更するには、フィールドの右側のアイコンをクリックして、鍵を選択、削除または編集します。

編集可能なフィールドの詳細は、「サービス・キー・プロバイダの作成方法」、およびService Busに付属のオンライン・ヘルプを参照してください。

4. 変更が完了したら、ツールバーで「保存」をクリックします。

5. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

6.3.3 サービス・キー・プロバイダの削除方法

サービス・キー・プロバイダを削除すると、Service Busでは、鍵ペア・バインディングに対して関連付けられている別名もPKI資格証明マッピング・プロバイダから削除します。ただし、関連付けられている鍵と証明書のペアはキー・ストアから削除されません。サービス・キー・プロバイダが他のリソースで参照される場合でも、そのプロバイダを削除できますが、削除されたリソースに対する未解決の参照が原因で競合が生じることがあります。

始める前に:

プロキシ・サービスがサービス・キー・プロバイダを使用するよう構成されている場合は、プロキシ・サービスからサービス・キー・プロバイダを削除します。Oracle Service Busコンソールの場合、サービス・キー・プロバイダ定義エディタでサービス・キー・プロバイダを開き、右上のツール・アイコンをクリックし、「参照」を選択して、そのサービス・キー・プロバイダに参照があるかどうかを確認します。JDeveloperで、サービス・キー・プロバイダを右クリックして、「依存性の参照」を選択します。

サービス・キー・プロバイダを削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するサービス・キー・プロバイダを含むプロジェクトとフォルダを開きます。

2. サービス・キー・プロバイダの名前を右クリックして、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに、サービス・キー・プロバイダの参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

6.4 アラート宛先の操作

アラート宛先リソースは、Service Busからのアラート通知を受信できる受信者のリストを定義します。所定のコンテキストに基づいて受信者のセットを取り込むように、各アラート宛先リソースを構成し、リソースと定義したアラートを関連付けることができます。アラート宛先には、アラートをSNMPトラップに送信する、レポートのために収集する、ローカル・サーバーのアラート・ログに記録する、および電子メール受信者やJMS宛先に送信するかどうかを指定する柔軟性があります。

パイプラインでアラート・アクションを構成する場合やサービスのSLAアラート・ルールを構成する場合、アラート生成時の通知対象者を定義するアラート宛先を構成で指定する必要があります。電子メールおよびJMS宛先の場合は、宛先リソースに電子メール・アドレスまたはJMS URIのリストをそれぞれ含めることができます。アラート構成全体でアラート宛先を再使用できます。

6.4.1 アラート宛先タイプ

次の項で説明するように、アラート宛先ごとに、、複数のタイプの宛先にアラートを送信するように指定できます。

- 電子メール

- SNMPトラップ

- レポート

- アラートのロギング

- JMS

6.4.1.1 電子メール

アラート通知は、複数の電子メール・アドレスに送信できます。電子メールのアラート宛先を構成するには、SMTPサーバー・グローバル・リソースを使用するか、Oracle WebLogic ServerのJavaMailセッションを使用する必要があります。アラートが配信されるときに、アラートの詳細で構成される電子メールのメタデータが、ペイロードの詳細の前に置かれます。SMTPサーバー・リソースの詳細は、「SMTPサーバー・リソースの操作」を参照してください。JavaMailセッションの構成方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JavaMailへのアクセスの構成」を参照してください。

6.4.1.2 SNMPトラップ

簡易ネットワーク管理プロトコル(Simple Network Management Protocol: SNMP)トラップにより、サード・パーティ製ソフトウェアでService Bus内のサービス・レベル合意を監視できます。SNMP通知が有効な状態で、Webサービス管理(Web Services Management: WSM)ツールおよびESM (Enterprise Service Management)ツールは、SLA違反とパイプライン・アラートを監視できます。

SNMPは、リソースの管理に関する情報をネットワーク上で交換できるようにするアプリケーション層プロトコルです。これにより、リソースをモニターし、必要に応じて、リソースから取得したデータに基づいて処理を行うことができます。Service Busでは、SNMPバージョン1および2がサポートされます。SNMPは、次のコンポーネントで構成されます。

- 管理対象リソース

- 管理情報ベース(MIB)

- SNMPエージェント

- SNMPマネージャ

- ネットワーク管理システム(NMS)

6.4.1.3 レポート

レポート宛先を使用すると、Service Busに付属するレポートAPIを使用して開発できるカスタム・レポート・プロバイダに対して、パイプライン・アラートおよびSLAアラートの通知を送信できます。これにより、カスタムJavaコードを使用して、サード・パーティがアラートを受信および処理できます。

6.4.1.4 アラートのロギング

各アラート宛先では、アラート宛先に送信されるアラートを記録するかどうかを構成できます。記録されたアラートは、ローカルのアラート・ログに送信されます。各Service Busサーバーには、それ自体のアラート・ログがあります。クラスタ内で、管理サーバーは、すべての管理対象サーバーからアラート・ログを収集し、アラートを集約してログを記録します。

6.4.1.5 JMS

アラート通知は、複数のJava Messaging Service (JMS)キューまたはトピックに送信できます。アラートに関してJMS宛先のJNDI URLを構成し、JMS接続ファクトリおよびキューまたはトピックを作成して、Oracle WebLogic Server管理コンソールの該当するJMSサーバーにそれらをターゲット指定する必要があります。詳細は、Oracle WebLogic Server JMSリソースの管理のJMSシステム・リソースの構成方法に関する項を参照してください。JMSアラート宛先を定義するときは、宛先キューまたは宛先トピックを使用できます。メッセージのタイプは、バイトまたはテキストのいずれかです。JMSアラート宛先の構成方法の詳細は、「JMS宛先の追加」を参照してください。

6.4.2 アラート宛先の作成方法

アラートは実行時に集約され、Fusion Middleware ControlのService Busダッシュボードで表示できます。

アラート宛先を作成するには:

1. 次のいずれかを行います。

- JDeveloperの場合: アプリケーション・ナビゲータで、新しいアラート宛先を含めるプロジェクトまたはフォルダを右クリックして、「新規」をポイントし、「アラート宛先」を選択します。

- Oracle Service Busコンソールの場合: プロジェクト・ナビゲータで、新しいアラート宛先を含めるプロジェクトまたはフォルダを右クリックして、「作成」をポイントし、「リソース」を選択します。「その他」をクリックし、「アラート宛先」をクリックして「OK」をクリックします。

2. このアラート宛先の一意の名前と、必要に応じて説明を入力します。

3. 「作成」または「終了」をクリックします。

アラート宛先定義エディタが表示されます。

4. このアラート宛先リソースに含める宛先として、次のいずれかを選択します。JDeveloperで、「はい」を選択して宛先タイプを選択します。

- SNMPトラップ: アラートはSNMPトラップとして送信され、サード・パーティのエンタープライズ・モニター・システムで処理できます。

- レポート: アラートはService Busのレポート・モジュールに送信され、カスタム・レポート・プロバイダを使用して取得できます。カスタム・レポート・プロバイダは、Service Busで提供されるレポートAPIを使用して開発できます。これにより、カスタムJavaコードを使用して、サード・パーティがアラートを受信および処理できます。

- アラートのロギング: このアラート宛先に送られたアラートはアラート・ログに記録されます。

5. アラート宛先リソース定義に電子メール受信者を追加するには、「アラート宛先の電子メール受信者の定義方法」を参照してください。

6. アラート宛先リソース定義にJMS宛先を追加するには、「アラート定義のJMS受信者の定義方法」を参照してください。

7. 「保存」をクリックします。

6.4.3 アラート宛先の電子メール受信者の定義方法

電子メール宛先を追加する前に、SMTPサーバーを構成するか(「SMTPサーバー・リソースの作成方法」を参照)、またはWebLogic ServerでJavaMailセッションを構成する必要があります。使用可能なSMTPサーバー・リソースまたはJavaMailセッションが存在しない場合、電子メール受信者を構成できません。

アラート宛先で電子メール受信者を追加または更新するには:

1. 「アラート宛先の作成方法」の説明に従って、アラート宛先を作成します。

2. 「電子メール受信者」表の上にある「追加」をクリックします。

JDeveloperの場合、ページの下部に電子メールの構成フィールドが表示されます。Oracle Service Busコンソールの場合、「電子メール受信者の追加」ダイアログが表示されます。

3. 「電子メール受信者」フィールドに、電子メール受信者をmailto:username@hostnameの形式で入力します。

複数の電子メール受信者を指定するには、ユーザー名とホスト名をカンマ区切りリストで入力します。たとえば、mailto:username@hostname[,username_1@hostname_1]...[,username_n@hostname_n]のようになります。

最初のメール受信者にかぎり、先頭に「mailto:」というテキストの接頭辞を付ける必要があります。

4. Secure Sockets Layer (SSL)でメッセージを送信するには、「SSLが必要」を選択します。

5. 次のいずれかのみを実行します。

- 送信メールにSMTPサーバーを使用するには、「SMTPサーバー」フィールドをクリックして、使用するSMTPサーバーの名前を選択します。

- Javaメール・セッションを使用するには、「メール・セッション」フィールドをクリックして、使用可能なメール・セッションを選択します。

6. 「送信元の名前」フィールドに、アラート通知の送信者の名前を入力します。

7. 「送信元アドレス」フィールドに、送信者の電子メール・アドレスを入力します。

「送信元の名前」に値を指定した場合、このフィールドは必須です。

8. 「返信先の名前」フィールドに、返信の送信先の名前を入力します。

9. 「返信先アドレス」フィールドに、返信の送信先の電子メール・アドレスを入力します。「返信先の名前」に値を指定した場合、このフィールドは必須です。

10. 「接続タイムアウト」フィールドに、タイムアウトまでに接続がサーバーからのレスポンスを待機するミリ秒数を入力します。

11. 「ソケットI/Oタイムアウト」フィールドに、サーバーからのレスポンスを待機する場合のソケットI/Oタイムアウトのミリ秒数を入力します。

12. 「要求エンコーディング」フィールドに、文字セットのエンコーディング値を入力します。

デフォルトのエンコーディング値は、iso-8859-1です。

13. Oracle Service Busコンソールを使用している場合、「OK」をクリックするとダイアログが閉じます。

14. 電子メール受信者を変更するには、表の該当の行を選択して、表の右上にある「編集」をクリックします。前述のフィールドを変更します。

15. 電子メール受信者を削除するには、表の該当の行を選択して、表の右上にある「削除」をクリックします。

16. 「保存」をクリックします。

6.4.4 アラート宛先のJMS受信者の定義方法

WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。

アラート宛先でJMS宛先を追加または更新するには:

1. 「アラート宛先の作成方法」の説明に従って、アラート宛先を作成します。

2. 「JMS宛先」表の上にある「追加」をクリックします。

JDeveloperの場合、ページの下部にJMS構成フィールドが表示されます。Oracle Service Busコンソールの場合、「JMS宛先の追加」ダイアログが表示されます。

3. 「宛先URI」フィールドに、JMS宛先のURIをjms://host:port/factoryJndiName/destJndiNameという形式で入力します。

4. 「宛先のタイプ」フィールドで、「キュー」または「トピック」を選択します。

5. 「メッセージ・タイプ」フィールドで、「バイト」または「テキスト」を選択します。

6. 「要求エンコーディング」フィールドに、文字セットのエンコーディング値を入力します。

デフォルトのエンコーディング値は、UTF-8です。

7. Oracle Service Busコンソールを使用している場合、「OK」をクリックするとダイアログが閉じます。

8. JMS宛先を変更するには、表の該当の行を選択して、表の右上にある「編集」をクリックします。前述のフィールドを変更します。

9. JMS宛先を削除するには、表の該当の行を選択して、表の右上にある「削除」をクリックします。

10. 「保存」をクリックします。

6.4.5 アラート宛先の編集方法

アラート宛先を作成すると、その説明の変更や、電子メール受信者とJMS宛先の追加、更新または削除を行うことができます。

アラート宛先を編集するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、編集するアラート宛先を含むプロジェクトとフォルダを開きます。

2. アラート宛先名を右クリックして、「開く」を選択します。

3. 説明または構成の詳細を変更します。

- アラートが送信される宛先のタイプを変更するには、「SNMPトラップ」、「レポート」および「アラートのロギング」のいずれかを選択するか選択解除します。
JDeveloperの場合、タイプを選択するには「はい」を選択し、選択解除するには「いいえ」を選択します。

- 電子メール受信者を追加、更新または削除するには、「アラート宛先の電子メール受信者の定義方法」を参照してください。

- JMS宛先を追加、更新または削除するには、「アラート宛先のJMS受信者の定義方法」を参照してください。

4. 変更が終了したら、「保存」をクリックします。

5. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

6.4.6 アラート宛先の削除方法

アラート宛先を削除する場合、リソースを参照するアラート・アクションまたはアラート・ルールを更新する必要があります。アラート宛先から特定の電子メール受信者またはJMS宛先を削除する場合は、「アラート宛先の電子メール受信者の定義方法」または「アラート宛先のJMS受信者の定義方法」を参照してください。

始める前に:

アラート宛先に参照がある場合、宛先を削除する前に参照を削除します。Oracle Service Busコンソールの場合、アラート宛先定義エディタでアラート宛先を開き、右上のツール・アイコンをクリックし、「参照」を選択して、参照があるかどうかを調べます。JDeveloperで、アラート宛先を右クリックして、「依存性の参照」を選択します。

アラート宛先を削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するアラート宛先を含むプロジェクトとフォルダを開きます。

2. アラート宛先を右クリックして、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに、アラート宛先の参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

6.4.7 SNMPの使用

SNMPは、リソースの管理に関する情報をネットワーク上で交換できるようにするアプリケーション層プロトコルです。SNMPでは、リソースをモニターしたり、必要に応じてリソースから取得したデータに基づいてアクションを実行できます。SNMPの詳細は、SNMPによるOracle WebLogic Serverの監視を参照してください。

6.4.7.1 Service BusのSNMPエージェントを操作する場合のガイドライン

Service Busによって生成されたSNMPメッセージをトラップするためにSNMPエージェントを既存のOracle WebLogicドメインに作成してターゲットとして設定できます。SNMPエージェントを作成してターゲットとして設定する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次に関するトピックを参照してください。

- SNMPエージェントの作成

- SNMPエージェントのターゲット指定

- トラップ宛先の作成

ドメイン・スコープまたはサーバー・スコープのSNMPエージェントを作成できます。個々のサーバーではなくドメインへのターゲットとして設定されているドメイン・スコープ・エージェントは後方互換用で、非推奨です。サーバー・スコープ・エージェントを作成することをお薦めします。

Service Bus用にSNMPサーバー・スコープ・エージェントを作成してターゲットとして設定する場合は、次のガイドラインを使用します。

- エージェントのターゲットとしての設定: SNMPエージェントをService Busへのターゲットとして設定する場合は、Service Bus管理サーバーのみへのターゲットとして設定します。管理サーバーへのターゲットとして設定されたエージェントのみがService Busからアラートを受信します。管理対象サーバーへのターゲットとして設定されたエージェントはSNMPメッセージを受信しません。

- トラップ宛先の作成: 宛先の次の設定を入力します。

- 名前: alsbDestination-0

- コミュニティ: weblogic

- 「ホスト」と「ポート」: SNMPマネージャがリスニングするホストとポートを指す値(localhostと163など)を設定します。

6.4.7.2 トラップのリスニングの開始方法

コマンド行ユーティリティを実行して、Service Bus内で生成されたトラップをリスニングできます。

トラップのリスニングを開始するには:

1. コマンド・ウィンドウで、ディレクトリをWL_ORACLE_HOME/server/binに変更し、次のコマンドを実行します。

setWLSEnv.cmd(.sh)

2. 次のJavaコマンドを実行し、トラップをリスニングしてサーバー・コンソールに出力する(トラップのリスニング・ポートに163を使用)、WebLogic Server SNMPコマンド行ユーティリティを起動します。

java weblogic.diagnostics.snmp.cmdline.Manager SnmpTrapMonitor -p 163

これ以降、生成されたトラップは、実行中のコマンド行ユーティリティにアクセスする必要があります。

注意:

Solarisの場合、ポート番号0から1023は、ルート・ログイン用に予約されています。この手順で使用したようにポート161および163を使用すると、ルート・ログインを使用して、サーバーおよびコマンド行ユーティリティを起動する必要があります。この問題を回避し、ルート・ログインを使用しないようにするには、SNMPエージェントとSNMPマネージャのコマンドの両方に、1023より大きいポート番号を指定します。

6.5 XMLスキーマの使用

スキーマとは、基本データや構造化データのタイプを表すものです。XMLスキーマは、XMLビジネス・データが従う必要のあるルールを表すXMLボキャブラリです。XMLスキーマでは、ドキュメントの構造、つまり、ドキュメントに含まれる各要素や属性のデータ型を指定します。

XMLスキーマは、WSDLリソースの参照として、またXPath式で指定した要素をパイプラインで検証するために使用します。詳細は、「コンソールでの検証アクションの追加」を参照してください。

6.5.1 XMLスキーマの作成方法

XMLスキーマは、JDeveloperの標準機能です。XMLスキーマの作成に使用するエディタとツールの詳細は、『Oracle JDeveloperによるアプリケーションの開発』のXMLを使用したアプリケーションの開発に関する項を参照してください。

Oracle Service Busコンソールを使用する場合、XMLスキーマを作成するには、スキーマをインポートするかXMLスキーマ・リソースを作成します。インポートの詳細は、「リソースおよび構成のインポートとエクスポート」を参照してください。XMLスキーマ・リソースを手動で作成する手順は、次のとおりです。

Oracle Service BusコンソールでXMLスキーマを作成するには:

1. プロジェクト・ナビゲータで、新しいXMLスキーマを含めるプロジェクトまたはフォルダを右クリックして、「作成」をポイントし、「リソース」を選択します。「インタフェース」をクリックし、「スキーマ」をクリックして「OK」をクリックします。
「スキーマの作成」ダイアログが表示されます。

2. 次のいずれかを行います:

- 既存のスキーマ・ファイルからリソースを作成するには、「ファイルのアップロード」フィールドの横の「参照」をクリックしてから、使用するファイルに移動してそのファイルを選択します。
「リソース名」フィールドに、ファイル拡張子なしのファイル名が自動的に移入されます。この名前は変更可能です。

- 新しいXMLスキーマを作成するには、XMLスキーマ・リソースの一意の名前を入力します。

3. 必要に応じて、リソースの簡単な説明を入力します。

4. 「作成」をクリックします。
XMLスキーマ要素(定義されている場合)がスキーマ定義エディタに表示されます。

5. スキーマを変更するには、次のように実行します。

a. ツールバーの「ソースの編集」をクリックします。
「ソースの編集」ダイアログが表示されます。

b. アップロードする新しいスキーマ・ファイルを参照して選択するには、「参照」を選択します。

c. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

d. 「保存」をクリックします。

6. スキーマ定義エディタのツールバーで、「保存」をクリックします。

7. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

6.5.2 XMLスキーマの編集方法

XMLスキーマは、JDeveloperの標準機能です。XMLスキーマの編集の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のXMLを使用したアプリケーションの開発に関する項を参照してください。

Oracle Service Busコンソールを使用する場合、次の手順を使用して、XMLスキーマを編集します。

Oracle Service BusコンソールでXMLスキーマを編集するには:

1. プロジェクト・ナビゲータで、編集するXMLスキーマを含むプロジェクトとフォルダを開きます。

2. XMLスキーマ名を右クリックして、「開く」を選択します。

3. ツールバーの「ソースの編集」をクリックします。

「ソースの編集」ダイアログが表示されます。

4. アップロードする新しいXMLスキーマ・ファイルを参照して選択するには、「参照」をクリックします。

5. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

6. 「保存」をクリックします。

7. スキーマ定義エディタのツールバーで、「保存」をクリックします。

8. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

6.5.3 XMLスキーマの削除方法

削除するXMLスキーマをいずれかのリソースが参照する場合、XMLスキーマを削除する前にそれらの参照を削除します。Oracle Service Busコンソールのスキーマ定義エディタでXMLスキーマを開き、右上のツール・アイコンをクリックし、「参照」を選択して、そのスキーマに参照があるかどうかを確認します。JDeveloperで、XMLスキーマを右クリックして、「依存性の参照」を選択します。

XMLスキーマが他のリソースで参照される場合でも、そのスキーマを削除できますが、削除されたリソースに対する未解決の参照が原因で競合が生じることがあります。

XMLスキーマを削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するXMLスキーマを含むプロジェクトとフォルダを開きます。

2. スキーマの名前を右クリックして、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに、スキーマの参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

6.6 XMLドキュメントの操作

XMLドキュメント・リソースは、プロキシ・サービスまたはビジネス・サービスの構成で使用するXMLファイルを格納します。たとえば、JCA準拠のシステムと通信するJCAのプロキシ・サービスまたはビジネス・サービスに必要なTopLinkマッピング・ファイルに対するXMLドキュメント・リソースを作成できます。

JCAサービスの詳細は、「JCAトランスポートとJCAアダプタの使用」を参照してください。

6.6.1 XMLドキュメントの作成方法

XMLドキュメントは、JDeveloperの標準機能です。XMLファイルの作成に使用するエディタとツールの詳細は、『Oracle JDeveloperによるアプリケーションの開発』のXMLを使用したアプリケーションの開発に関する項を参照してください。

Oracle Service Busコンソールを使用する場合、XMLドキュメントを作成するには、インポート機能を使用する方法が最も簡単です。たとえば、JCAリソース(JCAファイル、関連付けられているWSDLファイルおよびTopLinkマッピング・ファイル)をインポートする場合、Service Busによって、マッピング・ファイルからXMLドキュメント・リソースが自動的に生成され、リソース・ファイル間の依存関係が保持されます。インポートの詳細は、「リソースおよび構成のインポートとエクスポート」を参照してください。

一括インポートしない場合、次の手順を使用して手動でXMLドキュメントを作成します。

Oracle Service BusコンソールでXMLドキュメントを作成するには:

1. プロジェクト・ナビゲータで、新しいXMLドキュメントを含めるプロジェクトまたはフォルダを右クリックして、「作成」をポイントし、「リソース」を選択します。「その他」をクリックし、「XMLドキュメント」をクリックして「OK」をクリックします。
「XMLドキュメントの作成」ダイアログが表示されます。

2. 次のいずれかを行います:

- 既存のXMLファイルからリソースを作成するには、「ファイルのアップロード」フィールドの横の「参照」をクリックしてから、使用するXMLファイルに移動してそのファイルを選択します。
「リソース名」フィールドに、ファイル拡張子なしのファイル名が自動的に移入されます。この名前は変更可能です。

- リソースの新しいXMLドキュメントを作成するには、XMLドキュメント・リソースの一意の名前を入力します。

3. 必要に応じて、リソースの簡単な説明を入力します。

4. 「作成」をクリックします。
XMLドキュメントがXMLドキュメント定義エディタに表示されます。

5. XMLコードを変更するには、次のようにします。

a. ツールバーの「ソースの編集」をクリックします。
「ソースの編集」ダイアログが表示されます。

b. アップロードする新しいXMLファイルを参照して選択するには、「参照」をクリックします。

c. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

d. 「保存」をクリックします。

6. XMLドキュメント定義エディタのツールバーで、「保存」をクリックします。

7. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

6.6.2 XMLドキュメントの編集方法

XMLドキュメントは、JDeveloperの標準機能です。XMLファイルの編集の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のXMLを使用したアプリケーションの開発に関する項を参照してください。

Oracle Service Busコンソールを使用する場合、次の手順を使用して、XMLファイルを編集します。

Oracle Service BusコンソールでXMLドキュメントを編集するには:

1. プロジェクト・ナビゲータで、編集するXMLドキュメントを含むプロジェクトとフォルダを開きます。

2. XMLドキュメント名を右クリックして、「開く」を選択します。

3. ツールバーの「ソースの編集」をクリックします。

「ソースの編集」ダイアログが表示されます。

4. アップロードする新しいXMLファイルを参照して選択するには、「参照」をクリックします。

5. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

6. 「保存」をクリックします。

7. XMLドキュメント定義エディタのツールバーで、「保存」をクリックします。

8. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

6.6.3 XMLドキュメントの削除方法

JCAバインドなどのリソースで、削除するXMLドキュメントを参照する場合、XMLドキュメントを削除する前にそれらの参照を削除します。Oracle Service BusコンソールのXMLドキュメント定義エディタでXMLドキュメントを開き、右上のツール・アイコンをクリックし、「参照」を選択して、そのドキュメントに参照があるかどうかを確認します。JDeveloperで、XMLドキュメントを右クリックして、「依存性の参照」を選択します。

XMLドキュメントを削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するXMLドキュメントを含むプロジェクトとフォルダを開きます。

2. ドキュメントの名前を右クリックして、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに、XMLドキュメントの参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

6.7 JARファイルの操作

JAR (Java Archive)ファイルとは、Javaクラスを含むzipファイルです。JARファイルは、コンパイルされたJavaクラスと、プログラムを構成する関連メタデータの保存に使用します。JARファイルはJavaコード要素用のコール可能なプログラム・ライブラリのように機能します(それぞれの要素に対して個別にバインディングを要求するのではなく、単一のコンパイル・リンクが複数要素へのアクセスを提供します)。

Service BusプロジェクトでJARファイルを使用するには、これらをJARリソースにアップロードします。Service BusのJARファイルは次の場所で使用されます。

- Javaコールアウトのアクション

- EJBベースのビジネス・サービス

- JEJBサービス

- Tuxedoベースのプロキシ・サービスとビジネス・サービス

6.7.1 JARファイルの追加方法

JARファイル統合は、JDeveloperの標準機能です。JARファイルとライブラリのService Busプロジェクトへの追加の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のライブラリの管理方法に関する項を参照してください。

Oracle Service Busコンソールを使用する場合、JARファイルを追加するには、これらをService Busプロジェクトにインポートするか、アーカイブ・リソースにアップロードします。インポートの詳細は、「リソースおよび構成のインポートとエクスポート」を参照してください。次の手順を使用して、JARファイルをアーカイブ・リソースにアップロードします。

Oracle Service Busコンソールを使用してJARファイルを追加するには:

1. プロジェクト・ナビゲータで、新しいJARファイルを含めるプロジェクトまたはフォルダを右クリックして、「作成」をポイントし、「リソース」を選択します。「その他」をクリックし、「アーカイブ」をクリックして「OK」をクリックします。
アーカイブの作成ダイアログが表示されます。

2. 「ファイルのアップロード」フィールドの横の「参照」をクリックしてから、アップロードするJARファイルに移動してそのファイルを選択します。
「リソース名」フィールドに、ファイル拡張子なしのファイル名が自動的に移入されます。この名前は変更可能です。

3. 必要に応じて、リソースの簡単な説明を入力します。

4. 「作成」をクリックします。
JARファイルの構成の詳細と依存関係が、アーカイブ定義エディタに表示されます。

5. 依存関係を追加するには、次のようにします。

a. 依存関係表の上にある「追加」をクリックします。
表に新しい行が表示されます。

b. 名前列の新しい行をクリックして、「参照」をクリックします。
「検索と選択」ダイアログが表示されます。

c. ファイル名またはファイルのパスを入力して、「検索」をクリックします。

d. 結果のリストで、依存関係を含むファイルの名前を選択して、「OK」をクリックします。

6. 追加する依存関係ごとに前述の手順を繰り返します。「依存関係」表の上にある上下の矢印を使用して、依存関係のリストを並べ替えます。

7. アーカイブ定義エディタのツールバーで、「保存」をクリックします。

8. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

6.7.2 JARファイルの更新方法

Service BusではJARを編集できないため、アーカイブ・リソースを更新する場合、基本的にリソースに対して新しいバージョンのJARファイルまたは別のJARファイルを指定する必要があります。JARファイル統合は、JDeveloperの標準機能です。JARファイルの更新の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のライブラリの管理方法に関する項を参照してください。

Oracle Service Busコンソールを使用する場合、次の手順を使用して、アーカイブ・リソースでJARファイルを更新します。

警告:

ファイルの新しいバージョンに更新することで、EJBビジネス・サービスで使用されるJARファイルを更新する場合、EJBを再デプロイして、JARファイルを使用するEJBサービスを編集し、JARリソースを再度選択して保存およびアクティブ化します。これにより、新しいJARを使用するようにEJBビジネス・サービスが再パッケージ化されます。

Javaコールアウト・アクションおよびTuxedoベースのサービスは、自動で新しいJARファイルを取得します。

Oracle Service BusコンソールでJARファイルを更新するには:

1. プロジェクト・ナビゲータで、編集するアーカイブ・リソースを含むプロジェクトとフォルダを開きます。

2. アーカイブ・リソース名を右クリックして、「開く」を選択します。

3. JARファイルを更新するには、次のようにします。

a. ツールバーで、「新規JARファイルのアップロード」をクリックします。
「新規JARファイルのアップロード」ダイアログが表示されます。

b. 「参照」をクリックしてから、使用する新しいJARファイルに移動してそのファイルを選択します。

c. 「保存」をクリックします。
アーカイブ定義エディタの情報は、新しいJARファイル構成で更新されます。

4. 依存関係を追加するには、次のようにします。

a. 依存関係表の上にある「追加」をクリックします。
表に新しい行が表示されます。

b. 名前列の新しい行をクリックして、「参照」をクリックします。
「検索と選択」ダイアログが表示されます。

c. ファイル名またはファイルのパスを入力して、「検索」をクリックします。

d. 結果のリストで、依存関係を含むファイルの名前を選択して、「OK」をクリックします。

5. 依存関係を削除するには、依存関係を含む行を「依存関係」表で選択して、「削除」をクリックします。
その行が削除されます。

6. 依存関係を並べ替えるには、表の上にある上下の矢印を使用します。

7. アーカイブ・リソースの更新が完了したら、アーカイブ定義エディタのツールバーで「保存」をクリックします。

8. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

6.7.3 JARファイルの依存関係の変更方法

Service Busには、JARファイルの依存関係を変更できるJARファイル機能が、JDeveloperに追加で用意されています。Oracle Service Busコンソールを使用する場合、「JARファイルの更新方法」の説明に従い、依存関係を変更します。

JDeveloperでJARファイルの依存関係を変更するには:

1. アプリケーション・ナビゲータで、依存関係を変更するJARファイルを見つけます。

2. ファイルの名前を右クリックして、「Service Bus」をポイントし、「Jar依存関係の変更」を選択します。

「Jar依存関係の変更」ダイアログが表示されます。

3. 依存関係を追加するには、JARファイルを「使用可能なJar」ペインから「Jar参照」ペインに移動します。

4. 依存関係を削除するには、JARファイルを「Jar参照」ペインから「使用可能なJar」ペインに移動します。

5. 完了したら「OK」をクリックします。

6.7.4 JARファイルの削除方法

削除するJARファイルをいずれかのリソースが参照する場合、アーカイブ・リソースを削除する前にそれらの参照を削除します。Oracle Service Busコンソールのアーカイブ定義エディタでアーカイブ・リソースを開き、右上のツール・アイコンをクリックし、「参照」を選択して、そのリソースに参照があるかどうかを確認します。JDeveloperで、JARファイルを右クリックして、「依存性の参照」を選択します。

JARファイルが他のリソースで参照される場合でも、そのファイルを削除できますが、削除されたリソースに対する未解決の参照が原因で競合が生じることがあります。

JARファイルを削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するJARファイルのアーカイブ・リソースを含むプロジェクトとフォルダを開きます。

2. リソースの名前を右クリックし、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに、JARファイルの参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

7 システム・リソースの作成と構成

この章では、JNDIプロバイダ、SMTPサーバー、プロキシ・サーバーなどのシステム・リソースを追加および構成する方法について説明します。システム・リソースは、Service Busサービスのすべてのプロジェクトのセッションで再利用できます。

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

- JNDIプロバイダ・リソースの操作

- SMTPサーバー・リソースの操作

- プロキシ・サーバー・リソースの操作

UDDIレジストリは、Service Busのシステム・リソースでもあります。これらについては、「UDDIレジストリの操作」で詳しく説明します。

Oracle Service Busコンソールでは、システム・プロジェクトにシステム・リソースを作成し、このプロジェクトには、デフォルトでシステム・リソースのタイプごとにフォルダが含まれます。JDeveloperでは、「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダにリソースを作成します。ファイル・システムでは、これらのリソースは、JDeveloperアプリケーション・フォルダのSystemサブフォルダにあります。

7.1 JNDIプロバイダ・リソースの操作

JNDIプロバイダ・リソースは、Service BusプロジェクトのJNDIルックアップを実行し、リモート・サーバーへのアクセスに必要なプロトコルとセキュリティの資格証明を提供します。HTTP、HTTPS、t3、t3s、IIOP、IIOPSといった、JNDIプロバイダの任意のプロトコルを使用できます。Service Busでは、使用するアプリケーション・サーバーに応じて、JNDIルックアップの初期コンテキスト・ファクトリ・クラスがいくつかサポートされます。IIOPまたはIIOPSを使用してJBossアプリケーション・サーバーに接続する場合は、com.sun.jndi.cosnaming.CNCtxFactoryクラスを使用してください(JBoss 7.0.0以降ではIIOP/Sはサポートされません)。

7.1.1 JBossアプリケーション・サーバーのクラスパス要件

JBoss初期コンテキスト・ファクトリ・クラスを使用する場合、必ずService Busサーバー・クラスパスにクラスおよび依存クラスを含めます。サーバーのpost-classpathまたはdomain_name/libディレクトリに次のJARファイルが必要です。これらのファイルは、JBossインストールの/clientディレクトリにあります。

- jbossall-client.jar (JBoss 4.xから6.xの場合)

- jboss-client.jar (JBoss 7.xの場合)

- log4j.jar

注意:

クラスパスにクライアントJARファイルを追加しない場合、jboss-client.jar、jboss-common-core.jar、jboss-integration.jar、jboss-logging-spi.jar、jboss-remoting.jar、jboss-security-spi.jar、jboss-serialization.jar、jbosssx-client.jarおよびjnp-client.jarの各ファイルを個別に追加できます。

さらに、次のプロパティを定義して、サーバー・クラスパスまたはライブラリにjboss-ejb-client.propertiesを追加します。

- セキュアでない接続の場合:

- remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false

- remote.connections=<name_of_connection>

- remote.connection.conn1.host=<hostname>

- remote.connection.conn1.port=<port>

- セキュアな接続の場合:

- remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false

- remote.connections=<name_of_connection>

- remote.connection.conn2.host=<hostname>

- remote.connection.conn2.port=<port>

- remote.connection.conn2.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER

- remote.connection.conn2.username=<username>

- remote.connection.conn2.password=<password>

IIOPプロトコルを使用する場合、Oracle WebLogic Serverのクラスパスに次のJARファイルを含めます。これらのファイルは、JBossインストールの/server/all/libにあります(ただし、logkit.jarは/clientディレクトリにあります)。

- jacorb.jar

- avalon-framework.jar

- logkit.jar

7.1.2 JBoss初期コンテキスト・ファクトリの環境プロパティについて

JBossアプリケーション・サーバーにデプロイされたEJBは、EJBおよびJEJBトランスポートを使用して呼び出すことができます。Service Busでは、JBossに対して次の初期コンテキスト・ファクトリ実装をサポートします。JBoss 4.xから6.xの場合、それぞれのクラスに対して環境プロパティを指定できます。

- org.jnp.interfaces.NamingContextFactory

- org.jboss.naming.HttpNamingContextFactory

- org.jboss.security.jndi.LoginInitialContextFactory

JBoss 7.xの場合、org.jboss.naming.remote.client.InitialContextFactoryに対して環境プロパティを指定できます。

次の表では、環境プロパティを示し、これらのプロパティに対するサポートの有無をファクトリ・クラスごとに表しています。これらのクラスと設定可能なプロパティの詳細は、http://docs.jboss.org/jbossas/jboss4guide/r1/html/ch3.chapter.htmlのInitialContextファクトリの命名に関する項を参照してください。

表7-1 JBoss初期コンテキスト・ファクトリの環境パラメータ

パラメータ

NamingContextFactory (4.x-6.x)

HttpNamingContextFactory (4.x-6.x)

LoginInitialContextFactory (4.x-6.x)

InitialContextFactory (7.xのみ)

java.naming.factory.initial

はい

はい

はい

はい

java.naming.provider.url

はい

はい

はい

はい

java.naming.factory.url.pkgs

はい

はい

はい

はい

jnp.socketFactory

はい

いいえ

いいえ

はい

jnp.timeout

はい

いいえ

いいえ

はい

jnp.sotimeout

はい

いいえ

いいえ

はい

java.naming.security.principal

いいえ

いいえ

はい

はい

java.naming.security.credentials

いいえ

いいえ

はい

はい

java.naming.security.protocol

いいえ

いいえ

はい

はい

さらに、JBossクラスタにデプロイされたEJBをルックアップする場合は、次の初期コンテキスト・プロパティが必要となる場合があります。

- jnp.partitionName

- jnp.discoveryGroup

- jnp.discoveryPort

- jnp.discoveryTimeout

- jnp.disableDiscovery

7.1.3 Oracle Service BusコンソールでのJNDIプロバイダ・リソースの表示方法

JNDIプロバイダのフォルダ定義エディタには、現在のセッションで作成したJNDIプロバイダ・リソースがすべて表示されます。このページを使用して、定義したJNDIプロバイダ・リソースをすばやく見つけ、そのリソースにアクセスできます。

コンソールでJNDIプロバイダを表示するには:

1. 「システム」プロジェクトを開き、「JNDIプロバイダ」を右クリックして、「開く」を選択します。
フォルダ定義エディタが開き、既存のJNDIプロバイダ・リソースのリストが表示されます。

2. 特定のJNDIプロバイダを見つけるには、次のようにします。

a. 「JNDIプロバイダ」表の上に問合せフィールドが表示されない場合は、表のツールバーで「例示問合せ」をクリックします。

b. 「名前」列の上に、検索するJNDIプロバイダ・リソースの名前を入力して、[Enter]を押します。
ワイルドカード文字(単一の文字を表す場合は?、複数の文字を表す場合は*)を入力してさらに一般的な検索を実行できます。

c. すべてのJNDIプロバイダを再度表示するには、問合せフィールドを消去して、[Enter]を押します。

3. JNDIプロバイダの構成を表示するには、「JNDIプロバイダ」表でリソース名をクリックします。

4. JNDIプロバイダ・リソースを削除するには、表でリソースの名前を選択して、「削除」をクリックします。「JNDIプロバイダ・リソースの削除方法」を参照してください。

7.1.4 JNDIプロバイダ・リソースの作成方法

JNDIプロバイダ・リソースを作成する場合、リモート・サーバーの接続情報(URL、初期コンテキスト・ファクトリ、セキュリティ資格証明、JBossコンテキスト・ファクトリの環境プロパティ(オプション)など)を指定します。

JNDIプロバイダ・リソースを作成するには:

1. 次のいずれかを行います:

- JDeveloperを使用する場合、「アプリケーション・リソース」パネルを開き、「Service Busシステム・リソース」を右クリックして「新規」をポイントし、「JNDIプロバイダ」を選択します。

ヒント:

JNDIプロバイダ・リソースをプロジェクトに直接作成するには(これによりプロジェクト・レベルのリソースになる)、プロジェクトを右クリックして「新規」をポイントし、「JNDIプロバイダ」を選択します。

- Oracle Service Busコンソールを使用する場合、「システム」プロジェクトを開き、「JNDIプロバイダ」を右クリックして「作成」をポイントし、「JNDIプロバイダの作成」を選択します。

「JNDIサービスの作成」ダイアログが表示されます。

2. リソースの名前と必要に応じて説明を入力し、「終了」または「作成」をクリックします。
JNDIプロバイダ定義エディタが表示されます。

3. protocol://hostname:portの形式でJNDIプロバイダのURLを入力します。
クラスタの場合、protocol://hostname:ms1port, hostname:ms2portの形式で管理対象サーバーのカンマ区切りリストを使用します。

4. 「初期コンテキスト・ファクトリ」フィールドで、作成するJNDIプロバイダの初期コンテキスト・ファクトリ・クラス名を選択します。

5. 「JNDIリクエスト・タイムアウト」フィールドに、JNDIリクエスト・タイムアウトをミリ秒単位で入力します。

6. JNDIオブジェクトのローカル・キャッシュを有効にするには、「JNDIキャッシュ」を選択します。

7. JBoss初期コンテキスト・ファクトリの環境プロパティを追加するには、「環境パラメータ」表の上にある「追加」アイコンをクリックして、表示された新しい行にパラメータ名と値を入力します。
パラメータの詳細は、「JBoss初期コンテキスト・ファクトリの環境プロパティについて」を参照してください。

8. 目的のJNDIプロバイダにアクセスするためにユーザー名およびパスワードが必要な場合、「ユーザー名」フィールドにユーザー名を入力して、関連するパスワードを「パスワード」および「パスワードの確認」フィールドに入力します。

9. 「保存」をクリックします。

10. Oracle Service Busコンソールを使用している場合、右上のツールバーで次のいずれかを実行します。

- JNDI接続とローカルにキャッシュされたオブジェクトを破棄するためにJNDIコンテキストをリセットするには、「リセット」アイコンをクリックします。

- JNDIプロバイダが接続を確立でき、JNDIコンテキストを取得できるかどうかをテストするには、「テスト」アイコンをクリックします。

11. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

7.1.5 JNDIプロバイダ・リソースの編集方法

JNDIプロバイダ・リソースを作成すると、その説明とほとんどのJNDIプロパティを変更できます。

JNDIプロバイダ・リソースを編集するには:

1. 編集するリソースを含むプロジェクトとフォルダを開きます。これは次の場所のいずれかになります。

- JDeveloperの「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダ。

- JDeveloperのアプリケーション・ナビゲータでJNDIプロバイダ・リソースが配置されるService Busプロジェクトまたはフォルダ。

- Oracle Service Busコンソールの「システム」プロジェクトの「JNDIプロバイダ」フォルダ。

2. JNDIプロバイダ名を右クリックして、「開く」を選択します。
JNDIプロバイダ定義エディタが表示されます。

3. 「JNDIプロバイダ・リソースの作成方法」で説明している任意のフィールドを変更します。これらのフィールドについては、オンライン・ヘルプでさらに詳細に説明しています。

注意:

「新規パスワード」フィールドは、JNDIプロバイダがユーザー名とパスワードで構成されなかった場合のみ編集できます。

4. 変更が終了したら、「保存」をクリックします。

5. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

7.1.6 JNDIプロバイダ・リソースの削除方法

JNDIプロバイダ・リソースを削除すると、他のService Busリソースによるリソースの参照は機能しなくなります。リソースでJNDIプロバイダを参照しているかどうかを判断するには、JNDIプロバイダ定義エディタでJNDIプロバイダ・リソースを開き、右上のツール・アイコンをクリックして「参照」を選択します。JDeveloperでは、JNDIプロバイダを右クリックして、「依存性の参照」を選択します。

JNDIプロバイダ・リソースを削除するには:

1. 編集するリソースを含むプロジェクトとフォルダを開きます。これは次の場所のいずれかになります。

- JDeveloperの「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダ。

- JDeveloperのアプリケーション・ナビゲータでJNDIプロバイダ・リソースが配置されるService Busプロジェクトまたはフォルダ。

- Oracle Service Busコンソールの「システム」プロジェクトの「JNDIプロバイダ」フォルダ。

2. JNDIプロバイダ・リソースを右クリックして、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに、リソースの参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

7.2 SMTPサーバー・リソースの操作

SMTPサーバー・リソースは、SMTPサーバーの接続プロパティを定義し、電子メール・トランスポートに基づいてアラート宛先リソースおよびビジネス・サービスを構成するときに使用されます。SMTPサーバー・グローバル・リソースはSMTPサーバーのアドレス、ポート番号、および認証資格証明(必要な場合)を取り込みます。この認証資格証明はサービス・アカウントとして格納されるのではなく、インラインで格納されます。アラート宛先の詳細は、「アラート宛先の操作」を参照してください。

7.2.1 Oracle Service BusコンソールでのSMTPサーバー・リソースの表示方法

SMTPサーバーのフォルダ定義エディタには、現在のセッションで作成したSMTPサーバー・リソースがすべて表示されます。このページを使用して、定義したSMTPサーバー・リソースをすばやく見つけ、そのリソースにアクセスできます。

コンソールでSMTPサーバーを表示するには:

1. 「システム」プロジェクトを開き、「SMTPサーバー」を右クリックして、「開く」を選択します。
フォルダ定義エディタが開き、既存のSMTPサーバー・リソースのリストが表示されます。

2. 特定のSMTPサーバー・リソースを見つけるには、次のようにします。

a. 「SMTPサーバー」表の上に問合せフィールドが表示されない場合は、表のツールバーで「例示問合せ」をクリックします。

b. 「名前」列の上に、検索するSMTPサーバー・リソースの名前を入力して、[Enter]を押します。
ワイルドカード文字(単一の文字を表す場合は?、複数の文字を表す場合は*)を入力してさらに一般的な検索を実行できます。

c. すべてのSMTPサーバーを再度表示するには、問合せフィールドを消去して、[Enter]を押します。

3. SMTPサーバーの構成を表示するには、「SMTPサーバー」表でリソース名をクリックします。

4. SMTPサーバー・リソースを削除するには、表でリソースの名前を選択して、「削除」をクリックします。「SMTPサーバー・リソースの削除方法」を参照してください。

7.2.2 SMTPサーバー・リソースの作成方法

SMTPサーバー・リソースを作成する場合、URLやポート番号といったサーバーの接続情報を指定します。セキュリティ情報は、サーバーで認証が必要な場合のみ必須です。

SMTPサーバー・リソースを作成するには:

1. 次のいずれかを行います。

- JDeveloperを使用する場合、「アプリケーション・リソース」パネルを開き、「Service Busシステム・リソース」を右クリックして「新規」をポイントし、「SMTPサーバー」を選択します。

注意:

SMTPサーバー・リソースをプロジェクトに直接作成するには(これによりプロジェクト・レベルのリソースになる)、プロジェクトを右クリックして「新規」をポイントし、「SMTPサーバー」を選択します。

- Oracle Service Busコンソールを使用する場合、「システム」プロジェクトを開き、「SMTPサーバー」を右クリックして「作成」をポイントし、「SMTPサーバーの作成」を選択します。

「SMTPサーバーの作成」ダイアログが表示されます。

2. リソースの名前と必要に応じて説明を入力します。

3. コンソールを使用している場合、SMTPサーバーのURLとポート番号を入力します。

4. 「終了」または「作成」をクリックします。

SMTPサーバー定義エディタが表示されます。

5. JDeveloperを使用している場合、URLとポート番号を入力してSMTPサーバーにアクセスします。

6. SMTPサーバーへのアクセスで認証が必要な場合、「ユーザー名」フィールドにユーザー名を入力して、対応するパスワードを「パスワード」および「パスワードの確認」フィールドに入力します。

7. 「保存」をクリックします。

8. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

7.2.3 デフォルトのSMTPサーバーの構成方法

Oracle Service Busコンソールで、ドメインのデフォルト・サーバーとして構成されたSMTPサーバーの1つを指定できます。

デフォルトのSMTPサーバーを構成するには:

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. プロジェクト・ナビゲータで、「システム」→「SMTPサーバー」を開きます。

3. デフォルトのサーバーにするSMTPサーバーの名前を右クリックし、「デフォルトに設定」を選択します。

4. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

7.2.4 SMTPサーバー・リソースの編集方法

SMTPサーバー・リソースを作成すると、その説明とほとんどのサーバー・プロパティを変更できます。

SMTPサーバー・リソースを編集するには:

1. 編集するリソースを含むプロジェクトとフォルダを開きます。これは次の場所のいずれかになります。

- JDeveloperの「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダ。

- JDeveloperのアプリケーション・ナビゲータでSMTPサーバー・リソースが配置されるService Busプロジェクトまたはフォルダ。

- Oracle Service Busコンソールの「システム」プロジェクトの「SMTPサーバー」フォルダ。

2. SMTPサーバー名を右クリックして、「開く」を選択します。

SMTPサーバー定義エディタが表示されます。

3. 「SMTPサーバー・リソースの作成方法」で説明している任意のフィールドを変更します。これらのフィールドについては、オンライン・ヘルプでさらに詳細に説明しています。

4. 変更が終了したら、「保存」をクリックします。

5. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

7.2.5 SMTPサーバー・リソースの削除方法

SMTPサーバー・リソースを削除すると、他のService Busリソースによるリソースの参照は機能しなくなります。リソースでSMTPサーバーを参照しているかどうかを判断するには、SMTPサーバー定義エディタでSMTPサーバー・リソースを開き、右上のツール・アイコンをクリックして「参照」を選択ます。JDeveloperでは、SMTPサーバーを右クリックして、「依存性の参照」を選択します。

SMTPサーバー・リソースを削除するには:

1. 編集するリソースを含むプロジェクトとフォルダを開きます。これは次の場所のいずれかになります。

- JDeveloperの「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダ。

- JDeveloperのアプリケーション・ナビゲータでSMTPサーバー・リソースが配置されるService Busプロジェクトまたはフォルダ。

- Oracle Service Busコンソールの「システム」プロジェクトの「SMTPサーバー」フォルダ。

2. SMTPサーバー・リソースを右クリックして、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに、リソースの参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

7.3 プロキシ・サーバー・リソースの操作

プロキシ・サーバー・リソースは、ビジネス・サービスのHTTPトランスポートを構成する場合に使用されます。詳細は、「HTTPトランスポートおよびポーラー・トランスポートの使用」を参照してください。

- SSLでのプロキシ・サーバーの使用

- Oracle Service Busコンソールでのプロキシ・サーバー・リソースの表示方法

- プロキシ・サーバー・リソースの作成方法

- プロキシ・サーバー・リソースの編集方法

- プロキシ・サーバー・リソースの削除方法

7.3.1 SSLでのプロキシ・サーバーの使用

プロキシ・サーバーを構成する際、ホスト名またはIPアドレスに加えて、サーバーのクリア・テキストまたはSSLポート番号を指定できます。プロキシ・サーバー・リソース構成で指定されたポートは、バック・エンド・サービスのポートではなく、Webプロキシ・サーバーの実際の物理的なポートに対応するものなので注意してください。ただし、ビジネス・サービスでのエンドポイント構成はバック・エンド・サービスの実際のエンドポイントに対応します。これはHTTP CONNECTコマンドを使用したSSL/TLSトンネリングの場合にも当てはまります。

Webプロキシ・サーバーには、クリア・テキスト・ソケットとSSLソケットの両方を使用したHTTP CONNECTをサポートするサーバーもあれば、クリア・テキスト・ソケットのみを使用したHTTP CONNECTをサポートするサーバーもあります。たとえば、Oracle iPlanet Web Proxy Server 4.0は、クリア・テキスト・ソケットおよびSSLソケットを使用したHTTP CONNECTをサポートしますが、プロキシ・サーバー・モードでのApache Web Server 2.2は、クリア・テキスト・ソケットのみを使用したHTTP CONNECTをサポートします。

通常は、SSL/TLSトンネリングをサポートする場合、物理的なプロキシ・サーバーにサーバーまたは認証局(CA)の証明書をインストールする必要はありません。かわりに、Webプロキシ・サーバーはセキュアなソケットを開くために、コール元(この場合、Service Bus)から受信した証明書を使用します。同様に、ビジネス・アプリケーションをホストするサーバーがクライアントの証明書を必要とする場合は、プロキシ・サービスをホストするサーバー(Service Bus)の証明書が認証に使用されます。

7.3.2 Oracle Service Busコンソールでのプロキシ・サーバー・リソースの表示方法

プロキシ・サーバーのフォルダ定義エディタには、現在のセッションで作成したプロキシ・サーバー・リソースがすべて表示されます。このページを使用して、定義したプロキシ・サーバー・リソースをすばやく見つけ、そのリソースにアクセスできます。

コンソールでプロキシ・サーバーを表示するには:

1. 「システム」プロジェクトを開き、「プロキシ・サーバー」を右クリックして、「開く」を選択します。
フォルダ定義エディタが開き、既存のプロキシ・サーバー・リソースのリストが表示されます。

2. 特定のプロキシ・サーバー・リソースを見つけるには、次のようにします。

a. 「プロキシ・サーバー」表の上に問合せフィールドが表示されない場合は、表のツールバーで「例示問合せ」をクリックします。

b. 「名前」列の上に、検索するプロキシ・サーバー・リソースの名前を入力して、[Enter]を押します。
ワイルドカード文字(単一の文字を表す場合は?、複数の文字を表す場合は*)を入力してさらに一般的な検索を実行できます。

c. すべてのプロキシ・サーバーを再度表示するには、問合せフィールドを消去して、[Enter]を押します。

3. プロキシ・サーバーの構成を表示するには、「プロキシ・サーバー」表でリソース名をクリックします。

4. プロキシ・サーバー・リソースを削除するには、表でリソースの名前を選択して、「削除」をクリックします。「プロキシ・サーバー・リソースの削除方法」を参照してください。

7.3.3 プロキシ・サーバー・リソースの作成方法

プロキシ・サーバー・リソースを作成する場合、サーバー名やポート番号といったサーバーの接続情報を指定します。セキュリティ情報は、サーバーで認証が必要な場合のみ必須です。

各プロキシ・サーバー・リソースに複数のプロキシ・サーバーを構成できます。この場合、Service Busは、ロード・バランシングを実行でき、リソースのフォルト・トレランス機能を提供できます。

プロキシ・サーバー・リソースを作成するには:

1. 次のいずれかを行います:

- JDeveloperを使用する場合、「アプリケーション・リソース」パネルを開き、「Service Busシステム・リソース」を右クリックして「新規」をポイントし、「プロキシ・サーバー」を選択します。

注意:

プロキシ・サーバー・リソースをプロジェクトに直接作成するには(これによりプロジェクト・レベルのリソースになる)、プロジェクトを右クリックして「新規」をポイントし、「プロキシ・サーバー」を選択します。

- Oracle Service Busコンソールを使用する場合、「システム」プロジェクトを開き、「プロキシ・サーバー」を右クリックして「作成」をポイントし、「プロキシ・サーバーの作成」を選択します。

「プロキシ・サーバーの作成」ダイアログが表示されます。

2. リソースの名前と必要に応じて説明を入力します。

3. 「終了」または「作成」をクリックします。
プロキシ・サーバー定義エディタが表示されます。

4. プロキシ・サーバーを定義するには、「ホスト-ポート・パラメータ」表で次のようにします。

a. 表の上にある「追加」アイコンをクリックします。
表に新しい行が表示されます。

b. 「ホスト」フィールドに、プロキシ・サーバーのホスト名またはIPアドレスを入力します。

c. 「ポート」フィールドに、プロキシ・サーバーのポート番号を入力します。

d. ホスト名とポート番号をリストから削除するには、削除するサーバーを含む行を表で選択して、「削除」アイコンをクリックします。

5. プロキシ・サーバーへのアクセスで認証が必要な場合、「ユーザー名」フィールドにユーザー名を入力して、対応するパスワードを「パスワード」および「パスワードの確認」フィールドに入力します。

6. 「保存」をクリックします。

7. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

7.3.4 プロキシ・サーバー・リソースの編集方法

プロキシ・サーバー・リソースを作成すると、その説明とセキュリティ・オプションを変更でき、プロキシ・サーバーの変更、追加およびホスト・リストからの削除を行うことができます。

プロキシ・サーバー・リソースを編集するには:

1. 編集するリソースを含むプロジェクトとフォルダを開きます。これは次の場所のいずれかになります。

- JDeveloperの「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダ。

- JDeveloperのアプリケーション・ナビゲータでプロキシ・サーバー・リソースが配置されるService Busプロジェクトまたはフォルダ。

- Oracle Service Busコンソールの「システム」プロジェクトの「プロキシ・サーバー」フォルダ。

2. プロキシ・サーバー名を右クリックして、「開く」を選択します。

プロキシ・サーバー定義エディタが表示されます。

3. 「プロキシ・サーバー・リソースの作成方法」で説明してる任意のフィールドを変更します。これらのフィールドについては、オンライン・ヘルプでさらに詳細に説明しています。

4. 変更が終了したら、「保存」をクリックします。

5. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

7.3.5 プロキシ・サーバー・リソースの削除方法

プロキシ・サーバー・リソースを削除すると、他のService Busリソースによるリソースの参照は機能しなくなります。リソースでプロキシ・サーバーを参照しているかどうかを判断するには、プロキシ・サーバー定義エディタでプロキシ・サーバー・リソースを開き、右上のツール・アイコンをクリックして「参照」を選択ます。JDeveloperでは、プロキシ・サーバーを右クリックして、「依存性の参照」を選択します。

プロキシ・サーバー・リソースを削除するには:

1. 編集するリソースを含むプロジェクトとフォルダを開きます。これは次の場所のいずれかになります。

- JDeveloperの「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダ。

- JDeveloperのアプリケーション・ナビゲータでプロキシ・サーバー・リソースが配置されるService Busプロジェクトまたはフォルダ。

- Oracle Service Busコンソールの「システム」プロジェクトの「プロキシ・サーバー」フォルダ。

2. プロキシ・サーバー・リソースを右クリックして、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに、リソースの参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

8 プロキシ・サービスの作成と構成

この章では、Service BusコンソールとOracle JDeveloperを使用して、プロキシ・サービスを作成、構成および管理する方法について説明します。Service Busのプロキシ・サービスとビジネス・サービスを使用すると、エンタープライズ全体でのサービスの管理、メッセージの変換およびメッセージのルーティングを行うことができます。

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

- プロキシ・サービスの概要

- プロキシ・サービスの保護

- サービス・レベル合意のアラート・ルール

- Webサービス相互運用性への準拠

- プロキシ・サービスの作成

- プロキシ・サービスの構成

- プロキシ・サービスの削除

- JDeveloperでのWSILによるプロキシ・サービスの使用

8.1 プロキシ・サービスの概要

プロキシ・サービスは、サービス・コンシューマがService Bus経由でバックエンド・サービスに接続するために使用するインタフェースを提供します。プロキシ・サービスは、Service Busがローカルにホストする仲介Webサービスの定義です。Service Busでは、プロキシ・サービスを使用してビジネス・サービス(エンタープライズWebサービスやデータベースなど)とサービス・クライアント(プレゼンテーション・アプリケーションやその他のビジネス・サービスなど)との間でメッセージをルーティングします。

プロキシ・サービスは、WSDL (Web Services Description Language)またはWADL (Web Application Definition Language)に関するインタフェースと使用するトランスポートを定義します。プロキシ・サービスでは、通信インタフェース、トランスポートのタイプ、トランスポート設定、セキュリティ設定および関連付けられるメッセージ処理ロジックを定義します。また、メッセージ・フロー定義またはパイプラインを使用して、メッセージを変換して1つ以上のビジネス・サービスにルーティングします。パイプラインでは、Service Busを介したメッセージ・フローでメッセージを処理する方法を決定するロジックを定義します。プロキシ・サービスがWSDLドキュメントに基づいている場合、構成にはWSDLポートまたはWSDLバインディングも含まれます

UDDIレジストリ、SOA Oracle Metadata Services (MDS)レジストリ、アプリケーション・サーバー、またはファイル・システムからインポートしたドキュメントを含む、既存のWSDLおよびWADLドキュメントをプロキシ・サービスの基盤にすることもできます。Service Busでは、RESTバインディングを使用するプロキシ・サービスもサポートしています(「Oracle Service BusでのRESTサービスの作成」を参照)。これらのプロキシ・サービスはWADLドキュメントに基づいています。RESTサービスは、Service BusコンソールまたはJDeveloperを使用して作成できます。

8.1.1 プロキシ・サービスの定義

各プロキシ・サービスは、WSDL Webサービス、RESTサービスまたはService Busトランスポートのいずれに基づくかで定義されます。WSDLベースのサービスは、WSDLドキュメントでインタフェースが記述されるSOAPプロキシ・サービスまたはXMLプロキシ・サービスです。RESTサービスは次のいずれかの方法で定義されます。型付きRESTサービスは、設計時に一部の情報(操作)が既知である場合にWADLドキュメントに基づき、型なしRESTサービスは、特定のWADLドキュメントまたはスキーマにバインドされません(設計時に操作が既知でない場合があります)。トランスポート型のサービスは、JCAトランスポートなどのService Busトランスポートに基づくプロキシ・サービスで、Oracle JCA準拠アダプタにプロキシ・サービスを構成するためのサポートが提供されます。これにはHTTPトランスポートを使用するRESTプロキシ・サービスも含まれます。各タイプのプロキシ・サービスでは、その定義に固有のトランスポート・プロトコルがサポートされます。Service Busは、いくつかの標準トランスポート・プロトコルとカスタム・トランスポートをサポートします。

プロキシ・サービスの作成ウィザードまたはJDeveloperのService Bus概要エディタを使用して、WSDLベース、RESTまたはトランスポート型のサービスでプロキシ・サービスを作成できます。Service Bus概要エディタを使用すると、JCAアダプタからプロキシ・サービスを直接生成して、そのアダプタ・タイプにすでに構成されているプロキシ・サービスを作成できます。ウィザードとエディタのどちらでも、ビジネス・サービスとパイプラインをプロキシ・サービスとして公開できます。

8.1.2 プロキシ・サービスのサービス・タイプとプロトコル

Service Busは、従来のWebサービス(WSDLファイルでXMLまたはSOAPバインディングを使用)から非XMLサービス(汎用)サービスまで、多くのサービス・タイプに対応しています。トランスポート型のプロキシ・サービスを作成する場合、サービス・タイプを指定して構成することで、サービスをさらに定義する必要もあります。選択できるサービス・タイプは、サービス・エンドポイントとの通信に使用するトランスポートに基づいて制限されます。各サービス・タイプでサポートされるトランスポートの詳細は、「トランスポート、アダプタおよびバインディング」を参照してください。

プロキシ・サービスのサービス・タイプは、次のいずれかになり、そのサービスが処理するメッセージのタイプで識別されます。

- WSDLベース・サービス: このサービス・タイプは、既存のWSDLドキュメント、またはプロキシ・サービスの作成と同時に作成したWSDLドキュメントから生成されます。WSDLベースのサービスを作成する際は、使用するポートまたはバインディングを指定する必要があります。

- メッセージ・サービス: このサービス・タイプは、あるデータ型のメッセージを受信し、レスポンスとして別のデータ型のメッセージを返すことができます。サポートされるデータ型には、XML、Message Format Language (MFL)、テキスト、型なし、バイナリ、Java、インタフェースがWSDLで記述されていない添付などがあります。

- 任意のSOAPサービス: このサービス・タイプは、SOAPメッセージを交換します。SOAPメッセージは、<soap:Envelope>要素内のheader変数およびbody変数のコンテンツをラップすることで作成されます。body変数に参照XMLが格納されている場合、メッセージは現状のまま送信されます。つまり、参照されているコンテンツはメッセージに置き換えられません。attachments変数で添付が定義されている場合は、メイン・メッセージと添付データからMIMEパッケージが作成されます。各添付部分のコンテンツの処理方法は、メッセージング・サービスのコンテンツの処理方法に類似しています。

- 任意のXMLサービス(非SOAP): このサービス・タイプでは、XMLベースのサービスへのメッセージはXMLですが、プロキシ・サービスの構成で許可された任意の型を使用できます。添付を含むメッセージの場合、そのコンテンツは、プライマリXMLペイロードをその一部(通常は最初の部分、または最上位のContent-Typeヘッダーで指定される部分)として含むMIMEパッケージです。

- RESTサービス: このサービス・タイプは、RESTバインディングに基づき、既存のWADLから生成するか、プロキシ・サービスの作成と同時に作成したWADLから作成するか(型付きREST)、またはWADLまたはスキーマなしで作成(型なしREST)できます。詳細は、「Oracle Service BusでのRESTサービスの作成」を参照してください。

8.1.3 SOAPまたは任意のXMLサービス・タイプを使用する場合

1つのポートのみを公開してクライアントに様々なエンタープライズ・アプリケーションを提供する場合は、任意のSOAPまたは任意のXMLサービス・タイプを使用します。任意のSOAPの場合、SOAP 1.1とSOAP 1.2のどちらであるかを指定する必要があります。

8.1.4 メッセージ・サービス・タイプを使用する場合

リクエスト・メッセージまたはレスポンス・メッセージのいずれかがXML以外である場合、メッセージング・サービス・タイプを使用する必要があります。Service Busでは、誤りのあるSOAPヘッダーのチェックは自動では行われません。ただし、XQuery条件式と検証アクションを使用して、このタイプのチェックをパイプラインで明示的に実行できます。検証アクションの詳細は、「コンソールでの検証アクションの追加」を参照してください。条件付きXQuery式の詳細は、「Oracle Service Busコンソールでの式エディタの操作」を参照してください。

8.1.5 プロキシ・サービス・タイプのバインディング定義とランタイム変数

各プロキシ・サービス・タイプは、その定義やタイプを問わず、同じパターンに従ってモデル化されます。各サービス・タイプでは、次の特徴を定義する必要があります。

- バインディング定義

- ランタイム構成

- ランタイム変数($operation、$body、$header、$attachments)

8.1.5.1 WSDLサービス・タイプ

ランタイム変数

- SOAPベースのWSDLサービスの場合、操作選択アルゴリズムに基づいて$operationが初期化される点を除き、変数は任意のSOAPサービス・タイプと同様です。

- XMLベースのWSDLサービスの場合、操作選択アルゴリズムに基づいて$operationが初期化される点を除き、変数は任意のXMLサービス・タイプと同様です。

8.1.5.2 メッセージング・サービス・タイプ

バインディング定義

メッセージ・サービス用のバインディング定義は、交換されるメッセージのコンテンツ・タイプの構成で構成されています。レスポンスのコンテンツ・タイプは、リクエストの場合と同じである必要はないため、レスポンスは個別に構成されます。たとえば、サービスでMFLメッセージを受け取り、XML確認受信を返すことができます。レスポンスは「なし」にも設定できます。

定義上、メッセージング・ベースのサービスにはWSDL定義はありません。これらのサービスのWSDLドキュメントをリクエストすることはできません。リクエストおよびレスポンスから選択するコンテンツ・タイプは、次のとおりです。

- なし

- バイナリ

- テキスト

- MFL

- XML

- Java

注意:

- サービスからの成功または失敗のメッセージをコール元のクライアントに伝搬するために、パイプラインで返信アクションを使用している場合は、「なし」以外のオプションを選択します。「なし」オプションは、返信をブロックします。

- メッセージ・サービス・タイプの電子メール、ファイル、FTPおよびSFTPトランスポート・プロキシ・サービスは、一方向のメッセージングのみをサポートするため、レスポンス・メッセージはありません。レスポンス・メッセージのコンテンツ・タイプは「なし」にします。

ランタイム変数

このサービス・タイプはメッセージ・ベースです。Webサービスには、複数の操作という概念はありません。したがって、$operation変数は空のままになります。$body変数には、<soap:Body>要素内にラップされた着信メッセージが保持されますSOAP 1.1プロキシ・サービスの場合、$bodyではSOAP 1.1のネームスペースBodyを使用し、SOAP 1.2プロキシ・サービスの場合はSOAP 1.2のネームスペースBodyを使用します。$header変数はこのサービス・タイプには適用されず、デフォルト値に設定されます。メッセージに添付ファイルがある場合は、$attachments変数に格納されます。

メッセージ・コンテキスト変数の詳細は、「メッセージ関連の変数」および「ディスパッチするメッセージの作成」を参照してください。

8.1.5.3 任意のSOAPサービス

バインディング定義

このサービス・タイプで定義する情報は、WSDLバインド定義に関係なく、サービスでSOAPメッセージを受信または送信するということのみです。このタイプのバインディング構成が存在しないため、このタイプとメッセージのコンテンツ・タイプの組合せから、メッセージに添付ファイルがあるかどうかを十分判別できます。定義上、「任意の」サービス(SOAPまたはXML)にはWSDL定義はありません。これらのサービスのWSDLドキュメントを生成または表示することはできません。

ランタイム変数

$body変数と$header変数に、受信SOAPメッセージの<soap:Body>と<soap:Header>がそれぞれ保持されます(SOAP 1.1プロキシの場合、$bodyと$headerではSOAP 1.1ネームスペース本体とネームスペースを使用し、SOAP 1.2プロキシではSOAP 1.2ネームスペース本体とネームスペースを使用します)。SOAPメッセージに添付ファイルがある場合は、$attachments変数に格納されます。ポート・タイプを定義しないため、$operation変数はこのサービス・タイプには適用されません。

メッセージ・コンテキスト変数の詳細は、「メッセージ関連の変数」および「ディスパッチするメッセージの作成」を参照してください。

8.1.5.4 任意のXMLサービス

バインディング定義

このサービス・タイプで定義する情報は、WSDLバインド定義に関係なく、サービスでXMLメッセージを受信または送信するということのみです。このタイプのバインディング構成が存在しないため、このタイプとメッセージのコンテンツ・タイプの組合せから、メッセージに添付ファイルがあるかどうかを十分判別できます。

定義上、「任意の」サービス(SOAPまたはXML)にはWSDL定義はありません。これらのサービスのWSDLドキュメントをリクエストすることはできません。

ランタイム変数

$body変数には、<soap:Body>要素内にラップされた受信XMLメッセージが保持されます(SOAP 1.1プロキシの場合、$bodyと$headerではSOAP 1.1ネームスペース本体とネームスペースを使用し、SOAP 1.2プロキシではSOAP 1.2ネームスペース本体とネームスペースを使用します)。メッセージに添付ファイルがある場合は、$attachments変数に格納されます。$header変数はこのサービス・タイプには適用されず、デフォルト値に設定されます。ポート・タイプを定義しないため、$operation変数はこのサービス・タイプには適用されません。

メッセージ・コンテキスト変数の詳細は、「メッセージ関連の変数」および「ディスパッチするメッセージの作成」を参照してください。

8.1.6 プロキシ・サービスのトランスポート・プロトコル構成

プロキシ・サービスの構成の大部分には、トランスポート・プロトコルが関与します。トランスポートは、外部システムとプロキシ・サービスとの間の通信レイヤーであり、Service Busへのエントリ・ポイントとして機能します。プロキシ・サービスに使用可能なトランスポート・プロトコルは、作成するサービス・タイプによって異なります。それぞれのトランスポート・プロトコルには独自の構成要件があります。トランスポート・プロトコルとその構成要件の詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照し、関連する特定のプロトコルのリンクをクリックしてください。

トランスポートとWSDLファイルに基づいて、トランスポート・モードが自動的に選択されますが、これは$inboundまたは$outbound変数で上書きできます。

8.2 プロキシ・サービスの保護

プロキシ・サービスは、Oracle Web Services Manager (WSM)ポリシー、認証マッピング、サービス・キー・プロバイダなど、複数の方法で保護できます。サービス・プロバイダが必要となるのは、プロキシ・サービスがクライアント証明書認証を必要とするHTTPSサービスにメッセージをルーティングする場合です。また、一部のメッセージ・レベルのセキュリティ・シナリオで必要となる場合もあります。サービス・アカウントは、ビジネス・サービスに接続するときに認証を提供するために作成できます。これは要求されるユーザー名とパスワードのペアの別名リソースとして機能します。WebLogic Serverを使用して、資格レベルの検証を要求するビジネス・サービスのセキュリティ資格を直接管理できます。

プロキシ・サービスの保護の詳細は、「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。

8.3 サービス・レベル合意のアラート・ルール

サービス・レベル合意(SLA)のアラート・ルールでは、アラートの生成条件が定義されます。これらの条件は、通常、Service Busアプリケーションまたは特定のサービス・コンポーネントの全体的なヘルスのインジケータになります。プロキシ・サービスに対するSLAアラート・ルールの定義の詳細は、『Oracle Service Busの管理』のサービス・レベル合意のアラート・ルールの作成に関する項を参照してください。

8.4 Webサービス相互運用性への準拠

WS-I準拠(SOAP 1.1サービスの場合のみ)を適用し、このプロキシ・サービスによってコールされる操作の決定に使用される選択アルゴリズムを選択するようにプロキシ・サービスを構成できます。このオプションは、WSDLファイルに基づいて定義されたSOAPサービスまたはXMLサービスでのみ使用できます。WSDL仕様では、受信するSOAPメッセージのタイプに基づいて呼び出す操作を計算するデフォルトのアルゴリズムが定義されています。ただし、その他の手段に基づいて操作を選択しなければならない場合もあります(パフォーマンスや、署名および暗号化に問題があったり、デフォルトのアルゴリズムが使用できない場合など)。

Service Busには、その他のアルゴリズムが用意されています。これらはそれぞれ同じパターンに従っており、式の評価に基づいて値を取得し、その値を使用して静的な表から対応する操作をルックアップします。

通常、Service Busは、インバウンド・メッセージが不明なデータで処理を判断できない場合や、データが有効な処理に対応していない場合にも、柔軟に対処します。どちらの場合も、$operationは空になります。Service Busでは、このようなメッセージをすべて拒否するのではなく、コンテキスト内のoperation変数を初期化せずに、メッセージの処理を続行します。ただし、プロキシ・サービスがWSDLベースで、次の条件の1つ以上が当てはまる場合は、セキュリティ要件が適用されます。

- WSDLファイルにWS-Securityポリシーが存在し、プロキシがアクティブな仲介になっています。

- プロキシにメッセージ・レベルのカスタム認証(カスタム・トークンまたはユーザー名/パスワード)が存在します。

これらの条件に該当する場合、操作選択アルゴリズムが有効な操作名を返すかどうかを確認する実行時チェックが行われます。操作選択アルゴリズムでnullまたはWSDLファイルに存在しない操作が返された場合、メッセージは拒否され、エラーが発生します。

8.5 プロキシ・サービスの作成

この項では、JDeveloperまたはOracle Service Busコンソールを使用して、プロキシ・サービスを作成する方法について説明します。Service Busアプリケーションおよびプロジェクトの作成の詳細は、「JDeveloperでのService Busアプリケーションおよびプロジェクトの作成」または「リソースの新しいプロジェクトおよびフォルダの作成方法」(コンソールの場合)を参照してください。JDeveloperでのプロジェクト、アプリケーションおよびその他コンポーネントの操作については、『Oracle JDeveloperユーザーズ・ガイド』を参照してください。

プロキシ・サービスの作成するには、「プロキシ・サービスの作成」ウィザード、Service Bus概要エディタ、既存のサービスやJCAリソースからの生成、パイプラインの作成時のプロキシ・サービスとしてのパイプラインの公開など、様々な方法を使用できます。プロキシ・サービスを作成する場合、「プロキシ・サービスの作成」ウィザードには、プロキシ・サービスの特定のプロパティを構成できる一連のページが用意されています。この項では、「プロキシ・サービスの作成」ウィザードを使用してプロキシ・サービスを作成する方法について説明します。Service Bus概要エディタの使用については、「JDeveloperでのOracle Service Busアプリケーションの開発」を参照してください。

始める前に:

SMTPサーバー、MQ接続、UDDIサーバーなどのシステム・リソースを使用する場合、プロキシ・サービスの作成を開始する前に、必ずこれらのリソースを作成します。プロキシ・サービスを構成するには、これらのリソースを指定または選択する必要があり、必要なリソースがService Busにないかぎり、プロキシ・サービスの構成を完了できません。

JDeveloperで作業する場合は、プロキシ・サービスの追加先のアプリケーションおよびプロジェクトを作成するか開きます。Oracle Service Busコンソールで作業する場合は、アクティブ・セッションで作業していることと、プロキシ・サービスの追加先のプロジェクトが存在することを確認します。

8.5.1 プロキシ・サービスの作成方法

プロキシ・サービスを作成する場合、サービス・タイプや、WSDLファイルとService Busトランスポートのどちらを使用するかなど、特定の情報を指定する必要があります。次のトピックでは、プロキシ・サービスの作成に関する詳細情報を示します。

- プロキシ・サービスのタイプの詳細は、「プロキシ・サービスの定義」を参照してください。

- WSDLファイルの詳細は、「WSDLドキュメントの操作」を参照してください。

- 使用できる様々なトランスポートの詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください。

プロキシ・サービスを作成するには、サービスを作成するためにService BusコンソールまたはJDeveloperのいずれを使用するかに応じて、次のいずれかのタスクを実行します。

- Service Busコンソールを使用したプロキシ・サービスの作成方法

- Service Busコンソールを使用した入力済RESTプロキシ・サービスの作成方法

- JDevleoperを使用したプロキシ・サービスの作成方法

8.5.2 Service Busコンソールを使用したプロキシ・サービスの作成方法

リソース・ギャラリからアクセスできるプロキシ・サービスの作成ウィザードを使用して、Service Busコンソールでプロキシ・サービスを作成します。

プロキシ・サービスを作成するには:

注意:

ウィザードから(WADLを使用して)型付きRESTサービスを作成する手順は、他のプロキシ・サービスの作成プロセスとは異なります。ウィザードを使用してこのタイプのサービスを作成する手順は、Service Busコンソールを使用した型付きRESTプロキシ・サービスの作成方法を参照してください。

1. プロジェクト・ナビゲータで、サービスを作成するプロジェクトまたはフォルダを右クリックし、「作成」をポイントして、「リソース」を選択します。
リソース・ギャラリが表示されます。

2. リソース・ギャラリで、「プロキシ・サービス」をクリックして、作成するサービスのタイプにナビゲートします。この問合せを選択し、「OK」をクリックします。

3. サービスの名前と、必要に応じて説明を入力します。

注意:

命名要件については、「Service Busコンポーネントのネーミング・ガイドライン」を参照してください。

4. 手順2で選択したサービスのタイプに応じて、次のいずれかのオプションを構成する必要がある場合があります。

- 既存のWSDLファイルからプロキシ・サービス構成を生成する場合は、「WSDL」オプションから、「検索」アイコンをクリックしてWSDLリソースを検索します。WSDLファイルを指定したら、「ポート/バインド」フィールドから、使用するポートまたはバインディングを選択します。

- RESTプロキシ・サービスを生成する場合は、オプションで「WADL名」フィールドで「WADLリソースの選択」アイコンをクリックし、「検索と選択: WADLリソース」ダイアログを表示します。このダイアログを使用して、このサービスの生成元となるWADLリソースを検索して選択します。これにより、ネイティブの型付きRESTサービスが作成されます。ネイティブの型なしRESTサービスを作成する場合は、「WADL名」フィールドを空白にしておきます。

- トランスポートからプロキシ・サービスを生成する場合は、「トランスポート」オプションから、「プロトコル」リストで正しいトランスポートが選択されていることを確認します。別のトランスポート・タイプのサービスを作成する場合は、「プロトコル」リストからそのトランスポート・タイプを選択します。

5. プロキシ・サービスに対して生成するパイプラインの新しい名前を入力します(オプション)。パイプラインを生成しない場合は、「パイプラインの生成」チェック・ボックスの選択を解除します。

注意:

このオプションは、JEJBトランスポートでは無効です。

6. 「次」をクリックします。

ウィザードの残りのページのフィールドは、最初のページの選択内容によって異なります。次の手順で説明するオプションは、すべての構成で使用できるわけではありません。

7. WSDLベースまたはRESTベースのサービスを作成する場合は、手順10に進みます。

8. 最初のページでトランスポート定義を選択した場合は、使用可能なサービス・タイプのいずれかを選択します。

- WSDL: このオプションを選択する場合は、「名前」フィールドから「WSDLの選択」をクリックして、使用するWSDLファイルを参照して選択します。オプションのリストから、ポートまたはバインディング・タイプを選択します。

- REST: (オプション)「WADL名」フィールドで「WADLリソースの選択」アイコンをクリックし、「検索と選択: WADLリソース」ダイアログを表示します。このダイアログを使用して、このサービスの生成元となるWADLリソースを検索して選択します。これにより、ネイティブの型付きRESTサービスが作成されます。ネイティブの型なしRESTサービスを作成する場合は、「WADL名」フィールドを空白にしておきます。

- 任意のSOAP: このオプションを選択する場合、使用するSOAPバージョンを選択します。

- 任意のXML: このオプションに追加の構成は必要ありません。

- メッセージング: このオプションを選択する場合、リクエスト・メッセージのデータ型とレスポンス・メッセージを選択します。「MFL」を選択する場合は、スキーマ・ファイルも選択する必要があります。「XML」を選択する場合は、オプションでスキーマ・ファイルを選択できます。

9. 「次」をクリックします。

「トランスポート」ページが表示されます。

10. 使用するプロトコルをまだ選択していない場合、リストから新しいプロトコルを選択します。

11. エンドポイントURIを指定します。必要なURI形式については、Service Busに付属のオンライン・ヘルプを参照してください。

12. 「作成」をクリックします。

プロキシ・サービス定義エディタに、新しいプロキシ・サービスの全般構成が表示されます。

サービスの作成後は、次のようにします。

- 「プロキシ・サービスの構成」の説明に従い、プロキシ・サービスを構成します。

- パイプラインまたは分割-結合でメッセージ・フローを構成します。詳細は、「Oracle Service Busコンソールでのパイプラインの操作」および「分割-結合によるサービスのパフォーマンスの向上」を参照してください。

8.5.3 Service Busコンソールを使用した型付きRESTプロキシ・サービスの作成方法

入力済ネイティブRESTプロキシ・サービスは、「ネイティブRESTプロキシ・サービスの作成」ウィザードを使用して作成できます。このウィザードで、サービスのリソースおよびメソッドを指定します。ウィザードにより、サービスおよび使用可能なリソースとメソッドの詳細を記述するWADLファイルが作成されます。

型付きRESTサービスの詳細は、「Service BusにおけるRESTの実装」を参照してください。

コンソールでネイティブの型付きRESTプロキシ・サービスを作成するには、次のようにします。

1. プロジェクト・ナビゲータで、サービスを作成するプロジェクトまたはフォルダを右クリックし、「作成」をポイントして、「リソース」を選択します。
リソース・ギャラリが表示されます。

2. リソース・ギャラリで、「プロキシ・サービス」をクリックし、「ウィザードの入力済REST(WADLを使用)」をクリックして「OK」をクリックします。
ネイティブRESTプロキシ・サービスの作成ウィザードが表示されます。

3. 「基本情報」ページから、サービスの基本詳細を指定します。

a. 「名前」フィールドにサービスの名前を入力します。

b. (オプション)「説明」フィールドに説明を入力します。

c. 「ベースURI」フィールドに、サービスのベースURI (たとえば、/reservationService)を入力します。

d. 「次」をクリックします。

4. 「リソース」ページから、サービスに含めるリソースを指定します。

注意:

各サービスにはリソースが1つ以上必要です。

a. 「URI」フィールドに一意のリソース・パス(たとえば、/makeReservation)を入力します。

b. (オプション)「説明」フィールドにリソース・パスの説明を入力します。

c. 「リソースの追加」をクリックします。

d. さらにリソースを追加するには、手順aからcを繰り返します。

ヒント:

すでに追加されているリソースにリソースを子として追加するには、次の図に示すように、「リソースの追加」ボタンのかわりに、リソースの隣にある「追加」アイコンをクリックします。

e. リソースの追加が終了したら、「次」をクリックします。

5. 「メソッド」ページから、各リソースで使用可能なメソッドを指定します。

a. リソースにメソッドを追加するには、「メソッド」の隣にある矢印をクリックし、HTTP動詞をクリックして、そのHTTP動詞を使用してメソッドを追加します。

注意:

使用可能なHTTP動詞は、GET、PUT、POSTおよびDELETEです。各リソースには複数のGETメソッドを指定できますが、PUT、POSTおよびDELETEの各動詞のメソッドは1つのみです。

b. 「名前」フィールドにメソッドの名前を入力します。

c. (オプション)「説明」フィールドにメソッドの説明を入力します。

d. 「リクエスト」タブで、このメソッドのリクエストを構成します。

このタブで使用可能なオプションは、メソッドに対して選択するHTTP動詞によって異なります。

- ペイロードを構成します。ペイロードを送信しない場合は、「なし」を選択します。「メディア」を選択し、メディア・タイプを選択してペイロードがそのフォーマットで表示されるようにします(「XML」、「JSON」、「URL-エンコード」、「テキスト」または「不透明」)。

- リクエストにさらにパラメータを追加するには、「パラメータの追加」をクリックします。表示される各フィールドにパラメータ名、タイプ、デフォルト値を入力して指定し、追加するパラメータごとにこの入力を繰り返します。

- 「パラメータ名」フィールドにパラメータの名前を入力します。

- 「タイプ」リストから、パラメータのタイプ(stringまたはintegerなど)を選択します。

- 「デフォルト値」フィールドにパラメータのデフォルト値を入力します。

e. 「レスポンス」タブで、このメソッドのレスポンスを構成します。

- 成功ペイロードについて、「なし」を選択してペイロードが表示されないようにするか、または「メディア」を選択し、メディア・タイプを選択してペイロードをそのフォーマットで表示できるようにします(「XML」、「JSON」、「URL-エンコード」、「テキスト」または「不透明」)。「成功ステータス」フィールドに、成功時に送信されるHTTPステータス・コードを入力します。

- 失敗ペイロードについて、「なし」を選択してペイロードが表示されないようにするか、または「メディア」を選択し、メディア・タイプを選択してペイロードをそのフォーマットで表示できるようにします(「XML」、「JSON」、「URL-エンコード」、「テキスト」または「不透明」)。「失敗ステータス」フィールドに、失敗時に送信されるHTTPステータス・コードを入力します。

f. メソッドの構成が終了したら、「完了」をクリックします。

g. リソースにさらにメソッドを追加するには、手順aからfを繰り返します。各リソースにはメソッドが1つ以上必要です。

6. 「作成」をクリックして、サービスを作成します。

プロキシ・サービス定義エディタが表示されます。

サービスの作成後は、次のようにします。

- 「プロキシ・サービスの構成」の説明に従い、プロキシ・サービスを構成します。

- パイプラインまたは分割-結合でメッセージ・フローを構成します。詳細は、「Oracle Service Busコンソールでのパイプラインの操作」および「分割-結合によるサービスのパフォーマンスの向上」を参照してください。

8.5.4 JDevleoperを使用したプロキシ・サービスの作成方法

プロキシ・サービスは「プロキシ・サービスの作成」ウィザードを使用して、WSDLファイル、トランスポート、および未入力のネイティブRESTサービスに基づいて作成します。

ネイティブの型付きRESTプロキシ・サービスとWSDLファイルに基づくRESTプロキシ・サービスの作成方法は、「JDeveloperを使用したService Bus用の入力済RESTサービスの作成方法」および「JDeveloperを使用したService Bus用のWSDLベースRESTサービスの作成方法」を参照してください。

プロキシ・サービスを作成するには:

1. アプリケーション・ナビゲータで、プロジェクトを右クリックして、「新規」をポイントし、「プロキシ・サービス」を選択します。

プロキシ・サービスの作成ウィザードが表示されます。

2. サービスの名前と、必要に応じて説明を入力します。

注意:

- JDeveloperでは、プロキシ・サービス・ファイルがサーバーに格納される場所を変更できます。ファイルは、アプリケーション・フォルダおよびプロジェクト・フォルダ(デフォルトの場所)に格納する必要があります。

- 命名要件については、「Service Busコンポーネントのネーミング・ガイドライン」を参照してください。

3. 次のいずれかを行います:

- ネイティブの型なしRESTサービスを生成するには、「REST」を選択します。

- プロキシ・サービスのトランスポートを構成してサービスを生成するには、「トランスポート」を選択して、トランスポートのタイプをリストから選択します。

- 既存のWSDLファイルからプロキシ・サービス構成を生成するには、「WSDL」を選択して、WSDLファイルの名前を入力するか、「検索」アイコンをクリックしてWSDLリソースを検索します。WSDLファイルを指定したら、「ポート/バインド」フィールドから、使用するポートまたはバインディングを選択します。

4. プロキシ・サービスに対して生成するパイプラインの新しい名前を入力します(オプション)。パイプラインを生成しない場合は、「パイプラインの生成」チェック・ボックスの選択を解除します。

注意:

このオプションは、JEJBトランスポートでは無効です。

5. 「次」をクリックします。

ウィザードの残りのページのフィールドは、最初のページの選択内容によって異なります。次の手順で説明するオプションは、すべての構成で使用できるわけではありません。

6. 最初のページでWSDLまたはREST定義を選択した場合、手順9に進みます。

7. 最初のページでトランスポート定義を選択した場合は、次のいずれかのサービス・タイプを選択します。

- REST: このオプションに追加の構成は必要ありません。

- WSDL: このオプションを選択する場合、WSDLファイル名を入力するか、「WSDLの選択」をクリックして、使用するWSDLファイルを参照して選択します。オプションのリストから、ポートまたはバインディング・タイプを選択します。

- 任意のSOAP: このオプションを選択する場合、使用するSOAPバージョンを選択します。

- 任意のXML: このオプションに追加の構成は必要ありません。

- メッセージング: このオプションを選択する場合、リクエスト・メッセージのデータ型とレスポンス・メッセージを選択します。「MFL」を選択する場合は、スキーマ・ファイルも選択する必要があります。「XML」を選択する場合は、オプションでスキーマ・ファイルを選択できます。

8. 「次」をクリックします。

「トランスポート」ページが表示されます。

9. 使用するプロトコルをまだ選択していない場合、リストから新しいプロトコルを選択します。

10. エンドポイントURIを指定します。必要なURI形式については、Service Busに付属のオンライン・ヘルプを参照してください。

11. 「終了」をクリックします。

プロキシ・サービス定義エディタに、新しいプロキシ・サービスの全般構成が表示されます。

12. 「プロキシ・サービスの構成」の説明に従い、プロキシ・サービスを構成します。

13. プロキシ・サービスを作成したら、パイプラインまたは分割-結合でメッセージ・フローを構成する必要があります。詳細は、「Oracle Service Busコンソールでのパイプラインの操作」および「分割-結合によるサービスのパフォーマンスの向上」を参照してください。

8.5.5 JCAバインド・リソースからのプロキシ・サービスの生成方法

Service Busでは、インバウンドJCAファイルからプロキシ・サービスを生成できます。Service Bus JCAトランスポートを使用するJCAサービスは、JCAアダプタ・フレームワークおよびJCA準拠アダプタを介してEnterprise Information Systems (EIS)と通信します。JCAバインド・リソースの詳細は、「JCAトランスポートとJCAアダプタの使用」を参照してください。

始める前に:

JDeveloperで、JCAファイル、その関連抽象WSDLファイルおよび必要なその他のリソース(TopLinkマッピング・ファイルなど)を作成します。詳細は、「JCAトランスポートとJCAアダプタの使用」および「テクノロジ・アダプタの理解」を参照してください。

注意:

- インバウンドJCAバインドではなくアウトバウンドJCAバインドを選択する場合、プロキシ・サービスを生成するオプションは利用できません。

- JDeveloperでは、JCAアダプタをService Bus概要エディタから作成する場合、アダプタの作成時にプロキシ・サービスも生成できます。詳細は、「プロキシ・サービスの作成方法」を参照してください。

8.5.5.1 JDeveloperでのJCAバインドからのプロキシ・サービスの生成

JDeveloperでJCAバインドからJCAプロキシ・サービスを生成するには:

1. アプリケーション・ナビゲータで、インバウンドJCAファイルを右クリックして、「Service Bus」をポイントし、「プロキシ・サービスの生成」を選択します。

選択したJCAバインドに対して構成された「プロキシ・サービスの作成」ウィザードが表示されます。

2. ウィザードで、デフォルトのサービス名と場所のままにするか、新しい名前と場所を指定します。場所は、現在のアプリケーションのディレクトリ構造内にしてください。

命名ガイダンスについては、「Service Busコンポーネントのネーミング・ガイドライン」を参照してください。

3. プロキシ・サービスに対応するパイプラインを生成するには、「パイプラインの生成」を選択したままにし、パイプラインの名前を指定します(またはデフォルト名をそのまま使用します)。この時点ではパイプラインを作成しない場合は、「パイプラインの生成」チェック・ボックスを選択解除します。

4. 「次」をクリックします。

「タイプ」ページが表示されます。

5. 必要に応じてWSDLバインドを選択して、「次」を再度クリックします。

「トランスポート」ページが表示されます。

6. 必要に応じてエンドポイントURIを更新して、「終了」をクリックします。

Service Busによって、プロキシ・サービスと、そのプロキシ・サービスが使用する具象WSDLファイルが生成されます。

7. 「プロキシ・サービスの構成」の説明に従い、プロキシ・サービスを構成します。

8.5.5.2 コンソールでのJCAバインドからのプロキシ・サービスの生成

始める前に、JCAリソース・ファイルをJDeveloperからコンソールにインポートし、依存関係へのすべての参照が維持されるようにします。詳細は、「JCAバインド・リソースの操作」および「リソースおよび構成のインポートとエクスポート」を参照してください。

コンソールでJCAバインドからプロキシ・サービスを生成するには:

1. プロジェクト・ナビゲータで、インバウンドJCAファイルを右クリックして、「WSDLとサービスの生成」を選択します。

「WSDLとサービスの生成」ダイアログが表示されます。

2. 必要に応じて、WSDLファイルと生成するサービスの名前を変更し、これらの新しいリソースの場所を選択します。

命名ガイダンスについては、「Service Busコンポーネントのネーミング・ガイドライン」を参照してください。

3. 「生成」をクリックします。

Service Busによって、サービスとこれに対応するWSDLファイルが生成されます。

4. プロジェクト・ナビゲータで、新しいリソースに移動し、プロキシ・サービス定義エディタでプロキシ・サービスを開きます。

5. 「プロキシ・サービスの構成」の説明に従い、プロキシ・サービスを構成します。

8.5.6 JDeveloperでの既存のサービスからのプロキシ・サービスの生成方法

JDeveloperでは、他のプロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合からプロキシ・サービスを生成できます。プロキシ・サービスの構成は、既存のサービスの構成に基づきます。

JDeveloperで別のサービスからプロキシ・サービスを生成するには:

1. アプリケーション・ナビゲータで、既存のサービスを右クリックして、「Service Bus」をポイントし、「プロキシ・サービスの生成」を選択します。

「プロキシ・サービスの作成」ウィザードが表示されます。

2. サービスの名前、説明、ファイルの場所を構成し、「次」をクリックします。

「タイプ」ページが表示されます。

3. サービスがWSDLサービスの場合、使用するバインディングを選択して、「次」をクリックします。

4. 「トランスポート」ページで、トランスポート・プロトコルを選択してエンドポイントURIを更新します。必要なURI形式については、Service Busに付属のオンライン・ヘルプを参照してください。

5. 「終了」をクリックします。

6. 「プロキシ・サービスの構成」の説明に従い、プロキシ・サービスを構成します。

8.5.7 JDeveloperでのWSDLドキュメントからのプロキシ・サービスの生成方法

既存のWSDLドキュメントを使用して、プロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合を生成できます。

JDeveloperでWSDLドキュメントからプロキシ・サービスを生成するには:

1. アプリケーション・ナビゲータで、既存のWSDLドキュメントを右クリックして、「Service Bus」をポイントし、「プロキシ・サービスの生成」を選択します。

「プロキシ・サービスの作成」ウィザードが表示されます。

2. サービスの名前、説明、ファイルの場所およびWSDLバインドを構成します。

3. プロキシ・サービスに対応するパイプラインを生成するには、「パイプラインの生成」を選択したままにし、パイプラインの名前を指定します(またはデフォルト名をそのまま使用します)。この時点ではパイプラインを作成しない場合は、「パイプラインの生成」チェック・ボックスを選択解除します。

4. 「次」をクリックします。

5. 「トランスポート」ページで、トランスポート・プロトコルを選択してエンドポイントURIを更新します。必要なURI形式については、Service Busに付属のオンライン・ヘルプを参照してください。

6. 「終了」をクリックします。

7. 「プロキシ・サービスの構成」の説明に従い、プロキシ・サービスを構成します。

8.6 プロキシ・サービスの構成

プロキシ・サービスを作成すると、構成の編集、セキュリティ・ポリシーの追加、セキュリティ設定の変更およびSLAアラート・ルールの設定を行うことができます。変更できる情報は、最初にサービスを構成した方法によって異なります。プロキシ・サービスに構成可能なプロパティのリストについては、プロキシ・サービス定義エディタの各ページで利用可能なオンライン・ヘルプを参照してください。

Oracle Service Busコンソールで作業する場合は、この項のタスクを実行する前に、アクティブ・セッションにいることを確認してください。

8.6.1 プロキシ・サービスの全般情報の構成方法

プロキシ・サービス定義エディタの「全般」タブには、サービスに関する情報(サービスの説明、サービスで使用されるトランスポート、サービス・タイプ、WSDLのポートまたはバインディング、XQueryバージョン、プロキシ・サービスで呼び出されるサービスなど)が表示されます。次の図に、Oracle Service Busコンソールの「全般」タブを示します。

図8-1 コンソールでのプロキシ・サービスの全般的な構成のページ

プロキシ・サービスの全般情報を構成するには:

1. プロジェクト・ナビゲータまたはアプリケーション・ナビゲータで、編集するプロキシ・サービスを右クリックして、「開く」を選択します。

2. まだ表示可能なページではない場合は、「全般」タブをクリックします。

3. サービスの説明を入力するか更新します。

4. WSDLまたはMFLドキュメントなどのリソースをサービスで参照している場合、リソースの名前をクリックして、それ自体のエディタでドキュメントを表示します。

5. プロキシ・サービスのターゲット・サービスを変更するには、ターゲット・サービス名の横の「サービス・リソースの選択」をクリックします。JDeveloperで、新しいターゲット・サービスを参照して選択します。コンソールで、新しいターゲット・リソースを検索して選択します。

6. 使用されるXQueryバージョンを変更するには、「XQuery処理」リストから新しいオプションを選択します。

7. Oracle Service Busコンソールで作業している場合、デフォルトのUDDIレジストリにプロキシ・サービスを自動でパブリッシュするには、「レジストリに自動パブリッシュ」を選択します。

プロキシ・サービスを自動でパブリッシュするには、デフォルトのUDDIサーバーを定義する必要があります。詳細は、「サービスの同期化の維持」を参照してください。

8. 変更が完了したら、「すべて保存」をクリックします。

9. Oracle Service Busコンソールで作業している場合、「アクティブ化」をクリックして、セッションを終了し、構成をランタイムにデプロイします。

8.6.2 プロキシ・サービスのトランスポートの構成方法

「トランスポート」ページと「トランスポートの詳細」ページを使用して、プロキシ・サービスのトランスポートを構成します。使用可能なプロパティはトランスポートごとに異なります。次の図に、Oracle Service Busコンソールの「トランスポート」タブを示します。

図8-2 コンソールでのプロキシ・サービスのトランスポートの構成のページ

プロキシ・サービスのトランスポートを構成するには:

1. プロジェクト・ナビゲータまたはアプリケーション・ナビゲータで、編集するプロキシ・サービスを右クリックして、「開く」を選択します。

2. 「トランスポート」タブをクリックして、次のいずれかを行います。

- エンドポイントURIを更新します。

- すべてのヘッダーを取得するには、「すべてのヘッダーを取得」を選択します。

- ヘッダーのサブセットを取得するには、「指定されたヘッダーの取得」を選択し、取得するヘッダーを「ヘッダー」表で指定します。表の上にある「追加」をクリックしてヘッダーを追加します。

3. 「トランスポートの詳細」タブをクリックします。

ここで構成できるプロパティは、プロキシ・サービスのトランスポートに基づきます。特定のトランスポートの詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください。次の図に、コンソールのHTTPトランスポート・プロパティを示します。

図8-3 コンソールでのプロキシ・サービスのトランスポートの詳細ページ

4. 変更が完了したら、「すべて保存」をクリックします。

5. Oracle Service Busコンソールで作業している場合、「アクティブ化」をクリックして、セッションを終了し、構成をランタイムにデプロイします。

8.6.3 プロキシ・サービスのメッセージ処理の構成方法

「メッセージ処理」ページでは、プロキシ・サービスによるメッセージ・コンテンツの処理(WS-I準拠の確認など)や、使用するXQueryバージョンを構成できます。次の図に、Oracle Service Busコンソールの「メッセージ処理」タブを示します。

図8-4 コンソールでのプロキシ・サービスのメッセージ処理のページ

プロキシ・サービスのメッセージ処理を構成するには:

1. プロジェクト・ナビゲータまたはアプリケーション・ナビゲータで、編集するプロキシ・サービスを右クリックして、「開く」を選択します。

2. 「メッセージ処理」タブをクリックします。

3. メッセージがWS-Iに準拠しているかどうかを確認するには、「WS-I準拠の適用」のチェック・ボックスを選択します。

4. 次のいずれかの選択アルゴリズムを選択します。

- トランスポート・ヘッダー: ルックアップ値を含むトランスポート・ヘッダーを定義できます。このオプションを選択する場合、表示される新しいフィールドでヘッダー名と操作値も指定する必要があります。

- SOAPアクション・ヘッダー: このプロキシ・サービスに関連付けられたWSDLファイルから自動的に操作のマッピングが行われるように指定します。

- WS-Addressing: ルックアップ値がSOAPメッセージのSOAPヘッダー内のWS-Addressing Actionタグに入るように指定します。このオプションを選択する場合、表示される新しいフィールドで操作値も指定する必要があります。

- SOAPヘッダー: SOAPヘッダーに対して評価されるXPath式を定義できます。これにより、ルックアップ値を取得できるようになります。このオプションを選択する場合、表示される新しいフィールドでXPath式と値も定義する必要があります。

- SOAP本体タイプ: WSDL仕様で定義されたデフォルトのアルゴリズムを使用し、受信するSOAPメッセージのタイプに基づいてコールされる操作が計算されます。

- ペイロード・タイプ: このオプションは、WSDLポートまたはWSDLバインドに基づいたXMLサービスでのみ使用できます。

これらのアルゴリズムの詳細は、このページで提供されるオンライン・ヘルプを参照してください。

5. 変更が完了したら、「すべて保存」をクリックします。

6. Oracle Service Busコンソールで作業している場合、「アクティブ化」をクリックして、セッションを終了し、構成をランタイムにデプロイします。

8.6.4 プロキシ・サービスのセキュリティの構成方法

プロキシ・サービスは、Oracle Web Services Manager (OWSM)ポリシーや、トランスポート・レベルおよびメッセージ・レベルのアクセス制御などの複数の方法で保護できます。プロキシ・サービスの保護の詳細は、「プロキシ・サービスの保護」および「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。

8.6.5 プロキシ・サービスのサービス・レベル合意のアラートの構成方法

SLAアラートを使用する場合、システム管理者は、プロキシ・サービスのヘルスを示す特定の条件が満たされるタイミングを把握できます。SLAアラートの定義の詳細は、『Oracle Service Busの管理』のサービス・レベル合意のアラート・ルールの作成に関する項を参照してください。

8.7 プロキシ・サービスの削除

プロキシ・サービスを削除すると、Service Busが制御するリポジトリ、および適切な認可プロバイダから、プロキシにより参照されるすべてのACLが削除されます。プロキシ・サービスが他のリソースで参照される場合でも、そのサービスを削除できますが、削除されたサービスに対する未解決の参照が原因で競合が生じることがあります。

8.7.1 プロキシ・サービスの削除方法

プロキシ・サービスを削除する前には、すべての依存関係を確認します。Oracle Service Busコンソールの場合、プロキシ・サービス定義エディタでプロキシ・サービスを開き、右上のツール・アイコンをクリックし、「参照」を選択して、いずれかのサービスでそのプロキシ・サービスを使用しているかどうかを確認します。JDeveloperでは、プロキシ・サービスを右クリックして、「依存性の参照」を選択します。

プロキシ・サービスを削除するには:

1. プロジェクト・ナビゲータまたはアプリケーション・ナビゲータで、削除するプロキシ・サービスを右クリックして、「削除」を選択します。

確認のダイアログが表示されます。

2. JDeveloperでは、他のリソースでこのプロキシ・サービスを参照する場合、確認ダイアログに参照の数が表示されます。「使用方法の表示」をクリックして、参照に関する情報を表示します。

3. 確認のダイアログで、「はい」をクリックして、サービスの削除を確定します。

プロキシ・サービスが削除されます。

4. Oracle Service Busコンソールで作業している場合、「アクティブ化」をクリックして、セッションを終了し、構成をランタイムにデプロイします。

8.8 JDeveloperでのWSILによるプロキシ・サービスの使用

Service Busでは、Web Services Inspection Language (WSIL)でのWSDLベースのプロキシ・サービスが使用可能であり、Oracle SOA Suiteでのサービス編成のためにJDeveloperでService Bus WSDLプロキシ・サービスを使用できます。

Service Bus WSILサーブレットは、Service Bus実行時環境にデプロイされているWSDLベースのプロキシ・サービスを自動的に登録します。WSIL接続をJDeveloperで作成することで、様々な階層レベル(プロジェクト、フォルダ、個々のサービスなど)にマップされる様々なURLパターンを介してそれらのプロキシ・サービスにアクセスできます。たとえば、プロジェクト・レベルのURLを使用してService Bus WSILサーブレットに接続すると、JDeveloperで、そのプロジェクトにあるすべての子フォルダとWSDLベースのプロキシ・サービスを確認できます。

8.8.1 JDeveloperでのWSILによるService Busプロキシ・サービスの使用方法

次の手順は、WSIL接続をJDeveloperで作成し、SOAアプリケーションで使用するためにService Bus WSDLプロキシ・サービスからWebサービス参照を生成するプロセスを示します。

JDeveloperでWSILによってプロキシ・サービスを使用するには:

1. JDeveloperでSOAアプリケーションを開くか作成します。

2. 新しいWSIL接続を作成します。
「リソース」ウィンドウで、「追加」アイコンをクリックして、「IDE接続」→「WSIL」を選択します。

「WSIL接続の作成」ダイアログで、次のようにします。

a. 接続の名前を入力します。
命名ガイダンスについては、「Service Busコンポーネントのネーミング・ガイドライン」を参照してください。

b. 管理者、デプロイ担当者、オペレータまたはモニターのいずれかのService Busロールの資格証明を入力します。

c. Service Bus WSILのURLを次のいずれかの形式で入力します。

- ドメイン(すべてのプロジェクト、フォルダおよびWSDLベースのプロキシ・サービスを取得):

http://host:port/sbinspection.wsil

- プロジェクト(すべての子フォルダおよびWSDLベースのプロキシ・サービスを取得):

http://host:port/sbinspection.wsil?refpath=project_name

- フォルダ(1つのプロジェクト内のフォルダ、すべての子フォルダおよびWSDLベースのプロキシ・サービスを取得):

http://host:port/sbinspection.wsil?refpath=project_name/folder_path

次に例を示します。

http://localhost:7021/sbinspection.wsil?refpath=MortgageBroker/ProxyServices

- プロキシ・サービス(個々のWSDLベースのプロキシ・サービスを取得):

http://host:port/sbinspection.wsil?refpath=project_name/folder_path/wsdl_proxy_service

次に例を示します。

http://localhost:7021/sbinspection.wsil?refpath=MortgageBroker/ProxyServices/loanGateway1

クラスタでは、WSILサーブレットは管理サーバーではなく管理対象サーバーにデプロイされます。URLでは管理対象サーバーのホスト名とポートを使用してください。

d. 「接続のテスト」をクリックして、接続が有効かどうかを検証します。

e. 「OK」をクリックします。WSIL接続が、入力したURLによって決まる階層で「リソース」ウィンドウに表示されます。

3. Service Bus WSDLベースのプロキシ・サービスをSOAアプリケーションで使用するには、そのプロキシ・サービスのWebサービス参照を作成します。

- 「コンポーネント」ウィンドウで、新しいWebサービスを作成します。「Webサービスの作成」ウィンドウで「WSDL URL」参照アイコンをクリックします。

- 「SOAリソース・ブラウザ」で「リソース」を選択し、前の手順で作成したWSIL接続のService Busプロキシ・サービスを選択します。

Service Bus WSDLベースのプロキシ・サービスのWebサービス参照を作成したら、SOAアプリケーションで外部参照として使用できます。

Service Bus WSILサーブレットはSBResourceサーブレットを利用します。SBResourceがデプロイ解除されると、WSIL接続は使用できなくなります。

9 ビジネス・サービスの作成と構成

この章では、Oracle Service BusコンソールおよびJDeveloperを使用して、ビジネス・サービスを作成、構成および管理する方法について説明します。Service Busのビジネス・サービスとプロキシ・サービスを使用すると、エンタープライズ全体でのサービスの管理、メッセージの変換およびメッセージのルーティングを行うことができます。

- ビジネス・サービスの概要

- プロキシ・サーバーの使用

- サービス・レベル合意のアラート・ルール

- ビジネス・サービスのセキュリティおよびセキュリティ・ポリシー

- ビジネス・サービスの作成

- ビジネス・サービスの構成

- ビジネス・サービスの削除

- ビジネス・サービスの結果のキャッシュによるパフォーマンスの改善

9.1 ビジネス・サービスの概要

ビジネス・サービスは、メッセージの交換先となるエンタープライズ・サービスのService Busでの定義です。これらは、Service BusがクライアントとなるエンタープライズWebサービスを定義します。これらの外部Webサービスは、外部システムに実装され、外部システムによってホストされるため、Service Busは呼び出す対象、呼び出す方法および呼出しの結果として予想される内容を認識しておく必要があります。Service Busが外部サービスを呼び出すことができるように、ビジネス・サービスではそのインタフェースをモデル化しています。

ビジネス・サービスは、プロキシ・サービスと同様に、WSDL (Web Services Definition Language)またはWADL (Web Application Definition Language)を使用して定義します。ビジネス・サービスの構成には、インタフェース、トランスポート設定、およびセキュリティ 設定が含まれますビジネス・サービスがWSDLドキュメントに基づいている場合、構成にはWSDLポートまたはWSDLバインドも含まれます。(「WSDLドキュメントの操作」を参照。)

UDDIレジストリ、SOA Oracle Metadata Services (MDS)レジストリ、アプリケーション・サーバー、またはファイル・システムからインポートしたドキュメントを含む、既存のWSDLおよびWADLドキュメントをビジネス・サービスの基盤にすることもできます。Service Busでは、RESTバインディングを使用するビジネス・サービスもサポートしています(「Oracle Service BusでのRESTサービスの作成」を参照)。これらのサービスは、WADLドキュメントに基づくものであり、JDeveloperのService Bus概要エディタでのみ作成できます。

9.1.1 ビジネス・サービスの定義

各ビジネス・サービスは、WSDL WebサービスとService Busトランスポートのどちらを基準にするかで定義されます。WSDLベースのサービスは、WSDLドキュメントでインタフェースが記述されるSOAPビジネス・サービスまたはXMLビジネス・サービスです。トランスポート型のサービスは、JCAトランスポートなどのService Busトランスポートに基づくビジネス・サービスで、Oracle JCA準拠アダプタにビジネス・サービスを構成するためのサポートが提供されます。これにはHTTPトランスポートを使用するRESTビジネス・サービスも含まれます。各タイプのビジネス・サービスでは、その定義に固有のトランスポート・プロトコルがサポートされます。Service Busは、いくつかの標準トランスポート・プロトコルとカスタム・トランスポートをサポートします。

「ビジネス・サービスの作成」ウィザードまたはJDeveloperのService Bus概要エディタのいずれかを使用して、WSDLベースまたはトランスポート型のサービスでビジネス・サービスを作成できます。Service Bus概要エディタを使用すると、JCAアダプタからビジネス・サービスを直接生成して、そのアダプタ・タイプにすでに構成されているビジネス・サービスを作成できます。ウィザードとエディタのどちらでも、プロキシ・サービスからビジネス・サービスを生成できます。

9.1.2 ビジネス・サービスのサービス・タイプとプロトコル

Service Busは、従来のWebサービス(WSDLファイルでXMLまたはSOAPバインディングを使用)から非XMLサービス(汎用)サービスまで、多くのサービス・タイプに対応しています。トランスポート型のビジネス・サービスを作成する場合、サービス・タイプを指定して構成することで、サービスをさらに定義する必要もあります。選択できるサービス・タイプは、サービス・エンドポイントとの通信に使用するトランスポートに基づいて制限されます。各サービス・タイプでサポートされるトランスポートの詳細は、「トランスポート、アダプタおよびバインディング」を参照してください。

ビジネス・サービスのサービス・タイプは、次のいずれかになり、そのサービスが処理するメッセージのタイプで識別されます。

- WSDLベース・サービス: このサービス・タイプは、既存のWSDLドキュメント、またはビジネス・サービスの作成と同時に作成したWSDLドキュメントから生成されます。WSDLベースのサービスを作成する際は、使用するポートまたはバインディングを指定する必要があります。

- メッセージ・サービス: このサービス・タイプは、あるデータ型のメッセージを受信し、レスポンスとして別のデータ型のメッセージを返すことができます。サポートされるデータ型には、XML、Message Format Language (MFL)、テキスト、型なし、バイナリ、Java、インタフェースがWSDLで記述されていない添付などがあります

- 任意のSOAPサービス: このサービス・タイプは、SOAPメッセージを交換します。SOAPメッセージは、<soap:Envelope>要素内のheader変数およびbody変数のコンテンツをラップすることで作成されます。body変数に参照XMLが格納されている場合、メッセージは現状のまま送信されます。つまり、参照されているコンテンツはメッセージに置き換えられません。attachments変数で添付が定義されている場合は、メイン・メッセージと添付データからMIMEパッケージが作成されます。各添付部分のコンテンツの処理方法は、メッセージング・サービスのコンテンツの処理方法に類似しています。

- 任意のXMLサービス(非SOAP): このサービス・タイプでは、XMLベースのサービスへのメッセージはXMLですが、ビジネス・サービスの構成で許可された任意の型を使用できます。添付を含むメッセージの場合、そのコンテンツは、プライマリXMLペイロードをその一部(通常は最初の部分、または最上位のContent-Typeヘッダーで指定される部分)として含むMIMEパッケージです。

- RESTサービス: このサービス・タイプは、RESTバインディングに基づき、既存のWADLから生成するか、プロキシ・サービスの作成と同時に作成したWADLから作成するか(型付きREST)、またはWADLまたはスキーマなしで作成(型なしREST)できます。詳細は、「Oracle Service BusでのRESTサービスの作成」を参照してください。

9.1.3 ビジネス・サービス・タイプのバインディング定義とランタイム変数

各ビジネス・サービス・タイプは、サービスに対して構成する必要があるパターン同じパターンに従ってモデル化されます。これらのモデルは、プロキシ・サービスのモデルと同じです。詳細は、「プロキシ・サービス・タイプのバインディング定義とランタイム変数」を参照してください。

9.1.4 ビジネス・サービスのトランスポート・プロトコル構成

ビジネス・サービスの構成の大部分には、トランスポート・プロトコルが関与します。トランスポートは、外部システムとビジネス・サービスとの間の通信レイヤーです。ビジネス・サービスに使用できるトランスポート・プロトコルは、作成するサービス・タイプによって異なります。それぞれのトランスポート・プロトコルには独自の構成要件があります。トランスポート・プロトコルとその構成要件の詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照し、関連する特定のプロトコルのリンクをクリックしてください。

トランスポートおよびWSDLファイル、またはインタフェースに基づいて、トランスポート・モードが自動的に選択されますが、ルート・アクションまたはパブリッシュ・アクションのルーティング・オプション・アクションを使用して上書きできます。

各ビジネス・サービスの次のパラメータを構成できます。

- 形式<string URI, integer weight>による重み付けされたエンドポイントURIのリスト(例: <http://www.oracle.com, 100>)。ランダムな重みベースのリストには、少なくとも1つの要素が含まれます。

- ロード・バランシング・アルゴリズム。ラウンド・ロビン、ランダム、ランダムな重みベースになります。ランダムな重みベースを選択すると、各URIに重みを適用できます。

- 再試行回数

- 再試行の反復間隔

- アプリケーション・エラーの再試行

選択するトランスポート方式は、バインディング定義で必要とされるトランスポート・モード(リクエスト/レスポンス、一方向、または両方)をサポートできる必要があり、それに従って構成する必要があります。

両方のモード(リクエスト/レスポンスと一方向)でメッセージを交換するサービスでは、トランスポート・モードを適宜選択できるようにバインディング・レイヤーを構成する必要があります。サービスが具象型の場合、バインディング定義の記述に従って、この選択が自動的に行われます。サービスが具象型でない場合、バインディング・レイヤーを構成するには、パイプラインでルーティング・オプション・アクションを使用して、ルートまたはパブリッシュのモードを設定する必要があります。

Tuxedoトランスポートベースのサービスでは、サービス・タイプがXMLの場合、TuxedoクライアントのFLD_MBSTRINGフィールドを含むFML32バッファはXMLに変換されません。各種トランスポート・プロトコルに基づくビジネス・サービスの構成の詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください。

9.1.4.1 ロード・バランシング・アルゴリズムについて

ロード・バランシング・アルゴリズムは、エンドポイントURIが実行時に選択される順序を定義します。Service Busでは、次のアルゴリズムがサポートされます。

- ラウンドロビン: ビジネス・サービスに定義するURIを動的に順序付けます。最初のものに失敗した場合は次が試行され、次のものに失敗した場合はその次というように、再試行回数に達するまで続きます。新しいメッセージごとに、URIの順序が新しく設定されます。

- ランダム: ビジネス・サービスに定義するURIのリストをランダムに順序付けます。最初のものに失敗した場合は次が試行され、次のものに失敗した場合はその次というように、再試行回数に達するまで続きます。

- ランダムな重みベース: ビジネス・サービスに定義するURIのリストをランダムに順序付けますが、「重み」フィールドに入力した値に基づいて、一部のURIが他のURIよりも頻繁に再試行されます。

- なし: ビジネス・サービスに定義するURIのリストを上から下に順序付けます。

9.1.4.2 ビジネス・サービスのURI再試行について

ビジネス・サービスの再試行オプションでは、ビジネス・サービスが最初の失敗後にエンドポイントURIへのアクセスを再試行できる最大回数を指定します。たとえば、エンドポイントURI eu1、eu2およびeu3を使用した場合のビジネス・サービスBの動作を考えてみます。再試行回数は、それぞれ1、2および4に設定しています。

再試行回数 = 1の場合: ビジネス・サービスBは、リクエストを処理できない場合や、エンドポイントURI eu1にアクセスできない場合、eu2を使用してリクエストを処理しようとします(再試行1)。再試行が失敗した場合には、エラーを返します。ビジネス・サービスは、3番目のエンドポイントURI eu3を試行しません。

再試行回数 = 2の場合: ビジネス・サービスBは、リクエストを処理できない場合や、エンドポイントURI eu1にアクセスできない場合、eu2を使用してリクエストを処理しようとします(再試行1)。再試行が失敗した場合には、eu3を使用してリクエストを処理しようとします(再試行2)。再試行が失敗した場合には、エラーを返します。

再試行回数 = 4の場合: ビジネス・サービスBは、リクエストを処理できない場合や、エンドポイントURI eu1にアクセスできない場合、eu2を使用してリクエストを処理しようとします(再試行1)。再試行が失敗した場合には、eu3を使用してリクエストを処理しようとします(再試行2)。次に、再試行の反復間隔に構成した間隔(秒)をおいて、eu1を試行します(再試行3)。これに失敗すると、eu2を再試行します(再試行4)。再試行が失敗した場合には、エラーを返します。

再試行回数を0に設定すると、ビジネス・サービスは、失敗後に再試行を実行しません。

注意:

ビジネス・サービスがエンドポイントを再試行する順序は、ロード・バランシング・アルゴリズムによって制御されます。

9.1.4.3 アプリケーション・エラー発生時の再試行の抑止

通信エラーやアプリケーション・エラーが発生すると、ビジネス・サービスはリクエストの処理に失敗します。通信エラーは、様々なネットワークの問題によって発生します。その場合、別のエンドポイントURIを使用してリクエストを再試行すると正常に処理できる可能性があります。アプリケーション・エラーは、リクエストの形式が正しくない場合やその他のエラーが原因で発生します。このエラーは、どのエンドポイントでも処理できません。使用したトランスポートに応じて、ビジネス・サービスの「トランスポート構成」ページにある「アプリケーション・エラーの再試行」オプションを選択解除することにより、アプリケーション・エラーの再試行動作を無効にできます。

9.1.5 ビジネス・サービスのメッセージ処理

ビジネス・サービスには、サービスによるメッセージ・コンテンツの処理(MTOM/XOPサポート、MIME添付ファイル、WS-I準拠のチェック、使用するXQueryバージョンなど)を定義するプロパティが含まれます。

9.1.5.1 XOP/MTOMサポート

XOP/MTOMサポートが有効なビジネス・サービスでは、アウトバウンド・メッセージをMTOM/XOP形式でエンコードできます。SOAP Message Transmission Optimization Mechanism (MTOM)は、バイナリ・データをWebサービスとの間で送受信する方法です。MTOMは、XML-binary Optimized Packaging (XOP)を使用してバイナリ・データを転送します。

Service Busでは、次のトランスポートを使用したXOP/MTOMがサポートされます。

- HTTP/S

- ローカル

- SB

$headerおよび$bodyメッセージ・コンテンツ変数のバイナリ・データは、次の2つの方法のいずれかで処理できます。

- 参照によるバイナリ・データを含む: (デフォルト)アウトバウンド・レスポンス・メッセージでの$bodyメッセージ・コンテキスト変数の設定時に、xop:Include要素をctx:binary-content要素に置換します。

- 値によるバイナリ・データを含む: アウトバウンド・レスポンス・メッセージで、$bodyメッセージ・コンテキスト変数の設定時にxop:Include要素を対応するバイナリ・データのBase64エンコード・テキスト・バージョンで置換します。

「XOP/MTOMサポート」がビジネス・サービスに対して有効になっている場合は、すべてのアウトバウンド・メッセージがMTOM形式である必要はありません。かわりに、この設定はビジネス・サービスがMTOMペイロードを処理できることを指定します。Service BusではMTOMとSwAの組合せがサポートされないため、Service Busがアウトバウンド・リクエストをビジネス・サービスにディスパッチしようとした場合、およびビジネス・サービスでMTOMとXOPの両方が有効で、$attachmentsメッセージ・コンテキスト変数がnullでない場合は、システムによって実行時エラーが発行されます。

9.1.5.2 添付ファイル

Service Busでは、HTTP/Sトランスポートを使用したMIME添付ファイルのストリーミングがサポートされます。この機能を使用すると、アウトバウンド・レスポンス・メッセージ内の添付ファイルをディスク・ファイルに格納し、添付ファイルのコンテンツをメモリーにバッファリングせずにストリーミング形式でデータを処理できます。これにより、ビジネス・サービスで、大きな添付ファイルを堅牢かつ効率的に処理できます。

XOP/MTOMサポートを有効にして「値によるバイナリ・データを含む」オプションを選択した場合、「添付ファイルのディスクへのページング」を選択しようとすると警告が表示されることに注意してください。この2つのオプションには互換性がありません。添付ファイルを含むペイロードはRFC 822に準拠している必要もあります。具体的には、インターネット・ヘッダーを含む行は、CRLF (復帰改行)で終了する必要があります。

9.1.5.3 Webサービス相互運用性への準拠

ビジネス・サービスのメッセージ処理プロパティでは、サービスがWeb Services Interoperability Organization (WS-I)で定義する基本プロファイルに準拠する必要があるかどうかを指定できます。このオプションは、SOAP 1.1サービスの場合のみ使用できます。サービスをWS-I準拠として指定すると、サービス間で送受信されるメッセージの確認が行われます。

9.2 プロキシ・サーバーの使用

メッセージをプロキシ・サーバー経由でルーティングするようにビジネス・サービスを構成するには、必要な資格証明とともに1つ以上のプロキシ・サーバーを指定するプロキシ・サーバー・リソースを作成します。その後、プロキシ・サーバー・リソースをビジネス・サービスに関連付けることができます。これにより、Service Busが、構成されたプロキシ・サーバーを使用してビジネス・サービスへの接続を行います。

複数のプロキシ・サーバーをリソースに追加すると、Service Busでロード・バランシングが実行され、構成されたプロキシ・サーバー間でフォルト・トレランスが可能になります。資格証明はプロキシ・サーバーに対する接続を開く場合に使用されます。特定のプロキシ・サーバーにアクセスできない場合、Service Busは構成に含まれる次のプロキシ・サーバーを使用しようとします。すべてのプロキシ・サーバーにアクセスできない場合、Service Busはバック・エンド・サービスへの直接接続を試みます。これにも失敗すると、フォルトが発生して呼出し元に返送されます。

プロキシ・サーバー・リソースの詳細は、「プロキシ・サーバー・リソースの操作」を参照してください。

9.3 サービス・レベル合意のアラート・ルール

サービス・レベル合意(SLA)のアラート・ルールでは、アラートの生成条件が定義されます。これらの条件は、通常、Service Busアプリケーションまたは特定のサービス・コンポーネントの全体的なヘルスのインジケータになります。ビジネス・サービスに対するSLAアラート・ルールの定義の詳細は、『Oracle Service Busの管理』のサービス・レベル合意のアラート・ルールの作成に関する項を参照してください。

9.4 ビジネス・サービスのセキュリティおよびセキュリティ・ポリシー

ビジネス・サービスは、Oracle Web Services Manager (OWSM)ポリシーや、トランスポート・レベルのアクセス制御など、複数の方法で保護できます。アウトバウンド・トランスポート・レベルのセキュリティは、プロキシ・サービスとビジネス・サービスのと間の接続に適用されます。OWSMは参照によってバインドされ、有効なWSDLファイル内にインライン化されません。OWSMでビジネス・サービスを保護する場合、ポリシーのオーバーライドも指定できます。

トランスポート・レベルのセキュリティの詳細は、「トランスポート・レベルのセキュリティの構成」を参照してください。ビジネス・サービスの保護の詳細は、「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。

9.5 ビジネス・サービスの作成

この項では、Oracle JDeveloperまたはOracle Service Busコンソールを使用して、ビジネス・サービスを作成する方法について説明します。Service Busアプリケーションおよびプロジェクトの作成の詳細は、「JDeveloperでのService Busアプリケーションおよびプロジェクトの作成」または「リソースの新しいプロジェクトおよびフォルダの作成方法」を参照してください。JDeveloperでのプロジェクト、アプリケーションおよびその他コンポーネントの操作については、『Oracle JDeveloperによるアプリケーションの開発』を参照してください。

ビジネス・サービスは、既存のサービス、JCAリソースまたはWSDLドキュメントからの生成など、様々な方法で作成できます。ビジネス・サービスを作成する場合、「ビジネス・サービスの作成」ウィザードには、ビジネス・サービスの特定のプロパティを構成できる一連のページが表示されます。この項では、「ビジネス・サービスの作成」ウィザードを使用してビジネス・サービスを作成する方法について説明します。Service Bus概要エディタの使用については、「JDeveloperでのOracle Service Busアプリケーションの開発」を参照してください。

始める前に:

SMTPサーバー、MQ接続、UDDIサーバーなどのシステム・リソースを使用する場合、ビジネス・サービスの作成を開始する前に、必ずこれらのリソースを作成します。ビジネス・サービスを構成するには、これらのリソースを指定または選択する必要があり、必要なリソースがService Busにないかぎり、ビジネス・サービスの構成を完了できません。

JDeveloperで作業する場合は、ビジネス・サービスの追加先のアプリケーションおよびプロジェクトを作成するか開きます。Oracle Service Busコンソールで作業する場合は、アクティブ・セッションで作業していることと、ビジネス・サービスの追加先のプロジェクトが存在することを確認します。

9.5.1 ビジネス・サービスの作成方法

- ビジネス・サービスを作成する場合、サービス・タイプや、WSDLファイルとService Busトランスポートのどちらを使用するかなど、特定の情報を指定する必要があります。次のトピックでは、ビジネス・サービスの作成に関する詳細情報を示します。

- ビジネス・サービス・タイプの詳細は、「ビジネス・サービスの定義」を参照してください。

- WSDLファイルの詳細は、「WSDLドキュメントの操作」を参照してください。

- 使用できる様々なトランスポートの詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください。

- ロード・バランシングの詳細は、「ロード・バランシング・アルゴリズムについて」を参照してください。

ビジネス・サービスを作成するには、サービスを作成するためにService BusコンソールまたはJDeveloperのいずれを使用するかに応じて、次のいずれかのタスクを実行します。

- Service Busコンソールを使用したビジネス・サービスの作成方法

- Service Busコンソールを使用した型付きRESTビジネス・サービスの作成方法

- SOAPからRESTウィザードを使用したSOAPサービスに基づくRESTビジネス・サービスの作成方法

- JDeveloperを使用したビジネス・サービスの作成方法

9.5.2 Service Busコンソールを使用したビジネス・サービスの作成方法

リソース・ギャラリからアクセスできるビジネス・サービスの作成ウィザードを使用して、Service Busコンソールでビジネス・サービスを作成します。

ビジネス・サービスを作成するには、次のようにします。

1. プロジェクト・ナビゲータで、サービスを作成するプロジェクトまたはフォルダを右クリックし、「作成」をポイントして、「リソース」を選択します。
リソース・ギャラリが表示されます。

2. リソース・ギャラリで、「ビジネス・サービス」をクリックして、作成するサービスのタイプにナビゲートします。この問合せを選択し、「OK」をクリックします。

注意:

ウィザードから(WADLを使用して)型付きRESTサービスを作成する手順およびSOAPからRESTウィザードを使用してSOAPサービスからRESTサービスを作成する手順は、他のビジネス・サービスの作成プロセスとは異なります。これらのタイプのサービスの作成手順は、「Service Busコンソールを使用した型付きRESTビジネス・サービスの作成方法」および「SOAPからRESTウィザードを使用したSOAPサービスに基づくRESTビジネス・サービスの作成方法」を参照してください。

3. サービスの名前と、必要に応じて説明を入力します。

注意:

命名要件については、「Service Busコンポーネントのネーミング・ガイドライン」を参照してください。

4. 手順2で選択したサービスのタイプに応じて、次のいずれかのオプションを構成する必要がある場合があります。

- 既存のWSDLファイルからビジネス・サービス構成を生成する場合は、「WSDL」オプションから、「検索」アイコンをクリックしてWSDLリソースを検索します。WSDLファイルを指定したら、「ポート/バインド」フィールドから、使用するポートまたはバインディングを選択します。

- RESTビジネス・サービスを生成する場合は、オプションで「WADL名」フィールドで「WADLリソースの選択」アイコンをクリックし、「検索と選択: WADLリソース」ダイアログを表示します。このダイアログを使用して、このサービスの生成元となるWADLリソースを検索して選択します。これにより、ネイティブの型付きRESTサービスが作成されます。ネイティブの型なしRESTサービスを作成する場合は、「WADL名」フィールドを空白にしておきます。

- トランスポートからビジネス・サービスを生成する場合は、「トランスポート」オプションから、「プロトコル」リストで正しいトランスポートが選択されていることを確認します。別のトランスポート・タイプのサービスを作成する場合は、「プロトコル」リストからそのトランスポート・タイプを選択します。

5. 「次」をクリックします。

ウィザードの残りのページのフィールドは、最初のページの選択内容によって異なります。次の手順で説明するオプションは、すべての構成で使用できるわけではありません。

6. WSDLベースまたはRESTベースのサービスを作成する場合は、手順9に進みます。

7. 最初のページでトランスポート定義を選択した場合は、使用可能なサービス・タイプのいずれかを選択します。

- WSDL: このオプションを選択する場合は、「名前」フィールドから「WSDLの選択」をクリックして、使用するWSDLファイルを参照して選択します。オプションのリストから、ポートまたはバインディング・タイプを選択します。

- REST: (オプション)「WADL名」フィールドで「WADLリソースの選択」アイコンをクリックし、「検索と選択: WADLリソース」ダイアログを表示します。このダイアログを使用して、このサービスの生成元となるWADLリソースを検索して選択します。これにより、ネイティブの型付きRESTサービスが作成されます。ネイティブの型なしRESTサービスを作成する場合は、「WADL名」フィールドを空白にしておきます。

- 任意のSOAP: このオプションを選択する場合、使用するSOAPバージョンを選択します。

- 任意のXML: このオプションに追加の構成は必要ありません。

- メッセージング: このオプションを選択する場合、リクエスト・メッセージのデータ型とレスポンス・メッセージを選択します。「MFL」を選択する場合は、スキーマ・ファイルも選択する必要があります。「XML」を選択する場合は、オプションでスキーマ・ファイルを選択できます。

8. 「次」をクリックします。

「トランスポート」ページが表示されます。

9. 使用するプロトコルをまだ選択していない場合、リストから新しいプロトコルを選択します。

10. エンドポイントURIを指定します。必要なURI形式については、Service Busに付属のオンライン・ヘルプを参照してください。

注意:

コンソールでは、リストに複数のURIを追加できます。「追加」をクリックしてから、表示される新しいURIを変更します。上下の矢印を使用してURIを並べ替えます。

11. 「作成」をクリックします。

ビジネス・サービス定義エディタに、新しいビジネス・サービスの全般構成が表示されます。

ビジネス・サービスを作成した後、「ビジネス・サービスの構成」の説明に従ってビジネス・サービスを構成します。

9.5.3 Service Busコンソールを使用した型付きRESTビジネス・サービスの作成方法

ネイティブRESTビジネス・サービスの作成ウィザードを使用して、ネイティブの型付きRESTビジネス・サービスを作成できます。このウィザードで、サービスのリソースおよびメソッドを指定します。ウィザードにより、サービスおよび使用可能なリソースとメソッドの詳細を記述するWADLファイルが作成されます。

型付きRESTサービスの詳細は、「Service BusにおけるRESTの実装」を参照してください。

コンソールでネイティブの型付きRESTビジネス・サービスを作成するには、次のようにします。

1. プロジェクト・ナビゲータで、サービスを作成するプロジェクトまたはフォルダを右クリックし、「作成」をポイントして、「リソース」を選択します。
リソース・ギャラリが表示されます。

2. リソース・ギャラリで、「ビジネス・サービス」をクリックし、「ウィザードの入力済REST(WADLを使用)」をクリックして「OK」をクリックします。
ネイティブRESTビジネス・サービスの作成ウィザードが表示されます。

3. 「基本情報」ページから、サービスの基本詳細を指定します。

a. 「名前」フィールドにサービスの名前を入力します。

b. (オプション)「説明」フィールドに説明を入力します。

c. 「ベースURI」フィールドに、サービスのベースURI (たとえば、http://example.com:7002/reservationservice)を入力します。

d. (オプション) このビジネス・サービスをターゲットとするプロキシ・サービスを作成する場合は、「仮想化」オプションを選択します。

e. 「次」をクリックします。

4. 「リソース」ページから、サービスに含めるリソースを指定します。

注意:

各サービスにはリソースが1つ以上必要です。

a. 「URI」フィールドに一意のリソース・パス(たとえば、/makeReservation)を入力します。

b. (オプション)「説明」フィールドにリソース・パスの説明を入力します。

c. 「リソースの追加」をクリックします。

d. さらにリソースを追加するには、手順aからcを繰り返します。

ヒント:

すでに追加されているリソースにリソースを子として追加するには、次の図に示すように、「リソースの追加」ボタンのかわりに、リソースの隣にある「追加」アイコンをクリックします。

e. リソースの追加が終了したら、「次」をクリックします。

5. 「メソッド」ページから、各リソースで使用可能なメソッドを指定します。

a. リソースにメソッドを追加するには、「メソッド」の隣にある矢印をクリックし、HTTP動詞をクリックして、そのHTTP動詞を使用してメソッドを追加します。

注意:

使用可能なHTTP動詞は、GET、PUT、POSTおよびDELETEです。各リソースには複数のGETメソッドを指定できますが、PUT、POSTおよびDELETEの各動詞のメソッドは1つのみです。

b. 「名前」フィールドにメソッドの名前を入力します。

c. (オプション)「説明」フィールドにメソッドの説明を入力します。

d. 「リクエスト」タブで、このメソッドのリクエストを構成します。

このタブで使用可能なオプションは、メソッドに対して選択するHTTP動詞によって異なります。

- ペイロードを構成します。ペイロードを送信しない場合は、「なし」を選択します。「メディア」を選択し、メディア・タイプを選択してペイロードがそのフォーマットで表示されるようにします(「XML」、「JSON」、「URL-エンコード」、「テキスト」または「不透明」)。

- リクエストにさらにパラメータを追加するには、「パラメータの追加」をクリックします。表示される各フィールドにパラメータ名、タイプ、デフォルト値を入力して指定し、追加するパラメータごとにこの入力を繰り返します。

- 「パラメータ名」フィールドにパラメータの名前を入力します。

- 「タイプ」リストから、パラメータのタイプ(stringまたはintegerなど)を選択します。

- 「デフォルト値」フィールドにパラメータのデフォルト値を入力します。

e. 「レスポンス」タブで、このメソッドのレスポンスを構成します。

- 成功ペイロードについて、「なし」を選択してペイロードが表示されないようにするか、または「メディア」を選択し、メディア・タイプを選択してペイロードをそのフォーマットで表示できるようにします(「XML」、「JSON」、「URL-エンコード」、「テキスト」または「不透明」)。

- 失敗ペイロードについて、「なし」を選択してペイロードが表示されないようにするか、または「メディア」を選択し、メディア・タイプを選択してペイロードをそのフォーマットで表示できるようにします(「XML」、「JSON」、「URL-エンコード」、「テキスト」または「不透明」)。

f. メソッドの構成が終了したら、「完了」をクリックします。

g. リソースにさらにメソッドを追加するには、手順aからfを繰り返します。各リソースにはメソッドが1つ以上必要です。

6. 「作成」をクリックして、サービスを作成します。

ビジネス・サービス定義エディタが表示されます。

ビジネス・サービスを作成した後、「ビジネス・サービスの構成」の説明に従ってビジネス・サービスを構成します。

9.5.4 SOAPからRESTウィザードを使用したSOAPサービスに基づくRESTビジネス・サービスの作成方法

コンソールでSOAPサービスに基づく型付きRESTビジネス・サービスを作成するには、次のようにします。

1. プロジェクト・ナビゲータで、サービスを作成するプロジェクトまたはフォルダを右クリックし、「作成」をポイントして、「リソース」を選択します。
リソース・ギャラリが表示されます。

2. リソース・ギャラリで、「ビジネス・サービス」をクリックし、「SOAPからREST」をクリックして「OK」をクリックします。
RESTビジネス・サービスの作成ウィザードが表示されます。

3. 「基本情報」ページから、サービスの基本詳細を指定します。

a. 「名前」フィールドにサービスの名前を入力します。

b. (オプション)「説明」フィールドに説明を入力します。

c. 「ベースURI」フィールドに、サービスのベースURI (たとえば、http://example.com:7002/reservationservice)を入力します。

d. (オプション) このビジネス・サービスをターゲットとするプロキシ・サービスを作成する場合は、「仮想化」オプションを選択します。

e. 「次」をクリックします。

4. 「リソース」ページから、サービスに含めるリソースを指定します。

注意:

各サービスにはリソースが1つ以上必要です。

a. 「URI」フィールドに一意のリソース・パス(たとえば、/makeReservation)を入力します。

b. (オプション)「説明」フィールドにリソース・パスの説明を入力します。

c. 「リソースの追加」をクリックします。

d. さらにリソースを追加するには、手順aからcを繰り返します。

ヒント:

すでに追加されているリソースにリソースを子として追加するには、次の図に示すように、「リソースの追加」ボタンのかわりに、リソースの隣にある「追加」アイコンをクリックします。

e. リソースの追加が終了したら、「次」をクリックします。

5. 「メソッド」ページから、各リソースで使用可能なメソッドを指定します。

a. リソースにメソッドを追加するには、「メソッド」の隣にある矢印をクリックし、HTTP動詞をクリックして、そのHTTP動詞を使用してメソッドを追加します。

注意:

使用可能なHTTP動詞は、GET、PUT、POSTおよびDELETEです。各リソースには複数のGETメソッドを指定できますが、PUT、POSTおよびDELETEの各動詞のメソッドは1つのみです。

b. 「名前」フィールドにメソッドの名前を入力します。

c. (オプション)「説明」フィールドにメソッドの説明を入力します。

d. 「リクエスト」タブで、このメソッドのリクエストを構成します。

注意:

このタブで使用可能なオプションは、メソッドに対して選択するHTTP動詞によって異なります。

- 「スキーマ」フィールドから、「XMLスキーマの選択」アイコンをクリックして、リクエストにマップする操作を含むXMLスキーマを検索して選択します。

- 「要素」リストから、リクエスト操作に一致する要素を選択します。該当する場合、選択した要素に基づいてService Busで自動的にパラメータと各パラメータのパラメータ名、タイプ、式およびデフォルト値が移入されます。

- ペイロードを構成します。ペイロードを送信しない場合は、「なし」を選択します。「メディア」を選択し、メディア・タイプを選択してペイロードがそのフォーマットで表示されるようにします(「XML」、「JSON」または「URL-エンコード」)。

- リクエストにさらにパラメータを追加するには、「パラメータの追加」をクリックします。表示される各フィールドにパラメータ名、タイプ、XPath式およびデフォルト値を入力して指定し、追加するパラメータごとにこの入力を繰り返します。

注意:

スキーマ要素から移入されたパラメータの値を編集することもできます。

- 「パラメータ名」フィールドにパラメータの名前を入力します。

- 「タイプ」リストから、パラメータのタイプ(stringまたはintegerなど)を選択します。

- 「式」フィールドに、パラメータのXPath式関数を入力します。式エディタ・ウィンドウは表示されないため、該当するパラメータのXPath式を知っている必要があります。

- 「デフォルト値」フィールドにパラメータのデフォルト値を入力します。

e. 「レスポンス」タブで、このメソッドのレスポンスを構成します。

- 「HTTPステータス」フィールドに、レスポンスとともに送信されるHTTPステータス(空白区切り)を入力します。

- ペイロードについて、「なし」を選択してペイロードが表示されないようにするか、または「メディア」を選択し、メディア・タイプを選択してペイロードをそのフォーマットで表示できるようにします(「XML」、「JSON」または「URL-エンコード」)。

- 「スキーマ」フィールドから、「XMLスキーマの選択」アイコンをクリックして、レスポンスにマップする操作を含むXMLスキーマを検索して選択します。

- 「要素」リストから、レスポンスにマップする要素を選択します。

f. (オプション)「フォルト」タブで、このメソッドのフォルトを構成します。

- 「フォルトの追加」をクリックして、このメソッドのフォルトを追加します。

- 「フォルト名」フィールドにフォルトの名前を入力します。

- 「HTTPステータス」フィールドに、フォルトとともに送信されるHTTPステータス(空白区切り)を入力します。

- フォルト・ペイロードについて、「なし」を選択してペイロードが表示されないようにするか、または「メディア」を選択し、メディア・タイプを選択してペイロードをそのフォーマットで表示できるようにします(「XML」、「JSON」または「URL-エンコード」)。

- 必要に応じて、これらの手順を繰り返してさらにフォルトを追加します。

g. メソッドの構成が終了したら、「完了」をクリックします。

h. リソースにさらにメソッドを追加するには、手順aからgを繰り返します。各リソースにはメソッドが1つ以上必要です。

6. 「作成」をクリックして、サービスを作成します。

ビジネス・サービス定義エディタが表示されます。

サービスを作成した後、「ビジネス・サービスの構成」の説明に従ってサービスを構成します。

9.5.5 JDeveloperを使用したビジネス・サービスの作成方法

ビジネス・サービスの作成ウィザードを使用して、WSDLファイルに基づくビジネス・サービス、トランスポートに基づくビジネス・サービスおよびネイティブの型なしRESTサービスを作成します。

ネイティブの型付きRESTビジネス・サービスとWSDLファイルに基づくRESTビジネス・サービスの作成方法は、「JDeveloperを使用したService Bus用の入力済RESTサービスの作成方法」および「JDeveloperを使用したService Bus用のWSDLベースRESTサービスの作成方法」を参照してください。

ビジネス・サービスを作成するには、次のようにします。

1. アプリケーション・ナビゲータで、プロジェクトを右クリックして、「新規」をポイントし、「ビジネス・サービス」を選択します。

「ビジネス・サービスの作成」ウィザードが表示されます。

2. サービスの名前と、必要に応じて説明を入力します。

注意:

- JDeveloperでは、ビジネス・サービス・ファイルがサーバーに格納される場所を変更できます。ファイルは、アプリケーション・フォルダおよびプロジェクト・フォルダ(デフォルトの場所)に格納する必要があります。

- 命名要件については、「Service Busコンポーネントのネーミング・ガイドライン」を参照してください。

3. 次のいずれかを行います:

- ネイティブの型なしRESTサービスを生成するには、「REST」を選択します。

- トランスポートを構成してビジネス・サービスを生成するには、「トランスポート」を選択して、トランスポートのタイプをリストから選択します。

- 既存のWSDLファイルからビジネス・サービス構成を生成するには、「WSDL」を選択してWSDLファイルの名前を入力するか、「検索」アイコンをクリックしてWSDLリソースを検索します。WSDLファイルを指定したら、「ポート/バインド」フィールドから、使用するポートまたはバインディングを選択します。

4. 「次」をクリックします。

ウィザードの残りのページのフィールドは、最初のページの選択内容によって異なります。次の手順で説明するオプションは、すべての構成で使用できるわけではありません。

5. 最初のページでWSDLまたはREST定義を選択した場合、手順8に進みます。

6. 最初のページでトランスポート定義を選択した場合は、次のいずれかのサービス・タイプを選択します。

- REST: このオプションに追加の構成は必要ありません。

- WSDL: このオプションを選択する場合、WSDLファイル名を入力するか、「WSDLの選択」をクリックして、使用するWSDLファイルを参照して選択します。オプションのリストから、ポートまたはバインディング・タイプを選択します。

- 任意のSOAP: このオプションを選択する場合、使用するSOAPバージョンを選択します。

- 任意のXML: このオプションに追加の構成は必要ありません。

- メッセージング: このオプションを選択する場合、リクエスト・メッセージのデータ型とレスポンス・メッセージを選択します。「MFL」を選択する場合は、スキーマ・ファイルも選択する必要があります。「XML」を選択する場合は、オプションでスキーマ・ファイルを選択できます。

7. 「次」をクリックします。

「トランスポート」ページが表示されます。

8. 使用するプロトコルをまだ選択していない場合、リストから新しいプロトコルを選択します。

9. エンドポイントURIを指定します。必要なURI形式については、Service Busに付属のオンライン・ヘルプを参照してください。

注意:

JDeveloperでは、ビジネス・サービスの構成時に複数のURIを追加できます。

10. 「終了」をクリックします。

ビジネス・サービス定義エディタに、新しいビジネス・サービスの全般構成が表示されます。

11. 「ビジネス・サービスの構成」の説明に従い、ビジネス・サービスを構成します。

9.5.6 JCAバインド・リソースからのビジネス・サービスの生成方法

Service Busでは、アウトバウンドJCAバインド・リソースからビジネス・サービスを生成できます。Service Bus JCAトランスポートを使用するJCAサービスは、JCAアダプタ・フレームワークおよびJCA準拠アダプタを介してEnterprise Information Systems (EIS)と通信します。JCAバインド・リソースの詳細は、「JCAトランスポートとJCAアダプタの使用」を参照してください。

始める前に:

JDeveloperで、JCAファイル、その関連抽象WSDLファイルおよび必要なその他のリソース(TopLinkマッピング・ファイルなど)を作成します。詳細は、「JCAトランスポートとJCAアダプタの使用」および「テクノロジ・アダプタの理解」を参照してください。

注意:

- アウトバウンドJCAバインドではなくインバウンドJCAバインドを選択する場合、ビジネス・サービスを生成するオプションは利用できません。

- JDeveloperでは、JCAアダプタをService Bus概要エディタから作成する場合、アダプタの作成時にビジネス・サービスも生成できます。詳細は、「ビジネス・サービスの作成方法」を参照してください。

9.5.6.1 JDeveloperでのJCAバインドからのビジネス・サービスの生成

JDeveloperでJCAバインドからビジネス・サービスを生成するには:

1. アプリケーション・ナビゲータで、アウトバウンドJCAファイルを右クリックして、「Service Bus」をポイントし、「ビジネス・サービスの生成」を選択します。

選択したJCAバインドに対して構成された「ビジネス・サービスの作成」ウィザードが表示されます。

2. ウィザードで、デフォルトのサービス名と場所のままにするか、新しい名前と場所を指定します。場所は、現在のアプリケーションのディレクトリ構造内にしてください。

命名ガイダンスについては、「Service Busコンポーネントのネーミング・ガイドライン」を参照してください。

3. 「次」をクリックします。

「タイプ」ページが表示されます。

4. 必要に応じてWSDLバインドを選択して、「次」を再度クリックします。

「トランスポート」ページが表示されます。

5. 必要に応じてエンドポイントURIを更新して、「終了」をクリックします。

Service Busによって、ビジネス・サービスと、そのビジネス・サービスが使用する具象WSDLファイルが生成されます。

6. 「ビジネス・サービスの構成」の説明に従い、ビジネス・サービスを構成します。

9.5.6.2 コンソールでのJCAバインドからのビジネス・サービスの生成

始める前に、JCAリソース・ファイルをJDeveloperからコンソールにインポートし、依存関係へのすべての参照が維持されるようにします。詳細は、「JCAバインド・リソースの操作」および「リソースおよび構成のインポートとエクスポート」を参照してください。

コンソールでJCAバインドからビジネス・サービスを生成するには:

1. プロジェクト・ナビゲータで、アウトバウンドJCAファイルを右クリックして、「WSDLとサービスの生成」を選択します。

「WSDLとサービスの生成」ダイアログが表示されます。

2. 必要に応じて、WSDLファイルと生成するサービスの名前を変更し、これらの新しいリソースの場所を選択します。

命名ガイダンスについては、「Service Busコンポーネントのネーミング・ガイドライン」を参照してください。

3. 「生成」をクリックします。

Service Busによって、サービスとこれに対応するWSDLファイルが生成されます。

4. プロジェクト・ナビゲータで、新しいリソースに移動し、ビジネス・サービス定義エディタでビジネス・サービスを開きます。

5. 「ビジネス・サービスの構成」の説明に従い、ビジネス・サービスを構成します。

9.5.7 JDeveloperでのプロキシ・サービスからのビジネス・サービスの生成方法

JDeveloperでは、作成するプロキシ・サービスからビジネス・サービスを生成できます。ビジネス・サービスの構成は、プロキシ・サービスの構成に基づきます。

JDeveloperでプロキシ・サービスからビジネス・サービスを生成するには:

1. アプリケーション・ナビゲータで、既存のプロキシ・サービスを右クリックして、「Service Bus」をポイントし、「ビジネス・サービスの生成」を選択します。

「ビジネス・サービスの作成」ウィザードが表示されます。

2. サービスの名前、説明、ファイルの場所を構成し、「次」をクリックします。

「タイプ」ページが表示されます。

3. サービスがWSDLサービスの場合、使用するバインディングを選択して、「次」をクリックします。

4. 「トランスポート」ページで、トランスポート・プロトコルを選択してエンドポイントURIを更新します。必要なURI形式については、Service Busに付属のオンライン・ヘルプを参照してください。

5. 「終了」をクリックします。

6. 「ビジネス・サービスの構成」の説明に従い、ビジネス・サービスを構成します。

9.5.8 JDeveloperでのWSDLドキュメントからのビジネス・サービスの生成方法

既存のWSDLドキュメントを使用して、プロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合を生成できます。

JDeveloperでWSDLドキュメントからビジネス・サービスを生成するには:

1. アプリケーション・ナビゲータで、既存のWSDLドキュメントを右クリックして、「Service Bus」をポイントし、「ビジネス・サービスの生成」を選択します。

「ビジネス・サービスの作成」ウィザードが表示されます。

2. サービスの名前、説明、ファイルの場所およびWSDLバインドを構成し、「次」をクリックします。

3. 「トランスポート」ページで、トランスポート・プロトコルを選択してエンドポイントURIを更新します。必要なURI形式については、Service Busに付属のオンライン・ヘルプを参照してください。

4. 「終了」をクリックします。

5. 「ビジネス・サービスの構成」の説明に従い、ビジネス・サービスを構成します。

9.6 ビジネス・サービスの構成

ビジネス・サービスを作成すると、構成の編集、セキュリティ・ポリシーの追加、セキュリティ設定の変更およびSLAアラート・ルールの設定を行うことができます。変更できる情報は、最初にサービスを構成した方法によって異なります。ビジネス・サービスに構成可能なすべてのプロパティのリストについては、ビジネス・サービス定義エディタの各ページで利用可能なオンライン・ヘルプを参照してください。

Oracle Service Busコンソールで作業する場合は、この項のタスクを実行する前に、アクティブ・セッションにいることを確認してください。

9.6.1 ビジネス・サービスの全般情報の構成方法

ビジネス・サービス定義エディタの「全般」タブには、サービスに関する情報(サービスの説明、サービスで使用されるトランスポート、サービス・タイプ、WSDLのポートまたはバインディングなど)が表示されます。このページでは、説明のみを変更できます。次の図に、Oracle Service Busコンソールの「全般」タブを示します。

図9-1 コンソールでのビジネス・サービスの全般的な構成のページ

ビジネス・サービスの全般情報を構成するには:

1. プロジェクト・ナビゲータまたはアプリケーション・ナビゲータで、編集するビジネス・サービスを右クリックして、「開く」をクリックします。

2. まだ表示可能なページではない場合は、「全般」タブをクリックします。

3. サービスの説明を入力するか更新します。

4. WSDLまたはMFLドキュメントなどのリソースをサービスで参照している場合、リソースの名前をクリックして、それ自体のエディタでドキュメントを表示します。

5. 変更が完了したら、「すべて保存」をクリックします。

6. Oracle Service Busコンソールで作業している場合、「アクティブ化」をクリックして、セッションを終了し、構成をランタイムにデプロイします。

9.6.2 ビジネス・サービスのトランスポートの構成方法

「トランスポート」ページと「トランスポートの詳細」ページを使用して、ビジネス・サービスのトランスポートを構成します。使用可能なプロパティはトランスポートごとに異なります。次の図に、Oracle Service Busコンソールの「トランスポート」タブを示します。

図9-2 コンソールでのビジネス・サービスのトランスポートの構成のページ

ビジネス・サービスのトランスポートを構成するには:

1. プロジェクト・ナビゲータまたはアプリケーション・ナビゲータで、編集するビジネス・サービスを右クリックして、「開く」をクリックします。

2. 「トランスポート」タブをクリックして、次のいずれかを行います。

- ロード・バランシング・アルゴリズムを変更するには、使用可能なオプションのリストから新しいアルゴリズムを選択します。
詳細は、「ロード・バランシング・アルゴリズムについて」を参照してください。

- エンドポイントURIを更新または追加します。詳細は、このページで提供されるオンライン・ヘルプを参照してください。

- 「再試行回数」フィールドで、URIエンドポイントを再試行する回数を指定します。

- 「再試行の反復間隔」フィールドで、すべてのURIの試行後、再試行するまでに待機する秒数を指定します。

- 「アプリケーション・エラーの再試行」を選択または選択解除して、アプリケーション・エラーを再試行するかどうかを指定します。

3. 「トランスポートの詳細」タブをクリックします。

ここで構成できるプロパティは、ビジネス・サービスのトランスポートに基づきます。特定のトランスポートの詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」または「トランスポートの詳細」タブのオンライン・ヘルプを参照してください。

4. 変更が完了したら、「すべて保存」をクリックします。

5. Oracle Service Busコンソールで作業している場合、「アクティブ化」をクリックして、セッションを終了し、構成をランタイムにデプロイします。

9.6.3 ビジネス・サービスのメッセージ処理の構成方法

「メッセージ処理」ページで、ビジネス・サービスによるメッセージ・コンテンツの処理方法(MTOM/XOPサポート、添付ファイル、WS-I準拠の確認、使用するXQueryバージョンなど)を構成できます。次の図に、Oracle Service Busコンソールの「メッセージ処理」タブを示します。

図9-3 コンソールでのビジネス・サービスのメッセージ処理のページ

ビジネス・サービスのメッセージ処理を構成するには:

メッセージ処理プロパティの詳細は、「ビジネス・サービスのメッセージ処理」を参照してください。

1. プロジェクト・ナビゲータまたはアプリケーション・ナビゲータで、編集するビジネス・サービスを右クリックして、「開く」をクリックします。

2. 「メッセージ処理」タブをクリックします。

3. XOP/MTOMサポートを有効にするには、「XOP/MTOM有効」を選択して、バイナリ・データを参照または値のどちらで含めるかを選択します。

4. MIME添付ファイルの処理方法を指定するには、「添付ファイルのディスクへのページング」を選択または選択解除します。

5. メッセージがWS-Iに準拠しているかどうかを確認するには、「WS-I準拠の適用」のチェック・ボックスを選択します。

6. 処理に使用するXQueryのバージョン(2004または1.0)を選択します。

注意:

お薦めするバージョンは、XQuery 1.0です。XQuery 2004のサポートは、将来のリリースで非推奨になる予定です。

7. (オプション) WSDLベースのRESTサービスを構成している場合は、「XMLスキーマの順序付けの適用」オプションを選択して、XMLスキーマ内の要素の順序と一致するようにJSONペイロードを並べ替えます。これには、インバウンド・リクエスト・ペイロードおよびアウトバウンド・リクエストからのレスポンスが含まれます。

8. 変更が完了したら、「すべて保存」をクリックします。

9. Oracle Service Busコンソールで作業している場合、「アクティブ化」をクリックして、セッションを終了し、構成をランタイムにデプロイします。

9.6.4 ビジネス・サービスのパフォーマンスの構成方法

「パフォーマンス」タブで、結果キャッシュを構成して、ビジネス・サービスのパフォーマンスを改善できます。詳細は、「ビジネス・サービスの結果のキャッシュによるパフォーマンスの改善」を参照してください。手順については、「結果キャッシュのビジネス・サービスの構成方法」を参照してください。

9.6.5 ビジネス・サービスのセキュリティの構成方法

ビジネス・サービスは、Oracle Web Services Manager (WSM)ポリシーや、トランスポート・レベルのアクセス制御など、複数の方法で保護できます。ビジネス・サービスの保護の詳細は、「ビジネス・サービスのセキュリティおよびセキュリティ・ポリシー」と「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。

9.6.6 ビジネス・サービスのサービス・レベル合意のアラートの構成方法

SLAアラートにより、システム管理者は、ビジネス・サービスのヘルスを示す特定の条件が満たされるタイミングを把握できます。SLAアラートの定義の詳細は、『Oracle Service Busの管理』のサービス・レベル合意のアラート・ルールの作成に関する項を参照してください。

9.7 ビジネス・サービスの削除

ビジネス・サービスが他のリソースで参照される場合でも、そのサービスを削除できますが、削除されたリソースに対する未解決の参照が原因で競合が生じることがあります。

9.7.1 ビジネス・サービスの削除方法

ビジネス・サービスを削除する前に、依存関係を確認してください。Oracle Service Busコンソールの場合、ビジネス・サービス定義エディタでビジネス・サービスを開き、右上のツール・アイコンをクリックし、「参照」を選択して、いずれかのサービスでそのビジネス・サービスを使用しているかどうかを確認します。JDeveloperでは、ビジネス・サービスを右クリックして、「依存性の参照」を選択します。

ビジネス・サービスを削除するには:

1. プロジェクト・ナビゲータまたはアプリケーション・ナビゲータで、削除するビジネス・サービスを右クリックして、「削除」を選択します。

確認のダイアログが表示されます。

2. JDeveloperでは、他のリソースでこのビジネス・サービスを参照する場合、確認ダイアログに参照の数が表示されます。「使用方法の表示」をクリックして、参照に関する情報を表示します。

3. 確認のダイアログで、「はい」をクリックして、サービスの削除を確定します。

ビジネス・サービスが削除されます。

4. Oracle Service Busコンソールで作業している場合、「アクティブ化」をクリックして、セッションを終了し、構成をランタイムにデプロイします。

9.8 ビジネス・サービスの結果のキャッシュによるパフォーマンスの改善

頻繁に変更されることのない結果を返すビジネス・サービスを使用する場合、それらのビジネス・サービスが結果をキャッシュするよう構成できます。結果のキャッシュを有効にすると、サービスは、外部サービスを呼び出すのではなく、キャッシュから結果を返します。これにより、外部サービスにアクセスするネットワーク・オーバーヘッドが減り、パフォーマンスが向上します。結果キャッシュによって、外部サービスをホストするバックエンド・サービスの負荷が削減され、スケーラビリティの向上にもつながります。

この項で、結果キャッシュとは、すべてのビジネス・サービスで共有し、各結果を格納するキャッシュ自体のことで、キャッシュされた結果とは、結果キャッシュ内の各結果のことです。結果キャッシュを使用するビジネス・サービスでは、キャッシュされた結果の存続時間を制御できます。キャッシュされた結果の有効期限に達すると、次のビジネス・サービス・コールによってバックエンド・サービスが呼び出され、結果が取得されます。この結果はキャッシュに格納され、以降のアクセス・リクエストに使用されます。

Service Busで使用される結果キャッシュのメカニズムは、WebLogic Serverに含まれているOracle Coherenceです。Service Busの結果キャッシュの実装には、グロバールな有効化/無効化、キャッシュ・メッセージ変数、各ビジネス・サービスの構成フィールド、およびサービス統計、デバッグ、アラート・ルールに関するキャッシュ・オプションが含まれます。

9.8.1 結果キャッシュの仕組み

図9-4に、ビジネス・サービスを呼び出し、キャッシュされた結果を含むレスポンスを受け取るクライアントを示します。

注意:

結果キャッシュは、リクエスト/レスポンス操作についてのみ機能します。

図9-4 ビジネス・サービスの結果キャッシュ

キャッシュされた各結果は、ServiceRef (完全修飾されたサービスのパス名であるサービスの一意の識別子)、呼び出される操作およびキャッシュ・トークン文字列で構成されるキャッシュ・キーによって一意に識別されます。キャッシュ・トークンは、あるビジネス・サービスの1つのキャッシュ結果を他のキャッシュ結果から一意に識別する場合に役立ちます。キャッシュ・トークンの値は制御されます。キャッシュ・トークンを設定するには、ビジネス・サービスの結果キャッシュ構成でキャッシュ・トークン式を構成するか、パイプラインを使用する$transportMetaDataでcache-tokenメタデータ要素を使用します。

ビジネス・サービスで、キャッシュ・キーを使用してキャッシュされた結果が特定されると、外部サービスを直接呼び出すかわりにキャッシュされた結果がクライアントに返されます。

図9-4で、実線の矢印は、クライアントとキャッシュされた結果とのメッセージ・パスを表します。点線の矢印は、キャッシュされた結果がない場合のメッセージ・パスを表します。キャッシュされた結果がない場合、ビジネス・サービスは外部サービスを直接呼出し、結果をクライアントに返して、結果をキャッシュに格納します。初めての呼出しでキャッシュがまだない、キャッシュのエラー、キャッシュがフラッシュされたなどの様々な理由から、結果キャッシュが空の場合があります。

キャッシュされた結果には、キャッシュの有効期限として存続時間(TTL)属性があります。キャッシュの有効期限は、ビジネス・サービスの結果キャッシュ構成の「有効期限」プロパティまたはパイプラインを使用する$transportMetaDataでcache-ttl要素を使用して構成できます。CoherenceでTTLの期限が過ぎていることが検出されると、キャッシュがフラッシュされ、ビジネス・サービスによって外部サービスが呼び出されて結果が取得されます。結果はキャッシュに格納され(結果にエラーがない場合)、次のリクエストで返すことができるようになります。

9.8.1.1 キャッシュされた結果のフラッシュ

Service BusとCoherenceを組み合せて使用すると、キャッシュされた結果を個別にフラッシュすることや、ビジネス・サービスのキャッシュされた結果をすべてフラッシュすることが可能です。次のイベントは、キャッシュがどのようにフラッシュされるかについて示しています。

- キャッシュのTTLの期限は過ぎています。キャッシュされたそれぞれの結果には独自のTTLがあります。TTLに達すると、Coherenceによってキャッシュされた個々の結果がフラッシュされます。

- 1つのビジネス・サービスに関する結果キャッシュを無効にします。1つのビジネス・サービスに関する結果キャッシュを無効にすると、Service Busでは、そのビジネス・サービスについてキャッシュされたすべての結果がCoherenceでフラッシュされます。

- ビジネス・サービスの更新、名前変更または削除を行います。これらのアクションによって、そのビジネス・サービスについてキャッシュされたすべての結果のCoherenceからのフラッシュがトリガーされます。

- 従属するリソースを更新します。WSDLドキュメントなど、従属するリソースを更新すると、そのビジネス・サービスについてキャッシュされたすべての結果のCoherenceからのフラッシュがトリガーされます。ただし、サービス・プロバイダ、UDDIレジストリ、アラート宛先といった従属リソースに対する変更ではキャッシュはフラッシュされません。

- 結果キャッシュをグローバルに無効化します。結果キャッシュをグローバルに無効にすると、結果キャッシュ全体(すべてのビジネス・サービスについてキャッシュされたすべての結果)のCoherenceからのフラッシュがトリガーされます。

9.8.2 結果キャッシュのベスト・プラクティス

キャッシュされた結果によって外部サービスは直接呼び出されなくなるため、静的でないサービス・アカウントまたはWS-Securityポリシーにセキュリティを提供するビジネスサービスには、結果キャッシュを使用しないでください。本番で結果キャッシュを使用するService Bus環境をデプロイする前に、『Oracle Coherenceでのアプリケーションの開発』の構成の理解に関する説明に従い、Coherenceの設定と構成の計画および実装を行って最適なパフォーマンスが得られるようにする必要があります。

9.8.3 結果キャッシュのエントリの削除方法

Oracle Service Busには、OSB結果キャッシュからエントリを削除するためのAPIが用意されています。APIを使用すると、単一のエントリを削除することも、特定のビジネス・サービスのエントリをすべて削除することもできます。APIは、JMXインタフェース(MBean)から公開されます。

ResultCacheRuntimeMBeanは、キャッシュされたエントリを結果キャッシュから削除するAPIを提供します。ドメインごとに、このMBeanのインスタンスが1つあります。ResultCacheRuntimeMBeanは、Javaコールアウトから呼び出せます。インタフェースには、次のメソッドがあります。

/**
* MBean for deleting result cache entry
*/
public interface ResultCacheRuntimeMBean {
/**
* Method to remove an entry from the resultcache
*
* @param ref
*            the reference for the resource
* @param operation
*            Applicable for WSDL based services
NULL for any Xml type.
* @param token
*            the token
* @throws Exception
*             thrown if there are semantic validation errors
*/
public void deleteCacheEntry (Ref ref,String operation, String token) throws Exception;
/**
* Method to delete all cached service data for a specific business service.
*
* @param ref
*            the reference for the resource to remove cache entries from
*
* @throws Exception
*             thrown if there are semantic validation errors
*/
public void deleteAllCacheEntriesFromServiceRef (Ref ref) throws Exception;

APIは、サービス参照(結果キャッシュが構成されているビジネス・サービスRefオブジェクト)、操作名(WSDLベースのサービスの場合に呼び出されるサービス・メソッドで、XMLタイプのメッセージの場合はNULL)、およびキャッシュ・トークンを取得して、結果キャッシュから単一のエントリを削除します。

「結果キャッシュの構成」では、WSDLベースのビジネス・サービスの場合の、結果キャッシュのサンプル構成を示しています。顧客IDは、FindCustomer Webサービス・コールから返された結果をキャッシュするキャッシュ・トークンとして使用されます。この構成では、評価済のXQuery式に対して返されるWebサービス・レスポンスがキャッシュされます。

図9-5 結果キャッシュの構成

次のコード・スニペットでは、MBean APIを呼び出し、たとえば顧客ID10に対応するキャッシュされた結果を削除する方法を示しています。Javaコールアウトを使用して、それをパイプラインから呼び出し、キャッシュされたエントリを削除するビジネス・サービス名、Webサービスの操作名およびキャッシュ・トークンを渡すことができます。

//Initialize the JMXConnector
JMXConnector conn =  initConnection(machine,Integer.parseInt(adminPort),username,password);
MBeanServerConnection mbconn = conn.getMBeanServerConnection();
ObjectName resultCacheObj = new ObjectName(ResultCacheRuntimeMBean.OBJECT_NAME);
ResultCacheRuntimeMBean resultCacheRuntimeMBean
= (ResultCacheRuntimeMBean) MBeanServerInvocationHandler.newProxyInstance(mbconn,
mbconn.queryNames(resultCacheObj, null).iterator().next(),
ResultCacheRuntimeMBean.class, false);
String cacheBizRefPath =  "resultcache/CacheBiz";
String[] arrayOfRef =  cacheBizRefPath.split("/");
Ref cacheBizRef = new Ref("BusinessService", arrayOfRef);
// Removes the result cached entry corresponding to the customer id 10
resultCacheRuntimeMBean. deleteCacheEntry(cacheBizRef, “FindCustomer”, “10”);

9.8.4 結果キャッシュのメタデータ

結果キャッシュでは、キャッシュ・キーを使用して、キャッシュされた結果を識別し、有効期限を使用して、キャッシュされた結果をフラッシュするタイミングを判断します。

- キャッシュ・トークン

- 有効期限

- リクエスト・メタデータ

- レスポンス・メタデータ

9.8.4.1 キャッシュ・トークン

Service Busでは、キャッシュ・キーを使用して取得または移入するキャッシュ結果を識別し、キャッシュ・キーのキャッシュ・トークン部分は一意の識別子として使用されます。式(キャッシュ・トークン式)を使用して、ビジネス・サービスのキャッシュされた結果を一意に識別するキャッシュ・キーのキャッシュ・トークン部分を生成できます。リクエスト(ビジネス・サービスを起動するパイプラインまたは分割-結合内)の値からキャッシュ・トークンを生成する場合、パイプライン$body、$header、$operationまたは$transportMetaData ($outbound/ctx:transport/ctx:requestまたは$outbound/ctx:transport/ctx:response)から値を取得する式を使用します。たとえば、メッセージ$body内の顧客IDからcache-tokenに移入できます。

キャッシュ・トークン式は、文字列または、属性や子要素のない要素などの単純な内容に解決される必要があります。式がNULLに評価されるか、エラーが発生すると、結果はキャッシュされません。ビジネス・サービス構成でキャッシュ・トークン式を設定せずに、リクエストからキャッシュ・トークンを生成することもできます。これを行うには、パイプラインの$outbound/ctx:transport/ctx:request/ctx:cache-tokenに値を含めます。このcache-tokenの値は、ビジネス・サービス構成のキャッシュ・トークン式をオーバーライドします。

9.8.4.2 有効期限

有効期限すなわち存続時間(TTL)は、ビジネス・サービスの結果キャッシュのエントリがいつフラッシュされるかを決定します。デフォルトの有効期限を使用して、結果キャッシュがフラッシュされるまでの期間を制限するか、リクエストまたはレスポンスの値から有効期限を生成する式を定義できます。デフォルトの有効期限は、resultcache.garのosb-coherence-cache-config.xmlファイルにあるexpiry-delayの値で定義されます。期間は、ビジネス・サービス構成で直接定義できます。

リクエストまたはレスポンス内の値から有効期限を生成するには、パイプラインまたは分割-結合$body、$header、$operationまたは$transportMetaData ($outbound/ctx:transport/ctx:requestまたは$outbound/ctx:transport/ctx:response)から値を取得する式を使用します。たとえば、Cache-Control HTTPヘッダーに設定した値を使用します。

有効期限は、整数(秒数を表す)、XQuery dayTimeDuration (XSDタイプ)または属性や子要素のない要素など、秒を表す単純な内容の整数値に解決される必要があります。式がNULLに評価されるか、エラーが発生すると、結果はキャッシュされません。

ビジネス・サービス構成で有効期限を設定しなくても、リクエストから有効期限を生成することもできます。これを行うには、パイプラインまたは分割-結合の$outbound/ctx:transport/ctx:request/ctx:cache-ttlに値を含めます。このcache-ttl要素の値が、ビジネス・サービス構成の有効期限をオーバーライドします。

9.8.4.3 リクエスト・メタデータ

結果キャッシュに使用されるリクエスト・メタデータには、cache-tokenおよびcache-ttl (両方とも文字列値)が含まれます。両方ともビジネス・サービス構成で構成できます。ビジネス・サービスでキャッシュ・トークンまたはTTLを未定義のままにすることも、リクエストでキャッシュ・トークンまたはTTLにこれらのメタデータを指定することもできます。リクエストでキャッシュ・トークンまたはTTLを設定すると、これらの値によって、ビジネス・サービス構成で定義されたキャッシュ・トークンまたはTTLがオーバーライドされます。

式(キャッシュ・トークン式またはTTL、あるいはその両方)を使用して結果キャッシュを構成する場合、式で使用するネームスペースと対応する接頭辞を入力できます。このフィールドでは、既存のネームスペースのリストを表示することもできます。

9.8.4.4 レスポンス・メタデータ

結果キャッシュに使用されるレスポンス・メタデータは、次のとおりです。

- cache-token: 結果キャッシュからのコンテンツの取得または外部サービスの呼出し後の結果キャッシュへのコンテンツの追加に使用されたキャッシュ・トークンが含まれます。

- cache-originated: ブール値(trueまたはfalse)が含まれます。trueの値は、返された結果が結果キャッシュからのものあることを表します。falseの値は、返された値が外部サービスの呼出しによるものであることを示します。

9.8.5 結果キャッシュのテスト

結果キャッシュは、結果キャッシュが構成されているビジネス・サービスが、パイプラインまたは分割-結合から(ルートまたはサービス・コールアウト・アクティビティなどを使用して)呼び出された場合のみ有効です。したがって、結果キャッシュをテストする場合、ビジネス・サービスをテスト・コンソールから直接起動しないでください。かわりに、テスト・コンソールを使用して、ビジネス・サービスを呼び出すパイプラインまたは分割-結合をテストします。

9.8.6 結果キャッシュのビジネス・サービスの構成方法

いくつかの変更が結果に含まれるビジネス・サービスを呼び出す場合は、結果キャッシュを使用すると、ビジネス・サービスのパフォーマンスが向上します。外部サービスを直接呼び出すかわりにキャッシュした結果をクライアントに返すためです。ビジネス・サービスの結果キャッシュは、Oracle Service Busコンソールでのみ構成できます。

キャッシュ・トークン式と有効期限式のどちらの場合も、式エディタを使用して式を定義します。式エディタの操作の詳細は、「XQueryでのデータの変換」を参照してください。次のイメージは、結果キャッシュを構成するOracle Service Busコンソールの「パフォーマンス」タブを示します。

図9-6 コンソールでのビジネス・サービスのパフォーマンスのページ

結果キャッシュを構成するには:

1. Oracle Service Busコンソールのプロジェクト・ナビゲータで、構成するビジネス・サービスに移動してそのサービスを開きます。

2. ビジネス・サービス定義エディタで、「パフォーマンス」サブタブを選択します。

3. 「結果キャッシュのサポート」を選択します。

注意:

結果キャッシュがここで有効な場合でも、『Oracle Service Busの管理』のグローバル・レベルでの操作設定の構成に関する項の説明に従い、Fusion Middleware Controlでも結果キャッシュを有効にする必要があります。

4. キャッシュ・キーのキャッシュ・トークン・パートを生成する式を定義するには、「キャッシュ・トークン式」フィールドの横の「式エディタ」アイコンをクリックします。

キャッシュ・トークン式の詳細は、「キャッシュ・トークン」を参照してください。

5. ビジネス・サービスの結果キャッシュの有効期限を定義するには、次のいずれかを選択します。

- デフォルト: このオプションでは、resultcache.garのosb-coherence-cache-config.xmlファイルにあるexpiry-delayの値を使用します。デフォルトは5分です。

- 期間: このオプションでは、存続時間を指定します。「日」フィールドと「時間:分:秒」フィールドを使用して、期間を定義します。

- XQuery式: このオプションでは、リクエストまたはレスポンスから有効期限を取得するXQuery式を使用ます。式を定義するには、「式」フィールドの横の「式エディタ」アイコンをクリックします。式を定義した後、リクエストとレスポンスのどちらに対して式を評価するかを「評価対象」フィールドで選択します。

注意:

期間として0を設定すると有効期限はなしになります。負の数を指定するとキャッシュは行われません。

有効期限の詳細は、「有効期限」を参照してください。

9.8.7 結果キャッシュの高度な構成

各Service Busドメインで、ドメインがビジネス・サービスの結果キャッシュに対してCoherenceを使用する方法を変更できます。Service Busでは、MW_HOME/osb/lib/appsにある2つのファイル、resultcache.garとresultcache.earを指定することにより、ドメイン内のサーバーに対して、自身のデフォルトのCoherence構成を指定します。GARファイルは、結果キャッシュで使用するCoherenceキャッシュを定義します。結果キャッシュを設定するには、resultcache.garをWebLogic Serverにデプロイし、キャッシュが対象となるサーバーまたはクラスタを指定します。その後、コンソール(またはお好みでWLSTコマンド)を使用して、キャッシュを構成できます。

GARファイルにはデフォルトのキャッシュ構成が埋め込まれています。GARファイルからosb-coherence-cache-config.xmlを抽出し、必要に応じてプロパティを変更することにより、キャッシュの独自の構成を定義できます。デフォルトでは、結果キャッシュには、分散キャッシュ・スキームが使用されます。詳細は、『Oracle Coherenceでのアプリケーションの開発』のキャッシュ構成の要素に関する項を参照してください。

異なるキャッシュ構成を使用するには、WebLogic Server管理コンソールでCoherenceクラスタの新しいキャッシュ構成を作成する必要があります。キャッシュ構成の名前は/osb/service/ResultCache、JNDI名はservicebus/result-cacheとし、Service Busで使用されているものと同じCoherenceクラスタに配置する必要があります。ドメイン内の様々なサーバーで、1つの異なる構成を使用できます。

9.8.7.1 ユニキャストおよびマルチキャストの操作

Coherenceのキャッシュ・アクセスをローカル・サーバーのみに限定するため、ユニキャスト設定を構成できます。この構成では、別のサーバーで起動されたノードは、同じCoherenceクラスタに参加してキャッシュされた情報を共有することはありません。かわりに、マルチキャスト値を構成して、同じテンプレートから作成された同じサブネット上の任意のWebLogic Serverノードによって共有されるCoherenceクラスタを作成できます。これらのプロパティは、WebLogic Server管理コンソールのCoherenceクラスタの「一般構成」タブで構成します。

Coherenceクラスタのノードの明示的なリストを持つユニキャスト・リスナーを使用するようにCoherenceクラスタを構成することをお薦めします。マルチキャストおよびユニキャストのプロパティについては、WebLogic Serverに付属のオンライン・ヘルプを参照してください。『Oracle Coherenceでのアプリケーションの開発』の既知のアドレスの使用に関する項も参照してください。

システム・プロパティを使用したオーバーライドを指定できます。複数のサーバーでCoherenceクラスタを正しく共有するようにCoherenceクラスタを構成する場合は、次のガイドラインに従ってください。

- クラスタ内でマルチキャスト・リスナーからユニキャスト・リスナーに切り替える場合は、既知のアドレスを構成します。

- 同一サブネット内に複数のWebLogic Serverクラスタがある場合、Coherenceクラスタを正しく共有するように、関係のあるCoherenceアドレスとポートのプロパティを変更します。WebLogic Serverクラスタに使用されるのと同じアドレスとポートを使用しないでください。

- 同一サブネット内に管理対象サーバーを持つ複数の管理サーバーがある場合、Coherenceクラスタを正しく共有するように、関係のあるCoherenceアドレスとポートのプロパティを変更します。

- 同一サブネット内にWebLogic Serverクラスタと管理対象サーバーを持つ管理サーバーの組合せがある場合、Coherenceクラスタを正しく共有するように、関係のあるCoherenceアドレスとポートのプロパティを変更します。

- 同一サブネット内に複数のCoherenceクラスタが稼働している場合、マルチキャスト・アドレスとマルチキャスト・ポートを変更して、ノードが接続する必要のあるCoherenceクラスタを指定します。

9.8.7.2 Service BusでCoherenceを無効にする方法

Service Busで完全にCoherenceが使用されないようにするには、次の手順を実行します。

1. Service Busを実行しているサーバーにターゲット指定されたすべてのCoherenceクラスタ・リソースを削除します。

2. Service Bus結果キャッシュのエンタープライズ・アプリケーション(resultcache.ear)をアンデプロイします。

3. グローバル結果キャッシュを無効にします。

9.8.7.3 プロセス外Coherenceサーバーについて

次の図に、プロセス外Coherenceサーバーを示します。

図9-7 プロセス外Coherenceクラスタ

この例には、2つのWebLogic Serverクラスタがあります。1番目のWebLogic Serverクラスタには、管理対象サーバー1および2が含まれ、次のようになっています。

- Service Bus実行中

- Service Bus結果キャッシュのエンタープライズ・アプリケーションがデプロイ済(resultcache.ear)

- 記憶域が無効

2番目のWebLogic Serverクラスタには、管理対象サーバー3および4が含まれ、次のようになっています。

- Service Bus結果キャッシュのグリッド・アーカイブがデプロイ済(resultcache.gar)

- 記憶域が有効

キャッシュされたすべてのエントリは、管理対象サーバー3および4に保存されます。

9.8.7.4 プロセス外Coherenceキャッシュ・サーバーの使用方法

Service Busで結果キャッシュを頻繁に使用し、結果キャッシュ用にヒープ領域を使用しすぎないようにする場合、Service BusのドメインJVMを共有するのではなく、独自のJVMを実行するようにCoherenceキャッシュ・サーバーを設定できます。Coherenceキャッシュ・サーバーをService Bus JVMの外部(プロセス外)で実行すると、Service Busでメッセージの処理に使用されるヒープ領域に影響なく、Coherenceキャッシュ・サーバーで独自のヒープ領域を使用できます。

注意:

Service Busとともに使用されるすべてのプロセス外Coherenceキャッシュ・サーバーでは、Service Busに含まれているバージョンと同バージョンのCoherenceを使用する必要があります。

9.8.7.4.1 プロセス外Coherenceキャッシュ・サーバーの作成

プロセス外Coherenceキャッシュ・サーバーを作成するには:

1. 同じCoherenceクラスタを使用する新しいWebLogic Serverノードおよびクラスタを作成します。

2. 新しいクラスタにMW_HOME/osb/lib/apps/resultcache.garファイルをデプロイします。

9.8.7.4.2 プロセス外Coherenceキャッシュ・サーバーのサーバーの構成

プロセス外Coherenceキャッシュ・サーバーを使用するには、各Service Busノードでローカル・キャッシュを無効にする必要があります。

プロセス外Coherenceキャッシュ・サーバーのサーバーを構成するには:

1. Service Busノードの起動に次の引数を追加して、各Service Busノードのローカル・キャッシュを無効にします。

-Dtangosol.coherence.distributed.localstorage=false

2. 次の引数を使用してCoherenceクラスタの名前を設定します。

-DOSB.coherence.cluster=cluster_name

9.8.7.5 Oracle Coherenceの構成方法および使用方法の追加情報

Oracle Coherence構成フレームワークを使用すると、様々なキャッシュ構成を、アプリケーションを変更することなく、柔軟に行うことができます。たとえば、属性を使用してキャッシュのタイプや動作を変更したり、キャッシュに問い合せたりできます。詳細は、『Oracle Coherenceでのアプリケーションの開発』のキャッシュの使用に関する項を参照してください。

10 分割-結合によるサービスのパフォーマンスの向上

この章では、分割-結合の概要とその作成方法について説明し、さらに静的分割-結合と動的分割-結合のシナリオについても説明します。分割-結合とは、高度な仲介機能であり、1つのリクエスト内の個々のメッセージを同時に処理できるため、サービスのパフォーマンスの向上に役立ちます。

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

- 分割-結合の概要

- サービス・レベル合意のアラート・ルール

- JDeveloperでの分割-結合の操作

- JDeveloperでの通信操作の追加

- JDeveloperでのフロー制御操作の追加

- JDeveloperでの割当て操作の追加

- Oracle Service Busコンソールでの分割-結合の操作

- 静的および動的分割-結合のサンプル

10.1 分割-結合の概要

分割-結合とは、メッセージのフローと処理を管理するためにService Busで使用できる仲介パターンです。分割-結合を使用すると、標準の順次処理とは対照的に、注文などのサービス・ペイロードを、複数のサービスに同時に送信される個々のメッセージに分割できます。これにより、サービスのパフォーマンスが大幅に向上します。分割-結合では、入力メッセージ・ペイロードをサブメッセージに分け(分割)、それらのサブメッセージを宛先に同時にルーティングして、レスポンスを1つの戻りメッセージに集約(結合)することで、このタスクを実現します。ペイロードを分割し、レスポンスを集約するこのプロセスを分割-結合パターンと呼びます。

分割-結合は、高速システムから低速システムの応答側のサービスに向けてペイロードを配信するシナリオで、全体的なレスポンス時間を最適化する場合に特に役立ちます。分割-結合を使用しない場合、通常、ペイロードの個々のメッセージは受信者によって順次解決されますが、応答側のシステムが低速な場合は時間がかかります。分割-結合を使用すると、複数のメッセージが同時に処理されるため、応答側のシステムの負担が減り、レスポンス時間が大幅に向上します。分割-結合を使用しない場合、全体的なレスポンス時間は、メッセージごとのレスポンス時間の合計になります。分割-結合を使用する場合、全体的なレスポンス時間は、個々のメッセージの最長レスポンス時間とシステムのわずかなオーバーヘッドの合計とほぼ同じになります。

分割-結合は、JDeveloperの分割-結合定義エディタで作成および設計します。その後、その分割-結合とそれに関連付けられたリソースをエクスポートしたり、テストおよび本番用にそれらのリソースをOracle Service Busコンソールにインポートできます。分割-結合はJDeveloperでは.flowファイルに保存され、常にWSDL操作に基づきます。分割-結合は、プロキシ・サービス、パイプラインまたは別の分割-結合から呼び出すことができます。分割-結合は、プロキシ・サービス、ビジネス・サービス、パイプラインまたは別の分割-結合を呼び出すことができます。

分割-結合には2種類のパターンがあります。1つは静的分割-結合で、既知の数のリクエストを処理し、もう1つは動的分割-結合で、可変数のリクエストを処理します。これらのパターンについては、以降の項で説明します。

注意:

分割-結合では、同じService Bus構成内の別の分割-結合を呼び出すことができるため、複雑な分割-結合機能を複数の分割-結合に分けることで、サービス設計がさらに柔軟になります。これにより、分割-結合機能のコンポーネント化と再利用が可能になります。分割-結合間にデータのマーシャリングやアンマーシャリングはないので、パフォーマンスは保持できます。

循環的な分割-結合参照を作成しないようにします。Service Busでは循環的な参照があるかどうかはチェックされません。

10.1.1 静的分割-結合

静的分割-結合では、分割-結合の構成に従って、ペイロードを固定数の新しいブランチに分割することで、Service Busメッセージ・フローのメイン実行スレッドから分岐します。設計時に、呼び出すサービスの数と種類を決定します。たとえば、顧客が、インターネット・サービス、TVサービス、電話サービスという3つの独立したサービスを含むケーブル・パッケージの注文を行う場合です。静的な使用例では、3つのリクエストすべてを、分割したパラレル・ブランチで実行できるため、標準的な順次実行と比較して実行時間のパフォーマンスが改善されます。

10.1.1.1 静的分割-結合 - サンプル・シナリオ

次のシナリオは、ある電話会社で、顧客からの通信サービス・パッケージの注文を処理するときに、静的分割-結合を使用する場合を示していします。この例では、顧客はDSLサービスとボイス・サービスを一度に申し込むことになります。電話会社は、ペイロードの各リクエストを単独で順に実行するのではなく、静的分割-結合を使用してメッセージを並行して実行できます。

開発者には、この特定のサービス・パッケージの受信サービス・リクエストが必ず2つ(DSLとボイス)になることがわかっているため、この場合、静的分割-結合が理想的なパターンといえます。リクエストを並列ブランチに分割することにより、リクエストを同時に処理できるようになるため、ペイロードを処理する際の全体的なレスポンス時間が向上します。すべてのメッセージの処理が完了すると、生成されたレスポンスが実行スレッドの1つの返信に集約されます。

図10-1は、2つの既知のサービス・リクエスト(DSLのアクティブ化と電話のアクティブ化)を分割し、各リクエストを並行処理して、レスポンスを1つの返信に結合する静的分割-結合を示しています。

図10-1 静的分割-結合: 既知の数のサービス・リクエスト

10.1.2 動的分割-結合

動的分割-結合では、受信ペイロードの内容に基づいて新しいブランチを動的に作成することで、Service Busパイプラインのメイン実行スレッドから分岐します。作成されるメッセージ・リクエストの数は変更できます。動的分割-結合では、条件ロジックを使用して、作成するブランチの数を決定します。すべてのリクエストが同時に処理され、各レスポンスが1つの返信に集約されます。たとえば、個別の発注数が変化する注文を小売業者が一括して行う場合です。動的な使用例では、一括注文を解析して発注ごとに分離したメッセージ・リクエストを作成できます。静的な使用例と同様に、これらのメッセージは並行に実行できるため、パフォーマンスが改善されます。

10.1.2.1 動的分割-結合 - サンプル・シナリオ

次のシナリオは、ある会社で、従業員の事務用品を自動的に注文するときに動的分割-結合を使用する場合を示しています。注文が従業員による送信に基づいて毎週自動的に行われる場合、各週の注文で発生する個々の注文数を知る方法はありません。この会社では、各注文を個別に行うのではなく、動的分割-結合を使用して、注文を同時に行うことができます。

毎週送信される注文数がわからないため、この場合、動的分割-結合が理想的なパターンといえます。動的分割-結合では、すべての注文をループ処理し、並行に実行します。処理する注文数を制限することもできます。すべての注文の処理が完了すると、生成された注文レスポンスが実行スレッドの1つの返信に集約されます。

図10-2は、15件の注文を分割し、それらの注文を同時に処理して、レスポンスを1つの返信に結合する動的分割-結合を示しています。

図10-2 動的分割-結合: 未知の数のサービス・リクエスト

10.1.3 分割-結合の操作

分割-結合の「コンポーネント」ウィンドウは、分割-結合を構成するために使用できるすべての操作を示します。操作は、通信、フロー制御および割当てのカテゴリに分かれます。

10.1.3.1 分割-結合の通信操作

通信操作では、分割結合と外部サービスとの相互運用方法を定義します。使用可能な操作は、表10-1を参照してください。

表10-1 分割-結合の通信操作

操作

説明

サービスの呼出し

この操作は、WSDLベースの非トランスポート型ビジネス・サービス、WSDLベース・プロキシ・サービスまたは分割-結合を呼び出します。「サービスの呼出し方法」を参照してください。

返信

この操作は、Oracle Service Busメッセージ・フローにレスポンスまたはフォルトを返します。「返信の構成方法」を参照してください。

10.1.3.2 分割-結合のフロー制御操作

フロー制御操作では、受信メッセージが分割-結合内を流れる方法を定義します。

表10-2 分割-結合のフロー制御操作

操作

説明

For Each

この操作は、スコープ内で構成されているロジックを指定回数だけ実行します。「リクエストの数に応じた反復方法」を参照してください。

条件操作

条件操作では、trueまたはfalseに評価する条件を定義し、各条件に対して定義された動作を実行できます。次の任意の条件を定義できます。

- 「If」: 条件がtrueに評価されると、if-else操作の関連するIfブランチが実行されます。Else-if操作は、条件付きノードでも現れます。if-else操作の関連するElse Ifブランチは、最初のIf条件がfalseに評価されたが2番目の条件がtrueに評価されると実行されます。「If-Else条件付きロジックの定義方法」を参照してください。

- 「While」: 条件がfalseに評価されるまで、関連する操作が繰り返されます。各ループが始まる前に、条件が評価されます。「Falseに評価されるまでの操作の繰返し方法」を参照してください。

- 「次の条件が満たされるまで繰返し」: 条件がtrueに評価されるまで、関連する操作が繰り返されます。各ループが終了した後で、条件が評価されます。「Trueに評価されるまでの操作の繰返し方法」を参照してください。

パラレル

この操作によって、固定数の構成済パラレル・ブランチが作成されるため、固定数のメッセージ・リクエストを処理する静的分割-結合を定義できます。パラレルには、1つまたは複数のスコープ・ブランチがあります。「固定数のリクエストの並行処理方法」を参照してください。

エラーの生成

この操作は、分割-結合の通常の処理を停止させるエラーを生成します。エラー・ハンドラを使用せずにエラーが処理されると、分割-結合が終了し、Oracle Service Busのメッセージ・フローにフォルトが送信されます。「エラーの生成方法」を参照してください。

エラーの再生成

この操作では、エラー・ハンドラのcatchまたはcatch allによって捕捉されたエラーを再生成できます。エラーの再生成操作の名前および説明を構成できます。「エラーの再生成方法」を参照してください。

スコープ

この操作は、それに含まれる操作の動きに影響を与えるコンテキストを作成します。スコープ内に定義されているローカル変数およびエラー・ハンドラは、このコンテキストに制限されます。スコープ操作の構成プロパティはありません。「コンテナ・ノードの作成方法」を参照してください。

待機

この操作では、分割-結合フローに一時停止を挿入して、他の依存ジョブの完了を少しの間待機できるようにします。指定した期間に到達すると、分割-結合の実行が再開されます。「処理での一時停止の挿入方法」を参照してください。

10.1.3.3 分割-結合の割当て操作

割当て操作では、変数の初期化や更新など、処理するメッセージ内のデータを操作できます。割当てノードでは、割当て、コピー、削除、挿入、Javaコールアウト、ログおよび置換の操作を実行できます。

表10-3 分割-結合の割当て操作

操作

説明

割当て

この操作では、XQuery式の結果を変数に割り当てることができます。「変数への値の割当て方法」を参照してください。

コピー

この操作では、XPath式で指定された情報を、ソース・ドキュメントから、宛先ドキュメントにコピーできます。「ソース・ドキュメントから宛先ドキュメントへの値のコピー方法」を参照してください。

削除

この操作では、XPath式によって指定された一連のノードを削除できます。「一連のノードの削除方法」を参照してください。

挿入

この操作では、XPath式で選択したノードを基準として特定された場所にXQuery式の結果を挿入できます。「XQuery式の結果の挿入方法」を参照してください。

Javaコールアウト

この操作では、検証、トランスフォーメーション、ロギングなどのJavaで処理するカスタム・アクションのための分割-結合から静的Javaメソッドを呼び出すことができます。「分割-結合でのJavaメソッドの呼出し方法」を参照してください。

ログ

この操作では、管理者が適切なアクションを行うことができるように、指定された重大度でデータを記録します。「分割-結合データのログの記録方法」を参照してください。

置換

この操作では、XPath式で指定されたノードまたはノードのコンテンツを置き換えることができます。「ノードおよびそのコンテンツの置換方法」を参照してください。

10.1.4 SOAPヘッダー内のコンテンツでの分割-結合の使用

分割-結合を使用して、SOAPヘッダーにメッセージ・コンテンツを格納するサービスのパフォーマンスを強化できます。デフォルトでは、分割-結合はSOAPヘッダーを伝播しません。ただし、これに対処するため、プロキシ・サービスがSOAPヘッダーを分割-結合に渡すことができるようにし、分割-結合が呼出しまたはレスポンスとしてSOAPヘッダーをプロキシおよびビジネス・サービスに渡すことができるように、WSDLファイルを変更できます。

この機能を有効にするには、分割-結合WSDLファイルと、分割-結合によって呼び出されるプロキシ・サービスやビジネス・サービスのWSDLファイルで、単一のリクエスト・メッセージまたはレスポンス・メッセージに本文部分とヘッダー部分を宣言する必要があります。メッセージ部分をWSDLファイルに宣言すると、分割-結合でリクエスト/レスポンス・メッセージ変数にSOAPヘッダー・コンテンツを利用できます。

次に、WSDLファイルでのメッセージとバインディング定義の例を示します。

メッセージ

<wsdl:message name="retrieveCustomerOverviewByIdRequestMessage">
<wsdl:part name="retrieveCustomerOverviewByIdRequest"
element="co:retrieveCustomerOverviewByIdRequest"/>
<wsdl:part name="serviceContext" element="sc:serviceContext"/>
</wsdl:message>

バインド

<wsdl:input>
<soap:body use="literal" parts="retrieveCustomerOverviewByIdRequest"/>
<soap:header message="tns:retrieveCustomerOverviewByIdRequestMessage"
part="serviceContext" use="literal"/>
</wsdl:input>

10.1.5 トランザクション・サポート

分割-結合ではトランザクションの伝播がサポートされます。多数の分割-結合操作には、トランザクション・サポートを制御する特定のサービス品質(QoS)値を設定するオプションがあります。分割-結合操作で「必ず1回」というQoS値を設定すると、トランザクションが存在する場合に操作がトランザクションのコンテキストで必ず実行されます。

個々の操作にQoS値を設定すると、単一の分割-結合操作において、トランザクションのコンテキストで複数の操作を実行し、その他の操作をトランザクション外で実行する柔軟性が得られます。QoSが「必ず1回」に設定された操作はトランザクションで実行されます。QoSが「ベスト・エフォート」に設定された操作はトランザクションのコンテキストでは実行されません。

分割-結合では、例外時のトランザクション・ロールバックが処理されません。トランザクションの例外とロールバックの処理は、分割-結合と呼ばれるサービス・コンポーネントが担当します。

次の分割-結合操作では、トランザクションの伝播がサポートされます。

- サービスの呼出し

- 割当て

- 削除

- 挿入

- Javaコールアウト

- 置換

10.1.6 分割-結合のセキュリティ

分割-結合では、セキュリティ・ポリシーは施行されず(つまり、ポリシーを含むWSDLファイルを備えた分割-結合は作成できない)、WSDLポリシーを含むWSDLベースのビジネス・サービスを分割-結合からコールすることはできません。

分割-結合を使用するときにセキュリティを確実に施行するには、プロキシ・サービスを使用して次のようにセキュリティの施行を処理します。

- 分割-結合を呼び出すインバウンド・プロキシを使用し、ポリシーを施行します。

- 分割-結合でポリシーを含むWSDLビジネス・サービスを呼び出す必要がある場合は、分割-結合でローカル・プロキシ(セキュリティ・ポリシーなしの構成)をコールし、必要なポリシーを含むビジネス・サービスをそのローカル・プロキシで呼び出すようにします。

10.1.7 分割-結合のリソース・タイプと環境変数

任意のスクリプトまたはカスタム・コードで分割-結合を参照する場合は、次の値を使用してください。

- typeId: FLOW

- ワーク・マネージャの環境値のタイプ: ワーク・マネージャ
ワーク・マネージャは、ディスパッチ・ポリシーの別称であることに注意してください。

10.2 サービス・レベル合意のアラート・ルール

サービス・レベル合意(SLA)のアラート・ルールでは、アラートの生成条件が定義されます。これらの条件は、通常、Service Busアプリケーションまたは特定のサービス・コンポーネントの全体的なヘルスのインジケータになります。分割-結合に対するSLAアラート・ルールの定義の詳細は、『Oracle Service Busの管理』のサービス・レベル合意のアラート・ルールの作成に関する項を参照してください。

10.3 JDeveloperでの分割-結合の操作

分割-結合は、JDeveloperでのみ作成および構成できます。JDeveloperにはグラフィカルなモデリング・エディタが用意されており、キャンバスに操作をドラッグし、「プロパティ」ウィンドウでそれらのプロパティを構成することで、簡単に分割-結合をモデル化できます。

10.3.1 JDeveloperでの分割-結合の作成方法

分割-結合は、JDeveloperで作成および構成します。Oracle Service BusコンソールでService Busプロジェクトを開発する場合、JDeveloperで作成した分割-結合をコンソールにインポートできます。分割-結合は.flowファイルで定義され、これはJDeveloperで分割-結合を作成するときに生成されます。このファイルには、プロキシ・サービス、ビジネス・サービス、または外部のWSDLリソースへの参照を含めることができます。分割-結合が依存するリソースは、分割-結合をアクティブ化する前に、サーバー上に存在する必要があります。

JDeveloperで分割-結合を作成するには:

1. Oracle JDeveloperで、分割-結合の追加先のアプリケーションおよびプロジェクトを開くか作成します。

2. アプリケーション・ナビゲータで、プロジェクトを右クリックして、「新規」をポイントし、「分割-結合」を選択します。

「分割-結合サービスの作成」ウィザードが表示されます。

3. 「サービスの作成」ページで、分割-結合の名前を入力し、必要に応じて場所と説明を入力します。

命名要件については、「Service Busコンポーネントのネーミング・ガイドライン」を参照してください。分割-結合名に、先頭および末尾の空白と、/ \ * : " < > ? |の文字は使用しないでください。

4. 必要に応じて、分割-結合の簡単な説明を入力するか、ファイルの場所を変更します。

デフォルトでは、ファイルはプロジェクト・フォルダに保存されます。

5. 「次」をクリックします。

6. 「型」ページで、次のいずれかを行います。

- 既存のWSDLファイルを使用するには、「WSDL」フィールドの右側の「既存のWSDLを検索します。」をクリックし、使用するWSDLファイルを検索してそのファイルを選択します。

- 新しいWSDLファイルを作成するには、「WSDL」フィールドの右側の「スキーマからWSDLを生成します。」をクリックします。詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のWSDLファイルの生成に関する項を参照してください。

7. 該当フィールドに対して表示されるオプションのリストから、使用するWSDLバインドと操作を選択します。

8. この分割-結合からプロキシ・サービスを生成するには、プロキシ・サービスとして公開を選択して、次の情報を入力します。

- プロキシ名: プロキシ・サービスの一意の名前。前述の命名要件を参照してください。

- プロキシの場所: プロキシ・サービス・ファイルを格納する場所のパス。デフォルトはプロジェクト・フォルダです。

- プロキシ・トランスポート: プロキシ・サービスに使用するトランスポートのタイプを選択します。詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください。

9. 「終了」をクリックします。

基本の分割-結合が作成され、分割-結合定義エディタの「設計」ビューにダイアグラムとして表示されます。デフォルトでは、これは開始ノード、受信ノードおよび返信ノードで構成されます(分割-結合がリクエスト/レスポンスのWSDLファイルに基づいている場合)。開始ノードには、WSDL操作からイントロスペクトされる変数が含まれています。受信ノードは、着信リクエスト・メッセージを受信するために使用されます。返信ノードは、レスポンス・メッセージを送信するために使用されます。

10.3.2 JDeveloperでのWSDLドキュメントからの分割-結合の生成方法

すでにService Busアプリケーション内に存在するWSDLドキュメントを使用して、分割-結合を生成できます。アプリケーションにWSDLドキュメントが存在しない場合は、これをインポートして次の手順を実行します。

JDeveloperでWSDLドキュメントから分割-結合を生成するには:

1. アプリケーション・ナビゲータで、既存のWSDLドキュメントを右クリックして、「Service Bus」をポイントし、「分割結合の生成」を選択します。

2. 「JDeveloperでの分割-結合の作成方法」の説明に従い、サービスに名前を付けて構成します。

10.3.3 「コンポーネント」ウィンドウと「プロパティ」ウィンドウの表示方法

分割-結合に追加する操作を「コンポーネント」ウィンドウから選択するため、分割-結合を構成するには、このウィンドウがJDeveloperで表示される必要があります。各操作は、JDeveloperの「プロパティ」ウィンドウを使用して構成するため、このウィンドウも表示される必要があります。

10.3.3.1 「コンポーネント」ウィンドウの表示

「コンポーネント」ウィンドウを表示するには

- 「コンポーネント」ウィンドウが「JDeveloper」ウィンドウに表示されない場合は、「ウィンドウ」→「コンポーネント」を選択します。
「コンポーネント」ウィンドウが「JDeveloper」ウィンドウの右側に表示されます。

10.3.3.2 「プロパティ」ウィンドウの表示

「プロパティ」ウィンドウを表示するには

- 「プロパティ」ウィンドウが「JDeveloper」ウィンドウに表示されない場合は、「ウィンドウ」→「プロパティ」を選択します。
「プロパティ」ウィンドウが「JDeveloper」ウィンドウの右側に表示されます。このウィンドウは、読みやすくなるように、別の場所(分割-結合定義エディタの下など)に移動できます。

10.3.4 開始ノードの構成方法

開始ノードは、新しい分割-結合を作成すると、自動的に生成されます。これは、その他のすべてのノードを実行するための出発点です。開始ノードで構成する要素はその名前のみです。

開始ノード名を変更するには:

開始ノードのラベルの名前を変更するには、ノードの名前をクリックします。表示されたフィールドに、ノードの一意の識別文字列を入力します。入力した名前が、分割-結合エディタでノードの下に表示されます。

10.3.5 外部サービスの表示方法

開始ノードに示されている外部サービスは、分割-結合のコンテキストの外部で呼び出されるサービスです。これらは、サービスの呼出しノードで指定されていますが、容易に使用できるようにリストされています。

外部サービスを表示するには:

外部サービスを表示するには、開始ノードの左矢印ボタンをクリックします。開始ノードの左側に「外部サービス」ボックスが表示されます。外部サービスの上にマウスを置くと、サービス・リソースの完全パスが表示されます。

10.3.6 グローバル変数とローカル変数の構成方法

開始ノードの変数には、分割-結合のノードによってグローバルに参照されるデータが格納されます。デフォルトでは、分割-結合が最初に作成されるときに、すべての開始ノードに、リクエストおよびレスポンスの両方の変数が割り当てられます。開始ノードから、新しいグローバル変数を作成するか、または既存のグローバル変数を編集することができます。

スコープの変数には、ローカルで(つまりデータの添付先のノードでのみ)参照されるデータが格納されます。スコープから、新しいローカル変数を作成したり、既存のローカル変数を編集できます。

グローバル変数とローカル変数の詳細は、「コンテナ・ノードの作成方法」を参照してください。

10.3.6.1 グローバル変数とローカル変数の定義

グローバル変数とローカル変数を定義するには:

1. 分割-結合定義エディタで、次のいずれかを実行します。

- グローバル変数を作成するには、開始ノードを右クリックして、「変数の作成」を選択します。

- ローカル変数を作成するには、変数の追加先のスコープを右クリックして、「変数の作成」を選択します。

「変数エイリアスの作成」ダイアログが表示されます。

2. 変数の名前を入力します。

3. 変数の型(組込み、XMLスキーマまたはWSDLメッセージ)を選択します。

4. 選択した変数の型の横にある「参照」をクリックして、型選択ダイアログから型を選択します。

5. 「OK」をクリックします。

「変数」ボックスの変数リストに新しい変数が表示されます。

10.3.6.2 グローバル変数とローカル変数の編集

グローバル変数とローカル変数を編集するには:

1. 編集する変数がエディタに表示されない場合は、その変数を含む開始ノードまたはスコープの左下にある矢印ボタンをクリックします。

「変数」ボックスが表示されます。

2. 編集する変数を右クリックして、「変数の編集」を選択します。

「変数エイリアスの編集」ダイアログが表示されます。

3. 次のいずれかの操作を実行します。

- 変数の名前を変更します。

- 変数の型(組込み、XMLスキーマまたはWSDLメッセージ)を選択します。

- 選択した変数の型の横にある「参照」をクリックして、型選択ダイアログから型を選択します。

4. 「OK」をクリックします。

10.3.7 受信操作の構成方法

新しい分割-結合を作成するたびに、受信操作が自動的に生成されます。受信操作は、着信リクエスト・データを変数に入れ、後のノードでコンテンツを使用できるようにします。受信操作を構成するには、受信操作で初期化する受信メッセージ変数と、必要に応じて操作の新しい名前および説明を指定できます。デフォルトの変数requestは、受信操作に対して自動で定義されます。

受信操作を構成するには:

1. 「プロパティ」ウィンドウが「JDeveloper」ウィンドウに表示されない場合は、「ウィンドウ」→「プロパティ」を選択します。

2. 分割-結合定義エディタで受信操作を選択します。

3. 受信メッセージ変数を指定するには、「プロパティ」ウィンドウの「受信」タブをクリックして、次のいずれかを実行します。

- 既存の変数を選択するには、「リクエスト変数」フィールドの使用可能なオプションのリストから変数名を選択します。

- 新しい変数を作成するには、「リクエスト変数」フィールドの横の「変数の作成」をクリックします。「変数の作成」ダイアログで、変数の名前を入力して、「OK」をクリックします。

4. 受信操作の名前を変更するには、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

新しい名前が、分割-結合定義エディタでノードの下に表示されます。

5. 「説明」フィールドに、重要と思われるノートを入力します。

6. JDeveloperのツールバーで、「保存」をクリックします。

10.4 JDeveloperでの通信操作の追加

通信操作では、分割結合と外部サービスとの相互運用方法を定義します。これには、サービスの呼出し操作と返信操作があります。

- サービスの呼出し方法

- 返信の構成方法

10.4.1 サービスの呼出し方法

サービスの呼出し操作を使用して、外部、WSDLベースのビジネス・サービス、WSDLベースのプロキシ・サービス、WSDLベースのパイプラインおよび分割-結合を呼び出します。

分割-結合からサービスを呼び出すには:

1. 「コンポーネント」ウィンドウの「通信」で、「サービスの呼出し」をクリックして、エディタのサービスを呼び出すフロー内の場所にドラッグします。

2. 新しい「サービスの呼出し」ノードを選択します。

3. 「プロパティ」ウィンドウで「呼出し」タブをクリックします。

4. 「サービス」フィールドで、「参照」をクリックして、呼び出すサービスを選択します。

5. 「操作」フィールドで、サービスの呼出しの基になっている操作を選択します。

6. 「リクエスト変数」フィールドで、タイプが操作の入力メッセージ・タイプと一致するメッセージ・タイプ変数を選択するか、「変数の作成」をクリックして新しい変数を作成します。

7. 「レスポンス変数」フィールドで、タイプが操作の出力メッセージ・タイプと一致するメッセージ・タイプ変数を選択するか、「変数の作成」をクリックして新しい変数を作成します。

注意:

サービスの呼出しには、一方向呼出しでないかぎり、リクエスト変数およびレスポンス変数の両方が必要です。いずれのタイプの変数も、グローバル(分割-結合全体で使用可能)にすることも、ローカル(特定のコンテキストのスコープ内で使用可能)にすることもできます。

8. 「QoS」フィールドで、「ベスト・エフォート」(トランザクションのコンテキストで実行されない)または「必ず1回」(トランザクションで実行される)のいずれかを選択します。

9. サービスの呼出しノードの名前を変更するには、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

新しい名前が、分割-結合定義エディタでノードの下に表示されます。

10. 「説明」フィールドに、重要と思われるノートを入力します。

11. JDeveloperのツールバーで、「保存」をクリックします。

10.4.2 返信の構成方法

新しい分割-結合を作成すると、グローバルな返信ノードが自動的に生成されます。グローバルな返信の目的は、コール元のサービスに、レスポンスを送り返すことです。ただし、返信を分割-結合の他の場所(エラー・ハンドラ内など)にも生成できます。

返信は、変数の構成に応じて、レスポンスまたはフォルトをクライアントに送り返すことができます。使用できるフォルトのオプションは、返信がグローバルかローカルかによって異なります。

- グローバルな返信(つまり、分割-結合でのエラー・ハンドラの外に生成される返信)には、SOAPフォルトは含まれませんが、WSDLフォルトが含まれる場合があります。これは、この場合、SOAPフォルト・オプションが無効になっているためです。

- ローカルな返信(つまり、エラー・ハンドラに付加された返信)は、WSDLフォルトまたはSOAPフォルトを持つことができます。WSDLフォルトは、分割-結合の基盤となるWSDLファイルで定義されている場合にのみ使用できます。SOAPフォルト・オプションは、以前にエラー・ハンドラで定義されていれば、常に使用できます。

注意:

「Response」および「Fault」ボタンを使用して切り替えると、それぞれの構成がクリアされます。たとえば、以前に「SOAPフォルトの伝播」を選択していて、「レスポンス」の構成に切り替えると、「SOAPフォルトの伝播」の選択が解除されます。

デフォルトの返信操作には、フォルトをトリガーせずにフローのインスタンスを終了する暗黙的な終了操作が自動的に含まれます。終了操作は、開発環境には表示されません。

返信を構成するには:

状況によっては、返信操作に対してフォルトが使用できない、またはSOAPフォルトしか使用できない場合があります。

1. 新しい返信操作を追加するには、「コンポーネント」ウィンドウの「通信」で、「返信」をクリックして、これをエディタの適切な場所にドラッグします。

2. 「返信」ノードを選択して構成します。

3. 「プロパティ」ウィンドウで「返信」タブをクリックします。

4. コール元のサービスにレスポンスを送り返すには、次のようにします。

a. 「レスポンス」オプションを選択します。

b. 「レスポンス」フィールドで、タイプが操作の出力メッセージ・タイプと一致するメッセージ変数を選択します。使用可能な変数のリストから選択するか、「変数の作成」をクリックして新しいメッセージ変数を定義します。

5. WSDLフォルトをレスポンスとして送信するには、次のようにします。

a. 「フォルト名」オプションを選択します。

b. 「フォルト名」フィールドで、メッセージ・フローに送り返すフォルトの名前を既存のフォルトのリストから選択します。

c. 「フォルト変数」フィールドで、フォルトが割り当てられる変数を選択します。使用可能な変数のリストから選択するか、「変数の作成」をクリックして新しいフォルト変数を定義します。

6. エラー・ハンドラで定義されたSOAPフォルト変数にあるSOAPフォルトを伝播するには、「SOAPフォルトの伝播」を選択します。

7. 返信ノードの名前を変更するには、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。
新しい名前が、分割-結合定義エディタでノードの下に表示されます。

8. 「説明」フィールドに、重要と思われるノートを入力します。

9. JDeveloperのツールバーで、「保存」をクリックします。

10.5 JDeveloperでのフロー制御操作の追加

フロー制御操作では、受信メッセージが分割結合内を移動する方法を定義します。この操作では、条件ロジック、エラー処理および並行処理を定義できます。

- コンテナ・ノードの作成方法

- リクエストの数に応じた反復方法

- 固定数のリクエストの並行処理方法

- If-Else条件付きロジックの定義方法

- エラー・ハンドラの作成方法

- エラーの生成方法

- エラーの再生成方法

- Trueに評価されるまでの操作の繰返し方法

- Falseに評価されるまでの操作の繰返し方法

10.5.1 コンテナ・ノードの作成方法

スコープは、様々な要素をまとめるコンテナです。このコンテナは、それに含まれる要素の動作に影響を与えるコンテキストを作成します。スコープ内に定義されているローカル変数およびエラー・ハンドラは、このコンテキストに制限されます。ただし、スコープ内の一部のノードは、ローカル(スコープ内)にも、グローバル(スコープ外)にも動作する場合があります。たとえば、特定のスコープ内のサービスの呼出しにより、そのスコープのコンテキストの外部のサービスがコールされる場合があります。

変数は定義されるスコープ内やそのスコープ内にネストされたすべてのスコープに表示できますが、外部のスコープに宣言される変数と同じ名前の変数が内部のスコープに宣言される場合、外部のスコープの変数が非表示になります。たとえば、外部のスコープ(So)にmyVarという変数を定義した後、外部のスコープSoにある内部のスコープ(Si)にもmyVar変数を定義する場合、内部のスコープ(Si)に定義したmyVarにのみアクセスできます。このmyVarにより、外部スコープSoで定義されたmyVarがオーバーライドされます。

コンテナ・ノードを作成するには:

1. 「コンポーネント」ウィンドウの「フロー制御」で、「スコープ」をクリックして、これをエディタの適切な場所のフローにドラッグします。

2. 新しい「スコープ」ノードを選択します。

3. スコープ・ノードの名前を変更するには、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

新しい名前が、分割-結合定義エディタでノードの下に表示されます。

4. スコープに操作を追加してその処理ロジックを定義し、「プロパティ」ウィンドウを使用して操作を構成します。

使用可能な操作の詳細は、「JDeveloperでのフロー制御操作の追加」および「JDeveloperでの割当て操作の追加」を参照してください。

5. スコープ・ノードのローカル変数を定義するには、「グローバル変数とローカル変数の構成方法」を参照してください。

6. JDeveloperのツールバーで、「保存」をクリックします。

10.5.2 リクエストの数に応じた反復方法

For Eachノードは、そのスコープ内で構成されたロジックを指定回数実行します。For Each操作を使用して、リクエストの数に応じて反復する条件付きロジックを作成します。これは、主に動的な分割-結合を作成するために使用されます。

リクエストの数に応じて反復するには:

1. 「コンポーネント」ウィンドウの「フロー制御」で、「For Each」をクリックして、これをエディタの適切な場所のフローにドラッグします。

2. 新しい「For Each」ノードを選択します。

3. 「プロパティ」ウィンドウで「For Each」タブをクリックします。

4. 「実行モード」フィールドで、For Eachループのそれぞれの繰返しを順次または並行のどちらで処理するかを選択します。

5. 「カウンタ変数名」フィールドに、繰返しをカウントする暗黙的変数の名前を入力します。

6. 「開始カウンタ値」フィールドの横で、「式ビルダー」アイコンをクリックして、XPath式ビルダーを起動し、カウンタ変数の初期値を指定する式を定義します。

注意:

カウンタの最小開始値と終了値は1です。

7. 「最終カウンタ値」フィールドの横で、「式ビルダー」アイコンをクリックして、XPath式ビルダーを起動し、最後の繰返し後のカウンタ変数の最終値を指定する式を定義します。

8. 「完了したブランチの数」フィールドの横で、「式ビルダー」アイコンをクリックして、XPath式ビルダーを起動し、ブランチの作成を中止するタイミングを判断する式を定義します。

9. 正常に完了したブランチのみをカウントして完了条件が満たされたかどうかを判断するには、「成功したブランチのみ」を選択します。

10. For Eachノードの名前を変更するには、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

新しい名前が、分割-結合定義エディタでノードの下に表示されます。

11. 「説明」フィールドに、重要と思われるノートを入力します。

12. JDeveloperのツールバーで、「保存」をクリックします。

10.5.3 固定数のリクエストの並行処理方法

並行操作によって、固定数の構成済パラレル・ブランチが作成されるため、固定数のメッセージ・リクエストを処理する静的分割-結合を作成できます。各ブランチには、任意の数の操作を含めることができる独自のスコープがあります。

パラレル・ノードは、基本的には、固定数の処理ブランチのプレースホルダであり、各ブランチには、それぞれのスコープがあります。2つのブランチは、並行操作をフローに追加すると自動的に生成されます。スコープごとに一意の処理ロジックを定義するには、適切な操作をスコープにドラッグします。スコープの追加ボタンを使用して、ブランチをさらに追加することもできます。

図10-3 「Add Scope」ボタン

固定数のリクエストを並行処理するには:

1. 「コンポーネント」ウィンドウの「フロー制御」で、「パラレル」をクリックして、これをエディタの適切な場所のフローにドラッグします。

2. ブランチをさらに追加するには、「パラレル」ノードの右上隅のスコープの追加ボタンをクリックします。

3. ブランチごとに、追加の操作をスコープにドラッグしてから、その操作を「プロパティ」ウィンドウで構成し、処理ロジックを定義します。

追加可能な操作の詳細は、「JDeveloperでのフロー制御操作の追加」および「JDeveloperでの割当て操作の追加」を参照してください。

4. パラレル・ノードの名前を変更するには、ノード上部の「パラレル」をクリックして、表示されたフィールドに新しい名前を入力します。

5. JDeveloperのツールバーで、「保存」をクリックします。

10.5.4 If-Else条件付きロジックの定義方法

Ifアクティビティは、分割-結合内で条件付きロジックを提供します。If条件全体の動作を決定する多数のノードから構成されます。各ノードを個別に構成する必要があります。Ifアクティビティを作成すると、アクティビティ内にIfブランチおよびElseブランチが自動的に生成されます。

IfおよびElse Ifの各ブランチは、Ifアクティビティ全体で、1つの条件付きロジック(XPath式で定義される)を提供します。これらのブランチでは、条件が満たされた場合に実行する処理ロジックも定義します。Elseブランチでは、条件が満たされない場合に実行する処理ロジックを定義します。Else Ifノードは、If操作に対して無制限に追加できます。

if-else条件付きロジックを定義するには:

1. 「コンポーネント」ウィンドウの「フロー制御」で、「If」をクリックして、これをエディタの適切な場所のフローにドラッグします。
Ifノードが、IfブランチおよびElseブランチとともに表示されます。

2. Ifブランチを構成するには、次のようにします。

a. 新しい「If」ノードで、「If」ブランチを選択します。

b. 「プロパティ」ウィンドウで「条件」タブをクリックします。

c. 「条件」フィールドの横で、「式ビルダー」アイコンをクリックして、XPath式ビルダーを起動し、If条件を定義する式を定義します。

d. If条件が満たされた場合に行われる処理を定義するには、操作を「コンポーネント」ウィンドウから「If」ブランチにドラッグしてから、その操作を「プロパティ」ウィンドウで構成します。
追加可能な操作の詳細は、「JDeveloperでのフロー制御操作の追加」および「JDeveloperでの割当て操作の追加」を参照してください。

3. Else Ifブランチを追加するには、次のようにします。

a. Ifノードの右上隅にある黄色いダイヤモンドの形のアイコンをクリックするか、Ifノード内で右クリックして「ElseIfの追加」を選択します。

図10-4 「Add Else If」ボタン

Elseブランチの左側に新しいElse Ifブランチが表示されます。

b. 手順2の説明に従い、Ifブランチと同様にElse Ifブランチを構成します。

4. どの条件も満たされない場合に行われる処理を定義するには、操作を「コンポーネント」ウィンドウから「Else」ブランチにドラッグしてから、その操作を「プロパティ」ウィンドウで構成します。

5. Ifノードまたはいずれかのブランチの名前を変更するには、ノードまたはブランチのアイコンを選択し、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

6. 「説明」フィールドに、重要と思われるノートを入力します。

7. JDeveloperのツールバーで、「保存」をクリックします。

10.5.5 エラー・ハンドラの作成方法

エラー・ハンドラは、エラーを受信して、処理します。エラー・ハンドラは、開始ノードやスコープにアタッチできます。開始ノードにアタッチされている場合は、グローバル・エラー・ハンドラであり、ローカルのすべてのエラー生成ノードの出力に対して、すべてをキャッチします。スコープにアタッチされている場合は、ローカルで発生したエラーのみを処理します。

エラー・ハンドラを作成するには:

1. エラー・ハンドラの追加先である開始ノードまたはスコープ・ノードを選択します。

2. 選択したノードを右クリックし、「Catchの追加」または「CatchAllの追加」を選択します。

選択したノードの右側に新しいエラー・ハンドラ・ノードが表示されます。

3. Catch Allハンドラに対してSOAPフォルトを呼び出すには、「CatchAll」ブランチを選択し、「プロパティ」ウィンドウで「CatchAll」タブをクリックして、「SOAPフォルト変数名」にフォルト名を入力します。

4. Catchハンドラを構成するには、「Catch」ブランチを選択し、「プロパティ」ウィンドウの「Catch」タブをクリックして、次のいずれかを実行します。

- 定義したフォルトを呼び出すには、「ユーザー定義のフォルト」を選択して、「編集」アイコンをクリックします。「QNameの編集」ダイアログで、フォルトの名前とネームスペースを入力します。

- 事前定義したフォルトを呼び出すには、「事前定義のフォルト」を選択して、オプションのリストからフォルトを選択します。

5. レスポンスが送信される前に、「Catch」または「CatchAll」ブランチに対して追加の処理を構成するには、割当て、If、返信の各ノードを「コンポーネント」ウィンドウからドラッグして、そのノードを「プロパティ」ウィンドウで構成します。

6. エラー・ハンドラ・ノードまたはいずれかのブランチの名前を変更するには、ノードまたはブランチのアイコンを選択し、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

7. 「説明」フィールドに、重要と思われるノートを入力します。

8. JDeveloperのツールバーで、「保存」をクリックします。

10.5.6 エラーの生成方法

エラーの生成は、分割-結合の通常の処理を停止させるエラーを生成します。エラーがエラー・ハンドラを使用して処理されないと、分割-結合は終了し、Service Busメッセージ・フローにフォルトが送信されます。「エラーを発生させる」の構成には、「一般情報」タブへのエラーの性質の入力が含まれます(オプション)。

エラーを生成するには:

1. 「コンポーネント」ウィンドウの「フロー制御」で、「エラーの生成」をクリックして、これをエディタの適切な場所のフローにドラッグします。

2. 新しい「エラーの生成」ノードを選択します。

3. 「プロパティ」ウィンドウで「エラーの生成」タブをクリックします。

4. 定義したフォルトを呼び出すには、「ユーザー定義のフォルト」を選択して、「編集」アイコンをクリックします。「QNameの編集」ダイアログで、フォルトの名前とネームスペースを入力します。

5. 事前定義したフォルトを呼び出すには、「事前定義のフォルト」を選択して、オプションのリストからフォルトを選択します。

6. エラーの生成ノードの名前を変更するには、ノードまたはブランチのアイコンを選択し、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

7. 「説明」フィールドに、重要と思われるノートを入力します。

8. JDeveloperのツールバーで、「保存」をクリックします。

10.5.7 エラーの再生成方法

エラー・ハンドラにエラーの再生成操作を追加できます。この操作では、エラー・ハンドラのCatchまたはCatch All操作によって捕捉されたエラーを再生成できます。この操作では構成は必要ありませんが、名前を変更して説明を追加できます。

エラーを再生成するには:

1. 「コンポーネント」ウィンドウの「フロー制御」で、「エラーの再生成」をクリックして、これをエディタの適切な場所のフローにドラッグします。

2. 新しい「エラーの再生成」ノードを選択します。

3. エラーの再生成ノードの名前を変更するには、「プロパティ」ウィンドウの「名前」フィールドに一意の識別文字列を入力します。

4. 「説明」フィールドに、重要と思われるノートを入力します。

5. JDeveloperのツールバーで、「保存」をクリックします。

10.5.8 Trueに評価されるまでの操作の繰返し方法

次の条件が満たされるまで繰返しノードは、分割-結合内で条件付きロジックを提供します。次の条件が満たされるまで繰返しノードを定義すると、定義した条件がtrueに評価されるまで、関連付けられた操作が繰り返されます。関連付けられる操作は、次の条件が満たされるまで繰返しノードのループで定義されます。各ループが終了した後で、条件が評価されます。

trueに評価されるまで操作を繰り返すには:

1. 「コンポーネント」ウィンドウの「フロー制御」で、「次の条件が満たされるまで繰返し」をクリックして、これをエディタの適切な場所のフローにドラッグします。

「次の条件が満たされるまで繰返し」ノードが、条件付きブランチとともに表示されます。

2. 新しい「次の条件が満たされるまで繰返し」ノードで、「条件」アイコンを選択します。

3. 「プロパティ」ウィンドウで「条件」タブをクリックします。

4. 「条件」フィールドの横で、「式ビルダー」アイコンをクリックしてXPath式ビルダーを起動し、処理が繰返しを停止するにはtrueに評価する必要がある式を定義します。

5. 条件がtrueに評価されるまで繰り返される処理ロジックを定義するには、操作を「コンポーネント」ウィンドウから「次の条件が満たされるまで繰返し」ノードにドラッグして、その操作を「プロパティ」ウィンドウで構成します。

追加可能な操作の詳細は、「JDeveloperでのフロー制御操作の追加」および「JDeveloperでの割当て操作の追加」を参照してください。

6. 次の条件が満たされるまで繰返しノードの名前を変更するには、ノードを選択し、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

7. 「説明」フィールドに、重要と思われるノートを入力します。

8. JDeveloperのツールバーで、「保存」をクリックします。

10.5.9 Falseに評価されるまでの操作の繰返し方法

Whileノードは、分割-結合内で条件付きロジックを提供します。Whileノードを定義する場合、定義した条件がfalseに評価されるまで、関連付けられた操作が繰り返されます。関連付けられる操作は、次の条件が満たされるまで繰返しノードのループで定義されます。各ループが終了する前に、条件が評価されます。

falseに評価されるまで操作を繰り返すには:

1. 「コンポーネント」ウィンドウの「フロー制御」で、「While」をクリックして、これをエディタの適切な場所のフローにドラッグします。

「While」ノードが、条件付きブランチとともに表示されます。

2. 新しい「While」ノードで、「条件」アイコンを選択します。

3. 「プロパティ」ウィンドウで「条件」タブをクリックします。

4. 「条件」フィールドの横で、「式ビルダー」アイコンをクリックしてXPath式ビルダーを起動し、処理が繰返しを停止するにはfalseに評価する必要がある式を定義します。

5. 条件がfalseに評価されるまで繰り返される処理ロジックを定義するには、操作を「コンポーネント」ウィンドウから「While」ノードにドラッグして、その操作を「プロパティ」ウィンドウで構成します。

追加可能な操作の詳細は、「JDeveloperでのフロー制御操作の追加」および「JDeveloperでの割当て操作の追加」を参照してください。

6. Whileノードの名前を変更するには、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

7. 「説明」フィールドに、重要と思われるノートを入力します。

8. JDeveloperのツールバーで、「保存」をクリックします。

10.5.10 処理での一時停止の挿入方法

待機操作では、分割-結合フローに一時停止を挿入して、他の依存ジョブの完了を少しの間待機できるようにします。指定した期間に到達すると、分割-結合の実行が再開されます。

処理で一時停止を挿入するには:

1. 「コンポーネント」ウィンドウの「フロー制御」で、「待機」をクリックして、これをエディタの適切な場所のフローにドラッグします。

「While」ノードが、条件付きブランチとともに表示されます。

2. 新しい「待機」ノードを選択します。

3. 「プロパティ」ウィンドウで「待機」タブをクリックします。

4. 「期間」フィールドの横で、「式ビルダー」アイコンをクリックして、XPath式ビルダーを起動し、次の形式で期間のタイプxsd:durationに評価される式を定義します。

PnYnMnDTnHnMnS (年、月、日、時、分、秒の数を指定し、日付と時刻はTで区切ります。)

5. 待機ノードの名前を変更するには、ノードを選択し、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

6. 「説明」フィールドに、重要と思われるノートを入力します。

7. JDeveloperのツールバーで、「保存」をクリックします。

10.6 JDeveloperでの割当て操作の追加

割当て操作には、割り当て、コピー、削除、挿入、Javaコールアウト、ログ、および置換があります。各割当ては、これらの1つ以上の操作から構成され、この操作はデザイン・ビューから割当てに追加できます。次に、分割-結合で使用できる割当て操作を示します。

- 割当て: 変数にXQuery式またはXSLT式の結果を割り当てます。

- コピー: XPath式で指定された情報を、ソース・ドキュメントから、宛先ドキュメントにコピーします。

- 削除: XPath式で指定されたノードのセットを削除します。

注意:

Service Busの削除とは異なり、変数全体ではなくXPath式のみを分割-結合から削除できます。

- 挿入: XPath式で選択したノードを基準として特定された場所にXQuery式の結果を挿入します。

- Javaコールアウト: 検証、変換、ロギングなどの処理のJavaメソッドを呼び出します。

- ログ: サーバー・ログ・ファイルに分割-結合データのログを指定の重大度で記録します。

- 置換: XPath式で指定されたノードまたはノードのコンテンツを置き換えます。

10.6.1 割当て操作での変換および式について

様々なXQueryおよびXSLTリソースを使用して、割当て操作の値を導出する変換および式を定義できます。ほとんどの割当て操作では次の手法がサポートされます。詳細は、次に示すリンクで確認できます。

- XQueryでのデータの変換

- XSLTでのデータの変換

- Oracle Service Busコンソールでの式エディタの操作

- 『Oracle SOA SuiteでのSOAアプリケーションの開発』のXQueryマッパーでの変換の作成に関する項

- 『Oracle SOA SuiteでのSOAアプリケーションの開発』のXSLTマップ・エディタでの変換の作成に関する項

注意:

分割-結合エディタの割当て操作は、パイプラインの対応するアクションと同じです。ただし、重要な相違点の1つとして、XQuery、XSLTまたはXPathエディタを使用して、分割-結合コンテキストの式を編集する場合に、分割-結合に対して内部の変数およびネームスペースのみが使用可能であるという点があります。

10.6.2 割当て操作の式の解決

分割-結合における割当て機能は、XPath、XQueryおよびXSLT式を単純型の変数にすることで解決するWS-BPEL仕様に準拠しています。式を分割-結合にある変数にバインドするためのサポート対象の単純な型は、文字列、ブールおよび浮動小数です。割当て操作は、型の値を定義された変数型に変換します。

次に例を示します。

- <order><number>4</number></order>を文字列で定義されたレスポンス変数($response.result)に割り当てる場合、Service Busでは、子要素および値を単純にコピーすることで<number>4</number>を文字列で返します。

- <order><number>4</number></order>を文字列変数(myStrなど)にマップして、$myStrを$response.resultに割り当てると、Service Busは$response.resultの文字列変数に割り当てる前にまず$myStrの値を文字列に変換するため、<result>4</result>を返します。

10.6.3 変数への値の割当て方法

割当てを使用してデータを操作するには、XSLTまたはXQueryの式やリソースを使用して変数を初期化および更新します。動的XSLTまたはXQueryも使用できます。

Service Busでは、インラインXQueryの変数をバインドするとき、型がxs:stringであると仮定します。このため、xs:stringと互換性のない定数の操作の場合に、解析エラーが発生する可能性があります。型の互換性を保証するためには明示的なXQueryキャストを使用します。たとえば、次のインラインXQueryは失敗します。$itemsTotalは型xs:doubleですが、xs:stringとしてバインドされ、10000でのテストで互換性がありません。

if ($itemsTotal < 10000) then . . .

このインラインXQueryが機能するようにするには、$itemsTotalをxs:doubleに明示的にキャストします。

if (($itemsTotal cast as xs:double) < 10000) then . . .

文字列の結果または変数への割当て操作を作成するとき、式が文字列値を返すようにしてください。非String値をStringの結果またはStringのグローバル変数に割り当てると、WS-BPEL仕様で定められているようにMismatchedAssignmentFailure例外は発生しません。

変数に値を割り当てるには:

1. 「コンポーネント」ウィンドウの「割当て操作」で、「割当て」をクリックして、これをエディタの変数を更新するフローの場所にドラッグします。

2. 新しい「割当て」ノードを選択します。

3. 「プロパティ」ウィンドウで「割当て」タブをクリックします。

4. 「値」フィールドの横で、「式ビルダー」アイコンを選択するか、アイコンの横の下向き矢印をクリックして、変数値の導出に使用する変換のタイプを選択します。

選択した変換の式ビルダーが表示されます。

5. 変換を定義するか、使用するリソースを選択します。詳細は、「割当て操作での変換および式について」を参照してください。

注意:

現在のプロジェクトにまだ含まれていないXQueryまたはXSLTリソースを選択する場合、これらをインポートする必要があります。式ビルダーからリソースを選択すると、インポート・ダイアログが自動で表示されます。詳細は、「JDeveloperでリソースをインポートする方法」を参照してください。

6. 値の割当て先の変数を指定するには、次のいずれかを実行します。

- 既存の変数を選択するには、「変数」フィールドの使用可能なオプションのリストから変数名を選択します。

- 新しい変数を作成するには、「変数」フィールドの横の「変数の作成」をクリックします。「グローバル変数とローカル変数を定義するには:」の説明に従い、「変数エイリアスの作成」ダイアログに入力します。.

7. 「QoS」フィールドで、「ベスト・エフォート」(トランザクションのコンテキストで実行されない)または「必ず1回」(トランザクションで実行される)のいずれかを選択します。

8. 割当てノードの名前を変更するには、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

新しい名前が、分割-結合定義エディタでノードの下に表示されます。

9. 「説明」フィールドに、重要と思われるノートを入力します。

10. JDeveloperのツールバーで、「保存」をクリックします。

10.6.4 ソース・ドキュメントから宛先ドキュメントへの値のコピー方法

コピー操作を使用すると、XPath式またはリテラル値で指定された情報を、ソース・ドキュメントから宛先ドキュメントにコピーできます。これは、分割-結合エディタに固有の操作です。

値をコピーするには:

1. 「コンポーネント」ウィンドウの「割当て操作」で、「コピー」をクリックして、エディタのデータのコピー先となるフローの場所にドラッグします。

2. 新しい「コピー」ノードを選択します。

3. 「プロパティ」ウィンドウで「コピー」タブをクリックします。

4. 宛先の既存の要素名を使用して、コピーした値を保持するには、「ソース要素の維持」を選択します。

このオプションを選択しない場合は、宛先のソース要素の名前を使用して、コピーした値が保持されます。

5. 「自: タイプ」フィールドで、コピー元の要素のタイプを選択します。

6. 次のいずれかを行います。

- 「式」、「変数」または「XMLフラグメント」を選択した場合、「値」フィールドの近くにある「式ビルダー」アイコンをクリックします。表示されるダイアログで式を定義します。

- 「リテラル」を選択した場合、コピーするリテラル文字列を「値」フィールドに入力します。

7. 「至: タイプ」フィールドで、コピー先の要素のタイプを選択します。

8. 「値」フィールドまたは「問合せ」フィールドの下にある「式ビルダー」アイコンをクリックします。表示されるダイアログで式を定義します。

9. コピー・ノードの名前を変更するには、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

新しい名前が、分割-結合定義エディタでノードの下に表示されます。

10. 「説明」フィールドに、重要と思われるノートを入力します。

11. JDeveloperのツールバーで、「保存」をクリックします。

10.6.5 一連のノードの削除方法

削除操作では、XPath式によって指定された一連のノードを削除できます。

注意:

Service Busの削除とは異なり、変数全体ではなくXPath式のみを分割-結合から削除できます。

一連のノードを削除するには:

1. 「コンポーネント」ウィンドウの「割当て操作」で、「削除」をクリックして、これをエディタのノードを削除するフローの場所にドラッグします。

2. 新しい「削除」ノードを選択します。

3. 「プロパティ」ウィンドウで「削除」タブをクリックします。

4. 「場所」フィールドで、XPath式の実行対象の変数を選択して、削除するノードを選択します。

5. 「式ビルダー」アイコンをクリックして式エディタを起動し、削除するノードを指定するXPath式を定義します。

6. 「QoS」フィールドで、「ベスト・エフォート」(トランザクションのコンテキストで実行されない)または「必ず1回」(トランザクションで実行される)のいずれかを選択します。

7. 削除ノードの名前を変更するには、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

新しい名前が、分割-結合定義エディタでノードの下に表示されます。

8. 「説明」フィールドに、重要と思われるノートを入力します。

9. JDeveloperのツールバーで、「保存」をクリックします。

10.6.6 XQuery式の結果の挿入方法

挿入操作は、XPath式で選択されたノードを基準に指定された位置に、XQuery式の結果を挿入します。

XQuery式の結果を挿入するには:

1. 「コンポーネント」ウィンドウの「割当て操作」で、「挿入」をクリックして、これをエディタの結果を挿入するフローの場所にドラッグします。

2. 新しい「挿入」ノードを選択します。

3. 「プロパティ」ウィンドウで「挿入」タブをクリックします。

4. 「値」フィールドの横で、「式ビルダー」アイコンを選択するか、アイコンの横の下向き矢印をクリックして、変数内の指定の場所に挿入するデータの作成に使用する変換のタイプを選択します。

選択した変換の式ビルダーが表示されます。

5. 式ビルダーで、変換を定義するか、使用するリソースを選択します。詳細は、「割当て操作での変換および式について」を参照してください。

注意:

現在のプロジェクトにまだ含まれていないXQueryまたはXSLTリソースを選択する場合、これらをインポートする必要があります。式ビルダーからリソースを選択すると、インポート・ダイアログが自動で表示されます。詳細は、「JDeveloperでリソースをインポートする方法」を参照してください。

6. 「位置」フィールドで、データの挿入位置を選択します。「の前に」、「の後に」、「の最初の子として」または「の最後の子として」の中から選択します。

7. 「場所」フィールドで、データの挿入先の変数を選択するか、「変数の作成」をクリックして新しい変数を追加します。

8. 「場所」フィールドの下にある「式ビルダー」アイコンをクリックしてXPath式ビルダーを起動し、選択するノードを指定する式を定義します。

9. 「QoS」フィールドで、「ベスト・エフォート」(トランザクションのコンテキストで実行されない)または「必ず1回」(トランザクションで実行される)のいずれかを選択します。

10. 挿入ノードの名前を変更するには、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

新しい名前が、分割-結合定義エディタでノードの下に表示されます。

11. 「説明」フィールドに、重要と思われるノートを入力します。

12. JDeveloperのツールバーで、「保存」をクリックします。

10.6.7 分割-結合でのJavaメソッドの呼出し方法

Javaコールアウト操作では、検証、変換、ロギングなどのJavaで処理するカスタム操作のために、分割-結合から静的Javaメソッドを呼び出すことができます。

分割-結合でJavaメソッドを呼び出すには:

1. 「コンポーネント」ウィンドウの「割当て操作」で、「Javaコールアウト」をクリックして、これをエディタのコールアウトを使用するフローの場所にドラッグします。

2. 新しい「Javaコールアウト」ノードを選択します。

3. 「プロパティ」ウィンドウで「Javaコールアウト」タブをクリックします。

4. 「メソッド」フィールドの横で、「参照」をクリックし、呼び出すメソッドを含むJARファイルに移動してそのファイルを選択してから、メソッドを選択します。

「引数」表にメソッドの引数が表示されます。

5. 「値」列で、「式ビルダー」アイコンをクリックするか、アイコンの横の下向き矢印をクリックして、変換タイプを選択します。

選択した変換の式ビルダーが表示されます。

6. 式を定義して、データを静的Javaメソッドの入力パラメータにマップします。詳細は、「割当て操作での変換および式について」を参照してください。

注意:

現在のプロジェクトにまだ含まれていないXQueryまたはXSLTリソースを選択する場合、これらをインポートする必要があります。式ビルダーからリソースを選択すると、インポート・ダイアログが自動で表示されます。詳細は、「JDeveloperでリソースをインポートする方法」を参照してください。

7. 「戻る」フィールドで、Javaメソッドの結果値を含む変数をオプションのリストから選択します。変数が存在しない場合は、「変数の作成」をクリックして新しい変数を追加します。

8. 「サービス・アカウント」フィールドで、「参照」をクリックして、Javaコールアウトを実行する場合に適切なサブジェクトをスレッドに配置するために使用するサービス・アカウントを選択します。

9. 「QoS」フィールドで、「ベスト・エフォート」(トランザクションのコンテキストで実行されない)または「必ず1回」(トランザクションで実行される)のいずれかを選択します。

10. Javaコールアウト・ノードの名前を変更するには、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

新しい名前が、分割-結合定義エディタでノードの下に表示されます。

11. 「説明」フィールドに、重要と思われるノートを入力します。

12. JDeveloperのツールバーで、「保存」をクリックします。

10.6.8 分割-結合データのログの記録方法

ログ操作により、サーバー・ログ・ファイルに特定の重大度の分割-結合データのログを記録できます。管理者は、ログ情報を使用して、記録したデータの重大度に基づく適切なアクションを行うことができます。

分割-結合データのログを記録するには:

1. 「コンポーネント」ウィンドウの「割当て操作」で、「ログ」をクリックして、これをエディタのログ・エントリを作成するフローの場所にドラッグします。

2. 新しい「ログ」ノードを選択します。

3. 「プロパティ」ウィンドウで「ログ」タブをクリックします。

4. 「コンテンツ」フィールドの横で、「式ビルダー」アイコンをクリックするか、このアイコンの横の下向き矢印をクリックして、変換タイプを選択します。

選択した変換の式ビルダーが表示されます。

5. ログを記録するデータを選択する式を定義します。詳細は、「割当て操作での変換および式について」を参照してください。

注意:

現在のプロジェクトにまだ含まれていないXQueryまたはXSLTリソースを選択する場合、これらをインポートする必要があります。式ビルダーからリソースを選択すると、インポート・ダイアログが自動で表示されます。詳細は、「JDeveloperでリソースをインポートする方法」を参照してください。

6. 「概要」フィールドで、ログのノートを指定します。注釈は、式によって選択されたデータとともにログに記録されます。

7. 「重大度」フィールドで、ログに対して次のいずれかの重大度レベルを選択します。

- デバッグ

- 情報

- 警告

- エラー

8. ログ・ノードの名前を変更するには、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

新しい名前が、分割-結合定義エディタでノードの下に表示されます。

9. 「説明」フィールドに、重要と思われるノートを入力します。

10. JDeveloperのツールバーで、「保存」をクリックします。

10.6.9 ノードおよびそのコンテンツの置換方法

置換操作は、XPath式で指定されたノードまたはノードのコンテンツを置き換えます。

ノードまたはそのコンテンツを置き換えるには:

1. 「コンポーネント」ウィンドウの「割当て操作」で、「置換」をクリックして、エディタのデータを置換するフローの場所にドラッグします。

2. 新しい「置換」ノードを選択します。

3. 「プロパティ」ウィンドウで「置換」タブをクリックします。

4. 「場所」フィールドで、置換するデータを含む変数を選択するか、「変数の作成」をクリックして新しい変数を追加します。

5. 「場所」フィールドの下にある「式ビルダー」アイコンをクリックしてXPath式ビルダーを起動し、置換するノードを指定する式を定義します。

6. 「値」フィールドの横で、「式ビルダー」アイコンをクリックするか、このアイコンの横の下向き矢印をクリックして、変換タイプを選択します。

選択した変換の式ビルダーが表示されます。

7. 置換するデータを選択する式を定義します。詳細は、「割当て操作での変換および式について」を参照してください。

注意:

現在のプロジェクトにまだ含まれていないXQueryまたはXSLTリソースを選択する場合、これらをインポートする必要があります。式ビルダーからリソースを選択すると、インポート・ダイアログが自動で表示されます。詳細は、「JDeveloperでリソースをインポートする方法」を参照してください。

8. 「置換」フィールドで、ノード全体を置換するには「ノード全体」を選択し、ノードのコンテンツのみを置換するには「ノードのコンテンツ」を選択します。

9. 「QoS」フィールドで、「ベスト・エフォート」(トランザクションのコンテキストで実行されない)または「必ず1回」(トランザクションで実行される)のいずれかを選択します。

10. ログ・ノードの名前を変更するには、「プロパティ」ウィンドウの「一般」タブをクリックして、一意の識別文字列を「名前」フィールドに入力します。

新しい名前が、分割-結合定義エディタでノードの下に表示されます。

11. 「説明」フィールドに、重要と思われるノートを入力します。

12. JDeveloperのツールバーで、「保存」をクリックします。

10.7 Oracle Service Busコンソールでの分割-結合の操作

分割-結合はJDeveloperで作成して構成しますが、分割-結合をOracle Service Busコンソールにインポートしてコンソールのプロジェクトに追加できます。これらは、プロジェクト全体をインポートすることでもインポートできます。コンソールから、ディスパッチ・ポリシーの指定、XQueryバージョンの更新およびSLAアラートの定義を行うことができます。

10.7.1 コンソールへの分割-結合のインポート方法

コンソールで分割-結合を操作する前に、これをJDeveloperからエクスポートしてコンソールにインポートする必要があります。リソースをコンソールにインポートしたら、分割-結合定義エディタでこれを開き、特定のプロパティの構成やSLAアラート・ルールの定義を行うことができます。リソースのエクスポートおよびインポートについては、「Oracle Service Busコンソールでのリソースのインポートとエクスポート」を参照してください。

10.7.2 コンソールでの分割-結合の構成方法

Oracle Service Busコンソールで構成できるのは、分割-結合の特定のプロパティのみです。分割-結合の処理ロジックは構成できません。

コンソールで分割-結合を構成するには:

1. プロジェクト・ナビゲータで、構成する分割-結合に移動します。

2. 分割-結合を右クリックして、「開く」を選択します。

分割-結合定義エディタに分割-結合が表示されます。

3. 「説明」フィールドに、分割-結合に関する重要なノートを入力します。

4. 「ディスパッチ・ポリシー」フィールドで、分割-結合の実行に使用するWebLogic Serverワーク・マネージャを選択します。

5. 「スニペットのバージョン」フィールドで、分割-結合でXQueryを処理するためのXQueryのバージョンを選択します。

6. 「保存」をクリックします。

10.7.3 分割-結合に対するサービス・レベル合意のルールの定義方法

サービス・レベル合意(SLA)のアラートを使用する場合、システム管理者は、分割-結合のヘルスを示す特定の条件が満たされるタイミングを把握できます。アラートは、エラー・カウント、メッセージ・カウント、経過時間、メッセージ処理の失敗率や成功率などの統計に基づき定義できます。SLAアラートの定義の詳細は、『Oracle Service Busの管理』のサービス・レベル合意のアラート・ルールの作成に関する項を参照してください。

10.8 静的および動的分割-結合のサンプル

この項では、サンプル・シナリオを使用して静的分割-結合および動的分割-結合を作成する方法について説明します。

- 静的な分割-結合の設計

- 動的な分割-結合の設計

10.8.1 静的な分割-結合の設計

このシナリオでは、テレビ、電話、インターネット・サービスを含む電話会社のケーブル・サービスのパッケージの注文を処理するService Availabilityという名前の新しい分割-結合を作成します。パッケージの注文を受信し、各種類のサービスに対して受注確認を返信するというのが、分割-結合での考え方になります。この例では、注文ごとに各タイプのサービスについて3つのメッセージ・リクエストがあるため、Service Availabilityは静的分割-結合として設計されます。この例では、顧客はテレビとDSLサービスのみをリクエストします。

Service Availability分割-結合の作成には次の手順が含まれます。

新しい分割-結合の作成

割当ての追加

パラレル・ノードの追加

各ブランチに対する割当ての追加

サービスを呼び出すの追加

各ブランチに対する割当ての追加

分割-結合のエクスポートとテスト

10.8.1.1 新しい分割-結合の作成

注文の実行に使用するWSDL操作に基づいて分割-結合を作成します。この例では、WSDL操作を「telecom」と呼びます。

WSDL操作を選択すると、次の図に示すように、新しく作成された分割-結合のスケルトンが分割-結合エディタに表示されます。スケルトンは開始ノード、受信ノード、返信ノードから構成されます。「プロパティ」ウィンドウにあるラベルは、この特定の分割-結合の各ノードの固有の機能をより適切に反映したものに編集されます。

図10-5 新しい分割-結合

開始ノードには、最初に選択されたWSDL操作によって決定されたリクエスト変数とレスポンス変数が両方とも含まれます。受信ノードでは受信リクエスト・メッセージ(この例では3種類以下のケーブル・サービス)を受信し、返信ノードではレスポンス・メッセージを生成して、これをクライアントに戻します。

注意:

受信ノードには、これ以上の構成は必要ありません。同様に、返信では、エラー・フォルトを生成する場合(このシナリオには該当しない)を除き、これ以上の構成は必要ありません。

10.8.1.2 割当ての追加

最初の割当てPrepare Output Messageには、後からノードでその中のデータを操作きるような形でレスポンス変数を用意する割当て操作が含まれます。この出力メッセージは、分割-結合の最終的な返信ノードに中継され、その結果、元のクライアントに戻ります。

10.8.1.3 パラレル・ノードの追加

パラレル・ノードには、ケーブルTVの可用性の確認と、DSLの可用性の確認の2つの主要ブランチがあります。各ブランチはいくつかのアクションで構成されており、そのシーケンスと全体的な構成は両方のブランチで同じになっています。

図10-6 パラレル・ノード

10.8.1.4 各ブランチに対する割当ての追加

各パラレル・ブランチの最初の割当てであるPrepare Input Addressでは、その場所でサービスが利用できるかどうかを確認するために、受信した顧客アドレス・データを、参照されている変数にコピーします。この割当ては、各ブランチに対して同じになっており、これはブランチが追加される場合でも同様です。

10.8.1.5 サービスの呼出しの追加

次に外部サービスが呼び出されて、リクエストされたサービスのタイプが顧客のいる場所で利用可能であるかどうかがチェックされます。各ブランチには、1つのサービスを呼び出す、「TVの利用可能性のチェック」、および「DSLの利用可能性のチェック」が含まれます。それぞれの外部サービスの呼出しでは、顧客のアドレス(前の手順で初期化された変数に格納されている)が、その場所でのサービスの利用可能性と比較されます。結果は出力変数に格納され、次の手順であるブランチの最終的な割当てに渡されます。

10.8.1.6 各ブランチに対する割当ての追加

最終的な2つの割り当て、「出力メッセージのケーブルTVステータスの更新」と「出力メッセージのDSLステータスの更新」では、外部サービス呼出しの結果を取得し、置換操作を使用して、これを出力メッセージに入れます。集約されたレスポンスは、これ以上の構成が必要でない最終的な返信ノードにある元のクライアントに送信されます。

10.8.1.7 分割-結合のエクスポートとテスト

分割-結合の設計が終了したら、これをテストと本番用にOracle Service Busコンソールにエクスポートできます。

図10-7 テスト前の完成した分割-結合

関連項目

- JDeveloperでの分割-結合の作成方法

- 開始ノードの構成方法

- 変数への値の割当て方法

- サービスの呼出し方法

- 固定数のリクエストの並行処理方法

10.8.2 動的な分割-結合の設計

このシナリオでは、個別の発注の数が(発注数が固定してる注文とは異なり)変化する、小売業者からの一括注文を処理する分割-結合を設計する場合を考えてみます。一括注文を受信し、その中にある各注文に受注確認を返信するというのが、分割-結合での考え方になります。個別の発注数リクエストの数は変化し、設計時にその数を知ることはできないので、これは動的な分割-結合になります。

この分割-結合の作成には次のタスクが含まれます。

新しい分割-結合の作成

割当ての追加

For Eachの追加

割当ての追加

サービスを呼び出すの追加

割当ての追加

エラー・ハンドラの追加

分割-結合のエクスポートとテスト

10.8.2.1 新しい分割-結合の作成

注文の実行に使用するWSDL操作に基づかない新しい分割-結合を作成します。この例では、WSDL操作を「batchOrders」と呼びます。この操作が選択されると、開始ノード、受信ノード、返信ノードから構成される新しく作成された分割-結合のスケルトンが、分割-結合エディタに表示されます。これらのラベルは、この特定の分割-結合の各ノードに固有の機能をより適切に反映するように、全般プロパティ・タブで編集されます。

図10-8 新しい分割-結合(ラベルの編集)

開始ノードである「注文の実行」には、リクエスト変数inputVarとレスポンス変数outputVarの両方が含まれます。受信ノードである「一括注文リクエストの受信」は、リクエスト変数(この例の場合は発注)の内容を初期化し、返信ノードである「注文の実行への返信」は、レスポンス変数に集約された受注確認に基づいてレスポンスをクライアントへ戻します。この例では、「注文の実行」には、個別の注文を承認するために呼び出される外部サービス「Order」へのコールアウトが含まれています。

注意:

受信ノードには、これ以上の構成は必要ありません。同様に、返信ノードには、エラー・フォルトを生成する場合(このシナリオには該当しない)を除き、これ以上の構成は必要ありません(フォルトの生成の詳細は、「返信の構成方法」を参照)。

10.8.2.2 割当ての追加

最初の割当てである「出力メッセージの用意」には、後からレスポンス変数(ここでは理解を容易にするために「出力メッセージ」というラベルになっています)をノード内にキャプチャしたデータで作業(つまり、変数へのコピー、挿入、割り当て、置換、削除)できるような形で用意する割当て操作が含まれます。この場合、データは受注確認やエラーで構成されます。この出力メッセージは、分割-結合の最終的な返信ノードに中継され、その結果、元のクライアントに戻ります。

10.8.2.3 For Eachの追加

For Eachである「注文全体で繰返し」には、一括注文内にある個別の注文を1つずつ解析して、承認のために外部プロキシに送信し、レスポンス内にある受注確認をキャプチャするロジックが含まれます。注文に問題がある場合、呼び出されたプロキシからエラーが送信され、エラー・ハンドラでキャプチャされます。次の図にFor Eachロジックのスコープ全体を示します。

図10-9 「注文全体で繰返し」というラベルのFor Eachノード

10.8.2.4 割当ての追加

割当て「発注の準備」は、受信発注リクエストを、次の手順で承認をチェックするために参照される変数にコピーします。

10.8.2.5 サービスの呼出しの追加

次に外部サービス「注文の有効性のチェック」が呼び出され、個別の発注ごとに承認を行います。注文が受け入れられる場合、サービスは受注確認で応答します。注文が受け入れられない場合、サービスはエラーで応答します。この結果は出力変数に格納され、次の手順で説明する最終的な割当てに渡されます。

10.8.2.6 割当ての追加

最終的な割当てである「出力メッセージの注文ステータスの更新」は、外部サービス呼出しの結果を取得し、挿入操作を使用してこの結果を出力メッセージにコピーします。集約されたレスポンスは、これ以上の構成が必要でない最終的な返信ノードにある元のクライアントに送信されます。

10.8.2.7 エラー・ハンドラの追加

エラー・ハンドラは、呼び出されたサービスから返されたすべてのエラーをキャプチャします。エラー・ハンドラは、エラーを取得し、割当て操作を使用してこれを出力メッセージに挿入します。

図10-10 エラー・ハンドラ

10.8.2.8 分割-結合のエクスポートとテスト

分割-結合の設計が終了したら、これをテストと本番用にOracle Service Busコンソールにエクスポートできます。

図10-11 テスト前の完成した分割-結合

11 WSDLドキュメントの操作

この章では、Web Service Definition Language (WSDL)ドキュメントについて、およびService Busプロジェクトでこれらのドキュメントを使用してビジネス・サービス、プロキシ・サービス、パイプラインおよび分割-結合を生成する方法について説明します。WSDLドキュメントはWebサービスの正式な記述で、サービスで何が実行できるか、サービスのある場所およびサービスの呼出し方法を定義します。

この章の構成は、次のとおりです。

- WSDLの概要

- Service BusでのWSDLドキュメント

- WSDLポートとWSDLバインドに基づくサービス

- WSDLリソースのインポートとエクスポート

- JDeveloperでのWSDLドキュメントの操作

- Oracle Service BusコンソールでのWSDLドキュメントの操作

- 有効なWSDLドキュメントの表示

11.1 WSDLの概要

WSDLドキュメントでは、サービス、サービスの場所、サービス操作、およびクライアントがサービスと通信する方法を記述します。この項では、Service Busの機能を説明する際のコンテキストを提供するために、WSDLの概要を簡単に説明します。

表11-1に、WSDLサービスの定義に使用する主な要素を示します。

表11-1 上位のWSDL要素

要素

説明

types

メッセージ・コンテンツの型定義。

message

やり取りされるデータの抽象的な定義。メッセージはパートで構成され、パートはメッセージの理論上抽象的な内容を表します。

portType

サービスでサポートされる操作の抽象的な集合。

operation

サービスでサポートされるアクションの抽象的な説明。

binding

ポート・タイプの具体的なプロトコルとデータ形式の指定。

port

ネットワーク・アドレスとバインディングで構成される単一のエンドポイント。

service

関連するポートまたはエンドポイントの集合。

WSDLでは、SOAP、HTTP、MIMEおよびService Bus固有のバインディング拡張が指定され、これらは、WSDLバインド・メカニズムを拡張することで、プロトコル固有またはメッセージ形式固有の機能をサポートします。

11.1.1 WSDL型

types要素は、データ型定義のコンテナです。この要素では、XMLスキーマ(XSD)などの型システムを使用して、このサービスで処理されるメッセージのボキャブラリを定義します。たとえば、株価を提供するサービスの場合、次の例に示すように、TradePriceRequestおよびTradePriceという用語によってXMLボキャブラリを定義できます。

例 - WSDLの型の例

<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

11.1.2 WSDLメッセージ

message要素は、通信するデータの抽象的な型付き定義です。メッセージはパートで構成され、各パートは、メッセージの1つの論理抽象単位を表します。WSDLドキュメントでは、1つ以上のメッセージを定義でき、各メッセージには1つ以上のパートを含めることができます。たとえば、次の例のWSDLフラグメントでは、sellerInfoMessage、buyerInfoMessage、responseおよびnegotiationMessageの4つのメッセージ・タイプが定義されており、各メッセージ・タイプには1つ以上のパートが含まれています。

例 - WSDLメッセージの例

<message name="sellerInfoMessage">
<part name="inventoryItem" type="xsd:string"/>
<part name="askingPrice" type="xsd:integer"/>
</message>

<message name="buyerInfoMessage">
<part name="item" type="xsd:string"/>
<part name="offer" type="xsd:integer"/>
</message>

<message name="response">
<part name="result" type="xsd:string"/>
</message>

<message name="negotiationMessage">
<part name="item" type="xsd:string"/>
<part name="price" type="xsd:integer"/>
<part name="outcome" type="xsd:string"/>
</message>

11.1.3 WSDLポート・タイプ

portType要素では、(port要素で定義された)1つ以上のエンドポイントがサポートする一連の操作を定義します(「WSDLのサービスとポート」を参照)。ポート・タイプは、サービスが提供する操作のパブリック・インタフェースを提供します。各操作は、サービスがサポートするアクションの抽象的な記述である<operation>要素で定義されます。

たとえば、次の例では1つのオペレーションGetLastTradePriceでポート・タイプを定義し、これは入力メッセージGetLastTradePriceInputおよび出力メッセージGetLastTradePriceOuputを処理します。次の例のsoap:operation下位要素に示すように、これらのメッセージの具体的な記述はWSDLバインドで定義されています。

例 - WSDLのポート・タイプと操作の例

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

11.1.4 WSDLバインド

binding要素では、ポート・タイプの具体的なデータ・フォーマット仕様と具体的なトランスポート・プロトコルを指定します。次の例では、type属性の値として提供されるStockQuotePortTypeポート・タイプのバインディングを指定します。soap:binding下位要素は、このバインディングがSOAPプロトコル形式にバインドされることを示します。この下位要素では、style属性でデータ・フォーマットがSOAPドキュメント・スタイルであることを指定し、transport属性で転送プロトコルがHTTPであることを指定しています。

例 - WSDLのバインディングの例

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation
soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

11.1.5 WSDLのサービスとポート

service要素では、関連するエンドポイントの集合を定義します。各エンドポイントは、port子要素で定義されます。ポートでは、ネットワーク・アドレスに関連付けられたバインディングを定義します。次の例では、StockQuotePortとStockQuotePortUKの2つのポートが定義されています。この2つのポートは、(bindingで具体的に定義された)tns:StockQuoteSoapBindingという同じバインディングを使用していますが、ネットワーク・アドレスは異なります(http://example.com/stockquoteとhttp://example.uk/stockquote)。これらのポートは、このサービスで使用できる代替ポートです。

例 - WSDLのサービスとポートの例

<service name="StockQuoteService">
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com:9999/stockquote"/>
</port>
<port name="StockQuotePortUK" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.uk:9999/stockquote"/>
</port>
</service>

11.2 Service BusでのWSDLドキュメント

Service Busでは、WSDLドキュメントは、プロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合を記述します。既存のWSDLリソースを基にしてSOAPおよびXMLサービスを構築できます。Service Busでは、WSDLドキュメント(Webサービスを記述するためのXMLベースの仕様)を使用して、複数のタイプのビジネス・サービス、プロキシ・サービスおよびパイプラインを定義します。すべての分割-結合は、WSDLドキュメントに基づきます。WSDLドキュメントには、サービス操作、入力/出力パラメータ、およびクライアントがサービスに接続する方法が記述されます。WSDL 1.1仕様については、W3C Noteの『W3C Web Services Description Language (WSDL) 1.1』(http://www.w3.org/TR/wsdl)を参照してください。

Oracle Service BusではWSDLに関する以下の2つの性質を考慮して、プロキシ・サービスおよびビジネス・サービスが定義されます。

- インタフェース内の操作、および操作の署名のメッセージ部のタイプを定義する抽象WSDLインタフェース。

- メッセージ部のメッセージへのバインディング(パッケージング)、およびメッセージのトランスポートへのバインディングを定義するバインディングWSDLインタフェース。

11.2.1 Webサービス・タイプ

サービスでWSDLインタフェースが明確に定義されている場合、WSDLドキュメントを使用してサービスを定義することをお薦めします(必須ではありません)。3タイプのWSDLドキュメントを定義できます。

- SOAPドキュメント・ラップのWebサービス

- SOAPドキュメント・スタイルのWebサービス

- SOAP RPCのWebサービス

11.2.1.1 SOAPドキュメント・ラップのWebサービス

ドキュメント・ラップのWebサービスは、ドキュメント・スタイルのサービスとしてWSDLファイルに記述されています。ただし、いくつかの追加規約に従います。標準のドキュメント指向のWebサービス操作では、1つのパラメータまたはメッセージ部分のみを取得します(通常は、XMLドキュメントを取得します)。つまり、操作を実装するメソッドに含まれるパラメータも1つだけである必要があります。これに対して、ドキュメント・ラップのWebサービス操作では、パラメータをいくつでも取得できます。パラメータ値は、SOAPメッセージ内の1つの複合データ型にラップされます。このラップされた複合データ型は、操作の1つのドキュメントとしてWSDLドキュメントに記述されます。

11.2.1.2 SOAPドキュメント・スタイルのWebサービス

Service Busサービスは、SOAPスタイル・サービスとして構成できます。次に、SOAP 1.1を使用するサンプルのドキュメント・スタイルWebサービスWSDLの例を示します。

例 - ドキュメント・スタイルのサンプルWebサービスのWSDL

<definitions name="Lookup"
targetNamespace="http://example.com/lookup/service/defs"
xmlns:tns="http://example.com/lookup/service/defs"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:docs="http://example.com/lookup/docs"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<xs:schema targetNamespace="http://example.com/lookup/docs"
elementFormDefault="qualified">
<xs:element name="PurchaseOrg" type="xs:string"/>
<xs:element name="LegacyBoolean" type="xs:boolean"/>
</xs:schema>
</types>
<message name="lookupReq">
<part name="request" element="docs:purchaseorg"/>
</message>
<message name="lookupResp">
<part name="result" element="docs:legacyboolean"/>
</message>
<portType name="LookupPortType">
<operation name="lookup">
<input message="tns:lookupReq"/>
<output message="tns:lookupResp"/>
</operation>
</portType>
<binding name="LookupBinding" type="tns:lookupPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="lookup">
<soap:operation/>
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
</definitions>

このサービスには、lookupという操作(Javaクラスのメソッドに相当)が含まれています。バインディングは、これがSOAP 1.1ドキュメント・スタイルWebサービスであることを示しています。

前述のWSDLドキュメントをリクエストに使用したときに、ドキュメント・スタイルのプロキシ・サービスが取得するbody変数($body)の値を次の例に示します。

注意:

わかりやすくするために、次のコード・リストではXMLからネームスペース宣言を削除しています。

例 - body変数の値

<soap-env:body>
<req:purchaseorg>Oracle</req:purchaseorg>
</soap-env:body>

前述の例では、soap-envは定義済のSOAP 1.1ネームスペースで、reqはPurchaseOrg要素のネームスペース(http://example.com/lookup/docs)です。

プロキシ・サービスによるルーティング先となるビジネス・サービスで前述のWSDLファイルを使用した場合、前述のbody変数($body)の値はプロキシ・サービスのbody変数($body)の値になります。

呼び出されたビジネス・サービスからプロキシ・サービスが受信するレスポンスのbody変数($body)の値を次の例に示します。

注意:

わかりやすくするために、次のコード・リストではXMLからネームスペース宣言を削除しています。

例 - body変数の値

<soap-env:body>
<req:legacyboolean>true</req:legacyboolean>
</soap-env:body>

これは、このWSDLファイルを使用するプロキシ・サービスによって返されるレスポンスのbody変数($body)の値でもあります。

使用可能な多くのツールでは、プロキシ・サービスのWSDLファイル(ブラウザで、プロキシ・サービスのURLに?WSDL接尾辞を追加することによって取得)を受け取り、適切なリクエスト・パラメータとレスポンス・パラメータを持つJavaクラスを生成して、サービスの操作を呼び出します。このJavaクラスを使用して、このWSDLファイルを使用するプロキシ・サービスを呼び出すことができます。

11.2.1.3 SOAP RPC Webサービス

プロキシ・サービスとビジネス・サービスは、RPCスタイルのサービスとして構成できます。次に、SOAP 1.1を使用するサンプルのRPCスタイルWebサービスWSDLファイルの例を示します。

例 - RPCスタイルのサンプルWebサービスのWSDLファイル

<definitions name="Lookup"
targetNamespace="http://example.com/lookup/service/defs"
xmlns:tns="http://example.com/lookup/service/defs"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:docs="http://example.com/lookup/docs"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<xs:schema targetNamespace="http://example.com/lookup/docs"
elementFormDefault="qualified">
<xs:complexType name="RequestDoc">
<xs:sequence>
<xs:element name="PurchaseOrg" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ResponseDoc">
<xs:sequence>
<xs:element name="LegacyBoolean" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</types>
<message name="lookupReq">
<part name="request" type="docs: RequestDoc"/>
</message>
<message name="lookupResp">
<part name="result" type="docs: ResponseDoc"/>
</message>
<portType name="LookupPortType">
<operation name="lookup">
<input message="tns:lookupReq"/>
<output message="tns:lookupResp"/>
</operation>
</portType>
<binding name="LookupBinding" type="tns:lookupPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="lookup">
<soap:operation/>
<input>
<soap:body use="literal" namespace="http://example.com/lookup/service"/>
</input>
<output>
<soap:body use="literal" namespace="http://example.com/lookup/service"/>
</output>
</operation>
</binding>
</definitions>

前述のサービスには、lookupという操作(Javaクラスのメソッドに相当)が含まれています。バインディングは、これがSOAP RPC Webサービスであることを示しています。つまり、このWebサービスの操作では、一連のリクエスト・パラメータを受け取り、一連のレスポンス・パラメータを返します。lookup操作には、requestというパラメータとresultという戻りパラメータがあります。バインディングにおける操作のネームスペースは次のとおりです。

http://example.com/lookup/service/defs

前述のサンプルRPCスタイルWebサービスの例のWSDLファイルに示されたWSDLドキュメントをリクエストに使用したときに、SOAP RPCプロキシ・サービスが取得するbody変数($body)の値を次の例に示します。

注意:

わかりやすくするために、次のコード・リストではXMLからネームスペース宣言を削除しています。

例 - body変数の値

<soap-env:body>
<ns:lookup>
<request>
<req:purchaseorg>Oracle</req:purchaseorg>
</request>
</ns:lookup>
<soap-env:body>

ここで、soap-envは定義済のSOAP 1.1ネームスペース、nsは操作のネームスペース(http://example.com/lookup/service)、reqはPurchaseOrg要素のネームスペース(http://example.com/lookup/docs)です。

プロキシ・サービスによるメッセージのルーティング先となるビジネス・サービスで前述の例のWSDLファイルを使用した場合、次の例に示すbody変数($body)の値は、プロキシ・サービスのbody変数($body)の値になります。

このWSDLドキュメントがリクエストに使用された場合に、呼び出されたビジネス・サービスから、プロキシ・サービスが受信するレスポンスのbody変数($body)の値を次の例に示します。

例 - body変数の値

<soap-env:body>
<ns:lookupResponse>
<result>
<req:legacyboolean>true</req:legacyboolean>
</result>
</ns:lookupResponse>
<soap-env:body>

これは、このWSDLファイルを使用するプロキシ・サービスによって返されるレスポンスのbody変数($body)の値でもあります。

使用可能な多くのツールでは、プロキシ・サービスのWSDLファイル(ブラウザで、プロキシのURLに?WSDL接尾辞を追加することによって取得)を受け取り、適切なリクエスト・パラメータとレスポンス・パラメータを持つJavaクラスを生成して、サービスの操作を呼び出します。このようなJavaクラスを使用して、このWSDLファイルを使用するプロキシ・サービスを呼び出すことができます。

WSDLドキュメントを使用する利点は次のとおりです。

- システムでWSDLドキュメントの各操作のメトリックを提供できます。

- パイプラインで操作ブランチが可能になります。詳細は、「パイプラインの分岐」を参照してください。

- SOAP 1.1サービスの場合、プロキシ・サービスが呼び出すサービスにSOAPActionヘッダーが自動的に作成されます。SOAP 1.2サービスの場合、プロキシ・サービスが呼び出すサービスにContent-Typeヘッダーのactionパラメータが自動的に作成されます。

- WS-Securityを使用するサービスにはWSDLファイルが必要です。WS-PolicyはWSDLファイルに添付されます。

- システムが<url>?WSDL構文をサポートしているため、HTTPプロキシ・サービスのWSDLファイルを動的に取得できます。これは、多くのSOAPクライアント生成ツールにとって便利です。詳細は、「WebブラウザでのService Busリソースの表示」を参照してください。

- XQueryエディタ、XPathエディタおよび条件ビルダーでは、プロキシ・サービスのWSDLファイルのリクエスト・メッセージにbodyコンテンツ変数($body)がデフォルトでマップされるため、$bodyの操作が容易になります。「メッセージ・コンテキスト」を参照してください。

- 特定のアクションにおける$bodyの実行時のコンテンツが、エディタに表示されるデフォルト・マッピングと異なる場合があります。これは、Service Busが型付きの変数を宣言して使用するプログラミング言語ではないためです。変数は型なしであり、値が割り当てられると実行時に動的に作成されます。また、変数の型は、メッセージ・フローの任意の位置でコンテンツに基づく型になります。XQuery式およびXPath式を容易に作成できるように、エディタでは、指定した変数をエディタで型にマップすることによって、その変数の型をマップできます。XQueryエディタおよびXPathエディタを使用して式を作成する方法については、「変数の構造での作業」を参照してください。

11.2.2 有効なWSDLドキュメントと生成されたWSDLドキュメントについて

Service Busでは、WSDLリソースと呼ばれる既存のWSDLファイルに基づいて新しいサービスを作成し、構成プロパティをオーバーライドしたり追加したりできます。実行時、Service Busでは、WSDLリソースの構成と追加のトランスポートやランタイム構成を含む、サービスの有効なWSDLドキュメントを生成します。

11.2.2.1 有効なWSDLドキュメント

WSDLベースのサービスの場合、Service Busでは、Service Busサービスの開発時に作成する実際の.wsdlファイルのかわりに、有効なWSDLドキュメントを実行時に使用します。有効なWSDLドキュメントとは、Service Busで構成されたサービスのWSDLプロパティであり、この中には、ソースWSDLドキュメントの外部で構成された追加プロパティも含まれます。ソースWSDLドキュメントは、有効なWSDLドキュメントのテンプレートとして機能します。

サービスをWSDLドキュメントに基づいて作成する場合、Service Busでは、元のWSDLドキュメントのプロパティ、構成したトランスポート・プロパティ、ランタイムの設定(ターゲット・サーバーなど)および任意のWS-Policy構成を組み合せて、有効なWSDLドキュメントを実行時に生成します。実行時に元のWSDLドキュメントに対して追加または変更したプロパティは、有効なWSDLドキュメントに含まれます。新しい構成で使用されないソースWSDLドキュメントのプロパティは、有効なWSDLドキュメントから省かれます。

Service Busでは、WSDLドキュメントから作成され、WSDLベースのサービスをサポートするトランスポート(HTTP、JMS、SBなど)を使用するSOAPおよびXMLサービスに対して有効なWSDLドキュメントを生成できます。Service Busでは、タイプが任意のSOAP、任意のXMLおよびメッセージングのサービスに対しては、有効なWSDLドキュメントを生成できません。

有効なWSDLドキュメントは、プロキシ・サービスとビジネス・サービス、およびWSDLポートに基づくサービスとWSDLバインドに基づくサービスに対して異なる特性を備えています。詳細は、「WSDLポートとWSDLバインドに基づくサービス」を参照してください。

11.2.2.2 生成されたWSDLドキュメント

生成されたWSDLドキュメントとは、WSDLリソースから作成されてはいないが、WSDLドキュメントを使用して記述できるトランスポート型サービス用にService Busが生成する有効なWSDLドキュメントです。たとえば、EJBベースのサービスからWSDLドキュメントを生成できます。

11.3 WSDLポートとWSDLバインドに基づくサービス

WSDLリソースに基づいてサービスを作成する場合、サービスはWSDLポートまたはWSDLバインドに基づいている必要があります。

- WSDLリソースのバインティングに基づいて新しいサービスを作成する場合は、WSDLリソースで選択したbinding要素で定義されているプロトコルとデータ・フォーマットを選択します。

- WSDLリソースのポートに基づいて新しいサービスを作成する場合は、port要素で定義されているバインディングとネットワーク・アドレスを選択します。

サービスを作成または変更するときに、トランスポートは変更できますが、データ・フォーマットはオーバーライドできません。元のWSDLリソースのポート定義とバインディング定義は、次の項で説明するように、様々な要因に応じて有効なWSDL内で変更されます。

11.3.1 プロキシ・サービスの有効なWSDLドキュメント

プロキシ・サービス用に生成される有効なWSDLドキュメントには、次の特性が適用されます。

- 有効なWSDLドキュメントに含まれるwsdl:serviceセクションは1つのみです。

- wsdl:serviceセクションに含まれるwsdl:portセクションは1つのみです。

- SOAPサービスの場合、既存の<wsdl:service>定義が削除され、<wsdl:port>が1つ含まれた新しいサービス定義が作成されます。

- サポートされているすべてのトランスポートのSOAPバインディングでは、wsdl:bindingセクションに標準のWSDL SOAPバインディング要素と、トランスポートを識別する一意のトランスポートURIが含まれます。

- XML over HTTPバインディングでは、wsdl:bindingセクションでWSDL 1.1仕様で指定された標準のバインディング要素が使用されます。

- サポートされている他のすべてのトランスポートのXMLバインディングでは、wsdl:bindingセクションでOracle (Service Bus)独自のWSDL XMLバインディング要素が使用されます。

サービスがバインディングに基づく場合、次の特性が適用されます。

- 有効なWSDLドキュメントでは、新しいサービスとポート(<bindingname>QSServiceおよび<bindingname>QSPort)を定義します。WSDLリソースで定義されているポートは、有効なWSDLドキュメントには含まれません。

- そのバインディングに関連付けられたWSDLドキュメントに複数のポートが含まれている場合があります。ポートごとに異なるURLを使用できます。そのため、有効なWSDLドキュメントではこのバインディングが使用されますが、バインディングに対応するサービスの構成から代用ポートが生成されます。他のポートはすべて削除されます。

サービスがポートに基づく場合、次の特性が適用されます。

- サービスの基準となるポートも有効なWSDLドキュメントで定義されます。WSDLリソースで定義されているその他のポートは含まれません。また、WSDLポートに基づいてプロキシ・サービスを作成した場合、有効なWSDLドキュメントではそのポート名が使用されます。バインディングはポートから決定され、ポート・タイプはバインディングから決定されます。

- 有効なWSDLドキュメントには、WSDLリソースで定義されているポートに関連付けられたすべてのWS-Policyが保持されます。

- ソースWSDLドキュメントのポート定義で指定されているトランスポート・アドレスは、有効なWSDLドキュメントでプロキシ・サービスのアドレスとしては使用されません。

- HTTPサービスの場合、トランスポートを構成するときにトランスポート・アドレスを指定する必要があります。このアドレスが、有効なWSDLドキュメントのポート定義で使用されます。

- Service Busは常にプロキシ・サービスをホストするため、プロキシ・サービスのトランスポート・アドレスとして指定したURLは、常にService Busドメイン内のパスからの相対位置になります。

- SOAPプロトコルのWSDLサービスの場合、SOAPバインディングのトランスポートURIはトランスポートの実装によって異なります。標準のトランスポート(HTTPやJMSなど)の場合、この値はSOAP仕様または汎用的に受け入れられる別の値に従います。SOAPで標準の値が定義されていないトランスポートの場合、Service Busは末尾にトランスポートIDを付加した定義済のネームスペース(http://www.oracle.com/transport/2007/05/)で構成される値を設定します。

- 有効なWSDLドキュメントに含まれるサービス要素は1つで、ポート・アドレスには、バインディングで選択されているトランスポートで構文とセマンティクスが定義されたURLが含まれます。

11.3.2 非トランスポート型ビジネス・サービスの有効なWSDLファイル

トランスポート型ではないビジネス・サービス用に生成される有効なWSDLドキュメントには、次の特性が適用されます。

- 有効なWSDLドキュメントに含まれるwsdl:serviceセクションは1つのみです。

- wsdl:service sectionには、複数のwsdl:portセクションが含まれる場合があります。通常、これが該当するのは、ロード・バランシングを使用しており、サポートされるロード・バランシング・アルゴリズムのいずれかを使用することによって使用できる複数のエンドポイント・アドレスが存在する場合です。

- サポートされているすべてのトランスポートのSOAPバインディングでは、wsdl:bindingセクションに標準のWSDL SOAPバインディング要素と、トランスポートを識別する一意のトランスポートURIが含まれます。

- サポートされているすべてのトランスポートのXMLバインディングでは、wsdl:bindingセクションにOracleのWSDL XMLバインディング要素が含まれます。

- トランスポート・アドレスとして指定されたURLは、リモート・サービスがホストされるリモートの場所を示します。

サービスがポートに基づく場合、次の特性が適用されます。

- 有効なWSDLドキュメントでは、ソースWSDLドキュメントのポートと同じ名前のポートが定義されます。ビジネス・サービスに複数のエンドポイント・アドレスが構成されている場合、そのサービスから生成される有効なWSDLドキュメントですべてのエンドポイントのポートが<portname_in_template>_1、<portname_in_template>_2、... (以降も同様)という名前で定義されます。

- 新しいサービスのバインディングはポートから決定され、ポート・タイプはバインディングから決定されます。

- トランスポート・アドレスのURLは、リモート・サービスがホストされるリモートの場所を示します。

サービスがバインディングに基づく場合、次の特性が適用されます。

- 有効なWSDLドキュメントでは、WSDLリソースのポートに基づいて新しいサービスとポートが定義されます。WSDLリソースで定義されているポートは、有効なWSDLファイルには含まれません。

- WSDLリソースのバインディングが複数のポートに関連付けられている場合があります。ポートごとに異なるURLを使用でき、それぞれ異なるWS-Policyを添付できます。そのため、生成されるWSDLドキュメントではこのバインディングが使用されますが、バインディング用にWS-Policyが添付されていない代用ポートが生成されます。

- XMLベースのWSDLサービスでは、サービスでHTTPトランスポートを使用している場合にのみ、標準のHTTPバインディングが使用されます。XMLベースのWSDLファイルから作成される他のすべてのサービスでは、有効なWSDLドキュメントでOracleバインディングが使用されます。

11.3.3 トランスポート型ビジネス・サービスの有効なWSDLファイル

Service Busは、トランスポート型ビジネス・サービス用に生成される有効なWSDLドキュメントのwsdl:serviceセクションが1つのみであることを保証しません。WSDLドキュメントはトランスポートによって生成されるため、Service Busがserviceセクションとportセクションを生成することはなく、クリーンアップも行いません。ただし、Service Busは依存関係を評価し、エクスポート時にその参照を設定します。

11.3.4 ポートとバインディングに基づくプロキシ・サービスの例

次の例では、WSDLリソースのポート定義とバインディング定義のフラグメントを示します。

例 - WSDLリソース

<portType name="StockQuotePortType">
...
</portType>
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
...
</binding>
<service name="StockQuoteService">
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com:9999/stockquote"/>
</port>
<port name="StockQuotePortUK" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.uk:9999/stockquote"/>
</port>
</service>

11.3.4.1 ポートに基づくサービス

ポートとバインディングに基づくプロキシ・サービスの例の例に基づいてプロキシ・サービスを作成すると、有効なWSDLドキュメントは次の例のフラグメントのようになります。

例 - ポートに基づいたプロキシ・サービスの有効なWSDLファイル

<binding name="StockQuoteSoapBinding" type="ns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
...
</binding>
<service name="StockQuoteService">
<port name="StockQuotePort" binding="ns:StockQuoteSoapBinding">
<soap:address location="http://host:port/project/proxyname"/>
</port>
</service>

この例について、次の点に注意してください。

- テンプレートと有効なWSDLドキュメントのサービス名(StockQuoteService)は同じです。

- テンプレートと有効なWSDLドキュメントのバインディングは同じです。この例のバインディングでは、サービスがSOAPドキュメント・スタイルのメッセージにHTTP転送プロトコルを使用することを指定しています。この例では示されていませんが、WSDLリソースと有効なWSDLドキュメントでは、同じバインディング操作も指定されています。

- WSDLリソースで定義されている2つ目のポートStockQuotePortUKは、有効なWSDLドキュメントでは定義されていません。

- WSDLリソースのポートで定義されているトランスポート・アドレス(URI) http://example.com:9999/stockquoteは、有効なWSDLのポートで生成されたアドレスhttp://host:port/project_path/proxy_service_nameとは異なります。有効なWSDLドキュメントでは、その構成時にトランスポートに指定したアドレスが使用されます。

11.3.4.2 バインディングに基づくサービス

「ポートとバインディングに基づくプロキシ・サービスの例」にStockQuoteBindingバインディングに基づくプロキシ・サービスを作成すると、有効なWSDLドキュメントは次の項のフラグメントのようになります。

例 - バインディングに基づいたプロキシ・サービスの有効なWSDLドキュメント

<binding name="StockQuoteSoapBinding" type="ns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
...
</binding>
<wsdl:service name="StockQuoteSoapBindingQSService"
<wsdl:port name="StockQuoteSoapBindingQSPort"
binding="ns:StockQuoteSoapBinding">
<soap:address location="http:/host:port/project/proxyname"/>
</wsdl:port>
</wsdl:service>

この例について、次の点に注意してください。

- WSDLリソースのサービスとポートは、有効なWSDLドキュメントで生成されたサービスとポートとは異なります。

- WSDLリソースと有効なWSDLドキュメントのサービス名は異なります。テンプレートではStockQuoteService、有効なWSDLドキュメントではStockQuoteSoapBindingQSServiceです。

- WSDLリソースと有効なWSDLドキュメントのバインディングは同じです。この例のバインディングでは、サービスがSOAPドキュメント・スタイルのメッセージにHTTP転送プロトコルを使用することを指定しています。

- この例では示されていませんが、テンプレートと有効なWSDLドキュメントでは、同じバインディング操作も指定しています。

- WSDLリソースのポートで定義されているトランスポート・アドレス(URI)http://example.com:9999/stockquoteは、有効なWSDLのポートで生成されたアドレスhttp://host:port/project/stockquoteとは異なります。

11.4 WSDLリソースのインポートとエクスポート

WSDLドキュメントをエクスポートすると、有効なWSDLドキュメントおよび関連付けられた依存関係(XMLスキーマなど)を含むJARファイルが生成されます。Service Busはこの依存関係を評価し、WSDLのimport要素のlocation属性に適切な場所が追加されます。生成されたWSDLドキュメントをエクスポートすることはできません。

リソースのインポートとエクスポートの詳細は、「リソースおよび構成のインポートとエクスポート」を参照してください。

11.5 JDeveloperでのWSDLドキュメントの操作

JDeveloperでは、JCAアダプタに基づいて新しいプロキシ・サービスやビジネス・サービスを作成すると、WSDLファイルが生成されてService Busプロジェクトに追加されます。WSDLファイルは、標準のJDeveloperツールを使用して最初から作成することもできます。WSDLファイルは、Oracle Service Busコンソールでは生成されません。必要なWSDLファイルをサービスで使用するには、そのファイルをインポートする必要があります。

WSDLファイルは、JDeveloperの標準機能です。WSDLファイルの作成に使用するエディタとツールの詳細は、『Oracle JDeveloperによるアプリケーションの開発』のXMLを使用したアプリケーションの開発に関する項を参照してください。

11.5.1 JDeveloperでのWSDLリソースの作成方法

作成するWSDLリソースに、JDeveloperに現在存在しない外部スキーマへのURL参照(http://www.w3.org/2001/XMLSchema.xsdなど)が含まれている場合、XMLスキーマのリソースを作成することによって、それらのURL参照付きスキーマと依存するすべてのスキーマをService Busに追加する必要があります。Service BusのWSDLリソースは、ローカルで使用可能なスキーマのみを参照できます。WSDLファイルは、XMLスキーマ定義(XSD)ファイルまたはサンプル・ファイルを使用して生成できます。

新しいWSDLドキュメントの入力タイプと出力タイプを定義するには、メッセージ・パートにXMLタイプを指定する必要があります。ローカル・ファイル・システムに存在するスキーマXSDファイルを使用する場合、XSDファイルと、そのファイルがインポートするXSDファイルのすべてがJDeveloperのプロジェクト・ディレクトリにあることを確認します。これで、スキーマがプロジェクトとともにデプロイされて実行時に使用可能になります。

JDeveloperでWSDLドキュメントを作成するには:

1. 次のいずれかを行います:

- 新しいWSDLリソースを作成するには、アプリケーション・ナビゲータで、新しいWSDLファイルの配置先のプロジェクトまたはフォルダを右クリックします。「新規」をポイントし、「SOA WSDLドキュメント」を選択します。

- 新しいWSDLリソースをサービスの作成ウィザード内から作成するには、「WSDL」フィールドの右側の「WSDLの生成」アイコンをクリックします。

「WSDLの作成」ダイアログが表示されます。

2. 「WSDLの作成」ダイアログで、WSDLファイルの一意の名前を入力して、ファイルの保存先のディレクトリを入力するか、デフォルトのままにします。
デフォルトでは、ファイルはプロジェクト・フォルダに格納されます。これは、現在のプロジェクト・ディレクトリまたはそのサブディレクトリのいずれかにしてください。指定のディレクトリが存在しない場合、Oracle JDeveloperでディレクトリが作成されます。

3. 「ネームスペース」フィールドに、WSDLファイルのネームスペース・アドレス(http://example.com/OrderProcess/wsdlなど)を入力します。
指定するネームスペースは、WSDLファイルでtnsネームスペースとして定義されます。

4. 「バインディング」フィールドに、サービス用に作成する、WSDLファイルのバインディングの名前を入力します。使用可能なオプションのリストから、バインディング・タイプを選択します(SOAP 1.1、SOAP 1.2またはXML)。

5. 「ポート・タイプの作成」を選択してWSDLドキュメントの新しいポート・タイプと操作を作成するか、「ポート・タイプの選択」を選択して既存のWSDLドキュメントからポート・タイプを選択します。

6. 次のいずれかを行います:

- ポート・タイプの作成を選択した場合は、引き続き手順7に進みます。

- ポート・タイプの選択を選択した場合は、「WSDL URL」フィールドの横の「WSDLの選択」をクリックし、使用するWSDLファイルを参照して選択します。次に、使用可能なオプションのリストからポート・タイプを選択します。手順14にスキップします。

7. 「ポート・タイプ」フィールドに、使用する操作を含むポート・タイプの名前を入力します。

8. 「操作」フィールドに、使用する操作の名前を入力します。

注意:

操作名やポート・タイプで、空白や特殊文字は使用できません。アルファベットおよび数字のみがサポートされますが、最初の文字に数字は使用できません。

9. 「インタフェース・タイプ」フィールドで、リクエスト専用メッセージングの場合は「一方向インタフェース」を選択し、リクエスト/レスポンス・メッセージングの場合は「同期インタフェース」を選択します。
使用可能なフィールドは、選択内容に応じて異なります。

10. 「入力」フィールドの右上の「新規メッセージ・パートを追加します。」をクリックします。

11. 「メッセージ・パートの追加」ダイアログで、次のようにします。

a. 「パート名」フィールドに、メッセージ・パートの名前を入力します。

b. 「URL」フィールドの右側で、「スキーマ・ファイルを参照」アイコンをクリックし、XMLタイプを参照して選択します。
「タイプ・チューザ」ダイアログが表示され、選択元のスキーマとWSDLファイルのリストが表示されます。

c. 「タイプ・エクスプローラ」ツリーを開き、使用するスキーマ・ルート要素を見つけて選択し、「OK」をクリックします。
「メッセージ・パートの追加」ダイアログが再度表示され、「URL」と「スキーマ要素」フィールドに「タイプ・チューザ」ダイアログからのデータが移入されます。XSD単純型を選択した場合、「スキーマ要素」フィールドは「単純型」フィールドで置き換えられます。

ヒント:

使用するスキーマが、作業しているプロジェクトにない場合、「スキーマ・ファイルのインポート」またはダイアログの右上隅にある「WSDLのインポート」アイコンを使用して、スキーマXSDファイルまたはWSDLファイルをプロジェクトにインポートできます。

d. 「OK」をもう一度クリックします。
「WSDLの作成」ダイアログの「入力」フィールドに新しいメッセージ・パート情報が表示されます。

12. 必要に応じて、前述の手順を繰り返して、追加のメッセージ・パートを定義します。

13. インタフェース・タイプに「同期インタフェース」を選択した場合、前述の手順を繰り返して、出力およびフォルト・メッセージ・パートを定義します。

14. 「OK」をクリックします。

注意:

パートナ・リンク・タイプは、通常BPELで使用されるため、Service Busに「partnerlinkType拡張機能の生成」を選択する必要はありません。

11.5.2 JDeveloperでのサービスからのWSDLファイルの生成方法

生成WSDLファイルとは、WSDLリソースで開始されなかったが、WSDLファイルを使用して記述できるサービスのためにService Busが生成するWSDLファイル・リソースです。EJBまたはJEJBトランスポート型のビジネス・サービスやJEJBプロキシ・サービスに関連付けられたWSDLファイルを生成できます。

JDeveloperでサービスからWSDLファイルを生成するには:

1. アプリケーション・ナビゲータで、WSDLファイルの生成元となるプロキシ・サービスやビジネス・サービスを含むプロジェクトまたはフォルダを右クリックします。

2. 「Service Bus」をポイントし、「WSDLの生成」をクリックします。

「WSDLの生成」ダイアログが表示されます。

3. WSDLファイルの「WSDL名」と場所を指定します。

デフォルトでは、現在の場所は、プロジェクトのパス、およびサービスが存在するフォルダの名前になります。

4. 「OK」をクリックします。

警告:

リシーケンス用に構成されたパイプラインで使用するようWSDLファイルを生成している場合、リシーケンサがサポートするのは一方向(リクエスト)の操作のみであることに注意することが重要です。ここで生成するWSDLファイルには出力タグが含まれ、このファイルをパイプラインで使用する前に、このタグをポート・タイプおよびバインディング定義から削除する必要があります。

11.5.3 JDeveloperでのWSDLドキュメントの編集方法

WSDLドキュメントを作成すると、JDeveloperで標準のXMLエディタを使用してこれらをさらに構成できます。WSDLドキュメントの表示と構成に使用するエディタおよびツールの詳細は、『Oracle JDeveloperによるアプリケーションの開発』のXMLを使用したアプリケーションの開発に関する項を参照してください。

11.5.4 JDeveloperでのWSDLドキュメントの削除方法

WSDLドキュメントを作成したら、そのドキュメントをプロジェクトおよびファイル・システムから削除できます。JDeveloperのリファクタ機能を使用すると、WSDLドキュメントを参照するリソースを表示できます。削除する前に依存関係を確認するには、WSDLドキュメントを右クリックして、「依存性の参照」を選択します。

JDeveloperでWSDLドキュメントを削除するには:

1. アプリケーション・ナビゲータで、削除するWSDLファイルを右クリックします。

2. 「リファクタ」をポイントし、「削除」を選択します。

「削除の確認」ダイアログが表示されます。

3. WSDLドキュメントが別のService Busリソースで参照される場合、「使用方法の表示」をクリックして参照を表示し、WSDLドキュメントを削除するかどうかを検証します。

4. WSDLドキュメントの削除を確定する場合は、「はい」をクリックします。

11.6 Oracle Service BusコンソールでのWSDLドキュメントの操作

Oracle Service Busコンソールを使用する場合、WSDLドキュメントを作成するには、ドキュメントをインポートするかWSDLリソースを作成します。インポートの詳細は、「リソースおよび構成のインポートとエクスポート」を参照してください。WSDLリソースを手動で作成するには、次の手順を実行します。WSDLリソースにアップロードする既存のWSDLファイルが必要です。

11.6.1 コンソールでのWSDLリソースの作成方法

作成するWSDLリソースに、Service Busで現在存在しない外部スキーマへのURL参照(http://www.w3.org/2001/XMLSchema.xsdなど)が含まれている場合、XMLスキーマのリソースを作成することによって、それらのURL参照付きスキーマと依存するすべてのスキーマをOracle Service Busコンソールにインポートする必要があります。Service BusのWSDLリソースは、ローカルで使用可能なスキーマのみを参照できます。

コンソールでWSDLリソースを作成するには:

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. プロジェクト・ナビゲータで、新しいWSDLドキュメントを含めるプロジェクトまたはフォルダを右クリックして、「作成」をポイントし、「リソース」を選択します。「インタフェース」をクリックし、「WSDL」をクリックして「OK」をクリックします。
「WSDLの作成」ダイアログが表示されます。

3. 次のいずれかを行います:

- 既存のWSDLファイルからリソースを作成するには、「ファイルのアップロード」フィールドの横の「参照」をクリックしてから、使用するWSDLファイルに移動してそのファイルを選択します。
「リソース名」フィールドに、ファイル拡張子なしのファイル名が自動的に移入されます。この名前は変更可能です。

- 新しいWSDLファイルを作成するには、WSDLリソースの一意の名前を入力します。

4. 必要に応じて、リソースの簡単な説明を入力します。

5. 「作成」をクリックします。
WSDL要素(定義される場合)がWSDL定義エディタに表示されます。

6. WSDLファイルのコンテンツを変更するには、次のようにします。

a. ツールバーの「ソースの編集」をクリックします。
「ソースの編集」ダイアログが表示されます。

b. アップロードする新しいWSDLファイルを参照して選択するには、「参照」をクリックします。

c. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

d. 「保存」をクリックします。

7. WSDL定義エディタのツールバーで、「保存」をクリックします。
新しいWSDLドキュメントに未解決の参照がある場合は、エディタのタイトル・バーの横に「競合」アイコンが表示されます。戻る矢印と次に進む矢印ボタンを使用して、エラー全体をスクロールします。

8. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

11.6.2 コンソールでのWSDLファイルのエクスポート方法

プロジェクトまたはフォルダ定義エディタを使用して、プロキシ・サービスやビジネス・サービスに関連付けられたWSDLファイルをエクスポートします。Service Busでは、WSDLファイルはJARファイルとしてエクスポートされます。WSDLファイルは、セッション外にいるときのみエクスポートできます。

WSDLドキュメントをエクスポートすることで、これをIDEなどの外部ツールで消費できるようにします。WSDLエクスポート機能は、2つのドメイン間でリソースを移動およびステージングする場合に使用するリソースのエクスポート機能とは異なります。この機能は、すべてのサービス・タイプに使用できるわけではありません。

11.6.2.1 コンソールでのWSDLファイルのプロジェクトまたはフォルダからのエクスポート

コンソールでWSDLファイルをプロジェクトまたはフォルダからエクスポートするには:

1. プロジェクト・ナビゲータで、エクスポートするWSDLファイルを含むプロジェクトまたはフォルダをクリックします。

プロジェクトまたはフォルダの定義エディタが表示されます。

2. リソース表で、WSDLファイルをエクスポートするプロキシ・サービスまたはビジネス・サービスの行で「WSDLのエクスポート」アイコンをクリックします。

ファイル・ダイアログが表示されます。ダイアログのタイプとそのオプションは、使用するWebブラウザに応じて異なります。

3. 「開く」をクリックしてJARファイルを開くか、「保存」をクリックしてJARファイルをデスクトップに保存します。

11.6.2.2 サービス定義エディタからのWSDLファイルのエクスポート

サービス定義エディタからWSDLファイルをエクスポートするには:

1. Oracle Service Busコンソールで、開いているセッションにいないことを確認します。

2. プロジェクト・ナビゲータで、WSDLファイルのエクスポート元とするプロキシ・サービスまたはビジネス・サービスをクリックします。

プロキシまたはビジネス・サービス定義エディタが表示されます。

3. エディタの右上のツールバーで、ツール・アイコンをクリックし、「WSDLのエクスポート」をクリックします。

ファイル・ダイアログが表示されます。ダイアログのタイプとそのオプションは、使用するWebブラウザに応じて異なります。

4. 「開く」をクリックしてJARファイルを開くか、「保存」をクリックしてJARファイルをデスクトップに保存します。

11.6.3 コンソールでのサービスからのWSDLファイルの生成方法

生成WSDLファイルとは、WSDLリソースで開始されなかったが、WSDLファイルを使用して記述できるサービスのためにService Busが生成するWSDLファイル・リソースです。プロジェクトまたはフォルダ定義エディタを使用して、EJBまたはJEJBトランスポート型のビジネス・サービスやJEJBプロキシ・サービスに関連付けられたWSDLファイルを生成します。WSDLファイルを生成するには、セッション内で作業している必要があります。

コンソールでビジネス・サービスからWSDLファイルを生成するには:

1. プロジェクト・ナビゲータで、WSDLファイルの生成元となるプロキシ・サービスやビジネス・サービスを含むプロジェクトまたはフォルダをクリックします。

プロジェクトまたはフォルダの定義エディタが表示されます。

2. リソース表で、WSDLファイルを生成するサービスの行で「WSDLの生成」アイコンをクリックします。

WSDLリソースの生成ダイアログが表示され、現在の場所(プロジェクト名およびビジネス・サービスが存在するフォルダの名前)が強調表示されます。

3. WSDLリソースの名前および場所を指定し、「WSDLの生成」をクリックします。

警告:

このWSDLリソースをリシーケンス用に構成されたパイプラインで使用するように生成している場合、リシーケンサがサポートするのは一方向(リクエスト)の操作のみであることに注意することが重要です。ここで生成するWSDLファイルには出力タグが含まれ、このファイルをパイプラインで使用する前に、このタグをポート・タイプおよびバインディング定義から削除する必要があります。

11.6.4 コンソールでのWSDLドキュメントの編集方法

Oracle Service BusコンソールでWSDLリソースを作成すると、ファイルを必要に応じて変更できますが、その方法はソース・コードを直接変更するのみです。

WSDLドキュメントを編集するには:

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. プロジェクト・ナビゲータで、編集するWSDLリソースをクリックします。

WSDL定義エディタが表示されます。

3. ツールバーの「ソースの編集」をクリックします。

「ソースの編集」ダイアログが表示されます。

4. アップロードする新しいWSDLファイルを参照して選択するには、「参照」をクリックします。

5. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

6. 「保存」をクリックします。

7. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

11.6.5 コンソールでのWSDLドキュメントの削除方法

削除するWSDLドキュメントをいずれかのリソースが参照する場合、WSDLリソースを削除する前にそれらの参照を削除します。Oracle Service BusコンソールのWSDLドキュメント定義エディタでWSDLドキュメントを開き、右上のツール・アイコンをクリックし、「参照」を選択して、そのドキュメントに参照があるかどうかを確認します。

コンソールでWSDLドキュメントを削除するには:

1. アプリケーション・ナビゲータで、削除するWSDLリソースを含むプロジェクトとフォルダを開きます。

2. WSDLドキュメントの名前を右クリックして、「削除」を選択します。

WSDLリソースが削除されます。他のリソースがこのリソースを参照している場合、削除の警告アイコンが表示されます。確認のための警告は表示されますが、リソースを削除することはできます。この場合、削除されたリソースへの未解決の参照が原因で、競合が発生する可能性があります。

3. 「アクティブ化」をクリックしてセッションを終了し、構成をランタイムにデプロイします。

11.7 有効なWSDLドキュメントの表示

設計時のWSDLドキュメントと有効なWSDLドキュメントの両方をWebブラウザで表示できます。ブラウザ・ウィンドウからファイルにアクセスすると、ファイルのコンテンツがXML形式で表示されます。

有効なWSDLドキュメントには、次の3通りの方法でアクセスできます。

- Webブラウザで、次の構文を使用して固定HTTP URLを入力します。

http://host:port/sbresource?PROXY/project_path/proxy_service_name

または

http://host:port/sbresource?BIZ/project_path/business_service_name

この方法は、Service Busが、有効なWSDLドキュメントを生成できるサービスすべてに使用できます。

- Webブラウザで、HTTPベースのプロキシ・サービスのURLの末尾に?WSDLを付加して入力します。
この方法は、Service Busが、有効なWSDLドキュメントを生成できるHTTPトランスポートベースのサービスでのみ使用できます。

- WSDLリソースをエクスポートします。詳細は、「コンソールでのWSDLファイルのエクスポート方法」および「コンソールでのサービスからのWSDLファイルの生成方法」を参照してください。一般的なエクスポートについての情報は、「リソースおよび構成のインポートとエクスポート」を参照してください。
Service Busでは、URLを介してService Busに登録されたリソースを表示するために使用されるリソース・サーブレットが提供されます。URLを使用したService Busリソースへのアクセスの詳細は、「WebブラウザでのService Busリソースの表示」を参照してください。

設計時のWSDLドキュメントを表示するには、次の構文を使用してURLを入力します。

http://host:port/sbresource?WSDL/project_path/wsdl_name

第III部 Oracle Service Busパイプラインの操作

この部では、Service Busプロジェクトでパイプラインを作成して使用する方法について説明します。

この部は、次の章で構成されています。

- Oracle Service Busでのメッセージ・フローの作成

- Oracle Service Busコンソールでのパイプラインの操作

- Oracle Service Busコンソールでのパイプライン・アクションの操作

- Oracle Service Busコンソールでの式エディタの操作

- Oracle JDeveloperでのパイプラインの操作

- Oracle JDeveloperでのパイプライン・アクションの操作

- パイプライン・テンプレートの操作

12 Oracle Service Busでのメッセージ・フローの作成

この章では、Oracle Service Busコンソールを使用したパイプラインまたはメッセージ・フローの作成および構成に関する概要と概念について説明します。内容には、パイプラインのコンポーネント、メッセージ変換、ルーティングとサービス・コールアウト、エラー処理、メッセージ・コンテキストおよびサービス品質(QoS)が含まれます。

Service Busにおけるメッセージ・フローは、パイプラインの実装を定義します。パイプラインは、Oracle Service BusコンソールまたはOracle JDeveloperで作成して構成できます。分割-結合でメッセージ・フローを定義することもできます。詳細は、「分割-結合によるサービスのパフォーマンスの向上」を参照してください。

次の各項では、Service Busのパイプラインについて説明します。

- パイプライン・コンポーネント

- パイプラインの分岐

- ステージおよびルート・ノードでのアクションの構成

- パイプラインでのトランスフォーメーションの実行

- サービス・コールアウト・メッセージの作成

- サービス・コールアウト・メッセージでの添付ファイルの使用

- サービス・コールアウトの結果としてのエラー処理

- パイプラインでのエラー処理

- 動的ルーティングの使用

- XQueryを使用したデータベースへのアクセス

- メッセージ・コンテキストについて

- 変数の構造での作業

- サービスの品質

- Service Busでのワーク・マネージャの使用

- コンテンツ・タイプ、JMSタイプ、およびエンコーディング

- 抑制パターン

- WS-Iへの準拠

- SOAP 1.1とSOAP 1.2との間の変換

Oracle Service Busコンソールでパイプラインを作成および構成する手順については、次の章を参照してください。

- Oracle Service Busコンソールでのパイプラインの操作

- Oracle Service Busコンソールでのパイプライン・アクションの操作

Oracle JDeveloperでパイプラインを作成および構成する手順については、次の章を参照してください。

- Oracle JDeveloperでのパイプラインの操作

- Oracle JDeveloperでのパイプライン・アクションの操作

12.1 パイプライン・コンポーネント

パイプラインは、パイプラインを介してメッセージが流れるときのメッセージのルーティングと操作のロジックを定義するコンポーネントで構成されます。ノードは、メッセージ・フローを介してメッセージをルーティングするように構成されます。ステージおよびアクションには、メッセージを処理および変換するためのルールが含まれます。

表12-1に、パイプラインを定義する際に使用できるコンポーネントを示します。

表12-1 パイプライン・コンポーネント

コンポーネント・タイプ

サマリー

開始ノード

すべてのパイプラインは開始ノードで始まります。すべてのメッセージは、開始ノードを介してパイプラインに入ります。また、すべてのレスポンス・メッセージが開始ノードを介してクライアントに返されます。開始ノードで構成するものはありません。

パイプライン・ペア・ノード

パイプライン・ペア・ノードは、1つのリクエスト・パイプラインと1つのレスポンス・パイプラインを1つの最上位要素に統合したものです。パイプラインでは、パイプライン・ペア・ノードが持つことができる直接の子孫は1つのみです。リクエスト処理中にService Busがパイプライン・ペア・ノードを処理すると、リクエスト・パイプラインのみが実行されます。Service Busがレスポンス・パイプラインを処理すると、実行パスが反転されます。

ステージ

リクエスト・パイプライン、レスポンス・パイプライン、およびエラー・ハンドラには、ステージを含めることができます。ステージでは、パイプラインを通過するメッセージを処理するアクションを構成します。

「ステージおよびルート・ノードでのアクションの構成」も参照してください。

エラー・ハンドラ

ノードまたはステージで発生する可能性のあるエラーを処理するために、ノードまたはステージにエラー・ハンドラを追加できます。

「パイプラインでのエラー処理」も参照してください。

ブランチ・ノード

ブランチ・ノードを使用すると、可能ないくつかのパスのうちの1つに限定して処理を進めることができます。WSDLベースのサービスでは、操作ブランチがサポートされます。操作ブランチでは、分岐はWSDLファイルで定義された操作に基づいています。XPathベースの切替え表で定義された条件では、条件付きブランチがサポートされます。未入力のネイティブRESTサービスでは、RESTブランチがサポートされます。RESTブランチでは、使用されるメディア・タイプ、相対URI、およびHTTP動詞から派生するロジックに基づいています。未入力のRESTサービスでも、操作ブランチがサポートされます。操作ブランチでは、分岐はWADLファイルで定義されたメソッドに基づいています。

「パイプラインの分岐」も参照してください。

ルート・ノード

ルート・ノードでは、別のサービスやコンポーネントとのリクエスト/レスポンス通信が実行されます。これは、パイプラインに関するリクエスト処理とレスポンス処理の境界を表します。ルート・ノードがリクエスト・メッセージをディスパッチすると、リクエスト処理が終了したと見なされます。ルート・ノードがレスポンス・メッセージを受信したときに、レスポンス処理が始まります。ルート・ノードは、リクエスト・トランスフォーメーション、レスポンス・トランスフォーメーション、および条件付きルーティングに対応します。

ルート・ノードはリクエスト処理とレスポンス処理の境界を表すので、パイプライン内に子孫を持つことはできません。

「ステージおよびルート・ノードでのアクションの構成」も参照してください。

12.1.1 メッセージ・フローの構築

一般には、メッセージ・フローは次の形式のいずれかで設計します。

- 非オペレーション・サービス(操作を含むWSDLファイルに基づいていないサービス)のフローでは、ルートにパイプライン・ペアが1つあり、その後にルート・ノードを配置します。

- オペレーション・サービスのフローでは、ルートにパイプライン・ペアが1つあり、その後にオペレーション(またはRESTブランチに対して使用されるメディア・タイプ、パス、またはHTTP動詞)に基づくブランチ・ノードを配置します。さらに、各ブランチにはパイプライン・ペアが1つあり、その後にルート・ノードを配置します。

12.1.2 メッセージの実行

表12-2と表12-3に、一般的なメッセージ・フローでリクエスト・メッセージおよびレスポンス・メッセージが処理される仕組みを簡単に示します。

表12-2 メッセージ・フローでのリクエスト・メッセージのパス

パイプライン・ノード

メッセージ処理の内容

リクエスト処理

リクエスト処理コンテナ。

開始ノード

開始ノードでリクエスト処理が開始されます。

パイプライン・ペア・ノード

リクエスト・パイプラインだけが実行されます。

ブランチ・ノード

ブランチ表を評価し、関連するブランチに進みます。

ルート・ノード

リクエスト・トランスフォーメーションと共にルーティングが実行されます。

パイプラインでは、ルーティングが実行されるかどうかに関係なく、ルート・ノードはリクエストの処理からレスポンスの処理への移行を表します。ルート・ノードでは、メッセージ・フローの方向は逆方向になります。リクエスト・パスにルート・ノードが含まれていない場合、レスポンスを待機せずに、レスポンス処理は逆方向で開始されます。

表12-3 メッセージ・フローでのレスポンス・メッセージのパス

パイプライン・ノード

メッセージ処理の内容

レスポンス処理

ブランチ・ノードをスキップして、ブランチの前にあるノードに進みます。

ルート・ノード

レスポンス・トランスフォーメーションが実行されます。

ブランチ・ノード

ブランチ・ノードをスキップして、ブランチの前にあるノードに進みます。

パイプライン・ペア・ノード

レスポンス・パイプラインが実行されます。

開始ノード

クライアントにレスポンスを返します。

12.2 パイプラインの分岐

パイプラインでは、3種類の分岐がサポートされています。操作ブランチ・ノードで構成される操作ブランチと、条件付きブランチ・ノードで構成される条件付きブランチ、およびRESTブランチ・ノードで構成されるRESTブランチです。

12.2.1 操作ブランチ

メッセージ・フローでWSDLベースのパイプライン・サービスを定義する場合、操作固有の処理が必要になります。パイプラインに操作ブランチ・ノードを作成すると、WSDLファイルで定義された操作に基づいて分岐ロジックを作成できます。

パイプラインが複数の操作を含むWSDLファイルに基づいている場合は、操作ブランチを使用する必要があります。この場合、オペレーション・ブランチ・ノードを使用して、操作ごとにメッセージを個別に処理することを検討できます。パイプラインが入力済ネイティブRESTサービスに基づいている場合は、操作ブランチを使用することも可能です(このブランチは、WADLファイルに定義されたメソッドに基づいています)。

12.2.2 条件分岐

メッセージのドキュメント・タイプなど、指定した条件に基づいて分岐する場合は、条件付きブランチを使用します。

条件付きブランチでは、ルックアップ表に基づいて分岐が行われます。ルックアップ表に含まれる各ブランチは、QuantityEqualToOrLessThan150やQuantityMoreThan150のような単純で一意の文字列値でタグ付けされています。

(たとえば、パイプライン内の前のステージで宣言された)メッセージ・コンテキスト内の変数の値に基づいて分岐するように条件付きブランチを構成できます。また、ブランチ自体で定義されたXPath式の結果に基づいて分岐するように条件を構成することもできます。

実行時に、変数または式が評価され、その結果値を使用してどのブランチに進むかが判断されます。値と一致するブランチがない場合は、デフォルト・ブランチに進みます。ブランチ・ノードでは、パイプライン内にいくつかの子孫を持つことができます(デフォルトのブランチを含め各ブランチに1つずつ)。デフォルト・ブランチを必ず定義する必要があります。ブランチ・ノードに到達する前にルックアップ変数の値が設定されるように、パイプラインを設計します。

たとえば、ルックアップ変数を使用する次のケースについて考えてみます。パイプラインのタイプが任意のSOAPまたは任意のXMLであり、条件付きブランチを実行できるようにメッセージのタイプを特定する必要があるとします。この場合、メッセージ・タイプを特定するステージ・アクションを設計した後に、メッセージ・タイプに基づいて処理を分ける条件付きブランチ・ノードをフロー内に設計できます。

今度は、条件付きブランチ・ノードでXPath式を使用するケースを考えてみます。注文の数量に基づいて分岐させるとします。この数量は、$body内の既知の場所から取得できる変数によって渡されます。

数量を取得する次のXPath式を定義できます。

declare namespace openuri="http://www.openuri.org/";
declare namespace com="oracle.com/demo/orders/cmnCust";
./openuri:processCust/com:cmnCust/com:Order_Items/com:Item/com:Quantity

メッセージ・フローの下位に向かって、条件(<500など)が式に対して評価されます。最初に満たされた条件によって、進むべきブランチが決定されます。満たされる分岐条件がない場合は、デフォルトのブランチに進みます。

条件付きブランチを使用して、最上位のフロー・ビューでメッセージ・フローのルーティングの代替方法を公開できます。たとえば、メッセージ・フローの初期の既知の条件(メッセージ・タイプなど)に基づいて、サービスAまたはサービスBを呼び出す状況について考えてみます。ルート・ノードのルーティング表に条件付きブランチを構成できます。ただし、フローの最上位だけを調べる場合、この方法では分岐がやや困難になります。かわりに、条件付きブランチ・ノードを使用して、パイプライン自体にこのブランチを公開し、各ブランチのサブフローとして単純なルート・ノードを使用できます。

メッセージ・フロー、ステージまたはルート・ノードのどの場所にブランチを構成するかを決定する前に、ビジネス・シナリオを検討してください。パイプラインにブランチを構成する場合、ブランチ・ノードから多数のブランチが分岐すると、設計インタフェースが煩雑になる可能性があることに注意してください。

12.2.3 RESTブランチ

メッセージ・フローでRESTベースのパイプライン・サービスを定義する場合、操作固有の処理が必要になります。パイプラインにRESTブランチ・ノードを作成する際、消費されるメディア・タイプ、相対URIまたはHTTP動詞に基づく分岐ロジックを構築できます。

RESTブランチ・ノードは、未入力のネイティブRESパイプラインまたは未入力のネイティブRESTテンプレートでのみ使用できます。詳細は、「JDeveloperでのパイプラインへのRESTブランチの追加」および「コンソールでのパイプラインへのRESTブランチの追加方法」を参照してください。

12.3 ステージおよびルート・ノードでのアクションの構成

アクションは、パイプライン・ステージ、エラー・ハンドラ・ステージ、およびルート・ノードでメッセージを処理する手順を提供します。次の項で説明するように、コンテキストによって、使用可能なアクションが決まります。

- 通信アクション

- フロー制御アクション

- メッセージ処理アクション

- レポート・アクション

関連項目

- Oracle Service Busコンソールでのパイプライン・アクションの操作

- Oracle JDeveloperでのパイプライン・アクションの操作

12.3.1 通信アクション

通信アクションは、メッセージ・フローを制御します。各通信アクションを表12-4に示します。

表12-4 通信アクション

アクション

用途

使用できる場所

動的にパブリッシュ

Xquery式で指定されたサービスにメッセージをパブリッシュします。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

パブリッシュ

メッセージの静的に指定されたターゲット・サービスを特定し、メッセージをパッケージ化してそのサービスに送信する方法を構成します。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

パブリッシュ表

ゼロまたはそれ以上の静的に指定されたサービスにメッセージをパブリッシュします。切替え式の条件ロジックを使用して、どのサービスをパブリッシュに使用するか実行時に決定します。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

ルーティング・オプション

アウトバウンド・リクエストのURI、サービスの品質、モード、再試行パラメータ、メッセージの優先度、動詞、相対パス、HTTP Acceptヘッダー、および問合せパラメータの各プロパティの一部またはすべてを変更します。

- ルート・ノード

サービス・コールアウト

Service Busに登録済のプロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合の同期(ブロッキング)コールアウトを構成します。「サービス・コールアウト・メッセージの作成」を参照してください。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

トランスポート・ヘッダー

メッセージのヘッダー値を設定します。「パイプラインでのトランスポート・ヘッダーの構成」を参照してください。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

動的ルーティング

XQueryリソースで使用できるルーティング情報に基づいて、メッセージ・ルートを割り当てます。

- ルート・ノード

ルーティング

そのメッセージのターゲット・サービスを指定し、サービスへのメッセージのルーティング方法を構成します。

- ルート・ノード

ルーティング表

単一のXQuery式の結果に基づいて、異なるルートを選択します。

- ルート・ノード

12.3.2 フロー制御アクション

フロー制御アクションは、条件付きルーティング、条件付きループおよびエラー処理を実装します。また、フロー制御アクションを使用して、呼出し元に成功を通知したり、ステージの残りのアクションをスキップしたりすることもできます。各フロー制御アクションを表12-5に示します。

表12-5 フロー制御アクション

アクション

用途

使用できる場所

For Each

値のシーケンスを反復処理し、アクションのブロックを実行します。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

If... then...

XQuery式またはインラインJavaScript式のブール結果に基づいて、1つのアクションまたは一連のアクションを条件付きで実行します。

- パイプライン・ステージ

- ルート・ノード

- エラー・ハンドラ・ステージ

エラーの生成

指定されたエラー・コード(文字列)と記述を含む例外を発生させます。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

返信

呼出し元に即時返信を送信します。

返信アクションは、リクエスト・パイプライン、レスポンス・パイプライン、またはエラー・パイプラインで使用できます。成功時または失敗時に返信するように構成できます。HTTPインバウンド・トランスポートでの失敗時の返信の場合、返信アクションでは、呼出し元に即時に返信されるように指定します。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

再開

エラー・ハンドラによってエラーが処理された後、メッセージ・フローを再開します。このアクションにパラメータはありません。このアクションは、エラー・ハンドラでのみ使用できます。

- エラー・ハンドラ・ステージ

スキップ

実行時に現在のステージの実行がスキップされ、パイプラインの次のステージに処理を進めます。このアクションにはパラメータがなく、リクエスト・パイプライン、レスポンス・パイプライン、エラー・パイプラインで使用できます。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

12.3.3 メッセージ処理アクション

このカテゴリのアクションは、メッセージ・フローを処理します。各メッセージ処理アクションを表12-6に示します。

表12-6 メッセージ処理アクション

アクション

用途

使用できる場所

割当て

コンテキスト変数にXQuery式またはXSLT式の結果を割り当てます。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

削除

XPath式で指定されたコンテキスト変数または一連のノードを削除します。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

挿入

XPath式で選択したノードを基準として特定された場所にXQuery式またはXSLT式の結果を挿入します。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

Javaコールアウト

パイプラインからJavaメソッドを呼び出します。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

JavaScript

JavaScript式を使用するXMLまたはJSONペイロードのコンテンツを操作します。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

MFL変換

メッセージ・パイプラインで、XMLから非XMLまたは非XMLからXMLにメッセージ・コンテンツを変換します。MFLは、バイナリ・データのレイアウトを記述するために使用する特別なXMLドキュメントです。Oracle独自の言語を使用して、フォーマットされたバイナリ・データをXMLデータに、またはXMLデータをバイナリ・データに変換するルールを定義します。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

nXSD変換

メッセージ・パイプラインで、XMLからネイティブ・フォーマット・データ、またはネイティブ・フォーマット・データからXMLに、メッセージ・コンテンツを変換します。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

名前変更

要素のコンテンツを変更せずに、XPath式で選択した要素の名前を変更します。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

置換

XPath式で指定されたノードまたはノードのコンテンツを置き換えます。ノードまたはそのコンテンツは、XQuery式が返した値で置換されます。

置換アクションでは、単純な値、要素、属性を置き換えることができます。XQuery式から何も返されない状態は、アクションがノード全体を置き換えるか、ノードコンテンツのみを置き換えるかにより、識別されたノードを削除すること、または空のノードを作成することと同じです。

置換アクションは更新アクションのセットの内の1つです。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

検証

XMLスキーマ要素またはWSDLリソースに対して、XPath式で選択した要素を検証します。検証できるのは、グローバル要素のみです。Service Busはローカル要素に対する検証に対応していません。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

12.3.4 レポート・アクション

このカテゴリのアクションを使用して、ステージ内のメッセージ・フローでの必要に応じて、エラーのログ記録またはレポート、およびアラートの生成を行います。各レポート・アクションを表12-7に示します。

表12-7 レポート・アクション

アクション

用途

使用できる場所

アラート

パイプラインのメッセージ・コンテキストに基づいてアラートを生成し、アラート宛先に送信します。SLAアラートと異なり、アラート・アクションで生成された通知は、主にビジネスでの使用、またはエラーの報告を目的とし、システムの状態を監視するものではありません。アラート宛先の構成と選択は、この点を考慮して行う必要があります。

パイプライン・アラートがサービスで有効になっていない場合や、ドメイン・レベルで有効になっている場合は、メッセージを処理するときに構成済のアラート・アクションが省略されます。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

ログ

ログに記録するメッセージを作成し、メッセージをログに記録するときに使用する一連の属性を定義します。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

レポート

パイプラインのメッセージ・レポートを有効にします。XQuery/XSLTまたはJavaScriptの式は、Service Busダッシュボードに報告するデータの作成に使用されます。キー値のペアは、メッセージ・コンテキスト変数やメッセージ・ペイロードからキー識別子を抽出して、残りのメッセージを無視する場合に使用します。

- パイプライン・ステージ

- エラー・ハンドラ・ステージ

- ルート・ノード

12.3.5 パイプラインでのトランスポート・ヘッダーの構成

トランスポート・ヘッダー・アクションは、通信タイプのアクションです。このアクションは、パイプライン・ステージとエラー・ハンドラ・ステージで使用できます。

12.3.5.1 グローバル・パススルー・オプションとヘッダー固有のコピー・オプション

トランスポート・ヘッダー・アクションを構成するときに、次のオプションを使用できます。

- 「パイプラインを介してすべてのヘッダーを渡す」オプションは、実行時にトランスポート・ヘッダー・アクションによって、インバウンド・メッセージからアウトバウンド・メッセージまたはアウトバウンド・メッセージからインバウンド・メッセージにすべてのヘッダーをパススルーすることを示します。ソース・ヘッダー・セットのすべてのヘッダーはターゲット・ヘッダー・セットにコピーされ、ターゲット・ヘッダー・セットの既存の値はすべて上書きされます。

- 「インバウンド・リクエストからヘッダーをコピー」オプションと「アウトバウンド・レスポンスからヘッダーをコピー」オプションは、実行時にトランスポート・ヘッダー・アクションによって、このオプションが関連付けられている特定のヘッダーをインバウンド・メッセージからアウトバウンド・メッセージまたはアウトバウンド・メッセージからインバウンド・メッセージにコピーすることを示します。

これらのオプションは、シナリオに合せて使用します。どちらのオプションを使用しても、ソース・ヘッダー・セットのヘッダーがターゲット・ヘッダー・セットにコピーされ、ターゲット・セットの既存の値はすべて上書きされます。「パイプラインを介してすべてのヘッダーを渡す」オプションは、ヘッダー固有のヘッダーをコピー・オプションの前に実行されます。つまり、特定のトランスポート・ヘッダー・アクションの構成で、「パイプラインを介してすべてのヘッダーを渡す」を選択した場合、特定のヘッダーに対してヘッダーをコピー・オプションを選択する必要はありません。

ただし、「パイプラインを介してすべてのヘッダーを渡す」を選択してすべてのヘッダーをコピーし、その後特定のヘッダーに対して「ヘッダーの削除」を選択して、個々のヘッダーを削除するようにアクションを構成できます。

警告:

トランスポート・ヘッダーはトランスポート・タイプに固有であるため、パススルー(またはコピー)オプションは、同じトランスポート・タイプのサービス間でヘッダーをコピーする場合にのみ使用することをお薦めします。トランスポート・タイプが異なるサービス間でヘッダーを渡す(またはコピーする)と、渡されるヘッダーがターゲットのトランスポートで受け入れられない場合にエラーが発生することがあります。同じ理由で、「ヘッダーを設定」オプションを使用してヘッダー名を指定するときにも注意が必要です。

12.3.5.2 ランタイムによってトランスポート・ヘッダーの設定が使用される仕組み

トランスポート・ヘッダー・アクションを使用して、アウトバウンド・リクエスト(ルート、パブリッシュ、またはサービス・コールアウトの各アクションでプロキシ・サービスが送信するメッセージ)とインバウンド・レスポンス(プロキシ・サービスがクライアントに返信するレスポンス・メッセージ)のトランスポート・ヘッダーの値を構成できます。通常、ヘッダー値に対して次の操作を実行できます。

- XQuery式を使用して指定します。

- ソースからターゲット・サービスにパススルーします。

- ソースからターゲット・サービスへの移動時に削除します。

トランスポート・ヘッダー・アクションを使用すると、$inboundまたは$outboundのヘッダーを設定、削除、またはパススルーできます。これらのヘッダーを設定または削除した後に、$inboundまたは$outboundをログに書き込むと、変更の影響を確認できます。ただし、メッセージが送信されるときにService Busバインディング・レイヤーによって$inboundまたは$outboundの一部のヘッダーが変更または削除され、そのため基礎になるトランスポートでこれらのヘッダーの一部が無視されて、固有の値が使用されることがあります。重要な違いは、バインディング・レイヤーによるヘッダーの変更は$inboundおよび$outboundに対して直接行われますが、トランスポートによる変更はメッセージのワイヤ形式だけに影響するという点です。たとえば、アウトバウンドのContent-Lengthヘッダーの値を指定することはできますが、メッセージの送信時に、この値はバインディング・レイヤーによって$outboundから削除されます。したがって、この変更はレスポンス・パスで確認できます(たとえば、$outboundをログに記録すると、変更された値を確認できます)。$outboundにUser-Agentヘッダーを設定した場合、HTTPトランスポートではこの設定が無視され、トランスポート独自の値が使用されます。ただし、$outboundの値が変更されることはありません。

「トランスポート・ヘッダー・アクションで指定するトランスポート・ヘッダーの値の制限」では、実行時に無視または上書きされるトランスポート・ヘッダーと、特定のトランスポート・ヘッダーに関するその他の制限を示します。

12.3.5.3 トランスポート・ヘッダー・アクションで指定するトランスポート・ヘッダーの値の制限

表12-8に、実行時に無視または上書きされるトランスポート・ヘッダーと、特定のトランスポート・ヘッダーに関するその他の制限を示します。

表12-8 トランスポート・ヘッダー・アクションで指定するトランスポート・ヘッダーの値の制限

トランスポート

制限の説明

アウトバウンド・リクエスト・ヘッダー

インバウンド・レスポンス・ヘッダー

HTTP

Service Busランタイムは、メッセージのディスパッチ準備中にバインディング・レイヤーでこれらのヘッダーを上書きする場合があります。これらのヘッダーが変更された場合、それに応じて$inboundと$outboundが更新されます。

Content-Type

Content-Type

HTTP

メッセージの送信時に、基になるトランスポートでこれらのヘッダーが無視され、別の値が使用される場合があります。トランスポートによって行われた変更は、$inboundまたは$outboundには反映されません。

- 承認

- Content-Length

- Connection

- Host

- User-Agent

- Content-Length

- Date

- Transfer-Encoding

JMS

リクエストが一方向のサービスまたはJMSMessageID相関に基づくリクエスト/レスポンス・サービスに関連する場合にのみ設定できます。

JMSCorrelationID相関に基づくリクエスト/レスポンス・サービスに送信する場合、これらのヘッダーは実行時に上書きされます。

JMSCorrelationID

JMSCorrelationID

JMS

Service Busランタイムはこれらのヘッダーを設定します。つまり、設計時にこれらのヘッダーに対して行った指定内容は実行時に上書きされます。

注意: JMS_IBMという接頭辞の付いたヘッダー名は、IBM MQサーバーがホストする宛先に関連して使用されます。

- JMSMessageID

- JMSRedelivered

- JMSTimestamp

- JMSXDeliveryCount

- JMSXUserID

- JMS_IBM_PutDate

- JMS_IBM_PutTime
JMS_IBM_PutApplType

- JMS_IBM_Encoding

- JMS_IBM_Character_Set

- JMSMessageID

- JMSRedelivered

- JMSTimestamp

- JMSXDeliveryCount

- JMSXUserID

- JMS_IBM_PutDate

- JMS_IBM_PutTime

- JMS_IBM_PutApplType

- JMS_IBM_Encoding

- JMS_IBM_Character_Set

JMS

IBM MQではクライアント・アプリケーションで一部のプロパティを設定できないため、IBM MQ宛先に関連するこれらのヘッダーを設定すると、実行時例外が発生します。

- JMSXDeliveryCount

- JMSXUserID

- JMSXAppID

- JMSXDeliveryCount

- JMSXUserID

- JMSXAppID

JMS

「パイプラインを介してすべてのヘッダーを渡す」オプションも指定されている場合、これらのヘッダーを削除することはできません。

- JMSDeliveryMode

- JMSExpiration

- JMSMessageID

- JMSRedelivered

- JMSTimestamp

- JMSXDeliveryCount

- JMSDeliveryMode

- JMSExpiration

- JMSMessageID

- JMSRedelivered

- JMSTimestamp

- JMSXDeliveryCount

- JMSCorelationID - インバウンド・メッセージに相関IDが設定されている場合。たとえば、登録済のJMSビジネス・サービスからのインバウンド・レスポンスの場合など。

FTPおよびファイル

制限はありません。つまり、ユーザーはファイル・トランスポートおよびFTPトランスポートのヘッダーを設定または削除でき、ユーザーによる指定はService Busランタイムで優先されます。

注意: FTPプロキシとファイル・プロキシには、fileNameというトランスポート・リクエスト・ヘッダーがあります。このリクエスト・ヘッダーの値は、ポーリング対象となるファイルの名前です。

N/A

N/A

電子メール

Service Busランタイムはこれらのヘッダーを設定します。つまり、設計時にこれらのヘッダーに対して行った指定内容は実行時に上書きされます。

Content-Type

Content-Type

電子メール

Service Busはアウトバウンド・リクエストでこれらのヘッダーを使用しません。これらを動的に設定すると(つまり、これらを$outboundヘッダー・セクションに設定する場合)、Service Busはこれらを無視します。

これらのヘッダーは$inboundで受信されます。Dateは、送信者が電子メールを送信した日時です。Fromは、受信電子メール・ヘッダーから取得されます。

- From(名前)

- Date

N/A

注意:

inboundコンテキスト変数とoutboundコンテキスト変数を設定する場合や、Service Bus Test Consoleを使用してプロキシ・サービスまたはビジネス・サービスをテストする場合は、トランスポート・ヘッダーとメタデータの設定のときと同じ制限が適用されます。

12.4 パイプラインでのトランスフォーメーションの実行

トランスフォーメーション・マップは、2つのデータ型の間のマッピングを記述したものです。Service Busは、XQueryおよびeXtensible Stylesheet Language Transformation (XSLT)標準を使用したデータ・マッピングに対応しています。XSLTマップでは、XMLからXMLへのマッピングを記述します。XQueryマップでは、XMLからXML、XMLから非XML、および非XMLからXMLへの各マッピングを記述できます。

パイプライン内にトランスフォーメーションを指定する位置は、次の条件によって異なります。

- メッセージ・フォーマットがターゲット・サービスに依存する場合。つまり、メッセージ・フォーマットが、ルートの宛先で受け入れられるフォーマットであることが必要な場合です。これに該当するのは、トランスフォーメーションがルート・ノードまたはパブリッシュ・アクションの1つで実行されるときです。
パブリッシュ・アクションで、メッセージのターゲット・サービスを判別し、メッセージのパッケージおよびサービスへの送信方法を構成します。Service Busには、パブリッシュ表アクションも用意されています。パブリッシュ表アクションは、切替え式条件表にラップされた一連のルートで構成されます。これは、単一のXQuery式の結果に基づいて各種ルートを選択できる短縮形の構文です。

- ルートの宛先に関係なく、リクエストまたはレスポンス・メッセージに対してトランスフォーメーションを実行するかどうか。この場合、リクエストまたはレスポンス・パイプライン・ステージでトランスフォーメーションを構成できます。

12.4.1 トランスフォーメーションとパブリッシュ・アクション

トランスフォーメーションをパブリッシュ・アクション内に設計した場合、トランスフォーメーションは$outbound変数およびメッセージ関連の変数($header、$bodyおよび$attachments)のローカル・コピーを保持します。パブリッシュ・アクションでアウトバウンド・メッセージに行った変更は、パブリッシュされるメッセージにのみ反映されます。つまり、パブリッシュ・アクションで行った変更は、メッセージ・フローがパイプラインのその次のアクションに進む前にロールバックされます。

たとえば、メッセージ・フローで大口の発注書を処理するときに、管理者宛てに発注書の要約を電子メールで送信する必要がある場合について考えます。このような場合、リクエスト・パイプラインにパブリッシュ・アクションを含めると、着信メッセージのSOAP本体に発注書の要約が作成されます。パブリッシュ・アクションでは、発注書データが発注書の要約に変換されます。たとえば、発注書の要約には添付ファイルは必要ないため、$attachmentsのすべての添付ファイルを削除できます。パブリッシュ・アクションの後は、次の項で説明するように、パブリッシュ・アクションより前の状態のメッセージがそのメッセージ・フローを通じて維持されます。

12.4.1.1 サービス品質におけるパブリッシュ・アクションの動作

この項では、様々なサービス品質(QoS)設定におけるパブリッシュ・アクションの動作を説明します。

必ず1回 - QoSが必ず1回の場合、パブリッシュ・アクションはターゲット・サービスからのレスポンスがあるまで待機します(ブロッキング・コール)。ターゲットがビジネス・サービスの場合、パブリッシュ・アクションはビジネス・サービス・レスポンスがあるまで待機します。ターゲットがプロキシ・サービスの場合、パブリッシュ・アクションはプロキシ・サービスのレスポンス・パイプラインが完了するまで待機します。

ベスト・エフォート - QoSがベスト・エフォートで、ターゲット・サービスが一方向プロキシ・サービスまたは一方向ビジネス・サービスの場合で再試行回数が1回以上に設定されていると、パブリッシュ・アクションはターゲット・サービスが返されるまで待機します。一方向のターゲット・サービスではレスポンスがありませんが、プブリッシュ・アクションはリクエストが配信されるまで待機します。

ターゲット・プロキシまたはビジネス・サービスがリクエスト-レスポンスまたは一方向ビジネス・サービスの場合で、再試行回数が0に設定されていると、パブリッシュ・アクションはレスポンスを待機しません(ノンブロッキング・コール)。

12.4.2 トランスフォーメーションとルート・ノード

WS-Addressingヘッダーに基づく2つの宛先の一方にメッセージをルーティングする必要があるとします。この場合、コンテンツ・ベースのルーティングです。また、もう一方の宛先では、SOAP本体のドキュメントの新しいバージョンが必要であるとします。このような場合、条件に基づいて2つの宛先の一方にルーティングされるように、ルート・ノードを構成できます。2つ目の宛先のためにドキュメントを変換するように、ルート・ノードでトランスフォーメーションを構成します。

アウトバウンド・コンテキスト変数($outbound)の制御要素を設定して、アウトバウンド・メッセージに関するシステムの動作を調整することもできます(たとえば、サービスの品質を設定できます)。

inbound変数とoutbound変数の下位要素、およびメッセージ・コンテキストの変数の値を使用してメッセージのコンテンツが作成される仕組みについては、「inbound変数とoutbound変数」および「ディスパッチするメッセージの作成」を参照してください。

関連項目

- メッセージ・コンテキスト

- 「XQueryでのデータの変換」および「XSLTでのデータの変換」

12.5 サービス・コールアウト・メッセージの作成

Service Busがサービス・コールアウト・アクションを通じてサービスをコールする場合は、メッセージ・コンテキストの変数の値を使用してメッセージのコンテンツが作成されます。アウトバウンド・メッセージのメッセージ・コンテンツは、ターゲット・サービスの種類に応じて異なって処理されます。

次のトピックで説明するように、メッセージ・コンテンツの作成方法は、ターゲット・サービスのタイプ、およびSOAP本体とペイロード(パラメータまたはドキュメント)のどちらを構成するかによって異なります。

- SOAPドキュメント・スタイルのサービス

- SOAP RPCスタイルのサービス

- XMLサービス

- メッセージング・サービス

12.5.1 SOAPドキュメント・スタイルのサービス

次のようなSOAPドキュメント・スタイルのサービス(EJBドキュメントおよびドキュメントにラップされたサービスを含む)のメッセージを作成できます。

- リクエスト・ドキュメントが割り当てられた変数にはSOAP本文が含まれます。

- SOAPリクエスト・ヘッダーに割り当てられた変数にはSOAPヘッダーが含まれます。

- レスポンスは単一のXMLドキュメント(SOAP本体のコンテンツとSOAPヘッダー(指定されている場合))である必要があります。

SOAPドキュメント・スタイルのサービスへのコールアウト時にメッセージが作成されるしくみを説明するために、次のように構成されたサービス・コールアウト・アクションについて考えてみます。

- リクエスト・ドキュメント変数: myreq

- レスポンス・ドキュメント変数: myresp

- SOAPリクエスト・ヘッダー: reqheader

- SOAPレスポンス・ヘッダー: respheader

また、実行時にリクエスト・ドキュメント変数myreqが次のXMLにバインドされていることを前提とします。

例 - リクエスト変数(myreq)のコンテンツ

<sayHello xmlns="http://www.openuri.org/">
<intVal>100</intVal>
<string>Hello Oracle</string>
</sayHello>

実行時に、SOAPリクエスト・ヘッダー変数reqheaderは、次のSOAPヘッダーにバインドされます。

例 - SOAPリクエスト・ヘッダー変数(reqheader)のコンテンツ

<soap:Header xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
<wsa:Action>...</wsa:Action>
<wsa:To>...</wsa:To>
<wsa:From>...</wsa:From>
<wsa:ReplyTo>...</wsa:ReplyTo>
<wsa:FaultTo>...</wsa:FaultTo>
</soap:Header>

このシナリオ例では、外部サービスに送信されるメッセージの本文全体は次の例のようになります(myreq変数とreqheader変数のコンテンツは太字で示しています)。

例 - サービス・コールアウト・アクションの結果としてサービスに送信されるメッセージ

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
<wsa:Action>...</wsa:Action>
<wsa:To>...</wsa:To>
<wsa:From>...</wsa:From>
<wsa:ReplyTo>...</wsa:ReplyTo>
<wsa:FaultTo>...</wsa:FaultTo>
</soap:Header>
<soapenv:Body>
<sayHello xmlns="http://www.openuri.org/">
<intVal>100</intVal>
<string>Hello Oracle</string>
</sayHello>
</soapenv:Body>
</soapenv:Envelope>

前述のサービス・コールアウト・アクションの構成に基づいて、サービスからのレスポンスがmyresp変数に割り当てられます。外部サービスからのレスポンス全体が次の例で示されています。

例 - サービス・コールアウト・アクションの結果としてサービスから送信されるレスポンス・メッセージ

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc="http://schemas.xmlsoap.
org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<env:Header/>
<env:Body env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<m:sayHelloResponse xmlns:m="http://www.openuri.org/">
<result xsi:type="xsd:string">This message brought to you by Hello Oracle and the number 100
</result>
</m:sayHelloResponse>
</env:Body>
</env:Envelope>

このシナリオでは、myresp変数に次の例に示す値が割り当てられます。

例 - サービス・コールアウト・アクションの結果であるレスポンス変数(myresp)のコンテンツ

<m:sayHelloResponse xmlns:m="http://www.openuri.org/">
<result ns0:type="xsd:string" xmlns:ns0="http://www.w3.org/2001/XMLSchema-instance">
This message brought to you by Hello Oracle and the number 100
</result>
</m:sayHelloResponse>

12.5.2 SOAP RPCスタイルのサービス

次のようなSOAP RPCスタイルのサービス(EJB RPCサービスを含む)のメッセージを作成できます。

- リクエスト・メッセージは、メッセージ・コンテキスト変数からアセンブルされます。

- SOAP本体は、SOAP RPC形式(操作ラッパー、パラメータ・ラッパーなど)に基づいて作成されます。

- SOAPヘッダーは、SOAPリクエスト・ヘッダーに指定された変数のコンテンツです(変数が指定されている場合)。

- partを要素として使用 - パラメータ値は変数のコンテンツです。

- partを単純型として使用 - パラメータ値は変数のコンテンツの文字列表現です。

- partを複合型として使用 - パラメータは、パラメータ名の後にある変数のコンテンツのルートの名前変更に対応します。

- レスポンス・メッセージは、次のようにアセンブルされます。

- 出力コンテンツはSOAPヘッダーのコンテンツです(SOAPヘッダーが指定されている場合)。

- partを要素として使用 - 出力コンテンツはパラメータの子要素です。子要素は1つだけです。

- partを単純型/複合型として使用 - 出力コンテンツはパラメータ自体です。

SOAP RPCスタイルのサービスへのコールアウト時にメッセージが作成されるしくみを説明するために、次のように構成された例について考えてみます。

- メッセージ・コンテキスト変数input1は値100にバインドされています。

- メッセージ・コンテキスト変数input2は文字列値Hello Oracleにバインドされています。

- サービス・コールアウト・アクションが次のように構成されています。

- リクエスト・パラメータ intval: input1

- リクエスト・パラメータ string: input2

- レスポンス・パラメータ result: output1

このシナリオでは、サービスへのアウトバウンド・メッセージの本文は次の例のようになります。

例 - アウトバウンド・メッセージのコンテンツ

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<sayHello2 xmlns="http://www.openuri.org/">
<intVal>100</intVal>
<string >Hello Oracle</string>
</sayHello2>
</soapenv:Body>
</soapenv:Envelope>

次の例では、コールが作成されたサービスによって返されるレスポンスを示します。

例 - helloWorldサービスからのレスポンス・メッセージのコンテンツ

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<env:Header/>
<env:Body env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<m:sayHello2Response xmlns:m="http://www.openuri.org/">
<result xsi:type="n1:HelloWorldResult" xmlns:n1="java:">
<message xsi:type="xsd:string">
This message brought to you by Hello Oracle and the number 100
</message>
</result>
</m:sayHello2Response>
</env:Body>
</env:Envelope>

メッセージ・コンテキスト変数output1には、次の例に示す値が割り当てられます。

例 - 出力変数(output1)のコンテンツ

<message ns0:type="xsd:string" xmlns:ns0="http://www.w3.org/2001/XMLSchema-intance">
This message brought to you by Hello Oracle and the number 100</message>

12.5.3 XMLサービス

次のようなXMLサービスのメッセージを作成できます。

- リクエスト・メッセージは、リクエスト・ドキュメントが割り当てられた変数のコンテンツです。

- リクエスト変数のコンテンツは、単一のXMLドキュメントである必要があります。

- 出力ドキュメントは、レスポンス・メッセージです。

XMLサービスへのコールアウト時にメッセージが作成されるしくみを説明するために、次のように構成されたサービス・コールアウト・アクションを例にとります。

- リクエスト・ドキュメント変数: myreq

- レスポンス・ドキュメント変数: myresp

また、実行時にリクエスト・ドキュメント変数myreqが次のXMLにバインドされていることを前提とします。

例 - myreq変数のコンテンツ

<sayHello xmlns="http://www.openuri.org/">
<intVal>100</intVal>
<string>Hello Oracle</string>
</sayHello>

このシナリオでは、次のようになります。

- 前述の例に示すように、アウトバウンド・メッセージ・ペイロードはmyreq変数の値です。

- レスポンスおよびメッセージ・コンテキスト変数myrespに割り当てられる値は、次の例のようになります。

例 - myresp変数のコンテンツ

<m:sayHelloResponse xmlns:m="http://www.openuri.org/">
<result xsi:type="xsd:string">This message brought to you by Hello Oracle and the number 100
</result>
</m:sayHelloResponse>

12.5.4 メッセージング・サービス

メッセージング・サービスの場合の特徴は次のとおりです。

- リクエスト・メッセージはリクエスト変数のコンテンツです。コンテンツには単純なテキスト、XML、または<binary-content ref=.../>参照XMLのインスタンスによって表されるバイナリ・データを使用できます。

- レスポンス・メッセージはバイナリとして扱われるため、実際にどのようなコンテンツを受信したかにかかわらず、レスポンス変数には<binary-content ref= ... />参照XMLのインスタンスが格納されます。

たとえば、リクエスト・メッセージのコンテキスト変数myreqが<hello>there</hello>という形式のXMLドキュメントにバインドされる場合、アウトバウンド・メッセージには厳密にこのペイロードが格納されます。レスポンス・メッセージのコンテキスト変数(myresp)は、次のような参照要素にバインドされます。

<binary-content ref=" cid:1850733759955566502-2ca29e5c.1079b180f61.-7fd8"/>

12.6 サービス・コールアウト・メッセージでの添付ファイルの使用

アウトバウンド・リクエストの添付ファイルを保持するオプションの変数と、アウトバウンド・レスポンスからの添付ファイルを保持する別の変数を指定できます。リクエスト添付ファイル変数とレスポンス添付ファイル変数を使用して、リクエスト添付ファイルとレスポンス添付ファイルをそれぞれ指定します。

リクエスト・メッセージ、レスポンス・メッセージあるいはその両方の添付ファイルを指定できます。次のコードは、リクエスト添付ファイル変数とレスポンス添付ファイル変数のスキーマ・タイプを示しています。

<!-- The schema type for  -->
<complexType name="AttachmentsType">
<sequence>
<!-- the 'attachments' variable is just a series of attachment elements -->
<element ref="mc:attachment" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<!-- Each attachment in the 'attachments' variable is represented by an instance of this element -->
<element name="attachment" type="mc:AttachmentType"/>
<complexType name="AttachmentType">
<all>
<!-- Set of MIME headers associated with attachment -->
<element name="Content-ID" type="string" minOccurs="0"/>
<element name="Content-Type" type="string" minOccurs="0"/>
<element name="Content-Transfer-Encoding" type="string" minOccurs="0"/>
<element name="Content-Description" type="string" minOccurs="0"/>
<element name="Content-Location" type="string" minOccurs="0"/>
<element name="Content-Disposition" type="string" minOccurs="0"/>
<!-- Contains the attachment content itself, either in-lined or as <binary-content/> -->
<element name="body" type="anyType"/>
</all>
</complexType>

リクエスト添付ファイル変数とレスポンス添付ファイル変数は、ターゲット・サービスのバインディング・タイプやトランスポート・タイプに関係なく使用できます。

12.6.1 SOAPドキュメント・スタイル・サービスでの添付ファイルの使用例

次の例では、SOAPドキュメント・スタイルJWSを使用したWLS Webサービスの例を示します。Webサービスには、入力引数をその戻り値として返す単一メソッドがあります。入力引数と戻り値は、添付ファイルとして送受信されます。

例 - サンプルSOAPドキュメント・スタイルJWS

import javax.activation.DataHandler;

@WebService(name="AttachmentsService", targetNamespace="http://example.org")
@Binding(Binding.Type.SOAP12)
@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
use=SOAPBinding.Use.LITERAL,
parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)

@WLHttpTransport(contextPath="testAttachments", serviceUri="AttachmentsService")
public class AttachmentsServiceImpl
{
@WebMethod(action="echoAttachmentAction")
public DataHandler echoAttachment(DataHandler dh)
{
return dh;
}
}

次の例では、前述のSOAPドキュメント・スタイルJWSの例のWebサービスに対応するWSDLドキュメントを示します。

例 - Webサービスに対応するWSDLドキュメント

<wsdl:definitions name="AttachmentsServiceImplServiceDefinitions"
targetNamespace="http://example.org"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:exam="http://example.org"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
<wsdl:types>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"
targetNamespace="http://example.org" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="http://www.bea.com/servers/wls90/wsee/attachment"/>
<xs:element name="echoAttachment">
<xs:complexType>
<xs:sequence>
<xs:element name="dh" type="att:datahandler"
xmlns:att="http://www.bea.com/servers/wls90/wsee/attachment"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="echoAttachmentResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="return" type="att:datahandler"
xmlns:att="http://www.bea.com/servers/wls90/wsee/attachment"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:schema targetNamespace="http://www.bea.com/servers/wls90/wsee/attachment"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="datahandler">
<xs:annotation>
<xs:documentation>Internal type created by WebLogic - Do not
edit!</xs:documentation>
</xs:annotation>
</xs:complexType>
</xs:schema>
</wsdl:types>
<wsdl:message name="echoAttachment">
<wsdl:part element="exam:echoAttachment" name="parameters"/>
</wsdl:message>
<wsdl:message name="echoAttachmentResponse">
<wsdl:part element="exam:echoAttachmentResponse" name="parameters"/>
</wsdl:message>
<wsdl:portType name="AttachmentsService">
<wsdl:operation name="echoAttachment" parameterOrder="parameters">
<wsdl:input message="exam:echoAttachment"/>
<wsdl:output message="exam:echoAttachmentResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="AttachmentsServiceImplServiceSoapBinding"
type="exam:AttachmentsService">
<soap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="echoAttachment">
<soap12:operation soapAction="echoAttachmentAction" style="document"/>
<wsdl:input>
<soap12:body parts="parameters" use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body parts="parameters" use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="AttachmentsServiceImplService">
<wsdl:port binding="exam:AttachmentsServiceImplServiceSoapBinding"
name="AttachmentsServiceSoapPort">
<soap12:address
location="http://adc4110062:7001/testAttachments/AttachmentsService"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

次に、前述のWSDLファイルがService Busに登録され、ビジネス・サービスがこのWSDL SOAPポートに登録されます。サービス・コールアウト・アクションは次のように構成されます。

- リクエスト・ドキュメント変数: reqDoc

- レスポンス・ドキュメント変数: respDoc

- リクエスト添付ファイル変数: reqatt

- レスポンス添付ファイル変数: respatt

サービス・コールアウト・アクションの追加と構成の詳細は、「コンソールでのサービス・コールアウト・アクションの追加」を参照してください。

次の例では、サービス・コールアウト処理が起動された際のリクエスト・ドキュメントの値およびリクエスト添付コンテキスト変数を示します。

例 - サービス・コールアウト呼出し時のリクエスト・ドキュメント変数(reqDoc)の値

<m:echoAttachment xmlns:m="http://example.org">
<m:dh href="cid:dh"/>
</m:echoAttachment>

例 - サービス・コールアウト呼出し時のリクエスト添付ファイル変数(reqatt)の値

<con:attachments xmlns:con="http://www.bea.com/wli/sb/context">
<con:attachment>
<con:Content-Type>image/jpeg</con:Content-Type>
<con:Content-ID><dh></con:Content-ID>
<con:body>
<con:binary-content ref="cid:-6175a307:131072c66ef:-7f56"/>
</con:body>
</con:attachment>
</con:attachments>

前述の例では、添付ファイルの本文は、ソース・リポジトリに格納されるソースを指し示すバイナリ・コンテンツ参照を使用します。これは、JavaコールアウトやMFL変換などの結果になります。

注意:

SOAPエンベロープのhref値が、添付ファイル・パートのContent-IDヘッダーに一致することを確認します。これにより、メッセージの本文と対応する添付ファイルがリンクされます。値が一致しない場合、JWS呼出しからSOAPフォルトを受信する場合があります。

次の例は、サービス・コールアウト・アクションのサンプル・アウトバウンド・ペイロードを示しています。

例 - サービス・コールアウトのアウトバウンド・ペイロード

POST http://localhost:7001/default/test1

Content-Type: multipart/related;boundary="----=_Part_0
_39288954.1310192119320";type="text/xml";start="<soapPart>"

------=_Part_0_39288954.1310192119320
Content-Type: application/soap+xml; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-ID: <soapPart>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header/>
<env:Body>
<m:echoAttachment xmlns:m="http://example.org">
<m:dh href="cid:dh"/>
</m:echoAttachment>
</env:Body>
</env:Envelope>

------=_Part_0_39288954.1310192119320
Content-Type: image/jpeg
Content-ID: <dh>

... binary content of some JPG file ….
------=_Part_0_39288954.1310192119320--

次の例では、サービス呼出しに対するJWSレスポンスを示します。

例 - Java Webサービス(JWS)のレスポンス

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: multipart/related;boundary="----=_Part_13
_1460020940.1310334461289";type="text/xml";start="<soapPart>"
------=_Part_13_1460020940.1310334461289
Content-Type: application/soap+xml; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-ID: <soapPart>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
<m:echoAttachmentResponse xmlns:m="http://example.org">
<return xmlns="http://example.org" href="cid:return"/>
</m:echoAttachmentResponse>
</env:Body>
</env:Envelope>

------=_Part_13_1460020940.1310334461289
Content-Type: image/jpeg
Content-ID: <return>

…. binary content of some JPG file …
------=_Part_13_1460020940.1310334461289--

次の例では、サービス・コールアウト・レスポンスのコンテキスト変数の値を示します。

例 - レスポンス・ドキュメント変数(respDoc)の値

<m:echoAttachmentResponse xmlns:m="http://example.org">
<return xmlns="http://example.org" href="cid:return"/>
</m:echoAttachmentResponse>

例 - レスポンス添付ファイル変数(respatt)の値

<con:attachments xmlns:con="http://www.bea.com/wli/sb/context">
<con:attachment>
<con:Content-Type>image/jpeg</con:Content-Type>
<con:Content-ID><return></con:Content-ID>
<con:body>
<con:binary-content ref="cid:-6175a307:131072c66ef:-7f57"/>
</con:body>
</con:attachment>
</con:attachments>

12.6.2 SOAP RPCスタイル・サービスでの添付ファイルの使用例

次に、SOAP RPCスタイルWSDLファイルの例を示します。WSDLファイルは、ビジネス・サービスとしてService Busに登録されます。サービス・コールアウト・アクションを使用して、このビジネス・サービスを呼び出します。

例 - ビジネス・サービスのWSDLドキュメント

<?xml version="1.0"?>
<wsdl:definitions xmlns:types="http://example.com/mimetypes"
xmlns:ref="http://ws-i.org/profiles/basic/1.1/xsd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://example.com/mimewsdl"
xmlns:tns="http://example.com/mimewsdl">

<wsdl:types>
<xsd:schema targetNamespace="http://example.com/mimetypes"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:import namespace="http://ws-i.org/profiles/basic/1.1/xsd" />
<xsd:complexType name="ClaimDetailType">
<xsd:sequence>
<xsd:element name="Name" type="xsd:string"/>
<xsd:element name="ClaimForm" type="ref:swaRef"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
</wsdl:types>

<wsdl:message name="ClaimIn">
<wsdl:part name="ClaimDetail" type="types:ClaimDetailType"/>
<wsdl:part name="ClaimPhoto" type="xsd:base64Binary"/>
</wsdl:message>

<wsdl:message name="ClaimOut">
<wsdl:part name="ClaimRefNo" type="xsd:string"/>
</wsdl:message>

<wsdl:portType name="ClaimPortType">
<wsdl:operation name="SendClaim">
<wsdl:input message="tns:ClaimIn"/>
<wsdl:output message="tns:ClaimOut"/>
</wsdl:operation>
</wsdl:portType>

<wsdl:binding name="ClaimBinding" type="tns:ClaimPortType">
<soapbind:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="SendClaim">
<soapbind:operation soapAction="http://example.com/soapaction"/>
<wsdl:input>
<mime:multipartRelated>
<mime:part>
<soapbind:body use="literal"
parts="ClaimDetail"
namespace="http://example.com/mimetypes"/>
</mime:part>
<mime:part>
<mime:content part="ClaimPhoto"
type="image/jpeg"/>
</mime:part>
</mime:multipartRelated>
</wsdl:input>
<wsdl:output>
<soapbind:body use="literal"
namespace="http://example.com/mimetypes"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>

サービス・コールアウト・アクションは次のように構成されます。

- リクエスト・パラメータ: claimDetail

- レスポンス・パラメータ: claimRefNo

- リクエスト添付ファイル変数: reqatt

- レスポンス添付ファイル変数: respatt

サービス・コールアウト・アクションの追加と構成の詳細は、「コンソールでのサービス・コールアウト・アクションの追加」および「JDeveloperでのサービス・コールアウト・アクションの追加」を参照してください。

次の例では、サービス・コールアウトが呼び出されたときのメッセージ・コンテキスト変数の値を示します。

例 - リクエスト・パラメータ(claimDetail)の値

<ClaimDetail xmlns=" http://example.com/mimetypes">
<Name>...</Name>
<ClaimForm>cid:claimform@example.com</ClaimForm>
</ClaimDetail>

例 - リクエスト添付ファイル変数(reqatt)の値

<con:attachments xmlns:con="http://www.bea.com/wli/sb/context">
<con:attachment>
<con:Content-Type>text/xml</con:Content-Type>
<con:Content-ID><claimform@example.com></con:Content-ID>
<con:body>
<form>...XML contents of claim form referenced by the swaRef... </form>
</con:body>
</con:attachment>
<con:attachment>
<con:Content-Type>image/jpeg</con:Content-Type>
<con:Content-ID><ClaimPhoto=4d7a5fa2-14af-451c-961b-5c3abf786796@example.com></con:Content-ID>
<con:body>
<con:binary-content ref="cid:-6175a307:131072c66ef:-7f58"/>
</con:body>
</con:attachment>
</con:attachments>

次に、アウトバウンド・リクエストの例を示します。

例 - サンプル・アウトバウンド・リクエスト

Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
start="<rootpart@example.com>"

--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <rootpart@example.com>

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body xmlns:types="http://example.com/mimetypes">
<types:SendClaim>
<ClaimDetail>
<Name>...</Name>
<ClaimForm>cid:claimform@example.com</ClaimForm>
</ClaimDetail>
</types:SendClaim>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--MIME_boundary
Content-Type: text/xml
Content-Transfer-Encoding: 8bit
Content-ID: <claimform@example.com>

...claim form referenced by the swaRef...

--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <ClaimPhoto=4d7a5fa2-14af-451c-961b-5c3abf786796@example.com>

...MIME attachment of binary photograph...
--MIME_boundary--

次に、レスポンスの例を示します。

例 - サンプル・レスポンス

Content-Type: text/xml; charset=UTF-8

<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body xmlns:types="http://example.com/mimetypes">
<types:SendClaimResponse>
<ClaimRefNo>.............................</ClaimRefNo>
</types:SendClaimResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

レスポンスに対応するメッセージ・コンテキスト変数(claimRefNoおよびrespatt)が設定されます。次の例はrespatt変数の値を示しています。

例 - レスポンス添付ファイル変数(respatt)の値

<con:attachments xmlns:con=http://www.bea.com/wli/sb/context />

12.6.3 MTOM/XOPサポート

サービス・コールアウトでSOAP Message Transmission Optimization Mechanism (MTOM)を使用できます。MTOMは、XML-binary Optimized Packaging (XOP)を使用してバイナリ・データを転送します。

ただし、MTOMと添付ファイルを混ぜ合せることはできません。ターゲット・サービスがMTOMに対応し、アウトバウンド・リクエストに添付ファイルがある場合、次のエラーが発生します。

XOP/MTOMと添付ファイルの混在は許可されません。

ターゲット・サービスでMTOMが有効な場合、添付ファイル変数は構成しないでください。

12.6.4 添付ファイルのディスクへのページング

サービス・コールアウトでは、ディスクへの添付ファイルのページングがサポートされます。アウトバウンド・リクエストで以前にページングされた添付ファイルのコンテンツを使用できます。

サービス・コールアウトでアウトバウンド・レスポンスを処理する場合、添付ファイルをディスクにページングするように構成されたビジネス・サービスが適宜呼び出されます。

12.7 サービス・コールアウトの結果としてのエラー処理

エラー処理は、メッセージ・フロー、パイプライン、ルート・ノード、およびステージ・レベルで構成できます。サービス・コールアウトの結果として外部サービスから受け取るエラーのタイプには、トランスポート・エラー、SOAPフォルト、予期されるレスポンスに一致しないレスポンスなどがあります。

faultコンテキスト変数の設定は、返されるエラーのタイプごとに異なります。fault変数のコンテンツに基づいて、ビジネス・ロジックとエラー処理ロジックを構築できます。$faultの詳細は、「fault変数」を参照してください。

12.7.1 トランスポート・エラー

外部サービスからトランスポート・エラーを受け取り、トランスポート・プロバイダからService Busにエラー・レスポンス・ペイロードが返されない場合(たとえば、HTTPビジネス・サービスがXMLまたはSOAP以外のレスポンス・タイプを受け入れたためにHTTPレスポンス・コードを受け取れない場合)、サービス・コールアウト・アクションは例外をスローするので、パイプラインでエラーが発生します。ユーザーが構成したエラー・ハンドラのfault変数は、次の例に示すメッセージと同様にフォーマットされたメッセージにバインドされます。

例 - fault変数のコンテンツ - トランスポート・エラー、エラー・レスポンス・ペイロードなし

<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>OSB-380000</con:errorCode>
<con:reason>Not Found</con:reason>
<con:details>
.......
</con:details>
<con:location>
<con:node>PipelinePairNode1</con:node>
<con:Pipeline>PipelinePairNode1_request</con:Pipeline>
<con:Stage>Stage1</con:Stage>
</con:location>
</con:fault>

トランスポート・エラーに関連付けられたペイロードがある場合(たとえばビジネス・サービスからHTTP 500のエラー・コードを受け取り、レスポンス内にXMLペイロードがある場合)、カスタム・エラー・コードOSB-382502のメッセージ・コンテキスト・フォルトが生成されます。

サービスがHTTPまたはJMSトランスポートを使用している場合に、そのサービスからのレスポンスの結果としてOSB-382502エラー・レスポンス・コードがトリガーされるには、次の条件が満たされる必要があります。

- (HTTP)レスポンス・コードは300以上のコードである必要があります。

- (JMS)レスポンスにエラー・レスポンスであることを示すプロパティが設定されている必要があります(トランスポート・メタデータのステータス・コードが1に設定されている場合はエラーを示します)。

- コンテンツ・タイプは、text/xml、application/any_string+xmlまたはmultipart/relatedである必要があります。

- サービスがAnySoapまたはWSDLベースのSOAPである場合、サービスにSOAPエンベロープが必要です。SOAPエンベロープ内の本体はXML形式でなければなりません(テキストは不可)。

- サービスのタイプがAnyXMLまたはRESTである、あるいはタイプがテキストであるメッセージング・サービスでXMLコンテンツが不成功レスポンス・コード(200または202以外の任意のコード)とともに返されます。

トランスポートがHTTPの場合、ErrorResponseDetail要素にはレスポンスとともに返されるHTTPエラー・コードも含まれます。fault内のErrorResponseDetail要素には、サービスから受信したエラー・レスポンス・ペイロードが含まれます。次の例では、ErrorResponseDetail要素の例を示します。

例 - fault変数のコンテンツ - トランスポート・エラー、エラー・レスポンス・ペイロードあり

<ctx:Fault xmlns:ctx="http://www.bea.com/wli/sb/context">
<ctx:errorCode>OSB-382502<ctx:errorCode>
<ctx:reason> Service callout has received an error response from the server</ctx:reason>
<ctx:details>
<alsb:ErrorResponseDetail xmlns:alsb="http://www.oracle.com/...">
<alsb:detail> <![CDATA[
. . .
]]>
</alsb:detail>           <alsb:http-response-code>500</alsb:http-response-code>
</alsb:ErrorResponseDetail>
</ctx:details>
<ctx:location>. . .</ctx:location>
</ctx:Fault>

注意:

サービス・コールアウト生成フォルトのXMLスキーマが「予期しないレスポンス」に示されています。

12.7.2 SOAPフォルト

外部サービスがSOAPフォルトを返した場合、Service Busランタイムは、カスタム・エラー・コードとフォルトの詳細を示す説明を含むコンテキスト変数$faultを設定します。そのために、SOAPフォルトの<SOAP-ENV:Fault>要素の下にある3つの要素のコンテンツが抽出され、Service Busのfault要素の作成に使用されます。

サービスが次のエラーを返すシナリオを例にとります。

例 - サービス・コールアウトから返されるSOAPフォルト

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Client</faultcode>
<faultstring>Application Error</faultstring>
<detail>
<message>That's an Error!</message>
<errorcode>1006</errorcode>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

<faultcode>、<faultstring>、<detail>の各要素が抽出され、<alsb:ReceivedFault>要素にラップされます。「予期しないレスポンス」の例のfaultcode要素にはQNameが含まれ、関連するすべてのネームスペース宣言が保持されます。トランスポートがHTTPの場合、ReceivedFault要素にはフォルト・レスポンスとともに返されるHTTPエラー・コードも含まれます。

生成される<alsb:ReceivedFault>要素、およびカスタム・エラー・コードとエラー文字列は、faultコンテキスト変数のコンテンツの作成に使用されます。この例では、前述の例と同様の形式になります。

例 - Service Busのfault変数のコンテンツ - SOAPフォルト

<ctx:Fault xmlns:ctx="http://www.bea.com/wli/sb/context">
<ctx:errorCode>OSB-382500<ctx:errorCode>
<ctx:reason> service callout received a soap Fault response</ctx:reason>
<ctx:details>
<alsb:ReceivedFault xmlns:alsb="http://www.oracle.com/...">
<alsb:faultcode
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">SOAP-ENV:Client
</alsb:faultcode>
<alsb:faultstring>Application Error</alsb:faultstring>
<alsb:detail>
<message>That's an Error!</message>
<errorcode>1006</errorcode>
</alsb:detail>
<alsb:http-response-code>500</alsb:http-response-code>
</alsb:ReceivedFault>
</ctx:details>
<ctx:location> </ctx:location>
</ctx:Fault>

注意:

一意のエラー・コードOSB-382500は、サービス・コールアウト・アクションがSOAPフォルト・レスポンスを受け取ったときに備えて予約されています。

ローカル・プロキシ・サービスをチェーンする場合、$fault変数ではSOAPフォルトの詳細はあるパイプラインから次へは伝搬されません。『Oracle Service Busでのサービスの開発』のプロキシ・サービス間でのSOAPフォルトの伝播に関する項で説明しているように、プロキシ・サービス間でSOAPフォルトを伝播するには、失敗時の返信アクションを指定したエラー・ハンドラを使用します。

12.7.3 予期しないレスポンス

プロキシ・サービスのランタイムが予期していないレスポンス・メッセージがサービスから返された場合、メッセージ・コンテキスト・フォルトが生成され、カスタム・エラー・コードOSB-382501で初期化されます。フォルトの詳細にはレスポンスのSOAP-Body要素のコンテンツが含まれます。トランスポートがHTTPの場合、ReceivedFault要素にはフォルト・レスポンスとともに返されるHTTPエラー・コードも含まれます。

次の例では、サービス・コールアウトで生成されるフォルトの詳細のXMLスキーマ定義を示します。

例 - サービス・コールアウトで生成されるフォルトの詳細のXMLスキーマ

<xs:complexType name="ReceivedFaultDetail">
<xs:sequence>
<xs:element name="faultcode" type="xs:QName"/>
<xs:element name="faultstring" type="xs:string"/>
<xs:element name="detail" minOccurs="0" >
<xs:complexType>
<xs:sequence>
<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax" />
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax" />
</xs:complexType>
</xs:element>
<xs:element name="http-response-code" type="xs:int" minOccurs="0"/>\
type="xs:int" minOccurs="0"/>
</xs:sequence>
</xs:complexType>

<xs:complexType name="UnrecognizedResponseDetail">
<xs:sequence>
<xs:element name="detail" minOccurs="0" type="xs:string" />
</xs:sequence>
</xs:complexType>

<xs:complexType name="ErrorResponseDetail">
<xs:sequence>
<xs:element name="detail" minOccurs="0" type="xs:string" />
</xs:sequence>
</xs:complexType>

12.8 パイプラインでのエラー処理

次のパラグラフで説明するプロセスでは、エラー・ハンドラ・ステージのエラー処理パイプラインを構成します。また、エラー・パイプラインは、パイプライン・ペアのリクエストまたはレスポンス、またはパイプライン全体に対して定義できます。

ステージ・レベルのエラー・ハンドラがエラー処理に呼び出されます。ステージ・レベルのエラー・ハンドラが特定タイプのエラーを処理できない場合、パイプライン・エラー・ハンドラが呼び出されます。パイプライン・レベルのエラー・ハンドラもエラーを処理できない場合は、サービス・レベルのエラー・ハンドラが呼び出されます。サービス・レベルのエラー・ハンドラも処理できない場合、システムがエラーを処理します。表12-9に、パイプラインの様々なレベルにおけるエラー・ハンドラのスコープの概要を示します。

表12-9 エラー・ハンドラのスコープ

レベル

スコープ

ステージ

ステージ内のすべてのエラーを処理します。

パイプライン

パイプラインのステージの未処理のエラーと共に、パイプラインのすべてのエラーを処理します。

サービス

サービスのパイプライン・ペアのリクエストまたはレスポンスの未処理のエラーとともに、パイプラインのすべてのエラーを処理します。

注意: WS-Securityエラーはすべてこのレベルで処理されます。

システム

パイプラインのどの場所でも処理されないすべてのエラーを処理します。

注意:

エラー・ハンドラのスコープには例外があります。たとえば、ステージ・レベルの非XMLトランスフォーメーションによってスローされる例外を捕捉するのは、サービス・レベルのエラー・ハンドラのみです。プロキシ・サービスの送信レスポンス・メッセージ用にXMLからMFLに変換する場合、このトランスフォーメーションは常にバインディング・レイヤーで発生します。したがって、たとえば、非XML出力でステージ・レベルの必須フィールドが欠落している場合、サービス・レベルのエラー・ハンドラだけがこのエラーを捕捉できます。

アサーションがtrueであるかどうかを確認するテストを構成することでエラーを処理できます。このテストは様々なレベルで繰り返すことができます。下位レベルでエラー・ハンドラのない状態でエラーが発生した場合、パイプラインの上位レベルのエラー・ハンドラによって処理することもできます。

通常、パイプラインのステージ・レベルで特定のエラーを処理し、下位レベルでは処理されないエラーのより一般的なデフォルト処理に上位レベルのエラー・ハンドラを使用する方が簡単です。予期されるエラーをパイプラインで明示的に処理し、予期されないエラーをサービス・レベルのハンドラで処理することをお薦めします。

12.8.1 エラー・メッセージの生成、レポート、および返信

メッセージ処理中に発生したエラーに関する情報はすべて、事前定義されたコンテキスト変数(fault変数)に保持されます。エラーが発生すると、この変数に情報が格納されてから、適切なエラー・ハンドラが呼び出されます。このfault変数はエラー・ハンドラ・パイプラインでのみ定義され、リクエスト・パイプラインやレスポンス・パイプライン、ルート・ノードやブランチ・ノードでは設定されません。$faultの詳細は、「事前定義されたコンテキスト変数」を参照してください。

リクエスト/レスポンス型のインバウンド・メッセージでのエラー発生時には、多くの場合、エラーが発生した理由を説明するメッセージを送信元に返送する必要があります。そのためには、送信するレスポンスに対してメッセージ・コンテキスト変数を構成した後、失敗時の返信アクションを使用します。たとえば、HTTPメッセージが失敗した場合は、失敗時の返信でHTTP 500ステータスが生成されます。JMSメッセージが失敗した場合は、失敗時の返信でJMS_BEA_Errorプロパティがtrueに設定されます。

プロキシ・サービスが呼び出したサービスがSOAPフォルトまたはトランスポート・エラーを返すと、エラー処理パイプラインが呼び出されます。受信したSOAPフォルトはすべて$bodyに格納されるため、$bodyを変更せずに失敗時の返信を実行すると、サービスの呼出し元のクライアントには元のSOAPフォルトが返されます。返信アクションが構成されていない場合、システム・エラー・ハンドラによって新しいSOAPフォルト・メッセージが生成されます。プロキシ・サービスでは、HTTPエラー・ステータスが設定されたか、JMSプロパティSERVER_Errorがtrueに設定されているためにSOAPフォルトが返されたと認識されます。

用途によっては、エラー・レポートが必要な場合があります。このような場合は、レポート・アクションを使用します。たとえば、リクエスト・パイプラインで追跡用にメッセージをレポートするレポート・アクションを実行した後、ルート・ノードによって呼び出されたサービスが失敗するというシナリオを想定します。このような場合、メッセージはレポート・システムによってログに記録されますが、メッセージが正常に処理されたという保証はありません。メッセージが正常に受信されたことを示すだけです。

Oracle Service Busコンソールでは、メッセージを追跡することによって、メッセージ・フローの正確な流れを把握することができます。これにより、メッセージが処理のために送信されたことをレポートする元のメッセージだけでなく、メッセージが正常に処理されなかったことをレポートする以降のエラーも確認できます。レポート・アクションの構成方法と実行時にレポートされるデータの使用方法については、「Oracle Service Busコンソールでのパイプライン・アクションの操作」を参照してください。

12.8.2 Service Bus 11gと12cのセキュリティ・フォルトの処理の異なる動作

Service Bus 12cは、メッセージ・フローのセキュリティ・フォルトをService Bus 11gとは別の方法で処理します。

Service Bus 11gでは、失敗したOWSMポリシーまたはインバウンド・リクエストのカスタム・トークン・メッセージ・レベル認証は、パイプライン・メッセージ・フローでユーザー構成サービス・エラー・ハンドラにより処理できます。たとえば、ユーザー名トークン認証ポリシーのサービスで、認証の失敗はサービスレベル・エラー・ハンドラをトリガーします(構成されている場合)。

Service Bus 12cでは、インバウンド・リクエストのセキュリティ処理によって発生するセキュリティ・エラーはパイプライン・サービスレベルのエラー・ハンドラでは処理されず、このSOAPフォルトの結果はデフォルト・インバウンドのシステム・エラー・ハンドラによって自動的に生成されます。これらのフォルトはカスタマイズできません。失敗したリクエストを次のコンポーネント(たとえば、パイプラインまたはビジネス・サービス)にルーティングすることはできません。

12.8.3 エラー・ハンドラでのアクションの構成の例

この例では、エラー・ハンドラにレポート・アクションと返信アクションを構成する方法を示します。図12-1に示すパイプラインには、validate loan applicationステージのエラー・ハンドラが含まれています。この例のエラー・ハンドラは、1つのステージが構成された単純なメッセージ・フローです。Oracle Service Busコンソールには、図12-1のように表示されます。

図12-1 エラー・ハンドラ・パイプライン

図12-2に示すように、このステージはアクション(置換、レポートおよび返信)で構成されています。

図12-2 ステージ・エラー・ハンドラのアクション

アクションによって、パイプライン・エラー・ハンドラのステージの動作が次のように制御されます。

- 置換: body変数の指定した要素のコンテンツが、faultコンテキスト変数のコンテンツで置換されます。body変数の要素はXPath式で指定します。コンテンツは、XQuery式で返される値で置換されます。この例では$fault/ctx:reason/text()です。

- レポート: このアクションで構成されたエラー・ハンドラが呼び出されると、レポート・アクションのメッセージがService Busレポート・データ・ストリームに書き込まれます。JMSレポート・プロバイダによって、メッセージがFusion Middleware ControlのService Busダッシュボードでレポートされます。Service Busには、メッセージ・データを1つ以上のレポート・プロバイダに配信する機能があります。メッセージ・データは、メッセージの本文、およびメッセージに関連付けられた他の任意の変数(ヘッダーやinbound変数など)から取り込むことができます。レポート・プロバイダに配信されたメッセージは、メッセージのトラッキングや規制の監査などの機能に使用できます。
エラーが発生すると、faultコンテキスト変数のコンテンツがレポートされます。キー名はerrorCodeです。キー値は./ctx:errorCodeというXPath式を使用してfault変数から抽出されます。キーと値のペアをキー識別子として使用して、実行時にダッシュボードでこれらのメッセージを識別します。

レポート・アクションを構成し、実行時にレポートされるデータを使用するには、「Oracle Service Busコンソールでのパイプライン・アクションの操作」を参照してください。

- 返信: 実行時に、loanGateway3プロキシ・サービスの呼出し元に即時返信が送信され、メッセージにフォルトが含まれていたことが示されます(図12-2を参照)。この返信は「失敗時」です。

12.9 動的ルーティングの使用

作成するパイプラインから呼び出す必要があるサービスがわからない場合に、動的ルーティングを使用できます。どのパイプラインでも、次のいずれかの方法を使用して、メッセージを動的にルーティングできます。

- Service Busの完全修飾サービス名を動的に設定し、動的ルート・アクションまたは動的パブリッシュ・アクションを使用するように、メッセージ・フロー・パイプラインでXQuery式を設計します。

注意:

動的ルーティングはルート・ノードで使用でき、動的パブリッシュはリクエスト・パイプラインまたはレスポンス・パイプラインのステージで使用できます。

この方法を使用すると、パイプラインでは、エンドポイント・ビジネス・サービスのサービス・アカウントを動的に使用して、ユーザー名とパスワードをそのアウトバウンド・リクエストに送信します。たとえば、パイプラインがビジネス・サービスAにリクエストをルーティングする場合、呼出し元プロキシ・サービスではビジネス・サービスAのサービス・アカウントを使用して、ユーザー名とパスワードをそのアウトバウンド・リクエストに送信します。「動的ルーティングの実装」を参照してください。

- ビジネス・サービスにメッセージをルーティングまたはパブリッシュするように、パイプラインを構成します。次に、ルート・アクションまたはパブリッシュ・アクションのリクエスト・アクション・セクションで、サービスのURIを動的に指定するルーティング・オプション・アクションを追加します。
この方法を使用すると、リクエストの送信先のURIに関係なく、ユーザー名とパスワードをそのアウトバウンド・リクエストに送信するために、プロキシ・サービスは静的に定義されたビジネス・サービスのサービス・アカウントを使用します。

この方法の使用方法については、「動的ルーティングの実装」を参照してください。

注意:

この方法は、インタフェースの概要が確定している場合に使用します。インタフェースの概要には、メッセージのタイプ、ポート・タイプ、およびバインディングが含まれます。具象インタフェースは含まれません。具象インタフェースは、サービスが配置されているトランスポートURLです。

動的サービスの呼出しの操作例については、http://www.oracle.com/technetwork/middleware/service-bus/learnmore/index.htmlでService Busのサンプルを参照してください。

12.9.1 動的ルーティングの実装

動的ルーティングを使用すると、パイプラインの実行時に宛先を確定できます。これを行うには、XMLファイルのルーティング表を使用して、XQueryリソースを作成します。

注意:

XQueryリソースを使用するかわりに、リソースの作成元のXMLファイルを直接使用することもできます。

XMLファイルまたはXQueryリソースは容易に保持できます。実行時に、パイプラインのルーティング先またはパブリッシュ先を決定するルーティング・テーブルにエントリを指定します。XMLファイルまたはXQueryリソースには、論理的な識別子(企業名など)を物理的な識別子(Service Busのサービスの完全修飾名)にマップするルーティング・テーブルが含まれています。メッセージから抽出された論理的な識別子は、呼び出すサービスの名前である物理的な識別子にマップされます。

注意:

動的ルート・アクションを使用するには、Service Busのサービスの完全修飾名が必要です。

パイプラインでは、論理的な修飾子はXPathを使用してメッセージに取得されます。XQueryリソースのXML表を変数に割り当てます。ルーティング表の変数に問合せを実装し、対応する論理的な修飾子に基づいて物理的な修飾子を抽出します。この変数を使用すると、必要なサービスを呼び出すことができます。次の項では、動的ルーティングの実装方法を説明します。

- サンプルXMLファイル

- サンプルXMLからのXQueryリソースの作成

- 動的ルーティングを実装するためのパイプラインの作成および構成

- IDベースのルーティングの実装に関するガイドライン

12.9.1.1 サンプルXMLファイル

次のXMLファイルからXQueryリソースを作成できます。sampleXquery.xmlとしてこれを保存します。

例 - サンプルXMLファイル

<routing>
<row>
<logical>Oracle</logical>
<physical>default/goldservice</physical>
</row>
<row>
<logical>ABC Corp</logical>
<physical>default/silverservice</physical>
</row>
</routing>

12.9.1.2 サンプルXMLからのXQueryリソースの作成

Oracle Service BusコンソールでサンプルXMLからXQueryリソースを作成するには:

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. 「Oracle Service Busコンソール」ウィンドウの右上から、「Designer」タブをクリックします。プロジェクト・ナビゲータが表示されます。

3. 「すべてのプロジェクト」ノードの前にある「展開」(矢印)アイコンをクリックし、このノードを開きます。

4. XQueryリソースの追加先となるプロジェクト名を右クリックします。

5. コンテキスト・メニューで「作成」、「リソース」をクリックします。

6. 「リソース・ギャラリ」から「変換」、「XQuery」の順にクリックします。XQueryの作成ダイアログが表示されます。

7. 「リソース名」フィールドにリソースの名前を入力します。これは必須です。

8. 「リソースの説明」フィールドにリソースの説明を入力します。これはオプションです。

9. 「ファイルの選択」をクリックして、XQueryリソースとして使用するXMLファイルを選択します。

10. 「作成」をクリックしてXQueryリソースを作成します。

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

12.9.1.3 動的ルーティングを実装するためのパイプラインの作成および構成

パイプラインを使用して動的ルーティングを実装するには:

1. プロジェクト・ナビゲータで、パイプラインの追加先のプロジェクトを選択して、「作成」アイコンの横の下向き矢印をクリックします。

2. オプションのリストから、「パイプライン」を選択します。

パイプラインの作成ダイアログが表示されます。

3. 「全般」セクションの「パイプライン名」フィールドに、パイプラインの名前を入力します。これは必須です。オプションで、パイプラインの「説明」を指定します。

4. パイプラインの「サービス・タイプ」を選択します。サービス・タイプの選択の詳細は、「プロキシ・サービスのサービス・タイプとプロトコル」を参照してください。

5. プロキシ・サービスとして公開を選択して、パイプライン・メッセージ・フローに対応するプロキシ・サービスを作成します。作成するプロキシ・サービスの名前とその他の詳細を指定します。

6. 「作成」をクリックして、パイプライン・リソースを作成します。パイプラインが作成され、開いて編集できます。

7. ウィンドウの右上隅付近にある「メッセージ・フローを開く」アイコンをクリックします。「メッセージ・フローの編集」ページが表示されます。メッセージ・フローは、最初は1つのアイコンで構成されます。

8. 開始ノード(パイプライン・アイコン)をクリックし、「パイプライン・ペアの追加」を選択してパイプライン・ペアをメッセージ・フローに追加します。

9. 「リクエスト・パイプライン」アイコンをクリックし、メニューから「ステージの追加」を選択します。

10. 「Stage1」アイコンをクリックし、メニューから「ステージの編集」を選択します。「ステージ構成の編集」ページが表示されます。

11. 「アクションの追加」アイコンをクリックします。メニューから「アクションの追加」項目を選択します。

12. 「メッセージ処理」から「割当て」アクションを選択します。

13. 「式」をクリックします。XQuery式エディタが表示されます。

14. 「XQueryリソース」をクリックします。ブラウザに、XQueryリソースをインポートできるページが表示されます。「参照」をクリックしてXQueryリソースを検索します。

15. 「検証」をクリックしてインポートしたXQueryリソースを検証します。

16. 検証が成功したら、インポートしたXQuery式を保存します。

17. 「ステージ構成の編集」ページで、フィールドに変数の名前を入力します。

これにより、XQueryリソースがこの変数に割り当てられます。これで、この変数に外部化したルーティング表が格納されました。

18. 別の「割当て」アクションを追加します。

19. 次のXQueryを入力します。

<ctx: route>
<ctx: service isProxy='false'> {$routingtable/row[logical/text()=$logicalidentifier]/physical/text()}
</ctx: service>
</ctx: route>

前述のコードで、$logicalidentifierを実際のXPathで置換して、メッセージ($bodyなど)から論理的な識別子を抽出します。

20. 「検証」をクリックして、XQueryを検証します。

21. 検証が成功したら、XQueryを保存します。

22. 「ステージ構成の編集」ページで、フィールドに変数の名前(routeresultなど)を入力します。

これにより、動的ルート・アクションで使用するXMLがこの変数に抽出されます。

23. パイプライン・アイコンをクリックして、パイプラインの最後にルート・ノードを追加します。

24. 「ルート・ノード」アイコンをクリックし、メニューから「編集」を選択します。

25. 「アクションの追加」アイコンをクリックします。メニューから「アクションの追加」項目を選択します。

26. 動的ルーティング・アクションを選択します。

27. 「式」をクリックします。XQuery式エディタが表示されます。

28. 変数($routeresultなど)を入力します。

12.9.1.4 IDベースのルーティングの実装に関するガイドライン

認証済ユーザーのIDをベースにしたメッセージの動的ルーティングを行う場合、Service Busはユーザー名、グループ・メンバーシップ(/principals/group)、サブジェクト名(/subject-properties/property/name)などの情報を次のインバウンド・コンテキスト変数に格納します。

- $inbound/ctx:security/ctx:transportClient/*

- $inbound/ctx:security/ctx:messageLevelClient/*

これらのコンテキスト変数の詳細は、表A-6を参照してください。

「動的ルーティングの使用」で説明されているガイダンスに従って、目的のマッピング方法としてXQueryまたは簡単なXMLを使用して、認証済ユーザーのID特性を異なるエンドポイントにマップします。

次の事前定義されたService Bus XQuery関数も、IDベースのルーティングのセキュリティ・チェックの実行に使用できます。

- fn-bea:lookupBasicCredentials

- fn-bea:isUserInGroup

- fn-bea:isUserInRole

動的サービスの呼出しの操作例については、http://www.oracle.com/technetwork/middleware/service-bus/learnmore/index.htmlでService Busのサンプルを参照してください。

12.10 XQueryを使用したデータベースへのアクセス

Service Busでは、カスタムのEJBコードやJavaコードを記述したり、Oracle Data Service Integratorなどの別のデータベース製品を使用せずに、パイプラインからデータベースに対して読取りアクセスを行うことができます。execute-sql()関数を使用して、データベースに対して簡単なJDBC呼出しを行い、単純なデータベースの読取りを実行できます。指定した地域の税率を取得する単純な問合せや、複雑な結合を使用して、基になる複数のデータベース表から注文の現在のステータスを取得する問合せなど、任意のSQL問合せが有効です。

データベース問合せを使用してデータを取得し、メッセージに情報を追加したり、ルーティング先を選択したり、パイプラインの動作をカスタマイズできます。Service Busパイプラインが「見積依頼」メッセージを受信する場合のシナリオを例として示します。パイプラインは、顧客の優先度に基づいて、見積りを提供する複数のビジネス・サービス(たとえば標準、ゴールド、プラチナ・レベルのサービス)のいずれかにリクエストをルーティングできます。その後で、パイプラインは、それらのサービスが返す結果をSQLベースで補強します。たとえば、選択した出荷方法と注文品の重量に基づいて送料を検索し、そのコストを見積依頼メッセージに追加できます。

関数の構文とその使用例については、「fn-bea:execute-sql()」を参照してください。execute-sql()関数は型付きデータを返し、SQL/JDBCデータ・モデルとXQueryデータ・モデル間で値を自動的に変換します。

返された要素を、Service Busパイプラインのユーザー定義の変数に格納できます。

execute-sql()関数でサポートされるデータベースおよびJDBCドライバは次のとおりです。

- WebLogic Serverに含まれるサンプル・データベース。
IBM DB2/NT 8

- Microsoft SQL Server 2000、SQL Server 2005

- Oracle9i、Oracle Database 10g、Oracle Database 11g、Oracle Database 12c

- Sybase 12.5.2および12.5.3

- WebLogic Type 4 JDBCドライバ

- WebLogic Serverでサポートされるサード・パーティ製ドライバ

「fn-bea:execute-sql()」関数で使用するデータソースには、非XAドライバを使用してください。この関数は、データソースへの読取り専用アクセスをサポートしています。

警告:

データベースへの接続に使用する非XA JDBCドライバ・クラスの指定に加え、グローバル・トランザクションと2フェーズ・コミットを必ず無効にする必要があります。(Oracle WebLogic Server管理コンソールで、グローバル・トランザクションはJDBCデータ・ソースに対してデフォルトでは有効です。)データ・ソースに対するこれらの指定は、Oracle WebLogic Server管理コンソールを介して行うことができます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの作成に関する項を参照してください。

Service BusでサポートされているデータベースおよびJDBCドライバの詳細は、次の場所にあるOracle Fusion Middlewareのサポートされるシステム構成を参照してください。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

前述のリストに示したコア・セット以外のデータベースもサポートされています。ただし、前述のコア・データベースでは、非コア・データベースの場合よりも、XQueryエンジンが適切にデータ型を認識し、XQueryタイプにマップします。データを取得する際に、コア・データベースの独自のJDBC拡張が使用される場合もあります。非コア・データベースでは、XQueryエンジンは、JDBCドライバが提供する標準タイプのコード、および標準のJDBC結果セットのアクセス・メソッドに完全に依存します。

パイプラインを設計する際に、XQueryはリソースとして入力するのではなく、アクション定義の一部としてインラインで入力できます。パイプラインでIf Thenアクションの条件にインラインXQueryを使用することもできます。インラインXQueryエディタの使用については、「変数の構造のマッピングの作成」を参照してください。

12.11 メッセージ・コンテキストの理解

メッセージ・コンテキストは、Service Busを介してメッセージがルーティングされるときに、メッセージ・コンテキストとメッセージに関する情報を保持する一連の変数です。header、bodyおよびattachmentsの各変数(XQuery文では、$header、$bodyおよび$attachments)は、Service Busを介して流れるメッセージを表します。メッセージの標準書式はSOAPです。サービス・タイプがSOAPでなくても、メッセージはService Busのメッセージ・コンテキスト内でSOAPとして表示されます。

表12-10に、Service Busメッセージ・コンテキスト変数を示します。

表12-10 Service Busの事前定義されたコンテキスト変数

コンテキスト変数

説明

関連項目

header

SOAPメッセージの場合、$headerにはSOAPヘッダーが格納されます。パイプラインがSOAP 1.2の場合、$headerにはSOAP 1.2 Header要素が格納されます。

メッセージのタイプがSOAP以外の場合、$headerには空のSOAPヘッダー要素が格納されます。

メッセージ関連の変数

body

この変数は、次に説明するようにメッセージ・タイプに応じて異なります。

- SOAPメッセージ: SOAPエンベロープから抽出した<SOAP:Body>部。パイプラインがSOAP 1.2の場合、$body変数にはSOAP 1.2 Body要素が格納されます。

- バイナリ以外の非SOAPメッセージ: <SOAP:Body>要素でラップされたメッセージ・コンテンツ全体。

- バイナリ・メッセージ: <SOAP:Body>でラップされたバイナリ・メッセージのメモリー内コピーへの参照。

- Javaオブジェクト: <SOAP:Body>でラップされたJavaオブジェクトのメモリー内コピーへの参照。

メッセージ関連の変数

attachments

メッセージのMIME添付。

メッセージ関連の変数

inbound

インバウンド・トランスポート・ヘッダーとメッセージを受信したプロキシ・サービスについての情報。

inbound変数およびoutbound変数

outbound

アウトバウンド・トランスポート・ヘッダーとメッセージが送信されるターゲット・サービスについての情報。

inbound変数およびoutbound変数

operation

パイプラインで呼び出される操作

operation変数

fault

メッセージの処理中に発生したエラーに関する情報。

フォルト変数

messageId

トランスポート・プロバイダ固有のメッセージIDです。このIDは、Service Busランタイムを通過するその他のメッセージからメッセージを一意に識別できることが必要です。ただし、この値は一意である必要はありません。

messageID変数

12.11.1 メッセージ・コンテキストのコンポーネント

メッセージ・コンテキストでは、$headerにSOAP Header要素が格納され、$bodyにSOAP Body要素が格納されます。Header要素とBody要素は、パイプラインのサービス・タイプに応じてSOAP 1.1またはSOAP 1.2のネームスペースで修飾されます。また、メッセージ・コンテキストでは、$attachmentsにattachmentsと呼ばれるラッパー要素が含まれ、attachmentごとに1つのattachment子要素を持ちます。attachment要素には、body要素と実際の添付ファイルが含まれます。

パイプラインでメッセージを受信すると、メッセージのコンテンツを使用してheader変数、body変数およびattachments変数が初期化されます。SOAPサービスの場合、受信したSOAPメッセージのエンベロープからHeader要素およびBody要素が直接取得され、それぞれ$headerおよび$bodyに割り当てられます。非SOAPサービスの場合、通常はメッセージのコンテンツ全体がBody要素(SOAP 1.1ネームスペースで修飾)でラップされて$bodyに割り当てられ、空のHeader要素(SOAP 1.1ネームスペースで修飾)が$headerに割り当てられます。

バイナリ・メッセージとMFLメッセージは別の方法で初期化されます。MFLメッセージの場合、$bodyに割り当てられるBody要素には、MFLと同等のXMLドキュメントが挿入されます。バイナリ・メッセージの場合、メッセージ・データは内部的に格納され、$bodyに割り当てられるBody要素には参照XMLが挿入されます。参照XMLは<binary-content ref="..."/>のような形式になります。"..."には、パイプラインによって割り当てられる一意の識別子が入ります。

メッセージ・コンテキストは、XMLスキーマによって定義されます。パイプラインのコンテキスト変数を操作するには、XQuery式を使用する必要があります。Service Busで事前定義されているコンテキスト変数は、次のように分類されます。

- メッセージ関連の変数

- inbound変数およびoutbound変数

- operation変数

- fault変数

事前定義されたコンテキスト変数の詳細は、「事前定義されたコンテキスト変数」を参照してください。

$bodyには、メッセージのペイロード変数が含まれます。Service Busからメッセージをディスパッチするときに、送信メッセージに含める変数を決定できます。この決定は、ターゲットのエンドポイントがSOAPメッセージを受信するか非SOAPメッセージを受信するかによって異なります。

- バイナリの場合、$bodyのBody要素に任意のテキストまたはXMLメッセージ・コンテンツが格納されて送信されます。

- MFLメッセージの場合、$bodyのBody要素にMFLドキュメントと同等のXMLが格納されます。

- テキスト・メッセージの場合、$bodyのBody要素にテキストが格納されます。テキスト添付では、$attachmentsのBody要素にテキストが格納されます。コンテンツがシンプル・テキストではなくXMLの場合、XMLはテキスト・メッセージとして送信されます。

- XMLメッセージの場合、$bodyのBody要素にXMLが格納されます。XML添付では、$attachmentsのBody要素にXMLが格納されます。

- SOAPメッセージは、<soap:Envelope>要素内のheader変数およびbody変数のコンテンツをラップすることで作成されます。SOAP 1.1ネームスペースはSOAP 1.1サービスに使用され、SOAP 1.2ネームスペースはSOAP 1.2サービスに使用されます。body変数に参照XMLが格納されている場合、この参照XMLが送信されます。つまり、参照されているコンテンツはメッセージに追加されません。

非SOAPサービスの場合、$bodyのBody要素にbinary-content要素が格納されると、ターゲット・サービスのタイプに関係なく、内部的に格納された参照先コンテンツがそのまま送信されます。

詳細は、「メッセージ・コンテキスト」を参照してください。

メッセージ・コンテキスト変数の型は、メッセージ・コンテキスト・スキーマ(MessageContext.xsd)によって定義されます。Oracle XQuery Mapperでメッセージ・コンテキスト変数を操作する場合は、JARファイル(OSB_ORACLE_HOME/lib/sb-schemas.jar)に用意されたMessageContext.xsdと、次の場所にあるトランスポート固有のスキーマを参照する必要があります。

OSB_ORACLE_HOME/lib/transports/

メッセージ・コンテキスト・スキーマおよびトランスポート固有のスキーマの詳細は、「メッセージ・コンテキスト・スキーマ」を参照してください。

12.11.2 メッセージ・コンテキストを表示および変更するためのガイドライン

メッセージ・コンテキストを検査または変更するときには、次のガイドラインを考慮してください。

- XQuery式で変数の要素を参照する場合、その変数のルート要素はパスに含まれません。たとえば、次のXQuery式は、メッセージの最初の添付のContent-Descriptionを取得します。

$attachments/ctx:attachment[1]/ctx:content-Description

2番目の添付を取得するには、次のように記述します。

$attachments/ctx:attachment[2]/ctx:body/*

- コンテキスト変数は空の場合もあれば、単一のXML要素または文字列値が格納されている場合もあります。ただし、多くの場合、XQuery式はシーケンスを返します。XQuery式を使用して値を変数に割り当てるとき、式によって返されるシーケンスの最初の要素のみが変数の値として格納されます。たとえば、SOAPヘッダーのWS-Addressing Message IDの値(ヘッダーに存在するものと仮定)をidvarという変数に割り当てる場合、割当てアクションを次のように指定します。

assign data($header/wsa:messageID to variable idvar

注意:

この例で2つのWS-Addressing MessageIDヘッダーが存在する場合、idvar変数には最初のMessageIDヘッダーの値が割り当てられます。

- 変数$header、$bodyおよび$attachmentsが空になることはありません。ただし、$headerには空のSOAP Header要素、$bodyには空のSOAP Body要素、$attachmentsには空のattachments要素がそれぞれ含まれる場合があります。

- トランスフォーメーション・リソース(XSLTまたはXQuery)を使用する場合、トランスフォーメーション・リソースは、メッセージのSOAP本体のドキュメントを変換するように定義されます。このような場合、トランスフォーメーションの入力パラメータをXQuery式にすることで、トランスフォーメーションの簡易化および効率化を図ることができます。たとえば、次のXQuery式を使用して、トランスフォーメーションへの入力として、メッセージのBody要素($body)にビジネス・ドキュメントを渡すことができます。

$body/* [1]

トランスフォーメーションの結果は、置換アクションによって$bodyに戻すことができます。つまり、$bodyのコンテンツ(Body要素のコンテンツ)を置換します。詳細は、「XQueryでのデータの変換」および「XSLTでのデータの変換」を参照してください。

- 挿入アクションまたは置換アクションを使用すると、単一の要素に対する挿入または置換だけでなく、選択した要素のシーケンスに対しても挿入または置換を行うことができます。要素のシーケンスを返すようXQuery式を構成できます。たとえば、挿入アクションおよび置換アクションを使用して、$inboundから$outboundに一連のトランスポート・ヘッダーをコピーすることができます。アクションの追加の詳細は、「コンソールでのパイプライン・アクションの追加と編集」を参照してください。使用例については、「inboundからoutboundへのJMSプロパティのコピー」を参照してください。

12.11.3 inboundからoutboundへのJMSプロパティのコピー

プロキシ・サービスと呼び出されるビジネス・サービスのインタフェースが異なることが前提になっています。そのため、Service Busでは、inbound変数からoutbound変数への情報(トランスポート・ヘッダーやJMSプロパティなど)を伝播しません。

プロキシ・サービスのリクエスト・メッセージとレスポンス・メッセージのトランスポート・ヘッダーは$inboundに含まれ、呼び出されるビジネス・サービスのリクエストとレスポンスのトランスポート・ヘッダーは$outboundに含まれます。

たとえば、一方向メッセージ(レスポンスのない呼出し)で、ユーザー定義のJMSプロパティをインバウンド・メッセージからアウトバウンド・メッセージにコピーする必要がある場合、次のXQuery式を使用できます。

トランスポート・ヘッダー・アクションを使用して、次を設定します

$inbound/ctx:transport/ctx:request/tp:headers/tp:user-header

次の最初の子として:

./ctx:transport/ctx:request/tp:headers

出力変数の中で。

トランスポート・ヘッダー・アクションの構成方法の詳細は、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。

12.12 変数の構造での作業

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

- インラインXQuery式エディタの使用

- 変数の構造の使用

「変数の構造のマッピングの作成」には例が示されています。

12.12.1 インラインXQuery式エディタの使用

Service Busでは、Oracle XQuery Mapperなどの外部ツールで作成されたXQueryをインポートできます。これらのXQueryは、パイプラインのどの場所でも使用できます。XQueryを使用するには、XQueryリソースの入力をインラインXQueryにバインドし、XQueryリソースの出力をアクションにバインドします。このアクションは、出力の結果を入力として使用する割当て、置換、挿入などのアクションです。

ただし、XQueryをリソースとして入力するのではなく、アクションの定義の一部としてインラインで入力することができます。If...Then...アクションの条件にインラインXQueryを使用することもできます。

インラインXQuery式エディタは、次のもので構成される簡単なXQueryを入力するときに使用します。

- XQueryが埋め込まれたXMLフラグメント

- child軸に沿った単純な変数パス

注意:

より複雑なXQueryについては、XQueryに慣れていない場合は特に、XQuery Mapperを使用することをお薦めします。

インラインXQueriesは、次のような場合に使用すると効率的です。

- インラインXQuery式エディタを使用して変数の構造を作成します。「変数の構造の使用」を参照してください。

- $headerまたは$bodyに含まれるSOAPエンベロープの要素からビジネス・ドキュメントまたはRPCパラメータを抽出したり、アクセスします。

- $attachmentsに含まれる添付ドキュメントを抽出したり、アクセスします。

- サービス・コールアウト・アクションのパラメータをSOAPエンベロープから抽出して設定します。

- サービス・コールアウト・アクションの結果パラメータをSOAPエンベロープに挿入します。

- for loopを実行するためにSOAPエンベロープからシーケンスを抽出します。

- 更新アクションで、for loop内のシーケンスの項目を更新します。

注意:

インラインXQuery式エディタを使用して、変数の構造を作成することもできます。詳細は、「変数の構造の使用」を参照してください。

12.12.1.1 インラインXQuery

インラインXQueryエディタとインラインXPathエディタでは、変数の構造を型または要素にマップし、その構造のグラフィック表現からドラッグ・アンド・ドロップ操作によってパス式を作成することにより、変数の構造を宣言できます。また、パス式を手動で入力することもできます。

この機能は、すべてのユーザー定義変数と$inbound、$outboundおよび$faultに対して直接使用できます。ただし、この機能を使用して$attachmentsのXML添付ファイル、$headerのヘッダーまたは$bodyのドキュメントとRPCパラメータに直接アクセスすることはできません。例外として、WSDLベースのプロキシ・サービスによって受信されたリクエスト・メッセージの$bodyのドキュメントとパラメータには直接アクセスできます。

変数の構造の作成方法の詳細は、「変数の構造のマッピングの作成」を参照してください。

XQueryエンジンのサポート、およびOracleの関数と演算子の関係の詳細は、「Service Bus XQuery関数」を参照してください。

12.12.1.2 インラインXQuery式エディタの用途

通常、インラインXQuery式エディタは、次のもので構成される簡単なXQueryを入力するときに使用します。

- XQueryが埋め込まれたXMLフラグメント

- child軸に沿った単純な変数パス

注意:

複雑なXQueryには、ドラッグ・アンド・ドロップ機能を備えたOracle XQuery Mapperを使用することをお薦めします。『Oracle SOA SuiteでのSOAアプリケーションの開発』のXQueryマッパーでの変換の作成に関する項を参照してください。

インラインXQueryの適切な使用例は次のとおりです。

- $headerまたは$bodyに含まれるSOAPエンベロープの要素からビジネス・ドキュメントまたはRPCパラメータを抽出したり、アクセスします。

- $attachmentsに含まれる添付ドキュメントを抽出したり、アクセスします。

- サービス・コールアウトのパラメータをSOAPエンベロープから抽出して設定します。

- サービス・コールアウトの結果パラメータをSOAPエンベロープに挿入します。

- for loopを実行するためにSOAPエンベロープからシーケンスを抽出します。

- 更新アクションで、for loop内のシーケンスの項目を更新します。

インラインXQuery式エディタを使用して、変数の構造を作成することもできます。詳細は、「変数の構造の使用」を参照してください。

12.12.1.2.1 タイプ依存の式のベスト・プラクティス

タイプ依存の式を使用する場合に予期した結果を保証するには、値を目的のタイプに手動でキャストします。たとえば、次の文では、counterをXQueryコンパイラの整数値としてキャストして、単一の戻り値を保証します。

<Body><result>{$foo/item[xs:int($counter)]}</result></Body>

12.12.2 変数の構造の使用

インラインXQuery式エディタを使用すると、変数の構造を作成することができます。これにより、設計の目的で特定の変数の構造を定義できます。たとえば、XPath変数のXMLスキーマを表示するよりも、管理コンソールでXPath変数を参照する方が簡単です。Oracle Service Busコンソールでの変数の構造の使用例は、「変数の構造のマッピングの作成」を参照してください。

注意:

ランタイムを作動させるために変数の構造を作成する必要はありません。変数の構造によって、変数の構造や変数パスが定義されますが、変数は作成されません。変数は、ステージでの割当てアクションの対象として実行時に作成されます。

一般的なプログラミング言語では、変数のスコープは静的です。変数の名前と型は明示的に宣言されます。静的なスコープ内の任意の場所から変数にアクセスできます。

Service Busにはいくつかの事前定義された変数が存在しますが、変数を動的に作成し、割当てアクションまたはforループ内のループ変数を使用して変数に値を割り当てることもできます。変数に値を割り当てると、パイプラインの任意の場所から変数にアクセスできるようになります。変数の型は宣言されませんが、原則として、任意の時点で変数に格納されている基礎になる値の型が変数の型になります。

注意:

forループの変数のスコープは制限されており、ステージ外からはアクセスできません。

インラインXQuery式エディタを使用すると、XQueryには0以上の入力と1つの出力が含まれます。式エディタ自体に入力と出力の構造を表示できるため、インラインXQueryを作成するときに、XMLスキーマまたはWSDLリソースを開いて構造を確認する必要はありません。構造が視覚的に表示されるため、作成中のXQueryに述部を指定せずに、child軸に沿って単純な変数パスをドラッグ・アンド・ドロップすることができます。

変数の構造のマッピングでは、各エントリはラベルを持ち、変数または変数パスを1つまたは複数の構造にマップします。これらのマッピングのスコープはステージまたはルート・ノードです。変数は静的に型指定されないので、1つの変数がステージまたはルート・ノードの様々な位置(または同じ位置)で複数の異なる構造を持つことができます。つまり、1つの変数または変数パスを複数の構造にマップし、それぞれに異なるラベルを使用することができます。構造を表示するには、リストで対応するラベルを選択します。

注意:

インラインXPath式エディタでも変数の構造のマッピングを作成できます。ただし、変数または変数パスは構造にマップされますが、構造から選択したときに生成されるXPathは、変数を基準にした相対XPathです。./ctx:attachment/ctx:bodyは、相対XPathの一例です。

12.13 サービスの品質

次の項では、Service Busメッセージングのサービス品質機能について説明します。

- 配信の保証

- アウトバウンド・メッセージの再試行

12.13.1 配信の保証

Service Busでは、信頼性のあるメッセージングがサポートされます。メッセージがルート・ノードから別のサービスにルーティングされるとき、プロキシ・サービスがトランザクションに対応するよう構成されている場合、デフォルトのサービス品質(QoS)は「必ず1回」で、それ以外の場合、「ベスト・エフォート」のQoSがサポートされます。

サービスの品質は、$outboundコンテキスト変数のqualityOfService要素で設定されます。

Service Busに用意されている配信の保証のタイプを表12-11に示します。

表12-11 配信の保証のタイプ

配信の信頼性

説明

必ず1回

「必ず1回」の信頼性では、アウトバウンド・メッセージの送信が開始されるまで終了エラーが発生しないことを前提として、メッセージがインバウンドからアウトバウンドに1回のみ配信されます。「必ず1回」は、信頼性が最適化されることを意味します。

「必ず1回」の配信の信頼性は提案であり、命令ではありません。「必ず1回」を指定すると、可能な場合に「必ず1回」の信頼性が提供されます。「必ず1回」が不可能な場合は、「1回以上」の配信セマンティクスが試行され、これも不可能な場合は「ベスト・エフォート」の配信が実行されます。

トランザクションに対応するよう構成されているプロキシ・サービスのサービス品質は、「必ず1回」です。

次のインバウンド・トランスポートでも、ルート・ノード・アクションのqualityOfService要素のデフォルト値はexactly-onceです。

- 電子メール

- FTP

- SFTP

- ファイル

- JMS(トランザクション対応)

- Tuxedo(トランザクション対応)

- MQ(バックアウトしきい値の設定が0)

- WS

注意: QoSが「必ず1回」の場合は、アウトバウンド・トランスポートを再試行しないでください。

1回以上

「1回以上」のセマンティクスは、アウトバウンド・メッセージの送信が開始されるまで終了エラーが発生しないことを前提として、メッセージがインバウンドからアウトバウンドに少なくとも1回は配信されることを意味します。ターゲット・サービスがトランスポートレベルのエラーとともに応答した場合でも、配信は成功と見なされます。ただし、タイムアウト、接続エラー、または通信リンクの中断が発生した場合は成功とは見なされません。フェイルオーバーURLが指定されている場合は、少なくとも1つのURLについて「1回以上」のセマンティクスが提供されます。

「必ず1回」が不可能であるが、qualityOfService要素がexactly-onceの場合は、「1回以上」の配信セマンティクスが試行されます。

ベスト・エフォート

「ベスト・エフォート」は、信頼性のあるメッセージングが存在せず、重複するメッセージが除去されないが、パフォーマンスは最適化されることを意味します。qualityOfService要素がbest-effortの場合に実行されます。「必ず1回」および「1回以上」の配信セマンティクスが不可能であるが、qualityOfService要素がexactly-onceの場合にも、「ベスト・エフォート」配信が実行されます。

次のインバウンド・トランスポートの場合、ルート・ノードのqualityOfService要素のデフォルト値はbest-effortです。

- HTTP

- JMS(トランザクション非対応)

- Tuxedo(トランザクション非対応)

- MQ(バックアウトしきい値の設定が0より大きい)

次の場合、qualityOfService要素のデフォルト値は常にbest-effortです。

- サービス・コールアウト・アクション - 常にbest-effortですが、必要に応じて変更できます。

- パブリッシュ・アクション - デフォルトはbest-effortで、変更可能
パブリッシュ・アクションでのQoSの動作の詳細は「トランスフォーメーションとパブリッシュ・アクション」を参照してください。

注意: パブリッシュ・アクションでqualityOfService要素の値がbest-effortの場合、すべてのエラーが無視されます。ただし、ルート・ノード・アクションまたはサービス・コールアウト・アクションでqualityOfService要素の値がbest-effortの場合は、すべてのエラーで例外が発生します。

他のトランスポートのサービス品質の詳細は、『Oracle Service Busでのサービスの開発』のトランスポートに関する項を参照してください。

12.13.1.1 デフォルト要素属性のオーバーライド

デフォルトの「必ず1回」のサービス品質属性をオーバーライドするには、アウトバウンド・メッセージのコンテキスト変数($outbound)でqualityOfServiceを設定する必要があります。詳細は、「メッセージ・コンテキスト・スキーマ」を参照してください。

次のパイプライン・アクションの場合、デフォルトのqualityOfService要素属性をオーバーライドできます。

- パブリッシュ

- 動的にパブリッシュ

- パブリッシュ表

- サービス・コールアウト

- ルーティング

- 動的ルーティング

- ルーティング表

qualityOfService要素属性をオーバーライドするには、前述の任意のアクションにルーティング・オプション・アクションを追加し、QoSオプションを選択し、オーバーライド値を選択します。

12.13.1.2 配信の保証のルール

パイプラインがメッセージをパブリッシュするか、リクエストをビジネス・サービスにルーティングするときは、次の条件に応じて配信の保証がサポートされます。

- qualityOfService要素の値

- インバウンド・トランスポート(および該当する場合は接続ファクトリ)

- アウトバウンド・トランスポート(および該当する場合は接続ファクトリ)

ただし、インバウンド・プロキシ・サービスがローカル・トランスポートで、呼出し元が別のプロキシ・サービスである場合、呼出し元のプロキシ・サービスのインバウンド・トランスポートが配信の保証を行います。呼び出されたプロキシ・サービスのトランスポートがローカル・トランスポートの場合、呼出し元のプロキシ・サービスが最適化されて、直接呼出しになるためです。トランスポート・プロトコルの詳細は、「プロキシ・サービスの作成と構成」および「ビジネス・サービスの作成と構成」を参照してください。

注意:

プロキシ・サービスからのレスポンスには配信の保証はありません。

配信の保証に適用されるルールを表12-12に示します。

表12-12 配信の保証のルール

提供される配信の保証

ルール

必ず1回

プロキシ・サービスのインバウンド・トランスポートはトランザクションに対応し、アウトバウンド・トランスポートへのqualityOfService要素の値はexactly-onceです。

1回以上

プロキシ・サービスのインバウンド・トランスポートはファイル、FTPまたは電子メールで、qualityOfService要素の値はexactly-onceです。

1回以上

プロキシ・サービスのインバウンド・トランスポートはトランザクションに対応し、トランザクション非対応のアウトバウンド・トランスポートへのqualityOfService要素の値(該当する場合)はexactly-onceです。

配信の保証なし

その他の場合(すべてのレスポンス処理を含む)。

注意:

JMSにより配信の保証として「1回以上」および「必ず1回」をサポートするには、JMSトランザクションを利用し、サーバーがクラッシュした場合、または返信アクションや再開アクションのエラー・ハンドラで処理できないエラーが発生した場合にメッセージを再配信できるように、JMSキューの再試行回数と再試行間隔を構成する必要があります。ファイル、FTP、および電子メール・トランスポートでも、内部ではJMS/XAキューが使用されます。JMS/XAトランスポートを使用したプロキシ・サービスのデフォルトの再試行回数は1です。

配信の保証のその他のルールは次のとおりです。

- インバウンド・プロキシ・サービスのトランスポートでトランザクションが伝播または開始される場合、リクエスト処理は1つのトランザクションで実行されます。

- qualityOfService要素がexactly-onceに設定されている場合、トランザクション対応の宛先へのリクエスト・フローで実行されるルート・ノード・アクションは、すべて同一トランザクションで実行されます。トランザクション・コンテキスト内のパブリッシュ・アクションとサービス・コールアウト・アクションは、デフォルトではbest-effortであるため、トランザクション・コンテキスト外で実行されます。これらのアクションを「必ず1回」に設定すると、トランザクション・コンテキスト内で実行されます。

- ルート・ノードの任意のアクションのqualityOfService要素がbest-effortに設定されている場合、サービス・コールアウト・アクションまたはパブリッシュ・アクションは、リクエスト・フロー・トランザクションの外部で実行されます。具体的には、JMS、Tuxedo、トランザクション対応のTuxedo、またはEJBの各トランスポートで、リクエスト・フロー・トランザクションが中断されます。トランザクション対応のTuxedoの処理はトランザクションなしで実行されるか、すぐにコミットされる別のトランザクションで実行されます。

- リクエストの処理中にエラーが発生しても、(再開アクションまたは返信アクションを使用して)エラーを管理するユーザーのエラー・ハンドラで捕捉されると、メッセージは正常に処理されたと見なされ、トランザクションはコミットされます。トランザクションが中断されるのは、システム・エラー・ハンドラがエラーを受け取る場合、つまりエラーが処理されずにシステム・レベルに届く場合です。また、リクエスト・パイプラインの処理中にサーバー障害が発生した場合もトランザクションが中断されます。

- ビジネス・サービスに対してJMS/XAトランスポートを使用するプロキシ・サービスがレスポンスを受信する(かつプロキシのインバウンドがトランザクション対応のTuxedoではない)場合、レスポンス処理は1つのトランザクションで実行されます。

- qualityOfService要素が exactly-onceに設定されている場合、すべてのルート・アクション、サービス・コールアウト・アクション、およびパブリッシュ・アクションは同じトランザクションで実行されます。

- qualityOfService要素がbest-effortに設定されている場合、すべてのパブリッシュ・アクションとサービス・コールアウト・アクションは、レスポンス・フロー・トランザクションの外部で実行されます。特に、JMS、EJB、またはトランザクション対応のTuxedoのタイプのトランスポートの場合、レスポンス・フロー・トランザクションは中断され、サービス呼出しの処理はトランザクションなしで、またはすぐにコミットされる別のトランザクションで実行されます。

- JMS/XA宛先へのレスポンス・フローで実行されるプロキシ・サービスのレスポンスは、qualityOfService要素の設定に関係なく、常に同じトランザクションで実行されます。

- プロキシ・サービスのインバウンド・トランスポートがトランザクション対応のTuxedoであるか、プロキシ・サービスの「レスポンスに同じトランザクション」オプションを設定している場合、リクエスト処理とレスポンス処理はともにこのトランザクションで実行されます。

注意:

インバウンド・トランスポートがトランザクション対応のTuxedoで、アウトバウンドがJMS/XAなどの非同期トランスポートの場合、ランタイム・エラーが発生します。

12.13.1.3 スレッド・モデル

Service Busのスレッド・モデルは次のように作動します。

- プロキシ・サービスのリクエストおよびレスポンスのパイプラインは、常に個別のスレッドで実行されます。

- 外部サービスを呼び出すと、スレッドはパイプライン・アクションに応じてサービス品質オプションおよび使用するトランスポートをブロックする場合があります。
サービス・コールアウトは常にブロックします。qualityOfService要素の値がbest-effortの場合、HTTPルート・アクションまたはパブリッシュ・アクションはブロックしません(リクエスト/レスポンスまたは一方向呼出しの場合)。

JMSルート・アクションまたはパブリッシュ・アクションは常にブロックしません。ただし、Service Busには永続メッセージ処理状態がないため、リクエストが送信された後でサーバーが再起動するとレスポンスが失われます。

注意:

リクエスト・フローまたはレスポンス・フローのパブリッシュ・アクションでは、レスポンスは常に破棄されます。これは、パブリッシュ・アクションは本質的に一方向のメッセージ送信であるためです 。

- ブロッキング・コールを使用する場合、サーバー・デッドロックを回避するため、最小スレッド数制約のあるワーク・マネージャをレスポンスに関連付ける必要があります。最小スレッド数制約により、処理する最小スレッド数が保証されます。
ワーク・マネージャの一般情報は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。Service Busのワーク・マネージャおよびスレッディングの詳細は、「ワーク・マネージャとスレッド」を参照してください。

12.13.1.4 プロキシ・サービスの分割

次の場合に、プロキシ・サービスの分割を検討してください。

- HTTPがプロキシ・サービスのインバウンドおよびアウトバウンド・トランスポートであるとき、パイプラインの途中に高信頼性を組み込みます。このようにして高信頼性を実現するには、プロキシ・サービスを、フロント・エンドHTTPプロキシ・サービスと、HTTPアウトバウンド・トランスポートを使用するバックエンドJMS (一方向またはリクエスト/レスポンス)プロキシ・サービスに分割します。エラー発生時には、メッセージの損失を回避できるように、最初のプロキシ・サービスがメッセージを2番目のプロキシ・サービスのキューにすぐに入れる必要があります。

- プロキシ・サービス(たとえばloanGateway1)が別のプロキシ・サービス(たとえばloanGateway2)を呼び出すときに、JMS以外のトランスポートについて直接呼出しの最適化を無効にするには次のようになります。プロキシ・サービスloanGateway1からプロキシ・サービスloanGateway2にルーティングします(プロキシ・サービスloanGateway2がJMSトランスポートを使用する場合)。

- HTTPプロキシ・サービスでJMSキューにパブリッシュするときに、リクエスト処理において後で例外が発生した場合にパブリッシュ・アクションをロールバックするには、プロキシ・サービスをフロント・エンドHTTPプロキシ・サービスとバックエンドJMSプロキシ・サービスに分けます。パブリッシュ・アクションでは、qualityOfService要素にexactly-onceを指定し、XA接続ファクトリを使用します。

12.13.2 アウトバウンド・メッセージの再試行

JMSを使用してメッセージのインバウンドの再試行を構成するだけでなく、アウトバウンドの再試行およびロード・バランシングも構成できます。ロード・バランシング、フェイルオーバー、および再試行の組合せによって、パフォーマンスと高可用性を実現できます。各メッセージのフェイルオーバーURLとして指定したURLのリストは、ロード・バランシング・アルゴリズムに基づいて自動的に並べ替えられ、フェイルオーバーのシーケンスが形成されます。再試行回数がNの場合、シーケンス全体がN回再試行されてから終了します。システムは指定された再試行間隔の時間だけ待機してから、シーケンスの次のループを開始します。再試行回数が完了してもまだエラーがある場合、ルート・ノードのエラー・ハンドラ・パイプラインが呼び出されます。

注意:

HTTPトランスポートの場合、Service Busでは200または202以外のHTTPステータスはエラーと見なされるため、再試行する必要があります。このアルゴリズムにより、Service Busでは、解決することのできない認証エラーなどのエラーを、そのURLで一定期間再試行することが可能です。これに対して、Service Busで任意のメッセージの送信を再試行するときに別のURLにフェイルオーバーする場合は、新しいURLではエラーにならない可能性があります。

quality of serviceがexactly-onceの場合、フェイルオーバーや再試行は行われません。

12.14 JavaScriptアクションおよびJavaScript式の使用

Service Busは、パイプラインで使用されるJavaScriptアクションを提供します。JavaScriptアクションを使用すると、パイプライン処理中に実行されるJavaScriptコードのスニペットを含めることができます。

JavaScriptを使用する最も一般的なケースは、RESTサービスでJSONオブジェクトを扱う場合です。ペイロードをXMLに変換して操作にXQueryまたはXSLTを使用するかわりに、JavaScriptを使用すると、JSONオブジェクトを直接操作できます。Service Busで使用されるJavaScriptエンジンでは、簡単にXML要素を参照し、JSONとXMLスタイルのペイロードをJavaScriptで簡単に処理できるようになります。

JavaScriptはRESTサービスのみに限定されず、どのようなサービスでもJavaScriptを使用できます。また、JavaScriptは評価用に式を作成するその他の領域でも使用できます。

ヒント:

JavaScriptアクションは、ネイティブRESTパイプラインに限定されず、どのようなパイプライン・タイプでも使用できます。

JavaScriptのオープン・ソース実装であるRhinoは全体がJavaで記述されており、Service Busで使用されるJavaScriptエンジンです。https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhinoを参照してください

JavaScriptによるメッセージ・コンテキストからの変数バインディング取得、および新しい変数バインディングでのメッセージ・コンテキスト更新を促進するため、Service Busでは、変数値の読取り/更新に使用するJavaScriptエンジン構成を使用します。スクリプトを呼び出す前に、Service Busでは、変数値の読取りと更新に使用する、processと呼ばれるグローバル・スコープのオブジェクトをバインドします。式に変数を呼び出すには、process.bodyやprocess.xyzなど、ドット(.)の表記法を使用します。

式process.varNameは次のいずれかを返します。

- 変数がJSONの場合、式はJSONスクリプト可能オブジェクトを返します

- 変数がXMLの場合、式はE4X (JavaScript XML)形式のXMLまたはXMLListオブジェクトを返します

- String

- ブール値

たとえば、次のような受信リクエスト・ペイロードです。

{
"employees": [
{ "firstName":"John" , "lastName":"Doe" },
{ "firstName":"Anna" , "lastName":"Smith" },
{ "firstName":"Peter" , "lastName":"Jones" }
]
}

JavaScriptエンジンで想定されているJSON固有のPOJOモデルに解析され、$body変数としてバインドされます。次のようにスクリプトで式を使用します。

var $body  = process.body;
var name = $body.employees[0].firstName + ” “ + $body.employees[0].lastName

文字列John Doeを含みます。

変数$fooが次のXMLにバインドされている場合:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22rdfsyntaxns#" xmlns="http://purl.org/rss/1.0/">
<rdf:item value="5"/>
<rdf:textNode>Hello World</rdf:textNode>
<item value="10"/>
<rdf:item>17</rdf:item>
</rdf:RDF>

および、接頭辞rdfとrssが実行スコープに定義されており、ステージ・コンテキストからマップされているか、JavaScriptスニペットで次の方法で明示的に宣言されている場合:

var rdf = new Namespace("http://www.w3.org/1999/02/22-rdf-syntax-ns#");
var rss = new Namespace("http://purl.org/rss/1.0/");

次の例に示すJavaScript式が考えられます。

process.foo.rdf::item.@value  =>  5
process.foo.rdf::textNode.text() => “Hello World”
process.foo.rss::item.@value => 10
process.foo.rdf::item[1].text() => 17

次のE4X式がインバウンドHTTP Content-Typeヘッダーの値を返します。

process.inbound.ctx::transport.ctx::request.tp::headers.http::[“Content-Type”].text()

注意:

XML要素名にハイフンがあるため、前述の例でContent-Typeを囲む大カッコが表示されます。ハイフンはXML要素で有効ですが、JavaScript識別子の名前には使用できません。SOAPActionなど、一部のヘッダーでは大カッコは不要です。たとえば、http::SOAPActionが有効です。同じ理由から、fn-beaやsoap-envなど、ハイフンのある既知のネームスペースの接頭辞は、かわりにfn_bea::bar.fn_bea::zot.text()のように、下線でエンジンにバインドされます。

前述の例では、Service Busは、XQuery式やXPath式の場合と同様に、識別子(ctx、tp、およびhttp)を対応するネームスペースURIに自動的に宣言します。

たとえば、次のE4X式では、インバウンドHTTPレスポンス・コード値を設定します。

process.inbound.ctx::transport.ctx::response.http::["http-response-code"] = 202;

12.14.1 JavaScriptアクションおよびメッセージ・コンテキスト変数

Service Busメッセージ・コンテキスト変数は、JavaScriptアクションで使用し、更新できます。

JavaScriptアクションは、次のメッセージ・コンテキスト変数のタイプを使用できます。

- XML

- XMLList (たとえば、SOAP Doc Literalスタイルで複数ルート要素を持つ$body)

- String

- ブール値

- JSON

注意:

JavaScript式では、JSON POJOへのテキストの解析に言語機能JSON.parse()を使用する必要があります。

JavaScriptアクションは、次のメッセージ・コンテキスト変数のタイプを更新できます。

- XML

- XMLList

- String

- ブール値

- JSON

12.14.2 JavaScript式を使用したコンテキスト変数の更新

Service Busメッセージ・コンテキスト変数の更新には、JavaScriptアクションを使用できます。

$bodyコンテンツをJSONオブジェクトに更新するには、次のいずれかの式を使用します。

- process.body = JSON.parse(‘{“example1” : “example2”});

- process.body = { “example1” : “example2” };

注意:

次のメソッドのみを使用して、JSON入力済変数をパイプラインに作成できます。

- JSONペイロードの入力済ネイティブRESTサービスへの送信($body内)

- JavaScriptアクションを使用したJSONオブジェクトの変数への割当て

$bodyコンテンツをXMLに割り当てるには、process.body = <example />;のような式を使用します。

$bodyコンテンツをテキストに更新するには、process.body = “example”;のような式を使用します。

$bodyコンテンツを<example1/>および<example2/>などの要素を含むXMLリストに更新するには、process.body = <> <example1/><example2/> </>;のような式を使用します。

12.14.3 JavaScript式を使用した変数の作成

変数はJavaScriptアクションのJavaScript式を使用して作成できます。

Service Busメッセージ・コンテキスト内で変数を作成するには、次のような式を使用します。

process.newVar = …;

12.14.4 JavaScript式を使用した変数の削除

JavaScript式を使用して、メッセージ・コンテキスト変数を削除できます。

変数を削除するには、JavaScript削除演算子を使用します。

delete process.var;

たとえば、次の式を使用すると、JSON要素を削除できます。

delete process.jsonvar2.foo;

次の式を使用すると、構造からXML要素や属性を削除できます。

delete process.xmlvar2.(@number='1234').name.first;

12.14.5 XQuery、XPath、およびJSON変数について

JSON変数は、その文字列式とともにXQueryエンジンにバインドされています。

次の例は、XQueryエンジンにバインドされているJSON変数を示します。

process.foo = { "foo" : "bar" }

$fooをXQueryリソースへの入力引数として指定した場合、XQueryエンジンは値"{ "foo" : "bar" }"を受け取ります。

注意:

JSON変数に関連するXPath式の実行はサポートされていません。実行すると、ランタイム・エラーが発生します。

12.14.6 ストリーミング$body変数およびJavaScriptアクション

JavaScriptアクションを使用したストリーミング$bodyコンテンツの読取りと書込みは推奨されていません。

かわりに、割当てアクションや置換アクションなど、XMLペイロードの読取り、または操作用のストリーミングXQueryエンジンを使用するパイプライン・アクションを使用する必要があります。

ただし、JavaScriptアクションを使用してストリーミング$bodyコンテンツを問い合せる場合、$bodyのコンテンツは完全にマテリアライズされ、E4Xファサードでエンジンにバインドされます。

12.14.7 JavaScriptアクションおよびカスタムJava関数

前のバージョンのService Busでは、カスタムJava関数の登録、およびこれらのカスタム関数のXQuery式XPath式からの呼出しがサポートされていました。このバージョンのService Busでは、これらと同じ関数のJavaScript式からの呼出しをサポートしています。

次の例に、JavaScript式から呼び出されるカスタムJava関数を示します。

isAdmin = IsUserInRoleFunction.isUserInRole($body.users[0].userName, "Admin");

Service Busランタイムは、すべての登録済カスタム関数のパッケージを自動的にインポートするよう拡張されています。これらの関数を使用するときに、式にimportPackage()構造を使用する必要はありません。また、JavaScript式は、Service Bus構成ディレクトリで、カスタムJava関数jarのクラスを含むクラス・ローダーのコンテキストで実行されます。

12.14.8 JavaScript式の結果のロギングおよびレポート

JavaScript式の結果のロギングおよびレポートがサポートされています。

式の結果は、次の例に示すようにロギングできます。

process.myJsonVar.Orders.items[0].name
or
process.xmlvar2.(@number='1234').name.first
or
process.myJsonVar.Orders.items[0].name.length() > 56

12.15 Service Busでのワーク・マネージャの使用

WebLogic Serverは、アプリケーションとWebサービス環境のパフォーマンスを最適化し、ワーク・マネージャという機能を使用してサービス・レベル合意を保持する際に役立ちます。ワーク・マネージャのリソースを作成し、作業実行ルールを定義することによって、作成したリソースを構成します。WebLogic Serverではワーク・マネージャのルールを使用して、作業の優先順位を付け、ワーク・マネージャが配置されているどのようなアプリケーションやコンポーネントにもスレッドを割り当てることができます。

ワーク・マネージャの一般情報は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。Service Busのワーク・マネージャおよびスレッディングの詳細は、「ワーク・マネージャとスレッド」を参照してください。

Service Busでは、プロキシ・サービスおよびビジネス・サービスのいくつかのトランスポートで、ワーク・マネージャとサービスを関連付けてサービス作業の優先順位を付けることができる、「ディスパッチ・ポリシー」という構成オプションが提供されます。この項では、プロキシ・サービスとビジネス・サービスでワーク・マネージャを使用する方法について説明します。

Service Busプロキシ・サービスのディスパッチ・ポリシーを構成することで、起動とリクエスト・パイプラインの実行はワーク・マネージャのルールによって制御されます。たとえば、最大制約が5のディスパッチ・ポリシーを使用したプロキシ・サービスの場合、そのプロキシ・サービスでは同時に5つのリクエスト・パイプライン・タスクしか実行できません。

リクエスト・パイプラインがプロキシ・サービスのディスパッチ・ポリシーによって制御されるのに対し、レスポンス・パイプラインはビジネス・サービスまたは分割-結合のディスパッチ・ポリシーによって制御されます。RouteToアクションでは、メッセージのルーティング先のビジネス・サービスまたは分割-結合を指定し、レスポンスには指定したビジネス・サービスまたは分割-結合のすべてのディスパッチ・ポリシーが適用されます。

RouteToアクションでローカル・プロキシ・サービスを指定した場合、元のプロキシのディスパッチ・ポリシーがローカル・プロキシのリクエスト・パイプラインで実行される作業に適用されます。ローカル・プロキシまたはローカル・プロキシのチェーンが、ビジネス・サービスまたは分割-結合を呼び出すRouteToアクションに達すると、ビジネス・サービス、分割-結合および後続のすべてのレスポンス・パイプラインが、呼び出されたビジネス・サービスまたは分割-結合のディスパッチ・ポリシーによって制御されます。

リクエストでエラーが発生すると、エラー・レスポンスは同じスレッド内でリクエスト・パイプラインとして処理されます。

アウトバウンド・メタデータで指定したサービス品質(QoS)は、リクエストをスレッド化する方法に影響を与える可能性があるため、ワーク・マネージャを監視する際の表示内容にも影響します。RouteToアクションでのQoSは、デフォルトではインバウンドQoSに設定されています。たとえば、JMS/XA、SB、Tuxedo、WS(WS-RM)などトランザクション対応の一部のインバウンド・トランスポートでは、QoSは「必ず1回」に設定されます。HTTPなどのその他のインバウンド・トランスポートでは、QoSはデフォルトで「ベスト・エフォート」に設定されます。RouteToアクションでのQoSは、RouteToアクションのユーザー設定でオーバーライドされない限り、インバウンドから継承されます。

「ベスト・エフォート」を使用すると、ルート・ノードはビジネス・サービスを非同期に呼び出します。「ベスト・エフォート」の場合は、ワーク・スレッドはプールに戻され、レスポンスを待機しないため、非同期に戻される予定の保留中の作業がある場合でも、ワーク・マネージャの制約に対してスレッドがカウントされることはありません。しかし、「必ず1回」を選択すると、リクエスト・スレッドによってリクエストが送信され、レスポンスの待機がブロックされて、ワーク・マネージャの制約に対してスレッドがカウントされます。「必ず1回」の場合は、待機中のスレッドはプロキシ・サービスに割り当てられたワーク・マネージャに適用されます。肯定レスポンスが届くと、新規スレッドにより、ビジネス・サービスまたは分割-結合に割り当てられたディスパッチ・ポリシーを使用して、そのレスポンス・パイプラインが処理されます。

「必ず1回」を指定することは、パフォーマンス、メモリーおよびスレッドの視点から費用がかかりますが、トランザクション対応のインバウンド・リソースおよびアウトバウンド・リソースにおける整合性を維持するためには必要です。

QoSの詳細は、「サービスの品質」を参照してください。

12.16 コンテンツ・タイプ、JMSタイプ、およびエンコーディング

Service Busでは、異種のエンドポイント間での相互運用性を確保するため、使用するコンテンツ・タイプ、JMSタイプおよびエンコーディングをそれぞれ制御できます。

Service Busでは外部のクライアントまたはサービスに必要な情報が想定されませんが、サービス定義で構成済の情報が使用されます。アウトバウンド・メッセージのコンテンツ・タイプは、サービス・タイプとインタフェースから派生します。コンテンツ・タイプは、電子メールおよびHTTPプロトコルの一部です。

サービス・タイプごとのコンテンツ・タイプを次に示します。

- XMLまたはSOAP (WSDLファイルの有無を問わない)の場合、コンテンツ・タイプはtext/XML。

- インタフェースがMFLまたはバイナリのメッセージングの場合、コンテンツ・タイプはbinary/octet-stream。

- インタフェースがテキストのメッセージングの場合、コンテンツ・タイプはtext/plain。

- インタフェースがXMLのメッセージングの場合、コンテンツ・タイプはtext/XML

- インタフェースがJavaのメッセージングの場合、コンテンツ・タイプはJavaオブジェクト。

また、JMSタイプには、Java型以外のメッセージ用のバイトまたはテキストを指定できます。Oracle Service BusコンソールまたはOracle JDeveloperでサービスを定義するときに使用するJMSタイプを構成します。

サービスを呼び出すプロキシ・サービスのアウトバウンド・コンテキスト変数($outbound)のコンテンツ・タイプ、およびプロキシ・サービス・レスポンスのインバウンド・コンテキスト変数($inbound)のコンテンツ・タイプはオーバーライドできます。$outboundコンテキスト変数と$inboundコンテキスト変数の詳細は、「inbound変数とoutbound変数」を参照してください。

すべてのアウトバウンド・メッセージのエンコーディングも、サービス定義で明示的に構成します。サービス定義の詳細は、「プロキシ・サービスの作成と構成」および「ビジネス・サービスの作成と構成」を参照してください。

12.17 抑制パターン

Service Busでは、ビジネス・サービスへのメッセージ・フローを制限できます。このビジネス・サービスへのメッセージ・フローを制限する技術は、スロットルと呼ばれます。詳細は、『Oracle Service Busの管理』のメッセージ抑制に関するビジネス・サービスの構成に関する項を参照してください。

12.18 WS-Iへの準拠

Service Busは、実行時環境でSOAP 1.1サービスへのWebサービス相互運用性(WS-I)準拠を提供します。WS-Iの基本プロファイルの目的を次に示します。

- WSDLとSOAPの仕様の曖昧な部分を明確にします。

- 相互運用性を拡張するために、メッセージの受信やWSDLファイルのインポートに適用できる制約を定義します。メッセージを送信するときは、制約を満たすようにメッセージを構成します。

WS-I基本プロファイルは、http://www.ws-i.org/Profiles/BasicProfile-1.1.htmlにあります。

プロキシ・サービスまたはビジネス・サービスをWSDLファイルに基づいて構成するとき、Oracle Service BusコンソールまたはOracle JDeveloperを使用すると、Service Busでそのサービスに対してWS-I準拠を適用するかどうかを指定できます。詳細は、「ビジネス・サービスのセキュリティおよびセキュリティ・ポリシー」を参照してください。

プロキシ・サービスのWS-I準拠を構成すると、そのプロキシ・サービスが受信するインバウンド・リクエスト・メッセージでチェックが実行されます。呼び出されたサービスについてWS-I準拠を構成すると、その呼び出されたサービスからのレスポンス・メッセージを任意のプロキシが受信したときに、チェックが実行されます。デフォルトでは、プロキシ・サービスのSOAPクライアントはシステム・エラー・ハンドラ定義のエラーを受け取るため、このようなエラーに対応するエラー・ハンドラを作成することをお薦めします。

プロキシ・サービスから送信されるメッセージについては、それがアウトバウンド・リクエストでもインバウンド・レスポンスでも、WS-I準拠のチェックは明示的には実行されません。これは、ほとんどのメッセージ・コンテンツの生成はパイプライン設計者によって行われるためです。ただし、メッセージのService Busによって生成されるパートは、サポートされるWS-I準拠のすべてのチェックを満たします。次のコンテンツが含まれます。

- サービス呼出しリクエスト・メッセージ

- プロキシ・サービスによって返されるシステム生成のエラー・メッセージ

- プロキシ・サービスによって生成されるHTTPステータス・コード

「WS-I準拠の適用」チェック・ボックスは、図12-3のように表示されます。

図12-3 「WS-I準拠の適用」チェックボックス

12.18.1 WS-I準拠チェック

注意:

WS-I準拠チェックでは、サービスで呼び出される操作をシステムが認識する必要があります。つまり、プロキシ・サービスが受信するリクエスト・メッセージでは、コンテキスト変数$operationはnull以外の値であることが必要です。そのためには、操作選択アルゴリズムが適切に構成されていることが前提になります。呼び出されたサービスから受信するレスポンス・メッセージでは、ルート、パブリッシュ、およびサービス・コールアウトのアクション構成で操作が指定されている必要があります。

プロキシ・サービスまたはビジネス・サービスのWS-I準拠チェックを構成すると、Service Busで表12-13に示すチェックが実行されます。

表12-13 Service BusのWS-I準拠チェック

チェック

WS-I基本プロファイルの詳細

Service Busの説明

3.1.1 SOAPエンベロープ構造

R9980 エンベロープは、SOAP 1.1、第4項「SOAP Envelope」に指定された構造に準拠する必要があります(修正対象)。

このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。レスポンス・メッセージがチェックされ、メッセージに外部Envelopeタグがない場合、soap:clientエラーが生成されます。メッセージがEnvelopeタグだが、別のネームスペースがある場合、3.1.2 SOAPエンベロープ・ネームスペースによって処理されます。

3.1.2 SOAPエンベロープ・ネームスペース

R1015 受信側は、ドキュメント要素がsoap:Envelopeでないエンベロープを検出した場合にエラーを生成する必要があります。

このチェックはリクエスト・メッセージとレスポンス・メッセージに適用されます。これは、3.1.1 SOAPエンベロープ構造に関連しています。リクエスト・メッセージのローカル名がEnvelopeであるが、ネームスペースがSOAP 1.1でない場合、soap:VersionMismatchエラーが生成されます。

3.1.3 SOAP Bodyのネームスペース修飾

R1014 エンベロープのsoap:body要素の子要素は、ネームスペースで修飾する必要があります。

このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。すべてのリクエスト・エラー・メッセージでsoap:Clientエラーが生成されます。

3.1.4 許可されない構成

R1008 エンベロープは文書型宣言を含むことはできません。

このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。すべてのリクエスト・エラー・メッセージでsoap:Clientエラーが生成されます。

3.1.5 SOAPトレーラ

R1011 エンベロープでは、soap:body要素の後にsoap:Envelopeの子要素を持つことはできません。

このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。すべてのリクエスト・エラー・メッセージでsoap:Clientエラーが生成されます。

3.1.9 SOAP 1.1要素のSOAP属性

R1032 エンベロープのsoap: Envelope、soap:header、およびsoap:body要素は、ネームスペースhttp://schemas.xmlsoap.org/soap/envelope/の属性を持つことはできません。

このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。任意のリクエスト・エラー・メッセージでsoap:clientエラーが生成されます。

3.3.2 SOAP Faultの構造

R1000 エンベロープがFaultの場合、soap: Fault要素は、faultcode、faultstring、faultactor、およびdetail以外の要素の子を持つことはできません。

このチェックは、レスポンス・メッセージのみに適用されます。

3.3.3 SOAP Faultのネームスペース修飾

R1001 エンベロープがFaultの場合、soap:Fault要素の子要素は修飾されません。

このチェックは、レスポンス・メッセージのみに適用されます。

3.4.6 HTTPクライアント・エラー・ステータス・コード

R1113 HTTPリクエスト・メッセージの形式に誤りがある場合、インスタンスは「400 Bad Request」HTTPステータス・コードを使用する必要があります。

R1114 HTTPリクエスト・メッセージの形式に誤りがある場合、インスタンスは「405 Method not Allowed」HTTPステータス・コードを使用する必要があります。

R1125 リクエストのフォーマットに問題があることを示すレスポンスについては、インスタンスは4xx HTTPステータス・コードを使用する必要があります。

リクエストのエラーで返されるステータス・コードを変更できない場合、プロキシ・サービスのレスポンスのみに適用されます。

3.4.7 HTTPサーバー・エラー・ステータス・コード

R1126 レスポンス・エンベロープがFaultの場合、インスタンスは「500 Internal Server Error」HTTPステータス・コードを返す必要があります。

このチェックは、リクエスト・メッセージとレスポンス・メッセージに別の方法で適用されます。リクエスト・メッセージの場合、生成されたフォルトには「500 Internal Server Error」HTTPステータス・コードが含まれます。レスポンス・メッセージの場合、「500 Internal Server Error」HTTPステータス・コードのないフォルト・レスポンスが受信されると、エラーが生成されます。

4.7.19 レスポンス・ラッパー

R2729 rpc-literalバインディングで記述されたエンベロープがレスポンスである場合、対応するwsdl:operationの名前に文字列Response.が接尾辞として付いた名前のラッパー要素が必要です。

このチェックは、レスポンス・メッセージのみに適用されます。Service Busでは、プロキシ・サービスからfault以外のレスポンスを生成することはありません。

4.7.20 パート・アクセッサ

R2735 rpc-literalバインディングで記述されたエンベロープでは、ネームスペースにないパラメータと戻り値のパート・アクセッサ要素を配置する必要があります。

R2755 rpc-literalバインディングで記述されたメッセージのパート・アクセッサ要素は、対応するwsdl:part要素のname属性と同じ値のローカル名を持つ必要があります。

このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。任意のリクエスト・エラー・メッセージでsoap:clientエラーが生成されます。

4.7.22 必須ヘッダー

R2738 エンベロープは、エンベロープを記述するwsdl: bindingのwsdl: operationのwsdl: inputまたはwsdl: outputに指定された、すべてのsoapbind:headersを含む必要があります。

このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。任意のリクエスト・エラー・メッセージでsoap:clientエラーが生成されます。

4.7.25 SOAPActionの記述

R2744 HTTPリクエスト・メッセージは、SOAPAction HTTPヘッダー・フィールドに、soap:operationのsoapAction属性の値と等しい、引用符で囲まれた値を含む必要があります(対応するWSDL記述にこの値が存在する場合)。

R2745 HTTPリクエスト・メッセージは、SOAPAction HTTPヘッダー・フィールドに、引用符で囲まれた空の文字列値を含む必要があります(対応するWSDL記述に、soapbind:operationのSOAPActionが存在しない場合、または値が空の文字列で存在する場合)。

このチェックはリクエスト・メッセージに適用され、soap:clientエラーが返されます。

12.19 SOAP 1.1とSOAP 1.2との間の変換

Service Busは、SOAP 1.1とSOAP 1.2をサポートしています。SOAP 1.1プロキシ・サービスでSOAP 1.2ビジネス・サービスを呼び出すことも、その逆の呼出しを行うこともできます。しかし、SOAP 1.1と1.2に違いがあるため、Service Busは一部の状況で2つのSOAP間での自動変換を実行できません。SOAP 1.1と1.2の変換を適切に使用するには、次のガイダンスを使用してください。

- ビジネス・サービスを呼び出す前に、Service BusによりSOAPネームスペースは自動的に変更されます。ビジネス・サービスからフォルトが返された場合、プロキシ・サービスのSOAPバージョンに自動的に変更されます。ただし、この処理は2つのバージョン間のSOAPヘッダー関連のXML属性(MustUnderstandなど)をマップするパイプライン・アクションに依存します。また、エンコードされたエンベロープのSOAPエンコードされたネームスペースの変更も、パイプライン・アクションに依存します。

- ペイロードがdoc/またはrpc/リテラル・エンコーディングを使用する場合のみ、SOAP 1.1からSOAP 1.2での自動変換が正常に機能します。

- SOAP 1.1では、encodingStyle属性はエンベロープの任意の要素に許可されます。SOAP 1.2では、encodingStyle属性は本文の子要素のみ許可されます。SOAP 1.1のencodingStyle属性が本文の子要素、ヘッダー、およびフォルト詳細以外で存在する場合、SOAP 1.1からSOAP 1.2への自動的な変換によって、無効エンベロープが生じる場合があります。有効なエンベロープを確保するには、プロキシ・サービス・パイプラインでSOAP変換を実行する必要があります。

- SOAP 1.1とSOAP 1.2サービスがrpc/encodedからdoc/literalなど、異なるエンコーディング・スタイルを使用している場合、プロキシ・サービス・パイプラインでSOAP変換を実行する必要があります。

13 Oracle Service Busコンソールでのパイプラインの操作

この章では、Oracle Service Busコンソールを使用してパイプラインまたはメッセージ・フローを作成および構成する方法について説明します。この項には、パイプライン・ペア、条件付きブランチ、ステージ、オペレーション・ブランチおよびルート・ノードの作成および構成が含まれます。

- Oracle Service Busコンソールのパイプライン・デザイナの概要

- コンソールでのパイプラインの表示と編集

- ステージおよびルート・ノードの切取り、コピー、貼付け

- コンソールでのリシーケンサの構成

- 変数の構造のマッピングの作成

パイプラインおよびそれらのコンポーネントの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。

13.1 Oracle Service Busコンソールのパイプライン・デザイナの概要

パイプライン・デザイナでは、アクションを作成および構成する際、メッセージ・フローがグラフィカルに表示されます。

- コンソールの「メッセージ・フローの編集」ページ

- コンソールの「ステージ構成の編集」ページ

13.1.1 コンソールの「メッセージ・フローの編集」ページ

「メッセージ・フローの編集」ページを使用して、パイプラインのメッセージ・フローを作成します。

「メッセージ・フローの編集」ページの左側のナビゲーション・ペインに、パイプライン内のノードとオブジェクトのツリー・ビューが表示されます。オブジェクトの詳細が別のページで定義されている場合は、オブジェクトの名前をクリックして、関連付けられているページを表示できます。

右側のペインには、パイプラインを作成するためのフィールドが表示されます。メッセージ・フローがまだ定義されていない場合、ペインには、パイプラインの開始ノードを示す1つの「パイプライン」アイコンがあります。アイコンをクリックして、サービスのパイプライン・ペア・ノード、ルート・ノード、条件付きブランチ、操作ブランチ、およびエラー処理を追加します。

ページにオブジェクトを追加すると、そのオブジェクトを示すアイコンがページに表示されます。オブジェクト間の関係は、線と境界を示す四角形で示されます。「メッセージ・フローの編集」ページのアイコンをクリックすると、そのオブジェクトで実行できるアクションのメニューが表示されます。メニューに含まれるオプションは、コンテキストに応じて異なります。アイコンとオプションの完全なリストについては、表13-1を参照してください。

表13-1 「メッセージ・フローの編集」ページのアイコンとオプション

アイコン

説明

メニュー・オプション

パイプライン

パイプラインの開始ノード。

- パイプライン・ペアの追加 - 「パイプラインへのパイプライン・ペアの追加方法」を参照してください。

- ルートの追加 - 「コンソールでのパイプラインへのルート・ノードの追加方法」を参照してください。

- 条件付きブランチの追加 - 「コンソールでのパイプラインへの条件付きブランチの追加方法」を参照してください。

- 操作ブランチの追加 - 「コンソールでのパイプラインへの操作ブランチの追加方法」を参照してください。

- サービス・エラー・ハンドラの追加 - 「コンソールでのパイプライン・エラー・ハンドラの追加」を参照してください。

パイプライン・ペア・ノード

パイプライン・ペア・ノードはリクエスト・パイプラインとレスポンス・パイプラインから成ります。

- 名前とコメントの編集

- パイプライン・ペアの追加 - 「パイプラインへのパイプライン・ペアの追加方法」を参照してください。

- ルートの追加 - 「コンソールでのパイプラインへのルート・ノードの追加方法」を参照してください。

- 条件付きブランチの追加 - 「コンソールでのパイプラインへの条件付きブランチの追加方法」を参照してください。

- 操作ブランチの追加 - 「コンソールでのパイプラインへの操作ブランチの追加方法」を参照してください。

- RESTブランチの追加 - 参照
コンソールでのパイプラインへのRESTブランチの追加方法

- ルートの貼付け - このオプションは、ルート・ノードの切取りまたはコピーを行い、クリップ・ボードにある場合にのみ使用できます。

レスポンス・パイプライン

前述のパイプライン・ペア・ノードを参照してください。

- ステージの追加 - 「コンソールでのパイプラインへのステージの追加方法」を参照してください。

- パイプライン・エラー・ハンドラの追加 - 「コンソールでのパイプライン・エラー・ハンドラの追加」を参照してください。

リクエスト・パイプライン

前述のパイプライン・ペア・ノードを参照してください。

- ステージの追加 - 「コンソールでのパイプラインへのステージの追加方法」を参照してください。

- パイプライン・エラー・ハンドラの追加 - 「コンソールでのパイプライン・エラー・ハンドラの追加」を参照してください。

エラー・ハンドラのあるパイプライン

エラー・ハンドラが定義されているパイプライン。

- パイプライン・エラー・ハンドラの編集 - 「コンソールでのパイプライン・エラー・ハンドラの追加」を参照してください。

- 「パイプライン・エラー・ハンドラの削除」

ルート・ノード

ルート・ノード・アクションは、ルート・ノードを通過する際のメッセージの処理を定義します。

- ルートの編集 - 「コンソールでのパイプラインへのルート・ノードの追加方法」を参照してください。

- 「名前とコメントの編集」

- ルート・エラー・ハンドラの追加 - 「コンソールでのルート・ノード・エラー・ハンドラの追加」を参照してください。

エラー・ハンドラがあるルート・ノード

エラー・ハンドラが定義されているルート・ノード。

- ルート・エラー・ハンドラの編集 - 「コンソールでのルート・ノード・エラー・ハンドラの追加」を参照してください。

- 「ルート・エラー・ハンドラの削除」

ステージ・ノード

ステージ・ノードは、アクションのコンテナです。

- ステージの編集 - 「コンソールでのパイプラインへのステージの追加方法」を参照してください。

- 「名前とコメントの編集」

- ステージの追加 - 「コンソールでのパイプラインへのステージの追加方法」を参照してください。

- ステージ・エラー・ハンドラの追加 - 「コンソールでのステージ・エラー・ハンドラの追加」を参照してください。

エラー・ハンドラがあるステージ・ノード

エラー・ハンドラが定義されているステージ・ノード。

- ステージ・エラー・ハンドラの編集 - 「コンソールでのステージ・エラー・ハンドラの追加」を参照してください。

- 「ステージ・エラー・ハンドラの削除」

条件付きブランチ・ノード

条件付きブランチ・ノードを使用すると、可能ないくつかのパスのうちの1つに限定して処理を進ませることができます。

- ブランチの編集 - 「コンソールでのパイプラインへの条件付きブランチの追加方法」を参照してください。

- 「名前とコメントの編集」

操作ブランチ・ノード

オペレーション・ブランチ・ノードでは、指定された操作に基づいてどのブランチに進むかが判断されます。

- ブランチの編集 - 「コンソールでのパイプラインへの操作ブランチの追加方法」を参照してください。

- 「名前とコメントの編集」

RESTブランチ・ノード

RESTブランチ・ノードでは、使用されたメディア・タイプ、相対URI、またはHTTP動詞に基づいてどのブランチに進むかが判断されます。

- ブランチの編集 - 「コンソールでのパイプラインへのRESTブランチの追加方法」を参照してください。

- 「名前とコメントの編集」

ブランチ・ノード

ブランチ・ノードは、条件付きブランチ・ノード、操作ブランチ・ノードまたはRESTブランチ・ノードによって定義される代替ノードの1つです。

- パイプライン・ペアの追加 - 「パイプラインへのパイプライン・ペアの追加方法」を参照してください。

- ルートの追加 - 「コンソールでのパイプラインへのルート・ノードの追加方法」を参照してください。

- 条件付きブランチの追加 - 「コンソールでのパイプラインへの条件付きブランチの追加方法」を参照してください。

- 操作ブランチの追加 - 「コンソールでのパイプラインへの操作ブランチの追加方法」を参照してください。

- RESTブランチの追加 - 参照
コンソールでのパイプラインへのRESTブランチの追加方法

- ルートの貼付け - このオプションは、ルート・ノードの切取りまたはコピーを行い、クリップ・ボードにある場合にのみ使用できます。

エラー・ハンドラ

エラー・ハンドラは、パイプラインでエラーを再送するロジックを提供します。

- サービス・エラー・ハンドラの追加 - 「コンソールでのパイプライン・エラー・ハンドラの追加」を参照してください。

13.1.2 コンソールの「ステージ構成の編集」ページ

「ステージ構成の編集」ページを使用して、パイプラインのパイプライン・ステージ、エラー・ハンドラ・ステージおよびルート・ノードにアクションを追加します。

- 「ステージ構成の編集」ページでまだ何も定義されていない場合、表示されるオブジェクトは「アクションの追加」アイコンのみです。アイコンをクリックして作業を開始します。

- ステージまたはルート・ノードがすでに構成されている場合は、そのステージまたはルート・ノードに対して定義されているアクションとオブジェクトがページに表示されます。必要に応じて、既存のアクションを編集するか、または、アクションを表すアイコンのいずれかをクリックして、ステージにアクションを追加します。

ステージに追加できるすべての種類のアクションの操作手順については、「コンソールでのパイプライン・アクションの追加と編集」を参照してください。

13.2 コンソールでのパイプラインの表示と編集

Oracle Service Busコンソールからパイプライン・デザイナを起動すると、パイプライン・デザイナは新しいブラウザ・ウィンドウで開かれます。

- コンソールでのパイプラインの表示および編集方法

- コンソールでのパイプラインへの共有変数の追加方法

- パイプラインへのパイプライン・ペアの追加方法

- コンソールでのパイプラインへの条件付きブランチの追加方法

- コンソールでのパイプラインへの操作ブランチの追加方法

- コンソールでのパイプラインへのステージの追加方法

- コンソールでのパイプラインへのルート・ノードの追加方法

13.2.1 コンソールでのパイプラインの表示および編集方法

Oracle Service Busコンソールからパイプライン・デザイナにアクセスするには、次の手順を実行します。

コンソールでパイプラインを表示および編集するには:

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. 「Oracle Service Busコンソール」ウィンドウの右上から、「Designer」タブをクリックします。プロジェクト・ナビゲータが表示されます。

3. 「すべてのプロジェクト」をクリックしてから、サービス・バス・プロジェクトの名前をクリックします。

4. パイプラインを編集するパイプライン・リソースをクリックします。

5. ウィンドウの右上隅付近にある「メッセージ・フローを開く」アイコンをクリックします。

- 選択したパイプラインに、まだメッセージ・フローが作成されていない場合は、1つのアイコン(「パイプライン」アイコン)が含まれた「メッセージ・フローの編集」ページが表示されます。これは、パイプライン・メッセージ・フローの開始ノードになります。このアイコンをクリックして、メッセージ・フローの作成を開始します。

- パイプラインにすでにメッセージ・フローがある場合、ページにはフローが図で表示されます。アイコンをクリックして、メッセージ・フローの各部を表示または編集します。

メッセージ・フローの作成については、「Oracle Service Busコンソールでのパイプライン・アクションの操作」を参照してください。

6. 「保存」アイコンをクリックして、現在のセッションで更新をコミットします。

7. セッションを終了して構成をランタイムにデプロイするには、Oracle Service Busコンソール・ウィンドウの右上隅にある「アクティブ化」をクリックします。

13.2.2 コンソールでのパイプラインへの共有変数の追加方法

1つのコール・チェーン内の2つのパイプラインで同じ共有変数を宣言する場合、これらは呼出しコール・チェーンの範囲内の同じ変数を読み取り、変更します。つまり、パイプラインP1で共有変数varを宣言し、パイプラインP1が、同様に共有変数varを宣言するパイプラインP2を呼び出す場合、P1のvarの変更はP2に表示され、逆も当てはまります。共有変数は、文字列、ブールまたはXMLのデータ型にする必要があります。

パイプラインでメッセージを受信して処理する場合、共有変数を使用する呼び出されたすべてのパイプラインは、その変数に対して同じ値を読書きします。プロキシで受信する以降のメッセージにより、呼び出されたパイプラインに共有変数の新しいインスタンスが作成されます。

共有変数は、ローカル・プロキシの呼出しと分割-結合コンポーネントの呼出しで機能します。たとえば、パイプラインP1およびP2で共有変数を宣言するとします。ここで、P1がローカル・プロキシ・サービスまたは分割-結合コンポーネントを呼び出し、このサービスまたはコンポーネントが同様にP2を呼び出す場合、P1とP2は引き続き共有変数を共有します。

次の制限事項が共有変数の使用に適用されます。

- システム変数($body、$attachments、$operation、$inbound、$outboundなど)は共有できません。

- 変数は、ローカル以外のプロキシ呼出しで共有できません。たとえば、パイプラインでHTTPプロキシ・サービスを呼び出す場合、共有変数はこのコール間で伝播されません。

- 変数は、パイプラインと分割-結合リソース間で共有できません。

- Javaとバイナリ・コンテンツ・タイプを使用する変数はサポートされません。たとえば、XML構造に<ctx:java-content/>があるXML型変数は、共有変数としてサポートされません。

始める前に

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

パイプラインに共有変数を追加するには:

1. 「「共有変数」セクションの展開」をクリックして、「メッセージ・フローの編集」ページの左上隅にある「共有変数」セクションを開きます。

2. 「変数」フィールドに、共有変数の名前を入力します。

3. 「追加」をクリックして、パイプラインに共有変数を追加します。

13.2.3 パイプラインへのパイプライン・ペアの追加方法

パイプラインには、パイプライン・ペア・ノード(パイプライン(またはサービスの処理用)のリクエストおよびレスポンス・パイプライン)と、ステージ、パイプラインおよびサービスに対して定義できるエラー・ハンドラ・パイプラインをゼロ個以上含めることができます。パイプラインは、1つまたは複数のステージを持つことができ、ステージはアクションを持ちます。

始める前に

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

パイプラインにパイプライン・ペアを追加するには:

1. 「パイプライン」アイコンをクリックし、「パイプライン・ペアの追加」をクリックします。

2. パイプライン・ペア・ノードのデフォルト名を変更して説明を追加するには、次の操作を行います。

a. パイプライン・ペア・ノード・アイコンをクリックし、「名前とコメントの編集」をクリックします。

b. 必要に応じて名前と説明を変更します。

c. 「保存」をクリックします。

注意:

パイプライン名やルート・ノード名を変更すると、パイプライン・カウンタがゼロにリセットされるので、「モニター」モジュールの「ダッシュボード」ページに表示されるメッセージの数と他のコンポーネントのメッセージ数との相関関係がなくなる可能性があります。これは、Service Busでは、いったん削除して再作成するアクションとして名前の変更を処理しているためです。これらのメッセージ数は、サービスのモニター間隔と同じ時間が経過した後に再び関連付ける必要があります。

3. パイプラインにステージを追加するには、「コンソールでのパイプラインへのステージの追加方法」を参照してください。

4. パイプラインのステージにアクションを追加するには、「コンソールでのパイプライン・アクションの追加と編集」を参照してください。

5. 「保存」をクリックして、現在のセッションで更新をコミットします。

6. セッションを終了して構成をランタイムにデプロイするには、Oracle Service Busコンソール・ウィンドウの右上隅にある「アクティブ化」をクリックします。

13.2.4 コンソールでのパイプラインへの条件付きブランチの追加方法

ブランチ・ノードを使用すると、可能ないくつかのパスのうちの1つに限定して処理を進めることができます。分岐は、XPathベースの切替え表に基づいて実行されます。表の各ブランチは、条件(たとえば、<500)を指定し、これが単一のXPath式(たとえば、$bodyの./ns: PurchaseOrder/ns:totalCost)に対してパイプラインの降順に評価されます。最初に満たされた条件によって、進むべきブランチが決定されます。満たされる分岐条件がない場合は、デフォルトのブランチに進みます。ブランチ・ノードでは、パイプライン内にいくつかの子孫を持つことができます(デフォルトのブランチを含め各ブランチに1つずつ)。

プロキシ・サービスがWSDLファイルに基づいておらず、複数のドキュメント・タイプを入力として受信する場合は、条件付きブランチ・ノードを使用することを検討してください。

条件付きブランチ処理は、単純でありながらユニークな文字列値のタグが付いたブランチをまとめたルックアップ表を基準に行われます。メッセージ・コンテキストの変数をそのノードのルックアップ変数として指定し、実行時に、この値を使用してどのブランチに進むかが判断されます。ルックアップ変数に一致するブランチがない場合は、デフォルトのブランチに進みます。ブランチ・ノードに到達する前にルックアップ変数の値が設定されるように、パイプラインを設計する必要があります。

始める前に

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

パイプラインに条件付きブランチを追加するには:

1. 「パイプライン・ペア・ノード」アイコンまたは「ブランチ・ノード」アイコンをクリックして、「条件付きブランチ・ノードの作成」をクリックします。条件付きブランチ・ノードが追加され、挿入したブランチ・ノードの後の既存のノードが、新しい条件付きブランチ・ノードのデフォルト・ブランチに移動します。

2. ブランチ・ノードのデフォルト名を変更して説明を追加するには、次を行います:

a. 「条件付きブランチ」アイコンをクリックし、「名前とコメントの編集」をクリックします。

b. 必要に応じて名前と説明を変更します。

c. 「保存」をクリックします。

3. ブランチ定義を追加するには、「条件付きブランチ」アイコンをクリックし、「ブランチの編集」をクリックします。「ブランチ・ノードの編集」ページが表示されます。

4. 次を実行します。

a. 「選択したパス」フィールドで「編集」をクリックして、XPath式を追加し、パスを指定します。インラインXQueryおよびXPath式の作成と編集を参照してください。

b. 「変数」フィールドにコンテキスト変数を入力します。

c. 「演算子」フィールドから、比較演算子を選択します。

d. 「値」フィールドにブランチの値を入力します。

e. 「ラベル」フィールドにブランチのラベルを入力します。

5. (オプション)「オプション」で次のようにします。

- 「新しいブランチの追加」をクリックして、このブランチ・ノードに新しいブランチ定義を追加します。

- 「このブランチを削除」をクリックして、ブランチ定義を削除します。

- 「ブランチを上に移動」または「ブランチを下に移動」をクリックして、ブランチ定義の位置を変更します。このオプションは、複数のブランチ定義が存在する場合にのみ表示されます。

6. 「保存」をクリックして、現在のセッションで更新をコミットします。

7. 「メッセージ・フローの編集」ページで、「コンソールでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

8. 「保存」をクリックして、現在のセッションで更新をコミットします。

9. セッションを終了して構成をランタイムにデプロイするには、「Oracle Service Busコンソール」ウィンドウの左上隅にある「アクティブ化」をクリックします。

13.2.5 コンソールでのパイプラインへの操作ブランチの追加方法

パイプラインでWeb Services Description Language (WSDL)ベースのプロキシ・サービスを定義する場合、操作固有の処理が必要になります。Service Busでは、操作に基づくブランチ・ノードを手動で構成するかわりに、操作に基づいて自動的に分岐するように構成された、最小限のブランチ・ノードが用意されています。つまり、操作ブランチ・ノードをパイプラインに作成すると、Oracle Service Busコンソールでは、WSDLに定義された操作がブランチ・ノード構成ページに表示されるため、これらの操作に基づいて分岐ロジックをすばやく構築できます。

ブランチ・ノードを使用すると、可能ないくつかのパスのうちの1つに限定して処理を進めることができます。分岐は、XPathベースの切替え表に基づいて実行されます。表の各ブランチは、条件(たとえば、<500)を指定し、これが単一のXPath式(たとえば、$bodyの./ns: PurchaseOrder/ns:totalCost)に対してパイプラインの降順に評価されます。最初に満たされた条件によって、進むべきブランチが決定されます。満たされる分岐条件がない場合は、デフォルトのブランチに進みます。ブランチ・ノードでは、パイプライン内にいくつかの子孫を持つことができます(デフォルトのブランチを含め各ブランチに1つずつ)。

始める前に

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

パイプラインに操作ブランチを追加するには:

1. 「パイプライン・ペア・ノード」アイコンまたは「ブランチ・ノード」アイコンをクリックして、「操作ブランチ・ノードの作成」をクリックします。操作ブランチ・ノードが追加され、挿入したブランチ・ノードの後の既存のノードが、新しい操作ブランチ・ノードのデフォルト・ブランチに移動します。

2. ブランチ・ノードのデフォルト名を変更して説明を追加するには、次を行います:

a. 「操作ブランチ」アイコンをクリックして、「名前とコメントの編集」をクリックします。

b. 必要に応じて名前と説明を変更します。

c. 「保存」をクリックします。

3. ブランチ定義を追加するには、「操作ブランチ」アイコンをクリックし、「ブランチの編集」をクリックします。「ブランチ・ノードの編集」ページが表示されます。

4. 「操作ブランチ定義」パネルで、サービス操作を選択します。

5. (オプション)「オプション」で次のようにします。

- 「新しいブランチの追加」をクリックして、このブランチ・ノードに新しいブランチ定義を追加します。

- 「このブランチを削除」をクリックして、ブランチ定義を削除します。

- 「ブランチを上に移動」または「ブランチを下に移動」をクリックして、ブランチ定義の位置を変更します。このオプションは、複数のブランチ定義が存在する場合にのみ表示されます。

6. 「保存」をクリックします。

7. 「メッセージ・フローの編集」ページで、「コンソールでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

8. 「保存」をクリックして、現在のセッションで更新をコミットします。

9. セッションを終了して構成をランタイムにデプロイするには、「Oracle Service Busコンソール」ウィンドウの左上隅にある「アクティブ化」をクリックします。

13.2.6 コンソールでのパイプラインへのRESTブランチの追加方法

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

パイプラインにRESTブランチを追加するには:

1. パイプライン・ペア・ノード・アイコンまたは「ブランチ・ノード」アイコンをクリックして、RESTブランチの作成をクリックします。RESTブランチ・ノードが追加され、挿入したブランチ・ノードの後の既存のノードが、新しいRESTブランチ・ノードのデフォルト・ブランチに移動します。

2. ブランチ・ノードのデフォルト名を変更して説明を追加するには、次を行います:

a. 「RESTブランチ」アイコンをクリックして、「名前とコメントの編集」をクリックします。

b. 必要に応じて名前と説明を変更します。

c. 「保存」をクリックします。

3. ブランチ定義を追加するには、「RESTブランチ」アイコンをクリックし、「ブランチの編集」をクリックします。「ブランチ・ノードの編集」ページが表示されます。

4. 「ラベル」フィールドにブランチのラベルを入力します。

注意:

RESTブランチ・ラベルにRESTブランチの実行の一部として、/name/{PlaceName}/zip/{ZipCode}などのパラメータ化したパス式が含まれている場合、メッセージ・コンテキスト変数PlaceNameおよびZipCodeは、Pittsburghや15217のように、実行時の実際のパス・セグメントの値で自動的に定義されます。これらのパラメータの値は、インバウンドHTTP相対パス・メタデータから抽出されます。

変数のスコープは、対応するブランチでネストされているすべてのアクションです

5. 次のブランチ・プロパティのいずれかを1つ以上構成します。

- メディア・タイプ: このブランチで使用されるクライアント・リクエストによって送信されるメディア・タイプの名前を入力します(application/xmlまたはapplication/jsonなど)。このフィールドには複数のメディア・タイプをカンマで区切って入力できます。

注意:

タイプまたはサブタイプのワイルドカードがサポートされています。たとえば、application/xml、examples/*、および*/xmlがサポートされます。examples/*+xmlなどの部分ワイルドカードはサポートされていません。

- パス: /dogs/{id}など、このブランチで使用されるクライアント・リクエストの相対URIパスを入力します。

- 動詞: このブランチで使用されるクライアント・リクエストのHTTP動詞を選択します。

6. (オプション)「オプション」で次のようにします。

- 「新しいブランチの追加」をクリックして、このブランチ・ノードに新しいブランチ定義を追加します。

- 「このブランチを削除」をクリックして、ブランチ定義を削除します。

- 「ブランチを上に移動」または「ブランチを下に移動」をクリックして、ブランチ定義の位置を変更します。このオプションは、複数のブランチ定義が存在する場合にのみ表示されます。

7. 「保存」をクリックします。

8. 「メッセージ・フローの編集」ページで、「コンソールでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

9. 「保存」をクリックして、現在のセッションで更新をコミットします。

10. セッションを終了して構成をランタイムにデプロイするには、「Oracle Service Busコンソール」ウィンドウの左上隅にある「アクティブ化」をクリックします。

13.2.7 コンソールでのパイプラインへのステージの追加方法

始める前に

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

パイプラインにステージを追加するには:

1. 必要に応じて、「パイプライン・ペア・ノード」アイコンの左側にあるプラス記号クリックしてパイプライン・ペア・ノードを展開します。パイプライン・ペアには、「リクエスト・パイプライン」および「レスポンス・パイプライン」が含まれています。

2. ステージに追加するパイプラインをクリックしてから、「ステージの追加」をクリックします。

3. ステージのデフォルト名を変更して説明を追加するには、次を行います:

a. 「ステージ」アイコンをクリックして、「名前とコメントの編集」をクリックします。

b. 必要に応じて名前と説明を変更します。

c. 「保存」をクリックします。

4. ステージにアクションを追加するには、「ステージ」アイコンをクリックし、「ステージの編集」をクリックします。「コンソールでのパイプライン・アクションの追加と編集」を参照してください。

5. ステージにエラー処理を追加するには、「ステージ」アイコンをクリックし、「ステージ・エラー・ハンドラの追加」をクリックします。「コンソールでのエラー・ハンドラの追加」を参照してください。「メッセージ・フローの編集」ページが表示されます。

6. 「コンソールでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

7. 「保存」をクリックして、現在のセッションで更新をコミットします。

8. セッションを終了して構成をランタイムにデプロイするには、Oracle Service Busコンソール・ウィンドウの右上隅にある「アクティブ化」をクリックします。

13.2.8 コンソールでのパイプラインへのルート・ノードの追加方法

始める前に

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

パイプラインにルート・ノードを追加するには:

1. パイプライン・ペアの「パイプライン・ペア・ノード」アイコンをクリックして、「ルートの追加」をクリックします。

2. ルート・ノードのデフォルト名の変更と説明の追加を行うには、「ルート・ノード」アイコンをクリックして、「名前とコメントの編集」をクリックします。必要に応じて名前と説明を変更し、「保存」をクリックします。

注意:

パイプライン名やルート・ノード名を変更すると、パイプライン・カウンタがゼロにリセットされるので、「モニター」モジュールの「ダッシュボード」ページに表示されるメッセージの数と他のコンポーネントのメッセージ数との相関関係がなくなる可能性があります。これは、Service Busでは、いったん削除して再作成するアクションとして名前の変更を処理しているためです。これらのメッセージ数は、サービスのモニター間隔と同じ時間が経過した後に再び関連付ける必要があります。

3. ルート・ノードにアクションを追加するには、「ルート・ノード」アイコンをクリックし、「ルートの編集」をクリックします。「メッセージ・フローの編集」ページが表示されます。ルート・ノードに追加できるアクションの詳細は、次のセクションを参照してください。

- コンソールでのIf-Thenアクションの追加

- コンソールでのルート・ノードへの動的ルーティングの追加

- コンソールでのルート・ノードへのルーティング・アクションの追加

- コンソールでのルート・ノードへのルーティング表の追加

- コンソールでのエラー・ハンドラの追加

4. 「メッセージ・フローの編集」ページで、「コンソールでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

5. 「保存」をクリックして、現在のセッションで更新をコミットします。

6. セッションを終了して構成をランタイムにデプロイするには、Oracle Service Busコンソール・ウィンドウの右上隅にある「アクティブ化」をクリックします。

13.3 ステージおよびルート・ノードの切取り、コピー、貼付け

ステージおよびルート・ノードの切り取り、コピー、貼付けが行えます。

- ステージまたはルート・ノードを切り取るには、そのアイコンをクリックし、「切取り」または「コピー」を選択します。

- このパイプラインのメッセージ・フロー内の異なるパイプライン・ペアから、または異なるパイプラインのメッセージ・フローから切り取ったりコピーしたステージを貼り付けるには、次のいずれかを行います。

- 「リクエスト・パイプライン」または「レスポンス・パイプライン」アイコンをクリックして、「ステージの貼付け」をクリックします。

- パイプラインの「ステージ」アイコンをクリックして、「貼付け」をクリックします。

- 別のパイプラインから切り取った、またはコピーしたルート・ノードを貼り付けるには、パイプライン・ペアのパイプライン・ペア・ノード・アイコンをクリックして、「ルートの貼付け」をクリックします。

13.4 コンソールでのリシーケンサの構成

Service Busのリシーケンサは、関連はあるが順序どおりではないメッセージのストリームを連続した順序に並べ替えます。受信メッセージが到着すると、それらはランダムな順序になっています。リシーケンサは、順次または時系列の情報に基づきメッセージを順序付け、メッセージをターゲット・サービスに対して正しい手順で送信します。順序付けは、選択した順序付け戦略に基づき実行されます。

リシーケンサは、パイプライン・コンポーネント内で構成できます。次のサービス・タイプのパイプラインがサポートされます。

- WSDL: リシーケンスは、リクエスト・タイプのみの操作に利用できます。

- メッセージ・タイプ: リクエスト・メッセージ・タイプは「XML」、レスポンス・メッセージ・タイプは「なし」にします。

注意:

リシーケンサでは、「任意のXML」と「任意のSOAP」のサービス・タイプはサポートされません。WSDLベースのサービスでは、WSDLファイルは一方向であることが必要です。つまり、これに出力要素を含めることはできません。リシーケンス・パイプラインでの生成WSDLファイルの使用については、「コンソールでのWSDLファイルのエクスポート方法」を参照してください。

13.4.1 コンソールでパイプラインでのリシーケンスを構成する方法

この項では、Oracle Service Busコンソールを使用してパイプラインでリシーケンサを構成する方法について説明します。

パイプライン・コンポーネントでリシーケンスを有効にするには:

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. 「Oracle Service Busコンソール」ウィンドウの右上から、「Designer」タブをクリックします。プロジェクト・ナビゲータが表示されます。

3. 「すべてのプロジェクト」をクリックしてから、サービス・バス・プロジェクトの名前をクリックします。

4. リシーケンサを構成するパイプライン・リソースをクリックします。パイプライン定義ページが表示されます。

5. 「リシーケンサ」タブをクリックします。

6. 「リシーケンスの有効化」を選択して、パイプラインのリシーケンスを有効にします。図13-1に、パイプライン定義のリシーケンス・ページの「リシーケンスの有効化」オプションを示します。

図13-1 Oracle Service Busコンソールでのリシーケンサの有効化

7. 「リシーケンス・レベル」を選択します。「パイプライン」を選択して、コンポーネント・レベルでリシーケンスを構成します。「操作」を選択して、操作レベルでリシーケンスを構成します。リシーケンス・レベルの詳細は、「コンソールでのリシーケンス・レベルの選択方法」を参照してください。

「操作」を選択した場合、操作ごとにリシーケンスを個別に構成するオプションを利用できます。

8. 「リシーケンス・モード」を選択します。「操作」レベルでリシーケンスを構成する場合、各操作に対応する「リシーケンス・モード」を選択します。各種リシーケンス・オプションの詳細は、「コンソールでのリシーケンス・モードの構成方法」を参照してください。

選択した「リシーケンス・モード」に応じて、そのモードに対応するオプションを利用できます。たとえば、「標準」モードを選択するには、「グループ式」、「ID式」などの値を選択する必要があります。図13-2に、「標準」モードの場合に表示されるオプションを示します。

図13-2 標準モードのリシーケンスで表示される構成オプション

9. 使用するワーク・マネージャを指定する「ディスパッチ・ポリシー」を選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

10. 「保存」アイコンをクリックして、変更をコミットします。

13.4.2 コンソールでのリシーケンス・レベルの選択方法

リシーケンスは、パイプライン・レベルまたは操作レベルのいずれかで定義できます。リシーケンス・レベルの値は、次のとおりです。

- パイプライン: コンポーネント・レベルで指定した共通構成を使用してすべてのメッセージをリシーケンスします。コンポーネントに複数の操作がある場合、各操作のメッセージは、共有コンポーネント構成を使用して個別に順序付けられます。
コンポーネント・レベルのリシーケンスは、パイプライン・コンポーネントのすべての操作でリクエスト一方向メッセージをサポートする場合のみ許可されます。操作のサブセットのみがリクエスト一方向メッセージをサポートする場合、これらの操作に操作レベルのリシーケンスを個別に指定できます。

- 操作: WSDLベースのパイプラインの場合、リシーケンスは操作レベルで構成できます。各操作には異なるリシーケンサ構成を設定できます。リクエスト一方向メッセージをサポートする操作のみをリシーケンスできます。WSDL以外のパイプラインでは、操作レベルでリシーケンサを構成できません。

13.4.3 コンソールでのリシーケンス・モードの構成方法

この項では、様々なリシーケンス・モードの構成方法を示します。各種リシーケンス・モードの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のリシーケンス順序に関する項を参照してください。デフォルトでは、グループIDの文字数制限は1000、IDの文字数制限は100です。

13.4.3.1 標準リシーケンサの構成

標準リシーケンサを構成するには:

1. パイプライン定義のリシーケンス・ページで、「リシーケンス・モード」ドロップダウン・リストから「標準」を選択します。操作レベルでリシーケンスを構成する場合、操作の「リシーケンス・モード」ドロップダウン・リストから、「標準」を選択します。

標準リシーケンス構成に関連するフィールドがページに表示されます。詳細は、図13-2を参照してください。

2. 表13-2に示すフィールドに入力します。

表13-2 標準リシーケンスのオプション

フィールド名

説明

デフォルト値

必須

グループ式

グループ化が行われる受信メッセージのフィールドを指し示すXQuery式。値を入力しない場合、すべてのメッセージが1つのデフォルト・グループに配置されます。

右側の「式ビルダー」アイコンをクリックして、XQuery/XSLT式エディタを呼び出します。

N/A

N

ID式

リシーケンスが行われる受信メッセージのフィールドを指し示すXQuery式。

右側の「式ビルダー」アイコンをクリックして、XQuery/XSLT式エディタを呼び出します。

N/A

Y

開始

ID順序の開始番号。

1

N

増分

ID順序の増分。

1

N

タイムアウト

予期されているメッセージを待機する期間(秒単位)。タイムアウトが発生すると、再シーケンサはグループをタイムアウトとしてロックします。

デフォルト値の0の場合、デフォルトではグループに対してタイムアウトが発生することはありません。

0

N

13.4.3.2 FIFOリシーケンサの構成

FIFOリシーケンサを構成するには:

1. パイプライン定義のリシーケンス・ページで、「リシーケンス・モード」ドロップダウン・リストから「FIFO」を選択します。操作レベルでリシーケンスを構成する場合、操作の「リシーケンス・モード」ドロップダウン・リストから、「FIFO」を選択します。

FIFOリシーケンス構成に関連するフィールドがページに表示されます。

2. 「グループ式」フィールドに、グループ化が行われる受信メッセージのフィールドを指し示すXQuery式を入力します。

右側の「式ビルダー」アイコンをクリックして、XQuery/XSLT式エディタを呼び出します。

13.4.3.3 ベスト・エフォート・リシーケンサの構成

ベスト・エフォート・リシーケンサを構成するには:

1. パイプライン定義のリシーケンス・ページで、「リシーケンス・モード」ドロップダウン・リストから「ベスト・エフォート」を選択します。操作レベルでリシーケンスを構成する場合、操作の「リシーケンス・モード」ドロップダウン・リストから、「ベスト・エフォート」を選択します。

ベスト・エフォート・リシーケンス構成に関連するフィールドがページに表示されます。

2. 表13-3に示すフィールドに入力して、ベスト・エフォート・リシーケンサを構成します。

表13-3 ベスト・エフォート・リシーケンスのオプション

フィールド名

説明

デフォルト値

必須

グループ式

グループ化が行われる受信メッセージのフィールドを指し示すXQuery式。ここに値を入力しない場合、すべてのメッセージは1つのデフォルト・グループ内になると見なされます。

右側の「式ビルダー」アイコンをクリックして、XQuery/XSLT式エディタを呼び出します。

N/A

N

ID式

リシーケンスが行われる、IDを含む受信メッセージのフィールドを指し示すXQuery式。

右側の「式ビルダー」アイコンをクリックして、XQuery/XSLT式エディタを呼び出します。

N/A

Y

データ型

順序IDのデータ型。注文プロセスはデータ型に基づいています。サポートされる値は、「日付/時刻」と「数値」です。

数値

Y

最大行数

再シーケンサが一度にデータ・ストアから取得する、順に従ったメッセージの数。これは正の整数にしてください。

「最大行数」または「時間ウィンドウ」(次に説明)を指定する必要がありますが、両方を指定しないでください。

5

N

時間ウィンドウ

メッセージが到着した後、リシーケンスに関してデータ・ストアからメッセージを選択するまでに待機する秒単位の時間。デフォルト値の0の場合、待機しません。

「時間ウィンドウ」または「最大行数」(前述)を指定する必要がありますが、両方を指定しないでください。

0

N

13.5 変数の構造のマッピングの作成

次の項では、様々なタイプの変数の構造のマッピングを作成する方法について説明します。

- サンプルWSDLドキュメント

- 例で必要なリソースの作成

- 例1: 事前定義された変数の構造の選択

- 例2: 変数の型へのマッピング

- 例3: 変数の要素へのマッピング

- 例4: 変数の子要素へのマッピング

- 例5: 変数のビジネス・サービスへのマッピング

- 例6: 子要素の別の子要素へのマッピング

13.5.1 サンプルWSDLドキュメント

このサンプルWSDLドキュメントは、この項のほとんどの例で使用します。このWSDLドキュメントをリソースとして構成に保存してください。詳細は、「例で必要なリソースの作成」を参照してください。

例 - サンプルWSDLドキュメント

<definitions
name="samplewsdl"
targetNamespace="http://example.org"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:s0="http://www.oracle.com"
xmlns:s1="http://example.org"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<types>
<xs:schema
attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="http://www.oracle.com"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="PO" type="s0:POType"/>
<xs:complexType name="POType">
<xs:all>
<xs:element name="id" type="xs:string"/>
<xs:element name="name" type="xs:string"/>
</xs:all>
</xs:complexType>
<xs:element name="Invoice" type="s0:InvoiceType"/>
<xs:complexType name="InvoiceType">
<xs:all>
<xs:element name="id" type="xs:string"/>
<xs:element name="name" type="xs:string"/>
</xs:all>
</xs:complexType>
</xs:schema>
</types>
<message name="POTypeMsg">
<part name="PO" type="s0:POType"/>
</message>
<message name="InvoiceTypeMsg">
<part name="InvReturn" type="s0:InvoiceType"/>
</message>

<portType name="POPortType">
<operation name="GetInvoiceType">
<input message="s1:POTypeMsg"/>
<output message="s1:InvoiceTypeMsg"/>
</operation>
</portType>
<binding name="POBinding" type="s1:POPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetInvoiceType">
<soap:operation soapAction="http://example.com/GetInvoiceType"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
</definitions>

13.5.2 例で必要なリソースの作成

この後の例を利用するには、サンプルWSDLドキュメントをリソースとして構成に保存し、サンプルWSDLドキュメントを使用するサンプルのビジネス・サービスとプロキシ・サービスを作成します。

以下の手順に従って、Oracle Service Busコンソールでタスクを実行します。

- リソースとしてのWSDLファイルの保存

- プロキシ・サービスとパイプラインの作成

- サンプル・パイプラインのメッセージ・フローの構築

- ビジネス・サービスの作成

13.5.2.1 リソースとしてのWSDLファイルの保存

次の手順を実行します。

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. 「Oracle Service Busコンソール」ウィンドウの右上から、「Designer」タブをクリックします。プロジェクト・ナビゲータが表示されます。

3. 「すべてのプロジェクト」ノードの前にある「展開」(矢印)アイコンをクリックし、このノードを開きます。

4. WSDLファイルの追加先となるプロジェクト名を右クリックします。コンテキスト・メニューで「作成」、「リソース」をクリックします。

5. 「リソース・ギャラリ」から「インタフェース」、「WSDL」の順にクリックします。「WSDLの作成」ダイアログが表示されます。

6. 「リソース名」フィールドに、SampleWSDLと入力します。これは必須フィールドです。

7. 「説明」フィールドに、WSDLリソースの説明を入力します。これはオプションです。

8. 「ファイルの選択」をクリックして、WSDLサンプル・ファイルを選択します。

9. 「作成」をクリックしてWSDLリソースを作成します。

13.5.2.2 プロキシ・サービスとパイプラインの作成

サンプルWSDLドキュメントを使用するプロキシ・サービスおよびパイプラインを作成するには、次の手順を実行します。

1. プロジェクト・ナビゲータで、パイプラインの追加先のプロジェクトを選択して、「作成」アイコンの横の下向き矢印をクリックし、「リソース」をクリックします。

2. 「サービス」をクリックし、「パイプライン」、「OK」をクリックします。

パイプラインの作成ダイアログが表示されます。

3. 「全般」セクションの「パイプライン名」フィールドに、PipelinewithSampleWSDLと入力します。このフィールドは必須です。

オプションで、パイプラインの「説明」を指定します。

4. 「サービス・タイプ」で、「WSDLベース・サービス」を選択します。

5. 「参照」アイコンをクリックし、WSDLファイルのリストからSampleWSDLを選択します。WSDLファイルを検索するには、「検索」をクリックする必要があります。

6. プロキシ・サービスとして公開を選択して、パイプラインに対応するプロキシ・サービスを作成します。

7. 「名前」フィールドにProxywithSampleWSDLと入力します。

8. 「作成」をクリックして、パイプラインとプロキシ・サービスを作成します。パイプラインが作成され、開いて編集できます。

13.5.2.3 サンプル・パイプラインのメッセージ・フローの構築

次の手順を実行します。

1. プロジェクト・ナビゲータで、パイプラインPipelinewithSampleWSDLをクリックして開きます。

2. 右上隅にある「メッセージ・フローを開く」アイコンをクリックして、パイプラインのメッセージ・フローの編集を開始します。「メッセージ・フローの編集」ページが表示されます。

3. 「メッセージ・フローの編集」ページで、PipelinewithSampleWSDLアイコンをクリックし、「パイプライン・ペアの追加」をクリックします。PipelinePairNode1が表示されます。ここには、リクエスト・パイプラインとレスポンス・パイプラインが含まれています。

4. 「リクエスト・パイプライン」アイコンをクリックし、「ステージの追加」をクリックします。ステージ「Stage1」が表示されます。

5. 「保存」をクリックします。PipelinewithSampleWSDLパイプラインの基本的なメッセージ・フローが作成されます。

13.5.2.4 ビジネス・サービスの作成

サンプルWSDLドキュメントを使用するビジネス・サービスを作成するには、次の手順を実行します。

1. プロジェクト・ナビゲータで、ビジネス・サービスの追加先となるプロジェクトを選択します。

2. 「作成」ドロップダウン・リストから、「リソース」を選択します。

3. 「サービス」が選択されていることを確認し、「ビジネス・サービス」をクリックします。「Webサービス」が選択されていることを確認し、「SOAP」、「OK」の順に選択します。
「ビジネス・サービスの作成」ウィザードが表示されます。

4. 「リソース名」フィールドに、BusinesswithSampleWSDLと入力します。これは必須フィールドです。

5. 「サービス定義」で、「WSDLベース・サービス」を選択します。

6. 「名前」フィールドの横の「参照」アイコンをクリックし、WSDLファイルのリストからSampleWSDLを選択します。WSDLファイルを検索するには、「検索」をクリックする必要があります。

7. 「次」をクリックします。「作成」をクリックします。ビジネス・サービスが作成されます。

これで、例を使用する準備ができました。「例1: 事前定義された変数の構造の選択」に進みます。

13.5.3 例1: 事前定義された変数の構造の選択

この例では、プロキシ・サービスProxyWithSampleWSDLを使用して事前定義された変数の構造を選択します。このサービスのタイプは、SampleWSDLのバインディングPOBindingを使用するWSDL Webサービスです。

パイプラインのメッセージ・フローが、処理するメッセージの構造を認識している必要があります。このために、Service Busでは事前定義された構造が自動的に提供されます。この構造は、インタフェースのすべてのメッセージで、プロキシ・サービスのWSDLファイルでの定義に従って、body変数をSOAP本体の構造にマップします。この事前定義された構造のマッピングのラベルはbodyです。

注意:

この事前定義された構造は、型付きインタフェースを備えたメッセージング・サービスのためにもサポートされています。

事前定義された変数の構造の選択

XQuery式エディタ・ページの「変数の構造」パネルで、組込み構造のリストから「body」を選択します。

変数の構造bodyは、図13-3のように表示されます。

図13-3 変数の構造 - body

13.5.4 例2: 変数の型へのマッピング

プロキシ・サービスProxyWithSampleWSDLが、ビジネス・サービスBusinessWithSampleWSDLへのサービス・コールアウトを呼び出すとします。このビジネス・サービスも、サービスのタイプはSampleWSDLのバインディングPOBindingを使用するWSDL Webサービスです。操作GetInvoiceTypeが呼び出されます。

この例では、パイプラインが、処理するレスポンス・パラメータの構造を認識する必要があります。このためには、レスポンス・パラメータ変数を型InvoiceTypeにマップする新しい変数の構造を作成します。

変数を型にマップするには:

1. 「変数の構造」パネルで「新しい構造の追加」をクリックします。追加フィールドが図13-4のように表示されます。

図13-4 変数の構造 - 新しい構造の追加

2. 「XMLタイプ」を選択します。

3. 「構造ラベル」フィールドに、作成する変数の構造の表示名として「InvoiceType」と入力します。この表示名を使用すると、実行時には影響を及ぼさず設計時に構造を認識できるように、構造に意味のある名前を付けることができます。

4. 「構造パス」フィールドに、実行時の変数の構造のパスとして「$InvoiceType」と入力します。

5. タイプ「InvoiceType」を選択するには、次のようにします。

a. 「タイプ」フィールドで、該当するラジオ・ボタンを選択し、リストから「WSDLタイプ」を選択します。

b. 「参照」をクリックします。WSDLブラウザが表示されます。

c. WSDLブラウザで「SampleWSDL」を選択してから、「WSDL定義の選択」ペインの「タイプ」で「InvoiceType」を選択します。

d. 「発行」をクリックします。選択した「WSDLタイプ」の下に「InvoiceType」が表示されます。

6. 「追加」をクリックします。新しい変数の構造「InvoiceType」が変数の構造のリストの「XMLタイプ」の下に追加されます。
変数の構造InvoiceTypeは、図13-5のように表示されます。

図13-5 変数の構造 - InvoiceType

13.5.5 例3: 変数の要素へのマッピング

一時変数には、SampleWSDL WSDLファイルで記述された要素Invoiceが含まれているとします。この例では、ProxyWithSampleWSDLパイプラインが、この変数にアクセスする必要があります。このためには、変数を要素Invoiceにマップする新しい変数の構造を作成します。

変数を要素にマップするには

1. 「変数の構造」パネルで「新しい構造の追加」をクリックします。

2. 「XMLタイプ」を選択します。

3. 「構造ラベル」フィールドに、作成する変数の構造の名前として、表示されたときに意味がわかるように「Invoice」と入力します。

4. 「構造パス」フィールドに、実行時の変数の構造のパスとして「$Invoice」と入力します。

5. 要素「Invoice」を選択するには、次のようにします。

a. 「タイプ」フィールドで、該当するラジオ・ボタンを選択していることを確認します。「WSDL要素」を選択します。

b. 「参照」をクリックします。

c. WSDLブラウザで「SampleWSDL」を選択してから、「WSDL定義の選択」ペインの「要素」で「Invoice」を選択します。

d. 「発行」をクリックします。選択した「WSDL要素」の下に「Invoice」が表示されます。

6. 「追加」をクリックします。新しい変数の構造「Invoice」が変数の構造のリストの「XMLタイプ」の下に追加されます。
変数の構造Invoiceは、図13-6のように表示されます。

図13-6 変数の構造 - Invoice

13.5.6 例4: 変数の子要素へのマッピング

プロキシ・サービスProxyWithSampleWSDLは、ドキュメント・スタイルがAny SOAPであるビジネス・サービスにルーティングします。このビジネス・サービスは、SOAP本体の発注書を返します。この例では、ProxyWithSampleWSDLパイプラインがレスポンスを処理する必要があります。このためには、body変数をPO要素にマップする新しい構造を作成し、PO要素を変数の子要素として指定します。body変数にはSOAP Body要素が格納され、PO要素はBody要素の子であるため、子要素として指定する必要があります。

変数を子要素にマップするには:

1. 「変数の構造」パネルで「新しい構造の追加」をクリックします。

2. 「XMLタイプ」を選択します。

3. 「構造ラベル」フィールドに、作成する変数の構造の名前として、表示されたときに意味がわかるように「body to PO」と入力します。

4. 「構造パス」フィールドに、実行時の変数の構造のパスとして「$body」と入力します。

5. PO要素を選択するには、次のようにします。

a. 「タイプ」フィールドで、該当するラジオ・ボタンを選択していることを確認します。「WSDL要素」を選択します。

b. 「参照」をクリックします。

c. WSDLブラウザで「SampleWSDL」を選択してから、「WSDL定義の選択」ペインの「要素」で「PO」を選択します。

d. 「発行」をクリックします。

6. PO要素をbody to PO変数の構造の子として設定するために、「子として設定」チェックボックスを選択します。

7. 「追加」をクリックします。新しい変数の構造「body to PO」が変数の構造のリストの「XMLタイプ」の下に追加されます。
変数の構造body to POは、図13-7のように表示されます。

図13-7 変数の構造 - body to PO

13.5.7 例5: 変数のビジネス・サービスへのマッピング

プロキシ・サービスProxyWithSampleWSDLは、ビジネス・サービスBusinessWithSampleWSDLにメッセージをルーティングします。このビジネス・サービスも、サービスのタイプはSampleWSDLのバインディングPOBindingを使用するWSDL Webサービスです。この例では、パイプラインがレスポンスを処理する必要があります。このためには、body変数をBusinessWithSampleWSDLビジネス・サービスにマップする新しい構造を定義します。これにより、サービスのWSDLインタフェースで、すべてのメッセージのSOAP本体にbody変数がマップされます。

注意:

このマッピングは、型付きインタフェースを備えたメッセージング・サービスのためにもサポートされています。

変数をビジネス・サービスにマップするには

1. 「変数の構造」パネルで「新しい構造の追加」をクリックします。

2. 「サービス・インタフェース」を選択します。

3. 「構造ラベル」フィールドに、変数の構造の名前として、表示されたときに意味がわかるように「BusinessService」と入力します。

4. 「構造パス」フィールドには、デフォルトとしてすでに$bodyが設定されています。これは、実行時の変数の構造のパスになります。

5. このビジネス・サービスを選択するには、次の操作を実行します。

a. 「サービス」フィールドで、「参照」をクリックします。サービス・ブラウザが表示されます。

b. サービス・ブラウザでBusinessWithSampleWSDLビジネス・サービスを選択し、「発行」をクリックします。ビジネス・サービスが「サービス」フィールドの下に表示されます。

c. 「操作」フィールドで、「すべて」を選択します。

6. 「追加」をクリックします。新しい変数の構造BusinessServiceが変数の構造のリストの「サービス・インタフェース」の下に追加されます。
変数の構造BusinessServiceは、図13-8のように表示されます。

図13-8 変数の構造 - Business Service

13.5.8 例6: 子要素の別の子要素へのマッピング

ProxyWithSampleWSDLプロキシ・サービスが単一の添付ファイルを受信するように、SampleWSDLを変更します。添付ファイルは発注書です。この例では、パイプラインが注文書を処理する必要があります。このためには、$attachmentsのbody要素を、子要素として指定されているPO要素にマップする新しい構造を定義します。body要素は、次の形式の変数パスとして指定されます。

$attachments/ctx:attachment/ctx:body

事前定義されたattachments構造のbody要素を選択してコピーし、新しいマッピング定義でマップされる変数パスとして貼り付けます。

子要素を別の子要素にマップするには:

1. 「変数の構造」パネルで、組込み構造のリストから「attachments」を選択します。
変数の構造attachmentsは、図13-9のように表示されます。

図13-9 変数の構造 - attachments

2. attachments構造でbody子要素を選択します。ページの右側にあるプロパティ・インスペクタにbody要素の変数パスが表示されます。

$attachments/ctx:attachment/ctx:body

3. body要素の変数パスをコピーします。

4. 「変数の構造」パネルで「新しい構造の追加」をクリックします。

5. 「XMLタイプ」を選択します。

6. 「構造ラベル」フィールドに、この変数の構造の名前として、表示されたときに意味がわかるように「PO attachment」と入力します。

7. 「構造パス」フィールドに、body要素の変数パスを貼り付けます。

$attachments/ctx:attachment/ctx:body

これは、実行時の変数の構造のパスになります。

8. PO要素を選択するには、次のようにします。

a. 「タイプ」フィールドで、該当するラジオ・ボタンを選択していることを確認し、「WSDL要素」を選択します。

b. 「参照」をクリックします。

c. WSDLブラウザで「SampleWSDL」を選択してから、「WSDL定義の選択」ペインの「要素」で「PO」を選択します。

d. 「発行」をクリックします。

9. body要素の子としてPO要素を設定するために、「子として設定」チェックボックスを選択します。

10. 「追加」をクリックします。新しい変数の構造「PO attachment」が変数の構造のリストの「XMLタイプ」の下に追加されます。

11. 複数の添付ファイルを使用する場合は、この構造化変数のフィールドをXQueryで使用するときに、索引を参照に追加します。たとえば、POフィールドをXQueryフィールドにドラッグしてPOを2番目の添付にする場合は、挿入した値を変更します。

$attachments/ctx:attachment/ctx:body/oracle:PO/oracle:id

次のように変更します。

$attachments/ctx:attachment[2]/ctx:body/oracle:PO/oracle:id

14 Oracle Service Busコンソールでのパイプライン・アクションの操作

この章では、ルート、パブリッシュ、サービス・コールアウト、トランスポート・ヘッダー、条件付きアクション、エラー・アクション、メッセージ変換アクションなど、Oracle Service Busコンソールを使用したパイプラインへの異なるタイプのアクションの追加方法について説明します。

アクションとは、パイプラインを流れるメッセージの定義方法を決定するパイプライン・ステージ、エラー・ハンドラ・ステージ、ルート・ノードおよびブランチ・ノードの要素です。

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

- コンソールでのパイプライン・アクションの追加と編集

- コンソールでのパブリッシュ・アクションの追加

- コンソールでのパブリッシュ表アクションの追加

- コンソールでの動的パブリッシュ・アクションの追加

- コンソールでのルーティング・オプション・アクションの追加

- コンソールでのサービス・コールアウト・アクションの追加

- コンソールでのトランスポート・ヘッダー・アクションの追加

- コンソールでのルート・ノードへの動的ルーティングの追加

- コンソールでのルート・ノードへのルーティング・アクションの追加

- コンソールでのルート・ノードへのルーティング表の追加

- コンソールでのFor-Eachアクションの追加

- コンソールでのIf-Thenアクションの追加

- コンソールでのエラーの生成アクションの追加

- コンソールでの返信アクションの追加

- コンソールでの再開アクションの追加

- コンソールでのスキップ・アクションの追加

- コンソールでの割当てアクションの追加

- コンソールでの削除アクションの追加

- 挿入アクションの追加

- コンソールでのJavaコールアウト・アクションの追加

- コンソールでのJavaScriptアクションの追加

- コンソールでのMFL変換アクションの追加

- nXSD変換アクションの追加

- コンソールでの名前変更アクションの追加

- コンソールでの置換アクションの追加

- コンソールでの検証アクションの追加

- コンソールでのアラート・アクションの追加

- コンソールでのログ・アクションの追加

- コンソールでのレポート・アクションの追加

- コンソールでのエラー・ハンドラの追加

- コンソールでのアクションまたはステージの無効化

14.1 コンソールでのパイプライン・アクションの追加と編集

アクションとは、プロキシ・サービスを流れるメッセージの定義方法を決定するパイプライン・ステージ、エラー・ハンドラ・ステージ、ルート・ノードおよびブランチ・ノードの要素です。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

また、パイプライン・ステージ、ルート・ノード、およびエラー・ハンドラ・ステージをすでに追加していることも前提としています。参照:

- パイプラインへのパイプライン・ペアの追加方法

- コンソールでのパイプラインへのステージの追加方法

- コンソールでのパイプライン・エラー・ハンドラの追加

パイプラインにアクションを追加するには:

1. アクションを追加するコンポーネントを選択します。たとえば、「ステージ」アイコンをクリックして、「ステージの編集」をクリックするか、または、「ルート・ノード」アイコンをクリックし、「ルートの編集」をクリックします。

2. ステージまたはルート・ノードにすでに追加しているアクションに応じて、次のいずれかを行います。

- まだアクションを何も追加していない場合、「ステージ構成の編集」ページには、「アクションの追加」アイコンのみが表示されます。そのアイコンをクリックして、アクション・タイプを選択します。

- すでに1つ以上のアクションを追加している場合、「ステージ構成の編集」ページには、「パブリッシュ」アイコン、「ルーティング」アイコンなど、それらのアクションを表す1つ以上のアイコンが表示されます。該当するアイコンをクリックし、「アクションの追加」をクリックして、アクション・タイプを選択します。

- パブリッシュ・アクションのリクエストおよびレスポンス・アクションなどの一部のアクションには、アクションを割り当てるための「アクションの追加」リンクが含まれています。そのアイコンをクリックして、アクション・タイプを選択します。

パイプラインのアクションは任意の組合せで連鎖できます。

パイプラインに構成できるアクションを表14-1から表14-4に示します。

表14-1 パイプライン - 通信アクション

アクション

説明

詳細

動的にパブリッシュ

XQuery式によって識別されたサービスにメッセージをパブリッシュします。

コンソールでの動的パブリッシュ・アクションの追加

パブリッシュ

静的に指定されたサービスにメッセージをパブリッシュします。

コンソールでのパブリッシュ・アクションの追加

パブリッシュ表

ゼロまたはそれ以上の静的に指定されたサービスにメッセージをパブリッシュします。切替え式の条件ロジックを使用して、どのサービスをパブリッシュに使用するか実行時に決定します。

コンソールでのパブリッシュ表アクションの追加

ルーティング・オプション

アウトバウンド・リクエストのURI、サービスの品質、モード、再試行パラメータ、メッセージ優先度の各プロパティの一部またはすべてを変更します。

コンソールでのルーティング・オプション・アクションの追加

サービス・コールアウト

Service Busに登録済のプロキシ・サービスまたはビジネス・サービスの同期(ブロッキング)コールアウトを構成します。

コンソールでのサービス・コールアウト・アクションの追加

トランスポート・ヘッダー

メッセージのトランスポート・ヘッダーの値を設定します。

コンソールでのトランスポート・ヘッダー・アクションの追加

動的ルーティング

XQueryリソースで使用できるルーティング情報に基づいて、メッセージ・ルートを割り当てます。

コンソールでのルート・ノードへの動的ルーティングの追加

ルーティング

メッセージのターゲット・サービスを指定し、ターゲット・サービスへのメッセージのルーティング方法を構成します。

コンソールでのルート・ノードへのルーティング・アクションの追加

ルーティング表

切替え式の条件表に含まれた一連のルートを割り当てます。これは、単一のXQuery式の結果に基づいて、異なるルートが選択されます。

コンソールでのルート・ノードへのルーティング表の追加

表14-2 パイプライン - フロー制御アクション

アクション

説明

詳細

For Each

値のシーケンスを反復処理し、アクションのブロックを実行します。

コンソールでのFor-Eachアクションの追加

If...Then

XQuery式のブール結果に基づいて、1つのアクションまたは一連のアクションを条件付きで実行します。

コンソールでのIf-Thenアクションの追加

エラーの生成

指定されたエラー・コード(文字列)と記述を含む例外を発生させます。

コンソールでのエラーの生成アクションの追加

返信

呼出し元に即時返信を送信します。

コンソールでの返信アクションの追加

再開

エラー・ハンドラによってエラーが処理された後、パイプラインを再開します。

コンソールでの再開アクションの追加

スキップ

実行時に現在のステージの実行がスキップされて、処理がパイプラインの次のステージに進むように指定します。

コンソールでのスキップ・アクションの追加

表14-3 パイプライン - メッセージ処理アクション

アクション

説明

詳細

割当て

コンテキスト変数にXQuery式の結果を割り当てます。

コンソールでの割当てアクションの追加

削除

XPath式で指定されたコンテキスト変数または一連のノードを削除します。

コンソールでの削除アクションの追加

挿入

XPath式で選択したノードを基準として特定された場所にXQuery式の結果を挿入します。

挿入アクションの追加

Javaコールアウト

パイプラインからJavaメソッドを呼び出します。

コンソールでのJavaコールアウト・アクションの追加

JavaScript

JavaScript式を使用するXMLまたはJSONペイロードのコンテンツを操作します。

コンソールでのJavaScriptアクションの追加

MFL変換

パイプラインで非XMLからXML、またはXMLから非XMLに変換します。

コンソールでのMFL変換アクションの追加

nXSD変換

パイプラインで、ネイティブ・データ・フォーマット(nXSD)からXMLに、またはXMLからネイティブ・データ・フォーマット(nXSD)に変換します。

nXSD変換アクションの追加

名前変更

要素のコンテンツを変更せずに、XPath式で選択した要素の名前を変更します。

コンソールでの名前変更アクションの追加

置換

XPath式で指定されたノードまたはノードのコンテンツを置き換えます。

コンソールでの置換アクションの追加

検証

XMLスキーマ要素またはWSDLリソースに対して、XPath式で選択した要素を検証します。

コンソールでの検証アクションの追加

表14-4 パイプライン - レポート・アクション

アクション

説明

詳細

アラート

パイプラインのメッセージ・コンテキストに基づいて、アラート通知を送信します。

コンソールでのアラート・アクションの追加

ログ

ログに記録するメッセージを作成します。

コンソールでのログ・アクションの追加

レポート

プロキシ・サービスのメッセージ・レポートを有効にします。

コンソールでのレポート・アクションの追加

3. アクションを追加したら、表14-5に示すように、さらにステージまたはルート・ノードのアクションを構成できます。

表14-5 ステージ構成の編集タスク

内容

この手順を完了するには...

アクションの削除

該当するアイコンを選択してから、「このアクションを削除」をクリックします。

アクションを下に移動する(降格する)

該当するアイコンを選択してから、「アクションを下に移動」をクリックします。アクションがこのステージに含まれる次のアクションの下に移動します。

このオプションは、ステージに2つ以上のアクションが含まれる場合にのみ表示されます。

アクションを上に移動する(昇格する)

該当するアイコンを選択してから、「アクションを上に移動」をクリックします。アクションがこのステージに含まれる前のアクションの上に移動します。

このオプションは、ステージに2つ以上のアクションが含まれる場合にのみ表示されます。

アクションの切取り

該当するアイコンを選択してから、「切取り」をクリックします。

アクションのコピー

該当するアイコンを選択してから、「コピー」をクリックします。

切り取りまたはコピーしたアクションを貼り付ける

該当するアイコンを選択してから、「アクションの貼付け」をクリックします。

アクションのコピーと貼付けは、ステージ全体で可能です。ただし、「割当て」アクション、「置換」アクション、または「挿入」アクションの場合は、次の点に注意してください。

- ソース(コピー)ステージの変数関連およびユーザー定義のすべてのネームスペースは、ターゲット(貼付け)ステージではユーザー定義のネームスペースとして追加されます。

- 重複するネームスペース(ソース・ステージおよびターゲット・ステージ両方で同一のネームスペース)はコピーされません。

- 競合するネームスペース(同じ接頭辞を使用しているがURIの異なるネームスペース宣言)はコピーされます。構成の保存は可能でありますが、ステージBの競合するネームスペース宣言を削除しないかぎり、アクティブ化することはできません。

ステージの検証

「ステージ構成の編集」ページで、「検証」をクリックして、そのステージで構成したすべてのアクションを検証します。有効化されたアクションのみが検証されます。

ステージが無効の場合、「検証」ボタンは使用できません。

4. 「保存」をクリックして、現在のセッションで更新をコミットします。

5. 「メッセージ・フローの編集」ページで、「コンソールでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

6. 「保存」をクリックして、現在のセッションで更新をコミットします。

7. セッションを終了して構成をランタイムにデプロイするには、Oracle Service Busコンソールの右上隅にある「アクティブ化」をクリックします。

14.2 コンソールでのパブリッシュ・アクションの追加

静的に指定された、メッセージのターゲット・サービスを指定し、メッセージのパッケージおよびサービスへの送信方法を構成するには、パブリッシュ・アクションを使用します。パブリッシュの動作の詳細は「パイプラインでのトランスフォーメーションの実行」を参照してください。

パブリッシュ・アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 「アクションの追加」→「通信」→「パブリッシュ」を選択します。

3. 「サービス」をクリックします。「サービスの選択」ページが表示されます。

4. リストからサービスを選択してから、「発行」をクリックします。これがメッセージのターゲット・サービスとなります。

5. サービスの操作がすでに定義されている場合、「操作」リストから選択して、呼び出す操作を指定できます。

6. アウトバウンド処理をインバウンド処理と同じにする場合、「インバウンド操作のアウトバウンドでの使用」チェックボックスを選択します。

7. メッセージのパッケージとサービスへの送信方法を構成するために、「リクエスト・アクション」フィールドで「アクションの追加」をクリックします。その後で、サービスと関連付けるアクションを選択します。複数のアクションを追加することも可能です。「コンソールでのパイプライン・アクションの追加と編集」を参照してください。

8. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.3 コンソールでのパブリッシュ表アクションの追加

ゼロまたはそれ以上の静的に指定されたサービスにメッセージをパブリッシュするには、パブリッシュ表アクションを使用します。切替え式の条件ロジックを使用して、どのサービスをパブリッシュに使用するか実行時に決定します。

パブリッシュの動作の詳細は「パイプラインでのトランスフォーメーションの実行」を参照してください。

パブリッシュ表アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 「アクションの追加」→「通信」→「パブリッシュ表」を選択します。

3. 「式」をクリックします。XQuery式エディタ・ページが表示されます。実行時にルーティングの決定を行う値を返すXQuery式を作成します。インラインXQueryおよびXPath式の作成と編集を参照してください。

4. 「演算子」リストから、比較演算子を選択します。その後で、隣のフィールドに、XQuery式から返される値が評価される対象の値を入力します。

5. 「サービス」をクリックして、指定した値の式による評価がtrueの場合にメッセージをパブリッシュするサービスを選択します。「サービスの選択」ページが表示されます。

6. リストからサービスを選択してから、「発行」をクリックします。これがメッセージのターゲット・サービスとなります。

7. サービスの操作がすでに定義されている場合、「invoking」リストから選択して、呼び出す操作を指定できます。

8. アウトバウンド操作をインバウンド操作と同じにする場合、「Use inbound operation for outbound」チェック・ボックスを選択します。

9. メッセージのパッケージとサービスへの送信方法を構成するために、「リクエスト・アクション」フィールドで「アクションの追加」をクリックし、サービスと関連付ける1つ以上のアクションを選択します。追加するアクションのタイプの詳細は、「コンソールでのパイプライン・アクションの追加と編集」を参照してください。

10. 新しいケースを挿入するには、「Case」アイコンをクリックし、「Insert New Case」を選択します。

11. 新しいケースについて、ステップ4 - 8を繰り返します。

12. ビジネス・ロジックで指定されているようにケースを追加します。

13. 最後に定義したケースの「Case」アイコンをクリックして、「Insert Default Case」を選択し、デフォルト・ケースを最後に追加します。

14. デフォルト・ケースを構成します。このケースの構成では、それ以前のケースが満たされていない場合のルーティングの動作を指定します。

15. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.4 コンソールでの動的パブリッシュ・アクションの追加

XQuery式によって指定されたサービスに対してメッセージをパブリッシュするには、動的パブリッシュ・アクションを使用します。パブリッシュの動作の詳細は「パイプラインでのトランスフォーメーションの実行」を参照してください。

動的パブリッシュ・アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「通信」→「動的にパブリッシュ」を選択します。

3. 「式」をクリックします。

4. XQuery式エディタで、XQuery式を入力するか、次と同様の結果となるXQueryリソースを選択します。

<ctx:route>
<ctx:service isProxy="false">project/folder/businessservicename</ctx:service>
<ctx:operation>foo</ctx:operation>
</ctx:route>

注意:

プロキシ・サービスが呼び出されている場合は、isProxyをtrueに設定します。ビジネス・サービスが呼び出されている場合は、isProxyをfalseに設定します。

operation要素は省略可能です。

または、次のコードでパイプラインにルーティングします。

<ctx:route>
<ctx:pipeline>project/folder/pipeline</ctx:pipeline>
</ctx:route>

または、次のコードで分割結合にルーティングします。

<ctx:route>
<ctx:splitjoin>project/folder/splitjoin</ctx:splitjoin>
</ctx:route>

5. 「保存」をクリックします。

6. 「要求アクション」フィールドの「アクションの追加」をクリックしてアクションを追加したうえで、そのサービスに関連付けるアクションを選択します。複数のアクションを追加することも可能です。追加できるアクションのタイプの詳細は、「コンソールでのパイプライン・アクションの追加と編集」のアクションの表を参照してください。

7. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.5 コンソールでのルーティング・オプション・アクションの追加

$outboundのアウトバウンド・リクエストのURI、サービスの品質、モードおよび再試行パラメータの一部またはすべてを変更するには、ルーティング・オプション・アクションを使用します。これらのプロパティは、$outbound上の割当て、挿入、置換または削除アクションで変更できますが、ルーティング・オプションを使用すると、XPath、XQueryまたは$outboundコンテキスト変数の構造を理解していなくてもこのタスクを実行できます。

ルーティング・オプションのアクションはコンテキスト変数$outboundが有効な場合にのみ使用できます。次のアクションに追加できます。

- パブリッシュ

- 動的にパブリッシュ

- パブリッシュ表

- サービス・コールアウト

- ルーティング

- 動的ルーティング

- ルーティング表

ルーティングの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。

ルーティング・オプションのアクションを構成するには

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「通信」→「ルーティング・オプション」を選択します。

3. 次の手順のいずれか、またはすべてを実行します。

- アウトバウンド・メッセージのURIを設定する場合: 「URI」を選択して、XQuery式エディタをクリックします。URIを返す式を入力します。これで呼び出されたサービスのURIがオーバーライドされます。

注意:

別のプロキシ・サービスにルーティングする場合は、URIのオーバーライドは無効です。

- サービス品質要素を設定する場合: 「サービス品質」を選択して、リストで「サービス品質」オプションを選択します。これで、自動計算されたデフォルトがオーバーライドされます。

- モードを設定するには、「モード」を選択して、リストから「リクエスト」または「リクエスト-レスポンス」を選択します。

注意:

これは、通常、呼び出されたサービスのインタフェースに基づいて、自動的に設定されています。Any SoapまたはAny XMLサービスなどでは、設定されていない場合もあります。

- 再試行間隔を設定する場合: 「再試行間隔」を選択して、再試行の間隔を秒単位で指定します。これで呼び出されたサービスで構成されたデフォルトがオーバーライドされます。

- 再試行回数を設定する場合: 「再試行回数」を選択して、アクションを中断するまでの再試行回数を指定します。これで呼び出されたサービスで構成されたデフォルトがオーバーライドされます。

- メッセージの優先度を設定する場合: 「優先度」を選択して、XQuery式エディタをクリックします。正の整数を返す式を入力します。

4. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.6 コンソールでのサービス・コールアウト・アクションの追加

Service Busに登録済のプロキシ・サービスまたはビジネス・サービスの同期(ブロッキング)コールアウトを構成するには、サービス・コールアウト・アクションを使用します。サービス・コールアウト・アクションの詳細は「サービス・コールアウト・メッセージの作成」を参照してください。

サービス・コールアウト・アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「通信」→「サービス・コールアウト」を選択します。

3. 「サービス」をクリックします。サービス・ブラウザが表示されます。

4. 登録済のプロキシ・サービスまたはビジネス・サービスのリストでサービスを選択し、「発行」をクリックします。

5. 前述のステップ3で選択したサービスがWSDLベースであり、サービスで呼び出せる操作がある場合、これらの操作は操作の呼出しリストに一覧表示されます。サービスで呼び出す操作を選択します。

注意:

様々な理由からService Busで必要とする操作を選択すると、選択した操作のみが呼び出されることは保証されません。たとえば、操作Aを選択した場合でも、メッセージに操作Bの呼び出しが含まれていると、操作Bも呼び出されます。

6. 次のいずれかのオプションを選択して、リクエスト・メッセージとレスポンス・メッセージの構成方法を指定します。

- 「SOAP本体の構成」を選択して、SOAP本体を構成します。このオプションを選択すると、$bodyを直接使用できます。

注意:

このオプションでサポートしているSOAP-RPCエンコード形式は、ペイロードのパラメータやドキュメントを構成している場合はサポートされません。

- 「ペイロード・パラメータの構成」または「ペイロード・ドキュメントの構成」を選択して、ペイロードを構成します。

7. 以降の構成オプションは、選択したサービスの種類とそのサービスに対して選択した構成オプションによって異なります。

表14-6に、各オプションの手順を示します。

表14-6 サービス・コールアウトの構成オプション

対象オプション...

次の手順を実行...

「SOAPリクエスト本体」および 「SOAPレスポンス本体」

これらのオプションを構成するには、次の手順を実行します。

- 「SOAPリクエスト本体」フィールドに、コールアウト・リクエストのSOAP本体要素のXMLを保持する変数の名前を入力します。

- 「SOAPレスポンス本体」フィールドに、レスポンスのSOAP本体要素のXMLがバインドされる変数の名前を入力します。

「リクエスト添付ファイル変数」および「レスポンス添付ファイル変数」

これらのオプションを構成するには(オプション):

- 「リクエスト添付ファイル変数」フィールドに、アウトバウンド・リクエスト添付ファイルに対応するXMLを保持する変数の名前を入力します。

- 「レスポンス添付ファイル変数」フィールドに、アウトバウンド・レスポンス添付ファイルに対応するXMLを保持する変数の名前を入力します。

「SOAPリクエスト・ヘッダー」および 「SOAPレスポンス・ヘッダー」

これらのオプションを構成するには、次の手順を実行します。

- 「SOAPリクエスト・ヘッダー」フィールドに、コールアウト・リクエストのSOAPヘッダー要素のXMLを保持する変数の名前を入力します。
SOAPリクエスト・ヘッダーの入力ドキュメントは、<soap-env:Header>...</soap-env:Header>でラップする必要があります。

- 「SOAPレスポンス・ヘッダー」フィールドに、レスポンスのSOAPヘッダー(存在する場合)のXMLがバインドされる変数の名前を入力します。

「リクエスト・パラメータ」および 「レスポンス・パラメータ」

オプションを構成するには、次の手順を実行します。

- 「リクエスト・パラメータ」フィールドに、実行時に評価される、リクエスト・パラメータの値を指定する変数の名前を入力します。
入力変数にはコアのペイロード・ドキュメントのみを指定します。SOAPパッケージは、Service Busによって自動的に作成されます。そのため、入力ドキュメントを<soap-env:Body>...</soap-env:Body>でラップしません。

たとえば、このリクエスト・パラメータに使用されるbody入力変数を作成する場合は、$body (soap-env:Bodyラッパーが保持されます)ではなく、body/*(ラッパーsoap-env:Bodyを削除します)というXPath文を使用して、その変数のコンテンツを定義します。

- 「レスポンス・パラメータ」フィールドに、実行時にレスポンスを割り当てる変数の名前を入力します。

「リクエスト・ドキュメント」および 「レスポンス・ドキュメント」

これらのオプションを構成するには、次の手順を実行します。

- 「リクエスト・ドキュメント変数」フィールドに、リクエスト・ドキュメントを割り当てる変数の名前を入力します。
SOAPドキュメント・タイプのサービスの場合、サービスに送信されるSOAPメッセージの本文を作成する変数は、実行時に評価されます。「任意のXML」サービスの場合、サービスに送信されるXMLメッセージの本文を作成する変数は、実行時に評価されます。

SOAPドキュメント・タイプのサービスおよび任意のXMLサービスの場合、入力変数にはコアのペイロード・ドキュメントのみを指定します。SOAPパッケージは、Service Busによって自動的に作成されます。そのため、入力ドキュメントを<soap-env:Body>...</soap-env:Body>でラップしません。

たとえば、このリクエスト・パラメータに使用されるbody入力変数を作成する場合は、$body (soap-env:Bodyラッパーが保持されます)ではなく、body/*(ラッパーsoap-env:Bodyを削除します)というXPath文を使用して、その変数のコンテンツを定義します。

メッセージ・サービスの場合、メッセージの本文を作成する変数は、サービスが予期するデータ型に基づいて評価されます。次の制限は、メッセージ・サービスで使用される変数に適用されます。

- バイナリ・データを受信するサービスの場合は、変数にctx:binary-content要素が必要です。

- MFLデータを受信するサービスの場合は、変数に同等のXMLデータが必要です。

- テキスト・データを受信するサービスの場合、変数は文字列になります。

- 「レスポンス・ドキュメント変数」フィールドに、実行時にレスポンス・ドキュメントを割り当てる変数の名前を入力します。

8. (オプション)1つ以上のトランスポート・ヘッダーを追加します。詳細は、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。

注意:

指定するトランスポート・ヘッダーに加え、その他のヘッダーがService Busバインディング・レイヤーによって追加されます。詳細は、「パイプラインでのトランスポート・ヘッダーの構成」を参照してください。

9. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.7 コンソールでのトランスポート・ヘッダー・アクションの追加

メッセージのヘッダーの値を設定するには、トランスポート・ヘッダー・アクションを使用します。

トランスポート・ヘッダー・アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「通信」→「トランスポート・ヘッダー」を選択します。

3. 「のトランスポート・ヘッダーを設定」リストから、次のいずれかを選択して、どのメッセージ・コンテキストの場所を変更するかをランタイムに対して指定します。

- 「アウトバウンド・リクエスト」 - アウトバウンド・リクエスト(ルート、パブリッシュまたはサービス・コールアウト・アクションでプロキシ・サービスによって送信されるメッセージ)のトランスポート・ヘッダーの値を設定するには、このオプションを選択します。これらのヘッダー要素は、メッセージ・コンテキストの次の場所にあります。

$outbound/ctx:transport/ctx:request/tp:headers

- 「インバウンド・レスポンス」 - インバウンド・レスポンス(プロキシ・サービスがクライアントに返信するレスポンス・メッセージ)のトランスポート・ヘッダーの値を設定するには、このオプションを選択します。これらのヘッダー要素は、メッセージ・コンテキストの次の場所にあります。

$inbound/ctx:transport/ctx:response/tp:headers

4. (オプション)すべてのヘッダーをインバウンド・メッセージとアウトバウンド・メッセージとの間でパススルーするには、「パイプラインを介してすべてのヘッダーを渡す」を選択します。ソース・ヘッダー・セットのすべてのヘッダーはターゲット・ヘッダー・セットにコピーされ、ターゲット・ヘッダー・セットの既存の値はすべて上書きされます。
ヘッダー固有のパス・スルー・オプションに関連してこのオプションを使用する方法の詳細は、「パイプラインでのトランスポート・ヘッダーの構成」を参照してください。

5. 追加する各ヘッダーについて、次の手順を行います。

a. 「トランスポート・ヘッダー」表で「ヘッダーの追加」をクリックして、ヘッダーを構成するためのフィールドを表示します。

b. 次のいずれかを実行して、ヘッダーを指定します。

- 「名前」列のリストから、ヘッダー名を選択します。リストには、事前定義されたすべてのターゲット・トランスポートのヘッダー名が含まれています(たとえば、HTTPトランスポートの場合はContent-Type、JMSトランスポートの場合はJMSCorrelationIDなど)。

- 「その他」フィールドにヘッダー名を入力します。ヘッダー名がこのサービスのトランスポート用に事前定義されたいずれかのヘッダーでない場合、そのヘッダーはトランスポート仕様の定義のとおりユーザー・ヘッダーになります。

c. 「アクション」列でいずれかのオプションを選択して、ヘッダーの値の設定方法を指定します。
ヘッダーを式に設定

このオプションを選択すると、XQuery式またはXSLT式を使用して、ヘッダーの値を設定できます。「text/xml」などの簡単な式にすることも、複雑なXQuery式またはXSLT式にすることもできます。

Service Busトランスポート・レイヤーでは、すべてのヘッダーのXML表現を文字列値として定義するため、式の結果は、ヘッダーの値が設定される前に文字列に変換されます。何も返さない式のヘッダーの値は、空の文字列に設定されます。式を使用してヘッダーを削除することはできません。

警告:

このアクションで指定できるヘッダー設定がすべて実行時に反映されるわけではありません。設定できる所定のトランスポートのヘッダーおよび実行時に反映されるそれらの設定の詳細は、「パイプラインでのトランスポート・ヘッダーの構成」を参照してください。

ヘッダーの削除

リクエストまたはレスポンスのメタデータからヘッダーが削除されるように指定します。

「インバウンド・リクエストからヘッダーをコピー」(アウトバウンド・リクエストのトランスポート・ヘッダーを設定している場合)

または

「アウトバウンド・レスポンスからヘッダーをコピー」(インバウンド・レスポンスのトランスポート・ヘッダーを設定している場合)

このヘッダーがインバウンド・メッセージの同じ名前を持つ対応するヘッダーからアウトバウンド・メッセージに、またその逆に直接コピーされるように指定します。たとえば、アウトバウンド・リクエストのSOAPActionヘッダーを設定する場合は、「インバウンド・リクエストからヘッダーをコピー」を選択すると、ランタイムが$inboundのSOAPActionリクエスト・ヘッダーから値をコピーします。インバウンド・レスポンス・ヘッダーの場合、コピーするヘッダーのソースは、$outboundのレスポンス・ヘッダーです。

ソースに存在しないヘッダーについて「ヘッダーのコピー」オプションが選択された場合、このオプションは無視され、このヘッダーのターゲットではアクションが実行されません。

グローバルな「パイプラインを介してすべてのヘッダーを渡す」オプションに関連してこのオプションを使用する方法の詳細は、「パイプラインでのトランスポート・ヘッダーの構成」を参照してください。

6. 表にヘッダーを追加するには、「ヘッダー」アイコンをクリックし、「ヘッダーの追加」をクリックします。
この表を展開すると、別のトランスポート・ヘッダーの構成に使用できる新しい一連のオプションを含む追加の行が表示されます。この表には、必要な数のヘッダーを追加することができます。ランタイムでは、対応するXMLの生成時に、ネームスペースを宣言し、適切な順序でヘッダー要素を配置するため、表のヘッダーの順序を指定する必要はありません。

7. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.7.1 アウトバウンドHTTPトランスポート・ヘッダーでのCookieの設定

HTTPパイプラインでは、次の方法でトランスポート・ヘッダーにCookieを設定できます。

- 複雑なXML式としてのCookieの設定

- 文字列式を使用したCookieの設定

14.7.1.1 複雑なXML式としてのCookieの設定

複雑なXML式を使用してCookieを設定する(Service Busのデフォルト・フォーマット)には、次の式の構文を使用して、アウトバウンド・リクエストのHTTP Cookieヘッダーの値を構成します。

<cookie-values xmlns="http://www.bea.com/wli/sb/transports/http">
<value>{fn:concat("cookie_name", "=", "cookie_value")}</value>
</cookie-values>

14.7.1.2 文字列式を使用したCookieの設定

アウトバウンド・リクエストで文字列を含むCookieヘッダーを設定するには、ドメインのstartWebLogicコマンドに次のオプションを追加する必要があります。

-Dcom.bea.osb.http.cookieAsNoComplexElement=true

このオプションを使用してサーバーを再起動した後、文字列式を使用してHTTP Cookieヘッダーを設定することができます。次に例を示します。

$cookie_name = "cookie_value"

14.8 コンソールでのルート・ノードへの動的ルーティングの追加

XQueryリソースで使用できるルーティング情報に基づいて、メッセージ・ルートを割り当てます。これは終端アクションなので、このアクションの後に別のアクションを追加することはできません。ただし、このアクションには、リクエストとレスポンスのアクションを含めることができます。動的ルーティングの詳細は、「動的ルーティングの使用」を参照してください。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

ルート・ノードに動的ルーティングを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 「ルート・ノード」アイコンをクリックして「ルートの編集」をクリックします。「ステージ構成の編集」ページが表示されます。

3. 「アクションの追加」アイコンをクリックして、「通信」→「動的ルーティング」を選択します。

4. 「式」をクリックします。XQuery式エディタが表示されます。

5. XQuery式エディタで、XQuery式を入力します。次のような結果になります。

<ctx:route>
<ctx:service isProxy='true'>{$service}</ctx:service>
<ctx:operation>{$operation}</ctx:operation>
</ctx:route>

注意:

プロキシ・サービスが呼び出されている場合は、isProxyをtrueに設定します。ビジネス・サービスが呼び出されている場合は、isProxyをfalseに設定します。

- サービス名は完全修飾サービス名です。

- 操作要素はオプションです。

または、次のコードでパイプラインにルーティングします。

<ctx:route>
<ctx:pipeline>project/folder/pipeline</ctx:pipeline>
</ctx:route>

または、次のコードで分割結合にルーティングします。

<ctx:route>
<ctx:splitjoin>project/folder/splitjoin</ctx:splitjoin>
</ctx:route>

6. 「保存」をクリックします。

7. 「要求アクション」フィールドの「アクションの追加」をクリックしてアクションを追加したうえで、そのサービスに関連付けるアクションを選択します。複数のアクションを追加することも可能です。追加するアクションのタイプの詳細は、「コンソールでのパイプライン・アクションの追加と編集」のアクションの表を参照してください。

8. 「応答アクション」フィールドの「アクションの追加」をクリックしてアクションを追加したうえで、そのサービスに関連付けるアクションを選択します。複数のアクションを追加することも可能です。追加するアクションのタイプの詳細は、「コンソールでのパイプライン・アクションの追加と編集」のアクションの表を参照してください。

9. 「保存」をクリックします。

10. 「メッセージ・フローの編集」ページで、「コンソールでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

11. 「保存」をクリックして、現在のセッションで更新をコミットします。

12. セッションを終了して構成をランタイムにデプロイするには、Oracle Service Busコンソールの右上隅にある「アクティブ化」をクリックします。

14.9 コンソールでのルート・ノードへのルーティング・アクションの追加

そのメッセージのターゲット・サービスを指定し、サービスへのメッセージのルーティング方法を構成します。これは終端アクションなので、このアクションの後に別のアクションを追加することはできません。ただし、このアクションには、リクエストとレスポンスのアクションを含めることができます。ルーティングの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

ルート・ノードにルーティング・アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 「ルート・ノード」アイコンをクリックして「ルートの編集」をクリックします。「ステージ構成の編集」ページが表示されます。

3. 「アクションの追加」アイコンをクリックして、「通信」→「ルーティング」を選択します。

4. 「サービス」をクリックします。サービス・ブラウザが表示されます。

5. リストからサービスを選択してから、「発行」をクリックします。そのサービスがデフォルトのリンクのかわりに表示されます。

6. アウトバウンド操作をインバウンド操作と同じにする場合、「Use inbound operation for outbound」チェック・ボックスを選択します。

7. 「要求アクション」フィールドの「アクションの追加」をクリックしてアクションを追加したうえで、そのサービスに関連付けるアクションを選択します。複数のアクションを追加することも可能です。追加できるアクションのタイプの詳細は、「コンソールでのパイプライン・アクションの追加と編集」のアクションの表を参照してください。

8. 「応答アクション」フィールドの「アクションの追加」をクリックしてアクションを追加したうえで、そのサービスに関連付けるアクションを選択します。複数のアクションを追加することも可能です。追加できるアクションのタイプの詳細は、「コンソールでのパイプライン・アクションの追加と編集」のアクションの表を参照してください。

9. 「保存」をクリックします。

10. 「メッセージ・フローの編集」ページで、「コンソールでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

11. 「保存」をクリックして、現在のセッションで更新をコミットします。

12. セッションを終了して構成をランタイムにデプロイするには、「チェンジ・センター」の「アクティブ化」をクリックします。

14.10 コンソールでのルート・ノードへのルーティング表の追加

ルーティング表は、切替え式の条件表にラップされた一連のルートです。これは、単一のXQuery式の結果に基づいて各種ルートを選択できる短縮形の構文です。ステージ・エディタで複数のレベルをネストできます。メッセージのターゲット・サービスを指定し、ターゲット・サービスへのメッセージのルーティング方法を構成します。

これは終端アクションなので、このアクションの後に別のアクションを追加することはできません。ただし、このアクションには、リクエストとレスポンスのアクションを含めることができます。ルーティングの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

ルート・ノードにルーティング表を追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 「ルート・ノード」アイコンをクリックして「ルートの編集」をクリックします。「ステージ構成の編集」ページが表示されます。

3. 「アクションの追加」アイコンをクリックして、「通信」→「ルーティング表」を選択します。ルーティング表アクションが表示されます。

4. 「演算子」リストから、比較演算子を選択して、隣のフィールドに値式を入力します。

5. 「サービス」をクリックします。「サービスの選択」ページが表示されます。

6. リストからサービスを選択してから、「発行」をクリックします。

7. サービスで操作を呼び出す場合は、「操作」リストから操作を選択します。

8. アウトバウンド操作をインバウンド操作と同じにする場合、「Use inbound operation for outbound」チェック・ボックスを選択します。

9. 「要求アクション」フィールドの「アクションの追加」をクリックしてアクションを追加したうえで、そのサービスに関連付けるアクションを選択します。複数のアクションを追加することも可能です。

10. 「応答アクション」フィールドの「アクションの追加」をクリックしてアクションを追加したうえで、そのサービスに関連付けるアクションを選択します。複数のアクションを追加することも可能です。

追加するリクエスト・アクションおよびレスポンス・アクションのタイプの詳細は、「コンソールでのパイプライン・アクションの追加と編集」を参照してください。

11. 新しいケースを挿入するには、「Case」アイコンをクリックし、「Insert New Case」を選択します。

12. 新しいケースについて、ステップ2 - 7を繰り返します。「ケース」アイコンをクリックして、「デフォルト・ケースの挿入」を選択すると、それ以前のすべてのケースが満たされなかった場合に選択されるルートのデフォルトのケースを末尾に追加できます。

13. 「保存」をクリックします。

14. 「メッセージ・フローの編集」ページで、「コンソールでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

15. 「保存」をクリックして、現在のセッションで更新をコミットします。

16. セッションを終了して構成をランタイムにデプロイするには、「チェンジ・センター」の「アクティブ化」をクリックします。

14.11 コンソールでのFor-Eachアクションの追加

For-Eachアクションは、一連の値を反復処理してアクションのブロックを実行するために使用します。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

For-Eachアクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「フロー制御」→「For Each」を選択します。

3. 「変数」フィールドに変数名を入力し、「XPath」をクリックして、XPath式を作成するためのXPathエディタを開きます。次に、Do ()ループでアクションを構成します。

4. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.12 コンソールでのIf-Thenアクションの追加

XQuery式のブール結果に基づき、1つまたは複数のアクションを条件付きで実行するには、if-thenアクションを使用します。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

If-Thenアクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「フロー制御」→「If...Then」を選択します。

3. 「条件」をクリックして、「XQuery条件エディタ」ページを表示します。

作成した条件は、then()句に入る前に、標準のif-thenロジックに従って実行されるテストとして使用されます。インラインXQueryおよびXPath式の作成と編集を参照してください。

4. XQuery条件を編集したら、「アクションの追加」をクリックしてから、その条件に関連付けるアクションを選択します。追加するアクションのタイプの詳細は、「コンソールでのパイプライン・アクションの追加と編集」を参照してください。

ルート・ノードでは、ルーティング・アクション、動的ルーティング・アクション、またはルーティング表アクションのみを選択できます。ただし、これらのアクションには、リクエストとレスポンスのアクションを入れることができます。

5. ロジックの必要性に応じて「If...Then」アイコンをクリックし、「else-if条件の追加」または「else条件の追加」をクリックしてelse-if条件またはelse条件を追加します。「アクションの追加」をクリックして、アクションをこれらの条件と関連付けます。

条件アクションはネストできます。

6. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.13 コンソールでのエラーの生成アクションの追加

指定したエラー・コード(文字列)と説明を使用して例外を発生させるには、エラーを発生させるアクションを使用します。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

エラー生成アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「フロー制御」→「エラーの生成」を選択します。

3. 「エラー・コード」フィールドに、発生させるエラー・コードを入力します。

4. 「エラー・メッセージ」フィールドに、エラー・コードの説明を入力します。

5. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.13.1 トランザクション

サービスがトランザクションの場合、トリガーされたエラー発生アクションにより、非同期のリクエストのトランザクションまたは同期のリクエスト/レスポンスのトランザクションが中断されます。たとえば、メッセージを参照し、SOAPフォルトは発生せず、エラーを発生させるアクションによりトランザクションが中断された場合にも、エラーの生成アクションが実行する際の条件を決定できます。

14.14 コンソールでの返信アクションの追加

呼出し元に即時に返信されるように指定するには、返信アクションを使用します。返信アクションは、リクエスト・パイプライン、レスポンス・パイプライン、またはエラー・パイプラインで使用できます。成功時または失敗時に返信するように構成できます。HTTPインバウンド・トランスポートでの失敗時の返信の場合、返信アクションでは、呼出し元に即時に返信されるように指定します。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

返信アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「フロー制御」→「返信」を選択します。

3. 「成功時」を選択すると、メッセージが成功した場合に応答します。「失敗時」を選択すると、メッセージが失敗した場合に応答します。

トランザクションがService Busによって起動されても、失敗時の応答によって中止されます。

4. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.15 コンソールでの再開アクションの追加

エラー・ハンドラによってエラーが処理された後で、メッセージ・フローを再開するには、再開アクションを使用します。このアクションにパラメータはありません。このアクションはエラー・パイプラインでのみ使用できます。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

再開アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「フロー制御」→「再開」を選択します。

完了した後に:

このアクションの構成が完了したら、「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、引き続き他のアクションを構成するか、この構成を保存します。

14.16 コンソールでのスキップ・アクションの追加

実行時にこのステージの実行がスキップされて、処理がパイプラインの次のステージに進むように指定するには、スキップ・アクションを使用します。このアクションにはパラメータがなく、リクエスト・パイプライン、レスポンス・パイプライン、エラー・パイプラインで使用できます。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

スキップ・アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「フロー制御」→「スキップ」を選択します。

14.17 コンソールでの割当てアクションの追加

XQuery式の結果をコンテキスト変数に割り当てるには、割当てアクションを使用します。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

割当てアクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「メッセージ処理」→「割当て」を選択します。

3. 「式」をクリックします。XQuery式エディタ・ページが表示されます。XQuery式を使用して、名前付き変数に割り当てるデータを作成します。インラインXQueryおよびXPath式の作成と編集を参照してください。

4. 式を編集したら、変数フィールドにコンテキスト変数を入力します。コンテキスト変数の詳細は、「inbound変数とoutbound変数」および「ディスパッチするメッセージの作成」を参照してください。

5. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.18 コンソールでの削除アクションの追加

削除アクションは、コンテキスト変数またはXPath式で指定したすべてのノードを削除するときに使用します。削除アクションは一連の更新アクションの1つです。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

削除アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. コンテキスト変数を削除するには、「変数」オプションを選択し、コンテキスト変数の名前を「変数」フィールドに入力します。

または、XPath式で選択されたすべてのノードを削除するには、「XPath」ラジオ・ボタンを選択して、「XPath」をクリックします。「XPath式エディタ」ページが表示されます。インラインXQueryおよびXPath式の作成と編集を参照してください。式を保存したら、「変数」フィールドにコンテキスト変数を入力します。

14.19 挿入アクションの追加

XPath式で選択したノードを基準に、指定した位置にXQuery式を挿入するには、挿入アクションを使用します。挿入アクションは更新アクションの1つです。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

挿入アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「メッセージ処理」→「挿入」を選択します。

3. 「式」をクリックして、XQuery式を編集します。XQuery式を使用して、名前付き変数で指定された場所に挿入されるデータを作成します。XQuery式エディタ・ページが表示されます。インラインXQueryおよびXPath式の作成と編集を参照してください。

4. 式を編集したら、リストで相対的な位置を選択します。相対的な位置は、XPath式の結果を基準として挿入位置を決める場合に使用します。

- の前に: XPath式で選択される各要素や属性の兄とします。

- の後ろに: XPath式で選択される各要素や属性の弟とします。

- の最初の子として: XPath式で指定される各要素の第1の子とします。XPathの結果が属性を返す場合はエラーが発生します。

- の最後の子として: XPath式で指定される各要素の最後の子とします。XPathが属性を返す場合はエラーが発生します。

5. 「XPath」をクリックします。「XPath式エディタ」ページが表示されます。インラインXQueryおよびXPath式の作成と編集を参照してください。

有効な構成には、次の構成が含まれます。

- XQuery式とXPath式の両方が要素を返します。

- XQuery式とXPath式の両方が属性を返します。この場合、XQuery式は属性を返す必要があります。

6. XPath式の編集が終わったら、「変数」フィールドにコンテキスト変数を入力します。XPathは、この変数の内容を評価します。

7. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.20 コンソールでのJavaコールアウト・アクションの追加

パイプラインからJavaメソッドまたはEJBビジネス・サービスを呼び出すには、Javaコールアウト・アクションを使用します。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

Javaコールアウト・アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「メッセージ処理」→「Javaコールアウト」を選択します。

3. 「メソッド」をクリックします。「JARの選択」ページが表示されます。リストからJARリソースを選択します。「クラスとメソッドの選択」ページが表示されます。

4. 表示されたJavaクラスのリストで、該当するクラスの横にある+をクリックしてメソッドのリストを表示します。メソッドを選択して、「発行」をクリックします。「ステージの編集」ページに、次のようにJavaコールアウト・アクションが表示されます。

- 「メソッド」はステップ2および3で選択したJavaメソッドの名前に置き換えられます。この名前は「クラスとメソッドの選択」ページへのリンクです。このリンクをクリックして、Javaメソッドの選択内容を変更することができます。
メソッドは静的メソッドである必要があります。

- パラメータ: Javaメソッドが必要とする各引数に対するXQuery式エディタ・ページへの「式」リンクが用意されています。それぞれのリンクに対するラベルは、引数のデータ型を示します。これは次のいずれかです。

- Java.lang.String

- プリミティブ型および対応するクラス型(intとjava.lang.Integerなど)

- java.lang.BigDecimalおよびjava.lang.BigInteger(これらの型は、ラウンドオフ・エラーやオーバーフローが許容されない財務関連の計算で使用されます)

- org.apache.xbeans.XmlObjectのみ(型指定されたXML Beanはなし)

- byte[]

- java.lang.String[](入力のみ)

- XmlObject[](入力のみ)

- javax.activation.DataSource

- 結果: 結果を割り当てる変数を入力する「結果」フィールド。このフィールドに対するラベルは、結果のデータ型を示します。

注意:

結果がバイト配列(唯一返される可能性のある配列)の場合は、バイナリ・コンテンツのXML要素が返されます。

- パラメータを参照として戻す: このオプションにより、jcidがパイプライン・オブジェクト・リポジトリのオブジェクトへのキーである実際のタイプに関係なく、Javaコールアウトの呼出しの戻り値を<java-content ref="jcid">参照要素にします。「結果」値フィールドに、java-content参照を含む変数の名前を入力します。このオプションを使用すると、パススルーを提供するか、Javaコールアウトおよびインライン・アクションでメッセージ情報追加を実行するか、Javaと非Javaトランスポート間でメッセージ変換を実行するために、パイプラインXMLに加えてパイプラインで参照オブジェクトを処理できます。詳細は、「メッセージでのJavaオブジェクトの送信および受信」を参照してください。

- サービス・アカウントをアタッチ: 「サービス・アカウント」リンクでは、Javaメソッドに対するセキュリティ・コンテキストがある場合、オプションのサービス・アカウントを指定できます。セキュリティ・コンテキストおよびサービス・アカウントの詳細は、「サービス・アカウントの操作」を参照してください。
固定およびマップされたサービス・アカウントの場合、そのサービス・アカウントのユーザーID/パスワードはローカル・システムとJavaコールアウトに伝播されたセキュリティ・コンテキストで認証されます。passthruの場合、セキュリティ・コンテキストはJavaコールアウトに伝播されます。(WS-Securityで)定義されている場合、このコンテキストは、メッセージ・レベルのコンテキストになります。そうでない場合は、トランスポート・レベルのコンテキストになります。

5. 「パラメータ」で、「式」をクリックします。XQuery式エディタ・ページが表示されます。XQuery式エディタを使用して、Javaメソッドに必要な引数を指定します。インラインXQueryおよびXPath式の作成と編集を参照してください。

入力値の型が宣言されている入力引数の型と一致しない場合、Service Busは入力値を入力引数の宣言された型に自動的に型キャストします。たとえば、入力引数の宣言された型がJavaプリミティブ「int」の場合、文字列値"123"は整数123に変換されます。

6. 「結果」フィールドで、Javaメソッドが戻した結果に対して、変数を割り当てます。

7. Javaメソッドに対するセキュリティ・コンテキストがある場合は、チェックボックスを選択して、「サービス・アカウント」をクリックします。「サービス・アカウントの選択」ページが表示されます。リストから必要なサービス・アカウントを選択して、「発行」をクリックします。

8. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.21 コンソールでのJavaScriptアクションの追加

JavaScriptアクションを使用して、JavaScript式を使用するXMLまたはJSONペイロードのコンテンツを操作します。

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

JavaScriptアクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「メッセージ処理」→「JavaScript」を選択します。

3. 次のいずれかの方法で、JavaScript式を入力します。

- To

- Service BusコンソールにすでにアップロードされているJavaScriptリソースからJavaScript式を使用するには、「リソース: {0}」オプションを選択し、「リソース」をクリックします。「JavaScriptの選択」ダイアログを使用して、JavaScriptリソースを検索して選択します。

4. 次のいずれかのタイムアウト・オプションを選択します。

- 「システム・デフォルト」: JavaScriptの処理は、システム・デフォルトのJavaScriptタイムアウトに達するとタイムアウトします。

- 「秒」フィールド: JavaScript処理がタイムアウトになるタイムアウト値(秒)を指定します。

- なし: JavaScriptの処理はタイムアウトしません。

5. JavaScript式を検証するには、「検証」をクリックします。

6. 「保存」をクリックします。

14.22 コンソールでのMFL変換アクションの追加

MFL (Message Format Language)変換アクションを使用して、メッセージ・パイプライン内でメッセージ・コンテンツをXMLとXML以外の形式との間で変換します。MFLは、バイナリ・データのレイアウトを記述するために使用する特別なXMLドキュメントです。Oracle独自の言語を使用して、フォーマットされたバイナリ・データをXMLデータに、またはXMLデータをバイナリ・データに変換するルールを定義します。「Message Format Languageを使用したデータ構造の定義」を参照してください。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

MFL変換アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「メッセージ処理」→「MFL変換」を選択します。

3. MFL変換を適用リストから、「XMLから非XMLへ」または「非XMLからXMLへ」を要件に応じて選択します。

4. 「式」をクリックします。XQuery式エディタを使用して、MFL変換アクションを実行する変数を指定します。この入力は、XMLへの変換の場合はテキストまたはバイナリ、XML以外への変換の場合はXMLである必要があります。メッセージ・コンテキストのバイナリ・コンテンツは、バイナリ・コンテンツXML要素によって表されます。入力がバイナリでなければならない場合、このXMLはXQuery式の結果となります。インラインXQueryおよびXPath式の作成と編集を参照してください。

5. 次のいずれかのオプションを選択します。

- MFLリソース: 「リソース」リンクをクリックします。「MFLの選択」ページが表示されます。MFL変換アクションを実行する静的なMFLリソースを選択します。

- からのMFLリソース: 「式」リンクをクリックします。XQuery式エディタ・ページが表示されます。XQuery式エディタを使用して、変換アクションを実行するMFLリソースを動的に指定するXQuery式を、project/folder/MFLresourcenameの形式で作成または編集します。インラインXQueryおよびXPath式の作成と編集を参照してください。

6. 変数に割当てフィールドで、この変換アクションの結果を割り当てる変数名を入力します。結果は、バイナリ・コンテンツのXML要素になります。

7. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.23 nXSD変換アクションの追加

nXSD変換アクションを使用して、メッセージ・パイプライン内でメッセージ・コンテンツをXMLとネイティブ・フォーマット・データとの間で変換します。変換に使用するネイティブ・スキーマの作成の詳細は、テクノロジ・アダプタの理解のネイティブ・フォーマット・ビルダー・ウィザードに関する項を参照してください。

nXSD変換アクションを使用して、メッセージ・パイプライン内でメッセージ・コンテンツをXMLとネイティブ・フォーマット・データとの間で変換します。変換に使用するネイティブ・スキーマの作成の詳細は、テクノロジ・アダプタの理解のネイティブ・フォーマット・ビルダー・ウィザードに関する項を参照してください。

次の例に示すとおり、関連付けられているXSDリソースに関連する注釈がある場合、nXSD変換アクションでは、XMLからJSON、およびJSONからXMLの変換をサポートしています。

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://example.com/RestService_Operation1_request"
targetNamespace="http://example.com/RestService_Operation1_request" elementFormDefault="qualified"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" nxsd:version="JSON" nxsd:encoding="US-ASCII">
<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="country" type="xsd:string"/>
<xsd:element name="circuit" type="xsd:string"/>
<xsd:element name="date" type="xsd:date"/>
…

nXSD変換アクションはこのバージョンのService Busで拡張されており、JSONからXMLへの変換時にスキーマの順序が適用されます。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

nXSD変換アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「メッセージ処理」→「nXSD変換」を選択します。

3. nXSD変換の適用リストから、「XMLからネイティブ」または「ネイティブからXML」を要件に応じて選択します。

4. 「式」をクリックします。XQuery/XSLT式エディタを使用して、nXSD変換アクションを実行する変数を指定します。この入力は、XMLへの変換の場合はネイティブ・フォーマット、ネイティブ・データ・フォーマットへの変換の場合はXMLです。インラインXQueryおよびXPath式の作成と編集を参照してください。

5. 次のいずれかのオプションを選択します。

- nXSDリソース: 「リソース」リンクをクリックします。「XMLスキーマの選択」ページが表示されます。ネイティブ・スキーマに対応するスキーマ(.xsd)ファイルを選択します。

- からのnXSDリソース: 「式」リンクをクリックします。XQuery式エディタ・ページが表示されます。XQuery式エディタを使用して、ネイティブ・スキーマを動的に指定するXQuery式を作成または編集します。インラインXQueryおよびXPath式の作成と編集を参照してください。

6. 「出力の割当て先」フィールドで、「変数」を選択し、この変換アクションの結果を割り当てる変数の名前を入力します。または、出力を「$bodyの内容」に割り当てることもできます。

7. (オプション) ネイティブ形式(JSONなど)からXMLに変換する場合は、「スキーマ順序の適用」オプションを選択します。選択すると、XMLスキーマの要素の順序付けと一致するようにJSONペイロードを並べ替えます。

8. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.24 コンソールでの名前変更アクションの追加

XPath式で選択された要素のコンテンツを変更せずに要素名を変更するには、名前変更アクションを使用します。名前変更アクションは更新アクションの1つです。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

名前変更アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「メッセージ処理」→「名前変更」を選択します。

3. 「XPath」をクリックします。「XPath式エディタ」ページが表示されます。XPath式を使用して、名前を変更する(名前付き変数内の)データを指定します。インラインXQueryおよびXPath式の作成と編集を参照してください。

4. 「変数」フィールドに、名前変更する要素を保持するコンテキスト変数を入力します。

5. 次のいずれかを行います。

- ローカル名を使用して選択した要素名を変更する場合は、最初の「ローカル名」オプションを選択して、「ローカル名」フィールドにローカル名を入力します。

- ネームスペースを使用して選択した要素名を変更する場合は、最初の「ネームスペース」オプションを選択して、「ネームスペース」フィールドにネームスペースを入力します。

- ローカル名とネームスペースを使用して選択した要素名を変更する場合は、ローカル名とネームスペース・ラジオ・ボタンを選択して、ローカル名とネームスペース・フィールドにローカル名とネームスペースを入力します。

6. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.25 コンソールでの置換アクションの追加

XPath式で指定されたノードまたはノードのコンテンツを置き換えるには、置換アクションを使用します。ノードまたはそのコンテンツは、XQuery式が返した値で置換されます。置換アクションでは、単純な値、要素、属性を置き換えることができます。XQuery式から何も返されない状態は、アクションがノード全体を置き換えるか、ノードコンテンツのみを置き換えるかにより、識別されたノードを削除すること、または空のノードを作成することと同じです。置換アクションは更新アクションのセットの内の1つです。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

置換アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「メッセージ処理」→「置換」を選択します。

3. 「XPath」をクリックします。「XPath式エディタ」ページが表示されます。XPath式を使用して、置換する(名前付き変数内の)データを指定します。インラインXQueryおよびXPath式の作成と編集を参照してください。

4. XPath式の編集が終わったら、「変数」フィールドにコンテキスト変数を入力します。

5. 「式」をクリックします。XQuery式エディタ・ページが表示されます。XQuery式を使用して、名前付き変数内のXPathで指定したデータを置換するデータを作成します。インラインXQueryおよびXPath式の作成と編集を参照してください。

6. XQuery式を編集したら、次のいずれかのオプションを選択します。

- 「ノード全体を置換」 - 定義したXPath式で選択したノードとそのすべてのコンテンツを置換するように指定します。

- 「ノードのコンテンツを置換」 - ノードは置換せず、そのコンテンツのみ置換するように指定します。

注意:

「ノード全体を置換」オプションを選択してXPathを./*に設定するよりも、「ノードのコンテンツを置換」オプションを選択して「XPath」フィールドを空白にする方が効率的です。

7. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.26 コンソールでの検証アクションの追加

XMLスキーマ要素またはWSDLリソースに対して、XPath式で選択した要素を検証するには、検証アクションを使用します。検証できるのは、グローバル要素のみです。Service Busはローカル要素に対する検証に対応していません。実行時にXQuery式の結果に基づいて、XMLスキーマ要素またはWSDLリソースを動的に選択することも選択できます。

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

検証アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「メッセージ処理」→「検証」を選択します。

3. 「XPath」をクリックします。検証する要素を指定するXPath式を作成します。インラインXQueryおよびXPath式の作成と編集を参照してください。XPath式エディタで式を作成したら、「保存」をクリックして、「ステージ構成の編集」ページで式を挿入します。

4. 変数フィールドに、検証する要素を保持する変数の名前を入力します。

5. 次のいずれかのオプションを選択します。

- リソースに対して: 「リソース」リンクをクリックし、「WSDL」または「スキーマ」を選択します。「WSDLブラウザ」または「XMLスキーマ・ブラウザ」から、次の手順を実行します。

a. WSDLファイルまたはXMLスキーマを選択します。

b. WSDLファイルまたはXMLスキーマのタイプまたは要素を選択します。

c. 「発行」をクリックします。

- 式からのリソースに対して: 「式」リンクをクリックします。XQuery式エディタ・ページが表示されます。XQuery式エディタを使用して、WSDLファイルまたはスキーマ・リソースを動的に指定するXQuery式を作成または編集します。インラインXQueryおよびXPath式の作成と編集を参照してください。
次のものは、WSDLリソースの動的な指定の例です。

<validate xmlns="http://www.bea.com/wli/sb/context">
<wsdl>default/MyWSDL</wsdl>
<schemaType>
<namespaceURI>http://openuri.org</namespaceURI>
<localname>MyType</localname>
</schemaType>
</validate>

次のものは、スキーマ・リソースの動的な指定の例です。

<validate xmlns="http://www.bea.com/wli/sb/context">
<schema>{dvm:lookup('SBProject/dvm/DVM_Validation', 'operation', $operationName, 'validationSchema','default')}</schema>
<schemaElement>
.........<namespaceURI>"http://www.server.com/date</namespace>
<localname>{dvm:lookup('SBProject/dvm/DVM_Validation', 'operation', $operationName, 'validationElement','default')}</localname>
</schemaElement>
</validate>

選択したスキーマまたはWSDLが、OSBにインポートされているスキーマまたはWSDLリソースであるようにしてください。URLファイルやURLは直接指定できません。必要なXMLフラグメントは、XQuery式で作成され、XMLを作成するためにどのようなXQuery式でも入力できます。前述の例で、示されたXMLはXML定数であり、想定されるXMLを示しています。

たとえば、WSDLの名前は変数になる場合があるため、リソース名を見つけるには、その名前を抽出します。別の例は、1つまたは複数のキーを指定してXMLフラグメントのルックアップを実行できる関数があるXqueryモジュール・リソースが存在する場合です。この場合、検証式で必要なキーを評価し、そのXqueryモジュール関数を呼び出すことができます。これにより、1つのXqueryモジュールとルックアップ・アルゴリズムですべての動的エントリを外部化して管理できます。

6. この検証の結果(ブール結果)を保存する場合は、検証結果を変数に保存を選択し、結果を保存する変数の名前を入力します。
また、WSDLファイルやXMLスキーマ要素に対する要素の検証が失敗したときにエラーを発生させる場合は、検証の失敗で「エラーの生成」を選択します。

7. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.27 コンソールでのアラート・アクションの追加

アラート宛先にアラートを送信するには、アラート・アクションを使用して、パイプラインのメッセージ・コンテキストに基づいてアラートを生成します。SLAアラートと異なり、アラート・アクションで生成された通知は、主にビジネスでの使用、またはエラーの報告を目的とし、システムの状態を監視するものではありません。このことを考慮して、アラートの宛先を構成および選択する必要があります。アラートの宛先の詳細は、「アラート宛先の操作」を参照してください。

サービスに対してパイプライン・アラートが有効になっていない場合や、ドメイン・レベルでパイプライン・アラートが有効になっていない場合は、メッセージの処理中に、構成したアラート・アクションがバイパスされます。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

アラート・アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「レポート」→「アラート」を選択します。

3. 「宛先」をクリックします。「アラート宛先の選択」ページが表示されます。リストから必要なアラートの宛先を選択して、「発行」をクリックします。

デフォルトでは、アラートは常に管理コンソールに出力されます。

4. 「式」をクリックします。XQuery式エディタ・ページが表示されます。コンテキスト変数のXQuery式を通じてアラート・メッセージに追加するメッセージ・コンテキストを指定します。インラインXQueryおよびXPath式の作成と編集を参照してください。

5. 「アラート要約」フィールドにアラートの簡単な説明文を入力します。説明文は、電子メール通知の場合の件名になり、80文字以内である必要があります。説明文が存在しない場合、「Oracle Service Busアラート」というあらかじめ定義された件名がかわりに使用されます。

6. 「重大度」リストで、このアラートの重大度を「通常」、「警告」、「軽度」、「重度」、「クリティカル」、「致命的」から選択します。

7. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.28 コンソールでのログ・アクションの追加

ログに記録するメッセージを作成し、ログに使用する一連の属性を定義するには、ログ・アクションを使用します。

始める前に

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

注意:

ログ・ファイルまたは標準出力(サーバー・コンソール)にログ・データを表示するには、WebLogic Serverのロギングを次の重大度に設定する必要があります。

- ログの最低の重大度: 情報

- ログ・ファイル: 情報

- 標準出力: 情報

ログの重大度の設定の詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』のログの重大度の使用に関する項を参照してください。

ログ・アクションを追加するには:

1. 必ずロギングをグローバルに有効にしてください。詳細は、『Oracle Service Busの管理』のグローバル・レベルの操作設定の構成に関する項を参照してください。

2. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

3. 該当するアイコンをクリックして、「アクションの追加」→「レポート」→「ログ」を選択します。

4. 「式」をクリックします。XQuery式エディタ・ページが表示されます。コンテキスト変数のXQuery式を通じてログに記録するメッセージ・コンテキストを指定します。インラインXQueryおよびXPath式の作成と編集を参照してください。

5. 「アノテーション」フィールドに、このログ・アクションのメモを入力します。これらのメモは、事前に定義された式の結果と一緒にログに記録されます。

6. 「重大度レベル」リストで、次のいずれかのオプションを選択します。

表14-7 ログ・アクションの重大度

重大度レベル

一般的使用方法

情報

通常の処理を報告するために使用する、低レベルの情報メッセージ。

警告

不審なオペレーションまたは構成が発生しましたが、通常のオペレーションには影響しません。

エラー

ユーザー・エラーが発生したことを示します。システムまたはアプリケーションでは、割込みやサービスの限定的な低下を起こすことなくエラーに対処できます。

デバッグ

アプリケーションの開発中、そのアプリケーションの低レベル・アクティビティを示すメッセージを作成および使用できると便利です。

プロキシ・サービスの操作設定におけるログの重大度が、ログ・アクションの重大度と同じであることを確認します。プロキシ・サービスの操作設定の詳細は、『Oracle Service Busの管理』の使用可能な操作設定に関する項を参照してください。

7. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.29 コンソールでのレポート・アクションの追加

プロキシ・サービスのメッセージ・レポートを有効にするには、レポート・アクションを使用します。

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

レポート・アクションを追加するには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。

2. 該当するアイコンをクリックして、「アクションの追加」→「レポート」→「レポート」を選択します。

3. 「式」をクリックします。XQuery式エディタ・ページが表示されます。インラインXQueryおよびXPath式の作成と編集を参照してください。XQuery式を使用して、Service Busダッシュボートにレポートされるデータを作成します。

4. XQuery式を編集したら、「キーの追加」をクリックします。「キー名」フィールドと「キー値」フィールド(XPath式編集用の画面に移動するための「XPath」リンクとコンテキスト変数を入力できる「変数」フィールドを持つ)の2つのフィールドが表示されます。
キー値のペアは、メッセージ・コンテキスト変数やメッセージ・ペイロードからキー識別子を抽出して、残りのメッセージを無視する場合に使用します。キーは、メッセージを識別する便利な手段となります。キーは、「レポート」モジュールでレポート・インデックスとして表示されます。『Oracle Service Busの管理』のメッセージ・レポートの操作に関する項を参照してください。

a. 「キー名」フィールドにキーの名前を入力します。

b. 「XPath」をクリックします。「XPath式の編集。」ページが表示されます。インラインXQueryおよびXPath式の作成と編集を参照してください。

c. 「変数」フィールドにコンテキスト変数を入力します。

d. さらにキー値を追加するには、「キー」アイコンをクリックして「キーの追加」を選択します。キーを削除するには、「キー」アイコンをクリックして「このキーを削除」を選択します。

たとえば、ステージのエラー・ハンドラで構成されたレポート・アクションを考えてみます。このアクションは、エラーが発生した場合にfaultコンテキスト変数のコンテンツを報告します。レポート・アクションは次のように構成されます。

- キー名= errorCode

- キー値= ./ctx:errorCode(変数fault)

実行時にこのこのアクションが行われるたびに、データ・ストリームを通じてメッセージが報告されます。次の表は、レポート・アクションが2回実行された後の結果を示しています。

レポート・インデックス

DBタイムスタンプ

インバウンド・サービス

エラー・コード

errorCode=OSB-382505

04/26/07 9:45 AM

MortgageBroker/ProxySvcs/loanGateway3

OSB-382505

errorCode=OSB-382505

04/26/07 9:45 AM

OSB-382505

14.30 コンソールでのエラー・ハンドラの追加

エラー処理は、メッセージ・フロー、パイプライン、ルート・ノード、およびステージ・レベルで構成できます。「エラー・ハンドラの編集」ページで、エラー・ハンドラを構成します。エラー・ハンドラの動作を指定するには、必ず、少なくとも1つのステージをページに追加する必要があります。

14.30.1 コンソールでのパイプライン・エラー・ハンドラの追加

始める前に

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

また、この手順は、「パイプラインへのパイプライン・ペアの追加方法」の説明に従って、パイプライン・ペア・ノードを作成していることも前提としています。

パイプライン・エラー・ハンドラを追加するには:

1. エラー・ハンドラを追加するパイプラインを含むパイプライン・ペア・ノードに移動します。パイプライン・ペア・ノードがまだ展開されていない場合は、アイコン の横のプラス記号をクリックしてパイプラインを表示します。

2. 「リクエスト・パイプライン」アイコンまたは「レスポンス・パイプライン」アイコンをクリックして、「パイプライン・エラー・ハンドラの追加」をクリックします。「エラー・ハンドラの編集」ページが表示されます。

3. 「エラー・ハンドラ」アイコンをクリックしてから、「ステージの追加」をクリックします。

4. 「ステージ」アイコンをクリックして「ステージの編集」をクリックします。「ステージ構成の編集」ページが表示されます。

5. 「アクションの追加」をクリックし、追加するアクションを選択します。

エラー・ハンドラはパイプラインであるため、構成は他のパイプラインと同じようにして行われます。たとえば、「パブリッシュ」アクションを使用して、他のサービスにエラー通知を送信したり、「割当て」アクションを使用して、コンテキスト変数を変更したりできます。追加するアクションのタイプの詳細は、パイプライン・コンソールでのアクションの追加と編集の該当する手順を参照してください。アクションは任意の組合せで連鎖できます。

「エラーの生成」、「返信」および「再開」の3つのエラー・アクションがよく使用されます。

6. 必要に応じて、「ステージ構成の編集」ページで、他のアクションの追加およびその他の編集を行います。

7. 「ステージ構成の編集」ページで、「保存」をクリックして、現在のセッションで更新をコミットします。

8. 「エラー・ハンドラの編集」ページで「保存」をクリックし、現在のセッションでの更新をコミットします。

14.30.2 コンソールでのステージ・エラー・ハンドラの追加

始める前に

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。この手順は、「コンソールでのパイプラインへのステージの追加方法」の説明に従って、パイプラインにステージを追加していることも前提としています。

ステージ・エラー・ハンドラを追加するには:

1. エラー処理を追加するステージへ移動します。

2. 「ステージ」アイコンをクリックしてから、「ステージ・エラー・ハンドラの追加」をクリックします。「エラー・ハンドラの編集」ページが表示されます。

3. 「エラー・ハンドラ」アイコンをクリックしてから、「ステージの追加」をクリックします。

4. 「ステージ」アイコンをクリックして「ステージの編集」をクリックします。「ステージ構成の編集」ページが表示されます。

5. 「アクションの追加」をクリックし、追加するアクションを選択します。

エラー・ハンドラはパイプラインであるため、構成は他のパイプラインと同じようにして行われます。たとえば、「パブリッシュ」アクションを使用して、他のサービスにエラー通知を送信したり、「割当て」アクションを使用して、コンテキスト変数を変更したりできます。追加するアクションのタイプの詳細は、パイプライン・コンソールでのアクションの追加と編集の該当する手順を参照してください。アクションは任意の組合せで連鎖できます。

「エラーの生成」、「返信」および「再開」の3つのエラー・アクションがよく使用されます。

6. 必要に応じて、「ステージ構成の編集」ページで、他のアクションの追加およびその他の編集を行います。

7. 「保存」をクリックして、現在のセッションで更新をコミットします。

14.30.3 コンソールでのルート・ノード・エラー・ハンドラの追加

始める前に

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

また、この手順は、「コンソールでのパイプラインへのルート・ノードの追加方法」の説明に従って、ルート・ノードを作成していることも前提としています。

ルート・ノード・エラー・ハンドラを追加するには:

1. 「ルート・ノード」アイコンをクリックしてから、「エラー・ハンドラの追加」をクリックします。「エラー・ハンドラの編集」ページが表示されます。

2. 「エラー・ハンドラ」アイコンをクリックしてから、「ステージの追加」をクリックします。

3. 「ステージ」アイコンをクリックして「ステージの編集」をクリックします。「ステージ構成の編集」ページが表示されます。

4. 「アクションの追加」をクリックし、追加するアクションを選択します。

エラー・ハンドラもある種のパイプラインであるため、構成は他のパイプラインと同じようにして行われます。たとえば、「パブリッシュ」アクションを使用して、他のサービスにエラー通知を送信したり、「割当て」アクションを使用して、コンテキスト変数を変更したりできます。追加するアクションのタイプの詳細は、パイプライン・コンソールでのアクションの追加と編集の該当する手順を参照してください。アクションは任意の組合せで連鎖できます。

「エラーの生成」、「返信」および「再開」の3つのエラー・アクションがよく使用されます。

5. 必要に応じて、「ステージ構成の編集」ページで、他のアクションの追加およびその他の編集を行います。

6. 「ステージ構成の編集」ページで、「保存」をクリックして、現在のセッションで更新をコミットします。

7. 「エラー・ハンドラの編集」ページで「保存」をクリックし、現在のセッションでの更新をコミットします。

14.30.4 コンソールでのエラー・ハンドラの編集

始める前に

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

エラー・ハンドラを表示および変更するには:

次のいずれかを行います:

表14-8 エラー・ハンドラの表示と変更

内容

この手順を完了するには...

パイプラインのエラー・ハンドラの表示および変更

「リクエスト・パイプライン」アイコンまたは「レスポンス・パイプライン」アイコンをクリックして、「パイプライン・エラー・ハンドラの編集」をクリックします。「エラー・ハンドラの編集」ページが表示されます。「コンソールでのパイプライン・エラー・ハンドラの追加」を参照してください。

ルート・ノードのエラー・ハンドラの表示および変更

適切な「ルート・ノード」アイコンをクリックしてから、「ルート・エラー・ハンドラの編集」をクリックします。「エラー・ハンドラの編集」ページが表示されます。「コンソールでのルート・ノード・エラー・ハンドラの追加」を参照してください。

ステージのエラー・ハンドラの表示および変更

適切な「ステージ」アイコンをクリックしてから、「ステージ・エラー・ハンドラの編集」をクリックします。「エラー・ハンドラの編集」ページが表示されます。「コンソールでのステージ・エラー・ハンドラの追加」を参照してください。

14.31 コンソールでのアクションまたはステージの無効化

パイプライン内のアクションまたはステージを無効化することもできます。無効化されたアクションまたはステージは、パイプラインの実行でスキップされます。アクションまたはステージを無効化した場合、ネストされたアクション(存在する場合)はすべて自動的に無効化されます。無効化されたステージまたはアクションは設計時に検証されません。

注意:

無効化されたステージにエラー・ハンドラがある場合、そのエラー・ハンドラも無効化されます。

無効化されたアクションまたはステージの構成は編集できます。リファクタは、無効化されたアクションおよびステージに対しても実行されます。したがって、無効化されたアクションまたはステージ内のサービスに対するコールがあり、そのサービスの名前が変更されている場合、サービス・コールアウトは自動的に更新されます。

無効化されたステージまたはアクションはいつでも再有効化でき、それによってそのアクションまたはステージはパイプラインでスキップされなくなります。

14.31.1 パイプラインでのアクションの無効化

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

パイプラインでアクションを無効化にするには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、編集するアクションに移動します。

2. 該当するアクションのアイコンをクリックし、「このアクションの無効化」を選択します。

そのアクション・アイコンがグレー表示になり、「無効」アイコンがそのアクションの横に表示されます。

3. 「保存」をクリックして、変更を保存します。

14.31.2 パイプラインでのアクションの再有効化

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

パイプラインでアクションを再有効化にするには:

1. 「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、編集するアクションに移動します。

2. 無効化されたアクションのアイコンをクリックし、「このアクションの有効化」を選択します。

グレー表示されたアクション・アイコンが通常表示に戻り、アクションが有効化されます。

3. 「保存」をクリックして、変更を保存します。

14.31.3 パイプラインでのステージの無効化

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

パイプラインでステージを無効化するには:

1. 「メッセージ・フローの編集」ページで、無効化するステージ・アイコンをクリックします。

2. 表示されたコンテキスト・メニューから「ステージの無効化」を選択します。

そのステージ・アイコンがグレー表示になり、「無効」アイコンがそのステージの横に表示されます。

3. 「保存」をクリックして、変更を保存します。

14.31.4 パイプラインでのステージの再有効化

始める前に:

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。

パイプラインでステージを再有効化にするには:

1. 「メッセージ・フローの編集」ページで、無効化されたステージ・アイコンをクリックします。

2. 表示されたコンテキスト・メニューから「ステージの有効化」を選択します。

グレー表示されたステージ・アイコンが通常表示に戻り、ステージが有効化されます。

3. 「保存」をクリックして、変更を保存します。

15 Oracle Service Busコンソールでの式エディタの操作

この章では、パイプラインまたはメッセージ・フローでXQueryおよびXPath式を使用する方法について説明します。

パイプラインでは、メッセージ・コンテキスト変数へのXQuery式の割当て、XQuery式のブール結果に基づくif-thenアクションの割当て、XPath式に対して相対的に指定した位置へのXQuery式の結果の挿入、コンテキスト変数のXQuery式を使用したログ用のメッセージ・コンテキストの指定などを実行できます。

コンテキストで必要な式を作成するために、メッセージ・フローの該当するコンテキストで、「XQuery式エディタ」、「XQuery条件エディタ」、「XPath式エディタ」を使用できます。

この章の構成は、次のとおりです。

- インラインXQueryおよびXPath式の作成と編集

- XQueryエディタのレイアウトとタスクについて

- エディタ・ワークスペースのテキスト・フィールドでの式の構築

- インライン式で使用するためのネームスペースの作成

- XQueryエディタによる変数の構造の作成

- XQueryエディタによるカスタムXPath関数の作成

- 外部XQueryリソースのインラインXQueryへのバインド

- 外部XSLTリソースのインラインXQueryへのバインド

- 動的XQuery式からインラインXQueryへのバインド

- 動的XSLT式のインラインXQueryへのバインディング

- 「ビルダー」オプションを使用したXQuery比較式の入力

- 「ビルダー」オプションを使用した単項式の入力

15.1 インラインXQueryおよびXPath式の作成と編集

「ステージ構成の編集」ページでステージまたはルート・ノードにアクションを追加する場合、構成の詳細を入力するページにスケルトン構造が表示されます。図15-1に例を示します。

図15-1 アクション構成スケルトンの例

コンテキスト上適切である場合は、XQueryエディタへアクセスするためのリンクがスケルトンによって用意されます。アクションのコンテキスト上必要である場合、インラインで実行される式をこのエディタで作成できます。

始める前に:

次の説明では、パイプライン・ステージ、エラー・ハンドラ・ステージ、またはルート・ノードの「ステージ構成の編集」ページでアクションの作成または編集を行うものとします。「コンソールでのパイプラインの表示と編集」および「コンソールでのパイプライン・アクションの追加と編集」を参照してください。

インライン式を作成または変更するには:

1. 「ステージ構成の編集」ページで、アクション内に式を追加または編集する場所を特定します。

2. 「式」リンクをクリックして、コンテキストに適切なエディタを開きます。式がまだ定義されていない場合は、その位置において使用可能な式の種類がリンクに示されます。

- XQuery式を作成するには、「式」をクリックします。Service Bus以外で作成したXQueryまたはXSLTリソースをインポートしてインラインXQueryにバインドすることもできます。

- if-thenアクション用にXQuery条件式を作成するには、「条件」をクリックします。

- メッセージ・コンテキスト変数用のXPath式を作成するには、「XPath」をクリックします。

式がその位置に対してすでに定義されている場合、「式」、「条件」または「XPath」リンクは式自体を示すtrue()のようなリンクに置き換わります。式の長さが長すぎる場合は、$body/urn:POSta...のような式の一部になります。式(または式のフラグメント)をクリックして適切なエディタで式を開きます。

3. 次のトピックの説明を参照して、式を構築します。

- エディタ・ワークスペースのテキスト・フィールドでの式の構築

- インライン式で使用するためのネームスペースの作成

- XQueryエディタによる変数の構造の作成

- XQueryエディタによるカスタムXPath関数の作成

- 外部XQueryリソースのインラインXQueryへのバインド

- 外部XSLTリソースのインラインXQueryへのバインド

- 動的XQuery式からインラインXQueryへのバインド

- 「ビルダー」オプションを使用したXQuery比較式の入力

- 「ビルダー」オプションを使用した単項式の入力

4. (オプション)次のいずれか、または両方を実行します。

- 式を検証するには、「検証」をクリックします。

- 式をテストするには、「テスト」をクリックします。「XQueryトランスフォーメーションのテストの前提条件とガイドライン」を参照してください。

5. 「保存」をクリックしてエディタを閉じ、式をアクションに挿入します。

15.2 XQueryエディタのレイアウトとタスクについて

XQuery式エディタ、XQuery条件エディタ、およびXPath式エディタは、それぞれ次のコンポーネントから構成されています。

- パレット

- ワークスペース

- プロパティ・インスペクタ

15.2.1 パレット

各エディタの左側のパネルには、次に示すパレットがあります。エディタでパレットの名前をクリックすると、そのパレットが表示されます。各パレットには、エディタ内で式に挿入できるエンティティが含まれています。

- 「ネームスペース定義」パレットには、Service Busのデフォルト・ネームスペース、変数のネームスペースおよびユーザー定義ネームスペースが表示されます。新しいネーム・スペースを定義することもできます。定義されたネーム・スペースはユーザー定義ネーム・スペースのリストに追加されます。
詳細な情報は、次を参照してください:

- エディタ・ワークスペースのテキスト・フィールドでの式の構築

- インライン式で使用するためのネームスペースの作成

- 「XQuery関数」パレットには、一連の標準XQuery関数が表示されます。式に関数を挿入するときには、入力する必要があるパラメータ値ついてプレースホルダーが使用されます。
詳細な情報は、次を参照してください:

- エディタ・ワークスペースのテキスト・フィールドでの式の構築

- XQueryエディタによるカスタムXPath関数の作成

- 外部XQueryリソースのインラインXQueryへのバインド

- 「変数の構造」パレットには、XPath式を使用して、変数や変数のパスを挿入するためのツールが用意されています。
変数の構造は、エディタに表示される変数または変数のパスのグラフィカルな表現です。変数の構造が視覚化されることにより、変数の内容を参照するインラインXQuery式の構築が容易になります。

注意:

変数の構造では、変数は作成されません。変数は、ステージでの割当てアクションの対象として実行時に作成されます。

Service Busには事前定義されたメッセージ・コンテキスト変数(attachments、body、header、outboundおよびinbound)があり、その内容を変数の構造として表示できます。ユーザーが独自に変数の構造を定義することもできます。

詳細は、次を参照してください。

- エディタ・ワークスペースのテキスト・フィールドでの式の構築

- XQueryエディタによる変数の構造の作成

15.2.2 ワークスペース

ページの右側は、XQuery式、XQuery条件、またはXPathを作成するためのワークスペースになっています。ワークスペースはそれぞれのエディタによって異なります。

15.2.3 プロパティ・インスペクタ

プロパティ・インスペクタは、3種類のエディタのすべてで、ページの右下に表示されます。パレットの1つからアイテムを式に追加するために選択すると、選択したアイテムがプロパティ・インスペクタに表示されます。表示されたアイテムは、ワークスペースに貼り付けることができます。エディタ・ワークスペースのテキスト・フィールドでの式の構築を参照してください。

15.3 エディタ・ワークスペースのテキスト・フィールドでの式の構築

XQuery式エディタ、XQuery条件エディタ、およびXPath式エディタのすべてにテキスト・フィールドがあり、このフィールドに直接入力するか、または、パレットから貼り付けることで、式を構築できます。

始める前に:

この説明では、インラインXQueryおよびXPath式の作成と編集で説明したように、XQuery式エディタ、XQuery条件エディタまたはXPath式エディタで式を作成または編集しているものと仮定します。

テキスト・フィールドで式を構築するには

1. テキスト・フィールドを含むパネルを表示します。エディタに応じて、次のいずれかを実行します。

- まだ選択していない場合は、XQuery式エディタで、(ワークスペースのボタン・バーの下にある)「XQueryテキスト」を選択します。

- まだ選択していない場合は、XQuery条件エディタで、(ワークスペースのボタン・バーの下にある)「テキスト」を選択します。

- XPath式エディタでは、その他のツールを選択するオプションがないため、何も選択する必要はありません。

注意:

前述のいずれかのリンクを選択すると、コンテキストに応じた完全な式を作成できるテキスト・フィールドが表示されます。ただし、このトピックで説明されているツールと方法は、外部XQueryリソースのインラインXQueryへのバインドおよび外部XSLTリソースのインラインXQueryへのバインドで説明されているとおり、インポートされたリソースからインライン式への変数のバインドなどのように、エディタにテキスト・フィールドが表示されている場合はいつでも使用できます。

2. 必要に応じて、式または式の一部を、フィールドに入力または貼り付けます。この方法で完全な式が作成できた場合は、ステップ7に進みます。使用していない場合は次の手順に進みます。

3. 次の表15-1の説明に従って、式に追加する項目を含むパレットを選択し、追加する項目を特定します。

表15-1 パレット

パレット

説明および使用方法

ネームスペース定義

デフォルトのService Busネームスペース、変数ネームスペースおよびユーザー定義のネームスペースを一覧表示します。定義されている場合は、ネームスペースの略語が一覧表示されます。

リストをスクロールして、目的のネームスペースを見つけ出します。

ネームスペースを定義することもできます。インライン式で使用するためのネームスペースの作成を参照してください。

XQuery関数

標準のXQuery関数と開発したカスタム関数がタイプ別にアルファベット順で含まれます。ツリー内のノードを展開するにはプラス記号(+)を、折りたたむにはマイナス記号(-)をクリックします。

関連項目:

- XQueryでのデータの変換

変数の構造

変数とそれらのコンテンツがツリー形式で表示されるため、視覚的に確認できます。

変数の構造とそのコンテンツを表示できます。

- パレットの上部にあるリストから構造の名前を選択します。リストには、組込みメッセージ・コンテキスト変数(attachments、body、header、outbound、inbound)と、型ごと(「XMLタイプ」、「サービス・インタフェース」、「単純な型」)に整理されたユーザー定義の構造が一覧表示されます。

- ツリー内のノードを展開するにはプラス記号(+)を、折りたたむにはマイナス記号(-)をクリックします。

ユーザーが独自に変数の構造を定義することもできます。XQueryエディタによる変数の構造の作成を参照してください。

変数の構造では、変数は作成されません。変数は、ステージでの割当てアクションの対象として実行時に作成されます。

変数の構造のツリーから項目をテキスト・フィールドに挿入すると、パスを記述するXPath式として挿入されます。

「XQueryでのデータ変換」も参照してください。

4. 次の表15-2に示されている方法のいずれかを使用して、目的の項目をテキスト・フィールドに貼り付けます。

表15-2 エディタのテキスト・フィールドに項目を貼り付ける方法

パレット

手順

「ネームスペース定義」パレット

標準のマウスまたはキーボードでの、ネームスペースの選択、コピー、および貼付けを使用します。例:

a. 文字列上でマウス・ポインタをドラッグして、ネームスペースの文字列全体(または、存在する場合は、その略語)を選択します。

b. [Ctrl]+[C]を押して、文字列をコピーします。

c. テキスト・フィールドの、ネームスペースを挿入する場所をクリックします。

d. [Ctrl]+[V]を押して、文字列を貼り付けます。

「XQuery関数」 パレットまたは 「変数の構造」 パレット

項目をパレットからテキスト・フィールドにドラッグします。

注意: パレットからワークスペースへのドラッグは、Internet Explorerでのみサポートされています。

「XQuery関数」 パレットまたは 「変数の構造」 パレット

a. パレットの項目をクリックします。「プロパティ・インスペクタ」ペインに項目が表示されます。
関数は、提供する必要がある値のプレースホルダーと共に表示されます。

変数とそれらの属性は、XPath式として表示されます。

b. テキスト・フィールドの、項目を挿入する場所をクリックします。

c. 「プロパティのコピー」をクリックして、テキスト・フィールド内の選択した場所に項目を貼り付けます。

「XQuery関数」 パレットまたは 「変数の構造」 パレット

a. パレットの項目をクリックします。「プロパティ・インスペクタ」ペインに項目が表示されます。

b. 標準のキーボードまたはマウスのアクションを使用して、プロパティ・インスペクタで項目を選択およびコピーします。

c. 標準のキーボードまたはマウスのアクションを使用して、テキスト・フィールド内の場所を選択して、項目をテキスト・フィールドに貼り付けます。

5. 引き続き、関数のドラッグ・アンド・コピーを行って、目的の式を構築します。

6. 必要に応じて、テキスト・フィールドで式を編集します。

7. (オプション)次のいずれか、または両方を実行します。

- 「検証」をクリックします。式の検証が成功した場合は、メッセージが表示されます。

- 式をテストするには、「テスト」をクリックします。「XQueryトランスフォーメーションのテストの前提条件とガイドライン」を参照してください。

8. 「保存」をクリックして、エディタを閉じ、式をアクションに挿入します。

15.4 インライン式で使用するネームスペースの作成

「ネームスペース定義」パレットには、デフォルトのネームスペースのリストが含まれています。新しいネームスペースを定義することもできます。

始める前に:

この説明では、インラインXQueryおよびXPath式の作成と編集で説明したように、XQuery式エディタ、XQuery条件エディタまたはXPath式エディタで式を作成または編集しているものと仮定します。

ネームスペースを作成してインライン式で使用するには:

1. 「ネームスペース定義」を選択します。「ネームスペース定義」パレットには、デフォルトのネームスペースのリストと、存在する場合は、変数ネームスペースおよびユーザー定義済のネームスペースのリストが含まれています。

2. ユーザーのネームスペースを定義および追加するには

a. 「ネームスペースの追加」をクリックします。

b. 「接頭辞」フィールドに、ネームスペースの一意の識別子を入力します。同じ接頭辞を複数回使用することはできません。

c. 「URI」フィールドに、このネームスペースのURLをhttp://url/.../の形式で入力するか、またはURNをuddi:server:の形式で入力します。

d. 「追加」をクリックして、「ユーザー定義済みネームスペース」にネームスペースを追加します。

e. インラインXQueryおよびXPath式の作成と編集の説明に従って、ユーザー定義済ネームスペースをコピーして、XQuery式、XQuery条件またはXPathに貼り付けます。

完了した後に:

インラインXQueryおよびXPath式の作成と編集の説明に従って、続行します。

15.5 XQueryエディタによる変数の構造の作成

XQueryエディタおよびXPathエディタの「変数の構造」パレットには、変数のコンテンツがグラフィカルに表示されます。これには、デフォルトで、組込みのメッセージ・コンテキスト変数attachments、body、header、outbound、およびinboundが含まれています。

変数の構造のマッピングでは、各エントリはラベルを持ち、変数または変数パスを1つまたは複数の構造にマップします。これらのマッピングのスコープは、ステージまたはルート・ノードです。

次に基づいて、独自の変数の構造を宣言することもできます。

- 次のようなXMLタイプ

- スキーマ要素

- WSDL要素

- スキーマ・タイプ

- WSDLタイプ

- MFL

- サービス・インタフェース

- 単純な型(文字列または任意のXML)

この機能は、すべてのユーザー定義変数と$inbound、$outboundおよび$faultに対して直接使用できます。ただし、この機能を使用して$attachmentsのXML添付ファイル、$headerのヘッダーまたは$bodyのドキュメントとRPCパラメータに直接アクセスすることはできません。例外として、WSDLプロキシ・サービスによって受信されたリクエスト・メッセージの$bodyのドキュメントとパラメータには直接アクセスできます。

始める前に:

この説明では、インラインXQueryおよびXPath式の作成と編集で説明したように、XQuery式エディタ、XQuery条件エディタまたはXPath式エディタで式を作成または編集しているものと仮定します。

変数の構造を作成するには

1. 「変数の構造」を選択します。

2. 「変数の構造」パレットで「新しい構造の追加」をクリックします。

3. 続けて、次の表15-3に示す作業のいずれかを行います。

表15-3 新しい変数の構造の作成

内容

次の手順を実行...

変数をXMLスキーマの型にマップする変数の構造の作成

1. まだ選択していない場合は、「変数の構造」パレットの上部にある「XMLタイプ」を選択します。

2. 「構造ラベル」フィールドに、作成する変数の表示名を入力します。この表示名を使用すると、実行時には影響を及ぼさず設計時に構造を認識できるように、構造に意味のある名前を付けることができます。

3. 「構造パス」フィールドに、実行時の変数の構造のパスを入力します。このパスは、$で始まる必要があります。

4. 「タイプ」フィールドで、該当するラジオ・ボタンを選択してから、「スキーマ・タイプ」を選択します。

5. 「参照」をクリックします。XMLスキーマ・ブラウザが表示されます。リストからXMLスキーマを選択し、定義ペインからXMLスキーマの型を選択して、「発行」をクリックします。

6. 「追加」をクリックして変数の構造を作成します。

変数をWSDLの型にマップする変数の構造の作成

1. まだ選択していない場合は、「変数の構造」パレットの上部にある「XMLタイプ」を選択します。

2. 「構造ラベル」フィールドに、作成する変数の表示名を入力します。この表示名を使用すると、実行時には影響を及ぼさず設計時に構造を認識できるように、構造に意味のある名前を付けることができます。

3. 「構造パス」フィールドに、実行時の変数の構造のパスを入力します。

4. 「タイプ」フィールドで、該当するラジオ・ボタンを選択してから、「WSDLタイプ」を選択します。

5. 「参照」をクリックします。WSDLブラウザが表示されます。WSDLファイルのリストからWSDLファイルを選択し、定義ペインからWSDLの型を選択して、「発行」をクリックします。

6. 「追加」をクリックして変数の構造を作成します。

変数をXMLスキーマ要素にマップする変数の構造の作成

1. まだ選択していない場合は、「変数の構造」パレットの上部にある「XMLタイプ」を選択します。

2. 「構造ラベル」フィールドに、作成する変数の表示名を入力します。この表示名を使用すると、実行時には影響を及ぼさず設計時に構造を認識できるように、構造に意味のある名前を付けることができます。

3. 「構造パス」フィールドに、実行時の変数の構造のパスを入力します。

4. 「タイプ」フィールドで、該当するラジオ・ボタンを選択してから、「スキーマ要素」を選択します。

5. 「参照」をクリックします。XMLスキーマ・ブラウザが表示されます。リストからXMLスキーマを選択し、定義ペインからXMLスキーマの型を選択して、「発行」をクリックします。

6. 「追加」をクリックして変数の構造を作成します。

変数をWSDL要素にマップする変数の構造の作成

1. まだ選択していない場合は、「変数の構造」パレットの上部にある「XMLタイプ」を選択します。

2. 「構造ラベル」フィールドに、作成する変数の表示名を入力します。この表示名を使用すると、実行時には影響を及ぼさず設計時に構造を認識できるように、構造に意味のある名前を付けることができます。

3. 「構造パス」フィールドに、実行時の変数の構造のパスを入力します。

4. 「タイプ」フィールドで、該当するラジオ・ボタンを選択してから、「WSDL要素」を選択します。

5. 「参照」をクリックします。WSDLブラウザが表示されます。WSDLファイルのリストからWSDLファイルを選択し、定義ペインからWSDL要素を選択して、「発行」をクリックします。

6. 「追加」をクリックして変数の構造を作成します。

変数を子要素にマップする変数の構造の作成

1. まだ選択していない場合は、「変数の構造」パレットの上部にある「XMLタイプ」を選択します。

2. 「構造ラベル」フィールドに、作成する変数の表示名を入力します。この表示名を使用すると、実行時には影響を及ぼさず設計時に構造を認識できるように、構造に意味のある名前を付けることができます。

3. 「構造パス」フィールドに、実行時の変数の構造のパスを入力します。

4. 「タイプ」フィールドで、作成する変数の型を選択します。
XMLスキーマ要素またはWSDL要素の変数を作成するには、このオプションに関連付けられているラジオ・ボタンを選択し、「スキーマ要素」または「WSDL要素」を選択します。

MFL変数を作成するには、このオプションに関連付けられているラジオ・ボタンを選択し、「MFL」を選択します。

5. XMLスキーマ、WSDLファイルまたはMFLファイルについては、「参照」をクリックし、ブラウザに表示されるリストからオブジェクトを選択して、「発行」をクリックします。たとえば、MFLのリストでMFLを選択し、「発行」をクリックします。

6. 作成する構造の子として要素を設定するために、「子として設定」チェックボックスを選択します。

7. 「追加」をクリックして変数の構造を作成します。

MFLリソースを使用する変数の構造の作成

1. まだ選択していない場合は、「変数の構造」パレットの上部にある「XMLタイプ」を選択します。

2. 「構造ラベル」フィールドに、作成する変数の表示名を入力します。この表示名を使用すると、実行時には影響を及ぼさず設計時に構造を認識できるように、構造に意味のある名前を付けることができます。

3. 「構造パス」フィールドに、実行時の変数の構造のパスを入力します。

4. 「タイプ」フィールドで、該当するラジオ・ボタンを選択してから、「参照」を選択します。MFLブラウザが表示されます。

5. MFLのリストからMFLを選択し、「発行」をクリックします。

6. 「追加」をクリックして変数の構造を作成します。

サービス・インタフェース変数の構造の作成

1. 「変数の構造」パレットの上部で、「サービス・インタフェース」を選択します。

2. 「構造ラベル」フィールドに、作成する変数の表示名を入力します。この表示名を使用すると、実行時には影響を及ぼさず設計時に構造を認識できるように、構造に意味のある名前を付けることができます。

3. 「構造パス」フィールドには、デフォルトの$bodyがすでに設定されています。このフィールドは変更できません。

4. WSDLベースのサービス・フィールドで「サービス・ブラウザ」アイコンを選択し、サービス・ブラウザに表示されるサービスのリストでサービスを選択して、「発行」をクリックします。

選択したサービスは、「WSDLベースのサービス」フィールドに表示されます。

1. 「操作」フィールドで、操作を選択するか、または操作を含めない場合は「なし」を選択します。

2. 「追加」をクリックして変数を作成します。

単純な変数の構造の作成

1. 「変数の構造」パレットの上部で、「単純な型」を選択します。

2. 「構造ラベル」フィールドに、作成する変数の表示名を入力します。この表示名を使用すると、実行時には影響を及ぼさず設計時に構造を認識できるように、構造に意味のある名前を付けることができます。

3. 「構造名」フィールドに、作成する変数の構造の名前を入力します。

4. 「タイプ」フィールドで、「文字列」または「任意のXML」を選択します。

5. 「追加」をクリックして変数を作成します。

完了した後に:

インラインXQueryおよびXPath式の作成と編集の説明に従って、続行します。

15.6 XQueryエディタでのカスタムXPath関数の作成

カスタムXQuery関数の作成は、Javaコードの記述が必要な開発プロセスです。詳細は、「カスタムXPath関数の作成」を参照してください。

15.7 外部XQueryリソースのインラインXQueryへのバインディング

XQueryリソースをインラインXQuery式にバインドして、アクションの一部としてインラインで実行できます。

始める前に:

この説明では、インラインXQueryおよびXPath式の作成と編集で説明したように、XQuery/XSLT式エディタ、XQuery条件エディタまたはXPath式エディタで式を作成または編集しているものと仮定します。

XQueryリソースをインライン式にバインドするには

1. 「変数の構造」をクリックします。

2. ワークスペース(ボタン・バーの下)で、「XQueryリソース」を選択します。

3. 「1.実行するXQueryリソースを選択します」ボックスで「参照」をクリックします。

4. XQueryブラウザで、使用するXQueryに関連付けられているラジオ・ボタンを選択し、「発行」をクリックします。

5. 「2.変数のバインド」ボックスで、トランスフォーメーション用の入力パラメータを定義します。「変数名」の下にリストされている各変数に対して、これにマッピングされるXQuery式を入力します。マッピングはパラメータごとに定義する必要があります。たとえば、XQueryトランスフォーメーションにoneおよびtwoという入力パラメータがある場合、「変数名」フィールドには、「one」および「two」という2つのラベルが表示されます。各ラベルに、XQuery式が入力されるテキスト・ボックスが1つ表示されます。

次のXQuery式は、このフィールドの有効な入力例です。

$body/*[1]
$body/po:PurchaseOrder

注意:

bodyという変数名はこのフィールドでは無効な入力となり、例外が発生します。

6. 完了した後は、次のいずれかの操作に進みます。

- 「検証」をクリックします。式の検証が成功した場合は、メッセージが表示されます。

- 「テスト」をクリックします。「XQueryトランスフォーメーションのテストの前提条件とガイドライン」を参照してください。

- 変更を保存するか、または破棄します。

15.8 外部XSLTリソースのインラインXQueryへのバインディング

「XQuery/XSLT式エディタ」ページでは、実行用XSLTリソースを選択できます。このエディタの詳細は、インラインXQueryおよびXPath式の作成と編集を参照してください。

実行用XSLTリソースを選択するには

1. 「XSLTリソース」オプションを選択します。

2. 「実行するXSLTリソースを選択します」フィールドで、「XSLT参照」アイコンをクリックします。

3. XSLTブラウザで、実行するXSLTに関連付けられているラジオ・ボタンを選択し、「発行」をクリックします。

4. 「変数のバインド」フィールドの下に、ラベルとそれに対応するテキスト・ボックスがトランスフォーメーションの入力パラメータごとに表示されます。各ラベルはパラメータ名に相当し、各テキスト・ボックスはそのパラメータにマッピングされるXQuery式を定義するためのものです。マッピングはパラメータごとに定義する必要があります。たとえば、XSLトランスフォーメーションにoneおよびtwoという入力パラメータがある場合、「変数マッピング」フィールドには、「one」および「two」というラベルと、ラベルごとにXQuery式を入力するテキスト・ボックスが表示されます。入力変数のマッピングの他に、トランスフォーメーションの入力ドキュメントのXQuery式を指定する必要もあります。このマッピングは、「入力ドキュメント」というラベルが付いたテキスト・ボックスで指定します。

次のXQuery式は、このフィールドの有効な入力例です。

$body/*[1]
$body/po:PurchaseOrder

注意:

bodyという変数名はこのフィールドでは無効な入力となり、例外が発生します。

5. 次の任意の作業を続行します。

- インライン式で使用するためのネームスペースの作成

- XQueryエディタによる変数の構造の作成

- エディタ・ワークスペースのテキスト・フィールドでの式の構築

- 外部XQueryリソースのインラインXQueryへのバインド

- 「検証」をクリックします。式の検証が成功した場合は、メッセージが表示されます。

- 「テスト」をクリックします。「XQueryトランスフォーメーションのテストの前提条件とガイドライン」を参照してください。

15.9 動的XQuery式のインラインXQueryへのバインディング

「XQuery/XSLT式エディタ」ページでは、あらかじめ登録したXQueryリソースの名前を実行時に評価する動的XQuery式を指定できます。このエディタの詳細は、インラインXQueryおよびXPath式の作成と編集を参照してください。

動的XQuery式を定義するには

1. 「動的XQuery」オプションを選択します。

2. 「XQueryリソースの式の入力」領域で、実行時に事前登録されたXQueryリソース名を評価するXQuery式を入力します。

XQueryリソース(リソースの完全な名前を表す)の構文は次のとおりです。

Project/folder1/folder2/XQueryResourceName

3. 「XQueryテンプレートまたはカスタム変数を使用して変数をバインドします」領域に、トランスフォーメーションの入力パラメータを定義します。

- 「XQueryテンプレートの選択」フィールドの「参照」をクリックして、問合せ形式(変数の数と名前)のテンプレートとして使用する既存の登録済のリソースを選択します。テンプレートを選択すると、「変数のバインド」領域に変数が表示されます。テンプレートは構成で保持されることはありません。かわりに、テンプレートは、問合せに変数を指定するのに役立つクイック・スタートとして機能します。

- 「カスタム変数の追加」フィールドに変数名を入力し、「追加」をクリックします。「変数名」の下にリストされている各変数に対して、これにマッピングされるXQuery式を入力します。マッピングはパラメータごとに定義する必要があります。たとえば、XQueryトランスフォーメーションにoneおよびtwoという入力パラメータがある場合、「変数名」フィールドには、「one」および「two」という2つのラベルが表示されます。各ラベルに、XQuery式が入力されるテキスト・ボックスが1つ表示されます。

次のXQuery式は、変数フィールドの有効な入力例です。

$body/*[1]
$body/po:PurchaseOrder

4. 完了した後は、次のいずれかの操作に進みます。

- 「検証」をクリックします。式の検証が成功した場合は、メッセージが表示されます。

- 「テスト」をクリックします。「XQueryトランスフォーメーションのテストの前提条件とガイドライン」を参照してください。

- 変更を保存するか、または破棄します。

15.10 動的XSLT式のインラインXQueryへのバインディング

「XQuery/XSLT式エディタ」ページでは、あらかじめ登録したXSLTリソースの名前を実行時に評価する動的XPath/XQuery式を指定できます。このエディタの詳細は、インラインXQueryおよびXPath式の作成と編集を参照してください。

動的XSLT式を定義するには

1. 「動的XSLT」オプションを選択します。

2. 「XSLTリソースの式を入力」領域で、実行時にあらかじめ登録したXSLTリソースの名前に評価するXPath/XQuery式を入力します。例: $body/*:name/text()

XSLTリソース(リソースの完全な名前を表す)の構文は次のとおりです。

Project/folder1/folder2/myXSLResourceName

3. 「入力のバインド」領域で、XML入力ドキュメントを選択するインラインXQuery/XPath式を入力します。例: $body/message。

4. 「XSLTテンプレートまたはカスタム変数を使用して変数をバインド」領域に、トランスフォーメーションの入力パラメータを定義します。

- 「XSLTテンプレートの選択」フィールドの「参照」をクリックして、問合せ形式(変数の数と名前)のテンプレートとして使用する既存の登録済XSLTリソースを選択します。テンプレートを選択すると、「変数のバインド」領域に変数が表示されます。テンプレートは構成で保持されることはありません。かわりに、テンプレートは、問合せに変数を指定するのに役立つクイック・スタートとして機能します。

- 手動で変数を追加するには、「カスタム変数の追加」フィールドで変数名を入力し、「追加」をクリックします。

- 「変数名」の下にリストされた各変数に、マップされるXQuery/XPath式を入力します。マッピングはパラメータごとに定義する必要があります。たとえば、XQueryトランスフォーメーションにoneおよびtwoという入力パラメータがある場合、「変数名」フィールドには、「one」および「two」という2つのラベルが表示されます。各ラベルに、XQuery式が入力されるテキスト・ボックスが1つ表示されます。

次のXQuery式は、変数フィールドの有効な入力例です。

$body/*[1]
$body/po:PurchaseOrder

5. 完了した後は、次のいずれかの操作に進みます。

- 「検証」をクリックします。式の検証が成功した場合は、メッセージが表示されます。

- 「テスト」をクリックします。「XQueryトランスフォーメーションのテストの前提条件とガイドライン」を参照してください。

- 変更を保存するか、または破棄します。

15.11 「ビルダー」オプションを使用したXQuery比較式の入力

始める前に:

次の手順は、インラインXQueryおよびXPath式の作成と編集の説明に従って、XQuery条件エディタでXQuery条件式を作成または編集していることを前提としています。

XQuery比較式を入力するには

1. まだ選択していない場合は、XQuery条件エディタで、(ワークスペースのボタン・バーの下にある)「ビルダー」を選択します。

2. まだ選択していない場合は、「式ビルダー」ボックスで、「比較式」を選択します。

3. 「オペランド」フィールドに、コンテキスト変数、ネームスペース定義、またはXQuery関数を入力します。

オペランドを構築する場合、「XQuery関数」パレットからXQuery関数を、「ネームスペース定義」パレットからネームスペースを貼り付けることができます。エディタ・ワークスペースのテキスト・フィールドでの式の構築を参照してください。

4. 「演算子」リストから、比較演算子を選択します。

5. 「値」フィールドに、テキストまたはコンテキスト変数を入力します。

テキストは引用符で囲む必要があります。たとえば、"true"は有効ですが、trueは無効です。

6. 「追加」をクリックします。入力したテキストが「式」ペインに表示されます。

7. 追加の条件を構築する際は、ステップ3 - 6を繰り返します。各条件は、条件リストの最後に追加されます。

複数の条件を使用する場合は、次の点を考慮してください。

- 追加の式を作成する場合は、「組合せ」フィールドで必ず「AND」または「OR」オプションを選択してください。

- 条件を選択し、上矢印および下矢印をクリックして、条件のリスト内を上下に移動できます。「編集」アイコンをクリックして条件を更新したり、「削除」アイコンをクリックして条件を削除したりすることもできます。

- 条件の全体定義では、単項式と比較式を混ぜることもできます。

8. (オプション)次のいずれか、または両方を実行します。

- 「検証」をクリックします。式の検証が成功した場合は、メッセージが表示されます。

- 式をテストするには、「テスト」をクリックします。「XQueryトランスフォーメーションのテストの前提条件とガイドライン」を参照してください。

9. 「保存」をクリックしてエディタを閉じ、式をアクションに挿入します。

完了した後に:

「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションの構成を続行します。

15.12 「ビルダー」オプションを使用した単項式の入力

始める前に:

次の手順は、インラインXQueryおよびXPath式の作成と編集の説明に従って、XQuery条件エディタでXQuery条件式を作成または編集していることを前提としています。

XQuery比較式を入力するには

1. まだ選択していない場合は、XQuery条件エディタで、(ワークスペースのボタン・バーの下にある)「ビルダー」を選択します。

2. まだ選択していない場合は、「式ビルダー」ボックスで、「単項式」を選択します。

3. 「NOT」チェックボックスを選択してこの式を否定の式にするか、または空白のままにします。

4. 「式」フィールドに、コンテキスト変数、ネームスペースの定義、またはXQuery関数を入力します。

式を構築する場合、「XQuery関数」パレットからXQuery関数を、「ネームスペース定義」パレットからネームスペースを貼り付けることができます。エディタ・ワークスペースのテキスト・フィールドでの式の構築を参照してください。

5. 「追加」をクリックして、「式」ペインにテキストを追加します。

6. 追加の条件を構築する際は、ステップ3 - 5を繰り返します。各条件は、条件リストの最後に追加されます。

単項式を構築する際は、次の点を考慮してください。

- 追加の式を作成する場合は、「組合せ」フィールドで必ず「AND」または「OR」オプションを選択してください。

- 条件を選択し、上矢印および下矢印をクリックして、条件のリスト内を上下に移動できます。「編集」アイコンをクリックして条件を更新したり、「削除」アイコンをクリックして条件を削除したりすることもできます。

- 条件の全体定義では、単項式と比較式を混ぜることもできます。

7. (オプション)次のいずれか、または両方を実行します。

- 「検証」をクリックします。式の検証が成功した場合は、メッセージが表示されます。

- 式をテストするには、「テスト」をクリックします。「XQueryトランスフォーメーションのテストの前提条件とガイドライン」を参照してください。

8. 「保存」をクリックしてエディタを閉じ、式をアクションに挿入します。

16 Oracle JDeveloperでのパイプラインの操作

この章では、Oracle JDeveloperを使用したパイプラインまたはメッセージ・フローを作成および構成する方法について説明します。項の内容は、パイプライン・ペア、条件付きブランチ、ステージ、操作ブランチ、ルート・ノードおよびエラー・ハンドラの追加および構成です。

メッセージ・フローの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。

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

- JDeveloperでのパイプライン・コンポーネントの追加

- JDeveloperでのパイプラインの表示と編集

- JDeveloperでのパイプラインへの共有変数の追加

- JDeveloperでのパイプラインへのパイプライン・ペア・ノードの追加

- JDeveloperでのパイプラインへの条件付きブランチの追加

- JDeveloperでのパイプラインへの操作ブランチの追加

- JDeveloperでのパイプラインへのRESTブランチの追加

- JDeveloperでのパイプラインへのステージの追加

- JDeveloperでのパイプラインへのルート・ノードの追加

- JDeveloperでのステージおよびルート・ノードの切取り、コピー、貼付け

- JDeveloperでのリシーケンサの構成

16.1 JDeveloperでのパイプライン・コンポーネントの追加

プロジェクトのメッセージ・フローおよびデータ変換または検証を定義するパイプラインを追加します。パイプラインでエラーおよびレポートを定義することもできます。新しいパイプラインを作成すると、パイプライン構成からプロキシ・サービスを生成するオプションが追加されます。

16.1.1 JDeveloperでのパイプラインの追加方法

Oracle JDeveloperのService Bus概要エディタを使用して、パイプライン・コンポーネントをService Busプロジェクトに追加できます。

パイプラインを追加するには:

1. Oracle JDeveloperでService Busプロジェクトを開いていることを確認します。

2. アプリケーション・ナビゲータでプロジェクト・アイコンをダブルクリックし、Service Bus概要エディタを開きます。Service Bus概要エディタの詳細は、「Service Bus概要エディタの概要」を参照してください。

注意:

アプリケーション・ナビゲータでプロジェクト・フォルダを右クリックし、表示されたコンテキスト・メニューで「新規」→「パイプライン」を選択することもできます。その後、手順5からパイプラインの構成を続行します。

3. 「コンポーネント」ウィンドウから、「Service Bus」を選択します。

4. 「リソース」リストからデザイナの「パイプライン/分割結合」レーンにパイプラインをドラッグします。

「パイプライン・サービスの作成」ウィザードが表示されます。

5. パイプラインの設定を構成します。

構成フィールドについては、「ヘルプ」をクリックするか、[F1]キーを押してください。

6. プロキシ・サービスを生成してパイプラインと関連付けるには、ウィザードの「タイプ」ページで「プロキシ・サービスとして公開」をクリックします。プロキシ・サービスのトランスポートを選択し、必要に応じて名前を変更します。

7. ウィザードの最後のページで、「終了」をクリックします。

パイプライン・ファイルがプロジェクトに追加され、デザイナの「パイプライン/分割結合」セクションにパイプラインが表示されます。プロキシ・サービスとしてパイプラインを公開すると、プロキシ・サービスも「プロキシ・サービス」スイムレーンに表示され、コンポーネントが自動的にワイヤリングされます。

8. パイプラインでメッセージ・フローを定義するには、「JDeveloperでのパイプラインの表示と編集」を参照してください。

9. JDeveloperのツールバーで「すべて保存」をクリックします。

16.2 JDeveloperでのパイプラインの表示と編集

プロキシ・サービスに対応するメッセージ・フローは、パイプラインによって処理されます。この項では、パイプライン・エディタを使用したパイプラインの表示方法について説明します。

16.2.1 JDeveloperでのパイプラインの表示および編集方法

Oracle JDeveloperのパイプライン・エディタを使用して、パイプラインのメッセージ・フローを表示および編集します。

パイプラインを表示および編集するには:

1. Oracle JDeveloperでService Busプロジェクトを開いていることを確認します。

2. 次の方法の1つを使用して、パイプラインのメッセージ・フローを編集します。

- アプリケーション・ナビゲータで、パイプライン・ノードを見つけます。パイプライン・ノードを右クリックし、「開く」を選択します。かわりに、パイプライン・ノードをダブルクリックして開くこともできます。

- アプリケーション・ナビゲータで、プロジェクト・ノード(またはoverview.xml)をクリックし、概要エディタを開きます。
概要エディタで、パイプライン・コンポーネントをダブルクリックし、パイプライン・エディタを開きます。

パイプライン・エディタが表示されます。エディタの左下隅の「設計」タブが選択されていることを確認します。

選択されたパイプラインに対してまだメッセージ・フローが作成されていない場合は、パイプライン・エディタの「設計」ビューのページにパイプライン・アイコンが1つ表示されます。これは、メッセージ・フローの開始ノードです。

3. 次の方法の1つを使用して、パイプライン・コンポーネント(ノード)を追加します。

- 開始ノードを右クリックし、追加できるパイプライン・コンポーネントのオプションを取得します。図16-1は、開始ノードに使用できるオプションを示しています。ルート・ノード、PipelinePairノード、条件付きブランチなどのノードを追加できます。

図16-1 ノードの右クリックによるパイプライン・コンポーネントの追加

- または、「コンポーネント」ウィンドウから追加するパイプライン・コンポーネントを選択し、そのコンポーネントをパイプライン・エディタ・ウィンドウにドラッグします。パイプライン内でコンポーネントをドロップできる場所を示す黄色の円が表示されます。コンポーネントを黄色の円にドラッグします。黄色の円が緑色に変化します。コンポーネントを解放して追加します。図16-2は、開始ノードに追加しようとしているパイプライン・ペア・ノードを示しています。

図16-2 開始ノードへのパイプライン・ペアの追加

エディタにコンポーネントを追加するときには、エディタにそのコンポーネントを表すアイコンが表示されます。コンポーネント間の関係は、線と境界を示す四角形で示されます。

図16-3は、パイプライン・ペア・ノードがフローに追加されたパイプラインを示しています。パイプライン・ペアは、リクエスト・パイプラインとレスポンス・パイプラインで構成されています。リクエストおよびレスポンスの各パイプラインには、アクション・ノードを含めることができるステージがあります。

図16-3 パイプライン・ペア・ノードのあるパイプライン

4. さらにコンポーネントをエディタに追加することでパイプラインの構築を続けます。たとえば、ステージ・ノードに通信アクションを追加するには、「コンポーネント」ウィンドウからエディタのステージ・ノードに通信アクションをドラッグできます。かわりに、ステージ・ノードを右クリックし、ステージ・ノードに追加できるパイプライン・コンポーネントのオプションを取得することもできます。各コンポーネントに使用できるオプションは、コンテキストに応じて異なります。

5. Oracle JDeveloperツールバーで、「保存」をクリックします。

16.3 JDeveloperでのパイプラインへの共有変数の追加

1つのコール・チェーン内の2つのパイプラインで同じ共有変数を宣言する場合、これらは同じ変数を読み取り、変更します。つまり、パイプラインP1で共有変数varを宣言し、パイプラインP2でも共有変数varを宣言する場合、P1のvarの変更はP2に表示され、逆も当てはまります。共有変数は、文字列、ブールまたはXMLのデータ型にする必要があります。

プロキシ・サービスでメッセージを受信して処理する場合、共有変数を使用する呼び出されたすべてのパイプラインは、その変数に対して同じ値を読書きします。プロキシで受信する以降のメッセージにより、呼び出されたパイプラインに共有変数の新しいインスタンスが作成されます。

共有変数は、ローカル・プロキシの呼出しと分割-結合コンポーネントの呼出しで機能します。たとえば、パイプラインP1およびP2で共有変数を宣言するとします。ここで、P1がローカル・プロキシ・サービスまたは分割-結合コンポーネントを呼び出し、このサービスまたはコンポーネントが同様にP2を呼び出す場合、P1とP2は引き続き共有変数を共有します。

次の制限事項が共有変数の使用に適用されます。

- システム変数($body、$attachments、$operation、$inbound、$outboundなど)は共有できません。

- 変数は、ローカル以外のプロキシ呼出しで共有できません。たとえば、パイプラインでHTTPプロキシ・サービスを呼び出す場合、共有変数はこのコール間で伝播されません。

- 変数は、パイプラインと分割-結合リソース間で共有できません。

- Javaとバイナリ・コンテンツ・タイプを使用する変数はサポートされません。たとえば、XML構造に<ctx:java-content/>があるXML型変数は、共有変数としてサポートされません。

16.3.1 JDeveloperでのパイプラインへの共有変数の追加方法

パイプライン・エディタを使用して、パイプラインのメッセージ・フローに共有変数を追加します。

パイプラインに共有変数を追加するには

1. パイプライン・エディタで、開始ノードを右クリックします。

2. 表示されたコンテキスト・メニューから「共有変数の追加」を選択します。

3. 「共有変数名の入力」フィールドに共有変数の名前を入力します。

4. 「OK」をクリックして、パイプラインに共有変数を追加します。

16.4 JDeveloperでのパイプラインへのパイプライン・ペア・ノードの追加

パイプラインには、パイプライン・ペア・ノード(プロキシ・サービス(またはサービスの処理用)のリクエストおよびレスポンス・パイプライン)と、ステージ、パイプラインおよびプロキシ・サービスに対して定義できるエラー・ハンドラ・パイプラインをゼロ個以上含めることができます。パイプラインは、1つまたは複数のステージを持つことができ、ステージはアクションを持ちます。

16.4.1 JDeveloperでのパイプラインへのパイプライン・ペア・ノードの追加方法

パイプライン・エディタを使用して、パイプラインのメッセージ・フローにパイプライン・ペアを追加します。

パイプラインにパイプライン・ペアを追加するには:

1. パイプライン・エディタで、開始ノード・アイコンを右クリックします。

2. 表示されたコンテキスト・メニューから「中に挿入」→「PipelinePairNode」を選択します。パイプライン・ペア・ノードが挿入されます。

注意:

かわりに、「パイプライン・ペア」コンポーネントを「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグすることも選択できます。「パイプライン・ペア」コンポーネントは、「メッセージ・フロー」カテゴリの「ノード」セクションの下にあります。

3. パイプライン・ペア・ノードのデフォルト名を変更して説明を追加するには、次の操作を行います。

a. パイプライン・ペア・ノードをクリックし、それを選択します。「プロパティ」ウィンドウに、選択したコンポーネントのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「プロパティ」ウィンドウで、必要に応じて名前および説明を変更します。

c. Oracle JDeveloperツールバーで、「保存」をクリックします。

4. パイプラインにステージを追加するには、「JDeveloperでのパイプラインへのステージの追加」を参照してください。

5. パイプラインのステージにアクションを追加するには、「JDeveloperでのパイプラインのアクションの追加および編集」を参照してください。

6. パイプライン・エディタで、「JDeveloperでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

7. Oracle JDeveloperツールバーで、「保存」をクリックします。

16.5 JDeveloperでのパイプラインへの条件付きブランチの追加

ブランチ・ノードを使用すると、可能ないくつかのパスのうちの1つに限定して処理を進めることができます。分岐は、XPathベースの切替え表に基づいて実行されます。表の各ブランチは、条件(たとえば、<500)を指定し、これが単一のXPath式(たとえば、$bodyの./ns: PurchaseOrder/ns:totalCost)に対してパイプラインの降順に評価されます。最初に満たされた条件によって、進むべきブランチが決定されます。満たされる分岐条件がない場合は、デフォルトのブランチに進みます。ブランチ・ノードでは、パイプライン内にいくつかの子孫を持つことができます(デフォルトのブランチを含め各ブランチに1つずつ)。

プロキシ・サービスがWSDLファイルに基づいておらず、複数のドキュメント・タイプを入力として受信する場合は、条件付きブランチ・ノードを使用することを検討できます。

条件付きブランチ処理は、単純でありながらユニークな文字列値のタグが付いたブランチをまとめたルックアップ表を基準に行われます。メッセージ・コンテキストの変数をそのノードのルックアップ変数として指定し、実行時に、この値を使用してどのブランチに進むかが判断されます。ルックアップ変数に一致するブランチがない場合は、デフォルトのブランチに進みます。ブランチ・ノードに到達する前にルックアップ変数の値を設定するように、プロキシ・サービスを設定する必要があります。

16.5.1 JDeveloperでのパイプラインへの条件付きブランチの追加方法

パイプライン・エディタを使用して、パイプラインのメッセージ・フローに条件付きブランチを追加します。

パイプラインに条件付きブランチを追加するには:

1. パイプライン・エディタで、開始ノード・アイコンまたは「ブランチ・ノード」アイコンを右クリックします。

2. 表示されたコンテキスト・メニューから「中に挿入」→「条件付きブランチ」を選択します。条件付きブランチ・ノードが追加され、挿入したブランチ・ノードの後の既存のノードが、新しい条件付きブランチ・ノードのデフォルト・ブランチに移動します。

注意:

かわりに、「条件付きブランチ」コンポーネントを「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグすることも選択できます。「条件付きブランチ」コンポーネントは、「メッセージ・フロー」カテゴリの「ノード」セクションの下にあります。

3. 条件付きブランチ・ノードのプロパティを変更するには、次のように実行します。

a. 「条件付きブランチ」ノードをクリックし、それを選択します。「プロパティ」ウィンドウに、選択したコンポーネントのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「全般」セクションの下で、必要に応じて名前および説明を変更します。

c. 「条件」セクションの下で、条件として使用するXPath式を指定します。XPath式ビルダーは、「fx」アイコンをクリックすることで起動できます。

d. Oracle JDeveloperツールバーで、「保存」をクリックします。

4. ブランチのプロパティを変更するには、次のように実行します。

a. ブランチ・ノードをクリックし、それを選択します。「プロパティ」ウィンドウに、選択したコンポーネントのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「名前」の下で、ブランチの名前を指定します。

c. 「値」の下で、値として使用する演算子およびXPath式を指定します。XPath式ビルダーは、「fx」アイコンをクリックすることで起動できます。

d. Oracle JDeveloperツールバーで、「保存」をクリックします。

5. オプション:

- 新規ブランチの追加アイコンをクリックし、新規ブランチ・ノードを追加します。

- ブランチを右クリックし、「削除」を選択してブランチを削除します。

6. Oracle JDeveloperツールバーで、「保存」をクリックします。

7. パイプライン・エディタで、「JDeveloperでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

8. Oracle JDeveloperツールバーで、「保存」をクリックします。

16.6 JDeveloperでのパイプラインへの操作ブランチの追加

パイプラインでWeb Services Description Language (WSDL)ベースのプロキシ・サービスを定義する場合、操作固有の処理が必要になります。Service Busでは、操作に基づくブランチ・ノードを手動で構成するかわりに、操作に基づいて自動的に分岐するように構成された、最小限のブランチ・ノードが用意されています。つまり、操作ブランチ・ノードをパイプラインに作成すると、Oracle Service Busコンソールでは、WSDLに定義された操作がブランチ・ノード構成ページに表示されるため、これらの操作に基づいて分岐ロジックをすばやく構築できます。

ブランチ・ノードを使用すると、可能ないくつかのパスのうちの1つに限定して処理を進めることができます。分岐は、XPathベースの切替え表に基づいて実行されます。表の各ブランチは、条件(たとえば、<500)を指定し、これが単一のXPath式(たとえば、$bodyの./ns: PurchaseOrder/ns:totalCost)に対してパイプラインの降順に評価されます。最初に満たされた条件によって、進むべきブランチが決定されます。満たされる分岐条件がない場合は、デフォルトのブランチに進みます。ブランチ・ノードでは、パイプライン内にいくつかの子孫を持つことができます(デフォルトのブランチを含め各ブランチに1つずつ)。

16.6.1 JDeveloperでのパイプラインへの操作ブランチの追加方法

パイプライン・エディタを使用して、パイプラインのメッセージ・フローに操作ブランチを追加します。

パイプラインに操作ブランチを追加するには:

1. パイプライン・エディタで、開始ノードまたは「ブランチ・ノード」アイコンを右クリックします。

2. 表示されたコンテキスト・メニューから「中に挿入」→「操作ブランチ」を選択します。操作ブランチ・ノードが追加され、挿入したブランチ・ノードの後の既存のノードが、新しい操作ブランチ・ノードのデフォルト・ブランチに移動します。

注意:

かわりに、「操作ブランチ」コンポーネントを「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグすることも選択できます。「操作ブランチ」コンポーネントは、「メッセージ・フロー」カテゴリの「ノード」セクションの下にあります。

3. 操作ブランチ・ノードのプロパティを変更するには、次のように実行します。

a. 操作ブランチ・ノードをクリックし、それを選択します。「プロパティ」ウィンドウに、選択したコンポーネントのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 必要に応じて名前と説明を変更します。

c. Oracle JDeveloperツールバーで、「保存」をクリックします。

4. ブランチのプロパティを変更するには、次のように実行します。

a. ブランチ・ノードをクリックし、それを選択します。「プロパティ」ウィンドウに、選択したコンポーネントのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. そのブランチによって表される「操作」を選択します。

c. Oracle JDeveloperツールバーで、「保存」をクリックします。

5. オプション:

- 新規ブランチの追加アイコンをクリックし、新規ブランチ・ノードを追加します。

- ブランチを右クリックし、「削除」を選択してブランチを削除します。

6. パイプライン・エディタで、「JDeveloperでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

7. Oracle JDeveloperツールバーで、「保存」をクリックします。

16.7 JDeveloperでのパイプラインへのRESTブランチの追加

パイプラインで未入力(デザインタイムのWADLなし)のネイティブRESTベース・プロキシ・サービスを定義する場合、クライアント・リクエストに固有の処理が必要です。Service Busでは、これらのリクエストに基づくブランチ・ノードを手動で構成するかわりに、使用されたメディア・タイプ、相対URI、HTTP動詞、またはこれらの基準の組合せに基づいて自動的に分岐するように構成された、最小限のブランチ・ノードが用意されています。パイプラインにRESTブランチ・ノードを作成する場合は、これらの基準に基づいて分岐ロジックを簡単に構築できます。

クライアント・リクエストをフィルタ処理するために次のオプションを構成できます。

- メディア・タイプの消費: application/jsonなど、このブランチで許可されている、クライアントによって送信されるメディア・タイプのリスト。

- パス: このブランチに許可されている単一のURIパターン(相対URIパス)。たとえば、/dogs/{id}は有効なパスです。

- 動詞: このブランチで許可されている単一のHTTP動詞(GET、PUT、POST、またはDELETE)。

注意:

RESTブランチ・ラベルにRESTブランチの実行の一部として、/name/{PlaceName}/zip/{ZipCode}などのパラメータ化したパス式が含まれている場合、メッセージ・コンテキスト変数PlaceNameおよびZipCodeは、Pittsburghや15217のように、実行時の実際のパス・セグメントの値で自動的に定義されます。これらのパラメータの値は、インバウンドHTTP相対パス・メタデータから抽出されます。

変数のスコープは、対応するブランチでネストされているすべてのアクションです

RESTブランチはネイティブの未入力RESTサービス用のパイプラインでのみ使用できます。その他のサービス・タイプはサポートされていません。

16.7.1 JDeveloperでのパイプラインへのRESTブランチの追加方法

パイプライン・エディタを使用して、パイプラインのメッセージ・フローにRESTブランチを追加します。

パイプラインにRESTブランチを追加するには:

1. パイプライン・エディタで、開始ノードまたは「ブランチ・ノード」アイコンを右クリックします。

2. 表示されたコンテキスト・メニューから「中に挿入」→「RESTブランチ」を選択します。RESTブランチ・ノードが追加され、挿入したブランチ・ノードの後の既存のノードが、新しいRESTブランチ・ノードのデフォルト・ブランチに移動します。

注意:

かわりに、「RESTブランチ」コンポーネントを「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグすることも選択できます。「RESTブランチ」コンポーネントは、「メッセージ・フロー」カテゴリの「ノード」セクションの下にあります。

3. RESTブランチ・ノードのプロパティを変更するには、次のように実行します。

a. RESTブランチ・ノードをクリックし、それを選択します。「プロパティ」ウィンドウが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メニューから「プロパティ」を選択します。

b. 「全般」タブから、必要に応じて名前を変更します。

c. Oracle JDeveloperツールバーで、「保存」をクリックします。

4. 「プロパティ」ウィンドウの 「ブランチ」タブから、次のブランチ・プロパティのいずれかを1つ以上構成します。

- 消費: メディア・タイプ: 「追加」(+)アイコンをクリックします。このブランチで使用されるクライアント・リクエストによって送信されるメディア・タイプの名前を入力します(application/xmlまたはapplication/jsonなど)。「追加」(+)アイコンをクリックして行を追加すると、複数のメディア・タイプを入力できます。「削除」(X)アイコンをクリックして、選択した行を削除します。

注意:

タイプまたはサブタイプのワイルドカードがサポートされています。たとえば、application/xml、examples/*、および*/xmlがサポートされます。examples/*+xmlなどの部分ワイルドカードはサポートされていません。

- パス: /dogs/{id}など、このブランチで使用されるクライアント・リクエストの相対URIパスを入力します。

- 動詞: このブランチで使用されるクライアント・リクエストのHTTP動詞を選択します。

5. オプション:

a. 新規ブランチの追加アイコンをクリックし、新規ブランチ・ノードを追加します。

b. ブランチを右クリックし、「削除」を選択してブランチを削除します。

6. パイプライン・エディタで、「JDeveloperでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

7. Oracle JDeveloperツールバーで、「保存」をクリックします。

16.8 JDeveloperでのパイプラインへのステージの追加

リクエスト・パイプライン、レスポンス・パイプライン、およびエラー・ハンドラには、ステージを含めることができます。ステージでは、パイプラインを通過するメッセージを処理するアクションを構成します。

16.8.1 JDeveloperでのパイプラインへのステージの追加方法

パイプライン・エディタを使用して、パイプラインのメッセージ・フローにステージを追加します。

パイプラインにステージを追加するには:

1. パイプライン・エディタで、パイプライン・ペア・ノードの「リクエスト・パイプライン」アイコンまたは「レスポンス・パイプライン」アイコンを右クリックします。

2. 表示されたコンテキスト・メニューから「中に挿入」→「ステージ」を選択します。ステージ・ノードが追加されます。

注意:

かわりに、「ステージ」コンポーネントを「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグすることも選択できます。「ステージ」コンポーネントは、「メッセージ・フロー」カテゴリの「ノード」セクションの下にあります。

3. ステージのデフォルト名を変更して説明を追加するには、次を行います:

a. ステージ・ノードをクリックし、それを選択します。「プロパティ」ウィンドウに、選択したコンポーネントのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 選択したステージ・ノードの「名前」および「説明」フィールドを編集します。

c. Oracle JDeveloperツールバーで、「保存」をクリックします。

4. ステージにアクションを追加するには、「ステージ」アイコンを右クリックし、表示されるコンテキスト・メニューから「中に挿入」→「ActionName」をクリックします。「JDeveloperでのパイプラインのアクションの追加および編集」を参照してください。

5. ステージにエラー処理を追加するには、「ステージ」アイコンを右クリックし、表示されるコンテキスト・メニューから「ステージ・エラー・ハンドラの追加」をクリックします。「JDeveloperでのエラー・ハンドラの追加」を参照してください。

6. 「JDeveloperでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

7. Oracle JDeveloperツールバーで、「保存」をクリックします。

16.9 JDeveloperでのパイプラインへのルート・ノードの追加

ルート・ノードでは、別のサービスとのリクエスト/レスポンス通信が実行されます。ルート・ノードはプロキシ・サービスに関するリクエスト処理とレスポンス処理の境界を表します。ルート・ノードがリクエスト・メッセージをディスパッチすると、リクエスト処理が終了したと見なされます。ルート・ノードがレスポンス・メッセージを受信したときに、レスポンス処理が始まります。ルート・ノードは、リクエスト・トランスフォーメーション、レスポンス・トランスフォーメーション、および条件付きルーティングに対応します。

ルート・ノードはリクエスト処理とレスポンス処理の境界を表すので、パイプライン内に子孫を持つことはできません。

16.9.1 JDeveloperでのパイプラインへのルート・ノードの追加方法

パイプライン・エディタを使用して、パイプラインのメッセージ・フローにルート・ノードを追加します。

パイプラインにルート・ノードを追加するには:

1. パイプライン・エディタで、開始ノードまたは「ブランチ・ノード」アイコンを右クリックします。

2. コンテキスト・メニューから「中に挿入」→「ルート」を選択します。ルート・ノードが追加されます。

注意:

かわりに、「ルート」コンポーネントを「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグすることも選択できます。「ルート」コンポーネントは、「メッセージ・フロー」カテゴリの「ノード」セクションの下にあります。

3. ルート・ノードにアクションを追加するには、「ルート・ノード」アイコンを右クリックし、コンテキスト・メニューから適切なオプションを選択します。ルート・ノードに追加できるアクションの詳細は、次のセクションを参照してください。

- JDeveloperでのIf Thenアクションの追加

- JDeveloperでのルート・ノードへの動的ルーティングの追加

- JDeveloperでのルート・ノードへのルーティング・アクションの追加

- JDeveloperでのルート・ノードへのルーティング表の追加

- JDeveloperでのエラー・ハンドラの追加

4. パイプライン・エディタで、「JDeveloperでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

5. Oracle JDeveloperツールバーで、「保存」をクリックします。

16.10 JDeveloperでのステージおよびルート・ノードの切取り、コピー、貼付け

パイプライン・エディタでは、ステージおよびルート・ノードの切取り、コピーおよび貼付けが可能です。

- ステージまたはルート・ノードを切り取るには、そのアイコンを右クリックし、「切取り」または「コピー」を選択します。

- このプロキシ・サービスのメッセージ・フロー内の異なるパイプライン・ペアから、または異なるプロキシ・サービスのメッセージ・フローから切り取ったりコピーしたステージを貼り付けるには、次のいずれかを行います。

- ターゲットの「リクエスト・パイプライン」または「レスポンス・パイプライン」アイコンを右クリックして、「貼付け」をクリックします。

- パイプラインの既存の「ステージ」アイコンを右クリックし、「貼付け」をクリックします。

- 別のパイプラインのメッセージ・フローから切り取ったりコピーしたルート・ノードを貼り付けるには、ターゲットの「ブランチ・ノード」アイコンをクリックして、「ルートの貼付け」をクリックします。

16.11 JDeveloperでのリシーケンサの構成

Service Busのリシーケンサは、関連はあるが順序どおりではないメッセージのストリームを連続した順序に並べ替えます。受信メッセージが到着すると、それらはランダムな順序になっています。リシーケンサは、順次または時系列の情報に基づきメッセージを順序付け、メッセージをターゲット・サービスに対して正しい手順で送信します。順序付けは、選択した順序付け戦略に基づき実行されます。

リシーケンサは、パイプライン・コンポーネント内で構成できます。次のサービス・タイプのパイプラインがサポートされます。

- WSDL: リシーケンスは、リクエスト・タイプのみの操作に利用できます。

- メッセージ・タイプ: リクエスト・メッセージ・タイプは「XML」、レスポンス・メッセージ・タイプは「なし」にします。

注意:

リシーケンサでは、「任意のXML」と「任意のSOAP」のサービス・タイプはサポートされません。WSDLベースのサービスでは、WSDLファイルは一方向であることが必要です。つまり、これに出力要素を含めることはできません。リシーケンス・パイプラインでの生成WSDLファイルの使用については、「JDeveloperでのサービスからのWSDLファイルの生成方法」を参照してください。

16.11.1 JDeveloperでパイプラインでのリシーケンスを構成する方法

この項では、JDeveloperを使用してパイプラインでリシーケンサを構成する方法について説明します。

パイプラインでリシーケンスを有効にするには:

1. JDeveloperでService Busプロジェクトを開いていることを確認します。

2. 次の方法の1つを使用して、パイプライン構成を編集します。

- アプリケーション・ナビゲータで、パイプライン・ノードを見つけます。パイプライン・ノードを右クリックし、「開く」を選択します。かわりに、パイプライン・ノードをダブルクリックして開くこともできます。

- アプリケーション・ナビゲータで、プロジェクト・ノード(またはoverview.xml)をクリックし、概要エディタを開きます。
概要エディタで、パイプライン・コンポーネントをダブルクリックし、パイプライン・エディタを開きます。

パイプライン・エディタが表示されます。エディタの左下隅から「構成」タブを選択します。

3. エディタの左ペインから「リシーケンサ」を選択します。「リシーケンサ構成」ページが表示されます。図16-4は、「リシーケンサ構成」ページを示しています。

図16-4 「リシーケンサ構成」ページ

4. 「リシーケンサの有効化」を選択し、パイプラインのリシーケンスを有効化します。

5. 「リシーケンス・レベル」を選択します。「パイプライン」を選択して、コンポーネント・レベルでリシーケンスを構成します。「操作」を選択して、操作レベルでリシーケンスを構成します。リシーケンス・レベルの詳細は、「JDeveloperでのリシーケンス・レベルの選択」を参照してください。

「操作」を選択した場合、操作ごとにリシーケンスを個別に構成するオプションを利用できます。

6. 「再順序」モードを選択します。「操作」レベルでリシーケンスを構成する場合、各操作に対応する「リシーケンス・モード」を選択します。各種リシーケンス・オプションの詳細は、「JDeveloperでのリシーケンス・モードの構成方法」を参照してください。

選択した「再順序」モードに応じて、そのモードに対応するオプションが表示されます。たとえば、「標準」モードを選択すると、「グループ」、「ID」などの値を選択する必要があります。図16-5は、「標準」モードを選択した場合に表示されるリシーケンサ構成オプションを示しています。

図16-5 「標準」リシーケンス・モードの場合のリシーケンサ・オプション

7. 使用するワーク・マネージャを指定する「ディスパッチ・ポリシー」を入力します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

8. JDeveloperツールバーで、「保存」をクリックします。

16.11.2 JDeveloperでのリシーケンス・レベルの選択

リシーケンスは、パイプライン・レベルまたは操作レベルのいずれかで定義できます。リシーケンス・レベルの値は、次のとおりです。

- パイプライン: コンポーネント・レベルで指定した共通構成を使用してすべてのメッセージをリシーケンスします。コンポーネントに複数の操作がある場合、各操作のメッセージは、共有コンポーネント構成を使用して個別に順序付けられます。
コンポーネント・レベルのリシーケンスは、パイプライン・コンポーネントのすべての操作でリクエスト一方向メッセージをサポートする場合のみ許可されます。操作のサブセットのみがリクエスト一方向メッセージをサポートする場合、これらの操作に操作レベルのリシーケンスを個別に指定できます。

- 操作: WSDLベースのパイプラインの場合、リシーケンスは操作レベルで構成できます。各操作には異なるリシーケンサ構成を設定できます。リクエスト一方向メッセージをサポートする操作のみをリシーケンスできます。WSDL以外のパイプラインでは、操作レベルでリシーケンサを構成できません。

16.11.3 JDeveloperでのリシーケンス・モードの構成方法

この項では、様々なリシーケンス・モードの構成方法を示します。各種リシーケンス・モードの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のリシーケンス順序に関する項を参照してください。デフォルトでは、グループIDの文字数制限は1000、IDの文字数制限は100です。

16.11.3.1 標準リシーケンサの構成

標準リシーケンサを構成するには:

1. 「リシーケンサ構成」ページで、「再順序」ドロップダウン・リストから「標準」を選択します。操作レベルでリシーケンスを構成する場合、操作の「リシーケンス・モード」ドロップダウン・リストから、「標準」を選択します。

「リシーケンサ・オプション」または「操作の詳細」領域に、標準リシーケンスに関連するフィールドが移入されます。詳細は、図16-5を参照してください。

2. 表16-1に示すフィールドに入力します。

表16-1 標準リシーケンスのオプション

フィールド名

説明

デフォルト値

必須

グループ

グループ化が行われる受信メッセージのフィールドを指し示すXQuery式。値を入力しない場合、すべてのメッセージが1つのデフォルト・グループに配置されます。

右側の「式ビルダー」アイコンをクリックし、XQuery式ビルダーを起動します。

N/A

N

ID

リシーケンスが行われる受信メッセージのフィールドを指し示すXQuery式。

右側の「式ビルダー」アイコンをクリックし、XQuery式ビルダーを起動します。

N/A

Y

開始

ID順序の開始番号。

1

N

増分

ID順序の増分。

1

N

タイムアウト

予期されているメッセージを待機する期間(秒単位)。タイムアウトが発生すると、再シーケンサはグループをタイムアウトとしてロックします。

デフォルト値の0の場合、デフォルトではグループに対してタイムアウトが発生することはありません。

0

N

16.11.3.2 FIFOリシーケンサの構成

FIFOリシーケンサを構成するには:

1. 「リシーケンサ構成」ページで、「再順序」ドロップダウン・リストから「FIFO」を選択します。操作レベルでリシーケンスを構成する場合、操作の「リシーケンス・モード」ドロップダウン・リストから、「FIFO」を選択します。

「リシーケンサ・オプション」または「操作の詳細」領域に、FIFOリシーケンスに関連するフィールドが移入されます。

2. 「グループ」フィールドに、グループ化が実行される受信メッセージ内のフィールドを指すXQuery式を入力します。

右側の「式ビルダー」アイコンをクリックし、XQuery式ビルダーを起動します。

16.11.3.3 ベスト・エフォート・リシーケンサの構成

ベスト・エフォート・リシーケンサを構成するには:

1. 「リシーケンサ構成」ページで、「再順序」ドロップダウン・リストから「ベスト・エフォート」を選択します。操作レベルでリシーケンスを構成する場合、操作の「リシーケンス・モード」ドロップダウン・リストから、「ベスト・エフォート」を選択します。

「リシーケンサ・オプション」または「操作の詳細」領域に、ベスト・エフォート・リシーケンスに関連するフィールドが移入されます。

2. 表16-2に示すフィールドに入力し、ベスト・エフォート・リシーケンサを構成します。

図16-2 ベスト・エフォート・リシーケンス・オプション

フィールド名

説明

デフォルト値

必須

グループ

グループ化が行われる受信メッセージのフィールドを指し示すXQuery式。ここに値を入力しない場合、すべてのメッセージは1つのデフォルト・グループ内になると見なされます。

右側の「式ビルダー」アイコンをクリックし、XQuery式ビルダーを起動します。

N/A

N

ID

リシーケンスが行われる、IDを含む受信メッセージのフィールドを指し示すXQuery式。

右側の「式ビルダー」アイコンをクリックし、XQuery式ビルダーを起動します。

N/A

Y

データ型

順序IDのデータ型。注文プロセスはデータ型に基づいています。サポートされる値は、「日付/時刻」と「数値」です。

数値

Y

最大行数

再シーケンサが一度にデータ・ストアから取得する、順に従ったメッセージの数。これは正の整数にしてください。

「最大行数」または「時間ウィンドウ」(次に説明)を指定する必要がありますが、両方を指定しないでください。

5

N

時間ウィンドウ

メッセージが到着した後、リシーケンスに関してデータ・ストアからメッセージを選択するまでに待機する秒単位の時間。デフォルト値の0の場合、待機しません。

「時間ウィンドウ」または「最大行数」(前述)を指定する必要がありますが、両方を指定しないでください。

0

N

17 Oracle JDeveloperでのパイプライン・アクションの操作

この項では、Oracle JDeveloperを使用して様々なタイプのアクションをメッセージ・フローに追加する方法について説明します。

アクションとは、パイプラインを流れるメッセージの定義方法を定義するパイプライン・ステージ、エラー・ハンドラ・ステージ、ルート・ノード、およびブランチ・ノードの要素です。Oracle JDeveloperのパイプライン・エディタを使用して、ルート、パブリッシュ、サービス・コールアウト、トランスポート・ヘッダー、条件付きアクション、エラー・アクションおよびメッセージ変換アクションなどのアクションを追加します。

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

- JDeveloperでのパイプラインのアクションの追加および編集

- JDeveloperでのパブリッシュ・アクションの追加

- JDeveloperでのパブリッシュ表アクションの追加

- JDeveloperでの動的パブリッシュ・アクションの追加

- JDeveloperでのルーティング・オプション・アクションの追加

- JDeveloperでのサービス・コールアウト・アクションの追加

- JDeveloperでのトランスポート・ヘッダー・アクションの追加

- JDeveloperでのルート・ノードへの動的ルーティングの追加

- JDeveloperでのルート・ノードへのルーティング・アクションの追加

- JDeveloperでのルート・ノードへのルーティング表の追加

- JDeveloperでのFor Eachアクションの追加

- JDeveloperでのIf Thenアクションの追加

- JDeveloperでのエラーの生成アクションの追加

- JDeveloperでの返信アクションの追加

- JDeveloperでの再開アクションの追加

- JDeveloperでのスキップ・アクションの追加

- JDeveloperでの割当てアクションの追加

- JDeveloperでの削除アクションの追加

- JDeveloperでの挿入アクションの追加

- JDeveloperでのJavaコールアウト・アクションの追加

- JDeveloperでのJavaScriptアクションの追加

- JDeveloperでのMFL変換アクションの追加

- JDeveloperでのnXSD変換アクションの追加

- JDeveloperでの名前変更アクションの追加

- JDeveloperでの置換アクションの追加

- JDeveloperでの検証アクションの追加

- JDeveloperでのアラート・アクションの追加

- JDeveloperでのログ・アクションの追加

- JDeveloperでのレポート・アクションの追加

- JDeveloperでのエラー・ハンドラの追加

- JDeveloperでのアクションまたはステージの無効化

17.1 JDeveloperでのパイプラインのアクションの追加および編集

アクションとは、パイプラインを流れるメッセージの定義方法を定義するパイプライン・ステージ、エラー・ハンドラ・ステージ、ルート・ノード、およびブランチ・ノードの要素です。

始める前に

この手順は、「JDeveloperでのパイプラインの表示と編集」の説明に従って、すでにパイプライン・エディタでパイプラインを編集していることを前提としています。

また、パイプライン・ステージ、ルート・ノードまたはエラー・ハンドラ・ステージをすでに追加していることも前提としています。参照:

- JDeveloperでのパイプラインへのパイプライン・ペア・ノードの追加

- JDeveloperでのパイプラインへのステージの追加

- JDeveloperでのエラー・ハンドラの追加

パイプラインにアクションを追加するには:

1. パイプライン・エディタで、アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、アクションを追加する「ステージ」を右クリックします。

2. 表示されたコンテキスト・メニューから「中に挿入」→「アクション名」を選択します。使用可能なアクション名はコンテキストによって異なります。

注意:

かわりに、「アクション」コンポーネントを「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグすることも選択できます。

エディタ・ウィンドウにコンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つにコンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。

パイプラインに構成できるアクションを表17-1から表17-4に示します。

表17-1 パイプライン - 通信アクション

アクション

説明

詳細

パブリッシュ

静的に指定されたサービスにメッセージをパブリッシュします。

JDeveloperでのパブリッシュ・アクションの追加

パブリッシュ表

ゼロまたはそれ以上の静的に指定されたサービスにメッセージをパブリッシュします。切替え式の条件ロジックを使用して、どのサービスをパブリッシュに使用するか実行時に決定します。

JDeveloperでのパブリッシュ表アクションの追加

動的にパブリッシュ

XQuery式によって識別されたサービスにメッセージをパブリッシュします。

JDeveloperでの動的パブリッシュ・アクションの追加

ルーティング・オプション

アウトバウンド・リクエストのURI、サービスの品質、モード、再試行パラメータ、メッセージ優先度の各プロパティの一部またはすべてを変更します。

JDeveloperでのルーティング・オプション・アクションの追加

サービス・コールアウト

Service Busに登録済のプロキシ・サービスまたはビジネス・サービスの同期(ブロッキング)コールアウトを構成します。

JDeveloperでのサービス・コールアウト・アクションの追加

トランスポート・ヘッダー

メッセージのトランスポート・ヘッダーの値を設定します。

JDeveloperでのトランスポート・ヘッダー・アクションの追加

動的ルーティング

XQueryリソースで使用できるルーティング情報に基づいて、メッセージ・ルートを割り当てます。

JDeveloperでのルート・ノードへの動的ルーティングの追加

ルーティング

メッセージのターゲット・サービスを指定し、ターゲット・サービスへのメッセージのルーティング方法を構成します。

JDeveloperでのルート・ノードへのルーティング・アクションの追加

ルーティング表

切替え式の条件表に含まれた一連のルートを割り当てます。これは、単一のXQuery式の結果に基づいて、異なるルートが選択されます。

JDeveloperでのルート・ノードへのルーティング表の追加

表17-2 パイプライン - フロー制御アクション

アクション

説明

詳細

For Each

値のシーケンスを反復処理し、アクションのブロックを実行します。

JDeveloperでのFor Eachアクションの追加

If...Then

XQuery式のブール結果に基づいて、1つのアクションまたは一連のアクションを条件付きで実行します。

JDeveloperでのIf Thenアクションの追加

エラーの生成

指定されたエラー・コード(文字列)と記述を含む例外を発生させます。

JDeveloperでのエラーの生成アクションの追加

返信

呼出し元に即時返信を送信します。

JDeveloperでの返信アクションの追加

再開

エラー・ハンドラによってエラーが処理された後、メッセージ・フローを再開します。

JDeveloperでの再開アクションの追加

スキップ

実行時に現在のステージの実行がスキップされ、処理がメッセージ・フローの次のステージに進むように指定します。

JDeveloperでのスキップ・アクションの追加

表17-3 パイプライン - メッセージ処理アクション

アクション

説明

詳細

割当て

コンテキスト変数にXQuery式の結果を割り当てます。

JDeveloperでの割当てアクションの追加

削除

XPath式で指定されたコンテキスト変数または一連のノードを削除します。

JDeveloperでの削除アクションの追加

挿入

XPath式で選択したノードを基準として特定された場所にXQuery式の結果を挿入します。

JDeveloperでの挿入アクションの追加

Javaコールアウト

パイプラインからJavaメソッドを呼び出します。

JDeveloperでのJavaコールアウト・アクションの追加

JavaScript

JavaScript式を使用するXMLまたはJSONペイロードのコンテンツを操作します。

JDeveloperでのJavaScriptアクションの追加

MFL変換

パイプラインで非XMLからXML、またはXMLから非XMLに変換します。

JDeveloperでのMFL変換アクションの追加

nXSD変換

パイプラインで、ネイティブ・データ・フォーマット(nXSD)からXMLに、またはXMLからネイティブ・データ・フォーマット(nXSD)に変換します。

JDeveloperでのnXSD変換アクションの追加

名前変更

要素のコンテンツを変更せずに、XPath式で選択した要素の名前を変更します。

JDeveloperでの名前変更アクションの追加

置換

XPath式で指定されたノードまたはノードのコンテンツを置き換えます。

JDeveloperでの置換アクションの追加

検証

XMLスキーマ要素またはWSDLリソースに対して、XPath式で選択した要素を検証します。

JDeveloperでの検証アクションの追加

表17-4 パイプライン - レポート・アクション

アクション

説明

詳細

アラート

パイプラインのメッセージ・コンテキストに基づいて、アラート通知を送信します。

JDeveloperでのアラート・アクションの追加

ログ

ログに記録するメッセージを作成します。

JDeveloperでのログ・アクションの追加

レポート

パイプラインのメッセージ・レポートを有効にします。

JDeveloperでのレポート・アクションの追加

3. 次の手順を使用して、アクションのプロパティを変更します。

a. アクションをクリックし、それを選択します。「プロパティ」ウィンドウに、選択したコンポーネントのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「プロパティ」ウィンドウで、必要に応じてプロパティを変更します。

c. Oracle JDeveloperツールバーで、「保存」をクリックします。

4. アクションを追加したら、表17-5に示すように、さらにステージまたはルート・ノードのアクションを構成できます。

表17-5 ステージ構成の編集タスク

内容

この手順を完了するには...

アクションの削除

パイプライン・エディタでアクションを右クリックします。表示されたコンテキスト・メニューから「削除」を選択します。

アクションを移動する

パイプライン・エディタで、アクション・アイコンをクリックし、マウス・ボタンを押したままそれをドラッグします。アクションをドロップできる有効な場所を示す黄色の円が表示されます。

アクションを黄色の円にドラッグすると、それが、有効なドロップであることを示す緑色に変化します。マウス・ボタンを離すと、アクション項目が緑の円上にドロップされます。

アクションの切取り

パイプライン・エディタでアクションを右クリックします。表示されたコンテキスト・メニューから「切取り」を選択します。

アクションのコピー

パイプライン・エディタでアクションを右クリックします。表示されたコンテキスト・メニューから「コピー」を選択します。

切り取りまたはコピーしたアクションを貼り付ける

パイプライン・エディタで、アクションの貼付け先のコンポーネントを右クリックします。コンテキスト・メニューから「貼付け」を選択します。

アクションのコピーと貼付けは、ステージ全体で可能です。ただし、「割当て」アクション、「置換」アクション、または「挿入」アクションの場合は、次の点に注意してください。

- ソース(コピー)ステージの変数関連およびユーザー定義のすべてのネームスペースは、ターゲット(貼付け)ステージではユーザー定義のネームスペースとして追加されます。

- 重複するネームスペース(ソース・ステージおよびターゲット・ステージ両方で同一のネームスペース)はコピーされません。

- 競合するネームスペース(同じ接頭辞を使用しているがURIの異なるネームスペース宣言)はコピーされます。構成の保存は可能でありますが、ステージBの競合するネームスペース宣言を削除しないかぎり、アクティブ化することはできません。

5. Oracle JDeveloperツールバーで、「保存」をクリックします。

6. パイプライン・エディタで、「コンソールでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

7. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.2 JDeveloperでのパブリッシュ・アクションの追加

静的に指定された、メッセージのターゲット・サービスを指定し、メッセージのパッケージおよびサービスへの送信方法を構成するには、パブリッシュ・アクションを使用します。パブリッシュの動作の詳細は「パイプラインでのトランスフォーメーションの実行」を参照してください。

始める前に

この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでにパイプライン・エディタでパイプラインを編集していることを前提としています。

また、パイプライン・ステージ、ルート・ノードまたはエラー・ハンドラ・ステージをすでに追加していることも前提としています。参照:

- JDeveloperでのパイプラインへのパイプライン・ペア・ノードの追加

- JDeveloperでのパイプラインへのステージの追加

- JDeveloperでのエラー・ハンドラの追加

パイプラインにパブリッシュ・アクションを追加するには:

1. 次の方法の1つを使用して、パブリッシュ・アクションをパイプラインに追加します。

- パイプライン・エディタで、パブリッシュ・アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」を右クリックし、それにパブリッシュ・アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「パブリッシュ」を選択します。

- 「パブリッシュ」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「パブリッシュ」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「通信」セクションの下で「パブリッシュ」アイコンを探します。
エディタ・ウィンドウに「パブリッシュ」コンポーネントをドラッグすると、「パブリッシュ」コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「パブリッシュ」コンポーネントをドラッグすると、その円が緑色に変化し、そこに「パブリッシュ」コンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、パブリッシュ・アクションのプロパティを設定します。

a. 「パブリッシュ」ノードをクリックし、それを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「プロパティ」ウィンドウで、「サービス」の横にある「検索」アイコンをクリックし、メッセージのターゲット・サービスを指定します。

c. サービスの操作がすでに指定されている場合、「操作」リストから選択して、呼び出す操作を指定できます。

d. 「プロパティ」ウィンドウの左側にある「全般」タブをクリックします。

e. 「説明」の下に、アクションの説明を任意で入力します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.3 JDeveloperでのパブリッシュ表アクションの追加

ゼロまたはそれ以上の静的に指定されたサービスにメッセージをパブリッシュするには、パブリッシュ表アクションを使用します。切替え式の条件ロジックを使用して、どのサービスをパブリッシュに使用するか実行時に決定します。パブリッシュの動作の詳細は「パイプラインでのトランスフォーメーションの実行」を参照してください。

パブリッシュ表アクションを追加するには:

1. 次の方法の1つを使用して、パブリッシュ表アクションをパイプラインに追加します。

- パイプライン・エディタで、パブリッシュ・アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」を右クリックし、それにパブリッシュ・アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「パブリッシュ表」を選択します。

- 「パブリッシュ表」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「パブリッシュ」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「通信」セクションの下で「パブリッシュ表」アイコンを探します。
エディタ・ウィンドウに「パブリッシュ表」コンポーネントをドラッグすると、「パブリッシュ表」コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「パブリッシュ表」コンポーネントをドラッグすると、その円が緑色に変化し、そこに「パブリッシュ表」コンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、パブリッシュ表アクションのプロパティを設定します。

a. パイプライン・エディタで、「パブリッシュ表」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「プロパティ」ウィンドウで、「値」の横にある「fx」アイコンをクリックし、XQuery式を指定します。実行時にXQuery式によってルーティングの決定の基になる値が返されます。

c. 「説明」の下に、パブリッシュ表アクションの説明を任意で入力します。

3. 「パブリッシュ表」ノードで「Case」構文をクリックし、それを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

4. 「プロパティ」ウィンドウで、演算子を選択し、「値」フィールドでXQuery式の値を選択します。

5. 「Case」に対応するパブリッシュ・アクションを構成します。パブリッシュ・アクションの構成の詳細は、「JDeveloperでのパブリッシュ・アクションの追加」を参照してください。

6. 必要に応じて、「Caseの追加」アイコンをクリックして、さらにCaseを追加します。追加したCaseごとに手順3から5を繰り返します。

7. 「デフォルト」Caseに対応するパブリッシュ・アクションを構成します。パブリッシュ・アクションの構成の詳細は、「JDeveloperでのパブリッシュ・アクションの追加」を参照してください。

8. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.4 JDeveloperでの動的パブリッシュ・アクションの追加

XQuery式によって指定されたサービスに対してメッセージをパブリッシュするには、動的パブリッシュ・アクションを使用します。パブリッシュの動作の詳細は「パイプラインでのトランスフォーメーションの実行」を参照してください。

動的パブリッシュ・アクションを追加するには:

1. 次の方法の1つを使用して、動的パブリッシュ・アクションをパイプラインに追加します。

- パイプライン・エディタで、動的パブリッシュ・アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」を右クリックし、それに動的パブリッシュ・アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「動的にパブリッシュ」を選択します。

- 「動的にパブリッシュ」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「動的にパブリッシュ」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「通信」セクションの下で「パブリッシュ」アイコンを探します。
エディタ・ウィンドウに「動的にパブリッシュ」コンポーネントをドラッグすると、「動的にパブリッシュ」コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「動的にパブリッシュ」コンポーネントをドラッグすると、その円が緑色に変化し、そこに「動的にパブリッシュ」コンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、動的パブリッシュ・アクションのプロパティを設定します。

a. パイプライン・エディタで、「動的にパブリッシュ」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「プロパティ」ウィンドウで、「サービス」の横にある「fx」アイコンをクリックし、XQuery式を指定します。完了すると、XQuery式は次のような結果を提供します。

<ctx:route>
<ctx:service isProxy="false">project/folder/businessservicename</ctx:service>
<ctx:operation>foo</ctx:operation>
</ctx:route>

注意:

プロキシ・サービスが呼び出されている場合は、isProxyをtrueに設定します。ビジネス・サービスが呼び出されている場合は、isProxyをfalseに設定します。

operation要素は省略可能です。

c. 「プロパティ」ウィンドウの左側にある「全般」タブをクリックします。

d. 「説明」の下に、動的パブリッシュ・アクションの説明を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.5 JDeveloperでのルーティング・オプション・アクションの追加

$outboundのアウトバウンド・リクエストのURI、サービスの品質、モード、および再試行パラメータの一部またはすべてを変更するには、ルーティング・オプション・アクションを使用します。これらのプロパティは、$outbound上の割り当て、挿入、置換、または削除アクションで変更できますが、ルーティング・オプションを使用すると、XPath、XQuery、または$outboundコンテキスト変数の構造を理解していなくてもこのタスクを実行できます。

ルーティング・オプションのアクションはコンテキスト変数$outboundが有効な場合にのみ使用できます。次のアクションに追加できます。

- パブリッシュ

- 動的にパブリッシュ

- パブリッシュ表

- サービス・コールアウト

- ルーティング

- 動的ルーティング

- ルーティング表

ルーティングの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。

ルーティング・オプション・アクションを追加するには:

1. 次の方法の1つを使用して、ルーティング・オプション・アクションをパイプラインに追加します。

- パイプライン・エディタで、ルーティング・オプション・アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「パブリッシュ」ノードで「リクエスト・アクション」を右クリックし、それにルーティング・オプション・アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「ルーティング・オプション」を選択します。

- 「ルーティング・オプション」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「ルーティング・オプション」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「通信」セクションの下で「ルーティング・オプション」アイコンを探します。
エディタ・ウィンドウに「ルーティング・オプション」コンポーネントをドラッグすると、「ルーティング・オプション」コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「ルーティング・オプション」コンポーネントをドラッグすると、その円が緑色に変化し、そこに「ルーティング・オプション」コンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、ルーティング・オプション・アクションのプロパティを設定します。

a. パイプライン・エディタで、「ルーティング・オプション」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「プロパティ」ウィンドウで、次のいずれかまたはすべてを設定します。
URI: 「fx」アイコンをクリックし、XQuery式ビルダーを起動します。URIを返す式を入力します。これで呼び出されたサービスのURIがオーバーライドされます。

QoS: リストから「サービス品質」オプションを選択します。これで、自動計算されたデフォルトがオーバーライドされます。

モード: 「一方向」または「リクエスト-レスポンス」を選択します。

再試行間隔: 再試行間隔を秒数で指定します。これで呼び出されたサービスで構成されたデフォルトがオーバーライドされます。

再試行回数: アクションを中断するまで再試行を行う回数を指定します。これで呼び出されたサービスで構成されたデフォルトがオーバーライドされます。

優先度: 「fx」アイコンをクリックし、XQuery式ビルダーを起動します。正の整数を返す式を入力します。

「説明」: 動的パブリッシュ・アクションの説明を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.6 JDeveloperでのサービス・コールアウト・アクションの追加

Service Busに登録済のプロキシ・サービスまたはビジネス・サービスの同期(ブロッキング)コールアウトを構成するには、サービス・コールアウト・アクションを使用します。

サービス・コールアウト・アクションの詳細は「サービス・コールアウト・メッセージの作成」を参照してください。

サービス・コールアウト・アクションを追加するには:

1. 次の方法の1つを使用して、サービス・コールアウト・アクションをパイプラインに追加します。

- パイプライン・エディタで、サービス・コールアウト・アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それにサービス・コールアウト・アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「サービス・コールアウト」を選択します。

- 「サービス・コールアウト」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「サービス・コールアウト」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「通信」セクションの下で「サービス・コールアウト」アイコンを探します。
エディタ・ウィンドウに「サービス・コールアウト」コンポーネントをドラッグすると、「サービス・コールアウト」コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「サービス・コールアウト」コンポーネントをドラッグすると、その円が緑色に変化し、そこに「サービス・コールアウト」コンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、サービス・コールアウト・アクションのプロパティを設定します。

a. パイプライン・エディタで、「サービス・コールアウト」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「サービス」の横にある「検索」アイコンをクリックし、ビジネス・サービスまたはプロキシ・サービスを指定します。

c. 前述の手順で選択したサービスがWSDLベースのサービスであり、サービスに対して呼び出せる操作がある場合、「操作」フィールドから操作を選択します。

d. 「構成」の下で、次のオプションの1つを選択して、リクエスト・メッセージとレスポンス・メッセージの構成方法を指定します。
「本体の構成」を選択して、SOAP本体を構成します。このオプションを選択すると、$bodyを直接使用できます。

「ペイロード・ドキュメントの構成」を選択して、ペイロードを構成します。

e. 選択したサービスの種類およびそのサービスに対して選択した構成オプションの種類に応じて、表示されるリクエストおよびレスポンスの変数の値を選択します。

f. サービス・コールアウト・アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.7 JDeveloperでのトランスポート・ヘッダー・アクションの追加

メッセージのヘッダーの値を設定するには、トランスポート・ヘッダー・アクションを使用します。

トランスポート・ヘッダー・アクションを追加するには:

1. 次の方法の1つを使用して、トランスポート・ヘッダー・アクションをパイプラインに追加します。

- パイプライン・エディタで、トランスポート・ヘッダー・アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノード・アイコンを右クリックし、それにトランスポート・ヘッダー・アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「トランスポート・ヘッダー」を選択します。

- 「トランスポート・ヘッダー」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「トランスポート・ヘッダー」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「通信」セクションの下で「トランスポート・ヘッダー」アイコンを探します。
エディタ・ウィンドウに「トランスポート・ヘッダー」コンポーネントをドラッグすると、「トランスポート・ヘッダー」コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「トランスポート・ヘッダー」コンポーネントをドラッグすると、その円が緑色に変化し、そこに「トランスポート・ヘッダー」コンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、「トランスポート・ヘッダー」アクションのプロパティを設定します。

a. パイプライン・エディタで、「トランスポート・ヘッダー」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「方向」リストについては、次のうちの1つを選択します。
アウトバウンド・リクエスト: アウトバウンド・リクエスト(ルート、パブリッシュまたはサービス・コールアウト・アクションでパイプラインによって送信されるメッセージ)のヘッダーの値を設定するには、このオプションを選択します。これらのヘッダー要素は、メッセージ・コンテキストの次の場所にあります。

$outbound/ctx:transport/ctx:request/tp:headers

「インバウンド・レスポンス」: インバウンド・レスポンス(プロキシ・サービスがクライアントに返信するレスポンス・メッセージ)のヘッダーの値を設定するには、このオプションを選択します。これらのヘッダー要素は、メッセージ・コンテキストの次の場所にあります。

$inbound/ctx:transport/ctx:response/tp:headers

c. 必要に応じて、「ヘッダーのコピー」を選択し、インバウンド・メッセージからアウトバウンド・メッセージおよびその逆にヘッダーをコピーします。

d. 「ヘッダー」の下で、「プロトコル」を選択し、緑色のプラス(+)記号で識別される「ヘッダーの追加」アイコンをクリックして、ヘッダーを追加します。「アクション」を選択し、ヘッダーの「名前」および必要な値があれば「値」を指定します。
「設定」アクションでは、XQuery式またはXSLT式を使用して、ヘッダーの値を設定できます。アウトバウンド・リクエストの値を設定する場合、「コピー」アクションは、インバウンド・リクエストからヘッダー値をコピーします。インバウンド・レスポンスの値を設定する場合、「コピー」アクションは、アウトバウンド・レスポンスからヘッダー値をコピーします。「削除」 アクションでは、リクエストまたはレスポンス・メタデータからヘッダーが削除されます。

e. 前述の手順を繰り返して、さらにヘッダーを追加します。

f. ヘッダーを削除するには、行を選択し、赤いX記号が付いた「ヘッダーの削除」アイコンをクリックします。

g. トランスポート・コールアウト・アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.8 JDeveloperでのルート・ノードへの動的ルーティングの追加

XQueryリソースで使用できるルーティング情報に基づいて、メッセージ・ルートを割り当てます。これは終端アクションなので、このアクションの後に別のアクションを追加することはできません。ただし、このアクションには、リクエストとレスポンスのアクションを含めることができます。ルーティングの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。

ルート・ノードに動的ルーティングを追加するには:

1. 次の方法の1つを使用して、動的ルーティング・アクションをパイプラインに追加します。

- パイプライン・エディタで、動的ルーティング・アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ルート」ノード・アイコンを右クリックし、それに動的ルーティング・アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「動的ルーティング」を選択します。

- 「動的ルーティング」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「動的ルーティング」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「ルート」セクションの下で「動的ルーティング」アイコンを探します。
エディタ・ウィンドウに「動的ルーティング」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「動的ルーティング」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、「動的ルーティング」アクションのプロパティを設定します。

a. パイプライン・エディタで、「動的ルーティング」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「サービス」の下にある「fx」アイコンをクリックし、XQuery式を指定します。XQuery式の結果は、次に似たものになります。

<ctx:route>
<ctx:service isProxy='true'>{$service}</ctx:service>
<ctx:operation>{$operation}</ctx:operation>
</ctx:route>

注意:

プロキシ・サービスが呼び出されている場合は、isProxyをtrueに設定します。ビジネス・サービスが呼び出されている場合は、isProxyをfalseに設定します。

- サービス名は完全修飾サービス名です。

- 操作要素はオプションです。

c. 動的ルーティング・アクションの「説明」を任意で指定します。

d. 引き続き、アクションを「リクエスト・アクション」および「レスポンス・アクション」ブランチに追加します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.9 JDeveloperでのルート・ノードへのルーティング・アクションの追加

そのメッセージのターゲット・サービスを指定し、サービスへのメッセージのルーティング方法を構成します。これは終端アクションなので、このアクションの後に別のアクションを追加することはできません。ただし、このアクションには、リクエストとレスポンスのアクションを含めることができます。ルーティングの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。

ルート・ノードにルーティング・アクションを追加するには:

1. 次の方法の1つを使用して、ルーティング・アクションをパイプラインに追加します。

- パイプライン・エディタで、ルーティング・アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ルート」ノード・アイコンを右クリックし、それにルーティング・アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「ルーティング」を選択します。

- 「ルーティング」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「ルーティング」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「ルート」セクションの下で「ルーティング」アイコンを探します。
エディタ・ウィンドウに「ルーティング」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「ルーティング」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、「ルーティング」アクションのプロパティを設定します。

a. パイプライン・エディタで、「ルーティング」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「サービス」フィールドの右にある「検索」アイコンをクリックし、サービスを指定します。「リソース・チューザ」ダイアログが表示されます。

c. リソースからサービスを選択し、「OK」をクリックします。

d. WSDLベースのサービスを選択した場合、そのサービスに対応する「操作」を選択します。

e. ルーティング・アクションの「説明」を任意で指定します。

f. 引き続き、アクションを「リクエスト・アクション」および「レスポンス・アクション」ブランチに追加します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.10 JDeveloperでのルート・ノードへのルーティング表の追加

ルーティング表は、切替え式の条件表にラップされた一連のルートです。これは、単一のXQuery式の結果に基づいて各種ルートを選択できる短縮形の構文です。ステージ・エディタで複数のレベルをネストできます。メッセージのターゲット・サービスを指定し、ターゲット・サービスへのメッセージのルーティング方法を構成します。

これは終端アクションなので、このアクションの後に別のアクションを追加することはできません。ただし、このアクションには、リクエストとレスポンスのアクションを含めることができます。ルーティングの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。

ルート・ノードにルーティング表を追加するには:

1. 次の方法の1つを使用して、ルーティング表アクションをパイプラインに追加します。

- パイプライン・エディタで、ルーティング表アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ルート」ノードを右クリックし、それにルーティング表アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「ルーティング表」を選択します。

- 「ルーティング表」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「ルーティング表」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「ルート」セクションの下で「ルーティング表」アイコンを探します。
エディタ・ウィンドウに「ルーティング表」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「ルーティング表」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、ルーティング表アクションのプロパティを設定します。

a. パイプライン・エディタで、「ルーティング表」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「プロパティ」ウィンドウで、「値」の横にある「fx」アイコンをクリックし、XQuery式を指定します。実行時にXQuery式によってルーティングの決定の基になる値が返されます。

c. 「説明」の下に、ルーティング表アクションの説明を任意で指定します。

3. 「ルーティング表」ノードで「Case」構成をクリックし、それを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

4. 「プロパティ」ウィンドウで、演算子を選択し、「値」フィールドでXQuery式の値を選択します。

5. 「Case」に対応するルーティング・アクションを構成します。ルーティング・アクションの構成の詳細は、「JDeveloperでのルート・ノードへのルーティング・アクションの追加」を参照してください。

6. 必要に応じて、「Caseの追加」アイコンをクリックして、さらにCaseを追加します。追加したCaseごとに手順3から5を繰り返します。

7. 「デフォルト」Caseに対応するルーティング・アクションを構成します。ルーティング・アクションの構成の詳細は、「JDeveloperでのルート・ノードへのルーティング・アクションの追加」を参照してください。

8. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.11 JDeveloperでのFor Eachアクションの追加

一連の値を反復処理してアクションのブロックを実行するには、For Eachアクションを使用します。

For Eachアクションを追加するには:

1. 次の方法の1つを使用して、For Eachアクションをパイプラインに追加します。

- パイプライン・エディタで、ルーティング表アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それにFor Eachアクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「For Each」を選択します。

- 「For Each」コンポーネントを「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「For Each」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「フロー制御」セクションの下で「For Each」アイコンを探します。
エディタ・ウィンドウに「For Each」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「For Each」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、ルーティング表アクションのプロパティを設定します。

a. パイプライン・エディタで、「For Each」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「For Each値」の値を入力します。「fx」をクリックしてXPath式を指定します。

c. 「値変数」、「索引変数」および「カウント変数」に値を入力します。

d. 「説明」の下に、For Eachアクションの説明を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.12 JDeveloperでのIf Thenアクションの追加

XQuery式のブール結果に基づき、1つまたは複数のアクションを条件付きで実行するには、If Thenアクションを使用します。

If Thenアクションを追加するには:

1. 次の方法の1つを使用して、If Thenアクションをパイプラインに追加します。

- パイプライン・エディタで、If Thenアクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それにIf Thenアクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「If Then」を選択します。

- 「If Then」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「If Then」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「フロー制御」セクションの下で「If Then」アイコンを探します。
エディタ・ウィンドウに「If Then」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「If Then」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、If Thenアクションのプロパティを設定します。

a. パイプライン・エディタで、「If Then」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. If Thenアクションの「説明」を任意で指定します。

3. 「If Then」ノードのIf: <condition>ブランチをクリックして選択します。

4. 「プロパティ」ウィンドウで、「fx」をクリックし、If条件の式を指定します。

5. 「コンポーネント」ウィンドウからブランチに、trueを返す条件に対応するアクションをドラッグします。

6. 必要に応じて、「If Then」ノードの「条件の追加」アイコンをクリックすることでIf条件を追加します。

7. 追加した条件ごとに手順3から5を繰り返します。

8. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.13 JDeveloperでのエラーの生成アクションの追加

指定したエラー・コード(文字列)と説明を使用して例外を発生させるには、エラーを発生させるアクションを使用します。

エラーの発生アクションを追加するには:

1. 次の方法の1つを使用して、エラーの生成アクションをパイプラインに追加します。

- パイプライン・エディタで、エラーの生成アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それにエラーの生成アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「エラーの生成」を選択します。

- 「エラーの生成」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「エラーの生成」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「フロー制御」セクションの下で「エラーの生成」アイコンを探します。
エディタ・ウィンドウに「エラーの生成」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「エラーの生成」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、エラーの生成アクションのプロパティを設定します。

a. パイプライン・エディタで、「エラーの生成」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「プロパティ」ウィンドウで、生成するエラーの「コード」を入力します。

c. 「メッセージ」フィールドにエラー・コードの説明を入力します。

d. エラーの生成アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.14 JDeveloperでの返信アクションの追加

呼出し元に即時に返信されるように指定するには、返信アクションを使用します。返信アクションは、リクエスト・パイプライン、レスポンス・パイプライン、またはエラー・パイプラインで使用できます。成功時または失敗時に返信するように構成できます。HTTPインバウンド・トランスポートでの失敗時の返信の場合、返信アクションでは、呼出し元に即時に返信されるように指定します。

返信アクションを追加するには:

1. 次の方法の1つを使用して、返信アクションをパイプラインに追加します。

- パイプライン・エディタで、返信アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それに返信アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「返信」を選択します。

- 「返信」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「返信」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「フロー制御」セクションの下で「返信」アイコンを探します。
エディタ・ウィンドウに「返信」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「返信」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、返信アクションのプロパティを設定します。

a. パイプライン・エディタで、「返信」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. メッセージが成功したことを返信するには、「オプション」の下で「成功時」を選択します。また、メッセージが失敗したことを返信するには、「失敗時」を選択します。

c. 返信アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.15 JDeveloperでの再開アクションの追加

エラー・ハンドラによってエラーが処理された後で、メッセージ・フローを再開するには、再開アクションを使用します。このアクションにパラメータはありません。このアクションはエラー・パイプラインでのみ使用できます。

再開アクションを追加するには:

1. 次の方法の1つを使用して、再開アクションをパイプラインに追加します。

- パイプライン・エディタで、再開アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、エラー・ハンドラで「ステージ」ノードを右クリックし、それに再開アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「再開」を選択します。

- 「再開」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「再開」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「フロー制御」セクションの下で「再開」アイコンを探します。
エディタ・ウィンドウに「再開」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「再開」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、返信アクションのプロパティを設定します。

a. パイプライン・エディタで、「再開」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 再開アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.16 JDeveloperでのスキップ・アクションの追加

実行時にこのステージの実行がスキップされて、処理がメッセージ・フローの次のステージに進むように指定するには、スキップ・アクションを使用します。このアクションにはパラメータがなく、リクエスト・パイプライン、レスポンス・パイプライン、エラー・パイプラインで使用できます。

スキップ・アクションを追加するには:

1. 次の方法の1つを使用して、スキップ・アクションをパイプラインに追加します。

- パイプライン・エディタで、スキップ・アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それにスキップ・アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「スキップ」を選択します。

- 「スキップ」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「スキップ」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「フロー制御」セクションの下で「スキップ」アイコンを探します。
エディタ・ウィンドウに「スキップ」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「スキップ」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、スキップ・アクションのプロパティを設定します。

a. パイプライン・エディタで、「スキップ」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. スキップ・アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.17 JDeveloperでの割当てアクションの追加

XQuery式の結果をコンテキスト変数に割り当てるには、割当てアクションを使用します。

割当てアクションを追加するには:

1. 次の方法の1つを使用して、割当てアクションをパイプラインに追加します。

- パイプライン・エディタで、割当てアクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それに割当てアクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「割当て」を選択します。

- 「割当て」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「割当て」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「メッセージ処理」セクションの下で「割当て」アイコンを探します。
エディタ・ウィンドウに「割当て」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「割当て」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、割当てアクションのプロパティを設定します。

a. パイプライン・エディタで、「割当て」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「値」フィールドの右にある「fx」 アイコンをクリックし、XQuery式を指定します。XQuery式は、指定の変数に割り当てる値を指定します。

c. 「変数」フィールドにコンテキスト変数を入力します。

d. 割当てアクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.18 JDeveloperでの削除アクションの追加

削除アクションは、コンテキスト変数またはXPath式で指定したすべてのノードを削除するときに使用します。削除アクションは一連の更新アクションの1つです。

削除アクションを追加するには:

1. 次の方法の1つを使用して、削除アクションをパイプラインに追加します。

- パイプライン・エディタで、削除アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それに削除アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「削除」を選択します。

- 「削除」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「削除」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「メッセージ処理」セクションの下で「削除」アイコンを探します。
エディタ・ウィンドウに「削除」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「削除」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、削除アクションのプロパティを設定します。

a. パイプライン・エディタで、「削除」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「場所」の下で、コンテキスト変数を指定します。

c. 「fx」アイコンをクリックしてXPath式を指定します。XPath式によって選択されるノードがすべて削除されます。

d. 「全般」セクションの下で、削除アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.19 JDeveloperでの挿入アクションの追加

XPath式で選択したノードを基準に、指定した位置にXQuery式を挿入するには、挿入アクションを使用します。挿入アクションは更新アクションの1つです。

挿入アクションを追加するには:

1. 次の方法の1つを使用して、挿入アクションをパイプラインに追加します。

- パイプライン・エディタで、挿入アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それに挿入アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「挿入」を選択します。

- 「挿入」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「挿入」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「メッセージ処理」セクションの下で「挿入」アイコンを探します。
エディタ・ウィンドウに「挿入」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「挿入」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、挿入アクションのプロパティを設定します。

a. パイプライン・エディタで、「挿入」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「値」フィールドの右にある「fx」 アイコンをクリックし、XQuery式を指定します。XQuery式を使用して、指定の変数で指定した場所に挿入されるデータを作成します。

c. 「位置」の下で、リストから関連場所を選択します。相対的な位置は、XPath式の結果を基準として挿入位置を決める場合に使用します。次の中から選択します。
の前に: XPath式で選択される各要素や属性の兄とします。

の後ろに: XPath式で選択される各要素や属性の弟とします。

の最初の子として: XPath式で指定される各要素の第1の子とします。XPathの結果が属性を返す場合はエラーが発生します。

の最後の子として: XPath式で指定される各要素の最後の子とします。XPathが属性を返す場合はエラーが発生します。

d. 「場所」の下で、コンテキスト変数を指定します。XPathは、この変数の内容を評価します。

e. 「fx」アイコンをクリックしてXPath式を指定します。有効な構成には、次の構成が含まれます。
- XQuery式とXPath式の両方が要素を返します。

- XQuery式とXPath式の両方が属性を返します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.20 JDeveloperでのJavaコールアウト・アクションの追加

パイプラインからJavaメソッドまたはEJBビジネス・サービスを呼び出すには、Javaコールアウト・アクションを使用します。

Javaコールアウト・アクションを追加するには:

1. 次の方法の1つを使用して、Javaコールアウト・アクションをパイプラインに追加します。

- パイプライン・エディタで、Javaコールアウト・アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それにJavaコールアウト・アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「Javaコールアウト」を選択します。

- 「Javaコールアウト」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「Javaコールアウト」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「メッセージ処理」セクションの下で「Javaコールアウト」アイコンを探します。
エディタ・ウィンドウに「Javaコールアウト」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「Javaコールアウト」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、Javaコールアウト・アクションのプロパティを設定します。

a. パイプライン・エディタで、「Javaコールアウト」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「メソッド」フィールドの右にある「検索」アイコンをクリックし、Javaアーカイブ(JAR)を指定します。選択したJARファイルに対応するJavaクラスおよびメソッドを選択します。メソッドは静的メソッドである必要があります。
「引数」セクションには、メソッドの引数が移入されます。XQuery式は、各引数に対して指定する必要があります。

c. 引数の「値」列の下にある「fx」アイコンをクリックし、それのXQuery式を指定します。
入力値の型が宣言されている入力引数の型と一致しない場合、Service Busは入力値を入力引数の宣言された型に自動的に型キャストします。たとえば、入力引数の宣言された型がJavaプリミティブ「int」の場合、文字列値"123"は整数123に変換されます。

d. 選択したメソッドの引数ごとに前述の手順を繰り返します。

e. 「戻り」セクションの下で、結果を割り当てる「変数」を指定します。

f. 必要に応じて、「参照として」を選択し、参照として結果を返します。このオプションにより、jcidがパイプライン・オブジェクト・リポジトリのオブジェクトへのキーである実際のタイプに関係なく、Javaコールアウトの呼出しの戻り値が<java-content ref="jcid">参照要素になります。

g. 選択したJavaメソッドのセキュリティ・コンテキストがある場合、必要に応じて、「サービス・アカウント」の右にある「検索」アイコンをクリックし、サービス・アカウントを指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.21 JDeveloperでのJavaScriptアクションの追加

JavaScriptアクションを使用して、JavaScript式を使用するXMLまたはJSONペイロードのコンテンツを操作します。

JavaScriptアクションを追加するには:

1. 次の方法の1つを使用して、Javaコールアウト・アクションをパイプラインに追加します。

- パイプライン・エディタで、JavaScriptアクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それにJavaScriptアクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「JavaScript」を選択します。

- 「JavaScript」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「JavaScript」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「メッセージ処理」セクションの下で「JavaScript」アイコンを探します。
エディタ・ウィンドウに「JavaScript」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「JavaScript」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. パイプライン・エディタで、「JavaScript」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

3. 次のいずれかの方法で、アクションに使用されるJavaScript式を設定します。

a. JavaScript式を構築するには、「値」フィールドからfxアイコンをクリックしてJavaScript式ビルダーを起動します。

b. JavaScript式を含むJavaScriptリソースを選択するには、「値」フィールドからfxアイコンの隣の矢印をクリックして「JavaScriptリソース」を選択します。「JavaScriptリソース・ビルダー」ダイアログから、「検索」アイコンをクリックします。「JavaScriptの選択」ウィンドウを使用して、使用するJavaScriptリソースに移動して選択し、「OK」をクリックします。「OK」を再度クリックして、「JavaScript式ビルダー」ダイアログを閉じます。

4. (オプション)タイムアウト値(秒)を「タイムアウト」フィールドに入力します。処理が完了する前にこのタイムアウトのしきい値に達した場合は、エラーが返され、JavaScript処理が終了します。

注意:

このフィールドの値は、Oracle Enterprise Managerで構成されているサーバー用のデフォルトのJavaScriptタイムアウトをオーバーライドします。

5. JDeveloperツールバーで、「保存」をクリックします。

17.22 JDeveloperでのMFL変換アクションの追加

MFL (Message Format Language)変換アクションを使用して、メッセージ・パイプライン内でメッセージ・コンテンツをXMLとXML以外の形式との間で変換します。MFLは、バイナリ・データのレイアウトを記述するために使用する特別なXMLドキュメントです。Oracle独自の言語を使用して、フォーマットされたバイナリ・データをXMLデータに、またはXMLデータをバイナリ・データに変換するルールを定義します。「Message Format Languageを使用したデータ構造の定義」を参照してください。

MFL変換アクションを追加するには:

1. 次の方法の1つを使用して、MFL変換アクションをパイプラインに追加します。

- パイプライン・エディタで、MFL変換アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それにMFL変換アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「MFL変換」を選択します。

- 「MFL変換」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「MFL変換」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「メッセージ処理」セクションの下で「MFL変換」アイコンを探します。
エディタ・ウィンドウに「MFL変換」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「MFL変換」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、MFL変換アクションのプロパティを設定します。

a. パイプライン・エディタで、「MFL変換」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「変換」の下で、XMLからネイティブに変換するのか、その逆に変換するのかを選択します。

c. 「入力」フィールドの右にある「fx」アイコンをクリックし、XQuery式を使用して入力変数を指定します。
この入力は、XMLへの変換の場合はテキストまたはバイナリ、XML以外への変換の場合はXMLである必要があります。メッセージ・コンテキストのバイナリ・コンテンツは、バイナリ・コンテンツXML要素によって表されます。入力がバイナリでなければならない場合、このXMLはXQuery式の結果となります。

d. 「MFL」の下で「静的」を選択し、静的MFLリソースを指定します。または、「動的」を選択して、動的MFLリソースを選択します。

e. 前述の手順で「静的」を選択した場合は、「検索」アイコンをクリックし、MFL変換を実行するMFLリソースを選択します。
前述の手順で「動的」を選択した場合は、「fx」アイコンをクリックし、変換を実行するMFLリソースを動的に選択するXQuery式を指定します。

f. 変換の結果を割り当てる「出力」変数を指定します。

g. MFL変換アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.23 JDeveloperでのnXSD変換アクションの追加

nXSD変換アクションを使用して、メッセージ・パイプライン内でメッセージ・コンテンツをXMLとネイティブ・フォーマット・データとの間で変換します。変換に使用するネイティブ・スキーマの作成の詳細は、テクノロジ・アダプタの理解のネイティブ・フォーマット・ビルダー・ウィザードに関する項を参照してください。

次の例に示すとおり、関連付けられているXSDリソースに関連する注釈がある場合、nXSD変換アクションでは、XMLからJSON、およびJSONからXMLの変換をサポートしています。

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://example.com/RestService_Operation1_request"
targetNamespace="http://example.com/RestService_Operation1_request" elementFormDefault="qualified"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" nxsd:version="JSON" nxsd:encoding="US-ASCII">
<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="country" type="xsd:string"/>
<xsd:element name="circuit" type="xsd:string"/>
<xsd:element name="date" type="xsd:date"/>
…

nXSD変換アクションはこのバージョンのService Busで拡張されており、JSONからXMLへの変換時にスキーマの順序が適用されます。

nXSD変換アクションを追加するには:

1. 次の方法の1つを使用して、nXSD変換アクションをパイプラインに追加します。

- パイプライン・エディタで、nXSD変換アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それにnXSD変換アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「nXSD変換」を選択します。

- 「nXSD変換」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「nXSD変換」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「メッセージ処理」セクションの下で「nXSD変換」アイコンを探します。
エディタ・ウィンドウに「nXSD変換」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「nXSD変換」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、nXSD変換アクションのプロパティを設定します。

a. パイプライン・エディタで、「nXSD変換」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「変換」の下で、XMLからネイティブに変換するのか、その逆に変換するのかを選択します。

c. 「入力」フィールドの右にある「fx」アイコンをクリックし、XQuery式を使用して入力変数を指定します。
この入力は、XMLへの変換の場合はネイティブ・フォーマット、ネイティブ・データ・フォーマットへの変換の場合はXMLである必要があります。

d. 「nXSDスキーマ」の下で、「静的」を選択し、静的XMLスキーマ(.xsd)を指定します。または、「動的」を選択し、動的にスキーマを指定します。

e. 前述の手順で「静的」を選択した場合は、「検索」アイコンをクリックし、ネイティブ・スキーマに対応するスキーマ(.xsd)ファイルを選択します。
前述の手順で「動的」を選択した場合は、「fx」アイコンをクリックし、ネイティブ・スキーマを動的に選択するXQuery式を指定します。

f. 変換の結果を割り当てる「出力」変数を指定します。または、出力として「$bodyの内容」を選択することもできます。

g. (オプション) ネイティブ形式(JSONなど)からXMLに変換する場合は、「スキーマ順序の適用」オプションを選択します。選択すると、XMLスキーマの要素の順序付けと一致するようにJSONペイロードを並べ替えます。

h. nXSD変換アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.24 JDeveloperでの名前変更アクションの追加

XPath式で選択された要素のコンテンツを変更せずに要素名を変更するには、名前変更アクションを使用します。名前変更アクションは更新アクションの1つです。

名前変更アクションを追加するには:

1. 次の方法の1つを使用して、名前変更アクションをパイプラインに追加します。

- パイプライン・エディタで、名前変更アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それに名前変更アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「名前変更」を選択します。

- 「名前変更」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「名前変更」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「メッセージ処理」セクションの下で「名前変更」アイコンを探します。
エディタ・ウィンドウに「名前変更」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「名前変更」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、名前変更アクションのプロパティを設定します。

a. パイプライン・エディタで、「名前変更」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「場所」の下で、名前を変更する要素を保持するコンテキスト変数を指定します。

c. 「fx」アイコンをクリックし、指定の変数内の名前を変更するデータの指定に使用するXPath式を指定します。

d. 名前を変更される要素の「ローカル名」および「ネームスペース」を入力します。これらの属性のうち少なくとも1つが必要です。

e. 「全般」セクションの下で、名前変更アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.25 JDeveloperでの置換アクションの追加

XPath式で指定されたノードまたはノードのコンテンツを置き換えるには、置換アクションを使用します。ノードまたはそのコンテンツは、XQuery式が返した値で置換されます。置換アクションでは、単純な値、要素、属性を置き換えることができます。XQuery式から何も返されない状態は、アクションがノード全体を置き換えるか、ノードコンテンツのみを置き換えるかにより、識別されたノードを削除すること、または空のノードを作成することと同じです。置換アクションは更新アクションのセットの内の1つです。

置換アクションを追加するには:

1. 次の方法の1つを使用して、置換アクションをパイプラインに追加します。

- パイプライン・エディタで、置換アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それに置換アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「置換」を選択します。

- 「置換」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「置換」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「メッセージ処理」セクションの下で「置換」アイコンを探します。
エディタ・ウィンドウに「置換」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「置換」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、置換アクションのプロパティを設定します。

a. パイプライン・エディタで、「置換」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「場所」の下で、置換する要素を保持するコンテキスト変数を指定します。

c. 「fx」アイコンをクリックし、指定の変数内の置換するデータの指定に使用するXPath式を指定します。

d. 「値」フィールドの右にある「fx」 アイコンをクリックし、XQuery式を指定します。XQuery式は、名前付き変数内でXPathによって指定されたデータを置換するデータの作成に使用されます。

e. 「置換」の下で、次のオプションの1つを選択します。
ノード全体を置換: XPath式によって選択されたノードとそのすべてのコンテンツが置換されます。

ノードのコンテンツを置換: ノードは置換されず、ノード・コンテンツのみが置換されます。

注意:

「ノード全体を置換」オプションを選択してXPathを./*に設定するよりも、「ノードのコンテンツを置換」オプションを選択して「XPath」を空白にする方が効率的です。

f. 「全般」セクションの下で、名前変更アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.26 JDeveloperでの検証アクションの追加

XMLスキーマ要素またはWSDLリソースに対して、XPath式で選択した要素を検証するには、検証アクションを使用します。検証できるのは、グローバル要素のみです。Service Busはローカル要素に対する検証に対応していません。実行時にXQuery式の結果に基づいて、XMLスキーマ要素またはWSDLリソースを動的に選択することも選択できます。

検証アクションを追加するには:

1. 次の方法の1つを使用して、検証アクションをパイプラインに追加します。

- パイプライン・エディタで、検証アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それに検証アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「検証」を選択します。

- 「検証」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「検証」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「メッセージ処理」セクションの下で「検証」アイコンを探します。
エディタ・ウィンドウに「検証」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「検証」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、検証アクションのプロパティを設定します。

a. パイプライン・エディタで、「検証」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「場所」の下で、検証する要素を保持するコンテキスト変数を指定します。

c. 「fx」アイコンをクリックし、指定の変数内の検証するデータの指定に使用するXPath式を指定します。

d. 「スキーマ」の下で、「静的」をクリックし、検証するスキーマまたはWSDLファイルを選択します。または、「動的」を選択し、スキーマまたはWSDLファイルを実行時に動的に指定します。

e. 前述の手順で「静的」を選択した場合は、「検索」アイコンをクリックし、XMLスキーマ(.xsd)またはWSDLファイルに含まれている要素を指定します。
前述の手順で「動的」を選択した場合は、「fx」アイコンをクリックし、XQuery式を指定します。XQuery式によってWSDLまたはスキーマ・リソースが動的に指定されます。

次のものは、WSDLリソースの動的な指定の例です。

<validate xmlns="http://www.bea.com/wli/sb/context">
<wsdl>default/MyWSDL</wsdl>
<schemaType>
<namespaceURI>http://openuri.org</namespaceURI>
<localname>MyType</localname>
</schemaType>
</validate>

次のものは、スキーマ・リソースの動的な指定の例です。

<validate xmlns="http://www.bea.com/wli/sb/context">
<schema>default/MySchema</schema>
<schemaElement>
<localname>MyElementType</localname>
</schemaElement>
</validate>

f. 「アクション」の下で、「変数の保存」を選択し、検証結果を保持する変数を指定します。また、WSDLやXMLスキーマ要素に照らした要素の検証が失敗したときにエラーを発生させる場合は、「エラーの生成」を選択します。

g. 「全般」セクションの下で、検証アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.27 JDeveloperでのアラート・アクションの追加

アラート宛先にアラートを送信するには、アラート・アクションを使用して、パイプラインのメッセージ・コンテキストに基づいてアラートを生成します。SLAアラートと異なり、アラート・アクションで生成された通知は、主にビジネスでの使用、またはエラーの報告を目的とし、システムの状態を監視するものではありません。このことを考慮して、アラートの宛先を構成および選択する必要があります。アラートの宛先の詳細は、「アラート宛先の操作」を参照してください。

サービスに対してパイプライン・アラートが有効になっていない場合や、ドメイン・レベルでパイプライン・アラートが有効になっていない場合は、メッセージの処理中に、構成したアラート・アクションがバイパスされます。

アラート・アクションを追加するには:

1. 次の方法の1つを使用して、アラート・アクションをパイプラインに追加します。

- パイプライン・エディタで、アラート・アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それにアラート・アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「アラート」を選択します。

- 「アラート」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「アラート」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「レポート」セクションの下で「アラート」アイコンを探します。
エディタ・ウィンドウに「アラート」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「アラート」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、アラート・アクションのプロパティを設定します。

a. パイプライン・エディタで、「アラート」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「コンテンツ」フィールドの右にある「fx」 アイコンをクリックし、XQuery式を指定します。XQuery式は、アラート・メッセージに追加されるメッセージ・コンテキストの指定に使用されます。

c. 「サマリー」フィールドにアラートの短い説明を入力します。
説明文は、電子メール通知の場合の件名になり、80文字以内である必要があります。説明文が存在しない場合、「Oracle Service Busアラート」というあらかじめ定義された件名がかわりに使用されます。

d. アラートの「重大度」レベルを選択します。

e. 「宛先」フィールドの右にある「検索」アイコンをクリックし、アラート宛先を選択します。
デフォルトでは、アラートは管理コンソールに出力されます。

f. 「全般」セクションの下で、アラート・アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.28 JDeveloperでのログ・アクションの追加

ログに記録するメッセージを作成し、ログに使用する一連の属性を定義するには、ログ・アクションを使用します。

始める前に

ログ・ファイルまたは標準出力(サーバー・コンソール)にログ・データを表示するには、WebLogic Serverのロギングを次の重大度に設定する必要があります。

- ログの最低の重大度: 情報

- ログ・ファイル: 情報

- 標準出力: 情報

ログの重大度の設定の詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』のログの重大度の使用に関する項を参照してください。

ログ・アクションを追加するには:

1. 必ずロギングをグローバルに有効にしてください。詳細は、『Oracle Service Busの管理』のグローバル・レベルの操作設定の構成に関する項を参照してください。

2. 次の方法の1つを使用して、ログ・アクションをパイプラインに追加します。

- パイプライン・エディタで、ログ・アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それにログ・アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「ログ」を選択します。

- 「ログ」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「ログ」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「レポート」セクションの下で「ログ」アイコンを探します。
エディタ・ウィンドウに「ログ」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「ログ」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

3. 次の手順を使用して、ログ・アクションのプロパティを設定します。

a. パイプライン・エディタで、「ログ」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「コンテンツ」フィールドの右にある「fx」 アイコンをクリックし、XQuery式を指定します。XQuery式は、ログに記録されるメッセージ・コンテキストの指定に使用されます。

c. 「サマリー」フィールドにアラートの短い説明を入力します。この説明は、事前に定義された式の結果と一緒にログに記録されます。

d. ログの「重大度」レベルを選択します。表17-6 は使用可能なオプションを示します。

表17-6 ログ・アクションの重大度

重大度レベル

一般的使用方法

情報

通常の処理を報告するために使用する、低レベルの情報メッセージ。

警告

不審なオペレーションまたは構成が発生しましたが、通常のオペレーションには影響しません。

エラー

ユーザー・エラーが発生したことを示します。システムまたはアプリケーションでは、割込みやサービスの限定的な低下を起こすことなくエラーに対処できます。

デバッグ

アプリケーションの開発中、そのアプリケーションの低レベル・アクティビティを示すメッセージを作成および使用できると便利です。

e. 「全般」セクションの下で、ログ・アクションの「説明」を任意で指定します。

4. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.29 JDeveloperでのレポート・アクションの追加

パイプラインのメッセージ・レポートを有効にするには、レポート・アクションを使用します。

レポート・アクションを追加するには:

1. 次の方法の1つを使用して、レポート・アクションをパイプラインに追加します。

- パイプライン・エディタで、レポート・アクションの追加先のコンポーネント・アイコンを右クリックします。たとえば、「ステージ」ノードを右クリックし、それにレポート・アクションを追加します。
表示されたコンテキスト・メニューから「中に挿入」→「レポート」を選択します。

- 「レポート」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「レポート」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「レポート」セクションの下で「レポート」アイコンを探します。
エディタ・ウィンドウに「レポート」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「レポート」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. 次の手順を使用して、レポート・アクションのプロパティを設定します。

a. パイプライン・エディタで、「レポート」ノードをクリックしてそれを選択します。「プロパティ」ウィンドウに、選択したノードのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「コンテンツ」フィールドの右にある「fx」 アイコンをクリックし、XQuery式を指定します。XQuery式は、Service Busダッシュボードに報告するデータの作成に使用されます。

c. 「検索キー」の下で、緑色のプラス(+)記号で識別される「キーの追加」アイコンをクリックして、検索キーを追加します。「鍵」フィールドは、キー名の指定に使用されます。「変数」フィールドと「XPath」フィールドを合せて、キー値が指定されます。「変数」フィールドによってコンテキスト変数が指定され、「XPath」フィールドによってXPath式が指定されます。
キー値のペアは、メッセージ・コンテキスト変数やメッセージ・ペイロードからキー識別子を抽出して、残りのメッセージを無視する場合に使用します。キーは、メッセージを識別する便利な手段となります。キーは、「レポート」モジュールでレポート・インデックスとして表示されます。『Oracle Service Busの管理』のメッセージ・レポートの操作に関する項を参照してください。

たとえば、ステージのエラー・ハンドラで構成されたレポート・アクションを考えてみます。このアクションは、エラーが発生した場合にfaultコンテキスト変数のコンテンツを報告します。レポート・アクションは次のように構成されます。

- キー名 = errorCode

- キー値= ./ctx:errorCode(変数fault)

実行時にこのこのアクションが行われるたびに、データ・ストリームを通じてメッセージが報告されます。次の表は、レポート・アクションが2回実行された後の結果を示しています。

レポート・インデックス

DBタイムスタンプ

インバウンド・サービス

エラー・コード

errorCode=OSB-382505

04/26/07 9:45 AM

MortgageBroker/ProxySvcs/loanGateway3

OSB-382505

errorCode=OSB-382505

04/26/07 9:45 AM

OSB-382505

d. 前述の手順を繰り返すことで、キーをさらに追加できます。キーを削除するには、赤いX記号が付いた「キーの削除」アイコンをクリックします。

e. 「全般」セクションの下で、レポート・アクションの「説明」を任意で指定します。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.30 JDeveloperでのエラー・ハンドラの追加

JDeveloperでのエラー・ハンドラの実装は、Oracle Service Busコンソールを使用した場合とよく似ています。主な相違点は、パイプライン・デザイナのドラッグ・アンド・ドロップ機能と、各パイプライン・アクションで表示されるプロパティ・ウィンドウです。

17.30.1 JDeveloperでのエラー・ハンドラのパイプラインへの追加方法

エラー・ハンドラを使用して、パイプライン内の特定の場所でエラーが発生した場合の処理を指定します。エラー処理は、パイプライン、パイプライン・ペア、ルート・ノードおよびステージ・レベルで構成できます。

始める前に

目的のパイプラインのメッセージ・フローを表示します。

パイプラインにエラー・ハンドラを追加するには:

1. 次の方法の1つを使用して、エラー・ハンドラをパイプラインに追加します。

- パイプライン・エディタで、エラー・ハンドラの追加先のコンポーネント・アイコンを右クリックします。次のようなエラー・ハンドラを追加できます。

- パイプライン・レベルでエラー・ハンドラを追加するには、開始ノードを右クリックします。コンテキスト・メニューから「エラー・ハンドラの追加」を選択します。

- リクエストまたはレスポンス・パイプラインのエラー・ハンドラを追加するには、「リクエスト・パイプライン」または「レスポンス・パイプライン」を右クリックします。コンテキスト・メニューから「エラー・ハンドラの追加」を選択します。

- ステージ・ノードのエラー・ハンドラを追加するには、「ステージ」ノードを右クリックします。コンテキスト・メニューから「エラー・ハンドラの追加」を選択します。

- ルート・ノードのエラー・ハンドラを追加するには、「ルート」ノードを右クリックします。コンテキスト・メニューから「エラー・ハンドラの追加」を選択します。

- 「エラー・ハンドラ」コンポーネントを、「コンポーネント」ウィンドウからパイプライン・エディタの適切な場所にドラッグします。「エラー・ハンドラ」コンポーネントを見つけるには、「コンポーネント」ウィンドウで「メッセージ・フロー」カテゴリを選択します。次に、「ノード」セクションの下で「エラー・ハンドラ」アイコンを探します。
エディタ・ウィンドウに「エラー・ハンドラ」コンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つに「エラー・ハンドラ」コンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

2. エラー・ハンドラのデフォルト名を変更して説明を追加するには、次のように実行します。

a. エラー・ハンドラ・ステージ・ノードをクリックし、それを選択します。「プロパティ」ウィンドウに、選択したコンポーネントのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 選択したステージ・ノードの「名前」および「説明」フィールドを編集します。

c. Oracle JDeveloperツールバーで、「保存」をクリックします。

3. エラー・ハンドラ・ステージでアクションを追加するには、「JDeveloperでのパイプラインのアクションの追加および編集」を参照してください。

4. エラー・ハンドラにさらにステージを追加するには、「JDeveloperでのエラー・ハンドラの追加」を参照してください。

5. パイプライン・エディタで、「JDeveloperでのパイプラインの表示と編集」の説明に従って、パイプラインの作成を続けます。

6. Oracle JDeveloperツールバーで、「保存」をクリックします。

17.31 JDeveloperでのアクションまたはステージの無効化

パイプライン内のアクションまたはステージを無効化することもできます。無効化されたアクションまたはステージは、メッセージ・フローの実行でスキップされます。無効化されたステージまたはアクションは設計時に検証されません。

注意:

無効化されたステージにエラー・ハンドラがある場合、そのエラー・ハンドラも無効化されます。

アクションまたはステージを無効化した場合、ネストされたアクション(存在する場合)はすべて暗黙的に無効化されます。これは、ネストされたアクションもメッセージ・フローの実行でスキップされることを意味します。ネストされたアクションを設計時検証で無効にする場合は、それらのアクションを個別に無効にする必要があります。

無効化されたアクションまたはステージの構成は編集できます。リファクタは、無効化されたアクションおよびステージに対しても実行されます。したがって、無効化されたアクションまたはステージ内のサービスに対するコールがあり、そのサービスの名前が変更されている場合、サービス・コールアウトは自動的に更新されます。

17.31.1 アクションまたはステージの無効化

アクションまたはステージを無効化するには:

1. パイプライン・エディタで、無効化するステージまたはアクションのアイコンを右クリックします。

2. 表示されたコンテキスト・メニューから「無効化」を選択します。

そのアクションまたはステージは無効化され、その横に「無効」アイコンが表示されます。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

無効化されたステージまたはアクションはいつでも再有効化でき、それによってそのアクションまたはステージはメッセージ・フローでスキップされなくなります。

17.31.2 アクションまたはステージの再有効化

アクションまたはステージを再有効化するには:

1. パイプライン・エディタで、無効化されたステージまたはアクションのアイコンを右クリックします。

2. 表示されたコンテキスト・メニューから「有効化」を選択します。

そのステージまたはアクションの横にある「無効」アイコンは表示されなくなり、ステージまたはアクションは有効化されます。

3. Oracle JDeveloperツールバーで、「保存」をクリックします。

18 パイプライン・テンプレートの操作

この章では、パイプライン・テンプレートを使用したプロトタイプ・メッセージ・フローの設計について説明します。また、Oracle JDeveloperを使用して、パイプライン・テンプレートおよび具象パイプラインを設計および構成する方法についても説明します。

注意:

Oracle Service Busコンソールでパイプライン・テンプレートを作成することはできません。ただし、プロジェクト・ナビゲータで既存のテンプレート・リソースを確認したり、バインディング・タイプやメッセージ処理のオプションなどのテンプレート・プロパティを表示することは可能です。テンプレートの削除、名前変更、および別のフォルダやプロジェクトへの移動も可能です。

パイプライン・テンプレートを使用して、プロキシ・サービスのプロトタイプ・メッセージ・フローを設計します。パイプライン・テンプレートによって、メッセージ・フローの一般的な形状またはパターンが定義されます。その後、パイプライン・テンプレートから具象パイプラインを生成できます。すべての具象パイプラインは、カスタム・ロジックを挿入可能な場所が指定されているパイプライン・テンプレートによって定義されるメッセージ・フローを使用します。

次の項では、Oracle JDeveloperでのパイプライン・テンプレートの操作について説明します。

- パイプライン・テンプレートの追加

- パイプライン・テンプレートの編集

- パイプライン・テンプレート・メッセージ・フローへのプレースホルダ・ブロックの追加

- パイプライン・テンプレートでのアクションのロック

- パイプライン・テンプレートからの具象パイプラインの作成

- 具象パイプラインに対するメッセージ・フローの編集

- 具象パイプラインから通常のパイプラインへの変換

18.1 パイプライン・テンプレートの追加

パイプライン・テンプレートを使用して、プロキシ・サービスのプロトタイプ・メッセージ・フローを設計します。パイプライン・テンプレートによって、メッセージ・フローの一般的な形状またはパターンが定義されます。

18.1.1 パイプライン・テンプレートの追加方法

Oracle JDeveloperで開いているService Busプロジェクトにパイプライン・テンプレートを追加できます。

パイプライン・テンプレートを追加するには:

1. Oracle JDeveloperでService Busプロジェクトを開いていることを確認します。

2. 次の方法の1つを使用して、新しいパイプライン・テンプレートを追加します。

- アプリケーション・ナビゲータで、「Service Busプロジェクト」アイコンを右クリックし、コンテキスト・メニューから「新規」→「パイプライン・テンプレート」を選択します。

- 「ファイル」メニューから、「新規」→「パイプライン・テンプレート」を選択します。

「パイプライン・テンプレートの作成」ウィザードが表示されます。

3. 「サービス名」の下に、パイプライン・テンプレートの名前を入力します。

4. 「場所」フィールドの右にある「参照」アイコンをクリックし、パイプライン・テンプレートのディレクトリを指定します。デフォルト・ディレクトリは、Service Busプロジェクト・フォルダです。

5. 必要に応じて、パイプライン・テンプレートの「説明」を入力します。

6. 既存のパイプラインを使用してテンプレートを定義する場合は、「パイプラインから」を選択します。「参照」アイコンをクリックし、パイプライン・ファイルを選択します。

7. 「次」をクリックします。「サービス・タイプ」ページが表示されます。

8. パイプライン・テンプレートの「サービス・タイプ」を選択します。このテンプレートから作成するすべての具象パイプラインは、同じサービス・タイプを使用します。

具象パイプラインを作成するときにサービス・タイプを選択できるようにする場合は、「任意」を選択します。

9. 「終了」をクリックし、パイプライン・テンプレートを作成します。テンプレート・デザイナで、パイプライン・テンプレート(.ptx)が開かれます。アプリケーション・ナビゲータにもパイプライン・テンプレートが表示されます。

10. テンプレート・デザイナで、左下にある「構成」タブを選択します。「構成」タブは、メッセージ処理構成設定およびその他の一般設定を指定するために使用します。

11. 「全般」をクリックし、パイプライン・テンプレートのオプションの「説明」を指定します。

18.2 パイプライン・テンプレートの編集

パイプライン・テンプレートは、作成後にテンプレート・デザイナを使用して編集できます。テンプレートのメッセージ処理構成設定などの設定を指定し、テンプレートのメッセージ・フローを編集できます。

18.2.1 パイプライン・テンプレートの編集方法

テンプレート・デザイナを使用し、パイプライン・テンプレートの設定およびメッセージ・フローを構成します。

パイプライン・テンプレートを編集するには:

1. アプリケーション・ナビゲータでパイプライン・テンプレートをダブル・クリックし、それをテンプレート・デザイナで開きます。

2. 左下にある「構成」タブをクリックし、「説明」などの一般構成設定と、コンテンツのストリーミング、トランザクション設定などのメッセージ処理設定を指定します。設定に関するヘルプを表示するには、[F1]キーを押します。

3. 左下にある「設計」タブをクリックし、パイプライン・テンプレートのメッセージ・フローを編集します。

パイプライン・テンプレートに対してまだメッセージ・フローが作成されていない場合は、テンプレート・デザイナの「設計」ビューのページに「プロキシ・サービス」アイコンが1つ表示されます。これは、メッセージ・フローの開始ノードです。

4. 次の方法の1つを使用して、メッセージ・フロー・コンポーネント(ノード)をメッセージ・フローに追加します。

- 開始ノード(プロキシ・サービス・アイコン)を右クリックし、追加できるメッセージ・フロー・コンポーネントのオプションを取得します。
図18-1は、開始ノードに使用できるオプションを示しています。PipelinePairノード、条件付きブランチなどのノードを追加できます。「ノード」、「ルート」、「条件テンプレート」などのテンプレート・プレースホルダを追加することもできます。テンプレート・プレースホルダは、具象パイプラインを作成するときに追加できる実際のノード用のプレースホルダです。

図18-1 ノードの右クリックによるメッセージ・フロー・コンポーネントの追加

- または、「コンポーネント」ウィンドウから追加するメッセージ・フロー・コンポーネントを選択し、そのコンポーネントをテンプレート・デザイナ・ウィンドウにドラッグします。メッセージ・フロー内でコンポーネントをドロップできる場所を示す黄色の円が表示されます。コンポーネントを黄色の円にドラッグします。黄色の円が緑色に変化します。コンポーネントを解放して追加します。図18-2は、開始ノードに追加しようとしているパイプライン・ペア・ノードを示しています。

図18-2 開始ノードへのパイプライン・ペアの追加

テンプレート・デザイナにコンポーネントを追加するときには、テンプレート・デザイナにそのコンポーネントを表す対応するアイコンが表示されます。コンポーネント間の関係は、線と境界を示す四角形で示されます。

図18-3は、パイプライン・ペア・ノードがフローに追加されたメッセージ・フローを示しています。パイプライン・ペアは、リクエスト・パイプラインとレスポンス・パイプラインで構成されています。リクエストおよびレスポンスの各パイプラインには、アクション・ノードを含めることができるステージがあります。

図18-3 パイプライン・ペア・ノードのあるメッセージ・フロー

5. さらにコンポーネントを追加することでメッセージ・フローの構築を続けます。たとえば、ステージ・ノードにアクション・プレースホルダを追加するには、「コンポーネント」ウィンドウからエディタのステージ・ノードにアクション・コンポーネントをドラッグできます。かわりに、ステージ・ノードを右クリックし、ステージ・ノードに追加できるメッセージ・フロー・コンポーネントのオプションを取得することもできます。各コンポーネントに使用できるオプションは、コンテキストに応じて異なります。

6. Oracle JDeveloperツールバーで、「保存」をクリックします。

18.2.1.1 外部サービスの表示方法

開始ノードに示されている外部サービスは、パイプラインのコンテキストの外部で呼び出されるサービスです。これらは、サービスの呼出しノードで指定されていますが、容易に使用できるようにリストされています。

外部サービスを表示するには:

外部サービスを表示するには、開始ノードの左矢印ボタンをクリックします。開始ノードの左側に「外部サービス」ボックスが表示されます。外部サービスの上にマウスを置くと、サービス・リソースの完全パスが表示されます。

18.2.1.2 共有変数の表示方法

開始ノードに示されている共有変数は、パイプラインが同じコール・チェーン内の別のパイプラインと共有できる変数です。

注意:

1つのコール・チェーン内の2つのパイプラインで同じ共有変数を宣言する場合、これらは呼出しコール・チェーンの範囲内の同じ変数を読み取り、変更します。つまり、パイプラインP1で共有変数varを宣言し、パイプラインP1が、同様に共有変数varを宣言するパイプラインP2を呼び出す場合、P1のvarの変更はP2に表示され、逆も当てはまります。共有変数は、文字列、ブールまたはXMLのデータ型にする必要があります。

外部サービスを表示するには:

共有変数を表示するには、開始ノードで左矢印ボタンをクリックします。開始ノードの左側に「共有変数」ボックスが表示されます。「共有変数」ボックスを右クリックすると、コンテキスト・メニューを表示できます。コンテキスト・メニューでは、共有変数の追加や削除などのタスクを実行できます。

18.3 パイプライン・テンプレート・メッセージ・フローへのプレースホルダ・ブロックの追加

パイプライン・テンプレートで特定のタイプのテンプレート・プレースホルダが定義されている場合、具象パイプラインでは、同じタイプのゼロ個以上のノードをそのテンプレート・プレースホルダに追加できます。たとえば、アクション・テンプレート・プレースホルダには、具象パイプラインでゼロ個以上のアクション・ノードを含めることができます。

テンプレート・プレースホルダには、次のタイプがあります。

- ノード: ノード・テンプレート・プレースホルダには、次のノードを含めることができます。

- ステージまたはアクションを含む具象パイプライン・ペア・ノード

- 条件付きブランチ・ノード

- 操作ブランチ・ノード

- RESTブランチ・ノード

- ルート・ノード

たとえば、ノード・プレースホルダ・ブロックには、具象パイプラインで、ルート・ノードが後に続くパイプライン・ペア・ノードを含めることができます。

- ステージ: ステージ・テンプレート・プレースホルダには、具象パイプラインでゼロ個以上のステージを含めることができます。各ステージには、アクションを含めることができます。

- アクション: アクション・テンプレート・プレースホルダには、具象パイプラインでゼロ個以上のアクションを含めることができます。

- ルート: ルート・テンプレート・プレースホルダは、具象パイプラインでのルーティング・アクション用のプレースホルダです。

- 条件: 条件テンプレート・プレースホルダによって、具象パイプラインの条件付きブランチ・ノードを指定できます。

- 操作: 操作テンプレート・プレースホルダによって、WSDL SOAPバインディングを使用する場合の具象パイプラインの操作ブランチ・ノードを指定できます。

- REST: RESTテンプレート・プレースホルダによって、RESTバインディングを使用する場合の具象パイプラインのRESTブランチ・ノードを指定できます。

18.4 パイプライン・テンプレートでのアクションのロック

パイプライン・テンプレート・メッセージ・フローに追加するアクションの必須プロパティをすべて指定しており、かつすべての具象パイプラインでそれらのプロパティに同じ値を使用する場合は、パイプライン・テンプレート・メッセージ・フローのアクションをロックできます。

ロックされたアクションは、具象パイプラインで編集できません。すべての必須プロパティおよびオプションのプロパティをパイプライン・テンプレートで指定済であることを確認してください。

18.4.1 パイプライン・テンプレートでのアクションのロック方法

テンプレート・デザイナの「プロパティ」ウィンドウからアクションをロックできます。

始める前に:

「パイプライン・テンプレートの編集」の説明に従って、テンプレート・デザイナでメッセージ・フローを編集していることを確認します。

アクションをロックするには:

1. テンプレート・デザイナでアクションを選択します。アクションのプロパティが、「プロパティ」ウィンドウに表示されます。

2. 選択したアクションに固有の必須プロパティをすべて指定済であることを確認します。

3. 「プロパティ」ウィンドウで、「ロック」アイコンをクリックし、アクションをロックします。

図18-4 パイプライン・テンプレートでのアクションのロック

18.5 パイプライン・テンプレートからの具象パイプラインの作成

具象パイプラインには、パイプライン・テンプレートによって定義されているメッセージ・フロー・パターンが実装されます。具象パイプラインのメッセージ・フローは、指定された場所でカスタマイズできます。

18.5.1 具象パイプラインの作成方法

パイプライン作成ウィザードを使用して、パイプライン・テンプレートに基づいて具象パイプラインを作成できます。

具象パイプラインを作成するには:

1. Oracle JDeveloperでService Busプロジェクトを開いていることを確認します。

2. 次の方法の1つを使用して、新しいパイプラインを作成します。

- 「ファイル」メニューで、「新規」→「パイプライン」をクリックします。「パイプライン・サービスの作成」ウィザードが表示されます。

- アプリケーション・ナビゲータで、「Service Busプロジェクト」アイコンを右クリックします。「新規」→「パイプライン」を選択します。「パイプライン・サービスの作成」ウィザードが表示されます。

- アプリケーション・ナビゲータで、新しいパイプラインの作成元とするパイプライン・テンプレートを右クリックします。「Service Bus」→「パイプラインの生成」を選択します。
「パイプライン・サービスの作成」ウィザードが表示されます。パイプライン・テンプレートの名前が、「テンプレートから」フィールドにすでに移入されています。

3. 「サービス名」の下に、新しい具象パイプラインの名前を入力します。

4. 「場所」フィールドの右にある「参照」アイコンをクリックし、具象パイプライン・リソースの場所を選択します。デフォルトの場所は、Service Busプロジェクト・フォルダです。

5. 具象パイプラインの「説明」を任意で指定します。

6. まだ選択していない場合は、「テンプレートから」を選択し、パイプライン・テンプレートを指定します。「テンプレートから」フィールドの右にある「参照」アイコンをクリックし、パイプライン・テンプレートを選択します。パイプライン・テンプレート・ファイルを選択し、「OK」をクリックします。

7. 「次」をクリックします。

8. 具象パイプラインの「サービス・タイプ」を選択します。使用可能なオプションは、基礎となるテンプレートに指定されているサービス・タイプに応じて異なります。

9. 「終了」をクリックし、具象パイプラインを作成します。

18.6 具象パイプラインに対するメッセージ・フローの編集

具象パイプラインは、パイプライン・テンプレートからそのメッセージ・フローを継承します。パイプライン・エディタでメッセージ・フローを完成できます。メッセージ・フロー内のテンプレート・プレースホルダにノードおよびアクションを追加できます。さらに、パイプライン・テンプレートで定義されているその他のロックされていないアクションのプロパティを編集または完了できます。具象パイプラインのロック済アクションは編集できません。

18.6.1 具象パイプラインに対するメッセージ・フローの編集方法

パイプライン・エディタを使用して、具象パイプラインのメッセージ・フローを編集します。テンプレート・プレースホルダにノードおよびアクションを追加でき、パイプライン・テンプレートで定義されている他のロックされていないアクションを編集できます。

具象パイプラインに対するメッセージ・フローを編集するには:

1. Oracle JDeveloperでService Busプロジェクトを開いていることを確認します。

2. 次の方法の1つを使用して、パイプラインのメッセージ・フローを編集します。

- アプリケーション・ナビゲータで、パイプライン・ノードを見つけます。パイプライン・ノードを右クリックし、「開く」を選択します。かわりに、パイプライン・ノードをダブルクリックして開くこともできます。

- アプリケーション・ナビゲータで、プロジェクト・ノード(またはoverview.xml)をクリックし、概要エディタを開きます。
概要エディタで、パイプライン・コンポーネントをダブルクリックし、パイプライン・エディタを開きます。

パイプライン・エディタが表示されます。エディタの左下隅の「設計」タブが選択されていることを確認します。

パイプライン・エディタには、パイプライン・テンプレートで設計されたメッセージ・フローが表示されます。

3. ロックされていないアクションのプロパティを編集するには:

a. パイプライン・エディタ・メッセージ・フローでアクションをクリックして選択します。「プロパティ」ウィンドウに、選択したアクションのプロパティが表示されます。

注意:

「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メイン・メニューから「プロパティ」を選択します。

b. 「プロパティ」ウィンドウでプロパティを編集します。

4. 次の方法の1つを使用して、テンプレート・プレースホルダを編集します。

- テンプレート・プレースホルダ・アイコンを右クリックし、追加できるメッセージ・フロー・コンポーネントのオプションを取得します。表示されたコンテキスト・メニューから「中に挿入」をクリックします。
図18-5は、アクション・テンプレート・プレースホルダに使用できるオプションを示しています。

図18-5 テンプレート・プレースホルダへのノードの追加

- 「コンポーネント」ウィンドウからパイプライン・エディタのテンプレート・プレースホルダに目的のコンポーネントをドラッグします。
エディタ・ウィンドウにコンポーネントをドラッグすると、コンポーネントをドロップできる有効な場所を示す黄色の円が表示されます。黄色の円の1つにコンポーネントをドラッグすると、その円が緑色に変化し、そこにコンポーネントをドロップできることを示します。マウス・ボタンを離すと、コンポーネントがドロップされます。

5. さらにアクションを編集したり、テンプレート・プレースホルダにさらにノードをドロップすることでメッセージ・フローの構築を続行します。

6. Oracle JDeveloperツールバーで、「保存」をクリックします。

18.7 具象パイプラインから通常のパイプラインへの変換

具象パイプラインをパイプライン・テンプレートに関連付ける必要がなくなった場合、テンプレート・リンクを解除し、そのパイプラインを通常のパイプラインに変換できます。通常のパイプラインは、具象パイプラインに適用される制限なしで編集できます。

18.7.1 具象パイプラインに対するテンプレート・リンクの解除方法

パイプライン・エディタの「構成」タブを使用して、関連付けられたテンプレートとのそのリンクを解除できます。

具象パイプラインのテンプレート・リンクを解除するには:

1. Oracle JDeveloperでService Busプロジェクトを開いていることを確認します。

2. 次の方法の1つを使用して、パイプライン・エディタを開きます。

- アプリケーション・ナビゲータで、具象パイプライン・ノードを見つけます。パイプライン・ノードを右クリックし、「開く」を選択します。かわりに、パイプライン・ノードをダブルクリックして開くこともできます。

- アプリケーション・ナビゲータで、プロジェクト・ノード(またはoverview.xml)をクリックし、概要エディタを開きます。
概要エディタで、具象パイプライン・コンポーネントをダブルクリックし、パイプライン・エディタを開きます。

パイプライン・エディタが表示されます。エディタの左下隅で「構成」タブが選択されていることを確認します。

3. 「全般」をクリックし、「一般構成」ページを表示します。

4. 「テンプレート」の下の「テンプレート・リンクの解除」アイコンをクリックします。図18-6は、「テンプレート・リンクの解除」アイコンを示しています。

図18-6 テンプレート・リンクの解除

第IV章 データの変換

この部では、Service Busによって処理されるメッセージのデータをマップおよび変換するためのツールについて説明します。

この部は、次の章で構成されています。

- XQueryでのデータの変換

- XSLTでのデータの変換

- 相互参照でのデータのマッピング

- ドメイン値マップでのデータのマッピング

- Message Format Languageを使用したデータ構造の定義

- JavaコールアウトおよびPOJOの使用方法

19 XQueryでのデータの変換

この章では、Oracle Service Busコンソールを使用したXQuery変換リソースの作成、検索、編集および削除の方法について説明します。

XQueryトランスフォーメーション・マップは、XMLからXML、XMLから非XML、および非XMLからXMLのマッピングを記述できます。

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

- XQuery変換の概要

- XQueryエディタおよびマッパー

- JDeveloperでのXQueryマップの作成

- JDeveloperでXQuery 2004からXQuery 1.0に変換されたService Busプロジェクトのテスト

- Oracle Service BusコンソールでのXQueryリソースの操作

- Service Bus XQuery関数

19.1 XQuery変換の概要

XQueryは、XMLドキュメントに対してXMLデータを問い合わせる際に役立ちます。XQueryはXPathを使用および拡張し、XMLドキュメント内の要素および属性をナビゲートしてそれらを抽出します。

Service BusはXQueryを使用してビジネス・ロジックを実装します。Service Busは、変換、データ選択、条件評価およびデータ操作などの様々なアクティビティでXQueryリソースを使用します。Service BusはXQuery 1.0を完全にサポートします。これには、モジュールなどのオプション機能が含まれます。古いXQuery 2004もサポートされます。

XQueryトランスフォーメーション・マップは、2つのデータ型の間のマッピングを記述したものです。XQueryマップは、スキーマの異なるXMLドキュメント間のマッピングを記述したものです。Service BusでXQueryを使用すると、XMLドキュメントを処理して、ドキュメント・データをXMLスキーマから別のXMLスキーマに変換できます。これにより、異なるスキーマを使用するアプリケーション間でデータの交換が可能になります。XQueryを使用して、複雑なデータ操作と変換を実行できます。たとえば、受信する発注スキーマを、送信する請求書スキーマにマップできます。

XQuery式は、メッセージ・フローの実行中にメッセージ・コンテキスト変数のデータ・コンテンツ(メッセージ・コンテキスト変数の一部)を作成するために使用します。XQuery式エディタ内で直接テスト・コンソールを使用して、式の定義をテストすることができます。同様に、XQuery条件を使用して、メッセージ・フロー内のブール条件を評価できます。XQuery条件エディタ内で直接テスト・コンソールを使用して、条件の定義をテストすることができます。

19.2 XQueryエディタおよびマッパー

JDeveloperには、XQueryを使用した変換をスクリプト化できる式ビルダーと、複雑なマッピングを作成できるXQueryマッパーがあります。

Oracle Service Busコンソールには、XQueryを使用した変換をスクリプト化するエディタがあります。このエディタには、XQuery式を定義したり、既存のXQueryリソースの名前として実行時に評価される式を定義したりするオプションが用意されています。

JDeveloperおよびコンソールのいずれの場合も、パイプラインまたは分割-結合のいずれかのアクションからエディタにアクセスします。

19.2.1 JDeveloperのエディタおよびマッパー

JDeveloperのXQueryマッパーは、スキーマのルート要素、WSDLメッセージ・パート、またはWSDLメッセージの間のマッピングを定義できるグラフィカル・ツールです。スキーマのルート要素はXSDスキーマ・ファイルまたはWSDLファイルから取得できますが、直接マップできるのは、単一のメッセージ・パートを含むWSDLメッセージのみです。JDeveloperでXSLTマッピングを作成したら、マッパーで生成された.xslファイルをOracle Service BusコンソールのXSLTリソースにアップロードできます。

JDeveloperには様々な式ビルダーも用意されており、式を作成して、使用する既存のXSLTリソースを指定できます。JDeveloperのマッパーとエディタの詳細は、次のトピックを参照してください。

- Oracle SOA Suiteを使用したSOAアプリケーションの開発のXQueryマッパーを使用した変換の作成に関する項

- Oracle SOA Suiteを使用したSOAアプリケーションの開発のOracle JDeveloperの式ビルダーを使用したXPath式の作成に関する項

19.2.2 Oracle Service Busコンソール・エディタ

Oracle Service Busコンソールで、XQuery/XSLT式エディタを使用して式を作成し、使用する既存のXQueryリソースを指定できます。

XQueryリソースを参照するには、コンソールでリソースを作成し、既存のXQuery変換ファイル(.xqy)をリソースにアップロードしておく必要があります。この機能により、JDeveloperで複雑なマッピングを作成し、それらをコンソールにインポートして使用できます。XQuery変換は複数のパイプラインおよび分割-結合で再利用できます。

Oracle Service Bus ConsoleのXQuery/XSLTエディタの詳細は、「Oracle Service Busコンソールでの式エディタの操作」を参照してください。

19.3 JDeveloperでのXQueryマップの作成

JDeveloperでService Busプロジェクト内にXQueryマップを作成し、パイプラインおよび分割-結合のXQuery式でそれらを使用して外部システム間でオブジェクトをマップできます。

19.3.1 JDeveloperでのXQueryマッピングの作成方法

XQueryマッピングを作成するには、ソースとターゲットのマッピングに使用する、ソースXMLスキーマ要素またはXMLファイルを選択する必要があります。

XQueryマップの作成方法の詳細は、Oracle SOA Suiteを使用したSOAアプリケーションの開発のXQueryマップ・ファイルの作成に関する項を参照してください。

XQueryマッパーを使用してXQueryを作成する方法の詳細は、Oracle SOA Suiteを使用したSOAアプリケーションの開発のXQueryマッパーの使用に関する項を参照してください。

19.4 JDeveloperでXQuery 2004からXQuery 1.0に変換されたService Busプロジェクトのテスト

Service BusプロジェクトをXQuery 2004からXQuery 1.0に変換する際に、すべての2004 XQueryはXQuery 1.0エンジンで実行されるように切り替えられます。XQuery 2004からXQuery 1.0に変換後、JDeveloperの「XQueryマッパー」タブが表示されるが、実際のマッピングは表示されません。

JDeveloperで変換されたXQueryをテストするには:

1. JDeveloperを再起動します。

2. テストするXQueryファイルが開いていることを確認します。

3. 「XQueryソース」タブをクリックし、「ソース」ビューを入力します。

4. ソースを右クリックし、「XQueryの実行」を選択します。

変換されたXQueryをテストする場合:

- ネームスペース宣言を正確に作成します。これには2通りの方法があります。

- XQuery仕様からimport文を使用:

import schema namespace ns0="http://www.example.com/custele"
at "../TestInputSchemas/customerEle.xsd";

- Oracleの注釈のメカニズムを使用:

xquery version "1.0"; (:: OracleAnnotationVersion "1.0" ::)
declare namespace ns0="http://www.example.com/custele";
(:: import schema at "../TestInputSchemas/customerEle.xsd"::)

- JDeveloperマッパー・メカニズムで認識されるように、変数をスキーマ要素として宣言します。次に例を示します。

declare function local:AttributeToElement($customerOut as element()(::schema-element(ns0:customerOut)::))
as element() (::schema-element (ns1:customer)::)

19.5 Oracle Service BusコンソールでのXQueryリソースの操作

XQueryリソースをService Busプロジェクトに追加できます。JDeveloperまたは他のエディタを使用して作成されたXQueryファイルは、リソースとしてプロジェクトにインポートできます。

- コンソールでのXQueryリソースの作成方法

- コンソールでのXQueryリソースの編集方法

- コンソールでのXQueryリソースの削除方法

- XQuery 1.0を使用したXQueryリソースのアップグレード方法

19.5.1 コンソールでのXQueryリソースの作成方法

Oracle Service Busコンソールを使用して、XQueryリソースをService Busプロジェクトに追加します。JDeveloperなどのエディタで作成したXQueryファイルをインポートするか、ソースを作成してインラインでコードを編集できます。

コンソールでXQueryリソースを作成するには:

1. プロジェクト・ナビゲータでは、プロジェクトまたはフォルダを右クリックしてXQueryリソースを含め、「作成」をポイントし、「リソース」を選択します。「変換」、「XQuery」をクリックし、次に「OK」をクリックします。
XQueryの作成ダイアログが表示されます。

2. 次のいずれかを行います:

- 既存のXQueryファイルからリソースを作成するには、「ファイルのアップロード」フィールドの横にある「ファイルの選択」をクリックし、使用するファイルを選択します。
「リソース名」フィールドに、ファイル拡張子なしのファイル名が自動的に移入されます。この名前は変更可能です。

- XQueryを最初から作成するには、XQueryリソースに一意の名前を入力します。

3. 必要に応じて、リソースの簡単な「説明」を入力します。

4. 「作成」をクリックします。
XQueryリソースがXQuery定義エディタに表示されます。

5. XQueryを変更するには、次の手順を実行します。

a. ツールバーで、「XQueryコンテンツの編集」をクリックします。
「ソースの表示/編集」ダイアログが表示されます。

b. アップロードする新しいXQueryファイルを参照して選択するには、「ファイルの選択」をクリックします。

c. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

d. 「保存」をクリックします。保存時にXQueryが検証されます。

6. XQuery定義エディタのツールバーで、「保存」をクリックします。

7. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

19.5.2 コンソールでのXQueryリソースの編集方法

Oracle Service Busコンソールを使用して、Service Busプロジェクト内のXQueryリソースを編集します。JDeveloperなどのエディタで作成した更新済XQueryファイルをインポートするか、インラインでコードを編集できます。

コンソールでXQueryリソースを編集するには:

1. プロジェクト・ナビゲータで、編集するXQueryリソースを含むプロジェクトおよびフォルダを開きます。

2. XQueryリソース名を右クリックして、「開く」を選択します。

3. XQueryソースを編集するには、ツールバーで「XQueryコンテンツの編集」をクリックします。

「ソースの表示/編集」ダイアログが表示されます。

4. アップロードする新しいXQueryファイルを参照して選択するには、「ファイルの選択」をクリックします。

5. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

6. 「保存」をクリックします。

7. XQuery定義エディタのツールバーで、「保存」をクリックします。

8. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

19.5.3 コンソールでのXQueryリソースの削除方法

Oracle Service Busコンソールを使用して、XQueryリソースをService Busプロジェクトから削除できます。リソースに参照がある場合は、リソースを削除する前に参照を削除します。XQuery定義エディタでXQueryリソースを開き、右上の「ツール」アイコンをクリックして「参照」を選択し、そこに参照があるかどうかを確認します。

コンソールでXQueryリソースを削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するXQueryリソースを含むプロジェクトおよびフォルダを開きます。

2. XQueryリソース名を右クリックして、「削除」を選択します。確認のダイアログが表示されます。

3. 「はい」をクリックすると、リソースを削除できます。

4. 「アクティブ化」をクリックしてセッションを終了し、構成をランタイムにデプロイします。

19.5.4 XQuery 1.0を使用したXQueryリソースのアップグレード方法

Service BusはXQuery 1.0をサポートします。古いXQuery 2004もサポートされます。Service Busで作成された新しいXQueryリソースは、デフォルトでXQuery 1.0を使用します。

12g以前のService Busプロジェクトからアップグレードした場合、プロジェクト内のすべてのXQueryリソースはXQuery 2004を使用するように構成されます。すべてのXQueryファイルで、次の行が1行目として存在します。

xquery version "2004-draft";

プロジェクト内のすべてのXQuery 2004リソースでXQuery 1.0を使用するようにアップグレードすることもできます。XQueryコンバータは、Query 2004ファイルからXQuery 1.0への基本的な変換を実行します。コンバータで処理できない構文エラーは、手動で確認して修正する必要があります。

プロジェクト内のXQueryリソースをアップグレードするには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、アップグレードするプロジェクトを右クリックします。

2. 表示されるコンテキスト・メニューから「XQ 1.0に変換」を選択します。確認のダイアログが表示されます。

3. 「はい」を選択して、XQuery 1.0エンジンを使用するようにすべてのリソースを変換します。

テスト・コンソールを使用してXQueryリソースをテストできます。テスト・コンソールを使用するには、プロジェクト・ナビゲータでプロジェクト名をクリックしてプロジェクトを開きます。テスト対象のXQueryリソースに対応する「アクション」列の下で「テスト・コンソールの起動」アイコンをクリックします。

19.6 Service Bus XQuery関数

Service Busでは、次のXQuery関数をサポートしています。

- W3C仕様で説明する標準のXQuery関数:
http://www.w3.org/TR/xpath-functions/

- いくつか例外はありますが、Oracle XQueryエンジンの一部として提供されるOracle拡張関数および言語キーワード(「Oracleでサポートされる拡張関数」を参照)。

- Service Bus固有の拡張関数。「Service Busの関数拡張機能」を参照してください。

注意:

すべてのOracleの拡張関数で、次の関数接頭辞fn-bea:を使用します。つまり、XQueryの完全な表記では拡張関数は次の形式になります。

fn-bea: function_name.

19.6.1 Oracleでサポートされる拡張関数

すべてのOracle関数拡張機能の説明は、「Service Bus XQuery関数」を参照してください。

Service Busでは、XQueryに対し、次のものを除くすべてのOracle拡張関数がサポートされています。

- fn-bea:is-access-allowed

- fn-bea:is-user-in-group

- fn-bea:is-user-in-role

- fn-bea:userid

- fn-bea:async

- fn-bea:timeout

- fn-bea:get-property

- fn-bea:execute-sql()

Service Busでは、次の関数は使用しないでください。他の言語機能で代用することをお薦めします。

- fn-bea:if-then-else

- fn-bea:QName-from-string

- fn-bea:sql-like

19.6.2 Service Busの関数拡張機能

Service Busには、次のXQuery関数が用意されています。

- fn-bea:lookupBasicCredentials

- fn-bea:isUserInGroup

- fn-bea:isUserInRole

- fn-bea: uuid

- fn-bea:execute-sql()

- fn-bea:serialize()

- fn-bea:binary-to-text

- fn-bea:binary-to-xml

19.6.2.1 fn-bea:lookupBasicCredentials

fn-bea:lookupBasicCredentials関数は、指定されたサービス・アカウントのユーザー名と暗号化されていないパスワードを返します。任意のタイプのサービス・アカウントを指定できます(静的、パススルー、またはユーザー・マッピング)。「サービス・アカウントの操作」を参照してください。

fn-bea:lookupBasicCredentials関数は、カスタム・トランスポート・ヘッダー、またはSOAPエンベロープのアプリケーション固有の場所にあるユーザー名とパスワードのエンコードに使用するXQuery関数の大規模なセットの一部として使用します。HTTP認証ヘッダーにユーザー名とパスワードだけを含める必要がある場合、またはWS-Securityユーザー名トークンとしてユーザー名とパスワードだけを必要とする場合は、この関数を使用する必要はありません。Service Busは事前にサービス・アカウントからユーザー名とパスワードを取得し、必要に応じてHTTP認証ヘッダーにエンコードします(WS-Securityユーザー名トークンの場合も同様)。

関数には次の署名が含まれます。

fn-bea:lookupBasicCredentials( $service-account as xs:string ) as UsernamePasswordCredential

ここで、$service-accountは、次の形式のサービス・アカウントのパスと名前です。

project-name[/folder[...]]/service-account-name

戻り値は、次の形式のXML要素です。

<UsernamePasswordCredential
xmlns="http://www.bea.com/wli/sb/services/security/config">
<username>name</username>
<password>unencrypted-password</password>
</UsernamePasswordCredential>

返された要素をユーザー定義の変数に保管し、必要なときにこの変数からユーザー名とパスワード値を取得できます。

たとえば、Service Busプロジェクトには、myProjectという名前が付けられます。myServiceAccountという名前の静的なサービス・アカウントを、myFolder1/myFolder2という名前のフォルダに作成します。サービス・アカウントに、ユーザー名patとパスワードpatspasswordを保存します。

サービス・アカウントのユーザー名とパスワードを取得するには、次の関数を呼び出します。

fn-bea:lookupBasicCredentials( myProject/myFolder1/myFolder2/myServiceAccount )

関数は次の要素を返します。

<UsernamePasswordCredential
xmlns="http://www.bea.com/wli/sb/services/security/config">
<username>pat</username>
<password>patspassword</password>
</UsernamePasswordCredential>

19.6.2.2 fn-bea:isUserInGroup

特定のユーザーが特定のグループに所属するかどうかを返します(trueまたはfalse)。次に例を示します。

fn-bea:isUserInGroup($user-name as xs:string, $group-name as xs:string)

19.6.2.3 fn-bea:isUserInRole

特定のユーザーが特定のロールに所属するかどうかを返します(trueまたはfalse)。次に例を示します。

fn-bea:isUserInRole($user-name as xs:string, $role-name as xs:string)

19.6.2.4 fn-bea: uuid

関数fn-bea:uuidは、汎用一意識別子を返します。関数には次の署名が含まれます。

fn-bea:uuid() as xs:string

この関数をプロキシ・パイプラインで使用して、ユニークな識別子を生成できます。生成されたユニークな識別子を、要素としてXMLドキュメントに挿入できます。システム変数にユニークな識別子は生成できません。これを、メッセージ・ペイロードの変更に使用できます。

たとえば、トラッキング用にユニークな識別子を生成してメッセージに追加するとします。この関数を使用してユニークな識別子を生成できます。関数が返す文字列をSOAPヘッダーに追加できます。

19.6.2.5 fn-bea:execute-sql()

fn-bea:execute-sql()関数を使用すると、Service Busのメッセージ・フローでXQueryから低レベルのデータベースにアクセスできます。詳細は、「XQueryを使用したデータベースへのアクセス」を参照してください。問合せは、型付きデータを含むフラットな行要素のシーケンスを返します。

関数には次の署名が含まれます。

fn-bea:execute-sql( $datasource as xs:string, $rowElemName as xs:QName,
$sql as xs:string, $param1, ..., $paramk) as element()*

説明:

- $datasourceはデータソースのJNDI名。

- $rowElemNameは行要素の名前。$rowElemNameを、結果の要素シーケンスの各要素に付けるQNameとして指定します。

- $sqlはSQL文。

- $param1, ..., $paramkは1 - k個のパラメータ。

- element()*は返された要素のシーケンスを表します。

戻り値は、型付きデータを含むフラットな行要素のシーケンスで、SQL/JDBCデータ・モデルとXQueryデータ・モデル間で値を自動的に変換します。サポート対象のデータベースについてXQueryエンジンが生成する、またはサポートするデータ型マッピングの詳細は、「XQuery-SQLマッピング参照」を参照してください。

Service Busメッセージ・フローからfn-bea:execute-sql()関数を実行する場合、返された要素をユーザー定義の変数に格納できます。

次の例では、Service Busでのfn-bea:execute sql()関数の使用方法について説明します。

- 例1: 動的ルーティングのデータベースからのURIの取得

- 例2: データベースからのXMLTypeデータの取得

19.6.2.5.1 例1: 動的ルーティングのデータベースからのURIの取得

Service Busプロキシ・サービスでは、実行時のメッセージのルーティング(動的)先であるURIの仕様をサポートしています。詳細は、「動的ルーティングの使用」を参照してください。次の例は、動的ルーティング・シナリオでデータベースからURIを取得するfn-bea:execute-sql()関数の使用例を示しています。

例 - データベースからのビジネス・サービスのURIの取得

<ctx:route><ctx:service>
{
fn-bea:execute-sql(
'ds.myJDBCDataSource',
xs:QName('customer'),
'SELECT targetService FROM DISPATCH_MAPPING WHERE customer_priority=?',
xs:string($body/m:Request/m:customer_pri/text())
)/TARGETSERVICE/text()
}
</ctx:service></ctx:route>

この例では:

- ds.myJDBCDataSourceはデータ・ソースのJNDI名。

- xs:string($body/m:Request/m:customer_pri/text())は、リクエスト・メッセージを確認し、メッセージにcustomer_priの値を含むcustomer_priority=?を生成します。

- /TARGETSERVICE/text()はSQL文の結果に適用されるパス。返される要素の文字列(CDATA)コンテンツを生成します。

- <ctx:route><ctx:service> ... </ctx:service></ctx:route>は、動的ルーティング・シナリオのXQuery文に必須の要素。

- DISPATCH_MAPPINGの表定義を次に示します。

create table DISPATCH_MAPPING
(
customer_priority varchar2(256),
targetService varchar2(256),
soapPayload varchar2(1024)
);

DISPATCH_MAPPING表は、次の例で示すように移入されます。

例 - DISPATCH_MAPPING表

INSERT INTO DISPATCH_MAPPING (customer_priority, targetService, soapPayload)
VALUES ('0001', 'system/UCGetURI4DynamicRouting_proxy1', '<something/>');
INSERT INTO DISPATCH_MAPPING (customer_priority, targetService, soapPayload)
VALUES ('0002', 'system/UCGetURI4DynamicRouting_proxy2', '<something/>');

注意:

このシナリオでは、表の3列目(soapPayload)は使用しません。

例3のfn-bea:execute-sqlの実行

プロキシ・サービスが次の例のリクエスト・メッセージ(リクエスト・メッセージの<customer_pri>の値は0001)を受信した結果として、「データベースからのビジネス・サービスのURIの取得」の例のXQueryが実行された場合、動的ルーティング・シナリオで返されるURIは次のようになります。

system/UCGetURI4DynamicRouting_proxy1

リクエスト・メッセージの$bodyの例

<m:Request xmlns:m="http://www.bea.com/alsb/example">
<m:customer_pri>0001</m:customer_pri>
</m:Request>

19.6.2.5.2 例2: データベースからのXMLTypeデータの取得

サポート対象のデータベースについてXQueryエンジンが生成する、またはサポートするデータ型マッピングの詳細は、「XQuery-SQLマッピング参照」を参照してください。SQLのXMLType列タイプはサポートされていません。ただし、XMLTypeオブジェクトの getStringVal()メソッドを使用してXMLType列のデータにアクセスし、文字列値に変換できます。

次のシナリオでは、Oracle DatabaseのXMLType列からデータを選択する際に使用できる手順について説明します。

1. プロキシ・サービスのメッセージ・フローで割当てアクションを使用して、次のXQueryの結果を変数($result)に割り当てます。
例 - データベースからのXMLTypeデータの取得

fn-bea:execute-sql(
'ds.myJDBCDataSource',
'Rec',
'SELECT a.purchase_order.getStringVal() purchase_order from datatypes a'
)

説明:

- ds.myJDBCDataSourceはデータ・ソースのJNDI名。

- Recは$rowElemName。したがって、Recは結果の要素シーケンスの各要素に指定されたQNameです。

- select a.purchase_order.getStringVal() ...は、文字列値に変換するために、XMLTypeオブジェクトのgetStringVal()メソッドを使用するSQL文。

- datatypesは、XMLの値の読込み元である表(この場合、datatypes表には1つの行が含まれています)。

注意:

dataty.pes表の表定義を次に示します。

create table datatypes
(
purchase_order xmltype
);

2. 次の置換アクションを使用して、$bodyのノードのコンテンツを(前の手順で$resultに割り当てた)fn-bea:execute-sql()問合せの結果に置き換えます。

Replace [ node contents ] of [ undefined XPath ] in [ body ] with
[ $result/purchase_order/text() ]

次のサンプル・コードは、置換後の$bodyを示します。

注意:

datatypes表には、(発注書データを含む)行が1つ含まれています。この行には、次の例に示すXMLが含まれています。

例 - XMLコンテンツをfn-bea:execute-sql()の結果に置き換えた後の$body

<soap-env:Body>
<openuri:orders xmlns:openuri="http://openuri.com/">
<openuri:order>
<openuri:customerID>123</openuri:customerID>
<openuri:orderID>123A</openuri:orderID>
</openuri:order>
<openuri:order>
<openuri:customerID>345</openuri:customerID>
<openuri:orderID>345B</openuri:orderID>
</openuri:order>
<openuri:order>
<openuri:customerID>789</openuri:customerID>
<openuri:orderID>789C</openuri:orderID>
</openuri:order>
</openuri:orders>
</soap-env:Body>

19.6.2.6 fn-bea:serialize()

XMLドキュメントをXML要素としてではなく文字列として表す必要がある場合は、fn-bea:serialize()関数を使用します。たとえば、EJBインタフェースを介してXMLドキュメントを交換する場合、EJBメソッドは引数を文字列として受け取ります。関数には次の署名が含まれます。

fn-bea:serialize($input as item()) as xs:string

19.6.2.7 fn-bea:binary-to-text

fn-bea:binary-to-text関数はbinary-contentをテキストに変換します。

この関数には、fn-bea:binary-to-text($arg0-anyType, $arg1-string)という署名があります

19.6.2.8 fn-bea:binary-to-xml

fn-bea:binary-to-xml関数はbinary-contentをインラインXMLに変換します。

この関数には、fn-bea:binary-to-xml($arg-anyType)という署名があります

19.6.3 カスタムXPath関数の作成と使用

インラインXQuery式およびXQueryリソースの両方で、独自のカスタムXPath関数を作成および使用できます。詳細は、「カスタムXPath関数の作成」を参照してください。

20 XSLTでのデータの変換

この章では、eXtensible Stylesheet Language Transformation (XSLT)の概要と、Service BusサービスでXSLTを使用してXML入力をXML出力にマップする方法を説明します。また、Service Busプロジェクト内でXSLTマップを作成する方法についても説明します。

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

- XSLTの概要

- XSLTエディタおよびマッパー

- JDeveloperでのXSLTマッピングの作成

- Oracle Service BusコンソールでのXSLTリソースの操作

- Service BusコンソールでのXSLTマッパーの使用

- XSLTリソースの削除方法

JDeveloperでのXSLTマッパーの詳細は、Oracle SOA Suiteを使用したSOAアプリケーションの開発のXSLTマップ・エディタを使用した変換の作成に関する項を参照してください。

20.1 XSLTの概要

トランスフォーメーション・マップは、2つのデータ型の間のマッピングを記述したものです。eXtensible Stylesheet Language Transformation (XSLT)マップは、スキーマの異なるXMLドキュメント間のマッピングを記述したものです。Service BusでXSLTを使用すると、XMLドキュメントを処理して、ドキュメント・データをXMLスキーマから別のXMLスキーマに変換できます。これにより、異なるスキーマを使用するアプリケーション間でデータの交換が可能になります。XSLTを使用して、複雑なデータ操作と変換を実行できます。たとえば、受信する発注スキーマを、送信する請求書スキーマにマップできます。

20.2 XSLTエディタおよびマッパー

JDeveloperには、XQueryを使用した変換をスクリプト化できる式ビルダーと、複雑なマッピングを作成できるXSLTマッパーがあります。Oracle Service Busコンソールには、XQueryを使用した変換をスクリプト化できるエディタと、複雑なマッピングを作成できるXSLTマッパーがあります。これらのエディタには、XQuery式を定義したり、実行するXSLTリソースを指定したり、既存のXSLTリソースの名前として実行時に評価される式を定義したりするオプションが用意されています。JDeveloperおよびコンソールのいずれの場合も、パイプラインまたは分割-結合のいずれかのアクションからエディタにアクセスします。

20.2.1 JDeveloperのエディタおよびマッパー

JDeveloperのXSLTマッパーは、スキーマのルート要素、WSDLメッセージ・パート、またはWSDLメッセージの間のマッピングを定義できるグラフィカル・ツールです。スキーマのルート要素はXSDスキーマ・ファイルまたはWSDLファイルから取得できますが、直接マップできるのは、単一のメッセージ・パートを含むWSDLメッセージのみです。JDeveloperでXSLTマッピングを作成したら、マッパーで生成された.xslファイルをOracle Service BusコンソールのXSLTリソースにアップロードできます。

JDeveloperには様々な式ビルダーも用意されており、式を作成して、使用する既存のXSLTリソースを指定できます。JDeveloperのマッパーとエディタの詳細は、次のトピックを参照してください。

- Oracle SOA Suiteを使用したSOAアプリケーションの開発のXSLTマップ・エディタを使用した変換の作成に関する項

- Oracle SOA Suiteを使用したSOAアプリケーションの開発のOracle JDeveloperの式ビルダーを使用したXPath式の作成に関する項

20.2.2 Oracle Service Busコンソール・エディタおよびマッパー

Oracle Service Busコンソールで、XQuery/XSLT式エディタを使用して式を作成し、使用する既存のXSLTリソースを指定できます。XSLTリソースを参照するには、コンソールでリソースを作成し、既存のXSLT変換をリソースにアップロードするか、Service Busに含まれている新しいWebベースのXSLTマッパーを使用してXSL変換をしておく必要があります。この機能により、JDeveloperを使用して複雑なマッピングを作成してコンソールにインポートするか、Service Busコンソールを直接使用できます。XSL変換は複数のパイプラインおよび分割-結合で再利用できます。

Oracle Service Bus ConsoleのXQuery/XSLTエディタの詳細は、「Oracle Service Busコンソールでの式エディタの操作」を参照してください。

20.3 JDeveloperでのXSLTマッピングの作成

JDeveloperでService Busプロジェクト内にXSLTマッピングを作成し、パイプラインおよび分割-結合のXQuery式でそれらを使用して外部システム間でオブジェクトをマップできます。

20.3.1 JDeveloperでのXSLTマッピングの作成方法

XSLTマッピングを作成するには、ソースとターゲットのマッピングに使用する、ソースXMLスキーマ要素またはXMLファイルを選択する必要があります。

JDeveloperでXSLTマッピングを作成するには:

1. JDeveloperのアプリケーション・ナビゲータで、マッピングを作成するService Busプロジェクトまたはフォルダを右クリックします。

2. 表示されたメニューで、「新規」をポイントし、「XSLマップ」を選択します。
「XSLマップ・ファイルの作成」ダイアログが開きます。

3. 「ファイル名」フィールドに、XSLTマップ・ファイルの一意の名前を入力します。

4. 必要に応じて、新しいディレクトリの場所および相互参照のための簡単な説明を入力します。
この場所は、現在のアプリケーションのディレクトリ構造内である必要があります。

5. ソース・スキーマを定義するには、次のようにします。

a. 「ソース・スキーマの使用」を選択します。

b. 「プライマリ・ソース」フィールドの横にある「参照」をクリックします。

c. 「スキーマの選択」ダイアログで、XMLスキーマを使用するか、またはXMLファイルからソースを直接生成するかどうかを選択します。

d. 選択したセクションで「参照」をクリックし、使用するXMLスキーマ要素またはファイルに移動して選択します。
XMLスキーマ要素は現在のアプリケーションから選択できます。XMLファイルはファイル・システムから選択できます。

e. スキーマ要素またはファイルを選択したら、「スキーマの選択」ダイアログで「OK」をクリックします。

f. パラメータとして使用する追加のソースを選択するには、「その他のソース」表の上にある「スキーマの追加」をクリックします。

6. ターゲット・スキーマを定義するには、「ターゲット・スキーマの使用」を選択し、「スキーマの選択」ダイアログでの前述の手順を繰り返して、使用するXMLコンポーネントを選択します。

7. 「XSLマップ・ファイルの作成」ダイアログで「OK」をクリックします。
XSLTマッパーが表示され、ソースおよびターゲットの構造が示されます。

8. マッピング・ロジックを定義するには、Oracle SOA Suiteを使用したSOAアプリケーションの開発のマップ・モードでのXSLTマップの編集に関する項を参照してください。

20.4 Oracle Service BusコンソールでのXSLTリソースの操作

Oracle Service Busコンソールでは、XSLTマップはXSLTリソースに保存され、現在のセッションの任意のパイプラインおよび分割-結合で再利用できます。既存のXSLTマップをXSLTリソースにアップロードして、テキスト・エディタで編集できます。

- コンソールでのXSLTリソースの作成方法

- コンソールでのXSLTリソースの編集方法

20.4.1 コンソールでのXSLTリソースの作成方法

Service Busコンソールを使用している場合は、最初にJDeveloperで作成したXSL変換を追加し、Service Busプロジェクトにインポートするか、XSL変換リソースにアップロードできます。インポートの詳細は、「リソースおよび構成のインポートとエクスポート」を参照してください。また、コンソールに含まれているXSLTマッパーを使用して新しいマッピングを作成することもできます。次の手順を使用して、既存のマッピングをインポートしたり、コンソールを使用して新しいマッピングを作成したりするための新しいXSLTリソースを作成します。

始める前に

- JDeveloperで作成した既存のXSL変換マップをアップロードする必要がある場合は、「JDeveloperでのXSLTマッピングの作成」に示すとおり、XSL変換マッピング・ファイルを作成します。

- 新しいマッピングを作成する必要がある場合は、ソース・スキーマとターゲット・スキーマがService Busコンソールからアクセス可能になっていることを確認します。詳細は、「XMLスキーマの作成方法」を参照してください。

コンソールでXSLTリソースを作成するには:

1. プロジェクト・ナビゲータで、新しいXSL変換を含めるプロジェクトまたはフォルダを右クリックし、「作成」をポイントして「リソース」を選択します。「リソース・ギャラリ」から「変換」、「XSLT」、「OK」の順にクリックします。
「スキーマの作成」ダイアログが表示されます。

2. 次のいずれかを行います:

- 既存のXSLマッピング・ファイルからリソースを作成するには、「ファイルのアップロード」フィールドの横の「参照」をクリックし、JDeveloperで作成したファイルに移動して選択します。「マッピングの生成」オプションの選択を解除します。
「リソース名」フィールドに、ファイル拡張子なしのファイル名が自動的に移入されます。この名前は変更可能です。

- 新しいXSL変換を作成するには、その変換リソースの一意の名前を入力します。「マッピングの生成」オプションが選択されていることを確認します。

3. 必要に応じて、リソースの簡単な説明を入力します。

4. 「作成」をクリックします。

5. 新しいマッピングを作成している場合、次の情報を「ソースとターゲットの選択」ダイアログに入力します。

a. ソースおよびターゲット・スキーマは、「ソース・スキーマ」フィールドおよび「ターゲット・スキーマ」フィールドの「検索」アイコンを使用して検索および選択します。これらのスキーマは、Service Busコンソールからアクセス可能にしておく必要があります。詳細は、「XMLスキーマの作成方法」を参照してください。

b. 「ソースのルート要素」リストから、マッピング用のソースのルート要素を選択します。このリストは「ソース・スキーマ」を選択した後に移入されます。

c. 「ターゲットのルート要素」リストから、マッピング用のターゲットのルート要素を選択します。このリストは「ターゲット・スキーマ」を選択した後に移入されます。

d. 「OK」をクリックします。
XSLTパラメータが定義されている場合、それがXSLT定義エディタに表示されます。

6. スキーマを変更するには、次のように実行します。

a. ツールバーの「ソースの編集」をクリックします。
「ソースの編集」ダイアログが表示されます。

b. アップロードする新しいマッピング・ファイルを参照して選択するには、「参照」をクリックします。

c. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

d. 「保存」をクリックします。

7. 新しいマッピングを作成している場合、マッパーの使用の詳細は、「Service BusコンソールでのXSLTマッパーの使用」を参照してください。

8. XSLT定義エディタのツールバーで、「保存」をクリックします。

9. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

20.4.2 コンソールでのXSLTリソースの編集およびXSL変換のアップロード方法

Oracle Service Busコンソールでは、XSLTリソースを直接編集することも、新規または更新済ファイルをアップロードすることでコンテンツを更新することもできます。

コンソールでXSL変換を編集するには:

1. プロジェクト・ナビゲータで、編集するXSL変換が含まれているプロジェクトおよびフォルダを開きます。

2. XSL変換の名前を右クリックし、「開く」を選択します。

3. ツールバーの「ソースの編集」をクリックします。

「ソースの編集」ダイアログが表示されます。

4. アップロードする新しいXSL変換ファイルを参照して選択するには、「参照」をクリックします。

5. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

6. 「保存」をクリックします。

7. XSLT定義エディタのツールバーで、「保存」をクリックします。

8. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

20.5 Service BusコンソールでのXSLTマッパーの使用

次のトピックでは、Service BusコンソールでのXSLTマッパーの使用について説明します。

トピック

- Service BusコンソールでXSLTマッパーを開く方法

- Oracle Mapperの使用

20.5.1 Service BusコンソールでXSLTマッパーを開く方法

XSLT定義エディタから、XSLTマッパーにアクセスします。

Service BusコンソールからXSLTマッパーを開くには、次の図に示すように、「ツール」アイコンをクリックし、次に「マッパーの起動」をクリックします。

注意:

マッピングは、セッションの編集時にのみ編集できます。アクティブ・セッションでない状態でマッパーを起動すると、マッパーは読取り専用モードで開きます。読取り専用モードでは、マッピングに変更を加えられません。

XSLTマッパーが新しいウィンドウで起動します。

20.5.2 Oracle Mapperの使用

XSLTマッパーのトピックは、「Oracleマッパーの使用」に記載されています。

20.6 XSLTリソースの削除方法

削除するXSLTリソースを参照しているリソースがある場合は、それらの参照を削除してからリソースを削除します。Oracle Service BusコンソールのXSLT定義エディタでXSLTリソースを開き、右上の「ツール」アイコンをクリックし、「参照」を選択してそこに参照があるかどうかを確認します。JDeveloperでは、XSLTリソースを右クリックして、「依存性の参照」を選択します。

変換は他のリソースによって参照されていても削除できますが、その場合、削除されたリソースへの未解決の参照が原因で、競合が発生する可能性があります。

XSLTリソースを削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するXSL変換が含まれているプロジェクトおよびフォルダを開きます。

2. 変換の名前を右クリックし、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに変換のための参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

21 相互参照でのデータのマッピング

この章では、相互参照の概要と、Service Busサービスでそれらを使用して外部システム間で同様のオブジェクトの識別子をマップする方法について説明します。また、Service Busプロジェクト内で相互参照を作成する方法についても説明します。

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

- 相互参照の概要

- JDeveloperでの相互参照表の作成

- Oracle Service Busコンソールでの相互参照リソースの操作

- 相互参照リソースの削除

- Oracle Service Busでの相互参照表への移入

相互参照の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の相互参照の操作に関する項を参照してください。

21.1 相互参照の概要

相互参照表は、複数のアプリケーションにわたる同等のオブジェクトを表す識別子をマップし、異なる外部アプリケーションで作成された同様のオブジェクトを関連付けます。たとえば、相互参照を使用して、複数の顧客管理システムで作成されたレコードの顧客IDをマップできます。相互参照はドメイン値マップ(DVM)と似ていますが、相互参照は実行中に更新できるため、システム間で値を動的に統合できます。実行時に更新された相互参照データは、データベースに保持されます。

相互参照は、複数のOracle SOA Suiteコンポーネント間で使用できます。Service Busでは、JDeveloperとOracle Service Busコンソールの両方で相互参照表を作成できます。

21.1.1 相互参照データベース表

すべての相互参照マッピングは、表の形式で格納されます。JDeveloperでService Busプロジェクトの相互参照表を作成する場合、表のメタデータ(つまり、値ではなくキー)のみを定義します。相互参照表はすべてデータベース(デフォルトではXREF_DATA表)に格納されます。相互参照表は、カスタムにすることも汎用(デフォルト)にすることもできます。汎用表は、インストール中に作成される単一のデータベース表にすべて格納されます(XREF_DATA)。カスタム表はそれぞれ、作成した個別のデータベース表に格納されます。Service Busは、標準SOA Suiteデータ・ソースjdbc/SOADataSourceを使用してデータベース表にアクセスします。次の要件で独自のデータ・ソースを作成できます。

- データ・ソースにはjdbc/xrefという名前を付ける必要があり、それ以外の場合、ランタイムによってデフォルト・スキーマが使用されます。

- データ・ソースはXAが有効化されている必要があります。

カスタム・データベース表の作成手順は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のカスタム・データベース表の作成方法に関する項を参照してください。

21.1.2 相互参照関数

Service Busメッセージ・フローでは、一連のXRef関数を使用して、XQuery式およびXSLT変換から相互参照表を参照し、受信メッセージ内の情報に基づいて実行時に相互参照エントリをルックアップ、移入および更新できます。これらの関数を使用して、相互参照表を最初に作成したときに定義したキーの値を移入します。

JDeveloper内のXRef関数には、XSLTマッパー、XQuery Mapperおよび式エディタからアクセスできます。Oracle Service Busコンソールでは、これらの関数には式および条件の各エディタから使用できます。Service Bus XRef関数の詳細は、「相互参照関数」を参照してください。

21.1.3 実行時の相互参照データの管理

Fusion Middleware Controlは、実行時の相互参照データの管理に役立つ機能を提供します。詳細および手順は、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理の相互参照の管理に関する項を参照してください。

21.2 JDeveloperでの相互参照表の作成

JDeveloperでService Busプロジェクト内に相互参照表を作成し、パイプラインおよび分割-結合のXQuery式でそれらを使用して外部システム間でオブジェクトをマップできます。

21.2.1 JDeveloperでの相互参照表の作成方法

相互参照表を作成するときは、表の名前と、データを共有するエンド・システムの名前を指定することのみが必要です。設計時に各システムの値を指定する必要はありません。

JDeveloperで相互参照表を作成するには:

1. JDeveloperのアプリケーション・ナビゲータで、相互参照を作成するService Busプロジェクトまたはフォルダを右クリックします。

2. 表示されたメニューで、「新規」をポイントし、「相互参照(XREF)」を選択します。

「相互参照(XREF)の作成」ダイアログが表示されます。

3. 「ファイル名」フィールドに、相互参照ファイルの一意の名前を入力します。

相互参照リポジトリで2つの相互参照表に同じ名前を指定することはできません。ファイル名は、.xref拡張子が付いた相互参照表の名前です。

4. 必要に応じて、新しいディレクトリの場所および相互参照のための簡単な説明を入力します。

この場所は、現在のアプリケーションのディレクトリ構造内である必要があります。

5. 「エンド・システム」フィールドに、最大2つのエンド・システムの名前を入力します。

エンド・システムを相互参照表の相互参照列にマップします。相互参照表の作成後に、システム名を追加できます。それぞれの名前は表の中で一意である必要があります。

6. 「OK」をクリックします。

相互参照エディタに新規相互参照表が表示されます。

7. 相互参照表に新規エンド・システムを追加するには、「エンド・システム」表の上にある「追加」をクリックし、新しく追加された行をダブルクリックして、エンド・システムの名前を入力します。

8. この相互参照マッピングのためのカスタム・データベース表を作成するには、『Oracle SOA SuiteでのSOAアプリケーションの開発』のカスタム・データベース表の作成方法に関する項を参照してください。

21.3 Oracle Service Busコンソールでの相互参照リソースの操作

Oracle Service Busコンソールを使用している場合、新しい相互参照表を作成するか、最初にJDeveloperで作成した相互参照表を相互参照(XRef)リソースにアップロードできます。

- コンソールでの相互参照(XRef)リソースの作成方法

- コンソールでの相互参照リソースの編集方法

- コンソールでのカスタム・データベース表の作成方法

21.3.1 コンソールでの相互参照(XRef)リソースの作成方法

相互参照表を作成するときは、表の名前と、データを共有するエンド・システムの名前を指定することのみが必要です。設計時に各システムの値を指定する必要はありません。

始める前に

「JDeveloperでの相互参照表の作成」に従って、JDeveloperですでに作成済の相互参照ファイルをアップロードする場合は、そのファイルがシステムで使用可能であることを確認してください。

コンソールで相互参照リソースを作成するには:

1. プロジェクト・ナビゲータで、新しい相互参照マッピングを含めるプロジェクトまたはフォルダを右クリックし、「作成」をポイントして「リソース」を選択します。「その他」をクリックし、「相互参照(XRef)」、「OK」の順にクリックします。

相互参照(XRef)の作成ダイアログが表示されます。

2. 次のいずれかを行います:

- 既存の相互参照表をアップロードするには、「ファイルのアップロード」フィールドの横の「参照」をクリックし、JDeveloperで作成したファイルに移動して選択します。
「リソース名」フィールドに、ファイル拡張子なしのファイル名が自動的に移入されます。この名前は変更可能です。

- 新しい相互参照表を作成するには、その相互参照リソースの一意の名前を入力します。

3. 必要に応じて、リソースの簡単な説明を入力します。

4. 「作成」をクリックします。

相互参照(XREF)定義エディタに新しい相互参照表が表示されます。

5. 相互参照(XREF)定義エディタのツールバーで、「保存」をクリックします。

6. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

21.3.2 コンソールでの相互参照リソースの編集方法

Oracle Service Busコンソールを使用している場合、次の手順を使用して相互参照リソースを編集します。

コンソールで相互参照リソースを編集するには:

1. プロジェクト・ナビゲータで、編集する相互参照が含まれているプロジェクトおよびフォルダを開きます。

2. 相互参照の名前を右クリックし、「開く」を選択します。

3. ソース・ファイルを変更するには、次のように実行します。

a. ツールバーの「ソースの編集」をクリックします。
「ソースの編集」ダイアログが表示されます。

b. アップロードする新しい相互参照ファイルを参照して選択するには、「参照」をクリックします。

c. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

d. 「保存」をクリックします。

4. 相互参照表にエンド・システムを追加するには、「エンド・システム」表の上にある「追加」をクリックし、表示される新しい行にシステムの名前を入力します。

5. 相互参照(XREF)定義エディタのツールバーで、「保存」をクリックします。

6. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

21.3.3 コンソールでのカスタム・データベース表の作成方法

前述したように、すべての実行時データはデフォルトでXREF_DATA表に格納されます。カスタム・データベース表を作成する場合は、次の手順を実行します。

注意:

JDeveloperで相互参照表を作成する場合は、相互参照エディタからカスタム・データベース作成スクリプトを直接実行できます。Oracle Service Busコンソールを使用する場合は、カスタム・データベース表を手動で作成します。詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のカスタム・データベース表の作成方法に関する項を参照してください。

コンソールでカスタム・データベース表を作成するには:

1. 相互参照(XRef)定義エディタで、「最適化の有効化」を選択します。

2. 「表名」フィールドに、データベース表のカスタム名を入力します。

このカスタム・データベース表名には、xref_という接頭辞を付け、XREF_DATAやXREF_DELETED_DATAにはできません。

3. 「保存」をクリックします。

4. 次の構文を使用してOracle Fusion Middlewareデータベースのsoainfraスキーマでカスタム表を作成します。

CREATE TABLE TABLE_NAME (
ROW_ID VARCHAR2(48) NOT NULL,
SYSTEM1 VARCHAR2(100),
SYSTEM2 VARCHAR2(100),
SYSTEM3 VARCHAR2(100),
LAST_MODIFIED TIMESTAMP NOT NULL
);

ここでTABLE_NAMEは、カスタム表に対して手順2で指定した名前であり、SYSTEM1、SYSTEM2およびSYSTEM3は、相互参照されるエンド・システムの名前です。

21.4 相互参照リソースの削除

削除するリソースを参照しているリソースがある場合、そのリソースを削除する前にそれらの参照を削除します。リソースは他のリソースによって参照されていても削除できますが、その場合、削除されたリソースへの未解決の参照が原因で、競合が発生する可能性があります。

21.4.1 相互参照リソースの削除方法

相互参照を削除する前に、参照および依存性を確認してください。Oracle Service Busコンソールの相互参照(XREF)定義エディタで相互参照リソースを開き、右上の「ツール」アイコンをクリックし、「参照」を選択してそこに参照があるかどうかを確認します。JDeveloperでは、XQueryリソースを右クリックして、「依存性の参照」を選択します。

相互参照リソースを削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するリソースが含まれているプロジェクトおよびフォルダを開きます。

2. リソースの名前を右クリックし、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに変換のための参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

21.5 Oracle Service Busでの相互参照表への移入

相互参照を使用して特定の値をルックアップする前に、実行時にそれに移入する必要があります。Service Busで提供されている相互参照XPath関数を使用して相互参照表に移入します。XPath関数により、相互参照列に移入し、ルックアップを実行し、列値を削除できます。これらのXPath関数は、式ビルダーで使用して式を作成したり、XSLTマッパーで使用して変換を作成できます。「式ビルダー」ダイアログには、いくつかのパイプライン・アクティビティおよび分割-結合操作からアクセスできます。

Service Busによって提供されるXRef関数の詳細は、「相互参照関数」を参照してください。Oracle Service Bus Console式エディタおよび条件エディタの一般情報と手順については、「エディタ・ワークスペースのテキスト・フィールドでの式の構築」を参照してください。

JDeveloperでの相互参照データの管理の詳細、例および手順は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の次のトピックを参照してください。これらのトピックの情報は、Oracle Service Busコンソールで作業する場合にも役立ちます。

- 相互参照表への移入に関する項

- 相互参照表のルックアップに関する項

- 相互参照表値の削除に関する項

22 ドメイン値マップでのデータのマッピング

この章では、ドメイン値マップの概要と、Service Busサービスでそれらを使用して、様々なドメインによって使用される用語を関連付けてオブジェクトのように記述する方法について説明します。また、Service Busプロジェクト内でドメイン値マップを作成する方法についても説明します。

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

- ドメイン値マップの概要

- JDeveloperでのドメイン値マップの作成

- Oracle Service BusコンソールでのDVMリソースの操作

- ドメイン値マップの削除

- 式および条件でのドメイン値マップの使用方法

ドメイン値マップの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のドメイン値マップの操作に関する項を参照してください。

22.1 ドメイン値マップの概要

ドメイン値マップによって、特定のフィールドに対して1つのドメインで使用される値が、その同じフィールドに対して他のドメインで使用される値に関連付けられ、複数のボキャブラリまたはシステム間での値のマッピングが可能になります。たとえば、国コード、市区町村コード、通貨コードなどをマップできます。マッピングが必要なフィールドの数に応じて、1つのService Busプロジェクトで複数のドメイン値マップを使用できます。ドメイン値マップは、相互参照に似ていますが、それらは静的定義に基づいています。ドメイン値マップは、デザインタイムに作成して移入し、ランタイムにデプロイします。ドメイン値マップ・データは相互参照のように実行時アクティビティによって変更されることはなく、ドメイン値マップはルックアップのためのみに使用されます。

ドメイン値マップは、複数のOracle SOA Suiteコンポーネント間で使用できます。Service Busでは、JDeveloperとOracle Service Busコンソールの両方でドメイン値マップを作成できます。

22.1.1 ドメイン値マップ関数

Service Busメッセージ・フローでは、一連のDVM関数を使用して、XQuery式およびXSLT変換からドメイン値マップを参照し、受信メッセージ内の情報に基づいて実行時に値をルックアップできます。これらの関数を使用することで、Service Busは1つのシステムから受信するデータを別のシステムに送信されるデータにマップする方法を認識します。

JDeveloper内のDVM関数には、XSLTマッパー、XQuery Mapperおよび式エディタからアクセスできます。Oracle Service Busコンソールでは、これらの関数には式および条件の各エディタから使用できます。Service Bus DVM関数の詳細は、「ドメイン値マップ関数」を参照してください。

22.2 JDeveloperでのドメイン値マップの作成

JDeveloperでService Busプロジェクト内にドメイン値マップを作成し、パイプラインおよび分割-結合のXQuery式でそれらを使用して外部システム間でオブジェクトをマップできます。ドメイン値マップは通常、1つのフィールドのみに対してマッピングを定義するため、パイプラインまたは分割-結合では複数のドメイン値マップを参照できます。

22.2.1 JDeveloperでのドメイン値マップの作成方法

JDeveloperの「ドメイン値マップ(DVM)・ファイルの作成」ダイアログを使用してドメイン値マップを作成および構成します。このダイアログでは、それぞれ1つの値を持つ2つのドメインを定義します。完了すると、ドメイン値マップ・エディタが表示され、追加のドメインおよび対応する値を定義できます。

ドメイン値マップを作成するときは、マップ対象の値を持つ最大2つのドメインの名前を、各ドメインの値とともに指定できます。マップを作成した後、ドメインおよび値を追加できます。

JDeveloperでドメイン値マップを作成するには:

1. アプリケーション・ナビゲータで、ドメイン値マップを作成するプロジェクトを右クリックし、「新規」をポイントして「ドメイン値マップ(DVM)」を選択します。

「ドメイン値マップ(DVM)・ファイルの作成」ダイアログが表示されます。

2. 「ファイル名」フィールドに、ドメイン値マップ・ファイルの一意かつ説明的な名前を入力します。ファイル名には.dvm拡張子を付ける必要があります。

3. 必要に応じて、新しいディレクトリの場所および相互参照のための簡単な説明を入力します。

この場所は、現在のアプリケーションのディレクトリ構造内である必要があります。

4. 「ドメイン名」フィールドに、最大2つのドメインに対する名前を入力します。

これらは、ドメイン値マップの列名であり、それぞれ異なるドメイン内の同じフィールドを表します。

注意:

ドメイン名は、タイプNCName (non-colonized name、コロンを含まない有効なXML要素名)である必要があります。各ドメイン名は、ドメイン値マップ内で一意である必要があります。後で、さらにドメインを追加できます。

5. 「ドメイン値」フィールドに、各ドメインに対応する値を入力します。

6. 「OK」をクリックします。

ドメイン値マップ・エディタに新しいドメイン値マップが表示されます。

7. 新しいドメインをドメイン値マップに追加するには、『Oracle SOA SuiteでのSOAアプリケーションの開発』のドメイン値マップへのドメインの追加方法に関する項を参照してください。

8. 新しい値をドメイン値マップに追加するには、『Oracle SOA SuiteでのSOAアプリケーションの開発』のドメイン値マップへのドメイン値の追加方法に関する項を参照してください。

22.3 Oracle Service BusコンソールでのDVMリソースの操作

Oracle Service Busコンソールを使用している場合、新しいドメイン値マップを作成するか、最初にJDeveloperで作成したドメイン値マップをDVMリソースにアップロードできます。

- コンソールでのDVMリソースの作成方法

- ドメイン値マップへのドメインの追加方法

- ドメイン値マップへのドメイン値の追加方法

- コンソールでのドメイン値マップの編集方法

22.3.1 コンソールでのDVMリソースの作成方法

DVMを作成するときは、ドメイン値マップの対象となるフィールドの対応する値とともにデータを共有する最大2つのエンド・システムの名前を定義します。マップを作成した後、DVM定義エディタで追加のドメインおよび値を定義できます。

始める前に

「JDeveloperでのドメイン値マップの作成」に従って、JDeveloperですでに作成済のドメイン値マップ・ファイルをアップロードする場合は、そのファイルがシステムで使用可能であることを確認してください。

コンソールでDVMリソースを作成するには:

1. プロジェクト・ナビゲータでは、プロジェクトまたはフォルダを右クリックして新しいドメイン値マップを含め、「作成」をポイントし、「リソース」を選択します。「その他」、「DVM」をクリックし、次に「OK」をクリックします。

DVMの作成ダイアログが表示されます。

2. 次のいずれかを行います:

- 既存のドメイン値マップ・ファイルをアップロードするには、「ファイルのアップロード」フィールドの横の「参照」をクリックし、JDeveloperで作成したファイルに移動して選択します。
「リソース名」フィールドに、ファイル拡張子なしのファイル名が自動的に移入されます。この名前は変更可能です。

- 新しいドメイン値マップを作成するには、そのDVMリソースの一意の名前を入力します。

3. 必要に応じて、リソースの簡単な説明を入力します。

4. 「作成」をクリックします。

新しいドメイン値マップがDVM定義エディタに表示されます。

5. DVM定義エディタのツールバーで、「保存」をクリックします。

6. 次の手順を実行することで、ドメインおよび値を構成します。

- ドメイン値マップへのドメインの追加方法

- ドメイン値マップへのドメイン値の追加方法

22.3.2 ドメイン値マップへのドメインの追加方法

マップへの追加ドメインを定義でき、それらはドメイン値マップに列として表されます。新しいドメインそれぞれには、実行時のルックアップに含めるため、またはマッピングを修飾するためのみに使用される値を含めることができます。ドメイン名は、タイプNCName (non-colonized name、コロンを含まない有効なXML要素名)である必要があります。

ドメイン値マップにドメインを追加するには:

1. DVMリソースを開いていない場合は、プロジェクト・ナビゲータでDVMリソースを見つけ、その名前をクリックします。

2. 「マップ表」で、「追加」をクリックし、「ドメインの追加」を選択します。

「ドメインの追加」ダイアログが表示されます。

3. 「名前」フィールドに、ドメインの名前を入力します。

4. この列を修飾子列として設定するには、「ルックアップのための修飾子の有効化」を選択します。

ヒント:

修飾子ドメインまたは修飾子順の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の修飾子ドメインに関する項および修飾子階層に関する項を参照してください。

5. 「ルックアップ順序」フィールドに、修飾子ドメインの優先順位を示す数字を入力します。

このフィールドは、「ルックアップのための修飾子の有効化」を選択した場合にのみ有効です。

6. 「追加」をクリックします。

7. 新しいドメインの値を定義するには、「ドメイン値マップへのドメイン値の追加方法」に進みます。

22.3.3 ドメイン値マップへのドメイン値の追加方法

ドメイン値はドメイン値マップの行に表示され、各行には、各ドメインにマッピングされる値が含まれます。ドメイン間のマッピングを完全に定義するために必要な数のドメイン値を追加できます。

ドメイン値マップにドメイン値を追加するには:

1. DVMリソースを開いていない場合は、プロジェクト・ナビゲータでDVMリソースを見つけ、その名前をクリックします。

2. 「マップ表」で、「追加」をクリックし、「ドメイン値の追加」を選択します。

「マップ表」の既存の行の下に新しい行が表示されます。

3. 新しい行で、各ドメインの値を入力します。

4. 前述の手順を繰り返し、追加の値をすべて作成します。

5. DVM定義エディタのツールバーで、「保存」をクリックします。

6. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

22.3.4 コンソールでのドメイン値マップの編集方法

Oracle Service Busコンソールを使用している場合、次の手順を使用して既存のドメイン値マップを変更します。

コンソールでドメイン値マップを編集するには:

1. プロジェクト・ナビゲータで、編集するドメイン値マップが含まれているプロジェクトおよびフォルダを開きます。

2. DVMリソース名をクリックします。

3. ソース・ファイルを変更するには、次のように実行します。

a. ツールバーの「ソースの編集」をクリックします。
「ソースの編集」ダイアログが表示されます。

b. アップロードする新しい相互参照ファイルを参照して選択するには、「参照」をクリックします。

c. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

d. 「保存」をクリックします。

4. マップにドメインを追加するには、「ドメイン値マップへのドメインの追加方法」を参照してください。

5. ドメイン値を追加するには、「ドメイン値マップへのドメイン値の追加方法」を参照してください。

6. ドメインを編集するには、「マップ表」でドメインを選択し、「編集」をクリックします。「ドメインの更新」ダイアログで、「ドメイン値マップへのドメインの追加方法」に記載されている変更を実行します。

7. 値を変更するには、「マップ表」で値名をダブルクリックし、新しい値を入力します。

8. DVM定義エディタのツールバーで、「保存」をクリックします。

9. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

22.4 ドメイン値マップの削除

削除するリソースを参照しているリソースがある場合、そのリソースを削除する前にそれらの参照を削除します。リソースは他のリソースによって参照されていても削除できますが、その場合、削除されたリソースへの未解決の参照が原因で、競合が発生する可能性があります。

22.4.1 ドメイン値マップの削除方法

ドメイン値マップを削除する前に、リソースまたは依存性を確認します。Oracle Service Busコンソールの場合、DVM定義エディタでDVMを開き、右上にある「ツール」をクリックして「参照」を選択し、サービスで参照を使用しているかどうかを調べます。JDeveloperでは、DVMを右クリックして、「依存性の参照」を選択します。

DVMリソースを削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するリソースが含まれているプロジェクトおよびフォルダを開きます。

2. リソースの名前を右クリックし、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに変換のための参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

22.5 式および条件でのドメイン値マップの使用方法

Service Busで提供されているDVM XPath関数を使用して、実行時に行われるドメイン値ルックアップを定義します。XPath関数によって、単一値または複数値のいずれに対しても様々な方法でルックアップを実行できます。これらのXPath関数は、式ビルダーで使用して式を作成したり、XSLTマッパーで使用して変換を作成できます。「式ビルダー」ダイアログには、いくつかのパイプライン・アクティビティおよび分割-結合操作からアクセスできます。

Service Busによって提供されるDVM関数の詳細は、「ドメイン値マップ関数」を参照してください。Oracle Service Bus Console式エディタおよび条件エディタの一般情報と手順については、「エディタ・ワークスペースのテキスト・フィールドでの式の構築」を参照してください。

JDeveloperでのDVM関数の使用の詳細、例および手順は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のドメイン値マップ関数の使用方法に関する項を参照してください。この情報は、Oracle Service Busコンソールを使用する場合にも役立ちます。

23 Message Format Languageを使用したデータ構造の定義

この章では、JDeveloperでMFL構造を定義するための手順を説明します (MFL構造は、XML形式と非XML形式の間でデータを自動的に変換するためにXQuery Mapperツールで使用できます)。また、Oracle Service BusコンソールでプロジェクトにMFLリソースを追加する方法についても説明します。

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

- Format Builderの概要

- Oracle Service BusコンソールでのMFLリソースの操作

- MFLメッセージ構造の作成

- MFLメッセージ構造の構成

- メタデータのインポートと変換

- MFLリソースの削除

- フォーマット定義のテスト

- パレットの使用

- Format Builderのサポート対象のデータ型

- Format Builderのフィールド参照

23.1 Format Builderの概要

Format Builderツールは、非XMLデータ・レコードの記述を作成するのに役立ちます。これにより、非XMLデータのレイアウトと階層を記述して、XMLと相互に変換できるようになります。また、バイト・シーケンスをフィールドとして記述できます。各フィールドには、データ型(浮動小数点、文字列など)、データ・サイズ、フィールド名の記述を含めます。Format Builderではさらに、フィールドのグループ化(グループ)、フィールドやグループの繰り返し、および集約を定義できます。

23.1.1 MFLファイルについて

Format Builderで作成した記述は、Message Format Language (MFL)と呼ばれるXML文法で保存されます。MFLドキュメントは、非XMLデータ・レコードのインスタンスをXMLドキュメントのインスタンス(またはその逆)に変換するために実行時に使用されます。MFL(メッセージ・フォーマット言語)ドキュメントは、バイナリ・データのレイアウトの記述に使用する特殊なXMLドキュメントです。これは、フォーマットされたバイナリ・データをXMLデータに変換するルールの定義に使用できるOracle独自の言語です。MFLドキュメントはmfl.dtdに準拠し、データの各フィールドに加え、フィールドのグループ化(グループ)、繰返し、および集約を記述する要素および属性を含みます。

メッセージ・サービス・タイプのビジネス・サービスやプロキシ・サービスを作成するとき、サービスのリクエスト・メッセージ・タイプまたはレスポンス・メッセージ・タイプとしてMFLタイプを選択できます。

23.1.2 フォーマット、フィールドおよびグループの有効な名前

メッセージ・フォーマット、フィールド、およびグループは、名前によって識別されます。この名前は、非XMLデータがXMLに変換されるときにXMLタグとして使用されます。そのため、名前はXMLの命名規則に準拠する必要があります。

次に名前フォーマットのガイドラインを示します。

- 先頭は文字またはアンダースコアでなければなりません。

- 文字、数字、コロン、ピリオド記号、ハイフン記号、およびアンダースコア記号を使用できます。

次に有効な名前の例を示します。

MyField
MyField1
MyField_again
MyField-again

次に無効な名前の例を示します。

1MyField - 先頭に数字を使用できません。

My>Field - 不等号(>)は無効な文字です。

My Field - スペースは使用できません。

My/Field - バック・スラッシュ(/)は無効な文字です。

My\Field - フォワード・スラッシュ(\)は無効な文字です。

My:Field - セミコロン(;)は無効な文字です。

23.1.3 サポートされる文字デリミタ

Format Builderで正しい構文を入力して、デリミタを指定できます。たとえば、タブ文字(\u009)をデリミタとして指定する場合、これに一致する構文\tを入力します。

表23-1 文字デリミタ

構文

一致

x

文字x

\\

バックスラッシュ

\0n

8進値0n (<= n <= 7)を含む文字

\0nn

8進値0nn (0 <= n <= 7)を含む文字

\0mnn

8進値0mnn (0 <= m <= 3、0 <= n <= 7)を含む文字

\xhh

16進値0xhhを含む文字

\uhhhh

16進値0xhhhhを含む文字

\xff

ファイルの終わり(EOF)文字

\t

タブ文字(\u0009)

\n

改行(ライン・フィード)文字(\u000A)

\r

キャリッジ・リターン文字(\u000D)

\f

改ページ文字(\u000C)

\a

アラート(ベル)文字(\u0007)

\e

エスケープ文字(\u001B)

\cx

xに対応する制御文字

詳細は、http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.htmlを参照してください。

23.2 Oracle Service BusコンソールでのMFLリソースの操作

JDeveloperでFormat Builderを使用してバイナリ・レコードの階層構造、フィールドのレイアウト、フィールドとグループのグループ化を定義すると、この情報は、実行時変換を実行するために使用できるMFLドキュメントとして保存されます。Format BuilderでMFLドキュメントを使用して、それに対応するDTDを生成することもできます。

23.2.1 コンソールでのMFLリソースの作成方法

JDeveloperのFormat Builderを使用してメッセージ・フォーマットを定義します。Oracle Service Busコンソールを使用している場合、MFLリソースを作成して、JDeveloperですでに作成済のMFLファイルをアップロードできます。MFLリソースはコンソールにインポートすることもできます。詳細は、「リソースおよび構成のインポートとエクスポート」を参照してください。次の手順を使用して、MFLファイルをMFLリソースにアップロードします。

始める前に

「MFLメッセージ構造の作成」に従って、JDeveloperのFormat BuilderでMFLファイルを作成します。

コンソールでMFLリソースを追加するには:

1. プロジェクト・ナビゲータで、新しいMFLファイルを含めるプロジェクトまたはフォルダを右クリックし、「作成」をポイントして「リソース」を選択します。「変換」をクリックし、「MFL」、「OK」の順にクリックします。
「MFLの作成」ダイアログが表示されます。

2. 「ファイルのアップロード」フィールドの横の「参照」をクリックし、JDeveloperで作成したMFLファイルに移動してこれを選択します。
「リソース名」フィールドに、ファイル拡張子なしのファイル名が自動的に移入されます。この名前は変更可能です。

3. 必要に応じて、リソースの簡単な説明を入力します。

4. 「作成」をクリックします。
MFL定義エディタにMFLファイルのテストが表示されます。

5. スキーマを変更するには、次のように実行します。

a. ツールバーの「ソースの編集」をクリックします。
「ソースの編集」ダイアログが表示されます。

b. アップロードする新しいMFLファイルを参照して選択するには、「参照」をクリックします。

c. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

d. 「保存」をクリックします。

6. MFL定義エディタのツールバーで、「保存」をクリックします。

7. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

23.2.2 コンソールでのMFLリソースの編集方法

MFLファイルを変更するには、JDeveloperのFormat Builderを使用することをお薦めします。Format Builderでの操作方法の詳細は、「MFLメッセージ構造の作成」を参照してください。

Oracle Service Busコンソールを使用している場合は、JDeveloperから更新済ファイルをアップロードするか、コンソールでコードを直接変更(お薦めしません)できます。

コンソールでMFLリソースを更新するには:

1. プロジェクト・ナビゲータで、編集するMFLリソースが含まれているプロジェクトおよびフォルダを開きます。

2. リソース名を右クリックし、「開く」を選択します。

3. ツールバーの「ソースの編集」をクリックします。

「ソースの編集」ダイアログが表示されます。

4. アップロードする新規または更新済MFLファイルを参照して選択するには、「参照」をクリックします。

5. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

6. 「保存」をクリックします。

7. MFL定義エディタのツールバーで、「保存」をクリックします。

8. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

23.3 MFLメッセージ構造の作成

MFLメッセージ構造には、1つ以上のフィールド、フィールド・グループ、参照およびコメントを含めることができます。

- Format Builderでのドラッグ・アンド・ドロップの使用

- JDeveloperでのMFLファイルの作成方法

- グループを作成する方法

- フィールドの作成方法

- グループまたはフィールドの参照方法

- コメントの追加方法

23.3.1 Format Builderでのドラッグ・アンド・ドロップの使用

Format Builderのドラッグ・アンド・ドロップ機能を使用して、ツリー・ビューの項目をコピーまたは移動できます。項目を移動するには、項目を新しい場所にドラッグ・アンド・ドロップするだけです。項目をコピーするには、[CTRL]キーを押したまま項目をドラッグ・アンド・ドロップします。

23.3.2 JDeveloperでのMFLファイルの作成方法

MFLファイルを作成すると、メッセージ書式ファイルのルート・ノードが、MFLファイルに指定した同じ名前で自動的に生成されます。このルート・ノード名は、変換後のXMLドキュメントのルート要素になるため、XML要素の命名規則に準じている必要があります。

JDeveloperでMFLファイルを作成するには:

1. アプリケーション・ナビゲータで、新しいMFLリソースを含めるプロジェクトまたはフォルダを右クリックし、「新規」をポイントして「MFL」を選択します。

「MFLの作成」ダイアログが表示されます。

2. 名前と、必要に応じてリソースの簡単な説明を入力します。

3. 「終了」をクリックします。

Format Builderが表示されます。

4. 次のいずれかの手順を使用してメッセージ書式を定義します。

23.3.3 グループを作成する方法

グループは、何らかの関連がある複数のフィールドを定義します(たとえば、PAYDATEフィールド、HOURSフィールド、RATEフィールドをPAYINFOグループに入れることができます)。グループを、メッセージ・フォーマット項目の子、別のグループの子、あるいはグループまたはフィールドの兄弟として作成できます。

グループを作成するには:

1. 左ペインのツリー・ビューでノードを選択します。

2. メッセージ・フォーマットまたは別のグループの子としてグループを作成する場合、「挿入」→「グループ」→子としてを選択します。別のグループまたはフィールドの兄弟としてグループを作成する場合、「挿入」→「グループ」→兄弟としてを選択します。グループの詳細ウィンドウが右ペインに表示されます。

3. フィールドに適切なデータを入力します。

詳細と手順は、「MFLメッセージ構造の構成」および「グループ構成ウィンドウ」を参照してください。

4. 「適用」をクリックしてメッセージ・フォーマット・ファイルへの変更を保存するか、「リセット」をクリックして詳細ウィンドウへの変更を破棄し、すべてのフィールドを最後に保存された値にリセットします。

23.3.4 フィールドの作成方法

フィールドとは、アプリケーションにとって何らかの意味を持つバイト・シーケンスです(たとえば、フィールドEMPNAMEには、従業員名が格納されます。)フィールドは、メッセージ・フォーマット項目の子、グループの子、あるいはグループまたは別のフィールドの兄弟として作成できます。

フィールドを作成するには:

1. 左ペインのツリー・ビューでノードを選択します。

2. メッセージ・フォーマットまたはグループの子としてフィールドを作成する場合、「挿入」→「フィールド」→子としてを選択します。別のグループまたはフィールドの兄弟としてグループを作成する場合、「挿入」→「フィールド」→兄弟としてを選択します。フィールドの詳細ウィンドウが右ペインに表示されます。

3. フィールドに適切なデータを入力します。

詳細と手順は、「MFLメッセージ構造の構成」および「フィールド構成ウィンドウ」を参照してください。

4. 「適用」をクリックしてメッセージ・フォーマット・ファイルへの変更を保存するか、「リセット」をクリックして詳細ウィンドウへの変更を破棄し、すべてのフィールドを最後に保存された値にリセットします。

23.3.5 グループまたはフィールドの参照方法

参照では、データを再入力しないで、事前に定義したフィールドまたはグループ・フォーマットの記述を再使用することを指定します。参照フィールドまたは参照グループのフォーマットは元のフィールドまたはグループと同じですが、参照フィールドまたは参照グループのOptional設定とOccurrence設定だけは変更できます。たとえば、「請求先」住所と「届け先」住所がデータに含まれ、その住所フォーマットが同じである場合、住所フォーマットの定義は1回で済みます。「請求先」住所定義を作成し、「届け先」住所には参照を作成します。

注意:

参照には、元の項目と同じ名前が付けられます。たとえば、「請求先」住所定義と「届け先」住所定義には同じ名前が付けられます。グループ定義を再使用する場合、汎用的なグループを作成し、そのグループを特定のグループに埋め込みます。たとえば、前の例では、「請求先」グループ内に「住所」グループを作成し、「届け先」グループ内で「住所」グループを参照します。

グループまたはフィールドを参照するには:

1. ツリー・ペインでフィールドまたはグループを選択します。

2. 「編集」→「コピー」を選択します。

3. ツリーで正しい兄弟を選択します。

4. 「編集」→「貼付け」→「参照として」を選択します。

5. フィールドに適切なデータを入力します。

詳細と手順は、「MFLメッセージ構造の構成」および「Format Builderの参照構成ウィンドウ」を参照してください。

6. 「適用」をクリックしてメッセージ・フォーマット・ファイルへの変更を保存するか、「リセット」をクリックして詳細ウィンドウへの変更を破棄し、すべてのフィールドを最後に保存された値にリセットします。

23.3.6 コメントの追加方法

コメントは、メッセージ・フォーマットまたはメッセージ・フォーマットによって変換されるデータについてのメモです。コメントはメッセージ・フォーマット定義に含まれますが、情報提供のみを目的とします。コメントは、任意のメッセージ・フォーマット、グループ、またはフィールドの子または兄弟として作成できます。

コメントを追加するには:

1. 左ペインのツリー・ビューで項目を選択します。

2. 選択した項目の子としてコメントを作成する場合、「挿入」→「コメント」→子としてを選択します。選択した項目の兄弟としてコメントを作成する場合、「挿入」→「コメント」→兄弟としてを選択します。コメントの詳細ウィンドウが右ペインに表示されます。

3. コメント・テキストを入力します。

4. 「適用」をクリックしてメッセージ・フォーマット・ファイルへの変更を保存するか、「リセット」をクリックして詳細ウィンドウへの変更を破棄し、すべてのフィールドを最後に保存された値にリセットします。

23.4 MFLメッセージ構造の構成

フィールド、グループまたは参照を作成したら、ノードを繰り返すかどうか、繰り返す回数、ノードが固定長か、区切られているかなどの特定の属性を構成できます。

- ノードの繰返しの作成方法

- デリミタの定義方法

23.4.1 ノードの繰返しの作成方法

ノードは、一定回数、メッセージで指定された回数または無制限に繰り返すことができます。

ノードの繰返しを作成するには:

1. 左ペインのツリー・ビューで、繰返しを作成するグループ、フィールドまたは参照をダブルクリックします。

2. 「発生」セクションで、次のいずれかの手順を実行します。

- 繰返しを示すデリミタを指定するには、繰返しのデリミタを選択し、関連付けられたフィールドにデリミタ値を入力します。

- 繰返し回数を示すメッセージ内のフィールドを指定するには、繰返しフィールドを選択し、使用可能なオプションのリストからフィールドの名前を選択します。

- 一定回数のノードの繰返しを構成するには、繰返し回数を選択し、関連付けられたフィールドに回数を入力します。

- ノードを無制限に繰り返すことができる場合は、「無制限」を選択します。

3. 「適用」をクリックしてメッセージ・フォーマット・ファイルへの変更を保存するか、「リセット」をクリックして詳細ウィンドウへの変更を破棄し、すべてのフィールドを最後に保存された値にリセットします。

23.4.2 デリミタの定義方法

可変長のデータ型の終了点をデリミタで指定できます。デリミタとは、フィールドの終わりをマークする文字。フィールド・データはデリミタが見つかるまで続きます。デリミタは参照または値によって指定できます。

23.4.2.1 参照によるデリミタの指定

参照によってデリミタを指定するには:

1. 左ペインのツリー・ビューでグループまたはフィールドを選択します。

2. 「終了」セクションで、「デリミタ」を選択します。

「属性」セクションが表示されます。

3. 参照フィールドをクリックします。

参照フィールドの選択ダイアログが表示されます。

図23-1 参照フィールドの選択

4. 左ペインで参照フィールドを選択し、右矢印ボタンをクリックして、それらを右側の選択済ペインに移動します。

5. 「OK」をクリックします。

6. 「値」フィールドには、メッセージ内に参照フィールドが存在しない場合のデフォルト・デリミタを入力します。

7. 「適用」をクリックしてメッセージ・フォーマット・ファイルへの変更を保存するか、「リセット」をクリックして詳細ウィンドウへの変更を破棄し、すべてのフィールドを最後に保存された値にリセットします。

23.4.2.2 値によるデリミタの指定

値によってデリミタを指定するには:

1. 左ペインのツリー・ビューでグループまたはフィールドを選択します。

2. 「終了」セクションで、「デリミタ」を選択します。

「属性」セクションが表示されます。

3. 「値」フィールドにデリミタを入力します。複数のデリミタを入力する場合は、指定されたセパレータ文字で区切ります。

たとえば、次のリストでは、デリミタをカンマ、チルダまたはセミコロンにすることができます。セパレータはパイプ(|)です。

,|~|;

4. このフィールドがオプションの場合は、「オプション」チェック・ボックスを選択します。フィールドが存在しない場合でもバイナリ・データにデリミタが含まれるようにするには、チェック・ボックスを選択解除します。

5. 「適用」をクリックしてメッセージ・フォーマット・ファイルへの変更を保存するか、「リセット」をクリックして詳細ウィンドウへの変更を破棄し、すべてのフィールドを最後に保存された値にリセットします。

23.5 メタデータのインポートと変換

Format Builderでは、COBOLコピーブックやgXMLガイドライン・ファイルをインポートしたり、C構造定義をMFLメッセージ定義に変換したりできます。

- ガイドラインXMLファイルの変換方法

- XMLスキーマの変換方法

- COBOLコピーブックの変換方法

- C構造の変換方法

- FMLフィールド表クラスの変換方法

23.5.1 ガイドラインXMLファイルの変換方法

Format Builderでは、ガイドラインXML (gXML)ファイルをインポートしてメッセージ定義に変換でき、メッセージ定義は、ユーザーがニーズに合わせて変更およびカスタマイズできます。gXMLは、XMLを使用するビジネス・ドキュメント(発注書、請求書など)の電子商取引ガイドラインの交換を促進するために設計されたオープンな仕様です。このリリースではgXMLバージョン0.71がサポートされています。

gXMLファイルを変換するには:

1. 「ツール」→「インポート」→EDI Importerを選択します。

EDI Importerダイアログが表示されます。

2. gXMLファイルのパスと名前を入力するか、「参照」をクリックして使用するファイルまで移動して選択します。

3. 「OK」をクリックします。

23.5.2 XMLスキーマの変換方法

Format Builderでは、非XMLドキュメントのXML表現を適切に表すXMLスキーマをインポートできます。この機能により、非XMLドキュメントのフォーマットを指定する作業をすぐに始めることができます。

XMLスキーマを変換するには:

1. 「ツール」→「インポート」→XML Schema Importerを選択します。

XML Schema Importerダイアログが表示されます。

2. XMLスキーマ・ファイルのパスと名前を入力するか、「参照」をクリックして使用するファイルまで移動して選択します。

3. 「ルート要素」フィールドで、MFLファイルのルート・ノードとして使用するXMLスキーマの要素を選択します。

4. 「MFLフィールド・デリミタのデフォルト」フィールドで、デリミタのデフォルト値を入力します。

5. 「OK」をクリックします。

23.5.3 COBOLコピーブックの変換方法

Format Builderでは、COBOLコピーブックをFormat Builderにインポートして、COBOLデータを変換するためのメッセージ定義を作成できます。コピーブックのインポート時には、インポートされるコピーブックとそれに含まれるグループおよびフィールドを説明するためにコメントが使用されます。

COBOLコピーブックを変換するには:

1. 「ツール」→「インポート」→COBOL Copybook Importerを選択します。

COBOL Copybook Importerダイアログが表示されます。

2. COBOLコピーブック・ファイルのパスと名前を入力するか、「参照」をクリックして使用するファイルまで移動して選択します。

3. 次のいずれかを選択します。

- ビッグ・エンディアン: バイト・オーダーをビッグ・エンディアンに設定します。
注意: このオプションは、IBM 370、Motorola、および大半のRISC設計(IBMメインフレームやほとんどのUNIXプラットフォーム)に使用されます。

- リトル・エンディアン: バイト・オーダーをリトル・エンディアンに設定します。
注意: このオプションは、Intel、VAXおよびUnisysプロセッサ(Windows、VMS、Digital、UNIXおよびUnisys)に使用されます。

4. 次のオプションから文字セットを選択します。

- EBCDIC

- US-ASCII
注: これらの2つの値は、インポート元のホスト・マシンの属性です。

- その他(このオプションを選択した場合は、使用可能なオプションのリストから文字セットを選択する必要があります。

インポートしたコピーブックは、他のメッセージ・フォーマット定義と同じように使用できます。コピーブックにエラーやサポートされていないデータ型が含まれている場合は、警告メッセージによりエラーが通知されます。エラーを表示するか、または今後の参考にエラーをログ・ファイルに保存するかを選択できます。

23.5.4 C構造の変換方法

Format Builderには、MFLまたはCコード出力を生成してC構造体定義をMFLメッセージ定義に変換するためのC Struct Importerユーティリティが含まれています。

MFLへの変換を定義する場合、MFLを直接生成するには、プロファイルの構成データをいくつか入力する必要があります。これらのデータ入力は、ハードウェア・プロファイルを新しく作成するか、または既存のプロファイルを指定して行うことができます。正常に生成されると、Format Builderのメイン・ウィンドウが表示され、ナビゲーション・ツリーにMFLオブジェクトがリストされます。このMFLオブジェクトには、解析で使用された入力ファイルと同じ名前が付けられます。生成プロセスでエラーが検出された場合は、「MFL Generation Errors」ダイアログが表示されます。このダイアログを使用して、エラー・ログを表示するかまたはファイルとして保存することができます。発生したエラーを確認したら、「C Struct Importer」に戻って前の手順を繰り返すことができます。

C構造を変換するには:

1. Format Builderのメイン・ウィンドウから、ツール→「インポート」→C Struct Importerを選択します。
C Structure Importerダイアログが表示されます。

2. インポートするファイルのパスと名前を入力するか、「参照」をクリックしてファイルまで移動して選択します。

3. 「解析」をクリックします。
「構造」フィールドに、選択したファイルで見つかった構造のリストが入力されます。

4. 変換する構造を選択します。

5. MFLデータを生成するには、次の手順を実行します。

a. 「出力」の下の「MFL」オプションを選択します。

b. 「構造」フィールドで、使用可能なオプションのリストから目的の構造を選択します。

c. 「名前」フィールドでは、既存のハードウェア・プロファイルを選択するか、「新規」をクリックして新しいプロファイルを作成します。表示されたダイアログで、名前および説明を指定し、プリミティブ・データ型とバイト・オーダーを変更して、「OK」をクリックします。
プロファイル・パラメータを参照または編集するには、「編集」をクリックしてハードウェア・プロファイル・エディタを開きます。

d. 「OK」をクリックして、MFLファイルを生成します。

e. エラー・ログの表示をクリックしてエラーを表示するか、エラー・ログの保存をクリックして指定した場所にエラー・ログを保存するか、「取消」をクリックしてMFL生成エラー・ダイアログ・ボックスを閉じます。

6. Cコードを生成するには、次の手順を実行します。

a. 「出力」の下の「Cコード」オプションを選択します。

b. MFL生成フィールドまたはデータ生成フィールドにファイル名を入力するか、「参照」をクリックしてファイルを選択します。

c. 「OK」をクリックします。
既存ファイルの上書きに関する警告と、コード生成の成功または失敗を通知するメッセージが表示されます。

d. 生成されたソース・コードを対象のプラットフォームにコピーし、ソース・コードをコンパイルして実行します。

注意:

構造体の宣言を含む入力ファイルもコピーする必要があります。コンパイルが完了すると、両方のプログラムで出力ファイル名の引数が取り込まれます。

e. 生成されたMFLまたはデータを、Format Builderを実行しているプラットフォームにコピーします。

23.5.5 FMLフィールド表クラスの変換方法

FML Field Table Class Importerは、WebLogic Tuxedo ConnectorとBusiness Process Management (BPM)機能の統合を促進します。WebLogic Tuxedo ConnectorのFML/XML Translator機能によって、Tuxedoアプリケーション・バッファがXMLとの間で相互に変換されます。TuxedoをBPM機能と統合するには、WebLogic Tuxedo Connector Translatorとプロセス・エンジンとの間で受け渡しされるXMLを作成する必要があります。必要なXMLを作成するには、FML Field Table Class Importerと、Format TesterのXML生成機能を使用します。

始める前に

1. FMLバッファと関連付けられているフィールド・テーブルを、TuxedoシステムからWebLogic Server/WebLogic Tuxedo Connector環境に移動します。

2. weblogic/wtc/jatmi/mkfldclassユーティリティを使用して、フィールド表を表すJavaソース・コードを構築します。FMLフィールド表の管理の詳細は、WebLogic Serverのドキュメントを参照してください。

3. ソース・コードをコンパイルします。生成されるクラス・ファイルは、FldTblインタフェースを実装するため、fldtblクラスと呼ばれます。これらのクラスは、FML Field Table Class Importerダイアログで選択できるJARファイルにパッケージする必要があります。

注意:

ほとんどのユーザーはWebLogic Tuxedo Connectorを構成するときにこの手順を実行するため、これらのクラス・ファイルがすでに存在していることがあります。WebLogic Tuxedo Connectorを使用してJavaクラスを作成する場合、.classファイルは\extディレクトリに置くことができます。こうしておくと、FML Field Table Class Importerダイアログ・ボックスから使用可能なフィールド・リストに自動的にデータを入力できます。

FML Field Table Class ImporterでXMLドキュメントを作成するには:

1. 「ツール」→「インポート」→EDI Importerを選択します。

FML Field Table Class Importerダイアログが表示されます。

2. 「選択」をクリックして、fldtblクラスを含むJARファイルを選択します。

「クラス」リストにfldtblクラスが表示されます。選択したJARファイルにfldtblクラスが含まれない場合、エラー・メッセージが表示され、「フィールド表Jarファイル」フィールドと「クラス」フィールドがクリアされます。

3. 「クラス」セクションで、使用可能なクラスのリストから1つ以上のfldtblクラス名を選択します。

4. 「使用可能なフィールド」リストで、オプションのリストからフィールドを選択し、「追加」をクリックします。

このリストでは重複する名前は許可されません。別のフィールド表に同じ名前のフィールドがあっても、リストには1つしか表示されません。

5. 「選択されたフィールド」リストに誤って追加されたフィールドを削除するには、フィールドを選択して「削除」をクリックします。

6. 「OK」をクリックします。

7. 次の表に従って、フィールドにデータを入力します。

8. 作成されたMFLドキュメントを編集し、Business Process Management (BMP)からWebLogic Tuxedo Connector FML/XML Translatorに渡されるXMLドキュメント内のフィールドの順序と出現数を指定します。

9. 「ツール」→「テスト」を選択し、Format Testerツールを表示します。

10. Format Testerのメニュー・バーで「生成」→「XML」を選択し、Format Builder内のMFLドキュメントに準拠するXMLドキュメントを作成します。

11. XMLドキュメントのフィールドのデータ・コンテンツを必要に応じて編集します。

12. Format Testerのメニュー・バーで、「ファイル」→XMLの保存を選択し、ファイルの名前と場所を指定してXMLドキュメントを保存します。

XMLインスタンス・エディタを使用すると、作成したXMLをインポートして、Business Process Management機能で使用できます。XMLのインポートについては、BPMのドキュメントを参照してください。

23.6 MFLリソースの削除

削除するMFLファイルを参照しているリソースがある場合、そのファイルを削除する前にそれらの参照を削除します。MFLリソースは他のリソースによって参照されていても削除できますが、その場合、削除されたリソースへの未解決の参照が原因で、競合が発生する可能性があります。

23.6.1 MFLリソースの削除方法

MFLリソースを削除する前に、参照または依存性を確認してください。Oracle Service Busコンソールの場合、MFL定義エディタでMFLファイルを開き、右上にある「ツール」をクリックして「参照」を選択し、サービスで参照を使用しているかどうかを調べます。JDeveloperでは、MFLを右クリックして、「依存性の参照」を選択します。

MFLリソースを削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するXSL変換が含まれているプロジェクトおよびフォルダを開きます。

2. MFLファイルの名前を右クリックし、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログにMFLリソースの参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

23.7 フォーマット定義のテスト

フォーマット定義を構築したら、Format Testerを使用してテストできます。Format Testerでは、データを解析して再フォーマットする検証テストを行い、サンプルの非XMLデータまたはXMLデータを生成します。このサンプル・データを編集、検索、およびデバッグして、目的のデータにすることができます。

23.7.1 Format Testerの起動方法

Format TesterはFormat Builderから起動され、個別のウィンドウで開かれます。

Format Testerを起動するには:

1. Format Builderでメッセージ・フォーマット・ドキュメント(MFLファイル)を開きます。

注意:

Format Testerを実行するには、Format Builderでメッセージ・フォーマット・ドキュメントが開いている必要があります。

2. Format Builderのメニュー・バーで「ツール」→「テスト」を選択します。

3. Format Testerダイアログ・ボックスが表示されます。

Format Testerでは、現在ロードされているメッセージ定義ドキュメントが使用されます。

23.7.2 非XMLウィンドウを使用したテスト方法

「非XML」データ表示パネルは、選択したタブに応じて16進数エディタまたはテキスト・エディタとして使用できます。

16進数エディタ・パネルには、データ・オフセット、個々のバイトの16進値、および対応するテキストが表示されます。対応するテキストは、必要に応じてASCII文字またはEBCDIC文字として表示できます。このエディタで、16進バイトまたはテキスト値を編集できます。16進データ値が変更されると、それに対応するテキスト値が更新され、テキスト値が変更された場合は16進データ値が更新されます。

23.7.2.1 データ・オフセット機能の使用

16進数エディタのデータ・オフセット機能を使用すると、データ・オフセットを16進数または10進数で表示できます。

データ・オフセットを変更するには:

「表示」→「16進」を選択します。次の2つのデータ・オフセット・オプションが表示されます。

- 16進数としてオフセット

- 10進数としてオフセット

必要に応じた表示オプションをクリックします。「非XML」ウィンドウのデータ・オフセット・パネルは、選択したオプションに合わせて動的に変更されます。

23.7.2.2 テキスト機能の使用

テキスト機能を使用するには、「非XML」ウィンドウ内で「Text」タブを選択します。キャリッジ・リターンなどの出力可能な文字がすべて表示されます。これらは改行付きテキストとして「Text」ウィンドウに表示されます。

23.7.3 XMLウィンドウを使用したテスト方法

「XML」データ・パネルには、「非XML」パネルのコンテンツから変換されたXMLデータが表示されます。「XML」パネルのコンテンツは、必要に応じて消去したり編集することができます。

このウィンドウでは、非XMLフォーマットに変換するXMLデータを入力または生成することもできます。

23.7.4 デバッグ・ウィンドウを使用したテスト方法

デバッグ・ウィンドウには、トランスフォーメーション処理で行われた操作、発生したエラー、およびフィールドとグループの値とデリミタが表示されます。エラーの場所を特定するには、Format Builderのツリー・ペインで、最後に正しく解析されたフィールドを特定し、その次のフィールドの仕様を調べます。

Format Testerを開くと、非XMLウィンドウとXMLウィンドウだけが表示されます。デバッグ・ウィンドウを開くには、「表示」→「デバッグ」を選択してデバッグ・ウィンドウの表示と非表示を切り替えます。デバッグ・ウィンドウは、非XMLウィンドウとXMLウィンドウの下に表示されます。

注意:

デバッグ出力は、最新の64KBまでのメッセージに制限されます。ファイルには、完全なデバッグ情報を保存できます。詳細は、「デバッグ・ログの使用」を参照してください。

23.7.5 フォーマット定義のデバッグ方法

次の項では、データのデバッグと修正に使用できる様々なFormat Testerユーティリティについて説明します。

- 値の検索

- オフセットの検索

- デバッグ・ログの使用

23.7.5.1 値の検索

検索機能を使用して、非XMLデータ内の16進値やテキスト値を検索できます。「検索」ダイアログには次のフィールドがあります。

値を検索するには:

1. Format Tester内で「ファイル」→非XMLを開くを選択して、検索する非XMLデータ・ファイルを開きます。

2. 「編集」→「検索」を選択します。

「検索」ダイアログが表示されます。

3. フィールドに適切なデータを入力します。詳細は、表23-2を参照してください。

表23-2 「検索」のオプション

フィールド

説明

値

検索する値を入力します。

テキスト

テキスト値を検索する場合はこのオプションを選択します。

16進

16進値を検索する場合はこのオプションを選択します。

次へ

選択した場所から下に向かってドキュメントを検索する場合はこのオプションを選択します。

前へ

選択した場所から先頭に向かってドキュメントを検索する場合はこのオプションを選択します。

ファイルの先頭

ファイルの先頭から検索を開始する場合はこのオプションを選択します。

現在位置

現在のカーソル位置から検索を開始する場合はこのオプションを選択します。

ファイルの末尾

ファイルの末尾から検索を開始する場合はこのオプションを選択します。

「OK」ボタン

検索操作を開始します。

「取消」ボタン

検索を実行せずに「検索」ダイアログを閉じます。

4. 「OK」をクリックして検索操作を開始します。

23.7.5.2 オフセットの検索

移動機能を使用して、非XMLエディタのカーソルを指定したバイト・オフセットに移動できます。「移動」ダイアログには次のフィールドがあります。

指定したオフセットに移動するには:

1. Format Tester内で「ファイル」→非XMLを開くを選択して、検索する非XMLデータ・ファイルを開きます。

2. 「編集」→「移動先」を選択します。

「移動先」ダイアログが表示されます。

3. フィールドに適切なデータを入力します。詳細は、表23-2を参照してください。

表23-3 「移動先」のオプション

フィールド

説明

オフセット

検索するオフセット値を入力します。

10進

10進値に移動する場合はこのオプションを選択します。

16進

16進値に移動する場合はこのオプションを選択します。

次へ

選択した場所から下に向かってドキュメントを検索する場合はこのオプションを選択します。

前へ

選択した場所から先頭に向かってドキュメントを検索する場合はこのオプションを選択します。

ファイルの先頭

ファイルの先頭から検索を開始する場合はこのオプションを選択します。

現在位置

現在のカーソル位置から検索を開始する場合はこのオプションを選択します。

ファイルの末尾

ファイルの末尾から検索を開始する場合はこのオプションを選択します。

「OK」ボタン

検索操作を開始します。

「取消」ボタン

検索を実行せずに「移動」ダイアログを閉じます。

4. 「OK」をクリックして検索操作を開始します。

23.7.5.3 デバッグ・ログの使用

デバッグ・ログでは、デバッグ情報をテキスト・ファイルに保存できます。

デバッグ・ログを使用するには:

- 「ファイル」→デバッグ・ログを選択します。
表示されたダイアログで、デバッグ情報の保存先として新しいパスとファイル名を入力するか、既存のファイルを選択できます。

注意:

既存のファイルを選択した場合、新しいデバッグ情報は、ファイルの最後に追加されます。

23.7.6 Format Testerのコマンド・リファレンス

この項では、Format Testerのメイン・メニューから使用可能なコマンドについて説明します。

- 「ファイル」メニュー

- 「編集」メニュー

- 「表示」メニュー

- 「生成」メニュー

- 「変換」メニュー

23.7.6.1 「ファイル」メニュー

「ファイル」メニューには次のコマンドがあります。

要素

説明

非XMLを開く

非XMLウィンドウに表示する非XMLファイルを選択できます。

注意: 非XMLファイルのデフォルトのファイル拡張子は.DATAです。

XMLを開く

「Format Tester」ウィンドウの「XML」セクションに表示するファイルを選択できます。

注意: XMLファイルのデフォルトのファイル拡張子は.XMLです。

非XMLの保存

非XMLウィンドウの内容を保存します。

XMLの保存

「XML」ウィンドウの内容を保存します。

デバッグ・ログ

デバッグ情報をテキスト・ファイルに保存します。

閉じる

「Format Tester」ウィンドウを閉じます。

23.7.6.2 「編集」メニュー

「編集」メニューには次のコマンドがあります。

要素

説明

切取り

現在選択されているテキストを切り取り、別の場所へ貼り付けられるようにクリップ・ボードに格納します。

コピー

現在選択されているテキストをコピーし、別の場所へ貼り付けられるようにクリップ・ボードに格納します。

貼付け

切り取ったテキストやコピーしたテキストをカーソル位置に挿入します。

検索

非XMLデータの16進値またはテキスト値を検索できます。

次を検索

指定した値の次のインスタンスを続けて検索します。

移動先

非XMLエディタの指定のバイト・オフセットにカーソルを移動できます。

23.7.6.3 「表示」メニュー

「表示」メニューには次のコマンドがあります。

要素

説明

XML

「XML」データ・パネルの表示と非表示を切り替えることができます。非表示にすると、非XMLデータ・ウィンドウが横に拡大してTester全体に表示されます。XMLボタンは表示されたままですが、分割線は非表示になります。

デバッグ

「デバッグ」出力ウィンドウの表示と非表示を切り替えることができます。

「クリア」→非XML

「非XML」データ・ウィンドウのコンテンツを空の状態にリセットします。

「クリア」→「XML」

「XML」ウィンドウのコンテンツを空の状態にリセットします。

16進数→16進数としてオフセット

オフセット値を16進数として表示します。このオプションを選択すると、10進数としてオフセットの表示が無効になります。

16進数→10進数としてオフセット

オフセット値を10進数として表示します。このオプションを選択すると、Offset as Hexadecimalの表示が無効になります。

23.7.6.4 「生成」メニュー

「生成」メニューには次のコマンドがあります。

要素

説明

非XML

現在のフォーマット仕様に適合する非XMLデータを生成します。

XML

現在のフォーマット仕様に適合するXMLデータを生成します。

データの生成中にプロンプト

このオプションは、生成プロセスの間にメッセージを表示して、省略可能なフィールドまたはグループを生成するかどうか、生成する子、さらに繰返しグループの反復回数を指定する場合に選択します。

23.7.6.5 「変換」メニュー

「変換」メニューには次のコマンドがあります。

要素

説明

非XMLからXMLへ

「非XML」ウィンドウのコンテンツをXMLに変換します。

XMLから非XMLへ

「XML」ウィンドウのコンテンツを非XMLデータに変換します。

23.8 パレットの使用

Format Builderのパレットを使用すると、よく使用するメッセージ・フォーマット項目を格納したり、格納されている項目をメッセージ・フォーマット定義に挿入することができます。これらの項目はXMLドキュメントに保存され、Windowsの標準のドラッグ・アンド・ドロップ機能を使用してパレットからメッセージ・フォーマット定義に項目をコピーできます。

パレットには、一般的な日付フォーマット、リテラルおよび文字列が含まれています。作成するメッセージ・フォーマットでこれらの項目を使用することも、独自の項目をパレットに追加することもできます。

23.8.1 「パレット」ウィンドウの表示方法

パレットの表示と非表示を切り替えるには、「表示」→パレットの表示を選択します。パレットが現在表示されていない場合は、Format Builderウィンドウの横に別のウィンドウとしてパレットが開きます。パレットが現在表示されている場合は、そのウィンドウが閉じます。

23.8.2 パレットへの項目の追加方法

別のノードの有無に依存するノードをパレットに追加することはできません。たとえば、フィールドまたはグループの参照を追加することはできません。また、繰返しフィールドが定義されている項目を追加することもできません。コメントは追加できますが、コメントは一意の名前を持たないのでパレット上で区別が付きにくいため、追加しないことをお薦めします。

パレットに項目を追加するには:

1. ナビゲーション・ツリーで、パレットに追加する項目を選択します。

2. 項目をクリックし、左マウス・ボタンを押したまま項目をパレット・ウィンドウにドラッグします。

3. 項目を配置する位置(選択した項目の兄弟として挿入される)までドラッグしたら、マウス・ボタンを離します。ナビゲーション・ツリーの項目がパレット・ウィンドウにコピーされます。

23.8.3 メッセージ・フォーマットへのパレット項目の追加方法

メッセージ・フォーマットにパレットの項目を追加するには:

1. パレット・ウィンドウで、メッセージ・フォーマットに追加する項目を選択します。

2. 項目をクリックし、左マウス・ボタンを押したまま項目を「Format Builder」ウィンドウの左ペインにドラッグします。

3. 項目を配置する位置(目的の項目の子または兄弟として挿入される)までドラッグしたら、マウス・ボタンを離します。パレットの項目がメッセージ・フォーマットにコピーされます。

23.9 Format Builderのサポート対象のデータ型

この項では、MFLのデータ型、COBOL Copybook Importerのデータ型およびサポートされていないC言語機能について説明します。

- MFLデータ型

- COBOL Copybook Importerのデータ型

- サポートされていないC言語機能

23.9.1 MFLデータ型

表23-4は、データ・トランスフォーマでサポートされているMFLのデータ型を示します。これらは、非XMLからXMLへ、またはXMLから非XMLへの変換で使用されるメタデータのデータ型で、フィールド・フォーマット要素のtype属性で指定されます。

表23-4 サポートされるMFLデータ型

データ型

説明

Binary (Base64エンコーディング)

任意の文字の値を入力できます。長さ、長さフィールド、デリミタ、またはデリミタ・フィールドが必要です。このフィールドの変換後のXMLデータはbase-64でエンコードされています。

Binary (16進数エンコーディング)

任意の文字の値を入力できます。長さ、長さフィールド、デリミタ、またはデリミタ・フィールドが必要です。このフィールドの変換後のXMLデータはbase-16でエンコードされています。

Date: DD-MMM-YY

日付を定義する文字列(例: 22-JAN-00)。

Date: DD-MMM-YYYY

日付を定義する文字列(例: 22-JAN-2000)。

Date: DD/MM/YY

日付を定義する文字列(例: 22/01/00)。

Date: DD/MM/YYYY

日付を定義する文字列(例: 22/01/2000)。

Date: DDMMMYY

日付を定義する文字列(例: 22JAN00)。

Date: DDMMMYYYY

日付を定義する文字列(例: 22JAN2000)。

Date: MM/DD/YY

日付を定義する文字列(例: 01/22/00)。

Date: MM/DD/YYYY

日付を定義する文字列(例: 01/22/2000)。

Date: MMDDYY

日付を定義する6桁の数字列(例: 012200)。

Date: MMDDYYYY

日付を定義する8桁の数字列(例: 01222000)。

Date: MMM-YY

日付を定義する文字列(例: JAN-00)。

Date: MMM-YYYY

日付を定義する文字列(例: JAN-2000)。

Date: MMMDDYYYY

日付を定義する文字列(例: JAN222000)。

Date: MMMYY

日付を定義する文字列(例: JAN00)。

Date: MMMYYYY

日付を定義する文字列(例: JAN2000)。

Date: Wed Nov 15 10:55:37 CST 2000

Javaプラットフォームのデフォルトの日付フォーマット(例: 'WED NOV 15 10:55:37 CST 2000')。

Date: YY-MM-DD

日付を定義する文字列(例: 00-01-22)。(文字列00-01-22は、2000年1月22日の日付を定義します。)

Date: YY/MM/DD

日付を定義する文字列(例: 00/01/22)。(文字列00/01/22は、2000年1月22日の日付を定義します。)

Date: YYMMDD

日付を定義する文字列(例: 000122)。(文字列000122は、2000年1月22日の日付を定義します。)

Date: YYYY-MM-DD

日付を定義する文字列(例: 2000-01-22)。(文字列2000-01-22は、2000年1月22日の日付を定義します。)

Date: YYYY/MM/DD

日付を定義する文字列(例: 2000/01/22)。(文字列2000/01/22は、2000年1月22日の日付を定義します。)

Date: YYYYMMDD

YYYYMMDDフォーマットの8バイトの数字列。文字エンコーディングを表すStringまたはEBCDICの基本データ型を指定できます。

DateTime: DD/MM/YY hh:mm

日付と時刻を定義する文字列(例: 22/01/00 12:24)。

DateTime: DD/MM/YY hh:mm AM

日付と時刻を定義する文字列(例: 22/01/00 12:24 AM)。

DateTime: DD/MM/YY hh:mm:ss

日付と時刻を定義する文字列(例: 22/01/00 12:24:00)。

DateTime: DD/MM/YY hh:mm:ss AM

日付と時刻を定義する文字列(例: 22/01/00 12:24:00 AM)。

DateTime: MM/DD/YY hh:mm

日付と時刻を定義する文字列(例: 01/22/00 12:24)。

DateTime: MM/DD/YY hh:mi AM

日付と時刻を定義する文字列(例: 01/22/00 12:24 AM)。

DateTime: MM/DD/YY hh:mm:ss

日付と時刻を定義する文字列(例: 01/22/00 12:24:00)。

DateTime: MM/DD/YY hh:mm:ss AM

日付と時刻を定義する文字列(例: 01/22/00 12:24:00 AM)。

DateTime: MMDDYYhhmm

日付と時刻を定義する数字列(例: 0122001224)。

DateTime: YYYYMMDDhhmmss

YYYYMMDDHHMISSフォーマットの14バイトの数字列。基本データ型を指定できます。

DateTime: MMDDYYhhmmss

日付と時刻を定義する数字列(例: 012200122400)。

EBCDIC

IBMのExtended Binary Coded Decimal Interchange Codeの文字列。長さ、長さフィールド、デリミタ、またはデリミタ・フィールドが必要です。

Filler

XMLに変換されないバイト・シーケンス。非XMLデータからXMLへの変換では、このフィールドはスキップされます。XMLから非XMLデータへの変換では、このフィールドはスペースのシーケンスとしてバイナリ出力ストリームに書き込まれます。

FloatingPoint: 4バイト、ビッグ・エンディアン

IEEE標準754に準拠する4バイト・ビッグ・エンディアンの浮動小数点数。

FloatingPoint: 4バイト、リトル・エンディアン

IEEE標準754に準拠する4バイト・リトル・エンディアンの浮動小数点数。

FloatingPoint: 8バイト、ビッグ・エンディアン

IEEE標準754に準拠する8バイト・ビッグ・エンディアンの浮動小数点数。

FloatingPoint: 8バイト、リトル・エンディアン

IEEE標準754に準拠する8バイト・リトル・エンディアンの浮動小数点数。

Integer: 符号付き、1バイト

1バイトの符号付き整数(例: 56は0x38)。

Integer: 符号なし、1バイト

1バイトの符号なし整数(例: 128は0x80)。

Integer: 符号付き、2バイト、ビッグ・エンディアン

ビッグ・エンディアン・フォーマットの2バイトの符号付き整数(例: 4660は0x1234)。

Integer: 符号付き、4バイト、ビッグ・エンディアン

ビッグ・エンディアン・フォーマットの4バイトの符号付き整数(例: 4660は0x00001234)。

Integer: 符号付き、8バイト、ビッグ・エンディアン

ビッグ・エンディアン・フォーマットの8バイトの符号付き整数(例: 4660は0x0000000000001234)。

Integer: 符号なし、2バイト、ビッグ・エンディアン

ビッグ・エンディアン・フォーマットの2バイトの符号なし整数(例: 65000は0xFDE8)。

Integer: 符号なし、4バイト、ビッグ・エンディアン

ビッグ・エンディアン・フォーマットの4バイトの符号なし整数(例: 65000は0x0000FDE8)。

Integer: 符号なし、8バイト、ビッグ・エンディアン

ビッグ・エンディアン・フォーマットの8バイトの符号なし整数(例: 65000は0x000000000000FDE8)。

Integer: 符号付き、2バイト、リトル・エンディアン

リトル・エンディアン・フォーマットの2バイトの符号付き整数(例: 4660は0x3412)。

Integer: 符号付き、4バイト、リトル・エンディアン

リトル・エンディアン・フォーマットの4バイトの符号付き整数(例: 4660は0x34120000)。

Integer: 符号付き、8バイト、リトル・エンディアン

リトル・エンディアン・フォーマットの8バイトの符号付き整数(例: 4660は0x3412000000000000)。

Integer: 符号なし、2バイト、リトル・エンディアン

リトル・エンディアン・フォーマットの2バイトの符号なし整数(例: 65000は0xE8FD)。

Integer: 符号なし、4バイト、リトル・エンディアン

リトル・エンディアン・フォーマットの4バイトの符号なし整数(例: 65000は0xE8FD0000)。

Integer: 符号なし、8バイト、リトル・エンディアン

リトル・エンディアン・フォーマットの8バイトの符号なし整数(例: 65000は0xE8FD000000000000)。

Literal

value属性の内容によって決定されるリテラル値。非XMLデータからXMLへの変換時、指定されたリテラルが非XMLデータに存在するかどうかがWLXTによって検証されます。リテラルは読み込まれるがXMLデータには変換されません。XMLデータから非XMLフォーマットへの変換で、リテラルが非XMLフォーマットの一部として定義されている場合、リテラルは変換後の非XMLバイト・ストリームに書き込まれます。

数値

数値(0 - 9)のみの文字列。長さ、長さフィールド、デリミタ、またはデリミタ・フィールドが必要です。

Packed Decimal: 符号付き

IBMの符号付きパック形式。長さ、長さフィールド、デリミタ、またはデリミタ・フィールドを指定する必要があります。長さまたは長さフィールドでは、このフィールドのサイズをバイト単位で指定する必要があります。

Packed Decimal: 符号なし

IBMの符号なしパック形式。長さ、長さフィールド、デリミタ、またはデリミタ・フィールドを指定する必要があります。長さまたは長さフィールドでは、このフィールドのサイズをバイト単位で指定する必要があります。

String

文字列。長さ、長さフィールド、デリミタ、またはデリミタ・フィールドが必要です。Stringデータ型に長さ、長さフィールド、デリミタのいずれも指定されていない場合は、「\x00」(NUL文字)が指定されているものと見なされます。

String: NULで終了

固定長フィールド内に含まれ、必要に応じてNUL (\x00)で終了される文字列。このフィールドのデータ型には、読み込むデータ量を決定する長さ属性または長さフィールドが必要です。このデータのNULデリミタの有無が調べられます。デリミタが検出されるとそれ以降のデータが破棄されます。NULデリミタが存在しない場合、固定長データがフィールドの値として使用されます。

Time: hhmmss

時刻を定義する文字列(例: 122400)。

Time: hh:mm AM

時刻を定義する文字列(例: 12:24 AM)。

Time: hh:mm

時刻を定義する文字列(例: 12:24)。

Time: hh:mm:ss AM

時刻を定義する文字列(例: 12:24:00 AM)。

Time: hh:mm:ss

時刻を定義する文字列(例: 12:24:00)。

Zoned Decimal: 先行符号

符号付きゾーン10進数形式(US-ASCIIまたはEBCDIC)。符号は最初のニブルに含まれます。長さ、長さフィールド、デリミタ、またはデリミタ・フィールドを指定する必要があります。長さまたは長さフィールドでは、このフィールドのサイズをバイト単位で指定する必要があります。

注意: このデータ型はMessage Format Languageバージョン2.02のUS-ASCIIデータでのみサポートされます。

Zoned Decimal: 先行分離符号

符号付きゾーン10進数形式(US-ASCIIまたはEBCDIC)。符号は最初のバイトに含まれます。最初のバイトには符号のみが含まれ、数値とは分離されています。長さ、長さフィールド、デリミタ、またはデリミタ・フィールドを指定する必要があります。長さまたは長さフィールドでは、このフィールドのサイズをバイト単位で指定する必要があります。

注意: このデータ型はMessage Format Languageバージョン2.02のUS-ASCIIデータでのみサポートされます。

Zoned Decimal: 符号付き

符号付きゾーン10進数形式(US-ASCIIまたはEBCDIC)。長さ、長さフィールド、デリミタ、またはデリミタ・フィールドを指定する必要があります。長さまたは長さフィールドでは、このフィールドのサイズをバイト単位で指定する必要があります。

注意: このデータ型はMessage Format Languageバージョン2.02のUS-ASCIIデータでのみサポートされます。

Zoned Decimal: 後続分離符号

符号付きゾーン10進数形式(US-ASCIIまたはEBCDIC)。符号は最後のバイトに含まれます。最後のバイトには符号のみが含まれ、数値とは分離されています。長さ、長さフィールド、デリミタ、またはデリミタ・フィールドを指定する必要があります。長さまたは長さフィールドでは、このフィールドのサイズをバイト単位で指定する必要があります。

注意: このデータ型はMessage Format Languageバージョン2.02のUS-ASCIIデータでのみサポートされます。

Zoned Decimal: 符号なし

符号なしゾーン10進数形式(US-ASCIIまたはEBCDIC)。長さ、長さフィールド、デリミタ、またはデリミタ・フィールドを指定する必要があります。長さまたは長さフィールドでは、このフィールドのサイズをバイト単位で指定する必要があります。

注意: このデータ型はMessage Format Languageバージョン2.02のUS-ASCIIデータでのみサポートされます。

23.9.2 COBOL Copybook Importerのデータ型

Format Builderツールは、COBOLコピーブックをMFLファイルへ変換するためのユーティリティを提供します。表23-5に、メタデータのデータ型に変換可能なCOBOLのデータ型と、Importerによるサポートの有無を示します。これらのデータ型のサポートには制限があります。たとえば、次のフォーマットは符号なしの4バイト整数型に変換されます。

05 pic 9(5) comp-5
05 pic 9(5) comp-x

次の場合はエラーが生成されます。

05 pic X(5) comp-5
05 pic X(5) comp-x

これらの例では、pic x(5)のかわりにpic9(5) を使用できます。

この表でのサポートの定義は次のとおりです。

- サポート対象: このデータ型はImporterで正しく解析され、メッセージ・フォーマットのフィールドまたはグループに変換されます。

- サポート対象外: このデータ型はサポートされず、コピーブックのインポート時にImporterでエラーが報告されます。

- 無視: このデータ型は解析され、メッセージ・フォーマットにコメントが追加されます。対応するフィールドまたはグループは作成されません。

表23-5 COBOLのデータ型

COBOLの型

サポート

BLANK WHEN ZERO (ゾーン10進数)

サポート対象

COMP-1、COMP-2(浮動小数点)

サポート対象

COMP-3、PACKED-DECIMAL

サポート対象

COMP、COMP-4、バイナリ(整数)

サポート対象

COMP、COMP-4、バイナリ(固定長)

サポート対象

COMP-5、COMP-X

サポート対象

DISPLAY(英数字)

サポート対象

DISPLAY数値(ゾーン10進数)

サポート対象

編集済英数字

サポート対象

編集済浮動小数点値

サポート対象

編集済数値

サポート対象

グループ・レコード

サポート対象

INDEX

サポート対象

JUSTIFIED RIGHT

無視

OCCURS(固定配列)

サポート対象

OCCURS DEPENDING(可変長)

サポート対象

OCCURS INDEXED BY

無視

OCCURS KEY IS

無視

POINTER

サポート対象

PROCEDURE-POINTER

サポート対象

REDEFINES

サポート対象

SIGN IS LEADING SEPARATE (ゾーン10進数)

サポート対象

SIGN IS TRAILING (ゾーン10進数)

サポート対象

SIGN IS TRAILING SEPARATE (ゾーン10進数)

サポート対象

SIGN IS LEADING (ゾーン10進数)

サポート対象

SYNCHRONIZED

無視

66 RENAMES

サポートされません

66 RENAMES THRU

サポートされません

77レベル

サポート対象

88レベル(条件付き)

無視

Importerでは、ベンダー固有の一部の拡張が認識されませんが、ANSI標準COBOLに準拠するコピーブック文はすべて正しく解析されます。Importerのデフォルトのデータ・モデルはIBMのメインフレーム・モデルに基づいており、Format Builderで変更することによって文字セットとデータの「エンディアン特性」を補正できます。

コピーブックのインポート時、フィールドは一般的なデータ型として識別されますが、目視で調べるとより詳細なデータ型を簡単に特定できる場合があります。そのため、Copybook Importerでは、コピーブックで検出された各フィールドにコメントが作成されます。この情報は、MFLデータを編集して元のコピーブックのデータをより適切に表す場合に役立ちます。

たとえば、次の元のコピーブックのエントリを考えます。

05 birth-date    picxx/xx/xx

これはEBCDICタイプのフィールドで、長さは8になります。さらによく見てみると、これは日付フォーマットを表しており、Date: MM/DD/YYタイプまたはData: DD/MM/YYタイプのフィールドとして定義できます。

23.9.3 サポートされていないC言語機能

Format Builderツールは、C構造をMFLファイルへ変換するためのユーティリティを提供しています。この項では、メタデータのデータ型に変換できないC言語構造体を示します(この変換は設計時に行われます)。C Struct Importerユーティリティでは、匿名ユニオン、ビット・フィールド、またはインライン・アセンブラ・コードを含むファイルは解析されません。ここでは、#include <windows.h>文を含むhello.cファイルのプリプロセッサ出力の一部を例にサポートされていない機能を示します。

- 匿名ユニオン

#line 353 "e:\\program files\\microsoft visual studio\\vc98\\include\\winnt.h"
typedef union_LARGE_INTEGER{
struct {
DWORD LowPart;
LONG HighPart;
};
struct {
DWORD LowPart;
LONG HighPart;
} u;
#line 363 "e:\\program files\\microsoft visual studio\\vc98\\include\\winnt.h"
LONGLONG QuadPart;
} LARGE_INTEGER

- ビット・フィールド

typedef struct_LDT_ENTRY {
WORD LimitLow;
WORD BaseLow;
union {
struct {
BYTE BaseMid;
BYTE Flags1;
BYTE Flags2;
BYTE BaseHi;
} Bytes;
struct
DWORD BaseMid : 8;
DWORD Type : 5;
DWORD Dpl : 2;
DWORD Pres : 1;
DWORD LimitHi : 4;
DWORD Sys : 1;
DWORD Reserved_0 : 1;
DWORD Default_Big : 1;
DWORD Granularity : 1;
DWORD BaseHi : 8;
} Bits;
} HighWord;
} LDT_ENTRY, *PLDT_ENTRY;

- インライン・アセンブラ・コード

_inline ULONGLONG
_stdcall
Int64ShrlMod32(
ULONGLONG Value,
DWORD ShiftCount
)
{
_asm {
mov ecx, ShiftCount
mov eax, dword ptr [Value]
mov edx, dword ptr [Value+4]
shrd eax, edx, cl
shr edx, cl
}
}

23.10 Format Builderのフィールド参照

この項では、Format Builderウィンドウと、Format Builderウィンドウに表示される各プロパティについて説明します。

- Format Builderウィンドウ

- Format Builderのツール・バー

- Format Builderのツリー・ペイン

- フィールド構成ウィンドウ

- グループ構成ウィンドウ

- Format Builderの参照構成ウィンドウ

23.10.1 Format Builderウィンドウ

Format Builderのメイン・ウィンドウは2つのペインに分かれています。左ペインには、データ・フォーマットの構造情報が表示されます。右ペインには、左ペインで選択した項目の詳細が表示されます。

23.10.2 Format Builderのツール・バー

次のメニュー・バー・オプションを使用して、MFLファイルの構造を作成および構成できます。使用できるメニューは、左ペインで選択されている項目に応じて異なります。

要素

説明

新規

新しいメッセージ・フォーマットを作成します。

開く

既存のメッセージ・フォーマットを開きます。

保存

現在のメッセージ・フォーマットを保存します。

切取り

左ペインで現在選択されている項目とその子オブジェクトをツリーから切り取ります。

注意: メッセージ・フォーマット(ルート)項目が選択されている場合、このコマンドは使用できません。

コピー

左ペインで現在選択されている項目をツリーの他の場所に挿入するために、コピーを作成します。

注意: メッセージ・フォーマット(ルート)項目が選択されている場合、このコマンドは使用できません。

兄弟として貼付け

切り取った、またはコピーした項目を、選択した項目の兄弟オブジェクトとして挿入します。

参照として貼付け

切り取った、またはコピーした項目の参照を、選択した項目の兄弟オブジェクトとして挿入します。

元に戻す

直前の操作を取り消します。ツール・チップは取消し可能な操作を反映して変化します。たとえば、フィールドの名前をField1に変更して「適用」をクリックすると、ツールチップに「フィールドField1への適用の再実行」が表示されます。

注意: Format Builderでは、複数レベルの取消し操作とやり直し操作がサポートされています。

再実行

「元に戻す」コマンドの結果を取り消します。ツール・チップはやり直し可能な操作を反映して変化します。たとえば、フィールドの名前をField1に変更して「元に戻す」をクリックすると、ツールチップに「フィールドField1への適用の再実行」が表示されます。

注意: Format Builderでは、複数レベルの取消し操作とやり直し操作がサポートされています。

フィールドの挿入

フィールドを、ツリー・ペインで選択した項目の兄弟として挿入します。

グループの挿入

グループを、ツリー・ペインで選択した項目の兄弟として挿入します。

コメントの挿入

コメントを、ツリー・ペインで選択した項目の兄弟として挿入します。

上に移動

選択した項目を、その親の中でポジションを1つ上に移動します。

下に移動

選択した項目を、その親の中でポジションを1つ下に移動します。

項目の昇格

選択した項目を、ツリー内のすぐ上のレベルに昇格させます。たとえば、Field1がGroup1の子オブジェクトであるとします。Field1を選択して「昇格」をクリックすると、それがGroup1の兄弟になります。

項目の降格

選択した項目を、ツリー内のすぐ下のレベルに降格させます。たとえば、Group1がField1の兄弟であるとします。ツリー内でField1はGroup1のすぐ次にあります。Field1を選択して「降格」をクリックすると、それがGroup1の子になります。

すべて開く

ツリー・ペイン内のすべての項目を展開し、子項目を表示します。

すべて閉じる

ツリー・ペインを折りたたんで、最初のレベルの項目のみを表示します。

Format Tester

「Format Tester」ウィンドウを開きます。

23.10.3 Format Builderのツリー・ペイン

ツリー・ペインには、ツリー内の非XMLデータのフォーマットに関する階層情報および構造情報が表示されます。ツリーのルート・ノードは作成中または編集中のMFLドキュメントに対応し、このルート・ノードの下にグループとフィールドを作成できます。ツリー・ペインで作成できる様々なタイプの要素を次に示します。

メッセージ・フォーマット、フィールドおよびグループは名前によって識別され、この名前は非XMLデータをXMLへ変換するときにXMLタグとして使用されます。そのため、名前はXMLの命名規則に準拠する必要があります。

フォーマット・ツリー内のノードに名前を付けるときは、次のガイドラインに従ってください。

- 先頭は文字またはアンダースコアでなければなりません。

- 文字、数字、コロン、ピリオド記号、ハイフン記号およびアンダースコア記号を使用できます。

要素

説明

メッセージ・フォーマット

最上位レベル(ルート)の要素です。

グループ

フィールド、コメント、あるいは何らかの関係があるその他のグループまたは参照の集合です。たとえば、フィールドPAYDATE、HOURSおよびRATEは、PAYINFOグループに含めることができます。そのグループに含まれるすべての項目のフォーマットを定義します。

オプションのグループ

メッセージ・フォーマットに任意で含めることができるグループ。このタイプのグループは、周囲を点線で囲んだアイコンによって表されます。

繰返しグループ

1回または複数回出現するグループ。このタイプのグループは、カスケード・アイコンによって表されます。

オプションの繰返しグループ

任意で使用できるが、使用する場合は複数回出現するグループ。

グループ参照

グループの別のインスタンスがデータ内に存在することを示します。参照グループのフォーマットは元のグループと同じですが、参照グループのOptional設定とOccurrence設定は変更できます。

グループ選択

グループ内の1項目のみを、メッセージ・フォーマットに取り込むことを示します。このタイプのグループは、アイコン内のドットによって表されます。

フィールド

アプリケーションにとって何らかの意味を持つバイト・シーケンスです。たとえば、フィールドEMPNAMEには、従業員名が入力されます。フィールドのフォーマットを定義します。

オプションのフィールド

該当するメッセージ・フォーマットに任意で使用できるフィールド。

繰返しフィールド

1回または複数回出現するフィールド。

フィールド参照

フィールドの別のインスタンスがデータ内に存在することを示します。参照フィールドのフォーマットは元のフィールドと同じですが、参照フィールドのOptional設定とOccurrence設定は変更できます。

オプションの繰返しフィールド

該当するメッセージ・フォーマットに任意で使用できるが、使用する場合は複数回出現するフィールド。

コメント

メッセージ・フォーマット、またはメッセージ・フォーマットによって変換されたデータについてのメモが含まれることを示します。

折りたたむ

オブジェクトの横のマイナース記号は、そのオブジェクトを折りたためることを示します。

展開

オブジェクトの横のプラス記号は、そのオブジェクトを展開して他のオブジェクトを表示できることを示します。

23.10.4 フィールド構成ウィンドウ

フィールド構成ウィンドウは、メッセージ・フォーマットに含めるフィールドを定義します。これらのフィールドは、アプリケーションに関連する意味を持つバイト・シーケンスです。たとえば、フィールドEMPNAMEは従業員名を意味します。

表23-6 Format Builderのフィールド説明プロパティ

要素

説明

名前

フィールドの名前。この名前はXML要素の命名規則に準拠する必要があります。

オプション

このチェック・ボックスを選択すると、フィールドはオプションになります。つまり、当該フィールドのデータが入力に存在する可能性があることを意味します。

ファイルに対してこのオプションを選択した場合は、フィールド属性ペインの「タグ付きフィールド」オプションも設定できます。さらに、「タグ付きフィールド」テキスト・ボックスで、グループ内のオプション・フィールドごとに一意の値を入力します。複数のグループで同じタグ値を使用できますが、グループ内のオプション・フィールドごとのタグ値は一意である必要があります。

タイプ

使用可能なオプションのリストからフィールドのデータ型を選択します。デフォルトの型は文字列です。

注意: 選択したフィールドのデータ型によって、ダイアログの他の領域に表示されるフィールド・データのオプションが決まります。

メッセージ・フォーマット内でこのフィールドが出現する回数を示す、表23-7のオプションの1つを選択します。

表23-7 Format Builderのフィールド出現プロパティ

要素

説明

1回

フィールドを1回だけ表示する場合は、このオプションを選択します。

注意: 省略可能として定義されていないかぎり、フィールドは少なくとも1回出現します。

繰返しのデリミタ

指定されたデリミタが見つかるまでフィールドを繰返し出現させる場合は、このオプションを選択します。関連付けられたフィールドにデリミタを入力します。

繰返しフィールド

実行時の繰返しフィールドの値でフィールドの繰返し回数を示す場合は、このオプションを選択します。使用可能なオプションのリストから繰返しフィールドの名前を選択します。

繰返し回数

指定された回数のみフィールドを繰返し出現させる場合は、このオプションを選択します。関連付けられたフィールドに出現回数を入力します。

無制限

無限にフィールドを繰返し出現させる場合は、このオプションを選択します。

表23-8 Format Builderのフィールド属性

要素

説明

タグ付きフィールド

タグ付きフィールドの場合はこのオプションを選択します。タグ付きでは、データの先頭にリテラルが付加されています。たとえば、SUP:ACME INCの場合、SUP:はタグです。ACME INCはフィールド・データです。

タグ付きフィールド・オプションを選択した場合は、チェック・ボックスの右にあるテキスト・ボックスにタグを入力します。

フィールドのデフォルト値

フィールドにデフォルト値がある場合はこのオプションを選択します。次に、チェック・ボックスの右にあるテキスト・ボックスにデフォルト値を入力します。

データ・ベース・タイプ

フィールドが日付または時間フィールドの場合に、データを構成する文字のタイプが決定されることを示します。このフィールドが表示されるかどうかは、「フィールドの説明」セクションの「型」フィールドで選択されたデータ型に基づきます。

年号カットオフ

日付フィールドに年号が2桁で入力されている場合、年号カットオフにより、2桁で表された年号を4桁の年号に変換できます。年号を表す2桁の数値が年号カットオフ値と等しいかそれを上回る場合は、年号の値に「19」という接頭辞が付加されます。それ以外の場合は「20」という接頭辞が付加されます。

このフィールドが表示されるかどうかは、「フィールドの説明」セクションの「型」フィールドで選択されたデータ型に基づきます。

コード・ページ

コード・ページは、文字列フィールドのデータをエンコードします。このフィールドが表示されるかどうかは、「フィールドの説明」セクションの「型」フィールドで選択されたデータ型に基づきます。

値

リテラル・フィールドに表示される値。このフィールドが表示されるかどうかは、「フィールドの説明」セクションの「型」フィールドで選択されたデータ型に基づきます。

表23-9 Format Builderの長さで定義されるフィールド終了プロパティ

要素

説明

「長さ」タブ

値

長さフィールドが可変長の場合、長さフィールドのバイト数を入力します。

可変長のデータ型に固定長を割り当てることができます。これにより、デリミタを使用してフィールドの終了点を指定する必要がなくなります。

文字列長(文字数)

文字列がバイト数ではなく文字数で長さを計算するマルチバイト・エンコードの場合は、このチェック・ボックスを選択します。デフォルトでは、文字列長はバイト単位です。

切捨てタブ

後続の切捨て

フィールド・データの後続エッジのデータを切り捨てるには、このオプションを選択します。このオプションの横にあるフィールドに切り捨てるデータを入力します。

先行の切捨て

フィールド・データの先行エッジのデータを切り捨てるには、このオプションを選択します。このオプションの横にあるフィールドに切り捨てるデータを入力します。

埋込みタブ

値の埋込み

データが指定の長さよりも短い場合に、適切な長さになるまでデータに埋め込む値を入力するには、このオプションを選択します。フィールドの後ろに埋め込む場合は、後続を選択します。フィールドの先頭に埋め込む場合は、先行を選択します。

表23-10 Format Builderの埋め込み長で定義されるフィールド終了プロパティ

要素

説明

「説明」タブ

タイプ

オプションのリストから埋め込み長のタイプを選択します。

長さ

バイト数を指定するには、このオプションを選択して、対応するフィールドに数値を入力します。

可変長のデータ型の終了点を埋め込み長で指定できます。埋め込み長はデータ・フィールドに先行して、データに含まれるバイト数を示します。このオプションは、埋め込み長に特定のデータ型が選択されている場合のみ使用可能です。

デリミタ

デリミタを指定するには、このオプションを選択して、対応するフィールドにデリミタ値を入力します。このオプションは、埋め込み長に特定のデータ型が選択されている場合のみ使用可能です。

タグ/長さの順序タブ

長さの後にタグ・フィールドを表示

長さフィールドとタグ・フィールドの両方が存在する場合に、タグ・フィールドの前に長さフィールドを表示するには、このオプションを選択します。デフォルトでは、タグが長さの前に表示されます。

切捨てタブ

後続の切捨て

フィールド・データの後続エッジのデータを切り捨てるには、このオプションを選択します。このオプションの横にあるフィールドに切り捨てるデータを入力します。

先行の切捨て

フィールド・データの先行エッジのデータを切り捨てるには、このオプションを選択します。このオプションの横にあるフィールドに切り捨てるデータを入力します。

表23-11 Format Builderのデリミタで定義されるフィールド終了プロパティ

要素

説明

「デリミタ」タブ

可変長のデータ型の終了点をデリミタで指定できます。デリミタは直接指定することも、文字を含むフィールドによって指定することもできます。デリミタとは、フィールドの終わりをマークする文字。フィールド・データはデリミタが見つかるまで続きます。

参照フィールド

このボタンをクリックすると、終了点を示すデリミタ文字を含むフィールドを指定できます。表示されたダイアログで参照フィールドを選択し、右矢印ボタンをクリックします。「OK」をクリックします。

値

デリミタ・フィールドが存在しない場合に使用するデフォルトのデリミタ文字を入力します。デフォルト値を指定する必要があります。

切捨てタブ

後続の切捨て

フィールド・データの後続エッジのデータを切り捨てるには、このオプションを選択します。このオプションの横にあるフィールドに切り捨てるデータを入力します。

先行の切捨て

フィールド・データの先行エッジのデータを切り捨てるには、このオプションを選択します。このオプションの横にあるフィールドに切り捨てるデータを入力します。

次のフィールドは、「フィールドの説明」セクションの「型」フィールドで「リテラル」を選択した場合のみ表示されます。

表23-12 Format Builderのリテラル・データ型のフィールド・プロパティ

要素

説明

値

リテラル値を指定することを示します。リテラル値は、単一の値として定義することも、リテラル・セパレータで区切られた値のリストとして定義することもできます。「値」が値のリストの場合、バイナリ・データのリテラル・フィールドのデータはリスト内のいずれかの値になります。

リテラル・セパレータ

リテラル値の列挙をサポートします。MFL定義のリテラル型の「Field」で、「Field」に値の複数の選択肢が必要な場合、リテラル・セパレータを指定できます。

たとえば、EDIFACTおよびX12 EDI標準でサポートされるセグメント・ターミネータは、\r\n\、\r、\n、`、および~です。ただし、Format Builderを使用することでその他のすべてのカスタム・ターミネータをサポートできます。また、リテラル値の既存のリストにカスタム・ターミネータを追加することも、リテラル・セパレータとしてカンマ(,)を使用して複数のカスタム値を分離することも可能です。

MFLファイルには、次の構造が必要です。

<FieldFormat name='ISA_Terminator' type='Literal' value='\r\n,\r,\n,~,|' literalSeparator=','/>

23.10.5 グループ構成ウィンドウ

グループ構成ウィンドウは、メッセージ・フォーマットに含めるグループを定義します。グループは、フィールド、コメント、あるいは何らかの関係があるその他のグループまたは参照の集合です。たとえば、フィールドPAYDATE、HOURSおよびRATEは、PAYINFOグループに含めることができます。

表23-13 Format Builderのグループ説明プロパティ

要素

説明

名前

グループ名。この名前はXML要素の命名規則に準拠する必要があります。

オプション

グループがオプションの場合は、「オプション」を選択します。

子の選択

グループ内の1項目のみをメッセージ・フォーマットに取り込む場合は、子の選択を選択します。

メッセージ・フォーマット内でこのグループが出現する回数を示す、表23-14のオプションの1つを選択します。

表23-14 Format Builderのグループ出現プロパティ

要素

説明

1回

グループを1回のみ表示する場合は、このオプションを選択します。

注意: オプションとして定義されている場合を除き、グループは少なくとも1回出現します。

繰返しのデリミタ

指定されたデリミタが見つかるまでグループを繰返し出現させる場合は、このオプションを選択します。関連付けられたフィールドにデリミタを入力します。

繰返しフィールド

実行時の繰返しフィールドの値でグループの繰返し回数を示す場合は、このオプションを選択します。使用可能なオプションのリストから繰返しフィールドの名前を選択します。

繰返し回数

指定された回数のみグループを繰返し出現させる場合は、このオプションを選択します。関連付けられたフィールドに出現回数を入力します。

無制限

無限にグループを繰返し出現させる場合は、このオプションを選択します。

表23-15 Format Builderのグループ属性

要素

説明

タグ付きグループ

タグ付きグループの場合はこのオプションを選択します。タグ付きの場合、データの先頭にリテラルが付加されて、そのデータが存在することを示します。

タグ付きグループ・オプションを選択した場合、チェック・ボックスの右にあるテキスト・ボックスにタグを入力します。

表23-16 Format Builderのグループ・デリミタ・プロパティ

要素

説明

なし

グループにデリミタがない場合はこのオプションを選択します。

デリミタ付き

グループの終端を、グループの終了点を示すデリミタでマークする場合は、このオプションを選択します。デリミタは、フィールドのグループの終わりをマークする文字列。グループは、デリミタが見つかるまで続きます。

このオプションを選択した場合は、「値」フィールドにデリミタを入力します。

注意: 通常、グループにはデリミタを使用しません。グループは通常、内容に基づいて解析されます(グループはすべての子オブジェクトの解析が完了した時点で終了します)。

デリミタ・フィールド

グループの終了点を、デリミタ文字列を含むフィールドで指定する場合は、このオプションを選択します。このオプションを選択した場合は、デリミタ文字列を含むフィールドを選択し、さらに前述のフィールドがデータ内に存在しない場合に使用されるデフォルトのデリミタ文字を入力します。この値は必須です。

デリミタの共有

デリミタによって、データのグループの終わりおよびグループ内での最後のフィールドの終わりをマークする場合は、このオプションを選択します。このデリミタは、グループ内およびグループ内の最後のフィールドによって共有され、データの終わりを区切ります。

デリミタは非オプション

グループが存在しない場合でも、バイナリ・データにデリミタを含めることを示すには、このオプションを選択します。

23.10.6 Format Builderの参照構成ウィンドウ

「参照構成」ウィンドウを使用して、データ内の別のフィールドまたはグループ・フォーマットの存在を示すことができます。参照フィールドまたは参照グループのフォーマットは元のフィールドまたはグループと同じですが、参照フィールドまたは参照グループのOptional設定とOccurrence設定は変更できます。たとえば、「請求先」住所と「届け先」住所がデータに含まれる場合、住所フォーマットの定義は1回で済みます。「請求先」住所定義を作成し、「届け先」住所には参照を作成します。

参照には、元の項目と同じ名前が付けられます。たとえば、「請求先」住所定義と「届け先」住所定義には同じ名前が付けられます。

表23-17 Format Builderの参照説明プロパティ

要素

説明

名前

名前は、この参照を作成した元のフィールドまたはグループの名前を示しています。この名前はXML要素の命名規則に準拠する必要があります。

オプション

参照フィールドまたは参照グループがオプションの場合は、「オプション」を選択します。

表23-18 Format Builderの参照出現プロパティ

要素

説明

1回

参照を1回のみ表示する場合は、このオプションを選択します。

注意: オプションとして定義されている場合を除き、参照は少なくとも1回出現します。

繰返しのデリミタ

指定されたデリミタが見つかるまで参照を繰返し出現させる場合は、このオプションを選択します。関連付けられたフィールドにデリミタを入力します。

繰返しフィールド

実行時の繰返しフィールドの値で参照の繰返し回数を示す場合は、このオプションを選択します。使用可能なオプションのリストから繰返しフィールドの名前を選択します。

繰返し回数

指定された回数のみ参照を繰返し出現させる場合は、このオプションを選択します。関連付けられたフィールドに出現回数を入力します。

無制限

無限に参照を繰返し出現させる場合は、このオプションを選択します。

24 JavaコールアウトおよびPOJOの使用方法

この章では、パイプラインおよび分割-結合内からカスタムJavaコードを呼び出すことで、Service Busの機能を拡張する方法について説明します。Service Busのパイプラインと分割-結合は、それぞれJavaコールアウト・アクションを備えており、それによってパイプラインまたは分割-結合の外部のPlain Old Java Object (POJO)を呼び出すことができます。

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

- Javaコールアウトの概要

- ストリーミング・コンテンツの操作

- JavaコールアウトおよびPOJOのベスト・プラクティス

POJOへのJavaコールアウトの構成については、「コンソールでのJavaコールアウト・アクションの追加」を参照してください。

24.1 Javaコールアウトの概要

Javaコールアウト・アクションによって、Javaアーカイブ(JAR)ファイル内のメソッドにアクセスし、自身のパイプラインおよび分割-結合に処理ロジックを追加できます。コールアウトを構成するときに、メソッドの引数を指定でき、必要に応じてセキュリティのためのサービス・アカウントを指定できます。パラメータは、メッセージ・コンテキスト変数にマップできます。静的メソッドには、どのPOJOからもアクセスできます。

また、 Javaコールアウトを使用してJavaオブジェクトを作成し、パイプラインに格納したり、Javaオブジェクトをパラメータとして他のJavaコールアウトに渡したりすることもできます。

ヒント:

JSON型変数は、その文字列化表現でjava.lang.String型の引数に渡されます。

24.1.1 Javaコールアウトの使用のガイドライン

Service BusでJavaコールアウトを使用できるシナリオは次のとおりです。

- DTDの検証、Javaでのフィールド間のセマンティック検証などカスタム検証の実行。

- バイナリ・ドキュメントからbase64Binaryへの変換(またはその逆)、カスタムJava変換クラスの使用などのカスタム変換の実行。

- カスタム認証および認可の実行。例としては、メッセージ内のカスタム・トークンを認証および認可する必要があるシナリオがあります。ただし、Service Busは、パイプラインまたは分割-結合によって以降に呼び出されるサービスまたはPOJOに、認証されたユーザーのIDを伝播することはできません。

- メッセージに情報を追加するためのルックアップの実行。たとえば、ファイルまたはJava表を使用して、メッセージに情報を追加できる任意のデータをルックアップできます。

- バイナリ・データへのアクセス。POJOへのJavaコールアウトを使用してバイナリ・ドキュメントの最初の数バイトを検出し、MFLの型を推測できます。返されるMFL型は、次のMFL変換アクションによる非XMLからXMLへのトランスフォーメーションで使用されます。

- カスタム・ルーティング・ルールまたはルール・エンジンの実装

- Javaオブジェクトの作成とパイプラインへの格納。

- 別のJavaコールアウトへのパラメータとしてのJavaオブジェクトの受け渡し。

- JEJBプロキシ・サービスを使用したJEJBによるリモートEJB操作またはサービスの呼出し。

Javaコールアウトの入力と戻りの型は制限されていません。パイプラインでのJavaオブジェクトの格納と受け渡しの詳細は、「Body変数内のJavaコンテンツ」を参照してください。

24.1.2 JavaコールアウトまたはEJB

Enterprise JavaBeans (EJB)もJava終了メカニズムを提供します。次の場合は、Javaコールアウトではなく、EJBを使用することをお薦めします。

- すでにEJBを実装している場合。JEJBトランスポートでService Busを介してEJBコールによりEJBを呼び出し、メッセージ・ルーティング、UDDI統合、アラート、操作ごとのモニター、レポート、結果キャッシュなどのService Busの機能を利用できます。

- JDBCデータベースへの読取りアクセスが必要な場合。この目的でPOJOを使用することもできますが、EJBはこのために専用に設計されているため、JDBCリソースの管理および接続に対して、より優れたサポートを提供します。

- JDBCデータベースまたは他のJ2EEトランザクション・リソースへの書込みアクセスが必要な場合。EJBは、トランザクション・ビジネス・ロジック専用に設計されており、障害の適切な処理に対して、より優れたサポートを提供します。ただし、トランザクションとセキュリティ・コンテキスト伝播はPOJOを使用してサポートされ、JEJBトランスポートで、トランザクション・コンテキストでのエラー処理が提供されます。

アウトバウンド・メッセージには、POJOまたはEJBを使用するかわりにカスタム・トランスポートを記述することをお薦めします。

24.2 ストリーミング・コンテンツの操作

バイナリ・コンテンツを入力引数としてコールアウト・メソッドに渡すため、およびJavaコールアウト・メソッドからストリーミング・コンテンツの結果を受け入れるために、Javaコールアウトを使用してストリーミング・コンテンツを操作できます。

24.2.1 ストリーミング・コンテンツをJavaコールアウトに渡す方法

Javaコールアウト・メソッドに、バイナリ・コンテンツを入力引数としてストリーミング形式で渡すことができます。Service Busは入力引数のJavaタイプを確認して処理します。引数のタイプがjavax.activation.DataSourceの場合、システムはラッパーDataSourceオブジェクトを作成し、Source.getInputStream()メソッドを呼び出して、対応するソースからInputStreamを取得します。このメソッドは、Javaコールアウト・コードから必要なだけ何回でも呼び出すことができます。

また、getContentType()メソッドは、バイナリ・コンテンツがページングされたMIME添付ファイルでないかぎり、application/octet-streamを返します。バイナリ・コンテンツがページングされたMIME添付ファイルである場合は、対応するMIME部分のContent-Typeヘッダー(存在する場合)が使用されます。

同様に、getName()メソッドは、バイナリ・コンテンツがページングされたMIME添付ファイルでないかぎり、バイナリ・コンテンツの参照属性の文字列値を返します。バイナリ・コンテンツがページングされたMIME添付ファイルである場合は、対応するMIME部分のContent-IDヘッダー(存在する場合)が使用されます。getOutputStream()メソッドは必要に応じてUnsupportedOperationExceptionをスローします。

完了後、結果はJavaコールアウト・メソッド引数に渡されます。入力ストリームのバイナリ・オクテットを正しく解釈するために、Javaコールアウト・メソッドでContent-Transfer-Encodingヘッダーの値が必要な場合もあります(たとえば、エンコーディングがバイナリ、7ビット、8ビットのいずれであるかを判別する場合ど)。次に示すように、このパラメータを別個の引数として渡すことができます。

$attachments/*:attachment[1]/*:Content-Transfer-Encoding/text()

入力引数がDataSourceでない場合、Service Busは引数をbyte[]配列に変換します。

24.2.2 Javaコールアウトからコンテンツ結果をストリーミングする方法

Javaコールアウト・メソッドからストリーミング・コンテンツ結果を取得できます。この処理のために、Service Busは結果のJavaタイプを確認し、適切なコンテキスト変数の値を対応するctx:binary-content XML要素に設定して、新しいソースをソース・リポジトリに追加します。

注意:

Javaコールアウト・メソッドからファイルのコンテンツを返す場合、javax.activation.FileDataSourceのインスタンスを使用することができます。

パイプラインまたは分割-結合がソースのバイナリ・コンテンツを必要とする場合、ctx:binary-content要素に対応するDataSourceオブジェクトをリポジトリから検索して、バイナリ・オクテットを取得するためにDataSource.getInputStream()メソッドを呼び出します。

getInputStream()メソッドは、トランスポート・レイヤーでのアウトバウンド・メッセージの再試行に応じるなどのために、メッセージ処理時に何度も呼び出されることがあることに注意してください。

24.3 JavaコールアウトおよびPOJOのベスト・プラクティス

POJOは、Service BusでJARリソースとして登録されます。JARリソースの詳細は、「JARファイルの操作」を参照してください。

通常、JARはサイズを小さくし、簡単なものにすることをお薦めします。JARが呼び出すサイズの大きいコードまたは使用される大きなフレームワークは、システム・クラス・パスに含めることをお薦めします。システム・クラス・パスを変更する場合は、サーバーを再起動する必要があります。

従属クラスと重複クラスは同じJARリソースに入れることをお薦めします。それらが本来別のものである場合は、異なるJARリソースに入れます。JARリソースに変更を行うと、それを参照するすべてのサービスが再デプロイされます。これは、Service Busシステムにとって時間の浪費となる可能性があります。同じクラスを、競合させずに複数のJARリソースに配置できます。JARファイルは、最初に参照されたときに、動的にクラス・ロードされます。

1つまたは複数のサービスで、単一のPOJOを呼び出せます。そのサービス内のすべてのスレッドが同じPOJOを呼び出すため、POJOはスレッド・セーフである必要があります。POJOのクラスまたはメソッドは同期でき、この場合、呼出しを行うすべてのプロキシ・サービスのすべてのスレッドによるアクセスを順序付けします。POJOコードによって、任意のより詳細な並行処理(たとえば、データベース読込みの結果キャッシュへのアクセスの制御や、古いキャッシュ・エントリ処理の実装)を実装する必要があります。

通常、POJOの場合、スレッドの作成は推奨されません。

第V部 JCAアダプタ、トランスポートおよびバインドの操作

この部では、Service Busで提供されるすべてのトランスポートの情報および構成の詳細を説明します。

この部は、次の章で構成されています。

- JCAトランスポートとJCAアダプタの使用

- Oracle Service BusでのRESTサービスの作成

- DSP転送の使用

- EJBトランスポートの使用

- HTTPトランスポートおよびポーラー・トランスポートの使用

- JEJBトランスポートの使用

- JMS転送の使用

- ローカル・トランスポートの使用

- MQ転送の使用

- Oracle BPEL Process Managerトランスポートの使用

- SBトランスポートの使用

- SOA-DIRECTトランスポートの使用

- Tuxedoトランスポートの使用

- WS転送の使用

25 JCAトランスポートとJCAアダプタの使用

この章では、Oracle JCAアダプタ・フレームワークについて説明し、Service Busでの特定のアダプタの使用方法に関するガイダンスを提供します。また、Service BusサービスにおけるOracle JCAアダプタの使用方法と構成方法についても説明します。

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

- JCAトランスポートの概要

- Service BusにおけるJCAアダプタ構成の推奨事項

- JCAバインド・リソースの操作

- JavaScriptリソースの操作

- JCAトランスポート構成のリファレンス

25.1 JCAトランスポートの概要

Service Busは、バックエンドのエンタープライズ情報システム(EIS)と相互作用するJ2EEコネクタ・アーキテクチャ(JCA)トランスポートを提供しており、これにより、これらのシステムがService Bus統合環境に参加することが可能になります。JCAトランスポートでは、Service Busと外部システムの間のネイティブ接続が提供されており、これによってサービス・バス・レイヤーでのシステム間の対話が可能になり、Service Busの機能および性能を活用できます。JCAトランスポートがサポートするアダプタのリストについては、「サポートされるJCAアダプタ」を参照してください。

JCAプロキシまたはビジネス・サービスで、図25-1に示すように、EISシステムと対話するよう、JCAトランスポートが組込みJCAアダプタ・フレームワークおよびJCA準拠のアダプタと連携して動作します。実線の矢印はリクエストを示し、点線の矢印はレスポンスを示します。

図25-1 EISと対話するService Busサービス

JCAプロキシ・サービスは、サポートされるアダプタを介したEISエンドポイントを呼び出すサポート対象のJCAアダプタおよびJCAビジネス・サービスからのインバウンド・リクエストをリスニングします。

25.1.1 サポートされるJCAアダプタ

JCAアダプタを使用すると、プロキシおよびビジネス・サービスを、データベース、ファイル・システム、FTPサーバー、メッセージング・システム、電子メール、LDAP、Coherenceキャッシュ、クラウド・サービスおよびOracle E-Business Suiteなどのテクノロジと統合できます。JCAアダプタをService Bus概要エディタのスイムレーンにドラッグすると、アダプタ構成ウィザードが起動し、そこでアダプタの構成プロパティを定義できます。次の各項では、Service BusによってサポートされているJCAアダプタの概要を説明します。

25.1.1.1 AQアダプタ

AQアダプタを使用すると、Service Busのビジネスおよびプロキシ・サービスは、単一コンシューマまたは複数コンシューマのキューと相互作用できます。Oracle Streams AQは、関連アプリケーション間での双方向の非同期通信を実現する柔軟なメカニズムを提供します。アドバンスト・キューはOracleデータベースの機能であるため、高いスケーラビリティと信頼性を備えています。また、単一のアプリケーションを複数のキューで処理できるため、メッセージを様々な方法で分割したり、ロード・バランシングを介して別のレベルのスケーラビリティを提供したりできます。

詳細は、テクノロジ・アダプタの理解のOracle JCA Adapter for AQに関する項を参照してください。

25.1.1.2 Oracle BAM 11gアダプタ

Oracle BAM 11gアダプタは、Service Busのビジネスおよびプロキシ・サービスをOracle BAM Server 11gと統合します。Oracle BAMアダプタをService Bus概要エディタのスイムレーンにドラッグすると、アダプタ構成ウィザードが起動し、そこでアダプタのプロパティを構成できます。

詳細は、テクノロジ・アダプタの理解のアダプタとOracle Fusion Middlewareの統合に関する項を参照してください。

25.1.1.3 コヒーレンス・アダプタ

Oracle Coherenceアダプタは、Service Busのビジネス・サービスをOracle Coherenceと統合します。Coherenceキャッシュは、データベースとクライアント・アプリケーションの間の仲介として機能するデータ・オブジェクトの集合です。データベース・データをキャッシュにロードして、異なるアプリケーションで使用できます。Coherenceキャッシュは、データベースの負荷を削減し、データベース・データへのより高速なアクセスを提供します。キャッシュ内のオブジェクトは、XMLまたはPlain Old Java Object (POJO)のいずれかになります。Coherenceアダプタを使用すると、Coherenceキャッシュに対して次の操作を実行できます。

- 項目の追加

- 項目の取得

- 項目の削除

- 項目の問合せ

詳細は、テクノロジ・アダプタの理解のOracle JCA Adapter for Coherenceに関する項を参照してください。

25.1.1.4 データベース・アダプタ

データベース・アダプタを使用すると、Service Busのビジネスおよびプロキシ・サービスは、JDBCを介してOracleデータベースやサード・パーティ・データベースと通信できます。

詳細は、テクノロジ・アダプタの理解のOracle JCA Adapter for Databaseに関する項を参照してください。

25.1.1.5 ファイル・アダプタ

ファイル・アダプタを使用すると、Service Busのビジネスおよびプロキシ・サービスは、ローカル・ファイル・システム上でファイルを交換(読取りおよび書込み)できます。ファイル・コンテンツは、XMLデータ・フォーマットと非XMLデータ・フォーマットのどちらでも構いません。

詳細は、テクノロジ・アダプタの理解のOracle JCA Adapter for Files/FTPに関する項を参照してください。

25.1.1.6 FTPアダプタ

FTPアダプタを使用すると、Service Busのビジネスおよびプロキシ・サービスは、ファイル転送プロトコル(FTP)を使用してリモート・ファイル・システム上でファイルを交換(読取りおよび書込み)できます。ファイル・コンテンツは、XMLデータ・フォーマットと非XMLデータ・フォーマットのどちらでも構いません。

詳細は、テクノロジ・アダプタの理解のOracle JCA Adapter for Files/FTPに関する項を参照してください。

25.1.1.7 JDE Worldアダプタ

JDE Worldアダプタは、Service Busのビジネス・サービスを、IBMのミニコンピュータ上で稼働しているERP (エンタープライズ・リソース・プランニング)製品のJDE Worldシステムと統合します。JDE Worldアダプタは、IBMシステムへの新しいJDBCドライバ・ベースの接続を使用して、Service Busと、標準データベースとしてのJDE Worldシステムとの相互作用を可能にします。

詳細は、テクノロジ・アダプタの理解のOracle JCA Adapter for JDE Edwards Worldに関する項、およびOracle Technology Networkの統合アダプタ・ドキュメントに関するページを参照してください。

25.1.1.8 JMSアダプタ

JMSアダプタを使用すると、Service Busのビジネスおよびプロキシ・サービスは、Java Messaging System (JMS)と相互作用できます。JMSアーキテクチャでは、多数のメッセージング・サーバーに対して1つのクライアント・インタフェースを使用します。JMSモデルには、2つのメッセージング・ドメインがあります。

- ポイント・ツー・ポイント: メッセージはキュー経由で交換され、各メッセージは1人の受信者にのみ配信されます。

- パブリッシュ・サブスクライブ: メッセージはトピックに送信され、多数のサブスクライブ・クライアントで読み取ることができます。

詳細は、テクノロジ・アダプタの理解のOracle JCA Adapter for JMSに関する項を参照してください。

25.1.1.9 LDAPアダプタ

LDAPアダプタを使用すると、Service Busのビジネスおよびプロキシ・サービスは、LDAPディレクトリと相互作用できます。LDAPアダプタは、非同期および同期の両方のインタフェースを定義して、LDAPディレクトリ・サーバーとの間でリクエストとレスポンスを送受信します。LDAPアダプタを使用すると、プロセスは、LDAPプロトコルを使用してLDAPディレクトリを検索、比較および変更できます。

詳細は、テクノロジ・アダプタの理解のOracle JCA Adapter for LDAPに関する項を参照してください。

25.1.1.10 MQ Seriesアダプタ

MQ Seriesアダプタは、Service Busのビジネスおよびプロキシ・サービスとWebSphere MQキューイング・システムとの間のメッセージ交換機能を提供します。Messaging and Queuing Series (MQ Series)は、IBMによって開発された製品および標準のセットです。MQ Seriesは、保証されたメッセージ配信、セキュリティおよび優先度ベースのメッセージングを提供するキューイング・インフラストラクチャを備えています。

詳細は、テクノロジ・アダプタの理解のOracle JCA Adapter for MQ Seriesに関する項を参照してください。

25.1.1.11 MSMQアダプタ

MSMQアダプタは、Service Busのビジネスおよびプロキシ・サービスとMicrosoft Message Queueing (MSMQ)との間のメッセージ交換機能を提供します。MSMQはメッセージ・インフラストラクチャであり、分散され疎結合されたメッセージング・アプリケーションを作成するためのMicrosoft Windowsオペレーティング・システム向けの開発プラットフォームです。

詳細は、テクノロジ・アダプタの理解のOracle JCA Adapter for Microsoft Messaging Queueに関する項を参照してください。

25.1.1.12 Oracle E-Business Suiteアダプタ

Oracle E-Business Suiteアダプタを使用すると、Service Busのビジネスおよびプロキシ・サービスは、E-Business Suiteと相互作用できます。このアダプタは、Oracle E-Business Suiteのバージョンに基づくカスタム統合インタフェース・タイプの選択をはじめ、Oracle E-Business Suiteリリース12およびリリース11iのすべてのモジュールをサポートしています。

詳細は、Oracle Fusion Middleware Oracle E-Business Suiteアダプタ・ユーザーズ・ガイドを参照してください。

25.1.1.13 Salesforceクラウド・アダプタ

Salesforceクラウド・アダプタを使用すると、Service Busのビジネス・サービスは、Salesforceサービスと相互作用できます。SalesforceのEnterprise、UnlimitedまたはDeveloperのエディションとの統合を可能にし、様々なシステムをSalesforceに接続して、SalesforceのSOAP APIを活用できます。

詳細は、Oracle Technology Networkの統合アダプタ・ドキュメントに関するページを参照してください。

25.1.1.14 SAPアダプタ

パッケージ・アプリケーション・アダプタであるSAPアダプタを使用すると、Service Busのビジネスおよびプロキシ・サービスをSAPアプリケーションと統合できます。

詳細は、テクノロジ・アダプタの理解のパッケージ・アプリケーション・アダプタに関する項、およびOracle Technology Networkの統合アダプタ・ドキュメントに関するページを参照してください。

25.1.1.15 ソケット・アダプタ

ソケット・アダプタを使用すると、クライアントまたはサーバー・ソケットを作成して接続を確立できます。このアダプタを使用して、TCP/IPソケットを介して通信するための標準または非標準プロトコルをモデル化できます。転送されるデータのフォーマットはテキストまたはバイナリです。

詳細は、テクノロジ・アダプタの理解のOracle JCA Adapter for Socketsに関する項を参照してください。

25.1.1.16 サード・パーティ・アダプタ

サード・パーティ・アダプタを使用すると、Service Busのビジネスおよびプロキシ・サービスを、PeopleSoftやSAPなどのサード・パーティ・アダプタと統合できます。これらのサード・パーティ・アダプタは、JCAアダプタを構成できるアーティファクト(WSDLおよびJCAファイル)を生成します。

詳細は、テクノロジ・アダプタの理解のパッケージ・アプリケーション・アダプタに関する項を参照してください。

25.1.1.17 ユーザー・メッセージング・サービス・アダプタ

Oracle User Messaging Serviceは、電子メール、セキュア・メッセージング・サービス(SMS)、インスタント・メッセージングおよびボイスなどのメッセージング・チャネルをサポートしています。Oracle User Messaging Serviceは、Service Busのビジネスおよびプロキシ・サービスと外部との間のメッセージング・プロキシを提供します。Oracle User Messaging Serviceには、2つのメッセージング方法(インバウンドおよびアウトバウンド)があります。

詳細は、テクノロジ・アダプタの理解のOracle JCA Adapter for UMSに関する項を参照してください。

25.1.2 Oracle JCAアダプタの制約事項

Service Busで一部のJCAアダプタを使用する際の制約事項を次に示します。

- すべてのJCAアダプタに適用される制約事項

- ファイル/FTP用のOracle JCAアダプタの制約事項

25.1.2.1 すべてのJCAアダプタに適用される制約事項

JCAトランスポートでは、アクティブ/パッシブ・トポロジでシングルトン・エンドポイント・プロパティがサポートされません。

25.1.2.2 ファイル/FTP用のOracle JCAアダプタの制約事項

ファイル/FTP用のOracle JCAアダプタでは、JCAトランスポートで、ファイルの前処理と後処理、ZIPファイル処理用のリエントラント・バルブの使用、ファイルのチャンク読取りがサポートされません。

25.1.3 JCAアダプタ・フレームワーク

JCAトランスポートはService Bus JCAアダプタ・フレームワークを使用して、外部EISサービスに接続を提供するJCA準拠のアダプタと対話します。JCAアダプタ・フレームワークは、これらのアダプタと対話する複雑さを除去してくれるため、ユーザーはプロキシおよびビジネス・サービス開発に集中できます。

インバウンド対話では、JCAプロキシ・サービスは関連するJCAアダプタ・エンドポイントにリスナーを登録します。JCAプロキシにメッセージを送信したEISシステムにイベントが発生すると、JCAアダプタ・フレームワークによりリクエストのみのパターンまたはリクエスト/レスポンスのパターンのプロキシ・サービスが呼び出されます。アウトバウンド対話で、クライアントがService Busを介してEISサービスを呼び出すと、JCAビジネス・サービスによりJCAアダプタ・フレームワークを介してJCAアダプタ・エンドポイントが呼び出されます。

JCAアダプタ・フレームワークの構成は不要です。JCAプロキシ・サービスおよびビジネス・サービスを作成し、アダプタをデプロイすると、JCAアダプタ・フレームワークはデプロイされ、自動的に機能します。

25.1.4 JCAトランスポートのメッセージング

JCAトランスポートは、SOAP 1.1を使用してリクエストのみのメッセージング・パターンおよび同期のリクエスト/レスポンスのメッセージング・パターンをサポートします。JCAトランスポートはトランザクションです。JCAプロキシ・サービスがEISトランザクションで呼び出される、またはJCAビジネス・サービスがトランザクションで呼び出されると、トランスポートによりトランザクションが伝播されます。

25.1.5 JCAトランスポートのセキュリティ

サービスでJCAトランスポートを使用する場合、JNDIサービス・アカウントがエンドポイント検証時と実行時の両方で使用されます。エンドポイント検証の際、静的サービス・アカウントにエンドポイントが関連付けられている場合、アダプタの接続ファクトリに対するJNDIルックアップが静的サービス・アカウントのサブジェクトを使用して実行されます。サービスがサービス・アカウントを使用しない場合は、匿名サブジェクトが使用されます。

実行時には、JCAプロキシ・サービス・アカウントでは静的サービス・アカウントしかサポートされません。静的サービス・アカウントがサービスで構成されている場合、アダプタの接続ファクトリに対するJNDIルックアップを実行するためにサービス・アカウントのサブジェクトが使用されます。そうでない場合は、匿名サブジェクトが使用されます。JCAビジネス・サービスでは、実行時に静的サービス・アカウント、パス・スルー・サービス・アカウントおよびマッピング・サービス・アカウントがサポートされます。サービス・アカウントがJCAビジネス・サービスで構成されている場合、アダプタ接続ファクトリおよび後続のアウトバウンド呼出しに対するJNDIルックアップは、そのサービス・アカウントのサブジェクトを使用して実行されます。サービスがサービス・アカウントを使用しない場合は、匿名サブジェクトが使用されます。

EISデータベースに接続するOracleアダプタ(データベース、AQおよびOracle E-Business Suite用のOracleアダプタ)は、アダプタで管理される接続ファクトリに関連するJDBCデータ・ソースを使用して接続します。他のOracleアダプタ(ファイル用のOracle JCAアダプタなど)は、アウトバウンド接続で、Oracle WebLogic Serverによるコンテナ管理およびアプリケーション管理のサインオンをサポートします。詳細は、テクノロジ・アダプタの理解のエンタープライズ情報システムの資格証明の保護に関する項を参照してください。

また、JCAトランスポートはOracle Web Services Manager (OWSM)ポリシーとともに使用できます。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のJCAアダプタでサポートされているOWSMポリシーに関する項を参照してください。

25.1.5.1 プロキシ・サービス

インバウンド・リクエストで、JCAプロキシ・サービスを呼び出すJCAアダプタ・フレームワークは匿名として常にプロキシ・サービスを呼び出します。

25.1.5.2 ビジネス・サービス

JCAビジネス・サービスで使用するJNDIサービス・アカウントのタイプによって、サブジェクト付きのアウトバウンド・サービス・エンドポイントが次の方法で呼び出されます。

- サービス・アカウントを使用しない。かわりに、匿名サブジェクトを使用してアウトバウンドJCAエンドポイントを呼び出します。

- パス・スルー・サービス・アカウントを使用する。インバウンド・リクエストに関連するサブジェクトを使用して、アウトバウンドJCAエンドポイントを呼び出します。

- 静的なサービス・アカウントを使用する。サービス・アカウントの静的ユーザー名/パスワードに関連するサブジェクトを使用して、アウトバウンドJCAエンドポイントを呼び出します。

- マッピング・サービス・アカウントを使用する。サービス・アカウントのマップされたユーザー名/パスワードに関連するサブジェクトを使用して、アウトバウンドJCAエンドポイントを呼び出します。

25.1.6 ロギング

JCAトランスポートは、Oracle WebLogic Server NonCatalogログ機能を使用してメッセージをロギングします。JCAアダプタ・フレームワークのログは、Oracle WebLogic Serverのログにリダイレクトされます。

デバッグ用にoracle.osb.debug.jca-framework-adapterロガーが構成されている場合のみ、JCAトランスポート、JCAアダプタ・フレームワークおよびJCAアダプタ(Oracle BAMアダプタを除く)によって生成されるデバッグ・ログ・レコードがOracle WebLogic Serverのログにリダイレクトされます。JCAフレームワークおよびアダプタのメッセージのログにはタグJCA_FRAMEWORK_AND_ADAPTERが付けられます。詳細は、『Oracle Service Busの管理』のログ・ファイルの構成と監視に関する項を参照してください。

25.1.6.1 Oracle BAM Adapterロギング

RMIベースおよびSOAPベースの接続プールを使用してOracle BAM Adapterバッチ処理のデバッグレベル・ロギングを有効にするには、次のロガー・エントリをdomain_home/config/fmwconfig/servers/server_name/logging.xmlに追加します。

- RMI/EJBの場合 - <logger name="oracle.bam.adc.api.batching.BatchProcessor" level="FINER"/>

- SOAPの場合 - <logger name="oracle.bam.adapter.adc.soap.SOAPBatchProcessor" level="FINER"/>

25.1.7 JCAトランスポートのエラー処理

JCAフレームワークおよびアダプタがEISからの例外をスローすると、JCAビジネス・サービスがその例外をjca-runtime-fault-detail要素内のSOAPフォルトに伝播します。このフォルト構造はJCAトランスポート・スキーマで定義されます。

次の1つ以上のサブ要素でEISフォルトの詳細にアクセスできます。

- eis-error-code (string): JCAフレームワークおよびアダプタによって伝播されたEISエラー・コードをキャプチャします(可能な場合)。

- eis-error-message (string): JCAフレームワークおよびアダプタによって伝播されたEISエラー・メッセージをキャプチャします(可能な場合)。

- exception (string): JCAフレームワークおよびアダプタのスタック・トレースをキャプチャします。

JCAトランスポートではアプリケーション・エラー時に再試行できず、このオプションを制御しません。このオプションを「いいえ」に設定します。

25.1.8 JCAトランスポートでのURIリライト

JCAトランスポートは、パイプラインのURIリライトをサポートします。

25.1.9 JCAトランスポートのメッセージ・エンコーディング

インバウンド・リクエストおよびアウトバウンド・レスポンスでは、JCAアダプタ・フレームワークがUTF-8エンコーディングを使用してJCAプロキシ・サービスにメッセージを送信します。

25.1.10 拒否されたメッセージ

JCAアダプタ・フレームワークにより、拒否されたメッセージ(データ・エラーのメッセージ)がアダプタごとに/domain/jca/read/rejectedMessagesディレクトリに自動的にログされます。詳細は、テクノロジ・アダプタの理解の拒否されたメッセージの処理に関する項を参照してください。

25.2 Service BusにおけるJCAアダプタ構成の推奨事項

JCAトランスポートはすべてJCAアダプタと互換性があり、各アダプタには、一連のエンドポイント・プロパティ、アクティブ化指定/相互指定プロパティ、または接続プロパティを構成できます。JCAアダプタ自体に定義された実行時プロパティまたはバインディング・プロパティは、プロキシまたはビジネス・サービスのトランスポート構成には伝播されません。それらのプロパティは手動で構成する必要があります。詳細は、「JCAトランスポート・エンドポイントのプロパティ」を参照してください。

次の各項では、Service Bus固有の構成の推奨事項について説明します。

25.2.1 JCAアダプタ接続の構成

Oracle JCAアダプタは、自動的にService Busドメインにデプロイされます。サポートされている他のサード・パーティ・リソース・アダプタは、Oracle WebLogic Server管理コンソールで手動でインストールし、デプロイする必要があります。デプロイされたOracleアダプタを使用するには、Oracle WebLogic Server内のアダプタごとに、データ・ソースと接続プールを作成する必要があります。必要なデータ・ソースと接続プールの作成に関する情報と手順は、テクノロジ・アダプタの理解のアダプタ接続ファクトリの追加に関する項を参照してください。このガイドでは、データ・ソースに関する追加情報がアダプタごとに提供されます。

25.2.2 データベースをポーリングするJCAアダプタの構成

デフォルトでは、データベースをポーリングするOracleアダプタは1スレッドを使用してデータベースをポーリングします(アクティブ化指定のNumberOfThreads=1プロパティ)。設計に基づき、アダプタはこのスレッドを解放しないため、サーバー・ログにスタック・スレッド・スタック・トレースが表示されます。NumberOfThreadsを2以上に設定すると、それらすべてのスレッドにスタック・トレースが表示されます。スタック・スレッド・スタック・トレースは無視できます。

アダプタに関するスタック・スレッド・スタック・トレースの表示を防ぐには、次の設定を含むようにワーク・マネージャを構成します。

<ignore-stuck-threads>true</ignore-stuck-threads>

JCAプロキシ・サービスで、作成したワーク・マネージャをトランスポートのディスパッチ・ポリシーが使用するように構成します。

ワーク・マネージャについては、次のトピックを参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

25.2.3 データベース用のOracle JCAアダプタの構成

特定のOracle Database表をポーリングするプロキシ・サービスは1つのみです。Oracle JCA Adapter for Databaseのデータ・ソースについては、次のオプションを設定します。

オプション

設定

初期容量

0

予約時の接続のテスト

選択済

テスト頻度

5

テスト対象の表名

SQL SELECT 1 FROM DUAL

アイドル・プール接続を信頼する秒数

0

接続作成の再試行間隔(秒)

10

25.2.4 AQ用のOracle JCAアダプタの構成

AQ用のOracle JCAアダプタのデータ・ソースでは、「予約時に接続をテスト」オプションを選択します。

25.2.5 Oracle JCA Adapter for Coherenceの構成

Coherenceキャッシュ内のオブジェクトがPlain Old Java Object (POJO)の場合は、アダプタ構成で、POJO JARファイルを保存するアーカイブ・リソースも指定します。このリソースは、Coherenceアダプタおよび関連するビジネス・サービスを作成する前に、Service Busプロジェクトで作成できます。構成ウィザードには、アップロードするJARファイルをファイル・システムで検索し、ファイルをインポートして、Service Busプロジェクトにアーカイブ・リソースを作成できるオプションも用意されています。アーカイブ・リソースの作成方法の詳細は、「JARファイルの操作」を参照してください。

25.2.6 Salesforceクラウド・アダプタの構成

Salesforceアダプタには、標準のWSDLファイルに対する依存性に加え、Salesforceから直接生成するエンタープライズWSDLファイルに対する依存性があります。このファイルは、標準のJCA WSDLファイルの他にJCAリソースにも関連付けられており、targetWSDLURLプロパティの値として、プロキシ・サービスまたはビジネス・サービスの管理対象外接続プロパティで参照されます。

25.3 JCAバインド・リソースの操作

Oracle JDeveloperやその他のサポートされているJCA開発環境を使用して、JCAアダプタを作成および構成し、バックエンドの統合に使用されるJCAアダプタ・リソース(.jcaファイルおよびWSDLファイル)を作成できます。

Oracle Service BusコンソールではJCAアダプタを作成および構成できませんが、JDeveloperで作成したアダプタをJCAバインド・リソースにアップロードできます。JCAバインド・リソースを作成したら、Service Bus JCAトランスポートを使用し、JCAアダプタを介してEISアプリケーションと通信するプロキシ・サービスおよびビジネス・サービスを生成できます。

JDeveloperでJCAアダプタを作成したら、Oracle Service Busコンソールで、そのアダプタをJCAバインド・リソースにインポートできます(Oracle Service Busコンソールが開発環境である場合)。

25.3.1 JDeveloperでのJCAアダプタの作成方法

Service Bus概要エディタでは、単純なドラッグ・アンド・ドロップ方式を使用して、JDeveloperでService Busプロジェクト内にJCAアダプタを作成できます。サポートされているJCAアダプタを「コンポーネント」ウィンドウからキャンバスにドラッグすると、そのアダプタの構成ウィザードが起動されます。ウィザードを完了すると、JCAファイルとプロキシ・サービスまたはビジネス・サービスが作成され、すべての必要なファイルがService Busプロジェクトに追加されます。

注意:

JDeveloperの概要から直接JCAアダプタを作成することにより、ビジネス・サービスまたはプロキシ・サービスを作成した場合でも、JCAトランスポートはサービスとアダプタの間の仲介として機能します。

詳細は、このガイドの「Service Busコンポーネントの追加」およびテクノロジ・アダプタの理解のOracle JCAアダプタの概要に関する項を参照してください。

25.3.2 Oracle Service BusコンソールでのJCAアダプタのインポート方法

Oracle Service BusコンソールでJCAバインド・リソースを作成する最も簡単な方法は、JDeveloperで作成したJCAリソース(JCAファイル、関連付けられているWSDLファイル、TopLinkマッピング・ファイルなど)の一括インポートによるものです。一括インポートでは、Service Busによって、自動的にJCAファイルからJCAバインドが作成され、WSDLファイルからWSDLリソースが作成され、マッピング・ファイルからXMLドキュメント・リソースが作成されます。ファイル間の依存関係は、Service Busによって維持されます。インポートの詳細は、「リソースおよび構成のインポートとエクスポート」を参照してください。

JCAリソースをインポートすると、「JCAバインド・リソースからのプロキシ・サービスの生成方法」および「JCAバインド・リソースからのビジネス・サービスの生成方法」の説明に従って、JCAリソースからプロキシ・サービスまたはビジネス・サービスを生成できます。

25.3.3 Oracle Service BusコンソールでのJCAバインド・リソースの作成方法

JCAリソースをOracle Service Busコンソールに一括インポートしない場合は、手動でJCAバインド・リソースを作成し、JCAファイルをコンソールにアップロードできます。Oracle Service BusコンソールでJCAプロキシ・サービスまたはビジネス・サービスを作成するには、JCAファイルとWSDLファイルが必要となります。この項では、JCAバインド・リソースを作成するプロセスについて説明します。WSDLリソースの作成方法の詳細は、「コンソールでのWSDLリソースの作成方法」を参照してください。

コンソールでJCAバインド・リソースを作成するには:

1. Oracle JDeveloperで、JCAアダプタを作成および構成します。これはService Bus概要エディタを使用して、Service Busプロジェクト内で直接実行できます。

詳細は、「Service Busコンポーネントの追加」を参照してください。

2. Oracle Service Busコンソールで、WSDLリソースやXMLリソースなど、Oracle JDeveloperで作成したJCAアダプタのJCA依存関係をアップロードします。

3. プロジェクト・ナビゲータでは、プロジェクトまたはフォルダを右クリックしてJCAバインド・リソースを含め、「作成」をポイントし、「リソース」を選択します。「インタフェース」、「JCAバインド」をクリックし、次に「OK」をクリックします。

4. 次のいずれかを行います。

- リソースの作成時にJCAファイルをアップロードするには、「ファイルのアップロード」フィールドの横にある「参照」をクリックし、使用するJCAファイルに移動して選択します。
「リソース名」フィールドに、ファイル拡張子なしのファイル名が自動的に移入されます。この名前は変更可能であり、必要に応じて説明を入力できます。JCAバインド名は一意である必要があります。

- JCAバインド・リソースを作成し、後からJCAファイルをアップロードするには、リソースの名前とオプションの説明を入力します。

5. 「作成」をクリックします。

JCAバインド定義エディタが表示されます。

6. JCAバインド定義エディタのツールバーで、「保存」をクリックします。

7. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

JCAバインド・リソースとそれらの依存関係を追加したら、JCAバインドからプロキシ・サービスとビジネス・サービスを生成できます。詳細は、「JCAバインド・リソースからのプロキシ・サービスの生成方法」および「JCAバインド・リソースからのビジネス・サービスの生成方法」を参照してください。

25.3.4 コンソールでのJCAバインド・リソースの編集方法

Oracle Service Busコンソールを使用している場合は、次の手順を使用してJCAバインドを編集します。

JDeveloperでJCAアダプタを変更する場合の詳細は、Service Bus概要エディタからのコンポーネントの編集方法を参照してください。

コンソールでJCAバインドを編集するには:

1. プロジェクト・ナビゲータで、編集するJCAバインドを含むプロジェクトおよびフォルダを開きます。

2. JCAバインド名を右クリックし、「開く」を選択します。

3. 参照する新しいWSDLファイルを検索して選択するには、「WSDLの依存関係」セクションで「WSDLの選択」アイコンをクリックします。

4. JCAファイルの内容を変更したり、新しいJCAファイルをアップロードするには、次の手順を実行します。

a. ツールバーの「ソースの編集」をクリックします。
「ソースの編集」ダイアログが表示されます。

b. アップロードする新しいJCAファイルを参照して選択するには、「参照」をクリックします。

c. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

d. 「保存」をクリックします。

5. JCAバインド定義エディタのツールバーで、「保存」をクリックします。

6. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

25.3.5 JCAバインド・リソースの削除方法

JCAバインド・リソースに基づくビジネス・サービスまたはプロキシ・サービスがある場合、JCAバインド・リソース自体を削除する前に、ビジネス・サービスまたはプロキシ・サービスからJCAバインド・リソースを削除します。Oracle Service BusコンソールのJCAバインド定義エディタでJCAバインドを開き、右上にある「ツール」アイコンをクリックし、「参照」を選択して参照が含まれているかどうかを確認します。JDeveloperでは、JCAファイルを右クリックして、「依存性の参照」を選択します。

JCAバインド・リソースを削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するJCAバインドを含むプロジェクトおよびフォルダを開きます。

2. JCAバインドの名前を右クリックして、「削除」を選択します。

JCAバインド・リソースが削除されます。他のリソースがこのリソースを参照している場合、削除の警告アイコンが表示されます。確認のための警告は表示されますが、リソースを削除することはできます。この場合、削除されたリソースへの未解決の参照が原因で、競合が発生する可能性があります。

3. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

25.3.6 カスタムJCAアダプタの使用

Service Busプロジェクトでは、カスタムJCAアダプタを作成して使用できます。カスタム・アダプタはJDeveloperでのみ作成できます。「Oracle Service BusコンソールでのJCAバインド・リソースの作成方法」の説明に従い、アダプタが作成されると、JDeveloperで使用することもでき、またアダプタの関連ファイルをOracle Service Bus Consoleにインポートすることもできます。その後、他のJCAアダプタと同様に、アダプタをJCAトランスポートと組み合せて使用できます。

注意:

TopLink XMLマッピング・ファイルやXSLTファイルなどの依存関係リソースを含むサポート対象の一部のOracle SOA Suiteアダプタとは異なり、Service Busでは、カスタム・アダプタでの依存関係リソースの使用がサポートされません。

25.3.6.1 カスタム・アダプタの登録ファイルについて

カスタム・アダプタはすべて、Service Busホーム・ディレクトリ(OSB_ORACLE_HOME/config/adapter)にあるOSBSupportedAdapters.xmlファイルに登録する必要があります。このファイルには、Service BusのすべてのカスタムJCAアダプタの名前のみがリストされます。以前にカスタムJCAアダプタを登録していないと、登録ファイルを作成する必要がある場合があります。独自の登録ファイルの作成に使用できる単純なファイルを次に示します。

<jca:osb-supported-adapters
xmlns:jca="http://www.bea.com/wli/sb/transports/jca">
<jca:adapter-type>CUSTOM_ADAPTER</jca:adapter-type>
<jca:adapter-type>SAMPLE_ADAPTER</jca:adapter-type>
<jca:adapter-type>MY_ADAPTER</jca:adapter-type>
</jca:osb-supported-adapters>

adapter-type要素の値は、アダプタJCAファイルから取得されます。それは、adapter-config要素のadapter属性の値に次の変更を加えた値になります。

- すべての文字が大文字に変換されます。

- 1つの空白が1つのアンダースコアに変換されます(たとえば、My AdapterはMY_ADAPTERに変換されます)。

- 連続する空白が1つのアンダースコアに変換されます(たとえば、My AdapterもMY_ADAPTERに変換されます)。

たとえば、アダプタのJCAファイルが次のようであるとします。

<adapter-config name="custom-adapter-endpoint" adapter="My Adapter"
wsdlLocation="custom-adapter-endpoint.wsdl"
xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
. . .
</adapter-config>

OSBSupportedAdapters.xmlのエントリは次のようになります。

<jca:adapter-type>MY_ADAPTER</jca:adapter-type>

25.3.6.2 Service BusでのカスタムJCAアダプタの登録および使用

Service BusでカスタムJCAアダプタを登録および使用するには:

1. JDeveloperで、カスタムJCAアダプタを作成します。

これは、「Service Busコンポーネントの追加」の説明に従い、Service Bus概要エディタを使用して行うことができます。カスタム・アダプタの構成方法の詳細は、テクノロジ・アダプタの理解のカスタム・アダプタの作成に関する項を参照してください。

2. 「カスタム・アダプタ登録ファイルについて」の登録ファイル例をベースとして使用して、次のいずれかを実行します。

- カスタム・アダプタ登録ファイルOSB_ORACLE_HOME/config/adapter/OSBSupportedAdapters.xmlがすでに存在する場合は、サポートされるアダプタ・タイプのリストにカスタム・アダプタを追加します。

- カスタム・アダプタ登録ファイルが存在しない場合は、そのファイルを作成します。サンプルのアダプタ・タイプの名前を、独自のアダプタJCAファイルの実際の名前に置き換えます。

3. 開発にOracle Service Busコンソールを使用している場合は、新しいカスタム・アダプタのJCAリソースをコンソールにインポートします。情報と手順については、「JCAバインド・リソースの操作」を参照してください。

4. ビジネスまたはプロキシ・サービスのJCAトランスポート構成ページで、エンドポイント・プロパティ、動的なエンドポイント・プロパティ、およびアクティブ化指定/相互指定プロパティを構成します。各アダプタで使用可能なプロパティについては、テクノロジ・アダプタの理解のOracle JCAアダプタ・プロパティに関する項を参照してください。

注意:

- JCAファイルを使用してプロキシまたはビジネス・サービスを生成することも、カスタム・アダプタを使用するようにJCAのプロキシまたはビジネス・サービスを構成することもできます。JCAファイルからのサービスの生成については、「ビジネス・サービスの作成と構成」または「プロキシ・サービスの作成と構成」を参照してください。

- JCAトランスポートでは、カスタム・アダプタの正規化メッセージ・プロパティがサポートされます(「JCAトランスポート・ヘッダーおよび正規化メッセージ・プロパティ」を参照してください)。

25.4 JavaScriptリソースの操作

JCA Adapter for Socketsは、XSLTおよびカスタムJavaコードに加え、カスタムJavaScriptを使用してハンドシェイクの処理をサポートします。JavaScriptは、HTMLページにインタラクティブ機能を追加するための軽量なスクリプト言語です。

25.4.1 JavaScriptリソースの作成方法

JDeveloperで作業する場合は、JDeveloperの標準機能を使用してJavaScriptをプロジェクトに追加できます。詳細は、『Oracle JDeveloperによるアプリケーションの開発』のスクリプト言語を使用したアプリケーションの開発に関する項を参照してください。

Oracle Service Busコンソールで、JavaScriptリソースを作成して、既存のJavaScriptファイルをそのリソースにアップロードします。

Oracle Service BusコンソールでJavaScriptリソースを作成するには:

1. Oracle JDeveloperまたは他のエディタで、JavaScriptファイルを作成して定義します。

2. Oracle Service Busコンソールのプロジェクト・ナビゲータで、新しいJavaScriptリソースを含めるプロジェクトまたはフォルダを右クリックし、「作成」をポイントして「リソース」を選択します。「その他」、「JavaScript」とクリックし、次に「OK」をクリックします。

3. 次のいずれかを行います。

- リソースの作成時にJavaScriptファイルをアップロードするには、「ファイルのアップロード」フィールドの横にある「参照」をクリックし、使用するファイルに移動して、それを選択します。
「リソース名」フィールドに、ファイル拡張子なしのファイル名が自動的に移入されます。この名前は変更可能であり、必要に応じて説明を入力できます。JavaScriptリソース名は一意である必要があります。

- JavaScriptリソースを作成し、後から実際のファイルをアップロードするには、リソースの名前とオプションの説明を入力します。

4. 「作成」をクリックします。

JavaScript定義エディタが表示されます。

5. JavaScript定義エディタのツールバーで、「保存」をクリックします。

6. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

25.4.2 JavaScriptリソースの編集方法

JDeveloperを使用している場合は、IDEの標準エディタを使用してJavaScriptファイルを編集できます。Oracle Service Busコンソールを使用している場合は、次の手順を使用してJavaScriptリソースを編集します。

Oracle Service BusコンソールでJavaScriptリソースを編集するには:

1. プロジェクト・ナビゲータで、編集するJavaScriptリソースが含まれているプロジェクトおよびフォルダを開きます。

2. JavaScriptリソース名を右クリックして、「開く」を選択します。

3. JavaScriptリソースの内容を変更したり、新しいJavaScriptリソースをアップロードするには、次の手順を実行します。

a. ツールバーの「ソースの編集」をクリックします。
「ソースの編集」ダイアログが表示されます。

b. アップロードする新しいJCAファイルを参照して選択するには、「参照」をクリックします。

c. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

d. 「保存」をクリックします。

4. JavaScript定義エディタのツールバーで、「保存」をクリックします。

5. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

25.4.3 JavaScriptリソースの削除方法

JavaScriptリソースがJCAアダプタに関連付けられている場合は、JavaScriptリソース自体を削除する前にアダプタからリソースを削除します。Oracle Service BusコンソールのJavaScript定義エディタでJavaScriptリソースを開き、右上の「ツール」アイコンをクリックし、「参照」を選択してそこに参照があるかどうかを確認します。JDeveloperでは、JavaScriptファイルを右クリックして、「依存性の参照」を選択します。

javaScriptリソースを削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するJavaScriptリソースを含むプロジェクトとフォルダを開きます。

2. 削除するリソースの名前を右クリックし、「削除」を選択します。

javaScriptリソースが削除されます。他のリソースがこのリソースを参照している場合、削除の警告アイコンが表示されます。確認のための警告は表示されますが、リソースを削除することはできます。この場合、削除されたリソースへの未解決の参照が原因で、競合が発生する可能性があります。

3. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

25.5 JCAトランスポート構成のリファレンス

この項では、JCAトランスポート固有の構成オプションについて説明します。

- JCAトランスポートのエンドポイントURI

- JCAトランスポート・ヘッダーおよび正規化メッセージ・プロパティ

- JCAトランスポートのエンドポイント・プロパティ

- JCAトランスポートの環境変数

- JCAトランスポートを使用するプロキシおよびビジネス・サービスの構成

- プロキシ・サービス操作の構成

注意:

JCAアダプタ・ファイルに定義されている実行時プロパティとバインド・プロパティは、プロキシまたはビジネス・サービス構成には伝播されない点に注意してください。それらのプロパティは、次の各項で説明するエンドポイント、仕様および接続プロパティを変更して、手動で構成する必要があります。

一般的なビジネスおよびプロキシ・サービスの構成の説明については、次の項を参照してください。

- プロキシ・サービスの作成と構成

- ビジネス・サービスの作成と構成

25.5.1 JCAトランスポートのエンドポイントURI

JCAサービスの次のエンドポイントURIフォーマットを使用してください。

jca://resource_adapter_jndi

ここで、resource_adapter_jndiは、JCAファイルに含まれるconnection-factory要素のlocation属性の値です。この値は、アダプタの接続ファクトリJNDIと一致します。

25.5.1.1 エンドポイント再デプロイメント

JCAサービス・エンドポイントは、WSDLファイル、XMLスキーマ、サービス・アカウント、JCAリソース、XMLスキーマおよびXMLリソース(TopLinkマッピング・ファイル)に依存します。それらのうちいずれかのリソース・タイプが更新され、サービス用に保存されると、JCAサービス・エンドポイントが自動的に削除、再作成および再デプロイされます。JCAプロキシ・サービスでは、新しいアダプタ・リスナーもインバウンド・リクエストをリスニングするために初期化されます。

表25-2で説明されているように、JCAエンドポイント再デプロイメントは、「常にJCAファイルからの構成を使用」オプションをサービスで選択しているかどうかによって、実行時にサービスに潜在的な影響を及ぼします。たとえば、JCAエンドポイントが再デプロイされた後、

- 「常にJCAファイルからの構成を使用」を選択すると、実行時にリソース・アダプタと接続および対話するために、更新されたJCAファイルが使用されます。

- 「常にJCAファイルからの構成を使用」を選択しないと、実行時にリソース・アダプタと対話するために、対応する更新済のJCAファイル・プロパティではなく、既存のサービス構成オーバーライドが使用されます。

25.5.2 JCAトランスポート・ヘッダーおよび正規化メッセージ・プロパティ

Oracle JCAアダプタは、正規化メッセージ・プロパティを介してヘッダー情報を送信します(AQ用Oracle JCAアダプタのペイロード・ヘッダーを除きます)。Service Busでは、JCAアダプタの正規化メッセージ・プロパティがサポートされます。Oracle JCAアダプタからのインバウンド・メッセージについては、Service Bus JCAトランスポートによって、正規化メッセージ・プロパティがキー値のペアとしてトランスポート・ヘッダーに自動的にマップされます。JCAアダプタへのアウトバウンド・メッセージについては、JCAトランスポートによって、トランスポート・ヘッダーが正規化メッセージ・プロパティに自動的に変換されます。

XQuery式の作成時は、オプション・リストから正規化された各メッセージ・プロパティを選択できます。

注意:

Service Busで正規化メッセージ・プロパティをSOAPメッセージ・ヘッダーにマップすることはできません。

次に、正規化メッセージ・プロパティをサポートする、Service Busでの事前定義済のトランスポート・ヘッダーのリストを示します。Service Busでは、この他のすべての標準化メッセージ・プロパティはユーザー定義のトランスポート・ヘッダーにマップされます。

Service Busトランスポート・ヘッダーは、$inboundおよび$outboundリクエスト変数で事前定義されています。正規化メッセージ・プロパティのリストと説明は、テクノロジ・アダプタの理解の次のトピックを参照してください。

- Oracle AQアダプタのJCAプロパティ: 正規化プロパティ

- Coherenceアダプタの正規化プロパティ

- Oracle DatabaseアダプタのJCAプロパティ: 正規化プロパティ

- Oracleファイル・アダプタのJCAプロパティ: 正規化プロパティ

- Oracle FTPアダプタのJCAプロパティ: 正規化プロパティ

- Oracle JMSアダプタのJCAプロパティ: 正規化プロパティ

- Oracle MQアダプタのJCAプロパティ: 正規化プロパティおよびRFHバージョン2 (RFH2)ヘッダー

- MSMQアダプタの正規化プロパティ

- UMSアダプタのメッセージ・ヘッダー

25.5.3 JCAトランスポートのエンドポイント・プロパティ

JCAトランスポートでは、JCAプロキシまたはビジネス・サービスの構成で「JCAトランスポートを使用するプロキシおよびビジネス・サービスの構成」の説明に従って設定できる、様々なサービス・エンドポイント・プロパティがサポートされます。エンドポイント・プロパティの詳細は、テクノロジ・アダプタの理解のOracle JCAアダプタのプロパティに関する項を参照してください。

警告:

これらのプロパティは、JCAアダプタ・ファイルに定義されている場合でも、ビジネスまたはプロキシ・サービスに定義する必要があります。

25.5.3.1 標準のエンドポイント・プロパティ

エンドポイント・プロパティの標準セットは、ほとんどのJCAアダプタに適用されます。JCAベースのプロキシ・サービスまたはビジネス・サービスを構成する場合、これらのプロパティをオプション・リストから選択し、それらの値を構成できます。表25-1に、JCAトランスポート用に選択できるエンドポイント・プロパティのリストと説明を示します。

表25-1 JCAトランスポートのエンドポイント・プロパティ

プロパティ名

説明

jca.retry.count

拒否するまでの最大再試行回数を示します。

jca.retry.interval

再試行の間隔を示します(秒単位)。

jca.retry.backoff

再試行間隔の増加係数(正の整数)を示します。

jca.retry.maxInterval

再試行間隔の最大値を示します。つまり、backoffが1より大きい場合は上限です。

jca.retry.maxPeriod

アウトバウンドJCAアダプタの最大総再試行期間を示します。期間がこのプロパティに指定された値を超えると、再試行は行われません。

activationInstances

インバウンドJCAリソース・アダプタのポーリング(ワーカー)スレッド数を増やします。つまり、ネイティブでマルチスレッドをサポートしていないアダプタの同時実行性の強化にのみ役立ちます。Oracle Fusion Middlewareに含まれるほとんどのアダプタはネイティブでマルチスレッドをサポートしているため、この設定は、通常、ネイティブでマルチスレッドをサポートしていないサード・パーティ(カスタム)のJCAアダプタで役立ちます。特定のJCAアダプタで、このプロパティに必要なスレッド数を設定します。

payloadSizeThreshold

アダプタ・レイヤーでのペイロード・サイズのしきい値を指定します。サイズが構成されたしきい値の制限を超えるメッセージは拒否されます。このプロパティが構成されていない場合、メッセージ・サイズに対する制限はありません。

rejectUncorrelatedMessages

関連付けできないメッセージを拒否するかどうかを指定します。インバウンド非同期メッセージと前のアウトバウンド・メッセージの関連付けにネイティブ相関が使用されている場合、通常、JCAフレームワークは、インバウンド・メッセージを関連付けできるかどうかに関係なく、メッセージをサービスにポストしようとします。このプロパティをtrueに設定すると、JCAフレームワークは関連付けできないメッセージを拒否します(ネイティブ相関がアクティブな場合)。

UseWorkManager

デフォルトの標準ワーク・マネージャではなく、ポーリング(ワーカー)スレッドの起動に使用するカスタム・ワーク・マネージャを指定します。このプロパティを使用して、特定のWebLogicワーク・マネージャを使用するようにインバウンドJCAエンドポイントを構成できます。ワーク・マネージャは、このプロパティが定義されているJCAサービスを開始するためにのみ使用されます。このプロパティの値は、ワーク・マネージャの名前です。JNDIルックアップに失敗した場合は、デフォルトのService Busワーク・マネージャが使用されます。

25.5.3.2 動的エンドポイント・プロパティ

ほとんどのJCAアダプタは、統合するシステム・タイプに一意の膨大なエンドポイント・プロパティ・セットをサポートしています。JCAベースのプロキシ・サービスまたはビジネス・サービスを構成する場合、これらのプロパティをオプション・リストから選択し、それらの値を構成できます。正規化メッセージ・プロパティのリストと説明は、テクノロジ・アダプタの理解の次のトピックを参照してください。

- すべてのOracle JCAアダプタのバインド・プロパティ

- Oracle AQアダプタのバインド・プロパティ

- データベース用のOracle JCAアダプタ

- OracleファイルおよびFTPアダプタのバインド・プロパティ

- Oracle FTPアダプタ固有のバインド・プロパティ

- Oracle JMSアダプタのバインド・プロパティ

- Oracle MQ Seriesアダプタのバインド・プロパティ

- MSMQアダプタのバインド・プロパティ

- UMSアダプタのメッセージ・ヘッダー

25.5.3.3 アクティブ化指定プロパティおよび相互指定プロパティ

Service Busでは、アクティブ化指定プロパティはプロキシ・サービス固有で、相互指定プロパティはのビジネス・サービス固有です。これらのプロパティは追加または削除できません。値の変更のみ実行できます。「トランスポート構成」ページに表示されるプロパティは、アダプタ構成ウィザードでアダプタを作成した際のアダプタ・プロパティの定義方法によって異なります。

これらのプロパティを更新するには、アダプタ・エンドポイントを再利用する必要があります。これらのタイプのプロパティは、相互に様々な依存関係を持っています。アクティブ化指定プロパティおよび相互指定プロパティのリストと説明は、テクノロジ・アダプタの理解の次のトピックを参照してください。

- すべてのOracle JCAアダプタのプロパティ

- Oracle AQアダプタのJCAプロパティ

- CoherenceアダプタのJCAプロパティ

- データベース用のOracle JCAアダプタ

- OracleファイルおよびFTPアダプタのJCAプロパティ

- Oracle FTPアダプタ固有のJCAプロパティ

- Oracle JMSアダプタのJCAプロパティ

- LDAPアダプタの接続プロパティ

- Oracle MQ SeriesアダプタのJCAプロパティ

- MSMQアダプタのJCAプロパティ

- Oracleソケット・アダプタのJCAプロパティ

- UMSアダプタのアクティブ化指定プロパティ

- UMSアダプタの相互指定プロパティ

25.5.4 JCAトランスポートの環境変数

JCAトランスポートでは次の環境変数値を宣言し、これらは、異なるデプロイメント環境間でService Bus構成を移動する場合も保持できます。

これらの値の説明は、「JCAトランスポートを使用するプロキシおよびビジネス・サービスの構成」を参照してください。環境変数の詳細は、『Oracle Service Busの管理』のOracle Service Bus環境のカスタマイズに関する項を参照してください。

- ワーク・マネージャ

- JCAは常にJCAファイルのフラグを使用

- JCA接続モード

- JCA上書き接続認証フラグ

25.5.5 JCAトランスポートを使用するプロキシおよびビジネス・サービスの構成

表25-2に、JDeveloperまたはOracle Service BusコンソールにおいてJCAトランスポート構成ページで使用可能なオプションを示します。

表25-2 JCAトランスポート・プロパティ

オプション

説明

JCAファイル

「参照」をクリックしてJCAリソースを選択します。JCAリソースによって、使用されるアダプタの詳細、WSDLへのバインド、TopLinkマッピング・ファイル、サービスで必要なアクティブ化指定/相互指定プロパティなど、サービスの様々な面が定義されます。

有効なJCAリソースを選択したら、その他のトランスポート構成フィールドが使用可能になります。

アダプタ名

JCAサービスが使用するアダプタの名前が表示されます。

アダプタ・タイプ

アダプタ・タイプが表示されます。

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャについては、次のトピックを参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュール済作業の最適化に関する項

JNDIサービス・アカウント

「参照」をクリックし、EISアダプタ管理対象の接続ファクトリにアクセスするためJNDIコンテキスト・セキュリティで使用されるJNDIサービス・アカウントを選択します。サービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。

JCAビジネス・サービスでは、静的またはパススルーなど、構成できるJNDIサービス・アカウントのタイプに制限はありませんが、ランタイムはユーザー名とパスワードにアクセスできる必要があります。JCAプロキシ・サービスは静的JNDIサービス・アカウントのみを使用できます。

JNDIサービス・アカウントの詳細は、「JCAトランスポートのセキュリティ」を参照してください。

エンドポイント・プロパティ

「追加」アイコンをクリックし、使用可能リストからエンドポイント・プロパティを選択して、各プロパティに値を割り当てます。このフィールドでは、サービスが使用するアダプタ・タイプの再試行回数など、エンドポイント・プロパティに値を割り当てることができます。

サポートされるエンドポイント・プロパティの情報へのリンクについては、「JCAトランスポート・エンドポイント・プロパティ」を参照してください。

動的エンドポイント・プロパティ

「追加」アイコンをクリックし、エンドポイントの動的なプロパティを定義して、各プロパティに値を割り当てます。指定する動的エンドポイント・プロパティごとに名前と値のペアを入力します。エンドポイント・プロパティ・キーが問合せパラメータ名と一致します。

このオプションを使用すると、リクエスト・パラメータをJCA準拠サービスに渡すことができます。たとえば、動的エンドポイント・プロパティを使用して、データベース問合せパラメータをデータベース用のOracle JCAアダプタに渡すことができます。

パラメータによる問合せの詳細は、テクノロジ・アダプタの理解のOracle JCA Adapter for Databaseに関する項を参照してください。サポートされるエンドポイント・プロパティの情報へのリンクについては、「JCAトランスポート・エンドポイント・プロパティ」を参照してください。

常にJCAファイルからの構成を使用

このオプションを選択して、「アクティブ化指定プロパティ」(プロキシ・サービス)および「相互指定プロパティ」(ビジネス・サービス)を常にJCAファイルから使用するかどうかを指定します。

このオプションが選択されている場合(デフォルト)、JCAトランスポートはJCAファイルのアクティブ化指定プロパティまたは相互指定プロパティを使用してJCAフレームワークとやり取りします。このオプションが選択されていない場合は、アクティブ化指定および相互指定プロパティをオーバーライドできます。

このオプションを使用する場合の再デプロイメントの影響については、「エンドポイント再デプロイメント」を参照してください。

操作名

選択したWSDL操作の読取り専用の名前を表示します。操作ごとに専用のアクティブ化指定プロパティまたは相互指定プロパティを指定できます。

アクティブ化指定プロパティ/相互指定プロパティ

ビジネス・サービスの場合、このフィールドには、「操作名」フィールドに表示されているJCAインバウンド操作のアウトバウンド相互指定プロパティが表示されます。プロキシ・サービスの場合、このフィールドには、「操作名」フィールドに表示されているJCAインバウンド操作のアクティブ化指定プロパティが表示されます。「常にJCAファイルからの構成を使用」を選択解除すると、アクティブ化または相互指定プロパティをオーバーライドできます。

注意: Oracle Adapter Suiteアダプタの場合、アクティブ化/相互指定プロパティは読取り専用になります。Oracle Adapter Suiteアダプタには独自の構成が保存されています。これは、Oracle Adapter Suite管理ツールで変更する必要があります。

接続モード

関連付けられたJCAアダプタにサービスを接続する方法を指定するには、次のオプションのいずれかを選択します。

管理対象: プロダクション環境に推奨されます。JCA転送はWebLogic Serverで構成したJCAアダプタ管理対象の接続ファクトリを介してJCAアダプタに接続します。認証のためにJNDIサービス・アカウントを指定します。JNDIサービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。

非管理対象: JCA転送は、JCAアダプタのコンテナとして機能するJCAアダプタ・フレームワークからJCAアダプタに接続します。認証のためにJNDIサービス・アカウントを指定します。JNDIサービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。接続ファクトリ・プロパティを編集してオーバーライドできます。

注意: これらのオプションは、レガシー・アダプタやクラウド・アダプタなどの特定のアダプタでのみ使用可能です。非管理対象モードから管理対象モードに変更する場合、モードを変更する前に、「接続認証プロパティの上書き」オプションを必ず選択解除してください。

上書き接続認証のプロパティ

アダプタ接続ファクトリのユーザー名とパスワードが、「接続認証サービス・アカウント」の資格証明によって上書きされるように指定するには、このオプションを選択します。サービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。

このオプションは、接続ファクトリ・プロパティにユーザー名およびパスワード・プロパティが含まれ、接続モードが「管理対象外」で、「常にJCAファイルからの構成を使用」が選択されていない場合のみ使用可能です。

接続認証サービスのアカウント

前述の「接続認証プロパティの上書き」が選択されている場合は、認証に使用するサービス・アカウントを参照して選択します(「接続認証プロパティの上書き」を選択した場合は、サービス・アカウントを指定する必要があります)。プロキシ・サービスでは、静的サービス・アカウントのみ使用できます。

接続ファクトリ・プロパティ

接続ファクトリ・オーバーライド値を入力します。

注意: 「常にJCAファイルからの構成を使用」が選択解除され、接続モードが非管理対象の場合に、プロパティ値をオーバーライドできます。プロダクション環境では管理対象のモードを使用して、JCAトランスポートがWebLogic Serverで構成したアダプタ接続ファクトリに接続するようにします。

エンドポイントおよびアクティブ化指定/相互指定プロパティの詳細は、テクノロジ・アダプタの理解のアダプタ・フレームワークに関する項を参照してください。

25.5.6 プロキシ・サービス操作の構成

JCA WSDLファイルはドキュメントliteralバインドのみサポートします。JCAプロキシ・サービスの操作構成用のアルゴリズムは、SOAPActionヘッダーのみです。Service Busの有効なWSDLファイルは常にSOAPActionを含みます。SOAPActionフィールドの値は操作名です。

26 Oracle Service BusでのRESTサービスの作成

この章では、Service Busプロジェクト内でバインド・コンポーネントとしてRepresentational State Transfer (REST)操作を統合する方法について説明します。また、RESTfulサービスでWSDLに相当するWeb Application Definition Language (WADL)ドキュメントについても説明します。

RESTプロキシおよびビジネス・サービスを作成できるのは、JDeveloperおよびService Busコンソールからのみです。

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

- Oracle Service BusおよびREST

- Service BusでのRESTサービスに関するWADLドキュメント

- WADLドキュメントの作成

- WADLドキュメントの変更

- RESTサービスの作成

- WebブラウザでのWADLドキュメントへのアクセス

26.1 Oracle Service BusおよびREST

RESTは、ネットワーク・アプリケーションの設計用のアーキテクチャです。RESTfulアプリケーションでは、HTTPリクエストを使用してデータのポスト(作成および更新)、データの取得(問合せの作成など)およびデータの削除を行います。RESTは、従来のWSDLベースのWebサービスの軽量な代替機能を提供します。

26.1.1 Service BusにおけるREST機能

Service Busでは、次のRESTサポートを提供します。

- プロキシ・サービスとビジネス・サービス、およびパイプラインでのRESTサポート

- 外部REST APIとの統合

- XML、JavaScript Object Notation (JSON), (XMLとの間の変換を含む)およびURLエンコード・データ

- JDeveloperのRESTインタフェースとWSDLマッピングをモデル化するためのウィザード

- ベースとなるWSDL (SOAPからREST)に基づく、または「RESTバインディング」ウィザードでのAPI指定によるWADLファイルの自動作成。

- JDeveloper内からOracle RESTエンドポイントを参照および使用する機能

- RESTセキュリティのためのOracle Web Service Manager (OWSM)ポリシーおよびOAuth 2ポリシーのサポート

Service Busは、Hypermedia as the Engine of Application State (HATEOAS)アプローチに従ってはいませんが、パイプラインでアクションを定義することによって、特定のHATEOAS機能をサポートします。これには次の機能が含まれます。

- RESTプロキシ・サービス・レスポンスでのHTTPリンク・ヘッダーの設定

- RESTビジネス・サービス・レスポンス内のHTTPリンク・ヘッダーの値の読取り

- RESTビジネス・サービス・リクエストのエンドポイントURIのオーバーライド

RESTプロキシ・サービスを作成すると、これをスタンドアロンのRESTクライアントから呼び出すことができます。作成したRESTビジネス・サービスは、WSDLベースのサービスとして呼び出すことができます。

注意:

添付ファイル・コンテンツへのリンクを含むペイロードを返すことはできますが、Service Busでは、RESTでMIME添付ファイルをサポートしていません。

26.1.2 Service BusにおけるRESTの実装

Service Busは、このリリースでRESTをネイティブにサポートするよう拡張されました。以前のService Busリリースでは、RESTをサポートするための仮想レイヤーを提供していました。つまり、プロキシおよびビジネス・サービスのみがRESTベースになっていました。これらのRESTサービスは、WSDLベースのパイプラインまたは分割-結合を呼び出すこともあれば、それらに呼び出されることもありました。RESTプロキシ・サービスは、パイプラインまたは分割-結合を呼び出す前にRESTネイティブ・ペイロードをSOAPに変換する一方、パイプラインまたは分割-結合によって呼び出されるRESTビジネス・サービスは、SOAPのペイロードをRESTに変換していました。内部インタフェースはWSDLベースですが、外部ビジネスおよびプロキシ・サービスはRESTエンドポイントを公開していました。このリリースでは、RESTプロキシ・サービスはRESTネイティブ・ペイロードをSOAPに変換する必要はありません。これらのペイロードはRESTベースのパイプラインで、XMLに変換、またはXMLから変換せずにネイティブに処理できます。

注意:

ネイティブRESTサービスについては、Service BusがクライアントのHTTP Acceptヘッダーに基づいて、インバウンド・レスポンスを自動的に変換することはありません。RESTバインディングを使用するとき、RESTバインディングで選択されているペイロードのタイプが1つのみでなければ、戻りペイロードはユーザーのAcceptヘッダーに基づいています。たとえば、$bodyのJSONペイロードは、インバウンド・リクエストのAccept Valueヘッダーの値に関係なく、そのまま(JSON)送信されます。パイプラインでは、nXSD変換アクションを使用して、必要に応じて手動で変換します。

このリリースのService Busでは、次の新しいネイティブRESTサービス・タイプが使用可能です。

- 未入力のRESTプロキシ・サービスおよびビジネス・サービス: デザイン・タイムでメソッド(操作)情報が通知されない可能性のあるサービス。

- 入力済RESTプロキシ・サービスおよびビジネス・サービス: デザイン・タイムでメソッド(操作)情報が通知されるサービス。これらのサービスのメソッド情報は、WADLファイルに定義されます。サービスを作成する場合、WADLファイルを指定するか、ウィザードを使用してサービスのメソッドを定義し、WADLファイルを作成できます。12.1.3 REST WADLファイルがサポートされています。REST操作をWSDLにマッピングするために定義されたSOA拡張は無視されます。ただし、Service Busでは、RESTサービスで使用されるWADLを構文的にも意味的にもチェックし、確実にルールに従うようにしています。

- RESTベースのパイプライン: ネイティブRESTプロキシ・サービスによって呼び出されるパイプライン。ネイティブRESTプロキシおよびビジネス・サービスによって、RESTベースのパイプラインは入力済または未入力のいずれかにできます。新しいRESTブランチ・ノードは、未入力のRESTベース・パイプラインまたはパイプライン・テンプレートで使用できます。詳細は、「RESTブランチ」を参照してください。

注意:

12.1.3スタイルのWADLを参照するネイティブRESTパイプラインは作成できません。WADL参照はネイティブREST WADLである必要があります。

Service Busでは、12c 12.1.3リリースからのRESTサービスの実装もサポートしています。これらのサービスは、WSDLベースの内部インタフェースによって、引き続きJDeveloperを使用して作成できます。詳細は、「JDeveloperを使用したService Bus用のWSDLベースRESTサービスの作成方法」を参照してください。また、Service Busコンソールを使用して、SOAP XMLスキーマからの要素に基づく入力済RESTビジネス・サービスを作成することもできます。

26.1.3 ネイティブRESTサービスのサービス・タイプ互換性

ネイティブRESTサービスを呼び出す、またはこのサービスによって呼び出されるサービス・タイプは次のとおりです。

- 未入力のRESTプロキシ・サービスは別のネイティブRESTサービス(パイプラインまたはビジネス・サービス)のみを呼び出します。

- 入力済ネイティブRESTプロキシ・サービスは、同じWADLを参照して未入力のネイティブRESTサービス、または入力済RESTサービス(パイプラインまたはビジネス・サービス)を呼び出すことができます。

注意:

ローカル・トランスポート・プロキシ・サービスを除き、ネイティブRESTプロキシ・サービスを呼び出せるコンポーネント(プロキシ、パイプラインまたは分割-結合)はありません。

- ネイティブRESTビジネス・サービスはどのパイプラインからでも呼び出せます。

26.1.4 ネイティブRESTサービスによってサポートされているペイロード

ネイティブRESTサービスは、JSON、XML、フォームURLエンコード、テキスト、および不透明のタイプのペイロードを送受信できます。

JSON

注意:

SOAPからRESTの場合は、ネイティブRESTとはみなされません。このタイプのサービスでは、application/xmlまたはapplication/jsonタイプのペイロードのみをサポートします。

コンテンツ・タイプapplication/jsonのペイロードはJSONペイロードとみなされ、それに応じてJSONネイティブ・データ・モデルに解析されます。$bodyをログ記録する場合、次の例に示すように、JSONペイロードの文字データはsoap:Bodyタグでラップされます。

$body = <soap-env:Body><![CDATA[{ “foo1” : “foo2”}]]><soap-env:Body>

JSONペイロードはOSB内部で文字データとしては表現されなくても、ログ記録用には表現されます。これは、メッセージング/テキスト・サービス・タイプのペイロードの表現モデルと類似している部分があります。JSONペイロードをJavaScriptまたはアクションで操作する必要がある場合(次を参照)、JSONネイティブ・オブジェクトは、JavaScriptで必要とされるスクリプト可能なファサードにラップされます。

JSONペイロードは解析され、パイプラインがコンテンツ・ストリーミング用にマークされているかどうかに関係なく、JSONデータ・モデル・オブジェクトに完全にマテリアライズされます。

XML、テキスト、およびフォームURLエンコード

前述の定義済ネイティブRESTサービス・タイプは、コンテンツ・タイプのあるペイロードの送受信に使用できるようになります

- text/xml or application/xml – これはXMLペイロードとみなされます。

- text/plain、application/text、またはx-www-form-urlencoded – テキスト・ペイロードとみなされます。

ネイティブRESTバインディングのXMLペイロードは、任意のXMLまたはメッセージング/XMLコンテンツのモデル化と完全に同じようにモデル化され、$bodyのコンテンツには、インライン・ペイロードXMLが含まれます。

ネイティブRESTバインディングのテキスト・ペイロードは、メッセージング/テキスト・コンテンツのモデル化と完全に同じようにモデル化され、$bodyのコンテンツには、インライン・ペイロード文字データが含まれます。

パイプラインのコンテンツ・ストリーミングが有効な場合、テキストおよびXMLコンテンツは、AnyXMLおよびメッセージング・サービスの処理方法と同じように、完全にマテリアライズされずに処理されます。

不透明(バイナリ)

次に示すもの以外のRESTサービスで受信したコンテンツ・タイプ値は、不透明(またはバイナリ)ペイロードとみなされます。

- application/json

- application/xml

- text/xml

- text/plain

- application/text

- application/x-www-form-urlencoded

不透明なペイロードは、イメージ・ファイルなどのバイナリ・メッセージをRESTプロキシからのレスポンス、またはRESTビジネス・サービスへのリクエストとしてバイナリ・メッセージを送信可能にするか、バイナリ・メッセージをRESTビジネス・サービスへのレスポンス、またはRESTプロキシへのリクエストとして受信可能にすることを目的としています。不透明なペイロード・コンテンツは、バイナリ・リポジトリに格納されます。$bodyには、<ctx:binary-content>要素を使用したこのコンテンツへの参照が含まれています。

example/bookmarks+xmlなどのカスタム・メディア・タイプを使用する場合は、バイナリからテキスト、XML、またはJSONテキストへの変換にカスタムXPath関数またはJavaコールアウト・アクションを使用できます。

パイプラインのコンテンツ・ストリーミングが有効な場合、不透明なぺイロードは、メッセージング/バイナリ・サービス・タイプの場合と同じように、ストリーミング形式で処理されます。

26.1.5 ネイティブRESTサービスのレスポンス・コードおよび失敗コード

正常なレスポンス、および失敗レスポンスには、それぞれ単一のデフォルト値を設定できます。ステータス・コードは、200から300の範囲になる場合は成功とみなされます。

ネイティブRESTプロキシ・サービスのランタイムでは、HTTPステータス・コードがインバウンド・レスポンス・メタデータに設定されていない場合、対応するREST操作のWADLに定義されたデフォルトの成功ステータス・コードが正常なレスポンス・コードとして送信されます。HTTPステータス・コードがインバウンド・レスポンス・メタデータで設定されている場合は、そのステータス・コードが返されます。

同様に、失敗した場合は、HTTPステータス・コードがインバウンド・レスポンス・メタデータに設定されていなければ、対応するREST操作のWADLに定義されたデフォルトの失敗ステータス・コードがクライアントに返されます。

ビジネス・サービスの場合、RESTウィザードで作成されたWADLには、ステータス・コードは定義されていません。既存のWADLにステータス・コードがある場合、ランタイムでは無視されます。このため、レスポンス・コードはビジネス・サービス起動から消費されます。

26.1.6 未処理のエラーおよびネイティブRESTサービス

未処理のエラーが発生した場合、ネイティブRESTサービスによって、Errors.xsdに定義されているスキーマに従ってコール元にペイロードが返されます。

<element name="RestError" type="err:RestErrorType"/>
<complexType name="RestErrorType">
<sequence>
<element name="errorMessage" minOccurs="0" type="string" />
<element name="errorCode" minOccurs="0" type="string" />
</sequence>
</complexType>

受信するHTTP Acceptヘッダーの値がapplication/jsonまたはnullの場合、次の例に示すとおり、前述のペイロードがJSON形式で返されます。

{
"errorMessage" : "XPath can only be executed against XML or MFL content",
"errorCode" : "OSB-395357"
}

HTTP Acceptヘッダーの値がapplication/xmlの場合はXML形式で返されます。HTTP Acceptヘッダーの値がapplication/json、application/xml、またはnull以外の場合、ペイロードは返されません。エラー・レスポンスはHTTPステータス・コード500で返されます。

26.1.7 RESTセキュリティ

Service BusのRESTサービスのセキュリティは、Oracle Web Services Manager (OWSM)ポリシーで保護されます。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のRESTful WebサービスおよびクライアントでサポートされるOWSMポリシーに関する項を参照してください。

RESTエンドポイントによるサービスも、OAuthを使用してセキュリティ保護できます。「OAuthを使用したRESTエンドポイントによるサービスの保護」を参照してください。

ネイティブRESTプロキシ・サービスは、Basic認証やSSLなど、任意のHTTPプロキシ・サービスですでにサポートされているトランスポート・レベルの認証メカニズムをサポートしています。ただし、メッセージ・レベルのセキュリティはサポートされていません。

26.2 Service BusでのRESTサービスに関するWADLドキュメント

RESTバインディングに基づいてプロキシまたはビジネス・サービスを作成する場合、JDeveloperは必要なWADLドキュメントを自動的に生成します。RESTバインディングの作成ウィザードで生成されるWADLファイルは、既存のWSDLファイル、またはRESTバインディング・ウィザードでユーザが作成するWSDLファイルに基づいています。それはサービスの構造を定義します。実行時に、Service BusはWADLドキュメントを使用して、関連するWSDL操作を計算し、メッセージ・ペイロードを変換します。ペイロードは、JSON、XML、URLエンコードなどのRESTメディア・タイプから、パイプラインで期待される形式に変換され、その後サービスで期待されるRESTメディア・タイプに戻されます。単一の部分を単一の要素で定義する操作を含むSOAPドキュメント・スタイルのWSDLファイルのみがRESTサービスでサポートされます。

WADLファイルは、拡張子.wadlでJDeveloperに保存されます。JDeveloperの標準XMLエディタを使用して、RESTバインディング・ウィザードで作成したWADLファイルを編集できます。WADLファイルには、1つ以上のXMLスキーマに対する依存関係を含めることができます。

26.2.1 設計時および実行時のWADLドキュメント

設計時、Service BusではWADLドキュメントを使用して、新しいサービスの構造を定義します。実行時に、Service BusはWADLドキュメントを使用して、関連するWSDL操作を計算し、メッセージ・ペイロードを変換します。ペイロードは、JSON、XML、URLエンコードなどのRESTメディア・タイプから、パイプラインで期待される形式に変換する必要があります。その後、サービスで期待されるRESTメディア・タイプに戻す必要があります。

26.2.2 入力済ネイティブRESTサービスによってサポートされているメディア・タイプ表現

ネイティブRESTサービスに対応するWADLには、どのメディア・タイプについても、関連付けられた型/スキーマ情報(メッセージの形状)がありません。次の個別ケースのリストは、JSON、XML、テキスト、フォームURLエンコード、および不透明(バイナリ)のサービス・タイプ用にWADLでサポートされています。

JSON

JSONベース表現はメディア・タイプapplication/jsonで定義されます。これはWADLに次の表現があります。

<representation mediaType=”application/json”>

ランタイムでは、これは「ネイティブRESTサービスによってサポートされているペイロード」に示すJSONペイロードとして扱われます。

XML

対応するWADL表現要素には、次の形式があります。

<representation mediaType=”application/xml”> or <representation mediaType="text/xml">

要素属性はXML要素をポイントします。XMLスキーマはWADL内の<grammars>の一部です。

ランタイムでは、これは「ネイティブRESTサービスによってサポートされているペイロード」に示すXMLペイロードとして扱われます。

テキスト

テキスト・ベース表現はメディア・タイプapplication/textで定義されます。これには次の表現が含まれます。

<representation mediaType=”application/text”> or <representation mediaType=”text/plain”>

ランタイムでは、これは「ネイティブRESTサービスによってサポートされているペイロード」に示すテキスト・ペイロードとして扱われます。

フォームURLエンコード

URLエンコード表現は、次の表現によって定義されています。

<representation mediaType="application/x-www-form-urlencoded">

ランタイムでは、これは「ネイティブRESTサービスによってサポートされているペイロード」に示すテキスト・ペイロードとして扱われます。

不透明(バイナリ)

バイナリ・ベース表現(つまり、このセクションでリストされているもの以外のすべて)は、メディア・タイプ*/*によって定義されます。これには次の表現が含まれます。

<representation mediaType=”*/*”>
ランタイムでは、これは「ネイティブRESTサービスによってサポートされているペイロード」に示す不透明なペイロードとして扱われます。

26.2.3 WADLによる問合せ操作

注意:

最初の段落にあるテキストは、Service Bus 12.1.3で使用されるものと同様に、WSDLベースRESTサービスで使用されるWADLにのみ適用されます。

問合せスタイルの操作パラメータを構成する場合、ペイロードまたはプロパティのいずれかに基づいて式を構成できます。ペイロードベースの式($msg.parameters/tns:symbolなど)では、対応する抽象リクエスト・メッセージ・パートの要素または属性の値を指定します。プロパティベースの式($property.PropertyNameなど)では、実行時に$inbound変数のリクエスト・メタデータの値を指定します。

プロキシ・サービスまたはインバウンド・リクエストの場合、パイプラインで$inbound変数に問合せを行い、指定のユーザーメタデータ要素の値を取得できます。たとえば、$property.PropertyNameの場合、$inbound/ctx:transport/ctx:request/tp:user-metadata[@name = 'PropertyName']/@valueの値を問い合せることができます。ビジネス・サービスまたはアウトバウンド・リクエストの場合、パイプラインの$outbound変数のパートの値を、対応するリクエスト・パラメータに割り当てることができます。

26.2.4 問合せパラメータおよびテンプレート・パラメータ

問合せパラメータは、$inbound HTTP固有のメタデータで使用できます。

インバウンド・リクエストの場合、テンプレート・パラメータの値はリクエスト・メタデータ内で使用可能になります。次に例を示します。

<param name="param1" style="template" type="xsd:string"/>

ランタイムでは、次の例に示すとおり、param1テンプレート・パラメータの値がリクエスト・メタデータの作成に使用されます。

$inbound =  …
<ctx:transport>
<ctx:request>
<headers …>
<ctx:user-metadata name=”param1” value=”1234” />
</ctx:request>
</ctx:transport>

アウトバウンド・リクエストの場合、ランタイムは$outboundメタデータ内で対応するWADLリソース/メソッドのテンプレート・パラメータ値を検索します。たとえば、WADLリソースが次のように定義される場合:

<resource path="/containers/{container}">
ランタイムでは$outboundにcontainerという名前のユーザー・メタデータ要素が含まれると想定され、その値が使用されます。

追加情報:

- soa:expression WADL属性はService Bus 12.1.3にあったため、WADLファイルのテンプレート・パラメータおよびクエリ・パラメータにはありません。

- テンプレート(パス)・パラメータのランタイム・プロパティ名は単なるパラメータ名です。

26.2.5 リソース・メソッドの識別

リソースとメソッドを識別するため、WADLインタフェースで定義されているすべてのリソースで、メソッド識別子(名前)を付けるようにWADLが拡張されています。

RESTウィザードUIでは、変更可能なデフォルト・メソッド名が生成されます。メソッド名は一意です。カスタム属性soa:nameは、この情報をメソッド要素に格納します。この例は、次のとおりです。

<method name="POST" soa:name="create_order">

create_orderは一意のメソッドIDです。

Service Busランタイムでは、この一意の識別子は$operationシステム変数にマッピングされます。

26.2.6 WSDLベースRESTサービスのWADL制限事項

単一のパートが要素によって定義される操作を含め、SOAPドキュメントスタイルのWSDLドキュメントのみがWSDLベースRESTサービスでサポートされます。SOAP RPCスタイルと汎用XMLスタイルのWSDLドキュメントはサポートされません。これは設計時の検証で実施されます。各操作またはメソッドについては、要素タイプのみが表現に対してサポートされます。スキーマ・タイプは使用されません。

26.2.7 有効なWADLドキュメント

WSDLベースのサービスと同様に、Service Busでは、Service Bus RESTfulサービスの開発時に作成する実際の.wadlファイルのかわりに、有効なWADLドキュメントを実行時に使用します。有効なWADLドキュメントとは、Service Busで構成されたサービスのWADLプロパティを表し、この中には、ソースWADLドキュメントの外部で構成された追加のプロパティも含まれます。有効なWADLドキュメントと設計時のWADLドキュメントでは、次の点が異なります。

- 有効なWADLドキュメントには、サービス・エンドポイントURLを含むベースURI情報があります。

- 有効なWADLドキュメントには、SOA拡張属性は含まれません。

設計時のファイルと有効なファイルとの違いについては、「有効なWSDLドキュメントと生成されたWSDLドキュメントについて」を参照してください。

26.3 WADLドキュメントの作成

JDeveloperでRESTバインディングに基づいてビジネスまたはプロキシ・サービスを作成する場合、RESTバインディングの作成ウィザードはサービスのWADLファイルを自動的に生成します。手順の詳細は、「RESTサービスの作成」を参照してください。

Oracle Service Busコンソールを使用する場合、WADLドキュメントを作成するには、ドキュメントをインポートするか、WADLリソースを作成して既存のWADLファイルを新しいリソースにアップロードします。

26.3.1 Oracle Service BusコンソールでのWADLリソースの作成方法

この項では、既存のWADLファイルを新しいWADLリソースにアップロードする方法を説明します。リソースのインポート方法の詳細は、「リソースおよび構成のインポートとエクスポート」を参照してください。

コンソールでWADLリソースを作成するには:

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. プロジェクト・ナビゲータで、新しいWADLドキュメントを含めるプロジェクトまたはフォルダを右クリックして、「作成」をポイントし、「リソース」を選択します。「インタフェース」をクリックし、「WADL」、「OK」の順にクリックします。
WADLの作成ダイアログが表示されます。

3. 次のいずれかを行います:

- 既存のWADLファイルからリソースを作成するには、「ファイルのアップロード」フィールドの横の「参照」をクリックしてから、使用するWADLファイルに移動してそのファイルを選択します。
「リソース名」フィールドに、ファイル拡張子なしのファイル名が自動的に移入されます。この名前は変更可能です。

- 新しいWADLファイルを作成するか、またはWADLファイルを後でアップロードするには、WADLリソースの一意の名前を入力します。

4. 必要に応じて、リソースの簡単な説明を入力します。

5. 「作成」をクリックします。
WADL要素(定義される場合)がWADL定義エディタに表示されます。

6. WADLファイルのコンテンツを変更するには、次のようにします。

a. ツールバーの「ソースの編集」をクリックします。
「ソースの編集」ダイアログが表示されます。

b. アップロードする新しいWADLファイルを参照して選択するには、「参照」をクリックします。

c. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

d. 「保存」をクリックします。

7. WADL定義エディタのツールバーで、「保存」をクリックします。
新しいWADLドキュメントに未解決の参照がある場合は、エディタのタイトル・バーの横に「競合」アイコンが表示されます。戻る矢印と次に進む矢印ボタンを使用して、エラー全体をスクロールします。

8. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

26.4 WADLドキュメントの変更

Service Busプロジェクト内でWADLドキュメントを作成したら、必要に応じてそのドキュメントを編集または削除できます。

- WADLドキュメントの編集方法

- WADLドキュメントの削除方法

26.4.1 WADLドキュメントの編集方法

WADLドキュメントは、JDeveloperの標準機能です。WADLドキュメントを標準エディタで表示して、ソース・コードを直接変更できます。

Oracle Service Busコンソールを使用している場合は、次の手順でWADLドキュメントを編集します。コードを直接編集するか、更新されたWADLファイルをリソースにアップロードできます。

コンソールでWADLドキュメントを編集するには:

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. プロジェクト・ナビゲータで、編集するWADLリソースをクリックします。

WADL定義エディタが表示されます。

3. ツールバーの「ソースの編集」をクリックします。

「ソースの編集」ダイアログが表示されます。

4. アップロードする新しいWADLファイルを参照して選択するには、「参照」をクリックします。

5. ファイルのコンテンツを変更するには、ダイアログの「コンテンツ」セクションでコードを直接更新します。

6. 「保存」をクリックします。

7. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

26.4.2 WADLドキュメントの削除方法

削除するWADLドキュメントをいずれかのリソースが参照する場合、WADLリソースを削除する前にそれらの参照を削除します。Oracle Service BusコンソールのWADL定義エディタでWADLドキュメントを開き、右上の「ツール」アイコンをクリックし、「参照」を選択してそこに参照があるかどうかを確認します。JDeveloperでは、WADLドキュメントを右クリックして、「依存性の参照」を選択します。

WADLドキュメントを削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するWADLドキュメントを含むプロジェクトとフォルダを開きます。

2. WADLドキュメントの名前を右クリックして、「削除」を選択します。

WADLリソースが削除されます。他のリソースがこのリソースを参照している場合、削除の警告アイコンが表示されます。確認のための警告は表示されますが、リソースを削除することはできます。この場合、削除されたリソースへの未解決の参照が原因で、競合が発生する可能性があります。

3. JDeveloperを使用している場合、確認ダイアログに、WADLドキュメントの参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

26.5 JDeveloperを使用したRESTサービスの作成

JDeveloperを使用して、RESTビジネスおよびプロキシ・サービスを作成できます。Service Bus概要エディタで「RESTバインディングの作成」ウィザードを使用して新しいサービスを作成、既存のWSDLサービスを、パイプラインおよび分割-結合を含めてRESTとして公開、または「プロキシ・サービスの作成」または「ビジネス・サービスの作成」ウィザードを使用してRESTサービスを作成できます。「MDSリポジトリに格納されたアーティファクトの使用」で説明されているように、Oracle Metadata Services (MDS)リポジトリに保存されたアーティファクトからRESTサービスを作成することもできます。

また、RESTプロキシおよびビジネス・サービスは、Service Busコンソールから作成するか、JDeveloperで作成されたリソースを含むプロジェクトまたはリソースを構成JARファイルを使用してコンソールにインポートできます。

RESTプロキシ・サービスは、次のものを呼び出すことができます。

- 同じWSDLバインドのWSDLベースのプロキシ・サービス、パイプライン、分割-結合またはビジネス・サービス。

- SOAP 1.1または1.2バインディング・タイプのプロキシ・サービス、パイプラインまたはビジネス・サービス。SOAPバージョンは、呼び出すプロキシ・サービスと同じである必要があります。

- 同じWADL参照およびWSDLバインドのRESTビジネス・サービス。

- その他のRESTベース・ビジネス・サービスまたはプロキシ・サービス。

RESTのプロキシ・サービスは、RESTおよびHTTPトランスポート・ビジネス・サービスによって呼び出すことができます。

RESTサービスとRESTバインディングの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のSOAコンポジット・アプリケーションでのREST操作の統合に関する項を参照してください。

注意:

RESTバインディングを作成したら、フォルト・スキーマは変更しないでください。フォルト・バインディングの詳細は、Oracle SOA Suiteを使用したSOAアプリケーションの開発のRESTフォルト・バインディングに関する必知事項を参照してください。

26.5.1 ネイティブRESTサービスの作成

ネイティブRESTサービスは、JDeveloperおよびService Busコンソールを使用して作成できます。

次のトピックを参照して、ネイティブRESTプロキシ・サービスを作成します。

- Service Busコンソールを使用したプロキシ・サービスの作成方法

- JDevleoperを使用したプロキシ・サービスの作成方法

- Service Busコンソールを使用した入力済RESTプロキシ・サービスの作成方法

次のトピックを参照して、ネイティブRESTビジネス・サービスを作成します。

- Service Busコンソールを使用したビジネス・サービスの作成方法

- JDeveloperを使用したビジネス・サービスの作成方法

- Service Busコンソールを使用した型付きRESTビジネス・サービスの作成方法

26.5.2 JDeveloperを使用したService Bus用のWSDLベースRESTサービスの作成方法

RESTバインディングを使用してプロキシまたはビジネス・サービスを作成すると、Service Busでは、必要なWADLファイルがHTTPタイプのプロキシまたはビジネス・サービスとともに生成されます。RESTバインディングはWSDLドキュメントをベースにすることができます。これにより、XMLに変換された受信ペイロードを使用して、RESTリソース/動詞を内部WSDL操作およびXMLスキーマにマッピングします。RESTバインディングの構成方法に応じて、プロキシ・サービスが既存のWSDLファイルに基づくことも、ユーザーがプロキシ・サービスの生成時にWSDLファイルを作成することもできます。

かわりに入力済のネイティブRESTサービスを作成する方法については、「JDeveloperを使用したService Bus用の入力済RESTサービスの作成方法」を参照してください。

JDeveloperでWSDLベースRESTプロキシまたはビジネス・サービスを作成するには:

1. 「コンポーネント」ウィンドウから「Service Bus」を選択し、RESTバインディングをデザイナの「プロキシ・サービス」または「外部サービス」レーンにドラッグします。

ヒント:

また、スイムレーンを右クリックして、表示されたメニューから「REST」を選択することもできます。

RESTバインディングの作成ウィザードが表示されます。

2. RESTサービスの名前を入力します。

ヒント:

構成フィールドについては、「ヘルプ」をクリックするか、[F1]キーを押してください。「ヘルプ」は、このプロセスで使用するすべてのダイアログで使用できます。

3. 「タイプ」フィールドはデフォルト値のままにします。これは、プロキシ・サービスを作成しているのか(「サービス」)、ビジネス・サービスを作成しているのか(「参照」)によって選択されます。

4. 「サービスはWSDLインタフェースを使用してコンポーネントを起動します」オプションを選択します。

5. (オプション)「XMLスキーマの順序付けの適用」オプションを選択し、JSONペイロードがXMLスキーマの要素順に一致するよう並べ替えます。これには、インバウンド・リクエスト・ペイロードおよびアウトバウンド・リクエストからのレスポンスが含まれます。

6. RESTビジネス・サービスを作成している場合は、「ベースURI」に入力します。これは、ビジネス・サービスのエンドポイントURIです。

7. 「リソース」セクションで次を実行します。

a. デフォルトのパス・エントリの/をダブルクリックします。
「RESTリソースの更新」ダイアログが表示されます。

b. 「相対パス」フィールドで、リソース・パスを指定し、「OK」をクリックします。

c. 追加リソースを定義して個々の操作に割り当てるには、「リソース」セクションの「追加」アイコンをクリックして、前述の手順を繰り返します。

8. 次のいずれかを実行して、操作バインディングを追加および定義します。

- 手動で操作バインディングを作成し、定義するには、「操作バインディングの追加」を選択し、手動で新しいREST操作を作成および定義します。複数のバインディングを追加できます。詳細は、「REST操作の作成または構成方法」を参照してください。

- (ビジネス・サービスのみ)「構成ショートカット」セクションから「追加」をクリックし、「WADLサービスに基づく操作の追加」を選択して「WADLの選択」ダイアログを起動し、実装する操作を含む既存のWADLファイルを選択します。ファイル・システム、アプリケーション、MDSリポジトリなどにあるWADLファイルを参照できます。

- (プロキシ・サービスのみ)「構成ショートカット」セクションから「追加」をクリックし、「RESTコンポーネントや参照の有効化」を選択して「リソース・チューザ」を起動し、現在のアプリケーションでREST操作の生成元となるService Busコンポーネントを選択します。

- (プロキシ・サービスのみ)「構成ショートカット」セクションから「追加」をクリックし、「REST外部Webサービスの有効化」を選択して「WSDLの選択」を起動し、REST操作の生成元となるWSDLファイルを選択します。ファイル・システム、アプリケーション、MDSリポジトリ、UDDIレジストリなどにあるWSDLファイルを参照できます。

「操作バインディング」表に操作が表示されます。

9. バインディングを構成するには、次を実行します。

a. バインディングをダブルクリックします。
「REST操作バインディング」ダイアログが表示されます。

b. 「REST操作の作成または構成方法」の説明に従ってバインディングを構成します。

10. RESTバインディングの作成ウィザードで「OK」をクリックします。
HTTPプロキシまたはビジネス・サービスが「プロキシ・サービス」または「外部サービス」レーンに追加され、そのファイルがプロジェクトに追加されます。関連付けられたWADLファイルがプロジェクトに追加されます。サービスとWADLファイルの両方に、手順2でRESTサービスに対して指定した名前と同じ名前が付けられます。

11. 新しいビジネス・サービスを構成するには、「ビジネス・サービスの構成」を参照してください。新しいプロキシ・サービスを構成するには、「プロキシ・サービスの構成」を参照してください。

12. JDeveloperのツールバーで「すべて保存」をクリックします。

26.5.3 JDeveloperを使用したService Bus用の入力済RESTサービスの作成方法

RESTバインディングを使用してプロキシまたはビジネス・サービスを作成すると、Service Busでは、必要なWADLファイルがHTTPタイプのプロキシまたはビジネス・サービスとともに生成されます。RESTバインディングの構成方法に応じて、プロキシ・サービスが既存のWADLファイルをベースにすることも、ユーザーがプロキシ・サービスの生成時にWADLファイルを作成することもできます。

かわりにWSDLベースRESTサービス(Service Bus 12.1.3で使用)を作成する場合は、「JDeveloperを使用したService Bus用のWSDLベースRESTサービスの作成方法」を参照してください。

JDeveloperで入力済ネイティブRESTプロキシまたはビジネス・サービスを作成するには:

1. 「コンポーネント」ウィンドウから「Service Bus」を選択し、RESTバインディングをデザイナの「プロキシ・サービス」または「外部サービス」レーンにドラッグします。

ヒント:

また、スイムレーンを右クリックして、表示されたメニューから「REST」を選択することもできます。

RESTバインディングの作成ウィザードが表示されます。

2. RESTサービスの名前を入力します。

ヒント:

構成フィールドについては、「ヘルプ」をクリックするか、[F1]キーを押してください。「ヘルプ」は、このプロセスで使用するすべてのダイアログで使用できます。

3. 「タイプ」フィールドはデフォルト値のままにします。これは、プロキシ・サービスを作成しているのか(「サービス」)、ビジネス・サービスを作成しているのか(「参照」)によって選択されます。「次へ」をクリックします。

4. RESTビジネス・サービスを作成している場合は、「ベースURI」に入力します。これは、ビジネス・サービスのエンドポイントURIです。

5. 「リソース」セクションで次を実行します。

a. デフォルトのパス・エントリの/をダブルクリックします。
「RESTリソースの更新」ダイアログが表示されます。

b. 「相対パス」フィールドで、リソース・パスを指定し、「OK」をクリックします。

c. 追加リソースを定義して個々の操作に割り当てるには、「リソース」セクションの「追加」アイコンをクリックして、前述の手順を繰り返します。

6. 次のいずれかを実行して、メソッドを追加および定義します。

- RESTメソッドを手動で作成し、定義するには、「メソッド」セクションで「追加」アイコンをクリックします。詳細は、「JDeveloperでのRESTメソッドの作成または構成方法」を参照してください。

- 「構成ショートカット」セクションから「追加」をクリックし、「WADLサービスからリソースとメソッドを追加」を選択して「WADLチューザ」ダイアログを起動し、追加するメソッドを含む既存のWADLファイルを選択します。ファイル・システム、アプリケーション、MDSリポジトリなどにあるWADLファイルを参照できます。

メソッドが「メソッド」表に表示されます。

7. メソッドを構成するには、次を実行します。

a. メソッドをダブルクリックします。
「RESTメソッド定義」ダイアログが表示されます。

b. 「JDeveloperでのRESTメソッドの作成または構成方法」に示すとおり、メソッドを構成します。

8. RESTバインディングの作成ウィザードで「OK」をクリックします。
HTTPプロキシまたはビジネス・サービスが「プロキシ・サービス」または「外部サービス」レーンに追加され、そのファイルがプロジェクトに追加されます。関連付けられたWADLファイルがプロジェクトに追加されます。サービスとWADLファイルの両方に、手順2でRESTサービスに対して指定した名前と同じ名前が付けられます。

9. 新しいビジネス・サービスを構成するには、「ビジネス・サービスの構成」を参照してください。新しいプロキシ・サービスを構成するには、「プロキシ・サービスの構成」を参照してください。

10. JDeveloperのツールバーで「すべて保存」をクリックします。

26.5.4 JDeveloperでのREST操作の作成または構成方法

手動でREST操作を作成したり、それらの操作または既存のサービス・コンポーネントやWebサービスから生成した操作を手動で変更することが可能です。どちらのプロセスも「REST操作バインディング」ダイアログを使用します。これらの手順は、「JDeveloperを使用したService Bus用のWSDLベースRESTサービスの作成方法」の手順8にあります。

注意:

操作を作成した方法、および操作を作成しているのか更新しているのかによって、次に説明するフィールドの一部は編集できない場合があります。

REST操作を作成または構成するには:

1. 「RESTサービスの作成」ダイアログで、編集する操作をダブルクリックします。
「REST操作バインディング」ダイアログが表示されます。

2. 新しい操作を作成している場合は、その操作の名前と必要に応じて説明を入力します。

3. 必要に応じて「リソース」リストから新しいリソースを選択します。

4. 「HTTP動詞」リストから、使用するHTTPメソッドを選択します。

5. リクエストのスキーマを定義するには、次のいずれかを実行します。

- 「スキーマ・ファイルを参照」をクリックして、その操作のXMLスキーマ・タイプに移動し、これを選択します。

- 「ネイティブ・フォーマットのスキーマの定義」をクリックし、ネイティブ・フォーマット・ビルダーを起動してカスタムの変換を定義します。

「要素」フィールドおよびURIパラメータが、選択内容に基づいて更新されます。

6. 「URIパラメータ」セクションで次を実行します。

- 「サンプルURL」ページで実行時に操作を呼び出すURLを表示するには、操作のURLを生成をクリックします。

- パラメータのスタイルを変更するには、パラメータの「スタイル」列をダブルクリックし、「スタイル」リストの「問合せ」または「テンプレート」を選択します。

- パラメータのタイプを変更するには、パラメータの「タイプ」列をダブルクリックし、「タイプ」リストから新しいタイプを選択します。

- パラメータのデフォルト値を入力するには、更新するパラメータの「デフォルト値」列をダブルクリックし、「デフォルト値」フィールドで使用する値を入力します。

- XPath式関数の追加または更新のために式ビルダーを起動するには、更新するパラメータの「式」列をダブルクリックし、「式」フィールドの隣の「式ビルダー」アイコンをクリックします。式ビルダーを使用して、使用するXPath式を定義します。

- パラメータを手動で追加するには、「パラメータの追加」をクリックして、表示される新しい行に値を入力します。

- パラメータを削除するには、その行を選択して、「パラメータの削除」をクリックします。

7. 「レスポンス」タブをクリックして、レスポンスを構成します。

8. 「HTTPステータス」フィールドに、成功した操作に対して返すHTTPステータス・コードを入力します(区切りは空白による)。

9. 「ペイロード」フィールドで、レスポンスのペイロードのタイプを選択します。

10. 後でファイルに保存可能なサンプル・ペイロードを生成するには、「サンプル・ペイロードの生成」をクリックします。

11. レスポンスのスキーマを定義するには、次のいずれかを実行します。

- 「スキーマ・ファイルを参照」をクリックして、その操作のXMLスキーマ・タイプに移動し、これを選択します。

- 「ネイティブ・フォーマットのスキーマの定義」をクリックし、ネイティブ・フォーマット・ビルダーを起動してカスタムの変換を定義します。

「要素」フィールドおよびフォルト・バインディングが、選択内容に基づいて更新されます。

12. フォルト・バインディングを手動で追加するには、「フォルト・バインディングの追加」をクリックします。「RESTフォルト・バインディング」ダイアログで次を実行します。

a. フォルトの名前を入力します。

b. フォルトに対して返されるHTTPのステータスのリストを入力します(区切りは空白による)。

c. フォルトのペイロードのタイプを選択します。フォルトのサンプル・ペイロードを生成するには、「サンプル・ペイロードの生成」をクリックします。

d. フォルトを定義するスキーマおよび要素を選択します。

e. 「OK」をクリックします。

13. フォルトのHTTPステータスまたはペイロード・タイプを更新するには、フォルト・バインディング表でこれをダブルクリックし、「RESTフォルト・バインディング」ダイアログの情報を更新します。

14. 「REST操作バインディング」ダイアログで「OK」をクリックします。

26.5.5 JDeveloperでのRESTメソッドの作成または構成方法

手動でRESTメソッドを作成したり、それらのメソッドまたは既存WADLから生成したメソッドを手動で変更することが可能です。どちらのプロセスも、「RESTメソッド定義」ダイアログを使用します。これらの手順は、「JDeveloperを使用したService Bus用の入力済RESTサービスの作成方法」の手順6にあります。

注意:

メソッドを作成した方法、およびメソッドを作成しているのか更新しているのかによって、次に説明するフィールドの一部は編集できない場合があります。

RESTメソッドを作成または構成するには:

1. 「RESTサービスの作成」ダイアログで、編集するメソッドをダブルクリックします。
「RESTメソッド定義」ダイアログが表示されます。

2. 新しいメソッドを作成している場合は、その名前とオプションの説明を入力します。

3. 必要に応じて「リソース」リストから新しいリソースを選択します。

4. 「HTTP動詞」リストから、使用するHTTPメソッドを選択します。

5. 「URIパラメータ」セクションで次を実行します。

- 「サンプルURL」ページで実行時にメソッドを呼び出すURLを表示するには、「メソッドのサンプルURLを生成します」をクリックします。

- パラメータのスタイルを変更するには、パラメータの「スタイル」列をダブルクリックし、「スタイル」リストの「問合せ」または「テンプレート」を選択します。

- パラメータのタイプを変更するには、パラメータの「タイプ」列をダブルクリックし、「タイプ」リストから新しいタイプを選択します。

- パラメータのデフォルト値を入力するには、更新するパラメータの「デフォルト値」列をダブルクリックし、「デフォルト値」フィールドで使用する値を入力します。

- パラメータを手動で追加するには、「パラメータの追加」をクリックして、表示される新しい行に値を入力します。

- パラメータを削除するには、その行を選択して、「パラメータの削除」をクリックします。

6. 「レスポンス」タブをクリックして、レスポンスを構成します。

7. 「HTTPステータス」フィールドに、成功したメソッドと失敗したメソッドに対して返すHTTPステータス・コードを入力します。

8. 「ペイロード」フィールドで、レスポンスのペイロードのタイプを選択します。

9. 「RESTメソッド定義」ダイアログで、「OK」をクリックします。

26.5.6 HTTPのプロキシまたはビジネス・サービスをRESTとして公開する方法

JDeveloperで、既存のWSDLベースのプロキシ・サービス、パイプライン、分割-結合またはビジネス・サービスを、プロキシ・サービスと関連付けられたWADLドキュメントを生成するRESTサービスとして公開できます。また、RESTベースのビジネス・サービスを公開することもできます。生成されたプロキシ・サービスは、自動的に作成元のサービスにワイヤリングされます。

Service BusサービスをRESTとして公開するには:

1. アプリケーション・ナビゲータで、RESTサービスとして公開するプロキシ・サービス、パイプライン、分割-結合またはビジネス・サービスを見つけます。

2. サービスを右クリックし、「Service Bus」をポイントして、「RESTで公開」を選択します。

RESTバインディングの作成ウィザードが表示されます。

3. 必要に応じて、RESTサービスの名前を変更します。

ヒント:

「タイプ」フィールドは変更できません。サービスを公開しているため、デフォルトは「サービス」(プロキシ・サービス)です。

構成フィールドについては、「ヘルプ」をクリックするか、[F1]キーを押してください。「ヘルプ」は、このプロセスで使用するすべてのダイアログで使用できます。

4. JSONペイロードをXMLスキーマ内の要素の順序に応じて並べ替えるように指定するには、「XMLSchemaの順序付けを強制」を選択します。

5. 新しいリソース・パスを入力するには、「リソース」セクションで「追加」アイコンをクリックします。

6. 必要に応じて、「操作バインディング」セクションの「HTTP動詞」列をダブルクリックして、メソッドを構成します。

7. 「OK」をクリックします。

8. 「ファイルのローカライズ」ダイアログが表示され、元のディレクトリ構造を維持する必要がない場合は、チェック・ボックスを選択解除して、「OK」をクリックします。

9. 次のいずれかを行います。

- 「ビジネス・サービスの構成」の説明に従って、ビジネス・サービスの構成を続けます。

- 「プロキシ・サービスの構成」の説明に従って、プロキシ・サービスの構成を続けます。

10. JDeveloperのツールバーで「すべて保存」をクリックします。

26.5.7 RESTのURIパラメータの構成に関する必知事項

12.1.3スタイルでWSDLベースRESTサービスのRESTバインディングを作成するとき、XPath式を使用して、操作のURIパラメータの値を定義できます。問合せスタイルの操作パラメータを構成する場合、ペイロードまたはプロパティに基づいた式にできます。$msg.parameters/tns:symbolのようなペイロードに基づく式は、該当する抽象リクエスト・メッセージ部分の要素または属性の値を指定します。$property.SomePropertyのようなプロパティに基づく式は、実行時に$inbound変数のリクエスト・メタデータの値を指定します。

インバウンド・リクエストの場合、パイプラインの$inbound変数を問い合せ、指定のメタデータ要素の値を取得できます。アウトバウンド・リクエストの場合、パイプラインの$outbound変数の部分に適した値を対応するリクエスト・パラメータに割り当てることができます。

26.6 WebブラウザでのWADLドキュメントへのアクセス

設計時のWADLドキュメントと有効なWADLドキュメントはどちらもWebブラウザを介して表示できます。ブラウザ・ウィンドウからファイルにアクセスすると、ファイルのコンテンツがXML形式で表示されます。Service Busでは、コンテンツの閲覧が容易になるようにユーザーが読取り可能なインタフェースも用意されています。

26.6.1 WADLドキュメントのXML形式での表示

次のいずれかを実行して、Service Bus WADLドキュメントをWebブラウザで表示します。

- サービスの有効なWADLを表示するには、次の構文を使用して固定HTTP URLをWebブラウザに入力します。

http://host:port/sbresource?PROXY/project_path/proxy_service_name

または

http://host:port/sbresource?BIZ/project_path/business_service_name

この方法は、Service Busが、サービスの有効なWADLドキュメントを生成できるサービスすべてに使用できます。このサービスにWSDLドキュメントも関連付けられている場合、前述の構文では、サービスの有効なWADLドキュメントのみが表示されます。

- 設計時のWADLドキュメントを表示するには、次の構文を使用して固定HTTP URLをWebブラウザに入力します。

http://host:port/sbresource?WADL/project_path/wadl_name

26.6.2 WADLドキュメントの読取り可能形式での表示

設計時のWADLドキュメントおよびサービスの有効なWADLドキュメントは、読みやすい形式を使用してブラウザで表示できます。WADLドキュメントを表示するには、Webブラウザを開き、次の説明に従いサービスのURLを入力します。

- サービスの有効なWADLドキュメントを表示するには、次の構文を使用します。

http://host:port/sbresource?PROXY/project_path/proxy_service_name&HTML=true

または

http://host:port/sbresource?BIZ/project_path/business_service_name&HTML=true

このサービスにWSDLドキュメントも関連付けられている場合、前述の構文では、サービスの有効なWADLドキュメントのみが表示されます。

- 設計時のWADLドキュメントを表示するには、次の構文を使用します。

http://host:port/sbresource?WADL/project_path/wadl_name&HTML=true

WADLコンテンツは、次のイメージのような形式でブラウザに表示されます。

図26-1 WADLドキュメントの読取り可能なインタフェース

27 DSPトランスポートの使用

この章では、DSP (Oracle Data Service Integrator)トランスポートの概要と、サービスでの使用および構成方法について説明します。

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

- DSPトランスポートの概要

- Service Busのデータ・サービスの有効化

- DSP転送の使用

- DSPトランスポート構成のリファレンス

Service BusとOracle Data Service Integratorとの相互運用性サポートの詳細は、『Oracle Service Busの管理』の相互運用性のシナリオと考慮事項に関する項を参照してください。Oracle Data Service Integratorの詳細は、Data Service Integratorによるアプリケーションの開発を参照してください。

27.1 DSPトランスポートの概要

Oracle Data Service Integratorには、DSPトランスポートを介してService Busからアクセスでき、Service Busでデータ・サービスを完全に使用できます。また、データ・サービスをWebサービスとして公開する方法と比較すると、この方法を使用した方が効率的で柔軟にデータ・サービスにアクセスできます。

27.2 Service Busのデータ・サービスの有効化

Oracle Data Service Integratorデータ・サービスをService Busクライアントで使用できるようにするには、次の手順が必要です。

- データ・サービス用のWSDLファイルを生成し、その新しいWSDLファイルをService Busにインポートします。

- WSDLファイルに基づいてビジネス・サービスを作成および構成します。

- ビジネス・サービスに基づいてプロキシ・サービスを作成および構成します。

- パイプラインを作成して、プロキシ・サービスとビジネス・サービス間でメッセージのルーティングと変換を行うようにそのパイプラインを構成します。

これらのタスクを完了すると、Service Busを介してデータ・サービスを呼び出せるようになります。

27.3 DSPトランスポートの使用

この項では、Service Busでのデータ・サービスの使用例を示すサンプル・プロジェクトについて説明します。このサンプルの手順を実行するには、サンプルWebLogicドメインを使用する必要があります。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

- Oracle Data Service IntegratorでのWSDLファイルの生成

- Service Busプロジェクトの作成

27.3.1 Oracle Data Service IntegratorでのWSDLファイルの生成

Oracle Data Service Integratorで次の手順を実行します。

- ステップ1: サーバーの起動

- ステップ2: データ・サービスからのWSDLファイルの生成

- ステップ3: Webサービス・アドレスの取得

27.3.1.1 手順1サーバーの起動

Oracle Data Service Integratorサーバーが起動していない場合は、起動します。このシナリオでは、Oracle Data Service Integratorで提供されているサンプルRetailDataspaceをサンプル・ドメインで使用します。

27.3.1.2 手順2データ・サービスからのWSDLファイルの生成

Data Services Studioを使用して、WSDLファイルをデータ・サービスから生成できます。また、Oracle Data Service Integratorコンソールを使用してWSDLファイルをエクスポートしたり、既存のWebサービス・マップ・ファイルからWSDL定義を表示してコピーしたりすることもできます。詳細と手順については、Data Service Integratorによるアプリケーションの開発のデータ・サービスからのWebサービス・マップおよびWSDLの生成に関する項を参照してください。

27.3.1.3 ステップ3: Webサービス・アドレスの取得

次の手順を使用して、WSDLファイルのURLアドレスを取得します。

1. WSファイル(たとえばOrderService.ws)を右クリックします。

2. 「Webサービスのテスト」を選択します。

3. テスト・クライアントが開いたら、URLアドレスを保存します。

次に、OrderServiceサンプルのアドレスを示します。

http://localhost:7001/RetailDataspace/RetailApplication/OrderManagement/OrderService.ws?WSDL

27.3.2 Service Busプロジェクトの作成

Oracle Service BusコンソールまたはJDeveloperで次の手順を実行します。

- ステップ4: データ・サービスWSDLファイルのService Busへのインポート

- ステップ5: ビジネス・サービスの作成

- ステップ6: プロキシ・サービスの作成

- ステップ7: パイプラインの作成

- ステップ8: 設定のテスト

27.3.2.1 ステップ4: データ・サービスWSDLファイルのService Busへのインポート

Service Busでは、Oracle Data Service Integratorで生成されたWSDLファイルを、Oracle Service BusコンソールまたはJDeveloperを使用して、Service Busにインポートできます。このシナリオでは、Service Busサンプル・サーバーとデフォルト・プロジェクトを使用します。デフォルトのユーザー名は、weblogicです。サンプル・サーバーを作成したときにパスワードを定義しています。

新規Service Busプロジェクトを作成し、WSDLファイルおよび関連するファイルをその新規プロジェクトにインポートします。インポートの詳細は、「リソースおよび構成のインポートとエクスポート」を参照してください。

27.3.2.2 ステップ5: ビジネス・サービスの作成

Oracle Data Service IntegratorからインポートしたWSDLファイルから、ビジネス・サービスを作成します。次のガイドラインを使用して、ビジネス・サービスを構成します。

- ビジネス・サービスのトランスポートには、「dsp」を選択します。

- サービス・タイプに対して、「WSDL」を選択し、インポートされたWSDLファイルを参照して選択し、適切なポートまたはバインディング(たとえばOrderServiceSoapBinding)を選択します。

- エンドポイントURIについては、Oracle Data Service IntegratorプロジェクトのURI(たとえばt3://localhost:7001/RetailDataspace)を入力します。

ビジネス・サービス定義エディタの「トランスポートの詳細」ページで、トランスポート設定を構成します。詳細は、表27-1またはトランスポート詳細ページに関するオンライン・ヘルプを参照してください。ビジネス・サービスの作成の詳細は、「ビジネス・サービスの作成と構成」を参照してください。

27.3.2.3 ステップ6: プロキシ・サービスの作成

「JDeveloperでの既存のサービスからのプロキシ・サービスの生成方法」に従って、ビジネス・サービスからプロキシ・サービスを生成します。JDeveloperでは、ビジネス・サービスからプロキシ・サービスのみを生成できます。あるいは、プロキシ・サービスをビジネス・サービスから生成するのではなくコンソールで作成できます。

実際には、暗号化キー、デジタル署名キー、およびSSLクライアント認証キーを識別する可能性があります。しかし、この例ではいずれも識別する必要はありません。DSPトランスポートでは、プロキシ・サービス提供の文字セットを使用します。したがって、データ・サービス・トランスポートを呼び出す前にデフォルトの文字セットを変更する必要がある場合、変換のエンコーディングは、プロキシ・サービス自体で処理する必要があります。

27.3.2.4 ステップ7: パイプラインの作成

データ変換を実行してデータをプロキシ・サービスからビジネス・サービスにルーティングするようにパイプラインを構成します。詳細は、「Oracle Service Busコンソールでのパイプラインの操作」または「Oracle JDeveloperでのパイプラインの操作」を参照してください。

27.3.2.5 ステップ8: 設定のテスト

次の手順を使用して、前述の手順で生成したプロキシ・サービスからOracle Data Service Integratorデータ・サービスにアクセスできるかどうかをテストします。

1. JDeveloperでプロジェクトをデプロイするか、Oracle Service Busコンソールでセッションをアクティブ化します。

2. 作成したプロキシ・サービスのテスト・コンソールを起動します。詳細は、「テスト・コンソールへのアクセス」を参照してください。

3. 「使用可能な操作」リストからデータ・サービス操作(たとえばgetOrderByCustID)を選択します。

4. 「ペイロード」フィールドに、データ・サービスで必要な情報を入力します。次に例を示します。

<ord:getOrderByCustID
xmlns:ord="ld:RetailApplication/OrderManagement/OrderService.ws">
<ord:custID>CUSTOMER3</ord:custID>
</ord:getOrderByCustID>

5. 「実行」をクリックします。図27-1のようにレスポンス・ドキュメントにデータが表示されます。

図27-1 Service Busテスト・コンソールからのリクエストとレスポンス

27.4 DSPトランスポート構成のリファレンス

この項では、ビジネス・サービスのDSPトランスポート固有のプロパティについて説明します。

- DSPトランスポート・エンドポイントURI

- DSPトランスポートを使用するビジネス・サービスの構成

27.4.1 DSPトランスポート・エンドポイントURI

DSPトランスポートを使用するビジネス・サービスを作成するときは、次の形式でビジネス・サービスのエンドポイントURIを入力します。

t3://dsp-ip-address:port/dsp-app-name

次に例を示します。

t3://localhost:7001/RetailDataspace

27.4.2 DSPトランスポートを使用するビジネス・サービスの構成

次の表は、DSPベースのビジネス・サービスの構成に使用するプロパティを示しています。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

表27-1 ビジネス・サービスのDSPトランスポート構成プロパティ

プロパティ

説明

デバッグ・レベル

次のオプション1つを入力してデバッグ情報の処理方法を指定します。

- 0: デバッグ情報なし

- 1: リクエスト・メッセージに関する情報を出力

- 3: リクエスト・メッセージとレスポンス・メッセージに関する情報を出力

サービス・アカウント

サービスにアクセスするための認証に使用するサービス・アカウントを入力します。サービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。

詳細は、「サービス・アカウントの操作」を参照してください。

ディスパッチ・ポリシー

レスポンス処理のための返信メッセージのポストに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

28 EJBトランスポートの使用

この章では、EJBトランスポートの概要と、サービスでの使用および構成方法について説明します。 Service Busは、EJBトランスポートを使用して、サポート対象プラットフォームにデプロイされたEJB 2.1またはEJB 3.0ステートレス・セッションBeanのネイティブRMI呼出しをサポートします。これにより、トランザクション対応のセキュアな通信が可能になります。また、EJBトランスポートを利用し、Service Busを介してEJBをWebサービスとして公開することもできます。

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

- EJBトランスポートの概要

- EJBを呼び出すサービスを作成するための前提条件

- EJBビジネス・サービスの呼出し

- WebサービスとしてのEJBの公開

- EJBトランスポートの詳細な説明

- EJBトランスポートのトラブルシューティング

- EJBトランスポート構成のリファレンス

28.1 EJBトランスポートの概要

Service Busでは、EJBトランスポートが構成されたビジネス・サービスを使用して、パブリッシュ、サービス・コールアウトおよびサービスの呼出しを実行できます。EJBトランスポートを使用するプロキシ・サービスは作成できません。

EJBトランスポートには次の機能があります。

- トランザクション整合性 - EJBビジネス・サービスは、グローバル・トランザクションのコンテキスト内で呼び出すことができます。また、EJBトランスポートは、EJBを呼び出す前にグローバル・トランザクションを中断または開始できます。

- セキュリティ伝播: Service Busクライアントから確立されたセキュリティ・コンテキストは、別の外部システムに伝播されます。たとえば、受信した、認証を必要とするService BusへのSOAP over HTTPリクエストは、Service Busによって認証され、認証されたサブジェクトはその後EJBサーバーに伝播されます。セキュリティ伝播の詳細は、『Oracle WebLogic Serverセキュリティの管理』のクロスドメイン・セキュリティのサポートに関する重要情報が記載された項を参照してください。

- HTTPトンネリングおよび暗号化通信: HTTPトンネリングを使用して、ファイアウォール内のEJBにアクセスできます。セキュリティを強化するには、SSLを使用してEJBサーバーとのすべての通信を暗号化します。

- JNDIプロバイダ: EJBトランスポートは、JNDIプロバイダ(Service Busリソース)を使用します。JNDIプロバイダは、リモート・サーバーにアクセスするための通信プロトコルやセキュリティ資格証明を定義します。JNDIプロバイダは、複数のEJBビジネス・サービスで再利用できます。これにより、管理者によるリモートEJBサーバー構成の一元的な管理が実現します。
JNDIプロバイダ・リソースの詳細は、「JNDIプロバイダ・子ソースの操作」を参照してください。

- 高性能キャッシュ: EJBトランスポートは高性能キャッシュに基づいて構築されています。そのため、確立された接続を再利用して、EJBスタブのルック・アップを最小限に抑えられます。

- フェイルオーバーとロード・バランシング: EJBトランスポートでは、ロード・バランシングまたはフェイルオーバー、もしくは両方のために、同じEJBが複数のドメインまたは1つのクラスタにデプロイされているシナリオを利用できます。

- XMLとJavaの拡張バインディング機能: EJBトランスポートは、Oracle WebLogic Server JAX-WSスタックを使用して、JavaとXMLのバインディングを実行します。JAX-WSスタックは、XML Beanなどの高度なJavaオブジェクトをサポートする高性能のエンジンです。Java型がスタックによって認識されない場合、これらのJava型をサポートできるようにするための拡張メカニズムが提供されます。(コンバータ・クラスを使用した)この拡張メカニズムについては、「サポートされる型およびコンバータ・クラス」を参照してください。

- インテリジェントな再試行: EJBトランスポートでは、EJBの呼出し中に発生する可能性のある障害の性質に基づいて再試行が決定されます。

28.2 EJBを呼び出すサービスを作成するための前提条件

EJBトランスポートを使用するようにビジネス・サービスを構成するには、JNDIプロバイダ・リソースおよびクライアントJARリソースを作成する必要があります。次のトピックでは、Service Bus内のEJBトランスポート・ビジネス・サービスを設計および構成するために必要な手順について説明します。

- JNDIプロバイダ・リソースの登録

- EJBクライアントまたはコンバータJARリソースの登録

28.2.1 JNDIプロバイダ・リソースの登録

JNDIプロバイダ・リソースでは、リモートOracle WebLogic ServerドメインのJNDIツリーにバインドされているEJBスタブを取得するために使用される通信プロトコルおよびセキュリティ資格証明を指定できます。通常、ターゲットEJBはService Busと同じドメイン内にはありません。この場合、JNDIプロバイダ・リソースを登録する必要があります。EJBが同じドメイン内にある場合、プロバイダを定義して資格証明を指定し、スタブ・キャッシングを利用できます。ただし、この場合、省略可能です。

JNDIプロバイダには、リモート接続とEJBスタブのための高性能なキャッシング・メカニズムがあります。Service BusからOracle WebLogic Serverドメインへの推奨される通信プロトコルは、t3またはt3sです。メッセージがファイアウォールを通過する必要がある場合は、HTTPトンネリングを使用できます。

注意:

Oracle WebLogic Serverの外部JNDIプロバイダを使用できますが、使用しないことをお薦めします。

このトランスポートでは、双方向SSLまたはクライアント証明書によるJNDIツリーのルックアップまたはEJBのメソッドへのアクセスをサポートしません。

Service BusへのJNDIプロバイダ・リソースの登録と構成の詳細は、「JNDIプロバイダ・リソースの操作」を参照してください。

28.2.2 EJBクライアントまたはコンバータJARリソースの登録

クライアントJARファイルがService Busサービスによって使用されるようにするには、そのクライアントJARファイルをService Bus内のリソースとして登録する必要があります。その結果、Service Bus構成の一部となり、プロジェクトからエクスポートすることもプロジェクトにインポートすることもできます。EJBクライアントJARファイルには、Service BusがEJBにアクセスするために必要なインタフェースとクラスが含まれている必要があります。これには、リモート・インタフェースとホーム・インタフェース(EJB 2.1)またはビジネス・インタフェース(EJB 3.0)、およびメソッドのパラメータ型またはアプリケーションの例外など、クライアントが公開される依存型が含まれます。

Service Bus 12.2.1以降、EJBトランスポートはJAX-WSスタックを使用します。JAX-WSスタックでは、JavaクラスのXMLへのマッピング、および逆方向のほとんどのJavaタイプへのマッピングをサポートしています。ほとんどの場合、コンバータ・クラスは必要ありません。このリリースでサポートされているコンバータ・クラスは、大部分が前のバージョンのService Busで作成されたビジネス・サービスとの後方互換性をサポートしています。

ビジネス・サービスにコンバータ・クラスが必要な場合は、コンバータ・クラスを含むJARファイルをService Busリソースとして登録すると、これらのクラスを使用してXMLにマップ可能なJavaクラスにパラメータと戻り値の型をマップできます。または、これらのコンバータ・クラスをEJBクライアントJARにパッケージ化できます。コンバータ・クラスについては、「カスタム・コンバータ・クラス」を参照してください。

EJBクライアントJARを使用するときは、次のガイドラインを考慮してください。

- システム・クラスパスでのホーム・インタフェースおよびリモート・インタフェースの追加は推奨されず、Service Busではサポートされません。

- クライアントJARファイルのサイズを小さくすること、JARファイル当たり1つのホーム・インタフェースを含めること、ejb-jarファイル全体を登録しないことをお薦めします。

- Service Busは、JDK 1.4以上でコンパイルされたclient-jarファイルをサポートします。

28.2.2.1 クライアントJARまたはコンバータJARファイルの追加

「サポートされる型およびコンバータ・クラス」で説明しているように、Service Bus EJB実装の拡張による複雑なタイプの継承を使用するには、コンバータ・クラスを作成して使用する必要があります。Service BusへのクライアントまたはコンバータJARリソースの登録と構成の詳細は、「JARファイルの操作」を参照してください。

28.2.2.2 サービス・アカウントの作成(オプション)

EJBメソッドが保護されている場合、サービス・アカウントを使用した呼出しに使用する資格証明を指定できます。多くの場合、これらの資格証明はJNDIプロバイダで使用される資格証明とは異なります。サービス・アカウントの追加と使用の詳細は、「サービス・アカウントの操作」を参照してください。

28.2.2.3 JNDIツリーでのEJBの検索

EJBのJNDI名がわからない場合は、EJBサーバーのJNDIツリーを参照できます。Oracle WebLogic Server管理コンソールを使用したJNDIツリーの参照については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJNDI内のオブジェクトの表示に関する項を参照してください。

28.3 EJBビジネス・サービスの呼出し

EJBビジネス・サービスは、SOAP XMLビジネス・サービスとして使用できます。EJBビジネス・サービスへのパブリッシュ、ルーティング、コールアウトが可能です。トランザクション・サポートが必要な場合は、サービス品質を「必ず1回」に設定します詳細は、「EJBトランスポートの詳細な説明」を参照してください。

テスト・コンソールを使用して構成を検証したり、XMLリクエストの形式を決定したりすることもできます。

28.4 WebサービスとしてのEJBの公開

EJBトランスポートを使用して、EJBをWebサービスとして簡単に公開できます。

注意:

プロキシ・サービスは既存のEJBビジネス・サービスから作成できません。EJBビジネス・サービスから生成されたWSDLファイルを最初に取得し、そのWSDLファイルに基づいてプロキシ・サービスを作成する必要があります。これを行うには、次の手順を実行します。

1. 公開するEJBを指すEJBビジネス・サービスを作成します。

2. 「サービスの詳細」ページで、EJBビジネス・サービスのWSDLファイルを取得します。

WSDLファイルはJARファイルに含まれています。保留中のセッションがない場合にのみWSDLファイルを取得できます。

3. JARファイルからWSDLファイルを抽出し、WSDLリソースとして登録します。

ビジネス・サービスの構成が変更されると、新しいWSDLファイルが生成されます。この場合、新しいWSDLファイルを取得し、WSDLリソースとして再登録する必要があります。

4. WSDLファイルに基づいてSOAP XMLプロキシ・サービスを作成します。

5. プロキシ・サービスをEJBビジネス・サービスにルーティングするためのパイプラインを作成および編集します。

28.5 EJBトランスポートの詳細な説明

この項では、EJBビジネス・サービスが、設計時の構成の方法に応じて、実行時にどのように動作するかを理解するために、EJBトランスポートについて説明します。

- EJBトランスポートのトランザクション

- EJBトランスポートの再試行およびフェイルオーバー

- EJBトランスポートのエラー処理

- サポートされる型およびコンバータ・クラス

- ビジネス例外クラス

28.5.1 EJBトランスポートのトランザクション

EJBトランスポートは、トランザクションを作成、中断、および伝播できます。Service BusおよびEJBサーバー間のトランザクションはXAトランザクションです。HTTPトンネリングを使用してトランザクションを使用する場合、または専用の通信チャネルがある場合は、トランザクション・マネージャのセキュリティの相互運用を「パフォーマンス」に設定する必要があります。セキュリティの相互運用モードの設定とその他のトランザクション構成の詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のトランザクションの構成に関する項を参照してください。

デプロイメント記述子をXA対応リソースに適切に設定するには、プロキシ・サービスを作成する前に、参照接続ファクトリのXA属性を設定する必要があります。

EJBビジネス・サービスの動作を決定する場合、パイプラインにトランザクション・コンテキストが含まれているかどうか、およびサービスを呼び出すときにパイプラインでどのサービスの品質(QoS)設定が指定されているかを考慮する必要があります。

- 「ベスト・エフォート」QoS: パイプラインで「ベスト・エフォート」QoSが指定されている場合、トランザクションはEJBに伝播されません。継続中のトランザクションは呼出しの前に中断され、呼出し後に再開されます。

- 「必ず1回」QoS: パイプラインでQoSとして「必ず1回」が指定され、EJBがトランザクションをサポートしない場合(つまり、EJBトランスポートの構成ページの「トランザクションをサポートする」オプションが選択されていない場合)、トランザクションはEJBに伝播されません。「ベスト・エフォート」の場合と同様に、継続中のトランザクションは呼出しの前に中断され、呼出し後に再開されます。
EJBがトランザクションをサポートする場合(つまり、EJBトランスポート構成ページの「トランザクションをサポートする」オプションが選択されている場合)、EJBはトランザクションのコンテキスト内で呼び出され、すべての継続中のトランザクションはEJBに伝播されます。トランザクションが存在しない場合、トランザクションは、呼出しの前に作成され、後でコミットされます。

Service BusサービスのQoSの詳細は、「サービスの品質」を参照してください。

28.5.2 EJBトランスポートの再試行およびフェイルオーバー

EJBビジネス・サービスで再試行またはフェイルオーバーが構成されている場合、EJBトランスポートは次のタイプの例外を区別します。

- 実行時例外またはリモート例外: これらは通常、予期しない致命的なエラーまたは通信例外です。

- JAX-WSエンジンによる例外: これらは、XMLからJavaへの変換中に発生する例外です。

- EJBチェック済例外: これらは、EJB実装固有のEJBメソッド署名で宣言される例外です。ビジネス例外とも呼ばれます。

次で説明するように、試行とフェイルオーバーは、エラーのタイプおよびQoSに基づきます。

QoSに「ベスト・エフォート」が指定されている場合

- 実行時例外またはリモート例外がスローされた場合、EJBトランスポートは再試行またはフェイルオーバーを試みます。

- JAX-WSエンジンで例外が発生した場合、パイプラインに対してエラーが生成され、再試行またはフェイルオーバー試行は行われません。

- EJBチェック済例外がスローされた場合、パイプラインに対してエラーが生成され、再試行またはフェイルオーバー試行は行われません。

QoSに「必ず1回」が指定されている場合

- 実行時例外またはリモート例外がスローされ、継続中のトランザクションが(一般的にEJBコンテナによって)「ロールバックのみ」に設定されている場合、EJBコンテナが影響を受け、EJBコンテナまたはEJBのいずれかで致命的なエラーが発生しています。この場合、再試行またはフェイルオーバーの試みは行われず、エラーはパイプラインで発生します。

- 実行時例外またはリモート例外がスローされても、継続中のトランザクションが「ロールバックのみ」に設定されていない場合は、EJBコンテナの呼出し前にエラーが発生しており、EJBトランスポートは再試行またはフェイルオーバーを試みます。この場合、EJBトランスポートでは「必ず1回」のセマンティックが引続き適用されることに注意してください。

- JAX-WSエンジンで例外が発生し、EJBトランスポートによって継続中トランザクションが「ロールバックのみ」に設定される場合、パイプラインに対してエラーが生成され、再試行またはフェイルオーバー試行は行われません。

- EJBチェック済例外がスローされた場合、パイプラインに対してエラーが生成され、再試行またはフェイルオーバー試行は行われません。

EJBビジネス・サービスへのQoS仕様のその他の影響については、「EJBトランスポートのトランザクション」を参照してください。

28.5.3 EJBトランスポートのエラー処理

チェック済例外をスローするときに、EJB仕様に応じて、継続中のトランザクションをロールバックのみに指定できます。EJB開発者によって継続中のトランザクションがロールバックのみに設定されている場合、トランザクションは、最終的にその作成者(多くの場合、プロキシ・サービス)によってロール・バックされます。

継続中のトランザクションがロールバックのみに設定されておらず、チェック済例外が発生した場合、エラー・ハンドラによってパイプラインのEJBチェック済例外を捕捉することが重要です。それらの例外が捕捉されない場合、パイプライン・エラーがプロキシ・サービスに逆に伝播されます。次に、一般的にプロキシ・サービスは、継続中のトランザクションを(トランスポートの実装に応じて)ロールバックします。この結果は意図されたものではない場合があります。

たとえば、次のメソッドを持つEJBがあると仮定します。

public void withdrawFunds(float amount) throws RemoteException, InsufficientFundsException {‚Ä¶}

また、InsufficientFundsException例外がスローされたときに、EJBが現在のトランザクションをロールバックのみに設定しないと仮定します。ほとんどのシナリオにおいて、プロキシ・サービスがトランザクションをロール・バックするのは不適切です。場合によっては、パイプラインにエラー・ハンドラを構成して、エラーを捕捉し、このシナリオを回避する必要があります。

28.5.4 サポートされる型およびコンバータ・クラス

EJBトランスポートは、XMLとJava間の変換を行います。変換は、Oracle WebLogic Server JAX-WSエンジンによって実行されます。EJBトランスポートは、次の型をネイティブにサポートしています。

- プリミティブ型

- XmlObject (Apacheバージョンのみ)

- スキーマで生成されるXMLBean (Apacheバージョンのみ、org.apache.xmlbeans.XmlObjectから拡張されたXMLBean)

- JavaBeanクラス

ネイティブでサポートされる型の一覧は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のJAXBデータ・バインディングの使用に関する項を参照してください。

EJBメソッドは、JAX-WSエンジンでサポートされない(設計時にエラーが報告される)、また、XMLに直接マップしない(実行時にエラーが発生する)パラメータ/戻り値の型を使用できます。サポートされない型の中で最もよく使用される型は、次のとおりです。

- Object、Object[]

- 強く型付けされていないJavaコレクション(List、Setなど)

- JavaBeanパターンに従わないJavaクラス(Mapなど)

これらの型をXMLとJava間の変換に適した型に変換しなくても、カスタム・コンバータ・クラスを記述できます。

28.5.4.1 XMLBeanサポートについて

EJBトランスポートでは、XMLBeanタイプ(org.apache.xmlbeans.*)の入力引数または戻り型のセッションBeanがサポートされています。

12.2.1以降、EJBトランスポートでは、デフォルトのバインディング方式としてJAXBを使用するJAX-WSスタックを使用します。JAXBではXMLBeanタイプは解釈されません。EJBトランスポートでのXMLBeanタイプのサポートは、プラグイン・モジュールに依存します。

XMLBeanプラグインの制限事項は次のとおりです。

1. プラグイン・モジュールを使用して、org.apache.xmlbeans.XmlObjectから拡張されたXMLBeanがサポートされています。

2. com.bea.xml.*から拡張されたXMLBeanオブジェクトはサポートされていません。

3. ユーザー定義Javaオブジェクトを含むXMLBeanの使用はサポートされていません。EJBにJavaオブジェクトとXmlbeansが入力引数または戻り型として含まれている場合、EJBトランスポートはランタイム・エラーを返します。

28.5.4.2 ユーザー定義のJavaデータ型およびJAX-WSについて

JAX-WSでは、EJBメソッドで入力引数またはメソッド戻り型として使用されるユーザー定義Javaオブジェクトには、パラメータをとらないデフォルトのコンストラクタが必要です。

これは、前のバージョンのService Busで(デフォルト・コンストラクタがない場合でも)機能していたユーザー定義Javaタイプを、デフォルト・コンストラクタに含めるよう変更する必要があることを意味します。詳細は、「ユーザー定義のJavaデータ型のプログラミング」を参照してください。

28.5.4.3 カスタム・コンバータ・クラス

Service Busは、EJB構造に正確に一致する中間Webサービスを生成します。すべてのEJBとそのデータ型をWebサービスのデータ型にマップできるとは限らないため、コンバータ・クラスを作成して中間Webサービスの形状を変更し、Service Bus側で必要なEJBタイプへのSOAPデータ型の内部変換を有効にすることができます。コンバータ・クラスは、Service BusパブリックAPIのcom.bea.wli.sb.transports.ejb.ITypeConverter Javaインタフェースで定義されるコントラクトを実装して準拠するJavaクラスです。

JAX-WS仕様では、EJBパラメータの特定の基準と、そのパラメータをWebサービス・レイヤーにラップするための戻り型が、データ型の特定の要件とともに必要になります。詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のJWSファイルのプログラミングに関する項を参照してください。コンバータ・クラスを使用すると、Webサービス・レイヤーを通じてデータ型を公開する方法でService Bus EJBラッパーをカスタマイズでき、このデータ型は、EJBで必要なデータ型に変化します。ラッパー実装は付属のEJBクライアント・クラスに基づくもので、EJBインタフェースに正確に一致する必要があります。この実装には、(WebLogic ServerのJWSツールセットを使用して作成された)Webサービス・レイヤー経由でアクセスできます。

28.5.4.4 EJBビジネス・サービスでのコンバータ・クラスの使用

EJBビジネス・サービスでコンバータ・クラスを使用するには:

1. インタフェースを実装およびコンパイルして、コンバータ・クラスを作成します。

2. コンバータ・クラスをクライアントJARファイルまたはコンバータ・クラスのJARファイルに追加します( 「クライアントJARまたはコンバータJARの追加」を参照)。

3. EJBビジネス・サービス用のメソッドを構成する場合、いずれかのパラメータまたは戻り値の型に移動し、目的のコンバータを選択します。

詳細は、「EJBトランスポート構成のリファレンス」を参照してください。ビジネス・サービスを構成すると、「トランスポートの詳細」ページに、特定のパラメータまたは戻り値の型に適用できる、使用可能なコンバータのリストが表示されます。

28.5.5 ビジネス例外クラス

EJBメソッドによってスローされるビジネス例外クラスは、フォルト要素のWSDLタイプ定義に例外クラスの詳細を適切にマップするため、JAX-WS 2.2仕様のセクション3.7に準拠している必要があります。例外クラスの対応するgetterメソッドを持つすべてのプライベートな非transientフィールドは、WSDLファイルの例外タイプ定義にマップされます。

詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のカスタム例外の作成および使用に関する項を参照してください。

28.6 EJBトランスポートのトラブルシューティング

この項では、EJBビジネス・サービスの設計または実行時の問題のトラブルシューティングについて説明します。また、「Oracle Service Busアプリケーションのデバッグ」の説明に従って、デバッグを有効化できます。

- WSDLの下位互換性

- tempディレクトリ

- デプロイ済アプリケーション

- EJBトランスポートのエラー

28.6.1 WSDLの下位互換性

前のバージョンのService Busでは、EJBトランスポートはベースとなるスタックとしてJAX-RPCを使用していました。このバージョンではJAX-WSを使用しているため、WSDLとの互換性の問題が発生することがあります。JAX-RPCおよびJAX-WSは2つの別の実装であり、相互に互換していません。

JAX-RPCおよびJAX-WSによって生成されたWSDLは、配列をメソッド入力/戻り型として使用する点が異なります。JAX-RPCは配列値の表現にラッパーを使用しますが、JAX-WSは使用しません。

JAX-RPCおよびJAX-WSによって生成されたWSDLは次のとおりです。

JAX-WS生成のWSDL

<xs:complexType name="ArrayOfJavaLangstring_literal">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="JavaLangstring" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:element name="ArrayOfJavaLangstring_literal" type="open:ArrayOfJavaLangstring_literal" xmlns:open="http://www.openuri.org/"/>
<xs:element name="returnNames">
<xs:complexType>
<xs:sequence>
<xs:element name="arg0" type="open:ArrayOfJavaLangstring_literal" xmlns:open="http://www.openuri.org/"/>
</xs:sequence>
</xs:complexType>
</xs:element>

JAX-WS生成のWSDL

<xsd:complexType name="returnNames">
<xsd:sequence>
<xsd:element form="qualified" maxOccurs="unbounded" name="arg0" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>

JAX-RPCのWebLogic Server実装では、繰り返される要素をラッパー内にラップします。

<foo>
<param1>
<JavaLangstring>arrayItemOfp1</JavaLangstring>
<JavaLangstring>arrayItemOfp1</JavaLangstring>
<JavaLangstring>arrayItemOfp1</JavaLangstring>
</param1>
</foo>

JAX-WSでは、配列にインライン反復要素を使用します。

<foo>
<param1>arrayItemOfp1</param1>
<param1>arrayItemOfp1</param1>
<param1>arrayItemOfp1</param1>
</foo>

ビジネス・メソッドString[] returnNames(String[] names)のあるステートレス・セッションBeanでは、JAX-RPC (前のバージョンのService Bus)およびJAX-WS (Service Bus 12.2.1)で生成されたWSDLによって次のリクエスト・ペイロードとレスポンス・ペイロードを想定しています。

JAX-RPCリクエスト

<soapenv:Envelope   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
</soap:Header>
<soapenv:Body>
<open:returnNames  xmlns:open="http://www.openuri.org/">
<open:arg0>
<open:JavaLangstring>John</open:JavaLangstring>
<open:JavaLangstring>Eric</open:JavaLangstring>
<open:JavaLangstring>Mark</open:JavaLangstring>
</open:arg0>
</open:returnNames>
</soapenv:Body>
</soapenv:Envelope>

JAX-RPCレスポンス

<env:Envelope  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<m:returnNamesResponse  xmlns:m="http://www.openuri.org/">
<m:return>
<m:JavaLangstring>John</m:JavaLangstring>
<m:JavaLangstring>Eric</m:JavaLangstring>
<m:JavaLangstring>Mark</m:JavaLangstring>
</m:return>
</m:returnNamesResponse>
</env:Body>
</env:Envelope>

JAX-WSリクエスト

<soapenv:Envelope  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
</soap:Header>
<soapenv:Body>
<open:returnNames  xmlns:open="http://www.openuri.org/">
<open:arg0>John</open:arg0>
<open:arg0>Eric</open:arg0>
<open:arg0>Mark</open:arg0>
</open:returnNames>
</soapenv:Body>
</soapenv:Envelope>

JAX-WSレスポンス

<S:Envelope  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header/>
<S:Body>
<ns0:returnNamesResponse  xmlns:ns0="http://www.openuri.org/">
<ns0:return>John</ns0:return>
<ns0:return>Eric</ns0:return>
<ns0:return>Mark</ns0:return>
</ns0:returnNamesResponse>
</S:Body>
</S:Envelope>

生成されたWSDLでの差異により、リクエスト・ペイロードに適用されるXPath関数は、動作が異なる場合があります。この差異に対応するよう、XPath関数を修正します。

28.6.2 tempディレクトリ

EJBトランスポートは設計時に、tempディレクトリのサブフォルダにファイルを生成します。それらのフォルダとファイルを削除すると安全です。また、アクティブ化の際の問題を判断するためにそれらを確認すると役に立つ場合があります。

28.6.3 デプロイ済アプリケーション

EJBビジネス・サービスが作成およびアクティブ化されると、Service Busサーバーにアプリケーションがデプロイされます。Oracle WebLogic Server管理コンソールとFusion Middleware Controlを使用して、このアプリケーションを監視およびチューニングできます。

28.6.4 EJBトランスポートのエラー

EJBビジネス・サービスに関する問題のトラブルシューティングが必要な場合に、次の情報が役立つことがあります。

- ビジネス・サービスの作成時に次のエラーが発生した場合、その原因はWindowsオペレーティング・システムの制限です。255文字を超える文字を含むパスはサポートされていません。

The system cannot find the path specified):Probably the string length of the path of the file being extracted was too long

Service Busドメインへの短いパスを作成することで、パスの長さを短くできます。また、サーバーの起動時に、次のオプションを使用してOracle WebLogic Serverのtempディレクトリをオーバーライドすることもできます。

-Dweblogic.j2ee.application.tmpDir=$desired_short_dir

- EJBビジネス・サービスの呼出し時にXMLマーシャリング・エラーを受け取り、リクエストがサービスのWSDLドキュメントに対し有効であるという確信がある場合は、コンバータ・クラスを記述することが必要になる可能性があります。詳細は、「カスタム・コンバータ・クラス」を参照してください。

- リモート・サーバーで、EJBインタフェースおよびスタブが変更された場合、新しいEJBの初回の呼出し時にエラーがスローされます。リモート・サーバーでのEJBインタフェースおよびスタブの変更はService Busに表示されないため、Service Busは、有効ではなくなった、キャッシュされているEJBを呼び出そうとします。ただし、呼出しエラーが発生すると、トランスポートはそれらのスタブが無効になったと見なし、それらをキャッシュから削除します。次回以降にEJBの呼出しを試行したときのエラーは、このような方法で回避されます。この初回時のエラーを回避するには、Oracle Service BusコンソールでJNDIプロバイダをリセットします。

28.7 EJBトランスポート構成のリファレンス

EJBビジネス・サービスはトランスポート型付きのサービスです。つまり、トランスポートのタイプはサービスの構成によって決まります。EJBビジネス・サービスのタイプは、SOAP XMLサービスに相当します。つまり、他のSOAP XMLビジネス・サービスと同様にEJBビジネス・サービスを使用できます。EJBトランスポート構成を保存すると、Service BusによってWSDLファイルが生成されます。生成されるWSDLファイルは、EJBのインタフェースに基づいています。EJBトランスポートの構成ページは、サービスのインタフェースと生成されるWSDLファイルを制御するための構成オプションを提供します。

28.7.1 EJBのエンドポイントURI形式

ビジネス・サービス内では、次のURIパターンを、EJBトランスポートのエンドポイントURIに使用します。

ejb:jndi_provider_name:ejb_jndi_name

ここで、jndi_provider_nameはService Bus JNDIプロバイダ・リソースの名前です。

EJBがローカルにデプロイされている場合、JNDIプロバイダの名前は不要です。この場合、次のURI形式を使用します。

ejb::ejb_jndi_name

Oracle WebLogic Server上のEJB 3.0ビジネス・サービスの場合、ejb_jndi_nameはmappedName#BusinessInterfaceという形式になります。

EJBがIBM WebSphere上で実行中の場合は、ejb_jndi_nameを次のいずれかの形式にしてください。

cell/nodes/node_name/servers/server_name/ejb_jndi_name

または

cell/clusters/cluster_name/ejb_jndi_name

詳細は、IBM WebSphereのドキュメントを参照してください。

28.7.2 EJBトランスポートを使用するビジネス・サービスの構成

次の表に、ビジネス・サービス用のEJBトランスポートの構成に使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

表28-1 ビジネス・サービス用のEJBトランスポート・プロパティ

プロパティ

説明

呼出し元のサブジェクトを渡す

EJBの呼出し時にサービス・アカウントが構成されていない場合、このチェック・ボックスを選択して、Service Busがプロキシ・サービスから認証されたサブジェクトを渡すようにします。これはサービス・アカウントの使用にかわる方法であり、このオプションを選択すると、「サービス・アカウント」フィールドが無効になります。

サービス・アカウント

サービスにアクセスするための認証に使用するサービス・アカウントを入力します。サービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。「呼出し元のサブジェクトを渡す」オプションを選択した場合、このオプションは使用できません。

詳細は、「サービス・アカウントの操作」を参照してください。

トランザクションをサポートする

EJBがトランザクションをサポートすることを指定する場合、このチェック・ボックスを選択します。

EJB 3.0

インタフェースがEJBバージョン3.0を使用する場合、このチェック・ボックスを選択します。

クライアントJar

「参照」をクリックし、使用可能なリソースのリストからEJBクライアントJARリソースを選択します。

コンバータJar

「参照」をクリックし、使用可能なオプションのリストからEJBコンバータ・クラスJARリソースを選択します。このフィールドは、前述のクライアントJARファイルを選択した後に表示されます。

詳細は、「クライアントJARまたはコンバータJARの追加」および「カスタム・コンバータ・クラス」を参照してください。

ホーム・インタフェース

JARファイルによって移入されたオプションから必要なEJBHomeインタフェースを選択します。このフィールドは、EJB 2.1でのみ使用可能です。

このURIサンプルのJNDI名はここで選択するEJBHomeインタフェースに関連付ける必要があります。EJBが必要なタイプのものではない場合またはEJBHomeインタフェースがクライアントJARファイルで指定されていない場合は、警告が表示されます。

リモート・インタフェース

リモート・インタフェースが表示され、ホーム・インタフェースの構成に基づいて、情報が自動的に移入されます。EJB 2.1でのみ使用可能です。

ビジネス・インタフェース

呼び出すクライアントJARでビジネス・インタフェースを選択します。このフィールドは、EJB 3.0でのみ使用可能です。

対象ネームスペース

JARファイルから選択された情報に基づいて決定されたネームスペースを表示します。このフィールドは、EJB 3.0を選択し、クライアントJARファイルを指定した場合のみ表示されます。

スタイル

要件に応じて、「ドキュメントをラップ」または「RPC」を選択します。ステートレス・セッションEJBの2つ以上のメソッドに、同じ数の同じデータ・タイプのパラメータがあり、操作をドキュメント指向にする場合はドキュメントのラップを指定します。

EJBへのルーティングまたはパブリッシュの場合、$bodyにはスタイルに合ったコンテンツが必要なので、スタイルは重要です。また、EJBへのコールアウトの場合、スタイルは、特にドキュメントのラップに関して、パラメータ・コンテンツに影響を及ぼします。2番目に、EJBビジネス・サービスを定義して、EJBにルーティングする同じWSDLファイルでプロキシ・サービスを作成する使用パターンもあります。この場合、プロキシを呼び出すクライアント・ツールにはスタイルの制限がある可能性があるため、WSDLのスタイルに注意してください。

RPCスタイルがJAX-WSでサポートされていますが、新しいEJBエンドポイントには「ドキュメントをラップ」することをお薦めします。既存のEJBビジネス・サービスでは、引き続きRPCスタイルを使用できます。

エンコーディング

SOAPメッセージのエンコーディングとして、「エンコード形式」または「リテラル形式」を指定します。

メソッド

選択したEJBリモートまたはビジネス・インタフェースのメソッドを構成します。必要なメソッドを選択します(複数のメソッドの選択も可能)。構成するメソッドを展開した後、デフォルトのパラメータ値を編集して、提供されている場合(または必要な場合)はコンバータを選択します。

各メソッドのデフォルトの操作名を変更できます。デフォルトでは、操作名はメソッド名です。EJBに同じ名前のメソッドが含まれている場合、一意になるように操作名を変更する必要があります。WSDLファイルは一意の操作名を必要とします。

追加または除外するメソッドを選択できます。JAX-WSスタックでサポートされないパラメータまたは戻り値の型を持つメソッドを除外するか、それらの引数をコンバータ・クラスに関連付ける必要があります。

注意: EJBのメソッド間で資格証明またはトランザクション設定が異なる場合、特定のビジネス・サービスのメソッドをカスタマイズして、メソッドごとのビジネス・サービスを作成できます。これにより、トランザクションと資格証明の詳細な制御が可能になります。

例外

メソッドによってスローされるすべてのビジネス例外を表示します。EJBメソッドが、ArrayListなどのJava Web Services (JWS)でサポートされないデータ型を持つ例外をスローした場合は、「例外」フィールドを使用して、例外をJWSでサポートされる型に変換するコンバータ・クラスを選択します。

コンバータ・クラスは、com.bea.wli.sb.transports.ejb.ITypeConverterを実装する必要があります。コンバータ・クラスは、実行時例外ではなくチェック済の例外用にのみ構成できます。コンバータ・クラスおよび変換された例外クラスをクライアントまたはコンバータJARファイルでパッケージ化します。

29 HTTPトランスポートおよびポーラー・トランスポートの使用

この章では、HTTP(S)トランスポートおよびポーラー・トランスポート(電子メール、ファイル、FTPおよびSFTP)の概要と、サービスでの使用および構成方法について説明します。

HTTPトランスポートの項では、Service BusでのRESTの使用についても説明しますが、「Oracle Service BusでのRESTサービスの作成」の説明に従い、RESTバインディングも使用できます。

このドキュメントは、次の項で構成されています。

- HTTPトランスポートの使用

- 電子メール・トランスポートの使用

- ファイル・トランスポートの使用

- FTPトランスポートの使用

- SFTPトランスポートの使用

29.1 ポーラー・トランスポートの概要

様々なタイプのトランスポートを使用して、Service Busのプロキシ・サービスまたはビジネス・サービスを構成できます。選択する転送プロトコルは、サービス・タイプ、必要な認証のタイプ、呼出し元のサービスのサービス・タイプなどによって異なります。ポーリングベースのトランスポートでは、管理対象サーバーにトランスポート・ポーラーが固定されています。このようなトランスポートは、ソース・ディレクトリまたは電子メール・サーバーで新しいメッセージをポーリングします。メッセージが1回以上処理されるように、JMSフレームワークが使用されます。電子メール、ファイル、FTPおよびSFTPは、ポーリングベースのトランスポートです。

デフォルトでは、ポーラー・トランスポートはWebLogic Server JMSを使用しますが、クラスタ化されたドメインは、ドメインの作成または拡張時にOracle Advanced Queueing (AQ) JMSを使用するように構成できます。リポジトリ作成ユーティリティ(RCU)を実行すると、必要なすべてのService Busキューおよびキュー表が作成されます。「到着順にソート」機能は、AQ JMSでのポーリングベースのトランスポートではサポートされていません。

Oracle AQを使用する環境の構成については、『Oracle Service Busの管理』のOracle Advanced Queueing JMSの使用に関する項を参照してください。

29.2 HTTPトランスポートの使用

HTTPトランスポートは、Service BusでHTTP(S)プロトコルを使用してクライアントとサービス・プロバイダ間でメッセージの送信を行います。また、「RESTサポート」で説明されているように、HTTPトランスポートはRepresentational State Transfer (REST)環境での作業のサポートも提供します。

29.2.1 HTTPセッションの固定

Service Busでは、ロード・バランシングにおいてビジネス・サービスにHTTPセッションの固定またはセッション・アフィニティがサポートされるため、特定のセッションに対するすべてのリクエストが1つのサーバーによって処理されます。固定は、サービスURI表の特定のエントリにセッションをマップすることで保持されます。スティッキー・セッションでは、最初のリクエストを処理するURIエントリがセッションを持ち、セッションの後続のメッセージがロード・バランサで受信された際は、最初のリクエストを処理したサービスURIエントリと同じエントリでルーティングされます。

標準的なロード・バランシング環境では、Service Busによって複数のサーバー間で負荷を分散できるため、セッション内の複数のメッセージをクラスタ内の同じサーバーで処理する必要がある場合は、セッションを固定するためにビジネス・サービスを構成する必要があります。

注意:

Oracle Service Busコンソールでは、サービスの再起動を必要とせずに、実行時にスティッキー・セッションを構成できます。

Service Busでは、スティッキー・セッションに対する次のシナリオはサポートされていません。

- 1つのメッセージ・フローにおける、セッションが固定された複数のビジネス・サービス。

- 同じパイプラインにおける、セッションが固定された複数のビジネス・サービス。

- セッションが固定されたビジネス・サービスを示す分割-結合サービス。

- セッションが固定された様々なビジネス・サービスへの動的ルーティング。

また、セッションを固定するように構成されたビジネス・サービスに対しては抑制が機能しないことにも注意してください。

29.2.2 プロキシ・サービスでのHTTP認可ヘッダーの取得

Service Busは、セキュリティの脆弱性が生じるため、リクエストからパイプラインにHTTP認可ヘッダーを渡しません。ユーザー名と暗号化されていないパスワードをログ・ファイルに書き込むログ・アクションを誤って作成するおそれがあります。

パイプラインでHTTP認可ヘッダーが必要なパターンを設計する場合は、次の手順を実行してください。

1. Service Bus用の起動コマンドで、次のシステム・プロパティをtrueに設定します。

com.bea.wli.sb.transports.http.GetHttpAuthorizationHeaderAllowed

2. JDeveloperまたはOracle Service Busコンソールのサービスの定義エディタの「トランスポート」ページで、「すべてのヘッダーを取得」を選択するか、ユーザー指定のヘッダーを選択して「認可」を指定します。

3. Service Busを再起動します。

29.2.3 圧縮済HTTPリクエストおよびレスポンスのペイロードのサポート

HTTPトランスポートは現在、圧縮済HTTPリクエストおよびレスポンスのペイロードで使用するgzipおよびdeflate圧縮をサポートしています。圧縮はインバウンドおよびアウトバウンドのペイロードでサポートされています。

29.2.3.1 Accept-Encoding

クライアントは、Accept-Encodingヘッダー内にサポートするエンコーディングを指定します。このヘッダーには、複数のエンコーディング・タイプをカンマ区切りリストとして含めることができます。Service Busでは、RFC 2616に従い、アルゴリズムと優先度を示すAccept-Encoding文字列を指定する受入れ可能なエンコーディングがあるかどうかをチェックします。

サポートされているアルゴリズムがない場合、Service Busはペイロードを操作しないことを示すidentityを想定します。

Accept-Encodingヘッダーを解析できない場合(たとえば、形式が無効なため技術的なエラーが発生するなど)、HTTP 406 – NOT ACCEPTABLEエラーが返され、リクエストは拒否されます。

q=0の優先度値は、特定のアルゴリズムではオフになります。これはすべてのアルゴリズムに適用されますが、その他の値が受け入れられない場合は、Service Busが常にデフォルトに設定されるidentityを除きます。

gzipおよびdeflateの圧縮アルゴリズムが両方Accept-Encodingヘッダーにあり、優先度が同じ場合、gzip圧縮が優先されます。

次の表に、Accept-Encodingsの有効な組合せと、それぞれの組合せにService Busが使用するエンコーディングを示します。

表29-1 Accept-Encoding処理

Accept-Encodingヘッダー値

Service Busエンコーディング・デシジョン

gzip;q=1.0, deflate;q=0.5

Gzip

x-gzip,gzip;q=0.25,deflate;q=1.0

Deflate

Gzip

Gzip

gzip;q=0.0,deflate

Deflate

Deflate

Deflate

deflate;q=1.0

Deflate

gzip,deflate

Gzip

x-gzip

Identity

*

Gzip

gzip;q=0.0,deflate,*;q=1.0

Deflate

gzip;q=0.0,*

Deflate

gzip;q=0.0,deflate;q=0.0,*

Identity

deflate;q=0.25,*;q=1.0

gzip

アウトバウンド・リクエストでは、ビジネス・サービスで圧縮サポートがオンの場合、Service Busは常にgzip,deflateのAccept-Encodingヘッダーを送信します。

29.2.3.2 Content-Encoding

Content-Encodingは、ペイロードがどのように操作されているかを受信者に示します

単一メッセージ・ペイロードへの複数の圧縮のネストはサポートされていません。Content-Encodingには、gzipまたはdeflateが含まれる場合があります。

インバウンド・リクエストまたはアウトバウンド・レスポンスでは、Service Busは、パイプラインにペイロードを移動する前にこのヘッダーを解析し、正しい解凍アルゴリズムを適用します。Service Busがインバウンド・レスポンスとアウトバウンド・リクエストを圧縮して送信すると構成されている場合、Content-Encodingは、適用される圧縮アルゴリズムに設定されます。

29.2.3.3 Content-Length

Content-Lengthは、チャンク済HTTP転送を解釈しないHTTP 1.0クライアントに特に必要です。

(オプション) このセクションに参照情報を入力します。

仕様に従い、Content-Lengthヘッダーは、データがストリームにコミットされる前に設定する必要があります。データが指定のContent-Lengthを超えている場合は、レスポンスがクライアントにコミットされ、メッセージが破損します。その結果、データがストリームに書き込まれる前に、Content-Lengthの通知が必要になります。このため、圧縮データの最終的な長さを判断するには、圧縮中に完全なメッセージをバッファする必要があります。

プロキシおよびビジネス・サービスの構成には、インバウンド・レスポンスとアウトバウンド・リクエストのバッファをオンにするオプションがあります。バッファ・モードでは、メッセージはContent-Lengthヘッダーとともに送信されます。これはデフォルト・オプションではなく、HTTP 1.0受信者のみに対するサポートです。

29.2.3.4 Transfer-Encoding

Transfer-Encodingヘッダーは、特定のメッセージで実行された操作の種類を(適用された順序で)示します。これは安全なメッセージ転送を保証するためのネットワーク・コンポーネントの追加情報です。

これは安全なメッセージ転送を保証するためのネットワーク・コンポーネントの追加情報です。HTTP 1.0実装はこのヘッダーを解釈できない場合があります。gzipまたはdeflate設定は、圧縮を実行する前にヘッダーがすでに存在する場合のみ追加する必要があり、インバウンド・レスポンスおよびアウトバウンド・リクエストにのみ適用されます。

注意:

chunkedはメッセージに適用する最後のエンコーディングです。

Transfer-Encodingヘッダーは現在、アウトバウンド・リクエストでは省略されています。

29.2.3.5 ETag

ETagヘッダーはコンテンツ・キャッシュ/プロキシへのペイロードの操作を示します。

キャッシュまたはプロキシには、圧縮ペイロードを想定できますが、呼出し元クライアントには想定しません。Service Busは、インバウンド・レスポンスにこのヘッダーが正しく保持されていることを確認します。アウトバウンド・リクエストには操作されません。Service Busでは、このヘッダーを中間パーティとしては必要としません。

29.2.3.6 サンプル・リクエストおよびレスポンス

次のインバウンドおよびアウトバウンドのリクエストおよびレスポンスのサンプルを参照してください。

例29-1 サンプル・インバウンド・リクエスト

GET /mySampleApp/myProxy HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip, deflate[, compress, exi, bzip2, …]

例29-2 サンプル・インバウンド・レスポンス

HTTP/1.1 200 OK
Date: Mon, 23 Sep 2013 13:14:34 GMT
Server: WLS 10.3.6 (Unix)  (Red-Hat/Linux)
Content-Length: 438
Content-Type: text/xml; charset=UTF-8
Content-Encoding: gzip
Transfer-Encoding: [if present already, append gzip or deflate, otherwise omit – ALWAYS append chunked as last value]
[gzip payload]

例 29-3 サンプル・アウトバウンド・リクエスト

POST /myExternalWebApp/some.html HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip
Content-Encoding: gzip
Transfer-Encoding: [if present already, append gzip, otherwise omit. ALWAYS append chunked as last value]
[gzip payload]

例29-4 サンプル・アウトバウンド・レスポンス

HTTP/1.1 200 OK
Date: mon, 15 Sep 2013 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix)  (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip

29.2.4 HTTPトランスポートWS-RMのサポート

Service Bus 12.2.1では、WSDLタイプのHTTPトランスポート・サービスにWeb Services Reliable Messaging (WS-Reliable MessagingまたはWS-RM)をサポートしています。

OWSMポリシーoracle/reliable_messaging_policyおよびoracle/reliable_messaging_internal_api_policyをアタッチし、プロキシ・サービスまたはビジネス・サービスへのWS-RMを有効にします。詳細は、「OWSMポリシーを使用したWS-ReliableMessagingのサポート」を参照してください。

29.2.5 HTTPトランスポート構成のリファレンス

この項では、エンドポイントURIの形式およびプロキシ・サービスとビジネス・サービスにおけるHTTPトランスポートの構成について説明します。

- HTTPトランスポートのエンドポイントURI

- HTTPトランスポートを使用するプロキシ・サービスの構成

- HTTPトランスポートを使用するビジネス・サービスの構成

29.2.5.1 HTTPトランスポートのエンドポイントURI

任意のタイプのプロキシ・サービスまたはビジネス・サービスを構成する場合は、HTTP転送プロトコルを選択できます。エンドポイントURIの形式は次のとおりです。

- プロキシ・サービス: /service_name

- ビジネス・サービス: http://host:port/service_name

説明:

- hostは、サービスをホストするシステムの名前です。

- portは、接続を行うポート番号です。

- service_nameはターゲット・サービス名です。

注意:

HTTPSに基づくビジネス・サービスを構成するときは、次のエンドポイントURIを指定する必要があります。

https://host:port/someService

29.2.5.2 HTTPトランスポートを使用するプロキシ・サービスの構成

次の表に、プロキシ・サービス用のHTTPトランスポートの構成に使用するプロパティを示します。詳細は、「プロキシ・サービスの作成と構成」を参照してください。

表29-2 プロキシ・サービス用のHTTPトランスポート・プロパティ

プロパティ

説明

HTTPSが必要

インバウンドHTTPSエンドポイントの場合は、このチェック・ボックスを選択します。HTTPSプロトコルは、通信を保護するためにSSLを使用します。SSLを使用して通信を暗号化し、メッセージの整合性を保証するとともに、強力なサーバーおよびクライアントの認証を要求できます。

詳細は、「HTTPSのトランスポート・レベルでのセキュリティの構成」を参照してください。

認証

認証方式として、次のいずれかを選択します。

- なし: 認証を必要としないことを指定します。プロキシ・サービスにOWSMポリシーを指定する場合は、このオプションを選択してください。

- 基本: このサービスにアクセスするには、基本認証が必要であることを指定します。基本認証では、Oracle WebLogic Serverでユーザー名とパスワードを使用し、セキュリティ・レルム(Lightweight Directory Access Protocol (LDAP)ディレクトリ・サービスやWindows Active Directoryなど)で構成された認証プロバイダに対してクライアントの認証が行われます。クライアントは、HTTPリクエスト・ヘッダーでユーザー名とパスワードを送信する必要があります。HTTPでの基本認証は、パスワードがクリア・テキストで送信されるため推奨しません。HTTPSでは暗号化されたチャネルが提供されるため、パスワードはHTTPSで送信するのが安全です。
警告:デフォルトでは、すべてのユーザー(認可ユーザーおよび匿名ユーザー)がプロキシ・サービスにアクセス可能です。プロキシ・サービスにアクセスできるユーザーを制限するには、トランスポートレベルの認可ポリシーを作成する必要があります。「トランスポート・レベルのセキュリティの構成」を参照してください。

- クライアント証明書: 暗号化通信および強力なクライアント認証(双方向SSL)を指定します。詳細は、「HTTPSのトランスポート・レベルでのセキュリティの構成」を参照してください。

- カスタム認証: 認証トークンがHTTPヘッダーに含まれていることを指定します。クライアントのIDは、ここでクライアントが指定したトークンを使用して設定されます。トークンをService BusユーザーにマップするIDアサーション・プロバイダを構成する必要があります。
カスタム認証トークンには、構成されたWebLogic Server IDアサーション・プロバイダがサポートする任意のアクティブなトークン・タイプを指定できます。

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

リクエストのエンコーディング

リクエスト・メッセージに使用する文字セットのエンコーディングを指定します。

- HTTPインバウンド・トランスポートの場合: クライアント・リクエストでContent-Typeヘッダーの文字セット・エンコーディング・パラメータが指定されていないときは、文字セット・エンコーディング・パラメータを入力します。値を入力しない場合は、このフィールドにデフォルトのISO-8859-1が設定されます。

- HTTPアウトバウンド・トランスポートの場合: リクエスト・エンコーディングを構成していない場合、Service Busランタイムによって、ビジネス・サービスにリクエストを行う際に最適なエンコーディングが決定されます。パススルー以外のシナリオでは、実行時のデフォルトの文字エンコーディングはUTF-8となります。ただし、パススルーのシナリオでは、ランタイムはアウトバウンド・レスポンスで受信したエンコーディングのパススルーを行います。

レスポンスのエンコーディング

レスポンス・メッセージに使用する文字セットのエンコーディングを指定します。

圧縮のサポート

圧縮のサポートを有効にする場合は、このオプションを選択します。リクエスト・ペイロードは、gzipまたはdeflateを含むContent-Encodingヘッダーが存在する場合、解凍されます。ネストした圧縮はサポートされていません。プロキシは圧縮サポートに構成されても、非圧縮リクエストを理解し、非圧縮レスポンスを送信することもできます。

このオプションを選択しない場合、クライアントが圧縮データを送信しても、プロキシ・サービスがデータを理解できないため、リクエストは拒絶されます。クライアントがgzipまたはdeflateを含むAccept-Encodingヘッダーを送信すると、無視されます。レスポンスは、圧縮されずに送信されます。

圧縮バッファの有効化

圧縮のバッファを有効にする場合は、このオプションを選択します。有効化された場合、メッセージ全体が圧縮形式でインメモリー・バッファに書き込まれ、圧縮データのContent-Lengthを決定します。Content-Lengthヘッダーは、データがクライアントに送信される前にレスポンス・オブジェクトに設定されます。この設定は、リクエスト処理に影響しません。これはインバウンド・レスポンス・データ処理のみに適用されます。インバウンド・リクエストは常に直接ストリーミングされます。

認証ヘッダー

Service Busがトークンを抽出するHTTPヘッダー(Authorization以外の任意のヘッダー)を入力します。このフィールドが使用可能になるのは、「カスタム認証」チェック・ボックスが選択されている場合に限られます。

たとえば、client-xyz-tokenです。

認証トークン・タイプ

認証トークン・タイプを選択します。IDアサーション・プロバイダ用に構成されたアクティブなトークン・タイプのみが使用可能になりますこのフィールドが使用可能になるのは、「カスタム認証」チェック・ボックスが選択されている場合に限られます。

29.2.5.3 HTTPトランスポートを使用するビジネス・サービスの構成

次の表に、ビジネス・サービス用のHTTPトランスポートの構成に使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

表29-3 ビジネス・サービス用のHTTPトランスポート・プロパティ

プロパティ

説明

読取りタイムアウト

読取りタイムアウトまでの間隔を秒単位で入力します。接続において、データが使用可能になる前にタイムアウトになると、接続エラーが生成されます。

値0ではタイムアウトが行われません。

接続タイムアウト

接続タイムアウトまでの間隔を秒単位で入力します。接続が確立する前にタイムアウトになると、Service Busによって接続エラーが生成されます。

値0ではタイムアウトが行われません。

HTTPリクエスト・メソッド

リクエスト内で使用するHTTPメソッドとして、次のいずれかを選択します。

- POST: HTTPリクエストの本文の一部として、長さにかかわらずすべてのデータをソケット接続で直接渡す場合に使用します。このやりとりはクライアントから認識できず、URLも変わりません。RESTベースのリクエストの場合、POSTでは作成/置換操作を実行するか、またはリクエストの操作を実行するようにトランスポートに指示します。

- GET: リクエストの一部として、取得対象を詳しく表した独自の情報を組み込む場合に使用します。この情報は、問合せ文字列内のリクエストURLに追加された文字のシーケンスとして渡されます。「リクエスト・メッセージ・タイプ」が「なし」に設定されている場合は、XMLサービス・タイプまたはメッセージ・サービス・タイプのビジネス・サービスでGETを使用できます。RESTベースのリクエストの場合、GETはリモート・リソースの表現を受け取ります。

- PUT: RESTベースのリクエストによる作成と置換の操作(既知の場所へのファイルのアップロードなど)を実行するようトランスポートに通知する場合に使用します。PUTはXMLまたはメッセージ・サービス・タイプのビジネス・サービスで使用できます。

- HEAD: RESTベースのリクエストでリモート・リソースの完全な表現を取得するのではなく、そのリソースのヘッダー情報を取得するようトランスポートに通知する場合に使用します。「リクエスト・メッセージ・タイプ」が「なし」に設定されている場合は、XMLサービス・タイプまたはメッセージ・サービス・タイプのビジネス・サービスでHEADを使用できます。

- DELETE: RESTベースのリクエストによる削除操作を実行するようトランスポートに通知する場合に使用します。DELETEはXMLまたはメッセージ・サービス・タイプのビジネス・サービスで使用できます。

注意: $outbound/transport/request/http:http-method変数でメソッドがすでに設定されている場合は、HTTPリクエスト・メソッドに選択したどのメソッドよりもその値が優先されます。

認証

HTTP認証のタイプとして、次のいずれかを選択します。

- なし: このサービスへのアクセスに認証を必要としません。

- 基本: このサービスへのアクセスに基本認証を必要とします。基本認証では、WebLogic Serverでユーザー名とパスワードを使用し、セキュリティ・レルム(Lightweight Directory Access Protocol (LDAP)ディレクトリ・サービスやWindows Active Directoryなど)で構成された認証プロバイダに対してクライアントの認証が行われます。クライアントは、HTTPリクエスト・ヘッダーでユーザー名とパスワードを送信する必要があります。
HTTPでの基本認証は、パスワードがクリア・テキストで送信されるため推奨しません。HTTPSでは暗号化されたチャネルが提供されるため、パスワードはHTTPSで送信するのが安全です。

警告: デフォルトでは、すべてのユーザー(認可ユーザーおよび匿名ユーザー)がビジネス・サービスにアクセス可能です。ビジネス・サービスにアクセスできるユーザーを制限するには、トランスポートレベルの認可ポリシーを作成する必要があります。「トランスポート・レベルのセキュリティの構成」を参照してください。

- クライアント証明書: 暗号化通信および強力なクライアント認証(双方向SSL)を指定します。詳細は、「HTTPSのトランスポート・レベルでのセキュリティの構成」を参照してください。

- カスタム認証: カスタムJavaクラスによって認証が定義されることを指定します。詳細設定の「HTTPカスタム認証クラス名」フィールド(次で説明)で、認証クラスを指定する必要があります。

サービス・アカウント

サービスにアクセスするための認証に使用するサービス・アカウントを入力します。基本認証を選択した場合、このフィールドは必須です。カスタム認証を選択した場合は省略可能です。

詳細は、「サービス・アカウントの操作」を参照してください。

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

リクエストのエンコーディング

電子メール・トランスポートにおけるリクエストの文字セット・エンコーディングとして、デフォルトのiso-8859-1を受け入れるか、別の文字セット・エンコーディングを入力します。

レスポンスのエンコーディング

HTTPトランスポートにおけるレスポンスの文字セット・エンコーディングとして、デフォルトのiso-8859-1を受け入れるか、別の文字セット・エンコーディングを入力します。

圧縮のサポート

圧縮のサポートを有効にする場合は、このオプションを選択します。有効化された場合、アウトバウンド・リクエストの圧縮アルゴリズムの「圧縮アルゴリズム・リクエスト」設定を選択できます。gzipまたはdeflate圧縮のいずれかのアウトバウンド・レスポンスは、アウトバウンド・レスポンスのContent-Encodingヘッダーに応じて自動的にサポートされます。

このオプションが選択されていない場合、非圧縮ペイロードが送信されます。ヘッダーは追加されません。圧縮されたアウトバウンド・レスポンスを受信すると、エラーが発生します。

リクエスト・アルゴリズム圧縮

「圧縮のサポート」が選択されている場合、アウトバウンド・リクエストの圧縮を処理するオプションが3つ使用できます。

- なし: アウトバウンド・リクエストを圧縮しません。ただし、圧縮されたアウトバウンド・レスポンスを理解できます。

- Gzip: gzipでアウトバウンド・ペイロードを圧縮します。

- Deflate: deflateでアウトバウンド・ペイロードを圧縮します。

Accept-Encodingヘッダーは"gzip, deflate"に送信されます。Content-Encoding ヘッダーを含む、これらの2つの圧縮アルゴリズムのアウトバウンド・レスポンスが解釈されます。

圧縮バッファの有効化

圧縮のバッファを有効にする場合は、このオプションを選択します。有効化された場合、メッセージ全体が圧縮形式でインメモリー・バッファに書き込まれ、圧縮データのContent-Lengthを決定します。Content-Lengthヘッダーは、レシピエントへのデータの送信に先立ちレスポンス・オブジェクト上に設定されます。

この設定は、リクエスト処理に影響しません。これはインバウンド・レスポンス・データ処理のみに適用されます。インバウンド・リクエストは常に直接ストリーミングされます。

このオプションは、次のいずれかの条件がtrueの場合、無効化されます。

- 「圧縮のサポート」設定が選択されていない場合。

- 「圧縮のサポート」設定が選択され、「圧縮アルゴリズム・リクエスト」リストで、「なし」が選択されている場合。

注意: この設定は、「チャンク・ストリーミング・モードの使用」設定と互換性がありません。いずれか1つのみが選択できます。

HTTPカスタム認証クラス名

カスタム認証に使用するJavaクラスの名前を入力します。このフィールドが使用可能になるのは、認証タイプとして「カスタム認証」を選択した場合のみです。カスタム認証クラスの作成の詳細は、「アウトバウンド用のカスタム認証クラスの作成方法」を参照してください。

プロキシ・サーバー

プロキシ・サーバー・リソースを入力するか、「参照」をクリックして構成されたプロキシ・サーバー・リソースの一覧からエントリを選択します。

HTTPリダイレクトの追跡

HTTPリダイレクト(レスポンス・コード3xxによるリクエスト)を自動的に追跡することを指定します。リダイレクトは、ビジネス・サービスのURLにアウトバウンド・リクエストを送信し、そのサービスから、URLが無効になったためこのリクエストを別のURLに送信する必要があることを示すレスポンス・コード(たとえば302)が返された場合に発生します。「HTTPリダイレクトの追跡」チェック・ボックスが選択されている場合、リクエストは自動的に新しいURLに再送信され、ユーザー側でのアクションは発生しません。HTTPリダイレクトを自動的に追跡しない場合は、このチェック・ボックスのチェックを外します。

チャンク・ストリーミング・モードの使用

HTTPチャンク転送エンコーディングを使用してメッセージを送信する場合は、このオプションを選択します。

注意: 「HTTPリダイレクトの追跡」オプションを使用する場合は、チャンク・ストリーミングを使用しないでください。リダイレクトと認証をチャンク・モードで自動的に処理することはできません。

セッション固定性

ビジネス・サービス用のHTTPリクエストにセッションの固定(セッション・アフィニティとも呼ばれる)を使用する場合は、このオプションを選択します。詳細は、「HTTPセッションの固定」を参照してください。

固定セッションID名

「セッション固定性」を有効にした場合、セッションを識別するための一意の名前を入力します。

29.2.6 RESTサポート

HTTPトランスポートは、非RESTサービス・プロバイダと対話する必要があるRESTクライアント、RESTベースのサービス・プロバイダと対話する必要がある非RESTクライアント、またはService Busを介して公開する必要があるREST-to-RESTサービスのいずれの場合にも、Service Busを介したREST環境での作業をサポートします。

RESTのパターンでは、特定のURLにあるリソースに対してHTTPメソッド(GET、PUT、HEAD、POST、DELETEなど)を呼び出します。たとえば、RESTを使用したWebアプリケーションでユーザーが各自のプロファイル情報を更新した場合、POSTアクションによって、サービスのREST APIを介してデータベースのユーザー情報が更新されます。

「Oracle Service BusでのRESTサービスの作成」で説明しているように、Service BusはRESTバインディングを組み込みつつ、Service Busでは、HTTPトランスポートを使用してインバウンドおよびアウトバウンド通信のRESTベースのリクエストを処理するために、次のプレースホルダ変数も提供します。

- $inboundまたは$outbound/transport/request/http:http-method: GET、PUT、HEAD、POST、DELETEのようなHTTPメソッドを処理します。

- $inboundまたは$outbound/transport/request/http:parameters: URLの問合せ文字列を処理します。parametersメタデータには、名前/値のペアを格納する1つ以上のparameter要素が含まれます。名前/値のペアは、問合せ文字列のURLDecoded値です。たとえば、http://localhost:7021/myproxy/weather?operation=temperature&pincode=94065というURLで、問合せ文字列は次の問合せパラメータとして格納されます。

<http:query-parameters>
<http:parameter name="operation" value="temperature"/>
<http:parameter name="pincode" value="94065"/>
</http:query-parameters>

- $inboundまたは$outbound/transport/request/http:relative-URI: RESTリソースのURLの相対的な部分(プロキシ・サービスのURIに対して相対的)を処理します。たとえば、http://localhost:7021/myproxy/weatherというURLで、/weatherはhttp://localhost:7021/myproxyに対して相対的なURLです。

29.2.6.1 プロキシ・サービスのREST

プロキシ・サービスには、RESTベースのリクエストを受信するか、RESTベースのアクションを生成するかにかかわらず、RESTパターンを操作できる柔軟性があります。

たとえば、RESTベースのアプリケーションを開発し、非RESTサービス・プロバイダでサービスを呼び出す場合は、プロキシ・サービスでREST操作を送り、その操作をサービス・プロバイダが認識できる形式に変換するか、非RESTリクエストをリソースURLに変換し、RESTベースのサービス・プロバイダで操作を呼び出すことができます。また、REST-to-REST実装の監視、監査およびレポートのために仲介者としてService Busを使用することもできます。

Service BusでRESTを使用する作業例は、Oracle Service Busサンプルのリポジトリ(http://www.oracle.com/technetwork/middleware/service-bus/learnmore/index.html)を参照してください。

29.2.6.1.1 XQueryサンプル

次に、プロキシ・サービスでHTTP変数を使用して行うURI解析のXQueryの例を示します。URI解析では、REST環境と非REST環境間でメッセージを変換できます。

相対URI

プロキシ・サービスのURIがhttp://localhost:7001/weatherであり、リクエストの相対URIの部分をキャプチャするとします。次のXQueryを作成します。

<relative-URI>
{
for $c in
fn:tokenize($inbound/ctx:transport/ctx:request/http:relative-URI, "/")
where fn:string-length($c) != 0
return
<part>
{$c}
</part>
}
</relative-URI>

リクエストのURIがhttp://localhost:7001/weather/temperature/35457の場合、相対URIは/temperature/35457になり、XQuery出力は次のようになります。

<relative-URI>
<part>temperature</part>
<part>35457</part>
</relative-URI>

問合せ文字列パラメータ

プロキシ・サービスのURIがhttp://localhost:7001/weatherであり、URL問合せ文字列パラメータをキャプチャするとします。次のXQueryを作成します。

<query-parameters>
{
return
<param name="$inbound/ctx:transport/ctx:request/http:parameters/param/name"
value="$inbound/ctx:transport/ctx:request/http:parameters/param/value"></param>
}
</query-parameters>

リクエストのURIがhttp://server:7001/weather?operation=temperature&pincode=35457の場合、問合せ文字列はoperation=temperature&pincode=35457になり、http:parametersメタデータの個別パラメータとして格納されます。XQuery出力は次のようになります。

<query-parameters>
<param name='operation' value='temperature'/>
<param name='pincode' value='35457'/>
</query-parameters>

29.2.6.1.2 ヘッダー

サービスによりHTTP/RESTメソッドを処理するために固有のヘッダーが必要な場合、パイプラインにユーザー定義済HTTPヘッダー変数を作成します。

29.2.6.2 ビジネス・サービスのREST

ビジネス・サービスでは、RESTベースのサービスを呼び出すことができます。REST操作で、HTTPトランスポートは$outbound/transport/request/http:http-method変数の値を使用します。この変数にHTTPメソッドが指定されていない場合、HTTPトランスポートではトランスポート構成に含まれるHTTPリクエスト・メソッド(POST、PUT、HEAD、GET、DELETE)のいずれかを選択できます。

注意:

ビジネス・サービスがWSDLサービス・タイプを使用している場合は、POSTメソッドのみが選択可能です。

$outbound/transport/request-http/http-method変数を使用して、独自のメソッドを指定することもできます。たとえば、WebDAV (Web-based Distributed Authoring and Versioning)環境でCOPY、MOVE、およびLOCKを使用できます。

次のガイドラインを使用して$outbound変数を設定します。

- トランスポートは、カスタム・メソッドに対して、またはこの項で説明する制約に従っていない手動で設定されたサポート対象メソッドに対して、実行時の検証を提供しません。

- $outboundはルーティング・ノードでのみ有効なため、パブリッシュおよびサービス・コールアウト・アクションのメソッド名を実行時に指定することはできません。

- $outbound問合せ文字列パラメータが設定されている場合、ビジネス・サービスは、RAWバイトからの問合せ文字列の構築にアウトバウンド・リクエスト・エンコーディングを、またparametersメタデータ要素から取得されたパラメータの名前/値のペアにURLエンコーディングを使用します。

- $outbound相対URIが設定されている場合、ビジネス・サービスはその値を使用して、ビジネス・サービスURIに対して相対的なURIを生成します。
たとえば、ビジネス・サービスが次のURIを使用し、

http://service.com/purchaseOrder

使用するHTTP変数は次のとおりです。

$outbound/transport/request-http/relative-URI: "/PO12367" and
$outbound/transport/request-http/parameters/parameter: "item=NO1"
$outbound/transport/request-http/parameters/parameter: "color=black"

最終的に解決されたURIは次のようになります。

http://service.com/purchaseOrder/PO12367?item=NO1&color=black

29.2.7 HTTPビジネス・サービスのレスポンス・コードおよびエラー処理

Service Busは、200から500までの範囲のすべてのレスポンス・コードを処理するために、HTTP 1.1仕様に準拠しています。表29-4に、Service Busが様々なレスポンス・コード・レベルを処理する方法を示します。

HTTPビジネス・サービスは、300以上のエラーを含むレスポンス・ペイロードを受信するため、次のタイプである必要があります。

- WSDL

- 任意のSOAP

- 次の条件を満たすメッセージング

- レスポンス・メッセージ・タイプは、「MFL」または「XML」である(タイプがXMLまたはSOAPであると判断される)必要があります。Service BusがXMLまたはSOAP以外であると判断したレスポンス・タイプを持つHTTPビジネス・サービスでは、HTTPレスポンス・ペイロードが受信されません。

- レスポンス・ペイロードのHTTPヘッダーContent-Typeは、text/xml、application/any_string+xmlまたはmultipart/relatedです。

表29-4 HTTPビジネス・サービスのレスポンス・コード処理

レスポンス・ステータス・コード

説明

100s

100レベルのステータス・コードは、Status-Lineとオプション・ヘッダーのみで構成され、空の行で終わる暫定レスポンスを示します。100レベルのコードのレスポンス動作は、内部のHttpURLConnection Javaクラスで処理済であるため、Service Busでは処理されません。

200s

200レベルのステータス・コードは、操作の成功を示します。Service Busは、ビジネス・サービス・タイプにかかわらず、HTTPビジネス・サービスにレスポンス・ペイロードとしてこれらのコードを戻します。

300s

300レベルのステータス・コードは、リクエストに対応するために呼出し元が追加アクションを実行する必要があることを示すエラーです。Service Busは、サポートされるメッセージ・レスポンス・タイプを含むHTTPビジネス・サービスにレスポンス・ペイロードとしてこれらのコードを戻します。

レスポンス・パイプラインで、300レベルのコードを処理するために適切なアクションを実行できます。

リダイレクトが必要であることを示す300レベルのレスポンス・コードを処理するには、HTTPビジネス・サービスのトランスポート構成で「HTTPリダイレクトの追跡」オプションを設定します。

400s

400レベルのステータス・コードは、クライアント・エラーを示します。Service Busは、サポートされるメッセージ・レスポンス・タイプを含むHTTPビジネス・サービスにレスポンス・ペイロードとしてこれらのコードを戻します。

レスポンス・パイプラインで、400レベルのコードを処理するために適切なアクションを実行できます。

500s

500レベルのステータス・コードは、サーバー・エラーを示します。Service Busは、サポートされるメッセージ・レスポンス・タイプを含むHTTPビジネス・サービスにレスポンス・ペイロードとしてこれらのコードを戻します。

レスポンス・パイプラインで、400レベルのコードを処理するために適切なアクションを実行できます。

29.3 電子メール・トランスポートの使用

電子メール・トランスポートは、メッセージ・サービス・タイプまたは任意のXMLサービス・タイプのサービスで使用できます。次の項では、電子メール・トランスポートを使用して、プロキシ・サービスとビジネス・サービスを構成する方法について説明します。電子メール・トランスポートでは、メッセージ・サービス・タイプのサービスの一方向のメッセージングをサポートしています。電子メール・トランスポートを使用して、メッセージ・タイプのプロキシ・サービスまたはビジネス・サービスを作成する場合、サービス構成でレスポンス・タイプを「なし」に設定する必要があります。

29.3.1 電子メール・トランスポート構成のリファレンス

この項では、エンドポイントURIの形式、およびプロキシ・サービスとビジネス・サービスにおける電子メール・トランスポートの構成について説明します。

- 電子メール・トランスポートのエンドポイントURI

- 電子メール・トランスポートを使用するプロキシ・サービスの構成

- 電子メール・トランスポートを使用するビジネス・サービスの構成

29.3.1.1 電子メール・トランスポートのエンドポイントURI

電子メール・トランスポートを使用してプロキシ・サービスを構成する場合は、エンドポイントURIを次の形式で指定します。

mailfrom:mailserver-host:port

ここで、mailserver-hostはメール・サービスをホストするサーバーの名前、portはそのサーバーが使用するポート番号です。

電子メール・トランスポートを使用するビジネス・サービスを構成するとき、次の形式で1つ以上のエンドポイントURIを指定でき、こうすることで、複数のドメインの複数の受信者に電子メール・メッセージを送信できます。

mailto:name@domain_name.com

mailto:name@domain_name.com?smtp=smtp_server_resource

mailto:name@domain_name.com?mailsession=jndi_mail_session

次に例を示します。

mailto:user1@example1.com

mailto:user2@example2.com?smtp=exampleSMTP

mailto:user3@example3.com?mailsession=my.mail.Session

29.3.1.2 電子メール・トランスポートを使用するプロキシ・サービスの構成

次の表に、プロキシ・サービス用の電子メール・トランスポートの構成に使用するプロパティを示します。詳細は、「プロキシ・サービスの作成と構成」を参照してください。

表29-5 プロキシ・サービス用の電子メール・トランスポート・プロパティ

プロパティ

説明

SSLが必要

Secure Sockets Layerを使用して通信するには、このオプションを選択します。デフォルトのSSLポート番号は、次のとおりです。

- POP3(S): 995

- IMAP: 993

注意: SSLが機能するには、Service Busトラストストアに電子メール・サーバーの証明書が存在する必要があります。電子メール・トランスポートでは一方向SSL通信がサポートされます。

サービス・アカウント

電子メール・アカウントにアクセスするための認証に使用するサービス・アカウントを入力します。サービス・アカウントは、電子メール・アカウントにアクセスするために必要なユーザー名とパスワードの組合せで構成されます。

詳細は、「サービス・アカウントの操作」を参照してください。

管理対象サーバー

ポーリング・サーバーとして機能させる管理対象サーバーを選択します。すべての管理対象サーバーがメッセージを処理できますが、メッセージをポーリングできるのは、1台のサーバーのみです。

このフィールドは、クラスタ・ドメインでのみ使用できます。

ポーリング間隔

処理する新しいメッセージのポーリングを次に試行するまでの間隔を秒単位で入力します。デフォルト値は60です。

電子メール・プロトコル

電子メール・サーバーへの接続に使用する電子メール・プロトコルとして、POP3またはIMAPを選択します。

読取り制限

ポーリング・スイープごとの読取りメッセージの最大数を指定します。無制限にするには「0」と入力します。デフォルト値は10です。

参照渡し

このチェック・ボックスを選択すると、ファイルはアーカイブ・ディレクトリにステージングされ、ヘッダーに参照として渡されます。

デフォルトでは、新しいサービスを作成するときに、「参照渡し」オプションが選択されるため、アーカイブ・ディレクトリの場所を指定する必要があります。

添付ファイルを参照として渡す

このチェック・ボックスを選択すると、添付ファイルはアーカイブ・ディレクトリにステージングされ、ヘッダーに参照として渡されます。

デフォルトでは、「参照渡し」オプションが選択されると、「添付ファイルを参照渡し」オプションが暗黙的に適用されるため、アーカイブ・ディレクトリの場所を指定する必要があります。

読取り後のアクション

メッセージの読込み後の動作を選択します。

- アーカイブ: メッセージはアーカイブされます。このオプションを選択した場合、Service Busがメッセージをアーカイブするアーカイブ・ディレクトリを指定します。

- 「削除」: メッセージが削除されます。

- 移動: メッセージは移動されます。このオプションを選択した場合、Service Busがメッセージを移動するIMAP移動先フォルダを指定します。「移動」は、IMAPプロトコルでのみ使用可能です。

添付ファイル

添付ファイルの処理方法を選択します。

- アーカイブ: 添付ファイルはアーカイブ・ディレクトリに保存されます。

- 無視: 添付ファイルは無視されます。

注意: 添付ファイルをアーカイブする場合、「参照渡し」パラメータの設定に関係なく、添付ファイルは参照としてメッセージ・ヘッダーに渡されます。

IMAP移動先フォルダ

「読取り後のアクション」フィールドが「移動」に設定されている場合は、メッセージの移動先フォルダを入力します。

このフィールドは、「読取り後のアクション」を「移動」に設定した場合に構成する必要があります。

ダウンロード・ディレクトリ

電子メールをダウンロードするための一時的な場所を入力します。

アーカイブ・ディレクトリ

「読取り後のアクション」フィールドが「アーカイブ」に設定されている場合は、アーカイブの場所へのパスを入力します。

「参照渡し」または「添付ファイルを参照渡し」オプションが選択されている場合は、このフィールドは必須です。これは、「読取り後のアクション」プロパティを「アーカイブ」に設定した場合にのみアクティブになります。

エラー・ディレクトリ

問題が生じたときにメッセージと添付ファイルを書き込むファイル・システム・ディレクトリへのパスを入力します。

リクエストのエンコーディング

電子メール・トランスポートにおけるリクエストの文字セット・エンコーディングとして、デフォルトのISO-8859-1を受け入れるか、別の文字セット・エンコーディングを入力します。

29.3.1.3 電子メール・トランスポートを使用するビジネス・サービスの構成

次の表に、ビジネス・サービス用の電子メール・トランスポートの構成に使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

表29-6 ビジネス・サービス用の電子メール・トランスポート・プロパティ

プロパティ

説明

SSLが必要

Secure Sockets Layerを使用して通信するには、このオプションを選択します。電子メール・トランスポートでは一方向SSL通信がサポートされます。SSL使用時のデフォルトSMTPポート番号は465です。

注意: SSL/TLSが機能するには、Service Busトラストストアに電子メール・サーバーの証明書が存在する必要があります。

SMTPサーバー

name@domain_name.comのエンドポイントURIエントリで使用するデフォルトのSMTPサーバーを選択します。エンドポイントURIにSMTPサーバーのパラメータを指定すると、それらのサーバー・リソースがこの「SMTPサーバー」設定のかわりに使用されます。

「メール・セッション」オプションを使用する場合はSMTPサーバーを選択しないでください。

最初にSMTPサーバー・リソースを作成する必要があります。詳細は、「SMTPサーバー・リソースの作成方法」を参照してください。

メール・セッション

name@domain_name.comのエンドポイントURIエントリで使用する構成済メール・セッションのJNDI名を入力します。エンドポイントURIにJNDIメール・セッションのパラメータを指定すると、この「メール・セッション」設定のかわりにそれらのメール・セッションが使用されます。

「SMTPサーバー」オプションを使用する場合は、メール・セッションを入力しないでください。

送信元の名前

このサービスでの送信元の電子メール・アカウントの表示名を入力します。最初に、Oracle WebLogic Server管理コンソールで電子メール・セッションを構成しておく必要があります。

送信元アドレス

このサービスでの送信元の電子メール・アカウントを入力します。Oracle WebLogic Server管理コンソールでメール・セッションを作成する必要があります。また、「メール・セッション」パラメータまたは「SMTPサーバー」パラメータも設定する必要があります。

返信先の名前

電子メール・アカウントの返信先の表示名を入力します。これは、返信の送信元の名前です。

返信先アドレス

返信先の電子メール・アドレスを入力します。

接続タイムアウト

接続を切断するまでのタイムアウト間隔をミリ秒単位で入力します。「0」を入力すると、タイムアウトは発生しません。

ソケットI/Oタイムアウト

ソケットI/Oタイムアウト間隔をミリ秒単位で入力します。この値がゼロ(0)の場合、タイムアウトは発生しません。

リクエストのエンコーディング

電子メール・トランスポートにおけるリクエストの文字セット・エンコーディングとして、デフォルトのISO-8859-1を受け入れるか、別の文字セット・エンコーディングを入力します。

29.4 ファイル・トランスポートの使用

ファイル・トランスポートは、共有ファイル・システムで、指定したディレクトリ内にあるファイルからメッセージをポーリングする場合に使用します。ファイルを読み取った後、Service Busはトランスポートの構成に応じて、そのファイルを削除またはアーカイブできます。Service Busがリモートの場所にファイルを書き込む際に、プログラムがそのファイルにアクセスしないように、ファイルへの書込みが完了するまでファイル・トランスポート・ビジネス・サービスによって一時的にファイル名に.aが追加されます。

ファイル・トランスポートでは、メッセージング・サービス・タイプおよび任意のXMLサービス・タイプをサポートしています。メッセージング・サービス・タイプのリクエストでサポートされるメッセージ・タイプは、バイナリ、テキスト、MFLおよびXMLです。ファイル・トランスポートでは一方向のメッセージングのみがサポートされるため、レスポンス・メッセージ・タイプを「なし」に設定する必要があります。

29.4.1 ファイル・トランスポート構成のリファレンス

この項では、エンドポイントURIの形式、およびプロキシ・サービスとビジネス・サービスにおけるファイル・トランスポートの構成について説明します。

- ファイル・トランスポートのエンドポイントURI

- ファイル・トランスポートを使用するプロキシ・サービスの構成

- NFSファイル・システムに関する特別な考慮事項

- ファイル・トランスポートを使用するビジネス・サービスの構成

29.4.1.1 ファイル・トランスポートのエンドポイントURI

プロキシ・サービスおよびビジネス・サービスでファイル・トランスポートを使用する場合は、エンドポイントURIを次の形式で指定する必要があります。

file:///<root-dir/dir1>

ここで、root-dir/dir1は、プロキシ・サービスがファイルをポーリングしたり、ビジネス・サービスがファイルを書き込むディレクトリへの絶対パスです。

29.4.1.2 ファイル・トランスポートを使用するプロキシ・サービスの構成

次の表に、プロキシ・サービス用のファイル・トランスポートの構成に使用するプロパティを示します。詳細は、「プロキシ・サービスの作成と構成」を参照してください。

表29-7 プロキシ・サービス用のファイル・トランスポート・プロパティ

プロパティ

説明

ファイル・マスク

プロキシ・サービスがポーリングするファイルを指定します。URIがディレクトリの場合、*.*を指定すると、サービスによってそのディレクトリのすべてのファイルがポーリングされます。ファイル・マスクにはワイルドカード文字*および?を使用できます。正規表現はサポートされません。

管理対象サーバー

ポーリング・サーバーとして機能させる管理対象サーバーを選択します。すべての管理対象サーバーがメッセージを処理できますが、メッセージをポーリングできるのは、1台のサーバーのみです。

このフィールドは、クラスタ・ドメインでのみ使用できます。

ポーリング間隔

新しいファイルのポーリングを次に試行するまでの間隔を秒単位で指定します。デフォルト値は60です。

注意:ファイルが処理用に選択されるときに変更されていないことを確認するため、トランスポートはファイルを1回ポーリングしてから5秒後に再度ポーリングして、ファイル・サイズを比較します。これにより、ここに設定したポーリング間隔の間で5秒の遅延が発生する可能性があります。処理を完了してファイルのロックを解除するために十分な時間がシステムで確保されるように、この値を必ず高く設定してください。

読取り制限

各ポーリングで読み込むファイルの数を指定します。デフォルト値は10です。0を指定すると、すべてのファイルが読み込まれます。

到着順にソート

発生したイベントの順序をファイルの到着順に指定します。デフォルト値はFalseです。

クラスタ環境で実行されるプロキシ・サービスに対してこのオプションを選択すると、メッセージは常に同じサーバーに送信されます。つまり、このオプションを選択した場合、サーバー全体のロード・バランシングは無視されます。

サブディレクトリのスキャン

ポーリング・ディレクトリ内にあるすべてのサブディレクトリを再帰的にスキャンする場合は、このチェック・ボックスを選択します。

参照渡し

このチェック・ボックスを選択すると、ファイルはアーカイブ・ディレクトリにステージングされ、ヘッダーに参照として渡されます。このオプションを選択した場合、アーカイブ・ディレクトリも指定する必要があります。

読取り後のアクション

メッセージの読込み後の動作を選択します。

- アーカイブ: メッセージはアーカイブされます。このオプションを選択した場合、アーカイブ・ディレクトリも指定する必要があります。

- 「削除」: メッセージが削除されます。

ステージ・ディレクトリ

ファイルの処理中に一時的にファイルをステージングする中間ディレクトリを入力します。

前述のオプション選択にかかわらず必須です。ステージ・ディレクトリは、ポーリング・ディレクトリ(ファイル・トランスポート・プロキシ・サービスのURLで識別されるディレクトリ)内に配置しないでください。

アーカイブ・ディレクトリ

「読取り後のアクション」オプションが「アーカイブ」に設定されている場合、アーカイブ場所へのパスを入力します。「アーカイブ・ディレクトリ」フィールドは、「参照渡し」フィールドを選択した場合も必須のフィールドです。

注意: アーカイブ・ディレクトリをポーリング・ディレクトリ内に配置することはできません。

エラー・ディレクトリ

エラーが発生した場合にファイルの内容を格納するディレクトリを入力します。

前述のオプション選択にかかわらず必須です。エラー・ディレクトリは、ポーリング・ディレクトリ内に配置しないでください。

リクエストのエンコーディング

ファイル・トランスポートにおけるリクエストの文字セット・エンコーディングとして、デフォルトのutf-8を受け入れるか、別の文字セット・エンコーディングを入力します。

29.4.1.3 NFSファイル・システムに関する特別な考慮事項

ファイル・トランスポートでファイルをポーリングする場合、最初にディレクトリのファイルのリストとそのサイズを取得します。次に、5秒またはポーリング間隔が経過した後(いずれか少ない方)に再度ポーリングします。トランスポートでは、ファイルのリストを再度取得して、ファイル・サイズを最初のリストと比較します。その間隔を通じてサイズが変わらないファイルのみを処理します。標準のNFSファイル・システムでは、このプロセスに必要なファイル・ロック・メカニズムをサポートしません。この問題の解決には、次のいくつかのオプションを使用できます。

- 追加のシグナリング(ファイル転送後のファイル名の変更など)を、特別なファイル名マスクと組み合せて使用します。

- NFSに対してファイル・サイズ増大の保護を有効にするには、noac NFSマウント・オプションを使用します。これにより、ファイルのキャッシュが行われないため、lsコマンドが、最終結果の要求ファイル・サイズではなく、実際のファイル・サイズになります。

- 追加のファイル・ロック機能が導入されたNFSバージョン4以降を使用します。

- NetAppファイラ・ストレージを使用する場合、Mixed Qtreeセキュリティをボリュームに対して使用します。これで、CIFSやNFSに対してファイル・ロック・メカニズムが使用しやすくなります。

29.4.1.4 ファイル・トランスポートを使用するビジネス・サービスの構成

次の表に、ビジネス・サービス用のファイル・トランスポートの構成に使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

表29-8 ビジネス・サービス用のファイル・トランスポート・プロパティ

プロパティ

説明

接頭辞

トランスポートによってリモート・サーバー上のファイル名の先頭に付加される接頭辞を入力します。

このフィールドにアスタリスク(*)を入力しないでください。この文字によりランタイム例外が発生します。ターゲット・オペレーティング・システムに対して無効な文字を使用しないでください。

接尾辞

トランスポートによってリモート・サーバー上のファイル名の末尾に付加される接尾辞を入力します。これは必須フィールドです。

このフィールドにアスタリスク(*)を入力しないでください。この文字によりランタイム例外が発生します。ターゲット・オペレーティング・システムに対して無効な文字を使用しないでください。

リクエストのエンコーディング

ファイル・トランスポートにおけるリクエストの文字セット・エンコーディングとして、デフォルトのutf-8を受け入れるか、別の文字セット・エンコーディングを入力します。

29.5 FTPトランスポートの使用

FTPトランスポートは、リモート・ファイル・システムで、指定したディレクトリ内にあるファイルからメッセージをポーリングする場合に使用します。ファイルを読み取った後、Service Busはトランスポートの構成に応じて、そのファイルを削除またはアーカイブできます。Service Busがリモートの場所にファイルを書き込む際に、プログラムがそのファイルにアクセスしないように、ファイルへの書込みが完了するまでFTPトランスポート・ビジネス・サービスによって一時的にファイル名に.aが追加されます。

FTPトランスポートでは、メッセージング・サービス・タイプおよび任意のXMLサービス・タイプをサポートしています。メッセージング・サービス・タイプのリクエストでサポートされるメッセージ・タイプは、バイナリ、テキスト、MFLおよびXMLです。FTPトランスポートでは一方向のメッセージングのみがサポートされるため、レスポンス・メッセージ・タイプを「なし」にする必要があります。

29.5.1 FTPトランスポート構成のリファレンス

この項では、エンドポイントURIの形式、およびプロキシ・サービスとビジネス・サービスにおけるFTPトランスポートの構成について説明します。

- FTPトランスポートのエンドポイントURI

- FTPトランスポートを使用するプロキシ・サービスの構成

- FTPトランスポートを使用するビジネス・サービスの構成

29.5.1.1 FTPトランスポートのエンドポイントURI

プロキシ・サービスおよびビジネス・サービスでFTPトランスポートを使用する場合は、URIを次の形式で指定する必要があります。

ftp://<hostname:port/directory>

説明:

- hostnameは、ソースまたは宛先ディレクトリがあるFTPサーバーの名前です。

- portは、FTP接続を行うポート番号です。

- directoryは、FTPサーバー上の宛先ディレクトリです。プロキシ・サービスの場合、これはサービスが新しいファイルをポーリングする場所です。ビジネス・サービスの場合、これはファイルが書き込まれる場所です。
このディレクトリは、FTPセッションの作業ディレクトリを基準とした相対パスです。たとえば、作業ディレクトリが/home/my_ftp/で、プロキシ・サービスのエンドポイントURIがftp://ftp_server:21/documentsの場合、サービスは/home/my_ftp/documentsのファイルをポーリングします。同じ作業ディレクトリを使用すると、ビジネス・サービスのエンドポイントURIがftp://fpt_server:21/outputの場合、ファイルはhome/my_ftp/outputに書き込まれます。

29.5.1.2 FTPトランスポートを使用するプロキシ・サービスの構成

次の表に、プロキシ・サービス用のFTPトランスポートの構成に使用するプロパティを示します。詳細は、「プロキシ・サービスの作成と構成」を参照してください。

表29-9 プロキシ・サービス用のFTPトランスポート・プロパティ

プロパティ

説明

ユーザー認証

ユーザー認証のタイプとして、次のいずれかを選択します。

- 匿名: このオプションでは、FTPサーバーへのログイン時にログイン資格証明は不要ですが、必要に応じてIDとして電子メールIDを指定できます。

- 外部ユーザー: このオプションでは、FTPサーバーのユーザー名とパスワードが含まれたサービス・アカウント・リソースが参照されます。このオプションを選択した場合、使用するサービス・アカウントを選択する必要があります。

ID(電子メールID)

匿名ユーザーのメールIDを入力します。

このフィールドは、「ユーザー認証」オプションが「匿名」に設定されている場合にのみ使用できます。

サービス・アカウント

FTPサーバーにアクセスするための認証に使用するサービス・アカウントを入力します。このフィールドは、「ユーザー認証」オプションが「外部ユーザー」に設定されている場合にのみ、有効かつ必須です。このサービス・アカウント・リソースは、あらかじめService Bus内で作成しておく必要があります。

詳細は、「サービス・アカウントの操作」を参照してください。

参照渡し

このチェック・ボックスを選択すると、ファイルはアーカイブ・ディレクトリにステージングされ、ヘッダーに参照として渡されます。このオプションを選択した場合、後述のアーカイブ・ディレクトリを指定する必要があります。

リモート・ストリーミング

処理時にリモート・サーバーからFTPファイルを直接ストリーミングする場合は、このチェック・ボックスを選択します。このオプションを選択した場合、アーカイブ・ディレクトリはリモートのFTPサーバー・マシン上のリモート・ディレクトリになります。そのため、FTPユーザー・ディレクトリを基準にした相対パスでアーカイブ・ディレクトリを指定する必要があります。

ファイル・マスク

プロキシ・サービスがポーリングするファイルの正規表現を入力します。URIがディレクトリで、ファイル・マスクが*.*の場合、サービスはディレクトリ内のすべてのファイルをポーリングします。

管理対象サーバー

ポーリング・サーバーとして機能させる管理対象サーバーを選択します。すべての管理対象サーバーがメッセージを処理できますが、メッセージをポーリングできるのは、1台のサーバーのみです。

このフィールドは、クラスタ・ドメインでのみ使用できます。

ポーリング間隔

処理するファイルのポーリングをサービスが次に実行するまでの間隔を秒単位で入力します。デフォルト値は60です。

注意:ファイルが処理用に選択されるときに変更されていないことを確認するため、トランスポートはファイルを1回ポーリングしてから5秒後に再度ポーリングして、ファイル・サイズを比較します。これにより、ここに設定したポーリング間隔の間で5秒の遅延が発生する可能性があります。処理を完了してファイルのロックを解除するために十分な時間がシステムで確保されるように、この値を必ず高く設定してください。

読取り制限

ポーリング・スイープごとの読取りメッセージの最大数を指定します。無制限にするには「0」と入力します。デフォルトは10です。

読取り後のアクション

メッセージが読み込まれた後の動作を選択します。

- アーカイブ: メッセージはアーカイブされます。このオプションを選択した場合、後述のアーカイブ・ディレクトリも指定する必要があります。

- 「削除」: メッセージが削除されます。

転送モード

ファイル転送モードとして「バイナリ」または「ascii」を選択します。デフォルトでは、転送はバイナリです。

アーカイブ・ディレクトリ

「読取り後のアクション」オプションが「アーカイブ」に設定されている場合は、アーカイブの場所へのパスを入力します。「参照渡し」オプションが選択されている場合は、このフィールドも必須です。

注意: アーカイブ・ディレクトリ、ダウンロード・ディレクトリ、およびエラー・ディレクトリは絶対パスであり、自動的に作成されます。相対パスを指定すると、ファイルはWebLogic Serverを起動するJavaプロセスを基準にした相対的な位置に作成されます。

ダウンロード・ディレクトリ

ファイル転送時にファイルがダウンロードされる、ローカル・マシンのディレクトリを入力します。

注意: アーカイブ・ディレクトリ、ダウンロード・ディレクトリ、およびエラー・ディレクトリは絶対パスであり、自動的に作成されます。相対パスを指定すると、ファイルはWebLogic Serverを起動するJavaプロセスを基準にした相対的な位置に作成されます。

エラー・ディレクトリ

エラーが発生した場合にファイルの内容を格納する場所を入力します。

注意: アーカイブ・ディレクトリ、ダウンロード・ディレクトリ、およびエラー・ディレクトリは絶対パスであり、自動的に作成されます。相対パスを指定すると、ファイルはWebLogic Serverを起動するJavaプロセスを基準にした相対的な位置に作成されます。

リクエストのエンコーディング

リクエスト・メッセージを読み込む際のエンコーディングのタイプを指定します。デフォルトのエンコーディングはutf-8です。

サブディレクトリのスキャン

ファイルをポーリングする際に、すべてのディレクトリを再帰的にスキャンする場合は、このチェック・ボックスを選択します。

到着順にソート

イベントを受信順に配信する場合は、このチェック・ボックスを選択します。

タイムアウト

接続が切断されるまでのソケット・タイムアウト間隔を秒単位で入力します。「0」を入力すると、タイム・アウトは発生しません。

再試行回数

FTP接続失敗時の再試行回数を指定します。

29.5.1.3 FTPトランスポートを使用するビジネス・サービスの構成

次の表に、ビジネス・サービス用のFTPトランスポートの構成に使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

表29-10 ビジネス・サービス用のFTPトランスポート・プロパティ

プロパティ

説明

ユーザー認証

ユーザー認証のタイプとして、次のいずれかを選択します。

- 匿名: このオプションでは、FTPサーバーへのログイン時にログイン資格証明は不要ですが、必要に応じてIDとして電子メールIDを指定できます。

- 外部ユーザー: このオプションでは、FTPサーバーのユーザー名とパスワードが含まれたサービス・アカウント・リソースが参照されます。このオプションを選択した場合、使用するサービス・アカウントを選択する必要があります。

ID(電子メールID)

匿名ユーザーのメールIDを入力します。

このフィールドは、「ユーザー認証」オプションが「匿名」に設定されている場合にのみ使用できます。

サービス・アカウント

サービスにアクセスするための認証に使用するサービス・アカウントを入力します。このフィールドは、「ユーザー認証」オプションが「外部ユーザー」に設定されている場合にのみ、有効かつ必須です。このサービス・アカウント・リソースは、あらかじめService Bus内で作成しておく必要があります。

詳細は、「サービス・アカウントの操作」を参照してください。

タイムアウト

接続が切断されるまでのソケット・タイムアウト間隔を秒単位で入力します。デフォルトでは60秒です。

宛先ファイル名の接頭辞

トランスポートによってリモート・サーバー上のファイル名の先頭に付加される、省略可能な接頭辞を入力します。

このフィールドにはアスタリスク(*)を入力しないでください。この文字を入力すると、実行時例外が発生します。

宛先ファイル名の接尾辞

トランスポートによってリモート・サーバー上のファイル名の末尾に付加される、省略可能な接尾辞を入力します。

このフィールドにはアスタリスク(*)を入力しないでください。この文字を入力すると、実行時例外が発生します。

転送モード

ファイル転送モードとして「ascii」または「バイナリ」を選択します。

リクエストのエンコーディング

FTPトランスポートにおけるリクエストの文字セット・エンコーディングとして、デフォルトのUTF-8を受け入れるか、別の文字セット・エンコーディングを入力します。

29.6 SFTPトランスポートの使用

SFTPトランスポートは、SSHバージョン2を使用したSFTP (SSHファイル・トランスポートプロトコル)経由でファイルを安全にトランスポートできるポーリング・ベースのトランスポートです。それは、定義済のポーリング間隔に基づいて指定されたディレクトリを定期的にポーリングします。認証後、Service BusサービスとSFTPサーバー間で接続が確立され、ファイル転送が可能になります。SFTPトランスポートでは、一方向のインバウンドおよびアウトバウンド接続をサポートしています。

Service Busがリモートの場所にファイルを書き込む際に、プログラムがそのファイルにアクセスしないように、ファイルへの書込みが完了するまでSFTPトランスポート・ビジネス・サービスによって一時的にファイル名に.aが追加されます。

注意:

SFTPトランスポートでは、マルチバイト文字セットのファイル名を正しく処理できないことがあります。

SFTPトランスポートでは、メッセージ・サービス・タイプおよび任意のXMLサービス・タイプのみをサポートしています。メッセージング・サービス・タイプのリクエストでサポートされるメッセージ・タイプは、バイナリ、テキスト、MFLおよびXMLです。SFTPトランスポートがサポートしているのは一方向のメッセージングのみであるため、レスポンス・メッセージ・タイプを「なし」に設定する必要があります。

29.6.1 SFTPトランスポートの機能

SFTPトランスポートは次の機能を提供しています。

- SFTPトランスポートは、任意のXMLサービス・タイプおよび(リクエスト・メッセージ・タイプが指定された)メッセージ・サービス・タイプで使用できます。サービス・タイプの構成の詳細は、「プロキシ・サービスの定義」および「ビジネス・サービスの定義」を参照してください。

- SFTPトランスポートでは、サイズの大きいメッセージの処理をサポートしています。プロキシ・サービスの構成時に、コンテンツ・ストリーミングを有効にし、サイズの大きいメッセージをメモリーまたはディスク・ファイルにバッファリングする必要があるかどうかを指定できます。詳細は、「bodyコンテンツのストリーミング」を参照してください。

- SFTPトランスポートでは暗号スイートやセキュリティ・アルゴリズムを選択でき、Service Busで適切な一致の検出を許可することもできます。

- インバウンド・メッセージを転送する場合、QoSをexactly-onceに設定します。これにより、各メッセージが少なくとも1回は処理されることが保証されます。アウトバウンド・メッセージを処理する場合は、QoSをbest-effortに設定します。

注意:

転送されないメッセージに関しては、パイプライン・エラー・ハンドラにエラー処理ロジック(再試行ロジックを含む)を作成する必要があります。

Service BusメッセージングのQoSの詳細は、「サービスの品質」を参照してください。

- SFTPトランスポートでFIPS (Federal Information Processing Standards)準拠がサポートされるようになりました。 詳細は、「SFTPトランスポートのためのFIPS準拠について」を参照してください。

29.6.2 SFTP認証の一般原則

次の原則は、プロキシ・サービスとビジネス・サービスのSFTP認証プロセスに適用されます。

- 接続: Service Busプロキシ・サービスまたはビジネス・サービスは、常にSFTPクライアントとして機能し、SFTPサーバーに接続します。

- SFTPサーバーによる認証: サーバー認証は、次のいずれかの方法で実行されます。

- 公開鍵認証およびホスト・ベース認証の場合、SFTPサーバーはService Busサービスの公開鍵を使用して接続を認証します。

- ユーザー名とパスワードによる認証の場合、SFTPサーバーは、ユーザー名とパスワードで接続を認証します。

- SFTPクライアントによる認証: Service Busサービスは、常に、known_hostsファイルに定義された公開鍵/ホスト/IPの組合せを使用してSFTPサーバーを認証します。詳細は、「既知ホスト・ファイルの作成」を参照してください。

- 接続の確立: サーバー認証とクライアント認証の両方に成功した場合にのみ接続が確立されます。

- ファイル転送:

- クライアントがプロキシ・サービスの場合、ファイル(メッセージ)はSFTPサーバーからダウンロードされます。

- クライアントがビジネス・サービスの場合、ファイル(メッセージ)はSFTPサーバーにアップロードされます。

29.6.3 SFTPトランスポートの実行時の動作

SFTPトランスポートを使用したファイルの転送には、次の手順が含まれます。

1. プロキシ・サービスが入力ディレクトリを定期的にポーリングします。
ポーリング・サイクルごとに新しい接続が作成されます。

2. プロキシ・サービスは、入力ディレクトリでファイルを見つけると、.stage拡張子の付いたファイル名に変更します。この名前変更により、サービスが次回のポーリング・サイクルで同じファイルを選択しないことが保証されます。
.stageファイルは、配信されるまで入力ディレクトリ内に存在します。

注意:

(ネットワーク障害などが原因で)入力ディレクトリからファイルを取得できない場合、.stageファイルはクリーンアップ・サイクルで処理されます。クリーンアップ・サイクルは、15分ごとまたは15回のポーリング・サイクルの後に実行されます(いずれか後に発生した方が実行されます)。連続する2回のクリーンアップ・サイクルで.stageファイルが存在する場合、ファイルは再度処理されます。

3. メッセージのJMSタスクが作成され、ドメイン全体のJMSキューに追加されます。

4. ドメイン全体のMDBがタスクを受け取り、メッセージを処理します。
このタスクでは、メッセージを処理する際にプールされた接続を使用します。プールの接続を使用できない場合は、新しい接続が作成されます。

5. メッセージがパイプラインに配信され、.stageファイルが削除されます。

6. SFTPビジネス・サービスを構成している場合、サービスはプールされた接続を使用して、メッセージをアウトバウンド・ディレクトリに配置します。

メッセージが配信されていない場合は、再度メッセージの転送が試行され、定義済の試行回数に達するまでプロセスが繰り返されます。メッセージを配信できない場合、メッセージはエラー・ディレクトリに移動されます。

29.6.4 SFTP認証の有効化

SFTPトランスポートでは、次の認証方式をサポートしています。

- ユーザー名/パスワード認証

- ホスト・ベース認証

- 公開鍵認証

Service Busサービスは、known_hostsファイルに定義されたサーバーの詳細に基づいてSFTPサーバーを認証します。サーバー認証を有効にするには、クライアント・マシンでknown_hostsファイルを作成する必要があります。

29.6.4.1 既知ホスト・ファイルの作成

known_hostsファイルは、Service Busプロキシ・サービス(インバウンド・リクエスト)またはビジネス・サービス(アウトバウンド・リクエスト)が実行されているサーバーに存在する必要があります。このファイルには、プロキシ・サービスまたはビジネス・サービスの接続先となるリモートSFTPサーバーのホスト名、IPアドレスおよび公開鍵が含まれている必要があります。

既知ホスト・ファイルを作成するには:

1. known_hostsファイルを作成し、情報を次の形式で入力します。

Hostname,IP algorithm publickey

説明:

- Hostnameは、SFTPサーバーのホスト名です。ホスト名は省略可能です。

- IPは、SFTPサーバーのIPアドレスです。
IPv6アドレスを使用する場合は、複数の0を表すために2つのコロンを使用しないでください。すべての0を指定します。たとえば、「::」という形式ではなく「:0:0:0:」を使用します。

- algorithmには、SFTPサーバーの構成に基づいて、DSAまたはRSAのいずれかを指定できます。サポートされているアルゴリズムに応じて、ssh-rsaまたはssh-dssと入力します。

- publickeyは、SFTPサーバーの公開鍵です。公開鍵は、Open SSH公開鍵形式であることが必要です。

例 - 既知ホスト・ファイル

getafix,172.22.52.130 ssh-rsa

AAAAB3NzaC1yc2EAAAABIwAAAIEAtR+M3Z9HFxnKZTx66fZdnQqAHQcF1vQe1+EjJ/HWYtg

Anqsn0hMJzqWMatb/u9yFwUpZBirjm3g2I9Qd8VocmeHwoGPhDGfQ5LQ/PPo3esE+CGwdnC

OyRCktNHeuKxo4kiCCJ/bph5dRpghCQIvsQvRE3sks+XwQ7Wuswz8pv58=

known_hostsファイルには、複数のエントリを含めることができますが、各エントリはそれぞれ別の行に入力する必要があります。

2. known_hostsファイルをDOMAIN_HOME/config/osb/transports/sftpディレクトリに移動します。

/transports/sftpディレクトリは、自動的に作成されるわけではありません。手動で作成する必要があります。

29.6.4.2 ユーザー名/パスワード認証の有効化

ユーザー名/パスワード認証は、最も簡単で手早い認証方式です。この認証方式は、ユーザーの資格証明に基づいています。

サービスのユーザー名/パスワード認証を有効にするには:

1. SFTPサーバーのユーザー資格証明を使用して静的サービス・アカウントを作成します。詳細は、「サービス・アカウントの操作」を参照してください。

2. known_hostsファイルを作成します。詳細は、「既知ホスト・ファイルの作成」を参照してください。

29.6.4.3 ホスト・ベース認証の有効化

ホスト・ベース認証では、プライベート・ホスト・キーを使用します。この方式は、すべてのユーザーが同じプライベート・ホストを共有している場合に使用できます。

ホストベース認証では、Open SSHがクライアント提供のホスト名と、クライアントIPアドレスのリバース・ルックアップを比較します。リクエストが複数ホーム・マシンから送られるシナリオ、またはNATゲートウェイを介して送られるシナリオでは、ホスト名は一致しない場合があり、認証が失敗します。このようなシナリオを回避するには、/etc/ssh/sshd_configのHostbasedUsesNameFromPacketOnlyプロパティをyesに設定することで、DNSチェックをオフにします。実際のセキュリティは、known_hostsファイルとSFTPサーバーの公開鍵の照合によって行われるため、この回避方法はセキュリティを損ないません。

サービスのホスト・ベース認証を有効にするには:

1. SSLクライアント認証キーでサービス・キー・プロバイダを構成します。詳細は、「サービス・キー・プロバイダの操作」を参照してください。

注意:

公開鍵は、サービス・キー・プロバイダの作成時に使用したキーストアから抽出できます。公開鍵は、Open SSH形式であることが必要です。

2. known_hostsファイルを作成します。詳細は、「既知ホスト・ファイルの作成」を参照してください。

3. SFTPサーバーのクライアントであるService Busからのリクエストを受け入れるようにSFTPサーバーを構成します。

たとえば、LinuxのSFTPサーバーの場合、次の手順を実行します。

- /etc/ssh/shosts.equivファイルを編集し、Service Busドメインを実行しているマシンのホスト名またはIPアドレスを追加します。

- /etc/ssh/ssh_known_hostsファイルを編集して、Service Busドメインを実行しているマシンのホスト名またはIPアドレスを追加し、その後に空白を入力して公開鍵を追加します。

29.6.4.4 公開鍵認証の有効化

公開鍵認証は、ユーザー独自の秘密鍵を使用して実行されます。この方式は、各ユーザーが秘密鍵を持っている場合に使用できます。

公開鍵認証を有効にするには:

1. SSLクライアント認証キーでサービス・キー・プロバイダを構成します。詳細は、「サービス・キー・プロバイダの操作」を参照してください。

2. Service Bus (SFTPクライアント)からのリクエストを受け入れるようにSFTPサーバーを構成します。

たとえば、LinuxのSFTPサーバーの場合、キーストアから公開鍵を抽出し、このキーをSFTPサーバーの$HOME/.ssh/authorized_keysファイルに入力します。このパスとファイルが存在することを確認してください。

3. known_hostsファイルを作成します。詳細は、「既知ホスト・ファイルの作成」を参照してください。

29.6.5 SFTPトランスポートのためのFIPS準拠について

SFTPトランスポートでFIPS (Federal Information Processing Standards)準拠がサポートされるようになりました。

FIPS-140–2の評価済暗号化アルゴリズムがSFTPトランスポートで使用可能です。FIPS準拠が有効な場合、次の公開鍵アルゴリズムと鍵交換アルゴリズムがサポートされています。

- 公開鍵アルゴリズム: ssh-rsa (Service Busランタイム・デフォルトでは、FIPS準拠が有効)

- 鍵交換アルゴリズム: diffie-hellman-group14-sha1 (Service Busランタイム・デフォルトでは、FIPS準拠が有効)

その他の公開鍵アルゴリズムと鍵交換アルゴリズムはサポートされておらず、選択できません。

29.6.5.1 FIPS準拠の有効化

SFTPトランスポートを使用するプロキシ・サービスまたはビジネス・サービスでは、FIPS準拠を有効にできます。このタスクは、JDeveloperまたはService Busコンソールを使用して実行できます。

プロキシ・サービスまたはビジネス・サービスでFIPS準拠を有効にするには:

1. プロキシ・サービスまたはビジネス・サービスの「トランスポートの詳細」ページから、「FIPS準拠の有効化」を選択します。

2. 「優先公開鍵アルゴリズム」リストから、サポートされているアルゴリズムを選択します。サポート対象外のアルゴリズムはリストに表示されません。

3. 「優先鍵交換アルゴリズム」リストから、サポートされているアルゴリズムを選択します。サポート対象外のアルゴリズムはリストに表示されません。

29.6.5.2 FIPS準拠のアップグレードの考慮事項

デフォルトでは、FIPS準拠は無効になっています。クライアントのアップグレード時に、既存のSFTPトランスポート構成のFIPS準拠は無効として表示されます。

FIPS準拠を有効にする場合は、FIPS準拠の暗号リストから「優先暗号化」を選択する必要があります。次の暗号がFIPSに準拠しています。

- aes128-cbc

- aes128-ctr

- arcfour

- arcfour128

- blowfish-cbc

- 3des-cbc

- 3des-ctr

29.6.6 SFTPトランスポートの通信エラーの処理

リモートSFTPサーバーへの接続時に接続またはユーザー認証に失敗した場合に発生する可能性のある通信エラーを処理するように、SFTPトランスポート・ベースのビジネス・サービスを構成できます。ビジネス・サービスを構成するときに、指定した再試行間隔の後、ビジネス・サービスのエンドポイントURIがオフラインになるように設定できます。

詳細は、『Oracle Service Busの管理』のビジネス・サービス用のエンドポイントURIの管理とモニターに関する項を参照してください。

29.6.7 SFTPトランスポートのトラブルシューティング

ほとんどのエラーは、SFTPプロキシ・サービスまたはビジネス・サービスの構成中に発生します。エラーについて理解し、エラーを解決する上で役立つヒントを次に示します。

- known_hostsファイルを適切に構成していることを確認します。

- 公開鍵認証では、公開鍵ファイルをサーバーに格納します。詳細は、SFTPサーバー付属のドキュメントを参照してください。

- 接続は拒否されましたというエラー・メッセージは、構成済のホストとポートでSFTPサーバーを使用できないことを示します。

- 「認証に失敗しました」というエラー・メッセージは、ユーザー名またはパスワードが無効であるか、公開鍵が正しく構成されていないことを示します。

- 接続が正常に完了しませんでしたというエラー・メッセージは、接続エラーの原因となった実際のエラー(キーが見つかりませんなど)が表示された後に表示されます。

- IP、ホストのキーが見つかりませんというエラー・メッセージは、指定されたIPとホストの組合せに対応するエントリがknown_hostsファイルに含まれていないことを示します。エントリが存在する場合は、別のアルゴリズムのキーを使用して試行されます。たとえば、以前の試行でRSAキーが使用された場合は、DSAキーを使用して再試行されます。

29.6.8 SFTPトランスポート・サービスのインポート

この項では、構成JARファイルおよびUDDIレジストリからのService Busリソースのインポートについて説明します。

- SFTPトランスポートにより使用されるリソースのインポート

- サービスのインポートとパブリッシュ: UDDIレジストリ

29.6.8.1 SFTPトランスポートにより使用されるリソースのインポート

Service Busドメインにすでに存在するリソースをインポートする場合、「セキュリティおよびポリシーの構成を保持」オプションを選択することで、そのリソースの既存のセキュリティおよびポリシーの構成の詳細を保持できます。リソースのインポート時に保持されるSFTPサービス固有の詳細は次のとおりです。

- クライアント認証方式

- サービス・アカウントへの参照(ユーザー名/パスワード認証に関連付けられたサービスの場合)

- ホスト・ベース認証または公開鍵認証に関連付けられたサービスのサービス・キー・プロバイダへの参照

- ホスト・ベース認証または公開鍵認証に関連付けられたサービスのユーザー名

リソースのインポートの詳細は、「リソースおよび構成のインポートとエクスポート」を参照してください。

29.6.8.2 サービスのインポートとパブリッシュ: UDDIレジストリ

SFTPサービスをUDDIレジストリにパブリッシュすると、「認証モード」、「リクエストのエンコーディング」、「到着順にソート」および「ファイル・マスク」の各プロパティがパブリッシュされます。サービスのインポート後のロード・バランシング・アルゴリズムのデフォルト値はround-robinです。

SFTPサービスをUDDIレジストリからインポートしたときに、レジストリからインポートされるプロパティを表29-11に示します。

表29-11 UDDIレジストリからインポートされるプロパティ

プロパティ

説明

宛先ファイル名の接頭辞

リモート・サーバーに格納されるファイルの名前に使用する接頭辞です。

デフォルト値は" "(null)です。

宛先ファイル名の接尾辞

リモート・サーバーに格納されるファイルの名前に使用する接尾辞です。

デフォルト値は" "(null)です。

認証モード

レジストリからインポートされる認証方式です。

ユーザー認証を使用するSFTPビジネス・サービスをUDDIレジストリからService Busにインポートすると、競合が発生します。

- ユーザー名/パスワード認証の場合は、サービス・アカウントを作成し、そのアカウントをサービスに関連付ける必要があります。

- ホスト・ベース認証または公開鍵認証の場合は、サービス・キー・プロバイダを作成し、サービスに関連付ける必要があります。

詳細は、「UDDIレジストリの操作」を参照してください。

29.6.9 SFTPトランスポート構成のリファレンス

この項では、エンドポイントURIの形式と環境値、およびプロキシ・サービスとビジネス・サービスにおけるSFTPトランスポートの構成について説明します。

- SFTPトランスポートのエンドポイントURI

- SFTPトランスポートを使用するプロキシ・サービスの構成

- パイプラインでのトランスポート・ヘッダーの構成

- テスト・コンソールでのトランスポート・ヘッダーとメタデータの構成

- SFTPトランスポートを使用するビジネス・サービスの構成

- SFTPトランスポートの環境値

29.6.9.1 SFTPトランスポートのエンドポイントURI

プロキシ・サービスおよびビジネス・サービスでSFTPトランスポートを使用する場合は、エンドポイントURIを次の形式で指定します。

sftp://hostname:port/directory

説明:

- hostnameは、SFTPサーバーのホスト名またはIPアドレスです。

- portは、SFTPサーバーがリスンしているポートです。SFTPのデフォルト・ポートは22です。

- directoryは、ビジネス・サービスがアウトバウンド・メッセージを書き込んだり、プロキシ・サービスが定期的にファイルをポーリングする場所です。
ディレクトリはSFTPセッションの作業ディレクトリを基準として相対的に指定します。たとえば、作業ディレクトリがhome/my_sftp/で、SFTPプロキシ・サービスがhome/my_sftp/documentsからファイルを読み取る場合、URIはsftp://sftp_server:22/documentsのようになります。ビジネス・サービスに同じ作業ディレクトリを使用すると、URIがsftp://sftp_server:22/outputの場合、ビジネス・サービスはhome/my_sftp/outputにファイルを書き込みます。

29.6.9.2 SFTPトランスポートを使用するプロキシ・サービスの構成

次の表に、プロキシ・サービス用のSFTPトランスポートの構成に使用するプロパティを示します。詳細は、「プロキシ・サービスの作成と構成」を参照してください。

表29-12 プロキシ・サービス用のSFTPトランスポート・プロパティ

プロパティ

説明

ユーザー認証

必要な認証方式を次から選択します。

- 「ユーザー名パスワード」認証: 静的サービス・アカウントをこの認証方式に関連付け、サービス・アカウントで提供される資格証明を使用してクライアントを認証します。

- 「ホスト・ベース」認証: ユーザー名とサービス・キー・プロバイダが必要です。既知のホストから接続するユーザーは、ホストの秘密鍵を使用して認証されます。

- 「公開鍵」認証: ユーザー名とサービス・キー・プロバイダが必要です。ユーザーは、独自の秘密鍵を持ちます。

注意: このサービスでは、SFTPサーバーから資格証明を認証するためにサービス・キー・プロバイダを使用しません。SFTPサーバーを認証する場合、「SFTPトランスポートのトランスポート・レベルでのセキュリティの構成」に示すとおり、known_hostsファイルのみを使用します。プロキシ・サービスは、指定されたユーザー認証方式に基づいてSFTPサーバーによって認証されます。

サービス・アカウント

サービスにアクセスするための認証に使用するサービス・アカウントを入力します。サービス・アカウントの使用については、「サービス・アカウントの操作」を参照してください。

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

認証に使用するサービス・キー・プロバイダを入力します。

このフィールドは、公開鍵認証方式とホスト・ベース認証方式にのみ使用できます。詳細は、「サービス・キー・プロバイダの操作」を参照してください。

ユーザー名

SFTPサーバーにログインするためのユーザー名を入力します。この値は、ホスト・ベース認証方式または公開鍵認証方式を選択した場合にのみ必要です。

- ホスト・ベース認証では、SFTPサーバー上のユーザーのホーム・ディレクトリをポーリングするためにユーザー名が必要となります。

- 公開鍵認証では、ユーザーのホーム・ディレクトリのポーリングとSFTPサーバー上の公開鍵の場所の識別にユーザー名が必要となります。

参照渡し

このオプションを選択すると、ファイルはアーカイブ・ディレクトリにステージングされ、参照としてヘッダーに渡されます。

注意: このオプションは、リモート・ストリーミングが無効になっている場合にのみ使用できます。

リモート・ストリーミング

このオプションを選択すると、処理時にSFTPのファイルがリモート・サーバーから直接ストリームされます。このオプションを選択した場合、SFTPサーバー・マシンのリモート・ディレクトリがアーカイブ・ディレクトリになります。そのため、SFTPユーザー・ディレクトリからの相対パスでアーカイブ・ディレクトリを指定する必要があります。

ファイル・マスク

正規表現を入力して、ディレクトリから取り出すファイルを選択します。ファイル・マスクは、特定のタイプのファイルを転送する場合に使用します。デフォルト値は*.*で、すべてのファイルが選択されます。

ファイル・マスクは正規表現です

「ファイル・マスク」フィールドに正規表現(regex)を使用する場合は、このオプションを選択します。

Tmpファイル接尾辞

転送時に使用される一時ファイルに付ける接尾辞を入力します。デフォルト値は_tmpです。

管理対象サーバー

ポーリング・サーバーとして機能させる管理対象サーバーを選択します。すべての管理対象サーバーがメッセージを処理できますが、メッセージをポーリングできるのは、1台のサーバーのみです。

このフィールドは、クラスタ・ドメインでのみ使用できます。

ポーリング間隔

入力ディレクトリでの処理するメッセージのポーリングを次に実行するまでの間隔を秒単位で入力します。ポーリングでは、SFTP接続を作成する必要があります。デフォルト値は60です。間隔が短いと頻繁にポーリングが発生するため、短いポーリング間隔を設定しないでください。

注意:ファイルが処理用に選択されるときに変更されていないことを確認するため、トランスポートはファイルを1回ポーリングしてから5秒後に再度ポーリングして、ファイル・サイズを比較します。これにより、ここに設定したポーリング間隔の間で5秒の遅延が発生する可能性があります。処理を完了してファイルのロックを解除するために十分な時間がシステムで確保されるように、この値を必ず高く設定してください。

読取り制限

ポーリング・スイープごとの読取りメッセージの最大数を指定します。ポーリング・ディレクトリに多数のファイルが存在する場合は、ここで指定した値により同時転送の数を制限できます。

制限を指定しない場合は、0(ゼロ)を入力します。デフォルト値は10です。

注意: SFTPサーバーで同時接続数が制限されている場合があります。定義した読取り制限がサーバーで定義されている制限よりも少ないことを確認してください。

読取り後のアクション

メッセージが読み込まれた後の動作を選択します。

- アーカイブ: メッセージは指定されたディレクトリにアーカイブされます。このオプションを選択した場合、後述のアーカイブ・ディレクトリを指定する必要があります。

- 「削除」: メッセージが削除されます。

アーカイブ・ディレクトリ

「読取り後のアクション」オプションが「アーカイブ」に設定されている場合、アーカイブ場所へのパスを入力します。このフィールドは、「参照渡し」オプションが選択されている場合、必須です。ファイルを読取り後にアーカイブする場合、それらのファイルは、読み取られた後に(ダウンロード・ディレクトリまたはリモートの場所から)アーカイブ・ディレクトリに移動されます。

リモート・ストリーミングが有効になっている場合、アーカイブ・ディレクトリはSFTPサーバーのディレクトリになります。リモート・ストリーミングが無効になっている場合は、Service Busマシン上のアーカイブ・ディレクトリを使用できます。

注意: アーカイブ・ディレクトリ、ダウンロード・ディレクトリおよびエラー・ディレクトリは絶対パスであり、自動的に作成されます。相対パスを指定すると、ファイルはWebLogic Serverを起動するJavaプロセスを基準にした相対的な位置に作成されます。

ダウンロード・ディレクトリ

ファイル転送時にファイルがダウンロードされる、ローカル・マシンのディレクトリを入力します。リモート・ストリーミングが有効になっている場合、このオプションは無効になります。

注意: アーカイブ・ディレクトリ、ダウンロード・ディレクトリおよびエラー・ディレクトリは絶対パスであり、自動的に作成されます。相対パスを指定すると、ファイルはWebLogic Serverを起動するJavaプロセスを基準にした相対的な位置に作成されます。

エラー・ディレクトリ

問題が発生した場合にメッセージがポストされる場所を入力します。

リモート・ストリーミングが有効になっている場合、エラー・ディレクトリはSFTPサーバーのディレクトリになります。リモート・ストリーミングが無効になっている場合は、Service Busマシン上のエラー・ディレクトリを使用できます。

注意: アーカイブ・ディレクトリ、ダウンロード・ディレクトリ、およびエラー・ディレクトリは絶対パスであり、自動的に作成されます。相対パスを指定すると、ファイルはWebLogic Serverを起動するJavaプロセスを基準にした相対的な位置に作成されます。

リクエストのエンコーディング

SFTPトランスポートでのリクエストの文字セット・エンコーディングとしてデフォルト値(UTF-8)を受け入れます。

サブディレクトリのスキャン

エンドポイントURIで指定されたディレクトリ内のすべてのサブディレクトリを再帰的にスキャンする場合は、このオプションを選択します。

注意: サブディレクトリをスキャンする場合、追加の処理オーバーヘッドが必要となるため、このオプションは慎重に使用してください。

到着順にソート

このオプションを選択すると、イベントは到着順に配信されます。これにより、メッセージ配信がランダムに行われるのではなく、ファイルが宛先ディレクトリにダウンロードされた時間に基づいて行われるようになります。

タイムアウト

ソケット・タイムアウト間隔を秒単位で入力します。この時間が経過すると、接続を切断する必要があります。接続をタイムアウトしない場合は、0を入力します。デフォルト値は60です。

再試行回数

SFTP接続に失敗した場合の再試行回数を指定します。この設定を使用すると、ネットワーク障害などのエラーの発生時に、複数回の試行が可能になります。デフォルト値は3です。

FIPS準拠の有効化

SFTP接続のFIPS (連邦情報処理標準)準拠を有効化します。有効にすると、FIPS準拠の公開鍵および鍵交換アルゴリズムが有効になり、「優先公開鍵アルゴリズム」および「優先鍵交換アルゴリズム」リストで選択可能になります。互換性のないアルゴリズムは無効で選択できません。

優先暗号スイート

サーバーとの通信時に使用する暗号スイートを、使用可能なオプションのリストから選択します。使用する暗号スイートにより、ネットワーク接続の認証と暗号化に関する設定が決まります。

デフォルト値「実行時のデフォルトの使用」を使用すると、サポートされる暗号スイートのリストがサーバーに送信され、一致が検出されるまで各暗号スイートが試行されます。

優先データ整合性アルゴリズム

データ整合性チェックに使用するバルク・ハッシュ・アルゴリズムを、使用可能なオプションのリストから選択します。

デフォルト値の実行時のデフォルトの使用を使用すると、Service Busによって優先アルゴリズムhmac-sha1が送信されます。サーバーでこれがサポートされない場合は、サポートされるアルゴリズムのリストがサーバーに送信され、一致が検出されるまで各アルゴリズムが試行されます。

優先公開鍵アルゴリズム

公開鍵暗号化に使用する非対称鍵アルゴリズムを、使用可能なオプションのリストから選択します。

デフォルト値の実行時のデフォルトの使用を使用すると、Service Busによって優先アルゴリズムssh-dssが送信されます。サーバーでこれがサポートされない場合は、サポートされるアルゴリズムのリストがサーバーに送信され、一致が検出されるまで各アルゴリズムが試行されます。

「FIPS準拠の有効化」オプションが選択されると、ランタイム・デフォルトが変わります。デフォルト値ランタイム・デフォルトの使用を使用すると、Oracle Service Busによって優先アルゴリズムssh-rsaが送信されます。サーバーでこれがサポートされない場合は、サポートされるアルゴリズムのリストがサーバーに送信され、一致が検出されるまで各アルゴリズムが試行されます。

優先鍵交換アルゴリズム

メッセージの暗号化のためのセッション鍵のネゴシエーション用として、デフォルトの鍵交換プロトコルを選択します。

デフォルト値の実行時のデフォルトの使用を使用すると、Service Busによって優先アルゴリズムdiffie-hellman-group1-sha1が送信されます。サーバーでこれがサポートされない場合は、サポートされるアルゴリズムのリストがサーバーに送信され、一致が検出されるまで各アルゴリズムが試行されます。

「FIPS準拠の有効化」オプションが選択されると、ランタイム・デフォルトが変わります。デフォルト値のランタイム・デフォルトの使用を使用すると、Oracle Service Busでは優先的にdiffie-hellman-group14-sha1アルゴリズムが送信されます。サーバーでこれがサポートされない場合は、サポートされるアルゴリズムのリストがサーバーに送信され、一致が検出されるまで各アルゴリズムが試行されます。

優先圧縮アルゴリズム

処理中のデータをzlibを使用して圧縮するかどうかを選択します。データを圧縮するには「zlib」または「zlib@openssh.com」を、それ以外の場合は「なし」を選択します。デフォルトは、Noneです。

29.6.9.2.1 トランスポート・ヘッダーとメタデータの構成

プロキシ・サービスを構成するときに、パイプラインでトランスポート・ヘッダー・アクションを使用してメッセージのヘッダー値を設定できます。SFTPトランスポートに関連するトランスポート・ヘッダーとメタデータを次の表に示します。

表29-13 トランスポート・ヘッダーとメタデータ

ヘッダー/メタデータ

説明

FileName

この値は、宛先ディレクトリでファイル名として使用されます。

isFilePath

メタデータ・フィールドです。指定可能な値はtrueとfalseです。

- True: FileName がファイルの絶対パスとして解釈されます。

- False: FileName がファイルの名前として解釈されます。

filePath

レスポンス・メタデータ・フィールドです。 FileName ヘッダーで指定したファイルが書き込まれる絶対パスを示します。

29.6.9.3 パイプラインでのトランスポート・ヘッダーの構成

パイプラインでは、アウトバウンド・リクエスト用のトランスポート・ヘッダーのみを構成できます。メッセージのヘッダーの値を設定するには、トランスポート・ヘッダー・アクションを使用します。詳細は、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。

29.6.9.4 テスト・コンソールでのトランスポート・ヘッダーとメタデータの構成

開発時にSFTPトランスポートベースのサービスをテストする場合、テスト・コンソールでFileNameトランスポート・ヘッダーとisFilePathメタデータの値を構成できます。詳細は、「テスト・コンソールの使用」を参照してください。

29.6.9.5 SFTPトランスポートを使用するビジネス・サービスの構成

次の表に、ビジネス・サービス用のSFTPトランスポートの構成に使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

表29-14 ビジネス・サービス用のSFTPトランスポート・プロパティ

プロパティ

説明

ユーザー認証

必要な認証方式を次から選択します。

- 「ユーザー名パスワード」認証: 静的なサービス・アカウントがこの認証方式に関連付けられ、クライアントは提供した資格証明によって認証されることを指定します。

- 「ホスト・ベース」認証: この認証方式を使用するためにユーザー名とサービス・キー・プロバイダが必要になることを指定します。既知のホストから接続するユーザーは、ホストの秘密鍵を使用して認証されます。

- 「公開鍵」認証: この認証方式を使用するためにユーザー名とサービス・キー・プロバイダが必要になることを指定します。各ユーザーは固有の秘密鍵を持っています。

注意: Service Busサービスは、SFTPサーバーからの資格証明を認証するために、サービス・キー・プロバイダを使用することはありません。SFTPサーバーを認証する場合、「SFTPトランスポートのトランスポート・レベルでのセキュリティの構成」に示すとおり、known_hostsファイルのみを使用します。

サービス・アカウント

サーバーにアクセスするための認証に使用するサービス・アカウントを入力します。サービス・アカウントの使用については、「サービス・アカウントの操作」を参照してください。

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

認証に使用するサービス・キー・プロバイダを入力します。

このフィールドは、公開鍵認証方式とホスト・ベース認証方式にのみ使用できます。詳細は、「サービス・キー・プロバイダの操作」を参照してください。

ユーザー名

ユーザー名を入力します。この値は、ホスト・ベース認証方式または公開鍵認証方式を選択した場合にのみ必要です。

- ホスト・ベース認証では、SFTPサーバー上のユーザーのホーム・ディレクトリをポーリングするためにユーザー名が必要となります。

- 公開鍵認証では、ユーザーのホーム・ディレクトリのポーリングとSFTPサーバー上の公開鍵の場所の識別にユーザー名が必要となります。

タイムアウト

接続が切断されるまでのソケット・タイムアウト間隔を秒単位で入力します。「0」を入力すると、タイムアウトは発生しません。デフォルト値は60です。

宛先ファイル名の接頭辞

トランスポートによってリモート・サーバー上のファイル名の先頭に付加される、省略可能な接頭辞を入力します。

このフィールドには「*」を入力できません。この文字を入力すると、実行時例外が発生します。

宛先ファイル名の接尾辞

トランスポートによってリモート・サーバー上のファイル名の末尾に付加される、省略可能な接尾辞を入力します。

このフィールドには「*」を入力できません。この文字を入力すると、実行時例外が発生します。

Tmpファイル接尾辞

転送時に使用される一時ファイルに付ける接尾辞を入力します。デフォルト値は_tmpです。

所有者のファイル権限

該当する場合は、UNIX/LinuxタイプFTPサーバーの明示的ファイル権限を設定します。この設定は、chmodをサポートしないサーバー・タイプでは無視されます。

グループのファイル権限

該当する場合は、UNIX/LinuxタイプFTPサーバーの明示的ファイル権限を設定します。この設定は、chmodをサポートしないサーバー・タイプでは無視されます。

その他のファイル権限

該当する場合は、UNIX/LinuxタイプFTPサーバーの明示的ファイル権限を設定します。この設定は、chmodをサポートしないサーバー・タイプでは無視されます。

リクエストのエンコーディング

SFTPトランスポートでは、リクエストの文字セット・エンコーディングとしてデフォルトのUTF-8を受け入れます。

FIPS準拠の有効化

SFTP接続のFIPS (連邦情報処理標準)準拠を有効化します。有効にすると、FIPS準拠の公開鍵および鍵交換アルゴリズムが有効になり、「優先公開鍵アルゴリズム」および「優先鍵交換アルゴリズム」リストで選択可能になります。互換性のないアルゴリズムは無効で選択できません。

優先暗号スイート

サーバーと通信する際に使用する暗号スイートを選択します。使用する暗号スイートにより、ネットワーク接続の認証と暗号化に関する設定が決まります。

デフォルト値「実行時のデフォルトの使用」を使用すると、サポートされる暗号スイートのリストがサーバーに送信され、一致が検出されるまで各暗号スイートが試行されます。

優先データ整合性アルゴリズム

データ整合性チェックに使用するバルク・ハッシュ・アルゴリズムを、使用可能なオプションのリストから選択します。

デフォルト値の実行時のデフォルトの使用を使用すると、Service Busによって優先アルゴリズムhmac-sha1が送信されます。サーバーでこれがサポートされない場合は、サポートされるアルゴリズムのリストがサーバーに送信され、一致が検出されるまで各アルゴリズムが試行されます。

優先公開鍵アルゴリズム

公開鍵暗号化に使用する非対称鍵アルゴリズムを、使用可能なオプションのリストから選択します。

デフォルト値の実行時のデフォルトの使用を使用すると、Service Busによって優先アルゴリズムssh-dssが送信されます。サーバーでこれがサポートされない場合は、サポートされるアルゴリズムのリストがサーバーに送信され、一致が検出されるまで各アルゴリズムが試行されます。

「FIPS準拠の有効化」オプションが選択されると、ランタイム・デフォルトが変わります。デフォルト値ランタイム・デフォルトの使用を使用すると、Oracle Service Busによって優先アルゴリズムssh-rsaが送信されます。サーバーでこれがサポートされない場合は、サポートされるアルゴリズムのリストがサーバーに送信され、一致が検出されるまで各アルゴリズムが試行されます。

優先鍵交換アルゴリズム

メッセージの暗号化のためのセッション鍵のネゴシエーション用として、デフォルトの鍵交換プロトコルを選択します。

デフォルト値の実行時のデフォルトの使用を使用すると、Service Busによって優先アルゴリズムdiffie-hellman-group1-sha1が送信されます。サーバーでこれがサポートされない場合は、サポートされるアルゴリズムのリストがサーバーに送信され、一致が検出されるまで各アルゴリズムが試行されます。

「FIPS準拠の有効化」オプションが選択されると、ランタイム・デフォルトが変わります。デフォルト値のランタイム・デフォルトの使用を使用すると、Oracle Service Busでは優先的にdiffie-hellman-group14-sha1アルゴリズムが送信されます。サーバーでこれがサポートされない場合は、サポートされるアルゴリズムのリストがサーバーに送信され、一致が検出されるまで各アルゴリズムが試行されます。

優先圧縮アルゴリズム

処理中のデータをzlibを使用して圧縮するかどうかを選択します。データを圧縮するには「zlib」または「zlib@openssh.com」を、それ以外の場合は「なし」を選択します。デフォルトは、Noneです。

29.6.9.6 SFTPトランスポートの環境値

環境値は、ドメイン固有の構成データに含まれる定義済のフィールドです。これらの値は、ドメイン間で構成を移動するとき(テスト環境から本番環境への移動など)に変更される可能性があります。SFTPトランスポートに関連付けられた環境値を次の表に示します。

表29-15 SFTPトランスポートの環境値

環境値

説明

SFTPアーカイブ・ディレクトリ

SFTPプロキシ・サービスのアーカイブ・ディレクトリ。ダイレクト・ストリーミングがオンの場合、このアーカイブ・ディレクトリはリモートSFTPサーバーに存在し、それ以外の場合はローカルに存在します。

SFTPダウンロード・ディレクトリ

SFTPプロキシ・サービスのダウンロード・ディレクトリ。

SFTPエラー・ディレクトリ

SFTPプロキシ・サービスのエラー・ディレクトリ。ダイレクト・ストリーミングがオンの場合、このエラー・ディレクトリはリモートSFTPサーバーに存在し、それ以外の場合はローカルに存在します。

ポーリングの管理対象サーバー

クラスタ・ドメイン内のポーリング用管理対象サーバー。

SFTP優先暗号スイート

SFTPプロキシ・サービスおよびビジネス・サービスでの認証と暗号化に使用する暗号スイート。

SFTP優先圧縮アルゴリズム

SFTPプロキシ・サービスおよびビジネス・サービスで処理中のデータの圧縮に使用する圧縮ライブラリ。

SFTP優先データ整合性アルゴリズム

SFTPプロキシ・サービスおよびビジネス・サービスでの整合性チェックに使用するバルク・ハッシュ・アルゴリズム。

SFTP優先鍵交換アルゴリズム

SFTPプロキシ・サービスおよびビジネス・サービスでメッセージの暗号化に使用するセッション鍵をネゴシエートするためのデフォルトの鍵交換プロトコル。

SFTP優先公開鍵アルゴリズム

SFTPプロキシ・サービスおよびビジネス・サービスでの公開鍵暗号化に使用する非対称鍵アルゴリズム。

環境変数とSFTP変数の詳細は、次を参照してください。

- 『Oracle Service Busの管理』のOracle Service Bus環境のカスタマイズに関する項

- SFTPトランスポートを使用するプロキシ・サービスの構成

- SFTPトランスポートを使用するビジネス・サービスの構成

30 JEJBトランスポートの使用

この章では、JEJBトランスポートの概要と、Service Busでトランスポートを使用してPlain Old Java Object (POJO)を処理する方法について説明します。

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

- JEJBトランスポートの概要

- JEJBサービスを作成するための前提条件

- 使用例

- UDDI統合

- JEJBトランスポート構成のリファレンス

30.1 JEJBトランスポートの概要

JEJBトランスポートを使用すると、Service Busを介してPlain Old Java Object (POJO)を渡すことができます。たとえば、EJBを使用してリモートEJB操作または非EJBサービスを呼び出すことができます。または、非EJBリクエストでEJB操作を呼び出すことができます。詳しい使用例を「使用例」で説明します。

J2EEクライアントに対して、JEJBプロキシ・サービスはステートレス・セッションBeanのように見えます。JEJBプロキシ・サービスは、メソッド引数を受け取ると、そのXML表現をパイプラインの$body変数に渡します。POJO引数は、パイプライン内のオブジェクト・リポジトリに格納された実際のPOJOの場所を含む、XMLフラグメントとして表されます。XML引数は、値または参照(オブジェクト・リポジトリに格納される実際のオブジェクトを参照する)として渡すことができます。プリミティブ型は常に値として渡されます。

パイプライン内のPOJOの詳細は、「body変数内のJavaコンテンツ」および「JavaコールアウトおよびPOJOの使用方法」を参照してください。

JEJBトランスポートは常に非同期であり、メッセージング・パターンはリクエスト/レスポンスです。デプロイメントに際して、Service BusはJEJBプロキシ・サービスをエンタープライズ・アーカイブ(EAR)として自動的にパッケージ化します。

30.1.1 JEJBトランスポートとEJBトランスポートの相違点

EJBトランスポート(ビジネス・サービスのみに対応)は、Java Web Services (JWS)フレームワークを介してリモートEJBをよびだします。JEJBトランスポート(リモートEJBや外部サービスをPOJOを使用して呼び出すことができる)は、RMIシリアライゼーション/デシリアライゼーション・サイクルを使用して、Service Busを介してターゲットEJBメソッドにPOJOを直接渡します。EJBトランスポートには「トランザクションをサポートする」フラグがありますが、すべてのプロキシ・サービスでトランザクションのサポートが提供されるため、JEJBビジネス・サービスではトランザクション・オプションが必要ありません。

30.1.2 JEJBトランスポートによるWSDLの生成

プロキシ・サービスとビジネス・サービスのために、JEJBトランスポートは、パイプラインに渡すメッセージを記述するためだけに使用されるリテラル・エンコーディングのドキュメント形式WSDLファイルを生成します。このWSDL形式を使用すると、Service BusのWSDL機能(操作ごとのモニターなど)を利用できます。表30-1で説明するように、「値でXMLBeansを渡す」オプションを使用してPOJO引数をメッセージにインライン指定すると、WSDLファイルに定義されるメッセージ構造は、実行時の実際のパイプライン・メッセージと異なる可能性があります。

XMLBeansパラメータ・タイプに対するパイプライン・メッセージ・フォーマットの動作は次のとおりです。

プロキシ・サービス

- リクエスト・パラメータ: 「値でXMLBeansを渡す」がtrueの場合、パイプライン・メッセージのリクエスト・パラメータはインラインXMLオブジェクトを参照します。これ以外の場合は、java-content refを参照します。

- レスポンス・パラメータ: レスポンスはビジネス・サービスのいずれかの形式に基づくため、レスポンスはインラインXMLオブジェクトまたはjava-content refを参照します。

ビジネス・サービス

- レスポンス・パラメータ: 「値でXMLBeansを渡す」がtrueの場合、パイプライン・メッセージの戻りパラメータはインラインXMLオブジェクトを参照します。そうでない場合は、java-content refを参照します。

- リクエスト・パラメータ: リクエストはプロキシ・サービスのいずれかの形式に基づくため、パイプライン・メッセージのリクエスト・メソッド・パラメータは、インラインXMLオブジェクトまたはjava-content ref,を参照できます。

30.1.3 JEJBトランスポートのエラー処理

ここでは、JEJBトランスポートがどのようにエラーを処理するかを説明します。

- レスポンスでの例外の伝播

- アプリケーション・エラーおよび接続エラー

30.1.3.1 レスポンスでの例外の伝播

JEJBトランスポートは、リクエスト例外をオブジェクト・リポジトリに格納し、$fault変数を介してJEJBプロキシ・サービスに伝播します。$fault変数には、<java-exception> <java-content ref="jcid"/> </java-exception>要素(jcidはオブジェクト・リポジトリに格納されている例外インスタンスへの参照)内の例外インスタンスの場所が含まれます。

JEJBプロキシ・サービスでユーザー例外をクライアントに伝播するには、レスポンスが次のいずれかの形式であることが必要です。jcidは常に、オブジェクト・リポジトリ内のエラーへの参照です。

- env:Envelope/env:Fault/detail/mc:java-exception

<detail>
<mc:java-exception>
<mc:java-content ref="jcid"/>
</mc:java-exception>
...
</detail>

- env:Envelope/env:Fault/detail/mc:fault/mc:java-exception

<detail>
<mc:fault xmlns:mc="http://www.bea.com/wli/sb/context">
<mc:java-exception>
<mc:java-content ref="jcid"/>
</mc:java-exception>
...
</mc:fault>
</detail>

- env:Envelope/ env:Fault/detail/mc:fault/mc:details/con1:ReceivedFaultDetail/con1:detail/mc:java-exception

<con:details>
<con1:ReceivedFaultDetail
xmlns:con1="http://www.bea.com/wli/sb/stages/transform/config">
<con1:faultcode>soapenv:Server</con1:faultcode>
<con1:faultstring>checkExceptionConversion</con1:faultstring>
<con1:detail>
<mc:java-exception>
<mc:java-content ref="jcid"/>
</mc:java-exception>
</con1:detail>
</con1:ReceivedFaultDetail>
</con:details>

独自の例外を生成して呼出し元に戻す場合は、パイプラインのJavaコールアウトで例外を生成します。

失敗時の返信のためにエラー・ハンドラでJavaコールアウトまたはサービス・コールアウトを構成する場合、前に説明したフォルト構文のいずれかに従って$bodyを指定します。

30.1.3.2 アプリケーション・エラーおよび接続エラー

ここでは、JEJBトランスポートによって、サービスの再試行構成の対象であるアプリケーション・エラーと接続エラーがスローされる条件を説明します。

- 接続エラー

- アプリケーション・エラー

30.1.3.2.1 接続エラー

JEJBトランスポートでは、次の場合に接続エラーがスローされます。

- リモート・コール時に発生したEJBをルックアップしている際のNamingExceptions。

- 実行時例外またはリモート例外がスローされるが、継続中のトランザクションが「ロールバックのみ」に設定されておらず、EJBコンテナの呼出し前にエラーが発生したことがわかる状況。

30.1.3.2.1.1 アプリケーション・エラー

JEJBトランスポートでは、次の場合にアプリケーション・エラーがスローされます。

- 実行時例外またはリモート例外がスローされ、継続中のトランザクションが(一般的にEJBコンテナによって)「ロールバックのみ」に設定されており、EJBコンテナが影響を受け、EJBコンテナまたはEJBそのもののいずれかで致命的なエラーが発生したことを意味する状況。

- EJBビジネス・インタフェースで定義されているビジネス例外。

- XMLのパラメータの誤ったエンコーディングによる例外。

30.2 JEJBサービスを作成するための前提条件

この項では、JEJBのプロキシ・サービスとビジネス・サービスを作成する前に知っておく必要があることについて説明します。

- クライアントEJB JARファイルの作成とパッケージ化

- JNDIプロバイダ・リソースの登録(ビジネス・サービス)

30.2.1 クライアントEJB JARファイルの作成とパッケージ化

JEJBサービスを使用する場合、JEJBのプロキシ・サービスとビジネス・サービスに関して、EJBの呼出しと操作を表すPOJOを作成し、パッケージ化する必要があります。次のガイドラインに従います。

- タイプjava.io.Serializableのインタフェースを定義し、必要なヘルパー・クラス(ビジネス例外など)を組み込みます。このインタフェースが「JEJBトランスポートのエンドポイントURI」で説明するRMIプロトコルの1つに対して有効である場合、またはJMSメッセージに対して有効である場合(EJBを呼び出すためにJMSを使用しているとき)、クラスを拡張する必要はありません。
必須ではありませんが、インタフェースをEJB 2.1仕様の定義に従ってリモート・インタフェースにしたり、メソッドをjavax.ejb.Remote注釈で注釈付けして、そのメソッドをEJB 3.0ビジネス・インタフェースとして指定できます。単純なPOJOインタフェース(EJBリモート・インタフェース以外)またはjavax.ejb.Remote注釈を含むインタフェースの場合、JEJBトランスポート・プロバイダはJEJBプロキシ・サービスから3.0 EJBインタフェースを生成します。リモート・インタフェースの場合、JEJBトランスポート・プロバイダはJEJBプロキシ・サービスから2.1 EJBインタフェースを生成します。

- 引数として受信されるオブジェクトは、Javaコールアウト・アーカイブ・リソースのいずれかの必須クラスに渡される必要があります。

- すべてのタイプのすべての配列はPOJOとみなされます。

- 不要なシリアライゼーション/デシリアライゼーション・サイクルを回避するために、JavaコールアウトをサポートするService Busアーカイブ・リソースとしてアップロードされるJARファイルを複製しないようにします。すべてのアーカイブ・リソース・クラスを1つのJARファイルにパッケージ化して、複数のJavaコールアウトがオブジェクトのシリアライゼーション/デシリアライゼーションを行わないようにします。

- インタフェースと依存クラスを1つのクライアントJARファイルにパッケージ化し、そのJARファイルをService Busにインポートします。これはサービスを構成するときに選択するクライアントJARファイルですが、スタブを含まないため、技術的には完全に展開されたEJBクライアントJARファイルではありません。JEJBプロキシ・サービスが作成されてアクティブ化されるまでは、実際のBean (WebLogic Serverスタブ生成)は存在しません。

30.2.2 JNDIプロバイダ・リソースの登録(ビジネス・サービス)

JNDIプロバイダ・リソースでは、リモートOracle WebLogic ServerドメインのJNDIツリーにバインドされているEJBスタブを取得するために使用される通信プロトコルおよびセキュリティ資格証明を指定できます。通常、ターゲットEJBはService Busと同じドメイン内にはありません。この場合、JNDIプロバイダ・リソースを登録する必要があります。EJBが同じドメイン内にある場合、プロバイダを定義して資格証明を指定し、スタブ・キャッシングを利用できます。ただし、これは省略可能です。

JNDIプロバイダには、リモート接続とEJBスタブのための高性能なキャッシング・メカニズムがあります。Service BusからOracle WebLogic Serverドメインへの推奨される通信プロトコルは、t3またはt3sです。メッセージがファイアウォールを通過する必要がある場合は、HTTPトンネリングを使用できます。

注意:

WebLogic Serverの外部JNDIプロバイダを使用できますが、使用しないことをお薦めします。

このトランスポートでは、双方向SSLまたはクライアント証明書によるJNDIツリーのルックアップまたはEJBのメソッドへのアクセスをサポートしません。

Service BusへのJNDIプロバイダ・リソースの登録と構成の詳細は、「JNDIプロバイダ・リソースの操作」を参照してください。

30.3 使用例

プロキシ・サービスとビジネス・サービスでのJEJBトランスポートの使用がサポートされている使用例を次に示します。各使用例には実装のガイドラインが含まれており、「JEJBトランスポート構成のリファレンス」の全般的なサービス構成と組み合せて使用できます。

- 外部サービスを呼び出すEJB

- EJBを呼び出す非EJBクライアント

- EJBを呼び出すEJB

30.3.1 外部サービスを呼び出すEJB

図30-1に示すように、Service Busを介してEJBで外部サービスを呼び出すことができます。

図30-1 外部サービスを呼び出すEJB

図30-1では、JEJBプロキシ・サービスはEJBクライアント・インタフェースに対してステートレス・セッションBeanとして機能します。プロキシ・サービスのJEJBトランスポート・プロバイダは、クライアントJARとパイプラインのリモート/ビジネス・インタフェースからステートレス・セッションEJBを生成します。次に、エンドポイントURIに指定されたJNDIアドレスにEARとしてデプロイします。

注意:

JNDIエントリが変更されないように保護するポリシーをインストールしてください。

EJBは、プロキシ・サービスEJBクライアントJARによって提供されるリモート・インタフェースをコールし、トランザクションとセキュリティの詳細をプロキシ・サービスに渡します。

EJBクライアント・インタフェースはPOJOであり、その引数はJEJBトランスポート・プロバイダがWSDLファイルとして表し、プロキシ・サービスの$body変数にXMLとして渡します。$bodyコンテンツのイントロスペクションを実行して、メッセージを必要な形式に変換してから、ビジネス・サービスに渡し、外部サービスを呼び出すことができます。実際のPOJOはオブジェクト・リポジトリに格納され、$bodyのXMLが<java-content ref="">要素で参照します。

レスポンスでは、呼出し元のEJBメソッドに渡すために、レスポンスをEJB戻り形式に変換するJavaコールアウトを提供します。プロキシ・サービスの生成されたWSDLファイルを表示して、予期されるメッセージ・フォーマットを確認します。

注意:

プロキシ・サービスのパイプラインで、Javaコールアウト、ビジネス・サービスまたは別のプロキシ・サービス(サービス・コールアウトまたはパブリッシュ・アクションを使用)にPOJO引数を渡すことができます。

30.3.2 EJBを呼び出す非EJBクライアント

図30-2に示すように、Service Busを介して非EJBクライアントでEJBを呼び出すことができます。

図30-2 EJBを呼び出す非EJBクライアント

図30-2では、非EJBクライアントが、リクエストと一致するトランスポートで構成されたプロキシ・サービス(たとえば、JMSトピックまたはキューで呼び出すJMSプロキシ・サービス)を呼び出します。

リクエストでJavaコールアウト(リクエストを$body変数のEJBコールのXML表現に変換する)を構成します。操作を$operation変数に設定します。ビジネス・サービスの生成されたWSDLファイルを表示して、予期されるメッセージ・フォーマットを確認します。JEJBビジネス・サービスは、生成されたWSDLファイルを使用して着信メッセージをEJBリモート・インタフェースにマップし、リモートEJBメソッドを直接呼び出します。

30.3.3 EJBを呼び出すEJB

図30-3に示すように、Service Busを介してEJBでEJBを呼び出すことができます。

図30-3 EJBを呼び出すEJB

図30-3では、EJBコールはプロキシ・サービスとビジネス・サービスを介して渡され、別のEJBメソッドを呼び出します。Service Busの外部に直接RMIコールを行うかわりに、このアーキテクチャではService Busの機能(メッセージ・ルーティング、UDDI統合、アラート、モニター、レポート、結果キャッシングなど)を利用します。

プロキシ・サービスのJEJBトランスポート・プロバイダは、クライアントJARファイルとパイプラインのリモート/ビジネス・インタフェースからステートレス・セッションEJBを生成します。次に、エンドポイントURIに指定されたJNDIアドレスにEARファイルとしてデプロイします。

実行時に、JEJBプロキシ・サービスはPOJOをメソッドの引数として受け取ってオブジェクト・リポジトリに格納し、生成されたプロキシ・サービスWSDLファイルに基づいて、プロキシ・サービスの$body変数にPOJOのXML表現を生成します。プロキシ・サービスはメッセージをビジネス・サービスに渡します。ビジネス・サービスは、生成されたWSDLファイルを使用してメッセージをリモート・インタフェースにマップし、リモート・メソッドを直接呼び出します。

30.4 UDDI統合

JEJBプロキシ・サービスのプロパティは、UDDIレジストリとの間でパブリッシュおよびインポートできます。

- UDDI公開

- UDDIのインポート

30.4.1 UDDI公開

JEJBプロキシ・サービスは次のプロパティをUDDIレジストリにパブリッシュします。

- URI

- EJB仕様バージョン

- クライアントJar

- ホーム・インタフェース(EJB 2.1のみ)

- リモート・インタフェース(EJB 3.0のビジネス・インタフェース)

- メソッド名。操作別名、パラメータおよび戻り値の詳細は含まれません。メソッド名は、すべてのメソッド・シグネチャが付けられた1つのプロパティで渡されます。メソッド・シグネチャは番号(#)記号で区切られます。

30.4.2 UDDIのインポート

ここでは、JEJBトランスポートがUDDIレジストリからのサービス・インポートを処理する方法を説明します。

- URI: JEJBトランスポート・プロバイダは、UDDIレジストリにあるURIプロパティのホストおよびポート情報を、サーバーに登録されているJNDIプロバイダ・リソースと照合しようとします。
トランスポート・プロバイダがJNDIプロバイダを見つけられない場合、インポートは失敗します。ただし、JNDIプロバイダが見つからなくても、ホストおよびポートがlocalhostのIPとリスニング・ポートと一致する場合、結果のビジネス・サービスはローカルになります(JNDIプロバイダではありません)。

- クライアントJAR: トランスポート・プロバイダがクライアントJARファイルをダウンロードし、マニフェスト・クラスパスがJARファイルに存在する場合は、対応するJARリソースを同じディレクトリ構造に作成します。リストの最初のURIがルート・クライアントJARファイルです。JARファイルにマニフェスト・クラスパスが存在しない場合は、リソースJARファイルをルートJARファイルに手動で追加する必要があります。インポートされたクライアントJARファイルのリソースが、ドメインの別のリソースと同じ名前である場合、インポートされたリソースによって既存のリソースが上書きされます。
インポートするクライアントJARファイルがドメインに存在していないことを確認します。

- メソッド名: 対応するプロパティに含まれるメソッドは、エンドポイントの構成で自動的に選択されます。他のすべてのメソッドは除外としてマークされます。

30.5 JEJBトランスポート構成のリファレンス

この項では、エンドポイントURIの形式と環境値、およびプロキシ・サービスとビジネス・サービスにおけるJEJBトランスポートの構成について説明します。

- JEJBトランスポートのエンドポイントURI

- JEJBトランスポートを使用するプロキシ・サービスの構成

- ビジネス・サービスの構成

- JEJBトランスポートの環境値

30.5.1 JEJBトランスポートのエンドポイントURI

エンドポイントURIの形式は、プロキシ・サービスとビジネス・サービスのどちらを構成するかによって異なります。

注意:

JEJBサービスでは同じ場所に配置した呼出しはサポートされません。

- プロキシ・サービスのJEJBエンドポイントURI

- ビジネス・サービスのJEJBエンドポイントURI

30.5.1.1 プロキシ・サービスのJEJBエンドポイントURI

JEJBプロキシ・サービスに対して構成されるURIは、JEJBトランスポートによって生成されるステートレス・セッションBeanをクライアントJARのリモート/ビジネス・インタフェースで探すためのグローバルJNDI名になります。URL形式はejb_jndi_name.です。

注意:

EJB 3.0の場合、ejb_jndi_nameは生成されるBeanの@javax.ejb.Stateless注釈のmappedName属性です。生成されるEJBサービスのルックアップJNDI名の接尾辞は#interface_classであり、これはビジネス・インタフェースの完全修飾名です。

次のようにJEJBプロキシ・サービスにアクセスできます。

- EJB 2.1: protocol://host:port/ejb_jndi_name

- EJB 3.0: protocol://host:port/ejb_jndi_name#interface_class

protocolは次のRMIプロトコルのいずれかです。

- iiop/iiops:サーバーにとらわれない汎用プロトコルです。

- t3/t3s: Oracle WebLogic Serverで使用されます。

- http/https: トンネリングおよびOracle WebLogic Serverで使用します。

次に例を示します。

- EJB 2.1: t3://localhost:7001/osb.jejb.myJejbProxy

- EJB 3.0: t3://localhost:7001/osb.jejb.myJejbProxy#com.example.MyEjb3

30.5.1.2 ビジネス・サービスのJEJBエンドポイントURI

JEJBのビジネス・サービスのエンドポイントURIには、次の形式を使用します。

jejb:jndi_provider_name:ejb_jndi_name

jndi_provider_nameはリモートJNDIコンテキスト、ejb_jndi_nameはリモートEJBのJNDI名です。

次に例を示します。

- EJB 2.1: jejb:myProvider:osb.jejb.myJejbBiz21

- EJB 3.0: jejb:myProvider:myBiz31#osb.jejb.myJejbBiz
ここで、#osb.jejb.myJejbBizは完全修飾されたビジネス・インタフェースです。

EJBがIBM WebSphere上で実行中の場合は、ejb_jndi_nameを次のいずれかの形式にしてください。

- cell/nodes/node_name/servers/server_name/ejb_jndi_name
または

- cell/clusters/cluster_name/ejb_jndi_name

詳細は、IBM WebSphereのドキュメントを参照してください。

30.5.2 JEJBトランスポートを使用するプロキシ・サービスの構成

次の表に、プロキシ・サービス用のJEJBトランスポートの構成に使用するプロパティを示します。プロキシ・サービスを作成する手順については、「プロキシ・サービスの作成と構成」を参照してください。

表30-1 プロキシ・サービス用のJEJBトランスポート・プロパティ

プロパティ

説明

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

EJB仕様バージョン

リモートEJBインタフェースのEJBバージョンを選択します。

値でXMLBeansを渡す

トランスポートによってPOJO引数(XMLObject)のインラインXML表現を生成する場合は、このオプションを選択します。この引数のパラメータは、XQuery式でアクセスおよび操作できます。

注意: 値で渡されたXMLObjectの場合、型情報はインラインでは利用できません。このオプションを使用する場合、プロキシ・サービス・パイプラインのJavaコールアウトで型付きのXMLObjectを引数として渡すことはできません。

参照でPOJOを渡す場合は、このオプションを選択しないでください。こうすることでパフォーマンスも向上します。

詳細は、「JEJBトランスポートによるWSDLの生成」を参照してください。

トランザクション属性

トランザクションを処理するために次のいずれかのオプションを選択します。

- Supports: トランスポートは着信トランザクションを受け入れます。サービス品質は、操作がトランザクションで呼び出される場合は「必ず1回」、操作がトランザクション外部から呼び出される場合は「ベスト・エフォート」です。

- Required: トランスポートは着信トランザクションを受け入れます。発信トランザクションが存在しない場合、トランスポートが発信トランザクションを開始します。サービス品質は「必ず1回」です。

- RequiresNew: トランスポートは常に新しいトランザクションを開始し、進行中のトランザクションを中断します。サービス品質は「必ず1回」です。

- Mandatory: トランスポートは既存のトランザクションのメソッドを呼び出します。サービス品質は「必ず1回」です。

- NotSupported: トランスポートは既存のトランザクションを中断し、呼出し時に再開します。サービス品質は「ベスト・エフォート」です。

- Never: トランスポートはトランザクションのメソッドを呼び出しません。サービス品質は「ベスト・エフォート」です。

リモート・クライアント・タイムアウト

リモートRMIクライアントがタイムアウトまでに待機する時間の長さを秒数で指定します。

クライアントJar

「参照」をクリックし、表示されるリストからEJBクライアントJARリソースを選択します。クライアントJARには、リモートEJBのリモートまたはビジネス・インタフェースが含まれます。クライアントJARは、汎用アーカイブ・リソースとして登録されます。

ホーム・インタフェース

EJB 2.1専用。クライアントJARによって設定されるオプションから必須のEJBHomeインタフェースを選択します。

リモート・インタフェース

EJB 2.1専用。このフィールドには、ホーム・インタフェースの構成に基づいて、自動的に情報が表示されます。

ビジネス・インタフェース

EJB 3.0専用。クライアントJARファイルから呼び出すビジネス・インタフェースを選択します。

対象ネームスペース

生成されるWSDLファイルのターゲット・ネームスペース。このフィールドにはJARからピックアップされた情報が自動的に移入されます。

メソッド

使用可能なメソッドのリストから、必要なメソッドを選択します。使用可能なメソッドは、使用するJARファイルによって異なります。デフォルトでは、すべてのメソッドが選択されています。メソッドを開くと、デフォルトのパラメータ値を編集できます。

任意のメソッドのデフォルトの操作名を変更できます。デフォルトでは、操作名はメソッド名です。EJBに同じ名前のメソッドが含まれている場合(オーバーロード)、一意になるように操作名を変更する必要があります。WSDLファイルでは一意の操作名が必要です。

30.5.3 ビジネス・サービスの構成

次の表に、ビジネス・サービス用のJEJBトランスポートの構成に使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

表30-2 ビジネス・サービスのためのJEJBトランスポート構成

オプション

説明

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

EJB仕様バージョン

リモートEJBインタフェースのEJBバージョンを選択します。

値でXMLBeansを渡す

トランスポートによってPOJO引数(XMLObject)のインラインXML表現を生成する場合は、このオプションを選択します。この引数のパラメータは、XQuery式でアクセスおよび操作できます。

注意: 値で渡されたXMLObjectの場合、型情報はインラインでは利用できません。このオプションを使用する場合、プロキシ・サービス・パイプラインのJavaコールアウトで型付きのXMLObjectを引数として渡すことはできません。

参照でPOJOを渡す場合は、このオプションを選択しないでください。こうすることでパフォーマンスも向上します。

参照でPOJOを渡す場合は、このオプションを選択しないでください。こうすることでパフォーマンスも向上します。

詳細は、「JEJBトランスポートによるWSDLの生成」を参照してください。

呼出し元のサブジェクトを渡す

このオプションは、サービス・アカウントを選択するかわりの手段として選択します。このオプションを選択すると、EJBを呼び出すときに、Service Busがプロキシ・サービスの認証済サブジェクトを渡します。

サービス・アカウント

サービスにアクセスするための認証に使用するサービス・アカウントを入力します。サービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。Basic認証を選択した場合、このフィールドは必須です。

詳細は、「サービス・アカウントの操作」を参照してください。

クライアントJar

「参照」をクリックし、表示されるリストからEJBクライアントJARリソースを選択します。クライアントJARには、リモートEJBのリモートまたはビジネス・インタフェースが含まれます。クライアントJARは汎用アーカイブ・リソースとして登録されます。

ホーム・インタフェース

EJB 2.1専用。クライアントJARによって設定されるオプションから必須のEJBHomeインタフェースを選択します。

リモート・インタフェース

EJB 2.1専用。このフィールドには、ホーム・インタフェースの構成に基づいて、自動的に情報が表示されます。

ビジネス・インタフェース

EJB 3.0専用。クライアントJARファイルから呼び出すビジネス・インタフェースを選択します。

対象ネームスペース

生成されるWSDLファイルのターゲット・ネームスペース。このフィールドにはJARからピックアップされた情報が自動的に移入されます。

メソッド

使用可能なメソッドのリストから、必要なメソッドを選択します。使用可能なメソッドは、使用するJARファイルによって異なります。デフォルトでは、すべてのメソッドが選択されています。メソッドを開くと、デフォルトのパラメータ値を編集できます。

任意のメソッドのデフォルトの操作名を変更できます。デフォルトでは、操作名はメソッド名です。EJBに同じ名前のメソッドが含まれている場合(オーバーロード)、一意になるように操作名を変更する必要があります。WSDLファイルでは一意の操作名が必要です。

30.5.4 JEJBトランスポートの環境値

JEJBトランスポートでは、JEJBサービスのために次の環境値が格納されています。

- サービスURI

- ワーク・マネージャ

- UDDI自動パブリッシュ(プロキシ・サービス)

- サービス・アカウント(ビジネス・サービス)

これらの値は、ビジネス・サービスとプロキシ・サービスのトランスポート・プロパティに対応しています。詳細は、「JEJBトランスポート構成のリファレンス」を参照してください。

31 JMSトランスポートの使用

この章では、JMSトランスポートの概要と、Service Busサービスでの使用および構成方法について説明します。また、Service BusとWebLogic JMS間、およびService BusとWebSphere MQ間の相互運用性に関連する機能および概念についても説明します。

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

- JMSトランスポートの概要

- SOAP Over JMSトランスポートの使用

- ドメイン、サーバーおよびURIの命名ガイドライン

- プロキシ・サービスでのJMSクライアントID

- JMSトランスポートのエラー処理

- WSDL定義のSOAPフォルト・メッセージ

- JMSリクエスト/レスポンスのメッセージIDと相関IDのパターン

- JMSトランスポート構成のリファレンス

31.1 JMSトランスポートの概要

JMSトランスポートでは、JMSサービスのJMSキューとトピックからメッセージを送受信できます。JMSトランスポートを使用するようにビジネス・サービスを構成する場合はメッセージをエンキューして、JMSトランスポートを使用するようにプロキシ・サービスを構成する場合はメッセージを読み取ります(またはポーリングします)。JMSキューまたはトピックは、ローカルWebLogic Serverまたはリモート・サーバーに存在できます。

JMSは、エンタープライズ・メッセージング・システムにアクセスするための標準APIです。WebLogic JMSの概要と機能については、『Oracle WebLogic Server JMSリソースの管理』のJMSとWebLogic Serverの概要に関する項を参照してください。

31.1.1 サービスのJMSコンテンツ・タイプ

Service Busでは、異種のエンドポイント間での相互運用性を確保するため、使用されるコンテンツ・タイプ、JMSタイプおよびエンコーディングをメッセージ・フローの構成時にそれぞれ制御できます。JMSタイプはバイトまたはテキスト(非Javaタイプ・メッセージの場合)のいずれかです。詳細は、「コンテンツ・タイプ、JMSタイプ、およびエンコーディング」を参照してください。

31.1.2 JMSトランスポートのセキュリティ

JMSトランスポートでは、一方向SSLはサポートされますが、双方向SSLはサポートされません。

31.1.3 非同期のリクエスト/レスポンス・メッセージング

メッセージングは、一方向、同期型のリクエスト/レスポンスまたは非同期のリクエスト/レスポンスのいずれかです。ただし、JMSでのメッセージングは、一方向または非同期のリクエスト/レスポンスのみです。JMSを使用した非同期のリクエスト/レスポンス・メッセージングは、HTTPまたはHTTPSを使用したメッセージングにかわるものです。

非同期のリクエスト/レスポンス・メッセージングを使用する利点は次のとおりです。

- レスポンスを待機する間、リクエスト・スレッドがブロックされることはありません。これにより、多数のブロッキング・リクエスト/レスポンス呼出しが行われた場合に生じる可能性のある、スレッドの管理上の問題が解消されます。ただし、HTTPとHTTP(S)は、操作の非ブロッキング・モードをサポートしています。

- メッセージングは次が可能であるため、HTTPよりも信頼できます:

- ディスク上に保持される

- サービスを利用できないときに、キューに格納される

- メッセージの処理時にサーバーにエラーや障害が発生した場合、メッセージを再配信できます。

- トランザクション

IBM WebSphere MQの場合、特定のメインフレームとの対話には非同期のリクエスト/レスポンス・メッセージを使用することをお薦めします。非同期サービスは、使用するJMSリクエスト/レスポンス・パターンに応じて相関IDまたはメッセージIDを返す必要があります。Service Busで使用するどちらのID形式も、IBM WebSphere MQとの互換性およびMQネイティブ・インタフェースを使用するターゲット・サービスとの互換性があります。詳細は、「JMSリクエスト/レスポンスのメッセージIDと相関IDのパターン」を参照してください。

非同期のリクエスト/レスポンス・メッセージは、アウトバウンド・トランスポートとインバウンド・トランスポートによって処理されます。つまり、トランスポート方式固有のデータである$outboundと$inboundを除き、JMSリクエスト/レスポンスとHTTPリクエスト/レスポンスのメッセージ・フローに違いはありません。

Service Busは、同期と非同期のリクエスト/レスポンスのブリッジングをサポートしています。たとえば、HTTPを使用してプロキシ・サービスを呼び出すことができ、呼び出されたプロキシ・サービスは、JMSリクエスト/レスポンス・ビジネス・サービスにルーティングされます。これを同期から非同期へのサービスの切替えと呼びます。

31.1.4 メッセージでのJavaオブジェクトの送信および受信

JMSトランスポートを使用してJavaオブジェクトを直接送信できます。リクエストまたはレスポンスでJavaオブジェクトのサポートを有効にするには、「メッセージ・サービス」タイプのプロキシ・サービスまたはビジネス・サービスを作成し、Service Busを通じてJavaオブジェクトを送信するか受信するかに応じて、リクエストまたはレスポンスの「メッセージング」ページで「Java」を選択します。

JMS宛先からのJavaオブジェクトのデキューには、Javaオブジェクトのデシリアライズが伴います。この処理を有効にするには、JARファイルにデキューされる予定のJavaオブジェクトのJavaクラスをパッケージ化して、JARをService Busプロジェクトにインポートする必要があります。次に、サービスに対するJMSトランスポート固有の構成ページで、「クライアントJar」フィールドでJARを選択します。「クライアントJar」フィールドは、リクエストのメッセージ・タイプとしてJavaを選択しているときはJMSプロキシ・サービスで、また、レスポンスのメッセージ・タイプとしてJavaを選択しているときはビジネス・サービスで使用できます。

Service BusのJavaオブジェクトは、パイプライン・オブジェクト・リポジトリに格納され、<java-content ref="jcid" />要素および属性によってSOAP本体で参照されます(jcidはオブジェクト・リポジトリのオブジェクトに対するキーです)。JavaオブジェクトがNULLの場合、オブジェクトはパイプラインでref="jcid:null"として表現されます。

各メッセージで使用可能なJavaオブジェクトは1つだけです。Javaタイプのメッセージ・タイプについて、Service Busはラージ・メッセージ(コンテンツ・ストリーミング)や、テスト・コンソールでのJavaタイプ・サービスのテストはサポートしていません。

31.1.5 必要なJMSリソース

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

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

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

すべてのService Bus JMSリソースを単一のJMSモジュールにまとめる場合、Oracle WebLogic Server管理コンソールを使用して、プロキシ・サービスのエンドポイントとして使用する宛先を含む新しいJMSモジュールを作成します。JMSリソースの構成の詳細は、『Oracle WebLogic Server JMSリソースの管理』のJMSリソースの構成方法に関する項を参照してください。

31.1.6 プラットフォームの相互運用性

次の項では、異なるJMSプラットフォームを使用する場合の相互運用性に関する情報とリンクを示します。

- WebLogic JMSとの相互運用性

- WebSphere MQとの相互運用性

- Tibco EMSとの相互運用性

31.1.6.1 WebLogic JMSとの相互運用性

WebLogic Server JMSの詳細は、次のトピックを参照してください。

- 『Oracle WebLogic Server JMSアプリケーションの開発』のアプリケーションの管理に関する項を参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの構成に関する項

注意:

Service Busでは、リモート・トランザクション・サポートの構成に不可欠なMQ Extended Transactional Clientがサポートされています。

31.1.6.2 WebSphere MQとの相互運用性

Service Busは、WebSphere MQ JMSインタフェースを介してWebSphere MQに接続するため、Service BusはWebSphere MQ JMSクライアントです。WebSphere MQは、次の方法でService Busと対話できます。

- Service BusがWebSphere MQのフロントエンドとして機能し、他のアプリケーションからのサービス・リクエストを受け入れ、それらをWebSphere MQリクエストに変換します。

- WebSphere MQがService Busを介して他のアプリケーションにメッセージを送信します。

詳細は、「WebSphere MQ JMSインタフェースの使用」を参照してください。

31.1.6.3 Tibco EMSとの相互運用性

メッセージング・プロバイダとしてTibco Enterprise Messaging Service (EMS)を使用する場合、EXT_PRE_CLASSPATHでTibco EMSのクライアントJARファイルを参照できるように、setDomainEnv.cmd/shを変更する必要があります。

31.2 SOAP Over JMSトランスポートの使用

SOAPはトランスポート方式に依存しないため、SOAPトランスポートでHTTPのかわりにJMSを使用できます。Service Busでは、JMSリクエスト/レスポンスによるSOAPメッセージと、SOAPベースのWebLogic Serverクライアントおよびサービスとの相互運用性をサポートしています。JMSは、信頼性の高いメッセージング方法でもあります。

31.2.1 WebLogic Serverとの相互運用

WebLogic ServerでJMSリソースを構成するときは、次のSOAP-JMS URI形式をWebLogic Serverで使用します。

jms://host:port/contextURI/serviceName?URI=destJndiName

Service Busでサービスを構成する場合、URIは次の形式で指定する必要があります。

jms://host:port/connection_factory/jndi_destination

どちらの形式でも同じjndi_destinationを使用します。jndi_destinationは、ターゲットのWebLogic Serverの既存のQueueConnectionFactoryのJNDI名である必要があります。詳細は、『Oracle WebLogic Serverの理解』のWebLogic Serverのメッセージングに関する項を参照してください。このドキュメントでは、JMSの概要と詳細へのリンクを示します。

注意:

WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。

Service BusからWebLogic Serverサービスを呼び出す場合は、リクエストをビジネス・サービスに送信する前に、パイプライン内でアウトバウンド変数($outbound)に値/contextURI/serviceNameを指定したURIをJMSプロパティとして設定する必要があります。このプロパティを設定するには、トランスポート・ヘッダー・アクションを使用します。$outboundの設定の詳細は、「inbound変数とoutbound変数」を参照してください。

WebLogic Server Webサービス・クライアントがService Busプロキシ・サービスを呼び出す場合、URIプロパティは無視されます。ただし、トランスポート・ヘッダー・アクションのパススルー・オプションを使用すると、呼び出されるサービスにパススルーできます。詳細は、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。

Service Busで呼び出すことができるのは、バージョン9.2以降で実行されているOracle WebLogicリクエスト/レスポンス・サービスのみです。ただし、一方向のJMSサービスも呼び出すことができます。

31.2.2 ドメイン間JMS呼出しのレスポンス・キューの構成

ドメイン間JMS呼出しのレスポンス・キューを構成する場合は、リクエスト側の管理対象サーバーごとに個別のレスポンス・キューを設定します。

たとえば、2つのService Busクラスタ・ドメイン(ドメインAとドメインB)が、2つの管理対象サーバーを含むWebLogic Serverドメインと通信しているとします。ドメインAには3つの管理対象サーバーがあり、ドメインBには4つの管理対象サーバーがあります。ドメインAとドメインBにレスポンスを返すには、レスポンス・キューとして機能する7つ(3 + 4 = 7)の異なるキューをWebLogic Serverドメインに構成する必要があります。この7つのキューは、(WebLogic Serverドメインの両方の管理対象サーバーにメンバーを持つ)分散キューである場合もあります。

注意:

異なるリモート・ドメインによってホストされている複数のプロキシ・サービスからJMSリクエストを受信するには、リクエスト側の各ドメインに対応する個別のレスポンス・キューのセットを使用して、JMSビジネス・サービスをホストするバックエンドのドメインを構成する必要があります。

31.3 ドメイン、サーバーおよびURIの命名ガイドライン

複数のドメインを使用する作業では、構成が次の要件に準拠していることを確認します。

- WebLogic Serverインスタンス名およびドメイン名がユニークであること。

- WebLogic JMSサーバー名はドメイン間に渡って一意とします。

- 永続メッセージ用にJMSファイル・ストアを使用している場合、そのJMSファイル・ストア名がドメイン間に渡って一意でなければなりません。

31.3.1 JMSサーバー名

JMSサーバー名に関しては次のルールを確認します。

- 同じドメインに重複したJMSサーバー名を持つことはできません。重複したJMSサーバー名があると、メッセージが特定のJMSサーバーの宛先に送信されたときに、Service Busはメッセージの送信先のサーバーを判別できません。

- ストア・アンド・フォワード(SAF)を使用する場合は、異なるドメインに重複したJMSサーバー名があってもかまいません。

- ドメイン間通信の場合、ReplyTo機能を使用するときに、重複したJMSサーバー名が問題になることがあります。特定のドメインから送信されたReplyToメッセージは、元のメッセージを送信したドメインではなく、そのメッセージを受信した同じドメイン上のJMSサーバーに返されます。

WebLogic JMSの構成と管理方法については、次を参照してください。

- 『Oracle WebLogic Server JMSアプリケーションの開発』のアプリケーションの管理に関する項を参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの構成に関する項

31.3.2 JNDI名とService Bus

Oracle WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるエンドポイントURIの形式と一致しないため、このような名前を使用することはできません。この問題を回避するには、JMS外部サーバーを定義し、その外部サーバーをエンドポイントURI内で参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。

31.4 プロキシ・サービスでのJMSクライアントID

プロキシ・サービスにおけるJMSクライアントIDは、jms-client-id記述子の値であり、サブスクライバ名およびトピックのサブスクライバのクライアントID値を生成するために使用されます。トピック宛先を使用してJMSプロキシ・サービスを構成する場合は、サブスクライバ名およびサブスクライバのクライアントIDの生成時にJMSクライアントIDが使用されるように指定できます。これによって、実行時にサービスおよびトピックを監視および管理する際に、サブスクライバおよび対応するプロキシ・サービスを簡単に識別できるようになります。これは、恒久サブスクリプションにおいてのみ有効です。

31.4.1 クライアントIDおよびサブスクライバ名について

トピック宛先のサブスクリプションは、クライアントIDおよびサブスクライバ名によって識別できます。これらの値は、次の記述子を使用して、様々なTopicMessagesDistribution構成に対して生成されます。

- jms-client-id: トピック宛先をターゲットとするJMSプロキシ・サービスでJMS Client IDプロパティに対して構成される値。

- ejb-name: プロキシ・サービスに対してService Busによって生成されるMDBの名前。これは、一意のID値です。

- DomainName: Service Busドメインの名前。

- ServerName: ランタイムService Busサーバーの名前。

- UniqueKey: generate-unique-client-id記述子がtrueに設定されている場合に、WebLogic Serverによって生成される一意のキー。generate-unique-client-id記述子は、JMSプロキシ・サービスによってデプロイされたMDBに対して、常にtrueに設定されます。

次の表に、様々な配信モードでサブスクライバのクライアントIDおよび名前が生成される方法を示します。

トピック・メッセージ配信

サブスクライバのクライアントID

サブスクライバ名

アプリケーションごとに1つのコピー

jms-client-id

ejb-name

サーバーごとに1つのコピー

{jms-client-id}_{DomainName}_{ServerName}

ejb-name

互換性

{jms-client-id}_{ドメイン名}_{サーバー名}_{一意キー}

クライアントIDと同じ

その他にも、サブスクライバのクライアントIDに影響を与える記述子があります。distributed-destination-connection記述子は常にlocalに、generate-unique-client-id記述子は常にtrueに設定されます。詳細は、Oracle WebLogic ServerメッセージドリブンBeanのプログラミングの「トピックのサブスクリプション識別子」を参照してください。

31.4.2 推奨される使用方法

「互換性」の「トピック・メッセージ配信」モードを使用しないことをお薦めします。かわりに、スケーラビリティを向上させるために、(要件に応じて)「アプリケーションごとに1コピー」または「サーバーごとに1コピー」のいずれかを使用します。「互換性」モードは、主に下位互換性のために提供され、通常は、特定のプロキシ・サービスに関連するトピック・サブスクライバでクリーンアップ処理が行われる恒久サブスクリプションに使用されます。

31.5 JMSトランスポートのエラー処理

アプリケーション・エラーおよび通信エラーを処理するJMSトランスポート・ビジネス・サービスは、次のように構成します。

- アプリケーション・エラー

- 通信エラー

- Javaオブジェクトにおけるパイプライン例外

31.5.1 アプリケーション・エラー

アプリケーション・エラーが発生したときにビジネス・サービスのエンドポイントURIを再試行するかどうかを指定できます。詳細は、『Oracle Service Busの管理』のビジネス・サービス用のエンドポイントURIの管理とモニターに関する項を参照してください。

リクエスト/レスポンスを使用するように構成されたJMSビジネス・サービスでは、レスポンス・メッセージのSystem.getProperty("com.bea.wli.sb.transports.jms.ErrorPropertyName", "SERVER_ERROR")プロパティがtrueである場合にアプリケーション・エラーが発生します。このシナリオでは、JMSトランスポート・プロバイダは、TRANSPORT_ERROR_APPLICATIONエラー・コードを使用してエラー・メソッドを呼び出します。

31.5.2 通信エラー

通信エラーが発生したときにビジネス・サービスのURIをオフラインにするように構成できます。ビジネス・サービスの操作設定を構成するときに、指定した再試行間隔の後、ビジネス・サービスのエンドポイントURIがオフラインになるように設定できます。詳細は、『Oracle Service Busの管理』のビジネス・サービス用のエンドポイントURIの管理とモニターに関する項を参照してください。

次のアクティビティのいずれかでJMS例外またはネーミング例外が発生すると、通信エラーが発生します。

- JMS接続ファクトリのルックアップ

- JMS接続ファクトリからのJMS接続の作成

- 接続オブジェクトを使用したJMSセッションの作成

- JMS宛先のルックアップ

- セッション・オブジェクトからの送信者の作成

- 送信者および宛先オブジェクトを使用したJMSメッセージの送信

31.5.3 Javaオブジェクトにおけるパイプライン例外

Javaオブジェクト・メッセージのビジネス・サービスまたはJavaコールアウトへのルーティング中などに、JMSプロキシ・サービスで例外が発生したら、プロキシ・サービスが例外インスタンスにアクセスして、それを呼出し元のクライアントに返すことができるように、メッセージ・ペイロードを正しく書式設定してください。必ず、ペイロードは次の形式に従ってください。

<soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<ctx:java-content ref="key1"
xmlns:ctx="http://www.bea.com/wli/sb/context" />
</soap:Body>

ここで、key1はオブジェクト・リポジトリ内のJavaオブジェクトに対するキーです。ペイロードがこの形式ではない場合、パイプラインはnullのペイロードをインバウンドJMSトランスポートに渡します。

エラー・ハンドラの使用

Javaオブジェクトに関連するパイプライン・エラーは、エラー・ハンドラを使用して捕捉できます。エラー・ハンドラの$fault変数には、例外インスタンスへの参照が含まれます(java-exception要素)。

$fault変数に例外インスタンスへの参照が含まれない場合、変数$faultの情報を使用するエラー・ハンドラ内でJavaコールアウトを使用して、前述の$bodyペイロードの形式で例外インスタンスを生成できます。$bodyをインバウンドJMSトランスポートに対するペイロードとして使用できるように、失敗時の返信アクションを使用する必要があります。

31.6 WSDL定義のSOAPフォルト・メッセージ

明示的にエラーを定義するWSDLファイルを使用している場合、XMLエラーのタイプに対し、WebLogic clientgenツールによってjava.lang.Exceptionというサブクラスが生成されます。WebLogic Server JAX-RPCスタックがSOAP応答メッセージを検査し、応答メッセージにSOAPフォルトが含まれると判断すると、そのエラーをclientgen生成の例外Javaクラスにマップしようとします。

たとえば、次のリストに示す定義がWSDLファイルに含まれる場合、clientgenツールはjava.lang.Exceptionを拡張したcom.bea.test.TheFaultType Javaクラスを生成します。このサービス・スタブの関連メソッドが呼び出されると、JAX-RPCクライアントがcom.bea.test.TheFaultTypeを受け取る可能性があります。

例 - WSDL定義のサンプル

<definitions ... xmlns:s0="http://www.oracle.com/test/">
...
<types>
<xsd:schema targetNamespace="http://www.oracle.com/test/">
...
<xsd:complexType name="theFaultType">
<xsd:sequence>
<xsd:element name="ID" type="xsd:int" />
<xsd:element name="message" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
<xsd:element name="theFault" type="theFaultType" />
</xsd:schema>
</types>
...
<message name="theFaultMessage">
<part element="s0:theFaultPart" name="theFault" />
</message>
...
<binding ...>
<operation ...>
<soap:operation soapAction="..." style="document" />
<input ...>
...
</input>
<output ...>
...
</output>
<fault ...>
<soap:fault name="theFaultPart" use="literal" />
</fault>
</operation>
</binding>
...
</definitions>

SOAPメッセージには正しい形式のエラーが含まれ、JAX-RPCスタックが正しい例外をスローできるようになっている必要があります。詳細は、「フォルトがService Busパイプライン内から作成される場合にSOAPメッセージにフォルトを追加」を参照してください。

31.6.1 フォルトがService Busパイプライン内から作成される場合にSOAPメッセージにフォルトを追加

SOAPメッセージには正しい形式のエラーが含まれ、JAX-RPCスタックが正しい例外をスローできるようになっている必要があります。

フォルトがService Busパイプライン内から作成される場合、次のことを行う必要があります。

1. $body変数のノードを次のSOAPのサンプルで置き換えます。

例 - SOAPのサンプル

<soap-env:Body>
<soap-env:Fault>
<faultcode
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">soap:Server</faultcode>
<faultstring>Some literal string</faultstring>
<detail>
<test:theFault>
<test:ID>Any user defined code</test:Id>
<test:message>A specific literal message</test:message>
</test:theFault>
</detail>
</soap-env:Fault>
</soap-env:Body>

説明:

- soap-envは、http://schemas.xmlsoap.org/soap/envelope/ネームスペースのシステム接頭辞です。

- testは、http://www.oracle.com/test/の接頭辞です。
test接頭辞がService Busにとって既知ではない場合は、宣言する必要があります。

2. 失敗時の返信アクションを構成します。

返信アクションの構成の詳細は、「コンソールでの返信アクションの追加」を参照してください。

clientgenツールを使用して、Webサービスを呼び出すために必要なクライアント側のアーティファクト(JAX-RPCスタブなど)を生成します。『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のAntタスク・リファレンスの項を参照してください。

31.7 JMSリクエスト/レスポンスのメッセージIDと相関IDのパターン

この項では、Service BusでサポートされるJMSリクエスト/レスポンスのメッセージIDと相関IDのパターン、およびService Busでこれらのパターンを使用してJava API for Remote Procedure Call (JAX-RPC) Webサービスと相互運用する方法について説明します。例も示します。

- JMSリクエスト/レスポンスと設計パターンの概要

- JMSメッセージIDのパターン

- JMS相関IDのパターン

- メッセージIDと相関IDのパターンの比較

- JMSでのJAX-RPCとの相互運用

- JMSメッセージIDのパターン例

31.7.1 JMSリクエスト/レスポンスと設計パターンの概要

メッセージングでは、プログラム間で配信が保証された高速非同期通信を行います。多くの場合、メッセージングはメッセージ指向ミドルウェア(MOM)と呼ばれるソフトウェアのレイヤーとして実装されます。エンタープライズ・コンピューティングにおいて、プロセスやプロセス間の通信の信頼性がそれほど高くない場合でも、メッセージングによりプロセス間の通信の信頼性が高まります。プロセスで通信が必要になる理由は次のとおりです。

- あるプロセスのデータを別のプロセスに送信する必要があります。

- あるプロセスが別のプロセスのプロシージャをリモートから呼び出す必要があります。

IBM WebSphere MQを使用している場合、特定のメインフレームとの対話には非同期リクエスト/レスポンス・メッセージングを使用することをお薦めします。

31.7.1.1 メッセージングのパターン

メッセージングのパターンには、MOMで構築されたシステムの各部分間をフローするメッセージのフォーマットが記述されます。メッセージには、次のような様々なタイプがあります。

- メッセージング・システムでプロシージャ・コールのセマンティクスを実行できるようにするコマンド・メッセージ。

- メッセージング・システムが情報(コマンド・メッセージの結果として送信側に返す情報など)をトランスポートできるようにするドキュメント・メッセージ。

- メッセージングを使用してイベントの通知を実行するイベント・メッセージ。

- リモート・プロシージャ・コールの結果のセマンティクスを処理する応答メッセージ。応答メッセージでは、成功した結果と失敗した結果の両方を処理できる必要があります。

- リクエストを作成するプログラムが応答送信時のチャネルを識別できるようにする応答指定子。

- リクエスト元のプログラムが特定のレスポンスをリクエストに関連付けることを可能にする相関ID。渡されたデータが複数のメッセージにわたる場合は、シーケンス識別子により、受信側は元のデータを正確に再構築できます。

- 送信側がメッセージを配信または無視することによって期限を設定できるようにするメッセージ有効期限。

- 受信側がメッセージの受信率を制御できるようにするメッセージ抑制。

Service Busの場合、各返信メッセージに、リクエスト・メッセージと返信を関連付ける相関IDと呼ばれる一意の識別子を含める必要があります。

呼出し側は、リクエスト・メッセージの作成時に、現在未完了の他のすべてのリクエスト(応答をまだ受信していないリクエストなど)の識別子とは異なる一意の識別子をリクエストに割り当てます。受信側は、リクエストを処理するときにこの識別子を保存し、リクエストの識別子を応答に追加します。呼出し側は、応答を処理するときにリクエストの識別子を使用してリクエストを応答に関連付けます。この識別子は、呼出し側が各応答とリクエストの関連付けに使用するため、相関IDと呼ばれます。

通常、相関IDはメッセージのヘッダーに配置されます。このIDは、呼出し側が受信側に伝達するコマンドまたはデータに含まれるわけではありません。受信側は、リクエストのIDを保存し、呼出し側のために応答に追加します。メッセージ本文は2つのシステム間で送信されるコンテンツであり、IDはコンテンツの一部ではないため、IDはヘッダーに追加されます。リクエスト・メッセージには、IDを相関IDプロパティとして格納することも、単にメッセージIDプロパティとして格納することもできます。IDが相関IDとして使用されている場合、どのメッセージがリクエストでどのメッセージが応答か混乱を招くおそれがあります。リクエストにメッセージIDが含まれ、相関IDは含まれていない場合、応答にはそのリクエストのメッセージIDと同じ相関IDが含まれます。Service Busで内部的に使用される相関IDの形式はWebSphere MQの形式と互換性があり、MQネイティブのインタフェースが使用されているターゲット・サービスで動作します。

アウトバウンド・トランスポートでは、非同期のリクエスト/レスポンス・メッセージを処理します。つまり、トランスポート方式固有のデータである$outboundを除き、JMSリクエスト/レスポンスとHTTPリクエスト/レスポンスのパイプラインに違いはありません。

JMSリクエスト/レスポンス・ビジネス・サービスまたはプロキシ・サービスを定義するときには、まず設計パターンを選択する必要があります。これを行うには、JMSプロキシ・サービスでは「レスポンスが必要」オプション、JMSビジネス・サービスでは「レスポンス・キュー」オプションを選択し、JMSの「トランスポート構成」ページで次のいずれかの相関パターンを選択します。

- JMS相関ID (デフォルトのパターン)

- JMSメッセージID

注意:

プロキシ・サービスに対する相関IDのマッピングがメモリーに格納されているため、JMSリクエスト/レスポンス・メッセージングに信頼性のあるレスポンスが返されません。リクエストの送信後にレスポンスが受信されるまでの間に障害またはシステムの再起動が発生すると、そのレスポンスは破棄されます。

この状況を回避するには、JMSリクエスト/レスポンスを使用せずに、2つの一方向JMSプロキシ・サービス(メッセージ配信用とレスポンス配信用の2つ)を使用します。

次の項では、これらのパターンについて説明します。2つのパターンを比較するには、「メッセージIDと相関IDのパターンの比較」を参照してください。

31.7.2 JMSメッセージIDのパターン

JMSメッセージIDのパターンを使用してビジネス・サービスを作成する場合は、レスポンスが1つのURIに送信されるように構成できます。あるいは、フェイルオーバーをサポートするために、Service Busクラスタの各管理対象サーバー上の各リクエストURIに対してレスポンス・キューを構成できます。これらのキューは、サービスのリクエスト・キューと同じ場所に存在する必要があります。プロキシ・サービスは、ビジネス・サービスを呼び出すときにこの情報を使用してJMSReplyToプロパティを設定し、このリクエストを出した管理対象サーバーによってレスポンスが処理されるようにします。

JMSメッセージIDのパターンを使用してプロキシ・サービスを定義すると、プロキシ・サービスはJMSReplyToプロパティで指定されたキューに返信するため、レスポンスURIを定義する必要はありません。ただし、レスポンス・メッセージに対してJMS接続ファクトリのJNDI名を指定できます。JMSReplyToプロパティには、「JMSReplyToプロパティへのアクセス」の説明に従い、トランスポート・メタデータを介してアクセスできます。

注意:

デフォルトでは、リクエスト・メッセージの接続ファクトリが使用されます。これが役立つのは、JMSレスポンスに対して非XA接続ファクトリを使用するが、リクエストに対してXA接続ファクトリがある場合です。

デプロイメント記述子をXA対応リソースに適切に設定するには、プロキシ・サービスを作成する前に、参照接続ファクトリのXA属性を設定する必要があります。

呼び出されたサービスは、リクエストのメッセージID (JMSヘッダー・フィールドJMSMessageIDの値)をレスポンスの相関IDにコピー(JMSヘッダー・フィールドJMSCorrelationIDを設定)する必要があります。また、呼び出されたサービスは、JMSReplyToヘッダー・フィールドに指定されたキューに返信する必要があります。JMSメッセージIDのパターンを選択すると、レスポンスは適切な管理対象ノードに送信されます。

注意:

JMSメッセージID相関パターンは、プロキシ・サービスが別のプロキシ・サービスを呼び出す場合はサポートされません。

31.7.2.1 JMSReplyToプロパティへのアクセス

JMSプロキシ・サービスの場合、着信メッセージ内のJMSReplyToプロパティは、同じくJMSReplyToという名前を持つ、JMSトランスポート・メタデータ要素内のJavaオブジェクトとして格納されます。アウトバウンド・リクエストに含まれるこのメタデータ要素の値をビジネス・サービスに渡すと、動的な返信先をサポートできます。パイプラインでは、この値をJavaコールアウト・アクションに渡して変換できます。JMSプロキシ・サービスが、パイプラインを使用せずにJMSビジネス・サービスを直接呼び出す場合、JMSトランスポート・メタデータは自動的にビジネス・サービスに渡されます。プロキシ・サービスでパイプラインを呼び出す場合、ヘッダーをインバンド・メッセージからコピーしてアウトバウンド・リクエスト・ヘッダーで設定するようにパイプラインを構成する必要があります。

JMSビジネス・サービスがパイプラインを使用せずに直接呼び出される初めてのケースの場合、このキューをリスンするコンシューマは、JMSReplyToヘッダーを読み取り、さらにメッセージをヘッダーの宛先に送信します。つまり、2つのメッセージがキューに書き込まれます。これを避けるには、サービス間でパイプラインを使用します。

リクエスト/レスポンス・プロキシ・サービスの場合、JMSReplyToメタデータ要素は、相関パターンがメッセージIDの場合のみ設定されます。パターンが相関IDの場合、プロキシ・サービスはJMSReplyToの値をトランスポート構成から特定するため、この値はメタデータ要素には設定されません。

注意:

JMSReplyToメタデータ要素にはJavaオブジェクトのjava-content表現が含まれるため、この要素はテスト・コンソールに表示されません。

31.7.2.2 クラスタでのJMSメッセージIDのパターン

このパターンを使用するJMSプロキシ・サービスは、追加の構成なしにクラスタで使用できます。JMSビジネス・サービスはクラスタで使用できます。ただし、管理対象サーバーがクラスタに追加されると、すべてのビジネス・サービスが無効になります。これを回避するには、レスポンス・キューの数が、Service BusクラスタにおけるJMSメッセージIDの相関パターンを指定する管理対象サーバーの数と同じになるようにします。

31.7.3 JMS相関IDのパターン

ビジネス・サービスをJavaで設計するときは、レスポンスのJMS相関IDの値をリクエストのJMS相関IDの値に設定してから、JMSレスポンスをキューに送信するようにします。メッセージの受信時にJMS相関IDを取得するには、次の方法を使用します。

String getJMSCorrelationID()

上記のメソッドは、特定のメッセージIDまたはアプリケーション固有の値を表す相関IDの値を文字列として返します。

メッセージの送信時にJMS相関IDを設定するには:

void setJMSCorrelationID(String correlationID)

31.7.4 メッセージIDと相関IDのパターンの比較

JMSリクエスト/レスポンス・パターンは次の点で異なります。

- レスポンスをリクエストと関連させる方法

- レスポンス・キューの選択

この2つのパターンの相違について、表31-1にまとめます。

表31-1 メッセージIDと相関IDのパターンの相違点

JMSパターン名

レスポンス・キュー

CorrelationID

相関IDのパターン

すべてのレスポンスは固定された同じキューに入れられます。

サーバーはリクエストの相関IDをレスポンスの相関IDにコピーします。

メッセージIDのパターン

レスポンスは、JMSReplyToプロパティで指定されたキューに動的に入れられます。

サーバーはリクエストのメッセージIDをレスポンスの相関IDにコピーします。

相関IDのパターンが使用される場合、呼び出されたサービスは、リクエストURIに対応するキューに応答します。レスポンスは常に同じキューに置かれ、クライアントはレスポンスが置かれるキューを制御できません。たとえば、10のクライアントがリクエストURI「A」にメッセージを送信した場合、これらのクライアントはすべてリクエストURI「A」に対応するキューからレスポンスを取得します。このため、クライアントはレスポンス・キューのメッセージをフィルタして、各自に関連するレスポンスを選択する必要があります。フィルタ条件をリクエスト・メッセージの相関IDプロパティに構成し、これをレスポンスの相関IDプロパティに返すようにサーバーを構成します。

メッセージIDのパターンの場合、クライアントのJMSReplyToプロパティによってサーバーにレスポンスの送信先を指示します。このキューはクライアントのサーバーに固有であるため、別のクライアントへのレスポンスは別のキューに置かれます。サーバーは、レスポンスのJMS相関IDをリクエストのJMSメッセージIDに設定します。

メッセージIDによる相関は、JMSアプリケーションだけではなく多くのIBM MQアプリケーションでも一般に使用されており、リクエストとレスポンスを関連付ける標準的な方法です。

メッセージIDのパターンによるJMSリクエスト/レスポンスを使用して、複数のOracle WebLogicクライアント・ドメインからターゲットのOracle WebLogicドメインを呼び出す場合は、リクエスト・キューとレスポンス・キューの両方をSAFキューとして設定できます。ただし、所定のリクエストURIに対するすべてのレスポンスに単一のキューを使用する相関IDのパターンでは、このように設定することはできません。

相関IDのパターンには主に2つの利点があります。

- レスポンス・キューの構成が簡単であり、クラスタに管理対象サーバーが新しく追加されるたびに変更する必要はありません。

- ドメインのプロキシ・サービスが同じドメインの別のプロキシ・サービスを呼び出す必要がある場合、相関IDも使用できます。

31.7.5 JMSでのJAX-RPCとの相互運用

Service Bus開発環境では、HTTP/HTTPSに加え、JMSトランスポートを使用するJAX-RPC Webサービスを作成できます。このようなJMS転送のJAX-RPC Webサービスでは、操作に関連付けられた値を取得したり返したりするためのメカニズムとしてJMSキューを使用します。JMSメッセージIDのパターンを使用して、JMS転送のJAX-RPC Webサービスを呼び出すことができます。

また、Oracle WebLogic clientgenのAntタスクによって生成されたJAX-RPC静的スタブから、JMSリクエスト/レスポンス・プロキシ・サービスを呼び出すこともできます。

31.7.5.1 JMSメッセージIDのパターンを使用したJAX-RPC Webサービスの呼出し

JMSメッセージIDのパターンを使用してJMS転送のJAX-RPC Webサービスを呼び出すには、以下の手順を実行します。

1. JMSメッセージIDのパターンを使用してJMSトランスポートのJAX-RPC Webサービスを呼び出す、JMSリクエスト/レスポンス・ビジネス・サービスを作成します。詳細は、Service Busで提供されるオンライン・ヘルプを参照してください。
このビジネス・サービスは、JMSトランスポートを使用します。エンドポイントURIのJMSキューJNDI名の部分は、JMSトランスポートのJAX-RPC Webサービスの@WLJmsTransport注釈に指定したキュー属性と同じであることが必要です。次に例を示します。

jms://localhost:7001/AJMSConnectionFactoryJNDIName/JmsTransportServiceRequestQueue

「宛先」フィールドに割り当てるJMSキューのJNDI名は、「ターゲット」フィールドに表示されるWebLogic Server名を対象としたJMSサーバーに関連付けられている必要があります。

注意:

WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。

2. 手順1で作成したJMSリクエスト/レスポンス・ビジネス・サービスへのルーティング(またはサービス・コールアウト)アクションを含むプロキシ・サービスを作成します。
ルーティング・アクションの「リクエスト・アクション」領域には、アウトバウンド・リクエストのトランスポート・ヘッダーの設定アクションを含める必要があります。トランスポート・ヘッダー・アクションを構成するときは、アウトバウンド・リクエスト・アクションの2つのJMSヘッダーを追加する必要があります。トランスポート・ヘッダー・アクションの構成方法の詳細は、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。

次に、手順を簡単に説明します。

a. トランスポート・ヘッダー・アクションを構成するには、「ヘッダーの追加」フィールドの「その他」を選択し、表示されたフィールドにURIを入力します。

b. 「ヘッダーを<Expression>に設定」を選択し、(JMSトランスポートのJAX-RPC Webサービスの@WLJmsTransport注釈で)contextPath属性とserviceUri属性に指定した値を続けて入力(各属性の値の前にはスラッシュを入力)して式を作成します。たとえば、@WLJmsTransportアノテーションが次のように指定されているとします。

@WLJmsTransport(
contextPath="transports",
serviceUri="JmsTransportService",
portName="JmsTransportPort",
queue="JmsTransportServiceRequestQueue"
)

トランスポート・ヘッダーを構成する場合、「XQueryテキスト」入力領域に次の式を入力します。

/transports/JmsTransportService

c. 2つ目のJMSヘッダーを指定するには、「ヘッダーの追加」フィールドの「その他」をもう一度選択し、関連するフィールドに_wls_mimehdrContent_Typeと入力します。

d. 「ヘッダーを<Expression>に設定」を選択し、「XQueryテキスト」入力領域にtext/xml; charset=UTF-8と入力します。

31.7.5.2 JAX-RPCクライアントからのJMSリクエスト/レスポンス・プロキシ・サービスの呼出し

JAX-RPC WebLogic Serverクライアントからプロキシ・サービスを呼び出すシナリオでは、プロキシ・サービスのインバウンド・レスポンスに_wls_mimehdrContent_Type JMSヘッダーを設定し、着信JMSメッセージIDパターン・リクエストへのレスポンスを発行するときに、そのヘッダーを指定します。

たとえば、JAX-RPCクライアントからプロキシ・サービスを呼び出し、続いてWebLogic Server Webサービスを呼び出すシナリオでは、ルート・ノードの構成は次のようになります。

リクエスト・パイプラインの場合

1. Webサービス・コンテキストURIのトランスポート・ヘッダーを設定します(例: interop/AllocJmsDocLit)。

2. _wls_mimehdrContent_Typeのトランスポート・ヘッダーを、text/xml; charset=UTF-8に設定します。

3. 「トランスポート・ヘッダーを設定」メニュー項目から「アウトバウンド・リクエスト」を選択します。

4. 「パイプラインを介してすべてのヘッダーを渡す」を有効にします。

レスポンス・パイプラインの場合

1. 空のトランスポート・ヘッダーを追加し、「トランスポート・ヘッダーを設定」メニューから「インバウンド・レスポンス」を選択します。

2. 「パイプラインを介してすべてのヘッダーを渡す」を有効にします。

注意:

トランスポート・ヘッダー・アクションを構成する手順については、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。

31.7.6 JMSメッセージIDのパターン例

次の例で、JMSメッセージIDのパターンを使用する様々な方法について説明します。

- JMSメッセージIDを使用してリクエスト/レスポンス・メッセージの相関を行うMQサービス

- プロキシ・サービスを使用したJAX-RPCクライアント

- WebLogic Server JAX-RPCサービスのクライアントとしてのService Bus

31.7.6.1 JMSメッセージIDを使用してリクエスト/レスポンス・メッセージの相関を行うMQサービス

図31-1では、リクエスト/レスポンス通信においてMQサービスをホストするサーバーがリクエスト・メッセージIDをレスポンス相関IDに返し、レスポンスをreplyToキューに送信します。レスポンスが戻り、JMSメッセージIDを使用して関連付けられます。Service BusのreplyTo宛先は、ビジネス・サービスの構成時に、クラスタのService Busノードごとに1つ設定されています。また、JMSまたはMQネイティブ・クライアントが、JMSメッセージIDのパターンを使用してJMSリクエスト/レスポンス・プロキシ・サービスを呼び出すことができます。クライアントは、レスポンスを受け取るキューにreplyToプロパティを設定する必要があります。

この使い方で重要なのは、JMSメッセージIDがリクエスト/レスポンス・メッセージの相関を行うことです。また、クラスタ・サーバーと同じ数のMQ Seriesアウトバウンド・レスポンス・キューを作成する必要があります。

図31-1 相関にJMSメッセージIDを使用するMQサービス

31.7.6.2 プロキシ・サービスを使用したJAX-RPCクライアント

図31-2は、Service Busプロキシ・サービスにメッセージを送信するJAX-RPCクライアントを表します(JAX-RPCインバウンドの場合)。JAX-RPCスタックは、レスポンスを受信するために一時的なキューを使用します。JMSトランスポートでは、実行時にこの一時的なキューを使用します。

図31-2 Service Busプロキシ・サービスを使用したJAX-RPCクライアント

31.7.6.3 WebLogic Server JAX-RPCサービスのクライアントとしてのService Bus

図31-3は、JAX-RPCアウトバウンド、つまりWebLogic Server JAX-RPCリクエスト/レスポンス・サービスとService Busプロキシ・サービスとの相互運用性を表します。

図31-3 WebLogic Server JAX-RPCサービスのクライアントとしてのService Bus

注意:

1つ目のWebLogic Serverドメインのプロキシ・サービスが2つ目のドメインのプロキシ・サービスにメッセージを送信する必要がある場合、まずドメイン1のパススルー・ビジネス・サービスにメッセージをルーティングする必要があります。ドメイン1とドメイン2の間のJMSストア・アンド・フォワードでは、ドメイン2のプロキシ・サービスにインバウンド・リクエスト・メッセージを転送します。JMSリクエスト/レスポンスを使用する場合、JMSストア・アンド・フォワードを使用して、ドメイン2からドメイン1にインバウンド・レスポンス・メッセージを転送することもできます。この場合、ドメイン2のプロキシ・サービスに対して、エクスポートされるインバウンド・リクエスト・キューとインポートされるインバウンド・レスポンス・キューをドメイン2で構成する必要があります。JMSストア・アンド・フォワードの構成に特に注意する必要があります。

31.8 JMSトランスポート構成のリファレンス

どのサービス・タイプのプロキシおよびビジネス・サービスに対しても、JMSをトランスポート・プロトコルとして選択できます。この項では、ビジネスおよびプロキシ・サービスのJMSトランスポート用に構成できるプロパティについて説明します。ビジネス・サービスのエラー処理の詳細は、「JMSトランスポートのエラー処理」を参照してください。

プロキシ・サービスを構成するときに、トランスポート・ヘッダー・アクションを使用してメッセージのヘッダー値を設定できます。詳細は、「JMSトランスポート・ヘッダー」を参照してください。

- JMSトランスポートのエンドポイントURI

- JMSトランスポートを使用するプロキシ・サービスの構成

- JMSトランスポート・ヘッダー

- JMSトランスポートを使用するビジネス・サービスの構成

31.8.1 JMSトランスポートのエンドポイントURI

次の形式で、JMSトランスポートのエンドポイントURIを入力します。

jms://host:port[,host:port]*/connection_factory/jndi_destination

説明:

- hostは、サービスをホストするシステムの名前です。

- portは、接続を行うポート番号です。

- [,host:port]*は、対応するポートで複数のホストを構成できることを示します。

- connection_factoryは、JNDI接続ファクトリの名前です。接続ファクトリ・キューを定義する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのリソースの構成に関する項を参照してください。

- jndi_destinationは、JNDI宛先の名前です。

JMS宛先として複数のサーバーを指定するには、次のURI形式を使用します。

jms://host1:port,host2:port/connection_factory/jndi_destination

ここで、connection_factoryは、接続ファクトリ・キューの名前です。接続ファクトリ・キューを定義する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのリソースの構成に関する項を参照してください。

注意:

WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。

31.8.2 JMSトランスポートを使用するプロキシ・サービスの構成

次の表に、JMSベースのプロキシ・サービスの構成に使用するプロパティを示します。詳細は、「プロキシ・サービスの作成と構成」を参照してください。

表31-2 プロキシ・サービス用のJMSトランスポート・プロパティ

プロパティ

説明

宛先タイプ

次のいずれかを選択します。

- キュー(ポイント・ツー・ポイント宛先の場合)

- 「トピック」(パブリッシュ/サブスクライブの宛先の場合)

レスポンスが必要

アウトバウンド・メッセージの送信後にレスポンスを受け取ることを指定する場合は、このオプションを選択します。

このオプションは、「宛先タイプ」が「キュー」の場合のみ使用できます。

レスポンス・パターン

次のいずれかを選択して、レスポンスの設計パターンを指定します。

- JMSMessageID: WebLogic Serverで実行するJAX-RPCサービスの場合。

- JMSCorrelationID: その他のすべてのサービスの場合。このオプションを選択した場合、「レスポンスURI」にも入力する必要があります。

このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。

レスポンス・メッセージ・タイプ

レスポンス・メッセージのタイプとして、次のいずれかを選択します。

- 「バイト」(未解釈バイトのストリームの場合)

- 「テキスト」(テキスト・メッセージの場合)

レスポンスにJavaのメッセージ・タイプを選択した場合、このオプションは無効です。「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。

クライアントJar

Javaオブジェクトを含むメッセージのデキューに使用する、クライアントJARを選択します。クライアントJARの選択によって、それがクラスパス上にあることが確認されます。このオプションは、サービスが、Javaリクエスト・タイプのメッセージング・サービスのときに使用できます。

詳細は、「メッセージでのJavaオブジェクトの送信および受信」を参照してください。

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

リクエストのエンコーディング

リクエストのエンコード用の文字セットを入力します。デフォルト値はUTF-8です。

レスポンスのエンコーディング

レスポンスのエンコード用の文字セットを入力します。デフォルト値はUTF-8です。

このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。

クライアント・レスポンス・タイムアウト

接続を切断するまでのサーバー・レスポンスの待機時間を秒単位で入力します。このフィールドの値は、クライアントが同一ドメインの別のプロキシ・サービスである場合にのみ適用されます。

このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。

レスポンスURI

次に示すいずれかの形式で、レスポンスURIを入力します。このオプションは、「レスポンス・パターン」で「JMSCorrelationID」が選択されている場合にのみ使用できます。

jms://host:port/connection_factory/jndi_destination

複数のサーバーをターゲットとする場合は、次の形式を使用します。

jms://host1:port,host2:port/connection_factory/jndi_destination

レスポンスURIのホストとポートを省略することもできます。次に例を示します。

jms:///connection_factory/jndi_destination

ホストとポートを省略すると、ローカル・サーバーで接続ファクトリや宛先ルックアップが発生します。これは、リクエストURIが外部接続ファクトリや宛先を指し、レスポンスをローカル・サーバーに送信する場合などに便利です。

注意: WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。

レスポンス接続ファクトリ

レスポンス接続ファクトリURIを入力します。このオプションは、「レスポンス・パターン」で「JMSMessageID」が選択されている場合にのみ使用できます。

接続ファクトリが指定されていない場合、リクエストの接続ファクトリがレスポンスに使用されます。

JMSサービス・アカウント

JMSサーバーによって管理されているJMSリソースに使用するサービス・アカウントを選択します。サービス・アカウントは、リクエストとレスポンスの両方に使用される、ユーザーIDとパスワードの別名リソースです。同じサービス・アカウントが、JMSとJNDIの両方に使用されます。

詳細は、「サービス・アカウントの操作」を参照してください。

SSLを使用

リクエストがTLS/SSL接続を通して行われる場合にのみ、このチェック・ボックスを選択します。

TLS/SSL (Secure Sockets Layer)では、ネットワークで接続される2つのアプリケーションが互いのIDを認証し、アプリケーション間で交換されるデータを暗号化できるようにすることによって、安全な接続が可能になります。認証を使用すると、サーバー(および必要に応じてクライアント)はネットワーク接続の相手側アプリケーションのIDを検証できます。また、宛先のJNDIエントリに対してアクセス制御が設定されていることにより、管理者から個々のJMS宛先(キューまたはトピック)へのアクセスが制限されている場合、JNDIツリー内でのルックアップ時に、サービスで認証を行う必要があります。

注意: JMSトランスポートでは、双方向SSLはサポートされません。

メッセージ・セレクタ

メッセージ・セレクタ式を入力します。式に一致するプロパティを持つメッセージのみが処理されます。

クライアントID

サブスクライバに使用するクライアントIDをトピックに対してのみ入力します。値を入力しないと、クライアントIDが自動的に生成されます。カスタムIDを割り当てると、サービスの監視時にこのコンポーネントを識別するのに役立ちます。これは、恒久サブスクライバにおいてのみ有効です。

JMSクライアントIDは、トピックのサブスクライバに対してサブスクライバ名およびクライアントID値を生成するために使用される複数のMDB記述子の1つです。JMSクライアントIDを定義すると、サブスクライバ名またはクライアントIDによって、特定のトピックのサブスクライバを簡単に識別して表示できます。

詳細は、「プロキシ・サービスにおけるJMSクライアントID」を参照してください。

恒久サブスクリプション

サブスクリプションが恒久である場合はこのチェック・ボックスを選択し、サブスクリプションが恒久でない場合は、このチェック・ボックスを空のままにします。恒久サブスクリプションは、メッセージがパブリッシュされたときにサブスクリプションが非アクティブになっている場合でも、トピックに関してパブリッシュされたすべてのメッセージを受信します。

このオプションは、「宛先タイプ」で「トピック」が選択されている場合にのみ使用できます。

非XA接続の再試行

後述の再試行回数と間隔を使用して非XA接続を再試行する場合、このチェック・ボックスを選択します。このチェック・ボックスを選択しなかった場合、Service BusはXA接続のみを再試行し、再試行回数および間隔はXA接続のみに適用されます。

このチェック・ボックスは、サービスURI内に非XA接続ファクトリを含むJMSプロキシ・サービスのみに適用されます。

再試行回数

メッセージがエラー宛先に移されるまでに許可される配信の再試行回数を入力します。このフィールドは、WebLogic Server JMS宛先にのみ適用されます。

再試行間隔

ロールバックまたは復元されたメッセージが再配信されるまでの時間をミリ秒単位で入力します。このフィールドは、WebLogic Server JMS宛先にのみ適用されます。

エラー宛先

再配信制限に達したメッセージの宛先の名前を入力します。このフィールドは、WebLogic Server JMS宛先にのみ適用されます。

有効期限ポリシー

宛先で検出された有効期限切れメッセージの処理方法を定義するポリシーを選択します。メッセージを破棄またはリダイレクトすることを指定できます。リダイレクトされたメッセージは、前述のエラー宛先に移動されます。

このフィールドは、WebLogic Server JMS宛先にのみ適用されます。

XAが必要

接続ファクトリがXAである場合は、このチェック・ボックスを選択します。

このオプションは、リモート接続ファクトリが使用できない場合に考慮されます。接続ファクトリが使用可能であり、このオプションが有効になっている場合は、接続ファクトリがトランザクションとして定義されていることを確認してください。

トランザクション・タイムアウト

トランザクションが処理されるまでJMSプロキシ・サービスが待機する時間を秒単位で入力します。このオプションは、XA接続ファクトリを使用しているサービスにのみ適用されます。デフォルトは600秒です。

レスポンス・キューにMDBなし

インバウンド・レスポンス・キューでデフォルトのメッセージドリブンBean (MDB)を生成しない場合、このオプションを選択します。このオプションは、パフォーマンスを向上させるために使用します。このオプションを選択した場合、プロキシからプロキシへのルーティング形式はサポートされません。

JNDIタイムアウト

JNDIツリーでの宛先または接続ファクトリの検索時に使用されるJNDI接続タイムアウト(秒)。

トピック・メッセージ配信

メッセージドリブンBeanによって着信JMSメッセージ、高可用性およびフェイルオーバーを処理する方法を決定するために、次のいずれかのプロパティを選択します。

- アプリケーションごとに1コピー: JMSプロキシ・サービスをクラスタにデプロイしたときに高可用性とスケーラビリティを提供する場合は、このオプションを選択します。これにより、インバウンドJMSメッセージが、クラスタ内にある使用可能ないずれか1つのサーバーでのみ処理されます。これはデフォルト値です。

- サーバーごとに1コピー: クラスタのメンバーごとにプロキシ・サービスで受信されるトピックにインバウンドJMSメッセージをパブリッシュする場合に、このオプションを選択します。

- 互換性: クラスタ内の特定の管理対象サーバーまたはすべての管理対象サーバーでインバウンドJMSメッセージを処理する場合は、このオプションを選択します。このプロパティを選択した場合は「対象」サーバーを選択します。

このオプションは、「宛先タイプ」に「トピック」を選択した場合に使用できます。

注意: クラスタ内で互換性モードを使用する場合、重複メッセージが表示されることがあります。これを回避するには、他のいずれかのオプションを使用します。

「1コピー」オプションは、JMS接続ファクトリで構成された「サブスクリプション共有ポリシー」および「クライアントIDポリシー」をオーバーライドします。

ターゲット

受信したJMSメッセージを処理するターゲット・サーバーを選択します。「トピック・メッセージ配信」で「1コピー」オプションのいずれかを選択した場合、このフィールドにはクラスタの名前が表示されます。このオプションは、「トピック・メッセージ配信」オプションに「互換性」を選択した場合に、Service Busクラスタでのみ使用できます。

対象を設定しない場合は、クラスタ内の管理対象サーバーごとにトピックからメッセージを読み取るJMSプロキシ・サービス・インスタンスによってメッセージのコピーが取得されます。

31.8.3 JMSトランスポート・ヘッダー

JMSトランスポートに関連する各種のヘッダーを表31-3に示します。順序単位ヘッダーを除き、すべてのヘッダーはアウトバウンド・リクエストとインバウンド・レスポンスの両方で共通になっています。

表31-3 JMSトランスポート・ヘッダー

ヘッダー

説明

JMSCorrelation ID

メッセージを別のメッセージにリンクするために使用される識別子。たとえば、リクエスト・メッセージをレスポンス・メッセージにリンクできます。

JMSDeliveryMode

メッセージの送信時に指定された配信モード。

JMSExpiration

メッセージの有効期限。メッセージの有効期限が切れる特定の日時を示す絶対値です。XQuery式を使用して、各メッセージの正確な有効期限日時を計算できます。

JMSMessageID

プロバイダから送信されるメッセージを一意に識別する値。

JMSPriority

メッセージの処理優先順位。メッセージを送信すると、このフィールドは無視されます。送信操作が完了すると、メッセージを送信したメソッドによって指定された値が保持されます。

JMSType

メッセージの送信時にクライアントによって指定されるメッセージ・タイプの識別子。

JMSXAppID

JMSで定義されるプロパティの1つで、メッセージを送信するアプリケーションのIDを指定します。このプロパティは、JMSプロバイダによって設定されます。

JMSXGroupID

JMSで定義されるプロパティの1つで、メッセージが属するメッセージ・グループのグループIDを指定します。このプロパティは、クライアントによって設定されます。

JMSXGroupSeq

JMSで定義されるプロパティの1つで、メッセージ・グループ内でのメッセージの順序を指定します。

JMS_IBM_Format

アプリケーション・データの性質。詳細は、IBM WebSphereのドキュメントを参照してください。

JMS_IBM_Report_Exception

例外レポートをリクエストします。また、メッセージからレポート・メッセージに保持する必要があるアプリケーション・データの量も指定します。詳細は、IBM WebSphereのドキュメントを参照してください。

JMS_IBM_Report_Expiration

期限切れレポートをリクエストします。また、メッセージからレポート・メッセージに保持する必要があるアプリケーション・データの量も指定します。詳細は、IBM WebSphereのドキュメントを参照してください。

JMS_IBM_Report_COA

着信確認レポートをリクエストします。また、メッセージからレポート・メッセージに保持する必要があるアプリケーション・データの量も指定します。詳細は、IBM WebSphereのドキュメントを参照してください。

JMS_IBM_Report_COD

配信確認レポートをリクエストします。また、メッセージからレポート・メッセージに保持する必要があるアプリケーション・データの量も指定します。詳細は、IBM WebSphereのドキュメントを参照してください。

JMS_IBM_Report_PAN

肯定アクション通知レポートをリクエストします。詳細は、IBM WebSphereのドキュメントを参照してください。

JMS_IBM_Report_NAN

肯定アクション通知レポートをリクエストします。詳細は、IBM WebSphereのドキュメントを参照してください。

JMS_IBM_Report_Pass_Msg_ID

レポートまたは返信メッセージのメッセージ識別子が元のメッセージの識別子と同じになるようにリクエストします。詳細は、IBM WebSphereのドキュメントを参照してください。

JMS_IBM_Report_Pass_Correl_ID

レポートまたは返信メッセージの相関識別子が元のメッセージの識別子と同じになるようにリクエストします。詳細は、IBM WebSphereのドキュメントを参照してください。

JMS_IBM_Report_Discard_Msg

指定の宛先に配信できなかった場合にメッセージを廃棄するようにリクエストします。詳細は、IBM WebSphereのドキュメントを参照してください。

JMS_IBM_MsgType

メッセージのタイプ。詳細は、IBM WebSphereのドキュメントを参照してください。

JMS_IBM_Feedback

レポート・メッセージの性質を示すインジケータ。詳細は、IBM WebSphereのドキュメントを参照してください。

JMS_IBM_Last_Msg_In_Group

メッセージがメッセージ・グループの最後のメッセージかどうかを示すインジケータ。詳細は、IBM WebSphereのドキュメントを参照してください。

JMS_BEA_UnitOfOrder

このヘッダーはリクエストおよびレスポンスに有効です。

31.8.3.1 トランスポート・ヘッダーの構成

パイプラインでは、インバウンド・リクエストおよびアウトバウンド・リクエストの両方についてトランスポート・ヘッダーを構成できます。メッセージのヘッダーの値を設定するには、トランスポート・ヘッダー・アクションを使用します。トランスポート・ヘッダー・アクションの追加の詳細は、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。JMSトランスポートに関連するトランスポート・ヘッダーの詳細は、「JMSトランスポート・ヘッダー」を参照してください。

注意:

JMSトランスポート・ヘッダーの制限の詳細は、「ランタイムがテスト・コンソールでトランスポート設定を使用する方法」を参照してください。表12-8も参照してください。

31.8.4 JMSトランスポートを使用するビジネス・サービスの構成

JMSビジネス・サービスを登録する場合、WSDLファイルのURIをサービス定義に追加するときに、手動で編集する必要があります。URIの形式は次のとおりです。

jms://host:port/connection_factory/jndi_destination

注意:

ビジネス・サービスでJMS IDによるレスポンス相関を使用するようにJMSリクエスト/レスポンス・アプリケーションを構成するには、次の作業を行う必要があります。

- 選択した1つのJMSサーバーをターゲットとする共通分散キューおよびローカル・キューを作成します。

- クラスタにUDQをデプロイし、すべてのJMSに対してメンバー・キューを作成するUDQのデフォルトのターゲット指定を無効にします。

次の表に、JMSベースのビジネス・サービスの構成に使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

表31-4 ビジネス・サービス用のJMSトランスポート・プロパティ

プロパティ

説明

宛先タイプ

JMS宛先タイプとして、次のいずれかを選択します。

- キュー(ポイント・ツー・ポイント宛先の場合)

- 「トピック」(パブリッシュ/サブスクライブの宛先の場合)

メッセージ・タイプ

メッセージ・タイプとして、次のいずれかを選択します。

- 「バイト」(未解釈バイトのストリームの場合)

- 「テキスト」(テキスト・メッセージの場合)

レスポンスにJavaのメッセージ・タイプを選択した場合、このオプションは無効です。

レスポンス・キュー

レスポンスの処理方法を指定するためのオプションとして、次のいずれかを選択します。

- なし: レスポンスは想定されていません。一方向の操作の場合、このオプションを選択します。

- 「すべてのリクエストURIに対して1つ」: レスポンスを扱う1つのURIを入力し、他の詳細なレスポンス構成(エンコーディングやタイムアウトなど)も設定できます。また、オプションとして、JMS/JNDI資格証明を渡すために「JMSサービス・アカウント」を選択できます。

- 「リクエストURIごとに1つ」: このオプションではレスポンス・フェイルオーバーが提供されます。各リクエストURIのレスポンスURIつまり宛先を指定できます。オプションとして、リクエストとレスポンスのペアごとにJMS/JNDI資格証明のサービス・アカウントを選択できます。

このオプションは、「宛先タイプ」が「キュー」の場合のみ使用できます。

レスポンス・パターン

次のいずれかを選択して、レスポンスの設計パターンを指定します。

- WebLogic Serverで実行するJAX-RPCサービス以外のすべてのサービスの「JMSCorrelationID」を選択します。

- WebLogic ServerでJAX-RPCサービスを実行している場合、「JMSMessageID」を選択します。

このオプションを使用できるのは、「レスポンス・キュー」フィールドでレスポンス・オプションを選択した場合のみです。詳細は、「JMSリクエスト/レスポンスのメッセージIDと相関IDのパターン」を参照してください。

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

たとえば、ビジネス・サービスがJMS転送プロトコルに対応している場合、ビジネス・サービスのエンドポイントは、そのディスパッチ・ポリシーに関連付けることのできるMDB (メッセージドリブンBean)のJARファイルになります。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

リクエストのエンコーディング

リクエストのエンコード用の文字セットを入力します。デフォルトは、UTF-8です。

レスポンスのエンコーディング

レスポンスのエンコード用の文字セットを入力します。デフォルトは、UTF-8です。

このオプションを使用できるのは、「レスポンス・キュー」フィールドでレスポンス・オプションの1つを選択した場合のみです。

レスポンス・タイムアウト

レスポンスを待機する時間を秒単位で入力します。この時間が経過すると接続が切断されます。デフォルト値は0で、レスポンスのタイムアウトがありません。

このオプションを使用できるのは、「レスポンス・キュー」フィールドでレスポンス・オプションの1つを選択した場合のみです。

クライアントJar

Javaオブジェクトを含むメッセージのデキューに使用する、クライアントJARを選択します。クライアントJARの選択によって、それがクラスパス上にあることが確認されます。このオプションは、サービスが、Javaレスポンス・タイプのメッセージング・サービスのときに使用できます。

詳細は、「メッセージでのJavaオブジェクトの送信および受信」を参照してください。

レスポンスURI

次に示すいずれかの形式で、レスポンスURIを入力します。このオプションを使用できるのは、「すべてのリクエストURIに対して1つ」レスポンス・オプションと「JMSCorrelationID」レスポンス・パターンを選択した場合のみです。

jms://host:port/connection_factory/jndi_destination

複数のサーバーをターゲットとする場合は、次の形式を使用します。

jms://host1:port,host2:port/connection_factory/jndi_destination

レスポンスURIのホストとポートを省略することもできます。次に例を示します。

jms:///connection_factory/jndi_destination

ホストとポートを省略すると、ローカル・サーバーで接続ファクトリや宛先ルックアップが発生します。これは、リクエストURIが外部接続ファクトリや宛先を指し、レスポンスをローカル・サーバーに送信する場合などに便利です。

注意: WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。

レスポンスのリクエスト

汎用の「トランスポート」ページで入力したリクエストURIごとに、「レスポンスURI」を入力します。前述の「レスポンスURI」フィールドの説明に記載されている形式とガイドラインに従います。

URIごとに、オプションで、リクエスト・キューとレスポンス・キューの両方にサービスで使用するJMS/JNDI資格証明用のサービス・アカウントを選択できます。

このオプションを使用できるのは、「JMSCorrelationID」パターンに対して「リクエストURIごとに1つ」レスポンス・オプションを選択して、レスポンス・フェイルオーバーを提供する場合です。

ターゲット - レスポンス

レスポンスを受信する「対象」サーバーの名前と「レスポンスURI」を、「レスポンスURI」フィールドの説明に従って入力します。

このオプションを使用できるのは、「JMSMessageID」パターンに対して「すべてのリクエストURIに対して1つ」レスポンス・オプションを選択した場合のみです。

接続のリクエスト

リクエストURIごとに、JMS接続ファクトリ名を入力します。この名前は、「順序番号」フィールド。名前を入力しないと、JMSトランスポートではリクエストURIの接続ファクトリが使用されます。

サービスがリクエスト・キューとレスポンス・キューの両方で使用するJMS/JNDI資格証明のためにオプションとしてサービス・アカウントを選択できます。

このオプションを使用できるのは、「JMSMessageID」パターンに対して「リクエストURIごとに1つ」レスポンス・オプションを選択して、レスポンス・フェイルオーバーを提供する場合です。

ターゲット - 宛先

各ターゲット上のリクエストURIごとにレスポンスを受信する、各ターゲット・サーバー上の宛先キューを入力します。リスト内のターゲット・サーバー(クラスタ内の管理対象サーバーなど、現行ドメインのサーバーによって判別される)ごとに、リクエストURIが「順序番号」(「接続のリクエスト」フィールドの番号に対応)順に表示されます。

このオプションを使用できるのは、「JMSMessageID」パターンに対して「リクエストURIごとに1つ」レスポンス・オプションを選択して、レスポンス・フェイルオーバーを提供する場合です。このフィールドは「接続のリクエスト」フィールドと組み合せて使用します。

注意: Service Bus開発環境では1サーバー環境しかサポートされないため、「対象」は1つしか表示されません。複数サーバー環境でこのフィールドを構成するには、このサービスをランタイム環境にデプロイし、Oracle Service Busコンソールでサービス構成を完了してください。

JMSサービス・アカウント

JMSサーバーによって管理されているJMSリソースに使用するサービス・アカウントを入力します。サービス・アカウントは、リクエストとレスポンスの両方に使用される、ユーザーIDとパスワードの別名リソースです。同じサービス・アカウントが、JMSとJNDIの両方に使用されます。

このオプションを使用できるのは、「レスポンス・キュー」フィールドで「なし」または「すべてのリクエストURIに対して1つ」オプションを使用する場合です。このフィールドは「呼出し元のサブジェクトを渡す」オプションと互いに排他的です。JMS/JNDI認証のためにいずれか1つを使用してください。

詳細は、「サービス・アカウントの操作」を参照してください。

SSLを使用

リクエストがTLS/SSL接続を通して行われる場合にのみ、このチェック・ボックスを選択します。

TLS/SSL (Secure Sockets Layer)では、ネットワークで接続される2つのアプリケーションが互いのIDを認証し、アプリケーション間で交換されるデータを暗号化できるようにすることによって、安全な接続が可能になります。認証を使用すると、サーバー(および必要に応じてクライアント)はネットワーク接続の相手側アプリケーションのIDを検証できます。また、宛先のJNDIエントリに対してアクセス制御が設定されていることにより、管理者から個々のJMS宛先(キューまたはトピック)へのアクセスが制限されている場合、JNDIツリー内でのルックアップ時に、サービスで認証を行う必要があります。「サービス・アカウント」または「呼出し元のサブジェクトを渡す」オプションを使用して認証します。

注意: JMSトランスポートでは双方向SSLはサポートされません。

有効期限

メッセージが期限切れになるまでの時間間隔(ミリ秒単位)です。デフォルト値の0を指定すると、メッセージは無期限になります。

メッセージ永続性を有効にする

メッセージ配信を保証するためにはこのチェック・ボックスを選択します。少数のメッセージの紛失が許容される場合は、このチェック・ボックスを選択解除するとスループットが向上します。このJMSメッセージ配信モードを使用すると、信頼性とスループットのバランスを取ることができます。

順序単位

メッセージ・プロデューサが処理順序に関して複数のメッセージを1つの単位にグループ化できるようになる、メッセージ順序単位を入力します。この順序単位のすべてのメッセージは、メッセージが作成された順序に従って処理する必要があります。

順序単位の使用の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。

呼出し元のサブジェクトを渡す

Service Busがメッセージを送信するときに、認証されたサブジェクトを渡すには、このチェック・ボックスを選択します。

このフィールドを有効にしたときに、ビジネス・サービスの対象が別のドメインのJMSリソースである場合は、両方のドメインのグローバル信頼を有効にします。『Oracle WebLogic Serverセキュリティの管理』のWebLogicドメインのセキュリティの構成に関する項を参照してください。

このフィールドは「サービス・アカウント」オプションと互いに排他的です。JMS/JNDI認証のためにいずれか1つを使用してください。

JNDIタイムアウト

JNDIツリーで宛先ファクトリまたは接続ファクトリを検索する際に、JNDI接続がタイムアウトするまでの時間(秒単位)を入力します。

デフォルト値0では接続のタイムアウトは行われません。

32 ローカル・トランスポートの使用

この章では、ローカル・トランスポートの概要と、プロキシ・サービスでの使用および構成方法について説明します。

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

- ローカル・トランスポートの概要

- ローカル・トランスポート・プロキシ・サービスの使用

- プロキシ・サービス間でのSOAPフォルトの伝播

- ローカル・プロキシ・サービスでのOWSMセキュリティの使用

32.1 ローカル・トランスポートの概要

Service Busプロジェクトでは、プロキシ・サービス・ロジックはクライアントに公開されますが、ロジックの公開を望まない場合があります。この場合、ローカル・トランスポート・プロキシ・サービスの後方にロジックを設計して、他のService Busプロジェクトからそのプロキシ・サービスを呼び出すことができます。たとえば、バックエンド・サービスを呼び出すサービスがいくつかある場合、ローカル・プロキシ・サービスを含む個別のプロジェクトを作成して、すべてのバックエンド(未公開)・ロジックを定義できます。特定の処理ロジックをすべてのクライアントに対して非公開にしながら、他のService Busプロジェクトからそのローカル・プロキシ・サービスを呼び出すことができます。

ローカル・プロキシ・サービスは、他のプロジェクトに含まれるパイプラインをコールする唯一の方法でもあります。すべてのパイプラインが同じService Busプロジェクトに含まれている場合、1つのパイプラインから別のパイプラインを直接コールできます。ただし、1つのパイプラインから異なるプロジェクト内のパイプラインを直接コールすることはできません。これを行うには、パイプライン間でローカル・プロキシ・サービスを使用する必要があります。ローカル・トランスポートには次の機能があります。

- 効率的でセキュアな通信。

- トランザクションとトランザクション動作の伝播。

- IDをエンド・ツー・エンドで伝播できるようなセキュリティ・コンテキストの伝播。また、セキュリティ・コンテキストの伝播により、サービスのチェーンに含まれる最初のプロキシ・サービスのクライアントを、チェーン内で以降に呼び出されるプロキシ・サービスが認可できるようになり、詳細なアクセス制御がサポートされます。

32.1.1 ローカル・トランスポート・プロキシ・サービスの機能と特性

ローカル・トランスポート・ベースのプロキシ・サービスは、その他のプロキシ・サービスまたはパイプラインからのみ呼び出すことができ、その他のクライアントからは呼び出せません。呼出しはService Busによって最適化されます。ローカル・プロキシ・サービスにURIはありませんが、ローカル・トランスポート・プロキシ・サービスによってサポートされるサービスとインタフェースのタイプには制約はありません。1つの例外は、SAMLがパス・スルー・シナリオでのみサポートされることです。

呼出しを行うサービスのサービス品質(QoS)がExactly Onceに定義されている場合、そのサービスのトランザクションは、ローカル・トランスポート・プロキシ・サービスに伝播されます。つまり、呼び出されたローカル・トランスポート・プロキシ・サービスは呼出しを行ったサービスのトランザクション動作を継承します。

プロキシ・サービスはトランスポート・レベルまたはメッセージ・レベルで認証を行うことができます。メッセージ・レベルが有効な場合は、メッセージ・レベルで認証されたクライアントが有効になります。メッセージ・レベルで認証されたクライアントが有効でない場合は、トランスポート・レベルで認証されたクライアントが有効になります(トランスポート・レベルが有効な場合)。メッセージ・レベルおよびトランスポート・レベルで認証されたクライアントのいずれも有効になっていない場合、匿名のクライアントが有効なクライアントになります。

プロキシ・サービスがローカル・トランスポート・プロキシ・サービスを呼び出す場合、呼出しを行うサービスの有効なクライアントが、呼び出されるローカル・プロキシ・サービスのトランスポート・レベルのクライアントになります。ローカル・トランスポート・プロキシ・サービスでは、アクセス制御ポリシーを使用して、このクライアントにアクセスを認可できます。この方法により、エンド・ツー・エンドのメッセージ・フロー全体で、最初のサービスのクライアントを、後続のすべてのプロキシ・サービスに伝播できます。

ローカル・トランスポート・プロキシ・サービスは、ユーザー定義のトランスポート・ヘッダーをサポートします。プロキシ・サービスでHTTPトランスポートを使用するシナリオを想定してください。パイプラインを介してローカル・プロキシ・サービスへのルーティングが実行され、そのパイプラインはトランスポート・ヘッダー・アクションを使用して、ヘッダーをローカル・プロキシ・サービスに渡します。このシナリオでは、HTTPプロキシ・サービスがContent-Typeヘッダーを受け取った場合、このヘッダーをユーザー・ヘッダーとしてローカル・トランスポートで使用できるため、型付きのトランスポート・ヘッダーとしてではなく、標準のユーザー・ヘッダーを使用してアクセスできます。

32.2 ローカル・トランスポート・プロキシ・サービスの使用

ローカル・トランスポート・プロキシ・サービスは、メッセージ・フローの一部を非公開のままにし、その他の部分を公開する場合に役立ちます。たとえば、バックエンド処理を定義するプロジェクトがあり、それらのプロジェクトを、アラートやフォルト処理などのフロントエンド・ロジックを定義するプロジェクトからコールする場合があります。バックエンド・プロジェクトのローカル・プロキシ・サービスを使用すると、これらは非公開のままになります。

フロントエンド・プロジェクト内のパイプラインは、メッセージをローカル・トランスポート・プロキシ・サービスにルーティングします。複数のパイプラインや複数のプロジェクトから、同じローカル・プロキシ・サービスをコールできます。次の図に、HTTPプロキシ・サービスを含むプロジェクトと、JMSプロジェクト・サービスを含むプロジェクトによって呼び出されるローカル・プロキシ・サービスを示します。

図32-1 ローカル・トランスポート・プロキシ・サービスの使用

32.2.1 以前の使用方法からの変更点

Service Busの以前のバージョンでは、タイプが任意のSOAPまたは任意のXMLであるプロキシ・サービスが、異なるエンタープライズ・システムに対するフロントエンドとして機能する場合に、ローカル・トランスポートを使用できました。このフロントエンド・プロキシ・サービスは、適切なローカル・トランスポートへの汎用ルーターです。Service Busの現在のバージョンでは、プロキシ・サービスとは別にパイプラインを作成できるため、このようなローカル・トランスポートの使用方法は廃止されました。図32-2および図32-3に示すように、ローカル・プロキシ・サービスをパイプラインに置き換えることができます。

以前のバージョンと同様、動的ルーティングを使用して実行時にルーティング・ルールを抽象化し、メッセージをローカル・トランスポート・プロキシ・サービスにルーティングできます。動的ルーティングの使用例については、「動的ルーティングの使用」を参照してください。

次の図は、リリース11gのこのシナリオで、ローカル・トランスポートがどのように使用されるかを示しています。

図32-2 以前のバージョンにおける複数のビジネス・サービスへのアクセス

現在のリリースでは、前述の11gのシナリオが更新され、次に示すように、パイプラインがローカル・プロキシ・サービスのかわりに使用されます。

図32-3 更新された方法による複数のビジネス・サービスへのアクセス

32.3 プロキシ・サービス間でのSOAPフォルトの伝播

ローカル・プロキシ・サービスをチェーンすると、$fault変数のSOAPフォルトは、あるプロキシ・サービスからパイプラインを経由して別のプロキシ・サービスに自動的に伝播されません。次に例を示します。

Client > Proxy1 > Pipeline > Proxy2 > Business Service > Back-end Service

バックエンド・サービスでSOAPフォルトが発生すると、そのフォルトはProxy2の$fault変数に伝播されます。ただし、Proxy2のSOAPフォルトの値は、Proxy1の$fault変数に自動的に伝播されないため、クライアントに戻されません。

SOAPフォルトをあるプロキシから別のプロキシに伝播するには:

1. パイプラインで、失敗時の返信アクションを含むエラー・ハンドラを追加します。これにより、$body変数にフォルト情報を格納したSOAPメッセージが戻されます。詳細は、「コンソールでの返信アクションの追加」を参照してください。

2. パイプラインで、目的のSOAPエラーの詳細をクライアントに戻すには、必要に応じて$body変数を変換します。

Service BusによるSOAPフォルトの処理方法の詳細は、「エラー・メッセージの生成、レポート、および返信」を参照してください。

32.4 ローカル・プロキシ・サービスでのOWSMセキュリティの使用

Oracle Web Services Manager (OWSM)のサービス・ポリシーをWSDLサービス・タイプのローカル・プロキシ・サービスにアタッチして、各ローカル・プロキシに着信するメッセージに特定のセキュリティ制御を適用できます。この項では、プロキシ・サービスがセキュリティ・ヘッダーを含むメッセージをローカル・プロキシ・サービスにパイプライン経由で転送する場合に、Service Busが実行時にポリシーを処理する方法について説明します。メッセージ転送は、ルーティング、サービス・コールアウト、パブリッシュなどのアクションを通じて発生します。

プロキシ・サービスは、メッセージを他のプロキシ・サービスに転送する場合に、アウトバウンドWS-Security処理を実行しません。この項の図は、この動作を説明しており、プロキシ間接続の異なるシナリオにおけるWS-Security構成を示しています。他のプロキシ・サービスからメッセージを受信するローカル・プロキシ・サービスで適切にOWSMサービス・ポリシーを使用できるように、これらのシナリオを使用してその動作を理解してください。

図32-4は、次のいずれかの特徴を持つフロントエンド・プロキシにメッセージを送信するクライアント・ポリシーが適用されたクライアントを示しています。

- フロント・エンド・プロキシが、アクティブであり、リクエストのすべてのWS-Securityヘッダーまたはそれらのヘッダーのサブセットのみに対してインバウンド処理を実行するOWSMポリシーを含む場合。たとえば、リクエストに認証ヘッダーとメッセージ保護ヘッダーの両方が含まれる場合、認証ポリシーは処理されますが、メッセージ保護ポリシーは処理されません。プロキシには、OWSMログ・ポリシーなどのセキュリティ以外のポリシーも含まれることがあります。

- フロント・エンド・ポリシーが、パッシブであり、OWSMポリシーを含む場合。

- フロント・エンド・プロキシがOWSMポリシーを含まない場合。

どの場合でも、フロントエンド・プロキシ・サービスは、メッセージ内に少なくとも1つのセキュリティ・ヘッダーを検出します。プロキシ・サービスは、アウトバウンドWS-Security処理を実行せずにこのメッセージをパイプラインに渡し、パイプラインは、メッセージをローカル・プロキシ・サービスに渡します。ローカル・プロキシ・サービスは、OWSMポリシーを含む場合と含まない場合があります。

図32-4では、予期されるセキュリティ・ヘッダーがメッセージに含まれるため、ローカル・プロキシ・サービス2は例外をスローせずにメッセージを受信します。セキュリティ処理を部分的に実行するポリシーをフロントエンド・プロキシ・サービスが含む場合でも(認証処理は行うがメッセージ保護処理は行わないなど)、転送されたメッセージには引き続きセキュリティ・ヘッダーが含まれます。

図32-4 ローカル・プロキシにセキュリティ・パス・スルーを行うフロントエンド・プロキシ

図32-5は、フロントエンド・プロキシ・サービスにメッセージを送信するクライアント・ポリシーが適用されたクライアントを示しています。フロントエンド・プロキシ・サービスは、アクティブであり、メッセージのすべてのWS-Securityヘッダーを処理するOWSMサービス・ポリシーを含みます。インバウンド・サービス・ポリシーが処理され、そのセキュリティ・ヘッダーのメッセージが削除されます。フロントエンド・プロキシ・サービスは、他のプロキシにメッセージを転送するため、アウトバウンドWS-Security処理は実行されず、セキュリティ・ヘッダーのないメッセージがローカル・プロキシ・サービスに転送されます。一方のローカル・プロキシ・サービスには、セキュリティ・ヘッダーを予期しているOWSMサービス・ポリシーが含まれており、セキュリティ・ヘッダーのないメッセージが到着すると例外がスローされます。他方のローカル・プロキシには、セキュリティ・ポリシーではなく施行の発生しないOWSMポリシーが含まれているため、セキュリティ・ヘッダーのないメッセージは正常にパススルーされます。

図32-5 ローカル・プロキシへの転送前にすべてのセキュリティ・ヘッダーを処理するフロント・エンド・プロキシ

33 MQトランスポートの使用

この章では、MQトランスポートの概要と、サービスでの使用および構成方法について説明します。MQトランスポートにより、IBM WebSphere MQへのアクセスが提供され、インバウンド接続とアウトバウンド接続の両方がサポートされます。

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

- MQ転送について

- MQトランスポートの環境の設定

- MQ接続の操作

- MQトランスポートのエラー処理

- WebSphere JMS MQインタフェースの使用

- MQトランスポート構成のリファレンス

- MQトランスポート・ヘッダー

33.1 MQトランスポートの概要

MQトランスポートにより、Service BusコンポーネントとIBM WebSphere MQとの間にネイティブの接続が提供されます。MQプロキシ・サービスではWebSphere MQからのメッセージの受信が可能で、MQビジネス・サービスではWebSphere MQへのメッセージのルーティングが可能です。

WebSphere MQの基礎概念の詳細は、IBM WebSphere MQのドキュメントを参照してください。

33.1.1 MQトランスポートの機能

MQトランスポートによってService Busに提供される機能は、次のとおりです。

- インバウンドおよびアウトバウンド接続。MQプロキシ・サービスではWebSphere MQからのメッセージの受信が可能で、MQビジネス・サービスではWebSphere MQへのメッセージのルーティングが可能です。

- WebSphere MQへのアクセス。詳細は、「環境へのMQクライアント・ライブラリの追加方法」を参照してください。

- メッセージをXML、バイナリ、XML、テキスト、およびMFLの任意の種類で送受信可能です。

- すべてのMQメッセージ記述子(MQMD)ヘッダーの処理。メッセージ記述子は、送信または受信されたメッセージのプロパティを表す属性です。構成可能なMQヘッダーのリストについては、「MQトランスポート・ヘッダー」を参照してください。

- キュー・マネージャに接続するためのTCP/IPおよびバインディング・モード。TCP/IPモードでは、リモートのWebSphere MQサーバーに接続します。バインド・モードでは、ローカルのWebSphere MQに接続します。

- インバウンドおよびアウトバウンド・トランスポートにおける一方向および双方向SSL (TCP/IP接続が使用される場合のみ)。

33.1.2 MQトランスポートの利点

WebSphere MQ JMSインタフェースを使用する場合と比べて、MQトランスポートの使用には次のような利点があります。

- MQトランスポートを使用すると、WebSphere MQ JMSインタフェースを使用した場合に比べ、WebSphere MQへの接続がより高速に行えます。

- MQメッセージを読込みおよび生成する機能。JMSインタフェースの使用では、特定のヘッダーは設定できません。

- MQ受信メッセージの送受信のサポート。

- WebLogicのJNDIへのMQ接続ファクトリおよびMQキューの明示的なバインディングは不要です。

- Service Busの範囲外にあるJMSプロバイダのようなリソースの構成は不要です。

- メッセージが、JMSトランスポートを使用したチャネリングではなく、トランスポートを使用して直接送信されるため、パフォーマンスが向上します。

33.1.3 メッセージング・パターン

MQトランスポートでは、一方向メッセージおよびリクエスト/レスポンス・メッセージング・パターンがインバウンドおよびアウトバウンド接続の両方でサポートされます。デフォルトのパターンは一方向メッセージングです。プロキシ・サービスまたはビジネス・サービスでは、サービスの構成時に「レスポンスが必要」オプションを設定すると、リクエスト/レスポンス・メッセージングがサポートされます。

インバウンドおよびアウトバウンド・トランスポートでは、リクエストとレスポンス間の相関にmessageIDまたはcorrelationIDを使用する非同期のリクエスト/レスポンス・パターンをサポートします。サービスの構成時にレスポンス相関パターンを設定できます。詳細は、「MQトランスポート・ヘッダー」の「CorrelationID」と「MessageID」を参照してください。

アウトバウンド・トランスポートには、相関IDとメッセージIDを自動生成するか、パイプラインで指定したものを使用するオプションが用意されています。トランスポートによって相関IDとメッセージIDが自動生成される必要があることを指示するには、「相関値の自動生成」オプションを選択します。このオプションを選択しなかった場合、Service Busはパイプラインで指定された値を使用します。MQの実装で動的キューを使用する場合、アウトバウンド・トランスポートのレスポンス相関に動的キューを使用できます。

相関値(messageID/correlationID)を自動生成しない場合に、管理対象サーバーがダウンすると、サーバーの再起動時に残っているレスポンス・メッセージが削除されなくなることがあります。Oracleでは、リクエストの有効期限(Expiry)ヘッダーを有限な値に構成し、レポート(Report)ヘッダーにMQC.MQRO_PASS_DISCARD_AND_EXPIRYオプションを設定することをお薦めします。MQC.MQRO_PASS_DISCARD_AND_EXPIRYオプションは、返信のメッセージ記述子がリクエスト・メッセージの有効期限(Expiry)ヘッダー値から継承される必要があるという、受信クライアントに対する指示として機能します。これにより、構成された有効期限の経過後にMQサーバーによってレスポンス・メッセージが確実に削除されるようになります。相関値が自動生成される場合、残っているレスポンス・メッセージのクリーン・アップはService Busサーバーによって実施されます。

MQトランスポートではリモート・トランザクションではなくローカル・トランザクションがサポートされます。

サービスの「レスポンスが必要」、「レスポンス相関パターン」、「相関値の自動生成」の構成の詳細は、「MQトランスポートを使用するプロキシ・サービスの構成」および「MQトランスポートを使用するビジネス・サービスの構成」を参照してください。

33.1.4 MQ接続リソース

MQ接続は、複数のMQプロキシ・サービスおよびビジネス・サービスで再使用できる、共有可能なリソースです。MQ接続リソースは、MQキュー・マネージャに接続するために必要な接続パラメータを提供します。MQベースのプロキシ・サービスまたはビジネス・サービスを作成するには、MQ接続リソースを作成および構成する必要があります。詳細は、「MQ接続の操作」を参照してください。

33.1.5 サービスの品質

インバウンド・トランスポートがMQで、アウトバウンド・トランスポートのサービスの品質(QoS)がexactly-onceである場合、結果として得られるQoSはat-least-onceになります。アウトバウンド・トランスポートのQoSのデフォルトはexactly-onceです。

注意:

パイプライン・エラー・ハンドラに、(任意の再試行ロジックを含む)エラー処理ロジックを作成する必要があります。エラー処理の構成の詳細は、「JDeveloperでのエラー・ハンドラの追加」および「コンソールでのエラー・ハンドラの追加」を参照してください。

アウトバウンドがリクエスト/レスポンスの場合、アウトバウンド・トランスポートがexactly-once QoSをサポートするように構成されているときのみ、QoSはat-least-onceになります。Service BusメッセージングのQoSの詳細は、「サービスの品質」を参照してください。

33.1.6 マルチインスタンス・キュー・マネージャのサポート

MQトランスポートが更新され、マルチインスタンス・キュー・マネージャがサポートされています。

この機能はIBM MQ 7から導入されており、キュー・マネージャでプライマリと警告スタンバイの2つのホストを使用可能にします。プライマリ・ホストが失敗すると、マルチインスタンス・キュー・マネージャがスタンバイ・サーバーで自動的に再起動します。MQトランスポートは、メッセージ受信時にキュー・マネージャに接続しようとします。その時点でプライマリMQインスタンスが停止している場合、次に使用可能なインスタンスがチェックされ、スタンバイ・インスタンスへ新しく接続されます。ストレージは、プライマリおよびすべてのスタンバイ・サーバーで共有されるため、メッセージは新しいアクティブなインスタンスに移動します。プライマリMQサーバーがスタンバイ・サーバーにフェイルオーバーすると、スタンバイ・サーバーはプライマリ・サーバーのロールを持ちます。

マルチインスタンス・キュー・マネージャのサポートが有効な場合にMQ接続を確立するには、「MQ接続の作成方法」を参照してください。

33.1.7 MQクラスタとMQトランスポート

WebSphere MQのクラスタ・サポートは、ストア・アンド・フォワード・メッセージングであり、ロード・バランシングおよびフェイルオーバーではありません。WebSphere MQのクラスタ・キューは、キュー・マネージャの1つにローカルで作成され、共有キューに対してリモート・フォワーダとして動作する他のクラスタ・メンバーと共有されます。MQトランスポートからのリクエストは、ロード・バランシング・アルゴリズムを使用してクラスタのメンバーにメッセージを送信することによってロード・バランシングされます。ただし、トランスポートは、ローカル・キューへの参照を保持するMQサーバー・ノードにアクセスすることによってのみ、メッセージを受信します。

33.1.8 MQトランスポートの制限

MQトランスポートの制限は次のとおりです。

- MQプロキシ・サービスに基づくリクエスト/レスポンス・プロキシ・サービスを、次の方法で呼び出すことはできません。

- ルート・アクションまたは動的ルーティングおよびルーティング表アクションを使用して構成されているプロキシ・サービスから。
サービス・コールアウト・アクションを使用して。

- ターゲットがMQトランスポートに基づくリクエスト/レスポンス・プロキシ・サービスである場合、サービス・コールアウトを使用してプロキシ・サービスを呼び出すことはできません。

- Service Busテスト・コンソールで、リクエスト/レスポンスMQプロキシ・サービスへの間接呼出しは使用できません。

33.2 MQトランスポートの環境の設定

Service BusはIBM WebSphere MQのクライアントであり、Service Busではサポート対象のWebSphere MQバージョンについて実行時のサーバー互換性をサポートしていますが、これらのMQライブラリはService Busとともにインストールされません。使用するドメインで、MQクライアント・ライブラリcom.ibm.mq.jarのサポート対象のバージョンを利用できるようにする必要があります。

Service BusでのWebSphere MQバージョンのサポートについては、『Oracle Service Busの管理』の相互運用性のシナリオと考慮事項に関する項を参照してください。WebSphere MQのシステム要件の詳細は、http://www-306.ibm.com/software/integration/wmq/requirements/index.htmlを参照してください。

33.2.1 環境へのMQクライアント・ライブラリの追加方法

1. ドメイン・サーバーを停止します。

2. WebSphere MQのインストールから、com.ibm.mq.jarファイルをService BusドメインのDOMAIN_HOME/libディレクトリにコピーします。

3. ドメイン・サーバーを再起動します。

33.2.2 環境変数の構成方法

Service Busと同じマシン上にあるMQキュー・マネージャに接続するためにバインド・モードを使用する場合は、PATH環境変数に<MQ_install_directory>/binおよび<MQ_install_directory>/java/libを追加します。

33.3 MQ接続の操作

MQトランスポートを使用するようにプロキシ・サービスまたはビジネス・サービスを構成するには、MQサーバーへの接続を定義するMQ接続リソースを作成しておく必要があります。MQ接続は、複数のMQプロキシ・サービスおよびビジネス・サービスで再使用できる、共有可能なリソースです。MQプロキシ・サービスおよびビジネス・サービスは、MQキューにアクセスする前に、MQキュー・マネージャに接続する必要があります。MQ接続リソースは、MQキュー・マネージャに接続するために必要な接続パラメータを提供します。

各MQ接続リソースには、接続プールがあります。同じMQ接続リソースを使用してキュー・マネージャへの接続を取得しているすべてのビジネス・サービスまたはプロキシ・サービスは、そのリソースに対して作成された同じ接続プールを使用します。つまり、同じキュー・マネージャを使用している複数のビジネス・サービスまたはプロキシ・サービスは、接続プールを共有することになります。

33.3.1 MQ接続の作成方法

Oracle Service BusコンソールでMQ接続を作成するオプションは、MQクライアント・ライブラリをドメインに追加しないと利用できません。JDeveloperでは、ライブラリを使用せずに接続を作成できますが、ランタイムのライブラリが必要になります。

始める前に:

「MQトランスポートの環境の設定」の手順に従い、MQクライアント・ライブラリを使用できるようにします。

MQ接続の作成に必要な次のリソースを作成したことを確認します。

- サービス・アカウント

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

MQ接続を作成するには:

1. 次のいずれかを行います:

- JDeveloperの場合: アプリケーション・ナビゲータで、新しいMQ接続を含めるプロジェクトまたはフォルダを右クリックして、「新規」をポイントし、「MQ接続」を選択します。

- Oracle Service Busコンソールの場合: プロジェクト・ナビゲータで、新しいMQ接続を含めるプロジェクトまたはフォルダを右クリックして、「作成」をポイントし、「リソース」を選択します。「その他」をクリックし、「MQ接続」、「OK」の順にクリックします。

2. このMQ接続の一意の名前と、必要に応じて説明を入力します。
エンドポイントURIに空白を含めることはできません。そのため、空白を含む名前のMQ接続リソース、プロジェクトまたはフォルダを作成しないでください。

3. 「作成」または「終了」をクリックします。
MQ接続定義エディタが表示されます。

4. 「接続タイプ」フィールドで、MQキュー・マネージャに接続する次のいずれかのモードを選択します。

- mqTcpModeType: Service Busと同じマシンに存在しないキュー・マネージャに接続するには、TCP/IPを使用します。

- mqBindingModeType: Service Busと同じマシンに存在するキュー・マネージャに接続するには、バインド・モードを使用します。

エディタのフィールドは、選択内容に応じて変わります。

5. MQサーバーに関する次の情報を構成します。

- マルチインスタンス・キュー・マネージャ使用可能: 選択し、マルチインスタンス・キュー・マネージャのサポートを有効にします。TCPモード接続にのみ使用します。

- MQ接続リスト: このフィールドは、host1:port1,host2:port2の形式でMQ接続のカンマ区切りリストを受け入れます。このフィールドは、「マルチインスタンス・キュー・マネージャ使用可能」オプションが選択されている場合のみ有効です。

- MQホスト名: MQキュー・マネージャのホスト名。TCPモード接続にのみ使用します。このフィールドは、「マルチインスタンス・キュー・マネージャ使用可能」オプションが選択されていない場合のみ有効です。

- MQポート番号: MQキュー・マネージャ・リスナーのポート番号。TCPモード接続にのみ使用します。このフィールドは、「マルチインスタンス・キュー・マネージャ使用可能」オプションが選択されていない場合のみ有効です。

- MQキュー・マネージャ名: 接続先のMQキュー・マネージャの名前を入力します。

- MQキュー・マネージャのチャネル名: キュー・マネージャのサーバー接続チャネルの名前を入力します。TCPモード接続にのみ使用します。

- キュー・マネージャCCSID: 接続を確立するときに使用されるコード化文字セット識別子(CCSID)です。これはTCPモード接続にのみ使用され、主に国際化をサポートする目的で使用されます。

6. TCPモード接続のSSLサポートを構成するには、次のようにします。

a. メッセージの送信にSSLを使用するよう「SSLが必要」チェック・ボックスを選択します。これで、サービス側のSSL認証が有効になります。

b. 「暗号セット」フィールドで、SSLが使用する暗号スイート・アルゴリズムを選択します。
暗号スイート・アルゴリズムは、サーバーとクライアントとの間のメッセージ通信を暗号化および復号化する際に使用されます。

c. クライアント側およびサーバー側のSSL認証をどちらも有効にするには、「双方向SSLが必要」チェック・ボックスを選択します。

d. 双方向SSLを選択した場合、サービス・キー・プロバイダへの参照フィールドで、「参照」アイコンをクリックして、使用するサービス・キー・プロバイダを見つけて選択します。

7. 「静的なサービス・アカウントへの参照」フィールドで、「参照」アイコンをクリックして、使用するサービス・アカウントを見つけて選択します。

8. 「MQバージョン」フィールドで、使用するMQサーバーのバージョンを選択します。

9. MQ接続を構成するには、次のようにします。

a. 「MQ接続プール・サイズ」フィールドに、接続プールで保持される接続の数を入力します。

b. 「MQ接続タイムアウト」フィールドに、未使用の接続が破棄されるまでの時間間隔を秒単位で入力します。デフォルトは1800秒です。

c. 「MQ接続の最大待機時間」フィールドに、接続が利用可能になるまでに待機する最大時間(ミリ秒単位)を入力します。
その時間内に接続が確立されない場合、Service Busが例外をスローします。デフォルトは3000ミリ秒です。

d. この接続によって処理されるトランザクションが分散(XA)トランザクションである場合は、「XA有効」を選択します。
永続性を確保するには、キューを構成する必要があります。バージョン5.3または6.0 (いずれも非推奨)を使用している場合は、クラスパスにcom.ibm.mqetclient.jarファイルを追加します。

10. ツールバーで、「保存」をクリックします。

11. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

33.3.2 MQ接続の編集方法

MQ接続を作成すると、その情報を再構成できます。

MQ接続を編集するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、編集するMQ接続を含むプロジェクトとフォルダを開きます。

2. MQ接続名を右クリックして、「開く」を選択します。

3. 「MQ接続の作成方法」で説明するフィールドを変更します。オンライン・ヘルプに詳しい説明が記載されています。

4. 変更が完了したら、ツールバーで「保存」をクリックします。

5. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

33.3.3 MQ接続の削除方法

MQ接続を削除する前に、その接続がMQトランスポートで現在使用されていないことを確認します。使用されている場合、削除する前に、プロキシ・サービスまたはビジネス・サービス構成からその接続を削除します。MQ接続が他のリソースで参照される場合でも、その接続を削除できますが、削除されたリソースに対する未解決の参照が原因で競合が生じることがあります。

コンソールとJDeveloperの両方で、参照と依存関係があるかどうかを確認できます。Oracle Service Busコンソールの場合、MQ接続定義エディタでMQ接続を開き、右上にある「ツール」をクリックして「参照」を選択し、サービスで参照を使用しているかどうかを調べます。JDeveloperの場合、MQ接続を右クリックして、「依存性の参照」を選択します。

MQ接続を削除するには:

1. アプリケーション・ナビゲータまたはプロジェクト・ナビゲータで、削除するMQ接続を含むプロジェクトとフォルダを開きます。

2. MQ接続の名前を右クリックして、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに、MQ接続の参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

33.4 MQトランスポートのエラー処理

次のように、MQトランスポート・ビジネス・サービスを構成して、アプリケーション・エラーおよび通信エラーを処理できます。

- アプリケーション・エラー: アプリケーション・エラーが発生した場合に、ビジネス・サービスのエンドポイントURIを再試行するかどうかを指定できます。詳細は、ビジネス・サービス定義エディタの「アプリケーション・エラーの再試行」フィールドに関して提供されているオンライン・ヘルプを参照してください。

- 通信エラー: 通信エラーが発生した場合に、ビジネス・サービスのURIがオフラインになるように構成できます。詳細は、『Oracle Service Busの管理』のビジネス・サービス用のエンドポイントURIの管理とモニターに関する項を参照してください。

33.5 WebSphere JMS MQインタフェースの使用

次の項では、Service BusがWebSphere MQへ接続する方法について概説し、WebSphere MQとService Bus間の通信で使用されるメッセージ・タイプのいくつかについて概要を示します。

- WebSphere MQ JMSインタフェースの使用

- MQメッセージングのタイプ

- WebSphere MQのチューニング

33.5.1 WebSphere MQ JMSインタフェースの使用

Service Busは、WebSphere MQ JMSインタフェースを介してWebSphere MQに接続します。つまり、Service BusはWebSphere MQ JMSクライアントです。Oracle WebLogic Serverの外部JMSサーバーでは、WebSphere MQサーバーに対する初期コンテキスト・ファクトリ、接続ファクトリおよびキューを指定します。詳細は、『Oracle WebLogic Server JMSリソースの管理』の外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成に関する項を参照してください。

WebSphere MQ JMSでは、2種類のトランスポート方式がサポートされます。

- BINDINGS

- CLIENT

WebSphere MQ JMSクライアントがキュー・マネージャと物理的に同じマシン上で実行されている場合は、トランスポートのタイプをBINDINGSに設定します。それ以外の場合は、CLIENTタイプのみ使用できます。

WebSphere MQは、次の2通りの方法でService Busと対話できます。

- Service BusがWebSphere MQのフロントエンドとして機能し、他のアプリケーションからのサービス・リクエストを受け入れ、それらをWebSphere MQリクエストに変換します。図33-1を参照してください。

- WebSphere MQがService Busを介して他のアプリケーションにメッセージを送信します。図33-2を参照してください。

図33-1 Service Busフロントエンド

図33-2 Service Busを介して送信されるメッセージ

33.5.2 MQメッセージングのタイプ

Service Busでは、次のメッセージングのタイプがサポートされます。

- 非永続メッセージング

- 非XA永続メッセージング

- XAメッセージング

33.5.2.1 非永続メッセージング

リクエストが欠落しているなど、信頼性のない配信を受け入れる場合、必要に応じて非永続メッセージを使用できます。WebSphere MQのロギングとWebLogic JMSメッセージの永続化は永続メッセージに対してのみ実行されるため、非永続メッセージを使用すると関連するI/Oアクティビティが不要になります。

注意:

非永続メッセージのスループットは、通常はマシンのプロセッサ速度によって制限されます。ただし、物理メモリーが不足している場合は、サーバー・システムがページングI/OでCPUサイクルを消費することがあります。

33.5.2.2 非XA永続メッセージング

WebSphere MQ永続メッセージのスループットは、通常はキュー・マネージャおよびログへの書込みのI/Oレイテンシによって制限されます。

33.5.2.3 XAメッセージング

キューへのトランザクション(XA)アクセスのサポートを有効にするには、次のいずれかのトランスポート・タイプを使用します。

- Service BusがIBM WebSphere MQと同じマシン上にある場合は、BINDINGSを使用してキュー・マネージャにアクセスします。

- Service BusとIBM WebSphere MQが異なるマシン上に存在する場合はCLIENTを使用します。ただし、CLIENTを使用する場合、XAトランザクションをサポートするIBM WebSphere MQクライアントの特殊なバージョンが必要です。このバージョンは、WebSphere MQ Extended Transaction Clientと呼ばれます。

ヒント:

デプロイメント記述子をXA対応リソース(JMS、TUXEDO、EJB)に適切に設定するには、プロキシ・サービスを作成する前に、参照接続ファクトリのXA属性を設定する必要があります。

33.5.3 WebSphere MQのチューニング

Service Busとともに使用する場合、WebSphere MQのチューニングには次のガイドラインが役に立ちます。WebSphere MQ固有の情報については、関連するWebSphere MQのドキュメントを参照してください。

- Service Busおよびキュー・マネージャが同じマシンにデプロイされている場合は、トランスポートのタイプとしてBINDINGSを使用します。

- アプリケーション・リクエストのごく一部にのみXAが必要な場合は、別の接続オブジェクトを作成してXAを無効にします。

- アクティブ・ログを多くのボリュームに分散させます。システムで高い永続メッセージ・スループットを処理する必要がある場合は、他のデータ・セットの使用との競合を最小限に抑えるために、高速の直接アクセス・ストレージ・デバイス(DASD)にログ・ファイルを置く必要があります。各アクティブ・ログを使用率の低い個別のボリュームに割り当てることをお薦めします。

- バッファ・オーバーフローを削減するために、バッファ・プールとページ・セットをチューニングします。バッファ・オーバーフローにより、ハード・ディスクのフラッシュが発生します。

- Service Bus JMSからMQキューへの接続が切断されないように、アクティブなチャネル数を増やして100を超えるようにします。デフォルトでは、アクティブなチャネル数は10です。

33.6 MQトランスポート構成のリファレンス

プロキシ・サービスでMQトランスポートを使用すると、WebSphere MQからメッセージを取得できます。ビジネス・サービスでMQトランスポートを使用すると、WebSphere MQにメッセージを送信できます。この項では、Service Bus環境にWebSphere MQを追加する方法、Service Bus MQトランスポートの特性、およびMQプロキシ・サービスやビジネス・サービスを構成する方法について説明します。

- MQトランスポートのエンドポイントURI

- MQトランスポートを使用するプロキシ・サービスの構成

- MQトランスポートを使用するビジネス・サービスの構成

- MQトランスポートの環境値

33.6.1 MQトランスポートのエンドポイントURI

MQプロキシ・サービスまたはビジネス・サービスを作成する際は、次の形式でエンドポイントURIを指定します。

mq://local-queue-name?conn=mq-connection-resource-ref

説明:

- ここで、local-queue-nameはMQサーバーに構成されているローカル・キューの名前です。

- mq-connection-resource-refはMQ接続リソースの場所です。

たとえば、mqConnectionという名前のMQ接続リソースをdefaultMQフォルダに作成し、キュー名がtestQueueである場合、URIはmq://testQueue?conn=defaultMQ/mqConnectionになります。

注意:

エンドポイントURIには空白を含めることができないため、名前にスペースを入れてMQ接続リソース、プロジェクトまたはフォルダを作成しないでください。

33.6.2 MQトランスポートを使用するプロキシ・サービスの構成

MQトランスポートのプロキシ・サービスを構成するには、「MQ接続の作成方法」で示すようにMQ接続を作成する必要があります。サービスの構成時に、サービス・タイプとしてメッセージまたは任意のXMLを選択します。詳細は、「プロキシ・サービスの作成と構成」を参照してください。

次の表に、プロキシ・サービス用のMQトランスポートの構成に使用するプロパティを示します。

表33-1 プロキシ・サービス用のMQトランスポート・プロパティ

プロパティ

説明

レスポンスが必要

アウトバウンド・メッセージの送信後にレスポンスを受け取ることを指定する場合は、このオプションを選択します。

レスポンス相関パターン

MessageIDまたはCorrelationIDを選択して、レスポンス相関パターンがどちらのIDに基づく必要があるかを指定します。

このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。

MQレスポンスURI

レスポンスがパブリッシュされる宛先を入力します。次のようにエンドポイントURIと同じ形式でレスポンスURIを入力します。

mq://local-queue-name?conn=mq-connection-resource-ref

説明:

- local-queue-nameは、レスポンスが送信されるMQキューの名前。

- mq-connection-resource-refは、MQ接続リソースの名前とパス(プロジェクト/フォルダ)です。たとえば、default/my_MQconnection。

このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。

レスポンス・メッセージ・タイプ

レスポンスのメッセージ・タイプとして、次のいずれかを選択します。

- 「バイト」(未解釈バイトのストリームの場合)

- 「テキスト」(テキスト・メッセージの場合)

このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。

トランザクション・タイムアウト

プロキシ・サービスによって開始されたXAトランザクションがタイムアウトするまでに待機する時間を秒単位で入力します。このプロパティは、XAトランザクション用に構成されたMQ接続リソースを使用するサービスにのみ適用されます(つまり、MQ接続リソースに「XA有効」オプションが選択されます)。

デフォルト値は300秒です。

ポーリング間隔

メッセージの次のポーリングまでに待機する間隔をミリ秒単位で入力します。デフォルトは1000です。

ポーラー・ディスパッチ・ポリシー

ポーラー・スレッドのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

バックアウトしきい値

「配信失敗メッセージURI」フィールドに指定したキューにパイプラインがメッセージをリダイレクトする前に、メッセージを再試行する回数を示す値を入力します。

このフィールドに値が指定されていない場合は、再試行を実行しないで、メッセージを配信失敗キューにリダイレクトします。

MQ配信失敗メッセージURI

「バックアウトしきい値」フィールドに指定した再試行回数を行った後、リクエスト・メッセージがリダイレクトされる配信失敗メッセージ・キューのURIを入力します。

このフィールドに値を指定しない場合、「バックアウトしきい値」フィールドに指定した再試行回数を行った後、メッセージがキューに戻され、各ポーリングでMQトランスポートによって無視されます。配信失敗メッセージURIの形式はエンドポイントURIの形式と同じです。

エンドポイントURI 'GET'オプション

次のオプションでMQ GETメッセージ・オプションを入力します。

- MQC.MQGMO_ACCEPT_TRUNCATED_MSG

- MQC.MQGMO_ALL_MSGS_AVAILABLE

- MQC.MQGMO_BROWSE_FIRST

- MQC.MQGMO_BROWSE_NEXT

- MQC.MQGMO_COMPLETE_MSG

- MQC.MQGMO_CONVERT

- MQC.MQGMO_FAIL_IF_QUIESCING

- MQC.MQGMO_LOCK

- MQC.MQGMO_LOGICAL_ORDER

- MQC.MQGMO_MARK_BROWSE_CO_OP

- MQC.MQGMO_MARK_SKIP_BACKOUT

- MQC.MQGMO_NO_SYNCPOINT

- MQC.MQGMO_NONE

- MQC.MQGMO_NO_WAIT

- MQC.MQGMO_SYNCPOINT

- MQC.MQGMO_SYNCPOINT_IF_PERSISTENT

- MQC.MQGMO_UNLOCK

- MQC.MQGMO_UNMARK_BROWSE_CO_OP

- MQC.MQGMO_UNMARK_BROWSE_HANDLE

- MQC.MQGMO_UNMARKED_BROWSE_MSG

- MQC.MQGMO_VERSION_1

- MQC.MQGMO_VERSION_2

- MQC.MQGMO_VERSION_3

- MQC.MQGMO_WAIT

複数のオプションを区切るには、「|」または「+」を使用します。たとえば、次のように指定できます。

MQC.MQGMO_ACCEPT_TRUNCATED_MSG | MQC.MQGMO_LOCK

インバウンド・キューからのメッセージを読み込む場合、MQ GETメッセージ・オプションが適用されます。

MQトランスポートによるRFH2ヘッダーの処理方法の詳細は、「RFH2ヘッダーについて」を参照してください。

RFH2ヘッダーのプロセス

メッセージ・ペイロードからWebSphere MQ RFH2ヘッダーを解析して、RFH2データを含むRFH2Headersトランスポート・ヘッダーを自動的に生成する場合はこのオプションを選択します。このオプションを選択しない場合は、ペイロードはそのまま渡されます。

MQトランスポートによるRFH2ヘッダーの処理方法の詳細は、「RFH2ヘッダーについて」を参照してください。

返信先ヘッダーを無視

キュー・マネージャを指定する返信先ヘッダーを無視する場合はこのオプションを選択します。

動的返信先ヘッダー

リクエスト・メッセージの返信先ヘッダーをレスポンス・メッセージでも使用する場合はこのオプションを選択します。

このプロパティがtrueに設定されて、「返信先ヘッダーを無視」プロパティがfalseに設定される場合、静的返信先キュー・マネージャ(プロキシ・サービスのレスポンスURIで定義)が、リクエスト・メッセージで指定されるキュー・マネージャと同じでなければ、メッセージは、リクエスト・メッセージで指定されるキュー・マネージャに送信されます。

ワーカー・スレッド・ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

33.6.3 MQトランスポートを使用するビジネス・サービスの構成

MQトランスポートのビジネス・サービスを構成するには、「MQ接続の作成方法」で示すようにMQ接続を作成する必要があります。サービスの構成時に、サービス・タイプとしてメッセージまたは任意のXMLを選択します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

次の表に、プロキシ・サービス用のMQトランスポートの構成に使用するプロパティを示します。

表33-2 ビジネス・サービス用のMQトランスポート・プロパティ

オプション

説明

メッセージ・タイプ

サービスで処理されるメッセージのメッセージ・タイプとして、次のいずれかを選択します。

- 「バイト」(未解釈バイトのストリームの場合)

- 「テキスト」(テキスト・メッセージの場合)

レスポンスが必要

アウトバウンド・メッセージの送信後にレスポンスを受け取ることを指定する場合は、このオプションを選択します。

レスポンス相関パターン

レスポンス相関パターンのベースとして、次のいずれかのオプションを指定します。

- MessageId

- CorrelationId

- 「動的キュー」 - レスポンス相関のためにWebSphere MQ実装が動的キューを使用する場合はこのオプションを選択します。MQトランスポートでサポートされるのは一時的な動的キューのみです。

このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。

相関値の自動生成

このチェック・ボックスを選択して、CorrelationIDまたはMessageIDを自動的に生成します。

このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。

モデル・キュー

動的キューの生成に使用するモデル・キューの名前を入力します(「動的キュー」レスポンス相関パターンの場合のみ)。

MQレスポンスURI

レスポンスがパブリッシュされる宛先を入力します。次のようにエンドポイントURIと同じ形式でレスポンスURIを入力します。

mq://local-queue-name?conn=mq-connection-resource

動的キューを使用する場合、次の形式でURIを入力します。

mq://dynamic_queue_prefix?conn=mq-connection-resource

dynamic_queue_prefixは最大32文字に制限されており、MQサーバーでの動的キューの作成に使用されます。キュー名は接頭辞に一意のIDを追加したものです。たとえば、dynamic_queue_prefixがexampleの場合、動的キューの名前はexample123129083821のようになります。

動的キューのレスポンスURIではワイルドカードとしてアスタリスク(*)も使用できます。次に例を示します。

mq://dynamic_queue_prefix*
mq://*

URIにdynamic_queue_nameを指定しない場合、トランスポートはMQサーバーによって生成される動的キュー名を使用します。URIに明示的なmq_connection_resourceを指定しない場合(ベスト・プラクティス)、トランスポートはエンドポイントURIのmq_connection_resourceを使用します。

このオプションは、「レスポンスが必要」オプションが選択されている場合のみ使用できます。

レスポンス・タイムアウト

接続を切断するまでのレスポンスの待機時間を秒単位で入力します。デフォルトは300です。

このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。

ポーリング間隔

メッセージの次のポーリングまでに待機する間隔をミリ秒単位で入力します。デフォルトは1000です。

このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。

ポーラー・ディスパッチ・ポリシー

ポーラー・スレッドのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

動的キュー・プーリング

サーバーが動的キューへのプール接続を使用する場合は、このオプションを選択します(動的キュー・レスポンス相関パターンの場合のみ)。動的キューに別の接続プールを使用する場合は、動的キュー専用のMQ接続リソースを構成することを検討してください。

各リクエストに新しい動的キュー・インスタンスを作成する場合(レスポンスの後でキューを破棄する場合)は、このオプションを選択しないでください。

エンドポイントURI 'PUT'オプション

次の中からMQ PUTメッセージ・オプションを入力します。

- MQC.MQPMO_ALTERNATE_USER_AUTHORITY

- MQC.MQPMO_DEFAULT_CONTEXT

- MQC.MQPMO_FAIL_IF_QUIESCING

- MQC.MQPMO_LOGICAL_ORDER

- MQC.MQPMO_NEW_CORREL_ID

- MQC.MQPMO_NEW_MSG_ID

- MQC.MQPMO_NO_CONTEXT

- MQC.MQPMO_NO_SYNCPOINT

- MQC.MQPMO_NONE

- MQC.MQPMO_PASS_ALL_CONTEXT

- MQC.MQPMO_PASS_IDENTITY_CONTEXT

- MQC.MQPMO_RESOLVE_LOCAL_Q

- MQC.MQPMO_SET_ALL_CONTEXT

- MQC.MQPMO_SET_IDENTITY_CONTEXT

- MQC.MQPMO_SYNCPOINT

- MQC.MQPMO_VERSION_1

- MQC.MQPMO_VERSION_2

複数のオプションを区切るには、「|」または「+」を使用します。たとえば、次のように指定できます。

MQC.MQPMO_LOGICAL_ORDER | MQC.MQPMO_NEW_MSG_ID

MQ PUTメッセージ・オプションは、メッセージがアウトバウンド・キューに配置された場合に適用されます。

MQ認識できないレスポンスURI

認識できないレスポンス・メッセージの送信先のキューを示すURIを入力します。「相関値の自動生成」チェック・ボックスが選択された場合のみ、設定が有効になります。

このフィールドの値を指定しない場合、認証できないレスポンス・メッセージが削除されます。

RFH2ヘッダーのプロセス

メッセージ・ペイロードからWebSphere MQ RFH2ヘッダーを解析して、RFH2データを含むRFH2Headersトランスポート・ヘッダーを自動的に生成する場合はこのオプションを選択します。このオプションを選択しない場合は、ペイロードはそのまま渡されます。

MQトランスポートによるRFH2ヘッダーの処理方法の詳細は、「RFH2ヘッダーについて」を参照してください。

ワーカー・スレッド・ディスパッチ・ポリシー

ワーカー・スレッドのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

33.6.4 MQトランスポートの環境値

環境値とは、多くの場合ドメイン間での構成の移動(テスト環境から運用環境への移行など)に伴って変化する値で、構成データに含まれる特定の事前定義されたフィールドです。環境値の更新の詳細は、『Oracle Service Busの管理』のOracle Service Bus環境のカスタマイズに関する項を参照してください。

次の表に、MQトランスポートとMQ接続リソースでサポートされる環境値を示します。これらの変数に指定した値により、特定のMQプロキシ・サービスおよびビジネス・サービス用に構成されたプロパティがオーバーライドされます。MQトランスポートに基づいたサービスでは、「ワーク・マネージャ」環境値もサポートされています。

表33-3 MQトランスポートとMQ接続リソースの環境値

値

説明

MQ接続リスト

マルチインスタンス・キュー・マネージャのサポートが有効な場合に使用されるMQ接続のリスト。

MQ接続プール・サイズ

MQ接続プールで保持される接続の数。

MQ接続タイムアウト

未使用の接続が破棄されるまでの秒単位の時間間隔。

MQ配信失敗メッセージURI

指定した回数再試行を行った後、リクエスト・メッセージがリダイレクトされる配信失敗メッセージ・キューのURI。

MQホスト名

MQキュー・マネージャのホスト名(TCPモードの接続のみ)。

QMが有効化されたMQマルチインスタンス

MQマルチインスタンス・キュー・マネージャのサポートが有効かどうかを示すインジケータ。有効な場合、MQ接続リスト内にある接続のリストが使用されます。

MQポート番号

MQキュー・マネージャのポート番号(TCPモードの接続のみ)。

MQキュー・マネージャのチャネル名

キュー・マネージャ・サーバー接続チャネルの名前(TCPモードの接続のみ)。

MQキュー・マネージャ名

接続先のMQキュー・マネージャの名前。

MQレスポンスURI

レスポンスが必要なときに、そのレスポンスがパブリッシュされる宛先のURI。

MQ認識できないレスポンスURI

相関値が自動生成されたときに、認識できないレスポンス・メッセージが送信されるキューを表すURI。

MQバージョン

使用されるWebSphere MQのバージョン。

MQ XA有効

この接続によって処理されるトランザクションが分散(XA)トランザクションであるかどうかを示す値。

33.7 MQトランスポート・ヘッダー

次の表に、MQトランスポートで使用されるヘッダーを示します。ヘッダーの多くはアウトバウンド・リクエストとインバウンド・レスポンスの両方で共通になっています。返信先キュー名、返信先キュー・マネージャ名、ユーザーID、およびバージョンの各ヘッダーはインバウンド・レスポンス用としてのみ編集できます。

パイプラインを構成するときに、トランスポート・ヘッダー・アクションを使用してメッセージのヘッダー値を設定できます。

表33-4 MQトランスポート・ヘッダー

ヘッダー

説明

インバウンド・レスポンス/アウトバウンド・リクエスト

アカウンティング・トークン

アカウンティング・トークンは、メッセージのIDコンテキストの一部です。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

アプリケーションIDデータ

アプリケーションIDデータは、メッセージのIDコンテキストの一部です。この値を使用して、メッセージまたはメッセージの送信元についての追加情報を提供できます。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

アプリケーション送信元データ

送信元アプリケーションについてのデータです。この値は、メッセージの送信元についての追加情報を提供するためにアプリケーションが使用できます。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

バックアウト数

1単位の処理の一部として、メッセージがMQキューから返され、その後取り消された回数です。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

キャラクタ・セット

アプリケーション・メッセージ・データ内の文字データのコード化文字セット識別子です。

インバウンド・トランスポート・アクション: このフィールドは、データを特定の表現に変換するためにインバウンド・トランスポートによって使用されます。リクエスト/レスポンス・メッセージングの場合、リクエスト・メッセージのcharacterSetヘッダーはレスポンス・メッセージにコピーされます。このヘッダーがインバウンド・リクエストで構成されていない場合、デフォルト値であるMQC.MQCCSI_Q_MGR値が使用されます。

アウトバウンド・トランスポート・アクション: このヘッダーは、アウトバウンド・トランスポート用にパイプラインで設定できます。このヘッダー値が設定されていない場合は、デフォルト値のMQC.MQCCSI_Q_MGRが使用されます。

両方

相関ID

取得する必要があるメッセージの相関IDです。

インバウンド・トランスポート・アクション: correlationIDに基づくレスポンス相関パターンでは、リクエストのcorrelationIDがレスポンスにエコーされます。ユーザーはレスポンス・パイプライン内でcorrelationIDをオーバーライドできます。

アウトバウンド・トランスポート・アクション: サービスの構成中にcorrelationIDの自動生成オプションが選択されている場合、アウトバウンド・トランスポートは自動的にcorrelationIDを生成し、トランスポート・ヘッダーからのcorrelationIDが上書きされます。この値が指定されていない場合、パイプラインで指定されているcorrelationIDが使用されます。

一方向メッセージングの場合、パイプラインで指定されているcorrelationIDが(アウトバウンド)リクエストで使用されます。

両方

エンコーディング

アプリケーション・メッセージ・データ内の数値に使用される表現です。

インバウンド・トランスポート・アクション: インバウンド・トランスポートでは、このヘッダーを使用して着信メッセージ・データを解釈します。レスポンス・パイプラインでこのヘッダーが構成されていない場合、デフォルト値であるMQC.MQENC_NATIVEが使用されます。

アウトバウンド・トランスポート・アクション: このヘッダーがアウトバウンド・トランスポートのパイプラインで設定されていない場合、デフォルト値であるMQC.MQENC_NATIVEが使用されます。

両方

有効期限

有効期限は、メッセージを送信するアプリケーションによって設定されます(10分の1秒単位)。有効期限が過ぎたメッセージは、キュー・マネージャによって破棄されます。

インバウンド・トランスポート・アクション: リクエスト/レスポンス・メッセージングでは、リクエストの有効期限ヘッダーはインバウンド・トランスポートによってレスポンスにコピーされます。

アウトバウンド・トランスポート・アクション: 対応するトランスポート・ヘッダーがパイプラインで設定されている場合、このヘッダーはアウトバウンド・リクエスト・メッセージにコピーされます。

注意: レポート・ヘッダーには(他のオプションに加えて)MQC.MQRO_PASS_DISCARD_AND_EXPIRYオプションが必ず含まれています。このオプションは元のメッセージの有効期限をレポートまたは返信メッセージにコピーする必要があるという、受信側クライアントに対する指示です。

両方

フィードバック

フィード・バック・レポートの性質です。この値は、MQC.MQMT_REPORTというメッセージのタイプと共に使用して、レポートの性質を示すために使用します。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

フォーマット

メッセージ・データのフォーマット名です。フォーマット名は、メッセージの送信者によって使用され、受信者にメッセージのデータの性質を示すものです。

インバウンド・トランスポート・アクション: このフィールドがMQC.MQFMT_MD_EXTENSIONに設定されると、インバウンド・トランスポートは拡張MQMDオブジェクトを読み込みます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

グループID

物理メッセージが属しているメッセージ・グループを識別する値です。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

オフセット

セグメント化されたメッセージにおいて、論理メッセージの先頭からの、物理メッセージのデータのオフセットです。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

元の長さ

セグメント化されたメッセージの元の長さです。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

メッセージ・フラグ

メッセージのセグメント化とステータスを制御するフラグです。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

メッセージID

取得するメッセージのIDです。

インバウンド・トランスポート・アクション: messageIDがレスポンス・パイプライン内で指定されていない場合、messageIDヘッダーはMQC.MQMI_NONEに設定されます。

messageIDに基づく相関の場合、インバウンド・トランスポートによってリクエストのmessageIDがレスポンスのcorrelationIDヘッダーにコピーされます。レポート・ヘッダーにMQC.MQRO_COPY_MSG_ID_TO_CORREL_IDオプションが含まれている場合、messageIDに基づく相関が使用されます。

アウトバウンド・トランスポート・アクション: サービスの構成時にmessageIDの自動生成オプションが指定されていると、アウトバウンド・トランスポートによりmessageIDが自動生成され、トランスポート・ヘッダーのmessageIDが上書きされます。この値が指定されていない場合は、messageIDトランスポート・ヘッダーが使用されます。

一方向メッセージングの場合、パイプラインで指定されているmessageIDがアウトバウンド・リクエストで使用されます。この値が指定されていない場合、messageIDはトランスポートにより自動生成されます。

両方

メッセージ・シーケンス番号

グループ内の論理メッセージのシーケンス番号です。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

メッセージ・タイプ

メッセージのタイプです。

インバウンド・トランスポート・アクション: インバウンド・トランスポートでは、MQC.MQMT_REQUEST、MQC.MQMT_DATAGRAM、MQC.MQMT_REPLY、およびMQC.MQMT_REPORTを含むすべてのタイプのメッセージを読み込んで処理を行います。インバウンド・トランスポートではレポート・メッセージは生成されません。

アウトバウンド・トランスポート・アクション: アウトバウンド・トランスポートではMQC.MQMT_DATAGRAM、MQC.MQMT_REQUEST、MQC.MQMT_REPLY、およびMQC.MQMT_REPORTを含むすべてのタイプのメッセージを生成します。messageTypeヘッダーがパイプライン内で構成されていない場合、メッセージング・パターンが一方向のときにはMQC.MQMT_DATAGRAMタイプのメッセージが、メッセージング・パターンがリクエスト/レスポンスのときにはMQC.MQMT_REQUESTタイプのメッセージがトランスポートによって生成されます。

両方

永続性

メッセージの永続性を示します。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

優先度

メッセージの優先度です。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

配信アプリケーション名

メッセージを配信するアプリケーションの名前です。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

配信アプリケーションの種類

メッセージを配信するアプリケーションの種類です。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

配信日時

メッセージが配信された日付と時刻です。これは、簡単な日付書式(yyyy-MM-dd HH:mm:ss.SSS)で指定されます。例: 2014-03-18 05:17:20.123。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

両方

返信先キュー名

返信の送信先となるキューの名前です。

メッセージの取得リクエストを発行したアプリケーションは、MQC.MQFMT_REPLYおよびMQC.MQFMT_REPORTメッセージをこのキューに送信できます。

インバウンド・トランスポート・アクション: このフィールドが設定されていると、インバウンド・トランスポートではreplyToQueueNameをレスポンス・キューの名前として使用します。この値が設定されていない場合は、デフォルトの宛先URIからキューの名前が導出されます。

アウトバウンド・トランスポート・アクション: リクエスト/レスポンス・メッセージ・パターンでは、メッセージ・フローで設定されたreplyToQueueNameは無視されます。一方向メッセージ・パターンでは、メッセージ・フローで設定されたreplyToQueueNameがアウトバウンド・メッセージで使用されます。

インバウンド・レスポンス

返信先キュー・マネージャ名

返信またはレポート・メッセージを送信できるキュー・マネージャの名前です。

インバウンド・トランスポート・アクション: リクエスト/レスポンス・メッセージ・パターンでは、インバウンド・メッセージのreplyToQueueManagerヘッダー値が、レスポンスURIでキュー・マネージャについて構成された値と一致しない場合、レスポンス・メッセージは破棄され、トランスポート・エラーがログに記録されます。このロジックをオーバーライドするには、プロキシ・サービスで、「動的返信先ヘッダー」プロパティをtrueに、「返信先ヘッダーを無視」プロパティをfalseに設定します。その後、ヘッダーの値が一致しない場合、メッセージは、リクエスト・メッセージで指定されるキュー・マネージャに送信されます。

アウトバウンド・トランスポート・アクション: リクエスト/レスポンス・メッセージ・パターンでは、メッセージ・フローで設定されたreplyToQueueManagerは無視されます。一方向メッセージ・パターンでは、メッセージ・フローで設定されたreplyToQueueManagerがアウトバウンド・メッセージで使用されます。

インバウンド・レスポンス

レポート

レポートとは、他のメッセージに関するメッセージです。このフィールドでは、元のメッセージを送信しているアプリケーションでどのレポート・メッセージが必要か、これらのレポート・メッセージにアプリケーション・メッセージ・データを含める必要があるかどうか、またレポートまたは応答にメッセージIDおよび相関IDを設定する方法を指定します。これはMQCクラスの1つ以上の定数を「+」または「|」演算子で組み合せることによって構成されます。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。リクエスト/レスポンス・メッセージングの場合、このヘッダーはレスポンス・パイプライン内に構成できます。

アウトバウンド・トランスポート・アクション: トランスポートによってレポート・フィールドに次のオプションの組合せが必ず設定されます。

messageIDに基づく相関パターンが使用される場合にはMQC.MQRO_COPY_MSG_ID_TO_CORREL_IDが設定され、correlationIDに基づく相関パターンが使用される場合は、MQC.MQRO_PASS_CORREL_IDが設定されます。MQC.MQRO_PASS_DISCARD_AND_EXPIRYは常に設定されます。

注意: これらのオプションは、パイプラインの対応するトランスポート・ヘッダーで指定されているオプションに追加して設定されます。

両方

ユーザーID

メッセージIDの一部であり、メッセージ送信元のユーザーを識別します。

インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。

アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。

インバウンド・レスポンス

バージョン

メッセージ記述子のバージョン番号です。

インバウンド・トランスポート・アクション: インバウンド・トランスポートは、メッセージ記述子バージョン1とバージョン2の両方をサポートしています。

アウトバウンド・トランスポート・アクション: デフォルトでは、アウトバウンド・トランスポートはバージョン2のヘッダーを生成します。ただし、このフィールドはパイプライン内でオーバーライドされることがあります。

インバウンド・レスポンス

RFH2Headers

トランスポート構成に「RFH2ヘッダーの処理」オプションが設定されている場合のペイロードにあるRFH2ヘッダー。RFH2HeadersヘッダーはStringです。

インバウンド・トランスポート・アクション: RFH2ヘッダーは、対応するトランスポート・メタデータ・ヘッダーを作成するためにMQペイロードから抽出されます。

アウトバウンド・トランスポート・アクション: アウトバウンドMQペイロードに挿入されたRFH2ヘッダー(各ヘッダー用の内容の長さを含む)を抽出するために、RFH2Headersデータを解析します。

両方

33.7.1 トランスポート・ヘッダーの構成

パイプラインでは、インバウンド・リクエストおよびアウトバウンド・リクエストの両方について、トランスポート・ヘッダー・アクションを使用してメッセージ内のヘッダー値を設定することによって、トランスポート・ヘッダーを構成できます。詳細は、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。

パイプラインにおいて、トランスポート・ヘッダーが明示的に設定されている場合、次のシナリオを除いて、この値がヘッダー値をオーバーライドします。

- アウトバウンド・リクエスト/レスポンス・パターンの場合、「相関値の自動生成」オプションがリクエスト/レスポンス・メッセージ・パターンのアウトバウンド・リクエストで選択されていると、この値がメッセージ・フローで設定されている場合であっても、相関IDが常に生成されます。

- メッセージ・フローでレポート・ヘッダーが設定されている場合、レポート・ヘッダーに関連付けられた複数のディレクティブの組合せがデフォルトのディレクティブにマージされます。

- リクエスト/レスポンス・メッセージ・パターンのアウトバウンド・リクエストについて、メッセージ・フローでreplyToQueueManagerNameまたはreplyToQueueNameヘッダーが設定されている場合、これらの値は無視されます。そのかわりに、これらのトランスポート・ヘッダーの値はビジネス・サービス用に構成されたレスポンスURIから導出されます。

- インバウンド・レスポンスの場合、replyToQueueManagerNameヘッダーにある値が、レスポンスURIで指定されたキュー・マネージャ名と一致しないと、エラー・メッセージが生成され、レスポンス・メッセージは送信されません。

- インバウンド・リクエスト・ヘッダーに設定されたreplyToQueueNameは、プロキシ・サービスの返信先URIで構成された値をオーバーライドします。

- 一方向ビジネス・サービスの場合、メッセージ・タイプのヘッダーがメッセージ・フローでリクエスト・タイプに構成されていると、replyToQueueNameヘッダーを指定する必要があります。この値が指定されていない場合は、MQサーバーでエラーが発生すると、メッセージはロール・バックされます。

33.7.2 RFH2ヘッダーについて

RFH2Headerヘッダーには複数の<RFH2Header>ブロックがあり、各ブロックには複数のフォルダが含まれています。MQトランスポートによって、各ブロックが、フォルダの線形リストを含む1つのRFH2ヘッダーに統合されます。

たとえば、次のブロックが一つのRFH2Headerヘッダーに統合されます。

<RFH2Header>
<mcd><Msd>jms_bytes</Msd></mcd>
</RFH2Header>
<RFH2Header>
<usr><clientId>DASHBOARD</clientId></usr>
</RFH2Header>

34 Oracle BPEL Process Managerトランスポートの使用

この章では、BPELトランスポートの概要と、サービスでの使用および構成方法について説明します。BPELトランスポートを使用すると、Service Busを使用してサービス指向アーキテクチャ(SOA)環境にOracle BPEL Process Manager (Oracle BPEL PM)を導入できます。

注意:

BPELトランスポート(ユーザー・インタフェースではbpel-10g)は、Oracle SOA Suite 10g リリース3のみとのメッセージングに対応します。SOA Suite 11g以上で使用するためには、Service BusによってSOA-DIRECTトランスポートが提供されます。詳細は、「SOA-DIRECTトランスポートの使用」を参照してください。

この章の構成は、次のとおりです。

- BPELトランスポートの概要

- BPELトランスポートの簡単な使用例(同期)

- 高度な使用例(非同期)

- BPELトランスポート構成のリファレンス

- BPELトランスポートのセキュリティ

- BPELトランスポートのエラー処理

- WS-Addressingのリファレンス

- BPELトランスポートを使用するXMLメッセージングの例

34.1 BPELトランスポートの概要

Service Busでは、Oracle BPEL Process Managerとの通信をサポートしており、サービス指向アーキテクチャ(SOA)にBPELプロセスを含めることができます。Service BusのOracle BPEL PM用ネイティブBPELトランスポートを使用して、BPELプロセスをWebサービスとしてサービス・バス・レイヤーに公開し、他のサービスからBPELプロセスを呼び出すことができます。同様に、Oracle BPEL PMからサービス・バス・レイヤーにあるサービスを呼び出して、Oracle BPEL PM自体のプロセスで使用できます。

Service Bus APIレベルでは、Service BusとOracle BPEL Process Managerの組込み統合が有効になっています。この章では、このタイプの統合に重点を置いていますが、このようなソリューションに限定されるわけではありません。Service Busに用意されている他の標準の通信プロトコル(HTTP、JMS、Fileなど)を使用することもできます。

Oracle BPEL Process Managerの詳細は、http://www.oracle.com/technetwork/middleware/bpel/overview/index.htmlを参照してください。

34.1.1 BPELトランスポートでのSOAPのサポート

Oracle BPEL Process ManagerとService Busの間の通信は、SOAPのみを介して行われます。Service BusおよびOracle BPEL PMはSOAP RPCエンコーディングを完全サポートしていません。BPELトランスポートはSOAP RPCエンコーディングのバインディングを受け入れますが、multiRefなど一部のエンコーディング・メカニズムではランタイム・エラーが発生する場合があります。

BPELトランスポートは次の機能をサポートしています。

- SOAP 1.1。SOAP 1.2は、Service BusからOracle BPEL PMへの同期通信でのみサポートされています。

- SOAPヘッダー

BPELトランスポートには次の制限があります。

- 添付ファイルなし

- WS-SecurityまたはWS-RMなし

34.1.2 BPELトランスポートでのトランザクション伝播

Oracle BPEL PMは、APIを使用したトランザクション伝播をサポートしており、BPELトランスポートはトランザクション対応です。そのため、Oracle WebLogic ServerにOracle BPEL PMがデプロイされている場合はトランザクション伝播がサポートされます。たとえば、Oracle BPEL PM以外のサービスでプロセスが始まった場合、Service BusはBPELトランスポートを通じてそのトランザクションをOracle BPEL PMに伝播し、トランザクションを完了できます。

Oracle BPEL PMからSBトランスポート・ベースのプロキシ・サービスを使用したService Busへのトランザクション伝播もサポートされています。

注意:

トランザクション伝播は、OracleサーバーOC4JおよびOracle ASではまだサポートされておらず、IBM WebSphereではまだ認証されていません。

34.1.3 BPELトランスポートでのSSLのサポート

Service BusからOracle BPEL PMへの呼出しはRMIを使用して行われるので、BPELトランスポートは一方向SSLを使用した呼出しレベルのセキュリティをサポートしています。詳細は、「BPELトランスポートのエンドポイントURI」を参照してください。

34.1.4 BPELトランスポートの環境値

BPELトランスポートは、次の表に示す環境変数(各変数は、BPELトランスポートの構成時に指定するプロパティに対応)を宣言します。環境変数の値は、Service Busプロジェクトを様々なデプロイメント環境間で移動するときに、トランスポート構成自体を更新することなく更新できます。環境値の詳細は、『Oracle Service Busの管理』のOracle Service Bus環境のカスタマイズに関する項を参照してください。

表34-1 BPELトランスポートの環境変数

環境変数

説明

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

サービス・アカウント

JNDIコンテキスト・セキュリティの場合に、Oracle BPEL Process Manager配信サービスへのアクセスに使用されるService Busサービス・アカウント・リソース。

エンドポイントURI

サービスのURI。

34.2 BPELトランスポートの簡単な使用例(同期)

この項では、Service Busを介したOracle BPEL Process Managerとの通信の最も一般的な使用例を説明します。これらは簡単な一方向またはリクエスト/レスポンス型の同期通信を表します。

- 同期: Oracle BPEL Process Managerのプロセスの呼出し

- 同期: Oracle BPEL Process Managerからの外部サービスの呼出し

- メッセージと正しい会話の関連付け

34.2.1 同期: Oracle BPEL Process Managerのプロセスの呼出し

図34-1に、Service Busを介したクライアントとOracle BPEL Process Managerの同期通信パターンを示します。

図34-1 Service Busを介したOracle BPELプロセスの同期呼出し

34.2.1.1 サービスの作成と構成

次のガイドラインに従って、クライアントからOracle BPEL Process Managerプロセスを呼び出します。

- 呼び出すBPELプロセスに相当するService Busビジネス・サービスを作成します。

- WSDLベースのビジネス・サービスを作成します。WSDLファイルは、Oracle BPEL Process Managerから生成します。

- ビジネス・サービスの構成で bpel-10g トランスポートを選択します。

- 表34-2の説明に従ってエンドポイントURIを設定します。

- ビジネス・サービスの残りの部分を構成します。「BPELトランスポート構成のリファレンス」を参照してください。

- クライアントからのメッセージを受け入れるプロキシ・サービスをService Busで作成します。

- プロキシ・サービスからビジネス・サービスを呼び出すパイプラインをService Busで作成します。

メッセージを正しい会話に関連付けるには、「メッセージと正しい会話の関連付け」を参照してください。

34.2.2 同期: Oracle BPEL Process Managerからの外部サービスの呼出し

図34-2は、Service Busを介したOracle BPEL Process Managerとサービス・プロバイダの同期通信パターンを示します。

図34-2 Service Busを介してサービスを同期的に呼び出すOracle BPELプロセス

34.2.2.1 サービスの作成と構成

次のガイドラインに従って、Oracle BPEL Process Managerから外部サービスを呼び出します。

- 呼び出したい外部サービスを表すService Busでのビジネス・サービスを作成します。

- ビジネス・サービスを呼び出すプロキシ・サービスとその関連パイプラインをService Busで作成します。

- ビジネス・サービスを呼び出すには、SOAP WSDLファイルを使用してプロキシ・サービスを作成する必要があります。プロキシ・サービスを定義する際に、WSDLサービス・タイプを選択し、目的のポートまたはバインディングを選択します。

- プロキシ・サービスの構成でSBトランスポートを選択します。

- Oracle BPEL Process Managerからプロキシ・サービスを呼び出すために、プロキシ・サービスの有効なWSDLファイルをエクスポートし、Oracle BPEL Process Manager開発環境にインポートします。通常どおり、Oracle BPEL Process Managerからプロキシ・サービスを呼び出します。

構成情報については、Service Busで提供されるオンライン・ヘルプを参照してください。

メッセージを正しい会話に関連付けるには、「メッセージと正しい会話の関連付け」を参照してください。

34.2.3 メッセージと正しい会話の関連付け

ステートフル・メッセージを使用する場合、Service BusとOracle BPEL Process Managerの間で同期的に送信されるメッセージは、会話と呼ばれます。Oracle BPEL Process Managerは、メッセージを会話の一部として相互に正しく関連付けるために、次のメカニズムをサポートしています。これらのメカニズムは互いに独立していて、正しい関連付けを実現するために両方とも使用するように指定できます。

- BPEL相関: BPEL相関はBPEL仕様に含まれています。Service BusのWSDLベースのビジネス・サービスからBPELプロセスにメッセージを送信すると、BPELエンジンによってメッセージが調べられ、ターゲットのBPELプロセス・インスタンスが検出されます。

- WS-Addressingを使用した不明瞭な相関: クライアントからService Busを介してBPELプロセスへの会話を開始すると、BPELエンジンによってWS-Addressing SOAPヘッダーのmessageIDの値が調べられ、新しい会話のIDとして使用されます。会話IDは、「RelatesTo」の値としてその会話が終わるまで維持されます。
WS-Addressingの詳細は、「WS-Addressingのリファレンス」にある「MessageID / RelatesTo」を参照してください。会話IDの設定例は、「会話IDの例」を参照してください。

34.3 高度な使用例(非同期)

この節では、Service Busを介したOracle BPEL Process Managerとの非同期通信のより高度な使用例を説明します。

- 非同期: Oracle BPEL Process Managerのプロセスの呼出し

- 非同期: Oracle BPEL Process Managerからのサービス・プロバイダの呼出し

34.3.1 非同期: Oracle BPEL Process Managerのプロセスの呼出し

図34-3は、Service Busを介したOracle BPEL Process Managerとサービス・プロバイダの非同期通信パターンを示します。

図34-3 Service Busを介したOracle BPELプロセスの非同期呼出し

非同期のメッセージ交換では、リクエストとは別の接続でコールバックが送信されます。

34.3.1.1 サービスの作成と構成

次のガイドラインに従って、クライアントからService Busを介してOracle BPEL Process Managerプロセスを非同期的に呼び出します。

2つのプロキシ・サービスとその関連パイプラインをService Busで作成します。ビジネス・サービスを呼び出すプロキシ・サービスと、コールバックを処理するプロキシ・サービスになります。

- リクエスト・プロキシ・サービスおよびパイプライン: 非同期通信では別の接続でコールバックが送信されるので、リクエスト・プロキシでコールバック・アドレスを設定する必要があります。このコールバック・アドレスは、メッセージが正しいクライアントに戻るように、コールバック・プロキシ・サービスとコールバック・ビジネス・サービスに渡されます。
ビジネス・サービスの構成で、コールバック・プロキシを選択します。実行時に、BPELトランスポートでこのプロキシをコールバック・プロキシとして使用します。ビジネス・サービスでコールバック・プロキシを選択しない場合のコールバック・アドレスの設定方法は、「WS-Addressingのリファレンス」および「Service Busを介したBPEL間非同期通信の例」を参照してください。

- コールバック・プロキシ・サービスおよびパイプライン: WSDL SOAPまたは任意のSOAPサービス・タイプとSBまたはHTTPトランスポートを使用するようにプロキシを構成します。Oracle BPEL Process ManagerからService Busへのトランザクション伝播を行う場合はSBトランスポートを使用します。
このプロキシ・サービスをビジネス・サービスのコールバック・プロキシとして選択すると、実行時にBPELトランスポートにより正しいコールバックURIが提供されます。

Service Busで、対話相手のOracle BPEL Process Managerプロセスへのリクエストを行うサービスと、コールバックを処理するサービスの、2つのビジネス・サービスを作成します。

- リクエスト・ビジネス・サービス: WSDLベースのビジネス・サービスを作成します。WSDLファイルは、Oracle BPEL Process Managerから生成します。WSDLサービス・タイプを選択し、WSDLファイルで適切なバインディングまたはポートを選択します。

- ビジネス・サービスの構成で bpel-10g トランスポートを選択します。

- ロールを「非同期クライアント」に設定します。

- 表34-2に記載されているエンドポイントURIを指定します。

- BPELトランスポート構成ページの「コールバック・プロキシ」フィールドを使用して、作成したコールバック・プロキシを選択します。

- コールバック・ビジネス・サービス: コールバックの処理に必要なビジネス・プロセスを構成します。
このガイドで説明していない構成情報については、Service Busで提供されるオンライン・ヘルプを参照してください。

34.3.2 非同期: Oracle BPEL Process Managerからのサービス・プロバイダの呼出し

この項では、Service Busを介したサービスの呼出しを行うためにOracle BPEL Process Managerで必要な手順と構成について説明します。

図34-4は、Service Busを介したOracle BPEL Process Managerとサービス・プロバイダの非同期通信パターンを示します。

図34-4 Service Busを介してサービスを非同期的に呼び出すOracle BPELプロセス

非同期のメッセージ交換では、リクエストとは別の接続でコールバックが送信されます。

34.3.2.1 サービスの作成と構成

次のガイドラインに従って、Oracle BPEL Process ManagerからService Busを介して外部サービスを非同期的に呼び出します。

2つのプロキシ・サービスとその関連パイプラインをService Busで作成します。1つは、ビジネス・サービスを呼び出すリクエストのプロキシ・サービス、もう1つは、コールバックを処理するプロキシ・サービスです。

- リクエスト・プロキシ・サービスおよびパイプライン: SBトランスポートを使用するようにプロキシ・サービスを構成します。非同期通信では別の接続でコールバックが送信されるので、メッセージが正しいクライアントに戻るようにコールバック・アドレスを設定する必要があります。
コールバック・アドレスの設定の詳細は、「WS-Addressingのリファレンス」にある「ReplyTo」と、「Service Busを介したBPEL間非同期通信の例」を参照してください。

- コールバック・プロキシ・サービスおよびパイプライン: コールバック・アドレスをビジネス・サービスに渡すようにプロキシ・サービスを構成します。コールバックURIはリクエスト内で指定されます。URI再書込みを使用してコールバックURIを抽出し、ビジネス・サービスに転送します。
プロキシ構成の詳細は、「プロキシ・サービスの作成と構成」および「SBトランスポートの使用」を参照してください。

Service Busで、外部サービスを呼び出すリクエスト・ビジネス・サービスと、コールバック・ビジネス・サービスの、2つのビジネス・サービスを作成します。

- リクエスト・ビジネス・サービス: ビジネス・サービスが外部サービスを呼び出すように構成します。

- コールバック・ビジネス・サービス: コールバック・ビジネス・サービスは、コールバック・プロキシからコールバック・アドレスを受け取ります。コールバック・プロキシ・サービスで実行されるURI再書込みによって、レスポンスの送信先のBPELプロセスを判断します。

- WSDLベースのビジネス・サービスを作成します。WSDLファイルは、Oracle BPEL Process Managerから生成します。WSDLサービス・タイプを選択し、WSDLファイルで適切なバインディングまたはポートを選択します。

- ビジネス・サービスの構成で bpel-10g トランスポートを選択します。

- エンドポイントURIをbpel://callbackに設定します(表34-2の説明に従ってください)。コールバックURIは、コールバック・プロキシ・サービスによって提供されます。

注意:

トレーディング・パートナ契約によってクライアントとBPELサービスがリンクしている場合など、コールバック・アドレスが常にわかっている場合は、bpel://callbackを使用するのではなく、そのコールバック・アドレスをコールバック・ビジネス・サービスに設定できます。

- bpel-10gトランスポートの構成ページでロールを「サービス・コールバック」に設定します(表34-3の説明に従ってください)。

- ビジネス・サービスの残りの部分を構成します。このドキュメントで説明していない構成情報については、Service Busで提供されるオンライン・ヘルプを参照してください。

34.4 BPELトランスポートのセキュリティ

Oracle BPEL Process Managerのセキュリティは、EJBレベルで扱われます。BPELトランスポートは、表34-3で説明したように、JNDIコンテキストの作成およびEJBルックアップに使用するJNDIのサービス・アカウント・オプションをサポートしています。BPELトランスポートは、サービス・アカウントからユーザー名とパスワードを取得します。サービス・アカウントが構成されていない場合は、匿名サブジェクトが仮定されます。

BPELトランスポートは、呼出しレベルのセキュリティもサポートしており、Service BusからOracle BPEL Process ManagerへのURIのプロトコル部分で一方向SSLを指定できます。詳細は、「BPELトランスポートのエンドポイントURI」を参照してください。

34.4.1 Oracle Service BusからOracleサーバーへの通信でのSSLの使用

(ormisおよびopmnsプロトコルを使用した)Service BusからOC4JおよびOracle ASサーバーへの通信にSSLを使用するには、Service Busサーバーで、ドメインのsetDomainEnvスクリプトに次のプロパティを追加してSSLを構成する必要があります。

-Djavax.net.ssl.trustStorePassword=passphrase
-Djavax.net.ssl.trustStore=file path to a keystore of trust certificate

34.5 BPELトランスポートのエラー処理

BPELトランスポートでは、Oracle BPEL Process Managerの例外を複数の方法で処理します。

- アプリケーション・エラー

- 接続エラー

- その他のエラー

34.5.1 アプリケーション・エラー

BPELプロセスの返信にフォルトがあった場合、BPELトランスポートはAPIでそのフォルト・メッセージをインターセプトし、SOAPフォルトに変換します。BPELトランスポートのアプリケーション・エラー自動処理機能により、アプリケーション・エラーが発生した場合に自動的にアプリケーション・エラー(この場合はBPELフォルト)を再試行するかどうかを指定できます。たとえば、問題が解決するまでアプリケーション・エラーで必ず失敗するように指定できます。アプリケーションの再試行を有効または無効にするには、「トランスポート構成」・ページの「アプリケーション・エラーの再試行」オプションを使用します。

34.5.2 接続エラー

Oracle BPEL Process Managerは、エラーではない次の例外をスローすることがあります。BPELトランスポートでは、これらの例外を自動的にTransportException接続エラーとして分類します。

- NamingException

- RemoteException

トランスポートの接続エラー自動処理機能により、接続エラーを再試行するかどうか、および接続エラーの再試行頻度を指定できます。再試行回数、および接続エラー時に次の再試行まで待機する秒数を指定するには、「トランスポート構成」ページの「再試行回数」オプションと「再試行の反復間隔」オプションを使用します。「再試行の反復間隔」を0に設定すると、接続エラーは再試行されません。

34.5.3 その他のエラー

その他の、アプリケーションおよび接続以外の例外は、一般的なTransportExceptionエラーとして再スローされます。

34.6 WS-Addressingのリファレンス

ここでは、BPELトランスポートとOracle BPEL Process Managerの通信に使用する特定のWS-Addressingプロパティについて説明します。また、「高度な使用例(同期)」のガイドラインで取り上げた、非同期通信でコールバック・アドレスを指定する方法についても説明します。

WS-Addressingの例については、「BPELトランスポートを使用するXMLメッセージングの例」を参照してください。

- ReplyTo

- MessageID / RelatesTo

34.6.1 ReplyTo

非同期通信では、リクエストとは別の接続でコールバックが送信されます。サービス開発者は、非同期のやり取りで正しいコールバック・アドレスを提供してコールバックが正しいクライアントに送信されるようにする必要があります。

34.6.1.1 Service Busを介したBPELプロセスの非同期コール

BPELトランスポートには、正しいコールバック・アドレスを指定するためのメカニズムが組み込まれています。Service BusでBPELビジネス・サービスを作成するときに、コールバックを処理するコールバック・プロキシを選択でき、BPELトランスポートによって正しいコールバック・アドレスが自動的に設定されます。手動で「ReplyTo」を指定する必要はありません。

詳細は、「非同期: Oracle BPEL Process Managerのプロセスの呼出し」を参照してください。

34.6.1.2 Service Busを介して外部サービスをコールするBPELプロセス

Oracle BPEL Process ManagerからService Busを介して外部サービスを呼び出す場合は、コールバック・アドレスを手動で設定する必要があります。WS-Addressingでこれを行うには、リクエスト・プロキシ・サービスでコールバック・アドレスを「ReplyTo」の値として設定します。そのURIがビジネス・サービスのBPELトランスポートによってコールバック・アドレスとして使用されます。

詳細は、「非同期: Oracle BPEL Process Managerからのサービス・プロバイダの呼出し」を参照してください。

34.6.2 MessageID / RelatesTo

MessageIDおよびRelatesToは、Oracle Service BusとOracle BPEL Process Managerの会話で会話IDの格納に使用され、関連するメッセージが同じ会話内に維持されるようにします。BPELトランスポートでは、特定の操作が開始操作か続行操作かを指定できません。かわりに、BPELトランスポートでは、「MessageID」および「RelatesTo」プロパティを検索し、それぞれ設定します。

次に、同期会話と非同期会話で「MessageID」と「RelatesTo」がどのように使用されるかを説明します。

- 同期会話:最初のリクエストで、「MessageID」によって会話IDが決定されます。残りの通信で、会話IDはRelatesToの値として提供されます。
「MessageID」または「RelatesTo」に値が割り当てられていない場合、BPELトランスポートは、会話が発生していないか、またはOracle BPEL Process Managerが相関付けを処理中であると想定します。

- 非同期コールバック: 最初のリクエストで、MessageIDによって会話IDが決定されます。残りの通信で、会話IDはコールバックの「RelatesTo」の値として提供されます。
「MessageID」または「RelatesTo」に値が割り当てられていない場合、BPELトランスポートは、会話が発生していないか、またはOracle BPEL Process Managerが相関付けを処理中であると想定します。

メッセージが正しい会話に関連付けられるように会話IDを設定する方法の詳細は、 「メッセージと正しい会話の関連付け」および「会話IDの例」を参照してください。

34.7 BPELトランスポートを使用するXMLメッセージングの例

Service BusとOracle BPEL Process Managerの間のXMLメッセージングの問題の例を次に示します。

- 会話IDの例

- Service Busを介したBPEL間非同期通信の例

34.7.1 会話IDの例

この項では、Service BusとOracle BPEL Process Managerの会話内のメッセージに共通IDを設定する様々な例をあげます。

図34-5では、クライアントがOracle BPEL Process Managerのプロセスを同期的に呼び出しています。ビジネス・サービス(BS1)は、BPELトランスポートを使用してプロセスを呼び出します。パイプライン(PP1)は、必要な会話IDマッピングを処理して、メッセージをプロキシ・サービス(PS1)からビジネス・サービスに渡します。

図34-5 Service Busを介した同期的なやり取りでの操作

34.7.1.1 ポートおよびメッセージ定義

この項の例では、WSDLファイルで定義された次のポートおよびメッセージ定義を使用します。

<wsdl:types>
<xsd:schema
targetNamespace="http://www.sample.org/spec/samples/types"
elementFormDefault="qualified">
<xsd:complexType name="ValueHolder">
<xsd:all>
<xsd:any minOccurs="1"/>
</xsd:all>
</xsd:complexType>
</xsd:schema>
</wsdl:types>
<message name="create"/>
<message name="putRequest">
<part name="key" type="xsd:string"/>
<part name="value" type="types:ValueHolder"/>
</message>
<message name="putResponse">
<part name="value" type="types:ValueHolder"/>
</message>
...
<message name="dispose"/>
<portType name="ServiceMap">
<operation name="create">
<input message="tns:create"/>
</operation>
<operation name="put">
<input message="tns:putRequest"/>
<output message="tns:putResponse"/>
</operation>
...
<operation name="dispose">
<input message="tns:dispose"/>
</operation>
</portType>

34.7.1.2 WS-Addressingでの会話IDの設定

この例は、WS-Addressingを使用して会話内のメッセージに会話IDを設定する方法を示しています。図34-5に通信パターンが示されています。

作成操作

<soap:Envelope>
<soap:Header>
<wsa03:MessageID>uuid:123456789</wsa03:MessageID>
</soap:Header>
<soap:Body>
<create/>
</soap:Body>
</soap:Envelope>

Put操作

<soap:Envelope>
<soap:Header>
<wsa03:MessageID>uuid:111111111</wsa03:MessageID>
<wsa03:RelatesTo>uuid:123456789</wsa03:RelatesTo>
</soap:Header>
<soap:Body>
<put>
<key>key</key>
<value>
<PO/>
</value>
</put>
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Body>
<putResponse>
<value/>
</putResponse>
</soap:Body>
</soap:Envelope>

<put>操作にもMessageIDがありますが、RelatesToに会話IDを示す値があるので無視されます。

34.7.1.3 メッセージ・ペイロード・データでの会話IDの設定

この例は、メッセージ・ペイロード・データを使用して会話内のメッセージに会話IDを設定する方法を示しています。これらの例では、プロキシ・サービスがIDをMessageID/RelatesTo SOAPヘッダーにマッピングします。図34-5に通信パターンが示されています。

作成操作

クライアントからプロキシ・サービス

<soap:Envelope>
<soap:Body>
<create/>
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Body>
<createResponse>
<mapID>uuid:123456789</mapID>
</createResponse>
</soap:Body>
</soap:Envelope>

プロキシ・サービスからBPELプロセス(ビジネス・サービスを使用)

<soap:Envelope>
<soap:Header>
<wsa03:MessageID>uuid:123456789</wsa03:MessageID>
</soap:Header>
<soap:Body>
<create/>
</soap:Body>
</soap:Envelope>

説明なし: IDはプロキシ・サービス・パイプラインのリクエストで生成され、プロセスを呼び出す前に<wsa03:MessageID>として挿入されました。プロセス側では、create操作は一方向の操作なので、クライアントに応答する前にSOAPレスポンスが作成される必要があります。プロキシ・サービスで生成されたIDがレスポンスによって返送されます。

Put操作

クライアントからプロキシ・サービス

<soap:Envelope>
<soap:Body>
<put>
<mapID>uuid:123456789</mapID>
<key>key</key>
<value>
<PO/>
</value>
</put>
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Body>
<putResponse>
<value/>
</putResponse>
</soap:Body>
</soap:Envelope>

プロキシ・サービスからBPELプロセス(ビジネス・サービスを使用)

<soap:Envelope>
<soap:Header>
<wsa03:RelatesTo>uuid:123456789</wsa03:RelatesTo>
</soap:Header>
<soap:Body>
<put>
<key>key</key>
<value>
<PO/>
</value>
</put>
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Body>
<putResponse>
<value/>
</putResponse>
</soap:Body>
</soap:Envelope>

破棄操作

クライアントからプロキシ・サービス

<soap:Envelope>
<soap:Body>
<dispose>
<mapID>uuid:123456789</mapID>
</dispose>
</soap:Body>
</soap:Envelope>

プロキシ・サービスからBPELプロセス(ビジネス・サービスを使用)

<soap:Envelope>
<soap:Header>
<wsa03:RelatesTo>uuid:123456789</wsa03:RelatesTo>
</soap:Header>
<soap:Body>
<dispose/>
</soap:Body>
</soap:Envelope>

34.7.1.4 変換の例

これらの例では、クライアントがWS-Addressing仕様の新しいバージョン(wsa04接頭辞)を使用します。プロキシ・サービスで、wsa03接頭辞を使用するようにSOAPヘッダーの変換を行う必要があります。プロキシ・サービス開発者はトランスフォーメーションを構成します。図34-5に通信パターンが示されています。

作成操作

クライアントからプロキシ・サービス

<soap:Envelope>
<soap:Header>
<wsa04:MessageID>uuid:123456789</wsa04:MessageID>
</soap:Header>
<soap:Body>
<create/>
</soap:Body>
</soap:Envelope>

プロキシ・サービスからBPELプロセス(ビジネス・サービスを使用)

<soap:Envelope>
<soap:Header>
<wsa03:MessageID>uuid:123456789</wsa03:MessageID>
</soap:Header>
<soap:Body>
<create/>
</soap:Body>
</soap:Envelope>

Put操作

クライアントからプロキシ・サービス

<soap:Envelope>
<soap:Header>
<wsa04:MessageID>uuid:111111111</wsa04:MessageID>
<wsa04:RelatesTo>uuid:123456789</wsa04:RelatesTo>
</soap:Header>
<soap:Body>
<put>
<key>key</key>
<value>
<PO/>
</value>
</put>
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Body>
<putResponse>
<value/>
</putResponse>
</soap:Body>
</soap:Envelope>

プロキシ・サービスからBPELプロセス(ビジネス・サービスを使用)

<soap:Envelope>
<soap:Header>
<wsa03:MessageID>uuid:111111111</wsa03:MessageID>
<wsa03:RelatesTo>uuid:123456789</wsa03:RelatesTo>
</soap:Header>
<soap:Body>
<put>
<key>key</key>
<value>
<PO/>
</value>
</put>
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Body>
<putResponse>
<value/>
</putResponse>
</soap:Body>
</soap:Envelope>

34.7.2 Service Busを介したBPEL間非同期通信の例

次の例は、Service Busを介して別のBPELプロセスを非同期的に呼び出すBPELプロセスに関係するSOAPヘッダーを示します。図34-6のPP1とPP2は、PS1およびPS2プロキシ・サービスからBS1およびBS2ビジネス・サービスにメッセージを渡し、変換を実行するパイプラインです。ビジネス・サービスは、BPELトランスポートを使用してBPELプロセスのコールを行う場合に必要です。

図34-6 Service Busを介して別のBPELプロセスを呼び出すBPELプロセス

次のSOAPヘッダー例については、図34-6を参照してください。

34.7.2.1 ポートおよびメッセージ定義

<message name="LoanServiceRequestMessage">
<part name="payload" element="types:loanApplication"/>
</message>
<message name="LoanServiceResultMessage">
<part name="payload" element="types:loanOffer"/>
</message>
<portType name="LoanService">
<operation name="initiate">
<input message="tns:LoanServiceRequestMessage"/>
</operation>
</portType>
<portType name="LoanServiceCallback">
<operation name="onResult">
<input message="tns:LoanServiceResultMessage"/>
</operation>
</portType>

34.7.2.2 BP1からP1 - 開始操作

<soap:Envelope>
<soap:Header>
<wsa03:ReplyTo>
<wsa03:Address>ormi://serverB:7001/default/AmericanLoanClient/1.0/service/LoanServiceRequester
</wsa03:Address>
</wsa03:ReplyTo>
<MessageID>AmericanLoanClient~1.0/60007</MessageID>
</soap:Header>
<soap:Body >
<loanApplication>
...
</loanApplication>
</soap:Body>
</soap:Envelope>

34.7.2.3 P1/B1からBP2

<soap:Envelope>
<soap:Header>
<wsa03:ReplyTo>
<wsa03:Address>http://serverB:7001/P2</wsa03:Address>
<wsa03:ReferenceProperties>
<osb:Callback>
<osb:Address>
ormi//localhost/default/AmericanLoanClient/1.0/service/LoanServiceRequester
</osb:Address>
</osb:Callback>
</wsa03:ReferenceProperties>
</wsa03:ReplyTo>
<MessageID>AmericanLoanClient~1.0/60007</MessageID>
</soap:Header>
<soap:Body >
<loanApplication>
...
</loanApplication>
</soap:Body>
</soap:Envelope>

ReplyToコールバック・アドレスはB1で設定されます。B1は、表34-2の説明にあるように、BPELトランスポート構成の「コールバック・プロキシ」フィールドから値を取得します。B1のコールバック・プロキシはP2です。

元のreplyTo情報は、(後に続く) onResultコールバック・メッセージに反映されるように、ラップして参照プロパティとして送信する必要があります。

注意:

このサンプルでは、説明のためにosb:Callbackとosb:Addressを使用しています。WS-Addressingのサポートのために定義された標準またはService Bus標準の要素はありません。

34.7.2.4 BP2からP2 - onResult操作

<soap:Envelope>
<soap:Header>
<wsa03:RelatesTo>AmericanLoanClient~1.0/60007</wsa03:RelatesTo>
<osb:Callback>
<osb:Address>ormi//localhost/default/AmericanLoanClient/1.0/service/LoanServiceRequester
</osb:Address>
</osb:Callback>
</soap:Header>
<soap:Body >
<loanOffer>
...
</loanOffer>
</soap:Body>
</soap:Envelope>

参照プロパティosb:Callbackは、Oracle BPEL Process ManagerエンジンによってSOAPヘッダーとして返送されます。

34.7.2.5 P2/B2からBP1 - onResult操作

<soap:Envelope>
<soap:Header>
<wsa03:RelatesTo>AmericanLoanClient~1.0/60007</wsa03:RelatesTo>
</soap:Header>
<soap:Body >
<loanOffer>
...
</loanOffer>
</soap:Body>
</soap:Envelope>

この一時的なosb:Callbackヘッダーはプロキシ・サービスP2で削除されますが、このヘッダーを削除する前に、ビジネス・サービスB2のBPELトランスポートがコールバック・メッセージを正しいBPELプロセスに送信できるようにreplyToアドレス値が$outbound変数にコピーされます。

34.8 BPELトランスポート構成のリファレンス

この項では、ビジネスおよびプロキシ・サービスを対象とした、BPELトランスポート固有のプロパティについて説明します。

- BPELトランスポートのエンドポイントURI

- BPELトランスポートを使用するビジネス・サービスの構成

34.8.1 BPELトランスポートのエンドポイントURI

BPELトランスポートのURIフォーマット(表34-2を参照)は、JDeveloperまたはOracle Service Busコンソールのビジネス・サービスのメインの「トランスポート」ページで構成します。

表34-2 エンドポイントURIの指定

トランスポートのロール

エンドポイントURIフォーマット

同期クライアントまたは非同期クライアント・ロール

次のエンドポイントURIフォーマットで、大カッコで囲まれているのはオプションの要素です。

protocol://host[:port][/protocol-path]/domain/process[/version[/partnerlink/role

エンドポイントURIの他の要素の説明は次のとおりです。

- protocol: いずれかのRMI/JNDIプロトコルを使用します。
iiop/iiops: サーバーにとらわれない汎用プロトコルです。

t3/t3s: Oracle WebLogic Serverで使用されます。

http/https: トンネリングおよびOracle WebLogic Serverで使用します。

ormi/ormis: OC4J (Oracle Container for JEE)でのスタンドアロン開発で使用します。

- port: オプション。サーバーがデフォルト・ポートを使用するように構成されている場合、ormiおよびopmnプロトコルでのみ使用します。

- protocol-path: オプション。opmnおよびopmnsプロトコルでのみ使用します。protocol-pathはクラスタ内のサーバー・インスタンスです。

- version: オプション。呼び出すプロセスのバージョンです。

- partnerlink/role: オプション。バージョンを指定する場合、このオプションをフルパスの記述に含めます。

クラスタの場合、次のURIフォーマットを使用して、そのクラスタ内の特定のノードをターゲットとすることもできます。

protocol://host1:port1,host2:port2/<remainder_of_URI>

サービス・コールバック

トレーディング・パートナ契約によってクライアントとBPELサービスがリンクしている場合など、コールバック・アドレスが常にわかっている場合は、次のフォーマットを使用するのではなく、そのコールバック・アドレスをエンドポイントURIに設定できます。

bpel://callback

34.8.2 BPELトランスポートを使用するビジネス・サービスの構成

表34-3に、JDeveloperとOracle Service Busコンソールの両方のビジネス・サービスのBPELトランスポートの構成ページで使用可能なオプションを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

表34-3 ビジネス・サービス用のBPELトランスポート・プロパティ

プロパティ

説明

ロール

ビジネス・サービス用に、次のいずれかのロールを選択します。BPELトランスポートは、Service BusからOracle BPEL PMにリクエスト・メッセージを送信するために使用します。ロールごとに特定の構成が必要になります。ビジネス・サービスでは、次のロールを処理できます。

- 同期クライアント: Service Busクライアントと同期通信を行う場合は、このロールを選択します。必要な場所情報はBPELアドレスのみです。このアドレスは、エンドポイントURIとして静的に、またはURIリライトを通じて動的に取得されます。

- 非同期クライアント: Service Busクライアントと非同期通信を行う場合は、このロールを選択します。この場合、Oracle BPEL Process ManagerからService Busへのコールバックはリクエストと異なる接続上で送信されるため、「コールバック・プロキシ」フィールドで、正しいコールバック・アドレスを提供するようにService Busを構成する必要があります。詳細は、「高度な使用例(非同期)」のガイドラインを参照してください。

- サービス・コールバック: ビジネス・サービスをOracle BPEL Process Managerへのサービス・コールバックとして設計する場合は、このロールを選択します(この場合、Oracle BPEL Process ManagerはService Busを介して外部サービスを非同期的に呼び出します)。コールバック・アドレスは、実行時にのみ認識されます。bpel://callbackのエンドポイントURIを使用します。
マーカーURIでビジネス・サービスを構成する場合は、$outboundにURIを動的に設定するようにパイプライン・ロジックを構成します。たとえば、TransportHeaderアクションを使用してこれを行うことができます。

注意: サービス・コールバック・ビジネス・サービスでは、ロード・バランシングまたはフェイルオーバーはサポートされません。

サービス・コールバックの使用方法は、表34-2の「サービス・コールバック」と、「非同期: Oracle BPEL Process Managerからのサービス・プロバイダの呼出し」を参照してください。

コールバック・プロキシ

非同期クライアントの場合のみ、リクエストを行ったService Busクライアントへのコールバックのルーティングに使用されるプロキシ・サービスを入力します。このプロキシ・サービスは、サービス・タイプが「任意のSOAP」のSBまたはHTTPプロキシ・サービスである必要があります。詳細は、「高度な使用例(非同期)」のガイドラインを参照してください。

このフィールドは、非同期クライアント・ロールでのみ使用可能です。

サービス・アカウント

JNDIコンテキスト・セキュリティがOracle BPEL Process Manager配信サービスへのアクセスに使用するサービス・アカウントを入力します。サービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。静的またはパススルーなど、構成できるサービス・アカウントのタイプに制限はありませんが、ランタイムはユーザー名とパスワードにアクセスできる必要があります。

詳細は、「サービス・アカウントの操作」を参照してください。

トランザクションを中断

このオプションを選択すると、ビジネス・サービスがトランザクションによって呼び出された場合でも、ビジネス・サービスは非トランザクションになります。

「トランザクションを中断」を選択しない場合は、次のルールが適用されます。

- プロトコルによって、WebLogic Serverでサポートされるプロトコル(t3、iiop、http)が指定されている場合は、トランザクションが伝播されます。

- プロトコルがOC4Jサーバー(ormi、opmn)を指定している場合、OC4Jではトランザクションの伝播がサポートされないため、BPELトランスポートで例外がスローされます。

BPELトランスポートでは、次の状況で「トランザクションを中断」設定が無視されます。

- サービスの品質(QoS)を「ベスト・エフォート」に設定してビジネス・サービスが呼び出される場合。BPELトランスポートでは、QoSをサポートしていないトランザクションが自動的に中断されます。

- QoSを「必ず1回」に設定してビジネス・サービスが呼び出され、トランザクションが存在しない場合。

トランザクション伝播の説明については、「BPELトランスポートでのトランザクション伝播」を参照してください。

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

35 SBトランスポートの使用

この章では、SBトランスポートの概要と、サービスでの使用および構成方法について説明します。SBトランスポートは、RMIを使用してOracle製品をService Busと統合します。

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

- SBトランスポートの概要

- SBトランスポートのエラー処理

- UDDIとSBトランスポート

- SBトランスポート構成のリファレンス

35.1 SBトランスポートの概要

SBトランスポートによって、Oracle製品からRMIを使用して、Service Busプロキシ・サービスを同期的に呼び出すことができます。インバウンド・トランスポートでは、クライアントがRMIを使用してSBプロキシ・サービスにアクセスできます。アウトバウンド・トランスポートでは、RMIを使用してSBプロキシ・サービスを呼び出すことができます。デフォルトでは、T3プロトコル、IIOP、HTTP、T3、IIOPS、またはHTTPSを使用したすべてのサービスへのアクセスが、ターゲット・サーバーの構成に依存します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデフォルト・ネットワーク接続の構成に関する項を参照してください。

35.1.1 SBトランスポートの機能

SBトランスポートは次をサポートしています。

- トランザクション・コンテキストを伝播します。クライアントService Busサーバーで発生したトランザクションを必要に応じてSBプロキシ・サービスに伝播できます。

- セキュリティ・コンテキストを伝播します。デフォルトでは、SBクライアント・スレッドに関連付けられたセキュリティ・コンテキストを使用してSBプロキシ・サービスを呼び出します。これには、ドメイン間の信頼を有効化しなければならない場合があります。『Oracle WebLogic Serverセキュリティの管理』のクロスドメイン・セキュリティのサポートに関する重要情報が記載された項を参照してください。

- サービス・アカウントを使用したアウトバウンド・エンドポイントから、カスタムIDでSBプロキシ・サービスを呼び出します。

- 非トランザクションの呼出しに対してタイムアウト値を指定します。Service Busが指定間隔以内にリクエストに応答しない場合、クライアント・リクエストは返されます。

- リクエスト接続とレスポンス接続両方でのディスパッチ・ポリシーの関連付け。詳細は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。

- JNDIプロバイダを指定せずにSBビジネス・サービスにルーティングする場合、RMI呼出しおよびcall-by-referenceを最適化します。

- 次のサービス・タイプに対応します。

- WSDLサービス

- 任意のSOAPサービス

- 任意のXMLサービス

- 次のメッセージング・パターンに対応します。

- インバウンド・トランスポートに対するリクエスト(一方向)およびリクエスト/レスポンス。
Service Busクライアントの場合、メッセージング・パターンはデフォルトでSBアウトバウンド・トランスポートのパイプラインから継承されます。

Service Bus以外のクライアントの場合、デフォルトのメッセージング・パターンはリクエスト/レスポンスになります。

- アウトバウンド・トランスポートの環境値に対するリクエストおよびリクエスト/レスポンス。SBがサポートする環境値の詳細は、「SBトランスポートの環境値」を参照してください。

- サービスの品質(QoS)のデフォルト値は次のとおりです。

- Service Bus以外のクライアントの場合、Exactly-Onceです。

- Service Busクライアントの場合、Best-Effortです。

パイプラインのルーティング・オプションを使用してサービスのQoSを設定することもできます。詳細は、「サービスの品質」を参照してください。

35.2 SBトランスポートのエラー処理

ビジネス・サービスURIは、通信エラーが発生したときにオフラインにすることができます。ビジネス・サービスの操作設定を構成するときに、指定した再試行間隔の後、ビジネス・サービスのエンドポイントURIがオフラインになるように設定できます。詳細は、『Oracle Service Busの管理』のビジネス・サービス用のエンドポイントURIの監視と管理に関する項を参照してください。

SBプロキシ・サービスの呼出し中に接続エラーが発生すると、SBトランスポート・プロバイダによってBEA-380002エラー・コードが生成されます。接続エラーは、次のいずれかの理由で発生する可能性があります。

- ターゲット・プロキシ・サービスが存在しません。

- JNDIプロバイダ設定が正しくありません。

- RMI呼出し中に、リモート例外またはネーミング例外が発生しています。
ネーミング例外のタイプjavax.naming.NamingSecurityExceptionは、通常、呼出しで使用されたIDがターゲット・サーバーで認識されない場合に発生します。この例外が発生すると、リクエストは全般的な実行時エラーを返します。このエラーは、接続エラーとして処理されません。

- 外部サービスは、SOAPペイロードをフォルト・コードとともに返します。
フォルト・コードを処理するエラー・ハンドラが存在する場合、トランザクションはロールバック対象としてマークされません。エラー・ハンドラが存在しない場合、トランザクションはロールバック対象としてマークされます。

エラーが発生した際に、(返信アクション用のエラー・オプションを使用して)フォルトをキャッチしてフォルト・レスポンスを返信するエラー・ハンドラが存在する場合、エラーはアプリケーション・エラーとみなされ、トランザクションはロールバック対象としてマークされません。他のすべてのエラーの場合、トランザクションはロールバック対象としてマークされます。

SBプロキシ・サーバーによって返されるSOAPフォルトは、アプリケーション・エラーとして処理されます。

35.3 UDDIとSBトランスポート

UDDIレジストリに対してサービスのインポートとパブリッシュを行うことができます。詳細は、「UDDIレジストリの操作」を参照してください。

- サービスの公開

- サービスのインポート

35.3.1 サービスのパブリッシュ

プロキシ・サービスをUDDIレジストリにパブリッシュする場合、パブリッシュしたサービスに関連付けられたURIの形式は、次のとおりです。

sb://host:port/service_name

ここで、host:portはパブリッシュするプロキシ・サービスをホストしているサーバーのホスト名とリスニング・ポートを示します。

パブリッシュするプロキシ・サービスで「SSLを使用」オプションが有効になっている場合、パブリッシュされたサービスに関連付けられたURIの形式は、次のとおりです。

sbs://host:port/service_name

パブリッシュするプロキシ・サービスがクラスタ上で実行されている場合、host:portはconfig.xmlファイルのClusterセクションにあるCluster Address設定になります。この値は、クラスタ内の任意のWebLogic Serverへの接続に使用される1つのホスト名およびポート番号にするか、Service Busクラスタ内の管理対象サーバーのホスト名およびリスナー・ポートのカンマ区切りのリストにできます。詳細は、『Oracle WebLogic Server JNDIアプリケーションの開発』のWebLogic JNDIに関する項を参照してください。

詳細は、「UDDIレジストリへのプロキシ・サービスのパブリッシュ」を参照してください。

35.3.2 サービスのインポート

UDDIレジストリからサービスをインポートする場合、SBトランスポート・プロバイダは、サービスURIプロパティのsbschemeおよびhost:port情報を、sbschemeに基づく適切なプロトコルを使用してService Busサーバー上で登録されたJNDIプロバイダと照合します。sbschemeはSBトランスポート・ベースのサービスのURIスキームで、sbまたはsbsのいずれかになります。

sbschemeがsbである場合、トランスポート・プロバイダはT3、T3S、IIOP、IIOPS、HTTP、またはHTTPSプロトコルを(この順序で)使用してJNDIプロバイダを検索します。sbschemeがsbsである場合、トランスポート・プロバイダはT3Sプロトコル、IIOPS、次にHTTPSを(この順序で)使用してJNDIプロバイダを検索します。サービスURIプロパティに一致するJNDIプロバイダは、Service Busにインポートするビジネス・サービスのエンドポイントURIを生成するために使用されます。

一致するJNDIプロバイダがない場合、インポートは失敗し、デフォルトのコンテキストが使用されます。ただし、インポートされたURIがローカルURIでスキームがsb以外の場合を除きます。サービスにJNDIプロバイダが指定されていないので、サーバーと同じ場所にあるものと見なされることを意味します。

たとえば、サービスURIプロパティ値が次のようになっている場合を考えます。

sbs://remote_oracle_service_bus_host:7002/myservice

Service Busにインポートされたビジネス・サービスに生成されるURIは、次のようになります。

sb://my_jndi_provider/myservice

ここで、my_jndi_providerはt3s://remote_oracle_service_bus_host:7002 URLのService Busサーバー上で登録されたJNDIプロバイダ・リソースです。

詳細は、「UDDIレジストリの操作」を参照してください。

35.4 SBトランスポート構成のリファレンス

この項では、SBトランスポートを使用するビジネスおよびプロキシ・サービス用に構成できる環境値とプロパティについて説明します。また、SBトランスポート用のJNDIプロバイダとエラー処理についても説明します。

- SBトランスポートの環境値

- SBトランスポートを使用するプロキシ・サービスの構成

- SBトランスポートを使用するビジネス・サービスの構成

35.4.1 SBトランスポートの環境値

SBトランスポートでサポートされる環境値を表35-1に示します。これらの変数に指定した値により、特定のSBベースのビジネスまたはプロキシ・サービス用に構成されたプロパティがオーバーライドされます。

表35-1 SBトランスポートの環境変数

環境値

使用目的

タイムアウト(カテゴリ:操作)

ビジネス・サービスのタイムアウト値(秒)を指定します。

サービス・アカウント(カテゴリ:セキュリティ)

JNDIコンテキスト・セキュリティの場合に、Oracle BPEL Process Manager配信サービスへのアクセスに使用されるService Busサービス・アカウント・リソース。SBベースのビジネス・サービスに関連付けられたユーザー資格証明を更新するために使用します。

SSLを使用(カテゴリ:セキュリティ)

プロキシ・サーバー用のセキュアなプロトコルを使用してサービスを公開するかどうかを指定します。詳細は、「SBトランスポートを使用するプロキシ・サービスの構成」を参照してください。

35.4.2 SBトランスポートを使用するプロキシ・サービスの構成

Service Busクライアントは、JNDIコンテキストおよびプロキシ・サービスURIを使用してService Busサーバーに接続します。クライアントのセキュリティ・コンテキストは、プロキシ・サービスを呼び出すために使用されます。デフォルトのQoSはExactly-onceです。クライアントは必要に応じて、QoSを変更し、リクエストのタイムアウト値を設定し、適切なメッセージ・パターンを指定できます。メッセージはインバウンドSBトランスポートで受信し、パイプラインで処理されます。

表35-2に、SBベースのプロキシ・サービスの構成に使用するプロパティを示します。エンドポイントのエンドポイントURLをプロキシ・サービス名として指定します。プロキシ・サービスを作成する手順については、「プロキシ・サービスの作成と構成」を参照してください。

表35-2 プロキシ・サービス用のSBトランスポート・プロパティ

プロパティ

説明

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

SSLを使用

セキュアなプロトコルを使用してサービスを公開する場合は、このオプションを選択します。これは、クライアントがSSLプロトコルを使用してSBプロキシ・サービスにアクセスする必要があることを意味しますが、クライアントが非セキュアなプロトコルを使用してサービスにアクセスすることを防止するわけではありません。また、次の場合は、サービスに関連付けられたエンドポイントURIがsbではなくsbsになります。

- セキュア・サービスをUDDIでエクスポートし、セキュリティおよびポリシーの構成の詳細をインポート時に保持する場合。

- 効率的なWSDLファイル内。

注意: プロキシ・サービスは特定のプロトコルにバインドされません。必要に応じてSSL、IIOPまたはHTTPトンネリングを有効にする作業は、Oracle WebLogic Server管理者が行う必要があります。

このフラグは、エクスポート時のサービスのURIスキーム、またはUDDIからインポートされるときのビジネス・サービスURIに対するJNDIプロバイダの選択にのみ影響します。クライアントが非セキュアなプロトコルを使用してサービスにアクセスすることを防止するわけではありません。

35.4.3 SBトランスポートを使用するビジネス・サービスの構成

SBビジネス・サービスは、SBプロキシ・サービスに対してのみメッセージを送信できます。ビジネス・サービスのエンドポイントURIに指定されたJNDIプロバイダは、リモートService Busサーバー上でJNDIルックアップを実行します。クライアントのユーザー資格証明またはビジネス・サービスに関連付けられたサービス・アカウントに定義済のユーザー資格証明を使用して、プロキシ・サービスを呼び出します。必要に応じて、タイムアウト値およびカスタム・ディスパッチ・ポリシーをビジネス・サービスに関連付けることもできます。また、サービスのQoSを、ルーティング・オプションを使用して設定することができます。

次の形式を使用して、サービスのエンドポイントURIを指定します。

sb://jndi_provider_name/service_name

説明:

- jndi_provider_nameはJNDIプロバイダの名前で、対応するService Bus JNDIプロバイダ・リソースを示します。これはオプションです。省略した場合は、デフォルトのコンテキストが使用されます。これは、サービスとService Busサーバーが同じマシンに存在することを意味します。呼出しが同じ場所にある場合、シリアライズはサービス呼出し中にスキップされます。詳細は、「JNDIプロバイダ」を参照してください。

- service nameは、ターゲット・サービスであり、リモート・プロキシ・サービスURIに対応します。

次の表に、SBベースのビジネス・サービスの構成に使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

表35-3 ビジネス・サービス用のSBトランスポート・プロパティ

プロパティ

説明

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

タイムアウト

ビジネス・サービスがタイムアウトになり、実行時エラーを返すまでの期間を秒単位で入力します。

指定したタイムアウト値は、次の場合には適用されません。

- サービス・エンドポイントのQoSがExactly-Onceである場合。

- 負の値が指定された場合。

- タイムアウト値が、メッセージ・フローにおいて、アウトバウンド・リクエストのオプションのTimeoutカスタム・ヘッダーでオーバーライドされる場合。詳細は、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。

サービス・アカウント

リモート・プロキシ・サービスの呼出しに使用する必要があるユーザー資格証明を指定します。サービス・アカウントが指定されない場合は、このビジネス・サービスのインバウンド・プロキシ・サービス(インバウンド・クライアント)のユーザー資格証明が、セキュリティ・コンテキストの伝播に使用されます。詳細は、「サービス・アカウントの操作」を参照してください。

35.4.3.1 JNDIプロバイダ

JNDIプロバイダは、SBプロキシ・サービスに対応するRMIスタブを取得するためにサービスがデプロイされているService Busサーバーを指します。JNDIプロバイダには、リモート接続とEJBスタブのための高性能なキャッシング・メカニズムがあります。JNDIプロバイダでは、T3、IIOP、HTTP、T3s、IIOPS、またはHTTPS転送プロトコルを使用できます。Service BusからOracle WebLogic Serverドメインへの推奨される通信プロトコルは、T3またはT3Sです。メッセージがファイアウォールを通過する必要がある場合は、コンテキスト内でHTTPプロバイダのURLを使用し、Oracle WebLogic Serverサーバー上でHTTPトンネリングを有効にすることにより、HTTPトンネリングを使用できます。

注意:

JNDIプロバイダでサポートされるプロトコルがリモートService Busサーバーにあるかどうかの確認は、管理者が行う必要があります。

ビジネス・サービスを作成するとき、ビジネス・サービスにJNDIプロバイダを関連付けることができます。詳細は、「JNDIプロバイダ・リソースの操作」を参照してください。

36 SOA-DIRECTトランスポートの使用

この章では、SOA-DIRECTトランスポートの概要と、サービスでの使用および構成方法について説明します。SOA-DIRECTトランスポートを使用すると、Oracle SOA Suiteサービス・コンポーネント(BPELプロセス、ヒューマン・タスク、ルール、Oracle Mediatorコンポーネントなど)を呼び出すことができます。

注意:

SOA-DIRECTトランスポートはOracle SOA Suite 11g以上のサービス・コンポーネントと通信するためのものです。Service Busは、Oracle SOA Suite 10g リリース3との通信用にbpel-10gトランスポートを備えています。このトランスポートの詳細は、「Oracle BPEL Process Managerトランスポートの使用」を参照してください。

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

- SOA-DIRECTトランスポートの概要

- Service BusでのSOA Suiteサービスの使用

- SOA-DIRECTトランスポート構成のリファレンス

- WS-Addressingのリファレンス

- XMLメッセージングの例

36.1 SOA-DIRECTトランスポートの概要

SOA-DIRECTトランスポートにより、Service BusとOracle SOA Suiteサービス・コンポーネントとの間にネイティブの接続が提供されます。Oracle SOA Suiteで提供されるダイレクト・バインディング・フレームワークを使用すると、コンポジット・アプリケーション内でOracle SOA Suiteサービス・コンポーネントを公開できます。SOA-DIRECTトランスポートは、SOAダイレクト・バインディング・フレームワークを介して公開されたそれらのサービスと対話するため、サービス・バス・レイヤーでのサービス・コンポーネント間の対話が可能になり、Service Busの機能および性能を活用できます。

SOAバインディング・コンポーネントの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のバインディング・コンポーネントのスタート・ガイドおよびダイレクト・バインディング呼出しAPIに関する項を参照してください。

36.1.1 SOA-DIRECTトランスポートの機能

SOA-DIRECTトランスポートは次の機能をサポートしています。

- Javaリモート・メソッド呼出し(RMI)を介した任意のSOAバインディング・コンポーネント・サービスの呼出し

- WS-Addressing(非同期コールバックのReplyToプロパティのオプション自動生成を含む)

- ID伝播

- トランザクション伝播

- 添付ファイル

- SOAサービスの呼出し用に最適化されたRMIトランスポート

- 高可用性とクラスタリングのサポート

- フェイルオーバーとロード・バランシング(サービス・コールバック・ロールのサービスでは使用不可)

- エラー時の接続とアプリケーションの再試行

36.1.2 サービス・バインディング・タイプ

SOA-Directトランスポートでは、SOAP 1.1、SOAP 1.2またはXMLバインドを使用するWSDLタイプのサービスがサポートされます。SOAダイレクト・バインディング・フレームワークでは、ダイレクト・バインディング・サービスはSOAP 1.1およびSOAP 1.2バインドのWSDLとしてのみ公開されます。ただし、XMLバインディングを使用する必要がある場合、インポートされるSOAサービスWSDLファイルをダイレクト・バインディング・サービスのために手動でカスタマイズする必要があります。SOA-DIRECTトランスポートとSOAバインディング・コンポーネントの間のメッセージは常に抽象(バインディングなし)であるため、XMLバインドはメッセージ・ペイロードに影響しません。

36.1.3 SOA-DIRECTトランスポート用のWS-Addressing

SOA-DIRECTトランスポートは、同期および非同期通信でメッセージ相関のためにWS-Addressingしか使用しません。ビジネス・サービス構成でコールバック・プロキシを構成すると、このトランスポートにより、SOAPヘッダーに自動的に次のWS-Addressingプロパティが生成されます。

- ReplyTo: 非同期コールバックでのコールバック・アドレスと接続情報を設定します。

- ReferenceParameters: JNDIと接続ファクトリのプロパティなど、ReplyToのコールバック・プロパティを含みます。サポート対象の次のWS-Addressingバージョンに対応しています。

- http://www.w3.org/2005/08/addressing

- http://schemas.xmlsoap.org/ws/2004/08/addressing

- ReferenceProperties: JNDIと接続ファクトリのプロパティなど、ReplyToのコールバック・プロパティを含みます。サポート対象のWS-Addressingバージョン、http://schemas.xmlsoap.org/ws/2003/03/addressingに対応しています。

ReplyToおよびReferenceParametersの例は、「WS-Addressingのリファレンス」を参照してください。WS-Addressingの他のすべてのプロパティのうち、SOA-DIRECTビジネス・サービスのパススルーで使用できないプロパティまたは適していないプロパティは、Service Busパイプラインで追加または変換する必要があります。WS-Addressing以外の相関メカニズムまたはコールバック・メカニズムを使用する場合は、Service BusとSOAフレームワーク・サービス・コンポーネントとの間のWS-Addressingをサポートするように、パイプラインでメッセージを変換する必要があります。

SOA-DIRECTトランスポートにおけるWS-Addressingの例は、「WS-Addressingのリファレンス」および「XMLメッセージングの例」を参照してください。

36.1.4 SOA-DIRECTトランスポートのセキュリティ

SOA-DIRECTトランスポートでは一方向SSLがサポートされます。SSLを使用するには、ドメインでSSLを有効にし、エンドポイントURIでセキュアなプロトコル(HTTPS、IIOPS、T3Sなど)を使用し、URIでセキュアなポートを参照します。SOA-DIRECT URIの詳細は、「SOA-DIRECTのエンドポイントURI」を参照してください。

SOA-DIRECTトランスポートでは、呼出し元のサブジェクトをサービスを介して渡すか、サービスにバインドされたサービス・アカウントによって、ID伝播を行うことができます。SOA-DIRECTトランスポートは標準化された抽象メッセージのみを扱うため、WS-Securityをサポートしていません。セキュリティ設定の詳細は、「SOA-DIRECTトランスポートを使用するビジネス・サービスの構成」を参照してください。

36.1.5 SOA-DIRECTトランスポートのエラー処理

SOA-DIRECTトランスポートは、接続およびアプリケーションのエラーを認識します。したがって、トランスポートの構成で適切な再試行設定を構成できます。トランスポートは、接続やアプリケーションに関連しないエラーについては一般エラーをスローします。

- 接続エラー

- アプリケーション・エラー

- 一般エラー

36.1.5.1 接続エラー

SOA-DIRECTトランスポートでは、次の状況で接続エラーが発生します。

- ターゲット・サービスが存在していない場合。

- RMIのルックアップまたは呼出し中にネーミング例外が発生した場合(一般エラーのjavax.naming.NamingSecurityException例外を伴います)。

- RMIのルックアップまたは呼出し中にリモート例外が発生した場合。

36.1.5.2 アプリケーション・エラー

SOA-DIRECTトランスポートでは、アウトバウンド・ビジネス・サービスがSOAPフォルトを受信すると、アプリケーション・エラーが発生します。サービスの構成ページで「アプリケーション・エラーの再試行」を選択解除すると、アプリケーション・エラー(再試行を行ってもエラーが継続する可能性がある)の際の再試行を停止できます。

36.1.5.3 一般エラー

SOA-DIRECTトランスポートでは、次の状況で一般エラーが発生します。

- 接続エラーおよびアプリケーション・エラー以外のすべてのエラーの場合。

- javax.naming.NamingSecurityException (JNDIルックアップ中にスローされる)の場合。これは、他のネーミング例外と同じく接続エラーとはみなされません。

36.2 Service BusでのSOA Suiteサービスの使用

この項では、Service BusとOracle SOA Suiteコンポジットの間の同期および非同期通信パターンについて説明します。

- 簡単な使用例 - 同期

- 高度な使用例 - 非同期

36.2.1 簡単な使用例 - 同期

ここでは、Service Busを介してSOAコンポジットとネイティブに通信する、簡単で最も一般的な使用例(同期通信)について説明します。

- トランザクション境界

- SOAコンポジットの同期呼出し

- SOAコンポジットからの同期呼出し

- メッセージと正しい会話の関連付け

36.2.1.1 トランザクション境界

同期BPELコンポーネントでダイレクト・バインディングを使用してプロキシ・サービスと相互運用する場合、Service BusとBPELコンポーネントは、同じグローバル・トランザクションに参加することで同じトランザクション・コンテキストを共有します。パイプラインは、BPELコンポーネントで開始される同じトランザクション・コンテキスト内でバックエンド・アクティビティを実行できます。データ整合性を保証するには、処理中になんらかの不具合で状態を維持できない場合、そのトランザクションで行われたすべての内容をロールバックする必要があります。トランザクションまたはセキュリティの伝播が必要になるため、通常はダイレクト・バインディングが使用されることに注意してください。

Service Busダイレクト・バインディングの失敗は、システム・フォルトとしてBPELコンポーネントにスローされます。これは、リクエスト・パイプライン内で処理が失敗したときに、ロールバックのトランザクションをService Busで常にマーク付けするためです。そのため、Service Busダイレクト・バインディングからスローされるフォルトは、ロールバック・フォルトとなり、SOA Suite側でシステム・フォルトと解釈されます。

この動作の詳細は、Oracle SOA SuiteでのSOAアプリケーションの開発のBPELCallerで、bpel.config.transactionがrequiredに設定されたBPELCalleeをコールする場合に関する項を参照してください。この項では、同期インタフェースを備えたBPELコンポーネント間のトランザクション動作について説明しています。

36.2.1.2 SOAコンポジットの同期呼出し

SOA-DIRECTトランスポートは、ダイレクト・バインディング・サービスとして公開されているSOAコンポジットのすべてのコンポーネントを呼び出すことができます。図36-1に、Service Busを介したクライアントとOracle SOAサービス・コンポーネントとの間の同期通信パターンを示します。SOA-DIRECTビジネス・サービスとダイレクト・バインディング・サービスが使用されます。

図36-1 クライアントによるSOAバインディング・サービスの同期呼出し

次のガイドラインに従って、Oracle SOAダイレクト・バインディング・サービスをService Busを介してクライアントから呼び出します。

- Service Busに、呼び出すSOAサービス・コンポーネントに相当するSOA-DIRECTビジネス・サービスを作成します。

- Service Busで、対応するOracle SOAダイレクト・バインディング・サービスのWSDLファイルに基づいてWSDLリソースを作成します。
SOAダイレクト・バインディング・サービスのWSDLファイルは、Oracle SOA SuiteでのSOAアプリケーションの開発のOracle SOA SuiteでのSOAコンポジット・アプリケーションの開発に関する項に示すとおり、SOAリソース・ブラウザを使用してJDeveloperで探すことができます。

- soa-directトランスポート・タイプおよびWSDLサービス・タイプの新しいビジネス・サービスを作成します。

- 作成したWSDLリソースを選択し、適切なポートまたはバインドを選択します。

注意:

ポートを選択すると、トランスポート・タイプとURIは次の構成ページに自動的に伝播されます。

- 「SOA-DIRECTのエンドポイントURI」の説明に従って、エンドポイントURIを設定します。

- 「SOA-DIRECTトランスポートを使用するビジネス・サービスの構成」に従って、ビジネス・サービスの他の設定を構成します。

- ビジネス・サービスを呼び出すService Busでのプロキシ・サービスを作成します。クライアントで使用されるトランスポート・タイプを選択します。プロキシの構成情報については、Service Busで提供されるオンライン・ヘルプを参照してください。

ステートフル・サービスを使用してメッセージを正しい会話に関連付ける場合は、「メッセージと正しい会話の関連付け」を参照してください。

36.2.1.3 SOAコンポジットからの同期呼出し

SOAコンポジットは、任意のService Bus SB WSDLベース・プロキシ・サービスを呼び出すことができます。SBプロキシ・サービスを呼び出すには、SOAサービス・コンポーネントはターゲット・タイプが「Oracle Service Bus」のダイレクト・バインディング参照を使用する必要があります。ターゲット・タイプの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のアウトバウンド・ダイレクト・バインディング参照の作成方法に関する項を参照してください。

図36-2に、Service Busを介したOracle SOAサービス・コンポーネントと外部サービスとの間の同期通信パターンを示します。

図36-2 SOAバインディング・サービスによる外部サービスの同期呼出し

次のガイドラインに従って、ダイレクト・バインディング参照を使用してSOAコンポジットから外部サービスを呼び出します。

- 呼び出したい外部サービスを表すService Busでのビジネス・サービスを作成します。このサービスでサポートされるトランスポート・タイプを選択します。ビジネス・サービスの構成情報については、Service Busで提供されるオンライン・ヘルプを参照してください。

- Service Busで、ビジネス・サービスを呼び出すSBプロキシ・サービスを作成します。

- ビジネス・サービスを呼び出すプロキシ・サービスで使用されるWSDLリソースを作成します。

- sbトランスポート・タイプおよびWSDLサービス・タイプの新しいプロキシ・サービスを作成します。

- プロキシ・サービスのWSDLファイルを選択し、目的のポートまたはバインディングを選択します。

- プロキシ・サービスの他の設定を構成します。詳細は、「SBトランスポートの使用」を参照してください。

注意:

SBプロキシ・サービス対応のWSDLファイルとポート・タイプを使用して、Service Busを呼び出すダイレクト・バインディング参照を定義します。このWSDLファイルをOracle SOA Suiteプロジェクトにインポートできます。

ステートフル・サービスを使用している場合は、メッセージを正しい会話に関連付ける必要があります。「メッセージと正しい会話の関連付け」を参照してください。

36.2.1.4 メッセージと正しい会話の関連付け

ステートフル・サービスを使用する場合、Service BusとOracle SOAコンポジットの間で同期的に送信されるメッセージは、会話と呼ばれます。メッセージを会話の一部として相互に正しく関連付けるために、SOA-DIRECTトランスポートではWS-Addressingの組込みサポートが提供されます。

WS-Addressingの詳細は、「MessageID/RelatesToヘッダー」を参照してください。会話IDの設定例は、「会話IDの例」を参照してください。

36.2.2 高度な使用例 - 非同期

この項では、SOAコンポジットとService Busの間のSOA-DIRECTトランスポートを使用する非同期通信について説明します。

注意:

WS-Addressingを使用する非同期会話が現在サポートされているSOAサービス・コンポーネントは、BPELプロセス、Mediatorおよびヒューマン・タスクのみです。

- SOAコンポジットの非同期呼出し

- SOAコンポジットからの非同期呼出し

36.2.2.1 SOAコンポジットの非同期呼出し

SOA-DIRECTトランスポートは、ダイレクト・バインディング・サービスとして公開されている非同期SOAサービス・コンポーネントを呼び出すことができます。図36-3に、Service Busを介したクライアントとOracle SOAコンポジットとの間の非同期通信パターンを示します。ダイレクト・バインディング・サービス、SOA-DIRECTトランスポートおよびSBトランスポートが使用されます。

図36-3 クライアントによるSOAバインディング・サービスの非同期呼出し

次のガイドラインに従って、SOAダイレクト・バインディング・サービスをService Busを介してクライアントから非同期に呼び出します。

- インバウンド・クライアント側で、クライアントと対話するService Busアーティファクト(アウトバウンドSOA-DIRECTビジネス・サービスを呼び出すリクエスト・プロキシ・サービス、およびクライアントへのコールバックを処理するコールバック・ビジネス・サービス)を作成します。クライアントによって使用されるトランスポート・タイプを使用します。

- リクエスト・プロキシ・サービス
クライアント・リクエストを受信するプロキシ・サービスを構成します。このプロキシ・サービスはアウトバウンド・リクエストのSOA-DIRECTビジネス・サービスを呼び出します。

コールバックは別の接続に送信されるため、Service Busは、クライアントにコールバックするときに元のコールバック場所を記憶しておく必要があります。WS-Addressingを使用すると、コールバック・アドレスがReplyToアドレス・ヘッダーでリクエスト・プロキシ・サービスに送信されます。SOA-DIRECTビジネス・サービスを呼び出す前に、リクエスト・プロキシ・サービスはこのアドレスをReplyToヘッダー内のreferenceParameterプロパティとして渡すことができます。WS-Addressingの指定に従い、referenceParameterプロパティはコールバックのSOAPヘッダー・ブロックに挿入されます。その後、コールバックのSBプロキシがこのコールバック・アドレスを抽出し、コールバック・ビジネス・サービスURIを設定できます。

コールバック・アドレスの設定の詳細は、「ReplyToヘッダー」および「Service Busを介したコンポジット間非同期通信」を参照してください。

- コールバック・ビジネス・サービス
コールバックを処理するために必要なビジネス・サービスを構成します。このビジネス・サービスはアウトバウンド・コールバックSBプロキシ・サービスによって呼び出されます。

サービスとトランスポートの構成に関するガイダンスは、Service Busで提供されるオンライン・ヘルプを参照してください。

- Service Busのアウトバウンド側で、SOAコンポジットと対話するためのアーティファクトを作成します。これには、呼び出す非同期サービス・コンポーネントを公開するOracle SOAダイレクト・バインディング・サービスへのリクエストを行うリクエストSOA-DIRECTビジネス・サービス、およびダイレクト・バインディング・サービスからのコールバックを処理し、インバウンド・コールバック・ビジネス・サービスを呼び出すコールバックSBプロキシ・サービスが含まれます。

- リクエストSOA-DIRECTビジネス・サービス

- Service Busで、対応するOracle SOAダイレクト・バインディング・サービスのWSDLファイルに基づいてWSDLリソースを作成します。
SOAダイレクト・バインディング・サービスのWSDLファイルは、$operationのOracle SOA SuiteでのSOAコンポジット・アプリケーションの開発に関する項に示すとおり、SOAリソース・ブラウザを使用してJDeveloperで探すことができます。

- soa-directトランスポート・タイプおよびWSDLサービス・タイプの新しいビジネス・サービスを作成します。

- WSDLファイルについては、作成したWSDLリソースを参照し、ダイレクト・バインディング・サービスのために適切なポートまたはバインディングを選択します。
ポートを選択すると、トランスポート・タイプとURIは次の構成ページに自動的に伝播されます。

- 「SOA-DIRECTのエンドポイントURI」の説明に従って、エンドポイントURIを設定します。

- トランスポートの構成ページで、「ロール」を「非同期クライアント」に設定します。

- オプションとして、「コールバック・プロキシ」オプションを使用して、作成したSBコールバック・プロキシ・サービスを選択します。
コールバック・プロキシを選択すると、SOA-DIRECTトランスポートによってWS-Addressingヘッダーが自動的に生成され、非同期コールバック・レスポンスの指定コールバック・プロキシへの送信を予定していることがSOAダイレクト・バインディング・サービスに知らされます。

SOA-DIRECTビジネス・サービスでコールバック・プロキシを選択しない場合のコールバック・アドレスの設定方法については、「WS-Addressingのリファレンス」および「Service Busを介したコンポジット間非同期通信」を参照してください。

- ビジネス・サービスの残りの部分を構成します。詳細は、「SOA-DIRECTトランスポート構成のリファレンス」を参照してください。

- リクエスト・プロキシ・サービスからこのビジネス・サービスを呼び出します。

- コールバックSBプロキシ・サービス

- sbトランスポート・タイプおよびWSDLサービス・タイプの新しいプロキシ・サービスを作成します。

- ダイレクト・バインディング・サービスのWSDLファイルに対応するWSDLファイルを参照し、適切なポートまたはバインディングを選択します。

- プロキシ・サービスの構成を完了します。詳細は、「SBトランスポートを使用するプロキシ・サービスの構成」を参照してください。

36.2.2.2 SOAコンポジットからの非同期呼出し

SOAコンポジットの非同期SOAサービス・コンポーネントは、Service Busを介して外部サービスを呼び出すことができます。このためには、SOAサービス・コンポーネントはターゲット・タイプが「Oracle Service Bus」のダイレクト・バインディング参照を使用する必要があります。ターゲット・タイプの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のアウトバウンド・ダイレクト・バインディング参照の作成方法に関する項を参照してください。

図36-4に、ダイレクト・バインディング参照、SBトランスポートおよびSOA-DIRECTトランスポートを使用した、Service Busを介したOracle SOAサービス・コンポーネントと外部サービスとの間の非同期通信パターンを示します。

図36-4 SOAバインディング・サービスによる外部サービスの非同期呼出し

次のガイドラインに従い、Service Busを介して外部サービスをOracle SOAダイレクト・バインディング参照から非同期で呼び出します。

- Service Busのインバウンド側で、SOAコンポジットと対話するためのアーティファクト(SOAダイレクト・バインディング参照リクエストを受信するリクエストSBプロキシ・サービス、およびSOAダイレクト・バインディング参照へのコールバックを処理するコールバックSOA-DIRECTビジネス・サービス)を作成します。

- リクエストSBプロキシ・サービス

- ダイレクト・バインディング参照との対話に使用されるインタフェースに相当するWSDLリソースを作成します。

- sbトランスポート・タイプおよびWSDLサービス・タイプの新しいプロキシ・サービスを作成します。

- WSDLファイルについては、作成したWSDLファイルを参照し、適切なポートまたはバインディングを選択します。

- プロキシ・サービスの構成を完了します。詳細は、「SBトランスポートを使用するプロキシ・サービスの構成」を参照してください。
コールバックは別の接続に送信されるため、Service Busは、クライアントにコールバックするときに元のコールバック場所を記憶しておく必要があります。WS-Addressingを使用すると、コールバック・アドレスがReplyToアドレス・ヘッダーでリクエスト・プロキシ・サービスに送信されます。外部サービスを呼び出す前に、リクエスト・プロキシ・サービスはこのアドレスをReplyToヘッダー内のreferenceParameterプロパティとして渡すことができます。WS-Addressingの指定に従い、referenceParameterプロパティはコールバックのSOAPヘッダー・ブロックに挿入されます。その後、コールバック・プロキシ・サービスがこのコールバック・アドレスを抽出し、コールバック・ビジネス・サービスURIを設定できます。

コールバック・アドレスの設定の詳細は、「ReplyToヘッダー」および「Service Busを介したコンポジット間非同期通信」を参照してください。

- コールバック・ビジネス・サービス

- soa-directトランスポート・タイプおよびWSDLサービス・タイプの新しいビジネス・サービスを作成します。

- WSDLファイルについては、ダイレクト・バインディング参照に対するコールバック・インタフェースに相当するWSDLファイルを参照し、適切なポートまたはバインディングを選択します。

- 「SOA-DIRECTのエンドポイントURI」の説明に従って、サービスURIを「callback」に設定します。
一般的に、コールバックURIはURI再書込みを使用して呼出し側プロキシで動的に設定されます。ただし、コールバック・アドレスが常に認識されている場合は、"callback"のかわりに正確なコールバック・アドレスを指定できます。

- SOA-DIRECTトランスポートの構成ページでロールを「サービス・コールバック」に設定します。

- 「SOA-DIRECTトランスポートを使用するビジネス・サービスの構成」に従って、ビジネス・サービスの他の設定を構成します。

- Service Busのアウトバウンド側で、外部サービスと対話するためのアーティファクト(外部サービスへのリクエストを作成するリクエスト・ビジネス・サービス、およびこのサービスからのコールバックを処理するコールバック・プロキシ・サービス)を作成します。

- リクエスト・ビジネス・サービス
ビジネス・サービスが外部サービスを呼び出すように構成します。このビジネス・サービスはリクエストSBプロキシ・サービスによって呼び出されます。このサービスでサポートされるトランスポート・タイプを選択します。ビジネス・サービスの構成情報については、Service Busで提供されるオンライン・ヘルプを参照してください。

- コールバック・プロキシ・サービス
コールバック・アドレスをビジネス・サービスに渡すようにプロキシ・サービスを構成します。コールバックURIはリクエスト内で指定されます。URI再書込みを使用してコールバックURIを抽出し、SOA-DIRECTビジネス・サービスに転送します。このサービスでサポートされるトランスポート・タイプを選択します。プロキシ・サービスの構成情報については、Service Busで提供されるオンライン・ヘルプを参照してください。

WS-Addressingを使用したコールバック・アドレス設定の詳細は、「WS-Addressingのリファレンス」を参照してください。

36.3 SOA-DIRECTトランスポート構成のリファレンス

ここでは、SOA-DIRECTトランスポートのエンドポイントURLの形式と構成オプションを説明します。

- SOA-DIRECTのエンドポイントURI

- SOA-DIRECTトランスポートを使用するビジネス・サービスの構成

- SOA-DIRECTトランスポートの環境値

36.3.1 SOA-DIRECTのエンドポイントURI

SOA-DIRECTサーバー用のエンドポイントURIを指定する際は、サービスのロール・タイプに応じて、特定の形式パターンに従う必要があります。

インバウンド・リクエストを処理する「サービス・コールバック」ロールのSOA-DIRECTビジネス・サービスの場合、実際のURIは、実行時にパイプラインで動的に指定されます。次のようにエンドポイントURIを入力します。

callback

または、コールバック・アドレスが常に認識されている場合は、正確なコールバック・アドレスを指定できます。

他のすべてのSOA-DIRECTビジネス・サービス・ロールの場合は、次の形式を使用します。省略可能な要素は大カッコ[]で囲んでいます。

protocol://authority]/default/compositeName[!versionNumber[*label]]/serviceName

説明:

- protocolは、使用するRMIまたはJNDIプロトコルです。以下のいずれかを使用してください。

- iiop/iiops: サーバーにとらわれない汎用プロトコルです。

- t3/t3s: WebLogic Serverで使用します。

- http/https: トンネリングおよびWebLogic Serverで使用します。
HTTP(S)プロトコルの場合は、サーバーでHTTPトトンネリングを有効にします。SSLプロトコルの場合は、サーバーでSSLを有効にします。

SOAサービスがService Busと同じサーバーに配置される場合、protocolとauthorityは省略可能です。

- authority: IPアドレスまたはホスト名と、SOAサービス・コンポーネントをホストするSOAサーバーまたはクラスタのポート。
SOAサービスがService Busと同じサーバーに配置される場合、protocolとauthorityは省略可能です。

- default: このドメイン名の値は常にdefaultです。

- compositeName: バインディング・コンポーネント・サービスが定義されるコンポジット・アプリケーションの名前です。

- !versionNumber: コンポジット・アプリケーションのバージョン番号。これはオプションです。バージョンを指定しないと、最新バージョンが使用されます。

- *label: SOAサービスのWSDLファイルで使用されるラベル・ハッシュで、!versionNumberと一緒に使用します。これはオプションです。

- serviceName: SOAバインディング・コンポーネント・サービスの名前です。

ロード・バランシングとフェイルオーバーのために1つのサービスに複数のURIを指定できますが、表36-1に示すように、サービス・コールバック・ロールではサービスに対して1つのURIしか指定できません。このため、サービス・コールバック・ロールのサービスではロード・バランシングおよびフェイルオーバーは使用できません。

36.3.1.1 クラスタ内のエンドポイントURIの形式

クラスタ内で運用されるSOA-DIRECTトランスポートは、異なる形式のエンドポイントURIを使用します。クラスタ内のエンドポイントURIには、次の形式を使用します。

t3://example_managed1:port1,example_managed2:port2/service_path

このとき、t3://example_managed1:port1,example_managed2:port2はJNDIプロバイダのURLです。

36.3.1.2 エンドポイントURIの例

SOA-DIRECTトランスポート用のエンドポイントURIの例を、次にいくつか示します。

- t3s://example:7002/default/compositeApp/1.0/myService
単一ノードにデプロイされたサービスを指します。

- /default/compositeApp!1.0/myService
Service Busと同じサーバーに配置されているサービスを指します。

- t3://soaserver.example.com:7001/default/VacationRequest!1.0/directclient
バージョン番号を使用して、単一ノードにデプロイされているサービスを指します。これは、SOAバインディング・コンポーネント・サービスのWSDLファイルにおける形式です。

- t3://example_managed1:8001,example_managed2:8002/default/myComposite/myService
"myService"として識別されるクラスタSOAフレームワーク環境を指します。特定のバージョンが指定されていないため、サービスの最新バージョンが使用されます。

36.3.2 SOA-DIRECTトランスポートを使用するビジネス・サービスの構成

表36-1に、ビジネス・サービス用のSOA-DIRECTトランスポートの構成に使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

表36-1 ビジネス・サービス用のSOA-DIRECTトランスポート・プロパティ

プロパティ

説明

JNDIサービス・アカウント

ターゲットSOAサービスのJNDIルックアップのためのセキュリティ資格証明を定義する静的なサービス・アカウントを入力します。サービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。定義済サービス・アカウントのリストから選択できます。

詳細は、「サービス・アカウントの操作」を参照してください。

ロール

サービスで使用する通信パターンを指定するためのオプションとして、次のいずれかを選択します。

- 同期クライアント(デフォルト): このロールでは、非同期コールバックがないため、「コールバック・プロキシ」オプションは無効です。「WS-Addressingのバージョン」オプションも無効です。

- 非同期クライアント: このロールでは、コールバック・プロキシを指定でき、WS-Addressingのバージョンを選択する必要があります。通常は、非同期コールバックが必要です。非同期オプションが有効になるのは、WSDLサービスのタイプがSOAPの場合のみです。

- サービス・コールバック: このロールは、外部サービス呼出しの後で非同期コールバックをSOAサービスに返すためのものです。

コールバック・サービスのロード・バランシングまたはフェイルオーバーはありません。

コールバック・プロキシ

コールバックを受信するプロキシ・サービスを指定します。このオプションは、「非同期クライアント」ロールの場合のみ有効です。

コールバック・プロキシを選択したとき、リクエストまたはプロキシ・サービス・パイプラインによってWS-Addressingが提供されない場合、Service BusはSOAPヘッダーのReplyToプロパティに自動的に値を設定します。SBトランスポート(RMI用)を使用するWSDLプロキシ・サービスを選択する必要があります。また、コールバック・プロキシ・サービスはWS-Addressingを認識する必要があります。

リクエストで送信されるWS-Addressingプロパティ、またはプロキシ・サービス・パイプラインで設定されるWS-Addressingプロパティが、このオプションで設定するコールバック・プロキシのかわりに使用されます。

「コールバック・プロキシ」を指定せず、リクエストにReplyToプロパティが含まれない場合は、プロキシ・サービス・パイプラインによってSOAPヘッダーにReplyToプロパティを提供する必要があります。

フォルト・プロキシ

このオプションは現在サポートされていません。非同期パターンでフォルトを処理するようにコールバック・サービスを構成する必要があります。

WS-Addressingのバージョン

リクエストまたはプロキシ・サービス・パイプラインでWS-Addressingが提供されないときに使用するデフォルトのWS-Addressingバージョンを指定します。このオプションは、「非同期クライアント」ロールの場合のみ有効です。

リクエストで送信されるWS-Addressingプロパティまたはパイプラインで設定されるWS-Addressingプロパティは、このオプションで設定するWS-Addressingバージョンのかわりに使用されます。環境ごとにWS-Addressingのバージョンが異なる場合、パイプラインで必要な変換を実行します。詳細は、「変換の例」を参照してください。

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

呼出し元のサブジェクトを渡す

このオプションを選択すると、SOAサービスを呼び出すときに、Service Busがプロキシ・サービスの認証済サブジェクトを渡します。「呼出し元のサブジェクトを渡す」の代替オプションである「呼出しサービス・アカウント」オプションは、このオプションを選択すると無効になります。

注意: クライアントとターゲット・サーバーが別のドメインにある場合、それらの間でドメインの信頼が有効になっていることを確認します。詳細は、『Oracle WebLogic Serverセキュリティの管理』のクロスドメイン・セキュリティのサポートに関する重要情報が記載された項を参照してください。

呼出しサービス・アカウント

RMI呼出し用のサービス・アカウントを選択することにより、カスタム・セキュリティ資格証明を指定します。任意のタイプ(パス・スルー、静的またはマッピング)のサービス・アカウントを指定できます。サービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。これは、「呼出し元のサブジェクトを渡す」オプションのかわりに使用します。

詳細は、「サービス・アカウントの操作」を参照してください。

36.3.3 SOA-DIRECTトランスポートの環境値

SOA-DIRECTトランスポートでサポートされる環境値を表36-2に示します。これらの変数に指定した値により、特定のSOA-DIRECTビジネス・サービス用に構成されたプロパティがオーバーライドされます。

表36-2 SOA-DIRECTトランスポートの環境値

環境値

説明

「JNDIサービス・アカウント」(セキュリティ・カテゴリ)

ターゲットSOAサービスのJNDIルックアップのためのセキュリティ資格証明を定義する静的なサービス・アカウント。サービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。

サービス・アカウントの詳細は、「サービス・アカウントの操作」を参照してください。

「呼出し元のサブジェクトを渡す」(セキュリティ・カテゴリ)

これを有効にすると、SOAサービスを呼び出すときに、Service Busがプロキシ・サービスの認証済サブジェクトを渡します。次の「呼出しサービス・アカウント」変数は、「呼出し元のサブジェクトを渡す」のかわりに使用します。

「呼出しサービス・アカウント」(セキュリティ・カテゴリ)

カスタム・セキュリティ資格証明を使用するRMI呼出し用のサービス・アカウント。任意のタイプ(パス・スルー、静的またはマッピング)のサービス・アカウントを指定できます。サービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。これは、「呼出し元のサブジェクトを渡す」のかわりに使用します。

「ワーク・マネージャ」(環境カテゴリ)

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンス。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

これらの値の詳細は、「SOA-DIRECTトランスポートを使用するビジネス・サービスの構成」を参照してください。

36.4 WS-Addressingのリファレンス

ここでは、SOA-DIRECTトランスポートとOracle SOAコンポジットのネイティブ通信に使用する特定のWS-Addressingプロパティについて説明します。また、「高度な使用例 - 非同期」で示している非同期通信でコールバック・アドレスを指定する方法についても説明します。

WS-Addressingの例は、「XMLメッセージングの例」を参照してください。

- ReplyToヘッダー

- MessageID / RelatesToヘッダー

36.4.1 ReplyToヘッダー

非同期通信では、リクエストとは別の接続でコールバックが送信されます。サービス開発者は、非同期のやり取りで正しいコールバック・アドレスを提供してコールバックが正しいクライアントに送信されるようにする必要があります。WS-Addressing相関によるSOA-DIRECTトランスポートを使用するとき、コールバック・アドレスはWS-AddressingのReplyToヘッダーに指定されます。

36.4.1.1 SOAコンポジットの非同期コール

SOA-DIRECTビジネス・サービスは、オプションでReplyToヘッダーを生成できます。ビジネス・サービスの構成で、コールバックを処理するために「コールバック・プロキシ」を選択すると、SOA-DIRECTトランスポートは、このコールバック・プロキシに対応する正しいコールバック・アドレスをReplyToヘッダーに設定します。このヘッダーが生成されるのは、着信メッセージにすでにReplyToヘッダーが含まれない場合のみであることに注意してください。

詳細は、「SOAコンポジットの非同期呼出し」を参照してください。

36.4.1.2 SOAコンポジットの非同期コール・バック

Service Busを介して外部サービスをOracle SOAコンポジットからコールするとき、コールバック・アドレスを手動で設定する必要があります。このためには、コールバックSOA-DIRECTビジネス・サービスを呼び出すプロキシ・サービスにReplyToの値としてコールバック・アドレスを設定します。

詳細は、「SOAコンポジットからの非同期呼出し」を参照してください。

36.4.2 MessageID / RelatesToヘッダー

WS-AddressingのMessageIDヘッダーとRelatesToヘッダーは、Service BusとOracle SOAサービス・コンポーネントの会話で会話IDの格納に使用され、関連するメッセージが同じ会話内に維持されるようにします。

ReplyToとは異なり、SOA-DIRECTトランスポートでは、MessageIDヘッダーまたはRelatesToヘッダーの組込みサポートは提供されません。かわりに、SOA-DIRECTビジネス・サービスを呼び出すパイプラインにこれらのヘッダーの正しい値を設定する必要があります。

次に説明するように、MessageIDヘッダーとRelatesToヘッダーを使用するための要件は、同期会話と非同期会話で少し異なります。

- 同期会話: MessageIDヘッダーの値により、最初のリクエストで会話IDが決まります。同じ会話内のその後のリクエストでは、この会話IDをRelatesToヘッダーに提供する必要があります。

- 非同期コールバック: MessageIDヘッダーの値により、最初のリクエストで会話IDが決まります。その後、コールバックではこの会話IDをRelatesToヘッダーに提供する必要があります。

メッセージが正しい会話に関連付けられるように会話IDを設定する方法の詳細は、 「メッセージと正しい会話の関連付け」および「会話IDの例」を参照してください。

36.5 XMLメッセージングの例

次に、Service BusとOracle SOAサービス・コンポーネントの間のXMLメッセージの例を示します。

- 会話IDの例

- Service Busを介したコンポジット間非同期通信

36.5.1 会話IDの例

ここでは、Service BusとOracle SOAコンポジットの会話内のメッセージに会話IDを設定する例を示します。図36-5では、クライアントがOracle SOAコンポジットのBPEL Processコンポーネントを同期で呼び出しています。ビジネス・サービス(B1)は、SOA-DIRECTトランスポートを使用してプロセスを呼び出します。プロキシ・サービス(P1)によってコールされるパイプラインは、必要な会話IDマッピングを処理します。SOAコンポジットはBPEL Processをダイレクト・バインディング・サービスとして公開します。

図36-5 Service Busを介した同期的なやり取りでの操作

36.5.1.1 ポートおよびメッセージ定義

この項の例では、WSDLファイルで定義された次のポートおよびメッセージ定義を使用します。

<wsdl:types>
<xsd:schema
targetNamespace="http://www.sample.org/spec/samples/types"
elementFormDefault="qualified">
<xsd:complexType name="ValueHolder">
<xsd:all>
<xsd:any minOccurs="1"/>
</xsd:all>
</xsd:complexType>
</xsd:schema>
</wsdl:types>
<message name="create"/>
<message name="putRequest">
<part name="key" type="xsd:string"/>
<part name="value" type="types:ValueHolder"/>
</message>
<message name="putResponse">
<part name="value" type="types:ValueHolder"/>
</message>
...
<message name="dispose"/>
<portType name="ServiceMap">
<operation name="create">
<input message="tns:create"/>
</operation>
<operation name="put">
<input message="tns:putRequest"/>
<output message="tns:putResponse"/>
</operation>
...
<operation name="dispose">
<input message="tns:dispose"/>
</operation>
</portType>

36.5.1.2 WS-Addressingでの会話IDの設定

この例は、WS-Addressingを使用して会話内のメッセージに会話IDを設定する方法を示しています。

図36-5に通信パターンが示されています。

作成操作

<soap:Envelope>
<soap:Header>
<wsa03:MessageID>uuid:123456789</wsa03:MessageID>
</soap:Header>
<soap:Body>
<create/>
</soap:Body>
</soap:Envelope>

Put操作

<soap:Envelope>
<soap:Header>
<wsa03:MessageID>uuid:111111111</wsa03:MessageID>
<wsa03:RelatesTo>uuid:123456789</wsa03:RelatesTo>
</soap:Header>
<soap:Body>
<put>
<key>key</key>
<value>
<PO/>
</value>
</put>
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Body>
<putResponse>
<value/>
</putResponse>
</soap:Body>
</soap:Envelope>

<put>操作にもMessageIDがありますが、RelatesToに会話IDを示す値があるので無視されます。

36.5.1.3 メッセージ・ペイロード・データでの会話IDの設定

この例は、メッセージ・ペイロード・データを使用して会話内のメッセージに会話IDを設定する方法を示しています。

これらの例では、プロキシ・サービスがIDをMessageID/RelatesTo SOAPヘッダーにマッピングします。

図36-5に通信パターンが示されています。

作成操作

クライアントからプロキシ・サービス

<soap:Envelope>
<soap:Body>
<create/>
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Body>
<createResponse>
<mapID>uuid:123456789</mapID>
</createResponse>
</soap:Body>
</soap:Envelope>

プロキシ・サービスからSOAコンポジット(SOA-DIRECTビジネス・サービスを使用)

<soap:Envelope>
<soap:Header>
<wsa03:MessageID>uuid:123456789</wsa03:MessageID>
</soap:Header>
<soap:Body>
<create/>
</soap:Body>
</soap:Envelope>

説明なし: IDはパイプラインのリクエストで生成され、プロセスを呼び出す前に<wsa03:MessageID>として挿入されました。プロセス側では、作成操作は一方向の操作なので、クライアントに応答する前にSOAPレスポンスが作成される必要があります。プロキシ・サービスで生成されたIDがレスポンスによって返送されます。

Put操作

クライアントからプロキシ・サービス

<soap:Envelope>
<soap:Body>
<put>
<mapID>uuid:123456789</mapID>
<key>key</key>
<value>
<PO/>
</value>
</put>
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Body>
<putResponse>
<value/>
</putResponse>
</soap:Body>
</soap:Envelope>

プロキシ・サービスからSOAコンポジット(SOA-DIRECTビジネス・サービスを使用)

<soap:Envelope>
<soap:Header>
<wsa03:RelatesTo>uuid:123456789</wsa03:RelatesTo>
</soap:Header>
<soap:Body>
<put>
<key>key</key>
<value>
<PO/>
</value>
</put>
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Body>
<putResponse>
<value/>
</putResponse>
</soap:Body>
</soap:Envelope>

破棄操作

クライアントからプロキシ・サービス

<soap:Envelope>
<soap:Body>
<dispose>
<mapID>uuid:123456789</mapID>
</dispose>
</soap:Body>
</soap:Envelope>

プロキシ・サービスからSOAコンポジット(SOA-DIRECTビジネス・サービスを使用)

<soap:Envelope>
<soap:Header>
<wsa03:RelatesTo>uuid:123456789</wsa03:RelatesTo>
</soap:Header>
<soap:Body>
<dispose/>
</soap:Body>
</soap:Envelope>

36.5.1.4 変換の例

これらの例では、クライアントがWS-Addressing仕様の新しいバージョン(wsa04接頭辞)を使用します。プロキシ・サービスで、wsa03接頭辞を使用するようにSOAPヘッダーの変換を行う必要があります。プロキシ・サービス開発者はトランスフォーメーションを構成します。

図36-5に通信パターンが示されています。

作成操作

クライアントからプロキシ・サービス

<soap:Envelope>
<soap:Header>
<wsa04:MessageID>uuid:123456789</wsa04:MessageID>
</soap:Header>
<soap:Body>
<create/>
</soap:Body>
</soap:Envelope>

プロキシ・サービスからSOAコンポジット(SOA-DIRECTビジネス・サービスを使用)

<soap:Envelope>
<soap:Header>
<wsa03:MessageID>uuid:123456789</wsa03:MessageID>
</soap:Header>
<soap:Body>
<create/>
</soap:Body>
</soap:Envelope>

Put操作

クライアントからプロキシ・サービス

<soap:Envelope>
<soap:Header>
<wsa04:MessageID>uuid:111111111</wsa04:MessageID>
<wsa04:RelatesTo>uuid:123456789</wsa04:RelatesTo>
</soap:Header>
<soap:Body>
<put>
<key>key</key>
<value>
<PO/>
</value>
</put>
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Body>
<putResponse>
<value/>
</putResponse>
</soap:Body>
</soap:Envelope>

プロキシ・サービスからSOAコンポジット(SOA-DIRECTビジネス・サービスを使用)

<soap:Envelope>
<soap:Header>
<wsa03:MessageID>uuid:111111111</wsa03:MessageID>
<wsa03:RelatesTo>uuid:123456789</wsa03:RelatesTo>
</soap:Header>
<soap:Body>
<put>
<key>key</key>
<value>
<PO/>
</value>
</put>
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Body>
<putResponse>
<value/>
</putResponse>
</soap:Body>
</soap:Envelope>

36.5.2 Service Busを介したコンポジット間非同期通信

次の例は、Service Busを介して別のSOAコンポジットを非同期で呼び出すSOAコンポジットに関連するSOAPヘッダーです。最初のSOAコンポジットは、ダイレクト・バインディング参照として公開されたBPELプロセスを使用して、Service Busを呼び出します。2番目のSOAコンポジットは、ダイレクト・バインディング参照として公開されたBPELプロセスを使用して、Service Busからのリクエストを受信します。

図36-6のP1とP2は、B1およびB2ビジネス・サービスにメッセージを渡し、変換を実行するパイプラインを含むプロキシ・サービスで、SOA-DIRECTトランスポートを使用したSOAコンポジットのコールに必要です。

図36-6 Service Busを介してSOAコンポジットを呼び出すSOAコンポジット

次のSOAPヘッダー例については、図36-6を参照してください。

36.5.2.1 ポートおよびメッセージ定義

<message name="LoanServiceRequestMessage">
<part name="payload" element="types:loanApplication"/>
</message>
<message name="LoanServiceResultMessage">
<part name="payload" element="types:loanOffer"/>
</message>
<portType name="LoanService">
<operation name="initiate">
<input message="tns:LoanServiceRequestMessage"/>
</operation>
</portType>
<portType name="LoanServiceCallback">
<operation name="onResult">
<input message="tns:LoanServiceResultMessage"/>
</operation>
</portType>

36.5.2.2 BP1からP1 - 開始操作

<soap:Envelope>
<soap:Header>
<wsa03:ReplyTo>
<wsa03:Address>
t3://soaserver:8001/default/AmericanLoanClient/LoanserviceRequester
</wsa03:Address>
</wsa03:ReplyTo>
<MessageID>AmericanLoanClient~1.0/60007</MessageID>
</soap:Header>
<soap:Body >
<loanApplication>
...
</loanApplication>
</soap:Body>
</soap:Envelope>

36.5.2.3 P1/B1からBP2

<soap:Envelope>
<soap:Header>
<wsa03:ReplyTo>
<wsa03:Address>http://serverB:7001/P2</wsa03:Address>
<wsa03:referenceParameters>
<osb:Callback>
<osb:Address>
t3://soaserver:8001/default/AmericanLoanClient/LoanserviceRequesterRef#LoanserviceRequesterBpel
</osb:Address>
</osb:Callback>
</wsa03:referenceParameters>
</wsa03:ReplyTo>
<MessageID>AmericanLoanClient~1.0/60007</MessageID>
</soap:Header>
<soap:Body >
<loanApplication>
...
</loanApplication>
</soap:Body>
</soap:Envelope>

ReplyToのコールバック・アドレスは、B1が、「SOA-DIRECTトランスポートを使用するビジネス・サービスの構成」の説明に従って、SOA-DIRECTトランスポート構成の「コールバック・プロキシ」フィールドから値を取得することによって設定されます。B1のコールバック・プロキシはP2です。

元のreplyTo情報は、(後に続く) onResultコールバック・メッセージに反映されるように、ラップして参照プロパティとして送信する必要があります。

注意:

このサンプルでは、説明のためにosb:Callbackとosb:Addressを使用しています。WS-Addressingのサポートのために定義された標準またはService Bus標準の要素はありません。

36.5.2.4 BP2からP2 - onResult操作

<soap:Envelope>
<soap:Header>
<wsa03:RelatesTo>AmericanLoanClient~1.0/60007</wsa03:RelatesTo>
<osb:Callback>
<osb:Address>
t3://soaserver:8001/default/AmericanLoanClient/LoanserviceRequesterRef#LoanserviceRequesterBpel
</osb:Address>
</osb:Callback>
</soap:Header>
<soap:Body >
<loanOffer>
...
</loanOffer>
</soap:Body>
</soap:Envelope>

参照プロパティosb:Callbackは、Oracle BPEL Process ManagerエンジンによってSOAPヘッダーとして返送されます。

36.5.2.5 P2/B2からBP1 - onResult操作

<soap:Envelope>
<soap:Header>
<wsa03:RelatesTo>AmericanLoanClient~1.0/60007</wsa03:RelatesTo>
</soap:Header>
<soap:Body >
<loanOffer>
...
</loanOffer>
</soap:Body>
</soap:Envelope>

この一時的なosb:CallbackヘッダーはP2のパイプラインで削除されますが、このヘッダーを削除する前に、ビジネス・サービスB2のSOA-DIRECTトランスポートがコールバック・メッセージを正しいSOAサービス・コンポーネントに送信できるようにreplyToのアドレス値が$outbound変数にコピーされます。

37 Tuxedoトランスポートの使用

この章では、Tuxedoトランスポートの概要と、サービスでの使用および構成方法について説明します。Tuxedoトランスポートを使用すると、TuxedoサービスをService Bus環境にもたらすことができます。

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

- Tuxedoトランスポートの概要

- Oracle Tuxedo Connectorの構成

- Service BusでのTuxedoサービスの使用

- TuxedoでのService Busの使用

- Tuxedoトランスポートのバッファ変換

- Tuxedoトランスポートのトランザクション処理

37.1 Tuxedoトランスポートの概要

Service BusとOracle Tuxedoを連携して動作させることにより、各製品に用意されているサービスを使用できます。Tuxedoトランスポートでは、Service BusからTuxedoドメインへの、安全で保証された、高パフォーマンスの双方向アクセスが提供されます。Tuxedoトランスポートでは、Tuxedoドメインからサービスをコールすることも、Tuxedoドメインにあるサービスをコールすることもできます。

サービスはアウトバウンドまたはインバウンドのいずれかです。

- Service Busが、Tuxedoに用意されているサービスを使用する場合、TuxedoトランスポートによりそれらのTuxedoサービスへのアクセスが容易になります。アウトバウンドという用語はこのビジネス・サービス・シナリオを表します。

- TuxedoでService Busに用意されているサービスを使用する場合、TuxedoサービスはService Busサービスを、もう1つのTuxedoアプリケーションのようにコールできます。インバウンドという用語はこのプロキシ・サービス・シナリオを表します。

Tuxedoトランスポートは、JDeveloperまたはOracle Service Busコンソールで構成できます。特定のパラメータによって、プロキシ・サービスとビジネス・サービスの両方を定義します。Tuxedo転送の構成を有効にするには、1つのローカル・アクセス・ポイントおよび1つのリモート・アクセス・ポイントを含む、基本的なWebLogic Tuxedo Connector (WTC)構成が必要です。トランザクション・コンテキストとセキュリティ・コンテキストもサポートされます。

次の図に、このメッセージ処理プロセスをまとめます。

図37-1 WTCのメッセージ処理

37.1.1 Tuxedoトランスポートの機能

Service BusのネイティブなTuxedoトランスポートでは、次の機能が使用できます。

- 高水準の階層トランスポート
ネイティブのTuxedoトランスポートは、Service Busに完全に統合されています。Tuxedoビジネス・サービスとTuxedoプロキシ・サービスの両方を構成、管理、およびモニターできます。

- 双方向アクセス
Service Busは、SOAP、JMSまたは他のサービスとTuxedo間の仲介として機能します。Tuxedoトランスポートにより、Service Busのビジネス・サービスとしてTuxedo ATMIサービスにアクセスしたり、Tuxedoで、Service Busのプロキシ・サービスを別のATMIサービスとして表示できるようになります。

- バッファ変換
XMLメッセージをTuxedoバッファ・タイプに、またTuxedoバッファ・タイプをXMLに変換できます。すべての標準のTuxedoバッファ・タイプがサポートされており、変換は自動的および透過的に行われます。詳細は、「Tuxedoトランスポートのバッファ変換」を参照してください。

- トランザクションの整合性
Tuxedoトランスポートにより、インバウンド・メッセージとアウトバウンド・メッセージのトランザクションの整合性が実現されます。Tuxedoサービスを、「必ず1回」のサービス品質(QoS)が可能なグローバル・トランザクションのコンテキスト内で呼び出すことができます。Tuxedoアプリケーションは、トランザクションを開始し、Service Busサービスをコールでき、XAトランザクション・コンテキストはService Bus、パイプラインに送信され、最終的に目的のトランスポートに送信されます。詳細は、「Tuxedoトランスポートのトランザクション処理」を参照してください。

- セキュリティの伝播
パイプラインの最初で確立されたセキュリティ・コンテキストは、TuxedoクライアントまたはService Busクライアントのいずれかから、もう一方のシステムに伝播します。つまり、受信した、認証が必要なService BusへのSOAP over HTTPリクエストは、Service Busによって認証されます。トランザクションと同様に、このサポートも完全に双方向であるため、Tuxedoに対し認証されたクライアントは、Service Busサービスにも、再度認証を必要とせずにリクエストを行うことができます。

- 暗号化されたネットワーク接続
WTC構成によってService BusとTuxedo間の接続を暗号化し、2つのシステム間の通信のセキュリティとプライバシを確保できます。

- ロード・バランシング
Service BusとTuxedoドメインの接続の要件は、単一のネットワーク接続のみです。ただし、マシンまたはネットワーク障害の場合は複数の接続が必要になる場合があります。ロード・バランシングのために、単一のドメインまたは複数のドメインに、複数の接続を確立できます。

37.2 Oracle Tuxedo Connectorの構成

Tuxedoトランスポートにより、WebLogic Tuxedo Connector (WTC)を使用してTuxedoサービスにアクセスできるようになります。Tuxedoトランスポートを使用するには、1つのローカル・アクセス・ポイントおよび1つのリモート・アクセス・ポイントを含む基本のWTCサーバーを構成する必要があります。

次の項では、WTCを構成する方法を説明します。

- 始める前に

- Oracle Tuxedo Connectorの構成

WTCのセキュリティの詳細は、『Oracle WebLogic Server WebLogic Tuxedo Connectorの管理』のOracle TuxedoとOracle WebLogic Server間のセキュリティを提供するためのOracle WebLogic Tuxedo Connectorの構成方法に関する項を参照してください。

37.2.1 始める前に

Service Busで使用するTuxedoアプリケーションに関する次の情報を収集します。

- Tuxedoローカル・アクセス・ポイントのID

- Tuxedoローカル・アクセス・ポイントのネットワーク・アドレス

- エクスポートされたTuxedoサービスの名前

- サービスで、XMLからFMLおよびFMLからXMLへの変換、あるいはViewからXMLまたはXMLからViewへの変換が必要かどうか
次の項で説明する例では、FML/FML32バッファ・タイプの使用を前提とします。

- Tuxedoドメイン・ゲートウェイがこのOracle Tuxedo Connectorインスタンスを表すために使用するアクセス・ポイントのID。これはリモート・アクセス・ポイントIDとも呼ばれます。)

- Tuxedoドメイン・ゲートウェイがこのOracle Tuxedo Connectorローカル・アクセス・ポイントのために定義したネットワーク・アドレス。これはリモート・ネットワーク・アドレスとも呼ばれます。)

37.2.2 Oracle Tuxedo Connectorの構成

Service BusにTuxedoビジネス・サービスおよびプロキシ・サービスを作成またはインポートする場合、サービス構成にはOracle WebLogic Server管理コンソールにWebLogic Tuxedo Connectorリソースとして表示されるWebLogic Tuxedo Connector構成が含まれています。Service Busは同時に使用するWebLogic Tuxedo Connectorリソースを保つ必要があります。Oracle WebLogic Server管理コンソールにあるそれらのWebLogic Tuxedo Connectorリソースを変更すると、このリソースとService Busは同期しなくなります。また、Service Busにサービスを再インポートすると、サービス・アクティブ化が失敗します。

Service BusでWebLogic Tuxedo Connectorリソースを使用および構成するには、次のガイドラインに従ってください。

- Service Busプロキシおよびビジネス・サービスに使用されるOracle WebLogic ServerコンソールにあるWebLogic Tuxedo Connectorリソースは変更しないでください。Service Busサービス構成のWebLogic Tuxedo Connector構成を変更します。

- Service BusおよびOracle WebLogic ServerコンソールでのTuxedoサービス間にWebLogic Tuxedo Connector構成は同期していない場合、Oracle WebLogic ServerコンソールにあるWebLogic Tuxedo Connectorリソースを削除し、Service BusのTuxedoサービスを再構成するか、または再インポートする簡単な方法で、構成を同期できます。

37.3 Service BusでのTuxedoサービスの使用

次の項では、Service BusからTuxedoサービスを使用する方法を説明します。

- Tuxedoベースのビジネス・サービスの構成

- Tuxedoベースのビジネス・サービスのロード・バランシングおよびフェイルオーバー

- Tuxedoベースのビジネス・サービスのエラー処理

- 構成のテスト

37.3.1 Tuxedoベースのビジネス・サービスの構成

TuxedoサービスをService Busから使用するには、JDeveloperまたはOracle Service Busコンソールで、Tuxedoトランスポートを使用する新しいビジネス・サービスを作成します。ビジネス・サービスの作成と構成の詳細は、「ビジネス・サービスの作成と構成」を参照してください。Tuxedoトランスポートに固有のビジネス・サービスのプロパティについては、「Tuxedoトランスポートを使用するビジネス・サービスの構成」を参照してください。

ビジネス・サービスの作成時に、トランスポートとして「tuxedo」を選択し、サービス・タイプとして「任意のXMLサービス」または「メッセージ・サービス」を選択します。

注意:

「Service Bus」コンソールで、Tuxedoトランスポート・ビジネス・サービスの「トランスポート」タブを編集した場合、変更を伝播するにはタブを保存して閉じる必要がある場合があります。たとえば、エンドポイントURIを追加した場合、「トランスポートの詳細」タブで追加したエンドポイントURIを表示するには、タブを保存して閉じ、再度開く必要があります。

37.3.1.1 Tuxedoトランスポートのビジネス・サービスのエンドポイントURI

Tuxedoベースのビジネス・サービスを作成する際は、サービスのエンドポイントURIを指定します。Tuxedoサービスへのアウトバウンド・コールには、次のURI形式を使用します。

tuxedo:resourcename[/remotename]

説明:

- resourcenameは、WTCインポート・サービス名に対応します。

- remotenameは、リモートTuxedoドメインによりエクスポートされたサービス名に対応します。これはオプションです。

タイプ/QのTuxedoリソースへのアウトバウンド・コールには、次のURI形式を使用します。

tuxedo-queue:sendQspace/sendQname[/[rcvQspace:]/rcvQname][/failureQname]

説明:

- tuxedo-queueは、/Q呼出しが行われることを示します。

- sendQspaceは、Tuxedoドメインのキュー・スペースの一意の名前に対応します。

- sendQnameは、リクエストが格納されるキュー・スペースのキュー名に対応します。

- rcvQspaceは、返信が受信されるTuxedoドメインのキュー・スペースの一意の名前に対応します。これはオプションです。指定しない場合は、sendQspaceの値が使用されます。

- rcvQnameは、返信が受信されるTuxedoドメインのキューの名前に対応します。これはオプションです。

注意:

rcvQspaceおよびrcvQnameプロパティは省略可能です。どちらの値も指定しない場合、ランタイムはただちに戻り、レスポンスは想定されません。この場合、Tuxedoトランスポートの詳細ページにある「レスポンスが必要」オプションは使用できません。

どちらかの値を指定した場合に、「レスポンスが必要」オプションを選択していないと、指定した値は無視されます。

- failureQnameは、Tuxedoドメイン内でエラー・メッセージが格納されるキューの名前に対応します。この値も省略可能です。rcvQspaceとrcvQnameのどちらも指定されていないのに、failureQnameが指定されている場合、URI形式はtuxedo-queue:sendQspace/sendQname//failureQnameになります。

注意:

レスポンスが想定されている場合は、リクエストを送信したのと同じスレッドでレスポンスが発生します。

Tuxedoトランスポートでは、URIからリソース名とリモート名を使用して、WTCインポート・サービスを動的に作成します。複数のURIを指定する場合、エンドポイントごとに一意のリソース名を指定する必要があります。リモート名が指定されていない場合は、その値がリソース名の値になります。リモート名が入力されていない、またはリモート名およびリソース名が同じである場合は、1つのURIのみを使用できます。これにより、既に定義されたWTCインポート・サービスでWTCロード・バランシングおよびフェイルオーバーを使用できるようになります。

注意:

同一のURIを2つ構成すると、そのサービス名がすでに存在していることを通知するエラーが表示されます。

37.3.2 Tuxedoベースのビジネス・サービスのロード・バランシングおよびフェイルオーバー

ビジネス・サービスを指定し、エンドポイントURIを定義する場合に、リソース名とは異なるリモート名を入力すると、Service Busのロード・バランシングおよびフェイルオーバー機能が使用できます。この場合、複数のサービス名を定義し、それらを、複数のリモート・ドメインにレプリケートされたサービスに関連付けることができます。リソース名はユニークである必要がありますが、リモート名はユニークである必要はありません。

37.3.3 Tuxedoベースのビジネス・サービスのエラー処理

Tuxedoベースのビジネス・サービスでアプリケーションと通信のエラーを処理するには、次のように構成します。

- アプリケーション・エラー: アプリケーション・エラーが発生したときにビジネス・サービスのエンドポイントURIを再試行するかどうかを指定します。詳細は、「ビジネス・サービスのトランスポート・プロトコル構成」を参照してください。

- 通信エラー: 通信エラーが発生した場合に、ビジネス・サービスのURIをオフラインにするかどうかを指定します。詳細は、『Oracle Service Busの管理』の応答しないエンドポイントURIをオフラインにするためのService Busの構成に関する項を参照してください。

表37-1はTuxedo例外と例外によって示されるService Busエラーについて説明しています。

表37-1 Tuxedo例外

例外

説明

TPESVCFAIL

サービスが失敗しました。アプリケーション・エラーです。

TPENOENT

リクエストしたエントリが存在しません。通信エラーです。

TPEPERM

パーミッション・エラーが発生しました。通信エラーです。

37.3.4 構成のテスト

Service BusでTuxedoが動作するための構成が終了したら、Oracle Service Busコンソールにあるテスト・コンソールを使用して構成をテストできます。

次のタスク・リストは、Service BusによるTuxedoのアウトバウンドでの使用をテストするプロセスをまとめたものです。

1. Tuxedoサーバーを構築して起動します。

2. 作成したビジネス・サービスに関連付けられているService Busプロキシ・サービスをコールするように、Tuxedoサービスを設定します。

3. Oracle Service Busコンソールで、「アクティブ化」をクリックして、テスト・コンソールを有効にします。

4. ビジネス・サービスをエディタで開き、右上隅にある「テスト・コンソールの起動」アイコンをクリックします。

5. テスト・コンソールにペイロードを入力します。詳細は、「ビジネス・サービス・テスト」を参照してください。

6. 「実行」をクリックします。

レスポンス・ページに、サービス・リクエストの結果が表示されます。

37.4 TuxedoでのService Busの使用

次の項では、TuxedoからService Busサービスを使用する方法について説明します。

- Tuxedoベースのプロキシ・サービスの構成

- 構成のテスト

37.4.1 Tuxedoベースのプロキシ・サービスの構成

Service BusサービスをTuxedoから使用するには、JDeveloperまたはOracle Service Busコンソールで、新しいプロキシ・サービスを構成します。プロキシ・サービスの作成と構成の詳細は、「プロキシ・サービスの作成と構成」を参照してください。Tuxedoトランスポートに固有のプロキシ・サービスのプロパティについては、「Tuxedoトランスポートを使用するプロキシ・サービスの構成」を参照してください。

プロキシ・サービスの作成時に、トランスポートとして「tuxedo」を選択し、サービス・タイプとして「任意のXMLサービス」または「メッセージ・サービス」を選択します。エンドポイントURIは、サービスがデプロイされたTuxedoサーバー上のエンドポイントURIに対応するサービス名です。

37.4.2 構成のテスト

TuxedoをService Busとともに使用するように構成したら、サービスをテストして、そのサービスが正しく動作することを確認できます。XMLからFML32およびFML32からXMLへの変換を使用している場合は、Tuxedoに含まれているud32 Tuxedoクライアント・プログラムを使用してこの構成をテストします。FML変換を使用している場合は、udクライアントを使用できます。ud32は、FMLバッファのテキスト表現で構成される入力を読み込みます。

XMLからFMLおよびFMLからXMLへの変換を使用しない場合は、テスト・クライアント・プログラムをTuxedoで開発してこの構成をテストする必要があります。

37.5 Tuxedoトランスポートのバッファ変換

Service BusとTuxedoを相互運用して、各製品に用意されているバッファ変換を含めたサービスを使用できます。Service BusのサービスのタイプとTuxedoのバッファ・タイプによって変換の方法が決まります。

TuxedoトランスポートがService Busでサポートするサービスのタイプは、任意のXMLサービスおよびメッセージ・サービスです。

- 任意のXMLサービス(SOAP以外): XMLベースのサービスへのメッセージはXMLですが、サービスの構成で許可された任意のTuxedoのバッファ・タイプを使用できます。

- メッセージ・サービス: メッセージ・サービスは、あるデータ型のメッセージを受信し、レスポンスとして別のデータ型のメッセージを返すことができます。サポートされるデータ型は、XML、MFL、テキスト、および型なしバイナリです。

次の項では、Tuxedoトランスポートでのバッファ変換の処理方法について説明します。

- 任意のXMLサービス・タイプの場合のバッファ変換

- メッセージ・サービス・タイプの場合のバッファ変換

37.5.1 任意のXMLサービス・タイプの場合のバッファ変換

表37-2に、サービスのタイプが任意のXMLサービスの場合の、Tuxedoのバッファ・タイプに応じたTuxedoトランスポートの動作を示します。任意のXMLサービスの場合、ペイロードは整形式のXMLドキュメントであることが必要です。

表37-2 任意のXMLサービスの場合のバッファ変換

Tuxedoバッファ・タイプ

Tuxedoトランスポートの動作

STRING

バッファをそのまま渡します。

CARRAY

X_OCTET

バッファをそのまま渡します。

FML/FML32

構成されたフィールド・クラスを使用して、バッファをXMLに(またはXMLからバッファに)変換します。

XML

バッファをそのまま渡します。

注意: TuxedoのバッファがXMLの場合、TuxedoアプリケーションはNULLバイトを送信しません。

VIEW/VIEW32

X_C_TYPE

X_COMMON

構成されたViewクラスを使用して、バッファをXMLに(またはXMLからバッファに)変換します。

MBSTRING

バッファをそのまま渡します。

注意: エンコーディングは、送受信されたメッセージのMetaDataのencoding要素によって決まります。

37.5.2 メッセージ・サービス・タイプの場合のバッファ変換

表37-3に、サービスのタイプがメッセージング・サービスの場合の、Tuxedoのバッファ・タイプに応じたTuxedo転送の動作を示します。サブタイプになしが指定されている場合、Tuxedoトランスポートはバッファを受信しません。

表37-3 メッセージング・サービスの場合のバッファ変換

Tuxedoバッファ・タイプ

バイナリ・メッセージング・タイプ

テキスト・メッセージング・タイプ

MFLメッセージング・タイプ

XMLメッセージング・タイプ

STRING

そのまま渡されます。

そのまま渡されます。

バッファが適切な形式であると仮定し、そのまま渡されます。そうでない場合、トランスポートによってエラーが返されます。

XML

CARRAY

そのまま渡されます。

未サポート

バッファが適切な形式であると仮定し、そのまま渡されます。そうでない場合、トランスポートによってエラーが返されます。

XML

FML/FML32

そのまま渡されます。

未サポート

未サポート

XML

XML

そのまま渡されます。

そのまま渡されます。

未サポート

XML

VIEW/VIEW32

そのまま渡されます。

未サポート

未サポート

XML

MBSTRING

そのまま渡されます。

そのまま渡されます。

バッファが適切な形式であると仮定し、そのまま渡されます。そうでない場合、トランスポートによってエラーが返されます。

XML

Tuxedoトランスポートはバッファ処理を、任意のXMLサービス・タイプのサービスと同様に行います。

37.6 Tuxedoトランスポートのトランザクション処理

Service BusとTuxedoを相互運用して、各製品に用意されているサービス(多くの場合、トランザクション処理を含む)を使用できます。Tuxedoトランスポートは、Service Busでのトランザクションを活用または開始します。このトランザクション・サポートの例外は、インバウンド・トランスポートがトランザクション対応のメッセージのあるTuxedoで、アウトバウンドがリクエストおよびレスポンスXA/JMSの場合です。この場合、Service Busは例外を検出し、結果はTPESYSTEMエラーになります。

Tuxedoトランスポートのトランザクション動作は、メッセージ・コンテキスト・レベルで使用できるサービスの品質(QoS)設定に基づきます。詳細は、「サービスの品質」を参照してください。

次の項では、Tuxedoトランスポートでのトランザクションの処理方法について説明します。

- 任意のXMLサービス・タイプの場合のバッファ変換

- アウトバウンドTuxedoサービスのトランザクション処理

37.6.1 インバウンドTuxedoサービスのトランザクション処理

トランザクション・コンテキストを受信すると、パイプラインに送信されるメッセージによって、QoSが「必ず1回」に設定されるか、そうでない場合は、QoSは「ベスト・エフォート」に設定されます。応答がクライアントに返される前にTransportExceptionが捕捉された場合、TPESYSTEM例外をスローしてリクエストが中断され、トランザクションは結果をロールバックします。

37.6.2 アウトバウンドTuxedoサービスのトランザクション処理

ビジネス・サービスを呼び出すスレッドにトランザクション・コンテキストがある場合、Tuxedoトランスポートは次のように動作します。

- QoSが「必ず1回」に設定されている場合、エンドポイントがトランザクションを中断するように構成されている場合を除いて、Tuxedoトランスポートは、自動的にトランザクション・コンテキストをリモート・ドメインに転送します。

- QoSが「ベスト・エフォート」に設定されている場合、Tuxedoトランスポートは、呼出しを行う前にトランザクションを中断し、呼出しが行われてから再開します。これは、TPNOTRANフラグを設定してATMI呼出しを行う場合と同じです。

ビジネス・サービスを呼び出すスレッドに、関連付けられているトランザクションがない場合、QoS設定に関係なく、Tuxedo呼出しは非トランザクションとして行われます。この場合、TPNOTRANフラグが設定されたtpcall()またはtpacall()に相当します。

37.7 Tuxedoトランスポート構成のリファレンス

この項では、プロキシ・サービスおよびビジネス・サービスでTuxedoトランスポートを使用する場合に構成できるプロパティについて説明します。

- Tuxedoトランスポートを使用するプロキシ・サービスの構成

- Tuxedoトランスポートを使用するビジネス・サービスの構成

37.7.1 Tuxedoトランスポートを使用するプロキシ・サービスの構成

プロキシ・サービス定義エディタの「トランスポートの詳細」ページでは、次の表に示す、トランスポートを構成するためのプロパティが提供されます。

表37-4 プロキシ・サービス用のTuxedoトランスポート・プロパティ

オプション

説明

フィールド表クラス

受信されるFML/FML32バッファを表す(1つまたは複数の)クラスの名前を入力します。これらは、フィールド名を要素名にマップするために、FML/FML32からXMLへの変換ルーチンで使用されます。完全修飾クラス名をスペースで区切ってリストします。

Viewクラス

受信されるVIEW/VIEW32バッファを表す(1つまたは複数の)クラスの名前を入力します。これらは、フィールド名を要素名にマップするために、VIEWからXMLまたはVIEW32からXMLへの変換ルーチンで使用されます。これは空白で区切られた完全修飾クラス名のリストです。

Tuxedoのバッファ・タイプX_C_TYPEとX_COMMONは、VIEW/VIEW32バッファと同様に処理されます。

受信リクエストにVIEWが含まれる場合、該当するVIEWクラスをService BusのCLASSPATHに指定する必要があります。

クラスJar

このエンドポイント・オペレーションに必要なFML/FML32またはVIEW/VIEW32クラスを持つJARファイルを含んだJARリソースを選択します。Oracle Service Busコンソール内で作業している場合、コンソール内でJARリソースを作成してから、そのリソースを選択する必要があります。詳細は、「JARファイルの追加方法」を参照してください。

ローカル・アクセス・ポイント

エクスポートに関連付けられたリストから、ローカル・アクセス・ポイントを選択します。このリストには、WebLogic Tuxedo Connector (WTC)で構成されたローカル・アクセス・ポイントが含まれます。関連するローカル・アクセス・ポイントがない場合、プロキシ・サービスは作成できません。

ローカル・アクセス・ポイントが存在しない場合、または、新しいローカル・アクセス・ポイントを作成する場合は、「新規」を選択します。対応する「ローカル・アクセス・ポイント名」と「ローカル・ネットワーク・アドレス」を隣のフィールドに入力します。エンドポイントの検証時に、各WTCサーバーのWTC構成にアクセス・ポイントが追加されます。WTCサーバーがない場合は、新しいサーバーが作成されます。

「新規」オプションを選択した後では、既存のアクセス・ポイント名を入力できます。この場合、既存の情報が新しいパラメータで更新されます。変更できるのは、ホスト名とポート番号に限られます。

リモート・アクセス・ポイント

新しく作成したローカル・アクセス・ポイントと関連付けるリモート・アクセス・ポイントを、リストから選択します。新しいアクセス・ポイントを作成するには、「新規」を選択します。対応する「アクセス・ポイント名」と「ネットワーク・アドレス」を隣のフィールドに入力します。このフィールドは、「ローカル・アクセス・ポイント」フィールドで「新規」を選択した場合にのみ表示されます。

「新規」オプションを選択した後では、既存のアクセス・ポイント名を入力できます。この場合、既存の情報が新しいパラメータで更新されます。変更できるのは、ホスト名とポート番号に限られます。

リモート・アクセス・ポイントは、インバウンド・リクエストに対するWTC接続の認証プリンシパルでもあります。オプションとして、デフォルトのセキュリティ・レルムで同じアクセス・ポイントIDを持つユーザーを作成して、インバウンド呼出しを許可することができます。これを行うには、「ユーザーを作成しますか。」リストから「はい」を選択します。セキュリティの問題を回避するために、パスワードは一時変数を使用してランダムに生成されます。

応答バッファ・タイプ

リモートTuxedoクライアントが受信するバッファのタイプを選択します。

このオプションは、「レスポンスが必要」フィールドが選択されている場合にのみ使用できます。

応答バッファ・サブタイプ

応答バッファに関連付けるバッファのサブタイプを入力します。

このオプションは、「レスポンスが必要」オプションが選択されていて、「レスポンス・バッファ・タイプ」の値がVIEWまたはVIEW32の場合にのみ使用できます。

レスポンスが必要

このサービスにレスポンスの送信が想定されている場合は、このチェックボックスを選択します。デフォルトで、このオプションは選択されています。

サービスのタイプが「メッセージ・サービス」で、レスポンス・メッセージのタイプが「なし」の場合は、このオプションの選択が解除され、使用できません。

リクエストのエンコーディング

Tuxedoトランスポートのリクエストのエンコーディングを設定する文字を指定します。

レスポンスのエンコーディング

Tuxedoトランスポートのレスポンスのエンコーディングを設定する文字を指定します。

変換スタイル

XMLドキュメントでのFML/FML32バッファの表現方法を指定します。次のいずれかを選択します。

- 「なし」: フィールドの順序を無視します。これはデフォルト選択です。

- 「順序付け」: すべてのフィールドを正しい順序で表示します。

- 順序付けとグループ別: フィールドが論理的にレコード構造になっている場合、発生順に並べ替えられ、レコードごとにグループ化されます。

37.7.2 Tuxedoトランスポートを使用するビジネス・サービスの構成

ビジネス・サービス定義エディタの「トランスポートの詳細」ページでは、次の表に示す、トランスポートを構成するためのプロパティが提供されます。

表37-5 ビジネス・サービス用のTuxedoトランスポート・プロパティ

プロパティ

説明

フィールド表クラス

受信されるFMLまたはFML32バッファを表すクラス名を入力します。これらは、フィールド名を要素名にマップするために、FMLまたはFML32からXMLへの変換ルーチンで使用されます。完全修飾クラス名をスペースで区切ってリストします。

Viewクラス

送受信されるVIEWまたはVIEW32バッファを表すクラス名を入力します。これらは、フィールド名を要素名にマップするために、VIEWからXMLまたはVIEW32からXMLへの変換ルーチンで使用されます。完全修飾クラス名をスペースで区切ってリストします。

クラスJar

このエンドポイント・オペレーションに必要なFML/FML32またはVIEW/VIEW32クラスを持つJARファイルを含むJARリソースを選択します。

Oracle Service Busコンソール内で作業している場合、コンソール内でJARリソースを作成してから、そのリソースを選択する必要があります。詳細は、「JARファイルの追加方法」を参照してください。

リモート・アクセス・ポイント

使用可能なオプションのリストから、リモート・アクセス・ポイントを選択します。このリストには、WTCで構成されたリモート・アクセス・ポイントが含まれます。関連するリモート・アクセス・ポイントがない場合、ビジネス・サービスは作成できません。

リモート・アクセス・ポイントがない場合、または新規ポイントを作成する場合は「新規」を選択します。対応する「アクセス・ポイント名」と「ネットワーク・アドレス」を隣のフィールドに入力します。エンドポイントの検証時に、各WTCサーバーのWTC構成にアクセス・ポイントが追加されます。WTCサーバーがない場合は、新しいサーバーが作成されます。

「新規」オプションを選択した後では、既存のアクセス・ポイント名を入力できます。この場合、既存の情報が新しいパラメータで更新されます。変更できるのは、ホスト名とポート番号に限られます。

複数のURIを指定した場合、URIごとに1つのリモート・アクセス・ポイントが存在し、そのURIが参照用に表示されます。複数のURIが存在している場合、各URIに異なるリモート・アクセス・ポイントが必要です。既存のWTCリソースに対応するURIがすでに指定されている場合、対応するリモート・アクセス・ポイントが表示されますが、編集することはできません。

ローカル・アクセス・ポイント

新しく作成したリモート・アクセス・ポイントと関連付けるローカル・アクセス・ポイントを選択します。新しいアクセス・ポイントを作成するには、「新規」を選択します。対応する「ローカル・アクセス・ポイント名」と「ローカル・ネットワーク・アドレス」を隣のフィールドに入力します。

このフィールドは、「リモート・アクセス・ポイント」フィールドで 「新規」を選択した場合のみ表示されます。

注意: アクセス・ポイントは複数のエンドポイントから使用されることがあるため、エンドポイントが削除されても、トランスポートによってアクセス・ポイントが削除されることはありません。アクセス・ポイントを削除するには、Oracle WebLogic Server管理コンソールを使用します。

リクエスト・バッファ・タイプ

リモートTuxedoサービスが受信するバッファの種類を選択します。

リクエスト・バッファ・サブタイプ

リクエスト・バッファに関連付けるバッファのサブタイプを入力します。このオプションが有効になるのは、上記の「リクエスト・バッファ・タイプ」の値がVIEWまたはVIEW32の場合です。

レスポンスが必要

双方向の呼出しを指定する場合に選択します。これを選択しない場合、基礎になるtpcallがTPNOREPLYフラグで呼び出され、nullレスポンスが非同期的に返されます。

トランザクションを中断

トランザクションがある場合、このチェックボックスを選択してトランザクションを中断します。この機能は、リモート・サービスがトランザクションに対応していない場合に役立ちます。

/QタイプのTuxedoリソースを呼び出す場合は、レスポンスの想定の有無に関わらず、「トランザクションを中断」オプションを使用します。一方向の呼出しから正常に戻ってきたことは、メッセージがキューに正しく置かれたことを意味します。

注意: 「トランザクションを中断」オプションが選択されていない場合、/Qモード・エンドポイントへのTuxedoトランスポートは、非同期のトランザクションを伴うトランスポートだと見なされます。これにより、デッドロックが回避されます。/Qモードでは、エンドポイントが返信を想定している場合、複数の管理対象サーバーにある複数のスレッドが同じ宛先に返信を行うことがあります。このため、返信が想定される場合は、一意の相関IDがリクエストとともに送信されます。デキュー操作では、この相関IDを持つメッセージを待機します。相関IDはJMSトランスポートの同様の状況で使用される場合と同等の方法で構成されます。

リクエストのエンコーディング

リクエストに使用する文字セットのエンコーディングを指定します。

レスポンスのエンコーディング

レスポンスに使用する文字セットのエンコーディングを指定します。

タイムアウト

トランスポート・ランタイムの返信の最長待ち時間(秒単位)を指定します。0以上の整数を指定する必要があります。指定されていない場合またはゼロ(デフォルト)に指定されている場合は、ローカルのTuxedoアクセス・ポイントが部ブロッキング・コールを許可する最大秒数であるBLOCKTIMEの時点で返信はタイムアウトします。実行時、タイムアウト値を超えている返信は無視され、TPETIME例外でエラー・メッセージが返されます。

このフィールドは、リクエスト/レスポンス・サービスにのみ使用可能であり、m/Qまたは一方向のエンドポイントには使用できません。アウトバウンド呼出しの一部がトランザクションである場合、タイムアウト値は無視されます。

注意: WTC BLOCKTIME値がタイムアウト値よりも短い場合、WTC BLOCKTIME値が優先されます。

変換スタイル

FMLまたはFML32バッファがXMLに変換される際に要素を順序付けまたはグループ化する方法として、次のいずれかを選択します。

- 「なし」: (デフォルト)フィールドの順序を無視します。

- 「順序付け」: すべてのフィールドを正しい順序で表示します。

- 順序付けとグループ別: フィールドが論理的にレコード構造になっている場合、発生順に並べ替えられ、レコードごとにグループ化されます。

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。Service Busはこのワーク・マネージャを使用して、一方向の呼出しの場合に、null返信を非同期的にポストします。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

38 WSトランスポートの使用

この章では、WSトランスポートの概要と、サービスでの使用および構成方法について説明します。WSトランスポートでは、Webサービス信頼できるメッセージング(Web Services Reliable Messaging: WSRM)をService Busで使用できます。

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

- WSトランスポートの概要

- サービスの認証と認可

- WS転送の使用

- WSトランスポート構成のリファレンス

38.1 WSトランスポートの概要

WSトランスポートは、SOAP 1.1およびSOAP 1.2に基づくWebサービスの信頼性のあるメッセージング(WSRM)ポリシーを持ったWSDLドキュメントから派生したサービスに関するインバウンド・リクエストとアウトバウンド・リクエストの両方を実装しています。ただし、WSRMポリシーはWSDLファイルの一部である場合と、サービスにアタッチされる場合とがあります。さらに、セキュリティ・ポリシーもWSDLファイルで宣言される場合と、WSDLベースのサービスに関連付けられる場合があります。Service BusでWSDLベースのサービスにWSRMポリシーを構成する場合は、サービスにWSトランスポートを選択する必要があります。Service Busでは、サービスの構成が保存されるときにWSRMポリシーがチェックされて、WSRMポリシーがサービスに関連付けられたWSDLファイルで宣言されていない場合、検証エラーが送出されます。

38.1.1 Webサービスの信頼性のあるメッセージング

Webサービスの信頼性のあるメッセージングは、WS信頼できるメッセージングまたは単にWSRMとも呼ばれます。この仕様では、ソフトウェアやシステム、ネットワークに障害が発生した場合でも、分散アプリケーション間で信頼性のあるメッセージ配信を可能にするプロトコルについて記述されています。WS-ReliableMessagingは、IBM、Oracle、Microsoft、およびTIBCO Systemsによって共同開発された仕様です。この仕様は、OASISによって開発された競合関係にある仕様のWS-Reliability (WSR)とは異なります。

Service Busは、2005年2月に提出された仕様をサポートしています。この仕様の詳細は、「Web Services Reliable Messagingプロトコル(WS-ReliableMessaging)」(http://schemas.xmlsoap.org/ws/2005/02/rm/)を参照してください。

38.1.2 WSトランスポートの機能

WSトランスポートの主要な機能を次に示します。

- 一方向およびリクエスト/レスポンスのメッセージ・パターン。詳細は、「メッセージング・パターン」を参照してください。

- WSトランスポートと他のトランスポート(JMS、SB、およびTuxedoトランスポート)間でXAトランザクションをサポートする「必ず1回(Exactly Once)」送信。

- 基本認証を使用するHTTPS、およびクライアント証明書認証(双方向SSL)を使用するがクライアント認証を使用しないHTTPS。詳細は、「サービスの認証と認可」を参照してください。

- リソースのインポート中のWSRMセキュリティ構成の保持。詳細は、「リソースのインポートとエクスポート」を参照してください。

- WSプロキシ・サービスに対するトランスポート・レベル・アクセス制御ポリシーの割当て。このポリシーを割り当てることができるのは管理者に限られます。詳細は、「トランスポート・レベルのアクセス・ポリシーの構成方法」を参照してください。

- 2004年8月に提出されたWS-Addressingの仕様。詳細は、「Web Services Addressing (WS-Addressing)」(http://www.w3.org/Submission/ws-addressing/)を参照してください。

- WS-I基本プロファイルへの準拠。詳細は、「Webサービスの相互運用性」を参照してください。

- Service BusのWSプロキシに対するサービスの品質(QoS)は、常に「必ず1回」に設定されます。詳細は、「サービスの品質」を参照してください。
QoSは<beapolicy:QOS>要素を使用して、RMポリシー・ファイルで設定できます。この要素にはQOSという属性が1つあり、次の値のいずれかを使用します。

- AtMostOnce

- AtLeastOnce

- ExactlyOnce

- InOrder

注意:

WSトランスポートのQoSは、Service BusのQoSとは異なります。

- プロキシ・サービスまたはビジネス・サービスのWSRMポリシーに関連付けられるのは、SOAP 1.1およびSOAP 1.2に基づくWSDLファイルに限られます。詳細は、「WSトランスポートを使用するプロキシ・サービスの構成」および「WSトランスポートを使用するビジネス・サービスの構成」を参照してください。

38.1.3 メッセージング・パターン

WSRMでは、一方向とリクエスト/レスポンスの両方のメッセージング・パターンがサポートされます。WSトランスポートでは、信頼性のあるレスポンスはサポートされていません。リクエストには常に信頼性がありますが、レスポンスには信頼性がありません。

ビジネス・サービスの場合、外部Webサービスへのリクエストの送信は非同期で行われます。呼出しの成功は、メッセージがRMレイヤーに無事に到達し、確実に配信されることを示します。しかし、呼出しに成功しても、メッセージがエンドポイントに送信され、Webサービスの呼出しに成功するという意味ではありません。

リクエスト/レスポンス・メッセージング・パターンの場合、リクエストに対するレスポンスを外部Webサービスから受信します。この場合、リクエストとレスポンスのパスには2つの異なるトランザクションがあり、2つの異なるスレッドで実行されます。レスポンス・パイプラインは、一方向メッセージングのメッセージ・パターンで均等に実行されます。一方向のパターンの場合、レスポンス・パイプラインの呼出しは、メッセージが確実にターゲットの宛先に到達し、Webサービスの呼出しが完了したことを意味します。

38.1.4 WSトランスポートのWS-Policy

WSトランスポートを使用するプロキシ・サービスまたはビジネス・サービスは、RMアサーションを使用するWS-Policyを持つ必要があります。このことは逆に、WSトランスポート以外のトランスポートを使用するサービスではRMアサーションを使用するWS-Policyを持てないことを示しています。WSトランスポートでは、RMアサーションを使用するWS-PolicyとWSSP v1.2トランスポート・レベル・セキュリティ・アサーションがサポートされます。

ただし、WSSP v1.2メッセージ・レベル・セキュリティ・アサーションと9.X Oracle独自のセキュリティ・アサーションはサポートされません。RMアサーションは、操作レベルや操作のリクエスト/レスポンス・レベルではなく、サービス・レベルでのみバインドされる必要があります。

注意:

WS-Policyで使用するRMアサーションは1つに限られます。

38.1.4.1 WS-Policyの構成

WS-Policyは、次の2つの方法のどちらかを使用して構成できます。

- WS-Policyの構成をサービスに関連付けられたWSDLファイルの一部として指定します。WSDLファイルで指定されるポリシーは、WSDLファイルに含まれているか、あるいはWSDLファイルで参照されています。

- サービスを構成するときにWS-Policyをサービスに割り当てます。

注意:

サービスにセキュリティ・ポリシーを関連付けるには、この2つの方法のどちらか1つのみを使用できます。Service Busサービスでポリシーを直接構成すると、WSDLファイルで定義されたポリシーは無視されます。

38.1.5 サイズの大きいメッセージ・コンテンツのストリーミング

WSトランスポートでは、基礎となるインフラストラクチャ(WLS JAX-RPCスタック)で完全に具体化されたペイロードを使用しているため、サイズの大きいメッセージのストリーミングのサポートがありません。ただし、プロキシ・サービスでサイズの大きいメッセージの処理を構成した場合は、WSトランスポートによってService Busのストリーミングの最適化が使用されて、メッセージはJavaオブジェクトに完全に具体化されます。サイズの大きいメッセージの処理でコンテンツをストリーミングする場合は、プロキシ・サービスの構成中に、メモリーまたはディスクにコンテンツのバッファリングを行うようにします。詳細は、「bodyコンテンツのストリーミング」を参照してください。

38.1.6 Webサービスの相互運用性

WSトランスポートでは、WS-I基本プロファイルによってWebサービスの相互運用性をサポートします。現在、Service Busプロキシ・サービスはWS-I基本プロファイルの制限に従っていません。しかし、このトランスポートを使用するように構成されたすべてのサービスは、WS-I基本プロファイルの仕様に厳密に従っています。WSプロキシ・サービスにはサービスの構成にWS-I準拠のチェックがなく、常にWS-I基本プロファイルに従います。WS-I基本プロファイルはSOAP 1.1にのみ適用されるため、このことはSOAP1.1 WSDLバインディングに対して有効です。

38.2 サービスの認証と認可

この項では、WSプロキシ・サービスとビジネス・サービスが認証および認可される方法について説明します。

- プロキシ・サービスの認証

- プロキシ・サービスの認可

- ビジネス・サービスの認証

38.2.1 プロキシ・サービスの認証

WSプロキシ・サービスでは基本認証とクライアント証明書(双方向SSL)認証の両方をサポートします。WS-Policyで基本認証が指定された場合は、WSプロキシ・サービスに対するすべてのHTTPリクエストには、RMプロトコル・メッセージも含めて、有効なユーザー名とパスワードが含まれている必要があります。

プロキシ・サービス認証のサポートは次のように行われます。

- プロキシ・サービスが参照するサービス・キー・プロバイダに割り当てられたSSL鍵ペアを使用したクライアント証明書のアウトバウンド認証。

- WSプロキシ・サービス(基本認証を使用する)による他の任意のアウトバウンド・トランスポート、またはアウトバウンドWSSユーザー名トークンに対するユーザー名/パスワードのIDの伝播。

- WSプロキシ・サービス(基本認証または双方向SSL認証)と他の任意のトランスポートとの間の資格証明のマッピング。

- WSプロキシ・サービスからRMクライアントへのHTTPまたはHTTPSによる非同期レスポンスの送信。プロキシ・サービスとビジネス・サービスで使用されるデフォルトのプロトコルはHTTPです。

- WSプロキシ・サービスから、RMクライアントによって指定されるAcksToまたはReplyToエンドポイント参照に接続するRMクライアントへの非同期レスポンス。RMクライアントはHTTP URLまたはHTTPS URLのどちらかを使用できます。RMクライアントがHTTPSを使用する場合、RMクライアントはSSLハンドシェイク中にクライアント証明書をリクエストできます。WSトランスポートでは、リクエスト時にサービス・キー・プロバイダのSSLのキー・ペアを使用します。

38.2.2 プロキシ・サービスの認可

管理者は、トランスポート・レベルのアクセス制御ポリシーをWSプロキシ・サービスに割り当てることができます。他のすべてのトランスポートと同様に、このポリシーは、インバウンド・トランスポート・プロバイダがリクエスト・メッセージをService Busバインディング・レイヤーに渡した後、リクエスト・パイプラインを呼び出す前に実施されます。詳細は、「トランスポート・レベルのアクセス・ポリシーの構成方法」を参照してください。

38.2.3 ビジネス・サービスの認証

WSビジネス・サービスでは基本認証とクライアント証明書認証をサポートします。アウトバウンド基本認証は、サービス・アカウントによってサポートされます。ユーザー名およびパスワードのIDの伝播と資格証明のマッピングがサービス・アカウントによって提供されます。ただし、静的アカウントも認証に使用されることがあります。サービス・アカウントは、静的、パススルーまたはマップになります。パススルー認証では、クライアント・リクエストからバックエンドRMサービスへユーザー名およびパスワードを渡すことが可能です。マップされたサービス・アカウントでは資格証明のマッピングが可能です。静的サービス・アカウントは、固定した資格証明が必要な場合に使用されます。

WSビジネス・サービスでは、SSLクライアント証明書認証(双方向SSL)もサポートされています。アウトバウンドの双方向SSLで使用されるキー・ペア(秘密鍵と証明書)は、WSビジネス・サービスではなく、プロキシ・サービスによって参照されるサービス・キー・プロバイダで構成されます。

1つのメッセージをWSビジネス・サービスにルーティングすると、Service Busサーバーとバックエンド・サービスからの複数のHTTP/Sリクエストが対象となることがあります。このようなメッセージはすべて、WSビジネス・サービスで構成される認証方法の影響を受けます。つまり、サービスが基本認証用に構成されている場合は、Service Busから送信されるすべてのメッセージに、ユーザー名およびパスワードが格納されたHTTP認可ヘッダーが含まれており、メッセージがクライアント証明書認証用に構成されている場合は、Service Busで鍵ペアを使用してすべてのメッセージの認証を行います。

38.3 WSトランスポートの使用

WSトランスポートは、分散ネットワークにおいて信頼性のあるメッセージ配信を行います。WSRM機能は、SOAP 1.1およびSOAP 1.2に基づくWSRMポリシーを持ったWSDLファイルでのみトランスポートとして使用できます。サービスがRMポリシーを持つSOAP 1.1または1.2 WSDLファイルに関連付けられていること、あるいはRMポリシーがサービスにアタッチされていることを確認してください。WS-PolicyはWSDLファイルで構成するか、またはサービスに割り当てることができます。詳細は、「WSポリシーの構成」を参照してください。

WSトランスポートを使用するようにプロキシ・サービスおよびビジネス・サービスの構成を始める前に、必要なWSDLファイルが、使用するService Busドメインで利用可能であることを確認します。詳細は、「Oracle Service BusコンソールへのWSDLドキュメントのインポート」、「WSトランスポートを使用するプロキシ・サービスの構成」および「WSトランスポートを使用するビジネス・サービスの構成」を参照してください。

サービスにエラー・キューを構成して、Service Busがエラーになったメッセージをこのキューに配信するようにすることもできます。これは分散キューにできます。このキューは自動的には作成されないので、サービスの構成を始める前に作成しておく必要があります。詳細は、「エラー・キューの構成」を参照してください。

38.3.1 Oracle Service BusコンソールへのWSDLドキュメントのインポート

Oracle Service BusコンソールでWSRMポリシーを持つWSDLファイルに基づいてサービスを作成するためには、WSDLファイルをインポートするかまたはエディタでWSDLリソースおよびファイルの内容を作成する必要があります。詳細は、「Oracle Service BusコンソールでのWSDLドキュメントの操作」および「リソースおよび構成のインポートとエクスポート」を参照してください。

38.3.2 WSポリシーの構成

WSトランスポートは、WSRMポリシーを持つSOAP WSDLファイルでのみ使用できます。WS-PolicyをWSDLファイルで構成するか、JDeveloperあるいはOracle Service BusコンソールでWS-Policyをサービスに割り当てることができます。詳細は、「WSトランスポートのWS-Policy」を参照してください。

RMポリシー・アサーションがサービスに関連付けられたWSDLファイルで指定されていない場合、セッションをアクティブ化すると検証メッセージが表示されます。この競合を解決するには、WSDLファイルを更新するかまたはサービスにポリシーを付加する必要があります。詳細は、「サービスへのWSポリシーの付加」および「WS-PolicyによるOracle Service Busプロキシ・サービスとビジネス・サービスの保護」を参照してください。

38.3.3 サービスへのWSポリシーの付加

JDeveloperまたはOracle Service Busコンソールのいずれかのサービス定義エディタで、プロキシ・サービスまたはビジネス・サービスにポリシーをアタッチできます。サービスにWS-Policyをアタッチすると、そのサービスに関連付けられたWSDLファイルで定義されるすべてのポリシーは無視されます。ポリシーの付加の詳細は、「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。

38.3.4 エラー・キューの構成

デフォルトでは、配信されなかったメッセージは指定された回数の再試行を行った後、破棄されます。これらのメッセージを保存するために、ビジネス・サービスのエラー・キューを構成できます。Service Busは、パイプラインで失敗したメッセージをこれらのキューに配信します。エラーにはJMSキューを構成する必要があります。Oracleでは、エラー・キューをリモート・キューではなく、ローカルで構成することをお薦めします。

ビジネス・サービスでは、レスポンスのタイムアウトが発生すると、レスポンス・パイプラインがエラーで呼び出されます。シーケンスの有効期限に達すると、メッセージはビジネス・サービス用に構成されたエラー・キューに置かれ、レスポンス・パイプラインがエラーで呼び出されます。ただし、レスポンスのタイムアウトがすでに発生していた場合は、メッセージはエラー・キューに置かれますが、レスポンス・パイプラインは呼び出されません。

注意:

一方向サービスおよびリクエスト/レスポンス・サービスではどちらも、エラーになったメッセージをエラー・キューに入れる処理は「そうするように最善を尽くす」に過ぎません。

38.3.5 HTTPプロキシ・サーバーを経由するWSトランスポートのルーティング

HTTPプロキシ・サーバーが構成されている場合、WSビジネス・サービスはHTTPプロキシ・サーバーを使用してアウトバウンド・メッセージを送信します。クライアント・アプリケーションでHTTPプロキシ・サーバーの詳細を指定する方法の詳細は、Oracle WebLogic Server JAX-RPC Webサービスの開発の「Webサービスの呼出し」にあるWebサービス呼出し時のプロキシ・サーバーの使用に関する項を参照してください。

38.3.6 WSトランスポートのエラー処理

アプリケーション・エラーを処理するようにWSトランスポートベースのビジネス・サービスを構成できます。これには、アプリケーション・エラーの発生時にビジネス・サービスのエンドポイントURIを再試行するかどうかを指定します。アプリケーション・エラーは、WSベースのビジネス・サービスでSOAPフォルトがレスポンスとして受信され、BEA-380001またはOSB-380001エラー・コードが生成されると発生します。

ビジネス・サービスに対する要求で応答またはシーケンスのタイム・アウトが発生した場合、Service Busサーバーは、ロード・バランシング・アルゴリズムに基づいてその次のURIにメッセージの送信を試行します。この動作は「アプリケーション・エラーの再試行」オプションに依存しません。

38.3.7 リソースのインポートとエクスポート

Service Busドメインにリソースが存在する場合、「セキュリティおよびポリシーの構成を保持」オプションを選択することで、リソースをService Busにインポートするときにセキュリティおよびポリシーの構成の詳細を保持できます。このオプションを選択すると、リソース内でセキュリティとポリシーについての構成が更新されている場合であっても、インポート時に既存のリソースの値が保持されます。

リソースのインポートの詳細は、「リソースおよび構成のインポートとエクスポート」を参照してください。

38.3.8 UDDIレジストリを使用したサービスのインポートとパブリッシュ

プロキシ・サービスがUDDIレジストリにパブリッシュされると、サービスはWSDLファイルを使用するWSビジネス・サービスに変換されます。認証の構成がある場合は、これもUDDIにエクスポートされます。

WSRMポリシーを使用するWSDLベースのビジネス・サービスがUDDIレジストリからService Busにインポートされる場合は、サービスは自動的にWSトランスポートを使用するように構成されたWSビジネス・サービスとしてインポートされます。詳細は、「WSトランスポートのWS-Policy」を参照してください。

詳細は、「UDDIレジストリの操作」を参照してください。

38.4 WSトランスポート構成のリファレンス

ここでは、WSトランスポートのエンドポイントURLの形式と構成オプションを説明します。

- WSトランスポートのエンドポイントURI

- WSトランスポートを使用するビジネス・サービスの構成

- WSトランスポートを使用するプロキシ・サービスの構成

38.4.1 WSトランスポートのエンドポイントURI

WSトランスポートを使用するプロキシ・サービスのエンドポイント構成は、HTTPプロキシ・サービスの構成と同様です。次の形式でURIを指定し、HTTPトランスポートまたはWSトランスポートのどちらかを使用するプロキシ・サービスに対して、コンテキスト・パスが一意であることを確認します。

/contextPath

WSトランスポートを使用するビジネス・サービスのエンドポイント構成は、HTTPの構成と同様です。次の形式のいずれかでURIを指定します。

http://host:port number/name
https://host:port number/name

38.4.2 WSトランスポートを使用するビジネス・サービスの構成

WSトランスポートを使用するビジネス・サービスは、RMアサーションを持つWS-Policyと関連付けられている必要があります。詳細は、「WSトランスポートのWS-Policy」を参照してください。ビジネス・サービスは、外部の信頼性のあるWebサービスを呼び出すクライアントとして動作します。ビジネス・サービスによってサービスにリクエストが送信され、Service Busによってデプロイされたアプリケーションでレスポンスを受信します。これによりレスポンス・パスが呼び出されます。

次の表に、WSベースのビジネス・サービスを構成するために使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

表38-1 ビジネス・サービスのWSトランスポート・プロパティ

プロパティ

説明

レスポンス・タイムアウト

タイム・アウトまで応答を待つ時間(秒)を入力します。このフィールドを指定しない場合、レスポンスのタイムアウトは発生しません。ビジネス・サービスは、RMポリシーで構成されたシーケンス・タイムアウトの期間待機します。リクエストの送信後、定義された間隔以内にレスポンスが返されない場合、サービスがタイムアウトしたというエラーでレスポンス・パイプラインが呼び出されます。

値ゼロ(0)を入力すると、タイムアウトは発生しません(サービスはタイムアウトしません)。

サービス・アカウント

このサービスにHTTP基本認証ポリシーがある場合に使用する資格証明を定義するサービス・アカウントを指定します。

詳細は、「サービス・アカウントの操作」を参照してください。

注意: これは基本認証を必要とするWS-PolicyがWSビジネス・サービスにある場合にのみ適用されます。

エラー・メッセージをキューに入れる

このチェック・ボックスを選択して、構成されたエラー・キューにエラー・メッセージを送信することを指定します。

エラー・キューURI

エラー・メッセージを格納するJMSキューのURIを次の形式で入力します。

jms://host:port/connFactoryJndiName/queueJndiName

このオプションは、「エラー・メッセージをキューに入れる」チェック・ボックスが選択されている場合のみ有効です。

注意: WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。

JMSエラー・キューのサービス・アカウント

JNDI参照およびエラー・キューへのエラー・メッセージ送信用に使用する資格証明を定義するサービス・アカウントを指定します。このオプションは、「エラー・メッセージをキューに入れる」チェック・ボックスが選択されている場合のみ有効です。

詳細は、Oracle Service Busによるサービスの開発のサービス・アカウントの操作方法に関する項を参照してください。

エラー・キューにSSLを使用

エラー・キューへの接続にSSLを使用する場合に選択します。

このオプションは、「エラー・メッセージをキューに入れる」チェック・ボックスが選択されている場合のみ有効です。

Send Error Message as Binary

このオプションを選択して、エラー・メッセージをsoapInvokeStateオブジェクトではなくバイナリ・メッセージとして送信します。

WSトランスポートを使用してビジネス・サービスを構成する方法の詳細は、Service Busのオンライン・ヘルプを参照してください。

38.4.3 WSトランスポートを使用するプロキシ・サービスの構成

WSトランスポートを使用するプロキシ・サービスは、RMアサーションを持つWS-Policyと関連付けられている必要があります。詳細は、「WSトランスポートのWS-Policy」を参照してください。

プロキシ・サービスでは、クライアントからリクエストを受信し、WSRMに関連する処理を行った後で、これをパイプラインに渡します。プロキシ・サービスでは、レスポンス・パイプラインからレスポンスを受信した後、これをクライアントに送信することもできます。WSトランスポートを使用するプロキシ・サービスは他の任意のプロキシ・サービスから呼び出すことが可能で、外部クライアントから呼び出されたときと同じ動作を行います。HTTPプロキシ・サーバーが構成されている場合、WSプロキシ・サービスはHTTPプロキシ・サーバーを使用して非同期メッセージを送信します。

SOAP 1.2バインディングのWSDLに基づくプロキシ・サービスではSOAP 1.2メッセージのみをサポートしており、SOAP 1.1メッセージによるバージョンの不一致エラーが発生すると、エラーがスローされます。同様に、SOAP 1.1バインディングのWSDLに基づくプロキシ・サービスではSOAP 1.1メッセージのみをサポートしており、SOAP 1.2メッセージによるバージョンの不一致エラーが発生すると、エラーがスローされます。

次の表に、WSベースのプロキシ・サービスを構成するために使用するプロパティを示します。詳細は、「プロキシ・サービスの作成と構成」を参照してください。

表38-2 プロキシ・サービスのWSトランスポート・プロパティ

プロパティ

説明

ディスパッチ・ポリシー

このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。

ワーク・マネージャの詳細は、次の説明を参照してください。

- Service Busでのワーク・マネージャの使用

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項

再試行回数

WSRMレイヤーがService Busメッセージ・フローへのメッセージ配信を試行する回数を指定します。デフォルトは3です。

プロキシのリクエスト・フローで未処理の例外が発生した場合、着信WSトランスポート・メッセージはこの値で指定される回数までメッセージ・フローに再配信されます。これはWSトランスポート・メッセージを確実に処理するために重要です。

注意: メッセージの配信が失敗すると、現在のトランザクションはロール・バックされますが、メッセージはキューから削除されません。サーバーはメッセージの配信に成功するまで、または再試行回数の制限に到達するまでメッセージの送信を試行します。再試行回数の制限に到達すると、メッセージはキューから削除されるか、またはエラー・キューに移されます。エラー・キューは分散キューにすることができ、Oracle WebLogic Server管理コンソールで作成することができます。詳細は、「エラー・キューの構成」を参照してください。

再試行の遅延

サーバーがメッセージ配信を再試行する前に待機する時間(秒)を指定します。デフォルトは5秒です。

WSトランスポートを使用してプロキシ・サービスを構成する方法の詳細は、Service Busのオンライン・ヘルプを参照してください。

第VI部 カスタム・トランスポート・プロバイダの作成

ここでは、Service Bus Transport SDKについて説明します。このSDKは、Service Busで新しいカスタム・トランスポート・プロバイダを設計し、作成してデプロイすることを目的とする、経験豊かなJava開発者を対象としています。 トランスポートSDKのドキュメントでは、Webサービス・テクノロジ、Service Bus、Service Busで使用予定のトランスポート・プロトコル、そしてWebLogic Serverに関する深い知識があることを前提としています。

この部は、次の章で構成されています。

- カスタム・トランスポート・プロバイダについて

- カスタム・トランスポート・プロバイダの開発

- JDeveloper用のカスタム・トランスポート・プロバイダの開発

- カスタム・トランスポート・プロバイダのパッケージ化とデプロイ

- サンプル・ソケット・トランスポート・プロバイダの作成

カスタム・トランスポート・プロバイダのAPIおよび処理の詳細は、次の付録を参照してください。

- トランスポートSDKのインタフェースおよびクラス

- トランスポートSDK UMLシーケンス・ダイアグラム

39 カスタム・トランスポート・プロバイダについて

この章では、Service Busサービスで使用するカスタム・トランスポート・プロバイダを開発する際の概念、機能および設計上の考慮事項について説明します。開発作業を綿密に計画すると、カスタム・トランスポート・プロバイダの開発に要する時間と労力を大幅に削減できます。

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

- トランスポート・プロバイダの概要

- トランスポートSDKの概要

- カスタム・トランスポート・プロバイダの開発の必要性

- トランスポート・プロバイダのコンポーネント

- トランザクション・モデル

- トランスポートSDKセキュリティ・モデル

- トランスポートSDKおよびスレッド・モデル

- メッセージ・コンテンツの設計

39.1 トランスポート・プロバイダの概要

トランスポート・プロバイダは、トランスポート・ソフトウェア開発キット(SDK)のインタフェースを実装し、Service Busとメッセージを送受信するメカニズムとの橋渡しをします。このようなメカニズムには、HTTPなどの特定の転送プロトコルのみでなく、ファイルや電子メール・メッセージなど、他のエンティティが含まれる場合もあります。トランスポート・プロバイダは、トランスポート・エンドポイント(メッセージの送信元または送信先となるリソース)のライフ・サイクルおよび実行時の動作を管理します。

クライアントは、特定の転送プロトコルを使用してService Busにメッセージを送信します。トランスポート・プロバイダは、インバウンド・メッセージを処理します。サービス・クライアント・エンドポイントとの通信を処理し、Service Busへのメッセージのエントリ・ポイントとして機能します。バインディング・レイヤーは、メッセージの圧縮と解凍、メッセージのセキュリティ処理、パイプラインへのメッセージの引渡しを行います。Service Busを介したメッセージの基本的な流れについては、図1-3を参照してください。

ヒント:

Service Busのメッセージ・ブローカリングおよびトランスポート・レイヤーの役割の詳細は、「Oracle Service Busについて」を参照してください。Service Busを介したメッセージ・フローについてのより詳細なシーケンス・ダイアグラムは、「トランスポートSDKのUMLシーケンス・ダイアグラム」を参照してください。

デフォルトでは、Service Busには、HTTP、JMS、ファイル、FTPなど、一般的に使用されている複数の転送プロトコルをサポートするトランスポート・プロバイダが用意されています。これらのネイティブなプロバイダを使用して、前述の一般的な転送プロトコルを必要とするプロキシ・サービスおよびビジネス・サービスを構成できます。

ヒント:

ネイティブのトランスポート・プロバイダの使用および構成の詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください。

39.2 トランスポートSDKの概要

Service Busのメッセージ処理は、メッセージの送受信方法とは関係なく行われます。トランスポートSDKは、Service Busと、Service Busで送受信されるデータ・フローを扱うコンポーネントの間に抽象化レイヤーを提供します。この抽象化レイヤーがあることで、一意の転送プロトコルを扱うための新しいトランスポート・プロバイダを設計および開発できます。

SDKは、Service Busの他の部分から次を抽象化します。

- 特定のトランスポート・バインディングの処理。

- サービス・エンドポイントのトランスポート・バインディングへのデプロイ。エンドポイントではメッセージの送信も受信も行うことができます。

- モニター情報の収集。

- エンドポイントの管理(中断と再開操作の実行および接続プロパティの設定など)。

- サービス・レベル・アグリーメント(SLA)動作の適用(接続のタイム・アウトなど)。

39.2.1 トランスポートSDKの機能

この項では、トランスポートSDKの主要な機能について説明します。

- インバウンド・メッセージおよびアウトバウンド・メッセージの処理

- トランスポート関連のアーティファクトのデプロイ

- メッセージの非同期的な処理

39.2.1.1 インバウンド・メッセージおよびアウトバウンド・メッセージの処理

トランスポートSDKを使用して開発されたトランスポート・プロバイダは、次のようにインバウンド・メッセージおよびアウトバウンド・メッセージを処理します。

- 通常、インバウンド・メッセージは、HTTPクライアントなどの外部ソースからService Busに送信されます。ペイロードおよびトランスポート・レベル・ヘッダーがある場合、トランスポートSDKは、それらを汎用的なデータ構造にパッケージ化します。その後、トランスポートSDKは、汎用フォーマットでService Busパイプラインにメッセージを渡します。

- アウトバウンド・メッセージは、Service Busのビジネス・サービスから発信され、WebサービスまたはJMSキューなどの外部で管理されているエンドポイントに送信されます。トランスポートSDKは、Service Busパイプラインから汎用的なデータ構造を受け取り、対応するトランスポート固有のヘッダーおよびペイロードに変換し、外部システムに送信します。

トランスポートSDKは、アウトバウンド・メッセージおよびインバウンド・メッセージを個別に処理します。インバウンド・メッセージを1つの転送プロトコルにバインドし、アウトバウンド・エンドポイントで異なる転送プロトコルにバインドすることもできます。

39.2.1.2 トランスポート関連のアーティファクトのデプロイ

一部のトランスポートでは、アーティファクトをOracle WebLogic Serverにデプロイする必要があります。たとえば、JMSプロキシ・サービスは、メッセージ駆動型Beanとして実装されます。このアーティファクト、EARファイルは、新しいJMSプロキシ・サービスを登録する際にデプロイする必要があります。同様に、EJBトランスポート・プロバイダではEARファイルを使用しますが、これは新しいEJBビジネス・サービスを登録する際にデプロイする必要があります。サービス登録の一環としてキューおよびトピックを作成することがあるJMSトランスポートなどのように、その他のタイプのアーティファクトのデプロイが必要になる場合があります。SDKにより、これらのアーティファクトをサポートし、Oracle WebLogic Serverのデプロイメント・サイクルに参加できます。これらのアーティファクト・ファイルのいずれかのデプロイメントが失敗した場合、Service Busのセッションに通知され、デプロイメントはキャンセルされます。SDKのこの機能により、サービスを最小単位で作成できます。一部が失敗が発生した場合、セッションは以前の状態に戻ります。

注意:

Oracle WebLogic Serverのデプロイメント・サイクルに参加するには、トランスポート・プロバイダがTransportWLSArtifactDeployerインタフェースを実装している必要があります。この方法の第一の利点は、最小単位でOracle WebLogic Serverをデプロイできる点であり、必要に応じてロールバックすることもできます。このインタフェースの詳細は、「汎用インタフェースのサマリー」および「TransportWLSArtifactDeployerの実装が適している場合」を参照してください。

39.2.1.3 メッセージの非同期的な処理

メッセージを処理する際、サーバーで動作するスレッド数には制限があるため、非同期的に行うことが重要です。この機能により、多数のメッセージを処理できるようにService Busを拡張できます。リクエストが処理されると、スレッドは解放されます。ビジネス・サービスが応答を受信すると(または、一方向の場合は要求を処理し終えると)、コールバックによってService Busに非同期的に通知します。

詳細は、「同期トランザクションのサポート」および「トランスポートSDKおよびスレッド・モデル」を参照してください。

39.2.2 トランスポート・プロバイダのモード

トランスポートSDKを使用して、インバウンド・プロパティのモードおよびアウトバウンド・プロパティのモードを実装できます。これらの接続モードおよびエンドポイント・モードは、トランスポート・プロバイダのXMLスキーマ定義(XSD)ファイルで指定します。このファイルの詳細は、「ステップ3. トランスポート固有のアーティファクトのXMLスキーマ・ファイルの作成」を参照してください。このスキーマは、Service Busパイプラインでフィルタ処理およびルーティングを行う際に使用できます。

39.2.3 関連機能

この項では、トランスポート・マネージャによって提供される関連機能について示します。トランスポート・マネージャは、様々なトランスポート・プロバイダの管理、エンドポイントの登録、制御、インバウンド・メッセージとアウトバウンド・メッセージの処理、およびその他の機能を一元化するための主要ポイントとなります。これらの機能は、トランスポート・プロバイダによる特定のサポートを必要としません。

- ロード・バランシング

- モニターおよびメトリック

39.2.3.1 ロード・バランシング

トランスポートSDKは、アウトバウンド・メッセージのロード・バランシングおよびフェイルオーバーをサポートします。次のロード・バランシング・オプションがサポートされています。

- なし: アウトバウンド・リクエストごとに、トランスポート・プロバイダが、URIが記載されているリストを巡回し、送信が成功するまで、各URIにメッセージの送信を試みます。

- ラウンド・ロビン: 「なし」と似ていますが、トランスポート・プロバイダは最後に試行されたURIを追跡します。メッセージが送信されるたびに、プロバイダはリストの最後の位置から開始します。

- ランダム: トランスポート・プロバイダは、URIが記載されているリストからランダムに試行します。

- ランダムな重みベース: 各URIは、任意の重みに関連付けられます。アルゴリズムを使用して、この重みに基づいてURIを選択します。

39.2.3.2 モニターおよびメトリック

トランスポート・マネージャが、response-time、message-count、error-count、failover-count、throttling-time、cache-hit-countなどのメトリックのモニターを処理します。

39.3 カスタム・トランスポート・プロバイダの開発の必要性

この項では、カスタム・トランスポート・プロバイダの記述が必要となる基本的な使用例について説明します。別の方法を選択した方が適切な場合もあります。

- トランスポートSDKの使用が適している場合

- 別の方法を選択した方が良い場合

39.3.1 トランスポートSDKの使用が適している場合

トランスポートSDKの主要な使用例の1つは、既に内部アプリケーション間の通信に使用している特別なトランスポートをサポートすることです。このようなトランスポートでは、セット・アップされたハンドシェイク、ヘッダー・フィールド、メタデータ、またはトランスポート・レベルのセキュリティに独自の概念が用いられている場合があります。トランスポートSDKを使用して、個々のエンドポイント(インバウンドおよびアウトバウンドのいずれかまたは両方)の構成を可能にするService Busのトランスポートの実装を作成できます。カスタム・トランスポートを実装することで、特別なトランスポートのメタデータおよびヘッダー・フィールドをプロキシ・サービス・パイプラインで使用できるコンテキスト変数にマッピングできます。

信頼性、セキュリティ、パフォーマンス、管理、ユーザー・インタフェースおよびUDDIレジストリの使用のために、トランスポート・プロバイダをService Busのあらゆる側面にシームレスに統合する必要がある場合は、トランスポートSDKを使用してください。トランスポートSDKを使用してカスタム・トランスポートを開発した方が好ましい場合の例を次に示します。

- カスタム・インタフェースを必要とし、組織の既存のアプリケーションをサポートする、独自開発のトランスポートを使用している場合。

- CORBAアプリケーションとの通信にCORBAまたはIIOPプロトコルを使用している場合。

- IMSおよびMainframeなど、その他のレガシー・システムを使用している場合。

- 既存のトランスポートでバリエーションを使用する場合。

- LLP、AS3、およびACCORDなどの業界固有のトランスポートを使用している場合。

また、トランスポートSDKを使用して、Service Busで提供される既存のトランスポートの1つで特別なプロトコルをサポートできます。この例には、次のサポートが含まれます。

- HTTPを介した、解析済またはバイナリのXMLで構成されたメッセージ。

- HTTPを介したWS-RMまたは新しいWebサービス標準。

- JMSを介したリクエスト/レスポンス・メッセージ。ただし、Service BusのJMSトランスポートでサポートされている2つのパターンのいずれとも異なるレスポンス・パターンを持つもの(たとえば、メッセージ・コンテキストで定義されているレスポンス・キューなど)。

39.3.2 別の方法を選択した方が良い場合

トランスポートSDKを使用して新しいService Busトランスポート・プロバイダを作成する場合、多大な労力が必要となることがあります。トランスポートSDKは、カスタム・トランスポートが、Service Busにネイティブに付属するトランスポートの利便性と機能をすべて活用できるようにするために、多彩な機能をすべて備えた環境を提供します。ただし、このような多彩な機能を持ったカスタム・トランスポートは複雑になります。場合によっては、より簡単な別の方法を検討することをお薦めします。

既存のプロトコルを介して送受信される、異なるフォーマットのメッセージをサポートするためだけに拡張機能が必要な場合は、既存のトランスポートおよびJavaコールアウトを使用してメッセージを変換できる場合があります。たとえば、標準のJMSプロトコルを介して送信される(ASN.1またはシリアライズされたJavaオブジェクトなどの)特別なバイナリ・フォーマットを使用しているとします。この場合、サービスのタイプがバイナリの入出力メッセージを使用するメッセージング・サービスである、標準のJMSトランスポートを使用したサービスを定義することも検討できます。次に、パイプラインでメッセージ・コンテンツが必要な場合は、Javaコールアウト・アクションを使用してメッセージをXMLに変換したりXMLから変換したりできます。Javaコールアウトの使用の詳細は、「JavaコールアウトおよびPOJOの使用方法」を参照してください。

トランスポートSDKを使用してカスタム・トランスポート・プロバイダを開発することが最適とは言えないその他の例を次に示します。

- 既存のOracleソリューション(Oracle WebLogic Server、Oracle WebLogic Integration、Oracle Data Service Integrator、Oracle Business Process Management、Oracle Tuxedo、Oracle WebLogic Portalなど)をService Busと組み合せることにより、トランスポートの要件を満たす場合。

- サービス有効化ツールを使用することによって、SOA方式を実装するためのより簡略な標準ベースのメカニズムが提供される場合。

- (Service Busで動作確認されている)別の接続ソリューション(iWayアダプタ、Cyclone B2Bなど)でも要件に対応できる場合。

- ある種の簡単なJava機能を抽象化する手段として、EJBを代用できる場合。

39.4 トランスポート・プロバイダのコンポーネント

通常、カスタム・トランスポート・プロバイダは設計時部分と実行時部分から構成されています。設計時部分では、トランスポート・プロバイダへのエンドポイントの登録を行います。この構成動作は、UIインタフェースの実装によって実行されます。実行時部分では、メッセージの送受信のメカニズムを実装します。

新しいカスタム・トランスポート・プロバイダを開発する場合は、SDKによって提供される多数のインタフェースを実装する必要があります。この項では、SDKの設計時部分および実行時部分の構成をモデル化したUMLダイアグラムを示します。

ヒント:

Service Busでは、TransportProviderインタフェースの実装は、トランスポート・プロトコル固有の構成プロパティおよび実行時プロパティの集中的な管理ポイントとなります。サポートされているプロトコルごとに、TransportProviderオブジェクトの単一のインスタンスが存在します。たとえば、HTTPトランスポート・プロバイダ、JMSトランスポート・プロバイダ、およびその他のトランスポート・プロバイダに、それぞれ単一のインスタンスが存在します。

必要なインタフェースのリストは、「カスタム・トランスポート・プロバイダの開発」を参照してください。トランスポートSDKによって提供されるインタフェースおよびクラスの概要については、「トランスポートSDKのインタフェースおよびクラス」を参照してください。詳細は、「Oracle Service Bus Java APIリファレンス」を参照してください。

39.4.1 設計時のコンポーネント

カスタム・トランスポート・プロバイダの設計時部分はユーザー・インタフェースの構成で成り立っています。この構成は、新しいビジネス・サービスまたはプロキシ・サービスが登録される際に、Oracle Service BusコンソールまたはIDEによって呼び出されます。図39-1に、トランスポート・プロバイダの設計時部分の構造を説明したUMLダイアグラムを示します。ダイアグラムでは次のインタフェースについて説明しています。

- TransportManager: 転送プロバイダはこのインタフェースを介して転送マネージャと通信します。実装は公開されていません。

- TransportProvider: サード・パーティはこのインタフェースを実装する必要があります。TransportProviderは、TransportEndpointオブジェクトを追跡し、また、エンドポイントのライフ・サイクルも管理します。たとえば、トランスポート・エンドポイントは中断できますが、これはTransportProviderインタフェースを介して管理されます。

- TransportUIBinding: このインタフェースは、Oracle Service Busコンソールがトランスポート固有のページを表示する際に役立ちます。

図39-1 設計時のUMLダイアグラム

注意:

各トランスポート・エンドポイントの構成は、任意のトランスポート・プロバイダのすべてのエンドポイントに対して汎用なプロパティ(URIなど)と、そのプロバイダのエンドポイントだけに固有のプロパティとで構成されます。図39-2は、共有のエンドポイント構成プロパティと転送プロバイダ固有の構成プロパティの関係を示しています。詳細は、「トランスポート・エンドポイントのプロパティの概要」を参照してください。

図39-2 EndPointConfigurationのプロパティ

39.4.2 実行時のコンポーネント

カスタム・トランスポート・プロバイダの実行時部分は、メッセージを受信し、これをService Busランタイムに配信します。また、Service Busランタイムから外部サービスにアウトバウンド・メッセージを配信します。

実行時フレームワークでは、トランスポート・プロバイダは、トランスポート・マネージャを呼び出してインバウンド・メッセージを受信したことを認識します。トランスポート・メッセージ・コンテキストにはインバウンド・メッセージのヘッダーおよび本文が含まれています。アウトバウンド・メッセージの場合、TransportSendListenerおよびTransportSenderがあります。トランスポート・プロバイダは、メッセージからヘッダーおよび本文を取得します。

図39-1に、トランスポート・プロバイダの実行時部分の構造を説明したUMLダイアグラムを示します。

図39-3 実行時のUMLダイアグラム

39.5 トランザクション・モデル

トランスポートSDKを使用して新しいトランスポート・プロバイダを開発する前に、メッセージ・エンドポイントのトランザクション・モデルを検討することが重要です。この項では、Service Busで使用されるトランザクション・モデルおよびそのモデルがトランスポートSDKにどのように関係するかを説明します。

- トランスポート・エンドポイントのプロパティの概要

- 同期トランザクションのサポート

39.5.1 トランスポート・エンドポイントのプロパティの概要

トランスポート・エンドポイントは、JMSプロキシ・サービスなどのService Busリソースであり、メッセージの送信元または送信先となります。Service Busでは、トランスポート・エンドポイントはプロトコル固有のトランスポート・プロバイダによって管理されます。トランスポート・プロバイダは、トランスポート・エンドポイントのライフ・サイクルおよび実行時動作を管理するプラグイン・オブジェクトです。

Service Busのトランザクション・モデルを理解するには、サービス・トランスポート・エンドポイントのプロパティを確認しておくと役に立ちます。

39.5.1.1 トランザクション対応のエンドポイントとトランザクション非対応のエンドポイント

エンドポイントはトランザクション対応の場合と非対応の場合があります。トランザクション対応のエンドポイントは、メッセージを処理する際に、グローバル・トランザクションのコンテキスト内で開始または追加できます。次の例では、トランザクションのプロパティがエンドポイントによってどのように異なるかを示します。

- XA接続ファクトリを使用するJMSプロキシ・サービスはトランザクション対応のエンドポイントです。メッセージを受信すると、コンテナは、トランザクションのコンテキスト内でメッセージが処理されるように、トランザクションが開始されたことを確認します。

- Tuxedoプロキシ・サービスは、トランザクション対応でない場合があります。Tuxedoプロキシ・サービスは、メッセージを受信する前にTuxedoクライアント・アプリケーションによってトランザクションが開始された場合にのみトランザクション対応になります。

- HTTPクライアントによって呼び出されるHTTPプロキシ・サービスには通常はトランザクションが関連付けられませんが、トランザクションを開始して、そのトランザクションのコンテキストでメッセージ・フローを実行するというオプションをHTTPプロキシ構成で設定できます。

39.5.1.2 サポートされているメッセージ・パターン

任意のエンドポイントで、次のメッセージ・パターンのいずれかを使用できます。

- 一方向: レスポンスを受け取りません。一方向のエンドポイントの例としては、レスポンスを受け取らないJMSプロキシ・サービスがあります。

- 同期: リクエストまたはレスポンスを意味します。この場合、レスポンス・メッセージとリクエスト・メッセージは暗黙的にペアになります。これは、リクエストが出された時点からレスポンスを受け取るまでの間にトランスポート・チャネルで他のトラフィックが発生し得ないためです。ほとんどの場合、同期メッセージは、アウトバウンド・リクエストの呼出しのブロックを意味します。EJBエンドポイントは同期です。HTTPエンドポイントも同期です(レスポンスを受信するまで新しいリクエストは送信できません)。

- 非同期: リクエストおよびレスポンスを意味します。レスポンスは、JMSトランスポートおよびJMSCorrelationIDメッセージ・プロパティによる相関関係などの、トランスポート固有のメカニズムによって要求と関連付けられます。たとえば、リクエストおよびレスポンスを持つJMSビジネス・サービス・エンドポイントは非同期です。

39.5.2 同期トランザクションのサポート

すべてのService Busプロキシ・サービスはトランザクション伝播をサポートします。すなわち、トランザクションが存在していない場合に開始できます。また、アウトバウンド・ビジネス・サービスが非同期の場合でも、オプションとして、レスポンスがそのトランザクションのコンテキストで発生するように保証できます。つまり、非同期パターンを実質的に同期パターンに変換します。アウトバウンド・ビジネス・サービスでは、既存トランザクションの中断など、その他のトランザクション・サポートも提供されます。

同期トランザクション対応トランスポートでは、次の例がサポートされます。

- 使用例1 (応答パイプラインの処理)

- 使用例2 (サービス・コールアウトの処理)

- 使用例3 (トランザクションの中断)

- 使用例4 (複数のURI)

39.5.2.1 使用例1 (レスポンス・パイプラインの処理)

レスポンス・パイプラインの処理が受信トランザクションに含まれるのは、インバウンド・トランスポートが同期トランザクションをサポートする場合、またはトランザクションをレスポンスに伝播するようにプロキシ・サービスを構成する場合です。Service Busは、インバウンド・トランスポートが任意のアウトバウンド・トランスポートとペアになっている場合にこの使用例をサポートします。ただし、次のパラグラフで説明するケースは例外です。

インバウンド・トランスポートが同期トランザクションでアウトバウンド・トランスポートが非同期トランザクションの場合、デッドロック状況が発生します。デッドロックが発生する原因は、トランザクションがコミットされるまではアウトバウンド・リクエストがビジネス・サービスで受信できないにもかかわらず、トランザクションが外部で開始され、Service Busがレスポンスを受け取って制御が戻るまでコミットされないためです。トランスポート・マネージャはこの状況を認識し、ランタイム・エラーをスローしてデッドロックを回避します。たとえば、Tuxedoプロキシ・サービスなどの同期トランザクションのインバウンド・エンドポイントを使用していて、JMSビジネス・サービスなどのようにアウトバウンド・エンドポイントが非同期トランザクションである場合、レスポンスを受信するまでアウトバウンド・リクエストはトランザクションをコミットしません。外部エンティティがリクエストを受け取り、処理するまでは、レスポンスを受信できません。

また、この場合、レスポンス・パイプラインで実行されるパブリッシュ・アクションは、トランザクションの一部として行われます。これはリクエスト・パイプラインで実行されるパブリッシュ・アクションがトランザクションの一部として行われるのと同様です。

注意:

複数のアクションが(リクエスト・パイプラインまたはレスポンス・パイプラインの)トランザクションに参加できます。これには、パブリッシュ・アクション、サービス・コールアウト・アクション、およびレポート・アクションが含まれます。

たとえば、インバウンドTuxedoトランスポートが同期トランザクションの場合、リクエスト・パイプラインおよびレスポンス・パイプラインが完了した場合のみコミットできます。この場合、トランスポート・マネージャは、トランザクション・コンテキストをインバウンド・スレッドからアウトバウンド・スレッドに転送します。レスポンス・スレッドが終了すると、トランザクション・コントロールおよび結果が呼出しクライアントに返されます。

39.5.2.2 使用例2 (サービス・コールアウトの処理)

サービス・コールアウト・パイプライン・アクションを使用すると、パイプラインから別のサービスへのコールアウトを行うことができます。同期トランザクション対応のトランスポートに対しサービス・コールアウト・アクションが実行された場合、「必ず1回」および「ベスト・エフォート」のサービス品質がサポートされます。「必ず1回」では、アウトバウンド・メッセージの送信が開始されるまでは終了エラーが発生しないことを前提として、メッセージがインバウンドからアウトバウンドに1回だけ配信されます「ベスト・エフォート」では、それぞれの送信で独自のトランザクション・コンテキストが定義されます(トランザクション対応のトランスポート方式の場合)。「ベスト・エフォート」が指定されている場合、メッセージングの機能に信頼性はなく、重複するメッセージは除去されませんが、パフォーマンスが最適化されます。詳細は、「TransportOptionsの操作」を参照してください。

同期トランザクション対応のトランスポートへのコールアウトは必要に応じて既存のトランザクションの一部になります。たとえば、グローバル・トランザクション中にリクエスト・パイプラインを実行しいても、サービス・コールアウトはトランザクションへの参加を許可されます。たとえば、EJBサービスへのコールアウトがある場合、必要に応じてサービス品質の値を「必ず1回」に設定することで、サービスがそのトランザクションに参加できます。

サービス・コールアウトの詳細は、「コンソールでのサービス・コールアウト・アクションの追加」を参照してください。

39.5.2.3 使用例3 (トランザクションの中断)

次の条件に当てはまる場合、トランスポート・プロバイダを呼び出してアウトバウンド・リクエストを送信する前に、トランスポート・フレームワークがトランザクションを中断します。

- アウトバウンド・サービス・エンドポイントがトランザクション対応です。

- 進行中のグローバルXAトランザクションがあります。

- サービス品質が「ベスト・エフォート」に設定されている場合。

「送信」操作が完了すると、中断されていたトランザクションが再開されます。

39.5.2.4 使用例4 (複数のURI)

任意のアウトバウンド・サービス・エンドポイントに、関連付けられているURIが複数あり、トランザクション対応である場合、フェイルオーバーが発生する場合は、トランザクションの間にのみ発生し、ロールバックのマークは付けられていません。たとえば、URIが呼び出され、サービスがエラーを返した場合、フェイルオーバーは正常にトリガーされます。この場合、トランスポート・フレームワークが、トランザクションにロールバックのマークが付けられていることを検出するため、フレームワークは、別のURIに対しフェイルオーバーを実行しません。

39.6 トランスポートSDKセキュリティ・モデル

トランスポートSDKにより、ユーザーおよびサード・パーティは、Service Busに新しいトランスポートをプラグインできます。Service Busのセキュリティ・モデル内では、トランスポート・プロバイダは信頼性のあるコードと見なされます。セキュリティ・ホールによる潜在的なセキュリティ上の脅威を避けるため、トランスポート・プロバイダの実装は慎重に設計することが重要です。このドキュメントには、安全なトランスポート・プロバイダを開発する方法についての具体的なガイドラインは含まれていませんが、この項では、あるトランスポートSDKのセキュリティ目標について説明します。

39.6.1 インバウンド・リクエストの認証

トランスポート・プロバイダは、インバウンド認証のメカニズムがそのトランスポートに適しているものはすべて自由に実装できます。例:HTTPトランスポートは次の認証方式をサポートします。

- HTTP基本認証

- HTTPヘッダーで送信されるカスタム認証トークン

HTTPSトランスポート・プロバイダは、上記の認証方法の他に、SSLクライアント認証をサポートします。HTTPトランスポート・プロバイダおよびHTTPSトランスポート・プロバイダのどちらも、匿名のクライアント・リクエストをサポートします。

トランスポート・プロバイダは、適用可能な任意のトランスポート・レベル認証スキームを実装します。トランスポート・プロバイダがクライアントを認証する場合、weblogic.security.Security.runAs(subject)のスコープ内でTransportManager.receiveMessage()を呼び出し、Service BusがクライアントのSubjectオブジェクトを使用できるようにする必要があります。このメソッドの詳細は、「Oracle Service Bus Java APIリファレンス」を参照してください。

注意:

JavaのSubjectクラスの詳細は、http://docs.oracle.com/javase/7/docs/api/javax/security/auth/Subject.htmlを参照してください。

プロキシ・サービスは、次のように、このSubjectを使用します。

- プロキシ・サービスへのアクセス制御中

- メッセージ・コンテキスト変数$inbound/ctx:security/ctx:transportClient/*へのデータの入力

- IDの伝播および資格証明マッピングの入力として(メッセージ・レベルのクライアント認証もある場合を除く)

トランスポート・プロバイダが認証をサポートしない、または匿名のリクエストをサポートする場合、リクエストをディスパッチする前に匿名サブジェクトがスレッド上にあることを確認する必要があります。通常、トランスポート・プロバイダは、匿名としてすでに実行しています。そうでない場合、プロバイダは次の呼出しを行う必要があります。

Subject anonymous = SubjectUtils.getAnonymousUser()
Security.runAs(anonymous, action)

トランスポート・プロバイダは、インバウンド・クライアント認証の構成に必要な、任意のOracle Service Busコンソール構成ページの提供も行います。トランスポート・プロバイダは、インバウンド認証モデルを明確に記録しておく必要があります。

39.6.2 アウトバウンド・リクエストの認証

トランスポート・プロバイダは、アウトバウンド認証スキームがそのトランスポートに適しているものはすべて自由に実装できます。トランスポートSDKには、ユーザー名およびパスワードによるアウトバウンド認証、(双方向) SSLクライアント認証およびJAAS Subject認証を容易に実現するための方法が含まれています。

39.6.2.1 ユーザー名とパスワードによるアウトバウンド認証

Service Busのサービス・アカウントを使用して、ユーザー名およびパスワードによるアウトバウンド認証を実装できます。サービス・アカウントは、最上級で最高位のService Busリソースです。Oracle Service BusコンソールまたはJDeveloperでサービス・アカウントを作成して管理します。トランスポート・プロバイダでは、それぞれのトランスポート固有の構成を自由に設計し、サービス・アカウントへの参照を含めることができます。このようにして、トランスポート・プロバイダは、サービス・アカウントによって提供される資格証明管理メカニズムを利用できます。

トランスポート・プロバイダでは、サービス・アカウントの構成の詳細について懸念する必要はありません。サービス・アカウントのタイプは、次の3つです。

- 静的: 静的なサービス・アカウントは、固定されたユーザー名およびパスワードで構成されます。

- マップされている: マップされたサービス・アカウントには、リモート・ユーザーおよびリモート・パスワードのリストがローカル・ユーザーからリモート・ユーザーへのマップとともに含まれます。マップされたサービス・アカウントでは、必要に応じて、任意のリモート・ユーザーに匿名サブジェクトをマップできます。

- パススルー: パススルー・サービス・アカウントは、Service Busクライアントのユーザー名およびパスワードがバックエンドに送信される必要があることを示しています。

アウトバウンド・エンドポイントは、サービス・アカウントへの参照を持つことができます。サービス・アカウントへの参照は、トランスポート固有のエンドポイントの構成に格納する必要があります。プロキシ・サービスが、メッセージをこのアウトバウンド・エンドポイントにルーティングする場合、トランスポート・プロバイダは、サービス・アカウントへの参照をCredentialCallback.getUsernamePasswordCredential(ref)に渡します。Service Busは、サービス・アカウントの構成に応じて、ユーザー名およびパスワードを返します。この方法には、IDの伝播と資格証明マッピングの構成をトランスポート固有の詳細な作業から分離することで、トランスポートSDKを簡素化できるという利点があります。また、この構成の共有も可能になります。複数のエンドポイントが同じサービス・アカウントを参照できます。

注意:

CredentialCallbackオブジェクトは、TransportSender.getCredentialCallback()を呼び出すことによりトランスポート・プロバイダで使用できるようになります。

CredentialCallback.getUsernamePasswordCredential()は、weblogic.security.UsernameAndPasswordインスタンスを返します。これは、ユーザー名およびパスワードを取得するためのメソッドを持つ簡単なクラスです。返されるユーザー名およびパスワードは、サービス・アカウントのタイプによって異なります。サービス・アカウントのタイプが静的である場合、固定されたユーザー名およびパスワードが返されます。サービス・アカウントのタイプがマップされている場合、クライアント・サブジェクトを使用してリモートのユーザー名およびパスワードがルックアップされます。サービス・アカウントがパススルーの場合、クライアントのユーザー名およびパスワードが返されます。

注意:

次のいずれかが当てはまる場合、マップされたサービス・アカウントは、CredentialNotFoundExceptionをスローします。

- インバウンド・クライアントのマップが存在しない。

- インバウンドのセキュリティ・コンテキストが匿名であり、匿名マップが存在しない。

39.6.2.2 アウトバウンドSSLクライアント認証(双方向SSL)

Service Busは、アウトバウンドSSLクライアント認証をサポートします。この場合、アウトバウンドSSLリクエストを出すプロキシ・サービスを、SSL用のPKIキー・ペアを使用して構成する必要があります。これには、プロキシ・サービス・プロバイダへの参照が含まれますが、このドキュメントでは、詳細については取り上げていません。SSLクライアント認証用のキー・ペアを取得するには、トランスポート・プロバイダがCredentialCallback.getKeyPair()を呼び出す必要があります。この例として、HTTPSトランスポート・プロバイダがあります。

39.6.2.3 アウトバウンドJAAS Subject認証

一部のトランスポート・プロバイダは、認証トークンとして、シリアライズされたJAAS Subjectを回線で送信します。インバウンド・サブジェクトを取得するには、トランスポート・プロバイダがCredentialCallback.getSubject()を呼び出す必要があります。

注意:

戻り値は、匿名サブジェクトである場合があります。

39.6.3 リンクレベルまたは接続レベルの資格証明

一部のトランスポートでは、サービスに接続するために資格証明が必要になります。たとえば、FTPサーバーへの認証には、FTPエンドポイントが必要になる場合があります。トランスポート・プロバイダは、静的なサービス・アカウントを利用して、接続を確立するためのユーザー名およびパスワードを取得できます。これらの接続は、特定のクライアント・リクエストのかわりとしての確立されるものではないため、この場合、マップされたサービス・アカウントまたはパススルー・サービス・アカウントは使用できません。トランスポート・プロバイダでこのアプローチを採用する場合は、サービス・アカウントへの参照を使用してエンドポイントを構成する必要があります。実行時に、トランスポート・プロバイダは、TransportManagerHelper.getUsernamePassword()を呼び出して、静的なサービス・アカウントへの参照を渡す必要があります。

39.6.4 プロキシ・サービスへの一貫したアクセス制御

Service Busは、すべてのインバウンド・リクエストについてプロキシ・サービスへのアクセス制御を実施します。トランスポート・プロバイダでは、アクセス制御を実施するための、またはアクセス制御ポリシーを管理するためのインタフェースを提供する必要はありません。

アクセス制御ポリシーはほとんどの使用例を対象としていますが、トランスポート・プロバイダに固有の理由で、Service Busによって行われるアクセス制御チェックの他に独自のアクセス制御メカニズムが必要な場合は、それらを実装できます。この場合は、Oracle販売代理店にお問い合せください。通常は、トランスポート・プロバイダで、Service Busを使用してアクセス制御を処理する方法をお薦めします。

アクセスが拒否されると、TransportManager.receiveMessage()は、TransportException内にラップされているAccessNotAllowedExceptionをスローします。トランスポート・プロバイダは、TransportExceptionの根本原因を確認します。根本原因がAccessNotAllowedExceptionである場合、トランスポート・プロバイダは、特別なエラー処理を行う場合があります。たとえば、この場合、HTTP/Sトランスポート・プロバイダはHTTP 403 (forbidden)エラー・コードを返します。

注意:

Service Busは、アクセス制御の判断を行うために、認可プロバイダがリクエスト・ヘッダーを使用できるようにします。

39.6.5 IDの伝播および資格証明マッピング

「アウトバウンド・リクエストの認証」で説明したように、Service Busには、3つのタイプのサービス・アカウントが用意されています。トランスポート・プロバイダは、サービス・アカウントを利用して、アウトバウンド認証のためのユーザー名およびパスワードにアクセスできます。サービス・アカウントは、Service Busのトランスポート・プロバイダに対し、すべてのIDの伝播および資格証明マッピングの詳細を非表示にしています。

39.7 トランスポートSDKおよびスレッド・モデル

図39-4に、1つのインバウンド・メッセージを処理する仮想のトランスポート・エンドポイントを表す、Service Busのスレッド・モデルを示します。

サーブレットなどのフロント・エンド・アーティファクトが、インバウンド・メッセージを取得します。リクエストを、アウトバウンド・エンドポイントにルーティングし、非同期的に送信できます。この時点で、スレッドは解放されます。その後しばらくして、コールバックを使用して、レスポンスがService Busに送り返されます。レスポンスが受信され、パッケージ化されて、Service Busパイプラインに渡されます。その後、パイプラインが、レスポンスをクライアントに送信する準備ができていることをインバウンド・エンドポイントに通知します。スレッドが使用できないのは必要な間のみであるため、この処理はスケーラブルです。

図39-4 Service Busのスレッディング・モデルのサンプル

39.7.1 インバウンド・リクエスト・メッセージのスレッド

インバウンド・リクエストの処理中、同じスレッドで次のアクションが実行されます。

1. トランスポート・エンドポイントのフロント・エンド・アーティファクトがインバウンド・メッセージを受信します。このフロント・エンド・アーティファクトは、HTTPサーブレットやJMSメッセージ駆動型Beanのインスタンスなどです。

2. トランスポート・エンドポイントの実装により、メッセージはTransportMessageContextオブジェクトにパッケージ化され、Service Busランタイムに渡されます。TransportMessageContextインタフェースの詳細は、「リクエストおよびレスポンス・メッセージのメタデータおよびヘッダーの表現」を参照してください。

3. パイプラインは、構成されているリクエスト・パイプライン・アクションを実行します。

4. パイプラインでインバウンド・メッセージを処理すると同時に、同じ(リクエスト)スレッドで、Service Busランタイムは、アウトバウンド・メッセージを外部サービスに配信するよう、登録されているアウトバウンド・トランスポート・エンドポイント(このエンドポイントは、同じプロバイダで管理されている場合と管理されていない場合がある)に要求します。

5. その後しばらくして、外部サービスは、レスポンス・メッセージを配信するよう、アウトバウンド・エンドポイントに非同期的に要求します。アウトバウンド・エンドポイントは、トランスポート固有のコールバック・オブジェクトを使用して、事前に登録されている必要があります。

注意:

この時点で、最初のリクエスト・スレッドは解放され、別のリクエストが使用できるようにOracle WebLogic Serverのスレッド・プールに戻されます。

39.7.2 アウトバウンド・レスポンス・メッセージのスレッド

アウトバウンド・レスポンス・メッセージの処理中、同じスレッドで次のアクションが実行されます。

1. レスポンス・メッセージは、TransportMessageContextオブジェクトにパッケージ化され、レスポンス処理のためにService Busランタイムに戻されます。この処理は、リクエスト・スレッドとは別のスレッドで実行されます。新しいスレッドは、レスポンス・スレッドと呼ばれます。

2. レスポンス・メッセージが処理された後、Service Busランタイムは、レスポンスをコール元に送り返すことを通知するよう、InboundTransportMessageContextオブジェクトに要求します。InboundTransportMessageContextインタフェースの詳細は、「リクエストおよびレスポンス・メッセージのメタデータおよびヘッダーの表現」を参照してください。
トランスポート・プロバイダが、非同期の(非ブロッキング)アウトバウンド・コールをネイティブに実装していない場合は、インバウンド・リクエスト・メッセージを受信したスレッドとは別のスレッドで、Service Busランタイムにレスポンスを返す必要があります。これを行うためにトランスポート・プロバイダは、リクエスト・スレッドでブロッキング方法によりコールを実行し、トランスポートSDKのヘルパー・メソッドを使用して、Service Busランタイムにレスポンスを返します。

たとえば、EJBトランスポート・プロバイダは、非同期(非ブロッキング)のアウトバウンド呼出しを実装していません。基底のAPIはブロッキングAPIです。これに対処するには、プロバイダがブロッキング呼出しを行い、その後で、TransportManagerHelper.schedule()を使用して処理に対するレスポンスをスケジュールします。EJBトランスポート・プロバイダの詳細は、「EJBトランスポートの使用」を参照してください。

39.7.3 非同期のサポート

トランスポート・サブシステムは、意図的に、Service Busと非同期的に対話するようになっています。これは、非同期での動作が、同期での動作よりもスケーラブルであるため望ましいからです。非同期の対話用に1つ、および同期の対話用に1つと、2つの別々のAPIを作成するのではなく、Service Busランタイムでは非同期の対話が必要です。この処理は、ブロッキング呼出しやコールバックでのレスポンスをポストするなどの方法により、トランスポート開発者が行う必要があります。いずれにせよ、レスポンスは、リクエストとは別のスレッドで実行する必要があります。

39.7.4 パブリッシュおよびサービス・コールアウトのスレッディング

図39-4に示すスレッド・ダイアグラムは、ルーティングに焦点を当てたものです。トランスポート・サブシステムは、リクエストまたはレスポンス・パイプラインの処理中に実行されるService Busのパブリッシュ・アクションとサービス・コールアウト・アクションに対して同じように動作します。これらのアクションは、トランスポート・サブシステムの範囲外およびService Busパイプラインの範囲内で実行されます。そのため、パブリッシュおよびサービス・コールアウトのスレッディング動作とトランスポート・プロバイダのスレッディング動作には違いがいくつかあります。

ただし、次の場合に注意してください。

- サービス・コールアウト: 非同期的にレスポンスを受信するまで、パイプライン・プロセッサがスレッドをブロックします。その後、ブロックされたスレッドはパイプラインの実行を再開します。この目的は、後でパイプライン・アクションで使用できる変数をバインドし、ビジネス・ロジックを実行することです。そのため、レスポンスが返される前にビジネス・ロジックが実行されるように、これらのアクションがブロックする必要があります。

- パブリッシュ: 非同期的に応答を受信するまで、パイプライン・プロセッサがスレッドをブロックしない場合もあります。その後、このスレッドは、残りのリクエストまたはレスポンス・パイプラインの処理の実行を続行します。

ヒント:

サービス・コールアウト・アクションにより、ユーザーは、Service Busにすでに登録されているプロキシまたはビジネス・サービスに対し、同期(ブロッキング)呼出しを構成できます。メッセージのターゲット・サービスを特定し、そのサービスへメッセージをパッケージ化し、送信する方法を構成するには、パブリッシュ・アクションを使用してください。サービス・コールアウト・アクションおよびパブリッシュ・アクションの詳細は、「コンソールでのサービス・コールアウト・アクションの追加」および「コンソールでのパブリック・アクションの追加」を参照してください。

39.8 メッセージ・コンテンツの設計

トランスポート・プロバイダには、メッセージ・コンテンツの独自のネイティブ表現があります。たとえば、HTTPトランスポートはjava.io.InputStreamを使用し、JMSは、様々なタイプのMessageオブジェクトがあります。また、Tuxedoにはバッファがあり、Oracle WebLogic Server WebサービスのスタックはSAAJを使用します。ただし、プロキシ・サービスの実行時は、コンテンツのネイティブ表現は、メッセージ・コンテキストです。Service Busは、InputStreamからメッセージ・コンテキストへのまたはその逆などの一部の一般的な変換シナリオをサポートしますが、トランスポートでの表現とメッセージ・コンテキストの間の変換は、最終的にはトランスポート・プロバイダが行います。

通常、トランスポートSDKが、トランスポートの2つの異なるコンテンツ表現を直接変換することはありません。ただし、2つのトランスポートが互換性のある表現を使用していて、コンテンツを再エンコードする必要がない場合は、SDKによって、(たとえば、インバウンド・ファイル・トランスポートからアウトバウンドHTTPトランスポートにFileInputStreamを渡すことにより)ソース・コンテンツを直接パススルーできます。ただし、ソース・コンテンツでなんらかの処理が必要な場合は、最初にソース・コンテンツをメッセージ・コンテキストに復号化し、その後で標準のメカニズムを使用して送信トランスポート用のコンテンツを生成した方が適切です。

39.8.1 SourceおよびTransformer

コンテンツは、Sourceインタフェースのインスタンスとして表されます。TransportSenderやTransportMessageContextなどのメッセージ・コンテンツを処理するトランスポートSDKインタフェースは、すべてメッセージ・ペイロードを渡す際に、Sourceインタフェースを使用します。Sourceにおける要件はごくわずかです。Sourceは、基本となるSourceインタフェースで定義されている2つのメソッドを使用した、バイト単位のストリームへのプルベースおよびプッシュベースの変換をサポートする必要があります。Sourceは、シリアライゼーション中に、TransformOptionsパラメータで指定されている、文字セット・エンコーディングなどの様々なトランスフォーメーションのオプションを考慮しない場合があります。

すべてのSourceオブジェクトは基底のシリアライゼーション・インタフェースを実装する必要がありますが、Sourceオブジェクトのコンテンツの基礎となる表現は実装固有のものです。そのため、InputStream、JMS Messageオブジェクト、Stringまたは特定のトランスポートに最も適している表現に基づいたSourceオブジェクトを使用できます。通常、Sourceを実装することで、基本的なシリアライゼーション・メソッドのみでなく、基底のコンテンツに直接アクセスできるようになります。たとえば、内部でStringオブジェクトを使用してそのコンテンツを格納するStringSourceは、内部データにアクセスするためのgetString()メソッドを提供します。その後、Sourceの最終的なコンシューマは、これらのソース固有のAPIを呼び出して、基底のコンテンツを抽出し、シリアライゼーションのオーバーヘッドを回避できます。

また、Transformerオブジェクトを使用して、Sourceを他のタイプのSourceに変換することもできます。トランスポート・プロバイダなどのSourceコンシューマが、認識できないSourceインスタンスを受け取った場合は、多くの場合、認識できるSourceインスタンスに変換できます。その後、ソース固有のAPIを使用して、認識できるSourceから基底のコンテンツを抽出できます。ただし、トランスポート・プロバイダは多くの場合、単に基本的なシリアライゼーション・メソッドを使用してコンテンツをシリアライズし送信します。詳細は、「SourceおよびTransformerクラスとインタフェース」を参照してください。

39.8.2 SourceおよびMessageContextオブジェクト

Sourceは、トランスポート・レイヤーとバインディング・レイヤーの間の一般的なコンテンツ表現です。バインディング・レイヤーは、トランスポート・レイヤーで使用されるSource表現と実行時にパイプラインで使用されるメッセージ・コンテキストとの間でコンテンツを変換するエンティティです。変換がどのように行われるかは、サービスのタイプ(そのバインディングのタイプ)と添付の有無によって異なります。厳密にはトランスポートSDKの役割ではありませんが、独自のSourceオブジェクトを定義しているすべてのトランスポート・プロバイダは、この変換プロセスを認識している必要があります。

添付が存在しない場合、受信したSourceは単にコアとなるメッセージ・コンテンツを示します。受信したSourceを特定のタイプのSourceに変換し、その後で基底のコンテンツを抽出することでMessageContextが初期化されます。たとえば、XMLベースのサービスの場合、受信したSourceはXmlObjectSourceに変換されます。その後、XmlObjectSourceからXmlObjectが抽出され、$bodyコンテキスト変数内でペイロードとして使用されます。同様に、SOAPサービスはXmlObjectSourceに変換されます。ただし、<SOAP:Header>および<SOAP:Body>要素を抽出して$headerおよび$bodyコンテキスト変数を初期化できるようにするために、抽出されたXmlObjectがSOAP Envelopeである必要がある点が異なります。

定義された一連のサービス・タイプで使用される標準的なSourceのタイプを次に示します。

- SOAP: XmlObjectSource

- XML: XmlObjectSource

- TEXT: StringSource

- MFL: MFLSource

バイナリ・サービスの場合、Sourceの変換は行われません。かわりに、Sourceは、SourceRepositoryに登録され、結果の<binary-content/> XMLは、$body内でペイロードとして使用されます。

添付が存在する場合、Sourceは最初にMessageContextSourceに変換されます。MessageContextSourceから、2つのタイプのSourceオブジェクトが取得されます。1つが添付で、もう1つがコア・メッセージです。コア・メッセージのSourceは、前述のとおり処理されます。添付を表すSourceは、AttachmentsSourceに変換されます。AttachmentsSourceから、XMLが取得され、$attachmentsコンテキスト変数および任意のバイナリの添付コンテンツを表す登録済のSourceを含むSourceRepositoryの初期化に使用されます。図39-5に、このプロセス全体を示します。

図39-5 添付のフロー

トランスポート・レイヤーに渡すためにMessageContext内のデータからSourceを作成する場合にも、同様の変換が実行されます。コア・メッセージは、サービスのタイプの標準的なSourceに変換できるSourceインスタンスで表現されています。ほとんどの場合、Sourceは、すでに標準的なSourceのインスタンスになっていますが、必ずしもそうであるとは限りません。添付が存在する場合、トランスポート・レイヤーに渡されるSourceは、MessageContextSourceインスタンスに変換できるSourceになります。トランスポート・プロバイダが、事前定義されたトランスポート・ヘッダーとしてContent-Typeをサポートする場合、一般的に、配信されたSourceはMessageContextSourceのインスタンスになります。それ以外の場合、配信されたSourceはMimeSourceのインスタンスであることが多いですが、これもMessageContextSourceに変換できます。

この違いの理由は、トランスポート・ヘッダーとしてContent-Typeをネイティブにサポートするトランスポートでは、ペイロードではなく、トランスポート・ヘッダーにトップ・レベルのMIMEヘッダーが含まれている必要があるためです。この例としては、HTTPおよび電子メールがあります。Content-Typeをネイティブにサポートしないトランスポートでは、これらのトップ・レベルのMIMEヘッダーがペイロードに含まれている必要があります。Content-Typeヘッダーは、複数のMIMEパッケージのデコードに不可欠であるためです。

39.8.3 組込みのトランスフォーメーション

表39-1はソースと、そのソースを組込みのTransformerによって変換できるソース・タイプの一覧を示しています。たとえば、StringSourceからXmlObjectSourceへの変換を処理する組込みのトランスフォーメーションはありますが、StringSourceをMFLSourceに変換できるトランスフォーメーションはありません。通常、これらのトランスフォーメーションは両方のSourceのタイプで使用される内部データ表現の情報を利用します。

表39-1 組込みのトランスフォーメーション

パブリック・ソース

変換後のソース・タイプ

ソース

- StreamSource

- ByteArraySource

- StringSource

- XmlObjectSource

- DOMSource

- MFLSource

- SAAJSource

StreamSource

StreamSource

ByteArraySource

ByteArraySource

StringSource

- StringSource

- XmlObjectSource

- DOMSource

XmlObjectSource

- StringSource

- XmlObjectSource

- DOMSource

- MFLSource

DOMSource

- StringSource

- XmlObjectSource

- DOMSource

- MFLSource

MFLSource

- XmlObjectSource

- DOMSource

- MFLSource

MimeSource

- MimeSource

- SAAJSource

- MessageContextSource

SAAJSource

- MimeSource

- SAAJSource

- MessageContextSource

MessageContextSource

- MimeSource

- SAAJSource

- MessageContextSource

これらの一般的なトランスフォーメーションは元のSourceタイプの情報を使用せずに行われますが、かわりに、すべてのSourceが実装している基本的なシリアライゼーション・メソッドのgetInputStream()およびwriteTo()を利用します。したがって、XmlObjectSourceからByteArraySourceへの変換は最終的には可能ですが、XmlObjectSourceの内部情報を使用して行われることはありません。

注意:

トランスポートで実装されているカスタム・ソースの多くは、(基底のデータが構造化されていないバイトの収集である場合は特に)これらの一般的なトランスフォーメーションで処理できます。たとえば、ファイル・トランスポートは、ディスク上のファイルから直接コンテンツを取り出すカスタム・ソースを使用します。ただし、データは構造のない単なるバイトのセットであるため、XmlObjectSourceなどへのカスタム・トランスフォーメーションを実行する必要はありません。一般的なトランスフォーメーションで、すべてのSourceが実装している基本的なシリアライゼーション・メソッドのみを使用して、このカスタムFileSourceを処理できます。

詳細は、「SourceおよびTransformerクラスとインタフェース」を参照してください。

40 カスタム・トランスポート・プロバイダの開発

この章では、カスタム・トランスポート・プロバイダの開発に必要な基本手順について説明します。 トランスポートSDKは、トランスポート・プロトコルとService Busランタイム・システムとの間に抽象のレイヤーを提供します。この抽象のレイヤーでは、新しいトランスポート・プロバイダを開発してService Busにプラグインできます。トランスポートSDKインタフェースは、HTTPなどのトランスポート・プロトコルとService Busランタイムの間を橋渡しします。

ヒント:

この章を始める前に、「カスタム・トランスポート・プロバイダについて」を確認してください。

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

- 開発の流れ

- 始める前に

- 開発の基本手順

- 開発に関する重要トピック

- カスタム・トランスポートのヘルプの作成

40.1 開発の流れ

カスタム・トランスポート・プロバイダを設計および構築するプロセスは複雑です。この項では、トランスポート・プロバイダを開発する際の推奨事項について説明します。カスタム・トランスポート・プロバイダの開発は、計画、開発およびパッケージ化とデプロイの3つの基本的な手順に分類されます。

- 計画

- 開発

- パッケージ化とデプロイ

40.1.1 計画

カスタム・トランスポート・プロバイダを開発する前に、次の計画手順を実行します。

1. カスタム・トランスポート・プロバイダを開発する必要があるかどうかを判断します。「カスタム・トランスポート・プロバイダの開発の必要性」を参照してください。

2. ソケット・トランスポート・プロバイダのサンプルを実行して検討します。このプロバイダのソース・コードはService Busとともにインストールされます。また、内容を検討したり再利用したりできるように一般に公開されています。「サンプル・ソケット・トランスポート・プロバイダの作成」を参照してください。

3. 「カスタム・トランスポート・プロバイダについて」を確認します。ここでは、トランスポート・プロバイダのアーキテクチャ、およびトランスポート・プロバイダで使用されるセキュリティ・モデルやスレッディング・モデルなど、トランスポート・プロバイダの設計の様々な側面について説明しています。

4. 「始める前に」を確認します。

40.1.2 開発

カスタム・トランスポートの開発手順には、XMLスキーマ・ファイル、構成コンポーネント、ユーザー・インタフェースなどの必要なアーティファクトの作成が含まれます。「基本的な開発手順」では、トランスポート・プロバイダを開発するために実行する必要がある手順について説明します。カスタム・トランスポートを開発する前に、開発サイクル中に参照する必要があるメッセージ、エラー処理、メッセージの変換など、いくつかのトピックを説明している「開発に関する重要事項」を確認してください。

40.1.3 パッケージ化およびデプロイ

トランスポート・プロバイダのパッケージ化およびデプロイの詳細は、「カスタム・トランスポート・プロバイダのパッケージ化とデプロイ」を参照してください。

40.2 始める前に

カスタム・トランスポート・プロバイダの開発を始める前に、考慮する必要がある設計時に考慮事項のいくつかを次に示します。

- カスタム・トランスポート・プロバイダを開発する必要があるかどうかを判断します。「カスタム・トランスポート・プロバイダの開発の必要性」を参照してください。

- メッセージ・エンドポイントをトランザクション対応にするかまたはトランザクション非対応にするかを判断します。「トランザクション対応のエンドポイントとトランザクション非対応のエンドポイント」を参照してください。

- メッセージ・エンドポイントを一方向、同期、非同期のいずれにするかを判断します。「サポートされているメッセージ・パターン」および「同期トランザクションのサポート」を参照してください。

- 送信メッセージと着信メッセージのセキュリティ要件を決定します。「トランスポートSDKセキュリティ・モデル」を参照してください。

- Service Busで使用されるスレッド・モデルについて理解します。「トランスポートSDKおよびスレッド・モデル」を参照してください。

- トランスポート・プロバイダで同期アウトバウンド呼出しと非同期アウトバウンド呼出しのどちらがサポートされるかを判断します。「非同期のサポート」を参照してください。

- トランスポートSDKに用意されているインタフェースとクラスについて確認し、トランスポート・プロバイダの設計時部分および実行時部分にどのように適合するのかを理解します。「トランスポートSDKのインタフェースおよびクラス」を参照してください。

- カスタム・トランスポート・プロバイダをパッケージ化およびデプロイする方法について理解します。「カスタム・トランスポート・プロバイダのパッケージ化とデプロイ」を参照してください。

- トランスポート・フレームワークを介したメソッド呼出しのフローを確認します。「トランスポートSDK UMLシーケンス・ダイアグラム」を参照してください。

40.3 開発の基本手順

カスタム・トランスポート・プロバイダを開発する際に従う基本手順は次のとおりです。

ステップ1. トランスポート・フレームワーク・コンポーネントの確認

ステップ2. トランスポート・プロジェクトのディレクトリ構造の作成

ステップ3. トランスポート固有のアーティファクトのXMLスキーマ・ファイルの作成

ステップ4. トランスポート固有のアーティファクトの定義

ステップ5. TransportProviderConfiguration XMLBeanの定義

ステップ6. トランスポート・プロバイダのユーザー・インタフェースの実装

ステップ7. 実行時インタフェースの実装

ステップ8. トランスポート・プロバイダのパッケージ化とデプロイ

40.3.1 手順1トランスポート・フレームワーク・コンポーネントの確認

図40-1は、カスタム・トランスポート・プロバイダを作成する際に、実装および構成する必要があるコンポーネントを示しています。トランスポート・マネージャは、トランスポート・プロバイダの登録を制御および管理し、Service Busとの通信を処理します。トランスポート・プロバイダは、トランスポート・エンドポイント(メッセージの送信元または送信先となるリソース)のライフ・サイクルおよび実行時の動作を管理します。カスタム・トランスポート・プロバイダを開発するには、トランスポートSDKを使用します。

図40-1 トランスポート・サブシステムの概要

実装および構成する必要があるトランスポート・サブシステムには、次のものがあります。

- トランスポートUIバインディング: トランスポート・プロバイダのユーザー・インタフェース・コンポーネント。関連するインタフェースの概要は、「ユーザー・インタフェースの構成」を参照してください。

- トランスポート・エンドポイント: メッセージの送受信を行います。関連するインタフェースの概要は、「汎用クラスおよびインタフェース」を参照してください。

- エンドポイント構成: エンドポイント構成を格納します。関連するインタフェースの概要は、「スキーマで生成されるインタフェース」を参照してください。

- トランスポート・メッセージ・コンテキスト: メッセージ(インバウンドおよびアウトバウンド)のリクエスト・ヘッダー、レスポンス・ヘッダーおよびその他の部分のメタデータが含まれています。詳細は、「SourceおよびTransformerクラスとインタフェース」および「リクエストおよびレスポンス・メッセージのメタデータおよびヘッダーの表現」を参照してください。

- WLSアーティファクト・デプロイヤ: (オプション)メッセージを送受信するサーブレットなどの、アーティファクトをデプロイします。

- トランスポートの送信者: アウトバウンド・メッセージおよびペイロードのメタデータを取得します。関連するインタフェースのサマリーは、「汎用インタフェースのサマリー」を参照してください。

- トランスポートのリスナー: アウトバウンド・エンドポイントがService Busの残りの部分にアウトバウンド・リクエストの結果をポストできるようにします。「リクエストおよびレスポンス・メッセージのメタデータおよびヘッダーの表現」も参照してください。

- リクエスト/レスポンスのメタデータ: 関連するインタフェースの概要については、「リクエストおよびレスポンス・メッセージのメタデータおよびヘッダーの表現」を参照してください。

40.3.2 手順2トランスポート・プロジェクトのディレクトリ構造の作成

新しいトランスポート・プロバイダを開発する前に、プロジェクトの適切なディレクトリ構造をセットアップします。サンプル・ソケット・トランスポート・プロバイダに使用されているディレクトリ構造をコピーすることをお薦めします。この構造の詳細は、「サンプルの場所とディレクトリ構造」を参照してください。

40.3.3 手順3トランスポート固有のアーティファクトのXMLスキーマ・ファイルの作成

XMLスキーマ(XSD)ファイルを作成し、トランスポート固有の定義を記述します。このファイルは、サンプル・ソケット・トランスポート・プロバイダ用に開発されたスキーマ・ファイル(OSB_ORACLE_HOME/samples/servicebus/sample-transport/schemas/SocketTransport.xsd)を基に作成できます。

注意:

SocketTransport.xsdファイルにより、TransportCommon.xsdファイルがインポートされます。このファイルは、サービス・エンドポイントの構成用の基本となるスキーマ定義ファイルです。このファイルは、OSB_ORACLE_HOME/lib/modules/oracle.servicebus.kernel-api.jarにあります。続行する前に、このファイルのコンテンツを確認しておきます。

40.3.4 手順4トランスポート固有のアーティファクトの定義

前項の「ステップ3. トランスポート固有のアーティファクトのXMLスキーマ・ファイルの作成」で説明されているXMLスキーマ・ファイルで、次のトランスポート固有のアーティファクトのXMLスキーマを定義します。

- EndpointConfiguration

- RequestMetaDataXML

- ResponseMetaDataXML

これらの各スキーマ定義は、対応するJavaファイルに変換された後、コンパイルされます。サンプル・ソケット・トランスポート・プロバイダを作成すると、OSB_ORACLE_HOME/samples/servicebus/sample-transport/build/classes/com/bea/alsb/transports/sock/implで、これらの変換されたJavaソース・ファイルの例を検出できます。トランスポート・プロバイダ固有のメタデータおよびヘッダーを定義する場合は、単純なXMLタイプのみサポートされています。たとえば、ネストされた要素を持つ複雑なタイプはサポートされていません。また、指定の名前のヘッダーは最大でも1つのみです。

40.3.4.1 EndPointConfiguration

EndPointConfigurationは、エンドポイント構成のベース・タイプで、インバウンド・エンドポイントおよびアウトバウンド・エンドポイントのデプロイメントと操作に必要なパラメータの完全なセットを表します。この構成は、汎用的な部分とプロバイダ固有の部分で成り立ちます。EndPointConfigurationスキーマ定義の詳細は、TransportCommon.xsdファイルのドキュメント要素を参照してください。

プロバイダ固有のエンドポイント構成をスキーマ・ファイルに指定する必要があります。次の例はSocketTransport.xsdからの抜粋を示します。

例 - SocketEndPointConfiguration定義のサンプル

<xs:complexType name="SocketEndpointConfiguration">
<xs:annotation>
<xs:documentation>
SocketTransport - specific configuration
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:choice>
<xs:element name="outbound-properties"
type="SocketOutboundPropertiesType"/>
<xs:element name="inbound-properties"
type="SocketInboundPropertiesType"/>
</xs:choice>
<xs:element name="request-response" type="xs:boolean">
<xs:annotation>
<xs:documentation>
Whether the message pattern is synchronous
request-response or one-way.
</xs:documentation>
</xs:annotation>
</xs:element>
...

40.3.4.2 RequestMetaDataXML

各トランスポート・プロバイダは、メタデータ(メッセージ・ヘッダー)をPOJO (Plain Old Java Object)に格納し、パイプラインに渡す必要があります。メタデータとして送信できる情報の例には、Content-Typeヘッダー、セキュリティ情報、ロケール情報などがあります。RequestMetaData POJOは、RequestMetaData抽象クラスを拡張する汎用オブジェクトで、インバウンド・リクエストやアウトバウンド・リクエストのメッセージ・メタデータを表します。トランスポート・プロバイダでは、メッセージ・メタデータをRequestMetaData POJOのService Busランタイムに配信する必要があります。詳細は、「リクエストとレスポンスのメタデータの処理」を参照してください。

RequestMetaDataXMLは、同じRequestMetaData POJOをXMLで表現したものです。このXML表現では、Apache XML Beanテクノロジを使用します。アウトバウンド・リクエストのメタデータ全体を特定のXMLフラグメントに設定するなど、メッセージを処理するときにメタデータのXML表現を必要とするパイプラインでの操作を伴う場合のみ、Service Busランタイムで必要になります。

リクエスト・メタデータの構成をスキーマ・ファイルに指定する必要があります。次の例はSocketTransport.xsdからの抜粋を示します。

例 - SocketRequestMetaDataXML定義のサンプル

<xs:complexType name="SocketRequestMetaDataXML">
<xs:annotation>
<xs:documentation/>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ts:RequestMetaDataXML">
<xs:sequence>
<xs:element name="client-host"
type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation>
Client host name
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="client-port" type="xs:int" minOccurs="0">
<xs:annotation>
<xs:documentation>Client port</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

40.3.4.3 RequestHeadersXML

RequestHeadersXMLは、一連のインバウンド・リクエスト・ヘッダーまたはアウトバウンド・リクエスト・ヘッダーのベース・タイプです。RequestHeadersXMLの構成をスキーマ・ファイルに指定する必要があります。次の例はSocketTransport.xsdからの抜粋を示します。

例 - SocketRequestHeadersXML定義のサンプル

<xs:complexType name="SocketRequestHeadersXML">
<xs:annotation>
<xs:documentation/>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ts:RequestHeadersXML">
<xs:sequence>
<xs:element name="message-count" type="xs:long" minOccurs="0">
<xs:annotation>
<xs:documentation>
Number of messages passed till now.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

40.3.4.4 ResponseMetaDataXML

ResponseMetaDataXMLは、インバウンド・メッセージまたはアウトバウンド・メッセージに対するレスポンスのメタデータのベース・タイプです。ResponseMetaDataXMLの構成をスキーマ・ファイルに指定する必要があります。次の例はSocketTransport.xsdからの抜粋を示します。

例 - SocketResponseMetaDataXML定義のサンプル

<xs:complexType name="SocketResponseMetaDataXML">
<xs:complexContent>
<xs:extension base="ts:ResponseMetaDataXML">
<xs:sequence>
<xs:element name="service-endpoint-host"
type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation>
Host name of the service endpoint connection.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="service-endpoint-ip"
type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation>
IP address of the service endpoint connection.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

40.3.4.5 ResponseHeadersXML

ResponseHeadersXMLは、一連のレスポンス・ヘッダーのベース・タイプです。ResponseHeadersXMLの構成をスキーマ・ファイルに指定する必要があります。次の例はSocketTransport.xsdからの抜粋を示します。

例 - SocketResponseHeadersXML定義のサンプル

<xs:complexType name="SocketResponseHeadersXML">
<xs:annotation>
<xs:documentation/>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ts:ResponseHeadersXML"/>
</xs:complexContent>
</xs:complexType>

40.3.5 手順5TransportProviderConfiguration XMLBeanの定義

TransportProviderConfiguration XML Beanを構成するには、トランスポート・プロバイダの構成ファイルを編集します。このXMLファイルは、sample-transportディレクトリのresourcesディレクトリにあります。次のガイドラインに従ってこのファイルを構成します。

- プロキシ・サービスでトランスポートを使用できるようにする場合、inbound-direction-supported要素をtrueに設定します。

- ビジネス・サービスでトランスポートを使用できるようにする場合、outbound-direction-supported要素をtrueに設定します。

- トランスポートが自己記述型の場合、self-described要素の値をtrueに設定します。自己記述トランスポートでは、そのサービスがエンドポイント構成に基づいて形式(スキーマまたはWSDLファイル)を記述します。

- トランスポートのtModelをUDDIレジストリにパブリッシュする場合、UDDI要素を含めます。詳細は、「UDDIレジストリへのプロキシ・サービスのパブリッシュについて」を参照してください。

ヒント:

TransportProviderConfigurationのスキーマは、OSB_ORACLE_HOME/lib/sb-schemas.jarにあるTransportCommon.xsdに定義されています。詳細は、スキーマ・ファイルを参照してください。

40.3.6 手順6トランスポート・プロバイダのユーザー・インタフェースの実装

Oracle Service Busコンソールを使用してビジネス・サービスまたはプロキシ・サービスを追加する場合、サービス作成ウィザードでトランスポート・プロバイダを選択します。ウィザードには、Service Busで用意されているトランスポート・プロバイダおよびトランスポートSDKで開発されたカスタム・トランスポート・プロバイダが表示されます。ビジネス・サービスまたはプロキシ・サービスを構成すると、使用するトランスポート固有のプロパティがエディタに表示されます。これらは、カスタム・トランスポート・プロバイダ用に開発する必要があるすべてのユーザー・インタフェースです。

この項では、カスタム・トランスポート・プロバイダをOracle Service Busコンソールのユーザー・インタフェースにバインドする、トランスポートSDK APIコンポーネントについて説明します。プロバイダをユーザー・インタフェースに接続するには、これらのAPIを実装する必要があります。

ヒント:

ここでは、サービスの作成ウィザードおよびサービス定義エディタに慣れていることを前提としています。詳細な例は、「ソケット・トランスポートのサンプル・プロジェクトの作成」を参照してください。

トランスポート構成の処理フロー

1. ユーザーは、新しいサービスを作成するときに、サービスの作成ウィザードで適切なトランスポート・プロバイダを選択する必要があります。次に、SOAP、WSDLベース、XML、メッセージングなどのサービス・タイプも選択します。選択内容を検証するために、ウィザードによりTransportUIBindingインタフェースの次のメソッドが呼び出されます。

public boolean isServiceTypeSupported(BindingTypeInfo binding)

このメソッドにより、トランスポート・プロバイダが、選択したサービスの種類に適しているかどうかが判定されます。

2. 次にユーザーはエンドポイントURIを入力します。このURIを検証するために、ウィザードによりTransportUIBindingインタフェースの次のメソッドが呼び出されます。

public TransportUIError[] validateMainForm(TransportEditField[] fields)

3. サービスを作成すると、コンソールにサービス定義エディタが表示されます。ここには、トランスポート固有の構成ページが含まれています。このページを表示するために、エディタによりTransportUIBindingインタフェースの次のメソッドが呼び出されます。

public TransportEditField[] getEditPage(EndPointConfiguration config, BindingTypeInfo binding) throws TransportException

トランスポートSDKは、構成ページにフィールドを表示する、TransportUIObjectsのセットを提供します。たとえば、テキスト・ボックス、チェック・ボックス、およびその他のタイプのUI要素を追加できます。TransportUIFactoryを使用してこれらを作成してから、同じファクトリを使用して追加のプロパティを指定して、サービスの定義エディタに表示できるTransportEditFieldオブジェクトを取得します。

ヒント:

イベントを大部分のUIフィールドに関連付けることができます。イベントは、TransportUIBindingクラスのコールバック・メカニズムのように動作するため、構成ページをリフレッシュ、検証および更新できます。イベントがトリガーされると、ウィザードにより次のメソッドが呼び出されます。

updateEditPage(TransportEditField[] fields, String name) throws TransportException

4. トランスポートの構成が完了すると、エディタにより次の検証メソッドが呼び出されます。

TransportUIError[] validateProviderSpecificForm(TransportEditField[] fields)

5. サービスを保存すると、トランスポート・マネージャによりTransportProviderクラスの次のメソッドが呼び出されます。

void validateEndPointConfiguration(TransportValidationContext context)

エラーが報告されない場合は、新しいエンドポイントが作成されます。次に、トランスポート・マネージャにより次のメソッドが呼び出されます。

TransportEndPoint createEndPoint(EndPointOperations.Create context) throws TransportException

このメソッドが正常に返されると、新しいサービスがリストされ、基底のトランスポート構成がTransportProviderのエンドポイントに関連付けられます。

注意:

エンドポイント構成は、Service Busセッションに格納されます。サーバーを再起動するときに、トランスポート・プロバイダで保持したり復元したりする必要はありません。

6. セッションがアクティブになったら、エンドポイントをデプロイして、リクエストの処理を開始する必要があります。エンドポイントのデプロイおよびリクエストの処理の詳細は、「TransportWLSArtifactDeployerの実装が適している場合」および「クラスタへのデプロイ」を参照してください。

ヒント:

サンプル・ソケット・トランスポート・プロバイダの場合、これらのインタフェースの実装はsample-transport/srcディレクトリにあります。

40.3.7 手順7実行時インタフェースの実装

新しいカスタム・トランスポート・プロバイダでは、特定の実行時インタフェースを実装している必要があります。トランスポートSDKインタフェースの概要、および関連するクラスは、「トランスポートSDKのインタフェースおよびクラス」を参照してください。インタフェースとクラスの詳細は、Oracle Service Bus Java APIリファレンスを参照してください。

ヒント:

サンプル・ソケット・トランスポート・プロバイダの場合、これらのインタフェースの実装はsample-transport/srcディレクトリにあります。

カスタム・トランスポート・プロバイダを開発するときに、次のインタフェースを実装する必要があります。

- TransportProvider

- TransportWLSArtifactDeployer

- TransportEndPoint

- InboundTransportMessageContext

- OutboundTransportMessageContext

- Transformer

注意:

- トランスポート・プロバイダで、エンドポイントの作成時にWebLogic Server変更リストに記載される、WebLogic Server関連のアーティファクト(EAR、WAR、JARファイルなど)をデプロイする必要がある場合は、TransportWLSArtifactDeployerインタフェースのみを実装してください。詳細は、「TransportWLSArtifactDeployerの実装が適している場合」を参照してください。

- トランスポート・プロバイダで、非標準のペイロード・バインディング(ストリーム、DOM、SAXまたはXMLBean以外)を使用する必要がある場合のみ、Transformerインタフェースを実装してください。詳細は、「メッセージの変換」を参照してください。

40.3.8 手順8トランスポート・プロバイダのパッケージ化とデプロイ

このプロセスの詳細は、「カスタム・トランスポート・プロバイダのパッケージ化とデプロイ」を参照してください。

40.4 開発に関する重要トピック

ここでは、メッセージとエラーの処理、メッセージの変換、トランスポート・オプション、環境値、UDDIレジストリなど、カスタム・トランスポート・プロバイダを開発する際に考慮する必要があるいくつかのトピックについて説明します。

- メッセージの処理

- メッセージの変換

- TransportOptionsの操作

- エラー処理

- カスタム環境の値タイプの定義

- UDDIレジストリへのプロキシ・サービスのパブリッシュ

- TransportWLSArtifactDeployerの実装が適している場合

40.4.1 メッセージの処理

トランスポートSDKは、メッセージ・ペイロードを柔軟に表現できる点に特徴があります。ペイロードを処理するすべてのトランスポートSDK APIが、Sourceインタフェースを使用してメッセージ・コンテンツを表示します。

トランスポートSDKに用意されているSource派生のメッセージ・タイプには、次のものがあります。

- StreamSource

- ByteArraySource

- StringSource

- XmlObjectSource

- DOMSource

- MFLSource

- SAAJSource

- MimeSource

注意:

StreamSourceは、1度しか使用できないソースです。つまり、マーカー・インタフェースSingleUseSourceを実装しています。他のSourceの場合は、ソースから入力ストリームを何度でも取得できます。Sourceオブジェクトでは、毎回、入力ストリームを最初から取得します。SingleUseSourceの場合は、入力ストリームは1度しか取得できません。入力は、1度使用すると削除されます(ネットワーク・ソケットからのストリームなど)。ただし、Service Busでは、SingleUseSourceからの入力をバッファに入れ、基本的には、そのデータのすべてのコピーを保持します。

転送プロバイダにSourceクラスを実装する場合、入力ストリームを最初から再取得できるかどうかを判断する必要があります。入力ストリームが、その性質上1度しか使用できないものである場合は、Sourceクラスでマーカー・インタフェースSingleUseStreamを実装してください。

トランスポートSDKには、ソース・オブジェクト間で変換するための、一連のトランスフォーマが用意されています。一連の標準表現との変換をサポートするものであれば、必要に応じて、新しいトランスフォーマを実装できます。詳細は、「メッセージの変換」および「メッセージ・コンテンツの設計」を参照してください。

40.4.1.1 メッセージ・データの送受信

インバウンド・エンドポイントを実装して、インバウンド・メッセージをService Busランタイムに配信する場合、TransportManager.receiveMessage()をコールする必要があります。トランスポート・プロバイダは、ストリーム、DOM、SAXなどの標準のソース派生オブジェクトやカスタム・オブジェクトのいずれかで、着信メッセージ・ペイロードを自由に公開します。

Service Busでは、リクエストを送信したクライアントに対してレスポンス・メッセージを返信する必要がある場合、InboundTransportMessageContextでメソッドsetResponseMetaData()、setResponsePayload()およびclose()を呼び出して、レスポンスの返信準備ができていることを示します。Service Busランタイムがインバウンド・トランスポート・メッセージ・コンテキストのclose()メソッドをコールする場合、これは、インバウンド・リクエスト・メッセージを受信したスレッドとは異なるスレッドから行われます。トランザクションのセマンティクスに影響する可能性があるため、トランスポート・プロバイダでは、このことを認識している必要があります。また、close()が呼び出されるまで、トランスポート・プロバイダは、レスポンス・ペイロードまたはメタデータへのアクセスを試行できません。

40.4.1.2 リクエスト/レスポンスのメタデータの処理

各トランスポート・プロバイダは、メタデータおよびヘッダーをPOJO (Plain Old Java Object)に格納し、パイプラインに渡す必要があります。Service BusでXMLBeanが必要となる場合もあります。このような場合は、APIを使用して、POJOからXMLBeanへの変換を実装する必要があります。

POJOからXMLに変換するために、実装する必要があるメソッドを次に示します。

RequestHeaders.toXML()

RequestMetaData<T>.toXML()

ResponseHeaders.toXML()

ResponseMetaData<T>.toXML()

逆方向(XMLからPOJO)の場合は、次のメソッドを実装する必要があります。

TransportEndPoint.createRequestMetaData(RequestMetaDataXML)

InboundTransportMessageContext.createResponseMetaData(ResponseMetaDataXML)

40.4.1.3 文字セット・エンコーディング

各トランスポート・プロバイダは、Service Busに対して、着信メッセージ・ペイロードの文字セット・エンコーディングを指定します。送信メッセージ(アウトバウンド・リクエストとインバウンド・レスポンス)の場合、Service Busに対して、送信ペイロードに使用する文字セット・エンコーディングを指定します。文字セット・エンコーディングは、リクエストとレスポンスのメタデータに指定されます。

ほとんどの場合、トランスポートがメタデータに挿入する文字コード・エンコーディングは、サービス構成で静的に指定されているエンコードです。数少ない例外の1つがHTTPトランスポートです。HTTPトランスポートでは、charsetパラメータがあるかどうかContent-Typeを検査し、サービスに構成されているすべてのエンコーディングをオーバーライドします。この処理は、HTTP仕様に準拠する上で必要です。他の転送プロトコルでも、同様な問題を処理する必要がある場合があります。

ヒント:

通常、サービスのエンコーディングは固定です。SHIFT_JISに指定されているプロキシに対して、UTF-16でエンコードされたメッセージを送信すると、通常、エラーと見なされます。トランスポート・プロバイダは、単にエンコーディングを確認する目的で、メッセージを検査する必要はありません。

送信メッセージの場合、トランスポート・プロバイダがService Busに対してアウトバウンド・リクエストに必要なエンコーディングを指定し、Service Busが必要に応じて変換を実行します。

発信メッセージの場合、トランスポートは常にこのエンコーディングに基づいている必要があります。また、このエンコーディングは、サービス構成に指定されているエンコーディングと同じであるとはかぎりません。不一致がある場合、転送では不一致を許可できますが、転送以外の部分がエラーとみなして例外をスローする可能性があります。また、転送には、エンコーディング要素を空白のままにする、追加オプションがあります。これにより、パイプラインでは、自由にエンコーディングを指定できます(パススルーを使用する場合など)。

40.4.1.4 同じ場所に配置されたコール

特定のトランスポート・プロバイダがプロキシ・サービス・エンドポイントをサポートしている場合、ルーティング手順でそのプロバイダのプロキシ・サービスにルーティングするように、リクエスト・パイプラインを構成できます。さらに、パブリッシュ・アクション、またはビジネス・サービスではなくプロキシ・サービスに対してメッセージを送信するサービス・コールアウト・アクションが発生する場合があります。この使用例は、同じ場所に配置された呼出しと呼ばれます。

トランスポート・プロバイダは、同じ場所に配置された呼出しを認識し、それに応じて呼出しを処理する必要があります。プロキシ・サービス・エンドポイントの実装の性質によって異なりますが、トランスポート・プロバイダは呼出しの最適化を選択できます。その場合、呼出しは、トランスポート通信スタック全体およびすべてのインバウンド認可および認証を経由せずに、すぐにTransportManager.receiveMessage()を実質的に呼び出す直接呼出しになります。

ヒント:

Service Busは、この最適化をHTTP、ファイル、電子メールおよびFTPトランスポート・プロバイダで実装しています。JMSプロバイダでは、送信操作と受信操作のトランザクション・セマンティクスを分離する必要があるため、この最適化は使用されません。

カスタム・トランスポート・プロバイダでこの最適化を使用する場合は、CoLocatedMessageContextクラスを拡張して、TransportProvider.sendMessageAsync()が呼び出されたときにsend()メソッドをコールする必要があります。

40.4.1.5 Service Busランタイムへのアウトバウンド・レスポンスの返信

Service Busランタイムがアウトバウンド・エンドポイントにメッセージを送信し、レスポンス・メッセージが返される場合、トランスポート・プロバイダは、このレスポンスを非同期で返す必要があります。TransportSendListener.onReceiveResponse()メソッドまたはTransportSendListener.onError()メソッドは、TransportProvider.sendMessageAsync()が呼び出されたスレッドとは異なるスレッドから呼び出される必要があるということです。

トランスポート・プロバイダで、非同期レスポンス・オプションの使用時に、JMSリクエストやHTTPリクエストへのレスポンスなど、レスポンスを非同期で取得する組込みのメカニズムがある場合、これは自然に行われます。ただし、トランスポート・プロバイダで、レスポンスを非同期で取得する組込みのメカニズムがない場合は、ブロック方式でアウトバウンド・リクエストを実行し、TransportManagerHelper.schedule()メソッドを使用して、新しいワーカー・スレッドをスケジュールできます。この場合、レスポンスはTransportSendListenerにポストされます。

40.4.2 メッセージの変換

Service Busで、リクエスト・ペイロードをアウトバウンド・メッセージに設定するかまたはレスポンス・ペイロードをインバウンド・メッセージに設定する必要がある場合、Sourceインタフェースから派生したオブジェクトを介して設定を行うようにトランスポート・プロバイダに依頼します。トランスポート・プロバイダでは、基底のトランスポート・レイヤーで必要な表現を決定し、Transformer.transform()メソッドを使用して、Sourceオブジェクトを目的のソースに変換する必要があります。

ヒント:

メッセージ変換の詳細は、「メッセージ・コンテンツの設計」を参照してください。組込み変換のリストは、「組込みのトランスフォーメーション」および「SourceおよびTransformerクラスとインタフェース」を参照してください。

カスタム・トランスポート・プロバイダでは、新しい種類のトランスフォーメーションをサポートできます。アウトバウンド・メッセージを送信するために、トランスポート・プロバイダがDOMオブジェクトを使用する必要があるとします。setRequestPayload(Source src)で呼び出された場合、トランスポート・プロバイダは、次のメソッドを呼び出す必要があります。

TransportManagerHelper.getTransportManager().getTransformer().
transform(src, DOMSource.class, transformOptions)

メソッドの戻り値はDOMSourceで、DOMノードを取得する際に使用されます。

注意:

トランスポート・プロバイダでストリームが必要な場合は、簡単な方法を使用できます。各Sourceオブジェクトでは、ストリームへのトランスフォーメーションをネイティブにサポートしています。

新しいトランスフォーメーションをカスタム・トランスポート・プロバイダに追加できます。たとえば、XYZSourceと呼ばれる、新しい種類のSource派生クラスを追加するとします。パフォーマンス上の理由から、トランスポート・プロバイダではXYZSourceから2つの標準SourceオブジェクトXmlObjectSourceおよびStreamSourceのいずれかへの変換を提供することをお薦めします。このような変換を行わない場合は、XYZSourceのStreamSource表現に基づいた汎用トランスフォーマが使用されます。もちろん、XYZSourceが内部構造を持たない単純なバイト・ベースのSourceである場合は、通常は、汎用トランスフォーマで十分です。TransportManagerに登録されているカスタム・トランスフォーマは、スレッド・セーフかつステートレスであることが前提です。

添付ファイルをサポートする場合、トランスポート・プロバイダには次の3つのオプションがあります。

- TransportMessageContextが返すSourceは、MessageContextSourceのインスタンスである必要があります。このオプションには、MessageContextSourceでは、コンテンツがすでにコア・メッセージSourceと添付ファイルSourceに区分されている必要があるという制約があります。

- SourceはMimeSourceのインスタンスで、Headersオブジェクトにはマルチ・パートContent-Typeヘッダーが含まれています。

- Content-Typeは、固有の値multipart/relatedを持つ、トランスポート・プロバイダに事前定義されたヘッダーです。HTTPトランスポートと電子メール・トランスポートはいずれも、この3つ目のオプションに基づいて添付ファイルをサポートします。

40.4.3 TransportOptionsの操作

TransportOptionsオブジェクトは、メッセージを送受信する際のオプションを指定するために使用されます。TransportOptionsオブジェクトは、インバウンド・メッセージの場合、トランスポート・プロバイダからトランスポート・マネージャに渡されます。アウトバウンド・メッセージの場合は、TransportOptionsオブジェクトは、Service Busランタイムからトランスポート・マネージャに渡され、最後にトランスポート・プロバイダに渡されます。

40.4.3.1 インバウンド処理

トランスポート・プロバイダは、TransportManager.receiveMessage()に次のパラメータを提供します。

- QOS: exactly-onceまたはbest-effortのサービス品質を指定します。exactly-onceのサービス品質は、着信メッセージがトランザクション対応の場合に指定されます。

- エラー発生時にスロー: このフラグを設定すると、Service Busのパイプラインの処理中にエラーが発生した場合に、メソッドTransportManager.receiveMessage()の呼ばれた側に対して、例外がスローされます。例外スローのオプションには、インバウンド・メッセージに対して例外を返したり、エラーからレスポンス・メッセージを生成して、そのレスポンス・メッセージでインバウンド・メッセージに通知するものがあります。通常、QOSがexactly-once(トランザクション対応のメッセージ)の場合は、「エラー発生時にスロー」をtrueに設定します。
たとえば、JMS/XAではこのフラグをtrueに設定し、同じリクエスト・スレッドで例外をスローするため、例外をロールバックするようにマークできます。HTTPでは再試行のメカニズムがないため、このフラグをfalseに設定します。エラーがステータス・コードに変換され、レスポンス・メッセージが返されます。

- トランスポート固有の不透明なデータ: 不透明なデータは、トランスポート・プロバイダによって設定された任意のデータで、パイプラインを介してアウトバウンド呼出しに渡されます。この方法を使用すると、インバウンドとアウトバウンドで同じトランスポートを使用する場合に、パフォーマンスを最適化できます。不透明なデータは、パイプラインを介して、インバウンド・トランスポートからアウトバウンド・トランスポートに直接渡されます。たとえば、HTTPトランスポート・プロバイダでは、IDのパススルー伝播を効率的にサポートするために、ユーザー名とパスワードをインバウンドからアウトバウンドに直接渡すことができます。

40.4.3.2 アウトバウンド処理

アウトバウンド処理の場合、Service Busランタイムは、トランスポート・マネージャにパラメータを指定します。トランスポート・マネージャは、これらのパラメータのいくつかを内部的に使用し、TransportProvider.sendMessageAsync()に伝播します。これらのパラメータには、以下が含まれます。

- QOS: exactly-onceのサービス品質を実現可能かどうかを指定します。たとえば、HTTPでは、サービス品質をexactly-onceに設定している場合、HTTP呼出しはブロックされています。best-effortに設定している場合、HTTP呼出しはブロックされません。

- モード: 一方向または双方向(リクエスト/レスポンス)を指定します。詳細は、「トランスポート・プロバイダのモード」を参照してください。

- URI、再試行間隔、回数: トランスポート・プロバイダは、URIを使用してアウトバウンド・トランスポート接続を初期化します。たとえば、HTTPトランスポート・プロバイダは、新しいHttpURLConnectionをインストールする際にURIを使用します。トランスポート・プロバイダでは、再試行間隔および回数を使用する必要はありません。

- OperationName: トランスポート・プロバイダは、使用されているアウトバウンドWebサービスを認識する必要がある場合にOperationNameを使用します。トランスポート・マネージャは、このパラメータを使用してモニター統計を追跡します。

- トランスポート固有の不透明なデータ: トランスポート固有の不透明なデータの例としては、HTTPの認可ヘッダーの値があります。

40.4.3.3 リクエスト・モード

リクエスト・モードは、REQUEST_ONLY(一方向とも呼ばれる)およびREQUEST_RESPONSEの2つの値を持つ列挙値として定義されます。これらのモードは、リクエストおよびレスポンスについて次のように解釈されます。

- アウトバウンド・リクエストでは、パイプラインがTransportOptionsを介してモードを示し、トランスポート・プロバイダはそのモードを使用する必要があります。

- インバウンド・リクエストでは、パイプラインがモードを認識し、REQUEST_ONLYモードを算出した場合は、インバウンド・リクエストを閉じてレスポンスを送信しません。

- パイプラインがレスポンスを送信する場合は、レスポンスが空のときでもレスポンスが発生します。

- 本質的に一方向のトランスポートでは、トランスポートでレスポンス・メタデータを指定する必要はありません。

40.4.4 エラーの処理

実行時例外がトランザクション対応モデルに与える影響については、3つの異なるケースがあります。発生例を次に示します。

- ビジネス・サービスのアウトバウンド呼出しの前に、リクエスト・パイプラインで例外が発生します。

- ビジネス・サービスの呼出し中に、例外が発生します。

- ビジネス・サービスの呼出しの後に、レスポンス・パイプラインで例外が発生します。

40.4.4.1 発生例1: アウトバウンド呼出し前に例外が発生

この場合、図40-2に示すように、ビジネス・サービスのアウトバウンド呼出しの前に、例外がリクエスト・パイプラインで発生します。たとえば、リクエスト・メッセージのコンテンツに対して特定のXQueryを実行すると、例外が生成されます。

リクエスト・パイプラインにユーザー構成エラー・ハンドラを構成している場合、ユーザー構成に従ってエラーが処理されます。それ以外の場合は、引数としてreceiveMessage()呼出しに渡されるトランスポート・オプションに従って、プロキシ・サービスがTransportManager.receiveMessage()の呼出し時に例外を捕捉するか、レスポンス・メタデータを介してエラーのInboundTransportMessageContext.close()メソッドで通知されます。プロキシ・サービスが、例外をスローする必要があることを示している場合は、try/catch句でreceiveMessage()を囲み、トランザクションをロールバックするようにマークします。

図40-2 エラーの発生例1

40.4.4.2 発生例2: アウトバウンド呼出し中に例外が発生

この場合、図40-3に示すように、ビジネス・サービスの呼出し中に、例外が発生します。アウトバウンド・トランスポート・プロバイダでは、次の処理のいずれかが行われます。

- TransportProvider.sendMessageAsync()から例外をスローします。たとえば、外部サービスへのソケット接続を確立している最中にエラーが発生した場合、アウトバウンド・プロバイダは例外をスローします。このような状況は、誤ったURLや接続障害などのために、ビジネス・サービスを呼び出すことができない場合に発生します。この場合、トランスポート・プロバイダが例外を生成する必要があります。

- TransportSendListener.onError()を介して、リスナーに通知します。たとえば、ビジネス・サービスを呼び出したときに、呼出しがエラーになった場合(SOAPフォルトなど)、トランスポート・プロバイダは例外を生成するかわりにTransportSendListener.onError()を呼び出す必要があります。

最初の例では、「発生例1: アウトバウンド呼出し前に例外が発生」で説明したものと同じ例外処理が行われます。2つ目の例では、レスポンス・パイプラインにエラー・ハンドラを構成している場合、ユーザー構成に従ってエラーが処理されます。それ以外の場合は、InboundTransportMessageContext.close()のレスポンス・メタデータを介して、例外がプロキシ・サービス・エンドポイントに逆に伝播されます。

図40-3 エラーの発生例2

40.4.4.3 発生例3: アウトバウンド呼出し後に例外が発生

この場合、図40-4に示すように、ビジネス・サービスをコールした後、レスポンス・パイプラインで例外が発生します。レスポンス・パイプラインにユーザー定義のエラー・ハンドラがない場合、適切なレスポンス・メタデータを持つInboundTransportMessageContext.close()メソッドを使用して、エラーがプロキシ・サービス・エンドポイントに通知されます。インバウンド・トランスポート・エンドポイントが同期トランザクション・エンドポイントの場合、リクエストを受信したときにアクティブであったトランザクションがまだなおアクティブで、ロールバックできることが保証されます。インバウンド・エンドポイントがトランザクション対応でも同期型でもない場合、ロールバックするインバウンド・トランザクション・コンテキストがないため、他のアクションを実行する必要があります。

図40-4 エラーの発生例3

40.4.4.4 アプリケーション・エラーの捕捉

ビジネス・サービスが外部サービスへのアクセスを試行した時に、外部サービス・アプリケーションにSOAPフォルトなどのエラーが発生する場合、アプリケーションが修正されるまで、サービスによる後続の再試行によってエラーが発生します。Service Busによって、アプリケーション・エラーの識別が可能になり、トランスポートを使用するときにアプリケーション・エラーの再試行を回避するオプションが提供されます。

この項では、トランスポート内のアプリケーション・エラーを捕捉して、アプリケーション・エラーの再試行を回避できるようにトランスポートを構成する方法について説明します。

40.4.4.4.1 アプリケーション・エラーの識別

トランスポート・プロバイダのコードでは、アプリケーション・エラーが発生した条件を識別する必要があります。たとえば、HTTPトランスポートにおいて、アプリケーション・エラーとは、HTTPレスポンスに500ステータス・コードがあり、空でないペイロードがあり、サービス・タイプと一致するコンテンツ・タイプ(SOAP用XMLなど)を持つエラーです。エラーが定義されたアプリケーション・エラー条件を満たしている場合、次のメソッドの1つを用いて、「TRANSPORT_ERROR_APPLICATION」タイプを返します。

- リクエストでエラーが発生する: TransportProvider.sendMessageAsync()においてTRANSPORT_ERROR_APPLICATIONエラー・コードでTransportExceptionをスローします。

- レスポンスでエラーが発生する: TRANSPORT_ERROR_APPLICATIONエラー・コードを使用してTransportSendListener.onError()をスケジュールします。

トランスポートSDKは、発生したアプリケーション・エラーを識別して、それに応じて処理できます。トランスポートSDKは、アプリケーション・エラーをパイプラインの$fault変数に送信することもできます。

40.4.4.4.2 アプリケーション・エラーの再試行の構成

<Transport>Config.xmlファイルでは、/OSB_ORACLE_HOME/lib/modules/oracle.servicebus.kernel-api.jarのTransportCommon.xsdスキーマに準拠して、<ProviderConfiguration>要素の子として次の要素を入力します。

<declare-application-errors>true</declare-application-errors>

ユーザーがトランスポートを選択する場合、このエントリはビジネス・サービスのメインの「トランスポート構成」ページの「アプリケーション・エラーの再試行」オプションを提供します。この要素を入力しないと、デフォルト値はfalseで、アプリケーション・エラーを捕捉できず、アプリケーション・エラーの再試行オプションが提供されません。

40.4.4.5 接続エラーの捕捉

Service Busはトランスポートにある接続エラーを識別できます。これにより、アクセスできないエンドポイントURIを自動オフラインにするように、トランスポートSDKをトリガーします。たとえば、Service Busが管理対象サーバーで実行されているクラスタで、サービス・リクエストに対して接続エラーが発生した管理対象サーバーは、自動的にエンドポイントURIをオフラインとしてマークできます。

次の方法でエンドポイントURIを再有効化することができます。

- ビジネス・サービスを構成すると、接続エラー後に再試行の頻度と回数を決定するために再試行回数と再試行の反復間隔を設定できます。再試行により自動的にエンドポイントURIが再有効化された後の、サービスへの正常な接続。
再試行の反復間隔をゼロ(0)にすると、エンドポイントURIは無期限でオフラインになるため、手動で再有効化する必要があります。

- ビジネスサービスのダッシュボード上のFusion Middleware Controlから、オフラインになっているエンドポイントURIを手動で再有効化できます。

自動化接続エラーの機能は次の状況に対して適用されません。

- サービス・パイプラインはエンドポイントURIを動的に$outbound/ctx:transport/ctx:uriに設定すると、トランスポートSDKは、エンドポイントURIが サービス構成に設定されていないので、URIをオフラインにできません。

- トランスポートSDKは接続ステータスを保持しません。サーバーを再起動すると、すべてのエンドポイントURIはオンラインと見なされます。

詳細は、『Oracle Service Busの管理』のビジネス・サービス用のエンドポイントURIの管理とモニターに関する項を参照してください。

40.4.4.5.1 接続エラーの識別

エラーがスローされた後、接続エラーは、自動で影響を受けるエンドポイントURIをオフラインにするようにトランスポートSDKを設定します。トランスポート・プロバイダのコードでは、接続エラーが発生した条件を識別する必要があります。たとえば、Service Bus HTTPトランスポートにおいて、接続エラーとは、エンドポイントURIで接続しようとするとき、HTTPレスポンスに404ステータス・コードがありまたはIOExceptionが発生するかを識別します。

例外が定義された接続エラー条件を満たしている場合、次のメソッドの1つを用いて、「TRANSPORT_ERROR_CONNECTION」タイプを返します。

- リクエストでエラーが発生する: TransportProvider.sendMessageAsync()においてTRANSPORT_ERROR_CONNECTIONエラー・コードでTransportExceptionをスローします。

- レスポンスでエラーが発生する: TRANSPORT_ERROR_CONNECTIONエラー・コードを使用してTransportSendListener.onError()をスケジュールします。

これにより、トランスポートSDKは、接続エラーが発生したときにそのエラーを識別し、それに応じて処理できるようになります。また、トランスポートSDKは、接続エラーをパイプラインの$fault変数に送信し、それをレスポンスに追加します。

40.4.5 カスタム環境の値タイプの定義

トランスポートの実装に使用するカスタム環境の値タイプを定義できます。TransportProvider.getEnvValues()メソッドを使用してエンドポイントに対する環境値を返す際に、これらのカスタム・タイプの環境値を宣言できます。

トランスポートを使用した場合、構成をインポートした後、値をカスタマイズするか、検索して置き換えるか、保存するためにService Busで使用される標準的な環境値と同じようにカスタム環境の値タイプを使用できます。たとえば、トランスポート構成にあるサービス・アカウントまたはJMSキューにリファレンスを定義して保持することができます。環境値のタイプは環境、操作、およびセキュリティの3つのカテゴリに分けられます。

カスタム変数は<Transport>Config.xmlファイルに追加します。XML構造を決定するスキーマはTransportCommon.xsdで、/OSB_ORACLE_HOME/lib/servicebus-schemas.jarにあります。

次に示すのは、JMSトランスポートのJmsConfig.xmlにあるカスタム・セキュリティ変数の例です。

<env-value-type>
<name>JMS Service Accounts</name>
<localized-display-name>
<localizer-class>com.bea.wli.sb.transports.messages.
TransportsTextLocalizer</localizer-class>
<message-id>JMS_SERVICE_ACCOUNTS</message-id>
</localized-display-name>
<localized-description>
<localizer-class>com.bea.wli.sb.transports.messages.
TransportsTextLocalizer</localizer-class>
<message-id>JMS_SERVICE_ACCOUNTS</message-id>
</localized-description>
<simple-value>true</simple-value>
<category>security</category>
</env-value-type>

カスタム環境の値タイプに関する主要な要素の説明は、次のとおりです。

- name:トランスポートSDKで使用する変数名です。

- display-name: Service Busユーザー・インタフェースに表示する変数名です。次に、ローカライゼーションの代替手段を示します。

- localized-display-name: display-nameの代替のローカライズされたバージョン。

- localizer-class:ローカライズされたdisplay-nameを含むローカライゼーション・プロパティのテキスト・ファイル。.properties拡張子は必須ではありません。

- message-id: 表示名の値を提供するローカライゼーション・プロパティ・ファイルにあるプロパティ。

- description: 環境値タイプの説明。ローカライゼーションでは、display-nameで説明されているlocalizer-classとmessage-idの子要素のかわりにlocalized-description要素を使用します。

- simple-value: 環境値タイプが「環境」カテゴリである場合、simple-valueはService Busの検索と置換の機能を使用してこのタイプを検索できるかを決定します(trueまたはfalseの値)。

- category: 環境、セキュリティまたは操作の任意の環境値のカテゴリ。カテゴリがセキュリティまたは操作である場合、構成をインポートするときに環境値のタイプを保持するかどうかを決定できます。カテゴリが環境である場合、環境値のタイプを、検索および置換に使用できます。

40.4.6 UDDIレジストリへのプロキシ・サービスのパブリッシュ

UDDI (Universal Description, Discovery, and Integration)は、インターネット全体にわたるWebサービスを説明および検索するための標準のメカニズムです。カスタム・トランスポート・プロバイダに基づいて、プロキシ・サービスをUDDIレジストリにパブリッシュできます。これにより、ビジネス・サービスをホストするサービスからプロキシ・サービスを異なるドメインのService Busサーバーにインポートできます。

プロキシ・サービスをパブリッシュするには、トランスポート・プロバイダは、TransportProviderConfiguration XMLスキーマ定義のUDDIセクションで、トランスポートのタイプを表すtModelを定義する必要があります。このtModelには、CategoryBagおよびkeyedReferenceが含まれている必要があります。また、keyedReferenceでは、tModelKeyがUDDIタイプのカテゴリ・システムに設定され、keyValueがtransportになっている必要があります。このtModelでは、UDDI V3 tModelキーのみ指定する必要があります。UDDIがこのトランスポートのタイプにtModelを定義している場合は、定義をコピーして、UDDIセクションに貼り付けてください。(スキーマで生成されるインタフェースの詳細は、「スキーマで生成されるインタフェース」を参照してください)。

次の例は、そのようなtModelの例を示します。

tModelの例

<?xml version="1.0" encoding="UTF-8"?>
<ProviderConfiguration xmlns="http://www.bea.com/wli/sb/transports">
. . .
. . .
<UDDI>
<TModelDefinition>
<tModel tModelKey="uddi:bea.uddi.org:transport:socket">
<name>uddi-org:socket</name>
<description>Socket transport based webservice</description>
<overviewDoc>
<overviewURL useType="text">
http://www.bea.com/wli/sb/UDDIMapping#socket
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference keyName="uddi-org:types:transport"
keyValue="transport"
tModelKey="uddi:uddi.org:categorization:types"/>
</categoryBag>
</tModel>
</TModelDefinition>
</UDDI>
</ProviderConfiguration>

UDDIがこのトランスポートのタイプにtModelを定義していない場合、Service Busは、構成されたレジストリに、ここで定義するtModelをパブリッシュできます。Service BusにUDDIレジストリを構成している場合、「tModelsをレジストリにロード」オプションを指定できます。このオプションにより、カスタム・トランスポート・プロバイダのtModelを含め、Service BusのすべてのtModelが、UDDIレジストリにパブリッシュされます。トランスポート・プロバイダをデプロイすると、UDDIレジストリの構成を更新して、tModelをパブリッシュできます。

UDDIのエクスポート中に、TransportProvider.getBusinessServicePropertiesForProxy(Ref)が呼び出され、生成されたマップがUDDIレジストリにパブリッシュされます。UDDIのインポート処理中に、情報が失われることなくビジネス・サービスの定義を正確に作成できるよう、プロバイダは、ビジネス・サービスの重要なプロパティすべてをマップ内に確実に保持します。

UDDIのインポート中に、TransportProvider.getProviderSpecificConfiguration(Map)が呼び出され、プロバイダ固有のエンドポイント構成スキーマに準拠するXmlObjectが生成されて、サービス定義に含められます。

40.4.7 TransportWLSArtifactDeployerの実装が適している場合

個々のサービス登録を処理する、2セットのトランスポート・プロバイダ・インタフェースが用意されています。TransportProviderには、作成、更新、削除、サスペンド、再開などのメソッドがあります。また、TransportWLSArtifactDeployerにも同じメソッドがあります。この項では、これら2つの実装について説明します。また、TransportWLSArtifactDeployerを実装する必要がある場合についても説明します。

TransportWLSArtifactDeployerを実装するのは、プロバイダが、Oracle Service BusドメインのOracle WebLogic Serverアーティファクトを変更する必要がある場合のみです。TransportWLSArtifactDeployerのメソッドは、管理サーバーでのみ呼び出すことができます。この場合、渡されたDomainMBean引数を使用して変更が行われ、クラスタ全体に変更が伝播されます。

TransportProviderメソッドは、ドメインのすべてのサーバー(管理サーバーおよび管理対象サーバー)で呼び出されます。管理対象サーバーでService Busドメインのアーティファクトは変更できないため、TransportProviderのメソッドを呼び出すのは、内部データ構造を更新する場合のみです。

特定のトランスポート・プロバイダがTransportWLSArtifactDeployerインタフェースを実装する場合、TransportProviderの対応するメソッドが呼び出される前に、TransportWLSArtifactDeployerのメソッドが呼び出されます。たとえば、TransportProvider.createEndPoint()が呼び出される前に、TransportWLSArtifactDeployer.onCreate()が呼び出されます。TransportWLSArtifactDeployerの詳細は、「汎用インタフェースのサマリー」を参照してください。

40.5 カスタム・トランスポートのヘルプの作成

JDeveloperおよびOracle Service Busコンソールの両方で、カスタム・トランスポートのオンライン・ヘルプを提供できます。どちらの場合も、独自の統合ヘルプ・システムが用意されます。JDeveloperでは、ヘルプを既存のヘルプ・システムに組み込む必要があります。Oracle Service Busコンソールでは、図40-5に示すように、カスタム・トランスポートのヘルプ単体を独自のブラウザ・ウィンドウで表示します。カスタム・トランスポートのヘルプは、サービス定義エディタのトランスポート構成ページで「ヘルプ」アイコンをクリックすると表示されます。ヘルプの提供は省略可能です。しかし、ヘルプを提供することで、サービスの作成者に転送の構成プロセスを説明する際に非常に役立つ場合があります。

図40-5 Service Busコンソールから表示したカスタム・トランスポートのヘルプ

40.5.1 カスタム・トランスポート・オンライン・ヘルプについて

グラフィックスを含まない1つの単純なテキスト・ページから、多数のグラフィックス、PDFファイル、埋め込みのビデオなどを含む複数のページまで、提供するヘルプ・コンテンツのタイプを非常に柔軟に決定できます。たとえば、単一のHTMLファイルを作成し、そのファイルをヘルプ・リンクから参照できます。つまり、ビジネス・サービスおよびプロキシ・サービスのトランスポート構成フィールドについて説明し、さらに概要も示すヘルプ・ファイルを個別に作成できます。Oracle Service BusコンソールおよびJDeveloperに対して個別のヘルプ・トピックを作成するか、同じトピックを使用できます。

Service Busでは、サンプルのヘルプ実装をそのサンプル・ソケット・トランスポートに用意しています。これは、OSB_ORACLE_HOME/samples/servicebus/sample-transportにあります。サンプル・トランスポートは、独自のカスタム・トランスポートおよびヘルプを開発する上で良い参考となる実装です。

40.5.2 コンソールでのカスタム・トランスポートのヘルプの提供方法

この項では、Oracle Service Busコンソールで実行時にカスタム・トランスポートのヘルプを提供する方法を示します。Service Busは、図40-5に示されているように、カスタム・トランスポートのヘルプを、ブラウザで独立したヘルプ・ページとして表示します。

図40-6は、カスタム・トランスポートのコンソール・ヘルプ・フレームワークの概要図を示しています。

図40-6 Oracle Service Busコンソール・ヘルプ・フレームワーク

特定のService Busインタフェースを実装することにより、ユーザーがコンソールでカスタム・トランスポート構成ページの「ヘルプ」アイコンをクリックすると、getHelpPage()メソッドを使用して単一のHTMLページが起動します。HTMLファイルには、次の内容を含めることができます。

- テキスト、インラインCSS定義、インラインJavaScript関数

- グラフィックスおよびその他のリソースへの参照。これは、これらのリソースがWebアプリケーションまたは外部Webサイトでホストされている場合に限ります。

ほとんどの場合、カスタム・トランスポートのすべてのヘルプにテキストおよびインライン形式を含めることができます。

ただし、グラフィックスおよびその他の外部リソースを含むすべての機能を備えたWebベースのヘルプを提供する場合は、それらのリソースがWebアプリケーションまたは外部Webサイトでホストされている必要があります。それらの外部リソースをHTMLファイルで参照するか、または、HTMLファイルから外部の場所へのリンクを提供する必要があります。たとえば、サンプル・ソケット・トランスポートのヘルプでは、最初のHTMLファイルから、カスタムWebアプリケーションで実行されているグラフィックスを含むヘルプ・トピックへのリンクを提供しています。埋め込みのJavaScript呼出しを使用して、希望する拡張されたヘルプのURLに自動的にリダイレクトするようにHTMLファイルをセット・アップすることもできます。

次のタスクを実行して、コンソールでオンライン・ヘルプを実装します。

- CustomHelpProviderインタフェースの実装

- 起動するHTMLファイルの作成

- 拡張されたヘルプを表示する簡単なWebアプリケーションの作成(オプション)

ヘルプ・ファイルの作成が終了したら、「トランスポート・プラグインのヘルプのパッケージ化」の説明に従い、ファイルをパッケージ化します。

40.5.2.1 CustomHelpProviderインタフェースの実装

カスタム・トランスポートの構成ユーザー・インタフェースを開発するには、TransportUIBindingインタフェースをカスタム・クラスに実装します。Oracle Service Busコンソールでトランスポート構成のユーザー・インタフェースのヘルプを提供するには、CustomHelpProviderインタフェースも実装する必要があります。CustomHelpProviderには、Oracle Service Busコンソールでトランスポート構成ページのヘルプを起動するために必要なgetHelpPage()メソッドが含まれます。

サンプル・ソケット・トランスポートでは、OSB_ORACLE_HOME/samples/servicebus/sample-transport/src/com/bea/alsb/transports/sockにあるSocketTransportUIBindingクラスでCustomHelpProviderを実装します。

次の例には、CustomHelpProviderの実装を示すスニペットが含まれています。

例 - コンソール・オンライン・ヘルプを提供するCustomHelpProviderの実装

public class SocketTransportUIBinding
implements TransportUIBinding, CustomHelpProvider {
...
public Reader getHelpPage() {
String helpFile = "help/en/contexts_socketTransport.html";
ClassLoader clLoader = Thread.currentThread().getContextClassLoader();
InputStream is = clLoader.getResourceAsStream(helpFile);
InputStreamReader helpReader = null;
if(is!=null)
helpReader = new InputStreamReader(is);
else
SocketTransportUtil.logger
.warning(SocketTransportUtil.formatText(uiContext.getLocale(), "800138"));
return helpReader;
}
}

前述の例では、getHelpPage()によって、Oracle Service BusコンソールがブラウザにHTMLページを送信するために使用するReaderストリームが返されます。helpFileのパスは、トランスポートJAR内のルートからの相対パスです。

複数の言語でヘルプを提供する場合は、ローカライズされたコンテンツへの適切なパスの提供に役立つTransportUIContext.getLocale()を使用します。この場合は、/help/<locale>/<localized>.htmlにロケールの値を指定します。

40.5.2.2 起動するHTMLファイルの作成

CustomHelpProviderインタフェースの実装の例のhelp/en/contexts_socketTransport.htmlで示すように、起動するためのgetHelpPage()メソッドのHTMLファイルを作成できます。ヘルプの実装を簡潔に維持する場合は、テキスト、インラインCSS定義、およびインラインJavaScript関数を使用するHTMLファイルを作成してください。こうすることで、グラフィックスまたはその他の外部リソースをホストする個別のWebアプリケーションを作成する必要がなくなります。

ただし、グラフィックスやその他のリソースを含むように拡張したヘルプを作成する場合は、それらの外部リソースを次のようにHTMLファイルで参照してください。

img src="/help_socket/help/en/wwimages/addProject.gif"

または

a href="http://www.yoursite.com"

次の例で示されているように、埋込みのJavaScriptコールを使用して、拡張されたヘルプに自動的にリダイレクトするようにHTMLファイルを設定することもできます。この例では、サンプル・ソケット・トランスポートのHTMLページから、拡張されたhelp_socket Webアプリケーションのヘルプ・コンテンツにリダイレクトしています。

例 - リダイレクトを提供するJavaScript関数

<script language="JavaScript" type="text/javascript">
<!-- Begin
window.location="/help_socket/help/en/example.html";
// End -->
</script>

サンプル・ソケット・トランスポートのHTMLファイルが、拡張されたヘルプへのリンクを提供しています。HTMLファイルcontexts_socketTransport.htmlは、OSB_ORACLE_HOME/samples/servicebus/sample-transport/resources/help/en/にあります。

40.5.2.3 拡張されたヘルプを表示する簡単なWebアプリケーションの作成(オプション)

トランスポートのヘルプで基本的なテキストのHTMLファイル以上のものが必要な場合は、次の様々な方法を使用して、グラフィックスやその他のリソースを含めた拡張ヘルプを提供することができます。

- 自己完結型のHTMLファイルから既存のURLにリンクします(トランスポートに関するドキュメントを含む既存のWebサイトがある場合など)。必要な作業は、自己完結型のHTMLファイルからURLへのリンクの提供のみです。外部サイトでホストされているグラフィックスやその他のリソースへの参照を挿入することもできます。

- 拡張されたヘルプ用のWebアプリケーションを作成し、そのアプリケーションをトランスポートにバンドルしてそのリンクを設定するか、HTMLファイルからグラフィックスやその他のリソースを参照します。このトピックでは、トランスポートEARにバンドルして、拡張されたトランスポートのヘルプを表示するWebアプリケーションの作成手順について説明します。

Webアプリケーション用にMETA-INF/application.xmlおよびWEB-INF/web.xmlで説明したファイルを作成します。

40.5.2.3.1 META-INF/application.xml

application.xmlで、WebアプリケーションのルートURLに使用されるコンテキスト・ルートをWebアプリケーションに提供します。次の例は、ソケット・トランスポートWebアプリケーションの例のコンテキスト・ルートを示します。

例 - サンプル・ソケット・トランスポートのWebアプリケーションのapplication.xml

<application>
<display-name>Socket Transport</display-name>
<description>Socket Transport</description>
<module>
<web>
<web-uri>webapp</web-uri>
<context-root>help_socket</context-root>
</web>
</module>
</application>

サンプル・ソケット・トランスポートのapplication.xmlファイルは、OSB_ORACLE_HOME/samples/servicebus/sample-transport/META-INF/にあります。

このエントリは、ファイル・システムのディレクトリ/webappを別名のWebアプリケーションのルートURLにマップします。

http://server:port/help_socket/

ヘルプ・ファイルが、/help/en/などのディレクトリのWebアプリケーション内にある場合、拡張されたヘルプの完全なURLは次のようになります。

http://server:port/help_socket/help/en/index.html

ただし、ヘルプへの内部リンクの場合は、単に次のようになります。

/help_socket/help/en/index.html

ここで、index.htmlは、リンク先のHTMLページです。

40.5.2.3.2 WEB-INF/web.xml

web.xmlで、Webアプリケーションの表示名および説明を入力します。これは、標準のデプロイメント記述子情報です。次の例は、ソケット・トランスポートWebアプリケーションの例の名前および説明を示します。

例 - サンプル・ソケット・トランスポートのWebアプリケーションのweb.xml

<web-app>
<display-name>Sample Socket Transport Help WebApp</display-name>
<description>
This webapp implements the help webapp for the socket transport.
</description>
</web-app>

サンプル・ソケット・トランスポートのweb.xmlファイルは、OSB_ORACLE_HOME/samples/servicebus/sample-transport/webapp/WEB-INF/にあります。

40.5.2.3.3 ヘルプ・コンテンツとリソース

拡張されたヘルプ・ファイルを作成し、Webアプリケーション・ディレクトリ内にパッケージ化します。サンプル・ソケット・トランスポートでは、ヘルプ・ファイルはOSB_ORACLE_HOME/samples/servicebus/sample-transport/resources/help/enに格納されています。

注意:

ソケット・トランスポートのヘルプ・ファイルが/webappディレクトリに格納されてない理由は、helpディレクトリにJDeveloperとOracle Service Busコンソールの両方のヘルプ・ファイルとリソースが格納されているためです。サンプル・ソケットのANTビルドが、トランスポートJARおよびトランスポートEARを作成する場合は、ヘルプは別の方法でパッケージ化されます。トランスポートEARのビルドの場合、ヘルプ・ファイルは/webappディレクトリの下に移動します。

40.5.3 JDeveloperでのカスタム・トランスポートのヘルプの提供方法

カスタム・トランスポートをJDeveloperのサービス構成で使用できるようにする場合、サービス定義エディタに表示されるページのヘルプ・トピックを組み込むことができます。このためには、既存のヘルプJARファイルにヘルプ・ファイルを追加します。

JDeveloperでオンライン・ヘルプを提供するには:

1. ヘルプ・トピックを作成します。詳細は、「カスタム・トランスポート・オンライン・ヘルプについて」および「コンソールでのカスタム・トランスポート・ヘルプの提供方法」を参照してください。

2. すべてのヘルプ・ファイルをパッケージ化します。「トランスポート・プラグインのヘルプのパッケージ化」を参照してください。

3. MW_HOME/osb/plugins/jdeveloper/doc/studio_docに移動します。

4. osbjh.jarのバックアップ・コピーを作成します。

5. osbjh.jarのファイルを一時ディレクトリに抽出します。

6. ヘルプ・ファイル・システムの構造を維持しながら、作成したサンプル・トランスポート・ヘルプ・ファイルを一時ディレクトリにコピーします。ファイルは、サブディレクトリまたは同じレベルに既存のf1*.htmlファイルとしてコピーできます。

7. 一時ディレクトリでmap.xmlを開き、使用できるようにするヘルプ・トピックごとにmapIDエントリを追加します。

マップIDには、ヘルプ・トピックごとのターゲット(ID)とURL (相対パスとファイル名)、および説明が含まれます。次に、サンプル・ソケット・トランスポート・プロバイダの例を示します。

<mapID target="contexts_socketTransport" url="example.html" />
<!-- "Sample Sockets Transport Configuration"-->

8. マップ・ファイルを保存して閉じてから、すべてのヘルプ・ファイルをJAR形式で新しいosbjh.jarファイルに保存します。

9. MW_HOME/osb/plugins/jdeveloper/doc/studio_doc.の古いosbjh.jarファイルを、作成した新しいosbjh.jarファイルに置き換えます。

40.5.4 トランスポート・プラグインのヘルプのパッケージ化

トランスポート・プラグインには、次のものが含まれている必要があります。

- トランスポート・クラスおよびサポート・ファイルを含むトランスポートJARファイル。JARファイルには、/help/enディレクトリのヘルプ・リソースが含まれます。

- /webapp/help/enディレクトリのヘルプ・リソースなどの実行時コンポーネントを含むトランスポートEARファイル。

/enディレクトリを使用して、ローカライゼーションをサポートするようにヘルプがパッケージ化される点に注意してください。ローカライズを提供するには、ロケールごとにプラグインを作成する必要があります。トランスポートおよびヘルプのパッケージ化の詳細は、「カスタム・トランスポート・プロバイダのパッケージ化とデプロイ」を参照してください。

41 JDeveloper用のカスタム・トランスポート・プロバイダの開発

この章では、JDeveloperで使用するカスタムService Busトランスポートを開発するためのベスト・プラクティス、設計上の考慮事項およびパッケージ化について説明します。トランスポートSDKのインタフェースは、トランスポート・プロトコルとService Busランタイムの間の橋渡しを行います。

ヒント:

この章を始める前に、「カスタム・トランスポート・プロバイダについて」を確認してください。

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

- はじめに

- サービスのランタイムとサービスの構成

- JDeveloper用のトランスポートのパッケージ化

- オフライン・ツール用のカスタム・トランスポート・プロバイダ・リファレンス

41.1 概要

Service Busトランスポートは、元々はOracle Service Busサーバーにデプロイするように設計され、Oracle Service Busコンソールを使用して構成されています。JDeveloperのような設計環境では、SDKを一部変更し、トランスポート設計時機能をOracle Service Busコンソール以外のプラットフォームで使用できるようにする必要があります。

Service Busとともにインストールされているサンプル・ソケット・トランスポートは、JDeveloperに移植されており、JDeveloper統合のベスト・プラクティスとみなすことができます。サンプル・ソケットのリソースは、OSB_ORACLE_HOME/samples/servicebus/sample-transportにあります。Javaソース・ファイルは/srcサブディレクトリにあります。サンプルにはビルド・スクリプトも含まれており、JDeveloper統合とOracle Service Busコンソールデプロイメント両方のためにサンプル・ソケット・トランスポートを自動的にパッケージ化できます。サンプル・ソケット・トランスポートのビルドおよびデプロイについては、「サンプル・ソケット・トランスポート・プロバイダの作成」を参照してください。

41.2 サービスのランタイムとサービスの構成

トランスポートを開発する場合は、ランタイム・アスペクトと構成アスペクトを区別します。ランタイム・アスペクトには、プロキシ・サービスまたはビジネス・サービスのデプロイメントおよびサービスの実行時の呼出しが含まれます。構成アスペクトには、プロキシまたはサービスの構成と検証が含まれます。ランタイム・アスペクトは、Service Busサーバーが実行されている状況で常に実行されるため、変更する必要はありません。ただし、構成アスペクトは、設計環境に依存します。

開発者は、次の3種類のデプロイメント・モードを考慮する必要があります。

1. オンライン・モード: カスタム・トランスポートを使用するサービスが、実行中のService BusサーバーでOracle Service Busコンソールによって構成されます。

2. オフライン・モード: カスタム・トランスポートを使用するサービスが、Service Busサーバーの外部で実行されている設計環境を使用して構成されます。リモート・サーバーは使用できません。

3. オフライン・モード(リモート・サーバーあり): カスタム・トランスポートを使用するサービスが、Service Busサーバーの外部で実行されている設計環境を使用して構成されます。ただし、リモート・サーバーが利用可能であり、検証および構成の両方の目的に使用できます。

JDeveloperで実行されるトランスポートは、オフライン・モードと、必要に応じて、オフライン・モード(リモート・サーバーあり)をサポートする必要があります。

41.2.1 オフライン・メソッド

オフライン・モードでトランスポートをデプロイする場合、構成フレームワークは、すべてのリソースの構成用に1つのセッションを作成します。このセッションがアクティブ化されることはありません。プロキシ・サービスまたはビジネス・サービスは、実行中のService Busサーバーにしかデプロイできないため、セッションをアクティブ化する必要はありません。ただし、やはり競合および構成エラーの検出は重要であるため、検証メソッドは引続き実行されます。

次に、オフライン・モードで実装する必要がある、トランスポートSDKによって定義されているクラスおよびメソッドの最小セットのリストを示します。読みやすくするために、例外はメソッド・シグネチャから削除されています。

注意:

オフライン・モード用にトランスポートを完全に再実装する必要はありません。ほとんどの場合、トランスポートは、既存のメソッドにいくつかの変更を加えるだけで、オンライン・モードとオフライン・モードの両方をサポートできます。

オフライン・メソッドのために実装する必要があるクラスとメソッド

- public interface TransportProvider。特に次のメソッドです。

- String getId()

- void validateEndPointConfiguration(TransportValidationContext context)

- SchemaType getEndPointConfigurationSchemaType()

- SchemaType getRequestMetaDataSchemaType()

- SchemaType getRequestHeadersSchemaType()

- SchemaType getResponseMetaDataSchemaType()

- SchemaType getResponseHeadersSchemaType()

- TransportProviderConfiguration getProviderConfiguration()

- TransportUIBinding getUIBinding(TransportUIContext context)

- void shutdown()

- Collection<NonQualifiedEnvValue> getEnvValues(Ref ref, EndPointConfiguration epConfig)

- void setEnvValues(Ref ref, EndPointConfiguration epConfig, Collection<NonQualifiedEnvValue> envValues)

- Collection<Ref> getExternalReferences(EndPointConfiguration epConfig)

- void setExternalReferences(Map<Ref, Ref> mapRefs, EndPointConfiguration epConfig)

- Map<String, String> getBusinessServicePropertiesForProxy(Ref ref)

- XmlObject getProviderSpecificConfiguration(Ref ref, Map<String, String> props)

- public interface TransportProviderFactory
このインタフェースは、トランスポートをオフライン・モードで登録します。詳細は、「カスタム・トランスポート・プロバイダのパッケージ化とデプロイ」を参照してください。

- public interface TransportUIBinding
このインタフェースですべてのメソッドを実装して、プロキシ・サービスまたはビジネス・サービスの構成に使用されるユーザー・インタフェースを定義します。

ヘルパー・クラス

- public class TransportManagerHelper
このクラスは、通常はTransportProviderの開発者によって使用されます。プロバイダを実装する際にコードがオフラインで実行しているかどうかを判別するためのboolean isOffline()メソッドを提供します。オフライン・モードで無効な一部のメソッドは次のように例外をスローします。他のメソッドは、public isAdmin()のようにランタイムまたはデプロイメントのみに対応します。

オフライン・モード(リモート・サーバーあり)で作業するときは次のメソッドも使用できます。

- public Set<String> getDispatchPolicies(JMXConnector connector)

- public DomainRuntimeServiceMBean getDomainRuntimeServiceMBean(JMXConnector connector)
詳細は、「オフライン(リモート・サーバーあり)での作業」を参照してください。

オフライン・モードでは、次のメソッドは呼び出さないでください。

- public static boolean isAdmin()
このメソッドは、java.lang.IllegalStateExceptionメッセージをスローします。

- public static boolean clusterExists()
このメソッドは、常にfalseを返します。

注意:

ランタイムのステータスをチェックするための推奨メソッドは、isRuntimeEnabled()とgetRuntimeServers()を組み合せて使用することです。

41.2.2 オフラインで作業する場合の制限

オフラインで作業する場合、サーバー上で実行されているWebLogic Serverサービスは使用できません。「オフライン・メソッド」で説明されているメソッド内でこれらのサービスを使用しないでください。

次に、オフラインで作業する場合の制限の例を示します。

- Oracle WebLogic Server MBeansは使用できません。

- サーバーJavaプロパティは使用できません。

- JNDIツリーに直接アクセスすることはできません。ただし、JNDIプロパティがサービス構成で定義されている場合は、それらの使用を試みることができます。

- サービスがクラスタまたはスタンドアロン・サーバーのどちらで実行されるのかを判断することはできません。

- Oracle WebLogic Serverセキュリティ・インフラストラクチャにはアクセスできません。

- サーバーにある静的なシングルトン・サービスにアクセスすることはできません。

一部のサービスが使用できないため、トランスポートのユーザー・インタフェースがどのように影響を受けるかを評価する必要があります。一般的に、ユーザー・インタフェースは、ユーザーが値をサーバー環境から取得しようとするかわりに、値を手動で構成できるだけの柔軟性を備えている必要があります。

たとえば、一部のトランスポートでは、TransportManagerHelperを使用し、ユーザーがリストから選択できるようにして、使用可能なワーク・マネージャ(ディスパッチ・ポリシー)項目のリストを取得します。ただし、オフライン・モードではMBeanが使用できないため、リストを設定することはできません。トランスポート・プロバイダには次の2つの選択肢があります。

1. ユーザーが正確なワーク・マネージャ名を入力できるようにします。この場合、オフラインで作業する際は、ユーザー・インタフェースを、リストではなくテキスト・ボックスに変更する必要があります。

2. より柔軟性の低いもう1つの選択肢は、デフォルトのワーク・マネージャのみを使用してリストを設定する方法です。サービスが実行中のService Busサーバーにプッシュされるときに、環境値の代入を使用してワーク・マネージャ名を切り替えることができます。

41.2.3 オフライン(リモート・サーバーあり)での作業

オフラインで作業する場合に、リモート・サーバーを使用できる場合があります。たとえば、JDeveloperでサービスを構成するときに、リモートのService Busサーバーを現在のプロジェクトに関連付けることができます。トランスポート・プロバイダは、Oracle WebLogic Server MBeanにアクセスして情報を取得することで、リモート・サーバーを利用することができます。このモードは、オンラインでの作業に似ていますが、コードがサーバーで実行されず、MBeanしか使用できないため、やはりいくつかの制限が適用されます。

リモート・サーバーを使用してオフラインで作業している場合、次の制約があります。

- サーバーJavaプロパティは使用できません。

- 「オフライン・メソッド」で説明されているように、多くのTransportManagerHelperメソッドは使用できません。

- JNDIツリーに直接アクセスすることはできません。ただし、JNDIプロパティがサービス構成で定義されている場合は、それらの使用を試みることができます。

- サーバーにある静的なシングルトン・サービスにアクセスすることはできません。

MBeanにアクセスするために、フレームワークは、TransportUIオブジェクトをリクエストするときまたはプロバイダに構成を検証するようにリクエストするときに、JMXConnectorのインスタンスを提供します。JMXConnectorはTransportUIContextまたはTransportValidationContextで使用できます。

JMXConnector connector = (JMXConnector)uiContext.get(TransportValidationContext.JMXCONNECTOR);

詳細は、「オフライン・ツール用のカスタム・トランスポート・プロバイダ・リファレンス」のサンプル・トランスポートを参照してください。

コネクタが存在しない場合、リモート・サーバーは使用できません。このコネクタ・オブジェクトはその後MBeanへのアクセスに使用できます。ヘルパー・メソッドがTransportManagerHelperに追加されたため、WorkManagerおよびWebLogic ServerドメインMBeanのリストを取得できます。

注意:

この動作は、オンライン・モードおよびオフライン・モード用に汎用化されています。TransactionManagerHelperで定義されているpublic static Set<String> getDispatchPolicies()メソッドは非推奨となるため、JMXConnectorをパラメータとして持つ同じメソッドで置き換える必要があります。置換えない場合、com.bea.wli.sb.transports.TransportExceptionエラーが表示されます。

41.2.4 オフライン・モードでのトランスポートのブートストラップ

オンライン・モードでは、トランスポートをEARファイルとしてパッケージ化し、Service Busサーバーにデプロイする必要があります。起動時にEARがロードされると、トランスポートは、起動イベントでコールバックを登録し、TransportProviderのインスタンスをTransportManagerに登録します。

オフライン・モードでは、トランスポートを登録するcom.bea.wli.sb.transports.TransportProviderFactoryというインタフェースがSDKで提供されます。トランスポートの開発者は、このインタフェースを実装し、デフォルトのコンストラクタをパブリックにする必要があります。このインタフェースは、「オフライン・ツール用のカスタム・トランスポート・プロバイダ・リファレンス」でサンプル実装とともに提供されています。

TransportProvideFactoryがインスタンス化された場合、トランスポートを(リモート・サーバーの有無にかかわらず)オフライン・モードで動作させる必要があると想定できます。

注意:

トランスポートがオフライン・モードで実行されているかどうかを判断するためにコンストラクタが呼び出されるときに、TransportManagerHelperでブール演算子を設定できます。この情報は、TransportUIContextおよびTransportValidationContextにも渡すことができます。この決定に際しては、技術部門に支援を受けることができます。

41.3 JDeveloper用のトランスポートのパッケージ化

JDeveloperでカスタム・トランスポート・プロバイダを使用するためには、トランスポート・プロバイダを作成したときに生成したJARファイルをService Busインストールに追加する必要があります。JDeveloperプラグインとしてカスタム・トランスポートをパッケージ化し、同時にトランスポートのユーザー・インタフェースを実装することで、サービスの開発者が、開発環境でそのトランスポートを選択および構成できるようになります。

オフライン・モードでは、JDeveloperなど様々な設計環境でトランスポートを使用できます。一般的に、転送は、自己完結型のJARファイルとして、外部の設計時環境から使用できる必要があります。自己完結型のJARファイルでは、トランスポートのconfig.xmlファイル、ヘッダー、メタデータ・スキーマ、XBeanクラス、TransportProviderFactory実装およびコンパイル済のトランスポート・クラスが含まれます。

図41-1に、サンプル・ソケット・トランスポートの構成ページを含むJDeveloperのサービス・エディタ(サービス作成後)を示します。

図41-1 JDeveloperの「トランスポート構成」ページ

カスタム・トランスポート・プロバイダのパッケージ化およびデプロイの詳細は、「カスタム・トランスポート・プロバイダのパッケージ化とデプロイ」を参照してください。

注意:

TransportUIBindingインタフェースの実装によって、JDeveloperとOracle Service Busコンソールでの、トランスポートを選択および構成するためのユーザー・インタフェースが決まります。

41.4 オフライン・ツール用のカスタム・トランスポート・プロバイダ・リファレンス

ここでは、JDeveloperでオフライン・ツール用のカスタム・トランスポート・プロバイダを開発するときに認識している必要がある参考情報を説明します。

- 異なるモードでの動作

- TransportProviderFactory

- TransportManagerHelperメソッド

41.4.1 異なるモードでの動作

ほとんどのトランスポートでディスパッチ・ポリシーが使用されており、これによりサービスの抑制が可能になります。このコードは、「サービスのランタイムとサービスの構成」で説明されている、次の3つのモードを区別します。

- オンライン・モード

- オフライン・モード

- オフライン・モード(リモート・サーバーあり)

次の例で示しているように、リモート・サーバーへの接続はコンテキストから取得されます。

例 - リモート・サーバーへの接続

/**
* Builds the dispatch policies in the ui object.
*
* @param curDispatchPolicy
* @return TransportEditField containing existing dispatch policies.
*/
public TransportEditField getDispatchPolicyEditField(StringcurDispatchPolicy {
TransportUIFactory.TransportUIObject uiObject = null;
Set<String> wmSet = null;

if (SocketTransportManagerHelper.isOffline())
{ // if on JDeveloper try to get the MBeans from the UIContext
JMXConnector connector =
(JMXConnector)uiContext.get(TransportValidationContext.JMXCONNECTOR);
if (connector != null) {
try {
wmSet = TransportManagerHelper.getDispatchPolicies(connector);
} catch (Exception ex) {
wmSet = null;
}
}
} else { // if running on the server use the helper to get the policies
try {
wmSet = TransportManagerHelper.getDispatchPolicies();
} catch (TransportException transexcept) {
SocketTransportUtil.logger.error(SocketTransportMessagesLogger.noDispatchPolicies(),
transexcept);
}
}

if (wmSet == null) // if JMXConnector not available or impossible to connect provide a simple
edit field
{
uiObject = TransportUIFactory.createTextBox(curDispatchPolicy);
} else // create a drop down list
{   // adding default work manager to the list.
wmSet.add(DEFAULT_WORK_MANAGER);
String[] values = wmSet.toArray(new String[wmSet.size()]);
uiObject = TransportUIFactory.createSelectObject(values,values,curDispatchPolicy,
TransportUIFactory.SelectObject.DISPLAY_LIST,false);
}
return TransportUIFactory.createEditField(DISPATCH_POLICY,
TextMessages.getMessage(TextMessages.DISPATCH_POLICY,locale),
TextMessages.getMessage(TextMessages.DISPATCH_POLICY_INFO,locale), uiObject);
}

41.4.2 TransportProviderFactory

TransportProviderFactoryでは、JDeveloperで設計時機能が提供されます。これには、カスタム・トランスポート・プロバイダを登録するメソッドが含まれ、プロバイダ用に定義するIDを取得できます。このインタフェースで提供されるメソッドの詳細は、「Oracle Service Bus Java APIリファレンス」を参照してください。

サンプル・ソケット・トランスポートがこのインタフェースを実装する方法を次のサンプルに示します。

例 - インタフェースを実装するソケット・トランスポートの例

package com.bea.alsb.transports.sock;

import com.bea.wli.sb.transports.TransportManager;
import com.bea.wli.sb.transports.TransportException;
import com.bea.wli.sb.transports.TransportProviderFactory;

public class SocketTransportProviderFactory implements TransportProviderFactory
{

public void registerProvider(TransportManager tm) throws TransportException
{
SocketTransportProvider instance = SocketTransportProvider.getInstance();
tm.registerProvider(instance, null);
}

public String getId() {
return SocketTransportProvider.ID;
}
}

41.4.3 TransportManagerHelperメソッド

TransportManagerHelperクラスは、特にワーク・マネージャ(ディスパッチ・ポリシー)を取得するメソッドを提供します。このインタフェースで提供されるメソッドの一覧は、「Oracle Service Bus Java APIリファレンス」を参照してください。

42 カスタム・トランスポート・プロバイダのパッケージ化とデプロイ

この章では、Service Busで使用するためにカスタム・トランスポート・プロバイダをパッケージ化してデプロイする方法について説明します。

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

- トランスポート・プロバイダのパッケージ化

- トランスポート・プロバイダのデプロイ

- トランスポート・プロバイダのアンデプロイ

- クラスタへのデプロイ

42.1 パッケージ化とデプロイメントの概要

カスタム・トランスポート・プロバイダには、それぞれEARファイルとJARファイルの2つのファイルが必要です。3番目のファイルであるトランスポート・プラグインは、JDeveloperでカスタム・トランスポート・プロバイダを使用するために必要です。カスタム・トランスポート・プロバイダを、トランスポートを定義する自己完結型のJARファイルおよびWebLogic ServerにデプロイできるEARファイルとしてパッケージ化する必要があります。EARファイルは、JARファイルを含むことができ、また、JARファイルをEARファイルが依存するライブラリにすることもできます。後者の方法を使用すると、JARファイルの1つのコピーを維持することのみが必要になります。

Service Busでトランスポートを使用可能にするには、/MW_HOME/osb/lib/transportsにEARファイルをインストールし、オプションでJARファイルをインストールします。通常、EARファイルとJARファイルは両方とも、Service Busトランスポート用にこのディレクトリに配置されますが、JARファイルをここに配置する必要はありません。オフライン・ツールでカスタム・トランスポート・プロバイダを使用可能にするために作成するプラグイン・ファイルはJARファイルを指します。

Oracle Service Busコンソールおよびランタイムでトランスポートを使用できるようにするには、EARファイルをService Bus Kernel EARファイルおよびその他のService Bus関連アプリケーションとともにサーバーにデプロイします。サンプル・ソケット・トランスポート・プロバイダの例では、トランスポート・プロバイダを構成およびデプロイする方法を示しています。詳細は、「サンプル・ソケット・トランスポート・プロバイダの作成」を参照してください。

42.1.1 カスタム・トランスポート・プロバイダのコンポーネント

各トランスポート・プロバイダは、次の2つの異なるコンポーネントで構成されます。

- 構成: トランスポート・プロバイダの構成部分は、エンドポイントをトランスポート・プロバイダに登録するために、Oracle Service Busコンソールによって使用されます。この構成動作は、ユーザー・インタフェースの実装によって実行されます。詳細は、「ユーザー・インタフェースの構成」を参照してください。

- ランタイム: トランスポート・プロバイダの実行時部分は、メッセージを送受信するビジネス・ロジックを実装します。

構成部分と実行時部分が別のデプロイメント・ユニットに配置されるようにトランスポート・プロバイダをパッケージ化することをお薦めします。これにより、クラスタ・デプロイメントが容易になります。詳細は、「クラスタへのデプロイ」および「トランスポート・プロバイダのコンポーネント」を参照してください。

42.1.2 カスタム・トランスポート・プロバイダのリソース

トランスポートJARファイルには、次のリソースを含める必要があります。

- トランスポート・プラグインに関する重要な情報を含むMANIFEST.MFファイル。参考として、サンプル・ソケット・トランスポートのMANIFEST.MFを使用してください。

- トランスポート・プロバイダを構成するTransportConfig.xmlファイル。参考として、サンプル・ソケット・トランスポートのプラグインを使用してください。「ステップ5. TransportProviderConfiguration XMLBeanの定義」を参照してください。

- 使用するトランスポート実装を含むコンパイル済Javaクラス。

- コンパイル済XML Beanが生成したクラス。

- (オプション)オンライン・ヘルプを提供するためのリソース。

42.2 トランスポート・プロバイダのパッケージ化

ここでは、カスタム・トランスポート・プロバイダのJARファイルおよびEARファイルの構造を説明します。この項でリストするいずれかのファイルの例を表示するには、「サンプルのビルドとデプロイ」の説明に従ってサンプル・ソケット・トランスポート・プロバイダをビルドします。すべてのパッケージ化されたアーティファクトが表示できるようになります。サンプルのbuild.xmlファイルを確認して、カスタム・トランスポート・プロバイダのコンパイルおよびデプロイの方法の例を表示することも可能です。

42.2.1 トランスポートJARファイルのパッケージ化

トランスポート・プロバイダをJARファイルにパッケージ化して、トランスポートをポータブルにします。トランスポート・プロバイダをパッケージ化するには、次のガイドラインに従います。

- プラグインJARを構築するには、カスタム・トランスポートの名前に「transport」を付加してJARファイル名を作成します。たとえば、サンプル・ソケット・トランスポートJARファイルの名前はsock_transport.jarになります。

- 図42-1に示すように、次のディレクトリ構造でファイルをパッケージ化します。

- /com (トランスポート・クラスおよびリソース)

- /help
トランスポートのヘルプを提供する場合、「カスタム・トランスポートのヘルプの作成」の説明に従って、ヘルプ・リソースの/helpディレクトリを含めてください。

- /META-INF/MANIFEST.MF

- /schemaorg_apache_xmlbeans (XML Beanクラスおよびリソース)

- TransportConfig.xml (XMLBeanトランスポート・プロバイダ構成。詳細は「ステップ5. TransportProviderConfiguration XMLBeanの定義」を参照)

次の図は、サンプル・ソケット・トランスポート・プロバイダのJARディレクトリを示します。

図42-1 プラグインのパッケージ化

プラグインのパッケージ化の例を参照するには、「サンプル・ソケット・トランスポート・プロバイダの作成」の説明に従ってサンプル・ソケット・トランスポートをビルドします。生成されたsock_transport.jarおよびsock_transport.earを参照してください。

42.2.2 トランスポートEARファイルのパッケージ化

EARファイルでカスタム・トランスポート・プロバイダの実行時コンポーネントをパッケージ化します。これは、WebLogic Serverにデプロイできます。このファイルは、JARファイルを含むかまたはライブラリとしてJARファイルに依存できます。EARファイルの典型的なパッケージ化構造は次のものを含みます。

- APP-INF/lib/name-transport.jar

- META-INF/MANIFEST.FMおよび追加のスキーマ・ファイル。

- パッケージ化済ヘルプ・ファイルなど、追加のWebアプリケーション・ファイル

42.2.3 JDeveloper用のカスタム・トランスポート・プラグイン登録

JDeveloperが新しいトランスポートを取得するためには、トランスポート・プロバイダの実装、トランスポートID、ヘルプID (ある場合)およびトランスポートに必要な追加のライブラリを記述しているプラグイン・ファイルを作成する必要があります。JDeveloperでトランスポートを使用する計画がない場合、このファイルを作成する必要はありません。プラグイン・ファイルの命名規則は、transport-transport_name.xmlです。

次の形式を使用して、プラグイン登録ファイルを作成します。

<plugin xmlns="http://www.bea.com/alsb/offline/extensions">
<transport
class="transport_provider_class"
id="transport_id"
helpId="ID_to_access_help"/>
<libraries>
<library name='name_and_path_for_transport_jar'/>
</libraries>
</plugin>

次の例では、Service Busでインストールされたサンプル・ソケット・トランスポート・プロバイダに付属しているサンプル・プラグイン・ファイルを示します。

例 - サンプル・ソケット・トランスポート・プロバイダのプラグイン・ファイル

<plugin xmlns="http://www.bea.com/alsb/offline/extensions">
<transport
class="com.bea.alsb.transports.sock.SocketTransportProviderFactory"
id="socket"
helpId="contexts_socketTransport"/>
<libraries>
<library name='lib/transports/sock_transport.jar'/>
</libraries><
</plugin>

42.3 トランスポート・プラグインのインストール

トランスポート・プロバイダのEARファイル、JARファイル(およびオプションでJDeveloperのプラグイン)を作成したら、これらのファイルをJDeveloperのインストールに追加してJDeveloperで取得できるようにする必要があります。

- 生成されたEARファイルおよびJARファイルを/MW_HOME/osb/lib/transportsにコピーします。

- プラグイン登録ファイルを/MW_HOME/osb/config/pluginsにコピーします。

42.4 トランスポート・プロバイダのデプロイ

トランスポート・プロバイダのデプロイ可能なEARファイルを作成したら、Service Busドメインにデプロイする必要があります。次の方法のどれでもお好みの方法でEARファイルをデプロイできます。

- プログラムを実行します(WebLogic Deployment Manager JSR-88 APIを使用)。

- Oracle WebLogic Server管理コンソールを使用します。

- Service Busドメインconfig.xmlファイルに次の例のようなエントリを追加します

例 - アプリケーション・デプロイメント・エントリ

<app-deployment>
<name>My Transport Provider</name>
<target>AdminServer, myCluster</target>
<module-type>ear</module-type>
<source-path>$MW_HOME$/osb/lib/transports/mytransport.ear</source-path>
<deployment-order>6</deployment-order>
</app-deployment>

注意:

トランスポート・プロバイダのEARファイルのデプロイ順序は、トランスポート・プロバイダの前にすべてのService Bus Kernel EARがデプロイされるようにする必要があります。

42.4.1 トランスポートの登録

サーバーの再起動時に、デプロイしたトランスポートがすぐにサービス・リクエストの処理を開始できるようにする必要があります。トランスポートをすぐに使用できるようにするには、weblogic.application.ApplicationLifecycleListenerクラスを拡張し、preStart()メソッドを使用して、TransportManager.registerProvider()によってトランスポートを登録します。

実装例は、OSB_ORACLE_HOME/samples/servicebus/sample-transport/src/com/bea/alsb/transports/sockにあるサンプル・ソケット・トランスポートに付属しているApplicationListenerクラスを参照してください。ApplicationLifecycleListenerを拡張する際は、必ず拡張クラスをMETA-INF/weblogic-application.xmlに登録してください。サンプル・ソケット・トランスポートは、OSB_ORACLE_HOME/samples/servicebus/sample-transport/META-INF/weblogic-application.xmlで、次のApplicationListenerクラスのエントリを提供しています。

<weblogic-application>
<listener>
<!-- This class gives callbacks for the deployment lifecycle and socket
transport is registered with ALSB whenever the application is started.
-->
<listener-class>com.bea.alsb.transports.sock.ApplicationListener
</listener-class>
</listener>
</weblogic-application>

42.5 トランスポート・プロバイダのアンデプロイ

Service Busに登録されたトランスポート・プロバイダのアンデプロイメントまたは登録取消しはサポートされません。

42.6 クラスタへのデプロイ

トランスポート・プロバイダは、Service Busがデプロイされているすべてのサーバーとクラスタにデプロイする必要があります。つまり、Service Busが(常にデプロイ先である)管理サーバーにのみデプロイされる場合、トランスポート・プロバイダを管理サーバーにデプロイする必要があります。Service Busが管理サーバーのトポロジおよび管理対象サーバーのトポロジにデプロイされる場合、トランスポート・プロバイダを管理サーバーおよびその該当の管理対象サーバーにデプロイする必要があります。Service Busがクラスタにデプロイされる場合、トランスポート・プロバイダを管理サーバーおよびクラスタにデプロイする必要があります。Service Busは、ドメインのトポロジに関係なく必ず管理サーバーにデプロイされることに注意してください。

トランスポート・プロバイダのEARファイルにあるアプリケーション・コードは、トランスポートがどこにデプロイされているか(管理サーバーまたは管理対象サーバー)を動的に認識して、管理サーバーでは構成動作、管理対象サーバーでは実行時の動作のみを行う必要があります。

たとえば、some_transport.ear内の初期化疑似コードで、次のロジックを使用し、プロバイダの構成部分またはランタイム部分をアクティブにするかどうかを決定できます。

protected SomeTransportProvider() throws TransportException {
. . . some other initialization code . . .
if (!isRuntimeEnabled)
_engine = new RuntimeEngine(. . .);
}

この場合、RuntimeEngineクラスのインスタンスの作成は実行時の動作であるため、マルチサーバー・ドメインでは管理対象ノードでのみ、シングル・サーバー・ドメインでは管理ノードでのみ実行される必要があります。

さらに、クラスタ環境では、TransportProvider.createEndPoint()およびdeleteEndPoint()は、クラスタ内の管理対象サーバーのみでなく管理サーバー上でも呼び出されます(WLS HTTPルーター/フロントエンド・ホストを除く)。一部のトランスポート・プロバイダは、指定された構成(HTTPなど)を持つエンドポイントが存在するという事実の登録以外は何もしないことを選択できます。通常、トランスポート・プロバイダは、createEndPoint()またはdeleteEndPoint()が管理サーバーと管理対象サーバーのどちらで呼び出されたかを確認して適切な動作を決定する必要があります。

43 サンプル・ソケット・トランスポート・プロバイダの作成

この章では、サンプル・ソケット・トランスポート・プロバイダをビルドおよび実行する方法について説明します。このサンプルとソース・コードは、Service Busとともにインストールされます。このサンプルは、カスタム・トランスポート・プロバイダの実装例として使用できます。

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

- サンプル・ソケット・トランスポート・プロバイダの設計

- サンプルの場所とディレクトリ構造

- サンプルのビルドとデプロイ

- ソケット・トランスポートのサンプル・プロジェクトの作成

- ソケット・トランスポート・プロバイダのテスト

43.1 サンプル・ソケット・トランスポート・プロバイダの設計

サンプル・ソケット・トランスポート・プロバイダの主な目的は、トランスポート・プロバイダの実装例として機能することです。一般に公開されているこのサンプルでは、トランスポートSDKの実装および構成の詳細について説明します。

43.1.1 サンプルによって説明される概念

サンプル・トランスポートは、ストリーミングしたデータをService Busに構成されているTCPソケットとの間で送受信するために設計されています。サンプル・トランスポートでは、トランスポートSDKの次のような概念を示します。

- カスタム・トランスポートのビルドに必要な、トランスポートSDK APIのセットを実装します。

- 構成されたアドレスでリスニングするソケット・エンドポイントがないことを確認するなど、トランスポート・エンドポイントの検証を実行します。

- ソケット・プロパティ、メッセージ・パターンなど、様々なUI構成オプションを実装します。

- 一方向または同期型のリクエスト/レスポンス・メッセージ・パターンを実装します。

- エンドポイント・リクエスト/レスポンスのメタデータおよびヘッダーにPOJO (Plain Old Java Object)を使用します。

- Service Busパイプラインでストリーミングを使用します。

43.1.2 サンプルの基本アーキテクチャ

図43-1に、サンプル・ソケット・トランスポート・プロバイダの基本アーキテクチャを示します。どのクライアントでも、サーバー・ソケットに接続できます。データは、サーバー・ソケットで受信され、パイプラインを介して渡されます。レスポンスは、アウトバウンド・トランスポートを介して戻されます。レスポンスは、最後にインバウンド・トランスポートに返送され、クライアントに戻されます。

図43-1 サンプル・ソケット・トランスポートのアーキテクチャ

43.1.3 構成プロパティ

図43-2に、転送エンドポイントの構成のプロパティを示します。これらのプロパティは、スキーマ・ファイルSocketTransport.xsdで構成されています。このファイルの場所は、「サンプルの場所とディレクトリ構造」を参照してください。このファイルを使用すると、SDKの共通のスキーマに定義されている、基本的なプロパティ・セットを拡張できます。各プロパティは、SocketTransport.xsdファイルを参照してください。

ヒント:

これらの構成プロパティの詳細は、「ステップ4. トランスポート固有のアーティファクトの定義」を参照してください。

図43-2 SocketEndpointConfigurationのプロパティ

また、図43-3に示すように、SocketTransport.xsdファイルには、リクエスト・ヘッダー、レスポンス・ヘッダーおよびメタデータのプロパティが含まれています。これらのプロパティの詳細は、SocketTransport.xsdファイルを参照してください。

図43-3 リクエスト・ヘッダー、レスポンス・ヘッダーおよびメタデータの構成

43.2 サンプルの場所とディレクトリ構造

ここでは、サンプル・プロジェクトのいくつかの重要なフォルダについて簡単に説明します。このディレクトリ構造を、カスタム・トランスポート・プロバイダを開発する際のモデルとして使用できます。サンプル・ソケット・トランスポート・プロバイダはService Busにインストールされ、OSB_ORACLE_HOME/samples/servicebus/sample-transportディレクトリにあります。

表43-1に、重要なsample-transportディレクトリを示して、簡単に説明します。

表43-1 サンプル・トランスポート・プロバイダの重要なディレクトリ

ディレクトリ

説明

build

このディレクトリは、サンプル・ソケット・トランスポートをビルドするときに作成されます。Service Busで使用するビルド化およびパッケージ化されたトランスポートを含みます。

l10n

このディレクトリには、これらの国際化ファイルが含まれます。サポートされているロケールそれぞれにそれぞれのファイルがあります。

SocketTransportMessages.xml: Oracle Service Busコンソールに表示されるメッセージのための構成ファイルです。

SocketTransportTextMessages.xml: カスタム・トランスポート・フィールド名およびその説明のための構成ファイルです。

META-INF

このディレクトリには、これらのアプリケーション・デプロイメント・ディスクリプタ・ファイルが含まれます。

application.xml: J2EEアプリケーション記述子ファイル

weblogic-application.xml: WebLogicアプリケーション記述子ファイル

オフライン

このディレクトリには1つのファイルtransport-socket.xmlが含まれます。このファイルは完全修飾クラス名およびそのライブラリJARファイルの名前と場所を指定します。

resources

このディレクトリには、トランスポートSDKによって使用されるソケット・トランスポート・プロバイダの構成ファイルが含まれます。ファイル名はSocketConfig.xmlです。トランスポートのサンプル・ヘルプ・ファイルも含まれます。

スキーマ

このディレクトリには、このトランスポート用に定義された関連スキーマが含まれます(ここではSocketTransport.xsd)。このファイルは、ソケットのエンドポイント・リクエストとエンドポイント・レスポンスのメタデータおよびヘッダーを記述します。

src

このディレクトリには、サンプル・トランスポートのソース・ツリーが含まれます。

test

このディレクトリには、サンプル・トランスポート・プロバイダのテスト・ユーティリティおよびテスト・サーバーおよびクライアントのソース・ツリーが含まれます。

webapp

このディレクトリには、サンプル・トランスポート・ヘルプのWebアプリケーションで必要なデプロイメント記述子が含まれます。

次のAntビルド・ファイルも、sample-transportディレクトリに格納されています。

- build.properties - Antのプロパティ・ファイルです。

- build.xml - コンパイル、ビルド、およびデプロイ用の異なる対象を含むAntビルド・ファイルです。

43.3 サンプルのビルドとデプロイ

この項で示す手順を指定の順序で実行して、サンプル・トランスポート・プロバイダをビルドしてデプロイします。

- 環境の設定方法

- サンプル・トランスポート・プロバイダの構築方法

- サンプル・トランスポート・プロバイダのデプロイ方法

- サンプル・トランスポート・プロバイダのJDeveloperへの登録

43.3.1 環境の設定方法

Service Busドメインにスクリプトが指定され、サンプルをビルドするための環境を構成します。

環境を設定するには:

1. 新しいドメインを作成するか、Service Busとともにインストールされている、構成済のドメインの1つを使用します。

2. 次のスクリプトを実行して、ドメイン環境を設定します。

DOMAIN_HOME/bin/setDomainEnv.cmd (またはUNIXシステムのsetDomainEnv.sh)

43.3.2 サンプル・トランスポート・プロバイダの構築方法

環境構成を設定すると、sample-transportディレクトリにあるAntビルド・ファイルを使用してトランスポートをビルドできます。

サンプル・トランスポート・プロバイダをビルドするには:

1. コマンド・ウィンドウで、OSB_ORACLE_HOME/samples/servicebus/sample-transportに移動します。

2. 次のコマンドを実行します。

ant build

このコマンドにより、OSB_ORACLE_HOME/samples/servicebus/sample-transport/buildのソース・ファイルがコンパイルされます。

3. トランスポートが正常にビルドされてから、次のコマンドを実行します。

ant stage

sock_transport.earおよびsock_transport.jarがOSB_ORACLE_HOME/lib/transportsにコピーされ、transport-socket.xmlがOSB_ORACLE_HOME/config/pluginsにコピーされます。

43.3.3 サンプル・トランスポート・プロバイダのデプロイ方法

ソケット・サンプルは、サンプル・トランスポート・プロバイダをWebLogic Serverにデプロイする自動スクリプトも提供します。サンプルが正常にビルドされてステージングされると、デプロイ・コマンドを実行できます。

サンプル・トランスポート・プロバイダをデプロイするには:

1. 次の変数をsample-transport/build.propertiesに設定します。

wls.hostname

wls.port

wls.username

wls.password

wls.server.name

2. 次のコマンドを実行して、トランスポート・プロバイダをサーバーにデプロイします。

ant deploy

43.3.4 サンプル・トランスポート・プロバイダのJDeveloperへの登録

サンプル・ソケット・トランスポート・プロバイダを使用してJDeveloperにプロジェクトを作成またはインポートするには、トランスポート登録ファイルを変更する必要があります。

サンプル・トランスポート・プロバイダをJDeveloperに登録するには:

1. /MW_HOME/osb/config/pluginsに移動します。

2. XMLまたはテキスト・エディタでtransport-socket.xmlを開きます。

3. トランスポート要素で、次の属性を追加します。

id='socket'
helpId="contexts_socketTransport"

最終的なファイルは次のようになります。

<plugin xmlns="http://www.bea.com/alsb/offline/extensions">

<transport
class="com.bea.alsb.transports.sock.SocketTransportProviderFactory"
id="socket"
helpId="contexts_socketTransport"/>

<libraries>
<library name='lib/transports/sock_transport.jar'/>
</libraries>

</plugin>

4. ファイルを保存して閉じます。

5. JDeveloperを再起動します(実行中の場合)。

43.4 ソケット・トランスポートのサンプル・プロジェクトの作成

サンプルは、テスト・サーバーとテスト・クライアントで構成されています。クライアントは、サーバーにメッセージを送信します。メッセージを受信および処理するために、Service Busを構成します。

この項のタスクを指定の順序で実行します。これらの手順は、Oracle Service Busコンソールでサンプル・プロジェクトを作成するためのものですが、JDeveloperでも作成できます。

- プロジェクトの作成

- ビジネス・サービスの作成

- プロキシ・サービスの作成

- パイプラインの作成

- プロキシ・サービスとパイプラインの接続

43.4.1 プロジェクトの作成

サンプルを作成する最初の手順は、Service Busリソースを含める実際のプロジェクトを作成することです。

プロジェクトを作成するには:

1. Oracle Service Busコンソールを起動し、新しいセッションを作成するかまたは既存のセッションを編集します。

2. プロジェクト・ナビゲータで、「すべてのプロジェクト」を右クリックし、「作成」を指し、「プロジェクト」を選択します。

3. 「新規プロジェクトの作成」ダイアログで、「リソース名」フィールドに「SocketTest」と入力します。

4. 「作成」をクリックします。

プロジェクト定義エディタに新しいプロジェクトが表示されます。

43.4.2 ビジネス・サービスの作成

このサンプル・プロジェクトでは、サーバーと通信するビジネス・サービスを作成します。

ビジネス・サービスを作成するには:

1. プロジェクト・ナビゲータで、SocketTestプロジェクトを右クリックして、「作成」をポイントし、「リソース」を選択します。「ビジネス・サービス」、「テクノロジ」をクリックし、次に「ソケット」をクリックします。

「ビジネス・サービスの作成」ウィザードが表示されます。

図43-4 「ビジネス・サービスの作成」ウィザード

2. 「リソース名」フィールドに、「SocketBS」と入力します。

3. 「トランスポート」フィールドで、「ソケット」を選択します。「次」をクリックします。

4. 「サービス・タイプ」で、「任意のXMLサービス」を選択し、「次」をクリックします。

5. 「エンドポイントURI」フィールドで、デフォルトのURIをtcp://localhost:7031に変更します。

6. 「作成」をクリックします。

ビジネス・サービス定義エディタにビジネス・サービスが表示されます。様々なサブタブをクリックして、構成を表示できます。

7. 「保存」をクリックします。

43.4.3 プロキシ・サービスの作成

ここでは、クライアントからのメッセージを受け取るプロキシ・サービスを作成します。

プロキシ・サービスを作成するには:

1. プロジェクト・ナビゲータで、SocketTestプロジェクトを右クリックして、「作成」をポイントし、「リソース」を選択します。「プロキシ・サービス」、「テクノロジ」をクリックし、次に「ソケット」をクリックします。

「プロキシ・サービスの作成」ウィザードが表示されます。

図43-5 「プロキシ・サービスの作成」ウィザード

2. 「リソース名」フィールドに、「SocketProxy」と入力します。

3. 「トランスポート」フィールドで、「ソケット」を選択します。「次」をクリックします。

4. 「サービス・タイプ」で、「任意のXMLサービス」を選択し、「次」をクリックします。

5. 「エンドポイントURI」フィールドで、デフォルトのURIを7032に変更します。

6. 「作成」をクリックします。

プロキシ・サービス定義エディタにプロキシ・サービスが表示されます。様々なサブタブをクリックして、構成を表示できます。

7. 「保存」をクリックします。

43.4.4 パイプラインの作成

ビジネス・サービスとプロキシ・サービスを定義したので、着信メッセージをビジネス・サービスにルーティングするパイプラインを作成できます。

パイプラインを作成するには:

1. プロジェクト・ナビゲータで、SocketTestプロジェクトを右クリックして、「作成」をポイントし、「リソース」を選択します。「パイプライン」をクリックし、次に「OK」をクリックします。

パイプラインの作成ダイアログが表示されます。

2. 「パイプライン名」フィールドに、「SocketPipeline」と入力します。

3. 「サービス・タイプ」で、「任意のXMLサービス」を選択します。

4. プロキシ・サービスとして公開を選択解除します。

図43-6 パイプラインの作成ダイアログ

5. 「作成」をクリックします。

パイプライン定義エディタにパイプラインが表示されます。様々なサブタブをクリックして、構成を表示できます。

6. エディタの右上にある「メッセージ・フローを開く」アイコンをクリックします。

図43-7

「メッセージ・フローの編集」ウィンドウが表示されます。

7. **INTERNAL XREF ERROR**に示すとおり、SocketPipelineアイコンをクリックし、メニューから「ルートの追加」を選択します。

図43-8 メッセージ・フローの編集

8. RouteNode1アイコンをクリックし、「ルートの編集」を選択します。

9. **INTERNAL XREF ERROR**に示すとおり、「ステージ構成の編集」ウィンドウで「アクションの追加」をクリックし、「通信」→「ルーティング」を選択します。

図43-9 アクションの追加

10. 「ルーティング先」の横の、<Service>を選択します。

11. 「サービスの選択」ウィンドウで、リストからSocketBSを選択し、「発行」をクリックします。

12. 「ステージ構成の編集」ウィンドウで「保存」をクリックします。

13. 必要に応じて、RouteNode1アイコンをクリックし、名前をSocketBSに変更して、「保存」をクリックします。

14. 「保存」を再度クリックします。

パイプライン定義エディタに戻ります。

43.4.5 プロキシ・サービスとパイプラインの接続

ここでは、プロキシ・サービスを構成して、作成したパイプラインにメッセージを送信します。

プロキシ・サービスとパイプラインを接続するには:

1. プロジェクト・ナビゲータで、SocketProxyプロキシ・サービスをクリックします。

プロキシ・サービス定義エディタが表示されます。

2. 「構成」タブの「全般」サブタブで、ターゲットの「名前」フィールドの横にある「サービス・リソースの選択」をクリックします。

3. 「検索と選択」ダイアログで、「名前」フィールドに「SocketPipeline」と入力し、「検索」をクリックします。

4. 結果リストのパイプラインを選択し、「OK」をクリックします。

5. 「保存」をクリックします。

6. 「アクティブ化」をクリックし、新しいリソースをWebLogic Serverにデプロイします。

43.5 ソケット・トランスポート・プロバイダのテスト

サンプル・ファイルが提供するクライアント・ツールおよびサーバー・ツールを使用して、ソケット・トランスポート・プロバイダをテストできます。また、Oracle Service Busコンソールのテスト・コンソールを使用して、プロジェクト・コンポーネントをテストできます。

- テストするためのサンプルのサーバーとクライアントの使用

- テスト・コンソールの使用

43.5.1 テストするためのサンプルのサーバーとクライアントの使用

サンプル・プロジェクトには、ソケット・トランスポート・プロバイダをテストするための簡単なソケット・サーバーおよびクライアントが含まれています。まず、サンプルのサーバーおよびクライアントを起動する必要があります。次に、テスト・コンソールを操作して、トランスポート・プロバイダをテストできます。

43.5.1.1 サンプルの外部サービスの起動

次のコマンドをsample-transportディレクトリから実行してテスト・サーバーを起動します。これは、指定したポートでリスンしてメッセージを送受信するサーバー・ソケットです。

java -classpath .\test\build\test-client.jar -Dfile-encoding=utf-8
-Drequest-encoding=utf-8 com.bea.alsb.transports.sample.test.TestServer 7031
<message-file-location>

7031は、ServerSocketがリスニングしているビジネス・サービスのエンドポイントURIのポート番号です。ファイルおよびリクエスト・エンコーディングは、リクエストおよびレスポンスのエンコーディングを指定します。message-file-locationは、ビジネス・サービスへのレスポンスとして送信するメッセージ・ファイルのパスおよび名前です。

サーバーが正常に起動すると、サーバーが起動したことおよびソケットをリスニングしていることを示すメッセージが表示されます。処理するファイルを指定すると、コマンド・ウィンドウにファイルのテキストが表示されます。

43.5.1.2 サンプルの初期化サービスの起動

次のコマンドを実行して、構成済のソケット・プロキシ・サービスのクライアントである、初期化ソケット・サービスを起動します。Service Busに対してメッセージを送信し、レスポンスを受信します。

java -classpath .\test\build\test-client.jar -Dfile-encoding=utf-8
-Dresponse-encoding=utf-8 com.bea.alsb.transports.sample.test.TestClient
<host-name> <port> <thread-ct> <message-file-location>

説明:

- host-nameは、Service Busサーバーがあるホスト名です。

- portは、プロキシ・サービスがリスニングしているポート番号です(この例では7032)。

- thread-ctは、Service Busにメッセージを送信できるクライアントの数です。

- message-file-location (オプション)は、ビジネス・サービスへのレスポンスとして送信されるメッセージ・ファイルの場所です。

- file-encodingは、ファイルのエンコーディングを指定するオプション引数です。デフォルト値はutf-8です。

- response-encodingは、ソケット・プロキシ・サービスから受信したレスポンスのエンコーディングです。デフォルト値はutf-8です。

43.5.2 テスト・コンソールの使用

ここでは、Oracle Service Busコンソールを使用してトランスポート・プロバイダをテストします。

テスト・コンソールを使用してテストするには:

1. 「サンプルの外部サービスの起動」で以前説明したように、テスト・サーバーを起動します。

2. プロジェクト・ナビゲータで、SocketPipelineをクリックし、パイプライン定義エディタでこれを開きます。

3. エディタの右上にある「テスト・コンソールの起動」アイコンをクリックします。

新しいブラウザ・ウィンドウにテスト・コンソールが表示されます。

4. テスト・コンソールで、テキスト領域に有効なXMLスタンザを入力するか、「参照」ボタンを使用して、ローカル・システムの有効なXMLファイルを選択します。

図43-10 テスト・コンソールでのサンプル・トランスポート・プロバイダのテスト

5. 「実行」をクリックします。テストが正常に終了すると、図43-11に示すような情報がテスト・コンソールに表示されます。また、テスト・コンソールにXMLテキストを入力すると、サーバー・コンソールにエコーされます。

図43-11 成功したサンプル・トランスポート・プロバイダのテスト

6. テスト・コンソールを閉じます。

第VII部 アーティファクトとサービスの共有

Service BusのプロジェクトとリソースをService Busのサーバー、インスタンスおよびアプリケーション間で共有する方法はいくつかあります。共通のリポジトリを使用してOracle SOA Suiteのアーティファクトにアクセスすることも可能です。Service Busに用意されているインポートおよびエクスポートの機能を使用すると、Service Busプロジェクトを作成し、これらのプロジェクトまたは個別リソースのみを他のService Busのインスタンスおよびサーバーと共有できます。また、Oracle SOA SuiteおよびService Busは、共通のリポジトリを共有し、プロジェクトとアプリケーション間でデプロイされたアーティファクトを共有できます。また、UDDIレジストリでサービスを共有する方法もあります。

この部は、次の章で構成されています。

- リソースおよび構成のインポートとエクスポート

- メタデータ・サービス・リポジトリを使用したデータの共有

- UDDIレジストリの操作

44 リソースおよび構成のインポートとエクスポート

Service Busには、JDeveloperまたはOracle Service Busコンソールからリソースをインポートおよびエクスポートする方法、およびコマンド行からリソースをエクスポートする方法が複数用意されています。また、Fusion Middleware Control Consoleを対象としたインポートおよびエクスポートも可能です。この章では、JDeveloperおよびOracle Service Busコンソールを使用してリソースをインポートおよびエクスポートする方法、ならびにコマンド行を使用してエクスポートする方法を説明します。

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

- リソースのインポートとエクスポートについて

- JDeveloperでのリソースのインポートとエクスポート

- Oracle Service Busコンソールでのリソースのインポートとエクスポート

- オフラインでのService Bus構成のエクスポート

Fusion Middleware Controlを使用したプロジェクトのインポートとエクスポートの詳細は、『Oracle Service Busの管理』のOracle Service Busリソースのインポートとエクスポートに関する項を参照してください。

44.1 リソースのインポートとエクスポートについて

Service Busには、インポート機能とエクスポート機能が用意されていて、Service Busのプロジェクトおよびリソースをドメイン間および開発ツール間で移動する際に役に立ちます。たとえば、開発からテストに移行するとき、プロジェクトを開発環境からエクスポートし、テスト環境にインポートできます。共有リソースを本番環境で変更する場合、エクスポート機能とインポート機能を使用して、各サーバーのリソースを更新できます。これらのプロセスでは、ステージング環境とテスト環境から本番環境へのリソース構成の規則的なプロモーションがサポートされます。

また、リソースをエクスポートしてインポートすることによって、JDeveloperとOracle Service Busコンソールの間で移動できます。たとえば、JDeveloperでJCAアダプタ・ファイル、WADLファイルなど特定のアーティファクトを作成するとします。Oracle Service Busコンソールのプロジェクトでこれらのアーティファクトを使用するには、これらをJDeveloperからエクスポートしてコンソールにインポートすることによって、これらのアーティファクト間のすべての参照が維持されます。

既存のソース・コード・コントロール・システムと構成JARファイルを組み合せると、Service Bus構成のバージョン管理および変更管理を行うことができます。

44.1.1 リソースのエクスポートについて

Service Busのプロジェクト全体または特定のリソースのみをエクスポートできます。エクスポート・プロセスによって、構成JARファイルが作成され、これをJDeveloper、Oracle Service BusコンソールまたはFusion Middleware Controlの個別のインスタンスにインポートできます。プロジェクト・レベルでエクスポートする場合、現在のインスタンスの1つ以上のプロジェクトを選択してエクスポートできます。「Service Busリソースのエクスポート」ウィザードでは、プロジェクト、フォルダおよびリソースがツリー・ビューに表示されますが、コンポーネントはプロジェクト・レベルでのみ選択できます。リソース・レベルでエクスポートする場合、プロジェクトを開いて、エクスポートする個々のリソースを表示して選択できます。検証エラーを回避するために、エクスポート用に選択したリソースに関するすべての依存関係を自動的に含めることも選択できます。

Oracle Service Busコンソールで、セッション内またはセッション外で作業していても、プロジェクトとリソースをエクスポートできます。セッション内でエクスポートする場合、リソースはセッション・リソースおよび構成が不完全または競合する場合があります。セッション外でエクスポートする場合、エクスポートできるリソースは、アクティブ化されたリソースになります。

Service Busでは、コンソール用に作成したユーザー、グループまたはロールはエクスポートできません。また、WebLogic Server Administration Consoleで作成した資格証明マップやその他のセキュリティ・プロバイダ・データもエクスポートできません。このデータをエクスポートするには、かわりにWebLogic Server管理コンソールを使用します。『Oracle WebLogic Serverセキュリティの管理』のセキュリティ・データの移行に関する項を参照してください。

44.1.1.1 エクスポート時のデータ暗号化

Service Busのプロジェクトまたはリソースを構成JARファイルにエクスポートするとき、サービス・アカウント、サービス・キー・プロバイダ、UDDIレジストリ、JNDIプロバイダおよびSMTPサーバーの各リソースにあるユーザー名およびパスワード・データを暗号化できます。このJARファイルをインポートする場合、正しいパスワードを指定しないかぎり、暗号化したユーザー名およびパスワード・データを含むリソースはインポートされません。JARファイル内の他の暗号化されていないリソースは、パスワードを指定せずにインポートできます。

各サービス・アカウントに対し、そのサービス・アカウントに格納されていたデータの種類に応じて、ユーザー名およびパスワードまたはローカル・ユーザーからリモート・ユーザーへのマッピングがエクスポートされます。各サービス・キー・プロバイダに対しては、PKI資格証明マッピング・プロバイダからのキー・ペア・バインディングのエイリアスがエクスポートされます。秘密鍵、資格証明またはキー・ストアのその他のデータはエクスポートされません。キー・ストアのデータは、キー・ストアのベンダーが提供するツールを使用してエクスポートする必要があります。

44.1.2 リソースのインポートについて

Service Busプロジェクト全体、または別のService Busドメインから以前にエクスポートされた構成JARファイルおよびリソース構成ファイルに含まれる特定のリソースのみをインポートできます。エクスポートされたデータの一部だけをインポートするように選択することもできます。インポート先システムにリソースがすでに存在する場合は更新されます。存在しない場合は、新たに作成されます。リソースの削除は、インポートするJARがプロジェクト全体のJARであり、インポートするJARファイルに存在しないリソースがインポート先システムの同じプロジェクトに存在する場合にのみ行われます。他のプロジェクトにあるリソースは削除されません。

Service Busでは、プロジェクト・レベルでエクスポートされたService Busリソースであっても、リソース・レベルでインポートできます。たとえば、プロジェクト全体のJARファイルにエクスポートしたシステム・リソースを、インポート時に選択解除できます。構成をエクスポートする場合、ユーザー、グループ、または証明書はエクスポートできません。このため、エクスポートされた構成をインポートするときに、再度これらのオブジェクトを作成する必要があります。

44.1.2.1 インポート・パフォーマンスの改善

Service Busプロジェクトをインポートする場合、インポートしたリソースに対していくつかの検証が行われます。インポートする構成JARファイルのサイズに応じて、この検証が原因でインポート・プロセスの速度が遅くなる可能性があります。デフォルトでは、Service Busは、インポート中に4つの検証スレッドを並行して処理します。パフォーマンスを改善するために、検証に使用できるスレッド数を制御できます。このためには、Service Busサーバー起動スクリプトで次の引数をJavaオプションに追加します(使用する最大スレッド数をno_of_threadsに代入します)。

-Doracle.osb.config.parallelism=no_of_threads

これで、Oracle Service BusコンソールおよびFusion Middleware Controlに対してスレッド数が設定されます。JDeveloperに対してこの値を設定するには、MW_HOME/jdeveloper/jdev/binにあるjdev.confファイルに引数を追加します。

44.1.2.2 サービス・アカウントまたはサービス・キー・プロバイダのインポート

インポートするJARファイルがAquaLogic Service Bus 3.0以降で作成され、サービス・アカウントまたはサービス・キー・プロバイダが含まれる場合、これらのリソースをユーザー名、パスワード、ローカル・ユーザーからリモート・ユーザーへのマッピングおよびそれらに含まれるキー・ペア・バインディングへのエイリアスとともにインポートできます。

各サービス・キー・プロバイダについて、キー・ペア・バインディングへのエイリアスがPKI資格証明マッピング・プロバイダにインポートされます。このデータがエクスポート時に暗号化された場合は、データの暗号化に使用したパスワードを入力する必要があります。パスワードがわからない場合でも、暗号化されていない他のすべてのリソースはインポートできます。

サービス・アカウントまたはサービス・キー・プロバイダをインポートするときに、対応する同じ名前のリソースがドメインにすでに存在する場合は、インポートされるリソースによってドメインのリソースが上書きされます。ドメインに存在するリソースが現在のセッション中に変更された場合でも同様です。ただし、インポート中にセキュリティ設定を保持することを指定した場合を除きます。詳細は、「インポート時のセキュリティ構成の保持」を参照してください。

44.1.2.3 インポート時の操作設定の保持

操作値には、グローバル操作設定と、個々のコンポーネント用の操作設定の2種類があります。グローバル操作設定は、他のリソースと同様にインポートされますが、インポート時に「操作値の保持」を選択することで、インポート中のドメインで操作設定を保持して、インポート中に設定が上書きされないようにすることができます。Preserve Operational Valuesが指定されていない場合は、インポートするJARファイルの値がドメインに設定されます。

44.1.2.4 インポート時のセキュリティ構成の保持

関連付けられているセキュリティ構成データを失うことなく、Service Busリソースをエクスポートおよびインポートできます。インポートおよびエクスポートのウィザードでは、インポートするシステムの既存のセキュリティ構成を保持するかまたは既存の構成をインポートするリソースの構成で上書きするかを指定できます。これは、インポートするリソースがインポートするシステムにすでに存在していて、これらの既存のリソースを更新する場合のみ問題になります。

たとえば、資格証明をステージング領域で構成し、この資格証明を含むプロジェクトをエクスポートして、プロダクション環境でそのプロジェクトをインポートするとします。プロジェクトをエクスポートする場合、セキュリティ構成は、Service Busの構成JARファイルに含まれています。次に、プロジェクトをターゲット・システムにインポートする場合、セキュリティの処理は、インポートするリソースがターゲット・システムにすでに存在しているかどうかによって異なります。

- インポートするリソースが新規、つまりJARファイルには存在しているがターゲット・システムには存在していない場合、そのリソースはJARファイルのセキュリティ構成を使用します。

- インポートするリソースがインポートのターゲット・サーバーとJARファイルの両方に存在する場合、そのリソースは指定したセキュリティ構成を使用します。ターゲット・システムの既存のセキュリティ構成を保持するかまたはこれをJARファイルの構成で上書きできます。

インポート中に選択したオプションによって、インポートするシステムのリソースのセキュリティ構成のどの側面をインポート中に保持するかを決定できます。これらのオプションは、プロジェクト・レベルのエクスポートと個別リソースのエクスポートの両方で作成されたJARファイルをインポートするときに同じように機能します。インポート中のセキュリティ・オプションを次に示します。

- セキュリティおよびポリシーの構成を保持

- 資格証明の保持

- アクセス制御ポリシーを保持

WebLogic Server (WLS)ポリシーを使用するように構成されたサービスをインポートする場合、WLSポリシーのサポートは非推奨になっているため、これらのポリシーを編集できないことに注意してください。Oracle Web Services Managerポリシーでこれらのサービスを再構成する必要があります。

44.1.2.4.1 セキュリティおよびポリシーの構成の保持

「セキュリティおよびポリシーの構成を保持」を選択すると、インポートするシステムにあるリソースの次の構成パラメータが保持されます。インポートされるリソースの構成は保持されません。

- プロキシ・サービスのセキュリティおよびポリシーの構成:

- サービス・キー・プロバイダへの参照。

- 「ポリシー」タブを使用してサービスに直接バインドされているポリシーのセット。サービスでWSDLベースのポリシーを使用している場合、WSDLドキュメント自体が更新される場合があり、サービスがWSDLドキュメントを反映する必要があるため、ポリシーは保持されません。

- 「WS-Securityヘッダーの処理」オプションの状態。

- メッセージ・レベルのカスタム認証の構成。

- プロキシ・サービスのトランスポート固有のセキュリティ構成:

- HTTPの場合は、HTTPSフラグおよび認証モード(匿名、基本、クライアント証明書またはカスタム・トークン)。

- JMSの場合は、JMSおよびJNDIサービス・アカウント。

- 電子メールおよびFTPの場合は、サービス・アカウント参照。

- SFTPの場合は、認証構成。

- ビジネス・サービスのセキュリティおよびポリシーの構成:

- WS-Policyのバインディング。

- 「呼出し元のサブジェクトを渡す」の設定

- アウトバウンドWS-Securityのサービス・アカウントへの参照。

- ビジネス・サービスのトランスポート固有のセキュリティ構成:

- HTTPの場合は、認証モード(匿名、基本またはクライアント証明書)およびサービス・アカウント参照。

- JMSの場合は、JMSおよびJNDIサービス・アカウントへの参照。

- FTP、EJB、Tuxedo、およびDSPの場合は、サービス・アカウント参照。

- SFTPの場合は、認証構成。

44.1.2.4.2 資格証明の保持

「資格証明の保持」を選択すると、インポートするシステムにあるリソースの次の資格証明が保持されます。インポートされるリソースの構成は保持されません。

- サービス・キー・プロバイダのPKI資格証明。
PKI資格証明マッピング・プロバイダは、デジタル署名や暗号化およびアウトバウンドSSL認証に使用できる鍵ペアにサービス・キー・プロバイダをマップします。

- サービス・アカウントのユーザー名とパスワード。

- SMTPサーバー、JNDIプロバイダおよびUDDIレジストリのユーザー名とパスワード。

44.1.2.4.3 アクセス制御の保持

「アクセス制御ポリシーの保持」を選択すると、インポート・プロセス中にインポートするシステムにあるプロキシ・サービスのすべてのアクセス制御ポリシーが保持されます。インポートされるプロキシ・サービスのアクセス制御ポリシーは保持されません。

44.1.2.5 インポート後の環境値のカスタマイズ

このカスタマイズ機能を使用して、インポートされたリソースをアクティブ化する前に新しいドメインに合せて調整できます。構成ファイルを使用すると、インポート機能と検索および置換機能を一緒に使用して、リソースに対する環境に固有の属性をグローバルに変更できます。これは、複雑なデプロイメント・シナリオで必要とされる、構成の慎重な調整作業にかわる機能を意味するわけではありません。

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

- 他のService Busリソースへのサービス参照。

- プロキシ・サービスURLまたはビジネス・サービスURLのJMSキューおよび接続ファクトリ。

- パイプラインのルーティングの宛先。

- ビジネス・サービスおよびプロキシ・サービスのエンドポイントURI。

- ビジネス・サービスのロード・バランシング設定。

- ポーリングする特定のプロキシ・サービスおよびビジネス・サービスのトランスポート構成のディレクトリ名。

構成ファイルの詳細は、『Oracle Service Busの管理』のOracle Service Bus環境のカスタマイズに関する項を参照してください。

44.2 JDeveloperでのリソースのインポートとエクスポート

Service Busでは、様々なソースとの間でインポートおよびエクスポートを実行できます。その後のインポート処理を行うためにService Busリソースを構成JARファイルにエクスポートできます。また、実行中のWebLogic Serverにリソースを直接エクスポートできます。Service Busインスタンス、Service Busリソースを含むZIPファイルまたはService BusリソースがあるURLから以前エクスポートされた構成JARファイルからリソースをインポートできます。UDDIレジストリのリソースにもアクセスできます。これは、「UDDIレジストリの操作」を参照してください。

警告:

エクスポートを実行する前に、エクスポートするすべてのリソースを必ず保存してください。インポートを実行する前に、インポート先のアプリケーションのすべてのファイルを必ず保存してください。

44.2.1 Oracle JDeveloperで構成JARファイルにリソースをエクスポートする方法

JDeveloperからService Busリソースをファイルにエクスポートするとき、Service Busでは、後で異なるService BusインスタンスにインポートできるJARファイルを生成します。プロジェクト全体をエクスポートする場合、概要ファイル(servicebus.sboverview)はエクスポートに含まれませんが、プロジェクトを再インポートするときに再生成されます。

JDeveloperで構成JARファイルにリソースをエクスポートするには:

1. Service Busアプリケーションを開いた状態で、アプリケーション・ナビゲータを右クリックし、「エクスポート」を選択します。

2. 「エクスポート」ダイアログで、「Service Busリソース」を選択し、「OK」をクリックします。

「Service Busリソースのエクスポート」ウィザードが表示されます。

3. 「タイプ」ページで、「構成Jar」を選択し、「次」をクリックします。

選択したソースに含まれているリソースのリストが表示されます。

4. 「エクスポート・レベル」フィールドで、「プロジェクト」を選択してプロジェクト全体をエクスポートするかまたは「リソース」を選択して個別のリソースをエクスポートします。

5. リソースのリストを展開し、エクスポートするリソースのみが選択されていることを確認します。

6. リソース・レベル・エクスポートの場合、「依存関係を含める」を選択して、選択したリソースが参照する追加のリソースをエクスポートします。チェック・ボックスをクリアして、選択したリソースのみをエクスポートします。

7. 生成される構成JARファイルのパスおよびファイル名を入力します。

8. エクスポートされるリソースの機密データを暗号化するには、「機密データの保護」を選択し、「パスフレーズ」フィールドおよび「パスフレーズの確認」フィールドでファイルをロック解除するためのパスワードを入力します。

詳細は、「エクスポート時のデータ暗号化」を参照してください。

9. 「終了」をクリックします。

Service Busは、指定した場所に構成JARファイルを生成します。

44.2.2 Oracle JDeveloperでサーバーにリソースをエクスポートする方法

Service Busリソースをサーバーに直接エクスポートするとき、Service Busは、後でインポートできる構成JARファイルを生成しません。リソースをエクスポートし、指定したWebLogicサーバーに直接インポートします。

Service BusおよびJDeveloperでは現在、Oracle Cloudサーバーへの直接デプロイをサポートしています。

サーバーにエクスポートする前に、サーバーは、JDeveloperでアプリケーションの接続を定義する必要があります。これを行わないと、リストから選択できません。アプリケーション・サーバー接続を作成するには「アプリケーション・サーバー接続の作成方法」を参照してください。

JDeveloperでサーバーにリソースをエクスポートするには:

1. Service Busアプリケーションを開いた状態で、アプリケーション・ナビゲータを右クリックし、「エクスポート」を選択します。

2. 「エクスポート」ダイアログで、「Service Busリソース」を選択し、「OK」をクリックします。
「Service Busリソースのエクスポート」ウィザードが表示されます。

3. 「タイプ」ページで、「サーバー」を選択します。

4. 「次へ」をクリックします。
選択したソースに含まれているリソースのリストが表示されます。

5. 「エクスポート・レベル」フィールドで、「プロジェクト」を選択してプロジェクト全体をエクスポートするかまたは「リソース」を選択して個別のリソースをエクスポートします。

6. リソースのリストを展開し、エクスポートするリソースのみが選択されていることを確認します。

7. リソース・レベル・エクスポートの場合、「依存関係を含める」を選択して、選択したリソースが参照する追加のリソースをエクスポートします。チェック・ボックスをクリアして、選択したリソースのみをエクスポートします。

8. 「サーバー」フィールドで、リソースのエクスポート先のサーバーのアプリケーション・サーバー接続を選択します。

ヒント:

接続先のサーバーが実行中でない場合、ウィンドウの下部にある「サーバーの起動」をクリックして起動します。

9. 「セッション」フィールドで、インポートされるリソースと関連付けるセッションの名前を入力します。

10. Oracle Cloudサーバーにデプロイする場合、「クラウド・サーバーへのエクスポート」オプションが選択されていることを確認します。

11. 「次へ」をクリックします。

12. クラウド以外のサーバーにエクスポートする場合は、次のとおり実行します。

a. リソースのリストを展開し、インポートするリソースのみが選択されていることを確認します。

b. 従属リソースを自動的にインポートするには、「依存関係を含める」を選択します。

注意:

Oracle Cloudサーバーにエクスポートする場合、リソースのリストは表示されません。この手順はスキップできます。

13. インポートするリソースから保持する環境設定またはセキュリティ設定を選択します。
これらの設定の詳細は、「インポート時のセキュリティ構成の保持」およびJDeveloperが提供するオンライン・ヘルプを参照してください。

14. 次の作業を実行し、セッションを構成します。

a. Oracle Service Busコンソールでセッションを作成してアクティブ化するには、「パブリッシュ後にセッションをアクティブ化」を選択し、セッションの説明を入力します。

b. インポートによって競合が発生した場合またはセッションをアクティブ化できない場合にセッションを廃棄するには、「アクティブ化に失敗した場合にセッションを破棄」を選択します。

注意:

Oracle Cloudサーバーへのデプロイ時にアクティベーションに失敗した場合、セッションは常に破棄されます。

15. 構成ファイルを指定して環境値の更新に使用するには、「デプロイメント・カスタマイズ・ファイル」フィールドの横の「参照」をクリックし、使用するファイルに移動して選択します。

16. 「終了」をクリックします。
選択したリソースが指定したサーバーにパブリッシュされます。

44.2.3 JDeveloperでリソースをインポートする方法

以前エクスポートした構成JARファイル、アーカイブされたZIPファイル、URLなど様々なソースからService Busをインポートできます。URLからリソースをインポートする場合、ファイル・システム、MDSリポジトリ、現在のアプリケーション、アプリケーション・サーバー、プロジェクト・ライブラリ、UDDIレジストリ、WSILソースなど、リソースの複数のソースを参照できます。使用可能なソースは、インポートするリソースのタイプによって異なります。

新しいService Busプロジェクトをインポートする場合、Service Busは、プロジェクト概要ファイルを生成し、すべての派生Service BusリソースをService Bus概要エディタの図に追加します。インポートによって既存のService Busプロジェクトが更新される場合、新しいリソースまたは更新されたワイヤリングによって概要図も更新されます。インポートするファイルに含まれているシステム・リソースは、「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダに追加されます。システム・リソースは、アプリケーション・フォルダの「システム」フォルダにあります。

警告:

アーカイブされたZIPファイルをインポートするとき、ZIPファイルのXQueryリソースのファイル拡張子は、以前のバージョンのデフォルトの拡張子だった.xqueryではなく.xqyである必要があります。拡張子は、構成JARファイルをインポートするときに自動的に更新されます。

JDeveloperでリソースをインポートするには:

1. Service Busアプリケーションを開いた状態で、アプリケーション・ナビゲータを右クリックし、「インポート」を選択します。

2. 「インポート」ダイアログで、「Service Busリソース」を選択し、「OK」をクリックします。

「Service Busリソースのインポート」ウィザードが表示されます。

3. 「タイプ」ページで、次のソースの1つを選択してインポートします。

- 構成Jar

- URLからのリソース

- zip圧縮リソース

4. 「次」をクリックします。

「ソース」ページに表示されるオプションは、前の選択によって異なります。

5. 次のいずれかを行います。

- 「構成Jar」を選択した場合、インポートするService Bus JARファイルの名前を参照して選択します。

- 「URLからのリソース」を選択した場合、オプションのリストからリソース・タイプを選択し、リソースのURLを参照して選択し、リソース名を指定します。

- 「zip圧縮リソース」を選択した場合、インポートするリソースを含むZIPファイルの名前を参照して選択します。

6. 「次」をクリックします。

選択したソースに含まれるリソースのリストが、それぞれに対して実行される操作のタイプ(作成、更新または削除)とともに表示されます。

7. リソースのリストを展開し、インポートするリソースのみが選択されていることを確認します。

警告:

削除とマークされたリソースをすべて確認し、これらを削除することを確認します。これらを削除しない場合、そのチェック・ボックスをクリアします。

8. 構成JARファイルをインポートしている場合、次のいずれかを実行します。

- 従属リソースを自動的にインポートするには、「依存関係を含める」を選択します。

- インポートするソースがパスワードで保護されている場合、「パスフレーズ」フィールドにパスワードを入力します。

- インポートするリソースから保持する環境設定またはセキュリティ設定を選択します。
これらの設定の詳細は、「インポート時のセキュリティ構成の保持」およびJDeveloperが提供するオンライン・ヘルプを参照してください

9. 「終了」をクリックします。

選択したリソースがインポートされ、アプリケーション・ナビゲータに表示されます。

44.3 Oracle Service Busコンソールでのリソースのインポートとエクスポート

Service Busのインポート機能を使用すると、Service Busインスタンス、Service Busリソースを含むZIPファイルまたはService BusリソースがあるURLから以前エクスポートされた構成JARファイルからインポートできます。UDDIレジストリからのインポートおよびここへのパブリッシュも可能です。これは、「UDDIレジストリの操作」を参照してください。

警告:

エクスポートを実行する前に、エクスポートするすべてのリソースを必ず保存してください。インポートを実行する前に、インポート先のアプリケーションのすべてのファイルを必ず保存してください。

44.3.1 コンソールで構成JARファイルにリソースをエクスポートする方法

Oracle Service BusコンソールからService Busリソースをエクスポートするとき、Service Busは、後で異なるService BusインスタンスにインポートできるJARファイルを生成します。

コンソールで構成JARファイルにリソースをエクスポートするには:

1. プロジェクト・ナビゲータで、次のいずれかを実行します。

- すべてのプロジェクトを選択してエクスポートするには、「リソース」ツールバーで「エクスポート」をクリックするかまたは「すべてのプロジェクト」を右クリックして「エクスポート」を選択します。

- 特定のプロジェクトを選択してエクスポートするには、そのプロジェクトを選択してこれを右クリックします。表示されたメニューから「エクスポート」を選択します。

エクスポート可能なリソースのリストとともに「リソースのエクスポート」ダイアログが表示されます。

2. 「コンテンツのエクスポート」で、「プロジェクト」を選択してプロジェクト全体をエクスポートするかまたは「リソース」を選択して個別のリソースをエクスポートします。

3. リソースのリストを展開し、エクスポートするリソースのみが選択されていることを確認します。

4. リソース・レベル・エクスポートの場合、「リソースの依存関係を含める」を選択して、選択したリソースが参照する追加のリソースをエクスポートします。チェック・ボックスをクリアして、選択したリソースのみをエクスポートします。

5. エクスポートされるリソースの機密データを暗号化するには、「機密データの保護」を選択し、「パスフレーズ」フィールドおよび「パスフレーズの確認」フィールドでファイルをロック解除するためのパスワードを入力します。

詳細は、「エクスポート時のデータ暗号化」を参照してください。

6. 「エクスポート」をクリックします。

7. 「ファイルのダウンロード」ダイアログで、「保存」をクリックし、構成JARファイルの場所とファイル名を指定し、「保存」を再度クリックします。

Service Busは、指定した場所に構成JARファイルを生成します。

44.3.2 コンソールで構成JARファイルからリソースをインポートする方法

注意:

前のバージョンからXQueryリソースを含む構成JARファイルをインポートすると、リソースのファイル拡張子は.xqueryから.xqyに自動的に更新されます。前のバージョンのデフォルトの拡張子は.xqueryでした。

コンソールでJARファイルからリソースをインポートするには:

1. 次のいずれかを行います。

- プロジェクト・ナビゲータで、「すべてのプロジェクト」を右クリックし、「インポート」を指し、「構成Jar」を選択します。

- 「リソース」ツールバーで「インポート」アイコンをクリックします。

2. 「構成Jarのインポート」ウィザードで、インポートするJARファイルを参照して選択します。

3. 「次」をクリックします。

選択したソースに含まれるリソースのリストが、それぞれに対して実行される操作のタイプ(作成、更新または削除)とともに表示されます。

4. リソースのリストを展開し、インポートするリソースのみを選択します。デフォルトでは、すべてのリソースが選択されます。

警告:

削除とマークされたリソースをすべて確認し、これらを削除することを確認します。これらを削除しない場合、そのチェック・ボックスをクリアします。

5. 従属リソースを自動的にインポートするには、「依存関係を含める」を選択します。

6. インポートするソースがパスワードで保護されている場合、「パスフレーズ」フィールドにパスワードを入力します。

7. インポートするリソースから保持する詳細設定のいずれかを選択します。次のいずれかを保持できます。

- セキュリティおよびポリシーの値

- 資格証明

- アクセス制御ポリシー

- 環境変数値

- 操作設定

詳細は、「インポート時のセキュリティ構成の保持」およびコンソールが提供するオンライン・ヘルプを参照してください。

8. 「インポート」をクリックします。

選択したリソースがプロジェクト・ナビゲータに表示されます。「構成Jarのインポート」ウィザードに、インポートのサマリーおよびインポートされたリソースのエラーが表示されます。

9. インポート・プロセス中に削除されたすべてのリソースを表示するには、「削除されたリソース」タブをクリックします。

10. 別のJARファイルをインポートするには、「別のインポートを行う」をクリックし、上記手順を繰り返します。そうしない場合、「閉じる」をクリックします。

44.3.3 コンソールでZIPファイルからリソースをインポートする方法

ZIPファイルをインポートするとき、ZIPファイル内の各ファイルは多くの場合はリソースであり、Service Busはファイル拡張子によって各ファイルのリソースの種類を識別します。各リソースにはService Busのデフォルトの拡張子がありますが、これらのリソースを記述する追加の拡張子がある場合、ZIPファイルをインポートするときにこれらの拡張子マッピングを定義できます。1つの拡張子は、1つのファイル・タイプにのみ関連付けることができます。

インポート・プロセス中、Service BusがそのZIPファイルの内容をスキャンし、リソースの種類を各ファイルに関連付けます。拡張子を持たないファイル、またはマップ内に定義されていない拡張子を持つファイルは「不明」とみなされ、自動的にロードの対象から外されます。拡張子を確認できたファイルでは、拡張子を省いたファイル名がリソースの名前になります。Zipファイルのフォルダ構造は、対象のプロジェクトまたはフォルダ内に再作成されます。

WSDLドキュメントやXMLスキーマなどのリソースでは、依存リソースのツリー全体を定義できます。一括ロード機能を使用すると、一連のリソースをまとめてアップロードでき、依存関係を手動で解決する必要がありません。

警告:

アーカイブされたZIPファイルをインポートするとき、ZIPファイルのXQueryリソースのファイル拡張子は、以前のバージョンのデフォルトの拡張子だった.xqueryではなく.xqyである必要があります。

コンソールでZIPファイルからリソースをインポートするには:

1. プロジェクト・ナビゲータで、リソースのインポート先のプロジェクトまたはフォルダを右クリックし、「インポート」を指し、「ZIPファイル」を選択します。

2. 「ZIPファイルからインポート」ウィザードで、インポートするZIPファイルを参照して選択します。

3. 「拡張子マッピング」表で、リソースの種類とファイル拡張子のマッピングを確認します。必要に応じて、ファイル拡張子を変更または追加します。複数の拡張子はカンマで区切ります。

4. 「次」をクリックします。

選択したソースに含まれるリソースのリストが、それぞれに対して実行される操作のタイプ(作成、更新または削除)とともに表示されます。

5. リソースのリストを展開し、インポートするリソースのみを選択します。デフォルトでは、すべてのリソースが選択されます。

6. 「インポート」をクリックします。

選択したリソースがプロジェクト・ナビゲータに表示されます。「ZIPファイルからインポート」ウィザードに、インポートのサマリーおよびインポートされたリソースのエラーが表示されます。

7. 別のZIPファイルをインポートするには、「別のインポートを行う」をクリックし、上記手順を繰り返します。そうしない場合、「閉じる」をクリックします。

44.3.4 コンソールでURLからリソースをインポートする方法

URLまたはファイル・システムから入手できるリソースのバルク・インポートを実行できます。バルク・インポートによって、WSDLドキュメントのようなルート・リソースとともに、それに従属する他のWSDLドキュメントやスキーマなどもインポートできます。依存関係マップは、自動的に解決されます。

ファイル名の横にある「警告」アイコンは、リソースの種類が不明であることを示します(拡張子を持たないファイル、またはマップ内に定義されていない拡張子を持つファイルは不明と見なされます)。ファイルの種類が不明なファイルはインポートできません。

コンソールでURLからリソースをインポートするには:

1. プロジェクト・ナビゲータで、リソースのインポート先のプロジェクトまたはフォルダを右クリックし、「インポート」を指し、「URLから」を選択します。

2. 「URLからインポート」ウィザードで、次の情報を入力します。

- 「リソース・タイプ」: オプションのリストからインポートするリソースの種類を選択します。

- 「URLソース」: インポートするリソースへのURLまたはローカル・パスを入力します。ローカル・リソースを指定するには、fileプロトコルを使用します。次に例を示します。

file:///c:/osbresources/ForeachAction.jar

- 「リソース名」: インポートするリソースの名前を入力します。

3. 「次」をクリックします。

URLで識別されるリソースのリストが表示されます。

4. リソースのリストを展開し、インポートするリソースのみを選択します。デフォルトでは、すべてのリソースが選択されます。

5. 「インポート」をクリックします。

選択したリソースがプロジェクト・ナビゲータに表示されます。「URLからインポート」ウィザードに、インポートのサマリーおよびインポートされたリソースのエラーが表示されます。

6. URLから別のリソースをインポートするには、「別のインポートを行う」をクリックし、上記手順を繰り返します。そうしない場合、「閉じる」をクリックします。

44.4 Service Bus構成のオフラインでのエクスポート

ここでは、サーバーに接続していないときにService Bus構成をエクスポートする方法を説明します。構成JARファイルにプロジェクト全体または個別のリソースをエクスポートし、新しいService Bus環境またはインスタンスにインポートできます。

- エクスポート・プロセスについて

- Service Bus構成のエクスポートの準備

- オフラインでのService Bus構成のエクスポート

- エクスポート設定ファイルの形式、サンプルおよびスキーマ

44.4.1 エクスポート・プロセスについて

Service Bus構成をオフライン・モードでエクスポートするには、コマンドライン、AntタスクまたはWebLogic Scripting Tool (WLST)を使用します。いずれの方法でも、エクスポートの実行方法と生成される構成JARファイルに含めるファイル、フォルダ、プロジェクトまたはシステム・リソースを定義するために、エクスポート設定ファイルが使用されます。

エクスポート・ツールは2フェーズ(ロードとエクスポート)で実行され、各フェーズをエクスポート設定ファイルで構成されます。ロード・フェーズでは、エクスポート・ツールによって、ファイル・システムの走査、読み込むファイルの識別、対応するリソースへのファイル・コンテンツの変換および構成フレームワークへのファイルのインポートが行われます。

ロード・フェーズでは、次を構成できます。

- ディレクトリ構造: JDeveloperの作業ディレクトリ構造に依存せずに、プロジェクト・ルート・ディレクトリ、システム・リソースを配置するディレクトリ、および含める特定のフォルダとファイルを指定できます。

- ファイル拡張子: Service Busでは、リソース・タイプにそれぞれ固有のファイル拡張子(プロキシ・サービスには.proxy、XSLTリソースには.xslおよび.xslt、など)が使用されます。拡張子はそれぞれ1つのService Busリソース・タイプにのみマップできますが、リソース・タイプは複数のファイル拡張子にマップできます。各Service Busリソースに、変更できないデフォルトの拡張子が1つ含まれますが、リソースに対してカスタムのファイル拡張子を指定することもできます。エクスポート・ツールでカスタム拡張子を含むファイルが認識されるようにするには、エクスポート設定ファイルにファイル拡張子のマッピングを定義する必要があります。

- 包含ルールおよび除外ルール: プロジェクトまたはシステム・リソース・フォルダを指定すると、エクスポートにすべてのService Busファイルが含まれます。包含文および除外文を使用すると、いずれのファイルを含めるかについて詳細に制御することができます。たとえば、特定のバージョニング・システムでは、プロジェクト・フォルダ内に追加のシステム・フォルダおよびファイルが作成されます。これらのファイルはService Busリソースとして認識される可能性があり、エクスポートから特に除外しないかぎり、エクスポートされるJARファイルに含まれます。

Service Bus構成はプロジェクト・レベルまたはリソース・レベルでエクスポートでき、構成の複数のエクスポートを1つのエクスポート設定ファイルに定義できます。エクスポート・フェーズでは、次を構成できます。

- プロジェクト・レベルのエクスポート: プロジェクト・レベルでは、含めるプロジェクトの名前およびシステム・リソースを含めるかどうかを指定します。プロジェクト名を指定しなかった場合は、生成されるエクスポート・ファイルに、ロード・フェーズで追加したすべてのプロジェクトが含まれます。

注意:

ロード・フェーズの詳細包含が定義されている場合にはプロジェクト・レベルでエクスポートしないでください。これを行うと、含まれていないすべてのリソースが削除される可能性があります。

- リソース・レベルのエクスポート: リソース・レベルでは、前述のように包含ルールおよび除外ルールを使用して、エクスポートするリソースを指定します。依存性を含めるかどうかを指定することもできます。エクスポート設定ファイルにリソースを指定しなかった場合は、すべてのリソースがエクスポートされます。

- 複数の構成JARファイル: エクスポート設定ファイルに複数のconfigjar要素を定義して、それぞれで特定のファイルへのエクスポートを定義できます。同じ名前を持つ既存のファイルを上書きするかどうかを指定することもできます。

44.4.2 Service Bus構成のエクスポートの準備

Service Bus構成をオフライン・モードでエクスポートする前に、次の手順を実行します。

- 始める前に

- エクスポート設定ファイルの作成

- 環境の構成

44.4.2.1 始める前に

リソースのエクスポートを始める前に、次のものがインストールされていることを確認します。

- Service Bus 12.2.1

- Java 1.8.x

構成をエクスポートする際には、次のことに注意してください。

- スクリプト内のリソースJAR名に正しいバージョン番号が含まれている。

- JDeveloperのワーク・ファイルが読取り専用である場合、出力またはワークスペース・ログ・ファイルにスタック・トレースの例外が発生する可能性があります。

- 終了値で0が表示される場合、エクスポートが完了したことを意味します。

注意:

カスタム・トランスポートを開発した場合は、オフラインでトランスポートのプラグイン・ファイルを作成し、そのファイルをService BusインストールのOSB_ORACLE_HOME/config/pluginsに保存する必要があります。

44.4.2.2 エクスポート設定ファイルの作成

オフライン・エクスポートの実行時に、コマンド行引数を使用するかわりに、エクスポート・ツールによって、作成した設定ファイルが参照されます。このファイルはXMLフォーマットであり、エクスポート・ツールがファイルの検出およびロードを行って構成JARファイルを作成するために必要なすべての情報を含みます。ファイル形式とスキーマ定義の詳細および使用例は、「エクスポート設定ファイルの形式、サンプルおよびスキーマ」を参照してください。

44.4.2.3 環境の構成

エクスポートを実行する前に、setenv.*ファイルを実行して、ツールで使用する環境変数を設定する必要があります。このファイルは、実行する前に、JVMのヒープ・サイズの変更、CLASSPATHへのJARファイルの追加、またはシステム・プロパティの追加を行ってカスタマイズできます。エクスポートに含まれ、カスタムJARファイルが必要なJARリソースがある場合は、setenv.*ファイルにそれらのカスタムJARファイルを追加します。

ファイルをカスタマイズしたら、OSB_ORACLE_HOME/tools/configjarに移動して、次のコマンドを実行します。

Windowsの場合:

setenv.bat

UNIXまたはLinuxの場合:

source setenv.sh

44.4.3 Service Bus構成のオフラインでのエクスポート

次の各項では、Service Bus構成をオフラインでエクスポートするためのスクリプトおよびコマンド行オプションについて説明します。

- コマンド行を使用した構成のオフライン・エクスポート

- Antを使用した構成のオフライン・エクスポート

- WLSTを使用した構成のオフライン・エクスポート

44.4.3.1 コマンド行を使用した構成のオフライン・エクスポート

コマンド行からのエクスポートによって、エクスポート設定ファイルで指定したフォルダおよびファイルからService Bus構成JARファイルが生成されます。

構文

Windowsの場合は、次の構文を使用します。

configjar.bat -settingsfile <FILE_NAME> [-debug -help]

UNIXまたはLinuxの場合は、次の構文を使用します。

./configjar.sh -settingsfile <FILE_NAME> [-debug -help]

パラメータ

コマンド行では、次のパラメータを使用できます。

- -settingsfile FILE_NAME: エクスポート設定ファイルのパスおよびファイル名を入力します。このパラメータは必須です。

- -debug: エクスポート・プロセスのデバッグ・ロギングを有効にするには、コマンドにこのオプション・パラメータを含めます。このフラグを含めないと、デバッグ・ロギングは実行されません。

- -help: 使用方法を表示するには、コマンドにこのオプション・パラメータを含めます。

44.4.3.2 Antを使用した構成のオフライン・エクスポート

Apache Antビルド・ファイルを使用してService Bus構成をオフライン・モードでエクスポートできます。Antを使用したエクスポートによって、エクスポート設定ファイルで指定したフォルダおよびファイルから構成JARファイルが生成されます。

サンプルのビルド・ファイル

次にサンプルのAntビルド・ファイルを示します。

<project name="ConfigExport" basedir=".">
<target name="run">
<ant antfile="configjar-ant.xml" target="run">
<property name="settingsFile" value="/osb/config/exportProps1.xml"/>
</ant>
<ant antfile="configjar-ant.xml" target="run">
<property name="settingsFile" value="/osb/config/exportProps2.xml"/>
</ant>
</target>
</project>

注意:

これは単なるサンプル・スクリプトです。独自のスクリプトの基盤としてこれを使用できますが、パスとファイル名が現在のインストールと一致するか必ず確認してください。

パラメータ

Antでは、次のパラメータがサポートされます。

- settingsFile: エクスポート設定ファイルのパスおよびファイル名。このパラメータは必須です。

- debug: エクスポート・プロセスのデバッグ・ロギングを有効にするには、このパラメータをtrueに、そうでない場合はfalseに設定します。このパラメータは省略可能で、デフォルトでfalseに設定されます。

- failonerror: エクスポート・ツールが失敗した場合にタスクを失敗させるには、このパラメータをtrueに設定します。これをfalseに設定すると、エクスポート・ツールが失敗してもタスクは失敗しません。このパラメータは省略可能で、デフォルトでtrueに設定されます。

- errorProperty: 指定した場合、実行が失敗するとこのパラメータはtrueに設定されます。このパラメータは省略可能で、デフォルトで指定されません。

44.4.3.3 WLSTを使用した構成のオフライン・エクスポート

WebLogic Scripting Tool (WLST)を使用してService Bus構成ファイルをオフライン・モードでエクスポートできます。WSLTを使用したエクスポートによって、エクスポート設定ファイルで指定したフォルダおよびファイルからService Bus構成JARファイルが生成されます。

サンプルのWLSTスクリプト

次にサンプルのWLSTスクリプトを示します。

from com.bea.alsb.tools.configjar import ConfigJar

args = []
args.append('-settings')
args.append('/osb/config/exportProps2.xml')
ConfigJar.main(args)

パラメータ

次のパラメータを使用できます。

- -settingsfile FILE_NAME: エクスポート設定ファイルのパスおよびファイル名を入力します。相対パスを使用した場合、パスはエクスポート・ツールが存在するディレクトリ(OSB_ORACLE_HOME/tools/configjar)に解決されます。このパラメータは必須です。

- -debug: エクスポート・プロセスのデバッグ・ロギングを有効にするには、コマンドにこのオプション・パラメータを含めます。このフラグを含めないと、デバッグ・ロギングは実行されません。

- -help: 使用方法を表示するには、コマンドにこのオプション・パラメータを含めます。

44.4.4 エクスポート設定ファイルの形式、サンプルおよびスキーマ

エクスポート設定を構成することで、エクスポートされる構成JARファイルに含めるファイルおよびフォルダを指定できます。これは、プロジェクト・レベルおよびリソース・レベルで行うことができ、一連の除外ルールおよび包含ルールを使用することでより詳細なレベルで制御できます。含めたファイルおよびフォルダによって、エクスポート用のコンテンツ・セットが構成されます。

44.4.4.1 エクスポート設定ファイルの形式

エクスポート設定ファイルには、sourceおよびconfigjarの2つの主なセクションがあります。source要素は、エクスポート・ツールによって選択されるファイルを定義し、configjar要素は、選択されたファイルのうちいずれのファイルを生成される構成JARファイルに含めるかを定義します。

source要素では、エクスポートするプロジェクトのプロジェクト・ルート・ディレクトリ、エクスポートするシステム・リソースの場所および包含または除外する具体的なファイルを指定します。また、Service Busリソース・タイプにカスタムのファイル拡張子をマップすると、エクスポート・ツールでこれらの拡張子が有効なService Bus構成要素として認識されます。

注意:

プロジェクト・ルートまたはリソース・フォルダに相対ディレクトリを指定すると、そのパスはエクスポート設定ファイルがあるディレクトリに対して相対的に解決されます。

configjar要素では、生成されるJARファイルに名前を付け、プロジェクト・レベルおよびリソース・レベルで(プロジェクト・レベルにシステム・リソースを含めるか、リソース・レベルに依存性を含めるかなどの)ルールを指定します。複数のconfigjar要素を定義でき、定義したconfigjar要素ごとにJARファイルが生成されます。

構成JARファイルの命名に関するガイドラインおよび制約事項は、「Service Busコンポーネントのネーミング・ガイドライン」を参照してください。

44.4.4.2 検証

Service Busに適用される命名の検証ルールと同じルールが、コンテンツ・セットに含まれるファイルにも適用されます。これらのルールに準拠しないファイルおよびフォルダはすべて、コンテンツ・セットから除外されます。

- フォルダおよびファイルは有効な名前にする必要があります。

- ファイル拡張子はService Busリソースにマップする必要があります。
2つの異なるファイルはcom.bea.wli.config.Refの同じインスタンスにマップできません(詳細は、「Oracle Service Bus Java APIリファレンス」を参照してください)。

44.4.4.3 包含ルールおよび除外ルール

包含ルールおよび除外ルールを使用する場合、ファイルは1つ以上の包含ルールに一致するとともに、コンテンツ・セットに含まれるいずれの除外ルールにも一致しない必要があります。ファイルを除外するには、そのファイルが1つ以上の除外ルールに一致するとともに、いずれの包含ルールにも一致しない必要があります。包含ルールおよび除外ルールが定義されていない場合は、自動的にすべてのファイルが含まれます。

包含ルールおよび除外ルールは、同じパターンに基づいています。

- パターンは、プロジェクト名で始まるファイルのサブパスに適用されます。完全なファイル・パスには適用されません。

- アスタリスク(*)は、任意の文字を表すワイルドカードです。これは、ファイル名またはディレクトリ名の一部として使用できます。

- 2つのアスタリスク(**)のみが使用されている場合、それは0または複数のディレクトリおよびファイルを表します。

44.4.4.4 エクスポート設定ファイルのサンプル

この項では、Service Bus構成のエクスポート方法を示すエクスポート設定ファイルのサンプルを、ロード・フェーズおよびエクスポート・フェーズのルールを様々に組み合せて示します。

例 - JDeveloper以外のファイル構造からのエクスポート

次のサンプルは、Mavenなどの構造からプロジェクトおよびその関連システム・リソースをパッケージ化する方法を示しています。このサンプルでは、2つの構成JARファイルが出力されます。1つ目はシステム・リソースを含まないプロジェクト・レベルの構成で、2つ目はJNDIおよびSMTPリソースを含むリソース・レベルの構成です。

<configjarSettings xmlns="http://www.bea.com/alsb/tools/configjar/config">
<source>
<project dir="/scratch/modulePO/src/main/resources/PO"/>
<system  dir="/scratch/modulePO/src/main/system"/>
</source>
<configjar jar="/scratch/modulePO/sbconfig-po.jar">
<projectLevel includeSystem="false"/>
</configjar>
<configjar jar="/scratch/modulePO/sbconfig-po-system.jar">
<resourceLevel>
<resources>
<include name="**/*.jndi"/>
<include name="**/*.smtp"/>
</resources>
</resourceLevel>
</configjar>
</configjarSettings>

例- プロジェクト・レベルでのエクスポート

次のサンプルは、様々な場所のシステム・リソースをパッケージ化してプロジェクトによってエクスポートする方法を示しています。構成をインポートする際に、不要なリソースを削除できます。

<configjarSettings xmlns="http://www.bea.com/alsb/tools/configjar/config">
<source>
<system dir="/scratch/moduleX/src/main/system"/>
<system dir="/scratch/moduleY/src/main/system"/>
<system dir="/scratch/moduleZ/src/main/system"/>
</source>
<configjar jar="/scratch/sbconfig-systems.jar">
<projectLevel includeSystem="true"/>
</configjar>
</configjarSettings>

例 - ロード・フェーズでのファイル拡張子の除外

このサンプルは、source要素に除外ルールを定義することで、サービス・リソース以外のすべてのリソースを構成JARファイルにパッケージ化する方法を示しています。これを次の例「エクスポート・フェーズでのファイル拡張子の除外」と比較します。パフォーマンス上の理由から、ロード・フェーズ中にファイルを除外することが推奨されます。

<configjarSettings xmlns="http://www.bea.com/alsb/tools/configjar/config">
<source>
<project dir="/scratch/jdeveloper/mywork/projectX"/>
<project dir="/scratch/jdeveloper/mywork/projectY"/>
<fileset>
<exclude name="**/*.proxy"/>
<exclude name="**/*.biz"/>
<exclude name="**/*.flow"/>
</fileset>
</source>
<configjar jar="/scratch/jdeveloper/mywork/sbconfig-resources.jar">
<resourceLevel/>
</configjar>
</configjarSettings>

例 - エクスポート・フェーズでのファイル拡張子の除外

次のサンプルは、configjar要素に除外ルールを定義することで、サービス・リソース以外のすべてのリソースを構成JARファイルにパッケージ化する方法を示しています。

<configjarSettings xmlns="http://www.bea.com/alsb/tools/configjar/config">
<source>
<project dir="/scratch/jdeveloper/mywork/projectX"/>
<project dir="/scratch/jdeveloper/mywork/projectY"/>
</source>
<configjar jar="/scratch/jdeveloper/mywork/sbconfig-resources.jar">
<resourceLevel>
<fileset>
<exclude name="**/*.proxy"/>
<exclude name="**/*.biz"/>
<exclude name="**/*.flow"/>
</fileset>
</resourceLevel>
</configjar>
</configjarSettings>

例 - ファイル拡張子のマッピング

次の例は、追加のファイル拡張子を特定のService Busリソース・タイプ(ここでは、XQueryおよびXMLタイプ)にマップする方法を示しています。

<configjarSettings xmlns="http://www.bea.com/alsb/tools/configjar/config">
<source>
<project dir="/scratch/jdeveloper/mywork/projectX"/>
<project dir="/scratch/jdeveloper/mywork/projectY"/>
<extensionMapping>
<mapping type="Xquery" extensions="xquery,xq,xqy"/>
<mapping type="XML" extensions="toplink"/>
</extensionMapping>
</source>
<configjar jar="/scratch/jdeveloper/mywork/sbconfig.jar">
<resourceLevel/>
</configjar>
</configjarSettings>

注意:

ファイル拡張子をマップする際、タイプ属性がcom.bea.wli.config.Refに定義されているService Busリソース・タイプに一致している必要があります。詳細は、「Oracle Service Bus Java APIリファレンス」を参照してください。

44.4.4.5 エクスポート設定ファイルのスキーマ定義

次に、エクスポート設定XMLファイルのスキーマ定義を示します。読みやすくするために、テキストの一部がラップされています。

<?xml version="1.0"?>
<xs:schema targetNamespace="http://www.bea.com/alsb/tools/configjar/config"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://www.bea.com/alsb/tools/configjar/config">
<xs:element name="configjarSettings" type="tns:configjarSettings"/>
<xs:complexType name="configjarSettings">
<xs:sequence>
<xs:element name="source" type="tns:source" />
<xs:element name="configjar" type="tns:configjar" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="source">
<xs:sequence>
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="project">
<xs:complexType>
<xs:attribute name="dir" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="system">
<xs:complexType>
<xs:attribute name="dir" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
</xs:choice>
<xs:element name="extensionMapping" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="mapping" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="type" type="xs:string" use="required"/>
<xs:attribute name="extensions" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="fileset" type="tns:contentSet" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="configjar">
<xs:sequence>
<xs:choice minOccurs="1" maxOccurs="1">
<xs:element name="projectLevel" type="tns:projectLevel"/>
<xs:element name="resourceLevel" type="tns:resourceLevel"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="jar" type="xs:string" use="required"/>
<xs:attribute name="overwrite" type="xs:boolean" use="optional" default="true"/>
</xs:complexType>
<xs:complexType name="projectLevel">
<xs:sequence>
<xs:element name="project" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="includeSystem" type="xs:boolean" use="optional"
default="false"/>
</xs:complexType>
<xs:complexType name="resourceLevel">
<xs:sequence>
<xs:element name="resources" type="tns:contentSet" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="includeDependencies" type="xs:boolean" use="optional"
default="true"/>
</xs:complexType>
<xs:complexType name="contentSet">
<xs:sequence>
<xs:element name="include" type="tns:contentSetPattern" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="exclude" type="tns:contentSetPattern" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="contentSetPattern">
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>
</xs:schema>

45 メタデータ・サービス・リポジトリを使用したデータの共有

JDeveloperを使用する場合、共通のメタデータ・サービス(Metadata Services: MDS)リポジトリを使用して、Service BusアプリケーションおよびSOA Suiteアプリケーション用に生成されたアーティファクトを格納および共有できます。このリポジトリを使用して、作成したアーティファクトのバックアップを作成し、デプロイされたアーティファクトを複数のサーバー、インスタンス、アプリケーションおよび製品の間で共有します。

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

- Service BusおよびMDSリポジトリ

- MDSリポジトリの管理

- MDSリポジトリを使用したアーティファクトの共有

- MDSリポジトリに格納されたアーティファクトの使用

MDSリポジトリの詳細は、Oracle SOA SuiteでのSOAアプリケーションの開発の設計時のMDSリポジトリを使用した共有データの管理に関する項を参照してください。

UDDIレジストリを使用してアーティファクトを共有することも可能です。詳細は、「UDDIレジストリの操作」を参照してください。

45.1 Service BusおよびMDSリポジトリ

MDSリポジトリは、Oracle Fusion Middlewareコンポーネントに関する情報を格納します。リポジトリはファイル・ベースまたはデータベース・ベースにできますが、いくつかの設計時アクティビティはファイル・ベースのリポジトリに対してのみ実行できます。リポジトリ・タイプの完全な詳細は、Oracle Fusion Middlewareの管理のメタデータ・リポジトリの管理に関する項を参照してください。

ファイル・ベースの設計時MDSリポジトリおよび接続は、JDeveloperでService Busアプリケーションを作成するときに自動的に含まれます。この接続を変更して、既存の様々なリポジトリを指すか、新しい接続を作成して様々なリポジトリを指すことができます。操作の共有は、設計時のリポジトリに対して実行され、データベースに支持されたMDSリポジトリに対しては実行できません。

JDeveloperの「リソース」ウィンドウでは、MDSリポジトリに格納されているフォルダおよびアーティファクトを参照できます。フォルダの作成および削除、Service BusおよびSOA Suiteのアーティファクトの追加、インポートおよび削除、リポジトリに格納されたWSDLファイルからのService Busビジネス・サービスの生成も実行できます。「リソース」ウィンドウでは、リポジトリからのアーティファクトのエクスポート、リポジトリへのアーティファクトのインポートを、両方ともJARファイルの形式で実行できます。次の図に、「リソース」ウィンドウのMDSリポジトリのService Busコンポーネントを示します。

図45-1 MDSリポジトリのService Busアーティファクト

MDSリポジトリの詳細は、Oracle SOA SuiteでのSOAアプリケーションの開発の設計時のMDSリポジトリ管理の概要に関する項を参照してください。

45.2 MDSリポジトリの管理

MDSリポジトリで一般的な管理タスク(ソース・データによるリポジトリのシード、あるリポジトリのコンテンツの別のリポジトリへの転送、フォルダの作成と削除、アーティファクトのインポートとエクスポートなど)を実行できます。Oracle SOA SuiteによるSOAアプリケーションの開発の次の各項目では、リポジトリの管理に役立つ情報を提供します。

- デフォルトのSOA-MDS接続へのソース・データの入力

- /appsフォルダの下におけるサブフォルダの作成と削除

- JARファイルへの/appsフォルダの選択内容のエクスポート

- /appsフォルダへのJARファイルの内容のインポート

- 別のMDSリポジトリへの/appsフォルダの選択内容の転送

45.3 MDSリポジトリを使用したアーティファクトの共有

設計時のMDSリポジトリを使用してService Busのアーティファクト・タイプ(WSDL、WADL、JCA、JAR、相互参照、ドメイン値マップ、WSポリシー、XSD、XML、XSLT、MFLおよびXQueryの各ファイル)を共有できます。これらのファイルは、他のService Busアプリケーションと共有できます。また、これらのアーティファクト・タイプの多くではSOA Suiteアプリケーションと共有できます。

45.3.1 Service BusアーティファクトをMDSリポジトリにパブリッシュする方法

プロジェクト・コンポーネントは、「SOA-MDS転送」ウィザードを使用して、MDSリポジトリにパブリッシュされます。このウィザードにアクセスするには、共有可能なコンポーネントを右クリックします。これらのコンポーネントは、他のService BusアプリケーションおよびSOA Suiteアプリケーションと共有できます。

始める前に

MDSリポジトリのアーティファクトを作業するには、JDeveloperからそのリポジトリに対する接続を作成する必要があります。手順については、「SOA-MDS接続の作成方法」を参照してください。

Service BusアーティファクトをMDSリポジトリにパブリッシュするには:

1. インポートするコンポーネントがJDeveloperエディタで開いていないことを確認します。また、コンポーネントが依存するファイル(XMLスキーマ・ファイルなど)をすべて閉じます。

2. JDeveloperのアプリケーション・ナビゲータで、MDSリポジトリにパブリッシュするコンポーネントを表示します。

3. コンポーネントを右クリックし、「Service Bus」を指し、「SOAデザインタイム・リポジトリにパブリッシュ」を選択します。
「SOA-MDS転送」ウィザードが表示され、パブリッシュするコンポーネントがリストされます。

4. 「次へ」をクリックします。

5. 「ターゲットの選択」ウィンドウで、Service Busコンポーネントをパブリッシュする場所にフォルダを展開します。

図45-2 「SOA-MDS転送ウィザード」 - 「ターゲットの選択」ウィンドウ

6. 新しいフォルダを追加するには、次の作業を実行します。

a. 新しいフォルダを作成するフォルダを選択します。

b. 「フォルダの作成」アイコンをクリックします。

c. 新しいフォルダの名前を入力して「OK」をクリックします。
ツリーに新しいフォルダが表示されます。

7. MDSリポジトリに存在するコンポーネントまたはフォルダを検索するには、検索フィールドに名前の全部または一部を入力します。入力した下に結果が表示されます。

図45-3 「SOA-MDS転送ウィザード」 - 「ターゲットの検索」

8. 選択したコンポーネントのパブリッシュ先のフォルダを選択し、「次」をクリックします。

9. 「依存性」ウィンドウで、MDSリポジトリにコピーするファイルを確認します。
このウィンドウには、コピーすることを選択したファイルおよびそのファイルが依存するファイルが表示されます。

図45-4 「SOA-MDS転送ウィザード」 - 「依存性」ウィンドウ

10. MDSリポジトリの既存のファイルを上書きするには、「ドキュメントがターゲットMDSリポジトリに存在する場合は上書きします」を選択します。

11. 「終了」をクリックします。

12. 確認ダイアログで、「OK」をクリックします。
SOA-MDS接続でコピーしたファイルをJDeveloperの「リソース」ウィンドウに表示できるようになります。

45.4 MDSリポジトリに格納されたアーティファクトの使用

Service Busアプリケーションは、MDSリポジトリに格納されたアーティファクトを使用するとき、SOA Suiteアプリケーションが行うようなリポジトリのファイルの参照を行いません。かわりに、ファイルがService Busアプリケーションにインポートされます。MDSリポジトリに格納されているアーティファクトは、JDeveloperの「リソース」ウィンドウから直接使用するか、「選択」ダイアログを使用してアーティファクト(WSDLファイルなど)を追加することで使用できます。「選択」ダイアログには、ビジネス・サービスやプロキシ・サービスなどのコンポーネントの作成と構成に使用するウィザードおよびエディタからアクセスします。

45.4.1 リソース・ブラウザを使用してMDSリポジトリのアーティファクトを使用する方法

リソース・ブラウザは、パイプライン、分割結合、プロキシ・サービスまたはビジネス・サービスを作成する際にベースとなるWSDLファイルを選択するときに、ほとんどの場合Service Busで起動されます。これは、「タイプ・チューザ」ダイアログでWSDLファイルまたはXMLファイルをインポートする場合、あるいはXSLTマップやXQueryマップをパイプライン・アクションにインポートする場合も表示されます。

始める前に

MDSリポジトリのアーティファクトを作業するには、JDeveloperからそのリポジトリに対する接続を作成する必要があります。手順については、「SOA-MDS接続の作成方法」を参照してください。

リソース・ブラウザを使用してアーティファクトを使用するには:

1. Service Busコンポーネントの作成または構成でMDSリポジトリからファイルを選択する必要がある時点に到達したら、既存のファイルを選択できるアイコンをクリックします。

たとえば、WSDLドキュメントをベースにしてプロキシ・サービスを作成する場合、フィールドの右にある「WSDLの選択」をクリックします。

図45-5 「パイプライン・サービスの作成」ウィザードの「WSDLの選択」アイコン

2. 「リソース・ブラウザ」の上部で、SOA-MDSを選択します。

図45-6 「リソース・ブラウザ」

3. 「リソース・ブラウザ」の下部で、フォルダを展開して、使用するファイルを選択し、「OK」をクリックします。

「Service Busリソースのインポート」ウィザードが表示されます(Service Busでは、参照リポジトリ・ファイルのかわりにコピーするため)。

4. ソース・ファイルの情報を確認し、必要な変更を行います。「次」をクリックします。

5. 「構成」ウィンドウで、インポートするアーティファクトがすべて選択されていることを確認します。「終了」をクリックします。

ファイルおよびその依存関係が現在のプロジェクトにインポートされ、ファイルの情報が適切なフィールドに入力されます。

6. Service Busコンポーネントの作成または構成を続けます。

45.4.2 MDSリポジトリのアーティファクトをService Busプロジェクトに追加する方法

Service Busは、MDSリポジトリからサポートされているリソース・タイプのみを使用できます。Service Busリソースとして認識されるリソースは、Service Busプロジェクトにインポートできます。アーティファクトをインポートすると、Service Busは「Service Busリソースのインポート」ウィザードを起動し、選択したプロジェクトにリソースを追加します。

始める前に

MDSリポジトリのアーティファクトを作業するには、JDeveloperからそのリポジトリに対する接続を作成する必要があります。手順については、「SOA-MDS接続の作成方法」を参照してください。

リポジトリのアーティファクトをService Busプロジェクトに追加するには:

1. 「リソース」ウィンドウをJDeveloperで表示できない場合、「ウィンドウ」メニューをクリックし、「リソース」を選択します。

2. 「リソース」ウィンドウで、SOA-MDSおよびリポジトリ名(デフォルト名はSOA_DesignTimeRepository)を展開します。

3. プロジェクトに追加するアーティファクトが見つかるまでフォルダを展開します。

ヒント:

かわりに、「リソース」ウィンドウの「検索」フィールドに名前全体または一部を入力し、Enterキーを押してそのアーティファクトを検索します。

4. アーティファクトを右クリックし、「Service Bus」を指し、「リソースのインポート」を選択します。

「Service Busリソースのインポート」ウィザードが表示されます。

5. ソース・ファイルの情報を検証して、インポートしたファイルの名前と場所に必要な変更を加えます。「次」をクリックします。

6. 「構成」ウィンドウで、インポートするアーティファクトがすべて選択されていることを確認します。「終了」をクリックします。

新しいリソースが指定した場所に追加され、Service Busプロジェクトで使用できるようになります。

45.4.3 MDSリポジトリのWSDLファイルからビジネス・サービスを作成する方法

MDSリポジトリのWSDLドキュメントからService Busのビジネス・サービスを生成できます。このオプションを選択すると、「ビジネス・サービスの作成」ウィザードが表示され、ビジネス・サービスの定義を追加できます。ビジネス・サービスが生成されると、XMLスキーマ・ファイルなどの依存関係とともに、WSDLファイルがService Busプロジェクトにインポートされます。

始める前に

MDSリポジトリのアーティファクトを作業するには、JDeveloperからそのリポジトリに対する接続を作成する必要があります。手順については、「SOA-MDS接続の作成方法」を参照してください。

MDSリポジトリのWSDLファイルからビジネス・サービスを作成するには:

1. 「リソース」ウィンドウをJDeveloperで表示できない場合、「ウィンドウ」メニューをクリックして、「リソース」を選択します。

2. 「リソース」ウィンドウで、SOA-MDSおよびリポジトリ名(デフォルト名はSOA_DesignTimeRepository)を展開します。

3. ビジネス・サービスに使用するWSDLファイルが見つかるまでフォルダを展開します。

ヒント:

かわりに、「リソース」ウィンドウの「検索」フィールドに名前全体または一部を入力し、Enterキーを押してそのWSDLファイルを検索します。

4. WSDLファイルを右クリックし、「Service Bus」を指し、「ビジネス・サービスの生成」を選択します。

「ビジネス・サービスの作成」ウィザードが表示されます。

5. 「サービス・アーティファクト・フォルダ」フィールドの横の「参照」をクリックし、WSDLファイルの追加先のプロジェクトまたはフォルダを参照して選択します。「選択」をクリックします。

6. 「ビジネス・サービスの作成」ウィザードで、「次」をクリックします。

7. 「サービスの作成」ウィンドウで、デフォルト値を受け入れるかまたは次の変更を行います。

- サービスに割り当てたデフォルト名を変更します。

- ビジネス・サービスの説明を追加します。

- WSDLドキュメントから異なるポートを選択します。

8. 「次」をクリックします。

9. 「トランスポート」ウィンドウで、デフォルト値を受け入れるかまたは次の変更を行います。

- 新しい転送プロトコルを選択します。

- エンドポイントURIを変更します。

10. 「終了」をクリックします。

新しいリソースが指定した場所に追加されます。

11. 「ビジネス・サービスの構成」の説明に従って、ビジネス・サービスの構成を続けます。

45.4.4 MDSリポジトリのWADLファイルからビジネス・サービスを作成する方法

MDSリポジトリのWADLドキュメントからService Busのビジネス・サービスを生成できます。このオプションを選択すると、「RESTバインディングの作成」ウィザードが表示され、RESTサービスを構成できます。ビジネス・サービスとWSDLファイルが生成され、XMLスキーマ・ファイルなどの依存関係とともに、WADLファイルがService Busプロジェクトにインポートされます。

始める前に

MDSリポジトリのアーティファクトを作業するには、JDeveloperからそのリポジトリに対する接続を作成する必要があります。手順については、「SOA-MDS接続の作成方法」を参照してください。

MDSリポジトリのWADLファイルからビジネス・サービスを作成するには:

1. JDeveloperのアプリケーション・ナビゲータで、RESTビジネス・サービスを追加するアプリケーションを開き、そのサービスを配置するプロジェクトまたはフォルダを選択します。

2. 「リソース」ウィンドウを表示できない場合、「ウィンドウ」メニューをクリックして、「リソース」を選択します。

3. 「リソース」ウィンドウで、SOA-MDSおよびリポジトリ名(デフォルト名はSOA_DesignTimeRepository)を展開します。

4. ビジネス・サービスに使用するWADLファイルが見つかるまでフォルダを開きます。

ヒント:

あるいは、「リソース」ウィンドウの「検索」フィールドに名前全体または一部を入力し、[Enter]を押してそのWADLファイルを検索します。

5. WADLファイルを右クリックし、「Service Bus」を指し、「ビジネス・サービスの生成」を選択します。

RESTバインディングの作成ウィザードが表示されます。

6. RESTバインディングの名前を入力します。

7. 「ベースURI」を入力します。これは、ビジネス・サービスのエンドポイントURIです。

8. JSONペイロードをXMLスキーマ内の要素の順序に応じて並べ替えるように指定するには、「XMLSchemaの順序付けを強制」を選択します。

9. 残りの構成は、選択したWADLファイルに基づきます。「OK」をクリックします。

インポートするリソースがある場合は、「Service Busリソースのインポート」ウィザードが表示されます。

10. オプションで、インポートするリソースの新しい名前とインポートの場所を指定します。

11. 「次」をクリックします。

12. インポートするリソースの概要を確認して、「終了」をクリックします。

WADLファイル、WSDLファイルおよび従属リソースは、選択したプロジェクトの「リソース」フォルダに追加されます。ビジネス・サービスがプロジェクトに追加されます。

13. 「ビジネス・サービスの構成」の説明に従って、ビジネス・サービスの構成を続けます。

45.4.5 MDSリポジトリのWSDLファイルをRESTサービスとして公開する方法

MDSリポジトリのWSDLドキュメントからRESTビジネス・サービスおよびプロキシ・サービスを生成できます。このオプションを選択すると、「ビジネス・サービスの作成」ウィザードが表示され、続けて「RESTバインディングの作成」ウィザードが表示されます。Service Busサービスが生成され、XMLスキーマ・ファイルなどの依存関係とともに、WSDLファイルとWADLファイルがService Busプロジェクトにインポートされます。

始める前に

MDSリポジトリのアーティファクトを作業するには、JDeveloperからそのリポジトリに対する接続を作成する必要があります。手順については、「SOA-MDS接続の作成方法」を参照してください。

MDSリポジトリのWSDLファイルをRESTサービスとして公開するには:

1. JDeveloperのアプリケーション・ナビゲータで、RESTサービスを追加するアプリケーションを開き、そのサービスを配置するプロジェクトまたはフォルダを選択します。

2. 「リソース」ウィンドウを表示できない場合、「ウィンドウ」メニューをクリックして、「リソース」を選択します。

3. 「リソース」ウィンドウで、SOA-MDSおよびリポジトリ名(デフォルト名はSOA_DesignTimeRepository)を展開します。

4. RESTサービスとして公開するWSDLファイルが見つかるまでフォルダを開きます。

ヒント:

かわりに、「リソース」ウィンドウの「検索」フィールドに名前全体または一部を入力し、Enterキーを押してそのWSDLファイルを検索します。

5. WSDLファイルを右クリックし、「Service Bus」を指し、「RESTとして公開」を選択します。

「ビジネス・サービスの作成」ウィザードが表示されます。

6. 「サービス・アーティファクト・フォルダ」フィールドの横で「参照」をクリックして、リソースおよびサービスを追加するプロジェクトまたはフォルダに移動してそれを選択します。「選択」をクリックします。

7. 「ビジネス・サービスの作成」ウィザードで、「次」をクリックします。

8. 「サービスの作成」ウィンドウで、デフォルト値を受け入れるかまたは次の変更を行い、「次」をクリックします。

- サービスに割り当てたデフォルト名を変更します。

- ビジネス・サービスの説明を追加します。

- WSDLドキュメントから異なるポートを選択します。

9. 「トランスポート」ウィンドウで、デフォルト値を受け入れるかまたは次の変更を行います。

- 新しい転送プロトコルを選択します。

- エンドポイントURIを変更します。

10. 「終了」をクリックします。

RESTバインディングの作成ウィザードが表示されます。

11. オプションで、RESTサービスの新しい名前と説明を入力します。

12. JSONペイロードをXMLスキーマ内の要素の順序に応じて並べ替えるように指定するには、「XMLSchemaの順序付けを強制」を選択します。

13. 新しいリソース・パスを入力するには、「リソース」セクションで「追加」アイコンをクリックします。

14. 必要に応じて、「操作バインディング」セクションの「HTTP動詞」列をダブルクリックして、メソッドを構成します。

15. 「OK」をクリックします。

16. 「ファイルのローカライズ」ダイアログが表示され、元のディレクトリ構造を維持する必要がない場合は、チェック・ボックスを選択解除して、「OK」をクリックします。

17. 「ビジネス・サービスの構成」の説明に従って、ビジネス・サービスの構成を続けます。

18. 「プロキシ・サービスの構成」の説明に従って、プロキシ・サービスの構成を続けます。

45.4.6 SOA-MDS接続を使用してプロジェクト概要ファイルを開く

JDeveloperでSOA-MDS接続を作成し、その接続を開いて、「リソース」ウィンドウからService Busプロジェクトのservicebus.sboverviewファイルまたはSOAコンポジット・アプリケーションのoverview.xmlファイルを開こうとすると、ファイルが正しくロードされない場合があります。これらのファイルを開くのは、アプリケーション・ナビゲータからのみとしてください。

Oracle MDSリポジトリについては、Oracle Fusion Middlewareの管理を参照してください。

window.name='GUID-FA2E58B2-64DF-4EE3-B5B6-EA03956AE625' function footdisplay(footnum,footnote) { var msg = window.open('', 'NewWindow' + footnum, 'directories=no,height=120,location=no,menubar=no,resizable=yes,' + 'scrollbars=yes,status=no,toolbar=no,width=598'); msg.document.open('text/html'); }
46 UDDIレジストリの操作

この章では、UDDI (Universal Description, Discovery, and Integration)レジストリでService Busを使用する方法について説明します。

この章の構成は、次のとおりです。

- UDDI、UDDIレジストリおよびWebサービス

- Service BusとUDDI

- サービスの同期化の維持

- 関連リファレンス

- UDDIレジストリ・リソースの操作

- JDeveloperでのUDDIレジストリ・サービスの共有

- Oracle Service BusコンソールでのUDDIレジストリ・サービスの共有

- Service BusとUDDIのビジネス・シナリオの例

- Service Busプロキシ・サービスからUDDIエンティティへのマッピング

46.1 UDDI、UDDIレジストリおよびWebサービス

UDDIは、企業のビジネス、ビジネス・サービス、および公開するサービスの技術的な詳細を分類するためのフレームワークを提供します。UDDIプロジェクトは、企業間取引を迅速、容易、かつ動的に検索および実施できるようにすることを目指す業界イニシアティブです。UDDIレジストリには、ビジネス、ビジネスが提供するサービス、およびビジネスがトランザクションを実行するために使用する通信規格とインタフェースに関する情報がカタログ化されて格納されます。UDDIレジストリは、サービスの検索、サービスの呼び出し、およびサービスのメタデータ(セキュリティ、トランスポート、またはサービスの品質)の管理のための標準ベースの基盤インフラストラクチャです。UDDIレジストリでは、任意のカテゴリ化によってこれらのメタデータを格納し提供します。これらのカテゴリ化を分類法と呼びます。

組織は、UDDIレジストリを使用してWebサービスを共有します。UDDIレジストリを使用することで、企業はWebサービスを整理してカタログ化し、企業内または信頼できる外部のパートナと共有および再利用できます。UDDIバージョン3.0の仕様は、http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3で確認できます。

UDDIレジストリは、この仕様に基づいています。この仕様には、UDDIを使用してWebサービスの情報をパブリッシュおよび検索する方法の詳細が記載されています。仕様はサービスの実行時の様相は定義していません(それは、サービスの単なるディレクトリです)。UDDIは、企業のビジネス、ビジネス・サービス、および公開するサービスの技術的な詳細を分類するためのフレームワークを提供します。

レジストリへサービスをパブリッシュするには、サービス・タイプと、レジストリ内でそのサービスを表すデータ構造の知識が必要です。特定のプロパティは、各レジストリのエントリと関連付けられ、これらのプロパティ・タイプはレジストリの作成時に定義されます。レジストリにサービスをパブリッシュして、他の組織がそのサービスを検出して使用できるようにすることが可能です。Service Busで開発されたプロキシ・サービスは、UDDIレジストリにパブリッシュできます。Service Busは、バージョン3.0に準拠したUDDIレジストリと相互作用します。

図46-1は、Service BusとUDDIレジストリの統合を示しています。

図46-1 Oracle Service BusとUDDIの統合

Service BusのWebベース・インタフェースにより、レジストリにアクセスして簡単に利用できます。Service BusをUDDIと組み合せて使用することにより、規格準拠のWebサービスの再利用が促進されます。この方法で、Service Busレジストリのエントリを複数のドメインで検索、検出および使用できます。WebサービスとUDDIは一連の規格に基づいて構築されるため、再利用により、テストされて条件を満たしたWebサービスやアプリケーション開発規格の使用が企業全体で促進されます。Webサービスとインタフェースは、タイプ、機能または分類別にカタログ化できるため、検出や管理がさらに容易になります。

46.1.1 UDDI仕様の基本概念

UDDIは、HTTP、XML、XSD (XMLスキーマ定義)、SOAP、WSDLなど、確立された複数の業界標準に基づいています。UDDI仕様には、Webサービスのレジストリとそのプログラムのインタフェースが記述されています。UDDI自体が、Webサービスのセットです。UDDI仕様は、次に関する記述と検出をサポートするサービスを定義しています。

- ビジネスや組織などのWebサービス提供者

- これらのWebサービス提供者が公開するWebサービス

- これらのサービスのアクセスと管理に使用できる技術的なインタフェース

46.1.2 Service BusでUDDIレジストリを使用する利点

UDDIレジストリには、ビジネス・サービスに関するデータとメタデータが格納されます。UDDIレジストリは、他のアプリケーションがWebサービスを検出して使用できるように、Webサービスを分類、カタログ化および管理する標準ベースのメカニズムを提供します。UDDIは、設計時と実行時の両方において、IT管理者と開発者に次のような利点をもたらします。

- サービスに関する情報をレジストリにパブリッシュし、検出用にサービスを分類することで、インフラストラクチャの管理が向上します。UDDIでは、増加し続けるサービスのポートフォリオを分類できるため、サービスを管理しやすくなるだけでなく、コンポーネント間の関係を理解する上でも役立ちます。さらに、バージョン管理をサポートし、依存関係を管理することができます。

- UDDIサービスをレジストリからインポートして、Webサービスを呼び出すために必要なパラメータ、および必要なトランスポート・プロトコルとセキュリティ・プロトコルを構成できます。

- UDDIは、規格準拠のWebサービスの使用およびビジネス・アプリケーションでのビジネス・サービスの開発を促進し、Webサービス開発者にリソース・ライブラリへのリンクを提供します。これにより、開発時間が短縮され、生産性が向上します。また、規格準拠のリソースを共有することで、ビジネス・アプリケーション間の相互運用性の実現の可能性が増加します。

- UDDIは、Webサービスの検索と検出のためのユーザー・フレンドリなインタフェースを提供します。

46.1.3 UDDIエンティティの概要

UDDIは、特定のデータ・モデルを使用して、組織とサービスを定義するエンティティを表します。図46-2に、様々なUDDIエンティティの間の関係を示します。

図46-2 組織とサービスを表すUDDIエンティティ

表46-1に、UDDIエンティティの概要を示します。

表46-1 UDDIエンティティの概要

UDDIエンティティ

説明

ビジネス・エンティティ

サービスを所有および提供する組織またはグループ。ビジネス・エンティティは、サービス提供者の名前、説明、および連絡先詳細のセット、ビジネス・エンティティの特徴を表すカテゴリ、ユニークな識別子、および検出URLのセットで記述できます。

ビジネス・サービス

ビジネス・エンティティが提供する機能またはリソースの説明。ビジネス・サービスは、名前、説明、およびサービスの機能を表す一連のカテゴリで記述されます。UDDIレジストリのビジネス・サービスは、必ずしもWebサービスを表すわけではありません。UDDIレジストリでは、EJBやCORBAなどの任意のサービスを登録できます。

バインディング・テンプレート

ビジネス・サービスを呼び出す方法の技術的な詳細。ビジネス・サービスには、1つまたは複数のバインディング・テンプレートを含めることができます。バインディング・テンプレートは、サービス・エンドポイントを表すアクセス・ポイント(エンドポイントURIとプロトコル仕様)、tModelインスタンス情報、およびバインディング・テンプレートの特定の機能を参照するカテゴリで記述されます。

tModel

UDDIレジストリでのサービスの表現方法を記述する技術仕様(通常は仕様のポインタまたは仕様ドキュメントに関するメタデータ)。サービスの記述には、名前、説明、概要ドキュメント(tModelの目的を示すドキュメントへの参照)、カテゴリおよび(tModelを一意に識別する)識別子が含まれます。

46.2 Service BusとUDDI

Service Busは、UDDIのバージョン3.0実装に準拠する任意のUDDIレジストリを使用します。Service BusをUDDIレジストリとともに使用することによって、次の処理を実行できます。

- 1つまたは複数のV3.0準拠のUDDIレジストリを使用するようにService Busを構成します。

- ユーザーがサービスをパブリッシュおよびインポートできるように、レジストリを構成します。

- プロキシ・サービスに関する情報をレジストリにパブリッシュします。

- レジストリで特定のサービスを検索します。また、使用可能なすべてのサービスのリストを表示します。ビジネス・エンティティ、サービス名のパターン、またはこの両方で検索できます。

- レジストリからビジネス・サービスをインポートします。

46.2.1 UDDIレジストリのURL

Service BusでUDDIレジストリを構成するとき、様々なタイプのUDDIレジストリのアクセスにいくつかのAPIエンドポイントURLを指定します。これらのURLには次のものが含まれます。

- 照会URL: サービスの検索とインポートで使用される照会APIエンドポイントのURL。

- パブリッシュURL: サービスのパブリッシュで使用されるパブリッシュAPIエンドポイントのURL。

- セキュリティURL: レジストリへのパブリッシュを行うために必要な認証トークンの取得に使用される、セキュリティAPIエンドポイントのURL。

- サブスクリプションURL: レジストリの変更へのサブスクリプション、レジストリのサブスクリプションの作成、インポート・サービスに変更がないかどうかのリスンのために使用される、サブスクリプションAPIエンドポイントのURL。

46.2.2 UDDIレジストリのセキュリティ構成

UDDIレジストリをService Busで使用できるようにするには、UDDIレジストリの接続情報を定義するUDDIレジストリ・リソースを作成します。Service Busプロキシ・サービスのレジストリに対するパブリッシュまたはプロキシ・サービスで使用するビジネス・サービスのレジストリからのインポートを実行できます。リソースでUDDI URLを指定し、セキュリティ情報をオプションで指定します。サービスをほとんどのレジストリにパブリッシュする場合、レジストリにアクセスするときの認証用に有効なユーザー名とパスワードをプロキシ・サービス構成に含める必要があります。

複数のユーザー名とパスワードを使用してレジストリを設定できるため、関連付けられたサービス・アカウントに基づいて、ユーザーごとに異なるパーミッションを使用できます。Service Busでは、ユーザー・パーミッションによってレジストリ、レジストリの内容および使用できる機能へのアクセスを管理します。

46.2.3 認証およびUDDIレジストリ

プロキシ・サービスがUDDIレジストリにパブリッシュされると、サービスはWSDLドキュメントを使用するWSビジネス・サービスに変換されます。認証の構成がある場合は、これもUDDIにエクスポートされます。WSRMポリシーを使用するWSDLベースのビジネス・サービスがUDDIレジストリからService Busにインポートされる場合は、サービスは自動的にWSトランスポートを使用するように構成されたWSビジネス・サービスとしてインポートされます。

トランスポート・レベルのカスタム認証トークンは、UDDIにパブリッシュされます。client-authプロパティは、認証の構成時にHTTPまたはHTTPSトランスポート属性のinstanceParmsにあります。「トランスポート属性」で説明されているとおり、client-authに指定可能な値はBASIC、CLIENT-CERTおよびCUSTOM-TOKENです。値がCUSTOM-TOKENの場合は、さらにtoken-headerとtoken-typeという2つのプロパティが必ず存在します。

注意:

Service Busビジネス・サービス定義は、カスタム・トークン認証をサポートしていません。client-authがCUSTOM-TOKENであるUDDIからサービスをインポートする場合、認証の構成が何もないかのようにサービスがインポートされます。

46.2.4 UDDIレジストリへのプロキシ・サービスのパブリッシュについて

Oracle Service BusコンソールまたはJDeveloperを使用して、プロキシ・サービスをUDDIレジストリにパブリッシュし、他の組織がそのサービスを検索および使用できるようにします。Service Busで開発されたプロキシ・サービスはすべて、UDDIレジストリにパブリッシュできます。パブリッシュするサービスを含めるビジネス・エンティティを選択できます。また、複数のサービスを一度にパブリッシュできます。

これを行うには、UDDIレジストリにユーザー・アカウントを設定しておく必要があります。任意のプロキシ・サービスをUDDIレジストリにパブリッシュできます。また、サービスがパブリッシュされるビジネス・エンティティを選択できます。ビジネス・エンティティの管理(エンティティの作成、取消し、更新、削除など)は、レジストリ・ベンダーが提供する管理コンソールを使用して行います。レジストリに初めてパブリッシュするときに、そのレジストリにtModelsをロードする必要があります。これは、パブリッシュする詳細をコンソールまたはJDeveloperで構成するときに行います。UDDIレジストリにパブリッシュする方法の詳細は、「UDDIレジストリへのプロキシ・サービスのパブリッシュ」を参照してください。

注意:

UDDIレジストリからサービスをインポートする際に、このサービスのレジストリへのパブリッシュ元であるService Busクラスタで、クラスタリングされたサーバーがlocalhostアドレスを使用している場合は、エラーが発生することがあります。特に、インポート中のサービスが、他のリソース(WSDLまたはXSD)を参照するリソース(WSDLまたはXSD)を参照している場合に、このエラーが発生します。

クラスタリングされたドメインからUDDIレジストリにサービスをパブリッシュする前に、クラスタ内のいずれのサーバーもサーバー・アドレスにlocalhostを使用していないことを確認します。かわりに、マシン名かIPアドレスを使用します。

ローカル・プロキシ・サービスをService Bus汎用プロキシ・サービスに関連付けるために、サービスをUDDIレジストリにパブリッシュできます。たとえば、具体的なWSDLファイルを使用する複数のローカル・トランスポート・プロキシ・サービスに動的にルーティングする任意のSOAPまたは任意のXML汎用プロキシ・サービスを使用できます。また、ビジネス・サービスがアタッチされたService Bus2の汎用プロキシ・サービスに動的にルーティングするService Bus1の汎用プロキシ・サービスを使用することもできます。UDDIレジストリから、ローカル・プロキシ・サービスのWSDLファイルと、任意のSOAPまたは任意のXML汎用プロキシ・サービスのURLを取得できます。WSDLファイルとURLを組み合せることで、汎用プロキシ・サービスを介してローカル・プロキシ・サービスにメッセージを送信するための有効なWSDLファイルが作成されます。

46.2.5 UDDIレジストリからのサービスのインポートについて

UDDIレジストリにあるサービスをService Busビジネス・サービスとしてインポートできます。WSDLベースのサービスをインポートする場合、複数のUDDIバインディング・テンプレートがあると、Service Busはバインディング・テンプレートごとに異なるビジネス・サービスを作成します。

Service BusでUDDIレジストリへのアクセスに必要なセキュリティ・ロールの詳細は、『Oracle Service Busの管理』のOracle Service Busにおけるロール・ベースのアクセスに関する項を参照してください。インポート時に、使用可能なレジストリのリストから選択します。Oracle Service Busコンソールで、UDDIフォルダ定義エディタにレジストリの全リストを表示できます。レジストリからインポートすると、そのレジストリを照会してサービスを検出できます。JDeveloperで、使用可能なレジストリを「リソース」ウィンドウに表示し、リストを参照してサービスを検出できます。レジストリのエントリは一意です。

次のビジネス・サービスの種類をUDDIレジストリからService Busにインポートできます。

- WSDL over HTTPバインディング。複数のUDDIバインディング・テンプレートがある場合、バインディング・テンプレートごとにビジネス・サービスが作成されます。

- SOAP over HTTPバインディングまたはXML over HTTPバインディング。

- Service Busサービスとして分類されたサービス。UDDIレジストリにパブリッシュされたプロキシ・サービスです。この機能は主に、あるドメインのプロキシ・サービスが別のドメインのプロキシ・サービスを検出してそこにルーティングする必要のあるマルチドメインのService Busデプロイメントで使用されます。

サービスにはドキュメントが関連付けられており、これらのドキュメントには他のいくつかのドキュメント(スキーマ、ポリシーなど)が含まれる場合があります。インポートでは、UDDIレジストリはサービスの照会URLに基づいてドキュメントの場所を示します。他のリソースを含むドキュメントまたは他のリソースを参照するドキュメントが検索された場合は、参照されているすべての情報と含まれている各項目は個別のリソースとしてService Busに追加されます。

46.2.5.1 ビジネス・エンティティおよびパターンについて

レジストリのサービスを検索する条件として、ビジネス・エンティティとパターンを使用します。Service Busによってパブリッシュされたサービスには、サービスを識別する固有のtmodelキーがあり、レジストリのサービスを検索するときに使用されます。ビジネス・エンティティがレジストリの構成の最上位ですが、ビジネス、アプリケーション・タイプなどの他の検索条件を使用できます。認証が必要な場合は、システム管理者からユーザー名とパスワードを入手する必要があります。

46.3 サービスの同期化の維持

Service Busのサービス定義とUDDIのサービス定義との同期を自動的に維持できます(双方向)。Service Busで作成または変更されたサービスを、自動的にUDDIレジストリにパブリッシュできます。また、ビジネス・サービス定義をUDDIからインポートし、元のサービスがUDDIで変更された場合に自動的に更新できます。また、サービスがUDDIレジストリで変更された場合に同期の承認を求めるメッセージを表示するよう、Oracle Service BusコンソールまたはJDeveloperを構成できます。

46.3.1 プロキシ・サービスの自動パブリッシュ

Oracle Service Busコンソールでプロキシ・サービスを構成するときに、デフォルトのUDDIレジストリに自動的にパブリッシュするようにプロキシ・サービスを構成できます。この機能はJDeveloperでは使用できません。まず、デフォルト・レジストリを設定し、デフォルト・レジストリに自動的にパブリッシュするようにプロキシ・サービスを構成する必要があります。これらの変更をアクティブ化すると、プロキシ・サービスはデフォルト・レジストリにパブリッシュされます。UDDIレジストリを使用できない場合は、パブリッシュ・アクションが再試行されます。プロキシ・サービスにさらに変更を加えると、再試行がリセットされます。プロキシ・サービスをUDDIレジストリにリパブリッシュすると、UDDIに定義されているプロキシ・サービスの分類がすべて保持されます。

手順は、「デフォルトのUDDIレジストリ・リソースを指定する方法」および「UDDIレジストリにプロキシ・サービスを自動的にパブリッシュする方法」を参照してください。

46.3.1.1 デフォルト・レジストリの変更

デフォルト・レジストリを変更すると、自動パブリッシュが有効になっているすべてのプロキシ・サービスが新しいデフォルト・レジストリにパブリッシュされます。その後、現在のデフォルト・レジストリとの同期が実行されます。プロキシ・サービスが同期されていない場合、Oracle Service Busコンソールに同期されていないことを示す非同期アイコンが表示されます。

注意:

デフォルト・レジストリを使用しているときに、インポート中に同じ論理名でデフォルト・レジストリが設定された構成JARファイルをインポートすると、ビジネス・エンティティのデフォルト・レジストリが誤った値になる可能性があります。この場合、自動パブリッシュされたプロキシ・サービスがあると、「自動パブリッシュ・ステータス」ページにエラーが表示されることがあります。これを修正するには、デフォルト・レジストリを再度選択します。

46.3.1.2 同期プロセスの自動パブリッシュ

プロキシ・サービスで自動パブリッシュが有効になっている場合、Oracle Service Busコンソールの「自動パブリッシュ・ステータス」ページを使用して、サービスの同期プロセスを表示して管理できます。このページには、パブリッシュされるプロキシ・サービスおよびそのステータスが表示されます。エラーのためにサービスがレジストリを自動的にパブリッシュできない場合、このページから再試行できます。

パブリッシュされた後にプロキシ・サービスが変更された場合、Oracle Service Busコンソールの管理機能を使用して変更を同期化できます。自動パブリッシュが有効になっている場合、Service Busは、レジストリのサービスにすべての変更を自動的にパブリッシュします。また、「自動パブリッシュ・ステータス」ダイアログにこのサービスが表示され、レジストリにサービスをパブリッシュするためのオプションが提供されます。

46.3.2 UDDIサービスの自動インポート

自動インポート機能を使用すると、UDDIレジストリからインポートしたビジネス・サービスをレジストリ内の対応するサービスと同期できます。手順は、「インポートしたサービスを自動的に同期する方法」を参照してください。

注意:

自動インポートは、Oracle Service Busコンソールでのみ使用できます。JDeveloperでは使用できません。

サービスが更新された場合、UDDIレジストリ・リソースで自動インポートが有効になっていないかぎりにおいてはレジストリからサービスを再度インポートして最新バージョンを取得する必要があります。「自動インポートの有効化」オプションが選択されている場合、インポートされているサービスのUDDIレジストリとの同期が自動的に維持されます。自動同期の実行中に発生したエラーは、「自動インポート・ステータス」ページで報告されます。このページでサービスを手動で同期できます。

自動インポートが有効になっている場合、「自動インポート・ステータス」ページを使用して、サービスの同期プロセスを表示して管理できます。サービスをレジストリと同期するかまたはサービスのリンクを解除してこのページでの同期を回避できます。

46.3.2.1 インポートされたサービスの同期

UDDIレジストリからインポートしたサービスがレジストリの変更で変更された場合、Oracle Service Busコンソールの管理機能を使用してコンソールのサービスをレジストリ内のサービスと同期できます。自動インポートが有効になっていて、ビジネス・サービスがレジストリからリンク解除されていない場合、Service Busはレジストリ内のサービスへの変更を自動的にサブスクライブします。「自動インポート・ステータス」ダイアログにこのサービスが表示され、サービスを同期したり、レジストリからリンク解除したりするためのオプションが提供されます。サービスを同期すると、セマンティック検証エラーが発生し、セッションのアクティブ化が妨げられる場合があります。この場合、リンクを解除することをお薦めします。

サービスが同期されている場合、サービスはUDDIから取得されるフィールドでのみ更新されます。サービス定義の他のフィールドでは、最後のインポート以降に変更を行うと値が保持されます。たとえば、ポリシー構成などがあります。

サービスをDomain1からレジストリにパブリッシュするシナリオについて考えてみます。これらのサービスをレジストリからDomain2にインポートします(図46-3参照)。Domain1のサービスを変更し、変更したサービスをレジストリで更新します。自動インポート機能を使用して、変更したサービスをレジストリと同期することで、Domain2のサービスを更新できます。

図46-3 ドメイン間デプロイメントのビジネス・ケース例

46.3.2.2 インポートされたサービスのリンク解除

Oracle Service Busコンソールのサービスをレジストリ内の対応するサービスと同期する必要がない場合もあります。サービスをレジストリからリンク解除すると、同期を回避できます。「インポートされたサービスをUDDIレジストリからリンク解除する方法」を参照してください。

46.4 関連リファレンス

次のドキュメントには、UDDIの詳細が記載されています。

- 技術ノートについては、http://www.oasis-open.org/committees/uddi-spec/doc/tns.htmを参照してください。『Using WSDL in a UDDI Registry』の注記が重要です。

- UDDI製品および開発ツールの情報については、http://uddi.org/solutions.htmlのOASIS UDDIソリューションのページを参照してください。

- UDDI仕様(http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm)
この仕様では、次のことが定義されています。

- アプリケーションがUDDIレジストリに対して情報の照会やパブリッシュを行うために使用するSOAP API

- レジストリ・データ・モデルのXMLスキーマとSOAPメッセージ・フォーマット

- SOAP APIのWSDL定義

- UDDI登録の識別や分類に使用できる様々な識別子とカテゴリ・システムのUDDIレジストリ定義(tModels)

46.5 UDDIレジストリ・リソースの操作

Service BusでUDDIレジストリにアクセスするためには、UDDIレジストリを記述する、UDDIレジストリ・リソースを作成して構成する必要があります。レジストリへサービスをパブリッシュするには、サービス・タイプと、レジストリ内でそのサービスを表すデータ構造の知識が必要です。レジストリ・エントリには、特定のプロパティが関連付けられ、これらのプロパティ・タイプはレジストリの作成時に定義されます。レジストリにサービスをパブリッシュして、他の組織がそのサービスを検出して使用できるようにすることが可能です。Service Busで開発されたプロキシ・サービスは、UDDIレジストリにパブリッシュできます。

46.5.1 Oracle Service BusコンソールでのUDDIレジストリ・リソースの表示方法

UDDIレジストリのフォルダ定義エディタには、現在のセッションで作成したUDDIレジストリ・リソースがすべてリストされます。このページを使用して、定義したUDDIレジストリ・リソースをすばやく検索してアクセスします。

コンソールでUDDIレジストリを表示するには:

1. 「システム」プロジェクトを展開し、「UDDI」を右クリックし、「開く」を選択します。

フォルダ定義エディタが既存のUDDIレジストリ・リソースのリストとともに表示されます。

2. 特定のUDDIレジストリ・リソースを検索するには、次の手順を実行します。

- 照会フィールドがUDDI表の上に表示されていない場合、表のツールバーで「例による問合せ」をクリックします。

- 検出するUDDIレジストリ・リソースの名前を「名前」列の上に入力し、Enterキーを押します。
ワイルドカード文字(単一の文字を表す場合は?、複数の文字を表す場合は*)を入力してさらに一般的な検索を実行できます。

- すべてのUDDIレジストリ・リソースを再表示するには、照会フィールドをクリアしてEnterキーを押します。

3. UDDIレジストリの構成を表示するには、UDDI表のリソース名をクリックします。

4. UDDIレジストリ・リソースを削除するには、表でリソースの名前を選択し、「削除」をクリックします。「UDDIレジストリ・リソースの削除方法」を参照してください。

46.5.2 UDDIレジストリ・リソースの作成方法

UDDIレジストリ・リソースを作成するとき、URL、セキュリティ資格証明、サービスを自動的に同期するかどうかなど、リモート・サーバーの接続情報を指定します。レジストリを作成したら、Service Busプロキシ・サービスのレジストリに対するパブリッシュまたはプロキシ・サービスで使用するビジネス・サービスのレジストリからのインポートを実行できます。

UDDIレジストリ・リソースを作成するには:

1. 次のいずれかを行います:

- JDeveloperを使用している場合、「アプリケーション・リソース」パネルを開き、「Service Busシステム・リソース」を右クリックして、「新規」を指し、「UDDIレジストリ」を選択します。

注意:

プロジェクトに直接UDDIレジストリ・リソースを作成してプロジェクト・レベルのリソースにするには、プロジェクトを右クリックし、「新規」を指し、「UDDIレジストリ」を選択します。

- Oracle Service Busコンソールを使用している場合、「システム」プロジェクトを展開し、「UDDI」を右クリックし、「作成」を指し、「UDDIレジストリの作成」を選択します。

「UDDIレジストリの作成」ダイアログが表示されます。

2. リソースの名前と必要に応じて説明を入力し、「終了」または「作成」をクリックします。
UDDIレジストリ定義エディタが表示され、Oracle Service Busコンソールの「システム」フォルダまたはJDeveloperの「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダに新しいUDDIレジストリ・リソースが表示されます。

3. UDDIレジストリの照会URL、パブリッシュURL、サブスクリプションURLおよびセキュリティURLを入力します。
詳細は、「UDDIレジストリのURL」を参照してください。

4. Service Bus tModelsをレジストリにパブリッシュするには、「T-Modelsをレジストリにロード」を選択します。
このフィールドは、プロキシ・サービスをこのレジストリにパブリッシュする場合のみ必要です。

5. サービスをUDDIレジストリと自動的に同期するには、「自動インポートの有効化」を選択します。
このオプションを選択した状態でサービスをインポートすると、UDDIレジストリとの同期が維持されます。

注意:

自動同期はバックグラウンド・プロセスです。セッションの「取消し」機能を使用して取り消すことはできません。自動同期の変更を元に戻しても、永続的ではありません(次回の同期サイクルでサービスが再同期されるため)。インポートされたサービスがUDDIレジストリと同期されないようにするには、サービスを切り離してレジストリからの更新を避けます。「インポートされたサービスをUDDIレジストリからリンク解除する方法」を参照してください。

6. UDDIレジストリ・コンソールにアクセスするためにユーザー名およびパスワードが必要な場合、「ユーザー名」フィールドにユーザー名を入力して、関連するパスワードを「パスワード」および「新規パスワードの確認」フィールドに入力します。

7. 「保存」をクリックします。

8. 次のいずれかを実行してUDDIのURLをテストします。

a. JDeveloperを使用している場合、「接続のテスト」をクリックします。

b. Oracle Service Busコンソールを使用している場合、「UDDIレジストリをテストおよび検証します」をクリックします。

9. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

46.5.3 JDeveloper UDDI接続からUDDIレジストリ・リソースを作成する方法

JDeveloperでは、既存のUDDIレジストリ接続からUDDIレジストリ・リソースを作成できます。逆に、UDDIレジストリ・リソースからUDDI登録の接続を作成することも可能です。

UDDI接続からUDDIレジストリ・リソースを作成するには:

1. ツールバーで、「ウィンドウ」をクリックし、「リソース」を選択して「リソース」ウィンドウを表示します。

2. 「IDE接続」および「UDDIレジストリ」を展開します。

3. UDDI接続を右クリックし、「Service Bus」を指し、「Service Bus UDDIレジストリ・リソースの作成」を選択します。

「UDDIサービスの作成」ダイアログが表示されます。

4. リソースの名前を入力するかまたはデフォルトをそのまま使用し、「終了」をクリックします。

UDDIレジストリ接続に指定されたURLに基づいて、すでに入力済の照会URLとともにUDDIレジストリ定義エディタが表示されます。

5. 「UDDIレジストリ・リソースの作成方法」の説明に従って、残りのフィールドを入力します。

46.5.4 UDDIレジストリ・リソースの編集方法

UDDIレジストリ・リソースを作成すると、その説明およびUDDIプロパティのほとんどを変更できます。

UDDIレジストリ・リソースを編集するには:

1. 編集するリソースを含むプロジェクトとフォルダを開きます。これは次の場所のいずれかになります。

- JDeveloperの「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダ。

- JDeveloperでは、UDDIレジストリ・リソースがアプリケーション・ナビゲータで配置されているService Busのプロジェクトまたはフォルダ。

- Oracle Service Busコンソールでは、システム・プロジェクトのUDDIフォルダ。

2. UDDIレジストリ名を右クリックし、「開く」を選択します。
UDDIレジストリ定義エディタが表示されます。

3. フィールドの変更については、「UDDIレジストリ・リソースの作成方法」で説明しています。これらのフィールドについては、オンライン・ヘルプでさらに詳細に説明しています。

4. 変更が終了したら、「保存」をクリックします。

5. 次のいずれかを実行してUDDIのURLをテストします。

a. JDeveloperを使用している場合、「接続のテスト」をクリックします。

b. Oracle Service Busコンソールを使用している場合、「UDDIレジストリをテストおよび検証します」をクリックします。

6. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

46.5.5 デフォルトのUDDIレジストリ・リソースを指定する方法

ドメインのデフォルトのレジストリとしてすでに構成されてアクティブ化されているUDDIレジストリのいずれかを指定できます。自動パブリッシュ機能を使用するには、デフォルト・レジストリを設定しておく必要があります。詳細は、「プロキシ・サービスの自動パブリッシュ」を参照してください。

デフォルトのUDDIレジストリ・リソースを指定するには:

1. 編集するリソースを含むプロジェクトとフォルダを開きます。これは次の場所のいずれかになります。

- JDeveloperの「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダ。

- JDeveloperでは、UDDIレジストリ・リソースがアプリケーション・ナビゲータで配置されているService Busのプロジェクトまたはフォルダ。

- Oracle Service Busコンソールでは、システム・プロジェクトのUDDIフォルダ。

2. UDDIレジストリ・リソースを右クリックし、「UDDI設定」を選択します。

「UDDI設定」ダイアログが表示されます。

3. 「デフォルトUDDIレジストリ」リストでデフォルトに設定するレジストリ名を選択します。

注意:

リストには、作成したすべてのUDDIレジストリが表示されますが、すでにアクティブ化されたレジストリのみを選択できます。

4. 「デフォルト・ビジネス・エンティティ」リストでデフォルトに設定するビジネス・エンティティ名を選択します。これはオプションです。

5. 「OK」をクリックします。

6. 変更が終了したら、「保存」をクリックします。

7. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

46.5.6 UDDIレジストリ・リソースの削除方法

UDDIレジストリ・リソースを削除すると、他のService Busリソースからこのリソースへの参照が破損します。リソースを削除する前に、依存関係がないかどうかを確認します。Oracle Service BusコンソールのUDDIレジストリ定義エディタでUDDIレジストリ・リソースを開き、右上の「ツール」アイコンをクリックし、「参照」を選択します。JDeveloperで、UDDIレジストリを右クリックして、「依存性の参照」を選択します。

UDDIレジストリ・リソースを削除するには:

1. 編集するリソースを含むプロジェクトとフォルダを開きます。これは次の場所のいずれかになります。

- JDeveloperの「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダ。

- JDeveloperでは、UDDIレジストリ・リソースがアプリケーション・ナビゲータで配置されているService Busのプロジェクトまたはフォルダ。

- Oracle Service Busコンソールでは、システム・プロジェクトのUDDIフォルダ。

2. UDDIレジストリ・リソースを右クリックし、「削除」を選択します。

3. JDeveloperを使用している場合、確認ダイアログに、リソースの参照の数が表示されます。「使用方法の表示」をクリックして参照に関する情報を表示し、リソースを削除することを確定するため「はい」をクリックします。

4. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。

46.6 JDeveloperでのUDDIレジストリ・サービスの共有

JDeveloperでは、UDDIレジストリにあるサービスからビジネス・サービスを作成できます。単にService Busプロジェクトにサービスをダウンロードすることも可能です。

46.6.1 JDeveloperでのUDDIレジストリ接続の作成方法

JDeveloperでUDDIレジストリを操作する場合、JDeveloper UDDIレジストリ接続およびService Bus UDDIレジストリ・リソースを作成する必要があります。レジストリ接続を使用すると、「リソース」ウィンドウおよび様々なセレクタ・ダイアログでレジストリにアクセスおよび参照でき、そこでプロジェクトのアーティファクトを参照および選択できます。レジストリ・リソースによって、レジストリのAPIエンドポイントURLおよびセキュリティ情報が指定されます。

JDeveloperの「新規ギャラリ」を使用してUDDIレジストリ接続を作成するかまたは「アプリケーション・リソース」パネルで既存のUDDIレジストリ・リソースから接続を作成できます。次の手順では、リソースから接続を作成する方法を説明します。

始める前に:

JDeveloperでレジストリを操作する前に、そのレジストリのアカウントを入手しておく必要があります。Service Busは、バージョン3.0仕様に準拠するUDDIレジストリとの相互運用性をサポートしています。

JDeveloperでUDDI接続を作成するには:

1. UDDIレジストリ・リソースが存在しない場合、「UDDIレジストリ・リソースの作成方法」の説明に従って、これを作成します。

2. 「アプリケーション・リソース」パネルで、「Service Busシステム・リソース」を展開します。

3. 接続を作成するUDDIレジストリ・リソースを右クリックし、「Service Bus」を指し、「UDDI接続の作成」をクリックします。

UDDIレジストリ・リソースの構成に基づいて、新しい接続が作成されます。

4. 「リソース」ウィンドウを表示して接続にアクセスするには、ツールバーの「ウィンドウ」をクリックし、「リソース」を選択します。「IDE接続」および「UDDIレジストリ」を展開します。

5. 接続プロパティを変更し、接続をテストするには、接続を右クリックし、「プロパティ」を選択します。

「UDDIレジストリ接続の編集」ウィザードが表示され、照会エンドポイントURLおよびビューを変更し、接続をテストできます。

46.6.2 UDDIレジストリ・サービスからのビジネス・サービスの作成方法

JDeveloperでは、UDDIレジストリに格納されているサービスからビジネス・サービスを作成できます。JDeveloperからはUDDIレジストリにサービスをパブリッシュできません。次の手順を実行すると、現在のアプリケーションで指定した場所にビジネス・サービスが作成されます。

UDDIレジストリ・サービスからビジネス・サービスを作成するには:

1. 「リソース」ウィンドウを表示できない場合、「ウィンドウ」をクリックし、「リソース」を選択します。

2. 「リソース」パネルで、「IDE接続」および「UDDIレジストリ」を展開します。

3. アクセスするWebサービスを含むUDDIレジストリを検索し、該当のサービスが見つかるまでノードを参照します。

ヒント:

または、使用するサービスの「リソース」ウィンドウで検索を実行できます。

4. サービス名の下で、使用するバインディングが表示されるまで、「バインディング・テンプレート」を展開します。

5. バインディングを右クリックし、「Service Bus」を指し、「ビジネス・サービスの生成」を選択します。

「サービスの消費」ウィザードが表示されます。サービスのWSDLファイルおよびエンドポイントは、選択したサービスに基づいて自動的に構成されます。

6. 「サービス・アーティファクト・フォルダ」フィールドの横で、「参照」をクリックして現在のアプリケーションに移動し、ビジネス・サービスを作成するプロジェクトまたはフォルダを選択します。

詳細はいつでも、F1キーを押すかまたは「ビジネス・サービスの作成」ウィザード内から「ヘルプ」をクリックします。

7. 「次」をクリックします。

8. 「サービスの作成」ページで、「サービス名」フィールドにビジネス・サービスの名前を入力します。

9. 必要に応じて、説明を追加し、ファイル・システムの場所を更新します(この場所はアプリケーション・フォルダ内である必要があります)。WSDL情報は自動的に構成されます。

10. 「次」をクリックします。

11. 「トランスポート」ページで、ビジネス・サービスに使用するトランスポートを指定します。選択できるオプションは、選択したサービスの種類によって異なります。

12. 必要に応じて、エンドポイントURIを更新します。

13. 「終了」をクリックします。

ビジネス・サービスが作成され、ビジネス・サービス定義エディタが表示されて、サービスの構成を終了できます。詳細は、「ビジネス・サービスの作成と構成」を参照してください。

46.6.3 UDDIレジストリからサービスをダウンロードする方法

Service Busプロジェクトの特定のサービスを使用する場合、サービスおよび関連ファイルをプロジェクトにダウンロードできます。

UDDIレジストリからサービスをダウンロードするには:

1. 「リソース」ウィンドウを表示できない場合、「ウィンドウ」をクリックし、「リソース」を選択します。

2. 「リソース」パネルで、「IDE接続」および「UDDIレジストリ」を展開します。

3. アクセスするWebサービスを含むUDDIレジストリを検索し、該当のサービスが見つかるまでノードを参照します。

ヒント:

または、使用するサービスの「リソース」ウィンドウで検索を実行できます。

4. サービス名の下で、使用するバインディングが表示されるまで、「バインディング・テンプレート」を展開します。

5. バインディングを右クリックし、「Service Bus」を指し、「ダウンロード」を選択します。

「Service Busリソースのインポート」ウィザードが表示されます。リソース・タイプおよびソースURLは、選択したサービスに基づいて自動的に構成されます。

6. 「リソース名」フィールドに新しいサービス名を入力するか、既存の名前をそのまま使用します。

詳細はいつでも、F1キーを押すかまたは「Service Busリソースのインポート」ウィザード内から「ヘルプ」をクリックします。

7. 「インポート先」フィールドの横で、「参照」をクリックして現在のアプリケーションに移動し、サービスのダウンロード先のプロジェクトまたはフォルダを選択します。

8. 「次」をクリックします。

9. ダウンロードするリソースを確認し、「終了」をクリックします。

指定したプロジェクトまたはフォルダにサービスが追加され、WSDLエディタが表示されます。

46.7 Oracle Service BusコンソールでのUDDIレジストリ・サービスの共有

Oracle Service Busコンソールには、UDDIレジストリからパブリッシュおよびインポートするためのオプション(手動手順および自動プロセスを含む)がいくつか用意されています。

注意:

レジストリからサービスをアンパブリッシュする必要がある場合、これはUDDIレジストリから行います。

始める前に:

レジストリからのパブリッシュまたはインポートを実行する前に、そのレジストリのアカウントを入手しておく必要があります。Service Busは、バージョン3.0仕様に準拠するUDDIレジストリとの相互運用性をサポートしています。

46.7.1 UDDIレジストリへのプロキシ・サービスのパブリッシュ

UDDIレジストリにService Busプロキシ・サービスをパブリッシュして、他の組織がそのサービスを検出して使用できるようにすることが可能です。サービスをパブリッシュするとき、必要に応じて、サービスがパブリッシュされるビジネス・エンティティを選択できます。また、同時に複数のサービスをパブリッシュできます。Oracle Service Busコンソールからのみパブリッシュできます。JDeveloperからはパブリッシュできません。

注意:

サービスが正常にパブリッシュされていない場合は、再度パブリッシュすることができます。サービスを再度パブリッシュするには、「自動パブリッシュ・ステータス」ページでサービスを選択し、「パブリッシュ」をクリックします。

「レジストリにパブリッシュ」オプションが有効になっている場合、プロキシ・サービスは作成または編集直後にパブリッシュされ、セッションがアクティブ化されます。「レジストリにパブリッシュ」オプションは、ローカル・トランスポートを使用しているサービス以外のすべてのプロキシ・サービスで利用できます。

46.7.1.1 UDDIレジストリにプロキシ・サービスを自動的にパブリッシュする方法

セッションで構成したデフォルトのUDDIレジストリにプロキシ・サービスを自動的にパブリッシュできます。自動パブリッシュを有効にするためには、サービスの自動パブリッシュを有効にし、サービスのパブリッシュ先のUDDIレジストリをService Busが認識できるようにデフォルトのUDDIレジストリを定義する必要があります。

UDDIレジストリにプロキシ・サービスを自動的にパブリッシュするには:

1. プロキシ・サービスのパブリッシュ先のデフォルトのUDDIレジストリを指定します。

手順は、「デフォルトのUDDIレジストリ・リソースを指定する方法」を参照してください。

2. Oracle Service Busコンソールのプロジェクト・ナビゲータで、構成するプロキシ・サービスを含むプロジェクトおよびフォルダを展開します。

3. プロキシ・サービス名を右クリックし、「開く」を選択します。

4. 「全般」ページの「UDDI」で、「レジストリに自動パブリッシュ」を選択します。

注意:

UDDIセクションがない場合、デフォルトのUDDIレジストリは指定されていません。詳細は、「デフォルトのUDDIレジストリ・リソースを指定する方法」を参照してください。

5. 「保存」をクリックします。

プロキシ・サービスの編集の詳細は、「プロキシ・サービスの構成」を参照してください。

6. 「アクティブ化」をクリックしてセッションを終了し、構成をランタイムにデプロイします。

7. プロキシ・サービスがパブリッシュされたことを確認するには、「管理」タブをクリックし、「自動パブリッシュ・ステータス」をクリックします。

該当するプロキシ・サービスがパブリッシュされたサービスのリストに表示されます。

46.7.1.2 UDDIレジストリにプロキシ・サービスを手動でパブリッシュする方法

セッション内で作業していない場合のみUDDIレジストリにサービスをパブリッシュできます。セッションを編集して、UDDIのパブリッシュを有効にし、レジストリ・リストにアクセスします。

UDDIレジストリにプロキシ・サービスを手動でパブリッシュするには:

1. フォルダまたはプロジェクトを右クリックし、「エクスポート」を指し、「UDDIにパブリッシュ」を選択します。

「UDDIにパブリッシュ」ダイアログが表示されます。

2. 「レジストリ名」フィールドで、サービスのパブリッシュ先のUDDIレジストリを選択します。

3. 「ビジネス・エンティティ」フィールドで、サービスが分類されるUDDIレジストリのビジネス・エンティティを選択します。

4. 「プロキシ・サービス」表で、レジストリにエクスポートするプロキシ・サービスを指定します。

デフォルトでは、セッション内のすべてのプロキシ・サービスが選択されます。エクスポートしないサービスのチェック・ボックスをクリアします。

5. 「パブリッシュ」をクリックします。

「パブリッシュのサマリー」ページが表示され、サービスが正常にパブリッシュされたかどうかを示します。パブリッシュ・プロセス中に生成されたメッセージもリストされます。

6. 別のプロキシ・サービスのセットをパブリッシュするには、「別のパブリッシュ」をクリックします。そうしない場合、「閉じる」をクリックします。

46.7.2 UDDIレジストリからリソースをインポートする方法

次のビジネス・サービスの種類をUDDIレジストリからOracle Service Busコンソールにインポートできます。

- HTTPトランスポートを介したWSDLサービス。

- UDDIレジストリにパブリッシュされるService Busプロキシ・サービス。この機能は主に、あるドメインのプロキシ・サービスが別のドメインのプロキシ・サービスを検出してそこにルーティングする必要のあるマルチドメインのService Busデプロイメントで使用されます。

UDDIレジストリから同時に複数のリソースをインポートできます。

始める前に:

UDDIレジストリにアクセスしてそこからリソースをインポートするには、Service BusにUDDIリソースを作成する必要があります。詳細は、「UDDIレジストリ・リソースの作成方法」を参照してください。

コンソールでUDDIレジストリからリソースをインポートするには:

1. 次のいずれかを行います。

- リソースのインポート先のフォルダまたはプロジェクトを右クリックし、「インポート」を指し、「UDDIから」を選択します。

- 「すべてのプロジェクト」を右クリックし、「インポート」を指し、「UDDIから」を選択します。「UDDIからインポート」ダイアログの「宛先」ページで、サービスのインポート先のプロジェクトまたはフォルダを選択し、「次」をクリックします。

「サービス」ページが表示された状態で「UDDIからインポート」ダイアログが表示されます。

2. 「レジストリ名」フィールドで、サービスのインポート元のUDDIレジストリを選択します。

3. 「ビジネス・エンティティ」フィールドで、サービスがあるUDDIレジストリのビジネス・エンティティを選択します。レジストリのすべてのビジネス・エンティティを検索するには、「すべて」を選択します。

4. 「サービス名」フィールドで、インポートするサービスの名前を入力します。

検索では、ワイルドカード文字(複数の文字を表す場合は「*」、1文字を表す場合は「%」)を使用できます。

5. 「検索」をクリックします。

「ビジネス・サービス」表に、一致するビジネス・サービスのリストが表示されます。特定のサービスを検索できない場合は、そのレコードを表示するセキュリティ権限を持っていない可能性があります。

6. 「ビジネス・サービス」表で、該当するビジネス・サービスを選択してレジストリからインポートします。

7. 「次」をクリックします。

8. 選択したビジネス・サービスに複数のバインディング・テンプレートがある場合は、「バインディング・テンプレート」ページが表示されます。リストされたサービスそれぞれに対して、使用する1つのバインディング・テンプレートを選択してビジネス・サービスを作成します。

注意:

選択したサービスに複数のバインディング・テンプレートがある場合は、各バインディング・テンプレートからビジネス・サービスが作成されます。「バインディング・テンプレート」ページでは、インポートするバインディング・テンプレートを絞り込むことができます。

9. 「次」をクリックします。

「確認」ページが表示され、インポートされるリソースのサマリーが表示されます。インポートできないリソースについては、警告メッセージが表示されます。

10. インポートする選択をしたリソースのリストを確認し、「インポート」をクリックします。

選択したリソースがプロジェクト・ナビゲータに表示されます。「UDDIからインポート」ウィザードに、インポートのサマリーおよびインポートされたリソースのエラーが表示されます。

11. 別のビジネス・サービスのセットをインポートするには、「別のインポートを行う」をクリックします。そうしない場合、「閉じる」をクリックします。

インポート・プロセスでは依存性の問題が発生する可能性があります。発生した競合を表示して解決するには、コンソールの下部にある「競合」をクリックします。

46.7.3 インポートしたサービスを自動的に同期する方法

「自動インポート・ステータス」ページでは、サービスに対する変更内容をレジストリの内容と同期できます。自動インポートが有効になっている間にインポートされたサービスのUDDIレジストリとの同期が維持されます。レジストリ内のサービスに変更が加えられると、Service Busにより変更が通知されて「自動インポート・ステータス」ページに同期していないすべてのサービスが表示されます。

UDDIレジストリの自動インポートを有効にするには:

1. Oracle Service Busコンソールのプロジェクト・ナビゲータで、「システム・プロジェクトとUDDI」フォルダ展開します。

2. UDDIレジストリ・リソース名を右クリックし、「開く」を選択します。

3. 「自動インポートの有効化」を選択します。

4. 「保存」をクリックします。

UDDIレジストリからインポートしたサービスは、UDDIレジストリのサービスとの同期が維持されます。「自動インポート・ステータス」ページに同期されたサービスのステータスを表示できます。

46.7.4 インポートしたサービスを手動で同期する方法

自動インポートが有効になっていて、自動同期の実行中にエラーが発生した場合、エラーは「自動インポート・ステータス」ページで報告されます。エラーを修正した後、サービスを手動で同期できます。

サービスをUDDIレジストリと同期するには:

1. Oracle Service Busコンソールで、「管理」タブをクリックし、「自動インポート・ステータス」をクリックします。

「自動インポート・ステータス」ダイアログが表示されます。

2. サービスのリストで、UDDIレジストリに同期するサービスの横のチェック・ボックスを選択します。

3. 表の上の「同期」アイコンをクリックします。

46.7.5 インポートされたサービスをUDDIレジストリからリンク解除する方法

Oracle Service Busコンソール内のサービスをレジストリ内の該当するサービスと同期しない場合は、レジストリからサービスをデタッチすると、サービスは同期されません。

UDDIレジストリからのビジネス・サービスのリンク解除は元に戻せません。サービスを手動で再インポートして、リンクしなおす必要があります。

インポートされたサービスをUDDIレジストリからリンク解除するには:

1. Oracle Service Busコンソールで、「管理」タブをクリックし、「自動インポート・ステータス」をクリックします。

「自動インポート・ステータス」ダイアログが表示されます。レジストリにある元のサービスに変更があった場合にのみ、このページにサービスが表示されます。すべてのサービスがこのページに表示されるわけではありません。

2. サービスのリストで、UDDIレジストリとのリンクが不要になったサービスの横のチェック・ボックスを選択します。

3. 表の上の「リンク解除」アイコンをクリックします。

4. 表示される「警告」ダイアログで、「OK」をクリックしてサービスをリンク解除するか、あるいはサービスのリンク解除を行わない場合には「取消」をクリアします。

5. 「自動インポート・ステータス」ダイアログで、「閉じる」をクリックします。

46.8 Service BusとUDDIのビジネス・シナリオの例

UDDIを使用する利点を明確にする2つのビジネス・シナリオの例を次に示します。

46.8.1 プロキシ・サービスとUDDIレジストリの基本的な通信

このシナリオでは、Service Busを使用してレジストリからサービスをインポートし、Service Busプロキシ・サービスをそのレジストリにパブリッシュする方法を示します。図46-4を参照してください。

図46-4 プロキシ・サービスとUDDIレジストリの通信

Service Busに、UDDIレジストリからビジネス・サービスをインポートします。パイプラインでビジネス・サービスと通信するように、プロキシ・サービスを構成します。プロキシ・サービスを元のレジストリにパブリッシュし、他のドメインで使用できるようにすることが可能です。

46.8.2 Service Busのドメイン間デプロイメント

このシナリオでは、Service Busを使用したドメイン間デプロイメントを示します。このシナリオでは、あるドメインのService Busアプリケーションが実行時に別のドメインのService Busサービスにアクセスする必要があります。図46-5を参照してください。

図46-5 ドメイン間デプロイメントのビジネス・ケース例

2つのドメインに、Service Busのインスタンスがそれぞれデプロイされています。ドメイン(D1)にService Busプロキシ・サービス(P1)が構成されています。ドメイン(D2)のService Busプロキシ・サービス(P2)は、プロキシ・サービス(P1)にアクセスする必要があります。ドメインは直接相互通信することができないため、D2のP2はD1のP1を使用できません。Service Busのインポート/エクスポート機能では、異なるドメインにあるサービスの実行時検出をサポートしていませんが、UDDIレジストリにサービスをパブリッシュすることで、どのドメインのサービスでも検出し使用できるようになります。P1がUDDIレジストリで使用できるようになると、実行時に呼び出したり(たとえば、株価を取得する)、他のService Busプロキシ・サービスでビジネス・サービスとしてインポートしたりできます。

別のドメインからインポートおよびエクスポートする場合は、ネットワーク接続が必要です。プロキシ・サービスが別のドメインのリポジトリにあるスキーマを参照するとします。この場合、URLを使用してインポートするために、そのドメインへのHTTPアクセスが必要となります。接続されていない場合、エラー・メッセージが返されます。

46.9 Service Busプロキシ・サービスからUDDIエンティティへのマッピング

Service Busプロキシ・サービスの属性が、UDDIレジストリでサポートされるデータ・モデルにマップされる必要があります。これによって、プロキシ・サービスをUDDIビジネス・エンティティとしてパブリッシュできます。表46-2に、プロキシ・サービスのUDDIレジストリ・マッピングに関連する、サービス・タイプ、メッセージ・タイプおよびトランスポートを示します。

表46-2 プロキシ・サービスの属性とサービス・タイプ

サービス・タイプ

メッセージ・コンテンツ・タイプ

トランスポート

WSDL

SOAPまたはXML (添付ファイル付き)

HTTP、JMS、ローカル、SB、WS

トランスポート・タイプ

SOAPまたはXML

JEJB

任意のSOAP

型なしのSOAP (添付ファイル付き)

HTTP、JMS、ローカル、SB

任意のXML

型なしのXML (添付ファイル付き)

電子メール、ファイル、FTP、HTTP、JMS、ローカル、MQ、SB、SFTP、Tuxedo

メッセージング

バイナリ、テキスト、MFL、XML (スキーマ)

電子メール、ファイル、FTP、HTTP、JMS、ローカル、MQ、SFTP、Tuxedo

注意:

カッコ内の部分はオプションです。メッセージング・サービスでは、リクエストとレスポンスのコンテンツが異なる場合や、レスポンスがない場合(一方向のメッセージ)があります。電子メール、ファイル、SFTPおよびFTPは一方向であることが必要です。

プロキシ・サービスは共通の属性を持ちます。また、サービスやサービスのタイプで使用される転送プロトコルによって固有に定義される属性もあります。各プロキシ・サービスは、特定のタイプのメッセージを配信できます。

UDDIの主要な関連エンティティは次のとおりです。

- businessService: サービス全体を表し、サービスの一般的な概要情報が含まれます。

- bindingTemplate: サービスにアクセスするための情報が含まれます。

- tModels: サービスを分類および定義するための個々の属性を提供します。

図46-6に、WSDLベースのサービスがUDDIビジネス・エンティティにマップされる仕組みを示します。

図46-6 WSDLサービスからUDDIへのマッピング

WSDLベースのプロキシ・サービスをUDDIレジストリにパブリッシュするためのベースとして、http://www.oasis-open.org/committees/uddi-spec/doc/tns.htmにある技術ノート『Using WSDL in a UDDI registry, version 2.0.2』が使用されています。このドキュメントは、WSDLベース以外のサービスをパブリッシュするための基準としても使用されます。このドキュメントと、ベースとなるUDDI仕様には、UDDIエンティティの記述に使用される標準技術モデル(tModels)についての記載があります。Service Busプロキシ・サービスをUDDIレジストリのエンティティとしてパブリッシュするには、Service Bus固有の構成要素の一部をサポートする標準のtModelを追加する必要があります。サービスの検索時に、プロキシ・サービスのすべての属性(サービス・タイプやトランスポートの詳細など)が役立つわけではありません。これらの属性は、サービスを分類するものではありません。tModelsは、検出されたサービスの構成の詳細です。これらの構成の詳細は、ビジネス・サービスのバインディング・テンプレートのtmodelinstanceDetailsセクションにマップされます。その他の属性は、サービスを個別に識別するものであり、サービスの検索条件として使用できます。これらの属性は、キー付き参照を使用して、バインディング・テンプレートのcategoryBagの値とともにtModelsにマップされます。

Service BusからUDDIへのマッピングの例を図46-7に示します。

図46-7 Service BusからUDDIへのマッピング

46.9.1 Service Busプロキシ・サービスのUDDIマッピングの詳細

Service Busプロキシ・サービスの概要情報は、次のようにビジネス・サービスにマップされます。

- 名前と説明は、businessService要素にマップされます。

- Service Busのプロパティには、特殊なkeyedReferenceGroupがあります。uddi:bea.com:attributes:oracleservicebusはキーの一例です。

- Service Busのタイプ(WSDL、SOAP、XMLおよびこれらの組合せ)とインスタンスは、サービス・カテゴリのkeyedReferencesにマップされます。uddi:bea.com:servicetypeはキーの一例です。

- Service Busインスタンスは、Service Bus keyedReferenceGroup(名前 = "OracleServiceBus"、値 = Service BusインスタンスのURL)内のkeyedReferenceにマップされます。
このインスタンスは、次の2つの目的を果たします。

- このサービスが実際にService Busサーバーによってホストされていることを示します。

- Service BusインスタンスのURLを保持します。

次の例は、上位プロキシ・サービス情報からのビジネス・サービスへのマッピングを示します。

例 - プロキシ・サービスからビジネス・サービスへのマッピング例

<keyedReferenceGroup tModelKey="uddi:bea.com:servicebus:properties">
<keyedReference  tModelKey="uddi:bea.com:servicebus:servicetype"
keyName="Service Type"
keyValue="SOAP"/>
<keyedReference  tModelKey="uddi:bea.com:servicebus:instance"
keyName="Service Bus Instance"
keyValue="http://FOO02.amer.bea.com:7001"/>
</keyedReferenceGroup>

注意:

プロキシ・サービスをパブリッシュするときに作成されるbusinessServiceのキーは、パブリッシュする側が割り当てたキー名です。これは、Service Busのドメイン名、プロキシ・サービスのパスおよびプロキシ・サービス名から生成されます。形式は次のようになります。

uddi:bea.com:servicebus:<domainname>:<path>:<servicename>

たとえば、Service BusドメインであるAnonESBanにProxyというプロジェクトがあるとします。このプロジェクトにAccountingというフォルダがあり、このフォルダにはPayoutProxyというプロキシ・サービスが格納されています。PayoutProxyをUDDIにパブリッシュする場合、businessServiceは次のキーで作成されます。

uddi:bea.com:servicebus:AnonESB:Proxies:Accounting:PayoutProxy

Service Busプロキシ・サービスの詳細情報は、次のようにバインディング・テンプレートにマップされます。

- エンドポイントURIがアクセス・ポイントにマップされます。

- 各トランスポートのマーカーtModelがtModelInstanceDetailsにマップされます。

- HTTP、JMS、ファイル、FTP、電子メールのトランスポートtModel。JMSトランスポートとファイル・トランスポートをサポートするために、新しいtModelsがService Busにパッケージ化されています。

- Service Busの詳細構成情報はinstanceParmsにマップされます。

- 各サービス・タイプのマーカーtModelがtModelInstanceDetailsにマップされます。次のものが必要となります。

- WSDL、任意のSOAP、任意のXML、およびメッセージングのtModelプロトコル。任意のSOAP、任意のXMLおよびメッセージングをサポートする新しいtModelsがService Busにパッケージ化されています。

- WSDLはWSDLからUDDIへのマッピングの技術ノートを使用してマップされます。

- メッセージングに含まれる詳細な構成情報はInstanceParmsにマップされます。

次の例は、バインディング・テンプレートへのマッピングの詳細情報を示します。

例 - 詳細のバインディング・テンプレートへのマッピング例

<bindingTemplate bindingKey="uddi:" serviceKey="uddi:">
<accessPoint useType="endPoint">file:///c:/temp/in3</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:uddi.org:transport:file">
<InstanceDetails>
<InstanceParms><ALSBInstanceParms xmlns="http://www.bea.com/wli/sb/uddi">
<property name="fileMask" value="*.*"/>
<property name="sortByArrival" value="false"/> </ALSBInstanceParms>
</InstanceParms>
</InstanceDetails>
</tModelInstanceInfo>
<tModelInstanceInfo tModelKey="uddi:bea.com:servicebus:protocol:
messagingservice">
<InstanceDetails>
<InstanceParms><ALSBInstanceParms xmlns="http://www.bea.com/wli/sb/uddi">
<property name="requestType" value="XML"/>
<property name="RequestSchema" value="http://domain.com:7001
/sbresource?SCHEMA%2FDJS%2FOAGProcessPO"/>
<property name="RequestSchemaElement"
value="PROCESS_PO"/>
<property name="responseType" value="None"/></ALSBInstanceParms>
</InstanceParms>
</InstanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>

46.9.2 トランスポート属性

uddi:uddi.org:transport: *グループのトランスポートのタイプごとに、異なる詳細メタデータのセットが含まれます。表46-2を参照してください。このメタデータは、プロキシ・サービスのトランスポートの構成の詳細を示します。これは、サービスの特徴を示したりサービスを問い合せたりする場合に役立つものではありません。ただし、検出されたサービスにアクセスするときにこのデータが必要になります。メタデータはXML文字列で表され、tModelInstanceInfoのinstanceParmsフィールドに格納されます。

HTTPトランスポートを使用するプロキシ・サービスをマップし、HTTP構成の一部として、必要なクライアント認証やリクエストとレスポンスの文字エンコーディングなどの構成の詳細を記述する必要があるとします。次の例では、bindingTemplateのtModelInstanceDetailsに必要な内容の一例を示します。

例 - tModelInstanceDetailsの例

<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:uddi.org:transport:http">
<instanceDetails>
<instanceParms>
<ALSBInstanceParms xmlns="http://www.bea.com/wli/sb/uddi">
<property name="client-auth" value="basic"/>
<property name="request-encoding" value="iso-8859-1"/>
<property name="response-encoding" value="utf-8"/>
<property name="Scheme" value="http"/>
</ALSBInstanceParms>
</instanceParms>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>

注意:

各トランスポート方式のサービス・エンドポイントは、常にbindingTemplateのaccessPointフィールドに格納されます。

client-authプロパティは、認証の構成時にHTTPまたはHTTPSトランスポート属性のinstanceParmsにあります。client-authに指定できる値は、basic、client-certおよびcustom-tokenです。値がcustom-tokenの場合は、token-headerとtoken-typeの2つのプロパティが追加されます。

このリリースでは、Service Busビジネス・サービス定義でカスタム・トークン認証がサポートされていないため、サービスのインポート元のUDDIでclient-authの値がcustom-tokenである場合、サービスは認証が構成されていないものとしてインポートされます。

表46-3は、各トランスポートで使用するtModelKeyとinstanceParmsをトランスポート・タイプ別にまとめたものです。

表46-3 トランスポート属性

トランスポート

tModelKey

InstanceParms

電子メール脚注1

uddi:uddi.org:transport:smtp

- 添付ファイルのサポート「ブール値」

- リクエストのエンコーディング

ファイル

uddi:uddi.org:transport:file

- ファイル・マスク

- 到着順にソート「ブール値」

- リクエストのエンコーディング

FTP

uddi:uddi.org:transport:ftp

- ファイル・マスク

- 到着順にソート「ブール値」

- 転送モード「テキスト、バイナリ」

- リクエストのエンコーディング

HTTP

uddi:uddi.org:transport:http

- クライアント認証(なし、基本、クライアント証明書(HTTPのみ)およびカスタム・トークン)。

- リクエストのエンコーディング

- レスポンスのエンコーディング

JEJB

uddi:uddi.org:transport:jejb

- URI

- EJB仕様バージョン

- クライアントJar

- ホーム・インタフェース(EJB 3.0の場合、パブリッシュされません)

- リモート・インタフェース(EJB 3.0の場合のビジネス・インタフェース)

- メソッド名

JMS

uddi:uddi.org:transport:jms

- 宛先のタイプ「キュー、トピック」

- レスポンスが必要、レスポンスURI

- レスポンス・メッセージ・タイプ「バイト、テキスト」

- リクエストのエンコーディング

- レスポンスのエンコーディング

ローカル

uddi:uddi.org:transport:local

なし

MQ

uddi:bea.org:transport:mq

- レスポンスが必要

- レスポンスURI

- レスポンス相関パターン

SB

uddi:bea.org:transport:sb

URIスキームは、use sslがfalseの場合はsb、use sslがtrueの場合はsbs。

なし

SFTP

uddi:bea.org:transport:sftp

- ファイル・マスク

- 到着順にソート「ブール値」

- リクエストのエンコーディング

- 認証モード

Tuxedo

uddi:bea.org:transport:tuxedo

- レスポンスが必要

- アクセス・ポイントID

- バッファ・タイプ

- バッファ・サブタイプ

- クラスJar

- フィールド表クラス

- Viewクラス

WS

uddi:uddi.org:transport:http

WSはHTTP tModelKeyを使用

なし

脚注1

電子メール・トランスポートのバインディング・テンプレートのaccessPointでは、mailto:name@some_server.comという標準のmailto URL形式を使用します。これは、電子メールを読み込むためのURLであり、Service Busでプロキシ・サービスに構成したURLとは異なります。サーバー名が不明の場合、このmailto URLをプロキシ・サービス定義から生成することはできません。たとえば、プロキシ・サービスがPOP3サーバーから読み込むように定義されている場合、mailfrom:pop3.bea.comのようなURLで定義されていることが考えられます。このようなプロキシ・サービスをパブリッシュすると、ダミー・サーバーが追加されます。前述の例では、パブリッシュされるURLは、mailto:some_name@some_server.comの形式になります。

46.9.3 サービス・タイプ属性

表46-4に、各サービス・タイプの概要を示します。

表46-4 サービス・タイプの属性

サービス

説明

WSDL

WSDLベースのプロキシは、『Using WSDL in a UDDI Registry, version 2.0.2』技術ノート(URLはhttp://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.htm)に基づいてUDDIにマップされます。

任意のSOAP

bindingTemplateのtModelInstanceDetailsとcategoryBagに含まれる簡易マーカー・プロトコルtModelにより、任意のSOAPの属性が定義されます。

任意のXML

bindingTemplateのtModelInstanceDetailsとcategoryBagに含まれる簡易マーカー・プロトコルtModelにより、任意のXMLの属性が定義されます。

メッセージング・サービス

bindingTemplateのtModelInstanceDetailsに含まれる簡易マーカー・プロトコルtModelにより、メッセージング・サービスの属性が定義されます。他のサービス・タイプとは異なり、メッセージング・サービスには、リクエスト・メッセージとレスポンス・メッセージの詳細を示す追加の構成情報が関連付けられています。構成詳細は、tModelInstanceInfo内の次のtModel参照のInstanceParmsデータに、XMLデータとして表される。

- 入力メッセージ・フォーマット(XML、テキスト、バイナリ、MFL)

- Service Busの入力メッセージ・スキーマのURL (入力メッセージがXMLの場合は省略可能)

- Service Busの入力メッセージMFLのURL (入力メッセージがMFLの場合)

- 出力メッセージ・フォーマット(なし、XML、テキスト、バイナリ、MFL)

- Service Busの出力メッセージ・スキーマのURL (出力メッセージがXMLの場合は省略可能)

- Service Busの出力メッセージMFLのURL (出力メッセージがMFLの場合)

46.9.4 Service Busサービスをサポートする標準tModel

Service BusとUDDIのマッピングでは、Service Busのメタデータと関係を表すいくつかの標準tModelsが採用されています。このマッピングをサポートするには、これらのtModelsをUDDIレジストリに登録する必要があります。管理者IDを使用して、UDDIレジストリにtModelを作成できます。

表46-5から表46-8にtModelの概要を示します。

表46-5 CategorizationGroup tModelのタイプ

名前

説明

bea-com:servicebus:properties

Service Busサービス固有の属性を記述します。データ・モデルでは、ビジネス・サービスのcategoryBagで使用されます。

表46-6 Categorization tModelのタイプ

名前

値

説明

bea-com:servicebus:serviceType

WSDL、SOAP、XML、メッセージング・サービス

Service Busサービスのサービス・タイプを記述します。

bea-com:servicebus:instance

Service Bus管理コンソールのURL

サービスをUDDIにパブリッシュするService Busのサービス・インスタンスを記述します。

表46-7 Transport tModelのタイプ

名前

説明

uddi-org:jms

サービスが使用するトランスポート方式を記述します。これは、ビジネス・サービスのバインディング・テンプレートのaccessPoint属性で参照されます。

uddi-org:file

サービスの呼出しに使用するトランスポートのタイプを記述します。これは、ビジネス・サービスのバインディング・テンプレートのaccessPoint属性で参照されます。

表46-8 Protocol tModelのタイプ

名前

説明

bea-com:servicebus:anySoap

サービスへのアクセスに使用するプロトコルのタイプを記述します。SOAPメッセージを含み、WSDLファイルまたはスキーマで定義されていないサービスを指定します。メッセージ本文のコンテンツは、アプリケーションによって動的に決まります。

bea-com:servicebus:anyXML

サービスへのアクセスに使用するプロトコルのタイプを記述します。XMLメッセージを含む、WSDLファイルまたはスキーマで定義されていないサービスを指定します。メッセージ本文のコンテンツは、アプリケーションによって動的に決まります。

bea-com:servicebus:messagingService

サービスへのアクセスに使用するプロトコルのタイプを記述します。リクエスト・メッセージが任意のXML(スキーマの有無に関係なく)、テキスト、バイナリ、またはMFLで、レスポンス・メッセージがない、または前述のいずれかであるサービスを指定します。メッセージ本文のコンテンツは、アプリケーションによって動的に決まります。

46.9.5 マッピングの例

次の例は、リクエストがスキーマを使用するXML、レスポンスがテキスト・メッセージであるJMSトランスポートで構成されたメッセージング・サービスのマッピング例です。

例 - メッセージング・サービスのマッピング例

<businessService
serviceKey="uddi:bea.com:servicebus:Domain:Project:JMSMessaging"
businessKey="uddi:9cb77770-57fe-11da-9fac-6cc880409fac"
xmlns="urn:uddi-org:api_v3">
<name>JMSMessagingProxy</name>
<bindingTemplates>
<bindingTemplate
bindingKey="uddi:4c401620-5ac0-11da-9faf-6cc880409fac"
serviceKey="uddi:bea.com:servicebus:
Domain:Project:JMSMessaging">
<accessPoint useType="endPoint">
jms://server.com:7001/weblogic.jms.XAConnectionFactory/
ReqQueue
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:uddi.org:transport:jms">
<instanceDetails>
<instanceParms>
<ALSBInstanceParms
xmlns="http://www.bea.com/wli/sb/uddi">
<property name="is-queue" value="true"/>
<property name="request-encoding"
value="iso-8859-1"/>
<property name="response-encoding"
value="utf-8"/>
<property name="response-required"
value="true"/>
<property name="response-URI"
value="jms://server.com:7001/
.jms.XAConnectionFactory/
RespQueue"/>
<property name="response-message-type"
value="Text"/>
<property name="Scheme" value="jms"/>
</ALSBInstanceParms>
</instanceParms>
</instanceDetails>
</tModelInstanceInfo>
<tModelInstanceInfo
tModelKey="uddi:bea.com:servicebus:
protocol:messagingservice">
<instanceDetails>
<instanceParms>
<ALSBInstanceParms xmlns=
"http://www.bea.com/wli/sb/uddi">
<property name="requestType" value="XML"/>
<property name="RequestSchema"
value="http://server.com:7001/
sbresource?SCHEMA%2FDJS%2FOAGProcessPO"/>
<property name="RequestSchemaElement"
value="PROCESS_PO_007"/>
<property name="responseType" value="Text"/>
</ALSBInstanceParms>
</instanceParms>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReferenceGroup tModelKey="uddi:bea.com:servicebus:properties">
<keyedReference tModelKey="uddi:bea.com:servicebus:servicetype"
keyName="Service Type"
keyValue="Mixed" />
<keyedReference tModelKey="uddi:bea.com:servicebus:instance"
keyName="Service Bus Instance"
keyValue="http://cyberfish.bea.com:7001" />
</keyedReferenceGroup>
</categoryBag>
</businessService>

第VIII部 セキュリティ

この部の各章では、Service BusおよびService Busが処理するメッセージを保護する方法を説明します。

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

- Oracle Service Busセキュリティの理解

- Oracle Service Busセキュリティに関するFAQ

- ビジネス・サービスとプロキシ・サービスの保護

- Webサービスのメッセージ・レベルでのセキュリティの構成

- トランスポート・レベルのセキュリティの構成

- Oracle Web Services Managerを使用したOracle Service Busのセキュリティ

- WS-PolicyによるOracle Service Busプロキシ・サービスおよびビジネス・サービスの保護

- Oracle Service BusでのSAMLの使用

- カスタム認証の構成

- .Net 2.0とメッセージ・レベルのセキュリティの定義方法

関連情報

Service Busでは、より高度なセキュリティ・サービスの基盤として、Oracle WebLogicセキュリティ・フレームワークを使用します。これには、認証、IDアサーション、認可、ロール・マッピング、監査および資格証明マッピングなどが含まれます。Oracle WebLogicセキュリティについては、このドキュメントに加えて次のドキュメントを参照してください。

- Oracle WebLogic Serverのセキュリティの理解

- Webサービスの管理

- Oracle WebLogic Server本番環境の保護

- Oracle WebLogic Serverセキュリティの管理

- Oracle WebLogic Serverロールおよびポリシーによるリソースの保護

47 Oracle Service Busセキュリティの理解

この章では、Service Busのセキュリティ・モデルの概要とその機能(インバウンド・セキュリティおよびアウトバウンド・セキュリティを含む)について説明します。

Service Busでは、通信の整合性とプライバシを保証し、認可されたユーザーのみがService Busドメインのリソースにアクセスできるようにするために、オープンな業界標準をサポートしています。また、セキュリティ・サービスの構成要素として、基になっているWebLogicセキュリティ・フレームワークを使用します。

Service Busでは、Oracle Platform Security Services (OPSS)およびOracle Web Services Manager (OWSM)を使用して、より高度なセキュリティ・サービスを構成します。これには、認証、IDアサーション、認可、ロール・マッピング、監査、資格証明マッピングなどが含まれます。Service Busアクセス・セキュリティを構成するには、最初にOracle WebLogic Serverセキュリティを構成する必要があります。Service BusでOWSMを使用すると、組織全体で一貫性のあるWebサービスの管理と保護のためのポリシー・フレームワークが提供されます。

注意:

Oracle Web Services Manager (OWSM)は、Oracle Service Busで使用されるWebサービス・セキュリティ・メカニズムです。ビジネス・サービスやプロキシ・サービスなどの新規作成されたすべてのリソースでは、セキュリティにOWSMポリシーを使用します。WLS 9ポリシーは非推奨になったため、新しいService Busリソースのセキュリティの構成には使用できません。

ただし、WLS 9ポリシーですでに構成されたリソースをService Busプロジェクトにインポートできます。これらのWLS 9ポリシーの編集または変更はできませんが、OWSMポリシーに置き換えることができます。

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

- インバウンド・セキュリティ

- アウトバウンド・セキュリティ

- IDの伝播のオプション

- 管理セキュリティ

- Oracle WebLogicセキュリティ・フレームワークの構成: 主な手順

- コンテキスト・プロパティがセキュリティ・プロバイダに渡される

- セキュリティ・プロバイダの使用

47.1 インバウンド・セキュリティ

インバウンド・セキュリティによって、Service Busプロキシ・サービスは認可されたクライアントから出されたリクエストのみを処理できます(デフォルトでは、すべての匿名ユーザーまたは認証ユーザーがプロキシ・サービスに接続できます)。また、クライアントからデータが送信されたときに、認可されていないユーザーがそのデータを参照または変更していないことが保証されます。

プロキシ・サービスは、サービス・コンシューマと他のプロキシ・サービスという2つのタイプのクライアントを持つことができます。図47-1に、プロキシ・サービスとそのクライアント間の通信がインバウンド・セキュリティによって保護され、一方プロキシ・サービスとビジネス・サービス間の通信がアウトバウンド・セキュリティによって保護されることを示します。

図47-1 インバウンド・セキュリティとアウトバウンド・セキュリティ

インバウンド・セキュリティはプロキシ・サービスの作成時に設定し、ニーズの変化に応じて変更できます。外向きのプロキシ・サービス(サービス・コンシューマからリクエストを受信します)の場合は、双方向SSL over HTTPSなどの厳密なセキュリティ要件の設定を検討します。

プロキシ・サービスで、デジタル署名、暗号化、またはSSL認証に対して公開鍵インフラストラクチャ(PKI)テクノロジを使用する場合は、証明書とペアの秘密鍵を提供するサービス・キー・プロバイダを作成します。詳細は、「サービス・キー・プロバイダの操作」を参照してください。

各プロキシ・サービスに対し、次のインバウンド・セキュリティ・チェックを構成できます。

- トランスポートレベルのセキュリティは、クライアントとプロキシ・サービス間の接続確立の一部としてセキュリティ・チェックを適用します。トランスポート・レベルのセキュリティによって適用できるセキュリティ要件は、プロキシ・サービスで使用するように構成するプロトコルによって異なります。
たとえば、HTTPプロトコル経由で通信するプロキシ・サービスの場合、Fusion Middleware Controlで作成したユーザーのデータベースに対してすべてのクライアントが認証するように要求できます。次に、認証されたユーザーに対してプロキシ・サービスへのアクセスを認可する条件を指定するためのアクセス制御ポリシーを作成します。

Service Busは、トランスポート・レベルのインバウンド・リクエストでクライアント指定のカスタム認証トークンをサポートします。

サポートされる各プロトコルに対するトランスポート・レベルのセキュリティの構成については、「トランスポート・レベルのセキュリティの構成」.を参照してください。

- メッセージレベルのセキュリティでのカスタム認証。Service Busは、トランスポート・レベルおよびメッセージ・レベルのインバウンド・リクエストでクライアント指定のカスタム認証資格証明をサポートします。カスタム認証資格証明は、カスタム・トークン、またはユーザー名とパスワードの形式になります。
カスタム認証によるトランスポートレベルおよびメッセージレベルのセキュリティの構成は、「カスタム認証の構成」を参照してください。

- メッセージ・レベルのセキュリティ(Webサービスであるプロキシ・サービス用)は、WS-Security仕様の一部です。メッセージ・レベルのセキュリティでは、SOAPメッセージまたはSOAPメッセージの特定の部分を処理する前にセキュリティ・チェックを適用します。
メッセージ・レベルでのセキュリティの構成部分は、Webサービスと関連付けられたWSDLドキュメントおよびWS-Policyドキュメントに埋め込むことができます。これらのドキュメントでは、SOAPメッセージをデジタル署名したり暗号化したりする必要があるかどうか、および認可されたユーザーのみが呼び出すことができるWebサービス操作を指定します。

メッセージを保護するには、メッセージの機密保持の場合はメッセージを暗号化し、メッセージ整合性の場合はメッセージに署名する必要があります。OWSM事前定義済ポリシー、およびいずれかのメッセージ保護アサーション・テンプレートを使用して作成したポリシーにより、メッセージの機密保持またはメッセージ整合性(あるいはその両方)のオプションが提供されます。

プロキシ・サービスまたはビジネス・サービスがWS-Policy文を使用して操作へのアクセスを保護する場合、および(パススルー・サービスとは対照的に)アクティブな仲介としてサービスを構成する場合は、Oracle Service Busコンソールを使用してメッセージ・レベルのアクセス制御ポリシーを作成します。ポリシーでは、保護された操作を呼び出すためにユーザー、グループ、またはセキュリティ・ロールを認可する条件を指定します。

メッセージレベルでのセキュリティの構成の詳細は、「Webサービスのメッセージレベルでのセキュリティの構成」を参照してください。

47.2 アウトバウンド・セキュリティ

アウトバウンド・セキュリティは、プロキシ・サービスとビジネス・サービス間の通信を保護します。アウトバウンド・セキュリティのために行うタスクのほとんどは、ビジネス・サービスで指定されるトランスポート・レベルまたはメッセージ・レベルのセキュリティ要件に準拠するためのプロキシ・サービスの構成のためのものです。

たとえば、ビジネス・サービスでユーザー名とパスワード・トークンが必要な場合は、サービス・アカウントを作成します。このサービス・アカウントは、ユーザー名とパスワードを直接含み、アウトバウンド・リクエストに含まれていたユーザー名とパスワードを渡すか、またはアウトバウンド・リクエストに含まれていたユーザー名に応じてユーザー名とパスワードを提供します。詳細は、「サービス・アカウントの操作」を参照してください。

ビジネス・サービスでデジタル署名またはSSL認証のためにPKIテクノロジを使用する必要がある場合は、証明書とペアの秘密鍵を提供するサービス・キー・プロバイダを作成します。詳細は、「サービス・キー・プロバイダの操作」を参照してください。

47.3 IDの伝播のオプション

Service Busのセキュリティの設計時に決定する必要がある主な項目の1つは、クライアントが提供するIDの処理(伝播)方法です。Service Busの構成によって、次のことを実行できます。

- クライアントが提供する資格証明を認証します。

- 認可チェックを実行します

- クライアント資格証明を変更せずにビジネス・サービスに渡します。

- ビジネス・サービスが認証および認可できる別の資格証明にクライアント資格証明をマップします。

- セキュリティ・テクノロジ間を橋渡しします。

表47-1は、Service BusがクライアントIDをビジネス・サービスに伝播する方法に影響するオプションについての説明です。

表47-1 IDの伝播のオプション

デシジョン

説明

クライアントが提供する必要があるのはどのタイプの資格証明か。

トランスポート・レベルのセキュリティの場合、Service Busは既存のセキュリティ要件に合わせます。Service Busのクライアントは、ユーザー名とパスワード・トークン、SSL証明書または構成したIDアサーション・プロバイダによってサポートされる他のタイプのカスタム認証トークンを提供できます。

メッセージ・レベルのセキュリティの場合、Service Busではユーザー名トークン、X.509トークン、構成した認証プロバイダまたはIDアサーション・プロバイダによってサポートされるその他のカスタム認証トークンおよびSAMLトークン・プロファイルをサポートします(「セキュリティ・プロバイダの使用」を参照)。

Webサービス・セキュリティを使用する新しいビジネス・サービス用のセキュリティ要件を確立する場合は、SAMLトークンを提供するようクライアントに要求することを推奨します。SAMLは、Webサービス内でユーザーIDを伝播するための新しい標準です。「Oracle Service BusでのSAMLの使用」を参照してください。

Service Busでクライアントを認証するように要求するかまたはクライアントが提供する資格証明をそのまま認証のためにビジネス・サービスに渡すか。

Service Busでクライアントに認証を要求するときは、新たなセキュリティのレイヤーを追加します。通常、追加するセキュリティ・レイヤーが多いほど、ドメインの安全性が高くなります。

Service Busでユーザーを認証できるようにするには、Fusion Middleware Controlでユーザー・アカウントを作成する必要があります。ユーザーの集合が非常に大きい場合は、ユーザー・アカウントの大規模なデータベースを保守する価値があるかどうかを検討する必要があります。

X.509トークンまたはSAMLトークンを提供するクライアントをService Busで認証する場合は、どのService Busユーザーがトークンにマップされるか。

Service Busで認証するようにクライアントに要求し、特定の認証されたユーザーのみがプロキシ・サービスにアクセスできる(認可される)ように、デフォルトのアクセス制御ポリシーを変更することをお薦めします。

X.509証明書、SAMLトークンまたはユーザー名とパスワード以外の別のタイプの資格証明を提供するクライアントの認証と認可を行うには、クライアントの資格証明をService BusユーザーにマップするIDアサーション・プロバイダを構成する必要があります。Service Busはこのユーザー名を使用して、クライアントのセキュリティ・コンテキストを確立します。

カスタム認証トークンを提供するクライアントをService Busで認証する場合は、どのService Busユーザーがトークンにマップされるか。

Service Busで認証するようにクライアントに要求し、特定の認証されたユーザーのみがプロキシ・サービスにアクセスできるように、デフォルトのアクセス制御ポリシーを変更することをお薦めします。

ユーザー名とパスワード以外のカスタム認証トークンを提供するクライアントの認証と認可を行うには、クライアントの資格証明をService BusユーザーにマップするIDアサーション・プロバイダを構成する必要があります。Service Busはこのユーザー名を使用して、クライアントのセキュリティ・コンテキストを確立します。

ユーザー名とパスワード・トークンを提供するクライアントをService Busで認証する場合は、次の処理を行うかどうか。

- クライアントのユーザー名とパスワードをビジネス・サービスに渡します。

- クライアントのユーザー名を新しいユーザー名とパスワードにマップし、新しい資格証明をビジネス・サービスに渡します。

「カスタム認証トークンの理解」の説明のように、カスタム・ユーザー名/パスワード・トークンが使用される場合、カスタム・トークンのユーザー名とパスワードをアウトバウンドHTTP基本認証またはアウトバウンドWS-Securityユーザー名トークン認証で使用できます(パススルー・サービス・アカウントが使用される場合)。

クライアントが提供するユーザー名とパスワードをビジネス・サービスに渡す場合、クライアントはビジネス・サービスが要求する資格証明を保守する責任があります。ビジネス・サービスがセキュリティ要件を変更する場合は、対応する変更を行うように各クライアントに通知する必要があります。

ビジネス・サービスが要件を頻繁に変更する可能性がある場合は、クライアントの提供する資格証明からビジネス・サービスの要求する資格証明へのマッピングについて検討します。ビジネス・サービスのクライアントが増えると、この資格証明マッピングを保守するために必要な作業が多くなります。

表47-2は、インバウンドおよびアウトバウンドのトランスポートレベルのセキュリティに対して適用できる要件のすべての組合せについての説明です。

表47-2 トランスポートレベルのセキュリティ要件の組合せ

インバウンド要件

組合せ可能なアウトバウンド要件

構成方法

クライアントがHTTPヘッダー内にユーザー名とパスワードを提供し、Service Busがクライアントを認証します。

クライアントの資格証明をHTTPヘッダーで渡します。

1. インバウンドHTTPセキュリティを構成します。「インバウンドHTTPセキュリティの構成: 主な手順」を参照してください。
クライアントのユーザー名をService Busの「セキュリティ構成」モジュールに必ず追加してください。

2. アウトバウンドHTTPセキュリティを構成します。「アウトバウンドHTTPセキュリティの構成: 主な手順」を参照してください。

必ず パススルー ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付するようにします。

前述の要件と同じです。

クライアントの資格証明を別のService Busユーザーにマップし、新しい資格証明をHTTPヘッダーで渡します。

1. インバウンドHTTPセキュリティを構成します。「インバウンドHTTPセキュリティの構成: 主な手順」を参照してください。
クライアントのユーザー名をService Busの「セキュリティ構成」モジュールに必ず追加してください。

2. アウトバウンドHTTPセキュリティを構成します。「アウトバウンドHTTPセキュリティの構成: 主な手順」を参照してください。

必ず ユーザーマッピング ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付するようにします。

クライアントがHTTPヘッダー内にユーザー名とパスワードを提供し、Service Busはクライアントを認証しません。

クライアントの資格証明をHTTPヘッダーで渡します。

1. インバウンドHTTPセキュリティを構成します。「インバウンドHTTPセキュリティの構成: 主な手順」を参照してください。
HTTP(認証なし)またはHTTPS(一方向SSL、認証なし)でプロキシ・サービスを構成するようにします。

2. アウトバウンドHTTPセキュリティを構成します。「アウトバウンドHTTPセキュリティの構成: 主な手順」を参照してください。

必ず、HTTP基本認証またはHTTPS(一方向SSL、基本認証)でビジネス・サービスを構成します。

また、 パススルー ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付します。

クライアントがHTTPヘッダー内にカスタム認証トークンを提供します。Service Busはクライアントを認証します。

クライアントの資格証明を別のService Busユーザーにマップし、新しい資格証明をHTTPヘッダーで渡します。

1. インバウンドHTTPセキュリティを構成します。「インバウンドHTTPセキュリティの構成: 主な手順」を参照してください。
クライアントのユーザー名をService Busの「セキュリティ構成」モジュールに必ず追加してください。

2. アウトバウンドHTTPセキュリティを構成します。「アウトバウンドHTTPセキュリティの構成: 主な手順」を参照してください。

必ず ユーザーマッピング ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付するようにします。

あらゆる形式のローカル認証(HTTPまたはHTTPSの基本、あるいは資格証明マッピングによるHTTPSクライアント証明書)

クライアントの資格証明をEJB over RMIに渡します。EJBコンテナでユーザーを認証します。

パススルー・サービス・アカウントを作成し、そのアカウントをビジネス・サービスに添付します。「サービス・アカウントの操作」を参照してください。

表47-3は、インバウンドおよびアウトバウンドのメッセージレベルのセキュリティに対して適用できる要件のすべての組合せについての説明です。場合によっては、トランスポートレベルのセキュリティのインバウンド要件が、アウトバウンドのメッセージレベル・セキュリティに適用できる要件に影響します。

表47-3 メッセージレベルのセキュリティ要件の組合せ

インバウンド要件

組合せ可能なアウトバウンド要件

構成方法

クライアントがHTTPヘッダー内にユーザー名とパスワードまたはカスタム認証トークンを提供し、Service Busがクライアントを認証します。

クライアントの資格証明をSOAPヘッダーで渡します。

1. インバウンドHTTPセキュリティを構成します。「インバウンドHTTPセキュリティの構成: 主な手順」を参照してください。
必ずクライアントのユーザー名でユーザー・アカウントを作成してください。

2. パススルー・サービス・アカウントを作成し、そのアカウントをビジネス・サービスに添付します。「サービス・アカウントの操作」を参照してください。

前述の要件と同じです。

クライアントの資格証明を別のService Busユーザーにマップし、新しい資格証明をSOAPヘッダーで渡します。

1. インバウンドHTTPセキュリティを構成します。「インバウンドHTTPセキュリティの構成: 主な手順」を参照してください。
必ずクライアントのユーザー名でユーザー・アカウントを作成してください。

2. ユーザーマッピング・サービス・アカウントを作成し、そのアカウントをビジネス・サービスに添付します。「サービス・アカウントの操作」を参照してください。

前述の要件と同じです。

クライアント資格証明をSAMLトークンにマップします。Service BusがユーザーIDアサーションを行います。

1. インバウンドHTTPセキュリティを構成します。「インバウンドHTTPセキュリティの構成: 主な手順」を参照してください。
必ずクライアントのユーザー名でユーザー・アカウントを作成してください。

2. SAML資格証明マッピング・プロバイダを構成します。「IDのSAMLトークンへのマッピング」を参照してください。

クライアントがメッセージ・ヘッダーまたはメッセージ本体内にユーザー名とパスワードまたはカスタム認証トークンを提供し、Service Busがクライアントを認証します。

クライアントの資格証明をSOAPヘッダーで渡します。

1. カスタム・トークンまたはユーザー名/パスワードを処理するように、認証プロバイダまたはIDアサーション・プロバイダを構成します。
必ずクライアントのユーザー名でユーザー・アカウントを作成してください。

2. パススルー・サービス・アカウントを作成し、そのアカウントをビジネス・サービスに添付します。「サービス・アカウントの操作」を参照してください。

前述の要件と同じです。

クライアントの資格証明を別のService Busユーザーにマップし、新しい資格証明をSOAPヘッダーで渡します。

1. カスタム・トークンまたはユーザー名/パスワードを処理するように、認証プロバイダまたはIDアサーション・プロバイダを構成します。
必ずクライアントのユーザー名でユーザー・アカウントを作成してください。

2. ユーザーマッピング・サービス・アカウントを作成し、そのアカウントをビジネス・サービスに添付します。「サービス・アカウントの操作」を参照してください。

前述の要件と同じです。

クライアント資格証明をSAMLトークンにマップします。Service BusがユーザーIDアサーションを行います。

1. カスタム・トークンまたはユーザー名/パスワードを処理するように、認証プロバイダまたはIDアサーション・プロバイダを構成します。
必ずクライアントのユーザー名でユーザー・アカウントを作成してください。

2. SAML資格証明マッピング・プロバイダを構成します。「IDのSAMLトークンへのマッピング」を参照してください。

クライアントがHTTPヘッダー内にユーザー名とパスワードを提供し、Service Busはクライアントを認証しません。

クライアントの資格証明をSOAPヘッダーで渡します。

1. インバウンドHTTPセキュリティを構成します。「インバウンドHTTPセキュリティの構成: 主な手順」を参照してください。
HTTP(認証なし)またはHTTPS(一方向SSL、認証なし)でプロキシ・サービスを構成するようにします。

2. アウトバウンドHTTPセキュリティを構成します。「アウトバウンドHTTPセキュリティの構成: 主な手順」を参照してください。

必ず、HTTP基本認証またはHTTPS(一方向SSL、基本認証)でビジネス・サービスを構成します。

また、 パススルー ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付します。

クライアントがHTTPSクライアント証明書認証(双方向SSL)の一部として証明書を提供し、Service Busがクライアントを認証します。

クライアント資格証明をSAMLトークンにマップします。Service BusがユーザーIDアサーションを行います。

1. インバウンドHTTPセキュリティを構成します。「インバウンドHTTPセキュリティの構成: 主な手順」を参照してください。

2. SAML資格証明マッピング・プロバイダを構成します。「IDのSAMLトークンへのマッピング」を参照してください。

アクティブな仲介プロキシ・サービスが、ユーザー名トークン・プロファイルによるWebサービス・セキュリティを強制します。

SOAPメッセージのユーザー名とパスワード・トークンとして資格証明をコード化します。

パスワード(パスワード・ダイジェストではない)を要求するWS-Policy文でアクティブな仲介プロキシ・サービスを作成します。「アクティブな仲介プロキシ・サービスの作成: 主な手順」を参照してください。

前述の要件と同じです。

SOAPメッセージのSAMLトークンとして資格証明をコード化します。

1. パスワードを要求するWS-Policy文でアクティブな仲介プロキシ・サービスを作成します。「アクティブな仲介プロキシ・サービスの作成: 主な手順」を参照してください。

2. SAML資格証明マッピング・プロバイダを構成します。「IDのSAMLトークンへのマッピング」を参照してください。

アクティブな仲介プロキシ・サービスが、X.509トークン・プロファイルによるWebサービス・セキュリティを強制します。

SOAPメッセージのSAMLトークンとして資格証明をコード化します。

1. デジタル署名および必要に応じてX.509トークンによる認証を要求するWS-Policy文で、アクティブな仲介プロキシ・サービスを作成します。「アクティブな仲介プロキシ・サービスの作成: 主な手順」を参照してください。

2. SAML資格証明マッピング・プロバイダを構成します。「IDのSAMLトークンへのマッピング」を参照してください。

アクティブな仲介プロキシ・サービスが、SAMLトークン・プロファイルによるWebサービス・セキュリティを強制します。

アウトバウンドSOAPメッセージに新しいSAMLトークンを生成します。

1. SAMLトークンを要求するWS-Policy文でアクティブな仲介プロキシ・サービスを作成します。「プロキシ・サービス・リクエストでのSAMLトークンの認証」を参照してください。

2. SAML資格証明マッピング・プロバイダを構成します。「IDのSAMLトークンへのマッピング」を参照してください。

ユーザー名とパスワード、X.509トークン、またはSAMLトークンを渡すことができるパススルー・プロキシ・サービス。

ユーザー名トークン・プロファイル、X.509トークン・プロファイル、またはSAMLトークン・プロファイルを使用するビジネス・サービス。

1. パススルー・プロキシ・サービスを作成します。「アクティブな仲介プロキシ・サービスの作成: 主な手順」を参照してください。

2. いずれかのトークン・プロファイルを強制するビジネス・サービスを作成します。「ビジネス・サービスのメッセージレベルのセキュリティの構成: 主な手順」または「SAMLパススルーIDの伝播の構成」を参照してください。

インバウンドTuxedoリクエストの場合は、次のセキュリティ要件を構成できます。

- Tuxedoサービスのアウトバウンド呼出しでクライアントの資格証明をコード化します。

- ユーザー名トークンまたはSAMLトークンとしてアウトバウンドSOAPメッセージでクライアントの資格証明をコード化します。

- クライアントの資格証明を別のService Busユーザーにマップし、新しい資格証明をアウトバウンドHTTPヘッダーで渡します。

- クライアントの資格証明を別のService Busユーザーにマップし、新しい資格証明をEJB over RMIに渡します。EJBコンテナでユーザーを認証します。

Service BusでのTuxedoの使用方法の詳細は、「Tuxedoトランスポートの使用」を参照してください。

47.3.1 OWSMポリシーをアタッチする場合のビジネス・サービスでのサービス・アカウントの使用

即時利用可能な次のOWSMポリシーでは、サービス・アカウントの使用がサポートされます。

- oracle/**_username_token_**_client_policy

- oracle/wss11_saml_token_identity_switch_with_message_protection_client_policy

- oracle/**_saml*_**_client_policy (subject.precedenceプロパティはfalseに設定すること)

即時利用可能な次のOWSMポリシー・アサーションでは、サービス・アカウントがサポートされます。

- oracle/**_username_token_**_client_template

- oracle/**_saml*_**_client_template (subject.precedenceプロパティはfalseに設定すること)

47.3.2 例: ユーザー名トークンによる認証

図47-2に、Service Busを次のように構成したときの、Service Bus全体のユーザーIDの流れを示します。

- リクエストでユーザー名とパスワードを提供するようにクライアントに要求する
トランスポート・レベル、メッセージ・レベル、または両方のレベルで資格証明を提供するようにWebサービス・クライアントに要求できます。両方のレベルで資格証明を提供するようにクライアントに要求する場合、Service BusはIDの伝播および資格証明マッピングに対してメッセージ・レベルの資格証明を使用します。

- クライアントを認証する

図47-2 サービス・アカウントの使用方法

この図は、インバウンド・リクエストで開始され、アウトバウンド・リクエストで終了します。

1. あるクライアントがプロキシ・サービスにリクエストを送信します。リクエストには、ユーザー名とパスワード資格証明が含まれます。
クライアントは、認証のためにX.509証明書、カスタム認証トークンなどの他のタイプのトークンを送信することもできます。X.509証明書、SAMLトークンまたはユーザー名とパスワード以外の別のタイプの資格証明を提供するクライアントの認証と認可を行うには、クライアントの資格証明をService BusユーザーにマップするIDアサーション・プロバイダを構成する必要があります。Service Busはこのユーザー名を使用して、クライアントのセキュリティ・コンテキストを確立します。

2. プロキシ・サービスは、ドメインの認証プロバイダ・ストアにそのユーザーが存在するかどうかをドメインの認証プロバイダに問い合せます。
ユーザーが存在する場合、プロキシ・サービス用に構成したアクセス制御ポリシーを評価するように、プロキシ・サービスがドメインの認可プロバイダに依頼します。

3. プロキシ・サービスのアクセス制御ポリシーによってユーザーのアクセスが許可されている場合、プロキシ・サービスはメッセージを処理します。ビジネス・サービスへのアウトバウンド・リクエスト生成の一部として、プロキシ・サービスは、ビジネス・サービスが要求するユーザー名とパスワードを提供するようにビジネス・サービスに依頼します。
ビジネス・サービスは、その資格証明のサービス・アカウントを問い合せます。サービス・アカウントの構成方法に応じて、次のいずれかの処理を行います。

- 特定の(静的な)ユーザー名とパスワードをコード化するようにプロキシ・サービスに要求します。

- クライアントが提供するユーザー名とパスワードを渡すようにプロキシ・サービスに要求します。

- 認証プロバイダから返されたユーザー名を別の(リモート)ユーザー名にマップし、このリモート・ユーザー名をコード化するようにプロキシ・サービスに要求します。

4. プロキシ・サービスは、サービス・アカウントから返されたユーザー名とパスワードと共にアウトバウンド・リクエストを送信します。

47.4 管理セキュリティ

プロキシ・サービスやビジネス・サービスの作成など、管理機能へのアクセスを保護するために、Service Busには、事前定義されたアクセス権限を持つセキュリティ・ロールが用意されています。これらのロールの詳細は、『Oracle Service Busの管理』のOracle Service Busアプリケーション・セキュリティの理解に関する項を参照してください。

セキュリティ・ロールとは、実行時にユーザーやグループに動的に与えることができるIDです。これらの管理セキュリティ・ロールのアクセス権限は変更できませんが、それらのロールのいずれかにユーザーまたはグループを入れるための条件は変更できます。

Service Busのロールには、Service Busのリソースのみを変更する権限があります。WebLogic ServerまたはWebLogic Server上の他のリソースを変更する権限はありません。管理ユーザーをロールに割り当てるときは、最低1人のユーザーをWebLogic Server Adminロールに割り当てます。WebLogic Serverのセキュリティ・ロールについては、『Oracle Service Busの管理』のロールに関する項で説明されています。

47.5 アクセス制御ポリシー

アクセス制御によって、Service Busのリソースにアクセスするユーザーを決定します。アクセス制御ポリシーは、ユーザー、グループ、またはロールがプロキシ・サービスにアクセスできるようにするための条件を指定します。たとえば、あるプロキシ・サービスへのアクセスを、GoldCustomerロールのユーザーには常に許可し、SilverCustomerロールのユーザーには平日の午後12時以降にのみ許可するというポリシーを作成することができます。

アクセス制御ポリシーは、WebLogicリソースと、1つまたは複数のユーザー、グループ、またはセキュリティ・ロールとの間の関連付けです。セキュリティ・ポリシーは、権限のないアクセスからWebLogicリソースを保護します。アクセス制御ポリシーは特定のリソースに割り当てられてたブール式です。リソースへのアクセスが試行されると、式が評価されます。式は、ロール(オペレータ)とアクセス時間(午前8時から午後5時)など、ブール演算子で結合された1つまたは複数の条件で構成されます。アクセス制御ポリシーの詳細は、『Oracle WebLogic Serverセキュリティの理解』のセキュリティの基本に関する項を参照してください。

Service Busは、WebLogic Serverのセキュリティ・レルムを使用してそのリソースを保護します。各セキュリティ・レルムは、構成されたセキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、および(アクセス制御)セキュリティ・ポリシーの集合から成ります。レルムに属するリソースにアクセスするには、『Oracle Service Busの管理』のOracle Service Bus管理セキュリティの構成に関する項に記述されているように、ユーザーにはそのレルムで定義されているセキュリティ・ロールが割り当てられている必要があります。ユーザーがService Busリソースへのアクセスを試みると、WebLogic Serverが関連するセキュリティ・レルムとセキュリティ・ポリシーをチェックして、ユーザーに割り当てられているセキュリティ・ロールを確認し、ユーザーを認証および認可します。

注意:

WebLogic Server管理者のみがFusion Middleware Controlでセキュリティ・ポリシーの定義またはセキュリティ・ロールの編集を実行できます。

すべてのプロキシ・サービスに対して、トランスポート・レベルのポリシーを作成することができます。トランスポート・レベルのポリシーでは、クライアントがプロキシ・サービスとの接続を確立しようとしたときにセキュリティ・チェックが適用されます。トランスポート・レベルのポリシーのリストに入っているユーザーからのリクエストだけが続行を許可されます。

WS-Securityのアクティブな仲介、またはメッセージ・レベルのカスタム認証を実装するプロキシ・サービスの場合は、メッセージ・レベルのポリシーを作成することもできます。このタイプのポリシーでは、保護されているいずれかの操作をクライアントが呼び出そうとしたときにセキュリティ・チェックが適用されます。メッセージ・レベルのポリシーのリストに入っているユーザーだけが、その操作を呼び出せます。

Fusion Middleware Controlでは、ユーザー、グループおよびロールのセキュリティを表示および構成できます。

47.5.1 プロキシ・サービスのアクセス制御の構成

すべてのプロキシ・サービスに対してトランスポート・レベルのアクセス制御を構成できます。また、WS-Securityのアクティブな仲介プロキシ・サービス、またはメッセージ・レベルのカスタム認証を実装するすべてのプロキシ・サービスに対して、メッセージ・レベルでアクセス制御を構成することもできます。アクセス制御を構成するには、トランスポート・レベルまたはメッセージ・レベル(あるいはその両方)でプロキシ・サービスにアクセス制御ポリシーを割り当てる必要があります。

すべてのプロキシ・サービスに対するデフォルトのトランスポート・レベルおよびメッセージ・レベルのアクセス制御ポリシーによって、すべてのリクエストにアクセスを許可します。アクセス制御ポリシーをプロキシ・サービスに割り当てて、それを保護する必要があります。

「Service Busクライアント・アクセス・セキュリティの構成」の説明に従って、トランスポートレベルおよびメッセージレベルのアクセス制御ポリシーを構成します。

47.5.2 アクセス制御ポリシーの管理

アクセス制御ポリシーは認可プロバイダに保持されます。また、Service Busリポジトリにもこれらへの参照があります。

3.0以前のリリースの場合と同様に、アクセス制御ポリシーは、セッション外ではなく、Service Bus設計セッション内で管理されます。変更がセッション内で行われるため、他のリソースと同じように変更をコミットまたは破棄できます。

Oracle Service BusコンソールでACLを管理できますが、Service Busの外でもポリシーを変更できます。ただし、Service Busの外でポリシーを変更するとService Busの参照が期限切れになり、無効になる場合があります。

そのため、一貫した管理には、Service Busセッション外(認可プロバイダMBeansまたはサード・パーティの認可プロバイダ・ツールを使用)でACLを完全に管理するかまたはService Busセッション内でACLを完全に管理します。2つの方法を組み合せると、ポリシー表示の一貫性が失われる場合があります。

Service Busは、プロキシ・サービスのアクセス制御ポリシーのみを管理します。他のサーバー・リソース(JMSキュー、JNDIエントリ、EJB、アプリケーション、WebLogic Serverインスタンス、データ・ソースなど)のアクセス制御ポリシー管理は、Oracle WebLogic Server管理コンソールから管理する必要があります。

注意:

セッションでサービスのクローンを作成すると、ACLのクローンも作成されます。ユーザーがセッションをコミットすると、サービスのACLが認可プロバイダにコミットされます。そのため、サービスのクローンを作成するときは、クローンが元のACLと同じACLを持つようにするかどうかを決定する必要があります。同じACLを持たないようにする場合は、必ずクローンのACLを編集してください。

47.5.2.1 プロキシ・サービスの削除

プロキシ・サービスを削除すると、Service Busが制御するリポジトリ、および適切な認可プロバイダから、プロキシにより参照されるすべてのACLが削除されます。

47.5.2.2 プロキシ・サービスに割り当てられているアクセス制御ポリシーの削除

サービスを削除せずに、サービスに割り当てられているアクセス制御ポリシーを削除することもできます。手順は次のとおりです。

1. セッションを作成します。

2. 「プロキシ・サービスの表示」→「セキュリティ」タブを選択し、「トランスポート・アクセス制御」オプションを編集してポリシーを削除します。

3. セッションをコミットします。

47.5.2.3 プロキシ・サービスの移動または名前の変更

プロキシ・サービスの名前を適切に変更すると、すべてのポリシーが移動されます。サービスの名前の変更または移動は、Service Busセッション内でのみ行う必要があります。

47.5.2.4 プロキシ・サービスの操作の名前の変更

操作の名前を変更すると、既存の操作が透過的に削除され、新しい操作が作成されます。

ただし、WSDLファイルを変更することで操作の名前が変更された場合、Service Busは、古い操作のポリシーを無効と見なし、Service Busリポジトリから参照を削除し、該当する認可プロバイダからポリシーを削除します。

この場合、Service Busは、古い操作が新しい操作に名前が変更されたことを認識せず、新しい操作には新しく追加を行いません。つまり、Service Busは、この新しい操作にはポリシーがないものとみなします。

新しい操作に、適切なポリシーを手動で追加する必要があります。これは、操作の名前の変更が完了した後に、名前変更と同じセッションで行えます。

47.6 Oracle WebLogicセキュリティ・フレームワークの構成: 主な手順

Service Busセキュリティの初期構成タスクの多くでは、WebLogicセキュリティ・フレームワークの構成のためにOracle WebLogic Server管理コンソールで作業する必要があります。これらの初期タスクの後は、ほとんどのセキュリティ・タスクをOracle Service Busコンソールから実行できます。

Service Busに対してWebLogicセキュリティ・フレームワークを構成するには:

1. トランスポート・レベルのセキュリティの一部としてSSLの使用を計画している場合は、次の処理を行います。

a. Oracle WebLogic Server管理コンソールではIDと信頼を構成します。『Oracle WebLogic Serverセキュリティの管理』のIDと信頼の構成に関する項とドメイン間セキュリティ・サポートの重要事項に関する項を参照してください。

b. Oracle WebLogic Server管理コンソールでSSLを構成します。『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項を参照してください。

SSL構成に対して次のことを実行するようお薦めします。

- 双方向SSLを構成する場合は、「クライアント証明書をリクエスト(強制しない)」モードか、「クライアント証明書をリクエスト(強制する)」モードのいずれかを選択する必要があります。可能なかぎり、「クライアント証明書をリクエスト(強制する)」モードを選択することをお薦めします。詳細は、『Oracle WebLogic Serverセキュリティの理解』のSecure Sockets Layer (SSL)に関する項を参照してください。

- 本番環境では、「ホスト名の検証」が有効になっていることを確認します。『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項のホスト名の使用方法を参照してください。

2. Oracle WebLogic Server管理コンソールで、プロキシ・サービスがインバウンド・セキュリティに対して使用する認証プロバイダを構成します。
表47-4は、Service Busで通常構成する認証プロバイダについての説明です。構成できるすべての認証プロバイダの詳細は、『Oracle WebLogic Serverセキュリティの管理』のセキュリティ・プロバイダに関する項を参照してください。

表47-4 認証プロバイダ

クライアントに提供を要求するもの

構成

単純なユーザー名とパスワード

WebLogic認証プロバイダ。Fusion Middleware Controlを使用して、アクセスを許可するクライアントのユーザー名とパスワードを入力します。

注意: 「認証プロバイダの構成」で説明されているように、すべてのWebLogic ServerおよびService Busの管理アカウントにデフォルトのWebLogic認証プロバイダを使用することをお薦めします。

『Oracle Service Busの管理』のOracle Service Busユーザーの作成に関する項を参照してください。

インバウンドHTTPSと双方向SSL認証用のX.509トークン

次のすべてが含まれます。

- WebLogic IDアサーション・プロバイダ。このプロバイダは、X.509トークンを検証できますが、デフォルトでは検証は行われません。このプロバイダがX.509トークンをサポートできるようにします。さらに、このプロバイダがユーザー名マッパーを使用できるようにします。『Oracle WebLogic Serverセキュリティの理解』のIDアサーションとトークンに関する項を参照してください。

- WebLogic証明書パス・プロバイダ。チェックに基づいて信頼された認証局を使用して、証明書チェーンを作成して検証します。

インバウンドHTTPおよびメッセージ・レベル認証用のカスタム認証とユーザー名/パスワード・トークン

トークン・タイプを検証できるIDアサーション・プロバイダ(ユーザー作成またはサードパーティ)。このプロバイダがトークンをサポートすることを確認してください。

インバウンドWebサービス・セキュリティX.509トークン認証用のX.509トークン

プロキシ・サービスまたはビジネス・サービスのいずれかが抽象WS-Policy文を使用するWebサービスである場合は、次も構成する必要があります。

__SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__という名前のWebサービス・セキュリティ構成に、UseX509ForIdentityプロパティを追加してtrueに設定します。Oracle WebLogic Server Administration Consoleオンライン・ヘルプのX.509証明書を使用したIDの証明に関する項を参照してください。

SAMLトークン

次のすべてが含まれます。

- WebLogic SAML IDアサーション・プロバイダV2。このプロバイダは、Security Assertion Markup Language 1.1 (SAML)に基づいてユーザーを認証します。

- WebLogic SAML資格証明マッピング・プロバイダV2。このプロバイダは、Service Busユーザーをリモート・ユーザーにマップします。

3. 必要に応じて、Oracle WebLogic Server管理コンソールで1つ以上のIDアサーション・プロバイダを構成して、サポートする必要があるトークン・タイプ(X.509トークン・タイプやカスタム・トークン・タイプなど)を処理します。構成できるすべてのIDアサーション・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティの管理』のセキュリティ・プロバイダに関する項を参照してください。

4. インバウンド・リクエストでWS-Securityデジタル署名を要求するプロキシ・サービスまたはビジネス・サービスの作成を計画している場合は、証明書レジストリ・プロバイダを有効にします。このプロバイダは、登録した証明書のリストに対してインバウンド証明書を検証する証明書パス・プロバイダです。
Oracle WebLogic Server Administration Consoleオンライン・ヘルプの証明書パス・プロバイダの構成に関する項を参照してください。

5. ユーザー名とパスワード・トークンをリクエストするようにメッセージ・レベルのセキュリティ(インバウンド・リクエストまたはアウトバウンド・リクエスト)を構成する場合、およびメッセージでクリア・テキスト・パスワードではなくパスワード・ダイジェストを提供する場合は、次の操作を行います。

a. Oracle WebLogic Server管理コンソールで、Service Busによって提供される2つのWebサービス・セキュリティ構成を探し、UsePasswordDigestプロパティの値をtrueに設定します。
Service Bus Webサービス・セキュリティ構成の名前は次のとおりです。

__SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__

__SERVICE_BUS_OUTBOUND_WEB_SERVICE_SECURITY_MBEAN__

Webサービス・セキュリティ構成での値の設定の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSOAPメッセージでのパスワード・ダイジェストの使用に関する項を参照してください。

b. 構成した各認証プロバイダに対し、Oracle WebLogic Server管理コンソールでパスワード・ダイジェストの有効化チェック・ボックスを選択します。

c. 構成した各IDアサーション・プロバイダに対し、Oracle WebLogic Server管理コンソールでwsse:PasswordDigestをアクティブ・トークン・タイプの1つとして設定します。

6. サービス・キー・プロバイダ(アウトバウンド・リクエストで鍵と証明書のペアを渡します)の作成を計画している場合は、Oracle WebLogic Server管理コンソールを使用して、PKI資格証明マッピング・プロバイダを構成します。Service Busをホストする任意のWebLogic Serverドメインで、最大1つのPKI資格証明マッピング・プロバイダを構成できます。
PKI資格証明マッピング・プロバイダは、デジタル署名や暗号化(Webサービス・セキュリティ用)およびアウトバウンドSSL認証に使用できる鍵ペアにService Busサービス・キー・プロバイダをマップします。詳細は、『Oracle WebLogic Serverセキュリティの管理』のPKI資格証明マッピング・プロバイダの構成に関する項を参照してください。

PKI資格証明マッピング・プロバイダがキーストアで使用する鍵ペアを格納します。PKI資格証明マッピングは、WebLogic ServerのIDキーストアまたは別のキーストアに格納できます。各WebLogic Serverインスタンスがそれぞれ独自の各キー・ストア・コピーにアクセスするように構成します。PKI資格証明マッパーで参照されるすべてのエントリがすべてのキーストアに存在する必要があります(同じ別名を使用した同じエントリ)。WebLogic Serverでのキーストアの構成の詳細は、『Oracle WebLogic Serverセキュリティの理解』のIDと信頼に関する項を参照してください。

注意:

Service Busドメインを作成すると、デフォルトでドメインにユーザー名/パスワード資格証明マッピング・プロバイダが含まれ、ユーザー名とパスワード用の資格証明マッピングが必要な場合に使用できます。このユーザー名/パスワード資格証明マッピング・プロバイダの他に、1つのPKI資格証明マッピング・プロバイダを追加できます。Service Busドメインは、最大1つのユーザー名/パスワード資格証明マッピング・プロバイダ、1つのPKI資格証明マッピング・プロバイダおよび複数のSAML資格証明マッピング・プロバイダを持つことができます。

7. セキュリティ監査を有効にする場合は、次の操作を行います。

a. Oracle WebLogic Server管理コンソールで監査プロバイダを構成します。Oracle WebLogic Serverセキュリティの管理のWebLogic監査プロバイダの構成に関する項を参照してください。

b. WS-Securityに関連したイベントの監査を有効にするには、各Service Busサーバーの起動時に、サーバーの起動コマンドで次のJavaオプションを指定します。

-Dcom.bea.wli.sb.security.AuditWebServiceSecurityErrors=true

Service Busはセキュリティ・イベントの監査をサポートしますが、構成監査をサポートしません。構成監査では、ユーザーがドメイン内のリソースの構成を変更したり、ドメイン内のリソースに対して管理操作を呼び出したりすると、ログ・メッセージが出されて監査イベントが生成されます。『Oracle WebLogic Serverセキュリティの管理』の構成監査の有効化に関する項を参照してください。

8. まだ実行していない場合は、Oracle WebLogic Server管理コンソールで変更をアクティブ化します。WebLogic Serverの再起動が必要になる変更を行った場合は、Administration Consoleに再起動が必要であることが表示されます。このようなメッセージが表示された場合は、Service BusをホストするすべてのWebLogic Serverインスタンスを再起動して、セキュリティ・プロバイダに対する変更が残りの構成手順に対して有効になるようにします。

47.7 コンテキスト・プロパティがセキュリティ・プロバイダに渡される

コンテキスト・プロパティは、WebLogicセキュリティ・フレームワークに追加情報を提供する手段(ContextHandlerインタフェース)として使用でき、特定のプロバイダ・メソッドに対して引数で渡される以上のコンテキスト依存の情報をセキュリティ・プロバイダが取得できるようになります。ContextHandlerは、コンテキストとコンテナ固有の追加情報を取得する高パフォーマンスのWebLogicクラスです。

Service Busは、ContextHandlerインタフェースを利用して、トランスポート・レベルとメッセージ・レベルの認証、トランスポート・レベルとメッセージ・レベルのアクセス制御および資格証明マッピング用にセキュリティ・フレームワークにいくつかのコンテキスト・プロパティを渡します。

この項では、Service Bus固有のコンテキスト・プロパティが使用される状況について説明します。

47.7.1 HTTPトランスポートレベル認証用のコンテキスト・プロパティ

HTTPプロキシ・サービスで認証が構成されている場合、HTTPトランスポート・プロバイダはWebLogic Server ContextHandlerのService Bus実装を渡します。この機能ではユーザーの構成は必要ありません。

以下の条件で、実行時に表47-5のContextHandlerプロパティが渡されます。

- プロキシでHTTP基本認証が構成されている場合、認証プロバイダに渡されます。

- プロキシでクライアント証明書IDアサーションが構成されている場合、IDアサーション・プロバイダに渡されます。

- プロキシでHTTPカスタム・トークンIDアサーションが構成されている場合、IDアサーション・プロバイダに渡されます。

表47-5 HTTP転送認証用のContextHandlerプロパティ

プロパティ名

タイプ

プロパティ値

com.bea.contextelement.alsb.service-info

com.bea.wli.sb.services.ServiceInfo

プロキシ・サービスに関する情報が含まれるServiceInfoのインスタンス。

com.bea.contextelement.alsb.transport.endpoint

com.bea.wli.sb.transports.TransportEndPoint

HTTPまたはHTTPSエンドポイント。

com.bea.contextelement.alsb.transport.http.http-request

javax.servlet.http.HttpServletRequest

HttpServletRequestオブジェクト。

com.bea.contextelement.alsb.transport.http.http-response

javax.servlet.http.HttpServletResponse

HttpServletResponseオブジェクト。

47.7.2 アクセス制御およびカスタム認証用のContextHandlerプロパティ

アクセス制御およびメッセージ・レベルのカスタム認証用のContextHandlerプロパティは、次の条件で実行時に渡されます。

- メッセージ・レベルのカスタム・ユーザー名/パスワード認証を実行する場合、認証プロバイダに渡されます。

- メッセージ・レベルのカスタム・トークンIDアサーションを実行する場合、IDアサーション・プロバイダに渡されます。

- トランスポート・レベルまたはメッセージ・レベルのアクセス制御を実行する場合、認可プロバイダに渡されます。

表47-6 カスタム認証およびアクセス制御用のContextHandlerプロパティ

プロパティ名

タイプ

プロパティ値

com.bea.contextelement.alsb.router.ProxyService

java.lang.String

サービス名(完全な名前。/myproject/myfolder/svc-aなど)。

com.bea.contextelement.alsb.router.ServiceUri

java.net.URI

メッセージの受信元のベースURI。

com.bea.contextelement.alsb.router.inbound.TransportProvider

java.lang.String

このメッセージを受信したトランスポート・プロバイダのID。

com.bea.contextelement.alsb.router.inbound.request.MessageId

java.lang.String

トランスポート・プロバイダ固有のメッセージIDです。理想としては、Service Busランタイムを通過するその他のメッセージ間でメッセージを一意に識別できる必要があります。ただし、Service Busは、メッセージIDがユニークであることには依存しません。メッセージIDはメッセージ・コンテキストに追加されるため、パイプラインに示されます。

com.bea.contextelement.alsb.router.inbound.request.CharacterEncoding

java.lang.String

メッセージ・ペイロードで使用される文字エンコーディング、またはnull。

com.bea.contextelement.wli.Message

java.io.InputStream

入力ストリームとしてのリクエスト・メッセージ。

47.7.3 トランスポート固有のその他のコンテキスト・プロパティ

表47-7に示されているプロパティに加えて、トランスポート固有のその他のプロパティが存在する場合があります。トランスポート・リクエスト・ヘッダー(トランスポートSDKを参照)ごとに、次の名前を持つプロパティが存在します。

com.bea.contextelement.alsb.router.inbound.request.headers.
<provider-id>.<header-name>

ここで、provider-idはトランスポート・プロバイダのID、header-nameはプロバイダのスキーマ・ファイルで宣言されているリクエスト・ヘッダーの1つです。これらのプロパティの型およびセマンティクスはトランスポート固有です。HTTPプロキシ・サービスの場合、表47-3に示すメッセージ・レベルのセキュリティ・プロパティも使用できます。

表47-7 HTTPプロキシ・サービスのその他のContextHandlerプロパティ

プロパティ名

タイプ

プロパティ値

com.bea.contextelement.alsb.router.inbound.request.metadata.http.relative-URI

java.lang.String

リクエストの相対URI。

com.bea.contextelement.alsb.router.inbound.request.metadata.http.query-string

java.lang.String

リクエストURLでパスの後に含まれる問合せ文字列。

com.bea.contextelement.alsb.router.inbound.request.metadata.http.client-host

java.lang.String

リクエストを送信するクライアントの完全修飾名。

com.bea.contextelement.alsb.router.inbound.request.metadata.http.client-address

java.lang.String

リクエストを送信するクライアントのIP (Internet Protocol)アドレス。

47.7.4 管理者が提供するメッセージレベル認証用のコンテキスト・プロパティ

カスタム・ユーザー名/パスワード認証とカスタム・トークン認証の両方を使用すると、ユーザー(IntegrationAdminロールまたはIntegrationDeployerロールを持つユーザー)は「セキュリティ」タブの「コンテキスト・プロパティ」フィールドで追加のコンテキスト情報をセキュリティ・プロバイダに渡すことができます。

追加のコンテキスト・プロパティを構成するには、「プロパティ名」をリテラル文字列で入力し、「値セレクタ」に有効なXPath式を入力します(XPath式にリテラル文字列を使用することも可能です)。

XPath式は、カスタム・トークンまたはカスタム・ユーザー名/パスワードで使用されているのと同じメッセージ部に対して実行時に評価されます。つまり、「値セレクタ」のXPath式は、SOAPベースのプロキシ・サービスの場合はヘッダーに対して評価され、非SOAPベースのプロキシ・サービスの場合は本体に対して評価されます。

47.7.5 セキュリティ・プロバイダはプロパティ名を認識している必要がある

ContextHandlerは名前と値のリストであるため、セキュリティ・プロバイダが検索対象の名前を認識している必要があります。したがって、トランスポート・レベルおよびメッセージ・レベルのカスタム認証でXPath式が評価されるのは、認証プロバイダまたはIDアサーション・プロバイダがいずれかのプロパティの値を要求する場合のみです。

つまり、構成された認証プロバイダまたはIDアサーション・プロバイダは、ContextHandler.getValue(propertyName)メソッドでリクエストするプロパティ名を明確に知っている必要があります。この要件に対応する唯一の方法は、ユーザーまたはサード・パーティがカスタム認証プロバイダまたはIDアサーション・プロバイダを記述することです。

次の例は、記述するプロバイダからHttpServletRequestプロパティを取得する方法を示しています。

例 - HttpServletRequestプロパティの取得

:
Object requestValue = handler.getValue("com.bea.contextelement.alsb.transport.http.http-request");
if ((requestValue == null) || (!(requestValue instanceof HttpServletRequest)))
return;
HttpServletRequest request = (HttpServletRequest) requestValue;
log.println(" " + HTTP_REQUEST_ELEMENT + " method: " + request.getMethod());
log.println(" " + HTTP_REQUEST_ELEMENT + " URL: " + request.getRequestURL());
log.println(" " + HTTP_REQUEST_ELEMENT + " URI: " + request.getRequestURI());
return;

セキュリティ・プロバイダがユーザー定義プロパティの値を必要としない場合、XPath式は評価されません。

47.7.6 WebLogic Server管理チャネルがサポートされている

このリリースのService Busでは、WebLogic Server管理チャネルを使用できます。

『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・チャネルの理解に関する項で説明されているように、WebLogic Serverネットワーク・チャネルは、WebLogic Serverへのネットワーク接続の属性を定義する構成可能なリソースです。

管理チャネルと呼ばれる特定の種類のネットワーク・チャネルを構成して、WebLogicドメインで管理トラフィックとアプリケーション(ビジネス)トラフィックを分離することができます。管理チャネルは、SSL接続のみを受け入れる、セキュリティで保護されたチャネルです。

Service Busでは、ビジネス・トラフィックは、Service Busのプロキシ・サービスおよびビジネス・サービスで送受信されるすべてのメッセージで構成されています。SSLビジネス・トラフィックは、デフォルトのWebLogic Serverセキュア・ネットワーク・チャネルを使用する必要があります。

管理トラフィックは、Oracle WebLogic Server管理コンソール、Oracle Service Busコンソールとのすべての通信、クラスタ内の内部トラフィックおよび管理スクリプトと管理サーバーまたは管理対象サーバーとの間のトラフィックで構成されています。

ドメインで管理チャネルが有効になっている場合、そのドメイン内のすべての管理トラフィックがそのチャネルを通過します。それ以外の場合、管理トラフィックは、デフォルトのWebLogic Serverセキュア・ネットワーク・チャネルも使用します。

「管理チャネルの使用:主な手順」では、管理チャネルの使用について説明します。

47.7.6.1 管理チャネルの使用: 主な手順

管理チャネルを使用するには、次の手順を実行します。

1. ドメインのOracle Service Busコンソールに対するブラウザの接続を切断します。

WebLogic Serverで管理チャネルをアクティブ化するとすぐに、ドメインのOracle Service Busコンソールは現在のURLでアクセスできなくなります。ヘルプ・システムも使用できなくなります。

2. Oracle WebLogic Server管理コンソールでドメイン全体の管理ポートを有効にする(これにより、管理チャネルが構成される)か、管理チャネルを明示的に作成します。これら両方の操作は、『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・リソースの構成に関する項を参照してください。

ドメイン全体の管理ポートのコントロールは、「ドメイン」「構成」の「全般」ページにあります。デフォルトの管理ポートは9002です。

必ず、変更をアクティブ化してください。

3. ドメインのOracle Service Busコンソールの新しいURLへのブラウザ接続を開きます。

ドメイン全体の管理ポートを有効にして、デフォルトのポート番号を受け入れた場合、URLはhttps://hostname:9002/servicebusです。

4. 古いURLを参照する起動スクリプトを修正します。Windowsグラフィカル・インタフェースを使用してドメインのOracle Service Busコンソールを起動する場合は、新しいURLを反映するようにショートカットのプロパティを修正してください。

47.8 セキュリティ・プロバイダの使用

ここでは、Service Busでのセキュリティ・プロバイダの使用方法について説明します。

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

- 認証プロバイダの構成

- カスタム認可プロバイダによるService Busリソースの保護

- セキュリティ・プロバイダ・ポリシー使用時のエラーについて

47.8.1 認証プロバイダの構成

提供されるWebLogic Server認証プロバイダを調べて、ニーズに合うものがないか確認してください。WebLogic Serverには、次のようなさまざまな認証プロバイダが含まれます。

- WebLogic認証プロバイダは、WebLogic Serverの埋め込まれたLDAPサーバーにあるユーザーとグループ情報にアクセスする。これは即時利用可能なデフォルトの認証プロバイダです。このプロバイダは、非常に多くのユーザーでの使用には最適化されていません。

- LDAP認証プロバイダでは、外部のLDAPストアにアクセスします。LDAP認証プロバイダを使用すると、任意のLDAPサーバーにアクセスできます。WebLogic Serverには、Open LDAP、Oracle Directory Server Enterprise Edition、Microsoft Active DirectoryおよびNovell NDS LDAPサーバー用のLDAP認証プロバイダがすでに構成されています。

- RDBMS認証プロバイダでは、外部リレーショナル・データベースにアクセスします。WebLogic Serverには、SQL認証プロバイダ、読取り専用SQL認証プロバイダ、カスタムRDBMS認証プロバイダという3種類のRDBMS認証プロバイダが用意されています。

- SAML認証プロバイダ - Security Assertion Markup Language 1.1 (SAML)アサーションに基づいてユーザーを認証します。

これらの認証プロバイダのパフォーマンスを向上させる方法は、『Oracle WebLogic Serverセキュリティの管理』のWebLogicおよびLDAP認証プロバイダのパフォーマンスの向上に関する項を参照してください。

Oracle WebLogic Serverセキュリティの管理のデフォルト・セキュリティ構成をカスタマイズする理由に関する項で説明されているように、WebLogic Serverの組込みのLDAPサーバー以外のデータベースにアクセスする認証プロバイダを使用することもできます。たとえば、大多数のユーザー・アカウントに別の認証プロバイダを使用し、Service BusおよびWebLogic Serverの管理ユーザー・アカウントにはデフォルトの認証プロバイダ(組込みのLDAP)を引続き使用できます。

すべてのWebLogic ServerおよびService Busの管理ユーザー・アカウントにWebLogic認証プロバイダを使用することで、ネットワークまたはデータベースに問題が発生した場合に、信頼性の高いアクセスが提供されます。そのため、すべてのWebLogic ServerおよびService Busの管理ユーザー・アカウントにデフォルトのWebLogic認証プロバイダを使用することをお薦めします。

組込みの認証プロバイダのいずれかがニーズに合う場合は、その認証プロバイダをOracle WebLogic Server管理コンソールで構成する手順を『Oracle WebLogic Serverセキュリティの管理』の認証プロバイダの構成に関する項で参照してください。

WebLogic Serverに組み込まれている認証プロバイダがニーズに合わない場合は、まずユーザー自身(またはサード・パーティ)がカスタム認証プロバイダを作成し、次の手順に従い、Oracle WebLogic Server管理コンソールを使用してそのプロバイダをセキュリティ・レルムに追加する必要があります。

注意:

ここでは、必要なタスクの概要についてのみ説明します。実際にタスクを実行するにはWebLogic Serverドキュメントを調べる必要があります。

セキュリティ・レルムにプロバイダを追加するには:

1. 適切なSSPIを使用してランタイム・クラスを作成します(『Oracle WebLogic Serverセキュリティ・プロバイダの開発』)。

2. WebLogic MBeanMakerを使用してMBeanタイプを生成します

3. 管理コンソールを使用してカスタム認証プロバイダを構成します

47.8.2 カスタム認可プロバイダによるService Busリソースの保護

カスタム認可プロバイダでService Busリソースを使用できますが、これらのプロバイダがService Busリソースのタイプや形式を認識する必要があります。

Service Busには、認可プロバイダが検出して処理できる必要があるリソース・オブジェクトが3つあります。

- ALSBProxyServiceResourceオブジェクト

- ProjectResourceV2オブジェクト

- ConsoleResourceオブジェクト

これらのリソース・オブジェクトについては、この後の項で説明します。

47.8.2.1 WebLogic認証プロバイダの使用方法について

この項では、WebLogic Server認証プロバイダSSPIについて簡単に説明します。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の認可プロバイダに関する項を参照してください。

リソースを保護するには、Oracle Service Busコンソール、サードパーティ・ツールまたはスクリプトを使用して、アクセス制御ポリシーをリソースにバインドします。WebLogic Server SSPI (Security Service Provider Interface)では、リソースSPIを実装するためにService Busなどのコンテナが必要です。これらの実装は具象リソースを表します。

認可プロバイダ・データベースには、リソースからポリシーへのマップがあります。リソースへのアクセスが試みられると、コンテナは実行時SSPIを呼び出してアクセス制御の判断を行います。コンテナは、アクセスされるリソースを示すリソース・インスタンスを渡します。

認可プロバイダにはgetAccessDecision()という1つのメソッドがあります。getAccessDecision()メソッドは、AccessDecision SSPIの実装を取得します。AccessDecision SSPIそのものにはisAccessAllowed()という1つのメソッドがあります。isAccessAllowedには5つのパラメータがあり、その1つはリクエストされるアクセスに対するResourceオブジェクトです。

isAccessAllowedは、指定のリソースへのアクセスがリクエスト側に許可されるかどうか判断します。これを実行するには、認可プロバイダが評価のために正しいアクセス制御ポリシーを見つける必要があります。プロバイダは、渡されたリソースにバインドされたポリシーをまず検索する必要があります。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のセキュリティ・プロバイダのランタイム・クラスでのWebLogicリソースのルックアップに関する項で説明されるように、検索では検索のキーとしてgetId()メソッドまたはtoString()メソッドを使用できます。ポリシーが見つからない場合、認可プロバイダは親リソースを取得し、再検索する必要があります。このプロセスは、ポリシーが見つかるか、親がnullになるまで繰り返されます。この場合、ポリシーは見つかりません。ポリシーが見つからない場合、isAccessAllowedはfalseを返す必要があります。

このアルゴリズムによって、指定のプロジェクトまたはフォルダ内のすべてのプロキシ・サービス、プロジェクト内のすべてのリソースまたはService Busドメイン内のすべてのService Busプロキシ・サービスを保護する、大まかなポリシーを作成できます。より具体的で詳細なポリシーは、大まかなポリシーより優先されます。

注意:

Oracle Service Busコンソール・ユーザー・インタフェースには、フォルダ、プロジェクトまたはドメイン・レベルでプロキシ・サービスを保護するページは用意されていません。

47.8.2.2 ALSBProxyServiceResourceオブジェクト

ALSBProxyServiceResourceオブジェクトは、Service Busプロキシ・サービスへのトランスポート・レベルとメッセージ・レベルのアクセス制御で使用します。ALSBProxyServiceResourceリソースは、weblogic.security.spi.Resourceを実装しているweblogic.security.service.ResourceBaseを拡張します。

ALSBProxyServiceResourceは、weblogic.security.spi.Resourceに記述されるように、次のメソッドを実装しています。

getType() - タイプを返します。ここでは、タイプは<alsb-proxy-service>です。

getKeys() - 最大4つのキーと値のプロパティであるpath、proxy、actionおよびoperationを返します。プロパティは次のように定義されます。

- pathはプロキシ・サービスの完全名。たとえば、path=project/folder1/folder2です。

- proxyはプロキシ・サービスの名前。たとえば、proxy=myProxyです。

- actionは、invokeまたはwss-invokeという2つの値のいずれかです。たとえば、action=invokeです。
action属性は、トランスポートレベルとメッセージレベルのアクセス制御を区別するために使用されます。invokeは、トランスポートレベルのアクセス制御で使用されます。wss-invokeはメッセージレベルのアクセス制御(つまり、カスタムのメッセージレベル認証を含む、WS-Securityのアクティブな仲介またはプロキシに対するアクセス制御)で使用されます。operation属性は、actionがwss-invokeの場合のみ使用できます。

- operationは呼び出す操作の名前で、actionがwss-invokeの場合のみ使用されます。たとえば、operation=processPOです。operation属性は、actionがwss-invokeの場合のみ有効です。
ALSBProxyServiceResourceには1から4個のキーがあります。次の表は、プロキシ・サービスを保護する様々な組合せについての説明です。最も具体的なポリシーが優先されます。

リソースに含まれるキー

リソースにバインドされたポリシーの保護対象

path

ポリシーは指定のパスにあるすべてのプロキシ・サービスを保護します

pathおよびproxy

ポリシーは指定のプロキシ・サービスへのすべてのアクセスを保護します(トランスポート・レベルおよびメッセージ・レベル)

path、proxy、およびaction

action="invoke"の場合

ポリシーは指定のプロキシのトランスポート・レベルのポリシー

action="wss-invoke"の場合

ポリシーは指定のプロキシのメッセージ・レベルのポリシー(すべての操作)

path、proxy、action="wss-invoke"、およびoperation

ポリシーは指定のプロキシと操作に対するメッセージ・レベルのポリシー

getPath() - プロキシ・サービスへのパス(プロジェクトとフォルダ)を取得します。これは、Service Busの構成フレームワーク内でプロキシ・サービスが存在するパスです。

getProxyServiceName() - プロキシ・サービス名を取得します。たとえば、proxy=myProxyです。

getAction() - invokeまたはwss-invokeという2つの値のどちらかを取得します。たとえば、action=invokeです。

getOperation() - 呼び出す操作の名前を取得します。actionがwss-invokeの場合のみ使用します。たとえば、operation=processPOです。

makeParent() - 現在のALSBProxyServiceResourceリソースの親を表す新しいALSBProxyServiceResourceオブジェクトを作成します。makeParent()はプロキシ・サービスのパスを使用して親を作成します。

47.8.2.2.1 ALSBProxyServiceResourceの例

次の例は、ALSBProxyServiceResourceオブジェクトの様々な使用方法です。

- プロキシproject/folder/myProxyでのトランスポート・レベルのアクセス制御に対するALSBProxyServiceResourceの使用

type=<alsb-proxy-service>, path=project/folder, proxy=myProxy, action=invoke

- プロキシproject/folder/myProxyでの操作processPOのメッセージレベルのアクセス制御に対するALSBProxyServiceResourceの使用

type=<alsb-proxy-service>, path=project/folder, proxy=myProxy, action=wss-invoke, operation=processPO

- ALSBProxyServiceResourceに対する様々な詳細度の親子階層の使用

type=<alsb-proxy-service>, path=myProject/f1/f2, proxy=myProxy, action=wss-invoke, operation=foo
type=<alsb-proxy-service>, path=myProject/f1/f2, proxy=myProxy, action=wss-invoke
type=<alsb-proxy-service>, path=myProject/f1/f2, proxy=myProxy
type=<alsb-proxy-service>, path=myProject/f1/f2
type=<alsb-proxy-service>, path=myProject/f1
type=<alsb-proxy-service>, path=myProject
type=<alsb-project>, project-name=myProject
type=<alsb-proxy-service>

47.8.2.3 ProjectResourceV2オブジェクト

ProjectResourceV2は、指定のプロジェクトに含まれるすべてのALSBProxyServiceResourceオブジェクトのルート・リソースです。ProjectResourceV2はResourceBaseを拡張します。

ProjectResourceV2に対するアクセス制御ポリシーの設定によって、指定のプロジェクトでさらに具体的なポリシーを持たないすべてのプロキシ・サービスに対して、大まかなアクセス制御ポリシーが提供されます。

ProjectResourceV2には次のメソッドがあります。

getType() - タイプを返します。ここでは、タイプは"<alsb-project>"です。

getKeys() - キーを返します。ここで、キーは"project-name"です。

getName() - ProjectResourceV2オブジェクトの名前を取得します。

makeParent() - ProjectResourceV2オブジェクトには、親はありません。したがって、このメソッドは、ProjectResourceV2オブジェクトの作成に使用されたオブジェクト名を返すか、またはProjectResourceV2が存在しない場合はnullを返します。

47.8.2.4 ConsoleResourceオブジェクト

com.bea.wli.security.resource.ConsoleResourceオブジェクトは、Oracle Service Busコンソールへのアクセス制御で使用します。ただし、ConsoleResourceオブジェクト用のアクセス制御ポリシーを、カスタム認証プロバイダを使用して設定しないことをお薦めします。これは、これらのポリシーが今後のService Busリリースで変更される可能性があるためです。

代わりに、カスタム認証プロバイダを使用する必要がある場合でも、WebLogic Server XACML認証プロバイダの使用を継続して、ConsoleResourceオブジェクト用のポリシーを管理することをお勧めします。このように2つの認可プロバイダを使用する場合は、裁決プロバイダも構成する必要があります。

47.8.3 セキュリティ・プロバイダ・ポリシー使用時のエラーについて

WebLogic Serverでプラグイン・セキュリティ・プロバイダを使用して、Service Busで使用するためのポリシーを格納する場合、Service Busでは必要なポリシーを利用できるかどうかを判断できないことを伝えるエラーが生じる場合があります。

このようなエラー・メッセージが表示されても、ポリシーが存在しないことや、セキュリティ・プロバイダの接続上または構成上の問題が発生したことを意味するとはかぎりません。Service Busでは、WebLogic Server SSPIを使用して、セキュリティ・プロバイダが実装できるポリシーを読み取ります。ただし、SSPIの読取り機能はオプションです。セキュリティ・プロバイダでこのSSPIを実装せずに読取りアクセスを許可しないことも可能です。このような場合、Service Busでは、必要なポリシーがセキュリティ・プロバイダに実際に存在していても、必要なポリシーがセキュリティ・プロバイダに含まれているかどうかを確実に判断できません。

このような警告が本当の問題を示しているかどうかを判断するには、Oracle Service Busコンソールでリソースの作成または変更を試みます。また、アクセス制御ポリシーでプロキシ・サービスを保護し、テストします。プロキシ・サービスに対するアクセス制御ポリシーの構成の詳細は、「Service Busクライアント・アクセス・セキュリティの構成」を参照してください。セキュリティ・プロバイダを使用しながら、リソースの作成または操作、およびセキュアなプロキシ・サービスのテストに成功した場合、そのセキュリティ・プロバイダは正しく構成されており、エラー・メッセージは無視しても問題ありません。

48 Oracle Service Busのセキュリティに関するFAQ

この章では、Service Busセキュリティに関してよく聞かれる質問に対する回答を提供します。

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

- Service BusとWebLogic Serverのセキュリティにはどのような関係がありますか。

- トランスポート・レベルのセキュリティとは何ですか。

- Webサービス・セキュリティとは何ですか。

- Webサービス・ポリシーとは何ですか。

- Webサービス・ポリシーのアサーションとは何ですか。

- アクセス制御ポリシーとWebサービス・ポリシーは同じものですか。

- Webサービス・セキュリティのパススルーとは何ですか。

- Webサービス・セキュリティのアクティブな仲介とは何ですか。

- アウトバウンドWebサービス・セキュリティとは何ですか。

- SAMLとは何ですか。

- 証明書検索および検証フレームワークとは何ですか。

- Service Busでは、プロキシ・サービスでのIDの伝播はサポートされますか。

- SAMLアサーションのサブジェクトIDの形式はカスタマイズ可能ですか。

- シングル・サインオンはService Busでサポートされますか。

- セキュリティ・エラーはモニターされますか。

- MBeanのセキュリティを構成できますか。

48.1 Service BusとWebLogic Serverのセキュリティにはどのような関係がありますか。

Service BusではWebLogicセキュリティ・フレームワークを利用しています。このフレームワークの詳細は、『Oracle WebLogic Serverセキュリティの理解』の「WebLogicセキュリティ・サービスのアーキテクチャ」にあるWebLogicセキュリティ・フレームワークに関する項を参照してください。Service Busでセキュリティを構成する前に、「Oracle WebLogicセキュリティ・フレームワークの構成: 主な手順」の説明に従って、WebLogic Serverセキュリティ・レルムやその他のサーバーの構成(SSLなど)をWebLogic Serverで行う必要があります。

48.2 トランスポート・レベルのセキュリティとは何ですか。

トランスポート・レベルのセキュリティは、メッセージのトランスポートに使用する接続を保護する転送プロトコルを指します。トランスポート・レベルのセキュリティの例として、HTTPS (HTTP over SSL)があります。SSLのセキュリティはポイント・ツー・ポイントですが、メッセージの経路に仲介者がいるとメッセージが保護されません。詳細は、「トランスポート・レベルのセキュリティの構成」を参照してください。

48.3 Webサービス・セキュリティとは何ですか。

Webサービス・セキュリティ(WS-Security)はOASIS標準の1つです。SOAPメッセージにメッセージ・レベルのセキュリティを組み込むための相互運用可能なメカニズムを定義しています。WS-Securityは、メッセージの整合性と機密性をサポートします。また、SOAPエンベロープにセキュリティ・トークンを含める拡張モデルや、SOAPエンベロープ内からセキュリティ・トークンを参照するモデルも定義しています。WS-Securityトークン・プロファイルは、コアのWS-Security仕様内での特定のトークン・タイプの使用方法を指定します。メッセージの整合性はXMLデジタル署名を使用することで確保され、メッセージの機密性はXML暗号化を使用することで確保されます。WS-Securityでは、SOAPメッセージのどの部分をデジタル署名または暗号化するかを指定できます。Service Busは、HTTP (HTTPSを含む)およびJMSによってWS-Securityをサポートします。

注意:

Oracle Web Services Manager (OWSM)は、Oracle Service Busで使用されるWebサービス・セキュリティ・メカニズムです。ビジネス・サービスやプロキシ・サービスなどの新規作成されたすべてのリソースでは、セキュリティにOWSMポリシーを使用します。WLS 9ポリシーは非推奨になったため、新しいService Busリソースのセキュリティの構成には使用できません。

ただし、WLS 9ポリシーですでに構成されたリソースをService Busプロジェクトにインポートできます。これらのWLS 9ポリシーの編集または変更はできませんが、OWSMポリシーに置き換えることができます。

48.4 Webサービス・ポリシーとは何ですか。

Webサービス・ポリシー・フレームワーク(WS-Policy)は、Webサービスのポリシーを記述して通信するための汎用モデルとその構文を提供します。WS-Policyは、様々なサービスの要件、プリファレンスおよび機能を記述するために他のWebサービス仕様で使用および拡張できる一連の基本構成要素を定義しています。WLS9 Webサービスのポリシーの詳細は、「Webサービス・セキュリティとは何ですか。」の「注意」を参照してください。詳細は、「WS-PolicyによるOracle Service Busプロキシ・サービスとビジネス・サービスの保護」を参照してください。

48.5 Webサービス・ポリシーのアサーションとは何ですか。

Web Services Policy Assertions Language (WS-PolicyAssertions)は、セキュリティ・ポリシー内で指定できる一連の共通メッセージ・ポリシー・アサーションを指定しています。この仕様は、WS-Policyで使用する一般的なメッセージング関連のアサーションを定義しています。個別の仕様で、セキュリティ・アサーションと信頼性の高いメッセージング・アサーションについて、ドメイン固有のアサーションの構文とセマンティクスを記述します。WLS9 Webサービスのポリシーの詳細は、「Webサービス・セキュリティとは何ですか。」の「注意」を参照してください。

48.6 アクセス制御ポリシーとWebサービス・ポリシーは同じものですか。

いいえ。アクセス制御ポリシーは、特定のリソース(プロキシ・サービス、Webアプリケーション、EJBなど)へのアクセスのリクエストの承認および拒否を決定するために評価されるブール式です。通常、アクセス制御ポリシーはリクエスト側のロールに基づいています。WS-Policyは、サービス定義(WSDL)を補完する、Webサービスについてのメタデータです。WS-Policyは、「すべてのリクエストはクライアントのデジタル署名が必要である」などの、すべてのサービス・クライアントが満たすべき要件を表すために使用できます。

48.7 Webサービス・セキュリティのパススルーとは何ですか。

WS-Securityパススルーのシナリオで、クライアントは、WS-Securityをリクエスト・メッセージやレスポンス・メッセージに適用します。プロキシ・サービスは、セキュリティ・ヘッダーを処理しません。そのかわりに、セキュアなリクエスト・メッセージをそのままビジネス・サービスに渡します。Service Busは、メッセージにWS-Securityを適用しませんが、ヘッダーの値に基づいてメッセージをルーティングできます。ビジネス・サービスは、メッセージを受け取った後にセキュリティ・ヘッダーを処理し、リクエストに応答します。ビジネス・サービスには、WS-Policyセキュリティ文が構成されている必要があります。保護されたレスポンス・メッセージがそのままクライアントに渡されます。たとえば、クライアントはメッセージを暗号化して署名し、そのメッセージをプロキシ・サービスに送信します。プロキシ・サービスはメッセージの復号化、またはデジタル署名の確認を行いません。単にメッセージをビジネス・サービスにルーティングします。ビジネス・サービスはメッセージを復号化してデジタル署名を確認してから、リクエストを処理します。レスポンス・パスは同様です。これは、受動型中間プロキシと呼ばれることがあります。

48.8 Webサービス・セキュリティのアクティブな仲介とは何ですか。

アクティブな仲介シナリオでは、クライアントがリクエスト・メッセージとレスポンス・メッセージにWS-Securityを適用します。プロキシ・サービスが、セキュリティ・ヘッダーを処理してWS-Securityポリシーを適用します。たとえば、クライアントがメッセージを暗号化および署名してプロキシ・サービスに送信し、プロキシ・サービスがメッセージを復号化してデジタル署名を検証してから、メッセージをルーティングします。プロキシ・サービスは、レスポンスをクライアントに返す前に、メッセージに署名して暗号化します。クライアントはメッセージを復号化し、プロキシのデジタル署名を確認します。

48.9 アウトバウンドWebサービス・セキュリティとは何ですか。

アウトバウンドWS-Securityは、Service Busプロキシ・サービスとビジネス・サービスの間のセキュリティを表します。ビジネス・アプリケーションとプロキシ・サービスの間のリクエストとレスポンスの両方が含まれます。詳細は、「メッセージ・レベルのセキュリティについて」を参照してください。

48.10 SAMLとは何ですか。

SAML (Security Assertion Markup Language)は、OASIS標準ベースの拡張可能なXMLフレームワークです。認証および認可情報を交換することによって、最新のネットワーク環境でのシングル・サインオンを可能にします。

48.11 SAMLアサーションのサブジェクトIDの形式はカスタマイズ可能ですか。

デフォルトでは、アウトバウンドSAMLトークン内のサブジェクトIDは、インバウンド・ユーザー名と同じです。サブジェクトIDの形式は、カスタムのSAML名前マッパー・プロバイダを記述することでカスタマイズできます。詳細は、『Oracle WebLogic Serverセキュリティの管理』のSAML資格証明マッピング・プロバイダの構成に関する項を参照してください。

48.12 証明書検索および検証フレームワークとは何ですか。

証明書検索および検証(CLV)プロバイダは、証明書のパスを完成させてX509証明書チェーンを検証します。CLVプロバイダには次の2つのタイプがあります。

証明書パス・ビルダー - Webサービスまたはアプリケーション・コードから、証明書、証明書チェーンまたは証明書への参照(チェーン内の目的の証明書、または証明書のサブジェクトDN)を受け取ります。このプロバイダが、チェーン内の証明書を検索および検証します。

証明書パス検証プロバイダ - SSLプロトコル、Webサービスまたはアプリケーション・コードから証明書チェーンを受け取り、失効チェックなど追加の検証を実行します。

証明書パス・ビルダーと証明書パス検証プロバイダは、セキュリティ・レルムに少なくとも1つずつ構成する必要があります。1つのセキュリティ・レルムに、複数の証明書パス検証プロバイダを構成することもできます。複数のプロバイダを構成した場合は、すべての証明書パス検証プロバイダの検証が正常に終了しないと、証明書または証明書チェーンは有効になりません。WebLogic Serverでは、CLVプロバイダの機能をWebLogic証明書パス・プロバイダと証明書レジストリで提供します。詳細は、『Oracle WebLogic Serverセキュリティの理解』にある「WebLogicセキュリティ・サービスのアーキテクチャ」の証明書検索および検証に関する項を参照してください。

48.13 Service Busでは、プロキシ・サービスでのIDの伝播はサポートされますか。

はい。Service Busは、IDの伝播で2つのタイプの方法をサポートしています。

- Webサービス・セキュリティに準拠してSAMLアサーションを生成することにより、これを行います。
これは、プロキシがルーティングするビジネス・サービスでSAML holder-of-keyまたはsender-vouchesのWS-Policyを設定することで実行されます。

- ビジネス・サービスでユーザー名とパスワード・トークンを要求する場合は、元のクライアント・リクエストからユーザー資格証明をパススルーするようにビジネス・サービスのサービス・アカウントを構成します。「サービス・アカウントの操作」を参照してください。

48.14 シングル・サインオンはService Busでサポートされますか。

厳密に言えば、Service Busメッセージング・シナリオでは、シングル・サインオン(SSO)は様々な理由で使用できません。まず、Service Busはステートレスであるため、セッションの概念や複数のパーティ間での会話がありません。次に、Service Busのクライアントは、通常は他のエンタープライズ・ソフトウェア・アプリケーションであり、Webブラウザを使用するユーザーではありません。そのため、このようなクライアントがリクエストごとにユーザー名とパスワードなどの資格証明を送信する必要があっても、通信がSSLやWS-Securityなどの方法で保護されるかぎり、許容されます。ただし、Oracle Service BusコンソールとWebLogic Server管理コンソールの間のSSOはサポートされています。詳細については、『Oracle WebLogic Serverセキュリティの理解』の「セキュリティの基礎概念」にあるシングル・サインオンに関する項を参照してください。

48.15 セキュリティ・エラーはモニターされますか。

WS-Securityエラーのみが、Service Busモニター・フレームワークによってモニターされます。SSLハンドシェイク・エラー、トランスポート・レベルの認証、トランスポート・レベルのアクセス制御などのトランスポート・レベルのセキュリティ・エラーはモニターされません。ただし、監査プロバイダを構成して、トランスポート・レベルの認証と認可を監査することができます。詳細は、『Oracle Service Busの管理』のセキュリティ・ポリシーのモニタリングと管理に関する項を参照してください。

48.16 MBeanのセキュリティを構成できますか。

Service Busには、抽象WS-Policy文で利用できる資格証明のタイプなど、実行時の動作を構成する2つの管理対象Bean (MBean)があります。デフォルトでは、AdminおよびDeployerセキュリティ・ロールのユーザーのみがこれらのMBeanを変更できます。ただし、これらのデフォルトは変更できます。

49 ビジネス・サービスとプロキシ・サービスの保護

この章では、Service Busアプリケーションのビジネス・サービスとプロキシ・サービスにポリシーをアタッチする方法を説明します。ポリシーはメッセージの配信にセキュリティを適用します。

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

- ポリシーの概要

- ビジネス・サービスとプロキシ・サービスのセキュリティおよびセキュリティ・ポリシー

- JDeveloperでのポリシーのアタッチと構成

- Oracle Service Busコンソールでのポリシーのアタッチと構成

- Service Busクライアント・アクセス・セキュリティの構成

- メッセージ内の個人情報の非表示

49.1 ポリシーの概要

Oracle Fusion Middlewareは、ポリシー・ベースのモデルを使用して、組織全体のWebサービスを管理および保護します。ポリシーは、メッセージの配信にセキュリティを適用し、設計時環境の開発者と実行時環境のシステム管理者の両方によって管理できます。

ポリシーは、1つ以上のアサーションで構成されています。1つのポリシー・アサーションが、特定のアクションを実行するポリシーの最小単位となります。ポリシー・アサーションはリクエスト・メッセージとレスポンス・メッセージで実行され、どちらのタイプのメッセージでも同じアサーション・セットが実行されます。アサーションは、それらがポリシーに表示される順序で実行されます。

表49-1は、サポートされるポリシー・カテゴリを説明しています。

表49-1 サポートされるポリシー・カテゴリ

カテゴリ

説明

メッセージ送信最適化メカニズム(MTOM)

添付ファイルがMTOM形式であることを保証します。この形式を使用することで、バイナリ・データをWebサービスとの間で送受信できます。これによりワイヤ上の伝送サイズが削減されます。

セキュリティ

WS-Security 1.0および1.1標準を実装します。ユーザーの認証と認可、アイデンティティ伝播およびメッセージ保護(メッセージ整合性とメッセージの機密性)を適用します。

管理

リクエスト、レスポンスおよびフォルト・メッセージをメッセージ・ログに記録します。管理ポリシーにもカスタム・ポリシーを含めることができます。

個人の身元を特定する情報(PII)

個人情報を保護するため特定のフィールドを暗号化および復号化します。

注意:

JDeveloperには、「信頼性」および「アドレス指定」という2つのポリシー・カテゴリが追加で表示されます。Service Busでは、現在これらのポリシーはサポートされていません。Oracle Service Busコンソールでは、PIIポリシーとMTOMポリシーは、「セキュリティ」カテゴリに分類されます。

カテゴリ・タイプごとに、1つ以上のアタッチ可能なポリシー・タイプがあります。ポリシーのリストに目を向けると、情報アイコンをクリックして各ポリシーの説明を確認できます。

49.2 ビジネス・サービスとプロキシ・サービスのセキュリティおよびセキュリティ・ポリシー

Oracle Web Services Manager (OWSM)ポリシーを使用して、プロキシ・サービスとビジネス・サービスへのアクセスを保護できます。また、プロキシ・サービス構成でトランスポート・レベルおよびメッセージ・レベルのセキュリティを定義したり、ビジネス・サービス構成でトランスポート・レベルのセキュリティを定義したりすることもできます。OWSMポリシーの詳細は、「Oracle Web Services Managerを使用したOracle Service Busのセキュリティ」を参照してください。

サービス・プロバイダが必要となるのは、プロキシ・サービスがクライアント証明書認証を必要とするHTTPSサービスにメッセージをルーティングする場合です。また、一部のメッセージ・レベルのセキュリティ・シナリオで必要となる場合もあります。サービス・アカウントは、ビジネス・サービスに接続するときに認証を提供するために作成できます。これは要求されるユーザー名とパスワードのペアの別名リソースとして機能します。WebLogic Serverを使用して、資格レベルの検証を要求するビジネス・サービスのセキュリティ資格を直接管理できます。

49.2.1 Service Busのセキュリティ・ポリシー

OWSMポリシーを、WSDL Webサービス、メッセージング・サービス、任意のSOAPサービスまたは任意のXMLサービスのサービス・タイプのプロキシ・サービスまたはビジネス・サービスにアタッチできます。OWSMポリシーを、SOAP以外のWSDL Webサービス、メッセージング・サービスまたは任意のXMLサービスのプロキシ・サービスで使用するには、プロトコルをHTTPにする必要があります。WSDLベースのサービスの場合、OWSMポリシーは参照によってバインドされ、有効なWSDLファイル内にインライン化されません。OWSMポリシーでは、WS-Security 1.1、SAML 2.0およびKerberosToken Profileなどの各種業界標準をサポートしています。

以前のバージョンでは、Service Busは、WSDLファイルおよびWebLogic Serverで事前定義されたポリシーからのセキュリティ・ポリシーを受け入れていました。これらのポリシーは、12cではOWSMポリシーで置き換えられます。WSDL定義のポリシーまたはWLSポリシーを使用する以前のバージョンのプロジェクトをインポートする場合、ポリシーは読取り専用として表示されるため、変更できません。情報は、プロキシ・サービスまたはビジネス・サービスの構成に表示されるため、サービスをOWSMポリシーに更新できます。

49.2.2 ポリシーのオーバーライド

特定のOWSMポリシーを使用すると、ランタイム・プロパティのオーバーライド値を構成できます。OWSMポリシーを含むプロキシ・サービスをOracle Service Busコンソールで構成する場合、オーバーライドをサポートするポリシー・オーバーライド・オプションが、アタッチされるポリシーの下に表示されます。JDeveloperでは、「編集」アイコンによってダイアログが表示され、このダイアログでオーバーライドを構成できます。詳細は、「Oracle Web Services Managerを使用したOracle Service Busのセキュリティ」を参照してください。

49.2.3 セキュリティ設定

Service Busには、ビジネス・サービスとプロキシ・サービスのセキュリティ機能(サービスにアクセスするためのカスタム認証、トランスポート・レベルのセキュリティの指定)、およびプロキシ・サービスのみのセキュリティ機能(メッセージ・レベルのセキュリティ)が追加で用意されています。セキュリティ・ページとポリシー・ページで提供されているオンライン・ヘルプで、特定の設定に関する追加情報を確認できます。これらのオプションの詳細は、次の章を参照してください。

- Webサービスのメッセージ・レベルでのセキュリティの構成

- トランスポート・レベルのセキュリティの構成

- カスタム認証の構成

49.2.4 グローバル・ポリシー

JDeveloperまたはOracle Service BusコンソールでOWSMポリシーをサービスに適用する場合、ポリシーをそのサービスに直接割り当てます。また、Fusion Middleware Controlでグローバル・ポリシー・セットを使用すると、Service Busプロジェクトの複数のJCA、RESTおよびSOAPサービスにポリシーを割り当てることができます。詳細は、『Oracle Service Busの管理』のグローバル・ポリシーに関する項を参照してください。グローバル・ポリシー・アタッチメントおよびポリシー・セットの詳細は、Oracle Web Services Managerの理解のポリシー・セットを使用したグローバル・ポリシー・アタッチメントに関する項を参照してください。

49.2.5 ビジネス・サービスのサービス・アカウント

ビジネス・サービスのWS-Policyで認証を指定する場合、アウトバウンド・リクエストを行う際に、サービス・アカウントを選択して資格証明を指定できます。このビジネス・サービスにルーティングされるプロキシ・サービスは、このサービス・アカウントを使用してビジネス・サービスへの認証を行います。サービス・アカウントの資格証明は、次のOWSMポリシーの場合にサポートされます。

- oracle/**_username_token_**_client_policy

- oracle/wss11_saml_token_identity_switch_with_message_protection_client_policy

- oracle/**_saml*_**_client_policy (subject.precedenceプロパティをfalseに設定する場合のみ)

サービス・アカウントの資格証明は、次のOWSMポリシー・アサーションの場合も使用できます。

- oracle/**_username_token_**_client_template

- oracle/**_saml*_**_client_template (subject.precedenceプロパティをfalseに設定する場合のみ)

注意:

サービス・アカウントとcsf-keyのオーバーライドがどちらもビジネス・サービスに指定される場合、csf-key資格証明が優先されます。

49.2.6 アクティブなプロキシ・サービスのセキュリティ関連の検証

Oracle Service Busコンソールを使用して、アクティブなプロキシ・サービスへの変更が含まれるセッションをアクティブ化する場合、Service Busは変更を検証して、プロキシ・サービスの静的なエンドポイントに必要なすべての資格証明が作成されているかどうかを確認します。セッションにサービス・キー・プロバイダのキー・ペア・バインディングへの変更が含まれている場合は、そのサービス・キー・プロバイダを使用するすべてのプロキシ・サービスに対して変更が検証されます。たとえば、暗号化用のキー・ペアを削除すると、暗号化が必要なエンドポイントを含むサービス・キー・プロバイダを参照しているプロキシ・サービスに対して、検証エラーが報告されます。

次の条件により、セキュリティ関連の検証が実行されるタイミングと、検証中に行われるアクションが決定されます。

- プロキシ・サービスが静的なルートと処理を指定している場合は、静的なルートおよび処理に必要な資格証明が決定されます。必要な資格証明がプロキシ・サービスに含まれていない場合は、その資格証明が追加されるまで、セッションはコミットされません。

- プロキシ・サービスが静的なルートを指定しており、処理がインバウンド・リクエストからパススルーされる場合は、静的なルートおよび各ルートの処理に必要な資格証明が決定されます。必要な資格証明がプロキシ・サービスに含まれていない場合は、検証の警告が表示されますが、セッションをコミットすることはできます。

- プロキシ・サービスが動的なルートと処理を指定する場合は、Service Busではセキュリティ要件を検証できないため、実行時エラーが発生するおそれがあります。動的ルーティングについては、「動的ルーティングの使用」を参照してください。

49.3 JDeveloperでのポリシーのアタッチと構成

JDeveloperでは、設計時の環境でセキュリティをテストするためにポリシーをアタッチできます。アプリケーションを本番環境にデプロイする準備が整ったら、Oracle Enterprise Manager Fusion Middleware Controlでランタイム・ポリシーをアタッチまたはデタッチできます。ポリシーの実行時管理の詳細は、『Oracle Service Busの管理』のセキュリティ・ポリシーのモニタリングと管理に関する項を参照してください。

OWSMポリシーは、特定の構成のビジネス・サービスおよびプロキシ・サービスにのみアタッチできます。サービス・タイプおよびプロトコルによって、一部のポリシー・オプションが使用できない場合があります。サポートされる構成の詳細は、「Service Busのセキュリティ・ポリシー」を参照してください。サービス・アカウントがいつ使用されるかの詳細は、「ビジネス・サービスのサービス・アカウント」を参照してください。

以前のバージョンのService Busで作成されたサービスについては、WS-Policyの添付ファイルを含むWSDLファイルからサービスを作成すると、そのポリシーは、サービスの「ポリシー」ページに読取り専用で表示されます。

次のイメージは、JDeveloperでのビジネス・サービスの「ポリシー」ページを示しています。このイメージはすべてのカテゴリを示していますが、表示される実際のカテゴリは、サービス・タイプおよびサービスのプロトコルによって異なります。

図49-1 JDeveloperでのビジネス・サービスの「ポリシー構成」ページ

49.3.1 JDeveloperでのOracle Web Services Managerポリシーのアタッチ方法

JDeveloperでプロキシ・サービスまたはビジネス・サービスにポリシーをアタッチする場合、これらのポリシーは、WebLogic Serverにデプロイされるまで検証されません。OWSMの詳細は、「Oracle Web Services Managerを使用したOracle Service Busのセキュリティ」を参照してください。

注意:

サービスが以前のバージョンからアップグレードされ、WLS 9ポリシーが含まれる場合、それらのポリシーは表示できますが、編集できません。これらのポリシーは非推奨です。この項のステップを使用して、アップグレードされたサービス内のポリシーをOWSMポリシーに更新できます。

JDeveloperでのOracle Web Services Managerポリシーをアタッチするには:

1. アプリケーション・ナビゲータで、編集するビジネスまたはプロキシ・サービスを検索し、サービスのファイルをダブルクリックします。
ビジネスまたはプロキシ・サービス定義エディタが表示されます。

2. 「ポリシー」タブをクリックします。

3. 「ポリシー」ページで、使用可能なポリシー・バインディング・モデルのリストから「OWSMポリシー・ストアから」を選択します。
使用可能なカテゴリが表示されます。これらは、プロキシ・サービスまたはビジネス・サービスのサービス・タイプによって異なります。

4. 追加するポリシーのカテゴリで、*ポリシーの追加をクリックします。
選択可能なポリシーのリストを示すダイアログが表示されます。セキュリティ・ポリシーのダイアログを次に示します。

注意:

選択したカテゴリで使用可能なポリシーが1つのみの場合、*ポリシーの選択ダイアログは表示されず、かわりに使用可能なポリシーがポリシーの選択表に直接移入されます。

図49-2 JDeveloperでのセキュリティ・ポリシーの選択ダイアログ

5. *ポリシーの選択ダイアログが表示された場合は、次の手順を実行します。

a. 特定のポリシーに関する情報を表示するには、ポリシー名の右の情報アイコンをクリックします。

b. アタッチするポリシーを選択します。
複数のポリシーを選択するには、[Ctrl]キーと[Shift]キーを使用します。

c. 「OK」をクリックします。

ポリシーは、定義エディタで関連するカテゴリに追加されます。

6. ポリシーを一時的に無効にするには、ポリシーを選択し、ポリシーを含む表の上の選択したポリシーの無効化をクリックします。すべてのポリシーを一時的に無効にするには、すべてのポリシーの無効化をクリックします。

7. ポリシーを再度有効にするには、ポリシーを選択し、ポリシーを含む表の上の選択したポリシーの有効化をクリックします。すべてのポリシーを再度有効にするには、すべてのポリシーの有効化をクリックします。

8. 誤って追加されたポリシーを削除するには、そのポリシーを選択し、カテゴリの選択したポリシーの削除をクリックします。アタッチされたすべてのポリシーを削除するには、「すべてのポリシーの削除」をクリックします。

9. ポリシーの説明と追加情報を表示するには、そのポリシーの横の「詳細の表示」をクリックします。

10. ポリシーをビジネス・サービスにアタッチしている場合は、オプションで「サービス・アカウント」フィールドを参照し、そこからサービス・アカウントを選択できます。

11. ポリシーの構成が終了したら、「保存」をクリックします。

49.3.2 JDeveloperでポリシーのオーバーライド値を定義する方法

お使いの環境に同じポリシーを使用するサービスが含まれていることがあります。ただし、サービスごとに、オーバーライド・プロパティを使用して指定できる、固有のポリシー要件が存在する場合があります。すべてのポリシーがオーバーライド値を許容するわけではありません。

JDeveloperでポリシーのオーバーライド値を定義するには:

1. ポリシーを選択し、構成オーバーライド・プロパティを編集しますをクリックします。

構成オーバーライド・プロパティ・ダイアログが表示されます。

図49-3 JDeveloperでのOWSMポリシーの「構成オーバーライド・プロパティ」ダイアログ

2. 「オーバーライド値」列に、構成する各プロパティの「値」列にリストされたデフォルト値をオーバーライドするための値を入力します。

3. 「OK」をクリックします。

4. オーバーライド値の構成が終了したら、「保存」をクリックします。

49.3.3 JDeveloperでプロキシ・サービスのカスタム認証を構成する方法

カスタム認証を使用すると、カスタムのユーザー名とパスワードの組合せまたはカスタム・トークンを指定できます。カスタム・ユーザー名とパスワードまたはトークンをXPath形式で指定する必要が生じる場合があります。どちらの場合も形式は、Service Busで必要な情報を検索できるようにXPath式を指定するという点で似ています。これらのXPath式のルートは次のとおりです。

- サービスのバインドがAnySOAPまたはWSDL-SOAPの場合は、soap-env:Envelope/soap-env:Headerを使用します。

- サービスのバインドがSOAPベースでない場合はsoap-env:Bodyを使用します。

すべてのXPath式は有効なXPath形式である必要があります。使用するネームスペースをXPath式で宣言するには、次のようなXPathの"declare namespace"構文を使用します。

declare namespace
ns='http://webservices.mycompany.com/MyExampleService';)

注意:

次に説明するすべてのフィールドとタスクが、すべてのサービス・タイプで使用可能であるとはかぎりません。構成は、サービス・タイプとサービスのポリシー構成によって異なります。

また、プロキシ・サービスとビジネス・サービスのカスタム認証をトランスポート・レベルで構成することもできます。詳細は、「カスタム認証によるトランスポート・レベルのセキュリティの構成」を参照してください。

49.3.3.1 JDeveloperでのプロキシ・サービスのカスタム認証の構成

JDeveloperでプロキシ・サービスのカスタム認証を構成するには:

1. アプリケーション・ナビゲータで、編集するプロキシ・サービスを検索し、サービスのファイルをダブルクリックします。

プロキシ・サービス定義エディタが表示されます。

2. 「セキュリティ」タブをクリックします。

3. 次のいずれかを行います。

- ユーザー名とパスワードにXPathを指定するには、「カスタム・ユーザー名とパスワード」を選択します。式エディタを使用して、ユーザー名とパスワードのXPAthを定義します。

- トークンを指定するには、「カスタム・トークン」を選択し、トークン・タイプを選択してから、式エディタを使用してトークンへのXPathを定義します。

注意:

RESTプロキシ・サービスでは、現在、メッセージ・レベルのカスタム・トークン認証をサポートしていません。

4. オプションで、コンテキスト・プロバイダに追加情報を渡すためのコンテキスト・プロパティを指定できます。

詳細は、「コンテキスト・プロパティがセキュリティ・プロバイダに渡される」を参照してください。カスタム認証の詳細は、「カスタム認証の構成」を参照してください。

5. セキュリティ設定の構成が終了したら、「保存」をクリックします。

49.3.4 JDeveloperでプロキシ・サービスのサービス・キー・プロバイダを指定する方法

サービス・キー・プロバイダには、プロキシ・サービスがインバウンドSOAPメッセージの復号化、アウトバウンド認証、およびデジタル署名で使用する、公開鍵インフラストラクチャ(PKI)の資格証明情報が含まれます。この手順を実行する前に、プロキシ・サービスで使用されるサービス・キー・プロバイダのリソースを作成しておく必要があります。詳細は、「サービス・キー・プロバイダの操作」を参照してください。

JDeveloperでプロキシ・サービスのサービス・キー・プロバイダを指定するには:

1. アプリケーション・ナビゲータで、編集するプロキシ・サービスを検索し、サービスのファイルをダブルクリックします。

プロキシ・サービス定義エディタが表示されます。

2. 「セキュリティ」タブをクリックします。

3. 「サービス・キー・プロバイダ」フィールドの横にある「参照」または「検索」アイコンをクリックして、使用するサービス・キー・プロバイダを探して選択します。

4. セキュリティ設定の構成が終了したら、「保存」をクリックします。

49.3.5 JDeveloperでWebサービスのポリシー施行を指定する方法

プロキシ・サービスがセキュリティ・ヘッダーを処理せずにそのヘッダーをパススルーする場合、それは受動型中間と呼ばれます。Webサービス・セキュリティのパススルーの詳細は、「Webサービス・セキュリティのパススルーとは何ですか。」を参照してください。

JDeveloperでWebサービスのポリシー施行を指定するには:

1. アプリケーション・ナビゲータで、編集するプロキシ・サービスを検索し、サービスのファイルをダブルクリックします。

プロキシ・サービス定義エディタが表示されます。

2. 「セキュリティ」タブをクリックします。

3. 次のいずれかを行います。

- プロキシ・サービスでセキュリティ・ヘッダーを処理する必要がない場合は、「受動的なセキュリティ仲介」を選択します。

- プロキシ・サービスでセキュリティ・ヘッダーを処理する必要がある場合、「受動的なセキュリティ仲介」チェック・ボックスを選択解除します。

4. セキュリティ設定の構成が終了したら、「保存」をクリックします。

49.4 Oracle Service Busコンソールでのポリシーのアタッチと構成

OWSMポリシーは、特定の構成のビジネス・サービスおよびプロキシ・サービスにのみアタッチできます。サービス・タイプおよびプロトコルによって、一部のポリシー・オプションが使用できない場合があります。サポートされる構成の詳細は、「Service Busのセキュリティ・ポリシー」を参照してください。

以前のバージョンのService Busで作成されたサービスについては、WS-Policyの添付ファイルを含むWSDLファイルからサービスを作成すると、そのポリシーは、サービスの「ポリシー」ページに読取り専用で表示されます。

次のイメージは、Oracle Service Busコンソールでのビジネス・サービスの「ポリシー」ページを示しています。このイメージはすべてのカテゴリを示していますが、表示される実際のカテゴリは、サービス・タイプおよびサービスのプロトコルによって異なります。

図49-4 Oracle Service Busコンソールでのプロキシ・サービスの「ポリシー構成」ページ

49.4.1 コンソールでのOracle Web Services Managerポリシーのアタッチ方法

OWSMの詳細は、「Oracle Web Services Managerを使用したOracle Service Busのセキュリティ」を参照してください。

コンソールでOracle Web Services Managerポリシーをアタッチするには:

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. プロジェクト・ナビゲータで、ビジネス・サービスまたはプロキシ・サービスを検索し、サービス名をクリックします。
ビジネスまたはプロキシ・サービス定義エディタが表示されます。

3. 「ポリシー」タブをクリックします。

4. 「ポリシー」ページで、使用可能なポリシー・バインディング・モデルのリストから「OWSMポリシー・ストアから」を選択します。

5. 「サービス・レベル・ポリシー」表で「ポリシーのアタッチ」をクリックします。
次に示すように、「セキュリティ・ポリシー」ダイアログが表示されます。

図49-5 Oracle Service Busコンソールの「セキュリティ・ポリシー」ダイアログ

6. 次の手順を実行して、アタッチするポリシーを検索します。

a. タイプを選択して、検索するカテゴリまたはポリシーのいずれかの名前を入力します。

b. 「検索」をクリックします。

c. アタッチするポリシーが見つかったら、結果リストでそれを選択し、「アタッチ」をクリックします。

d. 複数のポリシーをアタッチできます。完了したら「OK」をクリックします。

7. ビジネス・サービスの場合のみ: ビジネス・サービスの資格証明が含まれるサービス・アカウントを選択するには、「サービス・アカウント」フィールドの横の「参照」をクリックし、使用するサービス・アカウントを参照して選択します。

注意:

ここでサービス・アカウント・リソースを選択するためには、事前にService Busで作成されている必要があります。

8. ポリシーの構成が終了したら、「保存」をクリックします。

9. ランタイムの変更をアクティブ化するには、「アクティブ化」をクリックします。

49.4.2 コンソールでポリシーのオーバーライド値を定義する方法

お使いの環境に同じポリシーを使用するサービスが含まれていることがあります。ただし、サービスごとに、オーバーライド・プロパティを使用して指定できる、固有のポリシー要件が存在する場合があります。すべてのポリシーがオーバーライド値を許容するわけではありません。

コンソールでポリシーのオーバーライド値を定義するには:

1. ポリシーをアタッチすると、オーバーライド値を指定できる場合は、「ポリシーのオーバーライド」セクションにポリシーが表示されます。「ポリシーのオーバーライド」表で、構成するポリシーを探します。

図49-6 Oracle Service Busコンソールの「ポリシーのオーバーライド」表

2. 「オーバーライド値」列で、構成する各プロパティの「オーバーライド値」列にリストされたデフォルト値をオーバーライドするための値を入力します。

3. オーバーライド値の構成が終了したら、「保存」をクリックします。

4. ランタイムの変更をアクティブ化するには、「アクティブ化」をクリックします。

49.4.3 コンソールでプロキシ・サービスのカスタム認証を構成する方法

カスタム認証を使用すると、カスタムのユーザー名とパスワードの組合せまたはカスタム・トークンを指定できます。カスタム・ユーザー名とパスワードまたはトークンをXPath形式で指定する必要が生じる場合があります。どちらの場合も形式は、Service Busで必要な情報を検索できるようにXPath式を指定するという点で似ています。これらのXPath式のルートは次のとおりです。

- サービスのバインドがAnySOAPまたはWSDL-SOAPの場合は、soap-env:Envelope/soap-env:Headerを使用します。

- サービスのバインドがSOAPベースでない場合はsoap-env:Bodyを使用します。

すべてのXPath式は有効なXPath形式である必要があります。使用するネームスペースをXPath式で宣言するには、次のようなXPathの"declare namespace"構文を使用します。

declare namespace
ns='http://webservices.mycompany.com/MyExampleService';)

注意:

次に説明するすべてのフィールドとタスクが、すべてのサービス・タイプで使用可能であるとはかぎりません。構成は、サービス・タイプとサービスのポリシー構成によって異なります。

また、プロキシ・サービスとビジネス・サービスのカスタム認証をトランスポート・レベルで構成することもできます。詳細は、「カスタム認証によるトランスポート・レベルのセキュリティの構成」を参照してください。

49.4.3.1 コンソールでのプロキシ・サーバーのカスタム認証の構成

コンソールでプロキシ・サーバーのカスタム認証を構成するには:

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. プロジェクト・ナビゲータで、編集するプロキシ・サービスを検索し、そのプロキシ・サービスの名前をクリックします。

「プロキシ・サービス定義」ページが表示されます。

3. 「セキュリティ設定」タブをクリックします。

4. 次のいずれかを行います。

- ユーザー名とパスワードにXPathを指定するには、「カスタム・ユーザー名とパスワード」を選択します。式エディタを使用して、ユーザー名とパスワードのXPAthを定義します。

- トークンを指定するには、「カスタム・トークン」を選択し、トークン・タイプを選択してから、式エディタを使用してトークンへのXPathを定義します。

5. オプションで、コンテキスト・プロバイダに追加情報を渡すためのコンテキスト・プロパティを指定できます。詳細は、「コンテキスト・プロパティがセキュリティ・プロバイダに渡される」を参照してください。カスタム認証の詳細は、「カスタム認証の構成」を参照してください。

6. セキュリティ設定の構成が終了したら、「保存」をクリックします。

7. ランタイムの変更をアクティブ化するには、「アクティブ化」をクリックします。

49.4.4 コンソールでプロキシ・サービスのサービス・キー・プロバイダを指定する方法

サービス・キー・プロバイダには、プロキシ・サービスがインバウンドSOAPメッセージの復号化、アウトバウンド認証、およびデジタル署名で使用する、公開鍵インフラストラクチャ(PKI)の資格証明情報が含まれます。この手順を実行する前に、プロキシ・サービスで使用されるサービス・キー・プロバイダのリソースを作成しておく必要があります。詳細は、「サービス・キー・プロバイダの操作」を参照してください。

コンソールでプロキシ・サービスのサービス・キー・プロバイダを指定するには:

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. プロジェクト・ナビゲータで、編集するプロキシ・サービスを検索し、そのプロキシ・サービスの名前をクリックします。

「プロキシ・サービス定義」ページが表示されます。

3. 「セキュリティ設定」タブをクリックします。

4. サービス・キー・プロバイダを指定するには、「参照」または「検索」アイコンをクリックして、使用するサービス・キー・プロバイダを検索し、選択します。

5. セキュリティ設定の構成が終了したら、「保存」をクリックします。

6. ランタイムの変更をアクティブ化するには、「アクティブ化」をクリックします。

49.4.5 コンソールでWebサービスのポリシー施行を指定する方法

プロキシ・サービスがセキュリティ・ヘッダーを処理せずにそのヘッダーをパススルーする場合、それは受動型中間と呼ばれます。Webサービス・セキュリティのパススルーの詳細は、「Webサービス・セキュリティのパススルーとは何ですか。」を参照してください。

コンソールでWebサービスのポリシー施行を指定するには:

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. プロジェクト・ナビゲータで、編集するプロキシ・サービスを検索し、そのプロキシ・サービスの名前をクリックします。

「プロキシ・サービス定義」ページが表示されます。

3. 「セキュリティ設定」タブをクリックします。

4. 次のいずれかを行います。

- プロキシ・サービスでセキュリティ・ヘッダーを処理する必要がない場合は、「受動的なセキュリティ仲介」を選択します。

- プロキシ・サービスでセキュリティ・ヘッダーを処理する必要がある場合、「受動的なセキュリティ仲介」チェック・ボックスを選択解除します。

5. セキュリティ設定の構成が終了したら、「保存」をクリックします。

6. ランタイムの変更をアクティブ化するには、「アクティブ化」をクリックします。

49.5 Service Busクライアント・アクセス・セキュリティの構成

プロキシ・サービスへのクライアント・アクセスは、Oracle Service Busコンソールでサービス構成に直接定義されます。プロキシ・サービスを作成または管理する場合は、「セキュリティ」タブの「セキュリティ設定」ページでサービスへのクライアント・アクセスを表示および更新できます。トランスポート・レベルの認証とメッセージ・レベルの認証の両方が存在する場合、メッセージ・レベルのサブジェクトIDが伝播されます。

49.5.1 トランスポート・レベルのアクセス・ポリシーの構成方法

プロキシ・サービスのトランスポート・レベル・セキュリティ・ポリシーは、Oracle Service Busコンソールのプロキシ・サービス定義エディタの「セキュリティ設定」タブで構成します。このページからポリシー・エディタにアクセスできます。

プロキシ・サービスがアクティブになると、Service Busでは、シンWebアプリケーションが生成され、デプロイされます。Service Busは、セッション管理、クライアント証明書の検証および認証、信頼性の管理およびサーバーのSSL鍵/証明書の操作といったサーバー側SSLの部分でWebLogic Serverに依存します。

様々なService Busトランスポートのトランスポート・レベルのセキュリティを定義する方法の詳細は、「トランスポート・レベルのセキュリティの構成」を参照してください。

「トランスポート・レベルでのアクセス・ポリシーの構成」の説明に従ってトランスポート・レベル・アクセス・ポリシーを構成するには、「ポリシー・エディタを開くためのHTTP URLリンクの有効化」の説明に従ってHTTP URLリンクを使用可能にしてポリシー・エディタを開く必要があります。

49.5.1.1 ポリシー・エディタを開くためのHTTP URLリンクの有効化

ポリシー・エディタを開くためにHTTP URLリンクを有効にするには:

1. 管理権限があるユーザーとして、Fusion Middleware Controlにログインします。

2. ターゲットのナビゲータで、「SOA」を開き、「service-bus」をクリックします。

3. 「Service Bus」メニューで、「セキュリティ」→「アプリケーション・ポリシー」を選択します。

4. 「アプリケーション・ポリシー」ページの「アプリケーション・ストライプ」フィールドで、Service_Bus_Consoleを選択します。
「作成」ボタンが有効になります。

5. 表の上にある「作成」をクリックします。

6. 「アプリケーション権限の作成」ページの「権限受領者」セクションで、「追加」をクリックします。

7. 「プリンシパルの追加」ダイアログで、次の操作を実行します。

a. 「タイプ」フィールドで、「アプリケーション・ロール」を選択します。

b. 「検索」をクリックします。

c. MiddlewareAdministratorロールを選択して、「OK」をクリックします。

8. 「アプリケーション権限の作成」ウィンドウの「権限」セクションで、「追加」をクリックします。

9. 「権限の追加」ダイアログで、次の操作を実行します。

a. Javaクラス単位で検索するには、「権限」を選択し、「権限クラス」フィールドでoracle.soa.osb.console.common.permissions.OSBPermissionを選択します。

b. 「検索」をクリックします。

c. 検索結果リストで、AdminOnlyTaskAccess を選択し、「続行」をクリックします。

d. 「権限アクション」フィールドで、updateを選択します。これによりAllも選択されます。

e. 「選択」をクリックします。
新しい権限が「権限」表に表示されます。

10. 権限の付与が完了したら、「アプリケーション権限の作成」ウィンドウの「OK」をクリックします。完了後、トランスポート・レベルのアクセス・ポリシーを構成する次のタスクを実行できます。

49.5.1.2 トランスポート・レベルでのアクセス・ポリシーの構成

トランスポート・レベルのアクセス・ポリシーを構成するには:

1. Oracle Service Busコンソールに管理者権限を持つユーザーとしてログインします。管理者権限を持つユーザーのみがセキュリティ構成データを変更できます。

2. セッションがアクティブでない場合は、「作成」または「編集」をクリックしてセッションを起動または再起動します。

3. プロジェクト・ナビゲータで、構成するトランスポート・レベル・アクセスのプロキシ・サービスを検索して開きます。

4. 「セキュリティ設定」タブをクリックします。

5. 「トランスポート・アクセス制御」フィールドでリンクをクリックします。

ポリシー・エディタが表示されます。

6. 「認証プロバイダ」フィールドで、認証プロバイダを選択します。「XACMLAuthorizer」を選択することをお薦めします。

7. 「ポリシー条件の追加方法」のいずれかの手順を使用してポリシー条件を追加します。

8. 「ポリシー条件」セクションでの条件の入力が終了したら、「保存」をクリックします。

49.5.2 メッセージ・レベルのアクセス・ポリシーの構成方法

プロキシ・サービスのメッセージ・レベル・セキュリティ・ポリシーは、Oracle Service Busコンソールのプロキシ・サービス定義エディタの「セキュリティ設定」タブで構成します。このページからポリシー・エディタにアクセスできます。アクセス・ポリシーは操作レベルでも同様に構成できます。

トランスポート・レベルのセキュリティの定義方法の詳細は、「Webサービスのメッセージ・レベルでのセキュリティの構成」を参照してください。

メッセージ・レベルのアクセス・ポリシーを構成するには:

1. Oracle Service Busコンソールに管理者権限を持つユーザーとしてログインします。管理者権限を持つユーザーのみがセキュリティ構成データを変更できます。

2. セッションがアクティブでない場合は、「作成」または「編集」をクリックしてセッションを起動または再起動します。

3. プロジェクト・ナビゲータで、構成するトランスポート・レベル・アクセスのプロキシ・サービスを検索して開きます。

4. 「セキュリティ設定」タブをクリックします。

5. 「メッセージ・アクセス制御」フィールドでリンクをクリックします。

注意:

このフィールドでの選択に応じて、メッセージ・レベルまたは操作レベルのアクセス制御を定義できます。

ポリシー・エディタが表示されます。

6. 「認証プロバイダ」フィールドで、認証プロバイダを選択します。「XACMLAuthorizer」を選択することをお薦めします。

注意:

Service Busでは、WebLogicのデフォルト認可プロバイダのサポートは非推奨です。かわりに、WebLogic XACML認可プロバイダを使用することをお薦めします。

7. 「ポリシー条件の追加方法」のいずれかの手順を使用してポリシー条件を追加します。

8. 「ポリシー条件」セクションでの条件の入力が終了したら、「保存」をクリックします。

49.5.3 ポリシー条件の追加方法

ユーザー、グループまたはロールが保護されている操作を呼び出すことができるようにするための複数の条件を定義できます。条件は、グループまたはロール、アクセスの日付または時間、コンテキスト要素(トランスポート・レベル・ポリシー)などの項目に基づきます。

ポリシー条件を追加するには:

1. アクセス制御ポリシーのポリシー・エディタにアクセスします。「トランスポート・レベルのアクセス・ポリシーの構成方法」または「メッセージ・レベルのアクセス・ポリシーの構成方法」を参照してください。

2. ポリシー・エディタで、「ポリシー条件」の下にある「条件の追加」をクリックします。
「述部の選択」ページが表示されます。

3. リストから述部を選択します。

4. 「次へ」をクリックします。条件の述部に対する選択に応じて、表49-2に示す手順のいずれかを実行します。
いつでも、「戻る」をクリックして変更を破棄し、前のページに戻るか、「取消」をクリックして変更を破棄し、プロキシ・サービス定義エディタに戻ることができます。

表49-2 条件の述部のオプション

選択内容

これらの手順を完了するには...

ロール

トランスポート・レベルのセキュリティでは、クライアントによる資格証明の提供を可能にするプロトコルをプロキシ・サービスが使用している場合にのみ、この条件が適用されます。

a. 「ロール引数名」フィールドに、アクセス権を与えるアプリケーション・ロールを入力します。

b. 「追加」をクリックします。

c. ロールの追加が終了するまで、ステップ1と2を繰り返します。「削除」をクリックすると、リストからその引数を削除できます。

d. 「終了」をクリックします。

グループ

トランスポート・レベルのセキュリティでは、クライアントによる資格証明の提供を可能にするプロトコルをプロキシ・サービスが使用している場合にのみ、この条件が適用されます。

a. 「グループ引数名」フィールドに、アクセス権を与えるグループを入力します。
このフィールドに入力したグループがまだ作成されていない場合は、アクセス制御ポリシーを作成した後に作成できます。『Oracle Service Busの管理』のOracle Service Busグループの作成に関する項を参照してください。このグループを作成しないと、誰にもアクセス権が与えられません。

b. 「追加」をクリックします。

c. 引数の追加が終了するまで、ステップ1と2を繰り返します。「削除」をクリックすると、リストからその引数を削除できます。

d. 「終了」をクリックします。

ユーザー

トランスポート・レベルのセキュリティでは、クライアントによる資格証明の提供を可能にするプロトコルをプロキシ・サービスが使用している場合にのみ、この条件が適用されます。

a. 「ユーザー引数名」フィールドに、アクセス権を与えるユーザーを入力します。
このフィールドに入力したユーザーがまだ作成されていない場合は、アクセス制御ポリシーを作成した後に作成できます。『Oracle Service Busの管理』のOracle Service Busユーザーの作成に関する項を参照してください。このユーザーを作成しない場合は、誰にもアクセス権は付与されません。

b. 「追加」をクリックします。

c. 引数の追加が終了するまで、ステップ1と2を繰り返します。「削除」をクリックすると、リストからその引数を削除できます。

d. 「終了」をクリックします。

指定した曜日にアクセスが発生

a. 「曜日」フィールドに、曜日の完全な名前を入力します。

b. 「GMTオフセット」フィールドに、GMTより進んだ標準時を使用する場合はその時差をGMT+h:mmの書式で、GMTより遅れた標準時を使用する場合はGMT-h:mmの書式で入力します。たとえば、アメリカ東部標準時の場合は「GMT-5:00」と入力します。

c. 「終了」をクリックします。

指定した時間帯にアクセスが発生

a. 「開始時刻」フィールドに、許容される最も早い時刻をhh:mm:ss AM|PMの書式で入力します。たとえば、「12:45:00 AM」と入力します。

b. 「終了時刻」フィールドに、許容される最も遅い時刻をhh:mm:ss AM|PMの書式で入力します。

c. 「GMTオフセット」フィールドに、GMTより進んだ標準時を使用する場合はその時差をGMT+h:mmの書式で、GMTより遅れた標準時を使用する場合はGMT-h:mmの書式で入力します。たとえば、アメリカ東部標準時の場合は「GMT-5:00」と入力します。

d. 「終了」をクリックします。

「次の日時より前にアクセスが発生」または「次の日時より後にアクセスが発生

a. 「日付」フィールドに、日付をm/d/yyの書式で入力します。たとえば、「1/1/04」と入力します。必要に応じて時刻をh:mm:ss AM|PMの書式で入力することもできます。その場合は、「1/1/04 12:45:00 AM」のように入力します。

b. 「GMTオフセット」フィールドに、GMTより進んだ標準時を使用する場合はその時差をGMT+hh:mmの書式で、GMTより遅れた標準時を使用する場合はGMT-hh:mmの書式で入力します。たとえば、アメリカ東部標準時の場合は「GMT-5:00」と入力します。

c. 「終了」をクリックします。

「指定した日にアクセスが発生」、「指定した日より前にアクセスが発生」または「指定した日より後にアクセスが発生」

a. 「指定した日」フィールドに、現在の月内の日を-31から31の値で入力します。負の値は月末から逆に数えることを意味し、-1は月の最終日を表します。0は、その月の初日の前日を表します。

b. 「GMTオフセット」フィールドに、GMTより進んだ標準時を使用する場合はその時差をGMT+hh:mmの書式で、GMTより遅れた標準時を使用する場合はGMT-hh:mmの書式で入力します。たとえば、アメリカ東部標準時の場合は「GMT-5:00」と入力します。

c. 「終了」をクリックします。

コンテキスト要素が定義されている

注意: トランスポート・レベルのセキュリティにのみ適用されます。コンテキスト要素は、Webコンテナなどのコンテナがセキュリティ・プロバイダに提示できる(オプション)パラメータと値のペアです。コンテキスト要素は、メッセージ・レベルのアクセス制御ポリシーでは使用できません。指定できる値については、「コンテキスト・プロパティがセキュリティ・プロバイダに渡される」を参照してください。

a. 「コンテキスト要素名」フィールドに、コンテキスト要素の名前を入力します。

b. 「終了」をクリックします。

コンテキスト要素の値が文字列定数と等しい

トランスポート・レベルのセキュリティにのみ適用されます。コンテキスト要素の詳細は、前述の「コンテキスト要素が定義されている」の注記を参照してください。

a. 「コンテキスト要素名」フィールドで、評価する値のコンテキスト要素の名前を入力します。

b. 「文字列値」フィールドに、比較対象となる文字列値を入力します。

c. 「終了」をクリックします。

「コンテキスト要素の値が数値定数より大きい」、「コンテキスト要素の値が数値定数と等しい」または「コンテキスト要素の値が数値定数より小さい」

トランスポート・レベルのセキュリティにのみ適用されます。コンテキスト要素の詳細は、前述の「コンテキスト要素が定義されている」の注記を参照してください。

a. 「コンテキスト要素名」フィールドで、評価する値のコンテキスト要素の名前を入力します。

b. 「数値」フィールドに、数値を入力します。

c. 「終了」をクリックします。

全員に対してアクセスを拒否、全員に対してアクセスを許可またはサーバーが開発モードである

「終了」をクリックします。

5. 前述のステップを繰り返して、各種ポリシー条件に基づき式を追加します。複数の条件を追加すると、演算子リストが表示され、ANDまたはORのいずれかによって条件の結合を選択できます。

6. 定義した条件を変更するには、次のステップのいずれかを実行します。

- 選択した式の順序を変更するには、条件に関連付けられたチェック・ボックスを選択し、「上に移動」および「下に移動」をクリックします。

- ポリシー条件をグループ化するには、それらの条件に関連付けられたチェック・ボックスを選択し、「結合」をクリックします。これによって、Role: Administrator OR (Role: Developer AND Access occurs after: 12/1/13, GMT-5:00)などの条件を作成できます。

- 結合したポリシー条件をグループ解除するには、それらの条件に関連付けられたチェック・ボックスを選択し、「結合解除」をクリックします。

- 条件を否定にするには、その条件に関連付けられたチェック・ボックスを選択し、「否定」をクリックします。たとえば、NOT Group Operatorsでは、ポリシーからOperatorsグループが除外されます。

- 選択した式を削除するには、その条件に関連付けられたチェック・ボックスを選択し、「削除」をクリックします。

49.6 メッセージ内の個人情報の非表示

Service Busパイプラインで機密データ(個人情報(Personally Identifiable Information: PII)として知られる)を保護するためにメッセージのフィールドを暗号化および復号化できます。この機能は、このようなデータが管理コンソールでクリア・テキストで表示されるのを防ぐため、特定のフィールド(たとえば、SSN)を不明瞭化します。

メッセージは暗号化され、プロキシ・サービスを介してService Busへ送られ、その後、ビジネス・サービスの出口で復号化されます。Service Bus外部のメッセージは、他のメッセージ保護ポリシー(WS-Security/SSL)を使用して保護できます。

次の例では、暗号化されていないメッセージの例を示します。PIIフィールドは、nameとdriversLicenseです。

例 - 暗号化されていないメッセージ

<person>
<name>John</name>
<driversLicense>B1234</driversLicense>
<ssn>123-456-789</ssn>
</person>

次の例では、暗号化された形式のnameフィールドおよびdriversLicenseフィールドでの暗号化されたメッセージの例を示します。

例 - 暗号化されたメッセージ

<person>
<name>John</name>
<driversLicense>encrypted:fdslj[lmsfwer09fsn;keyname=pii-csf-key</driversLicense>
<ssn>encrypted:gdf45md%mfsd103k;keyname=pii-csf-key</ssn>
</person>

暗号化書式は次のとおりです。

encrypted:<CIPHER_TEXT>;keyname:<CSF_KEY_NAME>

注意:

PIIポリシーと認可ポリシーの両方がサービスにアタッチされている場合は、PIIポリシーの前に認可ポリシーが実行されます。これは、PIIポリシーが認可に使用されるフィールドを暗号化することがあるためです。

認可ポリシーがサービスにアタッチされ、すでに暗号化されたフィールドが必要な場合は、認可は失敗します。

49.6.1 個人情報を非表示にする方法

- 暗号化メッセージをサービスと切り離す場合は、PIIを復号化する必要があります。PIIポリシーをプロキシ・サービスにアタッチしているが、そのターゲット・サービスにアタッチしない場合、アウトバウンド・メッセージのPIIは復号化されません。ただし、実際にはお薦めしません。

- あるService Busサービスで暗号化されたPIIは、別のService Busサービスでは復号化できません。

49.6.1.1 JDeveloperを使用した個人情報の非表示

JDeveloperを使用して個人情報を非表示にするには:

1. アプリケーション・ナビゲータで、編集するビジネスまたはプロキシ・サービスを検索し、サービスのファイルをダブルクリックします。

ビジネスまたはプロキシ・サービス定義エディタが表示されます。

2. 「ポリシー」タブをクリックします。

3. 「ポリシー」ページで、使用可能なポリシー・バインディング・モデルのリストから「OWSMポリシー・ストアから」を選択します。

4. 追加するポリシーのカテゴリで、*ポリシーの追加をクリックします。

ポリシーが追加されます。

5. 「個人の身元を特定する情報」セクションでポリシーを選択し、「編集」アイコンをクリックします。

「PIIプロパティのオーバーライド」ダイアログが表示され、入力メッセージからフィールドを選択しますページが示されます。

6. 「機密要素の選択」ペインで、ツリー・リストを開いて、非表示にする値を持つフィールドを選択し、右矢印をクリックしてそれを「XPath式」に移動します。

図49-7 「PIIプロパティのオーバーライド」ダイアログ

7. 暗号化するフィールドごとに上記ステップを繰り返します。

8. 「次」をクリックします。

「出力メッセージからフィールドを選択します」ページが表示されます。

9. ステップ6から8を繰り返して、出力メッセージのフィールドを選択します。

10. CSFキーを選択します。暗号化と復号化に使用されるキーは、このCSFキーから取得されるパスワードに基づきます。

49.6.1.2 コンソールを使用した個人情報の非表示

コンソールを使用して個人情報を非表示にするには:

1. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

2. プロジェクト・ナビゲータで、ビジネス・サービスまたはプロキシ・サービスを検索し、サービス名をクリックします。
ビジネスまたはプロキシ・サービス定義エディタが表示されます。

3. 「ポリシー」タブをクリックします。

4. 「ポリシー」ページで、使用可能なポリシー・バインディング・モデルのリストから「OWSMポリシー・ストアから」を選択します。

5. 「サービス・レベル・ポリシー」表で「ポリシーのアタッチ」をクリックします。
「セキュリティ・ポリシー」ダイアログが表示されます。

6. 次の手順でポリシーを選択します。

a. oracle/pii_security_policyポリシーの検索を実行するか、リストで該当するポリシーを探します。

b. ポリシーが見つかったら、結果リストでそれを選択し、「アタッチ」をクリックします。

c. 「OK」をクリックします。

7. 「ポリシーのオーバーライド」セクションで、次の情報を入力します。

- response.xpaths: レスポンス内の暗号化するフィールドを識別するXPath式のカンマ区切りリスト。

- response.namespaces: レスポンスのネームスペースのカンマ区切りリスト。各ネームスペースには、等号で区切られた接頭辞とURIがあります。

- reference.priority: ポリシー・アタッチメントの優先度を指定するオプションのプロパティ。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のreference.priorityに関する項を参照してください。

- request.namespaces: リクエストのネームスペースのカンマ区切りリスト。各ネームスペースには、等号で区切られた接頭辞とURIがあります。

- csf-key: フィールド値の暗号化と復号化に使用するパスワード情報を含むCSFキーの名前。

- request.xpaths: リクエスト内の暗号化するフィールドを識別するXPath式のカンマ区切りリスト。

50 Webサービスのメッセージ・レベルでのセキュリティの構成

この章では、Service Busのメッセージ・レベルのセキュリティを構成する方法について説明します。

メッセージ・レベルのセキュリティでは、Webサービス・クライアントがService Busプロキシ・サービスまたはビジネス・サービスとの接続を確立した後、プロキシ・サービスまたはビジネス・サービスがこのメッセージを処理する前にSOAPメッセージに対してセキュリティ・チェックが適用されます。

メッセージ・レベルのセキュリティは、次のように分類されます。

- インバウンド・メッセージ・レベルのセキュリティは、クライアントとService Busプロキシ・サービス間のメッセージに適用されます。このセキュリティは、クライアントからのリクエストおよびクライアントに返されるレスポンス・メッセージの両方に適用されます。
これを、プロキシ・サービスのセキュリティと考えることができます。

- アウトバウンド・メッセージ・レベルのセキュリティは、Service Busプロキシ・サービスとSOAP-HTTPビジネス・サービス間のメッセージ、またはService Busプロキシ・サービスとSOAP-JMSビジネス・サービス間のメッセージに適用されます。また、このセキュリティはリクエストとレスポンスの両方に適用されます。
これを、ビジネス・サービスのセキュリティと考えることができます。

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

- メッセージ・レベルのセキュリティについて

- プロキシ・サービスのメッセージ・レベルのアクセス制御ポリシー

- プロキシ・サービスのメッセージ・レベルのセキュリティの構成

- ビジネス・サービスのメッセージ・レベルのセキュリティの構成:主な手順

- サービス・アイデンティティ証明拡張の使用

- カスタムWS-Policy文の例

- アウトバウンドWS-Securityの無効化

プロキシ・サービスのメッセージ・レベルのセキュリティを構成する手順については、「Service Busクライアント・アクセス・セキュリティの構成」を参照してください。

注意:

メッセージ・レベルのセキュリティの実装には、メッセージ・レベルのカスタム認証(カスタム・トークンまたはユーザー名/パスワードのどちらか)で構成されたプロキシ・サービスが含まれます。

この項で説明されるメッセージ・レベルのセキュリティ・メカニズムは、単独またはメッセージ・レベルのカスタム認証メカニズムとともに機能します。これについては、「カスタム認証の構成」で説明します。両方のタイプのセキュリティの使用について詳しくは、「WS-Securityおよびカスタム・ユーザー名/パスワードとトークンの組合せ」を参照してください。

50.1 メッセージ・レベルのセキュリティについて

Service Busでは、HTTP (HTTPS含む)またはJMSプロトコル経由で送信されるSOAPメッセージに対し、メッセージ・レベルのセキュリティをサポートします。通常、これらのプロトコルで提供されるトランスポート・レベルのセキュリティに加えて、メッセージ・レベルのセキュリティを使用します。トランスポート・レベル、メッセージ・レベルまたは両方のレベルで資格証明を提供するようにWebサービス・クライアントに要求できます。両方のレベルで資格証明を提供するようにクライアントに要求する場合、Service Busはプロキシ・サービスの認証および認可に対してメッセージ・レベルの資格証明を使用します。

Webサービスであるプロキシ・サービスまたはビジネス・サービスのメッセージ・レベルのセキュリティ要件を指定するには、Webサービス・ポリシー(WS-Policy)フレームワークを使用します。

メッセージ・レベルのセキュリティでは、プロキシ・サービスまたはビジネス・サービスが、保護される操作、およびWebサービス・クライアントがSOAPメッセージ(操作を呼び出すリクエストを含む)に適用する必要がある次のセキュリティ対策を指定します。

- 認証
ドメインの認証プロバイダにあるユーザー・アカウントと比較できるIDの提示をクライアントに要求します。

- デジタル署名によるメッセージの整合性
ある操作の呼出しをリクエストするクライアントのIDを立証し、そのリクエストを改ざんした仲介者がいないことを保証します。また、その操作の戻り値が、仲介者によって改ざんされることなくクライアントに返されたことを保証します。

- XML暗号化によるメッセージの機密性
リクエストおよびレスポンスの戻り値を暗号化し、リクエストまたはレスポンスを参照した仲介者がいないことを保証します。

これらのセキュリティ対策のすべてで、SOAPメッセージのセキュリティ・トークンをコード化することがクライアントに要求されます。プロキシ・サービスまたはビジネス・サービスは、SOAPメッセージでのコード化を要求するセキュリティ・トークンのタイプを指定します。

50.1.1 メッセージ・レベルのセキュリティの一連のアクションのサンプル

メッセージ・レベルのセキュリティを要求するプロキシ・サービスにSOAPメッセージを送信するために、次のアクションが発生します。

1. Webサービス・クライアントがSOAPヘッダーを生成し、そのヘッダーをSOAPメッセージ・エンベロープに追加します。そのヘッダーには、デジタル署名、セキュリティ・トークン、および他の構成要素が含まれます。

2. プロキシ・サービスは、保護されたエンベロープを処理するときに、メッセージを復号化して、セキュリティ・ヘッダーを削除します。

3. 次に、メッセージがセキュリティ要件に準拠していることを確認します。たとえば、必要なメッセージ部分が署名または暗号化(またはその両方)されているかどうか、また必要なトークンが必要なクレームと共に存在するかどうかをプロキシ・サービスが確認します。

4. プロキシ・サービスからクライアントへのレスポンスでは、プロセス全体が逆方向に繰り返されます。

50.2 プロキシ・サービスのメッセージ・レベルのアクセス制御ポリシー

メッセージの整合性とメッセージの機密性によってメッセージが仲介で参照または改ざんされていないことが保証され、メッセージ認証によってクライアントは既知のユーザーであるという立証を要求されますが、これは どの 既知のユーザーがプロキシ・サービス操作を呼び出すことを許可(認可)されているかを指定するものではありません。

認可されたユーザーにアクセスを制限するには、Oracle Service Busコンソールを使用してメッセージ・レベルのアクセス制御ポリシーを作成します。これらのポリシーにより、認可されたクライアントからのSOAPメッセージのみをプロキシ・サービスで処理できます。

50.3 プロキシ・サービスのメッセージ・レベルのセキュリティの構成

インバウンド・メッセージ・レベルのセキュリティ用に次のいずれかの方法をサポートするように、プロキシ・サービスを構成できます。

- アクティブな仲介
プロキシ・サービスは、クライアントのSOAPメッセージのヘッダーを処理し、そのメッセージに対してメッセージ・レベルのアクセス制御ポリシーを強制します。

たとえば、クライアントはSOAPメッセージを暗号化して署名し、そのメッセージをプロキシ・サービスに送信します。プロキシ・サービスはメッセージを復号化してデジタル署名を確認してから、メッセージをルーティングします。プロキシ・サービスは、レスポンスをクライアントに返す前に、メッセージに署名して暗号化します。クライアントはメッセージを復号化し、プロキシ・サービスのデジタル署名を確認します。

- パススルー
プロキシ・サービスは、クライアントのSOAPメッセージのヘッダーを処理するかわりに、メッセージをそのままビジネス・サービスに渡します。プロキシ・サービスはSOAPメッセージの保護されたセクションを処理しませんが、ヘッダーの値に基づいてメッセージをルーティングできます。ビジネス・サービスは、メッセージを受け取ると、セキュリティ・ヘッダーを処理し、リクエストに応答します。ビジネス・サービスはWebサービス・ポリシー(WS-Policy)フレームワークを使用して、メッセージ・レベルのセキュリティで保護されている操作を記述する必要があります。ビジネス・サービスはレスポンスをプロキシ・サービスに送信し、プロキシ・サービスはレスポンスをそのままクライアントに渡します。

たとえば、クライアントはメッセージを暗号化して署名し、そのメッセージをプロキシ・サービスに送信します。プロキシ・サービスはメッセージの復号化、またはデジタル署名の確認を行いません。単にメッセージをビジネス・サービスにルーティングします。ビジネス・サービスはメッセージを復号化してデジタル署名を確認してから、リクエストを処理します。レスポンス・パスは同様です。

50.3.1 アクティブな仲介プロキシ・サービスの作成: 主な手順

アクティブな仲介として動作するようにプロキシ・サービスを作成するには:

1. テキスト・エディタまたはIDEで、プロキシ・サービスを定義するWSDLドキュメントを作成します。

- ポリシーをOracle Service Busコンソールから直接バインドする場合は、WSDLファイルにポリシー文を含める必要はありません。

- ポリシーをWSDLベースにする場合は、WSDLドキュメントに、定義済のポリシーなどの、1つまたは複数のWebサービス・ポリシー(WS-Policy)文を追加します。

2. Oracle Service Busコンソールで、WSDLドキュメントをService Bus WSDLリポジトリにインポートし、すべてのWSDLの依存関係を解決します。
WSDLファイルの詳細は、「WSDLドキュメントの操作」を参照してください。

3. Service BusをサポートするようにWebLogicセキュリティ・フレームワークをまだ構成していない場合は、クライアントからプロキシ・サービスへのリクエストを保護するセキュリティ・ポリシー・アサーションが、プロキシ・サービスのいずれかの操作のWS-Policyに含まれるかどうかに応じて、次の処理(1つまたは複数)を行います。

- 操作のリクエスト・ポリシーでWS-Security X.509証明書トークンによる認証を要求する場合は、__SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__というWebサービス・セキュリティ構成を行います。「Oracle WebLogicセキュリティ・フレームワークの構成:主な手順」を参照してください。

- 操作のリクエスト・ポリシーでパスワード・ダイジェストを使用したWS-Securityユーザー名/パスワード・トークンによる認証を要求する場合は、必ずパスワード・ダイジェストを有効にします。「Oracle WebLogicセキュリティ・フレームワークの構成:主な手順」を参照してください。

- 操作のリクエスト・ポリシーでSAMLトークンの使用を要求する場合は、このプロキシ・サービスのSAMLアサーション側を構成する必要があります。「プロキシ・サービス・リクエストでのSAMLトークンの認証」を参照してください。

- 操作の要求ポリシーでデジタル署名を要求する場合は、受け入れられたクライアント署名検証証明書をWebLogic Server証明書レジストリに登録する。「Oracle WebLogicセキュリティ・フレームワークの構成:主な手順」を参照してください。

- 操作のリクエスト・ポリシーでデジタル暗号化を要求する場合は、暗号化の資格証明を持つサービス・キー・プロバイダを構成します。プロキシ・サービスはこの資格証明を使用して、暗号化されたSOAPメッセージを復号化します。サービス・キー・プロバイダの詳細は、「サービス・キー・プロバイダの操作」を参照してください。

4. Oracle Service Busコンソールで、プロキシ・サービスからクライアントへの レスポンス を保護するセキュリティ・ポリシー・アサーションが、プロキシ・サービスのいずれかの操作のWS-Policyに含まれるかどうかに応じて、次の処理(1つまたは複数)を行います。

- 操作のレスポンス・ポリシーでデジタル署名を要求する場合は、デジタル署名資格証明を持つサービス・キー・プロバイダを構成します。1つで暗号化とデジタル署名の両方の資格証明を持つサービス・キー・プロバイダを作成できます。サービス・キー・プロバイダの詳細は、「サービス・キー・プロバイダの操作」を参照してください。

- 操作のレスポンス・ポリシーで暗号化を指定する場合、クライアントはリクエスト時に証明書をプロキシ・サービスに送信する必要があります。プロキシ・サービスはクライアントの公開鍵を使用してレスポンスを暗号化します。クライアントの証明書は、プロキシ・サービスの暗号化証明書と異なる必要があります。

5. Oracle Service Busコンソールで、インポートしたWSDLファイルからプロキシ・サービスを作成します。変更をアクティブ化します。

6. プロキシ・サービスにOWSMポリシーをアタッチするには、次のいずれかの項を参照してください。

- JDeveloperでのポリシーのアタッチと構成

- Oracle Service Busコンソールでのポリシーのアタッチと構成

7. 作成したプロキシ・サービスを編集して、 「セキュリティ」 タブから次を行います。

a. 作成したサービス・キー・プロバイダを指定します。

b. (オプション)ユーザー、グループ、またはロールが保護された操作を呼び出すことができる条件を指定する、プロキシ・サービスのデフォルトのメッセージ・レベルでのアクセス制御ポリシーを変更します。詳細は、「メッセージ・レベルのアクセス・ポリシーの構成方法」を参照してください。

c. (オプション)プロキシ・サービスのメッセージ・レベルの認証設定を変更します。

50.3.2 パススルー・プロキシ・サービスの作成: 主な手順

パススルー・プロキシ・サービスを作成するには:

1. プロキシ・サービスが、処理されていないSOAPメッセージを渡すビジネス・サービスを作成します。構成の方法には、次の2通りがあります。

- ビジネス・サービスを、WS-Policy文を含むWebサービスとします。

- ビジネス・サービスで、WS-Policyを直接バインドします。サービスのベースとなるWSDLファイルには、WS-Policy文を含めないでください。

「ビジネス・サービスのメッセージ・レベルのセキュリティの構成:主な手順」を参照してください。

2. プロキシ・サービスにOWSMポリシーをアタッチするには、次のいずれかの項を参照してください。

- JDeveloperでのポリシーのアタッチと構成

- Oracle Service Busコンソールでのポリシーのアタッチと構成

3. Oracle Service Busコンソールで、WSDLドキュメントからプロキシ・サービスを作成します。作成したビジネス・サービスで使用したWSDLドキュメントと同じドキュメントを使用できます。変更をアクティブ化します。

4. プロキシ・サービスで関連付けられているセキュリティ・ポリシーを施行しない場合は、「セキュリティ」タブの「セキュリティ設定」にある「受動的なセキュリティ仲介」を選択します。

5. 作成したビジネス・サービスにルーティングするプロキシ・サービスを構成します。

クライアントのSOAPメッセージが呼出しをリクエストする操作に基づいてビジネス・サービスにルーティングする場合は、SOAP本体のアルゴリズム以外の操作選択アルゴリズムを指定するようにルーティングを構成する必要があります。プロキシ・サービス・パイプラインのアクションによって、署名または暗号化されたWS-SecurityヘッダーまたはSOAPエンベロープの部分が変更されないことを確認します。デジタル署名されたクリア・テキストのメッセージ部分を変更すると、ほとんどの場合、デジタル署名は壊れます。これは、後で署名を検証できないためです。

50.4 ビジネス・サービスのメッセージ・レベルのセキュリティの構成:主な手順

アウトバウンド・メッセージ・レベルのセキュリティは、Service Busプロキシ・サービスとSOAP-HTTPビジネス・サービス間のメッセージ、またはService Busプロキシ・サービスとSOAP-JMSビジネス・サービス間のメッセージに適用されます。また、このセキュリティはリクエストとレスポンスの両方に適用されます。

SOAP-HTTPまたはSOAP-JMS Webサービスを表すビジネス・サービスに対してアウトバウンド・メッセージ・レベルのセキュリティを構成するには:

1. テキスト・エディタまたはIDEで、ポリシーを定義するWSDLドキュメントを作成します。

2. Oracle Service Busコンソールで、WebサービスのWSDLドキュメントをService Bus WSDLリポジトリにインポートし、すべてのWSDLの依存関係を解決します。

WSDLファイルの詳細は、「WSDLドキュメントの操作」を参照してください。

3. Oracle Service Busコンソールで、プロキシ・サービスからビジネス・サービスへの リクエスト を保護するWS-Policy文がWSDLドキュメントに含まれるかどうかに応じて次の処理(1つまたは複数)を行います。

- いずれかの操作のリクエスト・ポリシーに、サポートされるトークンのタイプの1つとしてWS-Securityユーザー名トークンによるIDアサーションが含まれる場合は、ビジネス・サービスに対するサービス・アカウントを構成します。このサービス・アカウントで、プロキシ・サービスがビジネス・サービスに送信するユーザー名とパスワードを提供します。このビジネス・サービスにルーティングするプロキシ・サービスは、このサービス・アカウントからユーザー名とパスワードを取得します。「サービス・アカウントの操作」および「ビジネス・サービスの作成と構成」を参照してください。

- 操作のリクエスト・ポリシーでパスワード・ダイジェストを使用したWS-Securityユーザー名/パスワード・トークンによる認証を要求する場合は、必ずパスワード・ダイジェストを有効にします。「Oracle WebLogicセキュリティ・フレームワークの構成:主な手順」を参照してください。

- 操作のリクエスト・ポリシーでデジタル署名を要求する場合は、デジタル署名資格証明を持つサービス・キー・プロバイダを構成します。1つで暗号化とデジタル署名の両方の資格証明を持つサービス・キー・プロバイダを作成できます。サービス・キー・プロバイダの詳細は、「サービス・キー・プロバイダの操作」を参照してください。

4. ビジネス・サービスの操作の レスポンス ポリシーで暗号化を要求する場合(つまり、ビジネス・サービスが、プロキシ・サービスの暗号化公開鍵でレスポンスを暗号化します)、サービス・キー・プロバイダを構成して暗号化の資格証明をサービス・キー・プロバイダに割り当ててください。

警告:

暗号化されるバックエンドのレスポンス・メッセージ: ビジネス・サービスのレスポンス・ポリシーで暗号化を指定する場合、プロキシ・サービスはリクエスト時に暗号化証明書をビジネス・サービスに送信します。ビジネス・サービスは、プロキシ・サービスの公開鍵を使用してレスポンスを暗号化します。プロキシ・サービスの暗号化資格証明は、ビジネス・サービスの暗号化資格証明と異なることが必要です。

5. ビジネス・サービスのポリシーがSAMLアサーションの使用を指定している場合は、WebLogic SAML資格証明マッピング・プロバイダV2のアサーション側を構成します。詳細は、「IDのSAMLトークンへのマッピング」を参照してください。

6. インポートしたWSDLファイルからビジネス・サービスを作成します。変更をアクティブ化します。

「ビジネス・サービスの作成と構成」を参照してください。

7. ビジネス・サービスにOWSMポリシーをアタッチするには、次のいずれかの項を参照してください。

- JDeveloperでのポリシーのアタッチと構成

- Oracle Service Busコンソールでのポリシーのアタッチと構成

8. SOAPメッセージをビジネス・サービスにルーティングするプロキシ・サービスを作成します。アクティブな仲介プロキシ・サービスまたはパススルー・プロキシ・サービスを使用できます。

「アクティブな仲介プロキシ・サービスの作成: 主な手順」を参照してください。

50.5 サービス・アイデンティティ証明書拡張の使用方法

Service Busは、OWSMメッセージ保護ポリシーでアタッチされたWSDL SOAPプロキシおよびビジネス・サービスの証明書ID拡張の発行と消費をサポートしています。

50.5.1 プロキシ・サービスの有効なWSDLの証明書ID拡張の発行

OWSMメッセージ保護ポリシーを実装するWSDL SOAPプロキシ・サービスは、WSDLファイルでのサービス用にbase64エンコード済の公開証明書を発行します。証明書は、ポリシーによってデータが暗号化されるか復号化されるかに関係なく、メッセージ保護ポリシーに対して内包されます。

証明書はアタッチされたポリシーの暗号化キー構成に基づいています。プロキシ・サービス・クライアントは、暗号化を目的に、WSDLファイルに埋め込まれた証明書を使用できます。

詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のサービス・アイデンティティ証明書拡張の使用方法に関する項を参照してください。

注意:

OWSMの以前のリリースでは、ビジネス・サービスとプロキシ・サービスのクライアントは、プロキシ・サービスの公開証明書をドメイン・レベルのキーストアに格納する必要がありました。

その後、クライアントはkeystore.recipient.aliasプロパティを使用して、キーストア内の証明書を識別します。

50.5.2 ビジネス・サービスでの証明書ID拡張の消費方法

OWSMメッセージ保護ポリシーを実装するWSDL SOAPビジネス・サービスは、WSDLファイルからの証明書ID拡張を消費します。WSDLファイルで公開鍵証明書が見つからない場合は、keystore.recipient.aliasプロパティが使用され、証明書はビジネス・サービスのドメイン・レベルのキーストアに存在している必要があります。

ホスト名検証機能によって、WSDLファイルから取得した証明書が置換攻撃や中間者攻撃の対象になることなく、本当に予期したとおりの証明書であることが保証されます。

ホスト名を検証するため、OWSMは、証明書の共通名(CN)またはサブジェクト・グループ・ベース識別名(DN)がサービスのホスト名と一致することを確認します。この機能は、証明書のサブジェクトDNに依存します。

OWSMは、WSDLファイルでX509証明書を公開してWebサービス・ポリシーを適用するかどうか、およびホスト名検証機能を使用するかどうかを指定できるドメイン構成プロパティを提供します。これらのプロパティの設定方法の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のFusion Middleware Controlを使用したID拡張プロパティの構成に関する項を参照してください。

50.6 カスタムWS-Policy文の例

次の項では、WS-Policy仕様に基づき、Oracle独自のセキュリティ・ポリシー・スキーマを使用して記述されたカスタムWS-Policy文の例を示します。

- 例: SOAP本体およびヘッダー部分の暗号化

- 例: ビジネス・サービスの暗号化ポリシー

- 例:カスタムSOAPヘッダーの暗号化

- 例: メッセージ本体とヘッダーの署名

- 例: SAML Holder-of-KeyによるSOAP本体の署名

- 例: SAML Sender-Vouchesによる認証、署名および暗号化

50.6.1 例: SOAP本体およびヘッダー部分の暗号化

SOAPメッセージの本文全体ではなく、特定の部分を暗号化またはデジタル署名するように指定する必要がある場合は、カスタムWS-Policyファイルを作成する必要があります。

この項に示す例は、実行する抽象WS-Policy文で、次を行います。

- クライアントのメッセージに認証用のユーザー名とパスワード・トークンを要求します

- クライアントに(セキュリティ・ヘッダーにある)ユーザー名およびパスワード・トークンの暗号化を要求します。

- クライアントに/definitions/message/CreditCardNumber要素の暗号化を要求します。

このポリシーは抽象的であるため、ビジネス・サービスでは使用できません: そのKeyInfo要素には、暗号化用の証明書が含まれません。かわりに、このWS-Policy文を使用するプロキシ・サービスをアクティブ化すると、Service Busは、プロキシ・サービスと関連付けられたサービス・キー・プロバイダからの暗号化証明書をWS-Policy文にバインドします。詳細は、「サービス・キー・プロバイダの操作」を参照してください。

図50-1 抽象ポリシーへの証明書のバインディング

また、例では、

- KeyWrappingAlgorithm要素で、対称キーをラップするRSA 1.5アルゴリズムをクライアントが使用する必要があることを指定します。

- EncryptionAlgorithmで、クライアントがTriple DES (Data Encryption Standard)アルゴリズムを使用してセキュリティ・ヘッダーとメッセージ本体の暗号化を実行する必要があることを指定します。

例 - SOAP本体およびヘッダー部分の暗号化

<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd"
xmlns:m="http://example.org"
wsu:Id="encrypt-custom-body-element-and-username-token">
<!-- Require messages to provide a user name and password token
for authentication -->
<wssp:Identity>
<wssp:SupportedTokens>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-username-token-profile-1.0#UsernameToken">
<wssp:UsePassword Type="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-username-token-profile-1.0#PasswordText"/>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Identity>
<wssp:Confidentiality>
<wssp:KeyWrappingAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<!-- Require the user name and password in the security header
to be encrypted -->
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(wsse:UsernameToken)
</wssp:MessageParts>
</wssp:Target>
<!-- Require the /definitions/message/CreditCardNumber element to
be encrypted -->
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts>
wsp:GetBody(.)/m:CreditCardNumber
</wssp:MessageParts>
</wssp:Target>
<!-- This is an abstract policy because the KeyInfo element is
empty. The KeyInfo data is bound to the policy at runtime -->
<wssp:KeyInfo/>
</wssp:Confidentiality>
</wsp:Policy>

50.6.2 例:ビジネス・サービスの暗号化ポリシー

通常、ビジネス・サービスへのメッセージを送信するプロキシ・サービスがパススルー・プロキシ・サービスである場合は、ビジネス・サービスへのメッセージを暗号化する必要があります。つまり、クライアントからメッセージを受信するプロキシ・サービスは、SOAPメッセージを処理しません。かわりに、プロキシ・サービスはメッセージをビジネス・サービスにルーティングし、ビジネス・サービスがWebサービス・セキュリティを確保します。「Webサービスのメッセージ・レベルでのセキュリティの構成」を参照してください。

この項の例は、具象ポリシーを含むWSDLドキュメントです。この例では、次に注意してください。

- ポリシーによって、メッセージ本体の暗号化をクライアントに要求します。

- クライアントが提供するトークンのタイプを指定するKeyInfo要素は、暗号化証明書を記述して埋め込むために使用する親要素です。BinarySecurityToken要素には、base-64エンコード形式の暗号化証明書が含まれます(例では、値は切り捨てられています)。証明書がPEM形式の場合、PEMファイル(PEM接頭辞と接尾辞なし)の内容はbase-64エンコード形式で表される証明書です。暗号化証明書がJDKキーストアに格納されている場合は、簡単にPEMファイルにエクスポートできます。

- ポリシーによって一意のIDが提供され、WSDLファイルはURIフラグメントを使用してそのIDを参照します。

例 - WSDLドキュメントに埋め込まれた具象ポリシーによる本体の暗号化

<definitions name="WssServiceDefinitions"
targetNamespace="http://com.bea.alsb/tests/wss"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
...>
<wsp:UsingPolicy xmlns:n1="http://schemas.xmlsoap.org/wsdl/"
n1:Required="true"/>
<!-- The policy provides a unique ID -->
<wsp:Policy wsu:Id="myEncrypt.xml">
<wssp:Confidentiality
xmlns:wssp="http://www.bea.com/wls90/security/policy">
<wssp:KeyWrappingAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<!-- Require the user name and password in the security header
to be encrypted -->
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<!-- Embed the token type and encryption certificate -->
<wssp:KeyInfo>
<wssp:SecurityToken
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-x509-token-profile-1.0#X509v3"/>
<wssp:SecurityTokenReference>
<wssp:Embedded>
<wsse:BinarySecurityToken
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-x509-token-profile-1.0#X509v3"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-wssecurity-secext-1.0.xsd">
MIICfjCCAeegAwIBAgIQV/PDyj3...
</wsse:BinarySecurityToken>
</wssp:Embedded>
</wssp:SecurityTokenReference>
</wssp:KeyInfo>
</wssp:Confidentiality>
</wsp:Policy>
<binding name="WssServiceSoapBinding" type="tns:WssService">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getPurchaseOrder">
<soap:operation soapAction="" style="document"/>
<input>
<soap:body parts="parameters" use="literal"/>
<!-- Use a URI fragment to refer to the unique policy ID -->
<wsp:Policy>
<wsp:PolicyReference URI="#myEncrypt.xml"/>
</wsp:Policy>
</input>
<output>
<soap:body parts="parameters" use="literal"/>
</output>
</operation>
</binding>
...
</definitions>

50.6.3 例:カスタムSOAPヘッダーの暗号化

この項の例は、CreditCardNumberというカスタム・ヘッダーを暗号化する抽象WS-Policy文です。

SOAPメッセージの本文全体ではなく、特定の部分を暗号化またはデジタル署名するように指定する必要がある場合は、カスタムWS-Policyファイルを作成する必要があります。

このポリシーは抽象的であるため、ビジネス・サービスでは使用できません: そのKeyInfo要素には、暗号化用の証明書が含まれません。かわりに、このWS-Policy文を使用するプロキシ・サービスをアクティブ化すると、Service Busは、プロキシ・サービスと関連付けられたサービス・キー・プロバイダからの暗号化証明書をWS-Policy文にバインドします。詳細は、「サービス・キー・プロバイダの操作」を参照してください。

また、この例のノートでは、

- KeyWrappingAlgorithm要素で、対称キーをラップするRSA 1.5アルゴリズムをクライアントが使用する必要があることを指定します。

- EncryptionAlgorithmで、クライアントがTriple DES (Data Encryption Standard)アルゴリズムを使用してセキュリティ・ヘッダーの暗号化を実行する必要があることを指定します。

例 - カスタムSOAPヘッダーの暗号化

<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
wsu:Id="dig-sig-for-get-header">
<wssp:Confidentiality>
<wssp:KeyWrappingAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<!-- Require the custom CreditCardNumber header to be encrypted -->
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
wsp:GetHeader(.)/n:CreditCardNumber
</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo/>
</wssp:Confidentiality>
</wsp:Policy>

50.6.4 例:メッセージ本体とヘッダーの署名

この項の例は、SOAPメッセージの次の内容へのアクセスにデジタル署名を要求するWS-Policy文です。

- header1というカスタム・ヘッダー

- すべてのシステム・ヘッダー

- タイム・スタンプ・セキュリティ・ヘッダー

- メッセージ本文

例 - SOAPヘッダーと本体の署名の要求

<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
wsu:Id="sign-custom-header-policy">
<wssp:Integrity>
<wssp:SignatureAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm
URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<!-- Require the custom header header1 to be signed -->
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd"
xmlns:n="http://example.org">
wsp:GetHeader(.)/n:header1
</wssp:MessageParts>
</wssp:Target>
<!-- Require the system headers to be signed -->
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SystemHeaders()
</wssp:MessageParts>
</wssp:Target>
<!-- Require the Timestamp header to be signed -->
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(wsu:Timestamp)
</wssp:MessageParts>
</wssp:Target>
<!-- Require the message body to be signed -->
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
</wssp:Integrity>
<wssp:MessageAge/>
</wsp:Policy>

50.6.5 例: SAML Holder-of-KeyによるSOAP本体の署名

この項の例は、holder-of-keyメソッドを使用してメッセージ本体に署名するようSAMLアサーション・プロバイダに要求するWS-Policy文です。「holder-of-key」サブジェクト確認が指定されたSAMLトークンは、リクエスト・メッセージの整合性を確保するために、受信側で信頼されていない可能性のあるX.509証明書をサブジェクトで使用できるようにすることを目的としたものです。

2つのSAML確認メソッド(sender-vouchesまたはholder-of-key)の詳細は、『Oracle WebLogic Serverセキュリティの理解』のWebLogic WebサービスでのSAMLトークン・プロファイルのサポートに関する項を参照してください。

Oracle WebLogic Server Webサービス・リファレンスのOracle WebLogic Serverセキュリティ・ポリシー・アサーションのリファレンスで、ポリシーの要素について詳しく説明しています。

この例では、次に注意してください。

- Integrityは、SOAPメッセージの署名に使用するアルゴリズムやキーに加え、SOAPメッセージの一部または全体にデジタル署名することを指定します。

- SignatureAlgorithmは、デジタル署名の計算に使用する暗号アルゴリズムを指定します。

- CanonicalizationAlgorithmは、デジタル署名するSOAPメッセージの要素を標準化する(単純なまたは標準の形式で使用する)ために使用するアルゴリズムを指定します。指定できるのは、http://www.w3.org/2001/10/xml-exc-cl4n#のみです。

- DigestAlgorithmは、SOAPメッセージの指定部分にデジタル署名する際に使用するダイジェスト・アルゴリズムを指定します。指定できるのは、http://www.w3.org/2000/09/xmldsig#sha1のみです。

- MessagePartsは、署名されるべきSOAPメッセージの部分を指定します。この場合は本体です。

- Dialectは、署名されるべきSOAPメッセージの部分の識別に使用される固有言語を指定します。

- SupportedTokensは、デジタル署名で使用できる、サポートされているセキュリティ・トークンのリストを指定します。

- SecurityTokenは、デジタル署名でサポートされているセキュリティ・トークンを指定します。
IncludeInMessageは、SOAPメッセージにトークンを含めるかどうかを指定します。有効な値はtrueまたはfalseです。<Integrity>アサーションで使用される場合、この属性のデフォルト値はtrueです。

TokenTypeは、セキュリティ・トークンのタイプを指定します。この場合、SAMLトークンを指定します。

- Claimsは、特定のタイプのセキュリティ・トークンに関連付けられる追加メタデータ情報を指定します。SAMLトークンの場合、<ConfirmationMethod>子要素を定義して、SAML確認のタイプ(sender-vouchesまたはholder-of-key)を指定する必要があります。

- ConfirmationMethodは、IDにSAMLトークンを使用する場合に使う確認メソッドのタイプ(sender-vouchesまたはholder-of-key)を指定します。
<Integrity>アサーション内の<ConfirmationMethod>アサーションを指定します。この確認メソッドのための<Integrity>アサーションにSAMLトークンを含める理由は、Webサービス・ランタイムで、sender-vouchesでは必要ないメッセージの整合性の証明が必要になるためです。

例 - SAML Holder-of-KeyメソッドによるSOAP本体の署名

<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
wsu:Id="saml-holder-of-key-signed">
<wssp:Integrity>
<wssp:SignatureAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm
URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:SupportedTokens>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-
token-profile-1.0#SAMLAssertionID">
<wssp:Claims>
<wssp:ConfirmationMethod>holder-of-key</wssp:ConfirmationMethod>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Integrity>
</wsp:Policy>

50.6.6 例: SAML Sender-Vouchesによる認証、署名および暗号化

この項の例は、sender-vouchesメソッドを使用してメッセージ本体およびヘッダーに署名するようSAMLアサーション・プロバイダに要求するWS-Policy文です。

sender-vouchesでは、(サブジェクトとは異なる)アサーション側がサブジェクトの検証を保証します。受信側がアサーション側との信頼関係を確立している必要があります。

2つのSAML確認メソッド(sender-vouchesまたはholder-of-key)の詳細は、『Oracle WebLogic Serverセキュリティの理解』のWebLogic WebサービスでのSAMLトークン・プロファイルのサポートに関する項を参照してください。

Oracle WebLogic Server WebLogic Webサービス・リファレンスのOracle WebLogic Serverセキュリティ・ポリシー・アサーションのリファレンスで、ポリシーの要素について詳しく説明しています。

この例では、次に注意してください。

- Identityは、セキュリティ・トークンのタイプを指定します。

- SupportedTokensは、デジタル署名で使用できる、サポートされているセキュリティ・トークンのリストを指定します。

- SecurityTokenは、デジタル署名でサポートされているセキュリティ・トークンを指定します。
IncludeInMessageは、この属性の値が常にtrueであるため、<Identity>アサーションに使用された場合、明示的にfalseに設定されても、指定されません。

TokenTypeは、SAMLトークンを指定するためにセキュリティ・トークンのタイプを指定します。

- Claimsは、特定のタイプのセキュリティ・トークンに関連付けられる追加メタデータ情報を指定します。SAMLトークンの場合、<ConfirmationMethod>子要素を定義して、SAML確認のタイプ(sender-vouchesまたはholder-of-key)を指定する必要があります。

- ConfirmationMethodは、IDにSAMLトークンを使用する場合に使う確認メソッドのタイプ(sender-vouchesまたはholder-of-key)を指定します。

- Integrityは、SOAPメッセージの署名に使用するアルゴリズムやキーに加え、SOAPメッセージの一部または全体にデジタル署名することを指定します(この例の場合は、本体とセキュリティ・ヘッダーの両方)。

- SignatureAlgorithmは、デジタル署名の計算に使用する暗号アルゴリズムを指定します。

- CanonicalizationAlgorithmは、デジタル署名するSOAPメッセージの要素を標準化する(単純なまたは標準の形式で使用する)ために使用するアルゴリズムを指定します。指定できるのは、http://www.w3.org/2001/10/xml-exc-cl4n#のみです。

- Targetは、親要素によって異なる、暗号化または署名するSOAPメッセージの対象に関する情報をカプセル化します。子要素も、親要素によって異なります。

- <Integrity>で使用される場合、<DigestAlgorithm>、<Transform>、<MessageParts>の子要素を指定できます。

- <Confidentiality>で使用する場合は、<EncryptionAlgorithm>、<Transform>、および<MessageParts>子要素を指定できます。

- DigestAlgorithmは、SOAPメッセージの指定部分にデジタル署名する際に使用するダイジェスト・アルゴリズムを指定します。指定できるのは、http://www.w3.org/2000/09/xmldsig#sha1のみです。

- MessagePartsは、署名されるべきSOAPメッセージの部分を指定します。この場合は本体およびセキュリティ・ヘッダーです。

- Dialectは、署名されるべきSOAPメッセージの部分の識別に使用される固有言語を指定します。

- Confidentialityは、SOAPメッセージの暗号化に使用するアルゴリズムやキーに加え、SOAPメッセージの一部または全部を暗号化することを指定します。この例では、triple-DESを使用して、本体およびセキュリティ・ヘッダーを暗号化する必要があります。

例 - SAML Sender-VouchesメソッドによるSOAP本体とヘッダーの署名

<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
wsu:Id="samlPolicy-sender-vouches-signed-encrypted">
<wssp:Identity>
<wssp:SupportedTokens>
<wssp:SecurityToken
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-
saml-token-profile-1.0#SAMLAssertionID">
<wssp:Claims>
<wssp:ConfirmationMethod>
sender-vouches
</wssp:ConfirmationMethod>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Identity>
<wssp:Integrity>
<wssp:SignatureAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm
URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(Assertion)
</wssp:MessageParts>
</wssp:Target>
</wssp:Integrity>
<wssp:Confidentiality>
<wssp:KeyWrappingAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(Assertion)
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo/>
</wssp:Confidentiality>
</wsp:Policy>

50.7 アウトバウンドWS-Securityの無効化

注意:

Oracle Web Services Managerのサービス・ポリシーを含む他のプロキシ(ローカル・プロキシなど)に転送されるプロキシ・サービスでは、アウトバウンドWS-Security処理が無効化されます。Service Busでは、この動作が自動的に行われ、doOutboundWssプロパティは使用されません。詳細は、「ローカル・プロキシ・サービスでのOWSMセキュリティの使用」を参照してください。

この項の残り部分では、他の設計パターンでアウトバウンドWS-Security処理を無効にする方法について説明します。

使用頻度の少ない設計パターンには、プロキシ・サービスによるアウトバウンドWS-Security SOAPエンベロープの自動生成が回避され、XQuery式を使用してエンベロープを作成できるものがあります。この設計パターンを使用する場合、プロキシ・サービスによるアウトバウンドWS-Security SOAPエンベロープの自動生成を回避するには、$outboundメッセージ・コンテキスト変数の./ctx:security/ctx:doOutboundWss要素の値をxs:boolean("false")に設定するアクションをプロキシ・サービスのメッセージ・フローに作成する必要があります。このアクションは、次のいずれかの場所で作成できます。

- パイプライン・ペアのリクエスト段階。「パイプラインへのパイプライン・ペアの追加方法」を参照してください。

- ルート・ノードのリクエスト・アクション内。「コンソールでパイプラインにルート・ノードを追加する方法」を参照してください。

$outboundメッセージ・コンテキスト変数の詳細は、「メッセージ・コンテキスト」を参照してください。

状況によっては、アウトバウンド・メッセージ・レベルのセキュリティを無効にしてプロキシ・サービスを作成または変更したセッションをアクティブ化しようとすると、Oracle Service Busコンソールに検証エラーが表示されます(エラーのあるセッションはコミットできません)。アウトバウンド・メッセージ・レベルのセキュリティを無効にしているためにセッションの検証エラーが表示される場合は、Service Busの起動コマンドを変更して、次のシステム・プロパティをtrueに設定します: com.bea.wli.sb.security.wss.LaxOutboundWssValidation

次に、Service Busを再起動します。このプロパティをtrueに設定すると、Oracle Service Busコンソールにはエラーではなく警告が表示されます(警告メッセージが表示されるセッションはコミットできます)。

Service Busの今後のリリースで、アウトバウンド・メッセージ・レベルのセキュリティの無効化を容易にする方法が提供される予定です。

51 トランスポート・レベルのセキュリティの構成

この章では、Service Busの様々なトランスポートに対して、トランスポート・レベルのセキュリティを構成する方法について説明します。

トランスポート・レベルのセキュリティは、サービス・コンシューマとプロキシ・サービス、ビジネス・サービス間の接続を確立する一環として、セキュリティ・チェックを適用します。Service Busが適用するセキュリティ・チェックのタイプは、プロキシ・サービスやビジネス・サービスが通信で使用するプロトコルによって異なります。プロトコルによっては、クライアントとエンドポイント間の通信を暗号化して、第三者による傍受を防止することもできます。

インバウンド・トランスポート・レベルのセキュリティは、クライアントとService Busプロキシ・サービス間の通信を保護します。アウトバウンド・トランスポート・セキュリティは、Service Busプロキシ・サービスからアウトバウンド・リクエストを送信する3つすべてのテクニック(ルート・アクション、パブリッシュ・アクション、コールアウト・アクション)を保護します。

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

- HTTPSのトランスポート・レベルでのセキュリティの構成

- HTTPのトランスポート・レベルでのセキュリティの構成

- JMSのトランスポート・レベルでのセキュリティの構成

- SFTPトランスポートのトランスポート・レベルでのセキュリティの構成

- 電子メール、FTP、およびファイル・トランスポート・レベルのセキュリティ

- SBトランスポートのトランスポート・レベルでのセキュリティの構成

- WSトランスポートのトランスポート・レベルでのセキュリティの構成

- WebSphereメッセージ・キュー・トランスポートのトランスポート・レベルでのセキュリティの構成

- メッセージ・コンテキストでのトランスポート・レベルのセキュリティ要素

ビジネス・サービスおよびプロキシ・サービスでセキュリティを構成する手順については、「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。

51.1 HTTPSのトランスポート・レベルでのセキュリティの構成

HTTPSプロトコルは、通信を保護するためにSSLを使用します。SSLを使用して通信を暗号化し、メッセージの整合性を保証するとともに、強力なサーバーおよびクライアントの認証を要求することができます。HTTPSを使用する前に、WebLogic ServerでSSLを構成する必要があります。「Oracle WebLogicセキュリティ・フレームワークの構成: 主な手順」を参照してください。

次の項で、HTTPSプロトコルのトランスポート・レベルのセキュリティの構成について説明します。

- HTTPSの認証レベル

- インバウンドHTTPSセキュリティの構成:主な手順

- アウトバウンドHTTPSセキュリティの構成:主な手順

51.1.1 HTTPSの認証レベル

HTTPSプロトコルを介して通信する各プロキシ・サービスやビジネス・サービスについて、次のレベルの認証のいずれかを要求するようにサービスを構成できます。

- 一方向SSL、認証なし
このレベルでは、暗号化された通信が可能ですが、クライアントに資格証明を要求しません。一方向のSSL接続を確立するには、クライアントが接続を開始して、Service Busがその証明書をクライアントに送信します。つまり、クライアントがService Busを認証します。

- 一方向SSL、基本認証
このレベルでは暗号化された通信が可能で、一方向SSL通信が確立された後にクライアントはユーザー名とパスワードを提供する必要があります。クライアントは、ユーザー名とパスワードをHTTPリクエスト・ヘッダー(SSLで暗号化されます)にエンコードして提供します。プロキシ・サービスは暗号化されたリクエストを受信すると、資格証明をドメインの認証プロバイダに引き渡し、認証プロバイダがクライアントの資格証明が作成されたユーザー・アカウントに一致するかどうかを判断します。

- 双方向SSL、クライアント証明書認証
このレベルでは暗号化された通信が可能で、強力なクライアント認証(二方向SSL)が行われます。

双方向のSSL接続を確立するには、クライアントが接続を開始してService BusがそのX.509証明書をクライアントに送信します。続いて、クライアントは自身の証明書をService Busに送信し、Service Busがクライアントを認証します。

クライアントの証明書からユーザー名を取得するには、IDアサーション・プロバイダを構成し、そのプロバイダが証明書のフィールドを抽出してクライアントのID (X.509トークン)として使用します。通常は証明書のSubjectDistinguishedNameのCN(共通名)またはE(電子メール)です。X.509トークンを抽出した後、そのトークンをFusion Middleware Controlで作成されたユーザー・アカウントと比較します。

SSLおよびIDアサーション・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティの理解』のセキュリティの基礎概念に関する項を参照してください。

- トランスポート・レベルのカスタム資格証明。
カスタム認証トークンを使用して、トランスポート・レベルでクライアントのリクエストを認証できます。カスタム・トークンは、HTTPヘッダーで指定します。サービス定義ウィザードのHTTPに固有な構成ページを使用すると、クライアントの認証を構成できます。カスタム認証の概念については、「カスタム認証の構成」で説明しています。

51.1.2 インバウンドHTTPSセキュリティの構成:主な手順

プロキシ・サービスのインバウンド・トランスポート・レベルのセキュリティを構成するには:

1. 使用するHTTPS認証レベルに応じて、SSLおよび認証プロバイダ、IDアサーション・プロバイダをサポートするWebLogicのセキュリティ・フレームワークを構成したことを確認してください。

- クライアント認証をなしにする場合(匿名リクエスト)、「クライアント認証」を「なし」に設定します。

- 基本認証については、「クライアント認証」を「基本」に設定します。『Oracle Service Busの管理』のOracle Service Busユーザーの作成に関する項を参照してください。

- SSLクライアント認証の場合、「クライアント認証」を「クライアント証明書」に設定し、WebLogic IDアサーション・プロバイダとWebLogic証明書パス・プロバイダを構成します。

- カスタムの認証トークンの場合、「クライアント認証」を「カスタム認証」に設定します。カスタムの認証トークンは、HTTPSヘッダーで送信される、IDアサーション・プロバイダに以前に構成された任意のアクティブなトークンを使用できます。カスタム認証の概念については、「カスタム認証の構成」で説明しています。

注意:

最初に、「カスタム・トークン用IDアサーション・プロバイダの構成」の説明に従って、WebLogic ServerのIDアサーション・プロバイダを構成、または作成して構成し、Fusion Middleware Controlへのアクセスを許可するクライアントのユーザー名とパスワードを追加する必要があります。

「Oracle WebLogicセキュリティ・フレームワークの構成:主な手順」を参照してください。

2. プロキシ・サービスを作成するときは、「トランスポート構成」ページで、「HTTP」を選択します。

3. HTTPトランスポート構成ページで、「HTTPSが必要」オプションを選択します。

4. 「HTTPSの認証レベル」の説明に従って、認証レベルを選択します。

5. Service Busのオンライン・ヘルプに説明されているように、「ディスパッチ・ポリシー」、「リクエストのエンコーディング」、「レスポンスのエンコーディング」の選択を行います。

6. 作成するサービスがWSDLベースで操作がある場合、「メッセージ処理構成」ページで選択を行います。WS-I準拠を実行して(SOAP 1.1サービスのみ)、使用する選択アルゴリズムを選び、このプロキシ・サービスが呼び出す操作を決定します。このオプションは、WSDLファイルから定義されたSOAPサービスまたはXMLサービスでのみ使用できます。

51.1.3 アウトバウンドHTTPSセキュリティの構成:主な手順

アウトバウンド・トランスポート・レベル・セキュリティでは、ビジネス・サービスとの接続を開くクライアントはプロキシ・サービスです。

アウトバウンド・トランスポート・レベル・セキュリティを構成するには:

1. (開発やテスト環境とは対照的に)本番環境でトランスポート・レベルのセキュリティを構成する場合、「ホスト名検証」が有効になっているか確認します。『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項のホスト名の使用方法を参照してください。

2. ビジネス・サービスを作成するときは、トランスポート構成ページで、「HTTP」を選択します。

3. 「HTTPSの認証レベル」の説明に従って、認証レベルを選択します。
Service Busがクライアントを認証しないようにプロキシ・サービスを構成した場合、エンタープライズ・システムを構成し、一方向SSLの認証レベル(基本認証オプション)を選択することによりクライアントを認証してください。

4. URIにより、HTTPとHTTPSのどちらを使用するかが決まります。HTTPビジネス・サービスは、HTTPとHTTPSのURLを組み合せることができます。ただし、認証方法がクライアント証明書の場合を除きます。この場合は、すべてのURLをHTTPSにする必要があります。

5. ビジネス・サービスが基本認証のHTTPSを使用する場合は、サービス・アカウントを作成して、ビジネス・サービスで要求するユーザー名とパスワードを指定します。
ユーザー名とパスワードを直接サービス・アカウントに追加するか、クライアントのリクエストから受け取った資格証明をサービス・アカウントがパススルーするように構成するか、またはクライアント・ユーザー名をService Busユーザーにマップできます。Service Busがクライアントを認証しないようにサービスを構成した場合は、資格証明をパススルーするサービス・アカウントを作成します。

6. ビジネス・サービスでクライアント証明書認証を使用する場合、次を実行します。

a. サービス・キー・プロバイダを作成して、プロキシ・サービスがビジネス・サービスのSSLクライアント認証に使用するキー・ペアを指定します。サービス・キー・プロバイダの詳細は、「サービス・キー・プロバイダの操作」を参照してください。

b. プロキシ・サービスを作成するか、既存のプロキシ・サービスを編集して、サービス・キー・プロバイダを指定します。

7. ビジネス・サービスでカスタム認証を使用する場合、認証のカスタムJavaクラスを指定します。

51.2 HTTPのトランスポート・レベルでのセキュリティの構成

HTTPプロトコルは、クライアントとプロキシ・サービスまたはビジネス・サービス間の通信を暗号化しませんが、基本認証はサポートしています。基本認証では、クライアントがユーザー名とパスワードをリクエスト内で送信します。また、HTTPはカスタム・トークン認証をサポートしています。

警告:

パスワードがクリア・テキストで送信されるため、強力なネットワーク・セキュリティを構成していないかぎり、本番環境では基本認証とHTTPを一緒に使用しないようお薦めします。かわりに、基本認証とHTTPSを併用してください。

次の項で、HTTPプロトコルのトランスポート・レベルのセキュリティの構成について説明します。

- インバウンドHTTPセキュリティの構成:主な手順

- アウトバウンドHTTPセキュリティの構成:主な手順

- アウトバウンドHTTPセキュリティのカスタム認証の使用

51.2.1 インバウンドHTTPセキュリティの構成:主な手順

プロキシ・サービスのインバウンド・トランスポート・レベルのセキュリティを構成するには:

1. プロキシ・サービスを作成するときは、「トランスポート構成」ページで、「HTTP」を選択します。「クライアント認証」オプションでは、「なし」、「基本」または「カスタム認証」を選択します。カスタム認証を選択すると、トークンを送信するHTTPヘッダーとトークンのタイプも指定する必要があります。

トランスポート・レベルのカスタム資格証明を構成する手順の説明は、「Oracle Service Busでのメッセージ・フローの作成」にあります。カスタム認証の概念については、「カスタム認証の構成」で説明しています。

カスタム認証のトークンには、任意のアクティブなトークン・タイプで、以前にIDアサーション・プロバイダ用に構成され、HTTPヘッダーで送信されたものを使用できます。

注意:

カスタム認証を使用するには、「カスタム・トークン用IDアサーション・プロバイダの構成」の説明に従って、最初にWebLogic Server IDアサーション・プロバイダを構成、あるいは作成してから構成する必要があります。

Service Busでクライアントを認証(基本またはカスタム認証)する場合、クライアントのユーザー・アカウントを作成する必要があります。『Oracle Service Busの管理』のOracle Service Bus管理セキュリティの構成に関する項を参照してください。

2. プロキシ・サービスのデフォルトのトランスポート・レベルでのアクセス制御ポリシーを変更します。このポリシーにより、ユーザーやグループ、ロールがプロキシ・サービスにアクセスできる条件を指定します。「トランスポート・レベルのアクセス・ポリシーの構成方法」を参照してください。

51.2.2 アウトバウンドHTTPセキュリティの構成:主な手順

アウトバウンド・トランスポート・レベル・セキュリティでは、ビジネス・サービスとの接続を開くクライアントはプロキシ・サービスです。

アウトバウンド・トランスポート・レベル・セキュリティを構成するには:

1. ビジネス・サービスを作成するときは、「トランスポート構成」ページで、「HTTP」を選択します。「クライアント認証」オプションでは、「なし」、「基本」または「カスタム認証」を選択します。カスタム認証を選択すると、トークンを送信するHTTPヘッダーとトークンのタイプも指定する必要があります。

カスタム認証の概念については、「カスタム認証の構成」で説明しています。

2. 基本セキュリティを選択した場合は、ビジネス・サービスで必要とされるユーザー名とパスワードを提供するためのサービス・アカウントを作成します。これは、カスタム認証のオプションです。「サービス・アカウントの操作」を参照してください。

カスタム認証のトークンには、任意のアクティブなトークン・タイプで、以前にIDアサーション・プロバイダ用に構成され、HTTPヘッダーで送信されたものを使用できます。

注意:

アウトバウンド・セキュリティのカスタム認証を使用するには、OutboundAuthenticationインタフェースのdoOutboundAuthenticationメソッドを実装する必要があります。詳細は、「アウトバウンドHTTPセキュリティのカスタム認証の使用」を参照してください。

Service Busでクライアントを認証(基本またはカスタム認証)する場合、クライアントのユーザー・アカウントを作成する必要があります。『Oracle Service Busの管理』のOracle Service Bus管理セキュリティの構成に関する項を参照してください。

ユーザー名とパスワードを直接サービス・アカウントに追加するか、クライアントのリクエストから受け取った資格証明をサービス・アカウントがパススルーするように構成するか、またはクライアント・ユーザー名をService Busユーザーにマップできます。Service Busがクライアントを認証しないようにサービスを構成した場合は、資格証明をパススルーするサービス・アカウントを作成します。

3. プロキシ・サービスを作成するか、既存のプロキシ・サービスを編集して、サービス・アカウントを指定します。

51.2.3 アウトバウンドHTTPセキュリティのカスタム認証の使用

アウトバウンドでカスタム認証を使用するには、com.bea.wli.sb.transports.http.OutboundAuthenticationインタフェースのdoOutboundAuthenticationメソッドを実装する必要があります。Oracle Service Busice Busでは、OutboundAuthentication実装を呼び出す前に、HttpUrlConnectionFactoryを接続パラメータで初期化します。

カスタム認証コードでは、HttpURLConnectionの新しいインスタンスの取得にファクトリ・メソッドHttpUrlConnectionFactory.newConnection()を使用できます。ファクトリ・メソッドから返されるHttpURLConnectionインスタンスは、Service Busランタイムで設定されるパラメータで構成されます。

認証プロセスの最後の手順で、ビジネス・サービスのペイロードとユーザー・ヘッダーを、認証パラメータとともにターゲット・サービスに送信する必要があります。Service Busは、これを自動的に処理します。そのため、カスタム・オーセンティケータでは、カスタム認証コードで作成される最後のHttp接続インスタンスに認証パラメータのみが設定されていることを確認する必要があります。ターゲット・サービスへの接続を確立する次のHttpURLConnectionメソッドは、カスタム認証コードで作成されるHttpURLConnectionの最後のインスタンスに対して呼び出さないでください。

- connect

- getResponseCode

- getResponseMessage

- getHeaderメソッド

- getContent

- getInputStream

- getOutputStream

51.3 JMSのトランスポート・レベルでのセキュリティの構成

JMSのトランスポート・レベルのセキュリティは、JMSメッセージングに対してエンド・ツー・エンドのセキュリティを提供しませんが、次のものは提供されます。

- Service BusとJMSサーバー間でJMSメッセージを送受信するための、保護されたSSLチャネルを使用するオプション。

注意:

JMSトランスポートでは、双方向SSLはサポートされません。

Service Busは、ローカルのJMSサーバーや外部のJMSサーバーと通信できます。JMSサーバーへの接続は、T3Sプロトコル(SSLを介したT3)によって保護されます。T3とT3Sは、Oracle独自のプロトコルです。

- JMSサーバーとの接続を確立し、JNDIツリー内のJMS宛先をルックアップする際に、Service Busプロキシ・サービスが認証に使用するユーザー名とパスワードを指定する機能。

注意:

JMS管理者は、Oracle WebLogic Server管理コンソールを使用して、WebLogic JMSサーバーおよびJNDIツリー内の宛先へのアクセスを制限するアクセス制御ポリシーを作成します。詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のポリシーで保護できるリソース・タイプに関する項と『Oracle WebLogic Server JMSリソースの管理』のJMSシステム・リソースを構成するためのメソッドに関する項を参照してください。

JMS管理者がJMS宛先のアクセス制御ポリシーを構成または変更する場合、WebLogic Serverが変更を認識するまで最大60秒かかります。

デフォルトでは、WebLogic Server JMSは60秒ごとに各JMS宛先のポリシーを確認します。この動作を変更するには、WebLogic Serverの起動コマンドを変更して、システム・プロパティweblogic.jms.securityCheckIntervalを、WebLogic Server JMSによるアクセス制御ポリシーの確認頻度(秒単位)に設定してください。

このプロパティの値を0(ゼロ)にすると、認可の確認がJMSリソースに対するsend、receive、getEnumerationアクションのたびに行われます。

次の項で、JMSトランスポート・レベルのセキュリティの構成について説明します。

- インバウンドJMSトランスポート・レベル・セキュリティの構成:主な手順

- アウトバウンドJMSトランスポート・レベル・セキュリティの構成:主な手順

51.3.1 インバウンドJMSトランスポート・レベル・セキュリティの構成:主な手順

インバウンドJMSトランスポート・レベル・セキュリティを構成するには:

1. JMSプロキシ・サービスを作成または編集するときは、トランスポート構成ページの「詳細設定」の下で、「SSLを使用」チェック・ボックスを選択します。
Service Busは、T3Sプロトコルを使用するためにJMSプロキシ・サービスを構成します。

2. JMS管理者がJMS接続プールへのアクセスを制限するアクセス制御ポリシーを作成した場合、JMSサーバーへの接続時に認証するようプロキシ・サービスを構成してください。

a. サービス・アカウントを作成して、JMSサーバーで要求するユーザー名とパスワードを指定します。「サービス・アカウントの操作」を参照してください。
プロキシ・サービスのJMSサービス・アカウントは、JMSオブジェクトのアクセスだけでなく、JNDIのルックアップにも使用されます。

サービス・アカウントにユーザー名とパスワードを直接追加する必要があります。JMSは、クライアントのリクエストから受信した資格証明をパススルーしたり、クライアントのユーザー名をService Busユーザーにマップしたりするサービス・アカウントを使用できません。

b. プロキシ・サービスを作成または編集する場合、JMSトランスポート・ページで、「JMSサービス・アカウント」の横にある「参照」ボタンをクリックします。前述の手順で作成したサービス・アカウントを選択します。

51.3.2 アウトバウンドJMSトランスポート・レベル・セキュリティの構成:主な手順

アウトバウンドJMSトランスポート・レベル・セキュリティを構成するには:

1. JMSビジネス・サービスを作成または編集する場合、「トランスポート構成」ページの「詳細設定」の下で、「SSLを使用」チェック・ボックスを選択します。
Service Busは、T3Sプロトコルを使用するためにJMSビジネス・サービスを構成します。

2. JMS管理者がJMS接続プールへのアクセスを制限するアクセス制御ポリシーを作成した場合、JMSサーバーへの接続時に認証するようビジネス・サービスを構成してください。

a. サービス・アカウントを作成して、JMSサーバーで要求するユーザー名とパスワードを指定します。「サービス・アカウントの操作」を参照してください。
プロキシ・サービスのJMSサービス・アカウントは、JMSオブジェクトのアクセスだけでなく、JNDIのルックアップにも使用されます。

サービス・アカウントにユーザー名とパスワードを直接追加する必要があります。JMSは、クライアントのリクエストから受信した資格証明をパススルーしたり、クライアントのユーザー名をService Busユーザーにマップしたりするサービス・アカウントを使用できません。

b. ビジネス・サービスを作成または編集する場合、JMSトランスポート・ページで、「JMSサービス・アカウント」の横にある「参照」ボタンをクリックします。前述の手順で作成したビジネス・アカウントを選択します。

3. メッセージを送信するときにService Busで認証されたサブジェクトを渡すには、「呼出し元のサブジェクトを渡す」チェック・ボックスを選択します。

51.4 SFTPトランスポートのトランスポート・レベルでのセキュリティの構成

「SFTPトランスポートの使用」の説明にあるように、Service Busはインバウンドおよびアウトバウンドのトランスポート・レベル・セキュリティのSFTPトランスポートをサポートしています。SFTPトランスポートでは、Secure Shell (SSH)バージョン2を使用して、ファイルを転送します。

- 双方向認証の実行方法

- known_hostsファイルの使用

- SFTPトランスポート認証プロセス

- インバウンドSFTPトランスポート・レベル・セキュリティの構成:主な手順

- アウトバウンドSFTPトランスポート・レベル・セキュリティの構成:主な手順

- インポート時に保持されるSFTPのセキュリティ属性

- SFTP資格証明のライフサイクル

51.4.1 双方向認証の実行方法

SFTP認証は双方向で、SFTPサーバーとSFTPクライアント(Service Busサービス)は、異なるメカニズムを使用して互いを認証します。

- SFTPサーバーは、「トランスポート構成」ページで指定した認証方法(「ユーザー名パスワード」、「ホスト・ベース」、;「公開鍵」)を使用してSFTPクライアント(Service Busサービス)を認証します。

- SFTPクライアント(Service Busサービス)は、known_hostsファイルを使用してSFTPサーバーを認証します。Service Busプロキシ・サービス(インバウンド・リクエスト)またはビジネス・サービス(アウトバウンド・リクエスト)システム上のknown_hostsファイルには、ホスト名とIPアドレス、プロキシ・サービスまたはビジネス・サービスが接続可能なリモートSFTPサーバーの公開鍵が必要です。SSHバージョン2は、この公開鍵を使用して接続を認証します。

SFTPクライアント(Service Busサービス)は、「トランスポート構成」ページで3つの認証方法のうちどれが選択されたかに関係なく、常にknown_hostsファイルを使用して、SFTPサーバーに接続するかどうかを決定します。つまり、どの場合でもSFTPサーバーは、このファイルにある情報を使用してService Busサービスにより認証されます。こうすることで、Service Busサービスが既知のサーバーに接続することを確認します。

たとえば、「ユーザー名パスワード」による認証の場合、SFTPクライアント(Service Busサービス)は、known_hostsファイルにあるSFTPサーバーの公開鍵に対してSFTPサーバーを認証します。SFTPサーバーは、サービス・アカウントのユーザー名とパスワードを使用して、クライアント(Service Busサービス)を認証します。

51.4.2 known_hostsファイルの使用

「トランスポート構成」ページでどの認証方法を選択しても、Service Busプロキシ・サービス(インバウンド・リクエスト)またはビジネス・サービス(アウトバウンド・リクエスト)システム上のknown_hostsファイルには、ホスト名とIPアドレス、プロキシ・サービスまたはビジネス・サービスが接続可能なリモートSFTPサーバーの公開鍵が必要です。

Service Busサービスは、known_hostsファイルにある公開鍵/ホスト/IPの組合せを使用してSFTPサーバーを認証します。

注意:

このSSH認証メカニズムは、一般的なService Busサービス・キー・プロバイダ/PKI資格証明マッパー・プロセスには属しません。

認証時にknown_hostsファイルの要件が満たされる必要があります。known_hostsファイルにリストされていないSFTPサーバーは、認証されません。

known_hostsファイルの作成

1. known_hostsテキスト・ファイルを作成するには、任意のエディタを使用します。
known_hostsの形式は次のとおりです。

Hostname,IP   algorithm  public-key

Hostname、IP、public_keyは、SFTPサーバーを識別します。

RSA (ssh-rsaとしてのみ入力)およびDSA (ssh-dsaまたはssh-dssとしてのみ入力)でサポートされるアルゴリズム。

このファイルの公開鍵の形式は、「OpenSSH公開鍵形式」です。

次に例を示します。

getafix,172.22.52.130   ssh-rsa   AAAAB3NzaC1yc2EAAAABIwAAAIEAtR+M3Z9HFxnKZTx66fZdnQqAHQcF1vQe1+EjJ/HWYtgAnqsn0hMJzqWMatb/u9yFwUpZBirjm3g2I9Qd8VocmeHwoGPhDGfQ5LQ/PPo3esE+CGwdnCOyRCktNHeuKxo4kiCCJ/bph5dRpghCQIvsQvRE3sks+XwQ7Wuswz8pv58=

行ごとに1つのエントリで、複数のエントリがサポートされています。

2. known_hostsファイルを次のディレクトリに移動します。
MW_HOME/user_projects/domains/osb_domain/osb/transports/sftp

/transports/sftpディレクトリは、自動的に作成されるわけではありません。ユーザーが作成する必要があります。

51.4.3 SFTPトランスポート認証プロセス

次の原則は、プロキシ・サービスとビジネス・サービスの両方のSFTP認証プロセスに適用されます。

- 接続: Service Busサービス(プロキシおよびビジネス)は、常にSFTPクライアントとして機能し、SFTPサーバーに接続します。

- SFTPサーバーによる認証: 公開鍵とホスト・ベースの認証の場合、SFTPサーバーはService Busサービスの公開鍵を使用して接続を認証します。ユーザー名/パスワードの場合、SFTPサーバーはユーザー名とパスワードを使用して接続を認証します。

- SFTPクライアントによる認証: Service Busサービスは、常にknown_hostsファイルにある公開鍵/ホスト/IPの組合せを使用してSFTPサーバーを認証します。

- 接続の確立: サーバー認証とクライアント認証の両方に成功した場合のみ、接続が確立されて転送の準備が完了します。

- 転送: プロキシ・サービスの場合は、ファイル(メッセージ)がダウンロードされ、ビジネス・サービスの場合はアップロードされます。

プロキシ・サービスのSFTP認証プロセスは、「プロキシ・サービスへの一方向のインバウンド・ダウンロード」で説明しています。ビジネス・サービスのSFTP認証プロセスは、「ビジネス・サービスからの一方向のアウトバウンド・アップロード」で説明しています。

51.4.3.1 プロキシ・サービスへの一方向のインバウンド・ダウンロード

プロキシ・サービスへの一方向のインバウンド・ダウンロードは、次のように説明されています。

1. SFTPクライアントであるプロキシ・サービスは、SFTPサーバーに接続しようとします。

2. プロキシ・サービスは、「トランスポート構成」ページで選択された認証メカニズムを使用して、SFTPサーバーから認証されます。
ホスト・ベースと公開鍵による認証の場合、リモートSFTPサーバーはプロキシ・サービスのホスト名と公開鍵を使用してService Busシステムを認証します。ユーザー名/パスワードによる認証の場合、SFTPサーバーは、プロキシ・サービスから(サービス・アカウントを使用して)提供されたユーザー名とパスワードを使用して、Service Busシステムを認証します。

3. (Service Busプロキシ・サービス・システム上の)known_hostsファイルは、Service Busプロキシ・サービスが接続可能なリモートSFTPサーバーの情報を保持します。
具体的には、このファイルにはホスト名とIPアドレス、認められたリモート・サーバーの公開鍵が含まれます。

SSHバージョン2は、この公開鍵を使用して接続を認証します。known_hostsファイルにリストされていないSFTPサーバーは、認証されません。

4. 認証が問題なく行われた場合、プロキシ・サービスはリモートSFTPサーバーに接続されたSFTPクライアントになります。

5. SFTPサーバーから許可された場合、プロキシ・サービス(SFTPクライアント)は、SFTPサーバー上のリモート・ディレクトリをポーリングし、リモート・ディレクトリにあるすべてのファイル(メッセージ)をダウンロードします。
プロキシ・サービスの構成によって、ポーリングするリモート・ディレクトリやポーリングの頻度、ダウンロードされるファイル(メッセージ)の処理が決まります。

51.4.3.2 ビジネス・サービスからの一方向のアウトバウンド・アップロード

ビジネス・サービスからの一方向のアウトバウンド・アップロードは、次のように説明されています。

1. ビジネス・サービス(SFTPクライアント)は、SFTPサーバーに接続しようとします。

2. ビジネス・サービスは、「トランスポート構成」ページで選択された認証メカニズムを使用して、SFTPサーバーから認証されます。
ホスト・ベースと公開鍵による認証の場合、SFTPサーバーはビジネス・サービスのホスト名と公開鍵を使用してService Busシステムを認証します。ユーザー名/パスワードによる認証の場合、SFTPサーバーは(サービス・アカウントからの)ユーザー名とパスワードを使用して、Service Busシステムを認証します。

3. (Service Busビジネス・サービス・システム上の)known_hostsファイルは、Service Busビジネス・サービスが接続可能なSFTPサーバーの情報を保持します。
具体的には、このファイルにはホスト名とIPアドレス、認められたサーバーの公開鍵が含まれます。

SSHバージョン2は、この公開鍵を使用して接続を認証します。known_hostsファイルにリストされていないSFTPサーバーは、認証されません。

4. 認証が問題なく行われた場合、ビジネス・サービスはリモートSFTPサーバーに接続されたSFTPクライアントになります。

5. SFTPサーバーで許可された場合、ビジネス・サービス(SFTPクライアント)は、SFTPサーバー上のリモート・ディレクトリにファイルをアップロードします。
ビジネス・サービスの構成によって、ファイルをアップロードするリモート・ディレクトリやアップロードの再試行の頻度、アップロードされるファイル名に追加するファイルの接頭辞や接尾辞が決まります。

51.4.4 インバウンドSFTPトランスポート・レベル・セキュリティの構成:主な手順

プロキシ・サービスのインバウンド・トランスポート・レベルのセキュリティを構成するには:

1. 「known_hostsファイルの使用」の説明に従って、Service Busプロキシ・サービス・システム上にknown_hostsファイルを作成します。

known_hostsは、Service Busプロキシ・サービスが接続可能なリモートSFTPサーバーの情報を保持します。具体的には、このファイルにはホスト名とIPアドレス、認められたリモート・サーバーの公開鍵が含まれます。

SSHバージョン2は、この公開鍵を使用して接続を認証します。known_hostsファイルにリストされていないSFTPサーバーは、認証されません。

2. プロキシ・サービスを作成するときは、「トランスポート構成」ページで、「SFTP」を選択します。

3. エンド・ポイントのURIをsftp://hostname:port/directory形式で指定します。詳細は次のとおりです。

- hostname は、SFTPサーバーのホスト名またはIPアドレスです。

- portは、SFTPサーバーがリスニングしているポートです。SFTPのデフォルト・ポートは22です。

- directoryは、ファイルのために定期的にポーリングされる場所です。このディレクトリはユーザーのホーム・ディレクトリに相対します。

4. SFTPトランスポート構成ページで、「ユーザー名パスワード」、「ホスト・ベース」、「公開鍵」認証のいずれかを選択します。

ここでは、認証の選択肢の概要について説明しています。詳細は、「SFTPトランスポートの使用」を参照してください。

- ユーザー名/パスワードによる認証では、静的なサービス・アカウントが(SFTPサーバー上のユーザー資格証明を使用して)、この認証方法に関連付けられるよう指定します。サービス・アカウントは、プロキシ・サービスでSFTPサーバーへの認証に使用されるユーザー名とパスワードを提供します。SFTPクライアントは、提供された資格証明を使用して認証されます。サポートされているのは、静的なサービス・アカウントのみです。

- ホスト・ベースの認証では、識別された既知のホストからの接続のみが許可されるよう指定します。この認証方法では、ユーザー名とサービス・キー・プロバイダを要求します。
SFTPサーバーは、プロキシ・サービスの公開鍵を使用してプロキシ・サービスを認証します。

注意:

Service Busプロキシ・サービスは、SFTPサーバーからの資格証明を認証するために、自身でサービス・キー・プロバイダを使用することはありません。known_hostsファイルのみを使用して、SFTPサーバーを認証します。

プロキシ・サービスの公開鍵は、サービス・キー・プロバイダによって参照されるキー・ペア内に存在します。サービス・キー・プロバイダを設定する際に、このキーを抽出する必要があります。次に、この公開鍵を使用するため、SFTPサーバーを構成します。

たとえば、Linux上のSFTPサーバーの場合は、次を行う必要があります。

- /etc/ssh/shosts.equivファイルを編集し、Service Busドメインを実行しているマシンのホスト名またはIPアドレスを追加します。

- /etc/ssh/ssh_known_hostsファイルを編集し、Service Busドメインを実行しているマシンのホスト名またはIPアドレスを追加して、その後に空白と公開鍵を続けます。

ユーザー名を使用して、ポーリングするSFTPサーバー上のディレクトリを決定します。

- 公開鍵では、この認証方法を使用するためにユーザー名とサービス・キー・プロバイダが要求されることを指定します。各ユーザーは固有の秘密鍵を持っています。
SFTPサーバーは、公開鍵を用いてプロキシ・サービスを認証します。

注意:

Service Busプロキシ・サービスは、SFTPサーバーからの資格証明を認証するために、自身でサービス・キー・プロバイダを使用することはありません。known_hostsファイルのみを使用して、SFTPサーバーを認証します。

プロキシ・サービスの公開鍵は、サービス・キー・プロバイダによって参照されるキー・ペア内に存在します。サービス・キー・プロバイダを設定する際に、このキーを抽出する必要があります。次に、この公開鍵を使用するため、SFTPサーバーを構成します。

たとえば、Linux上のSFTPサーバーについて、任意のIDに関してあるシステムにアクセス権限を許可するには、そのシステム上の$HOME/.ssh/authorized_keysファイルに公開鍵を入れます。そのファイルにリストされたすべての鍵にアクセスが許可されます。

ユーザー名を使用して、ポーリングするSFTPサーバー上のディレクトリを決定します。また、ユーザー名はSFTPサーバー上の公開鍵の場所を識別するときにも使用されます。

5. リモートSFTPサーバーから許可された場合、プロキシ・サービス(SFTPクライアント)は、SFTPサーバー上のリモート・ディレクトリをポーリングし、リモート・ディレクトリにあるすべてのファイルをダウンロードします。

プロキシ・サービスの構成によって、ポーリングするリモート・ディレクトリやポーリングの頻度、ダウンロードされるファイル(メッセージ)の処理が決まります。

ポーリングするディレクトリは絶対パスです。

51.4.5 アウトバウンドSFTPトランスポート・レベル・セキュリティの構成:主な手順

ビジネス・サービスのアウトバウンド・トランスポート・レベルのセキュリティを構成するには:

1. 「known_hostsファイルの使用」の説明に従って、Service Busビジネス・サービス・システム上にknown_hostsファイルを作成します。

known_hostsは、Service Busビジネス・サービスが接続可能なリモートSFTPサーバーの情報を保持します。具体的には、このファイルにはホスト名とIPアドレス、認められたリモート・サーバーの公開鍵が含まれます。

SSHバージョン2は、この公開鍵を使用して接続を認証します。known_hostsファイルにリストされていないSFTPサーバーは、認証されません。

2. ビジネス・サービスを作成するときは、「トランスポート構成」ページで、「SFTP」を選択します。

3. エンド・ポイントのURIをsftp://hostname:port/directory形式で指定します。詳細は次のとおりです。

- hostname は、SFTPサーバーのホスト名またはIPアドレスです。

- portは、SFTPサーバーがリスニングしているポートです。SFTPのデフォルト・ポートは22です。

- directoryは、ファイルがアップロードされる場所です。このディレクトリはユーザーのホーム・ディレクトリに相対します。

4. SFTPトランスポート構成ページで、「ユーザー名パスワード」、「ホスト・ベース」、「公開鍵」認証のいずれかを選択します。

ここでは、認証の選択肢の概要について説明しています。詳細は、「SFTPトランスポートの使用」を参照してください。

- ユーザー名/パスワードによる認証では、静的なサービス・アカウントが(SFTPサーバー上のユーザー資格証明を使用して)、この認証方法に関連付けられるよう指定します。サービス・アカウントは、ビジネス・サービスでSFTPサーバーへの認証に使用されるユーザー名とパスワードを提供します。SFTPクライアントは、提供された資格証明を使用して認証されます。サポートされているのは、静的なサービス・アカウントのみです。

- ホスト・ベースの認証では、識別された既知のホストからの接続のみが許可されるよう指定します。この認証方法では、ユーザー名とサービス・キー・プロバイダを要求します。
SFTPサーバーは、ビジネス・サービスの公開鍵を使用してビジネス・サービスを認証します。

注意:

Service Busビジネス・サービスは、SFTPサーバーからの資格証明を認証するために、自身でサービス・キー・プロバイダを使用することはありません。known_hostsファイルのみを使用して、SFTPサーバーを認証します。

ビジネス・サービスの公開鍵は、サービス・キー・プロバイダによって参照されるキー・ペア内に存在します。サービス・キー・プロバイダを設定する際に、このキーを抽出する必要があります。次に、この公開鍵を使用するため、SFTPサーバーを構成します。

たとえば、Linux上のSFTPサーバーの場合は、次を行う必要があります。

- /etc/ssh/shosts.equivファイルを編集し、Service Busドメインを実行しているマシンのホスト名またはIPアドレスを追加します。

- /etc/ssh/ssh_known_hostsファイルを編集し、Service Busドメインを実行しているマシンのホスト名またはIPアドレスを追加して、その後に空白と公開鍵を続けます。

ユーザー名を使用して、SFTPサーバー上のアップロード用ディレクトリを決定します。

- 公開鍵では、この認証方法を使用するためにユーザー名とサービス・キー・プロバイダが要求されることを指定します。各ユーザーは固有の秘密鍵を持っています。
SFTPサーバーは、公開鍵を用いてビジネス・サービスを認証します。

注意:

Service Busビジネス・サービスは、SFTPサーバーからの資格証明を認証するために、自身でサービス・キー・プロバイダを使用することはありません。known_hostsファイルのみを使用して、SFTPサーバーを認証します。

ビジネス・サービスの公開鍵は、サービス・キー・プロバイダによって参照されるキー・ペア内に存在します。サービス・キー・プロバイダを設定する際に、このキーを抽出する必要があります。次に、この公開鍵を使用するため、SFTPサーバーを構成します。

たとえば、Linux上のSFTPサーバーについて、任意のIDに関してあるシステムにアクセス権限を許可するには、そのシステム上の$HOME/.ssh/authorized_keysファイルに公開鍵を入れます。そのファイルにリストされたすべての鍵にアクセスが許可されます。

ユーザー名は、SFTPサーバー上のアップロード・ディレクトリの決定と、SFTPサーバー上の公開鍵の場所を識別するときに使用されます。

5. リモートSFTPサーバーで許可された場合、ビジネス・サービス(SFTPクライアント)は、SFTPサーバー上のリモート・ディレクトリにファイルをアップロードします。

ビジネス・サービスの構成によって、ファイルをアップロードするリモート・ディレクトリやアップロードの再試行の頻度、アップロードされるファイル名に追加するファイルの接頭辞や接尾辞が決まります。

アップロード・ディレクトリは絶対パスで、自動的に作成されます。

51.4.6 インポート時に保持されるSFTPのセキュリティ属性

次のセキュリティ属性は、インポート時に「セキュリティおよびポリシーの構成を保持」オプションが選択された場合に保持されます。

- クライアント認証方式

- サービス・アカウントへの参照(ユーザー名/パスワード認証の場合)

- サービス・キー・プロバイダへの参照(ホスト・ベースおよび公開鍵による認証の場合)

- ユーザー名(ホスト・ベースおよび公開鍵による認証の場合)

51.4.7 SFTP資格証明のライフサイクル

ユーザー名/パスワードや公開鍵の資格証明が変更になった場合、SFTPトランスポートは以前の資格証明により確立されたすべてのアイドル接続を解除し、再度接続しようとします。アクティブな接続の場合、SFTPトランスポートは現在の操作が完了した後に接続を解除します。

51.5 電子メール、FTP、およびファイル・トランスポート・レベルのセキュリティ

次の項では、電子メール、FTP、ファイル・プロトコルを介した通信で使用可能なセキュリティ対策について説明します。

- 電子メールとFTPトランスポート・レベルのセキュリティ

- ファイル・トランスポート・セキュリティ

51.5.1 電子メールとFTPトランスポート・レベルのセキュリティ

電子メールとFTPは、セキュアなプロトコルではありません。これらは通常、セキュアでないチャネルを通して、脆弱な認証をサポートします。電子メールやFTPトランスポートでサポートされているセキュリティ方法は、電子メールやFTPサーバーへの接続に必要とされるユーザー名およびパスワードです。

電子メールを保護するには、ユーザー名およびパスワードの別名としてサービス・アカウントを指定する必要があります。サービスでは、SMTPサーバーに対する認証にユーザー名とパスワードを使用します。

FTPトランスポートを保護するには、external_userを選択し、ユーザー名とパスワードの別名としてサービス・アカウントを指定します。サービスでは、FTPサーバーに対する認証にユーザー名とパスワードを使用します。

電子メールおよびFTPトランスポートにセキュリティを追加する方法の詳細は、「ビジネス・サービスの作成と構成」を参照してください。

51.5.2 ファイル・トランスポート・セキュリティ

ファイル・トランスポートでサポートされているセキュリティ方法は、ファイルがあるコンピュータに対するユーザー・ログインです。

「SFTPトランスポートのトランスポート・レベルでのセキュリティの構成」に説明されているSFTPトランスポートは、FTPを保護する推奨メカニズムです。

51.6 SBトランスポートのトランスポート・レベルでのセキュリティの構成

Service Bus (SB)トランスポートでは、クライアントのService BusサーバーがRMIを使用してService Busプロキシ・サービスを同期的に呼び出せます。RMIは、クライアントのService BusサーバーがSBトランスポートにアクセスできる唯一のメカニズムです。Service Busのこのリリースでは、関連のAPIは社内使用専用であり、文書化はされていません。

SBプロキシ・サービスには、次の2つの方法のどちらかによりアクセスします。

- プロキシ・サービスのService Busサーバーに接続するためにSBビジネス・サービスを使用するクライアントService Busサーバーから、JNDIコンテキストとプロキシ・サービスのURIを使用して。

- SBプロキシ・サービスにアクセスするために独自のアーティファクトを使用するOracle WebLogic IntegrationとOracle Data Service Integratorなどの製品を使用して。これらのアーティファクトは製品に対して一意であり、ここでは説明しません。

SBビジネス・サービスは、SBプロキシ・サービスにだけメッセージを送信できます。JNDIプロバイダ(ビジネス・サービスのエンドポイントURIで指定)を使用して、リモートService Busサーバー上でJNDIルックアップを行います。具体的にはJNDIプロバイダは、SBプロキシ・サービスに対応するRMIスタブを取得するためにサービスがデプロイされているService Busサーバーを参照します。

たとえば、ビジネス・サービスで指定するエンドポイントのURIは、sb://some_secured_jndi_provider/some_remote_sb_proxyとなります。

セキュアなJNDIプロバイダは、セキュア・プロトコルを使用したプロバイダURLを持っている必要があります。SBビジネス・サービスの場合は、HTTPSやt3sプロトコルを使用できます。

(ビジネス・サービスの)サービス・アカウントは、リモートSBプロキシ・サービスの呼出しに使用されるユーザー資格証明を指定します。サービス・アカウントが指定されない場合は、このビジネス・サービスのインバウンド・プロキシ・サービス(インバウンド・クライアント)のユーザー資格証明が、セキュリティ・コンテキストの伝播に使用されます。

SBトランスポートは、SSLを使用して協力なサーバーとクライアントの認証を要求できます。SBトランスポートとともにSSLを使用する前に、WebLogic ServerでSSLを構成する必要があります。「Oracle WebLogicセキュリティ・フレームワークの構成:主な手順」を参照してください。

警告:

「SSLを使用」フラグが設定されていると、リクエストをSSL接続経由で送信する必要があります。ただし、SBトランスポートではセキュアでない接続は禁止されていません。プロキシ・サービスはセキュアなURI (sbsとあるもの)を使用して(有効なWSDLファイルまたはUDDI経由で)通知されますが、セキュアなアクセスは強制されません。

Service Busサーバー管理者は、サーバー上のセキュアでないすべてのプロトコル(t3、httpなど)を閉じ、セキュアなクライアント接続を厳密に強制する必要があります。

51.6.1 サービス・バス(SB)トランスポートを使用したSAML認証の構成

SBトランスポートでSAMLベースの認証を使用する場合は、次の構成要件に従ってください。

- SBクライアント側で、SAML資格証明マッパー・プロバイダを構成し、このクライアントから呼び出す予定がある各SBプロキシ・サービスにSAMLの依存側を作成します。対象のURLフィールドに、http://openuri.org/<OSBProxyServiceURI>と入力します。OSBProxyServiceURIは、SBプロキシ・サービスのサービスURIです。

- (SBプロキシ・サービスが存在する) Service Bus側では、SAML IDアサーション・プロバイダを構成して、SAMLのアサーション側を作成します。対象のURLフィールドには、SBプロキシ・サービスのサービスURIを入力します。SBプロトコルやホスト/ポートの情報は含めないでください。たとえば、/<OSBProxyServiceURI>です。

51.7 WSトランスポートのトランスポート・レベルでのセキュリティの構成

Webサービスの信頼性のあるメッセージング(WS-RM)の機能が、WSトランスポートとしてService Busで使用できます。Service Busは、2005年2月に提出された仕様をサポートしています。この仕様の詳細は、「Web Services Reliable Messagingプロトコル(WS-ReliableMessaging)」(http://schemas.xmlsoap.org/ws/2005/02/rm/)を参照してください。

WSトランスポートには、プロキシ・サービス(インバウンド)とビジネス・サービス(アウトバウンド)の両方のコンポーネントがあり、それらはSOAP1.1およびSOAP1.2をベースとしたWSDLファイルとWS-RMポリシーに基づいています。一方向とリクエスト/レスポンスのパターンをどちらもサポートしていますが、レスポンスは信頼性に欠けます。

51.7.1 Webサービスの信頼性のあるメッセージングの定義

Oracle WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミングのWebサービスの信頼性のあるメッセージングの概要に関する項で説明されているとおり、WS-RMはあるアプリケーション・サーバーで実行中のアプリケーションが、別のアプリケーション・サーバーで実行中のWebサービスを安定して呼び出すことができるフレームワークです。この場合、どちらのサーバーもWS-ReliableMessaging仕様を実装していることが前提です。「安定した」とは、2つのWebサービス間でメッセージの配信を保証する能力として定義できます。特に、仕様では相互運用可能なプロトコルと記述され、あるソースのエンドポイント(またはクライアントのWebサービス)から宛先のエンドポイント(または安定して操作を呼び出せるWebサービス)に送信されたメッセージが、1つ以上の配信保証に従って配信されたことが保証されるか、あるいはエラーが発生するというものです。

51.7.2 WLS Consoleに表示されるWSトランスポート・リソース

WSプロキシ・サービスは、Oracle WebLogic Server管理コンソールで表示されますが、WLSからポリシーを割り当てようとしても無視されます。

具体的には、管理者はOracle WebLogic Server管理コンソールで「ホーム」→「セキュリティ・レルムのサマリー」→「myrealm」→「レルム・ロール」ページに移動して、WSプロキシ・サービスのセキュリティ・ポリシーを外見上は編集できます。

ただし、このポリシーには何の効果もなく、実行時に評価されません。

EARアプリケーションはセッションをアクティブ化すると自動的に生成され、Service Busによってデプロイされます。これは、それぞれのWSプロキシ・サービスに対して1つのEARファイルです。

51.7.3 Webサービスの信頼性のあるメッセージングを構成するためのWS-Policyファイルの使用

WSトランスポート・セキュリティは、WSDLファイルから、あるいはサービスに直接バインドされる形でWS-Policyファイルを通して構成します。

Service Busは、WS-Policyファイルを使用して、宛先のエンドポイントがそのWS-RM機能および要件を記述、通知できるようにします。WS-Policy仕様は、Webサービスのポリシーを記述および伝達するための一般目的のモデルと構文を提供します。

これらのWS-Policyファイルは、サポートされるWS-ReliableMessaging仕様のバージョン、ソース・エンドポイントの再送信の間隔、宛先エンドポイントの受信確認の間隔などの機能を記述するXMLファイルです。

RMアサーションとWSSPトランスポート・レベルのセキュリティ・アサーションを持つWS-Policyは、WSトランスポートのみでサポートされています。

51.7.3.1 構成済のWS-RMポリシー・ファイル

Service Busには、独自のWS-Policyファイルを作成しない場合に指定できる、2つの単純なWS-RM WS-Policyファイルが用意されています。

- DefaultReliability.xml - 信頼性のあるメッセージングのポリシーのアサーションに一般的な値(非アクティブ・タイムアウト10分、確認応答の間隔200ミリ秒、基本的な再送信間隔3秒など)を指定します。

- LongRunningReliability.xml - デフォルトの信頼性のあるメッセージングWS-Policyファイルと似ていますが、アクティビティのタイムアウト間隔に、より大きな値(24時間)を指定します。

これらのあらかじめパッケージ化されたファイルを変更することはできません。値がニーズに合わない場合は、独自のWS-Policyファイルを作成する必要があります。

たとえば、次の例は完全なLongRunningReliability.xmlファイル(weblogic.jarから抽出されたもの)を示します。

例 - LongRunningReliability.xmlファイル

<?xml version="1.0"?>
<wsp:Policy
xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:beapolicy="http://www.bea.com/wsrm/policy"
>
<wsrm:RMAssertion >
<wsrm:InactivityTimeout
Milliseconds="86400000" />
<wsrm:BaseRetransmissionInterval
Milliseconds="3000" />
<wsrm:ExponentialBackoff />
<wsrm:AcknowledgementInterval
Milliseconds="200" />
<beapolicy:Expires Expires="P1M" optional="true"/>
</wsrm:RMAssertion>
</wsp:Policy>

51.7.4 アクティブ化の前に必要なRM WS-Policy

WSトランスポートを使用するプロキシまたはビジネス・サービスは、WSDLファイルから、またはサービスに直接バインドされる形で、RMアサーションを含むWS-Policyを持っている必要があります。他のトランスポートを使用するサービスが、RMアサーションを含むWS-Policyを持つことはできません。

RMアサーションはサービス・レベルでのみバインドでき、操作やリクエスト/レスポンスのレベルではバインドできません。

51.7.5 非同期レスポンス

WS-RMは一方向とリクエスト/レスポンスという2つのメッセージング・パターンをサポートしています。WSトランスポートは両方のパターンをサポートしていますが、信頼性の高いレスポンスはサポートしていません。つまり、レスポンスは安全に送信されませんが、リクエストは常に信頼できます。

RMクライアントへのWSトランスポートを使用したプロキシ・サービスからの非同期レスポンスは、RMクライアントによって指定されるAcksToまたはReplyToエンドポイント参照に接続します。RMクライアントは、HTTP URLまたはHTTPS URLを使用できます。RMクライアントがHTTPSを使用する場合、RMクライアントはSSLハンドシェイク中にクライアント証明書をリクエストできます。WSトランスポートでは、リクエスト時にサービス・キー・プロバイダのSSLのキー・ペアを使用します。

51.7.6 プロキシ・サービスの認証

WSトランスポートは、WS-Policyファイルを使用して次のHTTPSセキュリティ・モードをサポートしています。

- HTTPS - クライアント認証なし

- 基本認証のHTTPS

- クライアント証明書(双方向SSL)のHTTPS

表51-1は、これらのモードを実装するあらかじめ構成されたセキュリティ・ポリシーと、それらを使用する状況を示します。

表51-1 WSトランスポートの認証一覧

HTTPSが必要

必要とされる認証

あらかじめ構成されたトランスポート・セキュリティ・ポリシー

はい

なし

Wssp1.2-Https.xml

はい

基本

Wssp1.2-HttpsBasic.xml

はい

クライアント証明書

Wssp1.2-HttpsClientCert.xml

WSプロキシ・サービスは、WS-PolicyのWSSP 1.2トランスポート・レベルのセキュリティ・アサーションで決められているとおり、基本とクライアント証明書(双方向SSL)による認証のどちらもサポートしています。

次の例にある、パッケージされたWssp1.2-Https.xmlポリシーから抽出された、HTTPSトークンとBasic256アルゴリズムの例について考えてみてください。

WS-policyで基本認証が指定されている場合、すべてのHTTPSリクエスト(WSプロキシ・サービスへのRMプロトコル・メッセージを含む)は、有効なユーザー名とパスワードを持っている必要があります。

例 - Wssp1.2-Https.xmlファイル(抜粋)

:
<sp:TransportBinding>
<wsp:Policy >
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken />
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
</wsp:Policy>
</sp:TransportBinding>
</wsp:Policy>

プロキシ・サービス認証のサポートは次のように行われます。

- プロキシ・サービス用に構成されたサービス・キー・プロバイダに割り当てられたSSL鍵ペアを使用するクライアント証明書のアウトバウンド認証。
サービス・キー・プロバイダ(アウトバウンド・リクエストで鍵と証明書のペアを渡します)の作成を計画している場合は、Oracle WebLogic Server管理コンソールを使用して、PKI資格証明マッピング・プロバイダを構成します。Service Busをホストする任意のWebLogic Serverドメインで、最大1つのPKI資格証明マッピング・プロバイダを構成できます。

- WSプロキシ・サービス(基本認証を使用する)による他の任意のアウトバウンド・トランスポート、またはアウトバウンドWSSユーザー名トークンに対するユーザー名/パスワードのIDの伝播。
ビジネス・サービスでユーザー名とパスワード・トークンを要求する場合は、元のクライアント・リクエストからユーザー資格証明をパススルーするようにビジネス・サービスのサービス・アカウントを構成します。「サービス・アカウントの操作」を参照してください。

- WSプロキシ・サービス(基本認証または双方向SSL認証)と他の任意のトランスポートとの間の資格証明のマッピング。

- WSプロキシ・サービスからRMクライアントへのHTTPまたはHTTPSを使用した非同期レスポンスの送信(信頼性なし)。プロキシ・サービスとビジネス・サービスで使用されるデフォルトのプロトコルはHTTPです。
WSプロキシ・サービスから、RMクライアントによって指定される AcksTo または ReplyTo エンドポイント参照に接続するRMクライアントへの非同期レスポンス。RMクライアントはHTTP URLまたはHTTPS URLのどちらかを使用できます。RMクライアントがHTTPSを使用する場合、RMクライアントはSSLハンドシェイク中にクライアント証明書をリクエストできます。WSトランスポートでは、リクエスト時にサービス・キー・プロバイダのSSLのキー・ペアを使用します。

51.7.7 インポート時のセキュリティ構成の保持

Preserve Security and Policy Configurationフラグが設定されている場合、WSトランスポート・プロバイダは次のセキュリティ構成を保持します。サービス・アカウントへの参照(WSビジネス・サービスのみ)

51.7.8 インバウンド/アウトバウンドWSトランスポート・レベルのセキュリティの構成

WSトランスポート・セキュリティは、WSDLファイルから、あるいはサービスに直接バインドされる形でWS-Policyを通して構成します。

51.8 WebSphereメッセージ・キュー・トランスポートのトランスポート・レベルでのセキュリティの構成

Service Busには、ネイティブのメッセージ・キュー(MQ)トランスポートのサポートが備わっています。これは、WebSphere MQとの間でメッセージを送受信できる機能です。この文脈において、MQトランスポートは、MQライブラリを使用してMQサーバーに接続するクライアントです。

MQ接続リソースを作成する際に、トランスポートのセキュリティ関連のプロパティを構成します。続いて、これらのプロパティは、MQプロキシ又はビジネス・サービスによって使用されます。

注意:

「環境へのMQクライアント・ライブラリの追加方法」の説明に従って、環境にMQクライアント・ライブラリを追加してください。

MQ接続リソースには、次の2つのモードが備わっています。

バインド・モード - バインド・モードを使用して、Service Busと同じマシンにあるMQキュー・マネージャに接続します。このモードでは、サービスはネットワークを介して通信するのでなく、既存のキュー・マネージャAPIに直接コールします。このモードは、ローカルのキュー・マネージャに接続する早い方法です。

tcpモード - tcpモードは、MQキュー・マネージャがService Busと同じマシン上にない場合に使用します。

51.8.1 インバウンドMQトランスポート・レベル・セキュリティの構成:主な手順

プロキシ・サービスのインバウンド・トランスポート・レベルのセキュリティを構成するには:

1. MQトランスポートを使用するプロキシ・サービスを作成する前に、使用するトランスポートにMQ接続リソースを作成してください。次のセキュリティ構成設定から選択します。

- SSLが必要。メッセージの送信にHTTPSを使用する場合は、このチェック・ボックスを選択します。「双方向SSLが必要」オプションが選択されていない場合に、サーバー側のSSL(サーバーがクライアントに対して認証)がサポートされます。

- 暗号セット。このオプションは、「SSLが必要」チェック・ボックスが選択されている場合にのみ使用できます。SSLで使用される暗号スイート・アルゴリズムを選択します。
暗号スイートとは、鍵交換アルゴリズム、対称暗号化アルゴリズム、およびセキュア・ハッシュ・アルゴリズムを含むSSL暗号方式の一種です。通信の整合性を保護するために使用します。

暗号化スイート・アルゴリズムは、WebSphere MQサーバーとMQトランスポート間のメッセージの通信を暗号化および復号化するときに使用されます。

- 双方向SSLが必要。このオプションは、「SSLが必要」チェック・ボックスが選択されている場合にのみ使用できます。クライアント側とサーバー側のSSL認証の使用を強制するには、このチェック・ボックスを選択します。

- サービス・キー・プロバイダへの参照。「双方向SSLが必要」を選択した場合、適切なクライアント側SSLのキー・マネージャを取得するために、サービス・キー・プロバイダへの参照を指定する必要があります。
サービス・キー・プロバイダのパス(プロジェクト/フォルダ)と名前を入力するか、「参照」をクリックして、「サービス・キー・プロバイダの選択」ページから選択します。

- 静的なサービス・アカウントへの参照。ユーザー名とパスワードによる認証に必要です。静的なサービス・アカウントのパス(プロジェクト/フォルダ)および名前を入力するか、「参照」をクリックしてサービス・アカウントを選択します。

2. プロキシ・サービスを作成するときは、「トランスポート構成」ページで、「mq」を選択します。

51.8.2 アウトバウンドMQトランスポート・レベル・セキュリティの構成:主な手順

ビジネス・サービスのアウトバウンド・トランスポート・レベルのセキュリティを構成するには:

1. MQトランスポートを使用するプロキシ・サービスを作成する前に、使用するトランスポートにMQ接続リソースを作成してください。次のセキュリティ構成設定から選択します。

- SSLが必要。メッセージの送信にHTTPSを使用する場合は、このチェック・ボックスを選択します。「双方向SSLが必要」オプションが選択されていない場合に、サーバー側のSSL(サーバーがクライアントに対して認証)がサポートされます。

- 暗号セット。このオプションは、「SSLが必要」チェック・ボックスが選択されている場合にのみ使用できます。SSLで使用される暗号スイート・アルゴリズムを選択します。
暗号スイートとは、鍵交換アルゴリズム、対称暗号化アルゴリズム、およびセキュア・ハッシュ・アルゴリズムを含むSSL暗号方式の一種です。通信の整合性を保護するために使用します。

暗号化スイート・アルゴリズムは、WebSphere MQサーバーとMQトランスポート間のメッセージの通信を暗号化および復号化するときに使用されます。

- 双方向SSLが必要。このオプションは、「SSLが必要」チェック・ボックスが選択されている場合にのみ使用できます。クライアント側とサーバー側のSSL認証の使用を強制するには、このチェック・ボックスを選択します。

- サービス・キー・プロバイダへの参照。「双方向SSLが必要」を選択した場合、適切なクライアント側SSLのキー・マネージャを取得するために、サービス・キー・プロバイダへの参照を指定する必要があります。
サービス・キー・プロバイダのパス(プロジェクト/フォルダ)と名前を入力するか、「参照」をクリックして、「サービス・キー・プロバイダの選択」ページから選択します。

- 静的なサービス・アカウントへの参照。ユーザー名とパスワードによる認証に必要です。静的なサービス・アカウントのパス(プロジェクト/フォルダ)および名前を入力するか、「参照」をクリックしてサービス・アカウントを選択します。

2. ビジネス・サービスを作成するときは、「トランスポート構成」ページで、「mq」を選択します。

51.9 メッセージ・コンテキストでのトランスポート・レベルのセキュリティ要素

クライアントを認証するためにプロキシ・サービスを構成する場合、クライアントのIDおよびクライアントが属するセキュリティ・グループに、プロキシ・サービスのパイプラインからアクセスできます。IDとグループ情報は、次の場所にあるメッセージ・コンテキストにあります。

$inbound/ctx:security/ctx:transportClient/ctx:username

および

$inbound/ctx:security/ctx:transportClient/ctx:principals/ctx:group

(メッセージ・コンテキストには、ユーザーが属する各グループごとに1つのctx:group要素が含まれます)

プロキシ・サービスがクライアントを認証しない場合、$inbound/ctx:security/ctx:transportClient/ctx:usernameの値は<anonymous>で、ctx:group要素はありません。

詳細は、「inbound変数とoutbound変数」を参照してください。

52 Oracle Web Services Managerを使用したOracle Service Busのセキュリティ

この章では、Service BusとOracle Web Services Manager (OWSM)を組み合せて使用し、既存のセキュリティ・プロバイダを活用しながら、WS-Securityポリシーとのサービス統合環境を保護するためのスケーラブルで標準ベースの集中管理型アプローチを提供する方法について説明します。

OWSMは、セキュリティ・ポリシーの作成、管理、および制御のための実行時フレームワークです。ポリシーを作成して、Service Bus内のサービスにアタッチし、OWSMエージェントを使用してこれらのポリシーをメッセージングのライフ・サイクルの様々なポイントで施行します。

OWSMポリシーにより、WS-AT、WS-RMおよびWS-Security/WS-SCが有効になります。WSDL埋込みポリシーは使用できません。

注意:

Oracle Web Services Manager (OWSM)は、Service Busで使用されるWebサービス・セキュリティ・メカニズムです。ビジネス・サービスやプロキシ・サービスなどの新規作成されたすべてのリソースでは、セキュリティにOWSMポリシーを使用します。WLS 9ポリシーは非推奨になったため、新しいService Busリソースのセキュリティの構成には使用できません。

ただし、WLS 9ポリシーですでに構成されたリソースをService Busプロジェクトにインポートできます。これらのWLS 9ポリシーの編集または変更はできませんが、OWSMポリシーに置き換えることができます。

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

- Oracle Web Services ManagerとOracle Service Busの統合について

- Oracle Service BusでのOracle Web Services Managerの使用

- OAuthを使用したRESTエンドポイントによるサービスの保護

52.1 Oracle Web Services ManagerとOracle Service Busの統合について

OWSMは、Oracle Enterprise Manager Fusion Middleware Controlのコンポーネントで、Oracle SOA Suite環境およびアプリケーションの集中管理と制御を提供するランタイムのフレームワークです。OWSMポリシーは、Oracle Enterprise Managerで作成および構成し、ポリシー・ストア(データベースを推奨)で保持されます。OWSMを使用すると、LDAPディレクトリに対してポリシーを定義し、標準のセキュリティ・トークン(SAMLトークンなど)を生成して、単一のトランザクションで使用される複数のWebサービス間でIDを伝播できます。

Service Busでは、セキュリティ・ポリシーをアタッチできるビジネス・サービスやプロキシ・サービスを定義する際に、使用可能なOWSMポリシーをアタッチできます。

52.1.1 セキュリティ・プロバイダ

Service BusおよびOracle Web Services Manager (OWSM)では、認証と認可に特定のサービスを使用します。OWSMはJava Platform Security (JPS)を使用するため、Service BusはOWSMポリシーにJPSプロバイダを使用します。Service Busでは、メッセージ・セキュリティの他のアスペクトに対してCommon Security Services (CSS)も使用します。これは、Oracle Platform Security Services (OPSS)の一部です。

Oracleセキュリティ・サービスの詳細は、Oracle Platform Security Servicesによるアプリケーションの保護のOracle Platform Security Servicesの概要に関する項を参照してください。

次のトピックでは、様々なセキュリティ分野でService BusとOWSMがどのセキュリティ・プロバイダを使用するかについて説明します。

52.1.1.1 JPSプロバイダ

Oracle Web Services Managerポリシーを使用する場合は、次の事項が適用されます。

- OWSMポリシーは、WebLogic Serverではなく、JPSのSAMLプロバイダを使用します。OWSMでのSAMLの構成の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のSAMLの構成に関する項を参照してください。

- 認証の場合、OWSMはJPSログイン・モジュールを使用し、このモジュールが、WebLogic Server上で構成された認証プロバイダをコールします。

- OWSMとService Busは、Oracle Platform Security Servicesで提供されるJavaキーストア(Java Keystore: JKS)とキーストア・サービス(Keystore Service: KSS)をサポートしています。OWSMポリシーの場合、WebLogic ServerとJPSキーストアの両方が同じ種類のキーストアを参照するようにJPS上でキーストアを構成する方法が最適です。たとえば、JKSファイル・キーストアを使用する場合、JPSとWebLogic Serverは同じファイルを示す必要があります。KSSキーストアを使用する場合、JPSとWebLogic Serverは同じKSS構成を示す必要があります。
キーストアの作成の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のメッセージ保護に関するキーストアの構成に関する項を参照してください。

- JPSキーストアは、OWSMポリシーのキーストア兼トラストストアとして機能します。

52.1.1.2 CSSプロバイダ

Service Busは、次のプロバイダを使用します。

- WLS 9ポリシーを施行するためのCSSプロバイダ

- トランスポート・セキュリティを施行するためのCSSプロバイダ

- 認証ポリシーのWebLogic Server認可プロバイダ

- カスタムのWebLogic Server認証プロバイダおよびカスタムの認証ポリシー用IDアサーション・プロバイダ

- WebLogic Serverの資格証明プロバイダおよびマッパー

- WLS 9ポリシーのWebLogic Serverキーストアおよびトラストストア

- Oracle Web Services Managerエージェントによる認証およびIDアサーション

52.2 Oracle Service BusでのOracle Web Services Managerの使用

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

- Oracle Service BusサービスへのOracle Web Services Managerポリシーの付加

- SAMLの構成

- WS標準をサポートするためのWSDLファイルの通知

- デプロイメントに関する考慮事項

- 監査

- 統計の監視

- 事前定義済ポリシーとサポートされないアサーション

52.2.1 Oracle Service BusサービスへのOracle Web Services Managerポリシーの付加

OWSMポリシーは、Service Busの「ポリシー」ページで、次の種類のプロキシ・サービスおよびビジネス・サービスにアタッチできます。

- WSDL

- 任意のSOAP

- 任意のXML

- メッセージング

- REST

OWSMポリシーは、サービス・レベルでのみアタッチでき、サービスWSDLファイルに埋め込むことはできません。非SOAPサービスに対するポリシー・サポートは制限されることに注意してください。

開発環境でポリシーを付加する際は、開発環境のサービスがOracle Service Busコンソール内のサービスと同期化されていない可能性があることを念頭に置いて、JDeveloperからコンソールにサービスを更新するときに注意してください。サービスをコピーして同じタイプのサービスを作成する場合(たとえば、ビジネス・サービスをコピーして新しいビジネス・サービスを作成する場合)、必ず新しいサービスのOWSMポリシーを確認し、必要な調整を行ってください。

52.2.1.1 ポリシーのオーバーライド

OWSMポリシーをサービスに追加した後、「セキュリティ」ページでポリシーのオーバーライドを入力できます。使用されたポリシーについては、オーバーライド・キー(プロパティ)とそのデフォルト値がユーザー・インタフェースに表示されます。キー名はポリシーのバインディングから取得されます。可能な場合には、キーのデフォルト値の横にテキスト・ボックスが表示され、そこでオーバーライド値を入力できます。Service Busでは、CSFストアでユーザー資格証明を指定する、署名キー別名やCSFキーのようなよく知られているオーバーライド用のキーが提供されません。(Service Busでは、サービス・アカウントでユーザー資格証明が提供されます。)入力するオーバーライド・キーは、呼出しのときにOracle Web Services Managerエージェントに渡されます。

52.2.2 SAMLの構成

Service Busで使用するSAMLの構成の詳細は、「Oracle Service BusでのSAMLの使用」を参照してください。OWSMでのSAMLの構成の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のSAMLの構成に関する項を参照してください。

52.2.3 WS標準をサポートするためのWSDLファイルの通知

WSDLファイルに組込みOracle Web Service Managerポリシーが含まれるとき、Oracle Service BusおよびOracle SOA Suiteでサポートされている、次のポリシー標準と適合するようにポリシーを通知できます。

- WS-Policy 1.2(デフォルト)および1.5

- WS-Security Policy 1.1(デフォルト)、1.2および1.3

OWSMポリシーが組み込まれたWSDLファイルにアクセスする特殊な問合せパラメータをURLで使用することで、Service Busは必要な標準に適合するWSDLファイルを生成します。URLを使用したWSDLファイルへのアクセスの詳細は、「WebブラウザでのService Busリソースの表示」を参照してください。

注意:

この機能は、Service Busの「WSDLのエクスポート」または「WSDLの生成」機能では使用できません。

特殊な問合せパラメータは&wsp (WS-Policy)および&wssp (WS-Security Policy)で、WSDL、PROXY、およびWSDLファイルを取得するためのBIZ URLパターンと組み合せて使用できます。次に例を示します。

- http://localhost:7001/proxy/myProxy?WSDL&wsp=1.5&wssp=1.2
myProxyのWSDLファイル、つまりWSDLベースのプロキシ・サービスを返すことで、OWSMポリシー参照がWS-Policy 1.5およびWS-Security Policy 1.2に適合します。

注意:

前述のURLで、 /proxy/myProxyはプロキシ・サービスのエンドポイントURIを指します。

- http://localhost:7001/sbresource?PROXY/myProject/myProxy&wsp=1.5&wssp=1.2
myProxyのWSDLファイル、つまりWSDLベースのプロキシ・サービスを返すことで、OWSMポリシー参照がWS-Policy 1.5およびWS-Security Policy 1.2に適合します。

- http://localhost:7001/sbresource?BIZ/myProject/myBiz&wsp=1.5&wssp=1.3
myBizのWSDLファイル、つまりWSDLベースのビジネス・サービスを返すことで、OWSMポリシー参照がWS-Policy 1.5およびWS-Security Policy 1.3に適合します。

- http://localhost:7001/sbresource?WSDL/proxy/myProxy
myProxyのWSDLファイル、つまりWSDLベースのプロキシ・サービスを返すことで、OWSMポリシー参照がWS-Policy 1.2およびWS-Security Policy 1.1に適合します。問合せパラメータが使用されていないため、Service Busはデフォルトを使用します。

- http://localhost:7001/proxy/myProxy?WSDL&wssp=1.3
WS-Security Policy 1.3がWS-Policy 1.5のみと互換性があるため、myProxyのWSDLファイルが返され、OWSMポリシー参照がWS-Security Policy 1.3およびWS-Policy 1.5に適合します。

- 無効な値/組合せ
WS-Security Policy 1.2および1.3はWS-Policy 1.5のみと互換性があります。無効な値の例については、表52-1を参照してください。

ヒント:

Webブラウザで別のバージョンの問合せパラメータを試行して、返されるWSDLがどのように変わるかを参照してください。

問合せパラメータの組合せに関するクイック・リファレンスは、次の項の「WSポリシーのためのWSDL問合せパラメータ・リファレンス」を参照してください。

52.2.3.1 WSポリシーのためのWSDL問合せパラメータ・リファレンス

この項では、前の項の「WS標準をサポートするためのWSDLファイルの通知」で説明した&wspおよび&wssp問合せパラメータの、有効および無効な組合せを示すクイック・リファレンスを提供します。例では、?WSDLを使用してWSDLファイルを取得します。「WebブラウザでのService Busリソースの表示」の説明のとおり、WSDLファイル取得の?PROXYおよび?BIZの各メソッドも使用できます。

表52-1に示すように、パラメータが1つ以上省略される際、Service Busでは有効なデフォルトが提供されます。無効な値の例外の場合、WS-Security Policy 1.2および1.3はWS-Policy 1.5のみと互換性があり、その逆もまた同様です。

表52-1 &wspおよび&wsspの問合せパラメータの有効および無効な組合せ

問合せパラメータの組合せ

WS-Policyバージョン

WS-Security Policyバージョン

...?WSDL

1.2

1.1

...?WSDL&wsp=1.2

1.2

1.1

...?WSDL&wsp=1.5

1.5

1.3

...?WSDL&wssp=1.1

1.2

1.1

...?WSDL&wssp=1.2

1.5

1.2

...?WSDL&wssp=1.3

1.5

1.3

...?WSDL&wsp=1.2&wssp=1.1

1.2

1.1

...?WSDL&wsp=1.5&wssp=1.2

1.5

1.2

...?WSDL&wsp=1.5&wssp=1.3

1.5

1.3

...?WSDL&wsp=1.2&wssp=1.2

無効な値の例外

無効な値の例外

...?WSDL&wsp=1.2&wssp=1.3

無効な値の例外

無効な値の例外

...?WSDL&wsp=1.5&wssp=1.1

無効な値の例外

無効な値の例外

...?WSDL&wsp=3.0&wssp=1.2

無効な値の例外

無効な値の例外

...?WSDL&wsp=1.2&wssp=2.0

無効な値の例外

無効な値の例外

52.2.4 デプロイメントの考慮事項

OWSMポリシー参照を持ったサービスを含むService Busの構成をエクスポートする際は、参照が維持されます。参照されているポリシーが、対象の環境にも存在することを確認する必要があります。対象の環境がIDEの場合、ポリシーがパブリッシュ時に検証されるという警告が表示されます。

52.2.5 監査

Oracle Enterprise Managerのポリシー・イベントを監査するには、監査データのリポジトリおよびイベント・コレクションを設定する必要があります。詳細は、Webサービスの管理の次のトピックを参照してください。

- 「監査データ・コレクションおよびストレージ」

- 監査レポートの表示に関する項 - Oracle Business Intelligence Publisher内の事前定義されたOWSMの監査レポートには、Service Busの統計が含まれます。

次のポリシー・レベルのイベントを監査できます。

- ポリシーの作成、削除、変更

- アサーション・テンプレートの作成、削除、変更

52.2.6 統計のモニター

Fusion Middleware Controlを使用すると、ユーザーのService Busサービスに付加されたポリシーをモニターおよび管理できます(それらのサービスの使用状況メトリックと違反メトリックを含む)。また、ポリシー・セットをグローバルに付加し、ポリシーのオーバライドを定義して、ユーザーのサービスに対してポリシーをアタッチおよびデタッチすることもできます。これらのポリシーの監視と管理の詳細は、『Oracle Service Busの管理』のセキュリティ・ポリシーの監視と管理に関する項を参照してください。

Service Busは、WLS 9ポリシーの場合と同様に、OWSMポリシーの施行エラーについてWS-Securityエラーの統計を収集し、この統計は、Service Busサービスの監視ダッシュボードで利用できます。

52.2.7 事前定義済ポリシーとサポートされないアサーション

この項では、OWSMの事前定義済ポリシーとアサーション(Service Busでサポートされるものとサポートされないものがある)を示し、そのリンクが提供されます。カスタム・アサーションがサポートされます。

注意:

Oracle Enterprise Manager Fusion Middleware Controlのユーザー・インタフェースにおけるアサーションまたはポリシーの「有効化/無効化」オプションでは、アサーションまたはポリシーがService Busでサポートされているかどうかは判断されません。この項では、サポートされるポリシーとアサーションをリストします。

- 事前定義済ポリシー

- wss_http_token_*_policy Guidelines

- OWSM認証ポリシーのガイドライン

- OWSMポリシーおよびSOAP with Attachments (SwA)

- OWSMポリシーおよびMTOM形式のメッセージ

- サポートされないアサーション

52.2.7.1 事前定義済ポリシー

Service BusでサポートされるOWSMポリシーの詳細は、次のトピックを参照してください。

- SOAPサービス: Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の使用する事前定義済ポリシーの決定に関する項を参照してください。ここでは、現在のリリースで利用可能な事前定義済ポリシーに関する情報が提供されます。

- 非SOAPサービス: 表52-2を参照してください。この表では、HTTPトランスポートを使用するWSDL (非SOAP)サービス・タイプ、XMLサービス・タイプまたはメッセージング・サービス・タイプで構成されたビジネス・サービスおよびプロキシ・サービスについて、サポートされるOWSM事前定義済ポリシーを示しています。ユーザー定義のポリシーもサポートされます。

- RESTサービス: Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のRESTful WebサービスおよびクライアントでサポートされるOWSMポリシーに関する項を参照してください。ここでは、RESTサービス・タイプで構成されるサービスのサポート対象のOWSM事前定義済ポリシーが示されます。

- JCAサービス: Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のJCAアダプタでサポートされているOWSMポリシーに関する項を参照してください。

注意:

開発環境でサポートされていないシード・ポリシーを使用すると次のようになります。

- 開発環境で生成された有効なWSDLファイルは、サポートされていないポリシーをスキップします。

- 検証はサービス・パブリッシュ時に実行されます。

次のポリシーの詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の事前定義済ポリシーに関する項を参照してください。

表52-2 HTTPトランスポートを使用するWSDL (非SOAP)、XMLおよびメッセージングの各サービス・タイプでサポートされるOWSM事前定義済ポリシー

タイプ

クライアント・ポリシー

サービス・ポリシー

認証のみ

oracle/wss_http_token_client_policy

Basic認証専用。

このポリシーの詳細は、「wss_http_token_*_policyのガイドライン」および「OWSM認証ポリシーのガイドライン」を参照してください。

oracle/wss_http_token_service_policy

Basic認証専用。

このポリシーの詳細は、「wss_http_token_*_policyのガイドライン」および「OWSM認証ポリシーのガイドライン」を参照してください。

認証およびメッセージ保護

oracle/wss_http_token_over_ssl_client_policy

このポリシーの詳細は、「wss_http_token_*_policyのガイドライン」および「OWSM認証ポリシーのガイドライン」を参照してください。

oracle/wss_http_token_over_ssl_service_policy

このポリシーの詳細は、「wss_http_token_*_policyのガイドライン」および「OWSM認証ポリシーのガイドライン」を参照してください。

認可専用

N/A

oracle/whitelist_authorization_policy

認可専用

N/A

oracle/binding_authorization_denyall_policy

認可専用

N/A

oracle/binding_authorization_permitall_policy

信頼できるメッセージング

N/A

oracle/reliable_messaging_policy

注意: このポリシーはWSDLサービス・タイプのHTTPトランスポート・サービスでのみサポートされています。このポリシーをアタッチするときには、oracle/reliable_messaging_internal_api_policyもアタッチする必要があります。

信頼できるメッセージング

N/A

oracle/reliable_messaging_internal_api_policy

注意: このポリシーはWSDLサービス・タイプのHTTPトランスポート・サービスでのみサポートされています。このポリシーをアタッチするときには、oracle/reliable_messaging_policyもアタッチする必要があります。

52.2.7.2 wss_http_token_*_policyのガイドライン

この項では、Service Busでwss_http_tokenポリシーを使用する場合のガイドラインを提供します。

注意:

OWSMポリシーとともにHTTPトランスポートを使用する場合は、トランスポートの「認証」プロパティを「なし」に設定します。これ以外の値に設定すると、OWSMポリシーと競合します。

OWSMのポリシーで特定のオプションを有効にする場合、一定のガイドラインが適用されます。オプションは次のとおりです。

- 認証モード – OWSMおよびService Busでは、ポリシーの「基本」認証モードのみがサポートされます。他のモードではすべて例外が発生します。

- トランスポート・セキュリティ - このオプションは、SSLチャネルで呼出しを実行する必要があることを示します。実行時は、次に従います。

- プロキシ・サービス: ポリシーでこのオプションを有効にする場合、ポリシーを含むプロキシ・サービスで「HTTPSが必要」オプションを有効にする必要があります。

- ビジネス・サービス: ポリシーでこのオプションを有効にするとビジネス・サービス構成で検証は発生しないため、ビジネス・サービス・エンドポイントのアドレスで必ずHTTPSを使用してください。エンドポイントでHTTPSを使用しないと、ランタイム・エラーがスローされます。

- 相互認証が必要 - このオプションは双方向SSLを示します。

- プロキシ・サービス: このオプションは、プロキシ・サービスでは使用できません。OWSMにより提供されるwss_*_over_ssl_* _policyポリシーを使用する場合、このオプションは消去してください。

- ビジネス・サービス: このオプションは、アウトバウンド・メッセージではOWSMに無視されるため、ビジネス・サービスとともに使用しても効果はありません。

- タイムスタンプを含める - このオプションは、SOAPヘッダーにタイムスタンプを強制的に含めます。

- プロキシ・サービス: このオプションをプロキシ・サービスで有効化すると、OWSMによって、SOAPヘッダーのタイムスタンプが利用可能で有効であることが保証されます。

- ビジネス・サービス: ビジネス・サービスでこのオプションを有効にすると、OWSMによって、タイムスタンプがまだ存在しない場合にSOAPヘッダーにタイムスタンプが追加されます。

注意:

HTTPトランスポートで非SOAPのサービス・タイプを使用するプロキシ・サービスおよびビジネス・サービスにwss_http_tokenポリシーを適用する場合は、OWSMポリシーの「タイムスタンプを含める」オプションを無効にする必要があります。

52.2.7.3 OWSM認証ポリシーのガイドライン

Service Busサービスでwss_http_token_over_ssl_client_policyやwss_username_token_over_ssl_client_policyなどのトークン・トランスポート・ポリシーを使用する場合、サービスのトランスポート構成ページで「認証」プロパティを「なし」に設定します。OWSMトークン・ポリシーを使用するか、またはトランスポートを通じて認証を処理できます(両方は実行できません)。

52.2.7.4 OWSMポリシーおよびSOAP with Attachments (SwA)

サポートされる任意のOWSMポリシーを、SOAP with Attachments (SwA)がサポートされるプロキシ・サービスおよびビジネス・サービスにアタッチできます。メッセージ本文の保護に加えて、メッセージ保護ポリシーにメッセージの署名またはメッセージの暗号化のためのSwA添付ファイルとMIMEヘッダーを含むように構成できます。

52.2.7.5 OWSMポリシーおよびMTOM形式のメッセージ

OWSMポリシーを、MTOM形式のSOAPメッセージがサポートされ、HTTP、ローカルまたはSBトランスポートを使用するプロキシ・サービスおよびビジネス・サービスに付加できます。サポートされるすべてのポリシーのメッセージ処理は、メッセージ保護ポリシーを除いて、MTOM形式のSOAPメッセージと他のすべてのSOAPメッセージで同じです。

メッセージ本文の任意の部分を暗号化するメッセージ保護ポリシーでは、復号化される前に、受信メッセージの<xop:Include>要素がインラインで埋め込まれます。復号化時に、<xop:Include>要素は、データのbase64Binary表現で置き換えられます。メッセージ・コンテンツは変更されません。

注意:

MTOM形式のメッセージをサポートするサービスにOWSMポリシーを適用する場合:

- プロキシ・サービスの場合は、同等のクライアント・ポリシーを使用して、着信メッセージが最初に暗号化される必要があります。

- サービスを構成する際は、トランスポートの「認証」プロパティを「なし」に設定します。これ以外の値に設定すると、OWSMポリシーと競合します。

52.2.7.6 OWSMポリシーを使用したWS-ReliableMessagingのサポート

Service Busでは、Oracle Web Services Managerポリシーoracle/reliable_messaging_policyおよびoracle/reliable_messaging_internal_api_policyをアタッチすることによって、WSDLサービス・タイプのHTTPトランスポート・サービスでWS-ReliableMessaging (WS-RM)をサポートしています。

このトピックでは、サポートされている機能、およびサポートされていない機能について説明します。

サポートされている機能

- WS-RM 1.0、1.1、および1.2のサポート

- 一方向のWS-RMのサポート

- 同期WS-RM (匿名ReplyTo)のサポート

- サービス品質(QoS):

- AtLeastOnce

- ExactlyOnce

- AtMostOnce

サポートされていない機能

- 非HTTPトランスポート・サービスはサポートされていません。

- 非同期WS-RM (非匿名ReplyTo)はサポートされていません。

その他の注意事項

- oracle/reliable_messaging_policyをサービスにアタッチする場合は、常にoracle/reliable_messaging_internal_api_policyもアタッチする必要があります。両方が追加されていない場合は、エラーがスローされます。

- 同期WS-RMシナリオでは、レスポンス・メッセージが確実に送信されなくてもかまいません。一部のシナリオでは、リクエスト・メッセージはサービスによって確実に処理されますが、クライアントがレスポンスを受信しない場合があります。

- WS-RMポリシーがアタッチされているHTTPプロキシ・サービスは、次の場合のみ、WS-RMポリシーがアタッチされているHTTPビジネス・サービスを呼び出します。

- ビジネス・サービスが、WS-RM対応プロキシ・サービスによってターゲットに設定されているパイプラインのルート・ノードである場合

- ビジネス・サービスがプロキシ・サービスのターゲット・サービスである場合

52.2.7.6.1 WS-RMポリシーを使用したプロキシ・サービスについて

OWSMポリシーoracle/reliable_messaging_ policyおよびoracle/reliable_messaging_internal_api_policyをプロキシ・サービスにアタッチし、そのサービスのWS-RMを有効にします。「Oracle Service BusサービスへのOracle Web Services Managerポリシーの付加」を参照してください。

WS-RMポリシーがアタッチされているHTTPプロキシ・サービスは次のとおりです。

- トランザクション

- 非同期

WS-RMスタックでは、シーケンスのQualityOfServiceがAtMostOnceまたはExactlyOnceとしてポリシーに設定されている場合のみトランザクションを開始します。「ルーティング」オプションの「サービス品質」(QoS)は、ポリシーにAtMostOnceまたはExactlyOnceとしてシーケンスQualityofServiceが含まれている場合にのみ、ExactlyOnceに設定されます。

一方向および同期リクエスト・メッセージの両方について、リクエスト・パス処理が完了した後、メッセージ確認がWS-RMスタックに通知されます。リクエスト・パスでエラーが発生した場合、WS-RMスタックにエラーが通知され、リクエスト・メッセージは未処理とみなされます。これはポリシーの再試行構成に応じて再試行されます。

52.2.7.6.2 WS-RMポリシーを使用したビジネス・サービスについて

OWSMポリシーoracle/reliable_messaging_ policyおよびoracle/reliable_messaging_internal_api_policyをビジネス・サービスにアタッチし、そのサービスのWS-RMを有効にします。「Oracle Service BusサービスへのOracle Web Services Managerポリシーの付加」を参照してください。

WS-RMポリシーがアタッチされているHTTPビジネス・サービスは次のとおりです。

- トランザクション

- 非同期

WS-RMポリシーがアタッチされているビジネス・サービスがトランザクション内でリクエスト・メッセージを受信すると、そのトランザクションはWS-RM処理に進む前に中断されます。トランザクションは、ターゲット・サービスから完了確認を受信した場合のみコミットします。

トランザクションは、次の場合にロールバック対象としてマークされます。

- WS-RMスタックが確認を受信しない場合、または処理中にメッセージがタイムアウトした場合

- ターゲット・サービスからWS-RM処理に関するフォルトを受信した場合。

WS-RMスタックのエラーによってリクエスト・メッセージを処理できない場合、フォルトが生成され、それがレスポンスとして送信されます。

52.2.7.6.3 エンドツーエンド・メッセージの信頼性

エンドツーエンド・メッセージの信頼性は、次のいずれかのシナリオを使用して実現できます。

エンドツーエンドの信頼性は、次のシナリオでサポートされています。

- WS-RMアウトバウンドへの非同期プロキシ・サービス

- WS-RMアウトバウンドへのWS-RMインバウンドは、次の構成でサポートされています。

- WS-RMインバウンドに、WS-RMアウトバウンドのターゲット・サービスがある

- WS-RMインバウンドが、WS-RMアウトバウンドへルーティングするパイプラインにターゲット設定されている

52.2.7.6.4 WS-RM相互運用性

Service Busを仲介した次の相互作用がサポートされています。

- SOA Suite 12.2.1 / WebLogic Server < --- > Service Bus < ---- > WS-RM以外のサービス

- WS-RM以外のクライアント < --- > Service Bus < ---- > Oracle SOA Suite 12.2.1 / WebLogic Server

- Oracle SOA Suite 12.2.1 / WebLogic Server < --- > Service Bus < ---- > Oracle SOA Suite 12.2.1 / WebLogic Server

52.2.7.6.5 WS-RMサブシステムのチューニング

OWSMポリシーoracle/reliable_messaging_policyおよびoracle/reliable_messaging_internal_api_policyに対してプロパティを構成すると、パフォーマンスを改善できます。

それぞれのポリシーに対して構成できるプロパティの完全なリストについては、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のoracle/reliable_messaging_policy、およびoracle/reliable_messaging_internal_api_policyを参照してください。

- oracle/reliable_messaging_internal_api_policyのuser.transaction.timeoutプロパティを使用して、適切なトランザクション・タイムアウトを構成します。

- oracle/reliable_messaging_internal_api_policyのsequence.manager.maintenance.periodプロパティを使用して、孤立したメッセージについて、データベース表に格納されているデータをパージするメンテナンス・タスク用に、間隔(ミリ秒)を構成します。

- oracle/reliable_messaging_internal_api_policyのmax.concurrent.sessionプロパティを使用して、WSエンドポイント専用のシーケンス・マネージャが、シーケンス作成の新規リクエストを拒否するまでに、同時にアクティブなWS-RMセッション(インバウンドWS-RMシーケンスに基づいて測定)をいくつ受け入れるかを指定します。

52.2.7.6.5.1 oracle/reliable_messaging_internal_api_policy

次のプロパティを構成すると、oracle/reliable_messaging_policyでのサービス・パフォーマンスをチューニングできます

表52-3 oracle/reliable_messaging_internal_api_policyプロパティ

名前

説明

デフォルト

必須かどうか

sequence.manager.maintenance.period

シーケンス・マネージャ・メンテナンス・タスクの実行期間(ミリ秒)を指定します。

60000

オプション

max.concurrent.session

WSエンドポイント専用のシーケンス・マネージャが、シーケンス作成の新規リクエスト拒否を開始するまでに、同時にアクティブなRMセッション(インバウンドRMシーケンスに基づいて測定)をいくつ受け入れるかを指定します。

100

オプション

user.transaction.timeout

プロキシ・サービスによって開始したXAトランザクションのトランザクション・タイムアウト。

デフォルト値0では、システム・デフォルトを使用します。

0

オプション

reference.priority

詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のreference.priorityに関する項を参照してください。

なし

オプション

52.2.7.7 サポートされないアサーション

表52-4は、SOAPおよび非SOAPサービス両方でのサポートされないOWSMアサーションの一覧であり、アサーションを含むポリシーを示し、影響を受ける機能とその機能を実現するための代替方法について説明しています。

表52-4 サポートされないアサーション

サポートされないアサーション

アサーションを含むOWSMポリシー

影響を受ける機能と代替方法

binding-permission-authorization

oracle/binding_permission_authorization_policy

サービスに対する許可ベースのアクセス制御。

代替方法: XACML認可ポリシーを使用します。

OptimizedMimeSerialization (MTOM)

oracle/wsmtom_policy

MTOM

代替方法: プロキシ・サービスまたはビジネス・サービスで直接MTOM構成を使用します。

RMAssertion

oracle/wsrm10_policy

oracle/wsrm11_policy

WS-RM 1.0/1.1/1.2

代替: WS-RM 1.0/1.1/1.2のService Busで直接WSトランスポートを使用するか、oracle/reliable_messaging_ policyおよびoracle/reliable_messaging_internal_api_policyをWSDLタイプのHTTPトランスポート・サービスにアタッチします。

sca-component-authorization

oracle/component_authorization_denyall_policy

oracle/component_authorization_permitall_policy

コンポーネントにアクセスするすべてを拒否または許可するロール・ベースのアクセス制御。

代替方法: 使用できません。

sca-component-permission-authorization

oracle/component_permission_authorization_policy

コンポーネントに対する許可ベースのアクセス制御

代替方法: 使用できません。

UsingAddressing

oracle/wsaddr_policy

WS-Addressingが要件

代替方法: SOA-DIRECTトランスポートを使用するビジネス・サービスでWS-Addressingを構成するか、Service BusパイプラインのメッセージにWS-Addressingを追加します。

52.2.8 カスタム・アサーション

Oracle Service Busでは、事前定義済ポリシーのセット、およびOWSMで配信されるアサーション・テンプレートの実行がサポートされます。製品で利用できる標準ポリシーで特定の機能が提供されない場合、ユーザーはカスタム・アサーションを開発できます。

カスタム・アサーションの詳細は、Oracle Web Services Managerの拡張可能アプリケーションの開発のカスタム・アサーションについてに関する項を参照してください。

カスタム・アサーションの作成の詳細は、Oracle Web Services Managerの拡張可能アプリケーションの開発のカスタム・アサーションの作成に関する項を参照してください。

52.3 OAuthを使用したRESTエンドポイントによるサービスの保護

Service Bus 12.2.1以降、OAuth OWSMポリシーをアタッチすることにより、RESTエンドポイントでサービスを保護できるようになりました。

このセクションのトピックでは、Service BusでOAuthを使用するために、OAuthサーバーおよびOWSMの構成に必要な、サポートされているユースケースと手順について説明します。

Service Busの今回のリリースでは、OAuth2のみサポートされています。

52.3.1 サポートされているOAuthユースケース

Service Busの今回のリリースでは、2–legged OAuthユースケースをサポートしています。次の2–legged OAuthユースケース(クライアント認証、およびクライアント + ユーザー認証)がサポートされています。

- クライアント認証:

- クライアント資格証明 - 認証HTTPヘッダーのAppIDユーザー名およびパスワード(federated=false) (SSL付き/SSLなし)

- クライアント資格証明 - JWT (JSON Webトークン)  (federated=true) (SSL付き/SSLなし)

注意:

federated=trueの場合、JWTトークンがクライアント資格証明用に作成されます。この値はOWSM OAuthポリシーで変更できます。

- クライアント + ユーザー認証

- クライアント資格証明 - 認証HTTPヘッダーのAppIDユーザー名とパスワード + ユーザー資格証明(federated=false) (SSL付き/SSLなし)

- クライアント・アイデンティティ – JWT + ユーザー・アイデンティティ – JWT (federated=true)  (SSL付き/SSLなし)

2–legged OAuthの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の2-legged OAuthの理解に関する項を参照してください。

52.3.2 Service BusでOAuthを使用するためのOracle Access Managementの構成

Service BusでOAuthポリシーを使用してRESTエンドポイントを保護するには、OWSMおよびOAuthサーバーを構成する必要があります。

トピック

注意:

このセクションでは、サンプルOAuthサーバーの構成に必要な手順を記載しています。これらのタスクに示す構成は、すべてのデプロイメント・シナリオに適用されるわけではありません。OAuthサーバーの構成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOAuthサービスの構成に関する項を参照してください

- OAuthサーバーの構成

- OWSMの構成

52.3.2.1 OAuthサーバーの構成

OAuthサーバーを構成するには、次のタスクを完了する必要があります。

トピック

注意:

このセクションでは、サンプルOAuthサーバーの構成に必要な手順を記載しています。これらのタスクに示す構成は、すべてのデプロイメント・シナリオに適用されるわけではありません。OAuthサーバーの構成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOAuthサービスの構成に関する項を参照してください。

- Oracle Access ManagementでのOAuthの有効化

- IDMコンソールを使用した認可RESTコールバック・プラグイン・プロファイルの作成

- IDM OAuthコンソールを使用したリソース・サーバー・プロファイルの作成

- OAuth OWSMクライアント・プロファイルの作成

- OAuthサーバー・プロファイル構成の更新

- 証明書のインポートとエクスポート

52.3.2.1.1 Oracle Access ManagementでのOAuthの有効化

OAuthサーバーを構成するには、OAuthをOracle Access Managementに対して有効にしておく必要があります。これはOracle Access ManagementコンソールでAccess ManagerサービスおよびMobile and Socialサービスを有効にして実行します。

OAuthを有効にするには、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の使用可能なサービスの有効化または無効化に関する項に示すとおり、Access ManagerおよびMobile and Socialサービスが有効化されていることを確認します。

このタスクを完了した後は、「IDMコンソールを使用した認可RESTコールバック・プラグイン・プロファイルの作成」に示すタスクを実行します。

52.3.2.1.2 IDMコンソールを使用した認可RESTコールバック・プラグイン・プロファイルの作成

このタスクを実行する前に、「IDMでのOAuthの有効化」に示すタスクを完了しておく必要があります。

IDMコンソールを使用して認可RESTコールバック・プラグイン・プロファイルを作成するには:

1. 『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の新しいプラグインの作成に関する項に示すとおり、プラグインを作成します。

2. 『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のプラグイン構成ページの理解に関する項に示すとおり、次の構成のいずれかに従ってプラグインを構成します。

オプション

説明

粗密(推奨)

次のフィールドを変更します。

- 名前: PermissionRESTPluginと入力します。

- 説明: Permission Authorization REST Coherence Pluginまたは別の関連する説明を入力します。

- 実装クラス: oracle.security.idaas.oauth.consent.impl.CoherenceAuthorizationUserConsentImplを選択します。

ファイングレイン

次のフィールドを変更します。

- 名前: PermissionRESTPluginと入力します。

- 説明: Permission Authorization REST Coherence Pluginまたは別の関連する説明を入力します。

- 実装クラス: oracle.security.idaas.oauth.consent.impl.CoherenceAuthorizationUserConsentImplを選択します。

- 属性rest.permission.service.endpoint=http://example.com:8001/ras/api/public/auth/get_permissiontokenを属性表に追加します。

このタスクを完了した後は、「IDM OAuthコンソールを使用したリソース・サーバー・プロファイルの作成」に示すタスクを実行します。

52.3.2.1.3 IDM OAuthコンソールを使用したリソース・サーバー・プロファイルの作成

このタスクを実行する前に、「IDMコンソールを使用した認可RESTコールバック・プラグイン・プロファイルの作成」に示すタスクを実行しておく必要があります。

IDM OAuthコンソールを使用してリソース・サーバー・プロファイルを作成するには:

1. 『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のカスタム・リソース・サーバーの作成に関する項に示すタスクを実行し、カスタム・リソース・サーバーを作成します。
「カスタム・リソース・サーバー構成」ページが開きます。

2. 「カスタム・リソース・サーバー構成」では、次のプロパティを構成します。

注意:

これらの値は、ユーザー環境の構成に応じて異なる場合があります。

a. 「追加」フィールドに、docServiceInstance1と入力します。

b. 「認可および承認サービス・プラグイン」メニューから、PermissionRESTPluginを選択します。

c. 「追加」をクリックして新しいスコープを追加します。

d. スコープの「名前」に、docServiceInstance1.ALLと入力します。

e. スコープの「説明」に、Default Scopeと入力します。

f. 「ユーザー承認が必要」オプションが選択されていないことを確認します。

このページのオプションの詳細は、「カスタム・リソース・サーバーの構成ページの理解」を参照してください。

3. 「作成」をクリックします。

このタスクを完了した後は、「OAuth OWSMクライアント・プロファイルの作成」に示すタスクを実行します。

52.3.2.1.4 OAuth OWSMクライアント・プロファイルの作成

このタスクを実行する前に、「IDM OAuthコンソールを使用したリソース・サーバー・プロファイルの作成」に示すタスクを実行しておく必要があります。

OAuth OWSMクライアント・プロファイルを作成するには:

1. 『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のクライアントの作成に関する項に示すタスクを実行し、OAuthサービスWebクライアントを作成します。

ヒント:

「OAuth Webクライアント」見出しで「作成」をクリックします。

2. Webクライアント構成ページで、次のプロパティを構成します。

注意:

これらの値は、ユーザー環境の構成に応じて異なる場合があります。

a. 「名前」フィールドにOWSM Clientと入力します。

b. 「クライアントID」フィールドに、OWSMClientIdと入力します。

c. 値を「クライアント・シークレット」フィールドに入力します。

d. 「許可されているスコープ」から、「追加」をクリックします。

e. ドロップダウン・リストから「docServiceInstance1.ALL」を選択します。

f. 「権限タイプ」から、「クライアント資格証明」、「JWTベアラー」、「認可コード」(3–legged OAuth用)、および「リフレッシュ・トークン」(3–legged OAuth用)の認可付与タイプが選択されていることを確認します。
このページのオプションの詳細は、「Webクライアントの構成ページの理解」を参照してください。

3. 「作成」をクリックします。

このタスクを完了した後は、「OAuthサーバー・プロファイル構成の更新」に示すタスクを実行します。

52.3.2.1.5 OAuthサーバー・プロファイル構成の更新

このタスクを実行する前に、「OAuth OWSMクライアント・プロファイルの作成」に示すタスクを実行しておく必要があります。

OAuthサーバー・プロファイル構成を更新するには:

1. 『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のサービス・プロファイルの編集または削除に関する項に示すタスクのとおり、OAuthServiceProfileを編集します。

2. 「サービス・プロファイル構成」ページで、「属性」表に次のプロパティを構成します。

a. jwt.issuerプロパティを更新します。jwt.issuer=www.example.com

b. jwt.CryptoSchemeプロパティを更新します。jwt.CryptoScheme=RS256

c. 新規のプロパティを追加します。jwt.trusted.issuer.size=1

d. 新規のプロパティを追加します。jwt.trusted.issue.1=http://www.example.com

3. 変更を保存します。

このタスクを完了した後は、「証明書のインポートとエクスポート」に示すタスクを実行します。

52.3.2.1.6 証明書のインポートとエクスポート

このタスクを実行する前に、「OAuthサーバー・プロファイルの更新」に示すタスクを実行しておく必要があります。

必要な証明書をインポートおよびエクスポートするには:

1. OAuthサーバーから、次のWSLTコマンドを実行して、OAuthキーストアのパスワードを取得します。listCred(map="oracle.wsm.security",key="keystore-csf-key")

2. OAuth構成の場所から、次のコマンドを実行してOAuth証明書をエクスポートします。keytool -exportcert -keystore default-keystore.jks -alias orakey -file oauth-key.pem -rfc

3. OWSM構成の場所から、次のコマンドを実行して、別名をorakeyからowsmkey<unique-ending>に変更します。keytool -changealias -alias orakey -destalias owsmkey<unique-ending> -keystore default-keystore.jks

4. OWSM構成の場所から、次のコマンドを実行してOWSM証明書をエクスポートします。 keytool -exportcert -keystore default-keystore.jks -alias owsmkey<unique-ending> -file owsmkey<unique-ending>.cer

5. OAuth構成の場所から、次のコマンドを実行してOWSM証明書をOAuthキーストアにインポートします。keytool -importcert -file owsmkey<unique-ending>.cer -keystore default-keystore.jks -alias owsmkey<unique-ending>

6. OWSM構成の場所から、次のコマンドを実行してOAuth証明書をOWSMキーストアにインポートします。keytool -importcert -file oauth-key.pem -keystore default-keystore.jks -alias orakey

このタスクを完了した後は、「OWSMの構成」に示すタスクを実行します。

52.3.2.2 OWSMの構成

このタスクを実行する前に、「証明書のインポートとエクスポート」に示すタスクを完了しておく必要があります

OWSMを構成するには:

1. 「OAuth OWSMクライアント・プロファイルの作成」で構成した「クライアントID」(ユーザー名)および「クライアント・シークレット」(パスワード)と同じユーザー名とパスワードでユーザーを作成します。

2. OWSMサーバーで次のWLSTコマンドを実行します。

- deleteCred(map="oracle.wsm.security", key="basic.client.credentials")

- createCred(map="oracle.wsm.security", key="basic.client.credentials", user="OWSMClientId", password="password")

3. 「証明書のインポートとエクスポート」の手順2で作成したOAuth証明書をOWSMサーバーにインポートします。

4. RESTプロキシ・サービスを作成します。

5. RESTビジネス・サービスを作成します。

52.3.3 Service BusサービスへのOAuth OWSMポリシーのアタッチ

OAuth OWSMポリシーは、任意のOWSMポリシーをService Busサービスにアタッチしたときと同じ方法でビジネス・サービスおよびプロキシ・サービスにアタッチします。

JDeveloperおよびService Busコンソールを使用したポリシーのサービスへのアタッチについては、「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。

oracle/http_jwt_token_service_policyまたはoracle/http_jwt_token_over_ssl_service_policyポリシーは、プロキシ・サービスにアタッチでき、oracle/oauth2_config_client_policy (OAuthトークンの取得元となるRESTエンドポイントを指定)およびoracle/http_oauth2_token_client_policyまたはoracle/http_oauth2_token_over_ssl_client_policyポリシーは、ビジネス・サービスにアタッチできます。

53 WS-PolicyによるOracle Service Busプロキシ・サービスおよびビジネス・サービスの保護

この章では、Service BusでWebLogic Serverのセキュリティ・ポリシーを使用する方法について説明します。

注意:

この章は主にWLS 9ポリシーに適用され、Oracle Web Services Manager (OWSM)ポリシーは対象ではありません。WLSポリシーは、このリリースで非推奨になったため、OWSMポリシーで置き換えられます。WLS9ポリシーがアタッチされているサービスをインポートできますが、新しいサービスにはOWSMポリシーのみを使用できます。

Webサービスであるプロキシ・サービスまたはビジネス・サービスのメッセージ・レベルのセキュリティ要件を指定するには、Webサービス・ポリシー(WS-Policy)フレームワークを使用します。

次の項では、プロキシ・サービスとビジネス・サービスのWS-Policyの構成について説明します。

- Webサービス・ポリシーについて

- Oracle独自のセキュリティ・ポリシーのベスト・プラクティス

- ポリシー・サブジェクトと有効ポリシー

53.1 Webサービス・ポリシーについて

Webサービス・ポリシー(WS-Policy)は、Webサービスの制約と要件を定義するための標準ベースのフレームワークです。それは、それぞれ1つまたは複数のアサーションを含む、ポリシーと呼ばれるXML文の集合で制約と要件を表します。

Service Busでは、WS-Policyアサーションを使用して、デジタル署名や暗号化に対するWebサービスの要件、および必要なセキュリティ・アルゴリズムや認証メカニズムを指定します。

WS-Policyフレームワークを使用すると、他の仕様で「ポリシー・アサーション」を宣言できます。ポリシー・アサーションは、<policy>要素内に示されるドメイン固有のXML要素です。ポリシー・アサーションの仕様は、このドメイン固有のアサーションの構文とセマンティクスを記述します。

WS-SecurityPolicyは、ドメイン固有のアサーション言語の一例です。WS-SecurityPolicy仕様は、WS-Policyフレームワークで使用する一連のセキュリティ・ポリシー・アサーションを定義しています。

WS-ReliableMessagingは、ドメイン固有のアサーション言語のもう1つの例であり、信頼性のあるメッセージング・ポリシーを宣言するためのアサーションを定義しています。

53.1.1 WS-SecurityとWS-Policyの関係

Webサービス・セキュリティ(WS-Security)は、Webサービス・ポリシー・フレームワーク(WS-Policy)と連動して機能します。次の用語の意味とこれらがどのように関係するのかを理解することが重要です。

- Webサービス・セキュリティ(WS-Security)はOASIS標準の1つです。SOAPメッセージにメッセージ・レベルのセキュリティを組み込むための相互運用可能なメカニズムを定義しています。WS-Securityによって、メッセージ・レベルのセキュリティが「どのように」 SOAPメッセージに組み込まれるかが決まります。
WS-Securityは、メッセージの整合性と機密性をサポートします。また、SOAPエンベロープにセキュリティ・トークンを含める拡張モデルや、SOAPエンベロープ内からセキュリティ・トークンを参照するモデルも定義しています。WS-Securityでは、SOAPメッセージのどの部分をデジタル署名または暗号化するかを指定できます。

- Webサービス・ポリシー・フレームワーク(WS-Policy)は、Webサービスのポリシーを記述して通信するための汎用モデルとその構文を提供します。WS-Policyは、抽象XMLフレームワークです。WS-Policyの特徴は、ポリシー「アサーション」と呼ばれる子要素です。

- WS-SecurityPolicyは、WS-Policyのセキュリティ面を指定するためのアサーションを定義します。WS-SecurityPolicyは、SOAPメッセージで「どの」メッセージ・レベルのセキュリティが必要かを決定します。
ポリシーでは、セキュリティで保護する操作と、Webサービス・クライアントが適用する必要があるセキュリティ対策を決定できます。

プロキシ・サービスまたはビジネス・サービスのWS-Policyを構成するときに、WS-Policyに1つまたは複数のセキュリティ・ポリシー・アサーションが含まれている場合、プロキシ・サービスまたはビジネス・サービスは、WS-Securityが有効になっていると見なされます。

53.1.2 抽象および具象WS-Policy文

WS-Policy仕様に基づいて(Oracle独自のセキュリティ・ポリシー・スキーマを使用して)記述されたセキュリティ・ポリシー・アサーションの場合、WebLogic Webサービス実行時環境では、2つのタイプのWS-Policy文を認識します。

- 具象WS-Policy文では、認証、暗号化、およびデジタル署名のために使用されるセキュリティ・トークンを指定します。具象暗号化ポリシーでは、必ず、サーバーの暗号化証明書が、base 64でエンコードされた証明書の形式でX.509バイナリ・セキュリティ・トークンに組み込まれます。
必要な認証のタイプ(X.509またはSAMLトークンの使用など)が設計時にわかっている場合は、具象WS-Policy文を作成できます。

- 抽象WS-Policy文では、セキュリティ・トークンを指定しません。具体的には、WS-Policyファイルの<Identity>要素や<Integrity>要素(またはアサーション)に<SupportedTokens><SecurityToken>子要素が含まれないこと、およびWS-Policyファイルの<Confidentiality>要素に<KeyInfo><SecurityToken>子要素が含まれないことです。
抽象ポリシーが受け取るセキュリティ・トークンのタイプは、Service Busの実行時環境で決定します。

53.2 Oracle独自のセキュリティ・ポリシーのベスト・プラクティス

この項では、WS-Policy仕様に基づき、Oracle独自のセキュリティ・ポリシー・スキーマを使用して記述されたセキュリティ・ポリシー・アサーションを使用する際に考慮すべきベスト・プラクティスについて説明します。

注意:

WS-SecurityPolicyを設計する前に、セキュリティ要件を入念に分析してください。このベスト・プラクティスは、特定のビジネス・セキュリティのニーズには当てはまらない可能性もあります。

- 操作のレスポンス・ポリシーでは、IDアサーションを使用しないでください。結果として、レスポンス・ポリシーでは、定義済のAuth.xmlポリシーを使用しないでください。
アクティブな仲介プロキシ・サービスに対してインバウンドでWS-Securityユーザー名トークンを使用する場合、ユーザー名/パスワードをバックエンド・サービスに渡すと(ユーザー名/パスワードのパススルー)、ユーザー名トークンには、パスワードをクリア・テキストで含める必要があります。

- WS-Securityのユーザー名トークンをクリア・テキストのパスワードで使用する場合、必ずトークン全体を(WS-Securityで)暗号化するか、メッセージをSSLで送信して、ユーザー名トークンの機密性を保護することを強くお薦めします。

- IDアサーションを使用する場合は、Integrityアサーションを使用して、機密メッセージ・コンテンツ(SOAP本体およびSOAPヘッダー部分)とともに、認証トークン(ユーザー名、X.509またはSAMLトークン)にデジタル署名することもできます。デジタル署名は、署名されたコンテンツの整合性を保護し、認証トークンとメッセージ・コンテンツをバインドします。これは、第三者による認証トークンの任意のSOAPエンベロープへのコピーと、それによるメッセージの偽造を防止するために重要です(Integrityアサーションを使用する代わりに、SSLを使用してメッセージを送信することもできます)。

- Integrityアサーションを使用する場合は、MessageAgeアサーションも使用してください。また、署名トークン(つまり検証証明書)をwsse:Securityヘッダーに含めること、およびデジタル署名で、署名するSOAP本体またはSOAPヘッダー部分に加えて、署名トークンおよびタイムスタンプを対象とすることもお薦めします。MessageAgeアサーションは、タイムスタンプがセキュリティ・ヘッダーに含まれることを保証します。タイムスタンプは、反射攻撃の防止に使用されます。定義済のSign.xmlポリシーは、このベスト・プラクティスに従っています。

- JMSでタイム・スタンプを使用する場合は(MessageAgeアサーション)、MessageAgeアサーションの有効期限を適切に設定するようにしてください。値が小さ過ぎると、キューに置かれている間にメッセージが有効期限切れになる可能性があります。

- IDアサーションで、X.509トークンをサポートされるトークン・リストに含める場合は、ポリシーにもIntegrityアサーションを含める必要があります。X.509トークンがデジタル署名で使用されていない場合、サーバーはX.509トークンを認証の証拠として受け入れません。
IDアサーションがその他のトークン・タイプを受け入れる場合、IntegrityアサーションのX509AuthConditional属性を使用して、実際の認証トークンがX.509トークンの場合のみ、デジタル署名を必要とすることを指定できます。抽象IDアサーションは、デプロイ時にあらかじめ処理されており、実行時環境によってサポートされているすべてのトークン・タイプのリストを挿入することで、具象アサーションに変換されます。

- ポリシーでは抽象IDアサーションを使用しないことをお薦めします。かわりに、認証でサポートされるトークン・タイプを直接正確に指定するようにしてください。また、IDアサーションでサポートするトークン・タイプは1つのみにすることをお薦めします。

注意:

これにより、サポートされるトークン・タイプがあいまいでなくなるため、IntegrityアサーションのX509AuthConditional属性は不要になります。

結果として、可能なかぎりAuth.xmlポリシー・ファイルを使用せずに、Sign.xmlおよびEncrypt.xmlのポリシーを使用することをお薦めします。

- Service Busプロキシがデジタル署名(インバウンド・リクエスト・メッセージまたはバックエンド・レスポンス・メッセージ上)を処理するときは常に、セキュリティ・レルムに証明書レジストリを構成し、取引パートナの証明書をレジストリにインポートすることを強くお薦めします。

53.3 ポリシー・サブジェクトと有効ポリシー

ポリシー・サブジェクトは、サービス、エンドポイント、操作、メッセージなどのエンティティであり、これにポリシーを関連付けることができます。1つのWS-Policy文を複数のポリシー・サブジェクトと関連付けることができ、反対に、複数のWS-Policy文を1つのポリシー・サブジェクトを関連付けることができます。ポリシー・スコープは、ポリシーが適用されるポリシー・サブジェクトの集合です。たとえば、wsd:binding/wsdl:operation/wsdl:inputに付加されたポリシーが適用されるポリシー・スコープは、入力メッセージ、操作、エンドポイント、およびサービスです。

特定のポリシー・サブジェクトの 有効ポリシー は、スコープにそのポリシー・サブジェクトを含むすべてのポリシーを結合したものになります。たとえば、バインディング操作の入力メッセージの有効ポリシーは、次に付加されるすべてのポリシーを結合したものになります。

- バインディング操作の入力メッセージ

- バインディング操作

- バインディング

- ポートのタイプの操作の入力メッセージ

- ポートのタイプの操作

- ポートのタイプ

- サービス

WS-Policy文を使用してプロキシ・サービスまたはビジネス・サービスを構成した場合、Oracle Service Busコンソールに有効ポリシーが表示されます(読取り専用)。

54 Oracle Service BusでのSAMLの使用

この章では、Service Busのクライアントおよびサービス間で認証および認可情報を交換するためのSecurity Assertion Markup Language (SAML)ポリシーを使用する方法について説明します。

SAMLは、WLS 9ポリシー・フレームワークまたはOracle Web Services Managerのいずれかで使用できます。「Oracle Web Services Managerを使用したOracle Service Busのセキュリティ」の説明に従って、Oracle Web Services Managerをサービス・セキュリティに使用することをお薦めします。

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

- IDのSAMLトークンへのマッピング

- SAMLパススルーIDの伝播の構成

- プロキシ・サービス・リクエストでのSAMLトークンの認証

- サービス・バス(SB)トランスポートを使用したSAML認証の構成

- SAMLのアイデンティティ切替えの使用

- Oracle Service BusにおけるSAMLのトラブルシューティング

54.1 IDのSAMLトークンへのマッピング

ビジネス・サービスでSAMLトークンが要求されるが、クライアントから提供されない場合は、クライアントのIDをSAMLトークンにマップするようにプロキシ・サービスを構成できます。

SAML資格証明マッピングを構成するには:

1. 次のいずれかの方法を使用してクライアントを認証するようにプロキシ・サービスを構成します。

- HTTPまたはHTTPS基本認証(クライアントがリクエスト内でユーザー名とパスワードを提供)

- HTTPSクライアント証明書

- メッセージ・レベルの認証(サポートされるトークン・プロファイルのいずれかを使用)
クライアント・リクエストにWS-Securityセキュリティ・ヘッダーが含まれる場合は、メッセージのプロキシ・サービス側でこのヘッダーを処理するようにプロキシ・サービスを構成する必要があります。Service Busでは、すでにWS-Securityヘッダーが含まれるSOAPエンベロープにSAMLヘッダー(または他のWS-Securityヘッダー)を追加したり、既存のセキュリティ・ヘッダーにSAML (または他の)セキュリティ・トークンを追加したりできません。

- サード・パーティ認証

プロキシ・サービスがユーザーを認証する場合、プロキシでは、ビジネス・サービスにメッセージを転送する前にサブジェクトが自動的に生成されます。

2. SAMLクライアント・ポリシーを含むようにビジネス・サービスを構成します。ポリシーによって、認証済ユーザーのためのSAMLトークンがサブジェクトに生成されます。

Service BusでサポートされるOracle Web Services Manager SAMLポリシーのリストは、「事前定義済ポリシーとサポートされないアサーション」を参照してください。

注意:

この項の手順では、プロキシからビジネス・サービスを呼び出すことを前提としています。ビジネス・サービスを呼び出す前にプロキシからプロキシを呼び出す環境を使用する場合、Service Busによるセキュリティ・ヘッダーの処理方法を理解すると役立ちます。詳細は、「ローカル・プロキシ・サービスでのOWSMセキュリティの使用」を参照してください。

54.2 SAMLパススルーIDの伝播の構成

クライアントがパススルー・プロキシ・サービスへのSAMLトークンを提供する場合は、クライアントのSAMLトークンをビジネス・サービスに伝播できます。

この方法では、ビジネス・サービスが、SAMLトークンを使用した認証を要求するポリシー文を持つWebサービスであることが必要です。

SAMLパススルーIDの伝播を構成するには:

- プロキシ・サービス - 「パススルー・プロキシ・サービスの作成: 主な手順」の説明のとおり、パススルー・プロキシ・サービスを構成します。

- ビジネス・サービス - 「ビジネス・サービスのメッセージ・レベルのセキュリティの構成:主な手順」の説明のとおり、SAMLトークンを使用する認証を要求するポリシー文でSOAP-HTTPまたはSOAP-JMSのビジネス・サービスを構成します。

54.3 プロキシ・サービス・リクエストでのSAMLトークンの認証

アクティブな仲介プロキシ・サービスへのSAMLトークンがクライアントから提供される場合は、クライアントのIDアサーションを行うようにプロキシ・サービスを構成できます。

SAMLトークンを使用してクライアントを認証するようにプロキシ・サービスを構成するには:

1. IDアサーション・プロバイダの構成時は、次の要件に注意してください。

- ポリシーの確認方法がSAMLアサーション側のSAMLプロファイルと一致する必要があります。

- アサーション側のターゲットURLをプロキシ・サービスの相対URLとして指定します(プロトコルとホスト情報は省略します)。

- 署名されたアサーションの場合は、IDアサーション・プロバイダ・レジストリに証明書を追加します。

2. HTTP、HTTPS、またはJMSプロトコル経由で通信するアクティブな仲介プロキシ・サービスを作成します。プロキシ・サービスは、認証を要求し、SAMLトークンを受け取るポリシー文を持つWebサービスであることが必要です。

「ローカルな」トランスポート・タイプで通信するプロキシ・サービスは、SAMLトークン・プロファイルを使用して認証を行うことはできません。

54.4 サービス・バス(SB)トランスポートを使用したSAML認証の構成

SBトランスポートでSAMLベースの認証を使用する場合は、次の構成要件に従ってください。

- アサーション側で、URI http://openuri.org/sb_proxy_uriを使用して、SAML資格証明マッパーを構成します。sb_proxy_uriは、SBトランスポート・サービスのURIです。

- Service Bus側(リライイング・パーティ)でIDアサーション・プロバイダを構成する場合は、アサーション側の対象URLをプロキシのエンドポイントURIとして使用します。プロトコルおよびホスト情報は含めないでください。例: /sb_proxy_uri。

54.5 SAMLのアイデンティティ切替えの使用

Oracle Web Services Managerは、アイデンティティ切替えの実行を可能にするwss11_saml_token_identity_switch_with_message_protection_client_policyを提供します。ビジネス・サービスに付加する対象のポリシーは、プロキシ・サービスから認証されたサブジェクトに基づくアイデンティティではなく、異なるアイデンティティを伝播します。ポリシーの詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のアイデンティティ切替えのためのSAML Webサービス・クライアントの構成に関する項を参照してください。

ポリシー・プロパティsubject.precedence = falseに設定し、切替え先のアイデンティティの資格証明ストア形式(CSF)キーを提供した場合、ビジネス・サービスは現在のサブジェクトを無視し、csf-keyの資格証明でSAMLトークンを作成します。

subject.precedence = trueに設定した場合、現在のサブジェクトがSAMLトークンの作成に使用されます。ただし、サブジェクトが匿名の場合、Oracle Web Services Managerはアイデンティティ切替えの実行にcsf-keyを使用しようとします。

CSFの使用に関する詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の資格証明ストア・フレームワークの開発に関する項を参照してください。

54.5.1 アイデンティティ切替えリソースの保護

アイデンティティ切替え機能への不正なアクセスを防ぐため、アイデンティティ切替えを実行するリソースに特別な権限を付与する必要があります。たとえば、Service Busで、アイデンティティ切替えビジネス・サービスが含まれるプロジェクトに権限を付与します。

Fusion Middleware Controlを使用して、Service Busプロジェクトに適切な権限を付与します。この内容をガイダンスとして、権限フィールドに次の情報を入力します。

- 権限クラス: oracle.wsm.security.WSIdentityPermission

- リソース名: ビジネス・サービスが含まれるService Busプロジェクトの名前(パスではない)

- 権限アクション: assert

54.6 Oracle Service BusにおけるSAMLのトラブルシューティング

質問: プロキシ・サービスのトランスポートIDを宛先のビジネス・サービスに伝播しようとすると、必ず、「Unable to add security token for identity」というエラーが表示されます。これはどういう意味ですか。

回答: このエラーには様々な原因があります。通常、これは次のいずれかの問題を意味します。

- SAML資格証明マッパーが正しく構成されていません。構成が、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のSAMLの構成に関する項の指示に準じていることを再確認してください。

- このエラーで一般的なもう1つの原因は、伝播するサブジェクト情報がないことです。SAMLトークンを生成するには、トランスポート・レベルまたはメッセージ・レベルのサブジェクトが必要です。クライアントにサブジェクトがあるか確認してください。これを行うには、$securityメッセージ・コンテキスト変数を検査します。

質問: SAML holder-of-keyを使用して、プロキシ・サービスのトランスポートIDを宛先のビジネス・サービスに伝播しようとすると、必ず「Failure to add signature」というエラーが表示されます。これはどういう意味ですか。

回答: このエラーには様々な原因がありますが、最も可能性が高いのは、ビジネス・サービスのサービス・キー・プロバイダに対して資格証明が構成されていないことです。Service Busは、アウトバウンドholder-of-keyアサーションを生成するときに、メッセージ・コンテンツに対するデジタル署名も生成します。これにより、受信者はメッセージが特定のユーザーから送信されたものであることのみではなく、そのメッセージが改ざんされていないことも確認できます。署名を生成するには、ビジネス・サービスは関連付けられたデジタル署名資格証明を持つサービス・キー・プロバイダを持つ必要があります。

質問: SAML IDトークンを受信するアクティブな仲介プロキシ・サービスを構成しようとすると、必ず「The SAML token is not valid」のようなエラーが表示されます。どのように修正すればよいですか。

回答: この問題は通常、そのプロキシ・サービスに対してSAML IDアサーション・プロバイダまたはSAML IDアサーション・プロバイダのアサーション側構成がないことが原因です。プロキシ・サービスがアクティブな仲介モードでSAMLアサーションを受信するには、SAML IDアサーション・プロバイダが構成されている必要があります。詳細は、『Oracle WebLogic Serverセキュリティの管理』の SAML IDアサーション・プロバイダの構成に関する項を参照してください。

55 カスタム認証の構成

この章では、Service Busのカスタム・トランスポート・レベルおよびメッセージ・レベルの認証を構成する方法について説明します。

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

- Oracle Service Busのカスタム認証の概要

- XPath拡張の形式

- カスタム・トークン用IDアサーション・プロバイダの構成

- カスタム認証によるトランスポート・レベルのセキュリティの構成

- メッセージ・レベルのカスタム認証の構成

プロキシまたはビジネス・サービス・セキュリティを構成する手順については、「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。

55.1 Oracle Service Busのカスタム認証の概要

Service Busは、トランスポート・レベルのプロキシおよびビジネス・サービス・リクエストと、メッセージ・レベルのプロキシ・サービス・リクエストについて、クライアントで指定されたカスタム認証の資格証明をサポートしています。カスタム認証資格証明は、トークン、またはユーザー名とパスワードのトークンの組合せになります。トランスポート・レベルでは、HTTPヘッダーでプロキシまたはビジネス・サービスに渡されるカスタム・トークンを受け入れて、認証を試行します。メッセージ・レベルでは、SOAPヘッダー(SOAPベース・サービスの場合)またはペイロード(非SOAPサービスの場合)から情報を取得できます。

プロキシ・サービス定義エディタを使用して、トークン・タイプとトークンが渡されるメカニズムによりプロキシ・サービスを構成します。ビジネス・サービスについては、カスタム認証Javaクラスを定義して、それをビジネス・サービス定義エディタから参照できます。

注意:

カスタム認証のメカニズムは、単独かWebサービスのメッセージ・レベルのセキュリティとともに機能します。これについては、「Webサービスのメッセージ・レベルでのセキュリティの構成」で説明しています。両方のタイプのセキュリティの使用について詳しくは、「WS-Securityおよびカスタム・ユーザー名/パスワードとトークンの組合せ」を参照してください。

55.1.1 カスタム認証トークンの理解

認証トークンは、文字列やXMLで表される何らかのデータで、X509クライアント証明書などのエンティティ(ユーザーまたはプロセス)を識別します。認証トークンは通常、特定のセキュリティ・プロトコル内で使用されることを意図しています。暗号により保護されている認証トークンもあれば、そうでないものもあります。一部の認証トークンは、重要なキー・マテリアルを持っています。

Service Busの文脈では、カスタム認証トークンはユーザー名およびパスワードであったり、リクエスト内のユーザー定義の場所にある不透明なIDアサーション・トークンであることもあります。ユーザー名およびパスワードのトークンは、SOAPヘッダー(SOAPベースのサービスの場合)または非SOAPプロキシ・サービスのペイロードで使用されます。IDアサーション・トークンは、HTTPヘッダーやSOAPヘッダー(SOAPベースのサービスの場合)、または非SOAPプロキシ・サービスのペイロード内で使用可能です。Service Busドメインには、トークン・タイプをサポートするIDアサーション・プロバイダを含める必要があります。

Service Busは、認証されたユーザーを使用して、クライアントのセキュリティ・コンテキストを確立します。カスタム・トークンやユーザー名およびパスワードを認証することで確立されたセキュリティ・コンテキストは、アウトバウンド資格証明のマッピングおよびアクセス制御の基礎として使用できます。認証のためにトークンを提供するクライアントの認証と認可を行うには、クライアントの資格証明をService BusユーザーにマップするIDアサーション・プロバイダを構成する必要があります。Service Busはこのユーザー名を使用して、クライアントのセキュリティ・コンテキストを確立します。

55.1.2 カスタム認証トークンの使用とデプロイメント

Service Busでのカスタム認証トークンのサポートにより、2つの要件に対応します。1番目の要件は、プロキシ・サービスのリクエストのメッセージ・ペイロードのどこか(SOAPヘッダーなど)にユーザー名およびパスワードがある場合です。Service Busは、このユーザー名およびパスワードを取得して、ユーザーを認証する必要があります。2番目の要件は、メッセージにsecure-token-xyzトークンなど何らかの認証トークン(ユーザー名およびパスワード以外)が含まれている場合です。トークンは、HTTPヘッダーまたはメッセージのペイロード内にある場合があります。Service Busは、このトークンを取得して認証する必要があります。どちらの場合でも、認証に成功するとセキュリティ・コンテキストが確立されます。

一般に、ほとんどのセキュリティ関連の構成はデプロイメント時に実行され、カスタム認証はそのモデルに適合します。これは、デプロイメント時に本番環境で直接構成できます。または、ステージングの際に認証を構成して、それを本番環境にインポートすることもできます。

カスタム認証(カスタム・トークンと、ユーザー名およびパスワードのトークンを含む)は、プロキシ・サービスの定義の中核です。プロキシ・サービスがエクスポートされるとき、カスタム・トークンのすべての構成がJARファイルに含まれます。新しいバージョンのプロキシ・サービスがインポートされる場合、前の構成はこのJARファイルに含まれる構成にオーバーライドされます。

カスタム・トークン認証を構成できるのは、Middleware管理者または開発者のアプリケーション・ロール(あるいは統合デプロイヤまたは統合管理者のエンタープライズ・ロール)のユーザーのみです。ロールの詳細については、「Oracle Service Busの管理」のOracle Service Busでのロール・ベースのアクセスに関する項を参照してください。

55.1.3 トランスポート・レベルのカスタム認証について

HTTPヘッダーで指定できるカスタム認証トークンを使用して、トランスポート・レベルでクライアントのリクエストを認証できます。トランスポート・レベルのカスタム認証は、サービス定義エディタの「トランスポートの詳細」ページで構成します。HTTPサービスおよびHTTPSサービスのオプションは次のとおりです。

- なし

- 基本

- カスタム認証

- クライアント証明書(HTTPSのみ)

これらのオプションは同時に複数選択することはできません。

プロキシ・サービスのカスタム認証を選択する場合は、トークン・タイプと、そのトークンを運ぶHTTPヘッダーの名前も指定する必要があります。ビジネス・サービスのカスタム認証を選択する場合は、カスタム・オーセンティケータのJavaクラスも指定する必要があります。カスタム認証のトークンには、任意のアクティブなトークン・タイプで、以前にIDアサーション・プロバイダ用に構成され、HTTPヘッダーで送信されたものを使用できます。

55.1.3.1 インポート/エクスポートおよびトランスポート・レベルのカスタム・トークン認証

トランスポート・レベルのカスタム認証トークンは、UDDIにパブリッシュされます。client-authプロパティは、認証の構成時にHTTPまたはHTTPSトランスポート属性のinstanceParmsにあります。「トランスポート属性」で説明されているとおり、client-authに指定可能な値はBASIC、CLIENT-CERTおよびCUSTOM-TOKENです。値がCUSTOM-TOKENの場合は、さらにtoken-headerとtoken-typeという2つのプロパティが必ず存在します。

55.1.4 メッセージ・レベルのカスタム認証について

Service Busは、プロキシ・サービスのメッセージ・レベルのリクエストについて、クライアントで指定されたカスタム認証の資格証明をサポートしています。カスタム認証資格証明は、カスタム・トークン、またはユーザー名とパスワードの形式になります。Service Busは、SOAPヘッダー(SOAPベースのプロキシ・サービスの場合)、またはペイロード(非SOAPプロキシ・サービスの場合)でプロキシ・サービスに渡されるカスタム・トークンを受け入れて、認証しようとします。「セキュリティ」ページ(Oracle Service Busコンソール)またはプロキシ・サービス定義エディタの「セキュリティ設定」ページ(JDeveloper)で、トークン・タイプおよびトークンを渡すメカニズムの指定を含めて、メッセージ・レベルのカスタム認証を構成します。

サポートされているプロキシ・サービスのメッセージ・レベルの認証メカニズムは次のとおりです。

- SOAPベースのプロキシ・サービスの場合

- SOAPヘッダーのカスタム・トークン

- SOAPヘッダーのユーザー名/パスワード

- 非SOAPベースのプロキシ・サービスの場合

- 任意のXMLベースのプロキシ・サービスのペイロードに含まれるカスタム・トークン

- 任意のXMLベースのプロキシ・サービスのペイロードに含まれるユーザー名/パスワード

メッセージ・レベルのカスタム・トークン、およびメッセージ・レベルのユーザー名とパスワードが以下のバインディング・タイプのプロキシ・サービスでサポートされます。

- WSDL-SOAP

- WSDL-XML

- 抽象SOAP

- 抽象XML

- 混合 - XML(リクエスト内)

- 混合 - MFL(リクエスト内)

55.1.5 カスタム認証トークンから取得したIDの伝播

カスタムのトークンまたはカスタムのユーザー名/パスワードにより確立されるセキュリティ・コンテキストは、決して一意ではなく、それを資格証明のマッピングに使用できます。トランスポート・レベルの認証とメッセージ・レベルの認証を両方とも実装する場合、メッセージ・レベルのセキュリティ・コンテキストは、常に資格証明のマッピングとIDの伝播に使用されます。

たとえば、プロキシ・サービスがSOAPヘッダーのsecure-token-xyzトークンによってクライアントを認証する場合、マップされたすべてのサービス・アカウントのルックアップ中に、認証されたサブジェクトが使用されます。サブジェクトはアウトバウンド・メッセージ上でSAMLトークンが生成されるときにも使用されます。また、カスタム・トークンまたはカスタムのユーザー名/パスワードに関連する認証コンテキストの下で、Javaコールアウトが実行可能です。

カスタムのユーザー名/パスワードを使用する場合、パススルー・サービス・アカウントが使用されるときは、カスタム・トークン内のユーザー名/パスワードをアウトバウンドHTTP BasicまたはアウトバウンドWS-Securityユーザー名トークンの認証に使用できます。

55.1.6 WS-Securityおよびカスタム・ユーザー名/パスワードとトークンの組合せ

トランスポート・レベル・セキュリティ(たとえば、HTTPS)またはメッセージ・レベル・セキュリティ(たとえば、WS-Security (WSS)とカスタム・トークン)、あるいはその両方の組合せによってService Busプロキシ・サービスを保護できます。たとえば、クライアントのリクエストをHTTPヘッダーのカスタム・トークンを使用してトランスポート・レベルで認証したり、WS-Securityヘッダーを除く、WS-Securityトークンやカスタム・トークン、ユーザー名/パスワードを使用して、メッセージ・レベルで認証したりできます。

制限が1つあります。WS-Securityとメッセージ・レベルのカスタム・トークンを組み合せることは可能ですが、WS-SecurityポリシーはWS-Securityトークンに基づいてプロキシ・サービス認証を要求することはできません 。メッセージ・レベルのカスタム・トークンとWS-Securityプロキシ・サービス認証は、同時に両方を選択することはできません。

次の例を参考にしてください。

- SOAPヘッダー<soap:MyToken>にタイプがMyTokenのカスタム・トークンを想定し、何らかのメッセージ部分(<soap:MyToken>ヘッダーおよびSOAP本体など)の署名や暗号化を要求するWS-Securityポリシーを持つプロキシ・サービスを構成することはできません。

- ヘッダー<soap:MyToken>にカスタム・トークンを要求し、SAMLトークンや他の形式の認証を要求するWS-Securityポリシーも持っているプロキシ・サービスを構成することはできません。

55.2 XPath拡張の形式

カスタム・ユーザー名/パスワードを使用する認証と、カスタム・トークンを使用する認証の構成はほぼ同じです。どちらの場合も、Service Busで必要な情報を検索できるようにするためのXPath式を指定します。これらのXPath式のルートは次のとおりです。

- サービスのバインドがanySOAPまたはWSDL-SOAPの場合は、soap-env:Envelope/soap-env:Headerを使用します。

- サービスのバインドがSOAPベースでない場合は、soap-env:Body(具体的には、$body変数の内容)を使用します。

注意:

すべてのXPath式は有効なXPath 2.0形式である必要があります。使用するネームスペースをXPath式で宣言するには、次のようなXPathの"declare namespace"構文を使用します。

declare namespace ns='http://webservices.mycompany.com/MyExampleService';

次に例を示します。

declare namespace y="http://foo";./y:my-custom-token/text()

55.3 カスタム・トークン用IDアサーション・プロバイダの構成

IDアサーション・プロバイダは、ユーザーまたはシステム・プロセスがトークンを使用してそれぞれのIDを証明する特殊な形態の認証プロバイダです。クライアントのIDは、クライアントから提供されるトークンを使用することにより確立されます。IDアサーション・プロバイダは、トークンを検証します。トークンが正常に検証されると、IDアサーション・プロバイダは、トークンをService Busユーザー名にマップしてそのユーザー名を返します。トークンがユーザー名にマップされることを、IDが「アサートされた」といいます。Service Busは、このユーザー名を使用してクライアントのセキュリティ・コンテキストを確立します。

プロキシまたはビジネス・サービスでカスタム・トークンを消費するには、提供されたWebLogic ServerのIDアサーション・プロバイダをチェックして、ニーズに合うかを確認してください。WebLogic Serverには、次のような幅広いIDアサーション・プロバイダが含まれています。

- WebLogic IDアサーション・プロバイダは、X.509およびIIOP-CSIv2トークンを検証します。必要に応じてユーザー名マッパーを使用し、そのトークンをユーザーにマップできます。

- SAML IDアサーション・プロバイダは、SAMLセキュリティ・アサーションのコンシューマとして機能します。

このサービスで、secure-token-xyzトークンなど、バンドルされたIDアサーション・プロバイダにより処理されないカスタム・トークンを消費する場合、ユーザー(またはサードパーティ)は最初にトークン・タイプをサポートするWebLogic Server IDアサーション・プロバイダを記述し、Oracle WebLogic Server管理コンソールを使用して、そのプロバイダをセキュリティ・レルムに追加する必要があります。

IDアサーション・プロバイダを開発して、ユーザーのIDをアサートするときに使用する特定のタイプのカスタム・トークンをサポートします。複数のトークン・タイプをサポートするために、IDアサーション・プロバイダを開発することができます。1つのセキュリティ・レルムに、同じトークン・タイプを検証する機能を備えた複数のIDアサーション・プロバイダを持つことはできますが、この検証を実際に実行できるのは、1つのIDアサーション・プロバイダだけです。

図55-1に、カスタム認証用に構成されたプロキシ・サービスのIDアサーション・プロセスを示します。このプロセスは、次のように機能します。

1. プロキシ・サービスがインバウンド・リクエストから認証トークンを取得します。

2. そのタイプのトークンの検証を担当し、「アクティブ」として構成されているIDアサーション・プロバイダにトークンが渡されます。

3. IDアサーション・プロバイダは、トークンを検証します。

4. トークンが正常に検証されると、IDアサーション・プロバイダは、トークンをユーザー名にマップしてそのユーザー名を返します。

5. その後、Service Busは、このユーザー名を使用して認証プロセスを続け、成功した場合は認証されたサブジェクトを取得します。

6. Service Busは、セキュリティ・コンテキストを作成します。カスタム・トークンやユーザー名およびパスワードを認証することで確立されたセキュリティ・コンテキストは、アウトバウンド資格証明のマッピングおよびアクセス制御の基礎として使用できます。

詳細は、『Oracle WebLogic Serverセキュリティの理解』のIDアサーションおよびトークンに関する項を参照してください。

図55-1 プロキシ・サービスのIDアサーションおよびカスタム・トークン

55.3.1 カスタム・トークンのオブジェクト・タイプ

トランスポート・レベルのIDアサーションの場合、ヘッダーの値はjava.lang.StringとしてIDアサーション・プロバイダに渡されます。メッセージ・レベルのIDアサーションの場合は、XPath式が次のように評価されます。

- XPath式が複数のノードを戻す場合、エラーが発生してIDアサーションは呼び出されません。

- XPath式が空の結果を戻す場合、nullの引数を持つIDアサーションが呼び出されます。

- XPath式がタイプTEXTまたはATTRの単一のトークンを戻す場合(http://xmlbeans.apache.org/docs/2.0.0/reference/org/apache/xmlbeans/XmlCursor.TokenType.htmlにあるXmlCursor.TokenTypeを参照)、テキスト・ノードの文字列の値または属性が渡されます(XmlCursor.getStringValue()によって戻される場合と同じように)。それ以外の場合は、単一のXmlObjectが渡されます。

55.3.2 IDアサーション・プロバイダでのカスタム・トークン・タイプの構成

これらのタスクを完了するために必要な手順は、次のWebLogic Serverのドキュメントで説明されています。

- 『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の新しいトークン・タイプの作成方法に関する項では、IDアサーション・プロバイダ用のカスタムのトークン・タイプを作成する方法について説明しています。

- 『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の管理コンソールによるカスタムIDアサーション・プロバイダの構成に関する項ではOracle WebLogic Server管理コンソールでのIDアサーション・プロバイダの構成方法について説明しています。

55.3.2.1 IDアサーション・プロバイダでのカスタム・トークン・タイプの構成方法

参考までに、IDアサーション・プロバイダ用のカスタム・トークン・タイプを作成する手順と、そのプロバイダをOracle WebLogic Server管理コンソールで構成する手順について、ここで簡単にふれています。ただし、実際にこのタスクを完了するには、WebLogic Serverのドキュメントに目を通す必要があります。

IDアサーション・プロバイダでカスタム・トークン・タイプを構成するには:

1. 新しいトークン・タイプを作成します。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の新しいトークン・タイプの作成方法に関する項を参照してください。

2. ランタイム・クラスを作成します。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の適切なSSPIを使用したランタイム・クラスの作成に関する項を参照してください。この項では、SampleIdentityAsserterProviderImpl.javaクラスについて説明しています。これは、サンプルのIDアサーション・プロバイダのランタイム・クラスです。

3. MBeanタイプを生成します。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のWebLogic MBeanMakerによるMBeanタイプの作成に関する項を参照してください。

4. カスタムIDアサーション・プロバイダを構成します。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の管理コンソールによるカスタムIDアサーション・プロバイダの構成に関する項を参照してください。

5. アクティブなトークン・タイプを定義します。『Oracle WebLogic Serverセキュリティの管理』のIDアサーション・プロバイダの構成に関する項と、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のIDアサーション・プロバイダの構成用に新しいトークン・タイプを使用可能にする方法に関する項を参照してください。

55.3.2.2 MBeanでサポートするアクティブなタイプの設定

カスタムのIDアサーション・プロバイダを構成するときは、「サポートされている種類」フィールドにIDアサーション・プロバイダがサポートしているトークン・タイプのリストが表示されます。「アクティブな種類」フィールドにゼロまたはそれ以上のサポートされているタイプを入力します。

「サポートされている種類」フィールドの内容は、カスタムIDアサーション・プロバイダのMBeanタイプを生成するために使用するMBean定義ファイル(MDF)のSupportedTypes属性から取得されます。サンプルIDアサーション・プロバイダの例を次の例で示します。MDFおよびMBeanタイプの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のWebLogic MBeanMakerによるMBeanタイプの生成に関する項を参照してください。

例 - SampleIdentityAsserter MDF : SupportedTypes属性

<MBeanType>
...
<MBeanAttribute
Name = "SupportedTypes"
Type = "java.lang.String[]"
Writeable = "false"
Default = "new String[] {&quot;SamplePerimeterAtnToken&quot;}"
/>
...
</MBeanType>

同様に、「アクティブな種類」フィールドの内容は、MBean定義ファイル(MDF)のActiveTypes属性から取得されます。MDFファイルのActiveTypes属性をデフォルトに設定すると、Oracle WebLogic Server管理コンソールで手動設定する必要がなくなります。サンプルIDアサーション・プロバイダの例を次の例で示します。

例 - SampleIdentityAsserter MDF: Defaultを使用したActiveTypes属性

<MBeanAttribute
Name= "ActiveTypes"
Type= "java.lang.String[]"
Default = "new String[] { &quot;SamplePerimeterAtnToken&quot; }"
/>

ActiveTypes属性のデフォルト化は便利ですが、他のIDアサーション・プロバイダがそのトークン・タイプを検証することがない場合にのみ行うようにします。それ以外の場合、無効なセキュリティ・レルムが構成されることになるおそれがあります(複数のIDアサーション・プロバイダが同じトークン・タイプを検証しようとします)。一番良いのは、IDアサーション・プロバイダのすべてのMDFがデフォルトでそのトークン・タイプをオフにすることです。その場合、そのトークン・タイプを検証するIDアサーション・プロバイダを構成して手作業でアクティブにすることができます。

55.4 カスタム認証によるトランスポート・レベルのセキュリティの構成

トランスポート・レベルのセキュリティ用にHTTPプロキシまたはビジネス・サービスを構成するには、使用するトークン・タイプを認識するIDアサーション・プロバイダを構成するか、作成して構成しておく必要があります。

- アウトバウンド用のカスタム認証クラスの作成方法

- トランスポート・レベルのカスタム認証の構成方法

55.4.1 アウトバウンド用のカスタム認証クラスの作成方法

アウトバウンドのカスタム認証では、カスタム・ロジックを定義するカスタムJavaクラスを作成する必要があります。次のインタフェースは、ビジネス・サービス用のカスタム認証を実装するために必要なメソッドを提供します。

- com.bea.wli.sb.transports.http.OutboundAuthentication

- com.bea.wli.sb.transports.http.HttpUrlConnectionFactory

カスタム・オーセンティケータは、OutboundAuthenticationインタフェースのdoOutboundAuthenticationメソッドを実装する必要があります。カスタム・オーセンティケータは、認証ヘッダーを設定して、初期トランザクションおよび中間トランザクションのターゲット・サービスからのレスポンスを読み取ることができます。最終ステップとして、カスタム・オーセンティケータは認証ヘッダーのみを設定し、ターゲット・サービスとの接続は確立しないことが想定されています。最終ステップでは、Service Busが認証ヘッダーとともにペイロードを送信します。カスタム・オーセンティケータではペイロードを操作しないでください。

55.4.2 トランスポート・レベルのカスタム認証の構成方法

次の手順は、トランスポート・レベルでカスタム認証を定義するために完了する必要があるステップの概要を示しています。より詳細な手順へのリンクが含まれます。

トランスポート・レベルのカスタム認証を構成するには:

1. 使用するカスタム・トークンの形式を決定します。

2. 既存のプロバイダがニーズに合うかどうかを判断します。詳細については、『Oracle WebLogic Serverセキュリティの管理』の認証プロバイダの選択に関する項を参照してください。

3. トークンの形式をサポートするIDアサーション・プロバイダを、構成あるいは作成してから構成してください。次の手順を参照してください。

- 既存のIDアサーション・プロバイダの構成については、Oracle WebLogic Serverのセキュリティの管理の認証プロバイダの構成に関する項(具体的には、IDアサーション・プロバイダの構成に関する項)を参照してください。

- プロバイダのカスタム・トークン・タイプの作成については、「IDアサーション・プロバイダでのカスタム・トークン・タイプの構成方法」を参照してください。

- カスタム・プロバイダの開発については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のIDアサーション・プロバイダに関する項を参照してください。

4. IDアサーション・プロバイダが、トークンをユーザー名にマップします。Fusion Middleware Controlでクライアントのユーザー名を追加します。

5. プロキシ・サービスについて、プロキシ・サービス定義エディタの「トランスポートの詳細」ページで次の手順を実行します。

a. 認証で、「カスタム認証」を選択します。

b. 「詳細オプション」(または「詳細設定」)の「認証ヘッダー」フィールドで、Service Busがトークンを検索できるメッセージ・ヘッダーを入力します。

c. 「認証トークン・タイプ」で、このエンドポイントで想定されるトークン・タイプを入力します。

6. ビジネス・サービスでは、カスタム・オーセンティケータJavaクラスを作成およびコンパイルして、システム・クラスパスにクラスを追加します。

7. ビジネス・サービスについて、ビジネス・サービス定義エディタの「トランスポートの詳細」ページで次の手順を実行します。

a. 認証で、「カスタム認証」を選択します。

b. 「HTTPカスタム認証クラス名」フィールドで、カスタム認証を定義するJavaクラスの名前を入力します。

8. 変更を保存してアクティブ化します。

55.5 メッセージ・レベルのカスタム認証の構成

プロキシ・サービスのカスタム認証によるメッセージ・レベルのセキュリティを構成するには、使用するトークン・タイプを認識する認証プロバイダまたはIDアサーション・プロバイダを構成するか、作成して構成しておく必要があります。

55.5.1 プロキシ・サービスのメッセージ・レベルのカスタム認証の構成方法

次の手順は、トランスポート・レベルでカスタム認証を定義するために完了する必要があるステップの概要を示しています。より詳細な手順へのリンクが含まれます。

注意:

使用するプロバイダは、提供するすべてのコンテキスト・プロパティを認識する必要もあります。いずれかの コンテキスト・プロパティ を指定した場合、プロバイダは処理するプロパティ名を知っておく必要があるため、おそらく独自のプロバイダを作成する必要があります。

メッセージ・レベルのカスタム認証を構成するには:

1. 使用するカスタム・ユーザー名/パスワードまたはトークンの形式を決定します。

2. 既存のプロバイダがニーズに合うかどうかを判断します。詳細については、『Oracle WebLogic Serverセキュリティの管理』の認証プロバイダの選択に関する項を参照してください。

3. ユーザー名/パスワードまたはトークンの形式をそれぞれサポートする認証プロバイダあるいはIDアサーション・プロバイダを、構成するか、作成して構成します。次の手順を参照してください。

- 既存の認証プロバイダまたはIDアサーション・プロバイダを構成するには、『Oracle WebLogic Serverのセキュリティの管理』の認証プロバイダの構成に関する項を参照してください。

- プロバイダのカスタム・トークン・タイプの作成については、「IDアサーション・プロバイダでのカスタム・トークン・タイプの構成方法」を参照してください。

- カスタムIDアサーション・プロバイダの開発については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のIDアサーション・プロバイダに関する項を参照してください。

4. Fusion Middleware Controlでクライアントのユーザー名を追加します。

5. Service Busのプロキシ・サービスのセキュリティ設定で、カスタム・トークン、またはユーザー名とパスワードを定義します。オプションで、プロバイダのコンテキスト・プロパティを指定します。

詳細および手順については、「コンソールでプロキシ・サービスのカスタム認証を構成する方法」または「JDeveloperでプロキシ・サービスのカスタム認証を構成する方法」を参照してください。

56 .Net 2.0とメッセージ・レベルのセキュリティの定義方法

この章では、.NET 2.0とService Bus間でメッセージ・レベルのセキュリティを構成する方法について説明します。

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

- .NET 2.0とOracle Service Bus間のメッセージ・レベルのセキュリティ

- .NETとは

- .NETでのメッセージ・レベルのセキュリティ構成

- Oracle Service Busの.NETとのメッセージ・レベルのセキュリティの構成

56.1 .NET 2.0とOracle Service Bus間のメッセージ・レベルのセキュリティ

Microsoft .NET 2.0フレームワークとService Busとの間でメッセージ・レベルのセキュリティを設定できます。メッセージ・レベルのセキュリティでは、Webサービス・クライアントがService Busプロキシ・サービスまたはビジネス・サービスとの接続を確立した後、プロキシ・サービスまたはビジネス・サービスがこのメッセージを処理する前にSOAPメッセージに対してセキュリティ・チェックが適用されます。

56.2 .NETとは

.NETフレームワークは、Microsoft Windowsオペレーティング・システムに追加することができるソフトウェア・コンポーネントです。一般的なプログラム要件に対してあらかじめコード化されたソリューションを提供し、このフレームワーク専用に記述されたプログラムの実行を管理します。

56.3 .NETでのメッセージ・レベルのセキュリティ構成

この項では、.NET 2.0およびService Busでメッセージ・レベルのセキュリティを構成するために必要な手順を説明します。

警告:

これらの手順を実行する前に、「Webサービスのメッセージ・レベルでのセキュリティの構成」の手順に従って、Service Busに対してインバウンドとアウトバウンドのメッセージングを構成する必要があります。

.NETとService Bus間でメッセージ・レベルのセキュリティを構成するには:

1. Service Busのインバウンドおよびアウトバウンド・メッセージングを構成する手順が完了していることを確認します。手順については、上記の警告を参照してください。

2. http://msdn2.microsoft.com/en-us/webservicesからWeb Service Enhancements (WSE) 3.0をダウンロードしてインストールします。WSE 3.0はSOAPの拡張が管理する.NET 2.0フレームワークと互換性があるAPI (Microsoft.Web.Services3.dll)です。

3. WSE 3.0のインストール後に、使用するWebアプリケーションでWSEを有効にし、またWSE Soap Protocol Factoryのサポートを有効にする必要があります。この2つの機能はVisual Studioのウィザードを使用して有効にできます。

WSE 3.0を有効にすると、次の制限が生じます。

- WSE 3.0ではWS-Policyがサポートされていません。そのため、.NET 1.1とWSE 2.0のときのような構成を目的とするWS-SecurityPolicyもサポートされません。WSE 3.0でサポートされるのは、WSE 2.0と同様の機能を提供するwse3policyCache.configファイル(または同等の.NETコード)を使用して構成された独自のポリシーに限られます。この変更の結果、.NET WebサービスのWSDLファイルにWS-Policy文は含まれなくなりました。一方、Service Busでは、2002年12月18日バージョンのWebサービス・セキュリティ・ポリシー言語(WS-SecurityPolicy)仕様に記述されたアサーションに基づくWebLogic Server独自の形式をサポートしています。Service Busで.NET WSDLファイルを利用するには、WSDLファイルに同等のService Bus独自バージョンのWS-Policyを組み込む必要があります。
「サンプルのWSDLファイル」のWSDLコード・サンプルは、Service Busにおけるメッセージ・レベルのID伝播、機密性および整合性をWS-Policyに構成する方法を示します。

- WSE 3.0ではwse3policyCache.configファイルに複数の設定不要のセキュリティ・アサーション用のポリシー構成が用意されており、Visual Studioのウィザードを使用して選択できます。提供されているメッセージ・レベル・セキュリティ(暗号化や署名など)にマップする証明書は、MutualCertificate10です。MutualCertificate10セキュリティ・アサーションの構成については、http://msdn2.microsoft.com/en-us/library/aa480581.aspxを参照してください。

- WSE SOAPプロトコル・ファクトリでは、SOAP 1.2を使用したセキュリティはサポートされません。Visual Studioの「Web Reference」オプションを使用して生成されたクライアント・スタブには、SOAP 1.1を選択した場合にのみセキュリティに対応した操作が含まれます。メッセージ・レベルのセキュリティの相互運用性は、SOAP 1.1でのみ機能します。

- .NET 1.1とWSE 2.0の場合と同じように、デフォルトで構成されているWS-Addressingヘッダーとタイムスタンプの自動署名機能を無効にする必要があります。次の例に示すように、wse3policyCache.configファイルにあるプロパティの一部を変更してください。
デフォルトのConfig

<protection>
<request signatureOptions="IncludeAddressing, IncludeTimestamp,
IncludeSoapBody" encryptBody="true" />
<response signatureOptions="IncludeAddressing, IncludeTimestamp,
IncludeSoapBody" encryptBody="true" />
<fault signatureOptions="IncludeAddressing, IncludeTimestamp,
IncludeSoapBody" encryptBody="false" />
</protection>

必要とされるConfig

<protection>
<request signatureOptions="IncludeSoapBody" encryptBody="true" />
<response signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="true"
/>
<fault signatureOptions="IncludeSoapBody" encryptBody="false" />
</protection>

- デフォルトでは、WSE 3.0は鍵のラッピング・アルゴリズムとしてOAEPを想定しています。ただし、Service BusではRSA15アルゴリズムを使用します。構成がOAEPのままの場合、「Microsoft.Web.Services3.Security.SecurityFault: An unsupported signature or encryption algorithm was used System.Exception: WSE3002: The receiver is expecting the key wrapping algorithm to be http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p, but the incoming message usedhttp://www.w3.org/2001/04/xmlenc#rsa-1_5.」という例外が表示されます。セキュリティ・トークン・マネージャを構成することで、鍵のラッピング・アルゴリズムを変更できます。
このエラーを回避するには、次の構成を<microsoft.web.services3> <security>要素の下にあるweb.configファイル(.NET Webサービス上)、およびapp.configファイル(.NETのクライアント側)に追加します。

<binarySecurityTokenManager>
<add valueType="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-x509-token-profile-1.0#X509v3";>
<keyAlgorithm name="RSA15" />
</add>
</binarySecurityTokenManager>

この構成により、WSEではOAEPではなくRSA15が強制的に使用されるようになります。

- ユーザー名のトークン認証の場合、.NETによって設定不要のアサーションusernameForCertificateSecurityが提供されます。このアサーションは、サービスのX.509証明書を使用して、クライアントとサービス間の通信チャネルをメッセージ・レイヤーで保護します。ただし、この証明書は<EncryptedKey>要素をセキュリティ・トークンとして参照する機能に依存し、署名確認のオプションが、レスポンス・メッセージとそれを引き起こしたリクエストを関連付けられるようにします。
ユーザー名トークン認証のかわりとして、.NETには設定不要のアサーションusernameOverTransportSecurityがあります。このアサーションではクライアントとサービスとの間の通信がトランスポート・レイヤーでセキュリティで保護されていることが前提となっています。このアプローチは、WS-Security 1.0互換であり、SSLを介したメッセージ・レベルの認証をサポートします。設定不要のアサーションusernameOverTransportSecurityを暗号化や署名といった他のメッセージ・レベルのセキュリティ・メカニズムと組み合せる場合は、.NETでカスタム・コードを作成する必要があります。

56.4 Oracle Service Busの.NETとのメッセージ・レベルのセキュリティの構成

Service Busの構成を行う前に、次の条件を満たしている必要があります。

- .NETクライアントは、プレーン・テキストのメッセージでService Busプロキシを呼び出します(たとえば、メッセージ・レベルのセキュリティは.NETクライアントとService Busプロキシ間には存在しません)。

- Service Busはアウトバウンド・メッセージ・レベルのセキュリティをSOAPリクエストに適用します。

注意:

.NETクライアントでメッセージ・レベルのセキュリティが有効になっている場合は、Service Busをパススルー・プロキシとして使用できます。

Service Busに.NETとのメッセージ・レベルのセキュリティを構成するには:

1. 次のように、暗号化アルゴリズムをtripledes-cbcからaes256-cbcに変更します。

<wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>

2. WSDLファイルのsign.xmlポリシーを変更します。この属性は、整合性アサーション要素にあります。

<wssp:Integrity SignToken='false' .... >
...
</wssp:Integrity>

この値はデフォルトではtrueになっています。

3. .NET Webサービスでは、WS-Addressingの<wsa:To>要素に自身のURLが含まれていることが想定されています。.NETクライアントが初めてService Busプロキシを呼び出すときに、<wsa:To>要素は最初はService BusプロキシのURLに設定されます。このURLをService Busのプロキシ・メッセージ・フローにある.NET WebサービスのURLに変更します。それには、次の例に示すようにReplaceアクションを使用します。

元のURL

<wsa:To wsu:Id="To_1mbmRK4w0bo2Dz1z" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd";>http://localhost:7001/SecurityALSBProxy<;/
wsa:To>

置換アクション後のURL

<wsa:To wsu:Id="To_1mbmRK4w0bo2Dz1z" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd";>http://localhost/SimpleSecurity/
SecurityService.asmx<;/wsa:To>

このURLを変更しないと、次のエラーが表示されます。

Microsoft.Web.Services3.Addressing.AddressingFault: Destination Unreachable
System.Exception: WSE846: The header must match the actor URI value of the web
service. The actor URI value can be explicitly specified using
SoapActorAttribute on the ASMX class. In the absence of the attribute, the
actor URI is assumed to be equal to the HTTP Request Url of the incoming
message. The header received contained
"http://localhost:7001/SecurityALSBProxy"; while the receiver is expecting
"http://localhost/SimpleSecurity/SecurityService.asmx";

4. .NETクライアントには、SOAPヘッダーに対する自身のTimestamp要素が含まれています。Service Busは余分なTimestampヘッダーを追加するため、次のエラーが発生します。

Microsoft.Web.Services3.Security.SecurityFault: An error was discovered
processing the header Microsoft.Web.Services3.Security.Security
FormatException: WSE001: The input was not a valid Security element
because it contains more than one Timestamp child element.

この問題を解決するには、削除アクションを使用して.NETクライアントがメッセージ・フローに追加した元のTimestamp要素を削除します。

5. CertificateRegistry証明書パス・プロバイダを追加します。これを追加するには、WLS管理コンソールから「レルム」→「プロバイダ」→「証明書のパス」→「新規」の順に選択し、オプションのリストからCertificateRegistryを選択します。

変更をアクティブ化し、サーバーを再起動します。

サーバーの再起動後、新規に作成したCertificateRegistryを編集します。「管理」タブで、次の3つの証明書を追加します。

- Service Busのパブリック証明書

- .NETのパブリック証明書

- ルート・エージェント(これらの証明書の発行者)

注意:

証明書を追加する方法の1つは、「移行」タブを使用してjksストアからそれらをインポートすることです。IDストアの実際のパスを指定します。

6. CertificateRegistryプロバイダの「構成(一般)」タブで、「現在のビルダー」を選択して、これを現在のビルダーに設定します。

変更を保存します。次にサーバーをアクティブ化し、再起動します。

7. WLSキーストアでは次の同じ証明書が必要です。

- Service Busのパブリック証明書

- .NETのパブリック証明書

- ルート・エージェント(これらの証明書の発行者)

サーバーの「構成:キー・ストア」ページで、WebLogic ServerインスタンスのIDと信頼できるキー・ストアを構成します。これを行うには、WebLogic Serverオンライン・ヘルプの「IDとトラストの構成」を参照してください。

56.4.1 サンプルWSDLファイル

この項のサンプルWSDLファイルは、Service Busにおけるメッセージ・レベルのID伝播、機密性および整合性をWS-Policyに構成する方法を示します。

例 - メッセージ・レベルのセキュリティのWS-Policyへの構成

<?xml version='1.0' encoding='UTF-8'?>
<definitions name="SecureHello WorldServiceDefinitions"targetNamespace=
"http://www.bea.com"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:s0="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
xmlns:s1="http://www.bea.com"
xmlns:s2="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:UsingPolicy xmlns:n1="http://schemas.xmlsoap.org/wsdl/"
n1:Required="true"/>
<wsp:Policy s0:Id="Encrypt.xml">
<wssp:Confidentialityxmlns:wssp="http://www.bea.com/wls90/
security/policy">
<wssp:KeyWrappingAlgorithm URI="http://www.w3.org/2001/04/
xmlenc#rsa-1_5"/>
<wssp:Target>
<wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/
04/xmlenc#aes256-cbc"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org
/2002/12/wsse#part">wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo>
<wssp:SecurityToken TokenType="http://docs.oasis-open.
org/wss/2004/01/oasis-200401-wss-x509-token-
profile-1.0#X509v3"/>
<wssp:SecurityTokenReference>
<wssp:Embedded>
<wsse:BinarySecurityToken EncodingType="http:
//docs.oasis-open.org/wss/2004/
01/oasis-200401-wss-soap-message
-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/
wss/2004/01/oasis-200401-wss-x509
-token-profile-1.0#X509v3"
xmlns:wsse="http://docs.oasis-open.org/
wss/2004/01/oasis-200401-wss-wssecurity-
secext-1.0.xsd">MIIB7DCCAZYCEN+FHomYRZU
YPLiIutc0lIIwDQYJKoZIhvcNAQEEBQAweTELMAk
GA1UEBhMCVVMxEDAOBgNVBAgTB015U3RhdGUxDzA
NBgNVBAcTBk15VG93bjEXMBUGA1UEChMOTXlPcmd
hbml6YXRpb24xGTAXBgNVBAsTEEZPUiBURVNUSU5
HIE9OTFkxEzARBgNVBAMTCkNlcnRHZW5DQUIwHhc
NMDYwNjA3MDQ0MDM2WhcNMjEwNjA4MDQ0MDM2WjB
6MQswCQYDVQQGEwJVUzEQMA4GA1UECBYHTXlTdGF
0ZTEPMA0GA1UEBxYGTXlUb3duMRcwFQYDVQQKFg5
NeU9yZ2FuaXphdGlvbjEZMBcGA1UECxYQRk9SIFR
FU1RJTkcgT05MWTEUMBIGA1UEAxYLYmFuZ3BsdHc
zazIwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAxv2
nWByAF2Xr9wrb06ydrrcqPt2VQa0xcwfdZZ6oGlj
1TXq+G5/Q82v7CdxjyWUQBuAzduQx9wFCrAe/aWV
pgQIDAQABMA0GCSqGSIb3DQEBBAUAA0EARbwfl8w
X915jL5reY+isriNF0EfUs5ck53WRNowiapJx2ea
ZE03quksJgeJ0z0HekkR/aTQnkMV1xIt1HxMKRw=
=</wsse:BinarySecurityToken>
</wssp:Embedded>
</wssp:SecurityTokenReference>
</wssp:KeyInfo>
</wssp:Confidentiality>
</wsp:Policy>
<wsp:Policy s0:Id="Auth.xml">
<wssp:Identity xmlns:wssp="http://www.bea.com/wls90/security/
policy">
<wssp:SupportedTokens>
<wssp:SecurityToken TokenType="http://docs.oasis-open.
org/wss/2004/01/oasis-200401-wss-username-token
-profile-1.0#UsernameToken">
<wssp:UsePassword Type="http://docs.oasis-open.
org/wss/2004/01/oasis-200401-wss-username
-token-profile-1.0#PasswordText"/>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Identity>
</wsp:Policy>
<wsp:Policy s0:Id="Sign.xml">
<wssp:Integrity SignToken='false' xmlns:wls="http://www.bea.com/wls90/security/
policy/wsee#part"xmlns:wssp="http://www.bea.com/wls90/
security/policy" xmlns:wsu="http://docs.oasis-open.org/wss
/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/
xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm URI="http://www.w3.org/
2001/10/ xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09
/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/
security/policy/wsee#part">
wls:SystemHeaders()
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09
/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/
security/policy/wsee#part">
wls:SecurityHeader(wsu:Timestamp)
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/
xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.
org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:SupportedTokens>
<wssp:SecurityToken IncludeInMessage="true" TokenType=
"http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-x509-token-profile-1.0#X509v3">
<wssp:TokenIssuer>CN=CACERT,OU=FOR TESTING ONLY,
O=MyOrganization,L=MyTown,ST=MyState,C=US,1.2.
840.113549.1.9.1=#160f737570706f7274406265612e636
f6d,CN=Demo Certificate Authority Constraints,OU=
Security,O=BEA WebLogic,L=San Francisco,ST=
California,C=US,1.2.840.113549.1.9.1=#16107365637
572697479406265612e636f6d,CN=Demo Certificate
Authority Constraints,OU=Security,O=BEA WebLogic,
L=San Francisco,ST=California,C=US,CN=CertGenCAB,
OU=FOR TESTING ONLY,O=MyOrganization,L=MyTown,ST=
MyState,C=US,CN=Equifax Secure eBusiness CA-1,O=
Equifax Secure Inc.,C=US,CN=VeriSign Class 1
Public Primary Certification Authority - G3,OU=
(c)1999 VeriSign\, Inc. - For authorized use only,
OU=VeriSign Trust Network,O=VeriSign\, Inc.,C=US,
OU=VeriSign Trust Network,OU=(c) 1998 VeriSign\,
Inc. - For authorized use only,OU=Class 2 Public
Primary Certification Authority - G2,O=VeriSign\,
Inc.,C=US,CN=VeriSign Class 3 Public Primary
Certification Authority - G3,OU=(c) 1999
VeriSign\,Inc. - For authorized use only,OU=
VeriSign Trust Network,O=VeriSign\,Inc.,C=US,CN=
Entrust.net Client Certification Authority,OU=(c)
2000 Entrust.net Limited,OU=www.entrust.net/
GCCA_CPS incorp. by ref. (limits liab.),O=Entrust
.net,OU=Go Daddy Class 2 Certification Authority,
O=The Go Daddy Group\, Inc.,C=US,CN=GTE Cyber
Trust Global Root,OU=GTE CyberTrust Solutions\,
Inc., O=GTE Corporation,C=US,CN=Entrust.net
Secure Server Certification Authority,OU=(c) 2000
Entrust.net Limited,OU=www.entrust.net/SSL_CPS
incorp. by ref. (limits liab.),O=Entrust.net,OU=
Class 1 Public Primary Certification Authority,
O=VeriSign\, Inc.,C=US,1.2.840.113549.1.9.1=#161
9706572736f6e616c2d6261736963407468617774652e636
f6d,CN=Thawte Personal Basic CA,OU=Certification
Services Division,O=Thawte Consulting,L=Cape
Town, ST=Western Cape,C=ZA,OU=VeriSign Trust
Network, OU=(c) 1998 VeriSign\, Inc. - For
authorized use only,OU=Class 1 Public Primary
Certification Authority - G2,O=VeriSign\, Inc.,
C=US,CN=Entrust.net Secure Server Certification
Authority,OU=(c) 1999 Entrust.net Limited,OU=
www.entrust.net/CPS incorp. by ref.(limits iab.),
O=Entrust.net,C=US, 1.2.840.113549.1.9.1=#161c706
572736f6e616c2d667265656d61696c407468617774652e63
6f6d,CN=Thawte Personal Freemail CA,OU=
Certification Services Div,O=Thawte Consulting, L
=Cape Town,ST=Western Cape,C=ZA,OU=Class 3 Public
Primary Certification Authority,O=VeriSign\, Inc.
C=US,CN=GTE CyberTrust Root,O=GTE Corporation,C=
US,CN=VeriSign Class 2 Public Primary Certificate
Authority - G3,OU=(c) 1999 VeriSign\, Inc. - For
authorized use only,OU=VeriSign Trust Network,O=
VeriSign\,Inc.,C=US,1.2.840.113549.1.9.1=#1617736
5727665722d6365727473407468617774652e636f6d,CN=
Thawte Server CA,OU=Certification Services
Division,O=Thawte Consulting cc,L=Cape Town,ST=
Western Cape,C=ZA,OU=Equifax Secure Certificate
Authority,O=Equifax,C=US,1.2.840.113549.1.9.1=#16
1b706572736f6e616c2d7072656d69756d407468617774652
e636f6d,CN=Thawte Personal Premium CA,OU=
Certification Services Division,O=Thawte
Consulting,L=Cape Town,ST=Western Cape,C=ZA,1.2.
840.113549.1.9.1=#16197072656d69756d2d73657276657
2407468617774652e636f6d,CN=Thawte Premium Server
CA,OU=Certification Services Division,O=Thawte
Consulting cc,L=Cape Town,ST=Western Cape,C=ZA,
OU=VeriSign Trust Network,OU=(c) 1998 VeriSign\,
Inc. - For authorized use only,OU=Class 3 Public
Primary Certification Authority - G2,O=VeriSign\,
Inc.,C=US,CN=Entrust.net Certification Authority
(2048),OU=(c) 1999 Entrust.net Limited,OU=www
.entrust.net/CPS_2048 incorp. by ref. (limits
liab.),O=Entrust.net,1.2.840.113549.1.9.1=#1611
696e666f4076616c69636572742e636f6d,CN=http://www.
valicert.com/,OU=ValiCert Class 2 Policy
Validation Authority,O=ValiCert\, Inc.,L=Vali
cert Validation Network,CN=Baltimore CyberTrust
Root, OU=CyberTrust,O=Baltimore,C=IE,OU=Secure
Server Certification Authority,O=RSA Data
Security\, Inc.,C=US,CN=Entrust.net Client
Cert Authority,OU=(c) 1999 Entrust.net Limited,
OU=www.entrust.net/Client_CA_Info/CPS incorp. by
ref. limits liab.,O=Entrust.net,C=US,CN=GeoTrust
Global CA,O=GeoTrust Inc.,C=US,CN=GTE CyberTrust
Root 5,OU=GTE CyberTrust Solutions\, Inc.,O=GTE
Corporation,C=US,OU=Starfield Class 2
Certification Authority,O=Starfield
Technologies\, Inc.,C=US,CN=Equifax Secure
Global eBusiness CA-1,O=Equifax Secure Inc.,C=US,
CN=Baltimore CyberTrust Code Signing Root,OU=
CyberTrust,O=Baltimore,C=IE,OU=Class 2 Public
Primary Certification Authority,O=VeriSign\,
Inc.,C=US,OU=Equifax Secure eBusiness CA-2,O=
Equifax Secure,C=US,</wssp:TokenIssuer>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Integrity>
<wssp:MessageAge Age="60" xmlns:wssp="http://www.bea.com/wls90/
security/policy"/>
</wsp:Policy>
<types>
<xs:schema attributeFormDefault="unqualified" elementFormDefault=
"qualified" targetNamespace="http://www.bea.com" xmlns:s0="
http://www.bea.com" xmlns:s1="http://schemas.xmlsoap.org
/wsdl/soap/" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/
09/policy" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="sayHello">
<xs:complexType>
<xs:sequence>
<xs:element name="s" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="sayHelloResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="return" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</types>
<message name="sayHello">
<part element="s1:sayHello" name="parameters"/>
</message>
<message name="sayHelloResponse">
<part element="s1:sayHelloResponse" name="parameters"/>
</message>
<portType name="SecureHelloWorldPortType" wsp:PolicyURIs="#Sign.xml
#Auth.xml #Encrypt.xml">
<operation name="sayHello" parameterOrder="parameters">
<input message="s1:sayHello"/>
<output message="s1:sayHelloResponse"/>
</operation>
</portType>
<binding name="SecureHelloWorldServiceSoapBinding" type="s1:
SecureHelloWorldPortType">
<s2:binding style="document" transport="http://schemas.
xmlsoap.org/ soap/http"/>
<operation name="sayHello">
<s2:operation soapAction="" style="document"/>
<input>
<s2:body parts="parameters" use="literal"/>
</input>
<output>
<s2:body parts="parameters" use="literal"/>
</output>
</operation>
</binding>
<service name="SecureHelloWorldService">
<port binding="s1:SecureHelloWorldServiceSoapBinding"
name="SecureHelloWorldServicePort">
<s2:address location="http://localhost:9111/
SecureHelloWorldService/SecureHelloWorld
Service"/>
</port>
</service>
</definitions>

第IX部 Oracle Service Busサービスの完了

この部では、作成したService Busサービスをデバッグおよびテスト・ツールを使用してテストする方法、およびそれらのサービスをデプロイする方法について説明します。

この部は、次の章で構成されています。

- Oracle Service Busアプリケーションのデバッグ

- テスト・コンソールの使用

- Oracle Service Busサービスのデプロイ

- Oracle Service Bus開発Mavenプラグインの使用

57 Oracle Service Busアプリケーションのデバッグ

この章では、メッセージ・フローでブレークポイントを設定し、JDeveloperデバッガを使用して、Service Busのパイプラインおよび分割-結合をデバッグする方法を説明します。次の項が含まれます:

- デバッガの概要

- プロジェクトおよびデバッガの構成

- デバッガへのアクセス

- Service Busアプリケーションのデバッグ

- デバッガ・ウィンドウでの操作

57.1 デバッガの概要

JDeveloperは、Service Busプロジェクト・コンポーネントを評価し強化するために役立つ包括的な統合デバッガを提供します。デバッガは、開発環境内に直接トラブルシューティング機能を提供することで、開発サイクルを短縮します。つまり、JDeveloperでService Busアプリケーションを構築して実行し、JDeveloperに戻って問題を修正し、これらの手順を繰り返すという必要はありません。かわりに、パイプラインと分割-結合をトラブルシューティングするためのブレークポイントをJDeveloper内で直接設定できます。

デバッガでは、Javaコールアウトを処理できます。また、並列処理を使用する分割-結合でのマルチ・スレッド・デバッグをサポートします。デバッガを使用するときは次のガイドラインに留意してください。

- デバッグは、JDeveloperのデザイン・ビューに制限されています。

- Javaコールアウト・アクション、XQueryの変換など、ほとんどの言語間機能はデバッグできません。XSLTマップのデバッグは、12.2.1リリースで新しくサポートされています。詳細は、「XSLTエディタのデバッグ・サポート」を参照してください。

- 一度に1つのクライアントのみがデバッガに接続できます。

- サーバーが開発モードの場合にのみデバッグできます。

- デバッガは本番モード、あるいはサーバーがクラスタの一部か非クラスタドメインの管理サーバーと1つ以上の管理対象サーバーの場合には有効にできません。

- SOAデバッガを使用するその他のガイドラインについては、Oracle SOA SuiteでのSOAアプリケーションの開発のSOAデバッガの概要に関する項を参照してください。

デバッガ・ウィンドウの一般的な情報は、『Oracle JDeveloperによるアプリケーションの開発』のJavaプロジェクトの実行およびデバッグに関する項を参照してください。

57.1.1 デバッグ・サーバー

統合またはスタンドアロンのWebLogic ServerにデプロイされているService Busコンポーネントをデバッグできます。JDeveloperではローカル統合WebLogic Serverインスタンスのライフサイクルを管理できます。ローカル統合サーバーを構成する場合は、「JDeveloperでこのサーバー・インスタンスのライフサイクルを管理します」を選択できます。この構成では、JDeveloperは、ユーザーが実行コマンドまたはデバッグ・コマンドを選択したときにサーバーを起動します。統合サーバーがJDeveloperによって管理されるように構成されていない場合は、サーバーを手動で起動および停止する必要があります。ただし、引き続き実行コマンドを使用して、テストするサービスをサーバーにデプロイできます。統合サーバーがリモートの場合、「JDeveloperでこのサーバー・インスタンスのライフサイクルを管理します」は選択しないでください。

デバッグ用にスタンドアロン・サーバーを使用する場合は、それがローカルであるか、リモートであるかに関係なく構成は同じです。アプリケーション・プロパティでサーバーを構成する必要はありません。スタンドアロン・サーバーでは、アプリケーション・ナビゲータから実行コマンドを使用できません。そのかわりに、デプロイ・コマンドを使用してService Busアプリケーションをサーバーに手動でデプロイし、テスト・コンソールを手動で起動する必要があります。

57.1.2 ローカルおよびリモートでのデバッグ

デバッグは、ローカルまたはリモートのいずれかのWebLogic Serverで実行できます。ローカルのデバッグ・セッションは、ソース・ファイルにブレークポイントを設定してからデバッガを起動することで、開始されます。Service Busコンポーネントのデバッグ時には、実行フローを完全に制御し、変数の値を表示および変更できます。

リモート・デバッグには、デバッガとデバッグ対象の2つのJDeveloperプロセスが必要です。デバッグ対象は実行中のサーバーで、JDeveloperで定義されている場合もあれば定義されていない場合もあり、異なるプラットフォームに常駐していることもあります。デバッグ対象サーバーには、Service Busアプリケーションがデプロイされている必要があります。リモート・デバッグを実行するには、「リモート・デバッグ用実行構成の作成方法」に説明されているとおり、プロジェクト・プロパティで実行構成を構成する必要があります。

57.1.3 ブレークポイントを使用したデバッグ

ブレークポイントは、パイプラインまたは分割-結合内でメッセージ処理を一時停止するポイントをマークします。これによって、一部またはすべてのメッセージ変数の値を確認できます。メッセージ・フローの考えられる問題領域にブレークポイントを設定することで、デバッグする位置に達するまでメッセージ・フローを通じてデータを実行できます。ブレークポイントに達すると、メッセージ処理は一時停止し、デバッガはソース・エディタ内のブレークポイントを含むアクションに着目します。その後、デバッガを使用してプログラムの状態を表示できます。ブレークポイントは、デバッグを開始する前に、またはデバッグ中に随時、柔軟に設定できます。

ブレークポイントは、パイプライン上の次のノードに追加できます。

- ルート・ノード

- ルート・アクション

- ブランチ・ノード

- パイプライン・ペア・パス(リクエストまたはレスポンス)

- ステージ(パイプライン・ペアとエラー・ハンドラの両方)

- ステージ・アクション(パイプライン・ペアとエラー・ハンドラの両方)

すべての分割-結合アクションにブレークポイントを追加できますが、Ifノードでブレークポイントを切り替えると、Ifノード自体ではなく、Ifノード内のIf条件のブレークポイントが切り替わります。

57.1.3.1 条件ブレークポイントについて

指定した条件がtrueのとき、条件ブレークポイントでコード実行が停止します。条件ブレークポイントは、このリリースのService BusおよびJDeveloperでサポートされています。Service Busアプリケーションのデバッグに使用するブレークポイントには、条件を追加できます。

trueまたはfalseを評価する有効なJavaScript式を、ブレークポイントの条件式として使用できます。式がtrueと評価された場合、または式が無効であるか、ブール値として評価されない場合は、実行が停止されます。ブレークポイントに有効な条件式は1つのみにしてください。

また、パス数を使用すると、トリガーされなくても、指定した回数までブレークポイントをパスした場合にコード実行が停止されます。条件式とパス数は同時に使用できます。

詳細は、次のトピックを参照してください。

- ブレークポイント・オプションの編集方法: ブレークポイントの「条件」タブの編集による、条件式またはパス数の追加

- 条件式の動作: JDeveloperでの条件式の動作

- パス数について: JDeveloperでのパス数の動作

- 条件式およびパス数の同時使用: 条件式とパス数の同時使用

57.1.3.1.1 条件式の動作

JDeveloperでService Busコンポーネントをデバッグする場合に、ブレークポイントに条件式を作成するときは、これらのガイドラインに従います。

式は最上位のスタック・フレームのデータ値のみを参照する可能性があります。図57-1に示す例について考えます。

図57-1 JDeveloperのデータ値

この例では、次の式のいずれも有効な条件式になります。

- $inbound.security.transportClient.username == “fred”

- $body.search(“aqz3”)

- $messageID.indexOf(“8087”) > -1

Service Busのほとんどのデータ値がXMLタイプであるため、1つの親の元に同じ名前のアイテムが複数ある場合があります。この構造のタイプは、条件式で配列として扱います。図57-1の$inbound.security.transportClient.principalsの構造について考えます。この場所には、4つの要素があります。このグループの特定の要素にアクセスするには、次の条件式を使用できます。

- $inbound.security.transportClient.principals[0] == “AdminChannelUsers”

- $inbound.security.transportClient.principals[3] == “Monitors”

図57-1では、$outbound変数の値はnullです。この場合、nullは文字列値です。null文字列値を表現する、正しい条件式は$outbound == “null”です。$outbound変数の値がない場合は、正しい条件式は$outbound == “”になります。

条件式では、空白は変数名の文字として使用できません。変数名の空白は、アンダースコア(_)に変更する必要があります。図57-1のJava Repository変数を例として使用すると、変数は、条件式でJava_Repository.jcid:null == “ref”のように参照され、変数名(Java Repository)はアンダースコアに置換されます(Java_Repository)。

57.1.3.1.2 条件式の実行時評価エラー

条件式が(論理的または構文上)無効な式の場合や、なんらかの理由でブール値として評価されない場合、評価に失敗したことが通知されます。

これらの通知は、クリアしなければ、残りのJDeveloperセッションにも使用できます。通知の他にも、JDeveloperは条件式の評価エラーをログに記録します。

57.1.3.1.3 スレッド・オプションについて

スレッド・オプションは、Service Busアプリケーションのデバッグではサポートされていません。

57.1.3.1.4 パス数について

パス数は、停止するまでにブレークポイントをパスする実行中の回数を指定する値です。この値に達すると、ブレークポイントでコード実行を停止します。パス数は、このバージョンのService BusおよびJDeveloperのブレークポイントでサポートされています。

「パス数」が設定されているブレークポイントをプロセスの実行に使用する場合、デバッガはカウント数を1ずつ減らし、それを0と比較します。結果がゼロでない場合、実行はそのブレークポイントで停止せずに続行されます。結果がゼロの場合、実行はそのブレークポイントで停止します。パス数が一致した後、現在のプロセスの残りについてもブレークポイントごとに実行が停止します。

注意:

パス数がゼロに達した後、次に示すように、パス数がリセットまたはクリアされるまでブレークポイントごとに実行が停止します。

パス数は次の場合にリセットされます。

- デバッグ・セッションが終了し、再開したとき。

- 「ブレークポイントの編集」ダイアログの「パスの回数」フィールドの値を更新したとき。

ブレークポイントからパス数をクリアするには、「ブレークポイントの編集」ダイアログでその値をゼロに設定します。

57.1.3.1.5 条件式およびパス数の同時使用

ブレークポイントには、条件式とパス数の両方を指定できます。両方が設定されている場合、式はtrueと評価され、さらに実行中にそのパス数に達すると指定のブレークポイントで停止します。

例に示すとおり、条件式がtrueと評価されても、パス数が10で設定されている場合、パス数の条件も一致するまでは、このブレークポイントで実行が停止しません。パス数と条件の両方が指定されている場合は、常にパス数が最初にチェックされ、ゼロに達していなければ減少します。パス数に達した場合、ブレークポイントに達するたびに条件式が評価されます。

57.1.3.2 例外ブレークポイントについて

どの位置で実行を停止するかを指定する標準のブレークポイントとは異なり、例外ブレークポイントは、指定したタイプの例外の発生源で実行を停止します。例外ブレークポイントは、このリリースのService BusおよびJDeveloperでサポートされています。例外ブレークポイントは、パイプラインと分割-結合に対して作成できます。

例外ブレークポイントがトリガーされると、デバッグ・フレームワークが通知され、実行を停止する位置が示されます。実行が停止されると、次の情報について確認できます。

- 発生した例外タイプ。これはワイルドカードを使用して例外ブレークポイントを作成した場合に役立ちます

- 例外に関するメッセージ

- ランタイムでスローされたベースとなる例外のスタック・トレース(使用可能な場合)

- 実行が停止したときのスタック・フレームおよびデータ値。

有効な複数の例外ブレークポイントが発生した例外タイプと一致する場合、デバッグ・フレームワークでは、例外と完全に一致するブレークポイント(たとえば、ワイルドカードを使用していない例外ブレークポイントなど)、またはワイルドカードが設定されている最初のブレークポイントが選択されます。

例外ブレークポイントでは、条件式とパス数がサポートされています。条件式とパス数に関する詳細は、「条件ブレークポイントについて」を参照してください。

Service Busコンポーネントでの例外ブレークポイントの使用に関する詳細は、次のトピックを参照してください。

- Service Busコンポーネントに例外ブレークポイントを設定する方法

- パイプライン例外ブレークポイント

- 分割-結合例外ブレークポイント

57.1.3.2.1 パイプライン例外ブレークポイント

パイプライン・ランタイムはPipelineException例外をスローします。PipelineExceptionsには、(エラーの生成アクションを使用して)設定できるエラー・コード、または各アクションごとに設定されるエラー・コードが含まれます。

パイプライン例外ブレークポイントには、次の例外タイプを選択できます。

- すべてのパイプライン例外: このタイプを使用すると、任意のパイプライン例外が(特に明示的なエラー・コードがなく)スローされたときに、実行が停止されます。

- パイプライン例外: このタイプを使用すると、明示的なエラー・コードのあるパイプライン例外がスローされたときに実行が停止されます。たとえば、382510を「エラー・コード」フィールドに入力すると、エラー・コード382510のパイプライン例外がスローされたときに実行が停止されます。

ヒント:

「エラー・コード」フィールドにアスタリスク(*)を入力すると、任意のパイプライン固有の例外を検索できます。

- システム例外: このタイプは、ランタイムによってスローされる、予期しない例外に使用します。

パイプライン例外ブレークポイントの追加については、「Service Busコンポーネントに例外ブレークポイントを設定する方法」を参照してください。

57.1.3.2.2 分割-結合例外ブレークポイント

分割-結合はBPEL言語に基づいています。BPELエラー処理フレームワークでは、フォルトおよびフォルト・ハンドラを使用します。フォルトはQNamesによって定義されます。分割-結合には一連のBPEL言語定義フォルトがあります。また、独自のフォルトを手動で定義するか、WSDLフォルトを使用して定義できます。

分割-結合例外ブレークポイントには、次の例外タイプを選択できます。

- すべての分割-結合例外: このタイプを使用すると、任意の分割-結合例外がスローされたときに、実行が停止されます。

- すべてのシステム例外: この例外タイプを使用すると、任意のランタイム例外がスローされたときに、実行が停止されます。

- 分割-結合例外: このタイプを使用すると、特定の分割-結合エラーがスローされたときに、実行が停止されます。たとえば、userFaultを「エラー・コード」フィールドに入力すると、userFaultという分割-結合エラーがスローされたときに実行が停止されます。

- システム例外: このタイプを使用すると、特定のランタイム・エラーがスローされたときに、実行が停止されます。

分割-結合例外ブレークポイントの追加については、「Service Busコンポーネントに例外ブレークポイントを設定する方法」を参照してください。

57.1.4 JDeveloperデバッグ・ウィンドウ

JDeveloperは、デバッガとともにいくつかの異なるデバッグ・ウィンドウを提供します。これらのウィンドウで、デバッグ・プロセスを経過中のデータを表示および分析できます。Service Busは次のデバッグ・ウィンドウを使用します。

- ブレークポイント

- データ

- ウォッチ

- スタック

- スレッド

- ログ

これらのウィンドウの詳細は、『Oracle JDeveloperによるアプリケーションの開発』のデバッガ・ウィンドウの使用方法に関する項を参照してください。

57.1.5 XSLTエディタのデバッグ・サポート

12.2.1以降、JDeveloperが拡張され、SOAデバッガを使用してXSLTマップをデバッグできるようになりました。

この機能は、Service Bus分割-結合エディタとパイプライン・エディタ、およびJDeveloperのXSLTテスト・ツールから起動できます。XSLTマップ・エディタでのXSLTマップのデバッグおよびブレークポイントの設定については、Oracle SOA SuiteでのSOAアプリケーションの開発のXSLTマップのデバッグに関する項を参照してください。

57.2 プロジェクトおよびデバッガの構成

デバッグ・プロセスを制御するため、プロジェクトおよびデバッガの設定を構成できます。プログラムのデバッグまたは実行方法を制御する設定は実行構成で定義されます。これらの設定には、ターゲット、起動オプションおよびデバッガ、ログ出力、プロファイラの動作などが含まれます。Service Busは、ローカルでのデバッグおよびテスト用のデフォルトの実行構成を提供していますが、新しい構成を作成することもできます。1つのプロジェクトに、それぞれプロジェクトの特定のファセットまたは開発プロセスのフェーズに対応して設定されている複数の実行構成が存在する場合があります。実行構成は、プロジェクトにバインドされ、プロジェクトで作業する全員が使用できる場合もあれば、自分専用のカスタム構成の場合もあります。

これらの手順はオプションで、統合サーバーでデフォルト構成を使用してローカル・デバッグを実行できます。詳細と手順は、『Oracle JDeveloperによるアプリケーションの開発』の次のトピックを参照してください。

- デバッグ用にプロジェクトを構成する方法

- デバッガ開始オプションの設定方法

- 実行用のプロジェクトの構成

57.2.1 リモート・デバッグ用に実行構成を作成する方法

Service Busが提供するデフォルト構成などの既存の構成をコピーして、新しい実行構成を作成します。コピー後に、新しい構成に応じて設定を変更します

リモート・デバッグ用に実行構成を作成するには:

ヒント:

実行構成ウィンドウで作業するウィンドウとフィールドの詳細を参照するには、「ヘルプ」をクリックしてください。

1. メイン・メニューから「アプリケーション」をクリックし、「プロジェクト・プロパティ」を選択します。

2. ナビゲーション・ペインで、「実行/デバッグ」を選択し、「実行/デバッグ」ページで「新規」をクリックします。

3. 「実行構成の作成」ダイアログで、新しい構成の名前を入力し、初期プロパティのコピー元となる既存の実行構成を選択します。

4. 「OK」をクリックします。

5. 「実行/デバッグ」ページの「実行構成」セクションで、作成した構成を選択し、「編集」をクリックします。

「実行構成の編集」ウィンドウが現れ、「起動設定」ページが表示されます。

6. 「リモート・デバッグ」を選択し、必要に応じてその他のフィールドを変更します。

7. ナビゲーション・ペインで、「ツール設定」→「デバッガ」の下の「リモート」を選択します。

8. 「プロトコル」フィールドで「Service Busにアタッチ」を選択します。

9. 以下のいずれか、または両方を実行します。

- この実行構成が選択されたときに特定のサーバーに自動的に接続するには、ホスト名、ポート番号およびタイムアウト値を入力します。

- この実行構成の選択時にホスト情報を入力できるダイアログを表示するには、「デバッガ接続前にダイアログ・ボックスを表示」を選択します。

前述の両方の手順を実行すると、実行構成の選択時にダイアログが表示され、指定した接続情報がすでに移入されています。

10. 「OK」をクリックし、さらに再度「OK」をクリックします。

11. 「保存」をクリックします。

57.2.2 デバッグ用の実行構成を作成する方法

デフォルトの実行構成は、新しいプロジェクトごとに作成され、ローカル・デバッグに統合WebLogic Serverを使用します。このデフォルト構成または作成した他の構成を選択して、選択したプロジェクトを実行できます。JDeveloperツールバーからデバッガを実行する場合は、「デバッグ」アイコンの横にある使用可能な構成オプションのリストから実行構成を選択できます。

デバッグ用に実行構成を選択するには:

1. メイン・メニューから「アプリケーション」をクリックし、「プロジェクト・プロパティ」を選択します。

2. 「実行/デバッグ」を選択します。

3. 「実行構成」リストで、使用する実行構成を選択して、「OK」をクリックします。

57.3 デバッガへのアクセス

JDeveloperデバッガを起動する方法は複数あります。この章に記載された手順では、アプリケーション・ナビゲータを使用してデバッガを起動しますが、準備が整った時点で次のいずれかの方法を使用してデバッガを起動できます。

- アプリケーション内のプロジェクトまたはコンポーネントを右クリックし、「デバッグ」を選択します。

- JDeveloperツールバーで、「デバッグ」アイコンをクリックします。デバッグ・プロセスは選択された実行構成を使用します。「デバッグ用に実行構成を選択する方法」を参照してください。

- Service Busコンポジット概要エディタでパイプラインまたは分割-結合を右クリックし、「デバッグ」を選択します。

- 開かれたパイプラインまたは分割-結合のエディタ内を右クリックし、「デバッグ」を選択します。

57.4 Service Busアプリケーションのデバッグ

この項では、JDeveloperでデバッガの起動、ブレークポイントの作成、およびService Busアプリケーションのデバッグを実行する方法を説明します。テスト・コンソールとデバッガを使用する以外にもデバッグする方法があります。JMSメッセージのポスト、ファイル・プロキシ・サービスのディレクトリへの入力ファイルの配置など、他の方法でサービスを実行することもできます。

- Service Busコンポーネントにブレークポイントを設定する方法

- ブレークポイントを使用してデバッグする方法

- デバッグ・セッションでのステップ実行方法

- デバッグから終了または連結解除する方法

57.4.1 Service Busコンポーネントにブレークポイントを設定する方法

ブレークポイントは、デバッグ・プロセス用に設定されるService Busアプリケーション内の意図的な一時停止位置です。テスト・コンソールを使用してテスト・データを実行すると、プロセスはブレークポイントごとに一時停止し、ユーザーが指示するまで再開しません。ブレークポイントは、パイプラインと分割-結合に設定できます。

Service Busコンポーネントにブレークポイントを設定するには:

1. デバッグするパイプラインまたは分割-結合をエディタで開きます。

2. ブレークポイントを追加するノードが表示されるまで、アクションを開きます。

3. ノードを右クリックし、「ブレークポイントの設定」を選択します。

ノードの横に、ブレークポイントが設定されていることを示す赤いアイコンが表示されます。

4. 前述の手順を、ブレークポイントを追加するノードごとに繰り返します。

5. ブレークポイントを無効にするには、ノードを右クリックし、「ブレークポイントを無効化」を選択します。

「ブレークポイントを削除または無効にする方法」および「無効なブレークポイントを有効にする方法」に説明されているとおり、ブレークポイント・ビューでブレークポイントを有効化、無効化および削除することもできます。

6. ブレークポイントを削除するには、ノードを右クリックし、「ブレークポイントの設定」を再度選択します。

7. 「ブレークポイントを使用してデバッグする方法」に説明されているとおり、デバッグを開始します。

57.4.2 Service Busコンポーネントに例外ブレークポイントを設定する方法

例外ブレークポイントは、設定されているポイントでは実行を停止しません。例外ブレークポイントは、特定の位置ではなく、JDeveloperの「ブレークポイント」ウィンドウで設定します。

Service Busコンポーネントに例外ブレークポイントを設定するには:

1. JDeveloperで、「ブレークポイント」ウィンドウに進みます。このウィンドウが表示されていない場合は、「ウィンドウ」メニューから「ブレークポイント」を選択してウィンドウを開きます。

2. 「ブレークポイントの追加」アイコンをクリックし、次にパイプライン例外ブレークポイントまたは分割-結合例外ブレークポイントを選択して、選択したタイプの例外ブレークポイントを追加します。

3. 「定義」タブで、「例外タイプ」リストからこのブレークポイントに使用する例外タイプを選択します。

パイプラインおよび分割-結合例外ブレークポイントで使用可能な例外タイプについては、「パイプライン例外ブレークポイント」および「分割-結合例外ブレークポイント」を参照してください。

4. 選択したタイプでサポートされている場合は、特定の例外エラー・コードを「エラー・コード」フィールドに入力するか、アスタリスク(*)を入力すると、選択したタイプの例外がスローされたときに実行が停止されます。

5. (オプション)必要に応じて、「条件」および「アクション」タブでオプションを構成します。

6. 「OK」をクリックします。

例外ブレークポイントが作成されます。例外ブレークポイントはデフォルトで有効になっています。

57.4.3 ブレークポイントを使用してデバッグする方法

ローカル・サーバーを使用してコンポーネントをデバッグする場合は、デバッグ・プロセスに入力情報を入力できるようにテスト・コンソールが起動されます。統合WebLogicサーバーを使用する場合は、ローカルでのみテストできます。プロジェクトのプロパティで、ローカルでテストするか、リモートでテストするかを指定します。また、デバッグ中のブレークポイントの処理方法も構成できます。

これらのオプションの設定方法の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のデバッグ用にプロジェクトを構成する方法およびデバッガ起動オプションの設定方法に関する項を参照してください。

ブレークポイントを使用してコンポーネントでデバッグを開始するには:

1. 「Service Busコンポーネントにブレークポイントを設定する方法」の説明に従って、デバッグするコンポーネントのブレークポイントを定義します。

2. アプリケーション・ナビゲータでパイプラインまたは分割-結合を右クリックし、「デバッグ」を選択します。

テスト・コンソールが表示されます。

注意:

実行中のドメインがない場合は、「デフォルト・ドメインの作成」ダイアログが表示されます。統合サーバーの接続情報を入力し、「OK」をクリックします。これには数分かかることがあります。

3. 「リクエスト・ドキュメント」セクションにテスト・データを入力し、追加の入力を構成します。

詳細は、「テスト・コンソールの使用」を参照してください。

4. テスト・コンソールで「実行」をクリックします。

テスト・コンソールはコマンドを実行しますが、最初のブレークポイントに達すると一時停止し、パイプラインまたは分割-結合のエディタに戻ります。この時点でブレークポイント・アイコンは、デバッガが停止されていることを示す赤色ではなく青色になります。

5. JDeveloperの下部の「ログ」ウィンドウで、「データ」をクリックします。

このウィンドウで、処理中の現在の状態の変数値を表示できます。ここで実行できる操作の詳細は、「デバッガ・ウィンドウでの操作」を参照してください。

6. メッセージ処理で操作を続行するには、「デバッグ・セッションでのステップ実行方法」のステップを実行します。

57.4.4 デバッグ・セッションでのステップ実行方法

デバッグ・フレームワークを使用すると、デバッグ・コードに対してステップ・アクションを実行してインクリメンタルにデバッグできます。メッセージ・フロー部分に対してステップ実行し、同じまたは異なるコンポーネントの異なるブレークポイントなどの異なる位置でデバッグを開始できます。デバッグが進行するにつれ、ブレークポイント用の追加のフレームが作成され、スタック・ビューが表示されます。

次のステップで示されるすべてのアイコンが、ツールバーの「デバッグ」アイコンの右側にあります。アイコンにポインタを重ねると、アイコンの名前が表示されます。

デバッグ・セッションでステップ実行するには:

1. 「ブレークポイントを使用してデバッグする方法」の説明に従って、パイプラインまたは分割-結合のデバッグを開始します。

デバッガがブレークポイントに到達すると、ステップ実行を開始できます。

2. 現在のどのブレークポイントでアクションが停止しているかを確認するには、「実行ポイントの検索」アイコンをクリックします。

現在のブレークポイント・アイコンは赤色ではなく青色です。

3. ブレークポイントでステップ実行し、次のアクションに移動するには、「ステップ実行」アイコンをクリックします。

4. メッセージ・フローの次の有効な位置にステップ・インするには、「トレース実行」アイコンをクリックします。

5. ブレークポイント・フレームからステップ・アウトするには、「ステップ・アウト」アイコンをクリックします。

6. デバッガがブレークポイントで一時停止している場合は、「再開」をクリックして処理を再開します。プロセスは、次のブレークポイントに達するまで実行されます。

57.4.5 デバッグから終了または連結解除する方法

デバッグを停止するには、デバッガを連結解除するか、または終了します。

デバッグ・セッションを終了または連結解除するには:

1. ツール・メニューで「終了」アイコンをクリックします。

デバッガ・プロセスの終了ダイアログが表示されます。

2. 「デタッチ」または「終了」を選択します。

両オプションとも、デバッガのサーバーへの接続を終了しますが、プロセスは完了するまでサーバー上で実行を継続します。

3. 「連結解除」を選択した場合、デバッグを再開するにはツール・メニューのデバッガ・アイコンをクリックします。

57.5 デバッガ・ウィンドウでの操作

デバッグ・セッションを開始すると、「ログ」ウィンドウにいくつかのタブが表示され、デバッグ・プロセスに役立つ追加情報と機能が示されます。これらのウィンドウは、「ウィンドウ」→「デバッガ」メニューから開くこともできます。

57.5.1 ブレークポイント・オプションの編集方法

「ブレークポイント」ウィンドウでは、ブレークポイントをグループに追加し、グループ内のすべてのブレークポイントを有効化または無効化できます。また、ロギング、サウンドおよびブレークポイントに達したら処理を停止するかどうかも構成できます。デバッグ・セッションの内側または外側のいずれにいる場合でも、「ブレークポイント」ウィンドウは使用可能です。

ブレークポイントのオプションを表示および変更するには:

1. 「ブレークポイント」ウィンドウが開いていない場合は、メイン・メニューから「ウィンドウ」→「ブレークポイント」を選択します。

2. ブレークポイントを右クリックして「編集」を選択するか、またはブレークポイントを選択して、ブレークポイント・ツールバーの「編集」アイコンをクリックします。

「ブレークポイントの編集」ダイアログが表示され、「定義」タブ、「条件」タブおよび「アクション」タブが示されます。

3. ブレークポイント・オプションに必要な変更を加えます。

「定義」および「アクション」タブの詳細を参照するには、「ヘルプ」をクリックしてください。

4. 変更を保存するため、「OK」をクリックします。

57.5.2 ブレークポイント・グループの作成方法

ブレークポイント・グループを作成することで、ブレークポイントに対して一括編集を実行できます。グループを作成すると、新しいノードが「ブレークポイント」ウィンドウに追加され、グループに追加されたブレークポイントがそのグループ・ノードの下に表示されます。

57.5.2.1 ブレークポイント・グループの作成

ブレークポイント・グループを作成するには:

1. 「ブレークポイント」ウィンドウが開いていない場合は、メイン・メニューから「ウィンドウ」→「ブレークポイント」を選択します。

2. ブレークポイントを右クリックして「編集」を選択するか、またはブレークポイントを選択して、ブレークポイント・ツールバーの「編集」アイコンをクリックします。

「ブレークポイントの編集」ダイアログが現れ、「定義」タブが表示されます。

3. 「ブレークポイントのグループ名」フィールドにグループの新しい名前を入力します。

4. 変更を保存するため、「OK」をクリックします。

新しいグループが「ブレークポイント」ウィンドウに追加され、ブレークポイントがそのグループに追加されます。

57.5.2.2 既存のグループへのブレークポイントの追加

ブレークポイントを既存のグループに追加するには:

1. 「ブレークポイント」ウィンドウが開いていない場合は、メイン・メニューから「ウィンドウ」→「ブレークポイント」を選択します。

2. ブレークポイントを右クリックして「編集」を選択するか、またはブレークポイントを選択して、ブレークポイント・ツールバーの「編集」アイコンをクリックします。

「ブレークポイントの編集」ダイアログが現れ、「定義」タブが表示されます。

3. 「ブレークポイントのグループ名」フィールドで、ブレークポイントを追加するグループの名前を選択します。

4. 変更を保存するため、「OK」をクリックします。

57.5.3 ブレークポイントを削除または無効にする方法

個々のブレークポイントまたはすべてのブレークポイントを無効化するか、または削除できます。

ブレークポイントを削除または無効化するには:

1. 個々のブレークポイントを削除するには、パイプラインまたは分割-結合エディタでブレークポイントに関連付けられたアクションを右クリックし、「ブレークポイントの設定」を選択します。また、「ブレークポイント」ウィンドウでブレークポイントを選択して、「削除」をクリックすることもできます。例外ブレークポイントは、「ブレークポイント」ウィンドウを使用して削除する必要があります。

2. すべてのブレークポイントを削除するには、「ブレークポイント」ウィンドウを右クリックし、「すべて削除」を選択します。

3. 個々のブレークポイントを無効にするには、パイプラインまたは分割-結合エディタでブレークポイントに関連付けられたアクションを右クリックし、「ブレークポイントを無効化」を選択します。また、「ブレークポイント」ウィンドウでブレークポイントを選択して、「無効化」をクリックすることもできます。例外ブレークポイントは、「ブレークポイント」ウィンドウを使用して無効化する必要があります。

4. すべてのブレークポイントを無効にするには、「ブレークポイント」ウィンドウを右クリックし、「すべて無効化」を選択します。

57.5.4 無効なブレークポイントを有効にする方法

ブレークポイントを無効にした場合、それを再度有効にして、デバッグ・プロセスに含めることができます。

ブレークポイントを有効にするには:

1. 個々のブレークポイントを有効にするには、パイプラインまたは分割-結合エディタでブレークポイントに関連付けられたアクションを右クリックし、「ブレークポイントの有効化」を選択します。また、「ブレークポイント」ウィンドウでブレークポイントを選択して、「有効化」をクリックすることもできます。例外ブレークポイントは、「ブレークポイント」ウィンドウを使用して有効化する必要があります。

2. 設定されているすべてのブレークポイントを有効にするには、「ブレークポイント」ウィンドウを右クリックし、「すべて有効化」を選択します。

57.5.5 現在のブレークポイントの変数値の表示および変更方法

「データ」ウィンドウには、現在のブレークポイントのコンテキスト変数とその値が表示されます。デバッグ・プロセス全体を通じたリクエストまたはレスポンス・データを表示し、さらにデバッグするためにそれらの値を変更できます。単純型の変数値のみを変更できます。

変数値を表示および変更するには:

1. デバッグを開始し、デバッガがブレークポイントに達した時点で、「ログ」ウィンドウの「データ」タブをクリックします。

2. 「名前」列で変数を開き、各変数とノードの値を表示します。

3. 変数値を変更するには、値をダブルクリックし、表示されたダイアログに新しい値を入力します。

4. 変数値を定義する文字列全体を表示するには、変数を右クリックして、「全値の表示」を選択します。

57.5.6 監視の追加方法

ウォッチを使用して、プログラムの実行につれて変化する変数や式の値をモニターできます。ウォッチ式を入力後、「ウォッチ」ウィンドウに式の現在の値が表示されます。プログラムの実行に伴い、プログラムがウォッチ式の変数の値を更新すると、ウォッチの値も変化します。

ウォッチは、「スタック」ウィンドウでの選択によって制御される現在のコンテキストに従って式を評価します。新しいコンテキストに移動すると、式は新しいコンテキストに応じて再評価されます。ウォッチ式内の変数が定義されていない位置に実行ポイントが移動すると、ウォッチ式全体が未定義となります。ウォッチ式が評価可能な位置に実行ポイントが戻ると、「ウォッチ」ウィンドウに再度ウォッチ式の値が表示されます。

ウォッチを追加するには:

1. デバッグを開始し、デバッガがブレークポイントに達した時点で、「ログ」ウィンドウの「データ」タブをクリックします。

2. 「名前」列で、モニターする変数が表示されるまでノードを開きます。

3. 変数を右クリックして、「ウォッチ」を選択します。

「ウォッチ」ウィンドウが開き、選択された変数のウォッチを定義する新しい行が示されます。

58 テスト・コンソールの使用

この章では、本番環境でのテスト・コンソールのアンデプロイ方法を含め、Service Busテスト・コンソールを使用したサービスのテストについてのガイドラインと情報を示します。

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

- テスト・コンソールの概要

- テスト・コンソールへのアクセス

- プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合のテスト

- MFL変換のテスト

- XSLTトランスフォーメーションのテスト(リソース)

- XQueryトランスフォーメーションのテスト(リソース)

- インライン式のテスト

- OWSMセキュリティを含むサービスのテスト

- セキュリティとトランスポートについて

- テスト・コンソールのアンデプロイ

- サービスのテスト・コンソール・ページ参照

58.1 テスト・コンソールの概要

Service Busテスト・コンソールは、システムの設計の検証およびテストに使用するブラウザ・ベースのテスト環境です。これはService Busコンソールの拡張機能で、コンソール、Oracle JDeveloperおよびFusion Middleware Controlからアクセスできます。テスト・コンソールは、オペレーティング・システムおよびJDeveloperの構成に応じて、JDeveloperまたはWebブラウザにタブ付きウィンドウとして表示されます。

Service Busリソースをテストする場合は、テストのオブジェクトを構成し、テストを実行して、テスト・コンソール・ウィンドウで結果を表示します。場合によっては、コードをトレースし、特定のトレース・ポイントのメッセージの状態を調べることができます。設計時テストを行うことで、構成を本番環境にデプロイする前に設計上の問題を割り出すことができます。テスト・コンソールを使用してテストできるコンポーネントには、プロキシ・サービス、ビジネス・サービス、パイプライン、分割-結合、XQueryリソース、XSLTリソース、MFLリソースおよびXQuery/XPath式が含まれます。

テスト・コンソールでは、システムの特定部分を切り分けてテストしたり、システムを1つの単位としてテストしたりできます。テスト・コンソールはクラスタ環境で使用できます。しかし、本番環境にテスト・コンソールをデプロイすることはお薦めしません。テスト・コンソールを使用できるのはIntegrationAdminおよびIntegrationDeployerロールのユーザーのみです。ロールの詳細は、『Oracle Service Busの管理』のロールに関する項を参照してください。

大半のサービスはテスト・コンソールを使用してテストできますが、テストコンソールでは、Javaオブジェクトがメッセージ入力であることを前提とするサービスを呼び出すことはできません。たとえば、メッセージのリクエストまたはレスポンス・タイプがJavaのメッセージ・サービスはテストできません。また、Javaオブジェクトを前提としているJEJB操作もテストできません。

58.1.1 プロキシ・サービス・テスト

プロキシ・サービスをテストする場合、メッセージはトランスポート・レイヤーを介してプロキシ・サービスへ送信されます。トランスポート・レイヤーでは、テストの一環としてメッセージ・ヘッダーまたはメタデータの操作を実行します。テスト用に入力する構成データは、クライアントからプロキシ・サービスへ送信されるデータをシミュレートします。プロキシ・サービス・テストのレスポンスは、システム内の次のコンポーネントへ送信されるメッセージです。これは、前バージョンのService Busの間接コールに緩やかに関連付けられます。

このテスト・アプローチと、テスト・コンソールの「トランスポート」セクションにあるカスタム(アウトバウンド)トランスポート・ヘッダーの設定を使用して、サービス・コールを正確にシミュレートします。トランスポート設定の詳細は、「テスト・コンソールのトランスポート設定」を参照してください。

注意:

リクエスト/レスポンスMQまたはJMSのプロキシ・サービスのテストは動作しません。messageIDに基づく相関を使用したMQまたはJMSリクエスト/レスポンス・プロキシ・サービスへのコールからのレスポンスは、テスト・コンソールには表示されません。MQまたはJMSリクエスト/レスポンス・プロキシ・サービスをテストした場合、レスポンスはレスポンス・キューに保持されますが、テスト・コンソールには表示されません。

58.1.2 パイプライン・テスト

パイプラインをテストする場合、入力メッセージは直接パイプラインへ送信されます。デフォルトでトレースが有効になり、テスト・コンソールでメッセージ・フローの診断とトラブルシューティングが可能になります。テスト・コンソールに入力する入力データは、呼出し元のプロキシ・サービスのパイプラインが想定するデータである必要があります。つまり、テスト・コンソールは、パイプラインを呼び出すプロキシ・サービスのロールを担います。これは、前バージョンのService Busの直接コールに緩やかに関連付けられます。

パイプラインのテストでは、内部メッセージ・フロー・ロジックがテストされます。このテスト・アプローチと、テスト・コンソールの「トランスポート」パネルにあるカスタム(インバウンド)トランスポート・ヘッダーの設定を使用して、サービス呼出しを正確にシミュレートします。

58.1.2.1 テスト・コンソールを使用したパイプラインでのトレースの実行

パイプラインを介したメッセージのトレースでは、メッセージ・フローの様々なポイントで、メッセージ・コンテキストの確認と、アウトバウンドを行う通信が発生します。メッセージを検査するポイントはService Busで事前に定義され、ステージ、エラー・ハンドラおよびルート・ノードに対して定義されます。トレースのステージごとに、メッセージ・コンテキストに発生した変更と、そのステージの実行中に呼び出されたすべてのサービスが含まれます。

トレースには次のステージ情報が含まれます。

- 初期メッセージ・コンテキスト: プロキシ・サービスが呼び出されたときに、プロキシ・サービスが初期化した変数を表示します。変数の値を確認するには、変数名に対応する+記号をクリックします。

- 新しい変数: すべての新しい変数の名前と値。変数を展開すると、その値が表示されます。

- 削除された変数: 削除されたすべての変数の名前。

- 変更された変数: ステージを経由してメッセージを処理した結果として変更された$header、$body、$inboundを含め、値が変更されたすべての変数の名前。変数を展開すると、新しい値が表示されます。

- フォルト: エラーが発生した場合に、ステージ・エラー・ハンドラが検証エラーを処理した結果として、faultコンテキスト変数($fault)のコンテンツが表示されます。

- パブリッシュ: すべてのパブリッシュ・コールがリストされます。トレースには、パブリッシュ呼出しごとに、呼び出されたサービスの名前と、outbound、header、bodyおよびattachmentの各変数の値が含まれます。

- サービス・コールアウト: すべてのサービス・コールアウトがリストされます。トレースには、サービス・コールアウトごとに、呼び出されたサービスの名前、outbound変数の値、リクエスト・メッセージとレスポンス・メッセージのheader、bodyおよびattachmentの各変数の値が含まれます。

ルート・ノードについても、ステージと同様の情報が含まれます。ルート・ノードの場合、トレースには次のカテゴリの情報が含まれます。

- リクエスト・パスでのサービス呼出しのトレース

- ルーティングされたサービスのトレース

- レスポンス・パスでのサービス呼出しのトレース

- (リクエスト・パスの)ルート・ノードの開始ポイントと(レスポンス・パスの)終了ポイントの間でメッセージ・コンテキストに加えられた変更

注意:

ログ・ファイルまたは標準出力(サーバー・コンソール)にトレースを表示するには、WebLogic Serverのロギングを次の重大度に設定する必要があります。

- ログの最低の重大度: 情報

- ログ・ファイル: 情報

- 標準出力: 情報

ログの重大度の設定の詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』のログの重大度の使用に関する項を参照してください。

58.1.3 ビジネス・サービス・テスト

ビジネス・サービスの入力テスト・データは、ビジネス・サービスの呼出し元のパイプライン、分割-結合またはプロキシ・サービスから受信したときにビジネス・サービスが想定する形式になっている必要があります。たとえば、ルート・ノードやパイプラインのサービス・コールアウト・アクションからのデータなどが考えられます。テスト・コンソールを使用してビジネス・サービスをテストする場合、テスト・コンソールは呼出し側のサービスの役割を果たします。ビジネス・サービスをテストする場合、メッセージは必ずトランスポート・レイヤーを経由してルーティングされます。

ビジネス・サービスをテストする場合は、テスト中のビジネス・サービスがリモート・ドメインにある場合でも、テスト・コンソールで指定されたユーザー名およびパスワードが、ローカルService Busドメインに存在することを確認します。テスト・サービスは、プロキシ・サービスまたはビジネス・サービスを呼び出す前に、ローカル認証を実行します。

58.1.4 サービスの推奨テスト・アプローチ

図58-1に示すシナリオでは、クライアントがプロキシ・サービスPS1を呼び出し、それによってパイプラインP1が呼び出されています。パイプラインは、パイプラインP2、ビジネス・サービスB1、ローカル・プロキシ・サービスPS2の順に呼び出してから、メッセージをクライアントに返します。インタフェースを番号で示しています。

図58-1 テスト・シナリオの例

このシナリオには、有効なテスト方法がいくつもあります。次が推奨されます。

- 最初に初期プロキシ・サービス以外のインタフェースのテストを完了します。つまり、図58-1に示すサンプル・シナリオでは、まずインタフェース1から6のテストを完了してから、インタフェース7をテストします。
通常は、メッセージがシステムを流れる逆の順序でテストします。この方法により、ダウンストリーム・インタフェースが正しく機能することを確認しながら、パイプラインのメッセージ・フロー・ロジックを反復的に変更およびテストできます。

- ビジネス・サービス(B1)インタフェース(1)へのパイプライン(P1)をテストします。

- パイプライン自身をテストする前に、パイプラインですべてのXQuery式を検証し、テストします。図58-1では、インタフェース2および5がXQuery式のテストを示しています。

- パイプライン(P2)インタフェース(3)へのパイプライン(P1)をテストします。

- ローカル・プロキシ・サービス(PS2)インタフェース(4)へのパイプライン(P1)をテストします。

- パイプライン(P1)インタフェース(6)への初期プロキシ・サービス(PS1)をテストします。

- 最後のシステム・テストで、プロキシ・サービスPS1を呼び出すクライアントをシミュレートします。図58-1では、このテストはインタフェース7によって表されています。

- システムの今後のトラブルシューティングを容易にするために、インタフェースのテストが成功した後のメッセージの状態を保存します。インタフェース6のテストは、実際にはシステム全体のテストです。システムの他のすべてのインタフェースが正しく機能していることを確認することで、システム・エラー発生時のトラブルシューティングの範囲を絞り込むことができます。

58.1.5 HTTPリクエスト

プロキシ・サービスをテストするときに、テスト・コンソールではネットワーク経由でHTTPリクエストを送信しないため、トランスポート・レベルのアクセス制御は適用されません。トランスポート・レベルのアクセス制御は、Webアプリケーション・レイヤーを介して実現されます。トランスポート・レイヤーのメッセージ処理の詳細は、「メッセージ処理」を参照してください。トランスポート設定の詳細は、「ランタイムがテスト・コンソールでトランスポート設定を使用する方法」を参照してください。

58.2 テスト・コンソールへのアクセス

特定のService Busサービスをテストするためにテスト・コンソールにアクセスする方法は複数あり、Oracle Service Busコンソール、JDeveloperまたはFusion Middleware Controlからアクセスできます。

プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合は、セッションの外部でのみテストできます。トランスフォーメーションはセッションの外部でも内部でもテストできます。

注意:

テスト・コンソール・サービスが実行されていないことを示すエラーを受信した場合は、管理サーバーがlocalhostなどの特定の有効なアドレスをリスニングするように設定してみます。Oracle WebLogic Server管理コンソールの「環境」→「サーバー」→「admin_server_name」→「構成」→ >「全般」を選択し、「リスニング・アドレス」を設定します。また、クラスタではすべての管理対象ノードが実行されていることを確認します。

58.2.1 前提条件

テスト・コンソールを使用するには、事前に次の準備が整っている必要があります。

- Service Busが稼動している必要があり、サービスをテストする場合はテストするリソースを含むセッションがアクティブ化されている必要があります。サービスはセッションの外部でのみテストできますが、トランスフォーメーションはセッションの外部でも内部でもテストできます。

- XQueryテストを実行するには、ブラウザのポップアップ・ブロッカを無効にする必要があります。Internet Explorerブラウザでツールバーを使用している場合、「インターネット オプション」メニューでポップアップ・ブロッカを無効にするだけでなく、ポップアップをブロックするように構成されているすべてのツール・バーについてもこの機能を無効にする必要があります。XQueryテストは、設計時環境(アクティブ・セッション)でのみ実行されます。

- テスト・コンソールを使用してSAMLトークンを生成し、プロキシ・サービスに送信する場合は、SAMLトークンを要求し、リライイング・パーティにするように、プロキシ・サービスを構成する必要があります。SAMLリライイング・パーティの作成方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAMLリライイング・パーティの作成に関する項を参照してください。

注意:

SAMLリライイング・パーティ作成時には、次に留意してください。

- プロキシ・サービスではWSS/Sender-VouchesプロファイルおよびWSS/Holder-of-Key SAMLプロファイルのみ使用できます。

- リライイング・パーティを構成する場合、対象URLの値としてプロキシ・サービスのURIを指定します。プロキシ・サービスのURIを表示するには、Oracle Service Busコンソールで「プロキシ・サーバーを開く」をクリックして、「トランスポート」サブタブをクリックします。

58.2.2 Oracle Service Busコンソールからテスト・コンソールへのアクセス方法

Oracle Service Busコンソールで、コンポーネントの定義エディタまたはプロジェクト/フォルダ定義エディタからサービスまたはトランスフォーメーションのテスト・コンソールにアクセスできます。

58.2.2.1 コンポーネントの定義エディタからのテスト・コンソールへのアクセス

コンポーネントの定義エディタからテスト・コンソールにアクセスするには:

1. Oracle Service Busコンソール・プロジェクト・ナビゲータで、テストするサービスまたはトランスフォーメーションを含むプロジェクトとフォルダを開きます。

2. リソースをクリックして、定義エディタで開きます。

3. 定義エディタの右上のセクションにある「テスト・コンソールの起動」(緑色の矢印アイコン)をクリックします。

新しいブラウザ・ウィンドウにテスト・コンソールが表示され、そこで選択したコンポーネントをテストできます。

58.2.2.2 プロジェクト/フォルダ定義エディタからのテスト・コンソールへのアクセス

プロジェクト/フォルダ定義エディタからテスト・コンソールにアクセスするには:

1. Oracle Service Busコンソール・プロジェクト・ナビゲータで、テストするコンポーネントを含むプロジェクトまたはフォルダの名前をクリックします。

そのフォルダまたはプロジェクトの定義エディタが表示されます。

2. リソース表でテストするコンポーネントを検索します。

3. 「アクション」列で、「テスト・コンソールの起動」(緑色の矢印アイコン)をクリックします。

新しいブラウザ・ウィンドウにテスト・コンソールが表示され、そこで選択したコンポーネントをテストできます。

58.2.3 Fusion Middleware Controlからテスト・コンソールへのアクセス方法

Fusion Middleware Controlで、サービスの「ダッシュボード」ページからサービスのテスト・コンソールにアクセスできます。Fusion Middleware Controlからはサービスのみテストでき、トランスフォーメーションはテストできません。

Fusion Middleware Controlからテスト・コンソールにアクセスするには:

1. Fusion Middleware Controlの対象のナビゲータで、SOA、service-busの順に開き、テストするコンポーネントを含むプロジェクトをクリックします。

そのプロジェクトの「サービス・ヘルス」ページが表示されます。

2. プロジェクトに関連付けられたサービスが「サービス」表に表示されない場合は、テストするサービスの検索を実行します。

注意:

このページには、モニタリングが有効なサービスのみが表示されます。

3. 「サービス」表で、テストするサービスの名前をクリックします。

サービスの「ダッシュボード」が表示されます。

4. サービス名の右の「テスト・コンソールの起動」(緑色の矢印アイコン)をクリックします。

新しいブラウザ・ウィンドウにテスト・コンソールが表示され、そこで選択したコンポーネントをテストできます。

58.2.4 JDeveloperからテスト・コンソールへのアクセス方法

JDeveloperで、サービスの定義エディタまたはコンテキスト・メニューからサービスまたはトランスフォーメーションのテスト・コンソールにアクセスできます。トランスフォーメーションは、テスト・コンソールおよびJDeveloper XSLTテスターを含む複数のテスト・オプションを備えています。

58.2.4.1 JDeveloperからテスト・コンソールへのアクセス

JDeveloperからサービスのテスト・コンソールにアクセスするには:

1. JDeveloperで、テストするサービスを含むService Busプロジェクトを開きます。

2. 次のいずれかを行います。

- サービスをダブルクリックしてエディタを表示し、その後、JDeveloperツールバーで「実行」アイコンをクリックします。

- サービスを右クリックし、「実行」を選択します。

新しいタブ付きウィンドウにテスト・コンソールが表示され、そこで、選択したサービスをテストできます。

58.2.4.2 JDeveloperからのトランスフォーメーションのテスト・コンソールへのアクセス

JDeveloperからトランスフォーメーションのテスト・コンソールにアクセスするには:

1. JDeveloperで、テストするトランスフォーメーションを含むService Busプロジェクトを開きます。

2. 次のいずれかを行います。

- トランスフォーメーションをクリックしてエディタを表示し、その後、JDeveloperツールバーで「実行」アイコンをクリックします。

- トランスフォーメーションを右クリックし、「実行」を選択します。

注意:

「デバッグ」をクリックしてもテスト・コンソールは起動しますが、通常はセクション内のメッセージ・フローをステップ実行できるように、ブレークポイントと組み合わせて使用します。

3. ダイアログが表示された場合は、ターゲットの起動方法の選択肢として「Service Busテスト・コンソール内」を選択します。

新しいタブ付きウィンドウにテスト・コンソールが表示され、そこで、選択したサービスをテストできます。

58.3 プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合のテスト

Service Busサービスをテストする場合、アクティブ・セッションでは実行できません。テスト・コンソールでは、入力、トランスポート・ヘッダー、添付ファイルおよび特定のセキュリティ構成をテストできます。サービスのテスト方法の詳細は、「テスト・コンソールの概要」を参照してください。

注意:

- クラスタリングされたドメインでは、テスト・コンソールを利用して、ビジネス・サービスにルーティングされる構成済のビジネス・サービスまたはプロキシ・サービスをテストすることはできません。

- HTTPカスタム・トークン認証を使用するプロキシをテスト・コンソールで呼び出した場合、認証チェックは行われません。

58.3.1 Service Busサービスのテスト方法

サービスのテスト・コンソールを起動した場合は、テストする操作、メッセージ・ペイロード、トランスポート・ヘッダー、セキュリティ情報を含むテスト入力を構成できます。パイプラインの場合は、様々なコンポーネントを介してメッセージ処理をトレースできます。次の図は、テスト・コンソール・ページの例を示しています。

図58-2 テスト・コンソールの「パイプライン・テスト」ページ

Service Busサービスをテストするには:

1. Oracle Service Busコンソール内のセッションがアクティブ化されていることを確認します(該当する場合)。

2. 「テスト・コンソールへのアクセス」で説明されているとおり、テストするプロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合を検索し、テスト・コンソールを起動します。

3. SOAPおよびXMLサービスの場合は、テストするWSDL操作を選択します。

4. 「リクエスト・ドキュメント」セクションで、使用するテスト・データを入力します。これはサービスが受信することを想定しているデータである必要があります。

このセクションの入力方法の詳細は、「リクエスト・ドキュメント・テスト・コンソール・プロパティ」を参照してください。

注意:

保護されたSOAPメッセージは、空白が追加されて表示されます。ホワイト・スペースはドキュメントのセマンティクスに影響する可能性があるため、このようなSOAPメッセージはリテラル・データとして必ずしも使用できるわけではありません。たとえば、デジタル署名はホワイト・スペースの影響を受け、無効になることがあります。

5. テスト・コンソールのその他のセクションを構成します。設定可能なプロパティの詳細は、「サービスのテスト・コンソール・ページ参照」を参照してください。

6. 「実行」をクリックします。

リクエスト・メッセージおよびサービスのレスポンス・メッセージとメタデータがテスト・コンソールに表示されます。テスト結果の解釈方法の詳細は、「サービスのテスト結果の表示方法」を参照してください。

7. もう一度テストを実行するには、「戻る」をクリックします。ステップ3から6を繰り返します。

58.3.2 サービス内の添付ファイルのテスト方法

プロキシ・サービス、ビジネス・サービスおよびパイプラインとともに、メッセージ添付ファイルをテストできます。

添付ファイルとともにサービスをテストするには:

1. Oracle Service Busコンソール内のセッションがアクティブ化されていることを確認します(該当する場合)。

2. 「テスト・コンソールへのアクセス」で説明されているとおり、テストするプロキシ・サービス、ビジネス・サービスまたはパイプラインを検索し、テスト・コンソールを起動します。

3. SOAPおよびXMLサービスの場合は、テストするWSDL操作を選択します。

4. パイプラインの場合は、トレースを有効にするかどうかを指定します。詳細は、「パイプライン処理のトレース方法」を参照してください。

5. 「リクエスト・ドキュメント」セクションで、テスト・メッセージのペイロードを入力します。

例として、次の入力はsubmitAttachment操作を使用して、SOAPメッセージ内の添付ファイルとしてZIPファイルを送信します。

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<m:submitAttachment xmlns:m="http://www.alsb.com/SOAPwithAttachment/">
<submitAttachment>
<fileName>c:\yourfile.zip</fileName>
</submitAttachment>
<zipFile href="cid:zipFile"/>
</m:submitAttachment>
</env:Body>
</env:Envelope>

このセクションの入力方法の詳細は、「リクエスト・ドキュメント・テスト・コンソール・プロパティ」を参照してください。

6. 「添付ファイル・テスト・コンソールのプロパティ」で説明されているとおり、テスト・コンソールの「添付ファイル」セクションで、添付ファイル・ヘッダーの値を入力します。添付ファイルとして使用するファイルを選択する必要があります。

7. テスト・コンソールのその他のセクションを構成します。設定可能なプロパティの詳細は、「サービスのテスト・コンソール・ページ参照」を参照してください。

8. 「実行」をクリックします。

添付ファイルが正常に送信されたことを確認するため、ここの例では、submitAttachment操作によってログに記録された次のようなメッセージが、サーバー・コンソールに表示されていることをチェックします。

WS called - received the following properties:
submitAttachment is:
com.alsb.soapwithattachment.SubmitAttachmentRequestType@e2abb0
zipFile is: javax.activation.DataHandler@175cf0a

58.3.3 パイプライン処理のトレース方法

パイプラインのトレースを有効にすると、テスト結果にはトレースの詳細が含まれます。トレースは、システムにある問題を追跡し、修正するために問題を切り分けるために使用します。トレース情報は、コード内で要求パスと応答パスを通過した経路を示します。次の図は、パイプライン・トレースの結果を示しています。

トレースの表示中、Service BusコンソールまたはOracle JDeveloperにメッセージ・フローを表示することもできます。これにより、トレースをメッセージ・フローのステージやアクションに対応付けるのが容易になります。メッセージ・フローを変更してから再度トレースを実行し、出力を表示できます。

図58-3 パイプライン呼出しのトレース

パイプラインを通じてメッセージをトレースするには:

1. Oracle Service Busコンソール内のセッションがアクティブ化されていることを確認します(該当する場合)。

2. 「テスト・コンソールへのアクセス」で説明されているとおり、テストするパイプラインを検索し、テスト・コンソールを起動します。

3. SOAPおよびXMLサービスの場合は、「サービス操作」セクションの使用可能なオプションから、テストするWSDL操作を選択します。

4. 「テスト構成」セクションで、「トレースを含む」が選択されていることを確認します。

5. 「リクエスト・ドキュメント」セクションで、使用するテスト・データを入力します。これはパイプラインが受信することを想定しているデータである必要があります。

このセクションの入力方法の詳細は、「リクエスト・ドキュメント・テスト・コンソール・プロパティ」を参照してください。

6. テスト・コンソールのその他のセクションを構成します。設定可能なプロパティの詳細は、「サービスのテスト・コンソール・ページ参照」を参照してください。

7. 「実行」をクリックします。

リクエスト・メッセージおよびサービスのレスポンス・メッセージとメタデータがテスト・コンソールに表示されます。テスト結果の解釈方法の詳細は、「サービスのテスト結果の表示方法」を参照してください。

8. 下の「呼出しのトレース」セクションまでスクロールします。

このセクションには、メッセージ・フローの表現が表示されます。サービスを通過したメッセージをトレースし、あらかじめ選択されたポイントでのメッセージの状態を表示できます。トレース・ポイントは自動的に設定されます。

9. 「+」記号をクリックしてメッセージ・フローを展開し、詳細を表示します。

58.3.4 サービスのテスト結果の表示方法

プロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合をテストする場合、テスト・コンソールのいくつかのセクションに結果が表示されます。表58-1は、テスト結果のセクションを示しています。

表58-1 プロキシ・サービスのテスト結果

セクション

説明

リクエスト・ドキュメント

テスト・コンソールによってサービスに送信されたリクエスト・メッセージです。

リクエスト・メッセージがテスト・コンソールによって変更されなかった場合は、このセクションは最初は折りたたまれています。「フォーム」タブでSOAPサービスを構成した場合、またはWS-Securityが適用されている場合は、このセクションは最初は開かれます。

WS-Securityが適用されている場合、このセクションには2つのSOAPメッセージが表示されます。1番目のメッセージはクリア・テキスト・メッセージで、2番目は保護されたSOAPメッセージです。

レスポンス・ドキュメント

サービスによって生成されたメッセージ・レスポンスです。このセクションには、エラーが発生したかどうかも示されます。

WS-Securityレスポンスが適用されたSOAPサービスの場合、このセクションには2つのSOAPメッセージが表示されます。1つ目のSOAPメッセージは、クライアントが受け取る保護されたメッセージ。2つ目のSOAPメッセージは、対応するクリア・テキストのメッセージ。

レスポンス・メタデータ

メッセージのレスポンスと共に返されたメタデータ。

呼出しのトレース

トレースはパイプラインの場合のみ使用可能で、このセクションにはシステムを経由した際のメッセージの状態が表示されます。これは、テストを実行する前に「トレースを含む」を選択した場合にのみ実行されます。

58.4 MFLトランスフォーメーションのテスト

MFL(メッセージ・フォーマット言語)ドキュメントは、バイナリ・データのレイアウトの記述に使用する特殊なXMLドキュメントです。MFLリソースは、次のトランスフォーメーションをサポートしています。

- XMLからバイナリ: 必須入力(XML)が1つと出力(バイナリ)が1つあります。

- バイナリからXML: 必須入力(バイナリ)が1つと出力(XML)が1つあります。

各トランスフォーメーションでは、入力を1つだけ受け入れ、出力を1つ返します。MFLトランスフォーメーションは、JDeveloperまたはOracle Service Busコンソールのいずれかからアクセスしたテスト・コンソールを使用して、またはJDeveloperのフォーマット・ビルダー内のテスターを使用してテストできます。

58.4.1 テスト・コンソールでのMFLトランスフォーメーションのテスト方法

セッションをアクティブ化した後、またはセッション中に、トランスフォーメーションをテストして、リソースが想定したとおりに動作するかどうかを確認できます。セッションをアクティブ化しない場合、テストはローカルでの変更内容を使用して設計時に実行されます。

JDeveloperで、フォーマット・ビルダーの組込みテスト・ツールを使用することもできます。フォーマット・ビルダーからテストを実行する方法の詳細は、「フォーマット定義のテスト」を参照してください。

テスト・コンソールでMFLトランスフォーメーションをテストするには:

1. 実行時にテストするには、現在のセッションをアクティブ化します。設計時にテストするには、セッションをアクティブ化しません。

2. 「テスト・コンソールへのアクセス」で説明されているとおり、テストするMFLリソースを検索し、テスト・コンソールを起動します。

3. MFLリソースのテスト・データを構成します。詳細については、表58-2を参照してください。

4. 「実行」をクリックします。

テスト・コンソールに結果が表示されます。

5. もう一度テストする場合は、「戻る」をクリックします。テスト・コンソールを閉じたら、リソースを変更し、再度テストできます。

表58-2 MFLテスト・コンソールのプロパティ

セクション

説明

サポートされるトランスフォーメーション

テストする特定のトランスフォーメーションを選択するには、トランスフォーメーション名を選択します。

入力ドキュメント

- XML入力: XMLからバイナリへのトランスフォーメーションでは必須です。
MFLドキュメントのXMLスキーマは推測できます。サンプルXMLドキュメントはテキスト・フィールドに自動的に入力されます。XML入力はファイル・ベースまたはテキスト・ベースで入力できます。テキスト入力よりファイルの参照による入力が優先されます。テストに使用するファイルを参照して選択します。

- バイナリ入力: バイナリからXMLへのトランスフォーメーションでは必須です。
バイナリ入力はファイル・ベースまたはテキスト・ベースで入力できます。テキスト入力よりファイルの参照による入力が優先されます。テストに使用するファイルを参照して選択します。

58.4.2 MFLテスト・コンソールの例

次の例は、MFLトランスフォーメーションのテストと、MFLファイルのコンテンツ、テスト入力およびテスト結果を示しています。テスト・コンソールによってMFLファイルからサンプルXMLドキュメントが生成されます。XML入力を使用してテストを実行します。テストが成功すると、入力XMLドキュメントのメッセージ・コンテンツがバイナリ形式に変換されます。

例 - MFLファイルのコンテンツ

以下は、MFLファイルの例です。

<?xml version='1.0' encoding='windows-1252'?>
<!DOCTYPE MessageFormat SYSTEM 'mfl.dtd'>
<MessageFormat name='StockPrices' version='2.01'>
<StructFormat name='PriceQuote' repeat='*'>
<FieldFormat name='StockSymbol' type='String' delim=':' codepage='windows-1252'/>
<FieldFormat name='StockPrice' type='String' delim='|'codepage='windows-1252'/>
</StructFormat>
</MessageFormat>

例 - テスト・コンソールでのXML入力

前述の例のMFLファイルをテストするためにテスト・コンソールで生成されるXMLドキュメントを次に示します。

<StockPrices>
<PriceQuote>
<StockSymbol>StockSymbol_31</StockSymbol>
<StockPrice>StockPrice_17</StockPrice>
</PriceQuote>
</StockPrices>

例 - MFLのテスト・コンソールでの結果

テスト・コンソールで「実行」をクリックしてこのテストを実行すると、コンソールには次のデータが表示されます(バイナリ形式での株価記号と株価)。

00000000:53 74 6F 63 6B 53 79 6D 62 6F 6C 5F 33 31 3A 53 StockSymbol_31:S
00000010:74 6F 63 6B 50 72 69 63 65 5F 31 37 7C .. .. .. StockPrice_17|...

58.5 XSLTトランスフォーメーションのテスト(リソース)

Service Busでは、Extensible Stylesheet Language Transformation (XSLT)を使用してXML間のマッピングを記述します。メッセージ・フローのXQuery式でXSLTトランスフォーメーションを使用できます。

XSLTリソースをテストするには、入力XMLドキュメントを指定する必要があります。テスト・コンソールは、出力XMLドキュメントを返します。XSLTトランスフォーメーションには、トランスフォーメーションに役立つ複数のパラメータを含めることができます。テスト・コンソールに、トランスフォーメーションに必要なパラメータがすべて表示されます。デフォルト値が表示されますが、値はオーバーライドできます。XSLTパラメータは、値としてプリミティブ型またはXMLドキュメントをとります。XSLトランスフォーメーションからパラメータの型を識別することはできません。

XSLTトランスフォーメーション用のテスト・コンソールには、Oracle Service BusコンソールまたはJDeveloperからアクセスできます。JDeveloperでは、XSLTマッパーの組込みテスターも使用できます。

58.5.1 テスト・コンソールを使用したXSLTトランスフォーメーションのテスト方法

セッションをアクティブ化した後、またはセッション中に、XSLTトランスフォーメーションをテストして、リソースが想定したとおりに動作するかどうかを確認できます。実行時テストを行うには、セッションをアクティブ化する必要があります。それ以外の場合は、ローカルでの変更内容を使用した設計時テストが行われます。

テスト・コンソールを使用してXSLTトランスフォーメーションをテストするには:

1. 実行時にテストするには、現在のセッションをアクティブ化します。設計時にテストするには、セッションをアクティブ化しません。

2. 「テスト・コンソールへのアクセス」で説明されているとおり、テストするXSLTリソースを検索し、テスト・コンソールを起動します。

3. 次の情報を入力してリソースのテスト・データを構成します。

- XML入力: XML入力はファイル・ベースまたはテキスト・ベースで入力できます。入力するためのファイルを選択した場合、それがテキスト入力より優先されます。テストに使用するファイルを参照して選択します。XML入力は必須です。

- param_name: 名前付きXSLTパラメータ。XML型とプリミティブ型(string型、integer型、float型など)の2つの入力型があります。デフォルトの入力型はstring型です。XMLタイプのパラメータを識別するには、パラメータ名に関連付けられた「XMLとして」チェック・ボックスを選択します。このオプションの詳細は、「XQueryトランスフォーメーションのテスト(リソース)」を参照してください。

4. 「実行」をクリックします。

テスト・コンソールに結果が表示されます。

5. もう一度テストする場合は、「戻る」をクリックします。テスト・コンソールを閉じたら、リソースを変更し、再度テストできます。

58.5.2 JDeveloper XSLTマッパーでXSLTトランスフォーメーションをテストする方法

JDeveloperからXSLTトランスフォーメーションのテスト・コンソールにアクセスできますが、JDeveloperはXSLTマッパーから直接アクセスできるXSLTトランスフォーメーション専用のテスターを提供しています。カスタムXPath関数はマッパーでテストできません。

JDeveloperでXSLTトランスフォーメーション・テストを実行する方法の詳細と手順は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のマップのテストに関する項を参照してください。

58.6 XQueryトランスフォーメーションのテスト(リソース)

XQueryは、データがXMLに物理的に格納されるか、XMLとして表示されるかに関係なく、XMLの構造を使用して、様々な種類のデータに対する問合せを表現します。XQueryトランスフォーメーションは複数の入力をとる場合があります。返される出力は1つです。XQueryトランスフォーメーションに想定される入力は、定義済の各XQuery外部変数にバインドする変数値です。XQuery入力変数の値には、プリミティブ型の値(string型、integer型、date型)、XMLドキュメント、またはこれらの型のシーケンスを指定できます。出力値は、プリミティブ型の値(string型、integer型、date型)、XMLドキュメント、またはこれらの型のシーケンスになります。

XQueryは型付きの言語で、外部変数ごとに型が決まっています。型は次のグループに分類できます。

- 単純型/プリミティブ型(string、int、floatなど)

- XMLノード

- 型なし

テスト・コンソールでは、これらの3つの変数がすべてテスト・コンソールの「変数」セクションにリストされ、入力はテストの実行時に構成されます。型なし変数には、デフォルトでXMLが選択されます。これが最も一般的なケースであるためです。

58.6.1 XQueryトランスフォーメーションのテストの前提条件とガイドライン

XQueryテストが機能するように、ブラウザのポップアップ・ブロッカを無効にする必要があります。Internet Explorerブラウザでツールバーを使用している場合、「インターネット オプション」メニューでポップアップ・ブロッカを無効にするだけでなく、ポップアップをブロックするように構成されているすべてのツール・バーについてもこの機能を無効にする必要があります。

テスト・コンソールでXQueryテストを実行する場合、新しいテストを実行するには「戻る」ボタンを使用します。ただし、XQueryを変更した後に新しいテストを実行する場合、変更を有効にするには、テスト・コンソールを閉じて再度開く必要があります。

58.6.2 テスト・コンソールでのXQueryトランスフォーメーションのテスト方法

XQueryマップでは、XMLからXML、XMLから非XML、および非XMLからXMLへの各マッピングを記述できます。テスト・コンソールは入力のシーケンスに対応していません。セッションをアクティブ化した後、またはセッション中に、トランスフォーメーションをテストして、リソースが想定したとおりに動作するかどうかを確認できます。実行時テストを行うには、セッションをアクティブ化する必要があります。それ以外の場合は、ローカルでの変更内容を使用した設計時テストが行われます。

テスト・コンソールを使用してXQueryトランスフォーメーションをテストするには:

1. 実行時にテストするには、現在のセッションをアクティブ化します。設計時にテストするには、セッションをアクティブ化しません。

2. 「テスト・コンソールへのアクセス」で説明されているとおり、テストするXQueryリソースを検索し、テスト・コンソールを起動します。

3. XQuery入力を入力してリソースのテスト・データを構成します。次で説明するとおり、入力は外部変数に基づきます。

- XQuery外部変数ごとに1つずつ名前付きの入力フィールドがあります。

- 単純型である場合は、1行の編集ボックスが表示されます。データがXMLである場合は、複数行の編集ボックスが表示されます。

- 変数に型がない場合は、両方の組合せの入力フィールドが使用されます。変数の型を宣言する必要があります。XML型のパラメータを指定するには、「XMLとして」チェック・ボックスを選択します。

- XML入力はファイル・ベースまたはテキスト・ベースで入力できます。テキスト入力よりファイルの参照による入力が優先されます。テストに使用するファイルを参照して選択します。

- テスト・コンソールの入力は、入力する必要のあるデータの型がわかりやすいように、型に基づいて表示されます。型なしの場合のデフォルトはXML型。

4. 「実行」をクリックします。

テスト・コンソールに結果が表示されます。

5. もう一度テストする場合は、「戻る」をクリックします。テスト・コンソールを閉じたら、リソースを変更し、再度テストできます。

58.7 インライン式のテスト

Oracle Service Busコンソールで式または条件を作成または変更する際、メッセージ・フロー・アクションの式をXQuery/XSLT式エディタ、XQuery条件エディタおよびXPath式エディタからテストできます。JDeveloperの式ビルダーからテスト・コンソールにアクセスすることもできます。テストは、XQuery/XSLT式エディタおよびXQuery条件エディタの両方で同じ形式をとりますが、XPath式エディタではわずかに異なります。

58.7.1 XQuery式をテストする方法

XQuery/XSLT式エディタおよびXQuery条件エディタからXQuery式を直接テストできます。

XQuery式をテストするには:

1. パイプライン・アクションで式を作成または更新します。

2. 次のいずれかを行います。

- JDeveloperで、「テスト式」アイコンをクリックします。

- Oracle Service Busコンソールで、「検証」をクリックして式が有効であることを確認し、「テスト」をクリックします。

テスト・コンソールが現れ、テストする式が表示されます。

3. 「データ入力」セクションで、XQuery入力を入力してリソースのテスト・データを構成します。次で説明するとおり、入力は外部変数に基づきます。

- XQuery外部変数ごとに1つずつ名前付きの入力フィールドがあります。

- 単純型である場合は、1行の編集ボックスが表示されます。データがXMLである場合は、複数行の編集ボックスが表示されます。

- 変数に型がない場合は、両方の組合せの入力フィールドが使用されます。変数の型を宣言する必要があります。XML型のパラメータを指定するには、「XMLとして」チェック・ボックスを選択します。

- XML入力はファイル・ベースまたはテキスト・ベースで入力できます。テキスト入力よりファイルの参照による入力が優先されます。テストに使用するファイルを参照して選択します。

- テスト・コンソールの入力は、入力する必要のあるデータの型がわかりやすいように、型に基づいて表示されます。型なしの場合のデフォルトはXML型。

4. 「実行」をクリックします。

テスト・コンソールに結果が表示されます。

5. もう一度テストする場合は、「戻る」をクリックします。テスト・コンソールを閉じたら、リソースを変更し、再度テストできます。

XQueryを変更してからもう一度テストを実行する場合、変更を有効にするには、テスト・コンソールを閉じて開きなおす必要があります。

58.7.2 XPath式をテストする方法

XPath式は、XMLメッセージ・コンテキスト変数のサブセットを選択するために使用します。XPath式エディタ内でテスト・コンソールを使用して、XPath式の定義をテストすることができます。XPath式は、入力として1つのXMLドキュメントをとり、出力としてXMLドキュメントのシーケンスやプリミティブ型、またはその両方を生成します。

XPath式をテストするには:

1. メッセージ・フロー・アクションでXPath式を作成または更新します。

2. 式の定義が終わったら、「検証」をクリックして式が有効であることを確認します。

3. 「テスト」をクリックします。

テスト・コンソールが現れ、テストする式が表示されます。

4. 「データ入力」セクションで、XML入力を入力してリソースのテスト・データを構成します。

- このセクションには、このXPath式のテスト対象のXMLドキュメントに対応する1つの入力フィールドが表示されます。

- XML入力はファイル・ベースまたはテキスト・ベースで入力できます。テキスト入力よりファイルの参照による入力が優先されます。テストに使用するファイルを参照して選択します。

5. 「実行」をクリックします。

テスト・コンソールに結果が表示されます。

6. もう一度テストする場合は、「戻る」をクリックします。テスト・コンソールを閉じたら、リソースを変更し、再度テストできます。

XPath式を変更してからもう一度テストを実行する場合、変更を有効にするには、テスト・コンソールを閉じて開きなおす必要があります。

58.8 OWSMセキュリティを含むサービスのテスト

テスト・コンソールは、OWSMセキュリティ・ポリシーで保護されたプロキシ・サービスとビジネス・サービスのテストをサポートします。サービスにOWSMポリシーがアタッチされている場合、テスト・コンソールとサービスとの間のメッセージのやり取りはポリシーによって保護されます。テスト・サービスは、ポリシーに従って、デジタル署名を施すか、メッセージ(正確にはメッセージの一部)を暗号化し、該当するセキュリティ・トークンを含めます。「リクエスト・ドキュメント・テスト・コンソール・プロパティ」に説明されているとおり、指定されたクリアテキストSOAPエンベロープでのデジタル署名操作および暗号化操作に対する入力を指定します。

テスト・コンソールでサービス・キー・プロバイダを指定すると、WS-Securityで要求されるクライアント側のすべてのPKIキー・ペア資格証明がサービス・キー・プロバイダから取得されます。操作のリクエスト・ポリシーでIDアサーションが指定されており、サポートされるトークン・タイプの1つがユーザー名トークンである場合は、「ユーザー名」フィールドと「パスワード」フィールドを使用します。

表58-3と表58-4にセキュリティ・シナリオを示します。

表58-3 デジタル署名と暗号化のシナリオ

シナリオ

サービス・キー・プロバイダの必要性

リクエスト・ポリシーにConfidentialityアサーションがあります。

いいえ。テスト・サービスは、サービスの公開鍵でリクエストを暗号化します。プロキシ・サービスをテストする場合、テスト・サービスは、プロキシ・サービスのサービス・キー・プロバイダに割り当てられた暗号化証明書から公開鍵を自動的に取得します。

ビジネス・サービスをテストする場合、暗号化証明書はビジネス・サービスのWSDLファイルに埋め込まれます。テスト・サービスは、WSDLリポジトリからこのWSDLファイルを自動的に取得し、WSDLファイルから暗号化証明書を取り出します。

レスポンス・ポリシーにConfidentialityアサーションがあります。

はい。このシナリオでは、操作ポリシーは、クライアントが証明書をサービスへ送信することを要求します。サービスは、この証明書の公開鍵を使用し、クライアントへのレスポンスを暗号化します。サービス・キー・プロバイダを指定する必要があり、このサービス・キー・プロバイダには、暗号化資格証明が関連付けられている必要があります。

リクエストとレスポンスの両方の暗号化がサポートされている場合、異なる資格証明を使用する必要があります。

リクエスト・ポリシーにIntegrityアサーションがあります。

はい。クライアントはリクエストに署名する必要があります。サービス・キー・プロバイダを指定する必要があり、このサービス・キー・プロバイダには、デジタル署名資格証明が関連付けられている必要があります。

さらに、このIntegrityアサーションがSAML holder-of-keyの場合は、サービス・キー・プロバイダに加え、ユーザー名とパスワードも必要です。

レスポンス・ポリシーにIntegrityアサーションがあります。

いいえ。この場合、ポリシーは、サービスがレスポンスに署名する必要があることを指定します。サービスは、秘密鍵でレスポンスに署名します。テスト・コンソールはこの署名を確認するのみです。

プロキシ・サービスをテストする場合、プロキシ・サービスのサービス・キー・プロバイダのデジタル署名資格証明に関連付けられた秘密鍵が使用されます。

ビジネス・サービスをテストする場合、サービスは、サービスをホストするシステムに製品固有の方法で構成されたキー・ペアを使用して署名します。

現在のセキュリティ・レルムが証明書検索および検証を実行するように構成されている場合、サービス・キー・プロバイダに割り当てられる証明書は、証明書検索および検証フレームワークに登録され、有効である必要があります。

証明書ルックアップと検証の詳細は、『Oracle WebLogic Serverセキュリティの管理』の証明書ルックアップおよび検証フレームワークの構成に関する項を参照してください。

表58-4 IDポリシーのシナリオ(ポリシーにIDアサーションが含まれている場合)

サポートされるトークン・タイプ(リクエスト・ポリシー内のIDアサーションから)

説明

コメント

UNT

サービスがWSSユーザー名トークンのみを使用

「セキュリティ」パネルでユーザー名とパスワードを指定する必要があります。

X.509

サービスがWSS X.509トークンのみを使用

「セキュリティ」パネルでサービス・キー・プロバイダを指定する必要があります。このサービス・キー・プロバイダには、WSS X.509資格証明が関連付けられている必要があります。

SAML

サービスがWSS SAMLトークンのみを使用

「セキュリティ」パネルまたは「トランスポート」パネルで、ユーザー名とパスワードを指定する必要があります。両方のパネルで指定した場合は、「セキュリティ」パネルのユーザー名とパスワードがSAMLトークンのIDとして使用されます。

UNT、X.509

サービスがUNTまたはX.509トークンを使用

「セキュリティ」パネルで、ユーザー名とパスワードを指定します。または、WSS X.509資格証明が関連付けられているサービス・キー・プロバイダを「セキュリティ」パネルで指定する必要があります。両方指定した場合は、UNTトークンのみが生成されます。

UNT、SAML

サービスがUNTまたはSAMLトークンを使用

「セキュリティ」パネルまたは「トランスポート」パネルで、ユーザー名とパスワードを指定する必要があります。両方指定した場合は、UNTトークンのみが送信されます。

X.509、SAML

サービスがX.509またはSAMLトークンを使用

次のいずれかを指定する必要があります。

- 「セキュリティ」パネルでユーザー名とパスワード

- 「トランスポート」パネルでユーザー名とパスワード

- WSS X.509資格証明が関連付けられているサービス・キー・プロバイダ

UNT、X.509、SAML

サービスがUNT、X.509、またはSAMLトークンを使用

次のいずれかを指定する必要があります。

- 「セキュリティ」パネルでユーザー名とパスワード

- 「トランスポート」パネルでユーザー名とパスワード

- WSS X.509資格証明が関連付けられているサービス・キー・プロバイダ

58.8.1 サービスとポリシーの制限

SAMLポリシーを持つプロキシ・サービスとSAML holder-of-keyポリシーを持つビジネス・サービスのテストには、次の制限があります。

- インバウンドSAMLポリシーを持つプロキシ・サービスのテストはサポートされていません。

- SAML holder-of-keyポリシーを持つビジネス・サービスのテストは特殊なケースです。SAML holder-of-keyのシナリオは、次の2とおりの方法で構成できます。

- 整合性ポリシーとして(推奨アプローチ)

- IDポリシーとして

どちらの場合も、ユーザー名とパスワードを指定する必要があります。SAMLアサーションはこのユーザーの代理として機能します。SAML holder-of-keyが整合性ポリシーとして構成されている場合は、サービス・キー・プロバイダも指定する必要があります。このサービス・キー・プロバイダには、デジタル署名資格証明が割り当てられている必要があります。これは、IDポリシーがない場合でもユーザー名とパスワードを指定する必要がある唯一のケースであり、特殊なケースです。

注意:

テスト・コンソールでテストを実行した後、WSSで生成されたエンベロープが必ずしも有効なエンベロープというわけではありません。テスト・コンソールの結果ページには、読みやすくするために空白が挿入されています。つまり、保護されたSOAPメッセージは、ホワイト・スペースが追加された状態で表示されます。ホワイト・スペースはドキュメントのセマンティクスに影響する可能性があるため、このようなSOAPメッセージはリテラル・データとして必ずしも使用できるわけではありません。たとえば、デジタル署名はホワイト・スペースの影響を受け、無効になることがあります。

58.9 セキュリティとトランスポートについて

テスト・コンソールを使用してBASIC認証でHTTPビジネス・サービスをテストする場合、テスト・コンソールは、ビジネス・サービスのサービス・アカウントのユーザー名とパスワードを認証します。同様に、認証を必要とするJMS、電子メールまたはFTPビジネス・サービスをテストする場合、テスト・コンソールは、そのビジネス・サービスに関連付けられたサービス・アカウントを認証します。

テスト・コンソールでは、プロキシ・サービスをテストするときに、HTTPリクエストはネットワーク経由で送信されません。そのため、トランスポート・レベルのアクセス制御は適用されません。

58.10 テスト・コンソールのアンデプロイ

Oracleは、本番システムでテスト・フレームワークを使用しないことをお薦めします。たとえば、パイプラインのテストでは、アクセス制御を含む重要なセキュリティ・ステップの一部がバイパスされます。

Service Busドメインを作成する場合、構成ウィザードには、デフォルトで、管理サーバーおよびすべての管理対象サーバーのターゲットとしてALSBテスト・フレームワーク(テスト・コンソール)が含まれます。次の項では、テスト・コンソールをアンデプロイする様々なオプションについて説明します。

- ドメイン作成前のテスト・コンソールの割当て解除

- サーバーが実行されている場合のテスト・コンソールの割当て解除

- サーバーが実行されていない場合のテスト・コンソールの割当て解除

58.10.1 ドメイン作成前のテスト・コンソールの割当て解除

ドメインの作成前に、Oracle Fusion Middleware構成ウィザードでテスト・コンソールを割当て解除するには、次の手順を実行します。

1. 構成ウィザードを使用してService Busドメインを作成する場合、「デプロイメントとサービス」のオプションの構成を選択します。

2. 後続の関連ウィザード・ページで、サーバーごとに、「ターゲット」パネルでService Busテスト・フレームワークを選択し、左矢印をクリックしてそれを「デプロイメント」パネルに移動します。

ウィザードによってドメインが作成される場合は、テスト・コンソール(OSB_ORACLE_HOME\lib\apps\TestFwk.ear)はデプロイされません。

58.10.2 サーバーが実行されている場合のテスト・コンソールの割当て解除

すでにテスト・コンソールがService Busサーバーにデプロイされ、サーバーが実行中の場合は、テスト・コンソールをアンデプロイできます。

実行中のService Busドメイン上のテスト・コンソールをアンデプロイするには:

1. Oracle WebLogic Server管理コンソールを起動し、ログインします。

2. 左側のナビゲーション・ペインの「ドメイン構造」の下にある「デプロイメント」をクリックします。

「デプロイメントのサマリー」ページが表示されます。

3. 「デプロイメント」表で、Service Busテスト・フレームワークをクリックします。

Service Busテスト・フレームワークの「概要」ページが表示されます。

4. 「ターゲット」タブをクリックします。

5. 「ターゲットの割当」表のService Busテスト・フレームワークの横のチェック・ボックスを選択して、すべてのフレームワーク・リソースを選択します。

6. 「ターゲットの変更」をクリックします。

7. 「デプロイメントのターゲット指定」ページで、管理サーバーおよびすべての管理対象サーバーの横のチェック・ボックスを選択解除します。

8. 「はい」をクリックします。

設定が正常に更新されたことを示すメッセージが表示されます。

58.10.3 サーバーが実行されていない場合のテスト・コンソールの割当て解除

Service Busドメインが実行されていない場合は、WebLogic Scripting Tool (WLST)を使用して、ドメインからテスト・コンソールのターゲット設定を解除できます。

WLSTを使用してテスト・コンソールをターゲット設定解除するには:

1. WLSTを使用する環境が設定されていない場合は、『WebLogic Scripting Toolの理解』の対話モードまたはスクリプト・モードでのWLSTの主な使用手順に関する項を参照してください。

2. 次のコマンドを使用してWLSTをオフラインで呼び出します。

C:>java weblogic.WLST

注意:

このコマンド用に環境が適切に設定されている必要があります。お使いのオペレーティング・システムに応じて、WL_HOME/server/binからsetWLSEnv.cmdまたはsetWLSEnv.shを実行します。

3. 構成ウィザードを使用して作成したドメインを読み取るために、次のコマンドを実行します。

wls:/offline>readDomain('C:/oracle/user_projects/domains/domain_name')

4. Service Busテスト・フレームワーク・アプリケーションをターゲット設定解除するには、次のコマンドを実行します。

wls:/offline/domain_name>unassign("AppDeployment", "Service Bus Test Framework", "Target", "AdminServer", "ManagedServer_1", "ManagedServer_2")

このコマンドにはすべての管理対象サーバーの名前を含めます。

5. ドメインを更新するには、次のコマンドを実行します。

wls:/offline/base_domain>updateDomain()

6. ドメインを閉じるには、次のコマンドを実行します。

wls:/offline/base_domain>closeDomain()

7. 終了するには、WLSTコマンド・プロンプトから次のコマンドを実行します。

wls:/offline>exit()

58.11 サービスのテスト・コンソール・ページ参照

次の項では、Service Busサービスをテストする際に、Oracle Service Busテスト・コンソールに表示される各セクションについて説明します。すべてのコンポーネントですべてのセクションが表示されるわけではなく、セクションの一部はテストするコンポーネントによって異なります。

テスト・コンソール・リクエスト・ページには、テストするサービスのタイプと、それが使用しているメッセージングのタイプに応じて、次のセクションの組合せが含まれます。

- テスト構成テスト・コンソール・プロパティ

- サービス操作テスト・コンソール・プロパティ

- リクエスト・ドキュメント・テスト・コンソール・プロパティ

- セキュリティ・テスト・コンソール・プロパティ

- 認証テスト・コンソール・プロパティ

- トランスポート・テスト・コンソール・プロパティ

- 添付ファイル・テスト・コンソール・プロパティ

58.11.1 テスト構成テスト・コンソール・プロパティ

このセクションはパイプラインをテストする場合のみ表示され、1つのフィールド「トレースを含む」が含まれます。このチェック・ボックスを選択すると、各処理ステージでのメッセージの状態のトレースが含まれます。

58.11.2 サービス操作テスト・コンソール・プロパティ

このセクションは、操作するWSDLファイルに基づいてプロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合をテストする場合、およびRESTfulプロキシまたはビジネス・サービスをテストする場合に表示されます。このセクションに表示されるされるフィールドは、サービスがWSDLベースかRESTfulか、およびRESTfulビジネス・サービスのSOAPビューまたはRESTビューのどちらを選択するかによって異なります。

RESTfulビジネス・サービスでは、RESTビューに純粋なRESTサービスとして情報が表示されます。SOAPビューでは、データを参照する呼出し元(パイプライン)として(WSDL SOAPサービスとしてラップされた)情報が表示されます。SOAPビューのフィールドはWSDLベース・サービスのフィールドと同じです。

表58-5 テスト・コンソール・プロパティ - サービス操作

プロパティ

説明

操作

サービスに関連付けられている操作のリストから、テストするWSDL操作を選択します。このフィールドはWSDLベース・サービスおよびRESTfulビジネス・サービスのSOAPビューで使用できます。

リソース

リストから既存のURLリソース・パスを選択します。リソースとは指定可能な特定の情報の任意のソースです。このフィールドは、RESTfulサービスのテスト時にのみ使用できます。

メソッド

実行するREST操作を選択します。このフィールドは、RESTfulサービスのテスト時にのみ使用できます。

承認

オプションのリストから、テスト入力用に承認されるメディア・タイプを選択します。オプションはサービス構成によって異なります。このフィールドは、RESTfulサービスのテスト時にのみ使用できます。

58.11.3 リクエスト・ドキュメント・テスト・コンソール・プロパティ

入力フィールドによって、プロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合へ送信されるリクエスト・メッセージが生成されます。「リクエスト・ドキュメント」セクションに入力する値は、サービス・タイプに固有です。それぞれで必要とされる入力のサービス・タイプと説明を以下に示します。

呼出しモード・オプションは、任意のSOAPまたは任意のXMLプロキシ・サービスをテストする場合にのみ表示されます。一方向のサービス呼出しの場合は、「リクエスト/レスポンス」チェックボックスを選択解除します。リクエスト/レスポンス呼出しのチェック・ボックスを選択します。

表58-6 テスト・コンソール・プロパティ - リクエスト・ドキュメント

サービス・タイプ

説明

WSDL

複数の操作が定義されたWSDLベースのサービスの場合、テスト・コンソールはサービスのテスト時に使用するサンプル・ドキュメントを生成および提供します。このサンプル・データを直接使用し、編集してテストを実行するか、または、独自のテスト・データを指定します。

任意のXML

ペイロードの形式でリクエスト入力を入力します。ペイロードは、送信されるメッセージのコンテンツです。コンテンツはXMLドキュメントであることが想定されます。ファイルを参照することも、テキスト・ボックスにメッセージ・コンテンツを直接入力することもできます。

任意のSOAP

ペイロードの形式でリクエスト入力を入力します。ペイロードは、送信されるメッセージのコンテンツです。コンテンツはSOAPエンベロープであることが想定されます。ファイルを参照することも、テキスト・ボックスにメッセージ・コンテンツを入力することもできます。

メッセージング

ファイルベースまたはテキストベースで単一の入力を入力します。メッセージ・サービスによって、バイナリ、Java、MFL、XML、テキストを含む各種入力タイプが定義されます。タイプがnoneの場合、入力は必要ありません。

Oracleでは、ファイルからのバイナリの入力をお薦めします。テキスト領域に入力したデータは、システム・エンコーディングでバイナリに変換されます。

テキスト型のサービスの場合、ファイルから入力したデータはテキストへの変換が必要です。エンコーディング入力フィールドでは、変換時に適用するエンコーディングを指定します。このフィールドを構成しない場合は、システム・エンコーディングが使用されます。デフォルトでは、エンコーディング・フィールドはプロキシ・サービスのエンドポイントに構成されたエンコーディング値で初期化されます。

SOAPドキュメント

SOAPドキュメントの場合、SOAPエンベロープは通常0個以上のヘッダーと1つの本体ペイロードで構成されます。「フォーム」タブと「XML」タブではそれぞれ異なる方法でコンテンツを指定します。

「フォーム」タブには「SOAPヘッダー」フィールドと「SOAP本体」フィールドがあります。「SOAPヘッダー」フィールドの内容は、SOAP Headerタグであることが想定されます(これにより1つ以上のヘッダーを定義できます)。「SOAP本体」フィールドには実際にメッセージの一部として送信されるデータが含まれます。コンテンツはXMLドキュメントであることが想定されます。ヘッダーと本体の両方を使用してSOAPエンベロープが生成されます。

SOAP RPC

SOAP RPCの場合、SOAPエンベロープは0個以上のヘッダーと0個以上の引数で構成される。「フォーム」タブと「XML」タブではそれぞれ異なる方法でコンテンツを指定します。

「フォーム」タブにはSOAPヘッダーの入力が1つと、引数ごとに1つの入力フィールドがあります(入力フィールドの名前は引数の名前に相当します)。「SOAPヘッダー」フィールドの内容は、SOAP Headerタグであることが想定されます(これにより1つ以上のヘッダーを定義できます)。

テスト・コンソールはWSDLファイルを使用して、各引数のタイプを検出します。プリミティブの型の場合は1行の入力フィールドを使用し、XMLの型の場合は複数行の入力フィールドを使用します。テストを効率化するサンプル・ドキュメントが自動的に生成されます。

テスト・コンソールにより、ヘッダーと引数を使用してSOAPエンベロープが生成されます。

「XML」タブには1つの入力フィールドがあります。このフィールドの内容は、送信されるSOAPエンベロープであることが想定されます。ペイロード(XML入力)はファイル・ベースまたはテキスト・ベースです。テキスト入力よりファイルの参照による入力が優先されます。テストに使用するファイルを参照して選択します。

REST

RESTfulサービスの入力は、テストするリソース、およびSOAPビューまたはRESTビューのどちらを使用しているかによって異なります。

SOAPビューで、ペイロードの形式でリクエスト入力を行います。ペイロードは、送信されるメッセージのコンテンツです。「参照」をクリックしてファイルへの移動またはファイルの選択を行うか、テキスト・ボックスにメッセージ・コンテンツを入力します

RESTビューで、RESTパラメータの形式またはペイロードの形式でリクエスト入力を行うことができます。パラメータ・フィールドが表示される場合は、各パラメータの入力を行ってください。「ペイロード」フィールドが表示されている場合は、オプションのリストからメディア・タイプを選択してから、「参照」をクリックしてファイルへの移動またはファイルの選択を行うか、テキスト・ボックスにメッセージ・コンテンツを入力します

58.11.4 セキュリティ・テスト・コンソール・プロパティ

テストするサービスがOWSMポリシーを使用して保護されている場合は、テスト・コンソールに「セキュリティ」パネルが表示されます。オーバーライド値を変更したり、セキュリティ・ポリシーを追加または削除したりできます。別のポリシーをテストするには、「追加」ボタンをクリックし、テストするポリシーを選択します。詳細は、「Oracle Web Services Managerを使用したOracle Service Busのセキュリティ」を参照してください。

表58-7 テスト・コンソール・プロパティ - セキュリティ

プロパティ

説明

ポリシー名

テストするサービスにアタッチされたOWSMポリシーの名前が表示されます。

プロパティ

リストされたポリシーについて、使用可能な各オーバーライド・プロパティの名前が表示されます。使用可能なプロパティは、アタッチされたポリシーに応じて異なります。

デフォルト値

各オーバーライド・プロパティのデフォルト値が表示されます(存在する場合)。

オーバーライド値

サービスのテスト時にオーバーライド・プロパティに使用する値を入力します。

アクション

この列の「削除」アイコンをクリックすると、テスト目的でアタッチされたポリシーが削除されます。

58.11.5 認証テスト・コンソール・プロパティ

テストしているサービスがSAMLトークンを想定しているビジネス・サービスへメッセージをルーティングする場合は、これがトークンで表されるIDになります。詳細は、「Oracle Service BusでのSAMLの使用」を参照してください。

表58-8 テスト・コンソール・プロパティ - 認証

プロパティ

説明

ユーザー名

サービスを呼び出したときにテスト・サービスによって使用されるセキュリティ・コンテキストを設定するためのユーザー名を入力します。このフィールドをWebサービス・セキュリティ(WSS)のユーザー名フィールドと混同しないでください。これは、ローカル・セキュリティ・レルムで有効なユーザー名とパスワードである必要があります。ユーザー名またはパスワードが無効な場合、テスト・サービスでクライアント側のエラーが発生します。

注意: HTTPカスタム・トークン認証を使用するプロキシをテスト・コンソールで呼び出した場合、認証チェックは行われません。

パスワード

ユーザー名に関連付けられるパスワードを入力します。

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

認証に使用するサービス・キー・プロバイダを入力します。このフィールドは、 クライアントの証明書認証を使用するHTTPSビジネス・サービスをテストする場合に使用します。サービス・プロバイダにはSSLクライアント資格が関連付けられている必要がある。テスト・サービスはSSLハンドシェイクでその資格証明を使用します。

58.11.6 トランスポート・テスト・コンソール・プロパティ

テスト・コンソールの「トランスポート」パネルでは、テスト・システムのメッセージのメタデータとトランスポート・ヘッダーを指定します。次の項では、トランスポート設定とそれらが処理に及ぼす影響について説明します。

- テスト・コンソールのトランスポート設定

- テスト・コンソールでのランタイムによるトランスポート設定の使用方法

58.11.6.1 テスト・コンソールのトランスポート設定

テスト・コンソールの「トランスポート」セクションは、テストするトランスポートのタイプにより異なります。図58-4に、WSDLベースのプロキシ・サービスの「トランスポート」セクションを示します。

図58-4 テスト・コンソールの「トランスポート」パネル

パイプラインのメタデータとトランスポート・ヘッダーを設定すると、アウトバウンド・トランスポートのアクションに影響します。メタデータ、メッセージ、およびヘッダーをテストして、パイプライン出力を表示できます。プロキシ・サービスのテスト時に「トランスポート」パネルに表示されるフィールドは、パイプラインで使用できるヘッダーとメタデータを表します。プロキシ・サービスによっては、テスト・コンソールに表示されるフィールドをフィルタできない場合もあります。HTTPベースのすべてのリクエストに対して、トランスポート・パラメータの同じセットが表示されます。

「ユーザー名」と「パスワード」フィールドは、プロキシ・サービスを実行しているユーザーの基本認証を実装するために使用されます。「ユーザー名」と「パスワード」フィールドは、特にトランスポートとの関連はありません。

メタデータ・フィールドは、「ユーザー名」フィールドおよび「パスワード」フィールドと、トランスポート・ヘッダー・フィールドの間に配置されています。表示されるフィールドは、サービスのトランスポート・タイプに基づいています。サービスを定義したときに選択した操作選択アルゴリズムに応じて、事前移入されているフィールドもあります。選択アルゴリズムの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。

テストするサービスのタイプに応じて、「トランスポート」パネルのフィールドに値を指定します。パイプラインまたは分割-結合をテストする場合、テスト・データは、呼出し元から離れ、テストするサービスに渡される時点で予期される状態のメッセージを表す必要があります。ビジネス・サービスをテストする場合、テスト・データは、ルート・ノードまたはサービス・コールアウトから送信されるデータを表します。

次のプロパティは、大半のトランスポート・タイプで共通です。特定のヘッダーおよびメタデータの詳細と、テスト・フレームワークでそれらが処理される仕組みについては、「テスト・コンソールでのランタイムによるトランスポート設定の使用方法」を参照してください。

表58-9 テスト・コンソール・プロパティ - トランスポート

プロパティ

説明

ユーザー名

テストを実行しているユーザーに対してBasic認証を実装するためのユーザー名を入力します。これはトランスポート固有ではありません。

パスワード

上記で入力したユーザー名のパスワードを入力します。

リクエスト/レスポンス

一方向のサービス呼出しの場合は、「リクエスト/レスポンス」チェックボックスを選択解除します。リクエスト/レスポンス呼出しのチェック・ボックスを選択します。このオプションは、任意のSOAPまたは任意のXMLプロキシ・サービスをテストする場合にのみ表示されます。

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

認証に使用するサービス・キー・プロバイダを入力します。このフィールドは、 クライアントの証明書認証を使用するHTTPSビジネス・サービスをテストする場合に使用します。サービス・プロバイダにはSSLクライアント資格が関連付けられている必要がある。テスト・サービスはSSLハンドシェイクでその資格証明を使用します。

58.11.6.2 テスト・コンソールでのランタイムによるトランスポート設定の使用方法

「トランスポート・テスト・コンソール・プロパティ」では、テスト・コンソールでプロキシ・サービスまたはビジネス・サービスをテストするときに、アウトバウンド・リクエストのトランスポート・ヘッダー、トランスポート・メタデータおよびトランスポート関連のセキュリティ・データの値を構成する方法が説明されています。ただし、テスト・コンソールで作成できる仕様の一部は、実行時に無視されます。つまり、特定のヘッダーやメタデータの値は、テストの実行時にService Busランタイムで上書きされるか無視されます。制限のあるヘッダーとメタデータについては、表58-10を参照してください。

表58-10 テスト・コンソールで指定するトランスポート・ヘッダーとメタデータの値の制限

トランスポート

サービス・タイプ

制限の説明

影響を受けるトランスポート・ヘッダー

HTTP(S)

注意: プロキシ・サービスをテストするときに、テスト・コンソールではネットワーク経由でHTTPリクエストを送信しないため、トランスポートレベルのアクセス制御は適用されません。

プロキシ・サービス

実行時に、設定したすべてのトランスポート・ヘッダーとその他のフィールドが保持されます。

すべて

HTTP(S)

ビジネス・サービス

これらのパラメータに設定したすべての値がService Busランタイムでオーバーライドされます。

Content-Length

Content-Type

relative-URI

client-host

client-address

JMS

プロキシ・サービス

トランスポート・ヘッダー・アクションの構成と同じ制限が適用されます。

表12-8に示すJMSトランスポート・ヘッダーの制限を参照してください。

JMS

ビジネス・サービス

トランスポート・ヘッダー・アクションの構成と同じ制限が適用されます。

表12-8に示すJMSトランスポート・ヘッダーの制限を参照してください。

電子メール

プロキシ・サービス

制限はありません。実行時に、設定したトランスポート・ヘッダーとその他のフィールドが保持されます。

なし

電子メール

ビジネス・サービス

これらのパラメータに設定したすべての値がService Busランタイムでオーバーライドされます。

Content-Type

ファイル

プロキシ・サービス

制限はありません。実行時に、設定したトランスポート・ヘッダーとその他のフィールドが保持されます。

たとえば、FileName (トランスポート・メタデータ)に指定した値は、出力ファイル名に付加されますたとえば、1698922710078805308-b3fc544.1073968e0ab.-7e8e-{$FileName}です。

なし

ファイル

ビジネス・サービス

制限はありません

なし

FTP

プロキシ・サービス

制限はありません。実行時に、設定したトランスポート・ヘッダーとその他のフィールドが保持されます。

なし

FTP

ビジネス・サービス

制限はありません

なし

58.11.7 添付ファイル・テスト・コンソール・プロパティ

テスト・コンソールの「添付ファイル」セクションを使用して、添付ファイルをテスト入力の一部として含めます。表58-11は、このセクションのプロパティを示しています。

表58-11 プロキシ・サービス・テスト・コンソール・プロパティ

プロパティ

説明

Content-Type

添付ファイルを識別するグローバルに一意の参照を入力します。

Content-ID

添付ファイルのメディア・タイプとサブタイプを入力します。

Content-Description

コンテンツの簡単な説明を入力します。

Content-Disposition

プロキシ・サービスが添付ファイルを処理する方法を指定します。

Content-Transfer-Encoding

添付ファイルのエンコード方法を指定します。

ファイル

添付ファイルとしてテストするファイルを参照して選択します。

Resp.Attach.Display Limit

テスト結果の表示に含める添付ファイルの文字数。

59 Oracle Service Busサービスのデプロイ

この章では、Service BusプロジェクトおよびアプリケーションをOracle WebLogic Serverにデプロイするための手順について説明します。 Oracle Service Busコンソール、JDeveloper、Fusion Middleware ControlおよびService BusデプロイメントAPIからService Busコンポーネントをデプロイできます。異なる環境へのデプロイおよび異なる環境からのデプロイでは、カスタマイズ・ファイルを使用してエンドポイントURIなどの環境値を更新できます。

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

- デプロイメントの概要

- デプロイする前に

- Oracle Service Busコンソールからのデプロイ

- JDeveloperからのデプロイ

- Fusion Middleware ControlでのService Bus構成JARファイルのデプロイ

- オンライン構成の更新

- クラスタでのオンライン構成の更新

59.1 デプロイメントの概要

デプロイメントは、Service Busリソースをパッケージ化し、それらをターゲット・アプリケーション・サーバーに転送するプロセスです。リソースは、次のような様々な方法によってデプロイできます。

- Oracle Service Busコンソールでの現行セッションのアクティブ化。

- JDeveloperでのデプロイ・コマンドの使用によるプロジェクトまたはアプリケーションのデプロイ。

- JDeveloperでの構成JARファイルのアプリケーション・サーバーへのエクスポート。また、JDeveloperに含まれる統合アプリケーション・サーバーにデプロイすることで、アプリケーションおよびプロジェクトの実行、デバッグおよびテストが行えます。

- Fusion Middleware Controlを使用した構成JARファイルのインポート。

- Mavenプラグインを使用したMaven環境へのService Busサービスのデプロイ。詳細は、「Oracle Service Bus開発Mavenプラグインの使用」を参照してください。

- WLSTコマンドを使用したセッションのアクティブ化および構成と環境値のインポート。詳細は、『Oracle Service Busの管理』のOracle Service BusデプロイメントAPIの使用に関する項を参照してください。

Service Busリソースのデプロイ後は、Fusion Middleware Controlを使用してランタイムでそれらのリソースをモニターおよび管理できます。詳細は、『Oracle Service Busの管理』のOracle Service Busランタイムの管理に関する項を参照してください。

59.2 デプロイする前に

Service Bus構成をデプロイする方法に関係なく、デプロイする前に次の項を確認してください。

- 構成ウィザードを使用したService Busドメインの作成

- 競合の解決

- JMSリソースの構成

- セキュリティの構成

59.2.1 構成ウィザードを使用したService Busドメインの作成

Service Bus構成をデプロイするには、Service Busリソースをデプロイする実行中のService Busドメインが必要です。ドメインには、実行中のデータベースで必要なスキーマが存在している必要があります。Oracle Fusion Middleware構成ウィザードを使用したService Busドメイン作成の詳細は、『Oracle Service Busのインストレーションおよび構成』のOracle Service Busドメインの構成に関する項を参照してください。

59.2.2 競合の解決

デプロイ中のService Busリソースに競合があると、そのデプロイメントは失敗します。「競合の表示と解決」の説明に従い、リソースのアクティブ化またはエクスポートの前に、既存の競合を表示し、解決します。Service Busリソースに競合がある場合、JDeveloperからのデプロイまたはコンソールからのアクティブ化は失敗します。

59.2.3 JMSリソースの構成

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

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

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

すべてのService Bus JMSリソースを単一のJMSモジュールにまとめるには、WebLogic Server管理コンソールを使用して、プロキシ・サービスのエンドポイントとして使用する宛先を含む新しいJMSモジュールを作成します。JMSリソースの構成の詳細は、『Oracle WebLogic Server JMSリソースの管理』のJMSリソースの構成方法に関する項を参照してください。

59.2.4 セキュリティの構成

Service Busでは、WebLogic Serverのセキュリティ機能を利用して、メッセージの機密性と整合性を保証し(メッセージ・レベルのセキュリティ)、WebLogic Server、サービス・クライアント、およびビジネス・サービスの間の接続を保護し(転送レベルのセキュリティ)、認証と認可(アクセス制御)を行います。Oracle Service Busのセキュリティを構成する方法の詳細は、「セキュリティ」を参照してください。

注意:

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

59.3 Oracle Service Busコンソールからのデプロイ

Oracle Service Busコンソールでは、変更をアクティブ化することで、作成したサービスをランタイムにデプロイします。アクティブ化した変更は、ただちに実行時環境で使用可能になります。また、Oracle Service Busコンソールを使用して、実行時にアクティブ化されるコンポーネントを更新することもできます。

59.3.1 コンソールからデプロイする方法

Service Busドメインの構成と保護を終え、サービスに必要なJMSリソースを追加すると、Service Bus構成が入ったJARファイルをインポートできます。構成メタデータをインポートした後、ドメインの環境固有の情報を更新できます。セキュリティ関連の変更を除くService Bus構成へのすべての変更には、セッションが必要です。

構成JARファイルのコンテンツをデプロイするには:

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

「セッションの作成方法」を参照してください。

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

「コンソールで構成JARファイルからリソースをインポートする方法」を参照してください。

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

『Oracle Service Busの管理』のOracle Service Busコンソールを使用した環境値の検索と置換に関する項または構成ファイルを使用した環境値と操作設定の更新に関する項を参照してください。

4. 競合がないことを確認します(競合はツールバーに「競合」アイコンで示されます)。

競合がある場合は、「競合の表示と解決」の説明に従って解決します。

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

「セッションのアクティブ化方法」を参照してください。

WebLogic Scripting Tool (WLST)とService BusのdeploymentMBeanを使用して、プログラムで構成のインポートと更新を行うこともできます。詳細は、『Oracle Service Busの管理』のOracle Service BusデプロイメントAPIの使用に関する項を参照してください。

59.4 JDeveloperからのデプロイ

アプリケーションまたはプロジェクトをWebLogic Serverに最初にデプロイするときに、アプリケーション全体とすべてのプロジェクトがパブリッシュされます。その後のアプリケーションのデプロイメントでは、変更されたリソースのみがサーバーにパブリッシュされます。アプリケーション内のService Busリソースに競合があると、そのデプロイメントは失敗します。

59.4.1 WebLogic Serverへの接続の作成方法

JDeveloperで、Service Busアプリケーションがデプロイされるアプリケーション・サーバーへの接続を作成する必要があります。Service Busサービスをホストしている各アプリケーション・サーバーに対してこのタスクを1回実行するだけです。次のタイプのサーバーに接続できます。

- スタンドアロン・サーバー: JDeveloperに管理されていないサーバー。スタンドアロン・サーバーには、Oracle Cloudの構成ウィザードとWebLogicサーバーを使用して作成したドメインが含まれます。スタンドアロン・サーバーへのデプロイにはデプロイ・コマンドのみを使用できます。デプロイ先のサーバーが実行されている必要があります。

- 統合サーバー: JDeveloperで管理でき、開発とテストでのみ使用されるサーバー。接続の設定時、JDeveloperによるサーバーのライフサイクルの管理を許可すると、実行コマンドまたはデプロイ・コマンドを使用してJDeveloperからサーバーに直接デプロイできます。JDeveloperでライフサイクルを管理しない場合は、サーバーを手動で起動および停止する必要があります。この場合、サーバーがすでに実行されていれば、実行コマンドのみをデプロイに使用できます。

アプリケーション・サーバー接続を作成するには:

1. アプリケーション・サーバー・ナビゲータが表示されていない場合、「ウィンドウ」メイン・メニューをクリックして「アプリケーション・サーバー」を選択します。

2. アプリケーション・サーバー・ナビゲータで、「アプリケーション・サーバー」を右クリックして「新規アプリケーション・サーバー」を選択します。

「アプリケーション・サーバー接続の作成」ウィザードが表示されます。

3. 「スタンドアロン・サーバー」または「統合サーバー」のいずれかを選択します。

4. 「次」をクリックします。

5. 次のいずれかを行います:

- 「スタンドアロン・サーバー」を選択した場合は、接続の名前を入力します。Oracle Cloudサーバーに接続している場合は、「接続タイプ」リストから「Oracle Cloud」を選択します。そうでない場合は、接続タイプをデフォルト値(WebLogic 12.x)のままにします。

- 「統合サーバー」を選択した場合は、接続名を入力します。JDeveloperから実行モードおよびデバッグ・モードでサーバーを起動する場合は、「JDeveloperでこのサーバー・インスタンスのライフサイクルを管理します」を選択し、ドメインおよびサーバー・インスタンスの場所を入力します。

6. 「次」をクリックします。

7. 「認証」ページで、ユーザー名とパスワードを入力してWebLogic Serverに接続し、「次へ」をクリックします。

8. 「構成」ページで、次の情報を入力します。

オプション

説明

Oracle Cloudサーバー接続を作成する場合:

データ・センター: 使用するデータ・センター、または必要な場合は新しいデータ・センターの短縮コードを入力します。たとえば、US Commercial 1 [us1]では、短縮コードはus1です。

Identityドメイン: Oracle Cloudサービス・インスタンスのアイデンティティ・ドメインを入力します。

サービス名: Oracle Cloudサービス・インスタンスのサービス名を入力します。

Oracle Cloudサービスにサインアップすると、Oracle Cloudサービス・インスタンスへの接続を確立するために、ここに入力するデータ・センター、アイデンティティ・ドメインおよびサービス名に関する情報を受信します。

クラウド以外のサーバー接続を作成する場合:

Weblogicホスト名(管理サーバー): WebLogic Serverが常駐するサーバーの名前。

Weblogicホスト名(管理サーバー): WebLogic Serverが常駐するサーバーの名前。

SSLポート: WebLogic Serverで使用されるSSLポート番号。

Secure Sockets Layer (SSL)を使用するには、「常にSSLを使用」チェック・ボックスを選択します。

WebLogicドメイン: WebLogic Serverドメインの名前。

ドメインの指定の詳細は、「ヘルプ」をクリックしてください。

9. 「次」をクリックします。

10. 「テスト」ページで、「接続のテスト」をクリックしてサーバー接続を検証します。

注意:

テストは、実行中のサーバーに対して行われた場合にのみ成功します。

11. 接続が成功したら「終了」をクリックします。それ以外の場合は、「戻る」をクリックして前のダイアログで修正を行います。

接続テストに失敗しても、接続は作成されます。

59.4.2 デプロイメント・プロファイルの作成方法

デプロイメント・プロファイルにより、プロジェクトまたはアプリケーションをデプロイするアプリケーション・サーバーについての情報がJDeveloperに提供されます。このプロファイルのタイプは、選択したプロジェクトのみをデプロイするか、Service Busアプリケーション全体をデプロイするかを示します。Service Busは、作成する各Service Busプロジェクトにデフォルトのプロジェクト・デプロイメント・プロファイルを追加し、各Service Busアプリケーションにデフォルトのアプリケーション・デプロイメント・プロファイルを追加します。それぞれが異なるアプリケーション・サーバーにデプロイされる追加デプロイメント・プロファイルを定義できます。

デプロイメント・プロファイルの使用の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のデプロイメント・プロファイルの作成および編集方法に関する項を参照してください。

デプロイメント・プロファイルを作成するには:

1. アプリケーション・ナビゲータで、Service Busプロジェクトを右クリックします。

2. 「デプロイ」をポイントし、「新規デプロイメント・プロファイル」を選択します。

「デプロイメント・プロファイルの作成」ダイアログが表示されます。

3. 「プロファイル・タイプ」フィールドで、次のいずれかを実行します。

- 選択したプロジェクトのみをデプロイするプロファイルを定義するには、「Service Busプロジェクト」を選択します。

- 選択したプロジェクトを含むアプリケーション内のすべてのプロジェクトをデプロイするプロファイルを定義するには、「Service Bus構成」を選択します。

4. 「デプロイメント・プロファイル名」フィールドに、プロファイルの一意の識別名を入力します。

5. 「OK」をクリックします。

6. 「保存」をクリックします。

59.4.3 Service Busデプロイメントをカスタマイズする方法

JDeveloperでは、Service Busのデプロイメントをカスタマイズできます。

JDeveloperでService Busのデプロイメントをカスタマイズするには:

1. 「アプリケーション」メニューから、「アプリケーション・プロパティ」を選択します。

2. 「Service Bus構成」をクリックします。

3. 次のいずれかを行います:

a. 「カスタム設定の使用」を選択し、「設定のカスタマイズ」ボタンをクリックして、JDeveloperで複数のService Busアプリケーションに使用できるデプロイメント設定をカスタマイズします。

b. アプリケーション設定の使用を選択し、JDeveloperで現在選択しているService Busアプリケーションのデプロイメント設定をカスタマイズします。

4. デプロイメント・プリファレンスと一致するように、次の設定を編集します。

要素

説明

設定の保持

設定を保持するオプションがあります。

環境変数値の保持

インポート先システムの既存リソースの環境変数値を保持する場合は、このオプションを選択します。

セキュリティおよびポリシーの設定の保持

インポート先システムのセキュリティ構成(アクセス制御ポリシーを除く)と(WSDLドキュメントにバインドされるのではなく)サービスに直接バインドされるWS-Policyへの参照を保持する場合は、このオプションを選択します。このオプションを選択すると、セキュリティおよびポリシーの構成がJDeveloperで更新済である場合でも、既存のリソースの値はインポート時に保持されます。

資格証明(ユーザー名/パスワード)の保持

サービス・キー・プロバイダのインポート先システムのPKI資格証明、サービス・アカウントのユーザー名とパスワード、およびSMTPサーバー、JNDIプロバイダ、UDDIレジストリ内のユーザー名とパスワード資格証明を保持する場合は、このオプションを選択します。

セッション設定

アーティファクトをService BusデプロイメントにパブリッシュするときのService Busセッションのオプションが含まれています。

パブリッシュ後にセッションをアクティブ化

インポートが正常に完了したらすぐに、Oracle Service Busコンソールにセッションを作成してアクティブ化するには、このオプションを選択します

アクティブ化に失敗した場合にセッションを破棄

インポートの完了後にセッションをアクティブ化することを選択していて、さらにセッションのアクティブ化に失敗したときにセッションを破棄する場合は、このオプションを選択します。インポートしているいずれかのリソースで競合が発生すると、失敗する場合があります。

説明

セッションの簡単な説明を入力します。

デプロイメント・カスタマイズ・ファイル

インポートに含めるカスタマイズ・ファイルを指定するか、「参照」をクリックし、構成ファイルに移動して選択します。カスタマイズの詳細は、『Oracle Service Busの管理』の構成ファイルを使用した環境値と操作設定の更新に関する項を参照してください。

KeyStoreファイル

「参照」をクリックして、JDeveloperでService Busコンポーネントを使用する場合に、サービス・アカウントとサービス・キー・プロバイダの構成に使用するキーストア・ファイルを選択します。

注意: これはターゲット・サーバーがポイントするキーストアと同じである必要があります。

パスワード

キーストア・ファイルのパスワードを入力します。

5. 「OK」をクリックして、変更を保存します。

59.4.4 Service Busプロジェクトまたはアプリケーションのデプロイ方法

選択したプロジェクトのみをWebLogic Serverにデプロイするか、選択したプロジェクトが配置されているアプリケーション全体をデプロイできます。プロジェクト・レベルのデプロイメントは、増分ではなく完全なプロジェクトとそのすべての依存関係をパブリッシュします。プロジェクトまたはアプリケーションをデプロイする場合、処理に使用するデプロイメント・プロファイルを選択します。使用するプロファイルによって、プロジェクトのみをデプロイするか、アプリケーション全体をデプロイするかが決定されます。各プロジェクトに生成されたデフォルト・プロファイルは、そのプロジェクトのみをデプロイします。

Service BusおよびJDeveloperでは現在、Oracle Cloudサーバーへの直接デプロイをサポートしています。Oracle Cloudサーバーへの接続の作成の詳細は、「WebLogic Serverへの接続の作成方法」を参照してください。

注意:

Runコマンド(選択したサーバーへのデプロイと、Service Busテスト・コンソールの起動)を使用したサーバーへのパブリッシュも可能です。統合型のサーバーでは、実行コマンドのみが使用可能です。詳細は、「テスト・コンソールへのアクセス」を参照してください。

始める前に

「WebLogic Serverへの接続の作成方法」の説明しているように、アプリケーション・サーバーに接続していることを確認します。デフォルトのデプロイメント・プロファイルを使用しない場合は、「デプロイメント・プロファイルの作成方法」で説明しているように、新しいプロファイルを作成します。

プロジェクトまたはアプリケーションをデプロイするには:

1. JDeveloperアプリケーション・ナビゲータで、デプロイするプロジェクトを右クリックします。

2. 「デプロイ」をポイントし、使用するデプロイメント・プロファイルの名前を選択します。

正しいプロファイルを選択してください。プロジェクトのみをデプロイするには、「Service Busプロジェクト」のタイプを持つプロファイルを選択します。アプリケーション全体をデプロイするには、「Service Bus構成」のタイプで構成されたプロファイルを選択します。プロジェクト・プロパティ内のデプロイメント・プロファイルの構成を表示できます。

3. デプロイ・ウィザードで、「Service Busサーバーへのデプロイ」を選択して「次へ」をクリックします。

4. 「サーバーの選択」ページで、デプロイ中のサーバーのアプリケーション・サーバー接続の名前を選択します。

「アプリケーション・サーバー」リストにそのサーバーがない場合、「WebLogic Serverへの接続の作成方法」の説明に従って、「アプリケーション・サーバーの追加」をクリックして「アプリケーション・サーバー接続の作成」ウィザードを完了します。

5. 既存のデプロイ済アーティファクトを上書きするには、「同一名モジュールの上書き」を選択します。

6. 「次」をクリックします。

7. デプロイメントの概要情報を参照して、「終了」をクリックします。

「デプロイメント - ログ」ウィンドウで、デプロイメントの進行状況を表示できます。

59.4.5 以前の構成を使用したプロジェクトまたはアプリケーションのデプロイ方法

プロジェクトを一度デプロイすると、以降のデプロイメントで同じ構成を使用する場合はデプロイ・ウィザードをスキップできます。デプロイ・ウィザードをスキップすると、Service Busは前回のプロジェクトのデプロイ時と同じデプロイメント・プロファイルとデプロイ・ウィザードでの選択を使用します。

前回の構成を使用してデプロイするには:

1. JDeveloperアプリケーション・ナビゲータで、デプロイするプロジェクトを右クリックします。

2. 「デプロイ」をポイントし、「Service Busサーバーへのデプロイ」を選択します。

プロジェクトは、プロジェクトのデプロイに使用された最後の構成を使用してデプロイされます。「デプロイメント - ログ」ウィンドウで、デプロイメントの進行状況を表示できます。

59.4.6 JDeveloperを使用したデプロイ時の動作

デプロイメントに成功した場合、デプロイされたプロジェクトが次の場所に表示されます。

- 「アプリケーション・サーバー」→「server_connection_name」→「Service Bus」→「Service_Bus_server_name」の下の「リソース」ウィンドウ。

- 「server_connection_name」→「Service Bus」→「Service_Bus_server_name」の下のアプリケーション・サーバー・ナビゲータ。

これで、Oracle Enterprise Manager Fusion Middleware Controlからアプリケーションをモニターする準備ができました。詳細は、『Oracle Service Busの管理』の管理およびモニター・ページの概要に関する項を参照してください。

デプロイメントに失敗した場合、デプロイメント・ログ・ウィンドウに表示されるメッセージを確認して修正処理を行ってください。

59.5 Fusion Middleware ControlでのService Bus構成JARファイルのデプロイ

ファイルをFusion Middleware Controlにインポートすることで、Service Bus構成JARファイルをデプロイできます。構成JARファイルには、以前別のService Bus環境からエクスポートされたService Busリソースが含まれます。エクスポートおよびインポート機能により、環境をまたいだプロジェクトおよびリソースの移動が容易になります。JARファイルのインポートでは、インポートしたリソースの操作設定および環境値を新しい環境に合せて更新する、個別の構成ファイルをインポートすることもできます。たとえば、構成ファイルではホスト名およびポート番号を更新したり、サービスのモニターを有効化または無効化できます。

Fusion Middleware Controlへのリソースのインポートの詳細は、『Oracle Service Busの管理』のOracle Service BusのFusion Middleware Controlへのインポートに関する項を参照してください。環境構成ファイルの詳細は、『Oracle Service Busの管理』の構成ファイルを使用した環境値と操作設定の更新に関する項を参照してください。

59.6 オンライン構成の更新

構成がデプロイされると、Service Busではシステムの構成情報を動的に変更できます。変更内容を有効にするためにサーバーを再起動する必要はありません。「コンソールからデプロイする方法」で説明している手順を使用して、リソースやプロジェクト、または複数の(関連する、あるいは関連しない)リソースを変更できます。手順2では、リソースを直接コンソール内で変更するか、オブジェクトのすべてまたはサブセットを構成JARファイルからインポートできます。

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

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

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

リソース

最初のバージョン

更新されたバージョン

プロキシ・サービス

X

A

MFL

Y

B

XQuery

W

C

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

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

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

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

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

Service Busは、メッセージがプロキシ・サービスに届いた時点で使用可能なバージョンのプロキシ・サービスとアーティファクトを使用して、メッセージを実行しようとします。これにより、メッセージのアーティファクトの一貫性が保たれます。メッセージ・プロセッサが、メッセージに対してこの動作を保証できない場合は、誤って処理しないようにメッセージを拒否します。

59.6.1 構成のオンライン更新のための前提知識

この項では、実行中のService Busシステムで構成を更新するときに従うガイドラインと注意する必要のある制約について説明します。

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

- セキュリティ関連の構成を最初に更新してから、システム内のService Busリソースを更新します。セキュリティ構成変更は、特にアクティブ化のため、Service Busに表示される前にWebLogicサーバー・レベルで変更しておく必要があります。たとえば、SSLを使用するためにプロキシ・サービスを有効にするには、SSL関連のオプションをドメイン・レベルで構成する必要があります(SSLポートの有効化、ドメインの識別および信頼など)。セキュリティ・リソースの更新の詳細は、『Oracle WebLogic Serverセキュリティの管理』のセキュリティ管理の概要に関する項を参照してください。

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

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

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

59.6.2 オンライン・ビジネス・サービスの変更

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

Oracle Service Busコンソールを使用したビジネス・サービスのエンドポイントURIの変更については、「ビジネス・サービスのトランスポートの構成方法」を参照してください。

59.6.3 オンライン・プロキシ・サービスの変更

プロキシ・サービスを定義する大部分のメタデータは、新しい環境にデプロイする際に変更する必要はありませんが、次の情報の更新が必要になることがあります。たとえば、ファイル、FTPおよび電子メール・メッセージのタイプを持つプロキシ・サービスの定義では、クラスタでのポーリング実行時コンポーネントのデプロイメント用に単一の管理対象サーバーを指定する必要があります。

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

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

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

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

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

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

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

59.6.4 オンライン・パイプラインの変更

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

59.7 クラスタでのオンライン構成の更新

クラスタでService Busコンポーネントを更新する場合は、非クラスタ環境について考慮する必要もあります。オンライン更新の実行については、「オンライン構成の更新」を参照してください。

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

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

ビジネス・サービスの変更方法については、「オンライン・ビジネス・サービスの変更」を参照してください。

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

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

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

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

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

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

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

後方互換性とインストール方針の詳細は、「オンライン・プロキシ・サービスの変更」を参照してください。

60 Oracle Service Bus開発Mavenプラグインの使用

この章では、Oracle Service Bus開発Mavenプラグインを使用してService Busプロジェクトを構築および管理する方法を説明します。Oracle Service Bus開発Mavenプラグインでは、Maven環境でのService Busプロジェクトのパッケージ化とデプロイが行えます。

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

- Oracle Service Bus Mavenプラグインの概要

- Mavenのインストールと構成

- Oracle Service Bus開発Mavenプラグインの使用

- Service Bus開発Mavenプラグインのゴール

- Oracle Service Bus開発MavenプラグインPOMファイルのサンプル

Oracle Fusion MiddlewareでのMavenの使用方法の詳細は、『Oracle Fusion Middleware継続的インテグレーションによるアプリケーションの開発』を参照してください。アプリケーションとプロジェクトを構築するためのMavenのインストールと使用方法の詳細は、http://maven.apache.org/users/index.htmlを参照してください。

60.1 Oracle Service Bus Mavenプラグインの概要

Mavenは、ランタイム・プロジェクトを作成および管理するビルド自動化ツールです。Oracle Service Bus開発Mavenプラグインでは、Service Busプロジェクトおよびアプリケーションの要件に固有のMavenゴールを提供します。これを使用して、Service Busプロジェクトやリソースをパッケージ化したり、そのパッケージを実行中のサーバーにデプロイするなどのタスクを実行できます。

60.1.1 Mavenライフサイクルのフェーズとゴール

ライフサイクル・フェーズは、Maven POMファイルにゴール実行の順序付けを行います。ゴールは固有のタスクで、1つ以上のフェーズにマップできます。Oracle Service Bus開発Mavenプラグインは、ライフサイクル・フェーズを通してService Busプロジェクトおよびアプリケーションを構築および管理するための、Service Busプロジェクト固有の標準Mavenゴールと組み合せて使用できるゴールを提供します。

Service Busはpackageおよびdeployの2つのカスタム・ゴールを提供します。これらのゴールの構文およびパラメータの詳細は、「Service Bus開発Mavenプラグインのゴール」を参照してください。表60-1には、Service BusのデフォルトMavenライフサイクルのフェーズおよび各フェーズにマッピングされるゴールを示します。同じライフサイクル・フェーズに複数のゴールをマップした場合は、通常、リストした順序で実行されます。

表60-1 Service BusのMavenライフサイクルのフェーズ

フェーズ

説明

package

Service Busプロジェクト・リソースを配布可能な形式のsbar (Service Busアーカイブ・ファイル)でパッケージ化します。com.oracle.servicebus.plugin:oracle-servicebus-plugin:12.1.3.0.0:packageゴールはこのフェーズにマップされます。

pre-integration-test

パッケージを処理して、必要に応じて統合テストを実行できる環境にデプロイします。com.oracle.servicebus.plugin:oracle-servicebus-plugin:12.1.3.0.0:deployゴールはこのフェーズにマップされます。

install

ローカルで他のプロジェクトにおける依存関係として使用するために、パッケージをローカル・リポジトリにインストールします。Service Busはこのフェーズにorg.apache.maven.plugins:maven-install-plugin:installゴールを使用します。

60.1.2 POMファイルおよびArchetype

MavenプロジェクトはPOMファイルによって定義され、プロジェクトのアーティファクト、使用するプラグイン、継承および他のアーティファクト(Service Busプロジェクトの構築に必要なシステム・リソースなど)の依存性について説明します。Archetypeは、特定のタイプのプロジェクトを作成するためのテンプレートです。Service Busは、Service Busプロジェクト向けとService Busシステム・リソース向けの2つの異なるArchetypeを提供します。

Service BusプロジェクトのArchetypeはcom.oracle.servicebus.archetype:oracle-servicebus-project:12.2.1-0-0という名前です。次のようなArchetypeで定義されます。

<groupId>com.oracle.servicebus.archetype</groupId>
<artifactId>oracle-servicebus-project</artifactId>
<version>12.2.1-0-0</version>
<name>Oracle Service Bus - Project Archetype</name>

Service Busシステム・リソースのArchetypeはcom.oracle.servicebus.archetype:oracle-servicebus-system:12.2.1-0-0という名前です。次のようなArchetypeで定義されます。

<groupId>com.oracle.servicebus.archetype</groupId>
<artifactId>oracle-servicebus-system</artifactId>
<version>12.2.1-0-0</version>
<name>Oracle Service Bus - System Resources Archetype</name>

60.2 Mavenのインストールと構成

Maven 3.2.5のディストリビューションは、Oracle Fusion Middlewareに付属しており、次の場所にあります。

Middleware_Home/Oracle_Home/oracle_common/modules/org.apache.maven_3.2.5

Oracle Fusion Middlewareに対するMavenのインストールおよび構成方法の詳細は、『Oracle Fusion Middleware継続的インテグレーションによるアプリケーションの開発』のビルドの自動化および依存性の管理のためのMavenのインストールおよび構成に関する項を参照してください。第5.1項「Mavenディストリビューションの設定」および第5.2項「Maven設定のカスタマイズ」の設定手順に従ってください。

Oracle Service Bus開発Mavenプラグインは、次の場所にインストールされます。

Service_Bus_Home/plugins/maven

60.2.1 Oracle Service Bus開発Mavenプラグインの構成方法

oracle-servicebus-pluginプラグインは、組込み済JARファイルとそれに付随するPOMファイルとして提供されます。Maven同期プラグインは、Oracleホームからローカルまたは共有Mavenリポジトリに移入するために使用します。これにはService Busプラグインが含まれます。同期プラグインのインストールと実行に関する詳細および全手順については、『継続的インテグレーションによるアプリケーションの開発』のMavenリポジトリ・マネージャの移入に関する項を参照してください。次のステップには、該当するガイドのより詳細なセクションへのリンクが含まれます。

Oracle Service Bus開発Mavenプラグインを構成するには:

1. ORACLE_HOME/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.2.1に移動します。

2. 次のコマンドを実行してMaven同期プラグインをインストールします。

mvn install:install-file -DpomFile=oracle-maven-sync-12.2.1.pom -Dfile=oracle-maven-sync-12.2.1.jar

その他のオプションについては、「Oracle Maven同期プラグインのインストール」を参照してください。

3. 次のコマンドを実行して、Oracle Service Bus開発Mavenプラグインを次のMavenリポジトリにシードします。

mvn com.oracle.maven:oracle-maven-sync:push -DoracleHome=ORACLE_HOME

ここでORACLE_HOMEは、Oracle Fusion Middlewareインストールのフルパスです。その他のオプションについては、「Oracle Maven同期プラグインの実行」を参照してください。

4. Maven help:describeゴールを使用して、プラグインのインストールが成功したかどうかを検証します。

mvn help:describe -DgroupId=com.oracle.servicebus.plugin
-DartifactId=oracle-servicebus-plugin -Dversion=12.2.1-0-0

次の情報で、Service Busプラグインのインストールを確認します。

Name: Oracle Service Bus - Plugin
Description: (no description available)
Group Id: com.oracle.servicebus.plugin
Artifact Id: oracle-servicebus-plugin
Version: 12.2.1-0-0
Goal Prefix: servicebus
This plugin has 2 goals:
servicebus:deploy
Description: (no description available)
servicebus:package
Description: (no description available)
For more information, run 'mvn help:describe [...] -Ddetail'

60.2.2 Mavenオンライン・ヘルプの使用方法

Mavenオンライン・ヘルプでは、ゴールとその関連コマンドのリストが提供されます。オンライン・ヘルプにアクセスするには、helpプラグインのdescribeゴールを使用します。たとえば、packageゴールのオンライン・ヘルプを取得するには、次のコマンドを入力します。

mvn help:describe -Ddetail -Dcmd=com.oracle.servicebus.plugin:oracle-servicebus-plugin:package

詳細は、Apacheヘルプ・プラグインdescribeゴールのドキュメントを参照してください。

60.3 Oracle Service Bus開発Mavenプラグインの使用

MavenプロジェクトのPOMファイルを介して、またはコマンド行から、Mavenゴールを起動します。推奨される方法は、Maven POMファイルの使用で、これは、Service BusプロジェクトおよびService Busアプリケーションの両方に向けて作成できます。

JDeveloperでのMavenの使用については、『Oracle JDeveloperによるアプリケーションの開発』のApache Mavenによるビルドおよび実行に関する項を参照してください。

60.3.1 Service BusプロジェクトのPOMファイルの生成方法

Service BuプロジェクトをJDeveloperで作成すると、そのプロジェクトのPOMファイルが自動的に作成されます。JDeveloperを使用して、Service BusプロジェクトのPOMファイルを手動で作成することもできます。

JDeveloperでService BusプロジェクトのPOMファイルを生成するには:

1. アプリケーション・ナビゲータで、プロジェクトを右クリックして「新規」をポイントし、「ギャラリから」を選択します。

2. 「新規ギャラリ」ダイアログの下の「一般」カテゴリで、「Maven」を選択します。

3. 「アイテム」の下で「プロジェクトのMaven POM」を選択して「OK」をクリックします。

4. POMファイルの名前とそのPOMファイルが配置されるディレクトリを入力します。

5. プロジェクトの一意のグループID、アーティファクトIDおよびバージョンを入力します。

これらの値は、<groupId>:<artifactId>:<version>の形式で完全修飾されたアーティファクト名です。

6. プロジェクトの説明を入力します。

7. 「パッケージ化」フィールドで「sbar」を選択します。

8. 要件に応じて、「このPOMをプロジェクトのデフォルトとして使用」を選択または選択解除します。

9. 「OK」をクリックします。

60.3.2 ArchetypeからService BusプロジェクトのPOMファイルを生成する方法

JDeveloperで、またはコマンド行から、Service BusプロジェクトのArchetypeからのプロジェクトのPOMファイルを生成できます。Archetypeは、Mavenプロジェクトを作成するためのテンプレートです。

60.3.2.1 JDeveloperでのArchetypeからのService BusプロジェクトのPOMファイルの作成

JDeveloperでArchetypeからのService BusプロジェクトのPOMファイルを生成するには:

1. アプリケーション・ナビゲータで、プロジェクトを右クリックして「新規」をポイントし、「ギャラリから」を選択します。

2. 「新規ギャラリ」ダイアログの下の「一般」カテゴリで、「Maven」を選択します。

3. 「アイテム」の下で「Archetypeからの生成」を選択して「OK」をクリックします。

「Archetypeからのプロジェクトの作成」ダイアログが表示されます。

4. プロジェクトの一意のグループID、アーティファクトIDおよびバージョンを入力します。

これらの値は、<groupId>:<artifactId>:<version>の形式で完全修飾されたアーティファクト名です。

このダイアログのプロパティの詳細は、オンライン・ヘルプおよび「POMファイルの生成のためのパラメータ」を参照してください。これらはarchetypeグループおよびアーティファクトIDではないことに注意してください。

5. デフォルトのパッケージ名、およびプロジェクトを格納するディレクトリを入力します。

6. 「Maven Archetype」フィールドで「参照」アイコンをクリックし、oracle-servicebus-project archetypeを見つけて選択します。

Archetypeの検索については、『Oracle JDeveloperによるアプリケーションの開発』のMavenプロジェクトを使用してMaven Archetypesを作成する方法に関する項を参照してください。

7. 完了したら、「Archetypeからのプロジェクトの作成」ダイアログの「終了」をクリックします。

60.3.2.2 コマンド行を使用したArchetypeからのService BusプロジェクトのPOMファイルの生成

コマンド行を使用してArchetypeからService BusプロジェクトのPOMファイルを生成するには:

1. POMファイルを作成するService Busプロジェクトのディレクトリから、次のコマンドを実行します。

mvn archetype:generate
-DarchetypeGroupId=com.oracle.servicebus.archetype
-DarchetypeArtifactId=oracle-servicebus-project
-DarchetypeVersion=12.2.1-0-0
-DarchetypeRepository=Repository_Home
-DgroupId=Group_ID
-DartifactId=Artifact_ID
-Dversion=1.0-SNAPSHOT

説明:

- Repository_Homeは、使用するMavenリポジトリへのパスです。パスを入力するかわりに、単純に「local」と入力することもできます。これにより、Mavenが他のリポジトリを検索しなくなるため、より効率的になります。

- Group_IDは、構築するプロジェクトの一意の識別名です。

- Artifact_IDは、プロジェクトのアーティファクトが生成される、現在のディレクトリ内のサブディレクトリの名前です。

このコマンドのパラメータの詳細は、「POMファイルの生成のためのパラメータ」を参照してください。

2. コマンド行でプロパティ構成の確認を求められたら、Yを入力して確定するかNを入力して取り消します。[Enter]キーを押します。

コマンドを実行したディレクトリのアーティファクトIDで指定されたサブディレクトリに、POMファイルが生成されます。

60.3.3 ArchetypeからService Busシステム・リソースのPOMファイルを生成する方法

JDeveloperで、またはコマンド行から、Service BusシステムのArchetypeからのService Busシステム・リソースのPOMファイルを生成できます。Archetypeは、Mavenプロジェクトを作成するためのテンプレートです。

60.3.3.1 JDeveloperでのArchetypeからのService Busシステム・リソースのPOMファイルの生成

JDeveloperでArchetypeからのService Busシステム・リソースのPOMファイルを生成するには:

1. アプリケーション・ナビゲータで、システム・リソースが含まれるプロジェクトを右クリックして「新規」をポイントし、「ギャラリから」を選択します。

注意:

Service Busシステム・リソースでは、JDeveloperでの場所が「アプリケーション・リソース」の「Service Busシステム・リソース」になる場合があります。

2. 「新規ギャラリ」ダイアログの下の「一般」カテゴリで、「Maven」を選択します。

3. 「アイテム」の下で「Archetypeからの生成」を選択して「OK」をクリックします。

「Archetypeからのプロジェクトの作成」ダイアログが表示されます。

4. プロジェクトの一意のグループID、アーティファクトIDおよびバージョンを入力します。

これらの値は、<groupId>:<artifactId>:<version>の形式で完全修飾されたアーティファクト名です。

このダイアログのプロパティの詳細は、オンライン・ヘルプおよび「POMファイルの生成のためのパラメータ」を参照してください。これらはarchetypeグループおよびアーティファクトIDではないことに注意してください。

5. デフォルトのパッケージ名、およびプロジェクトを格納するディレクトリを入力します。

6. 「Maven Archetype」フィールドで「参照」アイコンをクリックし、oracle-servicebus-system archetypeを見つけて選択します。

Archetypeの検索については、『Oracle JDeveloperによるアプリケーションの開発』のMavenプロジェクトを使用してMaven Archetypesを作成する方法に関する項を参照してください。

7. 完了したら、「Archetypeからのプロジェクトの作成」ダイアログの「終了」をクリックします。

60.3.3.2 コマンド行からのService Busシステム・リソースのPOMファイルの生成

コマンド行からService Busシステム・リソースのPOMファイルを生成するには:

1. Service Busシステム・リソースが存在するディレクトリから、次のコマンドを実行します。

mvn archetype:generate
-DarchetypeGroupId=com.oracle.servicebus.archetype
-DarchetypeArtifactId=oracle-servicebus-system
-DarchetypeVersion=12.2.1-0-0
-DarchetypeRepository=Repository_Home
-DgroupId=Group_ID
-DartifactId=Artifact_ID
-Dversion=1.0-SNAPSHOT

説明:

- Repository_Homeは、使用するMavenリポジトリへのパスです。パスを入力するかわりに、単純に「local」と入力することもできます。これにより、Mavenが他のリポジトリを検索しなくなるため、より効率的になります。

- Group_IDは、構築するプロジェクトの一意の識別名です。

- Artifact_IDは、プロジェクトのアーティファクトが生成される、現在のディレクトリ内のサブディレクトリの名前です。

これらのパラメータの詳細は、「POMファイルの生成のためのパラメータ」を参照してください。

2. コマンド行でプロパティ構成の確認を求められたら、Yを入力して確定するかNを入力して取り消します。[Enter]キーを押します。

コマンドを実行したディレクトリのアーティファクトIDで指定されたサブディレクトリに、POMファイルが生成されます。

60.3.4 POMファイルの生成のためのパラメータ

コマンド行からPOMファイルを生成する場合、次のパラメータを使用してプロジェクトを構成します。

パラメータ

説明

archetypeGroupId

使用するArchetypeのグループID。Service Busの場合はcom.oracle.servicebus.archetype。

archetypeArtifactId

使用するArchetypeのアーティファクトID。Service Busプロジェクトの場合はoracle-servicebus-project。Service Busシステム・リソースの場合はoracle-servicebus-system。

archetypeVersion

使用するArchetypeのバージョン。現行バージョンは12.2.1-0-0。

archetypeRepository

使用するMavenリポジトリ。

groupId

構築するプロジェクトのグループID。

artifactId

構築するプロジェクトのアーティファクトID。

version

構築するプロジェクトのバージョン

60.4 Service Bus開発Mavenプラグインのゴール

Oracle Service Bus開発Mavenプラグインでは、次の項で説明するService Bus固有の2つのゴールを提供します。

- package: Service Busプロジェクト・リソースを配布可能な形式のsbar (Service Busアーカイブ・ファイル)でパッケージ化します。

- deploy: Service Busプロジェクトおよびアプリケーションを実行中のサーバーにデプロイします。このゴールは、SBAR形式のファイルをサポートします。

60.4.1 パッケージ

完全な名前

com.oracle.servicebus.plugin:oracle-servicebus-plugin:package

説明

packageゴールは、POMファイルに関連付けられたリソースから構成JARファイルを作成し、そのリソースを.sbarファイルと呼ばれるService Bus固有のアーカイブ・ファイルにパッケージ化します。デフォルトでMavenプラグインは、パッケージ化されるリソースはプロジェクト・リソースであることを前提としていますが、Service Busアプリケーションにはプロジェクト間で共有されているシステム・リソースも含めることができます。システム・リソースはプロジェクト・リソースとは異なる方法でパッケージ化されるため、システム・リソースをパッケージ化する場合は、systemフラグをtrueに設定する必要があります。

Mavenプラグインはオフライン・エクスポート(構成JAR)ツールを使用してService Busリソースをパッケージ化します。エクスポート・ツールによって作成された一時ファイルは、project/.data/maven/configjarに置かれます。エクスポート・ツールの設定は、Mavenプロジェクト・コンテキストから導出されます。プロジェクト・リソースをパッケージ化する場合、Service Busはプロジェクト・レベルでエクスポートを実行します。システム・リソースをパッケージ化する場合、Service Busはリソース・レベルでエクスポートを実行します。デフォルトの拡張子マッピングが使用されます。詳細は、「Service Bus構成のオフラインでのエクスポート」を参照してください。エクスポート・ツールはProject_Home/.maven/configjar/configjar.logにあるログ・ファイルに情報を書き込みます。

Service Busリソースを含むディレクトリには、多くの場合、生成済パッケージから除外したい追加のファイルが含まれています。たとえば、バージョニング・システムで使用するメタデータ・ファイルを除外できます。SBARファイルの生成時にこれらのファイルが含まれないように、除外リストを定義できます。デフォルトでは、servicebus.sboverview、pom.xml、.settings/および.data/のファイルおよびフォルダがプロジェクトのArchetypeから除外されます。システムのArchetypeの場合、pom.xmlおよび.data/が除外されます。

パッケージング中に発生する検証エラーは報告されず、検証エラーが発生しても、パッケージ化は失敗しません。

パラメータ

パッケージ処理をカスタマイズするには、次のパラメータを使用します。

表60-2 servicebus:packageゴールのパラメータ

名前

タイプ

説明

oracleHome

java.lang.String

Oracle Fusion Middlewareホーム・ディレクトリの場所を指定します。この値は、式として指定できます。

system

java.lang.Boolean

パッケージング化されるリソースが、Service Busアプリケーション内で複数のプロジェクトに共有されているシステム・リソースかどうかを指定します。デフォルト値はfalseです。システム・リソースをパッケージ化する場合は、この値をtrueに設定する必要があります。

excludes

String[]

プロジェクトから除外するファイルのリストを指定します。バージョニング・システムのファイルなどを除外する場合に使用します。

60.4.2 デプロイ

完全な名前

com.oracle.servicebus.plugin:oracle-servicebus-plugin:deploy

説明

deployゴールは、Service Busプロジェクトを、実行中のサーバーにデプロイします。このゴールは、Service Busデプロイメント形式のSBARをサポートします。これは、ローカル・サーバー・インストールを必要としません。デフォルトでは、プロジェクトをデプロイしても、環境値に更新は適用されません。環境値を更新する場合は、新しい環境値を持つ構成ファイルを作成し、deployの実行時にその構成ファイルを指定できます。

各デプロイメントで、新しいセッションが作成され、次の形式で名前が付けられます。

Service_Bus_Maven-artifactId-currentTime

現在の時刻は、ミリ秒単位まで設定されます。

Service BusプロジェクトをMavenを使用してパッケージ化すると、Service Busによって構成JARファイルが生成され、これは、deployゴールを使用して実行中のサーバーにデプロイできます。Service Busではデフォルトのインポート・プランを使用しますが、これには依存関係が含まれ、環境変数、セキュリティ設定または資格証明は保持されません。

リソースのインポートに失敗すると、情報がログに記録され、ゴールの実行は失敗します。すべてのリソースのインポートに成功し、構成ファイルを指定した場合、Service Busは新しい環境変数を適用します。デプロイメントが正常に完了すると(つまり、リソースで競合が一切ない場合)、Service Busによってセッションがアクティブ化されます。失敗や競合があった場合、Service Busは変更のアクティブ化や新しい環境変数の適用を行いませんが、セッションは保持されるため、失敗を調査できます。

パラメータ

デプロイメント処理をカスタマイズするには、次のパラメータを使用します。式を使用して、任意のパラメータを指定できます。

表60-3 servicebus:deployゴールのパラメータ

名前

タイプ

説明

oracleServerUrl

java.lang.String

管理サーバーがリスニングするアドレスとポートを指定します。

デフォルト値: t3://localhost:7001

oracleUsername

java.lang.String

管理ユーザー名を指定します。

oraclePassword

java.lang.String

管理パスワードを指定します。

customization

java.io.File

Service Busアーカイブをデプロイしている環境の環境値を更新する、Service Bus構成ファイルの場所および名前を指定します。

60.5 Oracle Service Bus開発MavenプラグインPOMファイルのサンプル

Service Busには、Service Busアプリケーション向け、Service Busプロジェクト向け、Service Busシステム・リソース向けの3つの異なるタイプのPOMファイルがあります。どれを使用するかは、操作しているリソースによって異なります。

例 - Service BusアプリケーションのPOMファイル

Service BusアプリケーションのPOMファイルの例を次に示します。これは、個別のプロジェクトPOMファイルではなく、単一のPOMファイルに対するMavenの実行が可能となる、アプリケーションでコンパイルするすべてのプロジェクトをリストした集約ファイルです。Mavenは、アプリケーションPOMファイルにリストされた順序で、モジュールを実行します。

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd"
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>

<groupId>OrdersAndPayments</groupId>
<artifactId>OrdersAndPayments</artifactId>
<version>1.0-SNAPSHOT</version>

<packaging>pom</packaging>

<modules>
<module>System</module>
<module>Orders</module>
<module>Payments</module>
</modules>

</project>

例 - Service BusプロジェクトのPOMファイル

Service BusプロジェクトのPOMファイルの例を次に示します。このファイルは、Mavenリポジトリの親POM project-12.2.1から継承します。継承によって、プロジェクトのPOMファイルはさらに合理化されます。

Systemは、Service Busでシステム・リソースのために予約されたプロジェクト名です。これは、プロジェクトArchetypeを使用するときにアーティファクトIDとして使用しないでください。

<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd"
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>

<parent>
<groupId>com.oracle.servicebus</groupId>
<artifactId>project</artifactId>
<version>12.2.1.0.0</version>
</parent>

<groupId>OrdersAndPayments</groupId>
<artifactId>Orders</artifactId>
<version>1.0-SNAPSHOT</version>

<packaging>sbar</packaging>

<dependencies>
<dependency>
<groupId>OrdersAndPayments</groupId>
<artifactId>System</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>

</project>

例 - Service Busシステム・リソースのPOMファイル

Service Busシステム・リソースのPOMファイルの例を次に示します。このファイルは、Mavenリポジトリの親POM system-12.2.1から継承します。継承によって、システム・リソースのPOMファイルはさらに合理化されます。

Systemは、Service Busでシステム・リソースのために予約されたプロジェクト名です。システムArchetypeを使用するときは、アーティファクトIDをSystemにする必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd"
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>

<parent>
<groupId>com.oracle.servicebus</groupId>
<artifactId>system</artifactId>
<version>12.2.1.0.0</version>
</parent>

<groupId>OrdersAndPayments</groupId>
<artifactId>System</artifactId>
<version>1.0</version>

<packaging>sbar</packaging>

</project>

付録

この部では、様々な開発情報およびリファレンス資料を提供します。

この部は、次の付録で構成されています。

- メッセージ・コンテキスト

- XPath拡張関数

- Oracle Service Bus API

- トランスポートSDKのインタフェースおよびクラス

- トランスポートSDK UMLシーケンス・ダイアグラム

- XQuery-SQLマッピング・リファレンス

- ワーク・マネージャとスレッド

A メッセージ・コンテキスト

この付録では、Service Busメッセージ・コンテキスト・モデルとメッセージ・フローで使用する事前定義されたコンテキスト変数について説明します。

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

- メッセージ・コンテキスト・モデル

- 事前定義されたコンテキスト変数

- メッセージ関連の変数

- inbound変数およびoutbound変数

- operation変数

- フォルト変数

- コンテキスト変数の初期化

- コンテキスト変数に対する操作の実行

- ディスパッチするメッセージの作成

- メッセージ・コンテキスト・スキーマ

A.1 メッセージ・コンテキスト・モデル

Service Busメッセージ・コンテキストは、Service Busでメッセージがルーティングされるときに、メッセージ・コンテキストとメッセージに関する情報を保持する一連のプロパティです。これらのプロパティは、コンテキスト変数と呼ばれます。たとえば、サービス・エンドポイントは、事前定義されたコンテキスト変数によって表されます。Service Busは、ユーザー定義のコンテキスト変数もサポートします。

メッセージ・コンテキストは、XMLスキーマによって定義されます。通常は、XQuery式を使用して、パイプライン・サービスのコンテキスト変数を操作します。

A.2 事前定義されたコンテキスト変数

表A-1に、事前定義されたコンテキスト変数を示します。事前定義されたコンテキスト変数のタイプは、メッセージ関連の変数、inboundおよびoutbound変数、$operation変数、fault変数に分けられます。

注意:

メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。

メッセージ・コンテキスト変数の要素の型については、「メッセージ・コンテキスト・スキーマ」を参照してください。

表A-1 Service Busの事前定義されたコンテキスト変数

コンテキスト変数

説明

関連項目

header

SOAPメッセージの場合、$headerにはSOAPヘッダーが格納されます。パイプラインがSOAP 1.2の場合、$headerにはSOAP 1.2 Header要素が格納されます。

メッセージのタイプがSOAP以外の場合、$headerには空のSOAPヘッダー要素が格納されます。

メッセージ関連の変数

body

この変数は、次に説明するようにメッセージ・タイプに応じて異なります。

- SOAPメッセージ: SOAPエンベロープから抽出した<SOAP:Body>部。パイプラインがSOAP 1.2の場合、$body変数にはSOAP 1.2 Body要素が格納されます。

- バイナリ以外の非SOAPメッセージ: <SOAP:Body>要素でラップされたメッセージ・コンテンツ全体。

- バイナリ・メッセージ: <SOAP:Body>でラップされたバイナリ・メッセージのメモリー内コピーへの参照。

- Javaオブジェクト: <SOAP:Body>でラップされたJavaオブジェクトのメモリー内コピーへの参照。

メッセージ関連の変数

attachments

メッセージのMIME添付。

メッセージ関連の変数

inbound

インバウンド・トランスポート・ヘッダーとメッセージを受信したプロキシ・サービスについての情報。

inbound変数およびoutbound変数

outbound

アウトバウンド・トランスポート・ヘッダーとメッセージが送信されるターゲット・サービスについての情報。

inbound変数およびoutbound変数

operation

パイプラインで呼び出される操作

operation変数

fault

メッセージの処理中に発生したエラーに関する情報。

フォルト変数

messageId

トランスポート・プロバイダ固有のメッセージIDです。このIDは、Service Busランタイムを通過するその他のメッセージからメッセージを一意に識別できることが必要です。ただし、この値は一意である必要はありません。

messageID変数

A.3 メッセージ関連の変数

メッセージ関連の変数である$header、$bodyおよび$attachmentsは、Service Busのメッセージ・フローでのメッセージの標準書式を表します。これらの変数は、パイプラインが受信したメッセージ・コンテンツを使用して初期化され、他のサービスにルーティングまたはパブリッシュされる送信メッセージを作成するために使用されます。メッセージの処理の一部としてメッセージを変更するには、これらの変数を変更する必要があります。

メッセージ・ペイロード(つまり、ヘッダーや添付を除くメッセージ・コンテンツ)は、$body変数に格納されます。送信メッセージに含める変数のコンテンツは、Service Busからメッセージがディスパッチ(パブリッシュまたはルーティング)される時点で決定されます。この決定は、ターゲットのエンドポイントがSOAPメッセージを受信するか非SOAPメッセージを受信するかによって異なります。

- SOAPメッセージが要求される場合は、$header変数と$body変数がSOAPエンベロープで結合され、メッセージが作成されます。

- 非SOAPメッセージが要求される場合は、$body変数のBody要素のコンテンツによってメッセージ全体が構成されます。

- いずれの場合も、サービスが添付を受信するときは、生成されたメッセージと$attachments変数からMIMEパッケージが作成されます。

A.3.1 header変数

$header変数には、メッセージに関連付けられているSOAPヘッダーが格納されます。$header変数は、下位要素にヘッダーを含む<SOAP:Header>要素を参照します。プロキシ・サービスがSOAP 1.2の場合、$header変数にはSOAP 1.2 Header要素が格納されます。非SOAPメッセージまたはヘッダーがないSOAPメッセージの場合、<SOAP:Header>要素は空になり、下位要素を持ちません。

A.3.2 body変数

$body変数はコアのメッセージ・ペイロードを表し、常に<SOAP:Body>要素を参照します。プロキシ・サービスがSOAP 1.2の場合、$bodyにはSOAP 1.2 Body要素が格納されます。SOAPメッセージでも非SOAPメッセージでも、コアのペイロードは同じ変数とパッケージで使用できます。つまり、<SOAP:Body>要素でラップされます。

- SOAPメッセージの場合は、SOAP本文がエンベロープから抽出され、$body変数に割り当てられます。

- バイナリ以外の非SOAPメッセージの場合は、新しく作成された<SOAP:Body>要素内にメッセージ・コンテンツ全体が挿入されます。

- バイナリ・メッセージの場合は、メッセージ・コンテンツが$body変数に挿入されるのではなく、<binary-content/>参照要素が作成され、<SOAP:Body>要素に挿入されます。バイナリ・コンテンツの処理方法については、「body変数とattachments変数内のバイナリ・コンテンツ」を参照してください。

- Javaオブジェクトの場合は、<java-content/>参照要素が作成され、<SOAP:Body>要素に挿入されます。Javaコンテンツの処理方法については、「body変数内のJavaコンテンツ」を参照してください。

A.3.3 attachments変数

$attachments変数には、メッセージに関連付けられた添付が格納されます。attachments変数は、XMLスキーマで定義されます。これは、単一のルート・ノードである<ctx:attachments>と、各添付の<ctx:attachment>下位要素で構成されます。この下位要素には、添付に関する情報(MIMEヘッダーから派生)と、添付コンテンツおよび添付のカスタム・ヘッダーが含まれます。

他のメッセージ関連の変数と同様に、$attachmentsは常に設定されます。ただし、添付がない場合は、$attachments変数は空の<ctx:attachments>要素で構成されます。各添付の$attachments変数には、次のものが含まれます。

- 添付ファイル:添付ファイルがXMLの場合

- 参照XML :添付ファイルがバイナリの場合

- テキスト:添付ファイルがテキストの場合

注意:

メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。

各attachment要素には、表A-2に示す一連の下位要素が含まれます。

表A-2 attachments変数の下位要素

attachments変数の要素

説明

Content-ID

添付を識別するグローバルに一意の参照。型はstringです。

Content-Type

添付のメディアのタイプとサブタイプ。型はstringです。

Content-Transfer-Encoding

添付のエンコード方法のインジケータ。型はstringです。

Content-Description

コンテンツの説明。型はstringです。

Content-Location

添付を識別するローカルに一意のURIベースの参照。型はstringです。

Content-Disposition

受信者による添付の処理方法のインジケータ。型はstringです。

user-headers

添付のカスタムMIMEヘッダーのリスト。この要素には、各カスタム・ヘッダーを定義する1つ以上のuser-header要素が含まれます。

user-header

カスタムMIMEヘッダー。name属性にヘッダーの名前を、value属性にヘッダーの値を指定します。両方の属性の型はstringです。

body

添付データを保持します。型はanyTypeです。

型なしのbody要素を除き、すべてのその他の要素には、MIMEと同じ方法で解釈される文字列値が含まれます。たとえば、Content-Type要素の有効な値には、text/xmlおよびtext/xml; charset=utf-8が含まれます。

添付の解析は再帰的ではありません。添付のContent-Typeがmultipart/...の場合、body要素には元のアンパックのMIMEコンテンツがバイトのストリームとして保持され、添付の下位要素は含まれません。MIMEストリームにはバイナリ・データが含まれることがあり、その場合このストリームは<binary-content>参照要素で表します。バイナリ・コンテンツの処理方法については、「body変数とattachments変数内のバイナリ・コンテンツ」を参照してください。

Content-Typeがmultipart/form-dataであるメッセージは、実行時に次のように作成されます。

- インバウンド: 受信したインバウンドmultipart/form-dataタイプのメッセージのすべての部分が$attachments変数に割り当てられます。$body変数は空のままになります。

- アウトバウンド: アウトバウンドmultipart/form-dataタイプのメッセージのコンテンツが$attachments変数のコンテンツから作成されます。$headerまたは$bodyからは何も含まれません。

注意:

インバウンド・メッセージがmultipart/form-data以外のmultipartタイプ(multipart/relatedなど)で、アウトバウンド・メッセージがmultipart/form-dataの場合、インバウンド・ルート・パートのヘッダーとコンテンツを明示的に保持する必要があります。そうしないと、パススルーされません。

Service Busでは、EJB、TuxedoまたはDSPサービスへの添付ファイルの送信はサポートしていません。

A.3.4 メッセージ・タイプおよびコンテキスト変数

これらの変数は、SOAPヘッダー要素、SOAP本体要素、およびMIME添付を含むラッパー変数です。コンテキストによって、すべてのメッセージがSOAPメッセージであり、非SOAPメッセージがこのパラダイムにマップされるように見えます。次の表に、様々なメッセージ・タイプのマッピングを示します。Javaコンテンツの詳細は、「body変数内のJavaコンテンツ」を参照してください。

表A-3 メッセージのマッピング

メッセージ・タイプ

マッピング

XML

$bodyのBody要素にXMLドキュメントが含まれます。添付は$attachmentsに含まれます。

バイナリ

$bodyのBody要素に参照XMLドキュメントが含まれます。添付は$attachmentsに含まれます。

MFL

ドキュメントは、XMLとの相互変換が透過的に行われ、$bodyのBody要素ではXMLドキュメントとして表示されます。添付は$attachmentsに含まれます。

テキスト

$bodyのBody要素にテキストが含まれます。添付は$attachmentsに含まれます。

ファイル、FTPおよび電子メール

参照渡しドキュメントの場合、$bodyのBody要素に含まれる参照XMLドキュメントは、トランスポートによってファイル・システムに格納されたドキュメントのURIを参照します。添付は$attachmentsに含まれます。

SOAP

$bodyのBody要素にSOAP本体が含まれます。$headerのHeader要素にSOAPヘッダーが含まれます。添付は$attachmentsに含まれます。

A.3.5 body変数とattachments変数内のバイナリ・コンテンツ

$body変数と$attachments変数では、テキスト・ベース、XMLベースおよびMFLベースのコンテンツがXML要素内に直接挿入されます。バイナリ・データの場合、XMLで使用できないバイト値が含まれることがあるため、Service Busではバイナリ・コンテンツはXML要素内に挿入されません。したがって、バイナリ・コンテンツは操作できませんが効率的に処理されます。

バイナリ・コンテンツが受信されると、Service Busランタイムによってバイナリ・コンテンツがメモリー内ハッシュ表に格納され、そのコンテンツへの参照がXML (bodyまたはattachments)要素に挿入されます。この参照は、次のXMLスニペットで表されます。

<binary-content ref="..."/>

このref属性に、バイナリ・コンテンツを一意に識別するURIまたはURNを指定します。このXMLは、パイプライン・ペア、ブランチまたはルート・ノードで他のコンテンツと同様に操作できますが、影響を受けるのは、元のバイナリ・コンテンツではなく参照のみです。

次に例を示します。

- $body変数のバイナリ・コンテンツを添付にコピーするには、参照XMLを添付要素のbody下位要素にコピーします。

- 2つの異なる添付のバイナリ・コンテンツを置き換えるには、参照XMLスニペットまたはref属性の値を置き換えます。

メッセージがService Busからディスパッチされると、参照XMLのURIを使用して、関連バイナリ・コンテンツが送信メッセージ内に復元されます。アウトバウンド・メッセージの作成方法については、「ディスパッチするメッセージの作成」を参照してください。

クライアントと特定の転送(特に、電子メール、ファイル、FTP)では、この同じ参照XMLを使用して参照渡しを実装できます。この場合、実行時のプロキシ・サービスではなく転送またはクライアントによって、参照XMLが作成されます。また、ref属性内のURIの値は、参照XMLを作成するユーザーによって指定されます。参照XMLが実行時のプロキシ・サービスによって作成されない場合(特に、URIの参照先が、内部で管理されているバイナリ・コンテンツであると認識されない場合)、URIはService Busにより逆参照されず、送信メッセージにコンテンツが挿入されません。

A.3.5.1 ビジネス・プロセスへの添付付きSOAPの送信

Service BusからBPELビジネス・プロセスへ添付ファイル付きSOAP (SwA)を送信し、XPath関数ora:getAttachmentContent('inputVariable','bin','/bin')を使用してBPEL内の複数の添付を取得するには、必ず次の手順を実行してください。

- 複数の添付にContent-ID添付変数を設定します。

- href属性を使用して、プライマリSOAPエンベロープ内の添付を参照します。

場合によっては、cid:情報がhref属性にない場合があります。

次に、例を示します。

Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
start="<rootpart@example.com>"
Content-Description: This is the optional message description.
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <rootpart@example.com>

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body xmlns:types="http://example.com/mimetypes">
<m:SendClaim xmlns:m="http://example.com/mimewsdl“>
<ClaimDetail>
<Name>...</Name>
<!-- additional claim details -->
</ClaimDetail>
<ClaimPhoto href="cid:4d7a5fa2-14af-451c-961b5c3abf786796@example.com"/>
</m:SendClaim>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <4d7a5fa2-14af-451c-961b5c3abf786796@example.com>

...MIME attachment of binary photograph...
--MIME_boundary—

A.3.6 body変数内のJavaコンテンツ

Service Busパイプラインでは、Javaコールアウト・アクションへの入力および出力として、Javaオブジェクトをサポートしています。Javaコールアウトから返されたPOJOはパイプラインにキャッシュされ、そのキーは<java-content ref="cid:kkkkeeeeyyyy"/>の形式のXMLメッセージにラップされて返されます。ここで、cid:kkkkeeeeyyyyは、生成アクションによって自動的に生成されたキーであり、パイプラインのPOJOリポジトリにあるオブジェクトの索引を指定するために使用されます。後続するすべてのアクションに対して、このXMLが変更されずに引数として渡されます。

構成時にはPOJO変数のコンテンツは、パイプライン・アクションからは直接アクセスできません。かわりに、コンテンツは次の方法で操作できます。

- コンテンツのメタデータ(コンテンツのキー)は、他のXML(たとえば、$pojo/java-content/@refのようなXQuery)と同様に処理できます。これはロギングやデバッグに役立つことがありますが、オブジェクトのコンテンツに直接アクセスすることはできません。

- (パイプライン内で)自動的にPOJO型として指定される新しい変数にコンテンツを割り当てることができます。オブジェクト自体にアクセスすることはできません。XMLスニペット<java-content.../>がソース変数からターゲット変数にコピーされます。

- コンテンツは、別の適切なアクション(Javaコールアウトなど)に変数(たとえば、$pojo)として渡すことができます。オブジェクト自体にアクセスすることはできません。引数は、実際のオブジェクトに自動的に逆参照されます。

(<java-content />内に)Javaオブジェクトのキーを保持しているすべての変数を削除した場合、または<java-content />スニペットを指しているすべてのXPathを削除した場合、JavaオブジェクトはパイプラインのPOJOリポジトリから削除されます。

A.3.7 bodyコンテンツのストリーミング

メッセージ・コンテンツを処理する際に、パイプラインによってコンテンツをメモリーにロードするのではなく、コンテンツをストリームするように指定できます。パイプラインのコンテンツ・ストリーミングを有効にするときは、メッセージ処理時の中間手順として、ストリーミングされたコンテンツをメモリーとディスク・ファイルのどちらにバッファするかを指定します。これらの一時ファイルの作成は、パフォーマンスに影響を及ぼすことがあります。一時ファイルの保護については、『Oracle Service Busの管理』のbodyコンテンツをストリーミングする場合の一時ファイルの保護に関する項を参照してください。

ストリーミング・オプションを有効にした場合、コンテンツ・ストリーミングは$body変数のみに適用されます。

一般に、コンテンツ・ストリーミングを使用するのは次のような場合です。

- サイズの大きいコンテンツのメッセージを処理する場合。「コンテンツ・ストリーミングを使用する際のベスト・プラクティス」のガイドラインを参照してください。

- Service Busがペイロードにアクセスする回数が少ない場合。

- トランスフォーメーションのないコンテンツ・ベースのルーティングの場合。コンテンツ・ストリーミングを使用すると、部分解析の利点が得られるため、パフォーマンスが向上します。

A.3.7.1 コンテンツ・ストリーミングを使用する際のベスト・プラクティス

コンテンツのストリーミングを有効にするには、次のガイドラインと推奨事項に従ってください。

- サイズの大きいメッセージを処理するためにストリーミングを有効にした場合、$bodyメッセージ・コンテキスト変数について、挿入、置換、名前変更、for each、検証、および削除の各アクションを使用することはできません。これらのアクションでは、入力変数をメモリー内で完全に実体化する必要がありますが、完全な実体化はコンテンツ・ストリーミング・オプションと互換性がないためです。

- 次のパイプライン・アクションでは、サイズの大きい$bodyのXQuery変換またはXSL変換の結果を使用できます。

- 割当て、挿入および置換の各アクション: この結果を使用して、別のコンテキスト変数($body以外)の値を更新します。ただし、式の結果が完全に実体化でき、メッセージ・コンテキストに格納できる小さなサイズであることを確認する必要があります。

- Javaコールアウト: この結果を使用して、入力引数を渡します。Javaコールアウトへのすべての入力は完全に実体化されます。したがって、入力として使用する式の結果は、完全に実体化できる小さなサイズであることが必要です。

- MFL変換: この結果を使用して、入力をXML Beanとしてあらかじめ実体化せずに、サイズの大きいペイロードを変換します。MFL変換への入力としてサイズの大きい$bodyを使用する場合は、メッセージ・サービスをバイナリ・メッセージ・タイプのパイプラインとして宣言します。メッセージ・サービスをテキスト・メッセージ・タイプのパイプラインとして宣言すると、変換の入力ストリームを取得するために$bodyが完全に実体化されます。

- アラート、ログおよびレポートの各アクション: この結果を使用して、サイズの大きい$bodyのXQuery変換またはXSL変換の結果を報告します。

- サービス・コールアウト

- XSLトランスフォーメーションでは、トランスフォーメーションを実行するためにすべての入力が完全に実体化されます。したがって、入力が完全に実体化でき、XSLTプロセッサが処理できる小さなサイズであることを確認する必要があります。

- サイズの大きいMFL入力を使用する場合、MFLステージ・アクションではなく、MFLサービスを使用してMFLからXMLへの変換を実行する必要があります。

- コンテンツが完全に実体化されると、メモリー不足による例外が発生する可能性があり、コンテンツを表示することによって、テスト・コンソール・ウィンドウの処理速度が低下するので、テスト・コンソールを使用して、サイズの大きいコンテンツのメッセージでパイプラインをテストしないでください。

- XQueryを作成するときは、適切な索引を使用して部分解析を実行できるようにします。
たとえば、入力ストリーム全体を使用する$body/*:DateTimeStructを使用するのではなく、次のいずれかを使用します。

($body/*:DateTimeStruct)[1]

または

$body[1]/*:DateTimeStruct[1]

索引を使用することにより、1つ目のDateTimeStruct要素までのコンテンツのみが解析されます。

- 複数のコンシューマ(式)がアクセスする各変数が実体化されるため、XQueryを作成するときに、次のような文を記述しないようにしてください。

let $labdata1 := $body/*
return <HEADER>{ $labdata1/HEADER/@*, $labdata1/HEADER/node() }</HEADER>

この場合、$labdata1はルート要素なしにドキュメント全体にバインドされるため、XQueryエンジンがこれを実体化しようとするとメモリー不足になります。

この問合せを変更して必要以上に実体化されないようにする1つの方法として、/HEADERパス式をlet句内に移動します。

let $labdata1 := $body/*/HEADER
...

この場合、XQueryエンジンはHEADER要素のみを実体化します。

- 実行時に、サイズの大きいメッセージの処理は、基になるトランスポートの制限と制約を受けます(メッセージ・サイズの処理の制限など)。サイズの大きいメッセージを受け入れるトランスポートの容量を制限するJVMおよびRMIの設定に注意してください。

A.3.8 添付ファイルのストリーミング

メッセージの添付ファイルを処理する際に、添付ファイルをメモリーにバッファリングしてXMLとして解析するのではなく、MIME添付ファイルをディスクにページングしてからコンテンツをストリーミングするように指定できます。サイズの大きい添付ファイルを扱う場合は、この方法が特に効果的です。この方法を使用すると、ヘッダーのみがバッファリングされ、残りのメッセージ・ペイロードは、小さい複数の部分を同時に読み込むことができるストリームとして公開されます。ストリーミングされた転送により、サイズの大きいメモリー・バッファが不要になるため、サービスのスケーラビリティが向上します。

注意:

Service Busは、電子メールまたはWSトランスポートの添付ファイルのストリーミングをサポートしません。

パイプラインに対して有効になっている場合、設定はインバウンド・リクエスト・メッセージの処理に適用されます。HTTPビジネス・サービスの場合、設定はアウトバウンド・レスポンス・メッセージの処理に適用されます。アウトバウンド・リクエスト・メッセージをディスパッチすることができる次のアクションは、添付ファイルのストリーミングをサポートします。

- ルート、動的ルーティング、およびルート表

- パブリッシュ、動的パブリッシュ、およびパブリッシュ表

ストリーミングが有効な場合、バイナリ、テキストおよびXMLを含むすべての添付ファイルが不透明なデータとして処理されます。つまり、添付ファイルのXMLコンテンツに基づいてXQuery式またはXPath式を実行することはできません。

A.3.8.1 インバウンド・メッセージの処理

Service Busがインバウンド・メッセージを受信したとき、添付ファイルのストリーミングが構成されている場合は、各MIME添付ファイルのコンテンツはディスク上の別々のファイルに保存されます。各添付ファイルの標準MIMEヘッダー(これには、Content-ID、Content-Type、Content-Transfer-Encoding、Content-Description、Content-Location、およびContent-Disposition(指定されている場合)が含まれます)をattachment要素の下に追加するように、$attachments変数の値が設定されます。

body子要素には、ソース・リポジトリ内の対応するソースを参照する単一のbinary-content子要素が含まれます。

たとえば、$attachments変数は次のようになります。

<con:attachments xmlns:con="http://www.oracle.com/wli/sb/context">
<con:attachment>
<con:Content-Type>image/jpeg</con:Content-Type>
<con:Content-ID>
&lt;1.urn:uuid:BFB7D745CBAF21BA5B12023554608963@apache.org>
</con:Content-ID>
<con:Content-Transfer-Encoding>
binary
</con:Content-Transfer-Encoding>
<con:body>
<con:binary-content ref="cid:23976580:1183dd6aab9:-7fe0"/>
</con:body>
</con:attachment>
</con:attachments>

これは添付ファイルのコンテンツ・タイプに関係なく実行されます。つまり、たとえばtext/xml添付ファイルは、image/jpeg添付ファイルと同じように、バイナリ・コンテンツ要素を含む不透明なバイナリ・データとして扱われます。

このスタイルのメッセージ処理は、添付ファイルがストリーミングされない場合とは異なります。添付ファイルがストリーミングされない場合は、text/xmlやtext/plainなどの特定のファイル・タイプが認識されて、添付ファイルのXML body要素(XMLコンテンツを格納するため)またはテキスト・コンテンツの初期化に使用されます。

A.3.8.2 アウトバウンド・レスポンス・メッセージの処理

Service Busがアウトバウンド・メッセージを処理するとき、添付ファイルをストリーミングするように構成されている場合は、各MIME添付ファイルのコンテンツはディスク上の別々のファイルに保存されます。Service Busは、インバウンド・リクエストの場合と同様に$attachmentsメッセージ・コンテキスト変数を初期化します(「インバウンド・メッセージの処理」を参照してください)。

A.3.9 XOP/MTOMサポート

Service Busでは、XOP/MTOM形式のインバウンド・メッセージをデコードして解析し、必要に応じてXOP/MTOM形式を使用してレスポンスを送信するように、パイプラインを構成できます。また、アウトバウンド・メッセージをXOP/MTOM形式でエンコードするようにビジネス・サービスを構成できます。

Service Busは、着信XOP/MTOMペイロードを受け入れてデコードするために、次のバインディング・タイプを持つパイプラインをサポートしています。

- 任意のXML

- メッセージング(XML)

- 任意のSOAP

- WSDLベース

XOP/MTOMペイロードを受信するその他のサービス・バインディング・タイプのパイプラインは、MIMEマルチ・パート・リクエストと同じようにペイロードを処理し、MTOM固有の処理は行いません。

また、次のService BusトランスポートはXOP/MTOMをサポートします。

- HTTP/S

- ローカル

- SB (連鎖しているService Busドメインなど、適用可能な場合)

Service Busは、次のアウトバウンド・メッセージをディスパッチできるすべての既存アクションをサポートします。

- ルート、動的ルーティング、およびルート表

- パブリッシュ、動的パブリッシュ、およびパブリッシュ表

- サービス・コールアウト

Service Busでは、MTOMおよび添付ファイル付きのSOAP (SwA)の組合せはサポートされません。

A.3.9.1 パイプラインのXOP/MTOM

パイプラインでXOP/MTOM形式のインバウンド・メッセージをデコードして解析し、必要に応じてXOP/MTOM形式を使用してレスポンスを送信できます。「XOP/MTOMサポート」が有効になっている場合は、$bodyメッセージ・コンテキスト変数のバイナリ・データを処理する方法を次のオプションからさらに選択します。

- 「参照によるバイナリ・データを含む」(デフォルト): 「参照によるバイナリ・オプション」を参照してください。

- 「値によるバイナリ・データを含む」: 「値によるバイナリ・オプション」を参照してください。

「XOP/MTOMサポート」がパイプラインに対して有効になっている場合は、すべてのインバウンド・メッセージがMTOM形式である必要はありません。かわりに、この設定では、MTOM形式のメッセージが到着したときに、パイプラインでそれを適宜処理する必要があることを指定します。「XOP/MTOMサポート」が有効になっていないパイプラインがMTOM形式のメッセージを受信すると、サービスはメッセージを拒否して実行時エラーを発行します。

A.3.9.1.1 参照によるバイナリ・オプション

バイナリ・データに直接アクセスする必要がある場合、たとえばJavaコールアウトまたはMessage Format Language (MFL)変換にデータを渡す場合は、「参照によるバイナリ・データを含む」を使用します。

参照によるバイナリ・オプションが選択されている場合は、Service Busはインバウンド・メッセージのルートを解析してxop:Includeタグの存在をチェックします。これらのタグが検出された場合、タグはバイナリ・リポジトリ内の対応するソースへの参照を含むctx:binary-content要素に変換されます。結果としてのドキュメントは$bodyメッセージ・コンテキスト変数によって表されます。対照的に、$attachmentsメッセージ・コンテキスト変数は情報を含みません(nullです)。

つまり、パイプライン・アクションが$bodyメッセージ・コンテキスト変数のコンテンツにアクセスした場合、アクションはxop:Include要素を検出しないかわりに、ctx:binary-content要素を使用して動作します。

パイプラインがレスポンスを返信する必要がある場合、バインディング・レイヤーはctx:binary-content参照をメッセージのルートにあるxop:Includeタグに置換し、対応する各バイナリ・コンテンツ参照に別々のMIME部分を追加して、XOP/MTOMパッケージ・レスポンスを作成します。

A.3.9.1.2 値によるバイナリ・オプション

「値によるバイナリ・データを含む」は次の場合に使用します。

- MTOMとMTOM以外のサービスの間にブリッジを作成する場合。たとえば、MTOM対応でないサービスにルーティングされるリクエストを受信するMTOM対応のパイプラインについて考えます。このオプションを使用して、XML内のバイナリ・データをBase64エンコード形式で送信するために既存の標準に準拠できます。

- バイナリ・データの代わりにbase64binary要素の使用を必要とするXMLスキーマに照らしてメッセージのコンテンツを検証する場合。

「値によるバイナリ・データを含む」オプションが選択されている場合は、Service BusがインバウンドMIMEメッセージのルートを解析してxop:Includeタグの有無をチェックします。該当するタグが検出された場合、対応するMIME部分の本体(バイナリ・データ)はBase64でエンコードされ、結果としてのテキストが$bodyメッセージ・コンテキスト変数のxop:Includeタグを置換します。

対照的に、$attachmentsメッセージ・コンテキスト変数は情報を含みません(nullです)。

A.3.9.2 ビジネス・サービスのXOP/MTOM

ビジネス・サービスを有効にすると、アウトバウンド・メッセージをXOP/MTOM形式でエンコードできます。「XOP/MTOMサポート」が有効になっている場合は、$headerおよび$bodyメッセージ・コンテキスト変数のバイナリ・データを処理する方法を次のオプションからさらに選択します。

- 参照によるバイナリ・データを含む: (デフォルト)アウトバウンド・レスポンス・メッセージでの$bodyメッセージ・コンテキスト変数の設定時に、xop:Include要素をctx:binary-content要素に置換します。

- 値によるバイナリ・データを含む: アウトバウンド・レスポンス・メッセージで、$bodyメッセージ・コンテキスト変数の設定時にxop:Include要素を対応するバイナリ・データのBase64エンコード・テキスト・バージョンで置換します。

「XOP/MTOMサポート」がビジネス・サービスに対して有効になっている場合は、すべてのアウトバウンド・メッセージがMTOM形式である必要はありません。かわりに、この設定はビジネス・サービスがMTOMペイロードを処理できることを指定します。

A.3.9.2.1 アウトバウンド・メッセージのXOP/MTOM

ビジネス・サービスで「XOP/MTOMサポート」が有効になっている場合、Service Busは$bodyメッセージ・コンテキスト変数のコンテンツを調べてctx:binary-content要素を検索します。要素がある場合、Service Busはctx:binary-contentをxop:Include要素およびペイロードの対応するMIME部分に置換して、XOP/MTOM MIMEパッケージを作成します。

XOP/MTOMが有効で本体にバイナリ・コンテンツが含まれている場合、コンテンツのサイズに関係なく(たとえば、1KBより小さい場合でも) Service Busは常にXOP/MTOMを使用します。Service BusはMTOMとSwAの組合せをサポートしないため、ビジネス・サービスへのアウトバウンド・リクエストをディスパッチする必要があり、次の条件に該当する場合、システムはランタイム例外をスローします。

- ビジネス・サービスのXOP/MTOMが有効になっています。

- $attachmentsメッセージ・コンテキスト変数がnullではありません。

A.3.9.3 XOP/MTOM添付ファイルのストリーミング

サービスでXOP/MTOMが有効になっている場合、前の説明に示すように、Service Busはメッセージの$headerと$body内の要素を自動的に変更します。XOP/MTOMメッセージを変更する必要があるため、Service Busはメッセージ$headerとメッセージ$bodyのストリーミングをサポートしません。

ただし、添付ファイルが大きいためにメモリー不足のエラーを発生させるような場合、XOP/MTOMメッセージのバイナリ添付ファイルを、Service Busヒープ(デフォルト)ではなく、ディスクに直接ストリーミングする必要があります。

注意:

XOP/MTOM添付ファイルは、メッセージの$attachments変数では送信されません。前述のとおり、それらはメッセージ$body内に含まれるかまたは$bodyメッセージから参照されます。

XOP/MTOMメッセージの添付ファイルを直接ディスクにストリーミングするには、サービス構成で次の設定を使用します。

- XOP/MTOMの「参照によるバイナリ・データを含む」オプションを使用します。このオプションでは、$body内にバイナリ・データが直接含まれ、XOP/MTOMのサポートにはストリーミングできません。

- 「参照によるバイナリ・データを含む」が選択されている場合は、「添付ファイルのディスクへのページング」オプション(HTTPトランスポートのみ)も選択できます。「添付ファイルのディスクへのページング」が選択されている場合は、Service Busはメモリーではなくディスク上のバイナリ添付ファイルを参照するXOP/MTOMメッセージを生成します。

注意:

最適なパフォーマンスを得るためにはメモリー内の添付ファイルを参照する方法が推奨されるので、メモリー不足のエラーを発生させるようなサイズの大きい添付ファイルを送信する特別な必要性がある場合のみ「添付ファイルのディスクへのページング」オプションを使用します。

A.3.10 カスタムMIMEヘッダー

Service Busは、インバウンド・リクエスト/アウトバウンド・レスポンスおよびアウトバウンド・リクエスト/インバウンド・レスポンスのメッセージ・パターンの両方のカスタムMIMEヘッダーをサポートしています。インバウンド・メッセージにカスタム・ヘッダーが含まれ、メッセージがパイプラインに読み込まれると、次の例に示すようにカスタム・ヘッダー情報がXMLのuser-headers要素に表示されます。

<con:user-headers>
<con:user-header name="MyCustomHeader" value="Custom Header Value" />
</con:user-headers>

アウトバウンド・リクエストとインバウンド・レスポンスの場合、Service Busはアウトバウンド・リクエスト・メッセージの作成時に任意のuser-header要素を対応するMIMEパートのカスタム・ヘッダーに変換します。user-header要素は、(解凍済)インバウンド・リクエストの結果にでき、挿入、置換または割当てアクションなどの明示的パイプライン・アクションに手動で追加できます。

A.4 inbound変数とoutbound変数

$inboundコンテキスト変数と$outboundコンテキスト変数には、インバウンド・エンドポイントとアウトバウンド・エンドポイントに関する情報が格納されます。$inbound変数にはリクエスト・メッセージを受信したプロキシ・サービスに関する情報が格納され、$outbound変数にはメッセージの送信先であるターゲット・ビジネス・サービスに関する情報が格納されます。

$outbound変数は、ルート・ノードのルート・アクションとパブリッシュ・アクションで設定されます。$outboundを変更するには、ルート・ノードでリクエスト・アクションとレスポンス・アクションを構成し、パブリッシュ・アクションでリクエスト・アクションを構成します。

警告:

$inboundコンテキスト変数および$outboundコンテキスト変数に行う変更の一部は、実行時に保持されません。つまり、特定のヘッダーおよびメタデータは、Service Busランタイムによって上書きまたは無視されます。トランスポート・ヘッダーとサービス・コールアウト・アクションを使用してトランスポート・ヘッダーとメタデータを設定する場合や、テスト・コンソールを使用してサービスをテストする場合にもこの制限は当てはまります。

制限のあるヘッダーとメタデータの詳細は、「テスト・コンソールでのランタイムによるトランスポート設定の使用方法」を参照してください。ルート・ノードのリクエスト・アクションまたはレスポンス・アクションおよびパブリッシュ・アクション以外でメッセージ・フローの$outboundに行う変更は無視されることにも注意してください。つまりルート・ノードおよびパブリッシュ・アクションで$outboundが初期化される際、、それらの変更は上書きされるということです。

サービス・コールアウト・アクションで$outbound変数を変更することはできません。

$inbound変数と$outbound変数の特性は次のとおりです。

- 同じXMLスキーマを持ちます。$inboundコンテキスト変数と$outboundコンテキスト変数は、「メッセージ・コンテキスト・スキーマ」で説明されているようにendpoint要素のインスタンスです。

- サービス・ディレクトリに登録されているエンドポイントの名前を指定する単一のname属性を含みます。name属性は、$inbound、$outboundいずれの場合も読取り専用として扱う必要があります。

警告:

この読取り専用ルールは強制されません。読取り専用の要素を変更すると予期できない動作が生じることがあります。

- 「Inbound変数とOutbound変数の下位要素」で説明する下位要素service、transportおよびsecurityを含みます。

A.4.1 Inbound変数とOutbound変数の下位要素

この項では、コンテキスト変数$inboundおよび$outboundの下位要素について説明します。また、どの下位要素が実行時に初期化されるかについての情報も示します。コンテキスト変数が初期化される方法については、「コンテキスト変数の初期化」を参照してください。次の下位要素があります。

- service

- transport

- security

A.4.1.1 service

service要素は、$inbound、$outboundいずれの場合も読取り専用です。下位要素としてはproviderName、operationがあります。

注意:

メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。

表A-4 service要素の下位要素

サブ要素

説明

providerName

サービス・キー・プロバイダの名前。パブリッシュ・アクションおよびルーティング・アクションの構成に基づいて初期化されます。

operation

(outboundのみ)

対象のビジネス・サービスで呼び出される操作の名前。$inboundおよび$outboundに基づいて初期化されます。

注意: この要素は$outbound変数に対してのみ使用されます。inboundメッセージの場合は、プロキシ・サービスで呼び出される操作の名前が$operation変数によって指定されます。

A.4.1.2 transport

transport要素はinboundの場合は読取り専用ですが、例外として、response要素ではこの要素を変更してレスポンス・トランスポート・ヘッダーを設定できます。transport要素の下位要素を表A-5に示します。

注意:

メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。

表A-5 transport要素の下位要素

サブ要素

説明

uri

エンドポイントのURI。

- $inbound変数で使用する場合、これは、メッセージを受信するURIです。

- $outbound変数で使用する場合、これは、メッセージの送信時に使用するURIです。サービス・ディレクトリに登録されたURI値をオーバーライドします。

初期化

URI要素は次のように初期化されます。

- $inbound変数の場合は常に初期化されます。

- $outbound変数の場合は初期化されません。$outboundに対してURIを設定すると、サービス構成で指定されたURIのセットがオーバーライドされます。この要素を設定した場合、URIフェイルオーバーはサポートされません。

request

リクエストに関するトランスポート固有のメタデータ(トランスポート・ヘッダーを含む)。この要素の値は転送プロトコルによって定義されます(具体的には、トランスポートSDKによって定義されたRequestMetaData XML)。したがって、この要素の構造は使用されるトランスポートによって異なります。

$inbound変数では、この要素は読取り専用です。$outbound変数の場合は変更可能です。注意: この読取り専用ルールは強制されません。読取り専用の要素を変更すると予期できない動作が生じることがあります。

この要素のトランスポート固有の型については、Service Busインストールの次のディレクトリに用意された該当するトランスポート・スキーマを参照してください。

service_bus-home/config/plugins/

初期化

URI要素は次のように初期化されます。

- $inbound変数の場合は、Service Busで受信したリクエスト・メッセージの情報を使用して初期化されます。

- $outbound変数の場合は、適切な型のrequest要素が作成されます。使用される型はトランスポートに依存します。request要素は通常は空の要素として初期化されますが、一部の重要なトランスポート・ヘッダー(content-type、SOAPActionなど)については例外です。

ファイル・トランスポート・プロトコルを使用してアウトバウンド・メッセージのファイル名を設定するには、次で説明するように、ルート・ノード・リクエスト・アクションで$outboundを構成します。

- fileNameのみを指定した場合、その名前のファイルはターゲット・ビジネス・サービスのエンドポイントURIで指定される場所に格納されます。

- isFilePathをtrueに設定している場合、fileNameの値はターゲット・ビジネス・サービスのエンドポイントURIに追加された相対パスとして使用されます。たとえば、エンドポイントURIがfile:////service/ob/dataで、fileNameヘッダーが./schema/example.xmlに、isFilePathがtrueに設定されている場合、メッセージは/service/ob/data/schema/example.xmlに格納されます。
その名前のファイルがすでに存在する場合、path/filename_random-number.xmlの形式で新しい名前が生成されます。ここで、random-numberは0から999999の整数です。

response

レスポンスに関するトランスポート固有のメタデータ(トランスポート・ヘッダーを含む)。この要素の値は転送プロトコルによって定義されます(具体的には、トランスポートSDKによって定義されたResponseMetaData XML)。したがって、この要素の構造は使用されるトランスポートによって異なります。

この要素は、$outbound変数の場合は読取り専用です。$inbound変数の場合は変更可能です。

この要素のトランスポート固有の型については、Service Busインストールの次のディレクトリに用意された該当するトランスポート・スキーマを参照してください。

service_bus-home/config/plugins/

初期化

URI要素は次のように初期化されます。

- $outbound変数の場合は、Service Busで受信したレスポンス・メッセージの情報を使用して初期化されます。

- $inbound変数の場合は、適切な型のresponse要素が作成されます。使用される型はトランスポートに依存します。response要素は通常は空の要素として初期化されますが、一部の重要なトランスポート・ヘッダー(content-type、SOAPActionなど)については例外です。

標準HTTPヘッダーの説明については、http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlを参照してください。

標準JMSヘッダーの詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のJMSパブリックAPIの付加価値拡張機能に関する項を参照してください。

注意: MQヘッダーApplOriginData、ApplIdentityData、Accounting TokenにはOracle JMSと同等のものがありません。

mode

通信スタイルがrequest(一方向)であるか、request-response(双方向)であるかのインジケータ。

初期化

$inbound変数、$outbound変数のいずれの場合も、サービスおよびそのサービスの操作(該当する場合)の情報を使用して初期化されます。たとえば、リクエストのみの操作が呼び出されるとき、mode要素はrequest-responseではなくrequestに設定されます。

qualityOfService

この要素は、inbound変数の場合は読取り専用です。

outbound(パブリッシュ・アクションまたはルーティング・アクションのアウトバウンド・リクエスト・アクション)の場合は変更可能です。

メッセージ送信時または受信時に使用するサービスの品質。有効な値はbest-effortとexactly-onceです。

- best-effortは、各ディスパッチで、トランザクション・コンテキストが定義されることを意味します(トランスポートがトランザクションの場合)。メッセージングの機能に信頼性はなく、重複するメッセージは除去されませんが、パフォーマンスが最適化されます。
パブリッシュ・アクションの結果としてメッセージがディスパッチされるシナリオでは、ディスパッチ・エラーは抑制されます。ルーティング・ノードからメッセージがディスパッチされるシナリオでは、ディスパッチ・エラーは抑制されません。

- exactly-onceでは、ディスパッチはインバウンド・トランザクション・コンテキストの一部として含められます(コンテキストが存在し、アウトバウンド・トランスポートがトランザクション対応の場合)。エラーが発生すると、処理が中止され、関連付けられているエラー・ハンドラがトリガーされます(ルーティング、パブリッシュのいずれの場合も)。「必ず1回」の信頼性では、アウトバウンド・メッセージの送信が開始されるまで終了エラーが発生しないことを前提として、メッセージがインバウンドからアウトバウンドに1回のみ配信されます。

初期化

qualityOfService要素は、$inbound変数および$outbound変数で次のように初期化されます。

- inbound変数の場合、サービス品質(QoS)はトランスポートによって決定されます。たとえば、JMS/XAトランスポートでは「必ず1回」で、HTTPトランスポートでは「ベスト・エフォート」です。

- outboundの場合、QoSはパブリッシュとルーティングで異なり、次のように設定されます。
ルーティング: メッセージがルート・ノードから別のサービスにルーティングされる場合、QoSは、$inboundコンテキスト変数の値を使用して常に初期化されます。つまり、アウトバウンドのQoSは、インバウンドのQoSが「必ず1回」の場合(のみ)「必ず1回」に設定されます。それ以外の場合、アウトバウンドのQoSは「ベスト・エフォート」に設定されます。

パブリッシュ: メッセージが、パブリッシュ・アクションの結果として別のサービスにパブリッシュされる場合、サービスの品質(QoS)は、インバウンドの設定に関係なく、「ベスト・エフォート」に常に初期化されます。

retryCount

(outboundのみ)

Service Busからメッセージを送信するときの再試行回数。

retryCountが設定されている場合は、ターゲット・サービスの構成に含まれるすべての再試行回数の値がこの設定によりオーバーライドされます。

A.4.1.3 security

security要素の下位要素を表A-6に示します。

注意:

メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。

表A-6 security要素の下位要素

サブ要素

説明

transportClient

inboundのみ)

認証されたトランスポート・レベル・ユーザー情報。ユーザー情報にはユーザー名とオプションのprincipalsが含まれます。principalsには0個以上のgroupを含めて、subjectが属するgroupごとに1つの要素を含めることができます。

この変数は、Service Busによって初期化されます。inboundのtransportClient要素は読取り専用です。注意: この読取り専用ルールは強制されません。読取り専用の要素を変更すると予期できない動作が生じることがあります。subjectが匿名の場合、ユーザー名はanonymousであり、group要素はありません。

messageLevelClient

inboundのみ)

認証されたメッセージ・レベル・ユーザー情報を指定します。ユーザー情報にはユーザー名とオプションのprincipalsが含まれます。principalsには0個以上のgroupを含めて、subjectが属するgroupごとに1つの要素を含めることができます。

この変数は、Service Busによって初期化されます。inboundのmessageLevelClient要素は読取り専用です。subjectが匿名の場合、ユーザー名はanonymousであり、group要素はありません。

doOutboundWss

(outboundのみ)

Service Busは、ルーティング時またはパブリッシュ時にこの要素の値を設定します。使用頻度の低いデザイン・パターンには、この値をfalseに設定して、サービスがアウトバウンドWS-Security SOAPエンベロープを自動的に生成しないようにするものもあります。

詳細は、「アウトバウンドWS-Securityの無効化」の下を参照してください。

注意: あるプロキシ・サービスがOracle Web Services Managerサービス・ポリシーを含む別のプロキシ・サービス(ローカル・プロキシなど)を呼び出す場合は、アウトバウンドWS-Security処理は行われません。Service Busはその動作を自動的に処理して、doOutboundWssプロパティは使用しません。詳細は、「ローカル・プロキシ・サービスでのOWSMセキュリティの使用」を参照してください。

A.4.2 関連トピック

Oracle Service Busコンソールでのパイプライン・アクションの操作

コンソールでのパイプラインへのルート・ノードの追加方法

標準HTTPヘッダーの説明については、http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlを参照してください。

標準JMSヘッダーの詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のWebLogic JMSの理解に関する項を参照してください。

A.5 operation変数

$operation変数は、読取り専用の変数です。この変数には、パイプラインで呼び出される操作を指定する文字列が格納されます。操作が定義されていない場合は、$operation変数が設定されず、nullと等価の値が返されます。

Service Busは、パフォーマンスの最適化のために、$operation変数を、$inbound変数の下位要素としてではなく、スタンドアロン変数として提供します。操作の計算は、inbound変数がアクセスされた場合に常に行われるのではなく、$operation変数が明示的にアクセスされるまで保留される場合があります。

A.6 fault変数

fault変数は、メッセージ処理中に発生したすべてのエラーに関する情報を保持します。エラーが発生すると、この変数に情報が格納されてから、適切なエラー・ハンドラが呼び出されます。この変数はエラー・ハンドラ・パイプラインでのみ定義され、リクエスト・パイプラインやレスポンス・パイプライン、ルート・ノードやブランチ・ノードでは設定されません。

fault変数には、表A-7に示す下位要素が含まれます。

注意:

メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。

表A-7 fault変数の下位要素

fault変数の要素

説明

errorCode

文字列値によるエラー・コード。

reason

テキストによるエラーの説明。

details

エラーに関連するユーザー定義XMLコンテンツ。詳細は、「エラー・コード」および「エラーの詳細」を参照してください。

location

エラーが発生したノード、パイプライン、およびステージを指定します。また、エラーがエラー・ハンドラ内で発生したかどうかも指定します。次の下位要素があります。

- node: 文字列の形式による、エラーが発生したパイプライン・ペア、ブランチまたはルート・ノードの名前。

- pipeline: 文字列の形式による、エラーが発生したパイプラインの名前(該当する場合)。

- stage: 文字列の形式による、エラーが発生したステージの名前(該当する場合)。

- error-handler: エラー・ハンドラ内でエラーが発生したかどうかを示すブール値。

java-exception

例外インスタンス参照についての情報。これには、それぞれが単一インスタンスを定義する複数のref要素を含めることができます。

stack-trace

フォルトに追加される任意のスタック・トレース。

A.6.1 エラー・コード

fault変数のコンテンツは、SOAPベースのサービスからの返信時にフォルトを生成しやすいよう、SOAPフォルトに基づいてモデル化されています。Service Busによって生成されるエラー・コードの値は、他の方法で構成されていなければ、システム・エラー・コードに対応し、エラー・コードの先頭にはOSBという文字列が付加されます。エラーに関連付けられたエラー・コードは、faultコンテキスト変数の要素内に表示されます。値にアクセスするには、次のXQuery文を使用します。

$fault/ctx:errorCode/text()

Service Busでは、考えられる4つのクラスのエラーに対応する汎用エラー・コードが定義されています。汎用コードの形式はOSB-xxx000 (xxxは汎用カテゴリを次のように表します)です。

- 380トランスポートとプロキシ

- 382パイプライン

- 386セキュリティ

- 394 UDDI

これにより、次のように汎用コードが生成されます。

- OSB–380000—OSB–380999
トランスポートまたはプロキシ・サービスのエラーを示します(メッセージのディスパッチの失敗など)。

- OSB–382000—OSB–382499
パイプラインの実行時エラーを示します(ステージの例外など)。

- OSB–382500—OSB–382999
パイプライン・アクション内のエラーを示します。

- OSB–386000—OSB–386999
WS-Securityエラーを示します(認可エラーなど)。

- OSB–394500—OSB–394999
UDDIサブシステム内のエラーを示します。

Service Busでは、特定のエラーを示す一意のコードが定義されています。次に例を示します。

- OSB-382030: メッセージ解析エラーを示します(SOAPサービスが非SOAPメッセージを受信したなど)。

- OSB-382500: サービス・コールアウト・アクションがSOAPフォルト・レスポンスを受信した場合に備えて予約されています。

A.6.2 エラーの詳細

fault変数のdetails要素には、フォルトのタイプとその関連情報が表示されます。エラー・タイプを示す、次のいずれかの要素が含まれます。

- ErrorResponseDetail: サービス・コールアウト・アクションがトランスポート・プロバイダからエラー・レスポンスを受信したことを示します。

- InvalidEnvelope: SOAPサービスが予期しないSOAPエンベロープの整形式XMLドキュメントを受信したことを示します。

- PayloadDetail: XMLとしてペイロードのすべてまたは一部を解析中に、エラーが発生したことを示します。

- ReceivedFaultDetail: サービス・コールアウト・アクションがSOAPフォルトを受信したことを示します。

- UnrecognizedResponseDetail: サービス・コールアウト・アクションがトランスポート・プロバイダから認識できないレスポンスを受信したことを示します。

- ValidatonFailureDetail: 検証アクションでエラーが発生したことを示します。

- WebServiceSecurityFault: Webサービス・セキュリティ処理関連のエラーが発生したことを示します。

- StackTrace: 前述されていない場合の例外スタック・トレース。

エラー・スキーマ・ファイルについては、「エラー・スキーマ」を参照してください。

A.6.3 XML解析エラー(PayloadDetail)

「エラーの詳細」で説明するように、XML解析エラーの場合は不正なXMLテキストがエラー・スキーマのPayloadDetail要素に含まれます。解析エラーは、パイプラインへのインバウンド・リクエスト・メッセージおよびビジネス・サービスへのアウトバウンド・レスポンス・メッセージの解析中にのみ検出されます。割当てアクションなど、不正なXMLにつながるペイロードを明示的に変更するアクションは、このエラーの詳細に含まれません。

XMLパーサーが読み取るペイロードの一部のみがfault変数に含まれるため、PayloadDetail要素にはXMLテキスト全体は含まれない場合があります。デフォルトでは、エラーの詳細に含まれる文字数に制限はありません。fault変数のペイロード詳細に含まれるXMLテキストのサイズを制限するには、システム・プロパティのcom.bea.wli.sb.FaultPayloadDetailMaxSizeを、含めるテキストのサイズに設定します(KB単位)。このプロパティを0 (ゼロ)に設定すると、この機能が無効になり、フォルトはPayloadDetail要素に含まれません。

パイプラインでコンテンツのストリーミングを有効にすると、PayloadDetail要素内のテキストは、10KBまたは設定した最大サイズ(10KB未満の場合)のいずれかに切り捨てられます。ペイロードにバイナリ文字が含まれる場合、そのペイロードはbase64エンコード形式でPayloadDetail要素のbase64子要素に配置されます(最大ペイロード詳細サイズまで)。

A.7 messageID変数

messageIDは、メッセージに関連付けられたトランスポート・プロバイダ固有のIDです。$messageIDシステム変数を介してアクセスできます。

A.8 コンテキスト変数の初期化

メッセージ・コンテキストとその変数は、メッセージ受信時およびメッセージ処理の開始前にバインディング・レイヤーで初期化されます。コンテキスト変数を初期化する方法を表A-8に示します。

表A-8 コンテキスト変数の初期化

コンテキスト変数

初期化方法

outbound

ルーティングが行われていないか、エラーが発生していないため、nullに初期化されます。

fault

$outbound変数は、ルート・ノードのルート・アクションとパブリッシュ・アクションで初期化されます。ルーティング・ノードのリクエスト・アクションとパブリッシュ・アクションで(さらに、ルーティング・ノードのレスポンス・アクションでも)$outboundを変更できます。詳細は、「inbound変数とoutbound変数」を参照してください。

$outboundの下位要素の初期化については、「inbound変数とoutbound変数の下位要素」を参照してください。

inbound

登録されたプロキシ・サービスに関するService Busメタデータと、特定の受信リクエストに関するトランスポート・レベル・メタデータ(トランスポート・ヘッダー、認証されたユーザー情報など)から取得したサービス、トランスポート、およびセキュリティの情報で初期化されます。

$inboundの下位要素の初期化については、「inbound変数とoutbound変数の下位要素」を参照してください。

header

body

attachments

operation

インバウンド・メッセージのコンテンツを使用して初期化されます。初期化の実行方法は、この項の以降のトピックで説明するようにサービスのタイプによって異なります。

- attachmentsコンテキスト変数の初期化

- header、bodyコンテキスト変数の初期化

$header、$body、$attachmentsの3つの変数は、ルーティングの後に、受信したレスポンスのコンテンツを使用して再初期化されます。ルーティングが実行されない場合や、通信モードがリクエストのみの場合、これらの変数は再初期化されません。つまり、これらの変数のコンテンツはクリアされません。

A.8.1 Attachmentsコンテキスト変数の初期化

$attachmentsコンテキスト変数は、メッセージに含まれるすべてのMIME添付ファイルで初期化されますが、メイン・メッセージを表す部分は含まれません(SOAP、XML、MFLなど形式を問わず)。各<attachment>要素は、MIMEパッケージの各部分に伴うMIMEヘッダーを使用して初期化されます。

<attachment>の<body>要素のコンテンツは、添付のContent-Typeに応じて次のいずれかになります。

- XML

- テキスト

- 添付コンテンツを参照する参照XMLスニペット(「body変数とattachments変数内のバイナリ・コンテンツ」を参照)。

A.8.2 HeaderおよびBodyコンテキスト変数の初期化

この項では、コンテキスト変数$headerおよび$bodyの初期化方法について説明しますが、これらの変数の初期化方法は、サービスのタイプが「SOAPサービス」、「XMLサービス(非SOAP)」、「メッセージング・サービス」のいずれであるかによって異なります。

A.8.2.1 SOAPサービス

SOAPベースのサービスへのメッセージは、<soap:Envelope>要素に含まれるXMLを含むSOAPメッセージです。添付を含むメッセージの場合、インバウンド・メッセージのコンテンツは、SOAPエンベロープをその一部として(通常は最初の部分、または最上位のContent-Typeヘッダーで指定される部分)含むMIMEパッケージです。コンテキスト変数は次のように初期化されます。

- $header: SOAPメッセージの<soap:Header>要素で初期化されます。

- $body: SOAPメッセージの<soap:Body>要素で初期化されます。

A.8.2.2 XMLサービス(非SOAP)

XMLベースのサービスへのメッセージはXMLですが、サービス構成で許可された型を使用できます。添付を含むメッセージの場合、インバウンド・メッセージのコンテンツは、プライマリXMLペイロードをその一部として(通常は最初の部分、または最上位のContent-Typeヘッダーで指定される部分)含むMIMEパッケージです。

コンテキスト変数は次のように初期化されます。

- $header: 空の<soap:Header/>要素で初期化されます。

- $body: XMLペイロード全体をラップする<soap:Body>要素で初期化されます。

A.8.2.3 メッセージ・サービス

メッセージング・サービスは、あるデータ型のメッセージを受信し、応答として別のデータ型のメッセージを返すことができるサービスです。サポートされるデータ型は、XML、MFL、テキスト、または型なしバイナリです。コンテキスト変数は次のように初期化されます。

- $header: 空の<soap:Header/>要素で初期化されます。

- $body: ペイロード全体をラップする<soap:Body>要素で初期化されます。

- XML、MFL、およびテキスト・コンテンツの場合は、<soap:Body>要素内に直接挿入されます。

- バイナリ・コンテンツの場合は、参照XMLコードが作成され<soap:Body>要素内に挿入されます(「body変数とattachments変数内のバイナリ・コンテンツ」を参照)。バイナリ・コンテンツに対してアクセスまたは変更を行うことはできませんが、参照XMLを検証および変更し、インライン・コンテンツと置き換えることができます。

A.9 コンテキスト変数に対する操作の実行

メッセージ・コンテキストに対する対話および操作は、パイプラインを定義するパイプライン・ペア、ブランチまたはルート・ノードでのアクションを通じて行います。ほとんどのアクションについては、それを実行するためのXQuery言語が公開されています。各コンテキスト変数は、同じ名前のXQuery変数として表されます。たとえば、$header変数は、XQueryでは$headerとしてアクセスでき、$body変数は$bodyとしてアクセスできます。この項の例では、XQueryを使用してコンテキスト変数に対するチェックおよび操作を行っています。

A.9.1 $body

$body変数は<soap-env:Body>...</soap-env:Body>要素を含みます。(サービスがSOAP 1.2の場合、$body変数にはSOAP 1.2 Body要素が格納されます。)たとえば、割当てアクションを使用して$bodyコンテキスト変数にデータを割り当てた場合、<soap-env:Body>要素でデータをラップする必要があります。つまり、コンテキスト変数内に<soap-env:Body>要素を含めることによってSOAPパッケージを構築します。

サービス・コールアウト・アクションのリクエスト・ドキュメント変数を作成する場合は、例外です。この場合、サービス・コールアウト・アクションはコアのペイロード(RPCパラメータ、ドキュメントなど)を処理の対象とし、Service Busはコアのペイロードに基づいてSOAPパッケージを構築します。つまり、サービス・コールアウト・アクションのリクエスト・ドキュメント変数を構成するときには、入力ドキュメントを<soap-env:Body>...</soap-env:Body>でラップしません。

サービス・コールアウト・アクションの構成については、「コンソールでのサービス・コールアウト・アクションの追加」を参照してください。

A.9.2 $header

$header変数は<soap-env:Header>...</soap-env:Header>要素を含みます。(プロキシ・サービスがSOAP 1.2の場合、$header変数にはSOAP 1.2 Header要素が格納されます。)たとえば、割当てアクションを使用して $headerコンテキスト変数にデータを割り当てた場合、<soap-env:Header>要素でデータをラップする必要があります。つまり、コンテキスト変数内に<soap-env:Header>要素を含めることによってSOAPパッケージを構築します。これは、サービス・コールアウト・リクエストの1つまたは複数のSOAPヘッダーを設定できる場合を含め、$headerのすべての操作に該当します。サービス・コールアウト・アクションのSOAPヘッダーの構成の詳細は「コンソールのサービス・コールアウト・アクションの追加」を参照してください。

WS-Addressingヘッダー(From)の抽出: $header/wsa:From

非SOAPメッセージからのペイロードの抽出: $body/*

アウトバウンド・レスポンス・メッセージからのuser-headerの抽出: $outbound/ctx:transport/ctx:response/tp:user-header[@name='myheader']/@value

SOAPサービスへのサービス・コールアウト内のリクエスト・パラメータに使用する$body入力変数を作成する場合、soap-env:Bodyラッパーを削除するために、$body/*を使用してその変数のコンテンツを定義します($bodyを使用すると、soap-env:Bodyラッパーが保持されます)。

サービス コールアウト内のリクエスト・パラメータの変数コンテンツの割当て: $body/*

A.9.3 関連トピック

XQueryエディタおよびXPathエディタを使用したコンテキスト変数の処理の詳細は、次を参照してください。

- 変数の構造での作業

- Oracle Service Busコンソールでの式エディタの操作

A.10 ディスパッチするメッセージの作成

Service Busによってメッセージがパブリッシュまたはルーティングされるときに、メッセージ・コンテキストの変数の値を使用してメッセージのコンテンツが作成されます。たとえば、トランスポート・ヘッダーとトランスポート固有のメタデータは、$outbound/transport/requestから取得されます。コンテキストの初期化と同様に、アウトバウンド・メッセージのメッセージ・コンテンツはターゲット・サービスのタイプに応じて異なって処理されます。次のトピックで説明されているように、アウトバウンド・メッセージ・コンテンツの作成方法はターゲット・サービスのタイプによって異なります。

- SOAPサービス

- XMLサービス(非SOAP)

- メッセージング・サービス

A.10.1 SOAPサービス

送信SOAPメッセージは、$header変数と$body変数のコンテンツを<soap:Envelope>要素でラップして作成します。呼び出されたサービスがSOAP 1.2サービスの場合、作成されるエンベロープはSOAP 1.2エンベロープです。呼び出されたサービスがSOAP 1.1サービスの場合、作成されるエンベロープはSOAP 1.1エンベロープです。$body変数に参照XMLコードが格納されている場合、メッセージは現状のまま送信されます。つまり、参照されているコンテンツはメッセージに追加されません。

$attachments変数で添付が定義されている場合は、メイン・メッセージと添付データからMIMEパッケージが作成されます。各添付部分のコンテンツの処理方法は、メッセージング・サービスのコンテンツの処理方法に類似しています。

A.10.2 XMLサービス(非SOAP)

Service BusのXMLベースのサービスへのメッセージは、$body変数のコンテンツから作成されます。

- $body変数が空の場合は、サイズがゼロのメッセージが送信されます。

- $body変数に複数のXMLスニペットが含まれる場合は、最初のスニペットのみがアウトバウンド・メッセージで使用されます。たとえば、<soap:Body>に<abc/><xyz/>が含まれる場合は、<abc/>のみが送信されます。

- $body変数のコンテンツがXMLではなくテキストである場合は、エラーがスローされます。

- $body変数に参照XMLコードが格納されている場合、メッセージは現状のまま送信されます。つまり、参照されているコンテンツはメッセージに追加されません。

- $attachments変数で添付が定義されている場合は、XMLメッセージと添付データからMIMEパッケージが作成されます。XMLメッセージがnullの場合は、対応するMIME本文部分は空になります。各添付部分のコンテンツの処理方法は、メッセージング・サービスのコンテンツの処理方法に類似しています。

含まれているデータのタイプにかかわらず、$header変数はアウトバウンド・メッセージにコンテンツを提供しません。サービス・コールアウト・アクションに対するメッセージの作成の例については、「Oracle Service Busコンソールでのパイプライン・アクションの操作」を参照してください。

A.10.3 メッセージ・サービス

Service Busのメッセージ・サービスへのメッセージは、$body変数のコンテンツから作成されます。

- 送信メッセージのタイプに関係なく、$body変数が空の場合、サイズがゼロのメッセージが送信されます。

- 送信メッセージのタイプがXMLの場合、メッセージは「XMLサービス(非SOAP)」で示されているのと同じ方法で作成されます。

- 送信メッセージのタイプがMFLの場合は、抽出されたXMLがMFLに変換される点を除きXMLメッセージの場合と同様に処理されます。XMLからMFLへの変換が実行できない場合はエラーが発生します。

- ターゲット・サービスでテキスト・メッセージが要求される場合は、$body変数のコンテンツがテキストとして解釈され送信されます。このため、Service Busでは、ターゲット・サービスにテキストとして配信する必要がある着信XMLメッセージを処理できます。つまり、このようなメッセージを処理するためにメッセージ・フローを構成する必要はありません。

- バイナリ・メッセージを受信するターゲット・サービスの場合は、$body変数に参照XMLコードを格納する必要があります。参照URIは、Service Busのメモリー内ハッシュ表に格納されたバイナリ・データを参照します。参照先コンテンツはターゲット・サービスに送信されます。
クライアント、トランスポートまたはサービスの設計者によって参照URIが指定される場合、参照されるデータはService Busに格納されないため、アウトバウンド・メッセージに含めることはできません。したがって、参照XMLがメッセージで送信されます。

$body変数に参照XMLコードが含まれ、ターゲット・サービスでバイナリ以外のメッセージが要求される場合は、$body変数内の参照XMLはコンテンツとして処理されます。つまり、メッセージはXMLとして送信されるか、テキストに変換されるか、またはMFLに変換されます。これは、参照XMLのURIに関係なく当てはまります。

含まれているデータのタイプにかかわらず、$header変数はアウトバウンド・メッセージにコンテンツを提供しません。

サービス・コールアウト・アクションに対するメッセージの作成の例については、「Oracle Service Busコンソールでのパイプライン・アクションの操作」を参照してください。

A.10.3.1 電子メール・メッセージでのバイナリ・コンテンツの送信について

バイナリ・メッセージの場合、Service Busでは$body変数にメッセージ・コンテンツは挿入されません。かわりに、<binary-content/>参照要素が作成され<SOAP:Body>要素に挿入されます(「メッセージ関連の変数」を参照)。ただし、電子メール規格では、バイナリ・コンテンツ・タイプをメッセージの主要な部分として送信することがサポートされていません。テキストまたはXMLのドキュメントと任意の添付を受信するメッセージ・サービスに、電子メールでバイナリ・メッセージを送信する場合は、次の手順に従います。

1. バイナリ・コンテンツ参照XMLを$bodyから$attachmentsに変更します。

2. $bodyのコンテンツを<SOAP:Body>要素でラップされたテキストまたはXMLに置き換えます。

送信メッセージのタイプがMFLの場合は、$bodyのコンテンツが、MFLトランスフォーメーションに基づいてXMLからテキストまたはバイナリに変換されます。

- ターゲット・サービスでテキスト・メッセージを受信する場合は、$outboundでcontent-type (MFLメッセージ・タイプのデフォルトはバイナリ)をtext/plainとして設定できます。

- ターゲット・サービスでバイナリ・メッセージを受信する場合は、電子メール・トランスポートを使用してMFLコンテンツを送信することはできません。

バイナリ・コンテンツの処理方法については、「body変数とattachments変数内のバイナリ・コンテンツ」を参照してください。

A.10.4 関連トピック

メッセージ・コンテキスト・スキーマ

コンソールでのサービス・コールアウト・アクションの追加

コンソールでのトランスポート・ヘッダー・アクションの追加

コンソールでのパイプラインへのルート・ノードの追加方法

A.11 メッセージ・コンテキスト・スキーマ

次の例は、メッセージ・コンテキスト変数の要素の型を指定するメッセージ・コンテキスト・スキーマ(MessageContext.xsd)を示します。

メッセージ・コンテキスト変数を操作する場合、JARファイル(OSB_ORACLE_HOME/lib/servicebus-schemas.jar)に用意されたMessageContext.xsdと、OSB_ORACLE_HOME/config/plugins/にあるトランスポート固有のスキーマを参照する必要があります。

例 - MessageContext.xsd

<schema targetNamespace="http://www.bea.com/wli/sb/context"
xmlns:mc="http://www.bea.com/wli/sb/context"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">

<!-- =========================================================================== -->

<!-- The context variable 'fault' is an instance of this element -->
<element name="fault" type="mc:FaultType"/>

<!-- The context variables 'inbound' and 'outbound' are instances of this
element -->
<element name="endpoint" type="mc:EndpointType"/>

<!-- The three sub-elements within the 'inbound' and 'outbound' variables -->
<element name="service" type="mc:ServiceType"/>
<element name="transport" type="mc:TransportType"/>
<element name="security" type="mc:SecurityType"/>

<!-- The context variable 'attachments' is an instance of this element -->
<element name="attachments" type="mc:AttachmentsType"/>

<!-- Each attachment in the 'attachments' variable is represented by an
instance of this element -->
<element name="attachment" type="mc:AttachmentType"/>

<!-- Used to represent binary payloads and pass-by reference content -->
<element name="binary-content" type="mc:BinaryContentType"/>

<!-- Element used to represent POJOs stored in object repository -->
<element name="java-content" type="mc:JavaContentType"/>

<!-- =========================================================================== -->

<!-- The schema type for  -->
<complexType name="AttachmentsType">
<sequence>
<!-- the 'attachments' variable is just a series of attachment
elements -->
<element ref="mc:attachment" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>

<complexType name="AttachmentType">
<all>
<!-- Set of MIME headers associated with attachment -->
<element name="Content-ID" type="string" minOccurs="0"/>
<element name="Content-Type" type="string" minOccurs="0"/>
<element name="Content-Transfer-Encoding" type="string"
minOccurs="0"/>
<element name="Content-Description" type="string" minOccurs="0"/>
<element name="Content-Location" type="string" minOccurs="0"/>
<element name="Content-Disposition" type="string" minOccurs="0"/>

<!-- any (custom) headers not specified above will be here -->
<element name="user-headers" minOccurs="0">
<complexType>
<sequence>
<element name="user-header" maxOccurs="unbounded">
<complexType>
<attribute name="name" type="string"/>
<attribute name="value" type="string"/>
</complexType>
</element>
</sequence>
</complexType>
</element>

<!-- Contains the attachment content itself, either in-lined or as <binary-content/> -->
<element name="body" type="anyType"/>
</all>
</complexType>

<complexType name="BinaryContentType">
<!-- URI reference to the binary or pass-by-reference payload -->
<attribute name="ref" type="anyURI" use="required"/>
</complexType>

<complexType name="JavaContentType">
<!-- URI reference to POJOs in object repository -->
<attribute name="ref" type="anyURI" use="required"/>
</complexType>

<!-- =========================================================================== -->

<complexType name="EndpointType">
<all>
<!-- Sub-elements holding service, transport and security details for
the endpoint -->
<element ref="mc:service" minOccurs="0" />
<element ref="mc:transport" minOccurs="0" />
<element ref="mc:security" minOccurs="0" />
</all>

<!-- Fully-qualified name of the service represented by this endpoint -->
<attribute name="name" type="string" use="required"/>
</complexType>

<!-- =========================================================================== -->

<complexType name="ServiceType">
<all    >
<!-- name of service provider -->
<element name="providerName" type="string" minOccurs="0"/>

<!-- the service operation being invoked -->
<element name="operation" type="string" minOccurs="0"/>
</all>
</complexType>

<!-- =========================================================================== -->

<complexType name="TransportType">
<all>
<!-- URI of endpoint -->
<element name="uri" type="anyURI" minOccurs="0" />

<!-- Transport-specific metadata for request and response (includes
transport headers) -->
<element name="request" type="anyType" minOccurs="0"/>
<element name="response" type="anyType" minOccurs="0" />

<!-- Indicates one-way (request only) or bi-directional
(request/response) communication -->
<element name="mode" type="mc:ModeType" minOccurs="0" />

<!-- Specifies the quality of service -->
<element name="qualityOfService" type="mc:QoSType" minOccurs="0" />

<!-- Retry values (outbound only) -->
<element name="retryInterval" type="integer" minOccurs="0" />
<element name="retryCount" type="integer" minOccurs="0" />

<!-- Throttling priority (outbound only) -->
<element name="priority" type="positiveInteger" minOccurs="0" />
</all>
</complexType>

<simpleType name="ModeType">
<restriction base="string">
<enumeration value="request"/>
<enumeration value="request-response"/>
</restriction>
</simpleType>

<simpleType name="QoSType">
<restriction base="string">
<enumeration value="best-effort"/>
<enumeration value="exactly-once"/>
</restriction>
</simpleType>

<!-- =========================================================================== -->

<complexType name="SecurityType">
<all>
<!-- Transport-level client information (inbound only) -->
<element name="transportClient" type="mc:SubjectType" minOccurs="0"/>

<!-- Message-level client information (inbound only) -->
<element name="messageLevelClient" type="mc:SubjectType"
minOccurs="0"/>

<!-- Boolean flag used to disable outbound WSS processing (outbound
only) -->
<element name="doOutboundWss" type="boolean" minOccurs="0"/>
</all>
</complexType>

<complexType name="SubjectType">
<sequence>
<!-- User name associated with this tranport- or message-level subject -->
<element name="username" type="string"/>
<element name="principals" minOccurs="0">
<complexType>
<sequence>
<!-- There is an element for each group this subject
belongs to, as determined by the authentication
providers -->
<element name="group" type="string" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="subject-properties" minOccurs="0" maxOccurs="1">
<complexType>
<sequence>
<element name="property" minOccurs="0"
maxOccurs="unbounded"
type="mc:SubjectPropertyType"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>

<complexType name="SubjectPropertyType" mixed="true">
<sequence>
<any minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
</sequence>
<attribute name="name" type="string" use="required"/>
<anyAttribute processContents="lax"/>
</complexType>

<!-- =========================================================================== -->

<complexType name="FaultType">
<all>
<!-- A short string identifying the error (e.g. BEA38229) -->
<element name="errorCode" type="string"/>

<!-- Descriptive text explaining the reason for the error -->
<element name="reason" type="string" minOccurs="0" />

<!-- Any additional details about the error  -->
<element name="details" type="anyType" minOccurs="0" />

<!-- Information about where the error occured in the proxy -->
<element name="location" type="mc:LocationType" minOccurs="0" />

<!-- Information about the exception instance reference stored in the
object repository -->
<element name="java-exception" minOccurs="0">
<complexType>
<sequence>
<element ref="mc:java-content" />
</sequence>
</complexType>
</element>
</all>
</complexType>

<simpleType name="PipelinePathType">
<restriction base="string">
<enumeration value="request-pipeline"/>
<enumeration value="response-pipeline"/>
</restriction>
</simpleType>

<complexType name="LocationType">
<all>
<!-- Name of the Pipeline/Branch/Route node where error occured -->
<element name="node" type="string" minOccurs="0" />

<!-- Name of the Pipeline where error occured (if applicable) -->
<element name="pipeline" type="string" minOccurs="0" />

<!-- Name of the Stage where error occured (if applicable) -->
<element name="stage" type="string" minOccurs="0" />

<!-- Indicates if error occured from inside an error handler -->
<element name="error-handler" type="boolean" minOccurs="0" />

<!-- Indicates whether or not error occured in request or
response path -->
<element name="path" type="mc:PipelinePathType" minOccurs="0" />
</all>
</complexType>

<!-- Encapsulates any stack-traces that may be added to a fault <details> -->
<element name="stack-trace" type="string"/>

</schema>

A.12 エラー・スキーマ

次の例は、エラーの構造を指定するエラー・スキーマ(Errors.xsd)を示します。このファイルは、JARファイルOSB_ORACLE_HOME/lib/servicebus-schemas.jarにあります。

例 - Errors.xsd

<schema targetNamespace="http://www.bea.com/wli/sb/errors"
xmlns:err="http://www.bea.com/wli/sb/errors"
xmlns:tc="http://www.bea.com/wli/sb/transports"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">

<import namespace="http://www.bea.com/wli/sb/transports"
schemaLocation="TransportCommon.xsd" />

<element name="InvalidEnvelope">
<complexType>
<sequence>
<element name="localpart" type="NCName"/>
<element name="namespace" type="anyURI" minOccurs="0"/>
</sequence>
</complexType>
</element>

<element name="WebServiceSecurityFault">
<complexType>
<sequence>
<element name="faultcode" type="QName"/>
<element name="faultstring" type="string"/>
<element name="detail" minOccurs="0">
<complexType mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
</sequence>
<anyAttribute namespace="##any" processContents="lax"/>
</complexType>
</element>
</sequence>
</complexType>
</element>

<!-- Publish error details -->
<element name="ErrorResponseDetail" type="err:ErrorResponseDetail"/>
<complexType name="ErrorResponseDetail">
<sequence>
<!-- Response metadata -->
<element name="response-metadata" type="tc:ResponseMetaDataXML" minOccurs="0" />
</sequence>
</complexType>

<!-- payload information in $fault details when parsing message into XML raises an error -->
<element name="PayloadDetail" type="err:PayloadDetail"/>
<complexType name="PayloadDetail">
<choice>
<element name="text" minOccurs="0" type="string" />
<element name="base64" minOccurs="0" type="base64Binary" />
</choice>
</complexType>

<!-- REST default (system) faults -->
<element name="RestError" type="err:RestErrorType"/>
<complexType name="RestErrorType">
<sequence>
<element name="errorMessage" minOccurs="0" type="string" />
<element name="errorCode" minOccurs="0" type="string" />
</sequence>
</complexType>

</schema>

window.name='GUID-EDAB1104-6169-49D3-BFFD-C92718D7C577' function footdisplay(footnum,footnote) { var msg = window.open('', 'NewWindow' + footnum, 'directories=no,height=120,location=no,menubar=no,resizable=yes,' + 'scrollbars=yes,status=no,toolbar=no,width=598'); msg.document.open('text/html'); }
B XPath拡張関数

この付録では、Service Busで相互参照とドメイン値マップを操作するためのXPath拡張関数について説明します。また、ユーザー定義のXPath拡張関数の作成方法についても説明します。オラクルでは、Service BusおよびXPath標準に組み込まれた機能を使用する、新規関数を追加するためのXPath関数を提供しています。

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

- 相互参照関数

- ドメイン値マップ関数

- カスタムXPath関数の作成

B.1 相互参照関数

相互参照を使用して、あるアプリケーション内のエンティティの値を、他のアプリケーションの同等の値に動的にマップできます。これは、アプリケーション内のオブジェクトの情報を更新するとき、そしてその情報を他のアプリケーションの同一オブジェクトに伝播する必要がある場合に役立ちます。各アプリケーションは、オブジェクトの識別に独自の方法を使用できます。

相互参照はルックアップ表に格納され、相互参照XPath関数を使用して、表内のデータをモニターおよび管理できます。相互参照マッピング表のデータを追加、更新およびルックアップするには、これらの関数を使用します。グローバル・トランザクションは、これらの関数コール時に使用可能である必要があります。トランザクションが使用できない場合、新しいトランザクションが開始されます。

注意:

相互参照関数のほとんどは、Service Bus相互参照リソースの場所と名前を引数として取ります。Service Busでは、Oracle Metadata Services (MDS)リポジトリのリソースへの直接参照はサポートしていません。

相互参照の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の相互参照の操作に関する項を参照してください。Service Busの相互参照の詳細は、「相互参照でのデータのマッピング」を参照してください。

B.1.1 lookupPopulatedColumns

この関数は、指定の相互参照表、相互参照列および値について、移入されたすべての列をルックアップします。ノードセット(各ノードに1つの列名と対応する値が含まれる)を返します。この関数の詳細な説明は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のxref:lookupPopulatedColumns関数に関する項を参照してください。

署名

xref:lookupPopulatedColumns(xref-location, column, value, need-exception)

引数

特に断りのないかぎり、すべての引数は文字列値です。

- xref-location: 相互参照リソースのフルパスおよび名前。

- column: 参照列の名前。

- value: 参照列に対応する値。

- need-exception: 値が見つからない場合に例外をスローするかどうかを示すブール値。trueに設定されると、この関数は値が見つからない場合に例外をスローします。それ以外は、空の値を返します。
実行時に、次の理由で例外が発生することがあります。

- 指定された名前の相互参照表が見つからない。

- 指定された列名が見つからない。

- 指定された参照値が空である。

プロパティID

- namespace-uri: http://www.oracle.com/osb/xpath-functions/xref

- namespace-prefix: xref

例

xref:lookupPopulatedColumns('/BookSellers/XRefPublishers', 'HARPER', 'H_1500', true())

B.1.2 lookupXRef

この関数は、参照列内の特定の値に対応する値について、相互参照列をルックアップします。この関数の詳細な説明は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のxref:lookupXRef関数に関する項を参照してください。

署名

xref:lookupXRef(xref-location, ref-column, ref-value, column-name, need-exception)

引数

特に断りのないかぎり、すべての引数は文字列値です。

- xref-location: 相互参照リソースのフルパスおよび名前。

- ref-column: 参照列の名前。

- ref-value: 参照列に対応する値。

- column-name: 値をルックアップする列の名前。

- need-exception: 値が見つからない場合に例外をスローするかどうかを示すブール値。trueに設定されると、この関数は値が見つからない場合に例外をスローします。それ以外は、空の値を返します。
実行時に、次の理由で例外が発生することがあります。

- 指定された名前の相互参照表が見つからない。

- 指定された列名が見つからない。

- 指定された参照値が空である。

- 複数の値が見つかった。

プロパティID

- namespace-uri: http://www.oracle.com/osb/xpath-functions/xref

- namespace-prefix: xref

例

xref:lookupXRef('/BookSellers/XRefPublishers', 'HARPER', 'H_1500', 'PENGUIN', false())

B.1.3 lookupXRef1M

この関数は、参照列内の特定の値に対応する複数の値について、相互参照列をルックアップします。複数のノードを含むノードセット(各ノードに1つの値が含まれる)を返します。この関数の詳細な説明は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のxref:lookupXRef1M関数に関する項を参照してください。

署名

xref:lookupXRef1M(xref-location, ref-column, ref-value, column-name, need-exception)

引数

特に断りのないかぎり、すべての引数は文字列値です。

- xref-location: 相互参照リソースのフルパスおよび名前。

- ref-column: 参照列の名前。

- ref-value: 参照列に対応する値。

- column-name: 値をルックアップする列の名前。

- need-exception: 値が見つからない場合に例外をスローするかどうかを示すブール値。trueに設定されると、この関数は値が見つからない場合に例外をスローします。それ以外は、空の値を返します。
実行時に、次の理由で例外が発生することがあります。

- 指定された名前の相互参照表が見つからない。

- 指定された列名が見つからない。

- 指定された参照値が空である。

プロパティID

- namespace-uri: http://www.oracle.com/osb/xpath-functions/xref

- namespace-prefix: xref

例

xref:lookupXRef1M('/BookSellers/XRefPublishers', 'HARPER', 'H_1500', 'PENGUIN', true())

B.1.4 markForDelete

この関数は、相互参照表内の値を削除します。この関数に渡される列の値は、XREF_DATA表から削除され、XREF_DELETED_DATA表に移動されます。削除に成功すると、trueを返します。それ以外は、falseを返します。削除後に行に残された値が1つのみの場合、相互参照が残されていないため、その値も削除されます。

この関数の詳細な説明は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の相互参照表の値の削除に関する項を参照してください。

署名

xref:markForDelete(xref-location, column, value)

引数

特に断りのないかぎり、すべての引数は文字列値です。

- xref-location: 相互参照リソースのフルパスおよび名前。

- column: 削除する値が含まれる列の名前。

- value: 削除する値。

プロパティID

- namespace-uri: http://www.oracle.com/osb/xpath-functions/xref

- namespace-prefix: xref

例

xref:markForDelete('/BookSellers/XRefPublishers', 'HARPER', 'H_1500')

B.1.5 populateLookupXRefRow

この関数は、実行されているモードに応じて、相互参照表の列に単一の値を移入します。新しい行を追加したり、既存の行にある列に値を追加するには、この関数を使用します。この関数は移入される値として文字列値を返します。populateXRefRow関数とは異なり、populateLookupXRefRow関数は同一のIDを持つレコードが同時に追加されたときに一意制約違反エラーをスローしません。かわりに、ルックアップとして動作してエラーの原因となった既存のソース値を返し、処理フローを停止しません。populateXRefRow関数の使用時に起こる同時実行性の問題を解決するには、この関数を使用します。

この関数の詳細な説明は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のxref:populateLookupXRefRow関数に関する項を参照してください。

署名

xref:populateLookupXRefRow(xref-location, ref-column, ref-value,  column, value, mode)

引数

すべての引数は文字列値です。

- xref-location: 相互参照リソースのフルパスおよび名前。

- ref-column: 参照列の名前。

- ref-value: 参照列に対応する値。

- column: 移入する列の名前。

- value: 前述の列に移入する値。

- mode: XREF移入モード。ADDまたはLINKを使用でき、すべて大文字で入力する必要があります。これらのモードの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の異なるモードでのxref:populateLookupXRefRow関数の結果に関する項を参照してください。

プロパティID

- namespace-uri: http://www.oracle.com/osb/xpath-functions/xref

- namespace-prefix: xref

例

xref:populateLookupXRefRow('/BookSellers/XRefPublishers', 'HARPER', 'H_1500', 'PENGUIN', 'PEN_2001', 'ADD')

B.1.6 populateXRefRow

この関数は、実行されているモードに応じて、相互参照表の1つまたは2つの列に単一の値を移入します。新しい行を追加したり、既存の行にある列の値を更新または追加するには、この関数を使用します。この関数は移入される値として文字列値を返します。この関数の詳細な説明は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のxref:populateXRefRow関数に関する項を参照してください。

注意:

この関数の使用時に同時実行性の問題が発生した場合は、populateLookupXRefRow関数も使用できますが、この関数は、一意制約違反につながる同時更新が行われる場合にのみ使用してください。

署名

xref:populateXRefRow(xref-location, ref-column, ref-value,  column, value, mode)

引数

すべての引数は文字列値です。

- xref-location: 相互参照リソースのフルパスおよび名前。

- ref-column: 参照列の名前。

- ref-value: 参照列に対応する値。

- column: 移入する列の名前。

- value: 前述の列に移入する値。

- mode: XREF移入モード。ADD、LINKまたはUPDATEを使用でき、すべて大文字で入力する必要があります。これらのモードの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のxref:populateXRefRow関数のモードに関する項を参照してください。

プロパティID

- namespace-uri: http://www.oracle.com/osb/xpath-functions/xref

- namespace-prefix: xref

例

xref:populateXRefRow('/BookSellers/XRefPublishers', 'HARPER', 'H_1500',   'PENGUIN', 'PEN_2001', 'ADD'

B.1.7 populateXRefRow1M

この関数は、実行されているモードに応じて、相互参照表の列に複数の値を移入します。新しい行を追加したり、既存の行にある列に複数の値を追加するには、この関数を使用します。1つの外部システムにある2つの値が、別のシステムの単一の値に対応します。そのような例では、この関数を使用して相互参照列に値を移入します。この関数は移入される相互参照値として文字列値を返します。

この関数の詳細な説明は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のxref:populateXRefRow1M関数に関する項を参照してください。

署名

xref:populateXRefRow1M(ref-location, ref-column, ref-value, column, value, mode)

引数

すべての引数は文字列値です。

- xref-location: 相互参照リソースのフルパスおよび名前。

- ref-column: 参照列の名前。

- ref-value: 参照列に対応する値。

- column: 移入する列の名前。

- value: 前述の列に移入する値。

- mode: XREF移入モード。ADDまたはLINKを使用でき、すべて大文字で入力する必要があります。これらのモードの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の異なるモードでのxref:populateXRefRow1M関数の結果に関する項を参照してください。

プロパティID

- namespace-uri: http://www.oracle.com/osb/xpath-functions/xref

- namespace-prefix: xref

例

xref:populateXRefRow1M(/BookSellers/XRefPublishers', 'HARPER', 'H_1500', 'PENGUIN', 'PEN_2001', 'LINK'

B.2 ドメイン値マップ関数

ドメイン値マップを使用すると、同一エンティティを説明するために異なるドメインで使用される用語をマップでき、1つのドメインで使用される特定のフィールドの値は、他のドメインで使用される同一フィールドの値にマップされます。たとえば、アプリケーション間で国コードや都道府県コードをマップできます。ドメイン値マップはルックアップ表に格納され、ドメイン値マップXPath関数を使用して、表内のデータをルックアップできます。

ドメイン値マップの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のドメイン値マップ関数の使用に関する項を参照してください。Service Busの相互参照の詳細は、「ドメイン値マップでのデータのマッピング」を参照してください。

B.2.1 参照

この関数は、ソース列に指定のソース値を含むドメイン値マップのターゲット列の値をルックアップして文字列を戻します。

署名

dvm:lookup(dvm-location, src-column, src-value, target-column, default-value)

引数

すべての引数は文字列値です。

- dvm-location: ドメイン値マップのURI。

- src-column: ソース列の名前。

- src-value: ソース値(XSLT変換のソース・ドキュメントにバインドされたXPath式)。

- target-column: ターゲット列の名前。

- default-value: 値が見つからない場合、デフォルト値を戻します。

プロパティID

- namespace-uri: http://www.oracle.com/osb/xpath-functions/dvm

- namespace-prefix: dvm

例

次の例では、CityCodes表のBOという値に対応する値を、CityNames表で検索します。一致する値が見つからない場合は、かわりにCouldNotBeFoundを戻します。

dvm:lookup ('/CityMapsDVM/cityMap','CityCodes','BO','CityNames', 'CouldNotBeFound')

B.2.2 lookupValue

この関数は、ソース列に指定のソース値を含むドメイン値マップのターゲット列の値をルックアップして文字列を戻します。修飾列および値を指定することで、このルックアップを絞り込むことができます。この関数の詳細な説明は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のドメイン値マップ関数の使用に関する項を参照してください。

署名

dvm:lookupValue(dvm-location, src-column, src-value, target-column, default-value, qualifiers[])

引数

すべての引数は文字列値です。

- dvm-location: DVMリソースのフルパスおよび名前。

- src-column: ソース列の名前。

- src-value: ソース値(XSLT変換のソース・ドキュメントにバインドされたXPath式)。

- target-column: ターゲット列の名前。

- default-value: 値が見つからない場合、デフォルト値を戻します。

- qualifier-column: 修飾子の値とともにルックアップを絞り込む列。修飾子の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の修飾子ドメインに関する項を参照してください。

- qualifier-value: 修飾子列の値。

プロパティID

- namespace-uri: http://www.oracle.com/osb/xpath-functions/dvm

- namespace-prefix: dvm

例

次の例では、CityCodes表のBOという値に対応する値を、CityNames表で検索します。State表のMassachusettsという修飾子は、市の名前をその州にのみ絞り込む場合に役立ちます。一致する値が見つからない場合は、かわりにCouldNotBeFoundを戻します。

dvm:lookupValue ('/CityMapsDVM/cityMap','CityCodes','BO','CityNames', 'CouldNotBeFound', 'State', 'Massachusetts')

B.2.3 lookupValue1M

この関数は、ソース列の値がソース値と等しいドメイン値マップの複数のターゲット列の値を含むXMLドキュメント・フラグメントを戻します。この関数を式で使用するときに、戻り値を変数に直接割り当てる場合、最初に出現したものが変数に割り当てられます。正しく割り当てるために、戻り値を繰り返す必要があります。

この関数の詳細な説明は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のドメイン値マップ関数の使用に関する項を参照してください。

署名

dvm:lookupValue1M(dvm-location, src-column, src-value, target-columns[])

引数

すべての引数は文字列値です。

- dvm-location: DVMリソースのフルパスおよび名前。

- src-column: ソース列の名前。

- src-value: ソース値(XSLT変換のソース・ドキュメントにバインドされたXPath式)。

- target-columns: ターゲット列の名前。1つ以上の列名を指定する必要があります。ターゲット列の名前は、それぞれ個別の引数として複数指定できます。

プロパティID

- namespace-uri: http://www.oracle.com/osb/xpath-functions/dvm

- namespace-prefix: dvm

例

次の例では、CityCodes表のGarden Cityという値に対応する値を、CityNames表およびCityNickNames表で検索します。

dvm:lookupValue1M ('/CityMapsDVM/cityMap','CityCodes','Garden City','CityNames', 'CityNickName')

B.3 カスタムXPath関数の作成

Service Busで提供される標準のXPath関数に加えて、式で使用するカスタムXPath関数を作成および登録できます。Service Busでは、カスタムXPath関数を作成するための充実したフレームワークが提供されます。カスタムXPath関数は、パイプライン、分割-結合、XQuery Mapper変換など、開発時や実行時のツールにおいてXQuery式エディタで使用できます。

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

- Service Busでのカスタム関数の登録

- カスタム関数のJavaクラスの作成とパッケージ化

- カスタム関数の使用

- クラスタへのカスタム関数のデプロイ

注意:

Service Busでは、データベース表の更新やグローバル・トランザクションへの参加といった二次的な動作を含むカスタム関数はサポートされません。XQuery結果のみに影響するカスタム関数を作成し、二次的な動作はJavaコールアウトなど他の機能を使用して実行してください。

B.3.1 Service Busでのカスタム関数の登録

カスタム関数は、WebLogic Serverドメイン内のService Busのすべてのプロジェクトとサービスで使用できます。カスタム関数を登録するには、XMLファイル(およびローカライズ用のオプション・プロパティ・ファイル)を作成する必要があります。Service Bus提供の組込み関数はこの関数フレームワークが使用されるため、このような既存の登録リソースをガイドとして使用できます。これらのファイルは次のディレクトリにあります。

/service_bus_home/config/xpath-functions

Service Busの関数ファイルはosb-built-in.xmlです。このファイルでは、%記号で囲まれたキー(%OSB_FUNCTIONS%など)は対応する.propertiesファイルから値を取得します。新しいドメインにカスタム関数を拡張するには、次の場所にある新しいドメインに登録ファイル(XMLファイルとプロパティ・ファイル)をコピーする必要があります。

/domain_home/config/osb/xpath-functions

xpath-functionsサブディレクトリを作成する必要があります。

カスタム関数登録ファイルの基本構造の概要は次のとおりです。その後で要素について説明します。

category id
group id
function
name
comment
namespaceURI
className
method
isDeterministic
scope

要素にはxpf:接頭辞が付きます。

次の表では、カスタム登録ファイルの各要素を示して説明します。

表B-1 カスタム関数登録ファイルのプロパティ

要素

説明

カテゴリ

式エディタで一連の関数を物理的に分類する、Service Bus Functionsなどのグループ。id属性を使用して名前を指定します。ローカライズのために対応する.propertiesファイルを使用する場合は、テキスト値を含むキーをpropertiesファイルに入力します(例: %MY_FUNCTIONS%)。category id(プロパティ・ファイルのキー名と実際のnameの値を含む)は一意であることが必要です。

グループ

ユーザー・インタフェースで関数をグループ化するためのサブカテゴリ(General、Accessorsなど)。id属性を使用して名前を指定します。category idのネーミング・ルールはgroup idにも適用されます。group要素はオプションです。

名前

XQuery式に表示される関数の名前。namespaceURIと接頭辞を含む関数名は、一意であることが必要です。Service Busでは異なるメソッド引数でオーバーロードする関数はサポートされません。関数名が同一でもネームスペースが異なっていれば(つまり接頭辞が異なっていれば)使用できます。

コメント

関数の説明。説明はService Busユーザー・インタフェースには表示されませんが、関数の呼出し方法やわかりやすい引数の名前を示すように指示を指定できます。

namespaceURI

関数のネームスペース。たとえば、Service Busの関数ネームスペースはhttp://www.bea.com/xquery/xquery-functionsです。ネームスペースとネームスペース接頭辞は一意であることが必要です。指定するカスタム・ネームスペースは、XQueryエディタのデフォルト・ネームスペース・リストに表示されます。

className

関数を実装する、完全修飾されたカスタムJavaクラス。

method

前に戻り型を指定する、関数を実装するカスタムJavaメソッド(例: boolean isUserInGroup(java.lang.String, java.lang.String))。

メソッドが一次元配列を使用する場合は、XMLファイルにエントリを作成する方法について「一次元配列の使用」を参照してください。

isDeterministic

関数が決定的かどうかを宣言するtrueまたはfalseの値。決定的関数は常に同じ結果を返します(たとえば、文字列を連結する関数)。非決定的関数は一意の結果を返します(たとえば、時刻を返す関数)。非決定的関数を使用できますが、XQuery標準では、XQueryエンジンの最適化を保証するために決定的関数の作成が推奨されています。

scope

関数を適用するService Busリソースのタイプ(Pipeline、SplitJoinなど)。複数の範囲要素を定義できます。

B.3.2 カスタム関数のJavaクラスの作成とパッケージ化

カスタム関数が式エディタに表示されるのは、Service Busがカスタム・クラスを検出できるようになってからです。次のガイドラインに従って、Service Busで検索および使用できるよう、カスタムXPath関数のクラスを作成してパッケージ化します。

- クラスとメソッドの作成

- カスタム関数クラスのパッケージ化

B.3.2.1 クラスとメソッドの作成

次のガイドラインに従って、カスタム関数のJavaクラスとメソッドを作成します。

- クラス: クラスはパブリックであることが必要です。

- メソッド: メソッドはパブリックかつ静的であることが必要です。

- 引数および戻り値: 次の表に、メソッドの引数と戻り値でサポートされる型を示します。この表に含まれない型はサポートされません。内部クラスおよび多次元配列はサポートされません。

表B-2 カスタム関数でサポートされるJavaメソッドの型

Java型

XQuery型

XSLTの型

java.lang.String

xs:string

string

int、java.lang.Integer

xs:int

number

boolean、java.lang.Boolean

xs:boolean

boolean

long、java.lang.Long

xs:long

number

short、java.lang.Short

xs:short

number

byte、java.lang.Byte

xs:byte

number

double、java.lang.Double

xs:double

number

float、java.lang.Float

xs:float

number

char、java.lang.Char

xs:string

object

java.math.BigInteger

xs:integer

number

java.math.BigDecimal

xs:decimal

number

java.util.Date

xs:datetime

脚注脚注1を参照してください。

java.sql.Date

xs:date

脚注を参照してください。

java.sql.Time

xs:time

脚注を参照してください。

javax.xml.namespace.QName

xs:Qname

脚注を参照してください。

org.apache.xmlbeans.XmlObject

element()

脚注を参照してください。

org.w3c.dom.Element

element()

XSLTのnode-set型はカスタムXPath関数ではサポートされません。

脚注1

文字列に変換されてから、元のタイプとして戻されます。

B.3.2.1.1 1次元配列の使用

1次元配列(サポート対象のJavaの型を使用)が、アスタリスク(*)を使用して、対応するXQueryの型にマップされます(アスタリスクは、配列の複数のカーディナリティを暗黙に指定するワイルドカードです)。次に例を示します。

public static XmlObject[] getArrayOfXmlObjects(XmlObject[] a)

これが次の型にマップされます。

namespace:getArrayOfXmlObjects($arg1 as element()*) as element()*

1次元配列の入力引数または戻り値を含む関数のシグネチャでは、http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getName%28%29で説明されている型のエンコーディングを使用する必要があります。次の例は、カスタム関数XMLファイルで、必要な配列エンコーディングを使用して1次元配列のメソッドを指定する方法を示します。

Javaメソッド

カスタム関数XMLファイルでの入力

public static String[] myUppercaseStringArray(String[] arg)

Ljava.lang.String; myUppercaseStringArray([Ljava.lang.String;)

public static int[] myAddInts(int[] arg)

[I myAddInts([I)

B.3.2.2 カスタム関数クラスのパッケージ化

カスタム関数をXQueryエディタに組み込んで使用するためには、Service Busがそれらのカスタム関数を認識する必要があります。カスタム関数クラスをJARファイルにパッケージ化し、そのJARを次のいずれかのディレクトリに置きます。

- service_bus_home/config/xpath-functions/

- domain_home/config/osb/xpath-functions/

service_bus_homeはService Busがインストールされている場所を、domain_homeはService Busドメインがインストールされているディレクトリを表します。

IDEおよびサーバーの起動時に、Service Busは、これらのディレクトリのカスタム関数クラスから使用可能なカスタム関数を検索します。「Service Busでのカスタム関数の登録」に従って、カスタム関数のXMLファイルでカスタム・クラスおよびメソッドを正しく参照してください。

新しいカスタム関数を追加したら、IDEと新しい関数を使用するすべてのサーバーを再起動する必要があります。

B.3.3 カスタム関数の使用

ここでは、Service BusのXQuery式およびリソースでカスタム関数を使用する方法について説明します。

- インラインXQuery式およびXQueryリソースでのカスタム関数

- XSLTリソースでのカスタム関数

B.3.3.1 インラインXQuery式およびXQueryリソースでのカスタム関数

Service Bus提供の関数と同様に、インラインXQuery式とXQueryリソースの両方にカスタム関数を含めることができます。

B.3.3.2 XSLTリソースでのカスタム関数

XSLTリソース内からカスタム関数を呼び出すための構文は、Service Busで使用するXSLTエンジンによって異なります。次のカスタム関数コードを考えると、次に示すXalanエンジンを使用してカスタム関数を呼び出すための構文の例は、Xalan XSLTエンジン(Oracle JDK対応のMicrosoft Windowsでのデフォルト)を使用してカスタム関数を呼び出す構文を示します。

package tests.pipeline;
public class CustomXQFunctions
{
public static String myUppercaseString(String arg)
{
return arg.toUpperCase();
}
}

例 - Xalanエンジンを使用してカスタム関数を呼び出すための構文

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"   version="1.0">
<xsl:param name="arg-string"/>
<xsl:template name="myUppercaseString"
xmlns:ns0="xalan://tests.pipeline.CustomXQFunctions">
<xsl:variable name="upcase" select="ns0:myUppercaseString($arg-string)" />
<originalInput>
<xsl:value-of  select="$arg-string" />
</originalInput>
<result>
<xsl:value-of select="$upcase" />
</result>
</xsl:template>
<xsl:template match="*">
<xsl:copy>
<xsl:call-template name="myUppercaseString"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>

入力ドキュメントが<example />、入力arg-stringの値がhelloの場合、変換は次のように行われます。

<example>
<originalInput>hello</originalInput>
<result>HELLO</result>
</example>

B.3.4 クラスタへのカスタム関数のデプロイ

複数のOracle Fusion Middleware製品のホームがある複数サーバー環境では、カスタム関数が使用される環境ごとにすべてのカスタム関数リソースを手動で追加する必要があります。クラスタリングによって、すべての管理対象サーバーにカスタム関数リソースが自動的に配布されるわけではありません。

C Oracle Service Bus API

この付録では、リソースの更新とカスタマイズ、リソースのデプロイメントおよびそれらのリソースのランタイムでの管理とモニターのためのService Bus APIの概要を説明します。Service Busでは、リソースのカスタマイズ、モニター・データへの外部アクセスおよびデプロイメントを可能にするAPIを公開しています。

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

- リソースの更新とカスタマイズ

- 管理およびモニター

- デプロイメント

Oracle Service Bus APIのJavadocは、Oracle Service Bus Java APIリファレンスで提供されています。

C.1 リソースの更新とカスタマイズ

プログラムのインタフェースを使用して、サービス定義、WSDLドキュメント、スキーマ、XQueryなどの設計時リソースをカスタマイズできるように様々なAPIが公開されています。サポートAPIにより、リソース、フォルダ、およびプロジェクトの移動、名前変更、クローン作成、削除に加え、リソースが含まれているZIPファイルをロードすることもできます。一般的な使用例として、プロトタイプとなるプロキシ・サービスから複数のコピーを作成し、各コピーをプログラムによって変更することがあげられます。

デプロイメント時に様々なカスタマイズ・オプションを適用できます。たとえば、環境変数を使用すると、別の環境に移行する際に設定を保持したり調整することができます。

次のAPIを使用できます。

- ProxyServiceConfigurationMBean: プロキシ・サービスの有効化と無効化およびプロキシ・サービスのモニターの有効化と無効化

- BusinessServiceConfigurationMBean: ビジネス・サービス、ビジネス・サービスのモニター、スロットル、オフラインURIおよび結果キャッシュのモニターの有効化と無効化、およびUDDIレジストリからのサービスのデタッチ

- PipelineServiceConfigurationMBean: パイプラインのパイプライン・アラートおよびSLAアラートの有効化と無効化

- CommonServiceConfigurationMBean: ビジネス・サービスまたはプロキシ・サービスの有効化と無効化、およびメッセージ・トレースの有効化と無効化

- FlowServiceConfigurationMBean: SLAアラートおよび分割結合のモニターの有効化と無効化、

- ALSBConfigurationMBean:次のタスクの実行によるService Busドメイン内のリソースの管理

- Queryリソース、エクスポート・リソース、およびインポート・リソース

- 検証エラーの取得

- 環境値の取得と設定

- リソース内の参照の新しい参照への変更

- リソースの移動、名前変更、クローン作成、および削除

- ResultCacheRuntimeMBean: 単一エントリの削除、および特定のビジネス・サービスに属する全エントリの削除による結果キャッシュの管理。

- Customization: 次のタスクの実行によるService Busランタイムのカスタマイズ

- 環境値の検索と置換

- 環境値の割当て

- リソース内の参照の別の参照へのマップ

C.2 管理およびモニター

Oracle Service BusのJMXモニタリングAPIは、モニター・データへの外部アクセスを提供します。実装には、Java Management Extensions (JMX)テクノロジが使用されています。ドメイン内のService Busリソースは、JMXの管理対象Bean (MBean)を使用して管理機能を公開します。MBeanは、JMX仕様に従って開発されたJavaの具象クラスです。

詳細は、『Oracle Service Busの管理』のJMXモニターAPIに関する項を参照してください。

C.3 デプロイメント

Service Bus MBeansをJavaプログラムおよびWLSTスクリプトで使用すると、開発環境からテスト環境、ステージング環境を経て、最終的に本番環境に至るまで、Service Bus構成のプロモーションを自動化できます。デプロイメント時に様々なカスタマイズ・オプションを適用できます。たとえば、環境変数の拡張リストを使用すると、別の環境に移行する際に設定を保持したり調整することができます。

詳細は、『Oracle Service Busの管理』のデプロイメントAPIの使用に関する項を参照してください。

D トランスポートSDKのインタフェースおよびクラス

この付録では、Service BusトランスポートSDKで提供されるクラスおよびインタフェースを示し、それらについて簡単に説明します。

カスタム・トランスポート・プロバイダの開発に必要なインタフェースの詳細は、「カスタム・トランスポート・プロバイダの開発」を参照してください。

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

- はじめに

- スキーマで生成されるインタフェース

- 汎用クラスおよびインタフェース

- SourceおよびTransformerクラスとインタフェース

- リクエストおよびレスポンス・メッセージのメタデータおよびヘッダーの表現

- ユーザー・インタフェースの構成

D.1 はじめに

この章で説明されているトランスポートSDKクラスおよびインタフェースは、特に記載のないかぎり、OSB_ORACLE_HOME/lib/modules/oracle.servicebus.kernel-api.jarにあります。OSB_ORACLE_HOMEは、Service Busをインストールした場所です。

クラスとメソッドの詳細は、Oracle Service Bus Java APIリファレンスを参照してください。

D.2 スキーマで生成されるインタフェース

トランスポートSDKインタフェースの多くは、XMLスキーマ・コンパイラ・ツールによってXMLスキーマから生成されます。次のインタフェースのソース(XMLスキーマ)は、ファイルTransportCommon.xsdで提供されています。このファイルは、サービス・エンドポイントの構成用の基本となるスキーマ定義ファイルです。このファイルは、OSB_ORACLE_HOME/lib/modules/oracle.servicebus.kernel-api.jarにあります。

スキーマで生成されるインタフェースは次のとおりです。

- EndPointConfiguration: エンドポイント構成のベース・タイプ。エンドポイントは、メッセージの送信元または送信先となるService Busリソースです。EndPointConfigurationは、インバウンド・エンドポイントまたはアウトバウンド・エンドポイントのデプロイメントおよび操作に必要なパラメータ一式を示します。

- RequestMetaDataXML: インバウンド・リクエストまたはアウトバウンド・リクエストのメタデータの基本型。メタデータは、メッセージのペイロードに含まれず、個別に送信され、メッセージを処理するためのコンテキストとして使用されます。メタデータとして送信できる情報の例には、Content-Typeヘッダー、セキュリティ情報、ロケール情報などがあります。

- RequestHeadersXML: 一連のインバウンドまたはアウトバウンド・リクエスト・ヘッダーの基本型。

- ResponseMetaDataXML: インバウンド・メッセージまたはアウトバウンド・メッセージのレスポンス・メタデータの基本型。

- ResponseHeadersXML: 一連のレスポンス・ヘッダーの基本型。

- TransportProviderConfiguration: このプロバイダが(a)エンドポイントのサービスの説明(WSDLなど)を生成するかどうか、(b)インバウンド(プロキシ)エンドポイントをサポートするかどうか、または(c)アウトバウンド(ビジネス・サービス)エンドポイントをサポートするかどうかを構成できます。

D.3 汎用クラスおよびインタフェース

この項では、独自のカスタム・トランスポートの開発時に使用する、汎用トランスポートSDKクラスおよびインタフェースの概要を説明します。ここで説明する各クラスおよびインタフェースの詳細は、Oracle Service Bus Java APIリファレンスを参照してください。

- 汎用クラスのサマリー

- 汎用インタフェースのサマリー

D.3.1 汎用クラスのサマリー

TransportManagerHelperクラス: クライアントがトランスポート・サブシステムに関する一部の一般的なタスクを実行できるようにするヘルパー・クラス。

ServiceInfoクラス: トランスポートの構成およびバインディング・タイプなどのサービスについての情報を示すラッパー・クラス。

TransportOptionsクラス: メッセージの送受信に関するオプションを提供します。TransportOptionsには、複数行セットアップおよび単一行使用の2つの使用スタイルがあります。

EndPointOperationsクラス: トランスポート・プロバイダへの通知を行う、様々なタイプのトランスポート・エンドポイントのライフサイクル関連のイベントについて説明します。ネストされたクラスには、CommonOperation、Create、Delete、EndPointOperationTypeEnum、Resume、SuspendおよびUpdateがあります。

Refクラス: 構成システムで管理されるリソース、プロジェクトまたはフォルダを一意に表します。このクラスは、OSB_ORACLE_HOME/lib/modules/oracle.servicebus.configfwk.jarにあります。

TransportValidationContextクラス: エンドポイント構成の検証チェックを実装する際に使用できる情報をトランスポート・プロバイダに提供するコンテナ。

Diagnosticsクラス: 特定のリソースに関連するDiagnosticエントリの集合が含まれます。このクラスは、OSB_ORACLE_HOME/lib/modules/oracle.servicebus.configfwk.jarにあります。

Diagnosticクラス: リソースに関連する特定の検証メッセージを表します。Diagnosticオブジェクトは、リソースに変更があった際に実行される検証の結果として生成されます。このようなシステム内の変更は、変更されたリソース、および変更されたリソースに(過渡的に)依存するその他のすべてのリソースの検証をトリガーします。このクラスは、OSB_ORACLE_HOME/lib/modules/oracle.servicebus.configfwk.jarにあります。

NonQualifiedEnvValueクラス: 構成データ内にある環境依存の値のインスタンスを表します。通常、環境依存の値は、あるドメインから別のドメインに構成が移動された場合に変わります。たとえば、サービスのURIは、テスト・ドメインと本番ドメインで異なる場合があります。このクラスは、OSB_ORACLE_HOME/lib/modules/oracle.servicebus.configfwk.jarにあります。

D.3.2 汎用インタフェースのサマリー

TransportManagerインタフェース: 様々なトランスポート・プロバイダの管理、エンドポイントの登録、制御、インバウンド・メッセージおよびアウトバウンド・メッセージの処理などを一元化するための主要ポイントを提供するシングルトン・オブジェクト。

TransportProviderインタフェース: 転送プロトコル固有の構成および実行時プロパティの中心的な管理ポイントを表します。サポートされているプロトコルごとに、TransportProviderの単一のインスタンスが存在します。たとえば、HTTPトランスポート・プロバイダやJMSトランスポート・プロバイダなどに、それぞれ単一のインスタンスが存在します。

BindingTypeInfoインタフェース: サービスのバインディングの詳細について説明します。実装は、Service Busの複数の内部構造を包むコンビニエンス・ラッパー・クラスです。トランスポート・プロバイダの必要に応じて他のメソッドを追加できます。

TransportWLSArtifactDeployerインタフェース: Service Busのデプロイメントとともに、Oracle WebLogic Server関連のアーティファクトをデプロイ、アンデプロイまたは変更する必要があるモジュール用のプラグイン・インタフェース。たとえば、場合によっては、サービスの作成に応じてOracle WebLogic Serverのキューをデプロイする必要があります。

ヒント:

詳細は、「TransportWLSArtifactDeployerの実装が適している場合」を参照してください。

SelfDescribedTransportProviderインタフェース: TransportProviderを拡張します。任意のトランスポート・エンドポイントからサービスのバインディング・タイプについての説明を生成するトランスポート・プロバイダは、このインタフェースを実装する必要があります。この例としては、EJBトランスポート・プロバイダがあります。

SelfDescribedBindingTypeInfoインタフェース: EJBサービスなどの自己記述型のサービスのBindingTypeInfoインタフェースを拡張します。

WsdlDescriptionインタフェース: 登録されているService Busサービスに関連付けられているWSDLドキュメントについて説明します。

TransportCustomBindingProviderインタフェース: WSDLベースのトランスポートのための効果的なWSDLドキュメントの生成中に使用される、SOAPバインディングの拡張可能要素またはカスタムService Busバインディングのすべての要素の生成を促進するためのクラスを表します。<soap:binding>要素のトランスポートURIや、<soap:address>のロケーション属性などの情報が含まれます。

ServiceTransportSenderインタフェース: トランスポート・エンドポイントに関連付けられている登録済のサービスにアウトバウンド・メッセージを送信します。TransportProvider.sendMessageAsync()は、プロバイダがアウトバウンド・リクエストのペイロードおよびメタデータを取得できるServiceTransportSenderのインスタンスを取得します。このインタフェースは、TransportSenderを拡張します。

CredentialCallbackインタフェース: トランスポート・プロバイダは、Service Busからこのコールバック・インタフェースのインスタンスを取得します。トランスポート・プロバイダは、そのメソッドを呼び出して、アウトバウンド認証に使用する資格証明を取得できます。

TransportEndPointインタフェース: トランスポート・エンドポイントは、サービス・メッセージの送信元または送信先となるService Busのエンティティまたはリソースです。

D.4 SourceおよびTransformerクラスとインタフェース

この項では、SourceおよびTransformerの基本インタフェース、Service Busで提供される具体的なSources、およびサポート・クラスについて説明します。詳細は、「メッセージ・コンテンツの設計」を参照してください。

- SourceおよびTransformerインタフェースの概要

- SourceおよびTransformerクラスの概要

D.4.1 SourceおよびTransformerインタフェースの概要

Sourceインタフェース: 任意の形式のソース・コンテンツを表します。Sourcesは、Transformerインスタンスを介して他のSourcesに変換できます。Sourceは、少なくとも、このインタフェースで定義されている2つのメソッドを使用して、バイトベースのストリームへの変換をネイティブにサポートする必要があります。Sourceでは、シリアライゼーション中に文字セット・エンコーディングなどの様々なTransformOptionsを考慮することもできます。

SingleUseSourceインタフェース: あるタイプのSourceが1回にかぎり使用できることを示すマーカー・インタフェース。Sourceがまだ使用できる(有効)かどうかを判断するために使用できる1つのヘルパー・メソッドも提供します。

Sourceインタフェースを実装するSourceクラスを作成する場合、Service Busは、最初から入力ストリームを取得するたびに複数回getInputStream()メソッドをコールできます。SourceクラスがSingleUseSourceを実装する場合、Service Busは、getInputStream()を1回のみコールします。ただし、この場合、Service Busは、メッセージ全体をメモリーにバッファします。

Transformerインタフェース: あるタイプのSourceを別のタイプに変換します。このインスタンスは、どのタイプのソース間で変換できるかを示します。サポートされる入力ソースおよび出力ソースによって示される完全な製品間トランスフォーメーションをサポートするには、トランスフォーマが必要です。つまり、トランスフォーマは、サポートされるすべての入力ソースを、サポートされるすべての出力ソースに変換できる必要があります。

D.4.2 SourceおよびTransformerクラスの概要

StreamSourceクラス: InputStreamからコンテンツを読み込むバイトストリームSource。バイト・ストリームSourceであるため、シリアライゼーション・メソッドはトランスフォーメーションのオプションを考慮しません。

注意:

このストリームはInputStreamによってバックアップされるため、1回のみ使用するSourceとなります。両方のシリアライゼーション・メソッドは、基底の同じInputStreamから取得され、そのコンテンツは1度使用すると、失われます。エラーが発生しないことを前提とした場合、プッシュ・ベースのwriteTo()メソッドによりすべてのデータが即時に使用されます。プルベースのgetInputStream()は、実際に基底のInputStreamをコール元に直接提供します。

ByteArraySourceクラス: バイト配列からコンテンツを読み込むバイトストリームSource。バイト・ストリームSourceであるため、シリアライゼーション・メソッドはトランスフォーメーションのオプションを考慮しません。

StringSourceクラス: 単一のStringによってバックアップされるSource。シリアライゼーションは、単に、文字セット・エンコーディングが設定された文字データです。

XmlObjectSourceクラス: Apache XBeanのSourceコンテンツはApache XBeanとして表されます。XBeanは、型付きであるため、SchemaTypeオブジェクトおよび関連するClassLoaderが付随する場合があります。ただし、これらはどちらも省略可能であり、XBeanを型なしのXMLにすることもできます。

DOMSourceクラス: そのコンテンツがDOMノードに由来するSource。参照されるノードは、独立したorg.w3c.dom.Documentである場合も、より大きなドキュメント内の内部ノードである場合もあります。

MFLSourceクラス: MFLコンテンツを表します。MFLデータは、基本的には、MFL定義によって論理構造が指定されたバイナリ・データです。CSVはMFLデータの簡単な例ですが、構造は任意に複雑になる場合もあります。データの論理的表現およびメモリー内表現は、XMLドキュメントですが、シリアライズされた表現は構造化されていない生のバイナリ・データです。

SAAJSourceクラス :SAAJ SOAPMessageオブジェクトによってバックアップされるSource。通常、SAAJSourceは、MessageContextSourceおよびMimeSourceとの間で変換されます。

MimeSourceクラス: ヘッダーを持つ任意のコンテンツを示すSource。基本的に、これはMIMEパートを表すSourceです。ヘッダーはRFC822に準拠する必要がありますが、Sourceは任意のタイプにできます。このSourceのシリアライゼーション形式は、完全準拠のMIMEパッケージです。このSourceは、Content-Transfer-Encodingにも対応しており、ヘッダーがある場合、基底のコンテンツ・ストリームを適切にエンコードします。これは、コンストラクタに提供されているSourceが、まだエンコードされておらず、生の形式である必要があることを意味しています。

MessageContextSourceクラス: すべてのメッセージ・コンテンツを示すSource。メッセージと添付のSourceは、後で処理できるように型なしのままになっています。ただし、最終的に、添付ソースの多くはオブジェクトに変換され、メッセージ・ソースの多くは、XmlObjectSourceやStringSourceなどの特定の型付きのソースに変換されます。

注意:

MessageContextSourceのシリアライゼーション形式は、メッセージ・ソースおよび添付ソースのネイティブのシリアライゼーションにかかわらず、MIME multipart/relatedパッケージです。ただし、シリアライズされたオブジェクトが複数回必要な場合は、SourceをMimeSourceに変換する方法が最適です。

TransformOptionsクラス: 一連の変換オプションを表します。このクラスのインスタンスは、Transformerクラスと併せて使用され、入力ソースの出力ソースへの変換方法に影響を及ぼします(たとえば、SHIFT_JISからEUC-JPへの文字セット・エンコーディングの変更など)。このクラスは、SourceインタフェースのInputStreamメソッドおよびOutputStreamメソッドでも使用されます。これは、事実上この使用方法が、 InputStreamおよびOutputStreamにおけるSourceとバイトレベルの表現との変換でもあるためです。

JavaObjectSourceクラス: Javaメッセージング・タイプを提供するService Busトランスポート(JMSトランスポートなど)で送信されるペイロードを表します。このペイロードに含まれるオブジェクトは、バインディング・レイヤーによってパイプラインのJavaオブジェクト・リポジトリに登録されます。そのコンテンツは、<ctx:java-content ref='jcid:xyz' xmlns:ctx="http://www.bea.com/wli/sb/context" /> XML要素を介してメッセージ・コンテキスト変数で表示できます。この例では、refは、Javaオブジェクト・リポジトリにあるオブジェクトの一意のIDを指します。

JavaXmlSourceクラス: 引数としてJavaオブジェクトをサポートするサービス(JEJBトランスポートなど)によって送信されるペイロードを表します。JavaXmlSourceは、パイプラインのメッセージ本文の形式を定義するXML表現と、一意のキーに対してJavaオブジェクトを含むマップで構成されます。このXML表現で、Javaオブジェクト引数は<ctx:java-content ref='jcid:xyz' xmlns:ctx="http://www.bea.com/wli/sb/context" />要素で代入され、このref属性は、置換されるJavaオブジェクトの索引として機能するJavaObjectsマップのキーと等しくなります。このマップには、XML表現の一意IDに対して、パイプラインJavaオブジェクト・リポジトリに登録されるオブジェクトが含まれます。

D.5 リクエストおよびレスポンス・メッセージのメタデータおよびヘッダーの表現

ここでは、リクエスト・メッセージおよびレスポンス・メッセージのメタデータ表現を処理するクラスおよびインタフェースを示します。詳細は、「メッセージの処理」および「メッセージ・コンテンツの設計」を参照してください。

- メッセージ・コンテンツの実行時表現

- インタフェース

D.5.1 メッセージ・コンテンツの実行時表現

CoLocatedMessageContext抽象クラス: トランスポート・レイヤーのかわりにJavaメソッド・コールを実行するために、同じ場所に配置されているアウトバウンド・コールの最適化を実装するトランスポート・プロバイダによって拡張される必要があります。実装の例は、com.bea.alsb.transports.sock.SocketCoLocatedMessageContext.javaクラスを参照してください。このクラスは、「サンプル・ソケット・トランスポート・プロバイダの作成」で説明されているサンプル・ソケット・トランスポートに組み込まれています。詳細は、「同じ場所に配置された呼出し」を参照してください。

RequestHeaders抽象クラス: 任意のインバウンド・リクエスト・メッセージまたはアウトバウンド・リクエスト・メッセージの、標準およびユーザー定義のヘッダーのユニオンを表します。一連の標準ヘッダーは、各トランスポート・プロバイダに固有です。これは、それぞれのバージョンのリクエスト・ヘッダーを実装するために、各トランスポート・プロバイダによって拡張される必要のある抽象クラスです。

RequestMetaData<T extends RequestHeaders>抽象クラス: インバウンド・リクエスト・メッセージまたはアウトバウンド・リクエスト・メッセージのメタデータ情報(ヘッダー、リクエストの文字セット・エンコーディングなど)を表します。トランスポート・プロバイダは、トランスポート・プロバイダに応じたメタデータ情報を追加する、このクラスの拡張を提供します。たとえば、HTTPトランスポート・プロバイダは、get/setQueryString()メソッド、get/setClientHost()メソッドおよびその他のメソッドを追加します。

ResponseHeaders抽象クラス: 任意のインバウンド・レスポンス・メッセージまたはアウトバウンド・レスポンス・メッセージの、標準およびユーザー定義のヘッダーのユニオンを表します。一連の標準ヘッダーは、各トランスポート・プロバイダに固有です。これは、それぞれのバージョンのレスポンス・ヘッダーを実装するために、各トランスポート・プロバイダによって拡張される必要のある抽象クラスです。

ResponseMetaData<T extends ResponseHeaders>抽象クラス: インバウンド・レスポンス・メッセージまたはアウトバウンド・レスポンス・メッセージのメタデータ情報(ヘッダー、リクエストの文字セット・エンコーディングなど)を表します。トランスポート・プロバイダは、トランスポート・プロバイダに応じたメタデータ情報を追加する、このクラスの拡張を提供します。たとえば、HTTPトランスポート・プロバイダは、get/setHttpResponseCode()メソッドおよびその他のメソッドを追加します。

D.5.2 インタフェース

TransportMessageContextインタフェース: ほとんどのメッセージ指向ミドルウェア(MOM)製品は、メッセージをヘッダーとペイロードで構成される軽量エンティティとして処理します。ヘッダーにはメッセージのルーティングおよび識別情報に使用されるフィールドが含まれ、ペイロードには送信中のアプリケーション・データが含まれます。通常、トランスポート・レベルのメッセージ・コンテキストは、メッセージID、RequestMetadata、リクエスト・ペイロード、ResponseMetaData、レスポンス・ペイロードおよび関連プロパティで構成されます。

InboundTransportMessageContextインタフェース: 着信メッセージのメッセージ・コンテキストの抽象化を実装します。

OutboundTransportMessageContextインタフェース: 送信メッセージのメッセージ・コンテキストの抽象化を実装します。

ServiceTransportSenderインタフェース: 登録済のサービスにアウトバウンド・メッセージを送信します。サービスは、トランスポート・エンドポイントに関連付けられています。

TransportSendListenerインタフェース: これは、アウトバウンド・トランスポートに提供されるコールバック・オブジェクトで、システムにレスポンス処理を進めることができることを通知できるようにします。このコールバック・オブジェクトは、リクエスト・メッセージとは別のスレッドで呼び出す必要があります。

D.6 ユーザー・インタフェースの構成

各トランスポート・プロバイダは、永続化するサービス・エンドポイント固有の構成プロパティのリストを決定できるため、ユーザーが新しいサービス・エンドポイントごとのトランスポート固有の構成プロパティを入力できる、柔軟なユーザー・インタフェースが必要です。この項で説明する一連のクラスおよびインタフェースにより、各トランスポート・プロバイダは、Oracle Service Busコンソールのサービス定義エディタの一環としてユーザーが入力するための独自のプロパティを公開できます。新しいトランスポートのユーザー・インタフェースを開発するには、これらのインタフェースおよびクラスを使用します。

- UIインタフェースのサマリー

- UIクラスのサマリー

D.6.1 UIインタフェースの概要

TransportProviderFactoryインタフェース: このインタフェースは、新しいトランスポート・プロバイダを転送マネージャに登録します。

TransportUIBindingインタフェース: サービスの定義、サマリーの提供およびトランスポート・プロバイダ固有のエンドポイントの構成の検証で使用される、プロバイダ固有のUIページを表示するオブジェクトを表します。

CustomHelpProviderインタフェース:Oracle Service Busコンソールに追加する、カスタム・トランスポートなどの機能の状況依存ヘルプを提供できます。実装の詳細は、「カスタム・トランスポートのヘルプの作成」を参照してください。

D.6.2 UIクラスの概要

TransportUIContextクラス: トランスポート・プロバイダ固有のユーザー・インタフェース部分のオプションを提供します。Oracle Service Busコンソールによって各トランスポート・プロバイダに渡されます。

TransportUIGenericInfoクラス: サービス定義エディタでの、共通のトランスポート・ページのトランスポート固有のUI情報を保持します。

TransportUIFactoryクラス: トランスポートの変更フィールドおよびフィールドに関連付けられている様々なTransport UIオブジェクトを作成するファクトリ・メソッドを提供します。これらのオブジェクト内の値にアクセスするためのヘルパー・メソッドも提供します。

TransportEditFieldクラス: Oracle Service Busコンソールのサービス登録エディタのプロバイダ固有の部分で、編集可能な単一のUI要素を表します。

TransportViewFieldクラス: 「サービス・サマリー」ページのプロバイダ固有の部分で、読取り専用の単一のUI要素を表します。

TransportUIErrorクラス: Oracle Service Busコンソールに検証エラーを返します。

E トランスポートSDK UMLシーケンス・ダイアグラム

この付録では、UMLシーケンス・ダイアグラムを示し、Service Busランタイムを使用したメソッド・コールのフローについて説明します。

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

- Service Busランタイムのインバウンド・メッセージ

- Service Busランタイムのアウトバウンド・メッセージ

- 設計時のサービスの登録

E.1 Service Busランタイムのインバウンド・メッセージ

図E-1のシーケンス・ダイアグラムに、Service Busランタイムでのインバウンド・メッセージのフローを示します。

最初に、HTTP Servletなどのインバウンド・アーティファクトが、クライアント・リクエストを受け取ります。トランスポート・プロバイダが、InboundTransportMessageContextと呼ばれるデータ構造を作成します。メッセージ・コンテキストが、リクエストのヘッダーをメタデータ・オブジェクトにパッケージ化し、HTTPストリームのペイロードを特定のService Busソース・オブジェクトに変換します。トランスポート・プロバイダは、トランスポート・マネージャを呼び出し、メッセージを受信します。転送マネージャがメッセージを処理し、Service Busランタイムでの処理に渡します。ランタイムは、メッセージ・コンテキストのサービス、サービスのバージョンおよびその他の情報を要求します。また、処理に必要なメタデータおよびペイロードについても要求します。ランタイムは、レスポンス・メタデータおよびレスポンス・ペイロードを作成するようMessageContextに要求し、その後でclose()を呼び出します。クライアントにレスポンスが返されます。

図E-1 ランタイムにおけるインバウンド・メッセージ

E.2 Service Busランタイムのアウトバウンド・メッセージ

図E-2のシーケンス・ダイアグラムに、Service Busランタイムでのアウトバウンド・メッセージのフローを示します。

Service Busランタイムは、メッセージを外部サービスにルーティングします。トランスポート・プロバイダはリクエストのメタデータおよびTransportSenderオブジェクトを作成します。このオブジェクトには、ペイロード、サービス品質および再試行に関する情報が含まれます。次に、プロバイダは、(トランスポート・サブシステムの中心となるハブである) TransportManagerをコールし、メッセージを非同期で送信します。TransportManagerは、トランスポート・プロバイダをコールし、メッセージを送信します。トランスポート・プロバイダはOutboundTransportMessageContextを作成します。その後、トランスポート・プロバイダは、メタデータ、ペイロードおよびその他の情報を要求し、適切なアクションを実行します。たとえば、JMSメッセージの場合、トランスポート・プロバイダは、JMS APIを使用してヘッダーおよびペイロードにデータを設定し、プロトコル固有の送信操作を呼び出します。

レスポンスを受信すると、トランスポート・プロバイダはTransportSendListenerオブジェクトをコールします。最終的に、トランスポート・マネージャがレスポンス・パイプラインを呼び出します。パイプライン・アクションが実行された後、アウトバウンド・エンドポイントが閉じられます。

図E-2 ランタイムにおけるアウトバウンド・メッセージ

E.3 設計時のサービスの登録

サービスを作成する際は、ウィザードの指示に従って、Oracle Service Bus Consoleの複数のページで設定を行います。トランスポート・タイプを選択する場合、Oracle Service Busコンソールは、トランスポート・マネージャを呼び出して、リストにある各エントリに対応するオブジェクトを取得し、各トランスポート・プロバイダからバインディングを取得します。このバインディングは、サポートされるものとされないものなど、コンソールがリクエストする質問を解決します。この手順により、コンソールのページに適切な情報が入力されます。図E-3に、サービスの作成プロセスを示します。次に、トランスポート・ベースのサービスの基本手順を示します。

1. サービスの名前を指定します。

2. トランスポート・プロバイダ(プロトコル)のリストから選択します。

3. サービス・タイプを選択し、必要に応じて構成します。

4. サービスを作成します。

5. 構成をレビューし、加えたすべての変更を保存します。プロキシ・サービスを作成した場合は、ターゲット・サービスを指定する必要があります。ターゲット・サービスには、パイプライン・サービスまたは別のプロキシ・サービスを指定できます。

図E-3 サービスの登録

window.name='GUID-D5F5738D-3533-4905-A89F-DFBD0E3C16F9' function footdisplay(footnum,footnote) { var msg = window.open('', 'NewWindow' + footnum, 'directories=no,height=120,location=no,menubar=no,resizable=yes,' + 'scrollbars=yes,status=no,toolbar=no,width=598'); msg.document.open('text/html'); }
F XQuery-SQLマッピング・リファレンス

この章では、ネイティブ・データ型のサポート、およびOracle XQueryエンジンが生成する、またはサポートするXQueryマッピングについて説明します。

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

- コアRDBMSデータ型マッピング

- IBM DB2/NT 8

- Microsoft SQL Server

- Oracle8i、8.1.x

- Oracle 9i以降

- Sybase 12.5.2 (およびそれ以上)

- ベース(汎用) RDBMSデータ型マッピング

Oracle Service Bus XQueryでのこれらのマッピングの使用については、「XQueryを使用したデータベースへのアクセス」を参照してください。

Oracle Service BusでサポートされているデータベースおよびJDBCドライバの詳細は、次の場所にあるOracle Fusion Middlewareのサポートされるシステム構成を参照してください:

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

F.1 IBM DB2/NT 8

次の表に、IBM DB2/NT 8についてXQueryエンジンが生成またはサポートするデータ型マッピングを示します。

表F-1 IBM DB2データ型マッピング

DB2データ型

XQuery型

BIGINT

xs:long

BLOB

xs:hexBinary

CHAR

xs:string

CHAR() FOR BIT DATA

xs:hexBinary

CLOB脚注1

xs:string

DATE

xs:date

DOUBLE

xs:double

DECIMAL(p,s)脚注 2 (NUMERIC)

xs:decimal (if s > 0)、xs:integer (if s = 0)

INTEGER

xs:int

LONG VARCHAR^1

xs:string

LONG VARCHAR FOR BIT DATA

xs:hexBinary

REAL

xs:float

SMALLINT

xs:short

TIME脚注3

xs:time脚注4

TIMESTAMP脚注5

xs:dateTime脚注

VARCHAR

xs:string脚注

VARCHAR() FOR BIT DATA

xs:hexBinary

脚注1

プロジェクト・リストのみで導き出されます。

脚注2

ここで、pは精度(小数点以下および以上の両方を含めた総桁数)で、sは位取り(小数点次の桁数)を表します。

脚注3

秒単位の精度。

脚注4

TIMEおよびTIMESTAMPの制限のため、値はローカル・タイム・ゾーンに変換されます(タイムゾーン情報は削除されます)。

脚注5

精度はミリ秒までです。

F.2 Microsoft SQL Server

次の表に、Microsoft SQL ServerについてXQueryエンジンが生成またはサポートするデータ型マッピングを示します。

表F-2 SQL Server 2000データ型マッピング

SQLデータ型

XQuery型

BIGINT

xs:long

BINARY

xs:hexBinary

BIT

xs:boolean

CHAR

xs:string

DATETIME脚注6

xs:dateTime脚注7

DECIMAL(p,s)脚注 8 (NUMERIC)

xs:decimal (if s > 0)、xs:integer (if s = 0)

FLOAT

xs:double

IMAGE

xs:hexBinary

INTEGER

xs:int

MONEY

xs:decimal

NCHAR

xs:string

NTEXT脚注9

xs:string

NVARCHAR

xs:string

REAL

xs:float

SMALLDATETIME脚注10

xs:dateTime

SMALLINT

xs:short

SMALLMONEY

xs:decimal

SQL_VARIANT

xs:string

TEXT^4

xs:string

TIMESTAMP

xs:hexBinary

TINYINT

xs:short

VARBINARY

xs:hexBinary

VARCHAR

xs:string

UNIQUIDENTIFIER

xs:string

脚注6

秒の小数点の精度は3桁までです(ミリ秒)。タイム・ゾーンはありません。

脚注7

DATETIMEの制限のため、値はローカル・タイム・ゾーンに変換され(タイムゾーン情報は削除)、小数点以下の秒はミリ秒まで切り捨てられます。

脚注8

ここで、pは精度(小数点以下および以上の両方を含めた総桁数)で、sは位取り(小数点次の桁数)を表します。

脚注9

プロジェクト・リストのみで導き出されます。

脚注10

分単位の精度。

F.3 Oracle8i、8.1.x

次の表に、Oracle 8.1.x (Oracle 8i)についてXQueryエンジンが生成またはサポートするデータ型を示します。

表F-3 Oracle 8.1.xデータ型マッピング

Oracle 8データ型

XQuery型

BFILE

サポートされません

BLOB

xs:hexBinary

CHAR

xs:string

CLOB脚注11

xs:string

DATE脚注12

xs:dateTime

FLOAT

xs:double

LONG^1

xs:string

LONG RAW

xs:hexBinary

NCHAR

xs:string

NCLOB^1

xs:string

NUMBER

xs:double

NUMBER(p,s)脚注 13

xs:decimal (if s > 0)、xs:integer (if s <=0)

NVARCHAR2

xs:string

RAW

xs:hexBinary

ROWID

xs:string

UROWID

xs:string

脚注11

プロジェクト・リストのみで導き出されます。

脚注12

秒の小数点はサポートしていません。

脚注13

ここで、pは精度(小数点以下および以上の両方を含めた総桁数)で、sは位取り(小数点次の桁数)を表します。

F.4 Oracle 9i以降

次の表に、Oracle Database 9i、10g、11g、および12cについてXQueryエンジンが生成またはサポートするデータ型とその他のマッピングを示します。Oracleでは空の文字列はNULLとして処理され、この文字列は、XQueryセマンティクスから逸脱しており、プッシュ・ダウンされた式に対し予期しない結果が導き出される可能性があります。

表F-4 Oracle 9i以降のデータ型マッピング

Oracleデータ型

XQuery型

BFILE

サポートされません

BLOB

xs:hexBinary

CHAR

xs:string

CLOB脚注14

xs:string

DATE

xs:dateTime脚注15

FLOAT

xs:double

INTERVALDAYTOSECOND

xdt:dayTimeDuration

INTERVALYEARTOMONTH

xdt:yearMonthDuration

LONG^1

xs:string

LONG RAW

xs:hexBinary

NCHAR

xs:string

NCLOB^1

xs:string

NUMBER

xs:double

NUMBER(p,s)

xs:decimal (if s > 0)、xs:integer (if s <=0)

NVARCHAR2

xs:string

RAW

xs:hexBinary

ROWID

xs:string

TIMESTAMP

xs:dateTime脚注16

TIMESTAMP WITH LOCAL TIMEZONE

xs:dateTime

TIMESTAMP WITH TIMEZONE

xs:dateTime

VARCHAR2

xs:string

UROWID

xs:string

脚注14

プロジェクト・リストのみで導き出されます。

脚注15

SDOがxs:dateTime値をOracle DATE型で保存する場合、それはローカル・タイム・ゾーンに変換され、DATEの制限のため、小数点次の秒は切り捨てられます。

脚注16

タイム・ゾーン情報があるかどうかに応じて、XQueryエンジンはXQuery xs:dateTimeをTIMESTAMPまたはTIMESTAMP WITH TIMEZONEデータ型のいずれかにマップします。SDOを使用してxs:dateTimeを保存する場合、SQLの型定義に応じて、秒の小数点次の桁が欠落することがあります。

F.5 Sybase 12.5.2 (およびそれ以上)

次の表に、Sybase 12.5.2 (およびそれ以上)についてXQueryエンジンが生成またはサポートするデータ型を示します。

注意:

SybaseはXQueryセマンティクスから逸脱しており(XQueryセマンティクスでは空の文字列は無視されます)、空の文字列はシングル・スペースの文字列として処理されます。

表F-5 Sybase 12.5.2データ型マッピング

Sybaseデータ型

XQuery型

BINARY

xs:hexBinary

BIT

xs:boolean

CHAR

xs:string

DATE

xs:date

DATETIME脚注17

xs:dateTime脚注18

DECIMAL(p,s)脚注 19 (NUMERIC)

xs:decimal (if s > 0)、xs:integer (if s == 0)

DOUBLE PRECISION

xs:double

FLOAT

xs:double

IMAGE

xs:hexBinary

INT (INTEGER)

xs:int

MONEY

xs:decimal

NCHAR

xs:string

NVARCHAR

xs:string

REAL

xs:float

SMALLDATETIME脚注20

xs:dateTime

SMALLINT

xs:short

SMALLMONEY

xs:decimal

SYSNAME

xs:string

TEXT脚注21

xs:string

TIME

xs:time

TINYINT

xs:short

VARBINARY

xs:hexBinary

VARCHAR

xs:string

脚注17

小数点以下3桁までの秒(ミリ秒)をサポートします。タイム・ゾーン情報はありません。

脚注18

SDOがxs:dateTime値をOracle DATE型で保存する場合、それはローカル・タイム・ゾーンに変換され、DATEの制限のため、小数点次の秒は切り捨てられます。

脚注19

ここで、pは精度(小数点以下および以上の両方を含めた総桁数)で、sは位取り(小数点次の桁数)を表します。

脚注20

分単位の精度。

脚注21

テキストを戻す式は、プロジェクト・リストでのみプッシュ・ダウンされます。

F.6 ベース(汎用) RDBMSデータ型マッピング

SQLをXQueryデータ型にマッピングする際、XQueryエンジンでは最初にJDBCタイプ・コードを確認します。タイプ・コードがXQuery型に対応している場合、XQueryエンジンでは一致するネイティブ・タイプ名を使用します。一致するタイプ・コードやタイプ名がない場合、列は無視されます。表F-6にこのマッピングを示します。

表F-6 RDBMSデータ型マッピング

JDBCデータ型

タイプ・コード

XQueryデータ型

BIGINT

-5

xs:long

BINARY

-2

xs:string

BIT

-7

xs:boolean

BLOB

2004

xs:hexBinary

BOOLEAN

16

xs:boolean

CHAR

1

xs:string

CLOB脚注22

2005

xs:string

DATE

91

xs:date脚注23

DECIMAL (p,s)脚注 24

3

xs:decimal (if s > 0)、xs:integer (if s =0)

DOUBLE

8

xs:double

FLOAT

6

xs:double

INTEGER

4

xs:int

LONGVARBINARY

-4

xs:hexBinary

LONGVARCHAR^1

-1

xs:string

NUMERIC (p,s)脚注

2

xs:decimal (if s > 0)、xs:integer (if s =0)

REAL

7

xs:float

SMALLINT

5

xs:short

TIME脚注25

92

xs:time^4

TIMESTAMP^4

93

xs:dateTime脚注

TINYINT

-6

xs:short

VARBINARY

-3

xs:hexBinary

VARCHAR

12

xs:string

その他のベンダー固有のJDBCタイプ・コード

1111

Oracle Service Busは、ネイティブ・データ型名を使用して適切なXQueryデータ型にマップします。

脚注22

プロジェクト・リストのみで導き出されます。

脚注23

DATEの制限のため、値はローカル・タイム・ゾーンに変換されます(タイムゾーン情報は削除されます)。

脚注24

ここで、pは精度(小数点以下および以上の両方を含めた総桁数)で、sは位取り(小数点次の桁数)を表します。

脚注25

xs:timeをTIMEに変換する場合、基盤のRDBMSの精度により、TIMEデータ型の精度および小数点以下切捨ての度合い(該当する場合)が決定します。

G ワーク・マネージャとスレッド

この付録では、Oracle Service Busによって使用される内部スレッド・モデルと、パフォーマンスおよびサーバーの安定性に関するその影響について説明します。HTTPトランスポートに焦点を当てます。

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

- スレッドの主要な概念

- パイプライン・アクション

- ワーク・マネージャ

- ワーク・マネージャの指定

G.1 スレッドの主要な概念

ワーク・マネージャをサービスに割り当てる場合、次の概念を考慮することが重要です。

- リクエストおよびレスポンスのパイプラインは常に個別のスレッドで実行されます。リクエスト・スレッドはプロキシ・サービス・トランスポートを起点とし、レスポンス・スレッドはビジネス・サービス・トランスポートを起点とします。

- 外部サービスの起動時、スレッドは、パイプライン・アクション、サービス品質(QoS)の構成、および使用中のトランスポートに応じて、ブロッキングまたは非ブロッキングのいずれかになります。

- ブロッキング呼出しを使用する場合は、サーバーのデッドロックを回避するために、最小スレッド制約を持つワーク・マネージャをレスポンスに関連付ける必要があります。

Service Busはプロキシ・サービス間の呼出しを最適化します。あるHTTPプロキシ・サービスが次のHTTPプロキシ・サービスを呼び出すと、トランスポート・レイヤーがバイパスされます。リクエスト・メッセージがネットワーク・ソケットを使用して送信されないため、トランスポートのオーバーヘッドが削減されます。かわりに、最初のプロキシ・サービスを処理するスレッドが、呼び出されたサービスのリクエスト・パイプラインの処理を継続します。同様に、ビジネス・サービスを起動すると、プロキシ・サービス・スレッドがリクエストの送信にも使用されます。HTTPトランスポートはWebLogic Serverの非同期機能を使用するため、ビジネス・サービスのレスポンスは別のスレッドで処理されます。

スレッドの説明において、Service BusがWebLogic Server上で実行されることを 記憶しておくことは重要です 。 Service Busは、様々なタイプのリクエストの実行をWeb Logic Server HTTP、JMSおよびコア・エンジンに依存する場合があります。時には、Service BusからWebLogic Serverに処理の一部が渡されます。  WebLogic Serverは、WebLogic Server自己チューニング・スレッド・プールで利用可能なスレッドを使用して、それを実行します。Service Busのドキュメントでは、Service Busの処理がWebLogic Serverおよびその自己チューニング・スレッドに依存するシナリオについては記載していません。

例として、サービス・コール・アウトの場合、Service Busレイヤー内の同期コールであっても、バックエンドからのレスポンスはWebLogic Socket Muxerスレッドが読み込む必要があります。これらのMuxerスレッドは、バックエンド・システムからレスポンスを取得した後、ブロックされ、レスポンスを待っているService Busスレッドに通知します。

すべてのService Busプロキシおよびビジネス・サービスは、それぞれワーク・マネージャからのスレッドを使用して実行するように構成することを強くお薦めします。ワーク・マネージャの制約の最小値および最大値は最大ロードに基づいて設定してください。これにより、プロキシ・サービスおよびビジネス・サービスが、実行に関してWebLogic Server実行スレッド・プールに 依存 しなくなり、WebLogic Serverは、 スレッドがスタックする問題を引き起こすことなく、Service Busからの非定型リクエストを処理するのに十分な空きスレッドまたはアイドル・スレッドを持ちます。

G.2 パイプライン・アクション

スレッド処理に特に影響する3つのパイプライン・アクション(ルート・アクション、パブリッシュ・アクションおよびサービス・コールアウト・アクション)があります。

G.2.1 ルート・アクション

デフォルトでは、HTTPトランスポートはWebLogic Serverの非同期機能を使用して、ビジネス・サービスのレスポンスを待機しながらスレッドのブロックを回避します。ルート・アクションの実行では、リクエストの送信を完了したスレッドはプールに戻され、そこで別の作業の処理に使用されます。外部サービスからレスポンスが返されると、それを処理するために2番目のスレッドがスケジュールされます。この動作は、ルート・オプション・アクションを使用し、「QoS」を「必ず1回」に設定することで変更できます。

G.2.2 パブリッシュ・アクション

パブリッシュ・アクションは一方向の送信です。これは、レスポンスを受信せずに外部サービスを起動する手段を提供します。多くの場合、ロギングや監査などのイベントの通知に使用されます。デフォルトでは、呼出しの成否はパイプライン・スレッドに返されません。前述の2つのアクションでは、「QoS」を「必ず1回」に設定すると、レスポンスを受信するまでリクエスト・スレッドが強制的にブロックされます。これにより、リクエスト・スレッドは、コールバックなしで呼出し元にただちにエラーを通知できます。この動作はまた、プロキシ・サービスを同時に処理するスレッド数を調整する場合に役立ちます。

G.2.3 サービス・コールアウト・アクション

サービス・コールアウトは、同期ブロッキング呼出しとして実装されます。これは、ターゲット・サービスにリクエストをルーティングする前に、外部サービスを起動して、リクエスト・メッセージに情報を追加する機能を提供するために設計されたものです。コールアウトがレスポンスを待機している間、リクエスト・パイプライン・スレッドは、レスポンスの準備が完了して処理が続行できることをレスポンス・スレッドが通知するまでブロックされます。

G.3 ワーク・マネージャ

WebLogic Serverは、自己チューニング・スレッド・プールを使用してアプリケーション関連のすべての作業を実行します。プール・サイズは増分マネージャによって管理され、プールのスレッドが必要に応じて追加または削除されます。アクティブ・スレッド数は400を超えることはありません。リクエストがサーバーに届くと、スケジューラがリクエストの実行順序を管理します。リクエスト数が使用可能なスレッド数を超えると、リクエストはキューに格納され、スレッドがプールに戻って使用可能になった時点で実行されます。ワーク・マネージャはスケジューラに対して、作業のタイプとリクエストの優先度を示します。

ワーク・マネージャは、WebLogic Server管理コンソールを使用して作成および構成されます。この項では、Service Busの最適化の鍵となるワーク・マネージャの概念について説明します。ワーク・マネージャの詳細は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。

G.3.1 ワーク・マネージャの構成

ワーク・マネージャの構成に重要なプロパティは、最大スレッド制約と最小スレッド制約です。最大スレッド制約は、スケジューラに対して、構成された数を超える同時実行を制限することにより、あるリクエスト・タイプを実行する同時スレッド数を制限します。ただし、スレッド・プールはすべてのワーク・マネージャで共有されるため、常に最大数のスレッドで処理を実行できるわけではありません。

最小スレッド制約は、最小数のスレッドの処理を保証します。最小数のプロセスに至るまでの十分なスレッドがスレッド・プールで使用可能でない場合、スケジューラは最小数のスレッドの処理に対応するためにスタンバイ・スレッドを使用します。スタンバイ・スレッドは、プール内の最大数である400スレッドとしてはカウントされません。最小スレッド制約を含むワーク・マネージャに関連付けられたリクエストをスレッドで実行する場合、ワーク・マネージャはまず、同じ制約が関連付けられた別のリクエストについてキューをチェックし、それを実行します(空きプールには戻りません)。このような理由から、最小スレッド制約は慎重に使用してください。使いすぎるとデフォルトのワーク・マネージャのリソースが不足して、予期できない結果が生じることがあります。

G.3.2 ワーク・マネージャの優先度

デフォルトでは、ワーク・マネージャはスケジューラと同じ優先度を持ち、共有値は50に設定されています。待機中のリクエストを実行する際、スケジューラは、各ワーク・マネージャに関連付けられたリクエストに同数のスレッド・リソースが渡されていることを確認します(待機中のリクエストが同数である場合)。

ワーク・マネージャは、ディスパッチ・ポリシーを指定することでService Bus内からサービスに関連付けられます。ビジネス・サービスにルーティングする簡単なプロキシ・サービスが存在する場合は、各サービスに様々なディスパッチ・ポリシーを割り当てることができます。これにより、スケジューラは、新しいリクエストが受信レスポンスとは異なる作業であることを認識します。その後、作業リクエスト(プロキシ・サービスに対する新しい受信リクエスト・メッセージまたはビジネス・サービスに対するレスポンス・メッセージのいずれか)がキューに追加されると、各ワーク・マネージャは均等にスケジュールされます。これは、ビジネス・サービスがブロッキング呼出しにより起動される場合(サービス・コールアウトの場合)に不可欠になります。

スレッドが特定のワーク・マネージャを指定して処理されると、プールに戻るまでそれが継続されます。したがって、パイプライン内部からビジネス・サービスまたはプロキシ・サービスを起動した場合、実行中のスレッドは引き続き、最初のプロキシ・サービスのワーク・マネージャの下で処理されます。この場合、呼び出されるサービスに指定されたワーク・マネージャは無視されます。

G.4 ワーク・マネージャの指定

ビジネス・サービスのワーク・マネージャ(ディスパッチ・ポリシー)構成は、ビジネス・サービスの起動方法に応じて行う必要があります。サービス・コールアウト、パブリッシュ・アクション、または必ず1回行われるQoS (「パイプライン・アクション」を参照してください)によるルーティングを使用してプロキシ・サービスおよびビジネス・サービスを起動する場合は、プロキシ・サービスおよびビジネス・サービスの両方で同じワーク・マネージャを使用するのでなく、異なるワーク・マネージャを使用することを検討してください。ビジネス・サービス・ワーク・マネージャでは、使用可能なスレッドを確保するために、「最小スレッド数制約」プロパティの数を少なく構成します(1-3)。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

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

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

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

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、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を参照してください。