středa 5. listopadu 2008

JSF nemá mou důvěru

K tomuto zamyšlení mě vyburcovalo přečtení článku JSF vs. Tapestry - jak jednoduché je dělání komponent a letmé nahlídnutí do JSF specky 2.0 (zdroj JavaServer Faces 2.0 Composite Components). Nevím jestli se tomu dá říkat předpojatost, možná ano, možná ne, ale technologie JSF ve mě prostě nebudí důvěru. A mám k tomu několik pádných důvodů.

JSF byly od počátku přesně tím typem specifikace v Jave, který jasně ukazuje, jak se to nemá dělat. Není možné si říci, my teď potřebujeme komponentovou technologii pro vývoj web aplikací, tak si něco vymyslíme. To už ukázaly jiné specifikace v JEE, že tohle prostě nefunguje, protože lidé ve skutečnosti chtějí trochu něco jiného. Příklad JSF jasně ukazuje, že ve verzi 1.0 jsou uživatelé dané technologie spíše v roli pokusných králíků.

Mluvím o tom v každé své prezentaci otírající se o JEE, základním nepochopením lidí, kteří JEE tvořili (doufám už v minulém čase), bylo to, že je potřeba, aby technologie byla jednoduchá a použitelná. Většina všech webových aplikací, neřkuli všechny, řeší ty samé problémy. Proto musí být základní charakteristikou každého web frameworku to, že umožní tyto problémy řešit jednoduše.

K čemu je webový framework řešící problémy třetího světa (nadneseně řečeno), když v něm nejde jednoduše udělat vlastní komponenta. Přijde mi jako utopie spoléhat na nástroje, které by nás měly od této komplexnosti odstínit. Vývojáři neradi spoléhají na magické skříňky, které jim pod rukami generují tuny kódu. Je to vcelku pochopitelné a vychází to z dobře známých důvodů.

Další věcí k zamyšlení je, jestli opravdu odstínění od principu webové aplikace požadavek/odpověď je to co při vývoji webových aplikací potřebujeme. Opravdu nám vyšší abstrakce přinese tolik výhod oproti tomu, o co přijdeme? Má smysl zakrývat základní paradigma webu a tvářit se, že webovou aplikaci lze stavět podle podobných principů jako tu desktopovou? Osobně tuhle víru ztrácím. Položme si otázku, mají něco podobného technologie jako PHP či Ruby on Rails. Pokud ne, proč asi...

Poslední, ale rozhodně ne nejméně důležitý fakt představuje faktor inovace či agilnosti. JSF 2.0 po jejich finálním vydání zůstanou zakonzervované nějaký ten pátek. Oproti tomu jakýkoliv proprietární (nestandardizovaný) framework může relativně pružně reagovat na aktuální potřeby. Přidávání nových vlastností do čehokoliv standardizovaného je prakticky nemožné a pokud je to vůbec možné, tak ve většině případů ztrácíme přenositelnost. U proprietárních frameworků tohle prostě a jednoduše nehrozí.

úterý 4. listopadu 2008

Spring a jeho další směřování v enterprise oblasti

V rozhovoru SpringSource Elected Newest Executive Member of the Java Community Process poodkrývá Rod Johnson další budoucnost Springu a jeho další směřování v JEE oblasti. To co se dalo číst mezi řádky vyplouvá v tomto rozhovoru na hladinu. To nejdůležitější co jsem si odnesl odpovídá v podstatě tomu, co si již dávno myslím.

  • PHP, Ruby on Rails, .NET je potřeba brát jako seriózní hrozbu. JEE platforma a nejenom ona se musí neustále rozvíjet jinak zanikne. Není možné se neustále spoléhat na silné stránky jako škálovatelnost či spolehlivost, protože ty mohou být v relativně blízkém čase i v konkurenčních technologiích. Inovace je potřeba, stejně jako kopírování osvědčených postupů. Základním cílem je výrazné zjednodušení používání JEE.
  • Spring nebo mnohem přesněji SpringSource dm Server je alternativou se vším všudy k tradičním JEE serverům jak je známe. Velkou sázkou je OSGi, které zatím představuje dle mého soudu největší riziko, protože ovlivňuje návrh aplikace, její rozčlenění (packaging), vývoj i deployment.
  • SpringSource dm Server je jasným důkazem toho, že SpringSource (společnost stojící za Springem) snaží zaměřit na runtime a stát se plnohodnotným middleware dodavatelem. Ostatně je to logické, to je oblast, ze které tečou peníze. Proto nepřekvapí prohlášení o tom, že SpringSource dm Server bude JEE 6 implementace minimálně na úrovni web profilu.
  • Tím, že se SpringSource stal členem JCP (Java Community Process) může ovlivňovat rozhodnutí, která se mu hodí do krámu. To může být například adopce právě OSGi jako dalšího deployment modelu.