問題タブ [jca]

2Gb もの大きなファイルの署名を検証する必要があり、できるだけメモリ効率の良い方法で検証したいと考えています。さまざまな理由から、ファイルはすでにメモリに完全にロードされてInputStreamおり、アプリケーションによって を使用してアクセスされます。ストリーム インターフェイスを使用して署名を検証したいのですが、JCASignatureクラスのメソッドは、および関連するクラスupdateのみを受け入れます。byte[]

これを効率的に行うにはどうすればよいですか？ビーストを 2 番目のバイト配列にロードしたくありません。そうしないと、メモリ使用量が非常に高くなりますが、それ以外の場合、インターフェイスはそれをサポートしていないようです。

アップデート

問題があれば、署名アルゴリズムは SHA-1 です

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

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

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

Eclipse WTP のさまざまな種類の Java EE プロジェクトの違いは何ですか?

がある：

• アプリケーション クライアント プロジェクト
• コネクタ プロジェクト
• エンタープライズ アプリケーション プロジェクト
• ユーティリティ プロジェクト

JCA リソース アダプタを作成しています。また、JCA 仕様の接続管理部分を完全に理解しようとしています。思考実験として、このアダプターの唯一のクライアントが、別のマシンにある Swing Java アプリケーション クライアントであるとします。また、リソース アダプタは、ネットワークを介して「エンタープライズ情報システム」(EIS) とも通信すると仮定します。

JCA 仕様を理解しているので、.rar ファイルはアプリケーション サーバーにデプロイされます。アプリケーション サーバーは、ManagedConnectionFactory インターフェースの .rar ファイルの実装を作成します。次に、コネクション ファクトリを生成するように要求します。コネクション ファクトリは、ユーザーがリソースへの接続を取得するために使用する JNDI にデプロイされる不透明なオブジェクトです。(JDBC の場合、接続ファクトリーは javax.sql.DataSource です。)

接続ファクトリは、アプリケーション サーバーが提供する ConnectionManager への参照を保持する必要があります。これは、直列化可能である必要があります。これは理にかなっています。コネクション ファクトリを JNDI に格納するには、シリアライズ可能である必要があり、ConnectionManager への参照を維持するには、ConnectionManager もシリアライズ可能である必要があります。この小さなオブジェクト グラフは、アプリケーション クライアントの JNDI ツリーにインストールされます。

これが私が吐き始めるところです。ConnectionManager (接続管理、共有、プーリングなどを処理することになっているアプリケーション サーバーによって提供される部分) は、この時点で完全にクライアントに存在しますか? そのジョブの 1 つは ManagedConnection インスタンスを作成することであり、ManagedConnection は Serializable である必要はなく、それが提供するユーザー接続ハンドルも Serializable である必要はありません。これは、接続プーリング機構全体がアプリケーション クライアントに大量に出荷され、その JNDI ツリーに詰め込まれていることを示唆しています。

これはすべて、クライアント側からの JCA 対話がアプリケーション サーバーのサーバー側コンポーネントをバイパスすることを意味するのでしょうか? JCA API のネットワーク境界はどこにありますか?

JBossに基づく現在のJ2EEプロジェクトでは、メッセージ駆動型BeanとサードパーティによってRARファイルとして提供されるJCAリソースアダプターを使用して、リモートシステムとインターフェースする必要があります。プロジェクト全体をEARファイルとしてJBossサーバーにパッケージ化してデプロイしたいと思います。特に、RARファイルはEARファイル内に埋め込まれている必要があり、グローバルに展開されるべきではありません。

これまでのところ、これらはすべて正常に機能していますが、RARファイルの参照方法には特に満足していません。たとえば、MDBにパッケージ化されているjboss.xmlは、現在次のようになっています。

これは通常は正常に機能しますが、EARファイルの名前が「test2.ear」に変更されると機能しなくなります。含まれているアーカイブの名前をハードコーディングせずに、埋め込まれたRARファイルを参照する方法はありますか？

編集：ほぼ2か月後、私はまだこの質問に対する本当の答えを見つけていません。周りに聞いてみると、「Mavenのプロパティとフィルタリングを使用する」と「EARにRARを含めない」という2つの役立つ提案しかありませんでした。現在、JBossでこれを適切に処理する方法はないのではないかと強く思います。だから私はそれをあきらめて、ここで得た唯一の答えを受け入れます。

jca アダプター内の ejb3 ローカル ビジネス インターフェイスへの参照を取得できるかどうかを知りたいですか?

リソース アダプタと ejb.jarは同じ にパックされ.earます。アプリケーションは、ejb3 機能パックを使用して WebSphere AS 6.1 で実行されています。

JNDI 名として使用しようとしましejblocal:<full_class_name_of_local_interface>たが、成功しませんでした。

JCA を使用して、WebSphere 内から低レベルのネットワーク リソースとやり取りしてきましたが、Tomcat から外部の同じネットワーク リソースにアクセスできるようにする必要があります (つまり、管理された環境ではありません)。ネットワーク通信とプロトコルのレイアウトは非常に冗長であるため、数千行のコードをコピー/貼り付けすることは避けたいと考えています (そして、それらを個別に維持する必要があります)。

JCA仕様を読むと、管理されていない環境（Tomcatなど）でコードを実行するためのサポートがあると思われます。残念ながら、インターフェイスが何をするべきか、または管理された環境の外からそれらを呼び出す方法がわかりません (仕様はかなりあいまいです)。

管理されていない環境で使用できるように JCA を変更する方法を示す実装例はありますか?

ありがとう！

JBPM で使用できる JCA リソース アダプタはありますか? Jboss App サーバーがない本番環境で JBPM はどのように使用されますか?

JCA はレガシー EIS 統合用であると読みました。この仕様は、アプリケーション開発者ではなくベンダー向けですか? 開発者が技術的またはビジネス上の問題を解決するために JCA アダプターを作成したユース ケースを知りたいと思っています。

以前に JCA リソース アダプタを作成したことがあります。

しかし、今では、BootstrapContextとそれに関連付けられた にアクセスするためだけに 1 つを作成しなければWorkManagerならず、事実上、他の理由がない状況に陥っています。

私が仕様を正しく読んでいる場合 (それが私の質問です)、誰かが私のリソース アダプタを仕様に準拠した方法で使用ManagedConnectionFactoryできるようにしたい場合でも、 を実装する必要があるように見えます。実装によって提供されるユーザー接続ファクトリは、アノテーションManagedConnectionFactoryを介した注入の対象となります。@Resource

さあ、もう一度読んでください。待ちます。:-)

完璧な世界では、ResourceAdapter実装を作成し、注釈を付け@Connector、すべてのビットを指定し、ファイルに@ConfigPropertyパックして、それで完了したいと考えています。.rar

しかし、この仕様では、コンシューマー (私の場合はステートレス EJB) とリソース アダプター モジュール間のすべての通信がユーザー接続ファクトリーを介して行われることを事実上義務付けているように見えます。

たとえば、セクション 6.10.1 には次のように書かれています。

リソース アダプタは、次のインターフェイスの実装を提供する必要があります。

• javax.resource.spi.ManagedConnectionFactory
• javax.resource.spi.ManagedConnection
• javax.resource.spi.ManagedConnectionMetaData

しかし、セクション 18 (注釈に関するセクション) は、これを意味のある方法で強制することを規定していないようです。

これは本当にそうですか？そのはずだとは思いますが、1.6 のリソース アダプタをまとめた人たちの意見を聞きたいです。