Java na serveru - Úvod

6.10.2007 18:47 | Přečteno: 1807× | software | poslední úprava: 6.10.2007 18:52

V posledních pár článcích se objevilo slovo Java. Nevěřícně jsem zíral, jaký může vyvolat flame, jedno magické slůvko.

V určitých ohledech musím ríct, že se některým lidem nedivím, že Javu odmítají, ale z daných diskutujích nikdo nevzal v potaz fakt, že ona Java je silná na serveru. Zde kraluje z několika důvodů.

Abych jen nevytvářel další článek, který je o ničem, rozhodl jsem, že se pokusím sepsat důvody, proč vlastně Enterprise Java. Dále s jakými frameworky (samozřejme budou existovat alternativy) a jak jednoduchou aplikaci napsat. Samotné porovnání nechám na Vás.

Nepředpokládám, že se mi podaří někoho přesvědčit, že je Java skvělá. Spíše se pokusím vysvětlit, proč je "nejen" vhodná na serveru.

Architektura

Bude se jednat o klasickou aplikaci klient-server-databaze. Samotné rozdělení je vcelku jasné. Jako databázi volím MySQL. V tomto případě může být DBMS jakýkoli, jelikož enterprise aplikaci, kterou budu tvořit, bude nezávislá na volené DB. Samotný server bude glassfish v2, který se dále dělí na vlastní vrstvy (o tom až za chvíli). Klientem bude primárně web aplikace. Samozřejmostí bude, že klientem může být i desktop aplikace, která bude používat stejnou business logiku jako web aplikace.

Aplikační server

Asi nejzajímavější částí je tato. Popisu celé problematiky se věnují odborné knížky. Já zkusím provést pouhý rychlokurz, aby bylo přibližně jasné, oč se vlastně jedná.

AS bychom mohli rozdělit do tří skupin.

• Persistentní vrstva - obsahuje strukturu DB v objektech (entity) a komunikuje s DB
• EJB kontejner - obsahuje vlastní logiku (business logic)
• WEB kontejner - obsahuje podporu JSP-Servletu

Toto základní rozdělení by mohlo stačit. Nyní již k výběru jednotlivých frameworků.

Na persistentní vrstvu použiji TopLink s JPA. TopLink nám zajišťuje komunikaci s DB (EntityManager) a JPA je vlastně definice, jak mají jednotlivé Entity vypadat. Pod entitou si mohu představit nějakou oanotovanou třídu, která obsahuje atributy, setry-getry. Pro představu by se dalo říci, že jedna instance entity odpovídá 1 řádku tabulky v DB (samořejmě to vždý nemusí platit).

Na samotnou business logiku volím EJB3. Pod EJB si lze představit jednoduchou POJO třídu, která obsahuje metody (business metody) a zpracovává požadavky, které jdou z klientské části. Lze sem dosadit i několik služeb, jako JTA, JMS, Timers, JAAS, atd. Na této úrovni bych měl řešit vše, co se řešit dá. Více tím odstíním klientskou část od nějaké vlastní implementace logiky mezi DB a Javou.

Webový kontejner sice obsahuje JSP-Servlety, ale pro efektivnější práci použiji nějaký web-framework. Pro Javu jich existuje snad desítky. Asi není příliš jednoduché si najít ten správný (pomoc s výběrem bývá snad nejčastější dotaz na javovských konferencích). Já osobně použiji JSF. Důvod proč je ten, že se jedná komponentový framework, který má slušné zázemí, samotný Sun.

Jako demo aplikaci zvolím jednoduchý systém na správu zaměstnanců, který bude obsahovat zabezpečení pomocí JAAS služby. Jelikož se jedná o dobře rozdělenou architekturu, tak lze říci, že je to pouhý start, na kterém se dá dále stavět.

To by bylo prozatím asi vše. Jak jsem psal na začátku, existují i další alternativy, zejména při výběru řešení, ale jedno zůstává pořád stejné a to fakt, že Java je na tento druh aplikací vážně jak dělaná.

       

Komentáře

[Cohen]

Díky. Jsem zvědavý na pokračování.

[Karel Benák]

Konecne zapis, ktery snad bude davat smysl a ze ktereho se clovek neco dozvi

[Deleted [8409]]

