В мире сегодняшних корпоративных ИТ наиболее часто употребляемый термин, безусловно, – это «сервис-ориентированная архитектура» (service-oriented architecture, SOA). Скорее всего, секрет фантастической популярности SOA состоит в том, что впервые за 60-летнюю компьютерную историю появились предпосылки для вполне естественной «встречи» практики бизнеса с информационными технологиями.

Между бизнесом и поддерживающими его информационными технологиями всегда существовал разрыв, а системы автоматизации бизнеса принципиально отличались от встроенных автоматизированных систем. Удавалось автоматизировать лишь отдельные функции предприятия. Все началось с рутинных операций, подобных бухгалтерским, потом появились приложения MRP, ERP, CRM, SCM и т.п. Когда приложений стало очень много, стала очевидной необходимость интеграции приложений. Но для лиц, принимавших бизнес-решения, компьютеры оставались предметами декора кабинетов.

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

Утешая потребителей, поставщики компьютеров выдвигали утверждения вроде закона Гроша, который гласит, что их производительность растет пропорционально квадратному корню стоимости. Однако нарастающая потребность программного обеспечения сюедала дешевую мощность, и компьютеры практически не дешевели. Тогда представители ИТ-отрасли сосредоточили внимание на таком неочевидном с точки зрения оценки экономической эффективности показателе, как общая стоимость владения (total Cost of Ownership, TCO).

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

Тяжелейший удар по имиджу корпоративных ИТ нанес Николас Карр – сначала знаменитой статьей в Harvard Business Review, затем книгой «Дело ли в ИТ? Информационные технологии и разрушение корпоративных преимуществ», и наконец статьей «Конец корпоративных компьютерных систем». Если на волне подюема экономики критические высказывания Соллоу и Страссмана можно было «не заметить», то в период кризиса удар Карра оказался весьма чувствительным. Индустрия начала искать ответные «удары», и одним из них (возможно, самым существенным) стала инициатива SOA. Как и многие другие концепции в компьютерном мире, она начала формироваться на эмпирическом уровне, и лишь теперь получает адекватное обоснование.

Чтобы лучше понять происходящее в корпоративных информационных системах, зададимся вопросом: почему никто не задумывается об эффектности применения компьютеров в управляющих системах? Ответ лежит на поверхности: качество работы и функциональность подобного оборудования находятся в прямой зависимости от используемых компьютерных технологий. В бизнесе органичное включение компьютеров в контур управления намного сложнее встроенных систем. Решаемые задачи можно сравнить, уподобив встроенную систему компилятору с искусственного языка программирования, а систему управления бизнесом – автоматическому переводчику с естественного языка. Природа бизнеса гораздо сложнее природы любой инженерной системы.

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

По причине многоголосья высказываний о SOA наибольший интерес представляют не описания отдельных технологий, так или иначе укладывающихся в представления о сервисах, а попытки обобщить происходящее. В этом отношении показательна статья адмирала Джеймса Мак-Артура, который руководит созданием сетевого командования Военно-морских сил США. Статья опубликована в декабре 2005 года в журнале Signal, посвященном разработке систем вооружения для флота (www.afcea.org/signal/articles/anmviewer.asp?a=1067&z=169). Вообще же, судя по публикациям, SOA находится в центре внимания экспертов Пентагона. В частности, о своем намерении использовать ее заявили Командование транспортными операциями и Агентство по оборонным информационным системам Министерства обороны США.

Адмирал о SOA и EDA

Суждения адмирала достаточно поверхностны, чего и следовало ожидать от военного высокого ранга. Однако они позволяются понять, как высшее военное командование воспринимает перемены в области интеграции приложений. Даже в Пентагоне осознание значимости SOA вышло за стены кабинетов технических специалистов: оно становится базисом весьма значительных оборонных проектов. В армии США реализуются несколько крупных инициатив разработки нового поколения информационных систем, построенных на принципах SAO. Министерство обороны США считает, что Web-сервисы и SOA позволят создать приложения и системы, способные адаптироваться к изменяющимся требованиям военного руководства.

