oRESTovaná externalizace dat aneb když to másh nahoře

Další díl z cyklu oRESTování začnu možná trošku zmateně a vyhlásím soutěž o druhou nejlepší RESTovou aplikaci, přičemž je nám všem jasné, že webové prohlížeče (webové stránky jako takové) jsou tou první.

Tak co, už jste na to přišli?

Nechám Vás ještě chvíli se trápit...

Tak dobře. Nebudu Vás dlouho napínat, jsou to Feed Readery.

Mezi námi bloggery není jediný, který by nevěděl, co to je a jen velmi málo, kteří nepoužívají žádný. No ale pro jistotu pro ty, kteří nevědí, o co se jedná, malá naučná vsuvka.

Před dávnými a dávnými lety vznikl ve vývojovém centru firmy Netscape protokol Rich Site Summary (RSS, košatý popis stránky), který umožňoval v kostce popsat obsah stránky. Nejdůležitější částí byl vlastní popis, používaný pro jejich portál (snad vůbec první skutečný portál) my.netscape.com. Jako podružné se tehdy jevily popisy částí stránky.

Postupně se ale se zaváděním publikačních systémů (a hlavně blogů) karta obrátila. Protokol byl přejmenován na Really Simple Syndication (skutečně jednoduchý výcuc, opět RSS, to je ale náhodička, co?) a jeho hlavní náplní se stalo informovat čtenáře stránek o novinkách. Realizace je vskutku jednoduchá - RSS stránky (říká se mu feed) obsahuje ke každému článku jeho identifikátor (typicky část URL článku), odkaz na článek a datum a čas publikace. Potom aplikace, která RSS umí číst (říká se jí čtečka RSS neboli Feed Reader), si poznamená všechny položky seznamu, nabídne jejich seznam uživateli a zvýrazní ty, které nově přibyly a nebo si je ještě nepřečetl. Feed Reader se tedy chová obdobně jako poštovní klient, až na to, že místo do poštovní schránky chodi na URL s RSS Feedem. Po novu se prosazuje ATOM, rozšíření RSS, které kromě vylepšené syntaxe feedů zavádí Atom Publishing Protocol umožňující nejen číst, ale i vytvářet a měnit RSS (Atom) Feedy.

O tom, že systém RSS feedů je RESTová aplikace, snad není pochyb. Distribuce RSS jako u webu (RSS má své URL), přesně definované rozhraní (dokonce i struktura dat), operace jedna jediná - GET, a to buď na RSS feed, stránku nebo její část, bezestavovost komunikace, kešovatelnost, ...

Co má ale společné seznam nových článků na blogu a externalizace (vyvezení ven) dat, Holmesi? To je přeci zřejmé, můj drahý Watsone.

Na blog a jeho články se lze také dívat (a bývá to tak implementováno) jako na relační tabulku, kde jeden řádek databáze odpovídá jednomu článku. Potom vlastně jednotlivé položky RSS feedu nejsou nic jiného než řádky této tabulky nějak převedené na klasické RESTózní zdroje (jeden článek, jedno URL, na němž GET vrací obsah tohoto článku) a ty pak nějak přetransformované do struktury RSS. Odtud je již jen krůček k zobecnění, kdy JAKOUKOLI tabulku, dokonce jakýkoli výsledek SQL dotazu jsme schopni převést do podoby RSS feedu.

A bác ho. Když jsme schopni jakákoli data převést do RSS, můžeme je pak KOMUKOLI na světě v této podobě předat (a navíc mu stačí poslat jenom URLčko a on už vždy bude mít RESTově-aktuální data!) a on si je bude schopen prohlédnou ve svém Feed Readeru.

Navíc můžeme jít ještě dál a říct, že díky pevně dané struktuře RSS lze tato data strojově zpracovat obdobným způsobem, jako by nám je vrátila WebServisa.

Díky transportnímu protokolu HTTP máme ještě k dispozici HTTP-Basic autentizaci a všudypřítomné HTTPS, takže máme bezpečnost dat téměř zadarmo. No není to krása?

