State-full Web Services на Delphi

2006 г.

State-full Web Services на Delphi

Александр Шагин, ведущий программист отдела "ИНФОВУЗ", Волгоградский Государственный Педагогический Университет

Введение

Среда Borland Delphi (версии 6 и 7) предоставляет достаточно удобные инструменты по созданию Web Services application. В сочетании с технологией Midas у программиста есть очень эффективный инструмент по созданию N-звенных приложений доступа к корпоративным БД. Тем не менее реализация Web Services в Delphi содержит некоторые существенные ограничения, которые, в целом оправданы, но при переходе на новую платформу, будут вызывать у программистов, привыкших работать с TDCOMConnection, TSocketConnection и т.п. дополнительные сложности. SOAP Server applications - это, в общем случае, statelss приложения - сервер не хранит информацию о предыдущих вызовах клиента, что не позволяет использовать привычный подход и технологию программирования, а тем более говорить о прозрачном переходе на новый тип соединения(Например,так как это происходит при переходе с TDCOMConnection на TSocketConnection или наоборот). Конечно, отсутствие statefull-объектов на сервере оправдывается тем, что потенциально Web Services должны будут обрабатывать огромное количество входящих соединений, и выделение для каждого из них оперативной памяти приведет, в конце концов, к выводу сервера или сервиса из строя, но тем не менее отсутствие прозрачного механизма портации существующих проектов(если, конечно, таковая вообще требуется) может остановить от реализации этой идеи даже очень опытных программистов.

В процессе работы у нас возникла следующая задача. Корпоративная система работала в пределах локальной сети. Соеденение клиентов осуществлялось с помощью SocketConnection, что обеспечивало вполне приличную скорость и масштабируемость. Со временем появились новые удаленные рабочие места, но соеденение по локальной сети установить уже не было возможности, только Internet. Требовалось обеспечить работу пользователей в точности с тем же набором приложений (чтобы не приходилость дополнительно тратить времени на обучение по работе с новым софтом или на дополнительную организацию их взаимодействия с основной корпоративной системой), который они использовали ранее. Для коммуникации клиентских приложений с основным сервером идеально подходил SOAP-протокол, но отсутствие statefull соединений могло сильно затянуть время адаптации серверов приложений. Посколько в параллельных проектах уже был опыт использования Web Services , и появление вышеобозначенных проблем вполне предсказывалось, велась разработка механизма прозрачного перевода MIDAS-серверов и клиентов на использование протокола SOAP. Детали, проблемы и подходы в решении этой задачи я бы и хотел осветить в этой статье.

Проблемы и их решения.

Основной проблемой, с которой приходится изначально бороться - это отсутствие сессионности между вызовами клиента. От кого пришел запрос, в общем случае, однозначно понять практически невозможно. В интернете содержится достаточно много публикаций на эту тему и подход (пример: Managing sessions with Delphi 6 Web services , Building Real-Life Web Services), в общем-то, для решения проблемы един: создание на стороне сервера постоянно существующий объект: менеджер сессий. Как следствие - application server должен быть постоянно загружен на web-сервере или самостоятельно выполнять его функцию.

Следующая проблема - это обеспечение прозрачного вызова базовых методов интерфейса IAppServer с клиента соответствующих методов требуемого провайдера(TCustomProvider) на сервере в контексте сессии. Решением данной проблемы является создание наследника от TCustomRemoteServer, который инкапсулирует данные(контекст сессии) и методы по взаимодействию с менеджером сессий средствами SOAP-протокола. На стороне сервера создается наследник от TInvokableClass (TSOAPSessionManeger), и соответствующий ему IInvokable интерфейс ISOAPSessionManeger, который реализует базовые, но модифицированные, методы интерфейса IAppServer, и дополнительные методы, необходимые для авторизации, контроля состояния и др. .

 1: ISOAPSessionManeger = interface(IInvokable)
 2:   ['{59AD0E15-EF0F-4DF3-A782-18B5FEC70AC4}']
 3:   {IAppServer support}
 4:   function  WS_AS_ApplyUpdates(const SessionID:WideString; const ProviderName: WideString; Delta: OleVariant;
 5:                                MaxErrors: Integer; out ErrorCount: Integer; var OwnerData: OleVariant): OleVariant;  stdcall;
 6:   function  WS_AS_GetRecords(const SessionID:WideString; const ProviderName: WideString; Count: Integer; out RecsOut: Integer;
 7:                              Options: Integer; const CommandText: WideString;
 8:                              var Params: OleVariant; var OwnerData: OleVariant): OleVariant; stdcall;
 9:   function  WS_AS_DataRequest(const SessionID:WideString; const ProviderName: WideString; Data: OleVariant): OleVariant; stdcall;
