čtvrtek 14. prosince 2006

Podcast volume#3 konečně je venku

Vánoce, vánoce přicházejí a s nimi v pořadí třetí Java podcast tentokrát na téma Java 6 SE, Vývoj webových aplikací. Vzkaz tohoto podcastu je nad slunce jasnější: Místo vánočních koled a Mrazíka doma pouštějte Javu 6 a JSF ;-).

středa 13. prosince 2006

Seam 1.1 - nejenom EJB 3.0

Gavin King se asi chytil za nos, protože nová verze Seamunezávisí na EJB 3.0. V předchozích verzích šel sice Seam spustit například v Tomcatu, ale bylo nutné rozběhnout JBoss Micro Container. To s verzí 1.1 již není potřeba.

Mezi další novinky patří možnost, vygenerovat kostru Seam aplikace z existující databáze. Další novinkou je replikace stavu statefull komponent, funguje to i na POJO objekty. Právě replikace je velice zajímavá, protože se nereplikují celé objekty (grafy objektů), ale pouze vzniklé rozdíly. Pokud si chcete replikace POJO objektů vyzkoušet, začněte s konfigurací clusteru podle návodu JBoss cluster krok za krokem.

Další novinky najdete v článku What's New in Seam 1.1, kde je i spousta dalších zajímavých linků. Seam se mi začíná líbit čím dál tím víc. Pokud máte se Seamem reálnou zkušenost podělte se o ní v diskuzi. Určitě to zajímá velké množství čtenářů.

pondělí 11. prosince 2006

Java SE 6 je venku

Java Standard Edition 6 byla oficiálně uvolněna. Sun v rámci této verze nabízí bezplatnou nelimitovanou 60 denní podporu určenou k migraci skrze Sun Developer Expert Assistance. Krom veřejně proklamovaných vlastností nabízí i tato verze výkonostní posun v rozmezí 5% až 24% (TheServerSide) oproti předchozí verzi.

Následující seznam zahrnuje nové či inovované oblasti v rámci Java 6 SE.

  • Security Features and Enhancements
  • Integrated Web Services
  • Scripting Language Support
  • Enhanced Management and Serviceability
  • Increased Developer Productivity (JDBC 4.0, Java Platform Debug Architecture (JPDA) & JVM Tool Interface)
  • Improved User Experience (Swing performance, Vista support)

Mnohem detailnější popis najdete ve následujících článcích.

Přiblížení vizuálního vzhledu mezi Swing a OS ilustruje následující obrázek dialogu pro výběr souboru či adresáře (obrázek z diskuse k článku Around the Web: Java 6.0 Released).

Swingová komponenta

OS komponenta

Mě udělalo největší radost fixnutí IO chyby, která způsobovala, že nebylo možmé na Windows používat delší cestu než 255 znaků a vylepšení debug rozhraní JVM. Naopak jsem opět zatřel slzu, protože než bude Javu 6.0 adoptována, uteče mnoho vody v rodné Otavě.

Související články

Dagblog, související články :

neděle 10. prosince 2006

Web frameworky v Jave

Tento článek by se také mohl jmenovat po stopách MVC aneb nutné minimum, pokud nechcete udělat při vývoji webových aplikací v Jave chybu. Začneme hodně ze široka, Java není .NET, proto máte opravdu obrovský výběr frameworku pro tvorbu webových aplikací. Všechny frameworky, která znám a budu o nich mluvit, spojuje jedna věc. Tou věcí je jejich architektura, všechny je spojuje návrhový vzor MVC. Pokud jste seznámeni s konceptem MVC, můžete následující stať přeskočit.

Od špagetového kódu k MVC

Když byla poprvé představena technologie Java Server Pages (JSP, (1)) byla hodně podobná PHP či ASP a umožňovala používat Javu v prostředí webu pro dynamické vytváření stránek. Základem je takzvaný skriptlet (uvozený mezi <% %>), uvnitř kterého bylo možné používat přímo Javu ke generování HTML. To by nebylo na škodu, kdyby nedocházelo k tomu, že vývojáři začali všechen kód aplikace dávat přímo do JSP stránek. Výsledek pak vypadal pak přibližně následovně

 
<% 
 Connection con = null;
 String sql = "select name from users";
 PreparedStatement ps =  con.prepareStatement(sql);
 ResultSet rs = ps.executeQuery();
 out.println("<table>");
 while(rs.next()) {   
     out.println("<tr>"); 
       out.println("<td>");
         out.println(rs.getString(1));
       out.println("</td>");
     out.println("</tr>");
 }
 out.println("<table>");
