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

SOA — это компонентная модель, в которой разные функциональные единицы
приложений, называемые сервисами, взаимодействуют по сети посредством
интерфейсов. Расшифруем данные определения.
1. Все функции приложений определены как сервисы. В качестве сервиса
может выступать как целое приложение, так и отдельные его
функциональные модули. Сервисами могут быть прикладные функции,
реализующие определенную бизнес-логику, бизнес-транзакции, состоящие
из нескольких функций более низкого уровня, и системные функции,
отражающие специфику различных операционных платформ.
2. Все сервисы независимы друг от друга. Они выполняют определенные
действия по запросам, полученным от других сервисов, и возвращают
результаты. Все детали этого полностью скрыты: в концепции SOA сервисы
- это "черные ящики".
3. В интерфейсе сервиса определены параметры и описан результат.
Иными словами, интерфейс определяет суть сервиса, а не технологию его
реализации. На архитектурном уровне для обращения к сервису не имеет
значения, является он локальным (реализован в данной системе) или
удаленным (внешний по отношению к ней), какой протокол используется
для передачи вызова, какие компоненты инфраструктуры при этом
задействованы. SOA предполагает наличие единой схемы обращения к
сервису независимо от того, находится ли они в том же самом приложении,
в другом адресном пространстве многопроцессорной системы, на другой
аппаратной платформе в корпоративной intranet-сети или в приложении в
системе партнера.
Архитектура SOA.
SOA - это всего лишь иной стиль построения современных корпоративных
систем. Он ориентируется на сервисы, характеризуется распределенной
архитектурой и слабосвязанными интерфейсами. Сервис в данном случае - это не
что иное, как единица работ, выполняемая сервис-провайдером для обеспечения
желаемого результата потребителю сервиса. Именно сервис, а не объект, как в
ООП, является повторно используемым, и при этом он не зависит от технологий,
языковых сред и других ресурсов. Интегрирующую роль между сервиспровайдером и потребителем берут на себя программные агенты.
Ряд архитектурных особенностей SOA позволяет уменьшить степень
связанности различных элементов системы. Для взаимодействия компонентов
используется сравнительно небольшой набор простых интерфейсов, которые
обладают только самой общей семантикой и доступны всем провайдерам и
потребителям. Через эти интерфейсы передаются сообщения, ограниченные
некоторым словарем. А поскольку даны только общая структура корпоративной
системы и словарь, то вся семантика и бизнес-логика, специфичная для
приложений, описывается непосредственно в этих сообщениях.
Сами Web-сервисы не предполагают какого-либо архитектурного решения,
в то время как именно архитектурой определяется стиль процессов
взаимодействия. SOA не предписывает жесткой вертикальной («сверху вниз»)
методологии проектирования, внедрения или управления ИТ-инфраструктурой.
Вместо этого, SOA ограничивается лишь рядом принципов, характеризующих
каждый из этих процессов; поэтому ее иногда называют не архитектурой, а
архитектурным стилем.
Отметим некоторые из этих принципов.
1. Распределенное проектирование. Решения относительно внутренних
особенностей информационных систем принимаются различными группами
людей, имеющими собственные организационные, политические и
экономические мотивы.
2. Постоянство изменений. Отдельные участки архитектуры могут
претерпевать изменения в любой момент времени.
3. Последовательное совершенствование. Локальное улучшение компонентов
архитектуры должно приводить к совершенствованию всей архитектуры в
целом - к росту суммарной полезности компонентов того же уровня, что и
изменяемый, равно как и компонентов более низкого и более высокого
уровня.
4. Рекурсивность. Однотипные решения имеют место на различных уровнях
архитектуры.
Общая схема.
В самом общем виде SOA предполагает наличие трех основных участников:
поставщика сервиса, потребителя сервиса и реестра сервисов (см. рис. 1).
Взаимодействие участников выглядит достаточно просто: поставщик сервиса
регистрирует свои сервисы в реестре, а потребитель обращается к реестру с
запросом. ). Отсутствие любого из этих элементов недопустимо, а добавление
других составляющих на практике не только возможно, но и неизбежно. Среди
таких элементов могут быть всевозможные программные средства промежуточного
слоя, контролирующие порядок и контекст взаимодействия, осуществляющие
мониторинг и управление сервисами, а также управление метаданными и другие
вспомогательные процессы.
Рис. 1. Общая схема SOA
Для использования сервиса необходимо следовать соглашению об
интерфейсе для обращения к сервису - интерфейс должен не зависеть от
платформы. SOA реализует масштабируемость сервисов - возможность
добавления сервисов, а также их модернизацию. Поставщик сервиса и его
потребитель оказываются несвязанными - они общаются с помощью сообщений.
Поскольку интерфейс должен не зависеть от платформы, то и технология,
используемая для определения сообщений, также должна не зависеть от
платформы. Поэтому, как правило, сообщения являются XML-документами,
которые соответствуют XML-схеме.
Модель SOA не зависит от технологий, использующихся для реализации
SOA, а основным методологически значимым ее компонентом является реестр
сервисов. В обозначенном на схеме асинхронном протоколе общения провайдера и
потребителя сервисов он выполняет функции посредника. Провайдер размещает
информацию о своих сервисах в реестре, что дает возможность потребителю в
любой момент найти необходимый ему сервис. На первый взгляд кажется, что в
этом нет ничего особенного, однако за этим процессом общения скрывается
основное качество SOA — слабая связанность. Благодаря этому свойству, сервисы
обретают мобильность, способность перемещаться с одного сервера на другой, не
требуя согласования и координации со всеми потребителями. Естественно, что
потребители сервисов в ряде случаев не способны и не должны принимать во
внимание регулярное перераспределение ресурсов, обеспечивающих
функционирование сервисов.
Позднее связывание также позволяет отложить момент конечной сборки
связей до времени исполнения, а не времени разработки программы, что
характерно для традиционных монолитных систем. Можно также во время
исполнения менять параметры связи (такие как адрес, протокол и канал
взаимодействия). Это придает несколько измерений гибкости самой связке между
провайдером и потребителем сервиса — соответственно вызываемым и
осуществляющим вызов объектами. В частности, провайдер и потребитель могут
исполняться на сколь угодно физически удаленных инфраструктурах. Каждая из
систем может иметь собственные параметры жизненного цикла, а любые
изменения в них, не затрагивающие интерфейс сервиса, не требуют остановки ни
одной из них.
В SOA сервисы рассматриваются как автономные объекты, управление
которыми не централизовано. Это позволяет взаимодействующим посредством
сервисов информационным системам развиваться в соответствии с потребностями
бизнеса, которые потребителям сервисов, как правило, не только не известны, но и
не интересны. Однако это было бы невозможно, если бы интерфейс сервиса не был
прочно закреплен обоюдным соглашением провайдера и потребителя сервиса.
Одной из отличительных черт SOA является наличие контрактов,
описывающих интерфейсы сервисов. Такой контракт представляет собой документ,
специфицирующий ожидания сервиса по отношению к его потребителям и
наоборот. Контракты Web-сервисов описываются WSDL-документом, в нотации
XML определяющим, как потребители должны обращаться к сервису.
Использование XML на этом этапе имеет принципиальное значение, позволяя и
провайдеру, и потребителю сервиса не зависеть от определенной платформы.
Технические контракты, формулируемые провайдером сервисов, должны
быть доступны потенциальным потребителям для интерпретации, анализа и
реализации интеграции. Для этого используется специальный реестр,
каталогизирующий доступные сервисы.
Базовые стандарты SOA.
Набор базовых стандартов SOA держится на трех «китах». В их число, кроме
WSDL и UDDI, входит протокол SOAP — простой механизм для создания
структурированных пакетов данных, предназначенных для обмена информацией
между сервисами (сетевыми приложениями). Эту тройку стандартов объединяет то,
что все они построены на базе языка XML и являются открытыми, то есть их
развитием занимаются независимые комитеты по стандартизации.
Чтобы понять, как они работают вместе, сравним технологию Web-сервисов с
общением по телефону. В таком случае XML — это язык, на котором ведется
разговор, SOAP описывает правила набора номера, UDDI представляет собой
телефонную книгу, а WSDL объясняет, что такое разговор по телефону и как его
вести.
Рис. 3. Стандартизация типов сервисов
Пример.
Для демонстрации возможностей SOAP может быть использована реализация
SOAP Toolkit версии 2.0 производства Microsoft.
Объект SOAPClient выступает в роли посредника (proxy), предоставляющего
интерфейс Web-сервиса и позволяющего работать с ним как с обычным COMобъектом (рис. 1).
Рис. 1. Механизм взаимодействия клиента и сервера SOAP.
1. Клиентское приложение создает экземпляр объекта SOAPClient.
2. SOAPClient читает файлы описания методов Web-сервиса (на языках WSDL
и Web Services Meta Language, WSML). Эти файлы могут храниться и на
стороне клиента.
3. Клиентское приложение, используя возможности позднего связывания
методов объекта SOAPClient, вызывает метод сервиса. SOAPClient
формирует пакет запроса (SOAP Envelope) и отправляет его на сервер.
Можно применить любой транспортный протокол, но, как правило,
используется HTTP.
4. Серверное приложение Listener (это может быть ISAPI-приложение или
ASP-страница) принимает пакет, создает объект SOAPServer и передает ему
пакет запроса. Помимо этого Listener обрабатывает HTTP-пакеты от
клиента, отправляет клиенту пакеты с результатом работы сервиса,
обрабатывает ошибки и использует функциональность SOAP-объектов.
5. SOAPServer читает описание Web-сервиса, загружает описание и пакет
запроса в деревья XML DOM.
6. SOAPServer вызывает метод объекта или приложения, реализующего
сервис.
7. Результаты выполнения метода или описание ошибки конвертируются
объектом SOAPServer в пакет ответа и отправляются клиенту.
8. Объект SOAPClient проводит разбор принятого пакета и возвращает
клиентскому приложению результаты работы сервиса или описание
возникшей ошибки.
WSDL-файл - это документ в формате XML, описывающий методы,
предоставляемые Web-сервисом, а также параметры методов, их типы, названия и
местонахождение сервиса Listener. Мастер SOAP Toolkit автоматически генерирует
этот документ, фрагмент которого приведен ниже:
SOAP Envelope (Пакет) - это XML-документ, который содержит в себе запрос на
выполнение метода или ответ на него. Удобнее всего рассматривать пакет как
почтовый конверт, в который вложена информация (рис. 2).
Рис. 2. Структура SOAP-пакета.
[http://masu-inform.ru:8888/]
Технологии реализации
Инфраструктура интеграции и управления сервисами. Для организации
взаимодействия сервисов необходима среда, которая обеспечит динамическую
маршрутизацию запросов от прикладного компонента — потребителя сервиса и
получение результатов от приложения — провайдера сервиса. Для этого может
потребоваться поддержка синхронных и асинхронных коммуникаций более
низкого уровня между приложениями, трансформация и высокоскоростное
распределение данных, трансляция протоколов, кэширование функций Webсервисов, виртуализация ввода/вывода и т. д. Для решения этих задач все большее
распространение получает технология корпоративной сервисной шины (Enterprise
Service Bus, ESB), которая предоставляет единый механизм для передачи запросов
и получения результатов сервисов, выполнения необходимых преобразований
сообщений и транспортных протоколов и управления потоком обращений к
сервисам.
Инфраструктура безопасности сервисов. На основе корпоративных политик
безопасности должны быть определены и обеспечены технологические правила
доступа и использования прикладных ресурсов, организованных в виде сервисов. В
частности, должна быть решена задача управления правами доступа пользователя к
сервисам, которые могут инкапсулировать функции нескольких приложений.
Инфраструктура автоматизации и управления бизнес-процессами.
Конечная цель SOA — обеспечить представление бизнес-процессов как
взаимодействующих сервисов. Средства управления бизнес-процессами
обеспечивают интеграцию в нужной последовательности сервисов, которые могут
быть как локальными — реализованными в ИТ-инфраструктуре компании, так и
удаленными, если процесс на определенных этапах обращается к ресурсам
партнерских компаний. Стандартом для такой интеграции, которая в
профессиональном лексиконе обозначается терминами «хореография» или
«оркестровка» сервисов, становится разработанный IBM и Microsoft язык Business
Process Execution Language (BPEL).
[http://ww.prostoy.ru/273.html]
Сервис-ориентированная архитектура - эффективный метод снижения затрат
Новые исследования показывают, что сервис-ориентированная архитектура, как
эффективный инструмент экономии затрат на информационные технологии, становится
все более популярной.
Большинство IT-директоров понимают, что внедрение сервис-ориентированной
архитектуры (СОА) позволит компаниям определить и использовать критически
необходимые сервисы, особенно в свете экономического кризиса. В Великобритании
компания Software AG (разработчик программного обеспечения по автоматизации бизнеспроцессов) провела опрос более чем 100 IT -директоров различных компаний. 83% из них
заявили, что они намерены использовать СОА для сокращения расходов, а 40% планирует
внедрить технологию СОА уже в текущем году. Модульный подход использования
сервисов является эффективным способом разработки программного обеспечения и
построения распределённых программных комплексов.
По мнению Тима Хольейка, ведущего технолога Software AG, "серьезные проблемы в
экономике вынуждают многие компании существенно сократить расходы на внедрение
нового программного обеспечения, повторно используя существующие системы".
"Модульный подход к разработке программного обеспечения, являющийся основным
принципом СОА, гарантирует наилучший возврат инвестиций в программное обеспечение.
Это более эффективный путь, чем тратить деньги на полную замену уже имеющихся
компьютерных систем".
"Использование СОА поможет компаниям резко снизить операционные расходы
путем обмена сервисами и процессами в различных областях применения"
Опрос также показал, что 83% компаний были весьма обеспокоены эффективностью
бизнеса в 2010 году. Кроме того, в общей сложности 82% респондентов считают, что для
достижения наибольшей эффективности в их организации, скорее всего, будут сделаны
инвестиции именно в программное обеспечение.
По прогнозу IDC, аналитической фирмы, специализирующейся на исследованиях
рынка информационных технологий, затраты на внедрение сервис-ориентированной
архитектуры в сфере бизнеса к 2013 году возрастут на 25%.
Система "Простой Бизнес" использует принципы предоставления и потребления
услуг, автоматизируя процесс обмена как собственными, так и сторонними услугами среди
компаний, зарегистрированных в системе. Опыт и обратная связь позволяют оценить
показатели качества и эффективности, формируя рейтинг компаний. Это позволяет
фирмам, которые участвуют в процессе развития, экономить на поиске и приобретении
услуг, находящихся вне пределов их компетенции, не экономя при этом на качестве.
ВЫБОР КОРПОРАТИВНОЙ СЕРВИСНОЙ ШИНЫ С ОТКРЫТЫМ
ИСХОДНЫМ КОДОМ В СОСТАВЕ ИС НА ОСНОВЕ СЕРВИСНООРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ
И.В. Маурина
Государственный научно-исследовательский институт информационных
технологий и телекоммуникаций «Информика», г. Москва
Интеграция информационных систем различного класса остается актуальной темой для
многих компаний и государственных организаций. Для повышения эффективности и
прозрачности деятельности важно организовать сквозные бизнес-процессы и обеспечить
взаимодействие различных информационных систем.
Решением стал подход, основанный на использовании сервисов. Информационные
системы разбиваются на функционально законченные, независимые компоненты (сервисы),
каждый из которых предназначен для выполнения определенной. Для выполнения бизнеспроцесса необходимо обеспечить вызов сервисов в нужной последовательности. ИТархитектура, основанная на выделении и взаимодействии сервисов, получила название SOA
(service-oriented architecture). Одним из наиболее распространенных вариантов реализации
сервисов в SOA является использование web-сервисов.
Объединение концепций сервисов, управления бизнес-процессами и серверов
интеграции привело к созданию нового класса интеграционных решений – корпоративных
сервисных шин (Enterprise Service Bus). В настоящее время именно ESB является наиболее
развитым инструментарием для выполнения сложных и масштабных проектов интеграции.
При выполнении интеграции, в особенности, если речь идет о сложных и масштабных
проектах, ключевым вопросом можно назвать выбор оптимальной платформы, которая
позволит обеспечить надежность и быстродействие при совместной работе нескольких
систем.
ESB – подход к построению распределённых корпоративных информационных систем.
Обычно включает в себя промежуточное ПО, которое обеспечивает взаимосвязь между
различными приложениями по различным протоколам взаимодействия.
Одним из стандартов взаимодействия являются веб-сервисы. В популярных
реализациях ESB добавляются шлюзы для обмена данными с корпоративным ПО. С
использованием ESB может быть реализована сервисно-ориентированная архитектура.
Существует некоторое разногласие, что именно считать ESB – архитектуру или программное
обеспечение. Обе точки зрения имеют право на существование.
Целью интеграции приложения является создание единственного модуля (или
адаптера), который отвечает за «подключение» приложения к ESB. Последующую обработку
сообщений и их маршрутизацию в другие системы, ESB выполняет на основании
установленных бизнес-правил самостоятельно. Этот подход обеспечивает превосходную
гибкость, простоту масштабирования и переноса, поэтому в случае замены одного из
приложений подключенного к шине, перенастраивать остальные не нужно.
ESB описывает вполне реальный программный продукт, в задачи которого входит
упрощение вызова службы за счет управления всеми взаимодействиями на пути от
потребителя службы к поставщику и обратно. Двумя наиболее часто упоминаемыми
возможностями ESB являются преобразование сообщений и их маршрутизация.
Основные функции ESB включают в себя:
• Обеспечение интерфейсов взаимодействия.
• Отправка сообщений и маршрутизация.
• Преобразование данных.
• Сенсоры событий.
• Управление политиками.
• Виртуализация.
Достоинствами ESB является:
• Организация размещения существующих систем осуществляется быстрее и дешевле.
• Повышение гибкости.
• ESB основывается на общепризнанных стандартах.
• Наличие большого количества конфигурации для интеграции.
К числу недостатков ESB относят:
• Сложность реализации.
• Требует больших ресурсов.
На рынке представлены как коммерческие реализации ESB, такие как BEA AquaLogic,
так и бесплатные Open Source: Mule ESB, JBoss EJB, Apache ServiceMix. Ниже представлен
обзор некоторых из них.
Mule. Центральная часть системы Mule – определения сервисов, которые определяют
логику интеграции. Эти сервисы могут состоять из входящих и исходящих элементов
представляющие возможность для конфигурирования входящей и исходящей связи. Сервис
также может включать в себя компонент, включающий любую из технологий Java и Spring
beans. Это является одним из ключевых преимуществ для Java-разработчиков, нуждающихся
в интеграционной структуре. Большая часть разработки с Mule может реализовываться при
помощи Java-классов и Java-сообщений.
Apache ServiceMix – пакет W§@‹OжCдля создания JBI. ServiceMix базируется на
концепции сервисной шины предприятия (ESB), комбинируя сервисно-ориентированную
архитектуру (SOA) и архитектуру на основе событий (Event Driven Architecture – EDA).
ServiceMix часто используется совместно с ActiveMQ Apache, Apache Camel и Apache CXF в
SOA-проектах. На основе ServiceMix был сделан пакет Fuse ESB, компании LogicBlaze.
Open ESB – является проектом Sun Microsystems и ведется как один из проектов
Java.net. Так же, как и ServiceMix, эта система представляет собой реализацию спецификаций
JBI. По функционалу Open ESB сходен с ServiceMix. Главное отличие в том, что Open ESB
ориентирован на Glassfish application server, в то время, как ServiceMix не может быть
развернут без особых проблем на Apache Geronimo или the JBoss Application Servers. Второе
отличие данной системы от других реализаций ESB – это поддержка дополнительного
инструментария.
OW2 Petals – был официально сертифицирован Sun Microsystems и основан на JBI.
Архитектура OW2 Petals ориентирована на предоставление распределенной среды, в которой
функционируют и интегрированы несколько сущностей OW2 Petals. Это означает, что все
сервисы, размещенные на различных сущностях, могут беспрепятственно взаимодействовать
друг с другом без дополнительной конфигурации и настройки. Немаловажным достоинством
является наличие веб-интерфейса для мониторинга, через который также возможно
управлять потоками сообщений и компонентами JBI.
Таблица 1. Сравнение ESB-систем с открытым исходным кодом
Основываясь на результатах проведенного сравнительного анализа ESB-систем с
открытым кодом, можно сказать, что Mule лидирует по рассмотренным критериям, второе
место можно отдать ServiceMix.
Тем не менее, выбор конкретной сервисной шины зависит от нужд организации и
специфики поставленной задачи.