MIDAS і створення серверів додатків

Наталія Єлманова, Центр інформаційно Технологій

Після виходу статті "Створення серверів додатків за допомогою Delphi 3" від читачів і слухачів проводяться в Навчально-консалтинговому центрі Interface Ltd. курсів, присвячених Delphi 3 і MIDAS, надійшла велика кількість питань, що стосуються технічних та організаційних аспектів розробки та експлуатації триланкового інформаційних систем з "тонким" клієнтом. Дана стаття присвячена особливостям і найбільш переважним архітектура побудови подібних інформаційних систем у випадку різних схем організації функціонування обслуговуваних ними підприємств, нових можливостей створення "тонких" клієнтів, які надаються Delphi 3.01/3.02 і С + + Builder 3.0, відповідей на найбільш часто зустрічаються, а також найбільш розповсюджених помилок при створенні серверів додатків і "тонких" клієнтів.

Різні архітектури побудови триланкового інформаційних систем

Нерідко у потенційних користувачів MIDAS виникають питання про способи побудови багатоланкових інформаційних систем, найбільш відповідають потребам саме їх підприємства, у тому числі питання про те, скільки потрібно мати серверів додатків, як конфігурувати клієнтські робочі станції, які можливості здійснення і зміни конфігурації робочих станцій віддалено, наприклад, через Internet або за допомогою модемного зв'язку.

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

Перший часто зустрічається випадок - велике або середнє підприємство, розташоване компактно і має загальну локальну мережу. У цьому випадку нерідко корпоративні дані зберігаються в загальній для всіх серверної СКБД. Перехід до триланкової архітектурі в цьому випадку проводиться головним чином з метою зниження витрат, пов'язаних з конфігурацією робочих станцій (встановлення та налаштування клієнтської частини серверної СКБД, настроювання BDE, оновлення версій автоматизованих робочих місць) і підтримкою їх в робочому стані, і, по другу чергу - з метою зниження мережевого трафіку і підвищення надійності експлуатації системи в цілому. У цьому випадку найбільш прийнятним представляється наявність у мережі декількох комп'ютерів, на яких встановлені MIDAS і OLEnterprise і експлуатуються одні й ті самі сервери додатків, при цьому відомості про них експортовані до глобального реєстру (наприклад, за допомогою утиліти Object Explorer). На робочих станціях в цьому випадку встановлюється Run-time -- версія OLEnterprise, і всі описи серверів додатків імпортуються в локальні реєстри. При такій конфігурації робочі станції підключаються до серверів додатків випадковим чином і в разі відмови одного з серверів ці підключення виявляться рівномірно розподіленими по іншим серверам.

В випадку дуже великого числа користувачів і високої інтенсивності транзакцій можна рекомендувати як альтернативу "саморобним" серверів додатків сервери додатків Borland Entera, які, на відміну від серверів, створених за допомогою Delphi, можуть керуватися не тільки допомогою Windows 95 і Windows NT, але і за допомогою інших операційних систем (зокрема, різних версій Unix). У цьому випадку замість Delphi Client/Server Suite слід використовувати Delphi Enterprise, що дозволить створити "тонких" клієнтів для використання Entera як сервер додатків.

Другий випадок, характерний, зокрема, для багатьох підприємств нафтової і газової промисловості, великих торгових об'єднань, а також різних міжрайонних та міжрегіональних служб, від податкових інспекцій до авіаційних кас -- підприємство, що має кілька територіально розкиданих підрозділів (можливо, навіть в різних містах), не зв'язаних локальною мережею між собою. Нерідко такі підприємства мають кілька локальних інформаційних систем і набір пов'язаних з цим проблем, таких, як підтримка актуальності даних під всіх цих інформаційних системах, реплікація даних, об'єднання даних з декількох інформаційних систем для їх спільного аналізу та складання підсумкових зведень та звітів. Перехід до триланкової архітектурі в разі таких підприємств здійснюється з метою усунення цих проблем та організація централізованого зберігання і обробки даних (а нерідко також з метою зниження тих самих витрат на конфігурацію робочих станцій, що і в попередньому випадку). Звичайно в цьому випадку найбільш прийнятним представляється установка сервера баз даних і сервера додатків в центральному офісі (не обов'язково на одному і тому ж комп'ютері), при цьому останній повинен бути оснащений MIDAS і бути доступним через Internet. Робочі станції філій повинні бути оснащені Internet Explorer 3.0 і вище, при цьому і розробники, і користувачі робочих станцій видалених філій повинні мати доступ не тільки до комп'ютера, що містить сервер додатків, але і до будь-якого web-сервера (його місце розташування не грає істотної ролі, оскільки перші лише відправляють туди нові версії "тонких" клієнтських додатків, а друга вивантажувати їх на свої робочі станції). У цьому випадку ніяких особливих вимог до робочих станцій, крім наявності Internet Explorer 3.0, а також доступу в Internet, немає. У цьому випадку, природно, також можливе використання Borland Entera і Delphi Enterprise замість MIDAS і Delphi Client/Server Suite.

