Лекции - Корпоративные информационные системы и технологии
Подождите немного. Документ загружается.
• описание сервиса, для чего нужен некий читаемый машиной язык, на
котором описываются выполняемые сервисом операции; после
компиляции описания формируется код, определяющий процесс
взаимодействия между клиентом и поставщиком сервиса;
• протокол, который определяет способ обнаружения сервиса.
Идея сервисов в информационных системах как таковая не нова. Хорошо
известны следующие подходы к ее реализации:
• Java RMI от компании Sun Microsystems (Java Remote Method Invocation);
• CORBA консорциума Open Management Group (Common Object Request
Broker Architecture);
• DCE предложенная ассоциацией Open Group (Distributed Computing
Environment);
• Microsoft DCOM (Distributed Component Object Model).
Каждую из архитектур, которая реализуется этими средствами, вполне можно
назвать ориентированной на сервисы, но при этом каждая из них определяет
свои собственные форматы и протоколы, механизмы вызовов, интерфейсы для
прикладных программ. Недостаток универсальности ограничивает их
распространение. В сегодняшней трактовке SOA под сервисами понимают Web-
сервисы, в основе которых лежат общепринятые Internet-технологии и развитая
инфраструктура.
Главная отличительная черта Web-сервисов состоит в использовании XML. Что
же привнес этот язык в идею сервисов? Это чрезвычайно интересный вопрос, на
который нельзя дать полноценный ответ без глубинного анализа, без
рассмотрения различий между данными и информацией, не обращаясь не
столько к техническим, сколько к философским вопросам теории информации.
Первыми и наиболее очевидными соглашениями, позволяющими реализовать
Web-сервисы, стали «стандарты» SOAP, WSDL и UDDI, в шутку называемые
сегодня «святой троицей». Фактически это не стандарты, а три предложения от
группы крупных производителей, заинтересованных в развитии SOA,
возможно, наиболее рациональны, но далеко не единственны. Известно мнение,
что Web-сервисы — это только то, что реализуется стеком из SOAP, WSDL и
UDDI. Существует, скажем, предложенный Роем Филдингом альтернативный
подход, называемый REST, который позволяет реализовать функции Web-
служб без привлечения этих стандартов. Так или иначе, в общественном мнении
Web-сервисы главным образом ассоциируются именно с этими технологиями.
В таблице 8.2 приведена классификация сервисов и поддерживающих
соглашений и стандартов[4].
Таблица 8.2. Сравнение архитектур, ориентированных на сервисы
8.4.4 Два лица SOA
Наличие двух возможных точек зрения на SOA и на Web-сервисы привело к
тому, что над вопросами стандартизации в параллель работают две группы: в
рамках комитета W3C и в составе Organization for the Achievement of Structured
Information Standards (OASIS). Работа первой группы сосредоточена на
основных спецификациях сервисной инфраструктуры, а второй — на
расширении функциональности.
В рамках W3C работы по стандартизации Web-сервисов начались в 2000 году,
когда была создана рабочая группа XML Protocol Working Group (XMLP), а
затем сложилось объединение Web Services Activity, состоящее из трех рабочих
групп и одной координирующей. Деятельность Web Services Architecture
Working Group (WSAWG) сосредоточена на развитии стандартов для трех
компонентов сервисов, включая транспорт, описание и обнаружение,
максимально близких к SOAP, WSDL и UDDI. Работа групп WS-Desc и XMLP
непосредственно связана с разработкой XML-спецификаций для описания Web-
сервисов. Координирующая группа WSCG связывает деятельность W3C в
области сервисов с другими организациями.
OASIS имеет в своем составе более тридцати технических комитетов,
деятельность которых связана архитектурой Web-сервисов; в большинстве
своем они были созданы после 2000 года. Так, Web Security Technical Committee
разрабатывает стандарты, обеспечивающие безопасную передачу данных
средствами, построенными на основе SOAP. Со своей стороны, XML-Based
Security Service Technical Committee работает над стандартизацией механизма
авторизации и аутентификации с использованием XML, в том числе, языка
Security Assertion Markup Language (SAML). Есть комитеты, отвечающие за
выработку языков управления ресурсами, за обмен биометрической
информацией и целый ряд других.
8.4.5 Web-сервисы в интерпретации W3C
До начала прошлого года деятельность в области Web-сервисов в основном
сводилась к самоутверждению и конкуренции крупных компаний на поле
стандартов, подобных SOAP, WSDL, UDDI и ряду других. Это был совершенно
необходимый этап, в войне стандартов идеи Web-сервисов прошли обкатку, и
теперь появилась вполне реальная возможность для выработки практических
решений, которые могут быть приняты отраслью в целом.
В качестве рабочего органа, который должен взять на себя эту обязанность, в
январе 2002 года в рамках W3C была образована рабочая группа Web Services
Architecture Working Group [13]. За прошедшее время группой опубликован
целый ряд документов, в том числе глоссарий терминов из области Web-
сервисов [14]. В августе 2003 года была опубликована рабочая версия
документа «Архитектура Web-сервисов» [15], устранив противоречия,
которыми страдали отдельные публикации, и предложив единую платформу для
понимания того, что такое Web-сервисы и SOA. Оговоримся сразу — все, что
предлагает эта рабочая группа, относится к действующей модели Web; кроме
того, существуют академические исследования, в которых разрабатываются
Web-сервисы для Семантической Сети, но это сфера пока еще далека от
реального внедрения.
WSAWG предлагает следующее определение: «Web-сервис — это реализуемая
программными средствами система для поддержки межмашинного
взаимодействия через сеть. Интерфейс сервиса описывается на языке, читаемом
машиной, например, WSDL. Другие системы взаимодействуют с Web-сервисом
способом, указанным в его описании, используя сообщения в стандарте SOAP,
передаваемые с использованием HTTP и XML и в сочетании с другими
стандартами, относящимися к Web». Физически Web-сервис представляет собой
фрагмент программного обеспечения, называемый «агентом». Агент способен
передавать и принимать сообщения, он реализует абстрактную
функциональность сервиса. Следует проводить различие между агентом и
сервисом, один и тот же сервис может быть обеспечен разными агентами. Это
вполне тривиальная с инженерной точки зрения идея: скажем, в компьютере
должен быть отвод тепла, в таком случае сервис — это охлаждение, а
вентилятор — это агент; один вентилятор может быть заменен другим.
Web-сервис предназначен для предоставления некоторой функциональности от
лица ее владельца (поставщика), это может быть человек или организация
(provider entity), которая использует соответствующий собственный агент
(provider agent). Запрашивающая сторона (requester entity) тоже может быть
человеком или организацией, желающими использовать сервис. Для этого она
тоже использует свой агент (requester agent). Агенты взаимодействуют между
собой посредством обмена сообщениями. Для того чтобы этот обмен был
успешным, стороны прежде должны достичь соглашения об общем понимании
семантики механизме обмена сообщениями.
Механизм обмена сообщениями документирован в описании сервисов (WSD),
которое представляет собой читаемую машиной спецификацию интерфейса,
включающую: форматы сообщений, типы данных, транспортные протоколы,
форматы сериализации, используемые при обмене между агентами заказчика и
поставщика услуг. Она также содержит указание на одну или несколько точек в
сети (endpoint), откуда поставщик доступен и еще может содержать
информацию о предполагаемом шаблоне (pattern) сообщения, используемого
для обмена.
Семантика сервиса представляет собой содержание так называемого
«контракта» между сторонами; она также содержит некоторые дополнительные
сведения о механизмах обмена сообщениями, которые не отражены в WSD.
Важно отметить, что, хотя контракт содержит всеобъемлющее представление о
сервисе, он не должен быть документально зафиксированным. Контракт может
быть явным или скрытым, устным или письменным, в форме, доступной
машине или человеку. Различие между описанием сервиса и контрактом
заключается в том, что первое определяет механизм взаимодействия с сервисом,
а второй — смысл и предназначение этого взаимодействия.
Web-сервисы в основном предназначены для автоматизации процессов
управления, которые могли бы быть выполнены вручную, однако в архитектуре
Web-сервисов остается место и человеку. Во-первых, его участие требуется при
достижении соглашения по семантике и описанию. Человек (или организация)
является юридическим владельцем Web-сервисов; именно люди должны
согласиться с тем, что данная семантика и данное описание будут управлять
взаимодействием между сервисами. Возможно, что со стороны поставщика
участие может ограничиться публикацией и предоставлением возможности
использовать сервис только в той форме, в какой тот существует (take-it-or-
leave-it); иными словами, контракт предполагает неизменяемые условия с его
стороны. Есть и другие формы установления отношений, в том числе, через
координирующие организации или даже по запросу заказчика. Во-вторых,
агенты заказчика и поставщика сервисов создаются людьми, которые отвечают
за исполнение соглашений об описании и семантике услуги.
Рис. 8.2. Архитектура, ориентированная на сервисы, с учетом
предложений WSAWG
На рис. 8.2 представлена схема обмена между потребителем и поставщиком
сервисов с учетом предложений, сделанных WSAWG.
8.4.6 Архитектурные модели SOA
Одной из самых интересных находок, сделанных в [15], можно назвать
предложенные архитектурные модели SOA.
• Модель, ориентированная на сообщения (Message Oriented Model, MOM),
сосредоточена на сообщения, их структуру, способы транспортировки и
другие компоненты, ни как не связанные с причинами обмена
сообщениями и их семантикой.
• Модель, ориентированная на сервисы (Service Oriented Model, SOM),
сосредоточена на действиях, выполняемых сервисами.
• Модель, ориентированная на ресурсы (Resource Oriented Model, ROM),
сосредоточена на системных ресурсах.
• Модель политик (Policy Model, PM) определяет политики, связанные с
архитектурой, в основном она представляет собой ограничения,
накладываемые на поведения агентов и сервисов, в том числе
ограничения, связанные с требованиями безопасности, качества
обслуживания.
• Модель управления (Management Model, MM).
Анализ SOA с использованием каждой из моделей, характеристики моделей и
их взаимосвязь являются отдельной темой. В контексте данной статьи
достаточно согласиться с тем, что SOA как система сложнее других
информационных систем, и поэтому она требует для своего описания не одной,
а нескольких моделей. Наличие разных моделей позволит обеспечить
согласованную работу специалистов разных профилей, согласование различных
стандартов, образование структуры стандартов. Привычное представление о
такой простой структуре стандартов, как стек, в случае SOA явно не подходит.
Для установления связей между компонентами и сборки единой системы из
этих слабосвязанных и асинхронных компонентов требуются совершенно иные
приемы средства, которые получили довольно непривычно звучащие названия:
«оркестровка» (orchestration) и «хореография» (choreography).
Рис. 8.3. Архитектурные модели SOA
На Рисунке 8.3 приведена схема взаимодействия различных моделей между
собой.
8.4.7 Оркестровка и хореография Web-сервисов
С появлением Web-сервисов возникли термины «композиция Web-сервисов»
(Web-services composition) и «поток Web-сервисов» (Web-services flow),
используемые для описания потока работ, выполняемых с их помощью.
Недавно им пришли на смену два более выразительных термина — оркестровка
и хореография Web-сервисов. Под оркестровкой понимают то, как сервисы
взаимодействуют друг с другом на уровне сообщений, включая бизнес-логику и
кооперацию при выполнении сложных процессов в пределах одного
предприятия. Оркестровка основывается на открытых стандартах для создания
бизнес-процессов, включая BPEL4WS, WSCI и BPML. Хореография в данном
контексте охватывает более широкий круг участников взаимодействия, в том
числе поставщиков, потребителей и партнеров предприятия. Хореография
ассоциируется с публичным обменом сообщениями между множеством Web-
сервисов, а не с одним бизнес-процессом, осуществляемым на одном
предприятии [15]. Хореография — более публичный процесс.
Одним из наиболее интересных средств описания оркестровки стал язык
BPEL4WS (Business Process Execution Language for Web Services),
предложенный компаниями IBM, Microsoft и BEA Systems. Язык предназначен
для описания исполнения исполняемых бизнес-процессов и позволяет описать
поведение и взаимодействия Web-сервисов в бизнес-процессе.
Появление языков класса BPEL4WS в определенном смысле логически
завершает общую картину. Теперь можно — оговоримся, лишь условно —
рассматривать SOA как метакомпьютер, на котором выполняются процессы,
«запрограммированные» на языке описания процессов. Остается сделать всего
несколько шагов, чтобы системы управления бизнесом по своей логической
завершенности приблизились к техническим системам управления, а это
открывает путь к применению кибернетических методов управления с их
безграничными возможностями. Если учесть, что Web-сервисам понадобилось
всего несколько лет, чтобы превратиться в первооснову для создания
современных архитектур, то ждать новых открытий придется недолго.
8.4.8 Программные основы реализации SOA
На Рисунке 8.3а показаны основные компоненты прикладной корпоративной
сети, на базе которых реализуются основтые технологии SOA и
взаимодействуют известные системы интеграции типа ERP, CRM, B2B, B2C, др.
Рис. 8.3а. Программные основы реализации SOA
8.5 Модель, ориентированная на сообщения (МОМ).
Технологии обмена сообщениями в качестве основы для организации асинхронного
взаимодействия между компонентами информационной системы вовсе не новы, они
известны с 70-х годов, когда использовались в основном для общения между
задачами, работающими на мэйнфреймах.
В последующем на фоне всеобщего «сдвига ИТ-парадигм», вызванного взрывным
ростом Internet-технологий, в этой области сохранялась несколько необычная
ситуация стабильности. Она настолько затянулась, что, например, в мае 2000 года в
статье «Демистификация программного обеспечения промежуточного слоя»,
опубликованной в журнале CIO Magazine, средства MOM (message-oriented
middleware) были названы «старыми и добрыми» (dear old MOM). И вот
неожиданно эта «пожилая» технология оказалась в центре внимания. За последние
два года она вышла из тени и попала в число самых «горячих». Что же произошло?
8.5.1 «Электронная почта» для корпоративных приложений
Итак, десятилетиями события, происходившие в лагере MOM, не отличались
особой экстраординарностью. Все здесь развивалось на редкость спокойно. Первое
оживление датируется 1993 годом, когда была образована ассоциация Message
Oriented Middleware Association (MOMA). Затем на протяжении нескольких лет в
этой области доминировали две всем известные корпорации со своими известными
продуктами, а именно IBM с программным обеспечением MQSeries, которой
принадлежало 75% рынка, а также несколько позже вышедшей на него Microsoft с
продуктом MSMQ. Оставшийся небольшой сегмент достался компаниям
существенно меньшего масштаба, скажем, Talarian с продуктом SmartSockets или
Tibco с Tibco RV. Традиционное видение места средств MOM до событий
последних дней в общей картине ПО промежуточного слоя описано в [17].
Изменение ситуации вызвано развитием разного рода Internet-приложений.
Признание электронной почты в качестве классического примера «убойного
приложения» (killer application), давшего сильнейший импульс развитию Internet,
стало каноническим. Но это уже история, а вот теперь, когда не только люди, но и
приложения вышли в Сеть, возникла логическая необходимость сделать