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

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

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

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

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

источник

2009-02-19 Joel

Мне нравится идея, что нет никаких проблем с безопасностью подписанных приложений. –

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

Панель управления 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 в песочницах, подписка и гораздо более интерактивный графический интерфейс.

Другие преимущества включают в себя более быструю разработку (проще отлаживать код и производительность), реагировать на пользовательский интерфейс (не требует, чтобы серверы комет обеспечивали функциональность PUSH) и выполнялись быстрее (наверняка, поскольку клиентские компьютеры визуализуют графический интерфейс без перевода, 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 цента ... :)

источник

2009-08-17 05:14:33

Это чисто теоретический ответ. Несомненно, JWS отлично смотрится на бумаге, но это просто не готово к производству. –

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

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

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

источник

2009-02-19 12:02:18

Я вижу, что вы имеете в виду о «запуске», но учитывая, что мы предположили, что скорость загрузки была быстрой, как это вообще не отличается от «запуска» веб-страницы путем «нажатия» на ссылку? Это одно и то же, конечно, т. Е. Ссылка на странице. – Joel

Если обновление не было обновлено, оно запускается быстро во второй раз из-за кэширования. –

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

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

источник

2009-02-19 12:30:07

Я согласен, и я думаю, что если JNLP был создан ранее в истории Java, мы, вероятно, увидели бы более сильное присутствие Java на рабочем столе. – Thorn

С этого ответа я столкнулся с несколькими проблемами. Система кэширования JNLP имеет критический недостаток в дизайне. Если запущено 2 копии одного и того же приложения JNLP, и источник изменился между запуском 1-го и 2-го, результаты выполнения 1-го являются непредсказуемыми. Вместо того, чтобы загружать вторую копию и запускать ее, JNLP сбрасывает новую версию поверх старого и запускает вторую копию. Это ужасно ломает первый экземпляр. Следующая ошибка. Самоподписанные сертификаты теперь устарели. Прекрасно подходит для использования в Интернете, но на самом деле вредит разработчикам. –

Вы имеете в виду две копии с разными именами или две копии точно такой же кодовой базы с тем же именем, но с использованием разных браузеров? И да, вопиющие устаревающие самозанятые сертификаты, но для предприятия существует обход. Вы можете установить самозаверяющий сертификат как доверенный, а затем он должен функционировать так же, как и тот, который выдается «авторитетом». – Thorn

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

Edit: Я с тех пор приобрел некоторые практический опыт Webstart и теперь можно добавить эти две точки:

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

источник

2009-02-19 12:38:58

, но предположительно препятствие установки jre может быть сделано так же безболезненно, как установка flash или любого другого плагина браузера? – Joel

JRE по-прежнему намного больше, чем эти (Java6u10 представил меры, чтобы облегчить это), и он не поставляется с предустановленной Windows (что, как я считаю, Flash). –

Flash окончательно получил «запуск сразу». –

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

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

источник

2010-02-17 10:48:10

Это было бы неплохо дать человеку, который его развертывал. Тем не менее, я бы не сделал это полностью решением для конечных пользователей. Разработчику придется включить эту опцию, чтобы позволить использовать этот выбор. В моей конкретной среде нам нужно принудительно (без выбора пользователя) обновить во время запуска. –

Java Web Start имеет эту возможность. Поместите '' непосредственно перед вашим ''. – finnw

Похоже, что некоторые из новых функций появились с версией Java 6. Это тоже работает для главной банки. –

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

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

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

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

источник

2011-03-28 07:33:37

Какую версию Java вы использовали? – Raleigh

6 и обновлены. По-прежнему беспорядок на данный момент. –

Ничего себе, какая боль. Я этого не видел. Интересно, поможет ли установка проверки обновлений на «фон». Таким образом, он может загрузить последнюю версию во время текущей версии. – Thorn

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

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

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

источник

2011-09-06 07:14:24 audriusa

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

Java Web Start vs Embedded Java Applet

источник

2017-03-22 13:04:12 weberjn

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

ответ

Смежные вопросы