Tez se tesim na pokracovani. Ja jsem zacal experimentovat s djangem a zatim si neztezuji, ale velmi rad si rozsirim obzory

[kouby]

Jeste by jsi mohl pouzit spolu s Java Server Faces nejaky sablonovy system, aby vzhled te webove aplikace byl odstinen od systemu (napr. facelets se casto pouziva v kombinaci s jsf). Coz je docela dulezite u web aplikaci.

[springer]

Enterprise Java,

DBMS,

enterprise aplikaci,

glassfish v2,

Persistentní vrstva,

strukturu DB v objektech,

(entity),

EJB kontejner,

(business logic)

WEB kontejner

JSP-Servletu

persistentní vrstvu

TopLink

JPA.

EntityManager

oanotovanou třídu

setry-getry.

business logiku

EJB3.

POJO třídu

JTA,

JMS,

Timers,

JAAS,

Webový kontejner

JSP-Servlety

web-framework.

JSF.

komponentový framework

JAAS služby.

[Lukáš Zapletal]

Dost slabé, raději upřesním:

Pod EJB si lze představit jednoduchou POJO třídu, která obsahuje metody (business metody) a zpracovává...

Tady musí být řečeno pod session EJB si lze představit... Máme samozřejmě i jiné typy EJ beanů.

Bývá dobré zhodnotit také druhou stranu věci -- proč používat něco jiného. Jaké jsou problémy třeba s plněním testů, s přílišnou obecností a komplexností J2EE, problémy s testováním EJB a tak dále. Dle mého názoru jsou to všechno nevýhody, které lze snadno překonat.

JPA není jedinou možností, donedávna tu nebyla a používalo se často něco jiného. Krátkou větu bych určitě uvedl: Můžete použít i jiné technologie pro perzistenci dat, třeba Hibernate, iBatis nebo Cayene.

..sice obsahuje Servlety, ale je lepší použít framework...

To trošku zavání tím, že by snad Servlety měly být nedostatečným řešením. Proto bych zde rád doplnil, že Servlety se používají ve všech J2EE frameworcích, jen s nimi nemusíte pracovat přímo (minimálně je třeba je nakonfigurovat). A samozřejmě je můžete používat samostatně (front controller + JSP).

Zapomněl jste na messaging, který je nedílnou součástí J2EE řešení. Každá větší firma používá WS nebo JMS (či oboje). Je to integrační záležitost a dnes se bez ní firmy téměř neobejdou. A tady spatřuji velkou výhodu J2EE -- hluboká provázanost s těmito API (a to nejen na programové úrovni).

No a rád bych tedy slyšel proč vlastně enterprise java. Tohle je velmi zajímavé téma, které budu brzy studentům přednášet, a rád si poslechnu názory. Zajímá mě to na všech úrovních (obchodní, technická, IT). Takže reagujte na můj komentář:

Proč právě enterprise java (hergot)?

[finc]

Ocekaval jsem podobny prispevek.

1. Napsal jsem, ze cely popis problematiky zde nenajdete.

2. Vyber reseni jsem urcil podle sveho a opet jsem zminil, ze existuji alternativy. Pokud nekoho dane alternativy zajimaji, at si je nalezne, nerad bych zde udelal nejaky vycet a pak cetl rozzlobeny komentar, ze jsem neco vynechal :)

Ano, mame i jine typy beanu, vlastne tri: Stateless, Statefull a DrivenMessage. Opet, na tuto problematiku si lze spise otevrit nejaky ten tutorial a precist si, o cem to vlastne je. Samozrejme bychom mohli pokracovat a zminit Interceptory, atd. Ale do toho se poustet vazne nechci.

U tech servletu jste vlastne rekl to same. Nikde jsem nenapsal, ze by JSF byla nejaka nahrada. Je to pouze framework nad timto resenim.

Messaging, zminil jsem jednou zkratkou JMS. Co se tyce WS, je to dalsi hrac. Neminim zde delat nejaky komplexni popis vsech casti. Zminuji pouze to, co chci pouzit v dane chvili.

Nechci zachazet do detailu, na to vazne nemam tolik casu. Navic, nerad bych rozpoutal nejaky flame. Nekdo, kdo pouziva Spring, by me napr. mohl osocit, ze jsem ho nezminil. Pokud nekoho tato problematika zajima, jiste si o tom sezene vice informaci. Ja se spise pustil do jednoducheho prikladu, pred kterym musel prijit jednoduchy uvod, o tom, co vlastne ta java na serveru je.

