pátek 14. ledna 2005

Re:EJB aneb jeden obsáhlý komentář

Ke spotu Kdy použít EJB?, se váže velice zajímavé řešení, které nakousnul Pavel Roušar alias Totem. S jeho laskavým svolením publikuji detailnější popis řešení, které mě zaujalo a doufám, že zaujme i vás.

Nas uKernel neni postaven na konkretni technologii, tj. napr. JMS. Jedna se o pure java kod, nezavisly na cemkoliv krome JRE. Nicmeme JMS/MQ service je poskytovana - jako kazda jina obycejna sluzba, prostrednictvim MessagingBrokeru.

O JBossim mikrojadru jsem taky slysel, myslim, ze jsi tu mel odkaz na to uvolnene html. Classloading si nicmene resime sami, ale treba JMX se snad podari protlacit jako dalsi broker, urceny pro sluzby ohledne spravy service queues a vlastniho mikrojadra.

On sam uKernel v podstate nic nedela, vsechno se odehrava v "userspace". Dokonce i prava jsou resena takto transparentne, tj. zadny zasah do kodu uKernelu a uz vubec neni nutna implementace u konzumentu (ackoliv je mozna). O vlastni strukture bych rekl asi tolik, ze kazda service, resp. service request, je (zatim pomoci konfig. xml) namapovan na queue, ke ktere patri service stack. pozadavek pak propadava v queue a na zaver je POJO vraceno konzumentovi. Snazil jsem se o abstraktni pristup, takze vse je jenom N dimenzionalni vektor zobrazeni z mnoziny produktu do mnoziny producentu.

Tento koncept mimo svou cistotu (poskytuji nejake sluzby, tak mi popis ci chces a ja ti to obstaram. nemusis se starat o implementacni detaily, neafektuj zbytecne svuj kod. jen mi to protokolem popis a uvidime...) umoznuje delat takove vychytavky (je to holt mikrojadro) jako napr. transparentni loadbalancing, cachovani, filtrovani, prava, ... treba: odesel jeden koder a potrebovali jsme jeho service broker naucit cachovat. tak jsem mu proste do patricne queue pred/zaradil caching broker a bylo hotovo... to mozna trochu zavani AOP.

Ve vlastnim holem jadru muze kazdy delat co chce (registrovat nove sluzby, odebirat je, ...). uKernel je sice cisty a jednoduchy, ale neni to ono. Proto je prvnim ServiceBrokerem v Queue zarazen "stavovy filtr", takove male iptables a ten za sebe propusti jen ty pozadavky (treba na load/unload service brokeru), ktere prichazi od duveryhodneho objektu (modul je treba podepsany). Je to ale jen jeden z dalsich brokeru.

Takovy je zakladni, myslim rozumny a jednoduchy, koncept. technologie se myslim mimoradne osvedcila pri psani jednoho extremne velikeho portalu (posta jej bude brzo zpoustet). A dalsi projekty nasleduji. Kod je potom tak strukturovany, prehledny, ze to kodovani zacina byt pekna nuda.

Pokud by jsi mel zajem a chut se na tom podilet, nebo proste jen prohodit par slov, nebo nekdo z tvych ctenaru, bylo by to fajn. Mozna by si to pozdeji zaslouzilo pozornost i od ASF.

Do pranice: App server cache

Do pranice bude nová rubrika Dagblogu, ve které bych rád slyšel názory čtenářů na odborná témata. Na výběru témat se může podílet kdokoliv, stačí když mi jej napíšete a případně připojíte vlastní názor. Pro kickoff této rubriky jsem si vybral řešení cacheování dat na aplikačním serveru. Původně jsem to zkoušel v diskusních skupinách na java@builder.cz a konference@java.cz, ale ohlas nebyl takový.

zajimalo by me reseni cacheovani dat na apikacnim server. Rekneme, ze mame klasickou webovou aplikaci, ktera pouziva pro ziskani dat JDBC. Jde o to, ze business logika definuje opravdu vypecene pozadavky, takze SQL dotazy jsou velice narocne a jsou nad velkou kupou dat. S webovou aplikaci pracuje velke mnozstvi uzivatelu, takze zatizine SQL serveru se pekne sroubuje nahoru a tim se zpomaluje i celkova odezva aplikace.

Lze takto nastavene prostredi modifikovat, tak aby se SQL serveru ulevilo? Muj nazor je ten, ze bez pridani vrstvy mezi databazi a aplikacni logiku, nelze dosahnout patricneho efektu. Ta vrstva by mela primarne zarucit cacheovani dat (nejedna se mi o ORM). Klienti vrstvy, v nasem pripade primo business logika, nepise SQL (pro to co se rozhodneme cacheovat), ale vyuzivaji tuhle vrstvu. Na urovni vrstvy samzorejme lezi predefinovane SQL, ktere zaruci fyzicke rabovani dat z DB.

Dejme tomu, ze mame dotaz, ktery vraci data pro zobrazeni seznamu osob, pak tedy sloupecky v select tvori sloupecky, ktere mohou dat vzniknout objektu Osoba. Objekt osoba je pak mozne cacheovat nebot se bude v podstate jednat o POJO. Zbezne jsem koukal na JCS a to me v tom utvrzuje.

pondělí 10. ledna 2005

Microsoft EMEA Architect Tour - Enterprise patterns v Praze

BonzBlog alias Michael Juřek poskytl krátkou noticku o připravované akci Microsoft EMEA Architect Forum s tématem integrace aplikací a Enterprise Integration Patterns. Část programu, lépe řečeno některé session, povedou lidé z ThoughtWorks. Vzhledem k tomu, že hlavním tématem budou DP a integrace aplikací, bude tato akce nad rámec jednotlivých platforem.

Pokud vám firma ThoughtWorks nic neříká, pak zkusím jméno softwarového architekta Martina Fowlera, na kterého jsem několikrát na stránkách Dagblogu odkazoval a velice si jej považuji. V poslední době jsem nějaký čas strávil studiem Continuous Integration a Fowlerův článek byl velice nápomocný, ale to trochu odbočuji neboť k tématu Continuous ntegration bych se rád vrátil samostatným spotem.