Java Web Start - популярность

Недавно я использовал приложение Java Web Start. Я запустил его из своего веб-браузера, используя встроенную ссылку jnlp на странице, которую я просматривал. Приложение было загружено, запущено и проработано отлично. Он имел доступ к моей локальной файловой системе и помнил мои настройки между перезагрузкой.

Что я хочу знать, почему приложения Java Web Start не являются более популярным форматом доставки для сложных приложений в Интернете? Почему разработчики часто тратят значительное время и энергию на повторное использование функций рабочего стола в html/javascript, когда мощь настольного приложения может быть проще с помощью Java и Java Web Start?

Я знаю, что в некоторых корпоративных средах, например, в банковской сфере, они являются относительно популярными способами доставки сложных торговых приложений клиентам, но почему они не распространяются по всей сети в целом?

(Для обсуждения позвольте предположить мир, в котором: источники загрузки "доверены", а приложения "подписаны" (то есть без проблем безопасности), скорости загрузки бывают быстрыми (время загрузки выполняется быстро), а разработчики знают Java (в числа, которые они знают html/js/php)).

Ответ 1

Я думаю, что причиной этого является не безопасность и время запуска приложения. Дайте понять, что за сценой, прежде чем мы выясним основную причину.

Панель управления 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) и выполнялись быстрее (наверняка, поскольку клиентские компьютеры визуализуют GUI без перевода, например, HTML/Javascript/CSS и меньше обработки данных).

После всего этого я еще не затронул вопрос, почему JWS не так знаменит?

Мое мнение таково, что это то же самое, что комментарий Брайана Кноблауха, без осознания.

ИТ-специалистов слишком привлекает шумиха Web Technologies, Ajax PUSH, GWT, и все эти звуковые слова делают их предвзятыми в отношении использования различных технологий или решения технических проблем вместо того, что действительно работает для клиентов.

Взгляните на Citrix. Я думаю, что Citrix - отличная идея. Citrix позволяет создавать собственные фермы приложений за сценой. Существует множество стратегий обновления и реализации, которые вы можете использовать без влияния на опыт клиентов. Внедрение Citrix чрезвычайно просто, стабильно и безопасно. Предприятия все еще используют его. Тем не менее, я думаю, что JWS даже лучше, чем Citrix. Идея JWS заключается в том, чтобы запускать приложения на клиентских компьютерах вместо того, чтобы размещать множество серверных ферм, где клиентские компьютеры могут самостоятельно запускать эти приложения. Это экономит компании много денег! С JWS команда разработчиков все еще может создавать бизнес-логику и данные на стороне сервера. Тем не менее, без блока обработки веб-страниц и позволить клиентским компьютерам выполнять процесс рендеринга, это значительно сокращает объем сетевого потребления и мощности обработки сервера.

Другим примером того, почему JWS является удивительная идея, является Blackberry MDS. Приложения Blackberry на самом деле являются приложениями Java, переведенными с Javascript. С студией BB MDS вы используете инструмент GUI для создания графического интерфейса приложения BB, кодирования GUI-логики в Javascript. Затем приложения затем переводятся и развертываются на сервере BES. Затем сервер BES будет распространять эти приложения на BB. На каждом BB он запускает тонкое приложение Java с графическим интерфейсом и сетевыми возможностями. Всякий раз, когда приложение требует данных, оно связывается с BES через веб-службы, чтобы потреблять услуги с других серверов. Разве это не просто версия JWS BB? Это было чрезвычайно успешно.

Наконец, я думаю, что JWS не пользуется популярностью из-за того, как Sun рекламирует его. BB никогда не рекламирует, насколько хороши их BB Java-приложения, они полагают, что клиентам даже не все равно, что это такое. BB рекламирует преимущества использования MDS для разработки приложений: быстрое, экономия затрат, возврат бизнеса.

Просто мой, немного длинный, 2 цента...:)

Ответ 2

Основным препятствием для Java Webstart, вероятно, является то, что вам все еще нужно установить JVM, прежде чем он сможет даже попытаться загрузить и запустить приложение. У каждого есть браузер. Не у всех есть JVM.

