Главная | Обратная связь

Підходи до побудови серверів прикладного програмного забезпечення

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

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

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

Рис. 11. Прив’язка клієнта до сервера з використанням демона в середовищі ОС і суперсервера в UNIX

 

Найбільш коректний спосіб викликати переривання зв’язку – розробляти програмне забезпечення клієнта і сервера так, щоб вони могли пересилати один одному інформацію (out-of band) стосовно сервера, який має обробляти раніше за всі інші, дані, які передаються клієнтом. Один з підходів до застосування сигналу кінця зв’язку – змусити сервер переглядати окрему кінцеву точку, на яку клієнт його відправлятиме й одночасно (з нижчим пріоритетом), переглядати кінцеву точку, через яку передаються нормальні дані. Інший підхід – пересилати сигнал кінця зв’язку тим самим з’єднанням, через яке клієнт пересилав свій запит. У протоколі TCP, наприклад, можна надсилати термінові дані. Коли термінові дані досягають сервера, він перериває свою роботу (у UNIX- системах – за сигналом), після чого може проглянути ці дані й обробити їх.

Важливою характеристикою сервера є можливість збереження інформації про стан клієнтів на сервері.

Сервер без фіксації стану (stateless sewer) не зберігає інформацію про стан своїх клієнтів і може змінювати власний стан, не інформуючи про це клієнтів.

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

На відміну від сервера без фіксації стану, сервер з фіксацією стану (stateful server) зберігає і обробляє інформацію про своїх клієнтів.

 

Сервери об’єктів

Сервер об’єктів (object server) – це сервер, орієнтований на підтримку розподілених об’єктів.

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

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

Приклад.В багато потоковому сервері об’єктів окремий потік виконання може бути призначений окремому об’єкту або запиту на звернення до об’єкту.

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

Рис.12. Структура сервера об’єктів

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

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

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

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

Перенесення коду

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

Agent TCL (D’Agent) – це система, побудована на основі концепції агента,яким у цій системі називають програму, яка в гетерогенній системі здатна переміщуватися з однієї машини на другу.

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