Сервис-ориентированная архитектура (SOA). Управление SOA – путь к совершенству
Аннотация
Продолжительность курса
· Лекции – 45 мин;
· Ответы на тесты - 15 мин.
Теоретический курс
Понятие SOA
Согласно IT Gartner SOA SOA SOA SOA приложение».
Анатомия SOA
Слайды №6, 7
Рассмотрим логическую структуру SOA приложения. Как правило, подобное приложение на логическом уровне можно разделить на две большие части:
1. Бизнес – домен
2. IT – домен
Бизнес – домен включает в себя построение композитного корпоративного приложения и формирование бизнес-процессов из доступного набора сервисов.
IT – домен отвечает за создание сервисов, подключения существующих не – SOA приложений и т.д.
Если разделить SOA на уровни, то мы увидим следующие семь уровней:
Уровень 1: Уровень унаследованных систем. Состоит из существующих заказных приложений, называемых также унаследованными системами, например, приложения системы управления взаимосвязями с клиентами (CRM) и планирования ресурсов предприятия (ERP) и т.д. Многоуровневая архитектура SOA может помочь улучшить уже существующие системы и способствовать их интеграции с использованием сервис - ориентированных методов.
Уровень 2: Уровень корпоративных компонентов. Корпоративные компоненты несут ответственность за обеспечение функциональности и поддержание качества обслуживания (QoS) сервисов. Для реализации компонентов, управления рабочей нагрузкой, отказоустойчивостью и балансирования нагрузки данный уровень обычно использует такие технологии, основанные на использовании контейнеров, как серверы приложений.
Уровень 3: Уровень сервисов. На этом уровне находятся сервисы, выявленные бизнесом. Данный уровень выводит подмножество интерфейсов корпоративных компонентов в форму описания сервисов. Таким образом, корпоративные компоненты обеспечивают реализацию сервиса в период работы, используя функциональность, предоставленную их интерфейсами. На данном уровне интерфейсы экспортируются как описания сервиса, в котором они доступны для использования. Сервисы могут существовать отдельно или как композитный (составной) сервис.
Уровень 4: Уровень объединения (хореографии) бизнес процессов. На этом уровне определяется способы объединения сервисов, определенных на Уровне 3. Сервисы связаны в поток путем группировки (хореографии) и, следовательно, они действуют совместно как отдельное приложение. Для проектирования потоков приложения могут использоваться визуальные инструменты компоновки.
Уровень 5: Уровень презентации. SOA отделяет пользовательский интерфейс от компонентов, но без пользовательского интерфейса, как правило, обойтись нельзя. Пользовательский интерфейс позволяет вывести сервисы на уровень интерфейса приложения или презентации.
Уровень 6: Интеграция (ESB). Этот уровень допускает интеграцию сервисов путем предоставления набора таких возможностей, как интеллектуальная маршрутизация, посредничество протоколов и других механизмов преобразований, обычно описанных как ESB (Enterprise Service Bus) – корпоративная сервисная шина.
Уровень 7: Качество обслуживания (QoS) . Этот уровень предоставляет возможности для мониторинга, управления и поддержки таких аспектов качества обслуживания, как обеспечение безопасности, производительности и доступности. Он является фоновым процессом, использующим механизмы запросов и ответов, и инструменты, контролирующие общее состояние приложений SOA. Сюда включены все важные стандартные реализации WS - Management и других значимых протоколов и стандартов, реализующих качество обслуживания для SOA.
Стандарты SOA
Слайды №8, 9
Прежде чем рассмотреть каждый из вышеперечисленных уровней более подробно, необходимо познакомиться с основными стандартами, используемыми при создании приложений в SOA.
Спецификации SOAP, WSDL и UDDI де-факто определяют стандартную инфраструктуру текущей технологии Web-сервисов. Две группы по стандартизации работают над официальными стандартами Web-сервисов – W3C и OASIS (Organization for the Advancement of Structured Information Standards).
W3C фокусируется на спецификациях инфраструктуры ядра технологии, а OASIS на высокоуровневой функциональности.
Simple Object Access Protocol (SOAP) – протокол обмена сообщениями, основанными на XML, определяет как Web - сервисы могут посылать сообщения друг другу. Это высокоуровневый протокол, который лишь определяет структуру сообщений и несколько правил по их обработке. SOAP не зависит от транспортного протокола, поэтому обмениваться SOAP - сообщениями можно через множество транспортных протоколов. В настоящее время чаще всего для передачи SOAP – сообщений в качестве транспортного протокола используется HTTP.
Web Services Definition Language (WSDL) – стандарт для описания Web - сервисов. Описание на WSDL содержит всю информацию необходимую для доступа и использования Web - сервиса, включая интерфейс Web сервиса. Описание на WSDL – это XML документ, содержащий набор определений, таких как типы данных, формат сообщений и т.д.
Таким образом, WSDL определяет стандартный описательный механизм для Web – сервисов, документ WSDL описывает, какую функциональность предлагает Web – сервис, как получить доступ и т.д. Документ WSDL может быть откомпилирован для создания proxy для клиентов, которые вызывают данный сервис (proxy позволяет клиенту «думать», что сервис расположен на той же машине, что и сам клиент).
Universal Description Discovery and Integration (UDDI) – «желтые страницы», в которых могут быть зарегистрированы Web - сервисы и их описания на WSDL. UDDI сам по себе Web - сервис и является реестром общего назначения, где могут быть зарегистрированы не только Web - сервисы.
UDDI определяет стандартный механизм обнаружения для Web – сервисов, пользователи могут запросить реестр UDDI, задавая, например, название компании, тип сервиса или другие критерии поиска. UDDI обеспечивает указание на WSDL документ, который описывает Web – сервис и точки входа к реализации сервиса.
Транспортные протоколы для Web-сервисов
В процессе разработки Web – сервиса, необходимо определить какие транспортные протоколы будет поддерживать Web-сервис для обмена сообщениями. В настоящее время, для транспортировки XML – сообщений чаще всего используется HTTP (основной протокол, используемый web-серверами и web – браузерами), а при реализации Web-сервисов на платформе Java может использоваться Java Messaging Service (JMS), который является частью спецификации J2EE. Web-сервис может поддерживать несколько транспортных протоколов, это обстоятельство находит свое отражение в WSDL файле сервиса.
Достоинства HTTP в том, что он используется повсеместно, гибкий и большинство сетевых экранов пропускают HTTP – сообщения. HTTP позволяет передавать не только WWW - документы, но и практически любые другие документы. HTTP также полезен для Web-сервисов, которые требуют синхронных двунаправленных соединений. Когда клиент вызывает метод Web-сервиса через HTTP, этот метод должен сразу же возвратить результат клиенту.
Однако у HTTP есть ряд недостатков, которые могут оказаться критичными для приложений уровня предприятия, требующих, например, асинхронного обмена сообщениями. Для того, чтобы две системы могли обмениваться сообщениями через HTTP, обе системы должны быть доступными. Если это не так, никто не гарантирует, что сообщения будут доставлены, HTTP не может обеспечить хранение не доставленных сообщений. Также HTTP не поддерживает поддержку транзакций, поэтому сложные операции не могут быть выполнены через HTTP.
Для приложений уровня предприятия, требующих асинхронных коммуникаций и поддержки транзакций, можно рассмотреть возможность использования JMS в качестве транспортного протокола Web -сервисов.
Когда происходит обмен сообщениями через JMS, система, посылающая сообщение может быть полностью независимой от принимающей сообщение системы. JMS работает между этими системами, причем гарантирует доставку сообщений, так как может обеспечить их долговременное хранение.
JMS также поддерживает транзакции, что позволяет выполнять сложные операции в распределенных системах, которые при этом будут оставаться в стабильном состоянии.
Когда Web-сервис использует JMS как транспортный протокол, он работает с сообщениями через очередь JMS.
Форматы сообщений
Когда мы выбрали транспортный протокол для Web-сервиса, необходимо определиться с форматом собственно сообщений, которыми мы будем обмениваться. Формат сообщений описывает, как сообщение должно быть подготовлено к отправке по транспортному протоколу. Например, мы можем оформлять наши сообщения в SOAP – формате или в виде обычного XML. Независимо оттого, что мы выбрали – SOAP или XML, мы можем пересылать их через HTTP или JMS.
Web-сервис может поддерживать несколько транспортных протоколов и форматов сообщений.
Преимущества SOA
Слайд №10
Слабая связанность сервисов существенно повышает их мобильность и возможность многосторонней интеграции. Благодаря этому сервисы можно перемещать с одного сервера на другой, менять параметры связи и объединять сервисы в единое приложение не на этапе разработки, а на этапе исполнения. Это придает системе, построенной на базе SOA, особую гибкость и позволяет предприятиям осуществить давнюю мечту о многократном использовании одного и того же кода. Основная цель SOA - добиться более высокого уровня повторного использования разработок и более дешевой интеграции. Если система строится на базе Web-сервисов, то все последующие проекты смогут еще не раз воспользоваться функциями, разработанными на первом этапе. Поэтому в перспективе стоимость проектов будет снижаться. SOA позволяет также повысить эффективность процесса разработки приложений за счет применения имеющихся в продаже готовых программных компонентов.
У SOA есть и другие достоинства.
Во-первых, ее внедрение не требует полной перестройки корпоративной инфраструктуры. Предприятиям не нужно отказываться от привычных, хорошо себя зарекомендовавших приложений. Достаточно снабдить их соответствующими интерфейсами - и Web-сервисы готовы. Практическая ценность SOA для бизнеса заключается в возможности постепенного эволюционного развития корпоративной информационной инфраструктуры. Это позволяет внедрять SOA постепенно, начиная с небольших пилотных проектов.
Во-вторых, благодаря Web-сервисам бизнес - менеджеры могут гораздо активнее участвовать в создании корпоративных приложений.
В-третьих, новая архитектура дает предприятию возможность быстрее адаптироваться к изменяющимся условиям: можно быстро заменить одну реализацию сервиса на другую, не меняя его интерфейс.
И, в-четвертых, использование открытых стандартов вместо закрытых протоколов делает архитектуру SOA независимой от платформ. SOA поднимет на новый уровень интеграцию, обеспечивая взаимодействие гетерогенных систем.
Проблемы использования SOA
Слайд №11
В целом идеи SOA понятны и производителям ПО и клиентам, однако нельзя сказать, что данная технология находится в зрелом состоянии. Недостаточно проработаны стандарты, не хватает инструментов управления. Как и часто бывает в таких случаях, сложилось группировки производителей программного обеспечения, разрабатывающих свои спецификации. В результате на роль «заполнителей дыр» в SOA сейчас претендует множество различных методов, но явного лидера нет. Сближение подходов намечается в рамках организация Web Services Interoperability (www.ws-i.org), которая пытается выработать некий общий знаменатель для технологии Web-сервисов. Она выпустила документ WS-I Basic Profile, определяющий требования к различным компонентам SOA, которые могут гарантировать их совместимость и прояснить тонкости использования Web-сервисов.
Перспективы и прогнозы
Аналитики с большим оптимизмом смотрят на будущее SOA и Web-сервисов. Так, по прогнозу компании Gartner, к 2008 г. более 60% предприятий будут использовать эту архитектуру в качестве основного принципа при создании ответственных бизнес-приложений.
В IDC подсчитали, что в прошлом году предприятия потратили на поддержку Web-сервисов 1,1 млрд. долл., а в 2008 г. израсходуют 11 млрд. долларов. Компания ZapThink, занятая исследованиями в области SOA, прогнозирует, что рынок инструментов для реализации Web-сервисов вырастет со 120 млн. долл. в 2003 г. до 8,3 млрд. долл. в 2008 г. Аналитики объясняют такой подъем тем, что SOA, позволяющая снизить расходы на
IT
, становится главной стратегией при решении проблем интеграции разнородных систем. Отношение предприятий к SOA становится более серьезным, и они переходят от экспериментов к реальным внедрениям.
Понятие Web – сервиса
Слайд №13
Web - сервисы можно рассматривать как «plug and play» приложения. Web -сервис представляет собой часть информационной системы или бизнес-процесса, к которой можно обратиться в том числе и через Интернет с целью сборки требуемой информационной системы.
Отличие Web - сервисов от приложений других типов в том, что Web – сервисы разрабатываются для поддержки связи и взаимодействия приложений с приложениями. Другие Web приложения поддерживают коммуникации человек – человек (например, e-mail) или человек – приложение (браузеры). Технология Web – сервисов позволяет приложениям общаться с другими приложениями без участия человека.
Итак, Web – сервисы - это слабосвязанные, инкапсулированные компоненты которые выполняют определенную задачу, доступ к ним осуществляется через их интерфейсы по стандартным протоколам.
Основными возможностями, предоставляемыми Web-сервисами, являются:
· Возможность повторного использования, разработчики могут использовать Web-сервисы сторонних производителей для быстрого создания интеграционных решений
· Web-сервисы могут быть реализованы практически на любой платформе, на большинстве стандартных языков программирования, причем для использования Web-сервиса не требуется совместимость платформ с клиентом
· Доступ к Web –сервису можно осуществлять как через интранет, так и через Интернет.
На концептуальном архитектурном уровне Web-сервисы – это основанные на стандартах «обертки» для сервисов и ресурсов, которые провайдер делает доступными для потребителей.
Виды Web – сервисов
По формату сообщений, Web – сервисы разделяются на:
1. Web – сервисы, основанные на сообщениях SOAP.
2. Web – сервисы, основанные на технологии Representational State Transfer (REST).
3. Web – сервисы, основанные на XML-RPC.
Так как для приложений уровня предприятия требуется такие возможности как обеспечение безопасности и т.д., то, как правило, для таких целей выбирают Web-сервисы, обменивающиеся SOAP-сообщениями.
По способу обработки входящих сообщений Web - сервисы могут быть:
1. Синхронные
2. Асинхронные
Список источников
1. Об использовании BPMS - http://www.bpms.ru
2. Демонстрация BPMS - http://www.unify.ru/demo/bpm/index.html
3. Материалы исследований компании ZapThink - http://www.zapthink.com
4. Материалы о механизмах интеграции компании Intersoft Lab -
http://www.iso.ru/journal/articles/themes/17
5. Техническая библиотека компании BEA - http://dev2dev.bea.com/soa/
6. Техническая библиотека компании Sun - http://java.sun.com/webservices/index.jsp
7. Техническая библиотека компании IBM –
http://www-128.ibm.com/developerworks/ru/views/webservices/libraryview.jsp
8. mig_ssdoc\\$/ПРОИЗВОДСТВО SOA/Архитектура/Презентация платформы v2.ppt
9. mig_ssdoc\\$/ПРОИЗВОДСТВО SOA/Архитектура/Архитектура системы v2.doc
Приложение 1
Рисунок для иллюстрации архитектуры фронт – офисного решения Diasoft.
Аннотация
Данный документ предназначен для проведения лекционных занятий по теоретическому курсу "Основы сервисно – ориентированной архитектуры".
Требования к знаниям слушателей:
· Знание основ архитектуры построения распределенных многозвенных приложений;
По итогам обучения, слушатели должны:
· Получить представление о принципах построения приложений в SOA;
· Узнать о ключевых технологиях, применяемых в SOA;
· Иметь представление о сервисах, как основных строительных элементах SOA приложений;
· Узнать об использовании корпоративной сервисной шины ESB для интеграции Web - сервисов;
· Получить информацию о системах управления бизнес – процессами (BPMS).
· Получить основные сведения об архитектуре фронт – офисного решения Diasoft.SOA
Теоретический курс рассчитан на стажеров и сотрудников компании, для которых планируется работа с программными продуктами компании выполненными в SOA.
Программой курса предусматривается обязательное итоговое тестирование.
Продолжительность курса
· Лекции – 45 мин;
· Ответы на тесты - 15 мин.
«Основы сервисно – ориентированной архитектуры»
Теоретический курс
1. Краткий обзор сервисно – ориентированной архитектуры (SOA)..... 4
1.1. Понятие SOA................................................................................................................... 4
1.2. Предпосылки возникновения SOA........................................................................... 4
1.3. Эволюция архитектуры корпоративных IT систем............................................... 4
1.4. Анатомия SOA................................................................................................................ 5
1.5. Стандарты SOA.............................................................................................................. 6
1.6. Преимущества SOA........................................................................................................ 8
1.7. Проблемы использования SOA................................................................................. 8
1.8. Перспективы и прогнозы............................................................................................. 9
2. Инфраструктура для приложений в SOA.............................................. 9
2.1. Элементы инфраструктуры для реализации приложений в SOA.................... 9
2.2. Понятие Web – сервиса................................................................................................ 9
2.3. Схема регистрации и поиска Web – сервисов....................................................... 10
2.4. Механизм вызова Web – сервисов и конвертация данных \ протоколов с использованием ESB................................................................................................................................... 11
2.5. Использование ESB для интеграции приложений.............................................. 11
2.6. BPEL - язык описания бизнес - процессов............................................................. 12
2.7. BPMS – система управления бизнес - процессами.............................................. 14
3. Архитектура фронт - офисного решения Diasoft................................. 17
3.1. Особенности фронт – офисного решения Diasoft............................................... 17
3.2. Архитектурные слои фронт – офисного решения Diasoft................................. 18
Список источников..................................................................................... 19
Приложение 1............................................................................................... 20
Краткий обзор сервисно – ориентированной архитектуры (SOA)
Понятие SOA
Согласно IT словарю известной консалтинговой компании Gartner - признанного авторитета в данной области, SOA – это «топология приложений, в которой бизнес – логика приложения сосредоточена в модулях (сервисах), имеющих прозрачные интерфейсы идентификации, назначения и программного доступа. Сервисы – это «черные ящики»: их внутренний дизайн не зависит от природы и назначения программы выполняющей запросы к сервисам. Поскольку в SOA данные и бизнес – логика заключены в модульных бизнес – компонентах с хорошо документированными интерфейсами, то это упрощает дизайн и обеспечивает возможность инкрементальной разработки и последующего расширения функциональности. В SOA приложение может быть интегрировано с гетерогенными, внешними унаследованными и приобретенными приложениями более просто, чем монолитное, не – SOA приложение».
Таким образом, SOA - это не продукт и даже не технология, а концепция создания и интеграции отдельных корпоративных приложений. Данная концепция ориентируется на сервисы, характеризуется распределенной архитектурой и слабо связанными интерфейсами.
Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берёт своё начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько её реализаций. Но, по сути, SOA можно свести к нескольким идеям, причём архитектура не диктует способы их реализации:
- Сочетаемость приложений, ориентированных на пользователей.
- Многократное использование бизнес-сервисов.
- Независимость от набора технологий.
- Автономность (независимые эволюция, масштабируемость и развёртываемость).
SOA - это набор архитектурных принципов, не зависящих от технологий и продуктов, совсем как полиморфизм или инкапсуляция.
В этой статье я рассмотрю следующие паттерны, относящиеся к SOA:
- Общая архитектура брокера объектных запросов (CORBA).
- Веб-сервисы.
- Очередь сообщений.
- Сервисная шина предприятия (ESB).
- Микросервисы.
Общая архитектура брокера объектных запросов (CORBA)
В 1980-х началось активное использование корпоративных сетей и клиент-серверной архитектуры. Возникла потребность в стандартном способе взаимодействия приложений, которые созданы с использованием разных технологий, исполняются на разных компьютерах и под разными ОС. Для этого была разработана CORBA. Это один из стандартов распределённых вычислений, зародившийся в 1980-х и расцветший к 1991 году.
Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:
- Не зависящие от платформы вызовы удалённых процедур (Remote Procedure Call).
- Транзакции (в том числе удалённые!).
- Безопасность.
- События.
- Независимость от выбора языка программирования.
- Независимость от выбора ОС.
- Независимость от выбора оборудования.
- Набор данных через язык описания интерфейсов (Interface Definition Language, IDL).
Сегодня CORBA всё ещё используется для разнородных вычислений. Например, он до сих пор является частью Java EE , хотя начиная с Java 9 будет поставляться в виде отдельного модуля .
Хочу отметить, что не считаю CORBA паттерном SOA (хотя отношу и CORBA, и SOA-паттерны к сфере распределённых вычислений). Я рассказываю о нём здесь, поскольку считаю недостатки CORBA одной из причин возникновения SOA.
Принцип работы
Сначала нам нужно получить брокер объектных запросов (Object Request Broker, ORB), который соответствует спецификации CORBA. Он предоставляется вендором и использует языковые преобразователи (language mappers) для генерирования «заглушек» (stub) и «скелетов» (skeleton) на языках клиентского кода. С помощью этого ORB и определений интерфейсов, использующих IDL (аналог WSDL), можно на основе реальных классов генерировать в клиенте удалённо вызываемые классы-заглушки (stub classes). А на сервере можно генерировать классы-скелеты (skeleton classes), обрабатывающие входящие запросы и вызывающие реальные целевые объекты.
Вызывающая программа (caller) вызывает локальную процедуру, реализованную заглушкой.
- Заглушка проверяет вызов, создаёт сообщение-запрос и передаёт его в ORB.
- Клиентский ORB шлёт сообщение по сети на сервер и блокирует текущий поток выполнения.
- Серверный ORB получает сообщение-запрос и создаёт экземпляр скелета.
- Скелет исполняет процедуру в вызываемом объекте.
- Вызываемый объект проводит вычисления и возвращает результат.
- Скелет пакует выходные аргументы в сообщение-ответ и передаёт его в ORB.
- ORB шлёт сообщение по сети клиенту.
- Клиентский ORB получает сообщение, распаковывает и передаёт информацию заглушке.
- Заглушка передаёт выходные аргументы вызывающему методу, разблокирует поток выполнения, и вызывающая программа продолжает свою работу.
Достоинства
- Независимость от выбранных технологий (не считая реализации ORB).
- Независимость от особенностей передачи данных/связи.
Недостатки
- Независимость от местоположения : клиентский код не имеет понятия, является ли вызов локальным или удалённым. Звучит неплохо, но длительность задержки и виды сбоев могут сильно варьироваться. Если мы не знаем, какой у нас вызов, то приложение не может выбрать подходящую стратегию обработки вызовов методов, а значит, и генерировать удалённые вызовы внутри цикла. В результате вся система работает медленнее.
- Сложная, раздутая и неоднозначная спецификация : её собрали из нескольких версий спецификаций разных вендоров, поэтому (на тот момент) она была раздутой, неоднозначной и трудной в реализации.
- Заблокированные каналы связи (communication pipes) : используются специфические протоколы поверх TCP/IP, а также специфические порты (или даже случайные порты). Но правила корпоративной безопасности и файрволы зачастую допускают HTTP-соединения только через 80-й порт, блокируя обмены данными CORBA.
Веб-сервисы
Хотя сегодня можно найти применение для CORBA, но мы знаем, что нужно было уменьшить количество удалённых обращений , чтобы повысить производительность системы. Также требовался надёжный канал связи и более простая спецификация обмена сообщениями .
И для решения этих задач в конце 1990-х начали появляться веб-сервисы.
- Нужен был
надёжный канал связи
, поэтому:
- HTTP стал по умолчанию работать через порт 80.
- Для обмена сообщениями начали использовать платформо-независимый язык (вроде XML или JSON).
- Нужно было уменьшить количество удалённых обращений , поэтому:
[Веб-]сервисы можно публиковать, находить и использовать стандартным образом вне зависимости от технологий.
- Microsoft 2004,
Благодаря микросервисам мы перешли в парадигме SOA от удалённого вызова методов объекта (CORBA) к передаче сообщений между сервисами.
Но нужно понимать, что в рамках SOA веб-сервисы - не просто API общего назначения, всего лишь предоставляющие CRUD-доступ к базе данных через HTTP. В каких-то случаях эта реализация может быть полезной, но ради целостности ваших данных необходимо, чтобы пользователи понимали лежащую в основе реализации модель и соблюдали бизнес-правила . SOA подразумевает, что веб-сервисы являются ограниченными контекстами бизнес-субдоменов (business sub-domain) и отделяет реализацию от решаемых веб-сервисами задач.
С точки зрения технологий SOA не просто сервисная архитектура, а набор политик, методик и фреймворков, благодаря которым мы предоставляем и получаем нужные сервисы.
- Microsoft 2004, Understanding Service-Oriented Architecture
Достоинства
- Изолированность контекстов доменов (Domain contexts).
Недостатки
- Синхронный обмен сообщениями может перегрузить системы.
Очередь сообщений
У нас есть несколько приложений, которые асинхронно общаются друг с другом с помощью платформо-независимых сообщений. Очередь сообщений улучшает масштабируемость и усиливает изолированность приложений. Им не нужно знать, где находятся другие приложения, сколько их и даже что они собой представляют. Однако все эти приложения должны использовать один язык обмена сообщениями, т. е. заранее определённый текстовый формат представления данных.
Очередь сообщений использует в качестве компонента инфраструктуры программный брокер сообщений (RabbitMQ, Beanstalkd, Kafka и т. д.). Для реализации связи между приложениями можно по-разному настроить очередь:
Запрос/Ответ
- Клиент шлёт в очередь сообщение, включая ссылку на «разговор» («conversation» reference) . Сообщение приходит на специальный узел, который отвечает отправителю другим сообщением, где содержится ссылка на тот же разговор , так что получатель знает, на какой разговор ссылается сообщение, и может продолжать действовать. Это очень полезно для бизнес-процессов средней и большой продолжительности (цепочек событий, sagas ).
- Публикация/Подписка
- По спискам
Очередь поддерживает списки опубликованных тем подписок (topics) и их подписчиков. Когда очередь получает сообщение для какой-то темы, то помещает его в соответствующий список. Сообщение сопоставляется с темой по типу сообщения или по заранее определённому набору критериев, включая и содержимое сообщения. - На основе вещания
Когда очередь получает сообщение, она транслирует его всем узлам, прослушивающим очередь. Узлы должны сами фильтровать данные и обрабатывать только интересующие сообщения.
- По спискам
Все эти паттерны можно отнести к либо к pull- (polling) , либо к push -подходу:
- В pull-сценарии клиент опрашивает очередь с определённой частотой. Клиент управляет своей нагрузкой, но при этом может возникнуть задержка: сообщение уже лежит в очереди, а клиент его ещё не обрабатывает, потому что не пришло время следующего опроса очереди.
- В push-сценарии очередь сразу же отдаёт клиентам сообщения по мере поступления. Задержки нет, но клиенты не управляют своей нагрузкой.
Достоинства
- Независимость набора технологий, развёртывания и масштабируемости сервисов.
- Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт 80).
- Оптимизированный обмен сообщениями.
- Стабильная спецификация обмена сообщениями.
Недостатки
- Разные веб-сервисы тяжело интегрировать из-за различий в языках передачи сообщений. Например, два веб-сервиса, использующих разные JSON-представления одной и той же концепции.
Сервисная шина предприятия (ESB)
Сервисная шина предприятия использовала веб-сервисы уже в 1990-х, когда они только развивались (быть может, некоторые реализации сначала использовали CORBA?).
ESB возникла во времена, когда в компаниях были отдельные приложения. Например, одно для работы с финансами, другое для учёта персонала, третье для управления складом, и т. д., и их нужно было как-то связывать друг с другом, как-то интегрировать. Но все эти приложения создавались без учёта интеграции, не было стандартного языка для взаимодействия приложений (как и сегодня). Поэтому разработчики приложений предусматривали конечные точки для отправки и приёма данных в определённом формате. Компании-клиенты потом интегрировали приложения, налаживая между ними каналы связи и преобразуя сообщения с одного языка приложения в другой.
Очередь сообщений может упростить взаимодействие приложений, но она не способна решить проблему разных форматов языков. Впрочем, была сделана попытка превратить очередь сообщений из простого канала связи в посредника, доставляющего сообщения и преобразующего их в нужные форматы/языки. ESB стал следующей ступенью в естественной эволюции простой очереди сообщений.
В этой архитектуре используется модульное приложение (composite application), обычно ориентированное на пользователей, которое общается с веб-сервисами для выполнения каких-то операций. В свою очередь, эти веб-сервисы тоже могут общаться с другими веб-сервисами, впоследствии возвращая приложению какие-то данные. Но ни приложение, ни бэкенд-сервисы ничего друг о друге не знают, включая расположение и протоколы связи. Они знают лишь, с каким сервисом хотят связаться и где находится сервисная шина.
Клиент (сервис или модульное приложение) отправляет запрос на сервисную шину, которая преобразует сообщение в формат, поддерживаемый в точке назначения, и перенаправляет туда запрос. Всё взаимодействие идёт через сервисную шину, так что если она падает, то с ней падают и все остальные системы. То есть ESB - ключевой посредник, очень сложный компонент системы.
Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process Orchestration Service) и обработчиков правил (Rules Engine). Тот же паттерн может использовать интегрированная архитектура (federated design): система разделена на бизнес-домены со своими ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.
Главные обязанности ESB:
- Отслеживать и маршрутизировать обмен сообщениями между сервисами.
- Преобразовывать сообщения между общающимися сервисными компонентами.
- Управлять развёртыванием и версионированием сервисов.
- Управлять использованием избыточных сервисов.
- Предоставлять стандартные сервисы обработки событий, преобразования и сопоставления данных, сервисы очередей сообщений и событий, сервисы обеспечения безопасности или обработки исключений, сервисы преобразования протоколов и обеспечения необходимого качества связи.
Создавая структуры связи между разными процессами, мы видели много продуктов и подходов, в которых применяются очень развитые механизмы связи. Хороший пример - сервисные шины предприятий, часто включающие в себя сложные средства маршрутизации сообщений, хореографии, преобразования и применения бизнес-правил.
- Martin Fowler 2014, Microservices
У этого архитектурного паттерна есть положительные стороны. Однако я считаю его особенно полезным в случаях, когда мы не «владеем» веб-сервисами и нам нужен посредник для трансляции сообщений между сервисами, для оркестрирования бизнес-процессами, использующими несколько веб-сервисов, и прочих задач.
Достоинства
- Независимость набора технологий, развёртывания и масштабируемости сервисов.
- Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт 80).
- Оптимизированный обмен сообщениями.
- Стабильная спецификация обмена сообщениями.
- Изолированность контекстов домена (Domain contexts).
- Простота подключения и отключения сервисов.
- Асинхронность обмена сообщениями помогает управлять нагрузкой на систему.
- Единая точка для управления версионированием и преобразованием.
Недостатки
- Ниже скорость связи, особенно между уже совместимыми сервисами.
- Централизованная логика:
- Единая точка отказа, способная обрушить системы связи всей компании.
- Большая сложность конфигурирования и поддержки.
- Со временем можно прийти к хранению в ESB бизнес-правил.
- Шина так сложна, что для её управления вам потребуется целая команда.
- Высокая зависимость сервисов от ESB.
Микросервисы
В основе микросервисной архитектуры лежат концепции SOA. Назначение у неё то же, что и у ESB: создать единое общее корпоративное приложение из нескольких специализированных приложений бизнес-доменов.
Главное различие микросервисов и шины в том, что ESB была создана в контексте интеграции отдельных приложений , чтобы получилось единое корпоративное распределённое приложение. А микросервисная архитектура создавалась в контексте быстро и постоянно меняющихся бизнесов, которые (в основном) с нуля создают собственные облачные приложения.
То есть в случае с ESB у нас уже были приложения, которые нам не «принадлежат» , и поэтому мы не могли их изменить. А в случае с микросервисами мы полностью контролируем приложения (при этом в системе могут использоваться и сторонние веб-сервисы).
Характер построения/проектирования микросервисов не требует глубокой интеграции. Микросервисы должны соответствовать бизнес-концепции, ограниченному контексту. Они должны сохранять своё состояние, быть независимыми от других микросервисов, и потому они меньше нуждаются в интеграции. То есть низкая взаимозависимость и высокая связность привели к замечательному побочному эффекту - уменьшению потребности в интеграции.
[Микросервисы - это] маленькие автономные сервисы, работающие вместе и спроектированные вокруг бизнес-домена.
- Sam Newman 2015, Principles Of Microservices
Главным недостатком архитектуры ESB было очень сложное централизованное приложение, от которого зависели все остальные приложения. А в микросервисной архитектуре это приложение почти целиком убрано.
Ещё остались элементы, пронизывающие всю экосистему микросервисов. Но у них гораздо меньше задач по сравнению с ESB. К примеру, для асинхронной связи между микросервисами до сих пор применяется очередь сообщений, но это лишь канал для передачи сообщений, не более того. Или можно вспомнить шлюз экосистемы микросервисов, через который проходит весь внешний обмен данными.
- Проектирование сервисов вокруг бизнес-доменов
Это может дать нам стабильные интерфейсы, высокосвязные и мало зависящие друг от друга модули кода, а также чётко определённые разграниченные контексты. - Культура автоматизации
Это даст нам гораздо больше свободы, мы сможем развернуть больше модулей. - Скрытие подробностей реализации
Это позволяет сервисам развиваться независимо друг от друга. - Полная децентрализация
Децентрализуйте принятие решений и архитектурные концепции, предоставьте командам автономность, чтобы компания сама превратилась в сложную адаптивную систему, способную быстро приспосабливаться к переменам. - Независимое развёртывание
Можно развёртывать новую версию сервиса, не меняя ничего другого. - Сначала потребитель
Сервис должен быть простым в использовании, в том числе другими сервисами. - Изолирование сбоев
Если один сервис падает, другие продолжают работать, это делает всю систему устойчивой к сбоям. - Удобство мониторинга
В системе много компонентов, поэтому трудно уследить за всем, что в ней происходит. Нам нужны сложные инструменты мониторинга, позволяющие заглянуть в каждый уголок системы и отследить любую цепочку событий.
Сообщество предпочитает другой подход: умные конечные точки и глупые каналы . Микросервисы, из которых собираются приложения, должны как можно меньше зависеть друг от друга и при этом быть очень тесно связанными - они содержат собственную доменную логику и работают скорее как фильтры с точки зрения классического Unix: получают запросы, применяют логику и генерируют ответы. Они оркестрируются с помощью простых REST-подобных протоколов, а не сложных протоколов вроде WS-Choreography или BPEL либо какого-то централизованного инструмента.
- Martin Fowler 2014, Microservices
Достоинства
- Независимость набора технологий, развёртывания и масштабируемости сервисов.
- Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт 80).
- Оптимизированный обмен сообщениями.
- Стабильная спецификация обмена сообщениями.
- Изолированность контекстов домена (Domain contexts).
- Простота подключения и отключения сервисов.
- Асинхронность обмена сообщениями помогает управлять нагрузкой на систему.
- Синхронность обмена сообщениями помогает управлять производительностью системы.
- Полностью независимые и автономные сервисы.
- Бизнес-логика хранится только в сервисах.
- Позволяют компании превратиться в сложную адаптивную систему, состоящую из нескольких маленьких автономных частей/команд, способную быстро адаптироваться к переменам.
Недостатки
- Высокая сложность эксплуатации:
- Нужно много вложить в сильную DevOps-культуру.
- Использование многочисленных технологий и библиотек может выйти из-под контроля.
- Нужно аккуратно управлять изменениями входных/выходных API, потому что эти интерфейсы будут использовать многие приложения.
- Использование «согласованности в конечном счёте» (eventual consistency) может привести к серьёзным последствиям, которые нужно учитывать при разработке приложения, от бэкенда до UX.
- Тестирование усложняется, потому что изменения в интерфейсе могут непредсказуемо влиять на другие сервисы.
Антипаттерн: архитектура равиоли (Ravioli Architecture)
Архитектурой равиоли обычно называют антипаттерн микросервисной архитектуры. Равиоли получаются, если микросервисов слишком много, они слишком мелкие и не отражают доменных концепций.
Заключение
В последние десятилетия SOA сильно эволюционировала. Благодаря неэффективности прежних решений и развитию технологий сегодня мы пришли к микросервисной архитектуре.
Эволюция шла по классическому пути: сложные проблемы разбивались на более мелкие, простые в решении.
Проблему сложности кода можно решать так же, как мы разбиваем монолитное приложение на отдельные доменные компоненты (разграниченные контексты). Но с разрастанием команд и кодовой базы увеличивается потребность в независимом развитии, масштабировании и развёртывании. SOA помогает добиться такой независимости, упрочняя границы контекстов.
Повторюсь, что всё дело в слабой взаимозависимости и высокой связности, причём размер компонентов должен быть больше прежнего. Необходимо прагматично оценить свои потребности: используйте SOA, лишь когда это необходимо, поскольку она сильно увеличивает сложность. И если на самом деле вы можете обойтись без SOA, то лучше выберите микросервисы подходящего размера и количества, не больше и не меньше.
Решение многих описанных выше задач, возникающих при создании современных Веб-приложений, теперь начинает возлагаться на Веб-сервисы – не зависящие от платформы, объектной модели и клиента программные компоненты, которые можно вызывать из клиентских Веб-приложений (а также из самих Веб-сервисов) через основанный на протоколе HTTP и языке XML протокол SOAP. Для описания Веб-сервисов используется XML-подобный язык WSDL, а для организации реестров Веб-сервисов, в которых разработчики и компании могут искать необходимые им сервисы, а также публиковать данные о своих сервисах – интерфейс UDDI.
Поддержка Веб-сервисов стала одним из главных стратегических направлений для многих компаний, специализирующихся на выпуске серверов приложений , систем управления базами данных и средств разработки приложений.
Сервис-ориентированная архитектура (SOA, service-oriented architecture) – модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами [21 ].
OASIS (Организация по распространению открытых стандартов структурированной информации) определяет SOA следующим образом (OASIS Reference Model for Service Oriented Architecture V 1.0): Сервисно-ориентированная архитектура – это парадигма организации и использования распределенных информационных ресурсов таких как: приложения и данные, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть: конечный пользователь или другое приложение.
В основе SOA лежат принципы многократного использования функциональных элементов ИТ, ликвидации дублирования функциональности в ПО, унификации типовых операционных процессов, обеспечения перевода операционной модели компании на централизованные процессы и функциональную организацию на основе промышленной платформы интеграции.
Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SOA, часто реализуются как набор веб-сервисов, интегрированных при помощи известных стандартных протоколов (SOAP, WSDL, и т. п.)
Интерфейс компонентов SОА-программы предоставляет инкапсуляцию деталей реализации конкретного компонента (ОС, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SOA предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределенных программных комплексов.
SOA хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, ИВК Юпитер, TIBCO, Diasoft).
Основными целями применения SOA для крупных информационных систем, уровня предприятия, и выше являются :
сокращение издержек при разработке приложений, за счет упорядочивания процесса разработки;
расширение повторного использования кода;
независимость от используемых платформ, инструментов, языков разработки;
повышение масштабируемости создаваемых систем;
улучшение управляемости создаваемых систем.
Принципы SOA:
архитектура , как таковая, не привязана к какой-то определенной технологии;
независимость организации системы от используемой вычислительной платформы (платформ);
независимость организации системы от применяемых языков программирования;
использование сервисов, независимых от конкретных приложений, с единообразными интерфейсами доступа к ним;
организация сервисов как слабосвязанных компонентов для построения систем.
Архитектура не привязана к какой-то определенной технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать, дополнительно, механизм файловой системы, для обмена данными.
Главное, что отличает SOA, это использование независимых сервисов, с четко определенными интерфейсами, которые, для выполнения своих задач, могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу.
SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путем комбинации слабосвязанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определенного платформо-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса.
Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах.Net и сервисы на Java, работающие на платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.
SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий или фреймворков для документирования сервисов.
Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов.
Дословно SOA расшифровывается как service-oriented architecture (сервис-ориентированная архитектура).
В последнее время это стало эдаким buzzword, то есть отчасти модным словечком, отчасти термином специально произносимым произвести впечатление на окружающих.
Все крупнешие компание-производители программного обеспечиния (такие как IBM, BEA, Oracle) постоянно преподносят новости, которые так или иначе обыгрывают SOA. Большинство фирм-консалтеров и интеграторов различными способами информируют, что занимаются реализацией и внедрением сервис-ориентированной архитектуры у клиентов. Часто правда каждый понимает сервис-ориентированную архитекту́немного (или сильно) по своему.
На самом деле и нет строгого определения SOA, нет комитета, вырабатающего стандарты сервис-ориентированной архитектуры (хотя это совершенно не относится к технологиям, на которых она может реализована), да и быть его в принципе не может, поскольку СОА это никак не технология, а философия, концепция, парадигма, новый подход (называйте, как хотите) к построению корпоративных информационных систем, интеграция бизнеса и информационных технологий.
Традиционные проблемы информационных систем
В настоящее время функционирование бизнеса сильно зависит от того, как он автоматизирован в самом широком понимании этого слова. Когда мир глобализован, успех (или, наоборот, поражение) зависит от того как быстро компания может предложить новую услугу или продукт на рынок. Одновременно ситуация осложняется "размыванием" основного направления деятельности компаний, например, банковские институты все чаще начинают предлагать различные страховые продукты и наоборот, страховые компании все активнее работают в финансовой сфере.
ИТ-департаменты компаний должны оперативно реагировать на подобные изменения, в конечном счете успех многочисленных бизнес-инициатив зависит от того, насколько существующие средства автоматизации компании смогут в принципе быть адаптированными под новые предлагаемые услуги и как быстро. Получается, что в итоге все зависит от департамента автоматизации. Конечно эта ситуация является совершенно не естественной для бизнеса, но как ни странно, она не является также хорошей и для ИТ департамента, поскольку тот без основного бизнеса также прекращает существование.
При этом совершенно не стоит думать, что ИТ отделы упиваются неожиданно свалившимися на них значимостью и властью. Скорее наоборот, сотрудники этих отделов все больше времени проводят на совещаниях, выясняя почему сроки сдачи проектов все больше затягиваются, составляя обьяснительные записки, почему существующее программное обеспечине не может быть легко адаптировано под новые требования и обосновывая необходимость расширения персонала. Рукодителей этих отделов бросает в холодный пот, когда им необходимо обьяснять на совещаниях, почему несмотря на все инвестиции, план внедрения новой бизнес-услуги постоянно срывается по причине неготовности программного обеспечения.
Определение SOA
По своей сути service-oriented architecture (SOA) не содержит новых революционных идей, а является обобщением лучших практик создания программно-информационных систем уровня предприятия и выше, она не привнесла ничего оригинального, но она служит квитэссенцией ведения интеграционных проектов.
Основными причинами появления SOA являются высокая динамика современного бизнеса и неуклонно возрастающие требования к постоянной адаптации информационных систем по отношению к этой динамике. Уже недостаточно, чтобы информационная система обеспечивала простую автоматизацию информационных и расчетных задач бизнеса. Необходимо стремиться к тому, чтобы быстро меняющиеся условия бизнеса, возникающие вследствие ужесточения конкуренции, находили полное отражение в информационной системе, то есть корпоративная информационная система должна меняться столь же быстро, сколь быстро меняются требования бизнеса и бизнес-процессы компании.
В любом случае, заказчикам необходимо полное понимание своего бизнеса и понимание неизбежности работы на перспективу, не ожидая сиюминутной отдачи, а консультантам и системным интеграторам необходима высокая квалификация на всех уровнях, понимание задач клиентов и согласование зон ответственности. Но нужно понимать, что SOA это не панацея от всех бед и не цель, а средство ее достижения и получения практических результатов.
SOA характеризуют следующие основные принципы, следование которым позволяет сказать является ли информационная система сервис-ориентированной или нет:
- сервисы как компоненты информационной системы, которые публикуют свои интерфейсы (контракты). Эти контракты являются независимыми от платформы, языка программирования, операционной системы и других технических особенностей реализации, сервисы взаимодействуют между собой и вспомогательными службами посредством открытых, широко используемых стандартов.
- каждый, составляющий информационную систему сервис реализует отдельную бизнес-функцию, которая является логически обособленной, повторяющейся задачей, являющейся составной частью бизнес-процесса предприятия.
- низкая связанность (loose coupling). Сервисы в системах, построенных на SOA могут быть реализованы в независимости от других служб системы, необходимо только знание интерфейса используемых сервисов.
Как видно, каждый из пунктов не является специфической особенностью СОА, многие технологии взяли на вооружение эти принципы, отличительной особенностью построенной на SOA системы является одновременное следование всем указанным принципам.
Рассмотрим их немного подробнее.
Сервисы как компоненты информационной системы
Сервисом называется независимый программный компонент, выполняющий определенную задачу, такую как например «проверить кредитную карточку», не требующей для использования клиентами какой-то определенной программной технологии.
Использование открытых стандартов является важной характерной особенностью SOA. Это значительно уменьшает время подключения нового бизнес-сервиса к существующей системе, так же как и (что является часто крайне важным моментом для предприятий, имеющих богатые наработки за предыдущее время), при внедрении СОА, нет необходимости переписывать или просто отказываться от проверенных годами и действующих решений.
Выбор распределенной технологии играет существенную роль. Использование, например, SNA или DCOM в качестве средства общения сервисов накладывают такое ограничение, при котором все компоненты в системе обязаны использовать SNA или DCOM, что ограничивает применимость системы.
Когда же говорят том, что информационная система следует принципам СОА, то сервис, реализованный, например, на языке Java и работающий в EE контейнере должен быть применим для использования клиентами, реализованными в Windows среде и наоборот.
Сервис выполняет повторяющуюся бизнес функцию
Что такое сервис в контексте SOA? Является ли сервисом функция в приложении? Являются ли технические сервисы сервисами, о которых говорят, когда имеют в виду СОА? Все это важные и уместные вопросы. Сервисы в SOA реализуют повторяющиеся бизнес-функции, которые необходимы для организации согласованной работы сложных, состоящих из большого числа различных компонентов, приложений.
Как правило, существующие корпоративные приложения состоят из некоторого числа монолитных модулей, в каждый из которых часто включают реализацию одинаковых фрагментов бизнес-логики, например, в приведенном выше примере страховой компании, начавшей также оказывать финансовые услуги, может быть в страховом и банковском программных модулях производиться расчет скидки на основе клиентских данных, клиентской истории и объема текущей операции. Если же при разработке придерживаться принципов сервис-ориентированной архитектуры, то следует реализовать сервис «расчет скидок», к которому обращались бы все сервисы, которым необходимо рассчитать скидку.
Таким образом функциональность используется многочисленными приложениями и существует возможность быстро и относительно просто изменить бизнес-логику, приспосабливая ее к постоянно меняющимся условиям рынка.
Причем изменения необходимо вносить только в один-единственный сервис, и сделанные изменения одновременно используются всеми клиентскими приложениями.
Это и является одним из главных достоинств SOA.
Необходимо отметить, что для успешного внедрения и последующего функционирования базирующейся на СОА системы, при разработке в первую очередь должен быть произведен анализ и описание бизнес-процессов компании. В принципе это достаточно независимые шаги, ведь описанные и отлаженные бизнес-процессы в значительной степени сами по себе являются основой успешной работы предприятия, являясь своего рода скелетом системы управления. В этом случае каждой структурной единице присвоены свойственные только ей функциональные обязанности, предоставляя информацию руководству для принятия управленческих решений и координации работы предприятия в целом. В таком случае автоматизация бизнес-процессов за счет использования программного обеспечения позволяет дополнительно ускорить их выполнение.
Существует бесчисленное количество примеров неудачного или не очень удачного внедрения автоматизированных информационных систем. При анализе этих проектов очень часто становится понятно, что отправной точкой всех неудач является заблуждение, что с внедрением автоматизированной системы решатся все внутренние проблемы на предприятии. В результате на первый план выходила разработка программного обеспечения, которая автоматизировала существующий беспорядок. Процессы управления, несмотря на всю произведенную автоматизацию, по сути оставались прежними.
В то время как на самом деле основной причиной этих проблем является отсутствие ясных и отработанных бизнесс-процессов, регламентирующих безотказную деятельность всех подразделений компании.
В принципе на важность и даже необходимость декомпозиции бизнес процессов при внедрении автоматизированных систем уровня предприятия обращалось внимание уже очень давно, но именно в СОА это является одним из основополагающих принципов.
Низкая связанность (loose coupling)
Низкая связанность - важный архитектурный принцип при разработке СОА систем. Использование этого принципа позволяет связывать различные компоненты информационной системы во время ее функционирования с помощью, так называемого, позднего связывания (late binding).
Благодаря этой особенности также значительно облегчается внесение изменений в функциональность сервисов, поскольку это совершенно не затрагивает другие сервисы.
Благодаря низкой связанности значительно упрощается пошаговое создание корпоративной системы из-за отсутствия барьеров реализации функциональности сервиса за несколько итераций.
Возможность динамически подключать новые сервисы, также как и поиск этих сервисов клиентами является также одним из краеугольных принципов системы, построенной на основе service-oriented architecture.
Пример построенной на SOA информационной системы
В этой части будет рассмотрена построенная на базе SOA информационная система некоторого предприятия. До сих при описании сервис-ориентированной технологии не было упоминания о технологиях, на которых могут быть построены системы и это достаточно справедливо, поскольку, как уже упоминалось, СОА - новый подход к построению корпоративных информационных систем.
Однако все-таки, наверное, имеет смысл рассмотреть, из каких компонент может состоять некая идеальная усредненная SOA система. Многие из предоставленных ниже этих составляющих частей настолько важны и объемны, что могут являться темами отдельного рассмотрения, здесь же эти компоненты будут предоставлены только для общего ознакомления.
Итак, основными компонентами (представлены на рисунке 1) являются сервисная шина предприятия (ESB), СОА реестр (SOA Registry), workflow engine, сервисный брокер (service broker), СОА супервизор (SOA supervisor) Все они играют собственную роль в системе, при этом взаимодействуя друг с другом.
Рисунок 1.
Сервисная шина предприятия (ESB):
В сервис-ориентированной архитектуре все различные части программного обеспечения общаются друг с другом, как правило, посылаю друг другу достаточно много сообщений. Эти сообщения должны быть доставлены быстро и доставка должна быть гарантирована.
Для передачи сообщений в SOA как правило используют сервисную шину предприятия (Enterprise Service Bus – ESB). Сервисная шина является настолько важной в СОА, что возможно представить, что сервис-ориентированная архитектура не может существовать без нее и, наоборот, наличие ее является достаточным условием для SOA. На самом деле можно построить основанную на сервис-ориентированной архитектуре систему без применения сервисной шины и ее наличие не гарантирует позиционирование системы как СОА.
Сервисная шина предприятия может быть представлена как отдельный уровень программного обеспечения, который совместно с корпоративной сетью обеспечивает гарантированный сервис отправки-приема сообщений, которые посылаются всеми остальными частями корпоративной системы.
СОА реестр (SOA Registry):
СОА реестр это своего рода электронный каталог, где хранится информация о каждом компоненте, составляющем корпоративную информационную систему, и об интерфейсах, которые эти компоненты используют для обеспечения связи между собой.
В эксплуатационном окружении СОА реестр поставляет клиентам информацию о сервисах, доступных в текущий момент для использования (что особенно важно для сервисного брокера).
Для разработчиков программного обеспечения и бизнес аналитиков СОА реестр является источником информации, которая помогает им выбирать существующие компоненты и соединять их для создания новых приложений и построения новых процессов.
СОА реестр также хранит информацию каждого компонента.
Workflow engine:
Каждый бизнес имеет свой workflow, являющимся случайным в каждом конкретном случае или формально описанным, сложившийся как бы само собой или возникший в результате тщательного анализа и автоматизации.
Workflow engine это программный продукт, позволяющий соединить весь бизнес процесс в корпоративной информационной системе от начала до его завершения, система для воспроизведения потока работ по имеющейся модели.
При этом обработка данных на отдельных этапах осуществляется в различных независимых друг от друга приложениях, а функции организации процесса и связи различных подсистем реализует специализированная Workflow система.
Продукты, моделирующие бизнес процессы, существовали задолго до СОА, существует огромное количество предложений от различных поставщиков, часто специализирующихся в различных областях. Около 15 лет назад большинство из этим систем были связаны с системами документооборота. Сейчас же поставщики этих систем все более тяготеют к системам управления бизнес-процессами и административными регламентами (business process management system или просто BPM).
Cервисный брокер (service broker):
Сервисным брокером является служба, соединяющая различные сервисы вместе. Он получает всю необходимую информацию от СОА реестра (SOA Registry), что означает, что реестр и брокер должны работать координировано.
Рисунок 2.
На рисунке 2 представлено как в некоторой СОА системе сервисный брокер организовывает обработку заказов. Схема включает только 4 бизнес сервиса и workflow engine.
Стрелками изображены действия сервисного брокера, утолщенные линии изображают потоки запросов.
Последовательность действий может выглядеть следующим образом:
- Пользователь входит в систему и запрашивает службу обработки заказов. Поскольку эта служба еще не запущена, сервисный брокер получает соответствующее уведомление и начинает свою работу
- Сервисный брокер запрашивает у СОА реестра, что необходимо для запуска службы обработки заказов и возможно ли ее стартовать в настоящее время
- Сервисный брокер проверяет, запущены ли 4 необходимых для службы обработки заказов бизнес-сервиса, если еще не запущены, то стартует их.
- На основании полученной от реестра СОА сервисный брокер проверяет интерфейсы между бизнес компонентами. Эти компоненты можно затем соединить вместе для службы обработки заказов.
- Сервисный брокер уведомляет бизнес компоненты, что они должны связаться с workflow engine для выполнения необходимой службы и бизнесс процесс начинает выполняться
Некоторые реализации сервисной шины предприятия (ESB) выполняют также функции сервисного брокера.
СОА супервизор (SOA supervisor):
СОА супервизор это, можно сказать, главный служебный сервис, функционирующий все время работы системы и контролирующий и координирующий работу всех остальных, прежде все служебных, сервисов.
Одна из основных задач СОА супервизора это отслеживать работу различных компонентов внутри СОА системы, оценивать корректность их функционирования, а также отслеживать запросы, посланные во внешние системы.
Трудно переоценить важность этого компонента.
Не секретом является тот факт, что для достижения определенного уровня перфоманса гораздо проще не использовать принцип низкой связанности, поскольку его реализация ведет к необходимости создания определенной инфраструктуры, которая несомненно налагает свой отпечаток на скорость выполнения.
Поэтому реализуя принцип СОА необходим своего рода контролирующий компонент, который своевременно будет оповещен в случае возникновения каких-либо проблем в ходе выполнения, чтобы можно было своевременно принять меры и продолжать обеспечивать клиентам достаточный уровень сервиса.
Очень часто становление того или иного подхода сопровождается появлением неверных или ошибочных трактовок. SOA не является чем-то новым: IT-отделы компаний успешно создавали и развертывали приложения, поддерживающие сервис-ориентированную архитектуру, уже много лет - задолго до появления XML и Web-сервисов.
SOA - это всего лишь иной стиль построения современных корпоративных систем. Он ориентируется на сервисы, характеризуется распределенной архитектурой и слабосвязанными интерфейсами. Сервис в данном случае - это не что иное, как единица работ, выполняемая сервис-провайдером для обеспечения желаемого результата потребителю сервиса. Именно сервис, а не объект, как в ООП, является повторно используемым, и при этом он не зависит от технологий, языковых сред и других ресурсов. Интегрирующую роль между сервис-провайдером и потребителем берут на себя программные агенты. Ряд архитектурных особенностей SOA позволяет уменьшить степень связанности различных элементов системы. Для взаимодействия компонентов используется сравнительно небольшой набор простых интерфейсов, которые обладают только самой общей семантикой и доступны всем провайдерам и потребителям. Через эти интерфейсы передаются сообщения, ограниченные некоторым словарем. А поскольку даны только общая структура корпоративной системы и словарь, то вся семантика и бизнес-логика, специфичная для приложений, описывается непосредственно в этих сообщениях.
Сами Web-сервисы не предполагают какого-либо архитектурного решения, в то время как именно архитектурой определяется стиль процессов взаимодействия. SOA не предписывает жесткой вертикальной методологии проектирования, внедрения или управления ИТ-инфраструктурой. Вместо этого, SOA ограничивается лишь рядом принципов, характеризующих каждый из этих процессов; поэтому ее иногда называют не архитектурой, а архитектурным стилем.
Отметим некоторые из этих принципов.
Распределенное проектирование. Решения относительно внутренних особенностей информационных систем принимаются различными группами людей, имеющими собственные организационные, политические и экономические мотивы.
Постоянство изменений. Отдельные участки архитектуры могут претерпевать изменения в любой момент времени.
Последовательное совершенствование. Локальное улучшение компонентов архитектуры должно приводить к совершенствованию всей архитектуры в целом - к росту суммарной полезности компонентов того же уровня, что и изменяемый, равно как и компонентов более низкого и более высокого уровня.
Рекурсивность. Однотипные решения имеют место на различных уровнях архитектуры.
Как бы неожиданно это ни показалось, перечисленные принципы были сформулированы американским архитектором Кристофером Александером в отношении архитектуры современного мегаполиса. В 1987 году он и его коллеги опубликовали работу под названием «Новая теория городского проектирования» (A New Theory of Urban Design), где излагались взгляды на возможность децентрализованного развития городов. В своей работе Александр показал, как можно осуществлять развитие городов с учетом существенной демографической разнородности жителей. Аналогичным образом SOA, основанная на адаптации этих принципов, позволяет объединить в общий взаимодействующий организм информационные системы, принадлежащие различным автономным организациям и их относительно автономным структурным подразделениям.
Общая схема.
В самом общем виде SOA предполагает наличие трех основных участников: поставщика сервиса, потребителя сервиса и реестра сервисов (см. рис. 2). Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом). Отсутствие любого из этих элементов недопустимо, а добавление других составляющих на практике не только возможно, но и неизбежно. Среди таких элементов могут быть всевозможные программные средства промежуточного слоя, контролирующие порядок и контекст взаимодействия, осуществляющие мониторинг и управление сервисами, а также управление метаданными и другие вспомогательные процессы.
Рис. 2.
Для использования сервиса необходимо следовать соглашению об интерфейсе для обращения к сервису - интерфейс должен не зависеть от платформы. SOA реализует масштабируемость сервисов - возможность добавления сервисов, а также их модернизацию. Поставщик сервиса и его потребитель оказываются несвязанными - они общаются с помощью сообщений. Поскольку интерфейс должен не зависеть от платформы, то и технология, используемая для определения сообщений, также должна не зависеть от платформы. Поэтому, как правило, сообщения являются XML-документами, которые соответствуют XML-схеме.
Модель SOA не зависит от технологий, использующихся для реализации SOA, а основным методологически значимым ее компонентом является реестр сервисов. В обозначенном на схеме асинхронном протоколе общения провайдера и потребителя сервисов он выполняет функции посредника. Провайдер размещает информацию о своих сервисах в реестре, что дает возможность потребителю в любой момент найти необходимый ему сервис. На первый взгляд, кажется, что в этом нет ничего особенного, однако за этим процессом общения скрывается основное качество SOA -- слабая связанность. Благодаря этому свойству, сервисы обретают мобильность, способность перемещаться с одного сервера на другой, не требуя согласования и координации со всеми потребителями. Естественно, что потребители сервисов в ряде случаев не способны и не должны принимать во внимание регулярное перераспределение ресурсов, обеспечивающих функционирование сервисов.
Позднее связывание также позволяет отложить момент конечной сборки связей до времени исполнения, а не времени разработки программы, что характерно для традиционных монолитных систем. Можно также во время исполнения менять параметры связи (такие как адрес, протокол и канал взаимодействия). Это придает несколько измерений гибкости самой связке между провайдером и потребителем сервиса -- соответственно вызываемым и осуществляющим вызов объектами. В частности, провайдер и потребитель могут исполняться на сколь угодно физически удаленных инфраструктурах. Каждая из систем может иметь собственные параметры жизненного цикла, а любые изменения в них, не затрагивающие интерфейс сервиса, не требуют остановки ни одной из них.
В SOA сервисы рассматриваются как автономные объекты, управление которыми не централизовано. Это позволяет взаимодействующим посредством сервисов информационным системам развиваться в соответствии с потребностями бизнеса, которые потребителям сервисов, как правило, не только не известны, но и не интересны. Однако это было бы невозможно, если бы интерфейс сервиса не был прочно закреплен обоюдным соглашением провайдера и потребителя сервиса. Одной из отличительных черт SOA является наличие контрактов, описывающих интерфейсы сервисов. Такой контракт представляет собой документ, специфицирующий ожидания сервиса по отношению к его потребителям и наоборот. Контракты Web-сервисов описываются WSDL-документом, в нотации XML определяющим, как потребители должны обращаться к сервису. Использование XML на этом этапе имеет принципиальное значение, позволяя и провайдеру, и потребителю сервиса не зависеть от определенной платформы.
Подобные контракты существовали и до появления Web-сервисов. Например, в архитектуре CORBA для описания интерфейса объектов использовался язык IDL, который уступает WSDL по ряду существенных параметров. Главный из них -- отсутствие поддержки XML и XML Schema, ставших наиболее распространенными языками разметки передаваемых по сети сообщений и представления моделей данных. Технические контракты, формулируемые провайдером сервисов, должны быть доступны потенциальным потребителям для интерпретации, анализа и реализации интеграции. Для этого используется специальный реестр, каталогизирующий доступные сервисы.
