Świat użytkownika Web 2.0

Klasyczny model przetwarzania i pracy z HTTP/HTML musi ulec zmianie, a najbardziej przyczynia się do tego popularyzacja Web 2.0 stawiająca programistom i wykorzystywanym przez nich narzędziom zupełnie nowe wymagania.

Klasyczny model przetwarzania i pracy z HTTP/HTML musi ulec zmianie, a najbardziej przyczynia się do tego popularyzacja Web 2.0 stawiająca programistom i wykorzystywanym przez nich narzędziom zupełnie nowe wymagania.

Jeżeli zapyta się osobę "techniczną" o to, czym jest Web 2.0, to usłyszymy rozważania na temat RSS, AJAX, budowy aplikacji mashup, taksonomii związanej z tagami przypisywanymi do blogów lub strategii ich indeksowania i przypisywania. Natomiast rozmowa na ten temat z humanistą będzie zapewne dotyczyła sieci współpracy, social networking lub wykorzystania popularności terminu Web 2.0 w marketingu.

Mimo że jednoznaczna definicja jest trudna, można określić kilka podstawowych elementów, które wyróżniają systemy Web 2.0. Najważniejszym jest zmiana roli użytkownika. Web 1.0 to przeglądanie informacji, katalogów w sklepie itp. z jasnym podziałem na publikującego i czytelnika. Web 2.0 dzięki mechanizmom blogów, komentarzy, tworzenia witryn na podstawie innych witryn (agregacja) lub portali społecznościowych z możliwościami współpracy stawia internautę na zupełnie innej pozycji, bo staje się on nie tylko odbiorcą treści, ale także ich twórcą.

Z technicznego punktu widzenia, aby było to możliwe, klasyczny model przetwarzania i pracy z HTTP/HTML musiał ulec zmianie.

Transformacja 2.0

Najpierw pojawiły się RSS i koncepcja tzw. syndykacji, które są próbą odpowiedzi na jedną z najważniejszych konsekwencji popularyzacji Web 2.0 - olbrzymiego wzrostu ilości informacji publikowanych na WWW, niemożliwego do ogarnięcia przez użytkowników sieci. Wykorzystując standard RSS (lub ATOM) można generować proste pliki XML, zawierające np. listę ostatnio publikowanych artykułów. Taka lista może zawierać słowa kluczowe, streszczenia itp. Specjalna przeglądarka zgodnie z określonym harmonogramem pobiera takie zestawienie, a potem internauta może przeglądać interesujące go artykuły. Równocześnie RSS okazał się wygodnym mechanizmem wymiany newsów między portalami. Warto dodać, że już wcześniej powstała koncepcja portletów (głównie w świecie serwerów aplikacyjnych Javy), które pozwalają osadzać informacje z różnych stron WWW w innym portalu. Technologia ta jest jednak skomplikowana i wymaga bardziej wyrafinowanej infrastruktury niż RSS.

Drugą istotną technologią była koncepcja komunikacji asynchronicznej AJAX (Asynchronous Javascript And XML). Standardowo, komunikacja z serwerem Web polega na przesyłaniu całych stron. Przeglądarka wysyła polecenie GET, co powoduje, że serwer generuje i przesyła stronę HTML przy wykorzystaniu protokołu HTTP. Jeżeli użytkownik wprowadzi jakieś informacje, to wysyła je POST-em na serwer. Aby zobaczyć wynik modyfikacji, konieczne jest ponowne przesłanie całej strony. Protokół HTTP jest z założenia bezstanowy, wszystkie informacje pozwalające zachować stan muszą być jawnie przesyłane razem ze stroną jako pole ukryte, parametr lub przechowywane po stronie serwera (rozwiązanie nieskalowane dla dużego obciążenia). A w większości przypadków zmianie ulega tylko część kodu HTML i nie ma sensu odświeżać całości. Przykładem może być przeglądanie katalogu w sklepie, gdzie lista towarów jest stała, a po wybraniu produktu zmieniać się powinna tylko część zawierająca jego opis.

