Действительно, он занимается архитектурой систем, то есть внутренней структурой коммуникаций, скрытой от глаз, как и водопроводные трубы. Впрочем, это отнюдь не значит, что он совсем не видит того, что делается вне «строения». Своими взглядами на внутреннее устройство информационных систем и то, что их окружает, Браун поделился в интервью с представителем нашей редакции Сергеем Кузнецовым.
 |
Каким вы видите место России в бизнесе Informix?
Начну с некоторых очевидных соображений. Во-первых, есть набор определенных условий, без которых не может развиваться бизнес информационных систем, набор условий, которые способствуют разработке программного обеспечения. Здесь в России они, в принципе, такие же, как и везде в мире. Надо иметь в виду размеры вашей страны, ее население, географию... Есть и специфические трудности, в их числе, например, принципиально иной алфавит. Мы понимаем проблемы бизнеса в России и работаем с несколькими местными компаниями, концентрируясь на тех возможностях, которые может предоставить Informix, в России.
Каковы перспективы России с точки зрения оффшорного программирования?
Тенденция все шире использовать оффшорное программирование действительно существует. Есть страны, например, Индия, где выполняется большой объем таких работ для Informix. С точки зрения управления работами, Индия имеет некоторые преимущества. Во-первых, подавляющее большинство населения страны говорит по-английски. Это практически родной язык для индийцев. А вы знаете, что восприятие разговорного языка значительно сложнее, у жителей России в этом могут возникнуть сложности. Во-вторых, действует фактор, свойственный для Европы в целом. Европа значительно опережает США как минимум в двух областях. Первая - это использование мобильных технологий. Быстрый темп развития мобильных технологий был вызван ростом спроса со стороны потребителей. Сейчас мобильные устройства - это часть социальной жизни. Европейцы значительно лучше представляют себе, как можно использовать мобильные телефоны. В Америке меньше граждан имеют мобильные телефоны. А представьте себе, какой информационный бизнес связан с этими телефонами, какого программного обеспечения они требуют. Результаты, достигнутые в этой области, интеллектуальные богатства и открытое программное обеспечение могут быть использованы и в бизнесе ПК.
С моей точки зрения персональные компьютеры будут использоваться еще в течение пяти лет. Это ужасное устройство со всех точек зрения, сложная, неуклюжая машина, с которой страшно трудно работать. Положение в корне изменят специализированные устройства. Я ожидаю - как бы этого ни отрицали другие специалисты - что Европа будет экспортировать мобильную технологию назад в США. В Европе есть очень энергичные компании, такие как Deutche Telecom, British Telecom. Наша американская компания, Ameritech, к примеру, заключает контракты с европейскими фимрами, дабы воспользоваться здешним опытом, и многие наработки быстро возвращаются назад в Соединенные Штаты.
Сейчас в Кремниевой долине, в Калифорнии сложился негативный баланс с точки зрения безработицы. Люди привыкли подолгу работать в одной области, в одной компании, что предоставляет определенные возможности. С другой стороны, что если вы не работали с компанией достаточное время, сложность задач программирования, которые можно вам поручить весьма ограничена. Отсюда - сложности для начинающих. Скажем, Web-компания, которая не имеет солидного технологического основания, такого как Informix Web Foundation.2000, может решать только очень простые задачи.
Вы имеете в виду, что существует проблема начинающих компаний?
Да. Проблема начинающих, которые пытаются работать в Сети. Я наблюдаю, за тем, что делают начинающие, что происходит в Web с этой точки зрения. Откровенно говоря, я не понимаю, что происходит в этой области, с тех пор, когда появился Amazon.com.
Давайте рассмотрим мобильную систему поддержки расписаний, к примеру, поездов. Я бы хотел, чтобы с помощью такой системы можно было узнать, когда отправляется следующий поезд, заказать билеты... Практически аналогичной системы не существует. Она и очень сложна, и требует применения больших сил разработчиков. Именно потребность в таких системах создает перспективу для Европы. Такого класса разработки могли бы быть созданы в Европе, и впоследствии экспортированы в США.
С моей точки зрения, в Европе общество лучше подготовлено к использованию мобильных технологий, здесь лучше понимают эти технологии, поэтому им легче «ухватить» эту возможность. Задача в целом очень большая, но европейцы, мне кажется, в состоянии ее решить.
Да, но это верно только для Западной Европы, а мне хотелось бы услышать вашу точку зрения на Россию. Конечно, у нас масса проблем, но у нас есть и превосходные программисты, разработчики. Согласитесь, есть разница между Швецией, к примеру, и нами. Швеция обладает отличными технологиями, но... это очень маленькая страна.
Я бы вот как это сформулировал. Исключительность Кремниевой долины состоит отнюдь не в технологиях и не в отличных программистах. Мне приходилось встречаться с прекрасными программистами во многих странах. Дело в том, что в Кремниевую долину поступает ежегодно 1,5 млрд. долл.
Когда в дело вкладываются такие огромные суммы, из этого, несомненно, должен получиться какой-то толк. Вот в этом-то и состоит задача, это именно то, что нужно, чтобы «навести мосты» с точки зрения технологии между Россией и западным миром. Впрочем, я бы не взял на себя смелость делать какие-то окончательные утверждения, поскольку я, в общем-то, технический специалист.
Есть многие вещи, которых я не понимаю. Я не понимаю, например, почему сейчас есть планы вложить 25 млн. долл. в начинающую компанию, которая собирается продавать через Web какие-то товары широкого потребления. Для меня это загадка, но зато это хороший пример того, какие деньги «протекают» через данный сектор информационных технологий. Иногда, мне кажется, что деньги идут на нечто совершенно... неподобающее.
Давайте, обратимся к технологиям, в которых вы ориентируетесь гораздо лучше. Для начала я бы хотел спросить вас об Illustra.
Сейчас над Illustra работает небольшая группа специалистов, занятых, в основном, наложением «заплаток». Разработки новых кодов Illustra сейчас не ведутся. В Illustra есть буквально пара функций, которые не вошли в Infromix Foundation.2000. Первая - это система хранения на базе time-travel. Мы планируем реализовать поддержку time-travel в существующих системах Informix Dynamic Server. Это интересная идея, действительно новое измерение.
Итак, коды Illustra сейчас не развиваются. Есть в ее отношении и такое интересное соображение, по которому я бы хотел знать и ваше мнение - не стоит ли открыть исходные коды Illustra.
О, мне бы это очень понравилось!
Сейчас в отношении Illustra не предпринимаются никаких усилий по разработке, и не планируется вести никаких работ, за исключением внесения исправлений и локальных усовершенствований. Практически все, что есть в Illustra, есть в Infromix Foundation.2000.
О-кей! А каковы взаимоотношения между Informix и Postgress SQL?
Не более чем формальные.
То есть вы просто работаете в public domain.
Я - нет. Но у нас есть люди, которые вносят свой вклад в это.
То есть вы не конкуренты?
Я бы посоветовал всем прежде попытаться реализовать характеристики, аналогичные Informix, используя Postgress Sequel. Например, у одного из наших клиентов в Европе в базу данных загружается 400 млн. специальных объектов, что составляет около
200 Гбайт данных, и время отклика составляет доли секунды. Да, на Postgress SQL разработаны вполне конкурентоспособные базы данных, но они не обладают такой масштабируемостью как Informix. Я знаю нескольких людей, которые работают на Postgress SQL, и отношусь к ним с искренним уважением, и желаю им всяческих успехов.
То, что они делают, как нельзя лучше сочетается с Internet.
Что делаем мы - мы разрабатываем систему, предоставляющую ограниченный доступ к набору информации для сообщества пользователей. Процессор Postgress SQL позволяет сделать это очень и очень эффективно. Но я знаю Postgress SQL и могу сказать, что с архитектурной точки зрения им будет трудно сделать то, что мы сделали, и за тот срок, за который это удалось нам. Например, Postgress SQL не имеет системы тиражирования, или, скажем, поддержки распределенного управления.
Да, но вы знаете почему? Не потому ли, что он относится к public domain?
Я так не думаю. Впрочем, не стоит жалеть о Postgress, это была не более чем пробная система.
Следующий вопрос - о поддержке транзакций в Internet. Я спрашиваю потому, что, откровенно говоря, плохо понимаю, как вы собираетесь это делать при помощи HTTP? Это же не транзакционный протокол!
Важно различать транзакции с точки зрения бизнеса, и с точки зрения поддержки.
То есть речь идет о целостности?
Да. Речь идет об избыточности, о продолжительности работы без сбоев.
Рассмотрим пример. Я прихожу в банк для того, чтобы осуществить транзакцию с моим банковским счетом. Я говорю - снимите такую-то сумму денег с такого-то счета. Как происходит обработка такой транзакции? Система определяет, сколько осталось средств на моем промежуточном счете, изымает, скажем, 100 долл. с моего промежуточного счета, и помещает эти деньги в мой итоговый счет.
О какой транзакции идет речь - обновление, закрытие?
Закрытие. На бизнес-уровне действия распадаются на четыре потока. Везде средствами HTTP обеспечивается поддержка транзакции с моего, допустим, телефона, то есть беспроводной системы, с серверным процессором. Главное здесь, что эта транзакция - в том, что касается информационной системы - обрабатывается «на лету» до тех пор, пока я не «скажу» что-то вроде: «Хорошо, вот то, чего я хотел добиться». Эта информация поступает обратно на сервер, и система фиксирует состояние транзакций, которые имели статус «на лету», и делает их постоянными. Сложность здесь состоит в изоляции. Я должен производить дополнения к данным через операционную систему, через систему поддержки транзакций «на лету». То есть здесь есть довольно значительные сложности с точки зрения разработки, сложности при проектировании транзакционной системы через HTTP.
Вот именно. Почему не IIOP?
Мы работаем над этим.
В том числе и с Object Management Group?
Мы являемся членами OMG. Это означает, что мы пытаемся отслеживать, что происходит в этом информационном пространстве. При разработке продуктов мы не отходим далеко от стандарта. Я думаю, что в скором времени, такие технологии, как IIOP, и даже RMI - превратятся в Java через Web.
Нет-нет, IIOP - это отнюдь не Java...
Да, но я имею в виду технологию, позволяющую поддерживать транзакции в целом. RMI и IIOP позволяют делать это.
Возникает вопрос, почему все же HTTP-системы более популярны? Понять причину можно, если взглянуть на то, что происходит в Internet, на наиболее крупные узлы... Amazon.com - это исключительно HTML-версия.
Стоит только взглянуть на тех, кто пытаться сделать что-либо более сложное, как сразу выясняется, что люди до сих пор работают с браузером Linx, некоторые - с браузером Netscape. Поэтому приходится искать общий знаменатель.
Протокол WAP и Web-технологии, скорее всего, дадут начало Internet нового поколения. HTTP и HTML используют для того, чтобы использовать Web. Web-предоставляет транзакционный слой. На мой взгляд, HTTP - своего рода введение в Internet, урок, который надо выучить, опыт, который необходимо получить для того, чтобы создать такой Web-протокол, который снимет многие проблемы для нас, специалистов по базам данных.
Мой следующий вопрос про JavaBeans. В прошлом году эта технология сослужила очень хорошую службу Informix, а сейчас вы пока не сказали про нее ни слова.
Да, JavaBeans обладают очень хорошей архитектурой, она даже лучше, чем COM.
Но тогда почему же вы не сказали ни слова о JavaBeans?
По двум причинам. Прежде всего, потому что объектно-реляционные базы данных - это оболочка для компонентов, в которую можно встраивать компоненты с различной логикой. В компонентной модели разработчик волен сам выбирать, какие компоненты использовать. Можно использовать JavaBeans, можно использовать компонентную технологию Microsoft, можно использовать даже CORBA. Оболочка в этом случае должна быть нейтральной к той компонентной технологии, которую может избрать разработчик или пользователь.
Я считаю, Java Beans превосходной технологией, и, откровенно говоря, я считаю Java, может быть, второй технологией девяностых годов, после объектно-реляционных баз данных. И я считаю так потому, что если вы пишете JavaBeans, их можно вставить в процессор базы данных, или в клиентское приложение, или в промежуточное программное обеспечение, и вся реализация приобретает мобильность.
Предположим, я хочу реализовать поддержку почтового адреса. Я могу поддерживать в ядре базы данных метод формирования адреса, по которому можно построить любой экземпляр, то есть индекс, город и так далее. Адреса можно сортировать, сравнивать по индексу и так далее.
Кроме того, я могу реализовать в виде JavaBean такие методы, как преобразование в строку.
Поддержка JavaBeans придется по душе разработчикам, пользующимся Java.
Более того, это единственный способ, которым можно реализовать некоторые приложения. Именно поэтому мы купили СУБД CloudScape, поскольку ее процессор полностью реализован на Java.
Мой следующий вопрос связан с вычислительными архитектурами с массовым параллелизмом (MPP - massive parallel processing. Вокруг этой технологии творятся странные вещи. Она принесла немалый доход Informix...
Вы знаете, что единственная архитектура, которая обеспечивает такую же масштабируемость в рамках одной машины - это NUMA (non-uniform memory architecture).
Таких архитектур много, правда, NUMA - это самая сложная.
Она сложна для проектировщика, но с ней замечательно просто работать. Системы, которые разрабатывались для MPP-систем, впечатляюще лучше работают на NUMA. Мы могли использовать быстродействие памяти для того, чтобы локально повысить эффективность некоторых операций. Все возможности масштабирования, к которым мы привыкли, работая с MPP, проявляются в многократно увеличенном масштабе в NUMA.
MPP обещала большую производительность и готовность, но на смогла обеспечить достаточной надежности. Кроме того, в действительности, достаточно трудно работать в стиле OLTP в системах MPP.
Но почему OLTP, а не OLAP? Скажем, NCR работает в той же архитектуре, что и вы, но ориентируется на OLAP.
Можно упомянуть такую, например, причину - это единственный способ обеспечить восстановление системы в случае отката. Что мы, например, делаем в CNN. Мы одновременно работаем с несколькими видеоматериалами. Это OLTP в средствах массовой информации. Здесь нельзя терять время на создание резервных копий, как вам известно, на это уходят целые дни. Единственный способ обеспечить восстановление - это избыточность. Сейчас мы вынашиваем планы создания такой базы данных, в которой бы был учтен весь опыт, который мы накопили, работая с архитектурой MPP. В то же время, мы хотим извлечь все возможные преимущества, создавая расширяемые базы данных и работая в распределенной слабосвязанной архитектуре, которая гарантирует надежность и высокую готовность.
Можно создать локализованую копию экономических данных и получить ответ только на основании этих локализованных данных. Если у вас есть некий выделенный уровень, я пошлю туда запрос. Многие клиенты хотят получить приблизительный ответ, но очень быстро, но, в то же время, остаются пользователи, которым время от времени нужен точный ответ.
MPP с точки зрения процессора XPS - это локальная архитектура в стиле NUMA. MPP должна была дать масштабируемость и готовность. Но и это можно было сделать только с помощью слабосвязанной архитектуры и распределенных компонентов.
Но как же быть с гигантской расширяемостью MPP?
Если у вас есть кластер Unix-машин - это не очень дорого. Можно запустить процессор XPS на кластере Unix-машин. Существует выбор - аппаратное обеспечение может быть очень дорогим. Но еще дороже может оказаться администрирование. Дело в том, что каким бы ни было дорогим «железо», люди стоят гораздо дороже.
Я знаю об опыте Software AG и ее XML-сервере. Почему вы так мало делаете в отношении XML? Интересно также ваше мнение относительно таких сочетаний, как хранилища данных и XML, и метаданные в Internet и XML.
Прежде всего, мы работаем с XML. И, кстати, неплохо бы еще раз окинуть взглядом эту технологию, поскольку меня она немного смущает. Informix участвует в Консорциуме WWW. Наша компания делает с XML три вещи. Во-первых, мы захватываем документы XML. И храним в библиотеках DLL. Кроме того, необходимо обеспечить своего рода внешний интерфейс XML, поддерживать существующие отношения. Хранить данные в нормализованной форме, с сохранением избыточности и непротиворечивости. Я должен иметь возможность передавать информацию из XML в другую систему. Кроме того, эти документы нужно преобразовывать. Прежде всего, можно решить проблемы XML без написания длинных программ, поскольку множество разработчиков сейчас используют Java, чтобы решить загадки XML. Документы XML можно хранить в реляционных отношениях. XML имеет принципиально иерархическую структуру. Поскольку процессор базы данных обладает расширяемостью, мы можем добавлять в него типы данных, которые «понимают» иерархию.
В иерархической структуре по верхнему уровню можно судить обо всем, что ниже. А это позволяет очень быстро перемещаться по иерархии. Мы можем использовать документы XML для использования этих преимуществ, и мы можем хранить их в реляционных таблицах. Если это структуры DDD, то их можно хранить в реляционных таблицах с foreign key, и это непосредственный XML-документ.
