Определение архитектуры Web-приложений

    Лекция 1. Определение архитектуры Web-приложений

    План

    1. Архитектура приложений

    2. Архитектурные шаблоны Web-приложений

    3. Шаблон Thin Web Client

    4. Шаблон Thick Web Client

    5. Шаблон Web Delivery 

    Содержание 

    1. Архитектура приложений

    Если  группа формулировки системных требований занимается построением модели прецедентов, то архитектор или группа специалистов проверяет эту модель и исследует возможные системные архитектуры. Архитектор несет ответственность за выбор той программной архитектуры, которая позволит удовлетворить выдвинутым требованиям и реализовать сценарии прецедентов.

    Под термином «архитектура» понимается высокоуровневое представление  значимых компонентов системы. В  этом смысле компонент представляет собой отдельную сущность с открытым интерфейсом.

    2. Архитектурные шаблоны Web-приложений

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

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

    Основными шаблонами являются:

    1. Thin Web Client используется в большинстве приложений Intenet и предоставляет ограниченные возможности по управлению конфигурацией клиента. В распоряжении клиента должен быть только стандартный браузер, поддерживающий формы. Все операции, связанные с бизнес-логикой, выполняются на сервере.

    2. Thich Web Client предполагает, что значительная часть бизнес-логики выполняется на клиентской машине. Обычно для выполнения бизнес-логики используется динамический HTML, аплеты Java или управляющие элементы ActiveX. Взаимодействие с сервером по-прежнему происходит через протокол HTTP.

    3. Web Delivery. При взаимодействии клиента и сервера, кроме протокола HTTP, используются и другие протоколы, такие как IIОР, DCOM, которые могут применяться для поддержки системы распределенных объектов. В данном случае браузер функционирует как контейнерный модуль системы распределенных объектов.

    3. Шаблон Thin Web Client

    Шаблон  на основе «тонкого» клиента полезно использовать в тех приложениях, в которых можно гарантировать наличие только минимальной конфигурации клиента. Этот шаблон больше всего подходит для Web-приложений, когда клиент обладает минимальными вычислительными возможностями или не может управлять своей конфигурацией.

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

    Структура шаблона. Основные компоненты архитектуры размещаются на сервере. В большинстве случаев – это минимальная структура Web-приложения. Основные компоненты:

• Клиентский браузер. Браузер функционирует как обобщенное устройство с интерфейсом пользователя. При использовании архитектуры тонкого клиента браузер обеспечивает только одну дополнительную возможность: прием и возврат данных cookie.
• Web-сервер – главная точка доступа для всех клиентских браузеров. В архитектуре тонкий клиент браузеры получают доступ к системе только через Web-сервер, который принимает запросы на получение Web-страниц – либо статических, либо динамических (формируемых на сервере). В зависимости от запроса Web-сервер может инициировать некоторые серверные процессы. Если запрос сгенерирован на получение серверной страницы со сценариями, модулями CGI, ISAPI, то Web-сервер передает эту страницу для обработки соответствующему интерпретатору сценариев или исполняемому модулю. Результатом обработки является отформатированная HTML-страница, которую можно отобразить в браузере.
• Соединение HTTP – стандартный протокол взаимодействия клиентских браузеров и серверов. Каждый раз, когда клиент и сервер обмениваются информацией, устанавливается новое независимое соединение.
• Станица HTML – Web-страница с интерфейсом пользователя и содержательной информацией, которая не обрабатывается сервером. Обычно такие страницы содержит пояснительный текст или HTML-форму для ввода данных. Когда Web-сервер получает запрос на страницу HTML, он просто извлекает требуемый файл и, не выполняя никакой фильтрации, передает его соответствующему клиенту.
• Серверная страница – Web-страницы, которые обрабатываются серверной частью приложения. Такие страницы реализуются в виде страниц со сценариями, которые пропускаются через фильтр сервера приложения или исполняемого модуля. Эти страницы потенциально имеют доступ ко всем  серверным ресурсам, включая бизнес-логику, базы данных и существующие системы.
• Сервер приложения – основное средство для выполнения бизнес-логики в серверной части приложения. В обязанности сервера приложений входит выполнение кода серверных страниц.
• Дополнительный элемент – база данных. Во многих Web-приложениях база данных используется для хранения коммерческой информации. В некоторых случаях база данных используется для хранения самих страниц (однако такое ее применение относится к другому архитектурному шаблону).

    Простейший  способ соединения системы с базой  данных заключается в обеспечении для сценариев серверных страниц возможности прямого доступа к компоненты хранения данных. Существуют стандартные библиотеки доступа к данным, такие как RDO(Remote Data Object), ADO (ActiveX Data Object), ODBC (Open Database Connectivity), JDBC (Java Database Connectivity).

    На  рис. 1.1 представлено логическое представление архитектурного шаблона "тонкого" Web-клиента.

    

    

 

    Рис. 1.1. Архитектура на основе "тонкого" Web-клиента 

    Основные  принципы поведения. В основе этого архитектурного шаблона лежит следующий принцип: бизнес-логика используется только в ответ на запрос Web-страницы клиентом. Клиент взаимодействует с системой, используя протокол HTTP для получения страниц с Web-сервера. Если запрашиваемая страница является файлом HTML файловой системы Web-сервера, то сервер просто извлекает страницу и пересылает ее клиенту. Если страница содержит сценарий, т.е. интерпретируемый код, то все необходимые действия по обработке сценария выполняются сервером приложения.

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

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

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

      4. Шаблон Thick Web Client

    Данный  архитектурный шаблон расширяет  функции архитектуры на основе «тонкого» клиента и позволяет реализовать в клиентской части приложения сценарии и пользовательские объекты, такие как управляющие элементы ActveX или аплеты Java. Как следует из названия шаблона, в клиентской части может быть реализована часть бизнес-логики системы.

    Архитектурный шаблон «толстый» клиент лучше всего  подходит для использования в  тех Web-приложениях, в которых предполагается использовать определенную клиентскую конфигурацию и версию браузера, а сложный интерфейс пользователя или некоторую часть бизнес-логики перенести на клиентскую часть. В некоторых ситуациях бизнес-логика может полностью выполняться на клиентской части.

    Структура шаблона. Поскольку архитектурный шаблон Thick Web Client является расширением архитектуры на основе "тонкого" Web-клиента, в обоих шаблонах имеются одни и те же базовые элементы, к которым добавляются некоторые дополнительные компоненты.

