Thursday, October 7, 2010

SOA vs. OOP – Jing a Jang v architektuře podnikových aplikací

Standardní odpověď aplikačního architekta na otázku zákazníka, jak by navrhl architekturu zamýšlené podnikové aplikace, bude pravděpodobně znít: „Použiji klasickou třívrstvou architekturu.“ Počet vrstev se může samozřejmě případ od případu lišit, faktem však zůstává, že se podobné odpovědi staly v posledních letech tak trochu klišé. Architektonická rozhodnutí jsou do značné míry předurčena etablovanými technologickými platformami, které aplikačnímu architektovi vymezují manipulační prostor pro rozhodování. Mezi nejpoužívanější platformy pro vývoj podnikových aplikací patří v současnosti bezesporu dvě rivalské technologie Microsoft .NET a Java EE[1]. Architekt obvykle nemá možnost volby mezi zmíněnými platformami a je často postaven před hotové rozhodnutí, učiněné s ohledem na obchodní a strategické zájmy dodavatele či zákazníka. Nicméně společným jmenovatelem obou vedoucích technologií je skutečnost, že byly navrženy s důrazem na usnadnění tvorby vícevrstvých, distribuovaných aplikací. Obě platformy poskytují pestrou škálu různých knihoven, API a nástrojů, které významně zefektivňují vývoj. Nezbytnou podmínkou je samozřejmě jejich zvládnutí vývojářem a dostatečná praxe.

Připomeňme si hlavní přednosti vícevrstvé architektury. Je-li správně a racionálně navržena, může mít pozitivní vliv hned na několik systémových kvalit. Asi nejdůležitější kvalitou je škálovatelnost. Tato vlastnost určuje, jak je aplikace schopna vypořádat se s rostoucími nároky, například zvyšujícím se počtem současně přistupujících uživatelů. Rozdělení aplikace do slabě svázaných vrstev umožňuje řešit problematiku úzkého hrdla aplikace na úrovni jednotlivých vrstev. Nejvíce zatíženou vrstvu lze po identifikaci vyčlenit a patřičně posílit. (Obecně platí, že prezentační vrstva se obvykle škáluje přidáváním dalších počítačů, zatímco perzistentní vrstva se škáluje navyšováním paměti a počtu procesorů.)

Vícevrstvá architektura úzce souvisí s architekturou orientovanou na služby (SOA). SOA aplikace jsou obvykle distribuované, vícevrstvé aplikace, které mají prezentační, aplikační a perzistentní vrstvu. Veškerá funkcionalita takové aplikace je vystavena prostřednictvím služeb. V SOA aplikacích se typicky neudržuje stav konverzace s klientem, komunikace probíhá způsobem dotaz-odpověď, případně jednosměrně, komponenty aplikace jsou slabě provázané a primárním zájmem je business logika aplikace poskytovaná formou služeb.

Zajímavým postřehem je, že v uvedených architektonických přístupech jaksi nezbývá místo pro objektové paradigma (OOP), tolik populární před nástupem SOA. Koneckonců, jak .NET tak Java jsou objektové jazyky, jejichž „objektovost“ zde přichází poněkud vniveč. Tyto jazyky mají vestavěné objektové koncepty jako dědičnost, polymorfismus a zapouzdření, které dávají architektům a vývojářů do rukou mocné nástroje při objektovém návrhu aplikací. V servisně orientovaných aplikacích je primárním artefaktem služba, tedy procedurální prvek, který zpracovává či poskytuje data. Data a business logika jsou zde oddělené. Návrhové vzory považované za „best-practicies“ v servisně orientovaném návrhu jsou v objektově orientovaném návrhu často považované za anti-vzory a naopak. Jistě stojí za úvahu, zda-li jsme se spontánním přechodem k servisně orientované architektuře nevědomky neochudili o nějaký důležitý či užitečný koncept ze světa objektového návrhu.

Pro ilustraci uvádím příklad webové aplikace pro ukládání a úpravu fotografií. Uvažujme případ užití, ve kterém si uživatel zobrazí vybranou fotografii. Na stránce s fotkou má k dispozici kontrolky, pomocí kterých může měnit různé vlastnosti a parametry fotky, například rozměr.

Aplikace navržená v intencích SOA paradigmatu bude poskytovat služby pro vyhledání fotografií, pro jejich úpravu, uložení atp. Fotka samotná bude reprezentovaná prostou datovou strukturou bez metod (tzv. anemický objekt). Pokud si uživatel přeje provést nějaké úpravy, aplikace zavolá odpovídající službu, které předá objekt fotografie. Služba vrátí upravený objekt a prezentační vrstva jej zobrazí uživateli. Pokud je uživatel s úpravami spokojen, uloží změny prostřednictvím služby pro ukládání fotografií. Objekt fotografie je po většinu času tzv. odpojený, neboli bez spojení na databázi. Výhody s tím spojené mohou být snadno převáženy komplikovaným a výkonnostně náročným slučováním pozměněného objektu se stávající verzí v databázi během ukládání. Tento problém je obzvlášť citelný v případě rozměrných objektů, jako například právě fotografií.

