Сервер приложения (статья)
Сервер приложения
Многозвенные распределенные приложения обеспечивают эффективный доступ удаленных клиентов к базе данных, так как в них для управления доступом к данным применяется специализированное ПО промежуточного слоя. В наиболее распространенной схеме — трехзвенном приложении — это сервер приложения, который выполняет следующие функции:
| · | обеспечивает авторизацию пользователей; |
| · | принимает и передает запросы пользователей и пакеты данных; |
| · | регулирует доступ клиентских запросов к серверу БД, балансируя нагрузку сервера БД; |
| · | может содержать часть бизнес-логики распределенного приложения, обеспечивая существование "тонких" клиентов. |
Delphi обеспечивает разработку серверов приложений на основе использования ряда технологий:
| · | Web; |
| · | Автоматизация; |
| · | MTS; |
| · | SOAP. |
Структура сервера приложения
Итак, сервер приложения — это ПО промежуточного слоя трехзвенного распределенного приложения. Его основой является удаленный модуль данных. В Delphi предусмотрено использование удаленных модулей данных пяти типов (см. ниже).
Далее в этой главе мы детально рассмотрим вопросы использования удаленных модулей данных, инкапсулирующих функции серверов Автоматизации. Другие типы удаленных модулей данных рассматриваются в следующих частях книги.
Каждый удаленный модуль данных инкапсулирует интерфейс IAppServer, методы которого используются в механизме удаленного доступа клиентов к серверу БД.
Для обмена данными с сервером БД модуль данных может содержать некоторое количество компонентов доступа к данным (компонентов соединений и компонентов, инкапсулирующих набор данных).
Для обеспечения передачи данных клиентам удаленный модуль данных обязательно должен содержать необходимое количество компонентов TDataSetProvider, каждый из которых должен быть связан с соответствующим набором данных.
Внимание
Обмен данными сервера приложения с клиентами обеспечивает динамическая библиотека MIDAS.DLL, которая должна быть зарегистрирована на компьютере сервера приложения.
Для создания нового сервера приложения достаточно выполнить несколько простых операций.
1. Создать новый проект, выбрав в качестве типа проекта обычное приложение (пункт меню File | New | Application) и сохранить его.
2. В зависимости от используемой технологии, выбрать из Репозитория Delphi необходимый тип удаленного модуля данных (см. рис. 20.3). Удаленные модули данных располагаются на страницах Multitier, WebSnap и WebServices.
3. Настроить параметры создаваемого удаленного модуля данных (см. ниже).
4. Разместить в удаленном модуле данных компоненты доступа к данным и настроить их. Здесь разработчик может выбрать один из имеющихся
наборов компонентов (см. часть IV) в зависимости от используемого сервера БД и требуемых характеристик создаваемого приложения.
5. Разместить в удаленном модуле данных необходимое число компонентов TDataSetProvider и связать их с компонентами, инкапсулирующими наборы данных.
6. При необходимости создать для потомка интерфейса IAppServer, используемого в удаленном модуле данных, дополнительные методы. Для этого создается новая библиотека типов (см. низке).
7. Скомпилировать проект и создать исполняемый файл сервера приложения.
8. Зарегистрировать сервер приложения и при необходимости настроить дополнительное ПО.
Весь механизм удаленного доступа, инкапсулированный в удаленных модулях данных и компонентах-провайдерах, работает автоматически, без создания разработчиком дополнительного программного кода.
Далее в этой главе на простом примере рассматриваются все перечисленные этапы создания сервера приложения.
Интерфейс IAppServer
Интерфейс IAppServer является основной механизма удаленного доступа клиентских приложений к серверу приложения. Набор данных клиента использует его для общения с компонентом-провайдером на сервере приложения. Наборы данных клиента получают экземпляр IAppServer от компонента соединения в клиентском приложении.
При создании удаленных модулей данных (см. ниже) каждому такому модулю ставится в соответствие вновь создаваемый интерфейс, предком которого является интерфейс IAppServer.
Разработчик может добавить к новому интерфейсу собственные методы, которые, благодаря возможностям механизма удаленного доступа многозвенных приложений, становятся доступны приложению-клиенту.
Свойство
property AppServer: Variant;
в клиентском приложении имеется как в компонентах удаленного соединения, так и клиентском наборе данных.
По умолчанию интерфейс является несохраняющим состояние (stateless). Это означает, что вызовы методов интерфейса независимы и не привязаны
к предыдущему вызову. Поэтому интерфейс IAppServer не имеет свойств, которые бы хранили информацию о состоянии между вызовами.
Обычно разработчику ни к чему использовать методы интерфейса напрямую, однако его значение для многозвенных приложений трудно переоценить. И при детальной работе с механизмом удаленного доступа интерфейс понадобится так или иначе.
Методы интерфейса IAppServar
function AS ApplyUpdates (const ProviderName: WideString; Delta: OleVariant; MaxErrors: Integer; out ErrorCount: Integer; var OwnerData: OleVariant) : OleVariant; safecall; Передает изменения, полученные от клиентского набора данных, компоненту-провайдеру, определяемому параметром ProviderName. Изменения содержатся в параметре Delta. Параметр MaxErrors задает максимальное число ошибок, пропускаемых при сохранении данных перед прерыванием операции. Реальное число возникших ошибок возвращается параметром ErrorCount. Параметр OwnerData содержит дополнительную информацию, передаваемую между клиентом и сервером (например, значения параметров методов-обработчиков). Функция возвращает пакет данных, содержащий все записи, которые не были сохранены в базе данных по какой-либо причине
function AS DataRequest (const ProviderName: WideString; Data: OleVariant) : OleVariant; safecall; Генерирует событие OnDataRequest для указанного провайдера ProviderName
procedure AS Execute (const ProviderName: WideString; const CommandText : WideString; var Params : OleVariant; var OwnerData: OleVariant) ; safecall;
Выполняет запрос или хранимую процедуру, определяемые параметром CommandText для провайдера, указанного параметром ProviderName. Параметры запроса или хранимой процедуры содержатся в параметре Params
function AS GetParams (const ProviderName: WideString; var OwnerData: OleVariant): OleVariant; safecall; Передает провайдеру ProviderName текущие значения параметров клиентского набора данных
function AS GetProviderNames: OleVariant; safecall; Возвращает список всех доступных провайдеров удаленного модуля данных
function AS GetRecords (const ProviderName : WideString, Count: Integer; out RecsOut: Integer; Options: Integer; const CommandText: WideString; var Params : OleVariant; var OwnerData :OieVariant) : OleVariant; safecall;
Возвращает пакет данных с записями набора данных сервера, связанного с компонентом-провайдером. Параметр CommandText содержит имя таблицы, текст запроса или имя хранимой процедуры, откуда необходимо получить записи. Но он работает только в случае, если для провайдера в параметре Options включена опция poAllowCommandText. Параметры запроса или процедуры помещаются в параметре Params. Параметр задает требуемое число записей, начиная с текущей, если его значение больше нуля. Если параметр равен нулю — возвращаются только метаданные, если он равен -1 — возвращаются все записи. Параметр RecsOut возвращает реальное число переданных записей
function AS RowRequest (const ProviderName: WideString; Row: OleVariant; RequestType: Integer; var OwnerData: OleVariant): OleVariant; safecall;
Возвращает запись набора данных (предоставляемого провайдером ProviderName), определяемую параметром Row. Параметр RequestType содержит значение типа TfetchOptions
Большинство методов интерфейса используют параметры ProviderName и OwnerData. Первый определяет имя компонента-провайдера, а второй содержит набор параметров, передаваемых для использования в методах-обработчиках.
Внимательный читатель обратил внимание, что использование метода AS_GetRecords подразумевает сохранение информации при работе интерфейса, т. к. метод возвращает записи, начиная с текущей, хотя интерфейс IAppServer имеет тип stateless. Поэтому перед использованием метода рекомендуется обновлять набор данных клиента.
Тип
TFetchOption = (foRecord, foBlobs, foDetails);
TFetchOptions = set of TFetchOption;
используется в параметре RequestType метода AS_RowRequest.
foRecord — возвращает значения полей текущей записи;
foBlobs — возвращает значения полей типа BLOB текущей записи;
foDetails — возвращает все подчиненные записи вложенных наборов данных для текущей записи.
Интерфейс IProviderSupport
Для организации взаимодействия клиентов с сервером БД удаленный модуль данных сервера приложения должен содержать компоненты-провайдеры TDataSetProvider. При этом используются методы интерфейса IAppServer.
Для обмена данными с набором данных на сервере компонент-провайдер применяет интерфейс IProviderSupport, который включен в любой компонент набора данных, произошедший от класса TDataSet. В зависимости от используемой технологии доступа к данным каждый компонент, инкапсулирующий набор данных, имеет собственную реализацию методов интерфейса IProviderSupport.
Методы интерфейса могут понадобится разработчику только при создании собственных компонентов, инкапсулирующих набор данных и наследующих от класса TDataSet.
Удаленные модули данных
Удаленный модуль данных является основой сервера приложения (см. рис. 20.2) для многозвенного распределенного приложения. Во-первых, он выполняет функции обычного модуля данных — на нем можно размещать компоненты доступа к данным. Во-вторых, удаленный модуль данных инкапсулирует интерфейс IAppServer, обеспечивая тем самым выполнение функций сервера и обмен данными с удаленными клиентами.
В зависимости от используемой технологии в Delphi можно использовать удаленные модули данных пяти типов.
Remote Data Module. Класс TRemoteDataModule инкапсулирует сервер Автоматизации.
Transactional Data Module. Класс TMTSDataModule является потомком класса TRemoteDataModule и к функциям обычного сервера Автоматизации добавляет возможности MTS.
WebSnap Data Module. Класс TWebDataModule создает сервер приложения, использующий возможности Internet-технологий.
Soap Server Data Module. Класс TSOAPDataModule инкапсулирует сервер SOAP.
CORBA Data Module. Класс TCORBADataModule является потомком класса TRemoteDataModule и реализует функции сервера CORBA.
Ниже мы рассмотрим процесс создания сервера приложения на основе удаленного модуля данных TRemoteDataModule. Остальные модули данных (за исключением удаленного модуля данных для CORBA) детально рассматриваются далее в этой книге.
Удаленный модуль данных для сервера Автоматизации
Для создания удаленного модуля данных TRemoteDataModule используется Репозиторий Delphi (команда File | New | Other). Значок класса TRemoteDataModuie находится на странице Multitier. Перед созданием экземпляра удаленного модуля данных появляется диалоговое окно, в котором необходимо предустановить три параметра.
Строка CoClass Name должна содержать имя нового модуля данных, которое будет также использовано для именования нового класса, создаваемого для поддержки нового модуля данных.
Список Instancing позволяет задать способ создания модуля данных.
Internal — модуль данных обеспечивает функционирование лишь внутреннего сервера Автоматизации.
Single Instance — для каждого клиентского соединения создается собственный экземпляр удаленного сервера Автоматизации в собственном процессе.
Multiple Instance — для каждого клиентского соединения создается собственный экземпляр удаленного сервера Автоматизации в одном общем процессе.
Список Threading Model задает механизм обработки запросов клиентов.
Single — поток запросов клиентов обрабатывается строго последовательно.
Apartment — модуль данных одновременно обрабатывает один запрос. Однако если DLL для выполнения запросов создает экземпляры СОМ объектов, то для запросов могут создаваться отдельные нити, в которых обработка ведется параллельно.
Free — модуль данных может создавать нити для параллельного выполнения запросов.
Both — аналогична модели Free, за исключением того, что все ответы клиентам возвращаются строго один за другим.
Neutral — запросы клиентов могут направляться модулям данных в нескольких нитях одновременно. Используется только для технологии СОМ+.
При создании нового удаленного модуля данных создается специальный класс — наследник класса TRemoteDataModule. И фабрика класса на основе класса TComponentFactory
Класс TComponentFactory представляет собой фабрику класса для компонентов Delphi, инкапсулирующих интерфейсы. Поддерживает интерфейс IClass Factory.
Создадим, например, удаленный модуль данных simpleRDM. В мастере создания модуля данных в качестве способа создания выберем Single Instance, a Free — как модель обработки запросов.
type
TSimpleRDM = class(TRemoteDataModuie, ISimpleRDM)
private
protected
class procedure UpdateRegistry(Register: Boolean; const Classic, ProgID: string); override;
public
end;
implementation
{$R *.DFM}
class procedure TSimpleRDM.UpdateRegistry(Register: Boolean; const
ClassID, ProgID: string);
begin
if Register then
begin
inherited UpdateRegistry(Register, Classic, ProgID);
EnableSocketTransport(ClassID);
EnableWebTransport(ClassID);
end
else
begin
DisableSocketTransport(ClassID);
DisableWebTransport(ClassID);
inherited UpdateRegistry(Register, ClassID, ProgID);
end;
end;
initialization
TComponentFactory.Create(ComServer, TSimpleRDM, Class_SimpleRDM, ciMultilnstance, tmApartment);
end.
Обратите внимание, что параметры модуля данных, заданные при создании, использованы в фабрике класса TComponentFactory в секции initialization.
Фабрика класса TComponentFactory обеспечивает создание экземпляров компонентов Delphi, поддерживающих использование интерфейсов.
Метод класса UpdateRegistry создается автоматически и обеспечивает регистрацию и аннулирование регистрации сервера Автоматизации. Если параметр Register имеет значение True, выполняется регистрация, иначе — отмена регистрации.
Разработчик не должен использовать этот метод, т. к. его вызов осуществляется автоматически.
Одновременно с модулем данных создается и его интерфейс — потомок интерфейса IAppServer. Его исходный код содержится в библиотеке типов проекта сервера приложения. Для удаленного модуля данных simpleRDM созданный интерфейс isimpleRDM представлен ниже. Для удобства из листинга удалены автоматически добавляемые комментарии.
LIBID_SimpleAppSrvr: TGUID='(93577575-OF4F-43B5-9FBE-A5745128D9A4}';
IID_ISimpleRDM: TGUID = '{Е2СВЕВСВ-1950-4054-В823-62906306Е840}';
CLASS_SimpleRDM: TGUID = '{DB6A6463-5F61-485F-8F23-EC6622091908}' ;
type
ISimpleRDM = interface;
ISimpleRDMDisp = dispinterface;
SimpleRDM = ISimpleRDM;
ISimpleRDM = interface(lAppServer)
['{E2CBEBCB-1950-4054-B823-62906306E840}']
end;
ISimpleRDMDisp = dispinterface
['{E2CBEBCB-1950-4054-B823-62906306E840}']
function AS_ApplyUpdates(const ProviderName: WideString; Delta: OleVariant; MaxErrors: Integer; out ErrorCount: Integer; var OwnerData: OleVariant): OleVariant; dispid 20000000; function AS_GetRecords(const ProviderName: WideString; Count: Integer; out RecsOut: Integer; Options: Integer; const CommandText: WideString; var Params: OleVariant; var OwnerData: OleVariant): OleVariant; dispid 20000001;
function AS_DataRequest(const ProviderName: WideString; Data: OleVariant): OleVariant; dispid 20000002;
function AS_GetProviderNames: OleVariant; dispid 20000003;
function AS_GetParams(const ProviderName: WideString;
var OwnerData: OleVariant): OleVariant; dispid 20000004;
function AS_RowRequest(const ProviderName: WideString; Row: OleVariant; RequestType: Integer; var OwnerData: OleVariant): OleVariant; dispid 20000005;
procedure AS_Execute(const ProviderName: WideString; const CommandText: WideString; var Params: OleVariant; var OwnerData: OleVariant);
dispid 20000006;
end;
CoSimpleRDM = class
class function Create: ISimpleRDM;
class function CreateRemote(const MachineName: string): ISimpleRDM;
end;
imp1ementation uses ComObj;
class function CoSimpleRDM.Create: ISimpleRDM;
begin
Result := CreateComObject(CLASS_SimpleRDM) as ISimpleRDM;
end;
class function CoSimpleRDM.CreateRemote(const MachineName: string):ISimpleRDM;
begin
Result := CreateRemoteComObject(MachineName, CLASS_SimpleRDM) as ISimpleRDM;
end;
end.
Обратите внимание, что интерфейс ISimpleRDM является потомком интерфейса IAppServer, рассмотренного выше.
Так как удаленный модуль данных реализует сервер Автоматизации, дополнительно к основному дуальному интерфейсу ISimpleRDM автоматически создан интерфейс диспетчеризации isimpleRDMDisp. При этом для интерфейса диспетчеризации созданы методы, соответствующие методам интерфейса IAppServer.
Класс coSimpleRDM обеспечивает создание СОМ-объектов, поддерживающих использование интерфейса. Для него автоматически созданы два метода класса.
class function Create: ISimpleRDM;
используется при работе с локальным и внутренним сервером (in process).
class function CreateRemote(const MachineName: string): ISimpleRDM;
используется в удаленном сервере.
Оба метода возвращают ссылку на интерфейс ISimpleRDM.
Теперь, если проект с созданным модулем данных сохранить и зарегистрировать, он станет доступен в удаленных клиентских приложениях как сервер приложения.
После создания удаленный модуль данных становится платформой для размещения компонентов доступа к данным и компонентов провайдеров (см. гл. 20), которые, наряду с модулем данных, реализуют основные функции сервера приложения.
Дочерние удаленные модули данных
Один сервер приложения может содержать несколько удаленных модулей данных, которые, например, выполняют различные функции или обращаются к разным серверам БД. В этом случае процесс разработки серверной части не претерпевает изменений. При выборе имени сервера в компоненте удаленного соединения на стороне клиента будут доступны имена всех удаленных модулей данных, включенных в состав сервера приложения.
Однако тогда для каждого модуля понадобится собственный компонент соединения. Если это нежелательно, можно использовать компонент TSharedConnection, но в этом случае в интерфейсы удаленных модулей данных необходимо внести изменения.
Для того чтобы несколько модулей данных были доступны в рамках одного удаленного соединения, необходимо выделить один главный модуль данных, а остальные сделать дочерними.
Рассмотрим, что же это означает для практики создания удаленных модулей данных. Суть идеи проста. Интерфейс главного модуля данных (разработчик назначает модуль главным, исходя из собственных соображений) должен содержать свойства, указывающие на интерфейсы всех других модулей данных, которые также необходимо использовать в рамках одного соединения на клиенте. Такие модули данных и называются дочерними.
Если такие свойства (свойство должно иметь атрибут только для чтения) существуют, все дочерние модули данных будут доступны в свойстве ChildName Компонента TSharedConnection (см. гл. 20).
Например, если дочерний удаленный модуль данных носит название Secondary, главный модуль данных должен содержать свойство Secondary:
ISimpleRDM = interface(lAppServer)
['{E2CBEBCB-1950-4054-B823-62906306E840}']
function Get_Secondary: Secondary; safecall;
property Secondary: Secondary read Get_Secondary;
end;
Реализация метода Get_secondary выглядит так:
function TSimpleRDM.Get_Secondary: Secondary; begin Result := FSecondaryFactory.CreateCOMObject(nil) as ISecondary; end;
Как видите, в простейшем случае достаточно вернуть ссылку на вновь созданный дочерний интерфейс.
Полностью пример создания дочернего удаленного модуля данных рассматривается далее в этой главе.
Регистрация сервера приложения
Для того чтобы клиент мог "увидеть" сервер приложения, он должен быть зарегистрирован на компьютере сервера. В зависимости от используемой технологии процесс регистрации имеет особенности. Регистрация серверов MTS, Web и SOAP рассматривается далее в этой книге.
Здесь же мы остановимся на регистрации сервера приложения, использующего удаленный модуль данных TRemoteDataModule (сервер Автоматизации), который чрезвычайно прост.
Для исполняемых файлов достаточно запустить сервер с ключом /regserver или даже просто запустить исполняемый файл.
В среде разработки ключ можно поместить в диалоге команды меню Run Parameters.
Для удаления регистрации используется ключ /unregserver, но только в командной строке.
Для регистрации динамических библиотек применяется ключ /regsvr32.