Розробка бази даних з архітектурою "клієнт-сервер". Розробка серверної та клієнтської частини

Размещено на http://www.allbest.ru/

Дипломна робота

Розробка бази даних з архітектурою “клієнт-сервер”. Розробка серверної та клієнтської частини

ЗМІСТ

• ВСТУП
• 1. ОГЛЯД І АНАЛІЗ РОЗГЛЯДУВАНОЇ ПРОБЛЕМИ І ІСНУЮЧИХ МЕТОДІВ І ЗАСОБІВ ЇЇ ВИРІШЕННЯ
• 1.1 Огляд архітектури “КЛІЄНТ-СЕРВЕР”
• 1.1.1 Клієнти та сервери локальних мереж.
• 1.1.2 Системна архітектура “клієнт-сервер”
• 1.1.3 Сервери баз даних
• 1.1.4 Принципи взаємодії між клієнтськими й серверними частинами
• 1.1.5 Переваги протоколів віддаленого виклику процедур
• 1.1.6 Типовий поділ функцій між клієнтами й серверами
• 1.1.7 Архітектури процесора бази даних
• 1.2 Трирівнева архітектура “КЛІЄНТ-СЕРВЕР”
• 1.2.1 Персональні СУБД.
• 1.3 INTRANET і архітектура “КЛІЄНТ-СЕРВЕР”
• 1.3.1 Дворівнева архітектура “клієнт-сервер”
• 1.3.2 Трирівнева архітектура “клієнт-сервер”
• 1.3.3. Програми розширення серверної частини
• 1.4 Технологія JAVA
• 1.4.1 Технологічний цикл обробки JAVA-програм
• 1.4.2 JAVA-машина
• 1.4.3 Типи даних які підтримує JAVA-машина
• 1.4.4 Регістри
• 1.4.5 Вказівники
• 1.4.6 “Збір сміття”
• 1.4.7 Система команд JAVA-машини
• 1.5 Взаємодія з серверами баз даних - JDBC
• 1.5.1 Використання JDBC
• 1.5.2 Принципи використання JDBC
• 1.6 Нетривіальні можливості JDBC
• 1.7 Використання JDBC 363
• 1.8 Робота з запитами в MS Access
• 2. МАТЕМАТИЧНО-ІНФОРМАЦІЙНА СИСТЕМА НА ОСНОВІ АРХІТЕКТУРИ “КЛІЄНТ-СЕРВЕР”
• 2.1 Основні поняття формальної моделі
• 2.2 Модель системи
• 3. ІМПЛЕМЕНТАЦІЯ ПРОГРАМИ З АРХІТЕКТУРОЮ “КЛІЄНТ-СЕРВЕР” ЗАСОБАМИ МОВИ JAVA2 EE
• 3.1 Постановка задачі
• 3.2 Реалізація клієнтської частини
• 3.3 Реалізація серверної частини
• 4. ВИЗНАЧЕННЯ ЕКОНОМІЧНОЇ ЕФЕКТИВНОСТІ РОБОТИ СИСТЕМИ
• 4.1 Економічна доцільність розробки програмного забезпечення та його впровадження
• 4.2 Побудова мережевого графа
• 4.3 Економічне обґрунтування розробки та впровадження програми
• 4.4 Розрахунок витрат на розробку програмного забезпечення
• 4.5 Розрахунок капітальних вкладень
• 4.6 Розрахунок експлуатаційних витрат
• 4.7 Розрахунок зведених економічних показників
• 5. ОХОРОНА ПРАЦІ
• 5.1 Аналіз небезпечних та шкідливих виробничих факторів
• 5.2 Заходи для забезпечення нормальних умов праці та розрахунок природної освітленості
• 5.3 Забезпечення безпеки експлуатації ЕОМ
• ВИСНОВКИ

ВСТУП

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

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

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

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

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

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

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

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

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

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

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

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

