{

}

… neboli složené závorky. S Tomuchou v MA jsme jim říkali “fousaté”, Jakub Podlesak je v osmnáctém Java podcastu nazývá “kudrnatými”

Jak jim říkáte vy?

… řekne nadšeně nejeden programátor, kdykoli to dává aspoň trochu smysl. A výsledkem je aplikace s šíleným konfiguračním souborem, jehož formát se dle potřeby vývojářů obměňuje každý release.

Řešení je prosté, konzistentní s pravidlem Don’t improve things you’re not asked to (zdravím pana evangelizátora) i se spoustou jiných: strčte si svou konfiguraci někam, kam slunce nesvítí a uživatel nevidí a v oficiální konfiguraci aplikace nechte jen pár pro uživatele podstatných možností. Ideálně v podobě, která dává smysl především uživateli a kterou příslušný kód přeloží do řeči interních komponent.

Zní to docela samozřejmě, že?

Podle článku Google App Engine Announces Pricing Plan, APIs, Open Access na ReadWriteWeb se očekává, že Google dnes na Google I/O konferenci oznámí několik novinek ohledně AppEngine (viz též starší zmínka na Jabloku):

Služba bude v základní bezplatné verzi přístupná všem zájemcům bez čekání (rozdíl oproti současnému uzavřenému byť zvolná narůstajícímu okruhu testerů).

Limity základní verze zůstavají na 500 MB persistentně uložených dat a přenosové kapacitě specifikované jako “dostatečná pro 5 milionů pageviews měsíčně”. Do konce roku se objeví možnost přikoupit dodatečné zdroje, ReadWriteWeb uvádí následující předběžný ceník:

• $0.10 - $0.12 per CPU core-hour
• $0.15 - $0.18 per GB-month of storage
• $0.11 - $0.13 per GB outgoing bandwidth
• $0.09 - $0.11 per GB incoming bandwidth

Zmínka o placení za CPU mi není příliš jasná vzhledem k tomu, že základní verze žádné omezení vlastní výpočetní kapacity nezmiňuje. Uvidíme.

Posledním zajímavým rozšířením jsou dvě nová API - pro manipulaci s obrázky a především - pro kešování (absence kešování byla vzhledem k přirozeným omezením odezvy distribuované databáze nepříjemná).

Jinak celý tento článek je pro Javisty off-topic, jiné jazyky než Python zatím Google v AppEngine podporovat nehodlá

V příspěvcích o eBay a AppEngine jsem zmiňoval, že používání HTTP sessions nejde úplně dobře dohromady s požadavky na horizontální škálovatelnost.

Používat sessions je lákavé, umožňují programátora odstínit od bezstavovosti HTTP protokolu. Na druhou stranu, jakmile aplikace přeroste možnosti jednoho stroje, tak začnou komplikovat život, když chcete provozovat load balancing přes cluster aplikačních serverů: duplikovat je napříč servery je patrný overhead, sticky sessions neméně zjevně snižují efektivitu load balanceru.

Jinými slovy: odstiňovat programátory od bezstavovosti HTTP vlastně nemusí být až tak dobrý nápad.

Nejmenší zlo je nakonec sessions ukládat do nějakého relativně persistentního úložiště vně aplikačního serveru - zpoždění sítě a potřebné serializace a deserializace sice mírně brzdí, ale aspoň neovlivňují zbytek clusteru.

Tedy, nejmenší zlo za předpokladu, že sessions používáme.

K čemu vůbec sessions?

K čemu se vlastně HTTP sessions používají? Napadá mě:

• udržování identity uživatele + kešování osobních dat
• udržování stavu uživatelského rozhraní (JSF, dívám se vaším směrem…)
• nákupní košík
• kešování informací potřebných pro stránkování dat (opravdu to někdo radí)
• a další - příklady uvítám v komentářích

Pokud mne laskaví čtenáři v komentářích nedoplní něčím nečekaným, dalo by se používání sessions rozdělit do následujících částečně se překrývajících kategorií:

• autentifikace
• kešování
• antipatterny

Antipatterny

Nevýhody používání sessions pro ukládání aktuální pozice při stránkování dat pitvali už před necelými deseti lety členové Usenetové skupiny cz.net.internet (a po nich i před nimi jistě spousta dalších).

Z nějakých záhadných důvodů se jako typický důvod pro sessions uvádí nákupní košík. K tomu mě nenapadá jiný důvod než že jej kdysi kdosi použil v nějakém tutorialu na sessions a od té doby to každý papouškuje: košík by měl být odolný proti výpadku aplikačního serveru, navíc se neaktualizuje ani nezobrazuje tak často, aby musel být nutně kešován - zkrátka i když jeho trvání obvykle nebývá dlouhé, je velmi záhodne jej ukládat do databáze.

