В настоящее время, веб-приложения, управляемые из браузера, по уровню производительности находятся на уровне настольных приложений, а в некоторых областях по функциональности и удобству использования опережают их. Однако остаются такие области, где вебприложение имеет ряд существенных недостатков относительно приложения, работающего на локальном компьютере. Одним из главных недостатков является отсутствие доступа к программным и аппартным средствам на локальном компьютере.
Это обуславливается защитной технологией браузера, которая называется песочницей1[1]. Данная технология накладывает серьезные ограничения на выполняемый программный код в браузере, в том числе и на доступ к программным и аппаратным средствам на локальном компьютере. На текущий момент существуют технологии, которые позволяют преодолеть данное ограничение. Примером может служить продукт компании Oracle Java applets[2]. Несмотря на возможность работы с любым браузером, данный продукт имеет ряд серьёзных недостатков, главными из которых являются необходимость установки дополнительного программного обеспечения, небезопасность и отсутствие поддерж- ки2. Таким образом, в настоящее время существует необходимость в оптимальном решении, удовлетворяющем требованиям безопасности, производительности и расширяемости.
Необходимо также упомянуть, что современные браузеры находятся на стадии развития и предлагают новые возможности для выполняемого кода. Однако эти возможности предоставляются только одним браузером, для другого браузера приходится искать новое решение. Например, разработчики браузера Chrome разработали технологию Native Messaging[3], предоставляющую API для общения браузерных приложений и расширений с приложениями на локальном компьютере. Данная технология способна решить проблему по обеспечению доступа к программным и аппаратным средствам на локальном компьютере. Однако данная технология не является стандартом, то есть она поддерживается только в браузерах Chrome. Другие популярные браузеры, такие как Opera или Mozilla Firefox, данное решение не поддерживают. Для таких браузеров необходимо искать альтернативный подход. Возможно, другие браузеры поддерживают свою технологию, позволяющую решить проблему по обеспечению доступа к программным и аппартным средствам на локальном компьютере.
Разумеется, можно разработать отдельную реализацию для отдельного браузера. Однако разработка решения под конкретный браузер сильно ограничивает возможности приложения и приводит к резкому повышению трудозатрат на разработку, отладку и выпуск приложения при увелечении поддерживаемых браузеров с собственной реализацией под каждый. Это делает продукт менее конкурентноспособным за счет повышения трудозатрат и увеличения длительности разработки. Поэтому для крупных компаний, которые создают сложные программные продукты, данное решение крайне невыгодно. Одной из таких компаний является Docsvision3, под руководством которой выполняется данная работа.
Таким образом, целесообразно разработать решение, которое позволит получить ранее сказанное преимущество веб-приложений и при этом устранит наиболее серьезные недостатки, такие как отсутствие доступа к аппаратным и программным средствам на локальном компьютере. Также установлено, что проблему необходимо решить с учетом обеспечения кроссбраузерности и кроссплатформенности, стремясь минимизировать трудозатраты на разработку и обеспечение программного продукта.
В ходе работы были достигнуты следующие результаты.
• Проведен обзор технологий HTML5, WebUSB, JavaApplets, Native Messaging. В результате обзора установлено, что ни одно из существующих решений не способно решить поставленную цель с учетом требования кроссбраузерности.
• Разработана архитектура прототипа. В ходе решения данной задачи были подробно разработаны основные компоненты архитектуры. Создан процесс их взаимодействия. Архитектура разрабатывалась с использованием самых актуальных и передовых на момент написания дипломной работы технологий - ReactJS, Redux, ASP.NET MVC5. Также разработка велась с учетом ограничений кроссплатформенности и расширяемости.
• Реализована архитектура прототипа с помощью таких технологий, как ASP.NET, Redux, ReactJS. При реализации разработанной архитектуры возникло немало проблем. Основными из которых были обеспечение взаимодействия технологий ReactJS и Redux, внедрение внешних зависимостей с целью разбиения компонент на независимые, хорошо тестируемые части.
• Проведено тестирование. В результате чего клиентское и серверное приложения полностью ’’покрыты” тестами, это позволяет вносить изменения или добавлять новую функциональность без риска, что ранее работающие функции окажутся неработоспособны. Успешно проведено ’ручное” тестирование.
