Enterprise Partner, 20 марта 2001 г.
Беседовал Сергей Костяков
Enterprise Partner: Какова в настоящее время стратегия разработки продуктов для корпоративного рынка и в чем особенности деятельности вашей компании по сравнению с другими крупными игроками рынка?
Лоран Серафин: Сейчас в составе нашей компании есть несколько подразделений, занятых разработкой различных продуктов. Одно из них занимается развитием C++ Вuilder, Delphi и Kylix - инструментального средства для операционной системы Linux. Второе подразделение работает над совершенствованием средства Java-разработки JBuilder. И наконец, третье занимается вопросами ПО промежуточного слоя (middleware) и средствами управления. Основные продукты этого подразделения - сервер приложений Borland AppServer, брокер объектных запросов Visibroker и система управления прикладной объектной инфраструктурой AppCenter.
Есть еще два подразделения - это InterBase и подразделение, созданное на перспективу. Сфера интересов последнего лежит в области ASP (application services provider) в применении к разработчикам корпоративных систем - хостинг и предоставление различных сервисов для разработчиков через Сеть, с использованием механизмов подписки.
Уникальная особенность нашей компании состоит в том, что мы объединяем три составляющих: инструментарий разработки, средства развертывания корпоративных приложений и средства управления ими. При этом, что очень важно, у нас нет приверженности какой-либо одной платформе. Например, компания Sun имеет полный спектр решений, но все их разработки привязаны к платформе Java. Microsoft также может предложить все те средства, которые я перечислил, однако они замкнуты на ОС Windows. Мы же стараемся поддерживать все то, что принято индустрией и является промышленным стандартом.
EP: Насколько важно поддерживать целую гамму промышленных стандартов в средствах разработки и продуктах промежуточного ПО, исходя из реальных потребностей рынка (с учетом того, что это требует от компании значительных ресурсов)?
ЛС: Инфраструктура middleware критична для развития современной инфраструктуры бизнеса. В этой области Borland предлагает сервер приложений AppServer. Несколько лет назад, когда я занимался непосредственно разработкой, при решении вопросов интеграции различных приложений упор делался на техническую сторону проблемы. Но за последнее время в постановке таких задач произошла определенная миграция из чисто технической сферы в область бизнес-процессов.
Любой бизнес стал сильнее полагаться на информационные технологии в решении самых важных вопросов. Это означает, что постоянно появляющиеся в бизнесе тенденции должны очень быстро и максимально адекватно отражаться в информационных решениях, часто строящихся на базе гетерогенных систем. Иными словами, чем сильнее бизнес связан с ИТ, тем выше значение инфраструктуры, роль которой и играет ПО промежуточного слоя. Это стало особенно очевидно при переходе от мэйнфреймов к двухзвенной технологии клиент-сервер и далее к нынешним распределенным информационным системам. Типичная корпоративная система сегодня по сути представляет собой набор неких технологических «островков», которые надо объединить в рамках единой интеграционной инфраструктуры. Что касается средств разработки, то они неразрывно связаны со структурой middleware. Нет большого смысла концентрировать усилия только на вопросах развертывания приложений, если нет возможности разрабатывать их в рамках имеющейся инфраструктуры.
EP: Возвращаясь к теме многоплатформности: на какие операционные системы Borland делает ставку в сервере приложений AppServer?
ЛС: Для нас сейчас приоритетны следующие платформы: Windows NT/2000, Solaris, IBM AIX, HP-UX и Linux. Следуя запросам наших заказчиков, мы иногда поддерживаем и некоторые экзотические платформы, например ОС серверов Siemens. Важна для нас и платформа OS/390. В определенном плане мы поддерживаем IRIX компании SGI, потому что у нас есть очень крупный заказчик в Америке - это NASA, и IRIX там в качестве операционной системы весьма распространена.
EP: Решения middleware вообще и применение серверов приложений в распределенных корпоративных системах в частности становятся сейчас одной из самых актуальных тем, когда речь заходит о построении крупных информационных комплексов. Что Вы можете сказать обо всей гамме решений, применяемых на рынке, и о взглядах Borland на технологию интеграции приложений?
ЛС: В настоящее время на рынке достаточно широко распространены такие концепции, как middleware, ориентированные на обмен сообщениями (Messaging Oriented Middleware, MOM), и мониторы транзакций. Они используются в индустрии уже более двадцати лет и не являются стандартизованными. Все они опираются на подходы той или иной компании. Кроме того, они не дают достаточной гибкости; разработка с их помощью сводится во многом к активному программированию с использованием низкоуровневого, процедурно-ориентированного API, существующего лишь в рамках технологии и идеологии того или иного поставщика. Если взять реально происходящие процессы, то мы увидим, что огромное число компаний отбрасывают или перерабатывают решения, сделанные на основе продуктов MQSeries и Tuxedo, и создают для себя принципиально новые решения на основе объектных технологий CORBA и EJB, которые, с одной стороны, дают высокую производительность и гибкость, а с другой - полностью полагаются на индустриальные стандарты. Таким образом, заказчик связывает себя не с конкретным продуктом или поставщиком, а с технологией, в развитии которой задействовано много различных вендоров.
EP: Объектная концепция построения middleware - это, похоже, самый перспективный подход к созданию промежуточного слоя бизнес-логики корпоративных систем. В этой связи не могли бы Вы кратко охарактеризовать преимущества каждой из моделей? Ведь известно, что Borland поддерживает все три присутствующие на рынке технологии - Enterprise Java Beans, CORBA и COM/DCOM?
ЛС: Часто приходится сравнивать CORBA и EJB. Опыт нашей компании показывает, что это комплементарные технологии, прекрасно дополняющие друг друга. Создание готового корпоративного решения с использованием EJB напоминает “крупноблочное строительство”, в то время как CORBA позволяет складывать его из более мелких «кирпичиков», получая готовую систему любой конфигурации (но, как правило, за счет несколько больших трудозатрат). Очень важно то, что эти технологии совместимы.
Мы в своем продукте AppServer используем обе технологии, и разработчики, создавая комплексные решения, всегда могут произвольно комбинировать эти концепции в рамках одного проекта, в зависимости от стоящих перед ними на данный момент задач.
Что касается DCOM, то, рассуждая с общих позиций, можно сказать, что между DCOM и CORBA большой разницы нет. И та и другая технология призвана делать возможной совместную работу объектов в распределенной вычислительной среде и обеспечивать взаимодействие между этими объектами В то же время к выработке стандартов CORBA было привлечено существенно большее количество мозговых ресурсов, что сделало ее более зрелой технологией, с помощью которой, как показывает наш опыт, можно подняться на очень высокий уровень обобщения в постановке и решении задач. DCOM базируется на существенно большем числе допущений и по функциональности может рассматриваться в качестве некоего подмножества CORBA. В то же время, используя технологии Microsoft, очень часто можно получить и гибкость, и эффективность, если не считать жесткой привязки к платформе Windows.
EP: Технология middleware чаще всего применяется для интеграции готовых систем класса ERP, CRM, приложений управления цепочками поставок и т.д. К сожалению, опыт работы с продуктами такого класса вообще и с сервером AppServer в частности в России невелик. Что бы Вы могли сказать о практическом применении технологий интеграции информационных систем, а также о применении AppServer в реальных корпоративных проектах?
ЛС: Речь всегда идет не об интеграции различных платформ, а об интеграции пакетов программ. Есть три способа решения этой задачи. Один из способов состоит в том, что разные элементы систем интегрируются при помощи, например, VisiBroker или другого CORBA-продукта. Еще одно решение - механизм коннекторов, который войдет в разрабатываемую в настоящее время спецификацию J2EE 1.3 и уже поддерживается в новой версии AppServer 4.5. Коннекторы обеспечивают очень четкий механизм объединения корпоративных приложений и, думается, смогут с большим успехом применяться в целом ряде случаев.
Третье направление решения этой проблемы, которое мы пропагандируем среди наших заказчиков, - использование XML. Можно достаточно хорошо работать и со стороны VisiBroker, и со стороны AppServer, используя мосты по обмену XML-сообщениями. Основная отличительная особенность этого подхода - он дает гораздо меньшую степень связанности объединяемых систем.
Можно привести и ряд конкретных примеров. В одной компании - крупном поставщике высокотехнологичного оборудования - в качестве ERP-системы используется SAP R/3, работающая на разных вариантах оборудования: NT-серверы, серверы на платформе HP-UX. Эта система интегрирована с ПО электронной коммерции компании Tibco Software при помощи CORBA-технологий.
У одного из наших заказчиков, финской телекоммуникационной компании, ERP-система R/3 “разговаривает” с системой Siebel класса CRM также средствами CORBA. Сделать это при помощи программы Visibroker было довольно просто. Если, к примеру, была бы поставлена задача интеграции этих двух сложных продуктов средствами DCOM, она представлялась бы практически неразрешимой в силу определенных ограничений этой технологии.
Помимо европейских примеров, которые мне более знакомы, можно назвать и американские проекты: в частности, в Bank of America также осуществлена интеграция ERP- и CRM-систем.
EP: Специалисты довольно часто высказывают весьма радикальную мысль о том, что в эпоху зрелости компонентной модели роль серверов приложений в информационных системах предприятий сильно возрастает. Иными словами, становится возможным, не применяя громоздких решений и, соответственно, не делая единовременно крупных инвестиций, выстраивать корпоративные решения шаг за шагом при помощи готовых компонентов и мощных инструментальных средств. Существуют ли на рынке примеры подобных внедрений?
ЛС: То, о чем Вы говорите, есть в некотором смысле идеальная ситуация. В подавляющем большинстве случаев мы сталкиваемся с компаниями, у которых уже есть ERP-решения, продукты CRM или другие системы подобного класса. В них уже вложены определенные инвестиции, и вопрос в том, как использовать то, что уже имеется. Тем не менее действительно можно выделить два сценария. В случае с финской телекоммуникационной компанией, о которой я уже говорил, были интегрированы два продукта - R/3 и Siebel. В проекте с одним из крупнейших поставщиков инфраструктуры Интернет, компанией UUNet, для обслуживания заказчиков исходно не было внедрено ничего. Все разрабатывалось с нуля, и в основу был положен AppServer, к которому комплементарно добавлялись те или иные компоненты. Все определяется тем, есть или нет в компании необходимая инфраструктура. С помощью AppServer можно эту инфраструктуру создать, объединяя уже имеющиеся наработки и добавляя к ним новые решения.