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

Проблемы, связанные с автоматизацией управления, известны всем, описаны во множестве статей, и над ними трудятся ведущие поставщики программно-аппаратных средств, наперебой предлагая каждый свое «лекарство». В последнее время в качестве решения наиболее типичных задач многие производители ПО рассматривают подходы и методы, основанные на использовании сервис-ориентированной архитектуры (англ. SOA — service-oriented architecture). Еще одна «панацея»? Разберемся вначале, от каких болезней эта «панацея» должна вылечить.

С чистого листа

Глеб Ладыженский, директор по технологиям Oracle СНГ, считает, что причины, которые привели к возникновению новой парадигмы, — это высокая динамика бизнеса и повышенные требования к адаптивности информационных систем в связи с этой динамикой. «Сейчас уже недостаточно того, чтобы информационная система компании обеспечивала простую автоматизацию информационных и расчетных задач, — говорит он. — Необходимо добиться того, чтобы быстро меняющиеся требования бизнеса (которые суть следствия обострения конкуренции) находили адекватное отражение в ИС. Говоря проще, ИС должна меняться столь же быстро, сколь быстро меняются требования бизнеса и бизнес-процессы».

Еще совсем недавно проблемы как бы и не было. Вернее, подстраивать ИТ-инфраструктуру под меняющиеся бизнес-задачи можно было проверенным способом: есть новая задача, — для ее решения закупается новое оборудование или программное обеспечение, а старое, ненужное — на свалку.

— В середине 1990-х годов было много предприятий, способных решать задачи внедрения ИТ практически «с чистого листа», — вспоминает Артем Денисюк, руководитель практики ПО Sun Microsystems в регионе СНГ. — Не обязательно это были только новые компании — и ветераны могли позволить себе полную замену старой ИТ-инфраструктуры.

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

— По мере стремительного роста количества автоматизированных информационных систем и повышения их вклада в бизнес, компании вынуждены внедрять все более сложные программные архитектуры, — говорит Леонид Алтухов, директор по продажам программного обеспечения IBM EE/A. — Индустрия ПО прошла через множество архитектурных решений, стремясь реализовать полностью распределенную обработку информации. Традиционные подходы уже достигли предела своих возможностей, но от подразделений ИТ продолжают требовать все более быстрого реагирования на новые запросы бизнеса, снижения стоимости ИТ-решений и прозрачной интеграции с новыми партнерами и заказчиками. Сервис-ориентированная архитектура помогает подразделениям ИТ достойно встретить возникающие задачи, являясь следующим эволюционным шагом в истории ИТ.

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

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

Для служебного использования

Глеба Ладыженского разница в дефинициях, даваемых термину SOA, не удивляет. «Разумеется, формулируя свое собственное определение, каждая компания фокусирует внимание именно на тех аспектах SOA, которые значимы для ее бизнеса», — считает он.

По мнению Ладыженского, для полного понимания парадигмы SOA необходимо обратиться к мнению инженерного сообщества. В качестве подтверждения он приводит формулировку, данную доктором Хао Хэ из рабочей группы по архитектуре веб-сервисов консорциума W3C (W3C Web Services Architecture Working Group): «Сервис-ориентированная архитектура есть архитектурный стиль [построения информационных систем], главная идея которого заключается в достижении слабой связанности между взаимодействующими программными агентами. Сервис есть единица работы, выполненная поставщиком сервиса для достижения конечного результата, необходимого потребителю сервиса».

— В этом определении отлично отражена суть SOA, — говорит Глеб Ладыженский. — Ведь парадигма SOA вовсе не сводится к формуле «программное обеспечение как сервис». Особенности русского языка таковы, что английский термин «service» переводится на русский язык и как «сервис», и как «услуга». В этой двойной трактовке кроется суть непонимания всей парадигмы SOA. Ведь SOA не имеет никакого (или почти никакого) отношения к другой популярной ныне парадигме — SaaS (software as a service). Если речь идет о программном сервисе — да, конечно, «программное обеспечение как сервис» (а лучше сказать — «программное обеспечение в виде сервисов») отражает, но отнюдь не исчерпывает парадигму SOA.

На службе бизнеса

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

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

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

— Разумеется, попутно, при реализации данного подхода, отделы информационных технологий решают некоторые важные задачи, — комментирует Глеб Ладыженский. — Например, они добиваются унификации («выравнивания») программных интерфейсов корпоративных бизнес-приложений.

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

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

— Переход на SOA открывает возможность для реализации распределенных решений, полностью соответствующих требованиям инфраструктуры бизнеса, — говорит Леонид Алтухов. — Распределенность информационных систем отражает реальные свойства бизнеса. Практически все предприятия состоят из отдельных подразделений, или, как их теперь принято называть, направлений бизнеса (line-of-business, LOB). Они представляют собой островки активности, деятельность которых нужно собирать воедино, чтобы обеспечить целостность бизнеса. LOB в системном смысле являются слабосвязанными, именно поэтому попытки построить распределенные информационные системы на принципах жесткой связанности, как это делалось до появления SOA, в подавляющем большинстве случаев оканчивались неудачей.