Przed AJAX-em było kilka prób rozwiązania tego problemu (IFrame, Remote Scripting itp.). Były też próby definiowania standardu tzw. partial caching, gdzie można by wskazać przeglądarce, które elementy strony wymagają odświeżania. Metody te nie zyskały jednak dużej popularności. AJAX zakłada, że po stronie serwera dostępna jest usługa Web, która reaguje na akcje wykonywane przez użytkownika. Dzięki połączeniu DOM (Document Object Model) i danych pobieranych asynchronicznie z serwera można uaktualnić część strony - bez konieczności odświeżania całości. Dzięki temu użytkownik nie widzi migotania interfejsu, aplikacja sprawia wrażenie szybkiej (dane pobierane są w tle) itp.

Problemem z AJAX-em jest to, że bazuje on na JavaScript, języku programowania, w którym trudno napisać skomplikowany kod, a dodatkowo występują niezgodności między przeglądarkami zarówno w warstwie DOM, jak i JavaScript. Programista powinien wybrać odpowiedni pakiet AJAX, który będzie potrafił generować sensowny kod i wysyłać go do przeglądarek. Jednak nawet wtedy programista musi często ręcznie napisać kawałek kodu, który będzie działał po stronie przeglądarki.

W świecie Web 2.0 wygodny interfejs jest jednym z kluczowych elementów, by dane rozwiązanie zyskało popularność. Ale to wiąże się z pisaniem/modyfikacją olbrzymich plików JavaScript, a aplikacje AJAX wymagają specjalnych zabiegów, by były prawidłowo indeksowane przez wyszukiwarki. W większości przypadków nie współpracują też z mobilnymi urządzeniami i trudno sprawić, by prawidłowo działał przycisk "wstecz". Klasyczne aplikacje AJAX wymagają także ciągłej komunikacji z serwerem, choć warto zauważyć, że Google uruchomił projekt Gears, który w przyszłości ma pozwolić na uruchamianie aplikacji AJAX w trybie offline przy wykorzystaniu lokalnej wersji bazy SQLLite oraz mechanizmu przechowywania niektórych obiektów HTML. Technicznie jest to po prostu dodatek do przeglądarki, który z punktu widzenia programisty komplikuje pracę, bo nakłada dodatkowe ograniczenia na konstruowaną aplikację (głównie jej interfejs UI).

Aplikacje w przeglądarce

Aplikacje Web 2.0 wcale nie muszą bazować na "czystym" HTML + CSS + DOM. Można skorzystać z innych możliwości, jakie daje przeglądarka. Pojawia się coraz więcej zapowiedzi narzędzi, które mają oferować tego typu funkcjonalności.

Adobe planuje zaoferować rozwiązanie Apollo do tworzenia bogatych aplikacji internetowych. Apollo to połączenie Flash, Flex, HTML oraz mechanizmów asynchronicznych pozwalających na komunikację z zapleczem serwerowym. Technologia jest w wersji alfa i wciąż brakuje jej odpowiednich narzędzi dla programistów. Warto dodać, że w wypadku Flash istnieje sporo pakietów projektanckich, ale są to głównie narzędzia do pisania reklam lub gier, a nie rozbudowanych aplikacji komunikujących się z systemami zaplecza.

Mozilla Foudnation opracowała dla Firefox model dodatków (XUL), który istotnie ułatwia programowanie interfejsu użytkownika. Z kolei Microsoft zaprezentował w tym roku nową technologię Silverlight, gdzie do opisu interfejsu użytkownika użyta została odmiana XAML. Podobny język używany jest do opisu UI w Windows Presentation Foundation. Obecnie Silverlight obsługuje tylko platformy Windows i Macintosh, ale Novell przygotowuje odpowiedni dodatek również dla Linuxa. Kolejna wersja Silverlight 1.1 (obecnie alfa) umożliwi instalowanie po stronie klienta małego modułu plug-in (kilka MB), który będzie kompilował kod C#, a więc także po stronie przeglądarki będzie można uniknąć JavaScript.

