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

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.

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

• Under the Hood of J2EE Clustering autorstwa Wang Yu
• Skalowanie aplikacji Java EE autorstwa Wang Yu
• Skalowanie aplikacji Java EE - część 2 autorstwa Wang Yu

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.

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.

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