Адмирал считает главной чертой этого подхода отказ от традиционной среды, которая состоит из сильно связанных компонентов и содержит все необходимое; ее центром являются приложения. Вместо нее предлагается применять слабо связанную среду, в которой гранулированные приложения потребляют функциональность и данные как сервисы. Слабая связанность позволяет сохранить целостность процессов в том случае, когда связи между ними нарушаются. Это критически важно именно для военных. Можно провести аналогию с переходом от коммутируемых каналов к коммутации пакетов, который привел к появлению Internet. Реализация SOA потребует разработки таких приложений, которые смогут потреблять сервисы, предоставлять их или выполнять и то, и другое.

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

Следующим по важности подходом Мак-Артур считает архитектуру, движимую событиями (Event-Driven Architecture, EDA). В ее основе – новые решения в области программного обеспечения промежуточного слоя, технологии «посредничества» и обмена сообщениями, реализация моделей публикации/подписки на генерируемые контентом события. Асинхронность таких интеграционных решений весьма предпочтительна для оборонных систем.

По мнению Мак-Артура, для строительства EDA достаточно создать работающую модель публикации/подписки, в соответствии с которой одни приложения смогут активировать другие, рассылая сообщения по нескольким пунктам назначения. Приложения должны иметь возможность прослушивания циркулирующих в системе потоков сообщений и выбора из них нужных. Такое решение обычно называют обработкой простых событий, но есть еще и необходимость в обработке сложных событий (Complex Event Processing, CEP).

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

Зрелость SOA

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

Ее главное преимущество состоит в том, что отдельные сервисы, как строительные блоки, могут создаваться независимо друг от друга, а потому многократно использоваться разными приложениями. Существенным является и то, что сервисы различаются по гранулярности: «строительные блоки» могут быть разных размеров. Если сервис является «мелкозернистым» (fine-grained), он обеспечивает выполнение одной работы. Если же он «крупнозернистый» (course-grained), обращение к нему приводит к выполнению нескольких работ. Во многих случаях архитектурные подходы SOA эффективнее традиционных решений в области интеграции приложений предприятия (Enterprise Application Integration, EAI).

Однако не следует переоценивать возможности новой архитектуры, воспринимая ее как волшебное лекарство от всех проблем корпоративных информационных систем. Как в и любой технологии, при работе с данными есть место и для классических монолитных, и для модульных решений. Это относится и серверам (к примеру, модульные лезвийные кластеры пока не могут заменить SMP-серверы), и к системам хранения (там есть место и модульным, и монолитным накопителям – несмотря на активное развитие средств виртуализации), и к средствам интеграции приложений. В частности, если приложения тесно связаны между собой их логикой, если они выполняют большой обюем транзакций, то предпочтительнее не компонентные архитектуры, а монолитные.

Ошибались не только оптимисты, но и скептики, которые на первых порах рассматривали сервисы лишь как еще один механизм вызова, альтернативный удаленному вызову процедур (Remote Procedure Call, RPC). Напомним, принципы RPC разработаны в 1976 году компанией Xerox, а позже реализованы в проекте Courier. Популярность они приобрели вместе с рабочими Unix-станциями Sun Microsystems и Apollo Computer. Возможность вызова удаленных процедур отличала эти рабочих станций от ПК. Позже свои реализации RPC предложили Microsoft (DCOM) и Object Management Group (независимое от платформы решение CORBA). По сути, RPC представляет собой развитие идеи вызова подпрограммы, распространенное на сеть. Отличие от сервисов заключается в том, что после вызова приостанавливается вызывающая процедура. Она ждет от вызываемой процедуры результата ее действия, и в это время на компьютере могут выполняться какие-то другие действия. С точки зрения одного процесса такие процедуры жестко связаны и синхронизированы между собой. В отличие от RPC, сервисная модель позволяет создавать слабосвязанные асинхронные процедуры.

