11 サービス対応アプリケーション・モジュールの統合

この章では、ADFアプリケーション・モジュールの公開方法と、サービス・インタフェース接続を定義してFusion Webアプリケーションで外部Webサービスとして使用できるようにする方法を説明します。また、公開されたアプリケーション・モジュールを外部サービスとしてFusion Webアプリケーションに組み込む方法についても説明します。

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

• 11.1項「サービス対応アプリケーション・モジュールの概要」

• 11.2項「サービス対応アプリケーション・モジュールの公開」

• 11.3項「サービス対応アプリケーション・モジュールによるリモート・データのアクセス」

11.1 サービス対応アプリケーション・モジュールの概要

サービス対応アプリケーション・モジュールは、サービス・インタフェースを使用して、サービス利用者に通知するADFアプリケーション・モジュールです。サービス利用者がサービス対応アプリケーション・モジュールの利用には、Webサービス・アクセス、Service Component Architecture (SCA)コンポジット・アクセス、および別なADFアプリケーション・モジュールからのアクセスという3つのシナリオがあります。

注意: WebサービスおよびWebサービスに対するOracle WebLogic Serverサポートの背景は、『Oracle Fusion Middleware Webサービスの紹介』を参照してください。

Service Component Architecture (SCA)は、リモートで使用可能なサービスを実装するためのオープンで技術に中立なモデルを提供します。SCAはビジネス機能の観点から定義されており、アプリケーション開発者によるミドルウェア機能のアクセスを容易にします。ADFビジネス・コンポーネントはサービス・インタフェースで公開可能なアプリケーション・モジュールにより、SCA準拠ソリューションをサポートしています。あらゆる開発チームはサービス対応アプリケーション・モジュールを公開することで、コンポジットFusion Webアプリケーションに貢献できます。リモート・サービスからアセンブルされたFusion Webアプリケーションも、単一のアプリケーション・サーバー上で稼働するための参加サービスが不要です。

コンポジット・アプリケーションは異なるアプリケーション・サーバーで実行されることが多いのですが、SCAは統一されたアプリケーションとしての外観を提供します。利用するクライアント・プロジェクトはADFサービス・ファクトリ検索メカニズムを使用して、データおよびサービス対応アプリケーション・モジュールによってカプセル化されたあらゆるビジネス・メソッドにアクセスします。実行時、サービスの起動に使用されるプロトコル(SOAPまたはRMI)によって、コール元のクライアントとADFサービスが同じトランザクションに参加している場合とそうでない場合があります。RMIプロトコルとJava Transaction API (JTA)マネージド・トランザクションのみで、コール元のクライアントと同じトランザクションでサービスをコールすることができます。デフォルトでは、RMIプロトコルをサポートするには、ADFサービスが同じトランザクションに参加するように構成しておく必要があります。

アプリケーション・モジュールをサービス対応にすると、JDeveloperが必要なアーティファクトを作成します。その構成内容は次のとおりです。1) サービスを定義しているJavaインタフェース、2) Javaインタフェースを実装するEJB 3.0セッションBean、3) サービスの操作を記述したWSDLファイル、および(4) サービスのデータ構造を定義したXML Schema Document (XSD)。サービス・インタフェースはWSDLとXSDを組み合せた中立言語で、Fusion Webアプリケーション・クライアント用に記述されます。

注意: SCAは次の2種類のサービスを定義します。 リモート対応可能なサービス。通常はきめが粗く、結合が緩いSOAアーキテクチャでのリモート公開用に設計されます。 ローカル・サービス。通常はきめが細かく、緊密に結合されたアーキテクチャ内で同時にデプロイされる他の実装でのローカルな使用のために設計されます。 ADFビジネス・コンポーネント・サービスは最初のカテゴリに分類され、リモート対応可能サービスとしてのみ使用する必要があります。ローカル・サービス・サポートには、9.10項「アプリケーション・モジュールのクライアント・インタフェースのプログラム的操作」で説明しているApplicationModuleインタフェースとViewObjectインタフェース・サポートを使用します。

リモート・アプリケーション・モジュールによって定義されたサービス(データ・アクセスとメソッド・コールを含む)は、その他のあらゆるアプリケーション・モジュールとの相互運用が可能です。これは、同じアプリケーション・モジュールで、ADFデータ・コントロールおよびWebサービス・クライアントを使用している対話型のWebユーザー・インタフェースをサポートできるということを意味しています。

ADF接続アーキテクチャでは、BPELプロセスなどのコンポーネントを起動する場合の一般的なメカニズムを使用して、入替え後のサービス実装を起動しており(13.2項「アプリケーション・モジュールからのWebサービスのコール」を参照)、汎用Webサービス・プロバイダはDataObject引数を取る任意のアプリケーション起動を処理し、DataObjectを返します。

SCAおよびSDO標準の詳細は、http://www.osoa.orgのOpen SOA Webサイトを参照してください。

11.2 サービス対応アプリケーション・モジュールの公開

アプリケーション・モジュールは、ビジネス・ロジックを関連する一連のビジネス機能としてカプセル化するADFビジネス・コンポーネント・フレームワーク・コンポーネントです。アプリケーション・モジュールはサービスにマップされます。アプリケーション・モジュールの概要エディタを使用して、Webサービス・インタフェースを有効化し、ビュー・オブジェクト・データの行をService Data Object (SDO)コンポーネントとして公開します。これらのコンポーネントの基礎になっているSDOフレームワークが、ビュー・オブジェクトのデータを抽出し、JavaとXML間でのデータ構造のやり取りを標準化します。この種のデータ抽出によってサービス指向アーキテクチャ(SOA)での異種環境データ・ソースの処理が簡略化され、対話型のWebユーザー・インタフェースとWebサービス・クライアントに同じビュー・オブジェクトを使用することで、ビュー・オブジェクトを選択してサービス対応にできます。

JDeveloperでは、SDOを使用してJavaとXML間でのデータ構造のやり取り方法を標準化する、Webサービスとしてアプリケーション・モジュールを公開できます。JDeveloperは、Webサービス・クライアントがコンシューミング・アプリケーションで使用するWSDLサービス記述も生成します。

サービス対応アプリケーション・モジュールは、ビュー・オブジェクト、カスタム・メソッド、組込みデータ処理操作、および指定されたビュー基準に基づく特殊な検索方法を公開し、クライアントが使用できるようにします。アプリケーション・モジュール・サービス・インタフェースの有効後、ADFビジネス・コンポーネントService Interfaceデプロイメント・プロファイルを作成して、ターゲット・アプリケーション・サーバーにデプロイする必要があります。

Business Process Execution Language (BPEL)プロセス・サービス・コンポーネントで使用する、ビュー・インスタンス・データ処理操作も公開する必要があります。BPELは、複数のサービスからエンドツーエンドのビジネス・プロセスを構成するための言語です。BPELエンティティ変数の使用によってSDOデータ・プロバイダにデータ操作を委譲する方法の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。

注意: SDOパラメータを使用して直接メソッドを実装するのではない点が重要です。SDOフレームワークを使用して、実行時にのみビュー行のタイプをラップします。

11.2.1 アプリケーション・モジュール・サービス・インタフェースの有効化の方法

JDeveloperでアプリケーション・モジュールを編集して、最上位のビュー・オブジェクトを公開し、サポートしているサービス操作を定義するWebサービス・インタフェースを作成します。選択する最上位のビュー・オブジェクトは自動的にサービス対応になり、サービス・クライアントがアクセス可能になります。

標準的なサービス操作の目的は、ビュー・オブジェクトのデータ処理操作を公開することです。標準のサービス操作を起動することで、基になるフレームワーク・オブジェクトで定義したあらゆるビジネス・ロジック(たとえばビジネス・ルールの評価など)が、適用されます。表11-1は、サービス・ビュー・インスタンスがサポートしている標準操作のリストです。

表11-1 標準ビュー・インスタンス・データ処理操作

操作	メソッド名	操作の説明
Create	create<VOName>	単一のADFビジネス・コンポーネント・ビュー行を作成します。
Update	update<VOName>	単一のADFビジネス・コンポーネント・ビュー行を更新します。
Delete	delete<VOName>	単一のADFビジネス・コンポーネント・ビュー行を削除します。
Merge	merge<VOName>	ADFビジネス・コンポーネント・ビュー行があれば更新し、なければ新しく作成します。
GetByKey	get<VOName>	主キーによって、単一のADFビジネス・コンポーネント・ビュー行を取得します。
Find (ビュー・オブジェクト問合せ文による)	find<VOName>	選択したビュー・オブジェクトの問合せ文に基づき、ADFビジネス・コンポーネントのビュー行のリストを検索して戻します。 問合せでは、問合せの実行に必要として定義されたバインド変数は指定してはなりません。サービス・インタフェースは実行時には必須バインド変数を公開しません。このシナリオ用の検索メソッドの作成の詳細は、11.2.8項「必須バインド変数によってフィルタされる宣言的検索操作の公開方法」を参照してください。
Find (ビュー基準による)	find<VOName><VCName>	SDOベースのビュー基準によって、単一のADFビジネス・コンポーネント・ビュー行のリストを検索して戻します。これは必須バインド変数に依存しているADFビジネス・コンポーネント・ビュー行のフィルタには適した方法です。
Process	process<VOName>	ADFビジネス・コンポーネント・ビュー行リストに対する作成、更新、削除、またはマージ操作を実行します。指定した操作が特定のリスト内のすべてのオブジェクトに対して適用されます。
ProcessChangeSummary	processCS<VOName>	ADFビジネス・コンポーネント・ビュー行リストに対する作成、更新、または削除操作を実行します。ChangeSummaryオブジェクトでの指定内容に応じて、異なるオブジェクトに対して異なる操作が適用されます。

注意: 親ビュー・オブジェクトのサービス・インタフェースを有効にすると、JDeveloperが多相コレクション内の親を拡張するビュー・インスタンスに対して、サービス・インタフェースを自動的に有効化します。多相ビュー・オブジェクトの詳細は、39.6.5項「多相ビュー行関連の作業」を参照してください。

子のビュー・オブジェクトを選択してサービス対応にするSDOクラスの作成方法の詳細は、11.2.4項「個別のビュー・オブジェクトのサービス対応化の方法」を参照してください。

作業を始める前に、次のようにします。

9.2.1項「アプリケーション・モジュールの作成方法」に記載されている方法に従って、該当するアプリケーション・モジュールを作成します。

Webサービスを作成するには:

1. アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「サービス・インタフェース」のナビゲーション・タブをクリックして、「サービス・インタフェースのサポートを有効化」ボタンをクリックします。

   サービス・インタフェースの作成ウィザードを使用して、該当するオプションを構成します。

3. サービス・インタフェースの作成ウィザードの「サービス・インタフェース」ページで、Webサービスの名前とターゲット・ネームスペースを入力します。

   ターゲット・ネームスペースはサービスのURIで、同じURIを入力することで、類似のサービスをグループ化するために割り当てることができます。

4. 有効化するサービス・ビュー・インスタンスで定義された静的なコントロール・ヒント(UIヒント)を戻すメソッドを生成するには、「コントロール・ヒント操作の生成」を選択します。

   このオプションを有効にすると、ウィザードがgetDfltCtrlHints()メソッドをサービス・インタフェースに追加します。サービス・インタフェース・クライアントはこのメソッドを起動して、サーバー上のUIヒントを解消するので、データベースへの往復は不要になります。メソッドはビュー・オブジェクト名とロケールを取得し、そのロケールの基本的なUIヒントを戻します。

5. アプリケーション・モジュールのメソッドを非同期サービス・メソッドとして公開し、Webサービスで同期と非同期の両方の操作を有効にするには、「非同期Webサービス・メソッドの生成」を選択します。

   デフォルトでは、Webサービスは同期サービス・メソッドをサポートしています。これによってクライアント・アプリケーションを強制的に起動して待機させ、レスポンスが返されるまで作業を続行できません。レスポンスがすぐに返される場合は、このWebサービスの起動方法が一般的です。しかし、リクエスト処理が遅延する場合もあるため、クライアント・アプリケーションは先に処理を続行し、後でレスポンスを処理するほうが効率的なことも少なくありません。

6. 「サービス・カスタム・メソッド」ページで、サービス・インタフェースに公開するカスタム・メソッドを追加し、各メソッドのパラメータと戻り値のデータ型を定義します。

   有効化するカスタム・サービス・メソッドのパラメータと非voidの戻り値は、プリミティブなJava型、oracle.jbo.server.ViewRowImpl、 java.util.List<ViewRowImpl>、oracle.jbo.AttributeList、またはjava.util.List<AttributeList>などのサポートされているデータ型のいずれかでなければなりません。

   ViewRowImplおよびAttributeListの両方のデータ型は、Webサービス・クライアントに対して同一の行構造で公開されますが、実行時には基本的な違いがあります。サポートされているデータ型の詳細は、11.2.3項「サービス・インタフェース上のメソッド・シグネチャについて」を参照してください。

   ViewRowImplまたはAttributeListデータ型を使用して、各パラメータと戻り値に対して、サービス・インタフェース内で使用可能なカスタム・メソッドを選択後、行構造に対応するビュー・オブジェクト・インスタンスの名前を選択する必要があります。

   1. 「選択済」リストで、returnまたはparametersを展開して、項目を選択します。

   2. Java要素データ型を「要素Javaタイプ」に入力します。

   3. Java要素型がViewRowImplまたはAttributeListの場合は、「要素のビュー・オブジェクト」に行構造を識別するビュー・オブジェクト・インスタンス名を入力します。

      たとえば、CustomerInfoビュー・オブジェクト・インスタンスの単一行を定義する場合、次のようなカスタム・メソッド・シグネチャが必要になります。

      public ViewRowImpl findCustomerInfo(int id)
      

      次にサービス・インタフェース内での表示用にfindCustomerInfo()カスタム・メソッドを選択した後、その戻り値をツリー内で選択し、「ビュー・オブジェクト」プロパティを、実行時に行構造を使用するビュー・インスタンスの名前であるCustomerInfoに設定します。

