1. Крос-платформне програмування
Лекція 16
Проміжне програмне забезпечення
10 червня, 2015
Примітка: частину слайдів лекції підготовлено за
матеріалами курсу А.Г. Анатольєва, АСОИУ ОмГТУ -
http://www.4stud.info/networking/lecture6.html
2. • Брокери об’єктних запитів
• Монітори оброблення транзакцій
• Виклики віддалених процедур
• Вибір застосування, сервісів, компонентів і
протоколів зв’язку
3. На минулій лекції: гетерогенність
• Гетерогенні системи - міститять цілий набір
незалежних комп'ютерів, з'єднаних різноманіт-
ними мережами
– Різні мережеві інфраструктури, АП та ПЗ, мови про-
грамування (і подання даних)
– Відмінності потрібно
приховати
– Приклад: Інтернет
• Гомогенні системи –
одна мережа, яка
з'єднує комп'ютери
та використовує
одну технологію
– Приклад: кластери
ІК – інтерфейс користувача
ЛП – логіка прикладних
програм
ДД – доступ до даних
4. На минулій лекції: Як приховати відмінності?
• Middleware - проміжне ПЗ між платформою і
компонентами розподіленого застосування
– Призначене для об'єднання компонентів розподіленого
клієнт-серверного застосування або цілих мережевих
застосуваннь в єдину систему
– Термін вперше з’явився у 1968 р.
• Приклади: CORBA, Java RMI, Microsoft DCOM
5. Модель взаємодії відкритих систем OSI/ISO
• Проміжне ПЗ охоплює рівні
– Подання данних - розуміння та подання інформації
– Сеансовий - керування сеансами зв’язку між прикладними
процесами
6. Завдання проміжного ПЗ
• забезпечення єдиного і незалежного від ОС
механізму використання одними програмними
компонентами сервісів інших компонентів
• забезпечення безпеки розподіленої системи
• забезпечення цілісності даних
• знаходження віддалених компонент
7. Види проміжного ПЗ
• ПЗ для міжпрограмної взаємодії (Inter-Process
Communication, IPC)
– Сервіси обробки повідомлень
– Виклики віддалених процедур
– Монітори обробки транзакцій
– Брокери об'єктних запитів
• ПЗ доступу до баз даних
– Власне проміжне програмне забезпечення СКБД
– Основне проміжне програмне забезпечення баз
данных
8. Синхронна та асинхронна взаємодії
• Синхронна (synchronous) - взаємодія між
компонентами, за якої клієнт, відіславши запит,
блокується і може продовжувати роботу тільки
після отримання відповіді від сервера
– З цієї причини такий вид взаємодії називають іноді
блокуючим (blocking)
– Приклад: віддалений виклик процедур (в середині
80х років розробила компанія XEROX)
• Асинхронна (asynchronous) або неблокуюча (non
blocking) - клієнт після відправки запиту
серверу може продовжувати роботу, навіть якщо
відповідь на запит ще не надійшла
– Приклад: обмін повідомленнями
9. Сервіси обробки повідомлень
• MOM (message-oriented middleware) - системи,
зазвичай асинхронні, в яких взаємодія між
клієнтом і сервером заснована на обміні
повідомленнями
– Повідомлення - текстові блоки, які складаються з керуючих
команд и даних, що передаються. Для передачі повідомлень
використовується байт-ориєнтовані протоколи (HTTP,
POP/SMTP и т.п.)
• Безпосередній обмін повідомленнями (message
passing)
– Відбувається безпосередня передача, яка можлива лише у
тому випадку, якщо приймаюча сторона готова прийняти
повідомлення в цей момент часу
– Приклад: використання транспортного рівня мережі через
інтерфейс сокетів, минаючи будь-яке проміжне ПЗ
• Черги повідомлень (message queuing, MQ)
10. Черги повідомлень
• Використовується посередник – менеджер черг
повідомлень
– Компонента посилає повідомлення в одну з черг менеджера,
після чого продовжує свою роботу. Сторона, що одержує
повідомлення, вилучить його із черги менеджера та
приступить до його обробки
– Підійде для реалізації потоків робіт і підтримки застосувань у
глобальних мережах з повільними і не дуже надійними
з’єднаннями
– Приклад: електронна пошта
– Реалізації
» Microsoft
Message Queuing
(MSMQ)
» IBM MQSeries
» Sun Java System
Message Queue
11. Віддалений виклик процедур
• Віддаленого виклику процедур (remote procedure
call, RPC) - за допомогою проміжного ПЗ функцію
на віддаленому комп'ютері можна викликати так
само, як і функцію на локальному комп'ютері
• Характерні риси
– Асиметричність – ініціатором є одна з взаємодіючих сторін
– Синхронність – виконання процедури, що викликає,
призупиняється з моменту видачі запиту і відновлюється
тільки після повернення з викликається процедури
• Реалізація істотно складніше реалізації викликів
локальних процедур
– Процедури виконуються на різних машинах, тому мають різні
адресні простори, що створює проблеми при передачі
параметрів і результатів
– Обов'язково використовує транспортний рівень мережевої
архітектури, але це залишається прихованим від розробника
– В реалізації RPC беруть участь як мінімум два процеси, кожен
з яких може аварійно завершиться
– Неоднорідністю мов програмування і операційних середовищ
12. Виконання виклику локальної процедури
• count = read(fd,buf,nbytes);
– Процедура, що викликає, заштовхує параметри у стек у
зворотному порядку
– Після виконання виклику функції read значення, що
повертається, та адреса повернення поміщаються в регістр
– Управління повертається процедурі, що викликає, яка
вибирає параметри зі стека, повертаючи його в початковий
стан
13. Етапи виконання RPC
• Заглушки (stub) - спеціальні компоненти, до яких звер-
таються клієнтський і серверний процеси для установки
зв'язку, передачі виклику і повернення результату
• RPC звернення клієнта (імена функцій і списки парамет-
рів) упаковуються клієнтської заглушкою в мережеві
повідомлення (т.з. маршалінг) і передаються серверній
заглушці
• Маршалінг або серіалізація (marshalling) - упаковка
параметрів викликів в потік байт стандартним чином, що
не залежить від архітектури
• На стороні сервера
серверна заглушка
розпаковує параметри
і поміщає їх у стек
• Після виконання
процедури сервер
передає результати
клієнтові
14. Розподіл часу між 14 етапами виконання
RPC
1 Виклик стабу
2 Підготувати буфер
3 Упакувати параметри
4 Заповнити поле заголовка
5 Обчислити контрольну суму в
повідомленні
6 Переривання до ядра
7 Черга пакету на виконання
8 Передача повідомлення контролеру
9 Час передачі по мережі Ethernet
10 Отримати пакет від контролера
11 Процедура обробки переривання
12 Обчислення контрольної суми
13 Перемикання контексту у простір
користувача
14 Виконання серверного стабу
15. Різновиди RPC
• Синхронний виклик
– клієнт очікує завершення процедури сервером і при
необхідності одержує від нього результат виконання
віддаленої функції
• Односпрямований асинхронний виклик
– клієнт продовжує виконання свого завдання, одержання
відповіді сервера або відсутнє, або його реалізація якось
інакше передбачена при розробці
• Асинхронний виклик
– клієнт продовжує своє виконання, при завершенні
сервером виконання процедури він одержує
повідомлення й результат її виконання, наприклад, через
callback-функцію, що викликається проміжним
середовищем при одержанні результату від сервера
16. Віддалений виклик процедур
• Засоби RPC призначені для полегшення органі-зації
розподілених обчислень
• Найбільша ефективність використання дося-гається
т.з. RPC-орієнтованих застосуваннях - в яких існує
інтерактивний зв'язок між віддаленими
компонентами з невеликим часом відповідей і
відносно малою кількістю даних, що передаються
• Реалізації
– Sun RPC (бінарний протокол на базі TCP та UDP)
– Net Remoting (бінарний протокол на базі TCP, UDP, HTTP)
– XML-RPC (текстовий протокол на базі HTTP)
– SOAP — Simple Object Access Protocol (текстовий протокол
на базі HTTP)
– Java RMI — Java Remote Method Invocation
– JSON-RPC JavaScript Object Remote Procedure Calls
(текстовий, на базі HTTP)
17. Використання віддалених об'єктів
(remote method invocation, RMI)
• Віддалений об’єкт - представляє собою деякі дані,
сукупність яких визначає його стан. Цей стан можна
змінювати шляхом виклику його методів
– Методи й поля об'єкта, які можуть використовуватися
через віддалені виклики, доступні через деякий
зовнішній інтерфейс класу об'єкту
– Клієнтська заглушка називається посередником
(proxy). Посередник реалізує той же інтерфейс, що й
віддалений об'єкт
– Заглушка на стороні
сервера називається
каркасом (skeleton)
18. Моделі використання віддалених об'єктів
• Єдиного виклику
– Об'єкт активується на час єдиного віддаленого виклику.
В найпростішому випадку для кожного виклику
віддаленого методу об'єкта клієнтом на сервері
створюється й активується новий екземпляр об'єкта, що
деактивується і потім знищується відразу після
завершення віддаленого виклику методу об'єкта
• Єдиного екземпляра
– Віддалений об'єкт існує не більш ніж в одному
екземплярі. Створений об'єкт існує, поки є хоч один
клієнт, що використовує його
• Активації об'єктів по запиту клієнта
– При кожному створенні клієнтом посилання на
віддалений об'єкт (точніше, на посередника) на сервері
створюється новий об'єкт, що існує, поки клієнт не
видалить посилання на посередника
19. Транзакції
• Транзакція – послідовність операцій з якими-
небудь даними, що або успішно виконується
повністю, або не виконується взагалі
• Властивості транзакції
– Атомарність (atomicity) - транзакція виконується за
принципом "все або нічого"
– Погодженість (consistency) - після успішного
завершення або відкоту транзакції всі дані перебувають
у погодженому стані, їхня логічна цілісність не
порушена
– Ізоляція (isolation) - одночасний доступ транзакцій
різних застосувань до спільних ресурсів координується
таким чином, щоб виключити їх вплив один на одного
– Сталість (durability) - у випадку успішності транзакції
зроблені зміни повинні мати постійний характер
20. Розподілені транзакції
• Розподілена транзакція – транзакція, що охоплює
операції декількох взаємодіючих компонент РС
• Монітори обробки транзакцій (Transaction Processing
monitors, TP-monitors) – проміжне ПЗ, що забезпечує
контроль передачі даних від клієнта при роботі з
розподіленими БД
– Монітор обробки транзакцій забезпечує цілісність даних,
слідкуючи за тим, щоб не було втрачених або незавершених
транзакцій
22. Протокол двофазного підтвердження
(Two-phase Commit Protocol, 2PС)
• Координатор надсилає кожному компоненту-учаснику
транзакції запит про підтвердження успішності його дій
• Якщо даний компонент виконав свою частину операцій
успішно, він повертає координаторові підтвердження.
Інакше — він надсилає повідомлення про помилку.
• Координатор збирає підтвердження всіх учасників і, якщо
всі зареєстровані учасники транзакції присилають
підтвердження успішності, розсилає їм повідомлення про
підтвердження транзакції в цілому. Якщо хоч би один
учасник прислав повідомлення про помилку або не
відповів в рамках заданого часу, координатор розсилає
повідомлення про необхідність відмінити транзакцію
• Кожен учасник, отримавши повідомлення про
підтвердження транзакції в цілому, зберігає локальні
зміни, зроблені в рамках транзакції. Якщо ж він отримає
повідомлення про відміну транзакції, він відміняє
локальні зміни
23. Брокери об'єктних запитів
• Брокер об'єктних запитів (Object Request Broker,
ORB) – об'єктна шина, по якій в стилі, що
нагадує класичний механізм RPC, відбувається
взаємодія локальних і віддалених об'єктів
– Забезпечує передачу об'єктних запитів, пошук необхідних
об'єктних сервісів і повернення результатів клієнту
• CORBA (Common Object Request Broker
Architecture) – стандарт, набір специфікацій для
проміжного ПЗ об'єктного типа
• Способи реалізації ORB
– ORB, що включається в
клієнтське і серверне
застосування
– ORB, виконаний у вигляді
сервера
– ORB як частина системи
– ORB, заснований на
бібліотеках
24. ПЗ доступу до баз даних
• Власне проміжне ПЗ СКБД - вбудовані механіз-
ми доступу для конкретного сервера баз даних
– підтримка стандартів мови SQL
– вбудовані засоби СКБД, які дозволяють виконувати
імпорт даних із зовнішніх джерел (напр., з інших
СКБД або текстових файлів) та експортувати дані в
сторонні формати (напр., XML)
• Основне проміжне ПЗ баз данных - зовнішні (по
відношенню до СКБД) засоби проміжного шару,
спеціально розроблені для звернень до БД
– технологічні рішення, напр., ODBC, JDBC
– концептуальні рішення, що представляють узагальнену
архітектуру ІС з розподіленими БД, напр., EDA або
DQB
25. Middleware: Яке вибрати?
• RPC – найкраще підходить для систем, для яких не
критичні можливі проблеми, пов'язані з синхрон-
ністю протоколу RPC
• MOM – підійде автоматизованим системам, компо-
ненти яких слабо зв'язані, працюють в незалежному
часовому режимі та використовують різнорідне
мережеве середовище
– Як правило не, підтримують автоматичне перетворення фор-
матів даних, вирішення цього завдання лягає на розробника
• ORB – для організації взаємодія компонентів корпо-
ративних застосувань в об'єктно-орієнтованому
середовищі
• TP-монітори – орієнтовані на складні та високо-
критичні корпоративні системи, тому забезпечують
необхідний рівень сервісу, включаючи управління
процесами, балансування навантаження на сервери,
засоби резервування відновлення даних
26. Література
• Таненбаум Э., М. ван Стеен.
Распределенные системы. Принципы и
парадигмы. – СПб: Питер. – 2003 г. –
880 c.
• Кулямин В.В. Технологии программирова-
ния. Компонентный подход. – М.: ИНТУИТ-
Бином, 2007. – 463 с. -
• Свистунов А.Н. Построение распределенных
систем на Java. - М.: ИНТУИТ-Бином,
2010. - 199 c. -
http://www.intuit.ru/studies/courses/633/489/
info
27. Література (2)
• Мэтью Мак-Дональд, Марио Шпушта.
Microsoft ASP.NET 3.5 с примерами
на C# 2008 и Silverlight 2 для
профес-сионалов.: Пер. с англ. – М.:
ООО "И.Д. Вильямс", 2009. – 1408 с.
• Рихтер Дж. CLR via C#. Програм-
мирование на платформе Microsoft
.NET Framework 4.0 на языке C#. 3-е
изд. – СПб.: Питер, 2012. – 928 с.
• Корисні ресурси
– http://msdn.microsoft.com/ru-ru/library/
Повідомлення — це текстові блоки, які складаються з керуючих команд и даних, що передаються. Для передачі повідомлень використовується байт-ориєнтовані протоколи (HTTP, POP/SMTP и т.п.).