На сучасному етапі для програмування модулів проміжного рівня використовується мова серверних сценаріїв РНР, а для управління даними - СУБД MySQL. Таким чином, зв'язку PHP-MySQL слід розглядати як стандартний інструмент для створення порівняно простих інтерактивних веб-сайтів та систем електронної комерції; близько 90% комерційних систем сьогодні створюється саме на цій основі. Водночас як засоби управління даними, так і middleware-засоби можуть бути найрізноманітнішими. Так, для створення серверних застосувань, крім РНР, широко застосовуються Java, Perl, Python. Взагалі, технології створення розподілених, зокрема веб-застосувань, стрімко розвиваються. Слід згадати про технології EJB (Enterprise Java Beans), CORBA, а також про .NET - порівняно нову ініціативу компанії Microsoft. Для зберігання даних та їх передачі часто використовується так звана розширена мова розмітки XML (Extensible Markup Language).

1. ОГЛЯД І АНАЛІЗ РОЗГЛЯДУВАНОЇ ПРОБЛЕМИ І ІСНУЮЧИХ МЕТОДІВ І ЗАСОБІВ ЇЇ ВИРІШЕННЯ

1.1 Огляд архітектури “КЛІЄНТ-СЕРВЕР”

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

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

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

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

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

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

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

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

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

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

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

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

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

Прикладами серверів можуть служити:

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

* обчислювальний сервер, що дає можливість робити обчислення, які неможливо виконати на робочих станціях;

* дисковий сервер, що володіє розширеними ресурсами зовнішньої пам'яті й їх у використання користувачам й, можливо, іншим серверам;

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

* сервер баз даних, фактично звичайна СУБД, що приймає запити по локальній мережі й повертає результати.

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

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

1.1.2 Системна архітектура “клієнт-сервер”

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

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

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

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

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

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

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

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

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

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



1.1.3 Сервери баз даних

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

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

1.1.4 Принципи взаємодії між клієнтськими й серверними частинами

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

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

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

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

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

1.1.5 Переваги протоколів віддаленого виклику процедур

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

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

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

1.1.6 Типовий поділ функцій між клієнтами й серверами

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

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

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

1.1.7 Архітектури процесора бази даних

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

1. Архітектура з декількома процесами

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

2. Багатопотокова архітектура

Ця архітектура використовує тільки один виконавчий файл з декількома потоками виконання. Головна перевага - більш скромні вимоги до впровадження ніж для архітектури з декількома процесами. Тут сервер бере на себе поділ часу між окремими потоками, іноді даючи перевагу деяким завданням над іншими. Крім того, відпадає необхідність у складному механізмі взаємодії процесів. По цій архітектурі побудовані MS SQL Server й Sybase SQL Server.

1.2 Трирівнева архітектура “КЛІЄНТ-СЕРВЕР”

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

* презентаційна логіка (Presentation Layer - PL), призначена для роботи з даними користувача;

* бізнес-логіка (Business Layer - BL), призначена для перевірки правильності даних, підтримки, тощо;

* логіка доступу до ресурсів (Access Layer - AL), призначена для зберігання даних;



Рисунок 2. “Товстий” клієнт. (fat client)

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

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

Рисунок 3. “Тонкий” клієнт. (thin client)

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



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

1.2.1 Персональні СУБД

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

Таблиця 1.2.1 - Коротка характеристика деяких персональних СУБД

Найменування	Коротка характеристика
Lotus Approach 97	Дозволяє виконувати всі види обробки даних. Має дуже простий інтерфейс. СУБД тісно інтегрована з базами даних Notes й електронними таблицями Lotus 1-2-3. Підтримує технологію електронного обміну повідомленнями MAPI.
MS Access 97	Повноцінна СУБД, що володіє багатим набором візуальних засобів, численними майстрами й потужною мовою програмування Visual Basic for Applications. Має гнучку систему підготовки звітів. Підтримуються технології ODBC і OLE 2.0. СУБД тісно інтегрована з усіма додатками MS Office.
MS Visual FoxPro 5	Одна з найбільш швидких персональних СУБД, що сполучає технологію xBase й об'єктно-орієнтировану мову програмування. Має багатий набір візуальних засобів розробки й майстрів для швидкої побудови додатків і звітів. Підтримуються технології Active, ODBC й OLE 2.0. Дозволяє створювати OLE-сервера й має засоби для розробки й підтримки додатків “клієнт-сервер”.
Paradox 7	Підтримує всі види роботи з даними. Для візуального виконання стандартних завдань є спеціальний засіб Experts. Наділений власною досить складною мовою ObjectPAL. Підтримує технології OLE 2.0, Active, MAPI й ODBC.

