クライアント アプリケーション開発者ガイド

     前  次    新しいウィンドウで目次を開く     
コンテンツに進む

Java クライアントからのデータ サービスへのアクセス

この章では、Java クライアント アプリケーションからデータ サービスにアクセスする方法について説明しています。 トピックは以下のとおりです。

 


AquaLogic Data Services Platform Mediator API の概要

BEA AquaLogic Data Services Platform Mediator API は、Java クライアント アプリケーション開発者がデータ サービス ルーチンを使用するための、使いやすいインタフェースです。 リモート データ サービス インタフェースをインスタンス化し、インタフェースのパブリック メソッドを呼び出すだけで、Mediator API を使用することができます。 パブリック メソッドには、読み込み関数、ナビゲーション関数、プロシージャを使用できます。

呼び出しの戻り値の型は、以下に示すように、メソッドのタイプと、使用されているインタフェースが静的であるかまたは動的であるかによって異なります。

Mediator API では、データ サービス用に静的インタフェースと動的インタフェースの両方が用意されています。

また、Mediator API では、以下のような高度な機能がサポートされています。

Mediator API は、データ サービスへのインタフェースのインスタンス化およびデータ サービス関数およびプロシージャの呼び出しに使用されています。 データ サービスに対して定義されている関数およびプロシージャは、Mediator API のメソッドとして利用できます。

動的 Mediator API クラスおよびインタフェースは、以下の JAR ファイルに含まれています.

	ld-client.jar 

Data Service Mediator パッケージには、以下の名前が付けられています。

	com.bea.dsp.dsmediator.client

API は、表 3-1 に示されているクラスおよびインタフェースで構成されています。

表 3-1 AquaLogic Data Services Platform Mediator API 
インタフェースまたはクラス名
説明
DataService
データを Data Objects として戻すデータ サービス用インタフェース。 インタフェースには、読み込みおよびナビゲーション関数を呼び出すための invoke() メソッド、プロシージャを呼び出すための invokeProcedure()、およびデータ オブジェクト変更を送信するための submit() メソッドがある。
PreparedExpression
アドホック クエリの準備および実行用インタフェース。 アドホック クエリは、データ サービス内でなく、クライアント プログラムで定義される。
DataServiceFactory
データ サービスに対するローカル インタフェースを作成するためのファクトリ クラス。 動的データ サービス インスタンス化およびアドホック クエリに使用できる。
StreamingDataService
データをトークン ストリームとして戻すデータ サービス用インタフェース。
StreamingPreparedExpression
情報をストリームとして戻すアドホック クエリ関数の準備および実行用インタフェース。 アドホック クエリは、クライアント プログラム内 (データ サービス内ではなく) で文字列として渡される XQuery である。

この型付きのデータ サービス用のクラス宣言の例に示すとおり、静的 Mediator API インタフェースにより、静的 Mediator インタフェースが拡張されます。

public class dataservices.Customer extends
com.bea.dsp.dsmediator.client.DataService { ... }

この静的データ サービス インタフェースは、AquaLogic Data Services Platform プロジェクトから生成された SDO Mediator Client JAR ファイル内にあります。

Mediator エラー用の例外クラス (SDOMediatorException) は、以下のパッケージに含まれています。

	com.bea.ld.dsmediator.client.exception

データ ソースにより生成された例外 (SQLException など) は、SDO Exception 内でラップされ、SDOMediatorException 上で getCause() を呼び出すことによりアクセスできます。

クラスパスの設定

Mediator API を使用した Java ベースのクライアント プログラムの開発には、使用する開発環境の CLASSPATH に 表 1-5 AquaLogic Data Services Platform Java アーカイブ ファイルに示す JAR ファイルが必要です。

また、静的データ API を使用するには、<app-name>-ld-client.jar ファイル (データ サービス設計者または管理者から取得してください) を含める必要があります。

注意 : 動的 SDO の場合は、<app-name>-ld-client.jar ファイルは不要です。

たとえば、静的 API を使用した Demo という名前のデータ サービスでは、使用する Microsoft Windows オペレーティング システムのクラスパスには以下が含まれます。

    set CLASSPATH=%CLASSPATH%;Demo-ld-client.jar;
C:\bea\weblogic81\server\lib\weblogic.jar;
C:\bea\weblogic81\liquiddata\lib\wlsdo.jar;
C:\bea\weblogic81\server\lib\xbean.jar;
C:\bea\weblogic81\server\lib\xqrl.jar;
C:\bea\weblogic81\server\lib\wlxbean.jar;
C:\bea\weblogic81\liquiddata\lib\ld-client.jar;

このクラスパスでは、最初のアイテム Demo-ld-client.jar が現在のディレクトリ、BEA WebLogic のホーム ディレクトリが C:\bea\weblogic81 であると想定しています。 使用するシステムに合わせて適切な場所にパスを修正し、Demo-ld-client.jar の名前を AquaLogic Data Services Platform 対応アプリケーションで生成された実際の JAR ファイル名に変更します。

Mediator API 概要および参照

クライアント アプリケーション開発者は、2 種類の SDO データ作業方法を選ぶことができます。

この章では、Mediator API について、および Java クライアント アプリケーションでの使用方法について説明します。 Data Service コントロールについては、「WebLogic Workshop アプリケーションからのデータ サービスへのアクセス」を参照してください。

クライアント アプリケーション開発者は、アプリケーション設計および特定の目的に応じて、表 3-2 に示す API をいくつか組み合わせて使用します。 また、データ サービス開発者も、SDO Update API (厳密には UpdateOverride インタフェース) を使用してデータ サービス機能をカスタマイズします。

表 3-2 Data Service Mediator API パッケージ参照
 
SDO Mediator API
SDO Update API
パッケージ
com.bea.dsp.dsmediator.client
com.bea.ld.dsmediator.update
説明
DataServiceFactory およびその他のクラス。 DataService、StreamingDataService、および PreparedExpression インタフェース。
DataServiceMediatorContext、DataServiceToUpdate、KeyPair、DataServiceMediator、および UpdatePlan クラス。 UpdateOverride インタフェース。
使用上の注意
データ サービスへのリモート インタフェースをインスタンス化する。
変更したデータ オブジェクトをデータ サービスに送信する。 特定のデータ サービスの更新処理をオーバーライドする。
場所
<bea_home>\weblogic81\liquiddata\lib\ld-client.jar
SDO Mediator API と同じ。
Javadoc
どちらのドキュメントも、AquaLogic Data Services Platform edocs ホームページからアクセスできる。
SDO Mediator API と同じ。

 


