Архитектура распределенных систем программного обеспечения. Учебное пособие издано при поддержке образовательной программы Формирование

• Название: Учебное пособие издано при поддержке образовательной программы Формирование
• Анкор: Архитектура распределенных систем программного обеспечения
• Дата: 13.01.2023
• Размер: 1 Mb.
• Имя файла: mdwrbook.docx
• Тип: Учебное пособие; #885216
• страница: 25 из 36

Базовые технологии сетевых служб

Многие архитектуры сетевых служб основаны в настоящее время на трех компонентах: запрашивающем службу, поставщике служб и реестре служб, что весьма близко к модели "клиент/сервер" с явно выделенной службой именования (регистрации). Хотя такие архитектуры имеют упрощенный характер, с их помощью можно проиллюстрировать самые основные компоненты сетевых служб: способ взаимодействия (SOAP), способ описания (WSDL) и сервер именования (UDDI).

Первое,что необходимо для всех спецификаций – это общий синтаксис их описания. В случае сетевых служб таким общим синтаксисом является XML. Все стандарты основаны на XML, а структуры данных и форматы описываются как XML-документы.

Во-вторых, необходим механизм, позволяющий удаленным сайтам взаимодействовать друг с другом. Спецификация этого механизма имеет три аспекта: общий формат данных для сообщений, которые будут использоваться при обменах, соглашение по поддержке специфических форм взаимодействия (посылка сообщений или удаленный вызов процедуры) и правила работы с сообщениями в терминах транспортного протокола. Сетевые службы могут пользоваться разными транспортными протоколами. В некоторых случаях подходит TCP/IP, для туннельного проникновения через межсетевые экраны необходим протокол HTTP, а для асинхронной отправки сообщений применяется протокол SMTP. Это означает, что механизм взаимодействия должен уметь работать с разными транспортными протоколами, а сообщения надо уметь преобразовывать, подстраиваясь под правила любого из них. Механизм также должен оставлять все взаимодействующие приложения слабо связанными. Именно поэтому он базируется не на процедурных вызовах как в RPC (хотя такие вызовы нужно обеспечивать для тех приложений, которые изначально проектировались с ориентиром на RPC), а на обменах сообщениями. Сетевые службы основывают свои взаимодействия на SOAP.

Сообщения протокола SOAP используются как конверты, куда приложения вкладывают отправляемую информацию. Они состоят из заголовка и тела сообщения (Рис. 4.7). Заголовок может отсутствовать, но тело сообщения присутствует в нем обязательно. И заголовок, и тело состоят из блоков. Предполагается, что у каждого сообщения есть отправитель, конечный получатель и некоторое число промежуточных узлов, которые обрабатывают сообщение и переправляют получателю.

Основная информация размещается в теле сообщения, заголовок служит для обработки на промежуточных узлах или для дополнительных служб (транзакционное взаимодействие, безопасность и т. д.). Протокол SOAP может использоваться разными способами. В одном случае происходит асинхронный обмен документами. Второй случай отличается от этого тем, как построено тело сообщения. В нем непосредственно содержится вызов процедуры (имя вызываемого метода и параметры). Все дополнительные свойства вызова RPC (например, указание транзакционного контекста) содержатся в заголовке.


конвертзаголовок
Рис.4.7.ПримерXML-сообщенияпротоколаSOAP,имеющеговзаголовкеодинблок, предназначенный для обработки промежуточным узлом.

Сообщения, пересылаемые по протоколу SOAP, подчиняются правилам кодирования, определяющим, как конкретная структура будет представлена в XML. Клиент и сервер должны заранее договариваться о выбранном способе передачи параметров сообщений (удаленных процедур) – в виде вложенных элементов или значениями атрибутов исходных элементов (Рис. 4.8).

Промежуточные узлы, которые поочередно обрабатывают SOAP-

сообщения по мере их доставки получателю, обычно представляют собой

разные ярусы системной поддержки сетевой службы. Каждый узел может играть в процессе передачи ту или иную роль, в блоках заголовка сообщения можно указывать, для выполнения какой роли этот блок предназначен. Если блоку приписана роль "никто", блок не обрабатывается ни на одном узле на пути сообщения (блок можно только читать). Если блоку приписана роль "конечный получатель", ни один промежуточный узел обработкой блока заниматься не будет. Если блоку приписана роль "следующий", блок может обрабатываться на каждом узле, куда попадает сообщение (в том числе и на узле конечного получателя). Тело сообщения не имеет приписанной роли, оно всегда обрабатывается конечным получателем.