10:   function  WS_AS_GetProviderNames(const SessionID:WideString): TWideStringDynArray;  stdcall;
11:   function  WS_AS_GetParams(const SessionID:WideString;const ProviderName: WideString; var OwnerData: OleVariant): OleVariant; stdcall;
12:   function  WS_AS_RowRequest(const SessionID:WideString; const ProviderName: WideString; Row: OleVariant; RequestType: Integer;
13:                             var OwnerData: OleVariant): OleVariant;  stdcall;
14:   procedure WS_AS_Execute(const SessionID:WideString; const ProviderName: WideString; const CommandText: WideString;
15:                           var Params: OleVariant; var OwnerData: OleVariant); stdcall;
16:   {Authorithation support}
17:   function  WS_Login(const AUserName, APassword: WideString ; var SessionID, ErrMsg:WideString):Integer; stdcall;
18:   function  WS_Logout(const SessionID:WideString):Integer; stdcall;
19:   function  WS_GetSessionState(const SessionID:WideString):Integer;stdcall;
20:   {Data-exchange support}
21:   function  WS_GetValue(const SessionID, AName: WideString):OleVariant;stdcall;
22:   procedure WS_SetValue(const SessionID, AName: WideString; const AData: OleVariant);stdcall;
23:   function  WS_CallMethod(const SessionID, MethodName: WideString; const Params: OleVariant):OleVariant;stdcall;
24:   end;

Базовым понятием в данной модели является понятие сессии (класс TWSSession) . Сессия - это объект, который идентефицирует клиетское соединение на стороне сервера, ассоциирует с ним наборы модулей данных(наследники TDataModule), обеспечивает регистрацию провайдеров из соответствующих модулей, вызов базовых методов интерфейса IAppServer, и методы авторизации для конкретной сессии. Ключевые понятия сессии:

SessionID - id сессии в менеджере сессий.
UserName, Password - данные для авторизации.
AppID - наименование набора классов(модулей данных), которые будут создаваться при регистрации нового клиента. AppID вместе с SessionID клиент передается в заголовке каждого SOAP-сообщения на сервер.

Для того, чтобы определить, какие модули данных необходимо создавать для данного AppID - их классы предварительно регистрируются. Поскольку интерфейс ISOAPSessionManeger является своеобразным "переходником" между клиентом и стандартным интерфейсами IAppServer посредством менеджера сессий, обеспечивая бинарную совместимость передаваемых пакетов данных, что позволяет прозрачно вызывать методы провайдеров уже в контексте сессии(т.е. только из тех дата-модулей, которые определены для данного AppID в конкретной сессии)

Вызов методов IInvokable интерфейсов в котнексте сессии. Для решения этой проблемы пришлось изменить стандартное поведение класса TSoapPascalInvoker. При определении экземпляра объекта для выполнения метода, запрашиваемого клиентом интерфейса, Delphi ищет в собственном реестре(объект InvRegistry) класс, его реализующий, а затем создает его экземпляр(Per request), или процедуру, возвращающую ссылку на этот объект(Global). Поскольку в каждом SOAP-сообщении содержится SessionID, можно определить сессиию клиента, и как следствие, получить ссылки на дата-модули, существующие в ее контексте. Далее находим дата-модуль, реализующий запрашиваемый интерфейс и возвращаем на него ссылку. Далее работает стандартная схема, а метод уже вызывается именно в контексте сессии. Поскольку предварительно мы реализуем стандартный код, вышеприведенные изменения ни в коем случае не изменяют установленного поведения компонентов и их методов. Таким образом задача создания своих собственных state-full объектов с поддержкой сессий становится тривиальной задачей: Создание наследника TDataModule TMyDM, объявление IInvokeble интерфейса IMyIntf и его регистрация в InvRegistry, включение интерфеса IMyIntf в класс TMyDM и его регистрация в системе(WSReg.RegisterDataModule(TMyDM,'MyApp')), реализация методов интерфейса.

