максимально знизити вимоги до клієнтських комп'ютерів, щоб в ідеалі могли використовуватися дешеві бездискові термінали, централізоване адміністрування і централізоване оновлення ПЗ. Тому значна частина програмних ресурсів клієнтів переноситься на сервер додатків, проміжна ланка між клієнтським комп'ютером і сервером бази даних.
Малюнок 1.1 - Загальна схема трирівневої інформаційної системи
Таким чином, трирівневу архітектуру можна представити у вигляді трьох основних компонентів:
клієнтська програма. Реалізує користувальницький інтерфейс і посилає запити на виконання потрібних дій. Мова не обов'язково йде про отримання наборів даних; віддалені компоненти можуть проводити інтенсивні обчислення, скажімо, створення аналітичних звітів. При цьому вимоги до ресурсів комп'ютера, на якому виконується клієнтська програма, мінімальні, так як вся логіка системи реалізується компонентами, що працюють на значно більш потужних серверах мережі. Такі клієнтські програми називають тонкими (thin), тому що вони виконують мінімальний обсяг роботи і не пред'являють особливих вимог до процесора і об'єму оперативної пам'яті;
сервер додатків. являє собою програмне забезпечення, яке пропонує послуги підтримки додатків, реалізує операції з обробки даних та пов'язує кінцевих користувачів з корпоративними базами даних. Діючи як посередник між користувачами і серверами баз даних, він позбавляє компанії від необхідності встановлювати на локальні комп'ютери кінцевих користувачів додаткове програмне забезпечення, що вимагають значних витрат на обслуговування;
віддалений сервер баз даних. СУБД, що виконується на виділеному комп'ютері, обробна запити від сервера додатків і по цих запитах повертає набори даних або вносить зміни в таблиці. Даний сервер не працює напряму з клієнтськими програмами, що підвищує безпеку інформації, що зберігається в системі.
При використанні триланкових архітектур з'являється можливість зняти частину навантаження з клієнта і сервера баз даних на спеціально виділений сервер додатків. У цьому випадку з'являється можливість проводити вторинну обробку даних окремо від обробки інтерфейсу з користувачем і передавати тільки актуальні дані від сервера додатків до клієнта.
Сервер додатків в даній схемі є многопользовательским багатопотокових сокет-сервером, призначення якого - забезпечити доступ з клієнтських додатків до даних, що зберігаються в базі даних, а також до процедур і функцій бізнес-логіки, реалізованим у вигляді COM-компонента або DLL. Набір інтерфейсних функцій забезпечує отримання з клієнтського застосування SQL-запиту і повернення результату у вигляді набору даних SQL-запиту. Сервер додатків виконує розбір SQL-інструкції і з'ясовує місце розташування джерела/споживача даних або бізнес-процедури. Якщо об'єкт знаходиться в БД, то запит передається в СУБД. В іншому випадку виконується пошук процедури (функції) в DLL і COM-серверах, виклик і передача їй параметрів, отримання результатів і повернення їх клієнтського додатку. Для ізоляції клієнтського додатки від структури бази даних використовуються запити (огляди), що зберігаються в БД.
При розробці інформаційної системи використовується компонентний підхід. Компонентні технології розподілених обчислень, зокрема DCOM, використовувана в розробляється системі, обмежують область застосування, побудованих на їх основі ІС (відносяться, як правило, до типу інформаційних систем рівня підприємства), локальною мережею або інтрамережа, що робить систему більш захищеною від втручання ззовні. Застосування компонентного підходу при розробці клієнтських додатків дозволяє істотно розширити їх функціональність. Всю турботу про передачу даних по мережі бере на себе підсистема віддалених викликів процедур - RPC (Remote Procedure Call) у разі DCOM, що позбавляє розробників клієнтів від зосередження на низькорівневих деталях мережевої комунікації.
Реалізація COM в операційних системах сімейства Windows пропонує цікавий механізм, що дозволяє уникнути блокування клієнта і спростити організацію черги запитів, оброблюваних пулом потоків - технологію асинхронних (не блокують) викликів. Звичайний (синхронний) виклик методу віддаленого COM-компонента передбачає блокування викликає потоку, після передачі параметрів в канал RPC, до отримання відповіді про завершення виклику. Здійснюючи асинхронний виклик, потік отримує управління назад, відразу ж після переміщення даних в канал, однак, при цьому, перевірка стану виклику та отримання результатів повинні здійснюватися окремо.
Для представлення клієнтської сторони, в структурі сервера доцільно виділити окремий компонент (за аналогією з об'єктом мережевого інтерфейсу, його можна назвати - сокет), до функцій якого повинні входити: взаємодія з клієнтом, пошук ...
