9

より軽いアプリケーションのためにGlassfishをTomcat/OpenEJBに置き換えることはできますか？EJBコンテナとしてのglassfishと比較したOpenEJBのパフォーマンスはどのくらいですか。

Glassfishの代わりにOpenEJBの制限は何ですか？

よろしく

4

6 に答える 6

9

Haniのコメントは、Geronimo 1.0 /OpenEJB2.0に関するものであることに注意してください。OpenEJB 2.xコードベースはGeronimo用に完全にゼロから構築され、その結果、Geronimoでのみ実行されたため、Haniはフランケンシュタインのコメントで間違っていました。組み込みモード、Tomcatモード、およびスタンドアロンモードはすべて失われました。パフォーマンスが良くなかったという点で、ハニのコメントは正しかったことがわかりました。

OpenEJB 3.xの場合、2.xコードベースを放棄し、OpenEJB 1.xで中断したところから再開し、EJB3.0認定に移行しました。2.xと3.xはコードを共有しません。OpenEJB 3.xは非常にうまく機能し、プロジェクトは2008年の最初の3.0リリース以来かなり急速に成長しています。EJB3.1組み込みコンテナーと.wars機能のEJBはOpenEJBから提供されました。最初の@Singleton実装があり、EJB 3.1の残りの部分を完了し、今年の第4四半期までにWebプロファイルを認証することを望んでいます。フェイルオーバーとJMXの監視は、1月から大幅に開発されており、現在は完了しており、3.1.3で数週間以内にリリースされる予定です。フェイルオーバーは実際には第2世代であり、最初のフェイルオーバーサポートは3.1.1でリリースされました。3.1では重要なリモートパフォーマンス作業が行われました。

一部の人にとってはそれほど重要ではありませんが、他の人にとっては非常に重要なことですが、ApacheOpenEJBは企業が管理するオープンソースプロジェクトではありません。コミッターの大多数は、コミットを獲得し、職場でOpenEJBを使用しているユーザーです。これには長所と短所がありますが、肝心なのは、OpenEJBはそれを愛し、使用する人々でいっぱいであり、コミュニティはソースと同じようにオープンです。

アップデート

2011年10月、現在ApacheTomEEと呼ばれている「Tomcat+OpenEJB」でJavaEE6Webプロファイル認証を取得しました。

認定されており、名前が明確になっているため、スタックの理解と比較が容易になることを願っています。

個人的なメモとして、私はこのスレッドのコメントを、認証ステップを実行するための主要な動機の1つと見なしています。StackOverlfowの皆さん、励ましと根拠の両方を感じてくださったフィードバックに感謝します。このコミュニティとのつながりは、OpenEJB/TomEEに非常に前向きな変化をもたらしました。

于 2010-07-26T20:15:32.750 に答える
5

質問はランタイム環境に関するものだと思いますが、それでも、より軽いアプリケーションが何を意味するのかわかりません。メモリフットプリント？起動時間は？展開時間？実際にどのような問題がありますか？そして、光を定義してください。

その価値については、GlassFish 3を軽いランタイムと見なしており、それに関する私の経験は非常にポジティブです。製品データシートから：

Oracle GlassFish Server 3はOSGiランタイムを実装します。これにより、必要に応じて機能をJavaサーバーに動的に追加し、アプリケーションをサポートするために可能な限り最小のJavaスタックをデプロイできます。これは、デプロイされたアプリケーションのサービスに必要なモジュールのみをロードすることでフットプリントを可能な限り小さく保つのに役立ち、起動時間を改善し、リソース使用率を削減します。

第二に、私は個人的にフランケンシュタインのアプローチが好きではありません。実際のアプリケーションサーバーで得られるすべての部分の接着剤は付加価値の一部であると信じています。そのため、実際にアプリサーバーを使用しています。

第三に、私はOpenEJBをベンチに置いたことはなく、テストのみに使用し、本番環境に使用する予定はありませんでした。これは主に評判が悪いためです。TSSでのGeronimoのパフォーマンスに関するこのコメントを参照してください（Hani Suleimanから、苛性である場合でも驚かないでください）：

EJB層が「許容可能」であると言うことは、あなたが言える最も素晴らしいことだと思います。

