čtvrtek 11. listopadu 2004

Programátorská hádanka

Dnešní programátorská hádanka je spíše dětským lechtadlem. Mějme následující kód.


	int array [] = new int[10];	
	for(int i = 0; i < array.length; i++){
		.
		.
           }

Na jaký počet příkazů, a to bez použití modula, nejefektivněji naplníte pole, tak aby se pravidelně střídala jednička s nulou tj. ve výsledku 1010101010.

Třívrstvá architektura v kostce I.

Úvod

Ač vědomě či nevědomě se s produkty postavenými podle moderního scénáře business aplikací, též nazývaného třívrstvá architektura, setkáváme na každém kroku. Nevěříte, tak si položte otázky, jestli jste někdy používali online shop, eleketronickou rezervaci hotelu, letenky či ubytování nebo jste využili servis některého zpravodajského portálu. Pokud je vaše odpověď ano, pak jste s pravděpodobností hraničící s jistotou, narazili na třívrstvou, někdy též nazývanou vícevrstvou, architekturu.

Proč tři a ne dvě?

Model třívrstvé architektury je přímou evolucí, z dnešního pohledu již koncepčně zastaralé, dvouvrstvé architektury. Dvouvrstvá architektura vychází z vrstvy klientské a vrstvy datové, jak ukazuje následující obrázek.

Obrázek ukazuje dvě vrstvy, vrstvu klientskou a datovou

Klient obsahuje většinu aplikační logiky, se kterou pracuje přímo nad datovým zdrojem. V mnoha scénářích je zdroj dat reprezentován relační databází a klient využívá jazyk SQL pro práci s daty. Mezi další typy datového zdroje patří soubory a nebo jiné aplikace např. informační systémy.

Nevýhody tohoto modelu se ukázaly při vzrůstající komplexností klientských aplikací. Se složitostí aplikací vzrůstaly výkonové nároky na klientské počítače což byl jeden faktor. Další faktory přímo vyplynuly z masivního rozšíření aplikací, softwárové firmy byly nuceny pružně reagovat na poptávku a tím pádem se snažit operativně plnit přání zákazníků. Z těchto business procesů byly definovány požadavky na budoucí aplikace. Například nutnost sdílení zdrojů, omezení datového přenosu atd., diky kterým se začalo uvažovat o architektuře, která by tyto požadavky pokryla.

Řešení se našlo v podobě přidání třetí - střední vrstvy (middle tier). Samozřejmě se nejednalo pouze o přidání vrstvy, bylo nutno specifikovat jednotlivé vrstvy resp. jejich role v architektuře. Třívrstvou architekturu znázorňuje následující obrázek.

Obrázek ukazuje tři vrstvy, vrstvu klientskou, 

aplikační a datovou

Staronový význam jednotlivých vrstev

S přechodem na třívrstvou architekturu se posunul i význam jednotlivých vrstev, nejmarkantněji se to projevilo u vrstvy klientské. Díky nově definované aplikační vrstvě bylo možné aplikační logiku, která do té doby ležela na klientu, přesunout na aplikační server. Díky tomuto tahu se klientům značně ulevilo neboť veškerý výpočetní výkon byl přesunut na výkonné servery.

Diky přesunutí aplikační logiky na jedno místo bylo možné dosáhnout jejího sdílení a lepší správy a dostupnosti. Aplikační vrstva prezentovaná aplikačním serverem mohl a nabídnout služby v podobě rozložení zátěže (load balancing) či výpadku (fail over). Významnou měrou se podařilo redukovat datový přenos, jehož těžiště se přesunulo na trasu mezi aplikačním serverem a datovým zdrojem. Spojení aplikačního serveru a datového zdroje bylo možno realizovat vhodným přenosovým připojením. Snížení datového přenosu přímo ovlivnilo rychlost odezvy klientů a umožnilo jejich připojení na linkách s omezenou přenosovou rychlostí .

Tenký a Tlustý klient

Takto "očesaní" klienti možná zavdali příčinu k jejich pojmenování na tenké klienty (thin client) . Obecně byla ovšem klientská vrstva definována jako vrstva, která je určena pouze k prezentaci dat uživateli. Tenký klient je proto takový klient, který neobsahuje žádnou aplikační logiku. Aplikační logiku mu zprostředkuje aplikační server, ke kterému tenký klient přistupuje. Naopak tlustý klient, v dvouvrstvém modelu pouze klient, obsahuje většinu aplikační logiky. Ve skutečnosti i tenký klient musí nějakou aplikační logiku obsahovat, ale oproti tlustému klientu je to naprosto zanedbatelná část.

A co webový prohlížeč?

Webový prohlížeč, v rámci předchozí definice, spadá do skupiny tenkého klienta. Já osobně rozlišuji mezi prohlížečem a tenkým klientem. Prohlížeč postavený na standardech webu používá pro popis grafického uživatelského rozhraní (GUI) jazyk HTML a CSS. Jazyk HTML v kombinaci s CSS nenabízí takové možnosti oproti tenkým klientům, aby bylo možné popsat složitější rozhraní. Další nevýhodou prohlížeče je svázání s modelem žádost/odpověď (request/response) nastaveným HTTP protokolem.

Tyto odlišnosti mě vedou k rozlišování pojmu webový prohlížeč a tenký klient v kontextu třívrstvé architektury. Mezi častý omyl patří rozlišování tenkých a tlustých klientů podle toho jestli se jedná o webový prohlížeč. K tomuto bych rád podotknul, že klíčovým faktorem není to jestli se jedná ve výsledku o prohlížeč či nikoliv, ale rozložení aplikační logiky.

Datová vrstva

