Сервис-ориентированная архитектура

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Санкт-Петербургский государственный электротехнический университет

Кафедра МОЭВМ

Реферат

Сервис-ориентированная архитектура

Выполнил:

Орешко Д.В.

Санкт-Петербург 2004

Содержание

программный инфраструктура операционный

Введение

1. Предпосылки

2. Архитектура SOA

3. Базовые стандарты SOA

4. Реестр сервисов

5. Оркестровка

6. Что такое Web-сервисы

7. Четыре уровня адаптации SOA

8. Проблемы SOA

9. Достоинства

Литература

Введение

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

Приведем формальное определение сервисно-ориентированной архитектуры, которое сформулировано специалистами корпорации IBM: «SOA -- это прикладная архитектура, в которой все функции определены как независимые сервисы с вызываемыми интерфейсами. Обращение к этим сервисам в определенной последовательности позволяет реализовать тот или иной бизнес-процесс». С точки зрения разработчиков, ту же мысль можно передать несколько иными словами: SOA -- это компонентная модель, в которой разные функциональные единицы приложений, называемые сервисами, взаимодействуют по сети посредством интерфейсов. Расшифруем данные определения. Все функции приложений определены как сервисы.

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

1. Предпосылки

Как решается задача интеграции приложений? Традиционный подход -- построение промежуточного программного слоя того или иного типа. Оптимальной для объединения разнородных платформ и решений выглядела технология взаимодействия распределенных объектов CORBA, позволявшая инкапсулировать бизнес-логику приложений, выполняющихся на разных платформах и созданных с использованием разных языков программирования, организовав связь между ними на базе строго описанных интерфейсов. Аналогичные возможности -- правда, с естественным ограничением гетерогенности -- предлагала корпорация Microsoft в рамках своей компонентной модели DCOM. Однако этим решениям не хватало универсальности; даже применение CORBA сильно зависело от реализации в продуктах разных поставщиков, появлялись новые объектные модели, не поддерживающие CORBA, интеграция по-прежнему реализовывалась на достаточно низком уровне, практически, исключая возможность динамичного изменения связей между приложениями в ходе выполнения. Важно и то, что все предлагаемые средства интеграции фокусировались на технологических особенностях реализации приложений и не позволяли учитывать специфику бизнес-процессов, в которых эти приложения использовались.

В то же время новые потребности бизнеса диктуют и новые условия интеграции. Динамичность ИТ-среды, ее нацеленность на решение бизнес-задач, необходимость быстрых изменений в ответ на изменение этих задач -- эти характеристики приобретают ключевое значение при проектировании или реформировании корпоративных ИТ-инфраструктур. В этих условиях отдельные, «точечные» решения по интеграции настолько усложняют и саму инфраструктуру, и процесс управления ею, что становятся абсолютно неприемлемыми. Представим себе, к примеру, что в компании существует несколько приложений, каждое из которых интегрировано со всеми остальными посредством соответствующих интерфейсов. Если таких приложений -- n, то всего потребуется n(n-1) интерфейсов. С добавлением всего лишь одного нового приложения появится 2n новых интерфейсов, для которых потребуется соответствующее документирование, тестирование и поддержка. В примере на рис. 1 пять взаимодействующих приложений порождают 20 интерфейсов, а добавление шестого приложения потребует еще 10. При этом придется вносить модификации в код каждого из существующих приложений для учета новых интерфейсов и проводить соответствующее тестирование. Чтобы избежать этого, нужна модель интеграции, которая позволит максимально упростить процесс добавления новых приложений и минимизирует число интерфейсов взаимодействия.

Рис. 1. Прямая интеграция приложений