1.3 INTRANET і архітектура “КЛІЄНТ-СЕРВЕР”

1.3.1 Дворівнева архітектура “клієнт-сервер”

Рисунок 5. Дворівнева архітектура “клієнт-сервер”

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

1.3.2 Трирівнева архітектура “клієнт-сервер”

Рисунок 6. Трирівнева архітектура “клієнт-сервер”

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

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

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

1.3.3 Програми розширення серверної частини

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

Існує три категорії розширень серверної частини: із звичайним CGI, з гібридним CGI і з API.

1.4 Технологія JAVA

1.4.1 Технологічний цикл обробки JAVA-програм

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

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

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

Додаток як місце входу має метод

public static void main (String args[]);

Цей метод повинен бути визначений у тім public-класі, що знаходиться у файлі, який виконується віртуальною Java-машиною. У параметр args передається масив рядків - параметрів командного рядка.

Приклад: програма, що друкує свої аргументи

public class myTop {

public static void main (String args[]) {

int argc = args.length;

for (int i = 0; i < argc; i++)

System.out.println (argc[i]);

}

}

Аплет виконується в контексті броузера і його життєвий цикл визначається наступними методами класу Applet:

public void init () - викликається броузером при завантаженні аплета;

public void start () - викликається броузером при показі сторінки;

public void stop () - викликається броузером, коли той іде з Web-сторінки;

public void destroy () - цей метод призначений для звільнення ресурсів; аналог деструктора, але не викликається автоматично; завжди викликає stop() і викликається при виході з броузера та при перезавантаженні аплета.

Приклад: аплета

1. import java.awt.Graphics;

2. import java.applet.Applet;

3. class SimpleApplet extends Applet {

4. public void paint (Graphics g) {

5. g.drawString (10, 10, "Hello world!");

6. }

7. }

Найпростіший аплет виглядає так.

Метод paint (рядки 4-6) визначає, як аплет перемальовує себе в той момент, коли віконний менеджер посилає броузеру запит на перемальовування.

Включення аплета в WWW-сторінку виробляється в такий спосіб. У мові HTML 2.0 передбачені спеціальні конструкції <applet> і <PARAM>. Перша з них задає ім'я класу, що завантажує, і розміри області у вікні броузера, виділеної аплету. Конструкція <PARAM> служить для передачі інформації з WWW-сторінки в те середовище, у якій буде виконуватися аплет.

<applet code=SimpleApplet.class width=200 height=100>

<PARAM NAME=font VALUE="TimesRoman">

<PARAM NAME=size VALUE="12">

<h3>Якщо ви бачите цей текст,

те ваш навігатор не підтримує Java </h3>

</applet>

Даний фрагмент містить простий приклад включення аплета в WWW-сторінку.

Оскільки броузери ігнорують невідомі конструкції, у навігаторі, що не підтримує Java, буде видний текст “Якщо ви бачите цей текст, то ваш навігатор не підтримує Java“

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

public void init () {

String fontname = getParameter ("name");

String fontSizestring = getParameter ("size");

int theSize = Int.parseInt (fontSizeString);

. . .

}

1.4.2 JAVA-машина

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

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

У контексті проекту Java специфікація віртуальної машини є частиною комплексу мір, спрямованих на стандартизацію Java-середовища на забезпечення її незалежності від апаратно-програмної платформи. Крім того, варто враховувати те специфічне середовище, у якій повинні готуватися й працювати Java-програми. Якщо Web-сторінка містить Java-аплеты, ці аплеты будуть передаватися по мережі. Виходить, досить бажано, щоб Java-код був як можна більше компактним; у противному випадку час завантаження сторінки ризикує стати занадто великим. Відповідно, архітектура й система команд Java-машини проектувалися таким чином, щоб усіляко сприяти компактності коду. З іншого боку, формат команд Java-машини досить простий (звичайно команди не мають операндов і займають один байт), тому можливо її (машини) ефективну емуляцію. Із цієї причини програми, підготовлені для виконання на Java-машині, часто називають байтами-кодами.