Edit: С тех пор я приобрел некоторый практический опыт веб-старта и теперь могу добавить эти две точки:

Deployment Toolkit script и модульная JVM, выпущенная где-то вокруг Java 1.6u10, делает требование JVM менее проблематичным, поскольку оно может автоматически загружать JVM и ядром API и запустите загрузку программы, оставив остальные.
Веб-старт серьезно глючит. Даже среди выпусков Java 1.6 был один, который загружал все приложение каждый раз, а другой, который загружал его, а затем не смог с неясным сообщением об ошибке. В общем, я не могу рекомендовать полагаться на такую хрупкую систему.

Ответ 3

Я думаю, что это в основном из-за недостаточной осведомленности. Он работает очень хорошо. Довольно бесшовные. Приложение загружается только в том случае, если оно было в первый раз, было обновление или если конечный пользователь очистил кеш. Отличный способ развертывания полнофункциональных настольных приложений, которые пользователю не придется беспокоиться о ручном обновлении!

Ответ 4

Проблема с Webstart заключается в том, что вам действительно нужно "запускать" что-то, что совсем не так быстро, даже при быстром подключении, в то время как с webapp вы вводите URL-адрес, и приложение есть.

Также многое может пойти не так с веб-стартом. Возможно, у предполагаемого пользователя нет необходимых привилегий, или прокси-сервер веб-страницы настроен неправильно, или что-то пошло не так с jre-зависимостями, или просто нет java, установленного в первую очередь. Так что для среднего Джона Доу в Интернете это совсем не приятно.

В контролируемых средах, таких как компания, во многих случаях это хорошее и простое решение.

Ответ 5

Я работал над развернутым JWS-приложением в течение нескольких лет над пользовательской базой в несколько тысяч, и его автоматическое обновление на самом деле является огромной болью.

При каждом обновлении по какой-то причине десятки пользователей получают "застряли посередине". Все, что вы получаете, это исключение "class not found" (если вам повезло) или неинформативный "не удалось запустить" из JWS, прежде чем он даже попадет в ваш код. Похоже, что обновление частично загружено. Или, другими словами, он не загружает и не применяет обновление атомарно И имеет плохое кэширование, так что перезапуск приложения с одного и того же URL-адреса ничего не исправляет.

Невозможно разрешить его, кроме очистки кеша JWS или предоставления другого URL-адреса (например, append ?dummyparam=jwssucks в конце). Даже я как разработчик иногда сталкивался с ним и не видел пути.

Когда он работает, он работает. Но слишком часто это не так, и тогда это огромная боль для вас и вашей службы поддержки. Я бы не рекомендовал его для корпоративного или критически важного использования.

Ответ 6

Существует очень большая проблема, которая заключается в том, что она не позволяет "мгновенно запускать программу и ТОГДА проверять и загружать любые обновления в фоновом режиме", к чему стремится поведение дефакторов приложений.

Я считаю это настолько большим досадой, что мы активно ищем другую технологию, которая обеспечивает это.

Ответ 7

Из этих сообщений это выглядит, когда вы используете Web start, важно заботиться о сервере. "Огромная боль" загрузки приложения при каждом запуске может быть вызвана неправильной меткой времени, доставленной с сервера. Здесь не приложение, а сервер, должно быть настроено правильно использовать кеширование, а не только для его отключения. О багги-старте, я не настолько уверен, но мне кажется, что это также может быть вызвано ненадежной связью.

Важным преимуществом веб-запуска является то, что он отлично работает с OpenJDK под Linux. Клиенты некоторых счастливых разработчиков используют только Windows, но мои клиенты этого не делают.

HTML и JavaScript, упомянутые в первоначальном вопросе, являются более легкими подходами, которые отлично работают с меньшими задачами, такими как анимированные кнопки или даже интерактивные таблицы. Java-ниша кажется гораздо более сложными задачами.

Ответ 8

Java Web Start является добрым преемником Java-апплетов, а апплеты сжигаются вокруг нового тысячелетия. Но я все еще считаю, что Java-апплеты лучше, чем GWT или Javascript.

Java Web Start vs Embedded Java Applet