• Клиентский сценарий (Client script) — сценарий JavaScript или VBScript, внедренный в отформатированные страницы HTML. Броузер интерпретирует сценарии. Консорциум W3C определил стандарт HTML и интерфейс объектной 
  модели документа DOM (Document Object Model), которые позволяют броузеру 
  обрабатывать клиентские сценарии.
• Документ XML (XML document) —- документ на языке XML (Extensible Markup 
  Language). В документах XML представляется содержимое (данные) без элемен 
  тов форматирования.
• Управляющий элемент ActiveX (ActiveX control) — загружаемый при необходимости СОМ-объект, на который может ссылаться клиентский сценарий. Как и 
  любой другой СОМ-объект, он имеет полный доступ к клиентским ресурсам. 
  Основной механизм обеспечения безопасности клиентских компьютеров за 
  ключается в применении алгоритмов аутентификации и цифровых подписей. 
  Броузеры можно настроить таким образом, чтобы при загрузке управляющих 
  элементов ActiveX на клиентский компьютер пользователю выдавалось предупреждающее сообщение. Механизмы аутентификации позволяют идентифици 
  ровать автора управляющего элемента посредством анализа подписи, выданной 
  одним из пользующихся доверием агентств по выдаче сертификатов.
• Аплет Java (Java applet) — платформно-независимый откомпилированный компонент, запускаемый в контексте броузера. Для обеспечения требуемого уровня 
  безопасности аплет имеет ограниченный доступ к клиентским ресурсам. Java-аплеты могут использоваться как для создания сложных элементов пользовательского интерфейса, так и для анализа документов XML или инкапсуляции 
  сложных правил бизнес-логики.
• Компонент JavaBean — небольшой Java-компонент, предназначенный для выполнения определенной задачи и поддерживающий некоторый набор интерфейсов, позволяющих встраивать его в более сложные системы. Управляющие 
  элементы ActiveX являются аналогом компонентов JavaBean в архитектурах, 
  разработанных компанией Microsoft.

 

    На  рис. 1.2 представлена архитектура на основе "толстого" Web-клиента.

    

    Рис. 1.2.  Архитектура на основе "толстого" Web-клиента 

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

    На  странице, передаваемой клиентскому  броузеру, могут содержаться сценарии, управляющие элементы и аплеты, которые позволяют либо просто улучшить пользовательский интерфейс, либо реализовать часть бизнес-логики. К наиболее простым бизнес-правилам относится проверка корректности входных данных. Клиентские сценарии могут использоваться для проверки правильности значения не только в одном поле формы, но и во всех полях любой Web-страницы.

    При использовании этого шаблона  очень важно обеспечить переносимость  приложения между различными реализациями броузеров. Не все HTML-броузеры поддерживают сценарии JavaSCript и VBScript. Кроме того, управляющие элементы ActiveX могут применяться лишь на клиентских компьютерах под управлением операционной системы Windows компании Microsoft. Даже если используются броузеры известных производителей, всегда присутствуют, пусть незначительные, но все же отличия в реализации модели DOM.

    Выводы. При использовании клиентских сценариев, управляющих элементов и аплетов очень важно, чтобы группой тестирования был выполнен полный набор тестов для всех поддерживаемых клиентских конфигураций. Если на клиенте размещена важная часть бизнес-логики, то необходимо удостовериться в ее корректном и непротиворечивом выполнении на всех типах используемых броузеров. Не надейтесь, что все броузеры работают одинаково. Различные броузеры будут по-разному обрабатывать один и тот же исходный код, и, более того, один и тот же броузер будет по-разному работать в различных операционных системах. 

    5. Шаблон Web Delivery

    В приложениях данного типа используется архитектура клиент/сервер и распределенные объекты, а в качестве важных элементов добавлен Web-сервер и клиентский броузер.