pátek 1. června 2007

Google Gears - když offline je online

Vždycky, když si myslím, že mě už svět webových aplikací nemá čím překvapit, tak se objeví Google a rozšlape můj náhled jako domeček z karet. Poslední majstrštik se jmenuje Google Gears a jedná se o framework, který umožňuje webové aplikaci fungovat v hybridním online/offline módu.

Představte si, že děláte web aplikaci pro plánování úkolů. U takové aplikace by nebylo na škodu, kdyby si člověk mohl svoje úkoly prohlížet i bez nutnosti, aby byl neustále připojený k serveru. Jinými slovy, je potřeba distribuovat část dat na klientskou stranu a vyřešit problémy s cacheováním statických resourcu a nebo zajistit synchronizaci klientského stavu po přechodu zpět do online módu. To vše samozřejmě pokud možno, bez toho aby si byl uživatel nutně vědom rozdílu.

Následující obrázek (pochází ze stránek Google Gears) ukazuje architekturu aplikace, která výše uvedené problémy řeší a nebo se o to alespoň pokouší.

Základním blokem je takzvaný Data Switch, což je chytrá škatulka, která se rozhoduje podle stavu připojení, jestli se budou požadavky směrovat na server a nebo zpracovávat lokálně. Data Switch je vlastně proxy objekt, který přímo volá Server Data Layer a nebo Local Data Layer což jsou jenom můstky, které převádějí volání v intencích klienta (forma lokálního požadavku např. dotaz do DB) či serveru (HTTP požadavek). Local Data Layer ovšem otevírá Nerudovu otázku Kam s ním? resp. Kam s daty?.

Z tohotu důvodu je na klientu potřeba trvalé datové úložiště, k tomu se nabízí přímo databáze. Jenže klientské úložiště znamená, že musí docházet k synchronizaci stavu mezi klientem a serverem a to podchycuje krabička jménem Sync Engine využívající Comet přístup viz článek Komety přilétají. Tohle všechno jsou úkoly, pro které tu je Google Gears.

Google Gears má tři základní komponenty.

  • LocalServer - lokálně cacheuje statické resources (obrázky, HTML, javascript) podle jejich URL
  • Database - relační databáze, běžící na lokále, která slouží pro ukládání dat
  • WorkerPool - thread pool, který umožňuje asynchronní exekuci na klientu např. synchronizaci se serverem.

Z implementačního hlediska je Google Gears směsicí javascriptu a specifického rozšíření prohlížeče. To znamená, že pokud se aplikace rozhodne využít Google Gears, musí jej mít klient nainstalovaný. To je samozřejmě nevýhoda, ale těžko si představit jiné řešení nabízející stejné možnosti bez požadavků na klienta.

Google Gears je podle mě dalším dílkem do skládačky technologií, které Google používá pro koncept dekstopových aplikací v prostředí webu, viz jejich kancelářský balík. Google Gears se stejně jako jakákoliv jiná technologie nehodí úplně pro všechny typy webových aplikací, ale svoje místo jako Google Web Toolkit si určitě najde.

pondělí 28. května 2007

Teorie a praxe v J2EE světě

Připadá vám J2EE stack jako složitá technologie? Mě tedy ano a vždycky to vysvětluji tím, že se jedná o technologii, která byla navržena k řešení opravdu enterprise výzev jako scalability, fail over apod. Prostě ty EJB mají svůj důvod, stejně jako distribuované transakce a nebo RMI. Každá aplikace přece potřebuje nějak řídit transakce, mít nějaký managovatelný komponentový model a taky možnost vzdáleného volání, které se jeví jako lokální. Pokud máte podobnými poučkami vypláchnutý mozek z chytrých knih a tutoriálu, pak je možná trocha praktického vystřízlivění.

Předem, většina výše zmíněných technologií má v J2EE stacku svoje místo o tom netřeba diskutovat. Bohužel praxe občas ukazuje, že některé z těchto technologií se v praxi ukázaly jako překonané. Připadá vám eBay jako dostatečně referenční materiál o tom, jaká technologie z J2EE stacku jsou opravdu použitelné pro ty největší aplikace? Pokud se vám eBay nezdá referenční, tak přidávám pár údajů z jejího provozu.

  • denně obslouží 1 miliardu page view
  • 26, slovy dvacet šest, miliard vykonaných SQL za den
  • 3 miliardy volání API na měsíc

Teď je na řadě otázka, jaké technologie z J2EE stacku by jste zvolili, kdybyste byli hypoteticky architekty eBay. Udělejte si malý soukromý seznam...

Máte ho? Tak dobře budeme odmazávat podle toho co v eBay nepoužívají. Já bych určitě na prvním místě tipoval JTA a především distribuované transakce. Špatně, nic takového v eBeay nepoužívají, většina DB operací jede v auto-comit módu! Pak bych použil EJB, přece jenom jim to musí řádně škálovat a to určitě na úrovni každého volání API. Opět špatně. Můžete klidně tipovat dál a svoje výsledky si můžete porovnat s prezentací o architektuře eBay od Dana Pritchetta z eBay.

Celkově vzato, jediná J2EE technolohgie zmíněná v této prezentaci jsou Servlety. Ač to není přímo zmíněno, tak bych hádal ještě JMS, JMX a možná JCA. Ta prezentace je opravdu velice zajímavá, protože se málokdy podaří nahlédnout pod pokličku architektury jiných aplikací, než které tvoříte. Ještě pár odrážek, které mě zaujaly.

  • celá aplikace je kompletně stateless
  • práce náročná na CPU je přesunuta z databáze na aplikaci (referenční integrity, joiny, řazení)
  • výstupním formátem business logiky je XML, které se XSL transformacemi žene ven jako HTML
  • vlastní OR nástroj

Pokud jste si výše zmíněnou prezentaci prošli, pak možná nevěříte vlastním očím. Tahle prezentace totiž vyvrací většinu toho co si můžete přečíst v chytrých knížkách o J2EE. V podstatě tu jsou dvě možnosti, buďto je z J2EE něco v nepořádku a nebo je eBay tak atypickým projektem, že tam i J2EE se svými možnostmi selhává. Odpověď nechávám na ctihodném čtenáři...