На протяжении последних пяти лет в компьютерном мире ведутся неутихающие дискуссии о сервисно-ориентированной архитектуре. Что понимать под SOA, как ее определять и каковы главные признаки нового подхода — об этом продолжают и продолжают спорить. Для того чтобы ярче проиллюстрировать эти прения, мы свели в одном месте приверженцев разных точек зрения, условно назвав их технологами-сервисниками, технологами-адаптистами и процессистами. Вопрос, который был им задан, весьма прост: «Каково корректное определение SOA?».

Технологи-сервисники: Всё элементарно — определение SOA заключено в названии. SOA — это архитектура построения программного обеспечения, набор концепций и методик построения корпоративных систем, в основе которой лежит идея сервисов. Это просто результат технологической эволюции идеи компонентов.

Первые идеи такого типа появились еще в середине 80-х. Принципы удаленного вызова процедур (Remote Procedure Call, RPC) были разработаны компанией Xerox в 1976 году и реализованы в проекте Courier, а позже в Unix-станциях Sun Microsystems. Суть состояла в том, чтобы развить подход вызова подпрограммы на сеть. Существенно позже реализацию RPC предложили Microsoft (DCOM) и Object Management Group (CORBA). Именно на технологии CORBA базировались первые работо­способные в корпоративном масштабе решения. Но в отличие от сегодняшних сервисов после RPC-вызова процедура приостанавливалась и ожидала результата. Сегодня мы бы сказали, что это была реализация жесткой связи.

Затем пришло понимание, что необходимы слабосвязанные асинхронные процедуры, для чего и был придуман сервис. По сути SOA появилась уже тогда, но в то время этот подход не достигал тех высот популярности, что сейчас. Только с возникновением технологии Web-сервисов строить такие решения стало сущест­венно проще, что и привело к сегодняшней распространённости SOA. О чем говорит вся эта история? О том, что развитие, очевидно, шло по пути упрощения межкомпонентного взаимодействия. И с такой точки зрения сервис — суть этого развития и суть SOA.

Технологи-адаптисты: Это слишком узкий взгляд на эволюцию. Да, действительно развитие шло именно по такому пути, но в процессе эволюции у технологии появились качественно другие свойства, о которых в середине 80-х и не думали. Прежде всего это возможность адаптации к изменениям. Главное совсем не в том, что сервис является совершенным развитием идей межкомпонентного взаимодействия. Если о свойстве многократного использования удаленных процедур или сервисов говорили давно, то гибкость и возможность адаптации к изменениям — принципиально иное качество, ключевое преимущество, понимание которого пришло именно с появлением SOA.

Поэтому с нашей точки зрения корректное определение SOA следующее. SOA — это каркас для интеграции бизнес-процессов и поддерживающей их архитектуры в форме безопасных стандартизированных компонентов, которые могут использоваться многократно и комбинироваться для адаптации к изменениям приоритетов бизнеса. Ключевой момент данного определения — именно адаптация и гибкость, а не просто сервисы.

Технологи-сервисники: Ничего подобного. Ключевые слова, связанные с сегодняшним этапом эволюции технологий взаимодействия компонентов, — стандартизация, многократное использование и слабая связанность. Это признают все, но в разные моменты различные специалисты пытались выдвигать то или иное свойство как главное. Например, во главу угла ставилась идея стандартизации — дескать, в ней главный признак SOA. Но этих инициаторов быстро угомонили, ведь с технологической точки зрения гораздо более определяющей является концепция многократного использования. А если нужно многократное использование, тогда обязательно присутствует и стандартизация.

Другие специалисты в качестве главного признака SOA пробивали и идею слабосвязанности. Понятно, что обычно приложение отражает сильно связанные функции, а бизнесу нужны лишь некоторые из них. Возникает проблема гибкости: бизнес должен строить процесс, а у него есть не отдельные его элементы, а цельные и крупные куски, и это не дает ему возможности быстро развивать свои процессы или менять их. Естественно, что для преодоления этой проблемы нужна слабая связанность. Однако необходимость слабосвязанных асинхронных взаимодействий была понята гораздо раньше, практически одновременно с расцветом монолитных корпоративных приложений, о гибкости которых тогда никто и не думал. Это сейчас их удобно применять для обеспечения гибкости. Но исторически слабая связанность — просто результат развития идей компонентного взаимодействия. Точно так же говорить, что главным признаком SOA является гибкость, — значит грешить против истины. Это свойство, которое приобрели компоненты в процессе эволюции, сегодняшнее содержание понятия «сервис». И не факт, что оно сохранится таковым надол­го. Скорее наоборот: наверняка через некоторое время станет актуальным решение других задач, которое по­требует других свойств сервисов. Поэтому мы настаиваем, что первичным является именно понятие сервиса.

