Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
PAGE \* MERGEFORMAT 23
Содержание
Введение
2.1 Описание
2.2Формальные правила
2.3 Расширение UML для WEB-приложений
2.4 Проектирование "тонкого" Web-клиента
Введение
С появлением высокопроизводительных серверов, сетевого оборудования и высокоскоростных каналов связи стала реальностью организация корпоративных вычислительных сетей. Корпоративные сети объединены во всемирную глобальную сеть -Internet. Одним из крупнейших достижений Internet стала "всемирная паутина" -WWW (World Wide Web или просто Web). WWW представляет собой множество независимых, но взаимосвязанных серверов.
Согласно RFC-html40-971218 – стандарту языка HTML 4.0 (RFC – Resource for Comments, так называются основные документы консорциума W3, специфицирующие технологии Internet), Web – это сеть информационных ресурсов, в которой для доступности этих ресурсов наиболее широкой аудитории используется три механизма:
- Единая схема именования ресурсов для поиска последних в Web - URI.
- Протокол для доступа к ресурсам через Web - HTTP.
- Гипертекст для перемещения по ресурсам - HTML.
Web-приложения возникли и приобрели популярность в начале 2000-х годов. Во многом это объясняется тем, что крупные компании развернули свой рынок в сети Интернет.
Архитектура Web-приложений наиболее близка к архитектуре централизованных вычислений, то есть существует множество распределенных «тонких» клиентов, предназначенных исключительно для отображения данных и серверы, которые хранят данные. «Тонкие» клиенты подключаются к серверам. Архитектура Web-приложений отличается от архитектуры централизованных вычислений тем, что Web-приложения работают на основе языка HTML и протокола HTTP .
Таким образом, любая информационная система, создаваемая как web-приложение, должна содержать следующие серверные компоненты:
-web-сервер;
- баз данных;
-сервер приложений и (или) сервер обработки транзакций.
1 Архитектурные шаблоны WEB-приложений
Архитектуры Web-приложений могут быть самыми различными. Не секрет, что на современном рынке существует большое количество технологий и программных продуктов, связанных с Internet. Когда Internet попала в поле зрения крупных корпораций, многие устремились занять свое место в этой области. Все, что можно было найти "на полке", либо модифицировалось, либо просто продавалось для использования в Web и Internet. В результате появился широкий спектр продуктов и технологий, которые могут быть частью архитектуры Web-приложений.
Web-приложения развивались на основе совершенствования и усложнения функций Web-узлов. Вообще, Web-приложение расширяет функции Web-узла, предоставляя его клиентам возможность использования бизнес-логики и, следовательно, изменения данных на сервере. Это определение Web-приложения указывает, что в нем, как минимум, имеется три важных архитектурных компонента: клиентский броузер, Web-сервер и сервер приложений. Зачастую Web-приложение использует также сервер баз данных.
Более строго Web-приложение можно определить как программную систему клиент/сервер, в состав которой, как минимум, входят следующие архитектурные компоненты: HTML/XML-броузер на одном или более клиентских компьютерах, взаимодействующих с Web-сервером по протоколу HTTP, и сервер приложений, который управляет бизнес-логикой. Из этого более строгого определения вовсе не следует, что в Web-приложении нельзя использовать распределенные объекты или аплеты Java, а также то, что Web-сервер и сервер приложений не могут размешаться на одном и том же компьютере. Эти распространенные технологии позволяют улучшить базовую архитектуру Web-приложения.
На достаточно высоком уровне абстракции можно выделить существующие в настоящее время архитектурные шаблоны Web-приложений. Архитектурный шаблон отражает фундаментальную структурно-организационную схему программных систем. Он предоставляет набор предопределенных подсистем, описывает спектр их обязанностей, а также представляет правила и рекомендации для организации взаимодействия между ними.
Рассмотрим три самых общих шаблона.
1. Thin Web Client (на основе "тонкого" Web-клиента) используется в большинстве приложений Internet и предоставляет ограниченные возможности по управлению конфигурацией клиента. В распоряжении клиента должен быть только стандартный броузер, поддерживающий формы. Все операции, связанные с бизнес-логикой, выполняются на сервере.
2. Thick Web Client (на основе "толстого" Web-клиента) предполагает, что значительная часть бизнес-логики выполняется на клиентской машине. Обычно для выполнения бизнес-логики клиентом используется динамический HTML, аплеты Java или управляющие элементы ActiveX. Взаимодействие с сервером по-прежнему происходит через протокол HTTP.
3. Web Delivery (на основе механизма Web-доставки). При взаимодействии клиента и сервера, кроме протокола HTTP, используются и другие протоколы, такие как IOOP и DCOM, которые могут применяться для поддержки системы распреде ленных объектов. В данном случае броузер функционирует как контейнерный модуль системы распределенных объектов.
Приведенный список нельзя считать исчерпывающим, особенно учитывая тот факт, что технологические революции происходят ежегодно. Он лишь представляет наиболее общие архитектурные шаблоны Web-приложений высокого уровня. Различнные шаблоны можно одновременно применять в одной архитектуре. Например, в системе электронной коммерции шаблон Thin Web Client может использоваться в прецеденте, связанном с продажей товаров потребителю, а шаблон Thick Web Client или Web Delivery можно применять для поддержки офиса филиала компании. Выбор такой архитектуры вполне оправдан, поскольку уровень управляемости конфигураций "собственного" клиента должен отличаться от тех случаев, когда информация собирается от пользователей Internet по всему миру.
Рассмотрим более подробно подробному рассмотрению каждый из этих архитектурных шаблонов, который может применяться в Web-приложении.
1.1 Шаблон Thin Web Client
Шаблон на основе "тонкого" Web-клиента полезно использовать в тех Web-приложениях, в которых можно гарантировать наличие только минимальной конфигурации клиента. При этом вся бизнес-логика выполняется на сервере, в процессе обработки запроса на получение страницы, сгенерированного броузером клиента.
Область применения
Этот шаблон больше всего подходит для Web-приложений или их окружения, когда клиент обладает минимальными вычислительными возможностями или не может управлять своей конфигурацией.
Примеры использования
Данный шаблон используется в большинстве Internet-приложений электронной коммерции, поскольку нет никакого смысла отказываться от покупателей только потому, что их клиентский компьютер не обладает достаточной вычислительной мощностью. Типичное приложение электронной коммерции предназначено для привлечения максимального количества покупателей.
Структура
Основные компоненты архитектуры на основе "тонкого" Web-клиента размещаются на сервере. В большинстве случаев — это минимальная архитектура Web-приложения. Ниже перечислены ее основные компоненты.
- Клиентский броузер (client browser) — любой стандартный броузер, поддерживающий формы HTML. Броузер функционирует как обобщенное устройство с интерфейсом пользователя. При использовании в архитектуре на основе "тонкого" Web-клиента такой броузер обеспечивает только одну дополнительную возможность: прием и возврат данных cookie. Пользователь приложения посредством броузера запрашивает Web-страницы – либо статические в формате HTML, либо динамические. На возвращаемой странице содержится полностью отформатированный пользовательский интерфейс — текст и управляющие элементы, которые отображаются броузером на экране клиентского компьютера. Взаимодействие пользователя с системой осуществляется через броузер.
- Web -сервер (Web server) — главная точка доступа для всех клиентских броузеров. В архитектуре Thick Web Client клиентские броузеры получают доступ к системе только через Web-сервер, который принимает запросы на получение Web-страниц — либо статических, либо динамических (формируемых на сервере). В зависимости от запроса Web-сервер может инициировать некоторые серверные процессы. Если запрос сгенерирован на получение серверной страницы со сценариями, модулями CGI, ISAPI или NSAPI, то Web-сервер передает эту страницу для обработки соответствующему интерпретатору сценариев или исполняемому модулю. В любом случае результатом этой обработки является отформатированная HTML-страница, которую можно отобразить в броузере, поддерживающем язык HTML.
- Соединение HTTP (HTTP connection) – стандартный протокол взаимодействия клиентских броузеров и Web-серверов. Этот архитектурный элемент представляет взаимодействие между клиентом и сервером без поддержки соединения. Каждый раз, когда клиент и сервер обмениваются информацией, устанавливается новое независимое соединение. Разновидностью соединения HTTP является безопасное HTTP-соединение с помощью протокола SSL (Secure Sockets Layer). При таком соединении данные, передаваемые между клиентом и сервером, шифруются с применением открытых/закрытых ключей.
- Страница HTML (HTML page) – Web-страница с интерфейсом пользователя и содержательной информацией, которая не обрабатывается сервером. Обычно такие страницы содержат пояснительный текст или HTML-форму для ввода данных. Когда Web-сервер получает запрос на страницу HTML, он просто извлекает требуемый файл и, не выполняя никакой фильтрации, передает его соответствующему клиенту.
- Серверная страница (Server page) — Web-страницы, которые каким-либо образом обрабатываются серверной частью приложения. Обычно такие страницы реализуются в виде страниц со сценариями (ASP, JSP, Cold Fusion), которые пропускаются через фильтр сервера приложения или исполняемого модуля (ISAPI или NSAPI). Эти страницы потенциально имеют доступ ко всем серверным ресурсам, включая бизнес-логику, базы данных и существующие системы.
- Сервер приложения (Application server) — основное средство для выполнения бизнес-логики в серверной части приложения. В обязанности сервера приложений входит выполнение кода серверных страниц. Сервер приложения может размешаться на одной машине с Web-сервером и выполняться в том же пространстве процесса, что и Web-сервер. Логически сервер приложения является отдельным архитектурным элементом, поскольку он имеет отношение лишь к бизнес-логике и для его реализации может использоваться технология, полностью отличающаяся от технологии Web-сервера.
Во многих Web-приложениях база данных используется для хранения коммерческой информации. В некоторых случаях база данных может использоваться также для хранения самих страниц, однако такое ее применение уже относится к другому архитектурному шаблону. Поскольку в Web-приложениях для постоянного хранения коммерческой информации могут использоваться самые разнообразные технологии, с соответствующим архитектурным компонентом связывается более общий термин хранилище (persistence). Этот компонент предполагает также возможность использования монитора обработки транзакций (Transaction Processing Monitor – ТРМ).
Простейший способ соединения системы с базой данных заключается в обеспечении для сценариев серверных страниц возможности прямого доступа к компоненту постоянного хранения данных. Эту обязанность, связанную с выполнением однообразных действий, можно возложить на стандартные библиотеки доступа к данным, такие как RDO (Remote Data Object), ADO (ActiveX Data Object), ODBC (Open Database Connectivity), JDBC (Java Database Connectivity) и DBLib. В этом случае серверным страницам должна быть известна структура базы данных. При использовании реляционных баз данных для получения доступа к информации потребуется конструировать и выполнять необходимые операторы SQL (Structured Query Language — структурированный язык запросов). Для малых Web-приложений этого может оказаться вполне достаточно. Однако для больших систем, к надежности которых предъявляются повышенные требования, более предпочтительно использовать отдельный уровень объектов логики приложения.
Рис. 1-Минимальная архитектура Thin Web Client
Компонент, содержащий объекты предметной области, инкапсулирует бизнес-логику. Обычно он компилируется и выполняется на сервере приложения. Одно из преимуществ создания такого отдельного компонента архитектуры заключается в том, что другая Web-система или Web-приложение для доступа к бизнес-логике могут использовать одни и те же компоненты. Например, в приложении электронной коммерции для обработки запросов всех потребителей можно использовать серверные страницы и архитектурный шаблон Thin Web Client, однако для отдела выписки счетов может понадобиться более изощренный доступ к данным и бизнес-логике. Для этого предпочтительнее использовать систему клиент/сервер, а не Web-систему. В подсистеме выписки счетов могут применяться компоненты одного и того же сервере приложения Web-системы, однако вместе с тем может использоваться более сложное клиентское программное обеспечение.
Поскольку реляционные базы данных являются наиболее распространенным их типом, применяемым в коммерческих приложениях, то между сервером приложения и базой данных, как правило, присутствует дополнительный архитектурный компонент. Этот компонент обеспечивает связь между объектами и реляционными базами данных. Он может реализовываться различными способами.
Проектирование серверных компонентов Web-приложения практически выполняется точно так же, как и при разработке любой другой системы клиент/сервер. Поскольку рассматриваемый шаблон предназначен для проектирования Web-приложений и их специфичных компонентов, подробное рассмотрение архитектуры серверной части выходит за рамки этого шаблона.
Основные принципы поведения
В основе поведения этого архитектурного шаблона лежит следующий принц бизнес-логика используется только в ответ на запрос Web-страницы клиентом. Клиент взаимодействует с системой, используя протокол HTTP для получения страниц с Web-сервера. Если запрашиваемая страница является файлом HTML файловой системы Web-сервера, то последний просто извлекает страницу и пересылает ее соответствующему клиенту.
Если страница содержит сценарий, т.е. интерпретируемый код, который доля быть обработан до отправки клиенту, то все необходимые для этого действия выполняются сервером приложения. Сервер приложения интерпретирует сценарии страницы и при необходимости обращается к серверным ресурсам, таким как базы данных, по чтовые службы, другие системы и т.д. Через сервер приложения и Web-сервер сценарий имеет доступ к специальной информации, содержащейся в запросе. В состав этих данных входят введенные пользователем значения полей формы и параметры, присоединенные к запросу. В результате создается корректно отформатированная HTML-страница, которую можно отправить обратно клиенту.
Страница может представлять собой исполняемый модуль, например динамическую библиотеку ISAPI или NSAPI. Динамически подключаемая библиотека (DLL) является скомпилированной, которая в процессе выполнения может загружаться и выполняться сервером приложения. Подобно странице со сценариями, модуль также имеет доступ к серверным ресурсам.
Ключевой аспект динамического поведения этого архитектурного шаблона заклю чается в том, что бизнес-логика используется только в процессе обработки запроса на страницу. После обработки запроса результат передается обратно клиенту, а соединение между клиентом и сервером разрывается. В некоторых случаях соединение может сохраняться, однако это скорее исключение, чем правило.
Эта архитектура наиболее подходит для приложений, сервер которых должен пере давать ответы в течение интервала времени, приемлемого для пользователя, а также до истечения интервала ожидания клиентского броузера. Обычно это время не превышает нескольких секунд. Применение шаблона Thin Web Client оказывается далеко не лучшим решением, если приложение должно обеспечивать возможность запуска пользователем продолжительного процесса. Для выполнения таких задач могут использоваться технологии, которые выполняют периодический опрос сервера.
Еще одной важной особенностью этого архитектурного шаблона являются ограни ченные возможности по созданию сложного интерфейса пользователя. Поскольку броузер предоставляет целостный интерфейс пользователя, все элементы управления должны им поддерживаться. В большинстве стандартных броузеров и в спецификации HTML множество доступных элементов управления ограничивается несколькими полями для ввода текста и кнопками. С другой стороны, упрощенный пользовательский интерфейс может оказаться и преимуществом, поскольку в этом случае команда разработчиков не сможет неоправданно его усложнить.
В данной работе мы не будем детально рассматривать два других шаблона, поскольку они предназначены для Web-приложений в изначальном смысле этого слова (например, Internet-магазин), а мы не ставим перед собой задачу разработки подобных приложений.
2 Спецификации расширения UML для WEB-приложений
2.1 Описание
В этом расширении языка UML определен набор стереотипов (stereotype), тегированных значений (tagged value) и ограничений (constraint), позволяющих моделировать Web-приложения. Стереотипы и ограничения применяются к определенным компонентам, характерным для Web-приложений, что позволяет представлять их в той же модели и на тех же диаграммах, которые описывают остальную часть системы.
Наиболее важными элементами Web-приложений являются Web-страницы. К ним могут применяться различные стереотипы. Кроме того, дополнительные стереотипы можно присваивать и другим элементам HTML, являющимся архитектурно значимы ми компонентами системы, например фреймам, целям и формам.
Многие тегированные значения, определенные в данном расширении, можно рас сматривать скорее как средство представления взаимосвязей модели, а не как струк турные элементы. Большое количество информации может ввести в заблуждение. На первый взгляд кажется, что от некоторых важных тегированных значений можно без проблем отказаться. Однако это не так. Более того, вполне возможно, что как только будут разработаны генераторы программного кода, к расширению будут добавлены дополнительные тегированные значения.
2.2 Формальные правила
Реализация компонентов. А общем случае компоненты Web Page могут реализовать классы-стереотипы <<Server Page>>, <<Client Page>>, <<Form>>, <<JavaScript Object>>, <<ClientScript Object>>, <<Frameset>> и <<Target>>. При использовании в процессе разработки специфических технологий, таких как ASP или JSP, Web-страницы не могут реализовывать классы-стереотипы <<Server Page>>.
Обобщение. Все моделируемые элементы в обобщении должны относиться к одному и тому же стереотипу.
Ассоциации. Клиентские страницы, как правило, могут иметь одну связь <<build>> с серверной страницей, однако серверная страница может иметь несколько связей <<build>> с различными клиентскими страницами. Кроме стандартных комбинаций языка UML, различные стереотипы могут быть связаны ассоциациями.
Для обеспечения определенной визуальной согласованности все пиктограммы страниц снабжены отогнутым корешком в верхнем правом углу. Это свидетельствует о том, что эти пиктограммы представляют целые Web-страницы, обрабатываемые либо клиентским броузером, либо Web-сервером.
Ожидается, что генераторами кода будут использоваться дополнительные тегированные значения для классов-стереотипов и ассоциаций. Тегированные значения, определенные в данном расширении, являются достаточно важными, и их необходимо рассматривать в качестве логически или структурно значимых элементов моделей.
2.3 Расширение UML для WEB-приложений
Расширение к языку UML выражается в терминах стереотипов, тегированных значений и ограничений. Эти объединенные механизмы позволяют создавать новые типы строительных блоков, которые затем можно использовать в модели.
· Стереотип (stereotype) – это расширение к словарю языка. Стереотип позволяет связать с элементом модели новый семантический смысл. Он может применяться практически к каждому элементу. Обычно этот стереотип представляется в виде строки между символами «». Кроме того, его можно изобразить и с использованием новой пиктограммы.
· Тегированное значение (tagged value) — это расширение свойства элемента модели. Большинство элементов модели имеют связанные с ними свойства. Например, классы имеют имена, область видимости, время жизни и другие связанные с ними атрибуты. Тегированное значение позволяет задать новое свойство, которое может быть связано с элементом модели. На диаграмме это значение изображается как строка, заключенная в скобки.
· Ограничение (constraint) — это расширение семантики языка. Оно является правилом, которое определяет, как модели можно поместить вместе. Ограничение определяет условия, при выполнении которых можно считать, что модель "хорошо сформирована". Данные ограничения представляют как строки, заключенные в фигурные скобки {}.
Расширение языка UML начинается с короткого описания, после которого помещается список и описание всех стереотипов, тегированных значений и ограничений. Кроме этих элементов, в расширении должен содержаться также набор хорошо сформулированных правил, используемых для определения того, что режим семантически согласован с самим собой.
2.4 Проектирование "тонкого" Web-клиента
Архитектурный шаблон Thin Web Client налагает на использование Web-страниц наиболее строгие ограничения. Он определяет, что каждая страница может содержать только те архитектурные элементы, которые определены текущей версией языка HTML.
При выполнении этого вида деятельности на этапе проектирования нужно определиться с используемой технологией. В рассматриваемом примере в качестве основного механизма <<Server Page>> применяются активные страницы сервера компании Microsoft (Active Server Page). Среда активных страниц сервера предоставляет также некоторые серверные объекты, которые являются чрезвычайно полезным, особенно объект Session, являющийся аналогом словаря, в котором хранятся значения и объекты, проиндексированные по ключевой строке. Отличительной особенностью такого словаря является то, что он способен поддерживать свое состояние при наличии нескольких запросов с клиентских страниц. Этот объект предоставляет разработчику механизм отслеживания состояния клиента на сервере.
При функционировании объекта Session в броузере помещаются данные cookie, которые хранятся в течение некоторого временного интервала. Это значение является уникальным в коллекции всех экземпляров Session приложения. В других средах разработки Web-приложений для поддержки состояния клиента на сервере применя ются аналогичные механизмы, которые также можно представить на диаграммах.
Зачастую процесс проектирования проще всего начать с непосредственного преобразования модели анализа. К этому виду деятельности можно приступить лишь тогда, когда выбрана определенная архитектура системы и ее хорошо понимают все члены группы проектирования. В приложениях на базе шаблона Thin Web Client исполнители взаимодействуют только с клиентскими страницами, а страницы сервера — лишь с серверными ресурсами. Таким образом, на диаграмму последовательностей нужно поместить клиентскую и серверную страницы. Проще всего это осуществить, напрямую преобразовав граничные объекты модели анализа в клиентские страницы, а объекты-контроллеры – в страницы сервера.
Страница сервера addguest загружается Web-сервером и, поскольку с ней связан стереотип «Server Page», запускает соответствующий механизм обработки сценариев (в данном случае, активных страниц сервера). Этот процесс может включать создание транзакций или промежуточных объектов, требуемых для добавления и проверки сообщения. Страницы сервера, даже если они могут реализовать этот тип бизнес-правил, зачастую являются далеко не лучшим местом для их размещения, поскольку возможность их повторного использования ограничена обработкой страниц. Если поместить эти бизнес-правила в компилируемые модули сервера, их смогут многократно использовать и системы, не являющиеся Web-приложениями.
Рис. 2-Диаграмма последовательностей добавления в гостевую книгу сообщения
Даже в Web-приложениях на основе "тонкого"' клиента серверные страницы перегружены по своей функциональности. Они отвечают за координацию деятельности серверных объектов из предметной области и создание интерфейса пользователя, передаваемого клиенту. Реализация деталей моделирования предметной области вне серверных страниц позволяет уменьшить их обязанности и упростить поддержку.
3. Влияние архитектуры Web-приложения на объемы инвестиций, жизненный цикл продукта и положительные эмоции пользователя
В последнее время стало модным использовать термины «Web-приложение», «front-end-архитектура», «Web 2.0», «HTML5-приложения». Но, к сожалению, в большинстве случаев контекст использования этих терминов не всегда верен, поскольку не учитывает всю специфику реализации и использования архитектуры Web-приложения. Сейчас речь будет идти именно об архитектуре.
Для начала мы рассмотрим самые распространенные архитектуры для Web-приложений, их достоинства и недостатки с трех точек зрения: заказчика, разработчика и пользователя. Возможны и другие варианты, но они все равно являются подтипами рассматриваемых архитектур и сводятся к основным трем.
Начнем с определения Web-приложения как такового. Википедия даст нам следующее определение: клиент-серверное приложение, в котором клиентом выступает браузер, а сервером — веб-сервер. Логика веб-приложения распределена между сервером и клиентом, хранение данных осуществляется преимущественно на сервере, а обмен информацией происходит по сети.
Здесь начинается путаница, связанная непосредственно с архитектурой, с помощью которой реализовано Web-приложение. Дело в том, что логика работы приложения может располагаться как на сервере, так и на клиенте. Разные архитектуры по-разному распределяют логику между клиентом и сервером.
К сожалению, объективно оценить совершенно разные архитектуры невозможно. Мы воспользуемся следующими критериями для оценки:
Пользователь:
Отзывчивость/юзабилити: обновление данных на странице и переключение между страницами (время отзыва). Богатство и удобство интерфейса, его интуитивность.
Linkability: возможность сохранять закладки и ссылки на различные разделы сайта.
Оффлайн: возможность работы приложения без сети.
Разработчик:
Скорость разработки: скорость добавления нового функционала, рефакторинг, распараллеливание процесса разработки между разработчиками и верстальщиками, и т. д.
Производительность: максимально быстрый отклик от сервера с минимальными затратами вычислительных мощностей.
Масштабируемость: возможность увеличения вычислительных мощностей либо дискового пространства в связи с ростом количества информации либо количества пользователей. В случае использования распределенной масштабируемой системы должна обеспечиваться согласованность данных, доступность и устойчивость к разделению (CAP-теорема). Надо заметить, что количество фич/скринов приложения с ростом пожеланий заказчика (на клиентской стороне) не относится к данному определению — это уже скорее зависит не от типа Web-архитектуры, а от используемого фреймворка и исполнения.
Тестируемость: возможность и легкость тестирования (модульное авто-тестирование).
Заказчик:
Функциональная расширяемость: возможность наращивания функционала с минимальными временными и денежными затратами.
SEO: пользователи должны иметь возможность найти приложение, используя любую поисковую систему.
Поддержка: расходы на поддержание инфраструктуры приложения — затраты на железо, сетевую инфраструктуру, персонал, необходимый для обслуживания приложения.
Безопасность: Заказчик приложения должен быть уверен в сохранности бизнес-данных и недоступности данных о других пользователях. В качестве главного критерия безопасности мы будем рассматривать только возможность изменения функциональности поведения приложения на клиенте, а также связанные с этим риски. Стандартные угрозы (к примеру, анализируемые в https://www.owasp.org/index.php/Main_Page) одинаковы для всех сравниваемых архитектур. Безопасность же на участке передачи данных «сервер-клиент» мы не берем во внимание в связи с тем, что все рассматриваемые архитектуры одинаково подвержены взлому — канал передачи данных может быть одним и тем же.
Конверсия: сайт — мобильное или десктопное приложение: возможность опубликовать приложение в мобильных маркетах, или обернуть его в десктопное приложение с минимальными дополнительными затратами.
Используемая литература
Переводчик: Михаил Райтман)