Architektura podřízená modelu

Modelem zde rozumím jádro is, jeho část, která určuje jaká data se mají zpracovávat, jaké jsou závislosti mezi daty, typově jaké výstupy by měly být generovány ap. Není to tedy pouze datový model, ale i aplikační logika. A také to není pouhý návrh, ale i příslušná implementace. V příloze B – „Proces vývoje aplikace“ uvidíme, že dělící čára mezi těmito způsoby chápání modelu je čím dál tím méně zřetelná. V této příloze se také trochu dotkneme některých prostředků k dosažení dobrého vnitřního návrhu modelu, ale ani tam se nebudu zabývat vlastním modelováním - k tomuto tématu se dočtete jinde 2 – „Model“.

Platforma je vše, na čem aplikace poběží. Řadím sem veškeré technické vybavení, které je nutné k provozu operačního systému a is (hardware), operační systém a další low-level software, například síťový. Blíže viz 3 – „Platforma“.

Pod pojem infrastruktura patří:

Blíže viz 4 – „Infrastruktura“.

Takové (téměř jistě softwarové) vybavení, které dokáže datům dodat trvalosti (perzistence). Nejběžnější implementací úložiště je nějaká forma databázového systému. Blíže viz 5 – „Úložiště“.

Jsou to rozličné kanály z a do aplikace, které nemůžeme označit jako uživatelské rozhraní a ani jako kanál k úložišti - zahrnuje rozličné:

Blíže viz 6 – „Neinteraktivní rozhraní“.

Zastřešuje vše, co z fungujícího is „vidí“ většina užvatelů - nejčastěji konkrétní programové obrazovky pro zadávání dat, ovládání, správu... Blíže viz 7 – „Uživatelské rozhraní“.

Stručně jsme vymezili, které oblasti nás zajímají. Pokud vašemu systému některá část chybí (například nepotřebujete komunikovat s uživateli), nezoufejte - jednoduše ji v dokumentu přeskočte. Pokud vás například zajímá pouze jak vyřešit ukládání dat, po dočtení této úvodní kapitoly můžete přímo přejít k „Úložišti“. Pokud naopak nějakou část v obrázku marně hledáte, pak

Ovšem věřím, že i v takovém případě zde naleznete něco užitečného.

V této části se pokouším shrnout běžné přístupy k jednotlivým doménám. Pokud je hodnotím, zkoumám je samostatně nebo ve vzájemném srovnání, ale neposuzuji je ve vztahu k ASM. K tomu bude prostor dále. Pouze u problémů, které to dle mého posouzení vyžadovaly, jsem se pustil do trochu větší šíře, ale nikdy příliš do hloubky.

V této části se pokouším specifikovat dle mého názoru principiální problémy běžných řešení.

V takto nazvané části můžete hledat odpověď na otázku: Jak by to tedy být mělo? Základní myšlenkou ASM je „princip obalu“, který můžeme shrnout asi takto: Klíčový je model - vše ostatní je obal. Tak snadno, jako můžeme zabalit například boty, tak snadno bychom měli být schopni „obalit“ model aplikace. Tak snadno, jako přehodíme boty do jiné krabice a krabici vložíme do nákupní tašky, bychom měli být schopni měnit části architekturálního obalu aplikací. Jakých okamžitých i odvozených přínosů uplatněním této zásady v celé aplikaci dosáhnete, můžete sledovat na obrázku:

Obrázek 2. Výsledky uplatnění principu obalu

Žlutě jsou zachyceny primární cíle ASM (výsledky uplatnění klíčového principu), tedy:

V modrých kolečkách jsou příklady druhotných přínosů, tedy snadná údržba, robustnost, trvalá hodnota, vpřed postupující vývoj, znovupoužitelnost. U každé popisované části is zkusím formulovat požadavek ASM, tedy stručný souhrn vlastností, které aplikace vytvořená dle ASM musí či nesmí mít a vlastností, které by měla, případně neměla obsahovat, aby byla vytvořena v souladu s principem obalu a výše uvedených cílů mohla dosáhnout. Aplikace která tyto požadavky splní, může být označena jako „aplikace s architekturou podřízenou modelu“ nebo zkráceně ASM aplikace.

Nejlepší kritika je taková, která nabízí alternativu či řešení. U problémů, které dle mého posouzení nevyžadují další zkoumání, je přímo uvedeno co použít a proč to doporučuji. Tam, kde jsou konkrétní možnosti řešení nejednoznačné či neznámé, je provedeno stručné porovnání možných řešení (které již vyhovují ASM požadavkům) a pokud je to možné, některé z nich na závěr doporučeno.

