12

私は LAMP スタックに精通しており、何年にもわたって、LAMP スタックに基づいたいくつかの Web スタイルのデプロイに成功してきました。Apache + modPerl から、PHP、Ruby、Rails まで、あらゆるものを使用してきました。私の Rails サイトは、キャッシングをうまく利用することでかなりの負荷に耐えることができますが、大したことではありません。

私は言語としての Java や XML があまり好きではなく、Java EE の側面全体を無視してきました。両方の世界で実際の直接的な経験をしたことがある人へ: Java EE について、私が見逃している超クールな何かがありますか? プロプライエタリなアプリ サーバーの高価格を正当化するものは何ですか?

私はここでトローリングしているわけではありません: Java EE が実際に最新のLAMP フレームワークに欠けているものの具体的な例を探しています (そのような違いが存在する場合)。(モダン = Rails、Django など)。代わりに、LAMP が実際に優れていること (1 つの XML シット アップが少ない) をパイプします。

+++++ 2008 年 10 月 16 日更新

残念なことに、ここでの返信のほとんどは役に立たず、単純に次の 2 つのカテゴリのいずれかに分類されます。 LAMPスタック」。

私はかなりの量の読書を行い、Java EE には本当に優れたトリックが 1 つしかないという結論に達しました。それはトランザクション (ありがとう、ウィル) であり、残りの部分については、成功するか失敗するかは自分のメリット次第です。環境には本質的に何もありません。スケーラブルで信頼性の高い Web サイトを作成するために、実際に Java EE には失敗しやすいトラップがかなりあります (たとえば、かなりの量の JMS に今支払っていることに気付かずにセッション Bean を使い始めるのは簡単です)。別の設計でおそらく回避できたはずのトラフィック。)

有益な議論

4

9 に答える 9

18

Java EE が LAMP スタックに対して提供する主な差別化要因は、1 つの単語に要約できます。トランザクション。

小規模なシステムのほとんどは、データベースによって提供されるトランザクション システムに依存しているだけであり、多くのアプリケーションにとっては (明らかに) 非常に満足のいくものです。

ただし、各 Java EE サーバーには分散トランザクション マネージャーが含まれています。これにより、さまざまなシステムでより複雑なことを安全かつ確実に行うことができます。

これの最も単純な例は、データベースからレコードを取得し、それをメッセージング キュー (JMS) に入れ、その行をデータベースから削除するという単純なシナリオです。この単純なケースには 2 つの別個のシステムが関係しており、トランザクションの外で確実に実行することはできません。たとえば、行をメッセージ キューに入れることはできますが、(システム障害のために) データベースから行を削除することはできません。JMS プロバイダーとのトランザクションとデータベースとの別のトランザクションを使用しても、トランザクションが互いにリンクされていないため、実際には問題が解決しないことがわかります。

明らかに、この単純なシナリオを回避したり、対処したりできます。ただし、Java EE の優れた点は、この種の問題に対処する必要がないことです。コンテナが対処します。

繰り返しになりますが、すべての問題でこのレベルのトランザクション処理が必要になるわけではありません。しかし、そうする人にとって、それはかけがえのないものです。使い慣れると、Java EE サーバーのトランザクション管理が大きな資産になることがわかります。

于 2008-10-04T03:35:37.270 に答える
10

強力な Java EE Web サーバー (Jboss、WebSphere、WebLogic など) と Windows Server/IIS/ASP.NET は、スケーラビリティとパフォーマンスにおいて、通常のランプ スタックとはまったく異なります。

私のチームは、米国最大の通信商取引サイトの 1 つを担当しており、1 日あたり数百万件のヒットを処理しています (データベースの 1 つはサイズが 1000 TB を超えています)。

サイトのさまざまなセクションに、ASP.NET と WebSphere、および SAP ISA (Java EE ソリューションでもある) を組み合わせて使用​​しています。LAMP スタックが、大量にスケーリングせずにこの種の負荷を処理できる方法は絶対にありません。ハードウェアの .....NET スタック セクションが負荷の大部分を処理し、32 台のサーバーのみで実行されます。

また、memcached タイプのソリューションや静的 HTTP キャッシュの使用など、手の込んだことは一切行っていません...個々のアプリ サーバーで SOAP 呼び出しとデータベース呼び出しをキャッシュしますが、インメモリ データベースなどは使用しません...私たちのプラットフォームはこれまでのところそれを処理できます。

