Krome hessian je take pomerne rychly JBoss remoting http://www.theserverlabs.com/blog/2009/02/19/jboss-remoting-jboss-serialization-kills-javarmi-and-spring-remoting/
ma par dalsich ficur navic v porovnani s RMI. Co se tyka poolu na DAO, tak existuje na to nejaky Apache projekt http://commons.apache.org/pool/ (blize to neznam). Ovsem pokud jsou tvoje DAO jednoduche na inicializaci a ruseni, tak je nema smysl poolovat. Alokace pameti v Jave je rychlejsi nez v C. Poolovani ma smysl, az kdyz se provadi nejake slozite inicializace. Otazka jestli nejaky aplikacni server se session beans nebo ne je tedy spise otazka, co muze app. server nabidnout navic k obycejnemu RMI-like reseni. Podle meho nazoru to muze byt treba (JBoss) to poolovani, transakce, moznost mit vice verzi aplikace pres classloader isolation, pohodlne vyvareni administratorskeho rozhrani k aplikaci pres MBeany nebo servlety, a muzes si psat JavaEE do CV :-))). Dale treba muzes v budoucnu potrebovat distribuovanou cache, nebo i treba stateful beanu v distribuovanem prostredi. Pokud nic z toho nepotrebujes (a potrebovat nebudes), tak se klidne app. serveru vyhni. My mame Java Swing aplikaci a mezivrstvu pres stateful beans na JBossu. V podstate vyuzivame hlavne moznost snadneho deploy nove verze (se zachovanim te stare, klienti se neupdatuji najednou) a jednu MBeanu pro zakladni informaci o behu aplikace (viditelne pres web rozhranni nazyvane JMS console). 2009/9/14 salmonel salmonel <[email protected]>: > Ohľadom rýchlosti - nejde mi o nejakú tú milisekundu, skôr je podstatné, aby > jeden server utiahol čo aby najviac klientov. Medzivrstvu vytvoriť musím, > ako som už písal, mám M klientov, ktorí lezú do N databáz. Občas však musím > nejakú databázu odobrať alebo pridať. Bolo by veľmi zložité aktualizovať > konfiguráciu pre všetkých M klientov. Použitie medzivrstvy by bolo podľa mňa > oveľa jednoduchšie. > Web aplikácia pristupuje k DAO cez interface, inštancie dao získava z > DaoFactory - takže prechod na medzivrstvu bude len prepísanie daofactory. > Potreboval by som skôr vedieť, či použiť nejaký aplikačný server so > stateless ejb, alebo samostatnú JVM aplikáciu, na ktorú by sa klienti > pripájali cez RMI(prípadne Hessian, ďakujem za upozornenie na túto > technológiu). > > V súčasnosti nepoužívam žiaden pool na dao - pri každej akcii sa dao(trieda > neobsahuje žiadne atribúty) vytvorí a po skončení ho zase musí garbage > collector zlikvidovať. To je asi chyba. Dá sa implementovať nejako > jednoducho pool na stateless klassy aj bez aplikačného servra? > > 2009/9/14 Stanislav Poljovka <[email protected]> >> >> Ja by som to riesil nasledovne: >> 1) premenovanie implementacie povodnych DAO tried pre pristup do lokalnej >> databazy >> 2) extrakcia metod (pull-up) do DAO interface-u pri zachovani povodneho >> pomenovania DAO tried >> 3) implementacia DAO tried na pristup cez RMI/REST/Hessian ... na ine >> servre a samozrejme aj serverovu cast pre dany typ komunikacie. Mozete sa >> inspirovat clankom >> http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/ >> >> Neviem, ako ziskavate instancie DAO objektov, ale ak: >> >> A) DAO mate spravovane cez spring, potom vsetky potrebne kombinacie >> pouzitia treba riesit viacerymi konfiguraciami spring bean-ov. Potom nie >> potrebne menit zvysok aplikacie (lebo DAO je interface s povodnym menom a >> ten teraz odkazovany v business / service vrstve). Horsie to bude z >> build-ovanim aplikacie alebo z deploymentom (buildovat vsetko a konfiguracne >> urcit, ktory sping beans sa ma pouzit). >> >> B) DAO mate spravovane manualne, tak to bude potrebne upravit v >> business/service vrstve asi nasledovne: >> 4) Vytvorit DAOHelper, ktory by podla potreby (on demand) / konfiguracie / >> service API / .. zpristupnil (cez spring / factory / ..) prislusne DAO >> objekty >> 5) zmenit ziskavanie instancie DAO v business / servisnej vrstve ... nieco >> ako MyDAO myDao = DAOHelper.getDAO(MyDAO.class) alebo = >> DAOHelper.getDAO(MyDAO.class, "serverA") >> Pozn.: Tu by som zvazoval radsej to prerobit na sposob A), ale to nemusi >> byt priechodne (ak napr. potrebujete robit naraz z objektami rovnakej triedy >> z roznych zdrojov / DB / .. on demand z dopredu stanovenymi serverami). >> >> Ohladne tej vykonosti, by som zvazoval zavedenie >> distribuovanej/cluster-ovej cache (napr. Terracotta + ehcache). Aj ked, ako >> si tak uvedomujem, tak to nemusi mat pozitivny vykonnostny efekt pre >> persistente objekty z druhej DB, lebo je takmer jedno ci sa kumunikuje cez >> RMI / REST / ... alebo cez komunikacne kanaly terracotta-y (hlavne pri >> vysokom zatazeni). >> >> Stano >> >> salmonel salmonel wrote: >> > Dobrý deň, >> > >> > mám web aplikáciu v jave, je napísaná v Spring web flow, používa >> > Hibernate pre perzistenciu objektov. K hibernate pristupujem vždy cez DAO. >> > >> > Momentálne aplikácia beží v tomcate. Potrebujem pridať medzi databázu a >> > tomcat vrstvu, v ktorej by boli všetky dao objekty. Na servroch nám totiž >> > beží niekoľko inštancií našej aplikácie(máme niekoľko klientov), tieto >> > inštacie majú každá vlastnú databázu. Niekedy však potrebuje jedna inštacie >> > liezť aj do databáze druhej inštancie. Preto chcem centralizovať prístup k >> > databázam. >> > >> > Podstatné je, že potrebujem pridať vrstvu, v ktorej by boli len DAO >> > objekty. Podľa toho, čo som pochopil mám na výber medzi EJB statless >> > beanami >> > bežiacimi v JBOSSe(prípadne inom aplikačnom servri), alebo si spraviť >> > vlastnú aplikáciu, ktorá by obsahovala dao objekty a fungovala ako RMI >> > server. Tomcat by bol RMI klient a vždy kontaktoval server. O pooling >> > databázových pripojení by sa postaral hiberante. >> > >> > Aplikácia už je naprogramovaná, iné výhody EJB asi nevyužijem. Ide mi >> > najmä o vysoký výkon a budúcu škálovatelnosť(s ktorou by nemal byť problém, >> > ide o stateless objekty, takže môžem nasekať koľko chcem RMI servrov, ktoré >> > nemusia medzi sebou komunikovať). >> > >> > Ďakujem >> >> > > -- Ondra Medek
