СОА преподносит неприятные сюрпризы

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

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

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

СОА не является здесь исключением и также нуждается в поддержке других технологий. Одной из них, появившейся практически одновременно с СОА, является концепция BPM (Business Process Management). Что же такое BPM и как он связан с СОА?

Соотношение и взаимосвязь СОА и BPM

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

В большинстве существующих ИС класса управления предприятием (ERP) такие события инициируются в системе действиями пользователя. А поскольку исходно в концепции СОА о наличии у сервисов пользовательского интерфейса ничего не говорится, то у нас возникает явная необходимость в таком клиенте верхнего уровня, который взял бы на себя ещё и функцию общения с пользователем.

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

Итак, если мы опишем необходимый нам бизнес-процесс на некотором языке, (таковым сейчас стандартно является BPEL – Business Process Execution Language) и запустим его на исполнение, то интерпретатор BPEL совместно с СОА-ландшафтом обеспечат нам реализацию этого бизнес-процесса. Вопрос о том, было ли исполнение БП изначально инициировано пользователем или в системе был сконфигурирован автоматизированный «стартер», запускающий процесс по некоторому событию (по времени, например), не является принципиальным. Главное, что после того, как он запущен на исполнение, операторы, сервисы и системы работают совместно над реализацией, представляя собой некую человеко-машинную систему. Возникает «композитное приложение», состоящее из сервисов, объединенных единым бизнес-процессом.

Приведенная схема логически стройна, и всё было бы прекрасно, если бы не отрицательные заключения специалистов, пытающихся применить ее на практике. Эти заключения неоднозначны, поскольку что-то иногда получается. Но следует признать, что общий баланс скорее отрицательный. И это проблема не только BPM. Это становится также и проблемой реализации СОА. Попробуем провести более глубокий анализ.

Разноликие бизнес-процессы

Если попытаться понять, какие бывают бизнес-процессы, то становится очевидным, что они очень различны. Приведем примеры.

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

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

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

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

Как мы уже говорили ранее, на сегодняшний день разработка ИС в концепции СОА имеет более высокую трудоёмкость по сравнению с монолитными приложениями. Аналогичный проигрыш концепции BPM при реализации БП функционального характера ещё более усугубляет ситуацию.

Неизбежность сравнений

При попытках реализации ИС в концепции СОА невозможно уйти от их сравнения с классическими монолитными приложениями, реализованными в двух или трехзвенной архитектуре. Это сравнение производится как в плане оценки стоимости разработки, так и на уровне удобства интерфейса пользователя.

Следует признать, что за время, прошедшее с начала периода широкого внедрения персональных компьютеров, был накоплен большой опыт разработки клиент-серверных приложений. Имеются многочисленные инструментальные системы, к которым прилагаются широкодоступные библиотеки компонентов. Всем этим умеет пользоваться широкий круг программистов. Было бы странно упрекать инструментарий СОА в отсутствии или недостаточной развитости такой поддержки, ведь, в конце концов, это более молодая технология. Но надо признать и такое важное базовое преимущество схемы «клиент-сервер», как близость всех трех логических слоев приложения - «данные-алгоритмы-представление» - друг к другу. Все программируется компактно, единым текстом. Даже переход к трехзвенной архитектуре уже усложняет программирование. Становится необходимо обеспечивать связность кодов, исполняемых (интерпретируемых) на клиенте и на сервере приложений. Хочется этого избежать либо встроить серверный код прямо в страницы гипертекста, либо научить код сразу генерировать необходимый интерфейс. А концепция СОА ведет нас ещё дальше. В общем случае, между пользователем, работающим с некоторым интерфейсом, и данными, находящимися в СУБД, может находиться несколько слоев вызываемых для обработки сервисов.

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

Обаяние классической реляционной СУБД

Принцип организации хранения данных – это ещё один вопрос, решение которого для COA нельзя назвать однозначным.

С одной стороны, на рынке присутствуют инструменты, работающие на уровне объектной модели данных. Они предполагают, что достаточно лишь отметить «постоянство» определенных объектов, а все остальное взаимодействие с СУБД будет скрыто от пользователя.

С другой стороны, у этой концепции есть свои сложности. Стабильная уже на протяжении полувека теория реляционных баз данных предлагает свой мощный инструментарий манипуляции данными с поддержкой параллельного доступа и транзакционности. Реляционные СУБД обладают своими механизмами мониторинга, настройки производительности и т.п. Сокрытие этого инструментария за СХД безразлично лишь для простых приложений. В сложных же случаях эта система превращается из средства снижения трудоемкости программирования в свою противоположность. Он становится ещё одним дополнительным слоем, разделяющим пользователя и данные.

Есть ещё один аргумент. СУБД сохраняют данные в реляционной схеме. Пользователь в девяти случаях из десяти работает с данными, представленными в виде таблицы. Нечего говорить, что эти схемы близки друг другу. Но находящиеся между ними сервисы - это уже вотчина объектной модели данных.

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

