チャンネルアダプタ †
一言要約 †
Channel Adapterを使うことで、接続するアプリケーションのアーキテクチャやデータ種類を意識することなく、データにアクセスしたりアプリケーション機能を呼び出せる。
要約 †
多くの企業では、複数の異なるアプリケーションを統合するためにMessagingを使用している。
どうやってアプリケーションはメッセージングシステムに繋いでメッセージを送受信しているのだろうか？
ほとんどのアプリケーションはメッセージングインフラと動作するようには設計されておらず、他システムで利用されるデータや機能を含んでいるにも関わらず、自己完結形式やスタンドアローンで開発されている。例えばメインフレームは他システムとつながることはなく1つのすべてのアプリケーションとして設計されている。(レガシー統合は今日のエンタープライズインテグレーションの最も一般的なものの一つ) また、多くのMOMが独自APIを公開していることによりアプリケーション開発者はミドルウェアベンダーごとに複数のインターフェースを実装しなければならない。
もしアプリケーションが他アプリケーションとデータを交換する必要があるならば、OSの基本的機能が使えるファイル交換やほとんどのビジネスアプリケーションで利用しているデータベースなどの一般的なインターフェースを使うよう設計する。またメッセージングを含むインテグレーションソリューションによって使われる汎用APIの内部機能を公開できる。
HTTPやTCP/IPのようなシンプルなプロトコルを使って通信できるかもしれないが、Message Channelと同じ信頼性は提供できないし、データフォーマットはアプリケーション固有であり共通メッセージングソリューションと互換性がない。
カスタムアプリケーションの場合、メッセージを送受信できるようアプリケーションにコードを追加できるが、アプリケーションを複雑にし、これらの変更にて望まない副作用がもたらされることに注意しなければならない。また、このアプローチは開発者がアプリケーションロジックとメッセージングAPIに長けている必要がある。またアプリケーションソースコードにアクセス出来ることを前提としており、サードパーティのソフトウェアベンダーから購入したパッケージ製品を扱うならば、コードを変更できるオプションを持っていないかもしれない。
Channel Adapterを使用することで、アプリケーションAPIやデータ上に基づいたチャネル上にメッセージを公開するデータにアクセスできたり、メッセージを受信しアプリケーション内の機能を呼び出せる。
アダプタはメッセージングシステムへのクライアントとして動作し、アプリケーションが提供するインターフェースを介してアプリケーション機能を呼び出す。同様に、Channel Adapterはアプリケーション内部のイベントをリスンし、これらのイベントに応答してメッセージングシステムを呼び出す。この方法により任意のアプリケーションはメッセージングシステムに接続し、適切なChannel Adapterがある限り他アプリケーションと統合できる。
Channel Adapterはアーキテクチャやアクセスする必要のあるメッセージングシステムのデータの種類に応じて、アプリケーションアーキテクチャの異なるレイヤに接続できる。
ユーザインターフェースアダプタ。時折「スクリーンスクレイピング」と軽蔑して呼ばれるこのアダプタは多くの状況で非常に効果的である。例えば、メッセージングシステムがサポートしていないプラットフォーム上で実装されているかもしれない。またはアプリケーションオーナーがインテグレーション対応にあまり興味をもっていないかもしれない。これはアプリケーションプラットフォーム上でChannel Adapterを動作する選択を排除してしまう。しかしながら、ユーザインターフェースは通常、他のマシンやプラットフォーム(例: IBM 3270端末)から利用できる。また、Webベースのシンクライアントアーキテクチャの急増によりユーザインターフェース統合のリバイバルを起こした。HTMLベースのユーザインターフェースはHTTPリクエストの作成や結果の解析をとても簡単にする。ユーザインターフェース統合の他の利点として、アプリケーション内部に直接アクセスする必要がないことである。いくつかのケースにて、システム内部機能を公開するのは望ましくない、またはできないことがある。ユーザインターフェースアダプタを使い、他アプリケーションは通常ユーザとしてアプリケーションと全く同じようにアクセスできる。ユーザインターフェースアダプタの欠点は、潜在的な脆弱性と低スピードである。アプリケーションはユーザ入力を解析し結果をスクリーンに描画するだけなので、Channel Adapterは画面情報を生データに戻すために解析する必要がある。このプロセスは不必要な手順を多く含むので、遅くなる。またユーザインターフェースはコアアプリケーションロジックに比べて頻繁に変更される。ユーザインターフェースが変更されるたびに、Channel Adapterも同様に変更する必要がある。
ビジネスロジックアダプタ。ほとんどのビジネスアプリケーションはAPIとしてコア機能を公開している。このインターフェースはコンポーネント(例: EJB、COM、CORBA)のセットまたはプログラミングAPI(例: C++、C#、Javaのライブラリ)である。ソフトウェアベンダー(または開発者)は他アプリケーションにてアクセス用に明示的にAPIを公開しているので、ユーザインターフェースに比べてより安定している。ほとんどの場合APIへのアクセスはより効率的である。一般的に、アプリケーションが明確に定義されたAPIを公開している場合、このChannel Adapterはベストなアプローチである。
データベースアダプタ。ほとんどのビジネスアプリケーションはRDBにデータを格納している。情報がすでにデータベースにあるので、Channel Adapterは簡単にデータベースから直接情報を取り出せ、アプリケーション統合の負担がかからない方法の一つである。Channel Adapterは関連テーブルにトリガーを追加しテーブル変更時にメッセージを送信できる。このチャネルアダプタは非常に効率的かつ普遍的であり、RDBマーケットを支配する2または3のデータベースベンダーによって支援されている。これは比較的一般的なアダプタを使って多くの異なるアプリケーションに接続できる。データベースアダプタの欠点はアプリケーション内部に深くさぐりこむことである。シンプルにデータを読むだけなら危険ではないかもしれないが、直接なデータベース更新は非常に危険である。また多くのアプリケーションベンダーはデータベーススキーマを未公開にしており、任意に変更する権利を留保していることを意味し、データベースアダプタソリューションを脆くさせる。
Channel Adapterの重要な制約はメッセージをアプリケーション機能に変換できることだが、コンポーネント実装に密接に似ているメッセージフォーマットを必要とする。例えば、データベースアダプタは通常、アプリケーションデータベース内のテーブルとフィールド名と同じになるよう着信メッセージのフィールド名を必要とする。この種のメッセージフォーマットはアプリケーションの内部構造により完全にゆだねられ、他アプリケーションと統合する時につかう良いメッセージフォーマットではない。よって、ほとんどのChannel Adapterはアプリケーション固有メッセージをCanonical Data Modelに沿うメッセージフォーマットに変換するためにMessage Translatorと組み合わせる必要がある。
Channel Adapterは多くの場合アプリケーションまたはデータベースとは別のコンピュータ上で動く。Channel AdapterはHTTPやODBCのようなプロトコル経由でアプリケーションロジックやデータベースに接続できる。アプリケーションやデータベースサーバ上に追加ソフトをインストールしないようにできるものの、これらのプロトコルは通常メッセージングチャネルが提供する保証された配信(Guaranteed Delivery)と同等のサービス品質を提供しない。よって、データベースへのリモート接続は潜在的な障害点になりうることを意識しておかなければならない。
いくつかのChannel Adapterは単方向である。例えば、もしChannel AdapterがHTTP経由でアプリケーションに接続しているなら、メッセージを消費しアプリケーション上の機能を呼び出すことができるが、繰り返しポーリングすることを除いてアプリケーションデータ内の変更を検知できないし、非常に非効率である。
Channel Adapterの興味深いバリエーションはMetadata Adapterであり、しばしばDesign-Time Adapterと呼ばれる。この種のアダプタはアプリケーション機能を呼び出さないが、メタデータ(アプリケーションの内部データフォーマットを定義するデータ)を取り出す。このメタデータはMessage Translatorを設定したりアプリケーションデータフォーマットの変更(詳細は第8章「Message Transformation」参照)を検出したりするのに使われる。多くのアプリケーションインターフェースはこの種のメタデータ抽出をサポートしている。例えば、ほとんどの商用データベースはアプリケーションテーブル定義の形式でメタデータを含むシステムテーブル群を提供している。同様に、ほとんどのコンポーネントフレームワーク(例: J2EE、.NET)は別コンポーネントによって提供されているメソッドを列挙できる特別な「リフレクション」機能を提供している。
Channel Adapterの特別な形式はMessaging Bridgeである。Messaging Bridgeはメッセージングシステムを特定アプリケーションではなく別のメッセージングシステムに接続する。一般的にChannel Adapterは各アダプタがメッセージングシステムと他システム間で成功することを確実にするためのTransactional Clientとして実装されている。
例: 株式売買
株式売買システムはデータベーステーブル内の全銘柄価格のログを保存したい場合がある。メッセージングシステムはチャネルから特定テーブルやスキーマに各メッセージを記録するRDBアダプタを含んでいる場合がある。このチャネル-RDBMSアダプタはChannel Adapterである。このシステムはまたインターネット(TCP/IPまたはHTTP)から外部値付けリクエストを受け取り、内部値付けリクエストと内部値付けリクエストチャネル上に送れる。このインターネット-チャネルアダプタはChannel Adapterである。
例: 商用EAIツール
商用EAIベンダーは自社製品の一部としてChannel Adapterコレクションを提供している。全ての主要なアプリケーションパッケージにアダプタを持つことはインテグレーションソリューション開発をとてもシンプルにする。ほとんどのベンダーはより一般的なデータベースアダプタだけでなくカスタムアダプタを開発するためのSDKも提供している。
例: レガシープラットフォームアダプタ
多くのベンダーは共通メッセージングシステムからUNIXやMVS、OS/2、AS/400、ユニシス、VMSのようなプラットフォーム上で実行するレガシーシステムへのアダプタを提供している。例えば、Envoy Technologies社のEnvoyMQは多くのレガシープラットフォームとMSMQを接続するChannel Adapterである。これはレガシーコンピュータ上で動作するクライアントコンポーネントとMSMQを含むWindowsコンピュータ上で動作するサーバコンポーネントで構成されている。
例: Webサービスアダプタ
多くのメッセージングシステムはHTTPトランスポートとメッセージングシステム間でSOAPメッセージをやりとりさせるChannel Adapterを提供している。この方法では、SOAPメッセージは信頼性があり非同期メッセージングシステムを使ってイントラネット上やHTTPを使ってグローバルインターネット(ファイヤウォールを通じて)上で送信できる。そのようなアダプタの一例は、IBM WebSphere? Application ServerのWeb Service Gatewayである。
担当者のつぶやき †
- 一行目(多くの企業がメッセージングを使ってる)がすでに信じられない件
- サマレてない。後でもうちょっと短縮する。
みんなの突っ込み †
