| Oracle Application Development Framework Forms/4GL開発者のための開発者ガイド 10g（10.1.3.0） B40013-02 |
|
 戻る |
 次へ |
この章は、ADFプロジェクトでWebサービスを使用する際のアドバイス、およびJDeveloperでWebサービスを作成および使用する際の一般的なアドバイスで構成されています。
この章の内容は次のとおりです。
Webサービスとは、オープンXMLベースの標準を使用してインターネット経由でビジネス機能を公開する一式のメッセージング・プロトコルとプログラミング標準で構成されるテクノロジを表す用語です。各Webサービスは、HTTPまたはSMTPを使用してインターネット経由でプログラム的にアクセスしてレスポンスが返される、個別の再使用可能なソフトウェア・コンポーネントです。
企業はWebサービスを使用して、元のアプリケーションのプラットフォームや言語に関係なくビジネス機能を公開できます。これは、ビジネス機能を、他のアプリケーションでも認識され、使用可能な標準XMLコンストラクトで構成されるメッセージに抽象化して公開するからです。
Oracle ADFには、Webサービスをアプリケーションのビジネス・サービス・プロバイダとして使用するためのサポートが組み込まれています。たとえば、アプリケーションで次のことを行えます。
他社がB2B E-Commerceを提供するWebサービスとして運用し、公開しているアプリケーションの一部の機能を使用できます。
Xmethods.comなどのサイトから利用可能なWebサービスを使用して、一部の標準機能を提供できます。
UDDIレジストリで指定された機能を提供するWebサービスを検索し、実行時に使用できます。
Oracle ADFでは、選択した実装テクノロジを使用して、J2EEプラットフォームの1つまたはすべての層をターゲットとするアプリケーションを作成できます。ADFビジネス・コンポーネントを使用してビジネス・サービスを実装すると、アプリケーションの一部をいつでもコード変更することなくWebサービスとして公開できるようになり、柔軟性が高まります。
コンポーネントをWebサービスとしてデプロイするかどうかを決定する際は、次の要因を考慮する必要があります。
Webサービスでは、アプリケーションと基礎となるアーキテクチャは分離されます。
Webサービスは軽量なので、インターネットまたはイントラネットでのパフォーマンスが向上します。
Webサービス・テクノロジは、HTTPを始めとするWebインフラストラクチャを使用するように設計されています。
Webサービスが基づくXML標準を説明すると役立ちます。
Simple Object Access Protocol（SOAP）は、軽量のXMLベースのプロトコルで、転送プロトコル（通常はHTTPまたはSMTP）のメッセージを介した送受信に使用されます。World Wide Web ConsortiumのWebサイトで参照可能なSOAP仕様は、リクエストとレスポンスを暗号化する標準的な方法を提供します。XMLスキーマを使用して、メッセージ・ペイロードの構造とデータ型を説明します。
SOAPメッセージは、次のコンポーネントで構成されます。
SOAPエンベロープ。SOAPメッセージの重要部分であるSOAP本体とオプションのSOAPヘッダーが含まれます。
SOAPエンベロープの送信方法を指定するプロトコル・バインディング。JDeveloperで生成されたWebサービスの場合はHTTPです。
WebサービスではSOAPを使用します。SOAPは、データをXMLで表し、HTTPを使用してそのデータをインターネット経由で転送するためのXMLプロトコルです。SOAPでは、複数の方法でデータをXMLに変換したり、元に戻したりすることができます。JDeveloperは、SOAP RPCエンコーディング、SOAP RPCリテラル・スタイル、およびドキュメント/リテラル・スタイル（メッセージ・スタイル）をサポートしています。
JDeveloperで作成するWebサービスは、Apache SOAP 2.2に基づき、Oracle Application Serverの一部であるOracle SOAPにデプロイするか、Oracle Application ServerのOC4Jコンテナの1つであるSOAPサーバーにデプロイできます。
Web Services Description Language（WSDL）は、Webサービス・インタフェースの構文とインタフェースの場所を説明するために使用されるXML言語です。World Wide Web ConsortiumのWebサイトでWSDL v1.1仕様を参照できます。各Webサービスには、サービスを使用するために必要なすべての情報、つまり、サービスの場所、名前、およびWebサービスが公開するメソッドに関する情報を含むWSDLドキュメントがあります。JDeveloperのWebサービス公開ウィザードの1つを使用してWebサービスを作成する場合、サービスのWSDLドキュメントは自動的に生成されます。
Universal Description, Discovery and Integration（UDDI）は、名前または産業カテゴリに基づく、標準ベースのWebサービス検索方法を提供します。UDDIレジストリは、JDeveloperから自動的に利用可能になるパブリックUDDIレジストリのように公開することも、組織内で使用されるUDDIレジストリのようにプライベートにすることもできます。このバージョンのJDeveloperは、UDDIを使用したWebサービスの検出のみをサポートしていますが、将来のバージョンではUDDI登録を完全にサポートします。http://www.uddi.org/でUDDI v2仕様を参照できます。
接続ナビゲータにあるJDeveloperのUDDIブラウザには、UDDIレジストリに関する情報が格納され、ユーザーは指定した検索基準でUDDIレジストリを検索し、WSDLで記述されたWebサービスを検出することができます。
別のパブリックUDDIレジストリまたは組織内のプライベートUDDIレジストリに独自のレジストリ接続を作成できます。この場合、問合せエンドポイントとレジストリのビジネス・キーを含む接続ディスクリプタ・プロパティ・ファイルが作成されます。このファイルは、<JDEV_INSTALL>/system<release_and_build_number>/uddiconnections.xmlにあります。<JDEV_INSTALL>はJDeveloperがインストールされているルート・ディレクトリです。
JDeveloperのWebサービスの検索ウィザードは、UDDIレジストリを参照して、名前またはカテゴリでWebサービスを検索します。JDeveloperから選択したUDDIレジストリに接続するには、マシンからの適切な接続が必要です。たとえば、パブリックUDDIレジストリを検索する場合は、インターネットへの接続が必要です。レジストリ・エントリがWSDLドキュメントによって定義されたかどうかを識別する「WSDLかどうか」列がオンになったWebサービスへのスタブのみを生成できます。
UDDIレジストリを使用する場合、Technical Modelを縮めたtModelというなじみのない用語が使用されます。これは、Webサービスの技術仕様を表し、Webサービスの検索ウィザードを使用してWebサービスを検索すると、同じtModelと互換性のある他のWebサービスも表示されます。
UDDIで使用されるデータ構造は次のとおりです。
サービスの詳細: このセクションには、名前を始めとするサービスに関する情報が含まれます。
ビジネス・エンティティ: businessEntityと呼ばれるトップレベルのデータ構造で、Webサービスを提供する企業に関する情報が含まれます。
サービス・バインディング: bindingTemplateが含まれます。ここには、サービス・アクセス・ポイントに関する情報とWebサービスの技術仕様のtModelが含まれます。
Webサービスの検索ウィザードによってWebサービスが検出されると、同じtModelと互換性のあるすべてのWebサービスがリストされます。
Webサービスが直面する大きな問題は、Webサービスに実際どの程度相互運用性があるかということです。Webサービスの大きな特長は、共通の標準を使用することで、異なるアプリケーションどうしが互いのコンポーネントを使用できるようにすることを目的としたCORBAなどの古いソリューションが抱えていた問題を回避していることです。しかし、標準そのものが、組織がWebサービスの作成、デプロイおよび使用を開始したのと同時期に作成されています。このため、WSDLを使用しないWebサービス情報の提供など、異なる標準を使用したWebサービスが作成され、相互運用性の問題が発生しました。
オラクル社および他の業界をリードする企業によって、この相互運用性の問題を解決し、Webサービスの相互運用性をテストできるツールを提供することを目指したWeb Services-Interoperability Organization（WS-I）が結成されました。JDeveloperでは、WebサービスのWS-I Basic Profile 1.0への準拠を分析することで、Webサービスの相互運用性をテストします。まず、WS-I準拠のアナライザをダウンロードする必要があります。様々なベンダーから多数のアナライザが提供されています。WS-I Webサイトからも1つダウンロードできます。一式のテスト・アサーションを使用して、Webサービスがどの程度基本プロファイルに準拠しているかを調べ、次のアーチファクトに関する情報が記録されます。
WebサービスがUDDIレジストリを使用して検索された際の検出。Webサービスの検索ウィザードを使用してサービスか検索されなかった場合、レポートのこのセクションによって入力なしのセクションにエラーが返されます。
WebサービスのWSDLドキュメントの説明。ドキュメントの各要素が検討され、準拠していない要素が報告されます。このセクションの失敗の例としては、アサーションWSI2703の失敗があります。この場合、「WSDL definition does not conform to the schema located at http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd for some element using the WSDL-SOAP binding namespace, or does not conform to the schema located at http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd for some element using the WSDL namespace.」というメッセージが返されます。
Webサービスに接続され、サービスが応答を返した場合、リクエストとレスポンスのメッセージをテストするメッセージ。
仕様を始めとするWS-Iの詳細は、Web Services-Interoperability Organization（WS-I）のWebサイト（ws-i.org）を参照してください。
Oracle ADFを使用して開発されたアプリケーションでWebサービスを使用する場合、外部Webサービスのデータ・コントロールを作成するのが最も一般的な方法です。アプリケーションとともに開発するには時間がかかる機能を、Webサービスとして即座に提供でき、異なるアーキテクチャで動作するアプリケーションにアクセスできるからです。
また、Oracle ADFで作成されたコンポーネントを再利用して、他のアプリケーションからアクセス可能なWebサービスとして提供することもできます。
JDeveloperでは、サービスにWSDLのみを使用して既存のWebサービスのデータ・コントロールを作成できます。ローカル・ファイル・システムまたはUDDIレジストリでWSDLを検索するか、WSDL URLを直接入力します。
|
注意: ファイアウォールで保護されている環境で、ファイアウォール外にあるWebサービスを使用する場合は、JDeveloperで「Webブラウザ/プロキシ」の設定を構成する必要があります。詳細は、JDeveloperのオンライン・ヘルプを参照してください。 |
Webサービス・データ・コントロールの作成方法:
アプリケーション・ナビゲータで、アプリケーションを右クリックして「新規」を選択します。
新規ギャラリの「カテゴリ」ツリーで「Business Tier」を展開し、「Web Services」を選択します。
「項目」リストで「Webサービス・データ・コントロール」をダブルクリックします。
ウィザードの指示に従って、データ・コントロールの作成を完了します。
ナビゲータでWSDLノードを右クリックして、ポップアップ・メニューから「データ・コントロールの作成」を選択することもできます。
Webサービスを使用すると、アプリケーションは定義済アプリケーション・プログラミング・インタフェースからデータと情報を交換できます。SSL（Secure Sockets Layer）は、信頼性の低いネットワークでの安全なデータ転送を提供しますが、SSLは2点間でのみ機能します。データが相手側に到達すると、SSLセキュリティは解除され、データはそのままの形式でアクセスできるようになります。複雑なWebサービス・トランザクションでは、データの複数メッセージが異なるシステムに送信されることがありますが、SSLはエンドツーエンドのセキュリティを提供できないため、データは盗み読みされる危険があります。
Webサービスでは、あらゆる形態のセキュリティで、次の問題に対応する必要があります。
データの真正性と整合性
データのプライバシと機密性
認証と認可
否認防止
サービス攻撃の拒否
WS-Security仕様は、複数のセキュリティ・テクノロジを統一し、システムおよびプラットフォーム間での安全なWebサービスの相互運用性を実現します。仕様はhttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdfで参照できます。
WS-Securityは、Webサービスのセキュリティ関連の次の問題に対応しています。
認証と認可
データの送信者のアイデンティティが確認され、セキュリティ・システムによって、送信者がデータ・トランザクションを実行する権限を持っていることが確認されます。
認証のタイプは、プレーン・テキストで送信される基本的なユーザー名とパスワードのペア、または信頼できるX509証明連鎖です。SAMLアサーション・トークンを使用して、クライアントがサービスに対する認証を受けたり、フェデレートされたSSO環境に参加できるようにすることもできます。この場合、認証の詳細は、ベンダー固有の方法を使用してドメイン間で共有できます。
データの真正性、整合性および否認防止
業界標準メッセージを使用するXMLデジタル署名は、アルゴリズムをダイジェスト化し、SOAPメッセージにデジタル署名します。
データのプライバシ
業界標準の暗号化アルゴリズムを使用するXML暗号化により、メッセージを暗号化します。
サービス攻撃の拒否
SOAPメッセージにタイム・スタンプを押すXML構造を定義します。サーバーは、タイム・スタンプを使用して、定義された間隔後SOAPメッセージを無効にします。
この項では、「クライアント」とは、デプロイされたWebサービスにSOAPメッセージを送信するWebサービス・データ・コントロールを指します。デプロイされたWebサービスは次のいずれかです。
テスト用にOC4JにデプロイされたWebサービス
Oracle Application Serverで動作するWebサービス
インターネット経由でアクセスできる、世界のどこでも実行可能なWebサービス
ADF 10.1.3 Web Servicesのデータ・コントロールは、Java Key Store（JKS）またはOracle Walletを使用して、メッセージ・レベルのセキュリティを構成できます。Oracle Walletの設定および使用の詳細は、Oracle Technology Network（www.oracle.com/technology）を参照してください。ここでは、次のトピックについて説明します。
J2SE 1.4 Keytoolユーティリティを使用したキーストアの作成
暗号化および署名に使用されるキーストアの秘密鍵と公開鍵の作成
ルート認証局からデジタル署名を発行するための証明書の取得方法
キーストアへの証明書のインポート方法
暗号化用の公開鍵を備えた証明書のエクスポート方法
サーバー側とクライアント側（データ・コントロール側）で構成される2つのキーストアを作成します。
|
注意: この項で説明するデジタル証明書をリクエストする手順は、テスト専用です。デジタル署名を有効にしてWebサービス・データ・コントロールを使用する予定の場合、デプロイ環境のセキュリティ・ポリシーに従って、信頼できる証明書が生成されていることを確認する必要があります。 |
クライアント側で暗号化と署名用に使用できる公開鍵と秘密鍵を作成するには、コマンド・プロンプトで次のコマンドを実行します。
例33-1 キーストアを作成するコマンド
keytool -genkey -alias clientenckey clientsignkey -keyalg RSA -sigalg SHA1withRSA -keystore client.jks
キーストア・ユーティリティからキーストア・パスワードが要求され、識別名（DN）を特定するための質問が表示されます。DNは一意の識別子で、次のコンポーネントからなります。
CN: 共通名。スペースや特殊文字のない1つの名前です。
OU: 組織単位。
O: 組織名。
L: 地域名。
S: 州または都道府県名。
C: 国。2文字の国コード。
質問に答えると、keytoolユーティリティからキー・パスワードが要求されます。キー・パスワードがキーストア・パスワードと同じ場合は、値を入力せずに[Enter]を押します。そうでない場合は、キー・パスワードを入力します。キー・パスワードを入力すると、キーストア・ファイルclient.jksが現在のディレクトリに作成されます。このファイルには、データ・コントロールからのSOAPリクエストの暗号化に使用できる別名clientenckeyを持つ1つのキー・ペアが含まれています。
次に、データ・コントロールによって作成されたSOAPリクエストにデジタル署名するキー・ペアを作成します。コマンド・プロンプトでもう一度コマンドを実行します。ただし、署名キー・ペアの別名にはclientsignkeyを使用します。
キーストアのキー・エントリをリストするには、次のコマンドを実行します。
keytoolユーティリティからストア・パスワードが要求されます。キーストアの作成に使用したパスワードを入力します。コマンドを繰り返して、サーバー側のキーストアを作成します。暗号化キー・ペアにはserverenckeyを、署名キー・ペアにはserversignkeyを使用します。
keytoolを使用すると、デフォルトでは、発行者が鍵の生成者と同じである自署証明書が生成されます。
公開鍵を外部に配布して、発行したデジタル署名を確認できるようにするには、信頼できる認証局（CA）が公開鍵の発行者アイデンティティを保証する証明書を発行する必要があります。この場合、作成した署名キー・ペアの証明書リクエスト・ファイルを作成し、そのリクエスト・ファイルをCAに発行します。
コマンド・プロンプトで、次のコマンドを実行します。
例33-3 証明書リクエスト・ファイルを作成するコマンド
keytool -certreq -file clientsign.csr -alias clientsignkey -keystore client.jks
keytoolユーティリティからストア・パスワードおよびキー・パスワードが要求されます。パスワードを入力すると、clientsign.csrと呼ばれるファイルに、clientsignkeyという別名を持つ公開鍵の証明書リクエストが生成されます。
アプリケーションの開発中は、VerisignなどのCAを使用して試用証明書をリクエストできます。www.verisign.comにアクセスし、Free SSL Trial Certificateに移動して、リクエストを作成します。キーストアの作成時と同じDN情報を入力する必要があります。Verisignの証明書生成ツールから、keytoolによって生成された証明書リクエスト・ファイル（ここではclientsign.csr）の内容を貼り付けるよう求められます。すべての情報を正しく入力すると、指定した電子メールIDに証明書が送信されます。この証明書をキーストアにインポートする必要があります。
テキスト・エディタに証明書の内容を開き、ファイルをclientsign.cerとして保存します。
Verisignによって発行されたルート証明書もキーストアにインポートする必要があります。ルート証明書は、発行者までの証明連鎖を完成させるために必要です。
ルート証明書は、発行者のアイデンティティを証明します。Verisignから受け取った電子メールの指示に従ってルート証明書にアクセスし、ルート証明書の内容をroot.cerという名前のテキスト・ファイルに貼り付けます。
root.cerファイルとclientsign.cerファイルの作成後、次のコマンドを実行して、証明書をキーストアにインポートします。
keytoolユーティリティからストア・パスワードが要求されます。次に公開鍵証明書をインポートします。
keytoolユーティリティからストア・パスワードおよびキー・パスワードが要求されます。パスワードの入力後、同じコマンドを実行して、サーバーのキーストアに信頼できる証明連鎖を設定します。
証明連鎖の設定後、クライアントとサーバーはデジタル署名されたSOAPリクエストを発行できるようになります。
|
注意: 信頼できる証明書は、SOAPメッセージでデジタル署名を発行する場合に必須です。キーストアの自署証明書や信頼されない証明書を使用してデジタル署名を発行することはできません。 |
サーバーは、公開鍵をクライアントにエクスポートして、クライアントからサーバーに送信されるデータを暗号化できるようにする必要があります。サーバーは、対応する秘密鍵を使用して、データを復号化できます。サーバーの公開鍵証明書はクライアントのキーストアにインポートされます。
コマンド・プロンプトで、次のコマンドを実行します。
例33-6 サーバーの公開鍵証明書をエクスポートするコマンド
keytool -export -file serverencpublic.cer -alias serverenckey -keystore server.jks
keytoolユーティリティからストア・パスワードが要求されます。
この例では、serverencpublic.cerにはサーバーの暗号化鍵の公開鍵証明書が含まれています。この証明書をクライアントのキーストアにインポートするには、次のコマンドを実行します。
例33-7 クライアントの暗号化鍵をインポートするコマンド
keytool -import -file serverencpublic.cer -alias serverencpublic -keystore client.jks
キーストア・ユーティリティからストア・パスワードが要求されます。
同様に、クライアントは、次の例に示すように公開鍵をエクスポートして、この鍵をサーバーのキーストアにインポートできるようにする必要があります。
例33-8 クライアントの公開鍵証明書をエクスポートするコマンド
keytool -export -file clientencpublic.cer -alias clientenckey -keystore client.jks
keytoolユーティリティからストア・パスワードが要求されます。
例33-9 公開鍵証明書をインポートするコマンド
keytool -import -file clientencpublic.cer -alias clientencpublic -keystore server.jks
keytoolユーティリティからキーストア・パスワードが要求されます。
これで、サーバーとクライアントのキーストアを使用して、Webサービス・データ・コントロールのセキュリティを構成する準備ができました。
JDeveloperプロジェクトにWebサービス・データ・コントロールを作成したら、データ・コントロールのセキュリティ・ウィザードを使用して、セキュリティを定義できます。
データ・コントロールのセキュリティ・ウィザードの起動方法:
アプリケーション・ナビゲータでWebサービス・データ・コントロールを選択します。
構造ウィンドウで、Webサービス・データ・コントロールを右クリックして「Webサービス・セキュリティの定義」を選択します。
ウィザードのページの詳細は次からの項で説明します。[F1]を押すか、「ヘルプ」をクリックしてヘルプを表示することもできます。
WS-Securityでは、ユーザー名トークンまたはバイナリ・トークンを使用して、サービス・レベルの認証を設定できます。この他、Webサービス・クライアントは、サーバー側の認証またはフェデレートされたSSO環境への参加に使用できるSAMLアサーション・トークンを発行できます。
OracleのWS-Security実装は、認証を行うためにJAZN（JAAS）と統合されています。証明書を使用した認証の実行方法は、実装方法とプラットフォームのセキュリティ・システムとの統合方法によって異なります。ここでは、アプリケーションのデプロイ先サーバーとしてOC4Jを構成する方法について説明します。
|
注意: アプリケーションをOracle Application Serverにデプロイするときに、管理者はセキュリティ編集ツールを使用して、ユーザーをセキュリティ・システムに追加し、適切なロールにグループ化して適切な権限を与える必要があります。このようにsystem-jazn-data.xmlを手動で編集するのはテストの場合のみです。実際に使用するアプリケーションにはお薦めしません。 |
ユーザー名トークン認証では、ユーザー名とパスワードのペアがJAZNリポジトリで信頼できるユーザー・エントリにしてください。
X509トークン認証の場合、証明書の発行対象となるCN（共通名）は、JAZNリポジトリで信頼できるユーザーにしてください。
SAML認証の場合、ユーザーはJAZNリポジトリの有効なユーザーにしてください。
JAZNリポジトリの編集方法:
<JDEV_INSTALL>/J2EE/home/system-jazn-data.xmlを開き、認証の詳細を入力します。たとえば、X509認証の場合は、次のように<users>セクションの下にエントリを作成します。
<user>
<name>King</name>
<display-name>OC4J Administrator</display-name>
<description>OC4J Administrator</description>
<credentials>{903}/LptVQLDeA5sgZFLL5TKlr/qjVFPxB42</credentials>
</user>
ユーザー名トークンでは、ユーザー名とパスワードのペアによる基本的な認証を行います。パスワードは、プレーン・テキストまたはダイジェストとして転送されます。
|
注意: これは、HTTPのBasicまたはDigest認証とは異なります。概念は似ていますが、HTTP認証の受信者はHTTPサーバーであるのに対して、Webサービス・データ・コントロールの場合、ユーザー名トークンはメッセージとともに渡され、受信者はターゲットのWebサービスです。 |
OracleのWS-Security実装は、認証を行うためにJAZN（JAAS）と統合されています。ユーザー名とパスワードのペアは、JAZNリポジトリで信頼できるユーザー・エントリにしてください。
認証にユーザー名トークンを使用する方法:
ウィザードの「認証」ページの「使用可能な操作」の下で、認証を適用する1つまたは複数のポートまたは操作を選択します。
認証タイプとして「ユーザー名トークン」を選択します。
ユーザー名認証に必要な残りの情報を入力します。
信頼できるCAによって発行されたX509証明書は、クライアントの認証に使用できるバイナリ・セキュリティ・トークンです。クライアントはデジタル署名とともにX509証明書を送信します。サーバーは、この証明書を認証に使用します。署名鍵に関連付けられたX509証明連鎖が認証に使用されます。
サーバーには、CAのルート証明書とともにキーストア・ファイルがインストールされている必要があります。
|
注意: X509証明書は、ポートまたは操作レベルで構成可能な他の認証タイプと異なり、ポート・レベルでのみ構成できます。 |
X509証明書による認証の使用方法:
ウィザードの「認証」ページで、認証タイプとして「X509トークン」を選択します。
ウィザードの「キーストア」ページで、キーストア・ファイルの場所を指定し、署名鍵の別名とパスワードを入力します。
SAMLアサーション・トークンを使用して、クライアントがWebサービスに対する認証を受けたり、フェデレートされたSSO環境に参加できるようにすることができます。この場合、認証の詳細は、ベンダー固有の方法を使用してドメイン間で共有できます。
|
注意: SAMLアサーションは、ユーザー・アイデンティティがJAZNで確定できない場合は発行されません。 |
SAML認証の使用方法:
ウィザードの「認証」ページで、認証タイプとして「SAMLトークン」を選択します。
サブジェクト名は、SAMLアサーションの発行対象のユーザー名です。
確認方法として、「SENDER-VOUCHES」または「SENDER-VOUCHES-UNSIGNED」を選択できます。
SENDER-VOUCHES（デフォルト）: SAMLトークンはデジタル署名する必要があります。SAMLトークンの発行にはこの方法をお薦めします。この確認方法を選択する場合、キーストアを構成し、ウィザードの「キーストア」ページでキーストアと署名鍵情報を入力する必要があります。
SENDER-VOUCHES-UNSIGNED: SAMLトークンはデジタル署名なしで転送されます。この確認方法を選択する場合は、キーストアと署名鍵を構成する必要はありません。
送信するSOAPメッセージでデジタル署名を構成し、アプリケーションが接続するWebサービスからの受信メッセージでデジタル署名を確認できます。デジタル署名の存続時間を設定することもできます。
ウィザードの「メッセージ整合性」ページで、ポート・レベルまたは操作レベルで送信SOAPメッセージにデジタル署名を設定し、Webサービスの受信メッセージからデジタル署名を確認できます。
SOAPリクエストに署名し、SOAPレスポンスの署名を確認する方法:
ウィザードの「メッセージ整合性」ページで、適切なオプションを選択します。
ウィザードの「キーストア」ページで、キーストア・ファイルの場所を指定し、署名鍵の別名とパスワードを入力します。
JDeveloperでWebサービスを作成する場合、Webサービス・エディタでセキュリティ・オプションを設定できます。Webサービスのデプロイ後、これらはサーバー側で適用されます。詳細は、JDeveloperのオンライン・ヘルプを参照してください。
Webサービスをデプロイする前に、エディタを実行し、Webサービスの暗号化と復号化の詳細を構成します。暗号化に使用するクライアント（データ・コントロール）の公開鍵が指定されていることを確認してください。
ウィザードの「メッセージの機密保持」ページで、ポート・レベルまたは操作レベルで送信SOAPメッセージを暗号化し、Webサービスからの受信メッセージを復号化できます。
SOAPリクエストを暗号化し、SOAPレスポンスを復号化する方法:
ウィザードの「メッセージの機密保持」ページで、適切なオプションを選択します。Webサービスのデプロイ時にサーバー側で構成した暗号化アルゴリズムを選択する必要があります。
サーバーの公開鍵の別名を入力して、データ・コントロールがサーバーの公開鍵を使用して鍵の詳細を暗号化できるようにします。この例では、serverencpublicがキーストア構成でインポートされたサーバーの公開鍵証明書です。
Webサービスが受信メッセージの暗号化を使用する場合は、「受信SOAPレスポンスの復号化」を選択します。
ウィザードの「キーストア」ページで、キーストア・ファイルの場所を指定し、暗号化鍵の別名とパスワードを入力します。
「キーストアの作成方法」では、クライアント（Webサービス・データ・コントロール）とサーバー（デプロイされたWebサービス）のキーストアの設定方法について説明しました。データ・コントロールのセキュリティ・ウィザードの「キーストアの構成」ページで、データ・コントロール・セキュリティに使用するキーストアに必要な情報を入力します。
Webサービスに基づいてデータ・コントロールのWS-Securityを構成する最後の手順は、キーストア詳細の指定です。ここではクライアント・キーストアにアクセスするための情報を入力します。ウィザードの終了後、データ・コントロールで生成されるすべてのリクエストとデータ・コントロールが処理するすべてのレスポンスの署名と暗号化に、ストアで構成した鍵を使用できるようになります。
キーストア・アクセス情報の設定方法:
ウィザードの「キーストアの構成」ページに適切な値を入力します。
Oracle ADF Business Componentsアプリケーション・モジュールには、Webサービス用のサポートが組み込まれています。ユーザーがアプリケーション・モジュールのクライアント・インタフェースに追加するカスタム・メソッドはすべて、Webサービス・デプロイ・オプションを有効にすると、そのWebサービス・インタフェースに表示されます。
アプリケーション・モジュールをWebサービスとして有効にする方法:
アプリケーション・モジュールのカスタムJavaクラスを有効にし、Webサービス・インタフェースに表示する1つまたは複数のカスタム・メソッドにそれを追加します。
アプリケーション・モジュール・エディタを開き、「クライアント・インタフェース」タブで、クライアント・インタフェースに表示するカスタム・メソッドを1つまたは複数選択します。
アプリケーション・モジュール・エディタを開いたまま、「リモート」パネルで「リモート対応のアプリケーション・モジュール」を選択した後、「使用可能」リストで「J2EE Webサービス」を選択し、選択したリストにそれを移動します。
「OK」をクリックして、変更を保存します。
アプリケーション・モジュールのリモート対応のJ2EE Webサービス・オプションを有効にすると、アプリケーション・モジュール・エディタを終了するたびに、Webサービス・クラスとアプリケーション・モジュールのクライアント・インタフェースに実施した変更の同期処理がJDeveloperによって実行されます。
JDeveloperは、生成されたWebサービス・クラスを、アプリケーション・モジュールが存在するパッケージのserver.webserviceサブパッケージの中に作成します。たとえば、アプリケーション・モジュールの名前がoracle.srdemo.model.SRServiceである場合、その生成されたWebサービス・クラスはoracle.srdemo.model.server.webserviceパッケージ内でSRServiceServerという名前になります。
アプリケーション・モジュールのクライアント・インタフェース内のsomeMethodという名前のメソッドごとに、JDeveloperは生成されたWebサービス・クラス内にdelegatorメソッドを1つ追加します（例33-10を参照）。このコードが実行する基本的な手順は次のとおりです。
プールからアプリケーション・モジュール・インスタンスを取得する。
Webサービス・メソッド・コールをアプリケーション・モジュール・インスタンスに委任する。
メソッドがvoidでない場合は、結果を返す。
アプリケーション・モジュール・インスタンスを、削除することなくプールに解放する。
該当するWebサービス・コードではConfigurationオブジェクトのreleaseRootApplicationModuleメソッドにfalseを渡しているため、アプリケーション・モジュール・インスタンスは削除されず、次に受信するステートレスなWebサービス・メソッドの起動を処理できる状態でプール内に残ります。その後、アプリケーション・プールは、Webアプリケーションの場合と同様に負荷に伴って増減します。この場合の唯一の違いは、プールがまったくステートレスな方法で使用される点です。アプリケーション・モジュール・プールのチューニングの詳細は、第29章「アプリケーション・モジュール・プーリングの理解」を参照してください。
例33-10 アプリケーション・モジュール・クライアント・インタフェース内の各メソッドで生成されるコード
// In YourAppModuleServer.java generated web service class
:
public void someMethod(int p1, String p2) {
AppModuleImpl _am = null;
try {
// 1. Acquire an application module instance from the pool
_am = (AppModuleImpl)Configuration.createRootApplicationModule(
"com.yourcompany.yourapp.YourAppModule", "YourAppModuleLocal");
// 2. Delegate a call to its someMethod() method, passing arguments
_am.someMethod(p1, p2);
// 3. If return of method is non-void, return the result here
} finally {
if (_am != null) {
// 4. Release application module to the pool, without removing it
Configuration.releaseRootApplicationModule(_am, false);
}
}
:
}
JDeveloperは、アプリケーション・モジュール上でWebサービス・リモート・オプションを有効化する処理の一部として、Webサービス・デプロイメント・プロファイルを作成します。このサービスをデプロイするには、該当するデプロイメント・プロファイルのポップアップ・メニューで「デプロイ」を選択するだけです。
カスタム・メソッドのパラメータおよび戻り型では、java.io.Serializableインタフェースを実装する任意のデータ型を使用できます。ただし、RowやViewObjectのようなoracle.jboパッケージの汎用ADF Business Componentsインタフェースは、これに含まれません。これらの型は、アプリケーション・モジュールのカスタム・インタフェースでは許可されていますが、Webサービスでは一般にサポートされていません。Webサービス・インタフェースを使用してデータ・コレクションを返すには、Serializableインタフェースを実装するカスタムなデータ転送オブジェクトを作成し、それらのデータ・コレクションをビュー・オブジェクト問合せ結果から移入した後、配列に返す必要があります。
たとえば、SRDemoアプリケーションのSRServiceアプリケーション・モジュール内のビュー・オブジェクト・インスタンスServiceRequestsから1行を返す必要がある場合は、適切なBeanプロパティおよび対応するgetterメソッドとsetterメソッドを持つ新しいServiceRequest Beanを作成する必要があります。該当するクラスでは、Serializableインタフェースを実装する必要があります。これはマーカー・インタフェースにすぎないため、クラス定義にimplements Serializableというキーワードを追加する以外の実装は不要です。このBeanを作成すると、そのプロパティをカスタム・メソッドの実装内に移入し、次のようにカスタム・サービス・メソッドの戻り値として返すことができます。
public ServiceRequest findServiceRequest(int svrid)
シリアライズ可能オブジェクトのコレクションを返す必要がある場合は、Webサービス・インフラストラクチャによってサポートされている任意の型を使用できます。たとえば、次のようなカスタム・メソッド・シグネチャを使用して、1つまたは複数のサービス・リクエストから構成される配列を返すこともできます。
public ServiceRequest[] findServiceRequests(String status, String technician)
サービス指向アーキテクチャでは、Webサービスから提供される機能をアプリケーション・モジュールで利用しなければならない場合もあります。JDeveloperに組み込まれているWebサービス・ウィザードを使用すると、そのようなタスクを簡単に実行できます。該当するウィザードを使用してWebサービス・プロキシ・クラスを作成すると、サービスのコールは、ローカルなJavaオブジェクト内のメソッドをコールするのと同じように簡単になります。
Webサービスは、任意のプログラミング言語で実装し、ネットワーク上の任意のサーバーに配置できます。各Webサービスでは、言語に依存しない標準的なXMLフォーマットで記述することにより、一連の該当するメソッドをそのAPI内で指定します。このXMLドキュメント（構文は、33.1.2項「WSDL」で説明したWeb Services Description Language（WSDL）に準拠）を使用すると、Webサービスのメソッドの名前に加えて、それらのメソッドが予期するパラメータや実際の戻り値のデータ型も、JDeveloperのようなツールで自動的に理解できます。
Webサービスを使用するには、該当するWSDLドキュメントを特定するURLを知る必要があります。該当するURLは、次のようなファイルベースのURLの場合もあります。
file:///D:/temp/SomeService.wsdl
たとえば、WSDLドキュメントは、電子メールの添付ファイルとして受信した場合、ローカルのハード・ドライブに保存します。また、URLは、次のようなHTTPベースのURLの場合もあります。
http://somerserver.somecompany.com/SomeService/SomeService.wsdl
一部のWebサービスの場合、そのWSDLドキュメントは、実際のサービスURL自体を変更する特殊なパラメータを使用して利用可能になります。そのため、たとえば次のようなHTTPアドレスでリクエストを受信することが期待されているWebサービスの場合は、
http://somerserver.somecompany.com/SomeService
同一のURLの末尾に次のような追加のパラメータを付けて、対応するWSDLドキュメントを公開することもあります。
http://somerserver.somecompany.com/SomeService?WSDL
標準が確立されていないため、WSDLドキュメントに対する正確なURLを知っておくのみで十分です。該当するURLを知っておけば、該当するサービスをコールするためのWebサービス・プロキシ・クラスを作成できます。
アプリケーション・モジュールからWebサービスをコールするには、起動するサービスのWebサービス・プロキシ・クラスを作成します。Webサービス・プロキシとは、該当するアプリケーション内のWebサービスを表す、生成されたJavaクラスのことです。該当するWebサービスのサービスURLをカプセル化し、サービスをコールをするための低レベルの詳細情報を処理します。
Webサービス・プロキシ・クラスは、WebサービスのパブリックAPIに対応する一連のJavaメソッドを表します。Webサービス・プロキシ・クラスを使用すると、Webサービス内の任意のメソッドを、他の任意のローカルなJavaクラスのメソッドの場合と同じ方法でコールすることができます。
アプリケーション・モジュールからWebサービスをコールするには、次の3つの手順を実行します。
WebサービスのWebサービス・プロキシ・クラスを作成します。
該当するWebサービス・プロキシ・クラスのインスタンスを、アプリケーション・モジュール内で作成します。
Webサービス・プロキシ・オブジェクト上でメソッドを1つまたは複数起動します。
コールするWebサービス用のWebサービス・プロキシ・クラスを作成するには、Webサービス・プロキシ作成ウィザードを使用します。このウィザードは、新規ギャラリの「Business Tier」→「Web Services」カテゴリにあります。該当するウィザードが表示されたら、次の手順に従って操作します。
「Webサービス記述」ページの手順1で、該当するサービスを表すWSDLドキュメントのURLを入力した後、[Tab]を押します。
たとえば、最新のJAXRPC標準に準拠するサービスを作成し、それをOracle Application Serverにデプロイする場合、WSDL URLは次のようになります。
http://someserver:8888/StockQuoteService/StockQuoteServiceSoapHttpPort?WSDL
ウィザードの「次へ」ボタンが有効になっている場合は、WSDLドキュメントをJDeveloperが認識し、検証済です。そのボタンをクリックすると、手順3に進むことができます。該当するボタンが有効になっていない場合は、「指定不可の理由」ボタンをクリックすると、WSDLドキュメントの読込みを試行した際にJDeveloperが検出した問題がわかります。URLを検証した後、必要に応じて問題を解決し、手順1を再試行してください。
「デフォルト・マッピング・オプション」ページの手順5で、生成されたWebサービス・プロキシ・クラスのJavaパッケージ名を選択し、「終了」をクリックします。
JDeveloperは、WSDLドキュメント内で検出されたWebサービス・ポートの名前を反映した名前を使用して、ユーザーが指定したパッケージ内でWebサービス・プロキシ・クラスを生成します。Webサービス・ポート名は、人間が判読できるStockQuoteServiceのような適切な名前の場合もあれば、StockQuoteServiceSoapHttpPortのようなわかりにくい名前の場合もあります。このポート名は、ユーザーが使用中のWebサービスを公開した開発者によって決定されます。サービスのポート名がStockQuoteServiceSoapHttpPortであると仮定すると、JDeveloperはStockQuoteServiceSoapHttpPortClientという名前のWebプロキシ・クラスを生成します。
Webサービス・プロキシは、アプリケーション・ナビゲータ内で、WebServiceNameProxyという単一の論理ノードとして表示されます。たとえば、前述のWebサービスStockQuoteServiceのノードは、ナビゲータ内でStockQuoteServiceProxyという名前で表示されます。JDeveloperでは、プロキシ・クラスの生成処理の一部として、サーバーの起動に使用するメインのWebサービス・プロキシ・クラスのみでなく、多数の補助クラスとインタフェースも生成されます。それらのファイルは、アプリケーション・ナビゲータ内でWebサービス・プロキシ・ノードを選択して、構造ウィンドウで確認できます。生成されたファイルは、Webサービスを起動するための低レベルの実装の一部で使用されます。
生成された補助クラスのうち、参照する必要のあるものは、構造化されたWebサービス・パラメータまたは戻り型を保持するように作成されるクラスのみです。たとえば、WebサービスStockQuoteServiceのquoteForSymbol()メソッドが、Stringパラメータを1つ受け取り、株の時価を表す浮動小数点値を1つ返すものとします。Webサービスの設計者がシンプルな浮動小数点数を1つ返すように選択すると、Webサービス・プロキシ・クラスは次のような対応するメソッドを持つことになります。
public float quoteForSymbol(String symbol)
また、Webサービスの設計者が結果として複数の情報を返す方が便利であると考える場合は、サービスのWSDLファイルには、包含される複数の要素を記述する名前付き構造の定義が1つ含まれることになります。たとえば、シンボル名と時価が結果としてサービスから返されるとします。これら2つのデータ要素を含めるために、WSDLファイルでは、String型のsymbolという名前の要素と浮動小数点型のpriceという名前の要素を持つQuoteInfoという名前の構造を1つ定義する場合もあります。このような状況でJDeveloperがWebサービス・プロキシ・クラスを生成する場合、Javaメソッド・シグネチャは次のようになります。
public QuoteInfo quoteForSymbol(String symbol)
戻り型QuoteInfoでは、Webサービス・プロキシ実装を構成する補助クラスの1つを参照します。それは、WSDLドキュメントの中で定義されている構造の名前と型がプロパティに反映されているシンプルなBeanです。同様に、Webサービスが受け取るパラメータ値が構造または構造の配列である場合は、それに対応する生成されたBeanを使用して、それらの構造をJavaコード内で操作する必要があります。
Webサービス・プロキシ・クラスが生成されると、アプリケーション・モジュール内のカスタム・メソッド内で使用できます（例33-11を参照）。
例33-11 Webサービス・プロキシ・クラスを使用したWebサービス・メソッドのコール
// In YourModuleImpl.java
public void performSomeApplicationTask(String symbol) throws Exception {
// application-specific code here
:
// Create an instance of the web service proxy class
StockQuoteServiceSoapHttpPortClient svc =
new StockQuoteServiceSoapHttpPortClient();
// Call a method on the web service proxy class and get the result
QuoteInfo quote = svc.quoteForSymbol(symbol);
float currentPrice = quote.getPrice();
// more application-specific code here
}
アプリケーション・モジュールからWebサービスを起動する場合、Webサービス・プロキシ・クラスはXMLベースのWebサービス・プロトコルを使用する際の低レベルの詳細処理を実行します（33.1.1項「SOAP」を参照）。具体的には、次の処理を実行します。
メソッドの起動を表すXMLドキュメントを作成
メソッド引数をXMLにパッケージング
HTTP POSTリクエストを使用してXMLドキュメントをサービスURLに送信
Webサービスから受信したXMLエンコード・レスポンスのパッケージングを解除
起動対象のメソッドが戻り値を持つ場合は、アプリケーション・モジュール・コード内で操作できるように、適切な型のオブジェクトとして受信します。
生成されたWebサービス・プロキシ・クラスを使用すると、リモートWebサービスの起動は、ローカルJavaクラス内のメソッドをコールするのと同じように簡単になります。その場合に注意が必要な唯一の現実的な違いは、HTTPリクエストに関与する問題が存在する場合にWebサービス・メソッドのコールが失敗する可能性がある点です。Webサービス・プロキシに対して実行するメソッド・コールでは、適切なtry...catchブロックを使用してコールをラップすることにより、リクエストの失敗に備える必要があります。例33-12では、Webサービス例外を検出するというベスト・プラクティスの実装により、前述の簡単な例を改善しています。この場合は該当するエラーをJboExceptionとして再スローしているだけですが、アプリケーションではさらに適切なエラー処理を実装することもできます。
例33-12 try/catchブロックを使用したWebサービス・メソッド・コールのラップ
// In YourModuleImpl.java
public void performSomeApplicationTask(String symbol) {
// application-specific code here
// :
QuoteInfo quote = null;
try {
// Create an instance of the web service proxy class
StockQuoteServiceSoapHttpPortClient svc =
new StockQuoteServiceSoapHttpPortClient();
// Call a method on the web service proxy class and get the result
quote = svc.quoteForSymbol(symbol);
}
catch (Exception ex) {
throw new JboException(ex);
}
float currentPrice = quote.getPrice();
// more application-specific code here
}
参照情報にアクセスするために使用するWebサービスもあります。また、データを変更するためにコールするサービスもあります。このデータ変更は、自社内の同一チームまたは別のチームによって該当サービスが記述されている場合、自社内で実行される可能性があります。Webサービスが自社のファイアウォールの外部にある場合はもちろん、変更対象のデータベースは別の会社によって管理されることになります。いずれの場合でも、起動するWebサービスによって実行されるデータ変更は、アプリケーション・モジュールの現在の作業ユニットとは無関係な独自のトランザクションによって実行されるということを理解しておくことが重要です。たとえば、データを変更するWebサービスを起動した後、rollback()をコールしてアプリケーション・モジュールの現在の作業ユニット内で保留中の変更を取り消しても、該当するプロセス内でコールしたWebサービスによって実行される変更に影響はありません。対応するWebサービス・メソッドを起動して、補正用の変更を実行し、アプリケーション・モジュールのトランザクションのロールバックを無効にする必要がある場合があります。
コール対象のWebサービスが自社ファイアウォールの外部にある場合は、HTTPプロキシ・サーバーを使用できるような適切な構成にJavaシステム・プロパティが設定されていることを確認する必要があります。確認する必要のあるJavaシステム・プロパティは、次のとおりです。
http.proxyHost
プロキシ・サーバーの名前を設定します。
http.proxyPort
プロキシ・サーバーのHTTPポート番号（80の場合が多い）を設定します。
http.nonProxyHosts
プロキシ・サーバーを使用しないサーバーを縦線で区切ってリストで指定します（オプション。例: "localhost|127.0.0.1|*.yourcompany.com"）。
JDeveloperでは、「IDE設定」ダイアログの「Webブラウザとプロキシ」ページでHTTPプロキシ・サーバーを構成できます。アプリケーションを実行する際、JDeveloperの-Dコマンドライン・オプションを使用すると、このダイアログで指定した設定値に基づき、前述の3つのシステム・プロパティを設定できます。
