Главная страница
Навигация по странице:

  • Зміст лекції

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

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

  • конспект лекцій (ТСПП). Конспект лекцій з дисципліни 07 технологія створення програмних продуктів напряму 050101 Компютерні науки


    Скачать 14.87 Mb.
    НазваниеКонспект лекцій з дисципліни 07 технологія створення програмних продуктів напряму 050101 Компютерні науки
    Анкорконспект лекцій (ТСПП).docx
    Дата15.12.2017
    Размер14.87 Mb.
    Формат файлаdocx
    Имя файлаконспект лекцій (ТСПП).docx
    ТипКонспект
    #11579
    страница23 из 62
    1   ...   19   20   21   22   23   24   25   26   ...   62

    Тема 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+ сервісів.
    1   ...   19   20   21   22   23   24   25   26   ...   62


    написать администратору сайта