Створення автономної Web-служби в Delphi 7 за допомогою комплекту Indy. Частина 2, HTML, XML, DHTML, Інтернет-технології, статті

Частина 1


Введення


Що робити, якщо є необхідність у web-службі з двома і більше модулями TSoapDataModule? У цій статті розповідається про те, як створити автономну Web-службу, використовуючи комплект Indy і Delphi 7, і описується один із способів створення подібної служби. Перш ніж читати цю статтю, рекомендується ознайомитися з демонстраційною версією модуля SOAPDataModule, що поставляється разом з Delphi 7. У демонстраційній версії не тільки показується, як створити SOAP-модуль даних з викликуваними методами в тому ж самому інтерфейсі, але також демонструється, як можна використовувати властивість SOAPServerIID з’єднання TSoapConnection для отримання потрібного інтерфейсу прямо з даної служби.


Значна частина цієї статті заснована на повідомленнях Бруно (Джин-Мері Бабет) з мережевої телеконференції (borland.public.delphi.webservices.soap). Ці повідомлення дозволили пролити світло на те, як SOAP-з’єднання взаємодіє з web-службами. Ось посилання на повідомлення, Яке дало початок цьому невеликому проекту:


З цього повідомлення можна зробити висновок, що з’єднання TSoapConnection завжди отримує інтерфейс IAppServer з модуля TSoapDataModule незалежно від назви інтерфейсу, заданого для даного покажчика URL. Спочатку відсилання здійснюється за допомогою операцій SOAPAction, але у разі невдачі, зрештою, буде використовуватися покажчик URL. Інтерфейс IAppServer завжди посилається назад додатку-клієнта, а конструктором цього інтерфейсу є перший зареєстрований модуль даних (швидше за все, це відбувається через те, що переміщення SDM-модуля в Delphi-проект раніше за інших модулів призводить до зміну постачальника послуг).


Рекомендується спробувати відтворити описану вище ситуацію, перш ніж переходити до розглянутого нижче рішенням. Це допоможе ознайомитися з іншими корисними технічними прийомами.


Три замість одного!


По-перше, необхідно стандартним чином створити нову Web-службу із системою DataSnap (File-> New-> Other, WebServices, а потім вибрати SOAP Server Application). SOAP-додаток буде створено як файл, що виконується сервером Web App Debugger, з ім’ям класу (Class Name) TheThreeSDMs. В даний момент не потрібно створювати ніякого додаткового інтерфейсу.


Тепер, коли є каркас SOAP-сервера, потрібно додати три модулі даних SOAP Data Module. У даній статті вони названі SDM1, SDM2 і SDM3. Для кожного модуля даних потрібно задати параметр, що визначає постачальника послуг. Далі будуть використані три набори даних ClientDataSets, а також будуть завантажені деякі дані з бази прикладів MyBase і додані деякі компоненти TDataSetProviders. Тепер є діючий SOAP-сервер і потрібно запустити даний проект, принаймні, один раз, щоб зареєструвати його на сервері WebApp Debugger. Після цього слід звернути увагу на мову WSDL, що генерується для даної служби.


Як можна бачити, справді, є три зареєстрованих модуля SOAP-даних. А зараз потрібно створити додаток-клієнт для тестування ці модулів даних. Відкрийте новий додаток, використовуючи звичайні і “slap on” компоненти: три компоненти з’єднання TSoapConnection, три набору даних ClientDataSets, три джерела даних Data Sources і три інструменти DBGrid. Вкажіть всі SOAP-з’єднання для кожного SDM-модуля за таким зразком: http:// [servername] / soap / [interfacename]. Після цього слід спробувати задати ім’я постачальника послуг для кожного сховища даних. Повертається саме dspSDM1, незалежно від того, який модуль SOAP-даних використовується. Знову таки, як пише Бруно в своїх повідомленнях, це відбувається через те, що в якості кінцевої точки викликається інтерфейс IAppServer, а не покажчик URL.


Рішення!


Час прогону, період проектування … Робота ніколи не йде так, як хотілося б. А хотілося б просто використовувати покажчик URL, а не конструктор інтерфейсу IappServer. Як же досягти цього? Щоб відповісти на це питання важливо розуміти суть самої проблеми. Слід звернути увагу на те, що в Delphi 7 існує властивість SOAPServerIID для з’єднання TSoapConnection. Для нього завжди встановлено значення “IAppServerSOAP – {C99F4735-D6D2-495C-8CA2-E53E5A439E61}”. Це значення можна змінити, але тоді для властивості Connected можна встановити значення True (це можна зробити, якщо задати значення False для параметра UseSOAPAdapter, але це призводить до виклику інтерфейсу IAppServer замість IAppServerSOAP, нового інтерфейсу, введеного в Delphi 6). Заглянувши в модуль SOAPConn, можна помітити, що, швидше за все, не відбувається створення основного RIO-компонента. У той же час, якщо подивитися на демонстраційну версію модуля SOAPDataModule можна побачити, що існує можливість зміни властивості SOAPServerIID. Однак у цьому випадку необхідно мати можливість імпортування мови WSDL з сервера і, крім того, це призводить до втрати ряду можливостей в період проектування.