ええ、この種のものをLAMPと比較するのは、リンゴとオレンジです。

于 2008-10-04T03:13:49.153 に答える
4

Amazon.com、ebay、google -- それらはすべて Java EE のサブセットを使用しており、かなりの成功を収めています。それらはすべてサーブレットと JSP を使用します

EJB 1.1 または EJB 2.0 を使用しようとすると、スケーラビリティーが損なわれます。単体テストが難しくなるため、開発者の生産性も低下します。

EJB 3.0 により、開発者の生産性とアプリケーションのスケーラビリティが向上します。

そのため、アプリケーションのニーズに応じて、自分にとって意味のある Java EE の部分のみを使用してください。使用する予定の部品のみを使用して、サンプルの POC (概念実証) を行います。この POC は、アプリケーションがどれだけうまく機能するかを示します。

NEW Java EE アプリケーション サーバーは、常に大量の XML を必要とするわけではありません。注釈を使用して、依存関係の注入とデータベースのマッピングを行うことができます。

すべてのエンタープライズ開発の 50% 以上が Java EE で行われています (私が言うには、ほとんどが Java EE スタックのサブセットを使用しています。誰かがステートレス SESSION Bean EJB を使用し、誰かが単に JNDI を使用し、誰かが MESSAGE DRIVEN BEAN EJB を使用している可能性があります)。 .

それが役に立てば幸い。

于 2008-10-04T03:05:36.643 に答える
4

Java EE を使用すると、非常に大規模でスケーラブルなアプリケーションを構築でき、エンタープライズ コンピューティングで広く使用されています。

しかし：

私の Java EE での私の経験は、私のチームが行っていた作業の 90% がボイラープレートと配管作業だったように見えたので、かなり悪かったです。当時の私たちの生産性は、別のテクノロジー スタックを使用していた場合よりもはるかに低かったのです。

于 2008-10-04T03:08:56.963 に答える
4

ほぼすべての回答で、Java EE Webアプリケーションの構築に必要なものが言及されています。別の重要な考慮事項について言及させてください。ほとんどの企業には、エンタープライズ アプリを他のアプリと統合する必要がある重要なバックオフィス要件があります。これは、粗末な古い COBOL メインフレーム プログラムへの接続から、LAMP スタック、会計士が夜間に作成した小さな Access アプリなどにまで及びます。通常、これは、2 つまたは一緒に接続するより多くのアプリ。私の経験では、Java EE の世界は、これらの統合の問題に対処するために、通常の LAMP スタックよりもさらに拡張されていることがわかりました。

于 2008-10-04T03:48:55.463 に答える
2

Java EE のコアは、コンテナーによって提供される実装を持つインターフェースの集まりです。ほとんどのアプリケーションは、Java EE 仕様のすべてを使用しているわけではありません。

Java EE について議論するときに人々が思い浮かべる Java EE の主な側面は、EJB とサーブレットの 2 つです。

EJB の経験はまったくありません。私はSpring Frameworkを使用しているため、Ben Collinsの回答で参照されている「配管とボイラープレート」コードがすべて提供されています。これは、EJB に必要なすべての機能を提供し、さらにいくつかを提供します (サーブレット部分には IOC コンテナーも使用しますが、データベース アクセスを伴うトランザクションは、その特別な機能を使用するものです)。

ただし、サーブレットは素晴らしいです。それらは非常に優れた実績のあるテクノロジーです。

サーブレットの核となるのは、要求と応答のサイクルです。ユーザーが何かを要求すると、サーバーが要求をインターセプトし、それに基づいて応答を返します。一連の要求と応答は、1 人のユーザーのセッションを使用して追跡できます。

プロプライエタリ アプリ サーバーの価格が高いことについては、なぜこれほど高いのかわかりませんが、Apache Tomcat は非常に優れたサーブレット コンテナーであり、無料です。テストには Tomcat を使用し、展開には WebSphere を使用します (Websphere は、アプリの使用のためにクライアントから提供されます)。残念ながら、これは Websphere 6 (更新 11、残念なことに、これには更新 13 の修正がなく、JSP タグ内に含まれている場合に JSTL 関数が適切に動作することがわかった) のみであるため、Java を使用する必要があります。 1.4x、Java 1.5+ ではありません。