%>  

 

Problém s uvedeným kódem byl v několika rovinách. Míchala se prezentační a aplikační logika. Kód který měl nějakou business funkci byl promíchán s kódem, který vytvářel jeho zobrazení. Takto vytvořený kód se nedal, a nebo velice obtížně, znovupoužít v jiné stránce a nebylo jej možné testovat. Výsledkem byl kód, který byl promíchaný jako klubko špaget.

Další evoluční krok bylo zavedení nového rozšíření a to takzvaných custom tagů (JSP 1.1), které bylo možno sdružovat do tag library (knihoven). Tag má dvě části, jednak vlastni zápis podobný HTML elementům a jednak Java třídu (2), která mu odpovídá. Díky tomu umožňuje zapouzdřit Java kód do znovupoužitelné podoby, jedno zda pro tvorbu dynamického obsahu nebo pro volání aplikační logiky.

V návaznosti na JSP 1.1 se někdy kolem roku 2000 začaly objevovat první web frameworky, které byly postavené na návrhovém vzoru Model View Controller (zkráceně MVC). Asi nejznámějším frameworkem, který tuto vlnu představoval a jenž se stal de facto standardem, byl Struts.

Návrhový vzor MVC slouží k oddělení aplikační a prezentační logiky. Za tímto účelem není použit jenom v rámci webových aplikací, ale například i v desktopových aplikacích (3).

Model View Controller

MVC má tři části, Model, View a Controller. Každá část má svojí specifickou a přesně určenou roli.

Controller
hraje roli prostředníka mezi Model a View.
Model
představuje entity (data), nad kterými pracuje View
View
transformuje Model do prezentační formy

Díky rozdělení rolí, má každá část svojí odpovědnost a nedochází k jejich vzájemnému promíchání. Jednotlivé části mezi sebou nemají těsnou vazbu, Model poskytovaný nezávislou aplikační logikou je možné využívat beze změny v N View. Pro objasnění, na následujícím obrázku je znázorněná jedna z možných realizací MVC v prostředí JSP a Servletů.

Realizace MVC v prostředí Servletů a JSP

Příchozí požadavek je delegován na Servlet, který představuje Contoller. Servlet (Controller) zavolá aplikační logiku, ze které získá Model (4) a ty zaregistruje do scope viditelného z JSP např. request attribute. Následně provede přesměrování na JSP, které si ze scope vyzvedne data (Model) a ten zobrazí.

Současná architektura web frameworků

Následující text není pro volbu webového frameworku tolik důležitý, slouží pouze jako nahlédnutí pod kapotu. Pokud Vás nezajímají nuance mezi enterprise návrhovými vzory, můžete tuto kapitolu s klidem přeskočit.

Existuje několik způsobů jak MVC v prostředí webu implementovat. V dnešní době jsou dva hlavní přístupy (5), které odpovídají následujícím dvěma návrhovým vzorům

Klasickými představiteli implementace Front Controller jsou frameworky Struts 1,2, Spring MVC. Naopak na vzoru Dispatcher view jsou postaveny všechny implementace standardu JSF a jeho nadstaveb jako Shale či Seam.

Rozdíl mezi webovým frameworkem postaveným na Front Controller a nebo Dispatcher view je z pohledu aplikace nad ním postavené v okamžiku volání aplikační logiky. V případě Front Controlleru se aplikační logika volá před předáním zpracování do View, kdežto v případě Dispatcher view se volání aplikační logiky děje zprostředkovaně uvnitř View viz návrhový vzor View Helper.

Rozdíl je vidět na následujícím sekvenčním diagramu. Front Controller jsem nahradil za specializovanější Service To Worker.

Sekvenční diagram Dispatcher view a Service to Worker
Plná velikost (cca. 25KB)

Určitě stojí minimálně za zmíňku, že Service To Worker i Dispatcher view jsou kompozicí vzorů Front Controlleru a View helper. Rozdíl je pouze ve větší čí menší míře odpověnosti na Controlleru resp. View.

Jak rozlišit webové frameworky

Pokud pomineme vnitřní architekturu jednotlivých frameworků, od které je aplikace odstíněna, hraje nejdůležitější roli úroveň abstrakce nad HTTP protokolem. Čím větší úroveň abstrakce, tím méně se musí jednotlivé vrstvy zajímat o samotný HTTP protokol. Pěkně to ilustruje následující obrázek (Kito D. Mann, Java Server Faces in Action str. 20).