静的 Mediator API JAR ファイルの生成

クライアント アプリケーションでは、AquaLogic Data Services Platform プロジェクトから生成された JAR (Java アーカイブ) ファイルを使用して静的データ サービス インタフェースを表すクラスにアクセスできます。 クライアント アプリケーション開発者は、(通常はデータ サービス設計者または AquaLogic Data Services Platform 管理者から) この JAR ファイルを取得し、JAR ファイルを開発環境のクラスパスに追加する必要があります。

生成された静的 Mediator クライアント JAR ファイルの命名規約は、以下のとおりです。

<AppName>-ld-client.jar

クライアント JAR の構築

データ サービス アプリケーションにより EAR ファイルが構築されると、データ サービスのクライアント バージョンである <AppName>-ld-client.jar ファイルを EAR から生成することができます。 クライアント バージョンには、クライアントから動的または静的 API を通じてデータ サービス関数を呼び出すことができるラッパー クラスがあります。

必要な JAR ファイルは、以下の 2 つの方法のいずれかを使用して生成できます。

表 3-3 は、静的クライアント JAR Mediator の生成に使用できる引数について説明します。

表 3-3 Data Services EAR からの静的クライアント JAR Mediator の生成
引数
説明
<archive>
生成された EAR ファイルの完全修飾名。 生成された名前は、アプリケーション名から派生している。
<outdir>
クライアント JAR ファイルの生成先となるディレクトリ。 省略可能のパラメータである。指定しない場合は、現在のディレクトリが使用される。
<tmpdir>
一時的に展開した EAR ファイルの内容の生成先となるディレクトリ。 このパラメータは省略可能であるが、プロセスの終了時にすべての内容が削除されるため、常に一時ディレクトリを作成および指定することが望ましい。 <tmpdir> が指定されていない場合は、現在のディレクトリが使用される。

Data Service Mediator API の使用

Data Service Mediator API を使用してデータ サービス関数またはプロシージャを呼び出すには、以下の手順で Java クラスを作成します。

  1. com.bea.dsp.dsmediator.client パッケージをインポートします。
  2. AquaLogic Data Services Platform アプリケーションをホストする WebLogic Server 用の JNDI コンテキストを作成します。
  3. 注意 : 詳細については、「AquaLogic Data Services Platform 用の WebLogic JNDI コンテキストの取得」を参照してください。 WebLogic Server コンテキストの詳細については、以下を参照してください。
    
    http://e-docs.bea.com/wls/docs81/javadocs/weblogic/jndi/WLInitialContextFactory.html
  4. データ サービス用にリモート インタフェースをインスタンス化します。 静的または動的 Mediator API インタフェースのどちらを使用してもかまいません。 データ サービス名の動的インタフェースが引数として渡されます。 例 :
  5. DataService ds = DataServiceFactory.newDataService(
    JndiCntxt, "RTLApp", "ld:DataServices/RTLServices/Customer");

    静的インタフェースを使用した同じオペレーションの例を以下に示します。

    CUSTOMER ds =  CUSTOMER.getInstance(JndiCntxt, "RTLApp");
  6. データ サービスで関数またはプロシージャを呼び出します。
  7. 以下は、動的インタフェースを使用してデータ サービスの読み込み関数を呼び出すオペレーションです。

    Object[] params = new Object { "CUSTOMER1" };
    DataObject[] myCustomer =
    (DataObject[]) ds.invoke("getCustomerByCustID", params);

    静的インタフェースを使用した同じオペレーションの例を以下に示します。

    CUSTOMERDocument myCust = ds.getCustomerByCustID("CUSTOMER1");

AquaLogic Data Services Platform 用の WebLogic JNDI コンテキストの取得

Java クライアント アプリケーションは、WebLogic Server 上では、JNDI を使用してデータ サービスなどの名前付きのオブジェクトにアクセスします。 JNDI 呼び出しを一回行い、初期コンテキストを取得します。次に、これをデータ サービス ファクトリ クラスに渡します。 サーバ コンテキストを取得すると、データ サービスから、関数を呼び出したり、情報を取得することができます。

WebLogic Server コンテキストを取得するには、INITIAL_CONTEXT_FACTORY および PROVIDER_URL 環境プロパティを指定して JNDI 初期コンテキストを設定します。

ローカル クライアント (WebLogic Server と同じコンピュータ上にあるクライアント) は、その初期コンテキスト コンストラクタを呼び出して (つまり、新規 InitialContext( ) を呼び出し) 取得したデフォルトのコンテキスト内の設定を使用して、これらのステップをバイパスすることもあります。

この段階では、クライアントがセキュリティ コンテキストを対応する JNDI 環境プロパティ SECURITY_PRINCIPAL および SECURITY_CREDENTIALS に渡し、自身を認証することもあります。

以下に示すのは、hashtable を使用して JNDI 初期コンテキストを取得している リモート クライアントのコードの抜粋です。

   Hashtable h = new Hashtable();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL,"t3://machinename:7001");
h.put(Context.SECURITY_PRINCIPAL,<username>);
h.put(Context.SECURITY_CREDENTIALS,<password>);
  InitialContext jndiCtxt = new InitialContext(h);

必ず、使用する環境に合わせて、マシン名、ユーザ名、パスワードを適切な値で置き換えてください。

関数および AquaLogic Data Services Platform プロシージャの呼び出し

動的 Mediator API では、関数およびプロシージャの呼び出しに、それぞれ 2 種類の方法が用意されています (表 3-4 を参照してください)。

コード内には、表 3-4 に示すような例外の発生を避けるため、関数またはプロシージャ用にそれぞれ適切なメソッド呼び出し (invoke() または invokeProcedure()) を使用する必要があります。

