Распределенные информационные системы и базы данных

Россия, в силу своего географического положения и размеров, "обречена" на преимущественное использование распределенных систем. На мой взгляд, это направление может успешно развиваться лишь при выполнении двух главных условий - адекватном развитии глобальной сетевой инфраструктуры и применении реальных технологий создания распределенных информационных систем.

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

Я имею в виду использование двузвенной модели "клиент/сервер" для реализации распределенных систем. Поведение и мотивация разработчиков во многом понятны. Ставится задача - построить информационную систему "клиент/сервер" на базе локальной сети с централизованной базой данных. Выбирается одна из популярных многопользовательских СУБД и какие-либо средства для быстрой разработки приложений. Наконец, создается сама система, представляющая собой сочетание базы данных и набора обращающихся к ней приложений, в которых, собственно, и реализована вся прикладная логика системы. Предположим, что организация, для которой выполнялась разработка, настолько выросла, что вновь возникшие задачи потребовали децентрализации хранения и обработки данных (то есть использования распределенных баз данных) и, соответственно, развития информационной системы. Именно в этот момент совершается роковая ошибка. Подходы, которые хорошо зарекомендовали себя во вполне определенных и резко обозначенных условиях, автоматически переносятся в совершенно иную среду, с иными правилами жизнедеятельности. Как результат - система становится неработоспособной и должна быть создана заново, но уже с использованием адекватного аппарата.

Эта ошибка непростительна в тех случаях, когда с самого начала известно, что информационная система будет иметь распределенный характер, но в угоду коммерческим соображениям или в силу предпочтений конкретного продукта навязывается заведомо неработоспособное решение. Работая с интеграционными проектами, я все больше убеждаюсь в том, что двузвенная модель "клиент/сервер" и корпоративная распределенная система - вещи несовместимые. Ни в коем случае нельзя создавать информационную систему, опираясь на средства, жестко связывающие интерфейс конечного пользователя (формы, меню и др.) с компонентами базы данных (таблицами, если речь идет о реляционных базах данных). Увы, многие CASE-системы построены именно по этому принципу, и это лишний повод задуматься о смысле их использования. Предвижу здесь взрыв негодования со стороны многих специалистов, но готов до конца отстаивать эту точку зрения.

На мой взгляд, если мы всерьез думаем о проектировании и реализации распределенных информационных систем, следует обратить самое пристальное внимание на трехзвенную модель "клиент/сервер" и на продукты класса middleware. Мне нравится подход, характерный для менеджеров распределенных транзакций и реализованный в системе, с которой я работаю уже несколько лет, Tuxedo System. Я убедился в его жизненности, будучи консультантом реальных завершенных проектов. Возможны и другие варианты решений - применение систем разработки распределенных приложений в стандарте CORBA. Не хотелось бы давать готовых рецептов. Главное, на мой взгляд, - избегать "лобовых" решений. Будем помнить о том, что реальные технологии - это эффективная комбинация специализированных систем с согласованными интерфейсами, но уж никак не результат применения закрытых монопольных продуктов.