7. 「サービス・ビュー・インスタンス」ページで、サービス・インタフェースで公開する、アプリケーション・モジュール内の最上位ビュー・インスタンスを選択します。

   最上位のビュー・レベル・インスタンスのビュー・オブジェクト・サブタイプは、自動的にサービス対応になります。

   このページでは、公開したメソッドでサポートされる、使用可能なデータ処理操作も設定できます(図11-1を参照)。

   図11-1 ビュー・インスタンスとCRUD操作の選択

   
   

8. 「基本操作」タブで、現在選択しているビュー・インスタンスのデータ処理操作を選択します。

   標準的なサービス操作の目的は、ビュー・オブジェクトのデータ処理操作を公開することです。サービス操作を起動することで、基になるフレームワーク・オブジェクトで定義したあらゆるビジネス・ロジック(たとえばビジネス・ルールの評価など)が、適用されます。サービス・ビュー・インスタンスでサポートされている操作の詳細は、表11-1を参照してください。

   選択可能な検索メソッド操作の場合、検索メソッドはビュー・オブジェクトの問合せ文で必須バインド変数を参照してはなりません。必須バインド変数は、有効なバインド変数値がなければ問合せの実行ができないようにするものです。サービス・インタフェースは実行時には必須バインド変数を公開しません。このシナリオ用の検索操作の定義の詳細は、11.2.8項「必須バインド変数によってフィルタされる宣言的検索操作の公開方法」を参照してください。

9. 宣言的検索操作を公開するには、「ビュー基準の検索操作」タブを選択し、「ビュー基準の追加」アイコンをクリックします。

   カスタム検索操作を定義して、事前に定義された問合せの実行をサービスにサポートさせることができます。名前付きビュー基準の定義の詳細は、5.11項「名前付きビュー基準の処理」を参照してください。

   
   

   注意: サービス・インタフェースの検索操作は、プロジェクトで定義された特定のビュー基準に基づいています。したがって、ビュー基準のバインド変数が対応する検索操作メソッドのパラメータと一致しなければなりません。検索操作を定義し、サービス・インタフェースを生成後にバインド変数の数や順番を変更すると、実行時に対応するメソッドが実行されなくなります。したがって基にあるビュー基準を変更したら、サービス・インタフェースを生成しなおす必要があります。

   
   

   1. 「ビュー基準検索操作の構成」ダイアログで、検索操作用の名前付きビュー基準を選択します。

      このダイアログには、参照先のビュー・オブジェクトが公開しているビュー基準のリストが表示されます。たとえば、OrderInfoVOはオーダーIDを指定するバインド変数OrdIdを使用して、OrderInfoVOCriteriaを定義しています(図11-2を参照)。

      図11-2 名前付きビュー基準に基づく専用検索メソッド

      
      

   2. ビュー基準でバインド変数が使用されている場合、XML名をダブルクリックして、XML定義内でそのサービスが表示される名前をカスタマイズできます。

10. 「次」をクリックして、サービス・ビュー・インスタンスによって公開されるカスタム・メソッドを確認します。

11. 「終了」をクリックします。

11.2.2 アプリケーション・モジュール・サービス・インタフェース作成時の処理

JDeveloperはサービス・インタフェース・クラスを生成し、選択したすべてのビュー・インスタンス・オプションを有効にします(図11-3を参照)。

図11-3 アプリケーション・モジュールの概要エディタの「サービス・インタフェース」ページ

次の種類のファイルが生成され、アプリケーション・ナビゲータの「プロジェクト」パネルで、アプリケーション・モジュールのserviceinterfaceノードの下に表示されます(図11-4を参照)。

• リモート共通インタフェース(StoreFrontService.javaなど)

• リモート・サービス・スキーマ・ファイル(StoreFrontService.xsdなど)

• リモート・サービス定義ファイル(StoreFrontService.wsdlなど)

• リモート・サーバー・クラス(StoreFrontServiceImpl.javaなど)

図11-4 アプリケーション・モジュールの下に表示されるサービス・インタフェース・ファイル

さらに、ADFビジネス・コンポーネント・サービスを初めて作成すると、connections.xmlファイルが作成されます。このファイルはアプリケーション・ナビゲータの「アプリケーション・リソース」パネルで、DescriptorsおよびADF META-INFフォルダの下に表示されます。

11.2.2.1 リモート共通インタフェース

リモート共通インタフェースはWebサービス仕様(JSR-181)で指定されたメタデータの注釈を使用して、インタフェースをWebサービスとして公開する方法を指定します。この例は、Fusion Order DemoのStoreFrontモジュール内のStoreServiceAMアプリケーション・モジュールである、StoreFrontService.javaの一部を示しています。

例11-1 Fusion Order Demoのリモート共通インタフェース

package oracle.fodemo.storefront.store.service.common.serviceinteface;
...
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;
    ...
}

11.2.2.2 リモート・サービス・スキーマ・ファイル

リモート・サービス・スキーマ・ファイルはWebサービス・スキーマを示すXMLスキーマ・ファイルです(図11-5を参照)。

図11-5 リモート・サービス・スキーマ・ファイル

11.2.2.3 リモート・サービス定義ファイル

リモート・サービス定義ファイルは、Web Service Definition Language (WSDL)仕様に準拠したXML構造化ドキュメント・ファイルで、生成されたWebサービスをエンドポイント、すなわちポートの集合として記述します。ポートは、ネットワーク・アドレスを再利用可能なバインドに関連付けることで定義されます。Webサービスに接続したクライアント・アプリケーションはWSDLを読み取り、サーバー上で提供されている機能を判断します。WSDLはサービス自体のエンドポイントも指定しており、デプロイ済のサービスの検索およびテストに使用できます。

図11-6は、WSDLビジュアル・エディタ内でStoreServiceAMアプリケーション・モジュール用に生成されたWebサービス用のWSDLを示しています。「ソース」タブを選択すると、WSDLをXMLドキュメントとして表示できます。

図11-6 WSDLドキュメント

11.2.2.4 リモート・サーバー・クラス

リモート・サーバー・クラスはEJB 3.0のステートレス・セッションBeanで、リモート共通インタフェースを実装し、ADFビジネス・コンポーネントの汎用サービス・エンジンである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);
    }
...
}

11.2.2.5 connections.xml

ADFビジネス・コンポーネント・サービス・ファクトリは、サービス・クライアントによるサービスの検索を可能にするメカニズムです。サービス・ファクトリでは、ADF接続アーキテクチャとconnections.xmlファイルによって、サービス・エンドポイントの場所を管理します。ADFビジネス・コンポーネント・サービスを初めて作成すると、connections.xmlファイルが作成されます。このファイルはアプリケーション・ナビゲータの「アプリケーション・リソース」パネルで、DescriptorsおよびADF META-INFフォルダの下に表示されます。

例11-3は、ADFビジネス・コンポーネント・サービスを初めて作成した際に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>

11.2.3 サービス・インタフェース上のメソッド・シグネチャについて

アプリケーション・モジュールに対して、クライアント・インタフェースとサービス・インタフェースという2種類のインタフェースを定義できます。クライアント・インタフェースは、ADFモデルがUIクライアント用に使用します。サービス・インタフェースはアプリケーションの統合用で、外部のWebサービスまたはその他のアプリケーション・サービスによって使用されます(プログラミングによって、またはサービス対応エンティティ機能を使用して自動的に)。

アプリケーション・モジュールではインタフェースをまったくサポートしないことも、クライアント・インタフェースまたはサービス・インタフェースのいずれかだけをサポートすることも、両方を組み合せてサポートすることもできます。ただし、それぞれのインタフェース用に定義するカスタム・メソッドのパラメータや戻り値としてサポートされているデータ型は、2種類のインタフェースで異なっている点に注意してください。クライアント・インタフェースでサポートされている型の詳細は、9.9.5項「サービス・インタフェース上のメソッド・シグネチャについて」を参照してください。

サービス・インタフェースは、クライアント・インタフェースよりも限定的なカスタム・メソッド・パラメータと戻り値をサポートしています(次に限定されている)。

• Javaプリミティブ型とそのオブジェクト・ラッパー型(int、Integerなど)

• 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が定義されている場合は、アプリケーションは自動的に次を行います。

1. 主キー、代替キーのいずれかまたは両方で、対応するビュー・オブジェクト・インスタンス内の行を検索

2. 行が検出されない場合は、新しい行を作成

3. 検出された行または新規行に属性の変更を適用

メソッド・シグネチャでAttributeListのデータ型が定義されている場合は自動動作は行われず、カスタム・メソッドで実行されるアクションおよび変更されるデータは、カスタム・メソッドのコードに限定されます。

11.2.4 個別のビュー・オブジェクトのサービス対応化の方法

アプリケーション・モジュール用の概要エディタを使用してWebサービス・インタフェースを有効にすることで、JDeveloperは親のビュー・インスタンス選択をService Data Object (SDO)コンポーネントとして自動的に有効化します。各ビュー・インスタンス用に生成されたSDOコンポーネントは同じネームスペースを参照し、警告のサポートの有無など、同じオプション設定で構成されます。概要エディタの「Java」ページを使用して、既存のサービス対応ビュー・オブジェクトのSDO定義をカスタマイズできます。「Java」ページを使用して、サービス・インタフェースにまだ追加されていなかったビュー・オブジェクトをサービス対応にすることもできます。たとえば、マスター/ディテール関係でマスターとなる親ビュー・オブジェクトを選択しても、子ビュー・オブジェクトは自動的にサービス対応となりません。子ビュー・オブジェクトの概要エディタで「Java」ページを使用して、サービス・インタフェースに個別に追加できます。

ビュー・オブジェクトの概要エディタで「Java」ページを使用して、ビュー・オブジェクトのSDO名とネームスペースを構成するか、子ビュー・オブジェクトを個別に選択してサービス対応にします。

作業を始める前に、次のようにします。

5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。

ビュー・オブジェクトのSDO名とネームスペースを設定する手順:

1. アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「Java」ナビゲーション・タブをクリックし、「Javaオプションの編集」ボタンをクリックします。

3. 「Javaオプションの選択」ダイアログの「サービス・データ・オブジェクト」セクションで、「サービス・データ・オブジェクト・クラスの生成」を選択します。サービス・オブジェクト名と、サービス・データ・オブジェクトのターゲット・ネームスペースの値を入力します。

   ターゲット・ネームスペースはSDOのURIで、同じURIを入力することで、類似のSDOをグループ化するために割り当てることができます。

   SDOのパッケージ名を基に、ピリオドを「/」に置き換えて、デフォルトのSDOネームスペースが作成されます。「プリファレンス」ダイアログの「ビュー・オブジェクト」ページで、ネームスペースの接頭辞を定義している場合は、実行時に、その接頭辞がネームスペースの冒頭に追加されます。たとえば、図11-7はパッケージ名に基づくデフォルト・ネームスペースを示しています。

   図11-7 サービス・データ・オブジェクト名とネームスペース・オプション

   
   

4. サービス・インタフェース・オブジェクトのビュー行に関連する警告を抽出できるようにしたい場合は、オプションで、「警告のサポート」を選択します。

5. 「OK」をクリックします。

11.2.5 サービス対応ビュー・オブジェクトのSDOプロパティのカスタマイズ方法

ビュー・オブジェクトの概要エディタを使用して、サービス対応ビュー・オブジェクトのSDOコンポーネント定義をカスタマイズできます。デフォルトでは、サービス対応ビュー・オブジェクトはSDOプロパティとして公開されます。ビュー・オブジェクト定義をカスタマイズすることで、サービス・インタフェースから個別のSDOプロパティを除外できます。数値を定義するSDOプロパティの場合は、2つのプロパティを関連付けて、サービス・インタフェースに単一の複合型として表示させることができます。たとえば、通貨または測定単位を定義する1つのプロパティを、数値を表示する別なプロパティに関連付けることができます。現在サポートされているのは、AmountType(通貨コード)およびMeasureType(測定単位)の複合サービス型だけです。

11.2.5.1 生成されたSDOコンポーネントでの個別SDOプロパティの除外

アプリケーション・モジュール用の概要エディタを使用してWebサービス・インタフェースを有効にすることで、JDeveloperは親のビュー・インスタンス選択をSDOコンポーネントとして自動的に有効化します。さらに、子ビュー・オブジェクトを個別に選択してサービス対応とし、SDOコンポーネントを生成できます。デフォルトでは、生成されたSDOコンポーネントは、基本ビュー・オブジェクト定義のすべての属性をSDOプロパティとして公開します。サービス・インタフェースにSDOプロパティとして戻させたくない属性は、非表示にできます。

概要エディタの「属性」ページを使用して、サービス・インタフェースから除外するビュー・オブジェクト属性を選択します。 ビュー・オブジェクトの概要エディタで、「属性」ページから表示される「属性の編集」ダイアログを使用して、選択した属性をSDOコンポーネントに表示させないようにします。

作業を始める前に、次のようにします。

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。

次のタスクを完了する必要があります。

1. 5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。

2. 11.2.4項「個別のビュー・オブジェクトのサービス対応化の方法」に記載されている方法に従って、該当するビュー・オブジェクトをサービス対応にします。

サービス対応ビュー・オブジェクトからSDOプロパティを除外する手順:

1. アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで除外するプロパティに対応する属性を選択し、「選択した属性の編集」ボタンをクリックします。