Пропоноване рішення грунтується на розумінні того, як з’єднання TSoapConnection отримує інформацію залежно від інтерфейсу модуля SOAP-даних. На серверній стороні інтерфейс зазвичай реєструється з допомогою модуля InvokeRegistry. Під час імпорту мови WSDL, як і в демонстраційній версії, він реєструє себе в додатку-клієнті теж за допомогою модуля InvokeRegistry. Це необхідно для того, щоб під час прогону з’єднання TSoapConnection могло знайти правильний інтерфейс для обслуговування звернень до даної службі (в разі демонстраційної версії це інтерфейс IDataMod). Однак це призводить до втрати деяких можливостей в період проектування. Далі буде розглянуто, як подолати цю проблему, яка, схоже, є єдиною перешкодою на шляху досягнення мети цієї статті. Якщо добре подумати, ця проблема не так вже й складна. Інтегроване середовище розробки нічого не знає про те, як викликати розділи ініціалізації модулів поточного проекту, так що в період проектування в модулі InvokeRegistry інтерфейси відсутні. Рішенням проблеми є створення для періоду проектування спеціального пакету з модулем, що містить інтерфейси-нащадки (такі як ISDM2).


Знову відкрийте проект сервера і додайте новий модуль під назвою uTheThreeSDMsIntf. Спочатку треба об’єднати всі SDM-інтерфейси сервера в цей модуль і задати оператор uses clause кожного SDM-модуля для використання нового модуля інтерфейсів. Крім того, звернення до служби повинно бути передано функції InvRegistry.RegisterInterface () для виклику розділу ініціалізації нового модуля. Нижче наведено відповідний програмний код для модуля uTheThreeSDMsIntf.







unit uTheThreeSDMsIntf;


interface


uses
InvokeRegistry, SOAPMidas;


type


ISDM1 = interface(IAppServerSOAP)
[“{E88F935E-94E4-4AFE-8A39-7453DB229286}”]
end;


ISDM2 = interface(IAppServerSOAP)
[“{063C7F1A-66B1-44C8-95A6-0FA025BF7028}”]
end;


ISDM3 = interface(IAppServerSOAP)
[“{6567D343-440B-42F8-931A-28735A8A3221}”]
end;


implementation


initialization
InvRegistry.RegisterInterface(TypeInfo(ISDM1));
InvRegistry.RegisterInterface(TypeInfo(ISDM2));
InvRegistry.RegisterInterface(TypeInfo(ISDM3));
finalization
InvRegistry.UnRegisterInterface(TypeInfo(ISDM3));
InvRegistry.UnRegisterInterface(TypeInfo(ISDM2));
InvRegistry.UnRegisterInterface(TypeInfo(ISDM1));
end.


Тепер, коли всі інтерфейси розміщені централізовано, потрібно створити такий пакет для роботи в період проектування, щоб в інтегрованому середовищі розробки можна було викликати ініціалізацію даного модуля під час його завантаження. Створіть новий пакет і встановіть для нього властивість Design-Time Only. Після цього залишається тільки додати модуль SDM-інтерфейсів, а потім скомпілювати і встановити отриманий пакет.


А зараз перейдемо до додатку-клієнта. Необхідно установити покажчик URL на задану за замовчуванням кінцеву точку протоколу SOAP так, щоб він вказував на адресу поточного WAD-проекту, тобто “Http://localhost:8081/threesdms.TheThreeSDMs/soap”. Крім того, потрібно скопіювати GUID-рядок інтерфейсу і вставити її в кожне властивість SOAPServerIID з’єднання TSoapConnection, точно таким же чином, як і в демонстраційній версії модуля SOAPDataModule. Відмінність полягає в тому, що тепер є сполуки, що діють в період проектування, а також є можливість заповнення таблиці даних в обох ситуаціях. Останнє, що залишається зробити в додатку-клієнті – Це додати модуль uTheThreeSDMsIntf до оператора uses. В завантаження був включений модуль під назвою uSoapIntf, який реєструє редактор властивостей, після чого властивість SOAPServerIID може відображати всі зареєстровані інтерфейси клієнтської частини. Крім того, тепер можна під’єднаються до SOAP-серверу, як це показано на наведеному нижче малюнку. Це не тільки значно скорочує число операцій копіювання і вставки, але також дозволяє відображати всі інтерфейси. Слід зазначити, що ім’я описаного вище модуля існує тільки в поточному проекті.


Готово! Тепер можна задати параметр ProviderName для кожного постачальника послуг і все буде працювати належним чином, як у період проектування, так і під час прогону. Ось, по суті справи, і все!
Приклад проекту можна подивитися тут.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*