Управлението от страна на сървъра при универсалния клиент-сървър модел не се обхваща от определени стандарти, какъвто е случаят при клиента. Тук нещата са специфични за всяко приложение, но те могат да се групират в две основни техники за осъществяване на достъп до информацията на база данни по Web технология.

Първата се базира на генерирането на статични HTML страници. Втората се основава на създаването на динамични бази от данни, достъпни непосредствено чрез Web. Трети вариант е възможен при комбиниране на първите два.

Генериране на статични HTML страници от база данни

Тази техника във всичките си стъпки е статична:

1. Обслужване на базата данни в режим off-line.
2. Периодично генериране на HTML страници като сечение на БД.
3. Прехвърляне на страниците във Web сървър.
4. Консултиране на страниците от сървъра.

Реализацията на този модел е относително лесен за осъществяване, прост за поддръжка и не изисква допълнителни инвестиции. Неудобствата, свързани с неговото използване не са малко. Информацията във Web сървъра не се обновява автоматично при промяна на данните в базата данни.

Генериране на динамични HTML страници от база данни

Реалните условия на динамично променяща се информация в една БД налагат и съответните гъвкави методи за консултиране на данните в нея по Web технология. При тази техника са разработени пет основни архитектури.

1. CGI интерфейса е станал своеобразен стандарт за всички производители на Web сървъри (Фигура 11).


Фигура 11 - Взаимодействия при CGI архитектура

Относително простият за реализация и поддържане CGI модел предизвиква често задръстване на сървъра при много едновременни заявки от клиентски машини. За всяка, получена в сървъра заявка CGI модула стартира отделен процес с отделна SQL заявка към СУБД. Тази архитектура е многоплатформена, CGI модулите се реализират на избран от разработчика език. При възникване на грешка отпада една заявка, с което не се предизвиква срив в системата.

2. API (Application Program Interface) е архитектура създадена като алтернатива на CGI от Netscape и Microsoft със сходна схема на функциониране. С API се въвежда един естествен диалог между Web сървъра и съответните приложения за достъп до БД. С помощта на предварително компилиран DLL ("Процес" от Фигура 11) в общ блок от паметта се извършва обработка на параметрите за заявката, получава се резултата от заявката и динамично се генерира HTML страница. Приложението е многонишково, но се реализира по различен начин. Netscape въвежда NSAPI, а Microsoft ISAPI, които са несъвместими помежду си. Грешките се обработват трудно поради общо използваната памет, което може да доведе до срив в системата.
3. ASP (Active Server Page) е архитектура разработена от Microsoft. В основата на ASP е заложена идеата за интерпретиране на код в сървър изпратен от клиент. В статичните HTML страници се вмъкват допълнителни елементи, които изпратени в сървъра ще бъдат интерпретирани от съответен интерпретатор. Подобна идеа е реализирана при PHP/FI, където в HTML кода се вмъкват инструкции, написани на скриптов език, подмножество на езика PERL, и интерпретирани във Web сървър от вида Apache с активиран модул за интерпретация. В този случай HTML страниците са с разширение .phtml. Предшественик на тази архитектурна схема е технологията SSI, с която се постига диалог с клиента почти в реално време. Схемата на функциониране на тази технология е проста и достъпна за развитие. "Процесът" от Фигура 11 е интерпетираща част в сървъра, където се обработва скрипт кода от клиентската страница, извлича се SQL код, получения резултат от БД се конвертира в HTML формат преди да бъде изпратен обратно в браузъра на клиента. Съществен недостатък в тази схема е задължителната връзка със сървър за интепретиране на код, което заема ресурс и е процес по-бавен от изпълнението на компилирана програма.
4. WRB (Web Request Broker) или посредник на заявки е архитектура въведена от Oracle. Посредникът играе ролята на арбитър при управлението на разпределени обекти по Web. Заявка от клиент се приема от посредника, който активира процес в отделен блок памет. Всеки процес управлява своя опашка, където се изпълнява заявката и се получават резултати. Брокерът на заявки може да управлява множество процеси едновременно чрез оптимизиране на опашките и заетата памет.


Фигура 12 - Брокер на заявки

Тази архитектура позволява на базата на протокола TCP/IP процесите да бъдат разпределени между няколко машини. Архитектурата WRB е изключително стабилна при работа и надежна по отношение на резултатите. Обемът на обработваната информация не влияе на скоростта на изпълнение на заявките. При възникване на грешка, брокерът на заявки е в състояние автоматично да рестартира обработката. Единствен недостатък тук може да се посочи много високата цена за реализация и необходимостта от специлно подготвен персонал за съпровождане и развитие на системата (Фигура 12). Изискванията към Web сървъра са специфични и обикновено се удовлетворяват от фирмени разработки като Oracle Web Server.

5. Архитектура "реле" е метод, основан на най-нови разработки в информационните технологии. Обектно-ориентираният модел, езикът Java, и разработките на SUN в областта на CORBA стандарта намират приложение в реализацията на тази архитектура. Фирмата Microsoft използва DCOM метод в тази идеа. Сървърът HTTP инициира начален диалог между обекти-клиент и обекти-сървър. Всяка клиентска заявка извиква съответен метод от списък с приложения в сървъра. Експериментират се различни разработки в усилията за реализация на тази архитектура. За комуникация между отдалечени обекти в среда Java се използва метод RMI (Remote method Invocation), Java/CORBA технологията прилага IIOP (Internet Inter-ORB Protocol). Прилагането на тази архитектура предполага функционална пълнота на приложенията, но реализацията е сложна.