Архітектура клієнт-сервер або Web: вибір розробника, Різне, Програмування, статті

Везе розробникам! Їм рідко доводиться мати справу з тими програмними продуктами, які вони створюють. Навіть якщо, беручи чергове рішення, розробник виконаний благих намірів, це аж ніяк не гарантує продуктивної роботи користувачів та адміністраторів з його застосуванням. Останнім часом серед найбільш важливих питань створення мережевих додатків з’явився ще один: яку вибрати архітектуру – клієнт-серверну або засновану на службі Web?


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

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

Клієнт-сервер та Web: розглянемо ближче


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

Справа ускладнюється ще й тим, що досить важко дати точне визначення двом розглянутим архітектурним підходам. У класичній архітектурі клієнт-сервер клієнтська частина представлена ​​так званим “Товстим” клієнтом, тобто додатком, розробленим за допомогою пакета типу Visual Basic або Delphi. Своє “прізвисько” він отримав у зв’язку з тим, що крім рівня представлення інформації містить ще й бізнес-логіку прикладної задачі. Такий клієнт працює не тільки з реляційної базою даних, але і з файл-сервером. Стандартне Web-додаток, як правило, використовується лише для представлення даних. Вся бізнес-логіка в цьому випадку виконується на сервері додатків, який і звертається до СУБД.

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

Дослідження продуктивності


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

Закладена у програму бізнес-логіка полягала в основному з SQL-запитів, і її головною метою було просто завантажити процесор машини. Програми на “товстих” клієнтів містили як прикладну частину, так і функції управління для користувача інтерфейсом, наприклад введення і редагування даних. Бізнес-логіка, яка працювала на серверах додатків, була створена переважно за допомогою програмного інтерфейсу ISAPI (Internet Server Application Programming Interface) фірми Microsoft і містила виклики функцій динамічних бібліотек, зокрема відповідальних за формування сторінок HTML. Для доступу до таблиць бази даних обидві версії додатків – і клієнт-серверна і Web – використовували інтерфейс ODBC (Open Database Connectivity).

У процесі запуску наших “доморослих” додатків ми відзначили, що динамічні бібліотеки, написані на Delphi, Працюють швидше DLL, створених за допомогою Visual Basic. І взагалі, продуктивність Delphi нас приємно здивувала. Справа в тому, що ми використовували спеціальну бібліотеку WebBridge фірми Borland International, дозволяє абстрагуватися від конкретного способу взаємодії з Web-сервером, будь то інтерфейс ISAPI або NSAPI (Netscape Application Programming Interface) фірми Netscape Communications.

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

Сервери баз даних різних постачальників мають власний синтаксис збережених процедур. Так, в сервері Oracle реалізований мову PL / SQL, а в MS SQL Server – мова Transact-SQL. Це дещо обмежує можливість застосування процедур, адже вам навряд чи захочеться викидати масу напрацьованого коду, якщо ви раптом зміните постачальника СУБД. Тим не менше ми вважаємо, що розумне використання збережених процедур здатне в рівній мірі підвищити продуктивність додатків і в клієнт-серверній середовищі і в середовищі Web.

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

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

Цікаво, що трафік в набагато більшій мірі залежав від використовуваного сервера баз даних (Oracle, MS SQL Server або DB2), ніж від архітектурного підходу. Зокрема, для Oracle ми спостерігали найменший мережевий трафік, а для SQL Server – найбільший.

Велике значення мають і використовуються мережеві протоколи. Так, найбільш “балакучим” виявився протокол NetBEUI, IPX / SPX був більш помірним, і самим “лаконічним” був TCP / IP. Ми також змогли знизити трафік служби DNS (Domain Name Service), використовуючи безпосередні адреси серверів баз даних замість їх доменних імен. Але для мережевих адміністраторів застосування цього методу означає додаткову роботу при установці нових машин.

Завантаження адміністратора


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

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

У Web-середовищі в адміністратора приблизно ті ж завдання. Однак на підтримку користувачів, пов’язану, наприклад, з перезапуском “завислих” додатків, у нього йде набагато менше часу, оскільки Web-браузери, такі, як Microsoft Internet Explorer або Netscape Navigator, “зависають” набагато рідше програм, виконаних за допомогою засобів розробки на зразок Visual Basic або Delphi. Крім того, браузер автоматично отримує класи міні-додатків Java з Web-сервера, тому адміністраторам не доводиться дбати про поширення користувальницьких додатків на локальні диски.

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

Порівняння по надійності


Web-підхід в загальному виявився більш надійним, ніж клієнт-серверний. Підтримка програми, т. е. необхідність внесення нових полів редагування або зміна старих, роблять ПО клієнт-сервер менш стабільним. Епітет “товстий” став синонімом визначення “складний”. Налагодження і тестування додатків клієнт-сервер – досить складний процес, оскільки вони містять велику кількість тісно взаємодіють модулів. З іншого боку, коли під час тестування несподівано починали “сипатися” помилки, виявити їх в “товстому” клієнті було значно легше: ОС Windows виводила на екран відповідне повідомлення.

Характерно, що в Web-середовищі “зависла” DLL, написана за допомогою ISAPI, виводила повідомлення на консоль сервера додатків, але користувач при цьому продовжував дивитися на незмінний екран браузера. У випадку серйозної помилки виконання модуля DLL операційна система Windows NT буде змушена завершити роботу Web-сервера IIS (Internet Information Server) разом з додатком. З точки зору надійності постачальникам слід було б розробляти більш досконалі методи відображення проблем сервера додатків для тих, хто використовує Web-браузер.

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

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

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

Переможцем стає …


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

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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*