表 3-4 Data Service Mediator API (クライアント Mediator API) のメソッド署名
メソッド署名
説明
invoke(String method, Object[] args)
データ サービスの読み込みおよびナビゲート関数を呼び出すメソッド。 AquaLogic Data Services Platform プロシージャに invoke() を使用して例外を発生させる。
invokeProcedure(String method, Object[] args)
データ サービスのプロシージャ (副作用のあるストアド プロシージャ、Web サービス、Java コード) を呼び出すメソッド。 読み込みまたはナビゲーション関数に invokeProcedure() を使用して例外を発生させる。
submit(DataObject sdo)
Mediator サービスに対し変更を送信するメソッド。 DataObject の一部として変更内容のまとめがあることを想定する。

詳細については、「AquaLogic Data Services Platform Mediator API Javadoc」のデータ サービス API Javadocs を参照してください。

静的 Mediator API を使用する場合、AquaLogic Data Services Platform 関数およびプロシージャの呼び出し間の区別が非表示になります。 読み込みおよびナビゲート関数とプロシージャは、プロシージャによる副作用があるかどうかを提示せずに、関数名に基づいて名前が付けられます。

静的および動的 Mediator API

AquaLogic Data Services Platform アーティファクトを持つサーバに対する初期コンテキストを取得すると、データ サービス用のリモート インタフェースをインスタンス化できます。 開発時にデータ サービスの型がわかっている場合は、静的データ オブジェクトを使用する静的データ サービス インタフェースを使用できます。

また、動的インタフェースでは、実行時に指定したデータ サービスを使用することができます。 静的インタフェースには、Eclipse やその他の開発ツールを使用する場合に型検証やコード補完などを実行できるなど、さまざまな利点があります。

静的 Data Service Mediator API の使用

静的データ サービス インタフェースを使用するには、特定の AquaLogic Data Services Platform 対応アプリケーションから生成された SDO Mediator Client JAR ファイルが必要です。 (JAR がない場合は、管理者に連絡して取得してください。)

JAR ファイルをクライアント アプリケーションのビルド パスに追加し、クライアント アプリケーションの基礎となる Java クラス ファイルにデータ サービス パッケージをインポートします。

たとえば、customerApp という名の AquaLogic Data Services Platform プロジェクト内にある Customer というデータ サービスを使用するには、以下の import 文を使用します。

	import customerapp.Customer; 

インポートしたファクトリ クラスおよびインタフェースが Java アプリケーションで使用可能になると、次の引数を使用して getInstance() メソッドを呼び出し、特定のデータ サービスに対するインタフェースをインスタンス化できます。

リモート データ サービス インスタンスを取得したら、データ サービス上で関数とプロシージャを呼び出すことができます。 たとえば、図 3-5 に示すデータ サービスを想定します。

図 3-5 Customer データ サービス


図 3-5 示されているデータ サービスに基づき、型付きのクライアント インタフェース用に生成されたアーティファクトには、動的データ API および静的 Mediator API の両方に対応する静的メソッドが含まれます。詳細については、リスト 3-1 を参照してください。 リスト 3-1 に示すように、データ サービスからの各読み込みおよびナビゲート関数は、getCustomer( ) および getApplOrder( ) などの静的データ API メソッドになります。

リスト 3-1 生成された Customer DataService クラスの静的メソッド
getCustomer()
getCustomerByCustID(String)
getCustomerByCustIDToFile(String, String)
getCustomerByZip(String)
getCustomerByZipToFile(String, String)
getCase(CUSTOMERPROFILEDocument)
getCreditCard(CUSTOMERPROFILEDocument)
getApplOrder(CUSTOMERPROFILEDocument)
getElecOrder(CUSTOMERPROFILEDocument)
getCustomerByLoginID(String)

getCustomer() や get CustomerByLoginID() など、上記に示されている生成された SDO データ API メソッドの詳細については、「静的データ API」を参照してください。

動的 API の一部であり、すべての静的 DataService クラスによって継承される DataService メソッドがいくつかあります。 これらには、以下のものが含まれます。

リスト 3-2 では、静的インタフェースの使用法について、短いながら完全な例が示されています。

リスト 3-2 データ サービスに静的インタフェースを使用する Mediator クライアント サンプル
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
import dataservices.rtlservices.Customer; //
import retailerType.CUSTOMERPROFILEDocument;

public class MyTypedCust
{
public static void main(String[] args) throws Exception {
//Get access to AquaLogic Data Services Platform data service
Hashtable h = new Hashtable();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL,"t3://localhost:7001");
h.put(Context.SECURITY_PRINCIPAL,"weblogic");
Context context = new InitialContext(h);

// Use the typed Mediator API
Customer customerDS = Customer.getInstance(context, "RTLApp");
CUSTOMERPROFILEDocument[] myCust =
     customerDS.getCustomerByCustID("CUSTOMER2");
System.out.println(" CUST" + myCustomer);
}
}

動的 Mediator API の使用

動的データ サービス インタフェースは、開発時には不明または存在しないデータ サービスのプログラミングに便利です。 たとえば、複数のデータ サービスにわたって稼動するツールやユーザ インタフェースの開発などに役立ちます。

動的インタフェースを使用すると、特定のデータ サービスの名前が一般的な get( ) および set( ) メソッド呼び出し内でパラメータとして渡されます。 例 :

DataService ds = DataServiceFactory.newDataService(
context, "RTLApp", "ld:DataServices/RTLServices/Customer");
Object[] params = {"CUSTOMER2"};
DataObject myCustomer = (DataObject)ds.invoke("getCustomerByCustomerID", params);
System.out.println(myCustomer.get("Customer/LastName"));

動的インタフェースにより戻されたデータ オブジェクトは、以下のように、静的オブジェクトにダウンキャストできます。

     DataService ds = 
DataServiceFactory.newDataService(
context, "RTLApp", "ld:DataServices/Customer");
Object[] params = {"CUSTOMER2"};
CUSTOMERDocument myCustomer =
(CUSTOMERDocument) ds.invoke("getCustomer", params);
System.out.println(myCustomer.getCUSTOMER().getCUSTOMERNAME() );
注意 : このコード例は、生成された静的 SDO Mediator JAR がコンパイル時および実行時にクラスパス上にある場合にのみ動作します。

