Практическое построение SOA: борьба с мифами

ПЕРЕДОВЫЕ ТЕХНОЛОГИИ

Анализ различных дискуссий об архитектуре SOA (Service-Oriented Architecture)*1 и бесед с клиентами показывает, что у большинства ИТ-специалистов существует неправильное ее восприятие. Для них SOA, Web-сервисы, а часто и технологии Enterprise Services Bus (ESB) и Business Process Management (BPM) - почти синонимы. Симптомом подобной путаницы являются вопросы: "А что нового это дает относительно обычного RPC?" (Remote Procedure Calls) или "А чем это отличается от CORBA?", т. е. спрашивающий воспринимает SOA как некоторую программную технологию, а не как модель архитектуры и методы организации работ. Поэтому мне кажется правильным еще раз прояснить некоторые базовые идеи SOA и развеять сопутствующие ей мифы.

_____

*1 Многомесячная дискуссия на эту тему состоялась, например, недавно на форуме ИТ-блогз (http://itblogs.ru).

Определение

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

Иными словами - это набор некоторых организационных мероприятий, направленных на упорядочивание накопившихся в компании программных систем и создание основы для их непротиворечивого развития. Концепция эта возникла не на пустом месте: многие корпорации накапливали ПО десятки лет и в них действует 5-10 разных поколений систем, которые требуется как-то развивать и согласовывать между собой.

Упоминание термина SOA можно встретить уже в середине 1990-х гг. в отчетах компании Gartner. Тогда эти идеи в практической плоскости соотносились с компонентными технологиями, в первую очередь с CORBA. С той поры спектр SOA-подходов заметно расширился за счет удачного и неудачного опыта внедрений и вырос в некоторый набор эвристических приемов разработки архитектуры и управления жизненным циклом ИС, которые в совокупности носят теперь название SOA Governance. Когда появились XML и стек протоколов WS-I, оказалось, что эти технологии упрощают развертывание данной архитектуры, и о них стали говорить в контексте SOA.

Ключевое место в SOA, однако, принадлежит не технологиям, а людям, созданию и утверждению внутрикорпоративных стандартов на разработку и архитектуру. Можно построить в организации массу Web-сервисов и не внедрить у себя в итоге SOA (об этом, кстати, часто говорят), а можно не внедрить ни одного Web-сервиса, а SOA все же построить (о чем вспоминают гораздо реже).

Техническая архитектура SOA

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

Сервисы отличаются от обычных объектных компонентов CORBA и EJB тем, что они не только ориентированы на обслуживание запросов на действия, но и, как правило, скрывают за собой крупные и логически изолированные (законченные) блоки делового функционала.

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

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

_____

*1 Для полноты картины имеет смысл упомянуть о существовании и других типов сервисов. Выделяют, например, технологические сервисы - адаптеры, сервисы трансформации данных, сервисы авторизации и т. п.

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

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

Это описание совсем не обязательно должно быть в формате WSDL (Web Service Definition Language). Известны успешные SOA-проекты (скажем, в Deutsche Post), где стандартом был язык CORBA IDL. Описание может быть сделано на UML или даже в MS Word. Главное, чтобы оно было. Конечно, если описание выполнено в структурированном машинном формате, то использовать сервис потом намного удобнее, а вся ИТ-инфраструктура становится гибче.

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

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

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

Клиенты сервисов. Главными клиентами сервисов являются так называемые фронт-энды, в первую очередь клиентские приложения разного сорта. В последние годы - это все больше приложения, функционирующие на Java-серверах приложений или на IIS/.Net. Фронт-энд должен знать и исполнять контракт, которому удовлетворяет вызываемый сервис. Забота об этом лежит на разработчике фронт-энда. Если фронт-энд не может выполнить контракт сервиса, то сервис не должен его обслуживать.

Но к обычным сервисам могут обращаться и высокоуровневые сервисы. Типичным примером является программа, оформленная как сервис делового процесса. Обычно подобные сервисы строят при помощи инструментов BPM (Business Process Management), но ни сами высокоуровневые сервисы, ни указанные инструменты не являются необходимыми для внедрения SOA.

Шина. Что же касается технологических средств для реализации сервисов, то их на предприятии может быть много - Web-сервисы, Java, .Net, CORBA. Более того, идея SOA как раз и состоит в том, чтобы обезопасить ИТ-инфраструктуру от смены поколений информационных технологий и стыковать плохо совместимые унаследованные технологии. Скажем, идеологи SOA открыто говорят, что протокол SOAP когда-то отомрет, а сама архитектура будет жить и дальше.

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

Например, если на одном конце шины находится фронт-энд, работающий с SOAP, а на другом - сервис, реализованный на CORBA, то шина может обеспечить преобразование формата вызова, отображая поля, содержащие названия методов в XML-документе, на методы объекта CORBA. Это теоретически возможно, так как SOA предполагает наличие нейтрального к технологиям описания сервиса.

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

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

Заметим, что шина не обязана отвечать за преобразование бизнес-семантики сообщений, она ответственна только за технологическую стыковку. Так, шина не должна сама преобразовывать запись о клиенте из бизнес-формата SAP R/3 в бизнес-формат Oracle Applications. Это - задача адаптеров или же сервисов трансформации, за вызов которых отвечает клиент сервиса. Предприятие, конечно, может "стандартизовать" для сервисов ту или иную семантику - это полностью его выбор.

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

Типовые проблемы

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

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

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

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

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

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

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

Кому нужна SOA?

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

Другие заказчики тоже смогут извлечь пользу из SOA, но косвенным образом - после того как основные пакетные приложения будут декомпозированы силами вендоров, предприятия смогут активнее развертывать средства мониторинга бизнес-активности и управления композитными процессами (BAM, BPM)*1.

_____

*1 На сегодня главные вендоры еще не декомпозировали свои продукты. SAP обещает выпустить подобную версию своей ERP-системы в 2007 г., Oracle - в 2008-м.

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

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

_____

*1 В нестабильных бизнес-ситуациях (слияния, вывод кардинально нового продукта на рынок) тактика реализации SOA может быть другой.

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

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

Автор - руководитель группы КОННАСИ, занимающейся исследованиями рынков программных систем и консалтинговым сопровождением проектов. С ним можно связаться по адресу: vlad.borkus@konnasi.ru.