Zasoby środowe:

1. Ciekawy skrót (z ciekawego bloga):
1. Things That Get People Excited (let's call them TTGPEs)
2. KISS
3. WIL (well I like it)
4. WMSDT (well Microsoft do that)
5. Duże ma też znaczenie też podejście "appeal to authority" (np Stefan and Mark Baker są autorytetami od REST)
2. Trwa walka w standardzie usług webowych - REST (google) lub SOA (MS/IBM)
3. Inny blog z BEA
4. Quercus - cyrk na kółkach czyli PHP napisany w czystej Javie
5. Przyjrzyj się tytanom VFP (Hsia i Rick) + ten rosyjski serwer o VFP.ru
6. Świetny serwer cytatów (np. Einsteina)
7. Serwer informacyjny - http://www.it-director.com/
   
8. Przy tworzeniu i projektowaniu oprogramowania należy pamiętać o F. Brooks. Czyta to się jak Biblię "wszyscy to znają i czytają ale nikt nie przestrzega...". Są też tam idee spowalniające projekt np. "syndrom drugiego systemu", "mityczne pojęcie człowieko-miesiąca" (nie sumuje się wydajność od zatrudnienia większej ilości osób), "zamiast używania wielu wyspec. narzędzi lepiej używać jednego ale z wieloma dodatkami" , "zespół naczelnego chirurga" (wykonuje on najtrudniejszą część operacji, resztę kończą jego pomocnicy)....
9. Super historia o Początkach technologii AJAX, która powstała w MS -Alex Hopmann
   
10. Bezpieczeństwo - AJAX (a w zasadzie XMLHttpRequest) podlega zasadzie "ograniczenie dostęp do zasobów tej samej domeny" (same origin policy). Można to łatwo obejść ponieważ dostęp do dwóch innych zasobów w przeglądarce nie podlegają tym restrykcją (polityce bezp.). Mowa oczywiście o skryptach i obrazkach. I tu tkwi główne niebezpieczeństwo protokołu HTTP. Z drugiej strony mamy rozproszoną architekturę korporacyjną SOA tzn. wywołanie zdalnych procedur (usług). Często do realizacji usług webowych (WS) wykorzystuje się SOAP, i to działa. Ale w przypadku przeglądarki i lekkiego klienta to jest za ciężkie. Dlatego w architekturze Web 2.0 stosuje się lekki protokół REST. Oferuje on przejrzysty model REST budowanie usług webwych w oparciu o specjalnie zdefiniowany adres do zasobów podawanych w adresie HTTP w zwykłej przeglądarce. Zasada działania REST opiera się o trzy reguły:
1. Usługa REST wyraża się poprzez URL np. jako adres - http://bea.com/content/getArticles?author=joe
2. Trzeba podać operację (poprzez żądanie HTTP):
1. GET odczyt,
2. POST zapis,
3. PUT aktualizacja
4. DELETE usunięcie
   
3. Zwracane są dane w formacie XML / JSON
11. REST ma operacje takie same jak DML w standardzie SQL czyli jest to kolejny dowód na pożyteczność takiego podejścia
12. Zasoby z powyższego serwisu (http://dev2dev.bea.com/pub/a/2007/05/google-mashups.html):
1. http://dev2dev.bea.com/pub/a/2005/08/ajax_introduction.html
2. http://dev2dev.bea.com/pub/a/2007/02/introduction-json.html
13. Inny problem - dostęp do bazy danych w językach programowania. Nowoczesne języki obiektowe (a nawet dynamiczne jak Python) wymagają ścisłego typowania danych. Powoduje to problemy przy dostępie do danych w bazach relacyjnych i przesyłania ich do pól w językach programowania. Najczęściej wymagane jest mapowanie. I tutaj pojawiają się problemy jakimi narzedziami to opisać. Wyróżniamy generalnie dwa sposoby:
    
1. Natywny
1. zaszłościowy:
1. przykładowo jak języki 4GL np. Informix 4GL (pożyteczne jest w nim odwzorowanie klasycznego problemu ORM z którym borykają się języki obiektowe np. Java czy C# struktur danych w rekordzie z bazy czy tabeli w pola i struktury w programie - DEFINE ... LIKE)
2. VFP bardzo nowocześnie, dodatkowo istnieją funkcje do przejścia z bazy to XML (CURSORTOXML) i na odwrót (XMLTOCURSOR)
2. nowoczesny poprzez ORM - Java Hibernate
3. nowocześniejszy - poprzez LINQ w C# (wady: działa z natwynym MS SQL Serverem i brak mu automatu do adnotacji/translacji klas - trzeba to robić zewnętzrnym 'sqlmetal' na piechotę)
   
2. Inny - np. obudowanie w specjalny wrapper składnie języka SQL jak to ma miejsce w dostępie ADO (ASP) czy ADODB (PHP), ale dane wysyłane i odbierane jako tekst, są też problemy z danymi binarnymi np. pochodzącymi z BLOB-ów.