Nie jest to jednak najważniejsza wada CGI. W CGI nie istnieje możliwość zapamiętywania informacji o stanie połączenia (sesji). Ponadto w skrypty CGI trzeba ręcznie wpisać odwołania SQL dostosowane do używanego serwera bazy danych. Zmiana serwera będzie wymagać przekodowania całej aplikacji. CGI nie zapewnia ponadto żadnych środków bezpieczeństwa.

API serwerów Web

Ograniczenia CGI spowodowały, że producenci serwerów Web wyposażyli je w firmowe zestawy funkcji programistycznych API, pozwalające na uniknięcie niektórych niedogodności CGI. Popularne NSAPI (Netscape) i IISAPI (Microsoft) umożliwiają bezpośrednie przekazywanie parametrów wywołania z przeglądarki do serwera bazy danych lub programu aplikacyjnego. Zwiększa to wydajność aplikacji klient/serwer i zapewnia większe bezpieczeństwo danych.

Wadą tych API jest ich ograniczenie do jednego serwera Web. Aplikacji napisanej dla serwera Microsoft nie można uruchomić z serwerem Netscape (i odwrotnie). Jeżeli więc potrzebna jest współpraca aplikacji z różnymi serwerami Web - wracamy do CGI. CGI, NSAPI i IISAPI są obecnie de facto standardami i wszyscy producenci serwerów Web i narzędzi będą musieli je wspierać.

Rozwiązania hybrydowe

Firmowe API i CGI są dodatkową warstwą oprogramowania między stacją klienta a serwerem bazy danych. Najwięksi producenci serwerów baz danych eliminują tę warstwę przez dostarczanie firmowych kombinacji serwera bazy danych z serwerem Web. I tak Oracle oferuje WebServer, Informix - Web DataBlade, IBM - Merchant Server, Netscape - LiveWire Pro a Sybase - web.SQL. Produkty te są oparte na odpowiednich serwerach baz danych; produkt Netscape korzysta z serwera bazy danych Informix.

Te rozwiązania hybrydowe eliminują większość wspomnianych problemów: utrzymują stan połączenia (sesję), otwierają proces bazy danych tylko raz na początku (co zwiększa wydajność całej aplikacji) oraz zapewniają lepsze bezpieczeństwo danych, gdyż wykorzystują własne rozwiązania wbudowane w serwer bazy danych. Niektóre serwery baz danych mają wbudowane mechanizmy posługiwania się szyfrowaniem komunikacji z bazą przez wykorzystanie komercyjnych pakietów szyfrujących lub protokołu Secure Sockets Layer.

Ograniczenie tego rozwiązania jest podobne jak w przypadku API: aplikacje dobrze i szybko działają z jednym serwerem baz danych. Jeśli trzeba korzystać z innego serwera bazy danych, konieczne jest używanie dodatkowej warstwy oprogramowania (middleware) lub pomostów (gateway) - podobnie jak to ma miejsce w tradycyjnych aplikacjach klient/serwer. Aplikacje także nie są przenośne.

Utrzymywanie stanu

Większość dawnych narzędzi do tworzenia aplikacji klient/serwer obecnie ma już wersje służące do tworzenia systemów transakcyjnych w Internecie. Utrzymywanie stanu połączenia realizowane jest przez zapisywanie informacji o sesji zarówno na serwerze aplikacji, jak na stacji klienta (w postaci specjalnych plików cookies) i odtwarzanie jej stanu przy kolejnym wywołaniu ze stacji klienta.

W pewnych kompleksowych rozwiązaniach architektonicznych (np. architektura NCA firmy Oracle lub ONE firmy Netscape) do komunikacji aplikacji z serwerem baz danych i serwerem aplikacji oraz utrzymywania stanu sesji proponuje się wykorzystanie nowych protokołów, jeszcze nie w pełni zestandaryzowanych (na różnych etapach opracowania przez organizacje międzynarodowe i przemysłowe). Protokół komunikacji międzyobiektowej Internet InterüObject Protocol (IIOP), będący podzbiorem protokołu ogólnego GIOP, może służyć do stworzenia "bocznej furtki" komunikacji między klientem a serwerem. Za jego pomocą można utrzymywać między nimi sesję (znika problem bezstanowości HTTP).

Transakcyjność

Utrzymywanie stanu, a zapewnienie poprawnej obsługi transakcji w Internecie to dwie zupełnie różne sprawy. Jedną z metod zapewnienia obsługi transakcyjnej jest użycie monitora transakcji. Obecne systemy do obsługiwania rozproszonych transakcji - monitory transakcji - są przeznaczone dla dużych instalacji i mają także rozszerzenia do pracy w Internecie. Zapewniają one nie tylko utrzymywanie stanu połączenia, ale wraz z odpowiednim protokołem obsługi komunikatów realizują cztery podstawowe własności systemów transakcyjnych - atomowość, spójność, izolacja i trwałość (Atomicity, Consistency, Isolation, Durability - ACID).