Právě jsem dokoukal záznam z přednášky Roda Johnsona s názvem „Už tam budem?“ (Are we there yet?) Vřele ji doporučuji, člověk se v ní doslechne mnoho zajímavých myšlenek.
Jak už název napovídá, celá přednáška měla být o tom, jestli už se Java vyvinula natolik, aby v ní bylo bezproblémové vyvíjet enterprise aplikace. Začíná zajímavým ohlédnutím do roku 2003, kdy jedinými masově rozšířenými open source projekty v Javě byly Struts a Log4j. Upozorňuje také na zajímavý posun v myšlení vývojářů. V roce 2003 panovalo přesvědčení, že na to, aby mohla být technologie úspěšná, musí být i komplexní. Dnes už tomuto věří málokdo.
Dle svého zvyku se přednášející obouvá do EJB. Hlavně do jejich snahy skrýt některé věci před vývojáři (pooling, starání se o vlákna atp.) Zaujaly mě následující hlášky
Když se k vývojářům budeme chovat jako k opicím, jediné co dostaneme bude tlupa naštvaných opic.
Je zásadní chybou definovat infrastrukturu a architekturu s tím, že architekti a vývojáři jsou hloupí.
Tento problém nemají jen EJB, setkáme se s tím i u všelijakých vlastnoručně psaných frameworků. Podle Roda Johnsona se omezením kreativity vývojařů o hodně připravíme. Toto téma vede k zamyšlení nad standardy a specifikacemi. Dovolím se opět ocitovat
Specifikace dobře pochopených problémů jsou úspěšné.
Je snadné standardizovat něco, co se za dvacet let nezměnilo.
Evidentními příklady jsou JMS, JTA a JNDI. Jsou to věci, které v době jejich specifikace byly dobře prozkoumány a jejich standardy jsou tím pádem úspěšné. Naproti tomu standardizování věcí, které ještě nejsou dobře prozkoumány vede k problémům (např. entity beany)
Zásadní myšlenka zazněla přibližně uprostřed prezentace.
Většina Java aplikací není objektově orientována.
Nejprve mě to překvapilo, ale pak jsem si uvědomil, že má pravdu. Uvědomme si, že objekt je cosi co seskupuje data a chování do jedné entity. Podíváme-li se na klasickou třívrstvou Java aplikaci, zjistíme, že tříd, které by měly obojí je tam minimum. Máme servisní vrstvu, která je obvykle bezstavová a kromě konfigurace v sobě moc dat nemá. V podstatě obsahuje jenom chování. Na druhé straně pak máme doménový model, který obvykle jenom drží data a neobsahuje žádné chování. To je zajímavé. Všichni tvrdíme, že OOP je dobrý nápad, ale přesto programujeme více méně procedurálně. Připravujeme se tím o spoustu výhod, které nám OOP nabízí.
Obchodní logika v servisní vrstvě není znovupoužitelná.
Co s tím? Řešením je přesunout logiku do doménových objektů. Tzn. místo toho abychom měli službu, která zaregistruje mazlíčka u veterináře, mít příslušnou metodu přímo u třídy reprezentující veterináře. Narazíme zde ale na jeden problém. Jak nainjektovat podpůrné služby do doménového objektu? Přes Spring to nejde, doménové objekty jsou obvykle instanciovány OR nástroji. Řešením je AspektJ. Napíšeme si malou anotaci (nebo XML konfiguraci) a můžeme injektovat přímo do doménového modelu. Pan Johnson tvrdí, že se tím výrazně zvýší znovupoužitelnost kódu.
V poslední části prezentace uvidíme zajímavou studii interceptorů v EJB 3. Zde se autoři specifikace nepoučili ze zkušeností AOP aliance a rozhodli se, že si problém AOP vyřeší po svém.
Ve skutečnosti nezáleží na tom jak je člověk chytrý, když mu chybí zkušenost.
U EJB 3 máme AOP bez pointcutů. Tzn. jediný způsob jak určit, kdy se interceptor zavolá, je přidat ke třídě nebo metodě příslušnou anotaci (nebo se vrhnou do ekvivalentní XML konfigurace). Není možné říci například, že chci mít interceptor kolem všech metod v tomto balíku. To je přinejmenším nepohodlné. Není možné říci, že chci volat interceptor jen u metod, které mají parametr daného typu. To už je i náchylné na chybu.
EJB interceptory jsou experimentální.
Ano, ještě nikdo nikdy nezkoušel dělat AOP bez pointcutů. Dá se očekávat, že se přitom narazí na problémy.
A jak zní odpověď na otázku v názvu prezentace? Dovolím si zde použít citát z Murphyho zákonů
Končí-li novinový titulek otazníkem, zní odpověď “ne”.
Zbývá ještě dost problémů, které je třeba v Javě vyřešit, než budeme moci říci, že vývoj enterprise aplikací je v ní bezproblémový.
Upozornění: V tomto příspěvku se mísí citáty Roda Johnsona s mojí interpretací. Netvrdím, že všechno co zde píši řekl, je to spíš o tom co jsem si z toho vzal já. Pokud chcete informace nezkreslené, vřele doporučuji originál.
Jsem sice zacatecnik v oblasti enterprise technologii, ale co je podle tebe idealni stav?
Podle meho bude vzdy co vytykat, vzdy budou mezery, vzdy budou otazniky. To, proc tomu tak je, bych nazval vyvoj.
Osobne jsem z “oslavnych tutorialu Java EE 5” take rychle vystrizlivel, ve chvili, kdy jsem zacal pouzivat distribuovanou javu pres glassfish do swingu. Ale zase na druhou stranu, kdyz si pote podrobneji procitam manualy, zjistuji, ze ne vse je chyba prvotni architektury, ale moje, protoze jsem nejdrive vytvarel a pak az premyslel. Take kdyz se divam na specifikaci EJB 2, tak musim rict, ze je to peknej zmatek. V podstate znam jen EJB3 a tento zpusob se mi dost zamlouva.
Az nekdy bude neco idealni, tak zde budou muset zit lide, kteri nebudou premyslet nad chybami.
Rod Johnson ma velmi dobre argumenty a i ma v mnoha vecech ma pravdu. Jen mi prijde skoda, ze nespolupracuje po vzoru Gavina Kinga s expert grupama, ktere vytvari nove specifikace Java EE a pouze se do nich navazi (EJB 3 nejsou tak spatne jak Rod tvrdi :). Tim prosazuje svuj framework – skoda, ze radeji nepracuje na tom, aby dalsi verze Java EE byla lepsi. Gavin to pochopil – pote co vytvoril hibernate spolupracoval na tvorbe JPA, ktera se stala dobrym standardem (jak i Rod rika) a posunul se dal a pracuje na Seamu (ktery bude z vetsi casti opet soucasti JCP diky web beans). Ale Rod zrejme musi take vydelavat penize s Interface 21, takze spolupracovat s JCP by mu mohlo snizit vynosy z konzultaci kolem Springu 🙂
to Roumen> nesouhlasim, Gavin King je v trochu jine pozici.
– Hibernate je pod kridly JBosse, takze verim, ze ho Fleury nebo nekdo donutil k participaci v JCP, aby byl zachovan vliv JBoss
– JPA v ktere predevsim participoval se tvorila uplne od zacatku
Oproti tomu Rod Johnson muze tezko participovat na necem, s cim vnitrne nesouhlasi a diky zpetne kompatibilite to nemuze ani zmenit. On ani Gaving King nebude moc spokojeny s EJB, kdyz puvodne psal Seam nad EJB 3.0, ale pak pochopil, ze to pro uzivatele nebude to prave orechove.
Taky nesouhlasim, ze vsude cpe jenom Spring viz debata AOP vs. Interceptory. Kdyby se vzali EJB 3.0 do detailu, tak to co mohli obslehnout ze Springu udelali tak na pul. Muzeme vzit novou funkcnost po funkcnosti v EJB 3.0 a ukazu ti jak ji Spring sfoukne jak svicku.
Rod Johnson je proste prilis revolucni na usedle JCP a to je dobre, protoze takhle muze svuj cas venovat na rozvoj Springu.
Nemyslim si, ze strkat business logiku do domenovych objektu je uplne nejvhodnejsi metoda OOP programovani v J2EE aplikacich. To jestli ta business logika drzi nejaky stav a nebo ne je veci vnitrni implementace. Nad to, ta bezestavovost ma samozrejme svuj smysl viz distribuovatelnost. Jinymy slovy nema cenu se drzet neceho dogamticky, ale jinak souhlasim, ze AOP introduction je pekna featura ;-).
Podle mě je důležité uvědomit si, že opravdu neprogramujeme moc objektově. Nevím jestli je to dobře nebo špatně, ale je to tak. Rozhodně bychom si toho měli všimnout a zamyslet se nad tím.
Podle me jde Rod Johnson spravnym smerem. Kdyz si uvedomim jak moc je Spring uzitecny na vetsich webovych projektech. Rozhodne se budu tesit na to co bude zase noveho v dalsich verzich Springu. Ja jsem kdysi ze Springu pouzival jen par veci, hlavne dependeny injection a desclarativni transaction management. Dneska uz bych toho pouzil asi vic. Rozhodne mi dneska prijde krome Springu jeste zajimavy i SEAM. A i kdyz uz jsem pres rok nedelal zadnou webovou aplikaci, chci se zase do zase toho dostat. Puvodne jsem chtel pockat az vyjde oficialne JSF 2.0, ale to bych pak zase musel cekat na neco dalsiho. 🙂
to Dagi> ja chapu, ze je Rod velmi revolucni a ze JCP je na nej pomale. Ja bych byl radeji, kdyby se zasnazil a prosadil dobre veci ze Spring v budoucich verzich Java EE standardu – tim by pomohl vic komunite nez tim, ze bude rikat jak jsou EJB spatne. Ale taky chapu, ze chce prosazovat svuj framework, zvlast kdyz mu z toho kapou finance.
Co se tyce AOP v EJB 3, je s podivem, ze nepouzili jiz existujici znalosti nashromazdene v AOP alliance. Docela by me zajimaly duvody.
Tak jsem uvazoval o tom nepouzivani OOP jak piset. Musim rict ze s tim se neda nez striktne nesouhlasit.
Vidite zasadni rozdil, mezi tim kdyz ma obekt parametry a metody, nebo kdyz ma objekt metody a parametr, ktery predstavuje objekt s dalsimi parametry? Ja v tom nevidmi problem zadny. Preci jestli pristupuju k parametru pomoci this.getParam(), nebo pomoci this.getData().getParam() je jedno.
Pokud vsak narazite na nedusledne vyuzivani dedicnosti, tak v tomhle myslim, ze je uz teroie daleko dal. Jak napriklad ukazuji navrhove vzory. Bezne OOP pocita s tim, ze kdyz kocka i pes vydavaji zvuk, ze bude tato metoda implementovana v predkovi animal, urcite ne v predkovy biostructure, protoze treba plostenka zvuk nevydava. Jenze pak narazite na to, ze kromne s kockou a psem pracujete i s prackou a autem a ty jako dost tezko muzete povazovat za potomky tridy animal a jineho predka ktery by vydaval zvuk nenaleznete. Takze nakonec prijdou na radu rozhrani, wrappery atp, ktere tady jsou prave protoze dedicnost je sice krasna, ale az tak casto ji nepouzijete.
V prikladu toho domaciho mazlicka registrovaneho k dokrovy, pak situace velmi zhoustne, kdyz pravomoc k registraci nema doktro, ale klinika, nebo nejaka sestra. Takze metodu register implementujete u doktora, kliniky i sestricky. Takze nakonec stejne skoncite s datovym objektem zvirete a doktora a funkcnim objektem sestricka. Muzete tvrdit ze je to proceduralni, nebo muzete tvrdit, ze sestricka ma sice zajimavou funkci, ale nezajimave udaje, zatimco zvire a doktor maji velmi zajimave udaje, ale nezajimave funkce. A porad se jedna o OOP.
> Většina Java aplikací není objektově orientována.
Ja som to pochopil tak, že ak funkcionalita pracuje s viacerými objektami (triedy sú vačšinou rôzne), hlavne vo vzťahu 1:n, m:n, niektorí programátori majú tendenciu napchať ten kod do akejsi univerzalnej helper triedy aj keď na to často nie je dôvod.
Helper triedy sú v podstate zoznam procedur napasovaných do OOP.
Aj sa som tak kedysi robil a sypem si popol na hlavu.
Nie je ľahké niekedy určiť ako dobre zapuzdriť správanie.
Pingback: Skrytý drahokam Springu « Java crumbs