4. 「属性の編集」ダイアログの「ビュー属性」ページで、「SDOプロパティ」の選択を解除します。

5. 「OK」をクリックします。

11.2.5.2 複合データ型を使用した関連する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>

また、13.2.5.4項「Webサービス・プロキシ・クラスを使用したアプリケーション・モジュールの起動」に記載の方法でWebサービス・プロキシを生成すると、クラスが2つの値を1つのオブジェクトとして扱います。

AmountType price;
...
price.setValue(123.00);
price.setCurrencyCode("USD");

概要エディタの「属性」ページを使用して、カスタマイズするサービス・タイプのビュー・オブジェクト属性を選択します。 概要エディタの「属性」ページから表示される「属性の編集」ダイアログを使用して、選択した属性のSDOプロパティを関連付け、事前定義済の複合サービス・タイプを選択します。

作業を始める前に、次のようにします。

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。

次のタスクを完了します。

1. 5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。

2. 11.2.4項「個別のビュー・オブジェクトのサービス対応化の方法」に記載されている方法に従って、該当するビュー・オブジェクトをサービス対応にします。

サービス対応ビュー・オブジェクト内のSDOプロパティを関連付ける手順:

1. アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで別なSDOプロパティに関連付けるプロパティに対応する属性を選択し、「選択した属性の編集」ボタンをクリックします。

   選択する属性は、数値型を定義する必要があります。たとえば、通貨コードを、顧客が支払った金額を表示する属性と関連付けるには、Ordersサービス対応ビュー・オブジェクトのOrderTotal属性を選択します。

4. 「属性の編集」ダイアログの「ビュー属性」ページで、該当するXSD型を選択します。

   「XSDタイプ」フィールドが有効でない場合は、概要エディタに戻って数値型の属性を選択します。値が数値型ではない属性を、使用可能な複合サービス・タイプに関連付けることはできません。

   SDOフレームワークは、複合サービス・タイプ、AmountTypeおよびMeasureTypeをサポートしています。関連付けるプロパティが通貨情報を指定する場合は、AmountTypeを選択します。関連するプロパティが測定単位を指定する場合は、MeasureTypeを選択します。

5. currencyCodeまたはunitCodeドロップダウン・リストで、ビュー・オブジェクト属性を選択して複合型を定義します。

   ダイアログが切り替わり、XSDタイプの選択に応じたドロップダウン・リストが表示されます。ビュー・オブジェクトが定義している任意の数値属性を選択できます。

6. 「OK」をクリックします。

11.2.6 サービス対応マスター/ディテール・ビュー・オブジェクトにおけるネスト処理のサポート方法

データ・モデルで親子間のマスター/ディテール関係を定義した場合、マスター・ビュー・オブジェクトに対して有効化するサービス操作は、詳細なビュー・オブジェクトでは自動的に実行されません。サービス・インタフェース内でこれらのメソッドのネスト処理サポートを有効化する必要があります。

• 親と一緒に子の詳細も入手する取得および検索メソッドをサポートするには、マスターおよびディテール・ビュー・オブジェクト間のビュー・リンクでリンク先アクセッサを生成しておく必要があります。リンク先アクセッサでにより、マスターから詳細なビュー・オブジェクトまでの階層が通過できます。

• 親と一緒に子の詳細もポストする作成/マージ/更新/処理メソッドをサポートするには、次の2つの状況のうちいずれかで、カスタム・プロパティSERVICE_PROCESS_CHILDRENを定義する必要があります。

  • ビュー・リンクがアソシエーションに基づいており、アソシエーションにリンク先アクセッサが生成されており、アソシエーションにカスタム・プロパティSERVICE_PROCESS_CHILDREN=trueが定義されている場合。

  • ビュー・リンクはアソシエーションに基づいていないが、カスタム・プロパティSERVICE_PROCESS_CHILDREN=trueが定義されている場合。

  通常、ディテール・ビュー・オブジェクトに対するポスト操作は、マスター・ビュー・オブジェクトのプライマリ・エンティティ・オブジェクトがディテール・ビュー・オブジェクトのプライマリ・エンティティ・オブジェクトで構成されている場合にのみサポートされます。カスタム・プロパティは、ビュー・リンクが定義された任意のビュー・オブジェクトのネスト処理を簡単にサポートするための代替手段を提供します。概要エディタでSERVICE_PROCESS_CHILDRENを、ビュー・リンクまたはビュー・リンクのアソシエーション(存在する場合)のカスタム・プロパティとして定義できます。

作業を始める前に、次のようにします。

1. 該当するビュー・オブジェクトを作成し、11.2.4項「個別のビュー・オブジェクトのサービス対応化の方法」に記載されている方法で、マスター/ディテール階層の子ビュー・オブジェクトをサービス対応にします。

2. ビュー・リンクがアソシエーションに基づいていない場合は、概要エディタでビュー・リンクを開き、「関係」ページを表示して、そのビュー・リンクのリンク先アクセッサがあることを確認します。アクセッサを生成し、「関係」ページに表示させるには、「アクセッサの編集」ボタンをクリックし、「ビュー・リンク」ダイアログ内でリンク先アクセッサに対してビュー・オブジェクトでアクセッサを作成を選択します。ビュー・リンクの詳細は、5.6項「マスター/ディテール階層における複数表の使用」を参照してください。

   ビュー・リンクがアソシエーションに基づいている場合は、アソシエーションのリンク先のエンティティ・オブジェクトに対して、リンク先アクセッサが存在している必要があります。リンク先アクセッサを作成するには、アソシエーションの概要エディタの「関連」ページを使用します。アソシエーションの詳細は、4.3項「アソシエーションの作成および構成」を参照してください。

マスター/ディテール階層でのネスト処理のサポート手順:

1. マスター/ディテール階層のビュー・リンクがアソシエーションに基づいていない場合は、アプリケーション・ナビゲータで、ビュー・リンクをダブルクリックします。ビューがアソシエーションに基づいている場合は、アプリケーション・ナビゲータ内でアソシエーションをダブルクリックします。

   概要エディタの「関係」ページで、ビュー・リンクの作成方法を確認できます。「属性」セクションで、リンク元とリンク先の属性名を指定します。リンクがアソシエーションに基づいている場合は、属性ハイパーリンクにアソシエーション名が含まれます。それ以外の場合は、ハイパーリンクに基本エンティティ・オブジェクトの名前が含まれます。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックします。

   ビュー・リンクの概要エディタとアソシエーションの両方に、同じ選択内容が表示されます。

3. 「一般」ページの「カスタム・プロパティ」セクションを展開し、「カスタム・プロパティの追加」をクリックして、プロパティにSERVICE_PROCESS_CHILDRENを、プロパティ値にtrueを入力します(図11-8を参照)。

   図11-8 ネスト処理をサポートするカスタム・プロパティ

   
   

11.2.7 SDOクラス作成時の処理

SDOクラスを作成すると、次のファイルが生成され、アプリケーション・ナビゲータ内の所有ビュー・オブジェクトの下に表示されます。

• サービス・データ・オブジェクト・インタフェース

• サービス・データ・オブジェクト・クラス

• サービス・データ・スキーマ・ファイル

• サービス・データ・オブジェクト結果クラスとインタフェースは、「Javaオプションの選択」ダイアログで「警告のサポート」を有効化すると生成されます。

11.2.7.1 サービス・データ・オブジェクト・クラス

ビュー・オブジェクトSDOインタフェースには、SDOプロパティに対して強い型定義が行われたアクセッサが含まれています(例11-4を参照)。

例11-4 SDOプロパティに対する強い型定義が行われたアクセッサを含むSDOインタフェース

package oracle.fodemo.storefront.store.queries.common;
  public interface AddressesVOSDO {
  public java.math.BigInteger getAddressId();
  public void setAddressId(java.math.BigInteger value);
...}

11.2.7.2 サービス・データ・オブジェクト・クラス

ビュー・オブジェクトSDOクラスはビュー・オブジェクトSDOインタフェースを実装し、OracleによるSDO仕様の実装であるSDODataObjectクラスを拡張します。

実行時は、SDOオブジェクトのインスタンスはメモリー内の行を示します。

SDOクラスはビュー行クラスと類似しています(例11-5を参照)。

例11-5 SDOクラスによるビュー・オブジェクトSDOインタフェースの実装

package oracle.fodemo.storefront.store.queries.common;
import commonj.sdo.Type;
import oracle.sdo.SDODataObject;
public class AddressesVOSDOImpl extends SDODataObject implements AddressesVOSDO 
  {
  ...
  }

11.2.7.3 サービス・データ・オブジェクト・スキーマ・ファイル

図11-13に示すようなビュー・オブジェクトSDOスキーマ・ファイルは、SDOスキーマを示すXMLスキーマ・ファイルです。

図11-9 生成されたSDOスキーマ

11.2.7.4 サービス・データ・オブジェクト結果クラスとインタフェース

ビュー・オブジェクトSDO結果クラスは、サービス・メソッドがビュー行のリスト(サービス・データ・オブジェクトでラップされた)およびこれらのビュー行に関付けられた警告リストを戻せるようにするコンテナ・オブジェクトです。生成されたメソッド結果インタフェースを使用して、警告および例外を抽出できます。サービス対応ビュー・オブジェクトが、ADFビジネス・コンポーネント例外 (JboExceptionオブジェクト)ではなく、サービス例外をスローする点に注意してください。これを修正するために、サービス・インタフェース・アダプタは可能であればServiceExceptionをJboExceptionに構成しなおそうとします。

例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);
   }
}

11.2.8 必須バインド変数による宣言的検索操作の公開方法

ADFサービス・インタフェース・フレームワークにより、宣言的検索操作を公開して、選択したビュー・オブジェクトによる問合せ定義を行えます。ただし、その問合せがバインド変数を使用して問合せ結果をフィルタしている場合は、バインド変数を「必須」および「更新可能」として指定する必要があります。サービス・インタフェースは必須の更新可能バインド変数を公開しないので、この種のビュー・オブジェクトに対して実行する検索操作では、結果が戻されません。

バインド変数を使用して問合せ結果をフィルタする場合は、ビュー基準を使用して、サービス・インタフェース上での検索操作として公開します。作成するビュー基準に基づくサービス・インタフェースの検索操作には、必須バインド変数を指定できます。

作業を始める前に、次のようにします。

1. 9.2.1項「アプリケーション・モジュールの作成方法」に記載されている方法に従って、該当するアプリケーション・モジュールを作成します。

2. 5.11.1項「名前付きビュー基準を宣言的に作成する方法」 に記載されている説明に従って、ビュー基準を作成します。「ビュー基準の編集」ダイアログで、基準項目をバインド変数として設定し、「検証」フィールドを「必須」に設定します。このような選択によって、有効な値がなければ問合せが実行されなくなります。

必須バインド変数のあるビュー基準に対して検索操作を公開する手順:

1. アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「サービス・インタフェース」のナビゲーション・タブをクリックして、「サービス・インタフェースの属性を編集」ボタンをクリックします。

   サービス・インタフェースを定義済の場合は、かわりに「サービス・カスタム・メソッドの編集」を選択することもできます。

3. 「サービス・インタフェースの編集」で、ナビゲーション・リストから「サービス・ビュー・インスタンス」を選択し、名前付きのビュー基準でフィルタするビュー・オブジェクトを「選択済」リストに追加します。

4. 検索操作を公開するには、ビュー・インスタンスを選択し、「ビュー基準の検索操作」タブをクリックし、「ビュー基準の追加」ボタンをクリックします。

5. 「ビュー基準検索操作の構成」ダイアログで、検索操作用の名前付きビュー基準を選択します。

   ダイアログには、選択したビュー基準のバインド標準が表示されます。

6. XML名をダブルクリックしてサービスのXML定義で表示されるバインド変数名をカスタマイズできます。

7. 「OK」をクリックします。

11.2.9 必須バインド変数でフィルタするカスタム検索メソッドの公開方法

ビュー基準に依存する宣言的検索操作を公開するかわりに、データ・モデル・プロジェクトのアプリケーション・モジュール実装クラス内でサービス・メソッドを定義できます。この目的で作成するクラスでは、ビジネス・サービス機能を、実装する単一メソッドにカプセル化できます。カスタム・アプリケーション・モジュールの目的の詳細は、9.7項「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」を参照してください。

例11-7は、AppModuleNameImpl.javaファイルで実装されているカスタム検索メソッドを示します。このメソッドは、バインド変数を設定し、ビュー・オブジェクト・インスタンス問合せを行います。ビュー・オブジェクト・インスタンス上でsetNamedWhereClauseParam()を使用して、バインド変数を設定します。問合せ実行前に、検索メソッドが前方のみモードでビュー・オブジェクトを設定し、検索メソッドが繰り返し処理するビュー行のキャッシングを行わないようにします。問合せ結果のプログラミングによるフィルタの詳細は、5.10.5項「実行時に名前付きバインド変数を使用してWHERE句を追加する方法」を参照してください。

例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;
   }
}

作業を始める前に、次のようにします。

9.7.1項「アプリケーション・モジュールのカスタム・クラスの生成方法」に記載されている方法に従って、カスタム・アプリケーション・モジュール・クラスを作成します。

必須バインド変数を設定する検索メソッドの公開手順:

1. アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「サービス・インタフェース」のナビゲーション・タブをクリックして、「サービス・インタフェースの属性を編集」ボタンをクリックします。

   サービス・インタフェースを定義済の場合は、かわりに「サービス・カスタム・メソッドの編集」を選択することもできます。

3. 「サービス・インタフェースの編集」で、ナビゲーション・リストから「サービス・ビュー・インスタンス」を選択し、名前付きのビュー基準でフィルタするビュー・オブジェクトを「選択済」リストに追加します。