Jako antipattern mi osobně přijde i přístup JSF - a to ať už se stav stromu komponent ukládá do session nebo na klientovi. Ale vzhledem k popularitě tohoto frameworku mi asi něco uniká. Doufám.

Kešování

Session může působit dojmem jako bezva struktura pro kešování, aspoň dokud si člověk neuvědomí nevýhody popsané více. A dokud nezačne kešovat data, která mohou být modifikovány v rámci jiných sessions. A když si nevýhody uvědomí, tak nejspíš sáhne po něčem, co bylo pro kešování navrženo a uvedenými nedostatky ve škálovatelnosti netrpí. Třeba memcached. A těch pár zlomků sekundy na zpoždění sítě a (de)serializaci holt obětuje.

Autentifikace

Session se asi nejčastěji používá pro udržování informací o přihlášeném uživateli. Fakticky se ale jedná o speciální případ kešování popsaného níže - pokud víme, že o uživateli potřebujeme znát skutečné jméno, adresu, a základní preference, prostě si je můžeme nasypat do memcached pod těžkouhodnutelným klíčem generovaným podobným mechanismem jako session.

A pokud od autentifikace očekáváme jen ověření identity uživatele, můžeme prostě do cookie nastavit přímo identifikátor uživatele, jen digitálně podepsaný nebo ještě lépe zašifrovaný. Pokud autentifikační služba není izolována na vlastním clusteru, symetrické šifrování by mělo bohatě postačí. Na druhou stranu se v tomto případě se musíme postarat o pár praktických záležitostí okolo správy klíčů a deploymentu.

Obrázek: Možnosti ověření a interpretace authentication tokenu - kešování a kryptografie

Kryptohrátky jsou zbytečným overheadem v tradični aplikaci, kdy většina požadavků je zasílána za účelem vykreslení celé stránky - typicky vždy budete muset znovu zobrazit jméno uživatele a podobně, tudíž si hrábnutí do cache neušetříte.

Naopak pokud si mantru “udržovat stavu na klientovi” vykládáte po vzoru GMailu tak, že webová aplikace se sestává z pár HTML stránek, kterou uživatel porůznu aktualizuje AJAXem, pak samozřejmě může kryptografické ověřování a interpretace session tokenu přispět ještě o trošku k lepší odezvě a škálovatelnosti.

Pokud někomu ze čtenářů zbudou síly něco napsat, zajímalo by mě:

• k čemu výše neuvedenému používáte sessions?
• zkoušeli jste v praxi vytvořit bez použití sessions netriviální víceuživatelskou webovou aplikaci?
• a pro znalce a fanoušky Java Server Faces - máte po přečtení výše uvedeného dojem, že mi ohledně této technologie něco zásadního uniká?

Odkazy

• Gojko Adzic: Put the webserver on diet to increase scalability
• Cal Henderson: Scalable web architectures: Common patterns & approaches

Před pár dny Google na svém blogu oznámil spuštění automatického překladače mezi češtinou a opravdu velkou spoustou jazyků.

Takže pokud vás zajímá, co se tak zrovna zajímavého děje v Číně aniž byste disponovali patřičnými jazykovými znalostmi, můžete s trochou fantazie sledovat český překlad čínských Google News. Uznávám, že zpráva Andy Lau Shi Zhu Liqian vztahy s měkkou sílu postupně nejistý dotýkající se patrně čínské pop-kultury už vyznívá trochu surrealisticky, na druhou stranu na podobné výplody je patrně zvyklý mnohý uživatel dosavadních automatických překladačů mezi češtinou a angličtinou.

Teď ještě, aby to umělo překládat i feedy.

Mimochodem, japonština se i podle úrovně překladu zdá být znatelně jednodušším jazykem.

… se jmenuje článek od Joela Spolskeho, kde autor vysvětluje základní myšlenku Map/Reduce (tedy převést problém na paralelizovatelné zpracovávání seznamů) na JavaScriptu.

Lispu neznaje, první odpověď, která mě na otázku v nadpisu napadla, byla: no jo, perl

Javu samotnou hanět nezačnu ani náhodou, nicméně na Joelově stížnosti na “Java-only” vzdělávání něco bude.

