Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
конспект лекцій (ТСПП).docx
Скачиваний:
213
Добавлен:
01.05.2015
Размер:
15.59 Mб
Скачать

Лекція № 6

Тема 6. Технологія компонентного програмування (реалізація СОМ, COM+, DCOM).

План лекції

1.Вступ до компонентного програмування.

2.Основні поняття COM технологій.

3.Інтерфейс COM –об’єктів.

Самостійна робота

4. Ідентифікатори, використовувані в СОМ технології

5. Технологія DCOM. Технологія COM+

Зміст лекції

Технологія COM+ від Microsoft

COM+ можна назвати версією COM для Windows 2000. Але, насправді, це не просто чергова версія деякого продукту.

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

На відміну від локального застосування, в роботу з розподіленим застосуванням залучено багато кінцевих користувачі, які, з точки зору адміністратора системи, повинні мати різні права доступу до даного додатку. У COM+ вирішуються наступні питання:

Аутентификация клиента

Тот ли он, за кого себя выдает ?

  • Авторизация клиента

Какие операции может выполнять данный клиент ?

  • Передача полномочий

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

Транзакції

Транзакції забезпечують цілісність даних в розподіленій системі. Помітимо, що СУБД забезпечують механізм транзакцій, але тільки у рамках однієї бази даних. Тут же в одну розподілену транзакцію можуть бути залучені різні незалежні сховища даних.

Синхронізація

У COM синхронізація доступу до об' єктів з різних потоків здійснюється за допомогою використання механізму апартаментів. Практика програмування показує, що рідкісні програмісти проектують потоко-безопасные компоненти, які можуть жити в таких апартаментах як MTA і NA. Як правило, використовується STA, і доступ до усім об' єктам, що живуть в одному STA, синхронізується самою системою за допомогою черги повідомлень. COM+ йде на зустріч реальним перевагам програмістів, пропонуючи можливість задавати синхронізацію доступу об' єктам декларативним чином. При цьому, навіть об' єкти, що живуть в MTA або NA, можуть бути захищені від паралельного звернення.

Черги (асинхронна комунікація)

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

У COM+ реалізується нова по відношенню до COM модель подій. Стає можливою публікація деякій інформації одними об' єктами і підписка на отримання цієї інформації іншими. Сервіс подій забезпечує необхідний механізм для реалізації цієї моделі.

У COM+ розрізняють створення/видалення об' єкту і його активацію/деактивацію. У ряді випадків вигідно створити деяке число об' єктів потрібних типів, а потім виконувати активацію / деактивацію об' єктів, поміщаючи об' єкт, що деактивує, в так звань пул об' єктів, і витягаючи об' єкт потрібного типу з пулу об' єктів при активації.

Деякі таблиці з баз даних, які часто використовуються тільки для читання, можуть розміщуватися в оперативній пам' яті машин середнього рівня (рівень бізнес - логіки в Windows DNA архітектурі).

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

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

Використання декларативного підходу в даному випадку має ряд переваг в порівнянні з процедурним :

  • Зменшується час на розробку додатка

  • Підвищується надійність коду. Автоматично згенерований код надійніше створеного програмістом, оскільки він пройшов об'ємніше тестування

  • Зменшується міра залежності додатка від конкретної версії платформи (COM+)

Поки не змінена семантика, приписана атрибутам, це застосування працюватиме з усіма наступними версіями платформи.Атрибути фактично вже приписувалися компонентам і додатку вже в COM. Наприклад, шкірному класу приписувався його унікальний CLSID, шлях до сервера (DLL або EXE файлу), потокова модель (ThreadingModel). Проте можливості реєстру обмежені, і для зберігання великого числа додаткових атрибутів, що з'явилися в COM+, використовується додаткова база даних - так звань COM+ каталог. Є менеджер каталогу, у якого є доступ як до реєстру системи, так і до каталогу. Розробник і адміністратор дістають доступ до каталогу через утиліту Component Services, або через ієрархію об' єктів, що надаються системою.

У цьому курсі питання адміністрування спеціально розглядатися не будуть. Використовуючи Component Services нескладно задати необхідний набір атрибутів для нового застосування. Єдине, що для цього потрібне - розуміння наявних у COM+ сервісів.