Borland MIDAS – засіб надійної та ефективної експлуатації багатоланкових інформаційних систем, Інформаційні системи, Бази даних, статті

MIDAS (Multi-tier Distributed Application Services Suite) новий продукт компанії Borland International, призначений для експлуатації серверів додатків, що розширює можливості, що надаються технологією Microsoft DCOM (Distributed Component Object Model). Цей продукт дозволяє використовувати при побудові інформаційних систем триланкову архітектуру з “тонким” клієнтом і, що більш важливо, забезпечити високу продуктивність, надійність і захист від збоїв при експлуатації подібних систем.

Архітектура триланкової інформаційної системи, побудованої з використанням MIDAS, представлена ​​на рис.1.

Рис. 1. Архітектура триланкової інформаційної системи з використанням MIDAS.

Розглянемо, що являють собою технології, використовувані в MIDAS.

Remote Data Broker дозволяє створювати розподілені триланкового інформаційні системи, які з серверної СУБД, середньої ланки і “тонкого” клієнта, при цьому середня ланка може в загальному випадку складатися з декількох серверів додатків і функціонувати на декількох комп’ютерах. Зауважимо, що “тонкий” клієнт являє собою додаток, що не містить бізнес-правил, а лише надає інтерфейс користувача, і з цієї причини не потребує майже ніяких додаткових бібліотек (крім dbclient.dll розміром 140 K), що використовуються звичайними “товстими” клієнтами для доступу до даних (таких, як Borland Database Engine і клієнтська частина серверних СУБД) і, відповідно, практично не потребує відповідної налаштування. Типовим прикладом такого клієнтського додатка є виконувана в Web-броузері форма ActiveX (Створена за допомогою Delphi 3), що містить інтерфейсні елементи для відображення та редагування даних, вся процедура інсталяції і настройки якого полягає у завантаженні відповідної Web-сторінки з Internet або локальної мережі.

Джерелом даних для “тонкого” клієнта є сервер додатків, який отримує від клієнта запити на вибірку або зміну даних. При отриманні такого запиту сервер додатків звертається до сервера баз даних, клієнтом якого він є, зі своїм власним запитом. Отримавши від сервера результат виконання власного запиту, сервер додатків передає дані клієнта.

Як тільки клієнт отримує набір даних від сервера додатків, цей набір може бути використаний компонентом TClientDataset, який, поряд з компонентами TRemoteServer або TMidasConnection (з’явилися в Delphi 3.01 і володіє в порівнянні TRemoteServer більшою функціональністю, зокрема, можливістю вибору способу доступу до сервера), а також підтримує їх функціонування бібліотекою dbclient.dll, складає клієнтську частину Remote DataBroker.

Компонент TClientDataSet призначений для зберігання даних, отриманих від сервера додатків, в кеші клієнта, і, будучи нащадком компонента TDataSet, має, подібно компонентів TTable і TQuery, як навігаційними методами, так і методами, які здійснюють редагування даних. Крім того, цей компонент має методами SaveToFile і LoadFromFile, що дозволяють зберігати дані з кеша у файлі і відновлювати їх звідти, реалізуючи так звану “briefcase model” – модель обробки даних, засновану на тому, що “тонкий” клієнт здійснює редагування даних здебільшого за відсутності з’єднання з сервером, використовуючи лише кеш або локальні зовнішні пристрої, і лише іноді з’єднується з сервером додатків для передачі йому змінених даних з метою подальшої обробки.

Відзначимо також, що Remote DataBroker надає широкі можливості для вирішення характерних для багатокористувацького доступу до даних проблем, пов’язаних зі спробами одночасного редагування кількома користувачами одних і тих же даних. Відзначимо, що в даному випадку механізм блокувань, що використовується в традиційній двухзвенной моделі “клієнт / сервер”, може виявитися неефективним або навіть неприйнятним, так як проміжок часу між редагуванням запису і збереженням її в базі даних може бути досить тривалим. Тому при спробі збереження сервером додатків зміненої записи в базі даних проводиться пошук змінною записи або по ключовому полю, або по всіх полях в залежності від значення властивості UpdateMode відповідального за цей процес компонента TDBDataSet на сервері додатків і порівняння всіх полів змінною записи з вихідними значеннями (тобто тими, які були в кеші клієнта на момент отримання цього запису з сервера до того, як користувач змінив в кеші цей запис). Якщо які-небудь поля за час між отриманням оригіналу запису клієнтом і спробою зберегти зміни були модифіковані іншим користувачем, запис може бути передана назад в клієнтське додаток для подальшої обробки користувачем.

Відзначимо також, що віддалені модулі даних (об’єкти Remote Data Module), що входять до складу серверної частини Remote DataBroker і містять компоненти TDBDataSet, дозволяють надати DCOM-інтерфейс для відповідних об’єктів, роблячи їх керованими ззовні і перетворюючи, таким чином, сервер додатків в DCOM-сервер. Здійснюється така публікація об’єктів шляхом вибору опції експорту з віддаленого модуля даних з контекстного меню відповідного компонента при розробці сервера додатків.

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

