14

私たちのアプリケーションは、多くの場合、Web サービス、MQ、JDBC、専用 (ダイレクト オーバー ソケット)、およびその他の種類のトランスポートを介して、さまざまな種類のバックエンドに接続します。アプリケーションからこれらのバックエンドに接続できるようにする実装がすでにいくつかあります。これらの実装はすべて共通の Java インターフェイスを実装していますが、他には何も共有していません。

これらの特定のコネクタ実装のすべてに共通するコードの意味部分があることに気付き、1 つのユニバーサル コネクタを使用して将来のコネクタの開発を合理化することを決定しました。このコネクタは、バックエンドが期待する形式にメッセージをフォーマットし、利用可能なトランスポート メカニズムを使用してメッセージを送信できます。たとえば、MQ またはソケットを介した固定長メッセージ形式。

私たちが直面しているジレンマの 1 つは、この種のコネクタに最適なテクノロジです。これまでのコネクタは、共通の Java インターフェイスを実装する基本的な Java クラスでした。通常、Java EE アプリケーション サーバーでアプリケーションをホストしているため、このソフトウェアには Java コネクタ アーキテクチャが最適なテクノロジと思われます。ただし、JCA 準拠のコネクタの実装は比較的複雑に思われます。標準 - JCA を採用することの明らかな利点は何ですか? また、その利点は追加の努力を正当化しますか?

4

5 に答える 5

4

独自のプロトコルを介して通信する gps デバイス用のインバウンド リソース アダプターを開発しました。それほど面倒ではありませんでしたが、アウトバウンドの開発にはさらに多くの作業が必要になる可能性があるという印象を受けました. JCA の最悪の点は、ドキュメントがないことです。すべての本と記事には、同じばかげた例があるようです。

一番嬉しいのは携帯性です。アダプターを作成したら、rar (リソース アダプター アーカイブ) を任意のアプリケーション サーバーにプラグインして、デプロイされたアプリケーションが ra でサポートされている eis と通信できるようにします。または、rar を war/ear にバンドルすることもできます。

于 2009-04-04T02:55:03.360 に答える
1

利点は主に、任意のアプリサーバーで使用するために独自のバックエンドシステムにコネクタを販売したいベンダー、WebsphereではなくWebLogicでのみ機能するかどうかを気にせずにコネクタをドロップできるようにしたい顧客などです。これは、一般的なJavaEEの目標です。

JBossがJCAにいくつかのものを入れることを決定したことに注意してください。たとえば、JDBC接続はJCAを経由します。

将来のクライアントコードには、標準化されたインターフェイス、いくつかのプーリングおよびトランザクションサポートなどが含まれますが、全体像を見守ることが重要です。つまり、メリットはあなたとあなたの1つのプロジェクトに特に向けられるのではなく、多くのアプリサーバー、多くのバックエンドシステム、多くのコネクタなどで構成されるソフトウェアエコシステムに向けられます。

于 2009-04-07T20:06:35.993 に答える