středa 12. prosince 2007

Do pranice: kontrolované vs. běhové výjimky

Napsal jsem, nebo lépe řečeno zrefaktoroval jsem, velké množství kódu, z kontrolovaných výjimek na běhové a všude to bylo ku prospěchu věci. Principiálně souhlasím s tím, že kontrolované výjimky mají své uplatněni a to tam, kde je z kontextu možné zotavení. Typickým příkladem jsou vstupy od uživatele. Těchto případů je možná 20%. Zbylých 80% jsou výjimky systémové-běhové, ze kterých se není schopen klient se v daném kontextu zotavit, příkladem budiž výpadek databázového stroje.

Největší nevýhodu kontrolovaných výjimek vidím v jejich invazivnosti do klientského API. Tato invazivnost způsobuje dva problémy: narušuje zpětnou kompatibilitu a ve většině případů vede k často se opakujícímu kódu (konverze výjimky na běhovou). Nicméně souhlasím s tím, že je potřeba mít ošetřenou práci s výjimkami, ale nemyslím si, že je nějaká extra výhoda to vynucovat kompilátorem. Naopak to spíše vede k anarchii v jejich ošetření.

I v případě běhových výjimek lze dosáhnout správného ošetření. Klíčem je centralizované místo (může to být aspekt), které se bude starat o chytání a zpracování výjimek. Další velice užitečnou technikou je použití takzvané deklarované běhové výjimky. Běhové výjimky jsou nadeklarovány v throws klauzuli, takže minimálně při pohledu na signaturu metody je vidět, k čemu může dojít.

neděle 9. prosince 2007

Pětka technologií pro budoucnost enterprise Javy

Technologie jako Spring, Hibernate a nebo Seam charakterizují nebo charakterizovaly určitý stupeň vývoje. V současnosti se jedná de facto o standardy, které lze jenom stěží považovat za žhavou novinku. Na následujících řádcích jsem se pokusil sepsat pár technologií a konceptů, které by rozhodně neměly ujít vaší pozornosti, protože v budoucnu může dojít k jejich masivnímu použití v enterprise aplikacích.

OSGi

O OSGi jste si mohli již na Dagblogu přečíst. Ve zkratce řečeno, jedná se o způsob jakým spravovat služby v řízeném prostředí. Jedná se o deployment, vyhledání a použití služby. OSGi rozhodně není žhavou novinkou, nicméně do pětice technologií pro budoucnost rozhodně patří. I přes to, že je OSGi staršího data, k jejímu zapojení v oblasti enterprise Javy dochází teprve nyní.

OSGi má v současnosti problém, že s ním nebylo v předchozích verzích enterprise Javy počítáno. To způsobuje celou řadu problémů, ale pokud se podaří nějakým způsobem začlenit OSGi do připravované J2EE 6, měla by to být zelená pro jeho masivnější použití.

AOP

AOP alias Aspektově Orientované Programovaní je tu sice nějaký ten pátek, ale k jeho masivnímu rozšíření zatím podle mého názoru nedošlo. Pokud jste o AOP nikdy neslyšeli, můžete si udělat představu z mého článku Transparentní cache pomocí AOP. Aspekty se dají využít jak pro funkčnost, která má svoje místo v produkčním nasazení, tak pro funkčnost, která nám slouží pouze v době vývoje. Díky deklarativnímu nasazení AOP je možné pohodlné řídit přesnou množinu funkčnosti, která se dostane do výsledného kódu aplikace.

Pomocí AOP například snadno vytvoříte kód, který bude trasovat počet a trvání SQL příkazů v rámci jednoho HTTP požadavku na aplikaci. AOP se dá použít k tomu, aby jste například pro testy nasimulovali chybu v zpracování požadavku a testovali zotavení-chování dané části systému. To je jenom v rychlosti pár tipů, ve skutečnosti je AOP výtah, který posunuje možnosti Javy o pořádný kus dále.

REST

O RESTu jsem nejenom psal, ale i povídal. Protože věřím, že přijde čas online služeb, přijde mi REST jako nejlepší způsob jejich integrace. Nevýhodou RESTu je špatná infrastruktura, to znamená že si zatím takřka vše musíte lepit na koleni a pokud to slepíte, pak pravděpodobně narazíte na problémy s nestandardnímy požadavky na deployment.

Gridy

Grid computing je přirozeným vyústěním požadavků na výkonné a škálující aplikace. Klíčem k úspěchu je držet se hesla rozděl data a paralelizuj zpracování. V současnosti existují dva typy gridů - datové a výpočetní. Datové gridy umožňují zpracování velkého množství dat jejich rozdělením a výpočtové gridy umožňují paralelizaci zpracování. Samozřejmě nejlepší je kombinace datového i výpočetního gridu, moje sympatie patří Terracota a GridGain.

Grid řešení lze dnes integrovat se standardy, o kterých jsem psal na začátku článku. Například Terracotu můžete použít jako efektivní distribuovanou cache (Hibernate second level cache, replikace HTTP session). GridGain lze použít například pro paralelizaci testů.

Skriptovací jazyky

Skriptovací jazyky se budou prosazovat díky jejich efektivitě a nenáročnosti. Neočekávám, že by snad měli nahradit Javu jako jazyk, ale budou používány k jejímu doplnění. Klíčové části aplikací budou stále psány v Jave a skriptovací jazyky budou sloužit k tvorbě nadstaveb např. UI vrstva aplikace a nebo k zákaznické customizaci. Skriptovací jazyky mají blíže k tvorbě takzvaných DSL, což je zkratka pro Domain Specific Languages. Díky skriptovacím jazykům půjde lépe vytvořit a používat DSL oproti staticky typové Jave.

Další výhodou skriptovacích jazyků je jejich nenáročnost na deploymentu a ladění aplikace. Žádné restarty/reloady aplikací pro načtení nových změn. Současné IDE již dnes také nabízejí velkou podporu skriptovacích jazyků jako debuggovaní, zvýrazňování syntaze a další.

Tak to je moje pětice, pokud jsem na nějaký směr či technologii zapomněl, rád se to dozvím v komentářích. Prosím nepište ovšem o konkretních implementacích (např. JBoss Seam), ale spíše o přístupech či architektonických směrech.