34. Охарактерізуваті технологію dcom

Технологія COM (Component Object Model) і її варіант для розподілених систем DCOM (Distributed Component Object Model) була розроблена компанією Microsoft. DCOM є розширенням технології СОМ і включає середовище розподілених обчислень DCE (Distributed Computing Environment) і механізм видаленого виклику процедур (RFC — Remote Procedure Calling).

Технологія базується на основних принципах ООП, а саме: повторне використання об’єктів, технологія базується на ідеях поліморфізму та інкапсуляції.

Філософія СОМ полягає в наступному: програма-клієнт використовує при своїй роботі об'єкт (об'єкти) деякій іншої програми (сервера) так, немов ці об'єкти є частиною самого клієнта. Основну роль при цьому грає інтерфейс об'єктів. Під інтерфейсом об'єкту мається на увазі пойменована безліч функціонально зв'язаних методів (операцій) об'єкту. Інтерфейс може формуватися, як правило, за допомогою IDL (Interface Definition Language), спеціального C++ — подібної мови опису інтерфейсів. Клієнт отримує саме інтерфейс об'єкту, що зажадався. Сервер же є програмою, що містить, крім усього іншого, ще один або декілька об'єктів СОМ. Сервер СОМ може створювати реалізації об'єктів з декількох класів, кожен з яких представляє різні варіанти поведінки об'єкту. СОМ-клієнт взаємодіє з СОМ-СЕРВЕРОМ через покажчик на інтерфейс і використовує цей покажчик для виклику методів сервера.

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

DCOM являє собою типовий приклад двухзвенной розподіленої архітектури. При цьому він володіє всіма достоїнствами і недоліками подібної архітектури.

DСОМ містить всі елементи, необхідні для побудови розподіленої системи:

• технологію видаленого виклику методів (як статичних, так і динамічних);

• бази даних серверних об'єктів (бібліотеки типів), які можуть бути імпортовані для аналізу структури серверів СОМ;

• універсальний протокол обміну між клієнтами і серверами;

• специфікації так званих "складених документів" (ActiveDoc);

• об'єктний монітор транзакцій (MTS);

• компонентну модель (ACTIVEX) і ін.

• На основі СОМ булі побудована технологія ACTIVEX (працює лише на цій технології);

• Програма складається із взаємодіючих Сом-обєктів її архітектура визначається принципами взаємодії цих обєктів;

• Кожен Сом-обєкт має свій ідентифікатор, який вноситися до загальгний регістр Сом-обєктів

• Сом-обєкт взаємодіє з іншими через Сом-інтерфейс (набір абстрактних функцій і властивостей;

• Для роботи з Сом-обєктамі є низка спеціалізованих Win32 API;

• Широка підтримка Сом-обєктів забезпечується MFS(це набір стандартних класів Microsoft).

35. Проаналізувати використання программ з багатьма підпроцесами для організації високопродуктивних систем опрацювання даних.

У сучасних ОС вирізняють поняття «процес», «запущена програма» і поняття «нитка» або «підпроцес», яка визначає деякі потоки в рамках одного процесу. У ОС процес визначається ідентифікатором (PID-process ID)деяке ціле число, яку присвоюється ядром ОС.

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

Потік і процес співвідносяться таким чином

• процес має головний потік, що ініціалізував виконання команд процесу;

• будь-який потік може породжувати в рамках одного процесу інші потоки;

• кожен потік має власний стек;

• потоки, відповідні одному процесу, мають загальні сегменти коди і даних.

При розробці багатопотокових застосувань виникають наступні проблеми:

• гонки за даними;

• блокування;

• незбалансованість завантаження.

Гонки за даними (data races) - є наслідком залежностей, коли декілька потоків модифікують вміст однієї і тієї ж області пам'яті. Наявність гонок за даними не завжди є очевидним.

Блокування виникає, якщо потік чекає виконання умови, яка не може бути виконане. Звичайне виникнення тупикової

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

Умови виникнення блокування:

• доступ до ресурсу эксклюзивен (можливий тільки одним потоком);

• потік може утримувати ресурс, запрошуючи інший;

• жоден з конкуруючих потоків не може звільнити запрошуваний ресурс