name="…"

… name="…" …

… type="…" …

… make="…"



/>

Рис.4.8.РазныеметодыкодированиясообщенийвXML.

Обработка блоков может быть самой разной (удаление из заголовка, внесение добавочной информации и т. д.). Блок может содержать признак, который требует обязательной обработки узлом с указанной ролью. Если такой признак не установлен, узел, играющий соответствующую роль, самостоятельно принимает решение обрабатывать данный блок или игнорировать его. Тело сообщения такого признака не имеет, но конечный получатель все равно должен его обработать или выработать ошибку.

Для того, чтобы механизм передачи сообщений SOAP функционировал (Рис. 4.9), необходимо связать его с транспортным протоколом, действующим в сети. Спецификация транспортного протокола, то есть привязка, определяет, как надо преобразовать сообщение к правилам транспортного протокола и как трактовать сообщение в терминах транспортного протокола (Рис. 4.10).

Привязка протокола SOAP к транспортному протоколу имеет и другую неявную функцию – функцию адресации. Указание адреса конечного получателя отсутствует в сообщении SOAP. Это связано с тем, что это сообщение является частью запроса HTTP или частью сообщения SMTP. В этих протоколах имеются необходимые средства для описания адресата (URL или поле "to"). Близкой проблемой является проблема маршрутизации. Протокол SOAP описывает путь доставки сообщений как набор узлов, механизма точной спецификации пути в сообщениях SOAP нет.

запрашивающий услугу реализация клиента

вызывает службу как локальную

переходник клиента

поставщик службы реализация службы

вызывает локальную процедуру реализации службы

переходник сервера

вызывает мотор SOAP для подготовки сообщения
мотор SOAP
упаковывает SOAP в HTTP и передает его HTTP клиенту для отправки поставщику
мотор HTTP

маршрутизатор просматривает сообщение, выбирает нужный переходник и передает сообщение ему

маршрутизатор SOAP
передает содержимое сообщения

SOAP маршрутизатору

сервер HTTP

Рис.4.9.ПростейшаяреализацияпротоколаSOAP.

Протокол SOAP может работать в асинхронном режиме, пригодном для взаимодействия слабосвязанных партнеров. Вместо прямых вызовов при этом запросы отправляются с помощью системы очередей. Слабосвязанное взаимодействие обычно приводит к обмену сообщениями в стиле документов, выполняемому асинхронно и автоматически. Ответы передаются также асинхронно. Взаимодействующие объекты (в прежней терминологии – серверы и клиенты) остаются максимально независимыми друг от друга, что позволяет проводить их независимую разработку, сопровождение и внедрение. Обычно при этом в качестве транспортного протокола используется SMTP.

В-третьих, после выбора синтаксиса описаний и протокола взаимодействия для посылки сообщений нужна возможность описывать службы (и их интерфейсы) стандартным образом. Роль, отведенную в традиционных системах языкам IDL, играет для сетевых служб основанный на XML язык описания WSDL. Интерфейс описывается в терминах методов, которые поддерживаются сетевой службой, а каждый метод может принимать одно сообщение на входе и возвращать другое сообщение на выходе. В терминах RPC эти сообщения содержат входные и выходные параметры вызовов процедур. Используется WSDL так же, как и IDL. Файлы с описаниями транслируются в соответствующий язык программирования, при этом генерируются переходники и промежуточные слои, делающие обращения к сетевым службам прозрачными. Инфраструктура сетевой службы использует WSDL и SOAP для конструирования заместителей объектов на сторонах поставщика и

потребителя, поэтому разработчики могут программировать свои приложения, как если бы они выполняли локальные вызовы.





Рис.4.10.ВызовудаленнойпроцедурысиспользованиемпротоколаSOAPповерх HTTP.

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

платформой. Сетевые службы делаются доступными посредством протоколов, а их надо специфицировать на WSDL.

version= "1.0"?>


targetNamespace="http://example.com/procurement/definitions" xmlns:tns="http://example.com/procurement/definitions" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/" >

Рис.4.11. Примерспецификациинаязыке WSDL.

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

Чтобы иметь возможность решать все проблемы, возникающие при описании служб, спецификации WSDL (Рис.4.11) делят на две части –

абстрактную (концептуально похожую на традиционные описания на IDL) и конкретную (определяющую протоколы связывания и другую информацию).

