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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Работа сетевой службы

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

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

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

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

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

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