Ale svět jde ještě dál. Vznikl nový Buzzword MASHUP. Mashup je stránka či celá webová aplikace vzniknuvší jako syntéza dvou i více webových stránek (aplikací). Typickým příkladem budiž Internetový obchod, který jenom přeprodává zboží jiných Internetových obchodů.

Mashup pak samozřejmě musí nějak získat data od "podřízených" aplikací a rozumět jim. Existují mešupovače (óch, jak je ta na naše řeč bohatá a krásná, že jo, dědo Kovando!), které dokáží vytáhnout data přímo ze stránek, ale nejlépe se pracuje se strojově zpracovatelnými daty, které pro mé potřeby (nebo obecně) někdo zveřejnil, neboli externalizoval. No a nejlépe, pokud tato data mají nějaký rozumný rozšířený formát, kterému rozumí každý. Třeba RSS. A když mashupem je zase RSS, máme tu nádhernou distribuovanou RESTovou aplikaci, ve které máme jediný formát zveřejněných dat - RSS, kde každý si jej může a umí stáhnout, přetransformovat do jiného RSS a to zase zveřejnit...

Na závěr zbývá už jenom jedna otázka. Kolik procent sebere ATOM SOAPu? IMHO není důvod na B2B používat SOAP. Také většina infrastrukturních WebServis jsou stejně jenom donory, dekorátory či akceptory dat, což lze krásně a jednoduše řešit právě ATOMem. A pokud doprostřed celého toho intranetového světa umístíte ATOM repositoř (náhrada za WebDAV), dosáhnete úžasné flexibility.

Sherlock Holmes a poslanec Wolf

Našel jsem nádherný článek Holmes a Watson vyšetřují vydírání o naší demokracii a poslanci Wolfovi. To si prostě musíte přečíst. Nejlepší je Watsonův závěr:

Proč chtějí, u všech všudy, stavět Američané v takové zemi radar?

Mám vůbec koho volit?

Poslední dobou mám čím dál větší problém s tím, koho budu ve volbách volit.

Jakožto bývalý Orchouší Brontík mám hodně blízko k ekologii a tedy zeleným a jejich program mne z velké části oslovuje. Ale jakožto zarytý fyzik a atomista prosazuji stavbu dalších jaderných elektráren na úkor spalování dřeva a obilí. Komunální odpad budiž, ale pěstovat něco jenom na spálení v elektrárně mi přijde přitažené za vlasy. Proto je nemohu volit. A to ani nemluvím o Bů aféře, kdy z nás chtěl pan předseda udělal totální kretény. Kdyby chlapsky řekl, že to psal jí, a že byl večer naštvaný a proto to napsal jak napsal a že se jí omlouvá, v žebříčku popularity by musel hned vyskočit nahoru. Leč...

Jakožto zapřísáhlý antiteista (fanatický ateista) nemohu dát hlas lidovcům už z principu. Navíc jejich "pragmatická" politika "být tam furt" a "my se vždycky domluvíme" je krajně podezřelá. a to nemluvím o čunkiádě.

V principu jsem levicového přesvědčení. Preferuji jistotu před rizikem. Nechci se pořád někam hnát, chci žít. Stresy, které jsme zažili tento rok ohledně mého a manželčina zaměstnání fakt nemám zapotřebí. A to jsou na tom lidé DALEKO hůř. Jenomže demagogie komunistů není můj šálek kávy (snad s výjimkou europoslance Ransdorfa, který to fakt má v hlavě v pořádku). Fandil jsem ČSSD, ale už od dob "odchodu" pana Machovce to tam vypadá tak nějak na levačku. Má oblíbená trojice Špidla, Gross, Buzková totálně zklamala (neschopný politik, všehoschopný politik a neschopná ministryně), pod vedením pánů Paroubka a Ratha se z ČSSD stává stranou strachu. Poslední volitelná tak zbývá strana Zelených, leč viz výše.