Еще одно заблуждение, характерное для первых лет развития SOA, состояло в гиперболизации роли Web-сервисов, а точнее – протоколов HTTP и SOAP в сочетании с WSDL. Язык описания сервисов Web Services Description Language допускает использование протоколов SOAP, REST, .Net Framework, Enterprise Java Beans (EJB) и Java Messaging Service (JMS). Но несмотря на то, что в названии этого языка фигурирует буква W, он не ориентирован на Web-сервисы. Его ядро свободно от коммуникационных протоколов и данных. В нем описываются операции, обеспечивающие обмен данными посредством сервисов. А над ними выстраиваются оболочки, специфичные для определенных протоколов и форматов данных.

Язык создавали живые люди. Они включили одну из оболочек для SOAP, HTTP и MIME в первую версию описания языка, и это стало источником заблуждений. На самом деле, ничто не мешает построению иных оболочек. Не следует забывать и о том, что помимо SOAP (Simple Object Access Protocol) существует альтернативный способ доступа к сервисам REST (REpresentational State Transfer), и оба они могут сосуществовать в одном архитектурном решении.

В наиболее удачной форме конвергенцию SOA с бизнесом представила группа из нескольких небольших, но авторитетных компаний. Они предложили пятиуровневую модель зрелости SOA (SOA Maturity Model).

Модели зрелости SOA

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

Модель Capability Maturity Model (CMM) и ее модификация Capability Maturity Model Integration (CMMI) хорошо известны. Они созданы Институтом программной инженерии при Университете Карнеги-Меллона в начале 80-х годов и отражают итерационную специфику процесса создания программного обеспечения. Цикл из нескольких статей Кирилла Мильмана и Семена Мильмана [2], посвященных этой теме, опубликован в «Открытых системах» в 2005-2006 годах.

Оставив за скобками детали, можно сказать, что CMMI является пятиуровневой, а скорее – пятиэтапной моделью процесса разработки программного обеспечения. Он начинается не вполне определенными замыслами, а заканчивается оптимизированным результатом. В основном эта модель была принята при разработке встроенных программ для авионики. Раньше других мысль о распространении модели CMMI на SOA возникла в корпорации IBM. Правда, в отличие от оригинала, модель получилась семиуровневой. Труд, где эта модель описана, называется Increase flexibility with the Service Integration Maturity Model (SIMM). Maturity, adoption, and transformation to SOA (www-128.ibm.com/developerworks/webservices/library/ws-soa-simm). Он близок по духу оригинальной модели, поскольку посвящен процессу разработки и внедрения SOA.

Более интересна модель зрелости CMM, разработанная компаниями Sonic Software, AmberPoint, BearingPoint и Systinet (www.ebizq.net/white_papers/6473.html). Сейчас она находится в центре внимания общественности, активно обсуждается в профессиональной прессе. Учитывая, что основная роль в ее создании принадлежит компании Sonic Software, будем для простоты называть ее «моделью Sonic». Интерес к CMM вызван тем, что в ней отражается не столько процесс разработки, сколько корпоративная архитектура SOA в целом.

Рис. 1. Пятиуровневая модель зрелости SOA

Просматривается прямая аналогия между семиуровневой моделью открытых систем OSI и моделью Sonic. На рис. 1 показаны пять уровней модели Sonic: начальные сервисы, архитектурные сервисы, бизнес-сервисы и коллаборативные сервисы, измеряемые бизнес-сервисы, оптимизируемые бизнес-сервисы. Здесь, как и в модели OSI, просматривается восхождение от физического уровня (в данном случае уровня начальных сервисов) к прикладному (уровню оптимизированных бизнес-сервисов). Таким образом, модель Sonic двуедина: она одновременно отражает и зрелось, и структурную специфику SOA. Иначе говоря, создание SOA – это итерационный процесс восхождения снизу вверх с параллельной организацией многоуровневой архитектуры.

