アダプタの開発
![]() |
![]() |
![]() |
![]() |
この節では、アダプタまたは設計時グラフィカル ユーザ インタフェース (Graphical User Interface : GUI) の開発を行う前に理解する必要がある基本的な概念を説明します。この節では、以下の内容を扱います。
アダプタ アクティビティという用語は、実行時アクティビティと設計時アクティビティの両方を意味します。実行時アクティビティは、アダプタのプロセスを実行することです。アダプタのユーザによって実行される設計時アクティビティには、アプリケーション ビューの作成、デプロイメントおよびテストが含まれます。
実行時および設計時アクティビティは、それぞれ ADK の実行時フレームワークと設計時フレームワークによってサポートされています。実行時フレームワークは、アダプタを開発するためのツールで構成され、設計時フレームワークは Web ベースのユーザ インタフェースを設計するためのツールで構成されています。実行時および設計時アクティビティについては、この後の節で詳しく説明します。
実行時フレームワークは、イベント接続およびサービス接続の開発に使用するツール セットです。イベント接続の開発をサポートするため、実行時フレームワークには、拡張可能な基本イベント ジェネレータが用意されています。また、サービス接続の開発用に、J2EE に完全に準拠したアダプタが用意されています。
実行時フレームワークで提供されるクラスには、以下の利点があります。
さらに、実行時フレームワークでは、イベント ジェネレータの実装に役立つ抽象基本クラスが用意されています。イベント ジェネレータを使用すると、ADK 環境で提供されるイベントのサポートを活用できます。
実行時フレームワークの主要コンポーネントは、実行時エンジンです。これはサービス呼び出しを処理するアダプタ コンポーネントをホストし、以下の 3 つの WebLogic Server 機能を管理します。
これらは、すべて J2EE コネクタ アーキテクチャの規格に準拠しています。
設計時フレームワークには、アダプタのユーザがアプリケーション ビューを定義、デプロイ、およびテストする際に必要な Web ベースの GUI 作成用ツールが用意されています。どのアダプタにも EIS 固有の機能がありますが、すべてのアダプタにアプリケーション ビューをデプロイする GUI が必要です。設計時のフレームワークでは、そのような GUI の作成とデプロイに必要な作業を最小限に抑える以下の 2 つのツールが用意されています。
各アダプタの設計時インタフェースは、WAR ファイルにバンドルされている J2EE Web アプリケーションです。Web アプリケーションは、.jsp
、.html
およびイメージ ファイルなどをまとめたものです。Web アプリケーション記述子は web.xml
です。この記述子により、Web アプリケーションのデプロイおよび初期化方法が J2EE Web コンテナに伝えられます。
各 Web アプリケーションには、デプロイメント時に指定されたコンテキストがあります。このコンテキストにより、Web コンテナのドキュメント ルート下にある Web アプリケーションに関連付けられたリソースが識別されます。
ADK を使用すると、イベント接続とサービス接続の両方を作成できます。ADK アーキテクチャでは、サービスとイベントは、XML スキーマを使用して入出力を定義する自己記述オブジェクト (つまり、名前がビジネス機能を示す) として定義されます。
イベントは、対象のイベントが EIS 内で発生したときにアプリケーション ビューによってパブリッシュされる XML ドキュメントです。イベントの通知を希望するクライアントは、アプリケーション ビューに登録することによってその通知を要求します。登録すると、アプリケーション ビューは、対象アプリケーションとクライアント間のブローカとして機能します。クライアントがアプリケーション ビューによってパブリッシュされるイベントをサブスクライブした場合、アプリケーション ビューは対象アプリケーション内で目的のイベントが発生するたびにクライアントに通知します。イベント サブスクライバに、目的のイベントが発生したことが通知されると、サブスクライバにはそのイベントを記述した XML ドキュメントが渡されます。また、イベントをパブリッシュするアプリケーション ビューは、パブリッシュ可能なイベントの XML スキーマをクライアントに提供することもできます。
注意 : アプリケーション ビューは、アプリケーションの特定の機能に対するビジネスレベルのインタフェースを表します。この機能の詳細については、『Application Integration 入門』を参照してください。
サービスは、アプリケーション ビューによってエクスポーズされるアプリケーション内のビジネス オペレーションです。サービスは要求/応答のメカニズムとして機能します。アプリケーションが、ビジネス サービスを呼び出す要求を受信すると、アプリケーション ビューが対象アプリケーション内のサービスを呼び出し、結果を記述した XML ドキュメントを返します。
サービスを定義するには、入力要件、出力予想、および対話仕様を定義する必要があります。
ロギングは、アダプタに不可欠な機能です。通常、アダプタは複数のアプリケーションの統合に使用され、データの処理時にエンドユーザとは対話しません。フロントエンド コンポーネントとは異なり、アダプタにエラーや警告が発生すると、処理を中断してエンドユーザの応答を待つことができません。
また、アダプタが統合するビジネス アプリケーションの多くは、重要な役割を担っています。たとえば、アダプタに、EIS とのすべてのトランザクションに関する監査レポートの保持が要求されるケースが考えられます。その場合、アダプタ コンポーネントは、正確なロギング情報と監査情報を提供する必要があります。ADK のロギング フレームワークは、ロギングと監査の両方の要求に対応するように設計されています。
ADK には、ローカライズされたメッセージを複数の出力先にログとして記録できるツールキットが用意されています。ロギング ツールキットを使用すると、Apache Log4j オープン ソース プロジェクトの機能が強化されます。
ロギング ツールキットは、Log4j 内の重要なクラスをラップし、J2EE 準拠アダプタの構築時に追加機能を提供します。このツールキットは、logtoolkit.jar
ファイルにあります。
ロギング ツールキットの使用方法の詳細については、「ロギング ツールキットの使い方」を参照してください。
ADK では、ロギング フレームワークを実装することにより、アダプタ アクティビティのログを記録できます。このフレームワークにより、複数の出力先へのインターナショナライズまたはローカライズされたメッセージを記録できます。また、メッセージ、カテゴリ、優先度、フォーマット、および送信先を調整するためのさまざまなコンフィグレーション パラメータを使用できます。
ロギング フレームワークではカテゴリ階層が使用され、アダプタ内のすべてのパッケージおよびクラスでロギング コンフィグレーションを継承できます。また、パラメータは実行時に簡単に変更できます。
ロギング フレームワークでは、ログ メッセージをインターナショナライズできます。インターナショナライズされたアプリケーションは、コードを作成し直すことなく、世界中のエンドユーザの言語および語法に簡単に変換できます。ローカライゼーションは、ロケール固有のコンポーンネントおよびテキストを追加することにより、ソフトウェアを特定の地域または特定の言語用に変更する処理のことです。ロギング フレームワークでは、Java プラットフォームによるインターナショナライゼーションおよびローカライゼーション機能が使用されます。
どのアダプタにも、個別のアダプタを表し、すべてのアダプタの構成基準となるユニークな識別子としてアダプタ論理名を指定する必要があります。アダプタ論理名は、各アダプタと以下の関連項目を識別するために使用します。
アダプタ論理名は、ベンダ名、アダプタに接続する EIS のタイプ、および EIS のバージョン番号を組み合わせたものです。通常、この名前は「ベンダ_EIS のタイプ_EIS のバージョン」という形式で表わされます。たとえば、アダプタ論理名
BEA_WLS_SAMPLE_ADK
は、以下の情報を表します。
必要な情報が含まれていれば、別の形式で名前を指定することもできます。
アダプタに指定されたアダプタ論理名は、以下のように使用されます。
com.bea.adapter.web
内の抽象メソッド getAdapterLogicalName()
の戻り値として使用されます。アダプタ論理名を割り当てるには、<ConnectorComponent>
要素が含まれた <Application>
要素の Name
属性の値としてアダプタ論理名を指定します。この値は、WebLogic Integration でアプリケーション ビューとデプロイされたリソース アダプタを関連付けるためのキーとして使用されます。コード リスト 2-1 にその例を示します。
コード リスト 2-1 ConnectorComponent 要素の Name 属性
<Application Deployed="true" Name="BEA_WLS_DBMS_ADK"
Path="<WLI_HOME>/adapters/dbms/lib/BEA_WLS_DBMS_ADK.ear"
TwoPhase="true">
<ConnectorComponent Name="BEA_WLS_DBMS_ADK" Targets="myserver"
URI="BEA_WLS_DBMS_ADK.rar"/>
<WebAppComponent Name="DbmsEventRouter" Targets="myserver"
URI="BEA_WLS_DBMS_ADK_EventRouter.war"/>
<WebAppComponent Name="BEA_WLS_DBMS_ADK_Web" Targets="myserver"
URI="BEA_WLS_DBMS_ADK_Web.war"/>
</Application>
注意 : アダプタ論理名を RAR ファイル名として任意に使用できますが、このような命名は URI 属性では必要ありません。
アプリケーション ビューをデプロイすると、J2EE コネクタ アーキテクチャ CCI 接続ファクトリ デプロイメントと関連付けられます。たとえば、ユーザが abc.xyz
アプリケーション ビューをデプロイすると、WebLogic Integration では新しい ConnectionFactory
がデプロイされ、この接続ファクトリと以下の JNDI の場所がバインドされます。
com.bea.wlai.connectionFactories.abc.xyz.connectionFactoryInstance
表 2-1 に、アダプタ論理名が構成基準として使用される機能の種類を示します。
アダプタ論理名は、com.bea.adapter.web. AbstractDesignTimeRequestHandler
の抽象メソッド getAdapterLogicalName()
の戻り値として使用されます。この戻り値は、アプリケーション ビューのデプロイメント時に、接続ファクトリに対する RootLogContext
の値として使用されます。
ADK では、アダプタのデプロイにエンタープライズ アーカイブ (EAR) ファイルを使用します。1 つの .ear
ファイルには、アダプタのデプロイに必要な WAR および RAR ファイルが含まれます。EAR ファイルの例をコード リスト 2-2 に示します。
adapter.ear
META-INF
application.xml
sharedJar.jar
adapter.jar
adapter.rar
META-INF
ra.xml
weblogic-ra.xml
MANIFEST.MF
designtime.war
WEB-INF
web.xml
META-INF
MANIFEST.MF
コード リスト 2-3 に、サンプル アダプタの EAR ファイルを示します。
コード リスト 2-3 サンプル アダプタの EAR ファイル
sample.ear
META-INF
application.xml
shared.jar (shared .jar between .war and .rar)
BEA_WLS_SAMPLE_ADK.war (Web application with
META-INF/MANIFEST.MF entry Class-Path: shared.jar
BEA_WLS_SAMPLE_ADK.rar (Resource Adapter
META-INF/MANIFEST.MF entry Class-Path: shared.jar
RAR と WAR ファイル内には共有 JAR ファイルがなく、どちらも EAR ファイルのルート ディレクトリにある共有 JAR ファイルを参照しています。
EAR ファイルを使用したアダプタのデプロイ方法の詳細については、「アダプタのデプロイ」を参照してください。
![]() ![]() |
![]() |
![]() |