1.4.3 Типи даних які підтримує JAVA-машина

Java-машина підтримує наступні стандартні типи даних:

byte - однобайтові цілі числа;

short - двобайтові цілі числа;

int - чотирьохбайтові цілі числа;

long - восьмибайтові цілі числа;

float - чотирьохбайтові дійсні числа у форматі IEEE-754;

double - восьмибайтові дійсні числа;

char - двобайтові беззнакові символи в кодуванні Unicode.

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

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

Є ще два стандартних типи даних:

object - чотирьохбайтове посилання на об'єкт (масиви трактуються як об'єкти);

returnAddress - чотирьохбайтовий адрес повернення з методу.

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

Java-машина є 32-бітною. Більш довгі значення (long, double) представляються як пари чотирьохбайтових величин. Не обмовляється, у якому порядку розташовуються елементи пари; більше того, верифікатор байт-кодів зобов'язаний виявляти й відкидати програми, що намагаються "вручну" встановити довгі значення.

1.4.4 Регістри

В Java-машині повинні підтримуватися наступні регістри:

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

vars - базовий регістр для доступу до локальних змінних поточного методу.

optop - вказівник на вершину стека операндів. Java-машина є стековою, тому основна частина команд бере операнди зі стека й туди ж поміщає результат.

frame - вказівник на структуру, що містить оточення часу виконання.

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

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

Для забезпечення нормального повернення з методів виконується відновлення регістрового оточення методу.

Для обробки виняткових ситуацій Java-машина виконує прохід по стеку викликів методів і відшукує саму внутрішню конструкцію catch, що обробляє вийняткову подію.

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

1.4.5 Вказівники

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

Якщо потрібно передати посилання на змінну базового типу, такого, наприклад, як int або long, то нічого не вийде - змінні базових типів передаються за значенням, а не по посиланню. Тому не можна прямо створити мовою Java еквівалент наступної програми, складеної мовою С:

// Деяка змінна

int nSomeValue;

// Функція, що змінює значення змінної,

// заданою своєю адресою

void StoreValue(int *pVar, int nNewValue)

{

pVar->nNewValue;

}

. . .

StoreValue(&nSomeValue, 10);

Вихід, однак, є.

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

Що ж стосується даних базових типів, якщо вам потрібно передавати на них посилання, та варто замінити базові типи на відповідні класи, що заміщаються. Наприклад, замість типу int використайте клас Integer, замість типу long - клас Long і так далі.

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

Integer nSomeValue;

nSomeValue = new Integer(10);

Перший рядок створює неініціалізоване посилання з ім'ям nSomeValue і типом Integer. При спробі використання такого посилання виникне виключення.

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

Ім'я об'єкта nSomeValue типу Integer ви можете передавати функціям як параметр, причому це буде посиланням на об'єкт.

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

У мові Java реалізований механізм масивів, що виключають необхідність використання покажчиків.

1.4.6 “Збір сміття”

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

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

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

1.4.7 Система команд JAVA-машини

Команда Java-машини складається з однобайтового коду операції, за яким ідуть операнди (якщо такі є). Можна виділити наступні групи команд:

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

команди запам'ятовування даних зі стека в локальні змінні.

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

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

арифметичні команди. Операнди витягаються зі стека; туди ж поміщають результат.

логічні команди (зміщення, і, або, що виключає або).

команди перетворення до іншого типу.

команди передачі керування. Наприклад, у команді jsr (перехід на підпрограму) операндом служить відносна адреса переходу; адреса команди, що випливає за jsr, міститься на вершину стека операндов. Є команди для реалізації перемикачів.

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

команди маніпулювання з полями об'єктів (установити/ прочитати звичайне/статичне поле).

команди виклику методів. Їх чотири. Команда invokevirtual викликає (віртуальний) метод на основі аналізу інформації часу виконання. Команда invokenonvirtual здійснює виклик на основі інформації часу компіляції - наприклад, виклик методу батьківського класу. Команда invokestatic викликає статичний метод класу. Нарешті, команда invokeinterface викликає метод, представлений інтерфейсом. Виконання всіх перерахованих команд зв'язано не тільки з передачею керування, але й з аналізом різного роду таблиць.

