69063

Розподiлена архітектура компонентних систем

Лекция

Информатика, кибернетика и программирование

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

Украинкский

2014-09-29

1.78 MB

13 чел.

Лекцiя №6

Розподiлена архітектура компонентних систем

Слайд №1 Поняття архітектури

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

Для поняття "архітектура ІС" існує багато визначень. Є навіть Web-сайти, які іх колекціонують. Розглянемо визначення з різних джерел:

Архітектура – це організаційна структура системи.

Архітектура ІС – концепція, що визначає модель, структуру, виконувані функції і взаємозв'язок компонентів ІС.

Архітектура – це базова організація системи, втілена в її компонентах, їхні стосунки між собою і з оточенням, а також принципи, що визначають проектування та розвиток системи.

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

Архітектура програми чи комп'ютерної системи – це структура або структури системи, які включають елементи програми, видимі ззовні властивості цих елементів і зв'язки між ними.

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

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

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

Під архітектурою програмних систем будемо розуміти сукупність рішень щодо:

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

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

З розвитком програмних систем все більшого значення набуває їх інтеграція один з одним з метою побудови єдиного інформаційного простору підприємства. Як можна бачити з вищенаведених визначень інтеграція є найважливішим елементом архітектури.

Для того щоб побудувати правильну і надійну архітектуру і грамотно спроектувати інтеграцію програмних систем необхідно чітко слідувати сучасним стандартам в цих областях. Без цього існує велика ймовірність створити архітектуру, яка не здатна розвиватися і задовольняти зростаючі потреби користувачів ІТ. В якості законодавців стандартів у цій галузі виступають такі міжнародні організації як SEI (Software Engineering Institute), WWW (консорціум World Wide Web), OMG (Object Management Group), організація розробників Java - JCP (Java Community Process), IEEE (Institute of Electrical and Electronics Engineers) та інші.

Слайд №2 Визначення розподіленої системи

Поняття розподілена система в літературі визначається по-різному. Розуміння того, що повинна представляти собою розподілена система, сформувалося історично й постійно уточнюється.

Визначення 1. Розподіленою системою називається ряд з’єднаних центральних процесорів (ЦПУ – CPU), що працюють разом.

Визначення 2. Розподіленою системою називається ряд машин з нерозділеною пам'яттю.

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

Використовуються також наступні визначення:

Визначення 3. Розподілена система є системою із просторово розподіленими компонентами, які не використовують ніякої спільної пам'яті й не підлягають децентралізованій адміністрації. Для реалізації спільних цілей можлива кооперація компонентів. Якщо цими компонентами пропонуються послуги або використовуються запропоновані послуги, то виникає клієнт-серверна система, у випадку додаткового центрального службового посередництва - “торгівельна” система ( Trading-Система).

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

Розподілена система – це набір незалежних комп'ютерів, що уявляється користувачами єдиною об'єднаною системою.

У цьому визначенні є два однаково важливі моменти:

  •  стосовно апаратури: всі машини автономні;
  •  стосовно програмного забезпечення: користувачам надається у користування єдина система.

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

Розподілена інформаційна система (РІС) – це сукупність програмних компонентів, що взаємодіють один з одним. Кожний з таких компонентів може розглядатися як програмний модуль (застосування), що виконується в рамках окремого процесу.

Розподiлена iнформацiйна система є розподiленою системою з єдиними iнформацiйними ресурсами. Доступ до iнформацiйних ресурсiв регламентується встановленими правилами доступу до неї, процесами оброблення, передавання, зберiгання, перетворення й використання iнформацiї.

Слайд №3 Переваги та недоліки розподілених систем

Переваги розподілених систем. Є ряд причин, які приводять до заміни централізованих систем розподіленими:

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

Перевагами розподілених апаратних рішень, які використовуються в сучасному обчислювальному обладнанні є:

  •  більш прості модулі, поєднання яких забезпечую необхідний ресурс, їхня сумарна дешивизна в порівнянні з єдиним більш складним модулем;
  •  зростання надійності – так як вихід з ладу одного модуля не призведе до необхідності ремонту чи заміни обладнання, його функції розподіляться між іншими, в результаті тільки зменшиться продуктивність загальної схеми;
  •  для збільшення продуктивності загальної системи не потрібно розробляти нові апаратні елементи;
  •  полегшене тепловідведення – блоки «розкидані» на опорній платі,
  •  зменшується диференціація температурних зон і абсолютні значення температур.

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

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

По-друге, багато проблем пов'язано з транспортуванням повідомлень каналами зв'язку між комп'ютерами. Основні задачі тут – забезпечення надійності (щоб передані дані не губилися і не спотворювалися) та продуктивності (щоб обмін даними відбувався з прийнятними затримками). У структурі загальних витрат на обчислювальну мережу витрати на вирішення «транспортних питань» складають істотну частину, у той час як у централізованих системах ці проблеми цілком відсутні.

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

Недоліками розподілених апаратних рішень, які використовуються в сучасному обчислювальному обладнаані, є:

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

Слайд №4 Централізована (одноланкова, монолітна) архітектура

Перші компьтерні системи не були розподіленими. У 70-80-ті роки минулого століття була поширена централізована архітектура обчислювальних систем, що реалізовувалася на базі мейнфреймів (наприклад, IBM-360/370 або їх вітчизняних аналогів серії ЄС ЕОМ) або міні-ЕОМ (наприклад, PDP-11 або їх вітчизняного аналога СМ-4). Характерна особливість такої архітектури – повна "неінтелектуальність" терміналів. Їх роботою керує хост-ЕОМ.

Класичне уявлення централізованої архітектури показано на слайді.

Переваги такої архітектури:

  •  користувачі спільно використовують дорогі ресурси ЕОМ і дорогі периферійні пристрої;
  •  централізація ресурсів та обладнання полегшує обслуговування і експлуатацію обчислювальної системи;
  •  відсутня необхідність адміністрування робочих місць користувачів;

Головним недоліком для користувача є те, що він повністю залежить від адміністратора хост-ЕОМ. Користувач не може налаштувати робоче середовище під свої потреби – все використовуване програмне забезпечення є колективним. Централізація ресурсів і устаткування призводить до того, що всі компютери в системі залежать від надійності роботи центрального компьютера (ЦК). Це підвищує вимоги до надійності та відмовостійкості його роботи, що в свою чергу приводить до здорожчання апаратного та програмного забезпечення ЦК.

Використання такої архітектури є виправданим, якщо хост-ЕОМ дуже дорога, наприклад, супер-ЕОМ.

Слайд №5 Фактори розвитку РС

Сучасний рiвень розроблення РС зумовлено такими основними факторами:

  •  значними темпами зростання продуктивностi комп'ютерiв з одночасним зменшенням вартостi обробки iнформацiї. За вартостi комп'ютера 100 млн дол. у 50-х роках минулого столiття i швидкостi одна операцiя за секунду критерiй продуктивностi цiна/кiлькiсть операцiй становив 108 дол./операцiй/с. Для сучасних систем середня швидкiсть ПК становить 107 операцiй/с за вартостi 1000 дол., тобто критерiй цiна/кiлькiсть операцiй становить 10-4 дол./операцiй/с. Отже, пiдвищення критерiю цiна/продуктивнiсть становить 1012;
  •  широким застосуванням локальних комп'ютерних мереж, починаючи з 80-х рокiв минулого столiття, за швидкостi обмiну iнформацiєю 10-1000 Мбiт/с i бiльше;
  •  розвитком телекомунiкацiйних систем i глобальних комп'ютерних мереж WAN. Збiльшення швидкостi обмiну даними становить понад 104 вiд перших представникiв (arphanet, mibet) зi швидкiстю передавання iнформацiї 56 Кбiт/с до сучасних систем в Iнтернет, Intranet, VPN зi швидкiстю обмiну даними 1 Гбiт/с i бiльше;
  •  розвитком теорiї й практики створення програмних засобiв розподiлених БД та засобiв графiчного iнтерфейсу для них (Oracle, SQL Server, Informix);
  •  упровадженням еталонної моделi взаємодiї вiдкритих систем OSI для реалiзацiї стекiв протоколiв реальних систем.

Узагальнену органiзацiю РIС для комп'ютерiв А, В, С з локальними операцiйними системами (ЛОС) показано на рис. 1.1.

Рис. 1.1. Узагальнена структурна органiзацiя РIС

Прикладний рiвень розподiлених застосувань забезпечує єдине середовище взаємодiї застосувань. Служби промiжного рiвня надають єдине середовище додаткових послуг у разi взаємодiї з оперативною системою (ОС) окремих пiдсистем А, В, С. Таку РIС називають розподiленою системою промiжного рiвня. Зокрема, до неї належать мережi з використанням системи керування базами даних (СКБД) Oracle тощо.

Слайд №6 Основнi вимоги до РС:

Розподілені системи мають наступні характерні риси:

