Архитектурные особенности проектирования и разработки Веб-приложений

5.1.7. Архитектура Веб-приложений

Обычно Веб-приложения создаются как приложения в архитектуре "клиент-сервер", но серверная часть имеет различные архитектурные решения [20].

Изначально World Wide Web (WWW) представлялась ее создателям как "пространство для обмена информацией, в котором люди и компьютеры могут общаться между собой". Поэтому первые Веб-приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Таким образом, Веб начиналась как документо-ориентированная.

Следующим этапом развития Веб стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем – на ISAPI. Common Gateway Interface (CGI) – это стандартный интерфейс работы с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTTP-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство.

Появление Internet Server API (ISAPI) позволило не только решить проблемы производительности, которые возникали с CGI-приложениями, но и предоставить в распоряжение разработчиков более богатый программный интерфейс. ISAPI DLL можно было ассоциировать с расширениями имен файлов через специальную мета-базу. Эти два механизма (CGI и ISAPI) послужили основой создания первого типа Веб-приложений, в которых, в зависимости от каких-либо клиентских действий, выполнялся серверный код. Таким образом, стала возможной динамическая генерация содержимого Веб-страниц и наполнение Веб перестало быть чисто статическим.

Интерфейс ISAPI – это особенность Microsoft Internet Information Server. ISAPI-приложения представляют собой динамические загружаемые библиотеки (DLL), которые выполняются в адресном пространстве Веб-сервера. У других Веб-серверов через некоторое время также появилась возможность выполнять приложения, реализованные в виде библиотек. В случае Веб-серверов Netscape этот программный интерфейс назывался NSAPI (Netscape Server API). У довольно популярного Веб-сервера Apache также имеется возможность выполнять Веб-приложения, реализованные в виде библиотек; такие библиотеки называются Apache DSO (Dynamic Shared Objects).

Естественно, что при использовании как CGI-, так и ISAPI-приложений разработчики в основном решали одни и те же задачи, поэтому естественным шагом стало появление нового, высокоуровневого интерфейса, который упростил задачи генерации HTML-кода, позволил обращаться к компонентам и использовать базы данных. Таким интерфейсом стала объектная модель Active Server Pages (ASP), построенная на основе ISAPI-фильтра.

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

Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Веб-страницы кода, выполняемого Веб-сервером. Наиболее известная из них на сегодняшний день – технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер.

Новейшая версия технологии Active Server Pages – ASP .NET, являющаяся ключевой в архитектуре Microsoft .NET Framework. С помощью ASP .NET можно создавать Веб-приложения и Веб-сервисы, которые не только позволяют реализовать динамическую генерацию HTML-страниц, но и интегрируются с серверными компонентами и могут использоваться для решения широкого круга бизнес-задач, возникающих перед разработчиками современных Веб-приложений.

В общем случае клиентом Веб-сервера может быть не только персональный компьютер, оснащенный обычным Веб-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Веб-серверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк черно-белого текста), для них существуют и другие протоколы передачи данных (WAP – Wireless Access Protocol) и соответствующие языки разметки (WML – Wireless Markup Language, СHTML – Compact HTML и т.п.). При этом возникает задача передачи данных на мобильное устройство в соответствующем формате (и для этой цели существуют специальные сайты), либо, что представляется более удобным, происходит опознание типа устройства в момент его обращения к серверу и преобразование исходного документа (например, в формате XML) в формат, требующийся данному мобильному устройству (например, с помощью XSLT-преобразования).

Другим способом поддержки различных типов клиентов является создание "разумных" серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP .NET.

Другим направлением развития клиентских частей Веб-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Веб-браузере. В частности, современные Веб-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP-код, внедряется в Веб-страницу, но интерпретируется не Веб-сервером, а браузером и соответственно выполняется на клиентском устройстве. Кроме того, современные браузеры способны отображать и выполнять Java-аплеты – специальные Java-приложения, которые пользователь получает в составе Веб-страницы, а некоторые из браузеров могут также служить контейнерами для элементов управления ActiveX – выполняющихся в адресном пространстве браузера специальных COM-серверов, также получаемых в составе Веб-страницы. И в Java-аплетах, и в элементах управления ActiveX можно реализовать практически любую функциональность.

Отметим, что с ростом объема используемых данных и числа посетителей Веб-сайтов возрастают и требования к надежности, производительности и масштабируемости Веб-приложений. Следующим этапом эволюции подобных приложений стало отделение бизнес-логики, реализованной в Веб-приложении, а нередко и сервисов обработки данных и реализации транзакций от его интерфейса. В этом случае в самом Веб-приложении обычно остается так называемая презентационная часть, а бизнес-логика, обработка данных и реализация транзакций переносятся в сервер приложений в виде бизнес-объектов. В зависимости от типа сервера приложений подобные бизнес-объекты могут быть выполняющимися самостоятельно COM-серверами, CORBA-серверами, а также объектами COM+, выполняющимися с помощью служб компонентов Windows 2000, или объектами EJB (Enterprise Java Beans), исполняемыми сервером приложений, поддерживающим спецификаци ю J2EE (Java 2 Enterprise Edition). В качестве механизма доступа к данным подобные объекты могут использовать OLE DB, ODBC, JDBC (это зависит от того, как реализован бизнес-объект).

