КОНЦЕПЦИИ

Ясность появляется, но вопросов становится еще больше

Ровно год назад в нашем еженедельнике был опубликован обзор "ИТ-рынок глазами системных интеграторов" (PC Week/RE, N 47/2005, с. 39). Среди прочих ведущим российским интеграторам был задан и такой вопрос: "Что вы думаете о концепции SOA?" Из семи экспертов лишь трое захотели что-то сказать по этому поводу. Сами же ответы хорошо отразили спектр мнений по теме на тот момент: от "SOA не является чем-то принципиально новым" до "SOA - руководство в выборе оптимального с точки зрения стоимости и функционала решения". Однако самым реалистичным мне показался вот такой ответ: "По этому вопросу необходима серьезная дискуссия, поскольку SOA предполагает пересмотр подходов к созданию систем. 2006 г. может лишь подвести теоретическую базу под дальнейшие стратегии их развития".

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

Говоря о подвижках в обсуждениях SOA, хотелось бы, в частности, выделить прошедшие в конце осени конференции IBM и Sun по этой теме, следствием которых стали сразу несколько публикаций в PC Week/RE (N 44/2006, с. 10, , и ). И тут хотелось бы обратить внимание на любопытную деталь: две из этих статей (с. 10 и 23) готовились разными авторами по различным событиям и независимо друг от друга, но их названия при этом оказались практически одинаковыми: "SOA: ...от концепции к реализации". Такое совпадение, конечно, не случайно - оно отражает насущную потребность ИТ-сообщества перейти от теории к практике.

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

Действительно, в одной из упомянутых статей ("SOA и Sun: от концепции к практической реализации") приведена наглядная графическая схема архитектуры SOA и даны соответствующие пояснения к ней. Как цель при построении конкретной информационной системы - такой подход выглядит весьма привлекательно, с точки зрения бизнес-заказчиков и ИТ-служб. Но насколько реально достижение этой цели? Какие подводные камни и явные препятствия нужно преодолеть на данном пути?

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

SOA как разработка композитных приложений

В своем обзоре "Рынок средств разработки в 2006 году" (PC Week/RE, N 46/2006, c. 32) я уже отмечал, что один из возможных путей реализации SOA - это создание составных или композитных приложений; его предлагают многие ИТ-компании, в том числе те же IBM и Sun. Идея проста: решать новые бизнес-задачи не путем покупки или разработки специализированного ПО, а с помощью максимального использования существующего функционала (как самого предприятия, так и внешних сервисов). Иными словами, поставленная задача решается путем интеграции различных уже имеющихся вычислительных и информационных ресурсов, а также создания необходимой специфической бизнес-логики и пользовательского интерфейса.

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

Давайте посмотрим на типичную задачу: продажа автомобиля в кредит (ПАК). Традиционно она решается таким образом. Чтобы обеспечить гибкость работы с клиентами, нужно создать три типа рабочих мест (рис. 1): "планирование услуг" (ПУ), "оформление заказа" (ОЗ) и "оплата счетов" (ОП). Для каждого из них разрабатывается (или используется готовое, с соответствующими настройками) отдельное функциональное приложение; при этом получается так, что любое из них содержит ряд функций, имеющихся в каком-то другом. Информационное взаимодействие этих программ происходит через использование единых баз данных.

Рис. 1. Взаимодействие “монолитных” приложений в их традиционной схеме базируется на

 использовании общих репозиториев данных (здесь выделены дублирующие операции

в каждом приложении)

Далее их нужно увязать в цепочку конкретного бизнес-процесса ПАК. Он не сводится к простой структуре типа ПУ - ОЗ - УП, а представляет собой более сложный граф (с ветвлениями, условными и безусловными переходами, параллельными ветвями), в каждом узле которого выполняется какая-то элементарная операция одного из рабочих мест. В результате получается, что для автоматизации задач ПАК мы создали новое бизнес-приложение (систему) и состоит оно из трех функциональных приложений, объединенных бизнес-логикой взаимодействия, возможно, выраженной просто в виде письменной должностной инструкции.

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

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

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

- "точка - точка". Такую модель довольно легко реализовать, но трудно поддерживать и модифицировать. Это вполне понятно - с увеличением числа компонентов (N) количество взаимосвязей возрастает в квадратичной зависимости: N х (N - 1)/2;

- взаимодействие через брокер сообщений;

- SOA - сервисная шина предприятий.

Рис. 2. Эволюция интеграционных моделей (слева направо): а) “точка - точка”;

 б) через брокер сообщений; в) SOA: сервисная шина предприятия

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

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

Рис. 3. Внутренняя организация композитного SOA-приложения

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

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

Рис. 4. Структура решения “продажа автомобиля в кредит”,

реализованного в варианте композитного приложения

Путь к SOA совсем не так прост

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

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

