|
|
この章では、クライアント アプリケーション開発者向けの ALDSP の概要について説明します。内容は以下のとおりです。
BEA AquaLogic Data Services Platform (ALDSP) は、サービス指向アーキテクチャ (SOA) に基づくデータ アクセスを実現します。ALDSP を採用することにより、企業は社内に分散しているさまざまなデータ ソースの一括管理、統合、変換、およびサービス対応が可能となり、企業データはアクセスが容易な再利用可能コモディティ、つまりデータ サービスとして利用できるようになります。
クライアント アプリケーションの観点からすると、データ サービスは顧客や注文など、個別のビジネス エンティティを表すのが一般的です。裏では、データを統合して複数のソースに由来するデータを単一ビューで構成します。たとえば、複数のソースをアセンブルしてさまざまな形式に変換します。データ サービスは他のデータ サービスに関連付けられている場合がありますが、ALDSP ではこうした関連付けを簡単に適用することができます。クライアント アプリケーションはデータ サービスを利用することにより、各ビジネス エンティティを構成する詳細について処理する必要がなくなります。クライアント アプリケーションで必要なのは、データ サービスの公開インタフェースを理解することのみです。
ALDSP では、クライアント アプリケーションは統合されたサービス層を介して異種データを処理するため、多様な接続メカニズムやデータ形式を駆使して分散したデータソースを扱う必要はありません。ALDSP では、クライアント開発者向けに統合された堅牢なインタフェースを提供するため、異種のバックエンド データへのアクセスおよび更新が可能です。SOA に基づく方法で、データ サービスを利用する情報アクセスを実現します。
このマニュアルでは、ALDSP 対応のクライアント アプリケーションの作成方法について説明します。ALDSP がサポートするさまざまなクライアント アクセス メカニズムや、サービス データ オブジェクト (SDO) など、主なクライアント側データ プログラミング モデルについて説明します。また、ALDSP 更新フレームワークを利用した更新可能なデータ サービスの作成方法についても説明します。
高レベルな観点から、データ サービスは顧客や顧客注文など個別のビジネス エンティティを定義します。データ サービスは、リレーショナル データベース管理システム、Web サービス、企業アプリケーション、フラット ファイル、および XML ファイルなど、さまざまなソースからのデータを統合し、ビジネス エンティティの単一ビューで表示します。また、必要に応じてオリジナルのソースからデータを変換することもできます。
以下に示す点のみを理解するだけで、クライアントとしてデータ サービスの利用が可能です。
データ サービス クライアント アプリケーションは、Web サービス クライアント アプリケーションが Web サービスのオペレーションを呼び出すのと同じ方法で、データ サービスを利用できます。
データ サービスの開発の詳細については、『データ サービス開発者ガイド』を参照してください。
ALDSP クライアント アプリケーションとは、データ サービス ルーチンを呼び出すアプリケーションです。クライアント アプリケーションには、任意のプログラミング言語で、Microsoft ADO.NET アプリケーション、BEA Workshop for WebLogic アプリケーション、JDBC/ODBC または Web サービス ベースのアプリケーションなどの Java プログラムおよび非 Java プログラムが含まれます。
図 1-1 に、これらのさまざまなアクセス方法の概要を示します。
クライアントのタイプにかかわらず、ALDSP を利用すると、統合されたサービス指向メカニズムを利用し、分散された異種データへのアクセスおよび修正を行うことができます。開発者はさまざまなデータ ソースの接続や形式の詳細について理解する必要がなく、ビジネス ロジックにのみ集中できます。
クライアント アプリケーション コードで、データ サービス ルーチンを呼び出すと、ALDSP は次のタスクを実行します。
これらの ALDSP データ オブジェクトは、BEA、IBM、Oracle、SAP、および他社が共同開発したデータ プログラミング用の Java ベース API である、Service Data Object (SDO 2.1) 仕様に準拠しています。
アプリケーション開発者は、ALDSP サービスへのアクセスを、複数のクライアント API モデルから選択することができます。選択したモデルは、求めるアクセス メカニズムに依存します。各アクセス方法には独自の利点と用途があります。表 1-2 に、それぞれのアクセス方法の説明と、ALDSP データ サービスにアクセスするためのさまざまなプログラミング モデルの利点を示します。
|
|
|||
|
|
Service Data Objects (SDO) とは BEA と IBM、Oracle、SAP、および他社が共同提案した仕様で、データ プログラミングにおける Java ベースの API を持ちます。SDO は異なるタイプのデータ ソースに対してデータ プログラミングを簡略化します。データ アクセスを簡略化し、データ利用者はデータベース、Web サービス、アプリケーション、その他のシステムなど、データ ソースにかかわらず、一貫性があり、統一された方法でデータを利用することができます。
SDO は非連結データの概念を使用します。このアーキテクチャでは、クライアントは SDO データ オブジェクトまたはデータ グラフで外部的に永続化されたデータのコピーを取得します。つまり、データを保持する構造になっています。クライアントはリモートで (つまり、データ ソースから非接続の状態) データを操作します。
クライアントが行ったデータの変更をデータ ソースに保存する必要がある場合、後でソースへ再接続する必要があります。接続時間を最小限に抑えることにより、web とサービス指向アプリケーションのスケーラビリティとパフォーマンスを最大化します。
SDO クライアント側では、データはデータ ソースまたは基底のソース形式にかかわらず、統一されて表示されます。SDO モデルにおけるデータの統一されたビューを可能にするのがデータ メディエータの概念です。Mediator はデータ クライアントとバックエンド システムの仲介を行います。これによってクライアントはデータ サービスにアクセスし、データ取得またはデータ変更送信に関する関数を呼び出すことができます。ALDSP は、こうした SDO Mediator を実装します。
SDO の詳細については、「データ プログラミング モデルと更新フレームワーク」を参照してください。
SDO 仕様では、特定タイプのクエリ言語またはバックエンド システムを対象としたさまざまな型の Mediator を利用できます。ALDSP では Data Service Mediator を提供します。Data Service Mediator は ALDSP の XQuery 処理エンジンのサーバ側コンポーネントで、データ サービスとクライアント アプリケーションまたはプロセスの仲介を行います。
Data Service Mediator は、すべてのデータ サービスを構成するさまざまなデータ ソースへのアクセスと更新を円滑化します。Mediator はデータ サービス更新フレームワークのコア メカニズムです。Web サービス クライアントおよび Java クライアントの Mediator API の使い方の詳細については、以下を参照してください。
ALDSP 対応のクライアント アプリケーションの開発には以下の手順があります。
たとえば、データ サービスが Web サービスとしてマップされている場合、Java を当該サービスの WSDL ファイルと関連付けて使用し、Web サービス クライアント アプリケーションを開発できます。
同様に、データ サービスがポータル、ビジネス プロセス、または Web アプリケーションに組み込まれている場合、コントロールを使用してクライアント アプリケーション開発プロセスは、ページフローまたは他のサーバ側アーティファクトのセットとしてサーバのコンテキスト全体で行われる場合があります。
ALDSP 管理者はロール ベースのセキュリティ ポリシーを介して、デプロイされた ALDSP リソースへのアクセスを制御できます。ALDSP は基礎となる WebLogic Platform のセキュリティ機能を活用および拡張します。ロールを WebLogic Administration Console で設定できます。(DSP コンソールの詳細については、『ALDSP 管理ガイド』を参照してください。)
デプロイメントにおけるすべてのデータ サービス、各データ サービス、各データ サービス関数、またはデータ サービス関数によって返された各要素においても、リソースへのアクセス ポリシーをあらゆるレベルで定義できます。
ALDSP セキュリティに関する情報については、『ALDSP 管理ガイド』の「AquaLogic Data Services Platform リソースの保護」を参照してください。WebLogic セキュリティの詳細については、『e-docs』の「WebLogic セキュリティ プログラマーズ ガイド」を参照してください。
データ サービスのパフォーマンスは以下を含むシステム全体を構成するエンド ツー エンド コンポーネントによって決まります。
データ サービに対するクライアント アプリケーションを作成する前に、基底となるそれぞれデータ ソースのパフォーマンスを注意して、開発時にデータ サービスのパフォーマンスをベンチマークすることをお勧めします。負荷テスト ツールを使用してデプロイされたデータ サービスがサポートできる最大クライアント数を決定します。
ALDSP の監査機能を利用して、パフォーマンスの問題発生時にそれを識別し解決するのに役立つパフォーマンス プロファイル情報を取得できます。ALDSP 監査機能の詳細については、『ALDSP 管理ガイド』を参照してください。
以下の表では、以下に示す項目に対するクラスパスの要件があります。
ALDSP Mediator API を使用するクライアント アプリケーションには、以下のいずれかのクラスパスを設定する必要があります。
CLASSPATH=
<app-static-client>.jar <= this is generated static client jar
<ALDSP_HOME>/lib/sdo.jar
<ALDSP_HOME>/lib/ld-client.jar
<WL_HOME>/common/lib/apache_xbean.jar
<WL_HOME>/server/lib/weblogic.jar
CLASSPATH=
<ALDSP_HOME>/lib/sdo.jar
<ALDSP_HOME>/lib/ld-client.jar
<WL_HOME>/common/lib/apache_xbean.jar
<WL_HOME>/server/lib/weblogic.jar
ALDSP ネイティブ Web サービス機能を使用するクライアント アプリケーションには、以下のいずれかのクラスパスを設定する必要があります。
CLASSPATH=
<app-static-client>.jar <= this is generated static client jar
<ALDSP_HOME>/lib/sdo.jar
<WL_HOME>/common/lib/apache_xbean.jar
<WL_HOME>/server/lib/weblogic.jar
CLASSPATH=
<ALDSP_HOME>/lib/sdo.jar
<ALDSP_HOME>/lib/ld-client.jar
<WL_HOME>/common/lib/apache_xbean.jar
<WL_HOME>/server/lib/weblogic.jar
JMX Mbean Management API には、以下のクラスパスを設定する必要があります。
CLASSPATH=
<ALDSP_HOME>/lib/ld-server-core.jar
<ALDSP_HOME>/lib/ld-client.jar
<WL_HOME>/common/lib/apache_xbean.jar
<WL_HOME>/server/lib/weblogic.jar
ALDSP JDBC API クライアントには、以下のクラスパスを設定する必要があります。
CLASSPATH=
<ALDSP_HOME>/lib/ldjbc.jar
<ALDSP_HOME>/lib/ld-client.jar
<WL_HOME>/server/lib/weblogic.jar
ALDSP 2.5 は相互運用性 JAR ファイル (wls90interop.jar) を提供するので、WebLogic Server 9.2 クライアントは ALDSP 2.x データ サービスにアクセスできます。ALDSP 3.0 にアップグレードした後、WLS 9.2 べースのクライアントの CLASSPATH および ALDSP 2.5 クライアントの CLASSPATH の両方から使用しているすべての wls90interop.jar を削除する必要があります。
  
|
