Мифология SOA

Вы увлечены идеями SOA? Вы хотите применить их на практике при проектировании своих систем или в интеграционном проекте? Тогда приготовьтесь к трудностям. Существует ряд широко распространенных мнений, которые я, иначе как мифами SOA назвать не могу. На пути практической реализации своих идей вы наверняка столкнетесь с трудностями в самых неожиданных местах, именно там где их быть вроде бы не должно.
Проектирование систем всегда ведется по двум встречным направлениям. С одной стороны, мы движемся от бизнес модели, которая представлена бизнес возможностями и бизнес требованиями, через модель сервисов, которая и есть суть предмета SOA, к технологической модели, в которой раскрывается реализация системы. С другой стороны существует встречное движение от технологических платформ, которые определяют основные возможности и ограничения, к модели сервисов, где эти возможности и ограничения следует грамотно учесть, и к бизнес модели, где мы сверяем полученный результат с предъявляемыми требованиями. При этом основные трудности проектирования всегда возникают на границах, при переходе от одной модели к другой. О том, как трансформировать бизнес модель в модель сервисов, написано очень много. Среди написанного, попадаются здравые идеи, и об этом я расскажу в другой раз. Основные трудности и разочарования поджидают вас на этапе, когда вы приступите к реализации красивой и согласованной модели сервисов. На технологическом уровне, одни идеи оказываются не реализуемыми, другие - бесполезными, а третьи выглядят при реализации совсем по-другому. Все эти вещи я и называю «мифами SOA». Давайте поговорим о них.
Все проектируют сервисы, а кто спроектирует клиентов? «Автономные и независимые сервисы взаимодействуют путем передачи друг другу сообщений» - это одна из основных парадигм SOA. Все сосредоточены на проектировании сервисов, но когда мы спускаемся на уровень реализации, независимо от платформы (java, .Net, PHP) мы обнаруживаем что здесь оперируют другими терминами. Здесь сервис взаимодействует с клиентом. А сервис с сервисом взаимодействовать не может. Т.е. мы обнаруживаем, что в нашей системе, образно говоря, есть только розетки, и нет ни одного штепселя. Проблема концептуальная и достаточно серьезная. Подумайте о том, что контракт сервиса на самом деле имеет две комплиментарные стороны: строну сервиса и строну клиента. Если ваш сервис намерен не только выступать источником каких либо данных, но и получать какие либо данные из вне, то часть его контракта будет носить «клиентский» характер.
Сервисы регистрируются в реестре, для того чтобы другие сервисы могли их найти. Роль реестра сильно преувеличена. Сценарий, в котором сервис - потребитель данных обращается в некий реестр сервисов и находит там для себя реализацию сервиса - источника данных, а затем начинает ее использовать, чрезвычайно сложен в реализации. Более того, он недостаточно подкреплен соответствующими спецификациями отраслевых стандартов. Те спецификации, которые сейчас существуют (UDDI, WS-management) либо не покрывают все проблемы, связанные с данным сценарием, либо недостаточно поддерживаются вендорами платформ. Реестром может пользоваться middleware но сами сервисы - вряд ли. Проблемы тут, одна хуже другой. Проблема поиска – как найти нужный сервис, по каким критериям должен осуществляться поиск. Проблема совместимости – что делать, если нужный сервис найден, а контракты не совпадают. Наконец, проблема безопасности - нужный сервис найден – как установить доверительные отношения; как сервис источник узнает, что нового потребителя можно обслуживать; как сервис потребитель получит удостоверения для обращения к нужному сервису.
Вы не сделаете это сами. Вы не реализуете полноценную SOA архитектуру самостоятельно, потому что не один из технологических стеков (платформ разработки web сервисов) не предоставляет всех возможностей для построения полнофункциональной SOA архитектуры от и до. Вам потребуется middleware. И оно стоит денег. Все, что на сегодняшний день предоставляют вам вендоры платформ, это инструментарий для разработки самих сервисов и более или менее богатый набор средств доставки сообщений (объектные брокеры, очереди сообщений, координаторы транзакций, транспортные и форматные привязки). Если у двух ваших сервисов, которые должны взаимодействовать, формат сообщений различается хоть на один байт, вам потребуется промежуточное ПО (middleware) для преобразования сообщений. Если вам надо организовать управляемую событиями или данными маршрутизацию сообщений - вам потребуется соответствующее middleware. Все наиболее привлекательные особенности SOA, как то, гибкость и адаптивность, композиция, ориентация на процессы, все это на сегодняшний день осуществляется в основном средствами соответствующего middleware. Вы можете предпринять отчаянную попытку все это сделать самостоятельно, но будьте готовы к тому, что ваши затраты вырастут в разы, а решение получится сложным, недостаточно гибким и не соответствующим промышленным стандартам.
Это, пожалуй, наиболее распространенные мифы SOA. Однако, не будем забывать о том, что два - три года назад вся SOA была лишь красивой теорией не подкрепленной даже соответствующими спецификациями и стандартами, не говоря уже о продуктах и платформах. Например в .Net 1.0 в плане реализации web сервисов не поддерживала ни WS-Security, ни WS-Atomic transaction. А Apache Axis даже не имела средств для генерации кода по WSDL описанию. Сегодня все гораздо лучше. Windows Communication Foundation уже не только поддерживают транзакции и шифрование но и оперирует такими понятиями, как контракт сервиса и контракт клиента, конечная точка и привязка. Будем надеяться, что через пару лет мифы превратятся в реальность. И эта реальность будет «сервис – ориентированной».