В разі неможливості доступу через Internet можливі інші варіанти, такі, як використання виділеної лінії, модемний зв'язок та ін Реалізація зв'язку не так принципова - аби при цьому була можливість використання протоколу TCP/IP. Природно, при частих збоїв і розривах з'єднання рекомендується активно використовувати кешування даних на робочих станціях, зберігати вміст кеша в файлах і завантажувати їх звідти, благо у компонента TClientDataSet є методи SaveToFile і LoadFromFile.

Можливі різні комбінації цих варіантів, наприклад, доступ по протоколу TCP/IP і наявність кількох однотипних серверів додатків. Дати рекомендації на всі випадки життя, звичайно, неможливо, але наявні завдяки коштам розробки Borland технічні можливості надають розробникам і керівникам відділів автоматизації досить великий простір для фантазії при організації інформаційних систем підприємств, і достатній вибір варіантів їх побудови.

Створення сервера додатків і "тонкого" клієнта з доступом через TCP/IP в Delphi 3.01/3.02 і в С + + Builder 3.0.

Створені за допомогою Delphi 3.0 клієнт і сервер додатків могли взаємодіяти за допомогою OLEnterprise або DCOM. У версії Delphi 3.01появілась також можливість організувати зв'язок клієнта і сервера безпосередньо за допомогою протоколу TCP/IP. Для цього в палітрі компонентів останніх версій Delphi (3.01 і 3.02) є компонент TMidasConnection, що володіє більшою функціональністю в порівнянні з TRemoteServer з Delphi 3.0. Цей компонент дозволяє вибрати тип з'єднання з сервером додатків (DCOM, OLEnterprise, безпосереднє використання протоколу TCP/IP). При його використанні процес створення сервера додатків і клієнта помітно спрощується, тому що у випадку доступу по протоколу TCP/IP в загальному випадку немає необхідності мати в реєстрі комп'ютера, на якому встановлено "тонкий" клієнт, будь-які відомості про сервері додатків. Розглянемо найпростіший приклад створення такої системи.

Почнемо з створення сервера додатків. Створимо головну форму додатку, основне призначення якої - служити індикатором запущеного сервера. З цією метою можна розмістити її де-небудь у кутку екрану, а властивість FormStyle встановити рівним fsStayOnTop, щоб не втратити це вікно серед інших відкритих вікон. Далі слід створити видалений модуль даних, вибравши піктограму Remote DataModule з сховища об'єктів, помістити в нього компонент TTable або TQuery, встановивши необхідні значення властивостей DatabaseName і TableName. Властивість Active також слід встановити рівним True (або встановити його динамічно при створенні модуля даних). В іншому випадку компонент не буде містити ніяких даних, і тим більше надавати їх клієнтського додатку (рис.1).

Рис.1. Форма і видалений модуль даних сервера додатків

Потім потрібно обов'язково експортувати цей компонент з модуля даних (або зв'язати його з компонентом TProvider і експортувати останній). Якщо цього не зробити, клієнтська програма не буде мати доступу до цього об'єкта (ця помилка є досить типовою). Основне призначення віддаленого модуля даних полягає саме в наданні що містяться в ньому компонентів доступу до даними можливості бути видимими і керованими ззовні, тобто з інших додатків (і в загальному випадку - з інших комп'ютерів, в тому числі доступних НЕ тільки за допомогою локальної мережі, але і за допомогою Internet). Проконтролювати наявність у віддаленому модулі даних об'єктів, видимих ззовні, можна, переглянувши відповідну бібліотеку типів (рис.2).

Рис.2. Бібліотека типів, пов'язана з віддаленим модулем даних