Неожиданной оказалась проблема автоматического включения в каждый заголовок SOAP-сообщения идентификационной информации. Класс TRIO не содержит событий, которые позволили добавить в заголовок нужную информацию c использованием сдандартных для этого методов(Класс TSOAPHeader). Событие OnBeforeExecute вызывается уже полсе того, как заголовки упакованы в сообщение. Исходный код TRIO пришлось модифицировать, добавлением события OnBeforeRequest(добавить метод DoBeforeRequest) и полученный класс TWSRIO использовать в классе TwssSoapConnection(наследник TCustomRemoteServer, реализующий взаимодействие сервером приложений). Вызов удаленных методов интерфейсов предпочтительно осуществлять с использованием этого класса, или же, для компонента TRIO самостоятельно добавлять нужные заголовки(класс TWSSHeader).

Как следствие, вышеприведенных изменений вполне достаточно как для портации серверных приложений на базе TRemoteDataModule под Web Services, так и создания новых state-full, state-less Web Services приложений в привычных для программиста условиях.

Дополнительные особенности.

В процессе работы, к стандартному механизму SOAP, были добавлены такие возможности как:

сжатие передаваемого по сети контента(используется библитека ZLib);
так называемые NotifyEvents для модулей данных.
вызов удаленных методов минуя IInvokable интерфейсы(wssIntf.pas : IModuleAuth.CallMethod).

Реализация

Исходники и примеры здесь(112 Кб). Для реализации примера установите у себя пакет wss.dpk. Пропишите необходимые пути в Library Path.

Пример

Сервер

Сервер будем реализовывать как standalone Web Service(Требуется библиотека Indy).

Создаем консольное приложение.
Добавляем к нему TDataModule.

Объявляем интерфейс(Классом реализации будет наш дата-модуль):

 1: { Invokable interface IWSSTest }
 2: 
 3: unit WSSTestIntf;
 4: 
 5: interface
 6: 
 7: uses InvokeRegistry, Types, XSBuiltIns;
 8: 
 9: type
10: 
11:   { Invokable interfaces must derive from IInvokable }
12:   IWSSTest = interface(IInvokable)
13:   ['{15907745-68B1-47A3-86A6-9EF2A3530493}']
14: 
15:     { Methods of Invokable interface must not use the default }
16:     { calling convention; stdcall is recommended }
17:     function TestMethod(const s : string): string ;stdcall;
18:   end;
19: 
20: implementation
21: 
22: initialization
23:   { Invokable interfaces must be registered }
24:   InvRegistry.RegisterInterface(TypeInfo(IWSSTest));
25: 
26: end.

Реализуем поддержку нашего интерфейса в дата-модуле:

 1: unit Unit2;
 2: 
 3: interface
 4: 
 5: uses
 6:   SysUtils, Classes, WSSTestIntf,
 7:   WSObj{WSS Core};
 8: 
 9: type
10:   TDataModule2 = class(TDataModule, IWSSTest, IWSSessionNotifyEvents)
11:   private
12:     { Private declarations }
13:     //добавление совершенно не обязательно, но удобно, а иногда и полезно:)
14:     procedure  WSSessionNotifyEvent(const SessionClient : TWSSesClient;
15:                                              const EventName : string;
16:                                              const Data: OleVariant);
17:   public
18:     { Public declarations }
19:     function TestMethod(const s : string): string ;stdcall;
20:   end;
21: 
22: var
23:   DataModule2: TDataModule2;
24: 
25: implementation
26: 
27: {$R *.dfm}
28: 
29: { TDataModule2 }
30: 
31: function TDataModule2.TestMethod(const s: string): string;
32: begin
33:   Result := 'Hello from server: '+ s;
34:   writeln('Method call: '+ s);
35: end;
36: 
37: procedure TDataModule2.WSSessionNotifyEvent(
38:   const SessionClient: TWSSesClient; const EventName: string;
39:   const Data: OleVariant);
40: begin
41:   writeln('EVENT:',EventName,' - sessionid:',SessionClient.SessionID);
42: end;
43: 
44: end.

