EJB - kiedy używać interfejsów zdalnych i / lub lokalnych?


180

Jestem bardzo nowy w Javie EE i staram się zrozumieć koncepcję interfejsów lokalnych i interfejsów zdalnych. Powiedziano mi, że jedną z wielkich zalet Java EE jest łatwość skalowania (co moim zdaniem oznacza, że ​​możesz wdrażać różne komponenty na różnych serwerach). Czy tam właśnie wchodzą interfejsy zdalne i lokalne? Czy powinieneś używać interfejsów zdalnych, jeśli spodziewasz się, że Twoja aplikacja będzie mieć różne komponenty na różnych serwerach? I użyj Lokalnych interfejsów, jeśli Twoja aplikacja będzie znajdować się tylko na jednym serwerze?

Jeśli moje powyższe założenia są prawidłowe, jak byś wybrał, czy użyć nowej lub lokalnej wersji interfejsu dla nowej aplikacji, a gdzie nie masz pewności co do natężenia ruchu? Zaczynasz od korzystania z interfejsów lokalnych i stopniowo uaktualniasz do interfejsów zdalnych, jeśli dotyczy?

Dziękujemy za wszelkie wyjaśnienia i sugestie.

Odpowiedzi:


186

Jestem bardzo nowy w Javie EE i staram się zrozumieć koncepcję interfejsów lokalnych i interfejsów zdalnych.

W początkowych wersjach specyfikacji EJB „EJB” były „zakładane” jako komponenty zdalne, a jedynym sposobem na ich wywołanie było nawiązanie zdalnego połączenia przy użyciu semantyki RMI i całego związanego z tym narzutu (połączenie sieciowe i serializacja obiektu dla każdego wywołanie metody). Klienci EJB musieli ponieść tę karę wydajności, nawet gdy byli umieszczeni na tej samej maszynie wirtualnej z kontenerem EJB.

Później firma Sun zdała sobie sprawę, że większość aplikacji biznesowych nie dystrybuuje EJB na innym poziomie i naprawiła specyfikację (w EJB 2.0), wprowadzając koncepcję interfejsów lokalnych, dzięki czemu klienci kolokowani na tej samej maszynie wirtualnej z kontenerem EJB mogą wywoływać EJB za pomocą bezpośrednie wywołanie metody, całkowicie omijając semantykę RMI (i związane z tym koszty ogólne).

Powiedziano mi, że jedną z wielkich zalet Java EE jest łatwość skalowania (co moim zdaniem oznacza, że ​​możesz wdrażać różne komponenty na różnych serwerach)

Java EE można skalować, ale niekoniecznie oznacza to dystrybucję komponentów. Możesz uruchomić aplikację Web + EJB w klastrze bez oddzielania warstwy Web i warstwy EJB.

Czy powinieneś używać interfejsów zdalnych, jeśli spodziewasz się, że Twoja aplikacja będzie mieć różne komponenty na różnych serwerach? I użyj Lokalnych interfejsów, jeśli Twoja aplikacja będzie znajdować się tylko na jednym serwerze?

Powiedziałbym to w ten sposób: użyj zdalnych interfejsów, jeśli klient nie jest w tej samej maszynie JVM (nie oznacza to, że używasz tylko jednego serwera / maszyny JVM).

(...) Zacznij od korzystania z interfejsów lokalnych i, w stosownych przypadkach, stopniowo przechodź na interfejsy zdalne?

Prawdopodobnie zacznę od korzystania z lokalnych interfejsów. I jak już wspomniano, przejście na zdalne interfejsy nie zawsze jest obowiązkowe (można grupować skolokowaną strukturę).

Sugeruję sprawdzenie zasobów wymienionych poniżej (2 pierwsze są dość stare, ale wciąż aktualne, pozostałe 2 są nowsze).

Zasoby


2
Uważam to pytanie za interesujące. Co miałeś na myśli mówiąc, że „przejście na zdalne interfejsy nie jest absolutnie obowiązkowe”? Czy to oznacza, że ​​kiedy dodajesz nowego klienta poza tą samą maszyną JVM, nie musisz tworzyć interfejsu zdalnego?
mohamida

2
@Josek Dzięki, cieszę się, że ci się podoba @mohamida Wprowadziłem niewielką zmianę w brzmieniu. Miałem na myśli to, że możesz grupować skolokowaną strukturę.
Pascal Thivent,

1
Dzięki za odpowiedź i dodatkowe zasoby były bardzo pomocne. Wygląda na to, że istnieje kilka sposobów skalowania aplikacji internetowej ... tj. Dystrybucja komponentów (co uważam za podział różnych warstw na różne maszyny JVM?) Lub użycie równoważenia obciążenia (które obejmowałoby całą aplikację liczne serwery?) i przypuszczam, że możesz użyć kombinacji obu? Czy przypadkiem znasz dobre książki na ten temat? Dzięki jeszcze raz!
Brian DiCasa,

2
@Brian It seems like there are a couple ways of scaling a web application (...) and I suppose you could use a combination of both?Tak, właśnie o to chodzi. Do you, by chance know of good books on this topic?Niestety nie, nie znam absolutnego zasobu „ZE”, jeśli taki istnieje. Dodałem jednak więcej zasobów z kilkoma referencjami.
Pascal Thivent,

pierwszy link do zasobów jest martwy
Viacheslav Dobromyslov

48

Chociaż zgadzam się z większością tego, co jest napisane powyżej, chciałbym nieco dopracować pomysły „jak zacząć”.

Sugeruję ci, abyś nigdy nie programował bezpośrednio do interfejsów EJB w swoim kodzie. Zawsze używaj zwykłego interfejsu biznesowego, programu do niego (co oznacza, że ​​masz metody wywoływania kodu w interfejsie biznesowym) i podaj kod „kleju” EJB jako implementację wtykową. Twój program powinien koncentrować się na logice biznesowej, a nie na szczegółach implementacji, takich jak EJB.

W ten sposób możesz łatwo przełączać się między implementacjami zdalnymi i lokalnymi - a jeśli korzystasz z kontenera IoC, takiego jak Spring, możesz to zrobić tylko za pomocą konfiguracji.

Specjalna uwaga na temat przełączania z lokalnego na zdalny: zauważ, że istnieje kilka różnic semantycznych między nimi. Na przykład wywołanie metody EJB przez „zdalny interfejs” powoduje przekazanie argumentów według wartości, podczas gdy wywołanie przez „interfejs lokalny” powoduje przekazanie argumentów przez odwołanie. To jest główna różnica; więc jeśli „zaczynasz od lokalnego”, upewnij się, że projektujesz system w taki sposób, aby uwzględniał również „zdalną” semantykę.

Jeśli twój projekt opiera się na metodach EJB zmieniających przekazane obiekty, później trudno byłoby „przełączyć się na zdalne”; może nawet niemożliwe.

Powodzenia.


2
brzmi jak kolejny powód do zminimalizowania zmienności na skuteczną Javę. czy pomogłoby to w elastycznym „przełączaniu na zdalne” dla interfejsu typu RMI z EJB?
Thufir,

19

Zgodnie z EJB Spec 3.2 EJB może być lokalny lub zdalny . Interfejs biznesowy nie może być jednocześnie lokalny ani zdalny.

@Local do fasoli z adnotacjami można uzyskać dostęp tylko wtedy, gdy są w tej samej aplikacji.

@Remote do ziaren z adnotacjami można uzyskać dostęp do różnych aplikacji, znajdujących się w różnych środowiskach Jvms lub na różnych serwerach aplikacji.

Ważnymi rzeczami do zapamiętania są:

  1. Jeśli klasa komponentu bean zawiera @Remoteadnotację, wszystkie zaimplementowane interfejsy mają być zdalne.
  2. Jeśli klasa komponentu bean nie zawiera adnotacji lub jeśli @Localadnotacja jest określona, ​​zakłada się, że wszystkie zaimplementowane interfejsy są lokalne.
  3. Wszelkie interfejsy, które są jawnie zdefiniowane dla komponentu bean, który nie zawiera interfejsu, muszą zostać zadeklarowane jako @Local.
  4. Wydanie EJB 3.2 zapewnia większą szczegółowość w sytuacjach, w których lokalne i zdalne interfejsy muszą być wyraźnie zdefiniowane.

1
Pytanie: Czy można użyć @Localdo wywołania EJB w innej aplikacji (JAR, WAR, EAR), ale w tej samej JVM?
Carlitos Way

@PritamBanerjee Każdy pomysł na Carlitos Wa, ja też mam do czynienia z tym samym problemem. EJB jest w innym klastrze, a aplikacja serwletu klienta jest w innej.
Govi S

@GovindaSakhare Nie jestem tego pewien. Przepraszamy :(
Pritam Banerjee

7

To może odpowiedzieć na twoje obawy:

Zasadniczo komponent Enterprise Java Bean będzie potrzebował zdalnego widoku klienta w przypadkach, gdy planowane jest użycie komponentu bean w środowiskach rozproszonych. W szczególności są to przypadki, w których klient, który będzie z nim pracował, będzie na innej maszynie wirtualnej Java (JVM). W przypadku widoku zdalnego klienta wywołanie dowolnej metody ze zdalnego interfejsu domowego i / lub interfejsu zdalnego komponentu będzie obsługiwane przez zdalne wywołanie metody (RMI).

EJB może korzystać z widoku lokalnego klienta tylko wtedy, gdy jest naprawdę zagwarantowane, że inne komponenty bean lub klienci korporacyjni będą adresować bean tylko w ramach jednej maszyny JVM. W takim przypadku dostęp będzie realizowany za pomocą bezpośrednich wywołań metod zamiast RMI.

Źródło: http://www.onjava.com/pub/a/onjava/2004/11/03/localremote.html?page=last&x-showcontent=text

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.