動的データ サービスの場合は、DataServiceFactory クラスの newDataService( ) メソッドを使用します。 メソッド呼び出しでは、次の引数を渡します。

リスト 3-3 は完全な例を示します。

リスト 3-3 動的 Mediator API データ サービス インタフェースを使用する Mediator クライアント サンプル
import com.bea.ld.dsmediator.client.DataService;
import com.bea.ld.dsmediator.client.DataServiceFactory;
import commonj.sdo.DataObject;
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;

public class MyUntypedCust
{
public static void main(String[] args) throws Exception {

//Liquid Data へのアクセスを取得
Hashtable h = new Hashtable();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL,"t3://localhost:7001");
h.put(Context.SECURITY_PRINCIPAL,"weblogic");
h.put(Context.SECURITY_CREDENTIALS,"weblogic");
Context context = new InitialContext(h);

// 動的 (型なし) Mediator API を使用
DataService ds =
DataServiceFactory.newDataService(context, "RTLApp",
"ld:DataServices/RTLServices/Customer");
DataObject myCustomer = (DataObject) ds.invoke("getCustomer", null);
System.out.println(" Customer Information: \n" + myCustomer);
}
}

静的および動的 SDO API

静的または動的 SDO API のいずれかを使用してデータ サービス関数を呼び出すことができます。 動的 API は、一般的に汎用 SDO と呼ばれています。これは、クライアント側で JAR ファイルを通じて SDO オブジェクトを実体化する必要がないためです。 代わりに、データ サービスの基礎にあるスキーマに関するユーザの知識に基づいて、適切な set( ) または get( ) メソッドを呼び出すだけです。

それぞれの方法には、以下の表 3-6 に示されている利点と短所があります。

表 3-6 静的 vs. 動的 Mediator API
メソッド
利点
短所
静的 (型付き)
  • 実行時の型検証
  • ほとんどの IDE でコード補完
  • [App]-ld-client JAR ファイルの生成が必要
動的 (型なし)、汎用 SDO を使用
  • スキーマ変更に容易に適合
  • スキーマからの Java クラスのコンパイルが不要
  • オーバーヘッドがより低い
  • 実行時の型チェックなし

静的および動的 Mediator API オプションについては、次を参照してください。

静的 Data Service Mediator API の使用

動的 Mediator API の使用

静的 SDO API の使用

AquaLogic Data Services Platform アーティファクトを持つサーバに対する初期コンテキストを取得すると、データ サービス用のリモート インタフェースをインスタンス化できます。 開発時にデータ サービスの型がわかっている場合は、静的データ オブジェクトを使用する静的データ サービス インタフェースを使用できます。 (また、動的 SDO インタフェースでは、実行時に指定したデータ サービスを使用することができます。 これについては、「動的 Mediator API の使用」で説明します。)

静的インタフェースには、Eclipse やその他の開発ツールを使用する場合、タイプ検証やコード完了などを含むさまざまな利点があります。

静的データ サービス インタフェースを使用するには、クライアント アプリケーションで使用するクエリ関数を含む特定の AquaLogic Data Services Platform 対応アプリケーションから生成された SDO Mediator Client JAR ファイルが必要です。 (JAR がない場合は、管理者に連絡して取得してください。)

JAR ファイルをクライアント アプリケーションのビルド パスに追加し、クライアント アプリケーションの基礎となる Java クラス ファイルにデータ サービス パッケージをインポートします。

たとえば、customerApp という名の AquaLogic Data Services Platform プロジェクト内にある Customer というデータ サービスを使用するには、以下の import 文を使用します。

	import customerapp.Customer; 

インポートしたファクトリ クラスおよびインタフェースが Java アプリケーションで使用可能になると、次の引数を使用して getInstance() メソッドを呼び出し、特定のデータ サービスに対するインタフェースをインスタンス化できます。

リモート データ サービス インスタンスを取得すれば、データ サービス上で関数とプロシージャを呼び出すことができます。 たとえば、図 3-5 に示すデータ サービスを想定します。

図 3-7 サンプル Customer データ サービス


静的クライアント インタフェース用に生成したアーティファクトには、動的データ API および静的 Mediator API の両方に対応する型付きのメソッドが含まれます。 リスト 3-1 に示すように、データ サービスからの各読み込みおよびナビゲート関数は、getCustomer( ) および getApplOrder( ) などの静的データ API メソッドになります。

リスト 3-4 生成された Customer DataService クラスの静的メソッド
getCustomer()
getCustomerByCustID(String)
getCustomerByCustIDToFile(String, String)
getCustomerByZip(String)
getCustomerByZipToFile(String, String)
getCase(CUSTOMERPROFILEDocument)
getCreditCard(CUSTOMERPROFILEDocument)
getApplOrder(CUSTOMERPROFILEDocument)
getElecOrder(CUSTOMERPROFILEDocument)
getCustomerByLoginID(String)

上記に示されているような、生成された SDO データ API についての詳細は、「静的データ API」を参照してください。

動的 API の一部である複数の DataService があり、以下のメソッドを含むすべての静的 DataService クラスにより継承されています。

リスト 3-2 では、静的インタフェースの使用法について、短いながら完全な例が示されています。

リスト 3-5 データ サービスに静的インタフェースを使用する Mediator クライアント サンプル
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
import dataservices.rtlservices.Customer; //
import retailerType.CUSTOMERPROFILEDocument;

public class MyTypedCust
{
public static void main(String[] args) throws Exception {
//Get access to AquaLogic Data Services Platform data service
Hashtable h = new Hashtable();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL,"t3://localhost:7001");
h.put(Context.SECURITY_PRINCIPAL,"weblogic");
Context context = new InitialContext(h);

// Use the typed Mediator API
Customer customerDS = Customer.getInstance(context, "RTLApp");
CUSTOMERPROFILEDocument[] myCust =
     customerDS.getCustomerByCustID("CUSTOMER2");
System.out.println(" CUST" + myCustomer);
}
}

動的 SDO API の使用

動的データ サービス インタフェース (汎用 SDO) は、開発時には不明または存在しなかったデータ サービスのプログラミングに便利です。

動的 SDO を使用する場合、DataObjects は、以下の項目を決定する場合に XML スキーマに依存します。