Процессисты: Ваш спор не имеет большого смысла, а ваши взгляды не выходят за пределы технологий. Все это подходы пятилетней давности, и они устарели. Тогда еще не было понимания использования сервисного похода в управлении бизнесом. Современный подход к SOA отражает в первую очередь требования бизнеса. Бизнес все больше рассматривается не как набор функциональных подразделений, а как набор процессов. А поскольку он становится процессным, отсюда и возникает требование поддержки процессов, распространяемое на ИТ-системы.

SOA появилась только вследствие того, что в бизнес внедряются процессные методики. Посмотрите, есть очень хорошие документы OASIS, которые определяют SOA так, что ИТ вообще не упоминаются. В них SOA определяется как подход к организации любого бизнес-действия. О чем это говорит? О том, что главное — процессный подход и оптимизация бизнеса.

На наш взгляд корректное определение SOA таково: это методика, позволяющая перевести ресурсы ИТ-подразделения в сервисы, которые используются бизнесом при процессном управлении. Надо сделать прозрачную трансляцию бизнес-сервисов на ресурсы ИТ-систем, причем это имеет смысл именно в разрезе процессов. Какая при этом будет архитектура — связанные композитные приложения или унаследованные монолитные, значения не имеет. Самое главное — поддержка процессного подхода в бизнесе.

Технологи-адаптисты: Это полная ерунда, процессы тут ни при чем. А определять SOA как средство оптимизации бизнес-процессов — это и вовсе глупость, которую и обсуждать не хочется. Так и факс можно обозвать средством оптимизации бизнес-процессов. И попробуйте доказать, что нет. Эта логика бессмысленна.

Реальная проблема ИТ — это все-таки обеспечение гибкости, и данная задача не связана напрямую с процессами. Понятно, что перестройку бизнеса, опирающегося на ИТ-поддержку, тормозит жесткая структура приложений. И возникает очевидная идея: а нельзя ли часть бизнес-логики из приложения вынести «вовне», сделать ее доступной для изменений? Именно так, а совсем не из процессного подхода родилась идея сервисов, к которым каждый может обратиться и узнать, что он может сделать. Да, процессный подход есть, и его популярность будет расти. Но SOA появилась раньше, и применять ее можно и без процессной ориентации — строить композитные приложения без развертывания «процессных движков». Более того, SOA не является абсолютно необходимой для реализации процессного подхода к бизнесу. Скорее эти подходы развиваются параллельно.

Процессисты: Это они раньше так развивались, а в последнее время слились в одну идеологию. И выяснилось, что самое главное — это формализовать бизнес-процессы до нужного элементарного уровня, а ИТ-процессы — до нужного агрегированного уровня. То, что главная проблема состоит в унаследованных системах, — это миф. Проблема не в унаследованных системах, а в том, что мы не можем формализовать бизнес-процессы до уровня элементарных и поднять до уровня этих элементарных бизнес-сервисов услуги ИТ. Технологических ИТ-сервисов для этого недостаточно. Через них мы можем обеспечить лишь элементарные бизнес-процессы. А со сложными что происходит? В лучшем случае ИТ-отдел делает какие-то запросы и строит отчеты с указанными полями; получается сложно, долго и дорого. А в худшем — не делает ничего.

Вот потому-то принципиально важно обеспечить прозрачную трансляцию бизнес-сервисов на ресурсы ИТ-систем. И SOA нацелена именно на это.

Технологи-сервисники: Нет, это все маркетинговый шум поставщиков и не более того. Ведь посмотрите: вы свалили в одну кучу все проблемы ИТ. Не надо мудрить. Сервисно-ориентированная архитектура — это есть подход к созданию композитных приложений на основе сервисов. Только и всего. Причем ключевым словом является «подход», и в этом смысле, конечно, SOA очень далека от традиционного понятия архитектуры. Но надеемся, она ею действительно станет. По крайней мере в этом направлении предпринимаются огромные усилия. Но для того, чтобы распространять на SOA все наиболее болезненные проблемы в области ИТ, нет никаких оснований. Это притянуто за уши.

Процессисты: А конвергенция SOA и BPM, которая очень активно идет сейчас, разве не подтверждает эту точку зрения? BPM как специализированная технология, связанная с оптимизацией бизнес-процессов и управлением изменениями в них, родилась в конце 90-х годов и была построена на проприетарных технологиях. Но SOA появилась несколькими годами позже и прин­ципиально на другом базисе. То есть между этими технологиями изначально не было родовой связи. Однако эксперты быстро осознали близость их конечных целей, и начался активный процесс конвергенции. В результате BPM стало верхним и наиболее общим слоем в SOA, и они не мыслятся друг без друга. Это разве не подтверждение безусловного приоритета процессного подхода?

