Дэниэл Сeрейн живет во Франции, но защитил диссертацию в известном американском университете Карнеги—Меллона и занимает должность ведущего специалиста по интеграционной архитектуре в американской же корпорации Oracle. Возможно, именно благодаря этому культурному дуализму Серейн сумел стать признанным гуру в области современных технологий, сохранив классический европейский стиль мышления с присущим французам академизмом.

Способность к обобщениям заметно отличает Серейна от многих его заокеанских коллег, излагающих свои мысли исключительно в презентантационном стиле. Подтверждение этому можно найти, в частности, в его книге Middleware and Enterprise Application Integration, выпущенной в 2002 году издательством Springer-Verlag. В августе минувшего года Дэниэл Серейн, побывав в Москве, уделил несколько часов на беседу с редактором журнала «Открытые системы» Леонидом Черняком.

В ИТ-отрасли заканчивается период послекризисной рецессии, занявший примерно четыре-пять лет. Главное — изменилось отношение бизнеса к ИТ. В этом контексте меняется роль архитекторов информационных систем: основной фокус их внимания должен сместиться от технологий к задачам бизнеса. А роль технологий сводится к созданию среды, позволяющей менять динамику бизнес-процессов в условиях гетерогенности систем и приложений. Яркими символами перемен стали сервис-ориентированная архитектура (Service-Oriented Architecture, SOA), коммерческие grid-среды, приложения поддержки бизнеса, подобные BPM/BAM/BI, самоуправляемые компьютерные системы (autonomic computing). Но, как ни удивительно, до сих пор мне не встретилось ни одного материала, в котором они рассматривались бы как части единого целого. Каким образом Вы представляете целостную картину «нового мира»?

Я бы назвал современное движение в области ИТ «походом за Чашей Грааля», поскольку путь труден и не определен, а целью является скорее образ, нежели что-то конкретное. Но все же идти надо, и основная задача заключается в выборе верного направления. Вот о нем мы и поговорим.

Начнем с сервис-ориентированных архитектур. Их не стоит расценивать как сенсационное открытие. Разработка подобных архитектур стала закономерным результатом эволюционного процесса, начавшегося в 80-е годы с первых попыток построения распределенных систем на основе объектно-ориентированных моделей. Некоторое время назад появились распределенные системы следующего поколения, базирующиеся на двухкомпонентных моделях .Net и J2EE. Они капитализировали унаследованные от предшественников свойства, а их гранулярность увеличилась в связи с добавлением объектов, названных «компонентами». Таким образом, распределенные системы стали более гибкими, и была обеспечена возможность выполнения транзакционных операций.

Компонентная распределенная модель заняла надлежащее место во внутренних сетях предприятий, обеспечив взаимодействие гомогенных приложений. Но на следующем витке развития технологий, вызванном появлением Internet, обнаружились ее ограничения. Во-первых, в каждой из моделей задействуется свой коммуникационный протокол (RMI для J2EE, .Net Remoting для .Net), и, хотя их совместное использование возможно, оно неэффективно. Во-вторых, слишком сложна схема адресации; ее применению в среде Internet мешает необходимость централизованного присвоения адресов компонентам. В-третьих, структура сообщений является низкоуровневой. По сути, она соответствует структуре, используемой в языках программирования: те же целые числа, символьные переменные, числа с плавающей точкой. При этом не обеспечиваются должная гибкость, возможности добавления новых параметров и самоописания объектов. В-четвертых, можно отметить недостаточную надежность. Протоколы, по существу, синхронны и сильно связаны, что противоречит требованиям больших структур.

Возникла потребность в новом, более простом коммуникационном протоколе, и в ответ на нее был создан независимый протокол SOAP. В нем используются стандартная схема адресации с применением URL для идентификации объектов, транспортный протокол HTTP, данные в формате ASCII и язык XML, открывающий возможность самоописания объектов. Все производители признали язык WSDL стандартом описания интерфейса объектов нового типа, которые получили название Web-сервисов.

Уточним связь между Web-сервисами и SOA. Не слишком ли часто мы произносим «Web» вместе со словом «сервис»?

SOA поддерживается языком WSDL, в котором описание сервисов делится на интерфейс и оболочку. Интерфейс описывает, что должен содержать запрос, а оболочка определяет протоколы транспорта и данных. В настоящее время для поддержки Web-сервисов служат HTTP и XML (основа SOAP), но есть и другие способы реализации сервисной архитектуры, скажем RMI, .Net Remoting, JDBC, JCA или JMS.

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

