Service DataObjects API バージョン 1.0 および 2.01 によるデータ・アクセス

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

  • SDO は、Enterprise JavaBeans (EJB) API のオブジェクト表示などの特殊な形式のデータをクライアント・アプリケーションが扱う必要性を解消するため、データ中心となっています。代わりに、クライアントは容易に透過できる DataObject のグラフを扱います。
  • SDO が切断状態であるのは、検索された結果が、いずれのバックエンド・データ・ソース接続やトランザクションにも依存しないためです。
  • SDO には XML が統合されており、検索したデータと XML フォーマット間の変換を簡単に行うサービスが提供されています。
簡単に言うと、SDO はデータ・アプリケーション開発用のフレームワークであり、 そこにはアーキテクチャーと API が組み込まれています。SDO には次の機能があります。
  • Java™ Platform, Enterprise Edition (Java EE) データのプログラミング・モデルの単純化。
  • サービス指向アーキテクチャー (SOA) でのデータの抽象化。
  • データ・アプリケーション開発の単一化。
  • XML のサポートおよび統合。
  • Java EE パターンとベスト・プラクティスの取り込み。

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

他の一部のデータ統合モデルと異なり、SDO はデータ抽象化の際に停止しません。 SDO フレームワークは、多数の Java EE パターンとベスト・プラクティスを取り込むこともでき、 それによって、実証済みのアーキテクチャーや設計をアプリケーションに取り込むことが容易になります。 例えば、最近の 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 Service の機能が提供します。 単にリレーショナル・データ・ソースからデータを取得し、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 の使用』および『サービス・データ・オブジェクト: 学習用リソース』の文書を参照してください。

トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cdat_datsdo
ファイル名:cdat_datsdo.html