Якщо для доступу до даних необхідний компонент TDatabase, його зазвичай розміщують на головною формою додатка, або в звичайному модулі даних. Чому при використанні компонента TDatabase його зазвичай не поміщають у віддалений модуль даних? Якщо цей компонент розмістити в віддаленому модулі даних, то можуть виникнути проблеми, пов'язані з тим, то за кількох підключених можуть бути конфлікти між кількома його екземплярами - адже кожне нове підключення створює свій екземпляр віддаленого модуля даних. Тому слід подбати про різних іменах сесії користувачів, щоб уникнути таких конфліктів, або, якщо це дозволяють міркування безпеки, використовувати для всіх підключень загальний компонент TDatabase.

Потім, якщо є бажання проконтролювати число які об'єдналися з сервером клієнтів, можна створити обробники подій OnCreate і OnDestroy віддаленого модуля даних, у яких значення будь-якої цілої змінної відповідно збільшується або зменшується на одиницю і при необхідності відображається в будь-якому интерфейсному елементі головної форми сервера додатків.

Після цього сервер додатків можна скомпілювати і запустити на виконання. Це потрібно для того, щоб зареєструвати його як OLE-сервер в реєстрі Windows. За приводу реєстрації сервера також слід зробити одне зауваження. Автору довелося спостерігати випадок, коли системний адміністратор зумів налаштувати операційні системи на комп'ютерах розробників відділу автоматизації одного з московських підприємств таким чином, що у них не було ніякої можливості змінювати щось у своїх реєстрах. При цьому, природно, і сервери додатків також у реєстрах не реєструвалися. Якщо при створенні сервера додатків він не реєструється в реєстрі, можливо, цей випадок подібний до описаного. А може Можливо, просто помилково замість віддаленого створений звичайний модуль даних ...

Якщо узагальнити даний випадок, то, образно кажучи, сервери додатків такого класу зобов'язані містити або генерувати якийсь набір SQL-запитів для змін в базі даних і послати на сервер баз даних по команді клієнтського додатку. Наш сервер додатків використовує для генерації запитів бібліотеку Borland Database Engine. Інші сервери додатків, такі, наприклад, як Borland Entera, використовують інші механізми створення запитів, обумовлені певною мірою тією платформою, на якій цей сервер додатків функціонує. У будь-якому випадку саме набір SQL-запитів є самою головною складовою функціональності такого сервера додатків. Що ж до призначеного для користувача інтерфейсу сервера додатків (форма з лічильником підключень або щось в цьому роді), він зовсім необов'язковий. Врешті-решт, сервер додатків може не мати головної форми або не показувати її, або може бути запущений у вигляді сервісу. Якщо ж говорити знову про загальному випадку (коли мова йде не тільки про сервери додатків, створених за допомогою Delphi, але і про інших подібних серверах додатків, у тому числі для інших платформ), то ж не всі платформи володіють графічним інтерфейсом користувача, і, отже, створення такого об'єкта, як форма, можливо не на всіх платформах. Не варто спокушатися -- найдорожчі сервери додатків нерідко просто запускаються з командного рядка і не мають інтерфейс у звичному для користувачів Windows розумінні.

В відомому сенсі сервер додатків і "тонкий" клієнт представляють собою розділене на дві частини класичне клієнтський додаток, зване в сукупності з клієнтом серверної СКБД і бібліотеками доступу до даних, такими як BDE, "товстим" клієнтом. Перша частина (створений нами сервер додатків) містить компоненти доступу до даних (і вимагає наявності BDE і клієнта серверної СКБД), а друга (клієнт) повинна містити користувальницький інтерфейс (і не вимагати наявності BDE і клієнтської частини серверної СКБД).

Перш ніж приступити до створення "тонкого" клієнта, запустимо Borland MIDAS Socket Server scktsrvr.exe (його можна знайти в каталозі Delphi 3.0Bin), що надає доступ ззовні до наявних на даному комп'ютері серверів додатків, створених за допомогою Delphi 3, по протоколу TCP/IP. Відзначимо, що в цьому випадку будь-який з наявних серверів додатків може бути запущений з будь-якого комп'ютера, що має доступ до Вашого комп'ютера за допомогою даного протоколу, тому при використання подібних систем слід розглядати різні питання, пов'язані з безпекою їх експлуатації.

Рис.3. Borland MIDAS Socket Server

