«Открытые системы»

В составе команды, которая прибыла на TechForum 2005, был ведущий специалист по стратегии и архитектуре Вадим Розенберг, который прокомментировал новации, связанные с появлением Oracle Fusion Architecture и Oracle Fusion Middleware.

В чем суть лозунга «Начать с середины»?

Я считаю его очень удачным, хотя любому понятно, что начать с середины нельзя. В Oracle, начав свой путь более двадцати лет назад и выйдя на нынешние позиции, смогли создать условия для нового старта, условно назвав его серединой. Мы создали самую передовую инфраструктуру хранения данных, теперь мы можем создать не уступающую ей инфраструктуру для доставки данных и интеграции приложений, для организации бизнес-процессов, которые используют имеющиеся или создают новые данные, для предоставления данных конечным пользователям.

Давайте пройдем по Oracle Fusion Architecture сверху вниз или снизу вверх…

Вадим Розенберг: «Наша задача состоит в том, чтобы ускорить процесс сборки приложений»

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

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

В чем состоит роль сервисной шины?

Способ доступа к объектам должен быть описан формально, в так называемом «контракте», чтобы потребителю были гарантированы заданные параметры качества доступа. Контракт обеспечивает не только функциональность сервиса, но еще и его потребительские свойства, например, время ответа и другие метрики, описывающие сервис. Роль шины данных состоит в обеспечении характеристик сервиса и выполнения условий контракта, а также динамического подключения требуемого сервиса. Под динамическим понимается замена одного сервиса другим. С точки зрения функциональности бизнес-процесса между такими сервисами нет заметных отличий, но, скажем, один сервис работает по протоколу HTTP, а нам, в силу каких-то условий более удобен протокол SMTP. Шина сервисов позволяет делать все это, не меняя бизнес-процессы.

Расскажите о стандартизации шин сервисов.

По своей логике шины сервисов очень похожи на аппаратные шины данных, но проблемы стандартизации здесь совершенно иные. На шину сервисов не распространяются какие-то общие отраслевые стандарты, каждый производитель может строить ее по-своему, важнее другое — стандартизованы должны быть те конечные точки, к которым она подключается. Скажем, шина сервисов Oracle поддерживает известные стандарты Web-сервисов, такие как SOAP и многие другие.

Шина сервисов реализует архитектуру взаимодействия «по событиям» (Event Driven Architecture), которая позволяет, в том числе, организовать обмен сообщениями по типу «опубликовать событие — подписаться на событие» (publish — subscribe). Этот тип обмена позволяет подписчику быть независимым от источника события и реагировать на само событие, обрабатывая связанные с ним данные. В случае, когда источниками и подписчиками являются бизнес-процессы, это свойство шины сервисов позволяет не вносить никаких изменений в бизнес-процесс, являющийся подписчиком, при появлении нового источника того же события, хотя он может иметь характеристики публикации события, отличные от других существующих источников этого события. Предположим, в некоей сети магазинов каждый из них имеет свой бизнес-процесс со своим интерфейсом, а их взаимодействие организовано через шину сервисов. В этом случае включение нового магазина в работающую систему взаимодействия не потребует внесения изменений в существующие бизнес-процессы, в отличие от случая реализации взаимодействия без шины сервисов.