Першим аспектом є просторова розподіленість компонент розподіленої системи. Вони вступають у взаємодію або локально або віддалено.

  1.  Компоненти розподіленої системи можуть працювати паралельно, через що швидкість роботи зростає в порівнянні з послідовною роботою.
  2.  Кожний стан компоненти розглядається локально, тобто з погляду певного обчислювального процесу, запущеного з локального робочого місця.
  3.  Компоненти працюють незалежно й можуть «випадати», не руйнуючи систему в цілому, також незалежно одна від одної. Розподілені системи підлягають, таким чином, частковому системному «випаданню».
  4.  Система працює асинхронно. Процеси комунікації й обробки не  управляються глобальним системним часом. Зміни й процеси синхронізуються.
  5.  У розподіленій системі функції управління розподіляються між різними автономними компонентами.  При цьому ніякий окремий компонент не може здійснювати весь контроль. Це гарантує певну міру автономії.
  6.  Розподілена система може утворюватися як об'єднання вже існуючих систем. Отже, потрібне контекстно-повне управління іменами, що дає можливість однозначно інтерпретувати найменування (імена) в рамках адміністративної або технологічної області.  В такому випадку говорять про федеративне управління іменами.
  7.  Щоб підвищити потужність розподіленої системи, програми й дані можуть переміщатися між різними вузлами, ця концепція називається міграцією. При цьому потрібно використовувати додаткові механізми, які протоколюють положення програм і даних.
  8.  Розподілена система повинна бути в змозі використовувати динамічні зміни структури. Ця динамічна реконфігурація потрібна, наприклад, тоді, коли протягом певного часу повинні з'являтися нові з'єднання.
  9.  Архітектура комп'ютерів може використовувати різні топології й механізми, зокрема, якщо апаратура надходить від різних виробників. Ця характеристика називається гетерогенністю.
  10.  Розподілена система підлягає еволюції, тобто за час її життя відбуваються різні зміни.
  11.  Джерела відомостей, одиниці обробки й користувачі можуть бути фізично мобільні. Програми й дані можуть переміщатися між вузлами, для одержання мобільності системи або збільшення потужності.

Для досягнення цих характерних рис, повинні бути виконані певні вимоги, яким повинні задовольняти розподілені системи:

  •  прозорість;
  •  відкритість;
  •  гнучкість;
  •  масштабованість;
  •  стійкість;
  •  безпека;
  •  ефективність.

Слайд №7 Прозорiсть

Прозорість (transparency) є центральною вимогою, що полегшує взаємодію розподілених прикладних програм і приховує той факт, що процеси й ресурси фізично розподілені серед багатьох комп'ютерів. Цей принцип дозволяє сховати складність реалізації розподілених систем від користувача. Внутрішні процеси в системі ховаються за допомогою, так званих, прозорих для користувача функцій. Внаслідок цього, розподілена система для користувача стає більше зручною. Розподілені системи, які представляються користувачам і прикладним програмам у вигляді єдиної комп'ютерної системи, називаються прозорими (transparent).

Основнi форми прозоростi:

  •  прозорiсть доступу - приховує вiдмiнностi у поданнi даних i доступу до ресурсiв; дозволяє приховати рiзний формат передавання даних для рiзних процесорiв (вiд молодшого байта до старшого або вiд старшого до молодшого), а також вiдмiнностi у поданнi iмен файлiв тощо.
  •  прозорiсть мiсцеположення - приховує вiд користувача фiзичне мiсцеположення ресурсу; досягається, зокрема, наданням логiчних iмен.
  •  прозорiсть перенесення - приховує факт перемiщення ресурсу в iнше мiсце;
  •  прозорiсть змiни мiсцеположення - приховує перемiщення ресурсу пiд час обробки даних;
  •  прозорiсть реплiкацiї - приховує факт реплiкацiї вiд користувача;
  •  прозорiсть паралельного доступу - приховує факт сумiсного використання ресурсу кiлькома конкуруючими процесами користувачiв;
  •  прозорiсть вiдмови - приховує факт виникнення вiдмов у системi й вiдновлення ресурсу;
  •  прозорiсть схоронностi - приховує факт розмiщення ресурсу на диску або кешування ресурсу.

Прозорiсть змiни мiсцеположення актуальна для мобiльних розподiлених систем, у яких вiдбувається пересування процесорiв у процесi оброблення даних.

Прозорiсть реплiкацiї може значно зменшити продуктивнiсть роботи РIС.

Несуперечливiсть прозоростi паралельного доступу, наприклад, у БД, пiдтримується механiзмом взаємоблокувань або використанням транзакцiй.

Прозорiсть вiдмов, зокрема i приховування збоїв, - одна з найскладнiших проблем побудови РIС i забезпечення її вiдмовостiйкостi.

Визначення вiдмов i збоїв може призводити до сповiльнення роботи окремих компонентiв системи.

Прозорiсть схоронностi маскує реальне розмiщення ресурсу на диску i на вiртуальному диску. Така прозорiсть характерна для об'єктно-орiєнтованих БД, у яких можливий безпосереднiй виклик методiв.

Iснує баланс мiж ступенем прозоростi й продуктивнiстю системи. У разi забезпечення прозоростi промiжного сервера може бути заборонений доступ до кiнцевого сервера, з якого отримують данi.

Прозорiсть реплiкацiї за умови пiдтримання їх цiлiсностi може виявитись недоцiльною через великi часовi витрати.

Слайд №8 Вiдкритiсть

Відкрита розподілена система (open distributed system) – це система, що пропонує стандартні засоби й служби доступу до системи широкому колу користувачів, що використовують стандартні синтаксис і семантику всіх протоколів взаємодії. Всі протоколи взаємодії компонент усередині розподіленої системи в ідеальному випадку повинні бути засновані на загальнодоступних стандартах. Це дозволяє використовувати для створення компонентів різні засоби розробки й операційні системи. Кожна компонента повинна мати точну й повну специфікацію своїх сервісів. У цьому випадку компоненти розподіленої системи можуть бути створені незалежними розробниками. При порушенні цієї вимоги може стати неможливим створення розподіленої системи, що охоплює кілька незалежних організацій.

Основні характеристики, що забезпечують відкритість розподілених систем: наявність загальних специфікацій інтерфейсів, служб розподілених систем, яких достатньо для реалізації інтерфейсів різними виробниками, такі специфікації інтерфейсів розуміються однозначно для різних реалізацій конкретного інтерфейсу.

Гнучкість – простота конфігурування системи, що складається з різних компонентів різних виробників (можливість переносу системи з одних операційних систем на інші, можливо навіть в іншу файлову систему). 

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

Слайд №9 Масштабованiсть

Масштабованість обчислювальних систем має кілька аспектів. Найбільш важливий з них – можливість додавання в розподілену систему нових комп'ютерів для збільшення продуктивності системи, що пов'язане з поняттям балансування навантаження (load balancing) на сервери системи. До масштабування також відносяться питання ефективного розподілу ресурсів серверів, що обслуговують запити клієнтів.

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

До основних технологiй масштабування належать:

  •  вилучення часу очiкування зв'язку;
  •  розподiлення;
  •  реплiкацiя, тобто розмноження компонентiв систем.

Вилучення часу в разi географiчного масштабування полягає у можливому уникненнi вiдповiдi на запит вiддаленого сервера. Додатки розраховують на асинхронний зв'язок, який передбачає переривання роботи додатка для вiдповiдi на ранiше поданий запит. Якщо переривається процес, додаток викликає обробник запитiв. Це характерно для РIС пакетного оброблення даних i паралельних додаткiв.

Для iнтерактивних РIС частину обчислень доцiльно перекладати iз сервера на клiєнта. Такий пiдхiд пiдтримується в системах Iнтернет, Intranet iз застосуванням Java-аплетiв, якi передаються клiєнту.

Масштабованiсть за технологiєю розподiлення передбачає роздiлення компонентiв на малi частини й рознесення їх по системi, наприклад, служби DNS iмен Iнтернет, у яких iмена органiзовуються у виглядi дерева доменiв. Домени розподiляють адреси на зони, якi не перетинаються. У WWW застосовуються URL-адреси документiв. Користувачам вони iнтерпретуються єдиною системою документообiгу. Однак середовище WEB фiзично рознесено по множинi серверiв, а iм'я сервера визначається за URL-адресою документа. У разi використання реплiкацiї збiльшується продуктивнiсть РIС i полiпшується доступнiсть до iнформацiї.

Крім того, до основних вимог до РС відносяться:

Гнучкість – простота конфігурування системи, що складається з різних компонентів різних виробників (можливість переносу системи з одних операційних систем на інші, можливо навіть в іншу файлову систему). 

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

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

Слайд №10 Проміжне середовище

  •  Система проміжного рівня забезпечує скоординовану роботу мереж і ОС із можливостями використання їхнього програмного інтерфейсу.
  •  Загальна структура розподілених систем із проміжним рівнем.

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

  •  Зв'язок – організація зв'язку і передачі даних між елементами системи.
  •  Іменування – підтримка ідентифікації та пошуку окремих ресурсів усередині системи.
  •  Процеси – організація робіт в рамках процесів і потоків.
  •  Синхронізація – синхронізація паралельно виконуваних потоків робіт.
  •  Підтримка цілісності даних і несуперечності внесених змін.
  •  Організація відмовостійкої роботи.
  •  Захист – організація захищеності даних і комунікацій.

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

Слайд №11 Поняття розподіленого середовища

