Поделиться
Секреты СОА: как получить реальную отдачу
В последнее время многие компании всерьез увлеклись идеей сервис-ориентированной архитектуры (СОА) и вложили в ее осуществление немало средств и усилий. СОА становится все более популярным подходом для построения новых корпоративных систем. К этой концепции более или менее привыкли, она теперь понятна широкому кругу руководителей, и ее разработка не представляет особой сложности для программистов, но, тем не менее, не все так просто. Вопрос о правильном использовании СОА остается открытым, а тема целесообразности и своевременности ее применения - актуальной.Как и у многих других понятий сферы ИТ, какого-то общепринятого определения у СОА нет. Можно найти ряд более или менее удачных вариантов, ориентированных на технологические аспекты или абстрагирующихся от них. Тем не менее, все они не дают ответа на вопрос о том, как же достигаются столь замечательные результаты и чем, собственно, СОА отличается от "не СОА". Попробуем разобраться.
Все определения, которые даются понятию СОА, объединяет положение о том, что новые ИС должны быть построены как совокупность некоторых "сервисов", расположенных в единой компьютерной сети и взаимодействующих друг с другом стандартизованным образом. Под сервисами мы понимаем здесь некие достаточно автономные аппаратно-программные ресурсы, способные выполнять запросы по обработке информации. Часто их называют еще веб-сервисами, однако этот термин, по большому счету, не означает, что протокол HTTP играет какую-то особую и исключительную роль и только его применение позволяет сервисам нести приставку веб. Поэтому правильнее использовать этот термин более широко, подразумевая, что веб-сервисы – это такие сервисы, которые способны функционировать в среде СОА. Но в этом случае приходится ответить на вопрос: а разве современные ИС не являются системами, построенными на сервисном принципе? В таком обобщенном виде сервисный подход известен со времен зарождения интернета. А модульный принцип организации ИС вообще относится к категории "вечных ценностей программирования". Что нового появилось за последнее время, что позволяет позиционировать СОА, не больше и не меньше, как новую парадигму организации и использования распределенных информационных ресурсов?
СОА должна научить нас жить в условиях эволюции
Безусловно, появились новые технологические стандарты. Это, в первую очередь, стек протоколов взаимодействия сервисов c протоколом SОАP на вершине. Это базирующийся на XML стандарт описания сервисов – WSDL. Это механизм их поиска – UDDI. Вообще, XML сделал очень много для развития веб-сервисов. Впервые появилась технологическая база для взаимодействия сервисов, не связанная ни с одним из производителей ПО, ни с одним из языков программирования или какой-либо другой "частной" технологией.
Но технология совсем не является определяющим признаком СОА. Во-первых, есть и альтернативные стандарты. А во-вторых, само по себе применение технологий не делает СОА и не приносит в ИС нового качества. Где же критерий?
Экономическая сверхзадача СОА
Итак, чего мы хотим достигнуть с помощью СОА? Очевидно, мы хотим преодолеть "программистское проклятье", когда мы программируем все сами и, в конце концов, достигаем предельного уровня сложности системы, с каким можем справиться при доступном бюджете. Когда ресурсы, необходимые для продолжения работы, становятся просто неприемлемыми. Или когда мы покупаем готовое ПО, но оно не в состоянии удовлетворить наши специфические потребности, а его исправление нереально или не успевает за бизнесом. И в том, и в другом случае ИС "костенеет", она неспособна больше изменяться и следовать за бизнесом, она неспособна аккумулировать накопленный опыт в своей структуре.
Новый идеальный мир ИС должен выглядеть примерно так: ИС состоит из модулей-сервисов; инфраструктура, необходимая для функционирования сервисов, достаточно проста и может быть приобретена у разных поставщиков; замена одного сервиса не требует немедленной замены других; сервисы имеют сравнительно невысокую стоимость разработки; исчезновение с рынка нескольких разработчиков сервисов не приводит к катастрофическим последствиям для сопровождения ИС; система постоянно "живет" – новые сервисы подключаются, старые заменяются и модифицируются; ИС способна к постоянному изменению при разумном бюджете.
Вот этот последний тезис и есть концентрированное выражение экономической "сверхзадачи" СОА – сделать так, чтобы даже при наличии небольшого бюджета ИС могли поэтапно развиваться. Не должно быть ситуации, когда для внесения каких-либо изменений в ИС она должна быть предварительно чуть ли не полностью разрушена и воссоздана заново. Инвестиции в ИС не должны обесцениваться столь катастрофически быстро. Для крупных ИС эволюция – это вообще единственно возможный способ развития. СОА должна научить нас жить в условиях эволюции.
Каким быть сервисам?
Уяснив, чего мы хотим от СОА в экономическом плане, становится понятно, почему само по себе применение специфического для СОА интерфейса (того же SОАP) между компонентами ИС не решает поставленную задачу. Необходимо что-то большее. Но что? Какими должны быть сервисы, чтобы, будучи объединенными в систему, дать этой системе новое качество? Попробуем дать разработчикам ряд практических советов и обосновать несколько принципиальных положений.
Гранулярность
О том, что сервисы должны быть достаточно "легкими" и дешевыми, уже говорилось выше. Практика программистского труда говорит о том, что максимальной эффективностью обладают коллективы программистов из 5–10 человек, работающих над проектом 3–6 месяцев. Сервис должен быть написан, а при необходимости и переписан именно в таких ресурсных рамках.
Разработка всей или части ИС как некоего сервиса с большим числом интерфейсов в течение пары лет компанией в 50–100 человек способна обесценить идею СОА, даже если все технологические требования были соблюдены.
Настолько объемная функциональность должна быть разбита на серию сервисов, интерфейс между которыми будет публично описан. Этот интерфейс не может быть внутренним делом компании-разработчика. И дело не столько в том, соответствует ли он стандартам СОА, сколько в его публичности. При необходимости замена и модернизация системы должны быть обеспечены на "посервисном" уровне и при отсутствии первоначального разработчика кода.
Инкапсуляция
Но что мешает архитектору СОА произвести нарезку более мелких сервисов, чем были описаны в предыдущем разделе? Тем более что существует принцип: для выполнения одинаковых действий старайся пользоваться одним и тем же кодом. Приходилось видеть тексты программ, где этот принцип доведен до крайности, и большинство методов состоят из двух-трех строк кода. Вряд ли такая методология может быть признана успешной.
Сокрытие сложности реализации сервиса внутри него самого и избавление тех, кто пользуется сервисом, от знания этих тонкостей – это важный постулат не только объектно-ориентированного программирования, но и СОА. Для того чтобы эффект инкапсуляции был максимальным, сервис все-таки должен быть достаточно большим. Иначе логическая сложность системы будет просто вытеснена на уровень взаимодействия сервисов. Запутанная логика взаимодействия простых сервисов нисколько не лучше, чем сложные запутанные сервисы, взаимодействие которых достаточно тривиально.
Короткая ссылка
