Главная
Трубопровод
Сервис-ориентированная архитектура: от концепции к применению. Краткий обзор сервисно – ориентированной архитектуры (SOA)

Сервис-ориентированная архитектура: от концепции к применению. Краткий обзор сервисно – ориентированной архитектуры (SOA)

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

Речь идет, прежде всего, о сервисной модели взаимодействия между приложениями общей системы в рамках так называемой сервис-ориентированной архитектуры ( Service -oriented architecture SOA ) и о реализации архитектуры, "управляемой моделями" (модельная архитектура . Model-driven architecture MDA ).

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

Само понятие SOA не является чем-то принципиально новым, так как сходные возможности реализовывались и ранее, например, с помощью технологий обмена сообщениями. Принципиальным фактором является то, что современные подходы к реализации SOA охватывают не только технологический уровень обмена данными, но и уровень бизнес-операций. В частности, одним из важных результатов стала разработка специализированного языка BPEL (Business Process Executable Language for Web Services) для описания аспектов взаимодействия различных сервисов с точки зрения реализации бизнес-правил. Вообще говоря, принятие SOA как целевой архитектуры будет подразумевать и соответствующий подход к разработке приложений (SODA – service -oriented development architecture ).

Для задач электронного бизнеса соответствующая функциональность SOA реализуется на уровне web -сервисов (служб). Под web -сервисами понимаются программные системы, которые используют XML в качестве формата данных, стандарты Web Services Description Language ( WSDL ) для описания своих интерфейсов, Simple Object Access Protocol ( SOAP ) для описания формата принимаемых и посылаемых сообщений и стандарт Universal Description , Discovery and Integration ( UDDI ) для создания каталогов доступных сервисов. И хотя принципы сервис-ориентированной архитектуры создания информационных систем не обязательно предполагают использование технологий web -сервисов, связь между этими двумя направлениями в развитии информационных технологий является достаточно тесной. При этом web-сервисы являются технологическими спецификациями, в то время как сервис-ориентированная архитектура ( SOA ) является принципом проектирования архитектуры программных систем.

С учетом отмеченных выше существующих тенденций перехода к бизнесу "реального времени" и создания систем так называемого "расширенного предприятия", объединяющих само предприятие, его поставщиков, партнеров и клиентов в единую систему, становится очевидно, что технологии web -cервисов найдут свое применение на всех уровнях корпоративных информационных систем. Предполагается, что в будущем практически все взаимодействие приложений как в рамках одной информационной системы, так и между системами отдельных участников бизнес-процесса, будет осуществляться с использованием такого механизма, так что достаточно критическими становятся вопросы согласованной работы этих сервисов. Для описания такой работы были предложены даже специальные термины – "хореография" и "оркестровка" (очевидно, по аналогии с управлением оркестром из различных инструментов или ансамблем разных исполнителей). При этом, если хореография определяет взаимодействие различных участников с использованием сервисов, то оркестровка описывает взаимодействие сервисов в рамках одного бизнес-процесса, в частности, с использованием языка типа BPEL.

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

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

Сервис-ориентированная архитектура (SOA) — настоящей статье рассматриваются способы обоснования эффективности, а также варианты ее внедрения с минимальными затратами.

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

Эффект от оптимизации процессов управления информационными технологиями для бизнеса незначителен: если затраты на ИТ были сокращены на 5%, а в общей сумме затрат компании они составляют всего 2%, то суммарный эффект от оптимизации — 0,1%. Достигнутые результаты не приносят ожидаемого эффекта на уровне бизнеса, поэтому энтузиазм ИТ-специалистов часто сопровождается разочарованием.

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

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

Данный алгоритм при кажущейся простоте требует детального анализа и оценки преимуществ от применения SOA. Самые важные из них:

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

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

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

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

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

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

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

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

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

Система мотивации должна предусматривать следующие основные принципы:

  • чем больше типовых сервисов создается, тем лучше для проекта и тем выше производительность разработчика;
  • те, кто больше всех использует типовые сервисы, снижая затраты, должны быть поощрены;
  • поставщик сервисов должен быть вознагражден, когда его сервисы начинают применяться;
  • лидером SOA является тот, кто производит сервис, наиболее часто используемый потребителями.

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

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