Сервисный инструментарий

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

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

По мнению Денисюка, основные компоненты SOA — это:

• платформа для интеграции — основной компонент, или шина сервисов предприятия (ESB), позволяющая взаимодействовать c веб-сервисами, осуществлять проектирование и развертывание композитных приложений, имеющая репозиторий для хранения сервисов, созданных проектов, объектов и т. д. с целью их повторного использования;
• адаптеры к внешним системам, позволяющие интеграционной платформе взаимодействовать с внешними системами, корректно воспринимать данные от них (учитывая сущность, форматы, семантику, способ взаимодействия) и конвертировать эти данные в форматы, принятые для обмена внутри платформы/шины;
• система передачи сообщений, гарантирующая успешную и своевременную передачу поверх коммуникационного протокола, а также поддерживающая различные механизмы взаимодействия, такие, как polling, listener, publish-subscribe.

Артем Денисюк отмечает, что далеко не все производители могут предоставить полный набор компонентов, чтобы решить различные задачи, возникающие на предприятии, а Глеб Ладыженский добавляет, что технологический инструментарий SOA пока еще находится в стадии формирования. Однако, по словам Ладыженского, имеется несколько уже устоявшихся зрелых компонентов программной инфраструктуры SOA, которые нашли свое удачное воплощение в программных продуктах лидеров отрасли.

— Прежде всего, речь идет об исполнителе бизнес-процессов, формализованных с использованием специального языка BPEL, — говорит он. — В терминологии Oracle этот исполнитель носит название Oracle BPEL Process Manager. Второй, не менее важный компонент, — корпоративная шина сервисов (Enterprise Service Bus), в арсенале Oracle имеется соответствующий программный продукт Oracle Enterprise Service Bus. Для исполнения бизнес-правил, которые целесообразно вынести «за скобки» бизнес-процессов для более простой их модификации, применяется программный продукт Oracle Business Rules. Далее задача управления, мониторинга и обеспечения безопасности веб-сервисов решается применением программного продукта Oracle Web Services Manager. Наконец, движение в сторону сервис-ориентированной архитектуры, управляемой событиями, реализовано в компоненте мониторинга бизнес-активности (BAM — Business Activity Monitoring). Этот компонент (в данном случае Oracle Business Activity Monitoring) позволяет расставлять в значимых точках информационной системы (и в бизнес-процессах в том числе) специальные программные датчики, которые по заранее определенным событиям собирают данные, ассоциированные с этими событиями, агрегируют их и доставляют линейным менеджерам на специальные информационные доски (dashboards).

Сервис на выбор

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

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

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

— Каждый из поставщиков стремится сделать свою платформу доминирующей у большинства заказчиков — таковы жестокие законы рынка информационных технологий, — констатирует Глеб Ладыженский. — Однако на практике ни одному из игроков не удается достичь тотального доминирования.

Есть в этом и положительная сторона: зачем «класть яйца в одну корзину» и становиться заложником решений единственного производителя? Вот только как далеко стоит идти, выстраивая мозаичную систему, состоящую из разных решений?

Артем Денисюк подчеркивает, что существуют определенные границы, за которые не стоит заходить. К примеру, не следует использовать различные системные шины. «Средства управления, используемые в одной сервисной шине, не будут отслеживать бизнес-процесс, затрагивающий сервисы другой шины, — объясняет он. — То есть сквозное решение не будет реализовано, и сам принцип SOA как объединяющей архитектуры в этом случае ставится под вопрос. Тем не менее, например, серверы приложений, как правило, — это предмет выбора».

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

— Каждая такая экосистема формируется из компонентов платформы конкретного поставщика, — подчеркивает Ладыженский. — Обычно в качестве ядра экосистемы выступает лидирующий, особо значимый компонент платформы. Так, экосистема Oracle чаще всего формируется либо вокруг СУБД Oracle, либо вокруг интегрированного набора приложений Oracle E-Business Suite, экосистема IBM — вокруг IBM WebSphere, экосистема Microsoft — вокруг операционных систем Microsoft, экосистема SAP — вокруг MySAP Business Suite.

Необходимость взаимодействия между разными экосистемами привела к возникновению продуктов, способных работать с представителями других экосистем. В качестве примера Глеб Ладыженский приводит программный продукт Oracle BPEL Process Manager:

— Этот продукт с успехом исполняется не только на платформе Oracle Application Server, но также и на платформе IBM WebSphere, BEA WebLogic и JBoss. Так что предпосылки к построению целостной программной инфраструктуры с использованием компонентов различных поставщиков, безусловно, имеются, однако само создание такой инфраструктуры представляет собой сложнейшую инженерную задачу.

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

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