Není vhodné svázat systém s uzavřeným proprietárním řešením, u kterého konec podpory ze strany výrobce znamená skutečně definitivní konec podpory. Kde je to možné, jsou proto upřednostněna open-source řešení.

Tzv. relační model je charakteristický tím, že veškerá logika systému je vyjádřitelná vztahem mezi daty. Procesy, které nad těmito daty pracují, mají sloužit pouze k vytěžení, uložení a změně těchto dat a občas provést nějaké složitější operace nad těmito daty. Pro zachycení vztahu mezi daty slouží tzv. ERD diagram. Dvě a více tabulek se mezi sebou provazují pomocí klíčů (existuje několik typů vazeb). Důležité však je, že znalost ERD diagramu systému znamená znalost 90 % informací o systému. [zoop, str.40]

Důležité na způsobu programování, označovaném jako strukturální je to, že pokud hovoříme o činnosti v programu, máme tím na mysli nějakou funkci, resp. proceduru, v systému vytvořenou, kterou můžeme volat se vstupními parametry a získat výstupní parametry. Celý tok programu je vyjádřitelný právě pomocí takovýchto funkcí a tok činnosti je dán jejich složením- tedy strukturou funkcí a procedur - odtud název strukturální programování. Takový program neobsahuje žádné objekty ve smyslu jak jsou popsány níže. [zoop, str.19]

Obrázek 4. Příklad strukturálního přístupu s relačním modelem

Z hlediska oddělenosti dat od operací by do této kategorie patřil rovněž model založený na XML, jehož základním stavebním kamenem nejsou tabulky, ale spíše strom.

Objekt je uzavřená struktura v programu, která splňuje určité charakteristiky. V první řadě obsahuje vnitřní paměť - ta je zvnějšku objektu nepřístupná. Je jeho soukromou záležitostí, co si objekt pamatuje a jak. Součástí vnitřní paměti mohou být další objekty. Objekt dále obsahuje metody, posloupnosti kódu programu, které vykonávají nějakou činnost nad vnitřní pamětí objektu (a ideálně pouze nad ní). Můžeme si představit, že metoda objektu je jedinou možností jak zpracovat vnitřní paměť objektu. [zoop, str.10]

Obrázek 5. Charakter objektu

Takto vypadá výše uvedený příklad převedený do podoby, jak jej zachytí objektový model:

Obrázek 6. Přístup objektového modelu

Již zavedení strukturálního programování bylo pokrokem oproti předešlému přístupu „řádkového“ programování složeného ze samých odskoků GO TO na návěští. Již při strukturálním programování se objevují určité prvky zapouzdření a to zapouzdření samotných funkcí a procedur při jejich skládání a při jejich strukturovanosti. Z procedurálního kódu je možné sestavovat bohaté knihovny. U strukturálního programování je výhodou, že je možné vnitřní funkci (která skládá vnější funkci) vyměnit, resp. opravit, a vnější složená funkce toto nepocítí. Když tedy voláme vnější funkci, potom nás nezajímá, jak je vnitřně strukturovaná. A právě v tomto ohledu lze hovořit o určité uzavřenosti nebo zapouzdření složených procesů, ale nikoliv o uzavřenosti nebo zapouzdření dat-proměnných. [zoop, str.19] Strukturální přístup selhává při potřebě dodatečných dramatických zásahů do systému. Ty nemusí být potřeba jen z důvodu chyb při úvodní analýze, ale mohou si je vynutit i skutečnosti, které vejdou ve známost až při přirozeném vývoji systému a nelze je na začátku předvídat. Za problém lze tedy potom obecně označit stupeň flexibility, který je dán tomu kterému modelu. Pokud jsou totiž objeveny chyby anebo nastane výše uvedená žádost o změnu systému a tento není napsán flexibilně, potom je vše ostatní už jedno, protože není co a hlavně není jak opravovat. Zkušenosti potvrzují, že pokud se jedná o jen trochu složitější systém, tak představa, že na základě „jedné analýzy“ navrhnu „jeden dobrý systém“, je nereálná. Na prvním místě musí být flexibilita a až potom bezchybnost návrhu. [zoop, str.39]

Kde je příčina problému strukturovaného programování? Abychom na tuto otázku mohli odpovědět, musíme si uvědomit, že celá složitost úkolů, které jste schopni vyřešit je přímo úměrná druhu a kvalitě abstrakce. Pod „druhem“ si lze představit větu: „Co vlastně zobecňujete?“ Assembler je malou abstrakcí podkladového počítače. Celá řada procedurálních jazyků, jež se objevily posléze je abstrakcí assembleru. Všechny tyto jazyky jsou jeho zdokonalením, ale jejich primární abstrakce i nadále od programátora vyžaduje, aby spíše než v souvislostech úkolu, který se snaží vyřešit, uvažoval v souvislostech uspořádání počítače. Programátor musí nastavit asociaci mezi modelem určitého stroje a modelem úkolu, který si žádá vyřešení. K tomuto mapování je třeba vyvinout značné úsilí a vznikající programy jsou velmi složité a jejich údržba velmi náročná.. [myslime, str.39]

