Реализация SOA как разработка композитных приложений
Термин SOA (Service Oriented Architecture, сервис-ориентированная архитектура), имевший еще недавно ореол загадочно-нового, за прошедший 2006-й год стал привычным и узнаваемым. И все же, при том что использование этой концепции приобрело повседневный характер, уровень понимания ее сути в ИТ-сообществе за прошедший год вряд ли сильно повысился. Тема SOA регулярно затрагивалась в презентациях вендоров, ей были посвящены даже специальные технические мероприятия, однако пока доводы поставщиков в пользу применения этих идей сводятся лишь к декларациям о повышении эффективности затрат заказчиков на ИТ.
В результате сегодня наиболее популярными в среде ИТ-специалистов, наверное, можно считать две полярные точки зрения. Первая: SOA — это нечто принципиально новое, что качественно улучшит жизнь заказчиков и решит все их проблемы, связанные с ИТ. Вторая: это все маркетинговые штучки, просто игра в новые слова, а по сути ничего принципиально нового здесь нет. Первая из этих позиций обычно главенствует на тех самых презентациях и в официальных интервью, вторая чаще встречается в обсуждениях в Интернет-форумах и в кулуарных разговорах. На самом же деле истина, как обычно, лежит где-то посередине.
Безусловно, в дискуссиях вокруг SOA (как, впрочем, и вокруг любого другого новшества в сфере ИТ) очень сильны маркетинговые моменты. Поставщики придумывают новые названия, следуя известному принципу маркетинга: “звучные” рыночные слова должны меняться каждые три года. А если технологии не успевают меняться с такой скоростью — тем хуже для технологий!
В то же время технологии, концепции, рыночная ситуация, конечно, постоянно изменяются, и терминологические новшества в той или иной мере действительно отражают их изменения. Но в чем состоят эти изменения? И в чем новизна той же самой SOA, если отбросить общие разговоры о стремлении ИТ-компаний улучшить жизнь потребителям?
Скорее всего, мы только сейчас подходим к моменту серьезного критического обсуждения концепции SOA и методов ее реализации. Некоторые подвижки в этом направлении наметились как раз минувшей осенью, в том числе на конференциях по этой тематике, проведенных в Москве компаниями IBM и Sun. Это вселяет надежду на то, что год 2007-й станет поворотным моментом в процессе продвижения SOA от слов к делу.
Общие соображения
Одна из проблем с концепцией SOA заключается в том, что точного ее определения просто не существует. А раз так, нетрудно догадаться, что каждый ИТ-вендор вкладывает в этот термин собственное понимание вопроса в соответствии со своим позиционированием на рынке.
Но все встает на свои места, если воспринимать SOA просто как концепцию. Более того, я бы предложил такой вариант — это некая идеальная модель организации современных сложных информационных систем, в реальности недостижимая, но к которой нужно тем не менее стремиться.
Действительно, COM, XML, Web Services и т. п. — это примеры стандартов, имеющих четкие утвержденные спецификации. Есть определение ERP, хотя, как отметила вице-президент подразделения IBM SOA & Middleware Services Мари Век, тут можно даже не заниматься формулированием десятка ключевых признаков, а лишь указать на некий эталонный продукт (SAP R3) и сказать — вот это и есть образец ERP-решения.
Довольно легко определить, что такое клиент-серверная архитектура, ПО промежуточного слоя, OC… А что же такое SOA?
Отвечая на этот вопрос, следует посмотреть на основные тенденции развития ИТ-рынка с двух точек зрения — заказчика и ИТ-службы.
Взгляд заказчика
- Проблема: роль ИТ в общем бизнесе компаний возрастает, ИТ становятся решающим фактором повышения эффективности и конкурентоспособности. При этом быстро увеличиваются затраты на ИТ, их нужно если не сокращать, то хотя бы оптимизировать.
- Задача: нужно принять меры для максимальной переориентации ИТ на потребности конкретного бизнеса с учетом быстро меняющихся рыночных условий. Нужно повысить эффективность использования уже накопленных на предприятиях ИТ-ресурсов для решения новых бизнес-задач.
Взгляд ИТ-службы
- Проблема: сложность информационных систем растет, теряется управляемость процессов, каждый шаг в развитии дается все труднее. Подавляющая часть ИТ-бюджета (от 70 до 90%) идет на поддержку нынешних систем, и лишь оставшаяся — на внедрение чего-то нового для развития бизнеса. Нужно, чтобы все было наоборот.
- Задача: нужно предпринять какие-то шаги на уровне применения принципиально новых архитектурных решений и организационных подходов.
Еще несколько лет назад все ведущие ИТ-поставщики стали использовать эффектные названия для характеристики своей рыночной стратегии: “по требованию”, “адаптивное предприятие”, “динамические системы” и т. п. На одной из осенних пресс-конференций представителя такого ИТ-лидера спросили: почему вы в презентации не используете свой звучный слоган (кажется, в данном случае это были “адаптивные вычисления”). “А зачем, — был ответ, — теперь мы поняли, что все подобные различные определения можно заменить двумя стандартными — SOA и ITSM!”
Действительно, если посмотреть внимательнее, станет ясно, что SOA и ITSM (IT Service Management) — это концепции, которые рассматривают обозначенные выше стратегические проблемы развития ИТ с двух сторон: создания и сопровождения современных информационных систем.
Еще в середине 1990-х было много предприятий, способных решать задачи внедрения ИТ практически «с чистого листа». Не обязательно это были новые компании — и ветераны могли позволить себе полную замену старой ИТ-инфраструктуры, поскольку в общем объеме бизнеса она занимала не очень много места. Сегодня такое уже невозможно: нужно принимать во внимание сделанные инвестиции, использовать существующие активы. Кроме того, при автоматизации приходится учитывать изменения требований пользователя в плане функций и оперативности решения задач, а также новые возможности ИТ, в частности повышение пропускной способности сети, появление мобильных клиентских устройств и т. д. Приложения сегодня должны работать в режиме реального времени в условиях географически распределенных систем, обеспечивать процессную модель управления компанией и т. п. И все это — за разумные деньги!
Довольно часто встречается точка зрения, что реализация SOA сводится исключительно к использованию Web-сервисов. Однако это конечно же неправильно, так как такой подход заведомо сужает возможности данной концепции.
В то же время, учитывая концептуальный характер понятия SOA, получается, что всякая дискуссия о том, в какой степени тот или иной продукт, или проект, или конкретная информационная система предприятия соответствует или не соответствует SOA, просто не имеет смысла. Конечно, можно попробовать сформулировать десяток критериев, на основании которых можно проводить такую оценку, но на практике многокритериальные сравнения фактически просто невозможны. Нужны четкие оценки по какому-то одному, легко определяемому критерию.
Я бы предложил в качестве такого универсального параметра следующую систему оценок:
- информационная система предприятия — оцените соотношение затрат на поддержку существующих и на внедрение новых функций. Если оно составляет 90/10 — это точно не SOA, если 10/90 — это точно SOA;
- новый ИТ-проект — оцените, в каком соотношении в нем используются новые (специально разработанные, купленные) и уже применявшиеся ранее в организации программные компоненты;
- прикладной программный пакет — оцените отношение функционала, доступного в виде отдельных компонентов для внешних приложений, к общему числу функций.
Создание SOA-систем
Определив, что концепция SOA связана с созданием информационных систем, было бы логично рассматривать этот процесс как разработку ПО на некотором качественно новом уровне: привычное понятие “разработка приложений” дополняется новым подходом “разработка информационных систем”. Соответственно, если раньше информационная система компании представляла собой набор по существу автономных приложений, привязанных к общей ИТ-инфраструктуре предприятия, то теперь стоит вопрос об их объединении на основе общей бизнес-логики. Получается, что на смену “системным интеграторам” как специалистам по реализации ИТ-проектов должны прийти “разработчики систем”.
Если посмотреть на ключевые идеи SOA — компонентный подход, повторное использование, — то легко видеть, что эти ключевые положения всегда были заложены в основе применения вычислительной техники. Но сегодня с учетом прогресса ИТ в эти понятия вкладывается иное содержание. Сегодняшние приложения отличаются от тех, что были десять лет назад: изменились ИТ-инфраструктура, возможности средств разработки, задачи пользователей. Раньше программист имел дело с компонентами в виде подпрограмм; потом разработчик использовал их в виде многофункциональных объектов. Сейчас речь идет о применении компонентов на уровне тех или иных законченных прикладных задач или операций.
Имея в виду такой подход к реализации проектов, сегодня SOA-системы часто представляют в виде составных, или композитных приложений, принципы реализации которых мы рассмотрим ниже.
От монолитных приложений к композитным
Итак, использование компонентов составляло основу разработки ПО на всем протяжении вот уже более чем полувековой истории современной вычислительной техники. Что же нового тогда в SOA?
Дело в том, что раньше такие компоненты использовались лишь на этапе собственно разработки, а в результате получалось некоторое монолитное приложение, которое было не очень хорошо приспособлено для работы с другими программами. По большому счету задачи интеграции разных приложений выполнялись через своего рода универсальный коннектор — человека, т. е. через пользователя, который решал вопросы преобразования форматов, контроля семантики данных, согласования передачи информации во времени и т. д. Сейчас же нужно обеспечить автоматическое взаимодействие приложений с минимальным участием человека.
Но ведь сегодняшнее бизнес-приложение — совсем не то же самое, что клиентская программа типа текстового процессора. Фактически речь идет о сложных бизнес-системах, решающих целый комплекс задач. Вот типичный пример: продажа автомобиля в кредит (рис. 1). Эту операцию можно представить в виде бизнес-процесса, по ходу которого нужно выполнить целый ряд автономных задач — проверить кредитоспособность клиента, разместить заказ у поставщика или производителя автомобиля, решить вопросы логистики, оформить банковский кредит… Особо подчеркнем, что при этом нужно взаимодействовать с внешними контрагентами.
Рис. 1. Традиционная схема “монолитных” приложений базируется на использовании общих репозиториев данных.
Раньше можно было взять за основу какую-то ERP-систему, но все равно многие внешние операции приходилось выполнять вручную, посылая запросы и ожидая ответов. В результате возникла идея автоматизировать такое взаимодействие. Но тут выясняется, что контрагент может не только быстро представить какие-то данные, но и взять на себя выполнение некоторой законченной бизнес-операции, например, оформление кредита и отслеживание его выплаты. Взглянув на задачу с учетом таких возможностей, мы обнаружим, что нужно только реализовать бизнес-логику, которая объединит готовые средства, в том числе уже имеющиеся в организации, — например, приложение для бухгалтерского учета. Так нужна ли для автоматизации этой работы совсем не дешевая ERP-система, которую все равно придется настраивать, состыковывать и т. д.? Или лучше создать композитное приложение с использованием уже готовых вычислительных и информационных ресурсов?
Для ответов на эти вопросы нужно посмотреть, какие существуют архитектурные подходы для интеграции различных приложений. На рис. 2 представлена эволюция интеграционных моделей. Модель “точка-точка” довольно легко реализовать, но трудно поддерживать и модифицировать. Это вполне понятно: с увеличением числа компонентов количество взаимосвязей возрастает в квадратичной зависимости: N х (N-1)/2. Следом за ней идут модели взаимодействия через брокер сообщений и SOA с сервисной шиной предприятия.
Рис. 2. Эволюция интеграционных моделей: а) “точка-точка”; б) через брокер сообщений; в) SOA: сервисная шина предприятия.
В двух последних случаях число интерфейсов взаимодействия равно N, и на первый взгляд не очень понятно, чем же эти схемы различаются: общение программ выполняется через единый центр. Но принципиальное отличие есть: в одном случае брокер сообщение “подстраивается” под приложения (N интерфейсов), а во втором — наоборот (один интерфейс). Следствие этого — не только упрощение задачи интеграции, но и повышение производительности и масштабируемости композитного решения. На самом же деле схема работы через брокер сообщений больше похожа на вариант “точка-точка” — просто управление интерфейсами находится в одном центре и потому его проще настраивать, хотя, как правило, с заметной потерей производительности в режиме исполнения.
Реализация SOA требует качественно иного подхода к внутренней организации приложения (рис. 3). На верхнем уровне, с точки зрения пользователей, все внешне обстоит так, как будто они работают с традиционными монолитными приложениями, соответствующими производственным задачам. Но на самом деле в данном случае правильнее говорить о ролевой модели, реализованной в рамках одной клиентской платформы и единого пользовательского интерфейса.
Рис. 3. Структурная организация композитного SOA-приложения.
А дальше внутренняя реализация приложения уже довольно существенно отличается от монолитного варианта. Каждая роль должна быть представлена соответствующим бизнес-процессом (или набором бизнес-процессов), которые должны исполняться в виде обращений к отдельным бизнес-сервисам, реализованным в рамках автономных бизнес-приложений. А те, в свою очередь, должны опираться на базовые сервисы, реализованные на уровне ИТ-инфраструктуры (Java, .NET и т. д.). С использованием такого подхода решение описанной выше задачи “продажа автомобиля в кредит” может выглядеть так, как показано на рис. 4.
Рис. 4. Схема решения “продажа автомобиля в кредит” в варианте композитного приложения.
На бумаге идея создания композитных приложений выглядит легкой и изящной, но на самом деле ее реализация совсем не так проста. Ведь монолитные приложения, кроме недостатков, обладают и множеством достоинств: это надежность функционирования, безопасность, высокая производительность…
Главный подводный камень на пути SOA — совместимость компонентов, и очевидный путь преодоления этой проблемы — стандартизация. За последние годы ИТ-индустрия — главным образом усилиями компаний-лидеров — сделала очень многое в этом направлении и прежде всего в сфере Web-сервисов и XML. Но объективно нужно иметь в виду, что стандартизация — это очень непростой и совсем не быстрый процесс. Он проходит через несколько последовательных уровней; представить себе его сложность и длительность можно с помощью модели оценки зрелости стандартов (см. таблицу). Как видно, стандарт проходит два этапа формирования — собственно создание и применение его в реальных условиях. На второй этап нужно обратить особое внимание: если с новыми приложениями в общем все понятно, то внедрение появляющихся стандартов в унаследованное ПО — это уже проблема.
Модель зрелости стандартов
| Уровень зрелости | Характеристика | Стандарты, соответствующие на сегодня данному уровню зрелости |
| Уровень 0 | Есть понимание, что проблема существует | Семантические стандарты для транзакций |
| Уровень 1 | Много точек зрения на суть проблемы | Семантические стандарты для данных |
| Уровень 2 | Предложен вариант стандарта версии 1.0 | WS-Reliability (обеспечение надежного обмена данными и сообщениями) |
| Уровень 3 | Создан стандарт в варианте «функционально достаточный» | WS-Security, BPEL |
| Уровень 4 | Многие приложения уже используют этот вариант стандарта | XML, SOAP, WSDL |
| Уровень 5 | Повсеместное использование стандарта | TCP/IP, HTTP, SSL |
| Источник: Sun Microsystems | ||
Отсюда можно понять, что полная стандартизация компонентов — это недостижимый идеал. Не нужно забывать о том, что все ключевые игроки рынка — конкуренты, и каждый из них пытается опередить других, предложить более эффективное решение. А разработка стандартов — процесс довольно долгий, и разработчики зачастую просто не могут ждать его окончательного завершения.
Есть и другая очевидная проблема в самой идее компонентной архитектуры, которая скрывается за такими вопросами: как поддерживать множество различных инсталляций внешнего приложения? Как осуществлять контроль версий? Что произойдет, когда выйдет новая версия продукта?
Не нужно забывать о том, что в случае SOA мы имеем дело не просто с распределенной системой, а с системой, использующей внешние компоненты, которыми распоряжаются совсем другие хозяева. Как будет чувствовать себя ваша компания, когда в приложении вашего контрагента что-то поменяется, после чего нарушится созданный вместе с ним интерфейс и весь ваш бизнес-процесс перестанет выполняться?
Для предотвращения подобных ситуаций в SOA должны использоваться схемы взаимодействия с так называемыми слабыми связями. Это означает, с одной стороны, что интерфейс между двумя программными компонентами обязан адаптироваться к возможным изменениям в данных или алгоритмах обработки, а с другой — что даже полный отказ одного из компонентов не должен приводить к потере работоспособности системы в целом.
Но на этом вопросы, связанные с к SOA, не заканчиваются. Как обеспечить безопасность? Производительность? Масштабируемость?
Еще одна важная проблема: а захотят ли разработчики прикладных решений выполнять их в виде компонентных приложений, функционал которых будет доступен для внешних систем? Как метко было подмечено в одной из Интернет-дискуссий: “все хотят делать SOA-платформы для интеграции приложений, но что-то никто не стремится создавать прикладное ПО, пригодное для использования в SOA”.
Но как бы то ни было, идеи SOA находят все более широкое применение на практике. Что же касается инструментария, который может применяться для создания композитных приложений, то тут можно обратить внимание на новую платформу Sun Java Composite Application Platform Suite (см. статью “SOA-платформа от Sun Microsystems” в этом номере журнала).
Исследование Butler GroupОсенью 2005 г. исследовательская компания Butler Group (http://www.butlergroup.com) провела исследование, посвященное эффективности применения технологии разработки композитных приложений на примере использования продукта SeeBeyond ICAN (ставшего затем основой Java CAPS). В подготовленном по его результатам отчете “Разработка композитных приложений, сравнение совокупной стоимости владения” (Developing Composite Applications, Comparing the Total Cost of Ownership) был сделан ряд рекомендаций и выводов. В частности, в отчете перечислены ключевые компоненты, необходимые для эффективной разработки составных приложений:
Основные выводы, сделанные при изучении совокупной стоимости владения, таковы. Использование интегрированного набора существенно сокращает время работы над проектом, особенно на этапе разработки, так как снижается необходимость в написании кода программы. Бизнес-аналитикам придется освоить инструментальные средства для проектирования процессов, что может удлинить время планирования первого проекта, однако это нельзя считать недостатком, учитывая, что разработчики (практически из любой группы программистов) смогут принять участие как в первом, так и в последующих проектах без переподготовки для работы с такими сложными архитектурами, как J2EE. Сокращение объема кодирования и снижение сложности полного решения приводят к общему уменьшению затрат времени на тестирование. Трудоемкость развертывания решения значительно снижается за счет тесной интеграции между средами, используемыми при разработке и развертывании. Благодаря использованию общей платформы и сокращению трудоемкости перехода от одного этапа работы над проектом к другому заметно снижается норма накладных расходов на управление проектом. Связанный с проектом риск уменьшается на всех рабочих этапах, соответственно снижается и частота возникновения непредвиденных ситуаций. Это следствие ряда факторов, таких, как улучшение согласования бизнес- и ИТ-функций, сокращение кодирования, встроенные функции управления, а также возможность использования имеющихся навыков. Значительно снижаются расходы на поддержку проекта в последующие годы — частично из-за сокращения программного кода, но главным образом благодаря дополнительной гибкости, вытекающей из подхода к разработке, ориентированного на процессы. При изменении потребностей бизнеса или основных приложений слабые связи между процессами и базовыми системами позволяют значительно уменьшить сложность решения. Главный вывод проведенного исследования заключается в том, что интегрированный набор потенциально позволяет сократить на 50% первоначальную фазу разработки проекта (от проектирования до развертывания) по сравнению с традиционным подходом к разработке, а также достичь экономии совокупной стоимости владения до 58% на протяжении трех лет, если принимать во внимание расходы на последующую поддержку. Учитывая среднюю стоимость разработки приложения, в рассмотренном в отчете примере снижение общей стоимости за трехлетний период составит примерно 220 000 долл. |