Назовите меня троллем, если хотите, но я серьезно - как точно новый тренд 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 - это слово раздутое для маркетинговой цели. Технически это так же просто, как де-сериализация и сериализация данных, чтобы сервисы могли быть развязаны и независимы от платформы, но идея, стоящая за ней, конкретна.
Вячеслав Ерохин
В статье рассматривается сервис-ориентированная архитектура (SOA ) как бизнес-концепция. Предлагается подход к управлению жизненным циклом SOA с помощью методики «Управление SOA » (SOA Governance ), основанной на средствах управления архитектурой предприятия (Enterprise Architecture Management ) и стратегического управления ИТ.
Для того чтобы предложить эффективный способ управления SOA , нужно понять что же это такое? В зависимости от ответа, может строиться своя система решений задачи управления жизненным циклом SOA .
SOA – Service Oriented Architecture – архитектура, ориентированная на сервисы. SOA – это прежде всего бизнес-концепция архитектурного подхода к построению предприятия. Более ранние концепции не ставили в центр внимания архитектуру предприятия
SOA – первая широко известная бизнес-концепция, концентрирующаяся на архитектуре. Таким, образом, SOA надо понимать и применять в контексте управления архитектурой предприятия (Enterprise Architecture Management ). Архитектура предприятия включает разные слои: бизнес-архитектура, информационная архитектура, техническая архитектура и т.д. SOA начинается с уровня бизнес-архитектуры.
Концепция SOA концентрируется на архитектуре, но архитектуре ориентированной на сервисы. Что такое сервисы и в чем разница с более ранними концепциями?
SOA , прежде всего, говорит о бизнес-сервисах. Конечно реализация SOA позволяет перейти к техническим сервисам, но это именно реализация SOA , а не ее суть. Самодостаточность, заменяемость и многократная используемость технического сервиса, лишь вытекает бизнес-сервиса. С точки зрения построения архитектуры предптриятия на принципах SOA первичен именно бизнес-сервис.
Таким образом, в SOA стоит выделить первый уровень - бизнес-архитектуры. В свою очередь бизнес-сервисы не существуют в отрыве от миссии компании, ее стратегии и целей. Бизнес-сервисы вытекают из места компании во внешней конкурентной среде. Долгосрочное развитие бизнеса может быть основано только на конкурентных преимуществах и их сочетании, обеспечивающем синергетический эффект. Обычно таких преимуществ немного – два-три. Большая удача – если их пять-шесть. Главная задача выживания компании – это задача создания и сохранения ее конкурентных преимуществ. Но конкурентные преимущества – или по-другому бизнес-потенциалы (Business Capabilities ) – не строятся на основе процессов. Это функции компании как целого организма во внешней среде.
Концепция бизнес-потенциалов (business capabilities ) получила в последнее время мощное развитие. Бизнес-потенциалы определяются как система конкурентных преимуществ, необходимых для реализации бизнес-стратегии предприятия. Бизнес-потенциалы ранжируются для определения их влияния на бизнес предприятия. Критически важные для бизнеса бизнес-потециалы получают максимальный приоритет. Такие бизнес-потенциалы являются самым высокоуровневым элементом построения архитектуры предприятия.
Проведение приоритизации бизнес-потенциалов позволяет принять решения, определяющие области управления в масштабе всего предприятия. Бизнес-потенциалы не критически важные для обеспечения долгосрочной конкурентоспособности предприятия остаются в поле зрения соответствующих бизнес-подразделений, рабочих групп или сотрудников, с предоставлением им соответствующих прав для их свободного использования и изменения. Такое распределение бизнес-потенциалов по степени важности и правам по их управлению определяется требованиями разумной минимизации архитектурной сложности на каждом уровне управления – принципом архитектурного минимализма.
Концепция бизнес-потенциалов в сочетании с принципом архитектурного минимализма открывает возможность к интеграции лучших черт, свойственных централизованной и децентрализованной моделям управления предприятием. Централизованные решения обеспечивают управляемость и мощный эффект от взаимодействия нескольких бизнес-потенциалов критически важных для бизнес-стратегии предприятия. Создается также благоприятный контекст для децентрализации управления предприятием, способной обеспечить инновационный цикл через создание малых рабочих групп с высокой автономией в принятии решений, не обязательно согласуемых с общей стратегией предприятия.
Основные правила, заложенные в основу концепции бизнес-потенциалов:
Цель предприятия в рамках концепции бизнес-потенциалов – построение эффективной архитектуры предприятия, позволяющей:
Управление бизнес-потенциалами в контексте архитектуры предприятия – в частности архитектуры приложений – позволяет поддерживать анализ текущих показателей эффективности деятельности компании в сравнении с желаемыми показателями эффективности с построением их иерархической взаимосвязи. Этот метод позволяет выделить ключевые бизнес-потенциалы компании и обеспечить их приоритетную поддержку со стороны ИТ. С другой стороны, выделение бизнес-потенциалов, не дающих компании конкурентных преимуществ, позволяет сократить их поддержку или передать ее сторонним провайдерам на аутсорсинг.
Бизнес-потенциалы (Business
Capabilities
) легко декомпозировать в бизнес-сервисы, но трудно – в бизнес-процессы. Сервисный подход ориентирован на стратегические цели компании – создание и сохранение бизнес-потенциалов.
Сервисный подход организации бизнеса ориентирован на построение сетей создания стоимости, предполагающих функциональное разделение рыночных субъектов и создание возможностей установления связей между ними. Процессный подход организации бизнеса ориентирован на способы реализации цепочек создания стоимости, где субъекты рынка объединены для производства товаров и услуг.
В сервисном подходе –именно бизнес-сервис является основным объектом планирования и управления. Бизнес-процесс – это способ реализации бизнес-сервиса. В процессном подходе первичен бизнес-процесс, как уникальная цепочка создания стоимости. Бизнес-сервис в процессном подходе либо не актуализируется вовсе и заменяется на технический сервис, либо является подчиненным элементом бизнес-процесса, кирпичиком из которых строится бизнес-процесс.
Может сложиться мнение, что SOA – это концепция, ориентированная на использование единой технологической платформы на основе веб-сервисов. Это не совсем так.
В SOA
первично использование концепции архитектуры предприятия и концепции бизнес-сервисов. Следовательно, предприятие внедрившее управление архитектурой предприятия и управление на основе бизнес-сервисов является предприятием использующим SOA
. Однако, если предприятие использует единую технологическую платформу типа Middleware
, технические сервисы в виде веб-сервисов, то оно не обязательно внедрило у себя SOA
.
Однако, прелесть SOA в том, что предприятие, внедрившее SOA , может эффективно использовать единую технологическую платформу и реализацию бизнес-сервисов, в виде набора технических сервисов.
Стив Джонс, автор книги «Enterprise SOA Adoption Strategies. Using SOA to deliver IT to the businesss» утверждает: «Большинство компаний совершают одну принципиальную ошибку в отношении технологий: они рассмативают их через призму существующих процессов. Компании спрашивают: "Как эти новые технологические возможности могут улучшить и оптимизировать текущую работу?" Но вместо этого они должны спрашивать: "Что новое могут позволить нам делать технологии?" В отличие от автоматизации суть реинжиниринга - в новаторстве, в использовании новейших технологических возможностей для достижения совершенно новых целей. Один из самых сложных элементов реинжиниринга - умение найти новые, незнакомые возможности технологии».
Приходится слышать, что SOA предполагает реинжиниринг бизнес-процессов. Нет – SOA предполагает отказ от бизнес-процессов как бизнес-концепции. SOA предполагает реинжиниринг предприятия, а не его бизнес-процессов. SOA предлагает концепцию бизнес-сервисов вместо бизнес-процессов.
Процессный подход оказался неприменим в большинстве компаний. И не потому, что в этих компаниях работали неквалифицированные менеджеры. Главные причины провала попыток внедрения процессного подхода:
Бизнес-процессы обращены внутрь компании и нацелены на оптимизацию исполнения корпоративной мелодии (бизнес-процесса) – раз и навсегда заданной. Поэтому так остро стоит проблема постоянного реинжиниринга бизнес-процессов. Бизнес-процесс-это мелодия. И до сегодняшнего дня большинство предприятий проектируют под эту мелодию свой оркестр. Для другой мелодии они проектирую другой оркестр. Получается множество оркестров, исполняющих множество мелодий. Есть оркестр, исполняющий вальс, есть оркестр исполняющий польку и т.п. Так получается, потому, что целью проектирования и управления является исполнение конкретной – часто уникальной - мелодии, а кто и как исполняет эту мелодию – неважно. Если нам надо будет исполнить другую мелодию, нам придется сделать или купить другой оркестр.
SOA ставит целью создание набора инструментов, с помощью которого можно будет исполнить любую мелодию – бизнес-процесс (не важно какую) - нужную предприятию. SOA – это набор инструментов, необходимый и достаточный для исполнения и польки, и вальса. SOA – это единая нотная грамота, позволяющая исполнить любую мелодию. SOA – это аранжировка мелодии, учитывающая доступный набор инструментов.
SOA требует не реинжиниринга бизнес-процессов на предприятии, а конструирование бизнес-процессов из набора бизнес-сервисов. SOA предполагает наличие бизнес-процесса по конструированию бизнес-процессов. Такой бизнес-процесс называется SOA Governance .
SOA Governance (управление SOA ) позволяет компании, использующей SOA , реализовать весь потенциал этого архитектурного подхода. SOA Governance позволяет решить проблемы, которые в противном случае могут помешать добиться гибкости и обеспечить преимущества, доступные при использовании SOA.
SOA Governance – это процесс управления жизненным циклом предприятия, построенного на основе SOA . SOA Governance – это также инфраструктура управления жизненным циклом SOA . Эффективное управление SOA - это не просто технология. Это подход к жизненному циклу, в котором участвуют все ответственные сотрудники организации, и учитываются различные активы организации.
Создание инфраструктуры управления SOA, предполагает решение ряда типовых задач:
Архитектура, ориентированная на сервисы, позволяет включать многократно используемые сервисы в состав типовых наборов или исключать их из состава этих наборов в зависимости от требований, предъявляемых в каждом бизнес-подразделении или регионе.
Реализация подхода SOA Governance позволяет ответить на следующие вопросы:
Эффективное управление SOA предполагает отказ от увеличения количества ненужных сервисов и создание механизма управления изменениями в многократно используемых сервисах. Этого можно достичь через реализацию соответствующих механизмов управления:
Разработка и внедрение механизмов управления изменениями и учета специфики пользователей, позволяет отвечать на следующие вопросы:
Для оценки эффективности инфраструктуры, построенной на основе SOA , требуется разработка соглашения об уровне обслуживания (Service Level Agreement - SLA). Необходимо также внедрение средств мониторинга, позволяющих, среди прочего, проводить биллинг за использование сервисов для оценки экономического эффекта. Такие средства мониторинга, должны обеспечивать доступ к информации о степени загрузки сервисов и стоимости их использования.
Для эффективного внедрения решений на основе архитектуры SOA важно с самых первых шагов реализовать процесс управления архитектурой, разработать наборы показателей и обеспечить доступность информации об использовании сервисов и ходе реализации проекта по внедрению SOA.
Процесс SOA Governance состоит из четырех этапов:
На этапе планирования анализируются потребности организации и выявляются области, в которых требуется более эффективное управление.
Основная часть планирования проводится специалистами, отвечающими как за развитие направлений бизнеса, так и за ИТ-инфраструктуру, и предполагает организацию их совместной работы. На этом этапе определяются проблемы согласования бизнеса и ИТ, требующие решения.
На этом этапе реализуются следующие мероприятия:
После определения направлений работы специалисты в области бизнеса и информационных технологий совместными усилиями определяют и трансформируют существующие методы и механизмы управления. На этом этапе, происходит формирование походов по созданию различных политик управления.
На этапе определения принимаются различные решения в области управления SOA :
На этапе реализации решения по управлению SOA претворяются в жизнь. На этом этапе выполняются следующие работы:
На этапе оценки осуществляется мониторинг методов и механизмов управления, выявленных на этапе определения и внедренных на этапе реализации.
Это позволяет оценить полученные результаты и запустить новый цикл из четырех этапов управления SOA для повышения эффективности управления. Как правило, на этом этапе выполняются следующие работы:
Эффективное управление предприятия, построенного на основе SOA возможно только с использованием соответствующего инструментария.
Требования к инструментарию SOA Governance позволяют сформировать набор продуктов, отвечающий задачам управления SOA :
Инструмент SOA Governance должен обеспечивать поддержку текущей, целевой и планируемой архитектур предприятия. Архитектура предприятия должна содержать не только технический и информационный слои, но и бизнес-слой.
Инструмент SOA Governance должен обеспечивать поддержку элементов сервис-ориентированной архитектуры. Наиболее важной является поддержка типов артефактов:
Инструмент SOA Governance должен обеспечивать поддержку всего процесса управления жизненным циклом SOA , состоящего из фаз планирование, согласование и определение, разработка и реализация, функционирование и оценка. Важно, чтобы инструментарий внедрялся на самых ранних стадиях реализации проекта по внедрению SOA . Это позволит избежать многочисленных ошибок планирования и сократить расходы на переход к SOA за счет создания единой платформы совместного управления для широкой профессиональной аудитории включающей менеджеров бизнес-направлений, системных архитекторов, менеджеров проектов, разработчиков ПО, финансистов и т.п.
Сегодня ни одна - даже очень крупная - компания не может обеспечить полноценную поддержку SOA Governance самостоятельно. Основной путь – это построение интегрированных решений на основе продуктов от независимых поставщиков. Такой путь позволяет использовать лучшие решения в каждом сегменте такого комплексного процесса как SOA Governance .
Ведущие поставщики программного обеспечения предлагают различные наборы инструментов, реализующих SOA Governance . Наиболее функционально полные решения предлагают компании IBM , Oracle , Software AG .
Интегрированное решение на основе alfabet planningIT и Oracle Fusion Middleware позволяет предоставить сквозную услугу по управлению жизненным циклом ИТ-инфраструктуры на основе SOA . Благодаря взаимодействию Oracle Fusion Middleware и alfabet planningIT можно успешно проектировать, разрабатывать и внедрять сервис-ориентированную архитектуру (SOA ).
Решение alfabet /Oracle обладает определенными преимуществами перед другими решениями SOA Governance :
Компоненты Oracle Fusion Middleware (FMW ):
Компоненты alfabet planningIT :
Система управления архитектурой предприятия и стратегического планирования ИТ Alfabet planningIT поддерживает планирование «сверху-вниз» с возможностью многослойного обзора ИТ-активов: бизнес-требования, бизнес-процессы, организационная структура, поддержка бизнеса со стороны ИТ, бизнес-приложения, сервисы. Это позволяет оценить насколько эффективно ИТ-инфраструктура обеспечивает поддержку бизнес-стратегии, стратегических целей, бизнес-процессов и т.п. Кроме того, становится возможным рассчитать стоимость изменений в ИТ-инфрастуктуре.
С помощью Oracle Fusion Middleware прозрачность планирования ИТ инфраструктуры расширяется для поддержки полного жизненного цикла ИТ-инфраструктуры на основе сервис-ориентированной архитектуры и обеспечения сквозного планирования и управления SOA .
Основным объектом интеграции alfabet planningIT и Oracle Fusion Middleware является объект «Сервис». В репозитарии alfabet planningIT существует артефакт «Технический сервис» (Technical Service ), который корреспондирует с термином «Сервис» (Service ) в SOA . Такой сервис может быть описан с использованием WSDL . Технический сервис в planningIT может быть создан или повторно использован для технической реализации логических сервисов. Логические сервисы в planningIT могут быть объединены в форме бизнес-приложений. Бизнес-приложение является артефактом репозитария, играющим ключевую роль в процессе планирования, управления, анализа затрат и т.п.
Продукты Oracle обеспечивают интегрированную поддержку проектирования, реализации и внедрения сервисов. Oracle Fusion Middleware реализует сервисную шину предприятия (ESB ) и оркестровку сервисов (BPEL ), а также предоставляет возможности мониторинга развернутых сервисов с помощью репозитария сервисов.
Система Alfabet planningIT также предоставляет инструментарий для оценки влияния изменений и проведения анализа затрат внедрения изменений. Oracle Fusion Middleware обеспечивает поддержку реализации, развертывания и выполнения сервисов, спланированных и прототипированных в planningIT .
Система alfabet planningIT является идеальным дополнением к Oracle FMW , поскольку она позволяет определить набор сервисов, имеющих стратегическое значение для предприятия. Сервисы могут быть легко оценены с точки зрения их места в архитектуре предприятия и могут быть спланированы в рамках единого процесса, прежде чем нужно будет приступать к их разработке и внедрению.
Использование planningIT для согласованного управления развитием бизнес и ИТ позволяет принимать управленческие решения о том, какие сервисы необходимо развивать, а какие - нет. Планирование уровня предприятия определяет, какие логические сервисы должны быть реализованы для обеспечения поддержки требований бизнеса.
Для обеспечения технической реализации логических сервисов пользователи planningIT могут детализировать описание логических сервисов в терминах технических сервисов. При этом технические сервисы могут быть импортированы из репозитария веб-сервисов Oracle . Если же необходимого технического сервиса не существует, то описание такого сервиса может быть создано в planningIT и затем опубликовано в репозитарии Oracle (OraSR +WSM ) со статусом «В стадии разработки». В то же время генерируется новый проект Java для реализации соответствующего технического сервиса.
Диаграмма процессов BPEL в Oracle соотносится с объектом бизнес-приложение (Business Application ) в репозитарии planningIT . Бизнес-приложение в planningIT – это набор бизнес-сервисов, которые поддерживают бизнес деятельность – а не программный компонент. Таким образом, бизнес-приложение может быть описано в виде диаграммы BPEL , описывающей оркестровку технических сервисов.
Бизнес-приложение может быть экспортировано из planningIT в виде проекта BPEL в формате XML . Все технические сервисы, соответствующие бизнес-приложению, должны быть включены в проект в формате XML и экспортированы в репозитарий Oracle (OraSR +WSM ). Диаграмма BPEL , разработанная в planningIT также может быть экспортирована для последующего использования в среде разработки Oracle (Oracle IDE ).
После развертывания сервисов, служба мониторинга Oracle Fusion Middleware позволяет отслеживать статус, использование и влияние любых изменений на сервисы. Эта информация возвращается planningIT , чтобы обеспечить процесс централизованного планирования и управления актуальными и полными данными.
Сквозная интеграция alfabet planningIT с Oracle FMW означает, что предприятия теперь могут вести управление эволюцией элементов SOA и жизненным циклом сервисов на основе надежных и последовательных данных и визуальной информации.
Модуль «Управление архитектурой предприятия» planningIT может использоваться для передачи и агрегирования данных с уровня внедренных сервисов на уровень бизнес-планирования, где менеджеры осуществляют оценку рисков, затрат, доступности и качества ИТ-сервисов для важных бизнес-процессов и продуктов. planningIT может импортировать статистику об использовании сервисов из Oracle BPEL Engine . Эта информация может использоваться для централизованного планирования SOA .
Сервис-ориентированная архитектура (SOA ) – путь к решению многих проблем, стоящих перед современным предприятием. SOA позволяет обеспечить конкурентоспособность компании в высококонкурентной среде, характеризуемой необходимостью постоянных изменений в бизнесе. Организация, готовая построить у себя сервис-ориентированную архитектуру, рискует столкнуться с большим количеством проблем, связанных с управлением переходом к SOA , а также планированием, развертыванием и функционированием SOA . Эти проблемы решаются за счет внедрения методик и инструментов управления жизненным циклом SOA – SOA Governance .
Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берёт своё начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько её реализаций. Но, по сути, SOA можно свести к нескольким идеям, причём архитектура не диктует способы их реализации:
SOA - это набор архитектурных принципов, не зависящих от технологий и продуктов, совсем как полиморфизм или инкапсуляция.
В этой статье я рассмотрю следующие паттерны, относящиеся к SOA:
В 1980-х началось активное использование корпоративных сетей и клиент-серверной архитектуры. Возникла потребность в стандартном способе взаимодействия приложений, которые созданы с использованием разных технологий, исполняются на разных компьютерах и под разными ОС. Для этого была разработана CORBA. Это один из стандартов распределённых вычислений, зародившийся в 1980-х и расцветший к 1991 году.
Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:
Сегодня 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) вызывает локальную процедуру, реализованную заглушкой.
Хотя сегодня можно найти применение для CORBA, но мы знаем, что нужно было уменьшить количество удалённых обращений , чтобы повысить производительность системы. Также требовался надёжный канал связи и более простая спецификация обмена сообщениями .
И для решения этих задач в конце 1990-х начали появляться веб-сервисы.
[Веб-]сервисы можно публиковать, находить и использовать стандартным образом вне зависимости от технологий.
- Microsoft 2004,
Благодаря микросервисам мы перешли в парадигме SOA от удалённого вызова методов объекта (CORBA) к передаче сообщений между сервисами.
Но нужно понимать, что в рамках SOA веб-сервисы - не просто API общего назначения, всего лишь предоставляющие CRUD-доступ к базе данных через HTTP. В каких-то случаях эта реализация может быть полезной, но ради целостности ваших данных необходимо, чтобы пользователи понимали лежащую в основе реализации модель и соблюдали бизнес-правила . SOA подразумевает, что веб-сервисы являются ограниченными контекстами бизнес-субдоменов (business sub-domain) и отделяет реализацию от решаемых веб-сервисами задач.
С точки зрения технологий SOA не просто сервисная архитектура, а набор политик, методик и фреймворков, благодаря которым мы предоставляем и получаем нужные сервисы.
- Microsoft 2004, Understanding Service-Oriented Architecture
У нас есть несколько приложений, которые асинхронно общаются друг с другом с помощью платформо-независимых сообщений. Очередь сообщений улучшает масштабируемость и усиливает изолированность приложений. Им не нужно знать, где находятся другие приложения, сколько их и даже что они собой представляют. Однако все эти приложения должны использовать один язык обмена сообщениями, т. е. заранее определённый текстовый формат представления данных.
Очередь сообщений использует в качестве компонента инфраструктуры программный брокер сообщений (RabbitMQ, Beanstalkd, Kafka и т. д.). Для реализации связи между приложениями можно по-разному настроить очередь:
Запрос/Ответ
Все эти паттерны можно отнести к либо к pull- (polling) , либо к push -подходу:
Сервисная шина предприятия использовала веб-сервисы уже в 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
У этого архитектурного паттерна есть положительные стороны. Однако я считаю его особенно полезным в случаях, когда мы не «владеем» веб-сервисами и нам нужен посредник для трансляции сообщений между сервисами, для оркестрирования бизнес-процессами, использующими несколько веб-сервисов, и прочих задач.
В основе микросервисной архитектуры лежат концепции SOA. Назначение у неё то же, что и у ESB: создать единое общее корпоративное приложение из нескольких специализированных приложений бизнес-доменов.
Главное различие микросервисов и шины в том, что ESB была создана в контексте интеграции отдельных приложений , чтобы получилось единое корпоративное распределённое приложение. А микросервисная архитектура создавалась в контексте быстро и постоянно меняющихся бизнесов, которые (в основном) с нуля создают собственные облачные приложения.
То есть в случае с ESB у нас уже были приложения, которые нам не «принадлежат» , и поэтому мы не могли их изменить. А в случае с микросервисами мы полностью контролируем приложения (при этом в системе могут использоваться и сторонние веб-сервисы).
Характер построения/проектирования микросервисов не требует глубокой интеграции. Микросервисы должны соответствовать бизнес-концепции, ограниченному контексту. Они должны сохранять своё состояние, быть независимыми от других микросервисов, и потому они меньше нуждаются в интеграции. То есть низкая взаимозависимость и высокая связность привели к замечательному побочному эффекту - уменьшению потребности в интеграции.
[Микросервисы - это] маленькие автономные сервисы, работающие вместе и спроектированные вокруг бизнес-домена.
- Sam Newman 2015, Principles Of Microservices
Главным недостатком архитектуры ESB было очень сложное централизованное приложение, от которого зависели все остальные приложения. А в микросервисной архитектуре это приложение почти целиком убрано.
Ещё остались элементы, пронизывающие всю экосистему микросервисов. Но у них гораздо меньше задач по сравнению с ESB. К примеру, для асинхронной связи между микросервисами до сих пор применяется очередь сообщений, но это лишь канал для передачи сообщений, не более того. Или можно вспомнить шлюз экосистемы микросервисов, через который проходит весь внешний обмен данными.
Сообщество предпочитает другой подход: умные конечные точки и глупые каналы . Микросервисы, из которых собираются приложения, должны как можно меньше зависеть друг от друга и при этом быть очень тесно связанными - они содержат собственную доменную логику и работают скорее как фильтры с точки зрения классического Unix: получают запросы, применяют логику и генерируют ответы. Они оркестрируются с помощью простых REST-подобных протоколов, а не сложных протоколов вроде WS-Choreography или BPEL либо какого-то централизованного инструмента.
- Martin Fowler 2014, Microservices
С помощью SOA реализуются три аспекта ИТ-сервисов, каждый из которых способствует получению максимальной отдачи от ИТ в бизнесе:
Появившаяся несколько лет назад концепция SOA поначалу воспринималась как некоторый новый подход к интеграции приложений на основе унифицированных отраслевых стандартов. Революционно новое решение SOA - это новый взгляд на модификацию и развитие функциональности прикладных корпоративных систем.
Своего рода предшественницей SOA стала технология Enterprise Service Bus , предоставлявшая унифицированный механизм взаимодействия приложений. Дополненная рядом других технологий, ESB позволила сформировать единую интеграционную платформу. По-видимому, качественный переход к SOA начался в тот момент, когда появилась возможность создавать поверх этого интеграционного слоя новые прикладные решения с использованием уже существующего функционала.
Еще недавно мы пользовались традиционными веб-ресурсами, не предполагая, что в этом плане можно что-либо кардинально поменять. Оказалось – можно, и появился веб-два-ноль. Тренд оказался настолько удачным и привлекательным, что моментально был взят на вооружение маркетологами. Ярлык 2.0 появился на многих программных решениях и в большинстве случаев его использование весьма спорно. Такой всеобщей тенденции не удалось избежать и сервисно-ориентированной архитектуре. Читать статью "SOA 2.0 "
Появление сервисно-ориентированного подхода произвело очередную реформу в теории разработки программного обеспечения, оставив в прошлом концепцию объектно-ориентированного программирования .
Как известно, повторное использование программного кода упрощает разработку больших информационных систем. До недавнего времени с этой целью традиционно применялся объектно-ориентированный подход, подразумевающий жёсткое объединение компонентов и объектов приложения в одно целое. В парадигме ООП от разработчика требуется знание прикладного программного интерфейса, в котором объединены атрибуты и методы, сообща реализующие необходимый функционал. Но поскольку объектные системы обычно создаются на основе какого-то одного языка программирования (Delphi , C Яык программирования++ , C Яык программирования# , Java и др.) и фиксированных механизмов обмена информацией между объектами и модулями информационной системы, то и в ООП сохраняются все зависимости и ограничения. Такой подход удобен не всегда - в частности, он не позволяет оперативно реагировать на изменение ситуации и, к примеру, проектировать новомодные системы, опирающиеся на концепцию «ресурсы по требованию». Кроме того, для модификации объектных систем нередко приходится переписывать коды связанных объектов и методов.
Cвести эти ограничения к минимуму позволяет технология SOA, которая многими уже признана как революция в технологии программирования.
Аналитики уверены, что по мере развития стандартов SOA компании освоят эту область, а вендоры модернизируют свои продукты в соответствии с ее требованиями. По их мнению, серьёзное осмысление SOA и ее продвижение в практику ИТ ещё впереди, хотя, возможно, в России - в отличие от мировой ситуации - самый глубокий спад интереса к теме будет зафиксирован немного позднее. Так или иначе сегодня вполне определенно можно сказать, что «гребень волны» в публичном обсуждении темы SOA пройден. В настоящее время происходит активное практическое применение концепции SOA и осмысление опыта реализованных проектов.
Ряд архитектурных особенностей SOA позволяет уменьшить степень связанности различных элементов системы. Для взаимодействия компонентов используется сравнительно небольшой набор простых интерфейсов, которые обладают только самой общей семантикой и доступны всем провайдерам и потребителям. Через эти интерфейсы передаются сообщения, ограниченные некоторым словарем. А поскольку даны только общая структура корпоративной системы и словарь, то вся семантика и бизнес-логика, специфичная для приложений, описывается непосредственно в этих сообщениях.
Корпоративная информационная система, построенная на основе SOA, состоит из набора сущностей, доступных через прикладные программные интерфейсы. Встроенный механизм поиска и обнаружения сервисов в общем реестре позволяет потребителю выйти на оператора, предлагающего искомую функцию.
Архитектура веб-сервисов также является сервисно-ориентированной. Более того, веб-сервисы - это суть SOA c двумя дополнительными ограничениями: интерфейсы базируются на интернет-протоколах (HTTP , FTP , SMTP Simple Mail Transfer Protocol - Простой протокол передачи почты , TCP), а все сообщения описываются в формате XML . Детальные описания стандарта веб-сервисов и спецификаций SOA приводятся на сайтах консорциума W3C и организации OASIS .
Практические аспекты сервисно-ориентированной технологии позволяют решить проблемы масштабируемости, интегрировать сети передачи данных и голоса, упростить процедуры проектирования и управления сетями, а также создать другие распределенные приложения, прозрачно взаимодействующие с ресурсами систем при помощи прикладных программных интерфейсов и открытых стандартов.
Грамотное и полноценное управление невозможно без целостного понимания тех компонентов, или столпов, которые поддерживают зрелый SOA-проект. Конечно, SOA-проект можно строить только на основных механизмах (механизме) поддержки, однако зрелый проект подразумевает больший уровень поддержки с ростом уровня ответственности, которая ложится на SOA-проект. Каждая предметная область требует разного подхода к управлению SOA, что, соответственно, разным образом отражается на «политике».
Следует также отметить, что политика имеет решающее значение для управления SOA, поскольку оно будет определять SOA-политику предприятия, а также то, кто создает политики SOA, где эти политики хранятся, как SOA-политика будет обновляться или изменяться, где ее можно проследить, какие системы/инструменты используются для осуществления SOA-политики, и какие отделы осуществляют ее вручную.
Вот шесть механизмов, с помощью которых поддерживается SOA-политика:
Эти механизмы используются обоими подходами к разработке и управлению SOA. Первый подход – это управление SOA по типу «сверху вниз». Он подразумевает, что управление по своей сути является стратегическим и начинается с модели и определённых проектов. Продвигаясь вниз, «стратегическое управление» определяет людей, процессы, сервисы, инструменты и технологии, которые будут привлекаться для поддержки корпоративного 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, расширяют концепцию сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов.
