2. Сервер застосувань

Усі запити клієнтів до БД попередньо потрапляють до сервера застосувань, який, за необхідності, перетворює їх у зручну для сервера БД форму і переправляє до СКБД. Результати виконання запиту на зворотному шляху також проходять подібну “цензуру”. Отож з допомогою внутрішніх процедур сервера застосувань розробник системи має змогу потрібним чином впливати на процес проходження запитів від клієнтів і отриманих вибірок даних з сервера. Наприклад, у багатьох випадках виявляється, що необхідна клієнтові інформація у сервера застосувань вже є і немає змісту зайвий раз завантажувати ресурси сервера БД та мережі.

Звісно, що використання сервера застосувань не обмежується функціями інтелектуального посередника між клієнтами та БД. Він також є зручним місцем зберігання (і виконання) багатьох спільних для клієнтських застосувань процедур з підтримки бізнес-правил і забезпечення інших сервісів.

Загальні зауваження

Технологія MIDAS реалізації сервера застосувань здатна підтримувати ідеології DCOM та CORBA^3[3] (додатково є змога використовувати MTS, яка фактично є удосконаленням DCOM, та SOAP). Ці ідеології проповідують різні підходи до вирішення багатьох проблем взаємодії серверів і клієнтів, таких як, наприклад, пошук потрібних алгоритмів і засобів їхнього виконання у загальній системі, рівномірного розподілення обчислювального навантаження між серверами застосувань, питання секретності тощо. У нашій архітектурно простій системі з одним-двома серверами застосувань такі питання не є надто актуальними, тому надалі викорис-товуватимемо доступніший за наявністю потрібного програмного інструментарію (вбудовано у Windows) підхід DCOM.

За такого підходу MIDAS реалізує сервер застосувань у вигляді сервера Автоматизації. Тому, як і будь-який COM об’єкт, він автоматично розпочинає роботу на вимогу зв’язку від першого ж клієнта і самостійно закривається разом із завершенням зв’язку з останнім^4[4].

Складовими частинами сервера застосувань є:

• віддалений модуль даних^5[5];

• інтерфейсна форма(и) для зв’язку з адміністратором сервера;

• компоненти-провайдери.

Віддалений модуль даних є основною частиною сервера застосувань^6[6].

По-перше, подібно до звичайного модуля даних, він є контейнером для розміщення невізуальних компонент доступу до даних (похідні від TDataSet) та трансакцій, а також компонент з’єднання з сервером БД (похідні від TCustomConnection). Окрім того, для передачі даних клієнтам віддалений модуль даних містить компоненти TDataSetProvider, кожна з яких має бути пов’язана з відповідним набором даних. TDataSetProvider виконує підготовку (пакетування, шифрування та ін.) даних для їхньої передачі клієнтові через мережу, або ж розпаковує отриману від клієнта інформацію для внесення змін у потрібний набір даних.

По-друге, за рахунок надання клієнтам інтерфейсу IAppServer^7[7] (або його наслідника), віддалений модуль даних реалізує основні функції сервера застосувань.

Демонстраційний приклад

Розглянемо послідовно етапи процесу створення найпростішого сервера застосувань як окремої програми, котра виконує функції віддаленого модуля даних.

Відкриваємо новий проект (у головному меню Delphi/ C++ Builder вказуємо File->New->Application) і збережемо його під довільною назвою, наприклад, PAppServer. Форма, що з’явилась на екрані монітора, виконуватиме функції зв’язку між адміністратором і сервером застосувань (друга складова частина, див. п. 3.1). Решта компонент останнього будуть невізуальними. Далі створюємо віддалений модуль даних: File->New->Other. В отриманому вікні всеможливих пропонованих до створення об’єктів вибираємо закладку Multitier (її відсутність засвідчує, що при інсталяції Delphi/C++ Builder можливість побудови багатошарових застосувань не передбачено). Розміщені на цій сторінці компоненти відповідають основним технологіям DCOM та CORBA реалізації серверів застосувань. За оговореним у попередньому параграфі принципом зупинимося на виборі компонента Remote Data Module. Вибір супроводжується вимогою уточнення трьох його головних параметрів:

• CoClass Name – ім’я класу сервера, котре автоматично буде доповнено першою літерою “Т” та занотовано у реєстрі Windows і, відповідно, надалі використовуватиметься усіма клієнтами для встановлення зв’язку із сервером застосувань. Для першого разу вкажіть, наприклад, MyFirstAppServer.

• Instancing.

• Internal – модуль створюється як частина активної бібліотеки DLL (тобто забезпечується функціонування лише внутрішнього сервера автоматизації) і працює він у межах процесу сервера застосувань.

• Single/Multiple – для кожного з’єднання з клієнтом утворюється власна копія віддаленого модуля даних. Усі модулі або ділять між собою єдиний процес на серверній машині (multiple), або ж запускаються у власних процесах (single).

Для початку роботи найкраще підійде вибір Multiple.

• Threading Model.

• Single – усі запити клієнта виконуються у єдиному потоці процесу, а, отже, послідовно.

• Apartment, Free, Both Neutral – різновиди багатопотоко-вого виконання запитів, завдяки яким можна значно збільшити ефективність роботи сервера. Проте для забезпечення безконфліктної паралельної роботи декількох потоків від програміста вимагається чимало зусиль і досвіду.

Найбезпечнішою (з огляду на безконфліктність корпоратив-ної роботи) є конфігурація Single.

