Ja to nechapu :-). Tim, ze pridate RMI a centralizujete to jednoho mista
tak si prece vubec nepomuzete. RMI vam prinese overhead v podobe
serializace/deserializace. Tim, ze to centralizujete, budete muset resit
rozlozeni zateze na ten centralni uzel. Jinymi slovy jedine co vam to
prinese bude slozitejsi deployment. Navic to zpusobi, ze klienti se
budou vzajemne ovlivnovat.
Pokud jsou vase DAO objekty stateless, tedy nemaji zadny stav, tak nevim
co resite. Poolovani jejich instanci je zbytecnost vzhledem k efektivite
dnesnich garbage collectoru. Osobne bych mel pro kazdou z tech aplikaci
vlastni instance te DAO vrstvy s ruznou konfoguraci kde bude recene na
jake DB se maji pripojit.
Ondra Medek napsal(a):
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
--
S pozdravem Roman "Dagi" Pichlik
/* http://www.sweb.cz/pichlik/ Blog pro kodery */
