Архітектура апаратно-програмних засобів розподіленої обробки інформації для інтранет-технології

Інформатика, програмування

МОСКОВСЬКИЙ ІНСТИТУТ радіотехніки, електроніки і АВТОМАТИКИ (ТУ)

Курсова робота з предмету системне програмне забезпечення

Тема: Архітектура апаратно-програмних засобів розподіленої обробки інформації для інтранет-технології.

Студента групи ВВ-22-95

Головченко В.

Викладач Малигіна О.П.

Москва 1998 < p> Зміст

1. Архітектура "клієнт-сервер"

1.1. Відкриті системи

1.2. Клієнти і сервери локальних мереж

1.3. Системна архітектура "клієнт-сервер"

1.4. Сервери баз даних

1.5. Принципи взаємодії між клієнтськими і серверними частинами
1.6. Переваги протоколів віддаленого виклику процедур
1.7. Типове розділення функцій між клієнтами та серверами
1.8. Архітектури процесора бази даних

2. Трирівнева архітектура "клієнт-сервер"

3. Програмні засоби розробки
3.1. Універсальні засоби
3.2. Персональні СУБД

4. Intranet та архітектура "клієнт-сервер".
4.1. Дворівнева архітектура "клієнт-сервер"
4.2. Трирівнева архітектура "клієнт-сервер"
4.2.1. Програми розширення серверної частини

5. Приклад бази даних

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

1.1. Відкриті системи
Реальне розповсюдження архітектури "клієнт-сервер" стало можливимзавдяки розвитку і широкого впровадження в практику концепції відкритихсистем. Тому ми почнемо з короткого вступу до відкриті системи.

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

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

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

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

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

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

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

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

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

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

Сервер локальної мережі надає ресурси (послуги) робочих станцій і/абоінших серверів.

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

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

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

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

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

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

Спільним рішенням проблеми мобільності систем, заснованих на архітектурі
"клієнт-сервер" є опора на програмні пакети, що реалізують протоколивіддаленого виклику процедур (RPC - Remote Procedure Call). При використаннітаких коштів звернення до сервісу у віддаленому вузлі виглядає як звичайнийвиклик процедури. Засоби RPC, в яких, природно, міститься всяінформація про специфіку апаратури локальної мережі та мережевих протоколів,переводить виклик в послідовність мережевих взаємодій. Тим самим,специфіка мережного середовища і протоколів прихована від прикладного програміста.

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

Якщо система реалізована на основі стандартного пакету RPC, вона може бутилегко перенесена в будь-яку відкриту середу.

Технологія "клієнт-сервер" стосовно до СУБД зводиться до поділусистеми на дві частини - програму-клієнт (front-end) і сервер бази даних
(back-end). Ця архітектура поєднує кращі риси обробки даних намейнфреймах та технології "файл-сервер". Від мейнфреймів технологія "клієнт -сервер "запозичила такі риси, як централізоване адміністрування,безпека, надійність. Від технології "файл-сервер" успадковані низькавартість і можливість розподіленої обробки даних, використовуючи ресурсикомп'ютерів-клієнтів. Зараз графічний інтерфейс користувача ставстандартом для систем "клієнт-сервер". Крім того, архітектура "клієнт -сервер "значно спрощує і прискорює розробку додатків за рахунок того,що правила перевірки цілісності даних знаходяться на сервері. Неправильнопрацює клієнтська програма не може привести до втрати чи спотворенняданих. Всі ці можливості, раніше властиві тільки складним ідорогим системам, зараз доступні навіть невеликим організаціям.
Вартість обладнання, програмного забезпечення і обслуговування дляперсональних комп'ютерів в десятки разів нижче, ніж для мейнфреймів.
Особливості обробки даних в різних архітектурах показані на рис.1.

Рис.1. Обробка даних в різних архітектурах

Локальний комп'ютер

Локальне додаток

СУБД

Дані

Архітектура "файл-сервер"

Клієнт

Файл-сервер

Мережеве додаток

Дані

СУБД

Клієнт

пересилання Мережеве додаток даних

СУБД

Архітектура "клієнт-сервер"

Сервер БД

Клієнтське

СУБД додаток

Дані

Клієнтський додатокпересилання запитів і результатів

1.4. Сервери баз даних
Термін "сервер баз даних" зазвичай використовують для позначення всієї СУБД,заснованої на архітектурі "клієнт-сервер", включаючи і серверну, іклієнтську частини. Такі системи призначені для зберігання та забезпеченнядоступу до баз даних.

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

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

Це мова по суті справи представляє собою поточний стандарт інтерфейсу СУБД ввідкритих системах. Збірна назва SQL-сервер відноситься до всіхсерверів баз даних, заснованих на SQL.

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

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

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

1.6. Переваги протоколів віддаленого виклику процедур
Згадувані вище протоколи віддаленого виклику процедур особливо важливі всистемах управління базами даних, заснованих на архітектурі "клієнт -сервер ".

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

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

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

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

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