Тепер новостворений модуль потрібно наповнити компонентами доступу до інформації в базі даних та зв’язку з клієнтськими застосуваннями. Історично склалось так, що на перших порах з цією метою використовували компоненти TDataBase, котрі застосовують BDE засоби доступу до БД. Проте сьогодні з цією метою використовують універсальні TSQLConnection та TADOConnection, або спеціалізовану TIBDataBase. Вибір компонент доступу до БД залежить від багатьох чинників, зокрема від обраної СКБД. Досвід авторів дає підставу сьогодні рекомендувати технологію ADO для СКБД MS SQL, Oracle, Sybase не через меншу ефективність інших технологій (зокрема, Borland), а з огляду на сучасні тенденції ринку програмного забезпечення і пов’язані з ними перспективи подальшої підтримки та розвитку цих технологій.

Для визначеності зупинимось на TSQLConnection. Для її роботи мінімально необхідно зазначити такі властивості:

• ConnectionName – назва конфігурації з’єднання, котра визначається користувачем (вкажіть, наприклад, My_IB_Con).

• DriverName – драйвер для зв’язку з потрібною СКБД (оберемо, наприклад, Interbase).

• Params – набір параметрів зв’язку, котрий залежить від типу обраної СКБД, і у якому обов’язковими є лише пари:

DataBase = < шлях до файла бази даних >.

User_Name = < ім’я зареєстрованого в СКБД користувача бази даних > ( SYSDBA по замовчуванню для Іnterbase).

Password = < його пароль > (masterkey для SYSDBA).

Важливо знати, що всі ці властивості можна динамічно визначати під час роботи процедур сервера застосувань безпосередньо перед встановленням з’єднання з БД (Connected = true). Це означає, що одна і та ж компонента здатна почергово підтримувати зв’язок з різними базами даних, і навіть з тими, котрі керуються різними СКБД.

Згадана властивість DataBase, окрім вказування місцезна-ходження файла БД, додатково визначає протокол мережі, за яким спілкуватимуться сервери застосувань і бази даних. Наприклад, для застосування внутрішнього (для WINDOWS) протоколу мережі – NETBEUI шлях до БД необхідно позначати так:

\\ < ім’я комп’ютера > \ < повний шлях до файла >, наприклад, \\ComputerDBServer\с:\...\DBDir\Simple.gdb.

Зауважимо, що тут під поняттям < повний шлях до файла > розуміємо не відданий під деяким іменем ресурс мережі, а фізичне розташування файла БД, починаючи від кореневого каталогу.

Для зв’язку ж за TCP/IP протоколом згадана вище стрічка має виглядати так:

ComputerDBServer : с:\...\DBDir\Simple.gdb.

Зв’язок за протоколом TCP/IP є дещо універсальнішим, бо дає змогу замість доменного імені комп’ютера вказувати його TCP/IP адресу, що часто допомагає встановити доступ до нього навіть у погано сконфігурованих багатодоменних мережних системах. Утім розміщувати працюючі бази даних “далеко” (в сенсі простоти доступу) від сервера застосувань із зрозумілих причин не рекомендовано. Коректність налаштування властивостей компоненти TSQLConnection проконтролюйте успішністю з’єднання з БД (Connected = true). Причиною відсутності зв’язку за правильного визначення місце-знаходження файла БД може бути непрацюючий у даний момент сервер БД, або проблеми з’єднання у мережі між комп’ютерами, які легко виявляються з допомогою системної утиліти PING.

Компонента TSQLConnection встановлює лише канал зв’язку з сервером БД. Для формування ж запитів на вибірку даних у віддаленому модулі даних необхідно мати компоненти набори даних, похідні від класу TDataSet. Їх можна знайти на закладці dbExpress палітри компонент Delphi/C++ Builder. Для прикладу перенесемо в наш модуль даних компоненту TSQLQuery. Після подачі запиту серверу БД (через TSQLConnection) вона отримує результуючі дані вибірки з БД. Для перевірки її роботи вкажіть у властивості SQL довільний коректний запит на вибірку даних, після чого властивість Active спробуйте перевести у значення True. Успішність останньої операції засвідчує працездатність усіх ланок у ланцюжку доступу до інформації в БД. Тепер, за потреби, будь-яка процедура сервера застосувань може потрібним чином використати інформацію в TSQLQuery. Залишилось тільки зробити її доступною для клієнтських програм, котрі функціонують десь у мережі. Для зв’язку з клієнтськими застосуваннями кожна TSQLQuery (чи інша TDataSet) повинна бути з’єднаною з власним провайдером (TDataSetProvider на закладці Data Access) (див. рис. 2). Отже, для обслуговування кожного окремого запиту до БД потрібно мати відповідну пару TDataSet + TDataSetProvider. Проте, на щастя, велика різноманітність запитів зовсім не означає необхідності утримувати у віддаленому модулі даних таке ж велике число згаданих пар завдяки можливості динамічного налаштування властивості SQL компоненти TSQLQuery. Особливістю такого налаштування є те, що його можуть виконувати не тільки процедури самого сервера застосувань, а й набори даних з програм клієнтів, передаючи текст потрібного запиту через TDataSetProvider. Зауважимо, що за замовчуванням (з огляду на безпеку доступу до даних) клієнтські застосування не мають права змінювати згадану властивість. Надання такого права відбувається переведенням у TRUE параметра poAllowCommandText властивості Options відповідного провайдера.

За наявності успішного зв’язку з інформацією в БД скомпілюйте проект сервера застосувань і бодай один раз запустіть отриманий *.exe файл на виконання на тому комп’ютері, де передбачається його подальша робота, для реєстрації отриманого COM сервера в операційній системі Windows.