1. Архитектура веб-приложений и технологии их создания

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

    Схематически архитектура "клиент-сервер" представлена на рис.1.

Рисунок 1 – Архитектура веб-приложений

    Изначально “World Wide Web” представлялась ее разработчикам как "система для обмена информацией, в которий люди и компьютеры будут общаться друг с другом" [4]. Из-за этого первые Web-приложения основывались на простой файл-серверной архитектуре, т.е. отправляли по запросу пользователя статическую html-страницу. Таким образом, Web зарождалось как простая документная система.

   Второй этап развития Web связан с появлением новых приложений, которые разрабатывались на таких интерфейсах, как “CGI”, а в дальнейшем – на “ISAPI”. Common Gateway Interface [5, 6] – является стандартным интерфейсом, работающим с серверами и позволяющим выполнять различные серверные приложения, вызываемые через URL. Входящей информацией для данных приложений служит содержимое HTTP-заголовков. CGI-приложения генерируют html-разметку, которая возвращается браузеру. Но главной проблемой CGI-приложений стало то, что при каждом запросе от браузера сервер заново выполняет CGI-программу, записывая ее в отдельное адресное пространство сервера.

    Появление Internet Server API (ISAPI) [4, 7] позволило не только решить проблемы производительности, связанные с использованием 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) [8], построенная на основе ISAPI-фильтра.

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

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

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

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

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

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

Рисунок 2 – Трехзвенная архитектура веб-приложений 

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

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

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

    Хронология развития веб-технологий отражена на рис.3.

Рисунок 3 – Хронология развития веб-технологий

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

• отсутствие необходимости использовать дополнительное ПО на стороне клиента, что позволяет реализовать кросс-платформенную клиентскую часть;

• возможность подключения практически неограниченного количества клиентов;

• объем хранимых и обрабатываемых данных ограничивается лишь пропускной способностью каналов связи и мощностью веб-серверов;

• благодаря единственному месту хранения данных и наличия системы управления базами данных обеспечиваются простота администрирования;

• доступность зависит от работоспособности сервера и каналов передачи данных;

• более низкая скорость отклика Веб-сервера и каналов передачи данных (сравнительно с локальной сетью);