Я думаю, что причина не в безопасности и не во времени запуска приложения. Давайте разберемся, что стоит за сценой, прежде чем мы выясним причину.
Панель управления Java имеет настройки, которые позволяют пользователям использовать настройки прокси-сервера браузера по умолчанию или переопределять их. Другими словами, команды инфраструктуры могут настроить установочные образы Windows или ОС, чтобы JVM была предварительно установлена с настройками прокси-сервера предприятия. Поэтому я считаю, что это вообще не проблема.
Java Web Start фактически кэширует все приложения с настраиваемыми настройками в панели управления Java. Как только приложение кэшируется, оно «устанавливается», как и другие приложения. Хотя выполнение в первый раз может быть медленным, во второй раз будет быстрым из-за технологии интеллектуального выделения памяти JVM. Таким образом, время запуска может быть проблемой, но многие веб-сайты (даже внутренние) теперь перенесены на портал. Веб-портал обычно содержит множество неиспользуемых библиотек для целей разработки, поскольку сам портал не предвидит, какие типы портлетов создаются и развертываются на конкретной странице. Таким образом, загрузка одной страницы портала может занять до МБ и заполнить страницу более чем за 5 секунд; это всего лишь одна страница, и кэширование помогает до 30%, но все еще есть много компонентов HTML / Javascript / CSS, которые необходимо загружать каждый раз. При этом я уверен, что Java Web Start является здесь преимуществом.
Java Web Start не загружается снова, если он кэшируется, если копия сервера НЕ обновлена. Следовательно, если, например, программное обеспечение для управления проектами, такое как MS Project, выполняется с использованием SmartClient (аналогично JWS), обмен информацией между клиентом и сервером будет представлять собой чисто данные без представления, как полное обновление страницы в браузере. Даже с помощью Ajax это не исключает полной загрузки страницы. Кроме того, многие компании считают Ajax незрелым и необеспеченным. Вот почему Ajax является горячей темой в кругах разработчиков, но пока не касается корпоративного программного обеспечения. Имея это в виду, приложения JWS определенно имеют больше преимуществ, таких как то, как приложения JWS развертываются и выполняются в песочницах, подписываются и имеют гораздо более интерактивный графический интерфейс.
Другие преимущества включают более быструю разработку (проще в отладке кода и производительности), отзывчивый пользовательский интерфейс (не требует, чтобы серверы Comet обеспечивали функциональность PUSH) и выполнение быстрее (наверняка, потому что клиентские компьютеры отображают графический интерфейс без перевода, как HTML / Javascript / CSS и меньше обработки данных).
После всего этого я еще не затронул вопрос, почему JWS не так знаменит?
Мое мнение таково, что это то же самое, что комментарий Брайана Ноблауха, оно без осознания.
ИТ-специалистов слишком привлекает шумиха над веб-технологиями, Ajax PUSH, GWT, и все эти модные слова заставляют их склоняться к удовольствию от использования различных технологий или для решения технических задач вместо того, что действительно работает для клиентов. 1015 *
Взгляните на Citrix. Я думаю, что Citrix на самом деле отличная идея. Citrix позволяет создавать собственные фермы приложений за сценой. Существует множество стратегий обновления и внедрения, которые вы можете использовать, не влияя на работу клиента. Развертывание Citrix чрезвычайно простое, стабильное и безопасное. Предприятия все еще используют это. Тем не менее, я думаю, что JWS даже лучше, чем Citrix. Идея JWS состоит в том, чтобы запускать приложения на клиентских компьютерах, а не размещать тонны серверных ферм, где клиентские машины могут сами запускать эти приложения. Это экономит компании много денег !!! С JWS команда разработчиков все еще может создавать бизнес-логику и данные на стороне сервера. Однако без модуля веб-обработки и предоставления возможности процессам рендеринга клиентским компьютерам это значительно уменьшает потребление энергии и вычислительную мощность сервера.
Другим примером того, почему JWS является удивительной идеей, является Blackberry MDS. Приложения Blackberry на самом деле являются приложениями Java, переведенными с Javascript. В студии BB MDS вы используете инструмент GUI для создания GUI приложения BB, кодируя логику GUI в Javascript. Затем приложения переводятся и развертываются на сервере BES. Затем сервер BES распространит эти приложения на BB. На каждом BB он запускает тонкое Java-приложение только с графическим интерфейсом и сетевыми возможностями Всякий раз, когда приложению требуются данные, оно связывается с BES через веб-сервисы, чтобы использовать сервисы с других серверов. Разве это не просто версия JWS BB? Это было чрезвычайно успешно.
Наконец, я думаю, что JWS не популярен из-за того, как Sun его рекламирует. BB никогда не рекламирует, насколько хороши их Java-приложения BB, они верят, что клиентам будет все равно, что это такое. BB рекламирует преимущества использования MDS для разработки приложений: быстрая, экономичная, окупаемая.
Только мои, немного длинные, 2 цента ...:)