ejb3 + stored procedures
pawelp
mam takie pytanie, bede musial zrealizowac projekt w ktorym trzeba bedzie
wystawic kilka ejb (ejb 3.0). Niestety baza danych juz istnieje i jest
oprogramowana silnie procedurami. Jak w tej sytuacji lepiej zrobic, czy pobrac
datasource adnotacja @resource i wywolywac procedury klasycznie, czy starac
sie wywolywac procedury za posrednictwem entitymanagera. Generalnie z racji
tego ze baza jest stara, to reesultsety z bazy sa dziwne, i nie ma sensu bawic
sie w mapowania tabel poniewaz jest tam jeden wielki balagan.
Jezeli ktos mial doswiadczenie z jedna badz druga sciezka dzialania to prosze
o jakies opinie.
PP
--
Wys�ano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Brzezi
> witam,
>
> mam takie pytanie, bede musial zrealizowac projekt w ktorym trzeba bedzie
> wystawic kilka ejb (ejb 3.0). Niestety baza danych juz istnieje i jest
> oprogramowana silnie procedurami. Jak w tej sytuacji lepiej zrobic, czy pobrac
> datasource adnotacja @resource i wywolywac procedury klasycznie, czy starac
> sie wywolywac procedury za posrednictwem entitymanagera. Generalnie z racji
> tego ze baza jest stara, to reesultsety z bazy sa dziwne, i nie ma sensu bawic
> sie w mapowania tabel poniewaz jest tam jeden wielki balagan.
>
> Jezeli ktos mial doswiadczenie z jedna badz druga sciezka dzialania to prosze
> o jakies opinie.
Jezeli zamierzasz stosowac tylko i wylacznie ziarna sesyjne, ale nie
bedziesz uzywac ziaren encyjnych z tego co piszesz, stosowanie JPA jest
zupelnie bez sensu, bo w takim przypadku bedziesz i tak musial wykonywac
zapytania natywne, czyli SQL, wiec po co do tego angazowac jeszcze entity
managera? uzyj po prostu DataSource wstrzyknietego przez @Resource
Pozdrawiam
Brzezi
pawelp
tak, dokladnie jak mowisz, musze wystawic ejb ktory wlasciwie opakuje
wywolanie procedur, ale chcialem sie upewnic.
Dzieki za odp.
Piotr Pietrzak
>
> tak, dokladnie jak mowisz, musze wystawic ejb ktory wlasciwie opakuje
> wywolanie procedur, ale chcialem sie upewnic.
>
tylko DAO w postaci procedur składowanych, to można na bazie
zdefiniować widoki, do których również można zapisywać (jak masz
procedury do odczytu i zapisu, to taka operacja to bułka z masłem), a
potem zdefinuj sobie na takich widokach mapowanie relacyjno obiektowe.
Projekt taki ma model po stronie DB i jedynie DAO w Javie, co chyba
mniej cuchnie - zmiana w bazie pociąga zmiany w bazie a nie zmiany i w
bazie i w kodzie javowym (np zmiana kolejności parametrów w procedurze
składowanej, lub dodanie jednego). Reszta wad jest taka jak w
przypadku O-R.
Jeśli nie zależy Ci na wydajności, to przemyśl rozwiązanie bez
wywoływania procedur składowanych po stronie javy.
PP
Witold Szczerba
> Jezeli zamierzasz stosowac tylko i wylacznie ziarna sesyjne, ale nie
Tak dla ścisłości: "ziarne encyjne" (Entity Beans) zakończyły swoją
karierę wraz ze specyfikacją EJB 2.1.
JPA to nie są "Entity Beans", nie są zarządzane przez kontener EJB.
> [...] z tego co piszesz, stosowanie JPA jest
> zupelnie bez sensu
Też tak uważam. Pchanie JPA do wszystkiego na siłę jest głupotą w
stylu (mamy w ręce młotek i wszystko zaczyna wyglądać jak gwoździe).
Tak na marginesie, to jeśli będziesz używał zdalnych interfejsów, to
JPA bym odradzał nawet jakbyś bazę danych projektował od zera, ale to
nie jest dyskusja na ten temat.
Brzezi
> Tak dla �cis�o�ci: "ziarne encyjne" (Entity Beans) zako�czy�y swoj�
> karierďż˝ wraz ze specyfikacjďż˝ EJB 2.1.
> JPA to nie s� "Entity Beans", nie s� zarz�dzane przez kontener EJB.
To w takim razie jak sugerujesz naywac klasy zaanotowane @Entity?
Pozdrawiam
Brzezi
Witold Szczerba
> To w takim razie jak sugerujesz naywac klasy zaanotowane @Entity?
Tak, jak je nazywają w specyfikacji: po angielsku po prostu "entiity",
"entities", klasa z adnotacją @Entity to "entity class". Cytat ze
wstępu do rozdziału drugiego Java Persistence API:
---------------
An entity is a lightweight persistent domain object.
The primary programming artifact is the entity class. An entity class
may make use of auxiliary classes
that serve as helper classes or that are used to represent the state
of the entity.
---------------
Po polsku to będzie... encja? Obiekt encyjny, klasa encyjna...
Pod dachem EJB wszystko co jest "Bean" jest obiektem zarządzanym przez
kontener, obiekty... encyjne nie są. Chyba, że weźmiesz prawdziwe
entity beans, ale te ze specyfikacji 2.1. Serwer EJB 3 musi umieć je
obsługiwać.
Tomek Łabuz
ja tam na filozofii za mocno si� nie znam ale chyba bli�sze temu co jest
teraz b�dzie okre�lenie klasa encyjna albo encja, poj�cie "encja" jest
raczej niezwi�zane z konkretn� platform�, a entity bean to by�a cz��
specyfikacji ejb i jak wszystkie ejb by� obdarzony jeszcze ca�� otoczk�
zarz�dzaj�c�
pawelp
> On 2 Gru, 20:06, " pawelp" <pawpietr.SKA...@gazeta.pl> wrote:
> >
> > tak, dokladnie jak mowisz, musze wystawic ejb ktory wlasciwie opakuje
> > wywolanie procedur, ale chcialem sie upewnic.
> >
> Jest jeszcze co najmniej jedna sensowna opcja - je=B6li chcesz mie=E6
> tylko DAO w postaci procedur sk=B3adowanych, to mo=BFna na bazie
> zdefiniowa=E6 widoki, do kt=F3rych r=F3wnie=BF mo=BFna zapisywa=E6 (jak mas=
> z
> procedury do odczytu i zapisu, to taka operacja to bu=B3ka z mas=B3em), a
> potem zdefinuj sobie na takich widokach mapowanie relacyjno obiektowe.
> Projekt taki ma model po stronie DB i jedynie DAO w Javie, co chyba
> mniej cuchnie - zmiana w bazie poci=B1ga zmiany w bazie a nie zmiany i w
> bazie i w kodzie javowym (np zmiana kolejno=B6ci parametr=F3w w procedurze
> sk=B3adowanej, lub dodanie jednego). Reszta wad jest taka jak w
> przypadku O-R.
> Je=B6li nie zale=BFy Ci na wydajno=B6ci, to przemy=B6l rozwi=B1zanie bez
> wywo=B3ywania procedur sk=B3adowanych po stronie javy.
>
> PP
jakby to odemnie zalezalo .. :) niestety ale projekt dla jednego z duzych
telekomow a tam niestety im mniej innowacji tym lepiej. Bede mial wystawione
procedury i nic wiecej wiec robienie widokow nie wchodzi w gre. Ja jedynie mam
zrobic ejb zeby wysrawic to na zewnatrz dla innych komponentow
Piotr Pietrzak
> Piotr Pietrzak <pi...@macintosh.pl> napisał(a):
ESB*. Jestem po świeżej porażce aplikacji na serwerze aplikacyjnym,
która jest tylko proxy pomiędzy web service a procedurami w bazie.
Zdecydowaliśmy wycofać się z EJB i przejść na coś light - udało się z
camelem. Dzięki temu mamy ładne proxy pomiędzy WS a bazą danych i
praktycznie z małą ilością własnego kodu.
Wadą aplikacji na czystym serwerze aplikacyjnym jest to, że w sumie,
to pisze się masę kodu, który odnosi się wrażenie, że powinien zostać
wygenerowany - tzn. podczas programowania odczuwa się bardziej
zmęczenie palców, niż mózgu. Był jeszcze problem z podłączeniem
wszystkich wymaganych transportów do serwera aplikacyjnego - do
glassfisha nie ma za bardzo jak podłączyć Oracle AQ.
Dodam jeszcze, że jest wsparcie dla czystego JDBC w camel
http://camel.apache.org/jdbc.html
W naszym projekcie użyliśmy jeszcze czegoś takiego jak Oracle AQ
(Advanced queue), czyli kolejki po stronie bazy. Wywołania metod WS
generują wiadomość odkładaną w bazie w MQ, gdzie następuje
przetworzenie i zwrotnie wysyłana jest odpowiedź do MQ a z tamtąd
wraca do WS. Dzięki takiemu podejściu zmieniając sporo po stronie bazy
danych nie trzeba ruszać części "javowej".
Można jeszcze zaszaleć i pójść w bogatsze ESB - np taki ServiceMix
nawet daje radę (a w wersji 4 można sobie poćwiczyć OSGi).
Myślę, że pewnie Twoje EJB i tak skończą za chwilę jako @WebService
(endpointInterface = "a.moglem.uzyc.ESB") .
Wracajac do smutnej rzeczywistości - skoro czeka Cię sporo klepania,
to Spring JDBC Template pozwala troszkę sobie życie uprzyjemnić i
zapomnieć o obsłudze wszystkich możliwych błędów, dodatkowo opakowuje
wyjątki bazodanowe dzięki czemu podmiana bazy nie zmienia obsługi
błędów. Dla mnie to istotne, bo prototypuje na PostgreSQL, a produkcje
mam na Oracle.
* W zależności od przyjętej definicji projekty takie jak apache camel
albo zalicza się do ESB albo nie.