Влад Боркус
Перечитав все комментарии, которые были сделаны в публикациях про SOA на ИТ Блогз, я обнаружил, что во всей нашей дискуссии был фундаментальный изъян. Начиная говорить про SOA, мы почти немедленно переходили на обсуждение веб-сервисов. В целом это не удивительно -- мы окружены вендорской пропагандой, из которой другой вывод сделать сложно. И все же веб-сервисы и SOA -- это не одно и то же.
И не только потому, что можно построить кучу веб-сервисов, и не внедрить у себя в итоге SOA. Этот тезис, безусловно, совершенно справедлив, но лишь чуть приближает к истине.
И не потому, что SOA -- не равно ESB, о чем тоже много говорилось.
А потому, что SOA -- это вообще не про веб-сервисы. Т.е. как бы совсем не про то.
Если говорить формально, то SOA -- это некоторая концепция реинжиниринга и развития корпоративного программного ландшафта. Упоминания этого термина можно встретить где-то в 1996 году у Гартнера. Тогда эти идеи в практической плоскости соотносились с компонентными технологиями.
С тех пор этот набор идей оброс неким опытом и набором где-то использованных приемов, которые в совокупности носят красивое название SOA Governance.
Появились XML и веб-сервисы, и оказалось, что эти идеи неплохо этой технологией дополняются.
Компоненты SOA
В основе SOA действительно лежит понятие сервиса, хотя не только его. Другими компонентами SOA являются фронт-энды приложений, репозиторий описаний сервисов, сервисная шина.
Ключевым для SOA являются наличие сервисов, ориентированных на деловые задачи. В SOA могут быть и масса других сервисов (трансформации, авторизации, и т.п.), но они вторичны.
Главное, что основные сервисы предоставляют каждый какой-то законченный деловой функционал. Крупный блок этого функционала. Скажем, сервис может предоставлять функции по работе с контрактом или с информацией о сотруднике.
В CORBA, EJB приложение строится из множества маленьких кирпичей. В SOA -- из малого количества больших.
В идеале бизнес-сервис должен предоставлять законченную функциональность по работе с сущностью, которой он взялся управлять. Например, в организации у нас есть только один
сервис по управлению контрактами. Иначе говоря, важное отличие сервиса от объекта CORBA -- это его изолированность от других сервисов.
Хотя в реальной жизни избежать даже корреляции сервисов не всегда удается, в идеале он должен быть совсем изолированным, и отвечать за все ресурсы, находящиеся под его управлением. Т.е., скажем, если у нас есть сервис, отвечающий за заказы, то изменить заказ в рамках SOA позволительно только одним способом -- через этот сервис. (Вспомним, что SOA -- это про организацию работ).
Чтобы добиться такой изолированности, борцы за SOA-веру предлагают проводить декомпозицию приложений. Или, когда это не возможно, строить так называемые «фасады» -- независимые сервисы, обращающиеся к одному или нескольким нижележащим системам. И работать потом через них.
Ключевым качеством сервиса является его описание. В описании сказано, что за интерфейс (функции) сервис имеет, приведен контракт (на каких условиях возможен доступ), и прочее -- кто его состряпал, какая версия, кто может менять сервис, когда этот сервис доступен, какая у него нагрузочная способность. Это описание совсем не обязательно должно быть на WSDL, например оно может быть на IDL или даже в MS Word. Главное, чтобы оно было.
Естественно, если описание -- в машино-распознаваемом формате, то использовать сервис потом намного удобнее.
Сами сервисы могут быть реализованы в рамках родной инсталляции SOA на разных технологических платформах -- WS, Java, .Net, CORBA. Более того, идея SOA как раз и состоит в том, чтобы обезопасить ИТ-инфраструктуру от смены поколений информационных технологий и стыковать плохо совместимые унаследованные технологии. Скажем, идеологи SOA открыто говорят, что SOAP когда-то отомрет, а ИТ надо будет и дальше жить. Требуется только, чтобы сервисы отвечали формальным требованиям SOA.
Работают с сервисами так называемые фронт-энды -- по большей части клиентские приложения разного сорта. Но могут работать и так называемые процессные сервисы, которые инкапсулируют оркестровку делового процесса. Можно также представить в этом контексте и другие сервисы - деловые правила.
Выше я также опустил так называемые технологические сервисы, к которым, например, относятся адаптеры. И сервисы, расширяющие функциональность нижележащей системы.
***
Все описания сервисов (описание интерфейса и контракт) обязаны храниться в репозитории.
Если это формальные описания, то система будет более конфигурируемая. Но, стоит заметить, что полноценные репозитории более сложны, а важны больше для B2B-среды, а не контролируемой корпоративной среды.
Но репозиторием может быть, и склад word-документов в файловой системе (это, конечно, экстремальный случай). В конце концов главный элемент в рамках SOA -- это корпоративный разработчик.
Здесь важны два момента. Описание всех интерфейсов должно быть унифицировано, и репозиторий должен быть центральным. Разработчик или динамически конфигурируемый клиент обращаются только к репозиторию, чтобы почерпнуть описания. Иначе -- SOA распадется.
Последний компонент SOA -- это шина сервисов. Это -- не обязательный компонент SOA. И уж, конечно, совсем не обязательно -- это ESB.
Главной задачей шины является технологическа стыковка систем на ее концах. Т.е. если с одной стороны у нас находится SOAP, а с другой -- CORBA, то шина должна обеспечить преобразование формата вызова от одной системы к другой. Например, коммутацию XML-полей на методы CORBA. Мы это можем сделать, так как у нас есть «нейтральное» описание сервиса.
В принципе, в рамках SOA может существовать несколько параллельных шин, скажем она -- асинхронная, а другая синхронная. Или идентичные шины в географички разных филиалах.
Проблемы
Как легко понять, у SOA много проблем. Транзакционной целостности очень сложно добиться, собрав систему из кубиков -- компенсационные шаги очень запутаны. Есть несколько теорий, как это надо делать, но все они имеют большие издержки. Хотя ясно, что задача не решается в общем случае в принципе.
Есть проблемы с тем, как строить безопасность в такой системе -- на каком уровне должна проводиться аутентификация, авторизация. Особенно все сложно в условиях, когда нельзя сделать общий identity сервис. Опять, есть у людей идеи, но выбор -- по обстоятельствам.
Есть проблемы, о которых упоминал Анатолий, -- как быть с бизнес-объектами. Хотя самый очевидный путь -- это стандартизовать их на уроне шины. Также бизнес-объекты по сути сами являются готовыми сервисами.
Есть в конце концов проблема организационная (все расползается) и с архитекторами (чтобы создать такую архитектуру нужны архитекторы экстра-класса, а их в мире на каждую фирму не наберешь).
Что касается успехов. Есть проекты, причем достаточно большие. Хотя их беглый анализ местами не внушает оптимизма -- в одних исходная задача была относительно простая, в других -- решение получилось кривое, и его переделывают.
****
PS. Написать этот текст меня подстрекал Анатолий, так что вся ответственность за последствия лежит на нем. Особенно если там отдельные вендор будут кидать в меня камнями :))
Но если статью на форуме сочтут приличной, то я ее попробую доработать и пристроить в какой-нибудь ИТ-журнал.
В жизни много чего было. Закончил Физтех, работал и программистом, и в науке, защитил диссертацию, работал в PCWeek обозревателем/потом зам. гл. редактора, закончил Школу ИТ-менеджмента АНХ. Последние пять лет занимаюсь аналитическими (в основном технологическими) исследованиями рынка и предтендерным и тендерным консалтингом: составлением требований, сравнением и выбором систем, разработкой архитектур, утряской проектов с бизнеc-заказчиками, сопровождением внедрений. Главным образом работаю с коллегами в области интеграции приложений (EAI, SOA, MOM и т.п.) и документооборота. Основал проект KONNASI. В общем смотрите www.konnasi.ru -- там немного про это написано.