Абстрактная часть построена на определениях типов портов, аналогичных интерфейсам традиционных IDL. Каждый тип порта есть логический набор связанных с портом операций. Каждая операция определяет простой обмен сообщениями, то есть коммуникационными единицами, представляющими обмен данными в одной логической передаче. Чтобы обмениваемые данные правильно интерпретировались на обоих концах взаимодействия, необходимо определить их типы. Все эти понятия определяются на XML.

Сообщения в WSDL представляют собой текстовые документы, разделенные на части, каждая из которых характеризуется именем и типом, который ссылается на тип, обычно определенный с помощью схемы XML. Например, вызывая процедуру с двумя параметрами, надо определить сообщение из двух частей, одна из которых будет содержать, например, целое, а другая, например, вещественное число. Эти типы входят в стандартный набор спецификаций схем XML, а если бы надо было использовать параметр сложной структуру, потребовалось бы дополнительно определить тип такой структуры.

В WSDL имеется четыре типа базовых операций: односторонние, уведомление, запрос/ответ и просьба/ответ. Первые два типа операций связаны с одиночными сообщениями, выполняемыми асинхронно, а последние два – с синхронными парными сообщениями. Сообщения типа уведомление и просьба/ответ инициируются службой, а других типов – клиентом.

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

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

могут кодироваться в сообщения по разным правилам, а одни и те же сообщения могут пересылаться по разным протоколам.

Разделение на абстрактную и конкретную части спецификации WSDL имеет очень важное следствие – спецификации, описывающие абстрактную часть, становятся переиспользуемыми. Это означает, что одни и те же абстрактные спецификации могут использоваться с различными привязками к протоколам и по разным сетевым адресам. Возможность как SOAP, так и WSDL использовать много разных транспортных привязок серьезно повышает степень стандартизации сетевых служб, поскольку отрывает описания от различных реализаций.

Конкретная часть интерфейса WSDL определяется с помощью трех конструкций:

• 
  Интерфейсное связывание, определяющее тип кодирования сообщений и привязку к протоколу для всех операций и сообщений, заданных для данного типа порта. Интерфейсное связывание может определять, что сообщения некоторой операции должны пересылаться с использованием протокола SOAP с привязкой к протоколу HTTP. Здесь же специфицируются правила кодирования, на основе которых сообщения сериализуются в XML.
  
• 
  Портысоединяют информацию интерфейсного связывания с сетевыми
  

адресами, специфицируемыми с помощью URI. В традиционных системных платформах этого делать нет нужды, но для сетевых служб – необходимо.

• 
  Службы, являющиеся логическими группами портов. По крайней мере,
  

в принципе, это означает, что некоторая WSDL-служба может оказаться доступной в Интернете распределенной сразу по нескольким адресам. На практике наиболее частой оказывается ситуация, в которой в одной службе группируются близкие по семантике порты, расположенные в одном месте. Часто также в службу включаются порты одного типа, но имеющие привязки к разным протоколам.

Одним из следствий структур данных, имеющихся в WSDL, является дальнейшее слияние понятий "клиент" и "поставщик службы". Как и всякий язык описания интерфейсов WSDL может использоваться в разных целях, важнейшими из которых можно считать такие:

• 
  Традиционное использование в качестве языка описания службы.
  
• 
  Использование в качестве входных данных для трансляторов переходников и других программных инструментов, которые по описаниям на WSDL могут генерировать переходники и другие
  

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

Поскольку сетевые службы применяются для демонстрации внутренних операций через Интернет, часто при начале разработки службы приложения, на которые она опирается, уже существуют. Это позволяет автоматически генерировать тексты на WSDL по уже имеющимся описаниям прикладных программных интерфейсов. На Рис.

4.12 изображена описанная схема, принципиально отличающаяся от схемы работы со спецификацией CORBA только отсутствием общей системной платформы.

В-четвертых, имея полное описание сетевой службы, чтобы действительно обратиться к сетевой службе, ее нужно отыскать. Чтобы службы имели глобальный характер и вызывали всеобщий интерес, процесс опубликования сведений о них и их локализация должны быть стандартизованы. Потребители должны иметь возможность искать интересующие их службы, понимать их свойства (интерфейсы и URI, по которым они могут оказаться доступными). Это делает важным стандартизацию реестра сетевых служб.





Рис. 4.12. Документы WSDL могут генерироваться на основе прикладных программныхинтерфейсов.Пунктиромпоказаныдействиястадииразработки.

Проект универсальныхсредствописания,обнаруженияиинтеграции