команда порушення виняткової ситуації - athrow.

інші об'єктні операції (створити об'єкт, перевірити тип об'єкта).

команди синхронізації (увійти в критичний інтервал, вийти з нього).

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

1.5 Взаємодія з серверами баз даних - JDBC

JDBC (Java DataBase Connectivity) - набір класів і методів, які використовуються у мові програмування Java для роботи з базами даних. JDBC забезпечує прості, універсальні й добре адатуємі засоби взаємодії з різними СУБД.

Інтерфейси JDBC, розроблені корпорацією Sun, забезпечують виконання всіх стандартних операцій з базами даних SQL, а розробники PostgreSQL надають конкретну реалізацію цих інтерфейсів. Реалізація робить всю взаємодію з базою даних: підключення, реєстрацію, виклик збережених процедур і т.д. Інтерфейси спроектовані таким чином, що програма, що використовує JDBC, може підключитися до будь-якої JDBC-сумісної бази даних без модифікації коду. Втім, при цьому все-таки необхідно враховувати деякі обставини.

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

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

Одне з переваг драйвера JDBC для PostgreSQL полягає в тім, що він є драйвером «четвертого типу». Це означає, що він написаний на «чистій» мові Java, що дозволяє перенести його куди завгодно й використати на будь-якій платформі з підтримкою TCP/IP, оскільки драйвер підключається тільки через TCP/IP.

1.5.1 Використання JDBC

Класи JDBC представляють основні компоненти взаємодії програми з SQL. У всіх основних класів JDBC - Connection, Statement, ResultSet, Blob й Clob - є прямі аналоги в SQL. Крім того, в JDBC включені допоміжні класи - наприклад, класи ResultsSetMetaData й DatabaseMetaData призначені для роботи з метаданними. Зокрема, вони використаються для одержання інформації про можливості бази даних, для перевірки типу результату запитів, у процесі налагодження й просто в ситуаціях, коли ви не маєте інформації про дані, з якими працюєте.

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

1.5.2 Принципи використання JDBC

Для створення фізичного підключення до бази даних використовується об'єкт Connection, що представляє фізичне підключення до бази даних. Об'єкт Connection потрібно для створення об'єктів Statement, за допомогою яких в JDBC базі даних передаються команди SQL.

Існує три різновиди об'єктів Statement: базовий клас Statement, класи PreparedStatement і CallableStatement.

Statement s = c.createStatement():

Тут створюється об'єкт класу Statement з ім'ям s для об'єкта Connection з ім'ям с. Далі створений об'єкт Statement може використатися для виконання запитів до бази даних.

У класі Statement особливо важливі два методи. Перший, executeQuery, одержує один аргумент (код виконуваної команди SQL) і повертає об'єкт класу ResultSet, про яке мова йтиме нижче. Метод executeQuery призначений для виконання команд, що повертають набори даних, наприклад запитів SELECT. Об'єкт, що повертає, ResultSet представляє дані, отримані в ході запиту.

Приклад вибірки даних з бази даних

Statement s = nul 1: try {

s = c.createStatement;

} catch (SQLException se) {

System.out.printlnC'We got an exception while creating a statement:" +

"that probably means we're no longer connected."):

se.printStackTrace();

System, exit(l);

}

ResultSet rs = null:

Try {

rs = s.executeQuery("SELECT * FROM books");

} catch (SQLException se) {

System.out.printlnC'We got an exception while executing our query:" +

"that probably means our SQL is invalid"):

se.pnntStackTrace():

System.exit(l):

}

int index = 0:

try {

while (rs.next) {

System.out.printlnC'Here's the result of row " + index++ + ":"):

System.out.pri ntln(rs.getStri ng(1)):

}

} catch (SQLException se) {

System.out.pnntlnC'We got an exception while getting a result:this " +

"shouldn't happen: we've done something really bad.");

se.pnntStackTrace();

System.exit(l):

}

Спочатку ми створюємо об'єкт Statement, а потім використовуємо метод executeQuery цього об'єкта для виконання запиту SELECT * FROM books. Повернутий запитом об'єкт ResultSet використовується для виводу отриманої інформації.

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

...