Datový model navržený pomocí metodologie zvené strukturální analýza má několik nesporných výhod. Například:

Ovšem systémy založené na relačním modelu trpí podobnou chybou jako strukturální programování: Zásahy v modelu značně ovlivní program a znesnadňují tak údržbu a vývoj celé aplikace. Co se stane, když máme bohatou košatou databázi a v jedné tabulce změním jednu definici sloupce, anebo dokonce když změním na základě změny požadavků celou vazbu? Co když požadavky na systém natolik narostou, že počty tabulek začínají přerůstat rozumnou mez a jdou do počtu až několika stovek a poté provedu změnu v několika z nich? Je to jednoduché - procesy začnou „padat“. Systém se stane neudržitelným a jakýkoliv zásah do něj způsobí neustálé problémy pracovníkům z jiných částí týmu, kteří nic netuší a všichni se jenom rozčilují, proč databáze najednou nefunguje. Navíc, a to je horší, nelze mnohdy ani určit, kterých procesů se změny dotknou. Musíte, ať už s podporou programovacího prostředku anebo čistě ručně, projít všechny příkazy SQL databáze, které tabulky, vazby atd. používají, a měnit, měnit, měnit... A protože máte vytvořit systém dost složitý, zákonitě se dostane do kruhu - oprava jedné skupiny tabulek s sebou přináší další opravy jiných tabulek a procesů atd. a systém se stane krajně nestabilním. [zoop, str.41-42] A proč to všechno nastane? Může za to „výhoda veřejnosti“- procesy počítají s datovou strukturou tabulek, kterou jste publikovali všem.

U větších projektů hrozí podobné nebezpečí jako u relačních modelů, způsobené přílišnou veřejností dat i jejich schémat.

Objektový model sám o sobě v drtivé většině případů chybou není. Chyby ovšem mohou vzniknout ve vývojovém procesu. Zdrojů k UML (modelovací jazyk pro objektové modely), k modelování a i k vývojovému procesu obecně je poměrně mnoho a detaily v tomto směru nejsou předmětem zájmu tohoto dokumentu, ale přesto - něco málo zejména k trendům v této oblasti se možná dozvíte v B – „Proces vývoje aplikace“.

Je potřeba zvolit model, který má dostatečné vyjadřovací schopnosti a tak umožní vytvoření flexibilní aplikace.

Pravděpodobně je nepoužijete pro vytvoření celé aplikace, ale mohou dobře posloužit v oblastech umělé inteligence, tedy tam, kde klasické procedurální jazyky nestačí. Mluvím o oblastech jako dolování informací , rozpoznávání tvarů , práce s lidskou řečí , zpracovávání nejasných a neúplných údajů - to všechno může být součástí obchodní aplikace.

ASM aplikace by měla fungovat na kterékoliv platformě. Změnou hardwaru či operačního systému kteréhokoliv z počítačů by funkčnost aplikace měla zůstat nedotčena.

Nejdelší historii mají jazyky kompilované. Jejich výhodou je rychlost výsledných programů - relativně časově náročná kompilace ze zdrojového do nativního kódu, kterému rozumí přímo operační systém proběhne pouze jednou, při běhu se pouze spustí - na obrázcích jsem to znázornil překrývajícími se ovály.

Obrázek 9. Proces vytvoření a spuštění kompilovaného programu

Výsledný program je nativní, tedy nutně nepřenositelný. Řešením by mohlo být (a bývá) použití specifických kompilátorů - a skutečně, kompilátory například jazyka C++ jsou dostupné prakticky pro všechny běžné platformy. V čem je tedy problém, když pomineme „drobnost“, že chcete-li distribuovat aplikaci použitelnou řekněme na 3 platformách, musíte ji pro každou zvlášt kompilovat?

Zejména v knihovnách, které vaše aplikace použije, protože ty musí být také k dispozici pro každou podporovanou platformu. A dokonce ani mnohé standardní knihovny například již zmíněného jazyka C++ se nechovají všude stejně. Z těchto důvodů je zajištění přenositelnosti buď nepříjemné, nebo hodně nepříjemné, nebo (a bohužel velice často) nemožné.

Proto: Vyvarujte se kompilovaných jazyků pokud můžete!

O něco novější jazyky interpretované přinášejí zásadní změnu - vlastní kompilace probíhá až při spuštění programu a nazývá se interpretace. Do této skupiny patří LISP, Scheme, Prolog, ale i většina jazyků označovaných jako skriptovací jazyky, tedy PHP, Perl, Python, Tcl, JavaScript.

