Oracle® Fusion Middleware Oracle Infrastructure Webサービスの開発

リリース12c (12.1.2)

E48045-01(原本部品番号:E28129-01)

目次

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- リリース12c (12.1.2)の新機能と変更機能

- リリース12c (12.1.2)に関するこのドキュメントにおけるその他の大きな変更

1 Oracle Infrastructure Webサービスの概要

- Oracle Infrastructure Webサービスの概要

- Oracle Infrastructure Webサービスおよびクライアントのタイプ

- サポートされている標準

- 関連ドキュメント

2 Oracle Infrastructure Webサービスへのポリシーのアタッチ

- ポリシーおよびポリシー・セットとは

- OWSMの事前定義済ポリシーとアサーション・テンプレート

- Webサービスへのポリシーのアタッチ

3 Oracle Infrastructure Webサービスの保護

- Webサービスのセキュリティの概要

- OWSMの事前定義済セキュリティ・ポリシーとアサーション・テンプレート

- セキュリティ・ポリシーのアタッチ

- セキュリティ・ポリシーの構成

4 非同期Webサービスの開発

- 非同期Webサービスの概要

- 単一のリクエスト・キューを使用した非同期Webサービス

- リクエスト・キューおよびレスポンス・キューを使用した非同期Webサービス

- クライアントから見た非同期Webサービス・コールの全体像

- 非同期メッセージの相関処理

- JDeveloperを使用した非同期Webサービスの開発とデプロイ

- 非同期Webサービスの開発

- リクエスト・キューおよびレスポンス・キューの作成

- デフォルトのWebLogic JMSキューの使用

- クラスタ・ドメインでのデフォルトのWebLogic JMSキューの使用

- 非クラスタ・ドメインでのデフォルトのWebLogic JMSキューの使用

- デフォルトのJMS配信失敗パラメータのチューニング

- カスタムのリクエスト・キューおよびレスポンス・キューの作成

- 実行時のリクエスト・キューおよびレスポンス・キューの管理

- リクエスト・キューおよびレスポンス・キューの保護

- JMSシステム・ユーザーの構成(オプション)

- リクエスト・キューおよびレスポンス・キューの保護を目的としたWLSTスクリプトの実行

- リクエストおよびレスポンスのキュー構成の確認

- コールバック・サービスの構成

- 非同期WebサービスのためのSSL構成

- 非同期Webサービス・クライアントの定義

- 非同期クライアント・コードの更新

- コールバック・サービス・コードの更新

- 非同期Webサービスおよびクライアントへのポリシーのアタッチ

- 非同期Webサービス・クライアントへのポリシーのアタッチ

- 非同期コールバック・サービスへのポリシーのアタッチ

- コールバック・クライアントへのポリシーのアタッチ

5 Webサービスの信頼性のあるメッセージングの使用

- Webサービスの信頼性のあるメッセージングの概要

- 事前定義済の信頼性のあるメッセージング・ポリシー

- 信頼性のあるメッセージング・ポリシーのアタッチ

- 信頼性のあるメッセージング・ポリシーの構成

6 Webサービス原子性トランザクションの使用

- Webサービス原子性トランザクションの概要

- WebサービスでのWebサービス原子性トランザクションの有効化(インバウンド)

- Webサービス・クライアントでのWebサービス原子性トランザクションの有効化(アウトバウンド)

- Webサービス原子性トランザクションの構成

- コーディネータと参加者の間で交換されるメッセージの保護

7 Fast Infosetを使用したXML送信の最適化

- Fast Infosetの概要

- WebサービスでのFast Infosetの有効化

- Webサービス・クライアントでのFast Infosetの有効化と構成

- コンテンツ・ネゴシエーション方針の構成

- 設計時にFastInfosetClientFeature機能を使用する例

- WebサービスおよびクライアントでのFast Infosetの無効化

8 MTOMエンコード・メッセージ添付ファイルの使用

- メッセージ転送最適化メカニズムの概要

- 事前定義済のMTOMアタッチメント・ポリシー

- MTOMポリシーのアタッチ

- MTOMポリシーの構成

9 RESTful Webサービスの開発

- RESTful Webサービスの概要

- RESTful Webサービス・リクエストが作成および処理される仕組み

- HTTP Getリクエストの構築

- HTTP Postリクエストの構築

- RESTfulレスポンスの構築

- RESTful Webサービスのサポートの制限事項

10 スタンドアロン・クライアントからのWebサービスの起動

11 Webサービスのテスト

12 相互運用性のガイドライン

- Webサービスの相互運用性の概要

- Webサービスの相互運用性に関わる組織

- SOAPBuildersコミュニティ

- WS-Interoperability

- 相互運用性のあるWebサービスを作成するための一般的なガイドライン

- Webサービスをトップダウン方式で設計する

- 最初はXSDを使用してデータ型を設計する

- データ型はシンプルにする

- 1次元配列を使用する

- 空の配列と配列へのNULL参照とを区別する

- スパース配列、可変サイズ配列または多次元配列は使用しない

- xsd:anyTypeは使用しない

- サポートされていないxsd:typeはSOAPElementにマッピングする

- NULL値は慎重に使用する

- WSDLの検証にコンプライアンス・テスト・ツールを使用する

- 各プラットフォームにネイティブの型の違いを考慮する

- RPC-encodedメッセージ書式は使用しない

- 名前の競合を回避する

- メッセージ・ハンドラ、カスタム・シリアライザまたはインターセプタを使用する

- WS-*仕様は慎重に適用する

Oracle® Fusion Middleware

Oracle Infrastructure Webサービスの開発

リリース12c (12.1.2)

E48045-01(原本部品番号:E28129-01)

2013年6月

Oracle Infrastructure Webサービスを開発して使用するソフトウェア開発者向けのドキュメントです。

Oracle Fusion Middleware Oracle Infrastructure Webサービスの開発, リリース12c (12.1.2)

E48045-01

Copyright © 2013, 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 Infrastructure Webサービス開発者ガイド)で使用している表記規則について説明します。

対象読者

このドキュメントは、Application Development Framework (ADF)サービスなどのOracle Infrastructure Webサービスを開発するプログラマを対象としています。

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

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

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)を参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middlewareリリース12c (12.1.2)ドキュメンテーション・セットの次のドキュメントを参照してください。

- 『Webサービスの理解』

- 『Webサービスの管理』

- 『Oracle Web Services Managerの理解』

- 『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』

- 『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドで説明する新機能

次のトピックでは、Infrastructure Webサービスの新機能や変更された機能について、およびこのガイドに記載されるその他の重要な変更について紹介し、詳細情報へのリンクを提供します。このドキュメントは、以前Oracle Fusion Middleware開発者ガイドと呼ばれていたマニュアルの新版です。

リリース12c (12.1.2)の新機能と変更機能

Oracle Fusion Middlewareリリース12c (12.1.2)には、このドキュメントに関する次の新機能と変更機能が含まれます。

- プログラムで非同期コールバック・サービスにポリシーをアタッチするために使用する新しい注釈。「非同期コールバック・サービスへのポリシーのアタッチ」を参照してください。

- 新しい事前定義済の信頼性のあるメッセージング・ポリシー。「事前定義済の信頼性のあるメッセージング・ポリシー」を参照してください。

- 新しい事前定義済の原子性トランザクション・ポリシー。第6章「Webサービス原子性トランザクションの使用」を参照してください。

- Fast Infosetは、圧縮されたバイナリ・エンコーディング形式で、テキストベースのXML形式よりも効果的なシリアライズを実現します。Fast Infosetは、ドキュメント・サイズと処理パフォーマンスの両方を最適化します。第7章「Fast Infosetを使用したXML送信の最適化」を参照してください。

- 新しいスタンドアロンWebサービス・クライアントのJARファイルで、Oracle Infrastructure Webサービスの基本的なクライアント側機能と、Oracle Web Services Manager (OWSM)セキュリティ・ポリシーをサポートします。第10章「スタンドアロン・クライアントからのWebサービスの起動」を参照してください。

- 新しいWebサービス・テスト・クライアントによる、Webサービスのテスト。第11章「Webサービスのテスト」を参照してください。

リリース12c (12.1.2)に関するこのドキュメントにおけるその他の大きな変更

リリース12c (12.1.2)に対応して、このガイドは次のように更新されています。

- 「注釈のリファレンス」の章が削除されました。この章の内容は、Oracle Infrastructure WebサービスのJava APIリファレンスのJavadocや、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のセキュリティおよびポリシーの注釈のリファレンスと重複していました。

1 Oracle Infrastructure Webサービスの概要

この章では、Oracle Infrastructure Webサービスの概要を示し、サポートされている標準について説明します。

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

- Oracle Infrastructure Webサービスの概要

- Oracle Infrastructure Webサービスおよびクライアントのタイプ

- サポートされている標準

- 関連ドキュメント

Oracle Infrastructure Webサービスの概要

Oracle Fusion Middleware 12cには、次のタイプのWebサービスの開発、セキュリティおよび管理をサポートするためのWebサービス・カテゴリが2つあります。

- Oracle Infrastructure Webサービス

- Java EE (WebLogic) Webサービス

次の図は、2つのWebサービス・カテゴリを示しています。図中でOracle Infrastructure Webサービスは(黄色で)ハイライト表示されています。

図1-1 Oracle Fusion Middleware 12c内のWebサービス

「図1-1 Oracle Fusion Middleware 12c内のWebサービス」の説明

注意:

図に示されている全部のコンポーネント(開発、セキュリティおよび管理、ポリシー管理のツールを含む)の詳細は、『Webサービスの理解』に関する項を参照してください。

この章では、Oracle Infrastructure Webサービスを開発するための概念について説明します。Java EE Webサービスの詳細は、『Oracle WebLogic Server WebLogic Webサービスの理解』を参照してください。

Oracle Infrastructure Webサービスおよびクライアントのタイプ

表1-1は、Oracle Fusion Middleware 12cでサポートされているOracle Infrastructure Webサービスのタイプをまとめたものです。

表1-1 Oracle Infrastructure Webサービス

Webサービス

説明

ADFビジネス・コンポーネント

ADF Business Componentsは、再利用可能なコンポーネントのライブラリの提供およびOracle JDeveloperの設計時機能のサポートを介して、Java EEプラットフォームのビジネス・アプリケーションの開発、配信およびカスタマイズを簡素化するものです。

開発者は、ADF Business Componentsを使用して次の作業を行う場合、通常のJava EEアプリケーションに必要なアプリケーション・インフラストラクチャ・コードを記述する必要はありません。

- データベースへの接続。

- データの取得。

- データベース・レコードのロック。

- トランザクションの管理。

また、Oracle JDeveloperの機能は、組み込まれたデータ操作とカスタム・メソッドをカプセル化するADF Business Componentのアプリケーション・モジュールをWebサービスとして公開するため、サービス対応のアプリケーション・モジュールはデプロイFusion Webアプリケーションの各モジュールで横断的に使用できます。

詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のサービス対応のアプリケーション・モジュールの統合に関する説明を参照してください。

表1-2は、Oracle Fusion Middleware 12cでサポートされているOracle Infrastructure Webサービス・クライアントのタイプをまとめたものです。

表1-2 Oracle Infrastructure Webサービス・クライアント

Webサービス・クライアント

説明

ADF Webアプリケーション

ADF Webアプリケーションは、WebLogic Webサービス、サービス対応のADFアプリケーション・モジュールなどのサービスを起動できます。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。

また、ADF Webアプリケーションは、Webサービス・データ・コントロールを使用してユーザー・インタフェースによるWebサービスとの連携が可能です。詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。

サポートされている標準

次の表は、Oracle実装の一部となるOracle Infrastructure Webサービス仕様をハイレベルな機能別に編成してまとめたものです。

オラクル社は、Webサービス・プラットフォームの相互運用性は、可能なあらゆるケースのWebサービス仕様に対してサポートを提供するよりも重要であると考えます。Oracleは、Web Services Interoperability Organizationによる次の仕様に準拠し、これらの仕様をWebサービスの相互運用性の基準として考えています。

- Basic Profile 1.1および1.0: http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html

- Basic Security Profile 1.0: http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html

- WS-I Attachments Profile 1.0: http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html

注意:

Oracle Infrastructure Webサービスのセキュリティ標準の詳細は、『Oracle Web Services Managerの理解』のWebサービス・セキュリティ標準に関する説明を参照してください。

表1-3 Oracle Infrastructure Webサービスでサポートされる仕様

機能

仕様

(メタデータ注釈に基づく)プログラミング・モデルおよびランタイム・アーキテクチャ

Web Services Metadata Exchange (WS-MetadataExchange) 1.1: WS-Federationロードマップの一部であり、Webサービス・エンドポイントに関するメタデータの取得を可能にします。詳細は、http://xml.coverpages.org/WS-MetadataExchange.pdfの『Web Services Metadata Exchange (WS-MetadataExchange)』を参照してください。

Webサービス記述

- Web Services Description Language (WSDL) 1.1: Webサービスを記述するXMLベースの仕様。詳細は、http://www.w3.org/TR/wsdlの『Web Services Description Language (WSDL)』を参照してください。

- Web Services Policy Framework (WS-Policy) 1.5および1.2: Webサービスのポリシーを記述したり通信したりするための汎用目的のモデルおよびこれに対応する構文。詳細は、次を参照してください:
WS-Policy 1.5 Framework(勧告): http://www.w3.org/TR/ws-policy/

WS-Policy 1.2 Framework(メンバー投票): http://www.w3.org/Submission/WS-Policy

- Web Services Policy Attachment (WS-PolicyAttachment) 1.5および1.2: ポリシーの抽象モデルおよびXMLベースの式の文法。詳細は、次を参照してください:
『WS-Policy Attachment 1.5』(勧告): http://www.w3.org/TR/ws-policy-attach/

『WS-PolicyAttachment 1.2』(メンバー購読): http://www.w3.org/Submission/WS-PolicyAttachment

Webサービスとリクエスト側クライアントの間のデータ交換

- Simple Object Access Protocol (SOAP) 1.1および1.2: 非集中、分散環境における情報交換のための軽量プロトコル。詳細は、http://www.w3.org/TR/SOAPの『Simple Object Access Protocol (SOAP)』を参照してください。

- SOAP with Attachments API for Java (SAAJ) 1.3: 開発者がSOAP 1.1仕様および添付ファイル付きSOAPノートに準拠するメッセージを生成および消費するために使用できる実装。詳細は、https://saaj.dev.java.netの『SOAP with Attachments API for Java (SAAJ)』を参照してください。

- Message Transmission Optimization Mechanism (MTOM): Webサービスが添付ファイルを含むインバウンドSOAPメッセージを読み取る際に、メッセージ全体をメモリーに読み込むデフォルト動作をとらずにストリーミングAPIを使用することを指定できます。詳細は、http://www.w3.org/TR/soap12-mtom/の『SOAP Message Transmission Optimization Mechanism』を参照してください。

セキュリティ

- Web Services Security (WS-Security) 1.0および1.1: セキュアなWebサービスを構築してメッセージ・コンテンツの整合性と機密性を実装する際に使用できるSOAP [SOAP11、SOAP12]拡張の標準セット。詳細は、http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wssの『OASIS Web Service Security Web』を参照してください。
Webサービス・セキュリティは、次のセキュリティ・トークンをサポートします。

- ユーザー名: Webサービス・コンシューマが、認証の資格証明としてユーザー名を指定する方法を定義します。

- X.509証明書: 受信パーティに公開鍵を送信するために設計された署名付きデータ構造。