4. 検索操作を公開するには、ビュー・インスタンスを選択し、続いて「ビュー基準の検索操作」タブを選択し、「ビュー基準の追加」アイコンをクリックします。

5. 「OK」をクリックします。

11.2.10 非同期のWebサービス・メソッドの生成方法

デフォルトでは、Webサービスは同期サービス・メソッドをサポートしています。これによってクライアント・アプリケーションを強制的に起動して待機させ、レスポンスが返されるまで作業を続行できません。レスポンスがすぐに返される場合は、このWebサービスの起動方法が一般的です。しかし、リクエスト処理が遅延する場合もあるため、クライアント・アプリケーションは先に処理を続行し、後でレスポンスを処理するほうが効率的なことも少なくありません。

非同期のリクエスト-レスポンスを使用したWebサービス起動の詳細は、『Oracle Fusion Middleware Oracle Infrastructure Webサービス・コンセプト・ガイド』を参照してください。

非同期Webサービスをデプロイする前に、リクエストおよびレスポンスを格納するためのキューを構成する必要があります。リクエストおよびレスポンス・キューの構成の詳細は、『Oracle Fusion Middleware Oracle Infrastructure Webサービス・コンセプト・ガイド』を参照してください。

作業を始める前に、次のようにします。

9.2.1項「アプリケーション・モジュールの作成方法」に記載されている方法に従って、該当するアプリケーション・モジュールを作成します。

非同期Webサービス・メソッドの公開手順:

1. アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「サービス・インタフェース」のナビゲーション・タブをクリックして、「サービス・インタフェースの属性を編集」ボタンをクリックします。

3. 「サービス・インタフェースの編集」ダイアログで、「非同期Webサービス・メソッドの生成」を選択します。

4. 「OK」をクリックします。

11.2.11 非同期サービス・メソッド生成時の処理

JDeveloperはサービスの共通インタフェースを生成し、非同期サービス操作を有効にします。例11-8に示すように、クラスの注釈@AsyncWebServiceはEmpServiceサービス・インタフェースを非同期と宣言し、インタフェース内の各同期メソッドに対して、サービスが同じメソッド名に「Async」が付加された非同期メソッドを公開します。

同じインタフェース内で同期および非同期の両方のメソッドを公開することで、Webサービス・クライアント開発者は、Webサービス・プロキシによる操作(適切な名前が付いたメソッドのコール)の起動方法を決定できます。開発者は、ADFビジネス・コンポーネント・サービス・プロキシで直接非同期メソッドを起動してはならない点に注意してください。

この例では、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);
   }
}

11.2.12 実行時の非同期コール時の処理

クライアントから見ると、非同期コールは一方向の2つのメッセージ交換から構成されます。図11-10のシーケンス図は、次のフローを示しています。

1. クライアントが非同期操作をコールします。(図中のステップ1。)

2. 非同期サービスはリクエストを受信し、リクエストを実際には処理せずに、HTTP確認をクライアントに戻します。(図中のステップ2。)

3. 最終的には非同期操作が完了し、サーバー側のモジュールがレスポンスをクライアント側に送信します。(図中のステップ3。)

   クライアント側でレスポンスを受信するには、クライアントにサーブレットまたはWebサービスなど、なんらかのHTTPリスナーが必要です。

4. クライアント側で生成されたWebサービス(コールバック・サービス)が、非同期レスポンスを受信します。(図中のステップ4。)

   ステップ3ではサーバー側のモジュールが、コールバック・サービスに対してクライアントのように機能するので、コールバック・クライアントと呼ばれます。

図11-10 非同期コール・シーケンス

11.2.13 サービス・インタフェース生成用プリファレンスの設定方法

JDeveloperで生成されたサービスに対しては、追加のコントロールが可能です。生成されたSDOクラスの名前にデフォルトの接尾辞を使用して、サービス共通インタフェースおよびクラスが保存されるデフォルト・サブパッケージを変更するように、JDeveloperプリファレンスを設定できます。

SDOクラス名接尾辞の設定手順:

1. メイン・メニューから、「ツール」→「プリファレンス」を選択します。

2. 「プリファレンス」ダイアログで、「ビジネス・コンポーネント」ノードを展開し、「クラス・ネーミング」を選択します。

3. 「ビュー・オブジェクト」接尾辞リストに、たとえばSDOのような、SDOの接尾辞を入力します。

生成されたサービス・インタフェースにデフォルト・サブパッケージを設定する手順:

1. メイン・メニューから、「ツール」→「プリファレンス」を選択します。

2. 「プリファレンス」ダイアログで、「ADFビジネス・コンポーネント」 を展開し、「パッケージ」を選択します。

3. 「クラスに対する関連パッケージの指定」リストで、デフォルト・パッケージ名を指定します。

   • サービス・インタフェース・パッケージ名を設定するには、「クライアント・インタフェース」に値を入力します。(「サービス・インタフェース」に、クライアント・インタフェースに指定したのと同じパッケージ名が表示されます)。デフォルト・パッケージ名はcommonです。

   • 「サービス・インタフェース」の「サービス・インタフェース・サブパッケージ」に値を入力します。デフォルトのサブパッケージ名はserviceinterfaceです。

   たとえば「サービス・インタフェース」にcommon、「サービス・インタフェース・サブパッケージ」にserviceinterface(デフォルト)を入力すると、データ・モデル・パッケージoracle.storefront.store.service内のデータ・モデル・コンポーネントのサービス・インタフェースが、サブパッケージoracle.storefront.store.service.common.serviceinterfaceに配置されます。

生成されるSDOスキーマとWebサービスのデフォルト・ネームスペース接頭辞を設定するには:

1. メイン・メニューから、「ツール」→「プリファレンス」を選択します。

2. 「プリファレンス」ダイアログで、「ビジネス・コンポーネント」ノードを展開し、「ビュー・オブジェクト」を選択します。

3. 「サービス・データ・オブジェクト・ネームスペース接頭辞」の値を入力し、生成されるSDOスキーマとWebサービスの冒頭に追加されるようにします。たとえば、http://example.com/などです。

11.2.14 SOAPクライアント用Webサービスのセキュリティ保護方法

実行時、Webサービス・クライアントはSOAPプロトコルを使用して、アプリケーション・モジュールのサービス対応メソッドを起動します。Oracle Web Service Manager (Oracle WSM)セキュリティ・ポリシーの構成によって、サービスの認証と許可を有効化できます。選択するセキュリティ・ポリシーでは、SOAPクライアント・コールによってSOAPヘッダーの一部として資格証明(SAMLトークン)を提供する必要があります。たとえば受信するSOAPリクエストなどに対するメッセージ保護(整合性および機密保護)を有効化するその他のポリシーも構成できます。Oracle WSMがサポートしている事前定義済ポリシーの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

11.2.14.1 SOAPクライアント認証の有効化

認証を有効にして、サービス・インタフェース上のサービス・メソッドへのアクセス前に、ユーザーに資格証明の提供を求めることができます。必要な認証タイプは、Oracle WSM認証ポリシーを使用しているリモート・サーバー・クラスで構成します。使用可能な認証ポリシーの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

認証ポリシーの構成手順:

1. アプリケーション・ナビゲータでアプリケーション・モジュールを展開し、serviceinterfaceフォルダを開き、リモート・サーバー・クラス(AppModuleServiceImpl.javaファイル)をダブルクリックします。

   Fusion Order DemoのStoreFrontModuleアプリケーションのStoreServiceAMアプリケーション・モジュールから生成されるWebサービスでは、リモート・サーバー・クラスはStoreFrontServiceImpl.javaです。

2. リモート・サーバー・クラスのソースで、@PortableWebServiceという注釈の上にカーソルを置きます。

   たとえば、StoreFrontService.wsdlでは、サービスの注釈が次のように表示されます。

   ...
   @PortableWebService(targetNamespace="www.globalcompany.example.com",
       serviceName="StoreFrontService", portName="StoreFrontServiceSoapHttpPort",    endpointInterface=
          "oracle.fodemo.storefront...common.serviceinterface.StoreFrontService")
   ...
   

3. プロパティ・インスペクタを開いてWebサービス拡張セクションを展開し、Oracle WSMポリシーの「セキュリティ」フィールドの横にある省略記号ボタンをクリックします。

4. 「プロパティの編集」の「セキュリティ」ダイアログで、該当する認証セキュリティ・ポリシーを選択して「OK」をクリックします。

   Oracle WSMがサポートしている使用可能なセキュリティ・ポリシーの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

5. ソース・ファイルに戻り、新しい注釈@SecurityPolicyが追加されたことを確認します。

   リモート・サーバー・クラスに対して定義した@SecurityPolicyという注釈は、潜在的なクライアントに対するセキュリティ要件を指定します。たとえばダイアログでoracle/wss_username_token_service_policyを選択した場合、次の@SecurityPolicyという注釈が@PortableWebServiceという注釈の下に現れます。

   ...
   @PortableWebService(targetNamespace="www.globalcompany.example.com",
       serviceName="StoreFrontService", 
       portName="StoreFrontServiceSoapHttpPort",    endpointInterface=
       "oracle.fodemo.storefront.store.service.common.serviceinterface.StoreFrontService")
   @SecurityPolicy( { "oracle/wss_username_token_service_policy" })
   ...
   

   サービスに対するメソッド起動のために十分なアクセス権をユーザーに求める許可ポリシー構成の詳細は、11.2.14.2項「SOAPクライアント許可の有効化」を参照してください。

6. リモート・サーバー・クラス・ファイルを保存します。

11.2.14.2 SOAPクライアント許可の有効化

権限チェックを有効化し、十分な権限を持つユーザーだけに、サービス・インタフェース上のサービス・メソッド起動を許可できます。このOracle Web Services Manager (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サービスのためのセキュリティおよび管理者ガイド』を参照してください。

作業を始める前に、次のようにします。

1. 11.2.14.1項「SOAPクライアント認証の有効化」の説明に従って、サービスの認証ポリシーを構成します。

2. 11.2.16項「サービスへのアクセスをテスト・ユーザーに許可する方法」の説明に従って、ユーザーにサービスへのアクセスを許可します。

権限ベースの許可ポリシーの構成手順:

1. アプリケーション・ナビゲータでアプリケーション・モジュールを展開し、serviceinterfaceフォルダを開き、リモート・サーバー・クラス(AppModuleServiceImpl.javaファイル)をダブルクリックします。

   Fusion Order DemoのStoreFrontModuleアプリケーションのStoreServiceAMアプリケーション・モジュールから生成されるWebサービスでは、リモート・サーバー・クラスはStoreFrontServiceImpl.javaです。

2. リモート・サーバー・クラスのソースで、@PortableWebServiceという注釈の上にカーソルを置きます。

   たとえば、StoreFrontService.wsdlでは、サービスの注釈が次のように表示されます。

   ...
   @PortableWebService(targetNamespace="www.globalcompany.example.com",
       serviceName="StoreFrontService", 
       portName="StoreFrontServiceSoapHttpPort",
       endpointInterface=
          "oracle.fodemo.storefront...common.serviceinterface.StoreFrontService")
   ...
   

3. プロパティ・インスペクタを開いてWebサービス拡張セクションを展開し、Oracle WSMポリシーの「セキュリティ」フィールドの横にある省略記号ボタンをクリックします。

4. 「プロパティの編集」の「セキュリティ」ダイアログで、認証セキュリティ・ポリシーを選択して「OK」をクリックします。

   Oracle WSMがサポートしているセキュリティ・ポリシーの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

5. ソース・ファイルに戻り、注釈@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" })
   ...
   

   サービスへのアクセスのために資格証明をクライアントに求める認証ポリシー構成の詳細は、11.2.14.1項「SOAPクライアント認証の有効化」を参照してください。

6. リモート・サーバー・クラス・ファイルを保存します。

11.2.15 RMIクライアント用Webサービスのセキュリティ保護方法

ADF WebサービスはEJBとして実装され、Oracle WebLogic Server上でOracle Web ServiceのPortableWebServiceとしてデプロイされるので、クライアント・アプリケーションは、RMIプロトコルを使用してアプリケーション・モジュールのサービス対応メソッドを起動できます。

11.2.15.1 RMIクライアント認証の有効化

RMIを使用してADFサービスを起動すると、共通のJAASログイン・モジュールによって認証が処理されます。ログイン・モジュールは、コール元のアプリケーションでEJBの当初のJNDIコンテキストの一部として、プリンシパルおよび資格証明を受け取ります。JNDIコンテキスト・プロパティを定義しなかった場合、ログイン・モジュールはコール元の現在のセキュリティ・コンテキストを取得しようとします。

リモートJNDIコンテキスト情報を定義した場合、次の4つのJNDIコンテキスト・プロパティをconnections.xmlファイルに追加する必要があります。

注意: Integrated WebLogic Serverを使用してJDeveloperでサービスのテストを行う場合、サービスのデプロイ前に、connections.xmlファイルで直接JNDIコンテキスト・プロパティを編集できます。ただし、スタンドアロンOracle WebLogic Serverにサービスをデプロイする場合は、Oracle Enterprise Managerを使用してJNDIコンテキスト・プロパティを構成します。

• 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を使用する必要があります。

認証処理用にJNDIコンテキスト・プロパティを構成する手順:

1. アプリケーション・ナビゲータの「アプリケーション・リソース」パネルで、DescriptorsおよびADF META-INFフォルダを展開し、connections.xmlファイルをダブルクリックします。

2. ソース・エディタの場合は、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>
   

3. ファイルを保存します。

11.2.15.2 RMIクライアント許可の有効化

権限チェックを有効化し、十分な権限を持つユーザーだけに、サービス・インタフェース上のサービス・メソッド起動を許可できます。権限チェックを有効にするために、ADF Webサービス・フレームワークはServicePermissionCheckInterceptorという名前のEJBインターセプタを提供しています。このEJBインターセプタにより、実行時に権限チェックが確実に実行されます。現在、インターセプタはOracle Web Services Manager (Oracle WSM)許可ポリシーbinding_permission_authorization_policyを使用するように構成されています。この種の許可ポリシーの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

作業を始める前に、次のようにします。

1. 11.2.15.1項「RMIクライアント認証の有効化」の説明に従って、クライアント・アプリケーション(サービスを起動するアプリケーション)のconnections.xmlファイルで、サービスの認証ポリシーを構成します。

2. 11.2.16項「サービスへのアクセスをテスト・ユーザーに許可する方法」の説明に従って、ユーザーにサービスへのアクセスを許可します。

権限ベースの許可ポリシーの構成手順:

1. アプリケーション・ナビゲータでWebサービス・プロジェクトのMETA-INFフォルダを展開し、ejb-jar.xmlファイルをダブルクリックします。

2. ソース・エディタで、アプリケーションのロール評価のための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>
   

3. アプリケーション・ナビゲータでアプリケーション・モジュールを展開し、serviceinterfaceフォルダを開き、リモート・サーバー・クラス・ファイル(AppModuleServiceImpl.java)をダブルクリックします。

4. ソース・エディタで注釈セクションの最後にカーソルを配置し、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})
   

