Поделиться
Секреты СОА: как получить реальную отдачу
В последнее время многие компании всерьез увлеклись идеей сервис-ориентированной архитектуры (СОА) и вложили в ее осуществление немало средств и усилий. СОА становится все более популярным подходом для построения новых корпоративных систем. К этой концепции более или менее привыкли, она теперь понятна широкому кругу руководителей, и ее разработка не представляет особой сложности для программистов, но, тем не менее, не все так просто. Вопрос о правильном использовании СОА остается открытым, а тема целесообразности и своевременности ее применения - актуальной.Хорошей аналогией здесь является разработка операционных систем, где многообещающий принцип микроядра оказался не таким эффективным на практике именно из-за сложности взаимодействия остальных компонентов операционной системы, общающихся через это микроядро.
Связность
Итак, сервис не должен быть ни слишком большим, ни слишком маленьким. Логическая сложность функционирования ИС должна быть рационально разделена между внутрисервисным уровнем, где система инкапсулирована, и межсервисным уровнем, где она должна быть публична и интерфейсы должны быть формально описаны.
При выполнении этих требований нарезку на сервисы, очевидно, необходимо производить так, чтобы связность их была минимальна. При этом мы максимально упрощаем уровень межсервисного взаимодействия, не жертвуя при этом оптимальной гранулярностью сервисов.
СОА пока задает больше вопросов, чем дает ответов
Минимизация связности частей – не новый принцип построения архитектуры ПО, и здесь, как и в других местах, просто подчеркивается, что при проектировании СОА важно придерживаться базовых принципов программирования, не возводя ни один из них в абсолют.
Иерархичность
Теперь представим ситуацию, когда рекомендуемый уровень гранулярности выдержан, но количество взаимодействующих сервисов все равно остается большим и, более того, возникают сложности при взаимодействии сервисов. Например, интерфейсы сервисов семантически близки, но формально не совпадают. В этом случае мы можем попытаться переложить часть функциональности на инфраструктуру сервисного взаимодействия, например, на сервисную шину (Service Bus) или систему обмена асинхронными сообщениями (Messaging System). Но не стоит этим увлекаться.
Возможности поддержки со стороны инфраструктуры будут достаточно быстро исчерпаны, а сложность системы так и удастся преодолеть.
Предполагается, что с самого начала должна быть поставлена задача по организации сервисов в иерархии. Плоская структура сервисов вряд ли способна выдержать испытание достаточно сложной ИС. Понадобятся сервисы, способные агрегировать и инкапсулировать работу других сервисов. При наличии таких сервисов появится возможность организовывать ИС как многоуровневую иерархию сервисов, сохраняя при этом достаточную простоту и прозрачность взаимодействия сервисов на каждом из уровней.
Агрегирующий сервис не в состоянии предоставить весь комплекс услуг, которые способны оказать агрегируемые сервисы по отдельности, но этого и не требуется. Сервис-агрегатор должен скрыть логическую сложность уровня, расположенного ниже. Одновременно он предотвратит соблазн получить некоторую услугу напрямую от агрегируемого сервиса, что хотя и выглядит соблазнительно, но способно "отравить" проектируемую архитектуру избыточной связностью.
Зависимость от инфраструктуры
Заманчиво объявить, что в архитектуре СОА есть только взаимодействующие сервисы и ничего больше. Теоретически такая модель возможна. Но мы уже упомянули сервисную шину (Service Bus) как объект инфраструктуры, который сам по себе, строго говоря, не является сервисом. Система обмена асинхронными сообщениями (Messaging System) может быть оформлена и как сервис, и как часть инфраструктуры. Еще один явный кандидат в объекты инфраструктуры – система безопасности и управления доступом.
Чем богаче инфраструктура, тем легче жизнь сервисов и тем проще формирование ИС. Но богатство инфраструктуры несет в себе элемент противоречия. Инфраструктура с богатым набором функций не может быть полностью стандартизирована. А приобретая ее у поставщиков, мы рискуем снова получить в свое распоряжение СОА от Microsoft, СОА от Oracle и т.д. Поставщики ИС уже продвигаются в этом направлении. Но зачем это потребителям?
Наверное, стоит признать, что минимум инфраструктуры сервисам необходим. Те сервисные функции, к которым должно обращаться большинство сервисов, стоит выносить на уровень инфраструктуры. Но безудержное наращивание его объема способно свести всю идею СОА на нет.
Наследование и полиморфизм
Уж если мы упомянули инкапсуляцию, то нельзя обойти вниманием и отношение СОА к двум другим "китам" объектного программирования – наследованию и полиморфизму.
Конечно, наличие механизма наследования при разработке сервисов весьма добавило бы им гибкости, и, наверное, для сервисов, производимых в одной среде разработки, это реализуемая задача. Полиморфизм появляется при этом как логическое следствие наследования. Сложнее сказать, можно ли было бы наследовать любому сервису.
Определенный ответ дать сложно. СОА пока задает больше вопросов, чем дает ответов.
Вездесущие бизнес-процессы
Разговор до настоящего времени шел лишь о том, как организовать архитектуру сервисов, чтобы дать системе возможность развиваться, упростить и удешевить ее разработку и эксплуатацию. Но какова же будет жизнь пользователей в такой системе? Очевидно, что если не принять специальных мер, эта жизнь будет просто невыносимой.
Бизнес-процессы, определяющие выполнение системой тех или иных полезных функций во взаимодействии с человеком, будут проходить, условно говоря, и вдоль, и поперек сервисов. Пользователю придется постоянно переключаться между интерфейсами, разработанными разными людьми, в разное время и по разным технологиям. Учитывая весьма ограниченную способность человека к освоению незнакомых интерфейсов, предугадать реакцию пользователей несложно – это полное неприятие системы.
Нельзя сказать, чтобы эта проблема никого не заботила. Для ее решения была предложена технология описания и исполнения бизнес-процессов – язык BPEL1 и его интерпретаторы. Интерпретатор BPEL должен взять на себя слой взаимодействия с пользователем, "аранжируя" (новый термин) работу сразу со многими сервисами и скрывая их самих от пользователя. Однако, оцените, какую часть ваших усилий как разработчика вы тратили на реализацию формального алгоритма манипуляции с данными, а какую на обеспечение удобства и производительности труда пользователя? Скорее всего, для большинства не относящихся к области научных и инженерных расчетов задач это будет до 80% в пользу интерфейса пользователя. Все существующие графические среды разработки развивались сначала как способ создать интерфейс пользователя и затем навесить на него необходимые back-end функции. Многие остаются такими до сих пор.
А теперь представьте, что всю эту сложную работу по организации окон, меню, выпадающих и древовидных списков, кнопок, экранов выбора и селекции, уточняющих диалогов – все это необходимо реализовать при помощи довольно примитивного интерпретатора, который генерирует настолько же примитивный интерфейс. Нечего говорить, что все это годится больше для презентаций или для таких задач, реализация которых и без того не представляет сложности.
На самом деле, проблема еще сложнее. Человек, встроенный в бизнес-процессы, представляет собой слишком специфическую их часть. Он допускает ошибки, может не отвечать на запросы системы, реагировать нестандартно и т.п. Попыткой ответить на этот вызов стала спецификация BPEL4PEOPLE, ориентированная на взаимодействие с человеком. Но и этой технологии еще далеко до зрелости.
Технология Rich Client Platform, начало которой положила знаменитая система Eclipse, уже обладает потенциалом, необходимым для того, чтобы организовать взаимодействие сервисов друг с другом при посредничестве человека, сохранив при этом ставший общепринятым сегодня уровень интерфейса с пользователем.
Но, к сожалению, вопросы стандартизации в этой области остаются непроработанными. Можно предположить, что схема взаимодействия СОА с пользователем, опирающаяся на единое рабочее место на базе RCP-решения, может быть достаточно эффективной. Хорошим аналогом здесь выступает архитектура X-Server. Сервер пользовательского интерфейса, назовем его RCP-сервером, должен предоставлять веб-сервисам набор стандартных функций не столько для организации пользовательского интерфейса, сколько для обеспечения интеграции пользовательских интерфейсов друг с другом под непосредственным управлением пользователя. Стоит еще раз напомнить, что стандартов в этой области пока не установлено.
Приманка самоорганизации
Мы упомянули, что СОА должна позволить ИС жить долго и развиваться эволюционно. Можно ли предусмотреть сразу все будущие потребности системы и выработать для нее нечто вроде генерального плана? Если и можно, то весьма приблизительно и с ощутимым риском ошибки. Более того, единый интерфейс, применяемый как для взаимодействия частей ИС, так и для взаимодействия самих ИС, делает их границы более "административными", чем техническими. Это принципы, по которым построена всемирная сеть интернет. И эта сеть обладает свойствами самоорганизации и не имеет какого-либо центрального плана вообще.
Если применение архитектуры СОА вырастет до ожидаемых масштабов, то она неизбежно должна будет обладать свойствами самоорганизации. Когда перед двумя развивающимися системами СОА, административно управляемыми раздельно, встанет задача интеграции, они должны решать ее достаточно быстро и эффективно.
Короткая ссылка