- Kerberosチケット: バイナリ認証およびセッション・トークン。

- Security Assertion Markup Language (SAML)アサーション: XMLドキュメントを介してインターネット上のセキュリティ情報を共有します。

詳細は、『Oracle Web Services Managerの理解』のWebサービス・セキュリティ標準に関する説明を参照してください。

- Web Services Security Policy (WS-SecurityPolicy) 1.3、1.2および1.1: WS-Policyの枠組みで使用するためのセキュリティ・ポリシー・アサーションのセット。詳細は次の項を参照してください。
Web Services Security Policy (WS-SecurityPolicy) 1.3仕様 参照サイト: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802

Web Services Security Policy (WS-SecurityPolicy) 1.2仕様 参照サイト: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html

Web Services Security Policy (WS-SecurityPolicy) 1.1仕様 参照サイト: http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf

- Security Assertion Markup Language (SAML) 2.0: セキュリティ・ドメイン間で認証および認可のデータを交換するためのXML標準。詳細は、http://docs.oasis-open.org/security/saml/v2.0/の『Security Assertion Markup Language (SAML)』を参照してください。

- Security Assertion Markup Language (SAML) Token Profile 1.1: SOAPメッセージの認証および暗号化を実装するSOAP拡張のセット。詳細は、http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdfの『Security Assertion Markup Language (SAML) Token Profile 1.1』仕様を参照してください。

- WS-Trust: セキュリティ・トークンのリクエストおよび発行を行う際の枠組みを提供するWS-Securityへの拡張機能と、ブローカ・トラスト関係への拡張機能を定義します。詳細は、http://docs.oasis-open.org/ws-sx/ws-trust/v1.3/ws-trust.htmlを参照してください。

- XML署名: デジタル署名用のXML構文を定義します。詳細は、http://www.w3.org/TR/xmldsig-core/の『XML Signature Syntax and Processing』を参照してください。

- XML暗号化: XML要素の内容を暗号化する方法を定義します。詳細は、http://www.w3.org/TR/xmlenc-core/の『XML Encryption Syntax and Processing』を参照してください。

信頼性のある通信

- Web Services Addressing (WS-Addressing) 1.0: Webサービスおよびメッセージのアドレッシングを行うための、トランスポートに依存しないメカニズム。詳細は、http://www.w3.org/TR/ws-addr-coreのWeb Services Addressing (WS-Addressing)仕様を参照してください。

- Web Services Reliable Messaging (WS-ReliableMessaging) 1.0および1.1: 異なるWebLogic Serverインスタンス上で動作する2つのWebサービスが、ソフトウェア・コンポーネント、システムまたはネットワークに障害が発生しても信頼性のある通信をできるようにする実装。詳細は、次を参照してください:
http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdfの『Web Services Reliable Messaging (WS-ReliableMessaging) 1.1』。

http://specs.xmlsoap.org/ws/2005/02/rm/ws-reliablemessaging.pdfの『Web Services Reliable Messaging (WS-ReliableMessaging) 1.0』。

- Web Services Reliable Messaging Policy (WS-ReliableMessaging Policy) 1.1: WS-PolicyおよびWS-ReliableMessagingの使用時に信頼性のあるメッセージングを行うためのドメイン固有のポリシー・アサーション。詳細は、http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdfの『Web Services Reliable Messaging Policy (WS-ReliableMessaging Policy)』仕様を参照してください。

原子性トランザクション

Webサービス原子性トランザクション: Web Services Coordination仕様で説明されている拡張可能調整フレームワークとともに使用する原子性トランザクション調整タイプを定義します。WS-AtomicTransaction仕様およびWS-Coordination仕様では、一連の参加者の間で分散されたアクティビティを調整するための拡張可能フレームワークを定義しています。詳細は、次を参照してください:

- 『WS-AtomicTransaction』: http://docs.oasis-open.org/ws-tx/wstx-wsat-1.2-spec-cs-01/wstx-wsat-1.2-spec-cs-01.html

- 『WS-Coordination』: http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.2-spec-cs-01/wstx-wscoor-1.2-spec-cs-01.html

XML送信の最適化

- Fast Infoset: 圧縮されたバイナリ・エンコーディング形式で、テキストベースのXML形式よりも効果的なシリアライズを実現します。Fast Infosetは、ドキュメント・サイズと処理パフォーマンスの両方を最適化します。Fast Infoset仕様、ITU-T Rec.X.891およびISO/IEC 24824-1 (Fast Infoset)は、ITU-TおよびISOの両方の標準化団体によって定義されています。この仕様は次のITUのWebサイトhttp://www.itu.int/rec/T-REC-X.891-200505-I/enでダウンロードできます。

- Message Transmission Optimization Mechanism (MTOM): SOAPメッセージ内のxs:base64Binaryまたはxs:hexBinaryタイプのXMLデータの転送を最適化するためのメソッドを定義します。

通知(登録および検出)

- Universal Description, Discovery, and Integration (UDDI) 2.0: Webサービスの記述、既知のレジストリへのWebサービスの登録、および他の登録済Webサービスの検出を行うための標準。詳細は、http://uddi.xml.orgの『Universal Description, Discovery, and Integration (UDDI)』を参照してください。

- Web Services Inspection Language 1.0: 使用可能なサービスのサイトの検査に役立つXMLフォーマットを提供します。詳細は、http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-wsilspec/ws-wsilspec.pdfのWeb Services Inspection Language (WS-Inspection) 1.0仕様を参照してください。

関連ドキュメント

次の表は、Oracle Infrastructure Webサービスの開発、セキュリティおよび管理に関連するドキュメントをまとめたものです。

表1-4 関連ドキュメント

ドキュメント

説明

『Webサービスの理解』

Oracle Fusion Middleware 12cのWebサービスの概要を示します。

『Oracle WebLogic Server WebLogic Webサービスの理解』

WebLogic Web Services (Java EE)の概要を示します。

『Oracle Web Services Managerの理解』

Webサービスのポリシーのアタッチメントと管理に使用するOracle Web Services Manager (OWSM)の概要を示します。

『Webサービスの管理』

Webサービスの保護および管理の方法について説明します。

『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』

OWSMポリシーを使用したWebサービスの保護方法について説明します。このドキュメントではまた、OWSMポリシーの作成および管理方法についても説明します。

『Oracle Web Services Manager Extensibility Guide』

OWSMのカスタム・ポリシー・アサーションの構築方法について説明します。

『Oracle Web Services Manager相互運用性ソリューション・ガイド』

OWSMの最も一般的な相互運用性シナリオの実装方法が説明されています。

『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』

ADFコンポーネントの開発方法について説明します。

『Oracle Jdeveloperによるアプリケーションの開発』のWebサービスの開発および保護に関する説明

Oracle JDeveloperを使用したWebサービスの開発およびポリシーのアタッチの方法について説明します。

Oracle Workshop for WebLogic

ソース・コードの記述と管理、および最先端のビジュアル・ツールやJavaフレームワークを使用した設計のためにWorkshopを活用する方法について説明します。

2 Oracle Infrastructure Webサービスへのポリシーのアタッチ

この章では、ポリシーをOracle Infrastructure Webサービスにアタッチする方法について説明します。

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

- ポリシーおよびポリシー・セットとは

- OWSMの事前定義済ポリシーとアサーション・テンプレート

- Webサービスへのポリシーのアタッチ

ポリシーおよびポリシー・セットとは

ポリシーでは、メッセージを保護する必要性と保護する方法、メッセージを確実に送信する必要性と確実に送信する方法など、Webサービスの機能および要件を記述します。詳細は、『Oracle Web Services Managerの理解』のポリシーに関する説明を参照してください。

ポリシー・セットとは、内部に複数のポリシー参照を格納し、同じタイプの一連のサブジェクトに対してグローバルにポリシーをアタッチする手段を提供する抽象表現の1つです。ポリシー・セットを使用してグローバルにポリシーをアタッチするメカニズムでは、開発者、アセンブラ、またはデプロイヤがポリシーのアタッチを明示的に指定しなかった状況でも、管理者はすべてのサブジェクトのセキュリティを確実に確保できます。ポリシー・セットを使用してアタッチされるポリシーは、外部的にアタッチされたと見なされます。

ポリシー・セットでは、実行時の制約を指定する機能が提供され、この制約によってそのポリシー・セットが関連するコンテキストが決定されます。たとえば、セキュリティ保護されていない公衆回線でメッセージが送信される可能性があるため、外部クライアントと通信する場合にのみ、サービスでメッセージ保護を使用するように指定できます。ただし、信頼できるネットワークで内部クライアントと通信するときは、メッセージ保護を要求しない場合もあります。詳細は、『Oracle Web Services Managerの理解』のポリシー・セットを使用したグローバル・ポリシー・アタッチメントに関する説明を参照してください。

OWSMの事前定義済ポリシーとアサーション・テンプレート

Oracle Web Services Manager (OWSM)には、組織全体で一貫してWebサービスを管理および保護するためのポリシー・フレームワークが備わっています。OWSMは、開発者が設計時に使用することも、システム管理者が本番環境で使用することも可能です。OWSMポリシーのフレームワークの詳細は、『Oracle Web Services Managerの理解』のOWSMポリシーのフレームワークの理解に関する説明を参照してください。

Oracle Fusion Middlewareをインストールすると自動的に使用可能になる、一連の事前定義済OWSMポリシーとアサーション・テンプレートがあります。事前定義済ポリシーは、顧客のデプロイで使用される一般的なベスト・プラクティス・ポリシーのパターンに基づいています。

これらの事前定義済ポリシーは、Webサービスやクライアントにすぐにアタッチできます。事前定義済ポリシーを構成することも、事前定義済ポリシーのいずれかをコピーして新しいポリシーを作成することもできます。

事前定義済ポリシーは、事前定義済アサーション・テンプレートに基づくアサーションを使用して作成されています。必要に応じて、新しいアサーション・テンプレートを作成できます。

事前定義済のOWSMポリシーおよびアサーション・テンプレートの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の次の項を参照してください。

- 事前定義済ポリシーに関する項

- 事前定義済アサーション・テンプレートに関する項

Webサービスへのポリシーのアタッチ

セキュリティ・ポリシーは、組織全体で一貫したWebサービスの管理と保護を実現するためのフレームワークを提供します。Webサービス・エンドポイントに直接アタッチできます。

- 設計時に、プログラムで注釈を使用。JDeveloperでアプリケーションを開発するとき、ウィザードを利用してWebサービスおよびクライアントにポリシーをアタッチできます。

- デプロイ後に、Oracle Fusion MiddlewareおよびWLSTを使用。

また、ポリシー・セットを使用すると、ある範囲に含まれる同じタイプのエンドポイントに対して、ポリシーをグローバルにアタッチできます。

詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のポリシーのアタッチに関する説明を参照してください。

3 Oracle Infrastructure Webサービスの保護

この章では、Oracle Infrastructure Webサービスを保護する方法について説明します。

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

- Webサービスのセキュリティの概要

- OWSMの事前定義済セキュリティ・ポリシーとアサーション・テンプレート

- セキュリティ・ポリシーのアタッチ

- セキュリティ・ポリシーの構成

Webサービスのセキュリティの概要

Webサービス・セキュリティには次の側面があります。

- 認証: ユーザーが表明しているとおりのユーザーであるかを検証します。ユーザーのアイデンティティは、ユーザー自身が提供する資格証明に基づいて検証されます。資格証明には次のものがあります。

1. ユーザーが所有しているもの。たとえばパスポート(実世界)やスマート・カード(ITの世界)など、信頼できる機関が発行した資格証明。

2. ユーザーが知っているもの。たとえばパスワードなどの共有の秘密鍵。

3. ユーザーの特性。たとえばバイオメトリック情報。

複数のタイプの資格情報を組み合せて使用することは、強い認証と呼ばれます。たとえば、ATMカード(ユーザーが持っているもの)とPINやパスワード(ユーザーが知っていること)を使用する場合などです。

- 認可(またはアクセス制御): 認証されたユーザーの権限に基づいて、特定のリソースへのアクセスを許可します。権限は1つ以上の属性によって定義されます。属性とはユーザーのプロパティまたは特性のことです。たとえば、「Marc」はユーザーで、「会議の発言者」は属性です。

- 機密保護、プライバシ: 情報の機密性を保ちます。Webサービス・リクエストや電子メールなどのメッセージと、送信ユーザーおよび受信ユーザーのアイデンティティに、機密を保つ方法でアクセスします。メッセージのコンテンツを暗号化し、送信ユーザーおよび受信ユーザーのアイデンティティを不明瞭化することで機密保護とプライバシが実現されます。

- 整合性、否認防止: 送信ユーザーがメッセージにデジタルで署名することによって、メッセージが転送中に変更されないようにします。デジタル署名を使用することによって、署名が検証され、否認防止が実現されます。署名内のタイムスタンプにより、このメッセージが有効期限後にリプレイされることを防ぎます。

これらのWebサービス・セキュリティの概念の詳細は、『Oracle Web Services Managerの理解』のWebサービスのセキュリティの概念を理解するための説明を参照してください。

Oracle Web Services Manager (WSM)は、異機種間環境でWebサービス・セキュリティを定義、実装するために設計され、単一トランザクションを完了するために使用される複数のWebサービスにわたる認証、認可、メッセージの暗号化および復号化、署名の生成および検証、およびアイデンティティ伝播が含まれます。さらにOWSMには、サービスレベル契約に基づいてWebサービスを管理するためのツールが用意されています。たとえば、ユーザー(セキュリティ設計者やシステム管理者)は、Webサービスの可用性、レスポンス時間、および請求目的で使用可能なその他の情報を定義できます。OWSMの詳細は、『Oracle Web Services Managerの理解』のOWSMポリシーのフレームワークの理解に関する説明を参照してください。

OWSMの事前定義済セキュリティ・ポリシーとアサーション・テンプレート

第2章「Oracle Infrastructure Webサービスへのポリシーのアタッチ」で説明されているように、OWSMには、Oracle Fusion Middlewareをインストールすると自動的に使用可能になる一連の事前定義済のポリシーおよびアサーション・テンプレートが用意されています。

次のカテゴリのセキュリティ・ポリシーおよびアサーション・テンプレートは、即時に利用可能です。

- 認証のみのポリシー

- メッセージ保護のみのポリシー

- メッセージ保護および認証ポリシー

- 認可のみのポリシー

事前定義済のOWSMポリシーおよびアサーション・テンプレートの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の次の項を参照してください。

- 事前定義済ポリシーに関する項

- 事前定義済アサーション・テンプレートに関する項

使用するセキュリティ・ポリシーを決定する際には、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の使用するセキュリティ・ポリシーの決定に関する説明を参照してください。

セキュリティ・ポリシーのアタッチ

Oracle Infrastructure Webサービスおよびクライアントにセキュリティ・ポリシーをアタッチします。設計時にはOracle JDeveloperを使用して、実行時にはFusion Middleware Controlを使用して行います。詳細は、第2章「Oracle Infrastructure Webサービスへのポリシーのアタッチ」を参照してください。

セキュリティ・ポリシーの構成

セキュリティ・ポリシーを環境内で使用するには、あらかじめ構成する必要があります。セキュリティ・ポリシーの構成手順の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のWebサービスの保護に関する説明を参照してください。

4 非同期Webサービスの開発

この章では、非同期Webサービスの概念の概要を示し、非同期Webサービスを開発および構成する方法について説明します。

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

- 非同期Webサービスの概要

- JDeveloperを使用した非同期Webサービスの開発とデプロイ

- 非同期Webサービスの開発