Protože jsem chtěl udělat něco pro obec, přijal jsem nabídku kandidovat jako nezávislý za ODS. Velmi se mi líbil pragmatismus některých ministrů, kteří konečně začali dělat rozumné věci a řekl jsem si tedy, že časy Klausiády v této zemi snad skončily. Bohužel ne. Topolánek nevyužil jedinečnou šanci zavrhnout Klause a páně prezidentovo demagogické vystupování mne dohání k šílenství. A to už od doby, kdy nás ekology sledovala BIS... Navíc způsoby, jakými postupují pan ministr Julínek či paní Vesecká, jsou více než zavrženíhodné. A to ani nemluvím o dalších geniálních plánech vlády. Vzpomeňme věk odchodu do důchodu, kterého se nedožiju, smlouvu s církqemi, přístup vlády k neustále sílící koruně, odklady přijetí Eura či jiné antievropské přístupy... Také nesdílím přesvědčení, že neviditelná ruka trhu vyřeší vše.

Kdybychom tak mohli, stejně jak odo senátu, volit lidi. A to lidi formátu pana profesora Zlatušky. Jenomže těch stejně bohužel v republice tolik nemáme.

Takže kdybyste věděli o pragmatické politické straně nevěřící slepě trhu, s výrazným, ale pragmatickým zeleným programem, která nebude zavrhovat jadernou energii, docílí, že sviňárny (co jiného udělala paní Vesecká?) a malé domů (zaměstnávání manželek a známých je naprosto normální, každý byste to taky udělali, i já, ale veřejně krást, jak se to děje v případě Julínkovy reformy (jak jinak vysvětlit, že se jde na ruku zdravotním pojišťovnám a jiným poskytovatelům zdravotnických služeb?)) se prostě v politice nedělají, která bude podporovat důkladnou až federativní integraci EU, která bude podporovat mladé, vzdělanost a tuzemské firmy, bude se umět vypořádat s nelegálním čímkoli, dokáže přimět tuto společnost, že fakt normální je nekrást a nejezdit jak prase, drasticky omezí kuřáky a byrokracii nahradí informační společností, dejte mi vědět.

Jak oRESTovat Javí aplikaci

Dneska ráno jsem našel naprosto zajímavý článek, první ze série o RESTu, který objasňuje REST na příkladu jeho převedení do světa Javy.

První díl vzali autoři z trošku jiného konce - začali od Bindingu neboli vazby mezi klientem a serverem. Vazbu v RESTu definují jako asociaci logického jména na něco "fyzického", třeba kusu kódu, kus paměti či metodu.

Dávají do kontrastu vazbu mezi jménem třídy v Javě (a klasický ClassLoading) proti volné asociaci mezi URLčkem a "stránkou" Webu. Zasmál jsem se nad přirovnáním, že změna implementace třídy (v jejich příkladě java.util.Date) znamená (bez šíleného overheadu s vlastní implementací ClassLoaderu) restart celého JVM, což v případě Webu je věc naprosto komická. No schválně si představte restart celého Webu. Ten synchronizační komunikační protokol bych chtěl vidět... tedy nechtěl...

Takže si řekli, že:
1. Browser se zeptá Domain Name Service (DNS) na "tapikuv.blogspot.com" (v jejich případě www.theserverside.com, ale co bychom si to neupravili, že :-D) a zpět získá IP adresu.
2. Browser vytvoří TCP/IP spojení na onu IP adresu na portu 80.
3. Spojení použije na odeslání HTTP GET requestu na zdroj "/" na tapikuv.blogspot.com.
4. Server dostane HTTP request, něco s ním udělá a vrátí nějakou reprezentaci zdroje "/".
5. Browser ji dostane, něco s ní provede a zobrazí to uživateli.
6. nakonec browser shodí TCP/IP spsojení a "un-binds" (poměrně hodně podstatné slovo, viz níže) od endpointu.

Takže si kluci zavedli vlastní URI schéma "resource" (např. resource:/customers) a navrhli pár tříd:
1. Context (něco mezi JNDI kontextem a proxy)
2. Request (obdoba HTTP requestu)
3. Representaion (obecná třída, ve své podstatě obdoba java.lang.Object)

Celý proces pak probíhá tak, že na kontextu vytvoří request na konkrétní URI, přidají k němu co potřebují, nechají jej provést a zpět dostanou Representation.

Na první pohled nic nového pod sluncem, máme EJB sdílející s klientem jenom mezixicht (miluji toto slovo, které jsem před víc než 20 lety našel ve VTMku), JNDI Context.lookup(), zavolání metody EJBčka a návrat nějaké hodnoty.