Proc prave Enterprise Java? Napsal jsem to jiz na zacatku. Jedna se o cast, ve ktere je Java vazne dobra, alespon dle meho nazoru. Druhou veci je i fakt, ze neni zrovna jednoduche (alespon na zacatku), vytvorit nejakou jednoduchou ukazku, ktera by nebyla vygenerovana z IDE a tim pochopit zakladni koncept.

[Lukáš Zapletal]

a) Nejsem rozzlobeny, jen rad uvadim veci na pravou miru, pokud si to situace vyzaduje. Myslim, ze to bylo patrne z toho prispevku - no offence...

b) Pokud jste neco takoveho cekal, nebylo nic jednodussiho nez zapisek o par vet rozvest a uvest nektere veci na pravou miru. Napriklad typy EJB jste krasne vyjmenoval v tomto komentari, doporucuji zapisek obohatit o tyto veci - ne kazdy komentare cte (ja ne, paklize necekam reakci, jako prave ted). Minimalne bych uvedl, ze EJB resi jak logiku, tak perzistenci a messaging (vzdaleny pristup).

c) "Enterprise Java je vazne dobra" -- dost chaby argument Vazne me mrzi, ze nikdo nereagoval. Opravdu me zajimaji pro/proti ohledne J2EE.

Na ten priklad jsem zvedavy.

[Kyosuke]

DrivenMessage

Taková třída v Javě neexistuje.

[Daniel Kvasnička ml.]

No, v posledni dobe v praci prechazime pri vyvoji novych systemu na Javu, tedy abych byl presnejsi, tak Tomcat, MySQL, Spring, Wicket, DWR... Moje dojmy jsou dost smisene. Pro one man show mi to pripadne jako nevhodna platforma, je to strasne "ukecane" reseni -- nedokazu si predstavit, ze bych svoje freelancove projekty zacal misto Djanga / CodeIgniteru delat v J2EE. Nicmene je mi jasne, ze ta rozvrstvenost a robustnost je v nekterych pripadech neocenitelna. Zvlaste, kdyz ma byt hodne slozita business logika abstrahovana na takovou uroven, aby bylo jedno, jestli k ni pristupuje web klient nebo desktop app (i to by se IMHO dalo celkem bez obtizi zaridit napr. dobre navrzenou Django aplikaci) nebo pokud jde o fakt mission critical vec. No uvidime, co se od tebe dozvime

Jednu vec bych ale ze sveta web Javy vyzdvihnul urcite a to je uz zminovane DWR. Pro zadnou jinou platformu jsem nenasel nic, co by tak efekt(iv)nim zpusobem povznaselo AJAX na vyssi uroven. Proti XML sice nic nemam, ale DWR je fakt parada. Pro PHP se o podobnou vec snazi SAJAX, ale o remotovani nejakych business trid nemuze byt rec...pokud vim, zvlada jen funkce a to jeste ne moc hezky.

[podlesh]

Moje dojmy jsou dost smisene. Pro one man show mi to pripadne jako nevhodna platforma, je to strasne "ukecane" reseni

Ano, pro "one man show" se skutečně jedná o nevhodnou platformu. Maximálně ještě tak pokud se počítá s výměnou onoho muže.

[finc]

Málokdy si člověk může být jistý, kam se jeho projekt dostane a kolik lidí se na něm bude podílet :)

[finc]

Souhlasím, že dost často se jedná kanón na vrabce. Na druhou stranu, stále zde existuje možnost vyměnit klienta za cokoli jiného. Dost často se mluví např. o jRuby.

Mě osobně se právě líbíla ta rozvrstvenost. U jazyků jako je PHP o tomto nemůže být ani řeč. Co se týče toho desktop klienta, zde jsem se dočkal docela zklamání. Sice ta možnost existuje, ale s příliš velkými omezeními (pouze serializovatelné objekty, nutnost linkování spousty knihoven, výkon, distribuování aplikace). I přesto ale občas desktop klient nabídne něco, co převáží tyto neduhy.

AJAX je zajímavá myšlenka, která je ale dost často přeceňována. Pokud ovšem chci jít tímto směrem, tak i v samotném JSF mám výborné prostředí toto uplatnit.