- リクエスト・キューおよびレスポンス・キューの作成

- コールバック・サービスの構成

- 非同期WebサービスのためのSSL構成

- 非同期Webサービス・クライアントの定義

- 非同期Webサービスおよびクライアントへのポリシーのアタッチ

非同期Webサービスの概要

Webサービスを同期的に起動する場合、起動するクライアント・アプリケーションは、レスポンスが返されるまで作業を続行できません。レスポンスがすぐに返される場合は、このWebサービスの起動方法は適切と言えます。ただし、リクエストの処理は遅延することがあるため、クライアント・アプリケーションが作業を続行し、後でレスポンスを処理する方が便利な場合もよくあります。Webサービスを非同期で呼び出すことで、クライアントは中断されずに処理を続行でき、非同期レスポンスが返されたときに通知されます。

次の各項で、非同期メッセージ・フローのダイアグラムをいくつか示し、クライアント側から見た全体像を示します。また、非同期メッセージが互いにどのように関連しているかを説明します。

- 単一のリクエスト・キューを使用した非同期Webサービス

- リクエスト・キューおよびレスポンス・キューを使用した非同期Webサービス

- クライアントから見た非同期Webサービス・コールの全体像

- 非同期メッセージの相関処理

単一のリクエスト・キューを使用した非同期Webサービス

注意:

単一のリクエスト・キューを使用した場合、パフォーマンスは高くなる可能性はありますが、リクエスト・キューとレスポンス・キューを使用した場合よりも信頼性が低くなります。単一のリクエスト・キューを使用するのではなく、「リクエスト・キューおよびレスポンス・キューを使用した非同期Webサービス」で説明されているように、リクエスト・キューとレスポンス・キューを使用することをお薦めします。

このシナリオでは、リクエストとレスポンスの両方の処理を実行する単一のメッセージドリブンBean (MDB)がリクエスト・キューに関連付けられています。

次の図は、単一のリクエスト・キューを使用した非同期メソッド・コールのフローを示しています。

図4-1 単一のリクエスト・キューを使用した同期Webサービス

「図4-1 単一のリクエスト・キューを使用した非同期Webサービス」の説明

前出の図に示されたフローについて次に説明します。

1. クライアントが非同期メソッドをコールします。

2. 非同期Webサービスがリクエストを受信して、それをリクエスト・キューに格納します。

3. 非同期Webサービスは受信確認をクライアントに送信します。

4. リクエスト・キューのMDBリスナーがメッセージを受信し、リクエストの処理を開始します。

5. リクエストMDBは、Webサービス実装の必須メソッドをコールします。

6. Webサービス実装がレスポンスを返します。

7. リクエストMDBがコールバック・クライアントとなり、コールバック・サービスにレスポンスを返します。

8. コールバック・サービスは受信確認メッセージを返します。

9. リクエストMDBは確認メッセージをリクエスト・キューに返して、プロセスを終了します。

このシナリオでは、コールバック・サービスへの接続(ステップ7)に問題がある場合、レスポンスは送信されません。後でリクエストが再試行される場合は、ステップ4からフローが再開し、再びWebサービス実装がコールされます(ステップ5)。このような動作は、アプリケーション・ロジックやトランザクション制御処理によっては望ましくないことがあります。次のシナリオでは、レスポンスが別のレスポンス・キューに格納されるため、最初にコールバック・サービスが使用可能になっていなくても、Webサービス実装を再びコールする必要がありません。

リクエスト・キューおよびレスポンス・キューを使用した非同期Webサービス

このシナリオでは、2つのMDBを使用し、それぞれがリクエスト処理とレスポンス処理を行います。このシナリオでは、ビジネス・ロジックの実行をレスポンスの返却と分離することにより、「単一のリクエスト・キューを使用した非同期Webサービス」で説明されている単一キューのモデルよりもエラー・リカバリを向上させています。

次の図は、単一のリクエスト・キューを使用した非同期メソッド・コールのフローを示しています。

図4-2 リクエスト・キューおよびレスポンス・キューを使用した非同期Webサービス

「図4-2 リクエスト・キューおよびレスポンス・キューを使用した非同期Webサービス」の説明

前出の図に示されたフローについて次に説明します。

1. クライアントが非同期メソッドをコールします。

2. 非同期Webサービスがリクエストを受信して、それをリクエスト・キューに格納します。

3. 非同期Webサービスは受信確認をクライアントに送信します。

4. リクエスト・キューのMDBリスナーがメッセージを受信し、リクエストの処理を開始します。

5. リクエストMDBは、Webサービス実装の必須メソッドをコールします。

6. Webサービス実装がレスポンスを返します。

7. リクエストMDBがレスポンスをレスポンス・キューに保存します。

8. リクエストMDBはリクエスト・キューに確認を送信して、プロセスを終了します。

9. レスポンス・キューのonMessageリスナーがレスポンスの処理を開始します。

10. レスポンスMDBがコールバック・クライアントとなり、コールバック・サービスにレスポンスを返します。

11. コールバック・サービスは受信確認メッセージを返します。

12. レスポンスMDBは確認メッセージをレスポンス・キューに返して、シーケンスを終了します。

クライアントから見た非同期Webサービス・コールの全体像

クライアントから見ると、非同期メソッド・コールは次の図のように2つの一方向メッセージ交換で構成されています。

図4-3 非同期Webサービス・クライアントのフロー

「図4-3 非同期Webサービス・クライアントのフロー」の説明

前出の図に示したように、クライアントは非同期コールを開始する前に、非同期Webサービスからのレスポンスをリスニングするためのコールバック・サービスをデプロイする必要があります。

メッセージのフローは次のとおりです。

1. クライアントが非同期メソッドをコールします。

2. 非同期Webサービスがリクエストを受信し、開始クライアントに確認メッセージを送信して、リクエストの処理を開始します。

3. リクエストの処理が完了すると、非同期Webサービスがクライアントとなり、コールバック・サービスにレスポンスを返します。

4. コールバック・サービスは確認メッセージを非同期Webサービスに送信します。

非同期メッセージの相関処理

注意:

メッセージ相関はランタイムによって自動的に処理されます。この項の説明は参考情報です。

コールバック・サービスはレスポンスの受信時に、レスポンスと元のリクエストを相互に関連付ける必要があります。これは、ランタイムによってWS-Addressingを介して自動的に行われます。

クライアントは、SOAPヘッダーのWS-Addressing部分に次の2つのフィールドを設定します。

- ReplyToアドレス: コールバック・サービスのアドレス。

- MessageID: リクエストを識別する一意のID。たとえば、UUIDなどです。

コールバック・クライアントは、WS-AddressingヘッダーのrelatesToIdフィールド内の初期リクエストに対応するMessageIdを送信します。コールバック・サービスでレスポンス処理に追加データが必要となる場合、クライアントは次のタスクのいずれかを実行できます。

- クライアントは、データをReplyToフィールド内の参照パラメータとして送信できます。非同期Webサービスでは、レスポンスで参照パラメータがすべて返されるため、コールバック・サービスで情報へのアクセスが可能となります。

- データを非同期リクエスト・メッセージの一部として送信することが実行可能でない場合、クライアントは、ローカル・データ・ストアに必要なMessageIDとデータを保存できます。

JDeveloperを使用した非同期Webサービスの開発とデプロイ

ADF Business Componentの非同期Webサービス・メソッドの開発とデプロイは、短時間で簡単に行うことができます。詳細は、Oracle Application Development Frameworkの開発者ガイドの非同期Webサービス・メソッドの生成方法に関する項を参照してください。

次の各項で、非同期Webサービスの実装方法を詳しく説明します。一部は参考情報です。

非同期Webサービスの開発

oracle.webservices.annotations.async.AsyncWebService注釈を使用して、JAX-WS Webサービスを非同期Webサービスとして宣言できます。

次の例は、非同期Webサービスのごく単純なPOJOを示しています。

import oracle.webservices.annotations.PortableWebService
import oracle.webservices.annotations.async.AsyncWebService

@PortableWebService
@AsyncWebService
public class HelloService {
public String hello(String name) {
return "Hi " + name;
}
}

非同期Webサービスに対して生成されたWSDLには、2つのportTypeとして定義された2つの一方向操作が含まれています(非同期操作用とコールバック操作用)。

次に例を示します。

<wsdl:portType name="HelloService">
<wsdl:operation name="hello">
<wsdl:input message="tns:helloInput"
xmlns:ns1="http://www.w3.org/2006/05/addressing/wsdl"
ns1:Action=""/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="HelloServiceResponse">
<wsdl:operation name="helloResponse">
<wsdl:input message="tns:helloOutput"
xmlns:ns1="http://www.w3.org/2006/05/addressing/wsdl"
ns1:Action=""/>
</wsdl:operation>
</wsdl:portType>

オプションとして、systemUser引数を使用して、非同期Webサービスへのアクセスのセキュリティを確保するためにシステム・ユーザーも定義できます。指定しない場合、この値はOracleSystemUserにデフォルト設定されます。

次に例を示します。