Вспомним: один из ключевых принципов SOА - компонентный подход. Но давайте посмотрим на очень простой прототип SOA, реализованный на клиентском ПК, - операционную систему Windows. Все присущее SOA-схеме там имеется: компоненты, репозиторий, унифицированные протоколы и пр. Причем все они от одного поставщика или находятся под его жестким контролем. Откуда же тогда появился DLL Hell ("кошмар DLL")*1, который Microsoft официально признала еще несколько лет назад, предложив в качестве решения проблемы реализованный в .NET подход создания полных сборок для каждого приложения в отдельности (что означает отказ от идеи повторного использования компонентов).

_____

*1 DLL Hell - проблема возникновения несовместимости компонентов ОС в результате их модернизации и обновления.

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

Что же будет, если мы реализуем подобную модель на уровне распределенной гетерогенной среды с компонентами от разных поставщиков? Здесь в отличие от DLL Hell речь будет идти не о "падении" отдельного ПК и простое отдельного пользователя, а о нарушении деятельности предприятия в целом! Не нужно забывать о том, что в случае SOA мы имеем дело не просто с распределенной системой, а с системой, использующей внешние компоненты, которыми распоряжаются совсем другие хозяева. Как будет чувствовать себя компания, когда в приложении контрагента что-то поменяется, после чего нарушится созданный вместе с ним интерфейс и весь бизнес-процесс не будет выполняться?

Да, за последние годы ИТ-отрасль добилась больших успехов в области стандартов, например Web Services *1, но в какой степени удастся сохранить их целостность и заставить всех пользоваться ими?*2

_____

*1 Довольно часто можно встретить утверждения о том, что реализация SOA сводится исключительно к использованию Web-сервисов. Однако это представляется конечно же неправильным, поскольку такой подход заведомо сужает возможности данной концепции. Речь идет об использовании широкого спектра протоколов взаимодействия программных компонентов.

*2  Интересные соображения на этот счет приведены в PC Week/RE, N 44/2006, с. 25.

Однако совместимостью компонентов круг проблем по SOA не ограничивается. Вот еще пара актуальных вопросов: как будет обеспечиваться безопасность системы и что будет с производительностью в целом (компонентная модель работает медленнее, чем монолитная)?

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

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

SOA как естественное развитие ИТ

Одна из проблем при обсуждении вопросов SOA заключается в том, что какого-то точного определения SOA просто не существует (сошлюсь на мнение специалистов IBM и Sun - см. PC Week/RE, N 44/2006, с.10 и ). Естественно, что каждый ИТ-вендор вкладывает в этот термин собственное понимание вопроса в соответствии со своим личным позиционированием на рынке.

Но все встает на свои места, если SOA воспринимать именно как концепцию, как некоторую идеальную модель организации современных сложных ИС, которая, возможно, недостижима в жизни, но к которой нужно тем не менее стремиться.

Действительно, COM, XML, Web Services и пр. - это примеры стандартов, имеющих четкие утвержденные спецификации. Есть определение ERP, хотя, как отметила вице-президент подразделения IBM SOA & Middleware Services Мари Век, тут можно даже не заниматься формулировкой десятка ключевых признаков, а лишь указать на некий эталонный продукт (SAP R/3) и пояснить - вот это и есть образец ERP-решения. Довольно легко можно сказать, что такое клиент-серверная архитектура, ПО промежуточного слоя, OC... А что же такое SOA?

Отвечая на этот вопрос, нужно понять основные тенденции развития ИТ-рынка, на которые следует посмотреть с двух сторон.

Заказчик

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

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

ИТ-службы

 

     Проблема: сложность ИС растет, теряется управляемость процессами, каждый шаг в развитии становится все более тяжелым. Подавляющая часть ИТ-бюджета (от 70 до 90%) идет на поддержку нынешних систем и лишь оставшаяся - на внедрение чего-то нового для развития бизнеса. Нужно, чтобы все было наоборот.

Задача: необходимо предпринять какие-то шаги на уровне принципиально новых архитектурных решений и организационных подходов.

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

Еще в середине 1990-х было много предприятий, способных решать задачи внедрения ИТ практически "с чистого листа". Не обязательно это были только новые компании - и ветераны могли позволить себе полную замену старой ИТ-инфраструктуры, поскольку в общем объеме бизнеса она занимала не очень много места. Сегодня такое уже невозможно: нужно учитывать сделанные инвестиции, использовать существующие активы. Кроме того, при автоматизации должны быть учтены изменения требований пользователя в плане функций и оперативности решения задач, а также новые достижения ИТ, в частности повышение пропускной способности сети, появление мобильных клиентских устройств и т. д. Приложения сегодня должны работать в режиме реального времени в условиях географической распределенности, обеспечивать процессную модель управления компанией и пр. И все это - за разумные деньги!

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

Я бы предложил в качестве такого универсального верификатора следующую систему оценок.

- Информационная система предприятия. Оцените соотношение затрат на поддержку действующих и внедрение новых функций. Если 90/10 - это точно не SOA, если 10/90 - это точно SOA.

- Новый ИТ-проект. Оцените соотношение использования в нем новых программных компонентов (специально разработанных, купленных) и уже применяемых ранее в организации.

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

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

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

Версия для печати