0

現在、ロジックモジュールとUIモジュールとして実装したい大学向けのプロジェクトに取り組んでいます。Webアプリケーションのデプロイの経験はほとんどありませんが、次の代替案を考え出しました。

  1. 単一のWARプロジェクトとしてデプロイします(これにより、UIとアプリケーションのバックエンドとの通信に関する問題が解決されます)。
  2. プロジェクト間の通信にWebサービスを使用して、同じサーバーに2つのWARプロジェクトをデプロイします。(Tomcatサーバーにデプロイされたこのアプローチを使用したプロトタイプがあります)
  3. WARプロジェクトとEJBプロジェクトをデプロイします。
  4. WARおよびEJBプロジェクトへの参照を含むEARプロジェクトをデプロイします。(Glassfishサーバーにデプロイされたこのアプローチを使用したプロトタイプがあります)

これらの選択肢のいずれかが正しくないかどうか、またはいずれかの選択肢が他の選択肢よりも優れているかどうかを知りたいと思います。具体的には、プロジェクトをEARモジュールとしてデプロイすることが役立つ(またはしない)のはなぜですか?

現在プロジェクトが開始されているため、現在は数百人のユーザーのみを処理します。ただし、プロジェクトが成功した場合は、数百万人のユーザーに対応する必要があります。

4

1 に答える 1

1

Tomcatはサーブレットコンテナですが、選択肢はどれも正しくありません。EJBが必要な場合は、Tomcatを完全なEEサポートに拡張したTomEEのようなものが必要になります。または、そのGlassfishを使用します。

何が最善かは、特定の要件によって異なります。モジュールのデカップリングをもっと必要とする/評価するのか、それとも、物事をまとめる一貫性と信頼性を持たせるのか。EJBには、興味深いと思われるいくつかの追加の利点もありますが、すべてのプロジェクトに関連しているわけではありません。上記の代替手段に加えて、JMSベースの通信、HTTP REST通信、OSGiを使用したパッケージの分離などの他の方法があることに注意してください。

wikipediaを引用して、プロジェクトをEARモジュールとしてデプロイすることが有用である理由について:「EAR(Enterprise ARchive)は、JavaEEが1つ以上のモジュールを単一のアーカイブにパッケージ化してさまざまなモジュールをデプロイするために使用するファイル形式です。アプリケーションサーバーへの移行は同時に一貫して行われます。また、モジュールの導入方法を説明する導入記述子と呼ばれるXMLファイルも含まれています。」つまり、基本的には、信頼性に帰着する結合の利点を得ることができます。モジュールが互いに対照的にどのように展開されているかを常に知っているはずです。EARモジュールはEJBモジュールなどのEEメカニズムを非常によくサポートしており、制御可能なコンテナーを取得します。

スレッドはすでに存在します。EARを使用するのが適切なのはいつですか。また、アプリをWARに含める必要があるのはいつですか。、これは興味深いかもしれません。

于 2013-02-23T17:03:18.727 に答える