WebSphere Application Server for i5/OS, Version 6.1   
             オペレーティング・システム: i5/OS

             目次と検索結果のパーソナライズ化

Service DataObjects によるデータ・アクセス

Service DataObjects (SDO) フレームワークは、XML が統合された、データ中心の切断状態でのデータ・アクセス・メカニズムであり、 ソースに依存しない結果セットを提供します。

簡単に言うと、SDO はデータ・アプリケーション開発用のフレームワークであり、 そこにはアーキテクチャーと API が組み込まれています。SDO には次の機能があります。

Service DataObjects フレームワークは、データ・アプリケーション開発用に統合されたフレームワークを提供します。 SDO を使用すると、データにアクセスおよび使用する際に、技術固有の API に精通する必要がなくなります。 1 つの API、SDO API を理解するだけで、 複数のデータ・ソース (リレーショナル・データベース、エンティティー EJB コンポーネント、XML ページ、Web サービス、 Java コネクター・アーキテクチャー、JavaServer Pages など) からのデータを処理することができます。

他の一部のデータ統合モデルと異なり、SDO はデータ抽象化の際に停止しません。 SDO フレームワークは、多数の J2EE パターンとベスト・プラクティスを取り込むこともでき、 それによって、実証済みのアーキテクチャーや設計をアプリケーションに取り込むことが容易になります。 例えば、最近の Web アプリケーションの大半は、 常時バックエンド・システムに接続されていることはなく、また常時接続することはできないので、SDO は、切断状態のプログラミング・モデルもサポートしています。同様に、 アプリケーションは非常に複雑で、多層構造のものが多くなっています。 データはどのように保管されるのでしょうか? 送信されるのでしょうか? GUI フレームワークでエンド・ユーザーに提示されるのでしょうか? SDO プログラミング・モデルでは、各考慮事項を明確に分離できる使用パターンがいくつか規定されています。

SDO コンポーネント

SDO のアーキテクチャーの概説として、 フレームワークを構成する各コンポーネントについて記述し、そのコンポーネントが連動する様子を説明します。 リストにある最初の 3 つのコンポーネントは、SDO の「概念的な」フィーチャーです。 つまり、API には該当するインターフェースがありません。

SDO クライアント

SDO クライアントは、SDO フレームワークを使用してデータを処理します。テクノロジー固有の API やフレームワークを使用するのではなく、 SDO のプログラミング・モデルと API を使用します。 SDO クライアントは SDO DataObject 上で動作するため、 処理するデータが持続またはシリアライズされる方法を知っている必要はありません。

Data Mediator Services
Data Mediator Services (DMS) は、データ・ソースからの DataGraph の作成と、 DataGraph を変更した場合のデータ・ソースの更新を受け持ちます。(DataGraph はサービス・データ・オブジェクトを含むエンベロープ・オブジェクトです。)

DMS は、 クライアントとデータ・ソース間でデータを移動するメカニズムを提供します。これは、バックエンド固有のメタデータにより作成されます。 メタデータは、バックエンドに対して使用される照会と同様に、DMS によって作成される DataGraph の構造を定義します。 DMS に対して DataGraph の作成が要求されると、対象のバックエンドに照会が行われ、ネイティブの結果セットが DataGraph 形式に変換されます。DataGraph が戻されると、DMS はこれに対する参照を解放し、DataGraph に関してはステートレスとなります。DMS に対して、 既存の DataGraph の変更をバックエンドにフラッシュすることが要求されると、 DataGraph の元の状態からの変更が抽出され、バックエンドにフラッシュされます。DMS は一般に、何らかの形のオプティミスティック並行性制御のストラテジーを使用して、更新の衝突を検出します。

WebSphere Application Server は、 2 つの別個の Data Mediator Services の機能を提供します。 単にリレーショナル・データ・ソースからデータを検索し、DataGraph を戻す場合は、Java Database Data Mediator Service を使用するのが適切な方法です。 ただし、ビジネス・ロジックがある場合は、 エンティティー Bean へのデータのオブジェクト指向 (OO) レンダリングが必要です。 SDO は、エンティティー Bean に類似したデータのオブジェクト・レンダリングとみなすことができます。 しかし、エンティティー Bean にはより適切な オブジェクト・リレーショナル (OR) マッピング・ツールがあり、 エンティティー Bean 用の EJB コンテナーとパーシスタンス・マネージャーでは、より高度なキャッシング・ポリシーが提案されています。 したがって、EJB Data Mediator Service を選択することが最善の方法です。EJB メディエーターは、これらのキャッシュと連動します。 また、エンティティー Bean のプログラミング・モデルは、単一レベルのストア・モデルです。 エンティティー間をナビゲートすると、 コンテナーとパーシスタンス・マネージャーが必要に応じてデータを事前に取り出したり、後から取り出したりします。 更新時に、プログラマーがトランザクションにコミットすると、 コンテナーとパーシスタンス・マネージャーが 更新済み Bean のトラッキングを行い、 それらをデータ・ストアとメモリー・キャッシュに再度書き込みます。

データ・ソース
データ・ソースは、バックエンド・データ・ソース (例えばパーシスタンス・データベース) に限定されているわけではありません。 データ・ソースには、独自フォーマットのデータが含まれます。SDO 1.0 API の場合、データ・ソースにアクセスするのは DMS のみであり、SDO アプリケーションはアクセスしません。アプリケーションは SDO 1.0 DataGraph の処理のみを行います。
次の各コンポーネントは、 SDO プログラミング・モデルでは Java インターフェースに相当します。
DataObject

