Между толстым нативным клиентом и веб-приложением
Компании-разработчики корпоративного ПО, в том числе на рынке ECM, вынуждены выбирать между разными вариантами клиентов своих систем. Их выбор определяют требуемая производительность и функциональность, ожидания конечных пользователей и удобство приложений, даже стоимость и окупаемость разработки.
Некоторые системы (например, Docsvision, «Дело») имеют десктоп-клиент в качестве основного пользовательского. Другие («Тезис», ELMA) работают через веб-интерфейс. Для таких систем, как DIRECTUM и «1С:Документооборот», характерно наличие функциональных, более или менее равноценных десктоп- и веб-приложений.
Данная статья — рассуждение на тему того, какой же может быть золотая середина между толстым нативным клиентом и веб-приложением. Для начала определим основные понятия, встречающиеся в тексте.
Ключевые используемые определения
Нативный клиент — приложение, разработанное специально под конкретную операционную систему, позволяющее использовать максимум программных и аппаратных возможностей ОС и устройства. Десктоп-клиент — нативный клиент для настольного компьютера.
Веб-приложение — приложение, в котором клиентом выступает браузер, а сервером — веб-сервер. Как правило, в секторе корпоративного ПО веб-приложения насыщены функциональностью нативных приложений, которая реализована либо за счет уникальной специфики браузера, либо через плагин, либо в специально выделенной среде безопасности (песочнице).
Толстый клиент — клиент, на котором исполняется часть бизнес-логики, а сервер может выполнять только роль хранилища данных; толстый клиент отличается расширенной функциональностью и возможностью работать даже при обрыве связи с сервером.
Тонкий клиент — клиент, который переносит всю или большую часть задач по обработке информации на сервер.
Классические нативные десктоп-клиенты
Корпоративным системам, устанавливаемым на локальных мощностях заказчиков, изначально были свойственны десктоп-клиенты. Причем зачастую десктоп-клиент является толстым, на нем лежит часть исполнения бизнес-логики приложения. Данный вариант предполагает ряд преимуществ:
- пользователи работают в привычном интерфейсе, свойственном конкретной оболочке операционной системы;
- приложение легко интегрируется с прочими нативными приложениями и системным программным обеспечением. Для корпоративных систем важна интеграция с офисным пакетом, почтовыми клиентами, мессенджерами и т.д., может быть востребован доступ к микрофону, камере, прочим периферийным устройствам;
- кроме того, толстые клиенты снимают часть нагрузки с серверов и со слоя бизнес-логики (при его наличии).
И ряд недостатков:
- жесткая привязка приложения к операционной системе, отсутствие кроссплатформенности;
- трудности, связанные с локальной установкой, а также с обновлением клиента;
- сложность с предоставлением удаленного доступа к данным.
Альтернативой нативному клиенту является веб-приложение.
Плюсы и минусы веб-приложений
Веб-приложения — кроссплатформенные клиенты по определению. Пользователю достаточно иметь устройство с установленным браузером, чтобы начать работать в корпоративной системе. В этом заключается основное преимущество по сравнению с нативными клиентами.
При этом, попадая в систему с разных устройств, пользователь будет видеть одинаковый (или практически одинаковый) интерфейс, что облегчит освоение приложения. Естественно, работа через веб-приложение не предполагает дополнительной установки, по крайней мере до тех пор, пока возможности браузера не становятся ограничением для развития интерфейса, функциональности приложения или интеграции с другими приложениями и системами.
Для преодоления этого ограничения приходится либо использовать возможности дополнительных платформ, либо устанавливать плагины и агенты (как минимум в песочницу браузера). Появляется возможность реализовывать практически полностью идентичный десктопному UI-функционал (в частности drag-and-drop, вывод контекстного меню по клику правой кнопки мыши и т.д.). Часть вычислений может выполняться на машине пользователя без отправки на сервер, и в целом лучше балансируется нагрузка на ресурсы клиента и сервера. Движок клиента может взаимодействовать с сервером, не дожидаясь действий пользователя (к примеру, обновлять список входящих в режиме реального времени).
За плюсы веб-приложений приходится платить следующими ограничениями:
- ввиду унификации приложение в большей или меньшей степени инородно на любой платформе;
- скрипты и движок приложения должны загружаться в рабочие папки браузера при подключении, что замедляет работу с системой;
- при запуске скрипта на стороне клиента теряется производительность;
- разворачивание клиента в песочнице браузера приводит к ограничениям использования системных ресурсов и устройств; могут возникнуть сложности с интеграцией с МФУ, сканерами, сторонним софтом для редактирования документов разных форматов и т.д.
Нативный тонкий, но «богатый» клиент
Решить эти вопросы получается, пустив приложение обратно в среду операционной системы, то есть фактически сделав его нативным, установив локально (возможно, по технологии ClickOnce для упрощения обновления и снятия такого ограничения, как наличие администраторских прав). Таким образом обеспечатся и легкость с точки зрения настройки и адаптации, и тонкость с точки зрения отсутствия бизнес-логики на клиенте, и расширенная функциональность.
Существенно упростится настройка клиента с точки зрения пользовательского интерфейса, интеграции и взаимодействия с устройствами и другим ПО.
Источники изображений: rx.directum.ru, www.teachucomp.com
Появится больше возможностей для прикладной разработки, в том числе силами собственных специалистов. Бизнес-логика может остаться на стороне сервера, что облегчит клиент, распределив нагрузку между клиентом и сервером, а, следовательно, позволит экономить на железе.
В итоге имеем нативный тонкий, но «богатый» клиент, работающий через интернет, прекрасно применимый в том числе для подключения пользователей к облачным решениям, как правило, предоставляемым по SaaS-модели. Клиент обеспечивает высокий уровень мобильности и возможность организации как удаленной, так и территориально распределенной работы. Легкость установки и обновления клиента усилит преимущества SaaS, так как администрирование даже на уровне пользователя сведется к минимуму.
Нативный тонкий, но «богатый» клиент можно признать искомой золотой серединой, таким пользовательским приложением, которое вобрало в себя качества и классического десктоп-, и веб-приложения. В качестве примера реализации подобного клиента можно привести облачное решение DirectumRX.
Такие полнофункциональные клиенты в идеале нужны для всех основных операционных систем, в которых работают пользователи системы, а для остальных ОС достаточно иметь более или менее функциональное веб-приложение. Нужен не один клиент, а несколько, подобранных с пониманием бизнес-задач конкретного заказчика ECM. В этом случае корпоративная система окажется удобной и доступной всем сотрудникам, нуждающимся в доступе к корпоративному контенту в любое время, с любого устройства и в любом месте.
От браузера к ОС: что такое Native Client и чем он может быть полезен?
Отметив в начале августа 20-летний юбилей, браузеры почти сразу перешагнули и ещё одну важную ступеньку: на прошлой неделе в бета-версии Google Chrome 14 был включён экспериментальный компонент Native Client (NaCl). Мне повезло рассказывать об этом уникальном проекте с самых первых его дней (см. Компьютерра #763) — и тем приятней констатировать сейчас, что цель, которую ставили перед собой авторы, в общем достигнута.
Чего не хватает веб-браузерам, не считая утопической стопроцентной совместимости? Увы, скоростей. Даже с учётом всех мыслимых инноваций и модификаций последних лет — революционных Javascript-движков, использования GPU, предварительного рендеринга страниц, новых протоколов (слышали про SPDY?) и прочего подобного — скорость исполнения веб-приложений на порядки медленней той, что обеспечивает любая нативная программа, выполняемая непосредственно микропроцессором. Вот здесь-то и вступает в игру NaCl.
Проект, ведомый уже три года по инициативе и под крылом Google, позволяет веб-программистам писать такие приложения, которые будут исполняться внутри браузера со скоростью, лишь слегка уступающей скорости программ в машинных кодах, но сохранят переносимость, присущую веб-приложениям.
Фокус объясняется просто: Native Client — это «песочница», внутри которой работают программы, написанные на C/C++ и других классических языках, компилируемых непосредственно в машинный код. Но замкнутые в своём участке памяти, NaCl-приложения общаются с внешним миром только через программный интерфейс, связывающий их с Javascript-движком браузера. Поэтому не имеет значения, в какой операционной системе идёт работа, важно лишь для какого процессора они скомпилированы (сейчас NaCl-программы могут быть в инструкциях x86 и ARM).
Поскольку речь идёт об исполнении непроверенного машинного кода, полученного извне, вопрос обеспечения безопасности выходит на первый план. Можно ли гарантировать, что NaCl-программа не навредит системе, где она исполняется (почистив жёсткий диск, украв ценную информацию и пр.)? Авторы уверены, что это возможно.
Native Client формирует три степени защиты. Во-первых, перед исполнением код подвергается анализу на предмет выявления потенциально опасных последовательностей. Во-вторых, программа изолирована от других приложений аппаратно, средствами микропроцессора. В-третьих, связь с окружающим пространством организована с помощью Javascript, а значит и воспользоваться NaCl сможет только теми ресурсами, которые доступны Javascript-программам. Наконец, исходные тексты опубликованы под свободной лицензией, что само по себе добавляет уверенности.
Native Client ценен не только собственными уникальными свойствами, но и наличием открытого, оформившегося API (Pepper), посредством которого он увязывается с элементами HTML5. Возможность гибко, стандартным образом вписать NaCl-программы в существующую веб-архитектуру, предположительно, даст толчок лавинообразному росту числа таких приложений. А простота переноса существующих наработок в среду Native Client (особенно легко портируются линуксовые программы, а системные библиотеки даже не требуют изменений в коде) позволит не изобретать велосипед.
Важность текущего момента в том, что эксперименты завершены и начата практическая стадия. Native Client незримо присутствует в Chrome уже на протяжении нескольких версий — в виде тестовой опции, активировать которую необходимо вручную. Начиная с версии 14, стабильный релиз которой ожидается в сентябре, NaCl-среда будет активирована по умолчанию, что сразу же расширит список её пользователей с узкого круга разработчиков до минимум нескольких миллионов рядовых сетян (Chrome сейчас третий по популярности браузер в мире).
Какими будут NaCl-программы? Теоретически, на их плечи лучше всего взвалить обязанности, для которых требуется обработка больших объёмов данных в кратчайшее время. Вот почему ожидается, что основными областями применения будут мультимедийные функции браузеров и игры (к примеру, Google реализовала так встроенный в Chrome PDF-вьюер).
Однако по факту самым востребованным свойством Native Client стала его независимость от операционных систем. NaCl-программа без модификаций и настройки работает в MS Windows, Mac OS X, Linux и Chrome OS. Правда, список приложений пока невелик (см. официальный сайт), но уже есть интересные сторонние разработки (например, NaClBox, позволяющий запускать DOS-игры в браузере).
Ближайшее будущее Native Client связывается с двумя тенденциями. Первую должны сформировать разработчики прикладного софта, которые с помощью NaCl могут сравнительно легко переносить имеющиеся наработки в Сеть и таким образом наделять их кроссплатформенностью. Подать пример собирается лично Google, где надеются со временем превратить сам браузер Chrome в приложение NaCl (а значит и уменьшить хлопоты по адаптации к разным ОС, и усилить защиту, поскольку браузер будет работать в закрытой «песочнице»).
Другую тенденцию сформируют пользователи, требуя поддержки NaCl-приложений в браузерах, конкурирующих с Chrome. Поскольку исходники открыты, ничто кроме идеологических соображений не должно помешать проникновению Native Client в Firefox, Safari, Opera и Internet Explorer. Ожидается, что это произойдёт с участием создателей браузеров или без них (при помощи плагинов).
Наконец, в отдалённой перспективе Native Client может сыграть важную роль в становлении облачной Chrome OS — где отныне возможен запуск приложений, едва ли хоть в чём-то уступающих программам для классических операционных систем. И здесь скрыт самый жирный плюс этой оригинальной разработки. Да, сторонники Native Client, безусловно, большие оптимисты. И верить им или нет, решать вам. Но в любом случае новинку стоит оценить лично. Ведь если ожидания оправдаются, резко и необратимо изменятся не только браузеры, но и весь мир вычислительной техники: браузеры станут полным эквивалентом операционных систем и фундаментом для обновлённой софтверной индустрии.
От браузера к ОС: что такое Native Client и чем он может быть полезен?
Отметив в начале августа 20-летний юбилей, браузеры почти сразу перешагнули и ещё одну важную ступеньку: на прошлой неделе в бета-версии Google Chrome 14 был включён экспериментальный компонент Native Client (NaCl). Мне повезло рассказывать об этом уникальном проекте с самых первых его дней (см. Компьютерра #763) — и тем приятней констатировать сейчас, что цель, которую ставили перед собой авторы, в общем достигнута.
Чего не хватает веб-браузерам, не считая утопической стопроцентной совместимости? Увы, скоростей. Даже с учётом всех мыслимых инноваций и модификаций последних лет — революционных Javascript-движков, использования GPU, предварительного рендеринга страниц, новых протоколов (слышали про SPDY?) и прочего подобного — скорость исполнения веб-приложений на порядки медленней той, что обеспечивает любая нативная программа, выполняемая непосредственно микропроцессором. Вот здесь-то и вступает в игру NaCl.
Проект, ведомый уже три года по инициативе и под крылом Google, позволяет веб-программистам писать такие приложения, которые будут исполняться внутри браузера со скоростью, лишь слегка уступающей скорости программ в машинных кодах, но сохранят переносимость, присущую веб-приложениям.
Фокус объясняется просто: Native Client — это «песочница», внутри которой работают программы, написанные на C/C++ и других классических языках, компилируемых непосредственно в машинный код. Но замкнутые в своём участке памяти, NaCl-приложения общаются с внешним миром только через программный интерфейс, связывающий их с Javascript-движком браузера. Поэтому не имеет значения, в какой операционной системе идёт работа, важно лишь для какого процессора они скомпилированы (сейчас NaCl-программы могут быть в инструкциях x86 и ARM).
Native Client часто сравнивают с ActiveX, ставшей настоящим кошмаром IT. Но тот, кто знаком с новым проектом не понаслышке, утверждают, что правильной аналогией будет не ActiveX или Java, а скорее VMware в браузере: для NaCl нет нужды писать новые приложения — можно адаптировать уже существующие!
Поскольку речь идёт об исполнении непроверенного машинного кода, полученного извне, вопрос обеспечения безопасности выходит на первый план. Можно ли гарантировать, что NaCl-программа не навредит системе, где она исполняется (почистив жёсткий диск, украв ценную информацию и пр.)? Авторы уверены, что это возможно.
Native Client формирует три степени защиты. Во-первых, перед исполнением код подвергается анализу на предмет выявления потенциально опасных последовательностей. Во-вторых, программа изолирована от других приложений аппаратно, средствами микропроцессора. В-третьих, связь с окружающим пространством организована с помощью Javascript, а значит и воспользоваться NaCl сможет только теми ресурсами, которые доступны Javascript-программам. Наконец, исходные тексты опубликованы под свободной лицензией, что само по себе добавляет уверенности.
Native Client ценен не только собственными уникальными свойствами, но и наличием открытого, оформившегося API (Pepper), посредством которого он увязывается с элементами HTML5. Возможность гибко, стандартным образом вписать NaCl-программы в существующую веб-архитектуру, предположительно, даст толчок лавинообразному росту числа таких приложений. А простота переноса существующих наработок в среду Native Client (особенно легко портируются линуксовые программы, а системные библиотеки даже не требуют изменений в коде) позволит не изобретать велосипед.
Важность текущего момента в том, что эксперименты завершены и начата практическая стадия. Native Client незримо присутствует в Chrome уже на протяжении нескольких версий — в виде тестовой опции, активировать которую необходимо вручную. Начиная с версии 14, стабильный релиз которой ожидается в сентябре, NaCl-среда будет активирована по умолчанию, что сразу же расширит список её пользователей с узкого круга разработчиков до минимум нескольких миллионов рядовых сетян (Chrome сейчас третий по популярности браузер в мире).
Помимо прочего, Native Client стал ещё и бесспорно уникальной функцией браузера Chrome. В условиях жесточайшей конкуренции, когда наткнуться на оригинальную идею — счастье, этот факт трудно переоценить
Какими будут NaCl-программы? Теоретически, на их плечи лучше всего взвалить обязанности, для которых требуется обработка больших объёмов данных в кратчайшее время. Вот почему ожидается, что основными областями применения будут мультимедийные функции браузеров и игры (к примеру, Google реализовала так встроенный в Chrome PDF-вьюер).
Однако по факту самым востребованным свойством Native Client стала его независимость от операционных систем. NaCl-программа без модификаций и настройки работает в MS Windows, Mac OS X, Linux и Chrome OS. Правда, список приложений пока невелик (см. официальный сайт), но уже есть интересные сторонние разработки (например, NaClBox, позволяющий запускать DOS-игры в браузере).
Ближайшее будущее Native Client связывается с двумя тенденциями. Первую должны сформировать разработчики прикладного софта, которые с помощью NaCl могут сравнительно легко переносить имеющиеся наработки в Сеть и таким образом наделять их кроссплатформенностью. Подать пример собирается лично Google, где надеются со временем превратить сам браузер Chrome в приложение NaCl (а значит и уменьшить хлопоты по адаптации к разным ОС, и усилить защиту, поскольку браузер будет работать в закрытой «песочнице»).
Другую тенденцию сформируют пользователи, требуя поддержки NaCl-приложений в браузерах, конкурирующих с Chrome. Поскольку исходники открыты, ничто кроме идеологических соображений не должно помешать проникновению Native Client в Firefox, Safari, Opera и Internet Explorer. Ожидается, что это произойдёт с участием создателей браузеров или без них (при помощи плагинов).
Наконец, в отдалённой перспективе Native Client может сыграть важную роль в становлении облачной Chrome OS — где отныне возможен запуск приложений, едва ли хоть в чём-то уступающих программам для классических операционных систем. И здесь скрыт самый жирный плюс этой оригинальной разработки. Да, сторонники Native Client, безусловно, большие оптимисты. И верить им или нет, решать вам. Но в любом случае новинку стоит оценить лично. Ведь если ожидания оправдаются, резко и необратимо изменятся не только браузеры, но и весь мир вычислительной техники: браузеры станут полным эквивалентом операционных систем и фундаментом для обновлённой софтверной индустрии
Между толстым нативным клиентом и веб-приложением
Компании-разработчики корпоративного ПО, в том числе на рынке ECM, вынуждены выбирать между разными вариантами клиентов своих систем. Данная статья — рассуждение на тему, какой может быть золотая середина между толстым нативным клиентом и веб-приложением.
Компании-разработчики корпоративного ПО, в том числе на рынке ECM, вынуждены выбирать между разными вариантами клиентов своих систем. Их выбор определяют требуемая производительность и функциональность, ожидания конечных пользователей и удобство приложений, даже стоимость и окупаемость разработки.
Некоторые системы (например, Docsvision, «Дело») имеют десктоп-клиент в качестве основного пользовательского. Другие («Тезис», ELMA) работают через веб-интерфейс. Для таких систем, как DIRECTUM и «1С:Документооборот», характерно наличие функциональных, более или менее равноценных десктоп- и веб-приложений.
Данная статья — рассуждение на тему того, какой же может быть золотая середина между толстым нативным клиентом и веб-приложением. Для начала определим основные понятия, встречающиеся в тексте.
Ключевые используемые определения
Нативный клиент — приложение, разработанное специально под конкретную операционную систему, позволяющее использовать максимум программных и аппаратных возможностей ОС и устройства. Десктоп-клиент — нативный клиент для настольного компьютера.
Веб-приложение — приложение, в котором клиентом выступает браузер, а сервером — веб-сервер. Как правило, в секторе корпоративного ПО веб-приложения насыщены функциональностью нативных приложений, которая реализована либо за счет уникальной специфики браузера, либо через плагин, либо в специально выделенной среде безопасности (песочнице).
Толстый клиент — клиент, на котором исполняется часть бизнес-логики, а сервер может выполнять только роль хранилища данных; толстый клиент отличается расширенной функциональностью и возможностью работать даже при обрыве связи с сервером.
Тонкий клиент — клиент, который переносит всю или большую часть задач по обработке информации на сервер.
Классические нативные десктоп-клиенты
Корпоративным системам, устанавливаемым на локальных мощностях заказчиков, изначально были свойственны десктоп-клиенты. Причем зачастую десктоп-клиент является толстым, на нем лежит часть исполнения бизнес-логики приложения. Данный вариант предполагает ряд преимуществ:
● пользователи работают в привычном интерфейсе, свойственном конкретной оболочке операционной системы;
Источники изображений: directum.ru, pixshark.com
● приложение легко интегрируется с прочими нативными приложениями и системным программным обеспечением. Для корпоративных систем важна интеграция с офисным пакетом, почтовыми клиентами, мессенджерами и т.д., может быть востребован доступ к микрофону, камере, прочим периферийным устройствам;
● кроме того, толстые клиенты снимают часть нагрузки с серверов и со слоя бизнес-логики (при его наличии).
И ряд недостатков:
● жесткая привязка приложения к операционной системе, отсутствие кроссплатформенности;
● трудности, связанные с локальной установкой, а также с обновлением клиента;
● сложность с предоставлением удаленного доступа к данным.
Альтернативой нативному клиенту является веб-приложение.
Плюсы и минусы веб-приложений
Веб-приложения — кроссплатформенные клиенты по определению. Пользователю достаточно иметь устройство с установленным браузером, чтобы начать работать в корпоративной системе. В этом заключается основное преимущество по сравнению с нативными клиентами.
При этом, попадая в систему с разных устройств, пользователь будет видеть одинаковый (или практически одинаковый) интерфейс, что облегчит освоение приложения. Естественно, работа через веб-приложение не предполагает дополнительной установки, по крайней мере до тех пор, пока возможности браузера не становятся ограничением для развития интерфейса, функциональности приложения или интеграции с другими приложениями и системами.
Для преодоления этого ограничения приходится либо использовать возможности дополнительных платформ, либо устанавливать плагины и агенты (как минимум в песочницу браузера). Появляется возможность реализовывать практически полностью идентичный десктопному UI-функционал (в частности drag-and-drop, вывод контекстного меню по клику правой кнопки мыши и т.д.). Часть вычислений может выполняться на машине пользователя без отправки на сервер, и в целом лучше балансируется нагрузка на ресурсы клиента и сервера. Движок клиента может взаимодействовать с сервером, не дожидаясь действий пользователя (к примеру, обновлять список входящих в режиме реального времени).
За плюсы веб-приложений приходится платить следующими ограничениями:
● ввиду унификации приложение в большей или меньшей степени инородно на любой платформе;
● скрипты и движок приложения должны загружаться в рабочие папки браузера при подключении, что замедляет работу с системой;
● при запуске скрипта на стороне клиента теряется производительность;
● разворачивание клиента в песочнице браузера приводит к ограничениям использования системных ресурсов и устройств; могут возникнуть сложности с интеграцией с МФУ, сканерами, сторонним софтом для редактирования документов разных форматов и т.д.
Нативный тонкий, но «богатый» клиент
Решить эти вопросы получается, пустив приложение обратно в среду операционной системы, то есть фактически сделав его нативным, установив локально (возможно, по технологии ClickOnce для упрощения обновления и снятия такого ограничения, как наличие администраторских прав). Таким образом обеспечатся и легкость с точки зрения настройки и адаптации, и тонкость с точки зрения отсутствия бизнес-логики на клиенте, и расширенная функциональность.
Существенно упростится настройка клиента с точки зрения пользовательского интерфейса, интеграции и взаимодействия с устройствами и другим ПО.
Источники изображений: rx.directum.ru, www.teachucomp.com
Появится больше возможностей для прикладной разработки, в том числе силами собственных специалистов. Бизнес-логика может остаться на стороне сервера, что облегчит клиент, распределив нагрузку между клиентом и сервером, а, следовательно, позволит экономить на железе.
В итоге имеем нативный тонкий, но «богатый» клиент, работающий через интернет, прекрасно применимый в том числе для подключения пользователей к облачным решениям, как правило, предоставляемым по SaaS-модели. Клиент обеспечивает высокий уровень мобильности и возможность организации как удаленной, так и территориально распределенной работы. Легкость установки и обновления клиента усилит преимущества SaaS, так как администрирование даже на уровне пользователя сведется к минимуму.
Нативный тонкий, но «богатый» клиент можно признать искомой золотой серединой, таким пользовательским приложением, которое вобрало в себя качества и классического десктоп-, и веб-приложения. В качестве примера реализации подобного клиента можно привести облачное решение DirectumRX.
Такие полнофункциональные клиенты в идеале нужны для всех основных операционных систем, в которых работают пользователи системы, а для остальных ОС достаточно иметь более или менее функциональное веб-приложение. Нужен не один клиент, а несколько, подобранных с пониманием бизнес-задач конкретного заказчика ECM. В этом случае корпоративная система окажется удобной и доступной всем сотрудникам, нуждающимся в доступе к корпоративному контенту в любое время, с любого устройства и в любом месте.