Obrázek 10. Proces vytvoření a spuštění interpretovaného programu

Z hlediska přenositelnosti je to dobré řešení - stačí aby existoval interpret pro každou platformu, která má být podporována. Pokud použijete výhradně přenositelné knihovny (např. v tom samém jazyce), je vše v pořádku. Nebezpečí se skrývá ve schopnosti využívat knihoven neinterpretovaných (a tedy nepřenositelných) jazyků, která je vlastní mnoha interpretovaným jazykům. Použijete-li nativní knihovnu, přenositelnost se rázem zboří. Před volbou interpretovaného jazyka proto prověřte, zda jsou k dispozici přenositelné knihovny ke všemu, co budete využívat.

Nevýhody jsou dvě: Dáváte veřejně k dispozici svůj zdrojový kód, což je chválihodné, ale možná o to nemáte zájem. A dále, program je pomalý - časově náročná kompilace se provádí při každém spuštění.

Jazyky interpretované s bytekompilací jsou další generací jazyků interpretovaných. Rozdělují proces kompilace do dvou fází. Bytekompilátor převede zdrojový kód do tzv. bytekódu, což je operace časově srovnatelná s kompilací do nativní podoby, ale bytekód je platformně nezávislý . Interpretr bytekódu je již nutně platformně závislý, a proto musí existovat pro každou podporovanou platformu.

Obrázek 11. Proces vytvoření a spuštění bytekompilovaného programu

Z hlediska přenositelnosti je to řešení stejně dobré, jako čistá interpretace. Navíc přináší výhodu v podobě vyšší rychlosti běžících aplikací a odpadá nutnost zveřejnit zdrojový kód. Ovšem i zde musíte dbát na to, že využijete pouze přenositelné knihovny. Věřím, že cesta vede právě tudy. Otázkou je, který jazyk konkrétně je nejvhodnější? Odpověď nemůže být naprosto jednoznačná - protože záleží na konkrétních parametrech aplikace. Ale myslím si, že zejména na poli procedurálních objektově orientovaných jazyků je natolik „čisto“, že se poměrně jednoznačný závěr dá učinit.

Hledaný jazyk musí být široce rozšířený, široce podporovaný, dostupné nástroje musí být schopny zajistit vše potřebné bez pevné vazby na cokoliv nativního. Co třeba Smalltalk? Je dobře navržený, výkonný, čistě objektově orientovaný, interpretovaný s bytekompilací, interprety existují pro mnoho platforem... Ovšem trpí právě nedostatkem kvalitních, dostupných knihoven a tento hendikep řeší možností využívat nativní knihovny C a dalších jazyků.

Řešením je Java . Možná má ve srovnání se Smalltalkem nějaké drobné chyby v základní specifikaci, možná trvá o něco déle naučit se s ní pracovat, ale prakticky nehrozí, že byste museli použít cokoliv nativního proto, že v Javě neexistuje vhodný ekvivalent. A existují interprety? Interpret javy se jmenuje Java Virtual Machine (JVM) a existuje skutečně pro cokoliv - PC s jakýmkoliv operačním systémem, handheld, mobilni telefon. Zakladatelem Javy a jejím silným podporovatelem je firma Sun Microsystems. Ale kromě standardní implementace JVM firmou Sun je možné použít i jiné - například IBM JVM nebo některou z open-source. Pokud by Sun z nějakého důvodu přestal Javu podporovat, je dostatečně otevřená na to, aby se jí ujal kdokoliv jiný.

Nejběžněším řešením v jednouživatelském prostředí je nevrstvená infrastruktura. Obvykle všechny části aplikace běží na jednom stroji, výhodou je jednoduchost ve všech směrech - jednoduchá výroba, jednoduché testování, jednoduché nasazení. Není použitelná v distribuovaném prostředí, kde například s jednou databází pracuje více lidí.

Obrázek 13. Samostatná aplikace

Poznámka k obrázku: Je to UML diagram nasazení, krabice znamená hardwarový prostředek, nejspíše počítač.

Základní způsob jak umožnit více uživatelům pracovat se sdílenými prostředky (daty případně i procesy), je vytvořit server, který bude tyto prostředky poskytovat klientům, kteří je budou naopak využívat. Data je nutné sdílet prakticky ve všech případech, ale z hlediska umístění aplikační logiky připadají v úvahu dvě možnosti:

4.1.2.1. S mohutným klientem

Pokud klient obsahuje kromě živatelského rozhraní i aplikační logiku, je to mohutný klient (thick client). Nejčastěji se se připojuje pouze k nějakému úložišti (databázi), aby ukládal a čerpal data.

