Распределенная система - это набор независимых вычислительных машин, представляющийся их пользователям единой объединенной системой. Не смотря на то, что все компьютеры автономны, для пользователей они представляются единой системой.
К основным характеристикам распределенных систем:
1. От пользователей скрыты различия между компьютерами и способы связи между ними. То же самое относится и к внешней организации распределенных систем.
2. Пользователи и приложения единообразно работают в распределенных системах, независимо от того, где и когда происходит их взаимодействие.
Распределенные системы должны также относительно легко поддаваться расширению, или масштабированию. Эта характеристика является прямым следствием наличия независимых компьютеров, но в то же время не указывает, каким образом эти компьютеры на самом деле объединяются в единую систему.
Для того чтобы поддержать представление системы в едином виде, организация распределенных систем часто включает в себя дополнительный уровень программного обеспечения, находящийся между верхним уровнем, на котором находятся пользователи и приложения, и нижним уровнем, состоящим из операционных систем (рисунок 1.11).
Соответственно, такая распределенная система обычно называется системой промежуточного уровня (middleware). Отметим, что промежуточный уровень распределен среди множества компьютеров.
К особенностям функционирования распределенных систем относятся:
· наличие большого количества объектов;
· задержки выполнения запросов (так если локальные вызовы требуют порядка пары сотен наносекунд, то запросы к объекту в распределенных системах требует от 0.1 до 10 мс);
· некоторые объекты могут не использоваться на протяжении длительного времени;
· распределенные компоненты выполняются параллельно, что приводит к необходимости согласования выполнения;
· запросы в распределенных системах имеют большую вероятность отказов;
· повышенные требования к безопасности.
В связи наличием повышенных задержек интерфейсы в распределенной системе должны быть спроектированы так, чтобы снизить время выполнения запросов. Это можно достичь путем снижения частоты обращения, а также укрупнением выполняемых функций.
Для борьбы с отказами клиенты обязаны проверять факт выполнения запросов сервером. Безопасность в распределенных приложениях может быть повышена путем контроля сеансов связи (аутентификация, авторизация, шифрование данных).
Архитектура Web-приложений (Web -сервиса) широко применяется в настоящее время. Web-сервис – приложение, доступное через Интернет. Оно предоставляет услуги, форма которых не зависит от поставщика услуг, так как используется универсальная платформа функционирования и универсальный формат данных (XML). В основе Web –сервисов лежат стандарты, определяющие форматы и язык запросов, а также протоколы поиска этих сервисов в Интернете. Схема доступа к базе данных через Интернет показана на рис.1.12.
 |
