Oracle® Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11g リリース2 (11.1.2.4.0) B69399-03 |
|
![]() 前 |
![]() 次 |
この章では、ADFアプリケーション・モジュールの公開方法と、サービス・インタフェース接続を定義してFusion Webアプリケーションで外部Webサービスとして使用できるようにする方法を説明します。また、公開されたアプリケーション・モジュールを外部サービスとしてFusion Webアプリケーションに組み込む方法についても説明します。
この章の内容は次のとおりです。
サービス対応アプリケーション・モジュールは、サービス・インタフェースを使用して、サービス利用者に通知するADFアプリケーション・モジュールです。サービス利用者がサービス対応アプリケーション・モジュールの利用には、Webサービス・アクセス、Service Component Architecture (SCA)コンポジット・アクセス、および別なADFアプリケーション・モジュールからのアクセスという3つのシナリオがあります。
Service Component Architecture (SCA)は、リモートで使用可能なサービスを実装するためのオープンで技術に中立なモデルを提供します。SCAはビジネス機能の観点から定義されており、アプリケーション開発者によるミドルウェア機能のアクセスを容易にします。ADF Business Componentsはサービス・インタフェースで公開可能なアプリケーション・モジュールにより、SCA準拠ソリューションをサポートしています。
アプリケーション・モジュールをサービス対応にすると、JDeveloperが必要なアーティファクトを作成します。その構成内容は次のとおりです。1) サービスを定義しているJavaインタフェース、2) Javaインタフェースを実装するEJB 3.0セッションBean、3) サービスの操作を記述したWSDLファイル、および(4) サービスのデータ構造を定義したXML Schema Document (XSD)。サービス・インタフェースはWSDLとXSDを組み合せた中立言語で、Fusion Webアプリケーション・クライアント用に記述されます。
SCAは次の2種類のサービスを定義します。
リモート対応可能なサービス。通常はきめが粗く、結合が緩いSOAアーキテクチャでのリモート公開用に設計されます。
ローカル・サービス。通常はきめが細かく、緊密に結合されたアーキテクチャ内で同時にデプロイされる他の実装でのローカルな使用のために設計されます。
ADF Business Componentsサービスは最初のカテゴリに分類され、リモート対応可能サービスとしてのみ使用する必要があります。
リモート・アプリケーション・モジュールによって定義されたADF Business Componentsサービス(データ・アクセスとメソッド・コールを含む)は、その他のあらゆるアプリケーション・モジュールとの相互運用が可能です。これは、同じアプリケーション・モジュールで、ADFデータ・コントロールおよびWebサービス・クライアントを使用している対話型のWebユーザー・インタフェースをサポートできるということを意味しています。
サービス対応アプリケーション・モジュールは、開発チームが公開し、Fusion Webアプリケーションに提供できます。リモート・サービスからアセンブルされたFusion Webアプリケーションも、単一のアプリケーション・サーバー上で稼働するための参加サービスが不要です。
Webアプリケーションは異なる複数のアプリケーション・サーバーで実行されることがありますが、SCAは統合アプリケーションのように見えます。利用するクライアント・プロジェクトはADFサービス・ファクトリ検索メカニズムを使用して、データおよびサービス対応アプリケーション・モジュールによってカプセル化されたあらゆるビジネス・メソッドにアクセスします。実行時は、サービスの起動に使用されるプロトコル(SOAPまたはRMI)に応じて、コール元のクライアントとADF Webサービスが同じトランザクションに参加する場合とそうでない場合があります。RMIプロトコルとJava Transaction API (JTA)マネージド・トランザクションのみで、コール元のクライアントと同じトランザクションでサービスをコールすることができます。デフォルトでは、ADF Webサービスは、RMIプロトコルをサポートするために、同じトランザクションに参加するように構成されます。
ADF Business Componentsサービスを使用する前に、他のOracle ADF機能について理解しておくと役立ちます。次に、関連する他の機能へのリンクを示します。
SCAとサービス・データ・オブジェクト(SDO)の標準の詳細は、Open SOAのWebサイト(http://www.osoa.org
)を参照してください。
WebサービスおよびOracle WebLogic ServerのWebサービス・サポートの背景は、『Oracle Fusion Middleware Webサービスの紹介』を参照してください。
Business Process Execution Language (BPEL)エンティティ変数を使用してSDOデータ・プロバイダにデータ操作を委譲する方法の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。
Oracle WSMでサポートされる事前定義済認可ポリシー(RMIクライアントの認可を有効にするために使用されるbinding_permission_authorization_policy
など)の詳細は、次を参照してください。詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。
ローカル・サービス・サポートには、9.10項「アプリケーション・モジュールのクライアント・インタフェースのプログラム的操作」で説明しているApplicationModuleインタフェースとViewObjectインタフェース・サポートを使用します。
oracle.jbo
パッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。
Oracle Fusion Middleware Oracle ADF Model Java APIリファレンス
アプリケーション・モジュールは、ビジネス・ロジックを関連する一連のビジネス機能としてカプセル化するADF Business Componentsフレームワーク・コンポーネントです。アプリケーション・モジュールはサービスにマップされます。アプリケーション・モジュールの概要エディタを使用して、Webサービス・インタフェースを有効化し、ビュー・オブジェクト・データの行をサービス・データ・オブジェクト(SDO)コンポーネントとして公開します。
SDOコンポーネントの基礎になっているSDOフレームワークによって、ビュー・オブジェクトのデータが抽出され、JavaとXML間でのデータ構造のやり取りが標準化されます。この種のデータ抽出によってサービス指向アーキテクチャ(SOA)での異種環境データ・ソースの処理が簡略化され、対話型のWebユーザー・インタフェースとWebサービス・クライアントに同じビュー・オブジェクトを使用することで、ビュー・オブジェクトを選択してサービス対応にできます。
JDeveloperでは、アプリケーション・モジュールをWebサービスとして公開できます。このようなWebサービスでは、アプリケーション・モジュールで定義されたビュー・インスタンスに基づくSDOコンポーネントを使用して、JavaとXML間のデータ構造のやり取りが標準化されます。JDeveloperは、Webサービス・クライアントがコンシューミング・アプリケーションで使用するWSDLサービス記述も生成します。
注意: JDeveloperでは、サービス対応アプリケーション・モジュールのビュー・オブジェクトのSDOコンポーネント生成のみをサポートします。現時点では、これ以外のOracle ADFビジネス・コンポーネントをSDOコンポーネントとして定義できません。 |
サービス対応アプリケーション・モジュールは、ビュー・オブジェクト、カスタム・メソッド、組込みデータ処理操作、および指定されたビュー基準に基づく特殊な検索方法を公開し、クライアントが使用できるようにします。アプリケーション・モジュール・サービス・インタフェースの有効後、ADF Business Components Service Interfaceデプロイメント・プロファイルを作成して、ターゲット・アプリケーション・サーバーにデプロイする必要があります。
Business Process Execution Language (BPEL)プロセス・サービス・コンポーネントで使用する、ビュー・インスタンス・データ処理操作も公開する必要があります。BPELは、複数のサービスからエンドツーエンドのビジネス・プロセスを構成するための言語です。BEPLエンティティ変数の使用によってSDOデータ・プロバイダにデータ操作を委譲する方法の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。
注意: SDOパラメータを使用して直接メソッドを実装するのではない点が重要です。SDOフレームワークを使用して、実行時にのみビュー行のタイプをラップします。 |
JDeveloperでアプリケーション・モジュールを編集して、最上位のビュー・オブジェクトを公開し、サポートしているサービス操作を定義するWebサービス・インタフェースを作成します。選択する最上位のビュー・オブジェクトは自動的にサービス対応になり、サービス・クライアントがアクセス可能になります。
標準的なサービス操作の目的は、ビュー・オブジェクトのデータ処理操作を公開することです。標準のサービス操作を起動することで、基になるフレームワーク・オブジェクトで定義したあらゆるビジネス・ロジック(たとえばビジネス・ルールの評価など)が、適用されます。表11-1は、サービス・ビュー・インスタンスがサポートしている標準操作のリストです。
表11-1 標準ビュー・インスタンス・データ処理操作
操作 | メソッド名 | 操作の説明 |
---|---|---|
|
|
単一のADF Business Componentsビュー行を作成します。 |
|
|
単一のADF Business Componentsビュー行を更新します。 |
|
|
単一のADF Business Componentsビュー行を削除します。 |
|
|
ADF Business Componentsビュー行があれば更新し、なければ新しく作成します。 |
|
|
主キーによって、単一のADF Business Componentsビュー行を取得します。 |
|
|
選択したビュー・オブジェクトの問合せ文に基づき、ADF Business Componentsのビュー行のリストを検索して戻します。 問合せでは、問合せの実行に必要として定義されたバインド変数は指定してはなりません。サービス・インタフェースは実行時には必須バインド変数を公開しません。このシナリオ用の検索メソッドの作成の詳細は、11.2.8項「必須バインド変数によってフィルタされる宣言的検索操作の公開方法」を参照してください。 |
|
|
SDOベースのビュー基準によって、単一のADF Business Componentsビュー行のリストを検索して戻します。これは必須バインド変数に依存しているADF Business Componentsビュー行のフィルタには適した方法です。 |
|
|
ADF Business Componentsビュー行リストに対する作成、更新、削除、またはマージ操作を実行します。指定した操作が特定のリスト内のすべてのオブジェクトに対して適用されます。 |
|
|
ADF Business Componentsビュー行リストに対する作成、更新、または削除操作を実行します。 |
注意: 親ビュー・オブジェクトのSDOクラスを生成すると、多相コレクション内で親を拡張するビュー・インスタンスのSDOクラスがJDeveloperによって自動的に生成されます。多相ビュー・オブジェクトの詳細は、42.6.5項「多相ビュー行関連の作業」を参照してください。 |
子ビュー・オブジェクトのSDOクラスの作成方法の詳細は、11.2.4項「個別のビュー・オブジェクトのサービス対応化の方法」を参照してください。
始める前に:
SDOフレームワークによって、サービス対応ADFアプリケーション・モジュールがどのようにサポートされ、Webサービス・クライアントのデータ行アクセスやサービス操作がどのように有効化されるかについて、理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
サービス対応アプリケーション・モジュールは、標準Webサービス(@WebService
の注釈の付いたJavaクラスまたはJavaインタフェース)がすでに含まれているプロジェクトには作成しないでください。JDeveloperのデプロイメント・プロファイルでは、同じプロジェクトに属する標準WebサービスとADFビジネス・サービスのデプロイはサポートされません。標準Webサービスと同じプロジェクトに属するADFビジネス・サービスのWebサービスをデプロイしようとすると、Oracle WebLogic Server例外エラーが発生してデプロイメントが失敗します。
次のタスクを完了します。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。
9.2.1項「アプリケーション・モジュールの作成方法」に記載されている方法に従って、該当するアプリケーション・モジュールを作成します。
オプションで、JDeveloperプリファレンスを設定して、生成されるSDOクラス名のデフォルト接尾辞の指定、サービス共通のインタフェースとクラスが入るデフォルト・サブパッケージの変更、および生成されるSDOスキーマとWebサービスのデフォルトのネームスペース接頭辞の設定を行います。11.2.13項「ADF Webサービス・インタフェース生成用プリファレンスの設定方法」を参照してください。
サービスでカスタム検索操作を公開する場合は、5.11.1項「名前付きビュー基準を宣言的に作成する方法」の説明に従って、宣言的なビュー基準を作成してカスタム問合せを指定します。
Webサービス・インタフェースを作成するには:
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「サービス・インタフェース」ナビゲーション・タブをクリックし、サービス・インタフェースのサポートの有効化ボタンをクリックします。
サービス・インタフェースの作成ウィザードを使用して、該当するオプションを構成します。
サービス・インタフェースの作成ウィザードの「サービス・インタフェース」ページで、Webサービスの名前とターゲット・ネームスペースを入力します。
ターゲット・ネームスペースはサービスのURIで、同じURIを入力することで、類似のサービスをグループ化するために割り当てることができます。
サービス対応にするビュー・インスタンスに定義された静的なコントロール・ヒント(UIヒント)を戻すメソッドを生成するには、「コントロール・ヒント操作の生成」を選択します。
このオプションを有効にすると、ウィザードがgetDfltCtrlHints()
メソッドをサービス・インタフェースに追加します。サービス・インタフェース・クライアントはこのメソッドを起動して、サーバー上のUIヒントを解消するので、データベースへの往復は不要になります。メソッドはビュー・オブジェクト名とロケールを取得し、そのロケールの基本的なUIヒントを戻します。
アプリケーション・モジュールのメソッドを非同期サービス・メソッドとして公開し、Webサービスで同期と非同期の両方の操作を有効にするには、「非同期Webサービス・メソッドの生成」を選択します。
デフォルトでは、Webサービスは同期サービス・メソッドをサポートしています。これによってクライアント・アプリケーションを強制的に起動して待機させ、レスポンスが返されるまで作業を続行できません。レスポンスがすぐに返される場合は、このWebサービスの起動方法が一般的です。しかし、リクエスト処理が遅延する場合もあるため、クライアント・アプリケーションは先に処理を続行し、後でレスポンスを処理するほうが効率的なことも少なくありません。
「サービス・カスタム・メソッド」ページで、サービス・インタフェースに公開するカスタム・メソッドを追加し、各メソッドのパラメータと戻り値のデータ型を定義します。
有効にするカスタム・サービス・メソッドのパラメータとvoid以外の戻り値は、サービス・インタフェースでサポートされているデータ型(Javaプリミティブ・タイプなど)またはそのようなデータ型のリスト(oracle.jbo.server.ViewRowImpl
、java.util.List<
ViewRowImpl
>
、oracle.jbo.AttributeList
、java.util.List<
AttributeList
>
、java.util.List<
PrimitiveType
>
など)である必要があります。
ViewRowImpl
およびAttributeList
の両方のデータ型は、Webサービス・クライアントに対して同一の行構造で公開されますが、実行時には基本的な違いがあります。サポートされているデータ型の詳細は、11.2.3項「ADF Webサービス・インタフェース上のメソッド・シグネチャについて」を参照してください。
ViewRowImpl
またはAttributeList
データ型を使用して、各パラメータと戻り値に対して、サービス・インタフェース内で使用可能なカスタム・メソッドを選択後、行構造に対応するビュー・オブジェクト・インスタンスの名前を選択する必要があります。
「選択済」リストで、returnまたはparametersを展開して、項目を選択します。
Java要素データ型を「要素Javaタイプ」に入力します。
Java要素型がViewRowImpl
またはAttributeList
の場合は、「要素のビュー・オブジェクト」に行構造を識別するビュー・オブジェクト・インスタンス名を入力します。
たとえば、CustomerInfo
ビュー・オブジェクト・インスタンスの単一行を定義する場合、次のようなカスタム・メソッド・シグネチャが必要になります。
public ViewRowImpl findCustomerInfo(int id)
次にサービス・インタフェース内での表示用にfindCustomerInfo()
カスタム・メソッドを選択した後、その戻り値をツリー内で選択し、「ビュー・オブジェクト」プロパティを、実行時に行構造を使用するビュー・インスタンスの名前であるCustomerInfo
に設定します。
サービス情報メッセージ(カスタム・メソッドの警告や例外など)や、プロセス処理メソッドの警告を公開するには、「戻りサービス・データ・オブジェクトに警告を含める」を選択します。
たとえば、従業員給与の合計を返すメソッドで合計が望ましい範囲を超えている場合に、情報メッセージを表示するとします。
「戻りサービス・データ・オブジェクトに警告を含める」が選択されていない場合、サービス・レスポンスとともに情報メッセージは返されません。
このオプションは、メソッドがビュー行やビュー行のリストを返さない場合にのみ有効になります。メソッドがビュー行を返す場合、メソッドで警告がサポートされるかどうかは、11.2.4項「個別のビュー・オブジェクトのサービス対応化の方法」で説明しているように、基礎となるビュー・オブジェクトによって決定されます。
情報メッセージ(および警告)は、戻りオブジェクトの一部として報告されます。JDeveloperにより、戻りオブジェクトとして適切なラッパーが生成され、このラッパーに実際のメソッド戻り値と情報メッセージが含まれています。
「サービス・ビュー・インスタンス」ページで、サービス・インタフェースで公開する、アプリケーション・モジュール内の最上位ビュー・インスタンスを選択します。
最上位のビュー・レベル・インスタンスのビュー・オブジェクト・サブタイプは、自動的にサービス対応になります。
このページで、公開したメソッドでサポートされる、使用可能なデータ処理操作も有効にできます(図11-1を参照)。
「基本操作」タブで、現在選択されているビュー・インスタンスのデータ処理操作を選択し、「メソッド名」フィールドで、選択したサービスの操作の名称を、サービス・インタフェースで公開する名前に変更します。
標準的なサービス操作の目的は、ビュー・オブジェクトのデータ処理操作を公開することです。サービス操作を起動することで、基になるフレームワーク・オブジェクトで定義したあらゆるビジネス・ロジック(たとえばビジネス・ルールの評価など)が、適用されます。サービス・ビュー・インスタンスでサポートされている操作の詳細は、表11-1を参照してください。
選択可能な検索メソッド操作の場合、検索メソッドはビュー・オブジェクトの問合せ文で必須バインド変数を参照してはなりません。必須バインド変数は、有効なバインド変数値がなければ問合せの実行ができないようにするものです。サービス・インタフェースは実行時には必須バインド変数を公開しません。このシナリオ用の検索操作の定義の詳細は、11.2.8項「必須バインド変数によってフィルタされる宣言的検索操作の公開方法」を参照してください。
宣言的検索操作を公開するには、「ビュー基準の検索操作」タブを選択し、「ビュー基準の追加」アイコンをクリックします。
カスタム検索操作を定義して、事前に定義された問合せの実行をサービスにサポートさせることができます。名前付きビュー基準の定義の詳細は、5.11項「名前付きビュー基準の処理」を参照してください。
注意: サービス・インタフェースの検索操作は、プロジェクトで定義された特定のビュー基準に基づいています。したがって、ビュー基準のバインド変数が対応する検索操作メソッドのパラメータと一致しなければなりません。検索操作を定義しサービス・インタフェースを生成した後、バインド変数の数や順番を変更すると、対応するメソッドが実行時に実行されなくなります。したがって基にあるビュー基準を変更したら、サービス・インタフェースを生成しなおす必要があります。 |
「ビュー基準検索操作の構成」ダイアログで、検索操作用の名前付きビュー基準を選択します。
このダイアログには、参照先のビュー・オブジェクトが公開しているビュー基準のリストが表示されます。たとえば、OrderInfoVO
はオーダーIDを指定するバインド変数OrdId
を使用して、OrderInfoVOCriteria
を定義しています(図11-2を参照)。
ビュー基準でバインド変数が使用されている場合、XML名をダブルクリックして、XML定義内でそのサービスが表示される名前をカスタマイズできます。
「次」をクリックして、サービス・ビュー・インスタンスによって公開されるカスタム・メソッドを確認します。
「終了」をクリックします。
JDeveloperはサービス・インタフェース・クラスを生成し、選択したすべてのビュー・インスタンス・オプションを有効にします(図11-3を参照)。
サービス対応アプリケーション・モジュール用に生成されたファイルは変更しないでください。生成されたファイルにより、サービス・インタフェースに必要なメソッドが実装されます。この例外となるのは、リモート・サービス実装クラスにJava注釈を追加する必要があるユースケースです。たとえば、リモート共通インタフェース実装クラスへの注釈の追加では、11.2.14項「SOAPクライアントによるアクセス用にADF Webサービスを保護する方法」で説明しているように、セキュリティ・ポリシーを追加します。
次の種類のファイルが生成され、アプリケーション・ナビゲータの「プロジェクト」パネルで、アプリケーション・モジュールのserviceinterfaceノードの下に表示されます(図11-4を参照)。
リモート共通インタフェース(StoreFrontService.java
など)
リモート・サービス・スキーマ・ファイル(StoreFrontService.xsd
など)
リモート・サービス定義ファイル(StoreFrontService.wsdl
など)
リモート・サーバー・クラス(StoreFrontServiceImpl.java
など)
さらに、ADF Business Componentsサービスを初めて作成すると、connections.xml
ファイルが作成されます。このファイルは、Webサービス・クライアント(コンシューミング・アプリケーション)のみで使用されますが、便宜的にサービス対応アプリケーションも一緒に生成されます。このファイルは、アプリケーション・ナビゲータの「アプリケーション・リソース」パネルで、DescriptorsおよびADF META-INFノードの下に表示されます。
リモート共通インタフェースはWebサービス仕様(JSR-181)で指定されたメタデータの注釈を使用して、インタフェースをWebサービスとして公開する方法を指定します。この例は、Fusion Order DemoのStoreFrontモジュールの、StoreServiceAM
アプリケーション・モジュールのリモート共通インタフェースであるStoreFrontService.java
の一部を示しています。
例11-1 Fusion Order Demoのリモート共通インタフェース
package oracle.fodemo.storefront.store.service.common.serviceinterface; ... import javax.jws.WebMethod; import javax.jws.WebParam; import javax.jws.WebResult; import javax.jws.soap.SOAPBinding; ... import oracle.fodemo.storefront.store.queries.common.CustomerInfoVOSDO; import oracle.fodemo.storefront.store.queries.common.OrderInfoVOSDO; ... import oracle.webservices.annotations.PortableWebService; import oracle.webservices.annotations.SDODatabinding; ... @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.WRAPPED, style=SOAPBinding.Style.DOCUMENT) @PortableWebService(targetNamespace="http://www.globalcompany.com/StoreFrontService", name="StoreFrontService", wsdlLocation= "oracle/fodemo/storefront/store/service/common/serviceinteface/StoreFrontService.wsdl") @SDODatabinding(schemaLocation= "oracle/fodemo/storefront/store/service/common/serviceinteface/StoreFrontService.xsd") public interface StoreFrontService { public static final String NAME = ("http://www.globalcompany.com/StoreFrontService") /** * @param orderId * @return * @throws ServiceException */ @WebMethod(action="www.globalcompany.example.com/getOrderInfoVOSDO", operationName="getOrderInfoVOSDO") @RequestWrapper(targetNamespace="www.globalcompany.example.com/types/", localName="getOrderInfoVOSDO") @ResponseWrapper(targetNamespace="www.globalcompany.example.com/types/", localName="getOrderInfoVOSDOResponse") @WebResult(name="result") OrderInfoVOSDO getOrderInfoVOSDO(@WebParam(mode = WebParam.Mode.IN, name="orderId") BigInteger orderId) throws ServiceException; ... }
リモート・サービス・スキーマ・ファイルはWebサービス・スキーマを示すXMLスキーマ・ファイルです(図11-5を参照)。
リモート・サービス定義ファイルは、Web Service Definition Language (WSDL)仕様に準拠したXML構造化ドキュメント・ファイルで、生成されたWebサービスをエンドポイント、すなわちポートの集合として記述します。ポートは、ネットワーク・アドレスを再利用可能なバインドに関連付けることで定義されます。Webサービスに接続したクライアント・アプリケーションはWSDLを読み取り、サーバー上で提供されている機能を判断します。WSDLはサービス自体のエンドポイントも指定しており、デプロイ済のサービスの検索およびテストに使用できます。
図11-6は、WSDLビジュアル・エディタ内でStoreServiceAM
アプリケーション・モジュール用に生成されたWebサービス用のWSDLを示しています。「ソース」タブを選択すると、WSDLをXMLドキュメントとして表示できます。
リモート・サーバー・クラスはEJB 3.0のステートレス・セッションBeanで、リモート共通インタフェースを実装し、ADF Business Componentsの汎用サービス・エンジンであるServiceImpl
クラスを拡張します。例11-2は、Fusion Order DemoのStoreFrontモジュール内にある、StoreServiceAM
アプリケーション・モジュールのリモート・サーバー・クラス、StoreFrontServiceImpl.java
の一部を示しています。
例11-2 リモート・サーバー・クラスによるリモート共通インタフェースの実装
package oracle.fodemo.storefront.store.service.server.serviceinteface; ... import oracle.fodemo.storefront.store.queries.common.CustomerInfoVOSDO; import oracle.fodemo.storefront.store.queries.common.OrderInfoVOSDO; import oracle.fodemo.storefront.store.service.common.serviceinterface.StoreFrontService; ... import oracle.webservices.annotations.PortableWebService; import weblogic.javaee.CallByReference; ... @Stateless(name="oracle.fodemo.storefront.store.service.common.StoreFrontServiceBean") @Remote(StoreFrontService.class) @PortableWebService(targetNamespace="http://www.globalcompany.com/StoreFrontService", serviceName="StoreFrontService", portName="StoreFrontServiceSoapHttpPort", endpointInterface="oracle.fodemo.storefront.service.common.serviceinteface.StoreFrontService") @CallByReference public class StoreFrontServiceImpl extends ServiceImpl implements StoreFrontService { ... /** * findCustomerInfoVO1: generated method. Do not modify. * @param findCriteria * @param findControl * @return * @throws ServiceException */ public List<CustomerInfoVOSDO> findCustomerInfoVO1(FindCriteria findCriteria, FindControl findControl) throws ServiceException { return (List<CustomerInfoVOSDO>)find(findCriteria, findControl, "CustomerInfoVO1", CustomerInfoVOSDO.class); } ... }
connections.xml
ファイルは、Webサービス・クライアントにより、サービスの検索に使用されます。ADF Business Componentsサービス・ファクトリは、サービス・クライアントによるサービス検索を可能にするメカニズムです。サービス・ファクトリでは、ADF接続アーキテクチャとconnections.xml
ファイルによって、サービス・エンドポイントの場所を管理します。ADF Business Componentsサービスを初めて作成すると、connections.xml
ファイルが作成されます。このファイルは、アプリケーション・ナビゲータの「アプリケーション・リソース」パネルで、DescriptorsおよびADF META-INFノードの下に表示されます。
例11-3は、ADF Business Componentsサービスを初めて作成した際にJDeveloperによって作成される、最初のconnections.xml
エントリを示しています。
例11-3 JDeveloperが生成するconnections.xmlファイル
<Reference name="{http://www.globalcompany.com}StoreFrontService" className="oracle.jbo.client.svc.Service" xmlns=""> <Factory className="oracle.jbo.client.svc.ServiceFactory"/> <RefAddresses> <StringRefAddr addrType="serviceInterfaceName"> <Contents>oracle.fodemo.storefront.store.service.common.serviceinterface. StoreFrontService</Contents> </StringRefAddr> <StringRefAddr addrType="serviceEndpointProvider"> <Contents>ADFBC</Contents> </StringRefAddr> <StringRefAddr addrType="jndiName"> <Contents>oracle.fodemo.storefront.store.service.common. StoreFrontServiceBean</Contents> </StringRefAddr> <StringRefAddr addrType="serviceSchemaName"> <Contents>StoreFrontService.xsd</Contents> </StringRefAddr> <StringRefAddr addrType="serviceSchemaLocation"> <Contents>oracle/fodemo/storefront/store/service/common/ serviceinterface/</Contents> </StringRefAddr> </RefAddresses> </Reference>
アプリケーション・モジュールに対して、クライアント・インタフェースとサービス・インタフェースという2種類のインタフェースを定義できます。クライアント・インタフェースは、ADF ModelがUIクライアント用に使用します。サービス・インタフェースはアプリケーションの統合用で、外部のWebサービスまたはその他のアプリケーション・サービスによって使用されます(プログラミングによって、またはサービス対応エンティティ機能を使用して自動的に)。
アプリケーション・モジュールではインタフェースをまったくサポートしないことも、クライアント・インタフェースまたはサービス・インタフェースのいずれかだけをサポートすることも、両方を組み合せてサポートすることもできます。ただし、それぞれのインタフェース用に定義するカスタム・メソッドのパラメータや戻り値としてサポートされているデータ型は、2種類のインタフェースで異なっている点に注意してください。クライアント・インタフェースでサポートされている型の詳細は、9.9.5項「サービス・インタフェース上のメソッド・シグネチャについて」を参照してください。
サービス・インタフェースは、クライアント・インタフェースよりも限定的なカスタム・メソッド・パラメータと戻り値をサポートしています(次に限定されている)。
Javaプリミティブ・タイプとそのオブジェクト・ラッパー型(int
、Integer
、Long
など)
java.lang.String
java.math.BigDecimal
java.math.BigInteger
java.sql.Date
java.sql.Time
java.sql.Timestamp
java.util.Date
oracle.jbo.AttributeList
oracle.jbo.domain.BlobDomain
oracle.jbo.domain.Char
oracle.jbo.domain.ClobDomain
oracle.jbo.domain.DBSequence
oracle.jbo.domain.Date
oracle.jbo.domain.NClobDomain
oracle.jbo.domain.Number
oracle.jbo.domain.Timestamp
oracle.jbo.domain.TimestampLTZ
oracle.jbo.domain.TimestampTZ
oracle.jbo.server.ViewRowImpl
または任意のサブタイプ
java.util.List<
aType
>
(aType
は、Javaプリミティブ・タイプなど、サービス・インタフェースでサポートされている任意のデータ型)
注意: サービス・インタフェースは特にJava Map
コレクションをサポートしていません。つまり、型の異なるオブジェクトのコレクションを返すことはできません。ただし、コレクションはビュー行属性には限定されません。戻り型は、サービス・インタフェースでサポートされている任意のデータ型のリストとして定義できます。たとえば、List<DataObject>
、List<AttributeList>
およびList<String>
はすべて有効な型です。
クライアント開発者がサービス対応エンティティ・オブジェクトまたはビュー・オブジェクトの属性リストを使用して、カスタム操作を実行することで、カスタム・メソッドの実行前にフレームワークを使用しなくてもよくする場合は、AttributeList
の型を戻すカスタム・メソッドを定義できます。あるいは、クライアント開発者がフレームワークを使用して行を管理(作成、検索および移入)する場合は、かわりにViewRowImpl
を戻すカスタム・メソッドを定義します。したがって、メソッド・シグネチャでデータ型としてViewRowImpl
が定義されている場合は、アプリケーションは自動的に次を行います。
主キー、代替キーのいずれかまたは両方で、対応するビュー・オブジェクト・インスタンス内の行を検索
行が検出されない場合は、新しい行を作成
検出された行または新規行に属性の変更を適用
メソッド・シグネチャでAttributeList
のデータ型が定義されている場合は自動動作は行われず、カスタム・メソッドで実行されるアクションおよび変更されるデータは、カスタム・メソッドのコードに限定されます。
アプリケーション・モジュール用の概要エディタを使用してWebサービス・インタフェースを有効にすることで、JDeveloperは親のビュー・インスタンス選択をService Data Object (SDO)コンポーネントとして自動的に有効化します。各ビュー・インスタンス用に生成されたSDOコンポーネントは同じネームスペースを参照し、警告のサポートの有無など、同じオプション設定で構成されます。概要エディタの「Java」ページを使用して、既存のサービス対応ビュー・オブジェクトのSDO定義をカスタマイズできます。「Java」ページを使用して、サービス・インタフェースにまだ追加されていなかったビュー・オブジェクトをサービス対応にすることもできます。たとえば、マスター/ディテール関係でマスターとなる親ビュー・オブジェクトを選択しても、子ビュー・オブジェクトは自動的にサービス対応となりません。子ビュー・オブジェクトの概要エディタで「Java」ページを使用して、サービス・インタフェースに個別に追加できます。
ビュー・オブジェクトの概要エディタで「Java」ページを使用して、ビュー・オブジェクトのSDO名とネームスペースを構成するか、子ビュー・オブジェクトを個別に選択してサービス対応にします。
始める前に:
SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
次のタスクを完了します。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。
オプションでJDeveloperプリファレンスを設定して、生成されるSDOクラス名のデフォルト接尾辞の指定、および生成されるSDOスキーマとWebサービスのデフォルトのネームスペース接頭辞の設定を行います。11.2.13項「ADF Webサービス・インタフェース生成用プリファレンスの設定方法」を参照してください。
ビュー・オブジェクトのSDO名とネームスペースを設定する手順:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「Java」ナビゲーション・タブをクリックし、「Javaオプションの編集」ボタンをクリックします。
「Javaオプションの選択」ダイアログの「サービス・データ・オブジェクト」セクションで、「サービス・データ・オブジェクト・クラスの生成」を選択します。サービス・オブジェクト名と、サービス・データ・オブジェクトのターゲット・ネームスペースの値を入力します。
ターゲット・ネームスペースは、SDOコンポーネントのURIです。同じURIを入力して類似のSDOコンポーネントをグループ化する場合に割り当てることができます。
SDOコンポーネントのパッケージ名を基に、ピリオドを「/」に置き換えたデフォルトのSDOネームスペースが作成されます。「プリファレンス」ダイアログの「ビュー・オブジェクト」ページで、ネームスペースの接頭辞を定義している場合は、実行時に、その接頭辞がネームスペースの冒頭に追加されます。たとえば、図11-7はパッケージ名に基づくデフォルト・ネームスペースを示しています。
サービス・インタフェース・オブジェクトのビュー行に関連する警告を抽出できるようにするには、「警告のサポート」を選択します。
たとえば、ビュー・オブジェクトに、Salary
属性に対して定義された範囲バリデータがあり、このバリデータの失敗処理が情報警告として指定されているとします。
「警告のサポート」が選択されていない場合、サービス・レスポンスとともに情報メッセージは返されません。
警告が有効になっており、基礎となるADFビジネス・コンポーネント・オブジェクトから標準のサービス操作またはカスタム操作のいずれかに警告が生成された場合は、レスポンス・オブジェクトによって警告情報が取得されます。11.2.7.4項「SDO結果クラスとインタフェースで実装されるコンテナ・オブジェクト」に記載されているように、サービス・オブジェクト結果クラスに生成されたメソッドを使用して、ビュー行からメッセージを抽出できます。
「OK」をクリックします。
ビュー・オブジェクトの概要エディタを使用して、サービス対応ビュー・オブジェクトのSDOコンポーネント定義をカスタマイズできます。デフォルトでは、サービス対応ビュー・オブジェクトはSDOプロパティとして公開されます。ビュー・オブジェクト定義をカスタマイズすることで、サービス・インタフェースから個別のSDOプロパティを除外できます。数値を定義するSDOプロパティの場合は、2つのプロパティを関連付けて、サービス・インタフェースに単一の複合型として表示させることができます。たとえば、通貨または測定単位を定義する1つのプロパティを、数値を表示する別なプロパティに関連付けることができます。現在サポートされているのは、AmountType
(通貨コード)およびMeasureType
(測定単位)の複合サービス型だけです。
アプリケーション・モジュール用の概要エディタを使用してWebサービス・インタフェースを有効にすることで、JDeveloperは親のビュー・インスタンス選択をSDOコンポーネントとして自動的に有効化します。さらに、子ビュー・オブジェクトを個別に選択してサービス対応とし、SDOコンポーネントを生成できます。デフォルトでは、生成されたSDOコンポーネントは、基本ビュー・オブジェクト定義のすべての属性をSDOプロパティとして公開します。サービス・インタフェースにSDOプロパティとして戻させたくない属性は、非表示にできます。
概要エディタの「属性」ページを使用して、サービス・インタフェースから除外するビュー・オブジェクト属性を選択します。 次に、ビュー・オブジェクトの概要エディタの「詳細」タブを使用して、選択した属性をSDOコンポーネントで非表示にします。
始める前に:
SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
次のタスクを完了する必要があります。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。
11.2.4項「個別のビュー・オブジェクトのサービス対応化の方法」に記載されている方法に従って、該当するビュー・オブジェクトをサービス対応にします。
サービス対応ビュー・オブジェクトからSDOプロパティを除外する手順:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
「属性」ページで、除外するプロパティに対応する属性を選択し、「詳細」タブをクリックして、「SDOプロパティ」の選択を解除します。
ビュー・オブジェクトをサービス対応にすると、JDeveloperは基になっているビュー・オブジェクトのデータ型に対応するXSD定義済のサービス・タイプとして、SDOプロパティを自動的に公開します。数値を定義する属性の場合は、次のいずれかの事前定義済サービス・タイプを使用して関係のあるプロパティに関連付けるように、SDOプロパティのサービス・タイプを変更できます。
AmountType
サービス・タイプは、通貨コードを定義する任意のプロパティ用です。
MeasureType
サービス・タイプは、測定単位を定義する任意のプロパティ用です。
SDOプロパティのサービス・タイプをこのいずれかの複合型に変更すると、サービス・インタフェースが2つのプロパティを一緒に関連付け、単一のXML要素として戻します。SDOコンポーネントの両方のプロパティを、基本サービス対応ビュー・オブジェクトの属性で定義しておく必要があります。
たとえば、ビュー・オブジェクトでOrderTotal
属性およびCurrencyCode
属性を定義し、対象の国での通貨コードを指定すると仮定します。デフォルトでは、サービス・インタフェースはこれらの属性をSDOプロパティとして公開し、各プロパティを個別のXML要素として戻します。
<OrderTotal>100.00</Price> <CurrencyCode>USD</CurrencyCode>
OrderTotal
プロパティの型を(XSDファイルがこのプロパティをdecimal
型として定義していると仮定)から複合型AmountType
に変更し、CurrencyCode
プロパティを関連付けた場合、サービス・インタフェースはそれらを単一のXML要素として戻します。
<OrderTotal CurrencyCode="USD">123.00</OrderTotal>
また、、9.12.1.3項「アプリケーション・モジュールでプロキシ・クラスを使用したWebサービス・メソッドのコール」で説明しているように、Webサービス・プロキシを生成すると、2つの値はクラスで1つのオブジェクトとして扱われます。
AmountType price; ... price.setValue(123.00); price.setCurrencyCode("USD");
概要エディタの「属性」ページを使用して、カスタマイズするサービス・タイプのビュー・オブジェクト属性を選択します。 概要エディタの「属性」ページから表示される「属性の編集」ダイアログを使用して、選択した属性のSDOプロパティを関連付け、事前定義済の複合サービス・タイプを選択します。
始める前に:
SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
次のタスクを完了します。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。
11.2.4項「個別のビュー・オブジェクトのサービス対応化の方法」に記載されている方法に従って、該当するビュー・オブジェクトをサービス対応にします。
サービス対応ビュー・オブジェクト内のSDOプロパティを関連付ける手順:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
「属性」ページで、他のSDOプロパティに関連付けるプロパティに対応する属性を選択します。
選択する属性は、数値型を定義する必要があります。たとえば、通貨コードを、顧客が支払った金額を表示する属性と関連付けるには、Orders
サービス対応ビュー・オブジェクトのOrderTotal
属性を選択します。
属性を選択した状態で「詳細」タブをクリックし、「XSDタイプ」ドロップダウン・リストから目的のサービス・タイプを選択します。
「XSDタイプ」ドロップダウンが有効でない場合は、属性リストに戻って数値型の属性を選択します。値が数値型ではない属性を、使用可能な複合サービス・タイプに関連付けることはできません。
SDOフレームワークは、複合サービス・タイプ、AmountType
およびMeasureType
をサポートしています。関連付けるプロパティが通貨情報を指定する場合は、AmountType
を選択します。関連するプロパティが測定単位を指定する場合は、MeasureType
を選択します。
currencyCodeまたはunitCodeドロップダウン・リストで、ビュー・オブジェクト属性を選択して複合型を定義します。
ダイアログが切り替わり、XSDタイプの選択に応じたドロップダウン・リストが表示されます。ビュー・オブジェクトが定義している任意の数値属性を選択できます。
データ・モデルで親と子のビュー・オブジェクト間のマスター/ディテール関係を定義した場合、マスター・ビュー・オブジェクトに対して有効化するサービス操作が、ディテール・ビュー・オブジェクトでは自動的に実行されない場合があります。デフォルトでは、ディテール・ビュー・オブジェクトに対するポスト操作は、マスター・ビュー・オブジェクトのプライマリ・エンティティ・オブジェクトがディテール・ビュー・オブジェクトのプライマリ・エンティティ・オブジェクトで構成されている場合にのみサポートされます。このマスター/ディテール関係は、JDeveloperで作成されるデフォルトのアソシエーション・タイプで、コンポジット・アソシエーションと呼ばれます(4.3.6項「コンポジット・アソシエーションについて」を参照)。
親とともに子の詳細をポストする、作成、マージ、更新および処理メソッドをサポートするには、次のいずれかのシナリオに従ってビュー・リンクを作成し、マスター/ディテール関係を作成しておきます。
ビュー・リンクがデフォルトのコンポジット・アソシエーションを使用しており、ディテール・ビュー・オブジェクトに対するポスト操作がデフォルトでサポートされる場合。
ビュー・リンクがアソシエーションに基づいており、アソシエーションにリンク先アクセッサが生成されており、アソシエーションにカスタム・プロパティSERVICE_PROCESS_CHILDREN=true
が定義されている場合。
ビュー・リンクはアソシエーションに基づいていないが、カスタム・プロパティSERVICE_PROCESS_CHILDREN=true
が定義されている場合。
カスタム・プロパティは、ビュー・リンクが定義された任意のビュー・オブジェクトで、コンポジット・アソシエーションを使用せずにネストされた処理をサポートできる便利な方法です。概要エディタでSERVICE_PROCESS_CHILDREN
を、ビュー・リンクまたはビュー・リンクのアソシエーション(存在する場合)のカスタム・プロパティとして定義できます。
親と一緒に子の詳細も入手する取得および検索メソッドをサポートするには、マスターおよびディテール・ビュー・オブジェクト間のビュー・リンクでリンク先アクセッサを生成しておく必要があります。リンク先アクセッサでにより、マスターから詳細なビュー・オブジェクトまでの階層が通過できます。
始める前に:
SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
ビュー・リンクまたはエンティティ・アソシエーションを使用したマスター・ディテール関係の定義方法を理解しておくと、役立つ場合があります。
ビュー・リンクの詳細は、5.6項「マスター/ディテール階層における複数表の使用」を参照してください。
アソシエーションの詳細は、4.3項「アソシエーションの作成および構成」を参照してください。
次のタスクを完了します。
該当するビュー・オブジェクトを作成し、11.2.4項「個別のビュー・オブジェクトのサービス対応化の方法」に記載されている方法で、マスター/ディテール階層の子ビュー・オブジェクトをサービス対応にします。
ビュー・リンクがアソシエーションに基づいていない場合は、概要エディタでビュー・リンクを開き、「関係」ページを表示して、そのビュー・リンクのリンク先アクセッサがあることを確認します。アクセッサを生成し、「関係」ページに表示させるには、「アクセッサの編集」ボタンをクリックし、「ビュー・リンク」ダイアログ内でリンク先アクセッサに対してビュー・オブジェクトでアクセッサを作成を選択します。
ビュー・リンクがアソシエーションに基づいている場合は、アソシエーションのリンク先のエンティティ・オブジェクトに対して、リンク先アクセッサが存在している必要があります。リンク先アクセッサを作成するには、アソシエーションの概要エディタの「関連」ページを使用します。
マスター/ディテール階層でのネスト処理のサポート手順:
マスター/ディテール階層のビュー・リンクがアソシエーションに基づいていない場合は、アプリケーション・ナビゲータで、ビュー・リンクをダブルクリックします。ビューがアソシエーションに基づいている場合は、アプリケーション・ナビゲータ内でアソシエーションをダブルクリックします。
概要エディタの「関係」ページで、ビュー・リンクの作成方法を確認できます。「属性」セクションで、リンク元とリンク先の属性名を指定します。リンクがアソシエーションに基づいている場合は、属性ハイパーリンクにアソシエーション名が含まれます。それ以外の場合は、ハイパーリンクに基本エンティティ・オブジェクトの名前が含まれます。
概要エディタで、「一般」ナビゲーション・タブをクリックします。
ビュー・リンクの概要エディタとアソシエーションに、同様の選択内容が表示されます。
「一般」ページの「カスタム・プロパティ」セクションを開き、「カスタム・プロパティの追加」アイコンをクリックして、プロパティにSERVICE_PROCESS_CHILDREN
を、プロパティ値にtrue
を入力します(図11-8を参照)。
SDOクラスを作成すると、次のファイルが生成され、アプリケーション・ナビゲータ内の所有ビュー・オブジェクトの下に表示されます。
サービス・データ・オブジェクト・インタフェース
サービス・データ・オブジェクト・クラス
サービス・データ・スキーマ・ファイル
サービス・データ・オブジェクト結果クラスとインタフェースは、「Javaオプションの選択」ダイアログで「警告のサポート」を有効化すると生成されます。
サービス対応ビュー・オブジェクト用に生成されたファイルは変更しないでください。生成されたファイルにより、ビュー・オブジェクトのSDOインタフェースに必要なメソッドが実装されます。
ビュー・オブジェクトSDOインタフェースには、SDOプロパティに対して強い型定義が行われたアクセッサが含まれています(例11-4を参照)。
ビュー・オブジェクトSDOクラスはビュー・オブジェクトSDOインタフェースを実装し、OracleによるSDO仕様の実装であるSDODataObject
クラスを拡張します。
実行時は、SDOオブジェクトのインスタンスはメモリー内の行を示します。
SDOクラスはビュー行クラスと類似しています(例11-5を参照)。
図11-9に示すようなビュー・オブジェクトSDOスキーマ・ファイルは、SDOスキーマを示すXMLスキーマ・ファイルです。
ビュー・オブジェクトSDO結果クラスは、サービス操作がビュー行のリスト(サービス・データ・オブジェクトでラップされている)およびこれらのビュー行に関連付けられた警告リストを戻せるようにする、コンテナ・オブジェクトです。具体的には、サービスの取得操作で元のオブジェクトが返され、作成、更新、マージ、検索および処理操作で元のオブジェクトのリストと情報メッセージのリストを含むラッパー・オブジェクトが、削除操作では情報メッセージのみが返されます。サービス対応ビュー・オブジェクトの「警告のサポート」オプションを有効にしている場合は、生成されたメソッド結果インタフェースを使用して警告を抽出できます。
例11-6に示すようなビュー・オブジェクトSDO結果クラスは、ビュー行クラスに類似しています。
例11-6 SDO結果クラスにおけるリストからの警告取得用メソッド定義
package oracle.fodemo.storefront.store.queries.common; import oracle.sdo.SDODataObject; public class OrderInfoVOSDOResultImpl extends oracle.jbo.common.service.types.MethodResultImpl implements OrderInfoVOResult { public static final int START_PROPERTY_INDEX = oracle.jbo.common.service.types.MethodResultImpl.END_PROPERTY_INDEX + 1; public static final int END_PROPERTY_INDEX = START_PROPERTY_INDEX + 0; public OrderInfoVOResultImpl() {} public java.util.List getValue() { return getList(START_PROPERTY_INDEX + 0); } public void setValue(java.util.List value) { set(START_PROPERTY_INDEX + 0 , value); } }
ADFサービス・インタフェース・フレームワークにより、宣言的検索操作を公開して、選択したビュー・オブジェクトによる問合せ定義を行えます。ただし、その問合せがバインド変数を使用して問合せ結果をフィルタしている場合は、バインド変数を「必須」および「更新可能」として指定する必要があります。サービス・インタフェースは必須の更新可能バインド変数を公開しないので、この種のビュー・オブジェクトに対して実行する検索操作では、結果が戻されません。
バインド変数を使用して問合せ結果をフィルタする場合は、ビュー基準を使用して、サービス・インタフェース上での検索操作として公開します。作成するビュー基準に基づくサービス・インタフェースの検索操作には、必須バインド変数を指定できます。
始める前に:
SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
また、バインド変数を使用したビュー・オブジェクト問合せのフィルタ処理方法を理解しておくと役立つ場合があります。詳細は、5.10項「バインド変数の使用」を参照してください。
次のタスクを完了します。
9.2.1項「アプリケーション・モジュールの作成方法」に記載されている方法に従って、該当するアプリケーション・モジュールを作成します。
5.11.1項「名前付きビュー基準を宣言的に作成する方法」の説明に従って、ビュー基準を作成します。「ビュー基準の編集」ダイアログで、基準項目をバインド変数として設定し、「検証」フィールドを「必須」に設定します。このような選択によって、有効な値がなければ問合せが実行されなくなります。
必須バインド変数のあるビュー基準に対して検索操作を公開する手順:
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「サービス・インタフェース」ナビゲーション・タブをクリックし、サービス・インタフェースの属性の編集アイコンをクリックします。
サービス・インタフェースを定義済の場合は、かわりに「サービス・カスタム・メソッドの編集」を選択することもできます。
「サービス・インタフェースの編集」で、ナビゲーション・リストから「サービス・ビュー・インスタンス」を選択し、名前付きのビュー基準でフィルタするビュー・オブジェクトを「選択済」リストに追加します。
検索操作を公開するには、ビュー・インスタンスを選択し、「ビュー基準の検索操作」タブをクリックし、「ビュー基準の追加」ボタンをクリックします。
「ビュー基準検索操作の構成」ダイアログで、検索操作用の名前付きビュー基準を選択します。
ダイアログには、選択したビュー基準のバインド標準が表示されます。
サービスのXML定義に示されているバインド変数名をカスタマイズする場合は、検索操作パラメータセクションで、XML名をダブルクリックして名前を編集します。
「OK」をクリックします。
ビュー基準に依存する宣言的検索操作を公開するかわりに、データ・モデル・プロジェクトのアプリケーション・モジュール実装クラス内でサービス・メソッドを定義できます。この目的で作成するクラスでは、ビジネス・サービス機能を、実装する単一メソッドにカプセル化できます。カスタム・アプリケーション・モジュールの目的の詳細は、9.7項「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」を参照してください。
例11-7は、AppModuleName
Impl.java
ファイルで実装されているカスタム検索メソッドを示します。このメソッドは、バインド変数を設定し、ビュー・オブジェクト・インスタンス問合せを行います。ビュー・オブジェクト・インスタンス上でsetNamedWhereClauseParam()
を使用して、バインド変数を設定します。問合せ実行前に、検索メソッドが前方のみモードでビュー・オブジェクトを設定し、検索メソッドが繰り返し処理するビュー行のキャッシングを行わないようにします。
例11-7 アプリケーション・モジュール実装クラスに追加された検索メソッド
public class AppModuleImpl extends ApplicationModuleImpl { public List<ViewRowImpl> findProducts(String location) { List<ViewRowImpl> result = new ArrayList<ViewRowImpl>(); ViewObjectImpl vo = getProductsView1(); vo.setNamedWhereClauseParam("TheLocation", location); vo.setForwardOnly(true); vo.executeQuery(); while (vo.hasNext()) { result.add((ViewRowImpl)vo.next()); } return result; } }
始める前に:
SDOフレームワークによって、サービス対応ビュー・オブジェクトがどのようにサポートされ、Webサービス・クライアントのデータ行アクセスやサービス操作がどのように有効化されるかについて、理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
また、バインド変数を使用したビュー・オブジェクト問合せのフィルタ処理方法を理解しておくと役立つ場合があります。詳細は、5.10項「バインド変数の使用」を参照してください。
次のタスクを完了します。
9.7.1項「アプリケーション・モジュールのカスタム・クラスの生成方法」に記載されている方法に従って、カスタム・アプリケーション・モジュール・クラスを作成します。
問合せ結果をプログラム的にフィルタし、必要なバインド変数を設定するための、カスタム検索メソッドを作成します。詳細は、5.10.5項「実行時に名前付きバインド変数を含むWHERE句を追加する方法」を参照してください。
必須バインド変数を設定する検索メソッドの公開手順:
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「サービス・インタフェース」ナビゲーション・タブをクリックし、サービス・インタフェースの属性の編集アイコンをクリックします。
サービス・インタフェースをすでに定義している場合は、「サービス・カスタム・メソッドの編集」アイコンをクリックしてもかまいません。
「サービス・インタフェースの編集」ダイアログで、ナビゲーション・リストから「サービス・ビュー・インスタンス」を選択し、定義した検索メソッドを「選択済」リストに追加します。
「OK」をクリックします。
デフォルトでは、Webサービスは同期サービス・メソッドをサポートしています。これによってクライアント・アプリケーションを強制的に起動して待機させ、レスポンスが返されるまで作業を続行できません。レスポンスがすぐに返される場合は、このWebサービスの起動方法が一般的です。しかし、リクエスト処理が遅延する場合もあるため、クライアント・アプリケーションは先に処理を続行し、後でレスポンスを処理するほうが効率的なことも少なくありません。
始める前に:
SDOフレームワークによって、サービス対応ビュー・オブジェクトがどのようにサポートされ、Webサービス・クライアントのデータ行アクセスやサービス操作がどのように有効化されるかについて、理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
また、非同期のリクエストとレスポンスを使用したWebサービスの起動について理解しておくと役立つ場合があります。詳細は、『Oracle Fusion Middleware Oracle Infrastructure Webサービス・コンセプト・ガイド』を参照してください。
次のタスクを完了します。
非同期Webサービス・メソッドの公開手順:
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「サービス・インタフェース」ナビゲーション・タブをクリックし、サービス・インタフェースの属性の編集アイコンをクリックします。
「サービス・インタフェースの編集」ダイアログの「サービス・インタフェース」ページで、「非同期Webサービス・メソッドの生成」を選択します。
「OK」をクリックします。
JDeveloperはサービスの共通インタフェースを生成し、非同期サービス操作を有効にします。例11-8に示すように、クラスの注釈@AsyncWebService
はEmpService
サービス・インタフェースを非同期と宣言し、インタフェース内の各同期メソッドに対して、サービスが同じメソッド名に「Async
」が付加された非同期メソッドを公開します。
同じインタフェース内で同期および非同期の両方のメソッドを公開することで、Webサービス・クライアント開発者は、Webサービス・プロキシによる操作(適切な名前が付いたメソッドのコール)の起動方法を決定できます。開発者は、ADF Business Componentsサービス・プロキシで直接非同期メソッドを起動してはならない点に注意してください。
この例では、EmpService
サービスが非同期操作用に有効化されているため、インタフェースはgetEmployeeAsync()
メソッドを公開して、@CallbackMethod(exclude=true)
メソッド注釈を使用してデフォルト操作をオーバーライドし、getEmployee()
メソッドを同期として宣言しています(非同期サービス内のメソッドを同期として宣言しているのは、exclude=true
の部分)。クラス注釈@AsyncWebService
がある場合は、非同期サービス・メソッドの宣言に注釈は不要です。
例11-8 非同期サービス・メソッドのあるリモート共通インタフェース
import javax.xml.ws.Action; ... import oracle.webservices.annotations.async.AsyncWebService; import oracle.webservices.annotations.async.CallbackMethod; @SOAPBinding(parameterStyle=SOAPBinding.ParameterStyle.WRAPPED, style=SOAPBinding.Style.DOCUMENT) @PortableWebService(targetNamespace="http://xmlns.example.com/apps/service/", name="EmpService", wsdlLocation="oracle/apps/service/EmpService.wsdl") @SDODatabinding(schemaLocation="oracle/apps/service/EmpService.xsd") @AsyncWebService public interface EmpService { ... @WebMethod(action="http://xmlns.example.com/apps/service/getEmployee", operationName="getEmployee") @RequestWrapper(targetNamespace="http://xmlns.example.com/apps/service/types/", localName="getEmployee") @ResponseWrapper(targetNamespace="http://xmlns.example.com/apps/service/types/", localName="getEmployeeResponse") @WebResult(name="result") @CallbackMethod(exclude=true) Emp getEmployee(@WebParam(mode = WebParam.Mode.IN, name="empno") Integer empno) throws ServiceException; @WebMethod(action="http://xmlns.example.com/apps/service/getEmployeeAsync", operationName="getEmployeeAsync") @RequestWrapper(targetNamespace="http://xmlns.example.com/apps/service/types/", localName="getEmployeeAsync") @ResponseWrapper(targetNamespace="http://xmlns.example.com/apps/service/types/", localName="getEmployeeAsyncResponse") @WebResult(name="result") @Action(input="http://xmlns.example.com/apps/service/getEmployeeAsync", output="http://xmlns.example.com/apps/service/getEmployeeAsyncResponse") Emp getEmployeeAsync(@WebParam(mode = WebParam.Mode.IN, name="empno") Integer empno); }
重複した非同期メソッドはサービス実装で同期メソッドに移譲されます(例11-9を参照)。これにより、基になっているビジネス・ロジックが、同期または非同期として宣言された操作と同一になります。
例11-9 リモート・サーバー・クラスによる非同期サービス・メソッドの実装
... import oracle.webservices.annotations.async.AsyncWebService; @Stateless(name="oracle.apps.service.EmpServiceBean", mappedName="EmpServiceBean") @Remote(EmpService.class) @PortableWebService(targetNamespace="http://xmlns.oracle.com/apps/service/", serviceName="EmpService", portName="EmpServiceSoapHttpPort", endpointInterface="oracle.apps.service.EmpService") @Interceptors(ServiceContextInterceptor.class) @AsyncWebService public class EmpServiceImpl extends ServiceImpl implements EmpService { ... /** * getEmployee: generated method. Do not modify. */ public Emp getEmployee(Integer empno) throws ServiceException { return (Emp) get(new Object[] { empno }, "Employee", Emp.class); } /** * getEmployeeAsync: generated method. Do not modify. */ public Emp getEmployeeAsync(Integer empno) throws ServiceException { return getEmployee(empno); } }
クライアントから見ると、非同期コールは一方向の2つのメッセージ交換から構成されます。図11-10のシーケンス図は、次のフローを示しています。
クライアントが非同期操作をコールします。(図中のステップ1。)
非同期サービスはリクエストを受信し、リクエストを実際には処理せずに、HTTP確認をクライアントに戻します。(図中のステップ2。)
最終的には非同期操作が完了し、サーバー側のモジュールがレスポンスをクライアント側に送信します。(図中のステップ3。)
クライアント側でレスポンスを受信するには、クライアントにサーブレットまたはWebサービスなど、なんらかのHTTPリスナーが必要です。
クライアント側で生成されたWebサービス(コールバック・サービス)が、非同期レスポンスを受信します。(図中のステップ4。)
ステップ3ではサーバー側のモジュールが、コールバック・サービスに対してクライアントのように機能するので、コールバック・クライアントと呼ばれます。
JDeveloperで生成されたサービスに対しては、追加のコントロールが可能です。生成されたSDOクラスの名前にデフォルトの接尾辞を使用して、サービス共通インタフェースおよびクラスが保存されるデフォルト・サブパッケージを変更するように、JDeveloperプリファレンスを設定できます。
SDOクラス名接尾辞の設定手順:
メイン・メニューで、「ツール」を選択し、「プリファレンス」を選択します。
「プリファレンス」ダイアログで、「ADFビジネス・コンポーネント」を開き、「クラス・ネーミング」を選択します。
「ビュー・オブジェクト」接尾辞リストに、たとえばSDO
のような、SDOの接尾辞を入力します。
生成されたサービス・インタフェースにデフォルト・サブパッケージを設定する手順:
メイン・メニューで、「ツール」を選択し、「プリファレンス」を選択します。
「プリファレンス」ダイアログで、「ADFビジネス・コンポーネント」 を展開し、「パッケージ」を選択します。
「クラスに対する関連パッケージの指定」リストで、デフォルト・パッケージ名を指定します。
サービス・インタフェース・パッケージ名を設定するには、「クライアント・インタフェース」に値を入力します。(「サービス・インタフェース」に、クライアント・インタフェースに指定したのと同じパッケージ名が表示されます)。デフォルト・パッケージ名はcommon
です。
「サービス・インタフェース」の「サービス・インタフェース・サブパッケージ」に値を入力します。デフォルトのサブパッケージ名はserviceinterface
です。
たとえば「サービス・インタフェース」にcommon
、「サービス・インタフェース・サブパッケージ」にserviceinterface
(デフォルト)を入力すると、データ・モデル・パッケージoracle.storefront.store.service
内のデータ・モデル・コンポーネントのサービス・インタフェースが、サブパッケージoracle.storefront.store.service.common.serviceinterface
に配置されます。
生成されるSDOスキーマとWebサービスのデフォルト・ネームスペース接頭辞を設定する手順:
メイン・メニューで、「ツール」を選択し、「プリファレンス」を選択します。
「プリファレンス」ダイアログで、「ADFビジネス・コンポーネント」を開き、「ビュー・オブジェクト」を選択します。
「サービス・データ・オブジェクト・ネームスペース接頭辞」の値を入力し、生成されるSDOスキーマとWebサービスの冒頭に追加されるようにします。
たとえば、ビュー・オブジェクトの作成ウィザードの「Java」ページで「サービス・データ・オブジェクト・クラスの生成」を有効にすると、サービス・データ・オブジェクトのパッケージ名にネームスペース接頭辞www.globalcompany.example.com
が追加されて、ネームスペースwww.globalcompany.example.com/oracle/fodemo/storefront/store/queries/common/
が作成されます。
実行時、Webサービス・クライアントはSOAPプロトコルを使用して、アプリケーション・モジュールのサービス対応メソッドを起動します。Oracle Web Service Manager (Oracle WSM)セキュリティ・ポリシーの構成によって、サービスの認証と認可を有効化できます。選択するセキュリティ・ポリシーでは、SOAPクライアント・コールによってSOAPヘッダーの一部として資格証明(SAMLトークン)を提供する必要があります。たとえば受信するSOAPリクエストなどに対するメッセージ保護(整合性および機密保護)を有効化するその他のポリシーも構成できます。
SOAPクライアント用にWebサービスを保護するには:
Oracle WSM認証ポリシーを構成します。
Oracle WSM許可ポリシーを構成します。
認証を有効にして、サービス・インタフェース上のサービス・メソッドへのアクセス前に、ユーザーに資格証明の提供を求めることができます。必要な認証タイプは、Oracle WSM認証ポリシー注釈を使用しているリモート・サーバー・クラスで構成します。
権限チェックを有効化し、十分な権限を持つユーザーだけに、サービス・インタフェース上のサービス・メソッド起動を許可できます。権限チェックは、このOracle WSM許可注釈を使用して、リモート・サーバー・クラスで構成します。
binding_permission_authorization_policy
このポリシーは、SOAPバインディング・レベルの認証されたサブジェクトに基づき、リクエストに対して簡単な権限ベースの認可を行います。このポリシーは、サブジェクトに操作を実行する権限があることを保証します。このポリシーは、サブジェクトが作成されている認証ポリシーの後に続ける必要があり、SOAPベースの任意のエンドポイントに添付できます。
権限チェック・ポリシーのかわりに、ロールベースのOracle WSMセキュリティ・ポリシーのいずれかを構成することもできます。
binding_authorization_denyall_policy
このポリシーは、SOAPバインディング・レベルの認証されたサブジェクトに基づき、リクエストに対して簡単なロールベースの認可を行います。このポリシーは、ロールを持つすべてのユーザーを拒否します。サブジェクトが作成されている認証ポリシーの後に続ける必要があり、SOAPベースの任意のエンドポイントに添付できます。
binding_authorization_permitall_policy
このポリシーは、SOAPバインディング・レベルの認証されたサブジェクトに基づき、リクエストに対して簡単なロールベースの認可を行います。このポリシーは、ロールを持つすべてのユーザーを許可します。サブジェクトが作成されている認証ポリシーの後に続ける必要があり、SOAPベースの任意のエンドポイントに添付できます。
許可ポリシーの詳細は、Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイドを参照してください。
ADFサービス・インタフェース・フレームワークには、EJBインターセプタであるServicePermissionCheckInterceptor
も用意されています。これは、oracle/binding_permission_authorization_policy
と同じチェックを実施し、さらにサービスに対するRMI起動にも対応します。サービスが常にSOAPを使用して起動される場合は、Oracle WSMの許可ポリシーoracle/binding_permission_authorization_policy
を添付してください。サービスがRMIを使用しても起動される場合は、EJBインターセプタServicePermissionCheckInterceptor
を添付してください。
始める前に:
SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
また、Oracle WSMでサポートされる事前定義済認証ポリシーについても理解しておくと役立つ場合があります。詳細は、Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイドを参照してください。
次のタスクを完了します。
11.2.16項「サービスへのアクセスをテスト・ユーザーに許可する方法」の説明に従って、ユーザーにサービスへのアクセスを許可します。
認証と許可を構成するには:
アプリケーション・ナビゲータでアプリケーション・モジュールを開き、serviceinterfaceノードを開いて、リモート・サーバー・クラス(AppModuleServiceImpl.javaファイル)をダブルクリックします。
Fusion Order DemoアプリケーションのStoreFrontModule
アプリケーションのStoreServiceAM
アプリケーション・モジュールから生成されるWebサービスでは、リモート・サーバー・クラスはStoreFrontServiceImpl.java
です。
リモート・サーバー・クラスのソースで、@PortableWebService
という注釈の上にカーソルを置きます。
たとえば、StoreFrontServiceImpl.java
では、サービスの注釈が次のように表示されます。
... @PortableWebService(targetNamespace="www.globalcompany.example.com", serviceName="StoreFrontService", portName="StoreFrontServiceSoapHttpPort", endpointInterface= "oracle.fodemo.storefront...common.serviceinterface.StoreFrontService") ...
プロパティ・インスペクタで、Webサービス拡張セクションを開き、Oracle WSMポリシーの「セキュリティ」フィールドの横にある参照(...)アイコンをクリックします。
「プロパティの編集」の「セキュリティ」ダイアログで、該当する認証セキュリティ・ポリシーを選択して「OK」をクリックします。
Oracle WSMがサポートしている使用可能なセキュリティ・ポリシーの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。
ソース・ファイルに戻り、新しい注釈@SecurityPolicy
が追加されたことを確認します。
リモート・サーバー・クラスに対して定義した@SecurityPolicy
という注釈は、潜在的なクライアントに対するセキュリティ要件を指定します。たとえば、ダイアログでoracle/wss11_saml_or_username_token_with_message_protection_service_policyを選択した場合は、@PortableWebService
注釈の下に、次の@SecurityPolicy
注釈と@CallbackSecurityPolicy
(非同期サービス用)が表示されます。
... @PortableWebService(targetNamespace="www.globalcompany.example.com", serviceName="StoreFrontService", portName="StoreFrontServiceSoapHttpPort", endpointInterface= "oracle.fodemo.storefront.store.service.common. serviceinterface.StoreFrontService") @SecurityPolicy( { "oracle/wss11_saml_or_username_token_with_message_protec tion_service_policy" }) @CallSecurityPolicy("oracle/wss11_saml_or_username_token_with_message_protec tion_service_policy") ...
サービスが常にSOAPを使用してのみ起動される(RMIは使用しない)場合は、次の手順に従ってOracle WSM許可ポリシーを使用する必要があります。
プロパティ・インスペクタで、Webサービス拡張セクションを開き、Oracle WSMポリシーの「セキュリティ」フィールドの横にある参照(...)ボタンをクリックします。
「プロパティの編集」の「セキュリティ」ダイアログで、認証セキュリティ・ポリシーを選択して「OK」をクリックします。
Oracle WSMがサポートしているセキュリティ・ポリシーの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。
ソース・ファイルに戻り、注釈@SecurityPolicy
の構成を確認します。
リモート・サーバー・クラスに対して定義した@SecurityPolicy
という注釈は、潜在的なクライアントに対するセキュリティ要件を指定します。この例では、注釈に権限チェック許可ポリシー(oracle/binding_permission_authorization_policy
)と認証ポリシーの両方が表示されます。
... @PortableWebService(targetNamespace="www.globalcompany.example.com", serviceName="StoreFrontService", portName="StoreFrontServiceSoapHttpPort", endpointInterface= "oracle.fodemo.storefront...common.serviceinterface.StoreFrontService") @SecurityPolicy( { "oracle/binding_permission_authorization_policy", "oracle/wss_username_token_service_policy" })
サービスがSOAPとRMIを使用して起動される場合は、次の手順に従って、ServicePermissionCheckInterceptor
のみを使用してください(Oracle WSM許可ポリシーを使用する必要はありません)。
ソース・エディタで@Interceptors
注釈にカーソルを置き、ServicePermissionCheckInterceptor.class
を追加して、実行時の権限チェックを有効にします。
... @SecurityPolicy( { "oracle/wss11_saml_or_username_token_with_message_protection_service_policy" }) @CallSecurityPolicy("oracle/wss11_saml_or_username_token_with_message_protection_service_policy") @Interceptors({ServiceContextInterceptor.class, ServicePermissionCheckInterceptor.class})
リモート・サーバー・クラス・ファイルを保存します。
ADF WebサービスはEJBとして実装され、Oracle WebLogic Server上でOracle Web ServiceのPortableWebService
としてデプロイされるので、クライアント・アプリケーションは、RMIプロトコルを使用してアプリケーション・モジュールのサービス対応メソッドを起動できます。
RMIクライアント用にWebサービスを保護するには:
JNDIコンテキスト・プロパティを構成して認証を有効にします。
権限チェックを有効にして、許可ポリシーを構成します。
始める前に:
Oracle WSMでサポートされる事前定義済許可ポリシーについて理解しておくと役立つ場合があります。詳細は、Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイドを参照してください。
RMIを使用してADF Webサービスを起動すると、共通のJAASログイン・モジュールによって認証が処理されます。ログイン・モジュールは、コール元のアプリケーションでEJBの当初のJNDIコンテキストの一部として、プリンシパルおよび資格証明を受け取ります。JNDIコンテキスト・プロパティを定義しなかった場合、ログイン・モジュールはコール元の現在のセキュリティ・コンテキストを取得しようとします。
リモートJNDIコンテキスト情報を定義した場合、次の4つのJNDIコンテキスト・プロパティをconnections.xml
ファイルに追加する必要があります。
注意: Integrated WebLogic Serverを使用してJDeveloperでサービスのテストを行う場合、サービスのデプロイ前に、 |
jndiFactoryInitial
はweblogic.jndi.WLInitialContextFactory
に設定する必要があります。
jndiProviderURL
はJNDIプロバイダのURLで、JNDIサーバーの場所を示します。URLはt3://
<hostname>
:
<server port>
という構成でなければなりません。
JDeveloperでサービスをテストし、サービスをIntegrated WebLogic Serverにデプロイする場合は、Integrated WebLogic ServerのJNDIプロバイダのURLにt3://
<hostname>
:7101を指定します。
リモートOracle WebLogic Serverにサービスをデプロイする場合は、t3://localhost:8888
のようなURLを指定します。ここでt3
はOracle WebLogicプロトコル、localhost
はリモートOracle WebLogic Serverインスタンスを実行するホスト名、8888
はポート番号です。
jndiSecurityPrincipal
は、リモートJNDIへのアクセス権のあるプリンシパル(ユーザー名)を指定します。
例11-10に示すように、サービスをJDeveloper Integrated WebLogic Serverでテストする際は、Integrated WebLogic Server上でJNDIサーバーのセキュリティが構成されていないため、このコンテキスト・プロパティは除外する必要があります。
例11-11および例11-12に示すように、サービスをスタンドアロンOracle WebLogic Serverにデプロイする際は、ユーザー名をファイルから読み取ることができます。
jndiSecurityCredentials
は、セキュリティ・プリンシパルに使用する資格証明(パスワード)を指定します。
例11-10に示すように、サービスをJDeveloper Integrated WebLogic Serverでテストする際は、Integrated WebLogic Server上でJNDIサーバーのセキュリティが構成されていないため、このコンテキスト・プロパティは除外する必要があります。
例11-11に示すように、サービスをテスト環境内のスタンドアロンOracle WebLogic Serverにデプロイする際は、JNDIプロバイダ用の資格証明をプレーン・テキストで指定できます。たとえば、Oracle WebLogic ServerのJNDIプロバイダにアクセスするための十分な権限を持つ、デフォルト管理者のユーザー名/パスワード資格証明である、weblogic
/weblogic1
を指定できます。
サービスを本番環境にデプロイする場合は、プレーン・テキストのパスワードを削除して、セキュリティの脆弱性を回避する必要があります。例11-12に示すように、connections.xml
ファイルには、パスワードを設定せずに<SecureRefAddr addrType="jndiSecurityCredentials"/>
を含む必要があります。スタンドアロンOracle WebLogic Server用のサービス・パスワードを構成するには、Oracleの資格証明ストアに暗号化されたパスワードを保存するOracle Enterprise Managerを使用する必要があります。
始める前に:
SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
認証処理用にJNDIコンテキスト・プロパティを構成する手順:
アプリケーション・ナビゲータの「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF META-INF」ノードを開き、connections.xmlをダブルクリックします。
ソース・エディタの場合は、JNDIコンテキスト・プロパティを使用してプリンシパルと資格証明を指定します。
JDeveloperのIntegrated WebLogic Serverをテストする場合は、jndiProviderURL
プロパティを指定するだけでかまいません(例11-10を参照)。
例11-10 JDeveloper Integrated WebLogic Server用のJNDIプロパティ
<References xmlns="http://xmlns.oracle.com/adf/jndi"> <Reference name="{www.globalcompany.com}StoreFrontService" className="oracle.jbo.client.svc.Service" xmlns=""> <Factory className="oracle.jbo.client.svc.ServiceFactory"/> <RefAddresses> ... <StringRefAddr addrType="jndiFactoryInitial"> <Contents>weblogic.jndi.WLInitialContextFactory</Contents> </StringRefAddr> <StringRefAddr addrType="jndiProviderURL"> <Contents>t3://a_hostname:7101</Contents> </StringRefAddr> ... </RefAddresses> </Reference> ... </References>
Oracle WebLogic Serverでのテスト用にサービスをデプロイする場合は、connections.xml
ファイルを使用してJNDIプロバイダの資格証明を指定できます。たとえば、例11-11のように、Oracle WebLogic ServerのJNDIプロバイダにアクセスするための十分な権限を持つ、デフォルト管理者のユーザー名/パスワード資格証明である、weblogic
/weblogic1
を指定できます。
例11-11 テスト環境用のJNDIプロパティ
<References xmlns="http://xmlns.oracle.com/adf/jndi"> <Reference name="{www.globalcompany.com}StoreFrontService" className="oracle.jbo.client.svc.Service" xmlns=""> <Factory className="oracle.jbo.client.svc.ServiceFactory"/> <RefAddresses> ... <StringRefAddr addrType="jndiFactoryInitial"> <Contents>weblogic.jndi.WLInitialContextFactory</Contents> </StringRefAddr> <StringRefAddr addrType="jndiProviderURL"> <Contents>t3://localhost:8888</Contents> </StringRefAddr> <StringRefAddr addrType="jndiSecurityPrincipal"> <Contents>weblogic</Contents> </StringRefAddr> <SecureRefAddr addrType="jndiSecurityCredentials"> <Contents>weblogic1</Contents> </SecureRefAddr> ... </RefAddresses> </Reference> ... </References>
本番Oracle WebLogic Serverにサービスをデプロイする場合は、connections.xml
ファイルを使用してユーザー名を指定できます。例11-12に示すように、パスワードの指定は行わないでください。
例11-12 本番環境用のJNDIプロパティ
<References xmlns="http://xmlns.oracle.com/adf/jndi"> <Reference name="{www.globalcompany.com}StoreFrontService" className="oracle.jbo.client.svc.Service" xmlns=""> <Factory className="oracle.jbo.client.svc.ServiceFactory"/> <RefAddresses> ... <StringRefAddr addrType="jndiFactoryInitial"> <Contents>weblogic.jndi.WLInitialContextFactory</Contents> </StringRefAddr> <StringRefAddr addrType="jndiProviderURL"> <Contents>t3://localhost:8888</Contents> </StringRefAddr> <StringRefAddr addrType="jndiSecurityPrincipal"> <Contents>a_username</Contents> </StringRefAddr> <SecureRefAddr addrType="jndiSecurityCredentials/"> ... </RefAddresses> </Reference> ... </References>
ファイルを保存します。
権限チェックを有効化し、十分な権限を持つユーザーのみに、サービス・インタフェース上のサービス・メソッド起動を許可できます。権限チェックを有効にするために、ADFサービス・インタフェース・フレームワークはServicePermissionCheckInterceptor
という名前のEJBインターセプタを提供しています。このEJBインターセプタにより、実行時に権限チェックが確実に実行されます。現在、インターセプタはOracle Web Services Manager (Oracle WSM)許可ポリシーbinding_permission_authorization_policy
を使用するように構成されています。
始める前に:
SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
また、Oracle WSMでサポートされるbinding_permission_authorization_policy
許可ポリシーについても理解しておくと役立つ場合があります。詳細は、Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイドを参照してください。
次のタスクを完了します。
11.2.15.1項「RMIクライアント認証の有効化」の説明に従って、クライアント・アプリケーション(サービスを起動するアプリケーション)のconnections.xml
ファイルで、サービスの認証ポリシーを構成します。
11.2.16項「サービスへのアクセスをテスト・ユーザーに許可する方法」の説明に従って、ユーザーにサービスへのアクセスを許可します。
権限ベースの許可ポリシーの構成手順:
アプリケーション・ナビゲータでWebサービス・プロジェクトのMETA-INFノードを開き、ejb-jar.xmlノードをダブルクリックします。
ソース・エディタで、アプリケーションのロール評価のためのEJBに必要な、次のJpsInterceptor
定義を追加します。
<?xml version = '1.0' encoding = 'windows-1252'?>
<ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/j2ee/ejb-jar_3_0.xsd" version="3.0"
xmlns="http://java.sun.com/xml/ns/javaee">
<enterprise-beans>
...
</enterprise-beans>
<interceptors>
<interceptor>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor
</interceptor-class>
<env-entry>
<env-entry-name>application.name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>ApplicationName</env-entry-value>
<injection-target>
<injection-target-class>
oracle.security.jps.ee.ejb.JpsInterceptor
</injection-target-class>
<injection-target-name>
application_name
</injection-target-name>
</injection-target>
</env-entry>
</interceptor>
...
<interceptors>
<assembly-descriptor>
<interceptor-binding>
<ejb-name>*</ejb-name>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor
</interceptor-class>
</interceptor-binding>
</assembly-descriptor>
</ejb-jar>
アプリケーション・ナビゲータでアプリケーション・モジュールを開き、serviceinterfaceノードを開いて、リモート・サーバー・クラス(AppModuleServiceImpl.java)ノードをダブルクリックします。
ソース・エディタで注釈セクションの最後にカーソルを配置し、ServicePermissionCheckInterceptor
という名前の注釈を追加して、実行時の権限チェックを有効にします。
... @Stateless(name="oracle.fodemo.storefront.store.service.common. StoreFrontServiceBean") @Remote(StoreFrontService.class) @PortableWebService(targetNamespace="http://www.globalcompany.com/ StoreFrontService", serviceName="StoreFrontService", portName="StoreFrontServiceSoapHttpPort", endpointInterface="oracle.fodemo.storefront. service.common.serviceinteface.StoreFrontService") @CallByReference @Interceptors({ServiceContextInterceptor.class, ServicePermissionCheckInterceptor.class})
ファイルを保存します。
サービスの許可ポリシーを構成後、Oracle Platform Security Services (OPSS)セキュリティ・プロバイダを構成して、サービスにメソッドを起動できるユーザーを指定する必要があります。設計時にjazn-data.xml
構成ファイルを編集して、アプリケーション・ロールの作成と該当するアプリケーション・ロールへの起動権限許可を行うことでこのタスクを実行します。その後サービスをデプロイする際には、ターゲットOracle WebLogic Serverの管理者が、指定したアプリケーション・ロールをエンタープライズ・ユーザーに関連付けます。これによって、サービス・メソッドの起動権利を、そのアプリケーション・ロールのメンバーである任意のユーザーに付与できます。起動権限が付与されていないロール・メンバーであるユーザーは、サービス・メソッドへのアクセスを拒否されます。
Oracle Web Servicesの起動権限は、oracle.wsm.security.WSFunctionPermission
クラスで定義されています。サービスの全メソッドまたは個別のメソッドに対して、定義するアプリケーション・ロールの権限を付与できます。
始める前に:
SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
また、アプリケーション・ロールとOPSSセキュリティ・プロバイダについても理解しておくと役立つ場合があります。詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
次のタスクを完了します。
11.2.14項「SOAPクライアントによるアクセス用にADF Webサービスを保護する方法」または11.2.15項「RMIクライアントによるアクセス用にADF Webサービスを保護する方法」の説明に従って、サービスの認証および許可ポリシーを構成します。
jazn-data.xml
デプロイメント・ディスクリプタを作成して、OPSSセキュリティ・プロバイダ構成ファイルをプロジェクトに追加します。デプロイメント・ディスクリプタの詳細は、『Oracle Fusion Middleware Oracle JDeveloperユーザーズ・ガイド』の「アプリケーションのデプロイ」を参照してください。
JDeveloper内の「新規ギャラリ」を開いて「一般」を展開し、「デプロイメント・ディスクリプタ」→「Oracleデプロイメント・ディスクリプタ」を選択して、「OK」をクリックします。
35.4項「アプリケーション・ロールの作成」の説明に従って、付与対象のアプリケーション・ロールを作成します。
JDeveloperで統合WebLogic Serverを使用してWebサービスをテストするために、35.6項「テスト・ユーザーの作成」の説明に従って、アプリケーション・ロールにテスト・ユーザーを追加できます。
jazn-data.xmlファイルでアプリケーション・ロールへのWebサービス権限を付与する手順:
「アプリケーション」メニューで、「保護」→「リソース権限」または「保護」→「資格付与」を選択します。
複数の権限を資格セットとしてアプリケーション・ロールに付与したり、リソースに対して個々の権限を付与できます。資格付与を作成するには、特定のエンド・ユーザー職務を保護する複数の権限を集約する場合です。資格付与の詳細は、35.5.12項「リソース権限を資格付与として集約する方法」を参照してください。
jazn-data.xml
ファイルのエディタ・ウィンドウで「ソース」タブをクリックします。
jazn-data.xml
ファイルのソースで、<policy-store>
要素を展開し、アプリケーション用に定義済のすべてのADFセキュリティ・ポリシーを表示します。
現在、このリリースではアプリケーション・セキュリティ・ポリシー作成用のエディタが提供されていません。jazn-data.xml
ファイルのソースで、ポリシーを手動で作成する必要があります。
<jazn-policy>
要素内に、該当するアプリケーション・ロールを指定した<grantee>
を定義する<grant>
要素と、Oracle WSM権限クラスの完全修飾クラス名(oracle.wsm.security.WSFunctionPermission
)、サービス・メソッドを一意に識別する権限ターゲット名、およびアプリケーション・ロール・プリンシパルに付与する起動メソッド・アクションを指定した<permission>
を作成します。
完成したソースは次のようになります。
<grant> <grantee> <principals> <principal> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <name>customers</name> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.wsm.security.WSFunctionPermission</class> <name>www.globalcompany.example.com/ StoreFrontService#CreateAccount</name> <actions>invoke</actions> </permission> </permissions> </grant>
<principal>
要素は、アプリケーション・ロール・クラス名oracle.security.jps.service.policystore.ApplicationRole
および作成済のアプリケーション・ロール名によって定義されます。たとえば、アプリケーション・ロールcustomers
を作成済で、そのロールのメンバーに起動サービス・メソッドの権限を付与する場合は、customers
と入力します。
<permission>
要素は、Oracle WSMクラス名oracle.wsm.security.WSFunctionPermission
および権限ターゲット名によって定義されます。権限ターゲット名は、/
serviceInterfaceName
および#
serviceMethodName
(またはワイルドカード文字)をサービス・ターゲット・ネームスペースに付加して作成します。
ヒント: ターゲット・ネームスペースとサービス名は、サービスのWSDL定義ファイルで検索できます。アプリケーション・ナビゲータでserviceinterfaceノードの下のWSDLファイルをダブルクリックし、 |
たとえば、Fusion Order Demo内のWSDL定義ファイルでは、次の名前とネームスペースが定義されています。
<wsdl:definitions name="StoreFrontService" targetNamespace="www.globalcompany.example.com"
サービス・インタフェース上で、これらのFusion Order Demo名とネームスペースを使用して、許可されたユーザーにCreateAccount
サービス・メソッドの起動権限を付与する場合、次のようなターゲット名を入力します。
www.globalcompany.example.com/StoreFrontService#CreateAccount
あるいはワイルドカード*を使用してターゲット名を入力し、1つの権限でサービス・インタフェースのすべての操作を許可することもできます。
www.globalcompany.example.com/StoreFrontService#*
入力可能なアクションは権限クラスによって定義されています。この場合、oracle.wsm.security.WSFunctionPermission
は単一のアクションであるinvoke
を定義します。
jazn-data.xml
ファイルに変更を保存します。
ADFサービス・インタフェースは、Message Transmission Optimization Mechanism (MTOM)を使用して、BlobDomain
/ClobDomain
属性のViewRow
に対して機能するサービス・メソッドでのバイナリ・データ送信処理をサポートしています。これによって、保険金請求書類に画像が必要な場合など、バイナリ・データにXMLメッセージを添付できます。サービス対応アプリケーション・モジュールのSDOデータ・オブジェクトは、BlobDomain
/ClobDomain
をjavax.activation.DataHandler
にマップします。SOAPプロトコルを使用してWebサービスをコールする際、SDOデータ・オブジェクトのマーシャリング/アンマーシャリング中に、これらのDataHandler
プロパティを添付データとして渡すことができます。
SOAPプロトコルのMTOMサポートを有効化するには、@MTOM
という注釈をサービス・インタフェース実装クラス(たとえばStoreFrontServiceImpl.java
)に追加し、また、BlobDomain
/ClobDomain
属性を持つViewRow
に対してメソッドが機能する必要があります。
始める前に:
SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
バイナリ・データ添付の送信サポートを有効化する手順:
アプリケーション・ナビゲータでアプリケーション・モジュールを開き、serviceinterfaceノードを開いて、リモート・サーバー・クラス(AppModuleServiceImpl.java)ファイルをダブルクリックします。
Fusion Order DemoのStoreFrontModule
アプリケーションのStoreServiceAM
アプリケーション・モジュールから生成されるWebサービスでは、リモート・サーバー・クラスはStoreFrontServiceImpl.java
です。
リモート・サーバー・クラスのソースで、注釈セクションの任意の場所にカーソルを置きます。
たとえば、StoreFrontServiceImpl.java
では、サービスの注釈セクションは次のようになります。
... @Stateless(name="oracle.fodemo.storefront....common.StoreFrontServiceBean", mappedName="StoreFrontServiceBean") @Remote(StoreFrontService.class) @PortableWebService(targetNamespace="www.globalcompany.example.com", serviceName="StoreFrontService", portName="StoreFrontServiceSoapHttpPort", endpointInterface= "oracle.fodemo.storefront...common.serviceinterface.StoreFrontService") ...
プロパティ・インスペクタで、「Webサービス」セクションを開き、「MTOMの有効化」を選択します。
JDeveloperが注釈@MTOM
を、ファイルの注釈セクションに追加します。
... @Stateless(name="oracle.fodemo.storefront....common.StoreFrontServiceBean", mappedName="StoreFrontServiceBean") @Remote(StoreFrontService.class) @PortableWebService(targetNamespace="www.globalcompany.example.com", serviceName="StoreFrontService", portName="StoreFrontServiceSoapHttpPort", endpointInterface= "oracle.fodemo.storefront...common.serviceinterface.StoreFrontService") @MTOM ...
Integrated WebLogic Serverを使用して、JDeveloperでWebサービスを実行できます。Oracle WebLogic ServerにWebサービスをデプロイして、サービスをテストすることもできます。
Integrated WebLogic Serverを使用した実行とテストの手順:
アプリケーション・ナビゲータでアプリケーション・モジュールを開き、serviceinterfaceノードを開いて、リモート・サーバー・クラス(AppModuleServiceImpl.java)ファイルを選択します。
Fusion Order DemoのStoreFrontModule
アプリケーションのStoreServiceAM
アプリケーション・モジュールから生成されるWebサービスでは、リモート・サーバー・クラスはStoreFrontServiceImpl.java
です。
リモート・サーバー・クラス・ファイルを右クリックして、「実行」または「デバッグ」を選択します。
アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの構成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。
JDeveloperがサーバー・インスタンスを初期化し、アプリケーションをデプロイしてWebサービスを開始します。この間、これらプロセスからの出力が「ログ」ウィンドウの「実行中」タブに表示されます。Webサービスの開始後、ターゲットURLも「ログ」ウィンドウに表示されます。
ヒント: 「ログ」ウィンドウでターゲットURLリンクをクリックすると、HTTPアナライザを起動できます。これは、JDeveloperと統合されたWebLogic Serverでテストを実行する場合のショートカットとして便利です。HTTPアナライザの詳細は、『Oracle Fusion Middleware Oracle JDeveloperユーザーズ・ガイド』の「アプリケーションの監査およびプロファイリング」を参照してください。 |
「ログ」ウィンドウからターゲットURL(http://
で始まる)をコピーします。
「ログ」ウィンドウにはたとえば次が表示されます。
http://<
ipaddress
>/ADFServiceDemo-ADFModel-context-root
統合WebLogic Serverにより、サービス・エンドポイントのURLが表示されます。そのため、サービス名を追加する必要はありません。
Webブラウザを起動し、「ログ」ウィンドウからコピーしたターゲットURLをブラウザのアドレス・フィールドにペーストして、HTTPリクエストを送信します。
テスト・ページで、起動する操作を「操作」ドロップダウン・リストから選択し、パラメータ・フィールドにサンプル・データを入力します。
準備ができたら、「起動」を押して操作を発行し、「テスト結果」ページで操作結果を確認します。
「テスト結果」ページには、操作で戻された情報のXML Soap形式が表示されます。
Webサービスをテストすると、一部のカスタム・メソッドがJava Transaction API (JTA)で設定されたタイムアウト制限を超えていることに気付く場合があります。JTAタイムアウト設定では、サービス・メソッドの実行制限時間をデフォルトでは30秒以内に設定しています。Oracle WebLogic Server管理コンソールを使用して、JTAタイムアウト設定を延長できます。それでもタイムアウト例外を受信する場合や、サービス・インタフェースのカスタム・メソッドの実行に長時間かかることが予想される場合は、ステートレス・セッションBean用のEJBトランザクション属性を指定して、EJBがJTAトランザクションでこれらのメソッドを実行しないようにします。
カスタム・メソッドをタイムアウト制限から除外するには、そのメソッドのプロパティ・インスペクタでTransactionAttributeType.NOT_SUPPORTED
を設定します。JDeveloperは注釈@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
を追加して、メソッドを更新します。
例11-13 カスタム・サービス・メソッドのNOT_SUPPORTED注釈
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) public void updateCustomerInterests(List<String> pCategoryIds) throws ServiceException { invokeCustom((Method) _map.get("updateCustomerInterests"), new Object[] { pCategoryIds }, new String[] { null }, false); }
このトランザクション属性が設定されたメソッドはJTAトランザクションでは実行されないため、oracle.jbo.ApplicationModule
and oracle.jbo.Transaction
インタフェースのADF Business Componentsメソッドを使用して各自でトランザクションの制御を行う必要があります。たとえば、例11-14に示すように、サービス対応にしたアプリケーション・モジュールの実装クラスのメソッドでは、am.getDBTransaction().commit()
またはrollback()
をコールして、トランザクションを完了する必要があります。
例11-14 実装メソッドでトランザクションの実行を処理するカスタム・コード
public void updateCustomerInterests(List pCategoryIds) { try { if (pCategoryIds != null && pCategoryIds.size() > 0) { List<Integer> copyOfCategoryIds = (List<Integer>) this.cloneList(pCategoryIds); ViewObject selectedCategories = this.getSelectedCategoriesShuttleList(); RowSetIterator rsi = selectedCategories.createRowSetIterator(null); // remove rows for the current user not in the list of product keys while (rsi.hasNext()) { Row r = rsi.next(); Number interestId = (Number)r.getAttribute("CategoryId"); // existing row is in the list, we're ok, so remove from list. if (copyOfCategoryIds.contains(interestId)) { copyOfCategoryIds.remove(interestId); } // if the existing row is in not list, remove it. else { r.remove(); } } rsi.closeRowSetIterator(); // at this point, add new rows for the keys that are left for (int i =0 ;i < copyOfCategoryIds.size(); i++ ) { Row newRow = selectedCategories.createRow(); selectedCategories.insertRow(newRow); newRow.setAttribute("CategoryId", (String) copyOfCategoryIds.get(i).toString()); } this.getTransaction().commit(); } } catch (JboException e) { this.getTransaction().rollback(); throw e; } }
サービス・インタフェース用に生成した標準サービス・メソッドのデフォルト・トランザクション属性設定は、変更しないでください(表11-1を参照)。標準メソッドは、JTAトランザクション用に設定されたデフォルト実行境界内で実行されます。
始める前に:
SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
カスタム・メソッドがJTAトランザクションで実行されないようにする手順:
アプリケーション・ナビゲータでアプリケーション・モジュールを開き、serviceinterfaceノードを開いて、リモート・サーバー・クラス(AppModuleServiceImpl.java)ファイルをダブルクリックします。
Fusion Order DemoのStoreFrontModule
アプリケーションのStoreServiceAM
アプリケーション・モジュールから生成されるWebサービスでは、リモート・サーバー・クラスはStoreFrontServiceImpl.java
です。
ソース・エディタで、タイムアウトさせたくないカスタム・メソッドを検索して、そのメソッド上にカーソルを置きます。
プロパティ・インスペクタで「ステートレス・セッションBean」を開き、「TransactionAttribute」ドロップダウン・リストから「TransactionAttributeType.NOT_SUPPORTED」を選択します。
例11-13のupdateCustomerInterests()
に示すように、JDeveloperによって、カスタム・サービス・メソッドが注釈付きで更新されます。
リモート・サーバー・クラスを保存します。
アプリケーション・ナビゲータで、アプリケーション・モジュール実装クラス(AppModule
Impl.java
)のファイルをダブルクリックします。
この実装クラスはサービス・インタフェースで公開されるカスタム・メソッドを定義します。Fusion Order Demoアプリケーションでは、アプリケーション・モジュール実装クラスはStoreServiceAMImpl.java
です。
ソース・エディタで、TransactionAttributeプロパティを設定したサービス・メソッドを実装するカスタム・メソッドに、トランザクションのコミットとロールバックを行うカスタム・コードを追加します。
例11-14に示すように、updateCustomerInterests()
という名前のサービス・メソッドにTransactionAttributeプロパティを構成した場合、アプリケーション・モジュールの実装クラスを開き、カスタム・メソッドupdateCustomerInterests()
を検索して、am.getDBTransaction().commit()
およびrollback()
をメソッドのtry
およびcatch
文に追加します。
アプリケーション・モジュール実装クラスを保存します。
たとえば、サービスのテストの第2段階を実行するために、Oracle WebLogic ServerにWebサービスをデプロイすることができます。
始める前に:
プロジェクトに標準Webサービス(@WebService
注釈付きのJavaクラスまたはJavaインタフェース)が含まれている場合は、Business ComponentsのWebサービスをデプロイする前に、該当Javaクラスから@WebService
注釈を削除する必要があります。標準Webサービスと同じプロジェクトに属するBusiness ComponentsのWebサービスをデプロイしようとすると、Oracle WebLogic Server例外エラーが発生してデプロイメントが失敗します。そのため、標準Webサービスは、ADF Business Componentsサービスとは別のプロジェクトに作成する必要があります。
非同期Webサービスを作成した場合は、サービスのデプロイ前に、リクエストおよびレスポンスを格納するためのキューを構成する必要があります。リクエストおよびレスポンス・キューの構成の詳細は、『Oracle Fusion Middleware Oracle Infrastructure Webサービス・コンセプト・ガイド』を参照してください。
11.2.14項「SOAPクライアントによるアクセス用にADF Webサービスを保護する方法」の説明に従ってWebサービスの認可を構成した場合は、weblogic-application.xml
ファイルを編集して、アプリケーションIDパラメータを定義します。このファイルは、アプリケーション・ナビゲータの「アプリケーション・リソース」パネルで、DescriptorsおよびMETA-INFノードの下に表示されます。
次の<application-param>
定義を最初の要素として追加します。
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/weblogic-application"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://www.bea.com/ns/weblogic/weblogic-application.xsd">
<application-param>
<param-name>jps.policystore.applicationid</param-name>
<param-value>ApplicationName</param-value>
</application-param>
...
</weblogic-application>
入力するApplicationName
は、 jazn-data.xml
ポリシー・ストア定義内の名前と一致する必要があります。
<jazn-data>
<policy-store>
<applications>
<application>
<name>ApplicationName</name>
<app-roles>
...
</app-roles>
<jazn-policy>
...
</jazn-policy>
</application>
</applications>
</policy-store>
</jazn-data>
ejb-jar.xml
ファイルを編集して、EJBでのアプリケーション・ロール評価に必要な、次のJpsInterceptor
定義を追加します。このファイルはアプリケーション・ナビゲータの、Webサービス・プロジェクトのMETA-INFノードの下にあります。
<?xml version = '1.0' encoding = 'windows-1252'?>
<ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/j2ee/ejb-jar_3_0.xsd" version="3.0"
xmlns="http://java.sun.com/xml/ns/javaee">
<enterprise-beans>
...
</enterprise-beans>
<interceptors>
<interceptor>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor
</interceptor-class>
<env-entry>
<env-entry-name>application.name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>ApplicationName</env-entry-value>
<injection-target>
<injection-target-class>
oracle.security.jps.ee.ejb.JpsInterceptor
</injection-target-class>
<injection-target-name>
application_name
</injection-target-name>
</injection-target>
</env-entry>
</interceptor>
...
<interceptors>
<assembly-descriptor>
<interceptor-binding>
<ejb-name>*</ejb-name>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor
</interceptor-class>
</interceptor-binding>
</assembly-descriptor>
</ejb-jar>
ApplicationName
も、jazn-data.xml
ポリシー・ストア定義内のアプリケーション名と一致する必要がある点に注意してください。
Oracle WebLogic Serverへのデプロイ手順:
Oracle WebLogic Serverにアプリケーション・サーバーの接続を作成する手順:
メイン・メニューで、「表示」を選択し、「アプリケーション・サーバー・ナビゲータ」を選択します。
アプリケーション・サーバー・ナビゲータで、「アプリケーション・サーバー」ノードを右クリックし、「新規アプリケーション・サーバー」を選択して、アプリケーション・サーバー接続の作成ウィザードを完了します。
サービス・デプロイメント・プロファイルの作成:
アプリケーション・ナビゲータで、Webサービスが含まれるプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログの「デプロイメント」ページを開き、 「新規」をクリックします。
「デプロイメント・プロファイルの作成」ダイアログで、アーカイブ・タイプとして「ビジネス・コンポーネント・サービス・インタフェース」を選択します(図11-11を参照)。
「アプリケーション」メニューで、作成したデプロイメント・プロファイルに対して、「デプロイ」→ 「デプロイメント・プロファイル」を選択します。
デプロイ・ウィザードの「デプロイメント・アクション」ページで、「アプリケーション・サーバーへのデプロイ」を選択し、「次へ」をクリックします。
「サーバーの選択」ページで、アプリケーション・サーバー接続を選択します。
「OK」をクリックします。
ADF Business ComponentsアプリケーションはWebサービス用の組込みサポート、およびビュー・オブジェクト・データをサービス・データ・オブジェクト(SDO)として公開するための組込みサポートを提供しています。ローカル・データ・モデル・プロジェクト内で作成するエンティティ・オブジェクトは、サービス対応アプリケーション・モジュールがそのサービス・インタフェースで公開するSDOサービスを利用できます。ローカル・オブジェクト内でサービスバック・エンティティ・オブジェクトを作成することで、すべての共通リモート・サービス・データ・アクセス・タスクに対して、サービス・プロキシとSDOをプログラミングによって直接扱う必要がなくなります。
エンティティ・オブジェクトの作成ウィザードによって、11.3.1項「サービス対応エンティティ・オブジェクトおよびビュー・オブジェクトの使用方法」で説明しているように、エンティティ・オブジェクトの作成時、ローカル・データベースとADF Business Componentsサービス間での選択が簡単になります。これにより、サービス対応アプリケーション・モジュールは、データベースでローカルに提供されていないデータに別な方法でアクセスできます。
サービスバック・エンティティ・オブジェクトを作成すると、ビュー・オブジェクト、ビュー・リンクおよびビュー基準を作成して、実行時にデータをフィルタできるようになります。また、あたかもデータベース表からローカルに提供されたデータにアクセスして作業しているかのように、これらのビュー・データをデータ・モデルで活用することもできます。
次の各項では、サービス対応ADFアプリケーション・モジュールを使用して、データ・モデル・プロジェクトを強化する方法を説明します。
次のいずれかの状況が発生した場合に、アプリケーション設計戦略の一環として、サービスバック・コンポーネントを使用できます。
クライアント・データ・モデル・プロジェクトで、別なビジネス・プロセスに含まれているサービス対応アプリケーションを使用する必要がある場合。
クライアント・データ・モデル・プロジェクトで、プラガブルな外部サービスを使用する必要がある場合。
最初の場合は、サービスの両側を提供します。2番目の場合は、外部サービスが不明なことがあるので、次を行う必要があります。
サービスのFusion実装は必要ないかもしれませんが、サービス対応アプリケーション・モジュールのサービス・インタフェースがプラガブル機能のサポート単位になっており、サービスバック・エンティティ・オブジェクトおよびビュー・オブジェクト作成方法としてサポートされているので、「標準的な」プラガブル・サービスに求める形状をサービス・インタフェースに記述してアプリケーション・モジュールを作成します。
11.2.1項「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」の説明に従ってサービス対応アプリケーション・モジュールを生成した後、サービスバック・エンティティ・オブジェクトとビュー・オブジェクトを作成します。
最後にステップ2で作成した「標準的」なサービス対応アプリケーション・モジュールと同じサービス・インタフェースをサポートするEJBセッションBean(またはSCAコンポジット)を作成し、このサービス・インタフェースに基づくサービス対応ビジネス・コンポーネントを含むクライアント・プロジェクトのconnections.xml
ファイルが、この「プラグイン」バージョンを使用するように構成します。
アプリケーション・モジュールをWebサービスとして公開する方法の詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。
エンティティ・オブジェクトの作成ウィザードで、アプリケーション・サーバー上ですでに稼働しているデプロイ済サービスを記述したWSDLドキュメントのURLを指定して、サービスバック・エンティティ・オブジェクトを作成します。このウィザードはWSDLサービス記述を使用して、使用可能なサービス・ビュー・インスタンスのリストを表示します。ウィザードで、表示されたビュー・インスタンスの中から選択して、エンティティ・オブジェクトのデータ・ソースを指定します。ウィザードの実行時、WSDLドキュメントを検索するためにサービス・エンドポイントへのアクセスが可能でなければなりません。
始める前に:
クライアントのFusion WebアプリケーションでADF Business Componentsサービスにアクセスする方法について理解しておくと役立ちます。詳細は、11.3項「サービス対応アプリケーション・モジュールによるリモート・データのアクセス」を参照してください。
次のタスクを完了します。
11.2.1項「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」に記載の説明に従って、Webサービスとしてアプリケーション・モジュールを公開します。
11.2.4項「個別のビュー・オブジェクトのサービス対応化の方法」の説明に従って、必要に応じて特定のビュー・オブジェクトをサービス対応にします。
11.2.5.2項「複合データ型を使用した関連するSDOプロパティの関連付け」の説明に従って、必要に応じて、サービス対応ビュー・オブジェクトの属性に対して複合型(通貨コードまたは測定単位を含む)を定義します。
データ・ソースとしてサービス・ビュー・インスタンスを使用するエンティティ・オブジェクトを作成する手順:
アプリケーション・ナビゲータで、エンティティ・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で、「ビジネス層」ノードを展開し、「ADF Business Components」を選択します。次に「エンティティ・オブジェクト」を選択し、「OK」をクリックします。
エンティティ・オブジェクトの作成ウィザードの「名前」ページで、次の操作を実行してエンティティ・オブジェクトを作成します。
エンティティ・オブジェクトが作成されるパッケージ名を入力し、エンティティ・オブジェクト名を入力します。
「サービス・インタフェース」を、エンティティ・オブジェクト作成用のデータ・ソースとして選択します。
公開済サービスのURLのWSDLドキュメントを入力するか、「参照」をクリックし、Webサービスの検索ウィザードを使用してUDDIレジストリでリモート・サービスを検索します。
ウィザードはサービス・エンドポイントとの接続を試み、WSDLサービス記述からリストへの移入を行います。エンドポイントが使用できな場合は、リストは空のままです。
「サービス・ビュー・インスタンス」ドロップダウンから、データ・ソースとしてサービス・ビュー・インスタンスを選択します(図11-12を参照)。
「次へ」をクリックして、エンティティ・オブジェクトの属性設定を変更してから、ウィザードを終了します。
たとえば「属性の設定」ページで、エンティティの変更時には常に変更が予想される属性について、「リフレッシュ」の「挿入後」および「リフレッシュ」の「更新後」オプションを有効化できます。通常、このような値には、行内のバージョン番号列や更新日付列などがあります。
「終了」をクリックします。
サービスバック・エンティティ・オブジェクトを作成すると、ベース・サービス対応ビュー・オブジェクトのSDOプロパティにより定義されている属性が、JDeveloperによって自動的に公開されます。エンティティ・オブジェクトに複合型の属性が含まれる場合、エンティティ・オブジェクトから複合型の関連属性を選択する必要があります。たとえば、サービスバック・エンティティ・オブジェクトでOrderTotal
属性およびCurrencyCode
属性を定義し、対象の国での通貨コードを指定すると仮定します。この場合、関連属性CurrencyCode
を、サービス対応ビュー・オブジェクトにより指定されるSDOプロパティのタイプにマップする必要があります。複合型でサポートされているサービス・タイプは次のとおりです。
AmountType
サービス・タイプは、通貨コードを定義する任意のプロパティ用です。
MeasureType
サービス・タイプは、測定単位を定義する任意のプロパティ用です。
概要エディタの「属性」ページを使用して、複合型として定義されたエンティティ・オブジェクト属性を選択します。概要エディタの「属性」ページから表示される「詳細」タブを使用して、選択した属性の複合型を適切な型の関連属性にマップします。
始める前に:
クライアントのFusion WebアプリケーションでADF Business Componentsサービスにアクセスする方法について理解しておくと役立ちます。詳細は、11.3項「サービス対応アプリケーション・モジュールによるリモート・データのアクセス」を参照してください。
複合型およびSDOプロパティについて理解しておくと役立ちます。詳細は、11.2.5.2項「複合データ型を使用した関連するSDOプロパティの関連付け」を参照してください。
次のタスクを完了します。
11.2.1項「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」に記載の説明に従って、Webサービスとしてアプリケーション・モジュールを公開します。
11.2.4項「個別のビュー・オブジェクトのサービス対応化の方法」に記載されている方法に従って、該当するビュー・オブジェクトをサービス対応にします。
11.2.5.2項「複合データ型を使用した関連するSDOプロパティの関連付け」の説明に従って、サービス対応ビュー・オブジェクトの個々の属性に対して複合型を指定します。
11.3.1.1項「SDOサービスにバックアップされたエンティティ・オブジェクトの作成」の説明に従って、サービス対応ビュー・オブジェクトからサービスバック・エンティティ・オブジェクトを作成します。
サービスバック・エンティティ・オブジェクトで複合型を使用して属性を関連付けるには:
アプリケーション・ナビゲータで、サービスバック・エンティティ・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
「属性」ページで、サービス対応ビュー・オブジェクトで複合型として定義された属性をベースとする属性を選択します。
選択した属性は、サービス対応ビュー・オブジェクトのSDOプロパティにより数値型として定義されます。
属性を選択した状態で、「詳細」タブをクリックし、「サービス」セクションの「currencyCode」または「unitCode」ドロップダウン・リストで、複合型に関連付けるエンティティ・オブジェクト属性を選択します。
ドロップダウン・リストには、エンティティ・オブジェクトにより定義されているすべてのString
属性が表示されます。複合型定義に関連属性としてマッピングするために適した属性を選択します。たとえば、通貨コードを、顧客が支払った金額を表示するOrderTotal
属性と関連付けるには、Orders
サービスバック・エンティティ・オブジェクトのCurrencyCode
属性を選択します。
SDOフレームワークは、関連サービス属性値currencyCodeおよびunitCodeをサポートしています。エディタにcurrencyCodeが表示される場合には、関連付ける属性は通貨情報を指定する必要があります。エディタにunitCodeが表示される場合には、関連付ける属性は測定単位を指定する必要があります。
プロジェクトにサービスバック・エンティティ・オブジェクトを追加したら、サービスバック・ビュー・オブジェクトを作成して、ユーザー・インタフェースで使用するリモート・サービス・データの問合せが行え、オプションでフィルタもできます。サービスバック・ビュー・オブジェクトは、そのエンティティを単独で使用すると、SDOサービスでバックアップされたエンティティ・オブジェクトを参照するビュー・オブジェクトです。既存のビュー・オブジェクトをサービスバックにできません。ビュー・オブジェクトを作成する際に、エンティティをサービスバック・エンティティ・オブジェクト用に使用する場合は、新しいビュー・オブジェクトが自動的にサービスバックになります。
始める前に:
11.3.1.1項「SDOサービスにバックアップされたエンティティ・オブジェクトの作成」に記載されている方法に従って、サービスバック・エンティティ・オブジェクトを作成します。
サービスバック・エンティティ・オブジェクトからビュー・オブジェクトを作成する手順:
アプリケーション・ナビゲータで、サービスバック・エンティティ・オブジェクトを右クリックし、新規デフォルト・ビュー・オブジェクトを選択します。
「デフォルト・ビュー・オブジェクトの作成」ダイアログで、ビュー・オブジェクトを作成するパッケージ名を入力し、ビュー・オブジェクト名を入力します(図11-13を参照)。
生成されたビュー・オブジェクトには、エンティティ・オブジェクトと同じ属性が含まれます。オプションで、概要エディタでビュー・オブジェクトを編集し、問合せをカスタマイズできます。リモート・サービスのデータをフィルタする場合は、ビュー・オブジェクトのビュー基準も定義できます。問合せ結果のフィルタの詳細は、5.11項「名前付きビュー基準の処理」を参照してください。
サービスバック・エンティティ・オブジェクトはアクセスの詳細、および必要に応じてリモートADF Business Componentsサービスからのデータ行の変更の詳細をカプセル化するエンティティ・オブジェクトです。エンティティ・オブジェクトの作成ウィザードを使用してサービスバック・エンティティ・オブジェクトを作成後、JDeveloperが追加のサービス関連メタデータを、エンティティ・コンポーネント定義の<Datasource>
要素に保存します(例11-15参照)。
サービスバック・ビュー・オブジェクトは、エンティティ・ベースのビュー・オブジェクトと同様に、そのメタデータ内の単一のサービスバック・エンティティ・オブジェクトを参照します。サービスバック・ビュー・オブジェクトは、他のビュー・オブジェクトと同様に使用できます。ビュー・オブジェクトの作業方法の詳細は、第5章「ビュー・オブジェクトを使用したSQL問合せの定義」を参照してください。ADFランタイムは、リモートADF Business Componentsサービスとの対話を処理します。
例11-15 エンティティ・オブジェクト・メタデータはサービス・ビューをデータ・ソースとして表示
<Entity xmlns="http://xmlns.example.com/bc4j" Name="Customer_ServiceBasedEO" InheritPersnalization="true" AliasName="CustomerSEO" BindingStyle="OracleName" UseGlueCode="false"> <DataSource DataSourceClass="oracle.jbo.datasource.svc.SIEODataSourceImpl" Type="ServiceInterface"> <ServiceInterface ServiceName="{http://www.globalcompany.com/oesvc/}OrderEntryService" SDOName="{http://www.globalcompany.com/oesvc/}CustomersSVO" SVIName="{http://www.globalcompany.com/oesvc/}CustomersSVO" CreateOpName="createCustomer" UpdateOpName="updateCustomer" DeleteOpName="deleteCustomer" GetOpName="getCustomer" FindOpName="findCustomers" ProcessOpName="processCustomers"/> </DataSource> <Attribute Name="CustomerId" ColumnName="CustomerId" SQLType="NUMERIC" Type="oracle.jbo.domain.Number" ColumnType="NUMBER" PrimaryKey="true"/> <!-- ... Attribute that is associated with complex type attribute ... --> <Attribute Name="CurrencyCode" Precision="255" ColumnName="CurrencyCode" SQLType="VARCHAR" Type="java.lang.String" ColumnType="VARCHAR2"/> <!-- ... Attribute with complex type mapping ... --> <Attribute Name="OrderTotal" ColumnName="OrdTotal" SQLType="NUMERIC" Type="java.math.BigDecimal" ColumnType="NUMBER" <Properties> <SchemaBasedProperties> <DomainAttrMappings> <DomainAttrMapping MappedAttrName="CurrencyCode" Name="currencyCode"/> </DomainAttrMappings> </SchemaBasedProperties> </Properties> </Attribute> <!-- ... Other Attribute elements here ... --> </Entity>
サービス・インタフェースは各ビュー・インスタンスを公開するので、コンシューミング・プロジェクトで、サービスバック・エンティティ・オブジェクト間の階層関係の定義(アソシエーションによる)、およびサービスバック・ビュー・オブジェクトの階層関係の定義(ビュー・リンクによる)を行う必要があります。サービスバック・ビジネス・コンポーネントを作成しても、ビュー・リンクとアソシエーションは自動的には作成されません。たとえば、公開済のADF Business Componentsサービスのアプリケーション・モジュールで、使用するマスター/ディテール関係が定義されている場合、プロジェクト内で対応するビュー・オブジェクトのビュー・リンクを定義して、この階層を維持する必要があります。
さらに、ローカルなデータとサービスバック・ビュー・オブジェクトを問い合せる(またはその逆)、ビュー・オブジェクト間のビュー・リンクは作成できますが、ビュー・リンクを一度定義すると、次のようなオブジェクト慣用名では、エンティティ・ベースのビュー・オブジェクトを作成できません。
ビュー・オブジェクトは、サービスバック・エンティティ・オブジェクトであるセカンダリ・エンティ慣用名を参照できません。
ビュー・オブジェクトは、セカンダリ・エンティティの慣用名付きのサービスバック・エンティティ・オブジェクトである、プライマリ・エンティ慣用名を参照できません。
クライアント・プロジェクト内の通常のエンティティ・オブジェクトとサービスバック・エンティティ・オブジェクト間のアソシエーションにも同じ制約が適用されます。アソシエーションは作成できますが、ビュー・オブジェクトは作成できません。
ビュー・リンクの作成ウィザードを使用して、プロジェクトで定義されたビュー・オブジェクト間の関係を指定します(図11-14を参照)。ビュー・リンクの作成の詳細は、5.6.1項「エンティティ・ベースのビュー・オブジェクトに対するマスター/ディテール階層の作成方法」を参照してください。
作成するビュー・リンクでは、ローカルにアクセスしたデータベース表に問い合せるサービスバック・ビューとビュー・オブジェクト間の関係を定義できます。たとえば、サービスバック・マスター・ビュー・オブジェクトで、データベースから派生したディテール・ビュー・オブジェクトを実行する場合があります。表11-2に示す組合せで、ビュー・リンクを作成できます。
表11-2 サービスバック・ビュー・オブジェクトに関連する、サポートされているビュー・リンクの組合せ
使用例 | マスター・ビュー・オブジェクト・タイプ | ビュー・リンク・ディテール・ビュー・オブジェクト・タイプ | ビュー・リンク・カーディナリティ |
---|---|---|---|
リモート・ディテールのあるローカル・マスター行 |
問合せベース |
サービスバック |
1対多 |
ローカル・ディテールのあるリモート・マスター行 |
サービスバック |
問合せベース |
1対多 |
リモート参照情報のあるローカル・マスター行 |
問合せベース |
サービスバック |
多対1 |
ローカル参照情報のあるリモート・マスター行 |
サービスバック |
問合せベース |
多対1 |
該当するビュー階層を定義したら、ビュー・リンクの作成ウィザードを使用して、プロジェクトのアプリケーション・モジュールの概要エディタで、データ・モデルの新しいビュー・インスタンスを定義します(図11-15を参照)。更新したデータ・モデルによって、Fusion Webアプリケーションのユーザー・インタフェースとのデータバインドを可能にするADFデータ・コントロールとして、ビュー・オブジェクトを公開できます。データ・モデルの更新の詳細は、9.2.3.2項「アプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加」を参照してください。
アプリケーションを実行し、公開済のサービス対応ADFアプリケーションとの対話を行ってサービス操作を起動する前に、サービス・エンドポイント・プロバイダ・タイプおよびその他の構成情報を含む、公開済サービスの記述を行う必要があります。ADF Business ComponentsのServiceFactory
クラス (oracle.jbo.client.svc.ServiceFactory
)はサービスのプロキシを戻し、サービス・プロキシを使用してサービス操作を起動します。サービス・ファクトリは、3つの異なるサービス・エンドポイント・プロバイダのプロキシを戻して、これらのトランスポート・プロトコルをサポートできます。
サービス・エンドポイント・プロバイダがADF Business Componentの場合は、トランスポート・プロトコルはEJB RMIです。
サービス・エンドポイント・プロバイダがSOA Fabricの場合は、トランスポート・プロトコルはSOA Fabric SDOバインディングです。
サービス・エンドポイント・プロバイダがSOAP (JAX-WSクライアント用)の場合は、トランスポート・プロトコルはSOAPです。
公開済のサービス操作を起動するようにコンシューミング・アプリケーションを構成する手順:
SDO生成クラスのbcProfileName
_Common.jar
ファイルを、クライアント・プロジェクトのクラスパスに追加します。
クライアント・プロジェクトの.adf/META-INF
フォルダ内のconnections.xml
ファイルを更新して、公開済ADF Business Componentsサービスを記述します。
このファイルでの更新内容はアプリケーションで使用しているトランスポート・プロトコルがEJB RMIプロトコル、SOA Fabric SDOバインディング、またはSOAPプロトコル(JAX-WSクライアント用)のいずれかによって異なります。
アプリケーションで公開済サービスにアクセスできるようになるには、サービス・コンシューミング・プロジェクトから生成されたSDOクラスとそのスキーマ定義にアクセスできなければなりません。これらのファイルは、サービス公開を担当する開発チームが生成したbcProfileName
_Common.jar
ファイルにパッケージされています。
アプリケーションでSDOクラスとそのスキーマ定義を使用できるようにするには、サービス・プロバイダ・チームからbcProfileName
_Common.jar
ファイルを入手し、このJARファイルをローカル・プロジェクト・フォルダに配置します。たとえば、JARファイルをプロジェクトのdeploy
フォルダにコピーできます。次にJDeveloperを使用してJARファイルを、作成したSDOクライアント・ライブラリとともにプロジェクトのクラスパスに追加できます。SDOクラスJARファイルの生成手順は、11.2.20項「Oracle WebLogic ServerへのWebサービスのデプロイ方法」を参照してください。
SDOクライアント・ライブラリをクラスパスに追加する手順:
アプリケーション・ナビゲータで、SDOクラスが含まれているプロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」を選択し、「ライブラリの追加」をクリックします。
「ライブラリの追加」ダイアログで、「新規」をクリックして、SDOクライアント・ライブラリを作成します。
「ライブラリの作成」ダイアログで、「エントリの追加」をクリックしてクラスパス・エントリを追加します。
「パス・エントリの選択」ダイアログで、bcProfileName
_Common.jar
ファイルが含まれたフォルダに移動して、そのファイルを選択し、「ライブラリの作成」ダイアログに表示します。
「パス・エントリの選択」ダイアログでは、ファイル・システムまたはローカル・エリア・ネットワークを参照して、JARファイルを検索できます。サービス・プロバイダのアプリケーション・ワークスペースのdeploy
フォルダを参照してJARファイルを入手できない場合、ファイルを入手して自分のプロジェクト・フォルダにコピーする必要があります。たとえば、JARファイルをプロジェクトのdeploy
フォルダにコピーします。
ダイアログで「OK」をクリックすると、SDOクライアント・ライブラリを選択した状態で「プロジェクト・プロパティ」ダイアログが表示されます。「OK」をクリックして、ライブラリをクラスパスに追加します。
図11-16に、ServiceProvider_Common.jar
という名前が選択された、SDOクライアント・ライブラリを示します。この場合は、ライブラリ名はJARファイル名と同じです。オプションで、「ライブラリの作成」ダイアログでライブラリ名を編集できます。
サービス・エンドポイント・プロバイダがADF Business Componentsの場合は、サービス・ファクトリがEJBコンテナ内で実行中のステートレス・セッションBeanにバインドされた、EJBオブジェクト・プロキシを戻します。JNDIコンテキスト情報を提供して、コンシューミング・アプリケーションが公開済サービスを検索できるようにする必要があります。
公開済ADF Business Componentsサービスの登録用に提供する検索情報は、Fusion Webのコンシューミング・アプリケーションのconnections.xml
ファイル内(アプリケーションに相対的な.adf/META-INF
フォルダ内)にあります。ADF接続アーキテクチャはこのファイルを使用してサービス・エンドポイント・プロバイダの詳細をカプセル化します。
公開済データがコンシューミング・アプリケーションでローカルに(同じJVM内で)実行されているのか、コンシューミング・アプリケーションとはな別なサーバーでリモートに実行されているのかによって、提供するJNDI検索情報は異なります。通常、ADF Business Componentsサービスはコンシューミング・アプリケーションとは異なっており、したがってリモートに実行されています。
公開済サービスをクライアント・アプリケーションに登録するには、例11-16に従ってconnections.xml
ファイルを更新します。ADF Business Componentsサービスがコンシューミング・アプリケーションでローカルに実行されている場合(JDeveloper内での実行時のように)、サービス・ファクトリはJNDI名さえあればサービスを検索できます。
注意: スタンドアロンOracle WebLogic Serverにコール元アプリケーションをデプロイする場合は、 |
例11-16 クライアントのconnections.xmlファイルによるローカルEJB ADF Business Componentsサービスの登録
<References xmlns="http://xmlns.oracle.com/adf/jndi"> <Reference name="{www.globalcompany.com}StoreFrontService" className="oracle.jbo.client.svc.Service" xmlns=""> <Factory className="oracle.jbo.client.svc.ServiceFactory"/> <RefAddresses> <StringRefAddr addrType="serviceInterfaceName"> <Contents>oracle.foddemo.storefront.store.service.common. serviceinterface.StoreFrontService</Contents> </StringRefAddr> <StringRefAddr addrType="serviceEndpointProvider"> <Contents>ADFBC</Contents> </StringRefAddr> <StringRefAddr addrType="jndiName"> <Contents>StoreFrontServiceBean#oracle.fodemo.storefront.store.service.common. serviceinterface.StoreFrontService</Contents> </StringRefAddr> <StringRefAddr addrType="serviceSchemaName"> <Contents>StoreFrontAMService.xsd</Contents> </StringRefAddr> <StringRefAddr addrType="serviceSchemaLocation"> <Contents>oracle/fodemo/storefront/store/service/common/serviceinterface/</Contents> </StringRefAddr> </RefAddresses> </Reference> ... </References>
ADF Business Componentsサービスがコール元クライアントに対してリモートに実行すると、リモートJNDIコンテキスト情報をconnections.xml
ファイルに追加する必要があります。connections.xml
ファイルにあるこれらのJNDIコンテキスト・プロパティを編集できます(例11-17を参照)。
jndiFactoryInitial
はweblogic.jndi.WLInitialContextFactory
に設定する必要があります。
jndiProviderURL
はJNDIプロバイダのURLで、JNDIサーバーの場所を示します。URLはt3://
<hostname>
:
<server port>
という構成でなければなりません。
たとえば、t3://localhost:8888
のようなURLを指定します。ここでt3
はOracle WebLogicプロトコルで、localhost
はリモートOracle WebLogic Serverインスタンスが実行するホスト名、8888
はポート番号です。
jndiSecurityPrincipal
は、リモートJNDIへのアクセス権のあるプリンシパル(ユーザー名)を指定します。
スタンドアロンOracle WebLogic Serverにデプロイすると、ユーザー名をファイルから読み取ることができます。
jndiSecurityCredentials
は、セキュリティ・プリンシパルに使用する資格証明(パスワード)を指定します。
例11-11に示すように、サービスをテスト環境内のスタンドアロンOracle WebLogic Serverにデプロイする際は、JNDIプロバイダ用の資格証明をプレーン・テキストで指定できます。たとえば、Oracle WebLogic ServerのJNDIプロバイダにアクセスするための十分な権限を持つ、デフォルト管理者のユーザー名/パスワード資格証明である、weblogic
/weblogic1
を指定できます。
サービスを本番環境にデプロイする場合は、プレーン・テキストのパスワードを削除して、セキュリティの脆弱性を回避する必要があります。例11-17に示すように、connections.xml
ファイルには、パスワードを設定せずに<SecureRefAddr addrType="jndiSecurityCredentials"/>
を含む必要があります。スタンドアロンOracle WebLogic Server用のサービス・パスワードを構成するには、Oracleの資格証明ストアに暗号化されたパスワードを保存するOracle Enterprise Managerを使用する必要があります。
例11-17 クライアントのconnections.xmlファイルによるリモートEJB ADF Business Componentsサービスの登録
<References xmlns="http://xmlns.oracle.com/adf/jndi"> <Reference name="{www.globalcompany.com}StoreFrontService" className="oracle.jbo.client.svc.Service" xmlns=""> <Factory className="oracle.jbo.client.svc.ServiceFactory"/> <RefAddresses> <StringRefAddr addrType="serviceInterfaceName"> <Contents>oracle.foddemo.storefront.store.service.common. serviceinterface.StoreFrontService</Contents> </StringRefAddr> <StringRefAddr addrType="serviceEndpointProvider"> <Contents>ADFBC</Contents> </StringRefAddr> <StringRefAddr addrType="jndiName"> <Contents>StoreFrontServiceBean#oracle.fodemo.storefront.store.service.common. serviceinterface.StoreFrontService</Contents> </StringRefAddr> <StringRefAddr addrType="jndiFactoryInitial"> <Contents>weblogic.jndi.WLInitialContextFactory</Contents> </StringRefAddr> <StringRefAddr addrType="jndiProviderURL"> <Contents>t3://localhost:8888</Contents> </StringRefAddr> <StringRefAddr addrType="jndiSecurityPrincipal"> <Contents>a_username</Contents> </StringRefAddr> <SecureRefAddr addrType="jndiSecurityCredentials"/> <StringRefAddr addrType="serviceSchemaName"> <Contents>StoreFrontAMService.xsd</Contents> </StringRefAddr> <StringRefAddr addrType="serviceSchemaLocation"> <Contents>oracle/fodemo/storefront/store/service/common/serviceinterface/</Contents> </StringRefAddr> </RefAddresses> </Reference> ... </References>
サービス・エンドポイント・プロバイダがSOAPの場合、サービス・ファクトリは動的なJAX-WSクライアント・プロキシを作成します。WSDL URLとポート名を提供して、コンシューミング・アプリケーションが公開済サービスを検索できるようにする必要があります。さらに、SOAPクライアント用には、SOAPヘッダーの一部として、Oracle Web Service Manager (Oracle WSM)クライアント・セキュリティ・ポリシーを添付できます。
公開済ADF Business Componentsサービスの登録用に提供する検索情報は、Fusion Webのコンシューミング・アプリケーションのconnections.xml
ファイル内(アプリケーションに相対的な.adf/META-INF
フォルダ内)にあります。ADF接続アーキテクチャはこのファイルを使用してサービス・エンドポイント・プロバイダの詳細をカプセル化します。
注意: スタンドアロンOracle WebLogic Serverにコール元アプリケーションをデプロイする場合は、 |
SOAPプロトコル用にクライアント・アプリケーションに公開済サービスを登録するには、アプリケーションがアイデンティティ伝播とアイデンティティ切替えのどちらを使用しているかによって、例11-18または例11-19の例に従ってconnections.xml
ファイルを更新します。アイデンティティ伝播と切替えは、各プロセスでアイデンティティを伝播するという点では同様です。Fusion Webアプリケーションでは、アイデンティティ伝播によって現在コードを実行中のアイデンティティが伝播されます。一方、アイデンティティ切替えでは、現在コードを実行中のものとは異なるアプリケーション・アイデンティティを伝播します。
公開済サービスをクライアント・アプリケーションに登録し、資格証明キーに基づいて、ユーザー・アイデンティティが切り替わるようにするには、例11-18の例に従って、connections.xml
ファイル内で、クライアント側のポリシー、oracle/wss11_username_token_with_message_protection_client_policy
を指定します。
注意:
|
例11-18 クライアントのconnections.xmlファイルによる、アイデンティティ切替えを使用したSOAPプロトコル用のリモートBusiness Componentsサービスの登録
<Reference name="{http://xmlns.oracle.com/apps/sample/hrService/}HrService" className="oracle.jbo.client.svc.Service" xmlns=""> <Factory className="oracle.jbo.client.svc.ServiceFactory"/> <RefAddresses> <StringRefAddr addrType="serviceInterfaceName"> <Contents>oracle.apps.sample.hrService.HrService</Contents> </StringRefAddr> <StringRefAddr addrType="serviceEndpointProvider"> <Contents>SOAP</Contents> </StringRefAddr> <StringRefAddr addrType="webServiceConnectionName"> <Contents>HrServiceConnection</Contents> </StringRefAddr> <StringRefAddr addrType="serviceSchemaName"> <Contents>HrService.xsd</Contents> </StringRefAddr> <StringRefAddr addrType="serviceSchemaLocation"> <Contents>oracle/apps/sample/hrService/</Contents> </StringRefAddr> </RefAddresses> </Reference> <Reference name="HrServiceConnection" className="oracle.adf.model.connection.webservice.impl.WebServiceConnectionImpl" xmlns=""> <Factory className="oracle.adf.model.connection.webservice.api.WebServiceConnectionFactory"/> <RefAddresses> <XmlRefAddr addrType="WebServiceConnection"> <Contents> <wsconnection description="http://rws65094fwks:7202/MySampleSvc/HrService?WSDL" service="{http://xmlns.oracle.com/apps/sample/hrService/}HrService"> <model name="{http://xmlns.oracle.com/apps/sample/hrService/}HrService" xmlns="http://oracle.com/ws/model"> <service name="{http://xmlns.oracle.com/apps/sample/hrService/}HrService"> <port name="HrServiceSoapHttpPort" binding="{http://xmlns.oracle.com/apps/sample/hrService/}HrServiceSoapHttp" portType="http://xmlns.oracle.com/apps/sample/hrService/}HrService"> <call-properties xmlns="http://oracle.com/adf"> <call-property id="csf-key" xmlns=""> <name>csf-key</name> <value>meuser.credentials</value> </call-property> </call-properties> <policy-references xmlns="http://oracle.com/adf"> <policy-reference category="security" uri="oracle/wss11_username_token_with_message_protection_client_policy" enabled="true" id="oracle/wss11_username_token_with_message_protection_client_policy" xmlns=""/> </policy-references> <soapaddressUrl="http://rws65094fwks:7202/MySampleSvc/HrService" xmlns="http://schemas.xmlsoap.org/wsdl/soap/"/> </port> </service> </model> </wsconnection> </Contents> </XmlRefAddr> </RefAddresses> </Reference>
公開済サービスをクライアント・アプリケーションに登録し、ユーザー・アイデンティティをコール元に伝播させるには、例11-19の例に従って、connections.xml
ファイル内で、クライアント側のポリシー、oracle/wss11_saml_token_with_message_protection_client_policy
を指定します。
例11-19 クライアントのconnections.xmlファイルによる、アイデンティティ伝播を使用したSOAPプロトコル用のリモートBusiness Componentsサービスの登録
<Reference name="{http://xmlns.oracle.com/apps/sample/hrService/}HrService" className="oracle.jbo.client.svc.Service" xmlns=""> <Factory className="oracle.jbo.client.svc.ServiceFactory"/> <RefAddresses> <StringRefAddr addrType="serviceInterfaceName"> <Contents>oracle.apps.sample.hrService.HrService</Contents> </StringRefAddr> <StringRefAddr addrType="serviceEndpointProvider"> <Contents>SOAP</Contents> </StringRefAddr> <StringRefAddr addrType="webServiceConnectionName"> <Contents>HrServiceConnection</Contents> </StringRefAddr> <StringRefAddr addrType="serviceSchemaName"> <Contents>HrService.xsd</Contents> </StringRefAddr> <StringRefAddr addrType="serviceSchemaLocation"> <Contents>oracle/apps/sample/hrService/</Contents> </StringRefAddr> </RefAddresses> </Reference> <Reference name="HrServiceConnection" className="oracle.adf.model.connection.webservice.impl.WebServiceConnectionImpl" xmlns=""> <Factory className="oracle.adf.model.connection.webservice.api.WebServiceConnectionFactory"/> <RefAddresses> <XmlRefAddr addrType="WebServiceConnection"> <Contents> <wsconnection description="http://rws65094fwks:7202/MySampleSvc/HrService?WSDL" service="{http://xmlns.oracle.com/apps/sample/hrService/}HrService"> <model name="{http://xmlns.oracle.com/apps/sample/hrService/}HrService" xmlns="http://oracle.com/ws/model"> <service name="{http://xmlns.oracle.com/apps/sample/hrService/}HrService"> <port name="HrServiceSoapHttpPort" binding="{http://xmlns.oracle.com/apps/sample/hrService/}HrServiceSoapHttp" portType="http://xmlns.oracle.com/apps/sample/hrService/}HrService"> <policy-references xmlns="http://oracle.com/adf"> <policy-reference category="security" uri="oracle/wss11_saml_token_with_message_protection_client_policy" enabled="true" id="oracle/wss11_saml_token_with_message_protection_client_policy" xmlns=""/> </policy-references> <soap addressUrl="http://rws65094fwks:7202/MySampleSvc/HrService" xmlns="http://schemas.xmlsoap.org/wsdl/soap/"/> </port> </service> </model> </wsconnection> </Contents> </XmlRefAddr> </RefAddresses> </Reference>
サービス・エンドポイント・プロバイダがファブリックの場合は、サービス・ファクトリによってSOAファブリック・コンポジット・プロキシが戻され、ファブリックのSDOバインディングを使用してファブリック・コンポジット内で実行中のサービスがコールされます。ファブリック・コンポジット名を提供して、コンシューミング・アプリケーションが公開済サービスを検索できるようにする必要があります。
公開済ADF Business Componentsサービスの登録用に提供する検索情報は、Fusion Webのコンシューミング・アプリケーションのconnections.xml
ファイル内(アプリケーションに相対的な.adf/META-INF
フォルダ内)にあります。ADF接続アーキテクチャはこのファイルを使用してサービス・エンドポイント・プロバイダの詳細をカプセル化します。
注意: スタンドアロンOracle WebLogic Serverにコール元アプリケーションをデプロイする場合は、 |
公開済サービスをファブリック・プロトコルのクライアント・アプリケーションに登録するには、例11-20に従って、connections.xml
ファイルを更新します。ここで、fabricAddress
は公開済サービスのファブリック・コンポジット名です。
例11-20 クライアントのconnections.xmlファイルによる、SOAファブリックのSDOバインディング用のリモートBusiness Componentsサービスの登録
<References xmlns="http://xmlns.oracle.com/adf/jndi"> <Reference name="{www.globalcompany.com}StoreFrontService" className="oracle.jbo.client.svc.Service" xmlns=""> <Factory className="oracle.jbo.client.svc.ServiceFactory"/> <RefAddresses> <StringRefAddr addrType="serviceInterfaceName"> <Contents>oracle.foddemo.storefront.store.service.common. serviceinterface.StoreFrontService</Contents> </StringRefAddr> <StringRefAddr addrType="serviceEndpointProvider"> <Contents>Fabric</Contents> </StringRefAddr> <StringRefAddr addrType="fabricAddress"> <Contents>fabric_StoreFrontService</Contents> <StringRefAddr addrType="serviceSchemaName"> <Contents>StoreFrontAMService.xsd</Contents> </StringRefAddr> <StringRefAddr addrType="serviceSchemaLocation"> <Contents>oracle/fodemo/storefront/store/service/common/serviceinterface/</Contents> </StringRefAddr> </RefAddresses> </Reference> ... </References>
Oracle ADFモデル・テスターを起動する場合、プロジェクトは事前に11.3.4項「サービスバック・ビジネス・コンポーネント・ランタイムの構成方法」に記載されているランタイム要件を満たしている必要があります。Oracle ADFモデル・テスターでは、リモート・サービスから作成したビュー・オブジェクトを表示し、サービスと対話して標準のCRUD操作を実行できます。
実行するアプリケーション・モジュールはローカルに問い合せたデータとリモートに問い合せたデータに一緒にアクセスできるので、サービスバック・ビュー・オブジェクトとデータベースから派生したビュー・オブジェクトが同じテスターに表示されます。Oracle ADFモデル・テスターで、サービスバック・ビュー・オブジェクトを選択したときにエンドポイントが使用できない場合は、ランタイム例外が発生します。
Oracle ADFモデル・テスターの実行方法の詳細は、6.3.1項「Oracle ADFモデル・テスターの実行方法」を参照してください。
ADF Business Componentsサービス・インタフェースでは、サービス・プロキシを戻して、起動した操作が公開済サービスで指定したトランスポート・プロトコルを使用していることを確認する必要があります。
始める前に:
コンシューミング・アプリケーションが、クラスパス上に正しいライブラリを持っていることを確認する必要があります。アプリケーション・ナビゲータでプロジェクトをダブルクリックし、「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」を選択し、次のライブラリが表示されることを確認します。
Java EE 1.5
Oracle XML Parserバージョン2
BC4Jサービス・クライアント
JAX-WS Client
サービスの共通JARファイル
例11-21に示すように、操作を起動する際、次のタスクを実行します。
oracle.jbo.client.svc.ServiceFactory
クラスと公開済サービス・クラスをインポートします。
サービス・ファクトリ・オブジェクト上でgetServiceProxy()
をコールし、<serviceName>
.NAME
の形式でサービス名を渡します。ADFサービス・ファクトリはこの方法で戻されたサービス・プロキシ・オブジェクトにSDOHelperContext
IDを組み込み、最新のADF Business Componentサービス・スキーマ・メタデータがSDOに提供されるようにします。
サービス・オブジェクトのスキーマ(.xsd
ファイル)は通常MDSに保存されており、たとえばビジネス・コンポーネント属性の追加、既存の型の拡張、新しい型の定義などのために拡張されている場合があります。ローカル・ヘルパー・コンテキストにより、他のサービスのSDOメタデータに影響を及ぼすことなく、アプリケーションの再起動を行わなくても、各サービス・スキーマ定義のカスタマイズが可能です。
データ・ファクトリ・オブジェクト上でcreate()
をコールし、プロキシ・オブジェクトをgetServiceProxy()
コールで入手します。
プロキシ・オブジェクト上で操作を起動すると、データ・オブジェクトが戻されます。
戻されたデータ・オブジェクトをXMLとして保存します。
例11-21 コンシューミング・アプリケーションにおけるサービス・プロキシの入手と起動
import commonj.sdo.DataObject; import commonj.sdo.helper.DataFactory; import commonj.sdo.helper.XMLHelper; import hr.common.Dept; import hr.common.serviceinterface.HRAppService; import oracle.jbo.client.svc.ServiceFactory; ... { HRAppService proxy = (HRAppService) ServiceFactory.getServiceProxy(HRAppService.NAME); Dept dept = (Dept) ServiceFactory.getDataFactory(proxy).create("http://example.com/hr/common/" "Dept"); dept.setDname("ENGINEERING"); ... dept = proxy.createDept(dept); String xml = ServiceFactory.getXMLHelper(proxy).save((DataObject) dept, "http://example.com/hr/common/", "dept"); out.print(xml); }
ADFサービス・インタフェース・フレームワークは、一連の共通データ・オブジェクト(oracle.jbo.common.service.types.FindCriteria
、oracle.jbo.common.service.types.FindControl
、oracle.jbo.common.service.types.ProcessControl
など)を定義します。これらのデータ・オブジェクトは、標準のfindXxx()
メソッドおよびprocessXxx()
メソッドの各コールで使用されます。これらのデータ・オブジェクトは、コンシューミング・アプリケーションで作成して、標準サービス・メソッドに渡すことができます。例11-22に示すように、データ・ファクトリ・クラスのcreate()
メソッドをコールして、findXxx()
またはprocessXxx()
メソッドに渡す前に、これらのデータ・オブジェクトを作成する必要がある場合があります。
ADFランタイムはデータ・ソース情報をサービスバック・エンティティ・オブジェクトXML定義から入手し、必要に応じてサービス・インタフェース・メソッドとの対話を自動化します。サービスバック・エンティティ・オブジェクトを使用することで、すべての共通リモート・サービスのデータ・アクセス・タスクに対して、サービス・プロキシおよびサービス・データ・オブジェクトを直接プログラミングする必要がなくなります。ADFサービス・ファクトリはサービスを検索し、connections.xml
で指定したサービス・インタフェースを使用して、サービス・メソッドを起動します。
アプリケーションがリモートADF Business Componentsサービスにアクセスする際、各リモート・コールはステートレスで、リモート・サービスは、サービス対応のアプリケーション・モジュールのサービス・インタフェースを使用するビジネス・コンポーネントと同じトランザクションには関与しません。
ほとんどの場合、リモート・サービスへのコールは情報提供を目的としたもので、リモート・オブジェクトは変更されません。ただし、リモート・サービスを使用して変更を行う必要がある場合は、次の点に注意してください。
リモート・サービスにスローされた例外によって、ローカル・トランザクションが失敗します。
データ変更を伴うリモート・サービス・コールが成功した後、なんらかの理由でローカル・トランザクションが失敗した場合、エラー処理コードを使用して、リモート・サービスに対して復元トランザクションを行い、過去の変更を「取り消す」必要があります。
参照情報にアクセスするためにWebサービスを使用することがあります。しかし、呼び出したサービスによってデータを変更する場合もあります。サービスが社内の自分自身のチームまたは別のチームによって記述されていた場合、このデータ変更が自社のデータベース内で発生する可能性があります。Webサービスが自社のファイアウォールの外部にある場合はもちろん、変更対象のデータベースは別の会社によって管理されることになります。いずれの場合でも、起動するWebサービスによって実行されるデータ変更は、サービス対応のアプリケーション・モジュールの現在の作業ユニットとは無関係な独自のトランザクションによって実行されるということを理解しておくことが重要です。たとえば、データを変更するWebサービスを起動した後、rollback()
をコールしてアプリケーション・モジュールの現在の作業ユニット内で保留中の変更を取り消しても、該当するプロセス内でコールしたWebサービスで実行した変更に対しては、ロールバックの影響はありません。対応するWebサービス・メソッドを起動して、補正用の変更を実行し、アプリケーション・モジュールのトランザクションのロールバックを無効にする必要がある場合があります。
実行時、ADFはリモートADF Business Componentsサービスとの対話を処理します。ただし、サービスバック・ビジネス・コンポーネントには、次のような設計時の制約があり、これによってアプリケーションの実行時の動作が制限されることがある点を認識しておく必要があります。設計時におけるこれらの制約の適用の詳細は、11.3.3項「サービスバック・ビジネス・コンポーネントのデータ・モデルの更新方法」を参照してください。
作成するビュー・オブジェクトは、サービスバック・エンティティ・オブジェクトを、セカンダリ・エンティティ・オブジェクト慣用名として参照できません。
作成するビュー・オブジェクトは、関連する複数のエンティティ・オブジェクトのいずれかがサービスバック・エンティティ・オブジェクトの場合、これらのエンティティ・オブジェクトからフラット化された結合を生成できません。
サービスバック・エンティティ・オブジェクトから作成するサービスバック・ビュー・オブジェクトは、セカンダリ・エンティ慣用名を参照しません。
設計時におけるこれらの制約の適用の詳細は、11.3.3項「サービスバック・ビジネス・コンポーネントのデータ・モデルの更新方法」を参照してください。