1.8. Архітектури процесора бази даних.
Основна частина будь-якої системи "клієнт-сервер" - це сервер БД. З часувиникнення архітектури "клієнт-сервер" з'явилося багато варіантівархітектури процесора БД, оскільки він багато в чому визначає успіх всієїсистеми. Основна вимога до сервера БД - забезпечення мінімальногочасу виконання запитів при максимально можливому числі користувачів.
Існують дві основні архітектури для побудови процесора БД:архітектура з декількома процесами і багатопотокова архітектура.

1. Архітектура з декількома процесами
Характеризується тим, що кілька примірників виконавчого файлу працюютьодночасно. Ці системи відрізняються гарною масштабованість, але вимагаютьзначних витрат пам'яті, тому що пам'ять кожному екземпляру програмививиділяється окремо. Ця архітектура має на увазі наявність ефективногомеханізму взаємодії процесів і покладається на операційну систему прирозподіл процесорного часу між окремими екземплярами програми.
Найвідоміший приклад сервера, побудованого за даної архітектури, - Oracle
Server. Коли користувач підключається до БД Oracle, він насправдізапускає окремий екземпляр виконавчого файлу процесора бази даних.
2. Багаторівнева архітектура
Ця архітектура використовує тільки один файл, з декількомапотоками виконання. Головна перевага - більш скромні вимоги дообладнанню, ніж для архітектури з декількома процесами. Тут сервербере на себе розподіл часу між окремими потоками, іноді даючиперевагу деяким завданням над іншими. Крім того, відпадаєнеобхідність у складному механізмі взаємодії процесів. З цієїархітектурі побудовані MS SQL Server та Sybase SQL Server.

2. Трирівнева архітектура "клієнт-сервер"
На верхньому рівні абстрагування взаємодії клієнта і серверадосить чітко можна виділити наступні компоненти:

• презентаційна логіка (Presentation Layer - PL), призначена дляроботи з даними користувача;
• бізнес-логіка (Business Layer - BL), призначена для перевіркиправильності даних, підтримки посилальної цілісності ..;
• логіка доступу до ресурсів (Access Layer - AL), призначена длязберігання даних;

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

1. "Товстий" клієнт. (fat client)

Сервер БД для користувача інтерфейс

Дані Бізнес-логіка

для користувача інтерфейс

Бізнес-логіка < p> Найбільш часто зустрічається варіант реалізації архітектури клієнт -сервер у вже впроваджених і активно використовуваних системах. Така модельмає на увазі об'єднання в клієнтському додатку як PL, так і BL, такимчином забезпечується повна децентралізація управління бізнес-логікою.
Однак у випадку необхідності виконання будь-яких змін у клієнтськомудодатку доведеться змінювати вихідний код. Серверна частина, при описаномупідході, являє собою сервер баз даних, що реалізує AL. До описаноїмоделі часто застосовують абревіатуру RDA - Remote Data Access.

2. "Тонкий" клієнт. (thin client)

Бізнес-

Логіка для користувача інтерфейс

Дані

для користувача інтерфейс

Модель, що починає активно використовуватися в корпоративному середовищі взв'язку з поширенням Internet-технологій і, в першу чергу, Web -браузерів. У цьому випадку клієнтський додаток забезпечує реалізацію PL,тому клієнт може задовольнятися досить скромною апаратноїплатформою, а сервер об'єднує BL і AL. Максимальне завантаження серверапередбачає виконання бізнес-логіки тільки за допомогою збережених процедурсервера (Збережені процедури - відкомпілювалися SQL-інструкції, що зберігаютьсяна сервер). Це дозволяє максимально централізувати контроль над данимиі легко змінювати правила роботи відразу для цілого підприємства. З іншогобоку, незначна коректування правил, що стосується тільки частиникористувачів, що потребують тривалої процедури узгодження. У цьому випадкунеможливо реалізувати якісь винятки із загальних правил для деякихкористувачів або програм. У принципі, це добре і є запорукоюбезпеки і цілісності даних.

3. Сервер бізнес-логіки. (трирівнева архітектура)

Проміжний сервер

Користувацький

Бізнес-логіка інтерфейс другого рівня

Сервер БД

Користувацький

Бізнес-логіка інтерфейс сервера

Дані

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

3. Програмні засоби розробки

3.1. Універсальні засоби

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

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

4. Intranet та архітектура "клієнт-сервер".
4.1. Дворівнева архітектура "клієнт-сервер"

Web-броузер Джерело даних

Web-сервер

NOS (Network Operation System)

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

4.2. Трирівнева архітектура "клієнт-сервер"

Web-броузер Джерело даних

Третій рівень

Програма розширення сервера

HTML

Web-сервер

NOS

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

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

5. Приклад бази даних
Приклад бази даних див у доданому до курсової роботи технічному завданні.

Джерела:

1. А. Горев, С. Макашаріпов, Ю. Владимиров

"SQL Server 6.5 Для професіоналів"

Изд. "Питер" Санкт-Петербург 1998

2. К. Ланг, Д. Чоу

"Публікація баз даних в Інтернеті"

Изд. "Символ-Плюс" Санкт-Петербург 1998

3. Д. Боуман, C. Емерсон, М. Дарновскі

"Практичний посібник з SQL"

Изд. "Діалектика" Київ 1997

4. Microsoft Press

"Секрети створення інтрамережі"

Изд. "Питер" Санкт-Петербург 1998

5. http:www.citforum.ru