私の同僚は、JAR 内にパッケージ化されたクラスとして機能するため、ローカル EJB を使用するのは良い考えではないと言いました (つまり、local通常のクラスよりも利点がないため、EJB のみを使用する場合)。また、コードの一部が複数のアプリケーションで使用される可能性がある場合にのみ、EJB を使用する必要があります。しかし、EJB のその他の利点 (セキュリティ、スレッドセーフ、トランザクションなど) について読みました。
だから私は混乱しました：いつGWTサーブレットを使うべきか（単純なものよりも便利でHTTPServlet、RPCスタイルのメソッド呼び出しを提供します）、いつEJBを使うべきですか？
PS JPA 2.0、CDI などの先物は使用しません (WAS 7 では Java EE 5 しか使用できないため)。
私の同僚は、ローカル EJB を使用するのは得策ではないと言っていました。
私はそれに強く反対します。ローカル EJBは、ビジネス ロジックを実装するのに最適なタイプの Bean であるため、非常に優れたアイデアです。現在の EJB Bean の作物は非常に軽量であるため、重量が重いという理由でそれらを避ける必要はありません。
これらのタイプの Bean の最大の利点は、おそらく自動トランザクション管理であり、あらゆる種類のデータベース作業を行う際に非常に役立ちます。
JMS キューや複雑な EIS システムにアクセスする必要があるのは、エンタープライズ アプリケーションだけではありません。一度に複数のデータベースへの書き込みを行う Web アプリケーションは、このことから大きな恩恵を受けます。トランザクションがなけれUserば、例外やクラッシュが発生するたびに、データベースに半分しか保持されないということになります。また、EJB を使用しないと、大量の非常に冗長なステートメントでコードを散らかさなければならずstart\commit\rollback、トランザクションを (通常は「接続」を介して) すべてのコードに伝播し、トランザクションがアクティブである場合とアクティブでない場合とで別々のケースを持つことは言うまでもありません。
EJB Bean を使用すると、その複雑さがすべて解消されます。ガベージ コレクションと手動のメモリ管理のようなものです。
@RolesAllowed宣言型ロール チェック ( )、Bean のプーリング (特にスループットを調整するため)、スレッド セーフなど、最も単純な Web アプリケーションでも利用できる興味深い機能が他にもたくさんあります。
Java EE 6 では単純な Web アプリケーションで使いやすくなり、.war のどこにでも表示できます (別の .jar と傘の .ear はもう必要ありません)。
だから私は混乱しています: GWT サーブレット (単純な HTTP サーブレットよりも便利で、RPC スタイルのメソッド呼び出しを提供します) をいつ使用し、いつ EJB を使用するのですか?
ここで、リモート EJBについて説明します。この場合、答えは異なります。
クライアントがインターネットから接続している場合、リモート EJB を使用することはほとんどありません。クライアントのポートを含め、通常、開く必要があるポートは多数あります。
同様に、異種クライアント (.NET、C++、さらにはリモート EJB が使用する AS のわずかに異なるバージョンを実行している Java クライアント) がある場合、通常はリモート EJB を使用しません。
理論的には Corba (IIOP) をサポートしているため、さまざまなタイプのクライアントを使用できますが、実際にはリモート EJB 通信は、クライアントとサーバーの両方が Java を実行していて、同じ AS (アプリケーション サーバー) を除いて同じであるか、それらの 1 つが Java SE クライアントである場合にのみ機能します。リモート サーバーのクライアント ライブラリ (巨大になる可能性があります)。
リモーティング テクノロジとしては少し厄介ですが、EJB 仕様ではそもそもリモート接続の設定方法さえ指定されていません。事実上の標準はリモート JNDI ですが、これは仕様ではないため、JBoss はたとえば JBoss AS 7 でのサポートを停止したいと考えていました。
いずれの場合も、Web Serviceリモート EJB の代わりにテクノロジを使用します。GWT Servletオプションかもしれませんが、ここでは実際には正規の例ではありません。すでに GWT を使用している場合を除き、任意の (非 GWT) クライアントからの一般的な web/rpc 接続のためだけにインストールすることはお勧めしません。
一般的な Java ソリューションは、SOAP resp REST 実装である JAX-WS と JAX-RS です (どちらも EJB と組み合わせることができます)。よく知られている JAX-RS 実装は、Jersey (例) とRestEasyです。Java EE 6 では、それらは既にプラットフォームの一部であるため、何もインストールする必要はありません。Java EE 5 の場合、JAX-RS を個別にインストールする必要がありますが、JAX-WS は既にインストールされています。
一般的に、JAX-RS の方が使い始めやすく、最新のアプローチであることがわかりますが、JAX-WS にはより多くの型安全機能が組み込まれています (複雑さのほとんどの原因はまさにそこにあります)。
最後に、いつリモート EJB を使用するのでしょうか? 通常、これは、同じ AS を実行しているローカル ネットワーク上のアプリケーション間の通信に対して行います。その場合、潜在的なパフォーマンス上の利点があり (バイナリ シリアライゼーションは json/xml 変換より高速である可能性があります)、セキュリティ コンテキストを伝播し、分散トランザクションを調整するためのいくつかの強力なオプションがあります。単純な Web アプリでは、最後の機能はほとんど必要ありません。
よく見られるパターンは、リモート (Web) クライアントからの要求を受け入れ、実際のビジネス ロジックを含むローカル EJB に作業を委譲する JAX-RS リソース (Bean) のパターンです。
EJB は、独自のコンテナのバックエンドで使用されるテクノロジであり、開発者に対して透過的なトランザクション セキュリティなどの機能を提供します。
Java EE チュートリアルから:
アプリケーションに次のいずれかの要件がある場合は、エンタープライズ Bean の使用を検討する必要があります。
アプリケーションはスケーラブルでなければなりません。ユーザー数の増加に対応するために、アプリケーションのコンポーネントを複数のマシンに分散することが必要になる場合があります。アプリケーションのエンタープライズ Bean を異なるマシンで実行できるだけでなく、それらの場所もクライアントに対して透過的なままになります。
トランザクションは、データの整合性を確保する必要があります。エンタープライズ Bean は、共有オブジェクトの同時アクセスを管理するメカニズムであるトランザクションをサポートします。
アプリケーションにはさまざまなクライアントがあります。わずか数行のコードで、リモート クライアントはエンタープライズ Bean を簡単に見つけることができます。これらのクライアントは、シンで、多様で、数が多い場合があります。
現在、単一の Web サーバーで Web 開発のみを行っている場合、EJB はあまり役に立ちません。たとえば、GWT サーブレットなどの他の簡単なオプションがあります。
ただし、マネージド トランザクションを使用する場合、JMS キューに接続する場合、またはバックグラウンドでバッチ処理を実行する場合は、EJB が役立ちます。
たとえば、注文を受けて、注文を履行するためにさまざまな部門と通信する必要があるとします。この場合、フロントエンドが注文の準備中であることを顧客に通知している間に作業を行うバックグラウンド プロセスが必要になります。サーブレットは、メッセージ駆動型 Bean が注文を受け取り、他の EJB を呼び出して何らかの処理を実行できるキューに注文を送信できます。
アプリケーション/プロジェクトの要件範囲によって異なります。EJB は、Java EE 機能をサポートするために使用されます。プロジェクトの範囲には含まれません。使用しないでください。Java EE の機能