5. ファイルを保存します。

11.2.16 サービスへのアクセスをテスト・ユーザーに許可する方法

サービスの許可ポリシーを構成後、Oracle Platform Security Services (OPSS)セキュリティ・プロバイダを構成して、サービスにメソッドを起動できるユーザーを指定する必要があります。設計時にjazn-data.xml構成ファイルを編集して、アプリケーション・ロールの作成と該当するアプリケーション・ロールへの起動権限許可を行うことでこのタスクを実行します。その後サービスをデプロイする際には、ターゲットOracle WebLogic Serverの管理者が、指定したアプリケーション・ロールをエンタープライズ・ユーザーに関連付けます。これによって、サービス・メソッドの起動権利を、そのアプリケーション・ロールのメンバーである任意のユーザーに付与できます。起動権限が付与されていないロール・メンバーであるユーザーは、サービス・メソッドへのアクセスを拒否されます。OPSSセキュリティ・プロバイダおよびアプリケーション・ロールの詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。

Integrated WebLogic Serverでのアプリケーション実行用に使用可能なテスト・ユーザーにjazn-data.xmlファイルを構成する場合は、30.6項「テスト・ユーザーの作成」を参照してください。

Oracle Web Servicesの起動権限は、oracle.wsm.security.WSFunctionPermissionクラスで定義されています。サービスの全メソッドまたは個別のメソッドに対して、定義するアプリケーション・ロールの権限を付与できます。

作業を始める前に、次のようにします。

1. 11.2.14項「SOAPクライアント用Webサービスのセキュリティ保護方法」または11.2.15項「RMIクライアント用Webサービスのセキュリティ保護方法」の説明に従って、認証および許可ポリシーを構成します。

2. JDeveloperオンライン・ヘルプのアプリケーションのデプロイに関するセクションにある「デプロイメント・ディスクリプタの作成と編集」の説明に従って、jazn-data.xmlデプロイメント記述子を作成して、OPSSセキュリティ・プロバイダ構成ファイルをプロジェクトに追加します。

   JDeveloper内の「新規ギャラリ」を開いて「一般」を展開し、「デプロイメント・ディスクリプタ」→「Oracleデプロイメント・ディスクリプタ」を選択して、「OK」をクリックします。

3. 30.4項「アプリケーション・ロールの作成」の説明に従って、該当するアプリケーション・ロールを作成します。

4. JDeveloperでWebサービスをテストするために、30.6項「テスト・ユーザーの作成」の説明に従って、テスト・ユーザーにアプリケーション・ロールを付与できます。

jazn-data.xmlファイルでアプリケーション・ロールへのWebサービス権限を付与する手順:

1. 「アプリケーション」メニューから、「保護」→「ADFポリシー」を選択します。

   この手順を開始する前に、30.4項「アプリケーション・ロールの作成」の説明に従って、付与するアプリケーション・ロールを作成する必要があります。JDeveloperでテストする場合は、30.6項「テスト・ユーザーの作成」の説明に従って、テスト・ユーザーにアプリケーション・ロールを付与することもできます。

2. jazn-data.xmlファイルのエディタ・ウィンドウで、Sourceタブを選択します。

3. jazn-data.xmlファイルのソースで、<policy-store>要素を展開し、アプリケーション用に定義済のすべてのADFセキュリティ・ポリシーを表示します。

   現在、このリリースではアプリケーション・セキュリティ・ポリシー作成用のエディタが提供されていません。jazn-data.xmlファイルのソースで、ポリシーを手動で作成する必要があります。

4. <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ファイルをダブルクリックし、nameおよびtargetNamespace定義を表示します。

   
   

   たとえば、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を定義します。

5. jazn-data.xmlファイルに変更を保存します。

11.2.17 SOAPクライアント用バイナリ添付サポートの有効化の方法

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に対して機能する必要があります。

バイナリ・データ添付の送信サポートを有効化する手順:

1. アプリケーション・ナビゲータでアプリケーション・モジュールを展開し、serviceinterfaceフォルダを開き、リモート・サーバー・クラス・ファイル(AppModuleServiceImpl.java)をダブルクリックします。

   Fusion Order DemoのStoreFrontModuleアプリケーションのStoreServiceAMアプリケーション・モジュールから生成されるWebサービスでは、リモート・サーバー・クラスはStoreFrontServiceImpl.javaです。

2. リモート・サーバー・クラスのソースで、注釈セクションの任意の場所にカーソルを置きます。

   たとえば、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")
   ...
   

3. プロパティ・インスペクタを開き、「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
   ...
   

11.2.18 Integrated WebLogic Serverを使用したWebサービスのテスト方法

Integrated WebLogic Serverを使用して、JDeveloperでWebサービスを実行できます。Oracle WebLogic ServerにWebサービスをデプロイして、サービスをテストすることもできます。

Integrated WebLogic Serverを使用した実行とテストの手順:

1. アプリケーション・ナビゲータでアプリケーション・モジュールを展開し、serviceinterfaceフォルダを開き、リモート・サーバー・クラス・ファイル(AppModuleServiceImpl.java)を選択します。

   Fusion Order DemoのStoreFrontModuleアプリケーションのStoreServiceAMアプリケーション・モジュールから生成されるWebサービスでは、リモート・サーバー・クラスはStoreFrontServiceImpl.javaです。

2. リモート・サーバー・クラス・ファイルを右クリックして、「実行」または「デバッグ」を選択します。

   アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの構成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

   JDeveloperがサーバー・インスタンスを初期化し、アプリケーションをデプロイしてWebサービスを開始します。この間、これらプロセスからの出力が「ログ」ウィンドウの「実行中」タブに表示されます。Webサービスの開始後、ターゲットURLも「ログ」ウィンドウに表示されます。

3. 「ログ」ウィンドウからターゲットURL(http://で始まる)をコピーします。

4. Webブラウザを起動し、「ログ」ウィンドウからコピーしたエンドポイントのURLをブラウザのアドレス・フィールドにペーストして、サービス名を付加し、HTTPリクエストを発行します。

   「ログ」ウィンドウにはたとえば次が表示されます。

   http://130.35.103.93:8888/ADFServiceDemo-ADFModel-context-root

   そしてサービス名はAppModuleServiceで、ターゲットURLは次のようになります。

   http://130.35.103.93:8888/ADFServiceDemo-ADFModel-context-root/AppModuleService

5. テスト・ページで、起動する操作を「操作」ドロップダウン・メニューから選択し、パラメータ・フィールドにサンプル・データを入力します。

6. 準備ができたら、「起動」を押して操作を発行し、「テスト結果」ページで操作結果を確認します。

   「テスト結果」ページには、操作で戻された情報のXML Soap形式が表示されます。

11.2.19 カスタム・サービス・メソッドのタイムアウトの防止方法

Webサービスをテストすると、一部のカスタム・メソッドがJava Transaction API (JTA)で設定されたタイムアウト制限を超えていることに気付く場合があります。JTAタイムアウト設定では、サービス・メソッドの実行制限時間をデフォルトでは30秒以内に設定しています。Oracle WebLogic Server管理コンソールを使用して、JTAタイムアウト設定を延長できます。それでもタイムアウト例外を受信する場合や、サービス・インタフェースのカスタム・メソッドの実行に長時間かかることが予想される場合は、ステートレス・セッションBean用のEJBトランザクション属性を指定して、EJBがJTAトランザクションでこれらのメソッドを実行しないようにします。

カスタム・メソッドをタイムアウト制限から除外するには、そのメソッドのプロパティ・インスペクタでTransactionAttributeType.NOT_SUPPORTEDを設定します。このトランザクション属性が設定されたメソッドはJTAトランザクションでは実行されないため、oracle.jbo.ApplicationModule and oracle.jbo.TransactionインタフェースのADFビジネス・コンポーネント・メソッドを使用して各自でトランザクションの制御を行う必要があります。たとえば、サービス対応にしたアプリケーション・モジュールの実装クラスのメソッドでは、am.getDBTransaction().commit()またはrollback()をコールして、トランザクションを完了する必要があります。

サービス・インタフェース用に生成した標準サービス・メソッドのデフォルト・トランザクション属性設定は、変更しないでください(表11-1を参照)。標準メソッドは、JTAトランザクション用に設定されたデフォルト実行境界内で実行されます。

カスタム・メソッドがJTAトランザクションで実行されないようにする手順:

1. アプリケーション・ナビゲータでアプリケーション・モジュールを展開し、serviceinterfaceフォルダを開き、リモート・サーバー・クラス・ファイル(AppModuleServiceImpl.java)をダブルクリックします。

   Fusion Order DemoのStoreFrontModuleアプリケーションのStoreServiceAMアプリケーション・モジュールから生成されるWebサービスでは、リモート・サーバー・クラスはStoreFrontServiceImpl.javaです。

2. ソース・エディタで、タイムアウトさせたくないカスタム・メソッドを検索して、そのメソッド上にカーソルを置きます。

3. プロパティ・インスペクタで「ステートレス・セッションBean」を展開し、TransactionAttributeドロップダウン・メニューからTransactionAttributeType.NOT_SUPPORTEDを選択します。

   JDeveloperは注釈@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)を追加して、メソッドを更新します。

   たとえば、カスタム・サービス・メソッドupdateCustomerInterests()では、次のようになります。

   @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
   public void updateCustomerInterests(List<String> pCategoryIds) throws
                                                          ServiceException {
           invokeCustom((Method) _map.get("updateCustomerInterests"), 
                new Object[] { pCategoryIds }, new String[] { null }, false);
   }
   

4. リモート・サーバー・クラスを保存します。

5. アプリケーション・ナビゲータで、アプリケーション・モジュール実装クラス(AppModuleImpl.java)のファイルをダブルクリックします。

   この実装クラスはサービス・インタフェースで公開されるカスタム・メソッドを定義します。Fusion Order Demoでは、アプリケーション・モジュール実装クラスはStoreServiceAMImpl.javaです。

6. ソース・エディタで、TransactionAttributeプロパティを設定したサービス・メソッドを実装するカスタム・メソッドに、トランザクションのコミットとロールバックを行うカスタム・コードを追加します。

   たとえば、updateCustomerInterests()という名前のサービス・メソッドにTransactionAttributeプロパティを構成した場合、アプリケーション・モジュールの実装クラスを開き、カスタム・メソッドupdateCustomerInterests()を検索して、am.getDBTransaction().commit()およびrollback()をメソッドのtryおよびcatch文に次のように追加します。

   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;
        }
   }
   

7. アプリケーション・モジュール実装クラスを保存します。

11.2.20 Oracle WebLogic ServerへのWebサービスのデプロイ方法

たとえば、サービスのテストの第2段階を実行するために、Oracle WebLogic ServerにWebサービスをデプロイすることができます。Webサービスのデプロイ手順は、Webサービスに対して許可を有効化しているかどうかによって異なります。許可を有効化している場合は、パッケージされたアプリケーションのEARファイル内で、web.xmlファイルの変更前の手順を実行する必要があります。11.2.14.2項「SOAPクライアント許可の有効化」の説明に従って許可を有効化している場合にのみ、この手順が必要になります。

注意: この項で説明している手順に従って、許可が有効化されたWebサービス用にパッケージされているEARファイルのweb.xmlを変更してください。ただし、EARファイルのデプロイにJDeveloperを使用すると、ターゲット・サーバーのweb.xmlファイルに上書きしてしまうので、JDeveloperは使用しないでください。Oracle WebLogic Server管理コンソールなどのツールを使用して、パッケージされたアプリケーションのEARファイルを手動でデプロイします。JDeveloper以外でのセキュアWebサービス・アプリケーションのデプロイの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

作業を始める前に、次のようにします。

1. 非同期Webサービスを作成した場合は、サービスのデプロイ前に、リクエストおよびレスポンスを格納するためのキューを構成する必要があります。リクエストおよびレスポンス・キューの構成の詳細は、『Oracle Fusion Middleware Oracle Infrastructure Webサービス・コンセプト・ガイド』を参照してください。

2. 11.2.14.2項「SOAPクライアント許可の有効化」の説明に従って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> 
   

3. 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へのデプロイ手順:

1. Oracle WebLogic Serverにアプリケーション・サーバーの接続を作成する手順:

   1. メイン・メニューから、「表示」 >→「アプリケーション・サーバー・ナビゲータ」を選択します。

   2. アプリケーション・サーバー・ナビゲータで、「アプリケーション・サーバー」フォルダを右クリックし、「新規アプリケーション・サーバー」を選択し、アプリケーション・サーバー接続の作成ウィザードを完了します。

2. サービス・デプロイメント・プロファイルの作成:

   1. アプリケーション・ナビゲータで、Webサービスが含まれるプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

   2. 「プロジェクト・プロパティ」ダイアログの「デプロイメント」ページを開き、 「新規」をクリックします。

   3. 「デプロイメント・プロファイルの作成」ダイアログで、アーカイブ・タイプとして「ビジネス・コンポーネント・サービス・インタフェース」を選択します(図11-11を参照)。

      図11-11 ビジネス・コンポーネント・サービス・デプロイメント・プロファイルの作成用ダイアログ

      
      

3. 11.2.14項「SOAPクライアントWebサービスのセキュリティ保護方法」の説明に従ってSOAP起動用にOracle WSM許可ポリシーを使用してWebサービスのセキュリティを構成した場合、WebサービスをEARファイルにデプロイし、web.xmlファイルを手動で編集できるようにします。

   注: Webサービスのセキュリティを構成していない場合は、この手順をスキップして、記述しているタスクを手動で編集します。ステップ4の説明に従ってEARをデプロイできます。

   1. From the 「アプリケーション」メニューで、作成したデプロイメント・プロファイルに対して、「デプロイ」→ 「デプロイメント・プロファイル」を選択します。

   2. デプロイ・ウィザードの「デプロイメント・アクション」ページで、「EARにデプロイ」を選択します。

   3. 「OK」をクリックします。

   4. JDeveloperが作成したEARファイルを検索します。ファイルはアプリケーションのmyworkフォルダ内のdeployフォルダに表示されます。たとえば、アプリケーション名がStoreFrontServiceの場合は、EARファイルは次の場所にあります。

      C:\JDeveloper\mywork\StoreFrontService\deploy\StoreFrontServiceProject_bcprofile1.ear
      

      このEARファイルのJARを解凍し、サービス・インタフェース・プロジェクトのWARファイルを検索します。たとえばWARファイルにStoreFrontService-MiddleTier_web.warという名前を付けます。

   5. WARファイルのJARを解凍し、WEB-INFフォルダ内のweb.xmlフィルを検索します。web.xmlファイルを抽出して、次のJPSWlsFilter定義を追加します。

      <filter>
          <filter-name>JpsWlsFilter</filter-name>
          <filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
             <init-param>
               <param-name>application.name</param-name>
               <param-value>ApplicationName</param-value>
             </init-param>
      </filter>
      <filter-mapping>
          <filter-name>JpsWlsFilter</filter-name>
          <servlet-name>
               ProjectName.server.serviceinterface.AppModuleServiceImpl
          </servlet-name>
          <dispatcher>REQUEST</dispatcher>
      </filter-mapping>
      

      JPSWlsFilterを構成する際、アプリケーション名の値はjazn-data.xmlおよびweblogic-application.xmlファイルで設定されているアプリケーション名と一致する必要があります。フィルタ・マッピング用に、web.xml内にすでにあるサーブレット名と一致する、<servlet-name>を入力します。フィルタ名がJpsFilter用に設定されたフィルタ名と一致しなければならない点に注意してください。

   6. 変更済のWARとEARファイルを編集済ファイルと一緒に再パッケージします。

   7. JDeveloperを使用してEARファイルをデプロイしないでください。ターゲット・サーバーのweb.xmlファイルが上書きされてしまいます。Oracle WebLogic Server管理コンソールなどのツールを使用して、アプリケーションのEARファイルを手動でデプロイします。JDeveloper以外でのセキュア・アプリケーションのデプロイの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

4. SOAP起動用のOracle WSM許可ポリシーを構成せずにWebサービスのEARをデプロイする場合は、JDeveloperでEARファイルをOracle WebLogic Serverにデプロイできます。

   1. From the 「アプリケーション」メニューで、作成したデプロイメント・プロファイルに対して、「デプロイ」→ 「デプロイメント・プロファイル」を選択します。

   2. デプロイ・ウィザードの「デプロイメント・アクション」ページで、「アプリケーション・サーバーへのデプロイ」を選択し、「次へ」をクリックします。

   3. 「サーバーの選択」ページで、アプリケーション・サーバー接続を選択します。

   4. 「OK」をクリックします。

11.3 サービス対応アプリケーション・モジュールによるリモート・データのアクセス

ADFビジネス・コンポーネント・アプリケーションはWebサービス用の組込みサポート、およびビュー・オブジェクト・データをサービス・データ・オブジェクト(SDO)として公開するための組込みサポートを提供しています。ローカル・データ・モデル・プロジェクト内で作成するエンティティ・オブジェクトは、サービス対応アプリケーション・モジュールがそのサービス・インタフェースで公開するSDOサービスを利用できます。ローカル・オブジェクト内でサービスバック・エンティティ・オブジェクトを作成することで、すべての共通リモート・サービス・データ・アクセス・タスクに対して、サービス・プロキシとSDOをプログラミングによって直接扱う必要がなくなります。

「エンティティ・オブジェクトの作成」ウィザードによって、11.3.1項「サービス対応エンティティ・オブジェクトおよびビュー・オブジェクトの使用方法」で説明しているように、エンティティ・オブジェクトの作成時、ローカル・データベースとADFビジネス・コンポーネント・サービス間での選択が簡単になります。これにより、サービス対応アプリケーション・モジュールは、データベースでローカルに提供されていないデータに別な方法でアクセスできます。

サービスバック・エンティティ・オブジェクトを作成すると、ビュー・オブジェクト、ビュー・リンクおよびビュー基準を作成して、実行時にデータをフィルタできるようになります。また、あたかもデータベース表からローカルに提供されたデータにアクセスして作業しているかのように、これらのビュー・データをデータ・モデルで活用することもできます。

次の各項では、サービス対応ADFアプリケーション・モジュールを使用して、データ・モデル・プロジェクトを強化する方法を説明します。

11.3.1 サービス対応エンティティ・オブジェクトとビュー・オブジェクトの使用方法

次のいずれかの状況が発生した場合に、アプリケーション設計戦略の一環として、サービスバック・コンポーネントを使用できます。

• クライアント・データ・モデル・プロジェクトで、別なビジネス・プロセスに含まれているサービス対応アプリケーションを使用する必要がある場合。

• クライアント・データ・モデル・プロジェクトで、プラガブルな外部サービスを使用する必要がある場合。

最初の場合は、サービスの両側を提供します。2番目の場合は、外部サービスが不明なことがあるので、次を行う必要があります。

1. サービスのFusion実装は必要ないかもしれませんが、サービス対応アプリケーション・モジュールのサービス・インタフェースがプラガブル機能のサポート単位になっており、サービスバック・エンティティ・オブジェクトおよびビュー・オブジェクト作成方法としてサポートされているので、「標準的な」プラガブル・サービスに求める形状をサービス・インタフェースに記述してアプリケーション・モジュールを作成します。

2. 11.2.1項「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」 に記載の説明に従ってサービス対応アプリケーション・モジュールを生成後、サービスバック・エンティティ・オブジェクトとビュー・オブジェクトを作成する必要があります。

3. 最後にステップ2で作成した「標準的」なサービス対応アプリケーション・モジュールと同じサービス・インタフェースをサポートするEJBセッションBean(またはSCAコンポジット)を作成し、このサービス・インタフェースに基づくサービス対応ビジネス・コンポーネントを含むクライアント・プロジェクトのconnections.xmlファイルが、この「プラグイン」バージョンを使用するように構成します。

アプリケーション・モジュールをWebサービスとして公開する方法の詳細は、11.2項「サービス対応アプリケーション・モジュールの公開」を参照してください。

11.3.1.1 SDOサービスにバックアップされたエンティティ・オブジェクトの作成

「エンティティ・オブジェクトの作成」ウィザードで、アプリケーション・サーバー上ですでに稼働しているデプロイ済サービスを記述したWSDLドキュメントのURLを指定して、サービスバック・エンティティ・オブジェクトを作成します。このウィザードはWSDLサービス記述を使用して、使用可能なサービス・ビュー・インスタンスのリストを表示します。ウィザードで、表示されたビュー・インスタンスの中から選択して、エンティティ・オブジェクトのデータ・ソースを指定します。ウィザードの実行時、WSDLドキュメントを検索するためにサービス・エンドポイントへのアクセスが可能でなければなりません。

作業を始める前に、次のようにします。

11.2.1項「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」に記載の説明に従って、Webサービスとしてアプリケーション・モジュールを公開します。

11.2.4項「個別のビュー・オブジェクトのサービス対応化の方法」に記載されている方法に従って、該当するビュー・オブジェクトをサービス対応にします。

11.2.5.2項「複合データ型を使用した関連するSDOプロパティの関連付け」に記載の説明に従って、サービス対応ビュー・オブジェクトの属性に対して複合型(通貨コードまたは測定単位を含む)を定義します。

データ・ソースとしてサービス・ビュー・インスタンスを使用するエンティティ・オブジェクトを作成する手順:

1. アプリケーション・ナビゲータで、エンティティ・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」ノードを展開し、「ADFビジネス・コンポーネント」を選択します。次に「エンティティ・オブジェクト」を選択し、「OK」をクリックします。

3. 「エンティティ・オブジェクトの作成」ウィザードの「名前」ページで、次の操作を実行してエンティティ・オブジェクトを作成します。

   • エンティティ・オブジェクトが作成されるパッケージ名を入力し、エンティティ・オブジェクト名を入力します。

   • 「サービス・インタフェース」を、エンティティ・オブジェクト作成用のデータ・ソースとして選択します。

   • 公開済サービスのURLのWSDLドキュメントを入力するか、「参照」をクリックし、Webサービスの検索ウィザードを使用してUDDIレジストリでリモート・サービスを検索します。

   • ドロップダウン・リストから「サービス・ビュー・インスタンス」を選択します(図11-12を参照)。

     ウィザードはサービス・エンドポイントとの接続を試み、WSDLサービス記述からリストへの移入を行います。エンドポイントが使用できな場合は、リストは空のままです。

     図11-12 「エンティティ・オブジェクトの作成」ウィザードにおけるデータ・ソースとしてのサービス・インタフェース

     
     

4. 「次へ」をクリックして、エンティティ・オブジェクトの属性を変更します。

   たとえば、「属性」ページで、サービスバック・エンティティ・オブジェクトによる参照を行わない属性を削除できます。

5. 「次へ」をクリックして、エンティティ・オブジェクトの属性設定を変更してから、ウィザードを終了します。

   たとえば「属性の設定」ページで、エンティティの変更時には常に変更が予想される属性について、「リフレッシュ」の「挿入後」および「リフレッシュ」の「更新後」オプションを有効化できます。通常、このような値には、行内のバージョン番号列や更新日付列などがあります。

   属性が複合型定義(通貨コードまたは測定単位を含む)を持つ場合、「属性の設定」ページには、サービス対応ビュー・オブジェクト属性のXSD型定義に応じて「currencyCode」または「unitCode」のいずれかのラベルが付いたドロップダウン・ボックスを含む「サービス」セクションが表示されます。ウィザードのドロップダウン・ボックスには関連する属性は表示されませんが(<未指定>のみが表示される)、ウィザードにより属性の複合型定義がエンティティ・オブジェクトの定義ファイルに追加されます。ウィザードを完了したら、11.3.1.2項「サービスバック・エンティティ・オブジェクト属性を持つ複合データ型の使用」の説明に従って、サービスバック・エンティティ・オブジェクトの概要エディタを使用して複合型属性の定義を完了します。

6. 「終了」をクリックします。

11.3.1.2 サービスバック・エンティティ・オブジェクト属性を持つ複合データ型の使用

サービスバック・エンティティ・オブジェクトを作成すると、ベース・サービス対応ビュー・オブジェクトのSDOプロパティにより定義されている属性が、JDeveloperによって自動的に公開されます。エンティティ・オブジェクトに複合型の属性が含まれる場合、エンティティ・オブジェクトから複合型の関連属性を選択する必要があります。たとえば、サービスバック・エンティティ・オブジェクトでOrderTotal属性およびCurrencyCode属性を定義し、対象の国での通貨コードを指定すると仮定します。この場合、関連属性CurrencyCodeを、サービス対応ビュー・オブジェクトにより指定されるSDOプロパティのタイプにマップする必要があります。複合型でサポートされているサービス・タイプは次のとおりです。

• AmountTypeサービス・タイプは、通貨コードを定義する任意のプロパティ用です。

• MeasureTypeサービス・タイプは、測定単位を定義する任意のプロパティ用です。

複合型およびSDOプロパティの詳細は、11.2.5.2項「複合データ型を使用した関連するSDOプロパティの関連付け」を参照してください。

概要エディタの「属性」ページを使用して、複合型として定義されたサービスバック・エンティティ・オブジェクトを選択します。概要エディタの「属性」ページから表示される「属性の編集」ダイアログを使用して、選択した属性の複合型を関連属性にマップします。

作業を始める前に、次のようにします。

11.2.1項「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」に記載の説明に従って、Webサービスとしてアプリケーション・モジュールを公開します。

11.2.4項「個別のビュー・オブジェクトのサービス対応化の方法」に記載されている方法に従って、該当するビュー・オブジェクトをサービス対応にします。

11.2.5.2項「複合データ型を使用した関連するSDOプロパティの関連付け」に記載の説明に従って、サービス対応ビュー・オブジェクトの属性に対して複合型を定義します。

