Развитие компонентных технологий

Среда Spring

Среда Spring [9,13,14,15] представляет собой одну из наиболее технологичных на данный момент сред разработки Web-приложений. В ее рамках получили дальнейшее развитие идеи специализации обработчиков запросов, использованные в Struts. В Spring также используются элементы аспектно-ориентированного подхода к разработке ПО, позволяющие значительно повысить гибкость и удобство модификации построенных на ее основе Web-приложений.

Основная задача, на решение которой нацелена среда Spring, — интеграция разнородных механизмов, используемых при разработке компонентных Web-приложений. В качестве двух основных средств такой интеграции используются идеи обращения управления (inversion of control) и аспектно-ориентированного программирования (aspect-oriented programming, AOP).

Обращением управления называют отсутствие обращений из кода компонентов приложения к какому-либо API, предоставляемому средой и ее библиотеками. Вместо этого компоненты приложения реализуют только функции, необходимые для работы в рамках предметной области и решения тех задач, с которыми приложению придется иметь дело. Построение из этих компонентов готового приложения, конфигурация отдельных его элементов и связей между ними — это дело среды, которая сама в определенные моменты обращается к нужным операциям компонентов. Конфигурация компонентов приложения в среде Spring осуществляется при помощи XML-файла springapp-servlet.xml. Этот файл содержит описание набора компонентов, которые настраиваются при помощи указания параметров инициализации соответствующих классов и значений своих свойств в смысле JavaBeans.

Другое название механизма обращения управления — встраивание зависимостей (dependency injection) — связано с возможностью указывать в коде приложения только интерфейсы некоторых объектов, а их точный класс, как и способ их получения (создание нового объекта, поиск при помощи службы каталогов, обращение к фабрике объектов и пр.) — описывать только в конфигурационном файле. Такой механизм позволяет разделить использование объектов и их конфигурацию и менять их независимо друг от друга.

Аналогичный механизм предполагается использовать и в рамках EJB 3.0 в следующем виде. При помощи конструкции @Resource Type object; некоторый объект может быть объявлен в коде как подлежащий отдельной конфигурации, а в конфигурационном файле для объекта с именем object указывается его точный тип и способ инициализации.

Аспектно-ориентированный подход к программированию основан на выделении аспектов — отдельных задач, решаемых приложением — таким образом, чтобы их решение можно было организовать в виде выполнения определенных действий каждый раз, когда выполняется определенный элемент кода в ходе работы программы. При этом действия в рамках данного аспекта не должны зависеть от других аспектов и остальных действий, выполняемых программой. Не все задачи могут быть представлены как аспекты. Поэтому AOP-программа представляет собой композицию из "обычной" программы, описываемой вне рамок AOP, и аспектных действий, выполняемых в определенных точках "обычной" программы. Такие действия называют указаниями (advice), точки их выполнения в "обычной" программе — точками вставки (joinpoints), а наборы точек вставки, в которых должно выполняться одно и то же действие — сечениями (pointcuts).

Примером указаний могут служить трассировка параметров вызова метода или проверка корректности инициализации полей объекта. В качестве примеров точек вставки можно привести момент перед вызовом определенного метода или сразу после такого вызова, момент после инициализации определенного объекта или перед его уничтожением. Сечения могут описываться условиями типа "перед вызовом в данном объекте метода, чье имя начинается на "get" " или "перед уничтожением объекта класса A со значением поля value, превышающим 0 ".

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

При помощи AOP в Spring реализована поддержка интеграции приложений с хранилищами данных при помощи различных технологий, примерами которых являются JDO и Hibernate. Для того чтобы использовать любую такую технологию в приложении на основе Spring, достаточно иметь специализированный адаптер, который реализует интерфейс, предлагаемый Spring для поддержки синхронизации данных между приложением и хранилищем данных. После указания этого адаптера в конфигурации приложения среда сама позаботится о том, чтобы всякий раз после появления возможных различий между данными приложения и базы данных были вызваны методы этого адаптера, копирующие новые данные в ту или другую сторону.

Похожим образом поддерживается интеграция с различными реализациями служб поддержки транзакций и декларативное управление транзакциями. Методам обычного класса Java в конфигурационном файле (или с помощью аннотаций Java 5) можно приписать определенные транзакционные атрибуты, а также набор типов исключительных ситуаций, вызывающих откат транзакции. Для сравнения — в EJB 2.1 только исключения, чей тип является наследником java.lang.RuntimeException, java.lang.Error или javax.ejb.EJBException, вызывают автоматический откат транзакции. Адаптер конкретной реализации службы транзакций также указывается в конфигурации приложения.

Использование обращения управления позволяет также упростить описание конфигурации сервлетов и контроллеров ( Spring -аналог действий из Struts ) и определение самих контроллеров.

Ajax

Рассказывая о развитии технологий разработки Web-приложений, невозможно обойти вниманием набор техник, известный под названием Ajax [16,17] и используемый для снижения времени реакции Web-интерфейсов на действия пользователя.

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

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

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

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