Розподілене середовище являє собою віртуальний обчислювальний простір, який може обмежуватися однією розподіленою системою, а може містити кілька взаємодіючих розподілених систем. Такий віртуальний обчислювальний простір надається користувачеві у вигляді систематизованого сховища інформаційних та програмних ресурсів, має певну структуру, зрозумілу систему адресації ресурсів та певні моделі обчислювальних процесів або бізнес-процесів даного користувача. Бізнес-процеси користувача є проблемно-орієнтованими, відповідають певним видам його робіт. Користувач звертається до бізнес-процесів, які у свою чергу відвантажують необхідні ресурси для своєї роботи.

Учасниками взаємодії в розподіленому середовищі виступають окремі сутності, якими можуть бути користувачі, прикладні програми та інші обчислювальні ресурси.

Слайд №12 Модель взаємодії клієнт-сервер

Як основу опису взаємодії двох сутностей розглянемо загальну модель взаємодії клієнт-сервер, у якій одна зі сторін (клієнт) ініціює обмін даними, надсилаючи запит іншій стороні (серверу). Сервер обробляє запит і при необхідності посилає відповідь клієнтові (рис. 2.25).

Рис. 2.25  Модель взаємодій клієнт сервер

У базовій моделі клієнт-сервер всі процеси в розподілених системах діляться на дві групи. Процеси, що реалізують деяку службу, наприклад службу файлової системи або бази даних, називаються серверами (servers). Процеси, що запитують служби в серверів шляхом посилки запиту й наступного очікування відповіді від сервера, називаються клієнтами (clients). Взаємодія клієнтів і сервера, відома також як режим роботи запит-відповідь (request-reply behavior), зображена на рис. 2.26.

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

Використання з'єднання, яке не потребує протоколу дає істотний виграш в ефективності. Доти поки повідомлення не почнуть пропадати або ушкоджуватися, можна цілком успішно застосовувати протокол типу запит-відповідь. На жаль, створити протокол, стійкий до випадкових збоїв зв'язку, – нетривіальне завдання. Усе, що можливо зробити, – це надати клієнтові можливість повторно надіслати запит, на який не була отримана відповідь. Проблема, однак, полягає в тому, що клієнт не може визначити, чи дійсно первісне повідомлення із запитом було загублено чи помилка відбулася при передачі відповіді. Якщо втратилася відповідь, повторна посилка запиту може привести до повторного виконання операції.

Взаємодія в рамках моделі клієнт сервер може бути як синхронною, коли клієнт очікує завершення обробки свого запиту сервером, так і асинхронною, при якому клієнт посилає серверу запит і продовжує виконання своєї роботи без очікування відповіді сервера. Модель клієнта й сервера може використовуватися як основа опису різних взаємодій. Для даного курсу важлива взаємодія складових частин програмного забезпечення, що утворюють розподілену систему.

Слайд №13 Розподіл прикладних програм по рівнях 

Модель клієнт-сервер потребує визначення питання, як розподілити програмне забезпечення між клієнтом і сервером. Наприклад, сервер розподіленої бази даних може постійно виступати клієнтом, що передає запити на різні файлові сервери, відповідальні за реалізацію таблиць цієї бази даних. У цьому випадку сервер баз даних сам по собі не робить нічого, крім обробки запитів.

Однак розглядаючи множину прикладних програм типу клієнт-сервер, призначених для організації доступу користувачів до баз даних, багато хто рекомендує розділяти їх на три рівні.

  •  рівень користувацького інтерфейсу;
  •  рівень обробки;
  •  рівень даних.

Рис. 2.27  Логічні рівні прикладної програми

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

Рівень користувацького інтерфейсу

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

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

У наш час навіть у середовищі мейнфреймів спостерігаються більш досконалі користувацькі інтерфейси.

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

Рівень обробки. Багато прикладних програм в моделі клієнт-сервер побудовані із трьох різних частин: частини, що займається взаємодією з користувачем, частини, що відповідає за роботу з базою даних або файловою системою, і середньої частини, що реалізує основну функціональність прикладної програми. Ця середня частина логічно розташовується на рівні обробки. На противагу користувацьким інтерфейсам або базам даних на рівні обробки важко виділити загальні закономірності.

Рівень даних. Рівень даних у моделі клієнт-сервер містить програми, які надають дані прикладним програмам, що їх оброблюють. Специфічною властивістю цього рівня є вимога збереження або живучості (persistence). Це означає, що коли прикладна програма не працює, дані повинні зберігатися в певному місці, розраховуючи на подальше використання. У найпростішому варіанті рівень даних реалізується файловою системою, але частіше для його реалізації задіється повномасштабна база даних. У моделі клієнт-сервер рівень даних як правило знаходиться на стороні сервера.

Крім простого зберігання інформації рівень даних також відповідає за підтримку цілісності даних для різних прикладних програм. Для бази даних підтримка цілісності означає, що метадані, такі як опис таблиць, обмеження й специфічні метадані прикладних програм, також зберігаються на цьому рівні. Наприклад, якщо у прикладній програмі, яка входить до банківської системи, необхідно сформувати повідомлення щодо боргу клієнта за кредитною карткою, то це може бути зроблено за допомогою тригера бази даних. Тригер у потрібний момент активізує процедуру, пов'язану із цим тригером та ту, що дозволяє виконати таку дію.

Як правило рівень даних організується у формі реляційної бази даних. Ключовим тут є незалежність даних. Дані організуються незалежно від прикладної програми так, щоб зміни в організації даних не впливали на прикладну програму, а прикладна програма не впливала на організацію даних. Використання реляційних баз даних у моделі клієнт-сервер допомагає відокремити рівень обробки від рівня даних, розглядаючи обробку й дані незалежно один від одного.

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

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

Слайд №14 Варіанти архітектури клієнт-сервер. Дволанкова

Варіанти архітектури клієнт-сервер

На практиці різних користувачів розподіленої системи цікавить доступ як до одних і тих самих даних, так і доступ до різних наборів даних. Найбільш простим рознесенням функцій такої системи між декількома комп'ютерами буде поділ логічних рівнів прикладної програми між однією серверною частиною прикладної програми, відповідальною за доступ до даних, і клієнтськими частинами, що перебувають на декількох комп'ютерах і реалізують інтерфейс користувача. Логіка прикладної програми може бути віднесена до сервера, клієнтів, або розділена між ними (рис. 2.28).

Рис. 2.28  Дволанкова архітектура

Архітектуру, побудовану за таким принципом прикладних програм, називають клієнт-серверною або дволанковою (two-tiered architecture). На практиці подібні системи часто не відносять до класу розподілених, але формально вони можуть вважатися найпростішими представниками розподілених систем.

Тонкий клієнт (thin client) в комп'ютерних технологіях — комп'ютер або програма-клієнт в мережах з клієнт-серверною або термінальною архітектурою, який переносить всі або більшу частину завдань з обробки інформації на сервер. Прикладом тонкого клієнта може бути комп'ютер з браузером, який використовується для роботи з веб-програмами.Тонкі клієнти зустрічаються як компоненти більш широкої комп'ютерної інфраструктури, де багато клієнтів діляться часткою свого обчислення з одного сервера. Таким чином, тонкий клієнт  інфраструктури можна розглядати як амортизацію деяких обчислювальних служб через кілька користувацьких інтерфейсів. Це бажано в умовах, коли окремі товсті клієнти мають набагато більшу функціональність і потужність, ніж інфраструктура вимагає або використовує.

Товстий або Rich-клієнт в архітектурі клієнт-сервер – це застосування, що забезпечує (на противагу тонкому клієнтові) розширену функціональність незалежно від центрального сервера. Часто сервер в цьому випадку є лише сховищем даних, а вся робота з обробки та подання цих даних переноситься на машину клієнта.

Розвиток архітектури "клієнт-сервер", а особливо поява сучасних графічних інтерфейсів, призвела спочатку до появи варіанту архітектури клієнт-сервер, яка отримала назву "архітектура з товстим клієнтом". В цій архітектурі логіка представлення даних і бізнес-логіка розміщуються на клієнті, який (скажімо, у разі, коли сервером є СКБД) спілкується з логікою зберігання і накопичення даних на сервері, використовуючи мову структурованих запитів SQL. Проте необхідність установки "товстих клієнтів", що вимагають значної кількості спеціальних бібліотек і спеціального налаштування оточення, на велику кількість користувачів з різними операційними середовищами, як правило викликає масу проблем.

Тому, як альтернатива, виникла також дворівнева архітектура "з тонким клієнтом". При цьому в ідеалі програма-клієнт реалізує лише графічний інтерфейс користувача (GUI) і передає/отримує запити, а вся бізнес-логіка виконується сервером баз даних. У ідеалі клієнтом є інтернет-браузер, який не вимагає спеціального налаштування, установки спеціалізованого ПЗ тощо. На жаль, така схема теж не вільна від недоліків тому, що серверу доводиться брати на себе інколи не властиві для нього функції реалізації бізнес-логіки застосунку (наприклад, серверу СКБД доводиться виконувати розрахунки).

Слайд №15 Варіанти архітектури клієнт-сервер. Триланкова