簡単なサーブレット開発を可能にするフレームワークもいくつかあります (例については、前に参照した Spring フレームワークを参照してください)。これを HTTP/HTML に使用するだけの場合は、この開発を簡単に支援するフレームワークが多数あります。

于 2008-10-04T03:20:18.860 に答える
1

スケーラビリティやその他の問題はさておき、ここでは言及されていない簡単なことが1つあります。これは、利点となる可能性があります。それはJavaです。

  • プロプライエタリとオープンソースの両方で、Javaで利用できるサードパーティのライブラリが驚くほどたくさんあります。さて、Perl、Ruby、PHPなどの巨大な無料ライブラリがあると確信していますが、よりニッチなアプリケーション領域の商用ライブラリに関しては、Java（および.NET、おそらくC ++）には近づいていません。 ）。もちろん、特別なサードパーティライブラリが必要かどうかは、構築しているアプリケーションの種類にのみ依存します。
  • 世界には、他のどのプラットフォームの開発者よりも多くのJava開発者がいると思います。（たぶん私は間違っていますが、これは私が時々聞いたことです。）

商用環境でプラットフォームを選択する場合、どちらかが重要になる可能性があります。

于 2009-02-06T06:57:21.980 に答える
1

Java EE およびその他のプログラム言語は、他のツールと同様に扱う必要があります。はい、エンタープライズ環境で使用されており、これらのツールを「完全に」機能させ、いつ使用するかを知るには、優れた職人技が必要です。私は現在メインフレーム環境で作業しており、Java EE はある程度使用されています。高速なトランザクションが関係する場合、Java EE は私の最後の選択肢です。マルチプラットフォームの相互運用性が必要な場合は、Java EE、XML、および Web サービスがより適切です。

于 2008-10-04T03:56:37.350 に答える
1

スケーラビリティーに関して、Java EE は、LAMP スタックや RUBY にはない大きな選択肢を提供します。ほとんどの LAMP および ruby​​ アプリケーションは 2 層ですが、すべての選択肢は N 層アプリケーションを中心に展開されます。

私はアプリケーションを開発しており、人々がネット経由で API にアクセスできるようにする予定です。Java EE を使用すると、UI 層に影響を与えることなく、中間層を簡単に拡張できます。アプリケーションにインターフェースを追加すると、中間層を非常に簡単に拡張できます。LAMP スタックには、組み込みのこの概念はありません。

そのため、インターフェイス、Web UI、および SOAP API が必要です。今、残りの API が必要です。わかりました...そのインターフェイスを構築して、中間層にもヒットします..さらにコンピューターをクラスターに追加します..またはマルチクラスターに移行するかどうかは実際には問題ではありません。この中間層はすべて EJB であり、多くの点で SOAP よりも高速なプロトコルです。

ここで、ユーザーに SMS テキストを送信する機能を追加したいとしましょう。また、設定に基づいてこれを行う必要があり、それはデータベースから取得されます。スケーラビリティに関しては、テキストの実際の送信を、アプリケーションが送信したい認識から切り離したいと考えています。これはJMSを叫びます。タイマー Bean を使用して、X 時間ごとにオフにし、送信する必要があるメッセージを特定し、各メッセージを JMS に入れることができます。これで、キューと、キューで作業しているプロセッサの数などを管理できます。送信されるテキストの数を確認できます。レシーバーを別のボックスに配置することもできるため、他のサーバーのパフォーマンスにはほとんど影響しません.

スケーリングに関しては、どの EJB が最もヒットしているかを確認し、それらの EJB にリソースを追加し、他の EJB からリソースを削除することができます。これは、JMS キューと、Java EE テクノロジ スタックの他のすべての部分を使用して行うことができます。スケーラビリティが得られるだけでなく、サーバー リソースの管理も得られます。

LAMP と Ruby には、非同期処理用の JMS のようなキューや、ビジネス ロジックを別の層に簡単に配置する機能がまだないため、複数のインターフェイスでスケーリングするのが難しくなる可能性があります。ロジックを切り取って、別のインターフェイスで利用できるようにするには、どうすればよいでしょうか? Web UI だけでなく、Web サイト用のデスクトップ UI、IVR インターフェイス、SOAP インターフェイスを提供するとしますか?

于 2008-12-16T22:56:38.253 に答える