U datové vrstvy též nazývané backend nedošlo v třívrstvém modelu k žádnému posunu. Tato vrstva slouží jako datová základna a lhostejno jestli je v pozadí relační databáze, souborový systém, webová služba či jiná aplikace.

Aplikační vrstva

Jak již bylo vzpomenuto o pár odstavců výše, aplikační vrstva v podstatě tvoří skořápku pro aplikační logiku. Tato vrstva resp. aplikační logika zajišťuje přístup k datům, práci s daty a z jejich vystavení ve vhodném formátu (XML, HTML) pro klient vrstvu. Z pohledů doby zaznamenala aplikační vrstva právě nejbouřlivější vývoj. Jako nejjednodušší realizaci aplikační vrstvy můžeme považovat webový server s CGI rozhraním, jehož pomocí se volaly výkone rutiny prezentované spustitelnými soubory a později serverovými skripty.

Komplexnost aplikační vrstvy vedla k jejímu dalšímu rozdělení na vrstvy. Toto rozčlenění pomohlo definovat odpovědnosti jednotlivých vrstev v rámci aplikační vrstvy. Vrstvy jsou definovány jako prezentační (presentation), aplikační (business) a datová (persistence). Na pomezí těchto vrstev leží například MVC (Model View Controller), ORM atd., ale o tom v příštím díle. Samozřejmě pokud bude zájem.

úterý 9. listopadu 2004

Proč trpíme za standardní dialogy lokalizovaných Windows aneb to snad nemyslíte vážně pane úředníku

Vždycky když slyším nějakou povedenou historku o uživatelích, tak připočtu nějaké to procento vtipnosti na vrub vypravěče. To bych neměl dělat! Dneska jsme obdrželi oficiální připomínky k webové aplikaci. Součástí aplikace je stažení souboru s výsledky, dialog pro stažení samozřejmě obhospodařuje internetový prohlížeč.

Když jsem četl připomínky k těmto dialogovým oknům tak jsem nevěřil vlastním očím, no posuďte sami (přikládám autentické obrázky včetně komentáře). Zdroj jsem z etických důvodů zamazal.

1.Vložit mezeru mezi slovy „Přenosová rychlost:“ a veličinou přenosové rychlosti:

2.Opravit chybu ve větě: „Před otevřením souboru thoto typu vždy zobrazit tento dotaz“.

Nejdříve mě to velice pobavilo a říkal jsem si o uživateli, no jak to říci kulantně, prostě něco o jeho inteligenci. Pak mě napadlo, že uživatel vůbec netuší nic o architektuře aplikace a tudíž nemůže vědět, že tyto hlášky padají na vrub lokalizovaným Windows resp. Internet Exploreru. Kdyby záleželo na mě, odkázal bych onoho připomínkovače nejdříve na jednu tiskovou zprávu a potom přímo na Microsoft.

neděle 7. listopadu 2004

Více konfigurátorem než programátorem

Pokud jste se dostali do křížku s nějakou novou technologií, byli jste s velkou pravděpodobností vystaveni nějaké formě konfigurace. Nikoho asi nepřekvapí, že pro konfiguraci se široce zakořenilo XML. XML má pro tento účel plno výhod, z těch základních namátkou, kontrola validity, snadná editace, lidsky čitelná forma.

Většina javovských produktů si vzala výhody xml konfigurace k srdci a tak málokdy narazíte na jinou formu. V tomto směru existují tři váhové kategorie co do rozsahu konfigurace. Do první kategorie, kterou označuji za muší váha, patří rádoby jednoduché utilitky s konfigurací do 30 řádků např. Log4J (framework pro logování) nebo Proxool (database connection pool).

Druhou kategorii, střední váha, tvoří konfigurace do 250 řádků. Mezi klasické zástupce patří servlet konfigurace resp. konfigurace webové aplikace. Do této rodiny patří i konfigurace, v uvozovkách jednodušších nástrojů, jako je Tomcat nebo Jetty (HTTP server a Servlet kontejner).

Třetí kategorii, bez váhové omezení, tvoří takové nástroje, kde konfigurace musí být rozdělena do více souboru, aby byla vůbec nějakým rozumným způsobem udržitelná. Jedná se například o Model-View-Controller frameworky (Struts), IoC kontejnery (Spring, Pico) apod.

Určitě si každý dokáže dosadit do těchto třech kategorií dosadit i produkty, které konfiguroval na vlastní kůži. Samozřejmě ne vždy mnou uvedení zástupci spadají do té či oné kategorie, mohu se pohybovat oběma směry,záleží na rozsahu projektu.

Dalším důležitým faktorem je kumulace jednotlivých konfigurací. Pro webovou aplikace budete potřebovat minimálně servlet a pak MVC konfiguraci. Vaše webová aplikace potřebuje logovat a protože spolupracuje s databází potřebuje i connection pool. Suma sumárum minimálně čtyři konfigurační soubory.

Absolutní extrém tvoří například IoC kontejner Spring, kde konfigurací spojujete jednotlivé vrstvy aplikace. Mezi ty další bych zařadil například konfiguraci deploy adresáře J2EE serveru JBoss, ostatně EJB je v tomto taktéž extrémem. Když to přeženu, jeden aby se ze všech těch konfigurací zbláznil, angličtina má pro to výstižný výraz Metadata hell.

XML konfigurace má z aplikačního hlediska obrovskou výhodu v tom, že vás nenutí svazovat, pěkně česky zadrátovat, jednotlivé komponenty systému na úrovni kódu. Dnes existuje velké množství nástrojů jako Ant či XDoclet, které mohou být velice nápomocny a konfigurační práci usnadnit.

Pokud zvážím všechna pro a proti, tak z mého pohledu se jeví výhodnější přístup pomocí XML konfigurací a to i za cenu, že jsem někdy více konfigurátorem než programátorem.