Jinak nečekej žádné zázraky. Za prvé nejsem takový expert v této oblasti a za druhé, spíše chci ukázat jednu z cest na jednoduchém příkladu.

S tou one man show příliš nesouhlasím. Osobně jsem na projekt také sám, ale nijak mě to nedegraduje k tomu, abych dané řešení nepoužil.

Uvidíme, budu ovšem rád, když se v komentářích objeví více lidí, co o tomto budou diskutovat a míti další konstruktivní myšlenky, co mohou ostatním pomoci.

[Daniel Kvasnička ml.]

Mě osobně se právě líbíla ta rozvrstvenost. U jazyků jako je PHP o tomto nemůže být ani řeč.

No, zas tak bych to nazabijel. PHP je sice strasne jako jazyk, ale existuje par frameworku, ktere separaci vrstev implementuji docela slusne. Sice ne tak granularizovane jako J2EE, ale v pripade, ze vam pro business logiku staci jednovrstvy Model (coz v mnoha pripadech staci), tak se s tim da pracovat.

AJAX je zajímavá myšlenka, která je ale dost často přeceňována. Pokud ovšem chci jít tímto směrem, tak i v samotném JSF mám výborné prostředí toto uplatnit.

Precenovana je casto, dusledek Web 2.0 boomu Kazdy to chce pouzivat, ale ne kazdy vi kdy a jak Kazdopadne DWR zkus, poskytuje java beans jako JS objekty, takze v JS volas metody s parametry napr. na servisnich tridach jak kdybys byl v jave.

S tou one man show příliš nesouhlasím. Osobně jsem na projekt také sám, ale nijak mě to nedegraduje k tomu, abych dané řešení nepoužil.

No ja na to ted nejsem sam, jsme na to cela firma, je to velky projekt. Ja se pohybuju spis v hornich vrstvach. Spring MVC, Wicket, AJAX... se spodnimi vrstvami nemam zkusenost.

[Lukáš Zapletal]

Souhlasím s Danielem. Že se v PHP nedají dělat enterprise věci je nesmysl. Sám jsem do detailu poznal jeden systém, na kterém běží e-shop evropského (velkého) mobilního operátora - mají to škálovatelné, robustní a výkonné. Design k nerozeznání od J2EE webové aplikace, polovina IT oddělení ani neví, že to jede na PHP (přípony nejdou vidět). Pravda, používají technologie Zendu, ale je to v podstatě PHP s vícevrstvou architekturou.

PHP bych rozhodně nezatracoval, s dobrým analitykem a project leaderem se dají dělat úspěšné projekty postavené i na této platformě. Stačí mít zkušenosti s vývojem enterprise systémů (nejlépe v Javě) a zajistit interoperabilitu do J2EE (což řeší produkty Zendu). Otázkou je, jestli firma nemusí investovat více prostředků na to, aby udržela vývoj ve správných kolejích a aby jim nové (nekompatibilní) verze PHP neztížily situaci. Evidentně se zdá, že to jde (zmíněná firma momentálně dost expanduje).

To mi připomíná jeden můj zápisek o tom, proč jsem pro docela jednoduchou webovou aplikaci nezvolil Javu. A to jsem javista už pár dekád...

[Ladicek]

Kazdopadne DWR zkus, poskytuje java beans jako JS objekty, takze v JS volas metody s parametry napr. na servisnich tridach jak kdybys byl v jave.

S Google Web Toolkitem mám totéž a ještě ke všemu v té Javě doopravdy jsem Jinak rozdíl mezi DWR a GWT je značný, případy užití se prakticky nepřekrývají.

[Daniel Kvasnička ml.]

Jinak rozdíl mezi DWR a GWT je značný, případy užití se prakticky nepřekrývají.

No vsak to jsou absolutne jine typy technologii S GWT mam take zkusenost, testoval jsem ho pro vyvoj UI pro svuj publikacni system, ale nejak jsem se nemohl skamaradit s RequestCallbacky... mozna jsem ty principy jen spatne pochopil, ale jak byste treba natahl jsenim requestem XML, druhym XSLT a vysledek transformace umistil nekam do aplikace? (treba za pomoci http://ebessette.com/wiki/display/dev/XSLT+for+GWT)