Podívejme se nyní na stejnou aplikaci, tentokrát navrženou v objektovém paradigmatu. Na rozdíl od servisně orientované architektury, kde je primárním artefaktem služba, zde je v centru pozornosti objekt fotografie. Ten neobsahuje pouze prostá data, ale současně s sebou nese také operace pro manipulace s daty (zapouzdření). Požadavek na přeformátování fotografie se nepředává specializované službě, nýbrž se o přeformátování požádá samotný objekt fotografie. Takový design je velmi intuitivní a přirozený, neboť vystihuje naše vrozené vnímání objektů z okolního světa coby autonomní entity. Významným rozdílem je také skutečnost, že objekt je po celou dobu tzv. připojený, neboli v kontaktu s perzistentní vrstvou. Nedochází zde tudíž k onomu komplikovanému a náročnému slučování verzí. Objektový návrh se také elegantněji vypořádává s požadavkem na odlišné zpracování požadavku v závislosti podle typu objektu (polymorfismus). Lze si představit, že změna rozměrů nějaké speciální fotografie, např. fotky do pasu, bude na rozdíl od obyčejné fotografie provádět jakési dodatečné kontroly na povolené rozměry. Využitím dědičnosti (jejíž podpora je součástí programovacího jazyka) lze tohoto chování snadno docílit. V servisně orientovaném návrhu vede řešení takového požadavku k složitému a předpotopnímu řešení pomocí větvení kódu.

Je potěšující, že poslední verze platformy Java EE přinesla řadu nových technologií a vylepšení (obvykle inspirovaných v open-source projektech – např. Seam a Guice), která návrh objektově orientované architektury podnikových aplikací významně usnadňují. Díky nim může nyní architekt navrhovat podle potřeby oba typy architektur v rámci jedné platformy. Závěrem bych rád podtrhl, že ačkoliv jsou oba přístupy v mnoha ohledech antagonistické, mohou nejen koexistovat v jedné aplikaci, ale mohou se i vhodně a účelně doplňovat.



[1] Další technologie postavené na Javě používané při vývoji podnikových aplikací, jako například Spring a Seam, považuji za produkty vzniklé v důsledku nedokonalostí a omezení starších verzí platformy Java EE. Je pravděpodobné, že současný trend nastavený platformou Java EE 5/6, která převzala řadu inovací a nápadů ze zmíněných technologií, povede k jejich postupnému opouštění.



Sunday, October 3, 2010

Konfigurace českého prostředí v BlueJ na Mac OS X

Postup pro zprovoznění češtiny v kódování UTF-8 na Mac OSX je následovný:

1. Rozbalte si archiv s lokalizací BlueJ stažený ze stránek p. Pecinovského (http://vyuka.pecinovsky.cz/bluej_config/index.html)
2. Rozbalte obsah aplikace BlueJ ve Finderu poklepáním pravým tlačítkem myši na její ikonu a volbou Show Package Contents
3. Přejděte do složky Contents/Resources/Java a nakopírujte do ní obsah archivu s lokalizací
4. Vraťte se do složky Contents, kde poklepejte na soubor Info.plist
5. V editoru vyberte složku Root/Java/Properties
6. Tlačítkem New Child přidejte novou systémovou vlastnost JVM file.encoding s hodnotou UTF-8
7. Uložte změny a spusťte BlueJ

Poslední úpravy lze provádět i manuálně v obyčejném textovém editoru. Soubor Info.plist je "obyčejné" XML.

Saturday, October 2, 2010

Nastavení TCP/IP portů využívaných serverem Glassfish v3

V základní konfiguraci využívá Glassfish tři porty: 4848, 8080 a 8181. Na portu 4848 běží administrátorská konzole, porty 8080 a 8181 jsou určeny pro webové aplikace, přičemž port 8080 slouží ke komunikaci prostřednictvím HTTP protokolu, port 8181 se používá pro HTTPS protokol.

V případě konfliktu s existujícími aplikacemi v systému, které již používají zmíněné porty, často nezbývá jiná možnost, než změnit čísla portů používaných Glassfishem. Nejjednodušší způsob, jak nastavit tato čísla, je ruční zásah do XML souboru v útrobách instalace serveru.

Nastavení je třeba provést v souboru, který se nachází na cestě [glassfish_path]\glassfish\domains\domain1\config\domain.xml, kde [glassfish_path] je adresář s instalací serveru. Je-li tato instalace součástí NetBeans, tento adresář se nachází v instalačním adresáři NetBeans. V tomto souboru je třeba vyhledat následující sekci a nastavit požadované hodnoty v atributech port:


<network-listeners>
<network-listener port="8093" ... />
<network-listener port="8181" ... />
<network-listener port="4848" ... />
</network-listeners>

Úpravy v NetBeans


Provedené změny se bohužel nepromítnou do prostředí NetBeans. Proto je třeba vytvořit nový server Glassfish 3 a asociovat jej s vyvíjenou aplikací.

Návod:

1. Přepněte do záložky Services

2. Klikněte pravým tlačítkem na položkou Servers a zvolte Add Server...

3. Vyberte Glassfish Server 3 a klikněte na Next

4. Lokalizujte adresář s instalací serveru na vašem počítači. Nachází se v adresáři s instalací NetBeans. Klikněte na Next

5. Klikněte na Finish


Nyní je třeba asociovat vyvíjenou aplikaci s nově vytvořeným serverem:

1. Přepněte do záložky Projects

2. Klikněte pravým tlačítkem nad uzlem projektu a zvolte Properties (poslední položka)

3. Vyberte položku Run a na pravé horní straně panelu vyberte název nově vytvořeného serveru.




About Me

My photo
Cokoliv říkáme, je až na výjimky jinak.

Followers