С точки зрения процесса создания SOA на предприятии модель Sonic можно представить следующим образом.

  • Уровень 1: изучение и начальная фаза проектирования, принятие проекта. Он должен одновременно соответствовать требованиям будущей функциональности и специфике технологических решений.
  • Уровень 2: детализация архитектурных решений.
  • Уровень 3: установление партнерства между разработчиками и представителями бизнеса, с тем чтобы будущая система SOA соответствовала представлениям последних.
  • Уровень 4: измерение и анализ бизнес-процессов, оценка качества и непрерывная работа в режиме постоянной обратной связи с Уровнем 3, оптимизация бизнес-процессов.
  • Уровень 5: приобретение информационной системой, основанной на SOA, черт, которые свойственны архитектуре, движимой событиями (EDA). Она становится «нервной системой» предприятия, может автоматически реагировать на происходящие события в соответствии заданными правилами и оптимизировать достижение целей бизнеса.

Со структурной точки зрения в модели Sonic то же разбиение на пять уровней можно представить иначе. Здесь при переходе от уровня к уровню архитектура обогащается системообразующими сервисами и функциями, приближающими ее к требованиям бизнеса. Это и есть тот ключевой момент, который обеспечивает преимущество SOA. На нижнем уровне создается практически весь необходимый с точки зрения ИТ функционал, а потом он «обвязывается» сервисами последующих уровней, причем система все больше и больше адаптируется к потребностям бизнеса. Эта обвязка, или создание оболочек, происходит, в сущности, виртуально. Все практические действия сводятся к дополнению сервисами корпоративной сервисной шины (Enterprise Service Bus, ESB), которая образует для них универсальную платформу.

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

  • Уровень 1. Его название, «Начальные сервисы», отражает два обстоятельства. Во-первых, именно с этого уровня начались исследования и разработки, приведшие к созданию SOA. С него же начинаются изучение предмета и первые фазы проектов, основанных на SOA. Во-вторых, этот уровень, как и нижние уровни в модели открытых систем OSI, является «физической» основой для верхних уровней. К данному уровню SOA относятся многие стандарты, предложенные комитетом W3C6, в том числе язык XML (используется для описания форматов сообщений), язык WSDL (описание самих сервисов) и SOAP (описание механизма вызова сервисов). В создании первого уровня участвуют традиционные коллективы разработчиков, а его основу чаще всего составляет корпоративная сервисная шина ESB. Она обеспечивает взаимодействие между компонентами SOA, в том числе Web-сервисами и реляционными базами данных, и масштабируемую распределенную инфраструктуру. Шина ESB допускает использование адаптеров, которые позволяют организовать обмен сообщениями между модулями, реализованными с использованием разных технологий (например, приложениями, написанными в средах Microsoft .Net и J2EE). На этом же уровне создается реестр сервисов на основе стандарта UDDI. И сюда же можно включить средства измерения эффективности работы сервисов и сервисы управления сервисами (Service Level Management Services).
  • Уровень 2. По роли, которую играют архитектурные сервисы этого уровня, их можно уподобить средствам системной интеграции. Они обеспечивают надежный обмен сообщениями между приложениями, выполняя посредническую миссию, организуют обмен с базами данных, проверку функционирования, внутреннюю безопасность и измерение производительности. С их помощью SOA распространяется на всю организацию, и начинается ее жизненный цикл (в том числе ее изучение и освоение персоналом, наращивание функциональности посредством «накопительной», или инкрементальной, интеграции и др.). На данном уровне могут добавляться сервисы репозитория политик, сервисы обработки исключительных ситуаций (служат для обнаружения и исправления ошибок), сервисы аутентификации и авторизации пользователей.
  • Уровень 3. Закладываются основы взаимодействия между технологиями и бизнесом, устанавливается соответствие между бизнес-процессами и цифровыми процессами обработки данных. Модель Sonic дополняется еще двумя видами сервисов. Во-первых, это бизнес-сервисы, обеспечивающие управление бизнес-процессами (Business Process Management, BPM); их можно назвать и «сервисами оркестровки» (Orchestration Services). Во-вторых, сервисы, поддерживающие взаимодействие с партнерами, или «коллаборационные сервисы» (Collaborative Services). На этом уровне реализуется одно из важнейших преимуществ модульной архитектуры SOA: при использовании бизнес-сервисов можно собрать нужный бизнес-процесс из готовых функциональных сервисов.
  • Уровень 4. В отличие от сервисов предыдущего уровня, в основном предназначенных для реализации внутренних и внешних бизнес-процессов, сервисы данного уровня служат для установления непрерывной обратной связи с внешней средой. Это позволяет оценивать производительность бизнеса и влияние внешних факторов. Здесь могут появиться сервисы обработки сложных потоков событий в режиме реального времени (Real-time Event Stream Processing Services). Примерами таких потоков являются сведения, которые поступают от устройств, считывающих данные меток радиочастотной идентификации. Вторую группу составляют сервисы мониторинга активности бизнеса (Business Activity Monitoring, BAM). Задача заключается в сборе и анализе данных, поступающих в режиме реального времени, а затем в соотнесении их с желаемыми характеристиками бизнес-процессов. В итоге должна повыситься скорость реакции бизнес-систем на изменения во внешней среде – вплоть до появления возможности работать в режиме реального времени.
  • Уровень 5. Его составляют сервисы оптимизации бизнес-процессов (Optimized Business Services). Их внедрение позволит создавать системы, реализующие самокорректирующиеся бизнес-процессы.

