Минувшим летом корпорация Oracle приобрела молодую, но хорошо известную компанию Collaxa, специализировавшуюся на программном обеспечении промежуточного слоя. За четыре года своего существования она успела войти в элиту софтверного бизнеса и вступить в ряды лидеров одной из наиболее актуальных областей информационных технологий — интеграции приложений средствами языка BPEL. Этому в немалой степени способствовал основатель Collaxa Эдвин Ходабакчан — человек, «широко известный в узких кругах» ведущих разработчиков программных систем, который прежде был главным архитектором Netscape/iPlanet. В составе руководства Collaxa были и другие яркие личности, в том числе Адам Босуорт, ранее — один из ведущих экспертов Microsoft, позже — вице-президент BEA, а ныне — сотрудник Google.
Заинтересованность в сделке со стороны Oracle очевидна. Приобретение Collaxa позволило компании, активно диверсифицирующей свои предложения, без промедления выпустить Oracle BPEL Process Manager 2.0. Благодаря этому, она смогла в одночасье войти в клуб ведущих вендоров, поставляющих решения для сервис-ориентированных архитектур (service-oriented architecture, SOA).
В октябре Эдвин Ходабакчан побывал в Москве на технологическом форуме Oracle в качестве вице-президента корпорации. Он согласился ответить на вопросы редактора «Открытых Систем» Леонида Черняка.
В числе причин быстрого взлета Collaxa можно назвать и ту снайперскую точность, с которой компания сделала ставку на интеграцию приложений с использованием Web-сервисов и язык BPEL. Чем, по Вашему мнению, объясняется повышенный интерес к BPEL в последние годы, способствовавший успеху Collaxa и Вашему карьерному росту?
В совокупности Web-сервисы и язык Business Process Execution Language for Web Services позволяют существенно повысить экономическую эффективность интеграции приложений. Прежде, несмотря на существование множества альтернативных технологий, она была чрезвычайно низкой, поэтому такая интеграция не могла стать массовой. С появлением средств на основе BPEL, в частности Oracle BPEL Process Manager, появилась возможность для применения интеграции в широких масштабах. И ранее было понятно, что создание согласованных между собой бизнес-процессов из разрозненных приложений обеспечит предприятию более высокую конкурентоспособность, но этот потенциал было сложно реализовать в рамках J2EE Connector Architecture (JCA), Java Messaging Service (JMS) или технологий, предлагаемых консорциумом RosettaNet.
Web-сервисы в сочетании с BPEL могут сыграть такую же роль в отношении интеграции приложений, как стандарт SQL, революционизировавший доступ к структурированным данным, или HTTP и HTML, обеспечивающие доступ к контенту и приложениям. В перспективе Web-сервисы позволят трансформировать Internet в распределенную платформу, обеспечив простое надежное взаимодействие гетерогенных систем. Можно сказать, что Web-сервисы — это путь к grid.
Однако до появления BPEL не было единого стандарта верхнего уровня, который бы собрал вместе XML Schema, SOAP, WSDL и другие известные стандарты. С технической точки зрения, язык BPEL представляет собой стандарт пересылки XML-сообщений удаленным сервисам и получения асинхронных сообщений от них, оперирования событиями и реагирования в исключительных ситуациях. Он позволяет создавать конструкции, сочетающие в себе наборы сервисов в форме бизнес-процессов. Очень важно, что поддержка BPEL такими компаниями, как Oracle, Microsoft, IBM, SAP, Siebel, BEA и рядом других достигла необходимой критической массы.
Тему слабой связанности асинхронных приложений мы уже как-то обсуждали с Вашим другом и соратником Адамом Босуортом. Каковы Ваши взгляды на этот предмет и какими соображениями Вы можете поделиться с теми, кто решит строить асинхронные архитектуры?
Я вполне согласен с Босуортом в том, что в информационной индустрии обнаруживается непрерывное и вполне устойчивое движение от интеграции приложений классического стиля, основанной на традиционном вызове удаленных процедур (remote procedure call, RPC), к интеграции асинхронного стиля, базирующейся на передаче документов (document-based integration). Все больше и больше разработчиков приходят к выводу, что только асинхронные сервисы могут стать ядром новых слабосвязанных архитектур, использующих обмен сообщениями. В том профессиональном сообществе, которому я принадлежу, практически все разработчики осознали суть происходящей смены парадигмы и те выгоды, которые они получают.
К числу важнейших достоинств асинхронных архитектур следует отнести, во-первых, надежность, поскольку мы избавляемся от общей хрупкости конструкции, присущей синхронности. При жестких синхронных связях в случае поломки слабейшего звена может рухнуть вся конструкция. Во-вторых, это масштабируемость. Как свидетельствует опыт тех, кто уже реализовал интеграцию приложений с помощью средств обмена сообщениями, такой способ особенно эффективен при объединении разнородных процессов. В-третьих, появляется возможность включения человека в цикл управления. Практика показывает, что крупные интеграционные проекты оказываются наиболее эффективными, если допускают вмешательство человека в автоматизированный процесс. А процесс, предполагающий человеческую реакцию, не может быть синхронным по определению.
Вот несколько советов тем, кто решит создавать асинхронные системы с использованием BPEL. Во время проектирования интерфейса следует ориентироваться на обмен сообщениями, причем не только при передаче данных сервисам, но и при получении ответных данных. При передаче в сервисы можно описывать документы с использованием XML Schema, а при организации обратного потока опираться на WSDL и PartnerLinkTypes (расширение BPEL, используемое в WSDL. — Л.Ч.).
Это может прозвучать как тавтология, но асинхронный режим порождает проблему обеспечения синхронизации (точнее, координации в процессе обмена сообщениями), явно отсутствующую при синхронном подходе. Она проявляется в том, что для реагирования на входное сообщение необходимо знать адрес, по которому нужно отослать сгенерированное сообщение, и то, как последнее коррелируется с входным инициирующим сообщением. В BPEL для этой цели есть спецификация WS-Addressing.
Другая проблема — обеспечение надежности передачи сообщений с использованием не поддерживающих отказоустойчивости протоколов, например, HTTP. Средства WS-ReliableMessaging гарантируют прием каждого переданного сообщения. Еще одна проблема — целостности транзакции сообщений — решается средствами WS-Transaction. В целом можно утверждать, что совокупность стандартов BPEL4WS, SOAP, WSDL, WS-Addressing, WS-Transaction и других может обеспечить высокое качество асинхронных архитектур.
Расскажите, пожалуйста, о продукте, который теперь называется Oracle BPEL Process Manager.
Из его названия следует, что Oracle BPEL Process Manager позволяет организациям моделировать и внедрять бизнес-процессы с применением BPEL. Этот язык — краеугольный камень организации оркестровки и выполнения сервисов в сервис-ориентированных архитектурах. Стандарт BPEL можно назвать «корпоративной проектной заготовкой» (enterprise blueprint), которая позволяет снизить сложность и повысить скорость реализации интеграционных проектов. По поводу конкретной реализации Oracle BPEL Process Manager добавлю, что она является первой версией BPEL-машины, на 100% соответствующей стандарту, доведена до уровня продукта и готова к использованию уже сегодня.
Что представляет собой Oracle BPEL Process Manager на практике?
Для того, чтобы создать работающую систему, основанную на Web-сервисах, нужно пройти два этапа работы с сервисами — публикации и оркестровки. Публикация сервисов в основном означает предоставление возможности пользования сервисами с применением интерфейсных протоколов. Оркестровка, по сути, является сборкой сервисов в единое бизнес-приложение и их координацией.
Потребность в продуктах, подобных Oracle BPEL Process Manager, обусловлена тем, что логика оркестровки довольно сложна и должна соответствовать требованиям окружающей среды. Для публикации используется некая существующая функциональность (скажем, компонент системы ERP, традиционное приложение либо компонент, созданный с применением Java или .Net), и функциональность делается доступной через сеть. Есть стандарты, описывающие, как создать интерфейс к этой функциональности (WSDL) и модель данных (XML и XML Schema). Они достаточно гибки, чтобы поддерживать любой протокол. Можно сказать, что опубликованный сервис становится строительным блоком, способным обмениваться со своим окружением входными и выходными XML-сообщениями, хотя реальный обмен сообщениями намного сложнее, он опирается на HTTP, JMS, JCA, Java и SMTP.
Предназначение BPEL заключается в том, чтобы облегчить прохождение всех этапов, в том числе создание компонентной модели на основе Web-сервисов и WSDL, XML-модели данных и координированного потока управления. Oracle BPEL Process Manager является удобным инструментом разработчика, который позволяет проектировать, внедрять бизнес-процессы и управлять ими на основе BPEL. Соответственно, он включает в себя BPEL Designer, обеспечивающий графический интерфейс к BPEL-процессам, ядро, которое представляет собой BPEL-машину, считающуюся сегодня одним из наиболее эффективных BPML-серверов. В состав Oracle BPEL Process Manager входят встроенные интеграционные сервисы, «заготовки» для связи с SOAP и другими протоколами, а также консоль BPEL Console, поддерживающая интерфейс в стиле Web.
Вам не кажется, что есть очевидное противоречие между заявлениями известных «евангелистов» BPM о важности моделирования бизнес-процессов, о революционных математических основаниях BPM и тем, что средства и методы, которые сегодня предлагает BPEL, по большому счету, не отличаются радикализмом?
Да. Я неплохо знаком и с сетями Петри, и с пи-исчислением Робина Милнера, которым особенно дорожат те, кого вы назвали евангелистами. Я высоко ценю проделанную Ассафом Аркиным работу по интеграции этих математических аппаратов в язык BPML. Но существуют высокие материи и реальная жизнь, а между ними не всегда есть прямая связь. Скажите, многие ли программисты знают о существовании машины Тьюринга или лямбда-исчисления Черча? Я даже не говорю о способности объяснить, что они собой представляют. Формальные основания программирования известны и доступны для понимания лишь избранным, имеющим достаточную математическую культуру. Но их меньшинство, а индустрия программного обеспечения вынуждена ориентироваться на большинство. Не исключено, что именно поэтому многие чрезвычайно интересные проекты остались на обочине. Надо быть реалистом: сейчас до массового сознания необходимо донести то, что возможно, а дальше — посмотрим.
<>bКак специалисту по автоматическому регулированию и кибернетике (правда, в прошлом) мне кажутся чрезвычайно наивными рассуждения о моделировании и автоматизации управления в связи с BPM. У меня невольно возникает следующая аналогия. Представьте, что Норберт Винер сосредоточился бы не на создании принципов управления с обратной связью, а на совершенствовании отдельных компонентов зенитных систем и их интеграции (скажем, той же оркестровке или хореографии) в единую систему. Была бы при этом решена поставленная задача?
Вы попали в одну из самых болевых точек. Действительно, выросло не одно поколение специалистов, к которым я отношу и себя, совершенно не знающих кибернетики. Это колоссальная проблема, в том числе, образовательная. Я не думаю, что она будет преодолена в обозримом будущем, поскольку, повторяю, мы живем в реальном мире, где следует делать то, что нам под силу сейчас. Пока мы еще не можем говорить о создании автоматизированных систем управления предприятиями, работающих в режиме реального времени и аналогичных системам управления технологическими процессами, поэтому кибернетические методы не востребованы. Но, когда мы подойдем к этому рубежу, ситуация может измениться.