Warto też wspomnieć o języku Sun JavaFX, którego wstępna wersja zaprezentowana została na konferencji JavaOne w maju 2007. Jest to rozszerzenie przeglądarki pozwalające pisać rozwiązania w oparciu o język F3 (Form Follows Function), który potem jest kompilowany i przekazywany do standardowego interpretera Javy. Język nie jest związany z HTML, DOM itp. i przeznaczony głównie do budowy interfejsów. Największą jego zaletą jest to, że zamiast interpretowanego JavaScript, po stronie klienta wykorzystywana jest maszyna wirtualna Javy.

Warto się jednak zastanowić, czy na pewno przeglądarka jest właściwym pojemnikiem na aplikacje Web 2.0? W pewnych scenariuszach sprawdza się doskonale, ale wydaje się, że sam model współpracy Web 2.0 może pozwolić na konstrukcję zupełnie innych aplikacji, które nie będą bazować na HTML. Należy też pamiętać, że Flash/Flex/Apollo, Silverlight, JavaFX itd. tak naprawdę oferują podzbiór funkcjonalności, jakie daje normalna aplikacja desktopowa.

Do tego mechanizmy Web 2.0 nie powinny być ściśle związane z komputerem. Część aktywności można wykonywać za pośrednictwem innych urządzeń - telefonów, PDA, elementów elektroniki użytkowej itp. Już obecnie smartfony pełnią rolę komputerów osobistych i naturalnym ruchem będzie rozszerzenie Web 2.0 na tego typu urządzenia. Klientem w nich na pewno jednak nie będzie uniwersalna przeglądarka, która nie sprawdza się przy kilkucentymetrowym wyświetlaczu i wolnym procesorze, który miałby interpretować JavaScript.

SOA w serwerach Web 2.0

Implementacja części serwerowej Web 2.0 w naturalny sposób korzysta z dorobku związanego z koncepcją SOA/Web Services. Usługi są naturalnym sposobem komunikacji aplikacji AJAX czy Silverlight z zapleczem serwerowym. Zasady konstrukcji komunikatów SOA, takie jak autonomia, ściśle zdefiniowanie granice lub zgodność ze zdefiniowanym kontraktem sprawiają, że programista UI może z nich łatwo skorzystać. W praktyce przesyła on kompletne dokumenty, niemal jak w architekturze SmartClient. Dodatkowo, na przykład dla aplikacji AJAX, strona serwerowa generuje automatycznie proxy pozwalające wywołać usługę SOA. Z punktu widzenia programisty jest to normalna metoda JavaScript.

Przy okazji warto zauważyć, że w takim modelu niekoniecznie trzeba korzystać z pełnego stosu usług Web. Standardy SOAP i WS-Security w przypadku aplikacji Web 2.0 są tylko narzutem. Stąd ponownie wracają do łask stare mechanizmy - interfejs pobiera dane zapisane w POX (Plain Old XML) lub JSON (JavaScript Object Notation) i przesyła REST (GET/PUT z protokołu HTTP). W tym momencie taka usługa jest prosta do skonsumowania. Nie oznacza to, że SOAP/WS-* są niepotrzebne, ale przy komunikacji warstwy frontend z pomocniczymi usługami serwerowymi, czyli częścią UI zlokalizowaną po stronie serwera, są one zbyt skomplikowane. Do zabezpieczenia komunikacji w zupełności wystarczy szyfrowanie SSL. Stąd frameworki do pisania usług Web (WCF, VRapotor inne) coraz częściej oferują także możliwość przesyłania komunikatów przy wykorzystaniu mechanizmu REST/POX lub opakowywaniu parametrów w formacie JSON.


TOP 200