Lecture15 (1133572), страница 4
Текст из файла (страница 4)
Основнымиотличительными признаками служб (services) любого вида служат следующие.• Служба чаще всего предоставляет некоторую функцию, которая полезна достаточноширокому кругу пользователей.• Как и другие компоненты, службы имеют четко описанный интерфейс, выполняющийопределенный контракт. Именно контракт фиксирует выполняемую службой функцию.• Контракт службы не должен зависеть от платформ, операционных систем и языковпрограммирования, с помощью которых эта служба может быть реализована.
Интерфейс иреализация службы строго отделяются друг от друга.• Службы вызываются асинхронно. Ждать или нет результатов вызова службы, решает самклиент, обратившийся к ней.• Службы совершенно независимы друг от друга, могут быть вызваны в произвольныхкомбинациях и всякий раз работают в соответствии со своим контрактом.Контракт службы не должен зависеть от истории обращений к ней или к другим службам.Но он может зависеть, например, от состояния каких-либо хранилищ данных.• Обращение к службе возможно с любой платформы, из любого языка программирования, слюбой машины, имеющей какую-либо связь с той, на которой размещается реализацияслужбы.
Реализации служб должны предоставлять возможность обратиться к ним идинамически обнаружить их в сети, а также предоставлять необходимую дополнительнуюинформацию, с помощью которой можно понять, как с ними работать.Архитектура приложений, построенных из компонентов, являющихся такими службами,называется архитектурой, основанной на службах (service oriented architecture, SOA).Практически единственным широко используемым видом служб являются Web-службы. Webслужбами называют службы, построенные с помощью ряда определенных стандартныхпротоколов, т.е. использующие протокол SOAP и инфраструктуру Интернет для передачи данныхо вызовах операций и их результатах, язык WSDL для описания интерфейсов служб и реестрыUDDI для регистрации служб, имеющихся в сети.
Существуют многочисленные дополнительныетехнологии, протоколы и стандарты, относящиеся к другим аспектам работы Web-служб, однакоони пока применяются гораздо реже. Web-службы могут быть реализованы на основе J2EE, .NETили других технологий.БрокерWeb-служб,регистраторПоиск нужнойслужбыКлиент,использующийслужбуДействияОписанияслужбОбращение кслужбеПубликацияописания службыПоставщикслужбыОписаниеИнтерфейсРеализацияРисунок 81. Схема архитектуры приложений на основе Web-служб.Основное назначение 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> описываются типы сообщений, которыми стороны могутобмениваться в ходе работы службы. Для сообщения указывается, является ли оновходящим или исходящим, а его описывается структура в терминах определенных ранеетипов данных.Далее определяются операции, которые могут включать в себя обмен сообщенияминескольких типов.
Для операции указывается используемый в ее рамках шаблон обменасообщениями. Примерами шаблонов являются: однократное уведомление со стороныслужбы, запрос со стороны клиента, запрос-ответ. Всего в 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) — основное содержимое сообщения, должно относится к одному из типовсообщений, которыми можно обмениваться с данной службой согласно описанию ееинтерфейса. Должно быть в любом сообщении.Простой пример SOAP-сообщения приведен ниже.<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Header><t:Transactionxmlns:t="http://company.com/soap-headers/attrs"SOAP-ENV:mustUnderstand="1">5</t:Transaction></SOAP-ENV:Header><SOAP-ENV:Body><m:GetLastTradePrice xmlns:m="http://company.com/web-services/trading"><symbol>DEF</symbol></m:GetLastTradePrice></SOAP-ENV:Body></SOAP-ENV:Envelope>Кроме определения формата сообщений, протокол SOAP определяет процесс их обработкиразличными посредниками и получателями.ИменованиеРоль служб именования и каталогов в приложениях на основе Web-служб играют реестрыWeb-служб, организованные в соответствии со стандартом UDDI (Universal Description, Discoveryand Integration, универсальный стандарт описания, поиска и интеграции) [25].Существует всего лишь несколько универсальных реестров, регистрирующих любыедоступные в Интернет Web-службы.
Каждый из них поддерживается одной из крупных компаний,играющих заметную роль в развитии технологий разработки Web-служб. Такие реестры есть уIBM, Microsoft, SAP, NTT. К сожалению, они содержат не очень много записей о работающихWeb-службах. Гораздо больше специализированных реестров, предназначенных дляиспользования в рамках одной организации или компанией и ее партнерами.UDDI описывает структуру реестров Web-служб. Каждая запись в таком реестре являетсяXML-документом. Наиболее важная информация содержится в документах следующих видов.•businessEntity.
Такой документ описывает организацию (или лицо), предоставляющуюнабор Web-служб. В частности, он содержит название (имя), адрес, контакты, профиль, т.е.характеристику области ее (его) деятельности.•businessService. Это список Web-служб, предоставляемых некоторой организацией.•bindingTemplate. Описывает технические аспекты предоставляемых служб, в частности,адреса, к которым нужно обращаться, списки дополнительных описаний (tModels).•tModel (technical model). Содержит дополнительную информацию о службе, в частности,предоставляемые ею услуги, условия и ограничения ее использования, предоставляемыегарантии и пр.Помимо структуры реестра, UDDI определяет интерфейс для работы с ним, позволяющийпубликовать или удалять информацию о предоставляемых службах, изменять собственника служб,искать нужные службы по набору характеристик и т.д.ПроцессыПоскольку Web-службы считаются совершенно независимыми от реализации компонентами, ауправление процессами и потоками сильно зависит от платформы, в контексте Web-служб они нерассматриваются.
Можно считать, что каждый экземпляр Web-службы работает в своемотдельном процессе, к которому не имеют доступа все остальные экземпляры других Web-службили той же самой службы.Синхронизация и целостностьБазовые и общепризнанные стандарты построения Web-служб (WSDL, SOAP и UDDI) нерассматривают вопросы синхронизации работы нескольких Web-служб. В то же время, этивопросы очень важны при построении одних служб на базе других и разработке приложений изнаборов взаимодействующих Web-служб.Одной из попыток стандартизации протоколов совместной работы Web-служб являетсятехнология WS-Coordination (Web Services Coordination) [18,26]. Она предлагает набор протоколов,языков и инфраструктуру их использования, совместно позволяющих описывать и осуществлятьсинхронизацию и координацию нескольких Web-служб, которые работают над одной задачей.Для обеспечения целостности при совместной работе нескольких служб могут использоватьсятехнологии на основе стандартов WS-Transactions и WS-BusinessActivity [18,26], построенных набазе WS-Coordination.Задачи синхронизации могут решаться с помощью средств, помогающих строить приложенияна основе композиции Web-служб или при помощи их «оркестровки» (web servicesorchestration) [18].
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