Obrázek 14. Mohutný klient - úložiště

4.1.2.2. S tenkým klientem

Klient, který neumí nic jiného, než zprostředkovat uživateli přístup k datům a programové logice tím, že se spojí se serverem je tenký (thin). Takovým klientem může být například prohlížeč internetových stránek („browser“), který žádnou logiku konkrétní aplikace už ze své podstaty obsahovat nemůže.

Obrázek 15. Tenký klient - mohutný server

Je-li každý popisovaný systém maximálně autonomní, je to třívrstevná infrastruktura (three-tier, multilayered):

Obrázek 16. Třívrstevná infrastruktura

Tato varianta je každopádně nejsložitější, ale přináší mnohé výhody například: [taks]

ASM aplikace musí být snadno škálovatelná a to nejlépe z jednoduché desktop aplikace, přes různé klient server modifikace, až po třívrstevný model s aplikačním serverem uprostřed. Druh nasazení by neměl zvyšovat komplexitu objektového modelu a vývojářům by mělo být tak říkajíc jedno, v jak distribuovaném prostředí aplikace poběží.

Objektově orientované systémy (OODBMS) umožňují ukládat objektová data ve tvaru, který je jim přirozený [itl] a jsou tak řešením, které se tak říkajíc na první pohled nabízí, má-li aplikace propracovaný objektový návrh. Již několik let existuje standard vytvořený sdružením Object Database Management Group (ODMG). Definuje komponenty:

S ODMG je možné vytvářet transakce, přistupovat do databáze více vlákny, znovupoužívat připojení (connection pooling).

Avšak volně nabízené a otevřené OODBMS jsou stále v experimentální fázi vývoje a tak či onak nestabilní, zatímco komerční systémy ohromí svými cenami. Co je ale nejhorší, kromě ODMG existuje hned několik dalších dotazovacích jazyků a žádný není široce podporovaný. [itl]

Na rozdíl od objektově orientovaných, kde jsou data dobře strukturovaná a logicky propojená, jediné co relační databáze (RDBMS ) nabízejí jsou tabulky propojené relacemi. Relační databázové technologie jsou vyspělé - jedny z nejstarších, přitom používané a stále nejpopulárnější ze všech. Přispívá k tomu jejich jednoduchost, efektivita, obecně nižší nákladnost. Existuje i mnoho poměrně pokročilých RDBMS úplně zdarma, například PostgreSQL. [ itl ]

Objektový přístup k tvorbě aplikací pracuje s objekty - strukturami, kombinujícími data a chování, zatímco relační přístup je zaměřený čistě na ukládání dat. Takzvaný impedanční nesoulad (impedance mismatch) vyplyne na povrch, když porovnáme upřednostňované řešení přístupu: U objektového řešení je zvykem objekty procházet tak, jak jsou vystavěny příslušné závislosti, zatímco relační přístup duplikuje data při spojování řádků tabulek. Tento základní rozdíl znesnadňuje kombinaci obou přístupů, ale, přiznejme si, kdy jste naposled použili dvě různé, primárně nesouvisející věci, aniž by to vyžadovalo pár triků? Jedním z tajemství úspěchu při objektově relačním mapování je porozumět oběma přístupům, jejich odlišnostem a na základě tohoto poznání je přimět ke spolupráci. [mapping] Tyto postupy jsou již dnes docela dobře propracované a právě mappingje vhodným úvodem.

V současné době jsou také k dispozici použitelné nástroje, které značně usnadní mapování. Jsou to řešení proprietální, liší se funkcemi, podporovanými formáty popisu mapování, programátorským rozhraním, podporovanými RDBMS a mnoha dalšími vlastnostmi. Na Internetu je k dispozici celá řada srovnání.

Již před lety samozvaní objektoví guruové nabádali, abychom nechodili cestou nesouladu. Ano, objektový přístup je jiný než relační, ale v 99% případů, kdy vývojové prostředí je objektově orientované, úložištěm bude relační databáze. Prosím, smiřte se s tím. [mapping]

Mnoho výrobců databází, např. Oracle používá technologie, které zachovávají přednosti relačních databází a zároven umožnují podle standardu SQL 99 specifikovat uživatelské datové typy (UDT), které logicky odpovídají objektům. Datový model je přímo v databázovém systému objektový a na jeho základě se tvoří jednotlivé tabulky. Toto řešení se principielně neliší od O2R mapování popsaného výše, rozdíl je pouze v přímé podpoře ze strany databáze.

OLAP (On-Line Analytical Processing ) je technologie, která umožňuje pohlížet na data tradiční relační databáze jako na mnoharozměrnou strukturu. Příklad: [itl]

Obrázek 18. Tradiční tabulka