И ещё одно замечание по поводу СУБД. Современные методологии программирования предполагают итеративный подход к разработке кода. Он должен пройти ряд последовательных изменений, каждое из которых «обкатывается» на практике. Этих итераций может быть достаточно много. В то же время данные гораздо более консервативны. Они требуют накопления и только в редких случаях позволяют при каждой итерации кода «забыть» всю предысторию и пересоздать базу «с чистого листа». В этих условиях выделение данных, находящихся в СУБД, в самостоятельный слой может парадоксально снизить трудоёмкость разработки по сравнению с попытками скрыть СУБД за механизмом обеспечения «постоянства данных».

Возможный рецепт - cервисные модули

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

Разместим рядом с веб-сервисом (SOAP) терминальный сервис, который обеспечит классический функциональный интерфейс пользователя и позволит проводить все необходимые операции над данными «вручную» под непосредственным управлением оператора. Не будем стесняться наличия в нашей архитектуре явно выраженного слоя данных, хранящихся в СУБД.

Таким образом, мы будем иметь комплект из набора данных в СУБД, веб-сервиса для обработки этих данных по запросам клиентов и терминального сервиса для обработки этих же данных в интерактивном режиме.

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

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

Такая триада может быть названа «сервисным модулем» (СМ) и претендовать на роль автономно разрабатываемого и администрируемого компонента СОА. Совокупности таких модулей будут давать функциональность, обеспечиваемую сегодня монолитными приложениями. Все множество СМ предприятия составит функциональность, на которую претендуют сегодня системы уровня ERP вместе с классом сопутствующих ИС (типа CRM, SCM и других в изобилии появляющихся трехбуквенных аббревиатур).

Эффект такого замещения ожидается в возможности переделки и замены СМ «здесь и сейчас» за приемлемое время, при приемлемом бюджете и даже в отсутствие первоначального автора этого СМ.

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

Наличие именно трех серверов кажется важным для обеспечения их специализации. Специализированность сервера СУБД в настоящее время не вызывает сомнений, а вот смешение в серверах приложений контейнеров для разнотипных объектов не выглядит привлекательно. Специфика поддержки массовой обработки запросов к пулу веб-сервисов, а также терминальных сессий пользователя, всё-таки, слишком выражена.

Можно надеяться, что введение в архитектуру третьего сервера не увеличит реальную трудоемкость разработки, т.к. создание и веб-, и терминального сервиса предполагается в рамках одного и того же сервисного модуля, т.е. одним разработчиком в одно и то же время. Это позволяет достичь унификации сервисов по коду до 50-70%.

Таким образом здесь речь идет фактически о симбиозе СОА с классической архитектурой «клиент-сервер» с попыткой сохранения лучших черт каждой из них. Безусловно, такой подход не устраняет полностью «ступеньку» в разнице трудоемкости разработки между СОА-приложением и приложением «клиент-сервер», но позволяет уменьшить её высоту и «стоимость вхождения в СОА».

Снова о бизнес-процессах

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

Чтобы ослабить негативный эффект такой фрагментации придется вводить специальное решение, интегрирующее интерфейсные части разных СМ. Таким решением, может быть применение на стороне клиента RCP (Rich Client Platform) по типу Eclipse.

Наличие RCP на стороне клиента позволит скрыть от пользователя сложность и объёмность интерфейса и предоставить ему в распоряжение только те окна и формы, которые необходимы для реализации конкретных БП и выполнения конкретных функций там, где бизнес-процессы не носят выраженного процедурного характера.

Эта область в настоящее время почти совсем не стандартизирована, что, безусловно, является серьёзным препятствием на пути практической реализации архитектуры с использованием СМ. Но в то же время специалисты, знакомые с ERP SAP R\3, скажут, что такая архитектура интерфейса, собираемого из различных «транзакций», далеко не новость в сфере ИТ.

Можно сказать, что для COA предлагается принцип сборного функционального интерфейса, подобный тому, который реализован в SAP R\3, но только на основе открытых стандартов.

Если теперь вернуться к BPEL и связанной с ним концепции BPM и композитных приложений, то они, безусловно, имеют право на свою часть реализуемых в системе бизнес-процессов. Другое дело, что они не могут быть единственным инструментом, используемым в СОА для поддержки интерфейса пользователя, их доля в общем числе реализуемых БП вряд ли превысит 15-20%. Всё остальное и проще, и дешевле реализовывать на базе терминального сервиса.

Вместо заключения

«Горизонт окупаемости» СОА лежит существенно дальше, чем цикл разработки классического монолитного приложения. Именно поэтому так тяжело на практике решиться на существенное увеличение трудоемкости разработки, которое СОА приносит с собой. Тем более что «рецепты СОА» неоднозначны (тот, что приводится в данной статье, не исключение) и ещё требуют своей проверки на практике.

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

Возможно, поэтому СОА у нас внедряется пока более с формальной стороны, с целью использования некоторого интерфейсного инструментария для интеграции обычных монолитных приложений или для использования BPEL. Понятно, что и ожидаемого эффекта в этом случае не наблюдается.

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

Источник: CNews, 29 августа 2011