Возможные режимы работы OLE-сервера VisualFoxPro

Таблица 3.

OLE-сервер Visual FoxPro регистрируется автоматически. Для ручной регистра­ции сервера ЕХЕ достаточно его запустить с опцией /regserver. Опция /unregserver позволяет удалить информацию о сервере из Регистра Windows. Для регистра­ции сервера DLL вручную запустите утилиту REGSVR32.EXE с именем файла в качестве первого параметра. Удалить информацию о сервере из Регистра можно, использовав второй параметр /u. Например:

REGSVR32 OLE_SERV.DLL /u

OLE-сервер Visual FoxPro для своей работы требует присутствия библиотеки поддержки - файлов VFP500.DLL и VFP5ENU.DLL.

OLE-сервер в компьютерной сети

При коллективное работе с данными OLE-сервер должен обрабатывать вызовы всех пользователей компьютерной сети и, следовательно, должен находиться на сервере, а не на каждом компьютеры пользователя. Такой подход позволяет организовать трехуровневую модель обработки данных. Эта модель отличается от тра­диционной модели клиент-сервер, т. к. отображает не просто физическое взаимное - расположение пользователя и программы, а логику обработки данных. В трехуровневой модели выделяют следующие логические процессы:

· Пользовательский процесс — представляет возможность работы с данными пользователю приложения, обеспечивает защиту данных от несанкциони­рованного доступа.

· Бизнес-процесс — обеспечивает единые правила работы с данными с точки зрения технологии производственного процесса, генерирует информационную поддержку маркетинга и менеджмента.

· Процесс обработки данных — обеспечивает описание и хранение данных обработку и выполнение запросов, поддержку целостности данных.

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

Возможность взаимодействия между OLE-контроллером и OLE-сервером обеспе­чивается двумя объектами:

· Proxy — обеспечивает формирование пакета данных с параметрами вызова для OLE-сервера. Этот объект работает в адресном пространстве OLE-контроллера и обеспечивает соединение с соответствующим объектом Stub в адресном пространстве OLE-сервера.

· Stub — принимает пакет данных и обеспечивает переадресацию вызова для выполнения соответствующих действий на OLE-сервере. Этот объект рабо­тает в адресном пространстве OLE-сервера и связан с соответствующим объектом Proxy в адресном пространстве OLE-контроллера.

При работе OLE Automation на одном компьютере функционирование объектов Proxy и Stub обеспечивается системным файлом OLEAUT32.DLL

Если OLE-контроллер и OLE-сервер расположены на разных компьютерах, для обеспечения связи между ними необходимо использовать дополнительный ком­понент, который называется Automation Manager (файл AUTMGR32.EXE). Этот компонент должен быть установлен на обоих компьютерах.

OLE-контроллер продолжает использовать объект Proxy, но в этом случае его функционирование обеспечивается файлом AUTPRX32.DLL. На компьютере с внешним OLE-сервером Automation Manager управляет как объектом Stub для получения пакетов данных от OLE-контроллера, так и объектом Proxy для имита­ции наличия OLE-контроллера на этом компьютере. Таким образом для OLE-cepвера создаются все условия, чтобы он не ощущал «одиночества» от отсутствия OLE-контроллера на том же самом компьютере,

Сервер OLE Visual FoxPro 5.0 поддерживает обратные связи. Вы можете исполь­зовать метод на сервере, который будет получать ссылку на объект от OLE-кон­троллера как один из параметров. Эта возможность позволяет устанавливать асинхронную связь с сервером, если эта связь не может быть установлена немед­ленно по причине выполнения сервером какого-то длительного процесса.

В этом случае на сервере, который будет, например, называться Processor (в Регистр Windows — MyServer.Processor) должен быть описан класс:

DEFINE CLASS Processor AS Custom OLEPUBLIC

oObjRef = ""

PROCEDURE SetupRef (oRef)

This.oObjRef = oRef

ENDPROC

PROCEDURE DoCallBack

This.oObjRef.Notify ()

ENDPROC

ENDDEFINE

В клиентском приложении запишем:

oObjl = CREATEOBJECT ("Job")

o0bj2 - CREATEOBJECT ("MyServer .Processor")

o0bj2 . SetUpRef ( oObjl)

DEFINE CLASS Job AS Custom

PROCEDURE Notify

= MESSAGEBOX ("Задание выполнено!")

ENDPROC

ENDDEFINE

Как только на сервере вызывается метод DoCallBack, следует выполнение метода Notify объекта клиентского приложения.

Если связь с OLE-сервером происходит по компьютерной сети то на компьютере клиентского приложения должен быть установлю Automation Manager.

Первоначально Automation Manager и Remote Automation Manager были разработаны для Visual Basic 4.0 и в дальнейшем использованы в Visual Fox­Pro 5.0 для расширения функциональности в области разработки крупных проек­тов при коллективной работе с данными.

AutomationManager

Automation Manager работает в фоновом режиме, т. к. его основное предназначе­ние заключается в управлении процессом OLE Automation в сети путем внешних процедурных вызовов. Как отмечалось выше, эти вызовы формируются за счет взаимодействия между объектами OLE Proxy и OLE Stub. Без них вы не сможете создать внешний OLE-сервер.

Automation Manager устанавливается на сервере и распределяет вызовы от объек­та Proxy рабочей станции к соответствующему объекту Stub сервера. Возвращае­мые значения Automation Manager направляет OLE-контроллеру через объект Stub. За Счет этого ни OLE-контроллер, ни OLE-сервер не чувствуют, что распо­ложены на разных компьютерах.

В большинстве случаев достаточно установки Automation Manager на сервере. Од­нако, если приложение предусматривает наличие «обратной связи» от OLE-сервера, необходима установка Automation Manager и на клиентский компьютер. Обыч­но запуск Automation Manager происходит автоматически, как только система об­наруживает в этом необходимость. Если этого не произошло, одна из наиболее возможных причин — повреждение или неправильная запись в Регистре Win­dows.