理由はセキュリティでもアプリの起動時間でもないと思います。根本的な原因を突き止める前に、舞台裏にあるものを理解しましょう。
Java コントロール パネルには、ユーザーがデフォルトのブラウザのプロキシ設定を使用したり上書きしたりできる設定があります。つまり、インフラストラクチャ チームは、Windows または OS のインストール イメージをカスタマイズして、エンタープライズ プロキシ設定で JVM をプレインストールすることができます。したがって、これはまったく問題ではないと思います。
Java Web Start は、Java コントロール パネルでカスタマイズ可能な設定を使用して、すべてのアプリを実際にキャッシュします。アプリがキャッシュされると、アプリは他のアプリと同様に「インストール」されます。初回の実行は遅くなる場合がありますが、JVM のスマートなメモリ割り当て技術により、2 回目は高速になります。そのため、起動時間が問題になる可能性がありますが、現在、多くの Web サイト (企業内のものも含む) がポータルに移行されています。Web ポータルには、通常、開発目的で未使用のライブラリが多数含まれています。これは、ポータル自体が、特定のページで構築およびデプロイされるポートレットの種類を予測していないためです。したがって、単一のポータル ページをダウンロードすると、最大で MB が消費され、5 秒以上でページが完了する可能性があります。これは 1 ページのみであり、キャッシュは最大 30% 役立ちますが、毎回ダウンロードする必要がある HTML/Javascript/CSS コンポーネントはまだたくさんあります。これにより、ここでは Java Web Start が有利であると確信しています。
Java Web Start がキャッシュされている場合、サーバー コピーがアップグレードされない限り、Java Web Start が再度ダウンロードされることはありません。したがって、たとえば、MS Project のようなプロジェクト管理ソフトウェアが SmartClient (JWS と同様) を使用して完成した場合、クライアントとサーバー間の情報交換は、ブラウザのページ全体の更新などのプレゼンテーションのない純粋なデータになります。Ajax の助けを借りても、ページ全体のダウンロードが完全になくなるわけではありません。その上、多くの企業は、Ajax はまだ未熟で安全ではないと考えています。そのため、Ajax は開発者の間では話題になっていますが、エンタープライズ ソフトウェアではまだ注目されていません。それを念頭に置いて、JWS アプリには、JWS アプリがサンドボックスにデプロイされて実行される方法、署名されている方法、はるかにインタラクティブな GUI を備えている方法など、間違いなくより多くの利点があります。
その他の利点には、開発の高速化 (コードとパフォーマンスのデバッグが容易)、応答性の高いユーザー インターフェイス (PUSH 機能を提供するために Comet サーバーを必要としない)、実行の高速化 (クライアント コンピューターが HTML/Javascript/CSS のような変換なしで GUI をレンダリングするため) が含まれます。および少ないデータ処理)。
これらすべての後、私はまだ質問に触れていません.なぜJWSはそれほど有名ではないのですか?
私の意見では、Brian Knoblauch のコメントと同じで、意識がないということです。
IT 関係者は、Web テクノロジ、Ajax PUSH、GWT などの誇大宣伝にあまりにも惹かれすぎており、これらすべてのバズワードにより、クライアントにとって実際に機能するものではなく、さまざまなテクノロジを使用する楽しさや技術的な課題を解決することにバイアスがかかっています。
シトリックスを見てください。Citrix は実際には素晴らしいアイデアだと思います。Citrix では、バックグラウンドで独自のアプリ ファームを構築できます。クライアント エクスペリエンスに影響を与えずに実行できるアップグレードおよび実装戦略は数多くあります。Citrix の導入は非常に簡単で、安定していて安全です。企業はまだそれを使用しています。ただし、JWS は Citrix よりも優れていると思います。JWS の考え方は、クライアント マシンがアプリケーション自体を実行できる大量のサーバー ファームをホストするのではなく、クライアント マシンでアプリケーションを実行することです。これにより、会社は多くのお金を節約できます!!! JWS を使用すると、開発チームはサーバー側でビジネス ロジックとデータを構築できます。ただし、Web 処理ユニットがなく、クライアント コンピューターにレンダリング プロセスを実行させると、ネットワークの消費量とサーバーの処理能力が大幅に削減されます。
JWS が素晴らしいアイデアである理由のもう 1 つの例は、Blackberry MDS です。Blackberry アプリは、実際には Javascript から翻訳された Java アプリです。BB の MDS スタジオでは、GUI ツールを使用して BB アプリ GUI を構築し、Javascript で GUI ロジックをコーディングします。次に、アプリが翻訳され、BES サーバーにデプロイされます。次に、BES サーバーがこれらのアプリを BB に配布します。各 BB で、GUI レンダリングとネットワーク機能のみを備えたシン Java アプリを実行します。アプリがデータを必要とするときはいつでも、Web サービスを介して BES と通信し、他のサーバーからサービスを利用します。これってJWSのBB版だけじゃないの？それは非常に成功しています。
最後に、JWS は、Sun の宣伝方法のせいで人気がないと思います。BB は、自社の BB Java アプリがどれほど優れているかを宣伝することはありません。クライアントはそれが何であるかさえ気にしないと信じています。BB は、MDS を使用してアプリを開発する利点を宣伝しています。高速、コスト削減、ビジネス リターンです。
ちょうど私の、少し長い、2セント... :)