(UDDI) как раз и представляет собой такой стандарт. Фактически он

состоит из двух частей: реестра и прикладного программного интерфейса. Реестр (или регистр) эквивалентен серверу именования, имеющемуся в любой системной платформе. Это то место, где публикуются описания служб, которые могут затем отыскиваться в каталогах реестра. Прикладной интерфейс UDDI (Рис. 4.13) определяет, как опубликовать службу, какая информация необходима для регистрации службы, как делать запросы к службе.





Рис.4.13.ПоставщикисообщаютосвоихслужбахвреестрUDDI.Клиенты(вовремя разработки или выполнения) ищут службы в реестре, а затем обращаются к ним.

Поиск информации в реестре может преследовать две цели: во- первых, необходимо понять, что надо сделать, чтобы написать клиентскую программу для доступа к службе, во-вторых, после того, как эта клиентская программа написана, ей надо обеспечить возможность динамического поиска службы. Реестр UDDI также может использоваться в качестве универсального бизнес реестра, где каждый производитель программного обеспечения может свободно и бесплатно регистрировать свою продукцию, а пользователи могут искать интересующие их программы. Информация, занесенная в реестр UDDI, может группироваться там в алфавитном порядке имен предприятий, поставляющих сетевые службы для всеобщего использования, по

тематике, к которой относится деятельность предприятий поставщиков и сами службы, а также по способам вызова сетевых служб.

При занесении в реестр сетевая служба сопровождается различной информацией:

• 
  предприятиевключает сведения об имени компании, ее адресе и другую контактную информацию.
  
• 
  службаописывает набор сетевых служб, предлагаемых данным
  

предприятием. Предприятиеможет поставлять несколько служб, но

службаможет поставляться только одним предприятием.

• 
  шаблон использованияописывает техническую информацию, необходимую для использования конкретной службы: адрес, по которому доступна сетевая служба, а также детализированный набор ссылок на документы (технические модели), где описываются интерфейсы служб и другие их свойства. Одна служба может содержать несколько шаблонов использования, но шаблон может относиться только к одной службе.
  
• 
  техническаямодельможет содержать произвольную информацию:
  

WSDL-интерфейс службы, классификацию, протокол взаимодействия, сведения о семантике службы. На технические модели могут ссылаться любые объекты реестра (предприятия, службы, шаблоны), они не привязаны ни к одному из них.

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

Структура технической модели очень проста (Рис. 4.14). Фактическое описание находится в документах, на которые в модели только приводятся ссылки. Содержимое обзорных документов обычно не структурировано и предназначено для чтения людьми. Каждая техническая модель, зарегистрированная в реестре, имеет уникальный ключ, который помогает разработчикам получать доступ к моделям и, таким образом, получать информацию, нужную для разработки клиентских программ. Зная уникальный ключ моделей, разработчики имеют возможность организовывать динамический поиск служб, ссылающихся на них.

Технические модели могут использоваться не только для описания интерфейсов и протоколов, но также для идентификации и классификации. Каждый может определить собственную классификационную схему (например, по географическим признакам). Полное описание классификации помещается в обзорные документы, а в технических моделях остаются только классификационные признаки, которые можно использовать как поисковые ключи. Статически или динамически можно искать службы, относящиеся к данной классификационной категории (например, искать предприятие или службу, ссылающиеся на модель 211 и имеющие классификационный признак "Москва").

tModelKey="uddi:uddi.org:v3_publication">

UDDI Publication API_V3.0
http://uddi.org/wsdl/uddi_api_v3_binding.wsdl#UDDI_Publication_SoapBinding http://uddi.org/pubs/uddi_v.3.htm#PubV3

uddi-org:publication_v3

обзорный документ (ссылаетсянаспецификацию WSDL и спецификацию API)

классификационнаяинформация(специфицирует,чтоданная техническаямодельимеетотношениекXML,WSDLиSOAP)

Рис.4.14.ПримертехническоймоделивреестреUDDI,описывающейприкладной программный интерфейс самого реестра UDDI.

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

Рис.4.15.ВзаимодействиесреестрамиUDDIимеждуними.

Работу с реестром UDDI могут проводить пользователи разных типов: поставщики служб, публикующие сведения о них, клиенты, ищущие службы для выполнения собственных задач, и другие реестры, осуществляющие обмен информацией с данным реестром (Рис. 4.15). Для разных типов пользователей реестры поддерживают разные точки входа, взаимодействие с которыми осуществляется по протоколу SOAP обменом XML-документами.

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

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