Obrázek 19. Příklad pohledu podél jiného rozměru

Tento model včetně implementace a nezbytných nástrojů umožňuje rychlé, přirozené zpracovávání dat podél všech rozměrů. Má význam zejména pro velké databáze, kde jsou potřeba postupy označované jako data mining. Součástí mnoharozměrného pohledu mohou být hierarchie a mnoharozměrná aritmetika. OLAP analýza může být implementována nad tradičními (zejména relačními) databázemi, anebo nad speciálním optimalizovaným úložištěm - mnoharozměrnou databází (MDBMS). Jejich cena odpovídá typickému nasazení. [itl]

Stromová datová forma je velmi vhodná pro některá silně strukturovaná data, např. pro dokumenty, hierarchie objektů (třeba uživatelů), reprezentaci plánů apod. Příslušné technologie jsou LDAP, registry, XML databáze a další.

Sami vidíte různorodost existujících řešení perzistence aplikací, z nichž každé má své výhody a nevýhody a to jsem se o mnoha možnostech vůbec nezmínil. Potřeba zastřešit takto různorodé zdroje dat nějakým jednotným rozhraním vyústila v definování konkrétních standardů. Kromě příkladů specifických pro jazyk Java (níže) stojí za zmínku ještě jednou ODMG - viz 5.1.2 – „Objektově orientované databázové systémy“. Tento standard měl původně sloužit jako jednotné rozhraní objektových databází, ale teoreticky (díky svému poměrně univerzálnímu návrhu) by mohl splnit stejnou funkci. Je potřeba mít ovšem na mysli, že použitelný bude ten standard, jemuž se dostane podpory ze strany dodavatelů řešení úložišť.

Jakarta OJB (původně ObjectRelationalBridge, po kompletním přepracování a zuniverzálnění dále už jen OJB) je knihovna pro jazyk Java, která zpřístupňuje nejen relační databáze, ale teoreticky všechny běžné typy úložiště. Aplikace může přistupovat k úložišti přímo jednoduchým, ale proprietárním rozhraním nazvaným PersistenceBroker. OJB ale přidává další vrstvu abstrakce i směrem „dovnitř“, tedy k aplikaci a té tak umožňuje pracovat dle nejznámějších standardů - ODMG či JDO. Tato architektura je dobře vidět z obrázku, který jsem si půjčil z [ojb]

Obrázek 20. Architektura OJB

OJB dokáže pracovat jak ve vícevrstevné architektuře uvnitř EJB aplikačního serveru, tak u nevrstvené aplikace. Je, ostatně jako všechny jiné projekty Apache Jakarta, dobře dokumentována. Její novější verze se i docela snadno nastavují i používají. A je zadarmo, dokonce open-source. Sám jsem nepatrně jsem i přispěl k jejímu vývoji a její funkčnost odzkoušel na jednoduchých aplikacích. OJB je ale nasazena i v silně zatížených podmínkách na Internetu, u různých informačních systémů po celém světě a i leckde jinde. Vřele doporučuji.

Základní nevýhoda formátů pro tiskový výstup spočívá v tom, že jsou nevhodné pro jiné použití - informace „chápou graficky“a neznají význam informací. Dejme tomu, že pro tiskové výstupy programu použijeme RTF. Ale co když si pořídíme PostScriptovou tiskárnu a budeme chtít využít její schopnosti pro zvýšení kvality výstupů? Tak je převedeme, možná řeknete a s jistými obtížemi se vám to podaří. Ano, tak jiná otázka: Co když podobné výstupy, jaké tisknete, budete posílat ke zpracování „cizímu“informačnímu systému, spravovaného například ministerstvem financí. A co když požadovaný formát bude vyžadovat VÍCE informací, než kolik jich je v RTF, takže automatizovaný převod bude znamenat spoustu práce při psaní nějakého převodního programu či schématu a nebo bude principielně neproveditelný. Ano, přijde to nejhorší - zásah do vlastní aplikace (do metod uvnitř tříd modelu). Shrneme-li výše uvedený příklad: Pouze graficky formátované informace jsou takřka nepoužitelné jinak, zejména strojově.

U ASM aplikace musí být změna konkrétního výstupního formátu neinteraktivních sestav možná a maximálně snadná a nesmí vyžadovat zásahy do modelu..

XML= eXtensible Markup Language. XML umožňuje definovat vlastní sady „tagů“, konkrétní podle typu zachychené informace. Příkladem jednoduchého XML dokumentu (bez záhlaví) je následující popis výrobku:

<pecivo>
 <nazev>rohlik</nazev>
 <cena>2</cena>
 <mena>Kč</mena>
</pecivo>

