4

私は、Java EE の全体を掘り下げる時が来たと判断しました。JPAやJMSのようなJava SEでEEを使用していますが、まだJava SEをいじっていて、Java EEとアプリケーションサーバーが私の問題のいくつかを解決すると信じています。

BUT: Web でいくつかの記事を読んだ後、まだいくつか質問があります。

第 1 回: リクエスト/レスポンス アプリケーションに限定されますか? HTTP 経由で XML ドキュメントを提供するアプリケーションがあります。配信されたすべてのオブジェクトは、別のスレッドでディスパッチされるキューに追加されます。リモート マシンへのソケットを開くことを含め、このオブジェクトに対していくつかの検証が行われます (EJ-Beans はこれを行うことが許可されていないと聞きましたが、これは本当ですか?)。それで、アプリケーションサーバー内でこれを行うことは可能ですか?

2 番目: メッセージ駆動型 Bean があることは知っていますが、JMS メッセージをアプリケーション サーバーの外部から MDB に送信することは可能ですか? JMS メッセージを送信するサービスがありますが、同じアプリケーション サーバー内ではなく、レガシー システムとして実行されます。

3rd: システム管理者またはユーザーはアプリケーションをどのように構成できますか? データベース接続などのいくつかはアプリケーション サーバー内で構成されており、私のアプリケーションは JNDI 経由でそれらを検索したり、DI 経由で取得したりできることを知っています。しかし、アプリケーション固有の構成はどうでしょうか?

ええ、これらは非常に初歩的な質問ですが、誰かがこのすべてがどのように機能するかを説明する時間があるかもしれません. :)

よろしく、Posix

PS:

4番目：EJBはファイルに対して何もすることが許可されていないようです.Java EEは、ファイルを受け取り、それらを異なるシステムにプッシュし、それらをソケットに書き込むサービスのオプションではないようです（質問1を参照）?

4

5 に答える 5

2

あなたの場合、Java EEは疑いなく使用できると言えます。あなたの具体的な質問をもう少し掘り下げてみましょう。

  1. EJB からソケット接続を開くことができます。あなたがそれをするのを妨げるものは何もありません。ただし、この種の操作は、Java EE アプリケーションにはお勧めできません。私の意見では、独自のシステムへのソケット接続のプールを管理する Java EE コネクタ (JCA) を実装することをお勧めします。これは、仕様に従ってこのような統合を実装するモデルの方法です。

  2. はい！外部アプリケーション/システム (AS 外) から送信されたメッセージを受信することは完全に可能です。これは、メッセージングを使用した統合の主なアイデアです:) 多くの場合、Java EE アプリケーションであるアプリケーションは JMS チャネルから MDB 経由でメッセージを受信しますが、JMS は単なる API であり、IBM MQ などの任意のメッセージング システムで実装できます。このアーキテクチャでは、外部システムが MQ メッセージをキューに入れ、そのキューをリッスンする Java EE アプリケーションが JMS API 経由でメッセージを受信します。

  3. 一般的に言えば、Application Server は管理者に Java EE リソース (データ ソース、JMS 接続ファクトリ、JMS 宛先、JTA トランザクション マネージャなど) を管理するための優れたツールを提供します。特定の Java EE アプリケーションを変更する機能が必要な場合は、JMX が最適なオプションのようです。 . いくつかの MBean を実装し、それらをアプリケーション サーバーに組み込まれた JMX サーバーにエクスポートするだけで完了です。このタスクは、たとえば JBoss では非常に簡単ですが、最近のアプリケーション サーバーのほとんどは、広範な JMX 機能を提供しています。

  4. 一見したところ、EJB はファイルの処理に最適ではないように見えます。ただし、EJB の実装は依然として純粋な Java で記述されているため、ファイルの読み取りやストリーミングなどを妨げるものは何もないことに注意してください。私は、大きなファイルを入力ファイルとして処理する大規模な Java EE アプリケーションの経験があり、Java EE が適切なテクノロジの選択であることを保証できます :)

于 2009-05-18T11:50:56.410 に答える
0

現在痛みを感じている適切なポイントに各テクノロジーを適用することをお勧めします。ご指摘の点につきましては、

  1. EE コンテキストでは、実際の処理を行う MDB を持つ JMS キューにメッセージを追加します。HTTP リクエスト/レスポンス ライフサイクルの管理については、現在と同じ方法で管理するか、既存のライブラリを使用して管理します。EE アプリ サーバーに移行することで、手動で管理する代わりに、アプリ サーバーがスレッドやトランザクションなどを管理できるようになります。

  2. ダフィーモが述べたように、MDB はメッセージを受信する責任があり、メッセージの発信元は気にしません。

  3. システム管理者は、duffymo が述べたようにアプリ サーバーを構成できます。さらに、JMX Bean を他のシステムまたはエンド ユーザーに公開して、必要に応じてサービスを構成できるようにすることもできます。

于 2009-05-11T20:56:27.210 に答える
0

EJB 1.1 仕様の制限事項は次のとおりです。

あなたの質問に対する私の見解は次のとおりです。

  1. EJB はリモート マシンでソケットを開くことができると思いますが、ソケットを開く操作は低レベルすぎると思います。そのソケットがあなたのために行っていることは何でも、別の EJB として公開することを考えます。
  2. MDB は、特定のトピックまたはキューに登録された単なるリスナーです。送信については何も言いません。クライアントがキューにメッセージを取得する方法を知っている場合、それは可能です。キューの URL を知っていて、接続を作成できることだけが必要です。
  3. 管理者は、接続プール、JNDI 名などを設定します。すべてです。アプリサーバーの管理コンソールを使用してそれを行います。
于 2009-05-11T09:56:13.830 に答える
0
  1. ファイルに対して何かを行うことは、EE 仕様に違反しています (EE アプリが移植可能で配布可能であることを保証するため)。ただし、すべてプレーンな Java コードであるため、yopu は任意の操作を選択できます。ターゲット環境がどのように見えるか (たとえば、システムが内部使用のためのもの) を知っている限り、仕様がそう言っているという理由だけでファイルを変更することを躊躇しません。
于 2009-05-12T11:26:52.063 に答える
0
  1. Tomcat のようなアプリケーション サーバー (おそらく他のサーバーも同様ですが、私はそれらを使用したことはありません) では、要求を受け取ったときに処理を実行できるだけでなく、サーバーの起動時に処理 (実行時間の長いスレッドの開始を含む) を行うこともできます。基本的に、「通常の」Java でできることは何でもできます。実際、サーバーの起動時に適切な main() を呼び出すコードを含めるだけで、通常の Java アプリをアプリケーション サーバーに配置できます。
于 2009-05-12T11:56:11.003 に答える