Znowu piszę sobie:
Świetny artykuł na zdnet-cie: o istocie architektury klient - serwer. Po raz pierwszy wymyślił to pojęcie IBM w 1968 i polegał na zbudowaniu potężnej maszyny (mainframe) zawierającej bazy danych (do przechowywanie jej jedynie) i otoczony satelitami - małymi stacjami roboczymi przetwarzającymi dane pobrane z serwera (a więc klient przetwarza - serwer przechowuje). Etapy rozwoju były różne ale zawsze wystepowały dwie strony serwer i klient:
- Pierwszą taką realizacją był System 38 oraz System 51xx. Weryfikacja w życiu tej koncepcji okazała się okrutna. Zabrakło narzędzi do serializacji danych zmienianych przez wielu użytkowników naraz. Próbowano ratować sytuacje poprzez blokowanie dostępu przez innych do informacji raz pobranej przez jednego z klientów ale to pogorszyło jeszcze sprawę z uwagi na często występujace blokady oraz opóźnienia w dostepie (zwane później pessimistic buffering).
- Dlatego wkrótce IBM przesunął punkt cieżkosci na serwer poprzez instalację na nim interpretera RPG II a klientów sprowadził do roli prostych terminali. Codd był pierwszym (10 lat wczesniej), który zaproponował spojrzenie na aplikacje jako interfejs do danych - "Simple model: business applications are user interfaces to business data". Tak nawiasem mówiąc Codd wymyślił relacyjny model nie dlatego, że były problemy z przechowywanie i dostępem fizycznym do danych (baza IMS oraz pliki w COBOL-u świetnie sobie z tym radziły) ale z ujednoliceniem tego dostępu i wyższym poziomem abstrakcji przy manipulowaniu danymi w bazie. Znaczenie pracy Codd polegało na zmuszeniu dowolnej aplikacji do posługiwania się tym samym interfejsem do danych w bazie. Temu zagadnieniu służy wstępna zasada (zerowa) modelu relacyjnego: dostęp do danych wyłącznie przez współdzielony manager bazy danych. Zaowocowało to pojawieniem się w lipcu 1979 i później dużym sukcesem Systemu 38 wykorzystującym RPG/SystemR/ - w tym projekcie wniósł duży wkład Chen. Było to jakieś rozwiązanie ale przyszły nowe czasy.
- Era PC-tów polegała na większej roli klienta. Dane na centralnym serwerze były zmieniane poprzez procedury wbudowane pracujące na bazie serwerowej. Tutaj tez dochodziło do konfliktów ale później na etapie aktualizacji a nie pobierania danych (optimistc blocking). Ale - przeczyło to idei K/S, ze dane były zmieniane u klienta a przechowywane na serwerze
Ten sam problem i rozwój miał miejsce z pojawieniem się Internetu. Początkowo serwer podawał HTML jako porcje informacji w stylu ReadOnly czyli tylko do czytania. Ale wkrótce ludzie wymyślili formularze i zaczęli odsyłać dane do serwera. I znowu pojawił się problem - twrórcy aplikacji znowu nie wiedzieli co się dzieje po stronie klienta. Jest to tzw. "ajaxulation" problem - interakcja pomiędzy lokalnie przechowywanymi danymi w postaci ciasteczek, lokalnie przetwarzanymi skryptami w JS oraz danymi po stronie serwera. Problem łatwego sposobu oszukiwnia serwera co się naprawdę dzieje po stronie klienta. Może to doprowadzić do szeregu poważnych nadużyć.