Možná namítnete, co je na tom tak zvláštního, v čem se to liší například od takovéhoto dokumentu (který je mimochodem znatelně kompaktnější):

pecivo
 nazev:"rohlik"
 cena:"2"
 mena:"Kč"

Máte pravdu, že informačně je druhý (neXML) dokument stejně bohatý. Skutečné výhody XML se objeví, až když se zkombinuje s dalšími existujícími standardy a nástroji. XML má totiž v tomto smyslu vybudovanou kvalitní infrastrukturu, jinými slovy první dokument existujícími nástroji můžete snadno (bezpracně) reprezentovat stromovou datovou strukturou uvnitř vámi vyráběného programu, snadno ho převedete do zobrazitelné podoby (u které snadno změníte způsob zobrazení), snadno ho upravíte v XML editoru... Navíc existují schémata pro různé oblasti využití, pro která jsou opět hotové nástroje, transformační schémata... Omlouvám se - schémata jsou teprve před námi.

<xsl:template match="duraz">
 <i>
  <xsl:apply-templates />
 </i>
</xsl:template>

Z grafických uživatelských rozhraní doposud drtivě převažuje právě tento typ. Vzhled je včleněn do „oken“, ta se skládají z běžných i méně běžných widgetů, převzatých z programovacího jazyka či vývojového prostředí, ve kterém je aplikace tvořena a z jejich derivátů. Výřez okna editoru XML Mind (ve kterem píši tento dokument), aplikace s docela typickým „desktop“ vzhledem, vám možná trochu přiblíží, co tím myslím:

Obrázek 25. Příklad vzhledu desktop aplikace

V Javě byl takovou sadou komponent AWT, tento balík je ovšem zastaralý, nahradil ho nověji JFC, jehož novější verze jsou známy pod kódovým jménem Swing. Tato knihovna je svým návrhem, funkcemi a použitelností jednou z nejlepších vůbec, proto si přiblížíme některé její části a schopnosti: [j2sdk]

Systémy spadající do stejného scénáře jako Swing se obvykle vyznačují například těmito přednostmi:

Různé aplikace na Internetu jsou (a budou) čím dál významější, prostředky pro jejich vytváření proto přibývají jako houby po dešti a jsou velice různorodé. Stručné a přehledné srovnání přístupů (nikoliv konrétních nástrojů) jsem nikde nenašel, proto jsem se tomuto námětu věnoval o trošičku více, ale i tak je to pouhý rozcestník..

Populárním termínem v této oblasti je MVC , tedy model-view-controller architektura. I přes svou značnou popularitu toho MVC příliš mnoho neříká a prakticky cokoliv o sobě může prohlašovat, že je implentuje MVC přístup. Klíčová myšlenka MVC by se mohla shrnout slovem „oddělenost“. Model, vzhled i kontroler musí být maximálně oddělené jeden od druhého a komunikovat přes co nejužší, jasně vymezené rozhraní. Tato zásada je všeobecně přijímána jako důležitý předpoklad dosažení flexibility a snadné spravovatelnosti. V dalších částech se zamyslíme nad konkrétními typy MVC technologií pro prostředí webu. Termín „model“ se poměrně dobře kryje s tím, jak jej zde chápeme a mohli jste si o něm přečíst něco v 2 – „Model“, proto jej dále nebudu zkoumat. Z logického celku „view“ prozkoumáme postupy vytváření dynamického obsahu a poté se dokneme standardů pro vlastní formulářové prvky. O části „controller“ se zmíním na závěr, hodně stručně.

7.1.3.1. Vytváření dynamického obsahu

Principem aplikací na webu je nějakým způsobem implementovaná logika vytváření stránek a zpracovávání uživatelských vstupů, zkrátka to, co dodává běžným (a tedy statickým) HTML stránkám dynamiku. Je možné odlišit dva principielně odlišné přístupy, někdy označované jako „push“a „pull“. Historicky starší je pull přístup a funguje tak, že do jinak statické stránky „dotáhne“ dynamický obsah. Důležitým momentem je zde to, že tento proces je iniciován a řízen „z pohledu“ statické stránky.

Obrázek 26. Pull přístup k vytváření dynamického obsahu

Klasickým příkladem pull technologie jsou skripty včleněné do HTML stránky (ASP, PHP, JSP, ..). Výzkumy i zkušenosti čím dál tím jasněji ukazují, že tento přístup nevede k vytvoření snadno spravovatelné, flexibilní webové aplikace. Základní příčinou je jednoduchý fakt, že není technicky zaručeno, aby obsah, vzhled a logika byly maximálně odděleny a naopak jsou nabízeny prostředky k implementaci koncepčně špatných řešení, která jsou u pull technologií technicky neproveditelná. Silná stránka skriptovacích jazyků („moc“ a značné schopnosti) je v důsledku slabinou. O trochu méně výrazný, ale pořád ještě dostatečně nepříjemný je tento problém u „template engines“ (Velocity, WebMacro, FreeMarker, WebMacro, Tea,...), které jsou principielně ekvivalentní skriptování. Jejich výhodou je, že to nejsou plnohodnotné programovací jazyky, a tak nabízejí o něco méně možností k prohřeškům. Více v tomto směru např xmlcvsjsp.