Еще одна серьезная проблема -- избыточность программных компонентов и сложность их многократного использования. В рис. 1 приводится пример программной инфраструктуры банка, включающей в себя несколько групп приложений для различных направлений банковской деятельности, которые были разработаны в рамках никак не связанных между собой проектов. В результате, с большей долей вероятности возможна ситуация, когда одна функция (скажем, получение баланса по вкладу) реализована многократно в системе автоматизации банкоматов, в системе поддержки филиалов и в системе расчетов по кредитным картам, -- даже если все эти системы используют одни и те же данные о счете из общей базы данных. А теперь предположим, что банк намерен разработать новые системы, например, для обслуживания клиентов в Internet или выдачи ссуд в режиме on-line. Расширение функциональности программной среды банка повлечет за собой дополнительную избыточность, если в этой среде отсутствуют механизмы многократного использования компонентов, поддерживающих различные задачи бизнеса. Все эти интеграционные проблемы и привели к появлению идеи сервисно-ориентированной архитектуры (service-oriented architecture, SOA). Для разрешения этих проблем простого набора технологий уже недостаточно. Нужен общий, архитектурный подход, концепция архитектуры программной среды предприятия, в которой возможна адекватная потребностям бизнеса динамика разработки, интеграции и эксплуатации приложений.

2. Архитектура SOA

Очень часто становление того или иного подхода сопровождается появлением неверных или ошибочных трактовок. SOA не является чем-то новым: IT-отделы компаний успешно создавали и развертывали приложения, поддерживающие сервис-ориентированную архитектуру, уже много лет - задолго до появления XML и Web-сервисов.

SOA - это всего лишь иной стиль построения современных корпоративных систем. Он ориентируется на сервисы, характеризуется распределенной архитектурой и слабосвязанными интерфейсами. Сервис в данном случае - это не что иное, как единица работ, выполняемая сервис-провайдером для обеспечения желаемого результата потребителю сервиса. Именно сервис, а не объект, как в ООП, является повторно используемым, и при этом он не зависит от технологий, языковых сред и других ресурсов. Интегрирующую роль между сервис-провайдером и потребителем берут на себя программные агенты. Ряд архитектурных особенностей SOA позволяет уменьшить степень связанности различных элементов системы. Для взаимодействия компонентов используется сравнительно небольшой набор простых интерфейсов, которые обладают только самой общей семантикой и доступны всем провайдерам и потребителям. Через эти интерфейсы передаются сообщения, ограниченные некоторым словарем. А поскольку даны только общая структура корпоративной системы и словарь, то вся семантика и бизнес-логика, специфичная для приложений, описывается непосредственно в этих сообщениях.

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

Отметим некоторые из этих принципов.

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

Постоянство изменений. Отдельные участки архитектуры могут претерпевать изменения в любой момент времени.

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

Рекурсивность. Однотипные решения имеют место на различных уровнях архитектуры.

Как бы неожиданно это ни показалось, перечисленные принципы были сформулированы американским архитектором Кристофером Александером в отношении архитектуры современного мегаполиса. В 1987 году он и его коллеги опубликовали работу под названием «Новая теория городского проектирования» (A New Theory of Urban Design), где излагались взгляды на возможность децентрализованного развития городов. В своей работе Александр показал, как можно осуществлять развитие городов с учетом существенной демографической разнородности жителей. Аналогичным образом SOA, основанная на адаптации этих принципов, позволяет объединить в общий взаимодействующий организм информационные системы, принадлежащие различным автономным организациям и их относительно автономным структурным подразделениям.

Общая схема.

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

Рис. 2. Общая схема SOA

Для использования сервиса необходимо следовать соглашению об интерфейсе для обращения к сервису - интерфейс должен не зависеть от платформы. SOA реализует масштабируемость сервисов - возможность добавления сервисов, а также их модернизацию. Поставщик сервиса и его потребитель оказываются несвязанными - они общаются с помощью сообщений. Поскольку интерфейс должен не зависеть от платформы, то и технология, используемая для определения сообщений, также должна не зависеть от платформы. Поэтому, как правило, сообщения являются XML-документами, которые соответствуют XML-схеме.

Модель SOA не зависит от технологий, использующихся для реализации SOA, а основным методологически значимым ее компонентом является реестр сервисов. В обозначенном на схеме асинхронном протоколе общения провайдера и потребителя сервисов он выполняет функции посредника. Провайдер размещает информацию о своих сервисах в реестре, что дает возможность потребителю в любой момент найти необходимый ему сервис. На первый взгляд, кажется, что в этом нет ничего особенного, однако за этим процессом общения скрывается основное качество SOA -- слабая связанность. Благодаря этому свойству, сервисы обретают мобильность, способность перемещаться с одного сервера на другой, не требуя согласования и координации со всеми потребителями. Естественно, что потребители сервисов в ряде случаев не способны и не должны принимать во внимание регулярное перераспределение ресурсов, обеспечивающих функционирование сервисов.

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