11.3.1.1項「SDOサービスにバックアップされたエンティティ・オブジェクトの作成」に記載されている方法に従って、サービスバック・エンティティ・オブジェクトを作成します。

サービスバック・エンティティ・オブジェクトで複合型を使用して属性を関連付けるには:

1. 「アプリケーション」ウィンドウで、サービスバック・エンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、サービス対応ビュー・オブジェクトで複合型として定義された属性をベースとする属性を選択します。

   選択した属性は、サービス対応ビュー・オブジェクトのSDOプロパティにより数値型として定義されます。

4. 属性を選択した状態で、「属性の編集」ボタンをクリックします。

5. 「属性の編集」ダイアログの「サービス」セクションで、「currencyCode」または「unitCode」ドロップダウン・リストから、複合型に関連付けるエンティティ・オブジェクト属性を選択します。

   ドロップダウン・リストには、エンティティ・オブジェクトにより定義されているすべてのString属性が表示されます。複合型定義に関連属性としてマッピングするために適した属性を選択します。たとえば、通貨コードを、顧客が支払った金額を表示するOrderTotal属性と関連付けるには、Ordersサービスバック・エンティティ・オブジェクトのCurrencyCode属性を選択します。

   SDOフレームワークは、関連サービス属性値currencyCodeおよびunitCodeをサポートしています。エディタにcurrencyCodeが表示される場合には、関連付ける属性は通貨情報を指定する必要があります。エディタにunitCodeが表示される場合には、関連付ける属性は測定単位を指定する必要があります。

6. 「OK」をクリックします。

11.3.1.3 SDOサービスにバックアップされたビュー・オブジェクトの作成

プロジェクトにサービスバック・エンティティ・オブジェクトを追加したら、サービスバック・ビュー・オブジェクトを作成して、ユーザー・インタフェースで使用するリモート・サービス・データの問合せが行え、オプションでフィルタもできます。サービスバック・ビュー・オブジェクトは、そのエンティティを単独で使用すると、SDOサービスでバックアップされたエンティティ・オブジェクトを参照するビュー・オブジェクトです。JDeveloperでは、既存のビューをサービスバックにすることができません。JDeveloperでビュー・オブジェクトを作成する際に、エンティティをサービスバック・エンティティ・オブジェクト用に使用する場合は、新しいビュー・オブジェクトが自動的にサービスバックになります。

作業を始める前に、次のようにします。

11.3.1.1項「SDOサービスにバックアップされたエンティティ・オブジェクトの作成」に記載されている方法に従って、サービスバック・エンティティ・オブジェクトを作成します。

サービスバック・エンティティ・オブジェクトからビュー・オブジェクトを作成する手順:

1. アプリケーション・ナビゲータで、サービスバック・エンティティ・オブジェクトを右クリックし、新規デフォルト・ビュー・オブジェクトを選択します。

2. 「デフォルト・ビュー・オブジェクトの作成」ダイアログで、ビュー・オブジェクトを作成するパッケージ名を入力し、ビュー・オブジェクト名を入力します(図11-13を参照)。

   生成されたビュー・オブジェクトには、エンティティ・オブジェクトと同じ属性が含まれます。オプションで、概要エディタでビュー・オブジェクトを編集し、問合せをカスタマイズできます。リモート・サービスのデータをフィルタする場合は、ビュー・オブジェクトのビュー基準も定義できます。問合せ結果のフィルタの詳細は、5.11項「名前付きビュー基準の処理」を参照してください。

   図11-13 サービスバック・エンティティ・オブジェクトからのビュー・オブジェクトの作成

   
   

11.3.2 サービスバック・ビジネス・コンポーネント作成時の処理

サービスバック・エンティティ・オブジェクトはアクセスの詳細、および必要に応じてリモートADFビジネス・コンポーネント・サービスからのデータ行の変更の詳細をカプセル化するエンティティ・オブジェクトです。「エンティティ・オブジェクトの作成」ウィザードを使用してサービスバック・エンティティ・オブジェクトを作成後、JDeveloperが追加のサービス関連メタデータを、エンティティ・コンポーネント定義の<Datasource>要素に保存します。エンティティ・コンポーネント定義には、複合型定義を持つ属性も含め、サービス対応ビュー・オブジェクト・インスタンスから選択したすべての属性が含まれます(例11-13を参照)。

サービスバック・ビュー・オブジェクトは、エンティティ・ベースのビュー・オブジェクトと同様に、そのメタデータ内の単一のサービスバック・エンティティ・オブジェクトを参照します。サービスバック・ビュー・オブジェクトは、他のビュー・オブジェクトと同様に使用できます。ビュー・オブジェクトの作業方法の詳細は、第5章「ビュー・オブジェクトを使用したSQL問合せの定義」を参照してください。ADFランタイムは、リモートADFビジネス・コンポーネント・サービスとの対話を処理します。

例11-13 エンティティ・オブジェクト・メタデータはサービス・ビューをデータ・ソースとして表示

<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>

11.3.3 サービスバック・ビジネス・コンポーネントのデータ・モデルの更新方法

サービス・インタフェースは各ビュー・インスタンスを公開するので、コンシューミング・プロジェクトで、サービスバック・エンティティ・オブジェクト間の階層関係の定義(アソシエーションによる)、およびサービスバック・ビュー・オブジェクトの階層関係の定義(ビュー・リンクによる)を行う必要があります。サービスバック・ビジネス・コンポーネントを作成しても、ビュー・リンクとアソシエーションは自動的には作成されません。たとえば、公開済のADFビジネス・コンポーネント・サービスのアプリケーション・モジュールで、使用するマスター/ディテール関係が定義されている場合、プロジェクト内で対応するビュー・オブジェクトのビュー・リンクを定義して、この階層を維持する必要があります。

さらに、ローカルなデータとサービスバック・ビュー・オブジェクトを問い合せる(またはその逆)、ビュー・オブジェクト間のビュー・リンクは作成できますが、ビュー・リンクを一度定義すると、次のようなオブジェクト慣用名では、エンティティ・ベースのビュー・オブジェクトを作成できません。

• ビュー・オブジェクトは、サービスバック・エンティティ・オブジェクトであるセカンダリ・エンティティ慣用名を参照できません。

• ビュー・オブジェクトは、セカンダリ・エンティティの慣用名付きのサービスバック・エンティティ・オブジェクトである、プライマリ・エンティティ慣用名を参照できません。

クライアント・プロジェクト内の通常のエンティティ・オブジェクトとサービスバック・エンティティ・オブジェクト間のアソシエーションにも同じ制約が適用されます。アソシエーションは作成できますが、ビュー・オブジェクトは作成できません。

ビュー・リンクの作成ウィザードを使用して、プロジェクトで定義されたビュー・オブジェクト間の関係を指定します(図11-14を参照)。ビュー・リンクの作成の詳細は、5.6.2項「エンティティ・ベースのビュー・オブジェクトに対するマスター/ディテール階層の作成方法」を参照してください。

図11-14 ビュー・リンクの作成ウィザードで定義された1対多の関係

作成するビュー・リンクでは、ローカルにアクセスしたデータベース表に問い合せるサービスバック・ビューとビュー・オブジェクト間の関係を定義できます。たとえば、サービスバック・マスター・ビュー・オブジェクトで、データベースから派生したディテール・ビュー・オブジェクトを実行する場合があります。表11-2に示す組合せで、ビュー・リンクを作成できます。

表11-2 サービスバック・ビュー・オブジェクトに関連する、サポートされているビュー・リンクの組合せ

使用例	マスター・ビュー・オブジェクト・タイプ	ビュー・リンク・ディテール・ビュー・オブジェクト・タイプ	ビュー・リンク・カーディナリティ
リモート・ディテールのあるローカル・マスター行	問合せベース	サービスバック	1対多
ローカル・ディテールのあるリモート・マスター行	サービスバック	問合せベース	1対多
リモート参照情報のあるローカル・マスター行	問合せベース	サービスバック	多対1
ローカル参照情報のあるリモート・マスター行	サービスバック	問合せベース	多対1

該当するビュー階層を定義したら、ビュー・リンクの作成ウィザードを使用して、プロジェクトのアプリケーション・モジュールの概要エディタで、データ・モデルの新しいビュー・インスタンスを定義します(図11-15を参照)。更新したデータ・モデルによって、Fusion Webアプリケーションのユーザー・インタフェースとのデータバインドを可能にするADFデータ・コントロールとして、ビュー・オブジェクトを公開できます。データ・モデルの更新の詳細は、9.2.3.2項「アプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加」を参照してください。

図11-15 サービス・ビュー・インスタンスが含まれたデータ・モデル

11.3.4 サービスバック・ビジネス・コンポーネント・ランタイムの構成方法

アプリケーションを実行し、公開済のサービス対応ADFアプリケーションとの対話を行ってサービス操作を起動する前に、サービス・エンドポイント・プロバイダ・タイプおよびその他の構成情報を含む、公開済サービスの記述を行う必要があります。ADFビジネス・コンポーネントのServiceFactoryクラス (oracle.jbo.client.svc.ServiceFactory)はサービスのプロキシを戻し、サービス・プロキシを使用してサービス操作を起動します。サービス・ファクトリは、3つの異なるサービス・エンドポイント・プロバイダのプロキシを戻して、これらのトランスポート・プロトコルをサポートできます。

• サービス・エンドポイント・プロバイダがADFビジネス・コンポーネントの場合は、トランスポート・プロトコルはEJB RMIです。

• サービス・エンドポイント・プロバイダがSOA Fabricの場合は、トランスポート・プロトコルはSOA Fabric SDOバインディングです。

• サービス・エンドポイント・プロバイダがSOAP (JAX-WSクライアント用)の場合は、トランスポート・プロトコルはSOAPです。

公開済のサービス操作を起動するようにコンシューミング・アプリケーションを構成する手順:

1. SDO生成クラスのbcProfileName_Common.jarファイルを、クライアント・プロジェクトのクラスパスに追加します。

2. クライアント・プロジェクトの.adf/META-INFフォルダ内のconnections.xmlファイルを更新して、公開済ADFビジネス・コンポーネント・サービスを記述します。

   このファイルでの更新内容はアプリケーションで使用しているトランスポート・プロトコルがEJB RMIプロトコル、SOA Fabric SDOバインディング、またはSOAPプロトコル(JAX-WSクライアント用)のいずれかによって異なります。

11.3.4.1 クラスパスへのSDOクライアント・ライブラリの追加

アプリケーションで公開済サービスにアクセスできるようになるには、サービス・コンシューミング・プロジェクトから生成されたSDOクラスとそのスキーマ定義にアクセスできなければなりません。これらのファイルは、サービス公開を担当する開発チームが生成したbcProfileName_Common.jarファイルにパッケージされています。

アプリケーションでSDOクラスを使用できるようにするには、サービスプロバイダ・チームからbcProfileName_Common.jarファイルを入手し、このJARファイルをローカル・プロジェクト・フォルダに配置します。たとえば、JARファイルをプロジェクトのデプロイ・フォルダにコピーできます。次にJDeveloperを使用してJARファイルを、作成したSDOクライアント・ライブラリとともにプロジェクトのクラスパスに追加できます。SDOクラスJARファイルの生成手順は、11.2.20項「Oracle WebLogic ServerへのWebサービスのデプロイ方法」を参照してください。

SDOクライアント・ライブラリをクラスパスに追加する手順:

1. アプリケーション・ナビゲータで、プロジェクト・フォルダを右クリックして、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」を選択し、「ライブラリの追加」をクリックします。

3. 「ライブラリの追加」ダイアログで、「新規」をクリックして、SDOクライアント・ライブラリを作成します。

4. 「ライブラリの作成」ダイアログで、「エントリの追加」をクリックしてクラスパス・エントリを追加します。

5. 「パス・エントリの選択」ダイアログで、bcProfileName_Common.jarファイルが含まれたフォルダに移動して、そのファイルを選択し、「ライブラリの作成」ダイアログに表示します。

   「パス・エントリの選択」ダイアログでは、ファイル・システムまたはローカル・エリア・ネットワークを参照して、JARファイルを検索できます。サービスプロバイダのアプリケーション・ワークスペースのデプロイ・フォルダの参照でJARファイルを入手できない場合は、ファイルを入手して自分のプロジェクト・フォルダにコピーする必要があります。たとえば、JARファイルをプロジェクトのデプロイ・フォルダにコピーします。

6. ダイアログで「OK」をクリックすると、SDOクライアント・ライブラリを選択した状態で「プロジェクト・プロパティ」ダイアログが表示されます。「OK」をクリックして、ライブラリをクラスパスに追加します。

   図11-16に、ServiceProvider_Common.jarという名前が選択された、SDOクライアント・ライブラリを示します。この場合は、ライブラリ名はJARファイル名と同じです。オプションで、「ライブラリの作成」ダイアログでライブラリ名を編集できます。

   図11-16 SDOクライアント・ライブラリ・クラスパス・エントリ

   
   

11.3.4.2 コンシューミング・アプリケーションのEJB RMIプロトコル用connections.xmlへの、ADFビジネス・コンポーネント・サービスの登録

サービス・エンドポイント・プロバイダがADFビジネス・コンポーネントの場合は、サービス・ファクトリがEJBコンテナ内で実行中のステートレス・セッションBeanにバインドされた、EJBオブジェクト・プロキシを戻します。JNDIコンテキスト情報を提供して、コンシューミング・アプリケーションが公開済サービスを検索できるようにする必要があります。

公開済ADFビジネス・コンポーネント・サービスの登録用に提供する検索情報は、Fusion Webのコンシューミング・アプリケーションのconnections.xmlファイル内(アプリケーションに相対的な.adf/META-INFフォルダ内)にあります。ADF接続アーキテクチャはこのファイルを使用してサービス・エンドポイント・プロバイダの詳細をカプセル化します。

