ИНТЕГРАЦИЯ ПРИЛОЖЕНИЙ

В конце ноября в Москве прошла корпоративная конференция Microsoft "Платформа 2004", одной из ключевых тем которой был рассказ о продукте BizTalk 2004, предназначенном для интеграции корпоративных приложений. Во время этого мероприятия я встретился с Эриком ван Бивером, главным архитектором приложений в европейской штаб-квартире Microsoft, и побеседовал как об общих проблемах интеграции, так и о применении BizTalk.

Эрик ван Бивер

PC Week: Я начну с вопроса, который часто задают, когда речь заходит о платформе Microsoft вообще и BizTalk Server в частности. Когда вы интегрируете корпоративные приложения, то, как правило, приходится соединять технологии из разных миров, и платформа Microsoft только один из них. Например, нужно связывать программы на базе Java, CORBA и т. д. В то же время BizTalk ориентирован на работу преимущественно в среде Windows. Как вы решаете эту проблему?

Эрик ван Бивер: Интеграция приложений может идти двумя способами: intrusive (с вмешательством в их внутреннюю структуру) и non-intrusive (с минимумом вмешательства). Типичные примеры платформ для первого класса - это TIBCO и IBM WebSphere MQ. Если вы хотите интегрировать приложение при помощи IBM WebSphere MQ, то придется устанавливать IBM WebSphere MQ на всех машинах, на которых функционируют интегрируемые приложения. BizTalk Server исповедует философию non-intrusive integration. Мы пытаемся сделать так, чтобы он работал сам по себе, по возможности не требуя дополнительного ПО на машины, где работают интегрируемые приложения.

Причина этого совершенно очевидна: если попросить корпоративного заказчика, желающего интегрировать свою "боевую" систему SAP R/3, установить на сервер с ней еще одну программу, то он отнесется к этому отрицательно. Еще одна причина заключается в том, что весь мир движется в направлении Web-сервисов, а Web-сервисы по определению являются технологией класса non-intrusive.

PC Week: На мой взгляд, не стоит сравнивать напрямую BizTalk с WebSphere MQ, скорее нужно сравнивать его с IBM WebSphere Message Broker, IBM WebSphere или Interchange Server с BizTalk. В любом случае, когда вы пытаетесь соединить что-то с BizTalk, Message Broker или Interchange Server, вам обычно требуются коннекторы.

Э. Б.: Все зависит от конкретной ситуации. Например, в системе CRM фирмы Siebel начиная с версии 7.0 вся функциональность представлена как Web-сервисы. Поэтому там не требуется промежуточного ПО. SAP R/3 также интегрируется через SAP Net Weaver, и уже есть возможность выводить всю функциональность без соединительного промежуточного программного обеспечения - как Web-сервис. Поэтому в данных случаях не требуется устанавливать какую-то дополнительную программу для интеграции.

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

PC Week: И все же большинство приложений не приспособлены к архитектуре Web-сервисов, и применение адаптеров неизбежно. Распространено мнение, что если работать с BizTalk, то придется использовать и XML. Но некоторые вендоры, скажем Borland, не считают его эффективным с точки зрения расходования вычислительных ресурсов систем, предлагая более производительные способы передачи данных между приложениями.

Э. Б.: Люди, которые говорят о подобных "более эффективных" способах, возвращают нас в прошлое - ведь эти способы были и до появиления XML. Например, был DCOM - двоичная система, по определению более производительная, чем XML: размеченный при помощи XML файл содержит больше информации, которую нужно передавать, и соответственно на это уходит больше времени и ресурсов системы. То есть чистая производительность DCOM всегда была выше, чем у XML. Однако все имеет свои положительные и отрицательные стороны: при использовании DCOM возникают трудности в области интеграции, так как вы должны знать двоичные коды, глубоко в них вникать. А XML - текстовый формат, он более открыт и, несмотря на более низкую производительность, позволяет легче интегрироваться. Чудес не бывает, за все приходится платить.

PC Week: Но даже с точки зрения разработчика XML удобен далеко не всегда.