Тепер, нарешті, можна створити клієнтську програму. Для цього створимо звичайну форму (або виберемо зі сторінки ActiveX сховища об'єктів піктограму ActiveForm для створення клієнтського компоненту ActiveX). На форму помістимо компонент TMidasConnection і встановимо його властивість ComputerName рівним IP-адресою комп'ютера, на якому повинен виконуватися сервер додатків. Якщо цей комп'ютер в даний момент доступний в мережі, можна вибрати його ім'я зі списку, з'являється при натисканні навпроти імені цієї властивості. Але треба розуміти, що в загальному випадку, особливо якщо клієнтський додаток призначений для доступу до сервера через Internet, вказівка саме IP-адреси є більш кращим. Далі слід встановити значення властивості ServerName в наступному форматі: <ім'я файлу, що виконується>. <ім'я OLE-сервера>, наприклад MyAppSrv.MyRemDataMod1. Властивість ServerGUID можна не встановлювати. Якщо сервер додатків не зареєстрований на комп'ютері, де розробляється клієнт, значення цієї властивості має залишитися порожнім, і це не завадить спільній роботі сервера і клієнта - адже в загальному випадку при розповсюдженні клієнтського застосування або ActiveX через Internet в реєстрі комп'ютера, де воно буде виконуватися, немає і не може бути відомостей про сервері додатків.

Властивість Connected можна встановити рівним True (або зробити інсталяцію цієї властивості рівним True на етапі виконання в момент створення форми клієнтського додатки). Після цього має запуститися сервер додатків (у тому числі віддалений).

Далі слід помістити на форму компонент TClientDataSet, вибрати ім'я компонента TMidasConnection в якості значення властивості RemoteServer і вибрати значення властивості Provider зі списку об'єктів, експортованих з віддаленого модуля даних сервера додатків. Тепер можна встановити властивість Active рівним true. Далі слід помістити на форму компонент TDataSource і пов'язати його з компонентом TClientDataSet.

Після цього можна зайнятися для користувача інтерфейсом, помістивши на форму необхідні компоненти відображення даних (рис. 4). Слід також як обробника якого-небудь події викликати метод ApplyUpdates компонента TClientDataSet, інакше зміни будуть накопичуватися в кеші і не будуть зберігатися в базі даних.

Рис. 4. Активна форма на етапі проектування.

Далі можна запустити і протестувати клієнтську програму, а якщо він виконаний у вигляді ActiveX - здійснити його постачання на Web-сервер разом з бібліотекою dbclient.dll і протестувати, звернувшись до згенерованої HTML-сторінці (мал. 5).

Рис.5. Тестуєованіе "тонкого" клієнтського застосування

Відзначимо також, що можна звернутися до створеної HTML-сторінці з іншого комп'ютера локальної мережі.

Слід звернути увагу на те, що web-сервер зовсім не зобов'язаний перебувати на тому ж самому комп'ютері, що і сервер додатків. Призначення web-сервера в такій інформаційній системі вельми утилітарно - він є лише сховище, звідки можна вивантажити ActiveX, і нічого більше. Якщо говорити про передачі ActiveX через Internet та доступ до сервера додатків через Internet, то в принципі можлива ситуація, коли сервер додатків, Web-сервер і користувач знаходяться у трьох різних містах, користувач звертається до свого провайдера у своєму місті, а як саме він отримує ActiveX і звертається до сервера додатків, його як користувача Internet цікавити не повинно.

Нерідко при створенні таких ActiveX задаються запитання на кшталт: "А якщо додаток повинно містити кілька форм, що мені робити? ". Відповідь досить простий: у цьому випадку можлива генерація додаткових форм динамічно при настанні якої-небудь події (наприклад, натискання на кнопку). Потрібно тільки не забути знищити створену форму, коли вона стане не потрібна. Слід також пам'ятати, що бібліотека OCX, що містить ActiveX, що містить, у свою чергу, кілька форм, буде мати більший розмір, ніж у випадку ActiveX c однієї формою.

Досить часто зустрічаються питання, пов'язані з тим, що ActiveX не відображається в броузері. Ось один з таких листів:

Здравствуйте, Наталія Єлманова!

Прочитав вашу статтю на Web-сайті www.interface.ru. Пробую створити сервер додатків з використанням ActiveForm. Після створення і перенесення CAB-файлу і Web-сторінки на Web-сервер сторінка відкривається, але на місці передбачуваної аплікації тільки квадратик. Поясніть, в чому може бути проблема.

З повагою Слава. [email protected]

Причин такої поведінки може бути кілька. Перша причина пов'язана з тим, що далеко не всі броузери підтримують відображення ActiveX за допомогою тега