Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

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

Транзакції

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

План лекції

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

Лекція № 6

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+ сервісів.

<== предыдущая лекция | следующая лекция ==>
Реляційні особливості SQL Server | Інкапсуляція
Поделиться с друзьями:


Дата добавления: 2014-01-04; Просмотров: 312; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.011 сек.