公開済データがコンシューミング・アプリケーションでローカルに(同じJVM内で)実行されているのか、コンシューミング・アプリケーションとはな別なサーバーでリモートに実行されているのかによって、提供するJNDI検索情報は異なります。通常、ADFビジネス・コンポーネント・サービスはコンシューミング・アプリケーションとは異なっており、したがってリモートに実行されています。

公開済サービスをクライアント・アプリケーションに登録するには、例11-14に従ってconnections.xmlファイルを更新します。ADFビジネス・コンポーネント・サービスがコンシューミング・アプリケーションでローカルに実行されている場合(JDeveloper内での実行時のように)、サービス・ファクトリはJNDI名さえあればサービスを検索できます。

注意: スタンドアロンOracle WebLogic Serverにコール元アプリケーションをデプロイする場合は、connections.xmlファイルを編集するかわりにOracle Enterprise Managerを使用してJNDIコンテキスト・プロパティを構成します。手順は、Oracle Enterprise Managerのオンライン・ドキュメントを参照してください。

例11-14 クライアントのconnections.xmlファイルによるローカルEJB ADFビジネス・コンポーネント・サービスの登録

<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ビジネス・コンポーネント・サービスがコール元クライアントに対してリモートに実行すると、リモートJNDIコンテキスト情報をconnections.xmlファイルに追加する必要があります。connections.xmlファイルにあるこれらのJNDIコンテキスト・プロパティを編集できます(例11-15を参照)。

• 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-15に示すように、connections.xmlファイルには、パスワードを設定せずに<SecureRefAddr addrType="jndiSecurityCredentials"/>を含む必要があります。スタンドアロンOracle WebLogic Server用のサービス・パスワードを構成するには、Oracleの資格証明ストアに暗号化されたパスワードを保存するOracle Enterprise Managerを使用する必要があります。

例11-15 クライアントのconnections.xmlファイルによるリモートEJB ADFビジネス・コンポーネント・サービスの登録

<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>

11.3.4.3 コンシューミング・アプリケーションのSOAPプロトコル用connections.xmlへの、ADFビジネス・コンポーネント・サービスの登録

サービス・エンドポイント・プロバイダがSOAPの場合、サービス・ファクトリは動的なJAX-WSクライアント・プロキシを作成します。WSDL URLとポート名を提供して、コンシューミング・アプリケーションが公開済サービスを検索できるようにする必要があります。さらに、SOAPクライアント用には、SOAPヘッダーの一部として、Oracle Web Service Manager (Oracle WSM)クライアント・セキュリティ・ポリシーを添付できます。

公開済ADFビジネス・コンポーネント・サービスの登録用に提供する検索情報は、Fusion Webのコンシューミング・アプリケーションのconnections.xmlファイル内(アプリケーションに相対的な.adf/META-INFフォルダ内)にあります。ADF接続アーキテクチャはこのファイルを使用してサービス・エンドポイント・プロバイダの詳細をカプセル化します。

注意: スタンドアロンOracle WebLogic Serverにコール元アプリケーションをデプロイする場合は、connections.xmlファイルを編集するかわりにOracle Enterprise Managerを使用してJNDIコンテキスト・プロパティを構成します。手順は、Oracle Enterprise Managerのオンライン・ドキュメントを参照してください。

SOAPプロトコル用にクライアント・アプリケーションに公開済サービスを登録するには、アプリケーションがアイデンティティ伝播またはアイデンティティ切替えのいずれを使用しているかによって、例11-16または例11-17の例に従ってconnections.xmlファイルを更新します。アイデンティティ伝播と切替えは、各プロセスでアイデンティティを伝播するという点では同様です。Fusion Webアプリケーションでは、アイデンティティ伝播によって現在コードを実行中のアイデンティティが伝播されます。一方、アイデンティティ切替えでは、現在コードを実行中のものとは異なるアプリケーション・アイデンティティを伝播します。

公開済サービスをクライアント・アプリケーションに登録し、資格証明キーに基づいて、ユーザー・アイデンティティが切り替わるようにするには、例11-16の例に従って、connections.xmlファイル内で、クライアント側のポリシー・ファイル、oracle/wss11_username_token_with_message_protection_client_policyを指定します。

注意: connections.xmlファイルは、Oracle WSMセキュリティ・ポリシー・クライアントのオーバーライドをサポートしています。セキュリティ・ポリシーがoracle/wss11_username_token_with_message_protection_client_policyの場合、csf-keyプロパティにオーバーライドして、コンシューミング・アプリケーションの資格証明を指定できます。

例11-16 クライアントのconnections.xmlファイルによる、アイデンティティ切替えを使用したSOAPプロトコル用のリモート・ビジネス・コンポーネント・サービスの登録

<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-17の例に従って、connections.xmlファイル内で、クライアント側のポリシー・ファイル、oracle/wss11_saml_token_with_message_protection_client_policyを指定します。

例11-17 クライアントのconnections.xmlファイルによる、アイデンティティ伝播を使用したSOAPプロトコル用のリモート・ビジネス・コンポーネント・サービスの登録

<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>

11.3.4.4 コンシューミング・アプリケーションのファブリックSDOバインディング用connections.xmlへの、ADFビジネス・コンポーネント・サービスの登録

サービス・エンドポイント・プロバイダがSOAファブリックの場合は、サービス・ファクトリがSOAファブリック・コンポジット・プロキシを戻し、ファブリックのSDOバインディングによってファブリック・コンポジット内で実行中のサービスをコールします。ファブリック・コンポジット名を提供して、コンシューミング・アプリケーションが公開済サービスを検索できるようにする必要があります。

公開済ADFビジネス・コンポーネント・サービスの登録用に提供する検索情報は、Fusion Webのコンシューミング・アプリケーションのconnections.xmlファイル内(アプリケーションに相対的な.adf/META-INFフォルダ内)にあります。ADF接続アーキテクチャはこのファイルを使用してサービス・エンドポイント・プロバイダの詳細をカプセル化します。

注意: スタンドアロンOracle WebLogic Serverにコール元アプリケーションをデプロイする場合は、connections.xmlファイルを編集するかわりにOracle Enterprise Managerを使用してJNDIコンテキスト・プロパティを構成します。手順は、Oracle Enterprise Managerのオンライン・ドキュメントを参照してください。

公開済サービスをファブリック・プロトコルのクライアント・アプリケーションに登録するには、例11-18に従って、connections.xmlファイルを更新します。ここで、fabricAddressは公開済サービスのファブリック・コンポジット名です。

例11-18 クライアントのconnections.xmlファイルによる、SOAファブリック・プロトコル用のリモート・ビジネス・コンポーネント・サービスの登録

<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>

11.3.5ビジネス・コンポーネント・ブラウザでのサービスバック・コンポーネントのテスト方法

ビジネス・コンポーネント・ブラウザを起動する前に、プロジェクトが11.3.4項「サービスバック・コンポーネント・ランタイムの構成方法」に記載された実行時要件を満たしている必要があります。ビジネス・コンポーネント・ブラウザは作成するビュー・オブジェクトをリモート・サービスから表示し、標準のCRUD操作を実行するためにサービスとの対話が行えるようにします。

実行するアプリケーション・モジュールはローカルに問い合せたデータとリモートに問い合せたデータを一緒にアクセスできるので、サービスバック・ビュー・オブジェクトとデータベースから派生したビュー・オブジェクトが同じブラウザに表示されます。ビジネス・コンポーネント・ブラウザでサービスバック・ビュー・オブジェクトを選択したときに、エンドポイントが使用できない場合は、実行時例外が発生します。

ビジネス・コンポーネント・ブラウザの詳細は、6.3.1項「ビジネス・コンポーネント・ブラウザの実行方法」を参照してください。

11.3.6 コンシューミング・アプリケーションでのサービスバック・コンポーネント操作起動方法

ADFビジネス・コンポーネント・サービス・インタフェースでは、サービス・プロキシを戻して、起動した操作が公開済サービスで指定したトランスポート・プロトコルを使用していることを確認する必要があります。

作業を始める前に、次のようにします。

コンシューミング・アプリケーションが、クラスパス上に正しいライブラリを持っていることを確認する必要があります。アプリケーション・ナビゲータでプロジェクトをダブルクリックし、「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」を選択し、次のライブラリが表示されることを確認します。

• Java EE 1.5

• Oracle XML Parserバージョン2

• BC4Jサービス・クライアント

• JAX-WS Client

• サービスの共通JARファイル

例11-19に示すように、操作を起動する際、次のタスクを実行します。

1. oracle.jbo.client.svc.ServiceFactoryクラスと公開済サービス・クラスをインポートします。

2. サービス・ファクトリ・オブジェクト上でgetServiceProxy()をコールし、<serviceName>.NAMEの形式でサービス名を渡します。ADFサービス・ファクトリはこの方法で戻されたサービス・プロキシ・オブジェクトにSDOHelperContext IDを組み込み、最新のADFビジネス・コンポーネント・サービス・スキーマ・メタデータがSDOに提供されるようにします。

   サービス・オブジェクトのスキーマ(.xsdファイル)は通常MDSに保存されており、たとえばビジネス・コンポーネント属性の追加、既存の型の拡張、新しい型の定義などのために拡張されている場合があります。ローカル・ヘルパー・コンテキストにより、他のサービスのSDOメタデータに影響を及ぼすことなく、アプリケーションの再起動を行わなくても、各サービス・スキーマ定義のカスタマイズが可能です。

3. データ・ファクトリ・オブジェクト上でcreate()をコールし、プロキシ・オブジェクトをgetServiceProxy()コールで入手します。

4. プロキシ・オブジェクト上で操作を起動すると、データ・オブジェクトが戻されます。

5. 戻されたデータ・オブジェクトをXMLとして保存します。

例11-19 コンシューミング・アプリケーションにおけるサービス・プロキシの入手と起動

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);
   }

11.3.7 アプリケーションが公開済のアプリケーション・モジュールにアクセスした場合、実行時に行われる処理

ADFランタイムはデータ・ソース情報をサービスバック・エンティティ・オブジェクトXML定義から入手し、必要に応じてサービス・インタフェース・メソッドとの対話を自動化します。サービスバック・エンティティ・オブジェクトを使用することで、すべての共通リモート・サービスのデータ・アクセス・タスクに対して、サービス・プロキシおよびサービス・データ・オブジェクトを直接プログラミングする必要がなくなります。ADFサービス・ファクトリはサービスを検索し、connections.xmlで指定したサービス・インタフェースを使用して、サービス・メソッドを起動します。

アプリケーションがリモートADFビジネス・コンポーネント・サービスにアクセスする際、各リモート・コールはステートレスで、リモート・サービスは、サービス対応のアプリケーション・モジュールのサービス・インタフェースを使用するビジネス・コンポーネントと同じトランザクションには関与しません。

ほとんどの場合、リモート・サービスへのコールは情報提供を目的としたもので、リモート・オブジェクトは変更されません。ただし、リモート・サービスを使用して変更を行う必要がある場合は、次の点に注意してください。

• リモート・サービスにスローされた例外によって、ローカル・トランザクションが失敗します。

• データ変更を伴うリモート・サービス・コールが成功した後、なんらかの理由でローカル・トランザクションが失敗した場合、エラー処理コードを使用して、リモート・サービスに対して復元トランザクションを行い、過去の変更を「取り消す」必要があります。

11.3.8 サービスバック・エンティティ・オブジェクトおよびビュー・オブジェクトについて

参照情報にアクセスするために使用するWebサービスもあります。また、データを変更するためにコールするサービスもあります。このデータ変更は、自社のユーザーと同じチームまたは別のチームのメンバーによってサービスが記述された場合、自社のデータベースに存在する可能性があります。Webサービスが自社のファイアウォールの外部にある場合は、変更対象のデータベースは、当然、別の会社によって管理されます。いずれの場合でも、起動するWebサービスによって実行されるデータ変更は、サービス対応のアプリケーション・モジュールの現在の作業ユニットとは無関係な独自のトランザクションによって実行されるということを理解しておくことが重要です。たとえば、データを変更するWebサービスを起動した後、rollback()をコールしてアプリケーション・モジュールの現在の作業ユニット内で保留中の変更を取り消しても、該当するプロセス内でコールしたWebサービスで実行した変更に対しては、ロールバックの影響はありません。対応するWebサービス・メソッドを起動して、補正用の変更を実行し、アプリケーション・モジュールのトランザクションのロールバックを無効にする必要がある場合があります。

実行時、ADFはリモートADFビジネス・コンポーネント・サービスとの対話を処理します。ただし、サービスバック・ビジネス・コンポーネントには、次のような設計時の制約があり、これによってアプリケーションの実行時の動作が制限されることがある点を認識しておく必要があります。設計時におけるこれらの制約の適用の詳細は、11.3.3項「サービスバック・ビジネス・コンポーネントのデータ・モデルの更新方法」を参照してください。

• 作成するビュー・オブジェクトは、サービスバック・エンティティ・オブジェクトを、セカンダリ・エンティティ・オブジェクト慣用名として参照できません。

• 作成するビュー・オブジェクトは、関連する複数のエンティティ・オブジェクトのいずれかがサービスバック・エンティティ・オブジェクトの場合、これらのエンティティ・オブジェクトからフラット化された結合を生成できません。

• サービスバック・エンティティ・オブジェクトから作成するサービスバック・ビュー・オブジェクトは、セカンダリ・エンティティ慣用名を参照しません。

設計時におけるこれらの制約の適用の詳細は、11.3.3項「サービスバック・ビジネス・コンポーネントのデータ・モデルの更新方法」を参照してください。