SDO の基本コンポーネントとして、DataObject は SDO クライアントの構造化データの共通表示を提供します。DataObject はシリアライズ可能なタイプの複数の様々な属性 (ストリングまたは整数) を保持することができ、また、より複雑な DataObject にはよりシンプルな DataObject を含めることができます。DataObject は、プロパティー にそのすべてのデータを保持します。

SDO バージョン 1.0 DataObject は常に互いにリンクされ、DataGraph に格納されます。バージョン 1.0 DataObject インターフェースは、単純な作成メソッドおよび削除メソッド (各種のシグニチャーを伴う createDataObject()、 および delete()) と、これらのタイプ (インスタンス・クラス、名前、プロパティー、ネーム・スペース) を取得する反射的メソッドを提供しています。このインターフェースでは、 外部コード・ジェネレーターから作成する静的オブジェクト・タイプもサポートしています。詳しくは、「Dynamic and static object types for the JDBC DMS」の文書を参照してください。

DataGraph

DataGraph は、サービス要求への応答で戻される構造化された結果です。DMS は、ネイティブのバックエンドの照会結果を、 発生元のバックエンド・データ・ストアに依存しない DataGraph へと変換します。これにより、DataGraph が各種データ・ソース間で簡単に転送可能になります。DataGraph は、それぞれが SDO DataObject である相互接続ノードから構成されています。これは、発生元のデータ・ソースの接続およびトランザクションから独立しています。DataGraph は、そのオリジナルのソースからの変更を追跡します。この変更ヒストリーを DMS が使用することで、オリジナルのデータ・ソースに変更を反映させることができます。DataGraph は、XML 文書間と簡単に変換することができ、複数層のシステム・アーキテクチャー内のレイヤー間での転送が可能です。DataGraph は、幅優先 (breadth-first) または深さ優先 (depth-first) 方式のどちらでもアクセスでき、Web サービス用にシリアライズ化が可能な切断状態のデータ・キャッシュを提供します。

Mediator から戻された DataGraph には、動的、または生成された静的な DataObject が含まれます。生成されたクラスを使用することによってタイプ・セーフなインターフェースが得られ、プログラミングを容易にし、良好なランタイム・パフォーマンスを実現できます。EMF 生成クラスは、 動的な DataObject 用に作成されるスキーマと一貫した名前およびタイプを持つ必要があります (ただし、 属性および参照は追加で定義できます)。照会で指定された属性および参照のみ、データが埋め込まれます。他の属性および参照は、設定されません。

変更の要約

SDO 1.0 変更要約は DataGraph に格納され、 DMS が戻す DataGraph への変更を表す場合に使用されます。 これは、 最初 (DataGraph がクライアントに戻されるとき) は空で、 DataGraph が変更されると読み込まれます。変更要約は、バックエンドの更新時に、 DMS がその変更をデータ・ソースに再度適用する際に使用されます。これによって、DMS は、 変更済みプロパティー (およびその変更前の値) のリストと、DataGraph 内の作成および削除された DataObject を提供することで、 データ・ソースを効率的かつインクリメンタルに更新することができます。情報が DataGraph の変更要約に追加されるのは、 変更要約のロギングが活動状態にあるときだけです。変更要約では、 DMS がロギングのオン/オフを切り替える方法が用意されています。

注: SDO 1.0 変更要約はクライアント API ではありません。これは、DMS によってのみ使用されます。
プロパティー、タイプ、およびシーケンス

DataObject は、そのコンテンツを一連のプロパティーに保持します。各プロパティーには、 プリミティブなどの属性タイプ (例えば int)、一般に使用されるデータ・タイプ (例えば Date)、 あるいは、参照の場合は他の DataObject のタイプがあります。個々の DataObject には、 そのプロパティー用に読み取りおよび書き込みのアクセス・メソッド (getter および setter) が用意されています。 これらのアクセサーの多重定義版がいくつか提供され、プロパティーには、プロパティー名 (ストリング)、 番号 (int)、またはプロパティーのメタオブジェクトそのものを渡すことによってアクセスできます。 ストリング・アクセサーは、プロパティーにアクセスするための XPath に似た構文もサポートしています。 例えば、会社の DataObject 上で get("department[number=123]") を呼び出すと、 番号が 123 の最初の部門を取得することができます。シーケンスはさらに高機能です。 プロパティーと値のペアの異種リストで順序を保存することができます。

その他の入門情報

SDO 1.0 の概要 (サンプル・アプリケーションを含む) については、IBM developerWorks の文書「Introduction to Service DataObjects」を参照してください。

注: EJB Data Mediator サービスについて詳しく理解するには、EJB プログラミング・モデルについての知識が必要です。詳しくは、『タスクの概説: アプリケーションでのエンタープライズ Bean の使用』および『サービス・データ・オブジェクト: 学習用リソース』の文書を参照してください。



サブトピック
Java DataBase Connectivity Mediator Service
Enterprise JavaBeans Data Mediator Service
サービス・データ・オブジェクト: 学習用リソース
関連タスク
タスクの概説: アプリケーションでのエンタープライズ Bean の使用
関連資料
JDBC DMS の動的および静的オブジェクト・タイプ
関連情報
IBM developerWorks Web サイト
Apache Tuscany フリー・オープン・ソース・プロジェクト Web サイト
Java SDO subproject of the Apache Tuscany incubator project Web サイト
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 5:46:14 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.iseries.doc/info/iseries/ae/cdat_datsdo.html