В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 77
Текст из файла (страница 77)
Длятого чтобы использовать любую такую технологию в приложении на основе Spring, достаточноиметь специализированный адаптер, который реализует интерфейс, предлагаемый Spring дляподдержки синхронизации данных между приложением и хранилищем данных. После указанияэтого адаптера в конфигурации приложения среда сама позаботится о том, чтобы всякий раз после277появления возможных различий между данными приложения и базы данных были вызваныметоды этого адаптера, копирующие новые данные в ту или другую сторону.Похожим образом поддерживается интеграция с различными реализациями служб поддержкитранзакций и декларативное управление транзакциями.
Методам обычного класса 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.278Web-службыВ настоящее время совместно с компонентными технологиями на базе J2EE и .NET широкоераспространение получают Web-службы или Web-сервисы (Web services) [18-22], представляющиесобой компонентную технологию другого рода, реализуемую поверх этих платформ. Основнымиотличительными признаками служб (services) любого вида служат следующие.• Служба чаще всего предоставляет некоторую функцию, которая полезна достаточноширокому кругу пользователей.• Как и другие компоненты, службы имеют четко описанный интерфейс, выполняющийопределенный контракт.
Именно контракт фиксирует выполняемую службой функцию.• Контракт службы не должен зависеть от платформ, операционных систем и языковпрограммирования, с помощью которых эта служба может быть реализована. Интерфейс иреализация службы строго отделяются друг от друга.• Службы вызываются асинхронно. Ждать или нет результатов вызова службы, решает самклиент, обратившийся к ней.• Службы совершенно независимы друг от друга, могут быть вызваны в произвольныхкомбинациях и всякий раз работают в соответствии со своим контрактом.Контракт службы не должен зависеть от истории обращений к ней или к другим службам.Но он может зависеть, например, от состояния каких-либо хранилищ данных.• Обращение к службе возможно с любой платформы, из любого языка программирования, слюбой машины, имеющей какую-либо связь с той, на которой размещается реализацияслужбы.
Реализации служб должны предоставлять возможность обратиться к ним идинамически обнаружить их в сети, а также предоставлять необходимую дополнительнуюинформацию, с помощью которой можно понять, как с ними работать.Архитектура приложений, построенных из компонентов, являющихся такими службами,называется архитектурой, основанной на службах (service oriented architecture, SOA).Практически единственным широко используемым видом служб являются Web-службы. Webслужбами называют службы, построенные с помощью ряда определенных стандартныхпротоколов, т.е.
использующие протокол SOAP и инфраструктуру Интернет для передачи данныхо вызовах операций и их результатах, язык WSDL для описания интерфейсов служб и реестрыUDDI для регистрации служб, имеющихся в сети. Существуют многочисленные дополнительныетехнологии, протоколы и стандарты, относящиеся к другим аспектам работы Web-служб, однакоони пока применяются гораздо реже. Web-службы могут быть реализованы на основе J2EE, .NETили других технологий.БрокерWeb-служб,регистраторПоиск нужнойслужбыКлиент,использующийслужбуДействияОписанияслужбОбращение кслужбеПубликацияописания службыПоставщикслужбыОписаниеИнтерфейсРеализацияРисунок 81.
Схема архитектуры приложений на основе Web-служб.279Основное назначение Web-служб — предоставление бизнес-услуг организациями отдельнымпользователям, а также другим организациями на единой технологической основе. Привзаимодействии между различными организациями (business-to-business, B2B) Web-службыделают возможным оказание всех необходимых услуг вообще без вмешательства человека, если,конечно, урегулированы все вопросы, касающиеся стоимости услуг, защищенности данных обоказанных услугах, и доверия организаций друг к другу.Таким образом, Web-службы представляют собой компонентную технологию построениякрупномасштабных распределенных приложений, ориентированных на предоставление бизнесуслуг. В таких приложениях могут участвовать тысячи Web-служб, работающих на совершенноразных платформах, в различных организациях и реализованных с использованием разныхтехнологий.
В каждый момент времени такое приложение может не существовать как единоецелое: какие-то его компоненты могут не участвовать в текущей работе, другие вообще неработать в связи с отключением соответствующих серверов, третьи — перемещаться с одноймашины на другую. Все его компоненты объединяются только едиными стандартами описанияинтерфейсов и обеспечения взаимодействия между Web-службами.Схема архитектуры приложений на основе Web-служб, предложенная IBM в конце 1990-хгодов, изображена на Рис.
81.После создания новой службы ее поставщик — организация или частное лицо, котороепредоставляет ее, — регистрирует службу у брокера Web-служб (или у нескольких такихброкеров), помещая в его реестр описание службы. Такое описание содержит описание услуги,предоставляемой Web-службой и описание способа доступа к ней — протокол доступа, адрес ипорт, к которому надо обращаться.Клиент, которому понадобилась некоторая услуга, обращается к брокеру Web-служб. Найдяслужбу, которая, судя по описанию, эту услугу оказывает, он обращается по указанному в ееспецификации адресу и получает описание интерфейса для обращения к этой службе.