Механизм оболочки освобождает от забот и хлопот, связанных с тем, как устроен тот или иной сервис, как он активируется и т.д. Хочу еще раз подчеркнуть, что сервисы в SOA не тождественны Web-сервисам и что существуют разные способы реализации SOA, а не только SOAP. Сейчас наиболее популярен стек стандартов, состоящий из WSDL, SOAP, XML и UDDI.

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

Как, по Вашему мнению, связана сервис-ориентированная архитектура с набирающими популярность концепциями сервисной шины предприятия (Enterprise Service Bus, ESB) и архитектуры, управляемой событиями (Event Driven Architecture, EDA)?

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

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

Что же касается SOA и EDA, они дополняют друг друга. SOA можно представить как модель «клиент-сервер», реализуемую в условиях слабой связанности. В архитектуре EDA отсутствует необходимость в стыковке между взаимодействующими компонентами. И компонент, передающий сообщение о событии, ничего не знает о получателе сообщения.

Как grid-концепция связана с общей канвой Ваших рассуждений?

Идет сложный процесс переосмысления того, что такое grid, и есть разные точки зрения по этому поводу. В принципе, можно выделить три основных типа подобных систем: первый — grid-среды данных (имеются в виду данные, рассредоточенные между разными организациями и распределенные географически), второй — научные grid-среды (с них все начиналось, и по замыслу они должны собирать гетерогенные вычислительные ресурсы в единый пул), третий — корпоративные grid-среды. Между ними очень мало общего. В последнем случае философская идея grid низведена до потребностей предприятия. Она упрощена настолько, что предполагается наличие централизованного управления и обеспечения безопасности, а это противоречит идее научные grid-среды. Предназначение подобных «вырожденных» решений состоит в том, чтобы разные приложения могли разделять общие аппаратные ресурсы. Очень важно, что эти ресурсы тоже должны быть представлены в форме сервисов.

Идея grid предполагает идентификацию и стандартизацию набора сервисов программного обеспечения промежуточного слоя (middleware services) для совместного координированного использования общих распределенных ресурсов. Такие grid-среды базируются на концепции SOA, и в этом случае сервисы работают поверх компьютерной сети, но на уровень ниже приложений. Если рассматривать grid с этих позиций, можно сказать, что работа в данном направлении только начинается. Пока созданы лишь два стандарта, Web Services Resource Framework (WSRF) и Web Services Event Notifications (WSEN).

Отношения между grid и SOA еще полностью не установились. Научному сообществу ближе идея Web-сервисов, и оно ориентируется на архитектуру SOAP, поскольку последняя может быть распространена на Internet. Корпоративное сообщество задействует для реализации grid локальные кластеры и не нуждается в применении SOAP. Например, при реализации grid средствами Oracle RAC и Oracle Database 10g используются скоростные коммуникационные протоколы SQLNet и STREAMS.

Какой Вы видите связку сервисных архитектур с технологиями, непосредственно поддерживающими бизнес?

Подлинная задача информационных технологий состоит в помощи бизнесу. Если присмотреться внимательно, можно увидеть, что технологии, используемые для описания, выполнения бизнес-процессов и управления ими, базируются на идеях сервисов. Сегодня чаще всего упоминаются Business Process Management (BPM) и Business Activity Monitoring (BAM). BPM позволяет моделировать бизнес-процессы, интегрировать их с информационными системами, связывать с системами партнеров и заказчиков, и для этого используется язык описания бизнес-процессов BPEL. Мониторинг процессов на основе получаемых от датчиков данных осуществляется средствами BAM. Непосредственно на модели SOA базируются системы BPM. На каждом шаге выполнения модели, описанной на BPEL, вызывается тот или иной сервис. Он может быть реализован как Web-сервис, компонент Java или .Net, как процедура PL/SQL или вызов обычного приложения с помощью адаптера JCA (Java Connector Architecture).

Получается, что SOA делает всю корпоративную информационную систему общим организмом, объединенным сервисами разного рода?

Уже сейчас можно говорить о формировании четырехуровневой сервисной модели. Другими словами, можно представить корпоративную систему как SOA, состоящую из Business Layer (четвертый уровень), Application Layer (третий), Infrastructure Layer (второй) и Provisioning Layer (первый).

В этой модели сервисы, выраженные на языке BPEL (четвертый уровень) и выполняемые соответствующими средствами (BPEL Engine), поддерживаются сервисами уровня приложений (третий уровень), то есть приложениями, которые оформлены в виде сервисов. На втором уровне работают инфраструктурные сервисы, в том числе серверы приложений и ESB. Они обеспечивают обработку сообщений, безопасность и преобразование данных. Нижний уровень можно назвать физическим; на нем действуют сервисы, предоставляющие доступ к физическим ресурсам, в том числе к ресурсам grid, процессоров и систем хранения.

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