… volal s nakažlivým úsměvem ve vestibulu metra Flora chlapík v oblečku prodejce Nového Prostoru. Zářil dobrou náladou a svým sloganem rozptyloval pochyby potenciálních zákazníků. Úspěšně, aspoň co mohu soudit podle sebe a té paní, co si za mě stoupla do fronty.

Velký školitel

V pravidelných zprávách z LinkedIn jsem potkal následující doporučení na pana Martina Janků:

“We hired Martin as someone who has to teach our non-IT employees to became top IT experts interviewing IT professionals and i must say he has done excellent JOB - everyone understands now what f.e. not only CISCO is…”

Říkam “wow”.

Nejsou lidi?

Roste vám firma a nestiháte nabírat? Stávají se z vašich obchodníků či project managerů vyhořelí mrzouti a nemáte, kde nabrat novou krev?

Snadná pomoc. Prostě si najměte pana Janků, a zajeďte spolu na Floru.

Jak to vypadá, když se za pomocí J2EE vytváří webová aplikace, jejíž databáze obsahuje přes dva petabajty dat (peta = 1024⁵) a jejíž dvě stě milionů registrovaných uživatelů jejím prostřednictvím v kterýkoli čas nabízí okolo sta miliónů položek?

Architektura eBay

• na nejhrubší úrovni rozděleno na databázovou vrstvu, aplikační vstvu, vyhledávací systém a operations
• Aplikační vrstva:
  • nedrží stav (tedy žádné sessions, natož stateful session beans)
    • schválně jsem se podíval na HTTP hlavičky, zaujala mě cookie jménem “nonsession”
  • asi 100 funkčních celků, v terminologii eBay “apps” (někdo by možná řekl “business services”), dohromady to dělá cca 15,000 serverů
  • aplikační servery spolu nekomunikují, běží nezávisle na sobě (což lze snadno díky předchozímu bodu)
• Databázová vrstva:
  • rozdělena vertikálně na něco přes 70 funkčních celků (databází). Ty jsou dále řezány horizontálně podle hlavního klíče pro daný logický celek
  • většina náročných obvykle databázových operací se provádí na aplikační vrstvě; zmiňují se joiny, kontrola referenční integrity, třídění. Nepěstují se žádné uložené procedury (sem tam nějaký jednoduchý trigger)
  • eBay nepoužívá transakce (tedy kromě PayPalu, který pod eBay taky patří)
  • v praxi to znamená, že je vymezena skupina životně důležitých dat, které musí být vždy v konzistentním stavu, u ostatních se garantuje pouze “best effort”

Kdy se hodí Java?

Zajímavé jsou použité technologie: J2EE (konkrétně WebSphere) a Oracle, čímž se eBay výraně odlišuje od různých Flickrů a podobné havěti. Co mají ale tyto weby s eBay společné, jsou architektonické patterny, které se na hony vzdalují představě správné J2EE aplikace z dob EJB2.0. Ale na tom samozřejmě není nic divného.

Proč tedy v eBay Javu vůbec používají?

Dan Pritchett ve své prezentaci z roku 2006 píše: “[we] rewrote the entire application in J2EE … which gave us chance to architect the code for reuse and separation of duties”. A co si tak vzpomínám, to byl možná hlavní důvod, proč jsem se kdysi dávno po nějakých pěti letech s Perlem a PHP pouštěl do psaní webových aplikací v Javě.

Odkazy

• InfoQ Interview: Dan Pritchett on Architecture at eBay
• Dan Pritchett: The eBay Architecture (PDF, prezentace z SD Fora 2006)
• eBay Architecture at HighScalability.com
• Nati Shalom: Why most large-scale Web sites are not written in Java

I pokud vás žádné gridy a podobné moderní výmysly vůbec nezajímají, na GridGain se podívejte aspoň pro příklad, jak taky může vypadat JavaDoc-em generovaná dokumentace API:

.

“Start Here” anotace, prolinkování s Wiki a fóry, jednotná struktura popisků tříd. Vlastně žádná věda. Ale potěší.

Samozřejmě předevšim buzzword, jehož význam se oproti “dvojkové” verzi zatím neusadil. Osobně jsem se s ním poprvé setkal v nějakém rozhovoru s Novou Spivackem von Twine.

Příručka “jak blafovat o webu 3.0″ se dosud na pulty knihkupectví nedostala. Milovníkům buzzwordů určitě aspoň trochu pomůže článek Web 3.0 - The Semantic, Implicit, Mobile or Distributed Web?, ve kterém Jonas Bolinder sesumíroval přehled toho, co kdy kdo zajímavý za “web 3.0″ označil.