|
|
BEA AquaLogic Data Services Platform では、クライアント アプリケーション プログラミング モデルとしてデータ サービス オブジェクト (SDO) が実装されています。 SDO は、ソースと非接続型のデータ オブジェクトを操作するためのアーキテクチャおよび API のセットです。 DSP では、SDOは、型付きデータ オブジェクトであるか、型なしデータ オブジェクトであるかにかかわらず、Mediator API または Data Service コントロールを介してデータ サービスから取得されます。 (「サービス データ オブジェクト (SDO) について」を参照してください。)
クライアント アプリケーションでは、必要に応じてビジネス プロセスのデータ オブジェクトが操作されると、基底のデータ ソースに伝播するために、変更されたオブジェクトがデータ サービスに送信されます。 SDO 仕様では、SDO を送受信できる Mediator サービス定義について定義されてはいませんが、一般的な必要性について説明されています。また、この仕様では、実装を指定せずに、データ ソースに対する更新を処理する必要性についても説明されています。SDO 仕様では、Mediator サービスの実装方法および Mediator サービスによるデータ オブジェクトの更新処理方法に関して、その詳細を開発者に委ねています。
更新フレームワークと Data Service Mediator」で説明されるように、DSP の Mediator は、クライアント アプリケーションとデータ サービスとの間での送受信を処理するだけでなく、あらゆるデータ サービスを構成するさまざまなデータ ソースの更新を円滑化します。
この章では、SDO データ プログラミング モデルの DSP の実装と、その更新フレームワークについて説明されています。
Data Service Mediator API 経由またはデータ サービス コントロールからデータ サービスの読み込み関数またはナビゲーション関数を呼び出すと、データ サービスでは、1 つまたは複数の データ オブジェクトを構成するデータ グラフ が戻されます。データ オブジェクトおよびデータ グラフは、SDO データ プログラミング モデルの 2 つの基本アーティファクトです。 図 2-1 で示すように、データ グラフは以下のような構成になっています。
変更内容のまとめは (論理データ サービスの分解マップと連動して) Mediator により使用され、それによって更新プランが派生し、最終的にデータ ソースが更新されます。 submit() が成功したかどうかにかかわらず、変更済みの各 SDO とともに送信された変更内容のまとめはそのまま残るため、必要に応じてロールバックをサポートできます。
表 2-2 では、さまざまな SDO データ プログラミング アーティファクト を示し、それぞれの例を一覧表示しています (図 2-1を参照)。
SDO では、データ オブジェクトの静的 (型付き) および動的 (型なし) インタフェースの両方が指定されます。
動的データ API は、開発時にデプロイされていなかったデータ型と共に使用することができます。
表 2-3 では各アプローチの利点の概要を示しています。
SDO の静的データ API は、データ サービスの XML スキーマ定義から生成される型付き Java インタフェースです。 このインタフェースは JAXB または XMLBean の静的インタフェースと似ています。 JAR にパッケージ化されているインタフェース ファイルは、通常、WebLogic Workshop または提供されたツールの 1 つを使用して、DSP データ サービス開発者により作成されます (詳細については、「静的 Web サービス クライアントの開発」を参照)。
生成されたインタフェースは、動的 API (特に、DataObject インタフェース) および XmlObject インタフェースの両方を拡張します。 したがって、生成されたインタフェースでは、XML データ型付きのすべてのプロパティに対して型付きゲッターおよびセッターが提供されます。
また、インタフェースが各複合プロパティに対して生成されます (図 2-4 に示される CREDIT および ORDERなど)。生成には複合型を構成するそれぞれのプロパティのゲッターおよびセッターが使用されます。
また、複数存在する可能性のあるプロパティに対しては、配列および配列要素を操作するためのゲッターおよびセッターも生成されます。 複数発生するプロパティは、maxOccurs 属性が未バインドまたは 1 より大きな値のいずれかに設定されている XML スキーマ要素です。 DSP Console Metadata Browser において、このような要素にはアスタリスクが付けられています。たとえば、ORDER* および POITEM* (図 2-4 を参照) は、配列データ オブジェクトまたは順序データ オブジェクト (ORDERS[ ]) が戻されることを示しています。 反復オブジェクトに関する結果については、戻されるオブジェクト (datatypename[]) の配列にルート要素がキャストされます。
| 注意 : | Data Services Platform の旧リリースでは、「ArrayOf...」スキーマ要素が作成され、データ グラフの一部として戻される配列型のコンテナとして役割を果たしています。 ArrayOf メカニズムへの参照の一部は、コード サンプルやドキュメント内に残ります。 |
静的データ API を生成させる方法の例として、図 2-4 に示される CUSTOMER データ型を指定し、以下のように型付きクライアント インタフェースの結果を生成します。
SDO の静的データ API を使用する Java クライアント アプリケーションを開発するときは、これらの XMLBeans により生成される型付きインタフェースを Java クライアント コードにインポートします。 例 :
import appDataServices.AddressDocument;
SDO API インタフェースでは、XMLBeans を使用してオブジェクトのシリアライゼーションおよびデシリアライゼーションを実行します。 クライアント アプリケーション開発者としては、このような詳細を認識する必要はほとんどありません。 しかし、DSP と WebLogic 統合ワークフロー コンポーネント (JPD、または Java プロセス定義) を統合する開発者は、データ オブジェクトを使用する JPD コードでは、デフォルトのシリアライゼーションとデシリアライゼーションを変更する必要があります。 詳細については、「AquaLogic Data Services Platform ベースのアプリケーションによるワークフローの使用」を参照してください。
DSP では XMLBeans を使用するため、SDO でも、基底の XMLBeans 技術の多くの機能を同じように利用できます。 たとえば、XmlObjects toString() メソッドを使用して DataObject を String にキャストすると、プリント出力されます。
表 2-5 に、静的データ API ゲッターおよびセッターを表示されます。
DSP クライアント アプリケーション開発者は、Data Services Platform Console を使用してデータ サービスと関連する XML スキーマ型を表示できます (図 2-4、DSP コンソール メタデータ ブラウザに表示される CUSTOMER 戻り値の型を参照)。 [戻り値の型] タブには、たとえば、string、int、または complex type などの各要素のデータ型が示されます。 XML スキーマ データ型は、表 2-6 に示すデータ型マッピングによって Java のデータ オブジェクトにマップされます。
動的データ API には、set( ) や get( ) などの汎用プロパティのゲッターおよびセッター、および、Java 特有のデータ型 (たとえば、String、Date、List、BigInteger、および BigDecimal) のためのゲッターおよびセッターが用意されています。表 2-7 に、SDO の動的データ API からの代表的な API を示します。 propertyName 引数は、取得したり設定する値のプロパティ名を示しています。propertyValue は新しい値です。 動的データ API は、インデックス値により DataObject のプロパティを設定および取得するメソッドを含めます。 これは、setInt( )、setDate( )、getString( )、などのプリミティブ型としてプロパティを取得したり設定するメソッドです。
静的データ API は、このような文字 (たとえば、getLASTNAME( ) メソッドの結果は「LAST_NAME」) を含む可能性のある型から生成されたメソッド名のアンダースコアを削除しますが、動的データ API では、get("LAST_NAME") のようにフィールド名を正確に参照することが要求されます。 たとえば、CUSTOMER データ オブジェクトの参照があるとすれば、動的データ API を使用して以下のような LAST_NAME プロパティを取得できます。
String lastName = (String) customer.get("LAST_NAME");
動的データ API の詳細については、DSP Javadoc (「AquaLogic Data Services Platform Mediator API Javadoc」) を参照してください。 SDO 1.0 API に関するマニュアルについては、commonj.sdo パッケージ内の DataObject インタフェースを参照してください。 以下から入手できます。
表 2-7 に、動的データ API ゲッターおよびセッターが表示されます。
DSP で XMLBeans 技術を使用する利点の 1 つは、動的データ API で XPath がサポートされることです。 XPath 式により、データ API のアクセサリ内でのデータ オブジェクトおよび属性の検索がきわめて柔軟になります。 たとえば、データ要素および値に基づいて get( ) メソッドの呼び出し結果をフィルタできます。
company.get("CUSTOMER[1]/POITEMS/ORDER[ORDERID=3546353]")
SDO 実装は、ゼロベースの配列インデックス表記 (".index_from_0") を XPath の標準カッコ付き表記 ([n]) に追加することで、基本 XPath 1.0 サポートより優れたものになります。 例として、表 2-8 では、XPath 標準表記と SDO 拡張表記を比較し、同じ要素である CUSTOER の下の最初の ORDER 子ノード (表 2-8) を参照しています。
ゼロベースのインデックスは、ゼロベースのカウンタに慣れている Java プログラマにとっては便利なものであり、1 を追加せずにインデックス値としてカウンタ値を使用することもできます。
DSP は、従来のインデックス表記と拡張表記の両方を完全にサポートしています。 ただし、SDO プリプロセッサでは、<myAcct.12> のように名前にドット番号が含まれる要素との衝突を避けるため、ゼロベースの形式が 1 ベースの形式と透過的に置き換えられます。
DSP の XPath サポートに関するその他の点も覚えておいてください。
("CUSTOMER//POITEM")
この例では、ワイルドカードが、以下のいずれかを含む CUSTOMER ルートより下のすべての注文書配列と一致します。
CUSTOMER/ORDERS/POITEM
CUSTOMER/RETURNS/POITEM
この表記では型に曖昧な点が生じるため (型は ORDERS または RETURNS のいずれか)、DSP SDO の実装ではサポートされていません。
<ORDER ID="3434">
ORDER/@ID
| 注意 : | SDO による XPath 式の使用例の詳細については、「手順 2: データ オブジェクト プロパティへのアクセス」を参照してください。 |
動的データ API では汎用的なデータ オブジェクトが戻されます。 データ オブジェクトのプロパティに関する情報を入手するには、SDO の Type インタフェースで使用可能なメソッドを使用します。 (commonj.sdo パッケージ中にある) Type インタフェースには複数のメソッドが用意されており、データ オブジェクトの型、プロパティ、それぞれの型など、データ オブジェクトに関する情報を実行時に取得できます。
SDO 仕様による、Type インタフェース (表 2-9 を参照) および Property インタフェース (表 2-10 を参照) は、データ オブジェクトのモデルの内部検査に使用される最小のメタデータ API を構成します。 たとえば、以下ではデータ オブジェクトの型を取得し、プロパティの値を出力します。
DataObject o = ...;Type type = o.getType();System.out.println(o.getString("CUSTOMERNAME")); }
if (type.getName().equals("CUSTOMER") {
オブジェクトのデータ型を入手すると、(リストとして) すべてのプロパティを取得し、リスト 2-1 で示すように、Type インタフェースの get Properties( ) メソッドを使用してプロパティの値にアクセスできます。
public void printDataObject(DataObject dataObject, int indent) {
Type type = dataObject.getType();
List properties = type.getProperties();
for (int p=0, size=properties.size(); p < size; p++) {
if (dataObject.isSet(p)) {
Property property = (Property) properties.get(p);
// 多数の値を持つプロパティの場合、値のリストを処理。
if (property.isMany()) {
List values = dataObject.getList(p);
for (int v=0; count=values.size(); v < count; v++) {
printValue(values.get(v), property, indent);
}
else { // 単一の値を持つプロパティの場合、値を出力。
printValue(dataObject.get(p), property, indent);
}
}
}
}
表 2-9 に、Type インタフェースでのその他の有効なメソッドが表示されます。
表 2-10 に、Property インタフェースのメソッドを示します。
DSP では、データ サービスとクライアント アプリケーションとの間でデータ グラフが渡されます。たとえば、クライアント アプリケーションがデータ サービスで読み込み関数を呼び出すと、データ グラフがクライアント アプリケーションに送信されます。 クライアント アプリケーションにより (たとえば注文書に注文が追加されるなど) 適宜コンテンツが変更され、変更されたデータ グラフがデータ サービスに送られます。 Data Service Mediator とは、更新されたデータ オブジェクトを受信し、変更を基底のデータ ソースに伝播するプロセスのことです。
Data Service Mediator とは更新プロセスのキーです。 他のアーティファクトとともに送信された SDO (たとえば、変更内容のまとめなど) からの情報を使用して、基底のデータ ソースを変更する更新プランを派生します。 関連するデータ ソースに対して、更新は自動的に行われます。 Mediator などの DSP の更新フレームワークを構成するアーティファクトおよびデフォルト プロセスが機能する方法については、『クエリおよびデータ ビューの構築』の「データ サービスを介した更新の処理」の章で説明しています。
  
|