私の知る限り、geronimoのejbコードはopenEJBに基づいています。これは、歴史的に、Beanを見つけることができる最悪のコンテナーです。あなたもそれを見つけるのはかなり難しいように見える必要がありますが、その疑わしい目標を達成した後は、さまざまな程度の後悔/怒りで満たされるだけです。

Gのパフォーマンスが常に標準以下であることは驚くべきことではありません。ソフトウェアビルドのフランケンシュタインアプローチは、パフォーマンスが悪い場合の優れたレシピです。確かに、きれいな図、見栄えの良い依存関係グラフ、緩い結合がたくさんあります。これらはすべて、ブラックボックスとして扱うことができる一貫性のあるアプリサーバーを必要とするユーザーにはまったく関係ありません。

状況が変わった可能性があります。OpenEJBはおそらく少なくとも少しは改善されていますが、それでも次のようになります。

  • OpenEJBはEJB3.1を完全にはサポートしていません。
  • Tomcat +OpenEJBはまだ完全なJavaEE実装ではないため、クリーチャーにいくつかの部分を追加する必要がある場合があります（Java EE 6についても言及していません）。
  • そして、管理、クラスタリングなどはどうですか？
  • 完全なJavaEE6プロファイルが必要ない場合は、Java EE6Webプロファイルがあります。
  • GlassFish 3には満足していますが、「重い」とは思いません（試してみることをお勧めします）。
  • 私はそれがうまくいくことを知っています。

これらすべての理由から、特に解決する問題がない場合は、GlassFishの代わりにTomcat+OpenEJBを検討しません。

関連する質問

も参照してください

于 2010-07-26T07:21:56.470 に答える
4

簡単なテストで、Glassfishは自分のニーズ（起動時間とメモリ使用量）に対して十分に軽くないことがわかりました。これまでのところ、openejbに満足しています。

于 2010-07-27T08:22:32.003 に答える
4

本当に面白い投稿。これは、3、4年前にOpenEJB 3.0を試す前の私たち（会社）の意見でした。

現在、OpenEJBの使用経験は豊富で、本番/開発で広く使用されています。それは本当に軽くて使いやすいです。OpenEJBのおかげで、開発者は多くの時間を節約できます（Matthew B. Jonesの投稿も素晴らしいフィードバックです）。

コミュニティは活発で、心を開いており、ユーザーの実際のフィードバックから得られる便利な機能を使用して、製品を支援および改善する準備ができています。

そして最後になりましたが、パフォーマンスは実際に素晴らしいです！

ジャン・ルイ

于 2010-07-30T11:36:52.753 に答える
3

スタンドアロンアプリケーションサーバーの軽量で組み込みの代替手段としてのOpenEJB。アプリケーションをJBossとWeblogic（両方をサポートする必要がありました）からTomcat/OpenEJBに大きな問題なく移植しました。パフォーマンステストでは、結果が向上するか、悪化しないことが示されました。

OpenEJBの最大の制限は、不完全なドキュメントです。そのWebサイトは問題ありませんが（実際にはオープンソースプロジェクトとしてはかなりまともです）、JBossやGlassfishな​​どと比較することはできません。

注意すべきもう1つの点は、ActiveMQをJMSプロバイダーとして使用していることです。これは別のオープンソースプロジェクトです。ActiveMQとの統合は優れていますが、いくつかの制限があります。たとえば、ActiveMQの最新リリースにアップグレードするだけでは不十分です。

繰り返しになりますが、オープンソースではいつものように、サポートとドキュメントの欠如は、それを作成するソースと開発者への無料アクセスによって補われます。

于 2010-10-09T03:55:26.130 に答える
2

Glassfishが現在Oracleを意味しているという意味で、私はDavid Blevinsを支持していると思います。そして、彼らがOC4Jに残した遺産を私たちは皆知っています。Glassfishが同じサービスにますます多くのハードウェアを必要とするのではないかと心配しています。

とにかく最善のアドバイスは次のとおりです。ベンチマークを設定し、両方のソリューションを自分で試してください。20時間以内の専門家の作業の問題です。

于 2010-07-26T20:51:36.207 に答える