Поделиться
СОА преподносит неприятные сюрпризы
Концепция СОА, приобретающая все большую популярность, на самом деле оказывается не такой прозрачной, как представляется в начале. Для многих проектов, реализующих сервис-ориентированную архитектуру, очень важно обеспечить высокий уровень удобства и дружественности интерфейсов, к которым пользователь привык в классических системах "клиент-сервер". Задача, кажущаяся на первый взгляд простой, в реальности далеко не тривиальна. Например, неожиданным открытием может оказаться высокая трудоемкость реализации такого интерфейса.Взаимодействие терминального сервиса с СУБД при этом может происходить как напрямую, так и при посредничестве веб-сервиса, - как удобнее.
Для взаимодействия сервисов между собой оставим не только 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. Понятно, что и ожидаемого эффекта в этом случае не наблюдается.
Однако потенциальный выигрыш от полноценного применения СОА весьма велик. Глядя на то, с какими проблемами сталкивается построение комплексных корпоративных ИС, понимаешь, что альтернативы сервис-ориентированной архитектуре сегодня нет. Просто путь к ней оказался более сложным, чем предполагалось в начале.
Короткая ссылка