В SOA сервисы рассматриваются как автономные объекты, управление которыми не централизовано. Это позволяет взаимодействующим посредством сервисов информационным системам развиваться в соответствии с потребностями бизнеса, которые потребителям сервисов, как правило, не только не известны, но и не интересны. Однако это было бы невозможно, если бы интерфейс сервиса не был прочно закреплен обоюдным соглашением провайдера и потребителя сервиса. Одной из отличительных черт SOA является наличие контрактов, описывающих интерфейсы сервисов. Такой контракт представляет собой документ, специфицирующий ожидания сервиса по отношению к его потребителям и наоборот. Контракты Web-сервисов описываются WSDL-документом, в нотации XML определяющим, как потребители должны обращаться к сервису. Использование XML на этом этапе имеет принципиальное значение, позволяя и провайдеру, и потребителю сервиса не зависеть от определенной платформы.

Подобные контракты существовали и до появления Web-сервисов. Например, в архитектуре CORBA для описания интерфейса объектов использовался язык IDL, который уступает WSDL по ряду существенных параметров. Главный из них -- отсутствие поддержки XML и XML Schema, ставших наиболее распространенными языками разметки передаваемых по сети сообщений и представления моделей данных. Технические контракты, формулируемые провайдером сервисов, должны быть доступны потенциальным потребителям для интерпретации, анализа и реализации интеграции. Для этого используется специальный реестр, каталогизирующий доступные сервисы.

3. Базовые стандарты SOA

Набор базовых стандартов SOA держится на трех «китах». В их число, кроме WSDL и UDDI, входит протокол SOAP -- простой механизм для создания структурированных пакетов данных, предназначенных для обмена информацией между сервисами (сетевыми приложениями). Эту тройку стандартов объединяет то, что все они построены на базе языка XML и являются открытыми, то есть их развитием занимаются независимые комитеты по стандартизации. Чтобы понять, как они работают вместе, сравним технологию Web-сервисов с общением по телефону. В таком случае XML -- это язык, на котором ведется разговор, SOAP описывает правила набора номера, UDDI представляет собой телефонную книгу, а WSDL объясняет, что такое разговор по телефону и как его вести.

4. Реестр сервисов

Сейчас в области Web-сервисов сложились две группировки: одна включает IBM, BEA и Microsoft, а вторая -- Sun, Fujitsu и Oracle. Каждая из них продвигает свои разработки. Например, для управления транзакциями первая предлагает протокол WS-Transactions, а вторая -- WS-Transactions Management; для гарантированной доставки сообщений первая выпустила WS-ReliableMessaging, а вторая -- WS-Reliability. И так -- по всем направлениям технологии Web-сервисов. В результате на роль «заполнителей дыр» в SOA сейчас претендует множество различных методов, но явного лидера нет.