| Рисунок 1.12 – Схема доступа к серверу СУБД через Интернет |
В настоящее время существуют три различных технологии, поддерживающие концепцию распределенных объектных систем: EJB, DCOM CORBA.
Основная идея, лежащая в разработке технологии EJB (Enterprise Java Beans ) – создать такую инфраструктуру для компонентов, чтобы они могли бы легко вставляться и удаляться из серверов, тем самым повышая или снижая функциональность сервера. EJB-компоненты являются Java-классами и могут работать на любом EJB-совместимом сервере даже без перекомпиляции. Основными целями EJB-технологии является:
1. Облегчить разработчикам создание приложений, избавив их от необходимости реализовать с нуля такие сервисы, как транзакции, нити, загрузки и др. Разработчики могут сконцентрировать свое внимание на описании логики своих приложений, перекладывая задачи по хранению, передаче и безопасности данных на EJB-систему.
2. Описать основные структуры EJB-системы и интерфейсы взаимодействия между ее компонентами.
3. Освободить разработчика от реализации EJB-объектов за счет наличия специального кодогенератора.
Благодаря используемойJava-модели, EJB является относительно простым и быстрым способом создания распределенных систем.
Технология DCOM (Distributed Component Object Model ) - программная архитектура, разработанная компанией Microcoft для распределения приложений между несколькими компьютерами в сети. Программный компонент на одном из компьютеров может использовать DCOM для передачи сообщений к компоненту на другом компьютере. DCOM автоматически устанавливает соединение, передает сообщение и возвращает ответ удаленного компонента. Способность DCOM связывать компоненты позволила Microcoft наделить Windows рядом дополнительных возможностей, в частности, реализовать сервер Microsoft Transaction Server, отвечающий за выполнение транзакций баз данных через Интернет.
Назовем сервисом (service) ресурс, реализующий бизнес-функцию, обладающий следующими свойствами:
является повторно используемым;
определяется одним или несколькими явными технологически-независимыми интерфейсами;
слабо связан с другими подобными ресурсами и может быть вызван посредством коммуникационных протоколов, обеспечивающих возможность взаимодействия ресурсов между собой.
Веб-сервисом называется программная система, идентифицируемая строкой URI , чьи интерфейсы и привязки определены и описаны посредством XML . Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью Интернет-протоколов.
Web-сервисы - это новая перспективная архитектура, которая обеспечивает новый уровень распределённости. Вместо разработки или приобретения компонентов и их встраивания в ИС предлагается покупать время их работы и формировать программную систему, которая осуществляет вызовы методов из компонентов, которые принадлежат и поддерживаются независимыми провайдерами. Благодаря Web-сервисам функции любой программы в сети могут стать доступными через Интернет. Самый простой пример Web-сервиса - система Passport на Hotmail , которая позволяет создать аутентификацию пользователей на собственном сайте.
В основе Web-сервисов лежат следующие универсальные технологии:
TCP/IP – универсальный протокол, понимаемый всеми сетевыми устройствами, от мэйнфреймов до мобильных телефонов и PDA;
HTML – универсальный язык разметки, применяемый для отображения информации устройствами пользователей;
XML (Extensible Markup Language)– универсальный язык для работы с любыми типами данных.
Универсальность этих технологий – основа для понимания веб-сервисов. Они основаны только на общепринятых, открытых и формально независимых от поставщиков технологиях. Только посредством этого достигается главное преимущество веб-сервисов как концепции построения распределенных ИС – их универсальность, т. е. возможность применения для любых операционных систем, языков программирования, серверов приложений и т. д.
Таким образом, веб-сервисы решают исходную задачу – задачу интеграции приложений различной природы и построения распределенных ИС . В этом и заключается основное принципиальное отличие веб-сервисов от предшественников.
Веб-сервисы - это XML-приложения, осуществляющие связывание данных с программами, объектами, базами данных либо с деловыми операциями целиком. Между веб-сервисом и программой осуществляется обмен XML-документами, оформленными в виде сообщений. Стандарты веб-сервисов определяют формат таких сообщений, интерфейс, которому передается сообщение, правила привязки содержания сообщения к реализующему сервис приложению и обратно, а также механизмы публикации и поиска интерфейсов.
XML (англ. e X tensible M arkup L anguage - расширяемыйязык разметки ; произносится [икc-эм-эль ]). РекомендованКонсорциумом Всемирной паутины (W3C). Спецификация XML описывает XML-документы и частично описывает поведение XML-процессоров (программ, читающих XML-документы и обеспечивающих доступ к их содержимому). XML разрабатывался как язык с простым формальнымсинтаксисом , удобный длясоздания и обработки документов программам и одновременно удобный для чтения и создания документов человеком, с подчёркиванием нацеленности на использование в Интернете. Язык называется расширяемым, поскольку он не фиксирует разметку, используемую в документах: разработчик волен создать разметку в соответствии с потребностями к конкретной области, будучи ограниченным лишь синтаксическими правилами языка. Сочетание простого формального синтаксиса, удобства для человека, расширяемости, а также базирование на кодировкахЮникод для представления содержания документов привело к широкому использованию как собственно XML, так и множества производных специализированных языков на базе XML в самых разнообразных программных средствах.
Стандартные XML-приложения
XML можно использовать не только для описания отдельного документа. Индивидуальный пользователь, компания или комитет по стандартам может определить необходимый набор элементов XML и структуру документа, которые будут применяться для особого класса документов. Подобный набор элементов и описание структуры документа называют XML-приложением или XML-словарем . Например, организация может определить XML-приложение для создания документов, описывающих молекулярные структуры, мультимедиа презентации или содержащих векторную графику.
Веб-сервисы могут использоваться во многих приложениях. Независимо от того, откуда запускаются веб-сервисы, с настольных компьютеров клиентов или с переносных, они могут использоваться для обращения к таким интернет-приложениям, как система предварительных заказов или контроля выполнения заказов.
Веб-сервисы пригодны для В2В-интеграции (business-to-business), замыкая приложения, выполняемые различными организациями, в один производственный процесс. Веб-сервисы также могут решать более широкую проблему интеграции приложений предприятия (Enterprise Application Integration, EAI) , осуществляя связь нескольких приложений одного предприятия с несколькими другими приложениями. Во всех перечисленных случаях технологии веб-сервисов являются "связующим звеном", объединяющим различные части программного обеспечения.
Как видно из рис. 1, веб-сервисы представляют собой оболочку, обеспечивающую стандартный способ взаимодействия с прикладными программными средами, такими как системы управления базами данных (СУБД), .NET, J2EE (Java2 Platform, Enterprise Edition), CORBA (Common Object Request Broker Architecture), посредники пакетов планирования ресурсов предприятия (Enterprise Resource Planning, ERP), брокеров интеграции и пр.
Рис.1. Веб-сервисы взаимодействуют с прикладными системами
Интерфейсы веб-сервисов получают из сетевой среды стандартные XML-сообщения , преобразуют XML-данные в формат, "понимаемый" конкретной прикладной программной системой, и отправляют ответное сообщение (последнее - не обязательно). Программная реализация веб-сервисов (базовое программное обеспечение, нижний уровень) может быть создана на любом языке программирования с использованием любой операционной системы и любого связующего программного обеспечения (middleware ).
Простой пример: поиск информации
В настоящее время большинство сервисов вызываются по Сети посредством ввода данных в HTML-формы и отправки этих данных сервису путем добавления их в строку унифицированного указателя информационного ресурса (Uniform Resource Locator, URL ):
http://www.google.com/search?q=Skate+boots&btnG=Google+Search
Этот пример иллюстрирует простоту веб-взаимодействия (например, поиска, покупки акций или запроса маршрута движения), где параметры и ключевые слова внедряются непосредственно в URL. В данном случае представлен простой запрос поиска skate boots (ботинки с коньками) в строке обращения к поисковой машине Google. Ключевое слово search (искать) представляет сервис, к которому будет осуществлено обращение, а параметр Skate+boots является строкой поиска, которая была введена в HTML-форме на странице веб-сайта Google. Сервис поиска Google передаст этот запрос к различным поисковым машинам, которые вернут список URL для страниц, на которых имеется соответствие параметру поиска Skate+boots. Данный малоэффективный способ поиска в Сети полностью основан на установлении соответствия указанной текстовой строки и индексированных HTML-страниц.
XML - лучший способ отправки данных. XML предоставляет значительные преимущества при передаче данных через Интернет. Теперь предыдущий запрос можно представить в виде XML-документа :
xmlns:s="www.xmlbus.com/SearchService"> Отправка запроса
в виде XML-документа
имеет следующие преимущества: возможность
определения типов данных и структур,
большую гибкость и расширяемость. XML
может представлять структурированные
данные или данные определенного типа
(например, допустимо указывать значение
поля size (размер) как в виде строки цифр,
так и в форме числа с плавающей точкой)
и содержать больший объем информации,
чем это допускает URL. Данный пример
представлен в форме SOAP-сообщения (Simple
Object Access Protocol) - стандартной формы обмена
XML-сообщениями - одной из технологий,
лежащих в основе веб-сервисов. В
SOAP-сообщении имя запрашиваемого сервиса
и входные параметры представлены в виде
отдельных XML-элементов. Рассматриваемый
пример также иллюстрирует использование
пространства имен XML (xmlns:), еще одного
важного элемента веб-сервисов. Благодаря
тому, что XML-документы поддерживают
разные типы данных, сложные структуры
и объединение схем, современные технологии
веб-сервисов обеспечивают значительное
преимущество над существующими
возможностями обращения к программным
приложениям посредством HTML и URL. 01.06.2006
Майкл Папазоглоу, Виллем-Ян ван ден Хьювел
Решения на базе сервис-ориентированной архитектуры позволяют использовать преимущества распространенных сервисов и обеспечивают взаимодействие бизнес-процессов разных организаций. Однако приложения на основе Web-сервисов могут охватывать несколько компьютеров, операционных систем, языков и предприятий Рассмотрим связи между управлением Web-сервисами и традиционными распределенными системами, а также подходы к управлению Web-сервисами и их основообразующие архитектурные концепции. Сегодня Web-сервисы - самая популярная парадигма распределенных вычислений. Принимая на вооружение сервис-ориентированные архитектуры
(service-oriented architecture, SOA) на базе Web-сервисов, предприятия могут гибко решать внутри- и межкорпоративные проблемы интеграции. Web-сервисы начинают играть все более важную роль в жизни предприятий, и контроль над ними становится насущной необходимостью. Направляя развитие Web-сервисов, можно получать ясное представление об их работе, обоснованно принимать управленческие решения и осуществлять управляющие воздействия для адаптации поведения приложений на их базе. Для всего этого нужны распределенные средства управления Web-сервисами. При управлении распределенными системами наборы инструментов и утилиты контролируют их действия, что облегчает принятие управленческих решений и внесение изменений в поведение систем. По традиции основное внимание до сих пор уделялось управлению последовательными уровнями новых технологий, которые вводились в эксплуатацию в распределенных средах. Однако такие методы не отвечают корпоративным требованиям, поскольку не соответствуют бизнес-функциям. Кроме того, многие инфраструктуры системного управления не обеспечивают контроля над соглашениями об уровне обслуживания
(service level agreement, SLA) или получения от приложений на базе Web-сервисов информации об обслуживании, необходимой для устранения ошибок. Эксплуатируя решения на базе SOA, ИТ-администраторы должны непрерывно анализировать модели использования сервисов, критерии и метрики SLA, данные об отказах. Без такой информации довольно трудно понимать причины проблем с производительностью и стабильностью приложений SOA. В частности, предприятия должны контролировать и измерять уровни обслуживания распределенных и консолидированных процессов. Наблюдая за бизнес-процессами, ИТ-администраторы могут выявлять благоприятные возможности и диагностировать проблемы по мере их возникновения. Благодаря этому Web-сервисы, поддерживающие конкретную бизнес-задачу, выполняются в соответствии с требованиями SLA. Поставщики средств управления предлагают измерительные инструменты только для конечных точек и узлов-посредников SOAP или серверов UDDI. Обеспечиваемое данными инструментами представление об использовании Web-сервисов приложениями страдает неполнотой: ему не хватает жизненно важной информации о состоянии и характеристиках Web-сервисов. Для получения таких сведений Web-сервисы должны стать измеримыми и более управляемыми. Этого можно достичь только путем стандартизации, которая обеспечит сквозную управляемость всех частей долгоживущей многошаговой транзакции, охватывающей несколько приложений, предприятий и действующих лиц. Ожидается, что в ближайшем будущем управление Web-сервисами станет жизненно важным компонентом распределенных приложений. Мы обсудим распределенные Web-сервисы и проблемы управления ими, исследуем концепции SOA и их связь с ключевыми требованиями. Система управления распределенными приложениями направляет и контролирует приложение в течение его жизненного цикла - от установки и конфигурирования до сбора показателей и настройки выполнения с учетом конкретных требований. Функциональные возможности системы должны охватывать все эксплуатационные действия (включая запуск и остановку процессов, изменение маршрута операций и даже перезагрузку серверов), а также диагностические функции типа трассировки приложений и редактирования сообщений. Управление распределенной вычислительной средой требует надежных эффективных процессов как для администрирования системы, так и для управления сетью. Такие процессы обеспечиваются программами, инструментами и утилитами, которые дают администраторам представление о состоянии систем и сетей, приложений и моделей поведения. Хотя в традиционных распределенных средах наборы инструментов и утилиты действуют уже много лет, придется разработать эквивалентные технологии для сложного мира слабосвязанных приложений на базе Web-сервисов. Использование Web-сервисов для организации доступа к унаследованным приложениям и их расширения дает предприятиям явные технологические преимущества. Объединение сервисов в дискретные логические компоненты, непосредственно увязанные с бизнес-функциями, помогает получить еще более существенные плюсы. Компании могут «оркестровать» такие сервисы во многих конфигурациях для поддержки нескольких бизнес-процессов. Оркестрованная реализация сервисов формирует логическую сеть услуг, наложенную поверх инфраструктуры (в том числе программной среды, серверов, унаследованных приложений, внутренних систем) и физической сети связи. По мере разрастания такой сети Web-сервисов ее работа и производительность становятся жизненно важными для ключевых бизнес-операций. Поставщик и покупатель должны договориться об особенностях сервиса. В приложениях, объединяющих географически распределенные Web-сервисы, такой договор составляет суть корпоративного соглашения SLA. Цель состоит в том, чтобы улучшить фактическое качество услуг (quality of experience, QoE) для внутренних или внешних клиентов. QoE создает единую основу для измерения качества продукта или услуги, в том числе производительности, пред- и послепродажного обслуживания, степени удовлетворенности клиента. Поставщик часто должен заключить и контролировать выполнение несколько внутренних (для бизнеса или конечных пользователей) либо внешних (для поставщиков услуг, партнеров, аутсорсеров и т.д.) соглашений SLA. Вообще говоря, бизнес-процесс предполагает несколько соглашений SLA, управляющих взаимосвязанными услугами в интересах конечного пользователя. Для каждого уровня SLA одну из сторон можно считать поставщиком, а другую - потребителем. Обеспечение качественного сервис-ориентированного управления требует измерения ключевых показателей эффективности
(Key Performance Indicator, KPI) приложений и услуг. Поставщик услуг может рассмотреть общие KPI перед их применением к конкретным приложениям. К общим KPI бизнес-приложений относятся доступность и производительность сервиса, время отклика и скорость выполнения транзакций, время простоя и безопасность. Поставщик должен знать, соответствуют ли его услуги установленным показателям KPI, и бить тревогу в случае «накладок». Ему необходимо установить для сервиса целевые показатели KPI, научиться их измерять и анализировать, а также отчитываться о KPI, отличающихся от целевых. Web-сервисы не могут самостоятельно выполнять эти сервис-ориентированные функции управления. Поэтому есть острая необходимость в инструментах контроля над Web-сервисами и управления ими. Циклическое, замкнутое управление и мониторинг состояния ресурсов реализуется с помощью технологий системного управления, позволяющих реагировать на ситуации, непрерывно возникающие в объекте управления. Мы можем рассматривать инфраструктуру управления как концептуальную архитектуру, которая объединяет разные компоненты, в том числе ресурсы, менеджеров ресурсов и консоль управления (рис. 1
). Консоль управления отображает информацию через интерфейс, позволяющий администраторам контролировать ресурсы и изменять их поведение. Интерфейс управления использует такие механизмы, как журналы, события, команды, интерфейсы API и файлы конфигурации . Как показано в левой нижней части рис. 1, интерфейс также применяет метаданные о свойствах ресурса: Интерфейсы управления также требуют сведений о взаимосвязях ресурса с окружающей средой, в том числе пользователями и компьютерами. Наконец, интерфейс получает информацию о текущем состоянии управляемого ресурса и событиях управления (уведомлениях), которые могут произойти, если ресурс подвергнется существенным изменениям состояния. Широко применяются несколько стандартных платформ распределенного управления. Среди наиболее известных следует упомянуть SNMP (Simple Network Management Protocol - «простой протокол управления сетью», www.ietf.org/rfc/rfc1157.txt
), CIM (Common Information Model - «общая информационная модель», www.dmtf.org/standards/cim/
), WBEM (Web-Based Enterprise Management - «технология корпоративного управления на базе Web», www.dmtf.org/standards/wbem/
) и OMI (Open Management Interface - «открытый интерфейс управления», www.openview.hp.com/
downloads/try_omi_0001.html
). SNMP, предложенный IETF, - это протокол прикладного уровня, который облегчает обмен управляющей информацией между сетевыми устройствами . Элементами сети SNMP являются устройства (такие, как хосты, шлюзы и терминальные серверы), снабженные агентами. Последние исполняют функции, запрашиваемые станциями управления сетью. Платформа SNMP позволяет сетевым администраторам управлять пропускной способностью сети, находить и устранять неисправности, планировать наращивание сети. Фактически SNMP является отраслевым стандартом сетевого управления. Модель CIM, разработанная рабочей группой по управлению распределенными системами DMTF (Distributed Management Task Force), описывает все управляемые элементы предприятия, в том числе системы, сети и приложения. CIM не зависит от реализации и позволяет управляющим приложениям собирать необходимые данные из разных источников. Группа разработала также WBEM - набор стандартов управления и технологий Internet, нацеленных на унификацию управления корпоративной вычислительной средой. Опираясь на WBEM, можно построить интегрированный набор инструментов на базе стандартов, использующих преимущества развивающихся Web-технологий. Интерфейс OMI, совместно разработанный компаниями Hewlett-Packard и webMethods , предоставляет поставщикам систем управления и другим заинтересованным сторонам легкий открытый доступ к управлению ресурсами, связанными с платформой интеграции и к относящимся к ней бизнес-процессам. OMI позволяет управляющим инфраструктурам с помощью программного интерфейса получить доступ к управлению интегрированной платформой бизнес-процессов. Через этот интерфейс пользователи могут управлять набором объектов OMI, представляющих доступные ресурсы. Когда традиционные централизованные управляющие приложения переходят к распределенным динамическим архитектурам SOA, они могут более гибко выполнять основные функции управления. В рамках SOA платформа управления Web-сервисами WSMF (Web Services Management Framework) обеспечивает поддержку обнаружения, анализа, защиты и обращения к ресурсам, а также выполнение функций управления и поддержку инфраструктурных управляющих сервисов и наборов инструментов. Те же технологии, определяющие бизнес-процессы и высокоуровневые процессы управления ИТ, теперь могут согласовываться с технологиями менеджеров ресурсов, инфраструктурных сервисов и управления ресурсами. Все коммуникации между поставщиками и потребителями услуг осуществляются с помощью стандартизированных сообщений SOAP, которые облегчают управление Web-сервисами. Разработчики могут использовать сообщения SOAP для пометки начальных и конечных точек сервисных транзакций. Кроме того, источник и получатель сообщения SOAP легко идентифицируются, поэтому достаточно получить детальные критерии качества работы приложений, охватывающих платформы и предприятия. Управлять инфраструктурой Web-сервисов удается не всегда, но организации могут контролировать поток сообщений SOAP, которыми обмениваются приложения. Действительно, анализ трафика и изменение сообщений SOAP (которые могут быть перехвачены во многих точках сети приложений, связанных через Web-сервисы) являются основными принципами управления Web-сервисами. Контейнеры для сервисов облегчают построение среды потока сообщений типа «запрос-ответ». Подобно контейнерам J2EE, контейнеры для Web-сервисов подразумевают физическое проявление конечной точки абстрактного сервиса и обеспечивают реализацию сервисного интерфейса. ИТ-администраторы могут вводить средства управления сервисами в конвейер SOAP, используя агентов либо посредников. Управление сервисами с помощью агентов соответствует контейнерному стилю управления. В данном случае «родной» для платформы контейнер Web-сервиса имеет возможности управления. С архитектурной точки зрения выгода этой модели состоит в следующем. Агент способен использовать преимущества конфигурации конкретной инфраструктуры контейнера бизнес-приложений (сервера приложений), который администраторы могут кластеризовать и защищать для достижения требуемого уровня обслуживания. В отличие от подхода с использованием агентов, который непосредственно связывает управляющие серверы Web-сервисов с контейнерами, посредник (или брокер) действует как клиентская конечная точка, а затем передает запрос фактической конечной точке сервиса (рис. 2
). Администраторы развертывают средства управления на уровне посредника, что позволяет осуществлять управление и контроль. Посредническая модель полностью отделена от узлов Web-сервисов и может использоваться в любой среде. Через узел-посредник допускается направлять сервисы с нескольких платформ, что также облегчает централизованное конфигурирование и управление. Посредническая модель упрощает администрирование и техническую поддержку, она не подразумевает установки агента на каждом отдельном узле Web-сервисов. Однако посредники требуют реконфигурации сетевого адреса. Кроме того, при отсутствии инфраструктуры кластеризации посредников Web-сервисов они могут стать отдельными точками неисправности и таким образом создать проблемы в средах, требующих высокой надежности. Для управления услугами платформа WSMF использует свойства управляемости архитектурных ресурсов.
Они определяют стандартные схемы, метаданные и интерфейсы языка описания Web-сервисов WSDL (Web Services Description Language), описывающие поведение ресурсов, с помощью которого последние обеспечивают доступ к информации об управляемости . Как правило, ресурсы реализуют только применимые, а не все свои стандартные свойства управляемости, которые включают в себя эксплуатационный статус, метрику и отношения. Свойства управляемости реализуются через информационную модель управляемости, которая представляет управляемость ресурса и сопутствующую информацию, такую как состояние, конфигурация и отношения . Платформа управления сервисами использует информацию из этой модели, которая может, например, указывать, что заголовок сообщения SOAP содержит цифровое удостоверение личности клиента. WSMF извлекает эти сведения и задействует для идентификации клиента (например, при подсчете сообщений SOAP определенного клиента для конкретного Web-сервиса). WSMF применяет инфраструктурные сервисы управления для определения стандартных интерфейсов к общедоступным функциям инфраструктуры . К числу таких сервисов относятся измерение, посреднические функции при обработке метрик и событий, мониторинг, сканирование системы, реализация политик и мосты между моделями. Стандартные интерфейсы управления позволяют выполнять утилиты, процессы и приложения более высокого уровня, такие как управление готовностью и производительностью, оптимизация, планирование загрузки, формирование счетов, управление конфигурацией, защита ресурсов, выявление проблем, бизнес-анализ. Системы управления сервисами управляют ресурсами, используя их интерфейсы, сервисы инфраструктуры и другие доступные инструменты. Эти механизмы поддерживают ряд функций, в том числе простой мониторинг, контроль, автоматическую настройку и восстановление, управление качеством, сквозное управление бизнес-процессами, предоставление системных ресурсов и услуг на основе политик. Они также обеспечивают интерфейсы и контент для консолей управления. Web-сервис является управляемым, если его свойства управляемости доступны через стандартные интерфейсы управления, подобные функциональным интерфейсам . Интерфейсы управления отличаются лишь тем, что имеют семантику, связанную с управлением, и их использует система управления Web-сервисами, а не клиент. На рис. 3
показаны интерфейсы управления Web-сервиса, доступные для платформы WSMF. Документ WSDL описывает интерфейсы управления и конечные точки, которым WSMF может посылать сообщения, связанные с управлением. WSMF логически играет роль связующего звена между поставщиками и потребителями Web-сервисов. Чтобы управлять процессами на базе событий, сервис управления может поддерживать механизм событий для рассылки уведомлений. Поскольку агенты и сервис управления находятся в одном и том же пространстве памяти, они взаимодействуют посредством сообщений. Поведение агентов зависит от информации о событиях, поступающей из канала управления. Все сведения, собранные агентами, передаются сервису управления, который делает их доступными в канале управления. Как показано на рис. 3, наряду с распределенным мониторингом и реализацией политики WSMF предлагает централизованную платформу управления и политик. Она работает совместно с каталогами сервисов и средствами идентификации как при получении информации (такой, как статистика производительности сервисов, сведения о взаимозависимости сервисов), так и при ее отсылке. Политика в виде наборов правил направляется компонентам управления сервисами. Эти правила определяют поведение компонента управления сервисами - когда и куда посылать оповещения, как обрабатывать транзитный трафик сообщений, соблюдать политику защиты и соглашения SLA и т.д. В дополнение к традиционным средствам разработки прикладных сервисов для эффективного управления системами и приложениями архитектура SOA на базе Web-сервисов требует двух ключевых функций: На рис. 4
представлены концептуальные компоненты архитектуры, которые объединяют каналы управления сервисами и прикладные каналы, разработанные в соответствии с принципами SOA. Эта архитектура обеспечивает постоянную связь между прикладным каналом Web-сервисов и каналом управления. К числу управляющих приложений, которые она может обслуживать, относятся управление готовностью, производительностью, конфигурацией, заданиями, планирование загрузки, защита ресурсов и поиск неисправностей. В этой архитектуре управление сервисами подразумевает подбор сервисов, взаимодействующих друг с другом при передаче данных или координации определенных операций, что облегчает оказание одной или нескольких бизнес-услуг. Вместо того чтобы предписывать конкретный протокол управления или технологию измерений, архитектура обеспечивает работу с протоколом SOAP, расширениями JMX (Java Management Extensions), технологией WBEM и другими (в том числе будущими) технологиями и стандартами. На рис. 4 к управляемым ресурсам относятся физические и логические программные и аппаратные средства. Эти ресурсы публикуют свои свойства управляемости в виде Web-сервисов, которые реализуют разные интерфейсы, например определенные в спецификации распределенного управления Web-сервисами WSDM (Web Services Distributed Management). Интерфейс управления ресурсом описывается документом WSDL, схемой свойств ресурса, документами метаданных и, возможно, набором политик, связанных с управлением. В процессе управления или в бизнес-процессе менеджеры ресурсов могут непосредственно обращаться к ресурсам. Как показано на рис. 4, на двух взаимодействующих предприятиях бизнес-процесс основан на базовых сервисах, таких как проверка кредитоспособности, отгрузка, обработка заказа и управление складскими запасами. Управляющие приложения архитектуры контролируют ресурсы через их интерфейсы или сервисы инфраструктуры . Эти менеджеры обеспечивают ряд функций, в том числе простой мониторинг, контроль, автономную настройку и восстановление, управление качеством, сквозное управление бизнес-процессами, предоставление системных ресурсов и услуг на основе политик. Обычно они поддерживают интерфейсы и контент для консолей управления и отображают информацию, связанную с управлением. Менеджеры взаимодействуют с ресурсами и сервисами инфраструктуры, применяя интерфейсы Web-сервисов. Кроме того, менеджеры сервисов используют язык WS-BPEL (Web Services Business Process Execution Language) для описания и выполнения процессов управления, которые обеспечивают исполнение заданных сценарием функций управления. Решения на базе SOA, предназначенные для разработки приложений и управления ими, поощряют применение методов множественного связывания, а также следующие общедоступные сервисы управления: Передовые предприятия, строящие платформы сервисов на основе этой архитектуры, по мере необходимости могут дополнять бизнес-приложения специальными возможностями управления. Поскольку архитектура позволяет на основе стандартов гармонично сочетать проверенные взаимодополняющие элементы из разных источников, она обеспечивает адаптируемость предприятия к изменяющимся условиям. Майкл Папазоглоу ([email protected]) - профессор Университета Тилбурга (Голландия). В сферу его научных интересов входят распределенные системы, сервис-ориентированные архитектуры и Web-сервисы, интеграция корпоративных приложений, технологии и приложения электронного бизнеса. Виллем-Ян ван ден Хьювел ([email protected]) - доцент Университета Тилбурга. К его научным интересам относятся сервис-ориентированные архитектуры, эволюция систем и увязка новых корпоративных информационных систем с унаследованными.
Согласованное сквозное управление Web-сервисами невозможно без разработки общеотраслевых стандартов. С этой целью организация OASIS (Organization for the Advancement of Structured Information Standards) активно развивает спецификацию распределенного управления Web-сервисами WSDM (Web Services Distributed Management; www.oasis-open.org
). Она определяет протокол обмена управляющей информацией через Web-сервисы. При решении проблем управления распределенными системами WSDM подразумевает две задачи: управление с использованием Web-сервисов (management using Web services, MUWS) и управление Web-сервисами (management of Web services, MOWS). MUWS устанавливает использование технологий Web-сервисов как основы современной платформы управления распределенными системами, в том числе применение Web-сервисов для упрощения взаимодействия управляемых ресурсов и управляющих приложений. Так, MUWS определяет, как описывать свойства управляемости ресурсов с помощью документов WSDL. Описание этих свойств способствует более эффективному выявлению и анализу ресурсов. Поскольку ИТ-менеджеры обычно фокусируются на конкретной задаче или области управления, они должны иметь возможность эффективно выявлять подходящие свойства управляемого ресурса. MOWS определяет требования к управляющим Web-сервисам. В соответствии со спецификацией WSDM, Web-сервисы являются основой распределенных вычислений, интероперабельности, слабого связывания и независимости от реализации. Спецификация MOWS базируется на концепциях и определениях MUWS. Как и в MUWS, при определении модели управления Web-сервисами в MOWS прослеживается стремление оставаться в рамках существующих модельных структур, а не заново изобретать обобщенную объектную модель управляемых ресурсов. Michael Papazoglou, Willem-Jan van den Heuvel, Web Services Management: A Survey, IEEE Internet Computing, Nov/Dec 2005. IEEE Computer Society, 2005, All rights reserved. Reprinted with permission.
Web-сервисы
- это новая перспективная архитектура,
которая обеспечивает новый уровень
распределенности. Вместо разработки
или приобретения компонентов и их
встраивания в ИС предлагается покупать
время их работы и формировать программную
систему, которая осуществляет вызовы
методов из компонентов, которые
принадлежат и поддерживаются независимыми
провайдерами. Благодаря Web-сервисам
функции любой программы в сети могут
стать доступными через Интернет. Самый
простой пример Web-сервиса - система
Passport на Hotmail, которая позволяет создать
аутентификацию пользователей на
собственном сайте. В основе Web-сервисов
лежат следующие универсальные технологии: TCP/IP – универсальный
протокол, понимаемый всеми сетевыми
устройствами, от мэйнфреймов до мобильных
телефонов и PDA; HTML – универсальный
язык разметки, применяемый для отображения
информации устройствами пользователей; XML (Extensible Markup
Language)– универсальный язык для работы
с любыми типами данных. Универсальность
этих технологий – основа для понимания
веб-сервисов. Они основаны только
на общепринятых, открытых и формально
независимых от поставщиков технологиях.
Только посредством этого достигается
главное преимущество веб-сервисов как
концепции построения распределенных
ИС – их универсальность, т. е. возможность
применения для любых операционных
систем, языков программирования, серверов
приложений и т. д. Таким образом,
веб-сервисы решают исходную задачу –
задачу интеграции приложений различной
природы и построения распределенных
ИС. В этом и заключается основное
принципиальное отличие веб-сервисов
от предшественников. Веб-сервисы - это
XML-приложения, осуществляющие связывание
данных с программами, объектами, базами
данных либо с деловыми операциями
целиком. Между веб-сервисом и программой
осуществляется обмен XML-документами,
оформленными в виде сообщений. Стандарты
веб-сервисов определяют формат таких
сообщений, интерфейс, которому передается
сообщение, правила привязки содержания
сообщения к реализующему сервис
приложению и обратно, а также механизмы
публикации и поиска интерфейсов. Веб-сервисы могут
использоваться во многих приложениях.
Независимо от того, откуда запускаются
веб-сервисы, с настольных компьютеров
клиентов или с переносных, они могут
использоваться для обращения к таким
интернет-приложениям, как система
предварительных заказов или контроля
выполнения заказов. Веб-сервисы пригодны
для В2В-интеграции (business-to-business), замыкая
приложения, выполняемые различными
организациями, в один производственный
процесс. Веб-сервисы также могут решать
более широкую проблему интеграции
приложений предприятия (Enterprise Application
Integration, EAI), осуществляя связь нескольких
приложений одного предприятия с
несколькими другими приложениями. Во
всех перечисленных случаях технологии
веб-сервисов являются "связующим
звеном", объединяющим различные части
программного обеспечения. Как видно из рис.
5.1, веб-сервисы представляют собой
оболочку, обеспечивающую стандартный
способ взаимодействия с прикладными
программными средами, такими как системы
управления базами данных (СУБД), .NET, J2EE
(Java2 Platform, Enterprise Edition), CORBA (Common Object Request
Broker Architecture), посредники пакетов
планирования ресурсов предприятия
(Enterprise Resource Planning, ERP), брокеров интеграции
и пр. Рис.5.1. Веб-сервисы
взаимодействуют с прикладными системами
Интерфейсы
веб-сервисов получают из сетевой среды
стандартные XML-сообщения, преобразуют
XML-данные в формат, "понимаемый"
конкретной прикладной программной
системой, и отправляют ответное сообщение
(последнее - не обязательно). Программная
реализация веб-сервисов (базовое
программное обеспечение, нижний уровень)
может быть создана на любом языке
программирования с использованием
любой операционной системы и любого
связующего программного обеспечения
(middleware). Простой пример:
поиск информации
В настоящее время
большинство сервисов вызываются по
Сети посредством ввода данных в HTML-формы
и отправки этих данных сервису путем
добавления их в строку унифицированного
указателя информационного ресурса
(Uniform Resource Locator, URL): http://www.google.com/search?q=Skate+boots&btnG=Google+Search Этот пример
иллюстрирует простоту веб-взаимодействия
(например, поиска, покупки акций или
запроса маршрута движения), где параметры
и ключевые слова внедряются непосредственно
в URL. В данном случае представлен простой
запрос поиска skate boots (ботинки с коньками)
в строке обращения к поисковой машине
Google. Ключевое слово search (искать)
представляет сервис, к которому будет
осуществлено обращение, а параметр
Skate+boots является строкой поиска, которая
была введена в HTML-форме на странице
веб-сайта Google. Сервис поиска Google передаст
этот запрос к различным поисковым
машинам, которые вернут список URL для
страниц, на которых имеется соответствие
параметру поиска Skate+boots. Данный
малоэффективный способ поиска в Сети
полностью основан на установлении
соответствия указанной текстовой строки
и индексированных HTML-страниц. XML - лучший способ
отправки данных. XML предоставляет
значительные преимущества при передаче
данных через Интернет. Теперь предыдущий
запрос можно представить в виде
XML-документа: xmlns:s="www.xmlbus.com/SearchService"> Отправка запроса
в виде XML-документа имеет следующие
преимущества: возможность определения
типов данных и структур, большую гибкость
и расширяемость. XML может представлять
структурированные данные или данные
определенного типа (например, допустимо
указывать значение поля size (размер) как
в виде строки цифр, так и в форме числа
с плавающей точкой) и содержать больший
объем информации, чем это допускает
URL. Данный пример
представлен в форме SOAP-сообщения (Simple
Object Access Protocol) - стандартной формы обмена
XML-сообщениями - одной из технологий,
лежащих в основе веб-сервисов. В
SOAP-сообщении имя запрашиваемого сервиса
и входные параметры представлены в виде
отдельных XML-элементов. Рассматриваемый
пример также иллюстрирует использование
пространства имен XML (xmlns:), еще одного
важного элемента веб-сервисов. Благодаря
тому, что XML-документы поддерживают
разные типы данных, сложные структуры
и объединение схем, современные технологии
веб-сервисов обеспечивают значительное
преимущество над существующими
возможностями обращения к программным
приложениям посредством HTML и URL. Следующее
поколение Сети
Следующее поколение
Сети будет основано на программно-ориентированных
взаимодействиях. Веб-сервисы предполагают
использовать созданные для взаимодействия
людей глобальные сети совершенно в иных
целях. Использование
веб-сервисов очень выгодно с коммерческой
точки зрения. За счет повсеместного
распространения веб-сервисов Интернет
становится более эффективным, особенно
при осуществлении коммерческих сделок.
Сочетая прямой доступ к программным
приложениям и коммерческим документам,
веб-сервисы следующего поколения Сети
обеспечат полностью автоматическое
взаимодействие, что позволит обращаться
непосредственно к данным программ,
игнорируя знакомые веб-страницы. Более
того, основные компоненты веб-сервисов,
скорее всего, будут предоставляться и
публиковаться множеством различных
компаний, специализирующихся на отдельных
функциональных элементах (проверка
полномочий, координация сделок, ведение
счетов). Это обеспечит непосредственное
взаимодействие "приложение-приложение"
- принцип, лежащий в основе веб-сервисов
и определяющий их суть и реализацию. ОБЩЕЕ ВЗАИМОПОНИМАНИЕ Технология
веб-сервисов существует на очень высоком
уровне абстракции, позволяя поддерживать
множество одновременных определений,
которые иногда бывают противоречивы.
На простейшем уровне веб-сервисы могут
восприниматься как интернет-ориентированные
текстовые брокеры интеграции. Любые
данные могут преобразовываться в
ASCII-текст и обратно, и этот подход в
течение долгого времени был общим
знаменателем для систем графического
вывода и систем управления базами
данных. Ориентированные на использование
текста системы также лежат в основе
успешного развития Интернета, на котором
базируется дополнительная абстракция
веб-сервисов. Любой компьютер или
операционная система может поддерживать
HTML, браузеры и веб-сервисы; и при получении
по сети файлов им совершенно безразлично
и даже неизвестно, с каким типом прикладной
системы они взаимодействуют. Преимущества и
недостатки веб-сервисов.
К преимуществам
веб-сервисов
можно отнести следующее: Веб-сервисы
позволяют компании интегрировать свои
бизнес-процессы с бизнес-процессами
бизнес-партнеров и клиентов при меньшей
стоимости, чем с использованием других
интеграционных технологий. Стоимость
подобных решений на основе веб-сервисов
доступна даже для SMB (Small and Medium Business),
что откроет для таких компаний новые
перспективы развития; Поскольку
веб-сервисы организуются в публичные
реестры (UDDI-реестры, ebXML-реестры или
иные), доступные заинтересованным лицам
по всему миру, порог выхода компаний
на новые рынки снижается, возможности
же для наращивания клиентской базы
напротив возрастают; Веб-сервисы
обеспечивают преемственность в отношении
уже имеющихся в компании ИС, т. е. можно
сказать, что веб-сервисы надстраиваются
над
существующими ИС, но не вместо
них. Таким образом, обеспечивается
сохранность уже сделанных инвестиций
в IT-инфраструктуру и не идет увеличения
требуемых, поскольку нет необходимости
в радикальных изменениях; Построение
новых корпоративных решений с применением
веб-сервисов реализуется быстрее и
совокупно дешевле, поскольку основное
внимание сосредотачивается на создании
бизнес-логики решения, программирование
самих веб-сервисов лишь по необходимости
“обрамляет” этот процесс, не требуя
больших трудозатрат за счет эффективного
применения повторно используемого
кода и адаптированных средств разработки
(IDE и SDK). К недостаткам
(минусам) веб-сервисов можно отнести: Стандарты
интеграции бизнес-процессов, вопросы
управления транзакциями и выработка
единых бизнес- и IT-политик взаимодействующих
посредством веб-сервисов компаний
находятся пока на стадии разработки
(мы отметим следующие начинания: Web
Services Flow Language (WSFL), Business Process Execution Language 4
Web Services (BPEL4WS (аббревиатура “BPEL”
произносится кратко как “бипль”))
корпорации IBM, XLANG корпорации Microsoft и
спецификации WS-Coordination и WS-Transaction –
результат сотрудничества IBM, Microsoft и
BEA). Очевидно, без их четкой формализации
и опубликования построение ИС на основе
веб-сервисов может идти лишь с переменным
успехом; Динамическое
использование информации бизнес-реестров
веб-сервисов, вызов веб-сервисов, требует
решения вопросов доверительности
отношений между различными бизнес-реестрами.
Кроме того, есть трудности в совместном
использовании бизнес-реестров различных
форматов (например, задача поиска
определенного веб-сервиса в UDDI-реестре
и ebXML-реестре требует различных подходов
в силу различия XML-документов, описывающих
один и тот же веб-сервис в каждом из
этих реестров. Хотя, надо отметить, что
есть попытки решить эту проблему
созданием единого браузера реестров.
В качестве примера - графическая утилита
Registry Browser корпорации Sun Microsystems, реализующая
набор интерфейсов JAXR (Java API for XML
Registries); Добавление к
функциям сервера приложений
функциональности провайдера веб-сервисов
в силу новизны технологий может
представлять определенную трудность; Вопросы
безопасности функционирования ИС на
основе веб-сервисов пока не урегулированы
до конца. Спецификация WS-Security – продукт
деятельности корпораций IBM и Microsoft – в
настоящее время достаточно молода, не
“устоялась” и частично все еще
дорабатывается. Однако, в силу общности
положений спецификации WS-Security, уже
готовится к выпуску следующий слой
спецификаций, посвященных вопросам
безопасности: Web Services Policy Assertions, Web
Services Policy Attachments, Web Services Policy Framework, Web
Services Trust, Web Services Secure Conversation, Web Services
Federation. Таким образом,
преимущества представляют собой
стратегические бизнес-преимущества
компаний, а недостатки имеют технологический
характер и обусловлены новизной
технологий, решение этих проблем лишь
вопрос времени. Определение
веб-сервиса Назовем сервисом
(service)
ресурс,
реализующий бизнес-функцию, обладающий
следующими свойствами: является
повторно используемым; определяется
одним или несколькими явными
технологически-независимыми интерфейсами; слабо связан
с другими подобными ресурсами и может
быть вызван посредством коммуникационных
протоколов, обеспечивающих возможность
взаимодействия ресурсов между собой. Веб-сервисом
(см. документ W3C “Web-services architecture
requirements”) называется программная система,
идентифицируемая строкой URI, чьи
интерфейсы и привязки определены и
описаны посредством XML. Описание этой
программной системы может быть найдено
другими программными системами, которые
могут взаимодействовать с ней согласно
этому описанию посредством сообщений,
основанных на XML, и передаваемых с помощью
Интернет-протоколов. В данной статье мне хотелось бы обсудить вопросы, связанные с проектированием
web сервисов, предназначенных для межпрограммного взаимодействия. Так называемых
– интеграционных web сервисов. Прежде всего, это сервисы, которым предстоит
работать в различных решениях класса Enterprise Applications Integration (EAI),
а также в B2B решениях. Вопросам разработки web сервисов с использованием
различных платформ посвящено множество книг и статей, а вот вопросы
проектирования освещены гораздо хуже. Вы можете найти массу статей с
заклинаниями на тему SOA, которые будут совершенно бесполезны, когда вы
приступите к проектированию своего web сервиса. Где: Теперь попробуем набросать сигнатуру методов сервиса. Исходя из требований нам
понятно, что сервис должен содержать методы, которые позволяют создавать,
просматривать и удалять счета к оплате. Получился сервис с тремя методами:, а потому довольно сложно контролировать и измерять Web-сервисы, управлять их готовностью и производительностью.
Управление распределенными сервисами
Требования к качеству
Концептуальная архитектура управления
Платформы распределенного управления
Управление Web-сервисами
Методы управления сервисами
Управление инфраструктурными сервисами
Управление сервисами и приложениями
Литература
Стандарт управления Web-сервисами
5.1.1 Основы Web-сервисов
Итак, давайте рассмотрим ситуацию, когда у вас на руках есть две работающие
системы (либо проекты двух систем), и перед вами стоит задача организовать
взаимодействие между ними. Вам надоели схемы синхронизации на основе файлов
импорта / экспорта, и вы остановили свой выбор на модной, современной и удобной
технологии web сервисов. Я попытаюсь рассказать о том, на что следует обратить
внимание и как избежать типичных ошибок при проектировании web сервиса для
взаимодействия двух систем. Немного SOA
И все же, сначала пару слов о небезызвестной SOA. Термин Service Oriented
Architecture (SOA) довольно серьезно пострадал от беспорядочного употребления в
маркетинговых целях. Его так часто употребляют в различных контекстах, что
теперь сказать что-то определенное о SOA, кроме того, что это - «сервис
ориентированная архитектура», уже трудно.
Тем не менее, SOA имеет такое же право на жизнь, как и «клиент – серверная
архитектура» или «много уровневая архитектура». Как и любая другая
«архитектура», SOA вводит ряд абстракций и правил, которые помогают нам в
разработке определенного класса приложений. В данном конкретном случае,
руководствоваться принципами SOA полезно при разработке механизмов
взаимодействия и интеграции приложений в масштабе предприятия (Enterprise
Applications Integration - EAI).
Итак, начнем с того, что SOA рассматривает приложения как сервисы или
совокупности сервисов, которые обмениваются сообщениями напрямую, либо
посредством некоторых интеграционных механизмов. Эти сервисы должны
удовлетворять ряду условий или требований.
Во-первых, сервис должен иметь определенное «business value», иными словами,
сервис должен иметь прикладное значение. Если вы не можете простыми словами
объяснить заказчику или пользователю системы для чего нужен ваш сервис, то с
точки зрения SOA это неудачный сервис. Пример плохого сервиса: «Сервис для
получения глобально – уникальных идентификаторов». Пример хороших сервисов:
«Сервис данных о сотрудниках предприятия» или «Сервис приема и обработки счетов
к оплате» (Accounts Payable).
Во-вторых, с точки зрения SOA, сервисы должны быть автономными и независимыми.
Это необходимо для того, чтобы как это принято в SOA, мы могли комбинировать
одни сервисы с другими в зависимости от потребностей бизнеса. Если мы захотели
использовать «Сервис приема и обработки счетов к оплате» и при этом узнаем, что
нам придется установить и использовать «Сервис бюджетирования и финансового
планирования», «Сервис ведения главной книги», и еще дюжину сервисов, то с точки
зрения SOA все это выглядит просто отвратительно.
В-третьих, сервис должен быть функционально полным с прикладной точки зрения.
Это требование комплиментарно предыдущему. Например, «Сервис приема и обработки
счетов к оплате» позволяет добавить заявку, а отследить ее статус не позволяет.
Но в принципе мы можем получить отчет по заявкам, из которого можно узнать о
статусе заявки. Не правда ли, знакомая ситуация? С точки зрения SOA, да и с
любой точки зрения – это не правильно. Сервис должен обеспечивать выполнение
всех основных бизнес операций, связанных с прикладной областью или бизнес
процессом, который он обеспечивает.
В-четвертых, все сервисы должны уметь предоставлять свои описания в некотором
стандартизированном формате. WSDL и UDDI - это варианты форматов описания
сервисов.
В-пятых, сервисы должны быть ориентированы на распределенное асинхронное
взаимодействие без хранения состояния. Это типично для большинства современных
распределенных систем, и это очень важное требование. Достаточно вспомнить, что
клиент-серверная архитектура ориентирована на синхронное взаимодействие с
хранением состояния, и именно это обстоятельство стало ключевым ограничением для
дальнейшего развития этой архитектуры.
В-шестых, SOA предполагает, что благодаря выполнению предыдущих требований,
сервисы будут способны объединяться для взаимодействия друг с другом при помощи
различных интеграционных инструментов, типа брокеров и маршрутизаторов
сообщений, серверов workflow и т.д. и т.п. Ключевым моментом здесь является тот
факт, что интеграционные сценарии будут основываться на конфигурировании, часто
визуальном, а не на разработке специального «интегрирующего» кода, как это
делается в большинстве случаев сейчас.
Вот примерно так выглядят основные вехи, на которые мы должны ориентироваться и
которые должны ограничивать нашу разыгравшуюся дизайнерскую мысль в процессе
проектирования и разработки интеграционных web сервисов.Проектирование контракта сервиса.
После того, как Microsoft в своей платформе Windows Communication Foundation –
WCF (бывшая Indigo) использовала термин «контракт сервиса», он имеет все шансы
сделаться стандартным термином де-факто.
Контракт сервиса - это описание сигнатур всех его операций (методов), плюс
описание форматов данных, которыми он оперирует в качестве входных и выходных
сообщений.
Для web сервисов контракт исчерпывающе описывается WSDL схемой сервиса. Однако
согласитесь, что WSDL не очень хорошо приспособлен для человеческого восприятия.
Гораздо нагляднее контракт можно изобразить в виде UML диаграммы классов. К
счастью, большинство современных платформ для разработки web сервисов
обеспечивают функцию автоматической генерации WSDL описания сервисов.
Правильно спроектированный контракт сервиса, залог успеха, и гарантия того, что
ваш сервис проживет долгую и счастливую жизнь, и умрет своей смертью, потому что
на смену ему придет новая технология, о которой мы сейчас ничего не знаем.
Microsoft предлагает специальный термин – “contract first” для описания подхода
к проектированию, ориентированного в первую очередь, на контракт. Он
предполагает, что проектирование сервиса должно начинаться с описания XSD схем
сообщений (данных), затем создается WSDL описание операций сервиса, по которому
генерируется код класса сервиса. И лишь после этого приступают к имплементации
логики. Идея здравая, однако, я повторюсь, что работать с XSD и WSDL не очень
удобно, даже с использованием визуальных средств типа XmlSpy. Кроме того, сам по
себе принцип “contact first” не гарантирует нам получения правильного контракта
сервиса.
Для меня принцип “contact first” означает, что при проектировании сервиса мы
должны в первую очередь думать о его контракте и в последнюю - о деталях
реализации. Следует взглянуть на будущий сервис c внешней стороны, глазами
потребителя данных этого сервиса. Такой взгляд упрощает транспонирование
требований предъявляемых к сервису в набор предоставляемых им операций.
Например, мы разрабатываем сервис, предоставляющий данные о сотрудниках
предприятия. Логично предусмотреть в нем операцию, возвращающую список всех
сотрудников. Однако, в ходе анализа требований может оказаться, что потребителю
данных нашего сервиса будет интересен, в первую очередь, список сотрудников
конкретного подразделения. Это говорит нам о том, что в контракт операции,
возвращающей список сотрудников, следует добавить параметр, позволяющий
отфильтровать сотрудников конкретного подразделения, либо, нам следует выделить
это действие в отдельную операцию сервиса. Такой подход будет соответствовать
принципу “contract first”. И напротив, мы могли бы возложить на потребителя
данных нашего сервиса обязанность выбрать сотрудников нужного ему отдела из
общего списка. Придерживаться подобной стратегии при проектировании
интеграционных сервисов – плохая практика. Разбирая конкретный данный случай, мы
можем говорить о том, что такое решение не оптимально с точки зрения нагрузки на
сервис или объема трафика, а также что такое решение снижает безопасность.
Обобщая, можно сказать, что основания простоты и универсальности не должны
превалировать при проектировании сервиса. Универсальность сервиса должна
достигаться тщательным дизайном. Крайне сложно дать какие либо практические
рекомендации в данном направлении. Не легко создать сервис, который бы не
состоял из одного метода, вываливающего все внутренние данные системы наружу, и
в тоже время был достаточно универсальным для того, чтобы его смог использовать
не только тот потребитель, для которого вы проектировали сервис, но и любой
другой. Чтобы добиться этого, следует обращать внимание на функциональную
полноту контракта сервиса.
Давайте рассмотрим пример. Предположим, существует некая система учета и
согласования счетов к оплате, из разряда тех, что обозначаются термином Accounts
Payable. Система позволяет вводить данные счетов к оплате, обеспечивает бизнес
процесс их согласования и, далее взаимодействует с бухгалтерской системой для
формирования платежей. Ввод счетов и их согласование осуществляется, через UI
системы. Перед нами стоит задача: создать web сервис, посредством которого
другие системы могли создавать счета и отслеживать их статус.
Для простоты, будем считать, что счет к оплате имеет следующую структуру:
Number – уникальный номер счета, присваиваемый при создании
RecipientID – ссылка на справочник контрагентов, в котором хранятся все
реквизиты получателя платежа
Amount – сумма к оплате
PaymentDate – дата оплаты
CategoryID – ссылка на справочник категорий платежей
Owner - имя сотрудника, который создал счет
Description – описание
State – состояния счета, вокруг которого строится бизнес процесс согласования
счета.
Итак, исходные требования нам ясны. Схема данных для представления счета, тоже
понятна. На основе представленной диаграммы будет создана вот такая XML схема,
которая нас вполне устраивает:
Выглядит просто ужасно! Давайте разберем, что здесь не так.
Метод добавления счета AddPayment() принимает в качестве параметра структуру
Payment, а возвращает номер, присвоенный счету. Структура Payment не очень
подходящий тип данных для параметра этого метода, потому что она содержит ряд
полей, заполнение которых подчиняется внутренней бизнес логике системы. Это поля
Number, State и Owner. Мы не знаем этих бизнес правил, и не знаем, как заполнять
эти поля. Для создания счета мы должны указать: получателя, сумму платежа, дату,
категорию и описание. Поэтому имеет смысл создать метод именно с такими
параметрами, который создаст счет к оплате и вернет его в структуре Payment.
Метод ListPayments() возвращает список счетов в виде массива структур Payment.
Возможно, система должна возвращать только те счета, которые были созданы данным
пользователем. Однако отсутствие соответствующего параметра в сигнатуре метода
не должно вас удивлять. Более надежный и безопасный способ получить данные о
пользователе, - взять их из данных аутентификации. Со временем в системе может
накопиться огромное количество счетов, и данному методу не помешали бы параметры
для фильтрации выдаваемого списка по датам.
Наконец, метод RemovePayment() - принимает номер счета и возвращает true в
случае успешного удаления и false в противном случае. Использование Boolean в
качестве результата не лучшее решение в данном случае. Причины неудачи операции
удаления могут быть самыми различными от простого отсутствия счета с указанным
номером, до нарушения логических ограничений системы (например, нельзя удалить
счет со статусом Commited). Ситуация довольно распространенная. Ошибка может
случиться при выполнении любого метода web сервиса, и, к счастью, инфраструктура
web сервисов предлагает стандартный подход к решению этой проблемы. Для передачи
данных об ошибке используется SOAP сообщение, в теле которого содержится элемент
Fault с информацией об ошибке. Таким образом, нам не нужно расширять контракт
нашего web сервиса для передачи сообщений об ошибках, и в случае метода
RemovePayment() мы можем вполне обойтись без возвращаемого значения. В случае
неудачи удаления счета, информация о причине будет передана в сообщении об
ошибке.
После всех изменений наш web сервис будет выглядеть так:
Выглядит значительно лучше, но проблемы остались.
Давайте посмотрим на метод CreatePayment(). Для того чтобы создать счет, нам
надо передать пять параметров. С параметрами amount, date, desc, у нас проблем
нет. Но вот откуда взять ссылки на получателя (recipient) и категорию
(category)? Как я уже упоминал, эти данные представляют собой ссылки на элементы
соответствующих справочников нашей системы. И теперь нам становится понятно, что
для успешного использования нашего web сервиса, мы должны предоставить доступ к
значениям этих справочников.
Таким образом, окончательный вид контракта нашего web сервиса дополнился двумя
методами EnumRecipient() и EnumCategory() и двумя типами данных RecipientInfo и
CategoryInfo. Их не было в первоначальном контракте и необходимость этих методов
не определяется первоначальными требованиями. Они служат для обеспечения
синтаксической полноты контракта нашего сервиса. Теперь потребитель данных
сервиса может вызвать методы EnumRecipient() и EnumCategory() для получения
списков получателей и категорий, выбрать из них необходимые значения, и затем
вызвать метод CreatePayment() для создания счета.
Теперь мы можем сказать, что мы спроектировали функционально и синтаксически
полный сервис. Также, наш сервис достаточно универсален, и с большой
вероятностью его удастся использовать для интеграции с другими системами, перед
которыми будут стоять похожие задачи. Кроме того, контракт сервиса и его WSDL
описание, включают в себя полные схемы данных всех сообщений. Это очень важно
для того, чтобы наш сервис смогли использовать инструменты интеграции типа
BizTalk Server, Fiorano ESB, Sonic ESB и др.
На последнем моменте хочется заострить внимание. Формат данных, которыми
обменивается сервис, очень важен. Разработчики нередко впадают в одну из двух
крайностей. Первая из них, это использование в качестве формата для всех
сообщений «голого Xml». Причины тому могут быть самые разные, от попыток
использования существующего кода импорта - экспорта Xml данных, до слишком
буквального понимания сути web сервисов, как механизма обмена Xml сообщениями.
Недостаток такого подхода достаточно очевиден, - схема данных не попадает в WSDL
описание контракта сервиса, и это затрудняет его использование. На мой взгляд,
существует единственный случай, когда такой подход оправдан. Это случай, когда
нам заранее не известен формат передаваемых данных. Во всех остальных случаях,
следует использовать типизированные сообщения.
Вторая крайность, это противоположность первой, и выражается она в том, что
разработчики пытаются использовать в контракте сервиса существующие в системе
внутренние форматы представления данных. Действительно, если в системе уже
определены структуры и классы для представления данных (Data Transfer Objects),
то почему бы не использовать их в контракте сервиса? Это не всегда это хорошая
идея. Внутренние форматы данных могут оказаться не удобными для клиента сервиса.
Они могут иметь специфический формат, который не поддерживается клиентской
стороной. Пример такого формата DataSet из Microsoft ADO.NET. Данные DataSet
прекрасно преобразуются XML и могут быть использованы ASP.NET web сервисами.
Однако, это внутренний формат Microsoft, который не является отраслевым
стандартом, он имеет свои особенности форматирования Xml представления, которые
могут затруднить использование этих данных другими программными платформами web
сервисов. Существует масса случаев, в которых использование DataSet оправданно и
удобно, но интеграционные сервисы не относятся к их числу.
Таким образом, общие рекомендации по проектированию форматов сообщений web
сервисов сводятся к следующему. Всегда старайтесь использовать типизированные
сообщения, формат которых описывается определенной Xsd схемой. Проектируйте
формат сообщений исходя из функциональных требований, и лишь в том случае, когда
полученный формат совпадает с внутренним форматом данных системы, можно подумать
об использовании внутреннего формата.Протокол взаимодействия и его влияние на контракт
Под протоколом взаимодействия web сервиса мы понимаем ту часть требований,
которая описывает последовательность взаимодействия сервиса и клиента,
направление передачи данных, а также такие аспекты поведения сервиса, как
транзакционность, асинхронность, и т.д.
Протокол взаимодействия и контракт сервиса очень тесно связанны. Помимо
достаточно простых случаев, когда существует один сервис и его клиент,
существуют и более сложные, в которых протокол взаимодействия требует наличия
двух и более сервисов. Примером такого протокола может служить протокол
асинхронного взаимодействия
ASAP
Я не открою большого секрета, если скажу, что отличным способом построить
контракт сервиса (по крайней мере, в плане используемых операций) является
использование UML диаграмм взаимодействия. Мое личное мнение, наилучшие
результаты дает применение Sequence diagram. На рисунке приведена Sequence
diagram взаимодействия клиента и сервиса из примера AccountsPayable,
рассмотренного выше. К сожалению данный пример достаточно прост, чтобы
почувствовать насколько Sequence diagram облегчают проектирование контракта
сервиса.
В наиболее сложных случаях может потребоваться построение диаграммы состояния
для протокола взаимодействия. При этом переходы в графе состояний будут
представлять операции сервиса. Вопросы безопасности
После того, как контракт сервиса разработан, а иногда и раньше, перед
проектировщиком в полный рост встают проблемы обеспечения безопасности. Времена,
когда web сервисы называли незрелой технологией, не способной обеспечить
безопасность данных, давно прошли. Web сервисы могут быть надежными и
безопасными. А могут и не быть. Тут все зависит от нас.
Очертим круг вопросов, которые надо решить, для того чтобы спроектировать
безопасный сервис:
Аутентификация – это процесс подтверждения подлинности пользователя на основе
предъявленных им удостоверений. Надежность механизмов аутентификации является
критичной для обеспечения безопасности приложения в целом. Поэтому сразу стоит
забыть об «анонимном доступе». Наилучший сценарий обеспечения аутентификации,
воспользоваться средствами, предоставляемыми платформой web сервисов, которую вы
используете. Обычно для аутентификации используются специализированные протоколы
(Kerberos, NTLM) и их поддержка встраивается в платформу. Реализация собственных
механизмов аутентификации наверняка потребует значительных затрат и чревата
потенциальными сложностями реализации и дальнейшей поддержки.
Авторизация - это процесс предоставления пользователю полномочий по доступу к
функциям и данным. Естественно, для того чтобы авторизовать пользователя,
предварительно он должен быть аутентифицирован. Уловите разницу между
аутентификацией и авторизацией. Аутентификация отвечает на вопрос «кто» такой
клиент, а авторизация – на вопрос «что» может делать этот клиент. В подавляющем
большинстве случаев, бизнес правила по которым тому или иному пользователю
предоставляются права доступа к тем или иным данным и операциям определяются в
самом приложении. И, следовательно, авторизация – это область ответственности
приложения, предоставляющего сервис. Существует множество методов, практик и
шаблонов реализации механизмов авторизации, описание которых может быть
предметом отдельной статьи.
Помимо аутентификации и авторизации, защита данных при транспортировке их между
сервисом и его клиентом является третьей составной частью в обеспечении
безопасности web сервиса. Степень защиты определяется характером данных.
Различают два способа защиты данных: цифровая подпись и шифрование.
Цифровая подпись используется для подтверждения подлинности данных. Она не
защищает данные от несанкционированного прочтения, потому что данные не
шифруются. Цифровая подпись позволяет удостовериться в том, что данные
принадлежат именно владельцу подписи, а также в том, что данные не были изменены
с момента подписи. Механизм цифровой подписи довольно прост. Он основан на
использовании не симметричных алгоритмов шифрования, в которых используется пара
ключей, один из которых приватный (закрытый) а второй публичный (открытый).
Особенность не симметричных алгоритмов состоит в том, что данные, которые
зашифрованы одним ключом, можно расшифровать только другим ключом. Цифровая
подпись формируется следующим образом. Для данных вычисляется контрольная сумма
(хэш код), которая шифруется приватным ключом владельца цифровой подписи. Это и
есть цифровая подпись, она добавляется к данным. Так же, к данным может быть
добавлен открытый ключ. С помощью открытого ключа, любой пользователь может
расшифровать цифровую подпись и получить контрольную сумму, которую можно
сравнить с контрольной суммой рассчитанной над текущими данными и, таким образом
узнать, изменились ли данные.
В случае, когда нам необходимо не только обеспечить неизменность данных, но и
скрыть от посторонних их содержимое, применяется шифрование. Обычно, при
передаче данных применяется схема с сеансовым ключом, на механизме которой я не
буду останавливаться, поскольку обычно она обеспечивается на инфраструктурном
уровне. Итак, цифровая подпись и шифрование являются основными механизмами
защиты данных при передаче. Мы можем задействовать эти механизмы на уровне
транспортного протокола, либо на уровне сообщений SOAP. Каждый из способов имеет
свои преимущества и недостатки.
Для обеспечения защиты данных на уровне транспортного протокола обычно применяют
хорошо зарекомендовавший себя механизм SSL. При этом между клиентом и сервером
устанавливается защищенное соединение, в котором шифруется весь трафик.
Преимущество данного подхода состоит в том, что он практически не требует
дополнительных усилий со стороны разработчика (за исключением, может быть
некоторых особенностей при установлении соединения). Основная работа по
настройке защищенного SSL соединения производится при развертывании приложения.
К недостаткам такого подхода можно отнести то, что шифруется весь трафик, а не
только те данные, которые действительно являются конфиденциальными, и это
требует больших затрат вычислительных ресурсов. Описание того, как использовать
SSL совместно с web сервисами ASP.NET 1.1 вы можете найти в моей статье по
адресу http://stump-workshop.blogspot.com/2006/10/web-https-ssl.html
Механизмы защиты данных на уровне SOAP сообщений строятся на использовании таких
расширений SOAP протокола, как
WS-SecureConversation ,
WS-Trust ,
WS-SecurityPolicy
и WS-Security . Обычно
поддержка этих спецификаций встроена на уровне платформы, реализующей web
сервисы, и для разработчика они доступны как на декларативном уровне (атрибуты
или конфигурирование) так и в виде API. К преимуществам использования данных
механизмов относится их гибкость и универсальность. Вы можете использовать как
шифрование, так и цифровую подпись. Можно обеспечить защиту только сообщений
отдельных операций сервиса, и даже отдельных частей SOAP сообщения. К сожалению
не все платформы web сервисов в полной мере поддерживают данные спецификации.
Например, в широко распространенном.NET Framework 1.1 нет поддержки
WS-Security. Поэтому при использовании данной платформы придется реализовывать
защиту на транспортном уровне.
Наконец есть третий путь, - реализовать свой механизм защиты как, например,
описано
. Следует, однако, понимать, что такой путь резко сокращает возможности
использования вашего сервиса.
В заключении, стоит остановиться на таком вопросе, как хранение удостоверений
для подключения к web сервисам. Мы уже говорили о том, что доступ к web сервисам
следует предоставлять только аутентифицированным пользователям. Обратная сторона
медали состоит в том, что нам необходимо указывать удостоверения (credentials)
при подключении клиента к сервису. А следовательно, нам необходимо где-то
хранить эти удостоверения. Когда нашей системе приходится взаимодействовать с
несколькими сервисами, каждый из которых требует свои удостоверения, проблема
приобретает особую остроту.
Что такое удостоверения. В большинстве случаев - это пара значений логин –
пароль. Иногда это может быть клиентский сертификат или другой тип удостоверений,
- все зависит от используемого протокола аутентификации. Следует четко понимать,
что клиентские удостоверения относятся к данным, которые могут быть использованы
для атаки злоумышленника на систему. Следовательно, эти данные требуют защиты.
Вам следует учитывать это обстоятельство еще на стадии проектирования. При
реализации интеграционных web сервисов, вам наверняка придется затратить
некоторые усилия на разработку механизмов защищенного хранения клиентских
удостоверений и их настройки / редактирования.Вопросы реализации
Вопросы реализации web сервисов сильно зависят от платформы, с которой вы
работаете, а их на сегодняшний день существует великое множество. Только
Microsoft предлагает 4 платформы (ASP.NET 1.1, ASP.NET 2.0, WSE 1.0-3.0, WCF-Indigo).
В мире Java их еще больше. Поэтому давать конкретные рекомендации весьма
затруднительно. Однако есть моменты, на которые следует обратить внимание в
любом случае.
Большинство платформ берут на себя формирование WSDL описания сервиса,
предоставляя разработчику возможность работать с сервисом как с обычным классом.
Поэтому, следует уделять постоянное внимание тем деталям, которые оказывают
влияние на формирование правильного WSDL описания и XSD схем данных. К этим
вещам относится использование Xml Namespace и префиксов, управление порядком
сериализации данных, порядком и стилем генерации WSDL.
Следует стараться отделить бизнес логику от реализации сервиса. Хорошо, если у
вас получится использовать единую бизнес логику внутри приложения и в web
сервисе. В идеальном случае методы вашего web сервиса будут лишены всякой логики,
кроме проверки параметров, формирования результатов и обработки ошибок, как
показано на рисунке: Заключение
Итак, в данной статье мы рассмотрели круг вопросов, связанных с проектированием
интеграционных web сервисов.
Мы остановились на общих принципах концепции SOA. Рассмотрели практические
вопросы проектирования контракта сервиса, обеспечения его функциональной и
синтаксической полноты. Мы уделили внимание влиянию протокола взаимодействия на
контракт сервиса. Рассмотрели варианты решения вопросов безопасности web
сервисов. И в конце остановились на некоторых практических аспектах
проектирования. Я надеюсь, что данная статья будет полезна вам при
проектировании интеграционных web сервисов.