Використання Business ObjectBroker і OLEnterprise (Складової частини MIDAS) дозволяє вирішити подібну проблему (при цьому неістотно, який засіб розробки використовувалося для створення сервера додатків, аби це був сервер OLE Automation).

Рис. 2. Склад OLEnterprise.

Business ObjectBroker здійснює для “тонкого” клієнта пошук потрібного сервера додатків серед опублікованих (тобто доступних ззовні) частин реєстрів комп’ютерів мережі (сукупність опублікованих частин реєстрів іноді називається глобальним реєстром – global registry).

Додаток Object Factory, Що використовується сервером, є клієнтом OLE Automation. Воно діє на сервері від імені віддаленого клієнта, “представляючи” його шляхом відтворення його запитів. З боку клієнта є відповідний “Представник” віддаленого сервера додатків – Object Agent, Що є сервером OLE Automation. Отримавши запит до віддаленого серверу, Object Agent направляє його до Object Factory, використовуючи механізм виклику віддалених процедур (RPC – Remote Procedure Call).

Рис. 3. Object Explorer

Утиліта Object Explorer (рис.3), що входить до складу OLEnterprise, дозволяє переглядати локальний і глобальний реєстри, а також здійснювати експорт (публікацію) відомостей про об’єкти з локального реєстру в глобальний та імпорт цих відомостей з глобального реєстру в локальний, здійснюючи, таким чином, межреестровий обмін відомостями про віддалених серверах додатків в мережі. Якщо в мережі є кілька комп’ютерів, на яких встановлений і зареєстрований один і той же сервер додатків, при запиті “тонкого” клієнта Object Agent звернеться до Business ObjectBroker за відомостями про місцезнаходження сервера, а той, у свою чергу, знайде для нього в глобальному реєстрі один з цих комп’ютерів. Після цього Object Agent звернеться до Object Factory обраного комп’ютера, ініціюючи створення екземпляра віддаленого модуля даних на сервері додатків.

Який принцип вибору одного сервера додатків з декількох? В даний час сервер вибирається випадковим чином серед комп’ютерів, доступних в мережі. У разі відмови одного з серверів для з’єднаних з ним клієнтів, які не отримали відгуку від сервера, буде автоматично повторена процедура, описана вище, і ці клієнти будуть з’єднані з рештою серверами випадковим чином без участі користувача і непомітно для нього. В даний час ведеться розробка більш ефективної технології вибору сервера, що використовує відомості про завантаження процесорів і мережевому трафіку функціонуючих в мережі серверів, що дозволить більш рівномірно розподіляти навантаження між серверами.

Відзначимо також, що в глобальний реєстр можна включати відомості про RPC-серверах, що функціонують не тільки в операційних системах Windows 95 і Windows NT, а й в інших операційних системах.

Ще однією важливою складовою частиною MIDAS є ConstraintBroker, Що надає можливість використовувати бізнес-правила сервера баз даних “тонким” клієнтом. Зазвичай при проектуванні баз даних бізнес-правила і правила посилальної цілісності реалізуються у вигляді об’єктів бази даних, таких як індекси, тригери, збережені процедури. Такий підхід до проектування даних дозволяє використовувати ці об’єкти різними клієнтськими додатками без написання додаткового коду.

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

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

При використанні ConstrainBroker ця проблема вирішується по-іншому. В цьому випадку RemoteDataBroker не тільки доставляє дані клієнтського додатку, а й звертається до словника даних з метою отримання обмежень сервера і передачі їх клієнтові. Відповідно при спробі передачі записи на сервер додатків аналіз відповідності записи правилами сервера виробляється безпосередньо в клієнтському додатку без звернення до сервера баз даних і серверу додатків, що знижує завантаження серверів та мережі. Зазначимо, що при зміні бізнес-правил слід внести відповідні зміни до словника даних, що можна зробити за допомогою входить до складу MIDAS утиліти SQL Explorer (рис.4), що дозволяє вносити серверні обмеження, а також створювати і змінювати таблиці, індекси, тригери, збережені процедури, правила посилальної цілісності.

Рис. 4. SQL Explorer

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

На закінчення відзначимо, що розробка серверів додатків за допомогою Delphi 3 може бути здійснено за допомогою trial-версії MIDAS, що входить в комплект поставки Delphi 3 Client / Server Suite і має обмежене число підключаються клієнтів та об’єктів, доступних Business ObjectBroker, а також обмеження на час роботи ConstrainBroker. Однак експлуатація серверів додатків вимагає обов’язкової наявності на комп’ютерах, містять сервери додатків, повної версії MIDAS (мал. 5), не володіє перерахованими вище обмеженнями.

Рис. 5. Склад Borland MIDAS


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


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

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

Ваш отзыв

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

*

*