[EJB 3] Jak rozproszyć komponenty

Cześć!

Wpadłem na pomysł, żeby na pracę mgr. napisać coś w EJB3, i Struts, które to ostatnio poznałem.

Wiem, że EJB nie warto stosować tylko do tworzenia entity beanów - czyli odwzorowania relacyjnego na obiektowe, bo od tego jest Hibernate.

Chciałem więc rozproszyć system, aby użycie EJB3 było zasadne, tylko nie jestem pewien w jaki sposób.

Chciałbym zrobić tak:

Tomcat - Warstwa WWW (Struts)
2 x Jboss (JBoss_1 + My SQL / JBoss2+Potgres)
I teraz pytanie.
Załóżmy, ze mam dwie tabele: Users i Documents.

Każdy user ma dokumenty jakieś.

Czy żeby to rozproszyć to mogę umieścić na JBossie 1 Tabele users a na jbossie 2 tabele ducuments (Oczywiście połączyć je odpowiednimi kluczami w formie referencji do interfejsów zdalnych).

Czy też Obie tabele mają być i na jednym i na drugim jbossie/bazie, czy też rozproszenie powinno być zaimplementowane przez message driven beany??

Mam nadzieję, że za bardzo nie zakręciłem :)

Pozdrawiam.

Do persistence nie uzywa sie EJB tylko JPA, ktorej werjsa 1 (dosc nieszczesliwie bo jak widac mylaco) znalazla sie jako element specyfikacji EJB3.0, mimo ze mozna ja uzywac calkowicie legalnie bez kontenera EJB. JPA2 i EJB3.1 sa juz rozdzielone.
Co do Hibernate, to moze wiesz a moze nie, tworcami sa miedzy innymi Gavin King i Emmanuel Bernard, bardzo udzielali sie przy tworzeniu spec JPA (1 i 2) i sami wszedzie gdzie tylko mozna zalecaja uzywanie standardowych anotacji JPA, a nie natywnego hibernate. Hibernate mozna uzywac jako providera JPA (1, hiber 3.5 beta 4 nie jest jeszcze zgodna z JPA2).

:: napisał(a)

Do persistence nie uzywa sie EJB tylko JPA, ktorej werjsa 1 (dosc nieszczesliwie bo jak widac mylaco) znalazla sie jako element specyfikacji EJB3.0, mimo ze mozna ja uzywac calkowicie legalnie bez kontenera EJB. JPA2 i EJB3.1 sa juz rozdzielone.
Co do Hibernate, to moze wiesz a moze nie, tworcami sa miedzy innymi Gavin King i Emmanuel Bernard, bardzo udzielali sie przy tworzeniu spec JPA (1 i 2) i sami wszedzie gdzie tylko mozna zalecaja uzywanie standardowych anotacji JPA, a nie natywnego hibernate. Hibernate mozna uzywac jako providera JPA (1, hiber 3.5 beta 4 nie jest jeszcze zgodna z JPA2).

Dziękuję za wykład.
Ale to nie jest odpowiedź na moje pytanie.

Dla zainteresowanych:
http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Clustering_Guide/4/html/index.html

Natomiast teraz interesowało by mnie, jak to wygląda od strony bazy danych.
Ponieważ z tego, co zrozumiałem klaster jbossowy tworzy pewien cache (czy to raczej EJB 3.0 pozwala na cachowanie?).

Pytanie: Czy wszystkie Jbossy łączą się do tej samej bazy?
Czy można np. postawić pod spodem klaster oparty na potgressie/MySQL/Oracle, do którego łączyły by się jbossy.

Pozdrawiam.

@Black007, tak wszystkie JBoss'y będą łączyły się do tej samej bazy. Co więcej będzie to ta sama instancja jeżeli używasz Oracle. Każdy będzie jednak korzystał ze swojej puli połączeń, zatem trzeba wziąć to pod uwagę przy konfigurowaniu bazy, że możesz mieć N*M połączeń gdzie N - ilość węzłów klastra, M - pula w każdym węźle.
Co do klastra bazy danych. To oczywiście można, bo w prawidłowo skonfigurowanym klastrze łączysz się na loadbalancera, który później przydziela połączenia do konkretnych elementów.

Klaster to logicznie jeden logiczny element architektury. Jego fizyczna implementacja nie jest istotna z punktu widzenia użytkownika (klient - JBossa albo Jbossa - Baza).

:: napisał(a)

...sami wszedzie gdzie tylko mozna zalecaja uzywanie standardowych anotacji JPA, a nie natywnego hibernate. ...

A wiesz może dlaczego tak zalecają co jest tego powodem.

Jeśli chodzi o klastrowanie JBOSS na poziomie serwera aplikacji to rozumiem ze jest to klaster bezpieczenstwa tzn jak jeden node pada no nic sie nie dzieje. Ale jak to ma się to wydajności?.Czy klaster zlozony z 4 maszyn chodzi szybciej niz jedna maszyna. Pytanie może wydać się dlupie, a odpowiedz banalna wkoncy 4 kompy sa lepsze niz jeden. Ale jak mam 4 kompy w clustrze w ktorym wspoldziele obiekty entity ktorych jest duzzzzzzzzzoooooo. To czy czas potrzebny na samo klastrowanie/replikowanie własnie tych obiektów nie zamuli tych maszyn

Pozdrawiam

Szczery napisał(a)

A wiesz może dlaczego tak zalecają co jest tego powodem.

Ponieważ dostawca JPA może być różny Hibernatem TopLink, OpenJPA. W razie czego można go swobodnie wymienić. W przypadku Hibernate nie ma takiej możliwości. JPA jest bardziej abstrakcyjne.

Co do wydajności to raczej popatrzyłbym w ten sposób. Jeżeli padnie jeden węzeł to klient nie odczuje tego. Jeżeli ktoś stwierdzi, że twój serwis jest świetnym miejscem do ataku DoS to mając N węzłów możesz przyjąć na klatę większy ruch. To czy klient zostanie szybciej obsłużony zależy w większym stopniu od tego czy aplikacja jest wydajnie napisana.

System działa tak szybko, jak szybko działa jego najsłabsze ogniwo.
Zwykle najwolniejsza jest baza danych.
Jeżeli słaba wydajność jest spowodowana bazą, to dodawanie następnych serwerów aplikacji nic nie pomoże.

Jedną z najważniejszych kwestii jeżeli chodzi o wydajność programów w Javie EE jest umiejętne stosowanie JPA.
Przede wszystkim:

1. Trzeba uważać na złączenia typu eager. Najlepiej ustawić wszystko na lazy i dokonywać złączeń typu eager tylko tam, gdzie jest to konieczne (np. SELECT DISTINCT p FROM Parent p LEFT JOIN FETCH p.children c WHERE p.id = :id)
2. Jeżeli używamy hibernate'a to umiejętnie należy stosować hint'a "org.hibernate.cacheable".