動的 SDOは、DataObject 上の get( ) および setType( ) を通じて SDO API を正しくサポートします。

このような SDO 定義は、単一の汎用的な DataGraph および多数の DataObject クラスで構成されています。

動的 SDO は、createRootDataObject( ) メソッドを使用して作成されます。

DataObject /* root SDO document */ createRootDataObject()

リスト 3-6 のコードは、動的 SDO を使用するオペレーションのうち、よく知られているものを示しています。

XML スキーマを動的 SDO オペレーションに対して使用可能にする方法

XML スキーマは、クライアント側では使用できないため、動的 Mediator により、サーバからスキーマをダウンロードする必要があります。 スキーマをダウンロードする内部的な方法は、EJB クライアントを使用しているか、あるいは Web サービス クライアントを使用しているかによって異なります。

スキーマ型のキャッシング

SchemaTypeSystem の生成は、コストがかかる場合があります。 このため、API のフラッシュおよびクリアを通じたスキーマの再使用およびライフサイクル管理を可能にするスキーマ キャッシング機能が用意されています。

クライアント側でデータ サービス インスタンスの取得にキャッシュが渡されない場合は、内部キャッシュが作成されます。 内部スキーマ キャッシュのデフォルトの有効期間は、データ サービス インスタンスの有効期間と同じです。

データ サービスごとにキャッシュ オブジェクトを作成したり、複数のデータ サービス用に作成することもできます。 すべてのキャッシュはスレッドセーフです。 (複数の AquaLogic Data Services Platform アプリケーション間での差別化要因がないため、キャッシュは複数のアプリケーション間で共有しないようにしてください。)

以下のスキーマ キャッシング API を使用できます。

スキーマ キャッシュ管理シナリオ

いくつかのスキーマ キャッシュ管理シナリオを次に示します。

Mediator API 使用時のデータ キャッシュのバイパス

データ サービス関数により取得されたデータは、迅速にアクセスできるようにキャッシュに格納されます。 これは、データ キャッシングとして知られます。 (詳細については、AquaLogic Data Services Platform『管理ガイド』の「クエリ結果キャッシュのコンフィグレーション」を参照してください。) データ変更があまり頻繁になされないと思われる場合は、キャッシュ機能が役立ちます。

リスト 3-7 に示すように、関数内で GET_CURRENT_DATA 属性をバイパスすると、データ キャッシュをバイパスすることができます。 GET_CURRENT_DATA によりブール値が戻されます。 副生成物として、キャッシュも更新されます。

リスト 3-7 Mediator API 使用時のキャッシュ バイパス例
dataServices.customermanagement.CustomerProfile customerProfileDS = customerDS=dataServices.customermanagement.CustomerProfile.getInstance(ctx,appName);

RequestConfig config = new RequestConfig();

attr.enableFeature(RequestConfig.GET_CURRENT_DATA);

CustomerProfileDocument customerProfileDoc customerPlofileDS.CustomerProfile(params,config);

データ キャッシュのクライアント管理

AquaLogic Data Services Platform クエリを呼び出すと、REFRESH_CACHE_EARLY 属性と GET_CURRENT_DATA 属性を併用して、データ キャッシュの動作をより正確にコントロールできるようになります。

GET_CURRENT_DATA 属性の設定

GET_CURRENT_DATA 属性が True に設定されている場合は、以下のようになります。

REFRESH_CACHE_EARLY 属性の設定

GET_CURRENT_DATA プロパティが False に設定されているかまたは呼び出されていない場合は、REFRESH_CACHE_EARLY を使用して、関数のデータ キャッシュで使用できる残りの TTL (time-to-live : 生存時間) に基づきキャッシュ データを使用するかどうかをコントロールできます。

REFRESH_CACHE_EARLY 属性は整数型です。 setIntegerAttribute( ) メソッドを呼び出すことにより設定されます。 REFRESH_CACHE_EARLY を特定の値に設定するには、使用する前に、キャッシュ レコードに少なくとも n 秒以上の使用可能な TTL が残されている必要があります。 レコードの期限が n 秒以内に切れる場合は取得されません。 代わりに、この値が基礎となるデータに基づいて再計算され、その関数に関連するデータ キャッシュが更新されます。 クエリ評価中は、同一の REFRESH_CACHE_EARLY 値がすべてのキャッシュ オペレーションに適用されます。

注意 : REFRESH_CACHE_EARLY に提供された整数値は、常に正の値にする必要があります。 負の値は無視されます。

 


WebLogic Server 9.2 クライアント経由でのデータ サービスへのアクセス

この節では、AquaLogic Data Services Platform 2.x および WebLogic Server 9.2 を相互運用可能にする方法について説明します。 相互運用性が設定されると、WebLogic Server 9.2 クライアントから AquaLogic Data Services Platform 2.x データ サービスにアクセスできるようになります。

サンプル Customer データ サービス

注意 : AquaLogic Data Services Platform 2.x は、WebLogic Server 8.x. で実行します。

以下の手順に従って、WebLogic Server 9.2 クライアントおよび AquaLogic Data Services Platform 2.x の相互運用を可能にします。

相互運用の設定手順

  1. setDomainEnv.{cmd|sh} を編集し、AquaLogic Data Services Platform 2.x サーバ上の PRE_CLASSPATH${WLS_HOME}/liquiddata/lib/wls90interop.jar を入れます。
  2. 注意 : この変更を行った後は、AquaLogic Data Services Platform 2.x サーバの非 JDK 1.5 ベースのすべてのクライアントのクラス パスについて、他のクラスの前に wls90interop.ear を入れる必要があります。
  3. Workshop.cfg-cp キーの値を修正し、WebLogic Workshop のクラスパスの ${WL_HOME}/liquiddata/lib/wls90interop.jar に入れます。
  4. Workshop 内でアプリケーションを構築します。
  5. コマンド ラインに以下の引数を指定し、${WL_HOME}/liquiddata/bin/ld_clientapi.xml を使用して、クライアント側の JAR を構築します。
  6. -Dapproot=<application directory>

    -Dxbeanjarpath=${WEBLOGIC9x}/server/lib/xbean.jar

  7. ${WL_HOME}/liquiddata/lib/wlsdo90interop.jar, ld-client.jar および <appName>-ld-client.jarWEB-INF/lib または 9.2 サーバ側のクラスパスにコピーします。
  8. 注意 : WebLogic 9.0 リリースを使用している場合は、WLS 9.0. に付属する XMLBeans V2 をアップグレードする必要があります。 WLS 9.1 以上の XMLBeans を使用する必要があります。

 