Модифицируем dpr-файл как показано ниже.

 1: program Project2;
 2: 
 3: {$APPTYPE CONSOLE}
 4: 
 5: uses
 6:   SysUtils,
 7:   IndyHttpServerApp,{Под Apache2 заменить на Apache2ServerApp}
 8:   WSSTestIntf in 'WSSTestIntf.pas',
 9:   Unit2 in 'Unit2.pas' {DataModule2: TDataModule};
10: 
11: begin
12:   { TODO -oUser -cConsole Main : Insert code here }
13:   ServerApplication.Initialize;
14:   {register TDataModule2 class for AppID="TEST"}
15:   ServerApplication.RegisterDataModuleClass(TDataModule2,'TEST');
16:   ServerApplication.Run;
17: end.

Готово. Запускаем сервер.
Видим Service Info Page страницу по адресу: http://localhost:8888/

Клиент

Создаем новый проект.
На форме распологаем компонент TwssSoapConnection. Устанавливаем значения свойств как приведено на скриншоте.
При помощи утилиты WSDL Importer импортируем в наш проект модуль с описанием интерфейса IWSSTest(получаем модуль IWSSTest1.pas).
Устанавливаем: wssSoapConnection1.URL=http://localhost:8888/soap, wssSoapConnection1.AppID="TEST" и заполняем поля wssSoapConnection1.SessionUserName и wssSoapConnection1.SessionPassword.

Пишем обработчики для кнопок:

 1: unit Unit1;
 2: 
 3: interface
 4: 
 5: uses
 6:   Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
 7:   Dialogs, StdCtrls, DB, DBClient, wssSoapConn;
 8: 
 9: type
10:   TForm1 = class(TForm)
11:     wssSoapConnection1: TwssSoapConnection;
12:     Button1: TButton;
13:     Label1: TLabel;
14:     Button3: TButton;
15:     procedure Button1Click(Sender: TObject);
16:     procedure Button2Click(Sender: TObject);
17:     procedure Button3Click(Sender: TObject);
18:   private
19:     { Private declarations }
20:   public
21:     { Public declarations }
22:   end;
23: 
24: var
25:   Form1: TForm1;
26: 
27: implementation
28: 
29: uses IWSSTest1;
30: 
31: {$R *.dfm}
32: 
33: procedure TForm1.Button1Click(Sender: TObject);
34: begin
35:   wssSoapConnection1.Open;
36:   Label1.Caption := wssSoapConnection1.SessionID;
37: end;
38: 
39: procedure TForm1.Button2Click(Sender: TObject);
40: begin
41:   wssSoapConnection1.Close;
42: end;
43: 
44: procedure TForm1.Button3Click(Sender: TObject);
45: begin
46:   ShowMessage( (wssSoapConnection1.RIO as IWSSTest).TestMethod('Client.'));
47: end;
48: 
49: end.

Готово. Запускаем.
Клиент:

Сервер:

Исходный код примера здесь.(11,7Kb)

Переход от TXXXConnection к TwssSoapConnection

Клиент

TXXXConnection заменяется на TwssSoapConnection.
Вызовы методов через TCustomRemoteServer.AppServer заменяются на TwssSoapConnection.RIO as IMyAppIntf.

Сервер

Создаем серверный проект как показано в примере.
Добавляем к проекту TRemoteDataModule.(Меняем наследника на TDataModule)
Убираем все, что связано с DCOM.(Factrory и прочее...)
На базе You Project_TLB.pas создаем IInvokeble интерфейс и объявляем его поддержку для модуля данных.
Выполняем ServerApplication.RegisterDataModule(TMyDM,'MyApp');

Заключение

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

Оригинал статьи на странице автора