Abtrakce poskytovaná webovými frameworky
Plná velikost (cca. 81KB)

Jak je vidět, Java Server Faces nabízejí vyšší míru abstrakce oproti Struts (Spring MVC) a to v oblasti tvorby UI komponent a událostního modelu. Na stejné úrovni jako JSF je například framework Tapestry. O těchto frameworcích můžeme mluvit jako o komponentově orientovaných. Naproti tomu o Struts like frameworcích mluvíme jako o požadavkem řízených. Pokud vybíráme webový framework, měli bychom si zodpovědět několik zásadních otázek.

Komponentově orientovaný či požadavkem orientovaný framework?

Budoucnost patří rozhodně komponentově orientovaným frameworkům, protože jsou navržené tak, aby umožňovaly vývojáři pracovat na úrovni UI komponent. Díky tomu je možné vytvářet nástroje, které mají podporu UI komponent zabudovanou. Na druhou stranu existuje obrovské množství vývojářů, kteří ovládají Struts se všemi jejich best practises. Pokud nemáme čas potřebný na adoptování JSF, proč nesáhnout po Struts nebo Spring MVC.

Standardizovaný či proptietární?

Výhoda standardizovaných řešení je v míře jejich podpory v nástrojích. Především jednáli se o Java standard jako v případě JSF. Pěkným příkladem je Java Studion Creator od firmy Sun, který lze považovat za první opravdový RAD nástroj pro tvorbu webových aplikací v Jave. Oproti tomu open source proprietární řešení většinou nabízejí lepší možnost úpravy v případech, že něco nevyhovuje. Jejich další výhodou je nezávislost na úrovni implementace standardu.

Bude se používat JSP?

V některých případech není JSP zvoleno jako technologie pro tvorbu dynamického obsahu. Bude umožňovat webový framework jednoduše použít například XSLT? Velice dobře je to podchyceno v JSF, které nejsou závislé na JSP. V případě JSF je dokonce otázka JSP ano či ne celkem zásadní. Především z toho důvodu, že nelze rozumě mixovat JSTL tagy a JSF tagy. Životní cyklus JSF komponent je odlišný od životního cyklu JSP.

Pokud mělo v něčem Tapestry obrovskou výhodu, pak to byl zápis. V případě Tapestry se totiž zapisuje rovnou HTML kód rozšířený o Tapestry tagy. Při zpracování se pak obsah tagů nahradí odpovídajícími hodnotami. V JSF lze JSP nahradit technologií Facelets a podle některých je to více než doporučované.

Podporuje jednoduchou integraci s bean kontejnerem?

Aplikační logika bývá spravována kontejnery typu Spring, EJB apod. Bylo by pro to dobré, aby byly objekty s aplikační logikou jednoduše přístupné webovému frameworku resp. odpovídajícím částem Controller nebo View Helper. Například Seam umožňuje přímé vystavení business logiky realizované pomocí session bean jako JSF backing bean (6).

Nadstandard

V případě JSF nabízejí různé implementace různá rozšíření nad rámec specifikace. Je tedy dobré zvážit jestli se svázat s konkrétní implementací a jejím rozšířením (v mnoha případech velice potřebným) a nebo být nezávislý na použité JSF implementaci.

Závěr

Velkou výhodou Javy je široký výběr nabízených web frameworků. Někdo to sice považuje za navýhodu, protože není úplně jednoduché se v tom množství nabízených řešení vyznat. Cílem tohoto článku bylo zdůraznit, že není důležité konkrétní jméno, ale vlastnosti frameworku, které požadujete. Doufám tedy, že se to povedlo. Tomuto tématu, bychom se měli věnovat v příštím podcastu.

Poznámky

  • [1] JSP je podmnožina technologie Servlet, která je mnohem abstraktnější pracuje přímo nad komunikačním protoklem (HTTP, FTP) a nad ním poskytuje základní API. Každá JSP stránka je vždy před prvním požadavku zkompilována na servlet a použita.
  • [2] Musí implementovat přímo nebo nepřímo javax.servlet.jsp.tagext.Tag
  • [3] Příkladem z Javy je technologie Swing.
  • [4] Model představuje nejen vlastní data, může sloužit ja rozhraní k aplikační logice
  • [5] prezentace The State Of Web Frameworks (PDF) - Craig R. McClanahan
  • [6] Backing beana je v případě JSF takzvaný View Helper, který zprostředkovává data z aplikační logiky.

Související články

Zmiňované frameworky