Сервис-ориентированная архитектура и технологии BPM, ESB

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

Внедрение SOA невозможно без технологии управления бизнес-процессами (Business Process Management, BPM), которая поможет быстро компоновать новые автоматизированные процессы с учетом существующих сервисов. Сочетание принципов SOA с технологией BPM и BPM-системой гарантирует согласованность выполнения процесса без жесткой привязки к кодированию. В свою очередь BPM-система позволяет определить рамки использования компонентов и необходимость их типизации.

Далее при внедрении SOA потребуется инструментарий SOA Governance — библиотека унифицированных сервисов, которая обеспечит общий доступ к компонентам композитной среды для их повторного использования. SOA также должна поддерживаться определенным интеграционным инструментарием (Enterprise Service Bus, ESB), предназначенным для интеграции разнородных ИТ-ресурсов и рационализации обмена данными с помощью сервисной шины. И хотя в принципе SOA может быть построена без ESB, по мнению большинства аналитиков, именно интеграционная шина служит ключевым решением для сервис-ориентированной архитектуры.

А.Коптелов
Руководитель практики внедрения бизнес-приложений IDS Scheer Россия и страны СНГ

Аннотация

Продолжительность курса

· Лекции – 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) вызывает локальную процедуру, реализованную заглушкой.

  1. Заглушка проверяет вызов, создаёт сообщение-запрос и передаёт его в ORB.
  2. Клиентский ORB шлёт сообщение по сети на сервер и блокирует текущий поток выполнения.
  3. Серверный ORB получает сообщение-запрос и создаёт экземпляр скелета.
  4. Скелет исполняет процедуру в вызываемом объекте.
  5. Вызываемый объект проводит вычисления и возвращает результат.
  6. Скелет пакует выходные аргументы в сообщение-ответ и передаёт его в ORB.
  7. ORB шлёт сообщение по сети клиенту.
  8. Клиентский ORB получает сообщение, распаковывает и передаёт информацию заглушке.
  9. Заглушка передаёт выходные аргументы вызывающему методу, разблокирует поток выполнения, и вызывающая программа продолжает свою работу.