Э. Б.: Опять-таки, если я в среде .NET пишу приложение и мне нужно вызвать другой компонент, то его можно вызвать либо как Web-сервис, либо через функцию .NET Remoting (она позволяет сделать вызов в двоичном формате). Вы сами выбираете, что вам необходимо: работать с высокой производительностью в двоичном формате (тогда вы варитесь в собственном соку, но интеграция приложений затруднена) или работать открыто, с хорошей интеграцией, но за счет потери производительности.

PC Week: Есть мнение, что стратегия разработки полностью компонентного программного обеспечения потерпела неудачу. Слишком много связей между частями, компоненты трудно сделать независимыми друг от друга. Поэтому-то приложения по-прежнему монолитны и лишь часть своего функционала делают доступным внешнему миру. Задача Web-сервисов аналогична задачам макроязыков - в основном в связывании логически крупных программных блоков, но не отдельных мелких компонентов. Согласны ли вы с такой точкой зрения?

Э. Б.: Я не совсем согласен с этим утверждением, потому что все неудачи компонентного программирования, компонентного подхода происходят из-за отсутствия платформы для выполнения бизнес-процесса (business process platform). Сейчас разработчики, создав компоненты, обязательно должны написать и дополнительный код для того, чтобы их состыковать и построить в итоге нечто цельное, ведь компонент еще не есть приложение, это лишь некий строительный кирпичик. И здесь как раз необходима платформа дирижирования бизнес-процессом, которой, в частности, является BizTalk Server 2004. Он будет представлять среду исполнения (run-time environment), где все прозрачно интегрируется и уже не нужно писать никаких новых кодов. В этом направлении двигаются и другие крупные поставщики программных средств.

PC Week: Но если вы поставляете приложение в виде набора компонентов, то, следовательно, перекладываете задачу их интеграции на конечного пользователя. Ему придется иметь дело с малознакомым набором тысяч различных компонентов и интерфейсов. Связать их очень сложно. Как с этим быть?

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

PC Week: Тут возникает вопрос цены. Когда заказчику приходится соединять компоненты в единую систему, стоимость решения сильно возрастает.

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

PC Week: Похоже, подтверждений этому мало. Даже приложения Microsoft (скажем, офисные) не строятся по такому принципу - они имеют унаследованный код, с которым приходится считаться. То же самое касается ERP- и CRM-систем, это сложные приложения, компоненты которых сильно взаимосвязаны.

Э. Б.: Здесь есть два момента. Первое - то, что люди не делятся друг с другом, такова человеческая натура. И второе: Web-сервисы еще не заработали в полной мере, они только-только начинают появляться.

Их дебют на платформе Microsoft - это BizTalk Server 2004. Там будут механизмы исполнения бизнес-правил и workflow, ориентированного на участие человека. Конечно, являясь частями BizTalk Server 2004, данные механизмы могут вызываться откуда угодно - это настоящие Web-сервисы. К ним можно обратиться даже из Java2 Enterprise Edition, если необходимо.

О Web-сервисах много говорили, но их настоящая реализация появляется на наших глазах: Jupiter (это кодовое название набора средств интеграции Microsoft), семейство Web-сервисов в BizTalk Server 2004. Созревание Web-сервисов, конечно, требует времени. По сути, есть только стандарты XML, SOAP, WSDL, UDDI, но Web-сервисы не обеспечивают таких важных вещей, как асинхронные взаимодействия, многофазная транзакционность и пр. [об этом можно почитать в PC Week/RE, N 36, с+]. ?

PC Week: Если мы взглянем на продукты Oracle, IBM или, к примеру, технологию Siebel Universal Application Network, мы увидим, что они исповедуют высокоуровневый подход - концепцию обобщенных бизнес-объектов. Этого нет в BizTalk. Почему?

Э. Б.: Мы сейчас большое внимание уделяем стандартизации, в частности стандарту Rozetanet, который поддерживает Cisco, Intel, финансовые учреждения. Этот стандарт не только определяет формат сообщений, но и типовые бизнес-процессы. BizTalk является основой для выполнения этих процессов, например, тот же Siebel UAN использует BizTalk как инфраструктурный уровень.

PC Week: Хотелось бы еще узнать ваше мнение о том, насколько универсальна стандартизация бизнес-процессов.

