Поделиться
СОА преподносит неприятные сюрпризы
Концепция СОА, приобретающая все большую популярность, на самом деле оказывается не такой прозрачной, как представляется в начале. Для многих проектов, реализующих сервис-ориентированную архитектуру, очень важно обеспечить высокий уровень удобства и дружественности интерфейсов, к которым пользователь привык в классических системах "клиент-сервер". Задача, кажущаяся на первый взгляд простой, в реальности далеко не тривиальна. Например, неожиданным открытием может оказаться высокая трудоемкость реализации такого интерфейса.В том случае, когда надо поддержать БП, носящий скорее функциональный характер, концепция BPM явно проигрывает обыкновенному приложению в стиле "клиент-сервер" как по удобству использования, так и по сложности реализации.
Руководитель службы ИТ для снижения рисков вынужден искать некоторый "программный мейнстрим", который позволил бы ему и его ИС "продержаться на плаву" как можно дольше
Как мы уже говорили ранее, на сегодняшний день разработка ИС в концепции СОА имеет более высокую трудоёмкость по сравнению с монолитными приложениями. Аналогичный проигрыш концепции BPM при реализации БП функционального характера ещё более усугубляет ситуацию.
Неизбежность сравнений
При попытках реализации ИС в концепции СОА невозможно уйти от их сравнения с классическими монолитными приложениями, реализованными в двух или трехзвенной архитектуре. Это сравнение производится как в плане оценки стоимости разработки, так и на уровне удобства интерфейса пользователя.
Следует признать, что за время, прошедшее с начала периода широкого внедрения персональных компьютеров, был накоплен большой опыт разработки клиент-серверных приложений. Имеются многочисленные инструментальные системы, к которым прилагаются широкодоступные библиотеки компонентов. Всем этим умеет пользоваться широкий круг программистов. Было бы странно упрекать инструментарий СОА в отсутствии или недостаточной развитости такой поддержки, ведь, в конце концов, это более молодая технология. Но надо признать и такое важное базовое преимущество схемы "клиент-сервер", как близость всех трех логических слоев приложения - "данные-алгоритмы-представление" - друг к другу. Все программируется компактно, единым текстом. Даже переход к трехзвенной архитектуре уже усложняет программирование. Становится необходимо обеспечивать связность кодов, исполняемых (интерпретируемых) на клиенте и на сервере приложений. Хочется этого избежать либо встроить серверный код прямо в страницы гипертекста, либо научить код сразу генерировать необходимый интерфейс. А концепция СОА ведет нас ещё дальше. В общем случае, между пользователем, работающим с некоторым интерфейсом, и данными, находящимися в СУБД, может находиться несколько слоев вызываемых для обработки сервисов.
Принципиальная "многоярусность" сервисов СОА является обстоятельством, серьёзно усложняющим программирование. Поэтому для того, чтобы не проигрывать сравнение в трудоемкости с простым приложением "клиент-сервер" столь безнадежно, СОА надо научиться избегать этой "многоярусности" везде, где только возможно.
Обаяние классической реляционной СУБД
Принцип организации хранения данных – это ещё один вопрос, решение которого для COA нельзя назвать однозначным.
С одной стороны, на рынке присутствуют инструменты, работающие на уровне объектной модели данных. Они предполагают, что достаточно лишь отметить "постоянство" определенных объектов, а все остальное взаимодействие с СУБД будет скрыто от пользователя.
С другой стороны, у этой концепции есть свои сложности. Стабильная уже на протяжении полувека теория реляционных баз данных предлагает свой мощный инструментарий манипуляции данными с поддержкой параллельного доступа и транзакционности. Реляционные СУБД обладают своими механизмами мониторинга, настройки производительности и т.п. Сокрытие этого инструментария за СХД безразлично лишь для простых приложений. В сложных же случаях эта система превращается из средства снижения трудоемкости программирования в свою противоположность. Он становится ещё одним дополнительным слоем, разделяющим пользователя и данные.
Есть ещё один аргумент. СУБД сохраняют данные в реляционной схеме. Пользователь в девяти случаях из десяти работает с данными, представленными в виде таблицы. Нечего говорить, что эти схемы близки друг другу. Но находящиеся между ними сервисы - это уже вотчина объектной модели данных.
С одной стороны, двойное отображение объектной модели на данные и на интерфейс пользователя даром не дается. С другой стороны, а насколько часто нами используется действительно объектная модель прикладных данных - с наследованием, полиморфизмом и т.п.? Понятно, что программировать что-либо сегодня, не используя объектный подход, это нонсенс. Но чисто прикладные данные требуют объектной модели далеко не всегда.
И ещё одно замечание по поводу СУБД. Современные методологии программирования предполагают итеративный подход к разработке кода. Он должен пройти ряд последовательных изменений, каждое из которых "обкатывается" на практике. Этих итераций может быть достаточно много. В то же время данные гораздо более консервативны. Они требуют накопления и только в редких случаях позволяют при каждой итерации кода "забыть" всю предысторию и пересоздать базу "с чистого листа". В этих условиях выделение данных, находящихся в СУБД, в самостоятельный слой может парадоксально снизить трудоёмкость разработки по сравнению с попытками скрыть СУБД за механизмом обеспечения "постоянства данных".
Возможный рецепт - cервисные модули
Итак, мы попытались проиллюстрировать тезис о том, что разработка классических приложений в стиле "клиент-сервер", не смотря на кажущуюся архаичность, представляет собой весьма эффективный процесс и разработка композитных приложений в стиле COA сегодня не может с ним конкурировать, уступая как по трудоемкости разработки, так и по удобству использования. И если мы действительно уверены в том, что только СОА способна в дальнейшем обеспечить относительно безболезненное развитие и модификацию корпоративных ИС, то мы должны попытаться утилизировать для СОА преимущества схемы "клиент-сервер". Как это можно сделать?
Разместим рядом с веб-сервисом (SOAP) терминальный сервис, который обеспечит классический функциональный интерфейс пользователя и позволит проводить все необходимые операции над данными "вручную" под непосредственным управлением оператора. Не будем стесняться наличия в нашей архитектуре явно выраженного слоя данных, хранящихся в СУБД.
Таким образом мы будем иметь комплект из набора данных в СУБД, веб-сервиса для обработки этих данных по запросам клиентов и терминального сервиса для обработки этих же данных в интерактивном режиме.
Короткая ссылка