Достоинства

  • Независимость от выбранных технологий (не считая реализации 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, то лучше выберите микросервисы подходящего размера и количества, не больше и не меньше.

Назовите меня троллем, если хотите, но я серьезно - как точно новый тренд SOA отличается от архитектуры клиентского сервиса, которую я строил 15 лет назад? Я продолжаю слышать SOA, но я не вижу, как это отличается от того, что мы всегда делали. Назад 10 лет назад, у компании было несколько клиентов (на нескольких языках), которые говорили с одним и тем же сервисом. Это был не XML (это был двоичный протокол под названием Microsoft DCOM), и не было автоматического обнаружения через WSDL, но это нормально, так как чтение документов было так же просто. Наша система была даже "открытой" в том смысле, что мы ее достаточно документировали, чтобы третьи стороны могли говорить с нашими сервисами. Мы не были пионерами - каждая другая компания, которую я знала 10 лет назад, делала то же самое. Единственная разница, которую я вижу между тогда и сейчас, заключается в том, что теперь в Интернете есть одна служба, а 10 лет назад каждый клиент будет размещать свой экземпляр службы. Но это не проблема архитектуры, где физическая жизнь службы прозрачна для всех, кто пользуется службой.

Так что же такое SOA, которая отличается от того, что мы делали годами? Является ли SOA просто маркетинговым термином, представляющим собой наилучшую практику, которая на самом деле стала распространенной давным-давно? Или я немного упустил SOA, что отличается от того, что мы делали все это время?

10 ответов

Забудьте о XML. Забудьте о WSDL. SOA - это не технология, которую вы можете купить, хотя она часто продается именно так.

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

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

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

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

Позвольте мне использовать знаменитого мальчика-бичевателя Integration Hell: Telco.

Вернувшись в 90-е годы, компании сотового телефона были в изобилии в моем районе, почти так же многочисленны, как и реселлеры на большие расстояния, которые стали возможными благодаря дерегулированию коммуникаций середины 90-х. Ну, время продолжается, и Bell Atlantic становится электростанцией Verizon и поглощает компанию после компании (и хотя бы одного Baby Bell). У каждой из этих компаний есть технологии на башнях, в коммутационном оборудовании, в биллинговых системах, которые ПОЛНОСТЬЮ несовместимы друг с другом.

Итак, компания уходит и говорит, хорошо, у нас есть эти модели для того, как мы занимаемся бизнесом, давайте дружеское, последовательное лицо на ВСЕХ наших технологиях в виде WSDL/SOAP/XSD - на каждом языке и в системе мы сегодня могут быть сопряжены с этим! Медленно, но верно, компания создает все системы, способные сообщать о возможностях, быть опрошенными для загрузки и выставления счетов, а также подвергать будущих виджетов использованию в манерах, которые еще не были учтены.

Любой может создать SOA-клиент. Любой, у кого есть wget и текстовый редактор. И каждый может анализировать результаты (XML).

Это принципиально отличается от прошлых клиент-серверных архитектур. На днях я просто поговорил с кем-то о взаимодействии систем Cobol и Smalltalk с архитектурой SOA. Это легкая проблема для решения. Скажите, вы можете сказать то же самое для своих систем DCOM.

SOA ничего, кроме способа дизайна , в котором модули взаимодействуют друг с другом через "сервисы". Это просто, и теперь следующий вопрос: что такое "сервис" и каково его отличие от обычного "метода"?

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

SOA не имеет ничего общего с конкретной технологией, это всего лишь особый способ проектирования.

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

В случае новой компании-автозапуска с идеей для элемента программного обеспечения/набора программных средств я не вижу, как компания может начать с сервис-ориентированной архитектуры из офф. Сначала каждое решение (которое может хорошо развиваться в службу, чтобы оно могло взаимодействовать) должно стремиться к изолированному решению проблемного пространства.

Возможно, именно в "дорожной карте" для корпоративных возможностей или набора для каждого решения станет совместимым сервисом по мере завершения решений и ввода службы. Для этого, возможно, команды разработчиков будут применять модульный/компонентный подход к построению soluton (возможной службы), чтобы упростить включение решения в качестве службы в сервис-ориентированную архитектуру.

В случае, когда существующие острова программного обеспечения становятся интероперабельными службами в сервис-ориентированной архитектуре, подход позволяет программным элементам, которые могут быть распространены и могут быть записаны на разных языках, для связи через открытый API и/или общий протокол (например, вкус веб-службы) и общий формат данных (например, XML).

SOA - это подход или идея. Это не каркас или инструмент. Когда WDSL и EJB получают имя-падение, это часто забывается... так же, как идея SOA совсем не нова.

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

Аналогия: Игрушки строятся с использованием строительных блоков Lego.

Большинство ответов здесь, по-видимому, говорят о том, что SOA (Service Oriented architecture) относится к созданию приложения стандартизованным образом, чтобы другие приложения могли взаимодействовать с ним независимо от платформы.

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

Конечно, при разработке приложения вы не можете гарантировать, что он будет совместим с кросс-платформой. Возьмем, например, stock Trading systems . Они используют Fix protocol для передачи сообщений. Ожидаете ли вы теперь вернуть данные в формате XML, чтобы он мог быть так назван SOA-совместимым? Точно нет! SOA - это архитектурный подход, который может помочь вам decouple your application/services и позволить им взаимодействовать друг с другом. Магистраль SOA - это ESB (Enterprise Service Bus) , которая используется для передачи данных из одной службы в другую. Архитектура SOA должна заботиться о преобразованиях форматов. Например -

FIX(Service 1) -> (XML ---ESB---> XML) -> JSON (Service 2)

Эти модули преобразования обычно называются adapters и обычно являются частью пакета SOA. Для получения дополнительной информации обратитесь к другому ответу -

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



Разделы