手順 : Java クライアント プログラミング例

この節では、一般的な Java クライアント アプリケーション プログラミングのタスクについて説明します。

クライアント アプリケーション開発には、SDO データ API およびクライアント Mediator API (これは、リモート サーバへのローカル プロキシのインスタンス化に使用) が含まれます。また、Update SDO API (データ サービスに変更したデータ オブジェクトを送信するため) が含まれる可能性もあります。 したがって、この節の手順には、Mediator API や SDO を使用した呼び出し (たとえば、getInstance( ) および submit( ) ) が含まれます。

手順 1: データ オブジェクトのインスタンス化と入力

クライアント アプリケーションからの SDO データ オブジェクトの処理は、データ サービスへのインタフェースの取得 (静的または動的) から開始されます。 実行方法に応じて、生成した静的データ型インタフェースまたは動的データ インタフェースと、データ サービス インタフェースをインポートする必要があります。

表 3-8 に静的および動的 Mediator API インタフェースを示します。

表 3-8 静的および動的 Mediator API インタフェース
静的 Mediator API
動的 Mediator API

Customer cust = Customer.getInstance(
  context, "MyApp");

DataService ds =
DataServiceFactory.newDataService(
  context, "MyApp",  "ld:DataServices/CustomerDB/CUSTOMER");

静的 Mediator API のローカル インタフェースをインスタンス化するには、コンテキスト、アプリケーション名、およびデータ サービス名を DataServiceFactory クラスに渡します。 静的 Mediator API の場合は、ローカル インタフェースが getInstance() メソッドを使用してインスタンス化されます (JNDI コンテキストの確立後)。

ローカル インタフェースの構成後は、データ サービス関数を呼び出してデータ オブジェクトを取得します。

データ サービス プラットフォームおよびサービス データ オブジェクト (SDO)」で説明したように、戻されたデータ オブジェクトがデータ グラフに関連付けられています。 また、データ グラフは、データ グラフのルート データ オブジェクトのハンドルを提供します。

表 3-11 では、データ オブジェクトの入力における静的および動的な方法の両方を示します。 静的データ API の例は、データ グラフのルート ノードのインスタンス化方法を示します。この例では、論理データ サービス関数 (getCustomerView( ) ) で構成されているデータが使用されています。 例では、Customer3 に関する情報を選択しています。

動的な例では、データ グラフのルート ノードが、データ サービスを通じて使用可能なすべての顧客の配列とともに入力されています。

表 3-9 は、SDO のインスタンス化に使用可能な静的および動的 Mediator API を示しています。

表 3-9 静的および動的 Mediator API
静的 Mediator API
動的 Mediator API
CUSTOMERDocument[] custDoc =
ds.getCustomerView("CUSTOMER3");

DataObject[] custDoc =
  ds.invoke("CUSTOMER", null);

手順 2: データ オブジェクト プロパティへのアクセス

データ オブジェクトを取得すると、生成された静的データ API または動的データ APIのいずれかを使用して、データ オブジェクトのプロパティにアクセスできるようになります。表 3-10 は、静的および動的メソッドを使用してプロパティにアクセスする方法についての比較を示しています。 静的インタフェースは、単一の CUSTOMER オブジェクトを戻します。動的インタフェースは、汎用データ オブジェクトを戻します。

表 3-10 静的および動的 Mediator API によるプロパティ 取得の例
静的 Mediator API
動的 Mediator API
CUSTOMERDocument.CUSTOMER cust = custDoc[0].getCUSTOMER();
String lastName = cust.getLASTNAME();

DataObject cust = custDoc[0].get("CUSTOMER");
String lastName = (String) cust.get("LAST_NAME");

静的インタフェースを使用し、型名 (文字列として) が dynamic get( ) メソッドへのパラメータとして渡されます。 戻されるオブジェクトは、その後、必要な型にキャストできます。

戻される型が未バインドの場合は、戻されたオブジェクトをリストにキャストする必要があります。 未バインド型のすべてのオブジェクトを通過させるには、リスト 3-8 に示すように、反復子を使用する必要があります。

リスト 3-8 反復子を使用して、戻されたデータ オブジェクトのリストを通過させる
List addressList = (List) cust.get("ADDRESS");
Iterator iterator = addressList.iterator();
while ( iterator.hasNext() ){
CUSTOMERDocument.CUSTOMER.ADDRESS address =       (CUSTOMERDOcument.CUSTOMER.ADDRESS) iterator.next();
}
}

SDO アクセッサの引数内のプロパティは、要素名別に識別できます。 アクセッサ メソッドは、以下のように、XPath 式として指定されたプロパティ識別子を取ることができます。

   customer.get("CUSTOMER_PROFILE[1]/ADDRESS[AddressID="ADDR_10_1"]")

例では、指定 addressID を使用して指定したパスで ADDRESS を取得します。 要素識別子が同じ値の場合は、すべての要素が戻されます。

たとえば、ADDRESS には、CustomerID (顧客は、1 つ以上のアドレスを持つことができる) も含まれているため、すべてのアドレスが戻されることがあります。 (get( ) メソッドは DataObject を戻すため、戻されたオブジェクトを適切な型にキャストする必要があるので注意してください。 未バインド オブジェクトの場合は、リストを使用する必要があります。)

注意 : インデックス ポジションを指定する場合、SDO では一般的な XPath 表記法 (one-based) および Java スタイル (zero-based) をサポートしています。 詳細については、「動的 Data API における XPath のサポート」を参照してください。

XPath 表記を伴う get() メソッドを使用すると、親データ オブジェクトを含むデータ オブジェクトを取得できます。

	myCustomer.get("..")

XPath 表記を伴う get() メソッドを使用すると、データ オブジェクトを含むルートを取得できます。

	myCustomer.get("/")