Technologie umožňující obojí přístup existují od samého začátku dynamických stránek. Mám na mysli CGI skripty, tedy samostatně spustitelné programy, jejichž jediným úkolem je generovat výsledný kód stránky. Principielně shodné s CGI jsou servlety (vlastně CGI napsané v Javě). Jakým způsobem si výsledek sestaví, je jejich soukromou věcí - mohou kombinovat kód programu se statickým obsahem (pull) anebo načíst šablonu stránky a vhodně ji doplnit (push).

Prosím, nenechte se zmást reklamou technologií, která bude jistě tvrdit, že umožňuje oddělit vzhled, logiku a obsah. Skutečně, v zásadě všechny to umožňují, ale žádná z výše uvedených to nemůže zaručit.

Push technologie jsou naopak k takové záruce o dost blíže. Musíte se opravdu snažit, abyste princip oddělenosti porušili, a i to se vám podaří jen částečně. Zásadní, ale velice praktické omezení spočívá v tom, že šablona, zdrojová stránka (nejspíše XHTML ) prostě je statická a není žádný způsob, jak to změnit. Program načte ve vhodné podobě tuto čistě statickou stránku a „vtlačí“ do ní na požadovaná místa dynamický obsah. Statická stránka je zde jakýmsi „substrátem“ na kterém program dodávající dynamický obsah pracuje.

Obrázek 27. Push přístup k vytváření dynamického obsahu

Příkladem produktu, který implementuje push přístup je open-source projekt Enhydra XMLC. Návrhář stránek použije svůj oblíbený editor a pouze místa, kde má stránka obsahovat dynamický obsah, označí id atributem a o logiku „dotlačení“ dat se nestará. XMLC kompilátor z takové stránky sestaví specifickou DOM (stromovou) reprezentaci, a usnadní programátorovi přístup k označeným místům, určeným pro dynamický obsah. Programátor doplní postup získání dynamického obsahu a snadno ho včlení do stránky se zachováním jednotného vzhledu. Tento postup schematicky znázorňuje obrázek, který jsem si půjčil z [xmlcvsjsp]:

Obrázek 28. Princip XMLC

I s mobilními telefony a různými PDA zařízeními je nutno počítat - „mobilní aplikace“ budou pravděpodobně jedním z nosných směrů blízké budoucnosti. Existuje obdoba jazyka HTML (WML), dále speciálně upravený virtuální stroj javy včetně nejnutnějších knihoven (J2ME) a různé další pomůcky, nástroje, standardy a technologie. Nebudu zabíhat do podrobností, pouze připomenu, že uživatelské rozhraní na podobných zařízení má svá specifika, především si musí poradit s velikostí displeje zařízení, nesmí také vyžadovat nadbytečné datové přenosy nebo „myšově orientovanou“ výraznou interaktivitu... Určité ambice v tomto směru má standard XForms.

Kromě grafických výstupů má význam uvažovat též rozhraní pro slabozraké a nevidomé, např. systémy s Braillovým písmem a zejména zvukové. Rozhraní pro hendikepované vyžadují kompletně odlišný přístup. Nové možnosti se otvírají v souvislosti s pokrokem systémů umělé inteligence z oblasti rozpoznávání mluvené řeči. Vytvoření podobného rozhraní pro složitější aplikace je zatím velice pracné a nevím o žádné běžně použitelné „knihovně zvukových widgetů“. Je pravda, že takováto rozhraní nemají tu nejvyšší prioritu, ale striktně odmítnout možnost vytvářet aplikace s podporou pro hendikepované lidi by bylo diskriminující a nerozumné i z obchodního hlediska, zejména v přípdadě, že by tím složitost vývoje a správy aplikace nebyla výrazně dotčena.

Swing teoreticky umožňuje vytvořit zvukový l&f. Potíž je v tom, že widgety jsou navrženy zejména pro grafická rozhraní, a tak obsahují mnoho informací o tom, jak mají vypadat, kde mají být ve formuláři apod., ale chybí jim specifické informace pro snadnou implementaci principielně odlišných scénářů. Řešením by byla nějaká mezivrstva, která by obsahovala maximum informací o modelu a ty byla schopna převést či předat jak do specificky grafické reprezentace (např. Swingu), tak do jakékoliv jiné...