Технологи-сервисники и адаптисы в один голос: Нет, не подтверждение. Это всего лишь результат огромного желания поставщиков продать клиентам что-нибудь в обертке поновее и покрасивее. Какие эксперты «осознали близость их конечных целей»? Эскперты из ИТ-компаний. В результате их маркетинговая машина вылила на пользователей целый ушат «маркетинговых помоев», из которых только 20% имели отношение к истине. Да с тем, что SOA и BPM преследуют похожие цели, никто и не спорит. Но что с того? Разве это означает, что они должны слиться воедино? Мало ли в истории компьютерной техники было технологий, которые имели похожие цели? И что, они все конвергировали между собой? Отнюдь, скорее наоборот — убивали друг друга.

Так они и спорили всю ночь…

Авторы: Конечно же этот спор мы придумали, но мы уверены: это тот случай, когда искусство сильнее отражает суть происходящего, чем многочисленные примеры из жизни. При этом мы показали лишь наиболее поверхностный и грубый срез полемики вокруг понимания SOA — не более десяти процентов. Можете представить себе, что творится внутри оставшихся девяноста? Какие же выводы из этого можно сделать?

Первый и очевидный: проблема с пониманием сути происходящего налицо. И если сегодня кто-то говорит, что знает, что такое SOA, советуем сказать ему — не верю! Но почему имеют место столь разные точки зрения на одно явление? Рискнем предложить объяснение.

Второй, парадоксальный вывод: все они правы, но при этом слепы. По всей видимости, под видом шумихи вокруг SOA мы имеем дело со сложными и весьма глубинными изменениями в области построения корпоративных систем. Но мы не понимаем до конца сути этих изменений, а только подходим к этому пониманию. Что-то происходит, движутся какие-то глубинные пласты в представлениях об архитектуре корпоративных систем, и эти очень сложно фиксируемые явления на верхнем уровне выливаются в столь разнообразные интерпретации. Это как в том анекдоте про слепых, ощупывающих слона. Помните?

Только та история — анекдот, а в отношении SOA ситуация подается как нормальное положение дел. «Мы можем смотреть на SOA c разных точек зрения, и определение ее сути будет зависеть как от нашей текущей позиции, так и от конечных целей» — так написано в одной их книг по SOA. Но ведь это полный бред. Если нет единого взгляда на суть и значение происходящего, то нет и самого происходящего как единого целого.

Интересно, что слепые отчасти отдают себе отчёт, что объять слона таким образом нельзя. Например, одна уважаемая компания выделяет четыре слоя пользователей, каждый из которых понимает SOA по-своему. Даже страшно представить, какого же слона построят эти слепцы. Для фильма ужасов, наверное, подойдет.

Заметьте, что ситуация, когда к SOA предъявляются взаимоисключающие требования, отнюдь не редкость. Иногда кажется, будто идеи SOA возникают из представлений о чем-то идеальном: ИТ должны быть и жесткими, и мягкими, полезными и недорогими — дальше как про слона: толстыми и худыми, мощными и гибкими, похожими на змею и на колонну, смотря по чьему вкусу.

Эту точку зрения довели до абсурда те, кого в стиле нашей статьи мы можем назвать абстракционистами. У них свое определение SOA: это набор бизнес-методов, методов организации процессов и методов управления, предназначенных для улучшения ИТ-поддержки бизнеса и количественного измерения ценности ИТ. «SOA — это не технология, а средство оптимизации бизнес-процессов», — вещает другой поставщик-аб­стракционист. Что описывают такие определения? Всё, и поэтому как определение (а не как цель) они вообще не имеют смысла. Они похожи на картины абстракционистов: хочешь — видишь женское лицо, а хочешь — корову на поляне. И оба образа очень даже ничего.

Удивительно, что при всем при том маркетинговая машина вендоров разогналась настолько, что предпочитает всего этого не замечать. Все делают красивое лицо и говорят, что создаваемый ими слон поистине прекрасен. Квинтэссенцию этого маркетингового прессинга, как ни странно, выдали аналитики из Gartner. Они утверждают, что SOA уже преодолела период взлета-падения по кривой, иллюстрирующей отношение потребителей к технологии в ее жизненном цикле, и теперь обретает зрелость, выходит на «плато популярности». Даже непонятно, смеяться или плакать…