Э. Б.: Вообще Rozettanet вполне может быть всемирным стандартом, поскольку он не влияет, допустим, на конкретные системы бухгалтерского учета, но в основном этот стандарт сейчас применяется на странах Дальнего Востока и в США. Потому что там высокотехнологическая промышленность развита гораздо лучше, чем в Европе. Его поддерживают американские компании Cisco, Intel, имеющие на Дальнем Востоке сборочные предприятия. Rozettanet, конечно, станет мировым стандартом, но будут и локальные бизнес-процессы, что дает дополнительные возможности для местных разработчиков.

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

PC Week: Важно то, что не только бизнес-процесс изменяется от страны к стране, но и сами данные изменяются. Даже внутри одной компании запись о клиенте торгового отдела отличается, скажем, от записи о клиенте HR-департамента.

Э. Б.: Совершенно верно. В BizTalk Server есть брокер сообщений, механизм исполнения workflow, средства бизнес-анализа. С точки зрения анализа, конечно, заказчик разный: для продавца, для специалиста по маркетингу, специалиста по поддержке и т. д. В BizTalk Server у нас есть возможность представить разные взгляды на заказчика: взгляд на заказчика специалиста по маркетингу, продавца, специалиста по поддержке - каждый из них будет видеть именно своих заказчиков, т. е. иметь вид на данные со своей точки зрения.

PC Week: В заключение части беседы, посвященной общим вопросам, хотелось бы спросить следующее. Как вы оцениваете в процентном соотношении востребованность со стороны заказчика средств, ориентированных на интеграцию данных, и средств интеграции, ориентированных на бизнес-процессы?

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

Анализируя накопленные данные, можно сказать следующее. В BizTalk 2002 был механизм Orchestration, но 75% всех проектов использовали только функционал обмена сообщениями, и лишь 20-25% применяли Orchestration в минимальном объеме. Мы считаем, что в 2004 г. на основании данных, которые мы имеем о заказчиках, удельный вес интеграции, ориентированной на бизнес-процессы, возрастет. Во многом благодаря тому, что уже есть механизм выполнения бизнес-правил и human workflow.

PC Week: У меня есть еще несколько вопросов, посвященных деталям. Но главный касается безопасности. Когда вы занимаетесь интеграционным проектом, вы должны включить в него все аспекты безопасности, безопасность должна стать неотъемлемой частью. Каким образом этого можно достичь при помощи BizTalk?

Э. Б.: Это очень технический вопрос. С точки зрения безопасности в BizTalk Server 2004 многое есть. Во-первых, это средства single sign on, т. е. вы вводите пароль и логин один раз, и далее вас автоматически идентифицируют во всех системах, что существенно упрощает работу. Но это просто. Посложнее будет реализация B2B-взаимодействия. Для этого в BizTalk Server 2004 в стандартном комплекте поставки поддерживается PKI (Public Key Infrastructure - инфраструктура публичных ключей): если вам приходит сообщение, зашифрованное при помощи этих ключей, да еще с цифровой подписью, то вы на базе стандартного продукта BizTalk Server 2004 можете идентифицировать отправителя, расшифровать сообщение, определить аутентичность подписи и т. д.

Еще в BizTalk Server 2004 поддерживается концепция хостов. Хост - это процесс Win32. В BizTalk Server 2004 есть отправитель, получатель и механизм управления бизнес-процессом в середине. Так вот, каждый из этих трех компонентов может представлять собой отдельный хост, т. е. отдельный процесс. Это дает повышенную надежность, и если что-то происходит неправильно в каком-то одном процессе, то сбой не влияет на другие процессы и работы. С точки зрения безопасности также возникают границы безопасности: если хост 1 отправляет сообщение хосту 2, то прежде чем хост 2 получит это сообщение, он должен проверить, аутентифицировать отправителя. Это создает дополнительные границы, позволяющие на каждой из них обеспечить безопасность.

Поскольку весь обмен данными происходит через четко определенные каналы, то достаточно добавить еще один компонент. После утверждения стандарта обеспечения безопасности Web-сервисов WS Security мы просто добавим нужный компонент в BizTalk Server. С архитектурной точки зрения это сделать легко.

PC Week: Спасибо за беседу.