これは、myCustomer.getDataGraph( ).getRootObject( ) の実行に似ています。

戻り値の型の数値化

データ サービス関数からの戻り値の型は、表 3-11 に示すセマンティクスに基づき数値化できます。

表 3-11 戻り値の型の記号とその定義の数値化
限定子記号
定義
コメント
+
星 (*) と同じセマンティクス
すべてを戻す。
?
未修飾と同じセマンティクス。ただし、空の結果の可能性を処理するための追加のビルトイン ロジックがある場合を除く。
結果が空の場合は、静的 Mediator メソッドの戻り値は以下のいずれかになる。
  • Null。 Java の戻り値の型がプリミティブでない場合 (DataObject、BigDecimal、String などの型付きのサブクラス) は、Null が戻される。
  • 最適値。 Java の戻り値がプリミティブ (int、floatなど) の場合は、最適値が戻される。
「最適値」は、たとえば OUTPUT_FILENAME の例で RequestConfig が結果送信を防止する際に戻されるものと同じ。
整数値型の場合は、最適値が対応する MIN_VALUE になります。浮動小数点数値型では NaN (数字ではない)、ブールの場合は、False になる。

手順 3: データ オブジェクトおよびプロパティの変更、挿入、削除

デフォルトでは、データ グラフの変更追跡が有効になっているため、オブジェクト値に対して行った変更が変更内容のまとめに記録されます。

データ オブジェクト プロパティの変更

表 3-12 は、動的または静的 set( ) メソッドのいずれかを使用してデータ オブジェクト プロパティを変更する方法を示しています。

表 3-12 プロパティの静的および動的 Mediator API 設定の例
静的 Mediator API
動的 Mediator API
cust.setLASTNAME("Smith");
cust.set("LAST_NAME", "Smith");

どちらの方法でも、新規プロパティ値に対する文字列引数を取り、顧客オブジェクトの姓を“Smith”に変更します。 静的 Mediator API の例では、データ サービス上で静的インタフェースをインスタンス化していることを前提としています。

新規データ オブジェクトの挿入

addNew() メソッド (静的データ API) を使用して、新規データ オブジェクトを作成できます。 新規データ オブジェクトは、ルート データ オブジェクトに追加するか、または、より一般的な方法として、データ オブジェクト配列の新規要素として追加できます。 (新規配列も、データ オブジェクトに追加できます。) オブジェクトを配列に挿入するときは、submit() を呼び出す前に、XML スキーマで指定されているとおり、新規オブジェクトに必要なすべてのフィールドを設定する必要があります。

リスト 3-9 は、データ オブジェクトをオブジェクト配列に挿入する方法を示しています。

リスト 3-9 新規データ オブジェクトを配列に挿入する
CUSTOMERDocument.CUSTOMER newCust = custDoc[0].addNewCUSTOMER();
  int idNo = custDoc.length;
  newCust.setCUSTOMERID("CUSTOMER" + String.valueOf(idNo));
  newCust.setFIRSTNAME("Clark");
  newCust.setLASTNAME("Kent");
  newCust.setCUSTOMERSINCE(java.util.Calendar.getInstance());
  newCust.setEMAILADDRESS("kent@dailyplanet.com");
  newCust.setTELEPHONENUMBER("555-555-5555");
  newCust.setSSN("509-00-3683");
  newCust.setDEFAULTSHIPMETHOD("Air");
新規データ オブジェクトの挿入

テーマを変化させるには、新規データ オブジェクトを一から作成します。 RDBMS では、これを新規レコードの作成と見なしています。

リスト 3-10 は、customer "from scratch" というデータ オブジェクトの作成を示しています。

リスト 3-10 新規データ ソースの作成
queryPlansDataServices.customer.CUSTOMERDocument customerDocument= queryPlansDataServices.customer.CUSTOMERDocument.Factory.newInstance();
queryPlansDataServices.customer.CUSTOMERDocument.CUSTOMER

customer=customerDocument.addNewCUSTOMER();
customer.setLASTNAME("KAY_99");
customer.setFIRSTNAME("JOHN_99");
customer.setCUSTOMERID("CUSTOMER_99");
customer.setCITY("SAN JOSE");
customer.setCUSTOMERSINCE(Calendar.getInstance());
customer.setEMAILADDRESS("m@a.com");
customer.setTELEPHONENUMBER(new BigInteger("4085708612")); customer.setZIPCODE(new BigInteger("95131")); customer.setSTATE("CA");
RDBMS に関する考慮事項

追加するオブジェクトに関連するデータ ソースが RDBMS である場合は、以下のような考慮事項を注意してください。

データ オブジェクトの削除

データ オブジェクトを削除するには、データ オブジェクトを含むデータ グラフから削除する必要があります。 For example, Listing 3-11 searches a CUSTOMER array for a specific customer's name and deletes that customer.

リスト 3-11 データ オブジェクトの削除
dataServices.customer.CUSTOMERDocument[] customers=customerDS.CUSTOMER();
for (int i=0; i < customers.length; i++){
if (customers[i].getCUSTOMER().getFIRSTNAME().equals("JOHN_99") && customers[i].getCUSTOMER().getLASTNAME().equals("KAY_99")) {
customers[i].getCUSTOMER().delete();
customerDS.submit(customers[i]);
}
}

オブジェクトをコンテナから削除する場合、オブジェクトの参照のみが削除され、値は削除されません。値は、後で Java ガベージ コレクション中に削除されます。

データ オブジェクト インタフェース (commonj.sdo パッケージ内の DataObject) では、オブジェクトの削除に delete( ) メソッドが準備されています。

オブジェクトの削除は、カスケード スタイルのオペレーションです。つまり、削除するオブジェクトの子も同じように削除されます。 ただし、子は削除せずにオブジェクトのみを削除した場合は、削除時に変更内容のまとめに記録されるので注意してください。

手順 4: データ サービスへの変更の送信

データ変更を送信するには、以下のようにルートが変更されたオブジェクトを渡すオブジェクトにバインドされているデータ サービスで submit() メソッドを呼び出します。

custDS.submit(myCustomer);

submit オペレーションの基本例については、リスト 3-12 を参照してください。