Была создана организация Web Services-Interoperability (http://www.ws-i.org/), которая пытается выработать некий общий знаменатель для технологии Web-сервисов. В августе нынешнего года она выпустила документ WS-I Basic Profile 1.1, определяющий требования к различным компонентам SOA, которые могут гарантировать их совместимость и прояснить тонкости использования Web-сервисов. Программный интерфейс реестра сервисов составляет часть стека протоколов взаимодействия. В наборе технологий Web-сервисов таким стандартом является UDDI (Universal Description, Discovery and Integration). Его спецификация является единственной из ядра основополагающих стандартов Web-сервисов, разработанной вне рамок консорциума World Wide Web Consortium. Таким ядром принято считать спецификации, входящие в профиль WS-I Basic Profile, призванный обеспечить общую для различных инструментальных платформ базу взаимно совместимых технологий описания, публикации, обнаружения и вызова сервисов.

Для разработки данной спецификации в 2000 году был сформирован Консорциум UDDI (UDDI.org), объединивший более 200 корпоративных членов. В соответствии со своим трехлетним мандатом, консорциум выпустил три версии спецификации и перестал существовать в 2003 году. Уже зрелый стандарт, реализованный многими разработчиками, UDDI был передан в организацию Organization for the Advancement of Structured Information Standards (OASIS), занимающую важное место в мире ИТ-стандартов. Текущей версией UDDI, официально принятой в качестве стандарта OASIS, является вторая; ратификация третьей версии ожидается в конце лета этого года, а технический комитет UDDI в составе OASIS уже разрабатывает очередную порцию нововведений.

UDDI обладает весьма развитой функциональностью, существенно более богатой чем, аналогичный компонент набора стандартов CORBA -- CORBA Naming Service. В отличие от предыдущих поколений реестров, UDDI был изначально нацелен на применение как внутри организаций, так и между ними, поэтому реестры UDDI одинаково удобны для ведения информации о нескольких или о тысячах сервисах. Для этого UDDI предусматривает гибкую информационную модель и средства распределения доступа. C точки зрения применимости UDDI в SOA, наиболее методологически значимым элементом информационной модели UDDI является возможность стандартизации типов сервисов (рис. 3). Интерфейс сервиса, описанный WSDL-документом, или даже отдельную его характеристику (скажем, стоимость или поддержка некоего протокола, такого, как HTTP Basic или WS-Security для авторизации) можно представить самостоятельным объектом метаданных в UDDI. Совокупность ссылок на такие объекты характеризует профиль интероперабельности данного сервиса. Используя те или иные параметры, потребитель может найти в реестре сервис, соответствующий его техническим или деловым потребностям.

Рис. 3. Стандартизация типов сервисов

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

С момента публичного представления первой версии UDDI функционирует общедоступный реестр UDDI Business Registry (UBR), который сейчас состоит из четырех географически распределенных реплицируемых узлов: Microsoft (западное побережье США), IBM (восточное побережье США), SAP (Европа) и NTT Telecom (Азия). Наиболее популярным применением UDDI все же остается организация закрытого сообщества взаимодействующих информационных систем либо внутри компании, либо в строго ограниченном кругу ее деловых партнеров. Очевидно, что частный реестр UDDI при этом является центральным звеном корпоративной сервис-ориентированной архитектуры.

5. Оркестровка

Весьма интересна терминология, связанная с веб-сервисами. Так, средства обмена сообщениями, с помощью которых несколько независимых агентов стремятся достичь желаемого состояния, получили название "хореографии", а взаимодействие сервисов - "оркестровки". Для "оркестровки" (т.е., по сути, описания бизнес-логики) были разработаны (с участием крупнейших вендоров, таких, как IBM, Microsoft, Oracle и BEA Systems) специальные средства программирования - BPEL4WS, XLANG, WSFL и др.

Оркестровка относится к определению бизнес-процесса, который может взаимодействовать с внешними и внутренними Web-сервисами. Происходящие на основе обмена сообщениями взаимодействия включают бизнес-логику и порядок выполнения задач; они могут выходить за границы приложений и организаций, определяя долговременную, транзакционную, многошаговую бизнес-модель. Оркестровка всегда представляет управление с позиций одного участника процесса. Хореография позволяет каждому участнику описать свою часть взаимодействия. При использовании хореографии отслеживаются последовательности сообщений между несколькими участниками и источниками. Предлагаемые стандарты оркестровки и хореографии должны удовлетворять нескольким требованиям, относящимся к языку описания потока работ бизнес-процесса и инфраструктуре выполнения процесса. К числу этих требований относятся асинхронный вызов службы; управление исключительными ситуациями и обеспечение транзакционной целостности на основе компенсационного подхода; динамичность, гибкость и адаптируемость оркестровки к изменению потребностей бизнеса; возможность композиции сервисов более высокого уровня из существующих оркестрованных процессов.

К ранним языкам определения бизнес-процессов путем комбинирования Web-сервисов относятся XLANG компании Microsoft (www.gotdotnet.com/team/ xml_wsspecs/xlang_c/default.htm) и Web Services Flow Language (WSFL) компании IBM (www-3.ibm.com/software/solutions/ webservices/pdf/WSFL.pdf). XLANG основан на языке WSDL; его основное назначение состоит в определении бизнес-процессов и организации обмена сообщениями между Web-сервисами. WSFL позволяет описывать как публичные, так и частные процессы. Определяется обмен данными, последовательность выполнения и отображение каждого шага процесса на конкретные операции.

6. Что такое Web-сервисы

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

Любой разговор о SOA невольно переходит на рассуждение о роли и месте Web-сервисов. Несмотря на то, что основные положения SOA сложились задолго до появления Web-сервисов, сегодня Web-сервисы занимают центральное место в SOA. Использование XML и Web-сервисов "поднимает SOA на более высокий уровень". Действительно, открытые стандарты, описывающие XML и Web-сервисы, позволяют применять SOA ко всем технологиям и приложениям, установленным в компании. Как известно, Web-сервисы базируются на широко распространенных и открытых протоколах: HTTP, XML, UDDI, WSDL и SOAP. Именно эти стандарты реализуют основные требования SOA - во-первых, сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен использоваться независящий от платформы интерфейс (XML). Наконец, HTTP обеспечивает функциональную совместимость. Наконец, сегодня Web-сервисы рассматриваются как эффективный инструмент для интеграции, в том числе для взаимодействия процессов, выполняемых в различных компаниях.

Пример.

Для демонстрации возможностей SOAP может быть использована недавно вышедшая реализация SOAP Toolkit версии 2.0 производства Microsoft. Объект SOAPClient выступает в роли посредника (proxy), предоставляющего интерфейс Web-сервиса и позволяющего работать с ним как с обычным COM-объектом.

Рис. 4. Механизм взаимодействия клиента и сервера SOAP

Клиентское приложение создает экземпляр объекта SOAPClient. SOAPClient читает файлы описания методов Web-сервиса (на языках WSDL и Web Services Meta Language, WSML). Эти файлы могут храниться и на стороне клиента. Клиентское приложение, используя возможности позднего связывания методов объекта SOAPClient, вызывает метод сервиса. SOAPClient формирует пакет запроса (SOAP Envelope) и отправляет его на сервер. Можно применить любой транспортный протокол, но, как правило, используется HTTP.

Серверное приложение Listener (это может быть ISAPI-приложение или ASP-страница) принимает пакет, создает объект SOAPServer и передает ему пакет запроса. Помимо этого Listener обрабатывает HTTP-пакеты от клиента, отправляет клиенту пакеты с результатом работы сервиса, обрабатывает ошибки и использует функциональность SOAP-объектов. SOAPServer читает описание Web-сервиса, загружает описание и пакет запроса в деревья XML DOM. SOAPServer вызывает метод объекта или приложения, реализующего сервис. Результаты выполнения метода или описание ошибки конвертируются объектом SOAPServer в пакет ответа и отправляются клиенту. Объект SOAPClient проводит разбор принятого пакета и возвращает клиентскому приложению результаты работы сервиса или описание возникшей ошибки.

WSDL-файл - это документ в формате XML, описывающий методы, предоставляемые Web-сервисом, а также параметры методов, их типы, названия и местонахождение сервиса Listener. Мастер SOAP Toolkit автоматически генерирует этот документ, фрагмент которого приведен ниже: SOAP Envelope (Пакет) - это XML-документ, который содержит в себе запрос на выполнение метода или ответ на него. Удобнее всего рассматривать пакет как почтовый конверт, в который вложена информация.

Рис. 5. Структура SOAP-пакета

7. Четыре уровня адаптации SOA

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

Уровень 1.

Реализация отдельных Web-сервисов. Это начальный уровень развертывания SOA, на котором технологии Web-сервисов используются для разработки новых приложений или преобразования существующих, например, для интеграции с помощью WSDL-интерфейсов систем, написанных на С++, Cobol и Java. Здесь компании должны реализовать этапы создания и развертывания сервисов. Для создания предлагается инструментарий WebSphere Studio Application Developer, а также набор средств Emerging Technology Toolkit, который позволяет разработчикам опробовать новые решения в области Web-служб. Развертывание Web-сервисов поддерживается сервером приложений WebSphere Application Server.

Уровень 2.

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

Говоря об интеграции, мы подразумеваем взаимодействие между сервисами в SOA на уровне интерфейсов. Однако надо иметь в виду, что в реальной ИТ-инфраструктуре, где будет происходить переориентация на сервисы, проблема интеграции может оказаться гораздо шире, и необходимо будет учитывать различные типы и стили интеграции. Назовем некоторые из них. Интеграция на уровне пользовательского интерфейса. Получение удобного и эффективного интерфейса для взаимодействия пользователя со средой интегрированных сервисов. Эта область интеграции связана с развитием портальных технологий.

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

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

Интеграция унаследованных систем. Здесь стоит выделить еще одну архитектурную концепцию, используемую для сервисно-ориентированной интеграции. Речь идет о концепции сервисной шины предприятия (enterprise service bus, ESB). Ее задача -- предоставить единый механизм передачи запросов и получения результатов сервисов, выполнения необходимых преобразований сообщений и транспортных протоколов (скажем, от SOAP на базе HTTP к SOAP на основе WebSphere MQ), обеспечения требований безопасности доступа и, что наиболее важно, управления потоком обращений к сервисам. Благодаря такому управлению выполняется нужная последовательность вызовов сервиса для реализации бизнес-процесса; определение процесса как серии обращений к сервисам поддерживается, например, в разработанном усиловиями IBM и Microcoft языке Business Process Execution Language (BPEL). Обратившись к схематичной иллюстрации шины ESB (рис. 3), можно увидеть, что этот подход решает одну из главных проблем интеграции -- проблему минимизации интерфейсов. Добавление нового сервиса к общей картине приведет к появлению одного и только одного дополнительного интерфейса для интеграции с остальными компонентами архитектуры.

Рис. 6. Модель сервисной шины

Все задачи интеграции, отображения бизнес-процессов компании в сервисы -- предмет реализации на втором и третьем уровнях перехода к SOA в трактовке IBM. На этих уровнях вступают в действие все четыре этапа жизненного цикла сервисов, и используется множество программных продуктов. Второй уровень -- это реализация SOA для ограниченного числа подразделений в компании. Здесь, на этапе создания к средствам разработки WebSphere Studio Application Developer добавляется система WebSphere Host Access Transformation Services. Для развертывания используется поддерживающий язык BPEL сервер интеграции бизнес-процессов WebSphere Business Integration Server Foundation и шлюзы CICS Tranaction Gateway или IMS Connect. Для использования полученных возможностей предлагается WebSphere Portal, а функции управления возлагаются на модули семейства Tivoli -- Access Manager и Monitoring for Transaction Performance.

Уровень 3.

Трансформация ИТ-инфраструктуры в масштабе предприятия. Здесь речь идет о сервисно-ориентированной интеграции приложений и процессов уже в масштабах всей компании, причем согласованный, сервисный подход к ИТ-инфраструктуре распространяется не только на внутренние подразделения, но и на партнеров и поставщиков. Здесь вступают в действие системы, обеспечивающие более глубокую детализацию разработки и интеграцию сервисов с учетом всех уже рассмотренных типов интеграции. IBM предлагает WebSphere Business Integration Modeler и Rational Rose XDE для этапа создания сервисов, WebSphere Business Integration Message Broker для развертывания, DB2 Information Integrator и Lotus Workplace для стадии использования. Управление такой полноценной средой SOA реализуется с помощью инструментов семейства Tivoli -- Identity Manager, Business System Manager и Monitoring for Business Integration, а также WebSphere Business Integration Monitor.

По данным IDC, до 2003 года включительно, большинство организаций, проявивших практический интерес к технологиям Web-сервисов, тратили свои средства и усилия на разработку отдельных сервисов и изучение возможностей их использования в корпоративной инфраструктуре. Сейчас для них наступает новый этап, состоящий в интеграции сервисов в единую среду и решении задач управления ею и обеспечения безопасности. Таким образом, второй и третий уровень адаптации SOA приобретают вполне практический смысл.

Уровень 4.

Изменения в бизнесе. Последний уровень связан с изменениями в самих способах ведения бизнеса в ответ на глобальные трансформации ИТ-инфраструктуры. Здесь надо обратить внимание на связь между SOA и стратегией on-demand computing, которую проповедует IBM и которой подчинена вся стратегия развития ее программных и аппаратных решений. SOA становится архитектурной основой для реализации принципов данной стратегии на прикладном уровне благодаря гибкости, которую обеспечивает сервисный подход к реализации и развертыванию приложений. В SOA для поддержки бизнес-процессов используются не монолитные приложения, а динамичные сервисы, и потому всякое изменение в требованиях для решения бизнес-задач быстро получит адекватное отражение на уровне приложений: необходимые сервисы будут найдены, реконфигурированы и собраны в единое целое.

8. Проблемы SOA

Несогласованность стандартов. В области Web-сервисов сложились две группировки: одна включает IBM, BEA и Microsoft, а вторая -- Sun, Fujitsu и Oracle. Каждая из них продвигает свои разработки. Например, для управления транзакциями первая предлагает протокол WS-Transactions, а вторая -- WS-Transactions Management; для гарантированной доставки сообщений первая выпустила WS-ReliableMessaging, а вторая -- WS-Reliability. (Стоит отметить, что после анонсирования Microsoft Visual Studio Team System, а также предложений IBM по конкретным решениям, основанным на SOA, это противостояние стало минимальным, и можно ожидать продвижения в разработке единых стандартов, регламентирующих использование Web-сервисов).

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

9. Достоинства

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

Внедрение не требует полной перестройки корпоративной инфраструктуры. Предприятиям не нужно отказываться от привычных, хорошо себя зарекомендовавших приложений. Достаточно снабдить их соответствующими интерфейсами -- и Web-сервисы готовы. «Практическая ценность SOA для бизнеса заключается в возможности постепенного эволюционного развития корпоративной информационной инфраструктуры». Благодаря Web-сервисам бизнес-менеджеры могут гораздо активнее участвовать в создании корпоративных приложений. Правда, пока это лишь теоретическая возможность: необходимы специальные инструменты, позволяющие создавать сервисы без программирования. Но они уже начинают появляться. Например, компания UnitSpace выпустила ПО промежуточного слоя BCR. Оно позволяет адаптировать приложения к SOA, создавая Web-сервисы на основе заданных бизнес-аналитиками метаданных, без программирования. «Средства автоматического преобразования форматов позволяют приложениям обмениваться данными на основе их общей семантики, а выполнением бизнес-процессов управлять с помощью сценариев, написанных на стандартном языке BPEL.

Новая архитектура дает предприятию возможность быстрее адаптироваться к изменяющимся условиям: можно быстро заменить одну реализацию сервиса на другую, не меняя его интерфейс. Использование открытых стандартов вместо закрытых протоколов делает архитектуру SOA независимой от платформ. «SOA поднимет на новый уровень интеграцию, обеспечивая взаимодействие гетерогенных систем». Сервис-ориентированная архитектура предлагает разработчикам совершенно иной подход к многократному использованию кода. Вместо традиционного объектно-ориентированного наследования предполагается композиция, то есть создание более сложных сервисов из сервисов низкого уровня. При этом преодолевается основное ограничение наследования -- сервисы могут быть распределены в сети и даже принадлежать различным компаниям. Попутно композиция нивелирует эффекты специализации, интегрируя элементарные операции в бизнес-функции соответствующего уровня восприятия.

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

Литература

1. Сергей Кузнецов. Обзор октябрьского 2003 года номера журнала Computer (IEEE Computer Society, Vol. 36, No. 10, October 2003).

2. Валентин Колесов Демонстрация работы SOAP на примере написания Web-сервер.

3. Отчет "Сервис-ориентированная архитектура" (Service Oriented Architecture. InfoWorld Research Report. 2005).

4. Хао Хи (Hao He) "Что такое сервис-ориентированная архитектура" (What is Service-Oriented Architecture?).

5. Клив Финкельштейн (Clive Finkelstein) "Корпорация: сервис-ориентированная архитектура" (The Enterprise: Service-Oriented Architecture (SOA)).

6. Джерими Уэстерман (Jeremy Westerman) "Сервис-ориентированная архитектура сегодня: введение в SOA" (SOA Today: Introduction to Service-Oriented Architecture).

7. Владимир Беленкович, Тимофей Горшков Логическая структура понятия сервисов в рамках SOA.

8. Елена Гореткина Непростой путь от Web-сервисов к SOA.

9. Даниил Фейгин Концепция SOA.

10. Наталья Дубова SOA: подходы к реализации.

Размещено на Allbest.ru