Fígl je v tom, že v tomto systému je jenom jeden mezixicht, sdílí jej tedy VŠECHNA EJBčka. To umožňuje dramaticky omezit různá omezení. Klient se tak de jure nestará o evoluci takovýchto EJBček. Stačí mu jenom znát správné URIčko a umět se vypořádat s instancemi Representation.

Sranda je v tom, že výhody tohoto systému nepochopil téměř žádný diskutující. Odvolávky na zahození typovosti v Javě,když ji přece sami autoři používají, že do Javy to vůbec nepatří, že je to přece k ničemu, když ti server vrátí něco, co ty dopředu nevíš, že vrátí, či na to, že to všechno řeší přece CORBA, DCOM a SOAP, jsou velice srandovní. Šlo přece o vysvětlení na příkladu architektonického stylu. Težko přece budeme dělat RESTovou servisu na operátor ++, že...

Na druhou stranu se autoři zapomněli zmínit o jedné podstatné věci, a tou je právě onen "un-bind". Tato operace totiž není v RESTu definována, kde je nahrazena operací "rebind". Chápu, že ona jemná nuance nemusí být pro mnohé čitelná. Hlavní rozdíl je v tom, že ona vazba mezi logickým jménem a "fyzickou" reprezentací má obvykle trvání přesahující jeden request. Teprve když si klient usmyslí, že je načase aktualizovat odkaz, udělá onen "rebind". Kromě kešování bindingu tu navíc máme ještě kešování reprezentací, kdy zase klient rozhoduje, zda je na čase se podívat po aktuální verzi.

No a samozřejmě mám trochu potíž s onou třídou Context. Podle mne je mnohem lepší ji rozdělit na Registry, Repository a Proxy. Registry mi řekne "fyzičtější" odkaz (zde dělám rebind), Repository mi vrátí Proxy (které si kešuji) a na Proxy pak volám requesty. Přijde mi to logičtější a více RESTózní.

Sezóna hub začíná

Tak jsme byli s rodinkou letos poprvé na hřibech. Vyrazili jsme jenom kousek nad barák, ale přinesli jsme dom plný košík. Tady jsou fotky nejlepších úlovků.


Ten nůž je můj velký zálesácký, podnos je velký servírovací, větší než ten nemocniční.

Nový a výstižnější název pro Bulvár

Máme doma na návštěvě Elaphe se svými dvěma dětmi. Hned první noc po příjezdu ale nastal šavlový tanec, neboli Míša pořádně ohodil půlku pokoje, něco skončilo i na čerstvě vylíčené zdi. Ale je to školkáček a navíc asi něco špatného snědl, to se zkrátka stává i v lepších rodinách.
Když jsem to do telefonu popisoval svojí sestřičce, použil jsem pěkný novotvar BlujWare (čti blujvér). A odtud je jenom kousíček k Blujváru (či Blulváru, komu se co lepší líbí). Myslím, že tyto dva novotvary daný termín velmi přesně vystihují. Google Blujvár nezná vůbec, na Blulvár našel dva odkazy na celém Netu. Ale schválně se podívejte, co na blulvár a Blujvár zobrazí Google! To je naprosto přesně vystihující.

PS: Jsem polichocen, že můj blog čtou lidé z marketingu Blesku, Aha! a TV Nova. Ony tyto tři blujváry totiž zorazovaly svou reklamu právě na tyto dvě klíčové slova. A nyní (2008-10-07) už tam nejsou! Mohu si tedy udělat čárku za příspěvek ke kultivaci našeho národa :-)

Ořez textu v MANIFEST.MF

Dnes jsem při hledání příčin jednoho ClassNotFoundException narazil na zajímavou informaci. Jeden každý řádek manifestu nesmí být delší než 72 bajtů (nikoli znaků). Pokud vyvstane nutnost napsat na řádek delší text, je potřeba onen text rozdělit na více řádku po maximálně oněch 72 bajtech, přičemž každý pokračující řádek pak musí začínat právě jednou mezerou.
Pak se nedí co divit, že při dlouhé Class-path vygeneruje IDEA manifest, který třeba obsahuje začátek názvu jaru na konci jednoho a zbytek na začátku druhého.