Властвование над SOA

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

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

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

Основным инструментом властвования над SOA может служить интегрированный реестр/репозиторий сервисов. Он позволяет оперировать сервисами, поскольку в нем описываются все доступные сервисы и средства их идентификации (артефакты), в том числе описания на WSDL, нормативные документы, планы тестирования и т.д. Этот реестр/репозиторий позволяет представить сервисы в форме, удобной для управления ими, то есть образует систему записей о сервисах с момента их создания и до текущего момента.

С точки зрения теории управления организация SOA governance достаточно банальна и состоит из четырех этапов:

  • процесс (process), то есть запуск системы в эксплуатацию и наблюдение за ее поведением;
  • оценка (measurement), обнаружение критических точек, «узких мест», нарушений политик безопасности и т.д.;
  • изменение руководящих принципов (enforcement), на которые система должна динамически реагировать;
  • обратная связь (feedback), которая позволяет оценивать внесенные изменения и корректировать их.

***

Развитие SOA вступает в весьма интересную фазу. Все крупные производители (прежде всего, компании IBM, Microsoft, Oracle, SAP, Fujitsu вместе с Software AG, BEA Systems и Tibco) и множество небольших компаний избрали данную архитектуру в качестве основного направления развития своих программных систем. Но не следует ожидать быстрых результатов: SOA– уже реальность, но не большая, чем прототип автомобиля на автосалоне. А проблем на этом пути ожидает не меньше, чем при создании электронной коммерции. Для появления полноценных решений потребуется не менее десяти лет, причем SOA начнут работать лишь в тех организациях, которые действительно стремятся к управляемости и хотят построить систему управления, встроенную в бизнес-контекст. Учитывая это, а также то, что основные вопросы стандартизации еще не решены, уже сегодня стоит проводить стратегическую подготовку к миграции на SOA. Следует отказаться от сильно связанных приложений и осваивать идеологию и практику слабо связанных.

Литература
  1. Леонид Черняк, SOA – шаг за горизонт // «Открытые системы», 2003, б№ 9.
  2. Кирилл Мильман, Семен Мильман // CMMI – шаг в будущее. «Открытые системы», 2005, б№ 5-6, 7-8, б№ 9, 2006, б№ 1, б№ 2, б№3.