@AsyncWebService(systemUser="ABCIncSystemUser')

デフォルトでは、Webサービスに関連付けられた操作はすべて非同期となります。特定のメソッドを同期としてマークするには、コールバック・サービスの構成に関する項で説明するように、@CalbackMethod注釈を使用します。同期的にも非同期的にもメソッドを呼び出せるようにする場合は、それに応じて2つのメソッドと注釈を作成する必要があります。

@AsyncWebServiceおよび@PortableWebService注釈の詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。

非同期Webサービスで使用されるリクエスト・キューとレスポンス・キューの保護に関する詳細は、リクエスト・キューおよびレスポンス・キューの保護に関する項を参照してください。

リクエスト・キューおよびレスポンス・キューの作成

作成した非同期Webサービスをデプロイする前に、まずは次項の説明に従って、リクエストおよびレスポンスを格納するために使用されるキューを作成し、そのセキュリティを確保する必要があります。

- デフォルトのWebLogic JMSキューの使用

- カスタムのリクエスト・キューおよびレスポンス・キューの作成

- 実行時のリクエスト・キューおよびレスポンス・キューの管理

- リクエスト・キューおよびレスポンス・キューの保護

- リクエストおよびレスポンスのキュー構成の確認

デフォルトのWebLogic JMSキューの使用

次の各項で説明するように、このプロセスは、クラスタ・ドメインか非クラスタ・ドメインのどちらを使用しているかによって異なります。

- クラスタ・ドメインでのデフォルトのWebLogic JMSキューの使用

- 非クラスタ・ドメインでのデフォルトのWebLogic JMSキューの使用

- デフォルトのJMS配信失敗パラメータのチューニング

クラスタ・ドメインでのデフォルトのWebLogic JMSキューの使用

クラスタ・ドメインの場合は、クラスタごとに2つのJMS共通分散宛先(UDD)を作成する必要があります。デフォルト・キューをクラスタ環境に追加する際は、オフラインWLSTスクリプトを使用できます。

このスクリプトは次の場所にあります。

<MW_HOME>/oracle_common/webservices/bin/jrfws-async-createUDDs.py

このスクリプトの実行例を次に示します。

java -classpath <some_path>/weblogic.jar weblogic.WLST ./jrfws-async-createUDDs.py --domain_home <domain> --cluster <cluster>

非クラスタ・ドメインでのデフォルトのWebLogic JMSキューの使用

非クラスタ・ドメインの場合、oracle.jrf.ws.async_template_11.1.1.jarというWebLogicドメイン拡張テンプレートの一部として、1組のデフォルトのWebLogic JMSキューが用意されています。この拡張テンプレートに含まれているデフォルトのJMSキューは、次のとおりです。

- リクエスト・キュー: oracle.j2ee.ws.server.async.DefaultRequestQueue

- レスポンス・キュー: oracle.j2ee.ws.server.async.DefaultResponseQueue

基本ドメインの一部として用意されているデフォルトのJMS接続ファクトリであるweblogic.jms.XAConnectionFactoryが、デフォルトで使用されます。

必要なデフォルトのキューを作成するには、Fusion Middleware構成ウィザードを使用してドメインを作成または拡張するときに、「Oracle JRF Webサービスの非同期サービス」を選択します。詳細は、『構成ウィザードによるドメインの作成』を参照してください。

注意:

このドメイン拡張テンプレートを使用する場合は、必ずJMSモジュール(JRFWSAsyncJmsModule)に、ドメイン内の非クラスタ・サーバーを必要に応じて1つ以上ターゲットとして明示的に指定します。

デフォルトのJMS配信失敗パラメータのチューニング

次のデフォルト値は、JMS配信失敗パラメータ用に構成されています。設定を見直して、使用環境に応じてそれらを変更することをお薦めします。JMS配信失敗パラメータに関連する構成は、『Oracle WebLogic Server JMSリソースの管理』の説明に従って、WebLogic Server管理コンソールを使用して変更できます。

- 「再配信遅延のオーバーライド」の値を900000ミリ秒に設定します。つまり、メッセージ・コンシューマまたは接続ファクトリで指定されている再配信遅延に関係なく、15分間待機した後にロールバックまたはリカバリされたメッセージが再配信されます。

- 「再配信の制限」の値を100に設定します。この値は、キューに定義されているエラー宛先にメッセージが移されるまでに許可される再配信試行回数を示します。

- 「有効期限ポリシー」の値を「リダイレクト」に設定します。これにより、期限切れのメッセージは現在の場所からキューに定義されているエラー宛先に移されます。これが有効になっている場合は、対応するエラー宛先が構成されていることを確認してください。

カスタムのリクエスト・キューおよびレスポンス・キューの作成

デフォルトのWebLogic JMSキューが要件を満たしていない場合は、次の手順を実行できます。

1. 『Oracle WebLogic Server JMSアプリケーションの開発』の説明に従って、リクエスト・キューおよびレスポンス・キューを手動で作成します。

2. 次の注釈を使用して、これらのキューをアプリケーション・コードに追加します。

- リクエスト・キュー: oracle.webservices.annotations.async.AsyncWebServiceQueue
次に例を示します。

@AsyncWebServiceQueue (
connectionFactory = "weblogic.jms.XAConnectionFactory",
queue = "oracle.j2ee.ws.server.async.NonDefaultRequestQueue",
enableTransaction = true
transactionTimeout=3600
)

@AsyncWebServiceQueueの詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。

- レスポンス・キュー: oracle.webservices.annotations.async.AsycnWebServiceResponseQueue
次に例を示します。

@AsyncWebServiceResponseQueue (
connectionFactory = "weblogic.jms.XAConnectionFactory",
queue = "oracle.j2ee.ws.server.async.NonDefaultResponseQueue",
enableTransaction = true
)

@AsyncWebServiceResponseQueueの詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。

非同期リクエストは、最初に、非同期の実行のためにリクエストJMSキューに保存されます。メッセージドリブンBean (MDB)は、キューのリクエストにアクセスして、ビジネス・ロジックを実行します。

同時に多数のリクエストを処理する場合、アプリケーション・サーバーはMDBインスタンスのプールを作成します(このプールは、アプリケーションの要件に基づいて構成できます)。プール内のMDBインスタンスが多いほど、スループットは向上します。ただし、使用されるリソース(スレッドやデータベース接続など)は多くなります。厳密なリソース要件は、非同期リクエスト・メッセージの保存に使用される永続ストアのタイプによって異なります。

デフォルトでは、WebLogic Serverは、1つのMDBインスタンスのみでプールを初期化し、実行のためにキューに投入されるリクエストが増えると、プール・サイズを(最大16まで)増やし続けます。最大プール・サイズに達すると、それ以上MDBインスタンスは追加されずに、サーバーは既存のMDBインスタンスが現在実行中のリクエストを完了するまで待機します。

ユーザーは、アプリケーション要件に基づいて、初期プール・サイズおよび最大プール・サイズを構成できます。デフォルト値を使用し、検出したリソースの負荷に基づいて値を調節することをお薦めします。プールで使用されているリソースが多すぎる場合は、最大プール・サイズを小さくできます。システムのリソースに余裕があり、キューで待機中のリクエストが多すぎる場合は、最大プール・サイズを増やすことができます。

リクエスト・キューとレスポンス・キューを作成する(ステップ1)ためのベスト・プラクティスを次に挙げます。

- クラスタ内のキューを高可用性およびフェイルオーバーのために構成します。

- WebLogic Serverごとに単一のJMSサーバーとWebLogic永続ストアを構成し、ターゲットとしてサーバーのデフォルトの移行可能ターゲットを指定します。

- JMSサーバーに対して必要な割当て制限を構成します。
メモリー不足によるエラーを回避するため、各JMSサーバーに対してメッセージの最大割当て制限を構成することをお薦めします。目安として、各メッセージ・ヘッダーでは約512バイトが使用されます。したがって、500,000メッセージの最大割当て制限では、約250MBのメモリーが必要になります。環境で使用可能なメモリー・リソースを考慮して、それに応じた割当て制限を設定してください。

- 単一のJMSシステム・モジュールを構成し、ターゲットとしてクラスタを指定します。

- JMSシステム・モジュールに対して、次の手順を実行します。

- 単一のサブデプロイメントを構成し、各JMSサーバーを割り当てます。

- 必要な共通分散宛先を構成し、(前述の)拡張的なサブデプロイメントのターゲット指定を使用してターゲットを定義します。

- カスタムの接続ファクトリを構成します。トランザクションが有効になっている場合、接続ファクトリが有効であればトランザクションをサポートする必要があります。WebLogic JMSには、トランザクションをサポートするためのweblogic.jms.XAConnectionFactory接続ファクトリがデフォルトで用意されています。

実行時のリクエスト・キューおよびレスポンス・キューの管理

リクエスト・キューとレスポンス・キューは、Fusion Middleware Controlを使用すると実行時に変更できます。詳細は、『Webサービスの管理』の非同期Webサービスの構成に関する説明を参照してください。

リクエスト・キューおよびレスポンス・キューの保護

JMSのリクエスト・キューおよびレスポンス・キューをユーザーベースまたはロールベースのセキュリティ・ポリシーで保護して、これらのリソースへのアクセスを保護することをお薦めします。JMSのリクエスト・キューおよびレスポンス・キューを保護する手順は、次のとおりです。

1. JMSシステム・ユーザーの構成(オプション)に関する項の説明に従って、任意にJMSシステム・ユーザーを構成することもできます。
JMSキューへのアクセス権限を持つJMSシステム・ユーザーは、デフォルトではOracleSystemUserとして設定されています。通常はデフォルト・ユーザーで十分です。

2. リクエストとレスポンスのすべてのキューのセキュリティを確保するために、リクエスト・キューとレスポンス・キューの保護を目的としたWLSTスクリプトの実行に関する項の説明に従ってWLSTスクリプトを実行します。

JMSシステム・ユーザーの構成(オプション)

JMSキューへのアクセス権限を持つJMSシステム・ユーザーは、デフォルトではOracleSystemUserとして設定されています。ほとんどの場合、このデフォルト値で十分です。ただし、この値をセキュリティ・レルム内のカスタム・ユーザーに変更する必要がある場合は、@AsyncWebService注釈のsystemUser属性を使用してカスタム・システム・ユーザーを指定できます。次に例を示します。

@AsyncWebService(systemUser = "ABCIncSystemUser")

この変更を有効にするには、JDeveloperまたはojdeployコマンド・ライン・ユーティリティを使用してアプリケーションEARファイルを再生成する必要があります。@AsyncWebService注釈の詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。

アプリケーションのデプロイメントが済んだら、『Webサービスの管理』の非同期Webサービスに適したJMSシステム・ユーザーの変更に関する説明に従って、Fusion Middleware ControlおよびWebLogic Server Administration ConsoleのJMSシステム・ユーザーを変更できます。

リクエスト・キューおよびレスポンス・キューの保護を目的としたWLSTスクリプトの実行

リクエスト・キューとレスポンス・キューのセキュリティを確保する際は、オンラインWLSTスクリプトを使用できます。Administration Server接続に関する詳細(URL、ユーザー名およびパスワード)の他に、セキュリティをかけるJMSシステム・モジュール名と割り当てるセキュリティ・ロールを渡してください。

このスクリプトは次の場所にあります。

<MW_HOME>/oracle_common/webservices/bin/secure_jms_system_resource.py

このスクリプトの実行例を次に示します。

java -classpath <some_path>/weblogic.jar weblogic.WLST ./secure_jms_system_resource.py
--username <AdminUserName> --password <AdminPassword> --url <AdminServer_t3_url>
--jmsSystemResource <JMSSystemResourceName> --role <SecurityRoleToUse>

リクエストおよびレスポンスのキュー構成の確認

リクエスト・キューとレスポンス・キューが必要に応じて構成されていることを確認するには、次のタスクのいずれかを実行します。

1. 『Oracle WebLogic Server WebLogic Webサービスの理解』のAdministration Consoleの起動に関する説明に従って、Administration Consoleを起動します。

2. 次のJMSリソースが定義されており、「サービス」→「メッセージング」の順に選択して利用できることを確認します。

- JRFWSAsyncJmsServerという名前のJMSサーバー。
必要に応じて、JMSモジュールが、非クラスタ・ドメイン(標準的なキュー)については1つ以上のサーバーをターゲットとして指定していること、またはクラスタ・ドメイン(UDD)についてはそのクラスタをターゲットとして指定していることを確認します。構成ウィザードまたはWLSTを使用してドメインを構成している場合、JMSサーバーは適切にターゲット指定されています。詳細は、デフォルトのWebLogic JMSキューの使用に関する項を参照してください。

- JRFWSAsyncJmsModuleという名前のJMSモジュール。

- JDNI名がoracle.j2ee.ws.server.async.DefaultRequestQueueのリクエスト・キューとこれに対応するエラー・キュー。

- JDNI名がoracle.j2ee.ws.server.async.DefaultResponseQueueのレスポンス・キューとこれに対応するエラー・キュー。

3. 非同期Webサービスがデプロイされていることを確認し、必要があればシステムのメッセージドリブンBean(MDB)がJMS接続先に接続されていることを次のように検証します。

1. 「デプロイメント」をクリックします。

2. 「デプロイ」表のアプリケーションを開きます。

3. EJB直下に、非同期WebサービスのランタイムをサポートするためにWebサービス1件につき2つのシステムMDBが存在していることを確認します。例: <asyncwebservicename>_AsyncRequestProcessorMDBおよび<asyncwebservicename>_AsyncResponseProcessorMDB

4. 表示されている各MDBがJMS接続先に接続されていることを確認します。

5. 「EJB」を選択し、「監視」タブをクリックし、「実行中」タブをクリックします。

6. 「接続ステータス」フィールドが「接続」になっていることを確認します。

7. キューが正しく作成されなかった場合は、次の手順のいずれかを実行します。

- 必要なJMSキューを手動で作成して構成します。詳細は、『Oracle WebLogic Serverインフォメーション・ロードマップ』の「メッセージング」を参照してください。

- JMSサーバー、JMSモジュールおよび非同期Webサーバー用に作成されたデフォルト・キューを削除し、「デフォルトのWebLogic JMSキューの使用」の説明に従って、クラスタ・ドメインおよび非クラスタ・ドメイン用に指定された手順でもう一度これらを作成します。

注意:

JMSリソースは、そのドメインのconfig.xmlファイルに格納されます。

コールバック・サービスの構成

次の表に定義されている注釈を使用して、コールバック・サービス(portType)の特性をカスタマイズできます。これらの注釈は、oracle.webservices.annotations.asyncパッケージに含まれています。

表4-1 コールバック・サービスの構成に使用される注釈

注釈

説明

@CallbackMethod

コールバックportType内の対応する操作のWSDLエンティティの名前をカスタマイズし、メソッドが同期か非同期かを設定します。

次に例を示します。

@CallbackMethod(exclude=true)

詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。

@CallbackProperties

コールバック・サービスをコールするときにメッセージ・コンテキスト内で必須となるプロパティを指定します。

次に例を示します。

@CallbackProperties(
{
@Property(
key = SecurityConstants.ClientConstants.WSS_CSF_KEY,
value = "basic.credentials")
}
)

詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。

@Property

コールバック・サービスをコールするときにメッセージ・コンテキスト内で必須となるプロパティを指定します。

次に例を示します。

@CallbackProperties(
{
@Property(
key = SecurityConstants.ClientConstants.WSS_CSF_KEY,
value = "basic.credentials")
}
)

詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。

@ResponseWebService

レスポンスWebサービス・ポート情報をカスタマイズします。詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。

@Retry

システム障害などによって実行が異常終了した場合、この非同期メソッドを多重呼出し不変とするか再試行可能とするか指定します。

デフォルトでは、すべての非同期メソッドは多重呼出し不変で、これは非同期メソッドを2回以上コールしても副次的な影響がないことを意味します。非同期メソッドが多重呼出し不変でない場合は、明示的にこの注釈のenable属性にfalseを設定する必要があります。

詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。

非同期WebサービスのためのSSL構成

非同期Webサービス用にSSLを構成するには、次のタスクを実行する必要があります。

1. keytoolを使用してIDキーストアおよび信頼キーストアを作成します。
『Oracle WebLogic Serverセキュリティの管理』の秘密鍵、デジタル証明書、信頼性のある認証局の取得に関する説明を参照してください。

2. Oracle WebLogic Server Administration Consoleを使用して、キーストア、キーストア・タイプおよびIDキーストアと信頼キーストアのパスワードを構成します。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する説明を参照してください。

3. Fusion Middleware Controlを使用して、OWSM資格証明ストア・プロバイダでのIDキーストアと信頼キーストアのパスワードを構成します。
『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の資格証明ストアの構成に関する説明を参照してください。

oracle.ws.async.ssl.securityという名前のマップが存在することを確認します。存在しない場合は、これを作成する必要があります。

続いて、次の表で定義されている3つのキー・エントリを作成します。

表4-2 IDキーストアおよび信頼キーストアの構成

キー

ユーザー名

パスワード

trust-keystore-password

async

<trust_store_password>

identity-keystore-password

async

<identity_store_password>

key-password

async

<key_password>

非同期Webサービス・クライアントの定義

次の各項で、非同期クライアントおよび生成されるコールバック・サービスの例を示し、実施する必要のある更新について説明します。

- 非同期クライアント・コードの更新

- コールバック・サービス・コードの更新

非同期クライアント・コードの更新

次の例は、非同期Webサービスをサポートするために生成されるクライアント・コードを示しています。太字で示されているように、クライアント・コードではアウトバウンド・ヘッダー内に2つのフィールドを設定する必要があります。

- ReplyToアドレス: コールバック・サービスのアドレス。

- MessageID: リクエストを識別する一意のID。たとえば、UUIDなどです。

ほとんどの場合は生成されたクライアント・コードに含まれるメッセージIDのUUIDで間に合いますが、このUUIDを更新することもできます。コールバック・サービスを指し示すようにReplyToアドレスを更新する必要があります。

例4-1 非同期クライアント・コードの更新

package async.jrf;

import com.sun.xml.ws.api.addressing.AddressingVersion;
import com.sun.xml.ws.api.addressing.WSEndpointReference;
import com.sun.xml.ws.developer.WSBindingProvider;
import com.sun.xml.ws.message.StringHeader;
import java.util.UUID;
import javax.xml.ws.WebServiceRef;

// !THE CHANGES MADE TO THIS FILE WILL BE DESTROYED IF REGENERATED!
// This source file is generated by Oracle tools
// Contents may be subject to change

// For reporting problems, use the following
// Version = Oracle WebServices (11.1.1.0.0, build 090303.0200.48673)

public class HelloServicePortClient
{
@WebServiceRef
private static HelloServiceService helloServiceService;
private static final AddressingVersion WS_ADDR_VER = AddressingVersion.W3C;

public static void main(String [] args)
{
helloServiceService = new HelloServiceService();
HelloService helloService = helloServiceService.getHelloServicePort();
// Get the request context to set the outgoing addressing properties
WSBindingProvider wsbp = (WSBindingProvider)helloService;
WSEndpointReference repl
new WSEndpointReference(
"http://<replace with the URL of the callback service>",
WS_ADDR_VER);
String uuid = "uuid:" + UUID.randomUUID();
wsbp.setOutboundHeaders(
new StringHeader(WS_ADDR_VER.messageIDTag, uuid),
replyTo.createHeader(WS_ADDR_VER.replyToTag));
// Add your code to call the desired methods.
}
}

コールバック・サービス・コードの更新

次の例は、コールバック・サービス・コードを示しています。太字で示されたコードは、クライアントからMessageIDとして送信されたメッセージ・ヘッダーからrelatesToIDを抽出する方法を示しています。

レスポンスを処理してコールバック・サービスをWebサービスとしてデプロイするためのコードを実装する必要があります。デプロイした後は、コールバック・サービスのURLをreplyToフィールドとしてクライアント・コードに追加します。

package async.jrf;

import com.sun.xml.ws.api.addressing.AddressingVersion;
import com.sun.xml.ws.api.message.Header;
import com.sun.xml.ws.api.message.HeaderList;
import com.sun.xml.ws.developer.JAXWSProperties;
import javax.annotation.Resource;
import javax.jws.Oneway;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
import javax.xml.bind.annotation.XmlSeeAlso;
import javax.xml.ws.Action;
import javax.xml.ws.RequestWrapper;
import javax.xml.ws.WebServiceContext;
import javax.xml.ws.soap.Addressing;
// !THE CHANGES MADE TO THIS FILE WILL BE DESTROYED IF REGENERATED!
// This source file is generated by Oracle tools
// Contents may be subject to change
// For reporting problems, use the following
// Version = Oracle WebServices (11.1.1.0.0, build 090303.0200.48673)

@WebService(targetNamespace="http://jrf.async/", name="HelloServiceResponse")
@XmlSeeAlso(
{ async.jrf.ObjectFactory.class })
@SOAPBinding(style=Style.DOCUMENT)
@Addressing(enabled=true, required=true)
public class HelloServiceResponseImpl
{
@Resource
private WebServiceContext wsContext;
private static final AddressingVersion WS_ADDR_VER = AddressingVersion.W3C;
@WebMethod
@Action(input="")
@RequestWrapper(localName="helloResponse",targetNamespace="http://jrf.async/",
className="async.jrf.HelloResponse")
@Oneway
public void helloResponse(@WebParam(targetNamespace="", name="return")
String _return)
{
// Use the sample code to extract the relatesTo id for correlation and then add your rest of the logic
System.out.println("Received the asynchronous reply");
// get the messageId to correlate this reply with the original request
HeaderList headerList = (HeaderList)wsContext.getMessageContext().get(JAXWSProperties.INBOUND_HEADER_LIST_PROPERTY);
Header realtesToheader = headerList.get(WS_ADDR_VER.relatesToTag, true);
String relatesToMessageId = realtesToheader.getStringContent();
System.out.println("RelatesTo message id: " + relatesToMessageId);
// Add your implementation here.
}
}

非同期Webサービスおよびクライアントへのポリシーのアタッチ

ポリシーは次の非同期コンポーネントにアタッチできます。

- 非同期Webサービスをコールするクライアント(「非同期Webサービス・クライアントへのポリシーのアタッチ」を参照)。

- 非同期Webサービス(「非同期コールバック・サービスへのポリシーのアタッチ」を参照)。

- 非同期コールバック・クライアント(「コールバック・クライアントへのポリシーのアタッチ」を参照)。

- 非同期コールバックサービス(「非同期コールバック・サービスへのポリシーのアタッチ」を参照)。

非同期Webサービスとクライアント・ポリシーは互いに適合している必要があります。同様に、非同期コールバック・クライアントとコールバック・サービス・ポリシーも互いに適合している必要があります。

ポリシーをコンポーネントにアタッチするには、次のいずれかの方法を使用できます。

- 設計時に注釈を使用。

- 実行時にFusion Middleware Controlを使用。

次の各項で、それぞれの方法について詳しく説明します。

注意:

oracle/wsaddr_policyは、再度、非同期のWebサービスまたはクライアントにアタッチする必要はありません。oracle/wsaddr_policyポリシーはデフォルトですべての非同期Webサービスおよびクライアントにアタッチされ、WSDLで通知されます。これは、非同期Webサービスの処理で必要となるためです。しかし、Fusion Middleware Controlにはポリシーがアタッチされていることは反映されないため、ポリシーをアタッチする際の使用可能なポリシーリストではこのポリシーが選択可能になっています(『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のポリシーのアタッチに関する説明を参照)。

非同期Webサービス・クライアントへのポリシーのアタッチ

実行時には、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のFusion Middleware Controlを使用したWebサービスおよびクライアントへのポリシーのアタッチに関する説明に従って、Fusion Middleware Controlを使用してクライアントの各タイプにポリシーをアタッチできます。

非同期コールバック・サービスへのポリシーのアタッチ

設計時には、クライアントのコールバック・サービスへの非同期レスポンスの送信中にポリシーをアタッチするために、表4-3に定義されているいずれかの注釈を使用できます。

表4-3 ポリシーをWebサービスおよびコールバック・サービスにアタッチするための注釈

注釈

説明

@CallbackManagementPolicy

oracle.webservices.annotations.async.CallbackManagementPolicy注釈は、管理ポリシーを、クライアントのコールバック・サービスに非同期レスポンスを送信するときにアタッチします。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackManagementPolicyに関する説明を参照してください。

注意: この注釈は非推奨です。『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackPolicySetに関する項で説明するoracle.wsm.metadata.annotation.CallbackPolicySet注釈を使用することをお薦めします。

@CallbackMtomPolicy

oracle.webservices.annotations.async.CallbackMtomPolicy注釈は、MTOMポリシーを、クライアントのコールバック・サービスに非同期レスポンスを送信するときにアタッチします。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackMtomPolicyに関する説明を参照してください。

注意: この注釈は非推奨です。『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackPolicySetに関する項で説明するoracle.wsm.metadata.annotation.CallbackPolicySet注釈を使用することをお薦めします。

@CallbackPolicySet

oracle.wsm.metadata.annotation.CallbackPolicySet注釈は、1つ以上のポリシー・セットを、コールバック・サービスに接続される非同期Webサービスのコールバック・クライアントにアタッチします。デフォルトではいずれのポリシーもアタッチされません。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackPolicySetに関する説明を参照してください。

@CallbackSecurityPolicy

oracle.webservices.annotations.async.CallbackSecurityPolicy注釈は、セキュリティ・ポリシーをコールバックWebサービスにアタッチします。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackSecurityPolicyに関する説明を参照してください。

注意: この注釈は非推奨です。『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackPolicySetに関する項で説明するoracle.wsm.metadata.annotation.CallbackPolicySet注釈を使用することをお薦めします。

@FastInfosetCallbackClient

com.oracle.webservices.api.FastInfosetCallbackClient注釈は、Fast Infosetを、コールバック・サービスに接続される非同期Webサービスのコールバック・クライアントで有効化して構成します。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@FastInfosetCallbackClientに関する説明を参照してください。

実行時には、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のポリシーのアタッチに関する説明に従って、Fusion Middleware Controlを使用して非同期コールバック・サービスにポリシーをアタッチできます。

メッセージ保護ポリシーを非同期コールバック・サービスにアタッチする際には、次のガイドラインを使用してください。

- コールバック・サービスにメッセージ保護ポリシーを適用する場合は、非同期リクエストにもそのメッセージ保護ポリシーを適用する必要があります。そうしない場合、非同期クライアントの公開暗号化証明書が見つからないことを示すエラーが実行時に返されます。
非同期リクエストにメッセージ保護ポリシーを適用する場合は、コールバック・サービスに同じポリシーを適用する必要はありません。

- 非同期Webサービスにメッセージ保護ポリシーを適用する場合は、クライアント・キーストア内のクライアント公開暗号化証明書を構成する必要があります。

コールバック・クライアントへのポリシーのアタッチ

注意:

コールバック・クライアントにアタッチしたポリシーは、非同期WebサービスWSDLで通知されます。

実行時には、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のポリシーの非同期Webサービスのコールバック・クライアントへのアタッチに関する説明に従って、Fusion Middleware Controlを使用して非同期コールバック・クライアントにポリシーをアタッチできます。

5 Webサービスの信頼性のあるメッセージングの使用

この章では、Oracle Infrastructure Webサービスで、Webサービスの信頼性のあるメッセージング(WS-ReliableMessaging)を使用して安全にメッセージを交換する方法について説明します。

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

- Webサービスの信頼性のあるメッセージングの概要

- 事前定義済の信頼性のあるメッセージング・ポリシー

- 信頼性のあるメッセージング・ポリシーのアタッチ

- 信頼性のあるメッセージング・ポリシーの構成

Webサービスの信頼性のあるメッセージングの概要

Webサービス間でのメッセージ交換は、ネットワーク、システム、ソフトウェア・コンポーネントのエラーや異常など、様々なエラーによって中断されることがあります。Webサービスまたはクライアントがメッセージを送信した後で、そのメッセージが正常に配信されたか、配信が失敗して再送信が必要か、あるいは一連のメッセージが正しい順序で到着したかどうかをすぐに判断するためには、ネットワークレベルの例外やSOAPフォルト・メッセージを調べる以外に方法はありません。

これらの問題を解決するために、Oracle Infrastructure Webサービスでは、http://docs.oasis-open.org/ws-rx/wsrm/v1.2/wsrm.pdfのWebサービスの信頼性のあるメッセージング(WS-ReliableMessaging)仕様で定義されているメッセージング・プロトコルをサポートしています。この仕様は、信頼性のあるメッセージ交換を行うためのプロトコルを記述したものです。信頼性のあるとは、2つのWebサービス間でのメッセージの配信を保証できるということです。ソフトウェア・コンポーネント、システムまたはネットワークの障害に関係なく、分散アプリケーション間でメッセージの信頼性のある配信が確実に行われる必要があります。順序付き配信が保証されているため、クライアント・アプリケーションごとに、失敗したメッセージの自動再送信をコーディングする必要はありません。

信頼性のあるWebサービスには、次の配信保証が備わっています。

表5-1 信頼性のあるメッセージングの配信保証

配信保証

説明

最大1回

メッセージは最大1回、重複なしに配信されます。メッセージによっては、一度も配信されないこともあります。

最低1回

すべてのメッセージが、少なくとも1回配信されます。メッセージによっては、2回以上配信されることもあります。

1回のみ

すべてのメッセージが、必ず1回重複なしに配信されます。

順序どおり

メッセージは送信時の順序で配信されます。この配信の保証は、前述の3つの保証のいずれかと組み合せることができます。

Webサービスで次の問題が発生している場合は、信頼性のあるメッセージングの使用を検討してください。

- ネットワーク障害または接続切断が発生します。

- メッセージが送信中に消失します。

- メッセージが間違った順序で宛先に到着します。

事前定義済の信頼性のあるメッセージング・ポリシー

信頼性のあるメッセージングは、ポリシーおよびポリシー・フレームワークによって実施されます。第2章「Oracle Infrastructure Webサービスへのポリシーのアタッチ」で説明されているように、OWSMには、Oracle Fusion Middlewareをインストールすると自動的に使用可能になる一連の事前定義済ポリシーが用意されています。

表5-2にリストされている信頼性のあるメッセージング・ポリシーは、即時に利用可能です。

表5-2 事前定義済の信頼性のあるメッセージング・ポリシー

信頼性のあるメッセージング・ポリシー

説明

oracle/no_reliable_messaging_policy

エンドポイントに直接アタッチされている場合、または下位スコープでグローバルにアタッチされている場合、グローバルにアタッチされたWebサービスの信頼性のあるメッセージング・ポリシーを上位スコープで効率よく無効化します。

oracle/reliable_messaging_policy

Webサービスおよびクライアントで、Webサービスの信頼性のあるメッセージングを構成します。

事前定義済の信頼性のあるメッセージング・ポリシーの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の信頼性のあるメッセージング・ポリシーに関する説明を参照してください。

信頼性のあるメッセージング・ポリシーのアタッチ

Oracle Infrastructure Webサービスまたはクライアントに信頼性のあるメッセージング・ポリシーをアタッチします。設計時にはOracle JDeveloperを使用して、実行時にはFusion Middleware Controlを使用して行います。詳細は、第2章「Oracle Infrastructure Webサービスへのポリシーのアタッチ」を参照してください。

信頼性のあるメッセージング・ポリシーの構成

信頼性のあるメッセージング・ポリシーを環境内で使用するには、あらかじめ構成する必要があります。信頼性のあるメッセージング・ポリシーの構成手順の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の信頼性のあるメッセージング・ポリシーに関する説明を参照してください。

6 Webサービス原子性トランザクションの使用

この章では、Webサービス原子性トランザクションを使用して、他の外部トランザクション処理システムとの相互運用を可能にする方法について説明します。

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

- Webサービス原子性トランザクションの概要

- WebサービスでのWebサービス原子性トランザクションの有効化(インバウンド)

- Webサービス・クライアントでのWebサービス原子性トランザクションの有効化(アウトバウンド)

- Webサービス原子性トランザクションの構成

- コーディネータと参加者の間で交換されるメッセージの保護

Webサービス原子性トランザクションの概要

WebLogic Webサービスは、次の仕様のサポートを通じて、Websphere、Microsoft .NETなどの他の外部トランザクション処理システムとの相互運用を可能にします。

- WS-AtomicTransaction (WS-AT)バージョン1.0、1.1および1.2: http://docs.oasis-open.org/ws-tx/wstx-wsat-1.2-spec-cs-01/wstx-wsat-1.2-spec-cs-01.html

- WS-Coordinationバージョン1.0、1.1および1.2: http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.2-spec-cs-01/wstx-wscoor-1.2-spec-cs-01.html

これらの仕様は、一連の参加者の間で分散アクティビティを調整するための拡張可能なフレームワークを定義します。次の図に示されているコーディネータは中央のコンポーネントで、トランザクションの状態(調整コンテキスト)を管理し、Webサービスおよびクライアントを参加者として登録することを可能にします。

図6-1 Webサービス原子性トランザクション・フレームワーク

「図6-1 Webサービス原子性トランザクション・フレームワーク」の説明

次の表で、この図に示されているWebサービス原子性トランザクションのコンポーネントについて説明します。

表6-1 Webサービス原子性トランザクションのコンポーネント

コンポーネント

説明

コーディネータ

トランザクションの状態(調整コンテキスト)を管理し、Webサービスおよびクライアントを参加者として登録することを可能にします。

アクティブ化サービス

アプリケーションによるトランザクションのアクティブ化およびアクティビティの調整コンテキストの作成を可能にします。作成された調整コンテキストは、トランザクション・フローとともに渡されます。

登録サービス

アプリケーションを参加者として登録することを可能にします。

アプリケーション・プロトコルX、Y

サポートされている調整プロトコル(WS-AtomicTransactionなど)。

次の図は、Webサービス原子性トランザクションのコンテキスト内で相互に作用する2つのWebLogic Serverインスタンスを示しています。わかりやすくするために、2つのWebLogic Webサービス・アプリケーションを示しています。

図6-2 WebLogicサーバー環境内のWebサービス原子性トランザクション

「図6-2 WebLogicサーバー環境内のWebサービス原子性トランザクション」の説明

次のことに注意してください。

- ローカルJTAトランザクション・マネージャを使用すると、すべてWebサービス・リクエストのコンテキスト内で、トランザクションを下位トランザクションとしてローカルなJTA環境との間でインポートおよびエクスポートできます。

- 調整コンテキストの作成と管理は、ローカルJTAトランザクション・マネージャによって行われます。

- トランザクションの整合性管理とリカバリ処理はすべて、ローカルJTAトランザクション・マネージャによって行われます。

JTAの詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』を参照してください。

次に、図6-2に示されているエンドツーエンドのWebサービス原子性トランザクションの相互作用の例について説明します。

1. アプリケーションAは、サーバーAでJTAトランザクション・マネージャを使用して、コントロールの現行スレッドに対するトランザクションを開始します。

2. アプリケーションAは、サーバーBのアプリケーションBでWebサービス・メソッドをコールします。

3. サーバーAはトランザクション情報を更新し、調整コンテキストを含むSOAPヘッダーを作成して、トランザクションおよびローカル・コーディネータを指定します。

4. サーバーBは、アプリケーションBのリクエストを受信して、ヘッダーにトランザクション調整コンテキストが含まれていることを検出し、アプリケーションBがこのトランザクションの参加者としてすでに登録されているかどうかを判断します。すでに登録されていれば、そのトランザクションは再開されます。登録されていない場合は、新しいトランザクションが開始されます。
アプリケーションBは、インポート済トランザクションのコンテキスト内で実行されます。アプリケーションの対話に使用されるすべてのトランザクション・リソースは、このインポート済トランザクションに登録されます。

5. サーバーBは、トランザクション調整コンテキスト内で指定されている登録サービスを使用して、WS-ATトランザクションの参加者として自身を登録します。

6. サーバーAはトランザクションを再開します。

7. アプリケーションAは処理を再開し、トランザクションをコミットします。

WebサービスでのWebサービス原子性トランザクションの有効化(インバウンド)

Webサービスで、Webサービス原子性トランザクションを有効化および構成します。設計時にはOracle JDeveloperを使用してWebサービスの作成時に、デプロイ時にはFusion Middleware Controlを使用して行います。詳細は、次の項を参照してください。

- 『Webサービスの管理』のFusion Middleware Controlを使用したWebサービス原子性トランザクションの構成に関する説明

- 『Webサービスの管理』のWLSTを使用した原子性トランザクションの構成に関する説明

構成オプションの詳細は、「Webサービス原子性トランザクションの構成」を参照してください。

Webサービス・クライアントでのWebサービス原子性トランザクションの有効化(アウトバウンド)

Webサービス・クライアントで、設計時にFusion Middleware Controlを使用して、Webサービス原子性トランザクションを有効化および構成します。表6-3に定義されているように、バージョンおよびフロー・タイプを構成します。

Webサービス原子性トランザクションを有効化および構成します。設計時にはOracle JDeveloperを使用してWebサービスを作成するときに行い、デプロイ時にはFusion Middleware Controlを使用して行います。詳細は、次の項を参照してください。

- 『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の原子性トランザクションのポリシーに関する説明。

構成オプションの詳細は、「Webサービス原子性トランザクションの構成」を参照してください。

Webサービス原子性トランザクションの構成

次の表は、Webサービス原子性トランザクションを有効化する際に設定できる構成オプションをまとめたものです。Webサービス原子性トランザクションの詳細は、「WebサービスでのWebサービス原子性トランザクションの有効化(インバウンド)」および「Webサービス・クライアントでのWebサービス原子性トランザクションの有効化(アウトバウンド)」を参照してください。

表6-2 Webサービス原子性トランザクションの構成オプション

属性

説明

バージョン

サポートされるWebサービス原子性トランザクションの調整コンテキストのバージョン。Webサービス・クライアントの場合、アウトバウンド・メッセージにのみ使用されるバージョンが指定されます。トランザクション全体で同じ値を指定する必要があります。

有効な値は、WSAT10、WSAT11、WSAT12およびDEFAULTです。

WebサービスのDEFAULT値は、インバウンド・リクエストに基づくもので、任意の値になります。

Webサービス・クライアントのDEFAULT値は次のとおりです。

- フロー・オプションがWSDLDRIVENの場合、WSDLで通知されたバージョンが使用されます。

- フロー・オプションがWSDLDRIVEN以外の設定の場合は、WSAT10が使用されます。

フロー・タイプ

Webサービス原子性トランザクション調整コンテキストがトランザクション・フローとともに渡されるかどうかを指定します。有効な値は、表6-3を参照してください。

次の表は、フロー・タイプの有効な値およびWebサービスおよびクライアントでのそれらの意味をまとめたものです。また、@TransacationAttribute注釈を使用するEJB型のWebサービスに対してWebサービス原子性トランザクションを構成する際の有効な値の組合せも示しています。

表6-3 フロー・トランザクションの調整コンテキスト・タイプの値

値

Webサービス・クライアント

Webサービス

EJB @TransactionAttributeの有効な値

NEVER

JTAトランザクションがある場合: トランザクションの調整コンテキストをエクスポートしません。

JTAトランザクションがない場合: トランザクションの調整コンテキストをエクスポートしません。

トランザクション・フローが存在する場合: トランザクションの調整コンテキストをインポートしません。CoordinationContextヘッダーにmustunderstand="true"が含まれている場合は、SOAPフォルトがスローされます。

トランザクション・フローがない場合: トランザクションの調整コンテキストをインポートしません。

NEVER、NOT_SUPPORTED、REQUIRED、REQUIRES_NEW、SUPPORTS

SUPPORTS

JTAトランザクションがある場合: トランザクションの調整コンテキストをエクスポートします。

JTAトランザクションがない場合: トランザクションの調整コンテキストをエクスポートしません。

トランザクション・フローが存在する場合: トランザクション・コンテキストをインポートします。

トランザクション・フローがない場合: トランザクションの調整コンテキストをインポートしません。

SUPPORTS、REQUIRED

MANDATORY

JTAトランザクションがある場合: トランザクションの調整コンテキストをエクスポートします。

JTAトランザクションがない場合: 例外がスローされます。

トランザクション・フローが存在する場合: トランザクション・コンテキストをインポートします。

トランザクション・フローがない場合: サービス側の例外がスローされます。

MANDATORY、REQUIRED、SUPPORTS

コーディネータと参加者の間で交換されるメッセージの保護

コーディネータと参加者の間で交換されるメッセージを保護するには、WebLogic Server管理コンソールを使用して、次の表に定義されているプロパティを構成します。これらのプロパティは、ドメイン・レベルで構成します。詳細な手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebサービス原子性トランザクションの構成に関する説明を参照してください。

表6-4 Webサービス原子性トランザクションの保護

プロパティ

説明

Webサービス・トランザクションのトランスポート・セキュリティ・モード

コーディネータと参加者の間のメッセージ交換に双方向SSLを使用するかどうかを指定します。このプロパティは、次のいずれかの値に設定できます。

- SSLは不要: Webサービス・トランザクションのプロトコル・メッセージはすべて、HTTPチャネル経由で交換されます。

- SSLが必要: Webサービス・トランザクションのプロトコル・メッセージはすべて、HTTPSチャネル経由で交換されます。このフラグは、原子性トランザクションが有効になっているMicrosoft .NET Webサービスを起動する際に有効にする必要があります。

- クライアント証明書が必要: Webサービス・トランザクションのプロトコル・メッセージはすべてHTTPS経由で交換され、クライアント証明書が必要となります。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの双方向SSLの構成に関する説明を参照してください。

Webサービス・トランザクションの発行済みトークンを有効化

IssuedTokenを使用してWebサービス原子性トランザクションのコーディネータと参加者の間の認証を有効にするかどうかを指定するフラグ。

IssuedTokenは、コーディネータによって発行され、セキュリティ・コンテキスト・トークン(SCT)と署名用のセッション・キーで構成されます。参加者は、共有セッション・キーを使用して署名した署名を登録メッセージに入れて送信します。コーディネータは、セッション・キーを使用して署名を検証することにより、参加者を認証します。

7 Fast Infosetを使用したXML送信の最適化

この章では、Oracle Infrastructure WebサービスでFast Infosetを使用する方法について説明します。

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

- Fast Infosetの概要

- WebサービスでのFast Infosetの有効化

- Webサービス・クライアントでのFast Infosetの有効化と構成

- WebサービスおよびクライアントでのFast Infosetの無効化

Fast Infosetの概要

Fast Infosetは、圧縮されたバイナリ・エンコーディング形式で、テキストベースのXML形式よりも効果的なシリアライズを実現します。Fast Infosetは、ドキュメント・サイズと処理パフォーマンスの両方を最適化します。

有効にすると、データ送信の前に、Fast InfosetによってSOAPエンベロープ内のXML情報セットが圧縮されたバイナリ形式に変換されます。Fast Infosetは、暗号化され署名されたメッセージ、MTOM対応のメッセージおよびSOAP添付ファイルを最適化し、HTTPトランスポートとJMSトランスポートの両方をサポートします。

デフォルトでは、Fast Infoset機能は、すべてのWebサービスで有効になっています。Webサービス・クライアントの場合、Fast Infosetは、Webサービスで有効化されWSDLで通知された場合にのみ有効になります。

次の項の手順に従って、WebサービスまたはクライアントでFast Infosetを明示的に有効化し構成できます。

WebサービスでのFast Infosetの有効化

デフォルトでは、Fast Infoset機能はWebサービスで有効に設定され、WSDLによって通知されています。次のいずれかの方法を使用して、WebサービスでFast Infosetを明示的に有効化できます。

- 設計時には、「設計時に@FastInfosetService注釈を使用する例」に示すように、com.oracle.webservices.api.FastInfosetService注釈を使用します。この注釈の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@FastInfosetServiceに関する説明を参照してください。

- デプロイ後は、oracle/fast_infoset_service_policyをWebサービスにアタッチします。詳細は、次の項を参照してください。

- 『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のFusion Middleware Controlを使用したWebサービスおよびクライアントへのポリシーのアタッチに関する説明。

- 『Webサービスの管理』のWLSTを使用したFast Infosetの構成に関する説明。

設計時に@FastInfosetService注釈を使用する例

次に示すコードの抜粋は、com.oracle.webservices.api.FastInfosetService注釈を使用して、設計時にWebサービスでFast Infosetを有効化し構成する例を示しています。

package examples.webservices.fastinfoset;
import com.oracle.webservcies.api.FastInfosetService;
import oracle.webservices.annotations.PortableWebService;
import javax.jws.WebMethod;

@PortableWebService
@FastInfosetService(enabled = true)
public class HelloImplFastInfosetEnabled {
@WebMethod
public String hello(String name) {
return "Hello, " + name + "! (from FI Enabled Service)";
}
}

@PortableWebService注釈の詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。

Webサービス・クライアントでのFast Infosetの有効化と構成

次のいずれかの方法を使用して、Webサービス・クライアントでFast Infosetを明示的に有効化して構成できます。

- 設計時には、「設計時にFastInfosetClientFeature機能を使用する例」に示すように、com.oracle.webservices.api.FastInfosetClientFeature機能を使用します。

- デプロイ後は、oracle/fast_infoset_client_policyをWebサービスにアタッチします。詳細は、次の項を参照してください。

- 『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のFusion Middleware Controlを使用したWebサービスおよびクライアントへのポリシーのアタッチに関する説明。

- 『Webサービスの管理』のWLSTを使用したFast Infosetの構成に関する説明。

コンテンツ・ネゴシエーション方針の構成

クライアントでFast Infosetを有効化する際に、コンテンツ・ネゴシエーション・ポリシーを構成できます。表7-1は、com.oracle.webservices.api.FastInfosetContentNegotiationTypeで定義する、有効なコンテンツ・ネゴシエーション方針をまとめたものです。

表7-1 コンテンツ・ネゴシエーション方針

値

説明

OPTIMISTIC

サービスでFast Infosetが有効になっていると想定します。すべてのリクエストはFast Infosetを使用して送信されます。

PESSIMISTIC

クライアントからの最初のリクエストはFast Infosetを有効にせずに送信されますが、クライアントがFast Infoset機能をサポートしていることを示すHTTP Acceptヘッダーが付きます。サービス・レスポンスがFast Infoset形式である場合は、サービスでFast Infosetが有効になっていると確認し、クライアントからのそれ以降のリクエストはFast Infoset形式で送信されます。

NONE

クライアント・リクエストはFast Infosetを使用しません。

次のことに注意してください。

- コンテンツ・ネゴシエーション方針がクライアントで明示的に構成されている場合:

- WSDLで通知されたネゴシエーション方針よりも優先されます。

- 構成されたコンテンツ・ネゴシエーション方針が、サービスによって通知された機能と競合する場合(たとえば、クライアントではOPTIMISTICが構成され、サービスではFast Infosetを無効にしていた場合)には例外が発生します。

- コンテンツ・ネゴシエーション方針がクライアントで明示的に構成されていない場合:

- サービスでFast Infosetが有効化され通知されている場合は、OPTIMISTICコンテンツ・ネゴシエーション方針が使用されます。

- サービスでFast Infosetが無効化され通知されていない場合には、NONEコンテンツ・ネゴシエーション方針が使用されます。

設計時にFastInfosetClientFeature機能を使用する例

次に示すコードの抜粋は、com.oracle.webservices.api.FastInfosetClientFeature機能クラスを使用して、設計時にWebサービスでFast Infosetを有効化し構成する例を示しています。

package examples.webservices.fastinfoset;
import com.oracle.webservices.api.FastInfosetClientFeature;
import com.oracle.webservices.api.FastInfosetContentNegotiationType;
import javax.xml.ws.WebServiceRef;
...
public class HelloServicePortClient {
@WebServiceRef
private static HelloServiceService helloServiceService;

public static void main(String [] args)
{
FastInfosetContentNegotiationType clientNeg =
FastInfosetContentNegotiationType.PESSIMISTIC;
FastInfosetClientFeature feature = FastInfosetClientFeature.builder().fastInfosetContentNegotiation(clientNeg).enabled(true).build();
helloServiceService = new HelloServiceService();
HelloService helloService =
helloServiceService.getHelloServicePort(feature);
...
}

WebサービスおよびクライアントでのFast Infosetの無効化

設計時にFast Infosetを明示的に無効化する場合:

- 「WebサービスでのFast Infosetの有効化」の説明に従って、Webサービスで注釈のenabledフラグをfalseに設定します。

- 「Webサービス・クライアントでのFast Infosetの有効化と構成」の説明に従って、Webサービス・クライアントの注釈またはFeatureクラスで、enabledフラグをfalseに設定するか、コンテンツ・ネゴシエーション方針をNONEに設定します。

次に示すコードの抜粋は、com.oracle.webservices.api.FastInfosetService注釈を使用して、設計時にWebサービスでFast Infosetを無効化する例を示しています。

package examples.webservices.fastinfoset;
import com.oracle.webservices.api.FastInfosetService;
...
@PortableWebService
@FastInfosetService(enabled = false)
public class HelloImplFastInfosetDisabled{
@WebMethod
public String hello(String name) {
return "Hello, " + name + "! (from FI Disabled Service)";
}
}

デプロイ後にFast Infosetを無効化する場合:

- oracle/fast_infoset_service_policyまたはoracle/fast_infoset_client_policyポリシーを、それぞれWebサービスまたはクライアントからデタッチします。
詳細は、次の各項を参照してください。

- 『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のFusion Middleware Controlを使用したWebサービスおよびクライアントへのポリシーのアタッチに関する説明。

- 『Webサービスの管理』のWLSTを使用したFast Infosetの構成に関する説明。

- Fast Infosetをグローバルに無効化するには、Webサービスまたはクライアントの上位スコープで、それぞれoracle/no_fast_infoset_service_policyまたはoracle/no_fast_infoset_client_policyポリシーを含むポリシー・セットを定義します。
詳細は、次の各項を参照してください。

- 『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のポリシー・セットを使用したポリシーのグローバルなアタッチに関する説明。

- 『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のWLSTによるポリシー・セットを使用したポリシーのグローバルなアタッチに関する説明。

8 MTOMエンコード・メッセージ添付ファイルの使用

この章では、メッセージ転送最適化メカニズム(MTOM)形式でエンコードされたメッセージがOracle Infrastructure Webサービスにより処理される方法について説明します。

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

- メッセージ転送最適化メカニズムの概要

- 事前定義済のMTOMアタッチメント・ポリシー

- MTOMポリシーのアタッチ

- MTOMポリシーの構成

メッセージ転送最適化メカニズムの概要

クライアントとWebサービス間で、JPEG形式のイメージなどのバイナリ・コンテンツを受渡しできます。受渡しを可能にするために、バイナリ・コンテンツは通常、xsd:base64Binary文字列としてXMLドキュメントに挿入されます。この形式でバイナリ・コンテンツを送信すると、伝送中の送信メッセージのサイズが大幅に増え、処理に要する空間と時間の点でコストが高くなります。

MTOMを使用すると、バイナリ・コンテンツをMIME添付ファイルとして送信できるため、ワイヤ書式の送信サイズを小さくできます。バイナリ・コンテンツは意味的にXMLドキュメントの一部です。メッセージ上のWS-Security署名などの操作を適用できる点で、SWA(添付ファイル付きのSOAPメッセージ)よりも優れています。詳細は次の仕様を参照してください。

- SOAP 1.2: http://www.w3.org/TR/2005/REC-soap12-mtom-20050125

- SOAP 1.1: http://www.w3.org/Submission/2006/SUBM-soap11mtom10-20060405

MTOMを使用してバイナリ・コンテンツを添付ファイルとして渡すと、Webサービス・スタックのパフォーマンスが向上します。MTOMエンコード・メッセージにバイナリ・コンテンツが含まれていない場合、パフォーマンスは影響を受けません。

MTOMは、SOAP 1.2メッセージ用の最適化された送信メカニズムに、XMLスキーマ型xs:base64Binaryの要素を含むエンベロープを提供します。MTOMは、次の仕様で説明されているデータ処理メカニズムを利用します。

- XOP (XML-binary Optimized Packaging): コンテンツの型がxs:base64BinaryのXML Infosetをより効率的にシリアライズするためのメカニズムを提供します。XOP仕様は、Webサイトhttp://www.w3.org/TR/xop10/で入手可能です。

- DMCBDX (Describing Media Content of Binary Data in XML): コンテンツ型の情報をXMLインスタンスおよびスキーマのバイナリ・データに提供します。この情報を使用して、バイナリ・データの処理を最適化できます。DMCBDX仕様は、Webサイトhttp://www.w3.org/TR/2005/NOTE-xml-media-types-20050504/で入手できます。

- RRSHB (Resource Representation SOAP Header Block): SOAPメッセージを使用して、JPEGイメージなどのWebリソース表現をSOAPヘッダー・ブロックで送信できます。MTOMおよびXOPと組み合せると、RRSHB SOAPヘッダー・ブロックに含まれるWebリソースは、SOAPヘッダー内のxs:base64Binary文字列ではなく未処理のバイナリMIME添付ファイルとして送信できます。RRSHB仕様は、Webサイトhttp://www.w3.org/TR/2005/REC-soap12-rep-20050125/で入手できます。

これらの仕様は、OSUCR (SOAP Optimized Serialization Use Cases and Requirements)で説明されている要件を満たしています(http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/を参照)。

事前定義済のMTOMアタッチメント・ポリシー

第2章「Oracle Infrastructure Webサービスへのポリシーのアタッチ」で説明されているように、OWSMには、Oracle Fusion Middlewareをインストールすると自動的に使用可能になる一連の事前定義済のポリシーおよびアサーション・テンプレートが用意されています。

表8-1にリストされているMTOMアタッチメント・ポリシーは、即時に利用可能です。

表8-1 事前定義済のMTOMアタッチメント・ポリシー

信頼性のあるメッセージング・ポリシー

説明

oracle/wsmtom_policy

MTOM形式でないインバウンド・メッセージを拒否し、アウトバウンド・メッセージがMTOM形式であることを確認します。

事前定義済のMTOMアタッチメント・ポリシーの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のMTOMアタッチメント・ポリシーに関する説明を参照してください。

MTOMポリシーのアタッチ

MTOMポリシーは、設計時にOracle JDeveloperを使用して、あるいは実行時にOracle Enterprise Managerを使用して、Oracle Infrastructure Webサービスにアタッチできます。詳細は、第2章「Oracle Infrastructure Webサービスへのポリシーのアタッチ」を参照してください。

MTOMポリシーの構成

構成手順は必要ありません。

9 RESTful Webサービスの開発

この章では、Representational State Transfer (RESTful) Webサービスの概念を示し、Java API for RESTful Web Services (JAX-RS)を使用してRESTful Webサービスを開発および構成する方法について説明します。

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

- RESTful Webサービスの概要

- RESTful Webサービス・リクエストが作成および処理される仕組み

- RESTful Webサービスのサポートの制限事項

RESTful Webサービスの概要

Representational State Transfer (REST)は、SOAPなどの追加メッセージング・レイヤーなしで、標準化されたインタフェース(HTTPなど)を介してデータを送信する単純なインタフェースを記述するものです。RESTには、ステートレス・サービスを作成するための一連の設計ルールが用意されており、これらはリソース(特定の情報のソース)として表示されます。それぞれのリソースは固有のURIで識別できます。クライアントがURIを使用してリソースにアクセスすると、標準化された固定のメソッド・セットと、リソースの表示が返されます。クライアントは、新しい各リソース表示を使用してステートを転送します。

HTTPプロトコルを使用してRESTfulリソースにアクセスする際は、リソース識別子がリソースのURLとなります。そのリソースに対して実行する標準操作は、HTTPメソッドの1つ(GET、PUT、DELETE、POSTまたはHEAD)です。

RESTfulエンドポイントは、javax.xml.ws.Provider<T>インタフェースのinvoke()メソッドを使用して構築します(http://java.sun.com/javaee/5/docs/api/javax/xml/ws/Provider.htmlを参照)。Providerインタフェースは、サービス・エンドポイント・インタフェース(SEI)を構築しない動的な手段として使用できます。

RESTful Webサービス・リクエストが作成および処理される仕組み

次の各項で、RESTful Webサービス・リクエストがクライアント側でどのように作成され、サーバー側でどのように処理されるかを説明します。

- HTTP Getリクエストの構築

- HTTP Postリクエストの構築

- RESTfulレスポンスの構築

HTTP Getリクエストの構築

たとえば、次のURLでREST対応のSOAPエンドポイントがデプロイされているとします。

http://example.com/my-app/my-service

この場合、次のURLでHTTP GETリクエストが受け入れられます。

http://example.com/my-app/my-service/{operationName}?{param1}={value1}&{param2}={value2}

この例では、{operationName}はサービスに対するWSDL内の操作名の1つです。RPC-literal操作の場合は、{param1}、{param2}などが、操作の入力であるwsdl:message内で定義される各部分の名前になります。ただし、これらの各部分はsimpleType(xsd:intなど)である必要があります。

注意:

ブラウザによっては、HTTP GET URLのサイズが制限されていることがあります(通常は2000文字未満)。パラメータ数を制限し、パラメータの名前と値を短くすることで、URLのサイズを小さくするように注意してください。

document-literal操作では、メッセージはパラメータを1つのみ持ちます。複数のパラメータをシミュレートするため、WSDLには、スキーマでsequenceとして定義されている1つのみのパラメータを指定します。sequenceの各メンバーをパラメータと考えることができます。この場合、{param1}、{param2}などが、message部分ではなくsequence型のメンバーになります。RPC-literalの場合と同様に、これらのメンバーはsimpleTypeである必要があります。

次の例は、addNumbersという名前の操作に対して定義されたリクエスト・メッセージを示しています。

例9-1 操作に対するGETリクエスト

<wsdl:message name="AddNumbersRequest">
<wsdl:part name="a" type="xsd:int" />
<wsdl:part name="b" type="xsd:int" />
</wsdl:Message>

このリクエストは、次のURLを指定したGETを使用して起動できます。

http://{yourhost}/{context-path}/{service-url}/addNumbers?a=23&b=24

次の例は、Oracle Web ServicesプラットフォームがGETリクエストからサーバー側で作成するSOAPエンベロープを示しています。このメッセージは、他の受信SOAPリクエストと同様に処理されます。

例9-2 GETリクエストから作成されるSOAPエンベロープ

<soap:Envelope>
<soap:Body>
<ns:addNumbers>
<ns:a>23</ns:a>
<ns:b>24</ns:b>
</ns:addNumbers>
<soap:Body>
<soap:Envelope>

次の例は、サービスがdocument-literal操作として定義されている場合にaddNumbersサービスに対して送信されるリクエスト・メッセージを示しています。

例9-3 document-literalのラップ操作に対するGETリクエストの例

<wsdl:message name="AddNumbersRequest">
<wsdl:part name="params" type="tns:AddNumbersRequstObject" />
</wsdl:Message>

次の例は、AddNumbersRequestObjectの定義を示しています。これはスキーマでも同じ定義になります。

例9-4 document-literalのラップ操作のXML定義

<xsd:complexType name="AddNumbersRequestObject">
<xsd:complexContent>
<xsd:sequence>
<xsd:element name="a" type="xsd:int"/>
<xsd:element name="b" type="xsd:int"/>
</xsd:sequence>
</xsd:complexContent>
</xsd:complexType>

この操作は、次のURLを指定したGETリクエストによって起動できます。

http://{yourhost}/{context-path}/{service-url}/addNumbers?a=23&b=24

注意:

これは、例9-1のRPC-literalリクエストに使用したものと同じURLです。

HTTP Postリクエストの構築

RESTful Webサービスでは、単純なXMLメッセージのHTTP POSTリクエストはサポートされていますが、SOAPエンベロープのHTTP POSTリクエストはサポートされていません。RESTfulリクエストでは、添付ファイル付きのメッセージはサポートされていません。RESTful WebサービスではSOAPリクエストもサポートされているため、指定されたリクエストがSOAPまたはRESTfulのどちらであるかを実装側で判断する必要があります。

SOAPサービスは、POSTリクエストを受信するとSOAPアクション・ヘッダーを検索します。ヘッダーが存在する場合は、実装はこのリクエストをSOAPリクエストであると判断します。存在しない場合は、リクエストのroot要素のQNameが検索されます。それがSOAPエンベロープのQNameであれば、メッセージはSOAPリクエストとして処理されます。そうでない場合は、RESTfulリクエストとして処理されます。

RESTfulリクエストは、リクエスト・ドキュメントをSOAPエンベロープでラップすることで処理されます。SOAP 1.2リクエストのContent-TypeヘッダーではないHTTPヘッダーのみが、そのまま受信されます。このContent-Typeヘッダーは、SOAP 1.2用の適切なコンテンツ・タイプであるapplication/soap+xmlに変更されます。

たとえば、次のRESTfulリクエストは、例9-6のSOAPエンベロープにラップされます。

例9-5 RESTfulリクエスト

<ns:addNumbers>
<ns:a>23</ns:a>
<ns:b>24</ns:b>
</ns:addNumbers>

次のリクエストは、通常のSOAPリクエストとして処理されます。

例9-6 RESTfulリクエストをラップするSOAPエンベロープ

<soap:Envelope>
<soap:Body>
<ns:addNumbers>
<ns:a>23</ns:a>
<ns:b>24</ns:b>
</ns:addNumbers>
</soap:Body>
</soap:Envelope>

RESTfulレスポンスの構築

RESTfulリクエストとして処理される(GETまたはPOST)リクエストに対するレスポンスも、RESTfulスタイルである必要があります。サーバーは、サーバー上のSOAPレスポンスをクライアントに送信する前に、RESTfulレスポンスに変換します。RESTfulレスポンスは、SOAP本体の最初の子要素をルート要素として持つXMLドキュメントになります。たとえば、次の例のSOAPエンベロープがサーバー上にあると想定します。

例9-7 SOAPレスポンス

<soap:Envelope>
<soap:Body>
<ns0:result xmlns:nso="…">
<ns:title>How to Win at Poker</ns:title>
<ns:author>John Doe</ns:author>
</ns0:result>
</soap:Body>
</soap:Envelope>

次の例は、クライアントに返送されるレスポンスを示しています。Content-Typeが常にtext/xmlである点に注意してください。SOAPヘッダーや添付ファイルは、クライアントに返送されません。

例9-8 RESTfulレスポンス

<ns0:result xmlns:ns0="…">
<ns:title>How to Win at Poker</ns:title>
<ns:author>John Doe</ns:author>
</ns0:result>

RESTful Webサービスのサポートの制限事項

次のリストは、Oracle Web ServicesによるRESTful Webサービスのサポートにおける制限事項です。

- RESTful Webサービスは、literal操作を含むWebサービス・アプリケーションに対してのみサポートされます(リクエストとレスポンスの両方がリテラルである必要があります)。

- HTTP GETは、(必須の)複合パラメータのないWebサービス操作に対してのみサポートされます。

- ブラウザによっては、HTTP GET URLのサイズが制限されていることがあります(通常は2000文字以下)。パラメータ数を制限し、パラメータの値と名前を短くすることで、URLのサイズを小さくするように注意してください。

- RESTful Webサービスでは、簡易XMLメッセージのみが送信されます。添付ファイル付きメッセージは送信できません。

- セキュリティや信頼性など、管理機能の多くは、RESTful Webサービスでは利用できません。これは、この情報の伝達に通常使用されるSOAPヘッダーが、サービスのRESTful起動では使用できないためです。

- RESTful起動は、生成されたスタブまたはDIIクライアントから行うことはできません。それらのクライアントからの起動はSOAPで行われます。

- プロバイダのフレームワークでは、RESTはサポートされません。

- RESTful Webサービスでの操作名には、マルチバイト・キャラクタは使用できません。

10 スタンドアロン・クライアントからのWebサービスの起動

この章では、スタンドアロン・クライアントからOracle Infrastructure Webサービスを起動する方法について説明します。

Oracle Fusion Middlewareがローカルでインストールされていない環境から、CLASSPATHにOracle Fusion Middlewareクラスのセット全体を設定してOracle Infrastructure Webサービスを起動するときは、そのWebサービスの起動にスタンドアロン・クライアントのJARファイルを使用できます。

スタンドアロン・クライアントのJARは、Oracle Infrastructure Webサービスの基本的なクライアント側機能と、OWSMセキュリティ・ポリシーをサポートします。

クライアント・アプリケーションでスタンドアロン・クライアントのJARファイルを使用するには、次の手順を実行します。

1. Oracle JDeveloperなどの任意のIDEを使用してJava SEクライアントを作成します。

2. ファイルORACLE_HOME/oracle_common/modules/clients/com.oracle.webservices.fmw.client_12.1.2.jarを、Oracle Fusion Middlewareをホストするコンピュータからクライアント・コンピュータにコピーします。ORACLE_HOMEは、Oracle Fusion Middlewareのインストール時にOracleホームに指定したディレクトリです。
たとえば、ファイルを、クライアント・アプリケーションによって使用される他のクラスを格納したディレクトリにコピーできます。

3. JARファイルを、使用しているCLASSPATHに追加します。

4. Oracle Web Services Manager (OWSM)ポリシーの環境を構成します。この手順は省略可能で、Webサービス・クライアントにOWSMセキュリティ・ポリシーをアタッチする場合にのみ必要です。
必要な構成手順は、アタッチするポリシーのタイプによって異なります。次に例を示します。構成の要件の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のOPSSを使用するJava SEアプリケーションの構成に関する説明を参照してください。

例: BASIC認証

たとえば、oracle/wss_http_token_client_policyセキュリティ・ポリシーを使用してBASIC認証をサポートするには、次の手順を実行します。

1. jps-config-jse.xmlおよびaudit-store.xmlファイルを、domain_home/config/fmwconfigディレクトリからWebサービス・クライアントにアクセス可能な場所にコピーします。domain_homeは、ドメインの名前および位置です。

2. 手順aでファイルのコピー先にした場所にウォレット(cwallet.sso)を作成します。このウォレットで、oracle.wsm.securityというマップと、クライアント・アプリケーションが使用する資格証明のキー名(weblogic-csf-keyなど)を定義します。
ファイルcwallet.ssoの場所を、構成ファイルjps-config-jse.xmlの要素<serviceInstanceに指定します。詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のウォレット・ベースの資格証明ストアに関する説明を参照してください。

3. Javaコマンドラインで、手順1でコピーしたJPS構成ファイルを定義する次のプロパティを渡します。

-Doracle.security.jps.config=<pathToConfigFile>

詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のシナリオ3: Java SEアプリケーションの保護に関する説明を参照してください。

例: SSL

たとえば、SSLポリシーをサポートするには、次の手順を実行します。

1. jps-config-jse.xmlおよびaudit-store.xmlファイルを、domain_home/config/fmwconfigディレクトリからWebサービス・クライアントにアクセス可能な場所にコピーします。domain_homeは、ドメインの名前および位置です。

2. Javaコマンドラインで、手順1でコピーしたJPS構成ファイルを定義する次のプロパティを渡します。
手順1でコピーしたJPS構成ファイルを定義します。

-Doracle.security.jps.config=<pathToConfigFile>

詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のシナリオ3: Java SEアプリケーションの保護に関する説明を参照してください。

信頼できる証明書を格納するトラスト・ストアを定義します。

-Djavax.net.ssl.trustStore=<trustStore>

詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のLDAPへの一方向SSL接続に関する説明で、Java SEアプリケーションを使用する場合のWebLogic Serverの設定方法を参照してください。

トラスト・ストアのパスワードを定義します。

-Djavax.net.ssl.trustStorePassword=<password>

11 Webサービスのテスト

この章では、Oracle Infrastructure Webサービスのテストに使用できるツールについて説明します。

認証、認可、サービス品質(QoS)、HTTPヘッダーのオプションなどの、Webサービスの基本機能および拡張機能をテストできます。また、セキュリティ機能のストレス・テストも実行できます。Webサービス・テスト・クライアントまたはFusion Middleware Controlの「Webサービスのテスト」ページを使用した、Webサービスのテストの詳細は、『Webサービスの管理』のWebサービスのテストに関する説明を参照してください。

12 相互運用性のガイドライン

この章では、Oracle Infrastructure Webサービスとの相互運用性を確保するガイドラインを説明します。

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

- Webサービスの相互運用性の概要

- Webサービスの相互運用性に関わる組織

- 相互運用性のあるWebサービスを作成するための一般的なガイドライン

Webサービスの相互運用性の概要

Webサービス・アーキテクチャの目標は、異機種のビジネス・アプリケーションが円滑に連携することです。アーキテクチャは疎結合され、XML標準に基づいています。Webサービスは、サービス・コントラクトとしてWeb Service Description Language (WSDL)ファイルを定義することで、その背後にあるオペレーティング・システムや開発技術にかかわらず相互に連携するよう設計されています。ただし、サービス・コントラクトが複雑なため、WSDLやSOAPなどの標準の解釈が曖昧になっています。また、ベンダー固有の機能強化や拡張が全体的な相互運用性の妨げとなっています。

ビジネス・アプリケーションは互いのサービスを起動する必要があります。これらのサービスが異なるテクノロジで実装されていることもあります。Webサービスの複雑さが増すと、相互運用がうまくいかないケースも増える傾向にあります。一般に公開されているWebサービスを運用しているとしたら、様々なツールキットを使用している世界中のクライアントがそのWebサービスを起動できるようにする必要があります。同じように、ビジネス・アプリケーションにも、既存のレガシー・システム上に構築されていて、インタフェースの設計があまり一般的でない他ベンダーのWebサービスとの統合または連携が必要な場合もあります。

相互運用性の問題は、プロトコル・スタックのどのレイヤーからも生じる可能性があります。トランスポート・レベルでは、メッセージ交換における双方の当事者が特定の物理的なトランスポート・メカニズムについて合意している必要があります。たとえば、Java以外のプラットフォームを使用している相手にJMSトランスポートの使用を期待することはできません。基本的なHTTPプロトコルを使用した方が、相互運用性が高まる理由はここにあります。メッセージ・レベルでは、任意のデータ・エンコーディングの使用がSOAPで事実上許可されているため相互運用は難しくなります。たとえば、Javaプラットフォームの標準のArrayListは、.NETプラットフォームのSystem.collections.ArrayListには自動的には変換されません。また、相互運用性の問題は、基本的なWSDLやSOAPのレベルでも発生します。高度なWebサービスの開発者は、セキュリティ、信頼性、トランザクション・サービスなどのサービス品質(QOS)機能の実装を開始すると、その他にも様々な難題に直面することになります。

相互運用性の実現は難しい問題です。ただし、適切なガイドラインがあれば、Oracle Webサービスはその他のJava EEベンダーのプラットフォームや、Microsoft .NETプラットフォームなどのJava以外のプラットフォームとシームレスに連携できます。

Webサービスの相互運用性に関わる組織

Webサービスのコミュニティで相互運用性の重要度が増すにつれ、その目標を達成するために多くの組織が設立されました。

SOAPBuildersコミュニティ

SOAPBuildersは、SOAP実装間の相互運用性のテスト・セットの確立に向けて活動する開発者の、緩やかに組織化されたフォーラムです。相互運用性は、このフォーラムの参加者によって共同で定義された一連の正規テストを実施することにより実証されます。

SOAPBuilderコミュニティによって開発されたテストは、全般的にベンダーの慣例に基づいています。ただし、慣例は時とともに変わります。Webサービス・ベンダー、Webサービス開発者およびWebサービスの利用者には、正式にまとめられた、不要なものの混じっていないはっきりとしたルールが必要です。SOAPBuilderのテストの詳細は、次のWebサイトを参照してください。http://java.sun.com/webservices/interop/soapbuilders/index.html

WS-Interoperability

Web Services Interoperability (WS-I)は、Webサービス間の相互運用可能なメッセージ交換のための一般的なプロトコルの作成、普及、サポートを行う業界のオープンな組織です。WS-Iプロファイルは、標準の適用方法に関するガイドラインおよび推奨事項です。これらのプロファイルは、基礎となる仕様に制約を追加して曖昧さをなくすことを目的としています。

WS-Iの成果物は、プロファイル、一般的なプラクティスまたはベスト・プラクティス、シナリオ、テスト・ソフトウェアおよびテスト資料です。Webサービスは、WS-I Basic Profileに準拠するように設計する必要があります。WS-Iに準拠したサービスは明瞭なコントラクトに同意しており、相互運用性を実現する可能性が高くなります。

たとえば、WS-I Basic Profileに準拠しているWebサービスでは、次の機能を使用する必要があります。

- トランスポート・バインディングとしてHTTPまたはHTTPSを使用します。HTTP 1.0よりもHTTP 1.1が優先されます。

- literalスタイルのエンコーディングを使用します。SOAPエンコーディングは使用しないでください。

- より厳密なフォルト・メッセージ構文を使用します。MESSAGEにsoap:Fault要素が含まれている場合、その要素の子は非修飾である必要があります。

- XMLバージョン1.0を使用します。

- サービスでは、規則ArrayOfXXXを使用した配列ラッパー要素の宣言はできません。

WS-Iプロファイル、およびプロファイル内に定義されているルールの詳細は、WS-IのWebサイト(http://www.ws-i.org/)を参照してください。

OracleはWS-I組織のメンバーで、顧客が相互運用性を実現する手助けとなるよう取り組んでいます。Oracle Infrastructure Webサービス・プラットフォームは非常に柔軟性が高く、相互運用性のあるWebサービスの作成を支援します。

Oracle JDeveloperでは、WSDLファイルの統合テストおよびWS-I Basic Profile準拠のWebサービスの実行をサポートしています。監視およびロギング用の拡張HTTPアナライザが用意されており、相互運用性の問題をより詳細に診断する組込みの分析およびレポート・ツールも提供されています。詳細は、Oracle JDeveloperのオンライン・ヘルプを参照してください。

相互運用性のあるWebサービスを作成するための一般的なガイドライン

一般的なガイドラインの1つ目は、可能な場合にはWS-Iに準拠したWebサービスを作成することです。ただし、WS-Iプロファイルですべての相互運用性の問題が解決するわけではありません。WS-Iプロファイルが存在する以前から、多くのWebサービスが実装されていました。また、Webサービスとして有効化しているレガシー・システムにより、設計が制限される場合もあります。そのため、可能な場合には、開発プロセスの初期段階からWebサービス設計の秘訣を取り入れることです。

次の各項で、相互運用性のあるWebサービスを作成するための一般的なガイドラインを示します。

Webサービスをトップダウン方式で設計する

WSDLからのトップダウン方式を採用することにより、プラットフォームや言語に固有の特徴に制限されないサービス・コントラクトからWebサービスを設計できます。コントラクトレベルの相互運用性は、Webサービスの実装前から確保できます。他のWebサービス・プラットフォーム・ツールでWSDLファイルを処理できるようになり、サービスが既存のレガシーAPIに影響される可能性も低くなります。

最初はXSDを使用してデータ型を設計する

可能な場合には、XSDスキーマ・エディタを使用してスキーマ型を持つデータ型を設計します。.NETのDataSetデータ型やJavaコレクションなど、プラットフォーム固有のデータ型の使用は避けます。

データ型はシンプルにする

xsd:choiceなどの不必要に複雑なスキーマ・データ型の使用は避けます。最高の相互運用性はシンプルなデータ型により実現され、パフォーマンスの向上という利点ももたらします。

1次元配列を使用する

可能な場合は、1次元配列を使用します。多次元配列ではなく、配列の配列を使用します。

(RPCエンコード形式でのみ適用される)多次元配列は、.NETプラットフォームではサポートされていません。また、多次元配列の場合は、内部配列の長さが同じである必要があります。配列の配列を使用した方が、内部の配列の長さが異なってもかまわないという点で柔軟性があります。

注意:

XSDではWSDLでの多次元配列の定義がサポートされていますが、Javaなどのプログラミング言語ではそれらが配列の配列にマッピングされ、ペイロードが多次元形式で表示されます。ペイロードが多次元形式に変換されるときに、Java VMによって各内部配列の長さが同じであることが確認され、その他のチェックも実行されます。

空の配列と配列へのNULL参照とを区別する

たとえば、minoccurs=0およびxsd:nillable=trueという属性を含む配列がある場合、サービス実装がこの配列へのNULL参照を返そうとすると、ペイロードの表示に問題が発生します。ペイロード内のminoccurs=0としてのこの要素を完全に無視されるような実装もあれば、ペイロード内のこの要素を属性xsi:nil=trueで指定するような実装もあります。

同じ問題が、配列をデシリアライズしようとした場合にも発生します。NULL参照にデシリアライズすることも、何も要素を含まない配列にデシリアライズすることもできます。この場合のガイドラインは、必ず長さチェックの前にNULLをチェックすることです。

スパース配列、可変サイズ配列または多次元配列は使用しない

XSDではスパース配列、可変サイズ配列および多次元配列がサポートされていますが、ターゲット・プラットフォームではサポートされていないこともあります。WebサービスをWSDLからトップダウン方式で作成する場合は、これらの配列タイプの使用を避け、通常の配列を使用してください。

xsd:anyTypeは使用しない

通常、xsd:anyTypeはJavaプラットフォームでjava.lang.Objectにマッピングされます。これにより、個別のシリアライザおよびデシリアライザの登録を必要とするランタイムを通過することができます。ガイドラインは、ランタイムで使用可能なすべてのタイプを見つけて、それらをWSDLで定義することです。

次の例は、MyAnyTypeというクラスと、それを拡張するMyPossibleType1およびMyPossibleType2という2つのクラスを示しています。この場合は、Webメソッド内でxsd:anyTypeのかわりにMyAnyTypeを使用します。

例12-1 メンバー変数を含むクラス

public class MyAnyType {
//No member variable
}

public class MyPossibleType1 extends MyAnyType {
//member variable.
}

public class MypossibleType2 extends MyAnyType {
//member variable
}
..

サポートされていないxsd:typeはSOAPElementにマッピングする

WSDLでサポートされていないxsd:typeが1つあるだけで、相互運用性に影響を及ぼす可能性があります。簡単な回避策は、JAX-RPCマッピング・ファイルなどのマッピング・メカニズムを使用して、サポートされていないXSDタイプをSOAPElementにマッピングすることです。サポートはされているが実行時に失敗するような型も、SOAPElementにマッピングして、クライアントまたはサーバーの内部でSOAPElementを解析することができます。

NULL値は慎重に使用する

NULL値を使用して行う処理を決定します。たとえば、配列型にNULL値を許可しますか。NULL文字列または空の文字列を使用しますか。プラットフォーム間でNULL値を送信すると、受信者側で例外の原因となりますか。

可能な場合は、NULL値を送信しないようにします。アプリケーションでどうしてもNULL値を使用する必要がある場合は、NULL値が許可されていることが明確にわかるようにスキーマ型を設計します。

WSDLの検証にコンプライアンス・テスト・ツールを使用する

WebサービスがWS-Iに準拠するよう設計されている場合は、WS-Iモニター・ツールを使用してメッセージを記録し、アナライザ・ツールを使用して準拠しているかどうかを検証します。WS-Iツールは、Webサイトhttp://www.ws-i.org/deliverables/workinggroup.aspx?wg=testingtools/から無料でダウンロードできます。

各プラットフォームにネイティブの型の違いを考慮する

xsd:unsignedshortやxsd:unsignedintなどの一部のスキーマ型には、必ずしもネイティブのデータ型のダイレクト・マッピングがあるわけではありません。たとえば、Javaプラットフォームに相当する符号なし型はありません。xsd:double、xsd:float、xsd:decimalなどのスキーマの数値型は、一度プラットフォームにネイティブのデータ型にマッピングされると精度が変わることがあります。

また、xsd:string型には制限があります。文字列には不正なXML文字を含めることはできず、\r(キャリッジ・リターン)文字は通常は\n(改行)文字にマッピングされます。

ソース・データで使用されている文字セットがわからない場合は、xsd:stringでなくbyte[]を使用してください。バイナリ・コンテンツの方がテキスト・コンテンツよりも運用性が高くなります。

Javaクラスからボトムアップ方式でWebサービスを作成する場合は、可能な限り最も近いデータ型を使用します。したがって、よりxsd:typeに近いJavaデータ型を使用してください。たとえば、日時を表すためにxsd:dateTimeを使用する場合は、java.lang.Dataやjava.util.Calendarではなくjavax.xml.datatype.XMLGregorianCalendarデータ型を使用します。XMLGregorianCalendarデータ型の方が、小数秒を格納できるため、より正確な時刻を返すことができます。

WSDLからトップダウン方式でWebサービスを作成する場合は、時刻の正確性が非常に重要であれば、マッピング・ファイルを使用してxsd:dateTimeをXMLGregorianCalendarにマッピングします。

注意:

Java EE以前のプラットフォーム(J2EE 1.*など)ではすべてCalendarを使用していましたが、現在のJava EE準拠プラットフォームではXMLGregorianCalendarを使用しています。この方が長い小数秒を処理できるため、.Netの相互運用性が高くなります。

RPC-encodedメッセージ書式は使用しない

RPC-encodedメッセージ書式自体に、他のプラットフォームやクライアントとの相互運用性がないわけではありません。今日稼働しているWebサービスの多くは、RPC-encodedです。RPC-encodedメッセージ書式の使用を避ける理由は、基礎となる仕様の解釈や実装の選択の違いが相互運用性の妨げになるという問題を回避するためです。たとえば、スパース配列、多次元配列、カスタム・フォルト・コードQName、un-typedペイロードなどの処理がその例です。

名前の競合を回避する

Javaクラスからボトムアップ方式でWebサービスを作成する場合、クラス内に明示的なパッケージ名を使用することにより名前の競合を回避できます。WSDLからトップダウン方式でWebサービスを作成する場合は、一意のネームスペースURIを使用することにより名前の競合を回避できます。

注意:

トップダウン・アプローチを使用しているほとんどのWebサービス・アセンブリ・ツールでは、デフォルトで、生成されたクラスのパッケージ名をネームスペースURIから導出しようとします。ボトムアップ・アプローチを使用しているツールでは、Javaパッケージ名を使用してネームスペースURIを導出しようとします。

有効なパッケージ名の制限のため、この導出は1-1ではありません。したがって、ネームスペースURIの指定は、別のネームスペースURIにより生成されたパッケージと名前が競合することがないように行うことが非常に重要です。

メッセージ・ハンドラ、カスタム・シリアライザまたはインターセプタを使用する

メッセージ・ハンドラ、カスタム・シリアライザまたはインターセプタを使用すると、相互運用性の問題を簡単に修正できます。これは、デシリアライザで処理される前、またはシリアライザによりペイロードが生成されてからワイヤ書式になるまでに、ペイロードに関する問題を非常に細かいレベルで修正するという考え方です。

WS-*仕様は慎重に適用する

多くのWS-*仕様はまだ導入の初期段階であり、多様なスタックを持つ相互運用性の問題を浮き彫りにする可能性もあります。WS-*機能を適用する前に、それが本当に必要かどうかを確認することをお薦めします。あるいは、Webサービスの領域で最も一般的に使用されている機能を適用することをお薦めします。たとえば、セキュリティに対して基本認証、X.509またはKerberosを選択する場合など、使用可能なオプションが複数あれば、Webサービスの領域で最も一般的に使用されているオプションを選択してください。

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