|
|
WebLogic Integration で提供される Application Integration 機能は、アプリケーション ビューを動作させるための標準アーキテクチャを提供します。アプリケーション ビューはエンタープライズ アプリケーションに対するビジネス指向のインタフェースです。
以下の高レベルなライフサイクルには、さまざまな Application Integration コンポーネントが参加します。
リソース アダプタ (単にアダプタともいう) は、EIS と J2EE アプリケーション サーバ (BEA WebLogic Server など) の間のコネクタの役割を果たすソフトウェア コンポーネントです。各アダプタを使用すると、特定のアプリケーションまたは技術との、双方向の要求/応答の統合が可能です。リソース アダプタは、Sun Microsystems 社の J2EE コネクタ アーキテクチャ (J2EE Connector Architecture : JCA) バージョン 1.0 の実装です。詳細については、次の URL にある Sun の JCA に関するページを参照してください。
Application Integration は、アダプタおよび関連するアプリケーション ビューを使用して、企業のアプリケーションを統合します。ケーブル等で接続するのではなく、アダプタを使用して、エンタープライズ システムをアプリケーション サーバに接続できます。EIS 用のアダプタをデプロイすると、他のコンポーネントやアプリケーションから、このアダプタを使用して EIS 上のデータにアクセスできるようになります。
事実上、サービスとは一定の作業を実行するための要求であり、イベントとは一定の作業が実行されたという通知です。
実行時に、EIS とアダプタは、要求、応答、イベントを XML ドキュメントとして交換します。アダプタでは、設計時に定義されたスキーマを使用して、EIS フォーマットと XML フォーマットのデータ変換が自動的に行われます。
1 つのアダプタ インスタンスでは、ゼロ個または 1 個のイベント接続と、ゼロ個以上のサービス接続が定義されます。アダプタ インスタンスはそれぞれ、RAR ファイルとしてデプロイされる 1 つの基本アダプタに関連付けられます。
アプリケーション ビューは、EIS 内のオブジェクトおよび処理へのビジネス指向のインタフェースです。アプリケーション ビューには、EIS との通信に必要な情報や、サービスとイベントのコンフィグレーションが含まれます。アプリケーション ビューでは以下の項目が定義されます。
通常、アプリケーション ビューは単一のビジネス目的のためにコンフィグレーションされ、そのビジネス目的に必要なサービスまたはイベントのみを含みますが、1 つの EIS で、さまざまなビジネス目的に対応する複数のアプリケーション ビューを定義することもできます。たとえば、人事データが格納された EIS で、個々の従業員が人事情報に読み取り専用でアクセスできる HREmployee アプリケーション ビューと、データ入力担当者が人事情報の追加、更新、削除を行うことのできる HRDataEntry アプリケーション ビューを定義することができます。
アプリケーション ビューは、アダプタとそのアダプタの EIS 機能間の抽象化レイヤとしての役割を持っています。アプリケーション ビューを使用すると、アダプタへのアクセス手順を単純化できます。EIS を直接起動してアクセスすることなく、アダプタのアプリケーション ビューの編集、新規アプリケーション ビューの作成、古くなったビューの削除を簡単に行うことができます。アプリケーション ビューで構成される抽象化レイヤを使用すれば、プログラマでなくても、アダプタが提供するサービスやイベントの保守ができるようになります。
アプリケーション ビューはそれぞれ、1 つのアダプタの EIS 上のビジネス機能を定義します。アダプタ作成後、Web ベースのインタフェースを使用して、独自のアプリケーション ビューを定義できます。アプリケーション ビューを使用すると、アダプタが提供するアプリケーション機能を表示できます。
ビジネス アナリストまたはテクニカル アナリストのどちらかがアダプタを使用してアプリケーションを定義する場合、特定のビジネス目的用にアプリケーション ビューをカスタマイズすることができます。ビジネスの目的はビジネス アナリストが定義します。たとえば、カスタマ リレーションシップ マネジメント (Customer Relationship Management : CRM) システムのアダプタに「顧客管理」アプリケーション ビューを定義する場合、通常このアプリケーション ビューには、顧客管理に関連するサービスとイベントのみを追加します。ただし、必要に応じてそれ以外ものが追加できるアプリケーション ビューを作成することもできます。アプリケーション ビューは特定のビジネス目的用にカスタマイズすることができ、この点で、他の多くの EAI システムで使用されている、1 つだけ作成してそれをすべての場合に適用するアプローチよりもはるかに優れています。
アプリケーションの機能に対応するビジネスレベルのビューによって、プログラマとテクニカル アナリストの役割が論理的に区分されます。たとえば、ビジネスレベルのビューにより、テクニカル アナリストは SQL についての知識を持たなくてもデータベース上にレコードを作成することができます。図 2-1 は、Application Integration 環境での作業で使用されるアプリケーション ビューを示しています。
アプリケーション ビューは、Application Integration Design Console を使用して作成します。これについては「Application Integration Design Console」を参照してください。アプリケーション ビューの詳細については、次の URL の『Application Integration Design Console の使い方』の「アプリケーション ビューの定義」を参照してください。
http://edocs.beasys.co.jp/e-docs/wli/docs92/aiuser/2usrdef.html
アプリケーション ビューは、ビジネス プロセス (JPD)、Web サービス (JWS)、BEA Liquid Data のいずれかから使用できます。また、アプリケーション ビューにアクセスするためのカスタム コードを作成することもできます。詳細については、次の URL にある『Application Integration Design Console の使い方』の「カスタム コードの記述によるアプリケーション ビューの使用」を参照してください。
http://edocs.beasys.co.jp/e-docs/wli/docs92/aiuser/4usrcust.html
WebLogic Integration では、アダプタの主要なユーザ インタフェースとしてアプリケーション ビューを使用するため、競合する EAI テクノロジでは通常提供されないいくつかの機能があります。
EAI のシナリオでは、1 つの共通データ フォーマットを使用して各 EIS と WebLogic Server の統合を実行するほうが、各 EIS がそれぞれ独自のデータ フォーマットを使用して他の EIS との統合を実行するよりもはるかに容易で効率的です。共通のデータ フォーマットを使用すると、すべてのアプリケーションが標準言語を使用して通信できるようになります。WebLogic Integration は、共通のデータ フォーマットとして XML を使用しています。XML は、急速に普及しているデータ交換フォーマットです。
WebLogic Integration の環境では、ほぼすべてのメッセージが XML ドキュメントとして送信されます。
アダプタでは XML を使用してアプリケーションのデータ フォーマットが変換されるため、ビジネス アナリストがフォーマットを熟知している必要がありません。ビジネス アナリストがアダプタを使用する場合に必要な知識は、アプリケーション ビューの定義方法と使用方法です。とりわけ、すべてのアダプタが、アプリケーション ビュー定義のために同じ Web ベース インタフェースを使用しているため、現在使用されているアダプタの使用方法だけでなく、今後提供されるアダプタについても容易に習得することができます。このように、XML を使用すると、開発者にとってもビジネス アナリストにとっても、EAI が使い易くなります。
アプリケーション ビューは、特定のビジネス用途のイベントおよびサービスを、基底のアダプタを介してサポートします。イベントでは、アプリケーションで生成されるメッセージを、パブリッシュ/サブスクライブ モデルに従って管理できます。サービスは、ユーザによって呼び出されるビジネス機能です。サービスを呼び出すと、要求/応答モデルに従って、メッセージがアプリケーションに送信されます。イベント、サービス要求、サービス応答はすべて、XML ドキュメントとしてシステムを通過します。
各アプリケーション ビューでは、メタデータ (イベント、サービス要求およびサービス応答の XML 情報に関する情報) として、XML スキーマを使用します。このメタデータを使用すると、アプリケーション ビュー イベントまたはサービスでどのようなデータが必要かがわかります。
現時点では、J2EE コネクタ アーキテクチャ仕様バージョン 1.0 は EIS がアプリケーション サーバまたはクライアントと通信を開始するためのガイドラインを提供していません。WebLogic Integration ではイベントによってこの通信機能が実現されています。
この節では、サービス呼び出しのためのクライアントと、イベント通知のためのコンシューマについて説明します。
次の表では、アプリケーション ビューを使用して EIS のサービスを呼び出すクライアントの種類を説明します。
com.bea.wlai.client 内) はどれも、アプリケーション ビューでサービスを呼び出し可能。詳細については、『Application Integration Design Console の使い方』の「カスタム コードの記述によるアプリケーション ビューの使用」を参照。
|
アダプタでイベントの配信に使用される WebLogic Integration メッセージ ブローカでは、ビジネス プロセスに、チャネルベースのパブリッシュおよびサブスクライブ通信メカニズムが提供されます。詳細については、「実行時のイベント通知の処理」を参照してください。次の表では、EIS から配信されるイベントの一般的なコンシューマについて説明します。
|
|
com.bea.wlai.client 内) はどれも、イベントの消費が可能。詳細については、『Application Integration Design Console の使い方』の「カスタム コードの記述によるアプリケーション ビューの使用」を参照。
|
WebLogic Integration の設計時機能を使用すると、開発者は各アダプタの CCI (Common Client Interface) を作成できます。CCI により、アプリケーション コンポーネントおよびエンタープライズ アプリケーション統合 (Enterprise Application integration : EAI) フレームワークで共通のクライアント API を使用して、異種 EIS 間での対話を実現することができます。アダプタの設計時 GUI を使用すれば、プログラマでなくてもアプリケーション ビューの作成、デプロイ、テストおよび編集をすばやく行うことができ、またサービスやイベントを追加してカスタマイズすることができます。
アダプタの設計時 GUI の主な目的は、アプリケーション ビューの定義、デプロイおよびテストです。詳細については、『Application Integration Design Console の使い方』を参照してください。
Application Integration Design Console は、企業内の全アプリケーション ビューへのアクセス、編成、および編集を行う際に役立ちます。Application Integration Design Console では、新しいフォルダを作成して、そこに新しいアプリケーション ビューを追加することができます。このようなフォルダを使用すると、使用されるアダプタとは関係なく、アプリケーション ビューを独自のナビゲーション スキームに従って整理することができます。
アプリケーション ビュー管理の詳細については、『Application Integration Design Console の使い方』の「Application Integration Design Console の使い方」を参照してください。
EIS の機能をエクスポーズする方法は、アダプタの設計時 GUI を使用する方法だけではありませんが、通常はこれが最も便利な方法です。サービス呼び出しとイベントをサポートするには、アプリケーション ビューを定義する方法と、同様の機能を持つカスタム コードを作成する方法があります。アダプタのアプリケーションが提供する機能をエクスポーズするには、最低でもアダプタごとにアプリケーション ビューを定義する必要があります。ただし、ユーザが通常のレベル以上の管理を行うことを希望する場合は、アダプタのリソースへアクセスできるよう、カスタム コードを作成することもできます。企業のニーズを最大限に満たすには、アプリケーション ビューを定義するべきか、独自のコードを作成するべきか、あるいは両方を組み合わせた方法を導入するべきかを見極める必要があります。
多くの EIS アプリケーションは、アプリケーション ビューを定義することで容易にシステムへの統合が可能になります。アプリケーション ビューを定義するのが望ましいのは、次のような場合です。
一般的に、アダプタのインタフェースをカスタム コードで作成するのは以下のような場合に限ります。
この使用例では、JCA 1.0 アダプタを直接 WebLogic Server で使用していることを前提としています。このような場合、JCA CCI. に対して直接コーディングを行います。このようにすると、アプリケーション ビューや WebLogic Integration の機能を使用する必要がありません。
EIS では、それぞれ独自のインタフェースを使用して、サービス要求やイベント通知を処理します。たとえば、SAP で使用されている BAPI インタフェースでは、BAPI の要求および応答のパラメータと構文を定義します。EIS ごとに、アプリケーションを EIS に統合する際に使用できるメタデータが EIS インタフェースで定義されます。EIS は、データをパブリッシュして、インタフェースのルールおよびメタデータで指定されているフォーマットで要求を受信します。
実行時に、EIS とアダプタは、サービス要求、サービス応答、イベントを XML ドキュメントで交換します。アダプタは、設計時に定義済みのスキーマを使用して XML と EIS フォーマットの間でデータをマップすることにより、XML ドキュメントと EIS フォーマットの間のデータ変換を処理します。
設計時に、アプリケーション ビューでコンフィグレーションした各サービスの要求スキーマと応答スキーマ、各イベントのイベント スキーマを定義します。SAP など一部のアダプタでは、BEA Application Explorer を使用できます。これについては「BEA Application Explorer」で説明します。その他のアダプタでは、スキーマを手動で作成する必要があります。特定のアダプタのスキーマを定義する方法については、ご使用のアダプタのユーザ ガイドの「Generating Schemas」の章を参照してください。
必要なスキーマを作成したら、それらをイベントおよびサービスと関連付けるマニフェスト ファイルと共に、ファイルベースのリポジトリに保存します。Application Integration Design Console でアプリケーション ビューをコンフィグレーションするときは、アプリケーション ビューが必要に応じてスキーマを検索できるように、リポジトリの場所を指定します。詳細については、ご使用のアダプタのユーザ ガイドの「Defining Application Views」の章を参照してください。
この節では、EIS 統合に関連する統合ソリューションを設計およびデプロイするための、以下のツールについて説明します。
| 注意 : | BEA Application Explorer は、一部の BEA WebLogic アダプタでのみ使用します。このツールを使用する必要があるかどうかは、使用しているアダプタのドキュメントを参照してください。 |
BEA Application Explorer は、サービスおよびイベントのスキーマ生成に使用できる設計時ツールです。BEA Application Explorer では、アプリケーション システム環境に関する詳細な情報を組み込んで、EIS の特定のビジネス オブジェクトでメタデータのクエリが行われます。そのメタデータを使用して、選択したサービスまたはイベントの構築に必要なスキーマ (サービスの要求スキーマと応答スキーマおよびイベントのイベント スキーマ) が生成されます。スキーマの概要については、「EIS のメタデータ、スキーマ、リポジトリ」を参照してください。
特定のアダプタのスキーマを定義する方法については、ご使用のアダプタのユーザ ガイドの「Generating Schemas」の章を参照してください。
Application Integration Design Console は、アプリケーション ビューの構築およびサービスやイベントのコンフィグレーションに使用する設計時ツールです。イベントごと、またはサービスごとに、Application Integration Design Console を使用して、接続設定およびその他の関連情報をコンフィグレーションすることができます。
Application Integration Design Console を使用したアプリケーション ビューの作成方法については、ご使用のアダプタのユーザ ガイドの「Defining Application Views」の章、および『Application Integration Design Console の使い方』の「Application Integration の概要」にある「アプリケーション ビューの定義」を参照してください。
BEA WebLogic Workshop は、BEA WebLogic Platform 上でエンタープライズクラスのアプリケーションを構築するための統合開発環境です。WebLogic Workshop は、ビジネス プロセス、Web サービス、ポータルを構築するための設計時ツールであると同時に、ビジネス プロセスを実行するための実行時環境でもあります。
BEA WebLogic Workshop は EIS への統合メカニズムとして以下を提供します。
詳細については、WebLogic Workshop ヘルプ システムの「ビジネス プロセスを開始する」を参照してください。
WebLogic Integration Administration Console を使用すると、デプロイ済みのアプリケーション ビューおよびアダプタ インスタンスを管理できます。アプリケーション ビューごとに、管理者は、以下のような管理タスクを実行できます。
アダプタ インスタンスごとに、管理者は、以下のような管理タスクを実行できます。
コンソールの詳細については、『WebLogic Integration ソリューションの管理』を参照してください。この情報は、WebLogic Integration Administration Console のヘルプにも掲載されています。
この節では、アダプタで実行時にサービスおよびイベントを処理する方法を概説します。内容は以下のとおりです。
この節の手順では、プログラマ以外を対象として各プロセスの概要を説明します。サンプル コードについては、『Application Integration Design Console の使い方』の「カスタム コードの記述によるアプリケーション ビューの使用」にある「サンプルの Java クラスのコード」を参照してください。
ここに示す手順では、アダプタ インスタンスという用語を使用します。1 つのアダプタ インスタンスでは、ゼロ個または 1 個のイベント接続と、ゼロ個以上のサービス接続が定義されます。アダプタ インスタンスはそれぞれ、RAR ファイルとしてデプロイされる 1 つの基本アダプタに関連付けられます。
同期で呼び出した場合と非同期で呼び出した場合では、サービス呼び出しの処理手順は異なります。
この節では、図 2-2 に示す実行時の同期サービス呼び出しの処理を、手順を追って説明します。
以下の手順では、実行時の同期サービス呼び出しの処理方法を概説します。
invokeService メソッド)。
クライアント アプリケーションは、invokeService メソッドに対する戻り値として、応答ドキュメントを指定します。
execute メソッド)。invokeService メソッドに対する戻り値として応答ドキュメントを受信し、適宜処理します。
この節では、実行時の非同期サービス呼び出しの処理を、手順を追って説明します。非同期サービス呼び出しは、次の 2 つのうちいずれかの方法で開始できます。
図 2-3 は、実行時の非同期サービス呼び出しの処理方法を示しています。
以下の手順では、実行時の非同期サービス呼び出しの処理方法を概説します。
この節では、実行時のイベント通知の処理を、手順を追って説明します。イベント通知は常に非同期で、2 つの送り先にパブリッシュされます。
WLAI_EVENT_TOPIC JMS トピック)。メッセージ駆動型 Bean (WLI-AI Event プロセッサ) は WLAI_EVENT_QUEUE 分散送り先でリスンして、イベントのコピーを WLAI_EVENT_TOPIC にパブリッシュします。WLAI_EVENT_TOPIC は、分散 JMS トピックであり、リモートのアプリケーション ビュー クライアントへのイベントの配信を処理します。
設計時に、これらのいずれかの送り先でイベントをリスンするようにイベント コンシューマをコンフィグレーションする必要があります。さらに、特定の送り先にイベント メッセージを送信しするように EIS をコンフィグレーションし、アダプタが EIS 固有の通信プロトコルを使用してイベント メッセージを受信できるようにする必要もあります。
図 2-4 は、実行時のイベント通知の処理方法を示しています。
以下の手順では、実行時のイベント通知の処理方法を概説します。
  
|
