В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 77
Текст из файла (страница 77)
таких, где пользовательдостаточно часто выполняет какие-то действия, на которые приложение должно реагировать. Ониизначально разрабатывались для предоставления доступа к статической информации, котораяменяется редко и представлена в виде набора 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-служб. Найдяслужбу, которая, судя по описанию, эту услугу оказывает, он обращается по указанному в ееспецификации адресу и получает описание интерфейса для обращения к этой службе. После этогоклиент может обращаться к службе в соответствии с этим интерфейсом.Использование на всех этапах описанного процесса стандартных описаний в форматах,основанных на XML, позволяет полностью автоматизировать его.Описание интерфейса Web-службЯзыком описания интерфейса Web-служб служит WSDL (читается «виздэл») — Web ServicesDescription Language, язык описания Web-служб [23]. Этот язык служит аналогом (и некоторымобобщением) языков описания интерфейсов (IDL), используемых при реализации удаленныхвызовов процедур и методов.
В настоящее время используется версия WSDL 1.1, но в 2006 годувыйдет версия 2.0, в которой достаточно много новых элементов.Описание интерфейса работы с Web-службой на WSDL состоит из двух частей — абстрактнойи конкретной. Абстрактная часть описания содержит определения типов данных, используемых вобращениях к данной службе и определения абстрактных операций, которые можно «вызвать» услужбы.
Напомним, что все такие «вызовы» являются асинхронными обращениями. Конкретнаячасть содержит описание привязки операций к определенным адресам, протоколам доступа ипортам.•Типы данных описываются внутри тега <types>. Они могут основываться на встроенныхXML-типах и использовать XML Schema для описания сложных структур данных.•С помощью тегов <message> описываются типы сообщений, которыми стороны могутобмениваться в ходе работы службы.
Для сообщения указывается, является ли оновходящим или исходящим, а его описывается структура в терминах определенных ранеетипов данных.Далее определяются операции, которые могут включать в себя обмен сообщенияминескольких типов. Для операции указывается используемый в ее рамках шаблон обменасообщениями. Примерами шаблонов являются: однократное уведомление со стороны•280•службы, запрос со стороны клиента, запрос-ответ. Всего в WSDL 1.1 есть 4 вида шаблонов,в WSDL 2.0 — уже 9 видов.Операции группируются в интерфейсы, которые в WSDL 1.1 названы типами портов (porttypes).•С помощью элемента <binding> определяется привязка интерфейсов к их реализациям.Она задает конкретные форматы сообщений и протоколы их посылки/получения длянекоторого интерфейса. Один интерфейс может иметь несколько привязок.•Элемент <port> определяет порт, задающий конкретные адрес и порт некоторой привязки,а также, возможно, транспортный протокол для передачи сообщений на этот адрес.•Наконец, элемент <service> описывает службу целиком, указывая набор портов длядоступа к различным ее интерфейсам.СвязьСвязь между Web-службами и их клиентами осуществляется по протоколу SOAP (Simple ObjectAccess Protocol, простой протокол доступа к объектам) [24].
Протокол SOAP являетсяпротоколом уровня представления по модели OSI, т.е. он определяет формат сообщений, которыепересылаются с помощью некоторого транспортного протокола, в качестве которого обычноиспользуются HTTP, HTTPS, TCP, иногда SMTP.Формат сообщений SOAP основан на XML. SOAP-сообщение состоит из следующих частей.• Конверт (envelope) — содержит сообщение целиком.• Заголовок (header) — содержит значения некоторых дополнительных атрибутовсообщения, используемых при его обработке или переадресации. Заголовок можетотсутствовать и используется обычно для передачи информации о координации несколькихсообщений, идентификации сеансов и передачи разного рода сертификатов для защитыинформации.• Тело (body) — основное содержимое сообщения, должно относится к одному из типовсообщений, которыми можно обмениваться с данной службой согласно описанию ееинтерфейса.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