リスト 3-12 静的インタフェース
CUSTOMER custDS = CUSTOMER.getInstance(ctx, "RTLApp");
CUSTOMERDocument[] custDoc = (
CUSTOMERDocument[]) custDS.CUSTOMER();
custDoc[0].getCUSTOMER().setLASTNAME("Nimble");
custDS.submit(CustDoc);

リスト 3-13 では、動的インタフェースを使用してデータ オブジェクトを変更しています。

リスト 3-13 動的インタフェース
import com.bea.dsp.dsmediator.client.DataService;
import com.bea.dsp.dsmediator.client.DataServiceFactory;
import commonj.sdo.DataObject;

DataService custDS =
DataServiceFactory.newDataService(getInitialContext(), "MyDSPApp",
"ld:MyDSPAppDataServices/CUSTOMER");
DataObject[] custDocs = (DataObject[])custDS.invoke("CUSTOMER",
null);
DataObject custDoc=custDocs[0];
DataObject customer=(DataObject)custDoc.get("CUSTOMER");
customer.set("LAST_NAME","Nimble");
custDS.submit(custDoc);

 


Java クライアント アプリケーションの検査

リスト 3-14 は、前述した多数の手順をもう一度説明する完全な例を示しています。 この例の SDO クライアント アプリケーションでは、静的 Mediator API を使用して CUSTOMER データ サービスへのハンドルを作成しています。

クライアント アプリケーションでは、顧客に関する情報を抽出し、情報を変更して、その変更内容を送信します。 リスト 3-14 は、SDO クライアント プログラミングの基礎をいくつか示しているだけでなく、Mediator API を使用してデータ サービスへのハンドルを取得する方法、および、Update Mediator API を使用してデータ サービスに変更を送信する方法についても記載されています。

リスト 3-14 サンプル クライアント アプリケーション
import java.util.Hashtable;
import javax.naming.InitialContext;
import dataservices.customerdb.CUSTOMER;
public class ClientApp {
   public static void main(String[] args) throws Exception {
      Hashtable h = new Hashtable();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL,"t3://localhost:7001");
h.put(Context.SECURITY_PRINCIPAL,"weblogic");
h.put(Context.SECURITY_CREDENTIALS,"weblogic");
Context context = new InitialContext(h);
      // Customer データ サービスへのハンドルを作成
CUSTOMER custDS = CUSTOMER.getInstance(context, "RTLApp");
// 動的データ API を使用して SDO をインスタンス化 ("Customer" 形式)
CUSTOMERDocument[] myCustomer =
(CUSTOMERDocument[]) custDS.invoke("CUSTOMER", null);
     // 顧客名を取得および表示
String existingFName =
myCustomer[0].getCUSTOMER().getFIRSTNAME();
String existingLName =
myCustomer[0].getCUSTOMER().getLASTNAME();
     System.out.println(" \n---------------- \n Before Change: \n");
System.out.println(existingFName + existingLName);
     // 顧客名を変更
myCustomer[0].getCUSTOMER().setFIRSTNAME("J.B.");
myCustomer[0].getCUSTOMER().setLASTNAME("Kwik");
custDS.submit(myCustomer,"ld:DataServices/CustomerDB/CUSTOMER");
     //新規名を再クエリおよび出力
     myCustomer = (CUSTOMERDocument[]) custDS.invoke("CUSTOMER",null);
String newFName =
myCustomer[0].getCUSTOMER().getFIRSTNAME();
String newLName =
myCustomer[0].getCUSTOMER().getLASTNAME();
     System.out.println(" \n---------------- \n After Change: \n");
System.out.println(newFName + newLName); }
}

リスト 3-14 は、以下のように、SDO データ API および Mediator API の使用方法を示しています。

  1. アプリケーションでは、AquaLogic Data Services Platform がデプロイされている WebLogic Server を識別する JNDI コンテキストを渡しながら、Customer データ サービスへのリモート インタフェースをインスタンス化します。 静的 Mediator API をこの呼び出しに使用して、実際の Customer データ サービス インタフェースをインスタンス化します (動的 DataService インタフェースではない)。
  2. CUSTOMER custDS = CUSTOMER.getInstance(context, "RTLApp");

    custDS は、RTLApp WebLogic Server アプリケーション上で実行される CUSTOMER データ サービスのハンドルとして機能します。

  3. プログラムでは、CUSTOMERDocument オブジェクトの配列に結果を流し込みながら、Mediator API を使用して Customer データ サービスの読み込み関数を呼び出します。
  4. CustomerDocument[] myCustomer = 
    ( CustomerDocument[]) ds.invoke("CUSTOMER", null);
  5. データ オブジェクトを作成した後は、SDO の静的データ API (静的インタフェース) を使用してプロパティにアクセスできるようになります。これは、実際のノードの型

    myCustomer[0].getCUSTOMER().getFIRSTNAME(); を戻します。
  6. CUSTOMER の FIRSTNAME および LASTNAME プロパティの新規の値が静的データ API を使用して設定されます。
  7. myCustomer[0].getCUSTOMER().setFIRSTNAME("J.B.");
    myCustomer[0].getCUSTOMER().setLASTNAME("Kwik");
  8. 変更がデータ サービスに送信され (Client Mediator API の submit() を使用)、バックエンド データ ソースに送信されます。
  9. custDS.submit(myCustomer);
  10. Mediator API の invoke() メソッドがもう一度実行され、結果 (この時点で変更されたデータを表示) が出力されます。
注意 : 読み込みおよびナビゲーション関数の invoke( ) メソッドのみ。 データ サービス プロシージャの場合は、DataService インタフェースで使用できる invokeProcedure( ) メソッドを使用します。 Mediator API の詳細については、AquaLogic Data Services Platform Javadoc の「AquaLogic Data Services Platform Mediator API Javadoc」を参照してください。
注意 : プロシージャについての詳細は、「関数および AquaLogic Data Services Platform プロシージャの呼び出し」を参照してください。

例外処理用のコードは例には示されていませんが、SDO 実行時エラーは、SDOMediatorException を送出します。 また、SDOMediatorException クラスを使用して、データ ソース例外をラップすることもできます。


  ページの先頭       前へ  次へ