АНАЛИЗ

Поставки OLE DB не начнутся ранее 1997 года, слишком сильна привязка к Windows

Решить, как именно поделить приложение,  -  самая трудная часть разделения работы между клиентом и сервером. Если слишком утяжелить клиентскую часть, понадобится аппаратура побыстрее. Если же все задачи будет выполнять сервер базы данных, увеличится нагрузка на обмен данными по сети и пострадает производительность.

Корпорация Microsoft (Редмонд, шт. Вашингтон) объявила, что знает средство от этого недуга  -  лекарство называется OLE DB. При том весе, какой имеет на рынке эта компания, любые ее попытки создать стандарт заслуживают внимания.

Но у этой стратегии есть обратная сторона. Стандарт OLE DB не будет готов до 1997 года, а широко принятым он станет, видимо, на рубеже столетия. Более того, планы Microsoft нацелены на Windows. Есть шанс, что перенос OLE DB на машины Macintosh пройдет гладко, но вряд ли он скоро будет реализован в системах Unix или OS/2.

Основой плана корпорации Microsoft для новой схемы OLE является СОМ (Component Object Model), которая сама по себе есть архитектура, и в ней двоичные объекты могут быть разделяемыми и использованы многократно. Архитектура СОМ, разработанная корпорациями Microsoft и Digital Equipment, хорошо структурирована. Проблема в том, что есть и другие языково-независимые архитектуры, как раз такие, как, например, СОМ, Common Object Request Broker Architecture, создавшая для OLE конкурента по имени OpenDoc.

     Краеугольным камнем стратегии OLE корпорации Microsoft являются ОСХ. Эти компоненты, функционирующие в плане Microsoft как объекты, являются 32-разрядной заменой 16-разрядных управляющих элементов Visual Basic  

Однако, как только Microsoft разработает эти части, разделение приложений станет намного легче для организаций, которые в основном используют систему Windows. Например, с помощью OLE DB бизнес-правила будут инкапсулированы в объекты OLE, которые можно будет использовать в любом приложении, совместимом с OLE DB. Первые же выпуски OLE DB дадут возможность разделения таких объектов. В некоторых случаях добавления бизнес-правила к приложению клиента сделать будет так же просто, как перенести мышью в приложение управляющий элемент OLE (ОСХ). В противоположность этому в настоящее время большинство систем работает с бизнес-правилами как с хранимыми процедурами на сервере баз данных, что и мешает этому подходу: сама природа хранимых процедур затрудняет перенос их в приложение клиента, на конкурирующие серверы баз данных и даже на upgrade существующего сервера. Поэтому разработчикам приходится браться за средства CASE и заниматься переделкой исходных кодов.

Но даже в этом случае технология OLE DB сама по себе не дает жизнеспособного решения для настоящего разделения приложений. Необходимо общее хранилище объектов, и технология OLE должна работать на всех основных платформах. Ответом Microsoft на необходимость репозитария станет Cairo  -  объектно-ориентированная версия Windows NT. Но пока неясно, как создать OLE масштаба предприятия.

ДЖОН ТАШЕК