Недоліки DCE

Механізм RPC є єдиним механізмом взаємодії між процесами. Такий механізм вимагає встановлення з'єднання між клієнтом і сервером. Крім того, виклики RPC є синхронними і блокуючими. Це означає, що застосуванню доводиться чекати завершення кожного виклику. Все це призводить до того, що виклики RPC, як тільки вони стикаються з невеликою пропускною здатністю каналів між клієнтами або іншими «дивацтвами» мережі, працюють незадовільно.

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

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

У DCE немає функціональних можливостей, пов'язаних з організацією черг. Незважаючи на відсутність стандартів на ринку такого ПО, існує принаймні один продукт з організацією черг повідомлень - Encina Recoverable Queuing System фірми Transarc, сумісний з середовищем DCE.

Створення середовища DCE

Планування

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

Одна комірка чи кілька? При вирішенні цього питання необхідно домогтися оптимального співвідношення між вартістю, складністю експлуатації та рівнями сервісу.

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

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

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

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

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

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

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

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

По мірі збільшення числа додатків DCE виникає проблема відстеження версій. Наприклад, багато користувачів хочуть застосувати нові засоби захисту даних і управління зі складу DCE 1.2.Зазвичай перехід на наступну версію не викликає ускладнень, проте деякі утиліти, що використовують DCE, наприклад менеджер транзакцій, не працюють під управлінням DCE 1.2 або підтримують тільки частину її можливостей. Тому в ряді випадків перехід на нову версію доводиться відкладати до появи вдосконалених варіантів утиліт.

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

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

Поиск по сайту: