Niedawno dostałem do skrzynki takie pytanie:
(...)Głównie nurtuje mnie "jak długo" po otrzymaniu referencji do ejb mogę go używać (kontener może go przecież spasywować/usunąć albo *** wie, co jeszcze zrobić) - mogę z niego korzystać dowolnie długo/pobierać od nowa co wywołanie metody biznesowej czy jeszcze inaczej?
Początkowo miałem po prostu odpowiedzieć i zapomnieć o temacie. Zdalna referencja jest jedynie pośrednikiem (ang. proxy) między kodem klienta a serwerem i tak na prawdę odpowiada jedynie za komunikację z serwerem bez utrzymywania jakiegokolwiek stanu komponentu EJB. Mimo jasnej dla mnie odpowiedzi, postanowiłem sprawdzić ją w ramach niewielkiego eksperymentu, który miał mi nie tylko zweryfikować samą odpowiedź, ale również dać nową na pytanie, ile czasu potrzeba na zestawienie środowiska do jego przeprowadzenia. Do dyspozycji miałem linię poleceń lub IDE. Z IDE jest o tyle problem, że trudno wybrać to jedyne (w przypadku projektów Java EE wskazywałbym na NetBeans IDE), więc pozostałem przy linii poleceń. Tak się bawiłem, że skończyło się na nowym artykule - Jak długo korzystać z referencji bezstanowego komponentu sesyjnego EJB (na przykładzie EJB 3.0 i GlassFish v3).
Wykorzystałem w nim Apache Maven 2.2.1 i GlassFish v3 b66 do zestawienia projektu wielomodułowego, który posłużył mi za materiał testowy. Jest też kilka miejsc oznaczonych TODO, dla osób, które rozmyślają, jakby tu zaangażować się w naukę technologii javowych praktycznie. Ufam, że lektura dostarczy równie wiele zabawy co i mi. Pochwały/nagany mile widziane.
p.s. Zastanawiam się, czy nie warto rozważyć screencastów (brakuje mi dla tego chwytliwego odpowiednika po polsku). Wink, Camtasia, a może jeszcze coś innego? Pewnie z udziałem NetBeans IDE 6.8 dev, bo w końcu tego typu projekty dobrze się w nim robi. Co o tym sądzicie?
Korzystałem z Wink i się nawet sprawdza.
OdpowiedzUsuńOstatnio trafiłem na coś ciekawego: Screenr. Strona www, która pozwala na nagrywanie filmików do 5 minut i jest zintegrowana z twitter. Pierwszy przykład, który popełniłem: http://screenr.com/nCH
Niestety nie da się edytować nagrania. Można je wrzucić na YouTube i tam dodać opisy.
Pozdrawiam,
Krzysztof Kowalczyk
Jedna uwaga, która ogólnie jest globalna do tego typu przykładów. Mianowicie klientowi dostarczasz nie tylko interfejs ale również implementację jako zależność, przez co używanie serwera aplikacyjnego do zdalnej komunikacji jest zbędnym narzutem. Nigdzie jeszcze nie znalazłem przykładu jak to zrobić bez dostarczania implementacji a tylko sam interfejs. Moje próby potwierdziły tylko, że tego nie da się zrobić w przypadku Glassfisha :-(
OdpowiedzUsuń@Krzysiek, wpadłem na screenr i niestety bez głosu to nie dałem rady wytrzymać do końca :( Można prosić o głos?
OdpowiedzUsuń@Łukasz, Faktycznie, nie pomyślałem o tym wcześniej (!) W końcu ta implementacja powinna być bez znaczenia, bo wszystko idzie z serwera aplikacyjnego. Rolą serwera aplikacyjnego jest możliwość dostarczenia usług, które w Java EE deklaruje się zamiast pisać samodzielnie. W obecnej postaci implementacja to System.out/logger, ale przy zaangażowaniu dostępu do bazy danych (przez JNDI), albo kilku, na scenę wchodzi zarządca transakcji, a tego lokalnie nie będziesz miał (nie wspominając o owym wpisie w JNDI). Zbytnio uprościłeś, ale sama uwaga o implementacji słuszna. Spróbuję znaleźć odpowiedź dla Ciebie (wtedy będziemy kwita - Ty mi problem, ja rozwiązanie :))
Z głosem? Eh, może następną, zasadniczo preferuje Wink ta była tylko próbna ;)
OdpowiedzUsuńTematyka którą się zajmuje nie jest zbyt hm... popularna, przynajmniej nie w Polsce i ma strasznie dużo skrótów.
@Krzysiek, przeczytaj to, co napisałeś i sam zobacz, że Ty musisz coś zgłośnić, bo niepopularne a dobre. A jeśli dużo skrótów, to tym lepiej. Jako konsultant będę jeszcze mniej zrozumiały :]
OdpowiedzUsuńWe wnioskach do mojej magisterki rozważałem dopisać - "nie rób tego sam, zatrudnij konsultanta ;)".
OdpowiedzUsuńNajpierw się obronie (Polska październik, Szwecja listopad), potem napisze zaległą recenzje książki o Grails ;), w między czasie znajdę pracę sobie pracę, i pewnie wtedy trochę wypromuje trochę temat...
Nie chodzi mi oto, że nie będzie transakcji, etc. Tylko dostarczasz klientowi wszystko, włącznie z implementacją, czyli coś o czym klient nie powinien wiedzieć. To jak pokazanie wszystkich brudów, jakie normalnie ukrywa się przed klientem ;-)
OdpowiedzUsuńKlient powinien mieć tylko dostęp do interfejsu i informację jak połączyć się z serwerem. Szczegóły implementacji nigdy nie powinny wypłynąć poza serwer.
Trzymam cię za słowo, ja spisałem takie podejście na straty i wolę skupić się lżejszych technikach ;-)
@Łukasz, właśnie mi się udało i spisuję. Innymi słowy: DZIAŁA! Myślałem, że będzie znacznie trudniejsze, ale okazało się wyjątkowo banalne i co ważne przybliża aplikację do takiego podziału na moduły jak życzyłbym sobie we wszystkich aplikacjach, co niezwykle przypomina mi...podział na pakunki OSGi. Zresztą niedługo opublikuję wyniki doświadczeń i sam zweryfikujesz, czy przydatne. Jeszcze raz podziękowania za pomysł! Następnym razem dam Ci wygrać w bilarda :P
OdpowiedzUsuń