Розвитком архітектури клієнт-сервер є триланкова архітектура (three-tiered architecture), у якій інтерфейс користувача, логіка прикладної програми й доступ до даних виділені в самостійні складові системи, які можуть працювати на незалежних комп'ютерах (рис. 2.29).

Рис. 2.29 Триланкова архітектура

Таким чином, разом з клієнтською частиною застосунку і сервером баз даних з'явилися сервери застосувань (Application Servers).

В такій трирівневій архітектурі:

  •  програма-клієнт реалізує інтерфейс користувача, передає запити серверу застосувань і приймає від нього відповідь;
  •  сервер застосувань реалізує бізнес-логіку і звертається із запитами до сервера "третього рівня" (наприклад, сервера бази даних за даними);
  •  сервер третього рівня обслуговує запити сервера застосувань.

Програма-клієнт, таким чином, може бути "тонким клієнтом". Переваги такої архітектури очевидні:

  •  зміни на кожній з ланок можна здійснювати незалежно;
  •  знижуються навантаження на мережу, оскільки ланки не обмінюються між собою великими об'ємами інформації;
  •  забезпечується масштабування і проста модернізація устаткування і програмного забезпечення, що підтримує кожна з ланок, у тому числі оновлення серверного парку і термінального устаткування, СКБД і т.д.;
  •  Застосування можуть створюватися на стандартних мовах програмування  (Java, C/C++/C#, PHP тощо).

Запит користувача в подібних системах послідовно обробляється клієнтською частиною системи, сервером логіки прикладної програми й сервером баз даних. Однак звичайно під розподіленою системою розуміють системи з більш складною архітектурою, ніж триланкова.

Ця архітектура була домінуючою протягом останніх 15 років при створенні Веб-застосувань. Останнім часом, з ростом популярності веб-технологій виникла потреба в зменшенні навантаження на веб-сервер, тому звилася потреба в розробці "товстих клієнтів" в рамках трирівневої архітектури. Ця технологія отримала назву AJAX (асинхронний Java script  і XML).

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

Наступний логічний крок – подальше збільшення числа ланок, причому зросте не лише за рахунок розбиття, коли "тоншає" кожна з відомих технічних ланок, але вся бізнес-модель будується як багатоланкова. Сучасні корпоративні програмні системи є, як правило, складними системами, взаємодіючими між собою на різних рівнях компонентів, кожен з яких може бути клієнтом для одних компонентів і сервером для інших.

Слайд №16 Приклади триланкової архітектури

Рис. 2.30  Розподілена система роздрібних продажів (ІК – інтерфейс користувача, ЛП – логіка прикладних програм, ДД – доступ до даних, БД – база даних)

Стосовно прикладних програм автоматизації діяльності підприємства або організації, розподіленими, як правило, називають системи з логікою прикладної програми, розподіленої між декількома компонентами системи, кожна з яких може виконуватися на окремому комп'ютері. Наприклад, реалізація логіки прикладної програми системи роздрібних продажів повинна використовувати запити до логіки прикладної програми третіх фірм, таких як постачальники товарів, системи електронних платежів або банки, що надають споживчі кредити (рис. 2.30).

Таким чином, у побуті під розподіленою системою часто розуміють ріст багатоланкової архітектури "в ширину", коли запити користувача не проходять послідовно від інтерфейсу користувача до єдиного сервера баз даних.

Як інший приклад розподіленої системи можна привести мережі прямого обміну даними між клієнтами (peer-to-peer networks). Якщо попередній приклад мав "деревоподібну" архітектуру програмного забезпечення, то мережі прямого обміну організовані складніше, рис. 2.31. Подібні системи є в даний момент, імовірно, одними з найбільших існуючих розподілених систем, що поєднують мільйони комп'ютерів.

Один з підходів до організації клієнтів і серверів – це розподіл програм, що перебувають на рівні прикладного програмного забезпечення. Один з можливих варіантів організації – помістити на клієнтську сторону тільки термінальну частину користувацького інтерфейсу, як показано на рис. 2.32 а, дозволивши прикладній програмі віддалено контролювати представлення даних. Альтернативою цьому підходу буде передача клієнтові всієї роботи з користувацьким інтерфейсом (рис. 2.32 б). В обох випадках відокремлюється від прикладної програми графічний зовнішній інтерфейс, пов'язаний з іншою частиною прикладної програми (що перебуває на сервері) за допомогою специфічного для даної прикладної програми протоколу. У подібній моделі зовнішній інтерфейс робить тільки те, що необхідно для надання інтерфейсу прикладній програмі.

Рис. 2.31  Система прямого обміну даними між клієнтами (ІК – інтерфейс користувача, ЛП – логіка прикладних програм, ДД – доступ до даних, БД – база даних)

Рис. 2.32  Альтернативні форми організації архітектури клієнт-сервер

У багатьох системах клієнт-сервер популярна організація, представлена на рис. 2.32 г і д. Ці типи організації застосовуються в тому випадку, коли клієнтська машина – персональний комп'ютер або робоча станція – з'єднана мережею з розподіленою файловою системою або базою даних. Більша частина прикладних програм працює на клієнтській машині, а всі операції з файлами або базою даних передаються на сервер. Рисунок 2.15 д зображає ситуацію, коли частина даних утримується на локальному диску клієнта. Так, наприклад, при роботі в Інтернеті клієнт може поступово створити на локальному диску величезний кеш найвідвідуваніших web-сторінок.

Розглядаючи розподілення програмного забезпечення на клієнтське і серверне, необхідно враховувати те, що серверу іноді може знадобитися працювати як клієнт. Така ситуація, зображена на рис. 2.33 приводить нас до фізично триланкової архітектури (physically three-tiered architecture).

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

Сучасні варіанти архітектури – багаторівневі.

Багатоланкові архітектури клієнт-сервер є прямим продовженням поділу прикладних програм на рівні користувацького інтерфейсу, компонентів обробки й даних. Різні ланки взаємодіють відповідно до логічної організації прикладних програм. У бізнес-прикладних програмах розподілена обробка еквівалентна організації багатоланкової архітектури прикладної програми клієнт-сервер. Такий тип розподілу називається вертикальним розподілом (vertical distribution). Особливістю вертикального розподілу є те, що він досягається розміщенням логічно різних компонентів на різних машинах. Це поняття пов'язане з концепцією вертикальної розбивки (vertical fragmentation), яка використовується в розподілених реляційних базах даних, де під цим терміном розуміється розбивка по стовпцях таблиць для їхнього зберігання на різних машинах.

Однак вертикальний розподіл – це лише один з можливих способів організації клієнт-серверного прикладного програмного забезпечення. У сучасних архітектурах розподіл на клієнти й сервери відбувається способом, відомим як горизонтальний розподіл (horizontal distribution). При такому типу розподілу клієнт або сервер може містити фізично розділені частини логічно однорідного модуля, причому робота з кожною із частин може відбуватися незалежно. Це робиться для вирівнювання завантаження.

Як розповсюджений приклад горизонтального розподілу розглянемо web-сервер, реплікований на кілька машин локальної мережі, як показано на рис. 2.34. На кожному із серверів утримується той самий набір web-сторінок, і щораз, коли одна з web-сторінок обновляється, її копії одразу розсилаються на всі сервери. Сервер, якому буде переданий вхідний запит, вибирається за правилом «каруселі» (round-robin). Ця форма горизонтального розподілу досить успішно використовується для вирівнювання навантаження на сервери популярних web-сайтів.

Примітка. Репликация — это набор технологий копирования и распространения данных и объектов баз данных из одной базы в другую и последующей синхронизации двух баз для обеспечения согласованности данных. При помощи репликации можно распространять данные в различные места хранения, а также передавать их удаленным пользователям и пользователям мобильных устройств через локальную и глобальную сети, подключения удаленного доступа, беспроводные подключения и Интернет.

У такий же спосіб, хоча й менш очевидно, можуть бути розподілені й клієнти. Для нескладного прикладного програмного забезпечення, призначеного для колективної роботи, можливо не мати сервера взагалі. У цьому випадку зазвичай говорять про одноранговий розподіл ( peer-to-peer distribution). Подібне відбувається, наприклад, якщо користувач хоче зв'язатися з іншим користувачем. Обоє вони повинні запустити одну й ту саму прикладну програму, щоб почати сеанс. Третій клієнт може спілкуватися з одним з них або обома, для чого йому потрібно запустити ту саму прикладну програму.

Сервісно-орієнтоване програмування

Ця парадигма програмування з'явилася як наслідок розгляду програмних компонентів як готових сервісів, визначення для них інтерфейсів взаємодії в рамках нових архітектур ПЗ, зв'язаних із сервісами, у середовищі розподілених систем (CORBA, DCOM і EJB) і веб-сервісів у середовищі Інтернету. Такі архітектури отримали назву сервісно-орієнтованих архітектур – SOA (Service-Oriented Architecture) і зараз активно розвиваються разом із відповідними засобами їхньої підтримки й опису (XML, SOAP, WSDL і ін.) та механізмами взаємодії звичайних сервісів розподілених застосувань і веб-сервісів Інтернету.

Сервісно-орієнтоване програмування (або архітектура) (service-oriented architecture, SOA) – це подальший розвиток компонентного підходу до розробки компонентних програмних систем (ПС), заснований на використанні програм-сервісів із стандартизованими інтерфейсами. Компоненти ПС можуть бути розподілені по різних вузлах мережі, і пропонуватися як незалежні, слабо зв'язані, замінювані сервіси-застосування. Інтерфейс компонентів ПС забезпечує інкапсуляцію деталей реалізації кожного конкретного компоненту від інших. Таким чином, сервісно-орієнтована архітектура надає гнучкий спосіб комбінування і повторного використання компонентів для побудови складних розподілених програмних систем, зокрема, корпоративних програмних систем.

Сервісом (service) будемо називати ресурс, що реалізує бізнес-функцію та має наступні властивості:

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

Таким чином, сервісо-орієнтована архітектура (SOA) — це засіб, що дозволяє представити програмну систему як набір взаємозв'язаних сервісів. Однією з її переваг є гнучкість і простота розробки нових застосувань. SOA створює комунікаційне середовище для модулів, що реалізовують прикладну бізнес-логіку. Інформація про модулі публікується в такій формі, що їх використання не вимагає знань про використані в них рішення і технології.


Лекція №7

Проміжне програмне забезпечення

Проміжне програмне забезпечення (middleware) – це клас ПЗ, призначеного для об'єднання компонентів розподіленого клієнт-серверного застосування або цілих мережевих застосуваннь в єдину інформаційну систему. Проміжне ПЗ представляє набір сервісів, звернення до яких дозволяє різним застосуванням, в загальному випадку таким, що виконуються на різних платформах, взаємодіяти між собою (див. рис.). Загальні прикладні інтерфейси (API) проміжного ПЗ дозволяють реалізувати взаємодію між застосуваннями, не заглиблюючись в інфраструктуру і деталі реалізації гетерогенної мережі, а подальші зміни в структурі та складі такої мережі не зажадають змін в застосуваннях (за умови, що ці зміни не зачіпають API middleware).

Термін middleware вперше був використаний у 1968 р., але як технологія інтеграції корпоративних застосувань, цей тип ПЗ став використовуватися з 80-х років XX ст. для вирішення проблем сумісності та взаємодії нових застосувань із застарілими успадкованими системами.

Місце проміжного ПЗ – в умовній «середині» між рівнем операційної системи (ОС) і рівнем прикладного програмного забезпечення або його компонентами. Цим воно нагадує середню ланку в триланкових клієнт-серверній архітектурі, за винятком того, що функціональні частини middleware розподілені між застосуваннями та/або їх компонентами в корпоративному мережевому середовищі. 

Слайд №26 Основи мережної взаємодії. З точки зору одного з комп'ютерів розподіленої системи, всі інші вхідні в неї машини є віддаленими обчислювальними системами. Теоретичною основою мережної взаємодії віддалених систем є загальновідома модель взаємодії відкритих систем OSI/ISO, що розділяє процес взаємодії двох сторін на сім рівнів: фізичний, канальний, мережний, транспортний, сеансовий, прикладний, представлення.

Рис. 2.37 Модель взаємодії обчислювальних систем

У мережах найпоширенішого стека протоколів TCP/IP протокол TCP є протоколом транспортного, а протокол IP – протоколом мережного рівня. Забезпечення інтерфейсу до транспортного рівня на сьогоднішній день бере на себе мережна компонента операційної системи, надаючи оснований на сокетах інтерфейс для верхніх рівнів. Сокети забезпечують примітиви низького рівня для безпосереднього обміну потоком байт між двома процесами. Стандартного рівня представлення або сеансового рівня в стеці протоколів TCP/IP немає, іноді до них відносять захищені протоколи SSL/TLS.

Використання протоколу TCP/IP за допомогою сокетів надає стандартний, міжплатформовий, але низькорівневий сервіс для обміну даними між компонентами. Для виконання сформульованих вище вимог до розподілених систем функції сеансового рівня й рівня представлення повинне взяти на себе проміжне програмне забезпечення (рис. 2.37). Воно повинне допомогти створити розроблювачам відкриті, масштабовані й стійкі розподілені системи. Для досягнення цієї мети проміжне середовище повинне забезпечити сервіси для взаємодії компонент розподіленої системи. До таких сервісів відносяться:

  •  забезпечення єдиного й незалежного від операційної системи механізму використання одними програмними компонентами сервісів інших компонентів;
  •  забезпечення безпеки розподіленої системи: аутентифікація й авторизація всіх користувачів сервісів компоненти й захист переданої між компонентами інформації від перекручування й читання третіми сторонами;
  •  забезпечення цілісності даних: управління транзакціями, розподіленими між віддаленими компонентами системами;
  •  балансування навантаження на сервери із програмними компонентами;
  •  виявлення віддалених компонентів.

Функції middleware. Сервіси middleware надають застосуванням різні функції API, які, в порівнянні з функціями ОС і мережевих служб, забезпечують:

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

• незалежність від інших мережевих сервісів;

• високу надійність і постійну готовність.

Слід відзначити, що найчастіше відмінності у функціональності операційної системи і проміжного ПО є умовними. Зокрема, деякі можливості, що раніше надавалися виключно засобами middleware, тепер реалізуються на рівні ядра операційних систем. Типовим прикладом є стек TCP/IP, підтримка якого включена практично у всі ОС.

Слайд №27 Види проміжного ПЗ

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

1. Програмне забезпечення для межпрограммного взаємодії (див. також IPC - Inter-Process Communication).

2. Програмне забезпечення доступу до баз даних.

Проміжне ПЗ межпрограммного взаємодії. Протоколи та продукти цієї категорії полегшують між процесами взаємодії (IPC - InterProcess Communications) і розподіл об'єктів в інфраструктурі корпоративної інформаційної системи. Вони виконують роль клею, що дозволяє з'єднати багатоланкові застосування. Основними технологіями є: RPC, MOM, TPM та ORB. У готових рішеннях, як правило, використовується один або кілька таких протоколів.

Власне ПО проміжного шару. До цього виду належить, в першу чергу, підтримка стандартів мови SQL. Незважаючи на те, що SQL є міжнародним стандартом, розробники СКБД самостійно визначають, які з можливостей SQL вони будуть підтримувати в своїх системах. В результаті, конкретна СКБД може, з одного боку, не підтримувати чи підтримувати частково деякі команди SQL, а з іншого – представляти розробникам додатків нестандартні мовні розширення.

Іншим видом власного middleware є вбудовані засоби СКБД, що дозволяють виконувати імпорт даних із зовнішніх джерел (наприклад, з інших СУБД або текстових файлів) і експортувати дані в сторонні формати (наприклад, CSV або XML).

Слайд №28 У межах однієї розподіленої системи може використовуватися кілька видів проміжних середовищ (рис. 2.38). При правильному підході до проектування системи її кожна розподілена компонента надає свої сервіси за допомогою єдиного проміжного середовища  і використовує сервіси інших компонент за допомогою так само єдиного проміжного середовища, однак ці середовища можуть бути різними.

Рис. 2.38 Гетерогенна розподілена система, де ІК – інтерфейс користувача, ЛП – логіка прикладних програм, ДД – доступ до даних, БД – база даних

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

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

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

Взаємодія компонент розподіленої системи

Слайд №29 Синхронною (synchronous) називається така взаємодія між компонентами, за якої клієнт, відіславши запит, блокується і може продовжувати роботу тільки після отримання відповіді від сервера. З цієї причини такий вид взаємодії називають іноді блокуючим (blocking).

Звичайне звернення до функції або методу об'єкта за допомогою передачі керування по стеку викликів є прикладом синхронного взаємодії.

Синхронну взаємодію досить просто організувати, і вона набагато простіше для розуміння. Людська свідомість володіє єдиним «потоком керування», представленим у вигляді фокусу уваги, і тому людині простіше розуміти процеси, які розгортаються послідовно, оскільки не потрібно постійно переключати увагу на що відбуваються одночасно різні події. Код програми клієнтського компонента, яка описує синхронне взаємодія, влаштований простіше – його частина, що відповідає за обробку відповіді сервера, знаходиться безпосередньо після частини, в якій формується запит. В силу своєї простоти синхронні взаємодії в більшості систем використовуються набагато частіше асинхронних.

Разом з тим синхронна взаємодія веде до значних витрат часу на очікування відповіді. Цей час часто можна використовувати більш корисним чином: очікуючи відповіді на один запит, клієнт міг би зайнятися іншою роботою, виконати інші запити, які не залежать від результату, який ще не надійшов. Оскільки всі розподілені системи складаються з достатньо великої кількості рівнів, через які проходять практично всі взаємодії, сумарне падіння продуктивності, пов'язане з синхронністю взаємодій, виявляється дуже великим.

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

Прикладом асинхронної взаємодії є електронна пошта. Інший приклад – поширення повідомлень про новини різних видів відповідно до наявного на поточний момент реєстру передплатників, де кожен передплатник визначає теми, які його цікавлять.

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

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

Слайд №30 Концепції взаємодії компонент розподіленої системи

На сьогодні існують дві концепції взаємодії програмних компонент: обмін повідомленнями між компонентами й виклик процедур або методів об'єкта віддаленого компонента за аналогією з локальним викликом процедури. Оскільки будь-яка взаємодія між віддаленими компонентами в остаточному підсумку основана на сокетах TCP/IP, первинним з погляду проміжного середовища є низькорівневий обмін повідомленнями на основі мережних сокетів, сервіс яких ніяк не визначає формат переданого повідомлення. На базі протоколів TCP або HTTP потім можуть бути побудовані прикладні протоколи обміну повідомлень більш високого рівня абстракції для реалізації більш складного обміну повідомленнями або віддаленого виклику процедур.

Віддалений виклик є моделлю, що походить від мов програмування високого рівня, а не від реалізації інтерфейсу транспортного рівня мережних протоколів. Тому протоколи віддаленого виклику повинні обов'язково базуватися на будь-якій системі передачі повідомлень, включаючи як безпосереднє використання сокетів TCP/IP, так і основані на ньому інші проміжні середовища для обміну повідомленнями. Реалізація високорівневих служб обміну повідомленнями, у свою чергу, може використовувати віддалений виклик процедур, оснований на більш низькорівневій передачі повідомлень, що використовує, наприклад, безпосередньо мережні сокети. Таким чином, одне проміжне середовище може використовувати для свого функціонування сервіси іншого проміжного середовища, аналогічно тому, як один протокол транспортного або мережного рівня може працювати поверх іншого протоколу при тунелюванні протоколів.

Слайд №31 Обмін повідомленнями 

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

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

Існує кілька розробок в області проміжного програмного забезпечення, що реалізують високорівневі сервіси для обміну повідомленнями між програмними компонентами. До них відносяться Microsoft Message Queuing, IBM MQSeries і Sun Java System Message Queue. Такі системи дають можливість прикладним програмам використовувати наступні базові примітиви по використанню черг:

  •  додати повідомлення в чергу;
  •  взяти перше повідомлення із черги, процес блокується до появи в черзі хоча б одного повідомлення;
  •  перевірити чергу на наявність повідомлень;
  •  установити оброблювач, що викликається з появою повідомлень у черзі.

Слайд №32 Сервіси обробки повідомлень

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

Рис. 2.39  Системи черг повідомлень

Використання черг повідомлень орієнтовано на асинхронний обмін даними. Основні переваги таких систем:

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

Недоліки систем черг повідомлень є продовженням їхніх переваг:

  •  необхідність явного використання черг розподіленою прикладною програмою;
  •  складність реалізації асинхронного обміну;
  •  певні витрати на використання менеджерів черг;
  •  складність одержання відповіді: передача відповіді може вимагати окремої черги на кожний компонент, що посилає заявки.

Слайд №33 Віддалений виклик процедур

Ідея віддаленого виклику процедур (remote procedure call, RPC) з'явилася в середині 80-х років і полягала в тому, що за допомогою проміжного програмного забезпечення функцію на віддаленому комп'ютері можна викликати так само, як і функцію на локальному комп'ютері. Щоб віддалений виклик відбувався прозоро з погляду прикладної програми, яка виконує виклик, проміжне середовище повинне надати процедуру-заглушку (stub), що буде викликатися клієнтською прикладною програмою. Після виклику процедури-заглушки проміжне середовище перетворює передані їй аргументи у вид, придатний для передачі по транспортному протоколу, і передає їх на віддалений комп'ютер з функцією, що викликається. На віддаленому комп'ютері параметри вилучаються проміжним середовищем з повідомлення транспортного рівня й передаються функції, що викликається (рис. 2.40). Аналогічно на клієнтську машину передається результат виконання функції, що викликається.

Рис. 2.40 Віддалений виклик процедур

Засоби віддаленого виклику процедур призначені для полегшення організації розподілених обчислень. Найбільша ефективність використання RPC досягається в тих програмах, в яких існує інтерактивний зв'язок між віддаленими компонентами з невеликим часом відповідей і відносно малою кількістю переданих даних. Такі програми називаються 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).

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

Слайд №34 Існує три можливих варіанти віддаленого виклику процедур.

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

2. Односпрямований асинхронний виклик: клієнт продовжує виконання свого завдання, одержання відповіді сервера або відсутнє, або його реалізація якось інакше передбачена при розробці (наприклад, через функцію клієнта, що віддалено викликається сервером).

3. Асинхронний виклик: клієнт продовжує своє виконання, при завершенні сервером виконання процедури він одержує повідомлення й результат її виконання, наприклад через callback-функцію, що викликається проміжним середовищем при одержанні результату від сервера.

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

Десеріалізація – процедура, зворотня сериалізації – полягає в створенні копії серіалізованого об'єкта на основі отриманого набору байт. Такий підхід до передачі об'єкта між процесами шляхом створення його копій називається маршалізацією за значенням (marshal by value), на відміну від маршалізації по посиланню.

Маршалізація за посиланням при передачі параметрів за посиланням використовує серіалізацію не самих вказивників, а серіалізацію об’єктів, на які вказують вказівники.

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

Слайд №35 Використання віддалених об'єктів

У зв'язку з переходом розроблювачів прикладних програм від структурної парадигми до об'єктної з'явилася необхідність у використанні віддалених об'єктів (remote method invocation, RMI). Віддалений об'єкт представляє собою деякі дані, сукупність яких визначає його стан. Цей стан можна змінювати шляхом виклику його методів. Звичайно можливий прямий доступ до даних віддаленого об'єкту, при цьому відбувається неявний віддалений виклик, необхідний для передачі значення поля даних об'єкту між процесами. Методи й поля об'єкта, які можуть використовуватися через віддалені виклики, доступні через деякий зовнішній інтерфейс класу об'єкту. Зовнішній інтерфейс компонента розподіленої системи в таких системах звичайно збігається із зовнішнім інтерфейсом одного із класів, що входить компоненту.

У момент, коли клієнт починає використовувати віддалений об'єкт, на стороні клієнта створюється клієнтська заглушка, яка називається посередником (proxy). Посередник реалізує той же інтерфейс, що й віддалений об'єкт. Процес, який виконує виклик, використовує методи посередника, що маршалізує їхні параметри для передачі по мережі, і передає їх по мережі серверу. Проміжне середовище на стороні сервера десеріалізує параметри й передає їх заглушці на стороні сервера, що називають каркасом (skeleton) або, як і у віддаленому виклику процедур, заглушкою (рис. 2.41). Каркас зв'язується з деяким екземпляром віддаленого об'єкта. Це може бути як заново створений, так і існуючий екземпляр об'єкта, залежно від застосовуваної моделі використання віддалених об'єктів.

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

Рис. 2.41  Використання віддалених об'єктів

Як і віддалений виклик процедур, виклик методу віддаленого об'єкта може бути як синхронним, так і асинхронним. Існує дві особливості при використанні віддалених об'єктів, що не зустрічалися у віддаленому виклику процедур. По-перше, якщо на момент формування концепції віддаленого виклику процедур виключення (exceptions) ще не підтримувалися розповсюдженими мовами й не використовувалися, то надалі вони стали методом інформування сторони, яка виконує виклик, про проблеми, що виникли на стороні, яка викликається. Таким чином, у системах, що використовують віддалені об'єкти, сериалізації підлягають як параметри методу і його результат, так і виключення, що викидаються при виконанні віддаленого методу. По-друге, як параметр або результат методів можуть теж передаватися посилання на віддалений об'єкт (рис. 2.42), якщо віддалений метод клієнт, який виконує виклик, також є сервером RMI.

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

Слайд №36 При використанні віддалених об'єктів проблемними є питання про час їхнього життя:

  •  у який момент часу утворюється екземпляр віддаленого об'єкта;
  •  протягом якого проміжку часу він існує.

Для опису життєвого циклу в системах з віддаленими об'єктами використовуються два поняття прикладних програм:

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

Виділяють три моделі використання віддалених об'єктів – модель єдиного виклику (singlecall), модель єдиного екземпляра (singleton), а також модель активації об'єктів по запиту клієнта (client activation). Перші дві моделі також іноді називають моделями серверної активації (server activation), хоча, строго кажучи, активація завжди відбувається на сервері після якого-небудь запиту від клієнта.

Модель єдиного виклику

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

Рис. 2.43  Режим єдиного виклику віддаленого методу

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

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

Відмінною рисою методу одного виклику є мінімальні витрати на організацію системи балансування навантаження і її найбільша ефективність, оскільки кожний сервер, що обслуговує запити, може обробити виклик будь-якого віддаленого методу.

Модель єдиного екземпляру

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

Рис. 2.44  Використання віддалених об'єктів у режимі єдиного екземпляра

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

Активація по запиту клієнта

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

Рис. 2.45 Об'єкти, що активуються клієнтом

Стан компонента розподіленої системи

Програмні компоненти з погляду користувачів сервісів можна розділити на дві категорії:

  •  компоненти без внутрішнього стану, що зберігається між віддаленими викликами своїх методів (stateless components);
  •  компоненти із внутрішнім станом, що зберігається між віддаленими викликами своїх методів (statefull components).

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

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

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

Слайд №37 Розподілені події

При розробці програмного забезпечення досить часто виникає потреба одержувати повідомлення про які-небудь події, що виникають асинхронно, тобто в деякі довільні моменти часу. У розподілених системах також виникає необхідність використання таких повідомлень, що одержуються від віддаленої системи. Можна виділити два підходи до обробки подій: тіснозв'язні й слабкозв’язні події. При тіснозв'язній події відбувається пряме повідомлення однієї сторони іншою стороною. Хоча цей метод можна використовувати, наприклад, разом з односпрямованим асинхронним викликом, йому властивий ряд недоліків, що обмежують його застосування в розподілених системах:

  •  обидві компоненти системи повинні виконуватися одночасно;
  •  для повідомлення декількох компонент про одну подію стороною, що повідомляє, повинні використовуватися механізми для ведення списку одержувачів подій;
  •  утруднена фільтрація або протоколювання подій.

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

Рис. 2.46  Передплатники й видавці слабкозв’язних подій

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

Слайд №38 Розподілені транзакції

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

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

Транзакції є групами дій, що володіють наступним набором властивостей:

Атомарність (atomicity). Для оточення транзакція неподільна — вона або виконується цілком, або жодна з дій транзакції не виконується. Інші процеси не мають доступу до проміжних результатам транзакції.

Погодженіст або несуперечність (consistency). Транзакція не порушує інваріантів і обмежень цілісності даних системи.

Ізольованість (isolation). Транзакції, що одночасно відбуваються, не впливають одна на одну. Це означає, що декілька транзакцій, що виконувалися паралельно, справляють таке сумарне враження, неначе вони виконувалися в деякій послідовності. Сама ця послідовність визначається внутрішніми механізмами реалізації транзакцій. Цю властивість також називають серіалізуємістю транзакцій, оскільки будь-який сценарій їх виконання еквівалентний деякій їх послідовності або серії.

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

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

Слайд №38 Розподілені транзакції

Рис. 2.47  Розподілена транзакція

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

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

  •  проміжне середовище повинне підтримувати управління розподіленими між декількома компонентами транзакціями;
  •  компоненти розподіленої системи не повинні працювати з якими-небудь службами або ресурсами, які не можуть брати участь у транзакції.

Розподілені транзакції є найважливішим елементом підтримки цілісності даних у розподіленій системі. Тому для їх ширшого застосування проміжне середовище може містити механізми, які при необхідності (і певних витратах часу на написання коду) дозволять використовувати в розподілених транзакціях зовнішні служби, що не підтримують транзакції. Такий механізм називається менеджером, що компенсує ресурс (compensating resource manager). Компенсація в цьому випадку означає повернення ресурсу до первісного стану при відкоті транзакції.

У цей час відбувається формування й стандартизація ще одного поняття, пов'язаного з підтримкою цілісності даних – господарської діяльності (business activity) стосовно до розподілених систем. Діяльність звичайно є відображенням деякого реального процесу, наприклад, покупки в магазині: від оформлення замовлення до підтвердження доставки кур'єром. Діяльність може містити в собі транзакції (оформлення замовлення покупця, замовлення товару у постачальника, і так далі – до підтвердження покупцем доставки). На відміну від транзакції, час життя якої передбачається коротким, діяльність може тривати довго (наприклад, місяць). Діяльність може підтримувати скасування зроблених змін (наприклад, оформлення повернення товару постачальнику при відмові покупця) шляхом використання завдань, що компенсують.

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

Для організації таких транзакцій необхідний координатор, який отримує інформацію про всі дії, що беруть участь в транзакції, і забезпечує її атомарність і ізольованість від інших процесів. Зазвичай транзакції реалізуються за допомогою примітивів Клієнтської заглушки. 

Клієнт викликає серверну заглушку. Примітив «почати транзакцію» повідомляє координатора про необхідність створити нову транзакцію, зареєструвати об'єкт, що почав її, як учасника і передати йому ідентифікатор транзакції. При передачі управління (у тому числі за допомогою віддаленого виклику методу) учасник транзакції передає разом із звичайними даними її ідентифікатор. Компонент, операція якого була викликана в рамках транзакції, повідомляє координаторові ідентифікатор транзакції з тим, аби координатор зареєстрував і його як учасника цієї ж транзакції. Якщо один з учасників не може виконати свою операцію, виконується відкот транзакції. При цьому координатор розсилає всім зареєстрованим учасникам повідомлення про необхідність відмінити виконані ними раніше дії. Якщо викликається примітив «завершити транзакцію», координатор виконує деякий протокол підтвердження, аби переконатися, що всі учасники виконали свої дії успішно і можна відкрити результати транзакції для зовнішнього світу.

Рис. 13.3. Розподілені транзакції

Найширше використовується протокол двофазного підтвердження (Two-phase Commit Protocol, 2PС), який полягає в наступному.

1. Координатор посилає кожному компоненту-учасникові транзакції запит про підтвердження успішності його дій.

2. Якщо даний компонент виконав свою частину операцій успішно, він повертає координаторові підтвердження. Інакше — він посилає повідомлення про помилку.

3. Координатор збирає підтвердження всіх учасників і, якщо всі зареєстровані учасники транзакції присилають підтвердження успішності, розсилає їм повідомлення про підтвердження транзакції в цілому. Якщо хоч би один учасник прислав повідомлення про помилку або не відповів в рамках заданого часу, координатор розсилає повідомлення про необхідність відмінити транзакцію.

4. Кожен учасник, отримавши повідомлення про підтвердження транзакції в цілому, зберігає локальні зміни, зроблені в рамках транзакції. Якщо ж він отримати повідомлення про відміну транзакції, він відміняє локальні зміни. Аналог протоколу двофазного підтвердження використовується, наприклад, в компонентній моделі JavaBeans для повідомлення про зміни властивостей компонента, які деякі з компонентів-підписчиків, що оповіщаються про них, можуть відмінити.

Таким чином, Монітори обробки транзакцій (Transaction Processing Monitor — TPM) — це програмні системи, які входять до складу РЗ проміжного рівня, які вирішують  завдання ефективного управління інформаційно-обчислювальними ресурсами в розподіленій системі. Вони є гнучким, відкритим середовищем для розробки і управління мобільними застосуваннями, орієнтованими на оперативну обробку розподілених транзакцій. У числі найважливіших характеристик TPM — масштабованість, підтримка функціональної повноти і цілісності застосувань, досягнення максимальної продуктивності при обробці даних при невисоких вартісних показниках, підтримка цілісності даних в гетерогенному середовищі. TPM спираються на трирівневу модель "клієнт-сервер".

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

Брокери об'єктних запитів

Брокер об'єктних запитів (Object Request Broker, ORB) це об'єктна шина, по якій в стилі, що нагадує класичний механізм RPC, відбувається взаємодія локальних і віддалених об'єктів. На відміну від моделі СОМ, ORB не спирається безпосередньо на механізм RPC, але працює по тих же принципах. Окрім самого виклику методу віддаленого об'єкту, ORB відповідає за пошук реалізації об'єкту, його підготовку до отримання і обробки запиту, передачу запиту і доставку результатів клієнту. ORB є ядром компонентної моделі CORBA, яку ми розглянемо в лекції 15.

CORBA (Common Object Request Broker Architecture) - це стандарт, набір специфікацій для проміжного програмного забезпечення (middleware) об'єктного типа. Різні розробники архітектури CORBA по різному реалізовують ці специфікації.

При визначенні конкретної архітектури Брокер Об'єктних Запитів зовсім необов'язково має бути реалізований як один компонент, але кожна реалізація повинна реалізовувати три категорії операцій:

  •  Операції, які однакові для всіх реалізацій ORB.
  •  Операції, специфічні для конкретного об'єктного типа.
  •  Операції, специфічні для окремих видів реалізацій об'єктів.

Різні реалізації ORB можуть підтримувати різні види реалізацій, а різні адаптери об'єктів можуть забезпечувати різні набори сервісів для клієнта і реалізацій.

Ядро Брокера Об'єктних Запитів забезпечує основні механізми для маніпуляцій об'єктами і виконання запитів. Специфікація CORBA призначається для підтримки різних механізмів реалізації об'єктів, тому структура ядра не визначається. Замість цього задається набір інтерфейсних функцій, які мають бути присутніми в кожній реалізації ORB і тим самим маскують відмінності між різними реалізаціями Брокерів Об'єктних Запитів.

Система об'єктів забезпечує клієнта набором сервісів. Клієнт здатний запитати деякий сервіс. Об'єкт - це щось, що забезпечує один або більше сервісів, які може запитати клієнт.

Доступна багато способів реалізації конкретних ORB. Розглянемо окремі приклади таких реалізацій. Слід зазначити, що конкретний ORB може бути реалізований відразу декількома способами.

ORB, що включається в клієнтське і серверне застосування

Якщо є відповідний механізм комунікацій, то можлива реалізація ORB у вигляді набору підпрограм як з боку клієнта, так і з боку реалізації об'єкту. Виклики методів можуть транслюватися в роботу із засобами взаємодії процесів (Inter Process Communication - IPC).

ORB, виконаний у вигляді сервера

З метою забезпечення централізованого збору і управління всілякою інформацією, ORB може бути реалізований у вигляді окремого застосування. Взаємодіючі застосування встановлюють контакт з ORB-ом за допомогою нормальних механізмів IPC.

ORB як частина системи

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

ORB, заснований на бібліотеках

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

Безпека в розподілених системах

Для забезпечення безпеки розподіленої системи проміжне середовище повинне забезпечувати підтримку трьох загальновідомих функцій, необхідних для створення безпечних систем.

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

2. Обмеження доступу до сервісів компонента залежно від результатів аутентифікації (авторизація). Для рішення даного завдання проміжне середовище повинне підтримувати обмеження доступу, засноване на так званих ролях (role based security). Оскільки немає можливості позначити рівні доступу через конкретних користувачів або груп користувачів системи, то для цього повинні використовуватися деякі абстрактні ролі, які при розгортанні компоненти зв'язуються  адміністратором системи з обліковими записами користувачів системи.

3. Захист даних, переданих між компонентами системи, від перегляду й зміни третіми сторонами. Для цього передані між компонентами повідомлення повинні підписуватися електронним підписом і шифруватися як клієнтом, так і сервером.

Функції забезпечення безпеки можуть забезпечуватися транспортним протоколом, що використовується проміжним середовищем, самим середовищем, або ними обома в сукупності.

Middleware. Що вибрати? Стек протоколів TCP/IP давно вже підтримується на рівні операційних систем, засоби RPC також доступні в мережевих ОС чи не "за промовчанням". Цей механізм практично не вимагає від розробників та інтеграторів яких-небудь нових знань і навичок. Не потрібно вивчати специфічні middleware API: виклик віддаленої процедури нічим не відрізняється від звернення до локальної підпрограми, а всі процеси перетворення даних і передачі їх по мережі виконуються клієнтської і серверної заглушками. Використання RPC може бути найбільш підходящим рішенням для систем, де можливі проблеми, пов'язані з синхронністю протоколу RPC, не є критичними.

Проміжне ПЗ обміну повідомленнями пропонує більшу, в порівнянні з RPC, гнучкість, так як жодне з взаємодіючих застосувань не блокується в процесі обміну повідомленнями. Таке рішення краще підійде для автоматизованих систем, компоненти яких слабо пов'язані, працюють в незалежному часовому режимі і використовують різнорідну мережеву середу. Однак, системи на основі MOM як правило не підтримують автоматичне перетворення форматів (marshalling/unmarshalling), що вимагає від розробника вирішення завдань щодо перетворення форматів даних.

Взаємодію компонентів корпоративних застосувань в об'єктно-орієнтованому середовищі найзручніше реалізовувати за допомогою об'єктних-же засобів проміжного ПЗ. У цьому випадку, розробник використовує об'єктну модель, чітко описує бізнес-процеси. Високий рівень абстракції об'єктів (будь то ORB або EJB) повністю приховує від користувача деталі реалізації взаємодії між ними. Використання об'єктів дозволяє будувати корпоративні застосування немов лего місто, з уніфікованих «цеглинок» об'єктів. Це справедливо, якщо вся система є об'єктно-орієнтованою. Ускладнення з використанням розподілених об'єктів з'являються, коли компонентами автоматизованої системи є успадковані програми.

Монітори транзакцій орієнтовані на складні і висококритичні корпоративні системи. Вони забезпечують необхідний рівень сервісу для таких систем, включаючи управління процесами, балансування навантаження на сервери, засоби резервування відновлення даних. Для задач автоматизації невеликого підприємства можливості, що представляються TP-моніторами можуть бути надлишкові. До того ж, продукти цієї категорії мають високу вартість, що може бути економічно не вигідно.

Розглянуті категорії проміжного ПО все рідше і рідше використовуються в «чистому» вигляді. Навпаки, як і в більшості мережевих технологій, розвиток middleware йде в бік об'єднання можливостей різних його категорій і для різного роду завдань завжди можна підібрати найбільш відповідне рішення.

Користувач

Інтерфейс користувача

Логіка прикладної програми

Логіка прикладної програми

Доступ до даних

Логіка прикладної програми

База   даних

Інтерфейс користувача

Інтерфейс користувача

Інтерфейс користувача

Інтерфейс користувача

Прикладна  програма

Прикладна  програма

Прикладна  програма

Прикладна  програма

База даних

База даних

База даних

База даних

База даних

Прикладна  програма

Інтерфейс користувача

Серверна машина

а

б

д

г

Одержувачі

подій

Видавець

Проміжне середовище

Повідомлення

Подія


 

А также другие работы, которые могут Вас заинтересовать

34116. Показание и противопоказания психоаналитической терапии 62 KB
  Некоторые особенности российского пациента. Так же следует обратить особое внимание на особенности российского пациента и особенности построения терапии в зависимости от психологической конституции. Фрейд полагал что последние две силы связаны между собой и что существует некоторое соответствие внешней реальности и психологической предрасположенности самого пациента Тем самым предполагалось наличие патогенных компонентов в прошлом которые должны предопределять повышенную чувствительность по отношению к определенным обстоятельствам в...
34117. Сеттинг. Определение, взаимозависимость терапевтической задачи и сеттинга 46.5 KB
  Роль сеттинга в построение переходного пространства в рамках котрого происходит развертывание фантазий пациента и осуществляется работа с переносом и сопротивлением. Следует разобраться в ключевой роли сеттинга для формирования у пациента способности восприимать и продуцировать символическую организацию мира. Пациент лежит на кушетке или софе а психоаналитик сидит позади него оставаясь большей частью вне поля зрения пациента стараясь вмешиваться в процесс мышления пациента настолько мало насколько это возможно и не иначе как посредством...
34118. Структурные изменения, как основная цель психоанализа и психоаналитической терапии 62.5 KB
  Еще в 1894 году в работе “Невропсихозы защиты†он показывает что абсисивный симптом является компромиссом между неприемлемым сексуальным желанием защитой против удовлетворения этого желания и раскаянием или самонаказанием. Давайте попробуем понять фразу: Каждый симптом и каждая невротическая черта характера является компромиссным образованием И попробуенм в связи с этим ответить на два вопроса. Компромиссное образование является патологическим когда оно характеризуется любой комбинацией следующих черт: слишком большое ограничение...
34119. Терапевтические отношения. Форма и содержание 61 KB
  Именно в этом взаимодействие пациент продуцирует материал для анализа а аналитик создает условия для его интеграции в психики пациента что и будет являться основой для терапевтических изменений. Процесс ассимиляции связан с позитивной реакцией пациента на тот способ при помощи которого терапевт испоьзует полученный материал с тем как их усваивает Эго и с теми изменениями которые мы назвали “лечебными факторамиâ€. он представляет собой решающее звено между использованным способом действия терапевта и реальным эффектом для пациента...
34120. Ответы на экзаменационные вопросы Эго-психология 470.5 KB
  Положение ЭГОпсихологии в современной психоаналитической теории. ЭгоПсихология – направление в психоаналитической теории развитие которого как считалось началось с работы З. В какойто степени – это теория конкурирующая с теорией влечений и теорией объектных отношений хотя существует другая точка зрения определяющая Эгопсихологию как интегрирующую концепцию.
34121. Психоаналитическая терапия. Ответы на экзаменационные вопросы 325.5 KB
  Такой подход значительно сужает взгляд на проблему так как из вида упускается важнейший момент содержания терапевтического процесса которое образуется благодаря живому творческому взаимодействию его непосредственных участников – пациента и терапевта их влиянию друг на друга и на ход терапии в целом. Первоначально основатель психоанализа просто использует медицинскую однонаправленную модель в которой значение имеет только личность пациента катарсический метод. В дальнейшем обосновывая и развивая идею переноса Фрейд хотя и вводит в...
34122. Психодиагностика. Ответы на экзаменационные вопросы 501.5 KB
  Именно это и явилось основной предпосылкой возникновения психодиагностики как отдельной области научных знаний и системы методов исследования. Причиной этому послужили успехи в области исследования хромосомных болезней человека. Основным в исследованиях XIX века является то что психическое становилось особой областью экспериментального исследования отличной от физиологии. наибольшее влияние на становление психологической диагностики оказали экспериментальная психология диффференцальная психология прикладная психология и тестология;...
34123. Возрастная психология. Ответы на экзаменационные вопросы 811 KB
  Возрастная психология или психология развития направлена на исследование особенностей проявления и развития психики человека в различные возрастные периоды. Системное рассмотрение всего жизненного цикла позволяет выявить общие закономерности индивидуального развития человека и использовать их для решения таких существенных задач возрастной психологии как: Научное обоснование возрастных норм психофизиологических функций. Научное прогнозирование развития человека развертывание психических ресурсов человека. Определение наиболее...
34124. Психоаналитические теории характеров. Ответы на экзаменационные вопросы 397 KB
  Мазохистические и депрессивные паттерны характера в значительной степени совпадают особенно на невротически здоровом уровне организации личности. Важно понимать различия между этими двумя психологиями потому что особенно на пограничном и психотическом уровнях организации личности требуется применение существенно различающихся терапевтических стилей. Эти решения могут представать как чередующиеся состояния Эго особенно на уровне пограничной организации личности приводя терапевта в замешательство понимать ли этого пациента как...