Нередко подобные бизнес-объекты предоставляют доступ к данным корпоративных информационных систем либо реализуют какую-либо часть их функциональности. Нередко они позволяют, например, интегрировать Веб-сайт с CRM-системами (Customer Relationship Management) или с ERP-системами (Enterprise Resource Planning), сохраняя в корпоративных системах сведения о посетителях сайта и предоставляя потенциальным клиентам сведения об имеющейся продукции для осуществления заказов.

Поскольку современный Интернет – это не столько средство демонстрации присутствия компании на рынке или инструмент маркетинга, сколько инструмент ведения бизнеса, достаточно важными становятся задачи реализации организации через Интернет таких взаимоотношений с клиентами, как продажа товаров и услуг. И здесь довольно важными становятся решения для электронной коммерции типа "предприятие-клиент" (B2C – business-to-consumer). Не менее важными становятся и задачи интеграции Веб-приложений c данными и приложениями партнеров с целью реализации схемы "предприятие-предприятие" (B2B – business-to-business), позволяющей заключать торговые сделки между предприятиями, обмениваться каталогами товаров, проводить аукционы, создавать электронные торговые площадки.

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

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

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

Обобщая вышесказанное можно выделить основные особенности веб-архитектуры [19, 20]:

• отсутствие необходимости использовать дополнительное ПО на стороне клиента – это позволяет автоматически реализовать клиентскую часть на всех платформах;
• возможность подключения практически неограниченного количества клиентов;
• благодаря единственному месту хранения данных и наличия системы управления базами данных обеспечиваются минимальные требования для поддержания целостности данных;
• доступность при работоспособности сервера и каналов связи;
• недоступность при отсутствии работоспособности сервера или каналов связи;
• достаточно низкая скорость Веб сервера и каналов передачи данных;
• относительно объема данных – архитектура Веб систем не имеет существенных ограничений.

Схематически такую архитектуру (в трехзвенном варианте) можно представить, как показано на рис. 5.9.

Рис. 5.9. Архитектура Веб-приложений

5.1.8. Сервис-ориентированная архитектура

Решение многих описанных выше задач, возникающих при создании современных Веб-приложений, теперь начинает возлагаться на Веб-сервисы – не зависящие от платформы, объектной модели и клиента программные компоненты, которые можно вызывать из клиентских Веб-приложений (а также из самих Веб-сервисов) через основанный на протоколе HTTP и языке XML протокол SOAP [20]. Для описания Веб-сервисов используется XML-подобный язык WSDL, а для организации реестров Веб-сервисов, в которых разработчики и компании могут искать необходимые им сервисы, а также публиковать данные о своих сервисах – интерфейс UDDI.

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

Сервис-ориентированная архитектура (SOA, service-oriented architecture) – модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами [21].

OASIS (Организация по распространению открытых стандартов структурированной информации) определяет SOA следующим образом (OASIS Reference Model for Service Oriented Architecture V 1.0): Сервисно-ориентированная архитектура – это парадигма организации и использования распределенных информационных ресурсов таких как: приложения и данные, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть: конечный пользователь или другое приложение.

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

Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SOA, часто реализуются как набор веб-сервисов, интегрированных при помощи известных стандартных протоколов (SOAP, WSDL, и т. п.)

Интерфейс компонентов SОА-программы предоставляет инкапсуляцию деталей реализации конкретного компонента (ОС, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SOA предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределенных программных комплексов.

SOA хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, ИВК Юпитер, TIBCO, Diasoft).

Основными целями применения SOA для крупных информационных систем, уровня предприятия, и выше являются [21]:

• сокращение издержек при разработке приложений, за счет упорядочивания процесса разработки;
• расширение повторного использования кода;
• независимость от используемых платформ, инструментов, языков разработки;
• повышение масштабируемости создаваемых систем;
• улучшение управляемости создаваемых систем.

Принципы SOA:

• архитектура, как таковая, не привязана к какой-то определенной технологии;
• независимость организации системы от используемой вычислительной платформы (платформ);
• независимость организации системы от применяемых языков программирования;
• использование сервисов, независимых от конкретных приложений, с единообразными интерфейсами доступа к ним;
• организация сервисов как слабосвязанных компонентов для построения систем.

Архитектура не привязана к какой-то определенной технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать, дополнительно, механизм файловой системы, для обмена данными.

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

SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путем комбинации слабосвязанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определенного платформо-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса.

Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java, работающие на платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.

SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий или фреймворков для документирования сервисов.

Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов.

5.1.9. Ключевые термины

Архитектура, Централизованная архитектура, Архитектура "файл-сервер", Двухзвенная архитектура "клиент-сервер", , Терминал, Сервер приложений, Сервер базы данных, Архитектура распределенных систем, Архитектура Веб-приложений, Сервис-ориентированная архитектура.