|
|
この章では、Java クライアント アプリケーションからデータ サービスにアクセスする方法について説明しています。 トピックは以下のとおりです。
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 に示されているクラスおよびインタフェースで構成されています。
この型付きのデータ サービス用のクラス宣言の例に示すとおり、静的 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 ファイル名に変更します。
クライアント アプリケーション開発者は、2 種類の SDO データ作業方法を選ぶことができます。
この章では、Mediator API について、および Java クライアント アプリケーションでの使用方法について説明します。 Data Service コントロールについては、「WebLogic Workshop アプリケーションからのデータ サービスへのアクセス」を参照してください。
クライアント アプリケーション開発者は、アプリケーション設計および特定の目的に応じて、表 3-2 に示す API をいくつか組み合わせて使用します。 また、データ サービス開発者も、SDO Update API (厳密には UpdateOverride インタフェース) を使用してデータ サービス機能をカスタマイズします。
クライアント アプリケーションでは、AquaLogic Data Services Platform プロジェクトから生成された JAR (Java アーカイブ) ファイルを使用して静的データ サービス インタフェースを表すクラスにアクセスできます。 クライアント アプリケーション開発者は、(通常はデータ サービス設計者または AquaLogic Data Services Platform 管理者から) この JAR ファイルを取得し、JAR ファイルを開発環境のクラスパスに追加する必要があります。
生成された静的 Mediator クライアント JAR ファイルの命名規約は、以下のとおりです。
<AppName>-ld-client.jar
データ サービス アプリケーションにより EAR ファイルが構築されると、データ サービスのクライアント バージョンである <AppName>-ld-client.jar ファイルを EAR から生成することができます。 クライアント バージョンには、クライアントから動的または静的 API を通じてデータ サービス関数を呼び出すことができるラッパー クラスがあります。
必要な JAR ファイルは、以下の 2 つの方法のいずれかを使用して生成できます。
setWLSEnv.sh を使用します。<beahome>/weblogic81/server/bin
ant -Doutdir=<output-directory> -Darchive=<archive> -Dtmpdir=\tmp\clientbld -fld_clientapi.xml
ant -Doutdir="c:\myApp" =Darchive=C:\bea\user_projects\applications\myApp.ear -Dtmpdir=c:\temp -fld_clientapi.xml
このクライアント JAR ファイルのサンプル プロシージャに示されているとおり、以下のようにコマンドを実行します。
C:\myApp-ld-client.jar
表 3-3 は、静的クライアント JAR Mediator の生成に使用できる引数について説明します。
Data Service Mediator API を使用してデータ サービス関数またはプロシージャを呼び出すには、以下の手順で Java クラスを作成します。
com.bea.dsp.dsmediator.client パッケージをインポートします。 | 注意 : | 詳細については、「AquaLogic Data Services Platform 用の WebLogic JNDI コンテキストの取得」を参照してください。 WebLogic Server コンテキストの詳細については、以下を参照してください。 |
DataService ds = DataServiceFactory.newDataService(
JndiCntxt, "RTLApp", "ld:DataServices/RTLServices/Customer");
静的インタフェースを使用した同じオペレーションの例を以下に示します。
CUSTOMER ds = CUSTOMER.getInstance(JndiCntxt, "RTLApp");
以下は、動的インタフェースを使用してデータ サービスの読み込み関数を呼び出すオペレーションです。
Object[] params = new Object { "CUSTOMER1" };
DataObject[] myCustomer =
(DataObject[]) ds.invoke("getCustomerByCustID", params);
静的インタフェースを使用した同じオペレーションの例を以下に示します。
CUSTOMERDocument myCust = ds.getCustomerByCustID("CUSTOMER1");
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);
必ず、使用する環境に合わせて、マシン名、ユーザ名、パスワードを適切な値で置き換えてください。
動的 Mediator API では、関数およびプロシージャの呼び出しに、それぞれ 2 種類の方法が用意されています (表 3-4 を参照してください)。
コード内には、表 3-4 に示すような例外の発生を避けるため、関数またはプロシージャ用にそれぞれ適切なメソッド呼び出し (invoke() または invokeProcedure()) を使用する必要があります。
invoke(String method, Object[] args) |
|
invokeProcedure(String method, Object[] args) |
|
submit(DataObject sdo) |
詳細については、「AquaLogic Data Services Platform Mediator API Javadoc」のデータ サービス API Javadocs を参照してください。
静的 Mediator API を使用する場合、AquaLogic Data Services Platform 関数およびプロシージャの呼び出し間の区別が非表示になります。 読み込みおよびナビゲート関数とプロシージャは、プロシージャによる副作用があるかどうかを提示せずに、関数名に基づいて名前が付けられます。
AquaLogic Data Services Platform アーティファクトを持つサーバに対する初期コンテキストを取得すると、データ サービス用のリモート インタフェースをインスタンス化できます。 開発時にデータ サービスの型がわかっている場合は、静的データ オブジェクトを使用する静的データ サービス インタフェースを使用できます。
また、動的インタフェースでは、実行時に指定したデータ サービスを使用することができます。 静的インタフェースには、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-5 示されているデータ サービスに基づき、型付きのクライアント インタフェース用に生成されたアーティファクトには、動的データ API および静的 Mediator API の両方に対応する静的メソッドが含まれます。詳細については、リスト 3-1 を参照してください。 リスト 3-1 に示すように、データ サービスからの各読み込みおよびナビゲート関数は、getCustomer( ) および getApplOrder( ) などの静的データ API メソッドになります。
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 では、静的インタフェースの使用法について、短いながら完全な例が示されています。
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);
}
}
動的データ サービス インタフェースは、開発時には不明または存在しないデータ サービスのプログラミングに便利です。 たとえば、複数のデータ サービスにわたって稼動するツールやユーザ インタフェースの開発などに役立ちます。
動的インタフェースを使用すると、特定のデータ サービスの名前が一般的な 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 は完全な例を示します。
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 のいずれかを使用してデータ サービス関数を呼び出すことができます。 動的 API は、一般的に汎用 SDO と呼ばれています。これは、クライアント側で JAR ファイルを通じて SDO オブジェクトを実体化する必要がないためです。 代わりに、データ サービスの基礎にあるスキーマに関するユーザの知識に基づいて、適切な set( ) または get( ) メソッドを呼び出すだけです。
それぞれの方法には、以下の表 3-6 に示されている利点と短所があります。
静的および動的 Mediator API オプションについては、次を参照してください。
静的 Data Service Mediator 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 に示すデータ サービスを想定します。
静的クライアント インタフェース用に生成したアーティファクトには、動的データ API および静的 Mediator API の両方に対応する型付きのメソッドが含まれます。 リスト 3-1 に示すように、データ サービスからの各読み込みおよびナビゲート関数は、getCustomer( ) および getApplOrder( ) などの静的データ API メソッドになります。
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 では、静的インタフェースの使用法について、短いながら完全な例が示されています。
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) は、開発時には不明または存在しなかったデータ サービスのプログラミングに便利です。
動的 SDO を使用する場合、DataObjects は、以下の項目を決定する場合に XML スキーマに依存します。
動的 SDOは、DataObject 上の get( ) および setType( ) を通じて SDO API を正しくサポートします。
このような SDO 定義は、単一の汎用的な DataGraph および多数の DataObject クラスで構成されています。
動的 SDO は、createRootDataObject( ) メソッドを使用して作成されます。
DataObject /* root SDO document */ createRootDataObject()
リスト 3-6 のコードは、動的 SDO を使用するオペレーションのうち、よく知られているものを示しています。
DataService custDS = DataServiceFactory.newDataService(context,"RTLApp","ld:DataServices/CustomerDB/CUSTOMER");
DataObject root =(DataObject)custDS.invoke("getCustomerByCustID", new Object[]{"CUSTOMER1"})[0];
DataObject myCustomer = root.getDataObject(0);
String name = myCustomer.getString("name");
//ナビゲーション関数を使用
DataObject order = (DataObject)custDS.invoke("getApplOrder", new Object[]{root})[0];
// 更新
myCustomer.setString("Street","Lake Drive");
((DataObject)myCustomer.getList("ADDRESS").get(0)).setString("City", "Hayward");
// 変更した SDO をサーバに送信
custDS.submit( root );
// DataObject を削除
((DataObject)myCustomer.getList("ADDRESS").get(0)).delete();
custDS.submit( root );
// 新規 SDO オブジェクトをクライアント側で作成
DataService custDS = DataServiceFactory.newDataService(context,"RTLApp","ld:DataServices/CustomerDB/CUSTOMER");
DataObject root = custDS.createRootDataObject ();
root.createDataObject("CUSTOMER_PROFILE").setString("FirstName","helloW");
custDS.submit( root );
XML スキーマは、クライアント側では使用できないため、動的 Mediator により、サーバからスキーマをダウンロードする必要があります。 スキーマをダウンロードする内部的な方法は、EJB クライアントを使用しているか、あるいは Web サービス クライアントを使用しているかによって異なります。
SchemaTypeSystem の生成は、コストがかかる場合があります。 このため、API のフラッシュおよびクリアを通じたスキーマの再使用およびライフサイクル管理を可能にするスキーマ キャッシング機能が用意されています。
クライアント側でデータ サービス インスタンスの取得にキャッシュが渡されない場合は、内部キャッシュが作成されます。 内部スキーマ キャッシュのデフォルトの有効期間は、データ サービス インスタンスの有効期間と同じです。
データ サービスごとにキャッシュ オブジェクトを作成したり、複数のデータ サービス用に作成することもできます。 すべてのキャッシュはスレッドセーフです。 (複数の AquaLogic Data Services Platform アプリケーション間での差別化要因がないため、キャッシュは複数のアプリケーション間で共有しないようにしてください。)
キー : ルート要素名と対象となるネームスペースで構成される Qname
値 : コンパイルされたスキーマ型オブジェクト
SchemaTypeCache.dump( String dsName ) //dump contents for specified DS
SchemaTypeCache.dump(); //dump entire contents
public void flush()
public void clear( String dsName )
// 注意 : 各 DS は独自のスキーマ型キャッシュを保持する。
SchemaTypeCache custSchemaTypes = new SchemaTypeCache();
SchemaTypeCache addrSchemaTypes = new SchemaTypeCache();
DataService custDS = DataServiceFactory.newDataService( context,
"RTLApp", "ld:DataServices/Customer", custSchemaTypes );
DataService addrDS = DataServiceFactory.newDataService( context, "RTLApp", "ld:DataServices/Address", addrSchemaTypes );
// 注意 : ユーザが複数の DS 間でキャッシュを管理する。
SchemaTypeCache schemaTypes = new SchemaTypeCache();
DataService custDS = DataServiceFactory.newDataService( context, "RTLApp", "ld:DataServices/Customer", schemaTypes );
DataService addrDS = DataServiceFactory.newDataService( context, "RTLApp", "ld:DataServices/Address", schemaTypes);
DataService custDS = DataServiceFactory.newDataService( context, "RTLApp", "ld:DataServices/Customer" );
DataService addrDS = DataServiceFactory.newDataService( context, "RTLApp", "ld:DataServices/Address" );
データ サービス関数により取得されたデータは、迅速にアクセスできるようにキャッシュに格納されます。 これは、データ キャッシングとして知られます。 (詳細については、AquaLogic Data Services Platform『管理ガイド』の「クエリ結果キャッシュのコンフィグレーション」を参照してください。) データ変更があまり頻繁になされないと思われる場合は、キャッシュ機能が役立ちます。
リスト 3-7 に示すように、関数内で GET_CURRENT_DATA 属性をバイパスすると、データ キャッシュをバイパスすることができます。 GET_CURRENT_DATA によりブール値が戻されます。 副生成物として、キャッシュも更新されます。
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 属性が True に設定されている場合は、以下のようになります。
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 に提供された整数値は、常に正の値にする必要があります。 負の値は無視されます。 |
この節では、AquaLogic Data Services Platform 2.x および WebLogic Server 9.2 を相互運用可能にする方法について説明します。 相互運用性が設定されると、WebLogic Server 9.2 クライアントから AquaLogic Data Services Platform 2.x データ サービスにアクセスできるようになります。
| 注意 : | AquaLogic Data Services Platform 2.x は、WebLogic Server 8.x. で実行します。 |
以下の手順に従って、WebLogic Server 9.2 クライアントおよび AquaLogic Data Services Platform 2.x の相互運用を可能にします。
setDomainEnv.{cmd|sh} を編集し、AquaLogic Data Services Platform 2.x サーバ上の PRE_CLASSPATH に${WLS_HOME}/liquiddata/lib/wls90interop.jar を入れます。| 注意 : | この変更を行った後は、AquaLogic Data Services Platform 2.x サーバの非 JDK 1.5 ベースのすべてのクライアントのクラス パスについて、他のクラスの前に wls90interop.ear を入れる必要があります。 |
Workshop.cfg の -cp キーの値を修正し、WebLogic Workshop のクラスパスの ${WL_HOME}/liquiddata/lib/wls90interop.jar に入れます。${WL_HOME}/liquiddata/bin/ld_clientapi.xml を使用して、クライアント側の JAR を構築します。
-Dapproot=<application directory>
-Dxbeanjarpath=${WEBLOGIC9x}/server/lib/xbean.jar
${WL_HOME}/liquiddata/lib/wlsdo90interop.jar, ld-client.jar および <appName>-ld-client.jar を WEB-INF/lib または 9.2 サーバ側のクラスパスにコピーします。| 注意 : | WebLogic 9.0 リリースを使用している場合は、WLS 9.0. に付属する XMLBeans V2 をアップグレードする必要があります。 WLS 9.1 以上の XMLBeans を使用する必要があります。 |
この節では、一般的な Java クライアント アプリケーション プログラミングのタスクについて説明します。
クライアント アプリケーション開発には、SDO データ API およびクライアント Mediator API (これは、リモート サーバへのローカル プロキシのインスタンス化に使用) が含まれます。また、Update SDO API (データ サービスに変更したデータ オブジェクトを送信するため) が含まれる可能性もあります。 したがって、この節の手順には、Mediator API や SDO を使用した呼び出し (たとえば、getInstance( ) および submit( ) ) が含まれます。
クライアント アプリケーションからの SDO データ オブジェクトの処理は、データ サービスへのインタフェースの取得 (静的または動的) から開始されます。 実行方法に応じて、生成した静的データ型インタフェースまたは動的データ インタフェースと、データ サービス インタフェースをインポートする必要があります。
<appname>-ld-client.jar ファイルに含まれています。 静的 SDO API を使用するには、次の 2 ステップのプロセスを実行します。import com.bea.dsp.dsmediator.client.DataServiceFactory;
表 3-8 に静的および動的 Mediator API インタフェースを示します。
静的 Mediator API のローカル インタフェースをインスタンス化するには、コンテキスト、アプリケーション名、およびデータ サービス名を DataServiceFactory クラスに渡します。 静的 Mediator API の場合は、ローカル インタフェースが getInstance() メソッドを使用してインスタンス化されます (JNDI コンテキストの確立後)。
ローカル インタフェースの構成後は、データ サービス関数を呼び出してデータ オブジェクトを取得します。
「データ サービス プラットフォームおよびサービス データ オブジェクト (SDO)」で説明したように、戻されたデータ オブジェクトがデータ グラフに関連付けられています。 また、データ グラフは、データ グラフのルート データ オブジェクトのハンドルを提供します。
表 3-11 では、データ オブジェクトの入力における静的および動的な方法の両方を示します。 静的データ API の例は、データ グラフのルート ノードのインスタンス化方法を示します。この例では、論理データ サービス関数 (getCustomerView( ) ) で構成されているデータが使用されています。 例では、Customer3 に関する情報を選択しています。
動的な例では、データ グラフのルート ノードが、データ サービスを通じて使用可能なすべての顧客の配列とともに入力されています。
表 3-9 は、SDO のインスタンス化に使用可能な静的および動的 Mediator API を示しています。
データ オブジェクトを取得すると、生成された静的データ API または動的データ APIのいずれかを使用して、データ オブジェクトのプロパティにアクセスできるようになります。表 3-10 は、静的および動的メソッドを使用してプロパティにアクセスする方法についての比較を示しています。 静的インタフェースは、単一の CUSTOMER オブジェクトを戻します。動的インタフェースは、汎用データ オブジェクトを戻します。
|
静的インタフェースを使用し、型名 (文字列として) が dynamic get( ) メソッドへのパラメータとして渡されます。 戻されるオブジェクトは、その後、必要な型にキャストできます。
戻される型が未バインドの場合は、戻されたオブジェクトをリストにキャストする必要があります。 未バインド型のすべてのオブジェクトを通過させるには、リスト 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-12 は、動的または静的 set( ) メソッドのいずれかを使用してデータ オブジェクト プロパティを変更する方法を示しています。
どちらの方法でも、新規プロパティ値に対する文字列引数を取り、顧客オブジェクトの姓を“Smith”に変更します。 静的 Mediator API の例では、データ サービス上で静的インタフェースをインスタンス化していることを前提としています。
addNew() メソッド (静的データ API) を使用して、新規データ オブジェクトを作成できます。 新規データ オブジェクトは、ルート データ オブジェクトに追加するか、または、より一般的な方法として、データ オブジェクト配列の新規要素として追加できます。 (新規配列も、データ オブジェクトに追加できます。) オブジェクトを配列に挿入するときは、submit() を呼び出す前に、XML スキーマで指定されているとおり、新規オブジェクトに必要なすべてのフィールドを設定する必要があります。
リスト 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" というデータ オブジェクトの作成を示しています。
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 である場合は、以下のような考慮事項を注意してください。
追加したオブジェクトがバックエンドのデータ ソースのリレーショナル レコードに対応しており、レコードが自動生成された主キー フィールドを持つ場合は、フィールドがデータベース ソースに生成され、プロパティ配列のクライアントに戻されます。 プロパティには、カラム名および自動生成された新規キー値に対応する名前値項目が含まれます。 ( 『クエリおよびデータ ビューの構築』の「データ サービスを介した更新の処理」の章での「KeyPair を使用してマップされた主キーと外部キーの関連性」を参照してください。)
データ オブジェクトを削除するには、データ オブジェクトを含むデータ グラフから削除する必要があります。 For example, Listing 3-11 searches a CUSTOMER array for a specific customer's name and deletes that customer.
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( ) メソッドが準備されています。
オブジェクトの削除は、カスケード スタイルのオペレーションです。つまり、削除するオブジェクトの子も同じように削除されます。 ただし、子は削除せずにオブジェクトのみを削除した場合は、削除時に変更内容のまとめに記録されるので注意してください。
データ変更を送信するには、以下のようにルートが変更されたオブジェクトを渡すオブジェクトにバインドされているデータ サービスで submit() メソッドを呼び出します。
custDS.submit(myCustomer);
submit オペレーションの基本例については、リスト 3-12 を参照してください。
CUSTOMER custDS = CUSTOMER.getInstance(ctx, "RTLApp");
CUSTOMERDocument[] custDoc = (
CUSTOMERDocument[]) custDS.CUSTOMER();
custDoc[0].getCUSTOMER().setLASTNAME("Nimble");
custDS.submit(CustDoc);
リスト 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);
リスト 3-14 は、前述した多数の手順をもう一度説明する完全な例を示しています。 この例の SDO クライアント アプリケーションでは、静的 Mediator API を使用して CUSTOMER データ サービスへのハンドルを作成しています。
クライアント アプリケーションでは、顧客に関する情報を抽出し、情報を変更して、その変更内容を送信します。 リスト 3-14 は、SDO クライアント プログラミングの基礎をいくつか示しているだけでなく、Mediator API を使用してデータ サービスへのハンドルを取得する方法、および、Update Mediator API を使用してデータ サービスに変更を送信する方法についても記載されています。
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 の使用方法を示しています。
CUSTOMER custDS = CUSTOMER.getInstance(context, "RTLApp");
custDS は、RTLApp WebLogic Server アプリケーション上で実行される CUSTOMER データ サービスのハンドルとして機能します。
CustomerDocument[] myCustomer =
( CustomerDocument[]) ds.invoke("CUSTOMER", null);myCustomer[0].getCUSTOMER().getFIRSTNAME(); を戻します。myCustomer[0].getCUSTOMER().setFIRSTNAME("J.B.");
myCustomer[0].getCUSTOMER().setLASTNAME("Kwik");custDS.submit(myCustomer);
| 注意 : | 読み込みおよびナビゲーション関数の invoke( ) メソッドのみ。 データ サービス プロシージャの場合は、DataService インタフェースで使用できる invokeProcedure( ) メソッドを使用します。 Mediator API の詳細については、AquaLogic Data Services Platform Javadoc の「AquaLogic Data Services Platform Mediator API Javadoc」を参照してください。 |
| 注意 : | プロシージャについての詳細は、「関数および AquaLogic Data Services Platform プロシージャの呼び出し」を参照してください。 |
例外処理用のコードは例には示されていませんが、SDO 実行時エラーは、SDOMediatorException を送出します。 また、SDOMediatorException クラスを使用して、データ ソース例外をラップすることもできます。
  
|
